Lots of Disconnecting

[zubbs1]

I am struggling to understand this issue. For a few months everything seemed to work fine. It was connected and getting around 100Mb/s down and 20-30Mb/s up on the ATT network.

For the last several weeks, it is disconnecting and rebooting the router and then reconnecting. It will stay connected for a random amount of time, sometimes 30 seconds, sometimes 5 minutes and then disconnect. Once in awhile it stays connected and works great for the entire day.

I have turned off band lock. I have tried with or without the connection monitoring in place. I have pulled the power and let sit for 10 minutes before rebooting.
I checked with my provider that I pay for my monthly service and they claim none of their other customers are reporting this issue.
I need help on how to further troubleshoot. This is the overview screen system area:

Hostname WiFiX
Model WiFiX WG3526
Architecture MediaTek MT7621 ver:1 eco:3
Firmware Version GoldenOrb_2020-05-16
Kernel Version 4.14.167
Local Time Thu Jun 24 22:46:38 2021
Uptime 0h 18m 15s
Load Average

I figure there is useful information in a log file somewhere, but I don't know where to locate that information. The connection log section barely shows anything. Here is what it currently displays:

Thu Jun 24 22:14:27 2021 : Attempting to Connect Modem #1 (Quectel EM20-G)
Thu Jun 24 22:17:47 2021 : Modem #1 Connected
Thu Jun 24 22:19:04 2021 : Attempting to Connect Modem #1 (Quectel EM20-G)
Thu Jun 24 22:22:03 2021 : Modem #1 Connected
Thu Jun 24 22:23:44 2021 : Attempting to Connect Modem #1 (Quectel EM20-G)
Thu Jun 24 22:24:56 2021 : Modem #1 Connected
Thu Jun 24 22:26:38 2021 : Attempting to Connect Modem #1 (Quectel EM20-G)
Thu Jun 24 22:27:50 2021 : Modem #1 Connected
Thu Jun 24 22:29:26 2021 : Attempting to Connect Modem #1 (Quectel EM20-G)
Thu Jun 24 22:30:42 2021 : Modem #1 Connected

Modem Debug Information:

AT+QENG="servingcell"
+QENG: "servingcell","NOCONN","LTE","FDD",310,410,53FED95,63,9820,30,3,3,650C,-98,-10,-70,21,-
OK
AT+QNWINFO
+QNWINFO: "FDD LTE","310410","CDMA BC0",9820
OK
AT+QCAINFO
OK
AT+QCFG="nwscanmode"
+QCFG: "nwscanmode",0
OK
AT+QTEMP
+QTEMP:"aoss-usr","41"
+QTEMP:"mdm-q6-usr","42"
+QTEMP:"ddrss-usr","41"
+QTEMP:"cpu-usr","41"
+QTEMP:"mdm-core-usr","42"
+QTEMP:"xo-therm-adc","41"
+QTEMP:"pa-therm1-adc","40"
+QTEMP:"mdm-case-therm-adc","40"
OK

Thu Jun 24 22:52:42 2021 : /dev/ttyUSB2 AT+CPMS="SM"
+CPMS: 12,30,12,30,12,30
OK

Thu Jun 24 22:52:50 2021 : /dev/ttyUSB2 AT+CSQ
+CSQ: 21,99
OK
AT+QENG="servingcell"
+QENG: "servingcell","NOCONN","LTE","FDD",310,410,53FED95,63,9820,30,3,3,650C,-98,-10,-70,20,-
OK
AT+QNWINFO
+QNWINFO: "FDD LTE","310410","CDMA BC0",9820
OK
AT+QCAINFO
OK
AT+QCFG="nwscanmode"
+QCFG: "nwscanmode",0
OK
AT+QTEMP
+QTEMP:"aoss-usr","42"
+QTEMP:"mdm-q6-usr","42"
+QTEMP:"ddrss-usr","42"
+QTEMP:"cpu-usr","42"
+QTEMP:"mdm-core-usr","43"
+QTEMP:"xo-therm-adc","41"
+QTEMP:"pa-therm1-adc","40"
+QTEMP:"mdm-case-therm-adc","40"
OK

