[Beta] Asuswrt-Merlin 380.67 Beta is now available

[Xentrk]

Am having the same challenge. I'm using VyperVPN as the provider. Where should I set the "auth no-cache" in the vpn client?

Thanks in advance.

In the Custom Configuration section on the vpn client web GUI page.

 

[pietjepuk100]

In your VPN configure file before <ca> line, it usually has "ovpn" as file type if you export from router configure page.

In the Custom Configuration section on the vpn client web GUI page.

Thanks for the pointers. Somehow, when trying to adjust this the VPN was connected as it was before. I guess it must have been some thing on the providers side. Thanks anyway, appreciated.

 

[CristianM]

I have no control over hardware acceleration, it's closed source. Repeating the same thing multiple times is not gonna change the facts.

Eric,

First of all, please receive my warm appreciations for your very useful work!

When I discovered Merlin firmware I could prove many problems to the dealers which provided me my first router RT-AC68U that started to fail auto-negotiation for WAN ports after one year and a half of good behavior. Using the tab Tools I could prove and obliged the dealer to change the defective router with another one.

I understand that the control over hardware acceleration is closed source and cannot be changed. However, I would suggest that all your useful improvements to be implemented into the firmwares that do not present additional bugs like those reported by my post. I would suggest to avoid new Asus stock firmwares based on GPL 380_7743 for new Merlin firmwares. This might be a temporary decision, till when the mentioned bug will be fixed by Asus in a new stock firmware. Meanwhile, all the Merlin firmware users having high speed fiber Internet connection should be invited to check if the bug was fixed.

Once again, thank you for your help!

 

[RMerlin]

I would suggest to avoid new Asus stock firmwares based on GPL 380_7743 for new Merlin firmwares.

7743 addresses various issues, including security issues. This is the reason for the switch to 7743.

Note that 7743 works fine for many people, including myself. The limited number of people that have problems with code based on 7743 can still keep running 380.66, while the rest of us can move forward to 380.67. The security fixes that were added by myself are all present in the 380.66 updates that I released over the weeks - only those specific to Asus aren't. Some of their fixes to httpd in 7743 are in the closed source components, so I can't backport them to 380.66 (hence the need for 7743).

The fact is, for the majority of people, 7743 is an improvement. I don't want to hold back the majority because of a limited subset of users negatively affected by it - there isn't enough of them to justify it.

 

[oldgringo]

In added FTP TLS functionality is a small bug. After activation through the web interface I can find in vsftpd.conf two rows one with ssl_enable=NO and another one with ssl_enable=YES. The first row should disappear after TLS activation, I guess.

 

[RMerlin]

In added FTP TLS functionality is a small bug. After activation through the web interface I can find in vsftpd.conf two rows one with ssl_enable=NO and another one with ssl_enable=YES. The first row should disappear after TLS activation, I guess.

Good catch, fixed.

 

[john9527]

All 11 modules from "/lib/modules/2.6.36.4brcmarm/kernel/net/netfilter/ipset" are loaded. But "ip_set_hash_ipmac.ko" doesn't exist which I believe is the issue?

Also I can confirm the comment extension works on other distros, but I then I saw johns post in his thread;

Something new being tested on my fork.... Planning on including it for my next beta release.
Went through the tomato history (from where I did the original port), and they had removed support since it was causing random reboots. So far, am not seeing anything amiss with the latest ipset 6.32

@RMerlin - It's patching the kernel, so you'll have multiple levels to do. There may be a better way with depmod and adding directly from ipset_arm, but I wasn't able to get it to work.

admin@RT-AC68P-EC58:/tmp/home/root# modprobe -l | grep ipset
kernel/net/netfilter/ipset/ip_set_list_set.ko
kernel/net/netfilter/ipset/ip_set_hash_net.ko
kernel/net/netfilter/ipset/ip_set_hash_netiface.ko
kernel/net/netfilter/ipset/ip_set.ko
kernel/net/netfilter/ipset/ip_set_hash_ipmark.ko
kernel/net/netfilter/ipset/ip_set_hash_ipport.ko
kernel/net/netfilter/ipset/ip_set_hash_ipportip.ko
kernel/net/netfilter/ipset/ip_set_hash_ipportnet.ko
kernel/net/netfilter/ipset/ip_set_hash_ipmac.ko
kernel/net/netfilter/ipset/ip_set_bitmap_ipmac.ko
kernel/net/netfilter/ipset/ip_set_bitmap_port.ko
kernel/net/netfilter/ipset/ip_set_hash_netportnet.ko
kernel/net/netfilter/ipset/ip_set_hash_ip.ko
kernel/net/netfilter/ipset/ip_set_hash_netnet.ko
kernel/net/netfilter/ipset/ip_set_hash_mac.ko
kernel/net/netfilter/ipset/ip_set_bitmap_ip.ko
kernel/net/netfilter/ipset/ip_set_hash_netport.ko

