JohnnyRun wrote:
> Hi all!
> I think it's a bug....
That definately seems weired, but I never ran into it till now...
> HOSTA# ifconfig eth0 192.168.0.1
> HOSTA# ifconfig eth0 down
> HOSTA# ping 192.168.0.1
> (the ping works, like all other ICMP / TCP /UDP ... application.
> In other words: all work like eth0 in UP mode when source and
> destination point comunicate via loopback device.
> I think it's not correct because if eth0 is DOWN for all the hosts in
> LAN should be down for me too. Or not?
Just to rewrite that in iproute2
old ~ # ip addr flush dev eth1
old ~ # ip addr show dev eth1
4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:54:0b:8a brd ff:ff:ff:ff:ff:ff
old ~ # ping -c1 -q 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
--- 192.168.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
old ~ # ip addr add 192.168.0.1/32 dev eth1
old ~ # ip link set dev eth1 down
old ~ # ip link show dev eth1
4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:00:00:54:0b:8a brd ff:ff:ff:ff:ff:ff
old ~ # ping -c1 -q 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
--- 192.168.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.033/0.033/0.033/0.000 ms
> Suppose another conf:
>
> HOSTA# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:10:DC:C3:5E:FF
> inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.0.0.0
> BROADCAST MULTICAST MTU:1500 Metric:1
> eth1 Link encap:Ethernet HWaddr 00:0E:35:74:16:67
> inet addr:192.168.0.2 [...]
> UP BROADCAST RUNNING MULTICAST MTU:1500
> lo [...]
>
> HOSTB# ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 00:00:24:C8:4A:7D
> inet addr:192.168.0.1 Bcast:1.255.255.255 Mask:255.0.0.0
> UP BROADCAST RUNNING MULTICAST MTU:1500
> [...]
>
> So, HOSTA and HOSTB share the same ip but: HOSTA eth0 is DOWN; HOSTA eth1 is
> UP, HOSTB eth0 is UP. So, no conflict should be possible.
> but:
>
> HOSTB# ping 192.168.0.2
> (does not reply)
>
> So I suppose that HOSTA route the icmp reply through its lo.
> But:
>
> HOSTA# tcpdump -i lo
> doesn't show any reply, and
>
> HOSTA# tcpdump -i eth0
> it's not permitted, because eth0 is DOWN.
>
> The same result for TCP protocol (tested with hping).
> Operative conditions: Linux 2.6.14, HOSTA eth1 is wifi.
Very good testcase!
Any IP gurus? Ideas on why is such behaviour observerd?
Does it have to do something with the driver for ethX being notiefied of the link status and thus
hardware (PHY?) is shut down so signal from the wire is ignored?
Or down the ARP somewhere?
Cannot think of security exploit at the moment, but there should be one...
Kalin.
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
