Re: Do you know the TCP stack? (127.x.x.x routing)

From: Zdenek Radouch
Date: Sun Mar 06 2005 - 12:05:42 EST

At 10:56 AM 3/6/05 +0100, Martin Mares wrote:
>> Unfortunately, this does not work with the Linux stack, because the
>> 127 net is treated (for good reasons I suppose) as a special net.
>Is it really?

Well, at least it looks that way to me:

svfx:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window
irtt Iface U 0 0
0 eth0 UG 0 0
0 eth0

Hmmm, I don't seem to have the loopback interface...
This table implies that should go out via eth0
to a gateway That's hard to believe.

svfx:~# ping -c 1
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=0.2 ms

--- ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms

Looks like I do have the loopback interface after all. It just
seems to be hidden, i.e., it actually is treated in a special way
by one of the entities I am perusing.
Let's see if I can delete the route anyway.

svfx:~# route del -net netmask dev lo
SIOCDELRT: No such process

Looks like I can't, maybe it's not there?

>I've just tried
> ip addr del dev lo
> ip addr add dev lo
>and `ping' is then happily sent along the default route.

I don't have iproute around, so I will install it now.
and try your method:

svfx:~# ip addr del dev lo
Cannot send dump request: Connection refused

That actually looks like some compatibility issue if I had to guess.
I never used the iproute tools, so I'll ignore that for now.
[Anyone knows what this means?]

Something just crossed my mind - maybe the 127 processing
and/or the netstat/route/iproute tools are in flux, i.e., being
changed in a major way to the point that I really need to pay
attention to what kernel I am running. I have done the above tests
on my "stable" machine, which runs 2.2.20 (common Debian stable
release). I'll go and retest everything on my embedded target
which is running the 2.4.25 kernel.

Can someone comment on the stability of the tools in question
or any implementation changes in this area that would explain
the above behavior?

But point well taken, perhaps I just need a bit more imagination
when I'm testing these things. It may very well work, it just may
look like it does not. Thanks for the suggestions!


To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at