["Justin Shore" <justin.shore@xxxxxxxxxx>]

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