Okay, thanks. If the userbase ever becomes significant (more than 2?), then perhaps we could just have Hijack modify the DHCP packets as they pass through.

Cheers

This bug is also present in the regular car2-v3alpha11 load as well, so now I *really* want to squash it.

I suppose I'll have to have Hijack replace the CID on outgoing DHCP packets -- and probably put the old CID back again on incoming ones that match, right ?

Here's the wireshark trace. First, a short summary for those with good eyesight, and then an attached binary blob that can be reloaded back into wireshark for viewing/interpretation.

A more readable copy of the image below is available here.

One problem seems to be that the empeg's bootp request has the "broadcast bootp flag" set, so the server must use broadcast when replying.. and that reply then gets picked up by all other empegs on the subnet.

Most of the other DHCP clients here do not set that bit, so the server sends a targeted response to them.

I could try having Hijack clear that bit on the outgoing packet, and see if the empeg copes with it.

-ml

Mmm.. I suppose that trace is not quite complete -- used a switch during the capture. It still illustrates the problem (two players claim the same IP address, even though they were assigned different IP addresses by DHCP), but not the complete sequence.

So for completeness, I'll later hook up a shared hub and run Wireshark from there to get all of the packets.

Cheers

Hmmm... I do remember now that we set that bit for a reason -- we found a situation (perhaps it was a particular server) where it didn't work without the "broadcast replies" bit set. Still, that was the last remaining bit of the puzzle. You'll notice that your captured packets 3 and 8 (OFFER replies from the server aimed at the two clients) have the same xid in (Wireshark: "Transaction ID"), but different chaddr (Wireshark: "Client MAC address"). The Empeg, utterly incorrectly, matches on the former but not the latter.

So I suspect that checking incoming UDP to port 68 (bootpc) and dropping on the floor (or scrambling the xid of) packets whose chaddr isn't ours, would fix the problem.

Peter

Yes, that certainly does seem to fix things.
Hijack v501 is now released, with this workaround incorporated.

Thanks, Peter!

Of course, I have hardcoded the packet offset for the client MAC address -- to match where my own DHCP server puts the data.

But I have no idea if it is *always* at that exact offset, or whether more intelligent parsing of the packet is necessary to ensure it works everywhere (?).

EDIT: A consequence of which, is that DHCP might not work for anyone but me.

Cheers

According to RFCs 951 & 2131, the offset is constant, so no worries.

But just in case someone wants to run a DHCP *server* on the empeg, it might be slightly safer to also check the bootp message type field as well.. as is now done in Hijack v502.

Cheers