Source-Route on local ring

["Gilbert Ramirez Jr." <gram@verdict.uthscsa.edu>]

After using LanAlyzer (a packet-sniffer program for Windows), I
noticed some strange packets leaving my NIC. (Olicom TR, but this has to
do with the Linux Token-Ring layer, not the oltr device driver). I have
confirmed these packets with tcpdump also, but will show the LanAlyzer
trace below.

   0: 18 40 6C 00 19 C9 0E 8D 80 00 83 2D 53 A7 A2 20 |.@l........-S..
  10: AA AA 03 00 00 00 08 00 45 00 00 42 8C C8 00 00 |........E..B....
  20: 40 11 A3 72 C0 A8 2C 63 C6 42 97 22 05 4E 00 35 |@..r..,c.B.".N.5
  30: 00 2E 3E BB 6F 69 01 00 00 01 00 00 00 00 00 00 |..>.oi..........
  40: 0D 55 48 53 5F 55 48 4D 41 49 4C 5F 30 31 06 75 |.UHS_UHMAIL_01.u
  50: 68 73 63 69 73 00 00 01 00 01                   |hscis.....

Explanation. My Linux box is the source, hwaddr 00-00-83-2d-53-a7. The
destination hwaddr is my router, 6c-00-19-c9-0e-8d. This is a simple IP
packet that's leaving my machine and going to my default gateway to be
delivered somewhere else. The gateway's hwaddr *is* in my arp cache
(verified by `arp -a`), but the packet is being source routed. Bytes 0x1e
and 0x1f are the RCF... they show only two bytes of routing information,
which are the RCF bytes themselves. The LanAlyzer analysis shows  the same
thing... RCF, but no route/bridge pairs:


Length : 94 bytes
802.5: =================== IEEE 802.5 Datalink Layer ===================
       AC: Frame, Priority=0, Monitor Count=1, Priority Reservation=0
       FC: LLC Frame, Attention Code=0
       Station: 00-00-83-2D-53-A7 ----> 6C-00-19-C9-0E-8D
       Source Routing Information:
         Length: 2 bytes
         Broadcast: Value 5 is undefined
         Direction: From originating station
         Largest Frames: 2052 bytes (LF=2)
802.2: ================ IEEE 802.2 Logical Link Control ================
       SSAP: SNAP     DSAP: SNAP
       Unnumbered Command: Unnumbered Information (UI)
       SNAP Organization Code: 00 00 00
       SNAP Protocol Type: 0x0800 (IP)
   ip: ======================= Internet Protocol =======================
       Station:192.168.44.99 ---->198.66.151.34
       Protocol: UDP

(etc.. its analyzes the packet down the level of the query being sent to
DNS).

This happens for every single IP packet that I send through my default
gateway. I've compiled in the source-route patch from P. Norton to look at
my rif table through /proc/net/tr_rif, and indeed, my router is not in my
RIF table. Am I right in thinking that it doesn't have to be, because my
router is in my arp cache?

I've done some debugging, and tr_source_route is being called from
tr_rebuild_header. tr_rebuild_header looks like it checks to see if the
destination is in the arp cache, and if it's not, then it tries a source
route. My default gateway is not in the RIF table, so linux-tr sends a
source-route broadcast.

Here's my arp-cache:
Address                 HWtype  HWaddress           Flags Mask Iface
192.168.44.254          tr      6C:00:19:C9:0E:8D   C     *    eth0

My interface is eth0 because oltr uses "eth0" instead of "tr0", because of
some name problems when both oltr and ibmtr are used at the same time. This
should not matter, since the hwtype is known as token-ring.

Everything works, I have perfect IP connectivity. But it bothers me that
linux-tr is source-routing my outgoing packets when it looks like it is
unnecessary. I could save 2 bytes per packet if I didn't have to
source-route. :-)

Questions: Can someone replicate this on an ibmtr or mtok machine? (i'll be
able to try it at work sometime)
Am I right in thinking that these packets to my default gateway
should not be source-routed. And if I am, does anyone have any ideas where
linux-tr is failing?

thanks,

--gilbert

-- 
Gilbert Ramirez                Voice:  +1 210 358 4032
Technical Services             Fax:    +1 210 358 1122
University Health System       San Antonio, Texas, USA