Re: [PATCH 1/9] Ignore rild modem devices.

[Thomas Haller]

On Wed, 2016-06-08 at 16:20 -0400, Tony Espy wrote:
> From: Mathieu Trudel-Lapierre 
> 
> Gbp-Pq: Name Ignore-rild-modem-devices.patch
> ---
>  src/nm-manager.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/src/nm-manager.c b/src/nm-manager.c
> index 10aa3d7..c2ed1da 100644
> --- a/src/nm-manager.c
> +++ b/src/nm-manager.c
> @@ -2089,6 +2089,14 @@ platform_link_added (NMManager *self,
>   gboolean ignore = FALSE;
>   gs_free_error GError *error = NULL;
>  
> + /* Ignore rild modem devices, which will be handled
> by their modem parent */
> + if (g_strstr_len (plink->name, NM_STRLEN ("rmnet"),
> "rmnet") ||
> + g_strstr_len (plink->name, NM_STRLEN
> ("rev_rmnet"), "rev_rmnet") ||
> + g_strstr_len (plink->name, NM_STRLEN
> ("ccmni"), "ccmni")) {
> + _LOGW (LOGD_HW, "Ignoring rild modem device:
> %s", plink->name);
> + return;
> + }
> +
>   device = nm_device_factory_create_device (factory,
> plink->name, plink, NULL, , );
>   if (!device) {
>   if (!ignore) {


  g_strstr_len (plink->name, NM_STRLEN ("rmnet"), "rmnet")
is identical to
  g_str_has_prefix (plink->name, "rmnet")
or
  strncmp (plink->name, "rmnet", NM_STRLEN ("rmnet")) == 0
isn't it?


g_str_has_prefix() seems easier to understand in this case.



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 3/9] wwan: add support for using oFono as a modem manager

[Thomas Haller]

On Wed, 2016-06-08 at 16:20 -0400, Tony Espy wrote:
> From: Mathieu Trudel-Lapierre 
> 
> This patch adds core wwan support for ofono, as used by Ubuntu Touch.
> 
> Signed-off-by: Mathieu Trudel-Lapierre  ical.com>
> 
> Gbp-Pq: Name wwan-add-support-for-using-oFono-as-a-modem-
> manager.patch


Hi,

applying the patch series on master fails for this patch. I tried a bit
around but couldn't immediately find where it applies.

Could you kindly name a parent commit on which the series applies
without requiring manual intervening?


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: NM can't see WEP access point

[Dan Williams]

On Thu, 2016-06-09 at 17:28 +0200, Bastien Nocera wrote:
> On Thu, 2016-06-09 at 10:23 -0500, Dan Williams wrote:
> > 
> > On Thu, 2016-06-09 at 17:13 +0200, Bastien Nocera wrote:
> > > 
> > > On Thu, 2016-06-09 at 10:00 -0500, Dan Williams wrote:
> > > > 
> > > > 
> > > > 
> > > 
> > > > 
> > > > 
> > > > So I missed it before.  But your AP isn't actually set for WEP,
> > > > it's
> > > > set for WPA/TKIP.  If it's actually using just WEP, you won't
> > > > see
> > > > any
> > > > of the RSN/WPA IEs in the beacon.
> > > Still isn't right that it's not showing though, is it?
> > Yeah.  Can you 'nmcli g log', then:
> > 
> > nmcli g log level debug domains  > domains>,WIFI_SCAN
> > 
> > and then turn on airplane mode, turn it off, and wait for a bit
> > until
> > you're sure the AP doesn't get found by NM.  Then send me the logs
> > and
> > I'll take a look to see if I can figure out why NM doesn't find it.
> >  If
> > the supplicant sees it, but NM does not, then there's an NM bug
> > somewhere.
> Well, wpa_supplicant is throwing an error when you try to get the
> RSN,
> so I don't really expect NM to be able to process that access point.

The AP's beacon indicates that it is using TSN (Transition Security
Network), since it's indicating WEP-104 as the group cipher (00 0f ac
05).  It looks like wpa_supplicant tries to handle that in some places,
but ultimately the IE parsing in wpa_parse_wpa_ie_rsn() doesn't allow
that, so the IE won't parse, and the supplicant wouldn't allow
assocaiting to that network either.

So it's a bug in the supplicant for TSN networks.  For other testing,
try disabling RSN/WPA2?  If the AP allows a "WEP-only" mode that's what
I'd use.  You want *nothing* in the beacon that indicates RSN or WPA
capabilities.

Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/9] Ignore rild modem devices.

