[gutsy] network-manager i have to manually configure wpa/2 enterprise every time to connect

[Basilio Kublik]

Binary package hint: network-manager

every time i want to connect to a wireless network i have to "connect to other network" and manually configure it, the correct values are stored in gconf, except the wpa_eap_private_file password which is stored in gnome-keyring.

when i click on the previously configured wireless network from the applet i get in syslog:

http://launchpadlibrarian.net/9168552/syslog

and so on.

manually configure the wireless network with the "connect to other" option the connection is established as should

http://launchpadlibrarian.net/9168569/syslog-2

all this, using clean install of gutsy tribe 4 with:

network-manager 0.6.5-0ubuntu9
network-manager-gnome 0.6.5-0ubuntu8
wpasupplicant 0.6.0-1
gnome-keyring 2.19.90-0ubuntu1
libgnome-keyring0 2.19.90-0ubuntu1
linux-image-2.6.22-9-generic 2.6.22-9.25
linux-restricted-modules-generic 2.6.22.9.10

the same configuration works well under feisty with the same settings.

[riri (girardhenri)]

till gutsy 3 no problem but with 4 and 5 i have to start manually nm
at each start it's disconnected with dhcp so i disactived it and reactived it manually and it works

[Alexander Sack (asac)]

Could you please post your wifi chipset/card/firmware specs?

Thanks,

  - Alexander

[Alexander Sack (asac)]

can you please attach a bit more context out of your syslog for the error case? Is that a hidden network btw?

[Basilio Kublik (sourcercito)]

this is with an atheros pcmcia card using madwifi from the official ubuntu repository, about the syslog what are you exactly looking for, because this is where the log starts when try to connect to the network and goes the same over and over until i choose configure new network and set the same parameters which suppose to be using in the first place.
the network isn't hidden.

as soon as i can i'll check again against the wpa enterprise ap, i'm right now testing other bugs with wpa-psk, maybe with the gnome-keyring upgrade this was solved, i'll come back later with the response.

[Basilio Kublik (sourcercito)]

Yup, still the same, every reboot/reconnection i have to manually configure the access point. i'll attach the syslog output when i first login and other when i force the use of the access point configuring it again with the same settings saved in gconf previously.

gconftool-2 -a /system/networking/wireless/networks/Mordor
 bssids = [00:18:39:7A:E3:70]
 essid = Mordor
 wpa_psk_key_mgt = 2
 wpa_eap_key_mgt = 1
 wpa_psk_wpa_version = 2
 timestamp = 1189181546
 we_cipher = 32
 wpa_eap_key_type = 0
 wpa_eap_private_key_file = /etc/wpa_supplicant/certs/cert-clt.p12
 wpa_eap_phase2_type = 0
 wpa_eap_ca_cert_file = /etc/wpa_supplicant/certs/cacert.pem
 wpa_eap_eap_method = 32
 wpa_eap_wpa_version = 4
 wpa_eap_identity = <email address hidden>

[Basilio Kublik (sourcercito)]

and now the syslog output when i force the use of the network.

by the way iwlist ath0 scan outputs:

ath0 Scan completed :
          Cell 01 - Address: 00:18:39:7A:E3:70
                    ESSID:"Mordor"
                    Mode:Master
                    Frequency:2.442 GHz (Channel 7)
                    Quality=46/70 Signal level=-49 dBm Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                              12 Mb/s; 48 Mb/s
                    Extra:bcn_int=100
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : WEP-40
                        Pairwise Ciphers (2) : TKIP WEP-40
                        Authentication Suites (1) : 802.1x
                       Preauthentication Supported
                    IE: WPA Version 1
                        Group Cipher : WEP-40
                        Pairwise Ciphers (2) : TKIP WEP-40
                        Authentication Suites (1) : 802.1x
                       Preauthentication Supported

which probes that the network is visible.

[Basilio Kublik (sourcercito)]

sorry, i forgot to update the version of the software involved:

network-manager 0.6.5-0ubuntu10
network-manager-gnome 0.6.5-0ubuntu8
wpasupplicant 0.6.0-3
gnome-keyring 2.19.91-0ubuntu1
libgnome-keyring0 2.19.91-0ubuntu1
linux-image-2.6.22-10-generic 2.6.22-10.30
linux-restricted-modules-2.6.22-10-generic 2.6.22.3-10.1