Cheers.

[Didneywhorl]

Hey there, I would first change the modem to LTE only, as it appears you are using CDMA channels along with what looks like B30 of LTE. Its hard to tell sometimes.

Your modem is definitely setup to use both.

Send command in AT command terminal:

Code: Select all

AT+QCFG="NWSCANMODE",3

Your signal is very clean and of decent quality, but the over signal power level is low.

You may have some changes happening on the cell towers, maybe not, and ATT is terrible about admitting when they are jacking with the network. All carriers really, but I seem to see a pattern with ATT.

After you send the above command, reset your modem with:

Code: Select all

AT+CFUN=1,1

The modem will hard reset, disappearing and then returning.

Also, what mode are you using (protocol) QMI or MBIM? IT should show on the main part of the Modem->Network Status page

[zubbs1]

I tinkered with it yesterday and probably set it to use non LTE channels.

I completed both commands.

The protocol is QMI. Is this good?

My thinking was also that they have to be doing some upgrade/changes to the tower since everything had worked flawlessly for a few months, and since I wasn't being throttled down to slow speed.

Is there anything in a logfile that would indicate how/why it breaks down? I am much more patient than my wife, but really want to rule out something on my end so it doesn't persist longer than needed.

[zubbs1]

This is what the system log shows immediately prior to dropping connection. It changes from network of LTE FDD to WCDMA or HSPA+ and will require manually disconnect/reconnect of modem, or if auto connection detection is active the router will auto reboot or reconnect the modem, and the cycle repeats.

Sat Jun 26 17:06:53 2021 user.notice Create Connection: Connected
Sat Jun 26 17:06:53 2021 user.notice Connection Monitor: Start Connection Monitor for Modem 1
Sat Jun 26 17:08:26 2021 daemon.info dnsmasq-dhcp[3655]: DHCPREQUEST(br-lan) 192.168.1.157 20:47:47:b9:13:19
Sat Jun 26 17:08:26 2021 daemon.info dnsmasq-dhcp[3655]: DHCPACK(br-lan) 192.168.1.157 20:47:47:b9:13:19 ClickyClicky
Sat Jun 26 17:08:38 2021 daemon.info dnsmasq-dhcp[3655]: DHCPREQUEST(br-lan) 192.168.1.157 20:47:47:b9:13:19
Sat Jun 26 17:08:38 2021 daemon.info dnsmasq-dhcp[3655]: DHCPACK(br-lan) 192.168.1.157 20:47:47:b9:13:19 ClickyClicky
Sat Jun 26 17:09:02 2021 user.notice Quectel Data: AT+CSQ ERROR AT+ +CPIN: READY +QUSIM: 1 QE +CREG: 2 NG="SERVINGCELL" +QENG: "SERVINGCELL","SEARCH" OK AT+QRSRP ERROR AT+QCAINF +QIND: SMS DONE O OK AT+QCFG="NWSCANMODE" +QCFG: "NWSCANMODE",0 OK AT+QTEMP +QTEMP:"AOSS-USR","47" +QTEMP:"MDM-Q6-USR","47" +QTEMP:"DDRSS-USR","47" +QTEMP:"CPU-USR","47" +QTEMP:"MDM-CORE-USR","47" +QTEMP:"XO-THERM-ADC","45" +QTEMP:"PA-THERM1-ADC","44" +QTEMP:"MDM-CASE-THERM-ADC","45" OK +QIND: PB DONE
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.043291] ------------[ cut here ]------------
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.047958] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:320 dev_watchdog+0x1ac/0x324
Sat Jun 26 17:09:03 2021 kern.info kernel: [ 291.056203] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.062955] Modules linked in: rt2800usb rt2800lib qcserial pppoe ppp_async option cdc_mbim usb_wwan sierra_net sierra rt2x00usb rt2x00lib rndis_host qmi_wwan pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm cfg80211 cdc_ncm cdc_ether xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY usbserial usbnet usblp slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.135138] nf_conntrack_netlink iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_itu_t crc_ccitt compat cdc_wdm cdc_acm fuse sch_cake nf_conntrack sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred ledtrig_usbport xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb tun vfat fat hfs nls_utf8 nls_iso8859_1 nls_cp437 mmc_block usb_storage mtk_sd
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.205907] mmc_core leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd uhci_hcd ohci_platform ohci_hcd ahci libahci libata ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 exfat usbcore nls_base usb_common mii crc32c_generic
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.228421] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.14.209 #0
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.234489] Stack : 00000000 8ff81240 80590000 800728ec 805b0000 80553fe4 00000000 00000000
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.242824] 8051f92c 8fc0fdc4 8fc3cffc 8058e907 8051a6c0 00000001 8fc0fd68 ac07f5c8
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.251156] 00000000 00000000 806f0000 00006d18 00000000 0000014c 00000008 00000000
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.259490] 00000000 80590000 00037c45 00000000 00000000 805b0000 00000000 8054e074
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.267825] 803762c0 00000140 00000003 8ff81240 00000000 8029dce8 0000000c 806f000c
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.276160] ...
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.278598] Call Trace:
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.281060] [<8000c7b0>] show_stack+0x58/0x100
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.285505] [<8045b144>] dump_stack+0xa4/0xe0
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.289855] [<8002f798>] __warn+0xe0/0x138
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.293939] [<8002f820>] warn_slowpath_fmt+0x30/0x3c
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.298891] [<803762c0>] dev_watchdog+0x1ac/0x324
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.303602] [<80089638>] call_timer_fn.isra.25+0x24/0x84
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.308890] [<800898f4>] run_timer_softirq+0x1bc/0x248
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.314028] [<80479010>] __do_softirq+0x128/0x2ec
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.318721] [<80034164>] irq_exit+0xac/0xc8
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.322885] [<80250c60>] plat_irq_dispatch+0xfc/0x138
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.327917] [<80007588>] except_vec_vi_end+0xb8/0xc4
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.332858] [<80008f50>] r4k_wait_irqoff+0x1c/0x24
Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.337758] ---[ end trace 07a66a0557bde082 ]---
Sat Jun 26 17:09:05 2021 daemon.info dnsmasq-dhcp[3655]: DHCPREQUEST(br-lan) 192.168.1.157 20:47:47:b9:13:19
Sat Jun 26 17:09:05 2021 daemon.info dnsmasq-dhcp[3655]: DHCPACK(br-lan) 192.168.1.157 20:47:47:b9:13:19 ClickyClicky
Sat Jun 26 17:09:20 2021 daemon.info dnsmasq-dhcp[3655]: DHCPREQUEST(br-lan) 192.168.1.157 20:47:47:b9:13:19
Sat Jun 26 17:09:20 2021 daemon.info dnsmasq-dhcp[3655]: DHCPACK(br-lan) 192.168.1.157 20:47:47:b9:13:19 ClickyClicky
Sat Jun 26 17:09:29 2021 daemon.notice hostapd: wlan0: STA-OPMODE-SMPS-MODE-CHANGED 5c:e0:c5:d9:d9:a6 static
Sat Jun 26 17:09:32 2021 daemon.info dnsmasq-dhcp[3655]: DHCPREQUEST(br-lan) 192.168.1.157 20:47:47:b9:13:19
Sat Jun 26 17:09:32 2021 daemon.info dnsmasq-dhcp[3655]: DHCPACK(br-lan) 192.168.1.157 20:47:47:b9:13:19 ClickyClicky
Sat Jun 26 17:09:35 2021 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 5c:e0:c5:d9:d9:a6
Sat Jun 26 17:09:49 2021 daemon.info dnsmasq-dhcp[3655]: DHCPREQUEST(br-lan) 192.168.1.157 20:47:47:b9:13:19
Sat Jun 26 17:09:49 2021 daemon.info dnsmasq-dhcp[3655]: DHCPACK(br-lan) 192.168.1.157 20:47:47:b9:13:19 ClickyClicky
Sat Jun 26 17:09:51 2021 daemon.info dnsmasq[3655]: read /etc/hosts - 4 addresses
Sat Jun 26 17:09:51 2021 daemon.info dnsmasq[3655]: read /tmp/hosts/odhcpd - 2 addresses
Sat Jun 26 17:09:51 2021 daemon.info dnsmasq[3655]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Sat Jun 26 17:09:51 2021 daemon.info dnsmasq-dhcp[3655]: read /etc/ethers - 0 addresses