[Tony Espy]

On 06/08/2016 05:37 PM, Dan Williams wrote:

On Wed, 2016-06-08 at 16:20 -0400, Tony Espy wrote:

From: Mathieu Trudel-Lapierre 

Gbp-Pq: Name Ignore-rild-modem-devices.patch
---
  src/nm-manager.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/src/nm-manager.c b/src/nm-manager.c
index 10aa3d7..c2ed1da 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -2089,6 +2089,14 @@ platform_link_added (NMManager *self,
gboolean ignore = FALSE;
gs_free_error GError *error = NULL;

+   /* Ignore rild modem devices, which will be handled
by their modem parent */
+   if (g_strstr_len (plink->name, NM_STRLEN ("rmnet"),
"rmnet") ||
+   g_strstr_len (plink->name, NM_STRLEN
("rev_rmnet"), "rev_rmnet") ||
+   g_strstr_len (plink->name, NM_STRLEN
("ccmni"), "ccmni")) {
+   _LOGW (LOGD_HW, "Ignoring rild modem device:
%s", plink->name);
+   return;
+   }


I'd actually put this into the WWAN factory, see just below:


device = nm_device_factory_create_device (factory,
plink->name, plink, NULL, , );
if (!device) {
if (!ignore) {


where  is; the factory can indicate to the manager that it wants
certain devices ignored through that variable.  So you'd toss this into
src/devices/wwan/nm-wwan-factory.c::create_device() instead.


The one area of concern I have is whether or not these devices are 
reported as the proper type, otherwise they won't get passed to the wwan 
factory.


If this isn't a problem for us, then this seems like a reasonable 
approach... except for the fact that we've hard-coded these device 
matching expressions.  Over time this won't scale.


Any thoughts about how this could be made runtime configurable?  I'd 
love to get rid of one more source patch.  ;)


/tony

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 2/2] Clear WiFi requested_scan if suppl exits

[Tony Espy]

On 06/08/2016 05:36 PM, Dan Williams wrote:

On Wed, 2016-06-08 at 16:24 -0400, Tony Espy wrote:

It's possible for wpa_supplicant to exit with an
outstanding requested_scan pending.  This can lead
to a stall condition where scanning no longer occurs.


Oh, I see the fixup for cancel_pending_scan() now :)  That should go in
the last patch.


Yea, a bit sloppy... I'll clean that up too.


Other than that, I'd also remove the debug logging, I think we'll have
enough logging elsewhere (including the pending action remove and the
supplicant state change).  But I'm OK to keep it too.


The extra logging was important for actually catching/verifying that the 
condition could happen, so after the fact, I'm actually fine with 
removing it.


/tony






Dan


Gbp-Pq: Name Clear-WiFi-requested_scan-if-suppl-exits.patch
---
  src/devices/wifi/nm-device-wifi.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/devices/wifi/nm-device-wifi.c b/src/devices/wifi/nm-
device-wifi.c
index f6325a6..b147409 100644
--- a/src/devices/wifi/nm-device-wifi.c
+++ b/src/devices/wifi/nm-device-wifi.c
@@ -246,6 +246,13 @@ supplicant_interface_release (NMDeviceWifi
*self)

priv = NM_DEVICE_WIFI_GET_PRIVATE (self);

+   if (priv->requested_scan) {
+   nm_log_dbg (LOGD_WIFI_SCAN, "(%s): reset
requested_scan flag to FALSE",
+   nm_device_get_iface
(NM_DEVICE (self)));
+   priv->requested_scan = FALSE;
+   nm_device_remove_pending_action (NM_DEVICE (self),
"scan", TRUE);
+   }
+
nm_clear_g_source (>pending_scan_id);

/* Reset the scan interval to be pretty frequent when
disconnected */
@@ -1915,7 +1922,7 @@ supplicant_iface_state_cb
(NMSupplicantInterface *iface,
priv->requested_scan = FALSE;
}

-   cancel_pending_scan (self);
+   nm_clear_g_source (>pending_scan_id);
request_wireless_scan (self, NULL);
}
default:


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/2] Clear WiFi requested_scan if suppl goes INACTIVE

[Tony Espy]

On 06/08/2016 05:33 PM, Dan Williams wrote:

On Wed, 2016-06-08 at 16:24 -0400, Tony Espy wrote:

It's possible for wpa_supplicant to transition to INACTIVE
state with an outstanding requested_scan pending.  This can
lead to a stall condition where scanning no longer occurs.

