[CLOSED] Asuswrt-Merlin 378.50 Beta 1 is out

[RogerSC]

I did notice one thing about IPv6 on 50_Beta that I wanted to mention. With previous RMerlin firmware for the Asus RT-AC68P, like 376_49.*, I got a score of 19/20 on the "IPv6 Connectivity and Speed Test". This means, according to the test, that the firewall provided by the firmware is not filtering out ICMPv6 packets intended for the computers behind it. This seems like a good thing.

When I ran that test on 50_Beta firmware, I got a score of 17/20, which means that ICMPv6 packets are being filtered out. Which, they say, can cause problems.

Just wanted to make note of this in case this was something that hadn't yet been carried forward from the 376_49.* firmware to the 378_50 firmware that could be carried forward.

Thanks.

 

[morinzo]

The RT-AC56U is a 2x2 router, so the maximum supported link rate is 866 Mbps. I doubt you were getting 900+ Mbps with that router.

Additional channels might be because DFS was added by Asus. I don't know at which point they added it to the RT-AC56U.

Try using channel 36 to see if the link rate goes back closer to 866.

It was between 800 & 900, why isn't the channel saving correctly when i apply it??

The newest Asus fw didn't have the extra channels..

 

[jerry6]

n-66 , on wireless network there is no longer mac filter list for2.4 band and a separate list for 5.0 band , now just a mac filter list for all wireless , is this the new norm or is there a problem here ? Am I supposed to have a mac filtre list for each band like before ?
I had each band with different clients allowed on each band , now any client allowed on the network can jump on any band , not ideal , in my case at least .

Thanks

 

[RMerlin]

It was between 800 & 900, why isn't the channel saving correctly when i apply it??

The newest Asus fw didn't have the extra channels..

As intentioned, the DPI engine requires me to use the wireless driver intended for a different router model, so those type of issues aren't unexpected. That's why this is being tested with a beta release.

 

[RMerlin]

n-66 , on wireless network there is no longer mac filter list for2.4 band and a separate list for 5.0 band , now just a mac filter list for all wireless , is this the new norm or is there a problem here ? Am I supposed to have a mac filtre list for each band like before ?
I had each band with different clients allowed on each band , now any client allowed on the network can jump on any band , not ideal , in my case at least .

Thanks

This was deliberately changed by Asus. No idea what was the particular reason, but I saw them write code specifically intended to hide the field, and reproduce the existing MACs into one single list. I can only assume it wasn't working properly.

 

[RMerlin]

I did notice one thing about IPv6 on 50_Beta that I wanted to mention. With previous RMerlin firmware for the Asus RT-AC68P, like 376_49.*, I got a score of 19/20 on the "IPv6 Connectivity and Speed Test". This means, according to the test, that the firewall provided by the firmware is not filtering out ICMPv6 packets intended for the computers behind it. This seems like a good thing.

When I ran that test on 50_Beta firmware, I got a score of 17/20, which means that ICMPv6 packets are being filtered out. Which, they say, can cause problems.

Just wanted to make note of this in case this was something that hadn't yet been carried forward from the 376_49.* firmware to the 378_50 firmware that could be carried forward.

Thanks.

Can you try disabling the IPv6 firewall to see what happens when you re-test? I haven't noticed if Asus changed the default firewall rules.

 

[RogerSC]

Can you try disabling the IPv6 firewall to see what happens when you re-test? I haven't noticed if Asus changed the default firewall rules.

Interesting, that gave me 19/20, without the firewall. Then when I re-activated the firewall, 19/20 again. I guess all I needed to do was to toggle the firewall and it fixed itself *smile*. Doesn't make a lot of sense, but so it goes, I guess. Maybe the rules weren't fully applied the first time around, and the second time was the charm?

 

[RMerlin]

I had already restarted the PC and service, but 2.02 is not used after all, 1.50 instead. 3.02 with others Win8.1 PCs



thank Merlin.

Works for me:

Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. All rights reserved.

