All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalin KOZHUHAROV <kalin@thinrope.net>
To: linux-kernel@vger.kernel.org
Subject: Re: eth0 and loopback problems.
Date: Fri, 06 Jan 2006 12:31:24 +0900	[thread overview]
Message-ID: <dpkoae$5t2$1@sea.gmane.org> (raw)
In-Reply-To: <20060105092052.GE3008@darkstar.mylan>

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


  reply	other threads:[~2006-01-06  3:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-05  9:20 eth0 and loopback problems JohnnyRun
2006-01-06  3:31 ` Kalin KOZHUHAROV [this message]
2006-01-06  4:15 ` Bernd Eckenfels

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='dpkoae$5t2$1@sea.gmane.org' \
    --to=kalin@thinrope.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.