Re: dhclient problem
David Fokkema <fokkema@nat.vu.nl> writes:
>
> This is the log with the right options (yesterday I forgot some, so I
> didn't send it since I didn't think it would be useful). I hope you still
> have some time to look at it, the problem keeps annoying me. Thanks!
Well, after every DHCP REQUEST, there's an immediate ARP packet from
81.91.5.1 trying to resolve the offered IP address.
It looks like 81.91.5.1 is trying to deliver the DHCP ACK packet by
using ARP to resolve the IP address that hasn't yet been assigned to
your machine instead of by grabbing the MAC address from the chaddr
field of the packet. Your ISP can see the ACK leave their DHCP server
at 81.91.1.11; the problem is that their broken router/relay at
81.91.5.1 isn't delivering the ACK to your machine. It's just
unsuccessfully ARPing for the offered IP address and dropping the
packet. That's so broken it hurts.
The fact that it delivers the OFFER correctly and that changing your
MAC address, client identifier, or both can convince it to correctly
deliver the ACK packet (by broadcast) just makes it weirder.
You may be able to work around the problem by setting the BOOTP
broadcast flag on your DHCP REQUEST---this may convince the errant
relay to broadcast the DHCP ACK instead. Here's a patch against
Debian's dhcp-2.0pl5 to do so:
--- dhcp-2.0pl5/client/dhclient.c.orig Sun Mar 30 15:16:18 2003
+++ dhcp-2.0pl5/client/dhclient.c Sun Mar 30 15:20:03 2003
@@ -1586,9 +1586,11 @@
} else {
memset (&ip -> client -> packet.ciaddr, 0,
sizeof ip -> client -> packet.ciaddr);
+#if 0
if (can_receive_unicast_unconfigured (ip))
ip -> client -> packet.flags = 0;
else
+#endif
ip -> client -> packet.flags = htons (BOOTP_BROADCAST);
}
I'll be surprised if that works, but it's worth a try.
--
Kevin <buhr@telus.net>
Reply to: