RPi4 bekommt kein Default GW

ult

Problem

keiten

Hallo Hans

n.

Bei allem Respekt empfehle ich Ihnen, Ihren Beitrag auf Englisch zu verfass en, da dies hier die Mehrheitssprache ist.

Am 18.08.20 um 11:15 schrieb Folderol:

Sorry for that.

Am 18.08.20 um 09:38 schrieb Hans-Werner Kneitinger: Sorry for german, let me ask in my very unused school englisch.

I Have a strange Problem with my Pi4 and latest fresh installed Raspberry OS.

An older RPi is setup as an DHCP/DNS Server via dnsmmasq. The dhcp option 3 is set to the IN-GW IP.

The RPi4 requests via dhclint.conf the routers, too.

As the dnsmasq.log shows, there is a request for the router and it is answerde corectly. But on the RPi4 it is not set. Other options like domain or other routes are set.

Doing "route add defaukt gw " manually did the job until leastime ended and next dhcp requst is done by the RPi4

Other devices do well, RPi did well on an other segment in the network with an other router DHCP/DNS.

I found some Information abaut Network problems, but did not find a usefull answer. Setting a static defaukt gw via script at boot is no option in my usecase.

Have somebody an idea wich can help to figure out the problem or help debugging?

If that were mine, I'd start by taking Ethernet trace dumps from either end of the DHCP exchange, either the client or the server, to see if the default route is indeed requested and set from the server.

The tool to capture the traffic is tcpdump, which is pretty good in displaying what is going on. A still better way would be to install Wireshark to a desktop computer, get tcpdump grab a .pcap file and decode it using Wireshark.

The protocol to look at is UDP, ports 67 and 68.

Am 18.08.20 um 20:30 schrieb Tauno Voipio: Thank you for your support.

It looks ok to me. Here is the client output:

After restart I am beginning with

--- route Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface

---- end Thats OK but missing defaut GW.

--- dhclient -v eth0 Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit

Listening on LPF/eth0/dc:a6:32:87:69:13 Sending on LPF/eth0/dc:a6:32:87:69:13 Sending on Socket/fallback DHCPREQUEST for 192.168.2.14 on eth0 to 255.255.255.255 port 67 DHCPNAK from 192.168.2.1 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4 DHCPOFFER of 192.168.2.14 from 192.168.2.4 DHCPREQUEST for 192.168.2.14 on eth0 to 255.255.255.255 port 67 DHCPACK of 192.168.2.14 from 192.168.2.4 Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units. bound to 192.168.2.14 -- renewal in 37999 seconds

--- end

Normaly dhcp/dns at 192.168.2.1 is off. Same result if it is on/off, no default GW.

Starting tcpdump on the client with capturining udp 67,68 into file. On a second terminal doing

--- dhclient -v -r eth0 Killed old client process Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit

Listening on LPF/eth0/dc:a6:32:87:69:13 Sending on LPF/eth0/dc:a6:32:87:69:13 Sending on Socket/fallback DHCPRELEASE of 192.168.2.14 on eth0 to 192.168.2.4 port 67 Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.

--- end Stopping tcpdump

--- dcpdump file P (tos 0x0, ttl 64, id 36249, offset 0, flags [DF], proto UDP (17), length 328) 192.168.2.14.68 > 192.168.2.4.67: BOOTP/DHCP, Request from dc:a6:32:87:69:13, length 300, xid 0x1c37e372, Flags [none] Client-IP 192.168.2.14 Client-Ethernet-Address dc:a6:32:87:69:13 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Release Server-ID Option 54, length 4: 192.168.2.4 Hostname Option 12, length 6: "hoshi2" IP (tos 0x0, ttl 64, id 9930, offset 0, flags [none], proto UDP (17), length 365) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from dc:a6:32:87:69:13, length 337, xid 0x830907f7, Flags [none] Client-Ethernet-Address dc:a6:32:87:69:13 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Client-ID Option 61, length 7: ether dc:a6:32:87:69:13 Requested-IP Option 50, length 4: 192.168.2.14 MSZ Option 57, length 2: 1472 Vendor-Class Option 60, length 45: "dhcpcd-8.1.2:Linux-5.4.51-v7l+:armv7l:BCM2711" Hostname Option 12, length 6: "hoshi2" T145 Option 145, length 1: 1 Parameter-Request Option 55, length 14: Subnet-Mask, Classless-Static-Route, Static-Route,

