GNOME.org
 

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

Hello Thomas,

Thank you for the info.
Everything seems to sort of kind of work now.

On Sat, 21 Sep 2019 at 10:05, Thomas Haller <thaller redhat com> wrote:


On Fri, 2019-09-13 at 15:07 +0200, Einar Jón wrote:

Hi Dan

You've answered a bunch of my questions on modemmanager-list.
Thanks for your patience.

On Wed, 11 Sep 2019 at 15:14, Dan Williams <dcbw redhat com> wrote:

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 <thaller redhat com>
wrote:

On Wed, 2019-09-04 at 21:59 +0200, Einar Jón wrote:

On Wed, 4 Sep 2019 at 17:11, Thomas Haller <
thaller redhat com>
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 mobileXXXX profiles and NM is smart enough
to get the correct one and connect on startup, without even
needing
nmcli device connect $MODEM

$ nmcli connection
NAME                UUID                                  TYPE
   D
EVICE
eth0                7f79871d-15ff-446a-b1c3-
5978c81c176b  ethernet  eth0
eth1                5317eb97-1514-4852-b120-
ab4fa9173350  ethernet  eth1
mobile20404         ef48d247-00df-433a-bf6a-
97ad54e3b757  gsm       cdc-wdm0
mobile21407         b9d37621-32c9-4073-8848-
86dd8814f503  gsm       -
-
<snip> 4 similar lines <snip>
mobile234507        3d473ad6-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?


Actually, it seems to work fine. It's a brilliantly stupid solution.
I just added an additional profile roaming${IMSI} without the
network-id, and it works.
$ nmcli c s
NAME           UUID                                  TYPE  DEVICE
roaming21407   b9d37622-32c9-4073-8848-86dd8814f503  gsm   cdc-wdm0
mobile20404    ef48d247-00df-433a-bf6a-97ad54e3b757  gsm   --
mobile21407    b9d37621-32c9-4073-8848-86dd8814f503  gsm   --
....

Since I'm started, I still have a few more questions:
1) How does NetworkMananger decide which connection to try?
I.e. how do I set the priority of mobile21407 higher than
roaming21407?


Whenever a device or a profile changes, a check whether to autoconnect
may happen. E.g. plug-in cable in device, plug-in USB-device,
create/modify a profile.

In that case, NM looks at the device in question. This device must be
in state DISCONNECTED and not having autoconnect blocked. Autoconnect
gets for example blocked by `nmcli connection down` or `nmcli device
disconnect`.

Then, it creates a list of all profiles that are suitable candidates to
autoconnect on the device. That requires:

 - profile is compatible with the device
 - profile has "connection.autoconnect" enabled
 - profile is not blocked from autoconnect (e.g. after autoconnect
   fails a few times, it gets blocked for a time, or after `nmcli
   connection down`).
 - profile was connected in the past at least once successfully. That
   is, it has a connection timestamp set.
 - the profile must not be currently active/activating on another
   device (unless "connection.multi-connect" is enabled).

Then, profiles are sorted based on "connection.autoconnect-priority"
and further by last activation timestamp. And finally the most recent
connection will start autoconnecting.


I added roaming profiles with a lower connection.autoconnect-priority
(higher number), and that seems to work.
I do sometimes swap between them in certain situations, but it seems OK.
2019-09-23T11:13:10.212343+02:00 T175-EH1-1834-001
modem-monitor-nm[1283]: Active connection changed from roaming310170
to mobile310170
2019-09-23T11:23:58.838619+02:00 T175-EH1-1834-001
modem-monitor-nm[1283]: Active connection changed from mobile310170 to
roaming310170
2019-09-23T11:31:16.790939+02:00 T175-EH1-1834-001
modem-monitor-nm[1283]: Active connection changed from roaming310170
to mobile310170
2019-09-23T11:46:58.837791+02:00 T175-EH1-1834-001
modem-monitor-nm[1283]: Active connection changed from mobile310170 to
roaming310170
2019-09-23T11:51:46.996851+02:00 T175-EH1-1834-001
modem-monitor-nm[1283]: Active connection changed from roaming310170
to mobile310170
2019-09-23T11:56:35.194220+02:00 T175-EH1-1834-001
modem-monitor-nm[1283]: Active connection changed from mobile310170 to
roaming310170




2) I notice that my up, down lines in /etc/network/interfaces.d/wwan0
and
scripts in /etc/network/if-*.d/ are ignored.
How do run extra stuff on ifup/ifdown?
managed=true in the [ifupdown] section doesn't seem to help.


You could place a script to /etc/NetworkManager/dispatcher.d. See `man
NetworkManager`.


I figured that out in the end, but it was tricky because for me it is
called with
"wwan0" "up" and "cdc-wdm0" "down".


3) NetworkMananger either clobbers /etc/resolv.conf or ignores it.
Is there any way to get NetworkMananger to get along with udhcpc?
I could probably use rc-manager=resolvconf, but then I need to
rework udhcpc and udhcpc6 to work with openresolv, which is a PITA.


Yes, using resolveconf sounds most sensible. That's why it exists after
all. You may also set rc-manager=unmanaged and script whatever you
like. Maybe triggered by a dispatcher script. Note that NM writes two
files

  /run/NetworkManager/resolv.conf
  /run/NetworkManager/no-stub-resolv.conf

that contain the name servers too. You can also get the name servers
from D-Bus. See the output of plain `nmcli`.


I don't get no-stub-resolv.conf. But it doesn't matter. I added a
bastardized version
of openresolv-3.7.2/debian/openresolv.000resolvconf.if-up into
/usr/share/udhcpc/default.script.d/000resolvconf and that does the trick.
Yay for BSD license.
So the ethernet devices are handled by that, and NetworkManager does the modem.
I think that's all I need.

-- 
Thanks again
Einar Jón
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]