What's new

Internet Status: Disconnected?

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

I started getting this as well since updating to .14. I had done a nuclear reset with .13 prior and was running solid. I've had to restart my router several times now since .14. I have nothing checked on in Network Monitoring (never have)

Same here.
 
Same here.
On my rt-ac68u, the problem appears to be that wanduck isn't getting kicked off when using firmware newer than 384.13.

If I ssh in and manually start up wanduck, then the internet status immediately shows that it's connected.
 
On my rt-ac68u, the problem appears to be that wanduck isn't getting kicked off when using firmware newer than 384.13.

I wonder how something like that gets changes between builds? Typo? Compatibility with some other change?
 
I have the same error since I made .14 update. Internet is fine but RT-AC88U indicate disconnected.
Interested by any solution.

I just registered to mention that I also am having this error as of the .14 update for the RT-AC68U. Internet is normal, but the Network Map shows Internet status: Disconnected. I attempted the suggestions in this thread and in a few others on this forum to no avail. As you can see, when hovering over Internet Status, Ethernet WAN - Connected is shown. If memory serves, this issue has sporadically appeared for me in the past, but I don't know what causes or rectifies it. Thanks in advance for any help.
 

Attachments

  • Asus_Merlin_2019-12-27.png
    Asus_Merlin_2019-12-27.png
    300.6 KB · Views: 743
I just registered to mention that I also am having this error as of the .14 update for the RT-AC68U. Internet is normal, but the Network Map shows Internet status: Disconnected. I attempted the suggestions in this thread and in a few others on this forum to no avail. As you can see, when hovering over Internet Status, Ethernet WAN - Connected is shown. If memory serves, this issue has sporadically appeared for me in the past, but I don't know what causes or rectifies it. Thanks in advance for any help.

I have exactly the same issue! Everything seem to work as it should except the status on the network map.
 
I found this earlier in the topic. Start wanduck with the command "wanduck &" in a SSH session to the router. I use putty for my ssh sessions. Hopefully @merlin can debug this fairly quickly.
 
ASUSWRT-Merlin RT-AC68U 384.15_alpha1-wd-g7be95e7bd9 Sun Dec 29 05:49:34 UTC 2019
1admin_AS@RT-AC68U-EDF0:/tmp/home/root# ps -T | grep wanduck
1admin_AS@RT-AC68U-EDF0:/tmp/home/root# cat /tmp/syslog.log | grep wanduck
May 5 01:05:06 wanduck: Starting wanduck
May 5 01:05:06 wanduck: ate factory mode - 1
1admin_AS@RT-AC68U-EDF0:

Looks like date changed in the log when I loaded the new .trx and then the router got ntpd running so the correct date/time was set during the end of the initialization. wanduck started but did not keep running per the syslog and ps.
 
Last edited:
1admin_AS@RT-AC68U-EDF0:/tmp/home/root# cat /tmp/syslog.log | grep wanduck
May 5 01:05:06 wanduck: Starting wanduck
May 5 01:05:06 wanduck: ate factory mode - 1
1admin_AS@RT-AC68U-EDF0:

This matches another user - for some reason the bootloader has a flag set to factory/debug mode, causing wanduck to get skipped. I don't know the details of that check, it's part of closed source code.

I will have to remove that check, hoping it doesn't do anything but check for this, and that it would hopefully only affect manufacturing mode and not regular production/retail products.

Looks like date changed in the log when I loaded the new .trx and then the router got ntpd running so the correct date/time was set during the end of the initialization.

This is normal, routers have no battery-backed up clocks, so they have to rely on ntp to set up the clock at boot time.

wanduck started

It did not. According to the log entries, the start_wanduck() function exited early because it believed the router was in manufacturing/debug mode.
 
I know my ac68u has a modified cfe. Could that be a reason a debug mode got enabled somewhere?
 
PS mine:

ASUSWRT-Merlin RT-AC68U 384.15_alpha1-wd-g7be95e7bd9 Sun Dec 29 05:49:34 UTC 2019
admin@RT-AC68U-0A50:/tmp/home/root# cat /tmp/syslog.log | grep wanduck
May 5 14:35:06 wanduck: Starting wanduck
May 5 14:35:06 wanduck: ate factory mode - 1
 
This matches another user - for some reason the bootloader has a flag set to factory/debug mode, causing wanduck to get skipped. I don't know the details of that check, it's part of closed source code.

I will have to remove that check, hoping it doesn't do anything but check for this, and that it would hopefully only affect manufacturing mode and not regular production/retail products.
Since wanduck is able to start manually using "wanduck &" taking out the check should be fine.
 
This matches another user - for some reason the bootloader has a flag set to factory/debug mode, causing wanduck to get skipped. I don't know the details of that check, it's part of closed source code.

I will have to remove that check, hoping it doesn't do anything but check for this, and that it would hopefully only affect manufacturing mode and not regular production/retail products.
It is strange that some bootloaders have ATEMODE=1 and some ATEMODE=0... in fact all the cfe binary files shipped in the GPL bundle for the ac68u variants contain ATEMODE=1 which is what triggers the problem currently.

Hacking the bootloader so it sets ATEMODE=0 instead also fixes the problem.
 
Official. Mods are for clock speeds and region.

Depends how you modded it I suppose. If you edited the current CFE then I doubt it's related. If however you flashed some CFE downloaded over the Internet, then who knows how that CFE was set.

It is strange that some bootloaders have ATEMODE=1 and some ATEMODE=0... in fact all the cfe binary files shipped in the GPL bundle for the ac68u variants contain ATEMODE=1 which is what triggers the problem currently.

I don't have any information as to atemode itself, but I may have a few theories as to why some people may have it set to 1:

- Possible bug with the CFE upgrade done by the firmware for the RT-AC68U
- People flashing a CFE obtained from some random website
- Perhaps Asus accidentally shipped a few batches with atemode left to 1
- Maybe a specific piece of code in the firmware is supposed to clear that flag on a certain situation, and that code isn't doing it as expected

Only someone from Asus would know since everything surrounding atemode is considered proprietary and confidential.
 
My cfe I think came from the cfe thread that was here. I did this all many years ago so I have long forgotten the exact steps that got me to here.
I think it was memory overclocked and then I modded it's region with a hex editor.

I'm pretty sure that modded cfe later got updated by an official Asus update at some point also. The memory clock and region survived that update.

I have made no further changes to the cfe for many years and it has never previously caused any dramas. And it appears the only current issue is the .14 saying it is disconnected.

My device is an rt-ac68u stickered as an A1 and came with firmware 3.0.0.4.374. I think I bought it in maybe 2014 and modded the cfe back in 2014.
 

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