-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What does the NumSeconds option stand for? #530
Comments
According to RFC2131 section 2it is defined as follows:
It's not used anywhere in this library, as it's always set to 0. I don't think it's related to the issue you're seeing. Do you see lost packets with tcpdump? |
Thanks for the swift reply :) So that makes a lot of sense since the client is sending another DHCPDISCOVER 4 seconds after the first DHCPACK. Do you have any guess on what might be causing the client to send the DHCPDISCOVER again after 4 seconds? Could it be that the DHCPACK is not reaching the client? |
Usually, yes, it depends on the client. You should verify that the server is sending the reply and that it's making its way back to the client. Using tcpdump on the server should be enough |
dhcp/dhcpv4/dhcpv4.go
Line 64 in f1cffa2
By reading the DHCP RFC, I can't figure out what the field NumSeconds stands for.
I'm super interested in knowing this because I'm facing some flaky issues where with high load, it seems some UDP packets are dropped (my theory), by looking at the DHCP logs (I wrote a wrapper around this lib):
The text was updated successfully, but these errors were encountered: