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

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

I disgagree with your assumption it's a G-ARP. As you've said yourself
it's ill formatted as a G-ARP, and that is correct. It's used by some
DHCP clients to check if the DHCP OFFER is worth persuing. It could be
that multiple OFFERs come in and then you better select one that's
no-conflicting. Mind you, the THA still should be 0 or f.

I've seen this behaviour in the VxWorks DHCP client, so you will run into
this more often when using embedded devices.

Thanx,
Jaap

On Tue, 19 Dec 2006, Justin Shore wrote:

> Jaap,
>
> Thanks for the reply.  You've summed it up pretty well though I disagree
> with some of your conclusions.  3a and the subsequent 5 should not
> happen until after 4.  They're attempting to generate a gratuitous ARP
> before they've actually been assigned the IP.  The SPA can not be blank.
> It must be populated with a valid IP, something that can't happen until
> after 4.
>
> This lack of a valid IP is why the proxy ARP functionality of the DSL
> modem/router is kicking in.  It sees a ARP request for an MAC it has
> learned on the same physical wire as the requested MAC.  The DSL modem
> sends an arp reply with its own MAC as the SHA and the requested TPA as
> the SPA.  This allows the 2 hosts to communicate with each other in two
> different subnets overlayed on a single broadcast domain.  This is the
> very definition of proxy ARP.  Without a valid IP address for the SPA no
> proxy ARP daemon could distinguish between a sending host that can't
> access the requested MAC directly and one that can.
>
> Having thought about it further I don't believe the THA is part of the
> problem, though it is screwed up and should be fixed.  The THA is
> supposed to be blank or populated with the Ethernet frame's destination
> MAC (f's).  The THA they're using contains an unassigned OUI.  The wired
> version of the broadband router (I initially tested the wireless
> version) uses a similar THA.
>
> Essentially the DSL modem/router is functioning correctly if it's
> running a proxy ARP daemon.  The only problem with that device is that I
> can't disable proxy ARP.  The whole problem can be avoided if the
> BBRouter would delay its attempt at generating a gratuitous ARP until
> after 4 which is when can generate a valid gratuitous ARP (SPA = TPA,
> SHA is correct, THA is null).  I've sniffed the DHCP process of about a
> dozen different devices these past few days.  About half of them send a
> gratuitous ARP.  Only these 2 new broadband routers send these malformed
> gratuitous ARPs.
>
> The DSL modem/router manufacturer has been helpful so far.  I believe
> they will likely code a way to disable proxy ARP.  The broadband router
> manufacturer hasn't been quite as helpful.  They want us to work with
> the reseller we bought them from to troubleshoot the problem.  The
> reseller doesn't have that kind of knowledge and they can't fix a code
> problem on the manufacturer's devices.  The manufacturer did say that
> they would continue to work the problem on their end anyhow.  We have a
> few options that we can take at this point if need be.
>
> Thanks for the input
>  Justin
>
>
> -----Original Message-----
> From: wireshark-users-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Jaap Keuter
> Sent: Tuesday, December 19, 2006 3:33 AM
> To: Community support list for Wireshark
> Subject: Re: [Wireshark-users] Malformed Gratuitous ARP
>
> 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
> >
> >
>
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
>
>