From the Kernel Log:

[ 291.043291] ------------[ cut here ]------------
[ 291.047958] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:320 dev_watchdog+0x1ac/0x324
[ 291.056203] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out
[ 291.062955] Modules linked in: rt2800usb rt2800lib qcserial pppoe ppp_async option cdc_mbim usb_wwan sierra_net sierra rt2x00usb rt2x00lib rndis_host qmi_wwan pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm cfg80211 cdc_ncm cdc_ether xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY usbserial usbnet usblp slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache
[ 291.135138] nf_conntrack_netlink iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_itu_t crc_ccitt compat cdc_wdm cdc_acm fuse sch_cake nf_conntrack sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred ledtrig_usbport xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb tun vfat fat hfs nls_utf8 nls_iso8859_1 nls_cp437 mmc_block usb_storage mtk_sd
[ 291.205907] mmc_core leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd uhci_hcd ohci_platform ohci_hcd ahci libahci libata ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 exfat usbcore nls_base usb_common mii crc32c_generic
[ 291.228421] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.14.209 #0
[ 291.234489] Stack : 00000000 8ff81240 80590000 800728ec 805b0000 80553fe4 00000000 00000000
[ 291.242824] 8051f92c 8fc0fdc4 8fc3cffc 8058e907 8051a6c0 00000001 8fc0fd68 ac07f5c8
[ 291.251156] 00000000 00000000 806f0000 00006d18 00000000 0000014c 00000008 00000000
[ 291.259490] 00000000 80590000 00037c45 00000000 00000000 805b0000 00000000 8054e074
[ 291.267825] 803762c0 00000140 00000003 8ff81240 00000000 8029dce8 0000000c 806f000c
[ 291.276160] ...
[ 291.278598] Call Trace:
[ 291.281060] [<8000c7b0>] show_stack+0x58/0x100
[ 291.285505] [<8045b144>] dump_stack+0xa4/0xe0
[ 291.289855] [<8002f798>] __warn+0xe0/0x138
[ 291.293939] [<8002f820>] warn_slowpath_fmt+0x30/0x3c
[ 291.298891] [<803762c0>] dev_watchdog+0x1ac/0x324
[ 291.303602] [<80089638>] call_timer_fn.isra.25+0x24/0x84
[ 291.308890] [<800898f4>] run_timer_softirq+0x1bc/0x248
[ 291.314028] [<80479010>] __do_softirq+0x128/0x2ec
[ 291.318721] [<80034164>] irq_exit+0xac/0xc8
[ 291.322885] [<80250c60>] plat_irq_dispatch+0xfc/0x138
[ 291.327917] [<80007588>] except_vec_vi_end+0xb8/0xc4
[ 291.332858] [<80008f50>] r4k_wait_irqoff+0x1c/0x24
[ 291.337758] ---[ end trace 07a66a0557bde082 ]---

Can anyone decipher any useful information from this? This is what I see during the day. At night I don't believe I've been seeing the Netdev watchdog portion. It seems to work better in the evening after maybe 8 pm Central Standard Time, I'll try to update if the logfile shows a different pattern for later evening disconnects.

