Re: Changing IP on bridge without disconnecting VMs

[Dan Williams via networkmanager-list]

On Wed, 2022-07-13 at 07:57 -0500, Chris Adams via networkmanager-list
wrote:
> I have my primary ethernet interface configured in a bridge in NM, so
> that I can run VMs and have them on the local network directly.  I
> needed to change the IP of the host system, but when I ran "nmcli con
> up
> br0", NM removed the VM virtual NICs from the bridge.
> 
> Is there a way to do this differently so that wouldn't happen?  It's
> not
> a common thing of course, but something I have needed to do before.

I think this two step process might work for you:

1) update the connection to remove the old IP and add the new one, with
something like:

nmcli con  mod +ipv4.addresses 
nmcli con  mod -ipv4.addresses 

2) nmcli dev reapply 

Dan

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

Re: Agreement to relicense NetworkManager under LGPL-2.1+

[Dan Williams via networkmanager-list]

Ciaran,

Just to clarify, does this authorization include contributions made by
Novell/SUSE employees, when Novell and SUSE were combined from 2003 -
2011?

Thanks!
Dan

On Thu, 2020-09-17 at 15:09 +, Ciaran Farrell wrote:
> SUSE LLC hereby agrees to relicense any contributions under SUSE LLC
> or
> its corporate affiliates' ("SUSE Group") copyright to NetworkManager
> under GNU LGPL-2.1+ as proposed by Thomas Haller.
> 
> Specifically, this authorization applies to contributions of SUSE
> Group
> made by and through its employees, who have submitted source code to
> Network Manager.
> 
> Ciaran Farrell
> IP & Privacy Counsel
> SUSE
> 
> ___
> 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: Use signal strength when choosing AP

[Dan Williams via networkmanager-list]

On Wed, 2020-07-15 at 12:31 +0200, Gonsolo via networkmanager-list
wrote:
> Hi!
> 
> I have a home network with a router and a repeater. Network manager
> always connects to the last used network so I have to switch manually
> to the nearest AP when I take the notebook from the workroom to the
> living room. Is there a way to tell NetworkManager to do this
> automatically?

This isn't really an answer, but typically you use the same SSID for
your repeater and your main router, and the devices (computer, phones,
etc) will switch between them automatically based on signal strength.
Is that not possible in your setup?
Dan

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

Re: Collect agreement/disagreement to Relicense NetworkManager under LGPL-2.1+

[Dan Williams via networkmanager-list]

On Thu, 2020-01-09 at 09:14 -0500, Dan Winship via networkmanager-list
wrote:
> Thomas asked me to send email agreeing to the relicensing. I am not
> the
> copyright holder of any code in NetworkManager and do not believe
> that I
> have any say in this decision, but if it turns out that I do, then,
> sure, I agree.

I also agree (though like Dan, the copyright on my contributions is
held by Red Hat any may be relicensed as Thomas requests).

dan

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

Re: WiFi AP selection

[Dan Williams via networkmanager-list]

On Tue, 2019-10-22 at 15:00 -0700, Clive McCarthy wrote:
> The only odd thing I see is: current_signal=-54 current_noise=

What I think is happening is a wpa_supplicant bug with roaming and
"reassociate" handling. For some reason the supplicant sets a
reassociate flag when a given WiFi network is selected by NM, and that
short-circuits the signal checks in wpa_supplicant_need_to_roam() which
is called by wpas_select_network_from_last_scan() which itself is
called by wpa_supplicant_fast_associate() which is called by
wpa_supplicant_select_network().

We'll need to check with wpa_supplicant to see if this is intended
behavior (I can't think why it would be) or if this analysis is in
error.

Dan

> On 10/22/19 2:24 PM, Dan Williams wrote:
> > On Tue, 2019-10-22 at 13:37 -0700, Clive McCarthy wrote:
> > > I rand the commands you suggested but the response doesn't look
> > > like
> > > a log dump. I guess they just enable logging.
> > > 
> > > method return time=1571775394.161873 sender=:1.8 ->
> > > destination=:1.507 serial=32493 reply_serial=2
> > > method return time=1571775429.864202 sender=:1.8 ->
> > > destination=:1.508 serial=32496 reply_serial=2
> > > method return time=1571775528.578915 sender=:1.8 ->
> > > destination=:1.510 serial=32636 reply_serial=2
> > > 
> > > Can you point me to where the log files might be or at least
> > > their
> > > names.
> > 
> > If your distribution uses systemd, they may be available with:
> > 
> > journalctl -b -u wpa_supplicant
> > 
> > if your distro does not uses systemd, then it'll be wherever syslog
> > dumps that kind of output, like:
> > 
> > /var/log/messages
> > /var/log/wpa_supplicant.log
> > /var/log/daemon.log
> > 
> > Dan
> > 
> > > On 10/22/19 12:16 PM, Dan Williams wrote:
> > > > On Tue, 2019-10-22 at 11:17 -0700, Clive McCarthy wrote:
> > > > > Thanks for your reply.
> > > > > My laptop, when first opened, reports (via the Network
> > > > > Manage, I
> > > > > suppose) that it is disconnected from the network. After a
> > > > > second
> > > > > or
> > > > > two it reports being connected. And it is. However, as I
> > > > > noted,
> > > > > the
> > > > > manager seems to choose the last known connection. This is a
> > > > > satisfactory algorithm for a fixed computer and for a
> > > > > computer
> > > > > connecting to a single AP. It isn't good for a movable
> > > > > computer
> > > > > with
> > > > > multiple APs.
> > > > > 
> > > > > The Intel WiFi adapter is forced to shutdown when the
> > > > > computer is
> > > > > closed because there is a bug in the Intel-WiFi driver that
> > > > > doesn't
> > > > > handle suspend correctly. That is why there is a disconnect-
> > > > > connect
> > > > > sequence.
> > > > 
> > > > In this case we'd need the wpa_supplicant logs described below
> > > > to
> > > > diagnose why the supplicant is picking that specific AP rather
> > > > than
> > > > another.
> > > > 
> > > > Dan
> > > > 
> > > > 
> > > > > On 10/22/19 10:05 AM, Dan Williams wrote:
> > > > > > On Mon, 2019-10-21 at 20:42 -0700, Clive McCarthy via
> > > > > > networkmanager-
> > > > > > list wrote:
> > > > > > > I have a situation where I have multiple APs in a
> > > > > > > building
> > > > > > > all
> > > > > > > with
> > > > > > > the same SSID and WPA key but set to non-clashing
> > > > > > > frequencies.
> > > > > > > When I
> > > > > > > close my laptop and WiFi shuts down and I move to a new
> > > > > > > location
> > > > > > > the
> > > > > > > Network Manager seems to connect to the original AP,
> > > > > > > rather
> > > > > > > than
> > > > > > > one
> > > > > > > with a much stronger signal.
> > > > > > > 
> > > > > > > The algorithm for AP connection is suboptimal (in other
> > > > > > > words
> > > > > > > dumb).
> > > > > > >

Re: WiFi AP selection

[Dan Williams via networkmanager-list]

On Tue, 2019-10-22 at 13:37 -0700, Clive McCarthy wrote:
> I rand the commands you suggested but the response doesn't look like
> a log dump. I guess they just enable logging.
> 
> method return time=1571775394.161873 sender=:1.8 ->
> destination=:1.507 serial=32493 reply_serial=2
> method return time=1571775429.864202 sender=:1.8 ->
> destination=:1.508 serial=32496 reply_serial=2
> method return time=1571775528.578915 sender=:1.8 ->
> destination=:1.510 serial=32636 reply_serial=2
> 
> Can you point me to where the log files might be or at least their
> names.

If your distribution uses systemd, they may be available with:

journalctl -b -u wpa_supplicant

if your distro does not uses systemd, then it'll be wherever syslog
dumps that kind of output, like:

/var/log/messages
/var/log/wpa_supplicant.log
/var/log/daemon.log

Dan

> On 10/22/19 12:16 PM, Dan Williams wrote:
> > On Tue, 2019-10-22 at 11:17 -0700, Clive McCarthy wrote:
> > > Thanks for your reply.
> > > My laptop, when first opened, reports (via the Network Manage, I
> > > suppose) that it is disconnected from the network. After a second
> > > or
> > > two it reports being connected. And it is. However, as I noted,
> > > the
> > > manager seems to choose the last known connection. This is a
> > > satisfactory algorithm for a fixed computer and for a computer
> > > connecting to a single AP. It isn't good for a movable computer
> > > with
> > > multiple APs.
> > > 
> > > The Intel WiFi adapter is forced to shutdown when the computer is
> > > closed because there is a bug in the Intel-WiFi driver that
> > > doesn't
> > > handle suspend correctly. That is why there is a disconnect-
> > > connect
> > > sequence.
> > 
> > In this case we'd need the wpa_supplicant logs described below to
> > diagnose why the supplicant is picking that specific AP rather than
> > another.
> > 
> > Dan
> > 
> > 
> > > On 10/22/19 10:05 AM, Dan Williams wrote:
> > > > On Mon, 2019-10-21 at 20:42 -0700, Clive McCarthy via
> > > > networkmanager-
> > > > list wrote:
> > > > > I have a situation where I have multiple APs in a building
> > > > > all
> > > > > with
> > > > > the same SSID and WPA key but set to non-clashing
> > > > > frequencies.
> > > > > When I
> > > > > close my laptop and WiFi shuts down and I move to a new
> > > > > location
> > > > > the
> > > > > Network Manager seems to connect to the original AP, rather
> > > > > than
> > > > > one
> > > > > with a much stronger signal.
> > > > > 
> > > > > The algorithm for AP connection is suboptimal (in other words
> > > > > dumb).
> > > > > The selection process should scan ALL APs, figure out which
> > > > > ones
> > > > > are
> > > > > known (SSID and WPA); measure their signal strength and then
> > > > > choose
> > > > > the known AP with the strongest signal.
> > > > > 
> > > > > How hard is that?
> > > > 
> > > > This is what NetworkManager should already be doing.
> > > > 
> > > > Two things to check:
> > > > 
> > > > 1) NetworkManager depends on being notified by systemd or
> > > > upower
> > > > that
> > > > the laptop has suspended so that it can reconfigure when it
> > > > wakes
> > > > up.
> > > > It should be pretty clear if that's happening through the
> > > > NetworkManager logs because it will say that it's going to
> > > > sleep
> > > > and
> > > > waking up. For example:
> > > > 
> > > > NetworkManager[1198]:   [1571720491.7590] manager: sleep:
> > > > sleep requested (sleeping: no  enabled: yes)
> > > > NetworkManager[1198]:   [1571720491.7599] device
> > > > (wlp61s0):
> > > > state change: disconnected -> unmanaged (reason 'sleeping',
> > > > sys-
> > > > iface-state: 'managed')
> > > > NetworkManager[1198]:   [1571720491.7615] manager:
> > > > NetworkManager state is now ASLEEP
> > > > NetworkManager[1198]:   [1571752873.5481] sup-
> > > > iface[0x55f38553aaa0,wlp61s0]: connection disconnected (reason
> > > > -3)
> > > > NetworkManager[1198]:   [1571

Re: Enabling LTE

[Dan Williams via networkmanager-list]

On Tue, 2019-10-22 at 19:47 +0200, Bjørn Mork via networkmanager-list
wrote:
> Marc Murphy  writes:
> 
> > If I swap to a 3G antenna on mPCIe modems it will connect first
> > time
> > on 3G.
> > 
> > My main query is that why can an iPhone connect and us the 4G
> > signal
> > and the multiple modems not ?  ZTE ME3630 E1C mPCIe
> 
> The main difference I can think of is that LTE registration depends
> on a
> default bearer.  You may have to configure an APN and context type
> for
> this.  How to do that on a modem is not well defined unfortunately...
> You could try configuring context ID #1. Use the APN and context type
> that works on your phone.
> 
> But I guess ModemManager already should to this, so the problem is
> probably something else...

My other thought was that if the modems are QMI then perhaps the band
mask is misconfigured to ignore those bands, even if the hardware is
capable of it?

Even if they aren't QMI then if they have an AT channel there may be
vendor-specific commands to read the enabled bands.

Dan

> Anyway, no harm in testing. Use a terminal program connected to the
> AT
> command port:
> 
>  AT+CGDCONT=1,"IPV4V6","APN"
> 
> Or start ModemManager with --debug and run
> 
>  mmcli -m 0 --command='+CGDCONT=1,"IPV4V6","APN"'
> 
> 
> 
> Bjørn
> 
> 
> ___
> 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: WiFi AP selection

[Dan Williams via networkmanager-list]

On Tue, 2019-10-22 at 11:17 -0700, Clive McCarthy wrote:
> Thanks for your reply.
> My laptop, when first opened, reports (via the Network Manage, I
> suppose) that it is disconnected from the network. After a second or
> two it reports being connected. And it is. However, as I noted, the
> manager seems to choose the last known connection. This is a
> satisfactory algorithm for a fixed computer and for a computer
> connecting to a single AP. It isn't good for a movable computer with
> multiple APs.
> 
> The Intel WiFi adapter is forced to shutdown when the computer is
> closed because there is a bug in the Intel-WiFi driver that doesn't
> handle suspend correctly. That is why there is a disconnect-connect
> sequence.

In this case we'd need the wpa_supplicant logs described below to
diagnose why the supplicant is picking that specific AP rather than
another.

Dan


> On 10/22/19 10:05 AM, Dan Williams wrote:
> > On Mon, 2019-10-21 at 20:42 -0700, Clive McCarthy via
> > networkmanager-
> > list wrote:
> > > I have a situation where I have multiple APs in a building all
> > > with
> > > the same SSID and WPA key but set to non-clashing frequencies.
> > > When I
> > > close my laptop and WiFi shuts down and I move to a new location
> > > the
> > > Network Manager seems to connect to the original AP, rather than
> > > one
> > > with a much stronger signal.
> > > 
> > > The algorithm for AP connection is suboptimal (in other words
> > > dumb).
> > > The selection process should scan ALL APs, figure out which ones
> > > are
> > > known (SSID and WPA); measure their signal strength and then
> > > choose
> > > the known AP with the strongest signal.
> > > 
> > > How hard is that?
> > 
> > This is what NetworkManager should already be doing.
> > 
> > Two things to check:
> > 
> > 1) NetworkManager depends on being notified by systemd or upower
> > that
> > the laptop has suspended so that it can reconfigure when it wakes
> > up.
> > It should be pretty clear if that's happening through the
> > NetworkManager logs because it will say that it's going to sleep
> > and
> > waking up. For example:
> > 
> > NetworkManager[1198]:   [1571720491.7590] manager: sleep:
> > sleep requested (sleeping: no  enabled: yes)
> > NetworkManager[1198]:   [1571720491.7599] device (wlp61s0):
> > state change: disconnected -> unmanaged (reason 'sleeping', sys-
> > iface-state: 'managed')
> > NetworkManager[1198]:   [1571720491.7615] manager:
> > NetworkManager state is now ASLEEP
> > NetworkManager[1198]:   [1571752873.5481] sup-
> > iface[0x55f38553aaa0,wlp61s0]: connection disconnected (reason -3)
> > NetworkManager[1198]:   [1571752873.5504] device (wlp61s0):
> > supplicant interface state: completed -> disconnected
> > NetworkManager[1198]:   [1571752873.5803] manager: sleep:
> > wake requested (sleeping: yes  enabled: yes)
> > NetworkManager[1198]:   [1571752873.6556] device (wlp61s0):
> > state change: activated -> unmanaged (reason 'sleeping', sys-iface-
> > state: 'managed')
> > 
> > 2) enabling debug logging in wpa_supplicant with these two commands
> > will show you exactly what's going on:
> > 
> > sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
> > /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
> > string:fi.w1.wpa_supplicant1 string:DebugTimestamp
> > variant:boolean:true
> > sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1
> > /fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set
> > string:fi.w1.wpa_supplicant1 string:DebugLevel
> > variant:string:"msgdump"
> > 
> > this will dump logs to wherever your system typically sends system
> > logs, like the systemd journal or syslog. Once you have these logs,
> > please review them to ensure there is no private information and
> > then
> > attach them to a reply so that we can figure out what's going on.
> > 
> > Thanks!
> > Dan
> > 
>  

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

Re: WiFi AP selection

[Dan Williams via networkmanager-list]

On Mon, 2019-10-21 at 20:42 -0700, Clive McCarthy via networkmanager-
list wrote:
> I have a situation where I have multiple APs in a building all with
> the same SSID and WPA key but set to non-clashing frequencies. When I
> close my laptop and WiFi shuts down and I move to a new location the
> Network Manager seems to connect to the original AP, rather than one
> with a much stronger signal.
> 
> The algorithm for AP connection is suboptimal (in other words dumb).
> The selection process should scan ALL APs, figure out which ones are
> known (SSID and WPA); measure their signal strength and then choose
> the known AP with the strongest signal.
> 
> How hard is that?

This is what NetworkManager should already be doing.

Two things to check:

1) NetworkManager depends on being notified by systemd or upower that
the laptop has suspended so that it can reconfigure when it wakes up.
It should be pretty clear if that's happening through the
NetworkManager logs because it will say that it's going to sleep and
waking up. For example:

NetworkManager[1198]:   [1571720491.7590] manager: sleep: sleep requested 
(sleeping: no  enabled: yes)
NetworkManager[1198]:   [1571720491.7599] device (wlp61s0): state change: 
disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
NetworkManager[1198]:   [1571720491.7615] manager: NetworkManager state 
is now ASLEEP
NetworkManager[1198]:   [1571752873.5481] 
sup-iface[0x55f38553aaa0,wlp61s0]: connection disconnected (reason -3)
NetworkManager[1198]:   [1571752873.5504] device (wlp61s0): supplicant 
interface state: completed -> disconnected
NetworkManager[1198]:   [1571752873.5803] manager: sleep: wake requested 
(sleeping: yes  enabled: yes)
NetworkManager[1198]:   [1571752873.6556] device (wlp61s0): state change: 
activated -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')

2) enabling debug logging in wpa_supplicant with these two commands
will show you exactly what's going on:

sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 
/fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set 
string:fi.w1.wpa_supplicant1 string:DebugTimestamp variant:boolean:true
sudo dbus-send --system --print-reply --dest=fi.w1.wpa_supplicant1 
/fi/w1/wpa_supplicant1 org.freedesktop.DBus.Properties.Set 
string:fi.w1.wpa_supplicant1 string:DebugLevel variant:string:"msgdump"

this will dump logs to wherever your system typically sends system
logs, like the systemd journal or syslog. Once you have these logs,
please review them to ensure there is no private information and then
attach them to a reply so that we can figure out what's going on.

Thanks!
Dan

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

Re: Setup for multiple different gsm.sim-operator-id?

[Dan Williams via networkmanager-list]

On Wed, 2019-09-11 at 13:01 +0200, Einar Jón via networkmanager-list
wrote:
> On Wed, 4 Sep 2019 at 22:43, Thomas Haller 
> wrote:
> > On Wed, 2019-09-04 at 21:59 +0200, Einar Jón wrote:
> > > On Wed, 4 Sep 2019 at 17:11, Thomas Haller 
> > > wrote:
> > > > On Wed, 2019-09-04 at 16:46 +0200, Einar Jón via
> > > > networkmanager-
> > > > list
> > > > wrote:
> [snip]
> > > > I think that is not possible, you would need a different
> > > > connection
> > > > profile for each operator.
> > > 
> > > I was thinking of doing that, creating profiles
> > > modem12345.nmconnection
> > > modem22334.nmconnection
> > > modem556677.nmconnection
> > > etc...
> > > 
> > > But grabbing
> > > IMSI=$(mmcli -m XX| awk /operator id/ ...)
> > > and calling
> > > nmcli c do-stuff modem$IMSI
> > > seems to be the wrong way to use NetworkManager.
> > 
> > Hi,
> > 
> > I think you would create each profile only once.
> > 
> > Afterwards, you should be able to
> > 
> >   nmcli device connect $MODEM
> > 
> > and then (depending on the SIM), only one of the profiles is a
> > suitable candidate to activate. You can set properties in the
> > profile
> > that tie to the operator, can't you?
> > 
> > The only problem is that you have a larger number of profiles,
> > and that you need to create them (once).
> 
> I think we are talking about the same thing. Or I don't understand.
> My device ($MODEM) is always cdc-wdm0. I have a python script
> that creates multiple profiles that are identical apart from the
> [gsm] block that has different values for sim-operator-id, apn
> (and optional username, password and network-id).
> 
> I tried the multi-setup stuff, and it is much easier than I thought.
> So now I have 7 mobile profiles and NM is smart enough
> to get the correct one and connect on startup, without even needing
> nmcli device connect $MODEM
> 
> $ nmcli connection
> NAMEUUID  TYPE  D
> EVICE
> eth07f79871d-15ff-446a-b1c3-
> 5978c81c176b  ethernet  eth0
> eth15317eb97-1514-4852-b120-
> ab4fa9173350  ethernet  eth1
> mobile20404 ef48d247-00df-433a-bf6a-
> 97ad54e3b757  gsm   cdc-wdm0
> mobile21407 b9d37621-32c9-4073-8848-86dd8814f503  gsm   -
> -
>  4 similar lines 
> mobile2345073d473ad6-7a25-4130-bc61-c2e987bcfa2a  gsm   -
> -
> Wired connection 1  d82449b5-69e2-33c3-944d-c132881f9052  ethernet  -
> -
> 
> So... Now I just need a way to get the connection name. Is there a
> better way than
> nmcli c | awk '/cdc-wdm0/ {print $1}'
> ?
> 
> And I managed to make a case when none of the profiles connects (set
> gsm.network-id to a provider that isn't in range).
> Then it doesn't activate any profile, and it seems like there is no
> hope to start the modem.
> This is a feature our customers need, that instead of connecting to
> the IMSI of the sim card (like 21407), we prefer to roam with
> operator
> 12345.
> If that fails, fall back on normal roaming. Is that doable? Am I
> using
> gsm.network-id wrong?

network-id locks that connection to the given operator, and if the
modem cannot register with that network, then the connection will fail.
For example, if you are near a border and an international roaming
provider is stronger than your preferred network, and for whatever
reason your device always connects to the roaming provider and costs
you more. That kind of thing.

You could duplicate each connection and leave the network-id empty or
set to the SIM preferred operator. Then set the autoconnect priority of
that connection "worse" than the connection for the roaming operator.
NM should then try the roaming connection first, and if that fails fall
back to the non-roaming connection.

Does that work for you?

Dan

> > > > Note there is merge-request [1]. If that gets merged, the APN
> > > > settings
> > > > would be automatically read from the mobile-broadband-provider-
> > > > info
> > > > file. That should solve your issue in a different way.
> > > > 
> > > > [1]
> > > > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/98
> > > 
> > > That might work. If I can put my own apns and passwords in the
> > > mobile-broadband-provider-info file I'd get the same result.
> > > I guess I could just play around with the patches a bit.
> > > 
> > > > best,
> > > > Thomas
> > > 
> > > --
> > > Regards
> > > Einar Jón
> 
> 
> --
> Regards
> 
> 
> Einar Jón
> +31 610 957234
> ___
> 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: What to enter in the DCB tab for a PPPoE Internet connection

[Dan Williams via networkmanager-list]

On Thu, 2019-09-05 at 19:50 -0500, Mr. Christian Strubel via
networkmanager-list wrote:
> What do I need to enter in the DCB tab for Network Manager
> to work with a PPPoE Internet connection?

You shouldn't need to enter anything DCB ("Data Center Bridging") for
PPPoE actually. But really, I don't think you should see a DCB tab for
PPPoE since PPPoE is a different connection type than plain Ethernet.

If you're using nm-connection-editor you create a new connection with
the + button and then select "DSL/PPPoE" and you should get all the
right options.

Does that work for you?

Dan

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

Re: How to set network connection priority

[Dan Williams via networkmanager-list]

On Fri, 2019-07-26 at 21:52 +0530, Mohammed Sadiq wrote:
> Hi,
> 
> Is it possible to set IP routing (and DNS) priority when multiple
> network is present?  Say like, “Connection A” to have lower priority
> over every other connection, and “Connection B” having more priority
> than “Connection A”, but less priority than every other connection.
> So if there is ever a connection other than ‘A’ or ‘B’, that
> connection
> will be used for IP (and DNS) routing, otherwise “Connection B” will
> be
> used, and otherwise, “Connection A.”

The ipv4 setting for each connection has a "dns-priority" property that
you can use to set a given connection's DNS servers as lower priority.
It also has a "route-metric" property that will do the same for routes
(but has a different scale based on kernel routing metrics).

man nm-settings

has a lot of info about these values.

nmcli con mod "my connection name" ipv4.dns-priority X

By default every connection gets the same priority (0). The larger the
number, the less-preferred the connection. So in your example, you
could set:

nmcli con mod "Connection A" ipv4.dns-priority 10 ipv4.route-metric 1050
nmcli con mod "Connection B" ipv4.dns-priority 5 ipv4.route-metric 1040

And that may do what you want.

Dan

> I'm wring a C code (that will hopefully be into gnome-control-
> center),
> so I would be okay with solutions that are possible via code only, or
> just configuration changes for NMSetting.
> 
> 
> Thanks,
> Mohammed Sadiq
> ___
> 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: NetworkManager, ModemManager, and pppd

[Dan Williams via networkmanager-list]

On Thu, 2019-03-14 at 16:52 +1300, Harry Mander via networkmanager-list 
wrote:
> Hi,
> 
> I have a PPP connection brought up by pppd running on a ttyUSB
> connection
> to an LTE modem, which is managed by ModemManager. When pppd is
> started
> after simple-connecting the modem using ModemManager it is able to
> get an
> IP address fine (which can be seen from ifconfig and ip route etc.)
> and I
> can connect to the network using the modem. However, nmcli shows the
> ppp0
> connection as disconnected.

When used in combination with ModemManager, NetworkManager handles PPP
through a pppd plugin. MM itself does not do any IP configuration, that
is left to a connection manager like NetworkManager since IP config
(and routing, and DNS, etc) is pretty complicated and MM shouldn't re-
invent that wheel.

So, typically you run MM and NM at the same time, and NM will see the
modem and allow you to 'nmcli con up ' and NM will
handle talking to MM and then the IP configuration.

What you're probably missing is the NetowrkManager "WWAN" plugin. I see
below you have the ADSL, OVS, and WiFi plugins. But you should also
have a WWAN plugin in the same directory.

That's likely a build-time problem. NM must be built with the --with-
modem-manager-1 flag. It should also be built with the --with-pppd flag
so it knows where to put the pppd plugin that it uses.

But that brings up the question, why is your modem using PPP at all?
Typically LTE-capable devices use a pseudo-ethernet device or a netdev
that just does IP ("raw-ip"). PPP is typically not used as it limits
network speeds due to its overhead. I'd expect your device to use
something like QMI, MBIM, or a CDC-NCM port for data instead of PPP.

Dan

> How can I configure NetworkManager to see the PPP connection
> properly? Is
> it possibly related to the pppd plugin since we have libnm-ppp-
> plugin.so
> present in /usr/lib/NetworkManager/1.14.4 but the log does not show
> any
> pppd plugin being loaded:
> 
> > NetworkManager[285]:   [1552534718.0779] Loaded device
> > plugin:
> > NMAtmManager (/usr/lib/NetworkManager/1.14.4/libnm-device-plugin-
> > adsl.so)
> > NetworkManager[285]:   [1552534718.1004] Loaded device
> > plugin:
> > NMOvsFactory (/usr/lib/NetworkManager/1.14.4/libnm-device-plugin-
> > ovs.so)
> > NetworkManager[285]:   [1552534718.1181] Loaded device
> > plugin:
> > NMWifiFactory (/usr/lib/NetworkManager/1.14.4/libnm-device-plugin-
> > wifi.so)
> 
> This is running on an iMX7 based board using Yocto. I have added
> 
> > --enable-ppp=yes
> > --with-pppd-plugin-dir=${libdir}/pppd/2.4.5
> 
> to the networkmanager recipe file.
> ___
> 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: ipv6 RA: dhcp-level managed

[Dan Williams via networkmanager-list]

On Fri, 2019-01-04 at 12:00 -0500, Brian J. Murrell wrote:
> On Fri, 2019-01-04 at 09:52 -0600, Dan Williams via networkmanager-
> list 
> wrote:
> > While NM was running, is it possible there was a previous RA that
> > had
> > "stateful other conf" (eg the M/managed flag) set?
> 
> Possibly.
> 
> > To avoid ping-pong
> > with RA changes or multiple router advertisements from different
> > routers NM will cache the "most managed" level.
> 
> So that's a restart NM and see if it stops starting dhclient then?

Yeah.

Dan

> Cheers,
> b.
> 
> ___
> 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: ipv6 RA: dhcp-level managed

[Dan Williams via networkmanager-list]

On Fri, 2019-01-04 at 07:19 -0500, Brian J. Murrell wrote:
> I see the following message in the debug for NM:
> 
> Jan 04 07:02:19 server NetworkManager[1138]: 
> [1546603339.8846] ndisc[0x5592e10188c0,"enp2s0"]:   dhcp-level
> managed

You're not mistaken about the interpretation of those fields, but...

While NM was running, is it possible there was a previous RA that had
"stateful other conf" (eg the M/managed flag) set? To avoid ping-pong
with RA changes or multiple router advertisements from different
routers NM will cache the "most managed" level.

Dan

> Which I presume is what leads to:
> 
>  1138 ?Ssl   16:39 /usr/sbin/NetworkManager --no-daemon
> 26196 ?S  0:00  \_ /sbin/dhclient -d -q -6 -N -sf
> /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient6-enp2s0.pid -lf
> /var/lib/NetworkManager/dhclient6-90f5409c-bd23-48f
> 
> But what in the following RA contents:
> 
> Soliciting ff02::2 (ff02::2) on pc_bridge...
> 
> Hop limit :   64 (  0x40)
> Stateful address conf.:   No
> Stateful other conf.  :   No
> Mobile home agent :   No
> Router preference :   medium
> Neighbor discovery proxy  :   No
> Router lifetime   : 1800 (0x0708) seconds
> Reachable time:  unspecified (0x)
> Retransmit time   :  unspecified (0x)
>  Source link-layer address: D4:6E:0E:64:62:B6
>  MTU  : 1500 bytes (valid)
>  Prefix   : 2001:1234:525e:a700::/64
>   On-link :  Yes
>   Autonomous address conf.:  Yes
>   Valid time  :81098 (0x00013cca) seconds
>   Pref. time  :37898 (0x940a) seconds
>  Route: 2001:456:1d:6f8::/64
>   Route preference:   medium
>   Route lifetime  : infinite (0x)
>  Route: 2607:1234:f00f:cd00::/56
>   Route preference:   medium
>   Route lifetime  :81173 (0x00013d15) seconds
>  Route: 2001:1234:525e:a700::/56
>   Route preference:   medium
>   Route lifetime  :81098 (0x00013cca) seconds
>  Route: fd31:aeb1:48df::/48
>   Route preference:   medium
>   Route lifetime  : infinite (0x)
>  Recursive DNS server : fd31:aeb1:48df::2
>   DNS server lifetime : 6000 (0x1770) seconds
>  from fe80::d66e:eff:fe64:62b6
> 
> is leading NM to believe that it should be running dhclient?  AFAIK,
> I
> have configured this subnet to be autoconfiguration only, which I
> suspect is what the "Stateful * conf. : No" is, but I could very well
> be mistaken about the interpretation of those fields.
> 
> Cheers,
> b.
> 
> ___
> 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: u-blox R410M modem (QMI) configuration with modern Network-manager

[Dan Williams via networkmanager-list]

On Fri, 2018-11-30 at 11:24 -0800, Tim Harvey wrote:
> On Fri, Nov 30, 2018 at 3:12 AM Aleksander Morgado
>  wrote:
> > Hey,
> > 
> > > I'm trying to use a u-blox QMI R410M with network manager on
> > > Ubuntu
> > > bionic witht he following which works fine on Ubuntu xenial:
> > > 
> > > # nmcli connection add type gsm ifname cdc-wdm0 con-name mymodem
> > > apn $APN
> > > # nmcli connection up id mymodem
> > > 
> > > The modem's QMI interface is indeed /dev/cdc-wdm0, my APN is
> > > correct,
> > > and I can connect just fine using mmcli or qmicli directly.
> > > 
> > > On Xenial with network-manager-1.2.6 this works fine but on
> > > Bionic
> > > with network-manager-1.10.6 this results in 'Error: Connection
> > > activation failed: No suitable device found for this
> > > connection.'.
> > > 
> > > I'm thinking the connection configuration syntax has likely
> > > changed
> > > I'm I'm simply using the wrong syntax?
> > > 
> > > Note that I'm using libqmi-1.20.2 and modemmanager-1.8.2 from
> > > Aleksander's Ubuntu PPA's in both cases.
> > > 
> > 
> > I'm not totally sure what might have changed in NM, but have you
> > tried
> > creating the connection *without ifname*?
> > You can have "gsm" connection settings not bound any interface, NM
> > will try to find a suitable device when connecting.
> > 
> 
> hmm... I wonder if that's not available until a newer version of NM?
> 
> root@bionic-newport:~# nmcli --version
> nmcli tool, version 1.10.6
> root@bionic-newport:~# nmcli connection add type gsm con-name mymodem
> apn $APN
> Error: 'ifname' argument is required.

Yeah, that's a bug in nmcli:

https://bugzilla.gnome.org/show_bug.cgi?id=780323

I think you can delete the ifname after you create the connection
though.

> I've always thought the 'gsm' and 'cdma' types are a bit outdated for
> modern LTE modems but it looks like that is what your supposed to
> continue using according to the NM docs.

These days "gsm" means any GSM, UMTS, and LTE provider, even if the LTE
provider still runs a CDMA network. The modem hides the details of CDMA
for you. We may be able to deprecate it in a few years when most of the
CDMA/EVDO networks are shut down.

The NM distinction for cdma & gsm existed before LTE was a thing, and
NM values backwards compatibility, so it's still there.

> I wonder if there is something wrong with NM here as it doesn't even
> seem to be even managing my wired connections:

IIRC on Ubuntu (and perhaps Debian?) if you have anything in
/etc/network/interfaces, then the distro configures NM to ignore those
interfaces.  I think if you remove anything related to eth0 from /e/n/i
then NM will be able to manage them.

Dan