--> Default-Gateway 255.255.255.255.68: BOOTP/DHCP, Reply, length 548, xid 0x830907f7, Flags [Broadcast] Server-IP 192.168.2.1 Client-Ethernet-Address dc:a6:32:87:69:13 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: NACK IP (tos 0xc0, ttl 64, id 26735, offset 0, flags [none], proto UDP (17), length 419) 192.168.2.4.67 > 192.168.2.14.68: BOOTP/DHCP, Reply, length 391, xid

--> Your-IP 192.168.2.14 Server-IP 192.168.2.4 Default-Gateway Option 3, length 4: 192.168.2.1

You are right. It seems that the server behaves.

Do you have other client using the same server, just to check that they go well?

My experience stops here, I'm using a different DHCP client, dhclient instead of dhcpcd. Please check the configuration of dhcpcd.

Am 19.08.20 um 15:47 schrieb Tauno Voipio:

Thanks for help.

Strange things going on. Using a fresh installed beelink Mii-V with aktual debian -> same issue.

Using my very old Pi1B with upgraded all the time up to Buster

--- route Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface default nx01.dmz.kneiti 0.0.0.0 UG 0 0 0 eth0

--- end Its working.

How to check if Pi1 is using dhclient or dhcpd?

Is it possible to deaktivate dhcpd temporary and test dhclient?

You can see from ps -ef which of them is running. It is up to the init scripts (/etc/init.d) or systemd how the client is started.

Careful: dhcpd is the server daemon and dhcpcd is the client.

If the systemd is used, systemctl is the command, see man pages for details, there are plenty.

If the start-up is from /etc/init.d, you may use the activation script with stop argument.

Am 19.08.20 um 20:42 schrieb Tauno Voipio:

As I now have seen, the Pi wich is working, uses dhclient, too. But I dont find any packaeg wich is including dhclient. It seems that all are using dhcpcd.

Can you post the output of : grep -v ^# /etc/dhcpcd.conf

Issue this command:-

dpkg -S $(which dhclient)

It should return:-

isc-dhcp-client: /sbin/dhclient

---druck

Am 21.08.20 um 12:46 schrieb Chris Elvidge:

--- hostname

clientid

persistent

option rapid_commit

option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes, routers

option interface_mtu

require dhcp_server_identifier

slaac private

---

-- cu hawe

Am 21.08.20 um 14:42 schrieb druck:

It does. As I found out, dhclient is installed, too. I am working on a service-unit file to integrate dhclient in systemd startup. But I think, dhclient is outdated in near furture.

dhcpcd seems a little bit less stable than dhclient to me. I remember some issues some time ago, I cnat understand. Some Pis send hostname and som did not.

relevant?

Well that looks nearly like mine. The only difference is the "routers" parameter on the 3rd option. Does that option exist in your working dhcpcd machines? Now back to being puzzled!

Am 22.08.20 um 15:23 schrieb Chris Elvidge:

In original file it isn't set. I put it in during testing, but did not help. I forgot to put it out.

All I know and all test are done with help form many, it seems it get the routers IP but did not set in rounting table.

Now I am struggeling with dhclient. On an other device with amd64 Buster ther is neither dhcpcd nor dhclient in systemd. It seems its only ifup ifdown handeld. witj ps -ef there is a job /sbin/dhclient ... but no route entry. N dhcpcd maschien working. Working machines are iOS devises, Windows device or Synology NAS. One singe very old Rpi1B is working. It is updated bey the time to buster.

The dnsmasq machine is under heavy load (mem and cpu) and should be replaced by on of the new machines. But I must get a good feeling that it work right.

Could it be a timing problem or a limited routing table? I dont know anymore.

Am 22.08.20 um 09:20 schrieb Andy Burns:

Thanks, didn't know that article. The file looks pretty much like mine. Nevertheless changend the content with mine. Same ...

But, testing if dnsmasq is the problem I commentet out the option 121 line. Restarteing dhcpcd on RPi4 --- strange - default gw apeaes in the rouing table.

--- ip r default via 192.168.2.1 dev eth0 proto dhcp src 192.168.2.14 metric 202

You said earlier that you have option 3, have you tried not having option 3, but putting your default aroute as 0.0.0.0/0.0.0.0 within the option 121?

Thanks, that works.

Seems to be a good workaround, but no fix. In some dnsmasq docs I read, it is no good idea to do so. Therefor I have put it in option 3.

It seems dhcpcd struggles with both options. Is it a bug? Want to know whats to do next.