[Gutsy] Manual WPA network doesn't connect on reboot

[Saivann Carignan]

I'm running gutsy will all updates

A network configured with WPA or WPA2 and a static IP will not automatically connect at reboot. The only way to get the network to work is to type a /etc/init.d/network restart or else, the wireless card will never connect to the WPA wireless access point.

This problem doesn't happen with WEP keys, only WPA or WPA2.

[Saivann Carignan (oxmosys)]

Here's my complete dmesg after a reboot. Network still not works, it is BEFORE the /etc/init.d/networking restart

[Saivann Carignan (oxmosys)]

And here's a diff file made by comparing the dmesg BEFORE and AFTER the /etc/init.d/networking restart

[Reinhard Tartler (siretart)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 53387 and is being marked as such. Please look at the other bug report to see if there is any information missing that you can add or to see if there is a work around. Feel free to continue to report any other bugs you may find.

[Saivann Carignan (oxmosys)]

Reinhard Tartler : Feel free to correct my errors if you think that I make somes. I set back this bug has being not a duplicate because I think that this bug is different from the bug 53387 because the wpasupplicant package is different in Gutsy and is enabled and configured by default through the gnome-network-manager.

The problem is the same, but I'm not sure that the cause for that problem is the same and I feel that my posts will give a better help tracking the problem if we don't mix Dapper/Edgy/Feisty with Gutsy.

Because Wpasupplicant is enabled by default in Gutsy, shouldn't there be a milestone for it?

[Saivann Carignan (oxmosys)]

I use wpasupplicant ver. 0.6.0-1 on Ubuntu Gutsy tribe 5. the problem is still not fixed

I changed the boot priority of /etc/init.d/networking to be one of the first or last init to be launched. It gave no result at all.

I inspected my dmesg output and found interesting outputs :

// On normal boot
Aug 23 22:54:46 zxz-laptop kernel: [ 18.092000] ieee80211_crypt: registered algorithm 'NULL'
Aug 23 22:54:46 zxz-laptop kernel: [ 18.772000] ieee80211: 802.11 data/management/control stack, git-1.1.13
Aug 23 22:54:46 zxz-laptop kernel: [ 18.772000] ieee80211: Copyright (C) 2004-2005 Intel Corporation <email address hidden>
Aug 23 22:54:46 zxz-laptop kernel: [ 18.840000] usbcore: registered new interface driver hci_usb
Aug 23 22:54:46 zxz-laptop kernel: [ 18.852000] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.0kmprq
Aug 23 22:54:46 zxz-laptop kernel: [ 18.852000] ipw2200: Copyright(c) 2003-2006 Intel Corporation
Aug 23 22:54:46 zxz-laptop kernel: [ 18.852000] ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 17 (level, low) -> IRQ 18
Aug 23 22:54:46 zxz-laptop kernel: [ 18.852000] ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection
Aug 23 22:54:46 zxz-laptop kernel: [ 19.196000] ipw2200: Detected geography ZZA (11 802.11bg channels, 13 802.11a channels)
Aug 23 22:54:46 zxz-laptop kernel: [ 20.824000] ADDRCONF(NETDEV_UP): eth1: link is not ready

//After I typed sudo /etc/init.d/networking restart

Aug 23 23:01:50 zxz-laptop kernel: [ 469.140000] ADDRCONF(NETDEV_UP): eth1: link is not ready
Aug 23 23:01:50 zxz-laptop kernel: [ 469.776000] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Aug 23 23:01:50 zxz-laptop kernel: [ 469.856000] ieee80211_crypt: registered algorithm 'CCMP'
Aug 23 23:02:01 zxz-laptop kernel: [ 480.164000] eth1: no IPv6 routers present

ieee80211 uses the registered algorithm 'NULL' while it boots, but uses CCMP after a "sudo /etc/init.d/networking restart".

It looks like the CCMP algorithm doesn't exist during boot but is ready to use after gdm is started.

[Reinhard Tartler (siretart)]

Saïvann Carignan <email address hidden> writes:

> Reinhard Tartler : Feel free to correct my errors if you think that I
> make somes. I set back this bug has being not a duplicate because I
> think that this bug is different from the bug 53387 because the
> wpasupplicant package is different in Gutsy and is enabled and
> configured by default through the gnome-network-manager.
>
> The problem is the same, but I'm not sure that the cause for that
> problem is the same and I feel that my posts will give a better help
> tracking the problem if we don't mix Dapper/Edgy/Feisty with Gutsy.

Especially your next comment indicates to me that this is a clear dupe
of #53387. It could very well be a missing loaded module as you write.

Shall we mark this bug as dupe of bug #53387 again?

> Because Wpasupplicant is enabled by default in Gutsy, shouldn't there be
> a milestone for it?

only if you find a devloper willing to take over responsibilty for this
particular bug.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Saivann Carignan (oxmosys)]

Re-marked has duplicate. Thanks