> root@bionic-newport:~# ifconfig
> eth0: flags=4163  mtu 1500
> inet 172.24.25.23  netmask 255.240.0.0  broadcast
> 172.24.255.255
> inet6 fe80::2d0:12ff:fe0f:f583  prefixlen 64  scopeid
> 0x20
> ether 00:d0:12:0f:f5:83  txqueuelen 1000  (Ethernet)
> RX packets 66096  bytes 18460509 (18.4 MB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 3726  bytes 299073 (299.0 KB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1000  (Local Loopback)
> RX packets 58  bytes 5562 (5.5 KB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 58  bytes 5562 (5.5 KB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> root@bionic-newport:~# cat /etc/network/interfaces
> # ifupdown has been replaced by netplan(5) on this system.  See
> # /etc/netplan for current configuration.
> # To re-enable ifupdown on this system, you can run:
> #sudo apt install ifupdown
> allow-hotplug eth0
> auto eth0
> iface eth0 inet dhcp
> 
> root@bionic-newport:~# nmcli device status
> DEVICETYPE  STATE  CONNECTION
> can0  can   unmanaged  --
> eth0  ethernet  unmanaged  --
> eth1  ethernet  unmanaged  --
> eth2  ethernet  unmanaged  --
> eth3  ethernet  unmanaged  --
> eth4  ethernet  unmanaged  --
> loloopback  unmanaged  --
> cdc-wdm0  modem unmanaged  --
> 
> Instead on xenial I get:
> root@xenial-newport:~# nmcli --version
> nmcli tool, version 1.2.6
> root@xenial-newport:~# nmcli device status
> DEVICETYPE  STATE CONNECTION
> eth4  ethernet  connected Wired connection 1
> cdc-wdm0  modem disconnected  --
> eth1  ethernet  unavailable   --
> eth2  ethernet  unavailable   --
> eth3  ethernet  unavailable   --
> can0  can   unmanaged --
> eth0  ethernet  unmanaged --
> loloopback  unmanaged --
> 
> By the way, thank you again for your modemmanager PPA's, they are
> doing wonders for us ARM/ARM64 users!
> 
> Regards,
> 
> Tim
> ___
> networkmanager-list mailing list
> 

Re: D-Bus: Getting secrets through dbus-send

[Dan Williams via networkmanager-list]

On Mon, 2018-11-26 at 09:49 +0100, Damien Cassou wrote:
> Hi,
> 
> I want to better integrate NetworkManager with Emacs: I want an Emacs
> interface to start/stop connections, to see which
> devices/connections/access-points are available. I also want Emacs to
> present an interface when NetworkManager needs a password.
> 
> For that, I'm trying to implement a D-Bus SecretAgent for
> NetworkManager. To test that it is working, I'm using dbus-send, but
> this fails:
> 
> $ dbus-send --print-reply --system --
> dest=org.freedesktop.NetworkManager
> /org/freedesktop/NetworkManager/Settings/57
> org.freedesktop.NetworkManager.Connection.GetSecrets array:string:
> Error org.freedesktop.DBus.Error.AccessDenied: Rejected send message,
> 2 matched rules; type="method_call", sender=":1.4263" (uid=1000
> pid=20511 comm="/usr/bin/dbus-send --print-reply --system --dest=o"
> label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")
> interface="org.freedesktop.NetworkManager.Connection"
> member="GetSecrets" error name="(unset)" requested_reply="0"
> destination="org.freedesktop.NetworkManager" (uid=0 pid=1431
> comm="/usr/sbin/NetworkManager --no-daemon "
> label="system_u:system_r:NetworkManager_t:s0")
> 
> What does it mean please?

It's D-Bus saying that the request wasn't correct.  Let's assume first
that you're using NM 1.0 or later. Two problems:

1) The interface + method should be:

org.freedesktop.NetworkManager.Settings.Connection.GetSecrets

note the ".Settings" in there. See:

https://developer.gnome.org/NetworkManager/unstable/gdbus-org.freedesktop.NetworkManager.Settings.Connection.html

2) the arguments you want to pass should be:

string:

not "array:string:". In the link above, anything that is an "IN"
argument should be an arg you pass. Here the method defines its
arguments as "IN s setting_name" which means it's a string argument.

The  is the name of the setting for which you'd like to
get secrets, like "802-11-wireless-security" or "802-1x". Yes, you may
need a bit of logic to figure out which setting to pass, but there
aren't too many.  You can use the type name (eg the connection.type
field) for  except for WiFi and wired 802.1x. If an 802-
1x setting exists for the connection, then just ask for 802-1x secrets.
If not and it's WiFi, then ask for 802-11-wireless-security.  That
should be it for the usual special-cases.

So with these changes you'll get something like:

$ sudo dbus-send --print-reply --system \
  --dest=org.freedesktop.NetworkManager \
  /org/freedesktop/NetworkManager/Settings/57 \
  org.freedesktop.NetworkManager.Settings.Connection.GetSecrets \
  string:802-11-wireless-security
method return time=1543262087.143600 sender=:1.14 ->
destination=:1.7075 serial=410592 reply_serial=2
   array [
  dict entry(
 string "ipv4"
 array [
 ]
  )
  dict entry(
 string "connection"
 array [
 ]
  )
  dict entry(
 string "802-11-wireless-security"
 array [
dict entry(
   string "psk"
   variant   string "mypassword333"
)
 ]
  )
  dict entry(
 string "ipv6"
 array [
 ]
  )
  dict entry(
 string "802-11-wireless"
 array [
 ]
  )
  dict entry(
 string "proxy"
 array [
 ]
  )
   ]

Dan

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

Re: wifi permanently switching between 2.4 and 5 GHz

[Dan Williams via networkmanager-list]

On Sat, 2018-11-24 at 11:06 +0100, Shawn Adams wrote:
> Dan,
> 
> I wanted to ask more details about this statement, I'd like to
> understand more:
> 
> > It uses a combination of RSSI and expected throughput of the AP
> > based
> > on advertised capabilities and channel widths (eg HT, VHT,
> > etc).  I'm
> > not saying that wpa_supplicant is perfect, and I've personally
> > patched
> > it in the past to roam less frequently.
> 
> The RSSI portion is clear,  accounting for expected throughput is
> what
> id' like to understand more of:
> 
> Is this solely based on beacon/probe responses and the theoretic
> maximum
> TX/RX rates achievable

The supplicant estimates each SSID's AP's throughput based on the
advertised rates and HT/VHT information versus the SNR/RSSI for that
AP.

See scan_est_throughput() in wpa_supplicant's scan.c for the estimated
throughput calculations.

When deciding to roam or not between APs of the same SSID, that
estimated throughput is used in conjunction with signal level.

See wpa_supplicant_need_to_roam() in events.c for the comparison when
deciding to roam or not.  Start with the line:

if (selected->est_throughput > current_bss->est_throughput + 5000) {

and everything below that is relevant.

> on the advertising BSSID ?  or is there actual channel measurement,
> IE
> Load taken into account ?

Yes, actual channel measurement (RSSI of the scan result and noise of
the channel, if the driver reports it) is factored into the
calculations.

Dan

> 
> Best Regards,
> 
> Shawn Adams
> 
> 
> On 15.08.18 23:17, Dan Williams via networkmanager-list wrote:
> > On Wed, 2018-08-15 at 13:21 -0700, Michael Butash wrote:
> > > > On Wed, Aug 15, 2018 at 9:36 AM, Dan Williams via
> > > > networkmanager-
> > > > list <
> > > networkmanager-list@gnome.org> wrote
> > > > Does the switching cause an actual problem?  It's supposed to
> > > > happen
> > > > very quickly, within a couple 10s of ms.
> > > I have run into like roaming/band-selection issues with linux
> > > around
> > > various wireless environments for some time, pretty much any time
> > > I've has
> > > 2.4ghz and 5ghz co-existence on the same ssid's.  I seem to
> > > remember
> > > the
> > > few times I've gone to look into it, there was no granular way to
> > > control
> > > 2.4/5ghz either with iwconfig, wpa_supplicant, or nm, other than
> > > mentioned
> > > static bssid, which is messy when you have more than one ap
> > > around in
> > > high-density deployments.  It seems it's just far too hair-
> > > trigger to
> > > flip
> > > between AP's, and even enabling band-steering features on
> > > enterprise
> > > ap/controller side doesn't really seem to help influence which
> > > band a
> > > linux
> > > system will end up using.  I'm presuming it chooses generally the
> > > best
> > > rssi, which 2.4 will probably always win, and often I'll get my
> > > systems
> > > just refusing to use a 5ghz in places when available.
> > It uses a combination of RSSI and expected throughput of the AP
> > based
> > on advertised capabilities and channel widths (eg HT, VHT,
> > etc).  I'm
> > not saying that wpa_supplicant is perfect, and I've personally
> > patched
> > it in the past to roam less frequently.
> > 
> > What I am saying is that we were I to diagnose this issue, I don't
> > have
> > enough information to blame the roaming algorithm.  What are the
> > actual
> > issues?
> > 
> > When it roams, does a video you are watching suddenly downgrade
> > from
> > 1080p to HD?
> > 
> > When it roams, does the connection completely break and you get a
> > new
> > IP address and all your SSH sessions die?  Do downloads die?
> > 
> > When it roams, does your Skype call stall for a second before
> > recovering?  Or does it hiccup your FPS game and you die?
> > 
> > If the answer to those questions is "yes" then we have something to
> > work with and we can figure out whether the roaming is the cause of
> > them. Just saying "I want to be on 5GHz and it's not on 5GHz" isn't
> > a
> > necessarily a problem, because there are many factors in play and
> > 5GHz
> > is just one of those factors.
> > 
> > I hope that explains my questions better.  Again, I'm not saying
> > that
> > wpa_supplicant's roaming is perfect.  But its roaming algorithm has
> > been basically 

Re: why does network manager start activating disconnected ethernet ports?

[Dan Williams via networkmanager-list]

On Sat, 2018-11-10 at 13:54 -0500, David P. Reed wrote:
> Dan - thanks! Yes, the ports were in LOWER_UP, now that I understand
> what that means.
>  
> It is not a Network Manager problem. It was a real screwup on my
> part. Sorry to waste your time.

No problem, glad it got figured out!

Dan

> For some reason two of the ports were actually cabled to a switch
> that was otherwise unused (not connecting anywhere). It was supposed
> to be powered off, but it turns out that someone (not me, that I know
> of) turned it on.  That brought the links up, but there was no DHCP
> server reachable.
>  
> Again, thanks for the help with my troubleshooting.
>  
> I do like NM a lot, and appreciate your effort put in to continue
> improving and supporting it.
>  
> David
> -Original Message-
> From: "Dan Williams" 
> Sent: Thursday, November 8, 2018 5:35pm
> To: "David P. Reed" 
> Cc: networkmanager-list@gnome.org
> Subject: Re: why does network manager start activating disconnected
> ethernet ports?
> 
> 
> 
> On Thu, 2018-11-08 at 16:16 -0500, David P. Reed wrote:
> > Hi Dan -
> > I tried the rpm -e command and it said I don't have that module
> > installed. I did grep the directories (/var/run/NetworkManager and
> > /etc/NetworkManager) recursively for the string "carrier" and found
> > nothing there. So that seems not to be the problem.
> > 
> > It's clear from the journalctl log entries that the two non-
> > connected 
> > interfaces are being "auto-activated" over and over by something.
> > They move from prepare->config->ip-config.
> > Reason is "none", but I think that's normally what goes on.
> > 
> > One personal theory (that I don't know how to test properly) is
> > that
> > the RealTek r8169 driver (which seems to have been demonstrating
> > problems on Ubuntu in the past few months, on some hardware) is
> > somehow saying the ports are coming online or are online when they
> > are not. I'm not sure how NetworkManager gets told about such
> > transitions, but it might be a problem. I also wonder about chrony
> > somehow trying to probe the interfaces, triggering them by
> > accident.
> 
> NetworkManager listens to kernel messages from the driver. Run "ip
> link show dev " which should look similar to this:
> 
> 2: enp0s31f6:  mtu 1500
> qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
>  link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
> 
> if you see LOWER_UP that means the kernel driver thinks there is a
> carrier/link. At that point it's a kernel driver bug if nothing is
> plugged into the card's port.
> 
> If it doesn't show LOWER_UP, then it's probably some configuration
> issue or bug in NM itself.
> 
> Dan
> 
> > Is there a "no-ignore-carrier" option that would be something to
> > try
> > for debugging? or some specific logging option that will tell more
> > about why these ports are "auto-activating"?
> > 
> > I have several other Fedora 28 machines running similar
> > configurations, but they don't seem to do this. They are different,
> > in that their Ethernet hardware is different, but the software
> > setup
> > is roughly similar.
> > 
> > Anyway, I'd love to figure this out. I can share the journals if
> > you
> > want or get other data, but this level of logging doesn't say very
> > much to me other than what I summarize above.
> > 
> > Thanks.
> > -Original Message-
> > From: "Dan Williams" 
> > Sent: Wednesday, November 7, 2018 5:55pm
> > To: "David P. Reed" , networkmanager-list@gnom
> > e.
> > org
> > Subject: Re: why does network manager start activating disconnected
> > ethernet ports?
> > 
> > 
> > 
> > On Wed, 2018-11-07 at 16:23 -0500, David P. Reed wrote:
> > > I have a Fedora 28 server in my lab that has multiple network
> > > adapters, but only one of them is cabled to a switch. All the
> > > software is updated to NetworkManager-1.10.12-1.fc28.
> > 
> > Did you install the Fedora 28 "Server" spin, or something like
> > Workstation? Some of the config options are different for different
> > variants. That includes installing the "00-server.conf" file into
> > /etc/NetworkManager/conf.d for Server installs in some cases.
> > 
> > One thing that does is set "ignore-carrier=*" which, as you may
> > guess,
> > makes NM ignore the carrier detection of the NIC on all interfaces.
> > Mostly for servers with sta

Re: sierra modem connected through serial port not working

[Dan Williams via networkmanager-list]

On Mon, 2018-11-05 at 21:11 -0600, linux.challenge1 via networkmanager-
list wrote:
> We are using Modem manager 1.8.2. We are trying to connect sierra
> modem via
> serial port ttyS0. We modified /lib/udev/rules.d/77-mm-sierra.rules
> to

Are you really using ttyS0?  That's usually an onboard RS232 serial
port, while most devices these days tend to be USB-based.

But perhaps you have one of the IoT/embedded devices and you're using
the UART connection?

Can you share which specific Sierra device this is?

Dan

> ACTION!="add|change|move|bind", GOTO="mm_sierra_end"
> SUBSYSTEMS=="tty", GOTO="mm_sierra"
> GOTO="mm_sierra_end" 
> 
> LABEL="mm_sierra"
> 
> ACTION=="add", KERNEL=="ttyS0", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"
> 
> LABEL="mm_sierra_end"
> 
> But when we load we get following logs
> 
> syslog[4989]:  [1541472622.239884] (Sierra) [ttyS0] filtered
> as
> couldn't retrieve drivers
> syslog[4989]:  [1541472622.240072] [plugin manager] task
> 0,ttyS0:
> found '0' plugins to try
> syslog[4989]:  [1541472622.240265] [plugin manager) task
> 0,ttyS0:
> started
> syslog[4989]:  [1541472622.240424] [plugin manager] task
> 0,ttyS0:
> finished in '1.498676' seconds
> syslog[4989]:  [1541472622.240912] [plugin manager] task
> 0,ttyS0: not
> supported by any plugin
> 
> and sierra plugin is not loaded. Any help?
> 
> 
> 
> --
> Sent from: http://gnome-networkmanager.2324886.n4.nabble.com/
> ___
> 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: why does network manager start activating disconnected ethernet ports?

[Dan Williams via networkmanager-list]

On Thu, 2018-11-08 at 16:16 -0500, David P. Reed wrote:
> Hi Dan -
> I tried the rpm -e command and it said I don't have that module
> installed. I did grep the directories (/var/run/NetworkManager and
> /etc/NetworkManager) recursively for the string "carrier" and found
> nothing there. So that seems not to be the problem.
>  
> It's clear from the journalctl log entries that the two non-connected 
> interfaces are being "auto-activated" over and over by something.
> They move from prepare->config->ip-config.
> Reason is "none", but I think that's normally what goes on.
>  
> One personal theory (that I don't know how to test properly) is that
> the RealTek r8169 driver (which seems to have been demonstrating
> problems on Ubuntu in the past few months, on some hardware) is
> somehow saying the ports are coming online or are online when they
> are not. I'm not sure how NetworkManager gets told about such
> transitions, but it might be a problem. I also wonder about chrony
> somehow trying to probe the interfaces, triggering them by accident.

NetworkManager listens to kernel messages from the driver.  Run "ip
link show dev " which should look similar to this:

2: enp0s31f6:  mtu 1500
qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff

if you see LOWER_UP that means the kernel driver thinks there is a
carrier/link.  At that point it's a kernel driver bug if nothing is
plugged into the card's port.

If it doesn't show LOWER_UP, then it's probably some configuration
issue or bug in NM itself.

Dan

> Is there a "no-ignore-carrier" option that would be something to try
> for debugging? or some specific logging option that will tell more
> about why these ports are "auto-activating"?
>  
> I have several other Fedora 28 machines running similar
> configurations, but they don't seem to do this. They are different,
> in that their Ethernet hardware is different, but the software setup
> is roughly similar.
>  
> Anyway, I'd love to figure this out. I can share the journals if you
> want or get other data, but this level of logging doesn't say very
> much to me other than what I summarize above.
>  
> Thanks.
> -Original Message-
> From: "Dan Williams" 
> Sent: Wednesday, November 7, 2018 5:55pm
> To: "David P. Reed" , networkmanager-list@gnome.
> org
> Subject: Re: why does network manager start activating disconnected
> ethernet ports?
> 
> 
> 
> On Wed, 2018-11-07 at 16:23 -0500, David P. Reed wrote:
> > I have a Fedora 28 server in my lab that has multiple network
> > adapters, but only one of them is cabled to a switch. All the
> > software is updated to NetworkManager-1.10.12-1.fc28.
> 
> Did you install the Fedora 28 "Server" spin, or something like
> Workstation? Some of the config options are different for different
> variants. That includes installing the "00-server.conf" file into
> /etc/NetworkManager/conf.d for Server installs in some cases.
> 
> One thing that does is set "ignore-carrier=*" which, as you may
> guess,
> makes NM ignore the carrier detection of the NIC on all interfaces.
> Mostly for servers with static IPs where connectivity shouldn't
> change
> even if you unplug or trip over the cable.
> 
> Try 'rpm -e NetworkManager-config-server' and then restarting NM or
> rebooting and see if that fixes it.
> 
> Dan
> 
> > However, when I run journalctl -e I typically see pages and pages
> > and
> > pages of DHCPDISCOVER requests on the non-connected ports,
> > constantly
> > retrying. The logs fill very, very fast.
> > 
> > I did something yesterday that managed to cause the retrying to
> > stop,
> > leaving the unused ports all in the disconnected state (nmcli
> > device
> > status said disconnected for each one). I thought, hmm... well that
> > problem is now fixed. `journalctl -e` showed everything quiet.
> > 
> > Today, I thought I'd check. When I did `journalctl -e` there were
> > no
> > DHCPDISCOVERs issued, and when I did `nmcli device status` the
> > ports
> > were all still "disconnected".
> > 
> > But then I did `nmcli con show`. It said the ports were in a
> > disconnected state.
> > 
> > However at this point I happened to repeat the `journalctl -e`
> > command, and my goodness - the stream of DHCPDISCOVER requests
> > timing
> > out were a sight to amaze, and the network manager kept
> > transitioning
> > the state of the ports that had no cables correspondingly, trying
> > to
> > get an IP address.
> >

Re: [RFC] Automatically remove stored SIM-PIN from gsm connection settings if it fails to unlock?

[Dan Williams via networkmanager-list]

On Mon, 2018-10-08 at 11:45 +0200, Thomas Haller via networkmanager-
list wrote:
> On Mon, 2018-10-08 at 09:24 +0200, Aleksander Morgado wrote:
> > Hey,
> > 
> > I've SIM-PIN blocked one of my SIM cards just by having a gsm
> > autoconnected settings with a PIN stored and then PIN not matching
> > the
> > one in the device. When this happens, NM will try to unlock SIM-PIN
> > once, and if it fails it won't try again (good) (*)... until the
> > next
> > reboot (bad). So, I forgot about this setup and after just a couple
> > of
> > system reboots got the SIM-PIN blocked, and had to recover it with
> > the
> > PUK.
> > 
> > Don't know if this kind of thing is done in other kinds of
> > settings,
> > but could we completely remove the SIM-PIN stored within the
> > settings
> > if it fails once, so that not even on the next reboot the unlock
> > with
> > the wrong PIN is attempted? Or is this considered a user error? I'm
> > not exactly sure where to draw the line about this issue, I think I
> > have pros and cons for both solutions, so just opening the question
> > here.
> > 
> > What do you think?
> > 
> > (*) It also doesn't re-ask the user for the PIN right away, still
> > need
> > to get trace logs as thaller suggested.
> 
> Hi,
> 
> That sounds good to me.
> 
> it's slightly ugly, that activating a profile may result in writing
> it
> anew to disk. But we already do that when (for example with Wi-Fi),
> when the password is wrong and we get a better password from the
> secret
> agent. While a bit odd that activating a profile may re-write it, it
> probably makes sense.

+1

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

Re: No new PIN request to the user if PIN stored in settings is wrong

[Dan Williams via networkmanager-list]

On Thu, 2018-09-27 at 12:22 +0200, Thomas Haller via networkmanager-
list wrote:
> On Thu, 2018-09-27 at 11:51 +0200, Aleksander Morgado wrote:
> > Hey,
> > 
> > I'm trying to understand whether this behavior is on purpose or
> > not.
> > 
> > I have some "gsm" settings for a broadband connection, and the
> > settings have a PIN stored. I then try to use those settings on a
> > modem device but the expected PIN in the modem is a different one,
> > so
> > the connection attempt fails with a "sim-pin-incorrect" reason. At
> > this point NetworkManager doesn't request the user new secrets for
> > this connection after finding that the stored ones are wrong; i.e.
> > i
> > don't see any popup window in the shell asking to enter PIN. The
> > connection attempt just fails and we do get reported in the UI
> > about
> > the failed attempt.
> > 
> > Is this behavior (asking the user for PIN after a "sim-pin-
> > incorrect"
> > failure) not implemented or am I missing some reason that would
> > prevent doing that? The behavior is different e.g. with WiFi; if I
> > change the key in my router and I request NM to connect to the WiFi
> > network, the authentication failure triggers a new request for
> > secrets
> > to the user.
> > 
> > Cheers!
> 
> 
> Hi,
> 
> 
> sounds like a bug. If a secret/pin is wrong, NM should re-ask for it.

We do have to be careful here, because by the time NM asks for the PIN,
we've already tried the stored PIN once, and if the user enters the
wrong pin in the dialog you have one try left before the PIN is
blocked.  And then you have to find your PUK which often isn't right
next to you.

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

Re: Scanning for infrastructure SSIDs during in active AP mode connection

[Dan Williams via networkmanager-list]

On Mon, 2018-10-01 at 18:54 +0200, Tobias Grasse | glancr wrote:
> Hello everyone,
> 
> is it possible to scan for nearby WiFi SSIDs (i.e. get “nmcli d wifi
> list” to output available networks) while network-manager has an
> active WiFi connection in AP mode?

It *highly* depends on the driver, and some drivers can do this without
dropping clients.  Many cannot because when when scanning the device is
off the AP channel for a given amount of time, and at any time
(including while the AP is off-channel) a client could try to talk to
the AP.

The Linux kernel has the NL80211_FEATURE_AP_SCAN flag that drivers set
to indicate they can support AP-mode scanning, but only the ath10k and
tiwlan drivers set this flag.

> My usecase: An IoT device creates a setup WiFi (nmcli connection with
> mode “ap”). During setup, the user enters the credentials for their
> home WiFi so that the device can close the AP and connect to the
> infrastructure network. 

For most drivers, this would likely cause the client to disconnect from
the setup AP since it may take multiple seconds for the setup AP to
connect to a WiFi network (including authentication and DHCP).

> I couldn’t find conclusive info in the manpages, a similar question
> on SO has no answers yet and when I try it out ( duh :-D ), “nmcli d
> wifi list” lists only the AP WiFi while the AP connection is active.
> Once I deactivate the AP connection, the command returns all nearby
> networks as expected. Just want to make sure that I’m not missing
> something. 

You're not.

> Unfortunately, I cannot assume that the device has two WiFi
> interfaces, and the one it has only supports simultaneous modes on
> the same channel. 

Yeah, that's the only way around it with many devices, is to have the
setup AP be on the same channel as the other AP you want to connect to,
and then the device doesn't have to jump to another channel.  But of
course you don't know that during setup so that doesn't work...

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

Re: [PATCH ModemManager] docs: mm_modem_get_sim is async

[Dan Williams via networkmanager-list]

On Mon, 2018-08-27 at 16:51 +0200, Guido Günther wrote:
> Signed-off-by: Guido Günther 
> ---
>  libmm-glib/mm-modem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Pushed to git master, thanks!

Dan

> diff --git a/libmm-glib/mm-modem.c b/libmm-glib/mm-modem.c
> index e29716be..80cb280b 100644
> --- a/libmm-glib/mm-modem.c
> +++ b/libmm-glib/mm-modem.c
> @@ -2876,7 +2876,7 @@ modem_get_sim_ready (GDBusConnection
> *connection,
>   * @callback: A #GAsyncReadyCallback to call when the request is
> satisfied or %NULL.
>   * @user_data: User data to pass to @callback.
>   *
> - * Synchronously gets the #MMSim object managed by this #MMModem.
> + * Asynchronously gets the #MMSim object managed by this #MMModem.
>   *
>   * When the operation is finished, @callback will be invoked in the
> thread-default
> main loop of the thread you are calling this method from.
>   * You can then call mm_modem_get_sim_finish() to get the result of
> the operation.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: wifi permanently switching between 2.4 and 5 GHz

[Dan Williams via networkmanager-list]

On Wed, 2018-08-15 at 13:21 -0700, Michael Butash wrote:
> > On Wed, Aug 15, 2018 at 9:36 AM, Dan Williams via networkmanager-
> > list <
> 
> networkmanager-list@gnome.org> wrote
> > 
> > Does the switching cause an actual problem?  It's supposed to
> > happen
> > very quickly, within a couple 10s of ms.
> 
> I have run into like roaming/band-selection issues with linux around
> various wireless environments for some time, pretty much any time
> I've has
> 2.4ghz and 5ghz co-existence on the same ssid's.  I seem to remember
> the
> few times I've gone to look into it, there was no granular way to
> control
> 2.4/5ghz either with iwconfig, wpa_supplicant, or nm, other than
> mentioned
> static bssid, which is messy when you have more than one ap around in
> high-density deployments.  It seems it's just far too hair-trigger to
> flip
> between AP's, and even enabling band-steering features on enterprise
> ap/controller side doesn't really seem to help influence which band a
> linux
> system will end up using.  I'm presuming it chooses generally the
> best
> rssi, which 2.4 will probably always win, and often I'll get my
> systems
> just refusing to use a 5ghz in places when available.

It uses a combination of RSSI and expected throughput of the AP based
on advertised capabilities and channel widths (eg HT, VHT, etc).  I'm
not saying that wpa_supplicant is perfect, and I've personally patched
it in the past to roam less frequently.

What I am saying is that we were I to diagnose this issue, I don't have
enough information to blame the roaming algorithm.  What are the actual
issues?

When it roams, does a video you are watching suddenly downgrade from
1080p to HD?

When it roams, does the connection completely break and you get a new
IP address and all your SSH sessions die?  Do downloads die?

When it roams, does your Skype call stall for a second before
recovering?  Or does it hiccup your FPS game and you die?

If the answer to those questions is "yes" then we have something to
work with and we can figure out whether the roaming is the cause of
them. Just saying "I want to be on 5GHz and it's not on 5GHz" isn't a
necessarily a problem, because there are many factors in play and 5GHz
is just one of those factors.

I hope that explains my questions better.  Again, I'm not saying that
wpa_supplicant's roaming is perfect.  But its roaming algorithm has
been basically the same for at least 4 or 5 years so it clearly works
well enough in many cases already.

Dan

> It would be nice to have a bit better local control over band
> selection,
> roaming sensitivity, and other client radio behaviors since there
> really is
> no native ccx-like support to control better these things in
> enterprise
> environments, and consumer multi-ap solutions like this samsung
> probably
> don't even properly offer any proper roaming support to control
> client
> behavior in the first place.
> 
> -mb
> 
> 
> On Wed, Aug 15, 2018 at 9:36 AM, Dan Williams via networkmanager-list 
> <
> networkmanager-list@gnome.org> wrote:
> 
> > On Tue, 2018-08-14 at 23:04 -0500, Greg Oliver via networkmanager-
> > list
> > wrote:
> > > On Tue, Aug 14, 2018 at 2:24 PM "Jürgen Bausa"  > > .de>
> > > wrote:
> > > 
> > > > I have a Xiaomi Air 12 Laptop (Intel Core m3-7Y30, Network
> > > > controller:
> > > > Intel Corporation Wireless 8260
> > > > (rev 3a)). I use debian Stretch (linux 4.9.0-7-amd64) with KDE
> > > > and
> > > > Network-Mananger (1.6.2-3).
> > 
> > This is behavior specific to wpa_supplicant and how it decides to
> > roam
> > between access points.  It attempts to roam to a BSSID within the
> > same
> > SSID that has a better speed/signal.  It is expected that it might
> > jump
> > between BSSIDs when conditions change.
> > 
> > Does the switching cause an actual problem?  It's supposed to
> > happen
> > very quickly, within a couple 10s of ms.
> > 
> > Dan
> > 
> > > > Until now, wifi worked fine. However, after I exchanged my
> > > > router
> > > > (which
> > > > had only 2.4 GHz) against a
> > > > newer model that has both 2.4 and 5 GHz (both frequencies with
> > > > the
> > > > same
> > > > ssid), I experienced the
> > > > following problem: The computer switches permanently between
> > > > both
> > > > frequencies. This happens approximately
> > > > every 2 minutes. In /var/log/messages I find the following:
> > > > 
> > > > Aug 12 14:45:12 lina kernel: 

Re: wifi permanently switching between 2.4 and 5 GHz

[Dan Williams via networkmanager-list]

On Tue, 2018-08-14 at 23:04 -0500, Greg Oliver via networkmanager-list
wrote:
> On Tue, Aug 14, 2018 at 2:24 PM "Jürgen Bausa" 
> wrote:
> 
> > I have a Xiaomi Air 12 Laptop (Intel Core m3-7Y30, Network
> > controller:
> > Intel Corporation Wireless 8260
> > (rev 3a)). I use debian Stretch (linux 4.9.0-7-amd64) with KDE and
> > Network-Mananger (1.6.2-3).
> 

This is behavior specific to wpa_supplicant and how it decides to roam
between access points.  It attempts to roam to a BSSID within the same
SSID that has a better speed/signal.  It is expected that it might jump
between BSSIDs when conditions change.

Does the switching cause an actual problem?  It's supposed to happen
very quickly, within a couple 10s of ms.

Dan

> > Until now, wifi worked fine. However, after I exchanged my router
> > (which
> > had only 2.4 GHz) against a
> > newer model that has both 2.4 and 5 GHz (both frequencies with the
> > same
> > ssid), I experienced the
> > following problem: The computer switches permanently between both
> > frequencies. This happens approximately
> > every 2 minutes. In /var/log/messages I find the following:
> > 
> > Aug 12 14:45:12 lina kernel: [ 2256.208621] wlp1s0: disconnect from
> > AP
> > xx:xx:xx:xx:xx:xx for new auth to yy:yy:yy:yy:yy:yy
> > Aug 12 14:45:12 lina kernel: [ 2256.213032] wlp1s0: authenticate
> > with
> > yy:yy:yy:yy:yy:yy
> > Aug 12 14:45:12 lina kernel: [ 2256.223163] wlp1s0: send auth to
> > yy:yy:yy:yy:yy:yy (try 1/3)
> > Aug 12 14:45:12 lina NetworkManager[564]:   [1534077912.6843]
> > device
> > (wlp1s0): supplicant interface state: completed -> authenticating
> > Aug 12 14:45:12 lina kernel: [ 2256.228342] wlp1s0: authenticated
> > Aug 12 14:45:12 lina kernel: [ 2256.229481] wlp1s0: associate with
> > yy:yy:yy:yy:yy:yy (try 1/3)
> > Aug 12 14:45:12 lina kernel: [ 2256.230627] wlp1s0: RX AssocResp
> > from
> > yy:yy:yy:yy:yy:yy (capab=0x11 status=0 aid=1)
> > Aug 12 14:45:12 lina kernel: [ 2256.231932] wlp1s0: associated
> > Aug 12 14:45:12 lina NetworkManager[564]:   [1534077912.6931]
> > device
> > (wlp1s0): supplicant interface state: authenticating -> associated
> > Aug 12 14:45:12 lina NetworkManager[564]:   [1534077912.7338]
> > device
> > (wlp1s0): supplicant interface state: associated -> 4-way handshake
> > Aug 12 14:45:12 lina NetworkManager[564]:   [1534077912.7414]
> > device
> > (wlp1s0): supplicant interface state: 4-way handshake -> completed
> > 
> > where xx:xx:xx:xx:xx:xx the MAC of 2.4 and yy:yy:yy:yy:yy:yy the
> > MAC of 5
> > GHz net is.
> > 
> > However, this happens not at all places in my house. Near the
> > router, 5
> > GHz is much stronger than 2.4 Ghz
> > and the system keeps th 5 GHz net. But in the living room, both
> > nets have
> > nearly the same strength and the
> > systems switches all the time.
> > 
> > I found a lot of description of exactly this problem, but no
> > solution on
> > the net. See e.g.
> > https://forum.manjaro.org/t/frequent-wifi-disconnect/12211
> > 
> > https://jeremyfelt.com/2017/01/02/things-i-learned-or-broke-while-t
> > rying-to-fix-my-wireless-in-ubuntu-16-10/
> > 
> > https://www.archybold.com/blog/post/intermittent-connectionhigh-pac
> > ket-loss-intel-wireless-driver-iwlwifi-ubuntu-linux-networkmanager
> > 
> > I think there should be some treshold that avoids switching between
> > nets
> > based on small fluctiations. But
> > where can I set this treshold. And is the switching caused by NM or
> > by the
> > driver? As the bugreports
> > mention different adapters, I think its not driver specific.
> > 
> > Any hints welcome.
> > 
> > juergen
> > 
> > This is a long time nuisance of mine with NM and wpa-supplicant in
> > Linux.
> 
> I just set the BSSID in NM to the MAC of the 5Ghz chip on the AP
> .  This also keeps it from scanning into 2.4 and causing 10 seconds
> drop
> outs.
> 
> Unfortunately, I do not think a better way exists in Linux, which is
> unfortunate for us desktop users.  IMO, it is a major flaw that needs
> to be
> reworked ground up - it only happens on Linux (compared to MacOS and
> Windows on the same AP anyway - I have never run *BSD variants on a
> desktop
> machine).
> 
> 
> -
> Greg
> ___
> 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: Problems with modems/Example config for QMI-based modem,

[Dan Williams]

On Tue, 2018-03-06 at 12:01 +0100, Jakob Hasse wrote:
> Hello Dan, thanks for the answer.
> 
> On 28.02.2018 22:38, Dan Williams wrote:
> > On Wed, 2018-02-28 at 18:40 +0100, Jakob Hasse wrote:
> > > Hello,
> > > 
> > > We want to integrate different modems into our embedded system.
> > > Recently, our Linux-distributor decided to introduce
> > > NetworkManager.
> > > When we switch to NetworkManager, network connectivity via 3G/2G
> > > is
> > > never reliable: the connection either succeeds only sporadically
> > > or
> > > not
> > > at all. This happens on three types of modems from two different
> > > vendors. When we set up the modems manually with pppd or with a
> > > QMI
> > > test
> > > program, everything works fine an reliably, also automatically
> > > after
> > > boot.
> > > Could you give me advice what steps to do to produce debug/log
> > > output
> > > to
> > > then come back here and have someone look at it?
> > 
> > You want to increase the NetworkManager and ModemManager logging
> > level:
> > 
> > nmcli g log level debug
> > mmcli -G debug
> > 
> > and then plug your modem in.  This will dump debug logging to
> > whatever
> > system log service your linux distro uses.  For systemd-based
> > distros,
> > you want:
> > 
> > journalctl -b -u NetworkManager
> > journalctl -b -u ModemManager
> > 
> > other distros will use /var/log/messages, /var/log/daemon.log, or
> > wherever else syslog 'daemon' facility output goes.
> > 
> > > Furthermore, it would be really nice to have an example
> > > configuration
> > > file for /etc/NetworkManager/system-connections/ to configure a
> > > modem
> > > with QMI connection. All the examples I had so far (seem to) only
> > > establish the connection with pppd.
> > 
> > There should be no difference between a QMI or MBIM based modem and
> > a
> > PPP based one.  The only options you really need are the APN and
> > possibly the username and password in the [gsm] section.
> > 
> > Since your email address is ".ch" I'm going to assume you don't
> > care
> > about CDMA/EVDO and thus you only need to use [gsm].  The simplest
> > connection would be something like:
> > 
> > [connection]
> > id=T-Mobile Internet
> > uuid=0083942e-b260-4b73-a1fd-860f3e6ca2c2
> > type=gsm
> > 
> > [gsm]
> > apn=epc.tmobile.com
> > number=*99#
> > 
> > Again, there should be no difference between QMI and PPP-based
> > modems
> > from a NetworkManager perspective.  ModemManager abstracts that
> > away
> > for us.
> 
> I attached the log of a successful run and an unsuccessful run. 
> NetworkManager was successful with a Telit UE-910-UED (3G) and 
> unsuccessful with a Quectel BG96 (LTE Cat M1/2G). In the latter
> case, 
> the modem was registered in the network, according to he Manual and
> the 
> LED feedback. ModemManager recognized the modem as it printed me
> output 

The call for the Quectel is failing due to:

eQMIWDSCallManagerCallEndReasons_InvalidSIMState

which suggests something wrong with the SIM.  Does the same SIM work in
another device?

I do wonder about these errors:

Mar  6 08:26:31 ccimx6uluvalue daemon.warn ModemManager[775]:   couldn't 
load SIM identifier: 'Couldn't get UIM ICCID: QMI protocol error (94): 
'NotSupported''
Mar  6 08:26:31 ccimx6uluvalue daemon.warn ModemManager[775]:   couldn't 
load IMSI: 'Couldn't get UIM IMSI: QMI protocol error (94): 'NotSupported''

Maybe Aleksander knows more about this?

Dan

> with mmcli -m 0. But no Internet connection so far.
> Normally, we also had problems with the Telit modem, I don't know why
> it 
> worked yesterday... So far it was completely random for me, I could
> see 
> no correlation of time or place or configuration with successful 
> connections.
> 
> I tried the Quectel modem with this system-connections file:
> 
> [connection]
> id=cellular
> type=gsm
> 
> [gsm]
> apn=shared.m2m.ch
> number=*99#
> 
> [ipv6]
> method=ignore
> 
> Later I added a uuid and tried again without success, even though
> the 
> connection to the Telit module which was successful also didn't
> contain 
> a uuid.
> > 
> > > Another problem is that it often happens that we use
> > > NetworkManager
> > > on
> > > devices which changes some settings and afterwards we can't even
> > > use
> > > the
> > > old methods to establish a connection

Re: Problems with modems/Example config for QMI-based modem,

[Dan Williams]

On Wed, 2018-02-28 at 18:40 +0100, Jakob Hasse wrote:
> Hello,
> 
> We want to integrate different modems into our embedded system. 
> Recently, our Linux-distributor decided to introduce NetworkManager. 
> When we switch to NetworkManager, network connectivity via 3G/2G is 
> never reliable: the connection either succeeds only sporadically or
> not 
> at all. This happens on three types of modems from two different 
> vendors. When we set up the modems manually with pppd or with a QMI
> test 
> program, everything works fine an reliably, also automatically after
> boot.
> Could you give me advice what steps to do to produce debug/log output
> to 
> then come back here and have someone look at it?

You want to increase the NetworkManager and ModemManager logging level:

nmcli g log level debug
mmcli -G debug

and then plug your modem in.  This will dump debug logging to whatever
system log service your linux distro uses.  For systemd-based distros,
you want:

journalctl -b -u NetworkManager
journalctl -b -u ModemManager

other distros will use /var/log/messages, /var/log/daemon.log, or
wherever else syslog 'daemon' facility output goes.

> Furthermore, it would be really nice to have an example
> configuration 
> file for /etc/NetworkManager/system-connections/ to configure a
> modem 
> with QMI connection. All the examples I had so far (seem to) only 
> establish the connection with pppd.

There should be no difference between a QMI or MBIM based modem and a
PPP based one.  The only options you really need are the APN and
possibly the username and password in the [gsm] section.

Since your email address is ".ch" I'm going to assume you don't care
about CDMA/EVDO and thus you only need to use [gsm].  The simplest
connection would be something like:

[connection]
id=T-Mobile Internet
uuid=0083942e-b260-4b73-a1fd-860f3e6ca2c2
type=gsm

[gsm]
apn=epc.tmobile.com
number=*99#

Again, there should be no difference between QMI and PPP-based modems
from a NetworkManager perspective.  ModemManager abstracts that away
for us.

> Another problem is that it often happens that we use NetworkManager
> on 
> devices which changes some settings and afterwards we can't even use
> the 
> old methods to establish a connection. This is really scary since it 
> basically renders our devices unusable so far. Is it possible to
> tell 
> NetworkManager to put the device in the original state again after
> using it?

What kind of changes happen here?  Are they things that are done
externally, or done by NetworkManager?

> I also have a question to ModemManager but don't know whether I'm
> right 
> with it here:
> We want to send AT commands to the modems while they serve an
> internet 
> connection. Normally, this is possible since the Modems all have 
> multiple serial interfaces. But when using ModemManager, it locks
> all 
> serial interfaces of the modems and we can't use them anymore. I
> know 
> that ModemManager can send AT commands with "mmcli --command" but
> only 
> in debug mode, so apparently not for production use. Is it possible
> to 
> send commands another way with ModemManager or prevent it from
> locking 
> all AT interfaces?

Yeah, this request comes up periodically, and MM should probably just
not open ports it doesn't need.  With PPP-based modems MM needs at
least two AT ports (one for the PPP connection and a second to use for
status while connected).  I don't think MM will care about the AT ports
when it's using QMI/MBIM, but if you can get debug logs from
ModemManager we can verify that.

Dan


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

Re: NM 1.4.4 and hotspot problem

[Dan Williams]

On Thu, 2018-02-22 at 08:37 +0100, Belisko Marek wrote:
> Hi Dan,
> 
> On Wed, Feb 21, 2018 at 11:45 PM, Dan Williams <d...@redhat.com>
> wrote:
> > On Wed, 2018-02-21 at 22:46 +0100, Belisko Marek wrote:
> > > Hi Dan,
> > > 
> > > On Tue, Feb 20, 2018 at 11:53 PM, Dan Williams <d...@redhat.com>
> > > wrote:
> > > > On Tue, 2018-02-20 at 22:47 +0100, Belisko Marek wrote:
> > > > > Hi Dan,
> > > > > 
> > > > > On Tue, Feb 20, 2018 at 10:11 PM, Dan Williams <dcbw@redhat.c
> > > > > om>
> > > > > wrote:
> > > > > > On Tue, 2018-02-20 at 21:00 +0100, Belisko Marek wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I'm trying to configure hotspot by using this command:
> > > > > > > nmcli dev wifi hotspot ifname wlan0 ssid test password
> > > > > > > "test1234"
> > > > > > > 
> > > > > > > on orangepi which is using realtek wifi (out of tree
> > > > > > > driver).
> > > > > > > When
> > > > > > > want to setup simple hotspot it looks like there are soe
> > > > > > > mtroubles
> > > > > > > with iptbles + dnsmasq. Any ideas what can cause this
> > > > > > > issue?
> > > > > > > Thanks
> > > > > > 
> > > > > > Your analysis looks correct.  What happens when you run the
> > > > > > iptables
> > > > > > command manually?
> > > > > > 
> > > > > > /usr/sbin/iptables --table nat \
> > > > > >--insert POSTROUTING --source 10.42.0.0/255.255.255.0 \
> > > > > >! --destination 10.42.0.0/255.255.255.0 --jump
> > > > > > MASQUERADE
> > > > > > 
> > > > > > does /usr/sbin/iptables exist?
> > > > > > 
> > > > > > does your kernel have the ipt_MASQUERADE, iptable_nat,
> > > > > > nf_conntrack,
> > > > > > iptable_mangle, and other modules like that available?
> > > > > 
> > > > > I've nmcli c up Hotspot
> > > > 
> > > > What does your 'iptables-save' output look like on this
> > > > machine?
> > > 
> > > It looks like this:
> > > 
> > >  iptables-save
> > > # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018
> > > *filter
> > > :INPUT ACCEPT [61:11807]
> > > :FORWARD ACCEPT [0:0]
> > > :OUTPUT ACCEPT [42:7785]
> > > COMMIT
> > > # Completed on Wed Feb 21 21:42:54 2018
> > > # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018
> > > *nat
> > > :PREROUTING ACCEPT [0:0]
> > > :INPUT ACCEPT [0:0]
> > > :OUTPUT ACCEPT [0:0]
> > > :POSTROUTING ACCEPT [0:0]
> > > COMMIT
> > > # Completed on Wed Feb 21 21:42:54 2018
> > > root@orange-pi-pc-plus:~# lsmod
> > > Module  Size  Used by
> > > ipt_REJECT 16384  -2
> > > ipt_MASQUERADE 16384  -2
> > > xt_tcpudp  16384  -2
> > > iptable_filter 16384  -2
> > > iptable_nat16384  -2
> > > ip_tables  20480  -2
> > > x_tables   20480  -2
> > > mali  208896  -2
> > > 8189fs   1224704  -2
> > > 
> > > 
> > > I've added more kernel modules (according :
> > > https://wiki.gentoo.org/wiki/Iptables#Kernel) and output look
> > > much
> > > better (unfortunately there are still some problems):
> > 
> > Ok, so the issue with iptables is solved (at least I think?), but
> > now
> > it's dnsmasq.  There was a problem in Debian a while back, where
> > just
> > installing dnsmasq set up a configuration that did this, which
> > meant
> > that NM could not run its own interface-specific dnsmasq.
> 
> Issue with iptables remains (I think last one):
> Feb 21 21:39:28 orange-pi-pc-plus user.info NetworkManager[765]:
>   [1519249168.1555] Executing: /usr/sbin/iptables --table
> filter
> --insert FORWARD --destination 10.42.0.0/255.255.255.0 --out-
> interface
> wlan0 --match state --state ESTA
> BLISHED,RELATED --jump ACCEPT
> Feb 21 21:39:28 orange-pi-pc-plus user.warn NetworkManager[765]:
>   [1519249168.1786] ** Command returned exit status 1.

Ok, for the

Re: NM 1.4.4 and hotspot problem

[Dan Williams]

On Wed, 2018-02-21 at 22:46 +0100, Belisko Marek wrote:
> Hi Dan,
> 
> On Tue, Feb 20, 2018 at 11:53 PM, Dan Williams <d...@redhat.com>
> wrote:
> > On Tue, 2018-02-20 at 22:47 +0100, Belisko Marek wrote:
> > > Hi Dan,
> > > 
> > > On Tue, Feb 20, 2018 at 10:11 PM, Dan Williams <d...@redhat.com>
> > > wrote:
> > > > On Tue, 2018-02-20 at 21:00 +0100, Belisko Marek wrote:
> > > > > Hi,
> > > > > 
> > > > > I'm trying to configure hotspot by using this command:
> > > > > nmcli dev wifi hotspot ifname wlan0 ssid test password
> > > > > "test1234"
> > > > > 
> > > > > on orangepi which is using realtek wifi (out of tree driver).
> > > > > When
> > > > > want to setup simple hotspot it looks like there are soe
> > > > > mtroubles
> > > > > with iptbles + dnsmasq. Any ideas what can cause this issue?
> > > > > Thanks
> > > > 
> > > > Your analysis looks correct.  What happens when you run the
> > > > iptables
> > > > command manually?
> > > > 
> > > > /usr/sbin/iptables --table nat \
> > > >--insert POSTROUTING --source 10.42.0.0/255.255.255.0 \
> > > >! --destination 10.42.0.0/255.255.255.0 --jump MASQUERADE
> > > > 
> > > > does /usr/sbin/iptables exist?
> > > > 
> > > > does your kernel have the ipt_MASQUERADE, iptable_nat,
> > > > nf_conntrack,
> > > > iptable_mangle, and other modules like that available?
> > > 
> > > I've nmcli c up Hotspot
> > 
> > What does your 'iptables-save' output look like on this machine?
> 
> It looks like this:
> 
>  iptables-save
> # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018
> *filter
> :INPUT ACCEPT [61:11807]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [42:7785]
> COMMIT
> # Completed on Wed Feb 21 21:42:54 2018
> # Generated by iptables-save v1.6.1 on Wed Feb 21 21:42:54 2018
> *nat
> :PREROUTING ACCEPT [0:0]
> :INPUT ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> COMMIT
> # Completed on Wed Feb 21 21:42:54 2018
> root@orange-pi-pc-plus:~# lsmod
> Module  Size  Used by
> ipt_REJECT 16384  -2
> ipt_MASQUERADE 16384  -2
> xt_tcpudp  16384  -2
> iptable_filter 16384  -2
> iptable_nat16384  -2
> ip_tables  20480  -2
> x_tables   20480  -2
> mali  208896  -2
> 8189fs   1224704  -2
> 
> 
> I've added more kernel modules (according :
> https://wiki.gentoo.org/wiki/Iptables#Kernel) and output look much
> better (unfortunately there are still some problems):

Ok, so the issue with iptables is solved (at least I think?), but now
it's dnsmasq.  There was a problem in Debian a while back, where just
installing dnsmasq set up a configuration that did this, which meant
that NM could not run its own interface-specific dnsmasq.

This line:

Feb 21 21:39:28 orange-pi-pc-plus daemon.info NetworkManager[765]:
 dnsmasq: failed to create listening socket for 10.42.0.1: Address
 already in use
 Feb 21 21:39:28 orange-pi-pc-plus user.warn NetworkManager[765]:
   [1519249168.4498] dnsmasq-manager: dnsmasq exited with error:
 Network access problem (address in use, permissions) (2)

is likely the current problem.  Do you have an existing dnsmasq process
running and what is the contents of /etc/dnsmasq.conf?  If it has the
"bind-interfaces" option enabled, that could be causing this issue.

Dan

> Feb 21 21:39:27 orange-pi-pc-plus user.info NetworkManager[765]:
>   [1519249167.7576] device (wlan0): Activation: (wifi)
> connection 'Hotspot' has security, and secrets exist.  No new secrets
> needed.
> Feb 21 21:39:27 orange-pi-pc-plus user.info NetworkManager[765]:
>   [1519249167.7579] Config: added 'ssid' value 'test'
> Feb 21 21:39:27 orange-pi-pc-plus user.info NetworkManager[765]:
>   [1519249167.7580] Config: added 'mode' value '2'
> Feb 21 21:39:27 orange-pi-pc-plus user.info NetworkManager[765]:
>   [1519249167.7581] Config: added 'frequency' value '2412'
> Feb 21 21:39:27 orange-pi-pc-plus user.info NetworkManager[765]:
>   [1519249167.7583] Config: added 'key_mgmt' value 'WPA-PSK'
> Feb 21 21:39:27 orange-pi-pc-plus user.info NetworkManager[765]:
>   [1519249167.7584] Config: added 'psk' value ''
> Feb 21 21:39:27 orange-pi-pc-plus user.info NetworkManager[765]:
>   [1519249167.7585] Config: added 'proto' value 'RSN'
> Feb 21 21:39:27 orange-pi-pc-plus user.info NetworkManager[765]:
>   [1519249167.758

Re: NM 1.4.4 and hotspot problem

[Dan Williams]

On Tue, 2018-02-20 at 22:47 +0100, Belisko Marek wrote:
> Hi Dan,
> 
> On Tue, Feb 20, 2018 at 10:11 PM, Dan Williams <d...@redhat.com>
> wrote:
> > On Tue, 2018-02-20 at 21:00 +0100, Belisko Marek wrote:
> > > Hi,
> > > 
> > > I'm trying to configure hotspot by using this command:
> > > nmcli dev wifi hotspot ifname wlan0 ssid test password "test1234"
> > > 
> > > on orangepi which is using realtek wifi (out of tree driver).
> > > When
> > > want to setup simple hotspot it looks like there are soe
> > > mtroubles
> > > with iptbles + dnsmasq. Any ideas what can cause this issue?
> > > Thanks
> > 
> > Your analysis looks correct.  What happens when you run the
> > iptables
> > command manually?
> > 
> > /usr/sbin/iptables --table nat \
> >--insert POSTROUTING --source 10.42.0.0/255.255.255.0 \
> >! --destination 10.42.0.0/255.255.255.0 --jump MASQUERADE
> > 
> > does /usr/sbin/iptables exist?
> > 
> > does your kernel have the ipt_MASQUERADE, iptable_nat,
> > nf_conntrack,
> > iptable_mangle, and other modules like that available?
> 
> I've nmcli c up Hotspot

What does your 'iptables-save' output look like on this machine?

Dan


> IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> Feb 20 21:41:02 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162862.9165] device (wlan0): Activation: starting
> connection 'Hotspot' (13e514a4-5c21-43ec-9658-d2d80738bac7)
> Feb 20 21:41:02 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162862.9187] audit: op="connection-activate"
> uuid="13e514a4-5c21-43ec-9658-d2d80738bac7" name="Hotspot" pid=985
> uid=0 result="success"
> Feb 20 21:41:02 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162862.9207] device (wlan0): state change: disconnected
> -> prepare (reason 'none') [30 40 0]
> Feb 20 21:41:02 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162862.9230] manager: NetworkManager state is now
> CONNECTING
> Feb 20 21:41:02 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162862.9439] device (wlan0): set-hw-addr: set-cloned MAC
> address to 12:81:76:EA:FC:D0 (permanent)
> Feb 20 21:41:02 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162862.9810] device (wlan0): state change: prepare ->
> config (reason 'none') [40 50 0]
> Feb 20 21:41:02 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162862.9840] device (wlan0): Activation: (wifi) access
> point 'Hotspot' has security, but secrets are required.
> Feb 20 21:41:02 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162862.9856] device (wlan0): state change: config ->
> need-auth (reason 'none') [50 60 0]
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0233] device (wlan0): state change: need-auth ->
> prepare (reason 'none') [60 40 0]
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0343] device (wlan0): state change: prepare ->
> config (reason 'none') [40 50 0]
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0372] device (wlan0): Activation: (wifi)
> connection 'Hotspot' has security, and secrets exist.  No new secrets
> needed.
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0376] Config: added 'ssid' value 'test'
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0377] Config: added 'mode' value '2'
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0378] Config: added 'frequency' value '2412'
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0379] Config: added 'key_mgmt' value 'WPA-PSK'
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0379] Config: added 'psk' value ''
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0380] Config: added 'proto' value 'RSN'
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0381] Config: added 'pairwise' value 'CCMP'
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0382] Config: added 'group' value 'CCMP'
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.0543] sup-iface[0x25ecd0,wlan0]: config: set
> interface ap_scan to 2
> IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> Feb 20 21:41:03 orange-pi-pc-plus user.info NetworkManager[264]:
>   [1519162863.8770] device (wlan0): supplicant interface state:
> disconnected -> completed
> Feb 20 21

