lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 Jan 2014 16:08:11 -0200 From: Flavio Leitner <fbl@...hat.com> To: "Steinar H. Gunderson" <sgunderson@...foot.com> Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>, netdev@...r.kernel.org Subject: Re: IGMP joins come from the wrong SA/interface On Thu, Jan 30, 2014 at 11:47:09AM +0100, Steinar H. Gunderson wrote: > On Mon, Jan 20, 2014 at 07:40:25PM +0100, Steinar H. Gunderson wrote: > >> I currently only remember one commit 0a7e22609067ff ("ipv4: fix > >> ineffective source address selection") which did affect multicast source > >> address selection in recent times. > > I tried 3.10.27, just to check something older. I also tried 3.10.27 with > > 0a7e22609067ff reverted, and it's still wrong. > > > > I am thinking this might have something to do with the machine switching to > > systemd, presumably changing the order of DHCP and static addresses being > > assigned... > > Anything more I can do here? I've tried with net-next kernel 3.13.0-08598-g77d143d and it seems to be working fine here. No special multicast route, so it should go out on em1/default route. # ip route default via 192.168.0.1 dev em1 proto static metric 1024 10.0.0.0/24 dev vlan10 proto kernel scope link src 10.0.0.1 192.168.0.0/24 dev em1 proto kernel scope link src 192.168.0.2 It looks correct: [root@...x ~]# ip route get 224.0.0.11 multicast 224.0.0.11 dev em1 src 192.168.0.2 cache <local,mc> Looks good: [root@...x ~]# tcpdump -i em1 -n -nn -vv tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes 15:43:01.404504 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) 192.168.0.2 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.11 to_ex { }] then adding the multicast route: # ip route add multicast 224.0.0.0/4 dev vlan10 src 10.0.0.1 # ip route flush cache Checking: # ip route get 224.0.0.11 multicast 224.0.0.11 dev vlan10 src 10.0.0.1 cache <mc> Finally: [root@...x ~]# tcpdump -i vlan10 -n -nn -vv tcpdump: listening on vlan10, link-type EN10MB (Ethernet), capture size 65535 bytes 15:44:00.856478 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA)) 10.0.0.1 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 224.0.0.11 to_ex { }] Maybe your application is using wrong values to IP_MULTICAST_IF? strace and /proc/net/igmp as suggested might help you find out. fbl -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists