[CLOSED] Asuswrt-Merlin 378.50 Beta 1 is out

[RMerlin]

Ok, possible bug found: When using the traditional QoS there are no ip6tables rules generated for the ipv6 mangle table at all! IPv6 is completely ignored. For the ipv4 only ppl this is irrelevant but my ISP provides me with native IPv6 for 2 years now, can't ignore this bug.

This typically happens if there is a syntax error in one of the rules. I'll try to reproduce it when I get back home.

 

[RMerlin]

Installed on my RT-N66U. Working well so far, one question though, is the mac filter universal now ? I remember there was a separate list for the 2.4GHz and another one for the 5GHz.

Asus removed it, and I don't know why. But it was deliberate and not an accidental bug.

 

[charlie2alpha]

This typically happens if there is a syntax error in one of the rules. I'll try to reproduce it when I get back home.

Hmm, from what I noticed though, for the IPv4 rules a /tmp/mangle is generated, and normally a mangle_ipv6 should also be there but in this beta it's not there. This, if I'm not mistaken means the firmware is not even generating the rules themselves.

 

[redvers]

Having the same issue. Turning of NAT acceleration solved it though.

curiously, mine was already set to off, and changing it to auto caused the router to reboot - when it came back up, it was still disabled but my no-ip hostname then worked.

i tried my custom script and it still got stuck on "applying settings" until i logged in and ran the ddns-start script manually :

Jan 28 19:04:20 rc_service: httpd 373:notify_rc restart_ddns
Jan 28 19:04:22 watchdog: start ddns.
Jan 28 19:04:22 rc_service: watchdog 387:notify_rc start_ddns
Jan 28 19:04:52 watchdog: start ddns.
Jan 28 19:04:52 rc_service: watchdog 387:notify_rc start_ddns
Jan 28 19:05:22 watchdog: start ddns.
Jan 28 19:05:22 rc_service: watchdog 387:notify_rc start_ddns
Jan 28 19:05:52 watchdog: start ddns.
Jan 28 19:05:52 rc_service: watchdog 387:notify_rc start_ddns
Jan 28 19:06:22 watchdog: start ddns.
Jan 28 19:06:22 rc_service: watchdog 387:notify_rc start_ddns
Jan 28 19:06:46 dropbear[621]: Child connection from 192.168.0.82:50451
Jan 28 19:06:46 dropbear[621]: Password auth succeeded for 'admin' from 192.168.0.82:50451
Jan 28 19:06:52 watchdog: start ddns.
Jan 28 19:06:52 rc_service: watchdog 387:notify_rc start_ddns
Jan 28 19:07:22 watchdog: start ddns.
Jan 28 19:07:22 rc_service: watchdog 387:notify_rc start_ddns
Jan 28 19:07:52 watchdog: start ddns.
Jan 28 19:07:52 rc_service: watchdog 387:notify_rc start_ddns
Jan 28 19:08:22 watchdog: start ddns.
Jan 28 19:08:22 rc_service: watchdog 387:notify_rc start_ddns
Jan 28 19:08:40 ddns: Completed custom ddns update

i then tried the no-ip settings again and it worked fine :

Jan 28 19:18:20 rc_service: httpd 373:notify_rc restart_ddns
Jan 28 19:18:20 ddns update: ez-ipupdate: starting...
Jan 28 19:18:20 ddns update: connected to dynupdate.no-ip.com (8.23.224.120) on port 80.
Jan 28 19:18:21 ddns update: request successful
Jan 28 19:18:21 ddns update: asusddns_update: 0
Jan 28 19:18:21 ddns: ddns update ok

so some sort of issue running the custom script it seems...

 

[mastersnotty]

Broken OpenVPN...?

Hello, the OpenVPN settings have changed and has broken my site-to-site VPN.

In the past the following fields were available when entering the keys for OpenVPN (TLS)

Static Key
certificate authority
server certificate
server key
diffie hellman parameters

Now the fields available are:

certificate authority
server certificate
server key
diffie hellman parameters
certificate revocation list (optional)


Not being able to enter a value for the "Static Key" breaks my site-to-site VPN and forces me to use an older build.

