On Mon, Oct 16, 2000 at 06:48:26PM +0300, Paul Ionescu wrote:
> Hello,
>
> I have attached to this email a short capture of a token ring frame
> which is decoded as source routed but the frame is not source routed.
>
> This must be a bug in interpreting the RII bit in the source address
> field.
>
> To be more convinced one could download the dualhome.cap.gz capture from
> sample captures page of ethereal and filter on "tr.rif" and see that it
> does not find any frame with rifs but there are for sure some frames
> with rif.
>
> I tried to look into the "packet-tr.c" file to find the bug, but instead
> of finding the bug I found that token ring dissector tries to correct
> some bugs from linux kernels 2.0.x and from other strange OS-es.
Actually, the only strange OS it tries to work around is Linux. :)
The offending code starts at line 365:
/* sometimes we have a RCF but no RIF... half source-routed? */
/* I'll check for 2 bytes of RIF and the 0x70 byte */
if (!source_routed && trn_rif_bytes > 0) {
if (trn_rif_bytes == 2) {
source_routed = 1; /* <--- this line is affecting you */
}
....
> Maybe would be a better idea to split the file in two separate files:
> one for the old linux kernel 2.0.x with all the possible bugs in it, and
> one clean packet-tr.c file for newer kernels and other platforms.
> And the selection between the two files would be at compile time, if the
> kernel is 2.0.x then include the work-around file,if not then include
> the plain file.
But what if I make a packet capture using linux 2.0.x and send it to you, and you happen
to use Solaris? The weird OS-detection stuff has to be compiled in for all platforms.
Tonight I'll look through my old token-ring (linux 2.0.x) captures and see if I can't
decide on a better heuristic that accomodates all traces.
thanks,
--gilbert