[Alexander Sack (asac)]

> wpa_eap_private_key_file = /etc/wpa_supplicant/certs/cert-clt.p12
> wpa_eap_phase2_type = 0
> wpa_eap_ca_cert_file = /etc/wpa_supplicant/certs/cacert.pem

probably unrelated, but do those certs exist?

[Basilio Kublik (sourcercito)]

yes, they exists and everyone has read access to the certificates and directories containing them, if not it wouldn't work when i force the use of the ap either.

[Alexander Sack (asac)]

On Fri, Sep 07, 2007 at 05:39:19PM -0000, Basilio Kublik wrote:
> yes, they exists and everyone has read access to the certificates and
> directories containing them, if not it wouldn't work when i force the
> use of the ap either.
>

Is your wireless interface configured in /etc/network/interfaces?
Please remove those lines (comment by adding # at the beginning of
each line) and see if you see improvements.

 - Alexander

[Basilio Kublik (sourcercito)]

No, the wireless interface isn't configured in /etc/network/interfaces, if i do that, and use wpa_supplicant directly works flawlessly, and of course being configured that way the wireless interface isn't visible to network-manager

currently the interfaces file contain the following related to the wireless card:

auto ath0
iface ath0 inet dhcp
# name Atheros Wireless card
# wpa-ssid Mordor
# wpa-driver madwifi
# wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

but i try even without any reference to this card included in this file.

I think the problem could be for example how network-manager load the key file which require a password to be load, maybe the file is loaded before the key file's password is asked to gnome-keyring, i don't know this is just an hypothesis without any foundation.

[Persio (persiobarros)]

Hi,

I have the same problem here. After successfully configure a WAP-EAP wireless network in NM, if I disconnect and try to reconnect I get those messages about "no valid keys" in daemon.log. The network essid is not hidden by the ap.
At home, with a WEP enabled ap, I have no problems.
My wireless card is an Intel 4965agn, using iwl4965 and mac80211 drivers.

network-manager 0.6.5-0ubuntu11
network-manager-gnome 0.6.5-0ubuntu8

[Alexander Sack (asac)]

On Mon, Sep 10, 2007 at 11:42:47PM -0000, Basilio Kublik wrote:
> No, the wireless interface isn't configured in /etc/network/interfaces,

no your interrace is configured ....

> if i do that, and use wpa_supplicant directly works flawlessly, and of
> course being configured that way the wireless interface isn't visible to
> network-manager
>
> currently the interfaces file contain the following related to the
> wireless card:
>
> auto ath0
> iface ath0 inet dhcp
  ^^^
comment those out as well and let me know if things improve.

 - Alexander

[Alexander Sack (asac)]

On Mon, Sep 10, 2007 at 11:42:47PM -0000, Basilio Kublik wrote:
> No, the wireless interface isn't configured in /etc/network/interfaces,
> if i do that, and use wpa_supplicant directly works flawlessly, and of
> course being configured that way the wireless interface isn't visible to
> network-manager
>
> currently the interfaces file contain the following related to the
> wireless card:
>
> auto ath0
> iface ath0 inet dhcp
> # name Atheros Wireless card
> # wpa-ssid Mordor
> # wpa-driver madwifi

on another front: does wext work for you here as well?

 - Alexander

[Basilio Kublik (sourcercito)]

about the comment #13, without any reference to the interface, that is, for instance in a clean interfaces file, as in without any content, the same behaviour is observed, see the comment below the interface definition.

and about the comment #14, yes, the wext driver works as well, i check it manually with wpa_supplicant and with network-manager which i'm now connected with.

the issue here, is not that network-manager does successfully connect, which always does, the issue is that with this special configuration, every time i want to connect/reconnect to this network with this particular configuration, i have to manually fill out all the required information, this doesn't happen when connect to a WPA/2-PSK network, which automagically connects every time after being configured just one time.

by the way, Alexander, thanks for the patience, and i want to clarify that English isn't my native language, so sometimes might sound/read rude or impolite, but it's not my intention at all, just don't know how to express me better in English.

[pnr (rusyaev)]

I have a similar issue: when I open the network manager, the default setting is WPA, but I use WPA2 for my home network, so I change the setting to WPA2 and enter a password, when close the window. After that the network connection run flawlessly until the next reboot. After reboot, I have to enter the network manager again and change to WPA2. It looks like NM does not save the selected settings.

