hpj wrote:
> >> 54:#define ETH_P_RARP 0x8035 /* Reverse Addr Res
> >> packet */
> >> fgr: ETH_P_RARP found in ./linux/if_ether.h
> >
> >Imagine, it is correct 8)
>
> Okay, I agree now (-> RFC 1700, Assigned numbers, line 9399 and RFC 903,
> RARP)
>
> But unfortunately, a couple of years ago, I implemented the
> RARP-protocol after
> a german book, describing TCP/IP, which said: the ether-type of RARP is
> the same as
> ARP: 0x806. This was for a IP-conforming, but proprietary network
> filesystem protocol
> called BioNet, clients mostly running Atari ST/TT/etc (Servers: mostly
> DOS). The
> server is working on Linux now, but the RARP-stuff isn't, as you can
> imagine (before
> the patch).
>
> Now i realized, this is wrong. But investigating this with tcpdump, this
> program
> identifies our wrong (ethertype 0x806 instead of 0x8035) packets
> "correctly" as RARP!
>
> Is this a tcpdump parser or a common ethernet packet failure?
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?
> If it is network failure (as I think of), how this is handled commonly
> (without
> breaking the old "wrong" stuff)?
>
> Should I patch the rarp module to wait for both types (don't know, if
> this is possible
> either), or build a biorarpd in userspace (which may happens anyway,
> cause we also
> do some kind of (also non standard) dynamic address assignment, there)?
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.
--
Glynn Clements <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
