[Release 384/NG] Asuswrt-Merlin 384.4 is now available

[SwampKracker]

I also have an RT-AC68U that I run as transparent AP. I connect to the WebUI only with HTTPS on port 8443. What changed for me from .3 to .4 is that I no longer, no way can connect to WebUI with Firefox 59.x as I reported in https://www.snbforums.com/threads/r...4-4-is-now-available.45406/page-2#post-389741
I have after reporting done full factory reset and manual reconfiguration and full power cycling to ensure that no old settings are the culprit. No difference with Firefox 59.x. That one doesn't work.

However. I can connect just fine to WebUI with Chromium and Google Chrome. So what you should do is try another browser. (And remember to clear the browsers cached content with F5 or Shift+F5, depending on the browser.)

I have upgraded two RT-AC68U routers to 384.4 and manage both via HTTPS with Firefox 59.X. Sounds like there might be a certificate issue with your browser.

 

[Stephen Harrington]

I also have an RT-AC68U that I run as transparent AP. I connect to the WebUI only with HTTPS on port 8443. What changed for me from .3 to .4 is that I no longer, no way can connect to WebUI with Firefox 59.x as I reported in https://www.snbforums.com/threads/r...4-4-is-now-available.45406/page-2#post-389741
I have after reporting done full factory reset and manual reconfiguration and full power cycling to ensure that no old settings are the culprit. No difference with Firefox 59.x. That one doesn't work.

However. I can connect just fine to WebUI with Chromium and Google Chrome. So what you should do is try another browser. (And remember to clear the browsers cached content with F5 or Shift+F5, depending on the browser.)

Likewise I'm not seeing that behaviour at all ...
I just tried in on my AC68U with a fresh 384.4 and HTTPS (port 8443, LAN side) is working fine with Firefox 59.0.1 here, see screen shot. Tried it from 2 different macOS 10.13.3 High Sierra machines if that makes any difference?



StephenH

 

[RMerlin]

Sorry if this has been reported previously. OpenVPN Server Tab - If I click on the Local network only or Internet and local network only radio button, the Custom button disappears.

That's normal. That setting is merely a preset that gets applied to various options on the Advanced page. Custom means that those settings were manually configured in a way that doesn't match either settings. When you select a proper preset, then the custom option disappears, since you cannot apply a "custom preset", if you understand what I mean.


This is all getting overhauled in 384.5. I am removing various broken/useless/duplicate settings, and replacing this preset selector with an actual setting that will allow one to chose between giving access to the LAN only, the Internet only, or both LAN and Internet. This setting will combine the previous manual options of Redirect Gateway, Push LAN, Firewall.

The Advanced page will now be a bit less filled with useless or confusing settings:



The new Internet Only option will prevent access to anything on the LAN including the router itself. It's intended to allow you to give someone access to your Internet connection without being able to access your LAN. This option was actually previously available as the cryptic "External" option for the Firewall setting. It was not only cryptic, but it also didn't even work properly... Now it's more visible, and it actually works.

 

[mbze430]

I have a RT-AC5300 running Firmware Version:384.4. Every time I make changes to the WIFI, the wifi totally stop working. Reboot doesn't work unless I completely pull out the power and plug it back in. Please fix

Mar 22 22:29:29 rc_service: httpd 383:notify_rc restart_wireless
Mar 22 22:29:29 rc_service: waitting "restart_wireless" via httpd ...
Mar 22 22:29:44 rc_service: skip the event: restart_wireless.
Mar 22 22:36:21 kernel: net_ratelimit: 1 callbacks suppressed
Mar 22 22:38:12 rc_service: httpd 383:notify_rc restart_usb_idle;restart_time;restart_upnp;
Mar 22 22:38:12 rc_service: waitting "restart_wireless" via httpd ...
Mar 22 22:38:27 rc_service: skip the event: restart_usb_idle;restart_time;restart_upnp;.
Mar 22 22:40:59 rc_service: httpd 383:notify_rc reboot
Mar 22 22:40:59 rc_service: waitting "restart_wireless" via httpd ...
Mar 22 22:41:14 rc_service: skip the event: reboot.

 

