Modem: restore connectivity, without touching the modem itself #517
+115
−31
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…<4g_iface> immediately restores connectivity, without touching the modem itself
Collaborator
Author
|
example of logs with the patch
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Version française
Contexte
Plateforme : Orange Pi sous Armbian, avec modem 4G (SIMCom A76xx) configuré par rtkbase.
Le modem est vu comme une interface « USB Ethernet » (
enx…) gérée par NetworkManager via la connexion Cellular Modem.Problème observé : après quelques heures de fonctionnement, la connexion 4G ne permet plus d’accéder à Internet.
Symptômes :
nmcliindique toujours la connexion Cellular Modem comme activée ;+CEREG=1,+CGATT=1) et a un contexte data actif (AT+CGCONTRDP) ;Un simple
nmcli device disconnect <iface_4g>puisnmcli device connect <iface_4g>suffit à rétablir immédiatement la connexion, sans toucher au modem lui-même.Comportement actuel de
modem_check.pymodem_check.py:AT+CFUN=0puisAT+CFUN=1).Dans le cas décrit ci-dessus, cette séquence CFUN ne suffit pas à rétablir le trafic IP, alors qu’un simple reconnect NetworkManager de l’interface 4G le fait.
Patch proposé
Le patch garde la logique existante mais ajoute une étape intermédiaire plus douce côté host :
Ajout d’une fonction
get_interface_name()qui récupère le nom de l’interface associée à la connexion Cellular Modem vianmcli connection show(GENERAL.DEVICES).Modification du test de connectivité :
ping -I <iface_4g> caster.centipede.fr(oupch.net)plutôt qu’un ping global.
En cas de problème (
ip_in_usenon nulle,public_ipnon nulle, modem enregistré, mais ping KO) :tentative de reconnexion NetworkManager uniquement :
nmcli device disconnect <iface_4g>puisnmcli device connect <iface_4g>nmcli connection down "Cellular Modem"puisnmcli connection up "Cellular Modem"re-lecture de l’état (enregistrement, IP, ping).
si tout est OK → on logue que la connectivité a été restaurée et on ne touche pas au modem.
Si après cette tentative NM la situation est toujours incorrecte (pas d’IP / pas d’enregistrement / ping toujours KO), on applique la logique existante : bascule en mode avion du modem (
AT+CFUN=0puisAT+CFUN=1).En complément, les appels à
modem.close()sont protégés avec destry/exceptpour éviter des exceptions si l’objet n’est pas initialisé correctement.Ce patch permet de corriger les pertes de connectivité liées à l’interface 4G / NetworkManager, tout en conservant le comportement d’origine sur les cas où le modem lui-même est en défaut.
English version
Context
Platform: Orange Pi running Armbian, with a 4G modem (SIMCom A76xx) configured by rtkbase.
The modem appears as a “USB Ethernet” interface (
enx…) managed by NetworkManager through the Cellular Modem connection.Observed issue: after a few hours, the 4G link stops providing Internet access.
Symptoms:
nmclistill reports the Cellular Modem connection as activated;+CEREG=1,+CGATT=1) with an active data context (AT+CGCONTRDP);Running
nmcli device disconnect <4g_iface>thennmcli device connect <4g_iface>immediately restores connectivity, without touching the modem itself.Current
modem_check.pybehaviormodem_check.py:AT+CFUN=0thenAT+CFUN=1).In the situation described above, the CFUN sequence does not restore IP traffic, while a simple NetworkManager reconnect of the 4G interface does.
Proposed patch
The patch keeps the existing logic, but adds a gentler host-side recovery step:
Add a
get_interface_name()helper that retrieves the device name attached to the Cellular Modem connection vianmcli connection show(GENERAL.DEVICES).Change the connectivity check to use interface-bound ping:
ping -I <4g_iface> caster.centipede.fr(orpch.net)instead of a global ping, so we really test the 4G path.
When something looks wrong (non-null
ip_in_useandpublic_ip, modem registered, but ping fails):first try a NetworkManager reconnect only:
nmcli device disconnect <4g_iface>thennmcli device connect <4g_iface>nmcli connection down "Cellular Modem"thennmcli connection up "Cellular Modem"then re-check registration, IP addresses and ping.
if everything is back to normal → log that connectivity was restored and do not touch the modem.
If, after this NM reconnect, the situation is still wrong (no IP, not registered, ping still failing), fall back to the original behavior: modem airplane-mode reset (
AT+CFUN=0thenAT+CFUN=1).Additionally,
modem.close()calls are wrapped intry/exceptblocks to avoid errors if the modem object is not properly initialized.This patch fixes connectivity losses caused by the 4G interface / NetworkManager layer, while preserving the original CFUN-based recovery for cases where the modem itself is in a bad state.