loopback IP alias breaks tftp?

loopback IP alias breaks tftp?

[Josh Boyer]

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

[1] https://bugzilla.redhat.com/show_bug.cgi?id=739534

josh

Re: loopback IP alias breaks tftp?

[Julian Anastasov]

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

Regards

--
Julian Anastasov <ja@ssi.bg>

Re: loopback IP alias breaks tftp?

[Josh Boyer]

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?

josh

Re: loopback IP alias breaks tftp?

[Joel Sing]

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

Re: loopback IP alias breaks tftp?

[Eric Dumazet]

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 

Re: loopback IP alias breaks tftp?

[Josh Boyer]

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

Re: loopback IP alias breaks tftp?

[Eric Dumazet]

Le vendredi 07 octobre 2011 à 07:40 -0400, Josh Boyer a écrit :

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

Its a completely different problem IMHO : You describe a tftp server
bug.

Say your tftp server is multihomed with 3 different IPS : 

192.168.20.21, 192.168.20.22, 192.168.20.23

And tftp server listens to any address (UDP port 69) : 0.0.0.0:69

When receiving a request on 192.168.20.22, it should use same source
address, not let the system chose a "random or whatever policy" one.



So I would suggest to check/fix if TFTP server uses the correct socket
API to get both the client IP and its own IP in each UDP datagram

-> setsockopt(fd, IPPROTO_IP, &on, sizeof(on))

       IP_PKTINFO
              Pass  an  IP_PKTINFO  ancillary message that contains a pktinfo structure that supplies some
              information about the incoming packet.  This only works for datagram oriented sockets.   The
              argument  is a flag that tells the socket whether the IP_PKTINFO message should be passed or
              not.  The message itself can only be sent/retrieved as control message with a  packet  using
              recvmsg(2) or sendmsg(2).

                  struct in_pktinfo {
                      unsigned int   ipi_ifindex;  /* Interface index */
                      struct in_addr ipi_spec_dst; /* Local address */
                      struct in_addr ipi_addr;     /* Header Destination
                                                      address */
                  };

              ipi_ifindex  is  the unique index of the interface the packet was received on.  ipi_spec_dst
              is the local address of the packet and ipi_addr is the destination  address  in  the  packet
              header.  If IP_PKTINFO is passed to sendmsg(2) and ipi_spec_dst is not zero, then it is used
              as the local source address for the routing table lookup and for setting up IP source  route
              options.  When ipi_ifindex is not zero, the primary local address of the interface specified
              by the index overwrites ipi_spec_dst for the routing table lookup.



This permits tftp server to use the same "struct in_pktinfo" for replies, forcing a correct source address.

Re: loopback IP alias breaks tftp?

[Eric Dumazet]

Le vendredi 07 octobre 2011 à 14:04 +0200, Eric Dumazet a écrit :

> Its a completely different problem IMHO : You describe a tftp server
> bug.
> 
> Say your tftp server is multihomed with 3 different IPS : 
> 
> 192.168.20.21, 192.168.20.22, 192.168.20.23
> 
> And tftp server listens to any address (UDP port 69) : 0.0.0.0:69
> 
> When receiving a request on 192.168.20.22, it should use same source
> address, not let the system chose a "random or whatever policy" one.
> 
> 
> 
> So I would suggest to check/fix if TFTP server uses the correct socket
> API to get both the client IP and its own IP in each UDP datagram
> 
> -> setsockopt(fd, IPPROTO_IP, &on, sizeof(on))

> This permits tftp server to use the same "struct in_pktinfo" for replies, forcing a correct source address.
> 

By the way, there is no need for tftp change :

Just launch several tftpd instances, and bind each them to one
particular IP.

If started from xinetd.d :

$ cat /etc/xinetd.d/tftp1
service tftp
{
	socket_type		= dgram
	protocol		= udp
	wait			= yes
	user			= root
	server			= /usr/sbin/in.tftpd
	server_args		= -s /tftpboot
	disable			= no
	bind		= 192.168.20.21
	per_source		= 11
	cps			= 100 2
	flags			= IPv4
}

$ cat /etc/xinetd.d/tftp2
service tftp
{
	socket_type		= dgram
	protocol		= udp
	wait			= yes
	user			= root
	server			= /usr/sbin/in.tftpd
	server_args		= -s /tftpboot
	disable			= no
	bind		= 192.168.20.22
	per_source		= 11
	cps			= 100 2
	flags			= IPv4
}

$ cat /etc/xinetd.d/tftp3
service tftp
{
	socket_type		= dgram
	protocol		= udp
	wait			= yes
	user			= root
	server			= /usr/sbin/in.tftpd
	server_args		= -s /tftpboot
	disable			= no
	bind		= 192.168.20.23
	per_source		= 11
	cps			= 100 2
	flags			= IPv4
}

Re: loopback IP alias breaks tftp?

[Josh Boyer]

On Fri, Oct 07, 2011 at 02:23:21PM +0200, Eric Dumazet wrote:
> Le vendredi 07 octobre 2011 à 14:04 +0200, Eric Dumazet a écrit :
> 
> > Its a completely different problem IMHO : You describe a tftp server
> > bug.
> > 
> > Say your tftp server is multihomed with 3 different IPS : 
> > 
> > 192.168.20.21, 192.168.20.22, 192.168.20.23
> > 
> > And tftp server listens to any address (UDP port 69) : 0.0.0.0:69
> > 
> > When receiving a request on 192.168.20.22, it should use same source
> > address, not let the system chose a "random or whatever policy" one.
> > 
> > 
> > 
> > So I would suggest to check/fix if TFTP server uses the correct socket
> > API to get both the client IP and its own IP in each UDP datagram
> > 
> > -> setsockopt(fd, IPPROTO_IP, &on, sizeof(on))
> 
> > This permits tftp server to use the same "struct in_pktinfo" for replies, forcing a correct source address.
> > 
> 
> By the way, there is no need for tftp change :
> 
> Just launch several tftpd instances, and bind each them to one
> particular IP.
> 
> If started from xinetd.d :
> 
> $ cat /etc/xinetd.d/tftp1
> service tftp
> {
> 	socket_type		= dgram
> 	protocol		= udp
> 	wait			= yes
> 	user			= root
> 	server			= /usr/sbin/in.tftpd
> 	server_args		= -s /tftpboot
> 	disable			= no
> 	bind		= 192.168.20.21
> 	per_source		= 11
> 	cps			= 100 2
> 	flags			= IPv4
> }

(I've CC'd the original bug reporter now.)

I did this locally and it still timed out.  So the bind alone is not
enough to fix the problem.  At least not on lo:0 127.0.0.2.

Changing the source address in the routing table as Joel suggested does
work around the problem.

So, in summary,  either the TFTP server needs to be changed per your
original suggestion, or the routing table needs to be altered for every
alias?  Is that correct?

josh

Re: loopback IP alias breaks tftp?

[Olaf van der Spek]

> On Fri, Oct 07, 2011 at 02:23:21PM +0200, Eric Dumazet wrote:
>> By the way, there is no need for tftp change :
>>
>> Just launch several tftpd instances, and bind each them to one
>> particular IP.
>>
>> If started from xinetd.d :

Isn't that a bad way to work around this issue?
It'd require you to duplicate your IP config for every daemon that
listens on UDP interfaces.
What about IP addresses that are added/deleted after the daemon is launchad?

Olaf

Re: loopback IP alias breaks tftp?

[Eric Dumazet]

Le lundi 10 octobre 2011 à 17:15 +0200, Olaf van der Spek a écrit :
> > On Fri, Oct 07, 2011 at 02:23:21PM +0200, Eric Dumazet wrote:
> >> By the way, there is no need for tftp change :
> >>
> >> Just launch several tftpd instances, and bind each them to one
> >> particular IP.
> >>
> >> If started from xinetd.d :
> 
> Isn't that a bad way to work around this issue?
> It'd require you to duplicate your IP config for every daemon that
> listens on UDP interfaces.
> What about IP addresses that are added/deleted after the daemon is launchad?
> 
> Olaf

Thats a pretty common problem, even prior to discussed commit.

