Asuswrt-Merlin 374.40 Beta 2 is available

[RMerlin]

Yup, you're right. It's not DNS. But I found the problem. The FORWARD chain is defaulting to DROP in .40, but its ACCEPT in .39.

It has been set to DROP for more than a year now:

commit c1cef682061ee167cfa237258fb384b81e1ac629
Author: Eric Sauvageau <rmerl@lostrealm.ca>
Date:   Sat Feb 23 17:27:44 2013 -0500

    Fix cdrouter firewall_2 - we now drop FORWARD packets by default, but accept forwarded packets lan2wan

However I had only applied that fix to the regular and failover mode, and had forgotten to also apply it to load balancing mode - which was fixed recently at the same time I fixed the firewall not setting the default policy to ACCEPT when the firewall is disabled.

If you have it set to load balancing and your packets are dropped then there's a good chance that something's odd about your network environment. You will have to check why traffic isn't matching one of the FORWARD rules in the chain. For this, enable logging of dropped packets on the webui, then check your system log to see the logged dropped packets.

 

[KevTech]

With this beta and the 3.0.0.4.374.4561 stock firmware if I set the 5GHz channel to N only with bandwidth 40 only I can not set the channels as the dropdown is blank.

Going back to Merlin 39 or stock 3.0.0.4.374.4422 resolves the issue.

 

[L&LD]

KevTech, I see the same thing with my RT-N66U but I am positive that I initially set it as I wanted (channel 44)?

 

[RMerlin]

KevTech, I see the same thing with my RT-N66U but I am positive that I initially set it as I wanted (channel 44)?

What region are you in? I'm unable to reproduce this specific issue here. It might however be related to a separate issue I recently fixed that would cause some channels to be missing.

