Raspberry Pi 4's IP Address 169...

[Patrick Zacharczyp]

My Raspberry Pi 4 that I got recently has a 169.XX. IP address and I am trying to get it connected to the internet and install something. This happened to my other Raspberry Pi. Could someone help me? I tried doing some things in my router and I even used a command to add a static IP. I used a USB 3.0 to ethernet adaptor w/ my last Pi, and it worked, but it couldn't update. Someone please help as I spent a lot of money on this.

[Tauno Voipio]

On 7.1.22 21.18, Patrick Zacharczyp wrote:
> My Raspberry Pi 4 that I got recently has a 169.XX. IP address and I am trying to get it connected to the internet and install something. This happened to my other Raspberry Pi. Could someone help me? I tried doing some things in my router and I even used a command to add a static IP. I used a USB 3.0 to ethernet adaptor w/ my last Pi, and it worked, but it couldn't update. Someone please help as I spent a lot of money on this.

The 169.254.xx.yy address is a local link addres given by the
Pi after it has not succeeded to get an address from your router.

Check that your router has DHCP server enabled and that it
sees your Pi at Pi start up.

--

-TV

[Patrick Zacharczyp]

Hello, I will try that out. I will report back to you after I do it and test it. My other raspberry pi's automaticly show up on the list. I also use a TP-Link router.

[Marco Moock]

Please post the output of
ip a

Use a network Sniffer like Wireshark (maybe on another computer) and
sniff for DHCPv4 packages. Check if the Pi sends out a DHCP Discovery.

[NY]

"Marco Moock" <mo...@posteo.de> wrote in message
news:20220108130259.4e5d46fb@ryz...

There is the possibility that Wireshark run on *another* computer may not
see much of the DHCP conversation because the network switch in the router
may filter out traffic that is not from/to the computer that is running
Wireshark. However I think that the initial DHCP broadcast or multicast from
the Pi should should up.

Patrick, am I right that you are connecting the Pi to the router using
Ethernet? Try initially to get it working with Ethernet (to keep things as
simple as possible) even if you intend long-term to connect by wifi.

I'm worried that you had the same problem with another Pi previously and
that you need to use a USB-to-Ethernet adaptor instead of being able to use
the one that is built in to the Pi.

Are other computers (eg Windows, Mac, Android phone) able to connect to the
router (either by Ethernet or wifi) and are they getting sensible
192.168.x.y addresses? That will at least prove that DHCP is working
properly on the router, which is the first thing to confirm, before relying
on DHCP to give the Pi an IP address.

I think I'm right that if the Pi happened to be set to use a static IP,
configured at the Pi, that is the address that "ip a" or "ifconfig" would
report. But what would happen if the static address clashed with one that
the router had allocated to something else by DHCP? Would that make the Pi
report a 169.a.b.c address instead of the static one that had been
configured on the Pi?


When you say "I even used a command to add a static IP" was this using the
"address reservation" feature that is found on many modern routers, which
tells DHCP always to allocate the same IP to a device with a given MAC
address? Or was it done at the Pi to tell it to use a static address instead
of using DHCP? Can you remember what the command was?

Let's hope we all manage to solve your problem. A Pi running Raspberry PiOS
(aka Raspbian), connected by Ethernet to a router running DHCP, should work
without any configuration at the Pi or the router.

[The Natural Philosopher]

On 08/01/2022 14:52, NY wrote:
> "Marco Moock" <mo...@posteo.de> wrote in message
> news:20220108130259.4e5d46fb@ryz...
>> Am Freitag, 07. Januar 2022, um 11:18:57 Uhr schrieb Patrick Zacharczyp:
>>
>>> My Raspberry Pi 4 that I got recently has a 169.XX. IP address and I
>>> am trying to get it connected to the internet and install something.
>>> This happened to my other Raspberry Pi. Could someone help me? I
>>> tried doing some things in my router and I even used a command to add
>>> a static IP. I used a USB 3.0 to ethernet adaptor w/ my last Pi, and
>>> it worked, but it couldn't update. Someone please help as I spent a
>>> lot of money on this.
>>
>> Please post the output of
>> ip a
>>
>> Use a network Sniffer like Wireshark (maybe on another computer) and
>> sniff for DHCPv4 packages. Check if the Pi sends out a DHCP Discovery.
>
> There is the possibility that Wireshark run on *another* computer may
> not see much of the DHCP conversation because the network switch in the
> router may filter out traffic that is not from/to the computer that is
> running Wireshark. However I think that the initial DHCP broadcast or
> multicast from the Pi should should up.
>

I have run tcpdump while debugging DHCP. You see the initial broadcast.
....

> A Pi running Raspberry
> PiOS (aka Raspbian), connected by Ethernet to a router running DHCP,
> should work without any configuration at the Pi or the router.

WHS


--
"And if the blind lead the blind, both shall fall into the ditch".

Gospel of St. Mathew 15:14

[Marco Moock]

Am Samstag, 08. Januar 2022, um 14:52:07 Uhr schrieb NY:

> "Marco Moock" <mo...@posteo.de> wrote in message

> There is the possibility that Wireshark run on *another* computer may
> not see much of the DHCP conversation because the network switch in
> the router may filter out traffic that is not from/to the computer
> that is running Wireshark. However I think that the initial DHCP
> broadcast or multicast from the Pi should should up.

No, the DHCPv4 discovery message from the Pi is being sent to the
broadcast MAC address (FF:FF:FF:FF:FF:FF). Every switch has to sent out
that frame on every port except the port it came from.

> I think I'm right that if the Pi happened to be set to use a static
> IP, configured at the Pi, that is the address that "ip a" or
> "ifconfig" would report. But what would happen if the static address
> clashed with one that the router had allocated to something else by
> DHCP? Would that make the Pi report a 169.a.b.c address instead of
> the static one that had been configured on the Pi?

ip a reports the IP addresses that an are assigned to an interface -
regardless how they were assigned (static, auto configuration, DHCP).

[NY]

"Marco Moock" <mo...@posteo.de> wrote in message

news:20220108183111.318f397f@ryz...

> Am Samstag, 08. Januar 2022, um 14:52:07 Uhr schrieb NY:
>
>> "Marco Moock" <mo...@posteo.de> wrote in message
>
>> There is the possibility that Wireshark run on *another* computer may
>> not see much of the DHCP conversation because the network switch in
>> the router may filter out traffic that is not from/to the computer
>> that is running Wireshark. However I think that the initial DHCP
>> broadcast or multicast from the Pi should should up.
>
> No, the DHCPv4 discovery message from the Pi is being sent to the
> broadcast MAC address (FF:FF:FF:FF:FF:FF). Every switch has to sent out
> that frame on every port except the port it came from.

Yes I imagine the first part of the DHCP conversation is at broadcast level.
I couldn't remember how far through the process it stayed at broadcast level
before becoming a point-to-point conversation. Though thinking about it, the
client (the Pi) doesn't *know* what its IP address is until the end of the
conversation when the DHCP server has said "yes, you really *can* use the
address that I proposed earlier in the conversation".

>> I think I'm right that if the Pi happened to be set to use a static
>> IP, configured at the Pi, that is the address that "ip a" or
>> "ifconfig" would report. But what would happen if the static address
>> clashed with one that the router had allocated to something else by
>> DHCP? Would that make the Pi report a 169.a.b.c address instead of
>> the static one that had been configured on the Pi?
>
> ip a reports the IP addresses that an are assigned to an interface -
> regardless how they were assigned (static, auto configuration, DHCP).

I wasn't sure what IP address "ip a" would report if a computer was
statically configured to use an IP address that happened to clash with one
being used by another computer (whether that second computer got its IP
statically or by DHCP). In other words, if "ip a" is reporting a 169.a.b.c
address, does that imply that the Pi is configured to use DHCP, or could it
alternatively mean that it is configured statically but there is an IP
clash.

I'm still puzzled by why he has had the problem on more than one Pi and why
he's using an external USB-Ethernet adaptor rather than the built-in
Ethernet port: I bet one or other of those is at the root of why he's having
problems getting DHCP to work.

Suppose the 169 address relates to the built-in adaptor and not the external
one. Suppose the external one isn't even listed because it's not working due
to a lack of drivers.

"ip a" should reveal all...



Patrick, when you've got the output of "ip a" with your current setup, can
you try plugging the Ethernet cable instead into the Pi's own Ethernet port
rather than the external USB/Ethernet adaptor, and repeat the "ip a".

So you've got something to compare your "ip a" output against, here's mine
for a Pi 4 connected by Ethernet from its internal port to the router.

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether [my Ethernet MAC address] brd ff:ff:ff:ff:ff:ff
inet 10.120.1.73/24 brd 10.120.1.255 scope global dynamic noprefixroute
eth0
valid_lft 68116sec preferred_lft 57316sec
inet6 fe80::9d12:c3f2:a133:43e/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
qlen 1000
link/ether [my wifi MAC address] brd ff:ff:ff:ff:ff:ff


The important section is the "eth0" section. Note that my router is
configured (for obscure reasons) to hand out addresses 10.120.1.x which is
another private address range like 192.168.x.y and 172.a.b.c.

[Marco Moock]

Am Samstag, 08. Januar 2022, um 20:55:50 Uhr schrieb NY:

> "Marco Moock" <mo...@posteo.de> wrote in message
> news:20220108183111.318f397f@ryz...
> > Am Samstag, 08. Januar 2022, um 14:52:07 Uhr schrieb NY:
> >
> >> "Marco Moock" <mo...@posteo.de> wrote in message
> >
> >> There is the possibility that Wireshark run on *another* computer
> >> may not see much of the DHCP conversation because the network
> >> switch in the router may filter out traffic that is not from/to
> >> the computer that is running Wireshark. However I think that the
> >> initial DHCP broadcast or multicast from the Pi should should up.
> >
> > No, the DHCPv4 discovery message from the Pi is being sent to the
> > broadcast MAC address (FF:FF:FF:FF:FF:FF). Every switch has to sent
> > out that frame on every port except the port it came from.
>
> Yes I imagine the first part of the DHCP conversation is at broadcast
> level. I couldn't remember how far through the process it stayed at
> broadcast level before becoming a point-to-point conversation. Though
> thinking about it, the client (the Pi) doesn't *know* what its IP
> address is until the end of the conversation when the DHCP server has
> said "yes, you really *can* use the address that I proposed earlier
> in the conversation".

The DHCPCPv4 offer could already be an Ethernet unicast frame because
the DHCPv4 server know the MAC address of the DHCPv4 client. The DHCPv4
request can also be a unicast frame because the client knows the MAC
address from the server.

> I wasn't sure what IP address "ip a" would report if a computer was
> statically configured to use an IP address that happened to clash
> with one being used by another computer (whether that second computer
> got its IP statically or by DHCP). In other words, if "ip a" is
> reporting a 169.a.b.c address, does that imply that the Pi is
> configured to use DHCP, or could it alternatively mean that it is
> configured statically but there is an IP clash.

ip a just shows what addresses are assigned to an interface - not how
they were assigned.
There is the IPv4 link-local range 169.254.0.0/16. This is normally
being used if DHCPv4 is enabled, but no DHCP server responds.
You can set them manually, but you shouldn't according to RFC3927.
IIRC, they are only assigned if DHCPv4 fails and not if an address
conflict exists.

> I'm still puzzled by why he has had the problem on more than one Pi
> and why he's using an external USB-Ethernet adaptor rather than the
> built-in Ethernet port: I bet one or other of those is at the root of
> why he's having problems getting DHCP to work.

The only possibility to find that out is sniffing all the traffic
between Pi and the DHCP server. The MAC address/client identifier might
be the issue.

> Suppose the 169 address relates to the built-in adaptor and not the
> external one. Suppose the external one isn't even listed because it's
> not working due to a lack of drivers.
>
> "ip a" should reveal all...

True, because ip a shows interfaces that are usable. Some that don't
have a working driver are not shown.

>
> The important section is the "eth0" section. Note that my router is
> configured (for obscure reasons) to hand out addresses 10.120.1.x
> which is another private address range like 192.168.x.y and
> 172.a.b.c.

172.0.0.0/8 isn't completely a private IPv4 network.
172.16.0.0/12 is the private range of that network.

See https://datatracker.ietf.org/doc/html/rfc1918 and
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml

[Jan Panteltje]

On a sunny day (Fri, 7 Jan 2022 11:18:57 -0800 (PST)) it happened Patrick
Zacharczyp <patrick.z...@bccaschools.org> wrote in
<7ea4f333-833b-4a2f...@googlegroups.com>:

* If you have a static IP, do not forget to add the gateway *

1)
find the IP address of your router

2)
tyoe
ifconfig
to see the Pi PI address
make sure router and Pi have the same base address, say for example
192.168.178.XXXX

3)
try to ping the router from the Pi
ping ROUTER_IP_ADDRESS (for example 192.168.178.1)
if you get a ping reply type
route
that should show something like this:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default router 0.0.0.0 UG 202 0 0 eth0
192.168.178.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0

If it does not show anything like that add the route to the gateway by typing
route add default gw ROUTER_IP_ADDRESS

If you cannot ping the router check the cables and addresses again

4)
ping 8.8.8.8
to test google nameserver for net connection

So this is for a static IP, see other replies for dynamic.

[The Natural Philosopher]

On 08/01/2022 20:55, NY wrote:
> "Marco Moock" <mo...@posteo.de> wrote in message
> news:20220108183111.318f397f@ryz...
>> Am Samstag, 08. Januar 2022, um 14:52:07 Uhr schrieb NY:
>>
>>> "Marco Moock" <mo...@posteo.de> wrote in message
>>
>>> There is the possibility that Wireshark run on *another* computer may
>>> not see much of the DHCP conversation because the network switch in
>>> the router may filter out traffic that is not from/to the computer
>>> that is running Wireshark. However I think that the initial DHCP
>>> broadcast or multicast from the Pi should should up.
>>
>> No, the DHCPv4 discovery message from the Pi is being sent to the
>> broadcast MAC address (FF:FF:FF:FF:FF:FF). Every switch has to sent out
>> that frame on every port except the port it came from.
>
> Yes I imagine the first part of the DHCP conversation is at broadcast
> level. I couldn't remember how far through the process it stayed at
> broadcast level before becoming a point-to-point conversation. Though
> thinking about it, the client (the Pi) doesn't *know* what its IP
> address is until the end of the conversation when the DHCP server has
> said "yes, you really *can* use the address that I proposed earlier in
> the conversation".

Pi does an all stations broadcast 'I am on this ETHERNET address if
there is a DHCP server out there, please tell me who I am (sounds of
supertramp)

After that its all done by ethernet address and on a switch you wont see
any of that unless you set up tcpdump on the Pi.

Which is not a bad way to go actually.

> I wasn't sure what IP address "ip a" would report if a computer was
> statically configured to use an IP address that happened to clash with
> one being used by another computer (whether that second computer got its
> IP statically or by DHCP). In other words, if "ip a" is reporting a
> 169.a.b.c address, does that imply that the Pi is configured to use
> DHCP, or could it alternatively mean that it is configured statically
> but there is an IP clash.

Neither. it tells you nothing. Except that the interface is configured
to an address.

Ther is almost nothing in the IP protocol to prevent two interfaces
being on the same IP address,

>
> I'm still puzzled by why he has had the problem on more than one Pi and
> why he's using an external USB-Ethernet adaptor rather than the built-in
> Ethernet port: I bet one or other of those is at the root of why he's
> having problems getting DHCP to work.

Indeed. The auto DHCP will work for the primary ethernet adapter. No
idea how you adjust it for a second port



--
"Women actually are capable of being far more than the feminists will
let them."

[The Natural Philosopher]

On 09/01/2022 08:42, Marco Moock wrote:
> The DHCPCPv4 offer could already be an Ethernet unicast frame because
> the DHCPv4 server know the MAC address of the DHCPv4 client. The DHCPv4
> request can also be a unicast frame because the client knows the MAC
> address from the server.

The first message MUST be a broadcast since neither end knows the
(MAC/Ethernet) location of the other.

I actually spend some time tracing an issue with DHCP, and the best
place to out the tracer is on the machine requesting the address. It
sees one side of the conversation at least...


--
"What do you think about Gay Marriage?"
"I don't."
"Don't what?"
"Think about Gay Marriage."

[NY]

"The Natural Philosopher" <t...@invalid.invalid> wrote in message
news:sretjk$f6g$1...@dont-email.me...

> On 09/01/2022 08:42, Marco Moock wrote:
>> The DHCPCPv4 offer could already be an Ethernet unicast frame because
>> the DHCPv4 server know the MAC address of the DHCPv4 client. The DHCPv4
>> request can also be a unicast frame because the client knows the MAC
>> address from the server.
>
> The first message MUST be a broadcast since neither end knows the
> (MAC/Ethernet) location of the other.
>
> I actually spend some time tracing an issue with DHCP, and the best place
> to out the tracer is on the machine requesting the address. It sees one
> side of the conversation at least...

I agree. Switches and other devices that filter traffic are great for
reducing the amount of traffic on a particular LAN segment, leaving more
capacity for traffic between computers on that segment or for external
traffic to/from one of those computers. But.. they are a PITA when you try
to look for network traffic on a computer that is not party to the
conversation.

I learned network tracing on a "Sniffer" - a mains-powered laptop with
dedicated OS and network capture/protocol-decoding. It was used on Thin and
Thick Ethernet which had no network switches and all traffic on one length
of cable that was terminated at both ends was visible. The Sniffer could see
traffic between Computer 1 and Computer 2 (and any responses to multicasts
and broadcasts from any other computers).

