netdev - Re: loopback IP alias breaks tftp?

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]

Date:	Fri, 7 Oct 2011 07:40:18 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Joel Sing <jsing@...gle.com>, Julian Anastasov <ja@....bg>,
	netdev@...r.kernel.org
Subject: Re: loopback IP alias breaks tftp?

On Fri, Oct 07, 2011 at 09:29:33AM +0200, Eric Dumazet wrote:
> Le vendredi 07 octobre 2011 à 18:02 +1100, Joel Sing a écrit :
> > > > > We've had a report [1] of a change in behavior when trying to use an IP
> > > > > alias to tftp from a loopback device.  Apparently the steps outlined in
> > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=739534
> > >
> > > Yep.  That is exactly what my git bisect said too.
> > >
> > > So now we have a change in behavior since that commit for the usecase
> > > described in the bug above, but I'm unsure if that usecase was ever
> > > really valid or if the commit had unintentional side effects.
> > >
> > > Joel (or anyone else) can you take a look and comment?
> > 
> > Prior to this commit the src address in the local routing table was
> > completely ignored, so connecting to a local address always used the
> > same source and destination addresses. However, this is not what was
> > configured in the local routing table:
> > 
> >   $ ifconfig lo:0 127.0.0.2
> >   $ ip route show table local | grep 127.0.0.2
> >   local 127.0.0.2 dev lo  proto kernel  scope host  src 127.0.0.1
> > 
> > When an interface has an alias configured, the source address
> > installed in the local routing table is always the primary address for
> > the interface. The tftp use case you've described now breaks due to
> > the way that in.tftpd is determining the reply address (as documented
> > in the in.tftpd manual page). This means that it is now responding
> > from 127.0.0.1 even though the client connected to 127.0.0.2. Binding
> > inetd to a specific address will avoid this issue.
> > 
> > I have not yet looked to see if there is a specific reason for the
> > source address selection, however one way of restoring the previous
> > behaviour (whilst still respecting the configured source address)
> > would be to use a default source address which matches the configured
> > address (as is done for primary addresses). I cannot immediately think
> > of a reason not to do this, but I've not gone looking at the code.
> > 
> > Worst case scenario if you specifically need the original behaviour
> > then the source address can be changed in the local routing table:
> > 
> >   $ ip route change table local local 127.0.0.2 dev lo:0 proto kernel
> > scope host src 127.0.0.2
> >   $ ip route show table local | grep 127.0.0.2
> >   local 127.0.0.2 dev lo  proto kernel  scope host  src 127.0.0.2
> 
> Agreed.
> 
> The "table local" bit is really the key, because following naive setup
> doesnt work.
> 
> # ip addr add 127.0.0.11/8 dev lo
> # ip route add 127.0.0.11 dev lo src 127.0.0.11
> 
> since 127.0.0.1 will still be the src address selected for connections.
> 
> # ip ro show table local | grep 127.0.0.11
> local 127.0.0.11 dev lo  proto kernel  scope host  src 127.0.0.1 

The original bug reporter explained the loopback testcase is simply a
trivial example to illustrate the problem.  The real setup seems to be:

"I have a hardware (Dell PC) booting over the network with PXE, this
hardware try to load it system from a tftp server. If I used the real
ip of the tftp server I have no problem, if I used an alias I have the
problem (I have to use an alias, because I have a Cluster).

What I think, the bios tftp client talk to the server with the IP alias
but the server reply with the real IP and the client reject the reply."

So in this case, because the alias is being used in a cluster, should he
also setup the local routing table as you suggested?

I apologize for my lack of depth here.  I'm at the moment somewhat of a
go-between.  I do greatly appreciate the help!

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