Re: Raspberry Pi 4's IP Address 169...

Am Freitag, 07. Januar 2022, um 11:18:57 Uhr schrieb Patrick Zacharczyp:

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.

Your router should be supplying it with an IP address There ought to be a Network Control Panel or similar somewhere under Settings where you can tell the Pi to use DHCP. Then the router will supply it with an IP address.

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

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.

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

WHS

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

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.

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

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...

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

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.

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

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.

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.

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.

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

See

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

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.

On a sunny day (Fri, 7 Jan 2022 11:18:57 -0800 (PST)) it happened Patrick Zacharczyp snipped-for-privacy@bccaschools.org wrote in snipped-for-privacy@googlegroups.com:

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

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

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

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.

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,

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

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.

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]

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.

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

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

dhclient -v eth0

---druck

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).

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

There is Ethernet tha'ts all

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

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

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.

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.

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.

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

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..