[Background for those who are coming in in the middle: we use the Cisco VPN
for offsite access at ANL; it has always caused problems with using rat].
In looking at debug output from another libcommon app, I realized what the
problem has been with rat and the VPN.
The libcommon code I added to make it deal properly with multiple network
interfaces on Windows works by querying the system for the best route to
use for a multicast address, and then binds the UDP sockets to that address.
If you look at the routing table when the VPN is up you'll find something
like this:
224.0.0.0 240.0.0.0 140.221.18.101 140.221.18.101 10
224.0.0.0 240.0.0.0 192.168.1.13 192.168.1.13 10
224.0.0.0 240.0.0.0 192.168.200.200 192.168.200.200 30
(The first row is the VPN route, the second is the local network, and the
third is "MS Loopback" interface that Justin pointed me at that you can
install via the device mgr - gives you a live interface in the absence of
actual network. Required for doing development of this sort offline).
The last column is the interface metric; note that the VPN and the local
network have the same metric; this means that the route chosen is chosen
arbitrarily between the two. And in fact, windows chooses the VPN route, so
rat will use that route as well.
If you bring up the properties panel for the VPN interface, and click
through to the advanced settings for TCP/IP, you find a checkbox for
"Automatic metric". Uncheck that, and set a metric > 10 (I used 15). Now,
the routing table looks like this:
224.0.0.0 240.0.0.0 140.221.18.101 140.221.18.101 15
224.0.0.0 240.0.0.0 192.168.1.13 192.168.1.13 10
224.0.0.0 240.0.0.0 192.168.200.200 192.168.200.200 30
and rat and windows will choose the local network interface for routing
multicast, and things should be happier. I've not yet tried this on a
network with live multicast, but I suspect it should work.
--bob
