Terry T
2016-May-13 16:06 UTC
Bridge not forwarding multicast traffic to the tap interface
I have a Debian 8 64-bit machine set up as a server and apt-got the tinc
package. I configured tinc as a bridge and everything seems normal except
that the tunnel does not forward multicast traffic.
I used tcpdump to examine the br0, eth0 and tap interfaces. I could see
multicast packets on both br0 and eth0, but there is no such packet present
on the tap interface. I don't quite know why that is.
br0 Link encap:Ethernet HWaddr 7a:22:d7:1b:04:2e
inet addr:10.10.189.254 Bcast:10.10.189.255 Mask:255.255.255.0
inet6 addr: fe80::d227:88ff:fee5:2078/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3569 errors:0 dropped:0 overruns:0 frame:0
TX packets:2773 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1125028 (1.0 MiB) TX bytes:429677 (419.6 KiB)
eth0 Link encap:Ethernet HWaddr d0:27:88:e5:20:78
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:56890 errors:0 dropped:0 overruns:0 frame:0
TX packets:2869 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:26184692 (24.9 MiB) TX bytes:444021 (433.6 KiB)
tap0 Link encap:Ethernet HWaddr ae:a2:e1:cd:aa:68
inet6 addr: fe80::aca2:e1ff:fecd:aa68/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2336 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:1015186 (991.3 KiB)
bridge name bridge id STP enabled interfaces
br0 8000.7a22d71b042e no eth0
tap0
Samples of the tcpdump on the bridge.
root at lionrock:/home/terry# tcpdump -i br0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:03:04.185117 IP 10.10.189.254.30022 > 116.19.81.143.53880: Flags [P.],
seq 3950669668:3950669856, ack 1682193163, win 317, options [nop,nop,TS val
425064 ecr 4674355], length 188
00:03:04.242176 IP 116.19.81.143.53880 > 10.10.189.254.30022: Flags [.],
ack 188, win 1066, options [nop,nop,TS val 4674385 ecr 425064], length 0
00:03:04.269393 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 211
00:03:04.292112 IP 10.93.112.115.47978 > 224.10.86.1.2013: UDP, length 11
00:03:04.385814 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:04.406215 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:04.420350 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:04.422856 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:04.424661 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
root at lionrock:/home/terry# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:03:48.657143 IP 10.10.189.254.30022 > 116.19.81.143.53880: Flags [P.],
seq 3950676648:3950676836, ack 1682193487, win 317, options [nop,nop,TS val
436182 ecr 4685479], length 188
00:03:48.715103 IP 116.19.81.143.53880 > 10.10.189.254.30022: Flags [.],
ack 188, win 1313, options [nop,nop,TS val 4685503 ecr 436182], length 0
00:03:48.754522 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:48.769103 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
00:03:48.872717 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 361
00:03:48.941631 IP 10.68.150.37.54718 > 224.10.86.7.2014: UDP, length 11
00:03:48.993608 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 461
00:03:49.012100 IP 10.93.112.115.45907 > 224.10.86.3.2014: UDP, length 11
00:03:49.105880 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 161
00:03:49.115551 IP 10.68.150.38.59286 > 224.10.86.7.2003: UDP, length 11
00:03:49.155296 IP 10.93.112.51.57244 > 224.10.86.1.2001: UDP, length 1011
root at lionrock:/home/terry# tcpdump -i tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:04:41.417898 IP 10.10.189.1 > all-systems.mcast.net: igmp query v2
00:04:41.494373 IP 10.10.189.254.ntp > 10.10.189.255.ntp: NTPv4, Broadcast,
length 48
00:04:44.529568 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, Hello,
length 38
00:04:47.132901 IP 10.10.189.101 > 239.255.255.250: igmp v2 report
239.255.255.250
00:04:57.828645 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, DF Election,
length 20
00:04:57.828689 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, DF Election,
length 20
00:04:57.828847 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, DF Election,
length 20
00:04:57.828906 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, DF Election,
length 20
00:05:13.927163 IP 10.10.189.1 > pim-routers.mcast.net: PIMv2, Hello,
length 38
00:05:16.146586 IP 10.10.189.101.netbios-dgm > 10.10.189.255.netbios-dgm:
NBT UDP PACKET(138)
This really got me stumped. I've searched high and low for a clue but
haven't really come across with anything that helps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20160514/d4b4817e/attachment.html>
Guus Sliepen
2016-May-13 17:24 UTC
Bridge not forwarding multicast traffic to the tap interface
On Sat, May 14, 2016 at 12:06:51AM +0800, Terry T wrote:> I have a Debian 8 64-bit machine set up as a server and apt-got the tinc > package. I configured tinc as a bridge and everything seems normal except > that the tunnel does not forward multicast traffic.Did you enable forwarding (echo 1 >/proc/sys/net/ipv4/ip_forward) and allow forwarding in your iptables rules? -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160513/237b8384/attachment.sig>
Terry T
2016-May-13 17:27 UTC
Bridge not forwarding multicast traffic to the tap interface
yes, ip_forward was turned on. iptables is defaulted to ACCEPT policy on all the 3 chains. On Sat, May 14, 2016 at 1:24 AM, Guus Sliepen <guus at tinc-vpn.org> wrote:> On Sat, May 14, 2016 at 12:06:51AM +0800, Terry T wrote: > > > I have a Debian 8 64-bit machine set up as a server and apt-got the tinc > > package. I configured tinc as a bridge and everything seems normal except > > that the tunnel does not forward multicast traffic. > > Did you enable forwarding (echo 1 >/proc/sys/net/ipv4/ip_forward) and > allow forwarding in your iptables rules? > > -- > Met vriendelijke groet / with kind regards, > Guus Sliepen <guus at tinc-vpn.org> > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160514/3f381b11/attachment.html>
Liang Guo
2016-May-14 06:54 UTC
Bridge not forwarding multicast traffic to the tap interface
> tap0 Link encap:Ethernet HWaddr ae:a2:e1:cd:aa:68 > inet6 addr: fe80::aca2:e1ff:fecd:aa68/64 Scope:Link > UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2336 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 B) TX bytes:1015186 (991.3 KiB) > > bridge name bridge id STP enabled interfaces > br0 8000.7a22d71b042e no eth0 > tap0 >tap0 RX packets is 0, can you double check your tinc config is correct? You'd better remove tap0 from br0, configure sufficient ip address on tap0, then check the connection with other tinc nodes. -- Liang Guo http://guoliang.me/
Terry T
2016-May-22 07:10 UTC
Bridge not forwarding multicast traffic to the tap interface
As it turns out, it's a bug in the igmp snooping code in the kernel that's the problem with multicast traffic not being forwarded. This seems to affect recent versions. To check if it's turned on, run cat /sys/devices/virtual/net/<bridgename>/bridge/multicast_snooping If it's 1, it's highly this is the culprit causing the non-propagation of the multicast traffic. The solution is to turn it off by setting it 0. echo 0 > /sys/devices/virtual/net/<bridge name>/bridge/multicast_snooping On Sat, May 14, 2016 at 2:54 PM, Liang Guo <bluestonechina at gmail.com> wrote:> > tap0 Link encap:Ethernet HWaddr ae:a2:e1:cd:aa:68 > > inet6 addr: fe80::aca2:e1ff:fecd:aa68/64 Scope:Link > > UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:2336 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:500 > > RX bytes:0 (0.0 B) TX bytes:1015186 (991.3 KiB) > > > > bridge name bridge id STP enabled interfaces > > br0 8000.7a22d71b042e no eth0 > > tap0 > > > > tap0 RX packets is 0, can you double check your tinc config is correct? > > You'd better remove tap0 from br0, configure sufficient ip address on > tap0, then check the connection with other tinc nodes. > > -- > Liang Guo > http://guoliang.me/ > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160522/3e5d3109/attachment.html>