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.
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`.
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`. best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part