public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Amir Guindehi <amir@datacore.ch>
To: Paul Jakma <paul@clubi.ie>
Cc: "Jüri Põldre" <jyri.poldre@artecdesign.ee>,
	"Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: Ethernet driver link state propagation to ip stack
Date: Sat, 15 Jan 2005 13:17:36 +0100	[thread overview]
Message-ID: <41E909E0.7000902@datacore.ch> (raw)
In-Reply-To: <Pine.LNX.4.61.0501150507000.15839@sheen.jakma.org>

Hi,

>> My question is:  Does the kernel handle the interface state/routing 
>> tables modifications due to link changing automatically
> 
> Not completely.
> 
> The biggest problem is that kernel does not remove its "connected" or 
> "subnet" route while link is down. This means that even though kernel 
> knows link is down, it will still try route packets out that interface.

I can confirm this.

>> or is there some external daemon required to do that. Any links are 
>> greatly appreciated.

Try the shell script below. It works for me (tm).

> There is "Netplug" - part of the net-tools package (On fedora core 3 at 
> least). You can use it to 'ip link set dev .... down' when carrier is 
> removed. However, you wont get notified of carrier being inserted back - 
> I dont know whether that holds true generally, or whether its an e1000 
> bug. So it's one-shot.
> 
> We're looking at adding support to the 'zebra' daemon in Quagga to 
> remove connected routes while link is down and add them back when 
> link-up again, and hence deal with this properly. Amir is very 
> interested in this..

Yes, I am. And I found out the following. If I add the following 
one-liner shell script daemon, I get it all working:

while /bin/true; do echo "Check of eth5 ..."; A=`ethtool eth5 | grep 
'Link detected'`; if [ "$A" != "$O" ] ; then C=`echo "$A" | grep 'yes'`; 
if [ -n "$C" ] ; then echo "Adding route";  route add -net 5.5.7.0 
netmask 255.255.255.0 dev eth5; else echo "Removing route"; route del 
-net 5.5.7.0 netmask 255.255.255.0 dev eth5; fi; O="$A"; fi; sleep 1; done

[I have to mention that eth5 is the interface where I pull and reinsert 
the cable]

As you can see I simply try to remove and re-add the connected route 
from user space. The above shell script works for me, and i can pull and 
re-insert my network cable as often as I want while still being able to 
reach the network on eth5 over different routes (received via ospf, I 
run Quagga) while the cable is pulled out and over the local interface 
while the cable is back in.

> /me grumbles about why oh why the "make kernel add connected routes"
>   feature was *ever* added in 2.3 in the first place (cause now
>   userspace has "forgotten" how to manage them, so we cant simply undo
>   this brain-damage[1] without breaking networking for everyone, sigh)

True.

I'm /not/ able to recreate the route as it was before my 'route del' the 
recreated route looks different from the route I remove at first (the 
connected one). I'm nor able to recreate the 'src xxx' flags and 
neighter is it a 'proto kernel' route ;)

So, in my eyes we need:
- A way to create connected routes from user space
or
- A kernel which removes the connected route on link loss and recreates 
it later when the link gets connected again.

Regards
- Amir
-- 
Amir Guindehi, nospam.amir@datacore.ch
DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland


  reply	other threads:[~2005-01-15 12:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-14 16:42 Ethernet driver link state propagation to ip stack Jüri Põldre
2005-01-14 18:54 ` Peter Buckingham
2005-01-15  5:14   ` Paul Jakma
2005-01-14 19:44 ` Ben Greear
2005-01-15 12:10 ` Paul Jakma
2005-01-15 12:17   ` Amir Guindehi [this message]
2005-01-17  6:49 ` Stefan Seyfried
2005-01-17 10:03 ` Mark Watts

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=41E909E0.7000902@datacore.ch \
    --to=amir@datacore.ch \
    --cc=jyri.poldre@artecdesign.ee \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@clubi.ie \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox