Networking should be more resilient to ifupdown state problems, or report errors

Bug #9779 reported by Jeff Waugh
8
Affects Status Importance Assigned to Milestone
gnome-system-tools (Ubuntu)
Fix Released
Medium
Sebastien Bacher

Bug Description

Sometimes users report that the Networking dialogue lets them make a connection
active, but it unchecks the box a few seconds later. Usually, a quick ifdown
will reset the state of the connection, so you can either ifup it again, or use
the GUI. Sometimes, if ifupdown thinks the connection is already configured,
it'll return the following on ifup:

ifup: interface eth1 already configured

I'm pretty sure this is what's behind the Networking dialogue problems. If
nothing else, it should report an error (though that may end up being harder).

Revision history for this message
Sebastien Bacher (seb128) wrote :

I'm not sure to understand the exact purpose of the bug report.
Is that http://bugzilla.gnome.org/show_bug.cgi?id=144203 (ie: no error is
displayed) ?
The first part of the description seems to be that but the if* part is a bit
confusing.

Revision history for this message
Jeff Waugh (jdub) wrote :

ifupdown can get into a confused state. Try this:

  ifup eth0 (yay, we have eth0)
  ifconfig eth0 down (eth0 is no longer there)
  ifup eth0 (let's bring up eth0 again, but we can't because there's a failure)

If this happens when using network-admin, it doesn't fix the situation by doing
an ifdown eth0, and it doesn't report an error. I think robustness is preferable
to reporting an error, however. :-)

Revision history for this message
Matt Zimmerman (mdz) wrote :

(In reply to comment #2)
> ifupdown can get into a confused state. Try this:
>
> ifup eth0 (yay, we have eth0)
> ifconfig eth0 down (eth0 is no longer there)
> ifup eth0 (let's bring up eth0 again, but we can't because there's a failure)
>
> If this happens when using network-admin, it doesn't fix the situation by doing
> an ifdown eth0, and it doesn't report an error. I think robustness is preferable
> to reporting an error, however. :-)

ifupdown isn't getting confused; it's working as designed. If network-admin
brings up the interface with ifup, it must bring it down with ifdown, not with
ifconfig.

Revision history for this message
Jeff Waugh (jdub) wrote :

> ifupdown isn't getting confused; it's working as designed. If network-admin
> brings up the interface with ifup, it must bring it down with ifdown, not with
> ifconfig.

It *does* use ifup and ifdown. However, when ifupdown *does* get confused (as
demonstrated in comment #2, which can happen under many circumstances, including
dhcp errors), ifup won't work correctly. You cannot fix this in the gui. The gui
should ifdown and then ifup or something like that, to reset the ifupdown state
when it's confused.

Revision history for this message
Matt Zimmerman (mdz) wrote :

(In reply to comment #4)
> > ifupdown isn't getting confused; it's working as designed. If network-admin
> > brings up the interface with ifup, it must bring it down with ifdown, not with
> > ifconfig.
>
> It *does* use ifup and ifdown. However, when ifupdown *does* get confused (as
> demonstrated in comment #2, which can happen under many circumstances, including
> dhcp errors), ifup won't work correctly. You cannot fix this in the gui. The gui
> should ifdown and then ifup or something like that, to reset the ifupdown state
> when it's confused.

comment #2 shows ifup being run twice without ifdown being run at all. This is
not a valid sequence. If the interface is brought up with ifup, it MUST be
brought down with ifdown before trying to bring it up again with ifup.

Revision history for this message
Jeff Waugh (jdub) wrote :

Which is precisely why the GUI needs to be more resilient to this kind of event.

Revision history for this message
Carlos Garnacho (carlosg) wrote :

gnome-system-tools 1.1.3 is now able to report errors when activating an
interface fails, however, to make the tool some more instant-apply, I've been
forced to use ifconfig/dhclient/... by hand (which is something that
network-admin didn't do before this version, at least for debian), but I tried
to make things as robust as possible, so I think that this bug is at least
half-fixed :)

Revision history for this message
Sebastien Bacher (seb128) wrote :

closing at fixed. Feel free to reopen if you still have some issue with it

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.