If you take a look at common UDP daemons, they have to setup a listener
for each IP address, OR use the correct API ( setsockopt(fd, IPPROTO_IP,
&on, sizeof(on)) and handle IP_PKTINFO ancillary message)

Re: loopback IP alias breaks tftp?

[Olaf van der Spek]

On Mon, Oct 10, 2011 at 5:22 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Isn't that a bad way to work around this issue?
>> It'd require you to duplicate your IP config for every daemon that
>> listens on UDP interfaces.
>> What about IP addresses that are added/deleted after the daemon is launchad?
>>
>> Olaf
>
> Thats a pretty common problem, even prior to discussed commit.
>
> If you take a look at common UDP daemons, they have to setup a listener
> for each IP address, OR use the correct API ( setsockopt(fd, IPPROTO_IP,
> &on, sizeof(on)) and handle IP_PKTINFO ancillary message)

Only the latter solution seems right.

Olaf

Re: loopback IP alias breaks tftp?

[Francis SOUYRI]

Hello,

I put this in the Red Hat Bugzilla – Bug 739534:

#####	

I do the test with the bind of the IP alias (for test purpose 
127.0.0.2), but I have the same problem.

# ifconfig lo; ifconfig lo:0
lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:24418 errors:0 dropped:0 overruns:0 frame:0
           TX packets:24418 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:3798250 (3.6 MiB)  TX bytes:3798250 (3.6 MiB)

lo:0      Link encap:Local Loopback
           inet addr:127.0.0.2  Mask:255.0.0.0
           UP LOOPBACK RUNNING  MTU:16436  Metric:1

# netstat -an | grep 69 | grep udp
udp        0      0 127.0.0.2:69                0.0.0.0:* 

udp        0      0 :::52697                    :::* 

# tftp 127.0.0.2
tftp> trace
Packet tracing on.
tftp> get /thinstation/dell/vmlinuz
sent RRQ <file=/thinstation/dell/vmlinuz, mode=netascii>
received DATA <block=1, 512 bytes>
sent ACK <block=1>
received DATA <block=1, 512 bytes>
sent ACK <block=1>
received DATA <block=1, 512 bytes>
sent ACK <block=1>
received DATA <block=1, 512 bytes>
sent ACK <block=1>
sent ACK <block=1>
received DATA <block=1, 512 bytes>
sent ACK <block=1>
sent ACK <block=1>
sent ACK <block=1>
sent ACK <block=1>
received DATA <block=1, 512 bytes>
sent ACK <block=1>
Transfer timed out.

tftp>

I do also this test, I changed the local route (the loopback used is 
only for test purpose, in production I used 192.168.100.0/24 network).

# ip route show table local | grep 127.0.0.
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.2 dev lo  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
#
# ip route change local 127.0.0.2 dev lo  proto kernel  scope host  src
127.0.0.2
#
# ip route show table local | grep 127.0.0.
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.2 dev lo  proto kernel  scope host  src 127.0.0.2
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
#
# tftp 127.0.0.2
tftp> get /thinstation/dell/vmlinuz
tftp> quit
#
# ip route change local 127.0.0.2 dev lo  proto kernel  scope host  src
127.0.0.1
# tftp 127.0.0.2
tftp> get /thinstation/dell/vmlinuz
Transfer timed out.

tftp> quit
#

#####

Best regards.

Francis


On 10/10/2011 05:25 PM, Olaf van der Spek wrote:
> On Mon, Oct 10, 2011 at 5:22 PM, Eric Dumazet<eric.dumazet@gmail.com>  wrote:
>>> Isn't that a bad way to work around this issue?
>>> It'd require you to duplicate your IP config for every daemon that
>>> listens on UDP interfaces.
>>> What about IP addresses that are added/deleted after the daemon is launchad?
>>>
>>> Olaf
>>
>> Thats a pretty common problem, even prior to discussed commit.
>>
>> If you take a look at common UDP daemons, they have to setup a listener
>> for each IP address, OR use the correct API ( setsockopt(fd, IPPROTO_IP,
>> &on, sizeof(on)) and handle IP_PKTINFO ancillary message)
>
> Only the latter solution seems right.
>
> Olaf
>