Release Asuswrt-Merlin 3004.388.8_2 is now available

[eibgrad]

Not say I am happy but I was kinda ‘lonely’ with my problem.
So, it looks up Purana has same issue with mine… unfortunately

Let’s hope for a solution or maybe some workaround
Without it we must stick with old firmware atm.

Thanks in advanced

I'm not sure it is the same. You have introduced Wireguard into the picture, whereas (at least so far) @Purana has NOT.

As I said before, I'm still baffled why Wireguard is part of the discussion. As far as I can tell, it appears you have a functional, bi-directional, site-to-site OpenVPN tunnel between site A and B. I'm guessing you want to add accessibility to either site A or B *remotely* using Wireguard rather than OpenVPN, and that has created a conflict. Even using a remote OpenVPN client into site A instead of Wireguard could to lead to conflicts. I have seen users mistakenly using the same IP network on the co-located OpenVPN client and server tunnels (10.8.0.x), when in fact they need to be different. But Wireguard opens the door to other unknowns (at least to me; I don't have access to it w/ my AC68U). These VPNs typically manipulate both the routing tables and the firewall, increasing the likelihood of conflicts. But w/ nothing but your description to go by, I'm left to guess where that conflict lies.

 

[Rob90]

If the issue is with the stock firmware, Merlin won't be able to fix it.

So you need to figure out if it is a stock firmware related issue or MerlinWRT specific issue (if you want to progress this further).

Just installed stock 3.0.0.4.388_24243. No issue there.

So it looks MerlinWRT specific and is present on all versions > 388.5

 

[RMerlin]

But doesn't that still require the WAN to be listening on the open port

I'm not sure. Maybe not since it would be going over the NAT loopback.

Yes, I access the GUI remotely over the WAN

Don't. The majority of serious vunlerabilities fixed by Asus are related to the web interface. You should setup a VPN server for remote access instead.

 

[iBest]

I'm not sure it is the same. You have introduced Wireguard into the picture, whereas (at least so far) @Purana has NOT.

As I said before, I'm still baffled why Wireguard is part of the discussion. As far as I can tell, it appears you have a functional, bi-directional, site-to-site OpenVPN tunnel between site A and B. I'm guessing you want to add accessibility to either site A or B *remotely* using Wireguard rather than OpenVPN, and that has created a conflict. Even using a remote OpenVPN client into site A instead of Wireguard could to lead to conflicts. I have seen users mistakenly using the same IP network on the co-located OpenVPN client and server tunnels (10.8.0.x), when in fact they need to be different. But Wireguard opens the door to other unknowns (at least to me; I don't have access to it w/ my AC68U). These VPNs typically manipulate both the routing tables and the firewall, increasing the likelihood of conflicts. But w/ nothing but your description to go by, I'm left to guess where that conflict lies.

Hi,

I know how to handle subnets and vpn’s.
It’s not a problem of how i use.
Think only on this: on previous firmware all works.
On this (without any changes ofc) it doesn’t.
If there was some ip conflict it wasn’t possible to run on any firmware.

Will try some tests from both fw, from different wireguard clients. But as far as i can tell some routing is missing or it has limited access.

Thanks again !

 

[RMerlin]

Hey, thanks for the work. But another time, there is WiFi issue. RT-AX86U here

Zero changes to wifi in this release as there was no new GPL merged.

 

[bennor]

I'm unable to mount my LTE-USB dongle ever since 3004.388.5.
<snip>

The log you posted indicates "CD-ROM HUAWEI Mass Storage". If the LTE dongle is the only USB device attached then it is being misidentified by the router firmware as a CD-ROM mass storage device.

What router are you running?
What is the specific make/model of the USB dongle you are using.
Which USB port is it connected to?

There are certain aspects of the firmware that RMerlin has no control over and you'd have to complain up the chain to Asus to see if they have any suggestions.

 

[eibgrad]

I'm not sure. Maybe not since it would be going over the NAT loopback.

But the reason NAT loopback works is due to the DNAT. And the DNAT is typically only present if you enable remote access over the WAN. That's what turns the public IP reference into a local IP reference, and then back to a public IP reference on the reply when the DNAT is undone. I thought that perhaps in the case of the GUI, it *might* always be there, even if the port is closed, but I just tested it, and it isn't. It's only there when remote access over the WAN is enabled. Same thing holds true for port forwarding. No port forward, so no DNAT, so no NAT loopback.

Again, that's the issue for me. The fact anyone is making the GUI accessible over the WAN, even if https. I don't trust it.

 

[Rob90]

The log you posted indicates "CD-ROM HUAWEI Mass Storage". If the LTE dongle is the only USB device attached then it is being misidentified by the router firmware as a CD-ROM mass storage device.

What router are you running?
What is the specific make/model of the USB dongle you are using.
Which USB port is it connected to?

There are certain aspects of the firmware that RMerlin has no control over and you'd have to complain up the chain to Asus to see if they have any suggestions.

LTE dongle was indeed the only device attached.
Router AX86S
LTE USB Stick Huawei E3372

Just verified that it works fine on stock Asus firmware (see my previous post). Worked fine on Merlin firmware until 388.5. Noticed it broke when installing 388.6, tried every new release since then without any luck. So looks like some change introduced in 388.6 broke this functionality.

 

[eibgrad]

If there was some ip conflict it wasn’t possible to run on any firmware.

Not necessarily. Depends on what changed! Granted, it may be highly unlikely, but we can't say it's impossible. You can't assume the same config will *always* work from release to release. You can become the innocent victim of some other change, one you might not even suspect. It might even be an error introduced by the developer. Or perhaps just assumption you made about what should work, and it did, but then stopped working when the developer made some other change.

That's why I *need* to see the dumps! I'm otherwise forced to guess at possibilities here. I'm not willing to take anything off the table, no matter how it may *appear* to NOT be an issue according to your logic.

 

[eibgrad]

Hi,

I know how to handle subnets and vpn’s.
It’s not a problem of how i use.
Think only on this: on previous firmware all works.
On this (without any changes ofc) it doesn’t.
If there was some ip conflict it wasn’t possible to run on any firmware.

Will try some tests from both fw, from different wireguard clients. But as far as i can tell some routing is missing or it has limited access.

Thanks again !

Btw, I don't recall you mentioning it, but when you upgraded, did you do a CLEAN upgrade (i.e., start from fresh and manually apply changes) and NOT use a backup of the prior config? I've seen my share of problems w/ dirty upgrades too. They should be avoided. I know it's particularly tempting when one of the locations is remote.

 

[iBest]

Not necessarily. Depends on what changed! Granted, it may be highly unlikely, but we can't say it's impossible. You can't assume the same config will *always* work from release to release. You can become the innocent victim of some other change, one you might not even suspect. It might even be an error introduced by the developer. Or perhaps just assumption you made about what should work, and it did, but then stopped working when the developer made some other change.

That's why I *need* to see the dumps! I'm otherwise forced to guess at possibilities here. I'm not willing to take anything off the table, no matter how it may *appear* to NOT be an issue according to your logic.

Yeah, it’s logic.
Ok, I’ll make possible the logs.
Tell me please if I/we can take this in private after?

Thank-you very much !

 

[eibgrad]

Yeah, it’s logic.
Ok, I’ll make possible the logs.
Tell me please if I/we can take this in private after?

Thank-you very much !

Just PM me. If it makes it easier, post the dumps to PasteBIn and provide links.

 

[iBest]

Btw, I don't recall you mentioning it, but when you upgraded, did you do a CLEAN upgrade (i.e., start from fresh and manually apply changes) and NOT use a backup of the prior config? I've seen my share of problems w/ dirty upgrades too. They should be avoided. I know it's particularly tempting when one of the locations is remote.

Need a looot of time for this…
Never had a problem based on the update.
Since i don’t use beta fw but i know there can be a small chance of this to impact on settings.
Short answer, no at least atm

 

[CKret]

I have the same problem mentioned in posts #11, #25, #81, #88 and #93.

The Setup:
Site A: AX-88U OpenVPN Server, Merlin 3004.388.8
Site B: AX-68U OpenVPN Client, Merlin 3004.388.8, (Lan only. No redirect Internet i.e. no Killswitch rules should apply).
Site C: AX-55 OpenVPN Client, Stock 3.0.0.4.386_52303-ga31a98b, (Lan only. No redirect Internet. No Killswitch available).

OpenVPN Connection:
Site B <--> Site A <--> Site C

Everything worked as expected on 388.7 and before. Clients on Sites A, B and C all have access to each other.

After the update to 388.8 Site A cannot access Site B. Site C is still accessible from Site A and vice versa.
Reverting firmware to 388.7 on Site B (Site A still has .8) fixes everything again.

I've looked through all possible settings and cannot find a culprit.
The only thing in the changelog I can see which could interfere with this are the new routing rules implemented with the Killswitch functionality.
Seeing that it is only clients that are affected with 388.8 there seems to be a faulty rule(s) or missing rule(s).

I can look into this in the code later and unless @RMerlin has any other ideas where to start digging I'll start by looking at these new rules.

 

[eibgrad]

I have the same problem mentioned in posts #11, #25, #81, #88 and #93.

The Setup:
Site A: AX-88U OpenVPN Server, Merlin 3004.388.8
Site B: AX-68U OpenVPN Client, Merlin 3004.388.8, (Lan only. No redirect Internet i.e. no Killswitch rules should apply).
Site C: AX-55 OpenVPN Client, Stock 3.0.0.4.386_52303-ga31a98b, (Lan only. No redirect Internet. No Killswitch available).

OpenVPN Connection:
Site B <--> Site A <--> Site C

Everything worked as expected on 388.7 and before. Clients on Sites A, B and C all have access to each other.

After the update to 388.8 Site A cannot access Site B. Site C is still accessible from Site A and vice versa.
Reverting firmware to 388.7 on Site B (Site A still has .8) fixes everything again.

I've looked through all possible settings and cannot find a culprit.
The only thing in the changelog I can see which could interfere with this are the new routing rules implemented with the Killswitch functionality.
Seeing that it is only clients that are affected with 388.8 there seems to be a faulty rule(s) or missing rule(s).

I can look into this in the code later and unless RMerlin has any other ideas where to start digging I'll start by looking at these new rules.

Like I suggested to @iBest, provide the same dumps I requested of him. Something this complicated is likely only to be solved by looking at the actual inner workings. Sometimes the conflict (if there is one) will become immediately evident.

 

[Ripshod]

The log you posted indicates "CD-ROM HUAWEI Mass Storage". If the LTE dongle is the only USB device attached then it is being misidentified by the router firmware as a CD-ROM mass storage device.

Not necessarily. Some devices carry Windoze drivers and software on a partition that mounts as a cd-rom drive. That said, that is exactly what the problem is here.
@Rob90 I don't understand how you were ever able to use this dongle.

 

[tnpapa]

I'm going to stir the pot here a little on WireGuard, but in my testing I found that running a WireGuard server on a computer works much better than using the application in the router. I get much higher throughput and do not have to rely on the router to handle the VPN load on the CPU.

If you have a Mac computer here are the complete instructions to roll your own server. It takes a little bit of file creation but once you get through it, it's stable as can be. This could help those of you with issues to solve them.

Wireguard Server on macOS

With this guide, you too can enjoy Wireguard VPN’s performance and security on macOS.

barrowclift.me

 

[Celo]

Hello!

Upgraded from 388.7 on a GT-AXE11000 and everything seemed fine, no errors and all addons looked ok, but i got no internet, neither from wifi or ethernet. Tried rebooting several times, disabling firewall, skynet, diversion, VPN servers (ovpn and wireguard), DNS DoT, nothing worked. I get an IP from the ISP, DDNS syncs, i get the e-mail notification that the router rebooted and changed the IP on my phone (on 5G) but still no internet on the router connected devices.

Rolled back to 388.7 and internet worked as it was.

 

[CKret]

Like I suggested to @iBest, provide the same dumps I requested of him. Something this complicated is likely only to be solved by looking at the actual inner workings. Sometimes the conflict (if there is one) will become immediately evident.

Which dumps would those be? I can't find the post where you requested specific dumps from @iBest.

Anyway. 388.7 on clients works for now. I will start looking at the new rules which I'm fairly certain are the culprit.

 

[RMerlin]

Hello!

Upgraded from 388.7 on a GT-AXE11000 and everything seemed fine, no errors and all addons looked ok, but i got no internet, neither from wifi or ethernet. Tried rebooting several times, disabling firewall, skynet, diversion, VPN servers (ovpn and wireguard), DNS DoT, nothing worked. I get an IP from the ISP, DDNS syncs, i get the e-mail notification that the router rebooted and changed the IP on my phone (on 5G) but still no internet on the router connected devices.

Rolled back to 388.7 and internet worked as it was.

Read the changelog.