Give Beta 2 build a shot to see if it was the same issue that was fixed in it (I'm hoping to be able to upload this new build later tonight).

 

[Grump]

However I had only applied that fix to the regular and failover mode, and had forgotten to also apply it to load balancing mode - which was fixed recently at the same time I fixed the firewall not setting the default policy to ACCEPT when the firewall is disabled.

If you have it set to load balancing and your packets are dropped then there's a good chance that something's odd about your network environment.

I was playing with dual wan a while ago but I turned it off.
Enable Dual WAN: Off
Primary WAN: WAN
Dual WAN Mode: Load Balance

I just toggled the mode to Fail Over and it's fixed, even though Dual WAN is still disabled.

This added another rule to the end of the FORWARD chain.

ACCEPT     all  --  anywhere             anywhere

Glad we could get to the bottom of this. Bug report! Thanks for the help!

 

[RMerlin]

I was playing with dual wan a while ago but I turned it off.
Enable Dual WAN: Off
Primary WAN: WAN
Dual WAN Mode: Load Balance

I just toggled the mode to Fail Over and it's fixed, even though Dual WAN is still disabled.

This added another rule to the end of the FORWARD chain.

ACCEPT     all  --  anywhere             anywhere

Glad we could get to the bottom of this. Bug report! Thanks for the help!

Use the -v flag, as what you see is not the complete rule.

iptables -L FORWARD -v

I doubt it's just an accept all from anywhere to anywhere, there's probably some interfaces specified there:

2113  278K ACCEPT     all  --  any    any     anywhere             anywhere             ctstate DNAT
 4501  235K ACCEPT     all  --  br0    any     anywhere             anywhere

 

[Grump]

Use the -v flag, as what you see is not the complete rule.

iptables -L FORWARD -v

I doubt it's just an accept all from anywhere to anywhere, there's probably some interfaces specified there:

2113  278K ACCEPT     all  --  any    any     anywhere             anywhere             ctstate DNAT
 4501  235K ACCEPT     all  --  br0    any     anywhere             anywhere

Ya so this rule is missing if dual wan mode is set to fail over, even when enable dual wan is disabled.

 2518  158K ACCEPT     all  --  br0    any     anywhere             anywhere

 

[RMerlin]

Ya so this rule is missing if dual wan mode is set to fail over, even when enable dual wan is disabled.

 2518  158K ACCEPT     all  --  br0    any     anywhere             anywhere

Fixed: https://github.com/RMerl/asuswrt-merlin/commit/d5bd5900d028ac85227fab0c805f7e3dd9db2e60

 

[bluepoint]

KevTech, I see the same thing with my RT-N66U but I am positive that I initially set it as I wanted (channel 44)?

Same thing here. Initially you can set the static channel and bandwidth @40MHz but once you applied, the channel dropdown disappears. For the channels to re-appear, you need to change the bandwidth channels to 20/40. Ill check later, Merlin has the fix in beta2 I think.

 

[RMerlin]

Beta 2 has been uploaded to Mediafire.

374.40 Beta 2 (5-March-2014)
   - FIXED: Numerous buffer overruns in networkmap that would result
            in crashes or empty/incomplete device list.  Was often 
            visible on networks hosting a Windows Home Server machine.
   - FIXED: Site survey was reporting 5G as being disabled on RT-N16.
   - FIXED: Various issues related to the helper.sh script for postconf
   - FIXED: The OpenVPN instance wasn't restarted if it was currently 
            stopped due to a syntax error in its config and you had 
            just corrected it.
   - FIXED: Restarting the wireless service would stop emf/igs snooping
            until they were manually restarted/recconfigured.
   - FIXED: Channels above 153 were missing on 5 GHz band if width
            is set to 40 MHz (Asus bug)
   - FIXED: reg_mode was being enforced to "h" (EU region) or "off"
            (others) since GPL 4422.  We now stick again to what's 
            set in the webui by the end user.
  - FIXED: Allow LAN traffic while dualwan mode is set to lb (issue
           caused by the default policy fix in beta 1)

 

[cmillar6]

I see channel 157 now in 40 MHz mode but channel 161 is still missing?

 

[RMerlin]

I see channel 157 now in 40 MHz mode but channel 161 is still missing?

Probably because 161 + 157 would be redundant to 157 + 161.

 

[bluepoint]

Same thing here. Initially you can set the static channel and bandwidth @40MHz but once you applied, the channel dropdown disappears. For the channels to re-appear, you need to change the bandwidth channels to 20/40. Ill check later, Merlin has the fix in beta2 I think.

Not fixed in Beta 2 including regulation mode(defaults to off even when enabled in 2.4Ghz band).
What's odd is after I click apply to change the bandwidth to 40 and a static channel(control) the WEP key entries appears even if I'm using WPA2-AES personal. Same behavior in beta 1.

 

[vdemarco]

Beta 2 has been uploaded to Mediafire.

374.40 Beta 2 (5-March-2014)
   - FIXED: reg_mode was being enforced to "h" (EU region) or "off"
            (others) since GPL 4422.  We now stick again to what's 
            set in the webui by the end user.

The driver for the RT-AC66u looks like it was downgraded,
I just noticed that you did that purpose (sorry about that, and looking at it more, this was a good thing, thanks)

Regulation mode for 2.4Ghz doesn't stick, you can set it to anything and the pop up goes back to disabled.

Any plans of incorporating the new miniupnp daemon???

I have a ton of logs on the router in the form of
Mar 5 19:43:56 miniupnpd[533]: unsupported NAT-PMP version : 2

which is my Mac sending a Port Control Protocol message, failing then falling back to NAT-PMP because the router doesn't support it. i think the latest miniupnpd supports PCP.

 

[vdemarco]

Probably because 161 + 157 would be redundant to 157 + 161.

I have the channel set to 159+161, but don't see 159 or 161 in the popup.

 

[RMerlin]

The driver for the RT-AC66u looks like it was downgraded,
the new version is
wl0: Oct 25 2013 15:16:08 version 6.30.163.2002 (r382208)

Yes, just looking for some blind test results.

Regulation mode for 2.4Ghz doesn't stick, you can set it to anything and the pop up goes back to disabled.

GDI, it was working fine two nights ago after I changed that code... Sigh.

Any plans of incorporating the new miniupnp daemon???

Not in the near future. There is nothing in the recent versions worth upgrading to.

I have a ton of logs on the router in the form of
Mar 5 19:43:56 miniupnpd[533]: unsupported NAT-PMP version : 2

which is my Mac sending a Port Control Protocol message, failing then falling back to NAT-PMP because the router doesn't support it. i think the latest miniupnpd supports PCP.

PCP support is not in the plans, as that code doesn't compile properly yet, plus it's still very experimental. And since so far nobody but Apple supports this protocol, I see no point in spending time on this.

 

[RMerlin]

I have the channel set to 159+161, but don't see 159 or 161 in the popup.

Trying to understand Asus's channel manipulation code is a PITA. They have no less than 369 lines of code devoted strictly to adjusting what channels are available and which one to remove based on a bunch of factors. So debugging that code is even more annoying. Looks like once I fix a bug in it, another one creeps up... Starting to be tired of fighting with this, I might just let them sort it out since it's broken in their own firmware too.

 

[pilotboy72]

Running both RT-AC66 and RT-N66U (comments apply to both).

Looks like the "Protected Management Frames" configuration doesn't stick and goes back to "Disabled" regardless of other settings.

Also, using WiFi Explorer on my Mac, I'm seeing that the channel bandwidth is not sticking. I have it set to 40MHz for both 2.4 GHz and 5GHz on both routers and the 2.4GHz band is seeing only 20MHz bandwidth. Is the setting being ignored?

--Brian

 

[RMerlin]

Running both RT-AC66 and RT-N66U (comments apply to both).

Looks like the "Protected Management Frames" configuration doesn't stick and goes back to "Disabled" regardless of other settings.

No idea what this option does and on which models it applies, so I'm leaving this one to Asus.

Also, using WiFi Explorer on my Mac, I'm seeing that the channel bandwidth is not sticking. I have it set to 40MHz for both 2.4 GHz and 5GHz on both routers and the 2.4GHz band is seeing only 20MHz bandwidth. Is the setting being ignored?

Wifi specifications dictates that a router must downgrade to 20 MHz if there's any overlapping channel.

 

[RMerlin]

I have the channel set to 159+161, but don't see 159 or 161 in the popup.

No idea where that'd be from, since 159 is not a valid channel. It's probably 157+161 rather.