Wireshark · Wireshark-users: Re: [Wireshark-users] Malformed Gratuitous ARP

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

Oke, let sum this thing up:
1. DHCP DISCOVER from BBrouter
2. DHCP OFFER from ATMrouter to BBrouter
3a. ARP request(?) (SHA=BBrouter, SPA=NULL, THA=?, TPA=DHCP OFFER)
3b. DHCP REQUEST from BBrouter
4. DHCP ACK from ATMrouter
5. ARP reply (SHA=DSLmodem, SPA=DHCP OFFER, THA=BBrouter, TPA=NULL)
6. DHCP DECLINE from BBrouter

These are the steps described below, if I read them correctly.

So what does it all mean.
1 and 2 are straight forward DHCP transaction packets.
3a is used to check the local network to see if the IP address is already
in use. The THA is the only troublesome field, is it the same in the
Ethernet header?
3b is usually delayed until an ARP reply is to be expected. If there's
no reply, no conflict is detected. If there's a reply a conflict is there
and the address lease is not requested.
4 is a normal transaction based on 3b.
5 is a reply from the proxy ARP function in the DSLmodem
6 is the BBrouter pulling back from the lease

Is the proxy ARP spooked by the THA in the ARP request? Is the THA really
unknown in the network or related to some device, configuration or
whatever?

Thanx,
Jaap

On Mon, 18 Dec 2006, Justin Shore wrote:

> I stumbled across an unusual problem with a new series of broadband
> routers.  This particular product line absolutely will not work behind a
> certain model of DSL modem/router we use but will work behind the
> previous versions just find.  After sniffing the traffic in a number of
> scenarios I believe I have found the problem.  The broadband router does
> a DHCP DISCOVER and gets a DHCP OFFER from our ATM router.  It
> immediately ARPs for the IP address from the DHCP OFFER (more on this in
> a second).  At the same time it sends the DHCP REQUEST and receives the
> subsequent DHCP ACK.  The ARP it sent our is malformed.  The SHA is
> correct but the SPA is set to 0.0.0.0.  The TPA is the IP from the DHCP
> OFFER.  The THA is an bogus Ethernet MAC such as 40:47:40:47:40:47 or
> c0:a8:40:47:40:47.
>
> (For those that don't understand the ARP acronyms above refer to this
> page:)
>
> http://en.wikipedia.org/wiki/Address_Resolution_Protocol
>
> This is a invalid ARP request.  The SPA is always supposed to be the
> valid SPA for host, not 0.0.0.0.  The THA is supposed to be 0 or f.  I
> believe they're trying to do a gratuitous ARP.  However they can't do a
> G-ARP at this stage of the DHCP exchange because they haven't yet sent
> the DHCP REQUEST and received the DHCP ACK (so they don't yet have an
> IP).  A gratuitous ARP uses an identical SPA and TPA with the correct
> THA.  The only field not populated with known data is the THA and it's
> supposed to be populated with 0s or Fs.  You can't simply make up a THA.
>
>
> The end result is that the broadband router receives a reply to its ARP
> and immediately sends a DHCP DECLINE.  Now let me explain something
> about the ARP reply it receives.  It appears that the DSL modem/router
> has a builtin proxy-ARP function.  It replies to the ARP request with a
> reply that sets the THA the DSL modem's MAC and uses the TPA from the
> ARP request as the SPA for the reply packet.  The TPA is 0.0.0.0 and the
> THA is the original SHA.  I haven't found a way to disable the proxy ARP
> functionality in this modem.  It did not do this in the older models.
> This is part of the problem but under normal circumstances isn't a
> problem at all.  The broadband router's invalid usage of ARP causes the
> whole problem.  I believe this is the result of a proxy ARP
>
> Am I understanding this correctly?  I've been working on this all
> weekend.  It's ARP; there are only so many different ways in which you
> can use ARP.  I have packet dumps from both new models of the broadband
> routers on both the problematic modem and the older modem.  I also have
> similar packet dumps from the previous model of broadband router on both
> modems.
>
> Can anyone doublecheck my work and theory?  I'm trying to engage both
> vendors to resolve this problem.  I'm at a loss for any other
> explanation at this point though.
>
> Thanks
>  Justin
>
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
>
>