Asuswrt-Merlin 374.40 Beta 2 is available

[Grump]

With "router", clients will use the DNS server from the router's WAN settings, and will not be able to bypass it - they will be forced to use it.

With "none", clients will use the DNS server from the router's WAN settings, but they will also be able to specify their own DNS servers in their local network configuration.

With .40, no matter what settings I use (DNS filter disabled, DNS filter enabled > Global:None, Client:None) I can't specify my own DNS servers on client machines. All DNS traffic is filtered regardless of filter setting. I can query the router directly. Rebooting did not help. Going back to .39 resolves the issue.

I played with the DNS filter when .39 was released, but I shut it off because I didn't need it. There may be residual settings. I did not try factory reset as I'm accessing my network remotely at this time.

RT-AC66U

 

[murph2481]

Random Reboot today after 24 hours stable

Well everything was going fine with this version then today randomly the router restarted itself. I have flashed to factory default but that was a while ago (did it for .38 but went back to .35 because of IPv6 issues, then back to .39 now .40beta1) if it keeps rebooting might try that again.

Signal Strength on both bands is good and good throughput but surprised by the random reboot today

router: RT - N66U

 

[Chrysalis]

Ok done some diagnostics.

Manually selecting channel 36,40,44,48 upwards to 64 shows channel 36 in the wifi logo, its as if all channels from 40 to 64 broken. If I select any of the lower 5ghz channels I get connection speeds on AC of around 120-160. Ouch

If I select auto channels it picks 132 + 136 very very bizzare as they are very high, then my AC dongle only gets 1-2 bars but still manages 400mbps. If I select 40mhz width so I assume dropping back to N only, it connects at 270-300mbps. (note on previous firmware it gets 866 its max using lower channels)

So this firmware on AC on lower channels = screwed sadly

About to downgrade back to previous firmware to try and confirm its screwed in this version.

 

[RMerlin]

With .40, no matter what settings I use (DNS filter disabled, DNS filter enabled > Global:None, Client:None) I can't specify my own DNS servers on client machines. All DNS traffic is filtered regardless of filter setting. I can query the router directly. Rebooting did not help. Going back to .39 resolves the issue.

I played with the DNS filter when .39 was released, but I shut it off because I didn't need it. There may be residual settings. I did not try factory reset as I'm accessing my network remotely at this time.

RT-AC66U

Run the following commands to see what's the current state of DNSFilter on your router:

nvram show | grep dnsfilter_
iptables -t nat -L -v

 

[Chrysalis]

Ok done some diagnostics.

Manually selecting channel 36,40,44,48 upwards to 64 shows channel 36 in the wifi logo, its as if all channels from 40 to 64 broken. If I select any of the lower 5ghz channels I get connection speeds on AC of around 120-160. Ouch

If I select auto channels it picks 132 + 136 very very bizzare as they are very high, then my AC dongle only gets 1-2 bars but still manages 400mbps. If I select 40mhz width so I assume dropping back to N only, it connects at 270-300mbps. (note on previous firmware it gets 866 its max using lower channels)

So this firmware on AC on lower channels = screwed sadly

About to downgrade back to previous firmware to try and confirm its screwed in this version.

Ok I hope this helps merlin its better than just saying wifi got weakened, I believe the .40 build is buggy in this respect.

I reverted back to Firmware:3.0.0.4.374.35_4 and I can confirm now when I hover on the wifi logo top right it says channel 36+ 42 and if I eg. change to 40 it says 40 + 42, so works properly again. I think that extra option that appears for extension channel? which is always set to auto may be related to this. However my AC dongle hasnt reverted to 866mbps only is 580mbps now but that of course beats the sub 200mbps I was getting on the new firmware. I suspect since I downgraded I probably need to reset all my settings now.

 

[Grump]

Run the following commands to see what's the current state of DNSFilter on your router:

nvram show | grep dnsfilter_
iptables -t nat -L -v

Flashed .40 again, same symptoms. Affects all clients. I can do nslookups to the custom DNS servers from the router no problem. Went back to .39 and my clients work again.

Those commands look the same on both versions. (router is .2 and client is .1 in case it looks weird,)

admin@Router:/tmp/home/root# nvram show | grep dnsfilter_
dnsfilter_rulelist=
dnsfilter_custom1=
dnsfilter_custom2=
dnsfilter_custom3=
dnsfilter_mode=0
size: 49128 bytes (16408 left)
dnsfilter_enable_x=0

