> > > > However, after approximately five minutes of using and examining these > interfaces, I noticed the second bearer connection had failed with an > unknown error and mbimmux0.2 had been removed from the list of interfaces: > > user@ubuntu22a:~/Documents$ mmcli -m 0 -b 1 > > -------------------------------------- > > General | path: > /org/freedesktop/ModemManager1/Bearer/1 > > | type: default > > -------------------------------------- > > Status | connected: no > > | connection error name: > org.freedesktop.ModemManager1.Error.MobileEquipment.Unknown > > | connection error message: Unknown error > > | suspended: no > > | multiplexed: no > > | ip timeout: 20 > > -------------------------------------- > > Properties | apn: apnname2 > > | roaming: allowed > > | ip type: ipv4 > > | allowed-auth: pap > > | user: apnuser2 > > | password: apnpass2 > > -------------------------------------- > > Statistics | duration: 294 > > | attempts: 2 > > | total-duration: 578 > > No idea why that error happens. That's likely an error reported by the > modem itself and we're converting it to "Unknown" ourselves, but there > is probably more info about the specific error happening in the MM > debug log itself. You should look in the MM debug log and look for a > MBIM indication reporting that disconnection at that time, and see if > there's a better error description there. It could be that the modem > reports Unknown itself, I wouldn't be surprised to be honest. >
When the second bearer fails, I see something similar to the following in /var/log/syslog (Modem number received a value of 2 this time, rather than the 0 of my earlier experiments above): Mar 18 12:10:55 ubuntu22a ModemManager[709]: [/dev/cdc-wdm0] Received message...#012>>>>>> RAW:#012>>>>>> length = 80#012>>>>>> data = 07:00:00:80:50:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0C:00:00:00:24:00:00:00:02:00:00:00:03:00:00:00:00:00:00:00:01:00:00:00:7E:5E:2A:7E:4E:6F:72:72:73:6B:65:6E:7E:5E:2A:7E:00:00:00:00 Mar 18 12:10:55 ubuntu22a ModemManager[709]: [/dev/cdc-wdm0] Received message (translated)...#012>>>>>> Header:#012>>>>>> length = 80#012>>>>>> type = indicate-status (0x80000007)#012>>>>>> transaction = 0#012>>>>>> Fragment header:#012>>>>>> total = 1#012>>>>>> current = 0#012>>>>>> Contents:#012>>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)#012>>>>>> cid = 'connect' (0x0000000c)#012>>>>>> Fields:#012>>>>>> SessionId = '2'#012>>>>>> ActivationState = 'deactivated'#012>>>>>> VoiceCallState = 'none'#012>>>>>> IpType = 'ipv4'#012>>>>>> ContextType = '7e5e2a7e-4e6f-7272-736b-656e7e5e2a7e'#012>>>>>> NwError = '0' Mar 18 12:10:55 ubuntu22a ModemManager[709]: <debug> [1647627055.057091] [modem2] received notification (service 'basic-connect', command 'connect') Mar 18 12:10:55 ubuntu22a ModemManager[709]: <debug> [1647627055.057105] [modem2] session ID '2' was deactivated: Unknown error Mar 18 12:10:55 ubuntu22a ModemManager[709]: <debug> [1647627055.057111] [modem2] bearer '/org/freedesktop/ModemManager1/Bearer/2' was disconnected. Mar 18 12:10:55 ubuntu22a ModemManager[709]: <debug> [1647627055.057117] [modem2/mbimmux2.2/net] port now disconnected Mar 18 12:10:55 ubuntu22a NetworkManager[620]: <info> [1647627055.0589] device (mbimmux2.2): state change: unavailable -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed') Mar 18 12:10:55 ubuntu22a ModemManager[709]: <info> [1647627055.073236] [modem2/bearer2] connection #1 finished: duration 264s Any further interpretation of these log entries? I suspect this is the "unknown" that was predicted. The second bearer never stays connected for more than a few minutes. Duration of my last four tries was 264, 247, 331, and 246 seconds. Is there any way I could determine whether the network, modem, Modem Manager, or Network Manager is the one tripping here? Anywhere else to look for more information? > > > After it fails, running “sudo mmcli -m 0 -b 1 --connect” then “sudo ip > link set mbimmux0.2 up” puts things back in business. I did not expect to > have to keep checking and then stand it back up when it fails. > > > > MM does not do any reconnection logic by itself, because reconnections > may involve IP reconfiguration. All that should be done by upper > layers, the actual network management tool should do it. > > After it fails, running “sudo mmcli -m 0 -b 1 --connect” then “sudo ip link set mbimmux0.2 up” always seems to work and the second bearer will be operational for another 5 minutes or so. Thank you to Aleksander for the previous responses. -Riff