admin@RT-AC68P-EC58:/tmp/home/root# modprobe ip_set_hash_ipmac

admin@RT-AC68P-EC58:/tmp/home/root# ipset create foo hash:ip,mac comment

admin@RT-AC68P-EC58:/tmp/home/root# ipset -L foo
Name: foo
Type: hash:ip,mac
Revision: 0
Header: family inet hashsize 1024 maxelem 65536 comment
Size in memory: 64
References: 0
Number of entries: 0
Members:

 

[routers]

FYI, Dnsmasq 2.77 has been released.

 

[Goran]

AC-88U beta 2
Something wrong with Traffic Analyzer:
Only wifi downloading - on WAN graph UL and DL almost same.

 

[RMerlin]

@RMerlin - It's patching the kernel, so you'll have multiple levels to do. There may be a better way with depmod and adding directly from ipset_arm, but I wasn't able to get it to work.

Heavy kernel patching can be problematic if it touches to a data struct such as skbuf, which cannot be changed without breaking all pre-compiled kernel modules.

For depmod, you might need to manually update the dependency file for modules to automatically get inserted as needed.

 

[RMerlin]

FYI, Dnsmasq 2.77 has been released.

Unless there's a major issue resolved, I usually don't touch dnsmasq - Asus tend to take care of keeping that one up-to-date already. By the time I merge it, enough people will have tested it to confirm there was no regression in it (there's been a few in dnsmasq over the years).

So I have no plan to update the dnsmasq version currently included in 380.67 beta.

 

[RMerlin]

Something wrong with Traffic Analyzer:

Did you disable NAT acceleration?

 

[Goran]

Did you disable NAT acceleration?

it is enabled

 

[triple]

info
AC87U now online with SC: http://dlcdnet.asus.com/pub/ASUS/wireless/RT-AC87U/GPL_RT_AC87U_30043807743.zip

 

[john9527]

Heavy kernel patching can be problematic if it touches to a data struct such as skbuf, which cannot be changed without breaking all pre-compiled kernel modules.

For depmod, you might need to manually update the dependency file for modules to automatically get inserted as needed.

No structures changed.....just replaced the directories with the ipset modules with the latest versions. There was one header file that was looking for an skbuff structure that didn't exist, but I was able to work around it.

 

[RMerlin]

it is enabled

View attachment 9734

That's why. Note that the Traffic Monitor page has a mention that for accurate monitoring, NAT acceleration must be disabled.

 

[RMerlin]

No structures changed.....just replaced the directories with the ipset modules with the latest versions. There was one header file that was looking for an skbuff structure that didn't exist, but I was able to work around it.

Cool. Not sure if I'll be able to squeeze it in for 380.67 as I already have a bigger fish to fry with the incoming beta 3, but I'll see what I can do.

 

[RMerlin]

7743 addresses various issues, including security issues. This is the reason for the switch to 7743.

Note that 7743 works fine for many people, including myself. The limited number of people that have problems with code based on 7743 can still keep running 380.66, while the rest of us can move forward to 380.67. The security fixes that were added by myself are all present in the 380.66 updates that I released over the weeks - only those specific to Asus aren't. Some of their fixes to httpd in 7743 are in the closed source components, so I can't backport them to 380.66 (hence the need for 7743).

The fact is, for the majority of people, 7743 is an improvement. I don't want to hold back the majority because of a limited subset of users negatively affected by it - there isn't enough of them to justify it.

One thing I do see that's odd is that the closed-source NAT acceleration component (ctf.o) is nearly 300 bytes smaller in the newer Asus code. I wonder if they might have accidentally reverted it to an older version without PPP support (especially since they did not change that module for all models - only for AC56/AC68/AC87).

I can try reverting it to the previous version for beta 3, see if at least it's compatible, and if so we'll see what happens.

 

[brummygit]

One thing I do see that's odd is that the closed-source NAT acceleration component (ctf.o) is nearly 300 bytes smaller in the newer Asus code. I wonder if they might have accidentally reverted it to an older version without PPP support (especially since they did not change that module for all models - only for AC56/AC68/AC87).

I can try reverting it to the previous version for beta 3, see if at least it's compatible, and if so we'll see what happens.

I'm not running anywhere near the speeds in question but I just tested and definitely see a latency improvement on my RT-AC68U using PPPoE with NAT Acceleration set to auto and CTF mode active (I use QoS so only get limited acceleration).

 

[primitivo]

Has the broken dual-wan been fixed in this release?