Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues

2017-05-18 Thread Dan Williams 
On Thu, 2017-05-18 at 20:23 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Thursday, May 18, 2017 2:24 PM
> > To: Matthew Starr; networkmanager-list@gnome.org
> > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > 
> > On Thu, 2017-05-18 at 18:43 +, Matthew Starr wrote:
> > > > -Original Message-
> > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > Sent: Thursday, May 18, 2017 1:31 PM
> > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > > > 
> > > > On Thu, 2017-05-18 at 15:54 +, Matthew Starr wrote:
> > > > > I have tried using NetworkManager 1.0.0 and 1.0.12 on an
> > > > > embedded
> > > > > device built with buildroot that has Ethernet (eth0), Wi-Fi
> > > > > client
> > > > > (mlan0), Wi-Fi Access Point (uap0), and Cellular interfaces
> > > > > (ttyACM0
> > > > > and ppp0).  The Wi-Fi AP (uap0) interface is ignored by
> > > > > Network
> > > > > Manager based on my NetworkManager.conf file. I am able to
> > > > > boot
> > > > > the device and Network Manager will automatically configure
> > > > > and
> > > > > connect with Ethernet, Wi-Fi Client, and Cellular interfaces
> > > > > every
> > > > > time.
> > > > > 
> > > > > If I move out of range of the Wi-Fi access point the device
> > > > > will
> > > > > disconnect and if I move back into range in under an hour,
> > > > > NetworkManager will reestablish the connection.  If I wait
> > > > > multiple hours before moving back into range of the Wi-Fi
> > > > > access
> > > > > point, Network Manager will not reestablish a connection
> > > > > automatically with the access point (I waited hours with the
> > > > > AP
> > > > > within range and visible in Wi-Fi scan results).  When
> > > > > Network
> > > > > Manager is not automatically reestablishing a connection to
> > > > > the
> > > > > access point I can use nmcli to bring up the profile
> > > > > associated
> > > > > with the access point and it connects immediately.
> > > > > 
> > > > > Why is Network Manager not able to auto connect to a Wi-Fi AP
> > > > > after a longer period of time of not seeing the AP?  Is there
> > > > > a
> > > > > timeout within Network Manager?  Is this a bug?
> > > > 
> > > > Like you say, it does look like NM is trying to auto-activate
> > > > the
> > > > connection, but it's not doing it correctly.  The most likely
> > > > thing
> > > > happening is that it does try to activate, but it's not able to
> > > > find
> > > > the "best" connection for the device.
> > > > Somehow the existing WiFi connection profile isn't matching.
> > > > 
> > > > Can you run 'nmcli con show  > > > start>'?
> > > 
> > > Dan,
> > > 
> > > This issue has occurred on several different access point I have
> > > attempted to connect to all from different vendors (Linksys,
> > > Ubiquiti,
> > > D-link).
> > 
> > Ok, that doesn't ellucidate anything.  Are you able to apply a
> > debugging patch
> > to NetworkManager and rebuild it?  Alternatively, you could use
> > 'gdb' to step
> > through the code and see where it's not proceeding with the
> > activation in
> > nm-policy.c.
> > 
> > Dan
> > 
> 
> Some additional testing I just finished shows that version 1.6.2
> exhibits the exact same behavior.
> 
> I am able to apply patches easily and rebuild.  I could run gdb but
> it is not quite as easy on my current setup.

Which version do you prefer patches for?

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

RE: Network Manager 1.0.X Wi-Fi Autoconnect Issues