Nowadays you have separate Cat 5/6/7 cable to connect every computer to the
switch, and maybe several cascades of switches. A computer on one LAN cable
can only see traffic to/from that computer, that the switch has learned is
connected to the LAN cable. All point-to-point traffic for other computers
is filtered out. Unless you can put the *switch* (in addition to the
Wireshark computer's NIC) into promiscuous mode.

I've even found that a Wireshark PC that is connected to a LAN by wifi
doesn't always see point-to-point traffic for other computers that connect
by wifi. I'm not sure I understand why not: I thought that wifi was a "LAN
segment" that was common to all computers that were connected by it.



[digresssion]
I have a problem that I haven't managed to diagnose yet with Wireshark. Some
Android and iPad devices are unable to access a specific web site (which
hosts data for my weather station). All other devices (Windows, Linux) can
do fine. And every few weeks, my Android phone can access the site fine for
several days, and then stops: once again I get a "timed out" type of
message. But it only affects an internet connection by my VDSL connection;
if I switch the phone to use my Vodafone mobile internet, everything is
fine.

I'd like to monitor the HTTP conversation between phone and external web
server using Wireshark, but even with a Windows or Linux computer connected
by the same wifi as the Android device, I don't see HTTP traffic - even for
web sites that do work. I did try installing Wireshark-like packet-capturing
software (which used a proxy) on the Android computer that was having
problems, but I found that that was very unreliable even for known-good
traffic, missing most of it.

I did briefly manage to get a Linux computer to experience the problem, so I
was able to run Wireshark on that computer and see the traffic - which
wasn't what I expected. I expected to see the Linux computer do a DNS
resolve on the external address, then an HTTP GET request, and for there to
be no response. But even a newly-rebooted computer showed no DNS resolve or
HTTP GET request, so it was falling at a much earlier hurdle than I was
expecting. (In contrast, accessing any other site showed the DNS and HTTP
traffic that I was expecting.)
[/digression]

[meff]

On 2022-01-09, NY <m...@privacy.invalid> wrote:
> [digresssion]
> I have a problem that I haven't managed to diagnose yet with Wireshark. Some
> Android and iPad devices are unable to access a specific web site (which
> hosts data for my weather station). All other devices (Windows, Linux) can
> do fine. And every few weeks, my Android phone can access the site fine for
> several days, and then stops: once again I get a "timed out" type of
> message. But it only affects an internet connection by my VDSL connection;
> if I switch the phone to use my Vodafone mobile internet, everything is
> fine.

> ...
> [/digression]

It sounds like your Android and iPad can't seem to find a route to
your weather website. You might want to run `mtr` or some other
traceroute tool, then look at what's going on with the packet. Also
take a look at your route tables.

[Richard Falken]

Re: Re: Raspberry Pi 4's IP Address 169...
By: NY to The Natural Philosopher on Sun Jan 09 2022 09:01 pm

> I have a problem that I haven't managed to diagnose yet with Wireshark. Some
> Android and iPad devices are unable to access a specific web site (which
> hosts data for my weather station). All other devices (Windows, Linux) can
> do fine. And every few weeks, my Android phone can access the site fine for
> several days, and then stops: once again I get a "timed out" type of
> message. But it only affects an internet connection by my VDSL connection;
> if I switch the phone to use my Vodafone mobile internet, everything is
> fine.
>
> I'd like to monitor the HTTP conversation between phone and external web
> server using Wireshark, but even with a Windows or Linux computer connected
> by the same wifi as the Android device, I don't see HTTP traffic - even for
> web sites that do work. I did try installing Wireshark-like packet-capturing
> software (which used a proxy) on the Android computer that was having
> problems, but I found that that was very unreliable even for known-good
> traffic, missing most of it.
>

I'd use arp spoofing. You can use arp spoofing to trick the android device into
thinking another computer is the network's gateway (ie. router). Then the
ANdroid system will willingly serve you all the traffic as if you were the
router. It is easy enough to forward the traffic to its final destination and
become a transparent proxy of sorts.

At this point you may use Wireshark, tcpdump, mitm-proxy or any other analysis
tool.

If you use arpspoofing, make sure the phone is not using ipv6 connectivity,
since ipv6 connectivity disregards the arp protocol.

Tons of tutorials online for this.

--
gopher://gopher.richardfalken.com/1/richardfalken

[druck]

On 08/01/2022 12:02, Marco Moock wrote:
> Am Freitag, 07. Januar 2022, um 11:18:57 Uhr schrieb Patrick Zacharczyp:
>
>> My Raspberry Pi 4 that I got recently has a 169.XX. IP address and I
>> am trying to get it connected to the internet and install something.
>> This happened to my other Raspberry Pi. Could someone help me? I
>> tried doing some things in my router and I even used a command to add
>> a static IP. I used a USB 3.0 to ethernet adaptor w/ my last Pi, and
>> it worked, but it couldn't update. Someone please help as I spent a
>> lot of money on this.
>
> Please post the output of
> ip a

From that you'll see the name of the Ethernet adaptor, the built in one
is usually eth0

> Use a network Sniffer like Wireshark (maybe on another computer) and
> sniff for DHCPv4 packages. Check if the Pi sends out a DHCP Discovery.

A bit easier than that would be to do a manual DHCP discovery and see
what output you get, with:-

dhclient -v eth0

---druck

[Brian Gregory]

On 09/01/2022 21:01, NY wrote:
> I agree. Switches and other devices that filter traffic are great for
> reducing the amount of traffic on a particular LAN segment, leaving more
> capacity for traffic between computers on that segment or for external
> traffic to/from one of those computers. But.. they are a PITA when you
> try to look for network traffic on a computer that is not party to the
> conversation.

Surely the old Broadcast type Ethernet is totally obsolete now?
Nowadays no wired connection carries traffic intended only for other
devices on the network.
I don't think anyone even sells hubs now, they're all switches.

Nowadays it's up to you to use an arp poisoning type of thing or a
managed switch where you can set one port to monitor certain traffic.--
Brian Gregory (in England).

[The Natural Philosopher]

On 10/01/2022 12:48, Brian Gregory wrote:
> On 09/01/2022 21:01, NY wrote:
>> I agree. Switches and other devices that filter traffic are great for
>> reducing the amount of traffic on a particular LAN segment, leaving
>> more capacity for traffic between computers on that segment or for
>> external traffic to/from one of those computers. But.. they are a PITA
>> when you try to look for network traffic on a computer that is not
>> party to the conversation.
>
> Surely the old Broadcast type Ethernet is totally obsolete now?

Thetr is no such thing as 'old Broadcast type Ethernet'

There is Ethernet tha'ts all

> Nowadays no wired connection carries traffic intended only for other
> devices on the network.

That is a function of the ethernet switch, not the protocol. Ethernet
can still operate in a shared communication space.

> I don't think anyone even sells hubs now, they're all switches.
>

That is true, but you can still run Ethernet over coax if you want :-[)

> Nowadays it's up to you to use an arp poisoning type of thing or a
> managed switch where you can set one port to monitor certain traffic.--
> Brian Gregory (in England).

All very well if you are an IT pro with all the knowledge and the kit

For mere beginners, you simply run your sniffer on one end of the actual
conversation - in this case the Pi.



--
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

[Brian Gregory]

On 10/01/2022 15:02, The Natural Philosopher wrote:
> On 10/01/2022 12:48, Brian Gregory wrote:
>> Surely the old Broadcast type Ethernet is totally obsolete now?
>
> Thetr is no such thing as 'old Broadcast type Ethernet'
>
> There is Ethernet tha'ts all

a) Surely you can see there are differences in the way the old daisy
chained coax Ethernet (or twisted pair Ethernet with a hub rather than
a switch) use bandwidth compared with modern twisted pair with a switch
Ethernet?

b) I wasn't replying to you so STFU.

--
Brian Gregory (in England).

[NY]

"Brian Gregory" <void-invalid...@email.invalid> wrote in message
news:j440tn...@mid.individual.net...

> On 10/01/2022 15:02, The Natural Philosopher wrote:
>> On 10/01/2022 12:48, Brian Gregory wrote:
>>> Surely the old Broadcast type Ethernet is totally obsolete now?
>>
>> Thetr is no such thing as 'old Broadcast type Ethernet'
>>
>> There is Ethernet tha'ts all
>
> a) Surely you can see there are differences in the way the old daisy
> chained coax Ethernet (or twisted pair Ethernet with a hub rather than a
> switch) use bandwidth compared with modern twisted pair with a switch
> Ethernet?

It's the same sort of protocols at the electrical level, in that all the
devices could try to talk at once and need a way of backing off and trying
again with *different* random delays to prevent everyone stopping and then
all retrying after the *same* delay which just perpetuates the problem. And
this is as opposed to token ring where a token signal is sent sequentially
from one device to the next and only the device that currently has the token
is allowed to talk - the equivalent of the "I've got the Conch" in "Lord of
the Flies".

I imagine that interfacing Thick Ethernet to Thin Ethernet to modern UTP
star networking is easier than interfacing any of these to a token ring.

Is a Thick/Thin Ethernet bus logically similar to UTP if all devices are
connected by hubs that do no traffic filtering?


I remember the "joys" of Thin Ethernet, with coax cable, BNC connectors and
terminators. It was fine until you wanted to add an additional computer and
therefore an additional T piece. And sometimes even unplugging a T piece
from a network card (while still preserving the continuity and termination
of the LAN cable) could cause problems: some cards were notorious for
causing electrical glitches unless you powered-off the computer that you
were (dis)connecting which is a right PITA. UTP uses a hell of a lot more
cable, but it is a lot more resilient to computers being added/removed from
the LAN.



Anyway, have we got any more info from the OP to help us sort out his 169
problem? I've not seen any.

[The Natural Philosopher]

On 11/01/2022 13:14, NY wrote:
> "Brian Gregory" <void-invalid...@email.invalid> wrote in
> message news:j440tn...@mid.individual.net...
>> On 10/01/2022 15:02, The Natural Philosopher wrote:
>>> On 10/01/2022 12:48, Brian Gregory wrote:
>>>> Surely the old Broadcast type Ethernet is totally obsolete now?
>>>
>>> Thetr is no such thing as 'old Broadcast type Ethernet'
>>>
>>> There is Ethernet tha'ts all
>>
>> a) Surely you can see there are differences in the way the old daisy
>> chained coax Ethernet (or twisted pair  Ethernet with a hub rather
>> than a switch) use bandwidth compared with modern twisted pair with a
>> switch Ethernet?
>
> It's the same sort of protocols at the electrical level, in that all the
> devices could try to talk at once and need a way of backing off and
> trying again with *different* random delays to prevent everyone stopping
> and then all retrying after the *same* delay which just perpetuates the
> problem. And this is as opposed to token ring where a token signal is
> sent sequentially from one device to the next and only the device that
> currently has the token is allowed to talk - the equivalent of the "I've
> got the Conch" in "Lord of the Flies".
>
> I imagine that interfacing Thick Ethernet to Thin Ethernet to modern UTP
> star networking is easier than interfacing any of these to a token ring.
>
> Is a Thick/Thin Ethernet bus logically similar to UTP if all devices are
> connected by hubs that do no traffic filtering?
>

