PEAP or WPA-Enterprise not accessible
Hello togehter, I would like to know that a network-manager (especially the nm-tray) need to offer Enterprise connections with PEAP (e.g. for "eduroam" WLAN)? The background of my question: In a usual Debian bullsey (stable, 11) the nm is able to connect to "eduroam" with PEAP etc. No problem there. But I also have a minimal Debian bullsey (image for raspberry pi 4 from raspi.debian.net) with no X and no default user. I added a user myself and installed xfce and network-manager. I can connect to usual home network WLANs (WPA2). Then I tried to create a new connection via the nm-tray symbol to a PEAP (WPA-Enterprise?). The problem is that "PEAP" is not offered to my. It is missing in the "security" drop down menu. Also WPA-Enterprise is missing. I assume that some components are missing. But searching the Debian repository I got no hint what could it be. Do you have any idea? Kind Christian ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: how to disable WiFi / wpa-supplicant so hostapd can be used ?
Thank You so much, Thomas, for the most useful info ! RE: > Patch welcome to properly handle the release of a device > by setting it unmanaged. I will investigate this and see what I can do to improve management of wpa_supplicant (W_S) & wireless interfaces. I'd also like to develop a patch to make NM fully hostapd aware , so that the code realizes that use of W_S and hostapd are mutually exclusive for an interface , and which add settings for fully setting up & managing hostapd as well as W_S . And to allow switching between hostpd & W_S modes. hostapd probably needs its own module to manage things like providing dhcp service to connecting usits - I've been using static IP because I only have a few connecting devices - happily Android phones do allow connections to WEP APs with a static IP . But full Address Pool & DHCP server mgmt is needed for arbitrarily large numbers of connecting units. And the NM GUIs / applets would need changes to support the new hostapd settings . On 21/07/2021, Thomas Haller wrote: > On Tue, 2021-07-20 at 22:04 +0100, Jason Vas Dias via networkmanager- > list wrote: >> If I do : >> # nmcli radio wifi off >> , it disassociates the PHY for the device and I have to >> 'rfkill $id unblock' . >> If I reenable wireless, and do >> # systemctl stop wpa_supplicant >> # mv /usr/sbin/wpa_supplicant /usr/sbin/wpa_supplicant.bin >> after starting NM, then I can run hostapd . >> I have to remember to move wpa_supplicant back after I stop >> using hostapd . >> Please add support for enabling either hostapd or wpa_supplicant, >> not both, to NM = or is there some way of disabling running the >> wpa_supplicant service only, without rfkill ? > > Hi, > > > configure the device as unmanaged. > > Temporarily, with `nmcli device set wlan0 managed no` > > > Permanently, there are several means (udev rules, config files). the > best seems to be a file > > /etc/NetworkManager/conf.d/90-wlan-unmanaged.conf > > with > > [device-90-wlan-unmanaged] > match-device=interface-name:wlan0 > managed=0 > > see `man NetworkManager.conf`. > > > If you do it that way, you can still override it at runtime with `nmcli > device set wlan0 managed yes`. > > > > I think `nmcli device set wlan0 managed yes` may not sufficiently > instruct wpa_supplicant to let go of the device. That means, you still > might need `systemctl stop wpa_supplicant.service`. Patch welcome to > properly handle the release of a device by setting it unmanaged. > > > > best, > Thomas > > >> >> >> On 20/07/2021, Jason Vas Dias wrote: >> > >> > Good day - >> > >> > Whenever I try to run hostapd, NM still runs wpa-supplicant, >> > which periodically tries to put the WiFi interface into scanning >> > mode, which messes up the hostapd session . >> > >> > Please is there a config file setting or applet interaction >> > to disable wpa-supplicant (and maybe configure & run hostapd) ? >> > >> > I'd like NM to start dhclient on my Wired interface, and >> > be able to bring up my L2TP VPN, but leave the Wireless >> > interface entirely alone. >> > >> > Any way to do this in NetworkManager.conf or GUI ? >> > >> > Thanks in advance for any replies, >> > Best Regards, >> > Jason >> > >> ___ >> networkmanager-list mailing list >> networkmanager-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/networkmanager-list >> > > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: how to disable WiFi / wpa-supplicant so hostapd can be used ?
On Tue, 2021-07-20 at 22:04 +0100, Jason Vas Dias via networkmanager- list wrote: > If I do : > # nmcli radio wifi off > , it disassociates the PHY for the device and I have to > 'rfkill $id unblock' . > If I reenable wireless, and do > # systemctl stop wpa_supplicant > # mv /usr/sbin/wpa_supplicant /usr/sbin/wpa_supplicant.bin > after starting NM, then I can run hostapd . > I have to remember to move wpa_supplicant back after I stop > using hostapd . > Please add support for enabling either hostapd or wpa_supplicant, > not both, to NM = or is there some way of disabling running the > wpa_supplicant service only, without rfkill ? Hi, configure the device as unmanaged. Temporarily, with `nmcli device set wlan0 managed no` Permanently, there are several means (udev rules, config files). the best seems to be a file /etc/NetworkManager/conf.d/90-wlan-unmanaged.conf with [device-90-wlan-unmanaged] match-device=interface-name:wlan0 managed=0 see `man NetworkManager.conf`. If you do it that way, you can still override it at runtime with `nmcli device set wlan0 managed yes`. I think `nmcli device set wlan0 managed yes` may not sufficiently instruct wpa_supplicant to let go of the device. That means, you still might need `systemctl stop wpa_supplicant.service`. Patch welcome to properly handle the release of a device by setting it unmanaged. best, Thomas > > > On 20/07/2021, Jason Vas Dias wrote: > > > > Good day - > > > > Whenever I try to run hostapd, NM still runs wpa-supplicant, > > which periodically tries to put the WiFi interface into scanning > > mode, which messes up the hostapd session . > > > > Please is there a config file setting or applet interaction > > to disable wpa-supplicant (and maybe configure & run hostapd) ? > > > > I'd like NM to start dhclient on my Wired interface, and > > be able to bring up my L2TP VPN, but leave the Wireless > > interface entirely alone. > > > > Any way to do this in NetworkManager.conf or GUI ? > > > > Thanks in advance for any replies, > > Best Regards, > > Jason > > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: how to disable WiFi / wpa-supplicant so hostapd can be used ?
If I do : # nmcli radio wifi off , it disassociates the PHY for the device and I have to 'rfkill $id unblock' . If I reenable wireless, and do # systemctl stop wpa_supplicant # mv /usr/sbin/wpa_supplicant /usr/sbin/wpa_supplicant.bin after starting NM, then I can run hostapd . I have to remember to move wpa_supplicant back after I stop using hostapd . Please add support for enabling either hostapd or wpa_supplicant, not both, to NM = or is there some way of disabling running the wpa_supplicant service only, without rfkill ? On 20/07/2021, Jason Vas Dias wrote: > > Good day - > > Whenever I try to run hostapd, NM still runs wpa-supplicant, > which periodically tries to put the WiFi interface into scanning > mode, which messes up the hostapd session . > > Please is there a config file setting or applet interaction > to disable wpa-supplicant (and maybe configure & run hostapd) ? > > I'd like NM to start dhclient on my Wired interface, and > be able to bring up my L2TP VPN, but leave the Wireless > interface entirely alone. > > Any way to do this in NetworkManager.conf or GUI ? > > Thanks in advance for any replies, > Best Regards, > Jason > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
how to disable WiFi / wpa-supplicant so hostapd can be used ?
Good day - Whenever I try to run hostapd, NM still runs wpa-supplicant, which periodically tries to put the WiFi interface into scanning mode, which messes up the hostapd session . Please is there a config file setting or applet interaction to disable wpa-supplicant (and maybe configure & run hostapd) ? I'd like NM to start dhclient on my Wired interface, and be able to bring up my L2TP VPN, but leave the Wireless interface entirely alone. Any way to do this in NetworkManager.conf or GUI ? Thanks in advance for any replies, Best Regards, Jason ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli can't astablish connection to radius server with wpa eap tls
On Wed, Mar 07, 2018 at 10:28:18AM +0100, Iris Fiedler wrote: > Hi, > > I found my errror. My radius server had a wrong configuration and didn't send > the accepted response. So the network manager didn't received it and printed > an error. Hi, good to know! > Thank you for your help. You're welcome. Beniamino ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli can't astablish connection to radius server with wpa eap tls
Hi, I found my errror. My radius server had a wrong configuration and didn't send the accepted response. So the network manager didn't received it and printed an error. Thank you for your help. Iris ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli can't astablish connection to radius server with wpa eap tls
Hi,That EAP-TLS isn't supporting passwords maybe the case.I configure my freeradius server without passwords and set in nmcli the password-flag to 4 (no password required).I got the same error as if I had before.nmcli device connect wlan0 Passwords or encryption keys are required to access the wireless network 'Linksys02355'. Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli cannot ask without '--ask' option. Error: Connection activation failed: (7) Secrets were required, but not providedAlthough my radius server tells me that it accepts the authentication send from nmcli.Is there something else that I'm missing?IrisAm 21.02.2018 09:24 schrieb Beniamino Galvani <bgalv...@redhat.com>:On Mon, Feb 19, 2018 at 12:59:04PM +0100, Iris Fiedler wrote: Hi, > freeRADIUS: 3.0.15 (on a different PC with OpenSuse 42.3) > Konfigured as wpa-eap tls with identity and password. EAP-TLS doesn't support passwords AFAIK. Perhaps you mean EAP-TTLS? > radius-tls.log > (35) Invalid user: [testUser1/] (from client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) > (35) Rejected in post-auth: [testUser1/] (from client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) > (35) Login incorrect: [testUser1/] (from client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) > > As you can see the User-Password attribute is missing. Although the password in nmcli was set. > > This is what nmcli is responding with: > nmcli device connect wlan0 > Passwords or encryption keys are required to access the wireless network 'Linksys02355'. > Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli cannot ask without '--ask' option. > Error: Connection activation failed: (7) Secrets were required, but not provided. > > nmcli -a device connect wlan0 > Passwords or encryption keys are required to access the wireless network 'Linksys02355'. > Identity (802-1x.identity): testUser1 > Passwords or encryption keys are required to access the wireless network 'Linksys02355'. > Private key password (802-1x.private-key-password): > Passwords or encryption keys are required to access the wireless network 'Linksys02355'. > Identity (802-1x.identity): testUser1 > > Even here no user password is asked!!! > > I created a new user without password. Although the radius server accepted the authentication no connection was established!!! > > It confused me so I checkt if a wpa eap ttls-pap would work. > After reconfiguration of nmcli and radius server it worked without problems. > So I think this is only a tls problem. Yes, EAP-TLS only uses certificates and not passwords. Beniamino ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli can't astablish connection to radius server with wpa eap tls
On Mon, Feb 19, 2018 at 12:59:04PM +0100, Iris Fiedler wrote: Hi, > freeRADIUS: 3.0.15 (on a different PC with OpenSuse 42.3) > Konfigured as wpa-eap tls with identity and password. EAP-TLS doesn't support passwords AFAIK. Perhaps you mean EAP-TTLS? > radius-tls.log > (35) Invalid user: [testUser1/] (from client > 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) > (35) Rejected in post-auth: [testUser1/] (from > client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) > (35) Login incorrect: [testUser1/] (from client > 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) > > As you can see the User-Password attribute is missing. Although the password > in nmcli was set. > > This is what nmcli is responding with: > nmcli device connect wlan0 > Passwords or encryption keys are required to access the wireless network > 'Linksys02355'. > Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli > cannot ask without '--ask' option. > Error: Connection activation failed: (7) Secrets were required, but not > provided. > > nmcli -a device connect wlan0 > Passwords or encryption keys are required to access the wireless network > 'Linksys02355'. > Identity (802-1x.identity): testUser1 > Passwords or encryption keys are required to access the wireless network > 'Linksys02355'. > Private key password (802-1x.private-key-password): > Passwords or encryption keys are required to access the wireless network > 'Linksys02355'. > Identity (802-1x.identity): testUser1 > > Even here no user password is asked!!! > > I created a new user without password. Although the radius server accepted > the authentication no connection was established!!! > > It confused me so I checkt if a wpa eap ttls-pap would work. > After reconfiguration of nmcli and radius server it worked without problems. > So I think this is only a tls problem. Yes, EAP-TLS only uses certificates and not passwords. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
nmcli can't astablish connection to radius server with wpa eap tls
Debian: 9.3 network-manager: 1.6.2-3 cat /etc/NetworkManager/system-connections/wlan0 [connection] id=wlan0x0 uuid=ec4bcd13-d3e1-4707-b844-9b8c3821b7ac type=wifi interface-name=wlan0 permissions= [wifi] mac-address=80:1F:02:F2:2B:53 mac-address-blacklist= mode=infrastructure ssid=Linksys02355 [wifi-security] auth-alg=open key-mgmt=wpa-eap [802-1x] ca-cert=/var/opt/telemotive/etc/cert/ca.pem client-cert=/var/opt/telemotive/etc/cert/client.p12 eap=tls; identity=testUser1 password=testUser11 private-key=/var/opt/telemotive/etc/cert/client.p12 private-key-password=testCert1 [ipv4] dns-search= method=auto never-default=true [ipv6] addr-gen-mode=stable-privacy dns-search= method=auto never-default=true freeRADIUS: 3.0.15 (on a different PC with OpenSuse 42.3) Konfigured as wpa-eap tls with identity and password. radius-tls.log (35) Invalid user: [testUser1/] (from client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) (35) Rejected in post-auth: [testUser1/] (from client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) (35) Login incorrect: [testUser1/] (from client 192.168.2.254/16 port 10 cli 801f02f22b53 via TLS tunnel) As you can see the User-Password attribute is missing. Although the password in nmcli was set. This is what nmcli is responding with: nmcli device connect wlan0 Passwords or encryption keys are required to access the wireless network 'Linksys02355'. Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli cannot ask without '--ask' option. Error: Connection activation failed: (7) Secrets were required, but not provided. nmcli -a device connect wlan0 Passwords or encryption keys are required to access the wireless network 'Linksys02355'. Identity (802-1x.identity): testUser1 Passwords or encryption keys are required to access the wireless network 'Linksys02355'. Private key password (802-1x.private-key-password): Passwords or encryption keys are required to access the wireless network 'Linksys02355'. Identity (802-1x.identity): testUser1 Even here no user password is asked!!! I created a new user without password. Although the radius server accepted the authentication no connection was established!!! It confused me so I checkt if a wpa eap ttls-pap would work. After reconfiguration of nmcli and radius server it worked without problems. So I think this is only a tls problem. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] wifi: enable WPA-*-SHA256 AKMs only when the supplicant supports them
On Wed, 2018-01-17 at 18:06 +0100, Beniamino Galvani wrote:
> Commit 87ec5e90fe79 ("supplicant: set key_mgmt independent of pmf
> value") enabled WPA-PSK-SHA256 or WPA-EAP-SHA256 even when the
> supplicant didn't support them, potentially causing connection
> failures. Instead, use the 'pmf' capability to detect when they can
> be enabled.
>
> Fixes: 87ec5e90fe79fcb2ac315cf1604e757dcab60bb9
> ---
Hi,
After ACK from Masashi Honma, merged to master:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a0cf4664822142a4c2767256e28be59e643add7d
Thanks!
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] wifi: enable WPA-*-SHA256 AKMs only when the supplicant supports them
On 2018/01/18 05:52, Masashi Honma wrote:
> On 2018/01/18 02:06, Beniamino Galvani wrote:
>> Commit 87ec5e90fe79 ("supplicant: set key_mgmt independent of pmf
>> value") enabled WPA-PSK-SHA256 or WPA-EAP-SHA256 even when the
>> supplicant didn't support them, potentially causing connection
>> failures. Instead, use the 'pmf' capability to detect when they can
>> be enabled.
>>
>> Fixes: 87ec5e90fe79fcb2ac315cf1604e757dcab60bb9
>> ---
>>
>> Hi,
>>
>> this patch fixes regressions discovered after the merge of FILS
>> patches by our nightly CI that runs on CentOS where wpa_supplicant is
>> compiled without 802.11w support.
>>
>> This patch fixes those regression. Comments welcome.
> Hi,
>
> I am sorry for regression...
>
> Though indeed using pmf capability works, I think using key_mgmt
> capability is better. I will try this at this week end.
By watching wpa_supplicant code, the pmf capability exists if and
only if WPA-PSK-SHA256 and WPA-EAP-SHA256 exists. So your patch
looks nice to me. Thanks !
Masashi Honma.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] wifi: enable WPA-*-SHA256 AKMs only when the supplicant supports them
On 2018/01/18 02:06, Beniamino Galvani wrote:
> Commit 87ec5e90fe79 ("supplicant: set key_mgmt independent of pmf
> value") enabled WPA-PSK-SHA256 or WPA-EAP-SHA256 even when the
> supplicant didn't support them, potentially causing connection
> failures. Instead, use the 'pmf' capability to detect when they can
> be enabled.
>
> Fixes: 87ec5e90fe79fcb2ac315cf1604e757dcab60bb9
> ---
>
> Hi,
>
> this patch fixes regressions discovered after the merge of FILS
> patches by our nightly CI that runs on CentOS where wpa_supplicant is
> compiled without 802.11w support.
>
> This patch fixes those regression. Comments welcome.
Hi,
I am sorry for regression...
Though indeed using pmf capability works, I think using key_mgmt
capability is better. I will try this at this week end.
Masashi Honma.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] wifi: enable WPA-*-SHA256 AKMs only when the supplicant supports them
On Wed, 2018-01-17 at 18:06 +0100, Beniamino Galvani wrote:
> Commit 87ec5e90fe79 ("supplicant: set key_mgmt independent of pmf
> value") enabled WPA-PSK-SHA256 or WPA-EAP-SHA256 even when the
> supplicant didn't support them, potentially causing connection
> failures. Instead, use the 'pmf' capability to detect when they can
> be enabled.
>
> Fixes: 87ec5e90fe79fcb2ac315cf1604e757dcab60bb9
> ---
>
> Hi,
>
> this patch fixes regressions discovered after the merge of FILS
> patches by our nightly CI that runs on CentOS where wpa_supplicant is
> compiled without 802.11w support.
>
> This patch fixes those regression. Comments welcome.
>
> Thanks,
> Beniamino
>
>
> src/devices/nm-device-ethernet.c | 2 +-
> src/devices/nm-device-macsec.c| 2 +-
> src/devices/wifi/nm-device-wifi.c | 42 ++---
> ---
> src/supplicant/nm-supplicant-config.c | 55
> +++
>
> diff --git a/src/supplicant/nm-supplicant-config.c
> b/src/supplicant/nm-supplicant-config.c
> index a2502bd7b..14f5cac82 100644
> --- a/src/supplicant/nm-supplicant-config.c
> +++ b/src/supplicant/nm-supplicant-config.c
> @@ -47,6 +47,8 @@ typedef struct {
> guint32ap_scan;
> gboolean fast_required;
> gboolean dispose_has_run;
> + gboolean support_pmf;
> + gboolean support_fils;
inside structs, could we use bool:1 bitfields?
> NMSupplicantConfig *
> -nm_supplicant_config_new (void)
> +nm_supplicant_config_new (gboolean support_pmf, gboolean
> support_fils)
> {
> - return g_object_new (NM_TYPE_SUPPLICANT_CONFIG, NULL);
> + NMSupplicantConfigPrivate *priv;
> + NMSupplicantConfig *self;
> +
> + self = g_object_new (NM_TYPE_SUPPLICANT_CONFIG, NULL);
> + priv = NM_SUPPLICANT_CONFIG_GET_PRIVATE (self);
> +
> + priv->support_pmf = support_pmf;
> + priv->support_fils = support_fils;
I always find it nice if nm_*_new() only calls g_object_new() and
nothing else. But that would requie to introduce G_PARAM_CONSTRUCT_ONLY
properties, to pass in the parameters. Clearly that is more hazzle then
it's worth, so ok.
Rest lgtm.
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] wifi: enable WPA-*-SHA256 AKMs only when the supplicant supports them
Commit 87ec5e90fe79 ("supplicant: set key_mgmt independent of pmf
value") enabled WPA-PSK-SHA256 or WPA-EAP-SHA256 even when the
supplicant didn't support them, potentially causing connection
failures. Instead, use the 'pmf' capability to detect when they can
be enabled.
Fixes: 87ec5e90fe79fcb2ac315cf1604e757dcab60bb9
---
Hi,
this patch fixes regressions discovered after the merge of FILS
patches by our nightly CI that runs on CentOS where wpa_supplicant is
compiled without 802.11w support.
This patch fixes those regression. Comments welcome.
Thanks,
Beniamino
src/devices/nm-device-ethernet.c | 2 +-
src/devices/nm-device-macsec.c| 2 +-
src/devices/wifi/nm-device-wifi.c | 42 ++--
src/supplicant/nm-supplicant-config.c | 55 +++
src/supplicant/nm-supplicant-config.h | 2 +-
src/supplicant/tests/test-supplicant-config.c | 24 +++-
6 files changed, 68 insertions(+), 59 deletions(-)
diff --git a/src/devices/nm-device-ethernet.c b/src/devices/nm-device-ethernet.c
index 54c8176f6..0e1ebcc6a 100644
--- a/src/devices/nm-device-ethernet.c
+++ b/src/devices/nm-device-ethernet.c
@@ -550,7 +550,7 @@ build_supplicant_config (NMDeviceEthernet *self,
mtu = nm_platform_link_get_mtu (nm_device_get_platform (NM_DEVICE
(self)),
nm_device_get_ifindex (NM_DEVICE
(self)));
- config = nm_supplicant_config_new ();
+ config = nm_supplicant_config_new (FALSE, FALSE);
security = nm_connection_get_setting_802_1x (connection);
if (!nm_supplicant_config_add_setting_8021x (config, security,
con_uuid, mtu, TRUE, error)) {
diff --git a/src/devices/nm-device-macsec.c b/src/devices/nm-device-macsec.c
index 4f2cbcca0..8b51f8ce6 100644
--- a/src/devices/nm-device-macsec.c
+++ b/src/devices/nm-device-macsec.c
@@ -222,7 +222,7 @@ build_supplicant_config (NMDeviceMacsec *self, GError
**error)
mtu = nm_platform_link_get_mtu (nm_device_get_platform (NM_DEVICE
(self)),
nm_device_get_ifindex (NM_DEVICE
(self)));
- config = nm_supplicant_config_new ();
+ config = nm_supplicant_config_new (FALSE, FALSE);
s_macsec = (NMSettingMacsec *)
nm_device_get_applied_setting (NM_DEVICE (self),
NM_TYPE_SETTING_MACSEC);
diff --git a/src/devices/wifi/nm-device-wifi.c
b/src/devices/wifi/nm-device-wifi.c
index 979f309dd..a7283b63a 100644
--- a/src/devices/wifi/nm-device-wifi.c
+++ b/src/devices/wifi/nm-device-wifi.c
@@ -2389,7 +2389,9 @@ build_supplicant_config (NMDeviceWifi *self,
s_wireless = nm_connection_get_setting_wireless (connection);
g_return_val_if_fail (s_wireless != NULL, NULL);
- config = nm_supplicant_config_new ();
+ config = nm_supplicant_config_new (
+ nm_supplicant_interface_get_pmf_support (priv->sup_iface) ==
NM_SUPPLICANT_FEATURE_YES,
+ nm_supplicant_interface_get_fils_support (priv->sup_iface) ==
NM_SUPPLICANT_FEATURE_YES);
/* Warn if AP mode may not be supported */
if ( g_strcmp0 (nm_setting_wireless_get_mode (s_wireless),
NM_SETTING_WIRELESS_MODE_AP) == 0
@@ -2431,26 +2433,6 @@ build_supplicant_config (NMDeviceWifi *self,
NM_SETTING_WIRELESS_SECURITY_PMF_OPTIONAL);
}
- /* Don't try to enable PMF on non-WPA networks */
- if (!NM_IN_STRSET (nm_setting_wireless_security_get_key_mgmt
(s_wireless_sec),
- "wpa-eap",
- "wpa-psk"))
- pmf = NM_SETTING_WIRELESS_SECURITY_PMF_DISABLE;
-
- /* Check if we actually support PMF */
- if (nm_supplicant_interface_get_pmf_support (priv->sup_iface)
!= NM_SUPPLICANT_FEATURE_YES) {
- if (pmf == NM_SETTING_WIRELESS_SECURITY_PMF_REQUIRED) {
- g_set_error_literal (error,
NM_SUPPLICANT_ERROR, NM_SUPPLICANT_ERROR_CONFIG,
-"Supplicant does not
support PMF");
- goto error;
- } else if (pmf ==
NM_SETTING_WIRELESS_SECURITY_PMF_OPTIONAL) {
- /* To be on the safe side, assume no support if
we can't determine
-* capabilities.
-*/
- pmf = NM_SETTING_WIRELESS_SECURITY_PMF_DISABLE;
- }
- }
-
/* Configure FILS (802.11ai) */
fils = nm_setting_wireless_security_get_fils (s_wireless_sec);
if (fils == NM_SETTING_WIRELESS_SECURITY_FILS_DEFAULT) {
@@ -2463,24 +2445
Re: [PATCH 1/1] device/wifi: drop messing with wpa-supplicant's support for MAC address randomization
On Tue, 2017-02-07 at 11:29 +0100, Beniamino Galvani wrote: > On Sun, Feb 05, 2017 at 11:18:08PM +0100, Thomas Haller wrote: > > We no longer use wpa_supplicant for MAC address randomization. > > Instead, NetworkManager > > handle it on it's own. It is actually important that supplicant > > does not interfere > > when setting the MAC address of the device. > > > > The code was only in effect when a PreassocMacAddr property exists, > > which is a recent feature so this wasn't unnoticed until now. > > > > Fixes: 767abfa69040c62ae1dc0989a77df8c5e0e489c1 > > Looks good to me. > > Beniamino Thanks. merged: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=0cb85f161ea332dc400d7e33071ca1f3dfafd730 Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/1] device/wifi: drop messing with wpa-supplicant's support for MAC address randomization
On Sun, Feb 05, 2017 at 11:18:08PM +0100, Thomas Haller wrote: > We no longer use wpa_supplicant for MAC address randomization. Instead, > NetworkManager > handle it on it's own. It is actually important that supplicant does not > interfere > when setting the MAC address of the device. > > The code was only in effect when a PreassocMacAddr property exists, > which is a recent feature so this wasn't unnoticed until now. > > Fixes: 767abfa69040c62ae1dc0989a77df8c5e0e489c1 Looks good to me. Beniamino signature.asc Description: PGP signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/1] device/wifi: drop messing with wpa-supplicant's support for MAC address randomization
We no longer use wpa_supplicant for MAC address randomization. Instead,
NetworkManager
handle it on it's own. It is actually important that supplicant does not
interfere
when setting the MAC address of the device.
The code was only in effect when a PreassocMacAddr property exists,
which is a recent feature so this wasn't unnoticed until now.
Fixes: 767abfa69040c62ae1dc0989a77df8c5e0e489c1
---
src/supplicant/nm-supplicant-interface.c | 84 +---
1 file changed, 2 insertions(+), 82 deletions(-)
diff --git a/src/supplicant/nm-supplicant-interface.c
b/src/supplicant/nm-supplicant-interface.c
index deaac77..c913a69 100644
--- a/src/supplicant/nm-supplicant-interface.c
+++ b/src/supplicant/nm-supplicant-interface.c
@@ -67,7 +67,6 @@ typedef struct {
gboolean has_credreq; /* Whether querying 802.1x credentials is
supported */
NMSupplicantFeature fast_support;
NMSupplicantFeature ap_support; /* Lightweight AP mode support */
- NMSupplicantFeature mac_randomization_support;
guint32max_scan_ssids;
guint32ready_count;
@@ -520,25 +519,6 @@ nm_supplicant_interface_set_fast_support
(NMSupplicantInterface *self,
}
static void
-set_preassoc_scan_mac_cb (GDBusProxy *proxy, GAsyncResult *result, gpointer
user_data)
-{
- NMSupplicantInterface *self;
- gs_unref_variant GVariant *variant = NULL;
- gs_free_error GError *error = NULL;
-
- variant = _nm_dbus_proxy_call_finish (proxy, result,
- G_VARIANT_TYPE ("()"),
- );
- if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
- return;
-
- self = NM_SUPPLICANT_INTERFACE (user_data);
- if (error)
- _LOGW ("failed to enable scan MAC address randomization (%s)",
error->message);
- iface_check_ready (self);
-}
-
-static void
iface_introspect_cb (GDBusProxy *proxy, GAsyncResult *result, gpointer
user_data)
{
NMSupplicantInterface *self;
@@ -562,24 +542,6 @@ iface_introspect_cb (GDBusProxy *proxy, GAsyncResult
*result, gpointer user_data
/* The ProbeRequest method only exists if AP mode has been
enabled */
if (strstr (data, "ProbeRequest"))
priv->ap_support = NM_SUPPLICANT_FEATURE_YES;
-
- if (strstr (data, "PreassocMacAddr")) {
- priv->mac_randomization_support =
NM_SUPPLICANT_FEATURE_YES;
-
- /* Turn on MAC randomization during scans by default */
- priv->ready_count++;
- g_dbus_proxy_call (priv->iface_proxy,
- DBUS_INTERFACE_PROPERTIES ".Set",
- g_variant_new ("(ssv)",
-
WPAS_DBUS_IFACE_INTERFACE,
- "PreassocMacAddr",
- g_variant_new_string
("0")),
- G_DBUS_CALL_FLAGS_NONE,
- -1,
- priv->init_cancellable,
- (GAsyncReadyCallback)
set_preassoc_scan_mac_cb,
- self);
- }
}
iface_check_ready (self);
@@ -790,8 +752,7 @@ on_iface_proxy_acquired (GDBusProxy *proxy, GAsyncResult
*result, gpointer user_
(GAsyncReadyCallback) iface_check_netreply_cb,
self);
- if (priv->ap_support == NM_SUPPLICANT_FEATURE_UNKNOWN ||
- priv->mac_randomization_support == NM_SUPPLICANT_FEATURE_UNKNOWN) {
+ if (priv->ap_support == NM_SUPPLICANT_FEATURE_UNKNOWN) {
/* If the global supplicant capabilities property is not
present, we can
* fall back to checking whether the ProbeRequest method is
supported. If
* neither of these works we have no way of determining if AP
mode is
@@ -1226,33 +1187,6 @@ add_network (NMSupplicantInterface *self)
}
static void
-set_mac_randomization_cb (GDBusProxy *proxy, GAsyncResult *result, gpointer
user_data)
-{
- NMSupplicantInterface *self;
- NMSupplicantInterfacePrivate *priv;
- gs_unref_variant GVariant *reply = NULL;
- gs_free_error GError *error = NULL;
-
- reply = g_dbus_proxy_call_finish (proxy, result, );
- if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
- return;
-
- self = NM_SUPPLICANT_INTERFACE (user_data);
- priv = NM_SUPPLICANT_INTERFACE_GET_PRIVATE (self);
-
- if (!reply) {
- g_dbus_error_strip_remote_error (error);
- _LOGW ("couldn't send MAC randomization mode to the supplicant
interface:
Re: nm-connection-editor forgets WPA password
On Tue, 2016-06-07 at 19:29 +0200, Thomas Haller wrote: > On Tue, 2016-06-07 at 19:10 +0200, Bastien Nocera wrote: > > Hey, > > > > I get problems when trying this with both nm-connection-editor and > > gnome-control-center, so it's probably a problem in the common > > code. > > > > 1. Connect to a known wireless network with WPA/WPA2 Personal > > authentication > > 2. Once connected, edit the connection > > 3. In "Wi-Fi Security" select "Dynamic WEP", then "Tunneled TLS" as > > the > > authentication, enter bogus values in "anonymous identity", > > "username" > > and password". Tick the "No CA certificate is required" checkbox. > > 4. "nmcli connection down " > > 5. "nmcli connection up " (you can press Ctrl+C when > > you're bored) > > 6. Re-edit the connection > > 7. Select WPA/WPA Personal in "Wi-Fi Security", and put in the > > actual > > Wi-Fi password > > 8. Run "nmcli connection up " again > > > > " > > Passwords or encryption keys are required to access the wireless > > network 'test'. > > Warning: password for '802-11-wireless-security.psk' not given in > > 'passwd-file' and nmcli cannot ask without '--ask' option. > > " > > > > It will then ask for the password in a loop, and never allow > > connection. > > > > Ideas? Do you prefer this being filed in bugzilla? > > > > > could this be > https://git.gnome.org/browse/network-manager-applet/commit/?id=c21d56 > dd22057103c8125a49307b4ff47b5b644d I've moved the bug to: https://bugzilla.gnome.org/show_bug.cgi?id=767449 Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-connection-editor forgets WPA password
On Tue, 2016-06-07 at 19:29 +0200, Thomas Haller wrote: > On Tue, 2016-06-07 at 19:10 +0200, Bastien Nocera wrote: > > Hey, > > > > I get problems when trying this with both nm-connection-editor and > > gnome-control-center, so it's probably a problem in the common > > code. > > > > 1. Connect to a known wireless network with WPA/WPA2 Personal > > authentication > > 2. Once connected, edit the connection > > 3. In "Wi-Fi Security" select "Dynamic WEP", then "Tunneled TLS" as > > the > > authentication, enter bogus values in "anonymous identity", > > "username" > > and password". Tick the "No CA certificate is required" checkbox. > > 4. "nmcli connection down " > > 5. "nmcli connection up " (you can press Ctrl+C when > > you're bored) > > 6. Re-edit the connection > > 7. Select WPA/WPA Personal in "Wi-Fi Security", and put in the > > actual > > Wi-Fi password > > 8. Run "nmcli connection up " again > > > > " > > Passwords or encryption keys are required to access the wireless > > network 'test'. > > Warning: password for '802-11-wireless-security.psk' not given in > > 'passwd-file' and nmcli cannot ask without '--ask' option. > > " > > > > It will then ask for the password in a loop, and never allow > > connection. > > > > Ideas? Do you prefer this being filed in bugzilla? > > > > > could this be > https://git.gnome.org/browse/network-manager-applet/commit/?id=c21d56 > dd22057103c8125a49307b4ff47b5b644d No, that's already in my tree. It asks for a password repeatedly, even when it is correct. I think that NetworkManager might think it's a different kind of connection compared to what nm-connection-editor thinks. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-connection-editor forgets WPA password
On Tue, 2016-06-07 at 19:10 +0200, Bastien Nocera wrote: > Hey, > > I get problems when trying this with both nm-connection-editor and > gnome-control-center, so it's probably a problem in the common code. > > 1. Connect to a known wireless network with WPA/WPA2 Personal > authentication > 2. Once connected, edit the connection > 3. In "Wi-Fi Security" select "Dynamic WEP", then "Tunneled TLS" as > the > authentication, enter bogus values in "anonymous identity", > "username" > and password". Tick the "No CA certificate is required" checkbox. > 4. "nmcli connection down " > 5. "nmcli connection up " (you can press Ctrl+C when > you're bored) > 6. Re-edit the connection > 7. Select WPA/WPA Personal in "Wi-Fi Security", and put in the actual > Wi-Fi password > 8. Run "nmcli connection up " again > > " > Passwords or encryption keys are required to access the wireless > network 'test'. > Warning: password for '802-11-wireless-security.psk' not given in > 'passwd-file' and nmcli cannot ask without '--ask' option. > " > > It will then ask for the password in a loop, and never allow > connection. > > Ideas? Do you prefer this being filed in bugzilla? > could this be https://git.gnome.org/browse/network-manager-applet/commit/?id=c21d56dd22057103c8125a49307b4ff47b5b644d Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
nm-connection-editor forgets WPA password
Hey, I get problems when trying this with both nm-connection-editor and gnome-control-center, so it's probably a problem in the common code. 1. Connect to a known wireless network with WPA/WPA2 Personal authentication 2. Once connected, edit the connection 3. In "Wi-Fi Security" select "Dynamic WEP", then "Tunneled TLS" as the authentication, enter bogus values in "anonymous identity", "username" and password". Tick the "No CA certificate is required" checkbox. 4. "nmcli connection down " 5. "nmcli connection up " (you can press Ctrl+C when you're bored) 6. Re-edit the connection 7. Select WPA/WPA Personal in "Wi-Fi Security", and put in the actual Wi-Fi password 8. Run "nmcli connection up " again " Passwords or encryption keys are required to access the wireless network 'test'. Warning: password for '802-11-wireless-security.psk' not given in 'passwd-file' and nmcli cannot ask without '--ask' option. " It will then ask for the password in a loop, and never allow connection. Ideas? Do you prefer this being filed in bugzilla? Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
WPA Enterprise WiFi testing with freeradius
Hi,
The following is a brain-dump of what I've been using to test all the
WPA Enterprise stuff using freeradius.
1) install freeradius 3.0 or higher
2) in /etc/raddb/certs there is a 'bootstrap' script. You can use this
to generate testing certificates for the CA and the RADIUS server. It
gives you ca.pem and server.pem. The default files it writes out
should be automatically selected by the default configuration in
/etc/raddb/mods-enabled/eap.
3) in /etc/raddb/certs you can 'make client.pem' to get a client
certificate for TLS configuration on your test machine. Copy it to
your test machine (along with ca.pem) and use it for TLS
authentication.
4) add an entry for your AP to the end of clients.conf, which will look
like this:
client 192.168.0.5 {
secret = testing123
shortname = my-ap
}
5) on your AP set the authentication to WPA Enterprise or whatever, and
then in the RADIUS configuration enter the "secret" from step #4 and
the RADIUS server's IP. You shouldn't need to touch port settings,
they are almost always correct with the default of 1812.
6) add a user to users.conf, looking something like this:
"Bill Smith" Cleartext-Password := ""
The password is the same thing you'll enter in NetworkManager for any
of the PAP, CHAP, MSCHAP, PWD, GTC, etc inner eap methods that TTLS,
PEAP, and FAST use.
(side-note: if you happen to have a 3Com WXR-series you'll want to add
right below the user/password line:
Egress-VLAN-Name:0 = "default",
3Com-VLAN-Name:0 = "default"
or the client can't talk to anything else)
7) you might want to edit radiusd.conf to "auth", "auth_badpass", and
"auth_goodpass" in the "log" section for debugging.
8) make sure that 'default' and 'inner-tunnel' are symlinked from
/etc/raddb/sites-available into /etc/raddb/sites-enabled. Make sure
'eap' is symlinked from mods-available/ into mods-enabled/
9) copy /etc/raddb/certs/client.pem and /etc/raddb/certs/ca.pem to your
test client. ca.pem will be used whenever a CA certificate is
required, and client.pem should be used with TLS or TTLS/TLS
authentication.
10) you may need to change /etc/raddb/mods-enabled/eap and set
"default_eap_type" to force a specific type of EAP while testing.
==
When things go wrong...
* add "-x" to the freeradius command-line in the systemd or initd
service files for more logging
* look at /var/log/radius*
* run the client's wpa_supplicant in full debug mode (-dddt) so you can see the
output; all the radius stuff happens after the ASSOCIATING state and before the
4-way handshake
* make sure you have built wpa_supplicant with all the authentication options!!
eg, its going to fail if you try EAP-PWD but haven't built the supplicant with
CONFIG_EAP_PWD
* double-check all your passwords
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA/WPA2 Enterprise details
On Monday 14 of September 2015 12:51:01 Jirka Klimes wrote: > On Mon, 14 Sep 2015 10:36:59 +0200 > > Jan Grulich <jgrul...@redhat.com> wrote: > > Hi, > > > > I'm trying to improve our WPA/WPA2 Enterprise support in KDE and I > > have few questions regarding 802-11x security setting. > > > > 1) When phase2-foo properties should be used instead of just foo > > properties (e.g phase2-private-key/private-key) ? In implementation > > of gnome-applet I see they are used when phase2 property is set to > > true, but it's always set to false as I can see. > > phase2-foo properties are used for EAP methods that have 2 phases. In > the first phase a tunnel is established, and then, in phase 2, the > authentication is done inside the tunnel using the inner method that > uses the phase2 properties. > NM uses that for PEAP, TTLS and FAST EAP methods for which you can > specify inner methods. > > I am not aware of gnome-shell applet implementation. You can look at > nm-applet/nm-connection-editor code here: > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-securi > ty/eap-method.c > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-secur > ity/eap-method-peap.c I actually meant nm-applet and not gnome-applet. I see only phase2_auth property used in PEAP, FAST PEAP and TTLS, but in TLS there are other phase2-foo properties used only when parent->phase2 is true. I just don't understand why this property is always set to false in https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/wireless-security.c[1] by passing false as third parameter to eap_method_tls_new (line 428). Is there any place where this property gets changed? > > 2) Are subjectMatch/altSubjectMatch properties still valid and used? > > I don't see this implemented in gnome-applet, but we had this > > implemented in the old KDE networkmanagement applet. I'm asking > > because we got a bug report about missing implementation of these > > properties for the new applet and I would like to be sure how this > > should be implemented. > > https://developer.gnome.org/NetworkManager/1.0/ref-settings.html > > Yes, the properties are valid and used for matching the certificates. > They are passed to wpa_supplicant that performs the certificates > matching. > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/supplican > t-manager/nm-supplicant-config.c#n971 > > It seems that nm-connection-editor/nn-applet did not handle the > properties. But they can be set via nmcli. > > Jirka > Regards, Jan [1] https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/wireless-security.c ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA/WPA2 Enterprise details
On Mon, 14 Sep 2015 10:36:59 +0200 Jan Grulich <jgrul...@redhat.com> wrote: > Hi, > > I'm trying to improve our WPA/WPA2 Enterprise support in KDE and I > have few questions regarding 802-11x security setting. > > 1) When phase2-foo properties should be used instead of just foo > properties (e.g phase2-private-key/private-key) ? In implementation > of gnome-applet I see they are used when phase2 property is set to > true, but it's always set to false as I can see. > phase2-foo properties are used for EAP methods that have 2 phases. In the first phase a tunnel is established, and then, in phase 2, the authentication is done inside the tunnel using the inner method that uses the phase2 properties. NM uses that for PEAP, TTLS and FAST EAP methods for which you can specify inner methods. I am not aware of gnome-shell applet implementation. You can look at nm-applet/nm-connection-editor code here: https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/eap-method.c https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/eap-method-peap.c > 2) Are subjectMatch/altSubjectMatch properties still valid and used? > I don't see this implemented in gnome-applet, but we had this > implemented in the old KDE networkmanagement applet. I'm asking > because we got a bug report about missing implementation of these > properties for the new applet and I would like to be sure how this > should be implemented. > https://developer.gnome.org/NetworkManager/1.0/ref-settings.html Yes, the properties are valid and used for matching the certificates. They are passed to wpa_supplicant that performs the certificates matching. http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/supplicant-manager/nm-supplicant-config.c#n971 It seems that nm-connection-editor/nn-applet did not handle the properties. But they can be set via nmcli. Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA/WPA2 Enterprise details
On Mon, 14 Sep 2015 13:23:14 +0200 Jan Grulich <jgrul...@redhat.com> wrote: > On Monday 14 of September 2015 12:51:01 Jirka Klimes wrote: > > On Mon, 14 Sep 2015 10:36:59 +0200 > > > > Jan Grulich <jgrul...@redhat.com> wrote: > > > Hi, > > > > > > I'm trying to improve our WPA/WPA2 Enterprise support in KDE and I > > > have few questions regarding 802-11x security setting. > > > > > > 1) When phase2-foo properties should be used instead of just foo > > > properties (e.g phase2-private-key/private-key) ? In > > > implementation of gnome-applet I see they are used when phase2 > > > property is set to true, but it's always set to false as I can > > > see. > > > > phase2-foo properties are used for EAP methods that have 2 phases. > > In the first phase a tunnel is established, and then, in phase 2, > > the authentication is done inside the tunnel using the inner method > > that uses the phase2 properties. > > NM uses that for PEAP, TTLS and FAST EAP methods for which you can > > specify inner methods. > > > > I am not aware of gnome-shell applet implementation. You can look at > > nm-applet/nm-connection-editor code here: > > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-securi > > ty/eap-method.c > > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-secur > > ity/eap-method-peap.c > > I actually meant nm-applet and not gnome-applet. > > I see only phase2_auth property used in PEAP, FAST PEAP and TTLS, but > in TLS there are other phase2-foo properties used only when > parent->phase2 is true. I just don't understand why this property is > always set to false in > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/wireless-security.c[1] > by passing false as third parameter to eap_method_tls_new (line 428). > > Is there any place where this property gets changed? > As I said, phase 2 is only used for some of the methods, that have an inner authentication. Those are PEAP, TTLS and FAST. TLS if used by itself does not have phase 2, so the phase2 properties are not used. I think that the phase2 parameter in the eap_method_tls_new() is there just for the case EAP-TLS is used as an inner authentication method. However, nm-connection-editor does not support this configuration. And I am not sure if it is a common setup. http://www.opus1.com/www/whitepapers/8021xinnerauthmethods.pdf Jirka > > > 2) Are subjectMatch/altSubjectMatch properties still valid and > > > used? I don't see this implemented in gnome-applet, but we had > > > this implemented in the old KDE networkmanagement applet. I'm > > > asking because we got a bug report about missing implementation > > > of these properties for the new applet and I would like to be > > > sure how this should be implemented. > > > > https://developer.gnome.org/NetworkManager/1.0/ref-settings.html > > > > Yes, the properties are valid and used for matching the > > certificates. They are passed to wpa_supplicant that performs the > > certificates matching. > > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/supplican > > t-manager/nm-supplicant-config.c#n971 > > > > It seems that nm-connection-editor/nn-applet did not handle the > > properties. But they can be set via nmcli. > > > > Jirka > > > > Regards, > Jan > > > > [1] > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/wireless-security.c ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA/WPA2 Enterprise details
On Mon, 2015-09-14 at 15:02 +0200, Jirka Klimes wrote: > On Mon, 14 Sep 2015 13:23:14 +0200 > Jan Grulich <jgrul...@redhat.com> wrote: > > > On Monday 14 of September 2015 12:51:01 Jirka Klimes wrote: > > > On Mon, 14 Sep 2015 10:36:59 +0200 > > > > > > Jan Grulich <jgrul...@redhat.com> wrote: > > > > Hi, > > > > > > > > I'm trying to improve our WPA/WPA2 Enterprise support in KDE and I > > > > have few questions regarding 802-11x security setting. > > > > > > > > 1) When phase2-foo properties should be used instead of just foo > > > > properties (e.g phase2-private-key/private-key) ? In > > > > implementation of gnome-applet I see they are used when phase2 > > > > property is set to true, but it's always set to false as I can > > > > see. > > > > > > phase2-foo properties are used for EAP methods that have 2 phases. > > > In the first phase a tunnel is established, and then, in phase 2, > > > the authentication is done inside the tunnel using the inner method > > > that uses the phase2 properties. > > > NM uses that for PEAP, TTLS and FAST EAP methods for which you can > > > specify inner methods. > > > > > > I am not aware of gnome-shell applet implementation. You can look at > > > nm-applet/nm-connection-editor code here: > > > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-securi > > > ty/eap-method.c > > > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-secur > > > ity/eap-method-peap.c > > > > I actually meant nm-applet and not gnome-applet. > > > > I see only phase2_auth property used in PEAP, FAST PEAP and TTLS, but > > in TLS there are other phase2-foo properties used only when > > parent->phase2 is true. I just don't understand why this property is > > always set to false in > > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/wireless-security.c[1] > > by passing false as third parameter to eap_method_tls_new (line 428). > > > > Is there any place where this property gets changed? > > > As I said, phase 2 is only used for some of the methods, that have > an inner authentication. Those are PEAP, TTLS and FAST. > TLS if used by itself does not have phase 2, so the phase2 properties > are not used. > I think that the phase2 parameter in the eap_method_tls_new() is there > just for the case EAP-TLS is used as an inner authentication method. > However, nm-connection-editor does not support this configuration. And > I am not sure if it is a common setup. Yeah, I don't think we had an actual case of TTLS+TLS before. There is a valid reason for doing this (in plain one-phase EAP-TLS the identity is transmitted in the clear, using TTLS+TLS fixes that) but most locations seem to use PEAP or TTLS+(something else) since certificates are fairly difficult to administer at scale. Could be added though. Dan > http://www.opus1.com/www/whitepapers/8021xinnerauthmethods.pdf > > Jirka > > > > > 2) Are subjectMatch/altSubjectMatch properties still valid and > > > > used? I don't see this implemented in gnome-applet, but we had > > > > this implemented in the old KDE networkmanagement applet. I'm > > > > asking because we got a bug report about missing implementation > > > > of these properties for the new applet and I would like to be > > > > sure how this should be implemented. > > > > > > https://developer.gnome.org/NetworkManager/1.0/ref-settings.html > > > > > > Yes, the properties are valid and used for matching the > > > certificates. They are passed to wpa_supplicant that performs the > > > certificates matching. > > > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/supplican > > > t-manager/nm-supplicant-config.c#n971 > > > > > > It seems that nm-connection-editor/nn-applet did not handle the > > > properties. But they can be set via nmcli. > > > > > > Jirka > > > > > > > Regards, > > Jan > > > > > > > > [1] > > https://git.gnome.org/browse/network-manager-applet/tree/src/wireless-security/wireless-security.c > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
WPA/WPA2 Enterprise details
Hi, I'm trying to improve our WPA/WPA2 Enterprise support in KDE and I have few questions regarding 802-11x security setting. 1) When phase2-foo properties should be used instead of just foo properties (e.g phase2-private-key/private-key) ? In implementation of gnome-applet I see they are used when phase2 property is set to true, but it's always set to false as I can see. 2) Are subjectMatch/altSubjectMatch properties still valid and used? I don't see this implemented in gnome-applet, but we had this implemented in the old KDE networkmanagement applet. I'm asking because we got a bug report about missing implementation of these properties for the new applet and I would like to be sure how this should be implemented. Bug report: https://bugs.kde.org/show_bug.cgi?id=342728[1] Thanks for your help. Regards, Jan -- Jan Grulich <jgrul...@redhat.com> Software Engineer, Desktop team Red Hat Czech [1] https://bugs.kde.org/show_bug.cgi?id=342728 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager WPA supplicant
On Tue, 2015-06-02 at 21:04 +0200, Pieter Cardoen wrote: Dear I want to use the option scan_ssid=0 for the wpa_supplicant configuration. However when I add this line to the Wifi configuration keyfile of NetworkManager, it is ignored by the NM daemon. How could I configure the scan_ssid option using NetworkManager? NM doesn't offer scan_ssid as a configuration option on a per-connection basis. scan_ssid=0 doesn't offer any security benefits because by the time NM sends scan_ssid=1, NM has either (a) already found the network in the scan list and is already connecting to it, and thus any listener will soon hear your association/authentication anyway, or (b) the network is hiding its SSID, and sending scan_ssid=1 enables quicker connection to the network, and any listener will soon hear your association too. NM will *never* probe-request specific SSIDs during general scans unless you have set the wifi.hidden=true property in the connection details. NM only probe-requests (eg, scan_ssid=1) a network immediately before connecting to it, or when wifi.hidden=true. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager WPA supplicant
Dear I want to use the option scan_ssid=0 for the wpa_supplicant configuration. However when I add this line to the Wifi configuration keyfile of NetworkManager, it is ignored by the NM daemon. How could I configure the scan_ssid option using NetworkManager? Thanks in advance! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Save... button deactivated, can't create WPA WPA2 Enterprise connection
I've had this problem for awhile now (maybe the last year or 2, certainly Fedora 20 and Fedora 19, and probably Fedora 18 as well). When creating a new Wi-Fi connection: Security: WPA WPA2 Enterprise Authentication: TLS User certificate: file in .der format CA certifcate: file in .der format Private key: file in .pem format Private key password: provided The Save... button remains greyed out/deactivated, so there is no way to save the connection. This happens both when selecting a new Wi-Fi network from the Gnome shell, as well as running nm-connection-editor manually. Is there a workaround so I can create the connection? Thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Save... button deactivated, can't create WPA WPA2 Enterprise connection
On Fri, 2014-05-02 at 14:49 -0400, Chuck Anderson wrote: I've had this problem for awhile now (maybe the last year or 2, certainly Fedora 20 and Fedora 19, and probably Fedora 18 as well). When creating a new Wi-Fi connection: Security: WPA WPA2 Enterprise Authentication: TLS User certificate: file in .der format CA certifcate: file in .der format Private key: file in .pem format Private key password: provided Could you run nm-connection-editor from a terminal and see what output it dumps when you type the private key password? Next, could you provide the top few lines of the private key .pem file? They should look something like this: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,5FA2D6D6242C26D0 Feel free to obscure the salt at the end ofthe DEK-Info line, if that line exists for you. Dan The Save... button remains greyed out/deactivated, so there is no way to save the connection. This happens both when selecting a new Wi-Fi network from the Gnome shell, as well as running nm-connection-editor manually. Is there a workaround so I can create the connection? Thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Save... button deactivated, can't create WPA WPA2 Enterprise connection
On Fri, May 02, 2014 at 02:32:01PM -0500, Dan Williams wrote: On Fri, 2014-05-02 at 14:49 -0400, Chuck Anderson wrote: I've had this problem for awhile now (maybe the last year or 2, certainly Fedora 20 and Fedora 19, and probably Fedora 18 as well). When creating a new Wi-Fi connection: Security: WPA WPA2 Enterprise Authentication: TLS User certificate: file in .der format CA certifcate: file in .der format Private key: file in .pem format Private key password: provided Could you run nm-connection-editor from a terminal and see what output it dumps when you type the private key password? $ nm-connection-editor ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): CRITICAL **: crypto_md5_hash: assertion 'password_len 0' failed ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security Next, could you provide the top few lines of the private key .pem file? They should look something like this: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,5FA2D6D6242C26D0 Feel free to obscure the salt at the end ofthe DEK-Info line, if that line exists for you. -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC, Dan The Save... button remains greyed out/deactivated, so there is no way to save the connection. This happens both when selecting a new Wi-Fi network from the Gnome shell, as well as running nm-connection-editor manually. Is there a workaround so I can create the connection? So I now know what the problem was this time around. The passphrase I was using was incorrect. Is there any way to provide user feedback when this happens? Thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Save... button deactivated, can't create WPA WPA2 Enterprise connection
On Fri, 2014-05-02 at 16:37 -0400, Chuck Anderson wrote: On Fri, May 02, 2014 at 02:32:01PM -0500, Dan Williams wrote: On Fri, 2014-05-02 at 14:49 -0400, Chuck Anderson wrote: I've had this problem for awhile now (maybe the last year or 2, certainly Fedora 20 and Fedora 19, and probably Fedora 18 as well). When creating a new Wi-Fi connection: Security: WPA WPA2 Enterprise Authentication: TLS User certificate: file in .der format CA certifcate: file in .der format Private key: file in .pem format Private key password: provided Could you run nm-connection-editor from a terminal and see what output it dumps when you type the private key password? $ nm-connection-editor ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi: 802-11-wireless.ssid: property is missing ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): CRITICAL **: crypto_md5_hash: assertion 'password_len 0' failed ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Error: couldn't verify private key: 1 private-key ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security ** (nm-connection-editor:4150): WARNING **: Invalid setting Wi-Fi Security: Invalid Wi-Fi security Next, could you provide the top few lines of the private key .pem file? They should look something like this: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,5FA2D6D6242C26D0 Feel free to obscure the salt at the end ofthe DEK-Info line, if that line exists for you. -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC, Dan The Save... button remains greyed out/deactivated, so there is no way to save the connection. This happens both when selecting a new Wi-Fi network from the Gnome shell, as well as running nm-connection-editor manually. Is there a workaround so I can create the connection? So I now know what the problem was this time around. The passphrase I was using was incorrect. Is there any way to provide user feedback when this happens? Yeah, we've toyed with outlining fields
Re: nm-applet crashes when connecting to new wpa AP
On Sun, 2013-06-23 at 15:40 +0200, Kevin Brandstatter wrote: Settings schema 'org.gnome.nm-applet.eap' is not installed version 0.9.4.0-5 from debian wheezy (0.9.4.0 for network-manager as well) any thoughts? Ive tried recompiling the schemas, but the file simply doesnt exist. I've also tried reinstalling the network-manager-gnome package that provides the applet further note: im using e17 wm (0.17.3) on debian jessie, but using the network manager from wheezy becuase of some issues with wpa supplicant That schema should be defined in org.gnome.nm-applet.gschema.xml, which gets generated from org.gnome.nm-applet.gschema.xml.in and then installed in the GSettings schema directory, so it should end up here: /usr/share/glib-2.0/schemas/org.gnome.nm-applet.gschema.xml and then glib-compile-schemas /usr/share/glib-2.0/schemas should get called in the post-install scripts for the package to ensure that the schema is recognized. Any idea if that file is in the right place and if the .deb is rebuilding the schemas? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet crashes when connecting to new wpa AP
Ah i shouldve mentioned to the list that i solved this problem. the issue was that since i had to regress network manager to 9.4 because wpa1.1 isnt in the debian repository yet, i had libnm-gtk 9.8 still which meant package incompatibility. reverting libnm-gtk0 and libnm-gtk-common to 9.4 to match network manager and that solved the issue. I guess can only hope that wpa 1.1 will get to testing soon so i can finally update network manager to 9.8 -Kevin On 06/26/2013 04:32 PM, Dan Williams wrote: On Sun, 2013-06-23 at 15:40 +0200, Kevin Brandstatter wrote: Settings schema 'org.gnome.nm-applet.eap' is not installed version 0.9.4.0-5 from debian wheezy (0.9.4.0 for network-manager as well) any thoughts? Ive tried recompiling the schemas, but the file simply doesnt exist. I've also tried reinstalling the network-manager-gnome package that provides the applet further note: im using e17 wm (0.17.3) on debian jessie, but using the network manager from wheezy becuase of some issues with wpa supplicant That schema should be defined in org.gnome.nm-applet.gschema.xml, which gets generated from org.gnome.nm-applet.gschema.xml.in and then installed in the GSettings schema directory, so it should end up here: /usr/share/glib-2.0/schemas/org.gnome.nm-applet.gschema.xml and then glib-compile-schemas /usr/share/glib-2.0/schemas should get called in the post-install scripts for the package to ensure that the schema is recognized. Any idea if that file is in the right place and if the .deb is rebuilding the schemas? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
nm-applet crashes when connecting to new wpa AP
Settings schema 'org.gnome.nm-applet.eap' is not installed version 0.9.4.0-5 from debian wheezy (0.9.4.0 for network-manager as well) any thoughts? Ive tried recompiling the schemas, but the file simply doesnt exist. I've also tried reinstalling the network-manager-gnome package that provides the applet further note: im using e17 wm (0.17.3) on debian jessie, but using the network manager from wheezy becuase of some issues with wpa supplicant -Kevin ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
How to find out if my WLAN uses WPA or WPA2 security?
Dear NetworkManager folks, following a discussion on the linux-wireless list [1], I want to find out if my WLAN uses WPA(1) or WPA2 security. In his reply Larry Finger suggests to use `iwlist scan` but I do want to avoid installing the package containing this and wonder if NetworkManager exposes the same information. In the connection properties (Verbindungsinformationen) in `nm-applet`, the security line tells me WPA/WPA2. I also was not able to find this in the output of nmcli. $ LANG=C nmcli dev wifi list SSID BSSID MODE FREQ RATE SIGNAL SECURITY ACTIVE […] 'MYWLAN' XX:XX:XX:XX:XX:XX Infrastructure 2457 MHz 54 MB/s46 WPA WPA2 yes […] Does NetworkManager not know about this information because wpa_supplicant is responsible for this? Thanks, Paul [1] http://marc.info/?l=linux-wirelessm=137156919728549w=2 [2] http://en.wikipedia.org/wiki/IEEE_802.11 signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to find out if my WLAN uses WPA or WPA2 security?
On Wed, 2013-06-19 at 09:37 +0200, Paul Menzel wrote: Dear NetworkManager folks, following a discussion on the linux-wireless list [1], I want to find out if my WLAN uses WPA(1) or WPA2 security. In his reply Larry Finger suggests to use `iwlist scan` but I do want to avoid installing the package containing this and wonder if NetworkManager exposes the same information. In the connection properties (Verbindungsinformationen) in `nm-applet`, the security line tells me WPA/WPA2. I also was not able to find this in the output of nmcli. $ LANG=C nmcli dev wifi list SSID BSSID MODE FREQ RATE SIGNAL SECURITY ACTIVE […] 'MYWLAN' XX:XX:XX:XX:XX:XX Infrastructure 2457 MHz 54 MB/s46 WPA WPA2 yes […] Does NetworkManager not know about this information because wpa_supplicant is responsible for this? If nmcli says WPA WPA2 then your AP supports both versions of WPA and can accept clients that are not capable of WPA2. You'll get this same information from 'iwlist scan' or anywhere else. What you're probably wondering is whether your actual connection is using WPA2 *right now*, and the answer is that yes, it is. NetworkManager tells the supplicant to use the best available protocol, so if the AP is capable of WPA2 then that's what the connection is using. Dan (of course, if your card doesn't support WPA2 then it won't be using it, but everything supports WPA2 now, so this is quite unlikely) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/3] Revert wifi: disable Ad-Hoc WPA connections (lp:905748)
From: Nicolas Cavallari caval...@lri.fr
From: Nicolas Cavallari caval...@lri.fr
This reverts commit 69247a00eacd00617acbf1dfcee8497437b8ad39,
which disabled all security in Ad-Hoc networks, due to a bug
of wpa_supplicant that only affected WPA-None.
---
libnm-util/nm-utils.c | 4
src/nm-device-wifi.c | 60 --
src/settings/nm-settings.c | 45 --
3 files changed, 109 deletions(-)
diff --git a/libnm-util/nm-utils.c b/libnm-util/nm-utils.c
index 51ddfeb..40bd67a 100644
--- a/libnm-util/nm-utils.c
+++ b/libnm-util/nm-utils.c
@@ -1323,8 +1323,6 @@ nm_utils_security_valid (NMUtilsSecurityType type,
}
break;
case NMU_SEC_WPA_PSK:
- if (adhoc)
- return FALSE; /* FIXME: Kernel WPA Ad-Hoc support is
buggy */
if (!(wifi_caps NM_WIFI_DEVICE_CAP_WPA))
return FALSE;
if (have_ap) {
@@ -1351,8 +1349,6 @@ nm_utils_security_valid (NMUtilsSecurityType type,
}
break;
case NMU_SEC_WPA2_PSK:
- if (adhoc)
- return FALSE; /* FIXME: Kernel WPA Ad-Hoc support is
buggy */
if (!(wifi_caps NM_WIFI_DEVICE_CAP_RSN))
return FALSE;
if (have_ap) {
diff --git a/src/nm-device-wifi.c b/src/nm-device-wifi.c
index 9101f4d..8a23e1b 100644
--- a/src/nm-device-wifi.c
+++ b/src/nm-device-wifi.c
@@ -999,36 +999,6 @@ deactivate (NMDevice *dev)
}
static gboolean
-is_adhoc_wpa (NMConnection *connection)
-{
- NMSettingWireless *s_wifi;
- NMSettingWirelessSecurity *s_wsec;
- const char *mode, *key_mgmt;
-
- /* The kernel doesn't support Ad-Hoc WPA connections well at this time,
-* and turns them into open networks. It's been this way since at least
-* 2.6.30 or so; until that's fixed, disable WPA-protected Ad-Hoc
networks.
-*/
-
- s_wifi = nm_connection_get_setting_wireless (connection);
- g_return_val_if_fail (s_wifi != NULL, FALSE);
-
- mode = nm_setting_wireless_get_mode (s_wifi);
- if (g_strcmp0 (mode, NM_SETTING_WIRELESS_MODE_ADHOC) != 0)
- return FALSE;
-
- s_wsec = nm_connection_get_setting_wireless_security (connection);
- if (!s_wsec)
- return FALSE;
-
- key_mgmt = nm_setting_wireless_security_get_key_mgmt (s_wsec);
- if (g_strcmp0 (key_mgmt, wpa-none) != 0)
- return FALSE;
-
- return TRUE;
-}
-
-static gboolean
check_connection_compatible (NMDevice *device,
NMConnection *connection,
GError **error)
@@ -1086,14 +1056,6 @@ check_connection_compatible (NMDevice *device,
}
}
- if (is_adhoc_wpa (connection)) {
- g_set_error_literal (error,
-NM_WIFI_ERROR,
-NM_WIFI_ERROR_CONNECTION_INCOMPATIBLE,
-WPA Ad-Hoc disabled due to kernel bugs);
- return FALSE;
- }
-
/* Early exit if supplicant or device don't support AP mode */
if (g_strcmp0 (nm_setting_wireless_get_mode (s_wireless),
NM_SETTING_WIRELESS_MODE_AP) == 0) {
if (!(priv-capabilities NM_WIFI_DEVICE_CAP_AP)) {
@@ -1312,18 +1274,6 @@ complete_connection (NMDevice *device,
return FALSE;
}
- /* The kernel doesn't support Ad-Hoc WPA connections well at this time,
-* and turns them into open networks. It's been this way since at least
-* 2.6.30 or so; until that's fixed, disable WPA-protected Ad-Hoc
networks.
-*/
- if (is_adhoc_wpa (connection)) {
- g_set_error_literal (error,
-NM_SETTING_WIRELESS_ERROR,
-NM_SETTING_WIRELESS_ERROR_INVALID_PROPERTY,
-WPA Ad-Hoc disabled due to kernel bugs);
- return FALSE;
- }
-
g_assert (ssid);
str_ssid = nm_utils_ssid_to_utf8 (ssid);
format = g_strdup_printf (%s %%d, str_ssid);
@@ -3003,16 +2953,6 @@ act_stage1_prepare (NMDevice *dev, NMDeviceStateReason
*reason)
}
g_object_notify (G_OBJECT (self), NM_DEVICE_WIFI_MODE);
- /* The kernel doesn't support Ad-Hoc WPA connections well at this time,
-* and turns them into open networks. It's been this way since at least
-* 2.6.30 or so; until that's fixed, disable WPA-protected Ad-Hoc
networks.
-*/
- if (is_adhoc_wpa (connection)) {
- nm_log_warn (LOGD_WIFI, Ad-Hoc WPA disabled due to kernel
bugs);
- *reason = NM_DEVICE_STATE_REASON_SUPPLICANT_CONFIG_FAILED;
- return NM_ACT_STAGE_RETURN_FAILURE;
- }
-
/* Set
[PATCH 2/3] Replace Ad-Hoc WPA-None support with IBSS RSN-PSK.
From: Nicolas Cavallari caval...@lri.fr
From: Nicolas Cavallari caval...@lri.fr
This completely removes Ad-Hoc WPA-None support, as it is
not supported by the linux kernel since a long time,
have never been standardized and other vendors already
removed support for it since a long time. The security
of the protocol is also comparable to WEP, especially
when used with TKIP.
Instead, the standard-compliant WPA2/RSN protocol
is used for IBSS/Ad-Hoc mode. Compared to WPA-None,
this protocol uses the classical Four Way Handshake
for security association and features replay protection.
IBSS RSN-PSK requires wpa_supplicant 1.0 and a recent enough
kernel (best with = 3.2, 3.0 is still fine)
wpa_supplicant only supports the CCMP cipher when
operating in Ad-Hoc mode; if another cipher is requested,
wpa_supplicant will use CCMP anyway).
IBSS RSN will only be used when mode=adhoc and key_mgmt=wpa-psk
and only if the device claims support for it via nl80211.
---
include/NetworkManager.h | 4 +-
libnm-glib/nm-device-wifi.c| 3 +-
libnm-util/nm-setting-wireless-security.c | 49 +-
libnm-util/nm-setting-wireless.c | 8
libnm-util/nm-utils.c | 29 +
src/nm-wifi-ap-utils.c | 47 -
src/nm-wifi-ap.c | 43 ---
src/settings/plugins/ifcfg-rh/reader.c | 13 +++---
src/settings/plugins/ifcfg-rh/writer.c | 2 +-
src/settings/plugins/ifnet/connection_parser.c | 48 +
src/supplicant-manager/nm-supplicant-config.c | 3 +-
.../nm-supplicant-settings-verify.c| 2 +-
src/wifi/wifi-utils-nl80211.c | 3 ++
13 files changed, 89 insertions(+), 165 deletions(-)
diff --git a/include/NetworkManager.h b/include/NetworkManager.h
index 4c3e656..a6b9b96 100644
--- a/include/NetworkManager.h
+++ b/include/NetworkManager.h
@@ -157,6 +157,7 @@ typedef enum {
* @NM_WIFI_DEVICE_CAP_WPA: device supports WPA1 authentication
* @NM_WIFI_DEVICE_CAP_RSN: device supports WPA2/RSN authentication
* @NM_WIFI_DEVICE_CAP_AP: device supports Access Point mode
+ * @NM_WIFI_DEVICE_CAP_IBSS_RSN: device supports WPA2/RSN in an IBSS network.
*
* 802.11 specific device encryption and authentication capabilities.
**/
@@ -168,7 +169,8 @@ typedef enum {
NM_WIFI_DEVICE_CAP_CIPHER_CCMP = 0x0008,
NM_WIFI_DEVICE_CAP_WPA = 0x0010,
NM_WIFI_DEVICE_CAP_RSN = 0x0020,
- NM_WIFI_DEVICE_CAP_AP= 0x0040
+ NM_WIFI_DEVICE_CAP_AP= 0x0040,
+ NM_WIFI_DEVICE_CAP_IBSS_RSN = 0x0080
} NMDeviceWifiCapabilities;
diff --git a/libnm-glib/nm-device-wifi.c b/libnm-glib/nm-device-wifi.c
index aab659f..dba7ebf 100644
--- a/libnm-glib/nm-device-wifi.c
+++ b/libnm-glib/nm-device-wifi.c
@@ -463,8 +463,7 @@ connection_compatible (NMDevice *device, NMConnection
*connection, GError **erro
if (s_wsec) {
/* Connection has security, verify it against the device's
capabilities */
key_mgmt = nm_setting_wireless_security_get_key_mgmt (s_wsec);
- if ( !g_strcmp0 (key_mgmt, wpa-none)
- || !g_strcmp0 (key_mgmt, wpa-psk)
+ if ( !g_strcmp0 (key_mgmt, wpa-psk)
|| !g_strcmp0 (key_mgmt, wpa-eap)) {
/* Is device only WEP capable? */
diff --git a/libnm-util/nm-setting-wireless-security.c
b/libnm-util/nm-setting-wireless-security.c
index 404a38a..f0fa226 100644
--- a/libnm-util/nm-setting-wireless-security.c
+++ b/libnm-util/nm-setting-wireless-security.c
@@ -789,8 +789,7 @@ need_secrets (NMSetting *setting)
}
/* WPA-PSK infrastructure and adhoc */
- if ( (strcmp (priv-key_mgmt, wpa-none) == 0)
- || (strcmp (priv-key_mgmt, wpa-psk) == 0)) {
+ if (strcmp (priv-key_mgmt, wpa-psk) == 0) {
if (!verify_wpa_psk (priv-psk)) {
g_ptr_array_add (secrets,
NM_SETTING_WIRELESS_SECURITY_PSK);
return secrets;
@@ -838,7 +837,7 @@ verify (NMSetting *setting, GSList *all_settings, GError
**error)
{
NMSettingWirelessSecurity *self = NM_SETTING_WIRELESS_SECURITY
(setting);
NMSettingWirelessSecurityPrivate *priv =
NM_SETTING_WIRELESS_SECURITY_GET_PRIVATE (self);
- const char *valid_key_mgmt[] = { none, ieee8021x, wpa-none,
wpa-psk, wpa-eap, NULL };
+ const char *valid_key_mgmt[] = { none, ieee8021x, wpa-psk,
wpa-eap, NULL };
const char *valid_auth_algs[] = { open, shared, leap, NULL };
const char *valid_protos[] = { wpa, rsn, NULL };
const char *valid_pairwise[] = { wep40, wep104, tkip, ccmp,
NULL };
@@ -974,38 +973,12 @@ verify (NMSetting *setting, GSList *all_settings
WPA-PSK password length requirement
The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. First I was a major contributor to 802.11i and wrote the first paper on the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your typical end user having a complaint on client behaviour. Yesterday, I was at a major corporation for a meeting and the quest SSID had a 6 digit all numeric passcode. NM would not let me connect; it seem to insist that a passcode for WPA2-PSK be at least 8 characters long. The meeting participants using Windows had no difficulty with this 6 digit passcode and were able to get on the guest wireless network. On any SSID I set up, I will use a reasonably strong passcode (though I would REALLY like to start using SAE in place of PSK!), but sometimes you have NO control over what others do. I REALLY need an override on the passcode length requirement; I will again be at that location for a meeting Dec 19. I doubt I will find a way to complain to this company's senior management on their IT department's 'bad' policy. This setup is probably only intended to keep rifraf from trying to get to the NEXT level of access control (you then need an 8 hour user account for hotspot login). Oh, I did not mention that they hide this SSID. Sheesh. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. First I was a major contributor to 802.11i and wrote the first paper on the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your typical end user having a complaint on client behaviour. Yesterday, I was at a major corporation for a meeting and the quest SSID had a 6 digit all numeric passcode. NM would not let me connect; it seem to insist that a passcode for WPA2-PSK be at least 8 characters long. The meeting participants using Windows had no difficulty with this 6 digit passcode and were able to get on the guest wireless network. If it's a 6 digit passcode, then it's not a valid WPA passphrase. If you're able to get a scan of that network, I'd be very curious to see what it's output is. It *may* be a WPS network, which is a method to set up a wifi connection somewhat like pairing a Bluetooth device. That allows all numeric PIN codes, and automatically determines the *actual* passphrase from a handshake that uses the PIN. On any SSID I set up, I will use a reasonably strong passcode (though I would REALLY like to start using SAE in place of PSK!), but sometimes you have NO control over what others do. I REALLY need an override on the passcode length requirement; I will again be at that location for a meeting Dec 19. Excellent, can you run: iw dev wlan0 scan trigger iw dev wlan0 scan dump and grab the output for any AP of that network. Feel free to out the MAC address and the SSID, since they aren't the interesting part. What we want to know is a block like this: WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 3a05b2ad-a879-917c-cc3f-5717fb38815f * Manufacturer: NETGEAR, Inc. * Model: WNDR3400v2 * Model Number: WNDR3400v2 * Serial Number: 01 * Primary Device Type: 6-0050f204-1 * Device name: WNDR3400v2 * Config methods: Label * RF Bands: 0x3 Dan I doubt I will find a way to complain to this company's senior management on their IT department's 'bad' policy. This setup is probably only intended to keep rifraf from trying to get to the NEXT level of access control (you then need an 8 hour user account for hotspot login). Oh, I did not mention that they hide this SSID. Sheesh. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On 12/11/2012 10:02 AM, Dan Williams wrote: On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. First I was a major contributor to 802.11i and wrote the first paper on the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your typical end user having a complaint on client behaviour. Yesterday, I was at a major corporation for a meeting and the quest SSID had a 6 digit all numeric passcode. NM would not let me connect; it seem to insist that a passcode for WPA2-PSK be at least 8 characters long. The meeting participants using Windows had no difficulty with this 6 digit passcode and were able to get on the guest wireless network. If it's a 6 digit passcode, then it's not a valid WPA passphrase. Um, I helped write that section of 802.11i. Of course now it is just part of 802.11-2012: M.4 Suggested pass-phrase-to-PSK mapping The pass-phrase mapping defined in this subclause uses the PBKDF2 method from PKCS #5 v2.0 [B53]. PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256) Here, the following assumptions apply: — A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes from the desire to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal characters. — Each character in the pass-phrase must have an encoding in the range of 32 to 126 (decimal), inclusive. So, yes, we wrote the standard for 8-63 characters. But there are product out there that allow for smaller. Just bad implementations, but the real world. If you're able to get a scan of that network, I'd be very curious to see what it's output is. It *may* be a WPS network, which is a method to set up a wifi connection somewhat like pairing a Bluetooth device. That allows all numeric PIN codes, and automatically determines the *actual* passphrase from a handshake that uses the PIN. Nope, as there is more involved to use WPS. That does not work well at all in a big office building in the meeting rooms in same. But for the 'fun' of it, I will try it with WPS. On any SSID I set up, I will use a reasonably strong passcode (though I would REALLY like to start using SAE in place of PSK!), but sometimes you have NO control over what others do. I REALLY need an override on the passcode length requirement; I will again be at that location for a meeting Dec 19. Excellent, can you run: iw dev wlan0 scan trigger iw dev wlan0 scan dump and grab the output for any AP of that network. Feel free to out the MAC address and the SSID, since they aren't the interesting part. What we want to know is a block like this: WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 3a05b2ad-a879-917c-cc3f-5717fb38815f * Manufacturer: NETGEAR, Inc. * Model: WNDR3400v2 * Model Number: WNDR3400v2 * Serial Number: 01 * Primary Device Type: 6-0050f204-1 * Device name: WNDR3400v2 * Config methods: Label * RF Bands: 0x3 Will do this. For connectivity at the next meeting, I am working on getting Hotspot working on my new Galaxy phone... Dan I doubt I will find a way to complain to this company's senior management on their IT department's 'bad' policy. This setup is probably only intended to keep rifraf from trying to get to the NEXT level of access control (you then need an 8 hour user account for hotspot login). Oh, I did not mention that they hide this SSID. Sheesh. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On Tue, 2012-12-11 at 13:17 -0500, Robert Moskowitz wrote: On 12/11/2012 10:02 AM, Dan Williams wrote: On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. First I was a major contributor to 802.11i and wrote the first paper on the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your typical end user having a complaint on client behaviour. Yesterday, I was at a major corporation for a meeting and the quest SSID had a 6 digit all numeric passcode. NM would not let me connect; it seem to insist that a passcode for WPA2-PSK be at least 8 characters long. The meeting participants using Windows had no difficulty with this 6 digit passcode and were able to get on the guest wireless network. If it's a 6 digit passcode, then it's not a valid WPA passphrase. Um, I helped write that section of 802.11i. Of course now it is just part of 802.11-2012: M.4 Suggested pass-phrase-to-PSK mapping The pass-phrase mapping defined in this subclause uses the PBKDF2 method from PKCS #5 v2.0 [B53]. PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256) Here, the following assumptions apply: — A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes from the desire to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal characters. — Each character in the pass-phrase must have an encoding in the range of 32 to 126 (decimal), inclusive. So, yes, we wrote the standard for 8-63 characters. But there are product out there that allow for smaller. Just bad implementations, but the real world. And these devices pass WiFi Alliance certification? Dan If you're able to get a scan of that network, I'd be very curious to see what it's output is. It *may* be a WPS network, which is a method to set up a wifi connection somewhat like pairing a Bluetooth device. That allows all numeric PIN codes, and automatically determines the *actual* passphrase from a handshake that uses the PIN. Nope, as there is more involved to use WPS. That does not work well at all in a big office building in the meeting rooms in same. But for the 'fun' of it, I will try it with WPS. On any SSID I set up, I will use a reasonably strong passcode (though I would REALLY like to start using SAE in place of PSK!), but sometimes you have NO control over what others do. I REALLY need an override on the passcode length requirement; I will again be at that location for a meeting Dec 19. Excellent, can you run: iw dev wlan0 scan trigger iw dev wlan0 scan dump and grab the output for any AP of that network. Feel free to out the MAC address and the SSID, since they aren't the interesting part. What we want to know is a block like this: WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 3a05b2ad-a879-917c-cc3f-5717fb38815f * Manufacturer: NETGEAR, Inc. * Model: WNDR3400v2 * Model Number: WNDR3400v2 * Serial Number: 01 * Primary Device Type: 6-0050f204-1 * Device name: WNDR3400v2 * Config methods: Label * RF Bands: 0x3 Will do this. For connectivity at the next meeting, I am working on getting Hotspot working on my new Galaxy phone... Dan I doubt I will find a way to complain to this company's senior management on their IT department's 'bad' policy. This setup is probably only intended to keep rifraf from trying to get to the NEXT level of access control (you then need an 8 hour user account for hotspot login). Oh, I did not mention that they hide this SSID. Sheesh. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On 12/11/2012 01:53 PM, Dan Williams wrote: On Tue, 2012-12-11 at 13:17 -0500, Robert Moskowitz wrote: On 12/11/2012 10:02 AM, Dan Williams wrote: On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote: The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3. First I was a major contributor to 802.11i and wrote the first paper on the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your typical end user having a complaint on client behaviour. Yesterday, I was at a major corporation for a meeting and the quest SSID had a 6 digit all numeric passcode. NM would not let me connect; it seem to insist that a passcode for WPA2-PSK be at least 8 characters long. The meeting participants using Windows had no difficulty with this 6 digit passcode and were able to get on the guest wireless network. If it's a 6 digit passcode, then it's not a valid WPA passphrase. Um, I helped write that section of 802.11i. Of course now it is just part of 802.11-2012: M.4 Suggested pass-phrase-to-PSK mapping The pass-phrase mapping defined in this subclause uses the PBKDF2 method from PKCS #5 v2.0 [B53]. PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256) Here, the following assumptions apply: — A pass-phrase is a sequence of between 8 and 63 ASCII-encoded characters. The limit of 63 comes from the desire to distinguish between a pass-phrase and a PSK displayed as 64 hexadecimal characters. — Each character in the pass-phrase must have an encoding in the range of 32 to 126 (decimal), inclusive. So, yes, we wrote the standard for 8-63 characters. But there are product out there that allow for smaller. Just bad implementations, but the real world. And these devices pass WiFi Alliance certification? Given who this company is, I suspect yes. I was just thinking; I can get the BSSID and that will give us the MAC manufacture which is probably the device manufacture :) But their security certification has always been weak to compliance. ICSAlabs put in a bit back in the days, but we lost out as all we were 'good' at was the security and did not have experience in RF certification. Dan If you're able to get a scan of that network, I'd be very curious to see what it's output is. It *may* be a WPS network, which is a method to set up a wifi connection somewhat like pairing a Bluetooth device. That allows all numeric PIN codes, and automatically determines the *actual* passphrase from a handshake that uses the PIN. Nope, as there is more involved to use WPS. That does not work well at all in a big office building in the meeting rooms in same. But for the 'fun' of it, I will try it with WPS. On any SSID I set up, I will use a reasonably strong passcode (though I would REALLY like to start using SAE in place of PSK!), but sometimes you have NO control over what others do. I REALLY need an override on the passcode length requirement; I will again be at that location for a meeting Dec 19. Excellent, can you run: iw dev wlan0 scan trigger iw dev wlan0 scan dump and grab the output for any AP of that network. Feel free to out the MAC address and the SSID, since they aren't the interesting part. What we want to know is a block like this: WPS: * Version: 1.0 * Wi-Fi Protected Setup State: 2 (Configured) * Response Type: 3 (AP) * UUID: 3a05b2ad-a879-917c-cc3f-5717fb38815f * Manufacturer: NETGEAR, Inc. * Model: WNDR3400v2 * Model Number: WNDR3400v2 * Serial Number: 01 * Primary Device Type: 6-0050f204-1 * Device name: WNDR3400v2 * Config methods: Label * RF Bands: 0x3 Will do this. For connectivity at the next meeting, I am working on getting Hotspot working on my new Galaxy phone... Dan I doubt I will find a way to complain to this company's senior management on their IT department's 'bad' policy. This setup is probably only intended to keep rifraf from trying to get to the NEXT level of access control (you then need an 8 hour user account for hotspot login). Oh, I did not mention that they hide this SSID. Sheesh. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On Tue, 11 Dec 2012 12:53:58 -0600 Dan Williams wrote: And these devices pass WiFi Alliance certification? Since this is against golden devices instead of against a rigorous spec it doesn't actually guarantee that compliance means does what the spec says it should. -- Brian Morrison ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA-PSK password length requirement
On Tue, 2012-12-11 at 14:01 -0500, Robert Moskowitz wrote:
On 12/11/2012 01:53 PM, Dan Williams wrote:
On Tue, 2012-12-11 at 13:17 -0500, Robert Moskowitz wrote:
On 12/11/2012 10:02 AM, Dan Williams wrote:
On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote:
The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3.
First I was a major contributor to 802.11i and wrote the first paper on
the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your
typical end user having a complaint on client behaviour.
Yesterday, I was at a major corporation for a meeting and the quest SSID
had a 6 digit all numeric passcode. NM would not let me connect; it
seem to insist that a passcode for WPA2-PSK be at least 8 characters
long. The meeting participants using Windows had no difficulty with
this 6 digit passcode and were able to get on the guest wireless network.
If it's a 6 digit passcode, then it's not a valid WPA passphrase.
Um, I helped write that section of 802.11i. Of course now it is just
part of 802.11-2012:
M.4 Suggested pass-phrase-to-PSK mapping
The pass-phrase mapping defined in this subclause uses the PBKDF2 method
from PKCS #5 v2.0 [B53].
PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256)
Here, the following assumptions apply:
— A pass-phrase is a sequence of between 8 and 63 ASCII-encoded
characters. The limit of 63 comes
from the desire to distinguish between a pass-phrase and a PSK displayed
as 64 hexadecimal
characters.
— Each character in the pass-phrase must have an encoding in the range
of 32 to 126 (decimal),
inclusive.
So, yes, we wrote the standard for 8-63 characters. But there are
product out there that allow for smaller. Just bad implementations, but
the real world.
And these devices pass WiFi Alliance certification?
Given who this company is, I suspect yes. I was just thinking; I can get
the BSSID and that will give us the MAC manufacture which is probably
the device manufacture :)
But their security certification has always been weak to compliance.
ICSAlabs put in a bit back in the days, but we lost out as all we were
'good' at was the security and did not have experience in RF certification.
Note that wpa_supplicant does not allow passphrases with a shorter
length than 8 characters:
if (len 8 || len 63) {
wpa_printf(MSG_ERROR, Line %d: Invalid passphrase
length %lu (expected: 8..63) '%s'.,
line, (unsigned long) len, value);
return -1;
}
If you plead your case to Jouni (the hostap/wpa_supplicant maintainer
who also helps draft 802.11 standards), and he agrees to allow
shorter-than-8-char passphrases, then I'll entertain lowering the limit
in NetworkManager.
Random aside: another problem we periodically have is the character
encoding for hashing passphrases to the actual PSK. When entering the
initial setup passphrase in a browser, and if the browser allows
non-ASCII characters, it's entirely unknown (a) what encoding the
browser is set to, and (b) how the software on the AP hashes the
passphrase to the PSK. We've had problems with passphrases that contain
umlauts, for example.
When you're next at that location, if there's any chance you get get the
actual hashed passphrase (ie 64 hex chars) from somebody, I'd love to
see see how the shorter-than-8-char passphrase got hashed to a PSK; did
it get padded with zeros or something? Or just hashed straight-up?
Dan
Dan
If you're able to get a scan of that network, I'd be very curious to see
what it's output is.
It *may* be a WPS network, which is a method to set up a wifi connection
somewhat like pairing a Bluetooth device. That allows all numeric PIN
codes, and automatically determines the *actual* passphrase from a
handshake that uses the PIN.
Nope, as there is more involved to use WPS. That does not work well at
all in a big office building in the meeting rooms in same. But for the
'fun' of it, I will try it with WPS.
On any SSID I set up, I will use a reasonably strong passcode (though I
would REALLY like to start using SAE in place of PSK!), but sometimes
you have NO control over what others do. I REALLY need an override on
the passcode length requirement; I will again be at that location for a
meeting Dec 19.
Excellent, can you run:
iw dev wlan0 scan trigger
iw dev wlan0 scan dump
and grab the output for any AP of that network. Feel free to out
the MAC address and the SSID, since they aren't the interesting part.
What we want to know is a block like this:
WPS: * Version: 1.0
* Wi-Fi Protected Setup State: 2 (Configured)
* Response Type: 3 (AP)
* UUID: 3a05b2ad-a879-917c-cc3f-5717fb38815f
* Manufacturer: NETGEAR, Inc.
* Model: WNDR3400v2
* Model Number: WNDR3400v2
* Serial Number: 01
* Primary
Re: WPA-PSK password length requirement
On 12/11/2012 06:27 PM, Dan Williams wrote:
On Tue, 2012-12-11 at 14:01 -0500, Robert Moskowitz wrote:
On 12/11/2012 01:53 PM, Dan Williams wrote:
On Tue, 2012-12-11 at 13:17 -0500, Robert Moskowitz wrote:
On 12/11/2012 10:02 AM, Dan Williams wrote:
On Tue, 2012-12-11 at 06:24 -0500, Robert Moskowitz wrote:
The is on Fedora 17, x86_64 (NM 0.9.6.4-3.fc17?), Gnome 3.
First I was a major contributor to 802.11i and wrote the first paper on
the attack on WPA-PSK (and the myth on hiding SSIDs); I am not your
typical end user having a complaint on client behaviour.
Yesterday, I was at a major corporation for a meeting and the quest SSID
had a 6 digit all numeric passcode. NM would not let me connect; it
seem to insist that a passcode for WPA2-PSK be at least 8 characters
long. The meeting participants using Windows had no difficulty with
this 6 digit passcode and were able to get on the guest wireless network.
If it's a 6 digit passcode, then it's not a valid WPA passphrase.
Um, I helped write that section of 802.11i. Of course now it is just
part of 802.11-2012:
M.4 Suggested pass-phrase-to-PSK mapping
The pass-phrase mapping defined in this subclause uses the PBKDF2 method
from PKCS #5 v2.0 [B53].
PSK = PBKDF2(PassPhrase, ssid, ssidLength, 4096, 256)
Here, the following assumptions apply:
— A pass-phrase is a sequence of between 8 and 63 ASCII-encoded
characters. The limit of 63 comes
from the desire to distinguish between a pass-phrase and a PSK displayed
as 64 hexadecimal
characters.
— Each character in the pass-phrase must have an encoding in the range
of 32 to 126 (decimal),
inclusive.
So, yes, we wrote the standard for 8-63 characters. But there are
product out there that allow for smaller. Just bad implementations, but
the real world.
And these devices pass WiFi Alliance certification?
Given who this company is, I suspect yes. I was just thinking; I can get
the BSSID and that will give us the MAC manufacture which is probably
the device manufacture :)
But their security certification has always been weak to compliance.
ICSAlabs put in a bit back in the days, but we lost out as all we were
'good' at was the security and did not have experience in RF certification.
Note that wpa_supplicant does not allow passphrases with a shorter
length than 8 characters:
if (len 8 || len 63) {
wpa_printf(MSG_ERROR, Line %d: Invalid passphrase
length %lu (expected: 8..63) '%s'.,
line, (unsigned long) len, value);
return -1;
}
If you plead your case to Jouni (the hostap/wpa_supplicant maintainer
who also helps draft 802.11 standards), and he agrees to allow
shorter-than-8-char passphrases, then I'll entertain lowering the limit
in NetworkManager.
I will probably see Jouni at the January meeting in Vancouver.
Random aside: another problem we periodically have is the character
encoding for hashing passphrases to the actual PSK. When entering the
initial setup passphrase in a browser, and if the browser allows
non-ASCII characters, it's entirely unknown (a) what encoding the
browser is set to, and (b) how the software on the AP hashes the
passphrase to the PSK. We've had problems with passphrases that contain
umlauts, for example.
Oh, we have discussed this endlessly at the IETF, going way back. It can
get very messy. Even Unicode will not help you out here; in fact it can
make it worst! And this is causing major chanellenges for ISN.
When you're next at that location, if there's any chance you get get the
actual hashed passphrase (ie 64 hex chars) from somebody, I'd love to
see see how the shorter-than-8-char passphrase got hashed to a PSK; did
it get padded with zeros or something? Or just hashed straight-up?
I am so rusty with running Wireshark over wireless. I was probably
running F10 when I would be doing this sort of thing. I will try and
brush up early next week (I am off the next 2 days to visit my son in NJ).
I recall now that on the white board where they wrote down the wireless
access, they definitely said WPA2-PSK and that 6 digit code. And windoze
people were getting on the wireless network.
If you're able to get a scan of that network, I'd be very curious to see
what it's output is.
It *may* be a WPS network, which is a method to set up a wifi connection
somewhat like pairing a Bluetooth device. That allows all numeric PIN
codes, and automatically determines the *actual* passphrase from a
handshake that uses the PIN.
Nope, as there is more involved to use WPS. That does not work well at
all in a big office building in the meeting rooms in same. But for the
'fun' of it, I will try it with WPS.
On any SSID I set up, I will use a reasonably strong passcode (though I
would REALLY like to start using SAE in place of PSK!), but sometimes
you have NO control over what others do. I REALLY need an override on
the passcode length requirement; I will again be at that location for a
meeting Dec 19.
Excellent
Re: cnetworkmanager: Will --wpa-pass expose my password?
On Mon, Dec 3, 2012 at 3:32 AM, brom...@lavabit.com wrote: Hello! I'd like to try cnetworkmanager. The only thing that stops me is the following options: --wep-hex=KEY use this WEP key of 26 hex digits --wep-pass=KEYuse this WEP passphrase --wpa-psk-hex=KEY use this WPA key of 64 hex digits --wpa-pass=KEYuse this WPA passphrase Will the above put a password in .bash_history? I don't want to store my password in a file (even with strict permissions.) ΙΜΗΟ .bash_history is not such a big problem since you can just do unset HISTFILE before calling the command. /proc/*/cmdline on the other hand is probably more dangerous and less easy to deal with. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
cnetworkmanager: Will --wpa-pass expose my password?
Hello! I'd like to try cnetworkmanager. The only thing that stops me is the following options: --wep-hex=KEY use this WEP key of 26 hex digits --wep-pass=KEYuse this WEP passphrase --wpa-psk-hex=KEY use this WPA key of 64 hex digits --wpa-pass=KEYuse this WPA passphrase Will the above put a password in .bash_history? I don't want to store my password in a file (even with strict permissions.) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 2/3 v3] Replace Ad-Hoc WPA-None support with IBSS RSN-PSK.
From: Nicolas Cavallari caval...@lri.fr
This completely removes Ad-Hoc WPA-None support, as it is
not supported by the linux kernel since a long time,
have never been standardized and other vendors already
removed support for it since a long time. The security
of the protocol is also comparable to WEP, especially
when used with TKIP.
Instead, the standard-compliant WPA2/RSN protocol
is used for IBSS/Ad-Hoc mode. Compared to WPA-None,
this protocol uses the classical Four Way Handshake
for security association and features replay protection.
IBSS RSN-PSK requires wpa_supplicant 1.0 and a recent enough
kernel (best with = 3.2, 3.0 is still fine)
wpa_supplicant only supports the CCMP cipher when
operating in Ad-Hoc mode; if another cipher is requested,
wpa_supplicant will use CCMP anyway).
IBSS RSN will only be used when mode=adhoc and key_mgmt=wpa-psk
and only if the device claims support for it via nl80211.
--
Please drop the previous patch, as it didn't compile with the
default -Werror=unused-variable flag.
please drop v2, as it was identical to v1, sorry for the noise.
---
include/NetworkManager.h |4 +-
libnm-glib/nm-device-wifi.c|3 +-
libnm-util/nm-setting-wireless-security.c | 49 +---
libnm-util/nm-setting-wireless.c | 13 +++---
libnm-util/nm-utils.c | 29
src/nm-wifi-ap-utils.c | 47 +++
src/nm-wifi-ap.c | 43 +++--
src/settings/plugins/ifcfg-rh/reader.c | 13 ++
src/settings/plugins/ifcfg-rh/writer.c |2 +-
src/settings/plugins/ifnet/connection_parser.c | 48 ---
.../plugins/ifnet/tests/wpa_supplicant.conf| 10 ++--
src/supplicant-manager/nm-supplicant-config.c |3 +-
.../nm-supplicant-settings-verify.c|2 +-
src/wifi/wifi-utils-nl80211.c |3 ++
14 files changed, 101 insertions(+), 168 deletions(-)
diff --git a/include/NetworkManager.h b/include/NetworkManager.h
index bb67b8f..b35c097 100644
--- a/include/NetworkManager.h
+++ b/include/NetworkManager.h
@@ -155,6 +155,7 @@ typedef enum {
* @NM_WIFI_DEVICE_CAP_WPA: device supports WPA1 authentication
* @NM_WIFI_DEVICE_CAP_RSN: device supports WPA2/RSN authentication
* @NM_WIFI_DEVICE_CAP_AP: device supports Access Point mode
+ * @NM_WIFI_DEVICE_CAP_IBSS_RSN: device supports WPA2/RSN in an IBSS network.
*
* 802.11 specific device encryption and authentication capabilities.
**/
@@ -166,7 +167,8 @@ typedef enum {
NM_WIFI_DEVICE_CAP_CIPHER_CCMP = 0x0008,
NM_WIFI_DEVICE_CAP_WPA = 0x0010,
NM_WIFI_DEVICE_CAP_RSN = 0x0020,
- NM_WIFI_DEVICE_CAP_AP= 0x0040
+ NM_WIFI_DEVICE_CAP_AP= 0x0040,
+ NM_WIFI_DEVICE_CAP_IBSS_RSN = 0x0080
} NMDeviceWifiCapabilities;
diff --git a/libnm-glib/nm-device-wifi.c b/libnm-glib/nm-device-wifi.c
index 0058fd1..3e0fac2 100644
--- a/libnm-glib/nm-device-wifi.c
+++ b/libnm-glib/nm-device-wifi.c
@@ -463,8 +463,7 @@ connection_compatible (NMDevice *device, NMConnection
*connection, GError **erro
if (s_wsec) {
/* Connection has security, verify it against the device's
capabilities */
key_mgmt = nm_setting_wireless_security_get_key_mgmt (s_wsec);
- if ( !g_strcmp0 (key_mgmt, wpa-none)
- || !g_strcmp0 (key_mgmt, wpa-psk)
+ if ( !g_strcmp0 (key_mgmt, wpa-psk)
|| !g_strcmp0 (key_mgmt, wpa-eap)) {
/* Is device only WEP capable? */
diff --git a/libnm-util/nm-setting-wireless-security.c
b/libnm-util/nm-setting-wireless-security.c
index 336773c..3372394 100644
--- a/libnm-util/nm-setting-wireless-security.c
+++ b/libnm-util/nm-setting-wireless-security.c
@@ -785,8 +785,7 @@ need_secrets (NMSetting *setting)
}
/* WPA-PSK infrastructure and adhoc */
- if ( (strcmp (priv-key_mgmt, wpa-none) == 0)
- || (strcmp (priv-key_mgmt, wpa-psk) == 0)) {
+ if (strcmp (priv-key_mgmt, wpa-psk) == 0) {
if (!verify_wpa_psk (priv-psk)) {
g_ptr_array_add (secrets,
NM_SETTING_WIRELESS_SECURITY_PSK);
return secrets;
@@ -834,7 +833,7 @@ verify (NMSetting *setting, GSList *all_settings, GError
**error)
{
NMSettingWirelessSecurity *self = NM_SETTING_WIRELESS_SECURITY
(setting);
NMSettingWirelessSecurityPrivate *priv =
NM_SETTING_WIRELESS_SECURITY_GET_PRIVATE (self);
- const char *valid_key_mgmt[] = { none, ieee8021x, wpa-none,
wpa-psk, wpa-eap, NULL };
+ const char *valid_key_mgmt[] = { none, ieee8021x, wpa-psk,
wpa-eap, NULL };
const char *valid_auth_algs[] = { open, shared, leap, NULL
[PATCH 1/3] Revert wifi: disable Ad-Hoc WPA connections (lp:905748)
From: Nicolas Cavallari caval...@lri.fr
This reverts commit 69247a00eacd00617acbf1dfcee8497437b8ad39,
which disabled all security in Ad-Hoc networks, due to a bug
of wpa_supplicant that only affected WPA-None.
---
libnm-util/nm-utils.c |4 ---
src/nm-device-wifi.c | 60
src/settings/nm-settings.c | 45 -
3 files changed, 109 deletions(-)
diff --git a/libnm-util/nm-utils.c b/libnm-util/nm-utils.c
index 65bbd25..607c0e6 100644
--- a/libnm-util/nm-utils.c
+++ b/libnm-util/nm-utils.c
@@ -1285,8 +1285,6 @@ nm_utils_security_valid (NMUtilsSecurityType type,
}
break;
case NMU_SEC_WPA_PSK:
- if (adhoc)
- return FALSE; /* FIXME: Kernel WPA Ad-Hoc support is
buggy */
if (!(wifi_caps NM_WIFI_DEVICE_CAP_WPA))
return FALSE;
if (have_ap) {
@@ -1313,8 +1311,6 @@ nm_utils_security_valid (NMUtilsSecurityType type,
}
break;
case NMU_SEC_WPA2_PSK:
- if (adhoc)
- return FALSE; /* FIXME: Kernel WPA Ad-Hoc support is
buggy */
if (!(wifi_caps NM_WIFI_DEVICE_CAP_RSN))
return FALSE;
if (have_ap) {
diff --git a/src/nm-device-wifi.c b/src/nm-device-wifi.c
index e2ff77e..0809ce0 100644
--- a/src/nm-device-wifi.c
+++ b/src/nm-device-wifi.c
@@ -967,36 +967,6 @@ real_deactivate (NMDevice *dev)
}
static gboolean
-is_adhoc_wpa (NMConnection *connection)
-{
- NMSettingWireless *s_wifi;
- NMSettingWirelessSecurity *s_wsec;
- const char *mode, *key_mgmt;
-
- /* The kernel doesn't support Ad-Hoc WPA connections well at this time,
-* and turns them into open networks. It's been this way since at least
-* 2.6.30 or so; until that's fixed, disable WPA-protected Ad-Hoc
networks.
-*/
-
- s_wifi = nm_connection_get_setting_wireless (connection);
- g_return_val_if_fail (s_wifi != NULL, FALSE);
-
- mode = nm_setting_wireless_get_mode (s_wifi);
- if (g_strcmp0 (mode, NM_SETTING_WIRELESS_MODE_ADHOC) != 0)
- return FALSE;
-
- s_wsec = nm_connection_get_setting_wireless_security (connection);
- if (!s_wsec)
- return FALSE;
-
- key_mgmt = nm_setting_wireless_security_get_key_mgmt (s_wsec);
- if (g_strcmp0 (key_mgmt, wpa-none) != 0)
- return FALSE;
-
- return TRUE;
-}
-
-static gboolean
real_check_connection_compatible (NMDevice *device,
NMConnection *connection,
GError **error)
@@ -1054,14 +1024,6 @@ real_check_connection_compatible (NMDevice *device,
}
}
- if (is_adhoc_wpa (connection)) {
- g_set_error_literal (error,
-NM_WIFI_ERROR,
-NM_WIFI_ERROR_CONNECTION_INCOMPATIBLE,
-WPA Ad-Hoc disabled due to kernel bugs);
- return FALSE;
- }
-
// FIXME: check channel/freq/band against bands the hardware supports
// FIXME: check encryption against device capabilities
// FIXME: check bitrate against device capabilities
@@ -1222,18 +1184,6 @@ real_complete_connection (NMDevice *device,
return FALSE;
}
- /* The kernel doesn't support Ad-Hoc WPA connections well at this time,
-* and turns them into open networks. It's been this way since at least
-* 2.6.30 or so; until that's fixed, disable WPA-protected Ad-Hoc
networks.
-*/
- if (is_adhoc_wpa (connection)) {
- g_set_error_literal (error,
-NM_SETTING_WIRELESS_ERROR,
-NM_SETTING_WIRELESS_ERROR_INVALID_PROPERTY,
-WPA Ad-Hoc disabled due to kernel bugs);
- return FALSE;
- }
-
g_assert (ssid);
str_ssid = nm_utils_ssid_to_utf8 (ssid);
format = g_strdup_printf (%s %%d, str_ssid);
@@ -2789,16 +2739,6 @@ real_act_stage1_prepare (NMDevice *dev,
NMDeviceStateReason *reason)
connection = nm_act_request_get_connection (req);
g_return_val_if_fail (connection != NULL, NM_ACT_STAGE_RETURN_FAILURE);
- /* The kernel doesn't support Ad-Hoc WPA connections well at this time,
-* and turns them into open networks. It's been this way since at least
-* 2.6.30 or so; until that's fixed, disable WPA-protected Ad-Hoc
networks.
-*/
- if (is_adhoc_wpa (connection)) {
- nm_log_warn (LOGD_WIFI, Ad-Hoc WPA disabled due to kernel
bugs);
- *reason = NM_DEVICE_STATE_REASON_SUPPLICANT_CONFIG_FAILED;
- return NM_ACT_STAGE_RETURN_FAILURE
[PATCH 2/3] Replace Ad-Hoc WPA-None support with IBSS RSN-PSK.
From: Nicolas Cavallari caval...@lri.fr
This completely removes Ad-Hoc WPA-None support, as it is
not supported by the linux kernel since a long time,
have never been standardized and other vendors already
removed support for it since a long time. The security
of the protocol is also comparable to WEP, especially
when used with TKIP.
Instead, the standard-compliant WPA2/RSN protocol
is used for IBSS/Ad-Hoc mode. Compared to WPA-None,
this protocol uses the classical Four Way Handshake
for security association and features replay protection.
IBSS RSN-PSK requires wpa_supplicant 1.0 and a recent enough
kernel (best with = 3.2, 3.0 is still fine)
wpa_supplicant only supports the CCMP cipher when
operating in Ad-Hoc mode; if another cipher is requested,
wpa_supplicant will use CCMP anyway).
IBSS RSN will only be used when mode=adhoc and key_mgmt=wpa-psk
and only if the device claims support for it via nl80211.
---
I tested most of it, but haven't tested everything,
especially the various settings plugins.
include/NetworkManager.h |4 +-
libnm-glib/nm-device-wifi.c|3 +-
libnm-util/nm-setting-wireless-security.c | 49 +---
libnm-util/nm-setting-wireless.c | 13 +++---
libnm-util/nm-utils.c | 29
src/nm-wifi-ap-utils.c | 47 +++
src/nm-wifi-ap.c | 41 +++-
src/settings/plugins/ifcfg-rh/reader.c | 13 ++
src/settings/plugins/ifcfg-rh/writer.c |2 +-
src/settings/plugins/ifnet/connection_parser.c | 48 ---
.../plugins/ifnet/tests/wpa_supplicant.conf| 10 ++--
src/supplicant-manager/nm-supplicant-config.c |3 +-
.../nm-supplicant-settings-verify.c|2 +-
src/wifi/wifi-utils-nl80211.c |3 ++
14 files changed, 101 insertions(+), 166 deletions(-)
diff --git a/include/NetworkManager.h b/include/NetworkManager.h
index bb67b8f..b35c097 100644
--- a/include/NetworkManager.h
+++ b/include/NetworkManager.h
@@ -155,6 +155,7 @@ typedef enum {
* @NM_WIFI_DEVICE_CAP_WPA: device supports WPA1 authentication
* @NM_WIFI_DEVICE_CAP_RSN: device supports WPA2/RSN authentication
* @NM_WIFI_DEVICE_CAP_AP: device supports Access Point mode
+ * @NM_WIFI_DEVICE_CAP_IBSS_RSN: device supports WPA2/RSN in an IBSS network.
*
* 802.11 specific device encryption and authentication capabilities.
**/
@@ -166,7 +167,8 @@ typedef enum {
NM_WIFI_DEVICE_CAP_CIPHER_CCMP = 0x0008,
NM_WIFI_DEVICE_CAP_WPA = 0x0010,
NM_WIFI_DEVICE_CAP_RSN = 0x0020,
- NM_WIFI_DEVICE_CAP_AP= 0x0040
+ NM_WIFI_DEVICE_CAP_AP= 0x0040,
+ NM_WIFI_DEVICE_CAP_IBSS_RSN = 0x0080
} NMDeviceWifiCapabilities;
diff --git a/libnm-glib/nm-device-wifi.c b/libnm-glib/nm-device-wifi.c
index 0058fd1..3e0fac2 100644
--- a/libnm-glib/nm-device-wifi.c
+++ b/libnm-glib/nm-device-wifi.c
@@ -463,8 +463,7 @@ connection_compatible (NMDevice *device, NMConnection
*connection, GError **erro
if (s_wsec) {
/* Connection has security, verify it against the device's
capabilities */
key_mgmt = nm_setting_wireless_security_get_key_mgmt (s_wsec);
- if ( !g_strcmp0 (key_mgmt, wpa-none)
- || !g_strcmp0 (key_mgmt, wpa-psk)
+ if ( !g_strcmp0 (key_mgmt, wpa-psk)
|| !g_strcmp0 (key_mgmt, wpa-eap)) {
/* Is device only WEP capable? */
diff --git a/libnm-util/nm-setting-wireless-security.c
b/libnm-util/nm-setting-wireless-security.c
index 336773c..3372394 100644
--- a/libnm-util/nm-setting-wireless-security.c
+++ b/libnm-util/nm-setting-wireless-security.c
@@ -785,8 +785,7 @@ need_secrets (NMSetting *setting)
}
/* WPA-PSK infrastructure and adhoc */
- if ( (strcmp (priv-key_mgmt, wpa-none) == 0)
- || (strcmp (priv-key_mgmt, wpa-psk) == 0)) {
+ if (strcmp (priv-key_mgmt, wpa-psk) == 0) {
if (!verify_wpa_psk (priv-psk)) {
g_ptr_array_add (secrets,
NM_SETTING_WIRELESS_SECURITY_PSK);
return secrets;
@@ -834,7 +833,7 @@ verify (NMSetting *setting, GSList *all_settings, GError
**error)
{
NMSettingWirelessSecurity *self = NM_SETTING_WIRELESS_SECURITY
(setting);
NMSettingWirelessSecurityPrivate *priv =
NM_SETTING_WIRELESS_SECURITY_GET_PRIVATE (self);
- const char *valid_key_mgmt[] = { none, ieee8021x, wpa-none,
wpa-psk, wpa-eap, NULL };
+ const char *valid_key_mgmt[] = { none, ieee8021x, wpa-psk,
wpa-eap, NULL };
const char *valid_auth_algs[] = { open, shared, leap, NULL };
const char *valid_protos[] = { wpa, rsn, NULL };
const
Re: Wpa Supplicant
On Sunday 19 of February 2012 17:58:09 Almo Nito wrote: Hey Guys, im Trying to get Networkmanager to work together with wpa supplicant. They are both started fine with the dbus option but networkmanager doesn't seem to interact with wpa supplicant (it neither tells that is running in the logs nor sees access points) What exactly do I want to look for to make sure wpa_supplicant and networkmanager see each other and can communicate? regards NM normally starts wpa_supplicant and talks to it via D-Bus. If something goes wrong, you should be able to reaveal in logs. You see NM logs in syslog (etc. /var/log/messages on Fedora) and wpa_supplicant logs in something like /var/log/wpa_supplicant.log To get more detailed logging look at: http://live.gnome.org/action/edit/NetworkManager/Debugging#wifi Also, for increasing NM logs, you could use --log-level=level --log-domains=domain1,domain2,... options. See 'man NetworkManager' and man Networkmanager.conf' Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wpa Supplicant
On Fri, 2012-02-24 at 12:34 +0100, Jirka Klimes wrote: On Sunday 19 of February 2012 17:58:09 Almo Nito wrote: Hey Guys, im Trying to get Networkmanager to work together with wpa supplicant. They are both started fine with the dbus option but networkmanager doesn't seem to interact with wpa supplicant (it neither tells that is running in the logs nor sees access points) What exactly do I want to look for to make sure wpa_supplicant and networkmanager see each other and can communicate? regards NM normally starts wpa_supplicant and talks to it via D-Bus. If something goes wrong, you should be able to reaveal in logs. Also, if you're building your own supplicant you need to make sure the D-Bus interface is enabled in the build config file you're using, so that'll be something like: CONFIG_CTRL_IFACE_DBUS=y CONFIG_CTRL_IFACE_DBUS_NEW=y CONFIG_CTRL_IFACE_DBUS_INTRO=y Dan You see NM logs in syslog (etc. /var/log/messages on Fedora) and wpa_supplicant logs in something like /var/log/wpa_supplicant.log To get more detailed logging look at: http://live.gnome.org/action/edit/NetworkManager/Debugging#wifi Also, for increasing NM logs, you could use --log-level=level --log-domains=domain1,domain2,... options. See 'man NetworkManager' and man Networkmanager.conf' Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Wpa Supplicant
On Mon, Feb 20, 2012 at 1:09 AM, Almo Nito almon...@gmx.de wrote: Im actually getting this error: NetworkManager[1295]: error [1329674643.782386] [nm-supplicant-interface.c:570] interface_add_cb(): (wlan0): error adding interface: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. NetworkManager[1295]: dbus_g_proxy_cancel_call: assertion `pending != NULL' failed Looks the DBus call is failed, could you view your /var/log/wpa_supplicant? Maybe it'll be helpful. What do I look for? rehards ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Wpa Supplicant
Hey Guys, im Trying to get Networkmanager to work together with wpa supplicant. They are both started fine with the dbus option but networkmanager doesn't seem to interact with wpa supplicant (it neither tells that is running in the logs nor sees access points) What exactly do I want to look for to make sure wpa_supplicant and networkmanager see each other and can communicate? regards ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Wpa Supplicant
Im actually getting this error: NetworkManager[1295]: error [1329674643.782386] [nm-supplicant-interface.c:570] interface_add_cb(): (wlan0): error adding interface: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. NetworkManager[1295]: dbus_g_proxy_cancel_call: assertion `pending != NULL' failed What do I look for? rehards ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA + cloned mac doesn't work
On Friday 21 of October 2011 17:01:41 Maxim Levitsky wrote: Hi NM folks! I haven't updated/looked at NM and rest of wifi stack for so long. I stopped using Gnome too in meanwhile. I noticed that recent NM versions allow to setup custom MAC per interface, and it does work even in KDE, however setting custom MAC on WPA2 enabled network connection fails. Reason is same as what I have seen many years ago, when I played a lot with wifi. Reason is that supplicant is not informed of new MAC and thus rejects WPA handshake, or even worse its told old MAC by NM (I suspect later as I tried restarting the supplicant and that didn't help). When I set MAC prior to starting NM, the custom MAC works. I am using wifi stack from kubuntu 11.10, but have no problem compiling all programs (maybe except plasma applet yet) from git. So what you know about that? Is there a bugzilla for this you can share a link with me? Mostly I don't really need that feature, but on basis of 'why not?' I won't mind sharing with the world less private information this way. Exactly, MAC spoofing fails for WPA because wpa_supplicant doesn't update the MAC address. The spoofing feature in NM was implemented according to https://bugzilla.redhat.com/show_bug.cgi?id=447827. For that I also prepared a patch for wpa_supplicant that updates its MAC address and thus makes the spoofing work with WPA. We sent the wpa_supplicant patch to hostap list (and Jouni). Sadly, it didn't get applied. I guess we should bring the patch and the issue to Jouni again. http://lists.shmoo.com/pipermail/hostap/2010-November/022039.html Jirka ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
WPA + cloned mac doesn't work
Hi NM folks! I haven't updated/looked at NM and rest of wifi stack for so long. I stopped using Gnome too in meanwhile. I noticed that recent NM versions allow to setup custom MAC per interface, and it does work even in KDE, however setting custom MAC on WPA2 enabled network connection fails. Reason is same as what I have seen many years ago, when I played a lot with wifi. Reason is that supplicant is not informed of new MAC and thus rejects WPA handshake, or even worse its told old MAC by NM (I suspect later as I tried restarting the supplicant and that didn't help). When I set MAC prior to starting NM, the custom MAC works. I am using wifi stack from kubuntu 11.10, but have no problem compiling all programs (maybe except plasma applet yet) from git. So what you know about that? Is there a bugzilla for this you can share a link with me? Mostly I don't really need that feature, but on basis of 'why not?' I won't mind sharing with the world less private information this way. -- Best regards, Maxim Levitsky Visit my blog: http://maximlevitsky.wordpress.com Warning: Above blog contains rants. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
On 09/12/2011 10:19 PM, Dan Williams wrote: On Mon, 2011-09-12 at 19:18 +0100, iain wrote: Hi again, In case anyone else is wondering about this, I've found a patch from Android for an older version of wpa-supplicant, that with a bit of tweaking for 0.7.3 appears to fix the problem This would appear to indicate a buggy kernel driver. Which driver are you using? A closed source TI one. I wouldn't be surprised if it was buggy. iain ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
Some further information, when wpa-supplicant carries out a scan there are a lot of IWEVGENIE overflow errors. What might this indicate (if anything)? thanks, iain On 09/09/2011 04:42 PM, Lamarque Vieira Souza wrote: Em Friday 09 September 2011, iain escreveu: Hi, I'm running NetworkManager 0.9.1 from git and wpa_supplicant 0.7.3 on a custom distro (based from poky). When I run nmcli dev wifi, the access points appear but everything seems to be screwed up. Hi, have you patched wpa_supplicant-0.7.3 to work with NM-0.9? If not then this is your problem: https://bugzilla.gnome.org/show_bug.cgi?id=644634 . The patch is also there. SSID BSSID MODE FREQ RATE SIGNAL SECURITY ACTIVE 8C03000100 02:FE:F4:50:A9:50 Infrastructure 2 MHz 63 MB/s 75 WPA2 no 8C06000100 00:FE:F4:50:A9:50 Infrastructure 2 MHz 1 MB/s 75 -- no 8C06000100 00:FE:F4:59:01:A0 Infrastructure 2 MHz 0 MB/s 20 -- no 8C03000100 02:FE:F4:50:A9:50 Infrastructure 2 MHz 0 MB/s 72 -- no The driver appears to be working, iwlist gives all the details I expect and comparing the output below with the NM output shows what is wrong. iwlist tiwlan0 scanning tiwlan0 Scan completed : Cell 01 - Address: 12:FE:F4:50:A9:50 ESSID:BTFON Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-56 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 00054254464F4E IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD0900037F0101FF7F Cell 02 - Address: 02:FE:F4:50:A9:50 ESSID:BTOpenzone Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-56 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000A42544F70656E7A6F6E65 IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD0900037F0101FF7F Cell 03 - Address: 00:FE:F4:59:01:A0 ESSID:BTHub3-JJCH Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.437 MHz Signal level=-88 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000B4254487562332D4A4A4348 IE: Unknown: 010882848B960C121824 IE: Unknown: 030106 IE: Unknown: 05040203 IE: Unknown: 2A0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160608000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101870003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340608000 0 IE: Unknown: DD2C0050F204104A0001101044000102105700010010470 010565AA94967C14C0EAA8FF349E6F59311103C000101 Cell 04 - Address: 00:FE:F4:50:A9:50 ESSID:BTHub3-3M94 Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-55 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE
Re: NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
On Mon, 2011-09-12 at 19:18 +0100, iain wrote: Hi again, In case anyone else is wondering about this, I've found a patch from Android for an older version of wpa-supplicant, that with a bit of tweaking for 0.7.3 appears to fix the problem This would appear to indicate a buggy kernel driver. Which driver are you using? Dan http://codesearch.google.com/#dR3YEbitojA/driver_wext.cq=IWEVGENIE% 20overflowtype=csl=1254 /* To make sure correctly parse scan results which is impacted by wext * version, first check range-we_version, if it is default value (0), * update again here */ if (drv-we_version_compiled == 0) wpa_driver_wext_get_range(drv); Not entirely sure why it fixes things but it seems to. iain On 09/09/2011 04:42 PM, Lamarque Vieira Souza wrote: Em Friday 09 September 2011, iain escreveu: Hi, I'm running NetworkManager 0.9.1 from git and wpa_supplicant 0.7.3 on a custom distro (based from poky). When I run nmcli dev wifi, the access points appear but everything seems to be screwed up. Hi, have you patched wpa_supplicant-0.7.3 to work with NM-0.9? If not then this is your problem: https://bugzilla.gnome.org/show_bug.cgi?id=644634 . The patch is also there. SSID BSSID MODE FREQ RATE SIGNAL SECURITY ACTIVE 8C03000100 02:FE:F4:50:A9:50 Infrastructure 2 MHz 63 MB/s 75 WPA2 no 8C06000100 00:FE:F4:50:A9:50 Infrastructure 2 MHz 1 MB/s 75 -- no 8C06000100 00:FE:F4:59:01:A0 Infrastructure 2 MHz 0 MB/s 20 -- no 8C03000100 02:FE:F4:50:A9:50 Infrastructure 2 MHz 0 MB/s 72 -- no The driver appears to be working, iwlist gives all the details I expect and comparing the output below with the NM output shows what is wrong. iwlist tiwlan0 scanning tiwlan0 Scan completed : Cell 01 - Address: 12:FE:F4:50:A9:50 ESSID:BTFON Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-56 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 00054254464F4E IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD0900037F0101FF7F Cell 02 - Address: 02:FE:F4:50:A9:50 ESSID:BTOpenzone Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-56 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000A42544F70656E7A6F6E65 IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD0900037F0101FF7F Cell 03 - Address: 00:FE:F4:59:01:A0 ESSID:BTHub3-JJCH Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.437 MHz Signal level=-88 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000B4254487562332D4A4A4348 IE: Unknown: 010882848B960C121824 IE: Unknown: 030106 IE: Unknown: 05040203 IE: Unknown: 2A0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication
NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
(1) : PSK IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160608000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101870003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340608000 0 IE: Unknown: DD2C0050F204104A0001101044000102105700010010470 010565AA94967C14C0EAA8FF349E6F59311103C000101 Cell 04 - Address: 00:FE:F4:50:A9:50 ESSID:BTHub3-3M94 Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-55 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000B4254487562332D334D3934 IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 05040203 IE: Unknown: 2A0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD2C0050F204104A0001101044000102105700010010470 010565AA94967C14C0EAA8FF349E6F59311103C000101 Does anyone have any ideas on how to debug this further? I've added some debugging to wpa_supplicant to print out the SSIDs that it knows about as they appear in the scans and it appears that its getting them wrong as well, either they just contain garbage or they are empty, but as for what to look further at, I'm somewhat at a loss. iain ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
Hi, I'm running NetworkManager 0.9.1 from git and wpa_supplicant 0.7.3 on a custom distro (based from poky). When I run nmcli dev wifi, the access points appear but everything seems to be screwed up. SSID BSSID MODE FREQ RATE SIGNAL SECURITY ACTIVE 8C0300010002:FE:F4:50:A9:50 Infrastructure 2 MHz63 MB/s75 WPA2 no 8C0600010000:FE:F4:50:A9:50 Infrastructure 2 MHz 1 MB/s 75 -- no 8C0600010000:FE:F4:59:01:A0 Infrastructure 2 MHz 0 MB/s 20 -- no 8C0300010002:FE:F4:50:A9:50 Infrastructure 2 MHz 0 MB/s 72 -- no The driver appears to be working, iwlist gives all the details I expect and comparing the output below with the NM output shows what is wrong. iwlist tiwlan0 scanning tiwlan0 Scan completed : Cell 01 - Address: 12:FE:F4:50:A9:50 ESSID:BTFON Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-56 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 00054254464F4E IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD0900037F0101FF7F Cell 02 - Address: 02:FE:F4:50:A9:50 ESSID:BTOpenzone Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-56 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000A42544F70656E7A6F6E65 IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD0900037F0101FF7F Cell 03 - Address: 00:FE:F4:59:01:A0 ESSID:BTHub3-JJCH Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.437 MHz Signal level=-88 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000B4254487562332D4A4A4348 IE: Unknown: 010882848B960C121824 IE: Unknown: 030106 IE: Unknown: 05040203 IE: Unknown: 2A0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: WPA Version 1
Re: NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
: Unknown: 010882848B960C121824 IE: Unknown: 030106 IE: Unknown: 05040203 IE: Unknown: 2A0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160608000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101870003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340608000 0 IE: Unknown: DD2C0050F204104A0001101044000102105700010010470 010565AA94967C14C0EAA8FF349E6F59311103C000101 Cell 04 - Address: 00:FE:F4:50:A9:50 ESSID:BTHub3-3M94 Protocol:IEEE 802.11 BG Mode:Managed Frequency:2.462 MHz Signal level=-55 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s; 6.5 Mb/s; 13 Mb/s; 19.5 Mb/s 26 Mb/s; 39 Mb/s; 52 Mb/s; 58.5 Mb/s; 65 Mb/s Extra:Bcn int = 100 ms IE: Unknown: 000B4254487562332D334D3934 IE: Unknown: 010882848B960C121824 IE: Unknown: 03010B IE: Unknown: 05040203 IE: Unknown: 2A0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011B0 0 IE: Unknown: 3D160B08000 0 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F2020101890003A427A442435E00623 22F00 IE: Unknown: DD1E00904C33AC011B0 0 IE: Unknown: DD1A00904C340B08000 0 IE: Unknown: DD2C0050F204104A0001101044000102105700010010470 010565AA94967C14C0EAA8FF349E6F59311103C000101 Does anyone have any ideas on how to debug this further? I've added some debugging to wpa_supplicant to print out the SSIDs that it knows about as they appear in the scans and it appears that its getting them wrong as well, either they just contain garbage or they are empty, but as for what to look further at, I'm somewhat at a loss. iain ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Lamarque V. Souza http://www.geographicguide.com/brazil.htm Linux User #57137 - http://counter.li.org/ http://planetkde.org/pt-br ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.9.1 failing to get SSIDs with WPA supplicant 0.7.3
On 09/09/2011 04:42 PM, Lamarque Vieira Souza wrote: Em Friday 09 September 2011, iain escreveu: Hi, I'm running NetworkManager 0.9.1 from git and wpa_supplicant 0.7.3 on a custom distro (based from poky). When I run nmcli dev wifi, the access points appear but everything seems to be screwed up. Hi, have you patched wpa_supplicant-0.7.3 to work with NM-0.9? If not then this is your problem: https://bugzilla.gnome.org/show_bug.cgi?id=644634 . The patch is also there. Yes, that patch has been applied. thanks, iain ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM keeps asking for WPA-PSK password.
On Fri, 2011-05-06 at 20:30 +0200, Antoni Mont wrote: New on that list, sorry if that question was already discussed. Problem arises at setting up a netbook Samsung NF310 (network controller BCM 4313 802.11b/g/n) with Ubuntu 11.04 (Natty). NM detects my access point (and many others of the neighbourhood) but ask time and again for password, without establishing connection. That usually means that either the password you gave is invalid, or that the driver was for some reason unable to connect to the access point. NM treats inability to connect to the AP as wrong password because in many cases we simply don't know if the failure was password-related or not. And the kernel logs say: May 6 14:03:52 sm1 wpa_supplicant[530]: WPA: 4-Way Handshake failed - pre-shared key may be incorrect which indicate that is the case. How many characters long is the PSK, and what characters does it contain? According to the standards, the PSK must be 8 - 63 characters long, and can contain only ASCII characters (ie, no special characters like Ü or whatever). If your passprhase does contain those (some APs are buggy and allow it) then you may need to use a hexadecimal PSK (64 hex characters) that the AP shows in it's management interface. (the problem is that the exact conversion from PSK to hex depends on the language encoding (iso8859-1, iso8859-15, utf8, etc) that your browser has set when you enter the PSK if you're allowed to type in non-ascii characters by the AP's management web page. After the fact we have no idea what encoding was used when the PSK was entered, thus we have no way of knowing how to hash the PSK to hex key if non-ascii characters were actually used) Dan Have tried with Wicd, with similar results: bad passowrd (so, probably, not directly related with NM) Also tried substituting STA driver by b43-fwcutter + firmware: no way. At command line I get: montserrat@sm1:~$ iwconfig wlan0 wlan0 IEEE 802.11bgn ESSID:FTE-5C8A Mode:Managed Frequency:2.412 GHz Access Point: 94:FE:F4:F9:63:18 Bit Rate=1 Mb/s Tx-Power=19 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=70/70 Signal level=-17 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 As for the file /var/log/syslog, I copy some lines that seems to me significant: May 6 14:03:43 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: disconnected - scanning May 6 14:03:44 sm1 wpa_supplicant[530]: Trying to associate with 94:fe:f4:f9:63:18 (SSID='FTE-5C8A' freq=2412 MHz) May 6 14:03:44 sm1 kernel: [ 1579.722485] wlan0: authenticate with 94:fe:f4:f9:63:18 (try 1) May 6 14:03:44 sm1 kernel: [ 1579.724784] wlan0: authenticated May 6 14:03:44 sm1 kernel: [ 1579.724907] wlan0: associate with 94:fe:f4:f9:63:18 (try 1) May 6 14:03:44 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: scanning - associating May 6 14:03:44 sm1 kernel: [ 1579.729567] wlan0: RX AssocResp from 94:fe:f4:f9:63:18 (capab=0x411 status=0 aid=3) May 6 14:03:44 sm1 kernel: [ 1579.729579] wlan0: associated May 6 14:03:44 sm1 kernel: [ 1579.731487] Associated:True May 6 14:03:44 sm1 wpa_supplicant[530]: Associated with 94:fe:f4:f9:63:18 May 6 14:03:44 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: associating - associated May 6 14:03:44 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: associated - 4-way handshake May 6 14:03:52 sm1 kernel: [ 1587.793433] wlan0: deauthenticated from 94:fe:f4:f9:63:18 (Reason: 15) May 6 14:03:52 sm1 kernel: [ 1587.794312] Associated:False May 6 14:03:52 sm1 wpa_supplicant[530]: WPA: 4-Way Handshake failed - pre-shared key may be incorrect May 6 14:03:52 sm1 wpa_supplicant[530]: CTRL-EVENT-DISCONNECTED bssid=94:fe:f4:f9:63:18 reason=0 May 6 14:03:52 sm1 kernel: [ 1587.798570] cfg80211: All devices are disconnected, going to restore regulatory settings May 6 14:03:52 sm1 kernel: [ 1587.798591] cfg80211: Restoring regulatory settings May 6 14:03:52 sm1 kernel: [ 1587.798608] cfg80211: Calling CRDA to update world regulatory domain May 6 14:03:52 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: 4-way handshake - disconnected Thanks in advance for any help Toni ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM keeps asking for WPA-PSK password.
New on that list, sorry if that question was already discussed. Problem arises at setting up a netbook Samsung NF310 (network controller BCM 4313 802.11b/g/n) with Ubuntu 11.04 (Natty). NM detects my access point (and many others of the neighbourhood) but ask time and again for password, without establishing connection. Have tried with Wicd, with similar results: bad passowrd (so, probably, not directly related with NM) Also tried substituting STA driver by b43-fwcutter + firmware: no way. At command line I get: montserrat@sm1:~$ iwconfig wlan0 wlan0 IEEE 802.11bgn ESSID:FTE-5C8A Mode:Managed Frequency:2.412 GHz Access Point: 94:FE:F4:F9:63:18 Bit Rate=1 Mb/s Tx-Power=19 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=70/70 Signal level=-17 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 As for the file /var/log/syslog, I copy some lines that seems to me significant: May 6 14:03:43 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: disconnected - scanning May 6 14:03:44 sm1 wpa_supplicant[530]: Trying to associate with 94:fe:f4:f9:63:18 (SSID='FTE-5C8A' freq=2412 MHz) May 6 14:03:44 sm1 kernel: [ 1579.722485] wlan0: authenticate with 94:fe:f4:f9:63:18 (try 1) May 6 14:03:44 sm1 kernel: [ 1579.724784] wlan0: authenticated May 6 14:03:44 sm1 kernel: [ 1579.724907] wlan0: associate with 94:fe:f4:f9:63:18 (try 1) May 6 14:03:44 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: scanning - associating May 6 14:03:44 sm1 kernel: [ 1579.729567] wlan0: RX AssocResp from 94:fe:f4:f9:63:18 (capab=0x411 status=0 aid=3) May 6 14:03:44 sm1 kernel: [ 1579.729579] wlan0: associated May 6 14:03:44 sm1 kernel: [ 1579.731487] Associated: True May 6 14:03:44 sm1 wpa_supplicant[530]: Associated with 94:fe:f4:f9:63:18 May 6 14:03:44 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: associating - associated May 6 14:03:44 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: associated - 4-way handshake May 6 14:03:52 sm1 kernel: [ 1587.793433] wlan0: deauthenticated from 94:fe:f4:f9:63:18 (Reason: 15) May 6 14:03:52 sm1 kernel: [ 1587.794312] Associated: False May 6 14:03:52 sm1 wpa_supplicant[530]: WPA: 4-Way Handshake failed - pre-shared key may be incorrect May 6 14:03:52 sm1 wpa_supplicant[530]: CTRL-EVENT-DISCONNECTED bssid=94:fe:f4:f9:63:18 reason=0 May 6 14:03:52 sm1 kernel: [ 1587.798570] cfg80211: All devices are disconnected, going to restore regulatory settings May 6 14:03:52 sm1 kernel: [ 1587.798591] cfg80211: Restoring regulatory settings May 6 14:03:52 sm1 kernel: [ 1587.798608] cfg80211: Calling CRDA to update world regulatory domain May 6 14:03:52 sm1 NetworkManager[463]: info (wlan0): supplicant connection state: 4-way handshake - disconnected Thanks in advance for any help Toni ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
WPA Enterprise doesn't like PEM certs
We've received many reports that NetworkManager in Ubuntu 10.04 and Fedora 13 (0.8.1) doesn't like PEM-formatted cert files when configuring new wireless networks for WPA Enterprise, whereas earlier versions work fine. Also, 0.8.1 works for existing wireless network configurations that were created with older NM versions using PEM files. Using .p12 (.pfx) formatted files seems to work. Did something change in this area of either nm-applet or NetworkManger that might explain this? I can provide further troubleshooting details if needed. Thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA_SUPPLICANT (Fedora 13) - NetworkManager can not connect WPA-PSK -TKIP on IBM T30
On Fri, 2010-07-30 at 10:00 -0400, RumseyCW wrote: Mr. Williams et al, NetworkManager on Fedora 13 (IBM T30) installation can not connect to a 3CRWE554G72TU wireless router using WPA-PSK -TKIP. The laptop has the latest updates and all the NetworkManager packages installed including GNOME GUI. When I use NetworkManager it will accept the WPA WPA2 proto and the Key, applies and closes however when the network is selected a dialog requesting a WEP 40/128 Bit key pops up every time. A Connection can not be made. The messages I see are the WAP_SUPPLICANT can not initialize the AP. Also I see hostap driver is not supported although it is reported by man page as a supported driver. I believe that this driver is needed for T30 wireless and WPA-PSK. Can you or someone assist me in installing or making appropriate changes to my T30 installation? I have tried the IRC #fedora route and no one knows much about this problem. Is the T30 too ancient? It has been a faithful consulting tool. It needs to move to a working mobile LINUX platform for both wireless 802.11x and a 3G Modem. (PANTECH UM175 1xEVDO REV A) Do you mean that the wifi card in your machine is an Orinoco or PRISM 2/3 card? If so, then yes, there are problems with wpa_supplicant's interaction with the orinoco driver that's probably driving your card, but that's a problem with the orinoco driver and wpa_supplicant, not NetworkManager itself. Also if you are using the orinoco driver, make sure you have the TKIP-capable firmware. The fact that you're getting a dialog about WEP may mean the card isn't seeing the AP as WPA-capable. If on the other hand you're using the hostap driver (since orinoco and hostap can both drive some of the same hardware) there's likely a different set of driver issues. I'd suggest taking this up on the wpa_supplicant mailing list which you can find at www.w1.fi. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
WPA_SUPPLICANT (Fedora 13) - NetworkManager can not connect WPA-PSK -TKIP on IBM T30
Mr. Williams et al, NetworkManager on Fedora 13 (IBM T30) installation can not connect to a 3CRWE554G72TU wireless router using WPA-PSK -TKIP. The laptop has the latest updates and all the NetworkManager packages installed including GNOME GUI. When I use NetworkManager it will accept the WPA WPA2 proto and the Key, applies and closes however when the network is selected a dialog requesting a WEP 40/128 Bit key pops up every time. A Connection can not be made. The messages I see are the WAP_SUPPLICANT can not initialize the AP. Also I see hostap driver is not supported although it is reported by man page as a supported driver. I believe that this driver is needed for T30 wireless and WPA-PSK. Can you or someone assist me in installing or making appropriate changes to my T30 installation? I have tried the IRC #fedora route and no one knows much about this problem. Is the T30 too ancient? It has been a faithful consulting tool. It needs to move to a working mobile LINUX platform for both wireless 802.11x and a 3G Modem. (PANTECH UM175 1xEVDO REV A) Colin Rumsey 810-327-1553 rumse...@aol.com ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: can't enter wpa password
On Thu, 2010-07-01 at 12:54 -0400, carpetnailz wrote: I'm using my Linux box (OpenSuse 11.2) with a Sprint MiFi box. In the past it has worked fine but yesterday afternoon for some reason is cut me off and I haven't been able to get back on. All the other boxes work (using that other OS from Washington). When I try to log on it will only give me the option to enter a WEP code, not a WPA. With some jiggling--turning radio off and on, disabling wireless and reenabling it, deleting the connection and trying to recreate it, even rebooting, I sometimes will get a dialog box that calls for the WPA password. But then the Apply button is greyed out, so NetworkManager seems to be refusing to do anything with my WPA password even when it offers to let me enter it. That seems to indicate that the driver thinks the device is a WEP AP. When this happens, get the output of: nm-tool iwlist wlan0 scan(assuming your wifi card is wlan0) and we can figure out whether NM is the problem, or whether the drivers are the problem. Dan Help! I need to be able to work. Thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: can't enter wpa password
On Sat, Jul 3, 2010 at 12:42 AM, Eric Beversluis ebe...@researchintegration.org wrote: On Fri, 2010-07-02 at 14:42 +0800, Bin Li wrote: On Fri, Jul 2, 2010 at 12:54 AM, carpetnailz carpetna...@researchintegration.org wrote: I'm using my Linux box (OpenSuse 11.2) with a Sprint MiFi box. In the past it has worked fine but yesterday afternoon for some reason is cut me off and I haven't been able to get back on. All the other boxes work (using that other OS from Washington). When I try to log on it will only give me the option to enter a WEP code, not a WPA. With some jiggling--turning radio off and on, disabling wireless and reenabling it, deleting the connection and trying to recreate it, even rebooting, I sometimes will get a dialog box that calls for the WPA password. But then the Apply button is greyed out, so NetworkManager seems to be refusing to do anything with my WPA password even when it offers to let me enter it. So how about delete the connection in 'wireless' tab of 'Network Connections' Dialog, then try to connect the wireless again. Tried that. One of the situations in which I seemed to be offered opportunity to enter WPA passcode but the Apply button was greyed out. Make sure, you've select correct Security mode, 'WPA Personal' or 'WPA Enterprise', then make sure the correct password, I tried 'WPA Personal' in my laptop, when input more than 8 characters, the 'Apply' button was enabled. networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: can't enter wpa password
On Fri, Jul 2, 2010 at 12:54 AM, carpetnailz carpetna...@researchintegration.org wrote: I'm using my Linux box (OpenSuse 11.2) with a Sprint MiFi box. In the past it has worked fine but yesterday afternoon for some reason is cut me off and I haven't been able to get back on. All the other boxes work (using that other OS from Washington). When I try to log on it will only give me the option to enter a WEP code, not a WPA. With some jiggling--turning radio off and on, disabling wireless and reenabling it, deleting the connection and trying to recreate it, even rebooting, I sometimes will get a dialog box that calls for the WPA password. But then the Apply button is greyed out, so NetworkManager seems to be refusing to do anything with my WPA password even when it offers to let me enter it. So how about delete the connection in 'wireless' tab of 'Network Connections' Dialog, then try to connect the wireless again. Help! I need to be able to work. Thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
can't enter wpa password
I'm using my Linux box (OpenSuse 11.2) with a Sprint MiFi box. In the past it has worked fine but yesterday afternoon for some reason is cut me off and I haven't been able to get back on. All the other boxes work (using that other OS from Washington). When I try to log on it will only give me the option to enter a WEP code, not a WPA. With some jiggling--turning radio off and on, disabling wireless and reenabling it, deleting the connection and trying to recreate it, even rebooting, I sometimes will get a dialog box that calls for the WPA password. But then the Apply button is greyed out, so NetworkManager seems to be refusing to do anything with my WPA password even when it offers to let me enter it. Help! I need to be able to work. Thanks.___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkMananger failing to connect to WPA/WPA2 networks with rnd_wlan
Hi folks, I have a very old iMac G3 which I have equipped with a Linksys WUSB54GS v2.1 USB wireless adapter. This iMac runs 2.6.32 with rndis_wlan module for the USB wireless adapter. Working with just wpa_supplicant and wpa_supplicant.conf, I can always get a successful connection to my wireless router (again, a DD-WRT equipped Linksys WRT54GS v5.2 router). When I use NetworkManager and specify WPA/WPA2 and supply the passphrase, I simply cannot get a successful connection at all. Here's the versions I'm using on the iMac G3: NetworkManager 0.8 nm-applet 0.8 wpa_supplicant 0.6.9 As far as I can determine using only CCMP results in failed connections to the wireless net, but using both TKIP CCMP (same order) results in successful connections via wpa_supplicant. Any ideas that I can try? -- http://www.munted.org.uk One very high maintenance cat living here. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
realtek 8172 does not work with networkmanager and wpa on ubuntu 9.10
Dear list,
I have recently bought a thinkpad edge 64 bits with a realtek 8192.
lspci reports
Network controller: Realtek Semiconductor Co., Ltd. Device 8172 (rev 10)
I have installed ubuntu 9.10 amd64 but Linux does not come with the
driver for this card. The driver is available from
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=21PFid=48Level=5Conn=4ProdID=226DownTypeID=3GetDown=falseDownloads=true#2281
The driver compiles without problem but I can not connect to my access
point when network manager is running. If I disable it, I can manually
connect to the access point using the following wpa.conf
network={
ssid=doubidou-net
proto=WPA WPA2
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP
psk= my_secret
priority=2
}
The following command is used to run wpa_supplicant
wpa_supplicant -D wext -c wpa.conf -i $interface
I have followed the instructions in http://darrenalbers.com/networkmanager/
sudo ./nm-supplicant-test wlan0 path_to/wpa.conf nm-supplicant-test.txt
The output is attached to this mail. The command ends with the error
ioctl[SIOCSIWMLME]: Link has been severed
Could you tell me if I can use this card with network manager?
thanks,
Key: ssid, Value: doubidou-net
Key: proto, Value: WPA WPA2
Key: key_mgmt, Value: WPA-PSK
Key: pairwise, Value: CCMP TKIP
Key: group, Value: CCMP TKIP
Key: psk, Value: my_secret
Key: priority, Value: 2
SUP: sending command 'INTERFACE_ADD wlan0 wext
/var/run/wpa_supplicant '
SUP: response was 'OK'
SUP: sending command 'AP_SCAN 2'
SUP: response was 'OK'
SUP: sending command 'ADD_NETWORK'
SUP: response was '0'
SUP: sending command 'SET_NETWORK 0 ssid doubidou-net'
SUP: response was 'OK'
SUP: sending command 'SET_NETWORK 0 proto WPA WPA2'
SUP: response was 'OK'
SUP: sending command 'SET_NETWORK 0 key_mgmt WPA-PSK'
SUP: response was 'OK'
SUP: sending command 'SET_NETWORK 0 pairwise CCMP TKIP'
SUP: response was 'OK'
SUP: sending command 'SET_NETWORK 0 group CCMP TKIP'
SUP: response was 'OK'
SUP: sending command 'SET_NETWORK 0 psk my_secret'
SUP: response was 'OK'
SUP: sending command 'SET_NETWORK 0 priority 2'
SUP: response was 'OK'
SUP: sending command 'ENABLE_NETWORK 0'
SUP: response was 'OK'
wpa_supplicant(6330): Global control interface '/var/run/wpa_supplicant-global'
wpa_supplicant(6330): RX global ctrl_iface - hexdump_ascii(len=50):
wpa_supplicant(6330): 49 4e 54 45 52 46 41 43 45 5f 41 44 44 20 77 6c
INTERFACE_ADD wl
wpa_supplicant(6330): 61 6e 30 09 09 77 65 78 74 09 2f 76 61 72 2f 72
an0__wext_/var/r
wpa_supplicant(6330): 75 6e 2f 77 70 61 5f 73 75 70 70 6c 69 63 61 6e
un/wpa_supplican
wpa_supplicant(6330): 74 09 t_
wpa_supplicant(6330): CTRL_IFACE GLOBAL INTERFACE_ADD 'wlan0wext
/var/run/wpa_supplicant '
wpa_supplicant(6330): Initializing interface 'wlan0' conf 'N/A' driver 'wext'
ctrl_interface '/var/run/wpa_supplicant' bridge 'N/A'
wpa_supplicant(6330): Interface wlan0 set UP - waiting a second for the driver
to complete initialization
wpa_supplicant(6330): SIOCGIWRANGE: WE(compiled)=22 WE(source)=18 enc_capa=0xf
wpa_supplicant(6330): capabilities: key_mgmt 0xf enc 0xf flags 0x0
wpa_supplicant(6330): WEXT: Operstate: linkmode=1, operstate=5
wpa_supplicant(6330): Own MAC address: 70:1a:04:8e:23:86
wpa_supplicant(6330): wpa_driver_wext_set_wpa
wpa_supplicant(6330): wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0
seq_len=0 key_len=0
wpa_supplicant(6330): wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0
seq_len=0 key_len=0
wpa_supplicant(6330): y: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_supplicant(6330): wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0
seq_len=0 key_len=0
wpa_supplicant(6330): wpa_driver_wext_set_countermeasures
wpa_supplicant(6330): wpa_driver_wext_set_drop_unencrypted
wpa_supplicant(6330): RSN: flushing PMKID list in the driver
wpa_supplicant(6330): Setting scan request: 0 sec 10 usec
wpa_supplicant(6330): WPS: UUID based on MAC address - hexdump(len=16): 5e ab
3f 6b b7 44 5a cf 9f da cc 81 eb 14 52 31
wpa_supplicant(6330): WPS: Build Beacon and Probe Response IEs
wpa_supplicant(6330): WPS: * Version
wpa_supplicant(6330): WPS: * Wi-Fi Protected Setup State (0)
wpa_supplicant(6330): WPS: * Version
wpa_supplicant(6330): WPS: * Wi-Fi Protected Setup State (0)
wpa_supplicant(6330): WPS: * Response Type (2)
wpa_supplicant(6330): WPS: * UUID-E
wpa_supplicant(6330): WPS: * Manufacturer
wpa_supplicant(6330): WPS: * Model Name
wpa_supplicant(6330): WPS: * Model Number
wpa_supplicant(6330): WPS: * Serial Number
wpa_supplicant(6330): WPS: * Primary Device Type
wpa_supplicant(6330): WPS: * Device Name
wpa_supplicant(6330): WPS: * Config Methods (0)
wpa_supplicant(6330): WPS: * RF
Re: realtek 8172 does not work with networkmanager and wpa on ubuntu 9.10
On 02/11/2010 04:02 PM, vincent guffens wrote: Dear list, I have recently bought a thinkpad edge 64 bits with a realtek 8192. lspci reports Network controller: Realtek Semiconductor Co., Ltd. Device 8172 (rev 10) I have installed ubuntu 9.10 amd64 but Linux does not come with the driver for this card. The driver is available from http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=21PFid=48Level=5Conn=4ProdID=226DownTypeID=3GetDown=falseDownloads=true#2281 The driver compiles without problem but I can not connect to my access point when network manager is running. If I disable it, I can manually connect to the access point using the following wpa.conf The Realtek vendor drivers can be a major problem. From what I see in your wpa_supplicant log, it never got any scan data, which is why NM also failed. What do you see when you run (as root) iwlist scan You should also post the dmesg output that pertains to this device. Larry ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: realtek 8172 does not work with networkmanager and wpa on ubuntu 9.10
On Fri, 2010-02-12 at 14:47 -0600, Larry Finger wrote: On 02/11/2010 04:02 PM, vincent guffens wrote: Dear list, I have recently bought a thinkpad edge 64 bits with a realtek 8192. lspci reports Network controller: Realtek Semiconductor Co., Ltd. Device 8172 (rev 10) I have installed ubuntu 9.10 amd64 but Linux does not come with the driver for this card. The driver is available from http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=21PFid=48Level=5Conn=4ProdID=226DownTypeID=3GetDown=falseDownloads=true#2281 The driver compiles without problem but I can not connect to my access point when network manager is running. If I disable it, I can manually connect to the access point using the following wpa.conf The Realtek vendor drivers can be a major problem. From what I see in your wpa_supplicant log, it never got any scan data, which is why NM also failed. Also the supplicant test used AP_SCAN=2 though, which could affect this. The nm-supplicant-test is pretty old and probably shouldn't really be used anymore. But Vincent, can you get some supplicant debug logs when running NM, as described here? http://live.gnome.org/NetworkManager/Debugging under the Debugging WiFi Connections section. Specifically, we're looking for /var/log/wpa_supplicant.log when you see failures using NetworkManager. Note though that this driver is not part of the upstream kernel, and its quality is highly suspect. Just because it works manually with wpa_supplicant doesn't always mean the driver is OK. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
What type of wifi card? It may be that driver issues prevent the wifi card from completing the WPA Ad-Hoc network. WPA Ad-Hoc is more complex than WEP ad-hoc and there have been kernel driver issues with that configuration in the past. What kernel version are you using, what wifi hardware, and what wifi driver? Ubuntu Karmic, 2.6.31, Netgear WG511T, ath5k. g ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
On Sun, 2010-01-17 at 18:58 +0200, Quintin Beukes wrote: The type of encryption shouldn't make a difference to sharing ability. It's 2 completely differently networking layers. Actually it does; you can't connect to a WPA2-only Ad-Hoc network with the current wpa_supplicant and Linux kernel drivers. So that means NM can't use those networks. But they are quite rare. Dan Though, how are you sharing it? Are you building custom firewall rules, or using some automated sharing via a configuration option? Quintin Beukes On Sun, Jan 17, 2010 at 6:37 PM, Gonsolo gons...@gmail.com wrote: Hi! I wanted to inform you that I was able to share my connection with WEP64 but not WPA/WPA2. I am connecting my Ipod Touch 2nd generation to my notebook (ath5k based WLAN card, Ubuntu Karmic) which is connected to the internet via UMTS (Huawei E220, option kernel module). It works with WEP64 encryption but not with WPA/WPA2 encryption. Is that problem known? I would be happy to provide more information (lsmod, log messages, etc). Should I file a bug? If so, where (Launchpad, Gnome, Fedora)? g ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
On Sun, 2010-01-17 at 18:04 +0100, Gonsolo wrote: I wanted to inform you that I was able to share my connection with WEP64 but not WPA/WPA2. I am connecting my Ipod Touch 2nd generation to my notebook (ath5k based WLAN card, Ubuntu Karmic) which is connected to the internet via UMTS (Huawei E220, option kernel module). It works with WEP64 encryption but not with WPA/WPA2 encryption. Is that problem known? I would be happy to provide more information (lsmod, log messages, etc). Should I file a bug? If so, where (Launchpad, Gnome, Fedora)? Am 17.01.2010 17:58, schrieb Quintin Beukes: The type of encryption shouldn't make a difference to sharing ability. It's 2 completely differently networking layers. Though, how are you sharing it? Are you building custom firewall rules, or using some automated sharing via a configuration option? No, very simple: Plug in UMTS Stick and WLAN Pcmcia card, connect mobile broadband via NetworkManager and then create a new WLAN network also via NetworkManager like it is explained in http://magazine.redhat.com/2008/10/16/video-fedora-10-connection-sharing/ . It automatically adds DNS forwarding via dnsmasq (,I guess). And, how I said, it works with WEP64 but not with with WPA. What type of wifi card? It may be that driver issues prevent the wifi card from completing the WPA Ad-Hoc network. WPA Ad-Hoc is more complex than WEP ad-hoc and there have been kernel driver issues with that configuration in the past. What kernel version are you using, what wifi hardware, and what wifi driver? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
It should not have to be ad-hoc. The wifi card is acting in ap(Access Point) mode. How does this work? Q ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
Gonsolo a écrit : I think my WG511 card would allow WPA Note that it is not because a card works as a WPA station that it works as an WPA Access Point. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
2010/1/18 Marc Herbert marc.herb...@gmail.com: Gonsolo a écrit : I think my WG511 card would allow WPA Note that it is not because a card works as a WPA station that it works as an WPA Access Point. I agree. I remember that when I was testing a rt61-based card, I had problems when tried to use WPA with ad-hoc mode. I had to switch to the ndiswrapper driver to do that. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
On Mon, Jan 18, 2010 at 6:02 AM, Quintin Beukes quin...@last.za.net wrote: It should not have to be ad-hoc. The wifi card is acting in ap(Access Point) mode. How does this work? Internally or how to configure? To configure: 1. Create a new wireless connection with the add button 2. enter ssid 3. Keep mode as Infrastructure instead of Ad-hoc 4. In ipv4 settings tab select method: Shared to other computers. -- John ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Connection sharing with WPA/WPA2
Hi! I wanted to inform you that I was able to share my connection with WEP64 but not WPA/WPA2. I am connecting my Ipod Touch 2nd generation to my notebook (ath5k based WLAN card, Ubuntu Karmic) which is connected to the internet via UMTS (Huawei E220, option kernel module). It works with WEP64 encryption but not with WPA/WPA2 encryption. Is that problem known? I would be happy to provide more information (lsmod, log messages, etc). Should I file a bug? If so, where (Launchpad, Gnome, Fedora)? g ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
The type of encryption shouldn't make a difference to sharing ability. It's 2 completely differently networking layers. Though, how are you sharing it? Are you building custom firewall rules, or using some automated sharing via a configuration option? Quintin Beukes On Sun, Jan 17, 2010 at 6:37 PM, Gonsolo gons...@gmail.com wrote: Hi! I wanted to inform you that I was able to share my connection with WEP64 but not WPA/WPA2. I am connecting my Ipod Touch 2nd generation to my notebook (ath5k based WLAN card, Ubuntu Karmic) which is connected to the internet via UMTS (Huawei E220, option kernel module). It works with WEP64 encryption but not with WPA/WPA2 encryption. Is that problem known? I would be happy to provide more information (lsmod, log messages, etc). Should I file a bug? If so, where (Launchpad, Gnome, Fedora)? g ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
I wanted to inform you that I was able to share my connection with WEP64 but not WPA/WPA2. I am connecting my Ipod Touch 2nd generation to my notebook (ath5k based WLAN card, Ubuntu Karmic) which is connected to the internet via UMTS (Huawei E220, option kernel module). It works with WEP64 encryption but not with WPA/WPA2 encryption. Is that problem known? I would be happy to provide more information (lsmod, log messages, etc). Should I file a bug? If so, where (Launchpad, Gnome, Fedora)? Am 17.01.2010 17:58, schrieb Quintin Beukes: The type of encryption shouldn't make a difference to sharing ability. It's 2 completely differently networking layers. Though, how are you sharing it? Are you building custom firewall rules, or using some automated sharing via a configuration option? No, very simple: Plug in UMTS Stick and WLAN Pcmcia card, connect mobile broadband via NetworkManager and then create a new WLAN network also via NetworkManager like it is explained in http://magazine.redhat.com/2008/10/16/video-fedora-10-connection-sharing/ . It automatically adds DNS forwarding via dnsmasq (,I guess). And, how I said, it works with WEP64 but not with with WPA. g ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
Am 17.01.2010 18:04, schrieb Marc Luethi: On Sun, 2010-01-17 at 17:37 +0100, Gonsolo wrote: It works with WEP64 encryption but not with WPA/WPA2 encryption. If your notebook sets up an ad hoc WiFi network, you can't use WPA or WPA2. AFAIK, the ad hoc WiFi mode is still limited to WEP encryption. With certain hardware/driver combinations it is possible to run your hardware in Access Point mode - then this restriction does not apply, of course. Ok, thanks. It seems to be ad hoc. I think my WG511 card would allow WPA but I will continue to use WEP for now (since it is the easiest to do :) ). g ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
Are you sure the network is even established? Can you ping the other host? You mentioned ad-hoc. I've noticed NetworkManager has problems establishing AdHoc networks using WPA. For the network doesn't establish in the first place, so sharing won't work. Maybe this is your problem as well? try pinging the other host. Quintin Beukes On Sun, Jan 17, 2010 at 7:07 PM, Gonsolo gons...@gmail.com wrote: Am 17.01.2010 18:04, schrieb Marc Luethi: On Sun, 2010-01-17 at 17:37 +0100, Gonsolo wrote: It works with WEP64 encryption but not with WPA/WPA2 encryption. If your notebook sets up an ad hoc WiFi network, you can't use WPA or WPA2. AFAIK, the ad hoc WiFi mode is still limited to WEP encryption. With certain hardware/driver combinations it is possible to run your hardware in Access Point mode - then this restriction does not apply, of course. Ok, thanks. It seems to be ad hoc. I think my WG511 card would allow WPA but I will continue to use WEP for now (since it is the easiest to do :) ). g ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
On Sun, Jan 17, 2010 at 1:28 PM, Quintin Beukes quin...@last.za.net wrote: Are you sure the network is even established? Can you ping the other host? You mentioned ad-hoc. I've noticed NetworkManager has problems establishing AdHoc networks using WPA. For the network doesn't establish in the first place, so sharing won't work. It should not have to be ad-hoc. The wifi card is acting in ap(Access Point) mode. Maybe this is your problem as well? try pinging the other host. Quintin Beukes On Sun, Jan 17, 2010 at 7:07 PM, Gonsolo gons...@gmail.com wrote: Am 17.01.2010 18:04, schrieb Marc Luethi: On Sun, 2010-01-17 at 17:37 +0100, Gonsolo wrote: It works with WEP64 encryption but not with WPA/WPA2 encryption. If your notebook sets up an ad hoc WiFi network, you can't use WPA or WPA2. AFAIK, the ad hoc WiFi mode is still limited to WEP encryption. With certain hardware/driver combinations it is possible to run your hardware in Access Point mode - then this restriction does not apply, of course. Ok, thanks. It seems to be ad hoc. I think my WG511 card would allow WPA but I will continue to use WEP for now (since it is the easiest to do :) ). g ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection sharing with WPA/WPA2
Am 17.01.2010 22:09, schrieb John Mahoney: On Sun, Jan 17, 2010 at 1:28 PM, Quintin Beukesquin...@last.za.net wrote: Are you sure the network is even established? Can you ping the other host? You mentioned ad-hoc. I've noticed NetworkManager has problems establishing AdHoc networks using WPA. For the network doesn't establish in the first place, so sharing won't work. It should not have to be ad-hoc. The wifi card is acting in ap(Access Point) mode. Yes, but the simplest solution for me is to just use Create New Wireless Network in NetworkManager, use WEP64, and everything works. Looking in NetworkManager it tells me that it is an Adhoc network. I received an answer that WPA(2) mode in Adhoc mode is not in the specification. AP mode may work, I'm just too lazy. :) Thank you all for your answers, g (lying on the couch with his Ipod :) ) ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM deleting WPA key secret in Fedora 12?
On Fri, 04 Dec 2009 12:25:26 -0800 Dan Williams d...@redhat.com wrote: On Thu, 2009-12-03 at 15:03 +, Brian Morrison wrote: Brian Morrison wrote: The fix was to paste my WPA key into the entry field after using the edit menu for my home SSID and then going to the advanced tab (at least I think that's it, don't have it in front of me just now). There is only an SSID stored, no BSSID. I should have added that clicking on the network SSID in the NM applet's left click menu does nothing, it doesn't bring up a dialog asking for the connection's secrets and in fact it does precisely nothing. If this ever happened in F11 then I would be prompted for the WPA PSK which no longer happens. This is odd, but before we do anything else, can you try the NM in updates-testing? I haven't seen this at all but it could point to keyring issues since the WPA passphrase is stored in the keyring. Right. I have now seen a second case of this, the symptoms were sudden loss of network throughput but NM and the Netspeed applet both showed the connection still working. Reselecting my home SSID from the list in NM's left click menu resulted in an attempt to reconnect that never succeeded. On opening the WPA settings via NM's right-click edit menu the passphrase was blank. Re-entering it sorted the problem out. I see there is a new wpa-supplicant in updates-testing, do I need that too? I will restart with the updated NM and see if anything has changed. -- Brian ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM deleting WPA key secret in Fedora 12?
On Thu, 2009-12-03 at 15:03 +, Brian Morrison wrote: Brian Morrison wrote: The fix was to paste my WPA key into the entry field after using the edit menu for my home SSID and then going to the advanced tab (at least I think that's it, don't have it in front of me just now). There is only an SSID stored, no BSSID. I should have added that clicking on the network SSID in the NM applet's left click menu does nothing, it doesn't bring up a dialog asking for the connection's secrets and in fact it does precisely nothing. If this ever happened in F11 then I would be prompted for the WPA PSK which no longer happens. This is odd, but before we do anything else, can you try the NM in updates-testing? I haven't seen this at all but it could point to keyring issues since the WPA passphrase is stored in the keyring. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM deleting WPA key secret in Fedora 12?
Has anyone else suffered from a problem where on occasion F12 will boot and then be unable to connect to a previously usable AP because the WPA key is no longer stored? My home network has two APs with the same SSID but different BSSIDs on each channel. I have now had this happen twice, the first time I thought it was because it was I had just upgraded from F11 to F12 on my laptop, but it did it again this morning. The fix was to paste my WPA key into the entry field after using the edit menu for my home SSID and then going to the advanced tab (at least I think that's it, don't have it in front of me just now). There is only an SSID stored, no BSSID. Is this a common problem? I didn't see anything in the Fedora Common Bugs page. I have all the latest patches applied to F12 as of a day or two ago, I see there are a load more in updates though so will apply those. This is not very deterministic, it's hit me twice in a dozen boots I think. -- Brian ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM deleting WPA key secret in Fedora 12?
Brian Morrison wrote: The fix was to paste my WPA key into the entry field after using the edit menu for my home SSID and then going to the advanced tab (at least I think that's it, don't have it in front of me just now). There is only an SSID stored, no BSSID. I should have added that clicking on the network SSID in the NM applet's left click menu does nothing, it doesn't bring up a dialog asking for the connection's secrets and in fact it does precisely nothing. If this ever happened in F11 then I would be prompted for the WPA PSK which no longer happens. -- Brian ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: WPA troubles in F12
I have not forgotten about this and will gather the needed data. Just happen to be life-busy for the current time. On Tue, Nov 17, 2009 at 5:15 PM, Dan Williams wrote: Can you grab /var/log/messages from a successful run (cert+peap0) and a failed run so I can look at what NM is sending to the supplicant? Please note that my initial successful run is only with NoCert+Peap0. Once I connect in this manner, subsequent Cert+Peap0(or Automatic) connections work just fine (for the duration of the session). ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