2017-05-18 Thread Matthew Starr 
> -Original Message-
> From: Dan Williams [mailto:d...@redhat.com]
> Sent: Thursday, May 18, 2017 2:24 PM
> To: Matthew Starr; networkmanager-list@gnome.org
> Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> 
> On Thu, 2017-05-18 at 18:43 +, Matthew Starr wrote:
> > > -Original Message-
> > > From: Dan Williams [mailto:d...@redhat.com]
> > > Sent: Thursday, May 18, 2017 1:31 PM
> > > To: Matthew Starr; networkmanager-list@gnome.org
> > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > >
> > > On Thu, 2017-05-18 at 15:54 +, Matthew Starr wrote:
> > > > I have tried using NetworkManager 1.0.0 and 1.0.12 on an embedded
> > > > device built with buildroot that has Ethernet (eth0), Wi-Fi client
> > > > (mlan0), Wi-Fi Access Point (uap0), and Cellular interfaces
> > > > (ttyACM0
> > > > and ppp0).  The Wi-Fi AP (uap0) interface is ignored by Network
> > > > Manager based on my NetworkManager.conf file. I am able to boot
> > > > the device and Network Manager will automatically configure and
> > > > connect with Ethernet, Wi-Fi Client, and Cellular interfaces every
> > > > time.
> > > >
> > > > If I move out of range of the Wi-Fi access point the device will
> > > > disconnect and if I move back into range in under an hour,
> > > > NetworkManager will reestablish the connection.  If I wait
> > > > multiple hours before moving back into range of the Wi-Fi access
> > > > point, Network Manager will not reestablish a connection
> > > > automatically with the access point (I waited hours with the AP
> > > > within range and visible in Wi-Fi scan results).  When Network
> > > > Manager is not automatically reestablishing a connection to the
> > > > access point I can use nmcli to bring up the profile associated
> > > > with the access point and it connects immediately.
> > > >
> > > > Why is Network Manager not able to auto connect to a Wi-Fi AP
> > > > after a longer period of time of not seeing the AP?  Is there a
> > > > timeout within Network Manager?  Is this a bug?
> > >
> > > Like you say, it does look like NM is trying to auto-activate the
> > > connection, but it's not doing it correctly.  The most likely thing
> > > happening is that it does try to activate, but it's not able to find
> > > the "best" connection for the device.
> > > Somehow the existing WiFi connection profile isn't matching.
> > >
> > > Can you run 'nmcli con show  > > start>'?
> >
> > Dan,
> >
> > This issue has occurred on several different access point I have
> > attempted to connect to all from different vendors (Linksys, Ubiquiti,
> > D-link).
> 
> Ok, that doesn't ellucidate anything.  Are you able to apply a debugging patch
> to NetworkManager and rebuild it?  Alternatively, you could use 'gdb' to step
> through the code and see where it's not proceeding with the activation in
> nm-policy.c.
> 
> Dan
> 

Some additional testing I just finished shows that version 1.6.2 exhibits the 
exact same behavior.

I am able to apply patches easily and rebuild.  I could run gdb but it is not 
quite as easy on my current setup.

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

RE: Network Manager 1.0.X Wi-Fi Autoconnect Issues

2017-05-18 Thread Matthew Starr 
> -Original Message-
> From: Dan Williams [mailto:d...@redhat.com]
> Sent: Thursday, May 18, 2017 1:31 PM
> To: Matthew Starr; networkmanager-list@gnome.org
> Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> 
> On Thu, 2017-05-18 at 15:54 +, Matthew Starr wrote:
> > I have tried using NetworkManager 1.0.0 and 1.0.12 on an embedded
> > device built with buildroot that has Ethernet (eth0), Wi-Fi client
> > (mlan0), Wi-Fi Access Point (uap0), and Cellular interfaces (ttyACM0
> > and ppp0).  The Wi-Fi AP (uap0) interface is ignored by Network
> > Manager based on my NetworkManager.conf file. I am able to boot the
> > device and Network Manager will automatically configure and connect
> > with Ethernet, Wi-Fi Client, and Cellular interfaces every time.
> >
> > If I move out of range of the Wi-Fi access point the device will
> > disconnect and if I move back into range in under an hour,
> > NetworkManager will reestablish the connection.  If I wait multiple
> > hours before moving back into range of the Wi-Fi access point, Network
> > Manager will not reestablish a connection automatically with the
> > access point (I waited hours with the AP within range and visible in
> > Wi-Fi scan results).  When Network Manager is not automatically
> > reestablishing a connection to the access point I can use nmcli to
> > bring up the profile associated with the access point and it connects
> > immediately.
> >
> > Why is Network Manager not able to auto connect to a Wi-Fi AP after a
> > longer period of time of not seeing the AP?  Is there a timeout within
> > Network Manager?  Is this a bug?
> 
> Like you say, it does look like NM is trying to auto-activate the connection,
> but it's not doing it correctly.  The most likely thing happening is that it 
> does
> try to activate, but it's not able to find the "best" connection for the 
> device.
> Somehow the existing WiFi connection profile isn't matching.
> 
> Can you run 'nmcli con show '?

Dan,

This issue has occurred on several different access point I have attempted to 
connect to all from different vendors (Linksys, Ubiquiti, D-link).

Here is the output for my connection profile for one of them:

# nmcli con show linksys-hed-test
connection.id:  linksys-hed-test
connection.uuid:3a3fdd49-c624-42a3-acbd-135f728c9621
connection.interface-name:  mlan0
connection.type:802-11-wireless
connection.autoconnect: yes
connection.autoconnect-priority:0
connection.timestamp:   1495132442
connection.read-only:   no
connection.permissions: 
connection.zone:--
connection.master:  --
connection.slave-type:  --
connection.secondaries: 
connection.gateway-ping-timeout:0
802-11-wireless.ssid:   linksys-hed-test
802-11-wireless.mode:   --
802-11-wireless.band:   --
802-11-wireless.channel:0
802-11-wireless.bssid:  --
802-11-wireless.rate:   0
802-11-wireless.tx-power:   0
802-11-wireless.mac-address:--
802-11-wireless.cloned-mac-address: --
802-11-wireless.mac-address-blacklist:  
802-11-wireless.mtu:auto
802-11-wireless.seen-bssids:
802-11-wireless.hidden: no
802-11-wireless-security.key-mgmt:  wpa-psk
802-11-wireless-security.wep-tx-keyidx: 0
802-11-wireless-security.auth-alg:  --
802-11-wireless-security.proto: 
802-11-wireless-security.pairwise:  
802-11-wireless-security.group: 
802-11-wireless-security.leap-username: --
802-11-wireless-security.wep-key0:  
802-11-wireless-security.wep-key1:  
802-11-wireless-security.wep-key2:  
802-11-wireless-security.wep-key3:  
802-11-wireless-security.wep-key-flags: 0 (none)
802-11-wireless-security.wep-key-type:  0 (unknown)
802-11-wireless-security.psk:   
802-11-wireless-security.psk-flags: 0 (none)
802-11-wireless-security.leap-password: 
802-11-wireless-security.leap-password-flags:0 (none)
ipv4.method:auto
ipv4.dns:   
ipv4.dns-search:
ipv4.addresses: 
ipv4.gateway:   --
ipv4.routes:
ipv4.route-metric:  -1
ipv4.ignore-auto-routes:no
ipv4.ignore-auto-dns:   no
ipv4.dhcp-client-id:--
ipv4.dhcp-send-hostname:yes
ipv4.dhcp-hostname: --
ipv4.never-default: no
ipv4.may-fail:  yes
ipv6.method:auto
ipv6.dns:   
ipv6.dns-search:
ipv6.addresses:

Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues

2017-05-18 Thread Dan Williams 
On Thu, 2017-05-18 at 18:43 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Thursday, May 18, 2017 1:31 PM
> > To: Matthew Starr; networkmanager-list@gnome.org
> > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > 
> > On Thu, 2017-05-18 at 15:54 +, Matthew Starr wrote:
> > > I have tried using NetworkManager 1.0.0 and 1.0.12 on an embedded
> > > device built with buildroot that has Ethernet (eth0), Wi-Fi
> > > client
> > > (mlan0), Wi-Fi Access Point (uap0), and Cellular interfaces
> > > (ttyACM0
> > > and ppp0).  The Wi-Fi AP (uap0) interface is ignored by Network
> > > Manager based on my NetworkManager.conf file. I am able to boot
> > > the
> > > device and Network Manager will automatically configure and
> > > connect
> > > with Ethernet, Wi-Fi Client, and Cellular interfaces every time.
> > > 
> > > If I move out of range of the Wi-Fi access point the device will
> > > disconnect and if I move back into range in under an hour,
> > > NetworkManager will reestablish the connection.  If I wait
> > > multiple
> > > hours before moving back into range of the Wi-Fi access point,
> > > Network
> > > Manager will not reestablish a connection automatically with the
> > > access point (I waited hours with the AP within range and visible
> > > in
> > > Wi-Fi scan results).  When Network Manager is not automatically
> > > reestablishing a connection to the access point I can use nmcli
> > > to
> > > bring up the profile associated with the access point and it
> > > connects
> > > immediately.
> > > 
> > > Why is Network Manager not able to auto connect to a Wi-Fi AP
> > > after a
> > > longer period of time of not seeing the AP?  Is there a timeout
> > > within
> > > Network Manager?  Is this a bug?
> > 
> > Like you say, it does look like NM is trying to auto-activate the
> > connection,
> > but it's not doing it correctly.  The most likely thing happening
> > is that it does
> > try to activate, but it's not able to find the "best" connection
> > for the device.
> > Somehow the existing WiFi connection profile isn't matching.
> > 
> > Can you run 'nmcli con show  > start>'?
> 
> Dan,
> 
> This issue has occurred on several different access point I have
> attempted to connect to all from different vendors (Linksys,
> Ubiquiti, D-link).

Ok, that doesn't ellucidate anything.  Are you able to apply a
debugging patch to NetworkManager and rebuild it?  Alternatively, you
could use 'gdb' to step through the code and see where it's not
proceeding with the activation in nm-policy.c.

Dan

> Here is the output for my connection profile for one of them:
> 
> # nmcli con show linksys-hed-test
> connection.id:  linksys-hed-test
> connection.uuid:3a3fdd49-c624-42a3-acbd-
> 135f728c9621
> connection.interface-name:  mlan0
> connection.type:802-11-wireless
> connection.autoconnect: yes
> connection.autoconnect-priority:0
> connection.timestamp:   1495132442
> connection.read-only:   no
> connection.permissions: 
> connection.zone:--
> connection.master:  --
> connection.slave-type:  --
> connection.secondaries: 
> connection.gateway-ping-timeout:0
> 802-11-wireless.ssid:   linksys-hed-test
> 802-11-wireless.mode:   --
> 802-11-wireless.band:   --
> 802-11-wireless.channel:0
> 802-11-wireless.bssid:  --
> 802-11-wireless.rate:   0
> 802-11-wireless.tx-power:   0
> 802-11-wireless.mac-address:--
> 802-11-wireless.cloned-mac-address: --
> 802-11-wireless.mac-address-blacklist:  
> 802-11-wireless.mtu:auto
> 802-11-wireless.seen-bssids:
> 802-11-wireless.hidden: no
> 802-11-wireless-security.key-mgmt:  wpa-psk
> 802-11-wireless-security.wep-tx-keyidx: 0
> 802-11-wireless-security.auth-alg:  --
> 802-11-wireless-security.proto: 
> 802-11-wireless-security.pairwise:  
> 802-11-wireless-security.group: 
> 802-11-wireless-security.leap-username: --
> 802-11-wireless-security.wep-key0:  
> 802-11-wireless-security.wep-key1:  
> 802-11-wireless-security.wep-key2:  
> 802-11-wireless-security.wep-key3:  
> 802-11-wireless-security.wep-key-flags: 0 (none)
> 802-11-wireless-security.wep-key-type:  0 (unknown)
> 802-11-wireless-security.psk:   
> 802-11-wireless-security.psk-flags: 0 (none)
> 802-11-wireless-security.leap-password: 
> 802-11-wireless-security.leap-password-flags:0 (none)
> ipv4.method:auto
> ipv4.dns:   
> ipv4.dns-search:
> ipv4.addresses: 
> ipv4.gateway:   

