Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Steffen Sledz <sledz@dresearch-fe.de>
To: Phil Blundell <philb@gnu.org>
Cc: Tim Riker <Tim@Rikers.org>,
	openembedded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: default route handling of udhcpc
Date: Fri, 11 Nov 2011 08:50:11 +0100	[thread overview]
Message-ID: <4EBCD3B3.3020202@dresearch-fe.de> (raw)
In-Reply-To: <1320663454.22985.643.camel@phil-desktop>

On 07.11.2011 11:57, Phil Blundell wrote:
> If it's the case that interfaces always do go down and then up again
> when changing configuration then you're right, it would be a non-issue.
> I guess maybe the best thing to do is to make sure that this is true and
> then we could avoid the unconditional route squashing as you suggest.
>
>> On the contrary. As i mentioned above we really hit a problem with current setting.
>>
>> * Interface ethA (static config with default route) comes up and sets this default route.
>> * Interface ethB (in our case a USB-NIC for diagnostic purposes, DHCP with default route) comes up and *replaces* the former default route.
>>
>> scenario a)
>> * Interface ethB goes down and removes its default route.
>> * There does not exist a default route any longer. :(
>>
>> scenario b)
>> * Interface ethA tries to go down.
>> * This fails because removing the not-existing default route of config ethA fails. :(
>
> That latter scenario sounds like a separate scripting bug: failing to
> remove a route shouldn't prevent the interface going down.

It seems that we can't find a general solution for the default route handling for the moment. So i like to fix this bug at first. Can someone give a hint which scripts are involved here?

Regards,
Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058



      parent reply	other threads:[~2011-11-11  7:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07  8:13 default route handling of udhcpc Steffen Sledz
2011-11-07 10:11 ` Phil Blundell
2011-11-07 10:31   ` Steffen Sledz
2011-11-07 10:57     ` Phil Blundell
2011-11-07 11:11       ` Steffen Sledz
2011-11-11  7:50       ` Steffen Sledz [this message]

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=4EBCD3B3.3020202@dresearch-fe.de \
    --to=sledz@dresearch-fe.de \
    --cc=Tim@Rikers.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=philb@gnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox