What's new

WPS not working stuck on 'Connection Status: Idle'

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

Magpul_

New Around Here
Hello,

I was wondering if anyone else is not able to use WPS on RT-AC68U 386.3_2

I've tried both Button and PIN neither work, Connection Status never changes from Idle connection status.

Code:
rc_service: httpd 666:notify_rc start_wps_method

This is all i see in the logs.
 
I have exactly the same problem. I just changed the wifi key and wanted to connect my Huawei phone again. I have also tried all the combinations I can find (buttons and pins - rebooted several times).

On my phone several networks display as: 'Network name' (WPS is available)
However for my network it just says 'Network name', so WPS is not available from the router.
I know I have done this before (my router is more than 5 years old and my phone several years, and I have changed the key before using WPS).
So it's an issue that has come in one of the later firmwares.

Has anyone got a solution? How to make WPS work with the newest firmware?
 
Greetings,

I know this is an old thread, but I wanted to share my experience because it might be helpful. I didn't notice if you all are running Asus-supplied firmware or the alternative Merlin firmware, but regardless, I noticed that WPS stopped working properly at some point in the past year or so.

I am currently running two ASUS RT-AC68U routers configured in a mesh configuration. Both routes are running Merlin firmware version 386_5_2.

I spent all morning fighting with my Miele washer and dryer to get them to work with my Android 12 smartphone that recently was forced a system update that trashed my device so badly that I had to factory reset it and now it won't allow me restore from any backups. Suffice it to say I am quickly beginning to hate technology. But back to the WPS issue.

The last time I used WPS a little over a year ago and it was to bring my Miele washer and dryer online using the push button method. I noticed when I tried to activate this method from my web browser, WPS status never deviated from Idle. After checking my configuration a million times, I decided to revert back to an older firmware, one from a year ago old plus a few months because when I tried this last year, it worked and I remember behind behind on my updates.

Much to my surprise, Merlin firmware 386_1_2 applied directly to my main RT-AC68U router, with no changes to any configurable options, etc., worked like a charm. No factory reset necessary, just installed it, let it reboot itself then I hit the push button activation from the router's web page and the status immediately changed from Idle to something else that made me think it was working. Within 10 seconds, my washing machine successfully connected to my network and then I repeated the process and my clothes dryer successfully connected.

Once I was convinced that my Miele smartphone app had properly established communication with my washer and dryer, I restored the 386_5_2 firmware. Everything continues to work as expected.

For grins I tried to start WPS pushbutton again and it is most definitely broken in the current firmware. I don't know which version it stopped functioning, but at least I was able to identify that WPS still works in 386_1_2.

I hope this helps someone and prevents wasting a whole morning like I just did.
 
… few months later, hit exactly the same problem, running Merlin 386.7_2. 2 days wasted trying to troubleshoot both the printer and router, including multiple full resets and reconfigurations. I‘m surprised basic functionality like WPS has been broken for months, yet this is the only post I came across when googling. Is WPS so unpopular?
 
WPS is a security risk and has been for a very long time. Recommended to immediately disable it after you have set up your system (and AiMesh nodes too).
 
Thanks, @pqcracker for your great input.

It would have been good to mention that WPS has been broken with the corresponding software version in the changelog. The latest release for RT-AC68U with WPS working is 386.2.4 (might be helpful for diagnosis). This would have saved a lot of time for many folks trying to connect interface-less devices.
 
Last edited:
In fact such a report is meaningless because RMerlin can't do anything about any bugs with wifi, it is closed source and can only be fixed by Asus. Helpful advice is to install the latest Asuswrt stock firmware and if the error is the same then report it to Asus.
Are you certain this WPS problem is a "bug with wifi" and not an issue in Merlin?

The following report seems to indicate that WPS is working on stock ASUS firmware: https://www.snbforums.com/threads/wps-not-working-on-rt-ac88u.77241/

Additionally, WPS has been broken in Merlin before on certain router models due to a missing makefile as seen in this thread fixed by the following commit: https://github.com/RMerl/asuswrt-merlin/commit/6214cc8b79da666766e312b5507a13ed9b1b7fa3

If more evidence is needed that this might be a bug in Merlin I can flash back to stock Asus firmware and test this personally. However, based on the available information it seems at least possible that this is a legitimate fixable problem in Merlin rather than an issue upstream in the Asus codebase.
 
Are you certain this WPS problem is a "bug with wifi" and not an issue in Merlin?

The following report seems to indicate that WPS is working on stock ASUS firmware: https://www.snbforums.com/threads/wps-not-working-on-rt-ac88u.77241/

Additionally, WPS has been broken in Merlin before on certain router models due to a missing makefile as seen in this thread fixed by the following commit: https://github.com/RMerl/asuswrt-merlin/commit/6214cc8b79da666766e312b5507a13ed9b1b7fa3

If more evidence is needed that this might be a bug in Merlin I can flash back to stock Asus firmware and test this personally. However, based on the available information it seems at least possible that this is a legitimate fixable problem in Merlin rather than an issue upstream in the Asus codebase.
If you report this issue, I'm afraid you'll have to prove it because RMerlin is only one person and has a lot of work to do and can't focus on everything.

You have to test its behavior on stock firmware and provide detailed steps to reproduce if there are differences.