Re: ModemManager (qmi_wann / qcserial) and gpsd

2017-05-18 Thread Dan Williams 
On Wed, 2017-05-17 at 21:28 -0600, Phil Daum wrote:
> Hi Dan,
> 
> Now that I had a 3G connection working on my Sierra Wireless MC7354
> (thanks
> to you), I would like to utilize the on-board GPS.  I was wondering
> if I
> could ask you a general question:
> 
> Is the use of gpsd compatible with the use of ModemManager using
> qmi_wann
> and qcserial?
> 
> The reason I ask is that I have source code utilizing the gpsd API
> which I
> would like to continue using.

If the device provides a couple serial ports alongside cdc-wmd0, then
one of them may be a GPS port as is common with Gobi-based devices.  So
you may be able to follow these directions:

http://www.thinkwiki.org/wiki/Qualcomm_Gobi_2000#GPS

and get it to work with the 7354 too.  ModemManager gets location info
through the QMI interface, not the AT serial port, so it should not
conflict with your parallel usage of the GPS tty.

If the device doesn't provide the standalone GPS tty, then you'd have
to modify your workflow to use ModemManager's location API instead,
which does have the ability to output text-based GPS strings, but does
so through the D-Bus API rather than a serial port.

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

Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues

2017-05-18 Thread Dan Williams 
On Thu, 2017-05-18 at 15:54 +, Matthew Starr wrote:
> I have tried using NetworkManager 1.0.0 and 1.0.12 on an embedded
> device built with buildroot that has Ethernet (eth0), Wi-Fi client
> (mlan0), Wi-Fi Access Point (uap0), and Cellular interfaces (ttyACM0
> and ppp0).  The Wi-Fi AP (uap0) interface is ignored by Network
> Manager based on my NetworkManager.conf file. I am able to boot the
> device and Network Manager will automatically configure and connect
> with Ethernet, Wi-Fi Client, and Cellular interfaces every time.
> 
> If I move out of range of the Wi-Fi access point the device will
> disconnect and if I move back into range in under an hour,
> NetworkManager will reestablish the connection.  If I wait multiple
> hours before moving back into range of the Wi-Fi access point,
> Network Manager will not reestablish a connection automatically with
> the access point (I waited hours with the AP within range and visible
> in Wi-Fi scan results).  When Network Manager is not automatically
> reestablishing a connection to the access point I can use nmcli to
> bring up the profile associated with the access point and it connects
> immediately.
> 
> Why is Network Manager not able to auto connect to a Wi-Fi AP after a
> longer period of time of not seeing the AP?  Is there a timeout
> within Network Manager?  Is this a bug?

Like you say, it does look like NM is trying to auto-activate the
connection, but it's not doing it correctly.  The most likely thing
happening is that it does try to activate, but it's not able to find
the "best" connection for the device.  Somehow the existing WiFi
connection profile isn't matching.

Can you run 'nmcli con show '?

Also, 'iw dev mlan0 scan dump', find the block for the expected AP, and
report that.  Feel free to replace the BSSID with xs or something if
you want to hide it.

My best guess is a mismatch between the AP's beacon/properties and the
connection somehow.

Dan