Yes. Up to a point. CAT5 separates transmit and receive stuff, unlike
co-ax so there is slightly less chance of a collision.

There used to be Ethernet CAT5 hubs, but I cant fund any for sale now.
They would be handy for debugging.
Promiscuous mode is available on some high end switches, but not
consumer grade junk

>
>
> Anyway, have we got any more info from the OP to help us sort out his
> 169 problem? I've not seen any.

I think the answer is that his Pi is trying to attach an address to his
internal interface, failing and adding a default one to his ethernet dongle.
Because he has tried to 'so something different' At that point defaults
no longer work..




--
“But what a weak barrier is truth when it stands in the way of an
hypothesis!”

Mary Wollstonecraft

[David Higton]

In message <srjvr3$cfb$1...@dont-email.me>

"NY" <m...@privacy.invalid> wrote:

>"Brian Gregory" <void-invalid...@email.invalid> wrote in message
>>

Many years ago, where I worked, the LAN was originally on coax. One of
the little projects I had was to get a PC to channelise a multiplexed
data stream of large proportions, so performance was paramount. One
day I found that removing the coax from the back of the PC allowed it
to process in about two thirds of the time. It astonished me to see
how much time was wasted dealing in network traffic that wasn't meant
for my PC.

It's much better to have the network switches filter out all that
unwanted stuff.

David

[Marco Moock]

Am Sonntag, 09. Januar 2022, um 21:01:33 Uhr schrieb NY:

> I've even found that a Wireshark PC that is connected to a LAN by
> wifi doesn't always see point-to-point traffic for other computers
> that connect by wifi. I'm not sure I understand why not: I thought
> that wifi was a "LAN segment" that was common to all computers that
> were connected by it.

What about the encryption?
Maybe that is the reason for that, but I don't know much about it. With
Open-System you should be able to see all the traffic.

[Marco Moock]

Am Sonntag, 09. Januar 2022, um 20:59:42 Uhr schrieb Richard Falken:

> I'd use arp spoofing. You can use arp spoofing to trick the android
> device into thinking another computer is the network's gateway (ie.
> router). Then the ANdroid system will willingly serve you all the
> traffic as if you were the router. It is easy enough to forward the
> traffic to its final destination and become a transparent proxy of
> sorts.

That works only for traffic that needs to be routed.

> At this point you may use Wireshark, tcpdump, mitm-proxy or any other
> analysis tool.
>
> If you use arpspoofing, make sure the phone is not using ipv6
> connectivity, since ipv6 connectivity disregards the arp protocol.

True, because IPv6 uses the neighbor discovery protocol with neighbor
solicitations and neighbor advertisements.
That is the counterpart for IPv4's ARP.

It has the same "problems" - it can also be spoofed.

[Marco Moock]

Am Dienstag, 11. Januar 2022, um 13:14:10 Uhr schrieb NY:

> I imagine that interfacing Thick Ethernet to Thin Ethernet to modern
> UTP star networking is easier than interfacing any of these to a
> token ring.

It is possible, there are media converters for AUI to 10Base2 and for
AUI to 10BaseT. There are also hubs that support all 3 types.

> Is a Thick/Thin Ethernet bus logically similar to UTP if all devices
> are connected by hubs that do no traffic filtering?

Yes, it is. All computers receive all data and only half duplex is
allowed.

> I remember the "joys" of Thin Ethernet, with coax cable, BNC
> connectors and terminators. It was fine until you wanted to add an
> additional computer and therefore an additional T piece. And
> sometimes even unplugging a T piece from a network card (while still
> preserving the continuity and termination of the LAN cable) could
> cause problems: some cards were notorious for causing electrical
> glitches unless you powered-off the computer that you were
> (dis)connecting which is a right PITA. UTP uses a hell of a lot more
> cable, but it is a lot more resilient to computers being
> added/removed from the LAN.

10Base5 is more stable than 10Base2, because the bus itself is not
changed when connecting a vampire tap. There is a reason why 10Base2 is
called Cheapernet. :-)

[Marco Moock]

Am Dienstag, 11. Januar 2022, um 14:20:13 Uhr schrieb The Natural
Philosopher:

> Yes. Up to a point. CAT5 separates transmit and receive stuff, unlike
> co-ax so there is slightly less chance of a collision.

IIRC the collision detection checks the RX pair when in half duplex
mode, so the change of a collision doesn't decreases.

[Marco Moock]

Am Sonntag, 09. Januar 2022, um 15:00:57 Uhr schrieb The Natural
Philosopher:

> Indeed. The auto DHCP will work for the primary ethernet adapter. No
> idea how you adjust it for a second port

If you use /etc/network/interfaces you need to create a separate entry
for the new interface.
You need to know its name (ip a tells you) and the set it up like the
other interface, just replace the name (e.g. eth1 instead of eth0).

[Ahem A Rivet's Shot]

On Tue, 11 Jan 2022 17:40:06 GMT
David Higton <da...@davehigton.me.uk> wrote:

> It's much better to have the network switches filter out all that
> unwanted stuff.

Also you can pass a *lot* more data around the network with
switches - the effective bandwidth of switch fabric is enormous.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

[Tauno Voipio]

On 11.1.22 16.20, The Natural Philosopher wrote:

>> Is a Thick/Thin Ethernet bus logically similar to UTP if all devices
>> are connected by hubs that do no traffic filtering?
>>
>
> Yes. Up to a point. CAT5 separates transmit and receive stuff, unlike
> co-ax so there is slightly less chance of a collision.
>
> There used to be Ethernet CAT5 hubs, but I cant fund any for sale now.
> They would be handy for debugging.
> Promiscuous mode is available on some high end switches, but not
> consumer grade junk

There are inexpensive managed switches (around 40 EUR), e.g.
Zyxel GS1200 series. They have a feature called 'monitor port'
which allows assigning one of the switch ports to listen for
traffic on selected other ports.

A good hint for the managed features is that the switch is
specified 'VLAN compatible'.

--

-TV

[NY]

"Marco Moock" <mo...@posteo.de> wrote in message

news:20220111192232.5b62a4f2@ryz...

That takes me back: vampire taps (which could only be inserted at marked
places along the coax, presumably where nulls/maxima were); large
transceiver attached to vampire tap; very thick drop cable with sliding
locks on D connectors at each end, between transceiver and computer's
network card. Moving a LAN cable or a drop cable was a bit was like
wrestling a snake ;-) And that was as recent as 1990.

Even the transition from cylindrical Cat 5+ to flat Cat 5+ cable was quite
revolutionary when it came out a few years ago. Now it was possible to fit a
cable underneath a carpet (ideally close to the edge, between the
gripper-rod and the edge of the carpet) rather than having to tuck it down
the gap between carpet and skirting board. Also possible to lay it
underneath the metal strip between one carpet and another in a doorway. For
the first time it was possible to run several Cat 5+ cables side by side,
when the gap between carpet and skirting board would only fit one
cylindrical cable.

Thank goodness that modern Ethernet ports are auto-sensing and (AFAIK) all
cables are straight through. No more being caught out by devices which did
or didn't want a crossover cable.

[The Natural Philosopher]

....and the two cat 5 wiring standards have become essentially one...

What is impressive, is that the Ethernet standard has kept pace with all
this to gigabit and possibly beyond





--
There’s a mighty big difference between good, sound reasons and reasons
that sound good.

Burton Hillis (William Vaughn, American columnist)

[Ahem A Rivet's Shot]

On Wed, 12 Jan 2022 12:16:53 +0000
The Natural Philosopher <t...@invalid.invalid> wrote:

> What is impressive, is that the Ethernet standard has kept pace with all
> this to gigabit and possibly beyond

Well beyond, there are standards for 10, 40, 100 and 400 gigabit
over fibre also 10 and 40 gigabit over twisted pair(s), cat 8 for 40
gigabit so no reusing the old cat 5 wiring but still impressive. There's
work in progress on 800 gigabit and 1.6 terabit standards.

It seems Moore has moved his law to network bandwidth after getting
bored with processor speeds.

[The Natural Philosopher]

On 12/01/2022 14:11, Ahem A Rivet's Shot wrote:
> On Wed, 12 Jan 2022 12:16:53 +0000
> The Natural Philosopher <t...@invalid.invalid> wrote:
>
>> What is impressive, is that the Ethernet standard has kept pace with all
>> this to gigabit and possibly beyond
>
> Well beyond, there are standards for 10, 40, 100 and 400 gigabit
> over fibre also 10 and 40 gigabit over twisted pair(s), cat 8 for 40
> gigabit so no reusing the old cat 5 wiring but still impressive. There's
> work in progress on 800 gigabit and 1.6 terabit standards.
>
> It seems Moore has moved his law to network bandwidth after getting
> bored with processor speeds.
>

:0-)