You will also need to prove that this is not an issue caused by your IoT device.

I hope you can prove that you are right and provide a problem report that will be helpful to developers.

Good luck.
 
I don't know what to add to this except WPS has previously worked for me (no idea what version, I very rarely ever use it), and I only noticed it wasn't working because I happened to need it to connect my PS Vita because my wifi passwords are like 20 characters long generated and typing that in on a touchscreen is painful.

Anyway hopefully it'll work again in the next release.
 
I found some more time to dig into this and I believe I've now done enough legwork to confirm that this is a legitimate bug in merlin. I installed the latest stock Asus firmware on my router from here and confirmed that WPS is indeed working. I then upgraded to the latest merlin firmware and found that WPS is not working.

Based on my experiments, the WPS process can be triggered via the command line by running service wps_start_method. On firmware revisions where WPS works, this command then sets the wps_proc_status and wps_proc_status_x variables in nvram to 1 and kicks-off the WPS connection process. On the latest Merlin firmware wps_proc_status_x and wps_proc_status remain 0 after invoking service wps_start_method.

Code:
admin@RT-AC86U-7028:/var/run# service start_wps_method

Done.
admin@RT-AC86U-7028:/var/run# nvram show | grep wps_pro
wps_proc_status=0
wps_proc_status_x=0

I took a look at the source code on github to try to track down the bug. I believe start_wps_method is defined in wps-broadcom.c here. There is a section which stubs out these methods if the RTCONFIG_WPS macro is not defined here. However, it looks like the macro is set to "y" during compilation in config_base here so I don't think that's what's going on.

I tried to read through the function to see if there might be a lower-level call to trigger WPS that I could run manually (to verify that the bug is in fact in the start_wps_method function and not in lower level code) but couldn't find one. Based on my understanding, the code that actually does the work is in set_wps_env which is called by start_wps_method here. It looks like set_wps_env opens a socket and sends the wps command to it which seems a little difficult to do on the command line.

At this point, it would probably be more productive to have someone familiar with the codebase investigate. It looks like issues are disabled on the github repo so I'm not sure where to file a bug. I'll add another comment on the main release thread in addition to this comment here. Hopefully, one of them will garner enough attention to get this looked at.
 
Yes, very good work.

To clarify, after flashing RMerlin firmware, was a full reset performed on the router via the method recommended for that specific model, (see below).


If it was, have you tried multiple resets and re-flashing the RMerlin firmware as suggested in the link below? This has brought many routers, including RT-AC86Us, to a stable good/known state.

Nuclear Reset https://www.snbforums.com/threads/major-issues-w-rt-ac86u.56342/page-4#post-495710


I have not run into this issue with any RT-AC86U, for the record. And all are running RMerlin firmware.
 
I haven't needed to perform a full reset because of the somewhat unique nature of the issue. More specifically, since the issue affects WPS and WPS is only needed briefly when connecting a new device to the network, flashing to a firmware with working WPS, connecting the new device, then flashing back to current firmware is a viable albeit inconvenient workaround.

Given the behavior documented in my comment above, I suspect the problem can be narrowed down to the start_wps_method in the /sbin/rc binary. During my experiments, I actually tried copying the rc binary from the stock asus firmware onto the latest merlin firmware to see if that would be enough to get WPS working; unfortunately (and unsurprisingly), it seg-faulted. @L&LD if you have an RT-AC86U running merlin 386.12 that does not exhibit this WPS issue it might be helpful if I could test your /sbin/rc file on my router. If you can scp it off your router and attach it to a comment that might help shed some light on why some of us are experiencing the issue while you are not.
 
If your testing does not include a full reset (and the more hardcore Nuclear Reset, if needed/indicated), I don't believe your testing and conclusions are complete.

The potential interactions between stock Asus and RMerlin firmware are effectively infinite, given each network environment possible, not to mention code, variable(s), and other firmware/GUI differences.

Not doing a full reset or more, is not accounting for the easily accounted for interactions, as indicated above. And hardly gives Asus or RMerlin an incentive to further troubleshoot this issue.
 
Happy to do a full reset when I can take my network down again without impacting anyone if that is truly required.

Given the evidence I've gathered thus far along with the reports from other users experiencing the problem, I hope that RMerlin would be willing to run service start_wps_method and check the wps_proc_status* variables in nvram to see if they are able to corroborate my findings since doing so would only take a minute (commands copied below for convenience).
Code:
admin@RT-AC86U-7028:/var/run# service start_wps_method

Done.
admin@RT-AC86U-7028:/var/run# nvram show | grep wps_proc
wps_proc_status=0
wps_proc_status_x=0
Given that the wps_start_method behaves as expected after downgrading to 386.2.4 without doing a full reset (or making any changes to the router settings at all for that matter) it's difficult to come up with rationale which could explain why doing a reset should impact the behavior of this function. I understand that a full reset would set nvram back to default but since the function works on 386.2.4 and on the latest Asus firmware with no change to my current nvram settings it seems logical to conclude that the current settings should also work on 386.12.

As mentioned in my previous post, it would also be great to try your working /sbin/rc binary since I can easily slide it into place without affecting the network.
 

Similar threads

Sign Up For SNBForums Daily Digest

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