David Fokkema <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]