Asuswrt-Merlin 3.0.0.4.270.26 - Disconnect

[Auximen]

I was so happy... But 1 hour ago:

Jan  1 04:00:54 /usr/sbin/l2tpd[520]: Too many retransmissions on tunnel (45002/0); closing down
Jan  1 04:01:04 /usr/sbin/l2tpd[520]: tunnel_establish: gethostbyname failed for 'tp.internet.beeline.ru'
Jan  1 04:01:14 /usr/sbin/l2tpd[520]: tunnel_establish: gethostbyname failed for 'tp.internet.beeline.ru'

I will try RT-N16_3.0.0.4_354.27-BETA1b.

Same problem. After ASUS RT-N66U firmware update to 3.0.0.4.354.28 and clear all settings Beeline L2TP (Russia) internet work well, but after first reboot connection was down with log error "Too many retransmissions on tunnel (---/---)". On 3.0.0.4.270.26 Beeline Internet work good.

PS. RMerlin, please, include to the next beta firmware this fixes file streaming for some devices (MiniDLNA minidlna/upnphttp.c issue), thanks.

 

[DmitryOlenin]

Some new lines. This time it was reconnected.
Firmware: RT-N16_3.0.0.4_354.27.

Apr 30 17:27:46 WAN Connection: Ethernet link down.
Apr 30 17:27:46 stop_nat_rules: apply the redirect_rules!
Apr 30 17:28:13 /usr/sbin/l2tpd[518]: Too many retransmissions on tunnel (32995/18554); closing down
Apr 30 17:28:13 pppd[635]: Terminating on signal 15
Apr 30 17:28:13 pppd[635]: Connect time 919.6 minutes.
Apr 30 17:28:13 pppd[635]: Sent 1370694729 bytes, received 657543196 bytes.
Apr 30 17:28:13 pppd[635]: Couldn't set PPP MRU: Transport endpoint is not connected
Apr 30 17:28:13 pppd[635]: Modem hangup
Apr 30 17:28:13 pppd[635]: Connection terminated.
Apr 30 17:28:13 dnsmasq[449]: read /etc/hosts - 5 addresses
Apr 30 17:28:13 dnsmasq[449]: read /etc/hosts.dnsmasq - 1 addresses
Apr 30 17:28:13 dnsmasq-dhcp[449]: read /etc/ethers - 1 addresses
Apr 30 17:28:13 dnsmasq[449]: using nameserver 213.234.192.8#53
Apr 30 17:28:13 dnsmasq[449]: using nameserver 85.21.192.3#53
Apr 30 17:28:13 pppd[635]: Exit.
Apr 30 17:28:50 WAN Connection: Fail to connect with some issues.
Apr 30 17:28:53 /usr/sbin/l2tpd[518]: tunnel_establish: gethostbyname failed for 'tp.internet.beeline.ru'
Apr 30 17:29:33 /usr/sbin/l2tpd[518]: tunnel_establish: gethostbyname failed for 'tp.internet.beeline.ru'
Apr 30 17:29:43 pppd[779]: Plugin pppol2tp.so loaded.
Apr 30 17:29:43 pppd[779]: pppd 2.4.5 started by admin, uid 0
Apr 30 17:29:43 pppd[779]: Using interface ppp0
Apr 30 17:29:43 pppd[779]: Connect: ppp0 <--> l2tp (85.21.0.240)
Apr 30 17:29:44 pppd[779]: CHAP authentication succeeded: CHAP authentication success, unit 18858
Apr 30 17:29:44 pppd[779]: CHAP authentication succeeded
Apr 30 17:29:44 miniupnpd[669]: Failed to get IP for interface ppp0
Apr 30 17:29:44 miniupnpd[669]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Apr 30 17:29:44 miniupnpd[669]: Failed to get IP for interface ppp0
Apr 30 17:29:44 miniupnpd[669]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Apr 30 17:29:44 miniupnpd[669]: Failed to get IP for interface ppp0
Apr 30 17:29:44 miniupnpd[669]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Apr 30 17:29:44 pppd[779]: local IP address 89.178.65.196
Apr 30 17:29:44 pppd[779]: remote IP address 89.178.64.1
Apr 30 17:29:44 pppd[779]: primary DNS address 85.21.192.5
Apr 30 17:29:44 pppd[779]: secondary DNS address 213.234.192.7
Apr 30 17:29:44 miniupnpd[669]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Apr 30 17:29:44 miniupnpd[669]: Failed to get IP for interface ppp0
Apr 30 17:29:44 miniupnpd[669]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Apr 30 17:29:44 dnsmasq[449]: read /etc/hosts - 5 addresses
Apr 30 17:29:44 dnsmasq[449]: read /etc/hosts.dnsmasq - 1 addresses
Apr 30 17:29:44 dnsmasq-dhcp[449]: read /etc/ethers - 1 addresses
Apr 30 17:29:44 dnsmasq[449]: using nameserver 213.234.192.7#53
Apr 30 17:29:44 dnsmasq[449]: using nameserver 85.21.192.5#53
Apr 30 17:29:44 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Apr 30 17:29:44 rc_service: ip-up 783:notify_rc stop_upnp
Apr 30 17:29:44 rc_service: ip-up 783:notify_rc start_upnp
Apr 30 17:29:44 miniupnpd[813]: HTTP listening on port 52294
Apr 30 17:29:44 miniupnpd[813]: Listening for NAT-PMP traffic on port 5351
Apr 30 17:29:44 miniupnpd[813]: upnp_event_send: send(): Connection reset by peer
Apr 30 17:29:47 WAN Connection: WAN was restored.

 