Re: NM 1.4.4 and hotspot problem

[Dan Williams]

On Tue, 2018-02-20 at 21:00 +0100, Belisko Marek wrote:
> Hi,
> 
> I'm trying to configure hotspot by using this command:
> nmcli dev wifi hotspot ifname wlan0 ssid test password "test1234"
> 
> on orangepi which is using realtek wifi (out of tree driver). When
> want to setup simple hotspot it looks like there are soe mtroubles
> with iptbles + dnsmasq. Any ideas what can cause this issue? Thanks

Your analysis looks correct.  What happens when you run the iptables
command manually?

/usr/sbin/iptables --table nat \
   --insert POSTROUTING --source 10.42.0.0/255.255.255.0 \
   ! --destination 10.42.0.0/255.255.255.0 --jump MASQUERADE

does /usr/sbin/iptables exist?

does your kernel have the ipt_MASQUERADE, iptable_nat, nf_conntrack,
iptable_mangle, and other modules like that available?

Dan

> Log:
> IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.3228] keyfile: add connection in-memory
> (13e514a4-5c21-43ec-9658-d2d80738bac7,"Hotspot")
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.3308] device (wlan0): Activation: starting
> connection 'Hotspot' (13e514a4-5c21-43ec-9658-d2d80738bac7)
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.3343] keyfile: update
> /etc/NetworkManager/system-connections/Hotspot
> (13e514a4-5c21-43ec-9658-d2d80738bac7,"Hotspot") and persist
> connection
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.3351] audit: op="connection-add-activate"
> uuid="13e514a4-5c21-43ec-9658-d2d80738bac7" name="Hotspot" pid=1384
> uid=0 result="success"
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.3416] device (wlan0): state change: disconnected
> -> prepare (reason 'none') [30 40 0]
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.3426] manager: NetworkManager state is now
> CONNECTING
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.3726] device (wlan0): set-hw-addr: set-cloned MAC
> address to 12:81:76:EA:FC:D0 (permanent)
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4096] device (wlan0): state change: prepare ->
> config (reason 'none') [40 50 0]
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4111] device (wlan0): Activation: (wifi) access
> point 'Hotspot' has security, but secrets are required.
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4113] device (wlan0): state change: config ->
> need-auth (reason 'none') [50 60 0]
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4386] device (wlan0): supplicant interface state:
> inactive -> disconnected
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4392] device (wlan0): supplicant interface state:
> disconnected -> inactive
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4666] device (wlan0): state change: need-auth ->
> prepare (reason 'none') [60 40 0]
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4746] device (wlan0): state change: prepare ->
> config (reason 'none') [40 50 0]
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4759] device (wlan0): Activation: (wifi)
> connection 'Hotspot' has security, and secrets exist.  No new secrets
> needed.
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4763] Config: added 'ssid' value 'test'
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4765] Config: added 'mode' value '2'
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4766] Config: added 'frequency' value '2412'
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4767] Config: added 'key_mgmt' value 'WPA-PSK'
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4768] Config: added 'psk' value ''
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4769] Config: added 'proto' value 'RSN'
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4770] Config: added 'pairwise' value 'CCMP'
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4771] Config: added 'group' value 'CCMP'
> Feb 20 19:55:47 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156547.4983] sup-iface[0x259368,wlan0]: config: set
> interface ap_scan to 2
> IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> Feb 20 19:55:48 orange-pi-pc-plus user.info NetworkManager[1375]:
>   [1519156548.3471] device (wlan0): supplicant interface state:
> inactive -> completed
> Feb 20 19:55:48 orange-pi-pc-plus user.info 

Re: networkmanager permissions problem

[Dan Williams]

On Mon, 2018-02-19 at 06:12 +, John Frankish wrote:
> I've previously compiled modemmanager and networkmanager from source
> on x86_64 (non-systemd) and they work fine.
> 
> Using basically the same method on an RPi3 (non-systemd) - I get
> permissions problems.
> 
> I've compiled both (ModemManager-1.6.12, NetworkManager-1.4.6) with
> and without polkit, but both give a permissions error on starting nm-
> dispatcher.
> 
> I've tried starting nm-dispatcher and polkitd directly as root (the
> dbus and networkmanager daemons are running as root) and neither give
> errors.

It's not polkit that's the problem here.  It's D-Bus service activation
that's not able to launch nm-dispatcher or wpa_supplicant or polkit. 
Perhaps that's because of something like selinux or apparmor preventing
the main dbus-daemon process from running them, or perhaps permissions
aren't set on them correctly, or perhaps the paths in the service
activation files in /etc/dbus-1/system.d/ aren't correct.

Activation is a feature of dbus that actually runs the given program
the first time a request is made to that program's D-Bus interface.  On
systemd systems, that's handled by systemd.  On non-systemd systems, D-
Bus has a helper that the main dbus-daemon execs which then runs the
given service binary.

Dan

> Note also that eth0 is already running using udhcpc before starting
> networkmanager to enable an ssh connection.
> 
> Any trouble shooting suggestions would be much appreciated.
> 
> --
> 
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.5505] NetworkManager (version 1.4.6) is
> starting...
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.5507] Read config:
> /usr/local/etc/NetworkManager/nm-system-settings.conf
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.5766] manager[0xdd0028]: monitoring kernel
> firmware directory '/lib/firmware'.
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6028] dns-mgr[0xdda440]: init: dns=default, rc-
> manager=symlink
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6176] rfkill0: found WiFi radio killswitch (at
> /sys/devices/platform/soc/3f30.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0
> 001:1/ieee80211/phy0/rfkill0) (driver brcmfmac)
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6183] manager[0xdd0028]: WiFi hardware radio set
> enabled
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6184] manager[0xdd0028]: WWAN hardware radio set
> enabled
> Feb 18 05:55:02 box daemon.notice dbus[2961]: [system] Activating
> service name='org.freedesktop.nm_dispatcher' (using servicehelper)
> Feb 18 05:55:02 box daemon.notice dbus[2961]: [system] Activated
> service 'org.freedesktop.nm_dispatcher' failed: Failed to execute
> program org.freedesktop.nm_dispatcher: Permission denied
> Feb 18 05:55:02 box daemon.err NetworkManager[2966]: 
> [1518933302.6487] dispatcher: could not get dispatcher proxy! Error
> calling StartServiceByName for org.freedesktop.nm_dispatcher:
> GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to
> execute program org.freedesktop.nm_dispatcher: Permission denied
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6495] settings: loaded plugin keyfile: (c) 2007 -
> 2015 Red Hat, Inc.  To report bugs please use the NetworkManager
> mailing list.
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6565] settings: hostname: couldn't get property
> from hostnamed
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6585] dhcp-init: Using DHCP client 'dhcpcd'
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6587] manager: WiFi enabled by radio killswitch;
> enabled by state file
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6589] manager: WWAN enabled by radio killswitch;
> enabled by state file
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6590] manager: Networking is enabled by state
> file
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6594] Loaded device plugin: NMVxlanFactory
> (internal)
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6595] Loaded device plugin: NMVlanFactory
> (internal)
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6596] Loaded device plugin: NMVethFactory
> (internal)
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6598] Loaded device plugin: NMTunFactory
> (internal)
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6599] Loaded device plugin: NMMacvlanFactory
> (internal)
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6600] Loaded device plugin: NMIPTunnelFactory
> (internal)
> Feb 18 05:55:02 box daemon.info NetworkManager[2966]:
>   [1518933302.6601] Loaded device plugin: NMInfinibandFactory
> 

Re: How does IWD handle setting MAC address?

[Dan Williams]

On Mon, 2018-01-15 at 09:42 +0100, Marcel Holtmann wrote:
> Hi Thomas,
> 
> > > > > > > > > I am in favor of address randomization even while it
> > > > > > > > > has
> > > > > > > > > limited
> > > > > > > > > affect, but at least for background scanning it is
> > > > > > > > > useful.
> > > > > > > > > However
> > > > > > > > > doing this via RTNL is causing a weird layer
> > > > > > > > > violation and
> > > > > > > > > all
> > > > > > > > > sorts
> > > > > > > > > of potential races and issues. This needs to be done
> > > > > > > > > with
> > > > > > > > > full
> > > > > > > > > awareness of cfg80211 and thus via nl80211. So iwd
> > > > > > > > > should
> > > > > > > > > do
> > > > > > > > > it.
> > > > > > > > > And
> > > > > > > > > iwd should just expose an on/off switch for WiFi
> > > > > > > > > Privacy.
> > > > > > > > 
> > > > > > > > TL;DR: the policy of which MAC address to use (and
> > > > > > > > when) is
> > > > > > > > flexible
> > > > > > > > and present in NetworkManager configuration. And it's
> > > > > > > > more
> > > > > > > > then a
> > > > > > > > simple randomize on/off switch.
> > > > > > > > 
> > > > > > > > ===
> > > > > > > > A smaller reason is, that some people have strong
> > > > > > > > opinions
> > > > > > > > and
> > > > > > > > consider
> > > > > > > > important which bits of the address to scramble (and
> > > > > > > > choose a
> > > > > > > > well
> > > > > > > > known manufacturer OUI)[1].
> > > > > > > > I personally don't agree with the importance of such
> > > > > > > > considerations,
> > > > > > > > but I'd like NetworkManager to be the first choice for
> > > > > > > > people
> > > > > > > > with
> > > > > > > > this
> > > > > > > > particular need -- regardless of whether this need is
> > > > > > > > real or
> > > > > > > > only
> > > > > > > > perceived.
> > > > > > > > In NM you can configure how the bits are scrambled very
> > > > > > > > flexible.
> > > > > > > > Both
> > > > > > > > while scanning[2] and while being associated[3].
> > > > > > > > 
> > > > > > > > More interesting is, I don't only want to have a random
> > > > > > > > MAC
> > > > > > > > address
> > > > > > > > while scanning, but also while being associated. My
> > > > > > > > permanent
> > > > > > > > MAC
> > > > > > > > address should never ever be reveiled.
> > > > > > > > But a new random MAC address on each new association
> > > > > > > > isn't
> > > > > > > > exactly
> > > > > > > > what you
> > > > > > > > want either, because then I get a new IP address from
> > > > > > > > DHCP
> > > > > > > > each
> > > > > > > > time and have
> > > > > > > > to redo captive portal login.
> > > > > > > > So, I want for each of my Wi-Fi profiles a different,
> > > > > > > > stable
> > > > > > > > MAC
> > > > > > > > address. Actually, for public networks like a hotel, I
> > > > > > > > want
> > > > > > > > to
> > > > > > > > use
> > > > > > > > a
> > > > > > > > stable MAC address for a limited amount of time. The
> > > > > > > > example
> > > > > > > > in
> > > > > > > > [4]
> > > > > > > > show how to do that in NM.
> > > > > > > > ===
> > > > > > > 
> > > > > > > I have nothing against an option that says generate a new
> > > > > > > MAC
> > > > > > > address
> > > > > > > for this SSID and keep using it from that time forward.
> > > > > > 
> > > > > > If I understand correctly, you agree that the MAC address
> > > > > > depends
> > > > > > on
> > > > > > the profile.
> > > > > > 
> > > > > > 
> > > > > > > It is a bit counterproductive if nl80211 doesn’t allow to
> > > > > > > specify
> > > > > > > the
> > > > > > > MAC address for association. Since powering down WiFi,
> > > > > > > changing
> > > > > > > the
> > > > > > > address and powering back up is something that I am
> > > > > > > strictly
> > > > > > > against.
> > > > > > > 
> > > > > > > So if these things are what people really want, then
> > > > > > > neither NM
> > > > > > > nor
> > > > > > > iwd should actually do the heavy lifting for it. It
> > > > > > > should be
> > > > > > > done
> > > > > > > by
> > > > > > > the wireless stack in the kernel.
> > > > > > 
> > > > > > Ok, whatever works best.
> > > > > > 
> > > > > > 
> > > > > > > > > That said iwd should cope Ok with the MAC address
> > > > > > > > > changing
> > > > > > > > > behind
> > > > > > > > > its
> > > > > > > > > back if it receives the RTNL notification
> > > > > > > > > (RTM_NEWLINK) if
> > > > > > > > > it
> > > > > > > > > isn't
> > > > > > > > > connected.  It always updates it's copy of the
> > > > > > > > > address on a
> > > > > > > > > RTM_NEWLINK so the race condition shouldn't be
> > > > > > > > > present I
> > > > > > > > > suppose.
> > > > > > > > 
> > > > > > > > I would think so too. NM change the MAC address via
> > > > > > > > RTNL only
> > > > > > > > while
> > > > > > > > scanning, early during activation, and late during
> > > > > > > > deactivation.
> > > > > > > > As the wireless daemon does/should not autoactivate the
> > > > > > > > 

Re: How does IWD handle setting MAC address?

[Dan Williams]

