3G stability issues

[lancer73]

Just switched from Draytek 2130n to Asus RT-N66U.

The reason for switching was the wireless. I have several access points and the Draytek doesn't like it when switching from the internal AP to an external one and blocks Internet access for several minutes (confirmed bug). I have been using that modem for several years in combination with a glass-fibre modem and a 3G USB stick (Huawei E160G) for fallback reasons.

This combination proved to be rock solid.

Now the Draytek has been replaced with the RT-N66. Wifi is a real improvement. The Internet connection is really stable, when the 2nd (3G) WAN connection is not configured. There is only one artifact in the log (second line from the bottom):

Jan 1 01:00:08 kernel: NTFS (with native replay) support included
Jan 1 01:00:08 kernel: optimized: speed
Jan 1 01:00:08 kernel: Build_for__asus_n66u_2011-10-27_U86_r187446_b122
Jan 1 01:00:09 stop_nat_rules: apply the redirect_rules!
Jan 1 01:00:09 WAN Connection: ISP's DHCP did not function properly.
Jan 1 01:00:09 RT-N66U: start httpd

It happens only once during boot. The modem acquires an IP address just fine and refreshes it once every hour.

When I configure the 3G fallback connection something different happens. After boot, WAN shows connected and 3G disconnected.

Within a couple of hours this happens:
Jan 19 19:24:28 WAN Connection: ISP's DHCP did not function properly.
Jan 19 19:24:28 stop_nat_rules: apply the redirect_rules!
Jan 19 19:26:32 rc_service: wanduck 320:notify_rc restart_wan_if 0
Jan 19 19:26:32 stop_wan(): perform DHCP release
Jan 19 19:26:32 kernel: Attempt to kill tasklet from interrupt
Jan 19 19:26:33 dhcp client: bound 77.175.185.74 via 77.175.176.1 during 3600 seconds.
Jan 19 19:26:34 rc_service: wanduck 320:notify_rc restart_wan_line 1
Jan 19 19:26:34 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0__dev_ttyUSB0)!
Jan 19 19:26:34 miniupnpd[2962]: HTTP listening on port 35446
Jan 19 19:26:34 miniupnpd[2962]: Listening for NAT-PMP traffic on port 5351
Jan 19 19:26:41 rc_service: wanduck 320:notify_rc restart_wan_if 1
Jan 19 19:26:41 pppd[705]: Connection terminated.
Jan 19 19:26:42 pppd[705]: Child process /bin/comgt -d /dev/ttyUSB0 -s /etc/ppp/3g/Generic_disconn.scr (pid 2994) terminated with signal 15
Jan 19 19:26:42 pppd[705]: disconnect script failed
Jan 19 19:26:43 stop_wan(): perform DHCP release
Jan 19 19:26:45 pppd[2997]: pppd 2.4.5 started by admin, uid 0
Jan 19 19:26:47 rc_service: wanduck 320:notify_rc restart_wan_line 0
Jan 19 19:26:47 start_nat_rules: apply the nat_rules(/tmp/nat_rules_eth0_eth0)!
Jan 19 19:26:47 miniupnpd[2962]: received signal 15, good-bye
Jan 19 19:26:48 WAN Connection: WAN was restored.
Jan 19 19:26:49 pppd[2997]: Connect: ppp0 <--> /dev/ttyUSB0
Jan 19 19:26:51 pppd[2997]: Could not determine remote IP address: defaulting to 10.64.64.64
Jan 19 19:26:51 pppd[2997]: not replacing existing default route via 77.175.176.1
Jan 19 19:26:51 pppd[2997]: local IP address 188.91.195.109
Jan 19 19:26:51 pppd[2997]: remote IP address 10.64.64.64
Jan 19 19:26:51 pppd[2997]: primary DNS address 84.241.226.140
Jan 19 19:26:51 pppd[2997]: secondary DNS address 84.241.226.9

This interrupts the Internet connection for a couple of minutes (and worse, the Synology NAS behind the router updates the DDNS registration).

Then everything works normally, except now WAN shows as connected and 3G shows standby.

After 1 to 3 hours this happens again, etc....

Does anyone have any idea what causes this?

Some more observations:
1) Logs say ttyUSB0, even when modem is connected to ttyUSB1 (modem is really on ttyUSB0 now)
2) With comgt the reception strength shows as 21 out of 99. Could it be this is not enough? But if it is, disconnecting the main line while the backup line has a problem is really crappy behavior.
3) Already tried several factory resets
4) Modem is on latest firmware (3.0.0.4.374.2050).

 

[L&LD]

"Modem is on latest firmware"

is getting really tiring... there are many versions of the 'latest firmware' - couldn't you simply state which one you're using?

You may want to test drive the RMerlin firmware 374.38_2 or wait for the xxx.39 version he is currently working on - this issue may be already fixed for you.