Appreciate the help!

[Didneywhorl]

You could try MBIM mode to see if anything changes. I can't decipher the hard core info in there.

What is your signal level, under Network Status, in general?

[zubbs1]

Yesterday, I flashed the firmware to GoldenOrb_2021-01-21and also I switched to MBIM, and haven't noticed anything different. I've tried examining all my signal information and nothing stands out. I've noticed that if I run a speedtest, there is a decent chance it will disconnect, but it isn't a guarantee in and of itself. I even used the SQM Qos to only use ~50% of my normal bandwidth, but it disconnected all the same. I tried running the router through openvpn, and I didn't immediately notice any disconnects, but I could only get about 15Mb/s down. I also tried disabling all ipv6 connections.

I'm just confused because it is not affecting my speed. I ran some speed tests at about 3am, and it was getting 240-250 Mb/s, but was disconnecting every 3 minutes. If ATT thinks my account is suspect, why aren't they deprioritizing me to a 128kb/s connection? In your experience, if they were doing some software only upgrade on their end (as I have never seen any crews working the tower), should it take 3+ weeks?

Funny thing is this morning it ran just fine for like four hours with zero disconnects while my wife and kids were using the internet for streaming videos and surfing the web.

Here is my signal info:

Network :LTE FDD

CSQ :31

Signal Strength : 100%

RSSI :-51 dBm

ECIO3G/RSRQ4G/SS_RSRQ5G: -13 dB

RSCP3G/RSRP4G/SS_RSRP5G : -70 dBm

[Didneywhorl]

You have crazy good signal, and clean. Id be interested to know what the SINR is, I'd bet its around 20.

...

I tried running the router through openvpn, and I didn't immediately notice any disconnects, but I could only get about 15Mb/s down.

...

I think your being managed by the network. ATT is notorious for this, constantly changing things too. If you are experiencing none of the disconnects over VPN, then it is 100% the cell network, not really your gear.

You might need to just find the right VPN for speeds for your location and setup.

[mtl26637]

Code: Select all

Sat Jun 26 17:09:03 2021 kern.warn kernel: [ 291.047958] WARNING: CPU: 3 PID: 0 at net/sched/sch_generic.c:320 dev_watchdog+0x1ac/0x324
Sat Jun 26 17:09:03 2021 kern.info kernel: [ 291.056203] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out

Looks like your modem is hanging/freezing. I've seen this randomly with my EM20G every once in awhile. Seems I recall they are known to do this occasionally more so than other modems just not quite as often as you are seeing. I would guess its a thermal issue. This might coincide with your time frame also as your normal working conditions would have been during the winter months and also in the evenings when it is cooler. You might try to add a heatsink directly to the top of the modem or a small fan to keep it cool. That is where I would start as this is what I had to do when installing in a sealed outdoor enclosure.

Another option to try to isolate the issue would be to disconnect it from your main home network and let it run 'ide' for a day and see if it continues to reboot. I would guess if it is a thermal issue that it would not hang if the modem is only in an idle state and not trying to maintain your home network.

[Adm1jtg]

Since your on goldenorb you can do to modem/network status and get a temp reading there

[zubbs1]

I'm not sure that its a thermal issue. My router sits on a wall shelf inside my living room. It currently reads 43C, which hardly seems near any thermal limit, yet it has been randomly disconnecting all evening.

[zubbs1]

You have crazy good signal, and clean. Id be interested to know what the SINR is, I'd bet its around 20.




I think your being managed by the network. ATT is notorious for this, constantly changing things too. If you are experiencing none of the disconnects over VPN, then it is 100% the cell network, not really your gear.

You might need to just find the right VPN for speeds for your location and setup.

From what I can find in the AT manual, At+QCSQ gives the sinr. Here is my output:

AT+QCSQ
+QCSQ: "LTE",56,-81,238,-9

OK

