What's new

[Release] Asuswrt-Merlin 380.64_2 is now available

  • 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!

Status
Not open for further replies.
HI . I have a constant problem. my ppoe connection disconnect randomly and then riconnect.. provider problem or configuration/firmware problem? thanks

How are you connecting to the internet?

What modem?

What router?

What firmware and version ?

When did this problem start ?
 
Last edited:
excuse me...

How are you connecting to the internet?

What modem?
I LIVE IN ITALY. I HAVE EOLO PROVIDER.. IT S A DEDICATED MODEM. IT HAS ONLY POWER SUPPLY WAN IN (FROM THE RADIO ) WAN OUT TO ASUS

What router?
RT AC 87 U

What firmware and version ?
380.64 - ASUSWRT MERLIN


When did this problem start ?
THE PROBLEM STARTED A MONTH AGO ... I ALWAYS INSTALLED LAST UPDATE FIRMWARE FROM MERLIN

THANKS FOR HELP!
 
THIS IS THE LOG FILE:
I HAVE ONLY TO VERIFY IF IT S A ROUTER PROBLER OR A PROVIDER PROBLEM....
i ve contacted my provider and they said that the radio was always up and have disconnection
from router.....

Dec 18 06:13:52 pppd[513]: Serial link appears to be disconnected.
Dec 18 06:13:52 miniupnpd[2785]: Failed to get IP for interface ppp0
Dec 18 06:13:52 miniupnpd[2785]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Dec 18 06:13:53 WAN Connection: Fail to connect with some issues.
Dec 18 06:13:58 pppd[513]: Connection terminated.
Dec 18 06:13:58 pppd[513]: Modem hangup
Dec 18 06:14:44 pppd[513]: Timeout waiting for PADO packets
Dec 18 06:15:59 pppd[513]: Timeout waiting for PADO packets
Dec 18 06:16:34 pppd[513]: Connected to XX:XX::XX::XX::XX via interface eth0
Dec 18 06:16:34 pppd[513]: Connect: ppp0 <--> eth0
Dec 18 06:16:34 pppd[513]: PAP authentication succeeded
Dec 18 06:16:34 pppd[513]: peer from calling number XX:XX::XX::XX::XX authorized
Dec 18 06:16:37 miniupnpd[2785]: Failed to get IP for interface ppp0
Dec 18 06:16:37 miniupnpd[2785]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Dec 18 06:16:37 miniupnpd[2785]: Failed to get IP for interface ppp0
Dec 18 06:16:37 miniupnpd[2785]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Dec 18 06:16:37 miniupnpd[2785]: Failed to get IP for interface ppp0
Dec 18 06:16:37 miniupnpd[2785]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Dec 18 06:16:37 pppd[513]: local IP address XX..XX..XX..XX
Dec 18 06:16:37 pppd[513]: remote IP address XX..XX..XX..XX
Dec 18 06:16:37 pppd[513]: primary DNS address XX..XX..XX..XX
Dec 18 06:16:37 pppd[513]: secondary DNS address XX..XX..XX..XX
Dec 18 06:16:37 miniupnpd[2785]: ioctl(s, SIOCGIFADDR, ...): Cannot assign requested address
Dec 18 06:16:37 miniupnpd[2785]: Failed to get IP for interface ppp0
Dec 18 06:16:37 miniupnpd[2785]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Dec 18 06:16:37 rc_service: ip-up 16137:notify_rc start_firewall
Dec 18 06:16:37 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Dec 18 06:16:38 wan: finish adding multi routes
Dec 18 06:16:38 rc_service: ip-up 16137:notify_rc stop_upnp
Dec 18 06:16:38 rc_service: waitting "start_firewall" via ip-up ...
Dec 18 06:16:38 WAN Connection: WAN was restored.
Dec 18 06:16:39 rc_service: ip-up 16137:notify_rc start_upnp
Dec 18 06:16:39 rc_service: waitting "stop_upnp" via ip-up ...
Dec 18 06:16:39 miniupnpd[2785]: shutting down MiniUPnPd
Dec 18 06:16:40 miniupnpd[16178]: HTTP listening on port 48589
Dec 18 06:16:40 miniupnpd[16178]: Listening for NAT-PMP/PCP traffic on port 5351
Dec 18 06:16:44 rc_service: ip-up 16137:notify_rc start_firewall
Dec 18 06:16:45 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Dec 18 07:28:05 pppd[513]: Serial link appears to be disconnected.
Dec 18 07:28:05 miniupnpd[16178]: Failed to get IP for interface ppp0
 
I HAVE ONLY TO VERIFY IF IT S A ROUTER PROBLER OR A PROVIDER PROBLEM....
i ve contacted my provider and they said that the radio was always up and have disconnection
from router.....


A forum search for 'Serial link appears to be disconnected' shows several hits

e.g. Both @RMerlin/@john9527 etc. provide possible actions you can try in order to investigate/resolve the (PPoE) issue


http://www.snbforums.com/threads/wan-terminated-issue-with-merlin-378-55.28179/#post-218070