[Persio (persiobarros)]

Any hope that this issue will be solved before official release of Gutsy? Is anyone able to use network-manager with a WPA-Enterprise network, without having to enter certs and password every time?
May be I can help tracing this bug out. Here at work the (experimental) wireless network is provided by a PC with a wireless PCI card, running Ubuntu (Feisty). The card relies on MadWifi driver and Hostapd to implement an AP with WPA-TKIP and EAP. The Radius server is installed on another PC, also running Feisty and Freeradius. I have root access to both pcs, and, of course to my notebook which is running Gutsy. In this way, I have controll over the whole chain. If somebody gives me some directions, I can try different configurations in order to try to uncover what is going wrong.

Persio

[Pirouette Cacahuète (lissyx)]

I experience the same issue, right after upgrading from Feisty to Gutsy :/

Laptop is ipw3945 based if it helps ...

[Pirouette Cacahuète (lissyx)]

Maybe this is linked ?
http://www.redhat.com/archives/fedora-devel-list/2007-October/msg00125.html

What's Busted Right Now (but will be fixed ASAP)
------------------------------------------------

* Does not support WEP passphrases
* Does not support WPA[2] Enterprise, IEEE801.X (Dynamic WEP), or LEAP
* Does not support hidden networks
* Does not autoconnect to last wireless network
* OpenVPN VPN plugin busted
* SELinux Enforcing mode is rocky

[Pirouette Cacahuète (lissyx)]

Running NetworkManager with '--no-daemon' switch, I can see that WPA Supplicant isn't able to load the PKCS12 file.

This looks like :
---
OpenSSL: Failed to load private key
TLS: Failed to load private key '/home/ubuntu/lissyx.p12'
TLS: Failed to set TLS connection parameters
EAP-TLS: Failed to initialize TLS.
CTRL-REQ-PASSPHRASE-0: Private key passphrase needed for SSID wifi.reseau-local.fr
EAP: Failed to initialize EAP method: vendor 0 method 13 (TLS).
---

If I re-enter EAP-TLS configuration (when asked for the parameters right after this failure come into the logs), then, I get correctly connected and WiFi works like a charm ... until I disconnect/reconnect ... leading to the bug we're talking about.

[Pirouette Cacahuète (lissyx)]

The issues is here with both zydas wireless USB key, and Intel PRO/Wireless 3945ABG.

And this, with ipw3945, iwl3945 and zd1211rw drivers.

[Steven Ayre (steveayre)]

Also getting this problem since updating to Gutsy, using a ipw3945 card. I can connect to a WEP network fine, but connecting to a WPA2-Enterprise network authenticating with EAP-TLS doesn't work automatically - I have to connect manually every time.

When connecting automatically /var/log/daemon.log contains:
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1/wireless): access point 'Knossos' is encrypted, but NO valid key exists. New key needed.
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1) New wireless user key requested for network 'Knossos'.
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) complete.
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1) New wireless user key for network 'Knossos' received.
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled...
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) started...
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) scheduled...
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) complete.
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) starting...
Oct 21 18:30:29 verona NetworkManager: <info> Activation (eth1/wireless): access point 'Knossos' is encrypted, but NO valid key exists. New key needed.
...which keeps repeating until I try to connect manually instead.

[Giovanni Lovato (heruan)]

I'm confirming this bug on several laptop on my network, WPA1/2 Enterprise with TLS or PEAP are working only when I create the connection the first time, when I reboot it keeps trying to connect without success and I have to recreate the connection manually.
AP involved: US Robotics 9106, D-Link DWL-2200AP, D-Link DWL-2100AP, D-Link DWL-G700AP.
Wireless NIC: most ipw3945, some ipw2100/2200.

Notice that with Feisty (network-manager 0.6.4 and a slightly different keyring management) all of that was working fine.

[Paul Novotny (paul-novotny)]

Anyone seen this thread?
http://<email address hidden>/msg06528.html

There is an attached patch in that thread for what I think is the problem here. Looks like the problem started with Network-Manager 0.6.5 and wasn't in 0.6.4. Don't know the status of this patch though, and when/if it will be integrated into Network Manager

[Giovanni Lovato (heruan)]