> Below is the debug log output when Network Manager 1.0.12 is not auto
> reconnecting. The Wi-Fi client (mlan0) is scanning for access points
> every 60 seconds, but the autoactivate attempt only happens every 5
> minutes but then appears to immediately remove the pending action of
> autoactivate on the mlan0 interface.  At the same time the cellular
> connection is attempting to connect and can't connect because of bad
> signal strength.
> 
> May 18 14:33:31 canect2 daemon.info NetworkManager[245]: 
> [1495118011.701118] [devices/nm-device.c:7019]
> nm_device_add_pending_action(): [0x213c268] (mlan0):
> add_pending_action (1): 'scan'
> May 18 14:33:31 canect2 daemon.info NetworkManager[245]: 
> [1495118011.702526] [devices/nm-device.c:7052]
> nm_device_remove_pending_action(): [0x213c268] (mlan0):
> remove_pending_action (0): 'scan'
> May 18 14:33:31 canect2 user.alert kernel: [149885.509332] wlan:
> mlan0 START SCAN
> May 18 14:33:33 canect2 daemon.info ModemManager[423]:   Modem
> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
> changed (idle -> searching)
> May 18 14:33:33 canect2 daemon.info NetworkManager[245]: 
> [1495118013.317075] [platform/nm-linux-platform.c:1950]
> event_notification(): netlink event (type 16) for link: mlan0 (6,
> family 0)
> May 18 14:33:33 canect2 daemon.info NetworkManager[245]: 
> [1495118013.317486] [platform/nm-linux-platform.c:426]
> get_kernel_object(): get_kernel_object for link: mlan0 (6, family 0)
> May 18 14:33:33 canect2 daemon.info NetworkManager[245]: 
> [1495118013.318059] [platform/nm-linux-platform.c:1950]
> event_notification(): netlink event (type 16) for link: mlan0 (6,
> family 0)
> May 18 14:33:33 canect2 daemon.info NetworkManager[245]: 
> [1495118013.318402] [platform/nm-linux-platform.c:426]
> get_kernel_object(): get_kernel_object for link: mlan0 (6, family 0)
> May 18 14:33:33 canect2 user.warn kernel: [149887.121037] wlan: SCAN
> COMPLETED: scanned AP count=12
> May 18 14:33:33 canect2 user.err kernel: [149887.134455] Invalid
> sched_scan req parameter
> May 18 14:33:47 canect2 daemon.info ModemManager[423]:   Modem
> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
> changed (searching -> idle)
> May 18 14:33:52 canect2 daemon.info ModemManager[423]:   Modem
> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
> changed (idle -> searching)
> May 18 14:33:52 canect2 daemon.info ModemManager[423]:   Modem
> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
> changed (searching -> idle)
> May 18 14:33:57 canect2 daemon.info ModemManager[423]:   Modem
> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
> changed (idle -> searching)
> May 18 14:33:57 canect2 daemon.info ModemManager[423]:   Modem
> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
> changed (searching -> idle)
> May 18 14:34:02 canect2 daemon.info ModemManager[423]:   Modem
> /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state
> changed (idle -> searching)
> May 18 14:34:03

Re: [PATCH] Do not skip wifi slave connections

2017-05-18 Thread Nikolay Martynov 
Hi.

2017-05-18 12:22 GMT-04:00 Beniamino Galvani :
> On Thu, May 18, 2017 at 11:42:47AM -0400, Nikolay Martynov wrote:
>> Just to clarify: this patch only affects wifi bonded connections.
>> 'Classic' ethernet bond slaves are still skipped - so this change
>> should not affect existing users.
>> I think the intention of original patch was to hide ethernet ones.
>> The problem with wifi slaves is that they are not hidden since they
>> actually come from scan results - they still pop up in the list of
>> available APs. And this is the good thing - this means I can connect
>> and disconnect wifi bond slave at will from the applet.
>> So, with this in mind - could you please clarify why you think this is
>> not the right thing to do so I could try to address that? :)
>>
>
> Since wifi slave connection are displayed only if the matching SSID is
> found, and they don't waste space in the menu because they are grouped
> in the AP submenu, I think it's ok to display them.
>
> On the other hand, you still wouldn't be able to control the bond and
> the ethernet slave from the applet, so I wonder if this is really
> useful.
  As I've sort of tried to explain in comment to the patch:
  * Before this patch clicking on AP that is bond slave makes NM