Yup.
I was pondering the first modem I saw around 1972. 50 baud and an
acoustic coupler.
By 1982 ir was 300 baud
By 1992 we were happy at 9600...
at 2002 I had migrated via 64k ISDN to ADSL 256bps fixed rate.
by 2012 I was ion ADSL 2 at 6Mbps
By 2022 I am on 40Mbps on fibre.

I am still on 100Mbps ethernet, internally because for my little home
setup its 'fast enough' and the 20 year old cable run its reliably


--
“It is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

[Michael J. Mahon]

Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Wed, 12 Jan 2022 12:16:53 +0000
> The Natural Philosopher <t...@invalid.invalid> wrote:
>
>> What is impressive, is that the Ethernet standard has kept pace with all
>> this to gigabit and possibly beyond
>
> Well beyond, there are standards for 10, 40, 100 and 400 gigabit
> over fibre also 10 and 40 gigabit over twisted pair(s), cat 8 for 40
> gigabit so no reusing the old cat 5 wiring but still impressive. There's
> work in progress on 800 gigabit and 1.6 terabit standards.
>
> It seems Moore has moved his law to network bandwidth after getting
> bored with processor speeds.

Hear, hear—and thus it has been for decades!

At a presentation in the 1990s, after diagramming the progress of Moore’s
“Law”, an attendee remarked that “it was a shame that there was no
equivalent law for fibre bandwidth.”

My answer was that there was an exponential increase in bandwidth, even
over existing fibre, since the transmitting and receiving technology was
driving it.