http://www.snbforums.com/threads/rt-n66-378-56_2-merlin-wan-link-seem-to-fail.28685/#post-222190

even an apparently very,very obscure cause? (which seems very implausible to me):

http://www.snbforums.com/threads/lost-internet-connection.30871/#post-266673

....so personally I wouldn't advise disabling the firewall for the sake of a stable connection.
 
That's all very interesting, and I see you've got a complicated script that'll fix things/clean up routes when switching client configs (and I knew I could manually switch the status to "2" for the vpn client from the command line to show that it's up...) but the fact that adding a single "route" statement to the custom config section, with no other extra scripting generating routes, causes a vpn client to get into this supposed "error" state seems broken to me.

If I remove the route line, stop the client and start it... status is clear/up... if I add the route line, stop the client and start it, the error state is back.

I shouldn't need an extra script in order to fix things up for a simple config.
 
I shouldn't need an extra script in order to fix things up for a simple config.

Agreed, in an ideal world there should be no need for 'home-grown' workarounds (complicated or not) to correct perceived 'flawed' code - but this is the reason I prefer Rmerlin's end-user customisable firmware.

Clearly this cosmetic OpenVPN Asus specific annoyance has already been reported and has unfortunately been around for a long time, so if it isn't deemed worthy of RMerlin's time to address then that is his prerogative.

I doubt RMerlin could possibly predict the consequences of every VPN Client custom directive added manually or pushed by the various VPN servers.
However, as it is your decision to include the VPN client custom directive that causes the minor issue, then wouldn't you agree that surely it isn't unreasonable for you to assume responsibility and also include the appropriate one line script in the custom configuration to 'fix' the cosmetic NVRAM/GUI issue?

Alternatively you could compile your own firmware since you are under no obligation to use @RMerlin's firmware, which is provided for free.

Caveat Emptor.
 
Last edited:
uhhh....I have it enabled in my fork. I was trying out some scripts one time and enabled it.
I just did a git diff on Busybox's config file going all the way back to October 2015, and xargs was never enabled throughout that. In October 2016 I enabled modutils's alias support. Previous change to that config file was in March 2016, an Asus GPL merge removed an obsolete option related to DHCP. You can check the commit log on busybox/config_base for yourself on Github.
I dunno maybe a stray configuration because I'm pretty sure have used that on 380.63_2 fine. In any case, it doesn't matter now, I switched to using tr with variable expansion in my script.
 
That's all very interesting, and I see you've got a complicated script that'll fix things/clean up routes when switching client configs (and I knew I could manually switch the status to "2" for the vpn client from the command line to show that it's up...) but the fact that adding a single "route" statement to the custom config section, with no other extra scripting generating routes, causes a vpn client to get into this supposed "error" state seems broken to me.

If I remove the route line, stop the client and start it... status is clear/up... if I add the route line, stop the client and start it, the error state is back.

I shouldn't need an extra script in order to fix things up for a simple config.
Does it also happen on a fresh boot or only when you stop/restart the client?
 
ok if i disable nat doesent start internet. so disable qos and upnp.. now i will monitoring
 
The update left all my hosts without Internet connection. Only the router can reach Internet.
I had to disable Dual WAN to restore it.
Now I'll try to enable it again and, in case it doesn't work, I'll have to restore factory settings.
Unfortunatelly, it's not the first time that an upgrade does that.
 
Does it also happen on a fresh boot or only when you stop/restart the client?
Just rebooted, and the problem doesn't happen on a fresh boot, but simply "apply" the config (no need to change it) and it'll report errors and leave the vpn client status as "Error connecting - IP/Routing conflict"
 
You are not using RMerlin FW, but a fork from someone else.

Download it from http://asuswrt.lostrealm.ca/download

1. NTP Server?
2. Only 1 SSID available on RT-AC3200?
3. 380.64 showing instead 380.64_0?

Definitely not RMerlin FW, take a look at checksum:

4eb45deb03ef98fa9ec360400d2566bb46aa2af17cbc5b80677ad190c0f1a562 RT-AC3200_380.64_0.trx

Definitely is RMerlin FW, I always download Asuswrt-Merlin from his website, and the hashes match. :)

upload_2016-12-18_8-6-20.png


(1) NTP Daemon is a "scab-on" to the html ~ http://www.snbforums.com/threads/ntp-daemon-for-asuswrt-merlin.28041/ ~ it doesn't affect the firmware
(2) Yep, you only have one SSID when you turn on Tri-Band Smart Connect; it automagically hops connections to the "best" band for that device (do NOT ask me how THAT works, but it works very well in my experience).
(3) That part I admit is weird ... I'll factory reset.

I do appreciate the thoughts though.
 

Attachments

  • upload_2016-12-18_8-3-28.png
    upload_2016-12-18_8-3-28.png
    40.4 KB · Views: 603
You are missing other panes from that window. Signature version check is not there.
Also the firmware version is shown as 380.64_0 on my AC3200 in 4 browsers the number is 380.64.

Looks like it is time to do a reset.

