Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Page 2 of 2 < 1 2
Topic Options
#309160 - 15/04/2008 19:39 Re: Bugs in V3 A11 [Re: peter]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14466
Loc: Canada
Originally Posted By: peter
For now (and there aren't AFAICT all that many users of Receiver Edition) it'll have to be the workarounds.


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

Top
#312819 - 09/08/2008 10:11 Re: Bugs in V3 A11 [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14466
Loc: Canada
Originally Posted By: mlord
Originally Posted By: peter
For now (and there aren't AFAICT all that many users of Receiver Edition) it'll have to be the workarounds.


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 ?

Top
#312824 - 09/08/2008 13:22 DHCP trace from car2-v3alpha11 [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14466
Loc: Canada
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.


Attachments
wireshark.png

Description: Screen capture

v3a11_dhcp_trace.bin (582 downloads)
Description: tcpdump format output from wireshark.




Edited by mlord (09/08/2008 13:26)

Top
#312825 - 09/08/2008 13:35 Re: DHCP trace from car2-v3alpha11 [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14466
Loc: Canada
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


Edited by mlord (09/08/2008 13:37)

Top
#312826 - 09/08/2008 13:43 Re: DHCP trace from car2-v3alpha11 [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14466
Loc: Canada
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

Top
#312827 - 09/08/2008 13:58 Re: DHCP trace from car2-v3alpha11 [Re: mlord]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4169
Loc: Cambridge, England
Originally Posted By: mlord
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.

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


Edited by peter (09/08/2008 14:05)
Edit Reason: chaddr, obviously, not ciaddr

Top
#312830 - 09/08/2008 19:25 Re: DHCP trace from car2-v3alpha11 (Hijack v501) [Re: peter]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14466
Loc: Canada
Originally Posted By: peter
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.


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

Thanks, Peter!

Top
#312831 - 09/08/2008 19:29 Re: DHCP trace from car2-v3alpha11 (Hijack v501) [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14466
Loc: Canada
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. smile

Cheers

Top
#312832 - 09/08/2008 20:14 Re: DHCP trace from car2-v3alpha11 (Hijack v502) [Re: mlord]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 14466
Loc: Canada
Originally Posted By: mlord
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 (?).

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


Edited by mlord (10/08/2008 11:17)

Top
Page 2 of 2 < 1 2