It is remarkable when any technology standard has a useful life over a
decade, and the Ethernet family has proven very adaptable and resilient.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[Ahem A Rivet's Shot]

On Wed, 12 Jan 2022 18:12:18 +0000
The Natural Philosopher <t...@invalid.invalid> wrote:

> Yup.
> I was pondering the first modem I saw around 1972. 50 baud and an
> acoustic coupler.

I'm pretty sure the first one I saw in 1975 was 300 baud on an
acoustic coupler - it could keep up with an ASR-33 reader/punch.

> By 1982 ir was 300 baud
> By 1992 we were happy at 9600...

About that time 14,400 came in, then 28.8, 33.6 quite rapidly and
then the asymmetric standards with a digital signal on one end and a modem
on the other (V90, V92).

> at 2002 I had migrated via 64k ISDN to ADSL 256bps fixed rate.
> by 2012 I was ion ADSL 2 at 6Mbps

I went from ISDN to 6Mb/s fixed wireless DOCSIS in this period.

Then 70Mb/s LTE around 2016 before landing on my current gigabit
FTTP.

> I am still on 100Mbps ethernet, internally because for my little home
> setup its 'fast enough' and the 20 year old cable run its reliably

I wired this place eight years ago, so it got CAT-6 and a cheap 24
port managed gigabit switch, there's a fighting chance I might get 10
gigabit to run if I feel like spending money madly - there's no point.

[alister]

the term you are looking for is port mirroring, & can be configured on a
managed switch. unfortunately not possible on consumer grade switches as
they are invariably unmanned

--
The memory management in Windows 95 can be used to frighten small
children.

[druck]

On 12/01/2022 18:12, The Natural Philosopher wrote:
> I am still on 100Mbps ethernet, internally because for my little home
> setup its 'fast enough' and the 20 year old cable run its reliably

There's no such thing as fast enough when it comes to networking!

If it's CAT5e you should be able to run gigabit over it without problems.

CAT5 which is fine for 100MB may light up the gigabit LED on a switch,
but the throughput maybe terrible if the cables aren't up to it, or have
been kinked during installation.

---druck

[NY]

"Michael J. Mahon" <mjm...@aol.com> wrote in message
news:FJCdnQrHNq0oqUL8...@giganews.com...

I suppose with network bandwidth we are close to reaching the limit of the
rate at which *one computer* can send or receive over a network - because of
current limitations in other parts of a computer: CPU, bus, HDD/SSD. But we
now have communications which can carry *many* such conversations from many
different computers all talking at the same time.

I can see the difference that network communications makes when I changed
from a Pi 3B+ to a Pi4. The Pi 3 has a gigabit Ethernet port which is
throttled by the fact that it is connected to the CPU by USB. With an
external USB-connected HDD shared using Samba, a Windows computer can copy
large 1 GB (*) files to/from the Pi's share at about 130 Mbps maximum. The
Pi 4, with the same setup, can manage about 800 Mbps, so not far short of
the 1 Gbps limit. Of course some of that increase may be due to the Pi 4
having USB3 rather than just USB2, though even USB2 is 400 Mbps.

Then we have wifi. My old router was wireless N on 2.4 GHz. I was lucky to
get anywhere *near* that speed; usually a large file transferred at under
100 Mbps - when the wifi LAN was otherwise unused, and with the Pi still
connected by Ethernet and only the Windows computer over wifi. The I got a
new mesh network (Linksys Velop) which can use either 2.4 or 5 GHz, and the
backhaul between one mesh node and another is by a *second* 5 GHz network,
ie not the one that computers connect to. With the Windows computer on a
remote node which connects to a primary node which is connected by Ethernet,
I get very variable speed, but at best about 600 Mbps.


It is getting to the stage where a large video file can be accessed (eg when
scrolling quickly through it or moving from one part of the file to another
(**)) across an Ethernet or wifi network almost as quickly as if the file
was on a local disk connected by SATA. We're not there yet, but it won't be
long before it's difficult to tell.


(*) For example a recorded TV programme as a TS file - typically about 1.3
GB/hour when recorded from a BBC channel, a bit less for ITV.

(**) I use VideoReDo to edit the continuity announcements and commercials
from programmes I've recorded. I need to shuttle quickly through a file to
find each of the commercial breaks. Leaving aside the fact that SD
recordings (MPEG2) are a *lot* quicker to process than HD (H264) when
shuttling through, I can see a bit of difference between accessing a local
file and one on the Pi over Ethernet, and a significant difference if the
Windows computer uses wifi instead of Ethernet. But technology will improve,
I'm sure.

[NY]

"Ahem A Rivet's Shot" <ste...@eircom.net> wrote in message
news:20220112202158.5e39...@eircom.net...

>> Yup.
>> I was pondering the first modem I saw around 1972. 50 baud and an
>> acoustic coupler.
>
> I'm pretty sure the first one I saw in 1975 was 300 baud on an
> acoustic coupler - it could keep up with an ASR-33 reader/punch.

Yes I remember the old 300 baud acoustic coupler: a polished wooden box,
lined with green baize with mic/speaker "holes" which exactly matched the
handset of a standard GPO/BT telephone. That was the comms between the
teletype that we had at school and the mainframe computer that we accessed -
in the late 70s. The teletype was painfully slow, but sometimes we could see
it stall for a second if the comms couldn't keep up.

>> By 1982 ir was 300 baud
>> By 1992 we were happy at 9600...
>
> About that time 14,400 came in, then 28.8, 33.6 quite rapidly and
> then the asymmetric standards with a digital signal on one end and a modem
> on the other (V90, V92).

Yes I remember a friend had a standard 28.8 kbps modem for accessing the
internet by dialup. I bought my modem a bit later than him, and 33.6 became
possible. I think my modem was US Robotics. I've got a feeling that a PROM
upgrade became available that allowed it to work a little bit faster than
that, as long as the other end could use the correct protocol.


Then "broadband" started to be the word on everyone's lips. There was talk
of some large towns having their exchanges upgraded to support ADSL, but
those in villages needed to get more than a certain "trigger level" of firm
orders (via ISPs) before BT would even consider upgrading them. In the
meantime, a group of us on my housing estate investigated a long-range
microwave link to a mast on a nearby hill: companies were setting up in
business to supply fast internet this way for places that had not yet
reached their BT trigger.

Suddenly came the announcement we never thought we'd hear: BT were
abandoning the concept of trigger levels and were committing to add ADSL to
every exchange. I lived about 200 metres from my exchange so I knew that I'd
be able to get up to 8 Mbps. Initially ISPs (because of BT) were charging
various amounts depending on what speed you wanted - or could achieve due to
line length. I initially opted for 2 Mbps down and 448 k bps up, because 8
Mbps was a lot more expensive. But the price differential got smaller and
smaller, so I upgraded to 8 Mbps. Still only 448 kbps upload, though :-(

That situation lasted until "fibre". We got FTTC and managed about 15 Mbps
down and about 5 bps up. Not a huge increase in download speed, but a
tremendous increase in upload speed when FTPing files to a server.

At our present house we get about 25-35 down and about 8-10 up. The sync
speed fluctuates, taking roughly two weeks to go between one extreme and the
other. I'm sure if we had brand new wiring from where the drop cable
terminates at the old GPO lozenge box on the gable end, to the socket where
the router is plugged in, we'd get a slightly better speed. But it would be
a major job involving crawl boards on the roof to get at that socket and to
run new cable (with no junctions along the way) to the living room - and
it's difficult to know where the demarcation is between BT and owner
cabling. Maybe it's at the first BT socket rather than the GPO box.

It looks as if our village is being cabled up for FTTP, as part of BT's
phasing out of copper connections. That will cause some interesting problems
because the point where the BT cable comes into the house (and therefore
where they'd *probably* bring the fibre) has no mains socket near and no way
of running a mains cable without taking up a carpet (which means moving a
lot of furniture) to dig a channel in the concrete floor to run a spur from
the nearest socket on the ring main. And you *need* mains for the
fibre-to-Ethernet converter (I've forgotten what BT call it).

[The Natural Philosopher]

On 12/01/2022 18:30, Dennis Lee Bieber wrote:
> On Wed, 12 Jan 2022 14:11:31 +0000, Ahem A Rivet's Shot <ste...@eircom.net>
> declaimed the following:

>
>>
>> It seems Moore has moved his law to network bandwidth after getting
>> bored with processor speeds.
>

> Processor /speeds/ seem to have maxed out -- instead they are adding
> more and more parallel cores to the processor.
>
>
They cant shrink the gate size any more. That tends to be what limits speed.

And parallel cores are not the be all, for single thread performance.




--
Of what good are dead warriors? … Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory … The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.

[The Natural Philosopher]

On 12/01/2022 22:25, NY wrote:
> Then we have wifi. My old router was wireless N on 2.4 GHz. I was lucky
> to get anywhere *near* that speed; usually a large file transferred at
> under 100 Mbps

You do realise that 2.4GHz is the carrier centre frequency, not the data
rate.

Most wifi adapters wont do more than 50Mbps.

--
In theory, there is no difference between theory and practice.
In practice, there is.
-- Yogi Berra

[NY]

"The Natural Philosopher" <t...@invalid.invalid> wrote in message
news:sroqd7$g6k$1...@dont-email.me...

> On 12/01/2022 22:25, NY wrote:
>> Then we have wifi. My old router was wireless N on 2.4 GHz. I was lucky
>> to get anywhere *near* that speed; usually a large file transferred at
>> under 100 Mbps
>
> You do realise that 2.4GHz is the carrier centre frequency, not the data
> rate.

Yes, but I believe (and maybe I'm wrong) that the channels on 5 GHz are
wider and so allow a greater data rate. Also there is a greater chance that
the auto-channel-sensing logic in the router will be able to find a channel
that is free of interference from neighbouring routers and from other
sources of RFI,

> Most wifi adapters wont do more than 50Mbps.

Now that I didn't know. So maybe that explains why my old Win 7 laptop would
not go much above that speed even when I was close to the router on an
uninterfered-with channel with no other traffic on wifi. I thought the
built-in wifi adaptor was failing, but maybe it was never designed to go
much faster.

[The Natural Philosopher]

On 12/01/2022 20:21, Ahem A Rivet's Shot wrote:
> I wired this place eight years ago, so it got CAT-6 and a cheap 24
> port managed gigabit switch, there's a fighting chance I might get 10
> gigabit to run if I feel like spending money madly - there's no point.

I built this place 20 years ago with full structured cabling - cat 5.


--
WOKE is an acronym... Without Originality, Knowledge or Education.

[The Natural Philosopher]

On 12/01/2022 21:15, druck wrote:
> On 12/01/2022 18:12, The Natural Philosopher wrote:
>> I am still on 100Mbps ethernet, internally because for my little home
>> setup its 'fast enough' and the 20 year old cable run its reliably
>
> There's no such thing as fast enough when it comes to networking!

Ther is.

if for example your network is faster than the server disk I/O then
loading a file off that server wont get faster with extra network speed.

>
> If it's CAT5e you should be able to run gigabit over it without problems.
>
> CAT5 which is fine for 100MB may light up the gigabit LED on a switch,
> but the throughput maybe terrible if the cables aren't up to it, or have
> been kinked during installation.
>

I have yet to actually try gigabit over my wiring.


> ---druck

[The Natural Philosopher]

On 12/01/2022 23:28, NY wrote:
> about 5 bps up. Not a huge increase in download speed, but a tremendous

^^^^^^^^^^

> increase in upload speed when FTPing files to a server.

Really? :-)



--
Climate Change: Socialism wearing a lab coat.

[The Natural Philosopher]

https://en.wikipedia.org/wiki/IEEE_802.11

until 2008 or thereabout WiFi 3 was as good as it got - 802.11n took
that up to '72 to 600 Mbit/s ) and I am not sure I have ever seen
that...do more than 70Mbps.

IIRC a Pi only does 802.11n natively and 150 Mbps and that's half
duplex of course so will be less.

I think my Pi Zero W with is 5 feet away, through a wall from the wifi
router does around 20-50Mbps depending on random reflections etc...

That's all on 2.4Ghz.

I dont have any devices bar my router than run on 5Ghz.

But I do have lots of cat 5!

[NY]

"The Natural Philosopher" <t...@invalid.invalid> wrote in message
news:sros66$ov6$3...@dont-email.me...

> On 12/01/2022 23:28, NY wrote:
>> about 5 bps up. Not a huge increase in download speed, but a tremendous
> ^^^^^^^^^^
>> increase in upload speed when FTPing files to a server.
>
> Really? :-)

Yes, really. From 0.5 Mbps with ADSL (the maximum that my router every
synced) to 5 Mbps with VDSL. Made a very big improvement if I was sending
emails with large attachments, sending them over TeamViewer or FTPing them.

[Ahem A Rivet's Shot]

On Thu, 13 Jan 2022 09:42:30 +0000

The Natural Philosopher <t...@invalid.invalid> wrote:

> On 12/01/2022 23:28, NY wrote:
> > about 5 bps up. Not a huge increase in download speed, but a tremendous
> ^^^^^^^^^^
> > increase in upload speed when FTPing files to a server.
>
> Really? :-)

The day Linus released Linux 1.0 I (and untold numbers of others)
made the mistake of attempting to download it, contributing thereby to
DDOSing Finland! Before I abandoned the attempt I got to see a very rarely
triggered bug in my ftp program as it reported a download speed of "1 bytes
per second".

[NY]

"NY" <m...@privacy.invalid> wrote in message
news:sroun0$ajq$1...@dont-email.me...

Ah, I see what you were referring to: I did of course mean 5 Mbps, not 5 bps
;-)

[The Natural Philosopher]

Whoosh...
Look closely at what you wrote, young man...

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

[Ahem A Rivet's Shot]

On Thu, 13 Jan 2022 09:41:26 +0000

The Natural Philosopher <t...@invalid.invalid> wrote:

> if for example your network is faster than the server disk I/O then
> loading a file off that server wont get faster with extra network speed.

The nagging detail that my server disk I/O can be faster than the
two bonded gigabit cables can carry is what occasionally tempts me to
10gig, then I remember that it really doesn't matter and it's certainly not
worth spending *that* much on and besides if/when the beast dies (it's not
going to need upgrading) the replacement ex data centre box will almost
certainly come with 10gig on board and maybe there will be cheap switches by
then too.

[Axel Berger]

Ahem A Rivet's Shot wrote:

> I'm pretty sure the first one I saw in 1975 was 300 baud on an
> acoustic coupler - it could keep up with an ASR-33 reader/punch.

Fast enough before everything got silly. I tried it out. I can read text
at up to 300 baud and I can scan text, to find where to stop, at 1200
baud. Anything above that becomes a useless blur.


--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

[Ahem A Rivet's Shot]

On Thu, 13 Jan 2022 13:47:23 +0100
Axel Berger <Sp...@Berger-Odenthal.De> wrote:

> Ahem A Rivet's Shot wrote:
> > I'm pretty sure the first one I saw in 1975 was 300 baud on an
> > acoustic coupler - it could keep up with an ASR-33 reader/punch.
>
> Fast enough before everything got silly. I tried it out. I can read text

What silly like things that aren't text ?

Then again I used to think that sending a screenshot image instead
of typing a bit of text was the extreme of lazy bandwidth waste - until I
got sent a high definition video panning around a screen at close range from
which I was expected to glean two small pieces of essential text - needless
to say one was obscured by glare.

[The Natural Philosopher]

On 13/01/2022 18:39, Dennis Lee Bieber wrote:
> On Thu, 13 Jan 2022 09:36:56 -0000, "NY" <m...@privacy.invalid> declaimed the
> following:

>
>
>> Now that I didn't know. So maybe that explains why my old Win 7 laptop would
>> not go much above that speed even when I was close to the router on an
>> uninterfered-with channel with no other traffic on wifi. I thought the
>> built-in wifi adaptor was failing, but maybe it was never designed to go
>> much faster.
>

> Peruse https://en.wikipedia.org/wiki/IEEE_802.11#Protocol and modified
> by
> https://en.wikipedia.org/wiki/IEEE_802.11#Common_misunderstandings_about_achievable_throughput
>
>
> ]
Not bad, but with caeveats

They don't understand spread spectrum ...there is no such thing as
'channel width - what there is is adjacent channel crosstalk that
diminishes as the channels get 'less adjacent',

Spread spectrum is destined for high availability and freedom from
blocking by single frequencies in crowded spectrum space and when I was
working next door to its secret development, it was for battlefield radios.

It ended up in mobile phones, and then wifi.

The ideas is that you 'smear' the information over a large section of
spectrum, using a special secret code such that you cant kill the whole
signal with a strong carrier.

Some implementations use frequency hopping as well - so the center
channel frequency moves around again to throw off potential
interference. Wifi doesn't though.

Pretty sure that some wifi implentations use two widely spaced channels
to double the throughput


so each transmitter and receiver pair exchange data that is all over
half a dozen channels at varying strengths at the same time. So you only
get the signals belonging to you - everyone else's sound like noise.
Leastways that is how it worked for the military and I think GSM. Wifi
may in fact use one code per wifi point. And do the separation into wifi
devices using coding at the digital level


Needless to say data rate is as always governed by Shannon - so the more
other stuff is going on the slower the links will be.,





--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey

[meff]

On 2022-01-13, The Natural Philosopher <t...@invalid.invalid> wrote:
> Needless to say data rate is as always governed by Shannon - so the more
> other stuff is going on the slower the links will be.,

We are _far_ from information theoretic upper bounds on our links,
just FYI. Coding and frequency-division schemes for mobile networks
can also be a lot more complicated (like CDMA).

[The Natural Philosopher]

I dont think so at ALL.
examination of stuff like ADSL shows we are within a factor of two of
shannon limits


For a 22MHz wifi channel at say 30dB s/n, you are looking at around 660
Mbps shannon limit.

Its the same order of magnitude as the achievable maxima.





--
It is the folly of too many to mistake the echo of a London coffee-house
for the voice of the kingdom.

Jonathan Swift

[NY]

"The Natural Philosopher" <t...@invalid.invalid> wrote in message

news:srpupi$ols$1...@dont-email.me...

> They don't understand spread spectrum ...there is no such thing as
> 'channel width - what there is is adjacent channel crosstalk that
> diminishes as the channels get 'less adjacent',

I thought that wifi did have a defined bandwidth depending on the comms
speed (ie which 802.11 standard it supports). I've always understood that
channels 1, 6 and 11 are guaranteed not to overlap (at least for the earlier
standards) and therefore you get no further benefit from using channels
spaced more widely than 1, 6, 11, but that you get progressively more
degradation as you move the channels closer than 1, 6, 11.

> Spread spectrum is destined for high availability and freedom from
> blocking by single frequencies in crowded spectrum space and when I was
> working next door to its secret development, it was for battlefield
> radios.
>
> It ended up in mobile phones, and then wifi.
>
> The ideas is that you 'smear' the information over a large section of
> spectrum, using a special secret code such that you cant kill the whole
> signal with a strong carrier.

Sounds good. Which wireless standards support it, as an alternative to
channels that are spaced more closely than the bandwidth of any given comms
link (as you have with 2.4 GHz). Whenever I've run wifi spectrum analysis
software, it's always shown me specific channel number for each wifi network
that is in range, and the number of channels either side that each network
is using. Spread spectrum is completely different and as long as there are
holes at irregular places in the spectrum, a spread spectrum will use it.

[The Natural Philosopher]

On 13/01/2022 20:26, NY wrote:
> "The Natural Philosopher" <t...@invalid.invalid> wrote in message
> news:srpupi$ols$1...@dont-email.me...
>> They don't understand spread spectrum ...there is no such thing as
>> 'channel width - what there is is adjacent channel crosstalk that
>> diminishes as the channels get 'less adjacent',
>
> I thought that wifi did have a defined bandwidth depending on the comms
> speed (ie which 802.11 standard it supports). I've always understood
> that channels 1, 6 and 11 are guaranteed not to overlap (at least for
> the earlier standards) and therefore you get no further benefit from
> using channels spaced more widely than 1, 6, 11, but that you get
> progressively more degradation as you move the channels closer than 1,
> 6, 11.

Well 'guaranteed not to overlap' is ArtStudent talk for 'show < -60dB
adjacent channel crosstalk' and so on

Radio is intensely analogue. Spectra don't have sharp edges!

>
>> Spread spectrum is destined for high availability and freedom from
>> blocking by single frequencies in crowded spectrum space and when I
>> was working next door to its secret development, it was for
>> battlefield radios.
>>
>> It ended up in mobile phones, and then wifi.
>>
>> The ideas is that you 'smear' the information over a large section of
>> spectrum, using a special secret code such that you cant kill the
>> whole signal with a strong carrier.
>
> Sounds good. Which wireless standards support it, as an alternative to
> channels that are spaced more closely than the bandwidth of any given
> comms link (as you have with 2.4 GHz). Whenever I've run wifi spectrum
> analysis software, it's always shown me specific channel number for each
> wifi network that is in range, and the number of channels either side
> that each network is using. Spread spectrum is completely different and
> as long as there are holes at irregular places in the spectrum, a spread
> spectrum will use it.

No, wifi is spread spectrum. If you like its as if the frequency at any
given time is somewhere within 22Mhz of a given centre frequency, and is
constantly moving around, or you could say its heavily modulated by a
high frequency noise (a pseudorandom code) that its energy is spread
across several channels . Thats why you need to de convolute it with the
same pseudo random code in order to make sense of it.

The whole idea is to get away from any natural signals that might
'look' the same.

Oh heck, why have a dog and bark?

Here's a pretty decent write up

https://dsp.stackexchange.com/questions/2844/what-exactly-happens-with-spread-spectrum-modulation



--
Ideas are more powerful than guns. We would not let our enemies have
guns, why should we let them have ideas?

Josef Stalin

[Ahem A Rivet's Shot]

On Thu, 13 Jan 2022 20:26:05 -0000
"NY" <m...@privacy.invalid> wrote:

> Sounds good. Which wireless standards support it, as an alternative to

All the "wifi" and bluetooth standards are spread spectrum based.

> channels that are spaced more closely than the bandwidth of any given
> comms link (as you have with 2.4 GHz). Whenever I've run wifi spectrum
> analysis software, it's always shown me specific channel number for each

More detail than you probably want to know:

<http://webpages.eng.wayne.edu/~ad5781/ECECourses/ECE5620/Notes/Wi-Fi-Lecture.pdf>

> wifi network that is in range, and the number of channels either side
> that each network is using. Spread spectrum is completely different and
> as long as there are holes at irregular places in the spectrum, a spread
> spectrum will use it.

TL;DR Wifi and bluetooth are spread spectrum using many very narrow
channels spread around a fairly narrow space, this is why the effect of
crowding APs too closely is a slowdown rather than a stop.

[NY]

"The Natural Philosopher" <t...@invalid.invalid> wrote in message

news:srq2s5$mfh$1...@dont-email.me...

> Well 'guaranteed not to overlap' is ArtStudent talk for 'show < -60dB
> adjacent channel crosstalk' and so on

> Radio is intensely analogue. Spectra don't have sharp edges!

No, but there comes a point (eg your -60 dB) beyond which there is no
*discernable* difference in terms of speed, absence of glitches or however
you measure it. In common parlance that is "no overlapping".

That's why I described channels 1, 6 and 11 as non-overlapping, meaning data
rate of a comms link using one channel is not degraded if another link
starts up on a no-overlapping channel (or spaced more widely than that) and
that conversely if the second channel is closer than that limit, you get
progressively worse data rate or glitches as the two channels move closer
together in frequency.

In other words, taking the pragmatic engineering attitude rather than the
theoretical physical / mathematical approach of very wide bandwidth even if
the edges are so weak that they aren't distinguishable from noise.

> No, wifi is spread spectrum. If you like its as if the frequency at any
> given time is somewhere within 22Mhz of a given centre frequency, and is
> constantly moving around, or you could say its heavily modulated by a high
> frequency noise (a pseudorandom code) that its energy is spread across
> several channels . Thats why you need to de convolute it with the same
> pseudo random code in order to make sense of it.
>
> The whole idea is to get away from any natural signals that might 'look'
> the same.
>
> Oh heck, why have a dog and bark?
>
> Here's a pretty decent write up
>
> https://dsp.stackexchange.com/questions/2844/what-exactly-happens-with-spread-spectrum-modulation

I'll read that. Thanks.

I've heard of deliberately convoluting a signal in such a way that it looks
like noise, and then applying an inverse convolution at the other end. I
think one of the design criteria for DVB TV signals was that they had to
look like noise so they didn't produce noticeable patterning on analogue TVs
if there happened to be a bit of co-channel interference. Obviously that
requirement no longer applies now that analogue TV is no longer broadcast or
received. I have an old analogue-only TV which I;ve never got round throwing
away because it could still be used as a monitor or with an external DVB
decoder, and if I let that scan, I can see that the amount of "snow"
increases as it tunes across each of the multiplexes broadcast by the TV
transmitter. Weird to think that this snow is actually digital TV channels
;-)

[Axel Berger]

Dennis Lee Bieber wrote:
> But when you've got something like 6 neighbors all using "optimal"
> channels 1/6/11 -- you might be better off on channel 3/4 where you might
> not be getting channel usage congestion/collisions...

I always use channel 13 and I'm always the only one on it. With everyone
elso on "auto" even channel 11 is rarely used and if so it's usually
very weak. It seems they all begin on 1 and only move up when needed.

[The Natural Philosopher]

No, that's not how its done. At least not for original wifi. OFDM is
only used in later implementations..802.11a and g
DSSS is used on the rests.

Most routers support 802.11b,g and n. for 2,4Ghz
And 802.11a, an and ac on 5GHz

You should have read it. ADSL 'broad band' uses 'bins' like that. Wifi
spread spectrum used DSSS - it multiplies it (convolutes) by a very
high frequency pseudorandom code. What comes out is pseudorandom noise
across the whole two or three channels. You convolute that again with
the right code, and there is the wanted digital signal. Whereas any non
random single frequency noise in the channel becomes convoluted to noise.

Any other AP on nearby frequency will use a different code, so it will
just become 'noise' once convoluted and deconvoluted by the wrong code.

I was supposed to know this stuff, and I got as far as understanding the
principle, but the bloody maths was beyond me.

Frequency hopping is much slower than DSSS - Its an extra layer possibly
on top of DSSS used to shift from the centre of one channel to another.

It appears from your interesting PDF that bluetooth uses frequency
hopping on much narrower channels - 1MHz instead of 22MHz. Without using
DSSS

But the interesting thing about 2.4GHz is that the ONLY restrictions
legally placed on it are spectrum power and width. What you use within
it can be almost anything

[druck]

On 13/01/2022 09:41, The Natural Philosopher wrote:
> On 12/01/2022 21:15, druck wrote:
>> On 12/01/2022 18:12, The Natural Philosopher wrote:
>>> I am still on 100Mbps ethernet, internally because for my little home
>>> setup its 'fast enough' and the 20 year old cable run its reliably
>>
>> There's no such thing as fast enough when it comes to networking!
>
> Ther is.
>
> if for example your network is faster than the server disk I/O then
> loading a file off that server wont get faster with extra network speed.

That might be the case if you've got an old Raspberry Pi with a
knackered SD card acting as a file server, but a Pi 4B with a USB3
spinning rust drive does 100MB/s which is 8x faster than 100BaseT.
Another of my Pi 4Bs with a SATA3 SSD easily saturates the gigabit Ethernet.

---druck

[The Natural Philosopher]

On 13/01/2022 21:41, Dennis Lee Bieber wrote:
> On Thu, 13 Jan 2022 20:26:05 -0000, "NY" <m...@privacy.invalid> declaimed the
> following:
>

>> "The Natural Philosopher" <t...@invalid.invalid> wrote in message
>> news:srpupi$ols$1...@dont-email.me...
>>

>> I thought that wifi did have a defined bandwidth depending on the comms
>> speed (ie which 802.11 standard it supports). I've always understood that
>> channels 1, 6 and 11 are guaranteed not to overlap (at least for the earlier
>> standards) and therefore you get no further benefit from using channels
>> spaced more widely than 1, 6, 11, but that you get progressively more
>> degradation as you move the channels closer than 1, 6, 11.
>>

> But when you've got something like 6 neighbors all using "optimal"
> channels 1/6/11 -- you might be better off on channel 3/4 where you might
> not be getting channel usage congestion/collisions...
>
>
>

The whole 2.4Ghz things is a messy delight of fun. I fly model planes on
2.4Ghz and at least 4 modulation schemes are in place ...once at a model
plane show there was a 'fly your own' period and 50+ models were in the
air...well they didn't exactly interfere with each other, but the
normally very slow data rates slowed to the point where people were
losing control for a split second and seeing delays to command inputs.

Another funny story is that one particular very well known 'brand' of
transmitter went out with an individual code in its flash memory.
Essentially a MAC code. In use you press a button on the receiver and it
then 'pairs' with that MAC code...so different transmitters can coexist....


...until someone discovered that switching the transmitter on to check
the battery charge state and then immediately switching it off crashed
the NVRAM and erased the code...to zero. So all the transmitters ended
up with that code.


As far as wifi goes, even access points on the same channel will only
really be an issue if the receiver close to one trying to receive the
other. In DSSS the convolution code will sync with one or the other but
not both.

And I *think* that there is in general radio silence except when data is
being transferred. Or SSIDs being transmitted

Certainly when I ran my wifi scanner in a hospital last, there were
about 20 channels of varying strength on the three main channels, and it
all worked

But I hate wifi. Bloody unreliable. The spark igniter on my central
heating oil boiler reliably disconnects any wifi device in the house
within 20 feet of it.
My Pi-zero W maybe has 5ft reliable range through a wall, and the
worst wifi chip in the world

Oh dear. Its in the dining room and its managed to connect itself to
the living room, 6 meters away...7Mbps instead of the kitchen

Probably that one second power cut the other day..


wlan0 IEEE 802.11 ESSID:"LivingRoom"
Mode:Managed Frequency:2.432 GHz Access Point:
74:4D:28:4A:21:86
Bit Rate=7.2 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=29/70 Signal level=-81 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:22 Invalid misc:0 Missed beacon:0

let's see what rebooting gets me...

iwconfig wlan0
wlan0 IEEE 802.11 ESSID:"Kitchen"
Mode:Managed Frequency:2.457 GHz Access Point:
30:46:9A:A2:89:F6
Bit Rate=57.7 Mb/s Tx-Power=31 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=41/70 Signal level=-69 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:1 Invalid misc:0 Missed beacon:0

Ah. That's better. 12 dB better. Still rubbish.

I get -70dB and 40/70 quality in the laptop about 6 meters away from the
same point and that manages 150Mbps....or thats what iwconfig says
anyway., Realtek twin channel chip.





--
Renewable energy: Expensive solutions that don't work to a problem that
doesn't exist instituted by self legalising protection rackets that
don't protect, masquerading as public servants who don't serve the public.

[Laurenz Trossel]

On 2022-01-13, Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:

> But when you've got something like 6 neighbors all using "optimal"
> channels 1/6/11 -- you might be better off on channel 3/4 where you might
> not be getting channel usage congestion/collisions...

No. That's the worst option.

Wifi networks on the same channel detect their presence and schedule their
traffic so that only one transmitter is active at a time, reducing garbled
packets and retransmissons.

Wifi networks operating on adjacent, overlapping channels cause
unpredictable random RFI, reducing performance for all users due to
retransmissions. The same is true for a mix of 20Mhz/40Mhz networks.

For best performance, switch to 5GHz on a frequency not in use by neighbors
with enough spacing to enable 80+MHz channels.

[NY]

"Laurenz Trossel" <m...@example.invalid> wrote in message
news:srrjdp$1opa$1...@gioia.aioe.org...

5 GHz is the best, but it does have two disadvantages:

- the range is less because 5 GHz is attenuated more than 2.4 GHz for the
same location of router and computer (ie the same distance and the same
obstructions)

- some older devices (my old laptop, our Foscam security cameras) don't
support 5 GHz, so you may need 2.4 left on for compatibility

[Chris Green]

Nowhere in our house does 5Ghz offer any advantage, it's only if I put
a client virtually on top of the router or AP (I have two which offer
5Ghz) that it's any faster and I might as well use a wired connection
in that case.

Where I am using my laptop at the moment 2.4GHz gives me 300Mbs and
5GHz gives me 180Mbs.

We are lucky in that we have virtually no neighbours close enough to
have any effect on our WiFi, I can only see one, faint, signal from
our nearest neighbour who is across the road from us.

--
Chris Green
·

[druck]

On 13/01/2022 22:35, The Natural Philosopher wrote:
> But I hate wifi. Bloody unreliable. The spark igniter on my central
> heating oil  boiler reliably disconnects any wifi device in the house
> within 20 feet of it.
> My Pi-zero W  maybe has 5ft reliable  range through a wall, and the
> worst wifi chip in the world
>
> Oh dear. Its in the dining room and  its managed to connect itself to
> the living room, 6 meters away...7Mbps instead of the kitchen

The Pi-zero W's WiFi is fine for a single antenna of that size - as long
as it knows what to connect to.

If you are using multiple consumer access points you are always going to
get issues like this. Proper managed WiFi can be set up to ensure a
device connects to the most appropriate access point.

---druck

[The Natural Philosopher]

The problem is its set up to try the kitchen first, then the living room

But, under power cut conditions the kitchen - a repurposed Netgear ADSL
router - takes longer to boot than the Pi..

Ergo it found the nearest and best access point it could.

The problem is that i dont know how to make it switch to a strionger one
if there is one, later.





--
"Anyone who believes that the laws of physics are mere social
conventions is invited to try transgressing those conventions from the
windows of my apartment. (I live on the twenty-first floor.) "

Alan Sokal

[The Natural Philosopher]

My nearest neighbour is 200+ yards away.

All I can see are my three access points, one of which is almost
useless, and came with the router, which is in a room with foil backed
plasterboard walls.

It has been quite a struggle to find good places for the access points,
based on where people like to use WiFi.

[Chris Green]

Only if "a device" cooperates. Modern devices *should* have the latest
WiFi standards updates in them so that they understand and usew the
hints given by mesh systems. However it is always down to the client
to choose which AP to use and older (and other badly configured)
clients may well not choose the right AP or move when sensible.

--
Chris Green
·

[druck]

On 14/01/2022 14:24, Chris Green wrote:

> druck <ne...@druck.org.uk> wrote:
>> If you are using multiple consumer access points you are always going to
>> get issues like this. Proper managed WiFi can be set up to ensure a
>> device connects to the most appropriate access point.
>>
> Only if "a device" cooperates. Modern devices *should* have the latest
> WiFi standards updates in them so that they understand and usew the
> hints given by mesh systems. However it is always down to the client
> to choose which AP to use and older (and other badly configured)
> clients may well not choose the right AP or move when sensible.

An actively managed system can send a drop to a device on an undesirable
access point, which forces it to re-establish a connection to an access
point with a stronger system.

---druck

[Chris Green]

Yes, but dropping the connection will break whatever is going on. lost
phone conversation, broken streaming, whatever. It's an absolute last
resort to drop the connection.

--
Chris Green
·

[druck]

It's usually done at the point the device first connects to the
unsuitable access point, so nothing is going on then, and it just
appears to take slight longer to get a WiFi signal.

---druck

[Chris Green]

That assumes you have a client that does a "first connect" after not
being used for a while. I'm much more familiar with the way my laptop
does things and that simply never disconnects unless I explicitly tell
it to. Thus there isn't a time when "the device first connects", it has
been connected all night and I've just walked through from the lounge
where I used it last night to the breakfast room where I'm using it now.

--
Chris Green
·