create new connection for that AP name (i.e. it asks for secrets and
everything) - this is not what user would normally want because he
already has this SSID configured as bond slave
  * With this patch clicking same AP actually establishes bond slave
connection that was configured before and doesn't create a new one.
  From this perspective this is actually useful.

>
> Anyway, the patch LGTM.

Thanks!


-- 
Martynov Nikolay.
Email: mar.ko...@gmail.com
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] Do not skip wifi slave connections

2017-05-18 Thread Beniamino Galvani 
On Thu, May 18, 2017 at 11:42:47AM -0400, Nikolay Martynov wrote:
> Just to clarify: this patch only affects wifi bonded connections.
> 'Classic' ethernet bond slaves are still skipped - so this change
> should not affect existing users.
> I think the intention of original patch was to hide ethernet ones.
> The problem with wifi slaves is that they are not hidden since they
> actually come from scan results - they still pop up in the list of
> available APs. And this is the good thing - this means I can connect
> and disconnect wifi bond slave at will from the applet.
> So, with this in mind - could you please clarify why you think this is
> not the right thing to do so I could try to address that? :)
> 

Since wifi slave connection are displayed only if the matching SSID is
found, and they don't waste space in the menu because they are grouped
in the AP submenu, I think it's ok to display them.

On the other hand, you still wouldn't be able to control the bond and
the ethernet slave from the applet, so I wonder if this is really
useful.

Anyway, the patch LGTM.

Beniamino


signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Network Manager 1.0.X Wi-Fi Autoconnect Issues

2017-05-18 Thread Matthew Starr 
I have tried using NetworkManager 1.0.0 and 1.0.12 on an embedded device built 
with buildroot that has Ethernet (eth0), Wi-Fi client (mlan0), Wi-Fi Access 
Point (uap0), and Cellular interfaces (ttyACM0 and ppp0).  The Wi-Fi AP (uap0) 
interface is ignored by Network Manager based on my NetworkManager.conf file. I 
am able to boot the device and Network Manager will automatically configure and 
connect with Ethernet, Wi-Fi Client, and Cellular interfaces every time.

If I move out of range of the Wi-Fi access point the device will disconnect and 
if I move back into range in under an hour, NetworkManager will reestablish the 
connection.  If I wait multiple hours before moving back into range of the 
Wi-Fi access point, Network Manager will not reestablish a connection 
automatically with the access point (I waited hours with the AP within range 
and visible in Wi-Fi scan results).  When Network Manager is not automatically 
reestablishing a connection to the access point I can use nmcli to bring up the 
profile associated with the access point and it connects immediately.

Why is Network Manager not able to auto connect to a Wi-Fi AP after a longer 
period of time of not seeing the AP?  Is there a timeout within Network 
Manager?  Is this a bug?

Below is the debug log output when Network Manager 1.0.12 is not auto 
reconnecting. The Wi-Fi client (mlan0) is scanning for access points every 60 
seconds, but the autoactivate attempt only happens every 5 minutes but then 
appears to immediately remove the pending action of autoactivate on the mlan0 
interface.  At the same time the cellular connection is attempting to connect 
and can't connect because of bad signal strength.

