[network-admin] Changing ESSID requires reboot or, or manual iwconfig for changes to take effect

Thank you for your bug. The network-config job is to the change the config file and restart the network, if "sudo /etc/init.d/networking restart" doesn't apply the changes that's not a network-admin bug. The DHCP doesn't reply according to "No DHCPOFFERS received.", are you sure that's not a bug from your DHCP server? Do you have log from the server? Could you look if it receives a request for a new IP from the client?

I did some more troubleshooting. I can get the exact same results by manually editing the /etc/networking/interfaces and restarting networking thus yes -- I mis-categorized this bug report by selecting "gnome-system-tools" package. I don't know if the problem is in the ifupdown package, or wireless-tools (iwconfig), or elsewhere?

What appears to be happening is that any values the card uses during startup are retained until they are explicitly changed using iwconfig. For instance, my config file (/etc/network/interfaces) has:
auto eth1
iface eth1 inet dhcp
wireless-essid WORKACCESSPOINT
wireless-key s:WORKWEPKEY
but since I am at home these values are invalid. So I boot (and get no connectivity) and then edit the config file to change the essid line to "wireless-essid HOMEACCESSPOINT" and remove the entry for "key". Even if I do "$ sudo /etc/init.d/networking restart" it appears that it still is trying to do WEP authentication. Unless I explicitly issue an "$ sudo iwconfig eth1 key off" first, the ifup appears to still attempt to use the WEP key that was in the config file during boot -- even though the wireless-key line has been removed.

So the problem appears to be that "$ sudo /etc/init.d/networking restart" isn't starting the network similar to how it starts from a power-off condition and instead it only changes the values that are explicitly listed in the /etc/network/interfaces.

Here's another example.
With an invalid essid in the config file at boot, if I then do an "$ iwconfig eth1", it will list frequency 2.437 GHz which is Channel 06 -- the first access point found when I "$ iwlist eth1 scanning" is channel 6 so I am suspecting that this is why it show this specific frequency. After I change the config file to "wireless-essid HOMEACCESSPOINT" and then restart networking, the dhclient part of the restart will still report NO DHCPOFFERS". I then do "$ iwconfig eth1" which now shows the correct ESSID but it still shows the 2.437 GHz frequency, and it also still shows "Access Point: Invalid". If I make no further changes to the config file and then reboot, I'll get a connection no problem. But to get the changes to the config file to take effect without rebooting I need to manually do:
  $ sudo iwconfig eth1 channel 11 essid "HOMEACCESSPOINT"
  $ sudo /etc/init.d/networking restart
and it then restarts and connects no problem.

To answer your question about whether or not dhcp server is at fault, I get the same problem at work (Airport Extreme AP) as at home (Linksys BEFWS114 router), so I don't think dhcp server is at fault -- especially since every dhclient subsequent to an iwconfig (with channel, essid, and key) is always successful.

Is what I am experiencing (changes to config not taking effect until iwconfig or reboot) unique?

Not a gnome-system-tools, not sure of if that's a linux or network stack problem, reassigning to netbase the bug has probably enough information to be picked by somebody working on network

The user that reported bug #67152 is now experiencing identical behavior:
https://launchpad.net/ubuntu/+source/gnome-system-tools/+bug/67152

Related to this (I think) is that the network restart does not set the essid for me any more. I've just upgraded to feisty with settings that used to work. The relevant part of /etc/network/interfaces is

auto wlan0
iface wlan0 inet dhcp
    wireless-essid default

wlan0 is my primary interface. However, on start up, or after doing

$ sudo /etc/init.d/networking restart

DHCP has failed. On further investigation I find that no essid is set -

$ iwconfig
wlan0 IEEE 802.11b+/g+ ESSID:"" Nickname:"acx v0.3.36"
          Mode:Managed Frequency:2.422 GHz Access Point: Not-Associated
          Bit Rate:54 Mb/s Tx-Power=15 dBm Sensitivity=1/3
          Retry min limit:7 RTS thr:off
          Power Management:off
          Link Quality=34/100 Signal level=8/100 Noise level=0/100
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

But if I set it manually it works fine.

$ sudo iwconfig wlan0 essid default
$ sudo dhclient wlan0

Hope this is the right thread to add my comment to ...

Since yesterday's updates, the behaviour has changed a little - I still have no network connection on boot (and the essid is not set). But now, when I run

$ sudo /etc/init.d/networking restart

it does set the essid and start the network properly. So only one command to run each time I start my computer ... While this is an inconvenience for me (as I know the command line well) it could be a show stopper for others - so I think the priority should be increased.

I am confident it is not my DHCP server - it worked fine for me while I was using hoary, warty, breezy, dapper and edgy ... As soon as iwconfig reports that wlan0 has the essid set, dhclient works fine.

I did notice this section in /var/log/messages about 2 minutes after the boot - this may have been when I was running /etc/init.d/networking restart

Mar 18 15:04:53 whisper kernel: [ 150.220452] ADDRCONF(NETDEV_UP): eth0: link is not ready
Mar 18 15:04:55 whisper kernel: [ 151.728665] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Mar 18 15:04:57 whisper kernel: [ 154.296761] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Mar 18 15:04:58 whisper kernel: [ 155.160302] wlan0: duplicate address detected!

In case it matters, lscpi reports my wireless card as

 Network controller: Texas Instruments ACX 111 54Mbps Wireless Interface
 Subsystem: Netgear Unknown device 4c00

The netbase part of this seems to be working according to the most recent message (it would actually have been a wireless-tools bug) -- so the bug now must be just that the network admin tool doesn't ifdown/ifup the card properly?

Did a little experiment on boot today. I booted into safe mode. When I landed at the root command prompt I typed "ifconfig" and discovered that the network was working fine at that point. ifconfig reported my IP address and I was able to ping the internet.

I then did "telinit 5" to complete the boot process, logged in and found that the wireless card had had it's ESSID unset (or set to "") and I no longer had a network. The usual sudo /etc/init.d/networking restart was then required to get networking back.

As an aside, the networking icon at the top of the screen continues to report the network being disconnected, even once I am connected.

Would you like more info? Should I wait until the login screen, go to a different terminal and check for the network? Or is the above info enough to pin it on gnome-system-tools? Let me know.

the new comment seems to describe a network-manager bug

Did some more searching today and I now think my problem is a duplicate of bug #92299

Hi guys,

Just in case it helps ... I was having the same problem and the best way I found to get over this situation was just to remove:
#wireless-essid mySSID
#wireless-key myWirelessKey

then reboot. After that the icon showing signal strength appeared in the quick launch bar. Clicking on it shows all available SSIDs. When I selected my one it prompted for the paraphrase I used when I set up my WEP KEY. After inserting it I was connected to my wireless network.

I am running:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 6.10
Release: 6.10
Codename: edgy

Thanks,

-Nestor

Hi,
  I think I had a similar issue. I connect often to a DHCP wireless LAN at the University , but i need sometimes also to connect to a nother Ap wlan to control a robot. So I wrote 2 scripts in order to switch from one to another. When I started at the robot WLAN all was OK (this LAN had static IP); but when I ran the DHCP WLAN script, I was unable ro return later to the robot WLAN executing its script. iwconfig showed that WLAN connection switched to University LAN, after some seconds. Finally I found that I had to stop a dhcp client daemon AND a WPA_SUPPLICANT daemon too. Adding "dhclient stop" and "killall -q wpa_supplicant" at the beginning of my robotWLAN script was enough to end with that disturbing WLAN switching.

Thanks for your report, this is working fine for me with Gutsy and Hardy, may someone try to reproduce it on the latest one and give us some feedback? thanks in advance.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.