3G killed after most 12 hours

[mihaly.reg@…]

Using F2G with huawei 160x 3G dongle with unlimited data plan. No other option conneted to fonera. Accessing internet only from wifi smartphones. The 3G connection never stay online more then 12 hours, it's killed and does not reconnect. A secondary effect is that wifi is also killed. I could capture a logread only until wifi was disconnected, see attached.

[matthijs]

I haven't been able to figure out what happens from your logread. What seems to happen, is that Chillispot is restarted, which happens regularly. However, this should not break the private wifi connection, and certainly not the 3G connection. However, it looks like both of these get logged after the wifi disconnect, so I can't really tell what's happening. From looking at the code, I can't find anything wrong either.

Perhaps you can try to get a full logread? In /etc/init.d/boot there are two lines that call logread that are commented out, if you enable them, a /tmp/logread will be kept which you can retrieve after reconnecting to your wifi (or ethernet if wifi doesn't come back up).

I'll also see if I can reproduce the problem, but it'll take me a while to find time for that.

[mihaly.reg@…]

Ok, i will try to start log in boot. Btw...I found that if 3g is not available every one second fonera try to contact updates.fon.com and writes one line in logfile. Woudn't this flood the log and fill /tmp until fonera will hang and log cannot be retrieved? Why updates.fon.com is tried so frequent?

[matthijs]

onlined checks the internet connectivity every 10 seconds, as long as its online. As soon as its offline, it checks every second so it can detect the Fonera coming back online right away.

Now that onlined only controls the hotspot availability and no longer the orange screen, I think this might be a bit too aggressive. I've created #1125 about this.

If you are really worried about this, I think you can just run killall onlined to make it stop checking (wait until your Fonera's status is online, though, so until the power led is green).

[mihaly.reg@…]

Is there any side effect if I delete /sbin/onlined forever ? I'm using only private wifi.

[matthijs]

I think package installation from the internet might be disabled, but I don't remember anything else using the online status.

[mihaly.reg@…]

Ok I have the logs when 3g stopped working: puttywf.1.failing3G.log. I left home in afternoon and when I returned in evening the 3g was dead. A strange behavior: LED was green on fonera.

The worst part followed after this, I could not reconnect 3G following 3 hours. Checked the signal with another 3G phone and it was ok, I could connect to internet, but not with fonera. I tried several scenarios, see logs 2....6, none worked. At some point I could not even connect to fonera with ssh after I plugged out and in the usb hub, so the log nr.7 is missing. Then log nr.8 shows that it finally reconnected after another powercycle.

[matthijs]

This ticket got lost in my inbox, sorry for that.

Is this problem still occurring for you?

I've looked at the logs, but I'm not entirely sure what is going on yet. In the first log, it seems that the PPP connection simply stops working at some point (after 512 minutes of connection this time). No ppp-ping packets come through, so ppp kills the connection.

853	Dec  1 18:26:10 Fonera daemon.info pppd[2126]: No response to 5 echo-requests
854	Dec  1 18:26:10 Fonera daemon.notice pppd[2126]: Serial link appears to be disconnected.

At this time, umtsd restarts the connection, but the modem is not responding to the reset command (ATZ):

872	Dec  1 18:26:24 Fonera local2.info chat[25426]: send (ATZ^M)
873	Dec  1 18:26:24 Fonera local2.info chat[25426]: expect (OK)
874	Dec  1 18:27:09 Fonera local2.info chat[25426]: alarm

However, for some reason umtsd doesn't keep trying, but sticks around in the "IDLE" state. I'll see if I can reproduce this locally, since this shouldn't happen.

On your subsequent logs, umtsd can connect to the modem as expected, but the modem does not offer a working IP configuration to umtsd. The Fonera detects this by looking at the DNS server IP (10.11.12.13 is a dummy often used to say "The modem is not yet ready") and kills pppd again.

71	Nov  7 21:33:47 Fonera daemon.warn pppd[2262]: Could not determine remote IP address: defaulting to 10.64.64.64
472	Nov  7 21:33:47 Fonera daemon.notice pppd[2262]: local  IP address 172.17.42.108
473	Nov  7 21:33:47 Fonera daemon.notice pppd[2262]: remote IP address 10.64.64.64
474	Nov  7 21:33:47 Fonera daemon.notice pppd[2262]: primary   DNS address 10.11.12.13
475	Nov  7 21:33:47 Fonera daemon.notice pppd[2262]: secondary DNS address 10.11.12.14
...
521	Nov  7 21:34:22 Fonera user.notice root: ip-up.d/10-umts: Restarting pppd, since DNS server address indicates the 3G modem is not ready yet

Again, umtsd does not properly reconnect for some reason.

The subsequent logs show that the modem isn't responding again, until after the last powercycle when it starts working again.

I suspect that there might be some bug or incompatibility in the 3G modem, perhaps triggered by the way the Fonera talks to it. This might mean we can't completely fix this problem in the Fonera.

However, it seems that the Fonera is not properly reconnecting after a 3G connection fails, which is something we can probably fix. I'll see if I can reproduce that problem here, and if so if it can be fixed.

[mihaly.reg@…]

Well, I have not tested this for a long time now. Since then I bought a TP-LINK 3G router TL-MR3420, but that did not worked well either, so being dissapointed by latest technologies I have abandoned the idea to use a 3G router. Instead I'm using the 3G stick directly on Windows. Maybe sometime in the future I will try to find some time to power on my Fonera and retest this. I have all the components, but very busy to do this right now.

[matthijs]

I guess TP-link is suffering from the same problem as FON: 3G sticks are very badly standardized and often seem to require a very specific incantation to get them working (i.e., the same incantation the Windows driver for the particular 3G modem uses).

In any case, I tried killing pppd during a connection, which resulted in umtsd reconnecting just like expected. This means that reconnecting is not totally broken, but perhaps only in some specific circumstances.

However, I did notice at one point that umtsd.lua was segfaulting (for future reference: when getting the value of "needpin" in handle_state_error()), but when I disconnected the 3G stick, this problem magically disappeared and I haven't been able to reproduce it since...

For now, I am unsure how to proceed with this problem. In the future, if/when we implement umtsd2 in the firmware, we should revisit this setup to see if it still causes problems.