netdev - Re: ipv4: broadcast sometimes leaves wrong interface (since commit e066008b38ca9ace1b6de8dbbac8ed460640791d)

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1322756728.12482.52.camel@icts-sp-039>
Date:	Thu, 01 Dec 2011 17:25:28 +0100
From:	Jeroen van Ingen <jeroen@...ndomein.nl>
To:	Julian Anastasov <ja@....bg>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: ipv4: broadcast sometimes leaves wrong interface (since commit
 e066008b38ca9ace1b6de8dbbac8ed460640791d)

Hi Julian, David,

> > > 	May be the solution is to convert inet_addr_lst
> > > from hlist to normal list, so that we can append new
> > > addresses at tail and __ip_dev_find to find the first
> > > device where IP was added.
> > 
> > Sure, but do we really want to guarentee this behavior forever?
> 
> 	I remember for such issue with ipsec%d interfaces
> years ago. May be the PPP servers should be configured
> to use another local IP for PPP devices because broadcasts
> and multicasts may need their own local address - they can use
> addresses to refer to output devices.
> 
> 	Not sure what else we can do, now we have to waste
> 1-2KB for this to work before someone recreates the eth
> addresses and changes the ordering.

FYI: we successfully tested two scenarios that provide a workaround with
the current kernel versions:

1) Explicitly configuring Radius to use one of the secondary IPs as
source for the DHCP broadcast. Since the IP we chose is only bound to
eth0, this broadcast goes out the correct interface. Other
system-generated broadcast would probably still go out the wrong
interface, but at least it allows us to accept more than one PPTP
client.

2) Adding an option to the "pppd" config, so the ppp-devices it creates
do not use the primary IP from eth0 but rather one of the secondary
addresses. This way we don't have to modify any other software that
might generate a broadcast.

While the second option provides a workable solution for us, we're still
under the impression that this change in behavior might cause a problem
for other users and/or configurations as well. We'll leave the rest of
the considerations to the real experts, while remaining curious about
the outcome :)

Thanks again for your assistance.

Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands

--
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