RPi4 bekommt kein Default GW

Hallo zusammen,
GW gesetzt.
StandarsGW mit der IP Adresse gesetzt.
Aktuelles RaspiOS IP via DHCP. In der dhclient.conf wird u.A. auch eine
request auf routers gemacht.
Dem dnsmasq.log nach, wir das GW angefragt und auch gesendet. Es scheint
Nach Eingane von "route add default GW " hat der Pi4 bis zur
zu haben. An einer anderen Stelle im Netzwerk hinter einem anderen
Router bekommt der Pi sein default GW.
Das hier
formatting link
habe
nicht ganz schlau. Da der Pi im Netzwerk manchmal umzieht, ist ein
statisches Default GW nicht wirklich hilfreich.
--
cu 
hawe
Reply to
Hans-Werner Kneitinger
Loading thread data ...
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.
--
W J G
Reply to
Folderol
Am 18.08.20 um 11:15 schrieb Folderol:
Sorry for that.
--
cu 
hawe
Reply to
Hans-Werner Kneitinger
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?
--
cu 
hawe
Reply to
Hans-Werner Kneitinger
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.
--

-TV
Reply to
Tauno Voipio
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. --- 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 0x830907f7, Flags [none] --> Your-IP 192.168.2.14 Server-IP 192.168.2.4 Default-Gateway Option 3, length 4: 192.168.2.1
Reply to
Hans-Werner Kneitinger
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.
--

-TV
Reply to
Tauno Voipio
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 192.168.1.64 m-router.dmz.kn 255.255.255.192 UG 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 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?
--
cu 
hawe
Reply to
Hans-Werner Kneitinger
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.
--

-TV
Reply to
Tauno Voipio
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.
--
cu 
hawe
Reply to
Hans-Werner Kneitinger
Can you post the output of : grep -v ^# /etc/dhcpcd.conf
--

Chris Elvidge, England
Reply to
Chris Elvidge
Issue this command:-
dpkg -S $(which dhclient)
It should return:-
isc-dhcp-client: /sbin/dhclient
---druck
Reply to
druck
Am 21.08.20 um 12:46 schrieb Chris Elvidge:
--
hostname 

clientid 
 Click to see the full signature
Reply to
Hans-Werner Kneitinger
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.
--
cu 
hawe
Reply to
Hans-Werner Kneitinger
relevant?

Reply to
Andy Burns
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!
--

Chris Elvidge, England
Reply to
Chris Elvidge
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.
--
cu 
hawe
Reply to
Hans-Werner Kneitinger
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 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?
 Click to see the full signature
Reply to
Hans-Werner Kneitinger
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?
Reply to
Andy Burns
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.
--
cu 
hawe
Reply to
Hans-Werner Kneitinger

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.