What's new

Asus RT-AC68U PPPoE bridge random disconnects, ADSL modem stays up

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Chunkers

Occasional Visitor
I am having some problems with my ADSL 2+ connection and the logs from my modem seem to indicate that the disconnects are originating from my AC68U running 380.57 firmware. The connection goes down with this :
Router said:
Mar 8 02:00:38 miniupnpd[15030]: Failed to get IP for interface ppp0
Mar 8 02:00:38 miniupnpd[15030]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 8 02:00:41 WAN Connection: Fail to connect with some issues.
Mar 8 02:00:41 stop_nat_rules: apply the redirect_rules!
Mar 8 02:00:41 pppd[510]: Connection terminated.
Mar 8 02:00:41 pppd[510]: Modem hangup

I did a hard reset and followed the instructions when i I re-flashed my router.

This can happen multiple times ans seemingly at random, whilst my modem indicates there is no loss of connection. Are the any known issues or bugs which could be causing this?

Any suggestions of what I might try? I could re-flash etc

Chunks
 
Have you searched this forum, using "disconnects" as at least one of the search terms? The topic crops up from time to time. Obviously, there's no single, magic bullet, but there is, as always here, some good advice and tips, which may well help with your troubleshooting.
 
That's good - I just wanted to check because if someone has already searched the forum they usually say so, and they say what they have tried, which, indeed, you did do.

Did it start with 380.57? And, if so, soon after installation? Anything at all changed just before the problem started, either at your end or the ISP's?
 
Thanks for your reply, I completely understand, I wasn't able to find a similar issue by searching unfortunately,

380.57 was the first non-OEM firmware I have flashed onto my router - I mist admit I did assume the problem lay elsewhere so I have been through an exhaustive process with my ISP which has resulted in me replacing my modem, rewiring my home phone line and replacing the socket and I have had my line under test. The Asus RT-AC68U is really the last thing I haven't changed, its relatively new.

As a result, by process of elimination the finger of suspicion is starting to point at the AC68U particularly because it seems that, as shown above, on occasion my DSL connection is uninterrupted but my WAN connection fails.

I currently use my Zyxel VMG8324 as a modem bridged to the VCMG8324, I have the option to use it as a full modem/router and just use the AC68U as a WAP. A shame, but in the short term it might prove something. I'll probably try this tomorrow when the teenagers are out!

In the mean time I thought I would check to see if there any things I could look into....

Cheers

Chunks
 
You said you followed the instructions; can you confirm that after flashing with 380.57, you reset the router to factory default settings and then manually inputted your personal sertings?

This is from Merlin's instructions for 380.57: "A factory default reset is required specifically for the RT-AC68U, due to the switch to a new SDK + wireless driver. Some people reported having issues with the 2.4 GHz band with this new SDK - if that's your case, the only solution at this time is to revert back to 378.56_2."

Coming from stock firmware to Merlin's firmware, you would, anyway, have had to carry out a restoration to factory default settings. However, in light of Merlin's note, you might want to consider having another go but this time with 378.56_2 followed by a reset to factory default settings and a manual input of your own settings afterwards.

See http://www.snbforums.com/threads/faq-nvram-and-factory-default-reset.22822/ for info on resetting to factory default settings.
 
Last edited:
You said you followed the instructions; can you confirm that after flashing with 380.57, you reset the router to factory default settings and then manually inputted your personal sertings?
Yes, I inputted everything manually after flash as I read you could not upload saved settings - I am not experiencing any wireless problems as far as I know.

Chunks
 
Just my two cents I have rt-ac68u with VDSL2 profile on my modem, I was experience disconnect as well. ISP upgraded their firmware on their modem and ultimately solving the problem.

Once that was done no more disconnect or any problems, It may very well be modem.
 
Hawk may well be right: Merlin posted the following just a few weeks ago:

"I always recommend separate modem and router. Modems tend to have a shorter life expectancy than routers, as people will either upgrade (i.e. going from ADSL2+ to VDSL2), or their modem start acting flakey after 3-4 years."