On Fri, 2018-01-05 at 14:58 +0100, Thomas Haller wrote:
> On Thu, 2018-01-04 at 20:22 +0100, Marcel Holtmann wrote:
> > Hi Thomas,
> > 
> > > > I am in favor of address randomization even while it has
> > > > limited
> > > > affect, but at least for background scanning it is useful.
> > > > However
> > > > doing this via RTNL is causing a weird layer violation and all
> > > > sorts
> > > > of potential races and issues. This needs to be done with full
> > > > awareness of cfg80211 and thus via nl80211. So iwd should do
> > > > it.
> > > > And
> > > > iwd should just expose an on/off switch for WiFi Privacy.
> > > 
> > > TL;DR: the policy of which MAC address to use (and when) is
> > > flexible
> > > and present in NetworkManager configuration. And it's more then a
> > > simple randomize on/off switch.
> > > 
> > > ===
> > > A smaller reason is, that some people have strong opinions and
> > > consider
> > > important which bits of the address to scramble (and choose a
> > > well
> > > known manufacturer OUI)[1].
> > > I personally don't agree with the importance of such
> > > considerations,
> > > but I'd like NetworkManager to be the first choice for people
> > > with
> > > this
> > > particular need -- regardless of whether this need is real or
> > > only
> > > perceived.
> > > In NM you can configure how the bits are scrambled very flexible.
> > > Both
> > > while scanning[2] and while being associated[3].
> > > 
> > > More interesting is, I don't only want to have a random MAC
> > > address
> > > while scanning, but also while being associated. My permanent MAC
> > > address should never ever be reveiled.
> > > But a new random MAC address on each new association isn't
> > > exactly
> > > what you
> > > want either, because then I get a new IP address from DHCP each
> > > time and have
> > > to redo captive portal login.
> > > So, I want for each of my Wi-Fi profiles a different, stable MAC
> > > address. Actually, for public networks like a hotel, I want to
> > > use
> > > a
> > > stable MAC address for a limited amount of time. The example in
> > > [4]
> > > show how to do that in NM.
> > > ===
> > 
> > I have nothing against an option that says generate a new MAC
> > address
> > for this SSID and keep using it from that time forward.
> 
> If I understand correctly, you agree that the MAC address depends on
> the profile.
> 
> 
> > It is a bit counterproductive if nl80211 doesn’t allow to specify
> > the
> > MAC address for association. Since powering down WiFi, changing the
> > address and powering back up is something that I am strictly
> > against.
> > 
> > So if these things are what people really want, then neither NM nor
> > iwd should actually do the heavy lifting for it. It should be done
> > by
> > the wireless stack in the kernel.
> 
> Ok, whatever works best.
> 
> 
> > > > That said iwd should cope Ok with the MAC address changing
> > > > behind
> > > > its
> > > > back if it receives the RTNL notification (RTM_NEWLINK) if it
> > > > isn't
> > > > connected.  It always updates it's copy of the address on a
> > > > RTM_NEWLINK so the race condition shouldn't be present I
> > > > suppose.
> > > 
> > > I would think so too. NM change the MAC address via RTNL only
> > > while
> > > scanning, early during activation, and late during deactivation.
> > > As the wireless daemon does/should not autoactivate the device
> > > against
> > > NM's wish and NM determines that the device is deactivated only
> > > after
> > > an event from iwd.
> > > Hence, there shouldn't be a race of NM interfering while being
> > > connected. The race is only while scanning and iwd should just
> > > cope
> > > with that.
> > > 
> > > Alternatively/additionally, a SetMacAddress() D-Bus call would
> > > avoid
> > > any race and allow to leave the decision which address to user to
> > > somebody closer to the user.
> > 
> > It will not be as simple as that. You need to leave iwd with the
> > decision making for connecting to known WiFi networks. It just
> > isn’t
> > as dumb as wpa_supplicant and from a NM perspective, you should be
> > doing as little as you do with BlueZ or oFono.
> > 
> > This means iwd needs to be told what to do and not just an address.
> > It doesn’t matter if it is via a D-Bus call or RTNL. iwd remembers
> > known networks and will connect to them if they are in range, roam
> > automatically and also switch networks if it makes sense. That
> > means
> > any randomization policy would have to be executed inside iwd and
> > not
> > outside. As stated above, if you want different MAC addresses per
> > SSID, then that needs to be inside iwd.
> > 
> > So many things in the wpa_supplicant design led to “hacks” outside
> > to
> > add features and that really has to stop. It is not maintainable
> > and
> > the corner cases and race condition this architecture causes is
> > just
> > crazy.
> 
> 
> For NM, at each moment not all its connection profiles are candidate
> for connecting automatically. The list of 

Re: [PATCH 3/4] devices/wifi: Add the wifi-backend config option

[Dan Williams]

On Tue, 2017-12-05 at 16:26 +0100, Andrew Zaborowski wrote:
> Let the config file select between creating classes of NMDeviceWifi
> (for the usual wpa_supplicant based devices) and NMDeviceIwd
> depending
> on the new NetworkManager.conf setting.

This seems wrong to me.  We usually try to keep things runtime enabled
rather than add config options like this.  Is there any reason you
would have both wpa_supplicant and iwd running on the same system at
the same time?  Could we check whether the iwd dbus service is claimed
and just use iwd if it's running?

Dan

> ---
>  man/NetworkManager.conf.xml| 13 +
>  src/devices/wifi/nm-wifi-factory.c | 23 ---
>  src/nm-config.h|  1 +
>  3 files changed, 34 insertions(+), 3 deletions(-)
> 
> diff --git a/man/NetworkManager.conf.xml
> b/man/NetworkManager.conf.xml
> index 94465a019..a7fa752e9 100644
> --- a/man/NetworkManager.conf.xml
> +++ b/man/NetworkManager.conf.xml
> @@ -426,6 +426,19 @@ no-auto-default=*
>    
>  
>    
> +
> +  
> +wifi-backend
> +
> +  
> +If present, specifies the WiFi backend to use. Allowed
> +values are wpa_supplicant and, if
> +enabled during compilation, iwd
> + (expermiental). wpa_supplicant is
> also
> +the default backend.
> +  
> +
> +  
>  
>    
>  
> diff --git a/src/devices/wifi/nm-wifi-factory.c
> b/src/devices/wifi/nm-wifi-factory.c
> index a1752634b..6c6984eab 100644
> --- a/src/devices/wifi/nm-wifi-factory.c
> +++ b/src/devices/wifi/nm-wifi-factory.c
> @@ -27,8 +27,10 @@
>  #include "nm-setting-olpc-mesh.h"
>  #include "nm-device-wifi.h"
>  #include "nm-device-olpc-mesh.h"
> +#include "nm-device-iwd.h"
>  #include "settings/nm-settings-connection.h"
>  #include "platform/nm-platform.h"
> +#include "nm-config.h"
>  
>  /***
> **/
>  
> @@ -75,6 +77,7 @@ create_device (NMDeviceFactory *factory,
>  {
>   NMDeviceWifiCapabilities capabilities;
>   NM80211Mode mode;
> + const char *backend;
>  
>   g_return_val_if_fail (iface != NULL, NULL);
>   g_return_val_if_fail (plink != NULL, NULL);
> @@ -98,10 +101,24 @@ create_device (NMDeviceFactory *factory,
>   return NULL;
>   }
>  
> - if (plink->type == NM_LINK_TYPE_WIFI)
> - return nm_device_wifi_new (iface, capabilities);
> - else
> + if (plink->type != NM_LINK_TYPE_WIFI)
>   return nm_device_olpc_mesh_new (iface);
> +
> + backend = nm_config_data_get_value (NM_CONFIG_GET_DATA_ORIG,
> + NM_CONFIG_KEYFILE_GROUP_
> MAIN,
> + NM_CONFIG_KEYFILE_KEY_MA
> IN_WIFI_BACKEND,
> + NM_CONFIG_GET_VALUE_STRI
> P);
> +
> + nm_log_warn (LOGD_PLATFORM | LOGD_WIFI, "(%s) config:
> backend is %s, %i", iface, backend, WITH_IWD);
> + if (!backend || !strcasecmp (backend, "wpa_supplicant"))
> + return nm_device_wifi_new (iface, capabilities);
> +#if WITH_IWD
> + else if (!strcasecmp (backend, "iwd"))
> + return nm_device_iwd_new (iface, capabilities);
> +#endif
> +
> + nm_log_warn (LOGD_PLATFORM | LOGD_WIFI, "(%s) config:
> unknown or unsupported wifi-backend %s", iface, backend);
> + return NULL;
>  }
>  
>  /***
> **/
> diff --git a/src/nm-config.h b/src/nm-config.h
> index 47e929884..d94a279ca 100644
> --- a/src/nm-config.h
> +++ b/src/nm-config.h
> @@ -64,6 +64,7 @@
>  #define NM_CONFIG_KEYFILE_KEY_MAIN_DEBUG"debug"
>  #define
> NM_CONFIG_KEYFILE_KEY_MAIN_HOSTNAME_MODE"hostname-mode"
>  #define NM_CONFIG_KEYFILE_KEY_MAIN_SLAVES_ORDER "slaves-
> order"
> +#define NM_CONFIG_KEYFILE_KEY_MAIN_WIFI_BACKEND "wifi-
> backend"
>  #define
> NM_CONFIG_KEYFILE_KEY_LOGGING_BACKEND   "backend"
>  #define NM_CONFIG_KEYFILE_KEY_CONFIG_ENABLE "enable"
>  #define NM_CONFIG_KEYFILE_KEY_ATOMIC_SECTION_WAS".was"
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Pantech UML290 - 106c:3718 - QMI Modem

[Dan Williams]

On Mon, 2017-11-20 at 17:16 -0600, Greg Oliver wrote:
> On Mon, Nov 20, 2017 at 2:16 PM, Greg Oliver <oliver.g...@gmail.com>
> wrote:
> 
> > On Mon, Nov 20, 2017 at 12:00 PM, Greg Oliver <oliver.g...@gmail.co
> > m>
> > wrote:
> > 
> > > On Mon, Nov 20, 2017 at 11:11 AM, Dan Williams <d...@redhat.com>
> > > wrote:
> > > > On Mon, 2017-11-20 at 11:04 -0600, Dan Williams wrote:
> > > > > On Fri, 2017-11-17 at 08:48 -0600, Greg Oliver wrote:
> > > > > > On Fri, Nov 17, 2017 at 2:34 AM, Aleksander Morgado <
> > > > > > aleksan...@aleksander.es> wrote:
> > > > > > 
> > > > > > > On Fri, Nov 17, 2017 at 12:44 AM, Greg Oliver  > > > > > > g@gmail.
> > > > > > > co
> > > > > > > m>
> > > > > > > wrote:
> > > > > > > > On Thu, Nov 16, 2017 at 2:57 PM, Aleksander Morgado
> > > > > > > > <aleksan...@aleksander.es> wrote:
> > > > > > 
> > > > > > [snip]
> > > > > > 
> > > > > > 
> > > > > > > > [greg@dell-wifi ~]$ sudo mmcli -m 0
> > > > > > > > 
> > > > > > > > /org/freedesktop/ModemManager1/Modem/0 (device id
> > > > > > > > '48d4cf9eceb8dbb2de4e13da073cb011be31f29e')
> > > > > > > >   -
> > > > > > > >   Hardware |   manufacturer: 'QUALCOMM INCORPORATED'
> > > > > > > >    |  model: '42'
> > > > > > > >    |   revision:
> > > > > > > > 'L0290VWBB12F.248  1  [Nov  9 2011
> > > > > > > 
> > > > > > > 08:44:21]'
> > > > > > > >    |  supported: 'gsm-umts
> > > > > > > >    |  cdma-evdo
> > > > > > > >    |  lte
> > > > > > > >    |  cdma-evdo, gsm-umts
> > > > > > > >    |  gsm-umts, lte
> > > > > > > >    |  cdma-evdo, lte
> > > > > > > >    |  cdma-evdo, gsm-umts, lte'
> > > > > > > >    |current: 'cdma-evdo'
> > > > > > > 
> > > > > > > So this is being managed in QMI, which is ok, but as seen
> > > > > > > above
> > > > > > > the
> > > > > > > "current" mode is limited to cdma-evdo for some reason
> > > > > > > (i.e. no
> > > > > > > LTE).
> > > > > > > 
> > > > > > > Can you try to run this?
> > > > > > > mmcli -m 0 --set-current-capabilities="cdma-evdo|lte"
> > > > > > > 
> > > > > > > The device should reboot after that; then re-run "mmcli
> > > > > > > -m X" (X
> > > > > > > will
> > > > > > > likely be 1 after the reboot) and see if the "current"
> > > > > > > field
> > > > > > > shows
> > > > > > > "lte" as well.
> > > > > > > 
> > > > > > > [snip]
> > > > > > > 
> > > > > > 
> > > > > > [greg@dell-wifi ~]$ sudo mmcli -m 0
> > > > > > --set-current-capabilities="cdma-evdo|lte"
> > > > > > error: couldn't set current capabilities:
> > > > > > 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsup
> > > > > > ported:
> > > > > > Setting
> > > > > > capabilities is not supported by this device'
> > > > > 
> > > > > You may not actually be able to change the capabilities in
> > > > > ModemManager, I don't recall exactly why and I thought we'd
> > > > > fixed it,
> > > > > but perhaps just use qmicli for the time being.
> > > > > 
> > > > > The UML290 is a bit particular in the options it wants, so
> > > > > try this
> > > > > (it
> > > > > works on my 290...)
> > > > > 
> > > > > sudo qmicli -p -d /dev/cdc-wdm1 --nas-set-system-selection-
> > 

Re: Pantech UML290 - 106c:3718 - QMI Modem

[Dan Williams]

On Mon, 2017-11-20 at 11:04 -0600, Dan Williams wrote:
> On Fri, 2017-11-17 at 08:48 -0600, Greg Oliver wrote:
> > On Fri, Nov 17, 2017 at 2:34 AM, Aleksander Morgado <
> > aleksan...@aleksander.es> wrote:
> > 
> > > On Fri, Nov 17, 2017 at 12:44 AM, Greg Oliver <oliver.greg@gmail.
> > > co
> > > m>
> > > wrote:
> > > > On Thu, Nov 16, 2017 at 2:57 PM, Aleksander Morgado
> > > > <aleksan...@aleksander.es> wrote:
> > 
> > [snip]
> > 
> > 
> > > > [greg@dell-wifi ~]$ sudo mmcli -m 0
> > > > 
> > > > /org/freedesktop/ModemManager1/Modem/0 (device id
> > > > '48d4cf9eceb8dbb2de4e13da073cb011be31f29e')
> > > >   -
> > > >   Hardware |   manufacturer: 'QUALCOMM INCORPORATED'
> > > >    |  model: '42'
> > > >    |   revision: 'L0290VWBB12F.248  1  [Nov  9 2011
> > > 
> > > 08:44:21]'
> > > >    |  supported: 'gsm-umts
> > > >    |  cdma-evdo
> > > >    |  lte
> > > >    |  cdma-evdo, gsm-umts
> > > >    |  gsm-umts, lte
> > > >    |  cdma-evdo, lte
> > > >    |  cdma-evdo, gsm-umts, lte'
> > > >    |current: 'cdma-evdo'
> > > 
> > > So this is being managed in QMI, which is ok, but as seen above
> > > the
> > > "current" mode is limited to cdma-evdo for some reason (i.e. no
> > > LTE).
> > > 
> > > Can you try to run this?
> > > mmcli -m 0 --set-current-capabilities="cdma-evdo|lte"
> > > 
> > > The device should reboot after that; then re-run "mmcli -m X" (X
> > > will
> > > likely be 1 after the reboot) and see if the "current" field
> > > shows
> > > "lte" as well.
> > > 
> > > [snip]
> > > 
> > 
> > [greg@dell-wifi ~]$ sudo mmcli -m 0
> > --set-current-capabilities="cdma-evdo|lte"
> > error: couldn't set current capabilities:
> > 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsupported:
> > Setting
> > capabilities is not supported by this device'
> 
> You may not actually be able to change the capabilities in
> ModemManager, I don't recall exactly why and I thought we'd fixed it,
> but perhaps just use qmicli for the time being.
> 
> The UML290 is a bit particular in the options it wants, so try this
> (it
> works on my 290...)
> 
> sudo qmicli -p -d /dev/cdc-wdm1 --nas-set-system-selection-
> preference="cdma-1x|cdma-1xevdo|gsm|umts|lte"

And sorry, you want /dev/cdc-wdm0 here.  I already had a QMI device
plugged in, thus the UML290 got cdc-wdm1 for me...

> > I am asking the guy I am incorporating this for to check his plan
> > to
> > see if
> > his SIM card plan is even LTE capable.  He is switching from T-
> > Mobile 
> > 2g on
> > his devices (since they are disbanding that network) to
> > Verizon.  I'll post
> > back when I hear, but your earlier comment that evdo does not take
> > APNs
> > took me by surprise.  I have never used 3rd party network
> > subscriptions
> > before until this guy, but what you are saying is that when using
> > PPP
> > on
> > evdo networks there is no APN concept like in GSM?  His original
> > line
> > of
> 
> That's correct.  Verizon is still a hybrid CDMA/EVDO (which doesn't
> use
> APNs at all) and LTE (which does) network.  Your modem was originally
> in CDMA/EVDO mode with LTE disabled, and thus NetworkManager would
> not
> allow APN entry because it would be useless as CDMA doesn't use one.
> 
> But if you switch the device with the above command to enable LTE as
> well, then you can enter the APN which will be used when the device
> attaches to the Verizon LTE network.
> 
> (I could go into what it does when it's dual-mode CDMA/EVDO + LTE,
> but
> that's a much longer mail).
> 
> If that works and you can use your APN, great.  If it doesn't work,
> or
> handoff between LTE and CDMA/EVDO doesn't work for you, let us know
> because there's one more setting that needs to be on for dual-mode to
> work correctly (eHRPD).
> 
> > product on T-Mobile 2g was able to use 3rd party APNs just fine - I
> > did not
> > know the backend of the 2 technologies were that much different
> > other
> > than
> > the framing used - guess I need to read up more.
> 
> They are a ton different :)  CDMA/EVDO store more of the subscriber
> information with the carrier, thus you don't use APNs or SIM cards.
> 
> Dan
> ___
> 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: Pantech UML290 - 106c:3718 - QMI Modem

[Dan Williams]

On Fri, 2017-11-17 at 08:48 -0600, Greg Oliver wrote:
> On Fri, Nov 17, 2017 at 2:34 AM, Aleksander Morgado <
> aleksan...@aleksander.es> wrote:
> 
> > On Fri, Nov 17, 2017 at 12:44 AM, Greg Oliver  > m>
> > wrote:
> > > On Thu, Nov 16, 2017 at 2:57 PM, Aleksander Morgado
> > >  wrote:
> 
> [snip]
> 
> 
> > > [greg@dell-wifi ~]$ sudo mmcli -m 0
> > > 
> > > /org/freedesktop/ModemManager1/Modem/0 (device id
> > > '48d4cf9eceb8dbb2de4e13da073cb011be31f29e')
> > >   -
> > >   Hardware |   manufacturer: 'QUALCOMM INCORPORATED'
> > >    |  model: '42'
> > >    |   revision: 'L0290VWBB12F.248  1  [Nov  9 2011
> > 
> > 08:44:21]'
> > >    |  supported: 'gsm-umts
> > >    |  cdma-evdo
> > >    |  lte
> > >    |  cdma-evdo, gsm-umts
> > >    |  gsm-umts, lte
> > >    |  cdma-evdo, lte
> > >    |  cdma-evdo, gsm-umts, lte'
> > >    |current: 'cdma-evdo'
> > 
> > So this is being managed in QMI, which is ok, but as seen above the
> > "current" mode is limited to cdma-evdo for some reason (i.e. no
> > LTE).
> > 
> > Can you try to run this?
> > mmcli -m 0 --set-current-capabilities="cdma-evdo|lte"
> > 
> > The device should reboot after that; then re-run "mmcli -m X" (X
> > will
> > likely be 1 after the reboot) and see if the "current" field shows
> > "lte" as well.
> > 
> > [snip]
> > 
> 
> [greg@dell-wifi ~]$ sudo mmcli -m 0
> --set-current-capabilities="cdma-evdo|lte"
> error: couldn't set current capabilities:
> 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsupported:
> Setting
> capabilities is not supported by this device'

You may not actually be able to change the capabilities in
ModemManager, I don't recall exactly why and I thought we'd fixed it,
but perhaps just use qmicli for the time being.

The UML290 is a bit particular in the options it wants, so try this (it
works on my 290...)

sudo qmicli -p -d /dev/cdc-wdm1 
--nas-set-system-selection-preference="cdma-1x|cdma-1xevdo|gsm|umts|lte"

> I am asking the guy I am incorporating this for to check his plan to
> see if
> his SIM card plan is even LTE capable.  He is switching from T-Mobile 
> 2g on
> his devices (since they are disbanding that network) to
> Verizon.  I'll post
> back when I hear, but your earlier comment that evdo does not take
> APNs
> took me by surprise.  I have never used 3rd party network
> subscriptions
> before until this guy, but what you are saying is that when using PPP
> on
> evdo networks there is no APN concept like in GSM?  His original line
> of

That's correct.  Verizon is still a hybrid CDMA/EVDO (which doesn't use
APNs at all) and LTE (which does) network.  Your modem was originally
in CDMA/EVDO mode with LTE disabled, and thus NetworkManager would not
allow APN entry because it would be useless as CDMA doesn't use one.

But if you switch the device with the above command to enable LTE as
well, then you can enter the APN which will be used when the device
attaches to the Verizon LTE network.

(I could go into what it does when it's dual-mode CDMA/EVDO + LTE, but
that's a much longer mail).

If that works and you can use your APN, great.  If it doesn't work, or
handoff between LTE and CDMA/EVDO doesn't work for you, let us know
because there's one more setting that needs to be on for dual-mode to
work correctly (eHRPD).

> product on T-Mobile 2g was able to use 3rd party APNs just fine - I
> did not
> know the backend of the 2 technologies were that much different other
> than
> the framing used - guess I need to read up more.

They are a ton different :)  CDMA/EVDO store more of the subscriber
information with the carrier, thus you don't use APNs or SIM cards.

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

Re: "Shared to other computers" question

[Dan Williams]

On Fri, 2017-09-29 at 09:52 -0400, Ken Taylor wrote:
> Several months ago I setup a PC to share a VPN connection among the
> PCs 
> on my LAN. A CentOS 7 box serves as a "gateway" and accesses the VPN 
> using the openvpn client.
> 
> NIC1 connects to my router using DHCP on the router to obtain an IP 
> address such as 192.168.0.116.
> 
> NIC2 is set to "Share to other computers". ifconfig shows this device
> to 
> have the address 10.42.0.1.  By connecting another PC with a hard
> coded 
> IP address in the 10.42.0.xxx range to a switch and thereby to the
> dual 
> NIC machine, my second PC can connect to the Internet. MAGIC :-)

The "Shared" option actually runs its own DHCP server (using dnsmasq),
so you shouldn't need a second one anywhere.

> I then decided to do a little daisy chaining.  I added a second NIC
> to 
> the second PC. I configured that interface to "Share to other 
> computers." This connection gained the IP address 10.43.0.1 Cool.
> 
> I put the first dual NIC PC in "production" between my Internet 
> connection and my LAN. I installed a DHCP server on the box and it 
> serves up 10.42.0.xxx addresses to my LAN PCs.  Works great and has
> been 
> in use for about 3 - 4 months.
> 
> Today I needed to setup something to do some firewall experimenting. 
> I 
> plugged a test PC with 2 NICs to my LAN with NIC1. It received an IP 
> address 10.42.0.xxx from my DHCP server. So far, so good.
> 
> I configured the second NIC as "Shared to other computers" as
> described 
> above.  This time the second NIC received the address 10.42.0.1
> which 
> will not work. That is the address of the first dual NIC PC.
> 
> I have redone this several times. I also tried an Ubuntu 16.04 PC. 
> I 
> still get the 10.42.0.1 address on the second NIC. I am at a loss.

Any time you pick "Shared" the subnet on that NIC will get the default
IP subnet of 10.42.x.  Unless you change it.

Which you can do by either adding an IP address to the connection by
editing its config file, or by running nm-connection-editor, finding
your "shared" connection, and setting the IP address in the IPv4 tab. 
When you do that, NM will change its DHCP server to use the subnet that
you specify there, and reserve a few addresses for static servers.

So for example, if I created a new "Shared" connection and assigned it
the IP address 172.16.55.1/24, the sharing NIC would get 172.16.55.1. 
NM will set up a DHCP server for the 172.16.55.0/24 subnet, and reserve
about 10 IPs for static services like printers or servers or whatever. 
It will then start a DHCP server to provide IPs and DNS to other
computers on that NIC's network, starting around 172.16.55.11 or so. 
It will then NAT everything on that NIC/subnet to the IP address of
your upstream connection, whatever that might be.

Dan

> Was the original 10.43 address a fluke?
> Perhaps a newer version of network-manager-applet is hosed?
> Something I need to configure manually in the firewall to cause an
> new 
> subnet to be assigned to NIC2?  I really have no idea where the
> 10.42 
> address came from in the first place.
> 
> The test PC is running CentOS 7.4 with network-manager-applet
> 1.8.0.3.
> 
> 
> Any advice appreciated.
> 
> TIA,
> 
> Ken
> 
> ___
> 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: Retrieving 'secret' setting

[Dan Williams]

On Thu, 2017-09-07 at 18:24 +0100, Colin Helliwell wrote:
> > On 07 September 2017 at 16:37 Dan Williams <d...@redhat.com> wrote:
> > 
> > On Thu, 2017-09-07 at 09:31 +0100, Colin Helliwell wrote:
> > 
> 
> ..
> > > Thanks Dan, that gets it.
> > > Now I'm struggling to *modify* the password :S I see that I
> > > can
> > > do a
> > >  settings.set_property(NM.SETTING_GSM_PASSWORD, "NewPw")
> > > but unsure how to complete the updating. I found
> > > NM.Connection.replace_settings(), and update_secrets(), but both
> > > of
> > > those put me back into GVariant territory.
> > > What would be the route to get the new password fed back through
> > > (presumably prior to finishing with a
> > > NM.RemoteConnection.save()/commit()?)
> > 
> > You're correct. Here's what I'd do:
> > 
> > client = NM.Client.new(None)
> > c =
> > client.get_connection_by_uuid(sys.argv[1])
> > secrets =
> > c.get_secrets(NM.SETTING_WIRELESS_SECURITY_SETTING_NAME)
> > 
> > # this merges
> > the secrets into the existing connection
> > c.update_secrets(NM.SETTING_WIR
> > ELESS_SECURITY_SETTING_NAME, secrets)
> > 
> > 
> > 
> > # write the full connection back to NM
> > c.save()
> 
> Yep, that's working (subject to save vs. commit_changes)  - many
> thanks for the guidance.
> 
> Btw, it seems the password can be extracted simply by: 
>    password = secrets['gsm']['password']

Oh hey, that's cool.  Didn't know the python Gobject introspection
bindings would go that far into a GVariant.  Learned something new
today.

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

Re: Retrieving 'secret' setting

[Dan Williams]

On Thu, 2017-09-07 at 09:31 +0100, Colin Helliwell wrote:
> > On 06 September 2017 at 17:18 Dan Williams <d...@redhat.com> wrote:
> > 
> > On Wed, 2017-09-06 at 12:51 +0100, Colin Helliwell wrote:
> > 
> > > > On 06 September 2017 at 11:14 Thomas Haller <thal...@redhat.com
> > > > >
> > > > wrote:
> > > > 
> > > > On Wed, 2017-09-06 at 10:20 +0100, colin.helliwell@ln-systems.c
> > > > om
> > > > wrote:
> > > > 
> > > > > I'm python-scripting to get a connection's gsm properties,
> > > > > and
> > > > > want
> > > > > to get
> > > > > the password - which "c.for_each_setting_value(print_values,
> > > > > None)"
> > > > > seems to
> > > > > not report (just "None").
> > > > > What would be the technique to get it?
> > > > > Thanks
> > > > 
> > > > Hi,
> > > > 
> > > > on D-Bus, secrets are exposed separately from regular
> > > > properties of
> > > > the
> > > > connection.
> > > > 
> > > > GetSettings() vs GetSecrets() in
> > > > https://developer.gnome.org/NetworkManager/stable/gdbus-org.fre
> > > > edes
> > > > ktop.NetworkManager.Settings.Connection.html
> > > > 
> > > > Anyway, from libnm (and python gi) you would call
> > > > 
> > > > secrets = remote_connection.get_secrets('ethernet')
> > > 
> > > Great, got that. Now, don't suppose you could help me get to
> > > grips
> > > with parsing the Glib.Variant? ;)
> > 
> > You can get around the need for touching GVariant by passing what
> > you
> > get from get_secrets() to NMConnection's replace_settings() call
> > too.
> > Then you get a nice NMConnection object, with only the secrets
> > filled
> > in. For example, pass a connection UUID as the argument to this:
> > 
> > #!/usr/bin/env python
> > import gi
> > gi.require_version('NM', '1.0')
> > from
> > gi.repository import GLib, NM
> > import sys
> > 
> > client = NM.Client.new(None)
> > c = client.get_connection_by_uuid(sys.argv[1])
> > wifi_secrets =
> > c.get_secrets(NM.SETTING_WIRELESS_SECURITY_SETTING_NAME)
> > wifi_secrets_con = NM.SimpleConnection.new()
> > wifi_secrets_con.replace_settings(wifi_secrets)
> > wsec = wifi_secrets_con.get_setting_wireless_security()
> > print "%s" % wsec.get_psk()
> > 
> 
> Thanks Dan, that gets it.
> Now I'm struggling to *modify* the password :S   I see that I can
> do a
>    settings.set_property(NM.SETTING_GSM_PASSWORD, "NewPw")
> but unsure how to complete the updating. I found
> NM.Connection.replace_settings(), and update_secrets(), but both of
> those put me back into GVariant territory.
> What would be the route to get the new password fed back through
> (presumably prior to finishing with a
> NM.RemoteConnection.save()/commit()?)

You're correct.  Here's what I'd do:

client = NM.Client.new(None)
c =
client.get_connection_by_uuid(sys.argv[1])
secrets =
c.get_secrets(NM.SETTING_WIRELESS_SECURITY_SETTING_NAME)
# this merges
the secrets into the existing connection
c.update_secrets(NM.SETTING_WIR
ELESS_SECURITY_SETTING_NAME, secrets)

# write the full connection back to NM
c.save()

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

Re: Retrieving 'secret' setting

[Dan Williams]

On Wed, 2017-09-06 at 12:51 +0100, Colin Helliwell wrote:
> > On 06 September 2017 at 11:14 Thomas Haller 
> > wrote:
> > 
> > On Wed, 2017-09-06 at 10:20 +0100, colin.helliw...@ln-systems.com
> > wrote:
> > 
> > > I'm python-scripting to get a connection's gsm properties, and
> > > want
> > > to get
> > > the password - which "c.for_each_setting_value(print_values,
> > > None)"
> > > seems to
> > > not report (just "None").
> > > What would be the technique to get it?
> > > Thanks
> > 
> > Hi,
> > 
> > on D-Bus, secrets are exposed separately from regular properties of
> > the
> > connection.
> > 
> > GetSettings() vs GetSecrets() in
> > https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedes
> > ktop.NetworkManager.Settings.Connection.html
> > 
> > Anyway, from libnm (and python gi) you would call
> > 
> > secrets = remote_connection.get_secrets('ethernet')
> > 
> 
> Great, got that. Now, don't suppose you could help me get to grips
> with parsing the Glib.Variant? ;)

You can get around the need for touching GVariant by passing what you
get from get_secrets() to NMConnection's replace_settings() call too. 
Then you get a nice NMConnection object, with only the secrets filled
in.  For example, pass a connection UUID as the argument to this:

#!/usr/bin/env python
import gi
gi.require_version('NM', '1.0')
from
gi.repository import GLib, NM
import sys

client = NM.Client.new(None)
c = client.get_connection_by_uuid(sys.argv[1])
wifi_secrets = c.get_secrets(NM.SETTING_WIRELESS_SECURITY_SETTING_NAME)
wifi_secrets_con = NM.SimpleConnection.new()
wifi_secrets_con.replace_settings(wifi_secrets)
wsec = wifi_secrets_con.get_setting_wireless_security()
print "%s" % wsec.get_psk()

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

Re: primary device changing from boot to boot

[Dan Williams]

On Tue, 2017-09-05 at 12:32 -0700, Tim Harvey wrote:
> On Tue, Sep 5, 2017 at 9:53 AM, Dan Williams <d...@redhat.com> wrote:
> > On Tue, 2017-09-05 at 09:38 -0700, Tim Harvey wrote:
> > > On Fri, Sep 1, 2017 at 1:22 PM, Dan Williams <d...@redhat.com>
> > > wrote:
> > > > On Fri, 2017-09-01 at 13:01 -0700, Tim Harvey wrote:
> > > > > Greetings,
> > > > > 
> > > > > I've got a Sierra Wireless HL7588 modem which exposes three
> > > > > ttyACM
> > > > > devs via the cdc_acm driver. The device appears to work fine
> > > > > with
> > > > > ModemManager (1.6.8) but occasionally mm detects the primary
> > > > > device
> > > > > as
> > > > > ttyACM2 instead of the usuall ttyACM0. In this case (detected
> > > > > primary
> > > > > AT interface of ttyACM2), if I've already configured
> > > > > NetworkManager
> > > > > to
> > > > > use /dev/ttyACM0 I can't bring up the modem.
> > > > 
> > > > NM has a "DeviceIdentifier" property on GSM connections partly
> > > > for
> > > > this
> > > > reason.  You cannot always guarantee that even if MM *did*
> > > > detect
> > > > the
> > > > first exposed TTY as primary, that it's going to be called
> > > > ttyACM0.
> > > > The kernel is free to name these things whatever it wants, and
> > > > if
> > > > ttyACM0 is already used it'll pick another one.  I've had this
> > > > happen
> > > > when some program holds the TTY open and the modem reboots.
> > > > 
> > > > So moral of the story is, don't depend on device names.
> > > > 
> > > > Get the MM device identifier from the modem:
> > > > 
> > > > dbus-send --print-reply --system --
> > > > dest=org.freedesktop.ModemManager1
> > > > /org/freedesktop/ModemManager1/Modem/0
> > > > org.freedesktop.DBus.Properties.Get
> > > > string:org.freedesktop.ModemManager1.Modem
> > > > string:DeviceIdentifier
> > > > 
> > > > and then set that string as the DeviceIdentifier in the
> > > > NetworkManager
> > > > connection for the modem.  That connection will then only ever
> > > > apply to
> > > > that specific modem.  You can then do things liek "nmcli con up
> > > > " and NM will figure out what device it should
> > > > use.
> > > > 
> > > 
> > > Dan,
> > > 
> > > This makes sense, but how do I configure NetworkManager to use
> > > the
> > > device-id? I don't see it as an available option for type gsm, so
> > > perhaps I need to edit the file in
> > > /etc/NetworkManager/system-connections/mymodem and add it to the
> > > 'gsm'
> > 
> > nmcli con mod  gsm.device-id \
> > 6909b49a4d44867387a2b09b8095c579e031874c
> > 
> > Or yeah, drop:
> > 
> > device-id=6909b49a4d44867387a2b09b8095c579e031874c
> > 
> > into the [gsm] section of the keyfile in
> > /etc/NetworkManager/system-
> > connections.
> > 
> 
> Using 'device-id' does not appear to not work, at least not in NM
> 1.2.6:

1.2.6 should have the right support.  Perhaps I didn't quite understand
what you were asking though.

device-id is useful if you have multiple modems on a system, or if you
swap modems between systems and want a connection to apply to a
specific device.

But your original question was about device naming, and ACM0 vs. ACM2. 
For some modems, it shouldn't matter what the interface name is.  So in
your case, you wouldn't do anything to "configured NetworkManager to
use /dev/ttyACM0", you'd simply set the device-id and then use the NM
connection name to start/stop things.  You wouldn't hardcode "nmcli dev
connect ttyACM0" or anything like that.

Instead you'd "nmcli con up Verizon" and the device-id would tell NM to
use the right device, no matter whether ACM0, ACM2, or USB3 or
whatever.

Basically, you don't want to hardcode tty device names ever, because
they can and do change.  So if you're doing that somewhere, I'd
recommend instead using the NM connection name, and device-id to make
sure the connection always applies to that specific modem.

Dan

> root@ventana:~# dbus-send --print-reply --system \
>    --dest=org.freedesktop.ModemManager1 \
>    /org/freedesktop/ModemManager1/Modem/0 \
>    org.freedesktop.DBus.Properties.Get \
>    string:org.freedesktop.Mode

Re: primary device changing from boot to boot

[Dan Williams]

On Tue, 2017-09-05 at 09:38 -0700, Tim Harvey wrote:
> On Fri, Sep 1, 2017 at 1:22 PM, Dan Williams <d...@redhat.com> wrote:
> > On Fri, 2017-09-01 at 13:01 -0700, Tim Harvey wrote:
> > > Greetings,
> > > 
> > > I've got a Sierra Wireless HL7588 modem which exposes three
> > > ttyACM
> > > devs via the cdc_acm driver. The device appears to work fine with
> > > ModemManager (1.6.8) but occasionally mm detects the primary
> > > device
> > > as
> > > ttyACM2 instead of the usuall ttyACM0. In this case (detected
> > > primary
> > > AT interface of ttyACM2), if I've already configured
> > > NetworkManager
> > > to
> > > use /dev/ttyACM0 I can't bring up the modem.
> > 
> > NM has a "DeviceIdentifier" property on GSM connections partly for
> > this
> > reason.  You cannot always guarantee that even if MM *did* detect
> > the
> > first exposed TTY as primary, that it's going to be called ttyACM0.
> > The kernel is free to name these things whatever it wants, and if
> > ttyACM0 is already used it'll pick another one.  I've had this
> > happen
> > when some program holds the TTY open and the modem reboots.
> > 
> > So moral of the story is, don't depend on device names.
> > 
> > Get the MM device identifier from the modem:
> > 
> > dbus-send --print-reply --system --
> > dest=org.freedesktop.ModemManager1
> > /org/freedesktop/ModemManager1/Modem/0
> > org.freedesktop.DBus.Properties.Get
> > string:org.freedesktop.ModemManager1.Modem string:DeviceIdentifier
> > 
> > and then set that string as the DeviceIdentifier in the
> > NetworkManager
> > connection for the modem.  That connection will then only ever
> > apply to
> > that specific modem.  You can then do things liek "nmcli con up
> > " and NM will figure out what device it should
> > use.
> > 
> 
> Dan,
> 
> This makes sense, but how do I configure NetworkManager to use the
> device-id? I don't see it as an available option for type gsm, so
> perhaps I need to edit the file in
> /etc/NetworkManager/system-connections/mymodem and add it to the
> 'gsm'

nmcli con mod  gsm.device-id \
6909b49a4d44867387a2b09b8095c579e031874c

Or yeah, drop:

device-id=6909b49a4d44867387a2b09b8095c579e031874c

into the [gsm] section of the keyfile in /etc/NetworkManager/system-
connections.

> section but maybe I've got larger issues because nm seems to not even
> like ttyACM0 for the interface:
> 
> root@ventana:~# mmcli -m 0
> 
> /org/freedesktop/ModemManager1/Modem/0 (device id
> '6909b49a4d44867387a2b09b8095c579e031874c')
>   -
>   Hardware |   manufacturer: 'Sierra Wireless'
>    |  model: 'HL7588'
>    |   revision:
> 'RHL75xx.V.3.7.151600.201702071034.x7160_1'
>    |  supported: 'gsm-umts, lte'
>    |current: 'gsm-umts, lte'
>    |   equipment id: '01428470452'
>   -
>   System   | device:
> '/sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-
> 1'
>    |drivers: 'cdc_acm, cdc_ncm'
>    | plugin: 'Generic'
>    |   primary port: 'ttyACM0'
>    |  ports: 'wwx11121314 (net), ttyACM0 (at),
> wwx11121316 (net), wwx1112131a (net), wwx11121318 (net),
> ttyACM2 (at)'
>   -
>   Numbers  |   own : '+19529136397'
>   -
>   Status   |   lock: 'none'
>    | unlock retries: 'unknown'
>    |  state: 'enabled'
>    |power state: 'on'
>    |access tech: 'unknown'
>    | signal quality: '0' (cached)
>   -
>   Modes|  supported: 'allowed: 2g, 3g, 4g; preferred: none'
>    |current: 'allowed: 2g, 3g, 4g; preferred: none'
>   -
>   Bands|  supported: 'unknown'
>    |current: 'unknown'
>   -
>   IP   |  supported: 'ipv4, ipv6, ipv4v6'
>   -
>   3GPP |   imei: '01428470452'
>    |  enabled locks: 'none'
>    |operator id: 'unknown'
>    |  operator name: 'unknown'
>    |   subscription: 'unknown'
>    |   registration: 'idle'
>   -
>   SIM  |   path: '/org/freedesktop/ModemManager1/SIM/0'
> 
>   -
>   Bearers  |  paths: 'none'
> 
> root@ventana:~# dbus-send --p

Re: [review] dcbw/wifi-scan: delegate connected scanning to wpa_supplicant

[Dan Williams]

On Tue, 2017-08-01 at 20:05 -0500, Dan Williams wrote:
> Hi,
> 
> Now that all of the major UI clients (GNOME Shell, KDE, nm-applet)
> have
> been updated to request scans when appropriate, stop NM from doing
> periodic scans while connected, preferring instead to let the
> supplicant decide when to scan based on signal strength thresholds. 
> This branch preserves the behavior of not scanning at all when the
> connection is locked to a single BSSID (via not sending "bgscan" to
> the
> supplicant config, and preventing all periodic scans when connected).
> 
> Explicitly requested scans are of course not prevented when
> connected.
> 
> Yeah, nm-applet should probably update itself asynchronously, like
> the
> OS X Airport menu, but at least it requests scans since 1.8 so it'll
> be
> updated the next time the menu is shown.
> 
> nm-applet has requested scans since 1.8, GNOME Shell's applet has
> requested scans since 3.23, and KDE's plasma-nm has requested scans
> since 5.8.95.  All these UIs were updated mid-April 2017.

Squashed, rebased, repushed; another cleanup added.  more details here:

https://bugzilla.gnome.org/show_bug.cgi?id=766482#c20

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

[review] dcbw/wifi-scan: delegate connected scanning to wpa_supplicant

[Dan Williams]

Hi,

Now that all of the major UI clients (GNOME Shell, KDE, nm-applet) have
been updated to request scans when appropriate, stop NM from doing
periodic scans while connected, preferring instead to let the
supplicant decide when to scan based on signal strength thresholds. 
This branch preserves the behavior of not scanning at all when the
connection is locked to a single BSSID (via not sending "bgscan" to the
supplicant config, and preventing all periodic scans when connected).

Explicitly requested scans are of course not prevented when connected.

Yeah, nm-applet should probably update itself asynchronously, like the
OS X Airport menu, but at least it requests scans since 1.8 so it'll be
updated the next time the menu is shown.

nm-applet has requested scans since 1.8, GNOME Shell's applet has
requested scans since 3.23, and KDE's plasma-nm has requested scans
since 5.8.95.  All these UIs were updated mid-April 2017.

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

Re: Huawei E5786

[Dan Williams]

On Fri, 2017-06-30 at 21:43 +0300, Juha Koskiniemi wrote:
> I got some progress. It is indeed NM fail. If I have do devices
> connected as need to be connected. 3G phone and then LTE modem. I
> command.modprobe -a option && echo "0x12d1 0x1506" >
> /sys/bus/usb-serial/drivers/option1/new_id and device show up then in
> Modem Manager. Then Modem Manager start to scan operators. Then in NM
> icon come up in NM menu as it was previously transparent. I even some
> point was able to send #99* USSD and get connected to home network as
> previously it stays unconnected what ever you made. This I could not
> reproduce. What kind of logs to look at. What can cause such a
> sequence? This modem is very much up to date and for sure there is
> interest to connect other too. How I can add modbrobe in boot up?

If the modem is not recognized by the kernel drivers, then it will be
unavailable to ModemManager and NetworkManager as a WWAN device.  The
solution to that issue is to get the USB device IDs added to the right
kernel driver.

Most Huawei devices are matched either by 'option' or by interface
info.  The full dump of "lsusb -v -d 12d1:1506" would be useful so we
can figure out what driver the device should be using.

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

[Dan Williams]

On Tue, 2017-06-13 at 16:13 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Tuesday, June 06, 2017 10:10 AM
> > To: Matthew Starr; networkmanager-list@gnome.org
> > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > 
> > On Wed, 2017-05-31 at 19:50 +, Matthew Starr wrote:
> > > Now it is back to reconnecting every time when the AP is back in
> > > range
> > > after an hour of it being out of range.  Here are the logs for
> > > when it
> > > is working with the latest debug patch.  At 19:35:02 it failed to
> > > connect because I forgot to reattach the antenna, but it
> > > connected
> > > okay 30 seconds later when the antenna was connected.
> > > 
> > > Let me know what you would like to try next.
> > 
> > FYI I haven't forgotten about this, I hope to send a new test patch
> > today.
> > 
> > Dan
> > 
> 
> Dan,
> 
> Thanks for all your help so far.  Have you got a chance to generate a
> new patch?

Attached... same drill.

Thanks!
Dandiff --git a/src/devices/nm-device.c b/src/devices/nm-device.c
index bc7ebcb..423cc74 100644
--- a/src/devices/nm-device.c
+++ b/src/devices/nm-device.c
@@ -2150,7 +2150,10 @@ can_auto_connect (NMDevice *self,
 
 	s_con = nm_connection_get_setting_connection (connection);
 	if (!nm_setting_connection_get_autoconnect (s_con))
+{
+//	nm_log_info (LOGD_DEVICE, " (%s) [device] not autoconnect", nm_device_get_iface (self));
 		return FALSE;
+}
 
 	return nm_device_check_connection_available (self, connection, NM_DEVICE_CHECK_CON_AVAILABLE_NONE, NULL);
 }