Gbp-Pq: Name Clear-WiFi-requested_scan-if-suppl-goes-INACTIVE.patch
---
  src/devices/wifi/nm-device-wifi.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/src/devices/wifi/nm-device-wifi.c b/src/devices/wifi/nm-
device-wifi.c
index bacd5e6..f6325a6 100644
--- a/src/devices/wifi/nm-device-wifi.c
+++ b/src/devices/wifi/nm-device-wifi.c
@@ -1903,6 +1903,21 @@ supplicant_iface_state_cb
(NMSupplicantInterface *iface,
else
_LOGI (LOGD_DEVICE | LOGD_WIFI, "supplicant
interface keeps failing, giving up");
break;
+   case NM_SUPPLICANT_INTERFACE_STATE_INACTIVE:



I'd say we make this simpler; if the supplicant enters inactive state
that usually means either RFKILL or no enabled networks.  So we can
just do all this unconditionally:

 priv->requested_scan = FALSE;
 nm_clear_g_source (>pending_scan_id);
 request_wireless_scan (self, NULL);

Do you think that would work?


Yes.  I'll change and re-send.

/tony

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM can't see WEP access point

[Bastien Nocera]

On Thu, 2016-06-09 at 10:23 -0500, Dan Williams wrote:
> On Thu, 2016-06-09 at 17:13 +0200, Bastien Nocera wrote:
> > On Thu, 2016-06-09 at 10:00 -0500, Dan Williams wrote:
> > > 
> > > 
> > 
> > > 
> > > So I missed it before.  But your AP isn't actually set for WEP,
> > > it's
> > > set for WPA/TKIP.  If it's actually using just WEP, you won't see
> > > any
> > > of the RSN/WPA IEs in the beacon.
> > Still isn't right that it's not showing though, is it?
> 
> Yeah.  Can you 'nmcli g log', then:
> 
> nmcli g log level debug domains  domains>,WIFI_SCAN
> 
> and then turn on airplane mode, turn it off, and wait for a bit until
> you're sure the AP doesn't get found by NM.  Then send me the logs
> and
> I'll take a look to see if I can figure out why NM doesn't find it.
>  If
> the supplicant sees it, but NM does not, then there's an NM bug
> somewhere.

Well, wpa_supplicant is throwing an error when you try to get the RSN,
so I don't really expect NM to be able to process that access point.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM can't see WEP access point

[Dan Williams]

On Thu, 2016-06-09 at 17:13 +0200, Bastien Nocera wrote:
> On Thu, 2016-06-09 at 10:00 -0500, Dan Williams wrote:
> > 
> > 
> 
> > 
> > So I missed it before.  But your AP isn't actually set for WEP,
> > it's
> > set for WPA/TKIP.  If it's actually using just WEP, you won't see
> > any
> > of the RSN/WPA IEs in the beacon.
> Still isn't right that it's not showing though, is it?

Yeah.  Can you 'nmcli g log', then:

nmcli g log level debug domains ,WIFI_SCAN

and then turn on airplane mode, turn it off, and wait for a bit until
you're sure the AP doesn't get found by NM.  Then send me the logs and
I'll take a look to see if I can figure out why NM doesn't find it.  If
the supplicant sees it, but NM does not, then there's an NM bug
somewhere.

Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM can't see WEP access point

[Bastien Nocera]

On Thu, 2016-06-09 at 10:00 -0500, Dan Williams wrote:
> 

> So I missed it before.  But your AP isn't actually set for WEP, it's
> set for WPA/TKIP.  If it's actually using just WEP, you won't see any
> of the RSN/WPA IEs in the beacon.

Still isn't right that it's not showing though, is it?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM can't see WEP access point

[Dan Williams]

On Thu, 2016-06-09 at 15:34 +0200, Bastien Nocera wrote:
> On Tue, 2016-06-07 at 19:13 +0200, Bastien Nocera wrote:
> > 
> > On Tue, 2016-06-07 at 09:58 -0500, Dan Williams wrote:
> > > 
> > > On Tue, 2016-06-07 at 16:09 +0200, Bastien Nocera wrote:
> > > > 
> > > > Hey,
> > > > 
> > > > iwlist scan as root shows:
> > > >           Cell 17 - Address: 00:24:36:9D:3B:33
> > > > Channel:11
> > > > Frequency:2.462 GHz (Channel 11)
> > > > Quality=70/70  Signal level=-32 dBm  
> > > > Encryption key:on
> > > > ESSID:"WEP test"
> > > > 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
> > > > Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54
> > > > Mb/s
> > > > Mode:Master
> > > > Extra:tsf=0069f3b5fd9a
> > > > Extra: Last beacon: 27430ms ago
> > > > IE: Unknown: 00085745502074657374
> > > > IE: Unknown: 010882848B960C121824
> > > > IE: Unknown: 03010B
> > > > IE: Unknown: 0706474220010D1E
> > > > IE: Unknown: 2A0100
> > > > IE: Unknown: 32043048606C
> > > > IE: IEEE 802.11i/WPA2 Version 1
> > > > Group Cipher : WEP-104
> > > > Pairwise Ciphers (2) : CCMP TKIP
> > > > Authentication Suites (1) : PSK
> > > > IE: Unknown:
> > > > 2D1A2C401700
> > > > IE: Unknown:
> > > > 3D160B001100
> > > > IE: Unknown: 4605020001
> > > > IE: WPA Version 1
> > > > Group Cipher : WEP-104
> > > > Pairwise Ciphers (1) : TKIP
> > > > Authentication Suites (1) : PSK
> > > > IE: Unknown:
> > > > DD180050F2020101070003A427A442435E0062322F00
> > > > IE: Unknown: DD07000393016B0B20
> > > > IE: Unknown:
> > > > DD0E0017F207000101060024369D3B33
> > > > IE: Unknown: DD0B0017F2010001010007
> > > > 
> > > > Which is a WEP access point created on an Airport Express gen 1
> > > > device.
> > > > "nmcli -f all device wifi | grep 'WEP test'" doesn't show
> > > > anything
> > > > related to that access point?
> > > > 
> > > > Any ideas on how to debug this?
> > > It depends if the supplicant has actually exposed it via D-Bus
> > > yet
> > > too.
> > > 
> > > Grab http://people.redhat.com/dcbw/wpas-list.py and sudo-run that
> > > with
> > > the interface name of your wifi device, and see if the AP shows
> > > up
> > > in
> > > that list.  It directly dumps out the supplicant's AP list in a
> > > more
> > > readable form.
> > $ sudo ./wpas-list.py wlp2s0
> > [sudo] password for hadess: 
> >   54:64:d9:3e:0e:89  ::  ssid='Livebox-
> > 0E88'  wpa=yes  wpa2=yes  signal=-58%  freq=5240
> >   18:1e:78:70:c4:6b  ::  ssid='Livebox-
> > C46A'  wpa=yes  wpa2=yes  signal=-62%  freq=5520
> > Traceback (most recent call last):
> >   File "./wpas-list.py", line 68, in 
> > main()
> >   File "./wpas-list.py", line 46, in main
> > props = props_iface.GetAll(WPAS_DBUS_BSSID_INTERFACE)
> >   File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line
> > 70, in __call__
> > return self._proxy_method(*args, **keywords)
> >   File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line
> > 145, in __call__
> > **keywords)
> >   File "/usr/lib64/python2.7/site-packages/dbus/connection.py",
> > line 651, in call_blocking
> > message, timeout)
> > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed:
> > failed to parse RSN IE
> After adding a try/except:
> failed for /fi/w1/wpa_supplicant1/Interfaces/3/BSSs/2
> 
> Which is the "WEP test" AP I used.