admin@Router:/tmp/home/root# iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 428 packets, 30685 bytes)
 pkts bytes target     prot opt in     out     source               destination
   11  1309 VSERVER    all  --  any    any     anywhere             my.public.hostname

Chain POSTROUTING (policy ACCEPT 111 packets, 11567 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MASQUERADE  all  --  any    eth0   !my.public.hostname  anywhere
    0     0 MASQUERADE  all  --  any    any     anywhere             anywhere            MARK match 0xd001

Chain OUTPUT (policy ACCEPT 100 packets, 10258 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain DNSFILTER (0 references)
 pkts bytes target     prot opt in     out     source               destination

Chain LOCALSRV (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain VSERVER (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:https to:192.168.0.2:443
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:8082 to:192.168.0.2:8082
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:bootps to:192.168.0.2:67
    0     0 DNAT       udp  --  any    any     anywhere             anywhere            udp dpt:bootps to:192.168.0.2:67
    0     0 DNAT       tcp  --  any    any     anywhere             anywhere            tcp dpt:bootpc to:192.168.0.2:68
    0     0 DNAT       udp  --  any    any     anywhere             anywhere            udp dpt:bootpc to:192.168.0.2:68
   11  1309 VUPNP      all  --  any    any     anywhere             anywhere
   11  1309 LOCALSRV   all  --  any    any     anywhere             anywhere
   11  1309 DNAT       all  --  any    any     anywhere             anywhere            to:192.168.0.1

Chain VUPNP (1 references)
 pkts bytes target     prot opt in     out     source               destination
admin@Router:/tmp/home/root#

 

[Builder71]

I'm no expert with iptables, but if I compare your output with mine, it seems to me you don't have any dnsfilter leftovers configured.

Over here I see "dnsfilter_mode=11" and "dnsfilter_enable_x=1".
And the "Chain DNSFILTER" section shows three MAC addresses from devices I configured for dns filtering.

On your clients, you configured a public dns ip address on the NIC and did a ipconfig /flushdns?
As you can read here, that works fine for me with the proper router settings.

Maybe somebody else with a RT-AC66U, using dnsfilter, can chime in?

Edit: One thing I do notice is if I type "nslookup" on the client, it does show:
(The client with DNS 8.8.8.8 on the NIC.)

C:\Users\Papa>nslookup
Default Server:  google-public-dns-a.google.com
Address:  8.8.8.8

>

However if the router is set for "Filter Mode -> router", on this specific client, it is still forced to use the routers DNS. How cool is that!
So yes, the client shows google dns on "nslookup" but it is still forced to use the router.

nslookup will give the answer to e.g. www.playboy.com

C:\Users\Papa>nslookup
Default Server:  google-public-dns-a.google.com
Address:  8.8.8.8

> www.playboy.com
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    playboy.com
Address:  66.254.102.216
Aliases:  www.playboy.com

>

But if I type this IP address into the clients browser it still says the site is blocked.
That is because I use OpenDNS on the WAN page which I configured to not allow adult stuff.

Amazing piece of work RMerlin.

 

[Ritzie]

Ac66u

So far so good. I flashed the AC68U and the AC66U with the latest beta build. The AC66U is running in media bridge mode. The alert is telling me to fix the 2.4G wireless settings but I cannot access it.

 

[cyborgpunte]

Weird , getting this now on my RT-AC68U with .40B1 never on .39

I know when it happens because routers switches (dualwan) to my 3G dongle,
wich give me slower internet. Some days occuring 1-2 times some none.

WAN Connection: ISP's DHCP did not function properly.

have done a wife friendly quick'n'dirty
with TeraTerm Macrofile "ifconfig ppp0 down"

contact ISP or try .39 again ????

 

[RMerlin]

Flashed .40 again, same symptoms. Affects all clients. I can do nslookups to the custom DNS servers from the router no problem. Went back to .39 and my clients work again.

There's no firewall rule at all related to DNSFilter in your firewall, so your problem is definitely not caused by it.

 

[RMerlin]

So far so good. I flashed the AC68U and the AC66U with the latest beta build. The AC66U is running in media bridge mode. The alert is telling me to fix the 2.4G wireless settings but I cannot access it.

Asus's notification system has been rushed out to address the widespread complains from people failing to securely configure their router, so it has quite a few quirks. Just ignore the message, or revert back to Router mode, change your settings, and set it back to Media Bridge.

 

[bodean]

Seems by the number of posts that there is a speed decrease for wifi and wlan connections on this firmware. Hopefully it gets sorted out by the release build.

 

[Ritzie]

Asus's notification system has been rushed out to address the widespread complains from people failing to securely configure their router, so it has quite a few quirks. Just ignore the message, or revert back to Router mode, change your settings, and set it back to Media Bridge.

Ok thanks.

 

[joegreat]

Seems by the number of posts that there is a speed decrease for wifi and wlan connections on this firmware. Hopefully it gets sorted out by the release build.

I have no WLAN speed issues with my two routers on version 40_Beta1 - all (capable) clients can tranfer to internet at full speed (100/10 MBit) and great speed in the local network!

The only observation, is that the WLAN signal levels of the AC68U router are very low - but no problems with it as I only use devices in the living room (no walls in between) - which might be the reason: Maybe beamforming and power management reduces the WLAN transmit power as its not needed.

By the way: I have also no reboot issues with my AC68U router! Uptime shows 3 days 23 hours - since I installed 40_Beta1.
Maybe the reboot is tight to AiCloud or Download Manager, which I do not use.

With kind regards
Joe

 

[Qinn]

Hi I'm using 3.0.0.4.374.35_4 Merlin Build on ASUS RT-N16 in AP mode using 2 x 1 gb USB drives. First I wanna say Thnx to Merlin for some good product! I tried many version of DD-WRT like BS 2.6 even ported it to 3.x, Kong and Tomato (also many versions). The only one that was stable was the Kong build 22000, but USB speed was limited at 1 -1,5 mb/s with the Merlin build it went up to 2-3 mb/s. Tried the OFW, but speeds were the same as Kong. So I stayed with Merlin.

I use Merlin's build since a week and must say it's very stable. There is just one recurring error. After, say roughly, 72 hours I get the locked out screen says settings were changed, but I didn't change anything. The AP still functions and all clients have network access, only the AP settings are locked out and showing the message that settings are changed. I don't have telnet open (yet) so I can only power off and then all is well again. I tried the latest RT-N16_3.0.0.4_374.40_beta1 and report back that USB speeds are as unstable and slow as the ASUS OFW.

 

[Builder71]

Seems by the number of posts that there is a speed decrease for wifi and wlan connections on this firmware. Hopefully it gets sorted out by the release build.

Not that I noticed.
Be more specific.

 

[GoNz0]

just had a reboot spinning up the usb hdd after i paused a film long enough for it to spin down.

any news on the bug with it not mounting the usb hdd even though it recognises it ?

 

[allenlux]

Seems by the number of posts that there is a speed decrease for wifi and wlan connections on this firmware. Hopefully it gets sorted out by the release build.

I don't think that is true for the RT-N66U. I don't recall reading of speed issues on this model, and on mine the performance is, if anything, better than before.

 

[Chrysalis]

Not that I noticed.
Be more specific.

I was very specific and not a single reply.

5ghz is hosed on .40 on my ac66.

 

[Grump]

There's no firewall rule at all related to DNSFilter in your firewall, so your problem is definitely not caused by it.

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. Once I manually changed the policy (iptables -P FORWARD ACCEPT) my clients could connect again. If I click APPLY on the firewall page without changing anything, it defaults back to DROP and my clients have no internet.

Firewall General
Enable Firewall: Yes
Enable DoS Protection: No
Logged packets: None
Respond Ping: Yes

URL Filter: Disabled
Keyword Filter: Disabled
Network Services Filter: No
IPv6: Yes

Parental Control: Off
DNS Filtering: Off

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere            state INVALID
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            state NEW
ACCEPT     all  --  anywhere             anywhere            state NEW
ACCEPT     udp  --  anywhere             anywhere            udp spt:bootps dpt:bootpc
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:8082
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https
ACCEPT     icmp --  anywhere             anywhere
DROP       all  --  anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination
ipttolan   all  --  anywhere             anywhere
iptfromlan  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere            state INVALID
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere            ctstate DNAT

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain FUPNP (0 references)
target     prot opt source               destination

Chain PControls (0 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain iptfromlan (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere            account: network/netmask: 192.168.0.0/255.255.255.0 name: lan

Chain ipttolan (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere            account: network/netmask: 192.168.0.0/255.255.255.0 name: lan

Chain logaccept (0 references)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere            state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `ACCEPT '
ACCEPT     all  --  anywhere             anywhere

Chain logdrop (0 references)
target     prot opt source               destination
LOG        all  --  anywhere             anywhere            state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `DROP '
DROP       all  --  anywhere             anywhere

Need any other info?