Did you read through this topic: http://www.snbforums.com/threads/is-this-a-bug-on-asus-firmware-wan-disconnections.8433/ ? It's useful if only to remind you not to overlook the simple things, like the interconnecting cable between the router and the modem.
 
Yes, I inputted everything manually after flash as I read you could not upload saved settings - I am not experiencing any wireless problems as far as I know.

Chunks
But did you reset the router to factory default settings after flashing and before setting up everything manually?
 
threepwood said:
But did you reset the router to factory default settings after flashing and before setting up everything manually?
Yes I did.

Thanks for linking the thread, martinr, I will look again at my cabling but I am fairly confident this is not the issue as I share the same general concerns for such details. I have renewed all my main network cabling with premium Cat6 cabling apart from the 'bridge' cable which is a high quality Cat 5E cable. I also have had my internal telephone wiring renewed, my phone socket replaced and my phone extensions disconnected and removed, I now have tried 3 different (new) modems all using different chipsets and really the only remaining common denominator is the RT-AC68U.

To this end, I have now removed my RT-AC68U from routing and WAN duties and I am now using my Zyxel VMG8324 (which I bought as a modem only) as a full modem-router, the AC68U is now an overpowered WAP !
If my connection is now significantly more stable I will fairly confident in saying that it was the RT-AC68U that was the cause, if not then I am really out of ideas at my end ....

Thanks fro your support and ideas,

Chunks
 
I thought I would tidy up this thread by closing it out with some findings. Since I changed my network around and removed my Asus RT-AC68U router from bridge duties my connection has been uninterrupted and I haven't seen a single disconnection. Whilst its interface is a bit slow the Zyxel VMG8324 has been doing a good job so far, the AC68U has been relegated to a WAP as it is clearly unreliable when bridged and carrying out WAN / PPPoE duties on my line.

Previously I was averaging around 3 drops / day, since making the changes my connection has been solid since 2016 Mar 10 14:43:15, at the time of writing this is almost 3 days.

I think this is conclusive proof that the AC68U was the cause of my disconnections and further research suggests I am not the only one who has had this issue, although it does appear to be a small proportion of users.

This is disappointing as I really like the AC68U, especially the interface, and I had made up my mind that separate modem and router was the way forward and was convinced the AC68U was the best choice.
My plan will now be to find a more reliable alternative router to bridge to my VMG8324, I won't need wireless as the AC68U will stay in that role as WAP - a role it does seem to be able to carry out reliably.

I appreciate there are no doubt many happy users of the RT-AC68U out there but some people might find this thread useful if they are encountering the same issues, I was kind of in denial and took a long time to reach a conclusion!

Thanks for the helpful suggestions.

Chunks
 
I also have noticed similar random disconnects on the PPP protocol. In my setup I have ADSL connection, a ZTE modem/router connected at RT-AC68U WAN port, acting as modem in bridge mode. The ASUS RT-AC68U is working as router holding the PPPoE username/password. Sometimes, the random disconnects happen every 2-3 minutes which is extremely annoying. In that case I simply reboot the router and the disconnects stop. In some other rare cases I needed to re-flash the router as the reboot didn't help. The DSL line seems to be pretty stable with no disconnects at the modem's log. I also never had such problems with previous Fritz modem/router and the line was 100% stable, so I can't blame the line quality for the disconnects.

When I flash the router I always reset to factory settings and then use John's tool to load my settings.

Here is an extract from the logs

