Local LAN Discovery Sends Multicast out eth0?

[2bluesc]

I observed a large number of packets from BitTorrent Sync's LAN discovery hitting my Linux firewall:

[31888.915645] [UFW BLOCK] IN=eth0 OUT= MAC= SRC=1.2.3.4 DST=239.192.0.0 LEN=126 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=3838 DPT=3838 LEN=106 

Running tcpdump at the same time displays the outgoing packets (and the firewall catches and blocks the return)

When I shut off "LAN Search" for all my shares, it instantly stops.

The problem with this is that my workstation running btsync is also my NAT router and WiFi AP, it has 3 interfaces:

• eth0 connected to the Internet
  
• eth1 connected to my LAN
  
• wlan0 wireless LAN, note this is on it's own subnet, not bridged with eth1
  

If I add the following route, the broadcasts immediately start getting sent out on eth1 where my LAN actually is:

ip route add 239.192.0.0/14 dev eth1

Is there anyway to configure this within BitTorrent Sync, for example select a LAN interface so I don't broadcast multicast stuff to all my cable modem neighbors and so that I actually discover devices on my LAN? This also prevented LAN discovery from working.

I imagine this could be a problem for laptops with Ethernet + WiFi, but they likely aren't both enabled at the same time.

[Shot2]

Same question here, btsync (1.1.27/Ubuntu12) binds to 0.0.0.0:3838 for I-don't-know-what reason, and there seems to be no way to prevent that weird behaviour. What is it for? How do you switch that off?

[GreatMarko]

There is currently no way to "select" which network interface Sync will use - essentially, it will use the first one it finds.

To "force" it to use a specific interface, you would need to temporarily disable the other interfaces before running Sync, so that Sync is left with no choice but to use the one remaining interface that hasn't been disabled.

Once Sync is running, you can then re-enable the other interfaces.

The ability to be able to choose which network interface Sync connects through has been suggested a couple of times, so be sure to add your voice for this feature to the wishlist.

[rdebath]

You don't "select an interface" for multicast.

Multicast routing is weird, you can't bind to an interface, you always bind to 0.0.0.0 and the routing demon take care of where the packets should (and should not) travel. AIUI if you're not running a multicast router demon the kernel has to assume that all the interfaces are equivalent.

I'm not sure, but I think Windows uses the "first" interface; you can reorder them by looking at your interfaces in Explorer and Selecting Advanced->Advanced. Linux OTOH I think just uses the default routing table, so "ip route add" is the right solution if you don't want to run a proper routing demon. (IPv6 is different because Link local scope has to work.)

I suppose you're actually thinking more of local broadcast, sending the packets to 192.168.1.255. It's a lot easier, but, in theory, not as versatile. In practice there are several multicast routing protocols and none of them always work, so normally there's little difference between multicast and local broadcast.

For practical firewalling, just block multicast from leaving or entering your "organisation" and don't bother logging it.

Oh, and be careful when mixing NAT and bridging, iptables will see packets going across the bridge and you don't want to NAT multicast packets by accident.