Re: loopback IP alias breaks tftp?

[Eric Dumazet <eric.dumazet@gmail.com>]

Le vendredi 07 octobre 2011 à 18:02 +1100, Joel Sing a écrit :
> On 7 October 2011 00:23, Josh Boyer <jwboyer@redhat.com> wrote:
> >
> > On Thu, Oct 06, 2011 at 12:18:44AM +0300, Julian Anastasov wrote:
> > >
> > >       Hello,
> > >
> > > On Wed, 5 Oct 2011, Josh Boyer wrote:
> > >
> > > > Hi All,
> > > >
> > > > 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
> > > > the bug worked in 2.6.35, and broke somewhere before 2.6.38.6.
> > > >
> > > > I can confirm the steps fail on a 3.0 based kernel and I'm trying to do
> > > > a git bisect to find the commit involved, but I thought I would send
> > > > this along to see if anyone might have an idea.  (Also, I'm not really
> > > > sure how valid of a usecase this was to begin with.)
> > >
> > >       What about commit 9fc3bbb4a752f108cf096d96640f3b548bbbce6c ?
> > >
> > > ipv4/route.c: respect prefsrc for local routes
> > >
> > > http://marc.info/?t=129412232500001&r=1&w=2
> > >
> > > > [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