So I missed it before.  But your AP isn't actually set for WEP, it's
set for WPA/TKIP.  If it's actually using just WEP, you won't see any
of the RSN/WPA IEs in the beacon.

Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM can't see WEP access point

[Bastien Nocera]

On Tue, 2016-06-07 at 19:13 +0200, Bastien Nocera wrote:
> On Tue, 2016-06-07 at 09:58 -0500, Dan Williams wrote:
> > On Tue, 2016-06-07 at 16:09 +0200, Bastien Nocera wrote:
> > > Hey,
> > > 
> > > iwlist scan as root shows:
> > >           Cell 17 - Address: 00:24:36:9D:3B:33
> > > Channel:11
> > > Frequency:2.462 GHz (Channel 11)
> > > Quality=70/70  Signal level=-32 dBm  
> > > Encryption key:on
> > > ESSID:"WEP test"
> > > 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
> > > Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
> > > Mode:Master
> > > Extra:tsf=0069f3b5fd9a
> > > Extra: Last beacon: 27430ms ago
> > > IE: Unknown: 00085745502074657374
> > > IE: Unknown: 010882848B960C121824
> > > IE: Unknown: 03010B
> > > IE: Unknown: 0706474220010D1E
> > > IE: Unknown: 2A0100
> > > IE: Unknown: 32043048606C
> > > IE: IEEE 802.11i/WPA2 Version 1
> > > Group Cipher : WEP-104
> > > Pairwise Ciphers (2) : CCMP TKIP
> > > Authentication Suites (1) : PSK
> > > IE: Unknown:
> > > 2D1A2C401700
> > > IE: Unknown:
> > > 3D160B001100
> > > IE: Unknown: 4605020001
> > > IE: WPA Version 1
> > > Group Cipher : WEP-104
> > > Pairwise Ciphers (1) : TKIP
> > > Authentication Suites (1) : PSK
> > > IE: Unknown:
> > > DD180050F2020101070003A427A442435E0062322F00
> > > IE: Unknown: DD07000393016B0B20
> > > IE: Unknown: DD0E0017F207000101060024369D3B33
> > > IE: Unknown: DD0B0017F2010001010007
> > > 
> > > Which is a WEP access point created on an Airport Express gen 1
> > > device.
> > > "nmcli -f all device wifi | grep 'WEP test'" doesn't show
> > > anything
> > > related to that access point?
> > > 
> > > Any ideas on how to debug this?
> > 
> > It depends if the supplicant has actually exposed it via D-Bus yet
> > too.
> > 
> > Grab http://people.redhat.com/dcbw/wpas-list.py and sudo-run that
> > with
> > the interface name of your wifi device, and see if the AP shows up
> > in
> > that list.  It directly dumps out the supplicant's AP list in a
> > more
> > readable form.
> 
> $ sudo ./wpas-list.py wlp2s0
> [sudo] password for hadess: 
>   54:64:d9:3e:0e:89  ::  ssid='Livebox-0E88'  wpa=yes  wpa2=yes  signal=-58%  
> freq=5240
>   18:1e:78:70:c4:6b  ::  ssid='Livebox-C46A'  wpa=yes  wpa2=yes  signal=-62%  
> freq=5520
> Traceback (most recent call last):
>   File "./wpas-list.py", line 68, in 
> main()
>   File "./wpas-list.py", line 46, in main
> props = props_iface.GetAll(WPAS_DBUS_BSSID_INTERFACE)
>   File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 70, in 
> __call__
> return self._proxy_method(*args, **keywords)
>   File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 145, in 
> __call__
> **keywords)
>   File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in 
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: failed to 
> parse RSN IE

After adding a try/except:
failed for /fi/w1/wpa_supplicant1/Interfaces/3/BSSs/2

Which is the "WEP test" AP I used.

$ sudo gdbus introspect --system --dest fi.w1.wpa_supplicant1 --object-path 
/fi/w1/wpa_supplicant1/Interfaces/3/BSSs/2

  interface fi.w1.wpa_supplicant1.BSS {
methods:
signals:
  PropertiesChanged(a{sv} properties);
properties:
  readonly ay SSID = [0x57, 0x45, 0x50, 0x20, 0x74, 0x65, 0x73, 0x74];
  readonly ay BSSID = [0x00, 0x24, 0x36, 0x9d, 0x3b, 0x33];
  readonly b Privacy = true;
  readonly s Mode = 'infrastructure';
  readonly n Signal = -35;
  readonly q Frequency = 2462;
  readonly au Rates = [5400, 4800, 3600, 2400, 1800, 
1200, 1100, 900, 600, 550, 200, 100];
  readonly a{sv} WPA = {'KeyMgmt': <['wpa-psk']>, 'Group': <''>, 
'Pairwise': <['tkip']>};
  readonly a{sv} RSN;
  readonly a{sv} WPS = {};
  readonly ay IEs = [0x00, 0x08, 0x57, 0x45, 0x50, 0x20, 0x74,
0x65, 0x73, 0x74, 0x01, 0x08, 0x82, 0x84, 0x8b, 0x96, 0x0c, 0x12, 0x18,
0x24, 0x03, 0x01, 0x0b, 0x07, 0x06, 0x47, 0x42, 0x20, 0x01, 0x0d, 0x1e,
0x2a, 0x01, 0x00, 0x32, 0x04, 0x30, 0x48, 0x60, 0x6c, 0x30, 0x18, 0x01,
0x00, 0x00, 0x0f, 0xac, 0x05, 0x02, 0x00, 0x00, 0x0f, 0xac, 

Re: nm-connection-editor forgets WPA password

[Bastien Nocera]

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