compact cat /var/log/syslog.log | grep "RILCMD: [IP info] IPv4:"
... grazie al tuo script ;-)
cat /var/log/syslog.log | grep 'udhcpc: Lease of'
[dhcpc] Dec 15 14:10:01 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
[dhcpc] Dec 15 15:10:01 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
[dhcpc] Dec 15 16:10:02 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
[dhcpc] Dec 15 17:10:01 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
[dhcpc] Dec 15 18:10:01 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
[dhcpc] Dec 15 19:10:02 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
[dhcpc] Dec 15 20:10:01 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
[dhcpc] Dec 15 21:10:01 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
[dhcpc] Dec 15 22:10:01 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
[dhcpc] Dec 15 23:10:01 kern.info udhcpc: Lease of **.**.**.** obtained, lease time 7200
root@LTE5398-M904:~#
btw:
i 2 comandi da inviare via SSH, in sequenza, per disconnettere e riconnettere il collegamento wwan0 sono:
cfg cellwan_mapn edit --Index 1 --AP_Enable 0
cfg cellwan_mapn edit --Index 1 --AP_Enable 1
questo sistema è molto più veloce del reset del modulo LTE
sys resetcm
basterebbe controllare periodicamente che un host noto (ad es.: 1.1.1.1)
risponda al ping e, in caso contrario, "riavviare" la connessione LTE
ho letto che un utente di Mikrotic aveva impostato il controllo ogni 5 minuti
(ottenendo un down massimo teorico di 5 minuti+tempo del riavvio)
forse questo documento potrebbe tornare utile anche in ottica Openwrt
What is QMAP
“uqmi -d /dev/cdc-wdm0 –get-current-settings” give IP “B”.
“udhcpc” still attribute IP “A” to the wwan0 interface resulting in an nonoperational interface until I restart it (ubus call network.interface.wwan down / ubus call network.interface.wwan up).
After an interface restart “udhcpc” attribute IP “B” to the wwan0 interface.
__
senza averlo letto (o forse non lo ricordavo) mi ero preoccupato di utilizzare proprio udhcpc
(cioè la versione 0.9.8 di udhcpc che è installata nel router)
per ottenere un nuovo lease dal server (per lo stesso IP)
la cosa funziona fino a quando il provider cambia l'IP,
ma sembra che l'interfaccia si "accorga" del cambio
Dec 8 16:10:01 kern.info udhcpc: udhcp client (v0.9.8) started
Dec 8 16:10:01 kern.notice udhcpc: Attached to schema shared memory
Dec 8 16:10:01 kern.notice udhcpc: Attached to object name shared memory
Dec 8 16:10:01 kern.notice udhcpc: Attached to parameter name shared memory
Dec 8 16:10:01 kern.notice udhcpc:
Dec 8 16:10:01 kern.debug udhcpc: Sending discover...
Dec 8 16:10:01 kern.debug udhcpc: Sending select for 31.26.160.205...
Dec 8 16:10:01 kern.info udhcpc: Lease of 31.26.160.205 obtained, lease time 7200
Dec 8 16:32:24 **user.notice RILCMD: isChange=1**, old IP=[31.26.160.205], new IP=[31.26.154.248]
Dec 8 16:32:25 user.notice RILCMD: cid[1]: ip address change from 31.26.160.205 to 31.26.154.248.
Dec 8 16:32:27 user.notice RILCMD: RILCMD STATE: RS_READY ============> RS_INIT
Dec 8 16:32:28 user.notice RILCMD: set_LTE_connection_status: Down
[...] _sequenze ripetute di up/down/up della connessione_
Dec 8 16:44:46 kern.info udhcpc: udhcp client (v0.9.8) started
Dec 8 16:44:46 kern.notice udhcpc: Attached to schema shared memory
Dec 8 16:44:46 kern.notice udhcpc: Attached to object name shared memory
Dec 8 16:44:46 kern.notice udhcpc: Attached to parameter name shared memory
Dec 8 16:44:46 kern.debug udhcpc: Sending discover...
Dec 8 16:44:47 kern.debug udhcpc: Sending discover...
Dec 8 16:44:48 kern.debug udhcpc: Sending discover...
Dec 8 16:44:49 kern.debug udhcpc: Sending discover...
Dec 8 16:44:50 kern.debug udhcpc: Sending discover...
Dec 8 16:44:51 kern.debug udhcpc: Sending discover...
Dec 8 16:44:58 user.warning RILCMD: [LTE Cell info] RFCN:1850, Cell_ID:10041376, PCI:77, RSRP:-90
Dec 8 16:44:58 user.notice RILCMD: [LTE Cell info] RFCN:1850, Cell_ID:10041376, PCI:77, RSRP:-90
Dec 8 16:44:58 user.notice RILCMD: [IP info] IPv4:31.26.174.122
Dec 8 16:44:58 user.notice RILCMD: [IP info] IPv6:
Dec 8 16:44:59 kern.debug udhcpc: Sending discover...
Dec 8 16:45:01 kern.debug udhcpc: Sending discover...
Dec 8 16:45:03 kern.debug udhcpc: Sending discover...
Dec 8 16:45:12 kern.debug udhcpc: Sending discover...
Dec 8 16:45:14 kern.debug udhcpc: Sending discover...
Dec 8 16:45:16 kern.debug udhcpc: Sending discover...
Dec 8 16:45:25 kern.debug udhcpc: Sending discover...
Dec 8 16:45:28 kern.debug udhcpc: Sending discover...
Dec 8 16:45:30 kern.debug udhcpc: Sending discover...
Dec 8 16:45:39 kern.debug udhcpc: Sending discover...
Dec 8 16:45:41 kern.debug udhcpc: Sending discover...
Dec 8 16:45:43 kern.debug udhcpc: Sending discover...
nella seconda parte del log si vede che updhcp continua
ad interrogare invano il server dhcp,
nonostante l'interfaccia, a seguito del riavvio della connessione,
abbia già ottenuto un nuovo IP (attraverso una diversa istanza di udhcpc).
il tutto si riallinea con il comando
udhcpc -i wwan0 -r 31.26.174.122
(che riassegna all'interfaccia wwan0 lo stesso ip che ha ottenuto l'altra istanza)