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.
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
192.168.1.64 m-router.dmz.kn 255.255.255.192 UG 202 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
---- 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
formatting link
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
formatting link
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.
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.
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.
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!
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.
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
192.168.2.0/24 dev eth0 proto dhcp scope link src 192.168.2.14 metric 202
--
Activated the option 121 again -> no default GW anymore.
Anybody an idea?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.