@@ -7765,24 +7768,40 @@ nm_device_check_connection_available (NMDevice *self,
   const char *specific_object)
 {
 	NMDeviceState state;
+	gboolean avail;
 
 	state = nm_device_get_state (self);
 	if (state < NM_DEVICE_STATE_UNMANAGED)
+{
+//	nm_log_info (LOGD_DEVICE, " (%s) [device] < unmanaged", nm_device_get_iface (self));
 		return FALSE;
+}
 	if (   state < NM_DEVICE_STATE_UNAVAILABLE
 	&& nm_device_get_unmanaged_flag (self, NM_UNMANAGED_ALL & ~NM_UNMANAGED_DEFAULT))
+{
+//	nm_log_info (LOGD_DEVICE, " (%s) [device] < unavailable", nm_device_get_iface (self));
 		return FALSE;
+}
 	if (   state < NM_DEVICE_STATE_DISCONNECTED
 	&& (   (   !NM_FLAGS_HAS (flags, _NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_WAITING_CARRIER)
 	&& !nm_device_is_available (self, NM_DEVICE_CHECK_DEV_AVAILABLE_NONE))
 	|| (NM_FLAGS_HAS (flags, _NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST_WAITING_CARRIER)
 	&& !nm_device_is_available (self, NM_DEVICE_CHECK_DEV_AVAILABLE_IGNORE_CARRIER
+{
+//	nm_log_info (LOGD_DEVICE, " (%s) [device] < disconnected", nm_device_get_iface (self));
 		return FALSE;
+}
 
 	if (!nm_device_check_connection_compatible (self, connection))
+{
+//	nm_log_info (LOGD_DEVICE, " (%s) [device] incompatible with device", nm_device_get_iface (self));
 		return FALSE;
+}
 
-	return NM_DEVICE_GET_CLASS (self)->check_connection_available (self, connection, flags, specific_object);
+	avail = NM_DEVICE_GET_CLASS (self)->check_connection_available (self, connection, flags, specific_object);
+	if (!avail)
+	nm_log_info (LOGD_DEVICE, " (%s) [device] connection not available", nm_device_get_iface (self));
+	return avail;
 }
 
 static void
diff --git a/src/devices/wifi/nm-device-wifi.c b/src/devices/wifi/nm-device-wifi.c
index 0f7fb6e..0dc53b9 100644
--- a/src/devices/wifi/nm-device-wifi.c
+++ b/src/devices/wifi/nm-device-wifi.c
@@ -777,53 +777,84 @@ check_connection_compatible (NMDevice *device, NMConnection *connection)
 	const char *perm_hw_addr;
 
 	if (!NM_DEVICE_CLASS (nm_device_wifi_parent_class)->check_connection_compatible (device, connection))
+{
+//	nm_log_info (LOGD_DEVICE, " (%s) [wifi compat] parent fail", nm_device_get_iface (device));
 		return FALSE;
+}
 
 	s_con = nm_connection_get_setting_connection (connection);
 	g_assert (s_con);
 
 	if (strcmp (nm_setting_connection_get_connection_type (s_con), NM_SETTING_WIRELESS_SETTING_NAME))
+{
+//	nm_log_info (LOGD_DEVICE, " (%s) [wifi compat] not wifi", nm_device_get_iface (device));
 		return FALSE;
+}
 
 	s_wireless = nm_connection_get_setting_wireless (connection);
 	if (!s_wireless)
+{
+//	nm_log_info (LOGD_DEVICE, " (%s) [wifi compat] no wireless setting", nm_device_get_iface (device));
 		return FALSE;
+}
 
 	perm_hw_addr = nm_device_get_permanent_hw_address (device);
 	mac = nm_setting_wireless_get_mac_address (s_wireless);
 	if (perm_hw_addr) {
 		if (mac && !nm_utils_hwaddr_matches (mac, 

Re: MC7455 'Call Failed'

[Dan Williams]

On Thu, 2017-06-22 at 15:11 -0700, Tim Harvey wrote:
> On Thu, Jun 22, 2017 at 2:59 PM, Dan Williams <d...@redhat.com>
> wrote:
> > On Thu, 2017-06-22 at 23:29 +0200, Aleksander Morgado wrote:
> > > On Thu, Jun 22, 2017 at 10:11 PM, Tim Harvey <tharvey@gateworks.c
> > > om>
> > > wrote:
> > > > > > Also, I'm unclear how to NetworkManager on the QMI devices:
> > > > > > root@ventana:~# nmcli connection add type gsm ifname cdc-
> > > > > > wdm1
> > > > > > con-name
> > > > > > mc7455 apn h2g2
> > > > > > Connection 'mc7455' (5dc4516e-e857-4917-9542-0dee211b692a)
> > > > > > successfully added.
> > > > > > root@ventana:~# nmcli connection up id mc7455
> > > > > > Error: Connection activation failed: No suitable device
> > > > > > found
> > > > > > for this
> > > > > > connection.
> > > > > > 
> > > > > > What is the appropriate interface to use for QMI devices
> > > > > > (wwan1
> > > > > > gives
> > > > > > the same error)? This is supposed to be the 'control
> > > > > > interface'
> > > > > > not
> > > > > > the 'network interface' correct?
> > > > > > 
> > > > > 
> > > > > Retry without the "ifname cdc-wdm1" part; just add a gsm
> > > > > connection
> > > > > type with the APN settings, without binding to an explicit
> > > > > modem,
> > > > > and
> > > > > try to get that connected.
> > > > 
> > > > I tried that originally but it requires ifname:
> > > > 
> > > > root@ventana:~# nmcli connection add type gsm con-name mc7455
> > > > apn
> > > > h2g2
> > > > Error: mandatory 'ifname' not seen before 'apn'.
> > > 
> > > Dan, Thomas? I keep forgetting about this... How do you create a
> > > connection not bound to any device? And, how do yo create a
> > > connection
> > > bound to a given device/sim?
> > 
> > I filed a bug on that:
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=780323
> > 
> > Dan
> 
> Dan, it looks like network manager ignores the 'interface-name' param
> in the connection configs as I have an MC7354 here that I was able to
> use fine with NetworkManager by giving it 'ifname cdc-wdm0' (which is
> wrong)
> 
> On the MC7354:
> root@ventana:~# nmcli connection down id 'Wired connection 1'
> Connection 'Wired connection 1' successfully deactivated (D-Bus
> active
> path: /org/freedesktop/NetworkManager/ActiveConnection/1)
> root@ventana:~# nmcli connection add type gsm ifname cdc-wdm0 con-
> name
> mc7354 apn m2m.com.attz
> Connection 'mc7354' (6d89ff6e-6eb6-4f0f-80d1-fb081165f710)
> successfully added.
> # show status
> root@ventana:~# nmcli connection show
> NAMEUUID  TYPE   
>  DEVICE
> Wired connection 1  ea640ea4-3049-39e4-9cdf-a5e53971ced8  802-3-
> ethernet  --
> mc7354  6d89ff6e-6eb6-4f0f-80d1-
> fb081165f710  gsm --
> # connect
> root@ventana:~# nmcli connection up id mc7354
> [  305.557465] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
> Error: Connection activation failed: Active connection could not be
> attached to the device
> ^ not sure what this is from - the connection is made and traffic
> works
> [  305.688145] systemd-journald[162]: Successfully sent stream file
> descriptor to service manager.
> [  305.774230] systemd-journald[162]: Successfully sent stream file
> descriptor to service manager.
> root@ventana:~# ping www.google.com
> ^ works
> 
> I'm still not clear why using network-manager fails on the MC7455
> which I can get working with libqmi directly and with modemmanager
> directly:
> 
> On the MC7455:
> root@ventana:~# nmcli connection down 'Wired connection 1'
> Connection 'Wired connection 1' successfully deactivated (D-Bus
> active
> path: /org/freedesktop/NetworkManager/ActiveConnection/1)
> [   44.722377] systemd-journald[168]: Successfully sent stream file
> descriptor to service manager.
> root@ventana:~# nmcli connection add type gsm ifname cdc-wdm0 con-
> name
> mc7455 apn h2g2
> Connection 'mc7455' (426c0811-1f1e-439b-b497-b839502c6a4f)
> successfully added.
> root@ventana:~# nmcli connection up id mc7455
> Error: Connection activation failed: No suitable device found for
> this
> connection.
>  No IP config on wwan0

Yeah, because "no suitable device found".  Can you 'nmcli g log level
trace' and reproduce the issue, then we can take a look at the NM logs.
 Depending on your platform, that could be "journalctl -b -u
NetworkManager" or they could be files somewhere in /var/log like
/var/log/daemon.log, /var/log/NetworkManager.log, or /var/log/messages.

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

Re: MC7455 'Call Failed'

[Dan Williams]

On Thu, 2017-06-22 at 23:29 +0200, Aleksander Morgado wrote:
> On Thu, Jun 22, 2017 at 10:11 PM, Tim Harvey 
> wrote:
> > > > Also, I'm unclear how to NetworkManager on the QMI devices:
> > > > root@ventana:~# nmcli connection add type gsm ifname cdc-wdm1
> > > > con-name
> > > > mc7455 apn h2g2
> > > > Connection 'mc7455' (5dc4516e-e857-4917-9542-0dee211b692a)
> > > > successfully added.
> > > > root@ventana:~# nmcli connection up id mc7455
> > > > Error: Connection activation failed: No suitable device found
> > > > for this
> > > > connection.
> > > > 
> > > > What is the appropriate interface to use for QMI devices (wwan1
> > > > gives
> > > > the same error)? This is supposed to be the 'control interface'
> > > > not
> > > > the 'network interface' correct?
> > > > 
> > > 
> > > Retry without the "ifname cdc-wdm1" part; just add a gsm
> > > connection
> > > type with the APN settings, without binding to an explicit modem,
> > > and
> > > try to get that connected.
> > 
> > I tried that originally but it requires ifname:
> > 
> > root@ventana:~# nmcli connection add type gsm con-name mc7455 apn
> > h2g2
> > Error: mandatory 'ifname' not seen before 'apn'.
> 
> Dan, Thomas? I keep forgetting about this... How do you create a
> connection not bound to any device? And, how do yo create a
> connection
> bound to a given device/sim?

I filed a bug on that:

https://bugzilla.gnome.org/show_bug.cgi?id=780323

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

[Dan Williams]

On Wed, 2017-05-31 at 19:50 +, Matthew Starr wrote:
> Now it is back to reconnecting every time when the AP is back in
> range after an hour of it being out of range.  Here are the logs for
> when it is working with the latest debug patch.  At 19:35:02 it
> failed to connect because I forgot to reattach the antenna, but it
> connected okay 30 seconds later when the antenna was connected.
> 
> Let me know what you would like to try next.

FYI I haven't forgotten about this, I hope to send a new test patch
today.

Dan

> -Matt
> 
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Wednesday, May 31, 2017 11:23 AM
> > To: Matthew Starr; networkmanager-list@gnome.org
> > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > 
> > Another round, getting closer...
> > 
> > Dan
> > 
> > On Wed, 2017-05-31 at 14:10 +, Matthew Starr wrote:
> > > > -Original Message-
> > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > Sent: Tuesday, May 30, 2017 1:42 PM
> > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > > > 
> > > > Ok another patch attached.  Same as last patch, but it comments
> > > > out
> > > > a bunch of the debug logging.  It should point us in the right
> > > > direction at least.
> > > > 
> > > > Dan
> > > > 
> > > 
> > > Now the issue is occurring again and I was able to capture the
> > > attached log messages from syslog.  You can see network manager
> > > detecting the network I want to connect to "HED.Inc.Wifi", it
> > > shows it
> > > as a compatible connection, it lists it under the autoactivate
> > > candidates, but then never connects.
> > > 
> > > -Matt
> > > 
> > > > On Tue, 2017-05-30 at 16:19 +, Matthew Starr wrote:
> > > > > > -Original Message-
> > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > Sent: Thursday, May 25, 2017 11:25 PM
> > > > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > > > > > 
> > > > > > On Thu, 2017-05-25 at 22:00 +, Matthew Starr wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > > > Sent: Thursday, May 25, 2017 12:49 PM
> > > > > > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect
> > > > > > > > Issues
> > > > > > > > 
> > > > > > > > On Thu, 2017-05-25 at 13:06 +, Matthew Starr wrote:
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > > > > > Sent: Wednesday, May 24, 2017 3:26 PM
> > > > > > > > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > > > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi
> > > > > > > > > > Autoconnect
> > > > > > > > > > Issues
> > > > > > > > > > 
> > > > > > > > > > On Wed, 2017-05-24 at 18:22 +, Matthew Starr
> > > > > > > > > > wrote:
> > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > > > > > > > Sent: Wednesday, May 24, 2017 12:48 PM
> > > > > > > > > > > > To: Matthew Starr; networkmanager-l...@gnome.or
> > > > > > > > > > > > g
> > > > > > > > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi
> > > > > > > > > > > > Autoconnect
> > > > > > > > > > > > Issues
> > > > > > > > > > > > 
> > > > > > > > > > > > On Thu, 2017-05-18 at 22:25 +, Matthew
> > > > > > > > > > > > Starr
> > > > > 

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

[Dan Williams]

Another round, getting closer...

Dan

On Wed, 2017-05-31 at 14:10 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Tuesday, May 30, 2017 1:42 PM
> > To: Matthew Starr; networkmanager-list@gnome.org
> > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > 
> > Ok another patch attached.  Same as last patch, but it comments out
> > a bunch
> > of the debug logging.  It should point us in the right direction at
> > least.
> > 
> > Dan
> > 
> 
> Now the issue is occurring again and I was able to capture the
> attached log messages from syslog.  You can see network manager
> detecting the network I want to connect to "HED.Inc.Wifi", it shows
> it as a compatible connection, it lists it under the autoactivate
> candidates, but then never connects.
> 
> -Matt
> 
> > On Tue, 2017-05-30 at 16:19 +, Matthew Starr wrote:
> > > > -Original Message-
> > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > Sent: Thursday, May 25, 2017 11:25 PM
> > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > > > 
> > > > On Thu, 2017-05-25 at 22:00 +, Matthew Starr wrote:
> > > > > > -Original Message-
> > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > Sent: Thursday, May 25, 2017 12:49 PM
> > > > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > > > > > 
> > > > > > On Thu, 2017-05-25 at 13:06 +, Matthew Starr wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > > > Sent: Wednesday, May 24, 2017 3:26 PM
> > > > > > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect
> > > > > > > > Issues
> > > > > > > > 
> > > > > > > > On Wed, 2017-05-24 at 18:22 +, Matthew Starr wrote:
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > > > > > Sent: Wednesday, May 24, 2017 12:48 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 22:25 +, Matthew Starr
> > > > > > > > > > wrote:
> > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > > > > > > > Sent: Thursday, May 18, 2017 4:55 PM
> > > > > > > > > > > > To: Matthew Starr; networkmanager-l...@gnome.or
> > > > > > > > > > > > g
> > > > > > > > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi
> > > > > > > > > > > > Autoconnect
> > > > > > > > > > > > Issues
> > > > > > > > > > > > 
> > > > > > > > > > > > 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@gnom
> > > > > > > > > > > > > > e.or
> > > > > > > > > > > > > > g
> > > > > > > > > > > > > > Subject: Re: Network Manager 1.0.

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

[Dan Williams]

Ok another patch attached.  Same as last patch, but it comments out a
bunch of the debug logging.  It should point us in the right direction
at least.

Dan

On Tue, 2017-05-30 at 16:19 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Thursday, May 25, 2017 11:25 PM
> > To: Matthew Starr; networkmanager-list@gnome.org
> > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > 
> > On Thu, 2017-05-25 at 22:00 +, Matthew Starr wrote:
> > > > -Original Message-
> > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > Sent: Thursday, May 25, 2017 12:49 PM
> > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > > > 
> > > > On Thu, 2017-05-25 at 13:06 +, Matthew Starr wrote:
> > > > > > -Original Message-
> > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > Sent: Wednesday, May 24, 2017 3:26 PM
> > > > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > > > > > 
> > > > > > On Wed, 2017-05-24 at 18:22 +, Matthew Starr wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > > > Sent: Wednesday, May 24, 2017 12:48 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 22:25 +, Matthew Starr wrote:
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > > > > > Sent: Thursday, May 18, 2017 4:55 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 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-l...@gnome.or
> > > > > > > > > > > > g
> > > > > > > > > > > > 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@gnom
> > > > > > > > > > > > > > e.or
> > > > > > > > > > > > > > g
> > > > > > > > > > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi
> > > > > > > > > > > > > > Autoconnect Issues
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > On Thu, 2017-05-18 at 15:54 +, Matthew
> > > > > > > > > > > > > > Starr
> > > > > > > > > > > > > > wrote:
> > > > > > > > > >

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

[Dan Williams]

On Thu, 2017-05-25 at 22:00 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Thursday, May 25, 2017 12:49 PM
> > To: Matthew Starr; networkmanager-list@gnome.org
> > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > 
> > On Thu, 2017-05-25 at 13:06 +, Matthew Starr wrote:
> > > > -Original Message-
> > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > Sent: Wednesday, May 24, 2017 3:26 PM
> > > > To: Matthew Starr; networkmanager-list@gnome.org
> > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > > > 
> > > > On Wed, 2017-05-24 at 18:22 +, Matthew Starr wrote:
> > > > > > -Original Message-
> > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > Sent: Wednesday, May 24, 2017 12:48 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 22:25 +, Matthew Starr wrote:
> > > > > > > > -Original Message-
> > > > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > > > Sent: Thursday, May 18, 2017 4:55 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 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-l...@gnome.or
> > > > > > > > > > > > g
> > > > > > > > > > > > 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
> >

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

[Dan Williams]

On Thu, 2017-05-25 at 13:06 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Wednesday, May 24, 2017 3:26 PM
> > To: Matthew Starr; networkmanager-list@gnome.org
> > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> > 
> > On Wed, 2017-05-24 at 18:22 +, Matthew Starr wrote:
> > > > -Original Message-
> > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > Sent: Wednesday, May 24, 2017 12:48 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 22:25 +, Matthew Starr wrote:
> > > > > > -Original Message-
> > > > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > > > Sent: Thursday, May 18, 2017 4:55 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 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
> > > > > > > > > >

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

[Dan Williams]

On Wed, 2017-05-24 at 18:22 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Wednesday, May 24, 2017 12:48 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 22:25 +, Matthew Starr wrote:
> > > > -Original Message-
> > > > From: Dan Williams [mailto:d...@redhat.com]
> > > > Sent: Thursday, May 18, 2017 4:55 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 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 ti

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

[Dan Williams]

On Thu, 2017-05-18 at 22:25 +, Matthew Starr wrote:
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Thursday, May 18, 2017 4:55 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 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  > > > > > to
> > > > > > 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).
>

Re: ModemManager mmcli

[Dan Williams]

On Fri, 2017-05-19 at 12:47 -0600, Phil Daum wrote:
> Hi Dan,
> 
> We are trying to operate GPS routing application using:  mmcli -m 0
> --location-get
> 
> We are issuing the command once per second, and have noticed some
> failures
> where the command either fails or provides no data:

Can you run:

mmcli -G DEBUG

and then reproduce the problem?  That'll get debug logs which will be
much more useful.

Also, the output of 'mmcli -m 0' would be good when the problem
happens, so we can see what state it's in.  Feel free to  out
sensitive stuff like your IMEI, phone #, etc.

Dan

> cr044# mmcli -m 0 --location-get
> 
> /org/freedesktop/ModemManager1/Modem/0
>   -
>   3GPP location   | Mobile country code: '302'
>   | Mobile network code: '610'
>   |  Location area code: '11204'
>   | Cell ID: '79330668'
>   -
>   GPS NMEA traces | Not available
>   -
>   Raw GPS | Not available
>   -
>   CDMA BS | Not available
> cr044 [mmcli -m 0 --location-get] ~
> 
> I've attached the journal and status and see there is quite a bit of
> activity involving several client ID's.  The status shows our attempt
> to
> restart the service via: systemctl restart ModemManager seems to give
> an
> error of:
> 
> QMI protocol error (14): 'CallFailed'
> 
> I was wondering if this is an acceptable way of obtaining this GPS
> info and
> if the attached logs give an obvious reason for our failure.
> 
> Thanks in advance,
> Phil
> ___
> 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: Network Manager 1.0.X Wi-Fi Autoconnect Issues

[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

[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-

Re: ModemManager (qmi_wann / qcserial) and gpsd

[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

[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: Modem Manager stuck in a loop, ppp can't connect.

[Dan Williams]

On Wed, 2017-05-10 at 14:25 -0500, Dan Williams wrote:
> On Wed, 2017-05-10 at 14:21 -0400, A. F. Cano wrote:
> > On Mon, May 08, 2017 at 09:27:23AM -0500, Dan Williams wrote:
> > > ...
> > > Does the modem reply to AT+CSS with valid SID/NID values now, or
> > > still
> > > "?, 0"?
> > 
> > Interesting...
> > 
> > +CSS: ?, 22
> > 
> > OK
> 
> The device is using an early form of AT+CSS, which reports only the
> CDMA System ID, which is 22.  This means the modem has registered
> with
> the network correctly and we can most likely do packet data.  If it
> reports '0' then it's assumed that it hasn't successfully gotten
> registration far enough for data.

Ok, this phone is as dumb as a brick.

I bought one off eBay and captured the USB traffic in Verizon Access
Manager in Windows.  The only things VZAM bothers to send are AT+CAD,
AT+CSQ, various GMM/GMR/GMI to get the device and firmware version,
AT+GSN for the ESN, and AT+CBC to get battery charge.  That's about it.
 Connection is #777 as usual for CDMA.

So we need to make a Motorola CDMA plugin for the e8xx phones that
bypasses the AT+CSS check entirely, and just lets the connection
proceed.  I was unable to get a usable response to AT+CSS.  I did
verify that AT+MODE=2 and AT+CIND? return roaming and service status,
so we could possibly use that instead of just ignoring AT+CSS.

Either way, this phone needs a new plugin.

Dan

> > When connecting to the modem (with kermit) echo was off so my
> > command
> > isn't visible, but it did return the above.  What does the 22 mean
> > or
> > imply?
> > 
> > I have also noticed these warnings:
> > 
> > May  6 19:12:40 fbx ModemManager[277]:   Could not get
> > service
> > status: No AT port available to run command
> > May  6 19:13:10 fbx ModemManager[277]:   Could not get
> > service
> > status: No AT port available to run command
> > May  6 19:13:40 fbx ModemManager[277]:   Could not get
> > service
> > status: No AT port available to run command
> > May  6 19:14:10 fbx ModemManager[277]:   Could not get
> > service
> > status: No AT port available to run command
> 
> The modem only has one serial port, and that's taken by PPP when the
> data connection is active.  This means there's no port available to
> run
> the status commands.  But it's a bug this is printed at a  log
> level rather than  or something like that.  Anyway, the
> message
> is expected and harmless.
> 
> > And they keep repeating every 30 seconds.
> > 
> > I have encountered this the last time I connected.  The ppp
> > connection
> > was working fine but this message kept repeating the whole time the
> > connection was up:
> > 
> > May  9 21:02:06 fbx NetworkManager[379]: g_signal_emit_valist:
> > assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> > May  9 21:02:07 fbx NetworkManager[379]: instance with invalid
> > (NULL)
> > class pointer
> 
> This would be a bug in NetworkManager.  Any chance that, when this
> happens, you could 'gdb attach ', then 'break
> g_log', then 'continue'.  Then next time it breaks out to the '(gdb)'
> prompt, run "t a a bt" to get a backtrace.  That will likely tell us
> where the issue is.
> 
> Dan
> 
> > May  9 21:02:07 fbx NetworkManager[379]: g_signal_emit_valist:
> > assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> > May  9 21:02:08 fbx NetworkManager[379]: instance with invalid
> > (NULL)
> > class pointer
> > May  9 21:02:08 fbx NetworkManager[379]: g_signal_emit_valist:
> > assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> > May  9 21:02:09 fbx NetworkManager[379]: instance with invalid
> > (NULL)
> > class pointer
> > May  9 21:02:09 fbx NetworkManager[379]: g_signal_emit_valist:
> > assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> > May  9 21:02:11 fbx NetworkManager[379]: instance with invalid
> > (NULL)
> > class pointer
> > May  9 21:02:11 fbx NetworkManager[379]: g_signal_emit_valist:
> > assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> > May  9 21:02:12 fbx NetworkManager[379]: instance with invalid
> > (NULL)
> > class pointer
> > May  9 21:02:12 fbx NetworkManager[379]: g_signal_emit_valist:
> > assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> > May  9 21:02:13 fbx NetworkManager[379]: instance with invalid
> > (NULL)
> > class pointer
> > May  9 21:02:13 fbx NetworkManager[379]: g_signal_emit_valist:
> > assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> > May  9 21:02:14 fbx NetworkManager[379]: instance with invalid
> > (

Re: DHCP lease renewing but not being assigned to device

[Dan Williams]

On Tue, 2017-05-09 at 09:20 -0400, John Adam Cutchin wrote:
> He folks,
> 
> I'm having some trouble with a Fedora 25 machine using
> NetworkManager.
> The DHCP lease from my ISP expires after two hours, and when it
> happens my internet goes down. The device is still up, but it shows
> no
> IP address.
> 
> It looks like dhclient attempted to renew the lease (the lease file
> shows two (or maybe four?) leases) but the device has no inet4
> address. All the leases showed my current and correct IP address.
> Other than the dates, there's no real difference between them.
> 
> The info below was captured when it was in the "bad" state, where I
> had no ip address. "nmcli con up enp5s0" fixes it.
> 
> Below I've included the time in UTC (to correlate with leases), the
> lease file, the state of the device according to ip, the device
> configuration in /etc/sysconfig, and the contents of "nmcli
> connection
> show enp5s0", some additional logging, software versions, etc.
> 
> It's a headless server, there's no graphical desktop running.
> Everything should be controlled by NetworkManager.
> 
> Could anyone please suggest something to stop this from happening, or
> some additional places I could look for the root cause?

Could you grab a bit more logging?  Try:

nmcli g log level trace

and then get the problem to happen again.  That'll dump a *ton* of info
to 'journalctl -b -u NetworkManager', but that's the useful info we
want to help debug the issue.

Once you've reproduced it, you can "nmcli g log level info" to get
logging back to normal.

Thanks!
Dan


> Thanks,
> Adam
> 
> 
> $ cat /etc/fedora-release
> Fedora release 25 (Twenty Five)
> 
> $ rpm -qa | grep NetworkManager
> NetworkManager-1.4.4-4.fc25.x86_64
> NetworkManager-libnm-1.4.4-4.fc25.x86_64
> NetworkManager-tui-1.4.4-4.fc25.x86_64
> NetworkManager-vpnc-1.2.4-1.fc25.x86_64
> NetworkManager-team-1.4.4-4.fc25.x86_64
> 
> 
> $ date -u
> UTC Mon May  8 15:53:01 UTC 2017
> 
> $ ip add show enp5s0:
> 
> enp5s0:  mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
> link/ether 80:ee:73:77:d1:ad brd ff:ff:ff:ff:ff:ff
> inet6 fe80::b9a0:1e03:a05b:4bd5/64 scope link
>    valid_lft forever preferred_lft forever
> 
> $ cat /var/lib/NetworkManager/dhclient-b34d4f03-56b4-4597-a454-
> 57bd4f7b4f3d-enp5s0.lease
> default-duid "\000\004l\025DS\375xG\301\24301o\312e\022\253";
> lease {
>   interface "enp5s0";
>   fixed-address ;
>   option subnet-mask 255.255.255.0;
>   option dhcp-lease-time 7200;
>   option routers ;
>   option dhcp-message-type 5;
>   option dhcp-server-identifier ;
>   option domain-name-servers ;
>   option domain-name "";
>   renew 1 2017/05/08 14:34:14;
>   rebind 1 2017/05/08 15:31:23;
>   expire 1 2017/05/08 15:46:23;
> }
> lease {
>   interface "enp5s0";
>   fixed-address ;
>   option subnet-mask 255.255.255.0;
>   option routers ;
>   option dhcp-lease-time 7200;
>   option dhcp-message-type 5;
>   option domain-name-servers ;
>   option dhcp-server-identifier ;
>   option domain-name "";
>   renew 1 2017/05/08 14:38:18;
>   rebind 1 2017/05/08 15:37:01;
>   expire 1 2017/05/08 15:52:01;
> }
> lease {
>   interface "enp5s0";
>   fixed-address ;
>   option subnet-mask 255.255.255.0;
>   option routers ;
>   option dhcp-lease-time 7200;
>   option dhcp-message-type 5;
>   option domain-name-servers ;
>   option dhcp-server-identifier ;
>   option domain-name "";
>   renew 1 2017/05/08 15:33:09;
>   rebind 1 2017/05/08 16:23:18;
>   expire 1 2017/05/08 16:38:18;
> }
> lease {
>   interface "enp5s0";
>   fixed-address ;
>   option subnet-mask 255.255.255.0;
>   option routers ;
>   option dhcp-lease-time 7200;
>   option dhcp-message-type 5;
>   option domain-name-servers ;
>   option dhcp-server-identifier ;
>   option domain-name "";
>   renew 1 2017/05/08 16:26:14;
>   rebind 1 2017/05/08 17:18:09;
>   expire 1 2017/05/08 17:33:09;
> }
> 
> $ cat /etc/sysconfig/network-scripts/ifcfg-enp5s0
> HWADDR=
> TYPE=Ethernet
> BOOTPROTO=dhcp
> DNS1=
> DNS2=
> DEFROUTE=yes
> IPV4_FAILURE_FATAL=no
> IPV4_ROUTE_METRIC=100
> IPV4_DNS_PRIORITY=100
> IPV6INIT=yes
> IPV6_AUTOCONF=no
> IPV6_DEFROUTE=yes
> IPV6_FAILURE_FATAL=no
> IPV6_ADDR_GEN_MODE=stable-privacy
> IPV6_DNS_PRIORITY=100
> NAME=enp5s0
> UUID=b34d4f03-56b4-4597-a454-57bd4f7b4f3d
> DEVICE=enp5s0
> ONBOOT=yes
> ZONE=public
> PEERDNS=yes
> PEERROUTES=yes
> 
> $ nmcli sho con enp50
> 
> connection.id:  enp5s0
> connection.uuid:b34d4f03-56b4-4597-a454-
> 57bd4f7b4f3d
> connection.stable-id:   --
> connection.interface-name:  enp5s0
> connection.type:802-3-ethernet
> connection.autoconnect: yes
> connection.autoconnect-priority:0
> connection.timestamp:   1494258511
> connection.read-only:   no
> connection.permissions:
> connection.zone:public
> connection.master:  

Re: Modem Manager stuck in a loop, ppp can't connect.

[Dan Williams]

On Wed, 2017-05-10 at 14:21 -0400, A. F. Cano wrote:
> On Mon, May 08, 2017 at 09:27:23AM -0500, Dan Williams wrote:
> > ...
> > Does the modem reply to AT+CSS with valid SID/NID values now, or
> > still
> > "?, 0"?
> 
> Interesting...
> 
> +CSS: ?, 22
> 
> OK

The device is using an early form of AT+CSS, which reports only the
CDMA System ID, which is 22.  This means the modem has registered with
the network correctly and we can most likely do packet data.  If it
reports '0' then it's assumed that it hasn't successfully gotten
registration far enough for data.

> When connecting to the modem (with kermit) echo was off so my command
> isn't visible, but it did return the above.  What does the 22 mean or
> imply?
> 
> I have also noticed these warnings:
> 
> May  6 19:12:40 fbx ModemManager[277]:   Could not get service
> status: No AT port available to run command
> May  6 19:13:10 fbx ModemManager[277]:   Could not get service
> status: No AT port available to run command
> May  6 19:13:40 fbx ModemManager[277]:   Could not get service
> status: No AT port available to run command
> May  6 19:14:10 fbx ModemManager[277]:   Could not get service
> status: No AT port available to run command

The modem only has one serial port, and that's taken by PPP when the
data connection is active.  This means there's no port available to run
the status commands.  But it's a bug this is printed at a  log
level rather than  or something like that.  Anyway, the message
is expected and harmless.

> And they keep repeating every 30 seconds.
> 
> I have encountered this the last time I connected.  The ppp
> connection
> was working fine but this message kept repeating the whole time the
> connection was up:
> 
> May  9 21:02:06 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:07 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer

This would be a bug in NetworkManager.  Any chance that, when this
happens, you could 'gdb attach ', then 'break
g_log', then 'continue'.  Then next time it breaks out to the '(gdb)'
prompt, run "t a a bt" to get a backtrace.  That will likely tell us
where the issue is.

Dan

> May  9 21:02:07 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:08 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:08 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:09 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:09 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:11 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:11 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:12 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:12 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:13 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:13 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:14 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:14 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:15 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:15 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:16 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:16 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:17 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:17 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:18 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:18 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:19 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:19 fbx NetworkManager[379]: g_signal_emit_valist:
> assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
> May  9 21:02:20 fbx NetworkManager[379]: instance with invalid (NULL)
> class pointer
> May  9 21:02:20 f

Re: Pointers for configuring vpn please

[Dan Williams]

On Wed, 2017-05-10 at 18:03 +0100, Colin Helliwell wrote:
> > On 10 May 2017 at 16:04 Dan Williams <d...@redhat.com> wrote:
> > 
> > 
> > Yes, the pptp package, typically obtained from your distro or from:
> > 
> > http://pptpclient.sourceforge.net/
> > 
> > Dan
> 
> Sorry to be a pain, but are you able to quickly tell me what binary
> it's actually looking for? I think I've installed the pptp package -
> I have /usr/bin/pptp (v1.9.0), but still getting 'could not find
> binary'...

It looks in:

static const char *pptp_binary_paths[] =
{
"/sbin/pptp",
"/usr/sbin/pptp",
"/usr/local/sbin/pptp",
NULL
};

Dan


> My NM connection is:
> 
> [connection]
> id=vpn-pptp
> uuid=5a2d1600-dead-babe-ac21-d8a5e1f0f8c5
> type=vpn
> autoconnect=false
> permissions=
> 
> [vpn]
> service-type=org.freedesktop.NetworkManager.pptp
> gateway=GATEWAYIP
> user=MYUSERNAME
> password-flags=0
> 
> [vpn-secrets]
> password=MYPASSWORD
> 
> [ipv4]
> dns-search=
> method=auto
> 
> [ipv6]
> addr-gen-mode=stable-privacy
> dns-search=
> method=auto
> 
> 
> Are there other configs needed?
> ___
> 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: Pointers for configuring vpn please

[Dan Williams]

On Wed, 2017-05-10 at 15:18 +0100, Colin Helliwell wrote:
> > On 10 May 2017 at 15:12 Thomas Haller  wrote:
> > 
> > On Wed, 2017-05-10 at 14:57 +0100, colin.helliw...@ln-systems.com
> > wrote:
> > 
> > > I'd like to get NM VPN connections going on my platform.
> > > We have a VPN for dial-in from home, so I'll just test out with
> > > that
> > > to
> > > begin with. We use a Draytek vpn client on Windows, which is
> > > configured for
> > > PPTP with the necessary username and password.
> > > I've built/installed the NetworkManager-pptp plugin, but could I
> > > get
> > > some
> > > tips please on how to manually (editing/nmcli - no gui) configure
> > > a
> > > vpn
> > > connection? (The errors from what I've tried so far aren't too
> > > informative
> > > 
> > > *   reason="Could not find source connection.")
> > > Not too concerned about the securest/cleanest way to configure
> > > the
> > > connection settings - just want to verify that I've got all the
> > > necessary
> > > components installed.
> > 
> > Hi,
> > 
> > There is no documentation. Look at the source:
> > 
> > https://git.gnome.org/browse/network-manager-pptp/tree/src/nm-pptp-
> > service.c?id=6e4a25d5abbc06010f4ce3a69edad6e121582357#n112
> > 
> > It seems easiest to use nm-connection-editor (with the GUI plugin
> > of
> > NetworkManager-pptp) on another host, and look at the created
> > connection in /etc/NetworkManager/system-connections
> > 
> > You can copy the keyfile over to your headless system (beware that
> > the
> > file must be owned by root, and chmod 600; followed by nmcli
> > connection reload).
> > 
> > Alternatively, once you *know* which properties you want to set,
> > you
> > can set them via
> >  nmcli connection modify "$NAME" +vpn.data 'property1=value1'
> > 
> > best,
> > Thomas
> 
> Thanks Thomas.
> I've got a little further just now: 
> First my Eth0 wasn't managed [still trying to figure out how to use
> the ifupdown 'managed' setting, so at the mo' I just need to remember
> to remove it from /etc/network/interfaces]
> Then I've added "password-flags=0" and a 'vpn-secrets' section for
> the password.
> Log messages now are:
> May 10 15:12:16 wg daemon.info NetworkManager[972]:
>   [1494425536.6092] audit: op="connection-activate"
> uuid="5a2d1600-531c-42de-ac21-d8a5e1f0f8c5" name="vpn-pptp" pid=1014
> uid=0 result="success"
> May 10 15:12:16 wg daemon.info NetworkManager[972]:
>   [1494425536.6422] vpn-connection[0x1098218,5a2d1600-531c-
> 42de-ac21-d8a5e1f0f8c5,"vpn-pptp",0]: Started the VPN service, PID
> 1020
> May 10 15:12:16 wg daemon.info NetworkManager[972]:
>   [1494425536.7229] vpn-connection[0x1098218,5a2d1600-531c-
> 42de-ac21-d8a5e1f0f8c5,"vpn-pptp",0]: Saw the service appear;
> activating connection
> May 10 15:12:16 wg daemon.info NetworkManager[972]:
>   [1494425536.9368] vpn-connection[0x1098218,5a2d1600-531c-
> 42de-ac21-d8a5e1f0f8c5,"vpn-pptp",0]: VPN connection:
> (ConnectInteractive) reply received
> May 10 15:12:16 wg daemon.warn NetworkManager[972]:
>   [1494425536.9610] vpn-connection[0x1098218,5a2d1600-531c-
> 42de-ac21-d8a5e1f0f8c5,"vpn-pptp",0]: VPN connection: failed to
> connect: 'Could not find pptp client binary.'
> May 10 15:12:17 wg daemon.info NetworkManager[972]:
>   [1494425537.0177] vpn-connection[0x1098218,5a2d1600-531c-
> 42de-ac21-d8a5e1f0f8c5,"vpn-pptp",0]: VPN plugin: state changed:
> stopped (6)
> May 10 15:12:17 wg daemon.info NetworkManager[972]:
>   [1494425537.0292] vpn-connection[0x1098218,5a2d1600-531c-
> 42de-ac21-d8a5e1f0f8c5,"vpn-pptp",0]: VPN service disappeared
> 
> So an additional package (the "pptp client binary") needed...?

Yes, the pptp package, typically obtained from your distro or from:

http://pptpclient.sourceforge.net/

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

Re: MAC address randomization prevents connecting to some wifi AP

[Dan Williams]

On Tue, 2017-05-09 at 12:21 +0200, Thomas Haller wrote:
> On Sun, 2017-05-07 at 16:18 +0200, Julien Cubizolles wrote:
> > Thomas Haller  writes:
> > 
> > 
> > > From the logfile it's not clear why it would fail. There is also
> > > no
> > >  message about NM being unable to change the MAC address --
> > > which
> > > I would expect to see when the driver cannot change the MAC
> > > address.
> > > But then it's unclear why you say "wifi.scan-rand-mac-address=no"
> > > fixes
> > > the issue.
> > > 
> > > You'd have to enable level=TRACE logging , see 
> > >   https://cgit.freedesktop.org/NetworkManager/NetworkManager/plai
> > > n/
> > > contrib/fedora/rpm/NetworkManager.conf?id=master
> > 
> > I enabled logging and now have a 3000+ lines file and I don't know
> > what
> > parts are relevant. It's too big for paste.bin so please find it
> > as a gzipped attachment.
> > 
> 
> Hi,
> 
> The logfile shows that you didn't disable MAC address randomization
> during activation. Ok, that is helpful to see that NM is able to
> change
> the MAC address. So, if it's related to MAC address randomization,
> it's
> either a supplicant or a driver bug.

Just to follow up on this, Julien and I were also talking on linux-
wireless@.  He said:

"I have my wifi AP set to only accept a whitelist of MAC addresses so
it makes sense that I can't connect if the MAC address is random."

So yeah, he's MAC filtering, and randomization should be disabled.

Dan

> -- note, your AP might be configured to filter by MAC address. But
> since you configured cloned-mac-address=permanent, that doesn't seem
> to
> be problem either. "wifi.scan-rand-mac-address" only matters while
> scanning. That should not matter while associating (where
> "wifi.cloned-
> mac-address" comes into play).
> 
> From the logfile it is not clear what the problem is. It doesn't seem
> to be related to changing the MAC address (as the original email
> claims). But even if that would be the case, it would be easy to rule
> out by configuring NM not to ever change the MAC address. Since you
> apparently tried to do that (without fixing your issue), it seems
> that
> MAC address randomization is the problem.
> 
> I would still suggest you disable MAC address randomization to rule
> that out and dig more.
> 
> Look at the logfiles from supplicant
>  ( https://wiki.gnome.org/Projects/NetworkManager/Debugging#Debugging
> _WiFi_Connections ).
> 
> 
> Best,
> Thomas
> ___
> 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: Modem Manager stuck in a loop, ppp can't connect.

[Dan Williams]

On Sat, 2017-05-06 at 18:16 -0400, A. F. Cano wrote:
> On Thu, May 04, 2017 at 09:14:01PM -0500, Dan Williams wrote:
> > On Sun, 2017-04-30 at 17:26 -0400, A. F. Cano wrote:
> > > I had a similar problem back in January which was discussed in
> > > the
> > > thread with title: "Network manager auto-upgraded, ppp no longer
> > > connects."
> > > 
> > > All the information about the device, AT commands and responses
> > > can
> > > be
> > > found there, as requested by Dan Williams.  Something was
> > > apparently
> > > fixed and Modem Manager went back to working correctly.
> > 
> > I don't think I was able to fix anything, so it must be something
> > in
> > the device.  The logs are the same problem as before, the device
> > isn't
> > returning a valid SID/NID for AT+CSS and thus we cannot figure out
> > if
> > we're registered on the network or not, and thus whether we can
> > connect.
> 
> Mmm...  This is puzzling.  The only thing that changed was an upgrade
> of
> network-manager/modem-manager in the previous installation.  Then
> that
> installation (system on an SD card) became unusable (unrelated
> problem)
> and I installed a new system on a new SD card and it didn't work,
> again.
> Your answer prompted me to try again and, surprisingly, it now works
> correctly again.

Does the modem reply to AT+CSS with valid SID/NID values now, or still
"?, 0"?

Dan

> > Just having service (eg, "AT+CSS: 1") isn't enough, because in the
> > CDMA
> > systems you'll almost always connect to the network for emergency
> > calls, even if you cannot initiate a data connection.
> 
> Thank you for the clarification.  I now understand better what
> modem-manager is trying to do and the likely bugs/limitations of this
> old phone.
> 
> > I'd be pretty curious what made things work again, if you have any
> > command traces from that time?
> 
> Not specific log file entries but the version of network-manager on
> the
> old system (where it worked, then didn't and then worked again) was
> 1.4.something.  The new installation was 1.6.something, but this is
> probably coincidental since this one is now working also and I'm
> pretty
> confident that the phone software is buggy.  It sometimes reboots
> itself, other times after a data session I have to power cycle the
> phone
> or voice calls can't be made, and I think the charging sofware is
> also
> buggy and is slowly ruining the battery by overcharging, but maybe
> the
> battery is just old.
> 
> In any case, thank you for replying.
> 
> > ...
> 
> Augustine
> 
> ___
> 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: help needed to use a Sierra Wireless MC7354 3G modem with a Raspberry Pi3 running Angstrom v2016.12 - Kernel 4.4.35

[Dan Williams]

On Fri, 2017-05-05 at 10:14 +0200, Aleksander Morgado wrote:
> Hey Phil,
> 
> > 
> > I think the problem lies with NetworkManager:
> > 
> > root@raspberrypi3:/# nmcli con show
> > 
> > NAMEUUID  TYPE
> > DEVICE
> > 
> > Wired connection 1  bdc6b7b3-1e60-453c-bfca-11ce7519826d  802-3-
> > ethernet
> > eth0
> > 
> > cellularbd4fbd79-329c-4af2-a68d-
> > a330df553abd  gsm --
> > 
> > root@raspberrypi3:/#
> > 
> > 
> > 
> > cellular was created with:
> > 
> > nmcli connection add type gsm con-name cellular ifname wwan0 apn
> > mnet.bell.ca.ioe
> > 
> > 
> > 
> > But my wwan0 interface shows “unmanaged” and I cannot bring it up:
> > 
> 
> This is wrong; you shouldn't create a connection bound to ifname
> wwan0. The "interface-name" connection property expected by
> NetworkManager would be the control port of the modem as specified by
> ModemManager. The data port, which is what you specified, is
> transient, and is actually a decision of ModemManager which port to
> use (your MC7354 may actually be configured with a pair of QMI+WWAN
> interfaces instead of just one, and MM would tell you which one to
> use).
> 
> I believe you can actually just ignore the "interface-name" and leave
> it blank, creating a "gsm connection setting that may be used with
> any
> modem"; e.g.:
> 
> $ nmcli connection add type "gsm" con-name "cellular" apn
> "mnet.bell.ca.ioe" ifname ""

Right.  If you want to lock to a specific modem or specific SIM, we
recommend using the "gsm.device-id" and "gsm.sim-id" properties
instead.  These come directly from ModemManager's "mmcli -m X" (device
id) and "mmcli -i X" (IMSI) outputs.

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

Re: Running NM without systemd

[Dan Williams]

On Tue, 2017-05-02 at 16:23 +0100, Colin Helliwell wrote:
> > On 02 May 2017 at 16:07 Dan Williams <d...@redhat.com> wrote:
> > 
> > On Tue, 2017-05-02 at 15:54 +0100, colin.helliw...@ln-systems.com
> > wrote:
> > 
> > > I'm hoping to use NetworkManager on a system which doesn't have
> > > systemd . So
> > > far I'm hitting a few dependency problems but, before I start
> > > trying
> > > to wade
> > > through them I wanted to check that what I'm trying to achieve
> > > *is*
> > > possible
> > > 
> > > *   or is systemd essential for NM?
> > 
> > systemd should not be essential for NM. The various points of
> > systemd
> > integration (suspend/resume, hostname, session-tracking, journal,
> > etc)
> > should be either build-time or runtime selectable.
> > 
> > What ./configure or ./autogen arguments are you using? What errors
> > are
> > you getting?
> > 
> > Dan
> 
> 
> Thanks for confirming that, Dan. Gives me hope (if not enthusiasm :S)
> for pushing on with the goal.
> As I say, I've only made a very brief stab at it so far, building
> under Yocto. But the first one I've hit is consolekit being missing
> [from the overall Yocto image recipes].
> Because this causes an an initial dependency parsing error then I
> don't yet get as for as the configure step, but on the recipe version
> *with* systemd, the configure line was
> 
> ../git/configure  --build=x86_64-linux  --host=arm-poky-
> linux-gnueabi   --target=arm-poky-linux-
> gnueabi --prefix=/usr   
> --exec_prefix=/usr  --bindir=/usr/bin   
> --sbindir=/usr/sbin 
> --libexecdir=/usr/libexec   
> --datadir=/usr/share--sysconfdir=/etc   
> --sharedstatedir=/com   
> --localstatedir=/var--libdir=/usr/lib   
> --includedir=/usr/include   
> --oldincludedir=/usr/include
> --infodir=/usr/share/info   
> --mandir=/usr/share/man --disable-silent-
> rules  --disable-dependency-
> tracking   --with-libtool-sysroot=/home/colin/100051-
> trunk/fsl-community-bsp/build/tmp/sysroots/wg2xx-tx6s --enable-
> introspection   --disable-ifcfg-rh --disable-ifnet 
> --disable-ifcfg-suse --disable-more-warnings --with-
> iptables=/usr/sbin/iptables --with-nmtui=no --enable-
> tests=no --enable-polkit=disabled  --disable-polkit-agent 
> --disable-gtk-doc  --disable-gtk-doc-html --disable-
> introspection --enable-vala=no--disable-static --enable-nls
> --disable-bluez5-dun --with-dhclient=/sbin/dhclient --enable-ifupdown 
> --with-modem-manager-1=yes --with-netconfig=no --with-crypto=nss --
> enable-ppp --disable-qt --with-resolvconf=no  --with-
> systemdsystemunitdir=/lib/systemd/system --with-session-
> tracking=systemd  --enable-wifi=no

--with-systemdsystemunitdir=no
--with-session-tracking=none
--with-suspend-resume=consolekit

What's the ConsoleKit dep issue?  In current NM it's just a D-Bus
thing, so there shouldn't be any hard dependency on headers or
libraries.  You'll probably get a log message error, but that should be
it I think.

Dan

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

Re: Running NM without systemd

[Dan Williams]

On Tue, 2017-05-02 at 15:54 +0100, colin.helliw...@ln-systems.com
wrote:
> I'm hoping to use NetworkManager on a system which doesn't have
> systemd . So
> far I'm hitting a few dependency problems but, before I start trying
> to wade
> through them I wanted to check that what I'm trying to achieve *is*
> possible
> - or is systemd essential for NM?

systemd should not be essential for NM.  The various points of systemd
integration (suspend/resume, hostname, session-tracking, journal, etc)
should be either build-time or runtime selectable.

What ./configure or ./autogen arguments are you using?  What errors are
you getting?

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

Re: Interactions with ModemManager

[Dan Williams]

On Fri, 2017-04-21 at 11:32 +0100, Colin Helliwell wrote:
> > On 20 April 2017 at 17:28 Dan Williams <d...@redhat.com> wrote:
> > 
> > On Mon, 2017-04-10 at 14:40 +0100, Colin Helliwell wrote:
> > 
> > > A couple of things I've noticed in integrating NM with
> > > ModemManager:
> > > 
> > > 1.  It seems that eth0 doesn't come up - i.e. dhcp client not
> > > fired
> > > off - until MM has done it's startup operations on the GSM modem.
> > > It
> > > so happens that my GSM has a long power-on pause, and that is
> > > holding
> > > up the system's eth network start-up too. Not a huge problem as a
> > > hyper-fast startup isn't needed, but not ideal..
> > 
> > Missed this message... This may be due to NM's "startup" function,
> > where it waits for all interfaces that exist at startup to settle
> > before it tries to do anything with them. This tries to ensure that
> > composed devices (eg, bonds, bridges, teams, etc) have all the
> > components they need at startup.
> > 
> > So yeah, that could prevent things from happening if the GSM modem
> > takes a long time to power on. You might be able to work around
> > this
> > by setting the NM "wwan enabled" property to "off" and then having
> > scripts or something flip that on later? A dispatcher script could
> > do
> > that perhaps.
> > 
> > > 1.  Even after the initial 'query' start-up on the GSM, NM seems
> > > to
> > > leave it enabled (as per mmcli -m 0), rather than leaving it
> > > disabled
> > > until called upon (with a nmcli conn up XX)
> > 
> > NM has the 'wwan-enabled' option which controls whether it powers
> > up
> > modems on start. If that option is off, NM will leave them in
> > 'disabled' state until the 'nmcli con up XXX'.
> > 
> > Try setting 'nmcli radio wwan off', ensuring the modem is disabled
> > in
> > MM, then restarting NM. Does that keep the modem disabled?
> 
> Just been having a try-out with that control. I see that the state
> persists across reboot - is there a way to force a particular bootup
> setting?

Yeah, you can twiddle that knob before NM starts in
/var/lib/NetworkManager/NetworkManager.state as you wish:

[main]
WWANEnabled=true   (or "false")

Just create the file if it doesn't exist, or use sed or something to
modify the value.  You could also change it with 'nmcli' at any point
during NM startup to, and NM should do the right thing.

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

Re: GSM conn up fails first time with SIM PIN

[Dan Williams]

On Mon, 2017-04-24 at 14:08 +0100, Colin Helliwell wrote:
> Does this look like one which should be punted over to MM mailing
> list?

Most definitely.

Dan

> > On 20 April 2017 at 09:23 Colin Helliwell <colin.helliwell@ln-
> > systems.com> wrote:
> > 
> > > On 19 April 2017 at 19:06 Dan Williams <d...@redhat.com> wrote:
> > > 
> > > On Wed, 2017-04-19 at 14:47 +0100, Colin Helliwell wrote:
> > > 
> > > > > On 19 April 2017 at 14:01 Colin Helliwell <colin.helliwell@ln
> > > > > -syste ms.com> wrote:
> > > > > 
> > > > > > On 18 April 2017 at 14:36 Colin Helliwell <colin.helliwell@
> > > > > > ln-sys tems.com> wrote:
> > > > > > 
> > > > > > > On 17 April 2017 at 18:32 Dan Williams <d...@redhat.com>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > On Sat, 2017-04-15 at 13:11 +0100, Colin Helliwell wrote:
> > > > > > > 
> > > > > > > > I have NM setup with ModemManager and GSM modem, and
> > > > > > > > can
> > > > > > > > bring up the
> > > > > > > > connection. But when I enable a SIM PIN lock, the first
> > > > > > > > 'nmcli conn
> > > > > > > > up' from reboot fails.
> > > > > > > > I can see that the modem is being unlocked ok, and is
> > > > > > > > indeed
> > > > > > > > registered afterwards. And a retry of the 'conn up'
> > > > > > > > also
> > > > > > > > works.
> > > > > > > > I wonder if there's some sequence/timing issue on the
> > > > > > > > first
> > > > > > > > time,
> > > > > > > > when the modem has to be brought out of locked state.
> > > > > > > > (I
> > > > > > > > leave the
> > > > > > > > enabling to NM/MM; with the PIN in the NM connection
> > > > > > > > settings).
> > > > > > > > 
> > > > > > > > NM log is below. I *think* the point at which it goes
> > > > > > > > awry is
> > > > > > > > indicated by the
> > > > > > > >  'enabling' --> 'disabled' (reason: unknown) @ 12:51:37
> > > > > > > > Unable to spot at the MM end of things [these logs
> > > > > > > > omitted
> > > > > > > > here]
> > > > > > > > what's triggering this change. Could it just be a
> > > > > > > > timeout?
> > > > > > > > (circa
> > > > > > > > 20secs)
> > > > > > > 
> > > > > > > Can you grab MM debug logs for this sequence too? I can't
> > > > > > > see
> > > > > > > what it
> > > > > > > would be from the NM side, maybe having both together
> > > > > > > would
> > > > > > > help.
> > > > > > > 
> > > > > > > Dan
> > > > > > 
> > > > > > Attached.
> > > > 
> > > > I also notice that at 12:51:36, "enabling_started(): Flashing
> > > > primary
> > > > AT port before enabling..." is occurring *twice*..?
> > > 
> > > I think that's a problem. Might not be the problem, but certainly
> > > could be involved. Here's what I think is happening:
> > > 
> > > 1) NM notices the modem is finally all initialized and in the
> > > 'disabled' state. Since your rfkill switch (or if you don't have
> > > one,
> > > the NM WWAN Enabled property) allows WWAN, so NM sends the
> > > 'enable this
> > > modem' request to MM.
> > > 
> > > 2) MM authorizes the Enable() request, which hits up polkit and
> > > thus
> > > might take a few mainloop iterations
> > > 
> > > 3) While the authorize is waiting, something (perhaps NM)
> > > triggers the
> > > Simple.Connect() request now that the modem is initialized and
> > > unlocked
> > > 
> > > 4) MM authorizes the Simple.Connect() request, which hits up
> > > polkit and
> > > thus might take a few mainloop iterations.
> > > 
> > > 5) The Enable() author

Re: Interactions with ModemManager

[Dan Williams]

On Mon, 2017-04-10 at 14:40 +0100, Colin Helliwell wrote:
> A couple of things I've noticed in integrating NM with ModemManager:
> 1. It seems that eth0 doesn't come up - i.e. dhcp client not fired
> off - until MM has done it's startup operations on the GSM modem. It
> so happens that my GSM has a long power-on pause, and that is holding
> up the system's eth network start-up too. Not a huge problem as a
> hyper-fast startup isn't needed, but not ideal..

Missed this message...  This may be due to NM's "startup" function,
where it waits for all interfaces that exist at startup to settle
before it tries to do anything with them.  This tries to ensure that
composed devices (eg, bonds, bridges, teams, etc) have all the
components they need at startup.

So yeah, that could prevent things from happening if the GSM modem
takes a long time to power on.  You might be able to work around this
by setting the NM "wwan enabled" property to "off" and then having
scripts or something flip that on later?  A dispatcher script could do
that perhaps.

> 2. Even after the initial 'query' start-up on the GSM, NM seems to
> leave it enabled (as per mmcli -m 0), rather than leaving it disabled
> until called upon (with a nmcli conn up XX)

NM has the 'wwan-enabled' option which controls whether it powers up
modems on start.  If that option is off, NM will leave them in
'disabled' state until the 'nmcli con up XXX'.

Try setting 'nmcli radio wwan off', ensuring the modem is disabled in
MM, then restarting NM.  Does that keep the modem disabled?

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

Re: GSM conn up fails first time with SIM PIN

[Dan Williams]

On Wed, 2017-04-19 at 14:47 +0100, Colin Helliwell wrote:
> > On 19 April 2017 at 14:01 Colin Helliwell <colin.helliwell@ln-syste
> > ms.com> wrote:
> > 
> > > On 18 April 2017 at 14:36 Colin Helliwell <colin.helliwell@ln-sys
> > > tems.com> wrote:
> > > 
> > > > On 17 April 2017 at 18:32 Dan Williams <d...@redhat.com> wrote:
> > > > 
> > > > On Sat, 2017-04-15 at 13:11 +0100, Colin Helliwell wrote:
> > > > 
> > > > > I have NM setup with ModemManager and GSM modem, and can
> > > > > bring up the
> > > > > connection. But when I enable a SIM PIN lock, the first
> > > > > 'nmcli conn
> > > > > up' from reboot fails.
> > > > > I can see that the modem is being unlocked ok, and is indeed
> > > > > registered afterwards. And a retry of the 'conn up' also
> > > > > works.
> > > > > I wonder if there's some sequence/timing issue on the first
> > > > > time,
> > > > > when the modem has to be brought out of locked state. (I
> > > > > leave the
> > > > > enabling to NM/MM; with the PIN in the NM connection
> > > > > settings).
> > > > > 
> > > > > NM log is below. I *think* the point at which it goes awry is
> > > > > indicated by the
> > > > >  'enabling' --> 'disabled' (reason: unknown) @ 12:51:37
> > > > > Unable to spot at the MM end of things [these logs omitted
> > > > > here]
> > > > > what's triggering this change. Could it just be a timeout?
> > > > > (circa
> > > > > 20secs)
> > > > 
> > > > Can you grab MM debug logs for this sequence too? I can't see
> > > > what it
> > > > would be from the NM side, maybe having both together would
> > > > help.
> > > > 
> > > > Dan
> > > 
> > > Attached.
> 
> I also notice that at 12:51:36, "enabling_started(): Flashing primary
> AT port before enabling..." is occurring *twice*..?

I think that's a problem.  Might not be the problem, but certainly
could be involved.  Here's what I think is happening:

1) NM notices the modem is finally all initialized and in the
'disabled' state.  Since your rfkill switch (or if you don't have one,
the NM WWAN Enabled property) allows WWAN, so NM sends the 'enable this
modem' request to MM.

2) MM authorizes the Enable() request, which hits up polkit and thus
might take a few mainloop iterations

3) While the authorize is waiting, something (perhaps NM) triggers the
Simple.Connect() request now that the modem is initialized and unlocked

4) MM authorizes the Simple.Connect() request, which hits up polkit and
thus might take a few mainloop iterations.

5) The Enable() authorize completes and calls mm_base_modem_enable(). 
That gets to mm-broadband-modem.c::enable().  That sees the modem is
MM_MODEM_STATE_DISABLED and falls through to
ENABLING_STEP_WAIT_FOR_FINAL_STATE.  That sees the modem is already in
a final state, and schedules a completion from an idle handler.

6) While #5's idle handler is scheduled, the authorize from #4
completes and sees MM_MODEM_STATE_DISABLED and jumps to
CONNECTION_STEP_ENABLE which also calls mm_base_modem_enable().  That
sees the modem is MM_MODEM_STATE_DISABLED and falls through to
ENABLING_STEP_WAIT_FOR_FINAL_STATE.  That sees the modem is already in
a final state, and schedules a completion from an idle handler.

