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] [day] [month] [year] [list]

Date:	Tue, 11 Oct 2011 09:28:05 +0200
From:	Francis SOUYRI <francis.souyri@...c.fr>
To:	Olaf van der Spek <ml@...pek.org>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	Josh Boyer <jwboyer@...hat.com>, Joel Sing <jsing@...gle.com>,
	Julian Anastasov <ja@....bg>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: loopback IP alias breaks tftp?

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@...il.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
>

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