At 10:56 AM 3/6/05 +0100, Martin Mares wrote:
>Hello!
>
>> 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
192.168.13.0 0.0.0.0 255.255.255.0 U 0 0
0 eth0
0.0.0.0 192.168.13.254 0.0.0.0 UG 0 0
0 eth0
svfx:~#
Hmmm, I don't seem to have the loopback interface...
This table implies that 127.0.0.1 should go out via eth0
to a gateway 192.168.13.264. That's hard to believe.
svfx:~# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.2 ms
--- 127.0.0.1 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 127.0.0.0 netmask 255.0.0.0 dev lo
SIOCDELRT: No such process
svfx:~#
Looks like I can't, maybe it's not there?
>I've just tried
>
> ip addr del 127.0.0.1/8 dev lo
> ip addr add 127.0.0.1/24 dev lo
>
>and `ping 127.1.2.3' 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 127.0.0.1/8 dev lo
Cannot send dump request: Connection refused
svfx:~#
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!
Regards,
-Zdenek
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
