hpj wrote:
> > If tcpdump is reporting 0x0806 as `RARP', then its broken. I've never
> > encountered a tcpdump which did this? Has your tcpdump been `fixed' to
> > deal with your local convention?
>
> Believe it or not, but I _know_ dozens of (commercial) products, which either use
> this ethertype. And even more, which interoperate. The other way around, I don't
> know any system, which breaks. (Not only OS, also router, firewalls, etc...) And,
> as you can imagine, there is no way to fix them all?
OK. Having checked the details, i can see that it isn't actually that
hard to handle. Both ARP and RARP use the same packet format, and they
use different opcodes (ar_op field in `struct arphdr').
> Here are the relevant excerpts of tcpdump (3.4a6), and no, _this_ parts
> wasn't patched (comments inserted):
[snip]
OK, that makes sense. That code is using the opcode, and not the
ethernet frame type, which will produce the correct results for a
valid packet. It seems odd that it doesn't actually report the frame
type, though.
> > You should fix the clients to use 0x8035. A broadcast 0x0806 packet is
> > probably going to be passed to the ARP handler on every host on the
> > network. There's no telling what effect this will have.
>
> I believe, this misunderstanding arises from the fact, that the packet struct is
> identical to ARP and that ARP defines it's operational codes (1,2), where the RARP
> types follow (3, 4), and so forth...
Yep.
> There should be no problem with ARP (as you can see). A protocol
> handler has to check the opcode correctly, before doing anything.
> And everything, which doesn't fit, should be ignored...
Yep.
> The different ethertypes are proposed to ease the implementation of
> different handlers for ARP and RARP, but it seems not to be a must.
However, Linux has different handlers for ARP and RARP. The selection
is based upon the ethernet frame type. ETH_P_RARP (0x8035) frames are
passed to rarp_rcv() in rarp.c, while ETH_P_ARP(0x0806) are passed to
arp_rcv() in arp.c.
rarp_rcv() ignores anything which doesn't have an opcode of
ARPOP_RREQUEST (3). arp_rcv() seems to assume that everything that it
was passed is either an ARP request or reply.
> Any comments, suggestions, how to handle this in the kernel?!? (config
> option?)
I'm presuming that you could pass both types of packets to a function
which dispatches them to either arp_rcv() or rarp_rcv() based upon the
opcode. However, there may be other factors which I'm completely
overlooking.
You could start by grepping for dev_add_pack in arp.c/rarp.c, and
following the logic from there.
--
Glynn Clements <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
