| Summary: | systemd-networkd does not renew DHCP lease when it expires | ||
|---|---|---|---|
| Product: | systemd | Reporter: | gt6 |
| Component: | general | Assignee: | Tom Gundersen <teg> |
| Status: | RESOLVED WORKSFORME | QA Contact: | systemd-bugs |
| Severity: | major | ||
| Priority: | medium | CC: | dirocco.nico, gt6 |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
journal
tcpdump tcpdump-br0 |
||
|
Description
gt6
2014-08-17 14:11:10 UTC
Sorry for net getting back to you sooner. The fact that you are getting a NAK from your server is what is causing the problem. networkd is asking to renew the lease, but the DHCP server is refusing, so the lease simply expires and the kernel drops the address. A dirty work-around is to mark this as a CriticalConnection. To fix the problem: May I ask for a package dump aronud the time you get the NAK? That way we can verify whether or not the problem is with the request networkd sends to the server, with the server itself or with the way networkd parses the reply. Thanks! Created attachment 104988 [details]
journal
Created attachment 104989 [details]
tcpdump
Thanks for your feedback. I've set up some timers inside a tmux session so I could run tcpdump a few seconds before the lease runs out and then restart systemd-networkd a few seconds later. I've attached both the journal and the tcpdump log from around that time. As can be seen in the journal at... ... 17:02:01 the connection went down ... 17:02:18 the timed script restarted systemd-networkd to re-establish connection The tcpdump doesn't show anything happening at 17:02:01, but one second later there's a dhcp6 solicit. The other stuff only happens once systemd-networkd was restarted. I stripped some ssh/nfs related stuff from the tcpdump but I'm 100% sure I didn't trim anything relevant. I'm not sure if this helps. I can post any additional info you need. Thanks again. Wait, I should have done this for br0 and not enp3s0... Let me do that again and come back later. Sorry about that. Ok, I'll check back later with the updated version. Just a note: what we are looking for is DHCP traffic, which sholud happen around the time you get the NAK (which is probably 50% or 75% of the way to the lease expiration). I see. In that case, I'll just let tcpdump run until tomorrow to make sure I catch it. Is it sufficient if I monitor port 67 and 68, i.e. tcpdump -i br0 -n port 67 and port 68 ? That should do it. Created attachment 106133 [details]
tcpdump-br0
Sorry for the delay. I attached a lengthy dump, hoping that it contains the information you require. I wasn't able to find anything about a NAK in it, though. The log contains close to 24h of packets of the br0 interface. At the beginning of the log (at 16:12:59) I restarted systemd-networkd.
I am pretty sure this works correctly on current systemd. CLosing hence. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.