Gutsy had become stable with a default networking management system that makes difficult to connect to WPA1/2 enterprises networks.
My wireless nic specifications are:
Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
with `ipw3945' module from linux-restricted-modules v.2.6.22.4-14.9

[Alex Cornejo (acornejoc)]

I can confirm this to with gutsy (latest release and patches) with an ipw3945.

Why is the importance of this bug undecided? Seeing as WEP is inherently insecure (and there are plenty of tools and exploits for WEP), I believe this bug should be marked as serious.

[Basilio Kublik (sourcercito)]

I don't want to change the bug importance since i file the report, but since has been some replies and seems that i'm not the only one using this configuration, i'll change it.
by the way i'll include the syslog output provided in the initial report as an attachment, because having that much information directly in the report just make it more difficult to follow.

[muhammedc (muhammedc)]

I can confirm this behaviour.

I connect daily to a WPA [EAP-TLS] wifi network. In Feisty, this worked fine without problem. The password for the certificate file was being successfully read from gnome-keyring. Now, after upgrade (and I have replicated this problem on a clean install as well) to Gusty, it does not seem to read the password from gnome-keyring. The workaround is to click on "Connect to other wireless Network" and manually configure all settings again. The problem with this however is its time consuming and a pain in the @$$. Lets hope a fix comes in rather quickly...

[Piotr Gawrysiak (pgawrysiak)]

I have the same problem - but connecting to WPA Personal (using atheros). NM asks for a password after every reboot. It seems also that the keyring configuration is somehow broken. In keyring manager an entry related to nm-applet seem to unnamed (see attached screenshot). BTW - perhaps also bug 150704 is related?

[Giovanni Lovato (heruan)]

I assigned this bug to the maintainer of the package. It should be solved as soon as possible, please! It's preventing many people passing to Ubuntu/Linux on my WPA2 Enterprise network!

[Sarah Kowalik (hobbsee-deactivatedaccount)]

Please do not assign bugs to the Ubuntu Core developers team. Thankyou.

[Paul Novotny (paul-novotny)]

I think I have fixed it. Although I have no idea how to create a package for people to use, etc.

I downloaded the network-manager-gnome source from the ubuntu repository and applied the attached patch that I got from: http://<email address hidden>/msg06535.html

I believe the patch is already in NetworkManager trunk, but just hasn't been backported to ubuntu.

I compiled it using dpkg-buildpackage and installed. The keys for my WPA2 enterprise connection are now properly stored and retrieved from the keyring.

Sorry if I am short on details, but I am sure I did all this the wrong way and would appreciate if someone who knows better can apply and disseminate the patch.

[Steven Ayre (steveayre)]

I've created a debdiff on the package network-manager-applet (known as network-manager-gnome) which applies this patch.

See https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff for instructions on how to use this patch.

[Steven Ayre (steveayre)]

I should say that I've not had the opportunity to test this patch yet, so could someone else experiencing this problem try it and post here whether it works?

[Persio (persiobarros)]

Tried the patch. It is working here. I'm using WPA-EAP-TLS. Thanks.
Persio

[muhammedc (muhammedc)]

works like a charm here to... tried on fresh install...
-M

[Steven Ayre (steveayre)]

I can now confirm it works here too. :o) Excellent.

Now maybe whoever looks after this package can get it released as an update through apt...

[Giovanni Lovato (heruan)]

Maybe I'm redundant but some time ago I updated on my repository the network-manager packages with the patch appeared on the NM mailing list. It works for me.
You could add my repository with:

deb http://packages.aldu.net/ubuntu gutsy main restricted universe multiverse
deb-src http://packages.aldu.net/ubuntu gutsy main restricted universe multiverse

and then apt-get update/upgrade to get the patched NM.
Attached you find the patch I applied on the package.

[Pirouette Cacahuète (lissyx)]

I've tried the proposed patch, It works for me.

But I'm experiencing a strange behavior. At first connection attempt, it asks me to configure the wireless connection. If I cancel this, and I click on NetworkManager Applet to select the same Wireless network, then it connects correctly, without asking for configuration.

And If I do the last part (clicking the wireless network in the applet) right after getting logged on, then, It works like a charm, and don't ask me to reconfigure ...

[Tom (tom-ranson)]

Hi all,

Can confirm that the patch works for me also.

Cheers,

Tom

[burcin (burcin)]

I have also seen this problem after upgrading to gutsy. The packages from comment 38 work fine.

[Matthew L. Dailey (matthew-l-dailey)]

I can confirm this bug on a fresh install of gutsy on a Dell D600 with the BCM4306 wireless card. I applied the debdiff from comment 33 and this fixes the problem - I can now go back and forth between wired and my WPA2 Enterprise wireless without trouble.

From the looks of it, this patch has not made it into either gutsy or hardy, but hopefully it will soon.

Alexander - let us know if there's anything else you need to help get this resolved.

[Matthew L. Dailey (matthew-l-dailey)]

One more data point...I just did a fresh install of hardy alpha 2 on my Dell D600/BCM4306 and the bug is still present in the 0.6.5-0ubuntu11 version.

The good news is that the same patch that worked for 0.6.5-0ubuntu10 also works for this version, too.

Also, in case it saves anyone some grief, the b43legacy driver was accidentally excluded from the hardy kernel in alpha 2 (https://bugs.launchpad.net/bugs/178409), so you'll need to build it manually. The fix is committed, though. :-)

[Launchpad Janitor (janitor)]

This bug was fixed in the package network-manager - 0.6.6~rc2-0ubuntu1

---------------
network-manager (0.6.6~rc2-0ubuntu1) hardy; urgency=low

  * new upstream release 0.6.6 RC (LP: #197538); fixes various bugs:
    - LP: #40232, #41134, #75554, #82113, #107598, #118439, #132473
  * drop patches applied upstream
    - drop debian/patches/04-if_fix.patch
    - drop debian/patches/11-man_page_sh_name.patch
    - drop debian/patches/24pp_svn2578-gnome354565-fix-ethernet-link-detection-races.patch
    - drop debian/patches/24pp_svn2579-sleep-1-second-to-stabilize-if.patch
    - drop debian/patches/24pp_svn2591_Ensure-the-device-is-up-stage3.patch
    - drop debian/patches/24pp_svn2604_Add-HAL-based-rfkill-support.patch
    - drop debian/patches/24pp_svn2605-gnome354565-dont-up-notwired-interfaces.patch
    - drop debian/patches/24pp_svn2618_set-hardware-RF-to-enabled-if-no-killswitches.patch
    - drop debian/patches/24pp_svn2754-lp101857-endianess.patch
    - drop debian/patches/41c_ubuntu-fixup--get_mode_always_fails_typo_fix.patch
    - drop debian/patches/41e_fix_vpn_ftbfs_dont_disable_gnome_deprecated.patch
    - drop debian/patches/41m_unref_dbus_connection_on_shutdown.patch
    - update debian/patches/series
  * refresh patch because of renamed NetworkManagerDispatcher manpage
    - update debian/patches/06-dispatch_more_events.patch
  * drop driver specific tweaks assuming that wext should be fine for most
    drivers nowadays
    - drop debian/patches/13-rml-wpa-workarounds.patch
    - drop debian/patches/14-j-hostap-supplicant-driver.patch
    - drop debian/patches/43b_lp181232_save_kernel_driver_check.patch
    - update debian/patches/series
  * simply unbittrotted patches
    - update debian/patches/41k_20_sec_wireless_link_timeout.patch
    - update debian/patches/41t_nm_device_wireless_index_ctrl_sockets_by_run_count.patch
    - update debian/patches/41u_custom_timeout_for_some_wpa_ctrl_operations.patch
  * don't use run count for global ctrl socket anymore
    - update debian/patches/41t_nm_device_wireless_index_ctrl_sockets_by_run_count.patch
  * try to drop hidden AP tweaks (lets hope that scan_capa patch in 2.6.24
    fixes this)
    - drop debian/patches/42a_lp50214_gnome464215_fix_hidden.patch
    - update debian/patches/series
  * fix manpage path for NetworkManager and NetworkManagerDispatcher
    - update debian/network-manager.manpages

 -- Alexander Sack <email address hidden> Wed, 05 Mar 2008 19:06:19 +0100

[Ton Biegstraaten (ton-biegstraaten)]

For me it started just now.
Sunday I upgraded from Gutsy to Hardy using the update manager and from then on Network manager does not remember my WPA2 enterprise settings. At home there is no problem.
regards,
Ton Biegstraaten

[Ton Biegstraaten (ton-biegstraaten)]

To be precise, at home I have wep132, not wpa2 enterprise