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.
"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.
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.
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.
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).
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: | Coz |
---|---|
Location: | Anoka, MN |
Users: | 2 |
Nodes: | 4 (0 / 4) |
Uptime: | 16:14:15 |
Calls: | 93 |
Files: | 4,554 |
Messages: | 215,503 |