Would you be able to put back the Static Key field?

Thanks!

 

[octopus]

Hello, the OpenVPN settings have changed and has broken my site-to-site VPN.

In the past the following fields were available when entering the keys for OpenVPN (TLS)

Static Key
certificate authority
server certificate
server key
diffie hellman parameters

Now the fields available are:

certificate authority
server certificate
server key
diffie hellman parameters
certificate revocation list (optional)


Not being able to enter a value for the "Static Key" breaks my site-to-site VPN and forces me to use an older build.

Would you be able to put back the Static Key field?

Thanks!

Certificate Revocation List (Optional) is still there.

You can put your TLS key on jffs or mnt, Yes I can't se that box.

tls-auth /mnt/rt-ac68u/openvpn/server1/static.key
modify to your own path

 

[RMerlin]

Hello, the OpenVPN settings have changed and has broken my site-to-site VPN.

In the past the following fields were available when entering the keys for OpenVPN (TLS)

Static Key
certificate authority
server certificate
server key
diffie hellman parameters

Now the fields available are:

certificate authority
server certificate
server key
diffie hellman parameters
certificate revocation list (optional)


Not being able to enter a value for the "Static Key" breaks my site-to-site VPN and forces me to use an older build.

Would you be able to put back the Static Key field?

Thanks!

Set authentication type to Static Key to get access to that field.

 

[mastersnotty]

Set authentication type to Static Key to get access to that field.

Thank you for the reply.
Just to clarify.
Currently for my OpenVPN (TLS) setup, I am populating all these fields with keys (static key, cert authority, server cert, server key and diffie hellman)

From your reply I'm under the impression my OpenVPN (TLS) setup is only working because of the values I have entered for the "static key". When I get a chance to bring down the VPN I will verify this...

Thanks!

 

[RMerlin]

Hmm, from what I noticed though, for the IPv4 rules a /tmp/mangle is generated, and normally a mangle_ipv6 should also be there but in this beta it's not there. This, if I'm not mistaken means the firmware is not even generating the rules themselves.

The only time a mangle script will exist for IPv6 is if you use Traditionnal QoS, or have dnsfilter enabled. Asus does not insert any rules in the IPv6 mangle table with Adaptive QoS.

 

[charlie2alpha]

The only time a mangle script will exist for IPv6 is if you use Traditionnal QoS, or have dnsfilter enabled. Asus does not insert any rules in the IPv6 mangle table with Adaptive QoS.

But I am talking about traditional QoS! I know it's not supposed to when Adaptive is used.

 

[charlie2alpha]

To make things more clear, I refer your previous reply which includes my original report: http://forums.smallnetbuilder.com/showpost.php?p=162798&postcount=242

 

[RMerlin]

But I am talking about traditional QoS! I know it's not supposed to when Adaptive is used.

From what I see, this was changed by Asus with GPL 3762. They now disable generating any IPv6 rule for QoS. No idea what was the reason behind it, but it looks a deliberate change rather than a bug. All I can think is maybe there was a problem with IPv6's QoS support.

merlin@mint-dev ~/asuswrt.ac68/release/src-rt-6.x.4708/router/rc $ git diff 68a34ba08be12bb965cee6fc993a4863f8f0c1e5~1 68a34ba08be12bb965cee6fc993a4863f8f0c1e5 -- qos.c
diff --git a/release/src/router/rc/qos.c b/release/src/router/rc/qos.c
index da82a4a..f811eb3 100644
--- a/release/src/router/rc/qos.c
+++ b/release/src/router/rc/qos.c
@@ -169,7 +169,12 @@ int add_iQosRules(char *pcWANIF)
        if(pcWANIF == NULL || nvram_get_int("qos_enable") != 1 || nvram_get_int("qos_type") != 0) return -1;
        if((fn = fopen(mangle_fn, "w")) == NULL) return -2;
 #ifdef RTCONFIG_IPV6
-       if(ipv6_enabled() && (fn_ipv6 = fopen(mangle_fn_ipv6, "w")) == NULL) return -3;
+#define ipv6_enabled() (0)
+       if(ipv6_enabled() && (fn_ipv6 = fopen(mangle_fn_ipv6, "w")) == NULL)
+       {
+               fclose(fn);
+               return -3;
+       }
 #endif
 
        inuse = sticky_enable = 0;