[RMerlin]

Any of you tried setting the DHCP mode to Normal if it was set to Aggressive on the WAN page?

 

[DmitryOlenin]

Where is it?
My WAN page.
My LAN page.

 

[Auximen]

I don't see this settings on http://192.168.1.1/Advanced_WAN_Content.asp page. Or, these settings should be edited using console tool SSH PuTTY?

 

[RMerlin]

I guess Asus doesn't expose that setting while in VPN mode then.

You could try switching to DHCP mode, changing that value, then switching back to L2TP mode. Not sure if will get used by the DHCP part of the VPN, but worth a try.

 

[DmitryOlenin]

There is no DHCP mode in my RT-N16_3.0.0.4_270.26b.
This is a picture.

And "DHCP mode" isn't exist at all 5 connection types.

 

[RMerlin]

Automatic IP is "DHCP Mode".

This is what I'm talking about:

That feature was added in build 354 (which your previous post said you were running):

 

[DmitryOlenin]

Oh, i see. Now i will try to test 270.26b.
This firmware is more stable with Beeline by information from russians forums.

Maybe Auximen can test DHCP mode?

 

[Mullins]

Oh, i see. Now i will try to test 270.26b.
This firmware is more stable with Beeline by information from russians forums.

Well...it is labeled stable while the 28b is beta...

 

[Auximen]

Maybe Auximen can test DHCP mode?

No. Now I use the firmware 3.0.0.4.270.26 that works in my opinion the most stable and has only one bug - the incorrect work MiniDLNA + Phillips SmartTV, due to an error in the file minidlna/upnphttp.c. Will install the new firmware only if it is fixed bug with MiniDLNA, and then try to suggested Merlin variant with switch DHCP mode.

 

[DmitryOlenin]

3.0.0.4.270.26
What was it? All previous logs were destroyed...
I think this was some kind of router reboot, but why? And where is the logs?

Jan 1 04:00:07 syslogd started: BusyBox v1.20.2
Jan 1 04:00:07 kernel: klogd started: BusyBox v1.20.2 (2013-03-17 15:24:32 EDT)
Jan 1 04:00:07 kernel: Linux version 2.6.22.19 (root@asus) (gcc version 4.2.4) #1 Sun Mar 17 15:53:37 EDT 2013
Jan 1 04:00:07 kernel: CPU revision is: 00019740
<skipped by me>
Jan 1 04:00:38 dnsmasq[489]: read /etc/hosts - 3 addresses
Jan 1 04:00:38 dnsmasq[489]: read /etc/hosts.dnsmasq - 1 addresses
Jan 1 04:00:38 dnsmasq-dhcp[489]: read /etc/ethers - 1 addresses
Jan 1 04:00:38 dnsmasq[489]: using nameserver 213.234.192.7#53
Jan 1 04:00:38 dnsmasq[489]: using nameserver 85.21.192.5#53
Jan 1 04:00:38 notify_rc : start_nat_rules
Jan 1 04:00:38 start_nat_rules: apply the nat_rules!
Jan 1 04:00:38 notify_rc : stop_upnp
Jan 1 04:00:38 notify_rc : start_upnp
Jan 1 04:00:38 miniupnpd[592]: HTTP listening on port 52929
Jan 1 04:00:38 miniupnpd[592]: Listening for NAT-PMP traffic on port 5351
Jan 1 04:00:38 notify_rc : stop_ntpc
Jan 1 04:00:38 notify_rc : start_ntpc
Jan 1 04:00:38 rc_service: start_ntpc is waitting stop_ntpc...
Jan 1 04:00:38 miniupnpd[592]: upnp_event_send: send(): Connection reset by peer
Jan 1 04:00:39 WAN Connection: WAN was restored.
May 1 21:31:59 notify_rc : restart_upnp

 

[RMerlin]

The log is stored in RAM.

 

[DmitryOlenin]

Is there some way to write logs... maybe on flash?
Can it help to know reasons of disconnect?

 

