[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Source-Route on local ring



Gilbert Ramirez Jr. writes:
 > 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?

The RIF table is always updated, whether the frame is from an
interface in the local ring or if it's from across one or more
source-routing bridges. So your router should have an entry in the RIF
table (provided it hasn't already expired) and it should show up as a
local route, i.e. no RIF necessary since it's on the local ring. 

 > 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. :-)

It shouldn't try to source-route the frames once it is determined that
the interface is on the local ring, such as your default
router. That's why we keep local interfaces in the RIF cache as well
as source-routed interfaces.  

 > 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?

I'm not sure why your default router isn't showing up in your RIF
cache. I'll need to look at the Olicom code to see if it affects
anything in that respect since on my network at home everything shows
up as local and isn't being source-routed. 

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