[RMerlin]

Firefox broke something with SSL when they moved to the Quantum engine, and things seem to have gotten even worse with their recent release. Not sure what happened, so far the only 100% working solution that I've found is to generate your own CA + signed certificate, and to import the CA into the trusted CA store. I suspect that Firefox is trying to validate something with the self-signed certificate (and failing miserably at doing so).

Some people have also had some success deleting the previously stored certificate from Firefox, and accepting it again.

I wish I knew what was going on (Chrome has a similar issue, except it's more random, and usually manifests itself with pages failing to fully load), but it seems that it would take someone with low-level knowledge of the TLS protocol to properly troubleshoot this. This is not a new issue, it's been happening for a few years now, but somehow has become worse with recent browser updates.

A search only showed a similar issue happened with Firefox a few years ago, where Firefox would choke on any certificate missing the email attribute. At the time it was marked as a bug in Firefox, and I believe it was eventually fixed.

 

[bozo29]

This usually indicate an Ethernet cabling issue, as the port will downgrade the link rate if the connection isn't stable enough. I recommend replacing the Ethernet cable. This is definitely not a firmware issue, there's been almost no changes to the Ethernet port driver in years.

Thank You Merlin,
Indeed, the cable was to blame.
I've changed it and now everything is all right.

 

[Stephen Harrington]

This is all getting overhauled in 384.5. I am removing various broken/useless/duplicate settings, and replacing this preset selector with an actual setting that will allow one to chose between giving access to the LAN only, the Internet only, or both LAN and Internet. This setting will combine the previous manual options of Redirect Gateway, Push LAN, Firewall.

The Advanced page will now be a bit less filled with useless or confusing settings:

The new Internet Only option will prevent access to anything on the LAN including the router itself. It's intended to allow you to give someone access to your Internet connection without being able to access your LAN. This option was actually previously available as the cryptic "External" option for the Firewall setting. It was not only cryptic, but it also didn't even work properly... Now it's more visible, and it actually works.

Looks good, will look forward to it @RMerlin.

StephenH

 

[Treadler]

I also have an RT-AC68U that I run as transparent AP. I connect to the WebUI only with HTTPS on port 8443. What changed for me from .3 to .4 is that I no longer, no way can connect to WebUI with Firefox 59.x as I reported in https://www.snbforums.com/threads/r...4-4-is-now-available.45406/page-2#post-389741
I have after reporting done full factory reset and manual reconfiguration and full power cycling to ensure that no old settings are the culprit. No difference with Firefox 59.x. That one doesn't work.

However. I can connect just fine to WebUI with Chromium and Google Chrome. So what you should do is try another browser. (And remember to clear the browsers cached content with F5 or Shift+F5, depending on the browser.)

I had the same problem, fixed by doing a Firefox browser reset to default. (In the browser settings).
Now HTTPS works fine.

 

[Grisu]

I had the same problem, fixed by doing a Firefox browser reset to default. (In the browser settings).
Now HTTPS works fine.

easier way instead resetting complete FF to default not loosing them:
open FF and wait more than an hour, update only router page not working correct, dont touch other tabs.
go to chronik/history and click delete newest chronik/history
you are asked choose delete last hour and let them all be deleted

now it works for me again with old profile ...

 

[Odkrys]

There is little bug.
When I set openvpn client config to Default, almost was gone but only Start with WAN setting remained to Yes.
nvram get vpn_clientx_eas => 1,3, (I removed client 3)

 

[Bagu]

HTTPS working fine for me on 384.4 with both an AC68U and my main AC86U, default port of 8443 with "BOTH" enabled.

StephenH

Not here.
I generate a new certificate...But the nothing change :

No problem or conflict with air web cloud service, i change the port to 1443.
Access http://192.168.1.1 work fine
Access https://192.168.1.1 don't work (Timeout)

 

[bbunge]

Firefox broke something with SSL when they moved to the Quantum engine, and things seem to have gotten even worse with their recent release. Not sure what happened, so far the only 100% working solution that I've found is to generate your own CA + signed certificate, and to import the CA into the trusted CA store. I suspect that Firefox is trying to validate something with the self-signed certificate (and failing miserably at doing so).

Some people have also had some success deleting the previously stored certificate from Firefox, and accepting it again.

I wish I knew what was going on (Chrome has a similar issue, except it's more random, and usually manifests itself with pages failing to fully load), but it seems that it would take someone with low-level knowledge of the TLS protocol to properly troubleshoot this. This is not a new issue, it's been happening for a few years now, but somehow has become worse with recent browser updates.

A search only showed a similar issue happened with Firefox a few years ago, where Firefox would choke on any certificate missing the email attribute. At the time it was marked as a bug in Firefox, and I believe it was eventually fixed.

Another fix is to move back the Firefox ESR version. FF 58 seemed to be OK but FF 59 seemed to bring on problems.

Sent from my P01M using Tapatalk

 

[skeal]

Not here.
I generate a new certificate...But the nothing change :

No problem or conflict with air web cloud service, i change the port to 1443.
Access http://192.168.1.1 work fine
Access https://192.168.1.1 don't work (Timeout)

You need to use https://192.168.1.1:443 for example.

 

[Bagu]

S

You need to use https://192.168.1.1:443 for example.

Same result - Already try

 

[AndreiV]

S

Same result - Already try

Try https://router.asus.com:8443/Main_Login.asp

 

[Bagu]

Try https://router.asus.com:8443/Main_Login.asp

404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.

 

[mikelees2]

Okay, done. I did the following:

1. Unplugged the USB flash drive from the RT-AC3200
   
   
2. Re-Uploaded 384.4
   
   
3. Initiated a Factory Reset from the GUI
   
   
4. Waited for 10 minutes after reboot
   
   
5. Turned SSH on, then turned the power switch off (I have no idea why I have to power-cycle to make SSH accept a connection, but even a Reboot from the GUI doesn't get the job done)
6. With the power switch off, unplugged the power supply, turned power switch back on for five seconds, turned power switch off, plugged the power back up, and turned the power switch back on.
   
   
7. Plugged in a USB flash drive containing my NVRAM settings backup
   
   
8. Restored Settings and rebooted

Sadly, I'm back to having all sorts of problems, as before: the Ecobee thermostat, Ubuntu laptop, some Chromecasts, and some LIFX bulbs now can't connect to Wi-Fi.

So, I'll be returning to 384.3 shortly, and will report back. Thanks again for your help, skeal.

I don't recommend restoring settings on this new firmware 384.4 from any firmware. If you did and are still having problems you need to build the router from scratch. Factory Reset and reprogram the router. Yes it sucks but it's the only way you can insure that you are not corrupting the routers new firmware by restoring settings from an old build. Take some screen shots and time and just do it. It will be worth the time. Until you do you will have nothing but problems. So to me if you wish to continue with the newest software you will have to take the leap and just do it.
The other thing to think about as with some who have also had troubles after restoring and having it work, If the restore works this time will it continue to work on the next update? Sometimes you just need to start fresh.

 

[SkOrPn]

Hello again,

I am wondering what people think "overall" of the new generation 384 Asus Merlin software? What does it have to bring to the table that the older software didn't? Is it stability, performance, design flaw or security issue that Asus improved with 384?

The reason I am wondering if I should upgrade to 384 (from 380.69_2) is because all of my Wemo wifi smart switches do not reconnect after a power outage reboot or even a simple router reboot. Belkin tells me they believe its the router or its firmware and to update it, lol. All my other wifi switches and wifi devices work and connect just fine though.

So, for the past Month I keep thinking to myself maybe this new 384 GPL branch could make a difference just because the software is newer? My AC66U_B1 (same as AC68U) is still running 380.69_2. Of course I will wait for 384.5 because that sounds like it will come with some substantial but needed changes to the UI. Thanks again at Merlin for this great and much appreciated work.

So do you all get the feeling that the 384 branch is better than the old 380 branch?

 

[bland328]

As usual, when facing stability issues, proceed with a real factory default reset, without restoring any kind of backup. It's the only way to be 100% certain of the resulting configuration.

tl;dr: I've been through multiple 384.4 installations on my RT-AC3200, but many Wi-Fi devices in my home that are perfectly happy with 384.3 are then unable to connect.

I'm the guy who reported Ubuntu laptop, Ecobee thermostat and LIFX bulb Wi-Fi connection woes with 384.4 (but not 384.3) back in post 391079.

Today I sat down with my RT-AC3200 to do a slow, patient, meticulous flash, factory reset, and manual configuration.

I did the following:

1. Unplugged all USB devices
2. Flashed 384.4 and waited for reboot to finish
3. Followed DaveMishSr's instructions on holding the WPS button at power up multiple times to get a good factory reset (as he describes, I did witness the power light pulsating at the 20-second mark the first time through, and at the 5-second mark the second time through)
4. Followed RMerlin's instructions on power cycling with a complete electrical reset
5. Turned the router on and waited 10 full minutes, per skeal's advice
6. Stepped through the simple three-step GUI wizard to get the fundamentals configured
7. Observed, as I always do, the WAN light was red, and since initiating a Reboot via the GUI has never cured that for me, followed RMerlin's instructions on power cycling with a complete electrical reset once more, for good measure.

After all that, my iPhone and my wife's Windows laptop successfully connected, but my Ubuntu laptop, Ecobee thermostat and some LIFX Wi-Fi lightbulbs still will not.

Any thoughts? Did I miss a trick? Any data I can gather for anyone?

 

[Datalink]

The only thing left to do, I think, is to record the router - Ubuntu exchange with Wireshark. You would need to record two sessions, one with a router firmware version that works, and one with 384.4 loaded. Here's what I would do:

1. Turn off all other wifi devices.
2. Turn off the router or turn off the wifi on the router, your choice.
3. Fire up the Ubuntu laptop and start recording with Wireshark.
4. Start the router, or, turn on the router's wifi. Let the Wireshark recording session run until it appears that the router's wifi is up and running and then let it run for another two or three minutes. Wireshark should, I believe, pick up and record the incoming and outgoing data from the wifi adapter when the router wifi starts up and attempts to connect with any device on its network.
5. Save the recorded session.


Reload the router with the other firmware. When complete, follow the same steps. When that session has been recorded, bring up both data sets in seperate Wireshark instances. When you select (click or double click on) the data file it will start a Wireshark instance with that data. You can filter the data to show the conversation between specific IP addresses, but, in the case of the data archive where the laptop doesn't connect, that might not work. So, what you will have to do is go thru the data to the start point where the Ubuntu laptop does connect with the previous version. Once you find that, you should be able to find the same start point in the other archive. From there, its a matter of examining the data to see where they diverge. This is more than a pain in the ***, but, without a method of seeing the two way conversation at the start of the connection attempt, I don't see any other way around this.

If you had another Ubuntu laptop around, you might be able to set its wifi adapter to run in Monitor or Promiscuous mode to capture the two way traffic between the router and original Ubuntu laptop. From there, you would have to step thru the data to see where the connection attempt occurs and where it fails.

In either case, hopefully you would find the problem point and be able to provide that info to Merlin or Asus.

Edit: Just thinking about this, I wonder if you would have to use a second Ubuntu/linux laptop with Monitor or Promiscuous mode set in order to capture the raw data exchange between the router and original laptop. I suspect that a good portion of the raw data would be filtered by the adapter card on the original laptop as the card would be running in its normal operating mode. That raw data would probably contain the lower level exchange that occurs when the laptop starts the login sequence with the router.