http://forums.smallnetbuilder.com/showthread.php?t=7846

 

[lancer73]

"Modem is on latest firmware"

is getting really tiring... there are many versions of the 'latest firmware' - couldn't you simply state which one you're using?

You may want to test drive the RMerlin firmware 374.38_2 or wait for the xxx.39 version he is currently working on - this issue may be already fixed for you.

http://forums.smallnetbuilder.com/showthread.php?t=7846

Sorry, valid point. I even had the version in the paste buffer, but forgot to hit paste. The version is 3.0.0.4.374.2050.

Trying out the RMerlin firmware is on the list, but I would like to determine what the cause is.

 

[L&LD]

Thanks for that data. I can't help with this issue, but maybe someone (now) can.

The thing with the RMerlin versions that I like is that he cleans up the Asus code which can be sloppy.

If this issue is fixed in a later firmware, I would bet RMerlin would be the primary reason.

 

[lancer73]

Switched to Merlins firmware today (last version; 374.39).

3G is still disabled. I want to ascertain that the modem is really stable (it was with 374.2050 without 3G)

First thing I noticed in the logs is that the

"WAN Connection: ISP's DHCP did not function properly."

is still there in the boot process. The link is IPv4, IPv6 is disabled. No cloned MAC address or any such business.

Does anyone have an idea to troubleshoot this?

 

[lancer73]

The problem is not solved in Merlin's firmware. Exact same behavior as the factory build.

 

[L&LD]

http://forums.smallnetbuilder.com/showpost.php?p=104003&postcount=3


If you can give more specific details of what you've done and tried to solve this, it may help others see where you're doing a misstep.

I don't use a 3G modem, so cannot help you directly.

 

[lancer73]

http://forums.smallnetbuilder.com/showpost.php?p=104003&postcount=3


If you can give more specific details of what you've done and tried to solve this, it may help others see where you're doing a misstep.

I don't use a 3G modem, so cannot help you directly.

To show that simple questions go a long way....

While I was describing the situation I realised that I had not tested without watchdog. Because there were no watchdog messages in the log, I discounted that in the root cause analysis.

Anyway, when I turned the watchdog off, the 3G became stable. I think the failovers were caused by the fact that the ping Delay was set at 0.

Fail-back does not work, as is documented elsewhere
http://forums.smallnetbuilder.com/showthread.php?t=11228

I created my own fail-back script. See at the bottom. I will try with watchdog later on, but I also need an intelligent way to find out if the primary connection is working again (watchdog can fail, while primary interface still shows as configured, with a pingable gateway, so there needs to be some additional magic)

My script (based on the aforementioned topic). Tested and works under all conditions:

#!/bin/sh
lockfile=/tmp/wan_start_locked

logger -t "($(basename $0))" $$ Primary line check starting.... " $0${*:+ $*}."

# If Semaphore Lock file exists then exit
if [ -e $lockfile ]; then
logger -t "($(basename $0))" $$ already LOCKED since `cat $lockfile` .....EXIT
exit
fi

# Create the locking semaphore file
date > $lockfile

logger -t "($(basename $0))" $$ wan-start LOCKED at `cat $lockfile`

# This script only needs to act on the following instances:
# 1) Primary WAN has an IP number (not 0.0.0.0)
# 2) Secondary WAN has an IP number (not 0.0.0.0)
# 3) Secondary WAN is active as shown by the nvram parameter wan_primary

# Allow for a stabilization period.
sleep 30

# Determine primary IP address
primip=$(nvram get wan0_ipaddr)
if [ "$primip" = "0.0.0.0" ] || [ "$primip" = "" ]
then
logger -t "($(basename $0))" $$ primary connection does not have IP address .....EXIT
rm $lockfile
exit
else
logger -t "($(basename $0))" $$ primary connection has IP address $primip .....OK
fi

# Determine secondary address
secoip=$(nvram get wan1_ipaddr)
if [ "$secoip" = "0.0.0.0" ] || [ "$secoip" = "" ]
then
logger -t "($(basename $0))" $$ secondary connection does not have IP address .....EXIT
rm $lockfile
exit
else
logger -t "($(basename $0))" $$ secondary connection has IP address $secoip .....OK
fi

# Determine which is primary
primary=$(nvram get wan_primary)
if [ "$primary" = "0" ]
then
logger -t "($(basename $0))" $$ primary connection shows as active ....DO NOTHING
else
logger -t "($(basename $0))" $$ secondary connection shows as active ....OK

# Determine secondary interface
secoif=$(nvram get wan1_pppoe_ifname)
logger -t "($(basename $0))" $$ kicking secondary connection $secoif in the nuts

ifconfig $secoif down

# Modem should now recover its connections with primary as active and secondary as standby
fi

logger -t "($(basename $0))" $$ wan_start complete .....EXIT
rm $lockfile