Release Asuswrt-Merlin 388.1 is now available for all supported Wifi 6 models
- Thread starter RMerlin
- Start date
I don`t expect to have any new GPL to merge until next month at the earliest.
randomName
Very Senior Member
On 386.7 with my RT-AX86U It's been fine for me for a while. Can I just upgrade to 388.1 and not reset everything?
L&LD
Part of the Furniture
Possibly. You can certainly try. 
Before you do, download the firmware you have installed now. Reboot the router, and wait for 10 to 15 minutes for it to settle. Create a backup config file of your current settings. Create a JFFS backup too. Put all these files in a safe place.
Safely (and physically) Remove all USB devices/drives from the router, and reboot. If any of these USB devices was used for amtm and/or associated scripts, do not plug into the router again until the flash has been shown to have 'taken' and the router has settled down (~10 minutes) after the last reboot. Once you insert the USB drive into the router, be sure you wait a few minutes, then perform a reboot via the GUI.
Flash the firmware you want to use/test today. If any issues that a few quick/specific questions don't get you quick resolution from the forums here, use the files above to quickly go back to where you were.
To revert to your previous working setup:
Before you do, download the firmware you have installed now. Reboot the router, and wait for 10 to 15 minutes for it to settle. Create a backup config file of your current settings. Create a JFFS backup too. Put all these files in a safe place.
Safely (and physically) Remove all USB devices/drives from the router, and reboot. If any of these USB devices was used for amtm and/or associated scripts, do not plug into the router again until the flash has been shown to have 'taken' and the router has settled down (~10 minutes) after the last reboot. Once you insert the USB drive into the router, be sure you wait a few minutes, then perform a reboot via the GUI.
Flash the firmware you want to use/test today. If any issues that a few quick/specific questions don't get you quick resolution from the forums here, use the files above to quickly go back to where you were.
To revert to your previous working setup:
- Remove all USB drives. Do not plug in these drives again until you've successfully completed all the steps below.
- Flash the firmware you have installed now (i.e. the firmware you're upgrading from).
- If the router/network is behaving as you expect, great! You're done.
- If it isn't, perform a full reset to factory defaults.
- Restore the saved backup config file you created above.
- Restore the saved JFFS backup file you created above.
TheKrankster
New Around Here
Apologies if this has been discussed. Anyone else having issues with download manager? I can’t login. It states my user name/password is incorrect. Any help?
snah001
Occasional Visitor
Well I always update with the USB stick attached (Diversion and Entware on it) and it always gives no hussle at all.Possibly. You can certainly try.
Before you do, download the firmware you have installed now. Reboot the router, and wait for 10 to 15 minutes for it to settle. Create a backup config file of your current settings. Create a JFFS backup too. Put all these files in a safe place.
Safely (and physically) Remove all USB devices/drives from the router, and reboot. If any of these USB devices was used for amtm and/or associated scripts, do not plug into the router again until the flash has been shown to have 'taken' and the router has settled down (~10 minutes) after the last reboot. Once you insert the USB drive into the router, be sure you wait a few minutes, then perform a reboot via the GUI.
Flash the firmware you want to use/test today. If any issues that a few quick/specific questions don't get you quick resolution from the forums here, use the files above to quickly go back to where you were.
To revert to your previous working setup:
- Remove all USB drives. Do not plug in these drives again until you've successfully completed all the steps below.
- Flash the firmware you have installed now (i.e. the firmware you're upgrading from).
- If the router/network is behaving as you expect, great! You're done.
- If it isn't, perform a full reset to factory defaults.
- Restore the saved backup config file you created above.
- Restore the saved JFFS backup file you created above.
That means not that one can not have troubles with it attached but for me it just works after every update out of the box.
Only extra I do after updating is powercycle the router.
It is running now for 35 days in a row without problems.
Caesar the Dictator
Occasional Visitor
The newly added WireGuard client feature works really well except for one thing: The DNS server. In fact, if only one client is active on the router, the DNS server customization will work fine. Unfortunately, things get complicated when multiple WireGuard clients are active with the same DNS server (for example, the VPN provider's internal ad-blocking DNS server address) set. In this scenario, devices connected to 3-4 active WireGuard clients will have their DNS queries made through the other client's tunnel instead of their own. I don't understand the which WireGuard client forces DNS queries to be made through its own tunnel why, because my technical knowledge is insufficient.
While this may not seem like a critical problem like IP/DNS leakage, it should be considered a problem. This is because normally all internet traffic for devices is expected to go through the VPN client set up in the VPN director. To overcome this problem in WireGuard clients, it was suggested that the DNS server address line in the clients should be left blank and the VPN's internal DNS server address should be manually added to the DNS director, followed by a DNS redirection rule for each device.
However, this method is in itself limited and impractical. Devices selected for the DNS director can be added by typing the MAC address instead of the CIDR notation, and this seems to be limited to 64 rules. For example, in the VPN director, let's say the range 192.168.1.1/25 is routed to WireGuard client 1 and 192.168.1.128/25 is routed to WireGuard client 2. In this case, the DNS director would have to add 254 rules, but the upper limit is 64. The logic would say that "Global redirection" should be used instead. However, sometimes some devices may be temporarily redirected to the WAN instead of VPN clients, in which case DNS queries will fail (because the VPN's internal ad-blocking DNS server is set in the DNS director) and internet access will suffer. This is why the "Global redirection" option cannot be set (i.e. no redirection should be preferred). This is an example of limited use.
Since rules cannot be set according to CIDR notation, let's move on to another scenario that falls within the maximum limit of 64 rules. Every time we redirect a device in the VPN director to the WAN, we also have to set the corresponding device in the DNS director to "no redirection". This is an example of impractical use.
It is certainly not my intention to impose an idea or a change on the developers, but shouldn't WireGuard clients have a more practical solution to the DNS server confusion? Maybe the client tunnel confusion in the first paragraph could be solved somehow. Maybe assign a DNS server address on that screen for devices that are included in the VPN director, which ignores the DNS director settings, even if active, until the device(s) are routed to the WAN. I don't know, it's just a simple thought, maybe there are many factors that I didn't take into account so that this can't be done.
Anyway, I hope you don't think I'm being impolite or patronizing with less technical knowledge. @RMerlin
While this may not seem like a critical problem like IP/DNS leakage, it should be considered a problem. This is because normally all internet traffic for devices is expected to go through the VPN client set up in the VPN director. To overcome this problem in WireGuard clients, it was suggested that the DNS server address line in the clients should be left blank and the VPN's internal DNS server address should be manually added to the DNS director, followed by a DNS redirection rule for each device.
However, this method is in itself limited and impractical. Devices selected for the DNS director can be added by typing the MAC address instead of the CIDR notation, and this seems to be limited to 64 rules. For example, in the VPN director, let's say the range 192.168.1.1/25 is routed to WireGuard client 1 and 192.168.1.128/25 is routed to WireGuard client 2. In this case, the DNS director would have to add 254 rules, but the upper limit is 64. The logic would say that "Global redirection" should be used instead. However, sometimes some devices may be temporarily redirected to the WAN instead of VPN clients, in which case DNS queries will fail (because the VPN's internal ad-blocking DNS server is set in the DNS director) and internet access will suffer. This is why the "Global redirection" option cannot be set (i.e. no redirection should be preferred). This is an example of limited use.
Since rules cannot be set according to CIDR notation, let's move on to another scenario that falls within the maximum limit of 64 rules. Every time we redirect a device in the VPN director to the WAN, we also have to set the corresponding device in the DNS director to "no redirection". This is an example of impractical use.
It is certainly not my intention to impose an idea or a change on the developers, but shouldn't WireGuard clients have a more practical solution to the DNS server confusion? Maybe the client tunnel confusion in the first paragraph could be solved somehow. Maybe assign a DNS server address on that screen for devices that are included in the VPN director, which ignores the DNS director settings, even if active, until the device(s) are routed to the WAN. I don't know, it's just a simple thought, maybe there are many factors that I didn't take into account so that this can't be done.
Anyway, I hope you don't think I'm being impolite or patronizing with less technical knowledge. @RMerlin
@Caesar the Dictator :
IMO there's a general misunderstanding about what WireGuard (is/isn't) most people quickly go from a fairly basic remote connection into full-blown (encryption/scrambling/obfuscation).
When initially testing WireGuard, I quickly learned that many networks implore deep packet analysis & therefore refuse WireGuard connections through.
But because of the limited feedback (for troubleshooting)... You're left just shrugging your shoulders or scratching your head thinking WTF???
+
We as consumers keep wanting & expecting more & more from our networks...
But eventually if you add enough features & complexity, at some point don't the expectations cross over into the professional, commercial, or corporate realm?
IMO there's a general misunderstanding about what WireGuard (is/isn't) most people quickly go from a fairly basic remote connection into full-blown (encryption/scrambling/obfuscation).
When initially testing WireGuard, I quickly learned that many networks implore deep packet analysis & therefore refuse WireGuard connections through.
But because of the limited feedback (for troubleshooting)... You're left just shrugging your shoulders or scratching your head thinking WTF???
+
We as consumers keep wanting & expecting more & more from our networks...
But eventually if you add enough features & complexity, at some point don't the expectations cross over into the professional, commercial, or corporate realm?
Caesar the Dictator
Occasional Visitor
@capncybo You are absolutely right about the things you mentioned. I personally don't always ask for more, but it's usually the case as you say. I have mentioned in the back pages that the above complexity or problem, whatever you want to call it, also affects OpenVPN clients.
Anyway, basically what I'm trying to say is that there is now a complexity or a problem that didn't exist before firmware 388.1, and if this is going to continue, then of course consumers should understand that. If we want more, we should go for networking devices that are made for specialists.
Anyway, basically what I'm trying to say is that there is now a complexity or a problem that didn't exist before firmware 388.1, and if this is going to continue, then of course consumers should understand that. If we want more, we should go for networking devices that are made for specialists.
kelddamsbo
Occasional Visitor
Just for your information. I had some problems on my 3 RT-AX88U setup in AiMesh.
2 days ago I updated to native FW from ASUS:
ASUS RT-AX88U Firmware version 3.0.0.4.388.22237
Version 3.0.0.4.388.22237 66.33 MB
1. Improved system stability.
2. Fixed the IPsec VPN compatibility issue with Win10.
3. Fixed the VPN fusion user interface issues under the HTTPS connection.
4. Fixed Client DOM Stored XSS vulnerability.
5. Improved Wireguard performance.
6. Optimized memory usage and improved system stability.
7. Fixed USB HDD compatibility issue with the Time machine.
8. Added a new web GUI login URL http://www.asusrouter.com
9. Fixed IPTV compatibility issue with Movistar. Thanks to Sergio de Luz from RedesZone.net.
10. Fixed VPN fusion, AiMesh, and Network map GUI bugs.
All problems gone, but I miss the nice features from Merlin.
I hope Merlin will get the new source from ASUS, and will implement it.
2 days ago I updated to native FW from ASUS:
ASUS RT-AX88U Firmware version 3.0.0.4.388.22237
Version 3.0.0.4.388.22237 66.33 MB
1. Improved system stability.
2. Fixed the IPsec VPN compatibility issue with Win10.
3. Fixed the VPN fusion user interface issues under the HTTPS connection.
4. Fixed Client DOM Stored XSS vulnerability.
5. Improved Wireguard performance.
6. Optimized memory usage and improved system stability.
7. Fixed USB HDD compatibility issue with the Time machine.
8. Added a new web GUI login URL http://www.asusrouter.com
9. Fixed IPTV compatibility issue with Movistar. Thanks to Sergio de Luz from RedesZone.net.
10. Fixed VPN fusion, AiMesh, and Network map GUI bugs.
All problems gone, but I miss the nice features from Merlin.
I hope Merlin will get the new source from ASUS, and will implement it.
Find the Door
Senior Member
Nothing but issues with AX86U after the update. Have to roll back.
CaptainSTX
Part of the Furniture
Running 388.1 on a new AX86S and it all seems stable. I had to disable the AX wifi option as older Iphones would not connect. Will decide if I'm going to keep this router before moving to latest Merlin firmware.
One issue is with the information displayed on the Network Map page.
It shows a warning (port displayed in yellow) for one of my LAN Ethernet ports and the explanation suggests that it might be a bad cable. What it is actually is that I have a device with a 100Mbps fast Ethernet port connected and changing the cable makes no difference.
Under Tools/sysinfo the port is displayed correctly and is listed as 100 Mbps.
One issue is with the information displayed on the Network Map page.
It shows a warning (port displayed in yellow) for one of my LAN Ethernet ports and the explanation suggests that it might be a bad cable. What it is actually is that I have a device with a 100Mbps fast Ethernet port connected and changing the cable makes no difference.
Under Tools/sysinfo the port is displayed correctly and is listed as 100 Mbps.
Yellow is normal for 100 Mb link. Nothing is wrong
visortgw
Very Senior Member
Any connection at a speed less than maximum port speed is subject to the warning.
CaptainSTX
Part of the Furniture
All I'm saying is at least it would be helpful if when someone clicks on the information Icon it listed that as a possible source for the warning that there is a 100 Mbps device connected on this port.
Oh I AGREE 100%, IMO it's definitely an over-site on the part of ASUS. I'm still using "Connected by TCP" smart bulbs which use a 100 Mbps Ethernet port on the HUB. Newer isn't always better LOL
We all agree with you. Complain to Asus support
shabbs
Very Senior Member
That does not seem to apply for 1gig connections into a 2.5gig port tho...
2.5G WAN port is a 2.5G connection to the Rogers XB7 Modem - all good.
2.5G LAN port to my gigabit switch is connected at 1 gig of course but all green.
visortgw
Very Senior Member
But it DOES seem to apply to one of my GT-AXE16000's 10 Gbps LAN ports connected to my 2.5 Gbps unmanaged switch at only 2.5 Gbps.
Similar threads
- Locked
Similar threads
Similar threads
-
-
-
Asuswrt-Merlin 3004.388.8_2 - Switching from ‘automatic IP’ to ‘PPPoE’- Started by AsusFreak
- Replies: 6
-
-
-
-
-
-
-
Beta Asuswrt-Merlin 3004.388.6_x test builds (dnsmasq 2.90)
- Started by RMerlin
- Replies: 102