So now we have two callchains trying to enable the modem.  I don't know
how that could actually trigger the enabling -> disabled bug, but I
don't doubt something could be involved there.  If this is all correct,
it's clearly an MM race bug.

Could you try the attached patch and see if you get the message and if
that fixes the issue?

Dandiff --git a/src/mm-broadband-modem.c b/src/mm-broadband-modem.c
index b480255..dee67df 100644
--- a/src/mm-broadband-modem.c
+++ b/src/mm-broadband-modem.c
@@ -9444,11 +9444,45 @@ enabling_started_ready (MMBroadbandModem *self,
 }
 
 static void
+enabling_wait_for_final_state_ready2 (MMIfaceModem *self,
+ GAsyncResult *res,
+ EnablingContext *ctx)
+{
+GError *error = NULL;
+MMModemState state = MM_MODEM_STATE_UNKNOWN;
+
+ctx->previous_state = mm_iface_modem_wait_for_final_state_finish (self, res, );
+if (error) {
+g_simple_async_result_take_error (ctx->result, error);
+enabling_context_complete_and_free (ctx);
+return;
+}
+
+g_object_get (self,
+  MM_IFACE_MODEM_STATE, ,
+  NULL);
+
+if (state != MM_MODEM_STATE_ENABLED) {
+  

Re: nmcli connection add type gsm with PAP|CHAP ?

[Dan Williams]

On Tue, 2017-04-18 at 09:17 +0900, Kajio, Yoshinori wrote:
> Can I set PAP or CHAP with "nmcli connection add type gsm" ?
> If not, is there any way to set it?

You actually add a PPP setting to the connection, in which you can set
the "refuse-pap" or "refuse-chap" properties, which will cause pppd to
refuse those specific auth protocols. eg:

nmcli con add type gsm  ppp.refuse-chap true

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

Re: GSM conn up fails first time with SIM PIN

[Dan Williams]

On Sat, 2017-04-15 at 13:11 +0100, Colin Helliwell wrote:
> I have NM setup with ModemManager and GSM modem, and can bring up the
> connection. But when I enable a SIM PIN lock, the first 'nmcli conn
> up' from reboot fails.
> I can see that the modem is being unlocked ok, and is indeed
> registered afterwards. And a retry of the 'conn up' also works.
> I wonder if there's some sequence/timing issue on the first time,
> when the modem has to be brought out of locked state. (I leave the
> enabling to NM/MM; with the PIN in the NM connection settings).
> 
> NM log is below. I *think* the point at which it goes awry is
> indicated by the 
>   'enabling' --> 'disabled' (reason: unknown) @ 12:51:37
> Unable to spot at the MM end of things [these logs omitted here]
> what's triggering this change. Could it just be a timeout? (circa
> 20secs)

Can you grab MM debug logs for this sequence too?  I can't see what it
would be from the NM side, maybe having both together would help.

Dan

> 
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8252] agent-manager: req[0x1c4e918, :1.9/nmcli-
> connect/0]: requesting permissions
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8283] agent-manager: req[0x1c4e918, :1.9/nmcli-
> connect/0]: agent registered
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8367] policy: re-enabling autoconnect for all connections
> with failed secrets
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8477] active-connection[0x1c3bdd0]: set device "ttyMux1"
> [0x1c3e3b0]
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8500] device[0x1c3e3b0] (ttyMux1): add_pending_action
> (1): 'activation-0x1c3bdd0'
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8583] active-connection[0x1c3bdd0]: constructed
> (NMActRequest, version-id 2, type managed)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8611] device[0x1c3e3b0] (ttyMux1): add_pending_action
> (2): 'autoactivate'
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8634] device[0x1c3e3b0] (ttyMux1): remove_pending_action
> (1): 'autoactivate'
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8645] device[0x1c3e3b0] (ttyMux1): unmanaged: flags set
> to [!sleeping,!loopback,!platform-init,!user-explicit,!user-
> settings=0x0/0x79/managed], set-managed [user-explicit=0x20], reason
> user-requested)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]:
>   [1492257074.8820] device (ttyMux1): Activation: starting
> connection 'Vodafone' (e0f97177-2f8e-4ed4-9942-7b4e499397cc)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8845] device[0x1c3e3b0] (ttyMux1): activation-stage:
> schedule activate_stage1_device_prepare,2 (id 204)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.8903] create NMAuditManager singleton (0x75300ec0)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]:
>   [1492257074.8926] audit: op="connection-activate"
> uuid="e0f97177-2f8e-4ed4-9942-7b4e499397cc" name="Vodafone" pid=1383
> uid=0 result="success"
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.9030] device[0x1c3e3b0] (ttyMux1): activation-stage:
> invoke activate_stage1_device_prepare,2 (id 204)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]:
>   [1492257074.9036] device (ttyMux1): state change:
> disconnected -> prepare (reason 'none') [30 40 0]
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.9105] active-connection[0x1c3bdd0]: set state activating
> (was unknown)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.9164] active-connection[0x1c3bdd0]: check-master-ready:
> not signalling (state activating, no master)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.9216] Secrets requested for connection
> /org/freedesktop/NetworkManager/Settings/2 (Vodafone/gsm)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.9219] agent-manager: req[0x1c4e918, :1.9/nmcli-
> connect/0]: agent allowed for secrets request
> [0x1c5ca18/"Vodafone"/"gsm"]
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.9222] settings-connection[0x75302fa0,e0f97177-2f8e-4ed4-
> 9942-7b4e499397cc]: (gsm:0x1c5ca18) secrets requested flags 0x5 hints
> 'pin'
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]:
>   [1492257074.9224] device (ttyMux1): state change: prepare ->
> need-auth (reason 'none') [40 60 0]
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.9358] device[0x1c3e3b0] (ttyMux1): activation-stage:
> complete activate_stage1_device_prepare,2 (id 204)
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.9606] agent-manager: ([0x1c5ca18/"Vodafone"/"gsm"])
> system settings secrets sufficient
> Apr 15 12:51:14 wg2xx-tx6s NetworkManager[1154]: 
> [1492257074.9669] settings-connection[0x75302fa0,e0f97177-2f8e-4ed4-
> 9942-7b4e499397cc]: (gsm:0x1c4d880) existing secrets returned
> Apr 15 12:51:14 

Re: Connection fail-over

[Dan Williams]

On Wed, 2017-04-12 at 10:44 -0500, Alex Ferm wrote:
> I don't think there is a built-in fail-over mechanism, but you should
> be 
> able to write a dispatcher script to handle it. 
> https://developer.gnome.org/NetworkManager/1.6/NetworkManager.html

Yeah, that was the general idea.  There are unfortunately a lot of ways
to say "this connection has failed" (IP packet loss? physical link
error rate? link speed degredation? latency spikes?) and encoding them
all into NetworkManager isn't a flexible solution.  So that gets punted
to dispatcher scripts if you need more detailed metrics to make the
decision of "this connection has failed".

Also important to distinguish between fail-over on the same device, or
fail-over between devices.  NM has some support for both, including
priorities for the default route across all devices, and for
connections for a given device.  I'd think many scenarios could be
handled through dispatcher scripts.

That all said, if there's something missing to help support dispatcher
script-based failover, or there is something that so many people use
that it might as well be included in NM, please let us know!

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

Re: Cellular modem connection does not come up on boot

[Dan Williams]

On Tue, 2017-04-04 at 21:27 -0400, Liam Monahan wrote:
> I definitely see the conspicuous gap you see with no dial out to #777
> happening. The
> logs that are there are unpruned straight from journalctl.  If I
> hotplug the modem
> back in, then I see additional info about the connection being made
> in the logs
> after “Simple connect started."
> 
> Just to add a little additional color to what appears to be happening
> here…the host
> in question runs docker containers, at least one of which appears to
> be running its
> own systemd process.  I noticed that systemd-udevd runs and
> ModemManager
> looks like it’s picking up on this udev event and re-scanning all
> ports.  When this
> happens, the modem connection terminates.

Interesting.  Could you play with "udevadm --trigger" and see if you
can reproduce the issue?

Dan

> To isolate this, I delayed docker start and let the system become
> quiescent, and
> took all journalctl output since the “Activation successful” message.
> 
> Here’s a log: https://gist.githubusercontent.com/spicybits/f723c9ce51
> df5dad86e83726c44db623/raw/gistfile1.txt
> <https://gist.githubusercontent.com/spicybits/f723c9ce51df5dad86e8372
> 6c44db623/raw/gistfile1.txt>
> 
> I first see an "Activation successful.”  Then, at Apr 05 00:57:57 I
> trigger docker to start
> up.  At Apr 05 00:58:00 udev triggers an event and MM reacts.
> 
> Once the modem drops off, it never comes back unless it is replugged.
> 
> Liam
> 
> > On Apr 3, 2017, at 5:15 PM, Dan Williams <d...@redhat.com> wrote:
> > 
> > On Mon, 2017-04-03 at 16:23 -0400, Liam Monahan wrote:
> > > Based off of the better picture I have now of what’s happening
> > > than
> > > when I originally
> > > posted, it looks like there is no condition where MM detection
> > > fails
> > > during boot.  The
> > > problem is that verbose logging seems to suggest that a
> > > connection
> > > does come up
> > > for a short time during boot, but always crashes by the end of
> > > the
> > > boot sequence.
> > > The log posted is very representative of the repeatable behavior
> > > I’ve
> > > been seeing.
> > > 
> > > MM detection and NM connection states both always take place, but
> > > by
> > > the time the
> > > system is quiescent and the boot sequence is “finished,”  the
> > > modem
> > > has disappeared
> > > from “mmcli -L", which in turn no longer presents the device to
> > > NM.  The log I posted is
> > > taken from that scenario taking place.
> > 
> > That's clearer.  A couple things:
> > 
> > 1) are you sure the logs from ModemManager are complete?  I would
> > expect to see a large gap between 12:06:43 and 12:07:13 with  no MM
> > log
> > messages but I'd expect to see some where MM is actually dialing
> > the
> > modem.  For example, the last thing we see is:
> > 
> > Mar 06 12:06:43 e5882e6 ModemManager[676]:   Simple connect
> > started...
> > Mar 06 12:06:43 e5882e6 ModemManager[676]: PIN:
> > unspecified
> > Mar 06 12:06:43 e5882e6 ModemManager[676]: Operator ID:
> > unspecified
> > 
> > and then later MM starts doing signal/registration checks.  But in
> > between there we should certainly see something like "ATDT#777"
> > where
> > MM is actually going through the steps for the "Simple connect",
> > and we
> > should see the resulting "CONNECT" from the modem before PPP
> > happens.
> > 
> > Any idea where those messages might have gone?  If you just grab
> > journal output from ModemManager, do they show up?
> > 
> > > Should I be focused on all the "released by modem” log messages
> > > that
> > > precede a
> > > state change from activated -> unmanaged (reason 'removed’)?  I’m
> > > assuming that removal
> > > is indicated to NM through MM and not directly, right?
> > 
> > Yeah, this is the larger problem.  The modem appears to crash and
> > drop
> > off the USB bus.  This could be due to either a firmware issue that
> > ModemManager is triggering somehow, or it could be due to
> > inadequate
> > power from the USB hub.
> > 
> > Once this happens, does it ever come back?  Or is this what
> > requires
> > the replug?
> > 
> > Dan
> > 
> > > Liam
> > > 
> > > > On Apr 3, 2017, at 3:56 PM, Dan Williams <d...@redhat.com>
> > > > wrote:
> > &

Re: Getting (a little more) started

[Dan Williams]

On Fri, 2017-04-07 at 17:17 +0100, Colin Helliwell wrote:
> > On 07 April 2017 at 17:15 Colin Helliwell <colin.helliwell@ln-syste
> > ms.com> wrote:
> > 
> > > On 07 April 2017 at 17:06 Dan Williams <d...@redhat.com> wrote:
> > > 
> > > On Fri, 2017-04-07 at 16:12 +0100, Colin Helliwell wrote:
> > > 
> > > > I've got NM installed n running on my embedded system. I can
> > > > 'nmcli
> > > > conn up modem' and the ppp link on my GSM modem comes up nicely
> > > > -
> > > > ifconfig reports inet and P-t-P addresses, and I seem able to
> > > > ping/traceroute through it to the interweb, but I may have some
> > > > clutter.
> > > > 
> > > > Being embedded and headless I don't have nice GUI widgets to
> > > > help me,
> > > > so I might need some more manual configuration or tidying of
> > > > stuff.
> > > > I'm using systemd, and also have running /lib/systemd/systemd-
> > > > networkd, /lib/systemd/systemd-resolved, /usr/bin/dnsmasq,
> > > > /sbin/dhclient.
> > > > I built NM with '--with-resolvconf=yes', and the [Yocto] image
> > > > also
> > > > has the resolveconf package included, but I'm unclear how these
> > > > relate to "/lib/systemd/systemd-resolved" and whether they have
> > > > common/conflicting configurations.
> > > 
> > > They will potentially conflict as there can only be one manager
> > > of
> > > /etc/resolv.conf, and both these things want to manage it.
> > > 
> > > NM 1.6+ has support for systemd-resolved and this will
> > > automatically be
> > > used if resolv.conf is managed by systemd-resolved and no other
> > > mode is
> > > configured in NetworkManager.conf.
> > 
> > Thanks.
> > So leave out the resolvconf package and leave it to NM & systemd-
> > resolved?
> > 
> 
> And if so, is '--with-resolvconf=yes' aimed at resolvconf (i.e. set
> it to no instead), or at systemd-resolved...?

Even if you set it to yes, you should still be able to set the
resolv.conf management mode via NM.conf.  The options are "dns" and
"rc-manager"; in your case if you want to use systemd-resolved as the
main management mode you'd:

dns=systemd-resolved
rc-manager=symlink

I think.

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

Re: Getting (a little more) started

[Dan Williams]

On Fri, 2017-04-07 at 16:12 +0100, Colin Helliwell wrote:
> I've got NM installed n running on my embedded system. I can 'nmcli
> conn up modem' and the ppp link on my GSM modem comes up nicely -
> ifconfig reports inet and P-t-P addresses, and I seem able to
> ping/traceroute through it to the interweb, but I may have some
> clutter.
> 
> Being embedded and headless I don't have nice GUI widgets to help me,
> so I might need some more manual configuration or tidying of stuff. 
> I'm using systemd, and also have running /lib/systemd/systemd-
> networkd, /lib/systemd/systemd-resolved, /usr/bin/dnsmasq,
> /sbin/dhclient. 
> I built NM with '--with-resolvconf=yes', and the [Yocto] image also
> has the resolveconf package included, but I'm unclear how these
> relate to "/lib/systemd/systemd-resolved" and whether they have
> common/conflicting configurations.

They will potentially conflict as there can only be one manager of
/etc/resolv.conf, and both these things want to manage it.

NM 1.6+ has support for systemd-resolved and this will automatically be
used if resolv.conf is managed by systemd-resolved and no other mode is
configured in NetworkManager.conf.

> I *haven't* yet deleted /etc/ppp/ip-up & /etc/ppp/ip-down (past info
> from Dan suggested there could be a risk of conflict here with what
> ppp tries to do vs. NM actions).

If things currently work then don't bother deleting them.  Your options
are apparently compatible :)

> I guess, put another way, is there something of a 'basic building
> blocks' info that I can follow to gradually build up a working but
> minimal/un-cluttered system, and good ways to sanity-check that
> things are correctly configuring...?

Most of the documentation is linked from here:

https://wiki.gnome.org/Projects/NetworkManager/

including manpage references, which you'll be interested in for
nmcli/nmtui and all the configuration files (keyfiles and NM.conf).  I
seem to recall there used to be docs for general architecture, but I
can't find those anymore and they are certainly out-of-date.  The core
parts are:

NetworkManager daemon - the NM binary, the central manager for network
interfaces controlled by NM.  Also manages DNS and the default route
for these devices, funneling aggregated DNS info to /etc/resolv.conf or
the DNS management service of your choice (dnsmasq, systemd-resolved,
resolvconf, etc).  Communicates with clients via the D-Bus IPC
protocol.

NetworkManager daemon plugins - optional device-specific plugins for
things like WWAN, WiFi, Team, Bluetooth, etc.  You don't need to
install these if you don't use these device types.

NetworkManager daemon VPN plugins - optional daemons that control VPN
services like IPSec, openvpn, vpnc, pptp, etc and funnel the tunnel
information (addresses, routes, DNS) back to NM.  You don't need to
install these if you don't use these VPNs.

client libraries - libnm and libnm-glib are GLib-based convenience
libraries for clients like nmcli, GNOME Shell, etc.  You don't need
these if your clients talk raw D-Bus to NM.  But the core NM tools like
nmcli/nmtui/nm-applet depend on these libraries.

command-line tools - nmcli/nmtui are the non-GUI, command-line tools
that can control almost all aspects of NM's operation.

GUI clients - nm-applet, GNOME Shell, KDE Plasma, etc.  Provide a GUI
way to view network status and to control NM's operation.

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

Re: bad gsm connections

[Dan Williams]

On Thu, 2017-03-30 at 19:32 +0300, matti kaasinen wrote:
> I tried to analyze log files from one card having problematic
> connection.
> First my set-up briefly:
> 1) Embedded Linux card behind Huawei E3131 modem connection + NM &
> MM.
> 2) Drivers: Option and huawei_cdc_ncm.
> 3) Connection monitor with following functionality:
> - monitoring frequency 10 minutes
> - monitoring task, 1..18 ping operations with 10s timeout (max 3
> minutes
> for one task)
> - if all the 18 ping operations fail = task fails => USB power lines
> are
> sequenced.

How long is power to the card turned off?

> - any of 18 ping operations passes = task passes => wait to next task
> start.
> - if 12 successive tasks fail (2 hours) => boot card.
> 4) Occasionally bandwidth or field limited conditions that get modem
> firmware crash and boot frequently/at any time. It is not quite sure
> what
> crashes, but usb device gets re-numerated over and over.

If it keeps enumerating, that's the firmware crashing.

I forget if we've covered this or not, but are you sure there's
adequate power to the card?  If the modem gets into a situation where
it thinks it needs to transmit at a higher power and then draws too
much power, that could be the issue.  But I've seen enough firmware
changelogs to know that all kinds of firmware crash bugs get fixed all
the time too.

> From logs it seems that:
> - Usually connection recovers automatically.
> - If it does not, power sequencing usually helps.
> - However, some times it does not help. If the first sequencing fails
> helping, next 10 power breaks fail too and 12'th task boots the card.
> It
> shows from the logs that USB enumeration does not work anymore when
> power
> sequencing stops working, which suggests that either udev or most
> likely
> some kernel driver has crashed. However, no kernel crash logs are
> printed.

Yes, it could be a kernel driver issue here, but you'd need to enable
kernel driver debugging for the USB Host Controller to figure that out,
most likely.  Which could require a kernel recompile.

Dan

> Connection seems recovering soon after booting.
> This might come now to wrong forum, as kernel driver seems the most
> likely
> suspect. Please, feel free forwarding me to correct one (MM perhaps).
> Also
> feel free suggesting your choice of kernel driver I should reload to
> get
> this locked state released without booting.
> 
> Thanks,
> Matti
> 
> 2017-03-08 20:22 GMT+02:00 matti kaasinen <matti.kaasi...@gmail.com>:
> 
> > 
> > 2017-03-07 20:11 GMT+02:00 Dan Williams <d...@redhat.com>:
> > 
> > > > > That's the modem firmware crashing and restarting.  It then
> > > > > reappears
> > > > > to the kernel and gets re-enumerated, and usb_modeswitch does
> > > > > its
> > > > > thing
> > > > > and then eventually it comes back as a modem.  Which could be
> > > > > due
> > > > > to
> > > > > any number of issues.
> > > > > 
> > > > 
> > > > But the first thing to check is whether the modem has enough
> > > > power.
> > > > > Laptops and embedded devices are sometimes unable to supply
> > > > > enough
> > > > > power to the USB ports while the modem is connected.
> > 
> > I studied this today by breaking power lines from USB cable and
> > feeding
> > modem power lines directly from laboratory power. Huawei E3131
> > dongle was
> > enclosed in metal box to damp field. Good power supply did not
> > help. It
> > turned out that modem did not recover from this error mode with
> > power
> > sequencing and not necessarily by booting Linux card. It required
> > longer
> > break and opening the chassis lid. Which made me suspect warming
> > up.
> > However, heating did not trigger this error mode if field was
> > somewhat
> > better. So, perhaps either E3131 firmware or kernel driver does not
> > tolerate low fields. Perhaps switching between modes (e.g.
> > edge/gprs)
> > triggers the error. Anyhow, I could not figure out the reason.
> > 
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Cellular modem connection does not come up on boot

[Dan Williams]

 2.4.7 started by root, uid 0
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: nm-pppd-plugin-Message:
> nm-ppp-plugin: (nm_phasechange): status 3 / phase 'serial connection'
> Mar 06 12:06:46 e5882e6 pppd[856]: Using interface ppp0
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: Using interface ppp0
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: Connect: ppp0 <-->
> /dev/ttyUSB3
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: nm-pppd-plugin-Message:
> nm-ppp-plugin: (nm_phasechange): status 5 / phase 'establish'
> Mar 06 12:06:46 e5882e6 pppd[856]: Connect: ppp0 <--> /dev/ttyUSB3
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: nm-pppd-plugin-Message:
> nm-ppp-plugin: (nm_phasechange): status 6 / phase 'authenticate'
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: nm-pppd-plugin-Message:
> nm-ppp-plugin: (nm_phasechange): status 8 / phase 'network'
> Mar 06 12:06:46 e5882e6 NetworkManager[723]:
>   [1488802006.5846] manager: (ppp0): new Generic device
> (/org/freedesktop/NetworkManager/Devices/4)
> Mar 06 12:06:46 e5882e6 pppd[856]: local  IP address 166.249.XXX.XXX
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: local  IP address
> 166.249.XXX.XXX
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: remote IP address
> 66.174.XXX.XXX
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: primary   DNS address
> 198.224.191.135
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: secondary DNS address
> 198.224.190.135
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: nm-pppd-plugin-Message:
> nm-ppp-plugin: (nm_phasechange): status 9 / phase 'running'
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: nm-pppd-plugin-Message:
> nm-ppp-plugin: (nm_ip_up): ip-up event
> Mar 06 12:06:46 e5882e6 NetworkManager[723]: nm-pppd-plugin-Message:
> nm-ppp-plugin: (nm_ip_up): sending IPv4 config to NetworkManager...
> Mar 06 12:06:46 e5882e6 pppd[856]: remote IP address 66.174.XXX.XXX
> Mar 06 12:06:46 e5882e6 NetworkManager[723]:
>   [1488802006.6702] ppp-manager: (IPv4 Config Get) reply
> received.
> Mar 06 12:06:46 e5882e6 pppd[856]: primary   DNS address
> 198.224.XXX.XXX
> Mar 06 12:06:46 e5882e6 pppd[856]: secondary DNS address
> 198.224.XXX.XXX
> Mar 06 12:06:46 e5882e6 NetworkManager[723]:
>   [1488802006.6887] device (ttyUSB3): state change: ip-config
> -> ip-check (reason 'none') [70 80 0]
> Mar 06 12:06:46 e5882e6 NetworkManager[723]:
>   [1488802006.6936] device (ttyUSB3): state change: ip-check ->
> secondaries (reason 'none') [80 90 0]
> Mar 06 12:06:46 e5882e6 NetworkManager[723]:
>   [1488802006.6955] device (ttyUSB3): state change: secondaries
> -> activated (reason 'none') [90 100 0]
> Mar 06 12:06:46 e5882e6 NetworkManager[723]:
>   [1488802006.6986] dns-mgr: Writing DNS information to
> /sbin/resolvconf
> Mar 06 12:06:46 e5882e6 NetworkManager[723]:
>   [1488802006.7816] device (ttyUSB3): Activation: successful,
> device activated.
> Mar 06 12:07:16 e5882e6 pppd[856]: IPV6CP: timeout sending Config-
> Requests
> Mar 06 12:07:16 e5882e6 NetworkManager[723]: IPV6CP: timeout sending
> Config-Requests
> Mar 06 12:08:07 e5882e6 NetworkManager[723]:
>   [1488802087.7799] manager: (docker0): new Bridge device
> (/org/freedesktop/NetworkManager/Devices/5)
> Mar 06 12:08:12 e5882e6 ModemManager[637]:   (tty/ttyUSB1):
> released by modem /sys/devices/platform/soc/3f98.usb/usb1/1-1/1-
> 1.2/1-1.2.1/1-1.2.1.4
> Mar 06 12:08:12 e5882e6 ModemManager[637]:   (tty/ttyUSB2):
> released by modem /sys/devices/platform/soc/3f98.usb/usb1/1-1/1-
> 1.2/1-1.2.1/1-1.2.1.4
> Mar 06 12:08:12 e5882e6 ModemManager[637]:   (tty/ttyUSB3):
> released by modem /sys/devices/platform/soc/3f98.usb/usb1/1-1/1-
> 1.2/1-1.2.1/1-1.2.1.4
> Mar 06 12:08:13 e5882e6 ModemManager[637]:   (tty/ttyUSB0):
> released by modem /sys/devices/platform/soc/3f98.usb/usb1/1-1/1-
> 1.2/1-1.2.1/1-1.2.1.4
> Mar 06 12:08:13 e5882e6 NetworkManager[723]:
>   [1488802093.2978] device (ttyUSB3): state change: activated
> -> unmanaged (reason 'removed') [100 10 36]
> Mar 06 12:08:13 e5882e6 pppd[856]: Terminating on signal 15
> Mar 06 12:08:13 e5882e6 NetworkManager[723]: Terminating on signal 15
> Mar 06 12:08:13 e5882e6 NetworkManager[723]: nm-pppd-plugin-Message:
> nm-ppp-plugin: (nm_phasechange): status 10 / phase 'terminate'
> Mar 06 12:08:13 e5882e6 NetworkManager[723]: nm-pppd-plugin-Message:
> nm-ppp-plugin: (nm_phasechange): status 8 / phase 'network'
> Mar 06 12:08:13 e5882e6 NetworkManager[723]: Connect time 1.5
> minutes.
> Mar 06 12:08:13 e5882e6 NetworkManager[723]: Sent 126 bytes, received
> 0 bytes.
> Mar 06 12:08:13 e5882e6 pppd[856]: Connect time 1.5 minutes.
> Mar 06 12:08:13 e5882e6 pppd[856]: Sent 126 bytes, received 0 bytes.
> Mar 06 12:08:13 e5882e6 NetworkMan

Re: Cellular modem connection does not come up on boot

[Dan Williams]

On Wed, 2017-03-29 at 10:48 -0400, Liam Monahan wrote:
> I have a USB cellular modem that will not show up in nm on boot.  If
> the system is started up and I unplug and plug it back in, it shows
> up then.  These device are deployed out in the field, so manual
> intervention is not a real option for my use case unfortunately.
> 
> device is ttyUSB3 and does not show up at first:
> 
> # nmcli d
> DEVICE TYPE  STATE CONNECTION 
> eth0   ethernet  connected Wired connection 1 
> wlan0  wifi  disconnected  -- 
> docker0bridgeunmanaged -- 
> lo loopback  unmanaged -- 
> resin-vpn  tun   unmanaged — 

When the device doesn't show up in NM, can you see it with "mmcli -L"
before you replug it?

If you can see it in mmcli, then the problem is likely in
NetworkManager.  Getting debug logs would be necessary, which you can
do by adding this to /etc/NetworkManager/NetworkManager.conf:

[logging]
level=trace

If you can't see it in ModemManager, then the bug is likely in MM.  You
can enable verbose MM debugging by modifying the ModemManager system
unit file and adding "--log-level=debug" to the Exec= line.

One of those should give us more info about the issue.

Dan

