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 evenused 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.
On 7.1.22 21.18, Patrick Zacharczyp wrote: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.
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
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
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.
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 evenused 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.
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.
"Marco Moock" <mo01@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.
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.
"Marco Moock" <mo01@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.
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?
Am Samstag, 08. Januar 2022, um 14:52:07 Uhr schrieb NY:
"Marco Moock" <mo01@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).
"Marco Moock" <mo01@posteo.de> wrote in message news:20220108183111.318f397f@ryz...
Am Samstag, 08. Januar 2022, um 14:52:07 Uhr schrieb NY:
"Marco Moock" <mo01@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 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...
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.
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 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.
"Marco Moock" <mo01@posteo.de> wrote in message news:20220108183111.318f397f@ryz...
Am Samstag, 08. Januar 2022, um 14:52:07 Uhr schrieb NY:
"Marco Moock" <mo01@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 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.
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...
[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]
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.
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.
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.
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).
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
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?
"Brian Gregory" <void-invalid-dead-dontuse@email.invalid> wrote in
message news:j440tnF3cj1U1@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?
Anyway, have we got any more info from the OP to help us sort out his
169 problem? I've not seen any.
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.
"Brian Gregory" <void-invalid-dead-dontuse@email.invalid> wrote in message
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.
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.
Yes. Up to a point. CAT5 separates transmit and receive stuff, unlike
co-ax so there is slightly less chance of a collision.
Indeed. The auto DHCP will work for the primary ethernet adapter. No
idea how you adjust it for a second port
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.
It's much better to have the network switches filter out all that
unwanted stuff.
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
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" <mo01@posteo.de> wrote in message news:20220111192232.5b62a4f2@ryz...
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. :-)
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.
What is impressive, is that the Ethernet standard has kept pace with all
this to gigabit and possibly beyond
On Wed, 12 Jan 2022 12:16:53 +0000
The Natural Philosopher <tnp@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.
It seems Moore has moved his law to network bandwidth after getting
bored with processor speeds.
On Wed, 12 Jan 2022 12:16:53 +0000
The Natural Philosopher <tnp@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" <tnp@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]
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
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
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
Ahem A Rivet's Shot <steveo@eircom.net> wrote:
On Wed, 12 Jan 2022 12:16:53 +0000
The Natural Philosopher <tnp@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.
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).
On Wed, 12 Jan 2022 14:11:31 +0000, Ahem A Rivet's Shot <steveo@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.
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
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.
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.
about 5 bps up. Not a huge increase in download speed, but a tremendous^^^^^^^^^^
increase in upload speed when FTPing files to a server.
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
"The Natural Philosopher" <tnp@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.
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? :-)
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 Natural Philosopher" <tnp@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.
"The Natural Philosopher" <tnp@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.
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.
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.
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
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.
On Thu, 13 Jan 2022 09:36:56 -0000, "NY" <me@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
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.,
On 2022-01-13, The Natural Philosopher <tnp@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).
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.
"The Natural Philosopher" <tnp@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.
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.
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, 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
"The Natural Philosopher" <tnp@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...
On Thu, 13 Jan 2022 20:26:05 -0000
"NY" <me@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.
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.
On Thu, 13 Jan 2022 20:26:05 -0000, "NY" <me@privacy.invalid> declaimed the following:
"The Natural Philosopher" <tnp@invalid.invalid> wrote in messageBut 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
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.
not be getting channel usage congestion/collisions...
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...
On 2022-01-13, Dennis Lee Bieber <wlfraed@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.
"Laurenz Trossel" <me@example.invalid> wrote in message news:srrjdp$1opa$1@gioia.aioe.org...
On 2022-01-13, Dennis Lee Bieber <wlfraed@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.
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
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
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.
NY <me@privacy.invalid> wrote:
"Laurenz Trossel" <me@example.invalid> wrote in messageNowhere in our house does 5Ghz offer any advantage, it's only if I put
news:srrjdp$1opa$1@gioia.aioe.org...
On 2022-01-13, Dennis Lee Bieber <wlfraed@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.
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
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.
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 <news@druck.org.uk> wrote:
If you are using multiple consumer access points you are always going toOnly if "a device" cooperates. Modern devices *should* have the latest
get issues like this. Proper managed WiFi can be set up to ensure a
device connects to the most appropriate access point.
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.
On 14/01/2022 14:24, Chris Green wrote:
druck <news@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 aOnly if "a device" cooperates. Modern devices *should* have the latest
device connects to the most appropriate access point.
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 <news@druck.org.uk> wrote:
On 14/01/2022 14:24, Chris Green wrote:Yes, but dropping the connection will break whatever is going on. lost
druck <news@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 aOnly if "a device" cooperates. Modern devices *should* have the latest
device connects to the most appropriate access point.
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.
phone conversation, broken streaming, whatever. It's an absolute last
resort to drop the connection.
On 14/01/2022 21:36, Chris Green wrote:
druck <news@druck.org.uk> wrote:
On 14/01/2022 14:24, Chris Green wrote: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.
druck <news@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 aOnly if "a device" cooperates. Modern devices *should* have the latest >>> WiFi standards updates in them so that they understand and usew the
device connects to the most appropriate access point.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 218:09:19 |
| Calls: | 6,621 |
| Calls today: | 3 |
| Files: | 12,171 |
| Messages: | 5,317,781 |