Asuswrt-Merlin 378.55 beta 2 is now available

[ydc]

Found what I would call "unexpected behavior" using selective routing on 378.54_2 and didn't see it in any of the change logs in the 378.55 beta * entries.

I configured a client ip to be routed through the client VPN I set up and selected the option to "block routed clients if the tunnel goes down." Later I decided to shut the tunnel down in the router UI. Turns out the client gets blocked regardless of whether the tunnel went down on it's own or I shut it down. I can see pros and cons for this but I kind of expected it to block the client only when the tunnel went down while I had the tunnel still enabled.

Any thoughts on whether it should be expected that such a client would be blocked when manually shutting the tunnel down?

 

[tommy76]

378.55 Beta 1 and 378.55 Beta 2:
Router doesn't use cloned MAC address

AC87

 

[Martineau]

Found what I would call "unexpected behavior" using selective routing on 378.54_2 and didn't see it in any of the change logs in the 378.55 beta * entries.

I configured a client ip to be routed through the client VPN I set up and selected the option to "block routed clients if the tunnel goes down." Later I decided to shut the tunnel down in the router UI. Turns out the client gets blocked regardless of whether the tunnel went down on it's own or I shut it down. I can see pros and cons for this but I kind of expected it to block the client only when the tunnel went down while I had the tunnel still enabled.

Any thoughts on whether it should be expected that such a client would be blocked when manually shutting the tunnel down?

Working as designed.

i.e. if you boot the router and never open the VPN tunnel then the VPN clients will never access the WAN (even though the VPN tunnel has never been physically UP) if you have the option selected.

This ensures there is no WAN 'leak' for VPN clients whose traffic/surfing activity must ALWAYS be 'hidden' by the (usually) encrypted VPN.

I suppose the wording of the option should be changed to "Always block WAN access for ALL routed clients if VPN is unavailable"

EDIT: You can always write a script that is manually ONLY called by you to shut the tunnel down and subsequently temporarily remove the RPDB selective routing rule for the client (to allow WAN access), then use a similar rule to reinstate the WAN blocking rule when you manually re-open the VPN tunnel.

 

[PabloAbonia]

That's a lot of customization, and something that would be difficult for me to reproduce here. Best I can do at this point is switch to Asus's own DHCP lease parser, which will skip the duid line as well as any entry that's not an IPv4 lease since I have no real way to test this.

That's what I figured, hence the description of the underlying probable problem first, rather than the customization. I can posts the scripts involved, but generating the EUI64 required an access database to derive it from the MAC addresses. Regardless, if it were an EUI64, or random assignment it would likely have the same problem.

Still, I would think that the lease page would be a problem if/when IPV6 addresses are allowed to be assigned by Asus. I don't know which would be more efficient for you (Asus parser, or your own), but for your own, you could always stop at the duid line as I believe it consistently separates IPV4 from IPV6 addresses.

One other thing, this the beta2 update appears to have cleared the ipv6_neighsol_drop=1 from NVRAM.

 

[highwire]

I know, and I already notified Asus about this issue two weeks ago. They recently did some change to traffic monitoring on the AC87U, I suspect it's what introduced the issue.

Thanks for confirming. I kinda wish I bought a 68U instead. The 87U appears to be a lemon with the Quantenna SoC.

 

[joegreat]

In addition, the wireless driver was updated for the RT-AC68U (from GPL 6975 - Asus forgot to include it in the 6117 GPL) and RT-AC56U (from GPL 6117). Please confirm there are no new major issues with this driver update (as usual I'm not interested in feedback regarding speed/range, as this is always conflicting as it depends on each user's specific environment, and a 2-3% difference can easily amount to be within the typical wifi variation).

I assume that a factory reset is recommended due to wireless driver change, or this time not needed?

Shouldn't be, there was no nvram change related to it. You might just want to forget the network on your clients and reconnect them again, just to be safe.

Hi,

I reconnected some of my wireless devices and have not encountered any issues with the 2.4GHz WLAN.

But with the 5 GHz, I have a strange behavior on my Google Nexus 5 smartphone:
The connection is not stable, in the middle of a speed test it disconnects from the N68U router and connects to the N66U 5GHz network.
The speed during the test is only 50-75% of my 150 MBit download max.

Not sure if this is a common issue, but I wanted to let you know as I will be off for the next 2 weeks and only after that I can test further (or install a new beta version).

With kind regards
Joe

 

[tonyquan]

One other thing, this the beta2 update appears to have cleared the ipv6_neighsol_drop=1 from NVRAM.

This flag was renamed to ipv6_ns_drop in the .53 release (see the changelog)

 

[RMerlin]

Still, I would think that the lease page would be a problem if/when IPV6 addresses are allowed to be assigned by Asus. I don't know which would be more efficient for you (Asus parser, or your own), but for your own, you could always stop at the duid line as I believe it consistently separates IPV4 from IPV6 addresses.

If Asus ever add real DHCPv6 capabilities, they will no doubt update their parser, so at that point I will easily be able to do the same.

