[...]
Glynn Clements 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?
Here are the relevant excerpts of tcpdump (3.4a6), and no, _this_ parts
wasn't
patched (comments inserted):
print-ether.c:
int
ether_encap_print(u_short ethertype, const u_char *p,
u_int length, u_int caplen)
{
extracted_ethertype = ethertype;
switch (ethertype) {
case ETHERTYPE_IP:
ip_print(p, length);
return (1);
/* this way, both ethertypes are detected */
case ETHERTYPE_ARP:
case ETHERTYPE_REVARP:
arp_print(p, length, caplen);
return (1);
[CUT]
function arp_print in print-arp.c:
case ARPOP_REQUEST:
(void)printf("arp who-has %s", ipaddr_string(TPA(ap)));
[...]
break;
case ARPOP_REPLY:
(void)printf("arp reply %s", ipaddr_string(SPA(ap)));
[...]
break;
case REVARP_REQUEST:
(void)printf("rarp who-is %s tell %s",
etheraddr_string(THA(ap)),
etheraddr_string(SHA(ap)));
break;
case REVARP_REPLY:
(void)printf("rarp reply %s at %s",
etheraddr_string(THA(ap)),
ipaddr_string(TPA(ap)));
break;
[CUT]
> 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...
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...
The different ethertypes are proposed to ease the implementation of
different handlers
for ARP and RARP, but it seems not to be a must.
Any comments, suggestions, how to handle this in the kernel?!? (config
option?)
I'm wondering, that this glitch isn't better known/handled?
> --
> Glynn Clements <[EMAIL PROTECTED]>
Bye, Hans-Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]