[RMerlin]

Is there some way to write logs... maybe on flash?
Can it help to know reasons of disconnect?

Writing logs to flash is a bad idea. Lots of writes = early death for your flash, which has a limited number of allowed write cycles. Writing to a USB disk might be possible, however it's not recommended - the USB disk won't be available until later on during the boot process.

Having logs stored to a disk won't help diagnosing disconnects anyway, unless your router keeps rebooting itself, which means you have a problem with the router itself.

 

[DmitryOlenin]

Having logs stored to a disk won't help diagnosing disconnects anyway, unless your router keeps rebooting itself, which means you have a problem with the router itself.

Do you mean, that reason of my sudden reboots is a hardware problem (can it be Beeline problem?)?
Does it mean, that i need to replace my router (or repair it)?

 

[RMerlin]

Do you mean, that reason of my sudden reboots is a hardware problem (can it be Beeline problem?)?
Does it mean, that i need to replace my router (or repair it)?

You never previously mentioned multiple reboots, only connection drops. If you do have regular reboots, then yes, something must be wrong with the hardware, and the router might need replacement.

There is a difference between a router reboot, and a connection drop. Reboots are totally unrelated to the ISP.

 

[DmitryOlenin]

Actually, I didn't know about reboots.

I had a connection drops only, but now i see what was it.
Maybe sometimes it was not only drops but reboot of router.

Thank you for your help. You are very benevolent!

 

[DmitryOlenin]

3 days without disconnects.
I bought UPS

But "tunnels" error is still here.
Sometimes it autoreconnect in 2 minutes.
I got an advice within Beeline forum: "lcp-echo-adaptive" in additional pppd parameters.
RMerlin, how do you think, can it be good for me?

 

[RMerlin]

3 days without disconnects.
I bought UPS

But "tunnels" error is still here.
Sometimes it autoreconnect in 2 minutes.
I got an advice within Beeline forum: "lcp-echo-adaptive" in additional pppd parameters.
RMerlin, how do you think, can it be good for me?

No idea. But I spent two full evening working on tracking down the Beeline issue where it was failing to connect at boot time, having obtained further info from another user. The issue was caused by the new web redirection implementation that I did in 354 Beta to resolve the issue where LAN hostnames weren't resolved if WAN was down.

What web redirection does is, either at boot time or after WAN goes down, all DNS queries or attempts to access a website are intercepted, and redirected to the router's internal server. This is what allows you to plug a new router, type "www.whatever.com", and end up on the configuration wizard - no need to know the router's IP.

The problem is with Beeline, you really have two stages in WAN connection: first the DHCP lease, then the VPN tunnel. Expected behaviour (before 3.0.0.4.354 beta) would be:

1) Router is booted. All DNS queries redirected to 10.0.0.1, which is intercepted by ebtables, and redirects to the router's webui.
2) WAN gets a DHCP lease from Beeline. You get an IP, and two internal DNS servers from Beeline.
3) The VPN client resolves Beeline's VPN server hostname using the internal DNS, connects the tunnel, and obtains new, public DNS.

The first bug in 354 beta was dnsmasq wasn't properly started at boot time because the router was trying to start it too early, preventing hostname resolution of the VPN hostname.

A second issue was, when the tunnel went down, the router would immediately re-enable web redirection, preventing the VPN client from resolving the VPN hostname. I am not sure if this was also a regression caused by my re-implementation of web redirect or something that was also broken in the original FW. Normally, web redirection should only get enabled if the actual WAN interface (either the Ethernet connection or the primary DHCP link) went down.

I had to recreate a lab environment similar to Beeline in my living room: main router providing a DHCP lease to my test router, and a PPTP server running in a virtual machine for the second stage of the connection. This allows my test router to work just like yours would on Beeline: get a DHCP lease, resolve the testvpn.mylan.lan hostname, and connect to its PPTP VPN.

Now that I was able to simulate a Beeline environment, I was able to track down and fix the first issue, which took a lot of time and experiments.

The second issue, which is web redirection being re-enabled when tunnel went down has taken me a lot of time as well. It was only last night at about 4 am that I had a sane, working solution: from now on, web redirection will still be active at boot time, but if you use either l2tp or pptp, it will NOT be re-enabled if the WAN goes down.

I still need to do a lot of tests here (this is what is causing Beta 2 to be delayed). There are various scenarios I haven't tested yet, such as name resolution after the tunnel goes down but dhcp lease remains valid.

So, at this point in my current development code:

1) The connect to Beeline at boot time is fixed
2) The reconnect if tunnel went down might be fixed, it needs further testing

In the mean time, Beeline users might want to revert back to 270.26b until the next beta release comes out.


PS: I still hate Beeline's weird architecture. I haven't heard of any other ISP in the world using a similar design.