> and then after unplugging and plugging back in:
>  
> # nmcli d
> DEVICE TYPE  STATE CONNECTION 
> ttyUSB3cdma  connected resin-verizon  
> eth0   ethernet  connected Wired connection 1 
> wlan0  wifi  disconnected  -- 
> docker0bridgeunmanaged -- 
> lo loopback  unmanaged -- 
> resin-vpn  tun   unmanaged --   
> 
> # mmcli -L
> 
> Found 1 modems:
>   /org/freedesktop/ModemManager1/Modem/0 [Telit] DE910-DUAL
> 
> 
> dmesg makes it seem like the modem connected briefly and then
> disappeared.  Does anyone have any thoughts on what’s going on or how
> I could do a better job of going about debugging this?
> 
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.4.48 (and...@misc1.dev.resin.io) (gcc
> version 6.2.0 (GCC) ) #2 SMP Sat Mar 11 03:08:12 UTC 2017
> [0.00] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7),
> cr=10c5383d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [0.00] Machine model: Raspberry Pi 3 Model B Rev 1.2
> [0.00] cma: Reserved 8 MiB at 0x3d80
> [0.00] Memory policy: Data cache writealloc
> [0.00] On node 0 totalpages: 253952
> [0.00] free_area_init_node: node 0, pgdat 80ca84c0,
> node_mem_map bcf3a000
> [0.00]   Normal zone: 2232 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 253952 pages, LIFO batch:31
> [0.00] [bcm2709_smp_init_cpus] enter (9540->f3003010)
> [0.00] [bcm2709_smp_init_cpus] ncores=4
> [0.00] PERCPU: Embedded 13 pages/cpu @bcef6000 s23052 r8192
> d22004 u53248
> [0.00] pcpu-alloc: s23052 r8192 d22004 u53248 alloc=13*4096
> [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
> [0.00] Built 1 zonelists in Zone order, mobility grouping
> on.  Total pages: 251720
> [0.00] Kernel command line: 8250.nr_uarts=1
> dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416
> bcm2709.boardrev=0xa22082 bcm2709.serial=0xca8e10ef
> smsc95xx.macaddr=B8:27:EB:8E:10:EF bcm2708_fb.fbdepth=16
> bcm2708_fb.fbswap=1 bcm2709.uart_clock=4800
> vc_mem.mem_base=0x3ea0
> vc_mem.mem_size=0x3f00  dwc_otg.lpm_enable=0 console=tty1
> console=ttyS0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
> [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [0.00] Dentry cache hash table entries: 131072 (order: 7,
> 524288 bytes)
> [0.00] Inode-cache hash table entries: 65536 (order: 6,
> 262144 bytes)
> [0.00] Memory: 983796K/1015808K available (7029K kernel code,
> 454K rwdata, 1956K rodata, 3524K init, 775K bss, 23820K reserved,
> 8192K cma-reserved)
> [0.00] Virtual kernel memory layout:
>    vector  : 0x - 0x1000   (   4 kB)
>    fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>    vmalloc : 0xbe80 - 0xff80   (1040 MB)
>    lowmem  : 0x8000 - 0xbe00   ( 992 MB)
>    modules : 0x7f00 - 0x8000   (  16 MB)
>  .text : 0x80008000 - 0x808ce6fc   (8986 kB)
>  .init : 0x808cf000 - 0x80c4   (3524 kB)
>  .data : 0x80c4 - 0x80cb1a80   ( 455 kB)
>   .bss : 0x80cb4000 - 0x80d75f84   ( 776 kB)
> [0.00] SLUB: HWalign=64, Order=0-3, 

Re: Configure errors under yocto

[Dan Williams]

On Wed, 2017-03-29 at 16:52 +0100, Colin Helliwell wrote:
> > On 29 March 2017 at 15:13 Dan Williams <d...@redhat.com> wrote:
> > 
> > On Wed, 2017-03-29 at 14:32 +0100, Colin Helliwell wrote:
> > 
> > > > > On 27 March 2017 at 14:25 Colin Helliwell <colin.helliwell@ln
> > > > > -sys tems.com> wrote:
> > > 
> > > ...
> > > 
> > > > > ... but still have subsequent errors which seem to have been
> > > > > due
> > > > > to output directories not having been created e.g. libnm-
> > > > > core,
> > > > > introspection.
> > > > > I can get it to limp a little further by creating the
> > > > > directories
> > > > > in the pre-configure, but not totally.
> > > > > Something perhaps not hooked in right to cater for the build
> > > > > directory being different to the source directory...?
> > > 
> > > May I contribute the attached patch for building-outside-source-
> > > directory? Well, as a starting point, at least - there may be
> > > other
> > > build targets which could benefit from a similar mod, but I'm
> > > building with my own (reduced) feature set, so I may not being
> > > seeing
> > > all of them.
> > > Hopefully it helps though.
> > 
> > NM should support "srcdir != builddir" already, but sometimes bugs
> > creep into the makefiles. What specific error are you getting from
> > the
> > build process?
> > 
> 
> The error log is (bearing in mind this is under Yocto environment):
> 
> DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 
> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
> 'common']
> DEBUG: Executing shell function do_compile
> NOTE: make -j 8
> /usr/bin/perl ../git/tools/enums-to-docbook.pl 'nm-vpn-dbus-types'
> 'VPN Plugin D-Bus API Types' ../git/libnm-core/nm-vpn-dbus-
> interface.h ../git/tools/enums-to-docbook.pl >libnm-core/nm-vpn-dbus-
> types.xml
> /usr/bin/perl ../git/tools/enums-to-docbook.pl 'nm-dbus-types'
> 'NetworkManager D-Bus API Types' ../git/libnm-core/nm-dbus-
> interface.h ../git/tools/enums-to-docbook.pl >libnm-core/nm-dbus-
> types.xml
> /bin/sh: libnm-core/nm-vpn-dbus-types.xml: No such file or directory
> /bin/sh: libnm-core/nm-dbus-types.xml: No such file or directory
> make: *** [libnm-core/nm-vpn-dbus-types.xml] Error 1
> make: *** Waiting for unfinished jobs
> make: *** [libnm-core/nm-dbus-types.xml] Error 1
> ERROR: oe_runmake failed
> ERROR: Function failed: do_compile (log file is located at
> /home/colin/100051-karo/fsl-community-bsp/build/tmp/work/cortexa9hf-
> neon-poky-linux-gnueabi/networkmanager/1.6-
> r0/temp/log.do_compile.6973)
> 
> 'ls ' shows just:
> aclocal-copyconfig.log docslibnm-
> util povapi
> arm-poky-linux-gnueabi-
> libtool  config.status  libnm   Makefile   shared
> config.hdata   libnm-
> glib  NetworkManager.pc  stamp-h1

Does this patch make anything better?

diff --git a/Makefile.am b/Makefile.am
index bacc616..1b9a2b4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -586,12 +586,12 @@ EXTRA_DIST += \
    libnm-core/crypto_nss.c
 
 libnm-core/nm-vpn-dbus-types.xml: libnm-core/nm-vpn-dbus-interface.h 
tools/enums-to-docbook.pl
-   @$(MKDIR_P) libnm-core/
-   $(AM_V_GEN) @PERL@ $(srcdir)/tools/enums-to-docbook.pl 
'nm-vpn-dbus-types' 'VPN Plugin D-Bus API Types' $< >$@
+   @$(MKDIR_P) $(top_builddir)/libnm-core/
+   $(AM_V_GEN) @PERL@ $(srcdir)/tools/enums-to-docbook.pl 
'nm-vpn-dbus-types' 'VPN Plugin D-Bus API Types' $< >$(top_builddir)/$@
 
 libnm-core/nm-dbus-types.xml: libnm-core/nm-dbus-interface.h 
tools/enums-to-docbook.pl
-   @$(MKDIR_P) libnm-core/
-   $(AM_V_GEN) @PERL@ $(srcdir)/tools/enums-to-docbook.pl 'nm-dbus-types' 
'NetworkManager D-Bus API Types' $< >$@
+   @$(MKDIR_P) $(top_builddir)/libnm-core/
+   $(AM_V_GEN) @PERL@ $(srcdir)/tools/enums-to-docbook.pl 'nm-dbus-types' 
'NetworkManager D-Bus API Types' $< >$(top_builddir)/$@
 
 BUILT_SOURCES += \
    libnm-core/nm-vpn-dbus-types.xml \

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

Re: Configure errors under yocto

[Dan Williams]

On Wed, 2017-03-29 at 14:32 +0100, Colin Helliwell wrote:
> > > On 27 March 2017 at 14:25 Colin Helliwell  > > tems.com> wrote:
> > > 
> 
> ...
> > > ... but still have subsequent errors which seem to have been due
> > > to output directories not having been created e.g. libnm-core,
> > > introspection.
> > > I can get it to limp a little further by creating the directories
> > > in the pre-configure, but not totally.
> > > Something perhaps not hooked in right to cater for the build
> > > directory being different to the source directory...?
> 
> May I contribute the attached patch for building-outside-source-
> directory? Well, as a starting point, at least - there may be other
> build targets which could benefit from a similar mod, but I'm
> building with my own (reduced) feature set, so I may not being seeing
> all of them.
> Hopefully it helps though.

NM should support "srcdir != builddir" already, but sometimes bugs
creep into the makefiles.  What specific error are you getting from the
build process?

Dan

> (My configure options, for ref:
> --disable-ifcfg-rh \
> --disable-ifnet \
> --disable-ifcfg-suse \
> --disable-more-warnings \
> --with-iptables=${sbindir}/iptables \
> --with-tests \
> --with-nmtui=no \
> --disable-gtk-doc  --disable-gtk-doc-html \
> --enable-polkit=disabled  --disable-polkit-agent \
> --enable-vala=no
> Yeah - a lot, I know, but I'm targeting a minimal embedded system.
> Sorry!)
> ___
> 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: Differences between GSM modems

[Dan Williams]

On Mon, 2017-03-27 at 17:14 +0100, Colin Helliwell wrote:
> > On 27 March 2017 at 17:02 Dan Williams <d...@redhat.com> wrote:
> > 
> > On Sat, 2017-03-25 at 13:29 +, Colin Helliwell wrote:
> > 
> > > > On 25 March 2017 at 06:31 Dan Williams <d...@redhat.com> wrote:
> > > > 
> > > > On Fri, 2017-03-24 at 13:53 +, Colin Helliwell wrote:
> > > > 
> > > > > > On 23 March 2017 at 19:43 Dan Williams <d...@redhat.com>
> > > > > > wrote:
> > > > > > 
> > > > > > On Thu, 2017-03-23 at 18:26 +, colin.helliwell@ln-syste
> > > > > > ms.c
> > > > > > om
> > > > > > wrote:
> > > > > > 
> > > > > > > NetworkManager[1398]: [1490292215.0368] (ttyMux1): modem
> > > > > > > state
> > > > > > > changed, 'connected' --> 'registered' (reason: user-
> > > > > > > requested)
> > > > > > > NetworkManager[1398]: [1490292215.0371] device (ttyMux1):
> > > > > > > state
> > > > > > > change: activated -> failed (reason 'modem-no-carrier')
> > > > > > > [100
> > > > > > > 120
> > > > > > > 25]
> > > > > > > NetworkManager[1398]: [1490292215.0390]
> > > > > > > active-connection[0x1f38140]: set state deactivated (was
> > > > > > > activated)
> > > > > > > NetworkManager[1398]: [1490292215.0395]
> > > > > > 
> > > > > > We'll need ModemManager logs here; MM is saying the modem
> > > > > > state
> > > > > > changed, possibly due to status changes on the secondary AT
> > > > > > port.
> > > > > > NM
> > > > > > hears that and terminates the connection.
> > > > > 
> > > > > Log including MM below.
> > > > > 
> > > > > But I think I've spotted the cause - the AT+CGACT? is getting
> > > > > a
> > > > > 'deactivated' response (@ 09:28:54). Hence MM seeing it as
> > > > > being
> > > > > disconnected.
> > > > > 
> > > > > As Aleksander commented before (https://lists.freedesktop.org
> > > > > /arc
> > > > > hive
> > > > > s/modemmanager-devel/2017-March/004042.html), it doesn't make
> > > > > sense
> > > > > to have different PDP's across multiple TTYs. And indeed
> > > > > their
> > > > > EHS5
> > > > > appears to behave sensibly i.e. indicates the port 1 PDP as
> > > > > active
> > > > > even if queried over [Primary] port 2.
> > > > > 
> > > > > However, on trawling through the BGS2 docs, I've found that
> > > > > that
> > > > > "PDP
> > > > > contexts can be defined on any [mux] channel, but are visible
> > > > > and
> > > > > usable only on the channel on which they are defined".
> > > > > And doing some manual tests seems to confirm that - they can
> > > > > indeed
> > > > > be set up independantly on different ports. Nice
> > > > > 'feature' :S
> > > > > (I'm wondering if that's also behind some of the other weird
> > > > > sh^t
> > > > > I've been grappling with).
> > > > 
> > > > That is... interesting. And unlike anything I've ever
> > > > encountered
> > > > before :) If there's a way to detect that it's a BGS2, then
> > > > we'll
> > > > need
> > > > to special-case that device and stop ModemManager from polling
> > > > bearer/connection status. We might also need to somehow
> > > > suppress
> > > > the
> > > > MM disconnect behavior of sending CGACT=x,0 on the secondary
> > > > port
> > > > while
> > > > trying to ensure that PPP terminates and the data port returns
> > > > to
> > > > command mode.
> > > 
> > > I wondered about altering the MM behaviour for it too - wasn't
> > > sure
> > > if it would be sane/possible to mess with with its 'view of the
> > > world' though. (Or, especially, worried about the likelihood of
> > > me
> > > doing it badly ;) ). Would it and/or NM lose some of its
> >

Re: NetworkManager general permission issue

[Dan Williams]

On Mon, 2017-03-27 at 13:54 +, Stéphane Boucher wrote:
> I can’t grant modify.system privilege.
> 
> However, I don’t see any pkla file other than mine doing something
> with NetworkManager.
> 
> Is there some place other than the pkla files I should look at for
> NetworkManager

Maybe look in /etc/polkit-1/rules.d and /usr/share/polkit-1/rules.d
too?  Not all polkit files are .pkla, some are .rules.

You could also just grep /etc and /usr/share for "modify\.system" too
and see if you get any hits.

Dan

> I’m on Ubuntu Mate 16.04.
> 
> Thanks.
> 
> $ nmcli g p
> PERMISSION   VALUE
> org.freedesktop.NetworkManager.enable-disable-networkyes
> org.freedesktop.NetworkManager.enable-disable-wifi   yes
> org.freedesktop.NetworkManager.enable-disable-wwan   yes
> org.freedesktop.NetworkManager.enable-disable-wimax  yes
> org.freedesktop.NetworkManager.sleep-wakeyes
> org.freedesktop.NetworkManager.network-control   yes
> org.freedesktop.NetworkManager.wifi.share.protected  yes
> org.freedesktop.NetworkManager.wifi.share.open   yes
> org.freedesktop.NetworkManager.settings.modify.systemno<=
> =
> org.freedesktop.NetworkManager.settings.modify.own   yes
> org.freedesktop.NetworkManager.settings.modify.hostname  yes
> 
> 
> # fgrep -re org.freedesktop.NetworkManager /etc/polkit-1/
> /usr/lib/policykit-1/
> /etc/polkit-1/localauthority/20-org.d/90-
> dbox.pkla:Action=org.freedesktop.NetworkManager.*
> 
> # cat /etc/polkit-1/localauthority/20-org.d/90-dbox.pkla
> [grant network privileges]
> Identity=unix-group:dbox
> Action=org.freedesktop.NetworkManager.*
> ResultAny=yes
> ResultInactive=yes
> ResultActive=yes
> 
> STÉPHANE BOUCHER
> Consultant software
> 
> D-BOX Technologies Inc. | A. 2172 de la Province, Longueuil, QC J4G
> 1R7 CANADA | T. 450-442-3003 | W. d-box.com
> 
> 
> AVIS : Ce courriel contient des renseignements confidentiels. Si vous
> n'êtes pas le véritable destinataire, la diffusion ou l'usage de ce
> courriel, des renseignements qu'il contient ou des documents qui lui
> sont joints pourrait être illégal. Il est donc strictement interdit
> de les diffuser ou de les utiliser. Si vous avez reçu ce courriel par
> erreur, nous vous saurions gré d’en aviser l'expéditeur immédiatement
> et de le supprimer sans le lire, l'imprimer, le sauvegarder ou le
> diffuser. Nous vous remercions de votre aimable collaboration.
> 
> NOTICE: This e-mail contains confidential information. If you are not
> the intended recipient, any disclosure or other use of this e-mail or
> the information contained herein or attached hereto may be unlawful
> and is strictly prohibited. If you have received this e-mail in
> error, please notify the sender immediately and delete this e-mail
> without reading, printing, copying or forwarding it to anyone. Thank
> you for your kind cooperation.
> ___
> 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: Configure errors under yocto

[Dan Williams]

On Mon, 2017-03-27 at 16:12 +0100, Colin Helliwell wrote:
> > On 27 March 2017 at 14:25 Colin Helliwell  > ms.com> wrote:
> > 
> > I think it was missing [under yocto/bitbake] the autogen.sh step.
> > I've corrected that (as a 'pre-configure' step), but still have
> > subsequent errors which seem to have been due to output directories
> > not having been created e.g. libnm-core, introspection.
> > I can get it to limp a little further by creating the directories
> > in the pre-configure, but not totally.
> > Something perhaps not hooked in right to cater for the build
> > directory being different to the source directory...?
> > 
> 
> Subsequent to creating those directories, I can't make out the actual
> failing command line, but the error summary has:
> > to generate clients/cli/settings-docs.c, configure with --enable-
> > introspection
> > alternatively, build --without-nmcli
> > make[2]: *** [clients/cli/settings-docs.c] Error 1
> 
> Neither of which I want to do!
> 
> My configure options are:
> "   --disable-ifcfg-rh \
> --disable-ifnet \
> --disable-ifcfg-suse \
> --disable-more-warnings \
> --with-iptables=${sbindir}/iptables \
> --with-tests \
> --with-nmtui=no \
> --enable-introspection=no \
> --disable-gtk-doc  --disable-gtk-doc-html \
> --enable-polkit=disabled  --disable-polkit-agent "
> 
> I'm pulling the nm-1-6 branch from anongit.freedesktop.org, by the
> way. (1.6.3 I think?)

The build process takes Introspection data from the NM objects
(NMDevice, NMConnection, etc) and generates files that nmcli uses to
provide help text, properties, etc, rather than hardcoding things
twice.  So unfortunately, if you want nmcli you also need --enable-
introspection.

Do you have gobject-introspection devel packages for Yocto you can
install?

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

Re: Differences between GSM modems

[Dan Williams]

On Sat, 2017-03-25 at 13:29 +, Colin Helliwell wrote:
> > On 25 March 2017 at 06:31 Dan Williams <d...@redhat.com> wrote:
> > 
> > On Fri, 2017-03-24 at 13:53 +, Colin Helliwell wrote:
> > 
> > > > On 23 March 2017 at 19:43 Dan Williams <d...@redhat.com> wrote:
> > > > 
> > > > On Thu, 2017-03-23 at 18:26 +, colin.helliwell@ln-systems.c
> > > > om
> > > > wrote:
> > > > 
> > > > > NetworkManager[1398]: [1490292215.0368] (ttyMux1): modem
> > > > > state
> > > > > changed, 'connected' --> 'registered' (reason: user-
> > > > > requested)
> > > > > NetworkManager[1398]: [1490292215.0371] device (ttyMux1):
> > > > > state
> > > > > change: activated -> failed (reason 'modem-no-carrier') [100
> > > > > 120
> > > > > 25]
> > > > > NetworkManager[1398]: [1490292215.0390]
> > > > > active-connection[0x1f38140]: set state deactivated (was
> > > > > activated)
> > > > > NetworkManager[1398]: [1490292215.0395]
> > > > 
> > > > We'll need ModemManager logs here; MM is saying the modem state
> > > > changed, possibly due to status changes on the secondary AT
> > > > port.
> > > > NM
> > > > hears that and terminates the connection.
> > > 
> > > Log including MM below.
> > > 
> > > But I think I've spotted the cause - the AT+CGACT? is getting a
> > > 'deactivated' response (@ 09:28:54). Hence MM seeing it as being
> > > disconnected.
> > > 
> > > As Aleksander commented before (https://lists.freedesktop.org/arc
> > > hive
> > > s/modemmanager-devel/2017-March/004042.html), it doesn't make
> > > sense
> > > to have different PDP's across multiple TTYs. And indeed their
> > > EHS5
> > > appears to behave sensibly i.e. indicates the port 1 PDP as
> > > active
> > > even if queried over [Primary] port 2.
> > > 
> > > However, on trawling through the BGS2 docs, I've found that that
> > > "PDP
> > > contexts can be defined on any [mux] channel, but are visible and
> > > usable only on the channel on which they are defined".
> > > And doing some manual tests seems to confirm that - they can
> > > indeed
> > > be set up independantly on different ports. Nice 'feature' :S
> > > (I'm wondering if that's also behind some of the other weird sh^t
> > > I've been grappling with).
> > 
> > That is... interesting. And unlike anything I've ever encountered
> > before :) If there's a way to detect that it's a BGS2, then we'll
> > need
> > to special-case that device and stop ModemManager from polling
> > bearer/connection status. We might also need to somehow suppress
> > the
> > MM disconnect behavior of sending CGACT=x,0 on the secondary port
> > while
> > trying to ensure that PPP terminates and the data port returns to
> > command mode.
> > 
> 
> I wondered about altering the MM behaviour for it too - wasn't sure
> if it would be sane/possible to mess with with its 'view of the
> world' though. (Or, especially, worried about the likelihood of me
> doing it badly ;) ). Would it and/or NM lose some of its consequent
> abilities by no longer polling the connection status?

If the connection drops, but pppd is unable to figure that out (because
the firmware doesn't send the LCP TermReq or something), then you'll
have to have an external script manually do health checking and kill
the connection when it times out.

MM's connection polling is an attempt to see whether this has happened
through actual modem commands (as opposed to an IP 'ping' or something)
and handle termination.  You don't get that if you're using PPP and
can't reference the PDP context on a secondary port.

> In part I'm tempted to drop the BGS2 as a 'bad job' and just use
> EHS5. Trouble is that many of our applications don't need the 3G
> capability of the latter, and there's quite a significant difference
> in BOM cost between the two.

Eh, it doesn't sound *that* bad, we can make it work.  As long as there
aren't too many more oddities...

> I guess the "model" string would identify it?

Is it serially connected?  Or USB?

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

Re: Python Wifi scan

[Dan Williams]

On Mon, 2017-03-27 at 12:27 +0200, Francesco Andrisani wrote:
> Hi,
> please can someone help me to find an example to wifi net scanning in
> python?
> I find only an example with C.

There's already one that uses GObject Introspection:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/gi/show-wifi-networks.py

And there is one for plain D-Bus, though somewhat confusingly named:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/dbus/show-bssids.py

Do either of those help?

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

Re: Differences between GSM modems

[Dan Williams]

On Fri, 2017-03-24 at 13:53 +, Colin Helliwell wrote:
> > On 23 March 2017 at 19:43 Dan Williams <d...@redhat.com> wrote:
> > 
> > On Thu, 2017-03-23 at 18:26 +, colin.helliw...@ln-systems.com
> > wrote:
> > 
> > > NetworkManager[1398]:  [1490292215.0368] (ttyMux1): modem
> > > state
> > > changed, 'connected' --> 'registered' (reason: user-requested)
> > > NetworkManager[1398]:  [1490292215.0371] device (ttyMux1):
> > > state
> > > change: activated -> failed (reason 'modem-no-carrier') [100 120
> > > 25]
> > > NetworkManager[1398]:  [1490292215.0390]
> > > active-connection[0x1f38140]: set state deactivated (was
> > > activated)
> > > NetworkManager[1398]:  [1490292215.0395]
> > 
> > We'll need ModemManager logs here; MM is saying the modem state
> > changed, possibly due to status changes on the secondary AT port.
> > NM
> > hears that and terminates the connection.
> > 
> 
> Log including MM below.
> 
> But I think I've spotted the cause - the AT+CGACT? is getting a
> 'deactivated' response (@ 09:28:54). Hence MM seeing it as being
> disconnected.
> 
> As Aleksander commented before (https://lists.freedesktop.org/archive
> s/modemmanager-devel/2017-March/004042.html), it doesn't make sense
> to have different PDP's across multiple TTYs. And indeed their EHS5
> appears to behave sensibly i.e. indicates the port 1 PDP as active
> even if queried over [Primary] port 2.
> 
> However, on trawling through the BGS2 docs, I've found that that "PDP
> contexts can be defined on any [mux] channel, but are visible and
> usable only on the channel on which they are defined". 
> And doing some manual tests seems to confirm that - they can indeed
> be set up independantly on different ports. Nice 'feature'  :S
> (I'm wondering if that's also behind some of the other weird sh^t
> I've been grappling with).

That is... interesting.  And unlike anything I've ever encountered
before :)  If there's a way to detect that it's a BGS2, then we'll need
to special-case that device and stop ModemManager from polling
bearer/connection status.  We might also need to somehow suppress the
MM disconnect behavior of sending CGACT=x,0 on the secondary port while
trying to ensure that PPP terminates and the data port returns to
command mode.

Dan

> 
> 
> Mar 24 09:28:46 w2 NetworkManager[23563]: NetworkManager[23563]:
>  [1490347726.6780] agent-manager: req[0x1733b58, :1.15/nmcli-
> connect/0]: requesting permissions
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.6780]
> agent-manager: req[0x1733b58, :1.15/nmcli-connect/0]: requesting
> permissions
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.6852]
> agent-manager: req[0x1733b58, :1.15/nmcli-connect/0]: agent
> registered
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.6941]
> policy: re-enabling autoconnect for all connections with failed
> secrets
> Mar 24 09:28:46 w2 NetworkManager[23563]: NetworkManager[23563]:
>  [1490347726.6852] agent-manager: req[0x1733b58, :1.15/nmcli-
> connect/0]: agent registered
> Mar 24 09:28:46 w2 NetworkManager[23563]: NetworkManager[23563]:
>  [1490347726.6941] policy: re-enabling autoconnect for all
> connections with failed secrets
> Mar 24 09:28:46 w2 NetworkManager[23563]: NetworkManager[23563]:
>  [1490347726.7106] active-connection[0x1713140]: set device
> "ttyMux1" [0x1730368]
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.7106]
> active-connection[0x1713140]: set device "ttyMux1" [0x1730368]
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.7202]
> device[0x1730368] (ttyMux1): add_pending_action (1):
> 'activation::0x1713140'
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.7206]
> active-connection[0x1713140]: constructed (NMActRequest, version-id
> 2)
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.7242]
> device[0x1730368] (ttyMux1): add_pending_action (2): 'autoactivate'
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.7248]
> device[0x1730368] (ttyMux1): remove_pending_action (1):
> 'autoactivate'
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.7252]
> device[0x1730368] (ttyMux1): unmanaged: flags set to
> [!sleeping,!loopback,!platform-init,!user-explicit,!user-
> settings=0x0/0x79/managed, set-managed [user-explicit=0x20], reason
> user-requested)
> Mar 24 09:28:46 w2 NetworkManager[23563]:   [1490347726.7456]
> device (ttyMux1): Activation: starting connection 'Vodafone'
> (e0f97177-2f8e-4ed4-9942-7b4e499397cc)
> Mar 24 09:28:46 w2 NetworkManager[23563]:  [1490347726.7459]
> device[0x1730368] (ttyMux1): activation-stage: schedule
> activate

Re: Configure errors under yocto

[Dan Williams]

On Fri, 2017-03-24 at 16:07 +, colin.helliw...@ln-systems.com
wrote:
> Just trying to migrate my build from 1.4.2 (from a tarball) to 1.6
> (from
> git), but getting some errors in the configure.
> I am passing some additional configure options, but this seems to be
> something more basic?

Default configure options will build documentation, which requires gtk-
doc.  If you don't have that or don't care about documentation and
manpages, you can pass --disable-gtk-doc at configure/autogen time.

Dan

> $ ls
> tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/networkmanager/1.6-
> r0/git/bu
> ild-aux
> compile  config.guess  config.sub  depcomp  install-
> sh  ltmain.sh  missing
> tap-driver.sh  test-driver
> 
> (I also need the same 'touch ${S}/ABOUT-NLS' that I need for building
> ModemManager -
> https://lists.freedesktop.org/archives/modemmanager-devel/2017-Februa
> ry/0039
> 41.html )
> 
> 
> DEBUG: Executing python function sysroot_cleansstate
> DEBUG: Python function sysroot_cleansstate finished
> DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
> 'common']
> DEBUG: Executing shell function autotools_preconfigure
> DEBUG: Shell function autotools_preconfigure finished
> DEBUG: Executing python function autotools_copy_aclocals
> DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
> 'common']
> DEBUG: Python function autotools_copy_aclocals finished
> DEBUG: Executing shell function do_configure
> automake (GNU automake) 1.15
> Copyright (C) 2014 Free Software Foundation, Inc.
> License GPLv2+: GNU GPL version 2 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by Tom Tromey 
>    and Alexandre Duret-Lutz .
> AUTOV is 1
> NOTE: Executing intltoolize --copy --force --automake
> NOTE: Executing ACLOCAL="aclocal
> --system-acdir=/home/colin/100051-karo/fsl-community-
> bsp/build/tmp/work/cort
> exa9hf-vfp-neon-poky-linux-gnueabi/networkmanager/1.6-
> r0/build/aclocal-copy/
> " autoreconf --verbose --install --force --exclude=autopoint -I
> /home/colin/100051-karo/fsl-community-bsp/build/tmp/work/cortexa9hf-
> vfp-neon
> -poky-linux-gnueabi/networkmanager/1.6-r0/git/m4/
> autoreconf: Entering directory `.'
> autoreconf: running: aclocal
> --system-acdir=/home/colin/100051-karo/fsl-community-
> bsp/build/tmp/work/cort
> exa9hf-vfp-neon-poky-linux-gnueabi/networkmanager/1.6-
> r0/build/aclocal-copy/
> -I
> /home/colin/100051-karo/fsl-community-bsp/build/tmp/work/cortexa9hf-
> vfp-neon
> -poky-linux-gnueabi/networkmanager/1.6-r0/git/m4/ -I
> /home/colin/100051-karo/fsl-community-bsp/build/tmp/work/cortexa9hf-
> vfp-neon
> -poky-linux-gnueabi/networkmanager/1.6-r0/git/m4/ --force
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: creating directory build-aux
> autoreconf: running: libtoolize --copy --force
> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-
> aux'.
> libtoolize: copying file 'build-aux/ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
> libtoolize: copying file 'm4/libtool.m4'
> libtoolize: copying file 'm4/ltoptions.m4'
> libtoolize: copying file 'm4/ltsugar.m4'
> libtoolize: copying file 'm4/ltversion.m4'
> libtoolize: copying file 'm4/lt~obsolete.m4'
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in
> Makefile.am.
> autoreconf: running:
> /home/colin/100051-karo/fsl-community-bsp/build/tmp/sysroots/x86_64-
> linux/us
> r/bin/autoconf
> --include=/home/colin/100051-karo/fsl-community-
> bsp/build/tmp/work/cortexa9h
> f-vfp-neon-poky-linux-gnueabi/networkmanager/1.6-r0/git/m4/ --force
> autoreconf: running:
> /home/colin/100051-karo/fsl-community-bsp/build/tmp/sysroots/x86_64-
> linux/us
> r/bin/autoheader
> --include=/home/colin/100051-karo/fsl-community-
> bsp/build/tmp/work/cortexa9h
> f-vfp-neon-poky-linux-gnueabi/networkmanager/1.6-r0/git/m4/ --force
> autoreconf: running: automake --add-missing --copy --force-missing
> configure.ac:24: installing 'build-aux/compile'
> configure.ac:43: installing 'build-aux/config.guess'
> configure.ac:68: error: required file 'build-aux/config.rpath' not
> found
> configure.ac:43: installing 'build-aux/config.sub'
> configure.ac:19: installing 'build-aux/install-sh'
> configure.ac:19: installing 'build-aux/missing'
> configure.ac:17: installing 'build-aux/tap-driver.sh'
> Makefile.am: installing './INSTALL'
> Makefile.am: installing 'build-aux/depcomp'
> parallel-tests: installing 'build-aux/test-driver'
> automake: error: cannot open < gtk-doc.make: No such file or
> directory
> autoreconf: automake failed with exit status: 1
> ERROR: autoreconf execution failed.
> 
> 
> 
> ___
> networkmanager-list 

Re: Differences between GSM modems

[Dan Williams]

On Fri, 2017-03-24 at 12:19 +0100, Thomas Haller wrote:
> On Thu, 2017-03-23 at 18:26 +, colin.helliw...@ln-systems.com
> wrote:
> > 
> > systemctl stop NetworkManager[because the service is enabled in
> > systemd]
> > NM_PPP_DEBUG=1 NetworkManager --no-daemon --debug --log-
> > level=DEBUG   [in
> > order to easily catch the debug output]
> 
> [[OFF-TOPIC]]
> 
> btw, instead of setting the environment variable, you can also enable
> logging of pppd via 
>   sudo nmcli general logging level KEEP domains PPP:DEBUG
> or with /etc/NetworkManager/NetworkManager.conf
>   [logging]
>   domains=ALL
>   level=TRACE
> 
> See https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/s
> rc/ppp/nm-ppp-
> manager.c?id=b11b6038792a3da3f47717129580d7c661140291#n749

Aha, you are correct; I was looking at NM 1.4.2 sources.

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

Re: Differences between GSM modems

[Dan Williams]

On Thu, 2017-03-23 at 18:26 +, colin.helliw...@ln-systems.com
wrote:
> NetworkManager[1398]:   [1490292215.0368] (ttyMux1): modem
> state
> changed, 'connected' --> 'registered' (reason: user-requested)
> NetworkManager[1398]:   [1490292215.0371] device (ttyMux1):
> state
> change: activated -> failed (reason 'modem-no-carrier') [100 120 25]
> NetworkManager[1398]:  [1490292215.0390]
> active-connection[0x1f38140]: set state deactivated (was activated)
> NetworkManager[1398]:  [1490292215.0395]

We'll need ModemManager logs here; MM is saying the modem state
changed, possibly due to status changes on the secondary AT port.  NM
hears that and terminates the connection.

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

Re: LibNM in C++ Wireless management

[Dan Williams]

On Wed, 2017-03-22 at 18:07 +0100, Francesco Andrisani wrote:
> I started to work on an application that use LibNM for wireless
> netwoak
> management (Scan, Connection, disconnection).
> I successfull write a scanning interface helped by the examples at
> this
> page
> https://github.com/lcp/NetworkManager/blob/master/examples/C/glib/get
> -ap-info-libnm-glib.c
> but my question is...can someone help me to know how can I manage
> connection and disconnection of wireless (wifi) board.
> I tried to find some examples, but nothing.

Some examples are here:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/C/glib/add-connection-libnm.c
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/C/glib/list-connections-libnm.c

and there are more in other languages.

The general process is that you need a "Connection" object to describe
the properties the network connection requires.  To connect to an AP,
you'd do something like:

1) identify the AP you want to connect to (see get-ap-info-libnm.c)

2) check if there's an existing WiFi connection for that SSID already
defined; if there is, just activate it with ActivateConnection()

3) if there isn't, you can call AddAndActivateConnection() with the AP
object and NetworkManager will fill in the details for you

to disconnect, you can get the current active connection on the device
and call DeactivateConnection().  Or you can call the Disconnect()
method on the device which doesn't require a conneciton, but that will
block further autoconnects.

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

[PATCH] ppp: only request IPV6CP when IPv6 is enabled in the connection

[Dan Williams]

NM always asks pppd to run IPV6CP which will complete if the modem supports
IPv6.  If the user doesn't want IPv6 then NM just ignores the result.  But
if the host has disabled IPv6, then pppd will fail to complete the connection
because pppd tries to assign the Link-Local address to the pppX interface,
and if IPv6 is disabled that fails and terminates the PPP session.

So only request IPV6CP when the user wants IPv6 on the connection; if they
have disabled IPv6 on their host then they can simply set ipv6.method=ignore.
---
 src/ppp/nm-ppp-manager.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/src/ppp/nm-ppp-manager.c b/src/ppp/nm-ppp-manager.c
index a51f7cf..b5270f8 100644
--- a/src/ppp/nm-ppp-manager.c
+++ b/src/ppp/nm-ppp-manager.c
@@ -834,6 +834,7 @@ create_pppd_cmd_line (NMPPPManager *self,
   NMSettingAdsl  *adsl,
   const char *ppp_name,
   guint baud_override,
+  gboolean ip6_enabled,
   GError **err)
 {
NMPPPManagerPrivate *priv = NM_PPP_MANAGER_GET_PRIVATE (self);
@@ -857,9 +858,11 @@ create_pppd_cmd_line (NMPPPManager *self,
/* NM handles setting the default route */
nm_cmd_line_add_string (cmd, "nodefaultroute");
 
-   /* Allow IPv6 to be configured by IPV6CP */
-   nm_cmd_line_add_string (cmd, "ipv6");
-   nm_cmd_line_add_string (cmd, ",");
+   if (ip6_enabled) {
+   /* Allow IPv6 to be configured by IPV6CP */
+   nm_cmd_line_add_string (cmd, "ipv6");
+   nm_cmd_line_add_string (cmd, ",");
+   }
 
ppp_debug = !!getenv ("NM_PPP_DEBUG");
if (nm_logging_enabled (LOGL_DEBUG, LOGD_PPP))
@@ -1034,6 +1037,8 @@ nm_ppp_manager_start (NMPPPManager *manager,
NMCmdLine *ppp_cmd;
char *cmd_str;
struct stat st;
+   const char *ip6_method;
+   gboolean ip6_enabled = FALSE;
 
g_return_val_if_fail (NM_IS_PPP_MANAGER (manager), FALSE);
g_return_val_if_fail (NM_IS_ACT_REQUEST (req), FALSE);
@@ -1076,7 +1081,10 @@ nm_ppp_manager_start (NMPPPManager *manager,
 
adsl_setting = (NMSettingAdsl *) nm_connection_get_setting (connection, 
NM_TYPE_SETTING_ADSL);
 
-   ppp_cmd = create_pppd_cmd_line (manager, s_ppp, pppoe_setting, 
adsl_setting, ppp_name, baud_override, err);
+   ip6_method = nm_utils_get_ip_config_method (connection, 
NM_TYPE_SETTING_IP6_CONFIG);
+   ip6_enabled = g_strcmp0 (ip6_method, NM_SETTING_IP6_CONFIG_METHOD_AUTO) 
== 0;
+
+   ppp_cmd = create_pppd_cmd_line (manager, s_ppp, pppoe_setting, 
adsl_setting, ppp_name, baud_override, ip6_enabled, err);
if (!ppp_cmd)
goto out;
 
-- 
2.9.3
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list