4:39 p.m.
Hi,
I am running ofono version 1.30 for uBlox SARA-R4 QMI on iMX6, it is
functional well, but there is one problem, it failed to be reconnected
when the 4G LTE signaling strength level is back to normal. Here is
what I tested:
- Connect antenna, it was running fine, network is connected.
- Remove the antenna, the network is down.
- Wait for a while, reconnect the antenna, the ofono could not
reconnect, the driver was still there.
- If I restart ofnono the connection would be back.
I tested the same sequence on SARA EVK which is not running ofono, it
is capable of re-register automatically.
Appreciate your sight comments if it is ofono issue or QMI issue or
something else, please find the attached debug file.
Thank you.
Kind regards,
- jupiter
10:26 p.m.
Hmm, strange, I tried to restart ofonod several times, the last one
was able to reconnect the 4G and network automatically after removing
the antenna to lose network, then adding the antenna, the only
difference was there were many messages popped out in the console
screen:
[33383.892047] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
[33383.961208] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
[33385.634408] mwifiex_sdio mmc0:0001:1: info: trying to associate to 'JupiterIo
T' bssid 34:08:04:12:b1:a2
[33385.658542] mwifiex_sdio mmc0:0001:1: info: associated to bssid 34:08:04:12:b
1:a2 successfully
[33385.800544] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
[33385.874181] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
[33453.714288] mwifiex_sdio mmc0:0001:1: info: successfully disconnected from 34
:08:04:12:b1:a2: reason code 3
[33453.771463] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
[33453.836374] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
it looks like when it did not work that some monitoring and callback
process was not activated, when it worked, the some process was
activated.
What I might missing here? Please see the attached log file
ofono_debug6.txt which is able to reconnect.
I'll do more test, something is not stable or missing.
Thank you.
On 11/20/20, Jupiter <jupiter.hce(a)gmail.com> wrote:
Hi,
I am running ofono version 1.30 for uBlox SARA-R4 QMI on iMX6, it is
functional well, but there is one problem, it failed to be reconnected
when the 4G LTE signaling strength level is back to normal. Here is
what I tested:
- Connect antenna, it was running fine, network is connected.
- Remove the antenna, the network is down.
- Wait for a while, reconnect the antenna, the ofono could not
reconnect, the driver was still there.
- If I restart ofnono the connection would be back.
I tested the same sequence on SARA EVK which is not running ofono, it
is capable of re-register automatically.
Appreciate your sight comments if it is ofono issue or QMI issue or
something else, please find the attached debug file.
Thank you.
Kind regards,
- jupiter
--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs
10:21 p.m.
Hi,
My apology for keeping a post on the topic to seek list helps.
After changing testing tactics, I now believe it could be something
wrong, missing or bug in ofono, hope someone could kindly respond to
shed some light on the cause.
Here is my new test:
(1) I pulled antenna out before starting ofonod, it failed network
which was good.
(2) I plugged antenna, ofono could connect to the network
automatically (which was good)
(3) I pulled the antenna out again, the network broken.
(4) I plugged the antenna again, ofono was not able to connect to the
network again.
If the ofono could connect to the network automatically at (2), it
should be able to connect to the network automatically at (4), right?
What are the differences between (2) and (4)?
(5) I had to restart ofono to get the network connected.
Could you please advise how to get ofono to reconnect at (4)? Or could
you please point me a direction on how to resolve it?
Please let me know if you need more debugging.
Thank you.
Kind regards,
- j
12:12 a.m.
Hi,
On 20/11/2020 06:26, Jupiter wrote:
Hmm, strange, I tried to restart ofonod several times, the last one
was able to reconnect the 4G and network automatically after removing
the antenna to lose network, then adding the antenna, the only
difference was there were many messages popped out in the console
screen:
[33383.892047] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
[33383.961208] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
[33385.634408] mwifiex_sdio mmc0:0001:1: info: trying to associate to 'JupiterIo
T' bssid 34:08:04:12:b1:a2
[33385.658542] mwifiex_sdio mmc0:0001:1: info: associated to bssid 34:08:04:12:b
1:a2 successfully
[33385.800544] IPv6: ADDRCONF(NETDEV_CHANGE): mlan0: link becomes ready
[33385.874181] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x23f error, result=0x2
[33453.714288] mwifiex_sdio mmc0:0001:1: info: successfully disconnected from 34
:08:04:12:b1:a2: reason code 3
[33453.771463] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready
[33453.836374] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
You're probably grounding something when disconnecting the antenna...
it looks like when it did not work that some monitoring and callback
process was not activated, when it worked, the some process was
activated.
What I might missing here? Please see the attached log file
ofono_debug6.txt which is able to reconnect.
Again, this log shows a bunch of modem resets.
This pattern is repeated a couple of times:
ofonod[20465]:
../ofono-1.30/drivers/qmimodem/network-registration.c:event_notify()
ofonod[20465]:
../ofono-1.30/drivers/qmimodem/network-registration.c:event_notify()
signal with 40%(-77 dBm) on 8
ofonod[20465]:
../ofono-1.30/src/network.c:ofono_netreg_strength_notify() strength 40
ofonod[20465]: ../ofono-1.30/src/modem.c:get_modem_property() modem
0x567908 property SystemPath
ofonod[20465]:
../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[20465]: QMI: > 01 11 00 00 03 01 00 45 01 20 00 05 00 10 02 00
.......E. ......
ofonod[20465]: QMI: ff 00
..
ofonod[20465]: QMI: NAS_req msg=32 len=5
[client=1,type=0,tid=325,len=17]
ofonod[20465]: QMI: {type=16,len=2}
ofonod[20465]: QMI: < 01 48 00 80 03 01 02 45 01 20 00 3c 00 02 04 00
.H.....E. .<....
ofonod[20465]: QMI: 00 00 00 00 01 02 00 b3 08 11 04 00 01 00 4d 08
..............M.
ofonod[20465]: QMI: 12 04 00 01 00 3f 08 13 04 00 96 ff ff ff 14 01
.....?..........
ofonod[20465]: QMI: 00 08 15 05 00 01 00 ff ff 08 16 02 00 f2 08 17
................
ofonod[20465]: QMI: 02 00 fe ff 18 02 00 96 ff
.........
ofonod[20465]: QMI: NAS_resp msg=32 len=60
[client=1,type=2,tid=325,len=72]
ofonod[20465]: QMI: {type=2,error=NONE} {type=1,len=2}
{type=17,len=4} {type=18,len=4}
ofonod[20465]: QMI: {type=19,len=4} {type=20,len=1}
{type=21,len=5} {type=22,len=2}
ofonod[20465]: QMI: {type=23,len=2} {type=24,len=2}
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 77 on RAT 8
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb() Bit
error rate: 65535 on RAT 8
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSRQ: -14 on RAT 8
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb() Got
LTE RSRP: -106
ofonod[20465]: QMI: < 01 11 00 80 03 01 04 0c 00 02 00 05 00 10 02 00
................
ofonod[20465]: QMI: b7 08
..
ofonod[20465]: QMI: NAS_ind msg=2 len=5 [client=1,type=4,tid=12,len=17]
ofonod[20465]: QMI: {type=16,len=2}
ofonod[20465]:
../ofono-1.30/drivers/qmimodem/network-registration.c:event_notify()
ofonod[20465]:
../ofono-1.30/drivers/qmimodem/network-registration.c:event_notify()
signal with 60%(-73 dBm) on 8
ofonod[20465]:
../ofono-1.30/src/network.c:ofono_netreg_strength_notify() strength 60
ofonod[20465]: ../ofono-1.30/src/modem.c:modem_change_state() old state:
3, new state: 0
ofonod[20465]: ../ofono-1.30/src/modem.c:flush_atoms()
ofonod[20465]: ../ofono-1.30/src/gprs.c:gprs_context_unregister()
0x565c00, 0x55b7f0
ofonod[20465]: ../ofono-1.30/src/gprs.c:gprs_context_remove() atom: 0x565c28
ofonod[20465]:
../ofono-1.30/drivers/qmimodem/gprs-context.c:qmi_gprs_context_remove()
ofonod[20465]: ../ofono-1.30/src/gprs.c:gprs_unregister() 0x55b7f0
ofonod[20465]:
../ofono-1.30/src/network.c:__ofono_netreg_remove_status_watch() 0x5549a8
ofonod[20465]: ../ofono-1.30/src/gprs.c:gprs_remove() atom: 0x55e198
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/gprs.c:qmi_gprs_remove()
ofonod[20465]: ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_remove()
ofonod[20465]: ../ofono-1.30/src/sim.c:ofono_sim_remove_spn_watch() 0x55e060
ofonod[20465]: ../ofono-1.30/src/network.c:netreg_remove() atom: 0x573510
...
...and the modem continues to reset itself. Is this coincidental with
you removing the antenna... I can't tell?
/Jonas
> I'll do more test, something is not stable or missing.
>
> Thank you.
>
>
>
> On 11/20/20, Jupiter <jupiter.hce(a)gmail.com> wrote:
>> Hi,
>>
>> I am running ofono version 1.30 for uBlox SARA-R4 QMI on iMX6, it is
>> functional well, but there is one problem, it failed to be reconnected
>> when the 4G LTE signaling strength level is back to normal. Here is
>> what I tested:
>>
>> - Connect antenna, it was running fine, network is connected.
>>
>> - Remove the antenna, the network is down.
>>
>> - Wait for a while, reconnect the antenna, the ofono could not
>> reconnect, the driver was still there.
>>
>> - If I restart ofnono the connection would be back.
>>
>> I tested the same sequence on SARA EVK which is not running ofono, it
>> is capable of re-register automatically.
>>
>> Appreciate your sight comments if it is ofono issue or QMI issue or
>> something else, please find the attached debug file.
>>
>> Thank you.
>>
>> Kind regards,
>>
>> - jupiter
>>
>
>
>
> _______________________________________________
> ofono mailing list -- ofono(a)ofono.org
> To unsubscribe send an email to ofono-leave(a)ofono.org
>
2:47 a.m.
Hi Jonas,
Thanks for the response and kind helps.
and the modem continues to reset itself. Is this coincidental with
you removing the antenna... I can't tell?
My apology, a watchdog to monitor and to restart ofono when it lost
register was still running.
I attached a new log which disabled watchdog.
Here is the issue when the antenna was pulled out (simulating to lose
signalling), the modem was unregistered but it stuck at rssi callback:
ofonod[27530]: ../ofono-1.30/src/gprs.c:ofono_gprs_status_notify()
/ubloxqmi_0 status unregistered (0)
ofonod[27530]: ../ofono-1.30/src/modem.c:get_modem_property() modem
0x13ae0e8 property SystemPath
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 128 on RAT 0
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
Bit error rate: 65535 on RAT 0
ofonod[27530]: ../ofono-1.30/src/modem.c:get_modem_property() modem
0x13ae0e8 property SystemPath
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 128 on RAT 0
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
Bit error rate: 65535 on RAT 0
.............
It then stuck and repeated following statements forever:
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 128 on RAT 0
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
Bit error rate: 65535 on RAT 0
static void qmi_netmon_request_update(struct ofono_netmon *netmon,
ofono_netmon_cb_t cb, void *user_data) invokes get_rssi_cb:
if (qmi_service_send(data->nas, QMI_NAS_GET_RSSI, param, get_rssi_cb,
cbd, g_free) > 0)
static void get_rssi_cb(struct qmi_result *result, void *user_data)
checks signalling RSSI, RSRQ, RSRP, obviously there is no valid
signaling streangh as the modem is in unregistered status.
My question is, where and how does ofono or qmimodem check modem
register status? Calling rssi_cb is not capable of finding modem
register status. Is the register status in src/modem.c?
Appreciate to shed light on how should ofono or qmimodme to handle
modem register status changes.
Thank you.
Kind regards,
- jupiter
7 a.m.
Hi,
On 27/11/2020 10:47, Jupiter wrote:
Hi Jonas,
Thanks for the response and kind helps.
> and the modem continues to reset itself. Is this coincidental with
> you removing the antenna... I can't tell?
My apology, a watchdog to monitor and to restart ofono when it lost
register was still running.
That would explain it...
I attached a new log which disabled watchdog.
Here is the issue when the antenna was pulled out (simulating to lose
signalling), the modem was unregistered but it stuck at rssi callback:
ofonod[27530]: ../ofono-1.30/src/gprs.c:ofono_gprs_status_notify()
/ubloxqmi_0 status unregistered (0)
ofonod[27530]: ../ofono-1.30/src/modem.c:get_modem_property() modem
0x13ae0e8 property SystemPath
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 128 on RAT 0
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
Bit error rate: 65535 on RAT 0
ofonod[27530]: ../ofono-1.30/src/modem.c:get_modem_property() modem
0x13ae0e8 property SystemPath
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 128 on RAT 0
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
Bit error rate: 65535 on RAT 0
.............
It then stuck and repeated following statements forever:
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
RSSI: 128 on RAT 0
ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
Bit error rate: 65535 on RAT 0
static void qmi_netmon_request_update(struct ofono_netmon *netmon,
ofono_netmon_cb_t cb, void *user_data) invokes get_rssi_cb:
if (qmi_service_send(data->nas, QMI_NAS_GET_RSSI, param, get_rssi_cb,
cbd, g_free) > 0)
static void get_rssi_cb(struct qmi_result *result, void *user_data)
checks signalling RSSI, RSRQ, RSRP, obviously there is no valid
signaling streangh as the modem is in unregistered status.
I wouldn't worry about these netmon functions. It's the
network-registration driver that you should be looking at. 'netmon' is
only for information, I think.
My question is, where and how does ofono or qmimodem check modem
register status? Calling rssi_cb is not capable of finding modem
register status. Is the register status in src/modem.c?
ss_info_notify() gets called when you get network information
notifications from the modem. That's where the magic happens.
Appreciate to shed light on how should ofono or qmimodme to handle
modem register status changes.
Thank you.
Looking at the log, it sure does seem like the modem just stops sending
network status indications. What happens if you re-assert interest in
these notifications regularly... something like this?
--- a/drivers/qmimodem/network-registration.c
+++ b/drivers/qmimodem/network-registration.c
@@ -211,6 +211,9 @@ static void ss_info_notify(struct qmi_result
*result, void *user_data)
return;
status = remember_ss_info(data, status, lac, cellid, roaming);
+
+ qmi_service_register(data->nas, QMI_NAS_SS_INFO_IND,
+ ss_info_notify, netreg, NULL);
ofono_netreg_status_notify(netreg, status, data->lac, data->cellid,
tech);
The log file is in quite a readable state now. It would be great if
somebody else could take a look at it... I'm a bit out of the loop with
ofono, currently, so getting a bit rusty!
/Jonas
>
> Kind regards,
>
> - jupiter
>
12:19 a.m.
Hi Jonas,
Looking at the log, it sure does seem like the modem just stops
sending
network status indications. What happens if you re-assert interest in
these notifications regularly... something like this?
--- a/drivers/qmimodem/network-registration.c
+++ b/drivers/qmimodem/network-registration.c
@@ -211,6 +211,9 @@ static void ss_info_notify(struct qmi_result
*result, void *user_data)
return;
status = remember_ss_info(data, status, lac, cellid, roaming);
+
+ qmi_service_register(data->nas, QMI_NAS_SS_INFO_IND,
+ ss_info_notify, netreg, NULL);
ofono_netreg_status_notify(netreg, status, data->lac,
data->cellid,
tech);
I made a patch to add qmi_service_register(data->nas,
QMI_NAS_SS_INFO_IND, ss_info_notify, netreg, NULL);, it broken ofono
completely, even I removed the patch, it could still not get ofono
back until I delete the whole build and rebuild it.
# systemctl status ofono
* ofono.service - Telephony service
Loaded: loaded
(8;;file://solar/lib/systemd/system/ofono.service/lib/systemd/system/ofono.service8;;;
enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Mon 2020-11-30 01:03:02 UTC; 33min ago
Process: 153 ExecStart=/usr/sbin/ofonod -n (code=killed, signal=KILL)
Main PID: 153 (code=killed, signal=KILL)
Nov 30 00:59:53 solar systemd[1]: Starting Telephony service...
Nov 30 00:59:55 solar ofonod[153]: oFono version 1.30
Nov 30 00:59:56 solar systemd[1]: Started Telephony service.
Nov 30 01:00:05 solar ofonod[153]: Interface org.ofono.AllowedAccessPoint...list
Nov 30 01:01:32 solar systemd[1]: Stopping Telephony service...
Nov 30 01:03:02 solar systemd[1]: ofono.service: State 'stop-sigterm' tim...ing.
Nov 30 01:03:02 solar systemd[1]: ofono.service: Killing process 153 (ofo...ILL.
Nov 30 01:03:02 solar systemd[1]: ofono.service: Main process exited, cod...KILL
Nov 30 01:03:02 solar systemd[1]: ofono.service: Failed with result 'timeout'.
Nov 30 01:03:02 solar systemd[1]: Stopped Telephony service.
Hint: Some lines were ellipsized, use -l to show in full.
The debug file is attached, but it was stuck at driver failure.
Thank you very much.
Kind regards,
- jupiter
1:49 a.m.
Hi,
On 11/27/20 3:00 PM, Jonas Bonn wrote:
Hi,
On 27/11/2020 10:47, Jupiter wrote:
> Hi Jonas,
>
> Thanks for the response and kind helps.
>
>> and the modem continues to reset itself. Is this coincidental with
>> you removing the antenna... I can't tell?
>
> My apology, a watchdog to monitor and to restart ofono when it lost
> register was still running.
That would explain it...
>
> I attached a new log which disabled watchdog.
>
> Here is the issue when the antenna was pulled out (simulating to lose
> signalling), the modem was unregistered but it stuck at rssi callback:
>
> ofonod[27530]: ../ofono-1.30/src/gprs.c:ofono_gprs_status_notify()
> /ubloxqmi_0 status unregistered (0)
> ofonod[27530]: ../ofono-1.30/src/modem.c:get_modem_property() modem
> 0x13ae0e8 property SystemPath
> ofonod[27530]:
> ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
> ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
> ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
> RSSI: 128 on RAT 0
> ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
> Bit error rate: 65535 on RAT 0
> ofonod[27530]: ../ofono-1.30/src/modem.c:get_modem_property() modem
> 0x13ae0e8 property SystemPath
> ofonod[27530]:
> ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
> ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
> ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
> RSSI: 128 on RAT 0
> ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
> Bit error rate: 65535 on RAT 0
> .............
>
> It then stuck and repeated following statements forever:
>
> ofonod[27530]:
> ../ofono-1.30/drivers/qmimodem/netmon.c:qmi_netmon_request_update()
> ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
> ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
> RSSI: 128 on RAT 0
> ofonod[27530]: ../ofono-1.30/drivers/qmimodem/netmon.c:get_rssi_cb()
> Bit error rate: 65535 on RAT 0
>
> static void qmi_netmon_request_update(struct ofono_netmon *netmon,
> ofono_netmon_cb_t cb, void *user_data) invokes get_rssi_cb:
> if (qmi_service_send(data->nas, QMI_NAS_GET_RSSI, param, get_rssi_cb,
> cbd, g_free) > 0)
>
> static void get_rssi_cb(struct qmi_result *result, void *user_data)
> checks signalling RSSI, RSRQ, RSRP, obviously there is no valid
> signaling streangh as the modem is in unregistered status.
>
I wouldn't worry about these netmon functions. It's the
network-registration driver that you should be looking at. 'netmon' is
only for information, I think.
> My question is, where and how does ofono or qmimodem check modem
> register status? Calling rssi_cb is not capable of finding modem
> register status. Is the register status in src/modem.c?
ss_info_notify() gets called when you get network information
notifications from the modem. That's where the magic happens.
I agree with Jonas to say that all the magic is in ss_info_notify. At
least that's the case outside LTE, I don't know a lot about LTE
specificities.
Using netreg_status_changed logs:
- registration OK at line 544
- IP ok at line 586
- registration KO (I assume this is after antenna remove) at line 687
- another registration KO at line 716
So modem never says that data registration is back after antenna remove.
Or it says so using a way that is not handled by QMI driver in ofono.
When you restart Ofono, radio stack of the modem will be reset
(something like AT+CFUN=4, AT+CFUN=0 happens), that's why a new data
registration process occurs.
I don't know if you have access to an AT channel or another QMI channel
on your modem while Ofono is running. If this is the case, you could ask
for registration status while ofono is running using AT commands or
using qmicli. Let me know if you can do that and don't know the commands
to do it.
Best regards,
Christophe
>
>>
>> Appreciate to shed light on how should ofono or qmimodme to handle
>> modem register status changes.
>> Thank you.
>
> Looking at the log, it sure does seem like the modem just stops
> sending network status indications. What happens if you re-assert
> interest in these notifications regularly... something like this?
>
> --- a/drivers/qmimodem/network-registration.c
> +++ b/drivers/qmimodem/network-registration.c
> @@ -211,6 +211,9 @@ static void ss_info_notify(struct qmi_result
> *result, void *user_data)
> return;
>
> status = remember_ss_info(data, status, lac, cellid, roaming);
> +
> + qmi_service_register(data->nas, QMI_NAS_SS_INFO_IND,
> + ss_info_notify, netreg, NULL);
>
> ofono_netreg_status_notify(netreg, status, data->lac,
> data->cellid,
>
> tech);
>
> The log file is in quite a readable state now. It would be great if
> somebody else could take a look at it... I'm a bit out of the loop
> with ofono, currently, so getting a bit rusty!
>
> /Jonas
>
>
>>
>> Kind regards,
>>
>> - jupiter
>>
> _______________________________________________
> ofono mailing list -- ofono(a)ofono.org
> To unsubscribe send an email to ofono-leave(a)ofono.org
2:56 a.m.
Hi Christophe,
Thanks for the response.
I agree with Jonas to say that all the magic is in ss_info_notify. At
least that's the case outside LTE, I don't know a lot about LTE specificities.
Any idea how to modify the source to get ss_info_notify running in
qmimodem The question is how to do it? Adding
qmi_service_register(data->nas, QMI_NAS_SS_INFO_IND, ss_info_notify,
netreg, NULL); to ss_info_notify network-registration.c just not
working.
When you restart Ofono, radio stack of the modem will be reset
(something like AT+CFUN=4, AT+CFUN=0 happens), that's why a new data
registration process occurs.
You are right, restarting ofono is to reset modem, I can also run SARA
modem power reset via GPIO to bring the register back as well.
I don't know if you have access to an AT channel or another QMI
channel
on your modem while Ofono is running. If this is the case, you could ask
for registration status while ofono is running using AT commands or
using qmicli. Let me know if you can do that and don't know the commands
to do it.
Yes, there are two ports, /dev/ttyUSB0 is for QMI control,
/dev/ttyUSB1 is for AT, QMI modem does not use it. Yes, I can run AT
commands manually in the command line to get responses from
/dev/ttyUSB1.
Thank you.
Kind regards,
- j
11:53 p.m.
Hi,
On 20/11/2020 00:39, Jupiter wrote:
Hi,
I am running ofono version 1.30 for uBlox SARA-R4 QMI on iMX6, it is
functional well, but there is one problem, it failed to be reconnected
when the 4G LTE signaling strength level is back to normal. Here is
what I tested:
- Connect antenna, it was running fine, network is connected.
- Remove the antenna, the network is down.
- Wait for a while, reconnect the antenna, the ofono could not
reconnect, the driver was still there.
- If I restart ofnono the connection would be back.
I tested the same sequence on SARA EVK which is not running ofono, it
is capable of re-register automatically.
Appreciate your sight comments if it is ofono issue or QMI issue or
something else, please find the attached debug file.
You really need to annotate the log file because I can't see the problem
you're describing there.
The log file shows the modem being reset a couple of times; there is no
loss of signal before those events though. My first thought was that
you were crashing the modem while removing the antenna; however, it
seems to me that the the reset is more controlled than that so it seems
more likely that you are disabling the modem from some other program.
Like I said... annotate the logged events with some description of
what's going on around them so that the problem can be debugged.
/Jonas
>
> Thank you.
>
> Kind regards,
>
> - jupiter
>
>
> _______________________________________________
> ofono mailing list -- ofono(a)ofono.org
> To unsubscribe send an email to ofono-leave(a)ofono.org
>
302
days inactive
314
days old
9 comments
3 participants
participants (3)
-
Christophe Ronco -
Jonas Bonn -
Jupiter