The current Asus parser will skip any line that does not begin with a numerical value (skipping the duid line) as well as any line that has an IPv6 IP in the IP field. This is more reliable than having it stop parsing after the duid line, in case the dnsmasq author were to change that behaviour in the future.

One other thing, this the beta2 update appears to have cleared the ipv6_neighsol_drop=1 from NVRAM.

That setting was removed, and replaced with ipv6_ns_drop back in April, so I could have it use the new default value of "0". It was documented in the changelog of that release.

 

[RMerlin]

But with the 5 GHz, I have a strange behavior on my Google Nexus 5 smartphone:
The connection is not stable, in the middle of a speed test it disconnects from the N68U router and connects to the N66U 5GHz network.
The speed during the test is only 50-75% of my 150 MBit download max.

Try disabling Beamforming. My Nexus 4 never really liked it either.

 

[ydc]

Working as designed.

i.e. if you boot the router and never open the VPN tunnel then the VPN clients will never access the WAN (even though the VPN tunnel has never been physically UP) if you have the option selected.

This ensures there is no WAN 'leak' for VPN clients whose traffic/surfing activity must ALWAYS be 'hidden' by the (usually) encrypted VPN.

I suppose the wording of the option should be changed to "Always block WAN access for ALL routed clients if VPN is unavailable"

EDIT: You can always write a script that is manually ONLY called by you to shut the tunnel down and subsequently temporarily remove the RPDB selective routing rule for the client (to allow WAN access), then use a similar rule to reinstate the WAN blocking rule when you manually re-open the VPN tunnel.

Thanks. I really don't have a need for that feature at this time but was just experimenting.

Your suggestion is a good one though and maybe would be good to add to the wiki. I'll play around with it some and come up with a script.

Sent from my Nexus 6 using Tapatalk

 

[Coldfire26]

Had an issue with both of the 378.55 betas on the AC87R where it would randomly disconnect wifi from one of my laptops. It would only be for a few seconds and it would come back up right away without me having to do anything, but it would happen every 10-15 minutes. Tried every single version of the wireless drivers I could find on the Intel website and manufacturer's website but they all acted the same way/ Works fine with 378.54 so I reverted back to that for now but wanted to make a post in case it was not a known issue ( Could not find anything with my google-fu skills about it )

 

[Deleted member 22229]

Had an issue with both of the 378.55 betas where it would randomly disconnect wifi from one of my laptops.

It would help if you mentioned what model router your using.

 

[Coldfire26]

I would help if you mentioned what model router your using.

edited post to include router model

 

[hggomes]

What band? You should be more detailed about your specific issue.

 

[Coldfire26]

What band? You should be more detailed about your specific issue.

both bands are having the same issue. Reset up router back up from scratch with same issue. Tried different channels and different encryption settings for testing. Happens even as an open network

 

[hggomes]

Intel AC7260? My first advice to you is test a different client, such as a smartphone, notebook, etc and check if same issue happens, i know you reported .54 as working correctly but this way you will have a clue if its a general issue or an isolated case on .55.

Good luck

 

[Coldfire26]

Intel AC7260? My first advice to you is test a different client, such as a smartphone, notebook, etc and check if same issue happens, i know you reported .54 as working correctly but this way you will have a clue if its a general issue or an isolated case on .55.

Good luck

The one with the issues is an Intel N 6205. I have tried multiple other clients ( Phones, tablets, gaming consoles etc) just to make sure it was an isolated issue and it was. I actually have 2 different laptops in my office and the one in question would be the only one to lose connection. The weird part is that the wireless icon would stay connected with full signal strength and no errors. I talked to a buddy of mine and he is having the same issue ( Same router), but his wifi card is an Intel N 2200. Every other wireless device works fine for him as well.

 

[hggomes]

Simple, dont use Intel Wireless Manager Application, remove all Intel software from the computer and install only the drivers so the OS can control the wireless connections and not Intel , that issue is not new on Intel WNICs.

You can also go to Device Manager => Networking => Intel N6205 Wireless Card => Advanced Settings and tweak some options and do some extra testing.

 

[Coldfire26]

Simple, dont use Intel Wireless Manager Application, remove all Intel software from the computer and install only the drivers so the OS can control the wireless connections, that issue is not new on Intel WNICs.

You can also go to the Advanced Settings and tweak some options and do some extra tests.

Oh trust me, the intel software was never part of the equation hehe. I just unpacked the drivers and manually installed the required files using device manager. But I will try and play around with the advanced settings to see if they make a difference. I have been using the merlin fw for a while now ( have gone through 3 asus router) and I never had an issue like this, so I just wanted to let someone know just in case. I appreciate all your help

 

[hggomes]

You are welcome, i also notice the same issue recently on my Intel AC7260 card on FW 378.55 version, but the disconnects were random and not so often, which seems different from your case, i changed the option CTS-to-SELF to RTS/CTS and it got fixed right away, so far so good, i also changed from HT (limited to 300MBps) to VHT (now at 866MBps), so i guess you are also on the right way to solve your issue.