eth0 and loopback problems.

eth0 and loopback problems.

[JohnnyRun]

Hi all!
I think  it's a bug....

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?

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.
Regards
JohnnyRun

Re: eth0 and loopback problems.

[Kalin KOZHUHAROV]

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/ <-+
|[ ______________________ ]|

Re: eth0 and loopback problems.

[Bernd Eckenfels]

JohnnyRun <gianni79@gamebox.net> wrote:
> I think  it's a bug....

just a link to other places where this came up:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322654

Gruss
Bernd