Thanx geeks,
>> 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 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)?
Please suppress flaming about these silly hackings, I hate them, too!!!
Thanks for your help,
Hans-Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