Code:
May  7 16:12:13 pppd[506]: No response to 10 echo-requests
May  7 16:12:13 pppd[506]: Serial link appears to be disconnected.
May  7 16:12:13 pppd[506]: Connect time 16.6 minutes.
May  7 16:12:13 pppd[506]: Sent 25773271 bytes, received 1089025726 bytes.
May  7 16:12:13 miniupnpd[10391]: Failed to get IP for interface ppp0
May  7 16:12:13 miniupnpd[10391]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May  7 16:12:13 pppd[506]: Connection terminated.
May  7 16:12:14 pppd[506]: Sent PADT
May  7 16:12:14 dnsmasq[440]: read /etc/hosts - 5 addresses
May  7 16:12:14 dnsmasq[440]: read /etc/hosts.dnsmasq - 1 addresses
May  7 16:12:14 dnsmasq-dhcp[440]: read /etc/ethers - 1 addresses
May  7 16:12:14 dnsmasq[440]: using nameserver 192.168.2.1#53
May  7 16:12:15 WAN Connection: Fail to connect with some issues.
May  7 16:12:24 pppd[506]: PPP session is 62703 (0xf4ef)
May  7 16:12:24 pppd[506]: Connected to 50:87:89:30:f6:b3 via interface eth0
May  7 16:12:24 pppd[506]: Using interface ppp0
May  7 16:12:24 pppd[506]: Connect: ppp0 <--> eth0
May  7 16:12:24 pppd[506]: PAP authentication succeeded
May  7 16:12:24 pppd[506]: peer from calling number 50:87:89:30:F6:B3 authorized
May  7 16:12:24 miniupnpd[10391]: Failed to get IP for interface ppp0
May  7 16:12:24 miniupnpd[10391]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May  7 16:12:24 miniupnpd[10391]: Failed to get IP for interface ppp0
May  7 16:12:24 miniupnpd[10391]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May  7 16:12:24 miniupnpd[10391]: Failed to get IP for interface ppp0
May  7 16:12:24 miniupnpd[10391]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May  7 16:12:24 pppd[506]: local  IP address 79.130.171.227
May  7 16:12:24 pppd[506]: remote IP address 80.106.108.102
May  7 16:12:24 pppd[506]: primary   DNS address 212.205.212.205
May  7 16:12:24 pppd[506]: secondary DNS address 195.170.0.1
May  7 16:12:24 miniupnpd[10391]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
May  7 16:12:24 miniupnpd[10391]: Failed to get IP for interface ppp0
May  7 16:12:24 miniupnpd[10391]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May  7 16:12:24 rc_service: ip-up 12128:notify_rc start_firewall
May  7 16:12:24 dnsmasq[440]: read /etc/hosts - 5 addresses
May  7 16:12:24 dnsmasq[440]: read /etc/hosts.dnsmasq - 1 addresses
May  7 16:12:24 dnsmasq-dhcp[440]: read /etc/ethers - 1 addresses
May  7 16:12:24 dnsmasq[440]: using nameserver 212.205.212.205#53
May  7 16:12:24 dnsmasq[440]: using nameserver 195.170.0.1#53
May  7 16:12:25 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
May  7 16:12:26 wan: finish adding multi routes
May  7 16:12:26 rc_service: ip-up 12128:notify_rc stop_upnp
May  7 16:12:26 rc_service: waitting "start_firewall" via ip-up ...
May  7 16:12:27 rc_service: ip-up 12128:notify_rc start_upnp
May  7 16:12:27 rc_service: waitting "stop_upnp" via ip-up ...
May  7 16:12:27 miniupnpd[10391]: shutting down MiniUPnPd
May  7 16:12:28 miniupnpd[12169]: HTTP listening on port 50908
May  7 16:12:28 miniupnpd[12169]: Listening for NAT-PMP/PCP traffic on port 5351
May  7 16:12:28 ddns update: ez-ipupdate: starting...
May  7 16:12:28 ddns update: connected to dynupdate.no-ip.com (8.23.224.120) on port 80.
May  7 16:12:30 ddns update: request successful
May  7 16:12:30 ddns update: asusddns_update: 0
May  7 16:12:30 WAN Connection: WAN was restored.
May  7 16:12:30 ddns: ddns update ok
May  7 16:12:31 rc_service: ip-up 12128:notify_rc stop_vpnserver1
May  7 16:12:31 rc_service: ip-up 12128:notify_rc start_vpnserver1
May  7 16:12:31 rc_service: waitting "stop_vpnserver1" via ip-up ...
May  7 16:12:32 openvpn[10560]: event_wait : Interrupted system call (code=4)
May  7 16:12:32 openvpn[10560]: Closing TUN/TAP interface
May  7 16:12:32 openvpn[10560]: /usr/sbin/ip addr del dev tun21 10.8.0.1/24
May  7 16:12:32 openvpn[10560]: SIGTERM[hard,] received, process exiting
May  7 16:12:34 kernel: tun: Universal TUN/TAP device driver, 1.6
May  7 16:12:34 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
May  7 16:12:35 openvpn-routing: Refreshing policy rules for client 1
May  7 16:12:35 openvpn-routing: Allow WAN access to all VPN clients
May  7 16:12:35 openvpn-routing: Refreshing policy rules for client 2
May  7 16:12:35 openvpn-routing: Allow WAN access to all VPN clients
May  7 16:12:35 openvpn-routing: Refreshing policy rules for client 3
May  7 16:12:35 openvpn-routing: Allow WAN access to all VPN clients
May  7 16:12:36 openvpn-routing: Refreshing policy rules for client 4
May  7 16:12:36 openvpn-routing: Allow WAN access to all VPN clients
May  7 16:12:36 openvpn-routing: Refreshing policy rules for client 5
May  7 16:12:36 openvpn-routing: Allow WAN access to all VPN clients
May  7 16:12:36 kernel: ADDRCONF(NETDEV_UP): tun21: link is not ready
May  7 16:12:36 kernel: device tun21 entered promiscuous mode
May  7 16:12:37 openvpn[12339]: OpenVPN 2.3.10 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Mar 20 2016
May  7 16:12:37 openvpn[12339]: library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
May  7 16:12:37 openvpn[12340]: Diffie-Hellman initialized with 2048 bit key
May  7 16:12:37 openvpn[12340]: Socket Buffers: R=[122880->122880] S=[122880->122880]
May  7 16:12:37 openvpn[12340]: TUN/TAP device tun21 opened
May  7 16:12:37 openvpn[12340]: TUN/TAP TX queue length set to 100
May  7 16:12:37 openvpn[12340]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
May  7 16:12:37 openvpn[12340]: /usr/sbin/ip link set dev tun21 up mtu 1500
May  7 16:12:37 kernel: ADDRCONF(NETDEV_CHANGE): tun21: link becomes ready
May  7 16:12:37 openvpn[12340]: /usr/sbin/ip addr add dev tun21 10.8.0.1/24 broadcast 10.8.0.255
May  7 16:12:37 openvpn[12340]: UDPv4 link local (bound): [undef]
May  7 16:12:37 openvpn[12340]: UDPv4 link remote: [undef]
May  7 16:12:37 openvpn[12340]: MULTI: multi_init called, r=256 v=256
May  7 16:12:37 openvpn[12340]: IFCONFIG POOL: base=10.8.0.2 size=252, ipv6=0
May  7 16:12:37 openvpn[12340]: Initialization Sequence Completed
May  7 16:12:40 rc_service: ip-up 12128:notify_rc start_firewall
May  7 16:12:41 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
May  7 16:14:24 pppd[506]: No response to 10 echo-requests
May  7 16:14:24 pppd[506]: Serial link appears to be disconnected.
May  7 16:14:24 pppd[506]: Connect time 2.0 minutes.
May  7 16:14:24 pppd[506]: Sent 3506682 bytes, received 83901681 bytes.
May  7 16:14:24 miniupnpd[12169]: Failed to get IP for interface ppp0
May  7 16:14:24 miniupnpd[12169]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
May  7 16:14:24 pppd[506]: Connection terminated.

And as you can see, connection was terminated 16:12 and after two minutes again at 16:14.
Very strange
 
I also have noticed similar random disconnects on the PPP protocol. .. snip....

And as you can see, connection was terminated 16:12 and after two minutes again at 16:14.
Very strange

Looks very similar to mine, I just use my AC68U as a WAP now, I reluctantly switched to using my Zyxel VMG8324 as my main router (I bought it as a bridge modem) - and I don't see any disconnects of this type any more.

I spent a lot of time and money changing other stuff and talking to my ISP before I narrowed it down to my AC68U - I guess I had a lot of faith in it :rolleyes:

I guess you could do the same and configure your ZTE device temporarily as your router to see if the problems persist?

Chunks
 
Other people had same issues, check UTP cable between asus and you dsl modem, it has to be cat6 because of gigabit wan interface on asus
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top