[AG-TECH] Windows, Rat, and multiple interfaces

[Robert Olson]

Howdy folks --

We've been seeing growing problems with rat and Windows boxes with multiple 
network interfaces. The symptom of the problem is that rat would not appear 
when launched, and leave a ratui.exe process hanging about.

I've fixed rat to handle this situation properly; this new rat will be 
available with 2.1.2 and as a separate (informal) zipfile release for those 
who need it in that form.

In the short time I've been poking at this, we've come across a couple 
failure modes that aren't really the fault of the rat code, but that cause 
it to fail nonetheless. This note will discuss these problems and their 
solutions.

I'll digress with a bit of network routing discussion first. If you have 
multiple network interfaces, the OS has to decide how to route traffic 
properly to these addresses. It uses a routing table for this. For example, 
my laptop here at MCS is currently on both the wired and wireless network. 
The routing table looks like this:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
           0.0.0.0          0.0.0.0    140.221.34.61   140.221.34.35       20
           0.0.0.0          0.0.0.0   140.221.57.253  140.221.57.128       30
         127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     140.221.34.32  255.255.255.224    140.221.34.35   140.221.34.35       20
     140.221.34.35  255.255.255.255        127.0.0.1       127.0.0.1       20
      140.221.56.0    255.255.254.0   140.221.57.128  140.221.57.128       30
    140.221.57.128  255.255.255.255        127.0.0.1       127.0.0.1       30
   140.221.255.255  255.255.255.255    140.221.34.35   140.221.34.35       20
   140.221.255.255  255.255.255.255   140.221.57.128  140.221.57.128       30
         224.0.0.0        240.0.0.0    140.221.34.35   140.221.34.35       20
         224.0.0.0        240.0.0.0   140.221.57.128  140.221.57.128       30
   255.255.255.255  255.255.255.255    140.221.34.35   140.221.34.35       1
   255.255.255.255  255.255.255.255   140.221.57.128  140.221.57.128       1
Default Gateway:     140.221.34.61

We'll concentrate on the multicast routes first, as those are what affect 
rat. They are these:

         224.0.0.0        240.0.0.0    140.221.34.35   140.221.34.35       20
         224.0.0.0        240.0.0.0   140.221.57.128  140.221.57.128       30

This means to route traffic destined for 224.0.0.0 (the multicast address 
range) via either 140.221.34.35 (my wired interface) or 140.221.57.128 (my 
wireless interface). The choice between them is made based on the routes' 
metric - 20 for the wired, and 30 for the wireless. Lower metric values 
take precedence, so my laptop will be using wired net for outgoing 
multicast traffic.

There is an additional consideration in the case of multicast where the 
code that configures multicast sockets for the apps (rat in this case) 
apparently, on Windows, needs to know the interface on which multicast 
traffic is to be sent. The fixes made today use the Win32 IP Helper API to 
determine the interface on which multicast traffic will flow, and configure 
the sockets accordingly. This information comes from the routing table, as 
we discussed above.

This leads to the problems we've seen. In one, a Cisco VPN software 
installation failure apparently left a stray VPN interface configured and 
enabled, which caused the multicast route to point out the VPN interface, 
which of course didn't lead anywhere. Hence, rat failed.

In the other (on the same machine as it happens), the interface metric for 
the wireless network was hardcoded. Apparently, some wireless drivers do 
this, which causes the routing table to prefer the wireless network to the 
wired network. It is often the case that a site that has wireless 
networking will disable multicast on that network; if this is case, and if 
the metrics are wrong, rat may come up but not see any multicast traffic.

The fix for this is to inspect the network interface settings. On XP, bring 
up the network connections panel, right-click an interface, select 
Properties, scroll down to "Internet Protocol (TCP/IP)", click Properties, 
click Advanced, and ensure that "Automatic Metric" is checked.

When this has been done on all interfaces, Windows should assign the lowest 
metric to the fastest network connection. See the following article for 
more information on this.

http://www.winnetmag.com/MobileWireless/Article/ArticleID/24163/MobileWireless_24163.html

Microsoft's knowledge base also has this:

http://support.microsoft.com/default.aspx?scid=kb;en-us;299540

Ah, this is an XP-only thing. If folks have problems with this on Win2k, 
please drop me a note and we can figure something out. It appears that 
metrics can be manually set there for the appropriate behavior. (Yes, 
that's the case. I just verified that with my Win2k box that has a couple 
VMWare interfaces configured that in the past had always interfered with rat).

http://support.microsoft.com/default.aspx?scid=kb;EN-US;258487

--bob