Hi My probe arrived late last week and I finally hooked it up late yesterday afternoon. All was working fine until around 3:30am today when I received an automated email to say that my probe was down. I restarted it at around 7:00am when I got up but that didn't help - ever since it's been requesting a new IP every 3-5 seconds but not accepting the offered lease. From my dhcpd logs: Nov 6 07:12:02 dreamland dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via br0 Nov 6 07:12:02 dreamland dhcpd: DHCPOFFER on 192.168.1.248 to aa:bb:cc:dd:ee:ff via br0 Nov 6 07:12:05 dreamland dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via br0 Nov 6 07:12:05 dreamland dhcpd: DHCPOFFER on 192.168.1.248 to aa:bb:cc:dd:ee:ff via br0 (where aa:bb:cc:dd:ee:ff is the correct MAC, I've just redacted it). I've allocated the device a static IP based upon its MAC. Help! :) My probe ID is 3508. -mj -- Michael-John Turner mj@mjturner.net <> http://mjturner.net/
On 11/6/12 21:59 , Michael-John Turner wrote:
I've allocated the device a static IP based upon its MAC.
When a probe knows it probe ID, it changes its DHCP client-id. See https://atlas.ripe.net/faq#how-does-the-probe-connect Maybe you can capture the dhcp traffic with tcpdump to see if the server sends something the probe doesn't like?
On Wed, Nov 07, 2012 at 10:36:14AM +0100, Philip Homburg wrote:
When a probe knows it probe ID, it changes its DHCP client-id. See https://atlas.ripe.net/faq#how-does-the-probe-connect
Thanks for the suggestion - I had seen that but didn't have the stanza matching by client ID as I didn't think it was necessary (MAC address alone should be sufficient, I would've thought?). I have added it now, but it hasn't helped.
Maybe you can capture the dhcp traffic with tcpdump to see if the server sends something the probe doesn't like?
Sure. I've placed a copy of the the request/reply at http://dl.rsx11.net/misc/atlas_probe_dhcp.txt. I've redacted the MAC addresses (aa:bb:cc... is the MAC of the probe) but everything else is unchanged. I don't see anything unusual - please let me know if you'd like a copy of the raw tcpdump output. I also received an off-list suggestion regarding a possible duplicate IP so I've changed the IP assigned to the probe without it making any difference. Not sure if it makes a difference, but I do also have rtavd and DHCPv6 servers running on the same network (IPv6 connectivity to/from the probe was working fine until this problem started). -mj -- Michael-John Turner mj@mjturner.net <> http://mjturner.net/
On 11/7/12 11:14 , Michael-John Turner wrote:
Sure. I've placed a copy of the the request/reply at http://dl.rsx11.net/misc/atlas_probe_dhcp.txt. I've redacted the MAC addresses (aa:bb:cc... is the MAC of the probe) but everything else is unchanged. I don't see anything unusual - please let me know if you'd like a copy of the raw tcpdump output.
According to your log the dhcp server sends the offer to 192.168.1.247, but the probe doesn't listen to that IP address because it is still trying to get one. The proper response would be to broadcast the offer.
On Wed, Nov 07, 2012 at 11:22:06AM +0100, Philip Homburg wrote:
According to your log the dhcp server sends the offer to 192.168.1.247, but the probe doesn't listen to that IP address because it is still trying to get one. The proper response would be to broadcast the offer.
Ah, well spotted! I've enabled the 'always-broadcast' option (ISC dhcpd 4.2.2) to force a broadcast to be sent even when the client doesn't request it. ... TIME: 2012-11-07 11:13:48.277 IP: 192.168.1.10 (ff:ee:dd:cc:bb:aa) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 2cce0f0a SECS: 0 FLAGS: 7f80 CIADDR: 0.0.0.0 YIADDR: 192.168.1.247 ... Still no request from the client after the offer :( Nov 7 11:25:41 dreamland dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via br0 Nov 7 11:25:41 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to aa:bb:cc:dd:ee:ff via br0 Nov 7 11:25:44 dreamland dhcpd: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via br0 Nov 7 11:25:44 dreamland dhcpd: DHCPOFFER on 192.168.1.247 to aa:bb:cc:dd:ee:ff via br0 11:29:51.569439 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from aa:bb:cc:dd:ee:ff, length 548 11:29:51.569927 IP 192.168.1.10.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 320 11:29:54.579613 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from aa:bb:cc:dd:ee:ff, length 548 11:29:54.579994 IP 192.168.1.10.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 320 (MAC redacted). This is most strange as this setup was working for several hours and I've not had any problems with my DHCP setup before. -mj -- Michael-John Turner mj@mjturner.net <> http://mjturner.net/
participants (2)
-
Michael-John Turner -
Philip Homburg