PS C:\WINDOWS\system32> Get-SmbConnection

ServerName          ShareName           UserName            Credential          Dialect             NumOpens
----------          ---------           --------            ----------          -------             --------
stargate87          Share (at KT410)    AVALON\Merlin       AVALON\Merlin       2.0.2               1

Did you also restart Samba on the router?

 

[RMerlin]

Interesting, that gave me 19/20, without the firewall. Then when I re-activated the firewall, 19/20 again. I guess all I needed to do was to toggle the firewall and it fixed itself *smile*. Doesn't make a lot of sense, but so it goes, I guess. Maybe the rules weren't fully applied the first time around, and the second time was the charm?

That's possible. Or, something else had changed the rules at some point.

If you ever get to reproduce it, check what rules are currently in place, with ip6tables -L -v .

 

[RMerlin]

Hi Merlin,
I found in "/etc/resolv.conf", there's only one line "nameserver 127.0.0.1". I wonder if it's what makes adding "strict-order" to dnsmasq.conf render pinging from router unusable, because according to the man page of dnsmasq, it says "Setting this flag forces dnsmasq to try each query with each server strictly in the order they appear in /etc/resolv.conf".
Thx

------------edit------------
With "strict-order" on.
After I append "nameserver 208.67.220.220" to /etc/resolv.conf and send a SIGHUP to dnsmasq to force it to reload /etc/resolv.conf, ping can work from router, but the interval between issuing the ping command and getting the response from it is abnormal, about 4-5 seconds(it's not the long pinging time, pinging time being normal like 23ms.)
If I remove "nameserver 127.0.0.1" from it and only leave "nameserver 208.67.220.220" in /etc/resolv.conf, and let it reload the /etc/resolv.conf, then the behavior of ping back to normal, very quick response from ping command.
It's like dnsmasq gets stuck if both "nameserver 127.0.0.1" and "strict-order" are there. And if there's only "nameserver 127.0.0.1" in resolv.conf accompanied with "strict-order", all pinging from router would get responded with "Bad Address" if that address is not cached, like a deadlock.

The reason why resolv.conf uses 127.0.0.1 is because we want to force the router to always use dnsmasq for name resolution. That way, it will use whatever nameservers are configured in dnsmasq itself.

I'd suggest checking which servers are used by dnsmasq, as it's possible that one on its list isn't working properly.

 

[SeCrEt_BoY]

@RMerlin: Do you know how to enable IGMP for IPTV??? I cant watch IPTV of my ISP...

 

[snapilica2003]

@RMerlin: Do you know how to enable IGMP for IPTV??? I cant watch IPTV of my ISP...

Isn't there a IGMP Proxy and IGMP Snooping setting in a dedicated "IPTV" tab in LAN settings?


In other news I've done the upgrade, and manually setup everything. I've also enabled adaptive QoS and tinkered with it for a bit. There's no visible fall in performance so I will leave it on for a while to make a better idea.

PS: It seems that the changes made in the Dual WAN stuff is also visible. From my limited tests it finally works as it should, with failover actually working this time. Great job!

 

[charlie2alpha]

Regarding the RT-AC56U and the 5GHz issues with the DPI build, it occurred to me that there is one thing I seem to have done differently from the users that have problems. Before I flash the 378 beta I backed up my settings with the nvram save & restore utility by john9527 from here. To be even safer, I used it in migration mode.

After I flashed this beta, I performed the restore procedure and rebooted. Perhaps that is why, as far I can tell from this forum thread, I am the only only with 5GHz working properly and with all the channels available.

What I suggest to users that already went to the non-DPI build, try to save your settings with the utility, then flash the DPI build, reset, and the restore with the utility. If someone tests this, please report it.

 

[RMerlin]

What I suggest to users that already went to the non-DPI build, try to save your settings with the utility, then flash the DPI build, reset, and the restore with the utility. If someone tests this, please report it.

I actually re-tested it on my AC56U tonight. With my CFE set to the proper US region, I had access to the usual channels, and my Nexus 9 had no problem connecting at about 585 Mbps (the test router was in another room, and lying half-disassembled on its face, so, not the ideal setup).

People with additional channels are probably folks who live in a region (EU) where DFS is available, which unlocks additional channels.

 

[charlie2alpha]

I actually re-tested it on my AC56U tonight. With my CFE set to the proper US region, I had access to the usual channels, and my Nexus 9 had no problem connecting at about 585 Mbps (the test router was in another room, and lying half-disassembled on its face, so, not the ideal setup).

People with additional channels are probably folks who live in a region (EU) where DFS is available, which unlocks additional channels.

Interesting, my CFE is indeed the EU version, probably the other users who reported extra channels too. But they also reported inability to select the channels properly plus bandwidth problems while I have no such issue.

 

[cyborgpunte]

clkfreq

Is it possible to overclock 378.50_beta1 on a RT-AC68U with CFE 1021, by edit CFE ???
Values now are 800,666, what values do you recomend, or should I buy a cooling fan first ???
Temperatures 2.4 GHz: 52°C - 5 GHz: 55°C - CPU: 75°C

 

[ligeza]

With the newest Merlin and asus firmware a have problem with upload speed in LAN when I set Adaptive QOS to "Upload Bandwidth 0,8 Mb/s
Download Bandwidth 2,5 Mb/s" My upload speed with this parameters to NAS is about 3-7 MB/s but when I change "Upload Bandwidth to 10 Mb/s" it instantly grow up to 40MB/s. I have RT-AC68U.

Is it possible to overclock 378.50_beta1 on a RT-AC68U with CFE 1021, by edit CFE ???
Values now are 800,666, what values do you recomend, or should I buy a cooling fan first ???
Temperatures 2.4 GHz: 52°C - 5 GHz: 55°C - CPU: 75°C

I have 1000,800 on a RT-AC68U with CFE 1.0.2.0 and my temperatures are:
2.4 GHz: 52°C - 5 GHz: 54°C - CPU: 74°C

 

[alby258]

I have noticed a problem with nat acceleration on: when is on, I can't reach my nas web interface and smb from wifi, but works well on ethernet. Surprised me that I can reach the web interface from wifi only using my asus ddns address.
With nat acceleration off I can reach the web interface and smb from wifi and from ethernet.

Another issue: with nat acceleration on, my nas can't connect to the internet. With nat acceleration off everything went well.
My hardware is AC68U, Netgear ReadyNas 104 connected with link aggregation.

Any advice?

 

[jernau]

RT-N66U Broken FTP

If you use IPv6 then check the second post of this thread with the list of known issues.

Thanks for the feedback (and the rather excellent firmware !!), unfortunately I did try the postconf script for VSFTPD but using listen=NO simply results in VSFTPD not starting as this directive will attempt to run the daemon under inetd on a per connection basis rather than a standalone daemon. I also tried appending listen_ipv6=YES but this results in VSFTPD running but the same "421 Service not available, remote server has closed connection" when attempting to connect from a client. I do not use IPV6 and have this fully disabled


***UPDATE****

Just tried installing vsftpd via optware on the router (opkg install vsftpd-ext) which is the same version (3.02) as that included within the firmware but this version does work.

 

[RogerSC]

One piece of good news, haven't seen any of these weird messages in my system log using 50_Beta yet:

Dec 3 23:42:29 dnsmasq-dhcp[682]: DHCPSOLICIT(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09
Dec 3 23:42:29 dnsmasq-dhcp[682]: DHCPADVERTISE(br0) 00:01:00:01:1b:eb:4f:58:44:8a:5b:bc:44:09 no addresses available

and since I was getting about 16 of these a day with 376.49*, it seems that whatever was causing them has been killed. Or they're being filtered. Either way, nice not to have them filling up my log day after day *smile*.

Thanks to whoever fixed this!