Okay, so after factory reset, I now have all the right buttons for checking for firmware, AND apparently some other changes that have happened along the way (the ones I noticed were cosmetic, perhaps there's others), and it shows the 380.64 in the firmware version box. Guess I got lucky in not having to do factory resets through a lot of upgrades, and so I was reluctant to believe that was the problem here. Lesson learned. :)
 
About busybox and Asuswrt:
As I remember porting busybox to Asuswrt was very (surprisingly!) easy. Actually, no real "porting" was required. I just download the latest source tarball busybox.tar.bz2 (I used the latest dev version), unpack it and that's it - it was ready to be compiled. Actually, there were some minor changes, but they were really very small and trivial.

No, it's more complicated than this, because Asus has various customizations on top of Busybox. Also, newer versions of Busybox break various scripts Asus uses to install Download Master, you have to do some changes to the awk applet code.

Look at the whole list of patches involved in upgrading to 1.25.1:

https://github.com/RMerl/asuswrt-merlin/pull/1146
 
I dunno maybe a stray configuration because I'm pretty sure have used that on 380.63_2 fine. In any case, it doesn't matter now, I switched to using tr with variable expansion in my script.

I'm open to adding the xargs applet, it shouldn't take much space, and since people are starting to heavily script things out, it might not be a bad idea.
 
Factory reset didn't help.
This firmware has serious issues. It won't work with Dual WAN.
I'm back to 380.63 until it's fixed.
 
ok if i disable nat doesent start internet. so disable qos and upnp.. now i will monitoring


after this test during evening i have this result:


Dec 18 19:20:57 pppd[16599]: Serial link appears to be disconnected.
Dec 18 19:20:58 WAN Connection: Fail to connect with some issues.
Dec 18 19:21:03 pppd[16599]: Connection terminated.
Dec 18 19:21:03 pppd[16599]: Modem hangup
Dec 18 19:21:48 pppd[16599]: Timeout waiting for PADO packets
Dec 18 19:21:48 pppd[16599]: Connected to via interface eth0
Dec 18 19:21:48 pppd[16599]: Connect: ppp0 <--> eth0
Dec 18 19:21:48 pppd[16599]: PAP authentication succeeded
Dec 18 19:21:48 pppd[16599]: peer from calling number authorized
Dec 18 19:21:48 pppd[16599]: local IP address
Dec 18 19:21:48 pppd[16599]: remote IP address
Dec 18 19:21:48 pppd[16599]: primary DNS address
Dec 18 19:21:48 pppd[16599]: secondary DNS address
Dec 18 19:21:49 rc_service: ip-up 24464:notify_rc start_firewall
Dec 18 19:21:49 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Dec 18 19:21:49 wan: finish adding multi routes
Dec 18 19:21:49 rc_service: ip-up 24464:notify_rc stop_upnp
Dec 18 19:21:49 rc_service: waitting "start_firewall" via ip-up ...
Dec 18 19:21:50 rc_service: ip-up 24464:notify_rc start_upnp
Dec 18 19:21:50 rc_service: waitting "stop_upnp" via ip-up ...
Dec 18 19:21:53 WAN Connection: WAN was restored.
Dec 18 19:21:55 rc_service: ip-up 24464:notify_rc start_firewall
Dec 18 19:21:56 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Dec 18 20:30:26 pppd[16599]: Serial link appears to be disconnected.
Dec 18 20:30:31 WAN Connection: Fail to connect with some issues.
Dec 18 20:30:32 pppd[16599]: Connection terminated.
Dec 18 20:30:32 pppd[16599]: Modem hangup
Dec 18 20:31:17 pppd[16599]: Timeout waiting for PADO packets
Dec 18 20:32:33 pppd[16599]: Timeout waiting for PADO packets
Dec 18 20:32:33 pppd[16599]: Connected to via interface eth0
Dec 18 20:32:33 pppd[16599]: Connect: ppp0 <--> eth0
Dec 18 20:32:33 pppd[16599]: PAP authentication succeeded
Dec 18 20:32:33 pppd[16599]: peer from calling number authorized
Dec 18 20:32:33 pppd[16599]: local IP address
Dec 18 20:32:33 pppd[16599]: remote IP address
Dec 18 20:32:33 pppd[16599]: primary DNS address
Dec 18 20:32:33 pppd[16599]: secondary DNS address
Dec 18 20:32:33 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Dec 18 20:32:33 wan: finish adding multi routes
Dec 18 20:32:33 rc_service: ip-up 30926:notify_rc stop_upnp
Dec 18 20:32:33 rc_service: waitting "start_firewall" via ip-up ...
Dec 18 20:32:34 rc_service: ip-up 30926:notify_rc start_upnp
Dec 18 20:32:34 rc_service: waitting "stop_upnp" via ip-up ...
Dec 18 20:32:36 WAN Connection: WAN was restored.
Dec 18 20:32:39 rc_service: ip-up 30926:notify_rc start_firewall
Dec 18 20:32:40 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
 
Thank you Merlin.

Updated my AC88U from .380.63.2 no issues. The GUI seems much faster too.
 
Status
Not open for further replies.

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