@@ -698,7 +703,7 @@ int add_iQosRules(char *pcWANIF)
                fprintf(fn_ipv6, "COMMIT\n");
                fclose(fn_ipv6);
                chmod(mangle_fn_ipv6, 0700);
-               eval("ip6tables-restore", (char*)mangle_fn_ipv6);
+//             eval("ip6tables-restore", (char*)mangle_fn_ipv6);
        }
 #endif
        fprintf(stderr, "[qos] iptables DONE!\n");

 

[charlie2alpha]

From what I see, this was changed by Asus with GPL 3762. They now disable generating any IPv6 rule for QoS. No idea what was the reason behind it, but it looks a deliberate change rather than a bug. All I can think is maybe there was a problem with IPv6's QoS support.

This is very very strange, I was using it in 376.49_5 and was working just fine for me, ip6tables was marking packets normally. This change and the change with NAT loopback for MIPS routers make zero sense to me.

 

[RMerlin]

This is very very strange, I was using it in 376.49_5 and was working just fine for me, ip6tables was marking packets normally. This change and the change with NAT loopback for MIPS routers make zero sense to me.

These are the kind of changes that make me wish I'd have at least read access to Asus's git server Otherwise, it's impossible to tell if those are actual "bugfixes", or just temporary debugging changes that they forgot to revert.

 

[charlie2alpha]

These are the kind of changes that make me wish I'd have at least read access to Asus's git server Otherwise, it's impossible to tell if those are actual "bugfixes", or just temporary debugging changes that they forgot to revert.

Meh, indeed annoying. So, should you revert this change, since you already reinstated the NAT loopback fix too?

 

[RMerlin]

Meh, indeed annoying. So, should you revert this change, since you already reinstated the NAT loopback fix too?

Let me sleep on that one. One reason I might see why having ip6tables rules for QoS makes no sense is because the webui won't even let you configure any IPv6-based traffic rule.

Asus has also been doing quite a few changes to iptables lately, and I don't understand the reason behind most of these.

 

[charlie2alpha]

Let me sleep on that one. One reason I might see why having ip6tables rules for QoS makes no sense is because the webui won't even let you configure any IPv6-based traffic rule.

Asus has also been doing quite a few changes to iptables lately, and I don't understand the reason behind most of these.

Yep, it's late for you indeed, have a good night!

As for the issue itself, the web ui indeed is mostly IPv4 oriented but the rules themselves for QoS are usually specifying just ports and/or MAC addresses, and these apply just fine to IPv6. Their QoS does not allow for source IP to be specified anyway, probably to avoid exactly such problems, I was doing it myself on the script level and even then, I was using source MACs since IPv6 addresses are dynamic in my setup.

 

[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.

dnsmasq does not use /etc/resolv.conf - the operating system does (and the 127.0.0.1 entry tells the OS to send all queries to dnsmasq). The nameservers used by dnsmasq are defined in /tmp/resolv.conf:

resolv-file=/tmp/resolv.conf

This is the list of servers that will be affected by strict-order.

 

[RMerlin]

NAT loopback (attempting to access a LAN server from the LAN, using the WAN address) doesn't seem to work with this firmware. Flashed back to 376.49_5 and it is working again.

Using an AC66u

Should be fixed in beta 2. Asus reverted a NAT loopback-related fix in recent GPL, for some unknown reason.

 

[RMerlin]

2nd:
I found in .50, if I add "strict-order" to "dnsmasq.conf.add", then I can't ping nothing from router until I ping the same host from a client (I can ping any hosts from a client). But after the cache of dnsmasq expired, then again I can't ping that host from router, which resulting in NTP not working, and thus DDNS, ipv6 tunnel and anything depending on the sync of time.
Removing "strict-order" makes pinging on the router work again.
This didn't happen on previous version. I'm using PPPoE for WAN.

I used the same nameservers as you, and I can't reproduce the problem. All my pings done on the router worked fine, regardless of which target I tried to ping.