May 18 14:33:31 canect2 daemon.info NetworkManager[245]:  
[1495118011.701118] [devices/nm-device.c:7019] nm_device_add_pending_action(): 
[0x213c268] (mlan0): add_pending_action (1): 'scan'
May 18 14:33:31 canect2 daemon.info NetworkManager[245]:  
[1495118011.702526] [devices/nm-device.c:7052] 
nm_device_remove_pending_action(): [0x213c268] (mlan0): remove_pending_action 
(0): 'scan'
May 18 14:33:31 canect2 user.alert kernel: [149885.509332] wlan: mlan0 START 
SCAN
May 18 14:33:33 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (idle 
-> searching)
May 18 14:33:33 canect2 daemon.info NetworkManager[245]:  
[1495118013.317075] [platform/nm-linux-platform.c:1950] event_notification(): 
netlink event (type 16) for link: mlan0 (6, family 0)
May 18 14:33:33 canect2 daemon.info NetworkManager[245]:  
[1495118013.317486] [platform/nm-linux-platform.c:426] get_kernel_object(): 
get_kernel_object for link: mlan0 (6, family 0)
May 18 14:33:33 canect2 daemon.info NetworkManager[245]:  
[1495118013.318059] [platform/nm-linux-platform.c:1950] event_notification(): 
netlink event (type 16) for link: mlan0 (6, family 0)
May 18 14:33:33 canect2 daemon.info NetworkManager[245]:  
[1495118013.318402] [platform/nm-linux-platform.c:426] get_kernel_object(): 
get_kernel_object for link: mlan0 (6, family 0)
May 18 14:33:33 canect2 user.warn kernel: [149887.121037] wlan: SCAN COMPLETED: 
scanned AP count=12
May 18 14:33:33 canect2 user.err kernel: [149887.134455] Invalid sched_scan req 
parameter
May 18 14:33:47 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed 
(searching -> idle)
May 18 14:33:52 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (idle 
-> searching)
May 18 14:33:52 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed 
(searching -> idle)
May 18 14:33:57 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (idle 
-> searching)
May 18 14:33:57 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed 
(searching -> idle)
May 18 14:34:02 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (idle 
-> searching)
May 18 14:34:03 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed 
(searching -> idle)
May 18 14:34:08 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (idle 
-> searching)
May 18 14:34:08 canect2 daemon.info ModemManager[423]:   Modem 
/org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed 
(searching -> idle)
May 18 14:34:12 canect2 daemon.info NetworkManager[245]:  
[1495118052.692978] [devices/nm-device.c:7019] nm_device_add_pending_action(): 
[0x213c268] (mlan0): add_pending_action (1): 'autoactivate'
May 18 14:34:12 canect2 daemon.info NetworkManager[245]:  
[1495118052.693286] [devices/nm-device.c:7019]

Re: [PATCH] Do not skip wifi slave connections

2017-05-18 Thread Nikolay Martynov 
Hi.

Thanks for your response!

2017-05-18 11:32 GMT-04:00 Thomas Haller :
> On Tue, 2017-05-16 at 22:13 -0400, Nikolay Martynov wrote:
>> If slave connection is a wifi connection we should still display it
>> Otherwise this AP gets scanned regardless, but when user clicks it
>> new
>> network is created in NM's configuation - which is unlikely what user
>> desired
>
> Hi Nikolay,
>
> I see what the patch does, but I am not convinced that it's the right
> thing to do.
>
> In a way, it changes
> https://git.gnome.org/browse/network-manager-applet/commit/?h=0abe8a8f46bcdce5907882ba355ec69156b33164
>
> Other opinions?

Just to clarify: this patch only affects wifi bonded connections.
'Classic' ethernet bond slaves are still skipped - so this change
should not affect existing users.
I think the intention of original patch was to hide ethernet ones.
The problem with wifi slaves is that they are not hidden since they
actually come from scan results - they still pop up in the list of
available APs. And this is the good thing - this means I can connect
and disconnect wifi bond slave at will from the applet.
So, with this in mind - could you please clarify why you think this is
not the right thing to do so I could try to address that? :)

Thanks!

-- 
Martynov Nikolay.
Email: mar.ko...@gmail.com
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] Do not skip wifi slave connections

2017-05-18 Thread Thomas Haller 
On Tue, 2017-05-16 at 22:13 -0400, Nikolay Martynov wrote:
> If slave connection is a wifi connection we should still display it
> Otherwise this AP gets scanned regardless, but when user clicks it
> new
> network is created in NM's configuation - which is unlikely what user
> desired

Hi Nikolay,

I see what the patch does, but I am not convinced that it's the right
thing to do.

In a way, it changes
https://git.gnome.org/browse/network-manager-applet/commit/?h=0abe8a8f46bcdce5907882ba355ec69156b33164

Other opinions?


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