[network-admin] locations do not get saved correctly

Bug #13727 reported by Jochem Kossen
16
Affects Status Importance Assigned to Milestone
GST
Fix Released
Medium
gnome-system-tools (Ubuntu)
Fix Released
Medium
Ubuntu Desktop Bugs
Nominated for Edgy by Bryce Harrington
Nominated for Feisty by Bryce Harrington

Bug Description

(all on hoary with gnome-system-tools 1.2.0-0ubuntu1, possibly the bugs are
upstream bugs)

When i configure multiple locations in network-admin (System -> Administration
-> Networking), it seems to save certain data to all locations when i select a
location. For example, i have a location 'home' in which i configure interface
'ath0' to be configured and active. Interface eth0 is not configured, and
disabled. I also have a profile called 'work' where ath0 is not configured and
not active, and eth0 is configured and active. After selecting a location,
somehow the interface settings of all profiles get saved to the selected
profile. /etc/gnome-system-tools/network/profiles.xml seems to confirm my
symptoms (<enabled> , <key> and <essid> are all set to the same values for every
location/profile)

Other annoying bits:
 - on boot, ubuntu seems to select the last-used profile. But when i boot, i am
most probably at a different location than i was before, so actually, there
should be a 'default' location which is always used (in my case i'd disable all
interfaces, and select a location after booting)
 - Changes to locations/interfaces seem to be applied when 1) a different
location is selected, 2) settings of an interface are changed and 3) after
closing network-admin. IMHO network-admin should have a button 'apply', or a
'cancel' button when changing profiles, so it'd not reset the network after each
action (because you can't cancel the current network changes, you can't change
the settings either, until the changes time out, in case of wrong network settings).
 - Together with bug 13156 and bug 13236 this makes network-admin quite unusable
on laptops...

http://bugzilla.gnome.org/show_bug.cgi?id=170663: http://bugzilla.gnome.org/show_bug.cgi?id=170663

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

(please open one bug by issue)

I've opened a bug upstream about that:
http://bugzilla.gnome.org/show_bug.cgi?id=170663

Revision history for this message
KeithCu (keithcu) wrote :

I am brand new to Linux and love Ubuntu very much, but these problems are huge
for me. I have found a number of bugs in ubuntu:
http://keithcu.com/wordpress/?page_id=15 but the biggest holdup for me is the
network settings tool. It is very slow, pauses where there shouldn't be, it
doesn't persist settings (SSID of locations, default gateway, IP/DHCP) the
current location is often blank, etc.

(Also, because I have a 2200 card, WEP is broken for me but that is bug 21304
which must be bothering a lot of people.)

Whoever is responsible for these bugs, pretty please work on them. This bug is
from March, and Apple and MSFT would not ship OSes with these bugs...

I tried to bump up the priority and severity but couldn't.

Trying to constructively rant...

Revision history for this message
KeithCu (keithcu) wrote :

Here is an e-week article about ubuntu, and it mentions the exact problems
listed in this bug report:

http://www.eweek.com/article2/0,1895,1878697,00.asp

We found it a hassle to switch among different network connections on Ubuntu
5.10, such as from a wireless link to a wired one, or from one wired network to
another. Ubuntu's network configuration utility includes a profiles feature, but
we couldn't get it to work properly—the tool wouldn't save the profile
definitions we created and would hang for long stretches during certain operations.

Changed in gnome-system-tools:
status: Unconfirmed → Confirmed
Revision history for this message
jens_acamedia (commercial-acamedia) wrote :

currently with final dapper there are the following 3 outstanding issues afaik.

1, you need to select a profile to delete it - this means that i have to wait 2 minutes for a profile to time out before i can actually delete it.

2, since last profile is selected i also have to wait 2 minutes for this to time out before i can change profiles.

3, when i click on ok the changes are committed again. making me wait another minute...

its a little annoying to not be able to change networks as easily as with nm-applet but i can live with configuring a profile each time...having to wait for the timeout of the dhcp is what really kills me...any decent dhcp responds within 2 secs -

WHY IS TIMEOUT SO LONG????
thanks

Changed in gst:
status: Unconfirmed → Confirmed
Revision history for this message
Blue (vali-dragnuta) wrote :

I could add the following :
- nm-applet knows about WPA protected wireless networks, but the gnome tool does NOT.
- gnome tool does know about profiles (which is good) but network manager does not.

The big problem here is that for mobile users there is no easy way to switch between various kinds of network profiles.
For example, I have two wired locations, one with static address A one with address B;
I have another wireless location, WPA protected, using static addreess A as above.
I have another wireless location, WPA protected where I use static address B as in the first example;
I might also have yet another location using dhcp,and so on.

I cannot use network manager & friends because it does not seem to be able to :
   - support static addresses - it always uses dhcp.
   - support profiling, that is switching static addresses and other settings on the same interface.
I cannot use the gnome tool either, because :
   - it does not correctly save prefferences, as stated by the bug reporters above (And I confirm the behaviour)
   - it is unable to set up WPA protected wireless networks.

Given these facts I would rate the bug a little higher then "medium" because a mobile user is unable to use any of the tools.
I personally use as a workaround the interface mapping scheme (man interfaces) which allows me to switch between more networking profiles. However, this method is not gui integrated, so I have to use a terminal to switch profiles. But... at least it does work.
PS : The interface mapping scheme can be further improved to automatically sense the network where you are in and chose settings automatically.

Changed in gnome-system-tools:
assignee: seb128 → desktop-bugs
Revision history for this message
Gustaf (opera) wrote :

It has been years and network-admin still is pretty much useless for lots of people... I agree this should be more than medium importance. Would it really be that difficult to make it actually save settings, and more or less "work as you expect it to"? Like being able to edit settings without it automatically trying to apply them?
This is just not funny anymore.

Revision history for this message
Realtime (peter-icb) wrote :

I have exactly the same problem. Network admin is an absolutely useless application. With a standalone office computer you do not need it, because you have always the same type of connection.

With a notebook you cannot use it, because you cannot change locations. So what is this application for? Please fix it or kick it out of the Ubuntu Repository!

Importance should be "high" because actually Ubuntu is an operating system which is unusable for notebook owners that do not know how to manually configure network devices in Linux!

Peter

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

We are just work with upstream to get that fixed to edgy, but that's not clear what is confusing for users so some concrete comments on what you would like to get changed would be welcome.

One thing that can be confusing is that if you select a profile and do modifications then close the tool the modification are not stored to the profile. The upstream rational is you might want to do changes to your current session without wanting to store them. The way to store the change is to add a profile with the same name, which is not a discovarable way. I've suggested upstream that adding an "store changes to current profile" button next to the add,remove option already placed next to the profiles name. What do you think about that?

Another confusion is the instant apply. If the dhcp timeout issue is fixed, would you prefer an "apply" button anyway or instant apply would work good enough for that?

We can get the "store configuration" and "apply changes" button next to the profile, but 4 options starts being a bunch of option, 3 would be better if possible. I think the "add a profile with the same name to modify the current profile" is not clear enough and that a "store changes to profile" button would be welcome. The instant apply should be fine if the dhcp timeout issue can be workarounded or fixed.

What do you think about that?

Revision history for this message
Realtime (peter-icb) wrote :

Sounds good. It is almost impossible to figure out that you have to save the location a second time with the same name to save configuration changes.

Maybe also a dialog "Do you want to save your changes to the location 'office'?" yes/no every time you close network admin after changes would be nice.

Revision history for this message
Michael Vogt (mvo) wrote :

I like the idea of Realtime. It could just mark the current profile with something (a "*" behind the name) if it was modified and ask on exit if the changes should be saved to this profile (maybe with the option to save them as a different name).

Revision history for this message
Daniel Holbach (dholbach) wrote :

That idea seems to accomodate different use cases and is easy enough to figure out.

Revision history for this message
Michael Gratton (mjog) wrote :

I'm waiving my own flag here, but I think instant apply to the currently selected location is still the better way to go (see http://bugzilla.gnome.org/show_bug.cgi?id=170663#c11).

You avoid the extra buttons, the dialog acts exactly like every other Gnome preferences window and it is pretty obvious what is going on to the user.

I can't think of any use case for upstream's concern with wanting to make some change to the current settings and not wanting to save it. Networks tend to be static things - once you set it up, you want to keep it like that and the settings rarely change later on. I'd be interested to know when this is likely to happen.

If the DHCP dialog was cancellable, then having to switch to a profile to delete it might not be so bad. As an alternative, have a seperate UI for editing the list of profiles, as MacOSX does.

Revision history for this message
Sebastien Bacher (seb128) wrote : Re: [Bug 13727] Re: [network-admin] locations do not get saved correctly

Le lundi 11 septembre 2006 à 12:03 +0000, Mike Gratton a écrit :

> I can't think of any use case for upstream's concern with wanting to
> make some change to the current settings and not wanting to save it.

Let's say you want to use a train station wireless network while
travelling, you probably don't want to modify your profile to connect to
it

> Networks tend to be static things - once you set it up, you want to keep
> it like that and the settings rarely change later on. I'd be interested
> to know when this is likely to happen.

Networks might be static but with a laptop you might from from a network
to an another pretty often

> If the DHCP dialog was cancellable, then having to switch to a profile
> to delete it might not be so bad. As an alternative, have a seperate UI
> for editing the list of profiles, as MacOSX does.

DHCP cancel would be nice right. Another question is to know if people
expect to have their network changed only because they are looking at
the available profiles from the list

Revision history for this message
Michael Gratton (mjog) wrote : Re: [Bug 13727] Re: [Bug 13727] Re: [network-admin] locations do not get saved correctly

On Mon, 2006-09-11 at 15:08 +0000, Sebastien Bacher wrote:
> Let's say you want to use a train station wireless network while
> travelling, you probably don't want to modify your profile to connect to
> it

If the location was currently set to (eg) my home network, I wouldn't
want to change the wireless network name for it if I wanted to connect
to the wireless network at the train station. I would either select the
blank location, create a new "Train Station" location if I was going to
use it frequently, or if not, create a "Roaming" (or similar) location
for this sort of situation before modifying anything. Why would I modify
my settings for home when I'm at the train station?

Again using MacOSX as an example, it by default has an "Automatic"
location that just picks an available wireless network if enabled or
wired ethernet if plugged in, and uses DHCP to get an address. That is
much more useful than network-admin's current behaviour. Perhaps the
blank location could be renamed to something similar to "Automatic" and
provide some sane default behaviour, like "use DHCP on ethernet if
plugged in, else use DHCP on a wireless network if available".

When network-admin tells the user "Your location is set to this" and
lets them modify some network settings with that still visible, I think
it is reasonable to expect that the user will assume they are modifying
that location and not some random settings based on the visible
location.

> Networks might be static but with a laptop you might from from a network
> to an another pretty often

Would the user be more likely to be using NetworkManager in that case?

> DHCP cancel would be nice right. Another question is to know if people
> expect to have their network changed only because they are looking at
> the available profiles from the list

True. I think the UI in X lets you add, duplicate, rename and delete
locations, but not activate them from that particular UI.

--
✌ michael gratton, itinerant geek
✇ <http://web.vee.net/>

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

fixed according to upstream

Changed in gnome-system-tools:
status: Confirmed → Fix Released
Changed in gst:
status: Confirmed → Fix Released
Changed in gst:
importance: Unknown → Medium
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.