a few questions:

- it sounds like this does only happen when two modems of this type are used together. That would be a bit surprising. Is that correct?

- it sounds like restarting ModemManager and NetworkManager was attempted, but the modem stayed broken until reboot. Is that correct?

- do we have internally have such hardware available for testing and reproducing 
  ourself?
  And/Or, can we get access to a system for testing?
  And/Or, if we provide an RPM in an attempt to try something, can it be tested?

Hi Thomas,

The customer reported this behaviour only 
> - it sounds like this does only happen when two modems of this type are used
> together. That would be a bit surprising. Is that correct?

Yes, As per the discussion with the customer, they have experienced this issue when using two modems.


> - it sounds like restarting ModemManager and NetworkManager was attempted,
> but the modem stayed broken until reboot. Is that correct?
Yes, Flapping of modems was performed via NetworkManager GUI. So when the issue was experienced customer even tried restarting ModemManager and NetworkManager but no luck so had to reboot the system.



> - do we have internally have such hardware available for testing and
> reproducing 
>   ourself?
I am not aware of it!


>   And/Or, can we get access to a system for testing?
Yes, if required we can schedule a remote session.



>   And/Or, if we provide an RPM in an attempt to try something, can it be
> tested?
I will have to check with the customer to confirm.

What CF3 carrier board are they using, something like the MangOH Red or MangOH Green? (https://mangoh.io/buy-boards)  Or something else?

I think the 7608 should be capable of QMI, and in fact it's recognized as QMI by the kernel drivers, but not responding to QMI requests.  It would be very interesting to get the USB interface layout as reported by the WP7608, which you can do via:

1) systemctl mask ModemManager
2) systemctl stop ModemManager
3) unplug/replug the 7608, wait for the AT port (ttyUSB7?) to show up
4) run something like "minicom -D /dev/ttyUSB7" and then enter:

at!entercnd="A710"
AT!UDUSBCOMP?
AT!UDUSBCOMP=?
AT!USBCOMP=?
AT!USBCOMP?

5) type Ctrl+A, then Z, then x to exit minicom
6) systemctl unmask ModemManager
7) systemctl start ModemManager

Created attachment 1489957 [details]
mimicon -D /dev/ttyUSB7

Created attachment 1489958 [details]
minicom -D /dev/ttyUSB7 (part2)

Created attachment 1489959 [details]
minicom -D /dev/ttyUSB7 (part3)

Created attachment 1489996 [details]
journalctl

Thanks, the minicom logs indicate that the device *does* expose a QMI port (eg rmnet) on USB interface #8, though we see from the ModemManager logs that it does not appear to respond to requests.

Let's try this:

1) systemctl mask ModemManager
2) systemctl stop ModemManager
3) killall -TERM qmi-proxy
4) qmicli -v -d /dev/cdc-wdm0 --dms-get-ids
5) systemctl unmask ModemManager
6) systemctl start ModemManager

If for whatever reason, QMI cannot be used, these NetworkManager commits may help the PPP issue:

e66e4d0e718b0f9102160e98fb6a1bf059677d71
30a469e0bba5ac052bc29914783e62ed24b2bd67
4d11eba8c59b6dc00a0cc4b644104b19873699c9
4a4439835dde96fc81f9e09889d8f82436b0331a
2a45c32e8c5b25889dc10a8b954f79a3539d39b7

Created attachment 1490848 [details]
Requested output for comment #9

Created attachment 1490849 [details]
(part 2)

Created attachment 1490850 [details]
journalctl output after installing the package which was provided by Thomas and reproducing the issue.

I'm closing this, because this is working as designed.

We've investigated this a couple of months ago and confirmed that the reconnect is throttled by the operator. In an e-mail communication we've suggested a workaround and asked for details about the operator's policy that would trigger throttling. We haven't heard back since then, so we can't really improve the reconnect policy.