DHCP client state if rebooted when local DHCPD server is offline?
Gregory Sloop
gregs at sloop.net
Thu Aug 14 19:07:20 UTC 2014
tlfc> On Thu, Aug 14, 2014, at 10:30 AM, Gregory Sloop wrote:
>> It seems clear that there's some problem with the DHCP server, [or perhaps VLAN's or network connectivity.]
>> How about a quick packet capture to be sure the DHCP server is actually seeing the requests. [I think this is the first, most important step.]
>> -If it IS seeing them, then there's some configuration problem.
>> -If it isn't, then figuring out what's preventing the communication from occurring, would be important. [Broadcast filtering, DHCP server and DHCP client on different VLANs without a DHCP helper/relay etc.]
tlfc> Assuming that dhcping is a useful way to test,
tlfc> checking from my client
tlfc> dhcping -h XX:XX:XX:XX:XX:XX -s 10.16.10.1 -c 10.16.10.26
tlfc> Got answer from: 10.16.10.1
tlfc> Watching on the server
tlfc> tcpdump -vvv -i eth1 -s 1500 port bootps or port bootpc
tlfc> tcpdump: listening on eth1, link-type EN10MB
tlfc> (Ethernet), capture size 1500 bytes
tlfc> 11:31:52.432820 IP (tos 0x0, ttl 64, id 33227,
tlfc> offset 0, flags [DF], proto UDP (17), length 278)
tlfc> tgdesktop.MYDOMAIN.net.bootpc >
tlfc> edgerouter.MYDOMAIN.net.bootps: [udp sum ok] BOOTP/DHCP, Request
tlfc> from XX:XX:XX:XX:XX:XX (oui Unknown), length 250, xid
tlfc> 0x9800ed53, Flags [none] (0x0000)
tlfc> Client-IP tgdesktop.MYDOMAIN.net
tlfc> Client-Ethernet-Address XX:XX:XX:XX:XX:XX (oui Unknown)
tlfc> Vendor-rfc1048 Extensions
tlfc> Magic Cookie 0x63825363
tlfc> DHCP-Message Option 53, length 1: Request
tlfc> Requested-IP Option 50, length 4: tgdesktop.MYDOMAIN.net
tlfc> END Option 255, length 0
tlfc> 11:31:52.433206 IP (tos 0x0, ttl 64, id 5840,
tlfc> offset 0, flags [DF], proto UDP (17), length 328)
tlfc> edgerouter.MYDOMAIN.net.bootps >
tlfc> tgdesktop.MYDOMAIN.net.bootpc: [bad udp cksum 0x6fed -> 0x1b16!]
tlfc> BOOTP/DHCP, Reply, length 300, xid 0x9800ed53, Flags [none] (0x0000)
tlfc> Client-IP tgdesktop.MYDOMAIN.net
tlfc> Your-IP tgdesktop.MYDOMAIN.net
tlfc> Client-Ethernet-Address XX:XX:XX:XX:XX:XX (oui Unknown)
tlfc> Vendor-rfc1048 Extensions
tlfc> Magic Cookie 0x63825363
tlfc> DHCP-Message Option 53, length 1: ACK
tlfc> Server-ID Option 54, length 4: edgerouter.MYDOMAIN.net
tlfc> Lease-Time Option 51, length 4: 14400
tlfc> Subnet-Mask Option 1, length 4: 255.255.252.0
tlfc> Default-Gateway Option 3, length 4: edgerouter.MYDOMAIN.net
tlfc> Domain-Name-Server Option 6, length 4: edgerouter.MYDOMAIN.net
tlfc> Domain-Name Option 15, length 18: "MYDOMAIN.net"
tlfc> END Option 255, length 0
tlfc> PAD Option 0, length 0, occurs 6
tlfc> 11:31:52.433580 IP (tos 0x0, ttl 64, id 33228,
tlfc> offset 0, flags [DF], proto UDP (17), length 272)
tlfc> tgdesktop.MYDOMAIN.net.bootpc >
tlfc> edgerouter.MYDOMAIN.net.bootps: [udp sum ok] BOOTP/DHCP, Request
tlfc> from XX:XX:XX:XX:XX:XX (oui Unknown), length 244, xid
tlfc> 0x9800ed53, Flags [none] (0x0000)
tlfc> Client-IP tgdesktop.MYDOMAIN.net
tlfc> Client-Ethernet-Address XX:XX:XX:XX:XX:XX (oui Unknown)
tlfc> Vendor-rfc1048 Extensions
tlfc> Magic Cookie 0x63825363
tlfc> DHCP-Message Option 53, length 1: Release
tlfc> END Option 255, length 0
tlfc> There's a "bad udp cksum" in there that doesn't look so good.
tlfc> But the server IS getting the request it seems, and the client DOES get a reply.
I'm not the most skilled at looking at that trace - the quick look I gave it looks fine - though that shouldn't be a stamp of approval either. :)
This dhcp client [or server] isn't hanging off a wireless network/bridge is it? IIRC, there's been a number of cases where DHCP broadcasts and/or replies get munged in certain situations like that.
Can you describe the physical network setup.
Finally, if you think it's not a network problem, I'd set the DHCP server up very simply. Make sure it works in a *very* basic setup, then tweak to do more esoteric things.
[I'm likely to be tied up with other things soon, so I hope someone else will chime in too...]
-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20140814/cd31f917/attachment-0001.html>
More information about the dhcp-users
mailing list