So I believe my SINR is 238 which I think is 47.6dB
I'm .25 miles from the tower with a clean line of sight, and it has many bands (2, 4, 12, 14, 30, 66). It flanks the interstate, so I'm sure it gets a fair amount of short duration traffic, but I would be surprised if it is saturated all the time.

As to the VPN:
Another hypothesis, down the drain.... Despite being on the router VPN, it still disconnected. I'm starting to agree the only thing left is ATT is to blame. The only question I have is can I do anything about it?

[Didneywhorl]

I think your right. I jave heard a few people starting to have issues with ATT lately. It may just be best to call and complain incessantly.

[mtl26637]

I don't think it is necessarily provider related. I agree it doesn't look thermal upon 2nd glance. It looks like it may be interference related? It seems the modem is hanging on transmit but hard to tell details. Google your error "wwan0 (qmi_wwan): transmit queue 0 timed out". I ran across a thread at quectel forum where this error is due to timeout. Maybe try moving the device to a different location just for testing? Seems I remember this error under heavy load too, did you try to remove from main network and let run idle for a time to see if error goes away?

[zubbs1]

I don't think it is necessarily provider related. I agree it doesn't look thermal upon 2nd glance. It looks like it may be interference related? It seems the modem is hanging on transmit but hard to tell details. Google your error "wwan0 (qmi_wwan): transmit queue 0 timed out". I ran across a thread at quectel forum where this error is due to timeout. Maybe try moving the device to a different location just for testing? Seems I remember this error under heavy load too, did you try to remove from main network and let run idle for a time to see if error goes away?

I was providing the information the best I knew it at the time, but after continuing to review the system log daily, it appears the error wwan0 is not a repeating entry.

[Adm1jtg]

