Re: How to probe a modem exposing virtual ports (GSM 07.10 muxed ports)
No unfortunately they are not. They (the psuedo terminals) are created by opening /dev/ptmx which creates a terminal(s) in /dev/pts/ . These are not enumerated in any way. Oh well... let me try your suggestion and see if it works. On 4/9/24 11:05, Aleksander Morgado wrote: On Tue, Apr 2, 2024 at 3:43 PM Garfield Watkins wrote: Unfortunately there doesn't seem to be a way for to write a udev rule against a pseudo terminal... Are they not notified via udev really? You could also try to set it up with ModemManager not running with udev support (--test-no-udev) and then report the ports manually with mmcli (--report-kernel-event).
Re: How to recover from serial device being force closed.
Hey! > > I completely understand why there may be concerns at editing such critical > code for a use case that is not very common. > > Unfortunately my current situation requires renaming the interfaces. Multiple > modems may take turns being 'selected' (having the interface renamed) to pass > traffic. I hope to remove that need one day, but until then I will need this > patch. > So you have a modem that is in connected state but isn't selected to pass traffic, and when it gets selected, the net interface is renamed to some other name? I think it is the first time I've seen something like this :) Is it because some other app uses a hardcoded net interface name somewhere or something like that? > Even if this is an uncommon problem, I still think this change (or at least > my approach) could be useful to pull into ModemManager mainline. Yes, people > don't rename interfaces often, but it is something that Linux/udev support, > these events effectively breaks the Modem object lifecycle in ModemManager > (which makes ModemManager look buggy), the log messages that are printed out > do not make it clear that renaming the interface caused it (it took my a long > time to figure it out), and I have not seen any piece of documentation > warning that renaming any interface managed by ModemManager is unsupported. > Technically it is completely possible, but my worry is that it may introduce an amount of complexity that is not worth the effort. Updating the documentation to say that MM currently does not support interface renaming once the device has been initially probed would be quicker... and maybe we should do that right away even before thinking about supporting your usecase. > You do bring up an interesting point I had missed: what if someone renamed a > control interface? My code currently would not catch that, but maybe it > should! > Renaming the control interface would be overkill. Renaming the net port may be somewhat easier. > ModemManager handles tons of events and states for modems and all the weird > things they can do. If a user could do something with the ModemManager API > that caused strange errors like I described, the issue would be fixed in the > driver/etc. > > Linux Interfaces can be renamed using the Linux API, and while they are > renamed, ModemManager is in a precarious state until the interface is changed > back to its original name. Removing or resetting the modem in that precarious > state will cause ModemManager to act strangely for that modem until it is > removed again with the original interface name (which could be a problem if > another modem was added while the interface was renamed). And linux+udev > gives us all the tools to handle these known and supported events. I > personally think these are enough reasons to address this behavior. > > I see this as an issue of stability, reliability, and resiliency. Even if > this behavior is rarely encountered, I believe there are substantial reasons > to fix it. That does not mean that my code is the best way to do it. If you > end up agreeing that this behavior should be fixed, I will make revisions to > address your concerns. > MM also has a lot of limitations, and one of the limitations that I always warn about is that the state of the modem should not be touched out of MM's own APIs. E.g. if you run QMI commands that modify the state of the modem using qmicli, MM may not pick them up. If the state needs to be updated, it should be done using MM's own APIs. I think we can say the same about this problem, you're trying to modify the state of how the modem is exposed in the kernel out of MM's eyes, and expect MM to pick that up. Technically both things could be possible, but it may really be too much complexity introduced for little gain, especially when the issues can be avoided in other ways :/ > To the complexity of my code, I tried to made it pretty straight forward and > self contained. When a rename event happens, find the Modem object associated > with the old device name, remove the old name from the modem, and add the new > name. I could make the replacement logic into a function to keep the code > more readable if you would prefer. > Aren't we fully re-probing the modem from scratch upon the net interface rename? We could try to do that as an initial step, in the same way as we do the forced reprobing when e.g. the proxy dies or when the SIM card is switched. The reprobing logic will make MM re-detect the modem object with the new state. > You mention opening the door to more complex interactions, and that is > interesting. If I don't correctly handle the udev events, then I am not > really fixing anything! > > I just looked up all of the udev event types: add, remove, change, move, > online, offline, bind, and unbind. > > ModemManager already has support for add, remove, change (kind of, more on > that later), and with my patch move (I would argue that the upstream version > of
Re: Empty APN, 2 PDP contexts and 1 PDP context
Hey!
>
> First of all I wanted to say thanks for developing and supporting a great
> piece of software.
>
Thanks to you for using it!
> We have a few thousand devices running ModemManager 1.18.6 and Quectel EC21
> modem. Our service provider Twilio/Kore keeps reporting that on some devices
> we have 2 simultaneous data sessions with different APNs: "super" and
> "de1.super".
>
> We use ModemManager's API to find the modem, enable it, then wait for
> auto-register done by the modem FW, and finally create a bearer with
> "de1.super" APN and connect. Operations are run over QMI protocol.
>
Ok, so if I'm reading this right, you do NOT explicitly configure the
attach APN settings, you only provide the data APN settings. The
attach APN settings are provided by the modem itself.
> We have autoselect disabled, so I'd expect to always use European APN
> "de1.super", instead of US "super" which is the default.
> mmcli -m 0 --command='AT+QMBNCFG="AutoSel"' response: '+QMBNCFG: "AutoSel",0
I don't know what AutoSel does in these modems, can you elaborate?
> We have made an experiment to show PDP contexts on the devices with
> AT+CGDCONT?, and noticed an interesting thing:
> On most of them, it only shows 1 PDP context:
> PdpContext { ctx_id: 1, pdp_type: IpV4V6, pdp_addr:
> \"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0\", apn: \"\", data_comp: Off, head_comp:
> Off, ipv4_addr_alloc: NasSignaling, request_type:
> ContextEstablishmentOrNon3GppAccessNetworkHandover }
>
> However, on 1 of the 200 devices, we see 2 PDP contexts:
> PdpContext { ctx_id: 2, pdp_type: Ip, pdp_addr: \"0.0.0.0\", apn:
> \"de1.super\", data_comp: Off, head_comp: Off, ipv4_addr_alloc: NasSignaling,
> request_type: ContextEstablishmentOrNon3GppAccessNetworkHandover }
>
> PdpContext { ctx_id: 1, pdp_type: IpV4V6, pdp_addr:
> \"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0\", apn: \"\", data_comp: Off, head_comp:
> Off, ipv4_addr_alloc: NasSignaling, request_type:
> ContextEstablishmentOrNon3GppAccessNetworkHandover }
>
> However, even on device with just 1 PDP context received from AT command
> # mmcli -m 0 --command='AT+CGDCONT?'
> response: '+CGDCONT: 1,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0'
>
> AT commands are run ~10 minutes after modem setup and connection is done with
> ModemManager.
> ModemManager always reports 2 bearers, I understand the 1st bearer is LTE
> default EPS bearer, while the 2nd one is the actual data session bearer:
>
Yes.
> # mmcli -b 0
> -
> General|path: /org/freedesktop/ModemManager1/Bearer/0
> |type: default-attach
> -
> Status | connected: yes
> | suspended: no
> | multiplexed: no
> | ip timeout: 20
> -
> Properties | apn: super
> | ip type: ipv4
>
> # mmcli -b 3
>
> General| path: /org/freedesktop/ModemManager1/Bearer/3
> | type: default
>
> Status | connected: yes
> | suspended: no
> |multiplexed: no
> | interface: wwan0
> | ip timeout: 20
>
> Properties |apn: de1.super
> |roaming: allowed
> |ip type: ipv4
>
> IPv4 configuration | method: static
> |address: 100.79.145.117
> | prefix: 30
> |gateway: 100.79.145.118
> |dns: 8.8.4.4, 8.8.8.8
> |mtu: 1360
>
> Statistics | duration: 3810
> | bytes rx: 513071
> | bytes tx: 296673
> | attempts: 1
> | total-duration: 3810
> | total-bytes rx: 513071
> | total-bytes tx: 296673
>
In the above output, your initial EPS default bearer that is brought
up during attach is using the "super" APN. I don't think this is what
you want, based on the previous comments? Not sure.
> I have some questions:
> 1. When using QMI, is it reliable to check modem state with AT commands? I
> don't care about immediate / race conditions, but I'd like to know that if I
> run some AT command e.g. 1 hour after it was set up by ModemManager with QMI
> it will tell me the accurate modem state.
>
Yes. As long as you don't modify state of the modem with the AT
commands, i.e. only use commands to read the state, you can safely run
them and they will give you the latest up to date info.
> 2. Why do some devices have only 1 PDP context with
Re: How to probe a modem exposing virtual ports (GSM 07.10 muxed ports)
Is there any other workaround you can suggest ? I really do need these virtual terminals exposed by the multiplexer. On 4/9/24 11:24, Aleksander Morgado wrote: Hey No unfortunately they are not. They (the psuedo terminals) are created by opening /dev/ptmx which creates a terminal(s) in /dev/pts/ . These are not enumerated in any way. Oh well... let me try your suggestion and see if it works. If the ptys don't have an entry in sysfs, not even as virtual devices, then the no-udev path won't work either
Re: Modems not detected with the latest MM
Hey Radu, > > I attached 1 OK log (ModemManager-1.23.4-ok.log - git > 6a8797927c1ef9df1f56513b742f01de86f5167f), and one not ok log > (ModemManager-1.23.5-nok.log git 6388b583c7b9c25d3061a070f54f9d97d59e2b2c). > > Please let me know if I can be of any help. > Radu > I looked at the two logs and I cannot find any reason why mmcli would not report the modems. I can see the 2 modems being detected in both logs, and in both of them the "exported modem at path '/org/freedesktop/ModemManager1/Modem..." logs happen, showing that they are being exposed in DBus. I'm really interested in knowing why this failed for you, could you please try with the latest git main branch and maybe even run a git bisect between the two version to see if we find which commit is causing the problem? -- Aleksander
Re: How to probe a modem exposing virtual ports (GSM 07.10 muxed ports)
On Tue, Apr 2, 2024 at 3:43 PM Garfield Watkins wrote: > > Unfortunately there doesn't seem to be a way for to write a udev rule against > a pseudo terminal... > Are they not notified via udev really? You could also try to set it up with ModemManager not running with udev support (--test-no-udev) and then report the ports manually with mmcli (--report-kernel-event). -- Aleksander
Re: How to probe a modem exposing virtual ports (GSM 07.10 muxed ports)
Hey > > No unfortunately they are not. They (the psuedo terminals) are created by > opening /dev/ptmx which creates a terminal(s) in /dev/pts/ . These are not > enumerated in any way. Oh well... let me try your suggestion and see if it > works. > If the ptys don't have an entry in sysfs, not even as virtual devices, then the no-udev path won't work either -- Aleksander
