ELS61 internet connection bug | Telit Cinterion IoT Developer Community
June 21, 2019 - 11:19pm, 3119 views
I was able to get IP address and connect to network using the following commands:
AT+COPS=0,0 // network registration
AT+CSQ // check signal
AT+CGDCONT=1,"IP","internet" // define APN
AT+CGATT=1 // attach
AT^SWWAN=1,1 // successfully received IP
Then I managed to "break" Gemalto using two phones on which I ran speedtest at the same time. Module loses internet connection, while AT+CGATT?, AT+COPS?, AT+CREG? and AT^SWWAN? responses all indicate that the network connection is still established.
Which command to I use to figure out if I have an internet connection?
We managed to discover the source of a crash. dhcpcd config on our linux machine was not configured correctly and it somehow lost internet connection. Now that we replaced it, it seems to work fine.
I would still like to know if there is a good way to test whether internet connection is established with Gemalto. I know we can ping google from Linux, but a solution using some AT command would be great. Any suggestion?
Please try AT+CGPADDR command. There is also AT+CGEREP for events reporting - maybe this will also be helpful.
Thank you for response, AT+CGPADDR works ok.
When running internet speed tests (modem under heavy load), we get a stacktrace from kernel watchdog. This is the stacktrace:
WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316 dev_watchdog+0x248/0x24c
NETDEV WATCHDOG: usb0 (cdc_ether): transmit queue 0 timed out
Modules linked in: cdc_ether usbnet cdc_acm mii ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter wl18xx wlcore mac80211 cfg80211 mxc_v4l2_capture ipu_bg_overlay_sdc ipu_still v4l2_int_device ipu_prp_enc ipu_csi_enc ipu_fg_overlay_sdc wlcore_sdio mxc_dcic ip_tables
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.88 #1
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[<8010f508>] (unwind_backtrace) from [<8010b2b0>] (show_stack+0x10/0x14)
[<8010b2b0>] (show_stack) from [<803b9330>] (dump_stack+0x78/0x8c)
[<803b9330>] (dump_stack) from [<8012a95c>] (__warn+0xe8/0x100)
[<8012a95c>] (__warn) from [<8012a9ac>] (warn_slowpath_fmt+0x38/0x48)
[<8012a9ac>] (warn_slowpath_fmt) from [<80762284>] (dev_watchdog+0x248/0x24c)
[<80762284>] (dev_watchdog) from [<8017f84c>] (call_timer_fn.constprop.2+0x28/0x98)bash* "mach" 01:46 22-Jun-19
[<8017f84c>] (call_timer_fn.constprop.2) from [<8017f954>] (expire_timers+0x98/0xa4)
[<8017f954>] (expire_timers) from [<8017fa00>] (run_timer_softirq+0xa0/0x180)
[<8017fa00>] (run_timer_softirq) from [<8012f438>] (__do_softirq+0xe8/0x234)
[<8012f438>] (__do_softirq) from [<8012f850>] (irq_exit+0xcc/0x108)
[<8012f850>] (irq_exit) from [<8016e5d4>] (__handle_domain_irq+0x80/0xec)
[<8016e5d4>] (__handle_domain_irq) from [<8010146c>] (gic_handle_irq+0x48/0x8c)
[<8010146c>] (gic_handle_irq) from [<8010bc8c>] (__irq_svc+0x6c/0xa8)
Exception stack(0x80d01f30 to 0x80d01f78)
1f20: 00000000 00000002 00000001 80d00000
1f40: 74b2cf25 00000102 ab71ff40 00000001 7441e632 00000102 00000000 80d03144
1f60: 00000000 80d01f80 80894d84 8065e7cc 200b0013 ffffffff
[<8010bc8c>] (__irq_svc) from [<8065e7cc>] (cpuidle_enter_state+0x118/0x29c)
[<8065e7cc>] (cpuidle_enter_state) from [<80165370>] (cpu_startup_entry+0x148/0x218)
[<80165370>] (cpu_startup_entry) from [<80c00c5c>] (start_kernel+0x37c/0x388)
---[ end trace bbe1c775b07ff6fd ]---
When this happens, modem still has an IP/internet connection, in Linux, usb0 still has IP, but internet connection doesn't work anymore. If we execute AT^SWWAN=0,1 and just after AT^SWWAN=1,1, usb0 works again (internet in Linux works again). Do you know what might be the cause to this? We tried this test on Linux kernel 4.9.88 and 5.1.2 with ELS61 firmware A-REVISION 01.000.01 and 01.000.02. Did you ever notice this before? We suspect that this is caused by a bug in Gemalto firmware.
We also tried establishing internet connection using PPP, not SWWAN, and this bug doesn't ocurr.
It seems that the same issue was reported to Gemalto support recently - same stack trace and similar description. So I'm almost sure that the report is from you. It is now being analyzed and will probably be also tested by the support team. You may expect the information or further questions from your technical sales.
Yes, the stack trace came from wihtin our company. We also notified our local technical sales support and they said that matter will be furtherly investigated.
Thank you and best regards,