I only glimpsed through this thead but with a signal that strong could you be over driving the signal? If your using any kind of antennas other then just the generic whip style, as a test only, I would try running with just 2 or 4 whip antennas (didnt see if you were 2x2 or 4x4. This will obviously reduce your signal strength as much as possible and I would be interested to see how it runs like that. Does it still drop?

If your already using whip style antennas try mocing the physical position of the router to a weaker area you got signal to burn anyway.

[zubbs1]

I only glimpsed through this thead but with a signal that strong could you be over driving the signal? If your using any kind of antennas other then just the generic whip style, as a test only, I would try running with just 2 or 4 whip antennas (didnt see if you were 2x2 or 4x4. This will obviously reduce your signal strength as much as possible and I would be interested to see how it runs like that. Does it still drop?

If your already using whip style antennas try mocing the physical position of the router to a weaker area you got signal to burn anyway.

My setup has 4 LTE whip antennas attached to the router (plus two for the wifi). If I remove all four, or 3 of 4, there is no connection made with tower. If I remove the rear two then nothing really changes either. If I remove the rear two, and wrap aluminum foil around the two main ones it gives me reduced signal but still the same download speed. Here is my signal numbers with the rear two removed and aluminum foil:

Network :
LTE FDD
CSQ :22
Signal Strength :70%
RSSI :-69 dBm
ECIO3G/RSRQ4G/SS_RSRQ5G: -7 dB
RSCP3G/RSRP4G/SS_RSRP5G : -99 dBm
AT+QCSQ
+QCSQ: "LTE",73,-100,217,-8

Also, after two speed tests, it still disconnected.

I have no weak signal area anywhere in my house. Is there any other way to better dampen my signal? I need like a partial faraday cage or something right?
Also, I'm still puzzled as to why this wasn't a problem for months before now?
Can I force my connection to lock to a different tower?

[Didneywhorl]

I wouldn't worry about weakening the signal. I had a tower 1/3 of a mile from me and I couldn't get anything but 100% signal and it was fantastic.

Copy your full System Log text and put in a text file and link it to us here.

I'm curious to see the full log.

[zubbs1]

I wouldn't worry about weakening the signal. I had a tower 1/3 of a mile from me and I couldn't get anything but 100% signal and it was fantastic.

Copy your full System Log text and put in a text file and link it to us here.

I'm curious to see the full log.

How do I get the full system log? I only know how to capture the like 7 hours on the "status-system log". Is there a location of a larger version?

Also, today it hasn't disconnected once :shrug:

[Didneywhorl]

Just copy paste all the text from the window there under Status->System Log.

The file is at: /tmp/System.Log

you can change the location in the System->System menu under the Logging tab. I change it to /etc/Sytem.Log

WinSCP or similar app can be sued to navigate the routers system files.

https://www.ofmodemsandmen.com/winscp.html

[zubbs1]

https://docs.google.com/document/d/1vtF ... sp=sharing

Sorry it took a bit. For awhile it locked itself into WCDMA. While I only got around 13 Mb/s, it stayed connected for more than a day at a time. The weird thing is that I cannot make it force itself to 3G. It just does it sometimes :Shrug:

I hope the link works, I have never shared a doc to the public before.

Cheers.

[mtl26637]

At quick glance it looks like in about a day and a half of logs that you had about 6 LTE reconnects and around 375 reconnects of dhcp clients on your lan. It sure looks like your router is keeping busy trying to keep up with your wireless network thats for sure. I'd guess about 99% of that log is all local wireless lan information and 1% LTE connection info. I didn't see anything that really stands out that would indicate why the LTE connection is dropping however.

Is there any way you can get your wireless traffic and local lan off the LTE modem/router setup? Depending on the device, most use a standard router for local home wireless and wired traffic and connect the LTE modem/router to its WAN port for internet source.

Might be a start if nothing else?

[bcase7090]

So I have a Em20 also, I posed about the same problem but with sprint, I never got it solved, but I had a spare sim/ plan and an old airmaster so I ended up doing a WAN failover. I know I saw a post about another Quectel Modem because I was looking into replacing my whole set up, the guy said he was having problems too and ended up being the power supply. He said that the 12v4 amps is not enough to power it and it would disconnect it. I'm not sure if this is true or not but have been always wondering.

[Didneywhorl]

Your losing your modem, it may be power related, as it doesn't look like its boot looping. Boot looping is the death knell.

[Didneywhorl]

So I have a Em20 also, I posed about the same problem but with sprint, I never got it solved, but I had a spare sim/ plan and an old airmaster so I ended up doing a WAN failover. I know I saw a post about another Quectel Modem because I was looking into replacing my whole set up, the guy said he was having problems too and ended up being the power supply. He said that the 12v4 amps is not enough to power it and it would disconnect it. I'm not sure if this is true or not but have been always wondering.

I used to run an em20 on 3A. It should be enough. 4A should definitely be enough. Unless its a failing supply.

[zubbs1]

I am currently using a 3A power supply. Its about a year old, so it may be failing. I have ordered a 4A power supply to rule out any underpower issue.

I also connected my ASUS RT-AC68U router to do the LAN and WIFI management. Will test it out for a few days and post an update.

Cheers.

[gscheb]

Used 2 amp for long time on mine for visible and TMobile. But had all kinds of issues staying connected to at&t. Finally started using a lesser device and it stays connected. A Netgear LB1120. Not saying anyone should get one of these. Just saying sometimes there is goofy stuff that might never make logical sense.

[zubbs1]

This is the newest logfile after using a standalone router for all lan and wifi traffic. It is also running the open vpn client. I have also upgraded the power supply to 4A.

https://docs.google.com/document/d/151J ... sp=sharing

[mtl26637]

Much cleaner logs for sure. Looks like you had around 5-10 reconnects within about a days time, most of them occurred right after the connection monitor ping test. Unfortunately the logs do not show specifics of why the connection fails. Maybe tweak some of the settings in connection monitor or disable it altogether and see how things run? Some modems can work smoother and recover better/quicker in "ECM" mode rather than "MBIM", might be worth a try. A couple of the dropouts shows the modem just disappearing, which is usually power related.

This one does seem to be quite the mystery.