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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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