Menu
What's new
By:
Filters Better Search

[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Well Cox just enabled native IPv6 in my area and it appears working fine. I did notice a problem with QOS with IPv6. With QOS enabled the download is capped with the upload setting. I have 50/5 service and Comcast's speed test shows 50/5 for IPv4 and 5/5 for IPv6. When I disable QOS IPv4 and IPv6 test results are both 50/5. I think this was reported before and was supposed to be fixed in some release.

Forgot to mention I am running version 14E1 of John's fork on a AC-68P
 
kolodzij said:
Well Cox just enabled native IPv6 in my area and it appears working fine. I did notice a problem with QOS with IPv6. With QOS enabled the download is capped with the upload setting. I have 50/5 service and Comcast's speed test shows 50/5 for IPv4 and 5/5 for IPv6. When I disable QOS IPv4 and IPv6 test results are both 50/5. I think this was reported before and was supposed to be fixed in some release.

Forgot to mention I am running version 14E1 of John's fork on a AC-68P
Click to expand...
Yes, it should be fixed...I'm on Cox also but use HETunnel for IPv6 (I'm not native enabled yet).
Just double checked with Xfinity speedtest and it's still fine for me.

Can you check the following via telnet/ssh?

nvram show | grep ipv6_prefix

do ipv6_prefix and ipv6_prefix_length look correct (not the ones ending in _s)
 
john9527 said:
Yes, it should be fixed...I'm on Cox also but use HETunnel for IPv6 (I'm not native enabled yet).
Just double checked with Xfinity speedtest and it's still fine for me.

Can you check the following via telnet/ssh?

nvram show | grep ipv6_prefix

do ipv6_prefix and ipv6_prefix_length look correct (not the ones ending in _s)
Click to expand...

QOS previously worked fine with 6to4 tunnel

ASUSWRT-Merlin RT-AC68U_3.0.0.4 Thu Sep 17 09:01:11 UTC 2015
admin@Readyshare:/tmp/home/root# nvram show | grep ipv6_prefix
ipv6_prefix=2600:8800:a880:14::
ipv6_prefix_length=64
ipv6_prefix_s=
size: 47295 bytes (18241 left)
ipv6_prefix_length_s=64
ipv6_prefix_len_wan=64
admin@Readyshare:/tmp/home/root#
 
kolodzij said:
QOS previously worked fine with 6to4 tunnel

ASUSWRT-Merlin RT-AC68U_3.0.0.4 Thu Sep 17 09:01:11 UTC 2015
admin@Readyshare:/tmp/home/root# nvram show | grep ipv6_prefix
ipv6_prefix=2600:8800:a880:14::
ipv6_prefix_length=64
ipv6_prefix_s=
size: 47295 bytes (18241 left)
ipv6_prefix_length_s=64
ipv6_prefix_len_wan=64
admin@Readyshare:/tmp/home/root#
Click to expand...
Looks reasonable/expected.....

Can you try this....

ip6tables - t mangle -L -v
 
john9527 said:
Looks reasonable/expected.....

Can you try this....

ip6tables - t mangle -L -v
Click to expand...
Readyshare login: admin
Password:


ASUSWRT-Merlin RT-AC68U_3.0.0.4 Thu Sep 17 09:01:11 UTC 2015
admin@Readyshare:/tmp/home/root# nvram show | grep ipv6_prefix
ipv6_prefix=2600:8800:a880:14::
ipv6_prefix_length=64
ipv6_prefix_s=
size: 47295 bytes (18241 left)
ipv6_prefix_length_s=64
ipv6_prefix_len_wan=64
admin@Readyshare:/tmp/home/root# ip6tables - t mangle -L -v
Bad argument `-'
Try `ip6tables -h' or 'ip6tables --help' for more information.
admin@Readyshare:/tmp/home/root# ip6tables -t mangle -L -v
Chain PREROUTING (policy ACCEPT 17380 packets, 4489K bytes)
pkts bytes target prot opt in out source destination

6 432 DROP ipv6-icmp eth0 any anywhere ff02::1:
ff00:0/104 ipv6-icmp neighbour-solicitation

Chain INPUT (policy ACCEPT 1758 packets, 157K bytes)
pkts bytes target prot opt in out source destination


Chain FORWARD (policy ACCEPT 15471 packets, 4313K bytes)
pkts bytes target prot opt in out source destination


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


Chain POSTROUTING (policy ACCEPT 17053 packets, 4488K bytes)
pkts bytes target prot opt in out source destination

admin@Readyshare:/tmp/home/root#

PS I do have the qos_sfql set to 1 in NVRAM if that makes a difference
 
Last edited:
@kolodzij

Now we're getting somewhere.....the ip6tables output doesn't look right

Sorry, but now I need the output of

cat /tmp/mangle_rules_ipv6
 
john9527 said:
@kolodzij

Now we're getting somewhere.....the ip6tables output doesn't look right

Sorry, but now I need the output of
admin@Readyshare:/tmp# ls
john9527 said:
@kolodzij

Now we're getting somewhere.....the ip6tables output doesn't look right

Sorry, but now I need the output of

cat /tmp/mangle_rules_ipv6
Click to expand...


admin@Readyshare:/tmp# ls
Beceem_firmware ipv6_client_list share
avahi ipv6_neigh syscmd.log
ddns.cache mnt syslog.log
dhtest.txt nat_rules udhcpc
etc nat_rules_eth0_eth0 udhcpc0.expires
filter.default notify usb.log
filter_rules ppp usb_err
filter_rules_ipv6 redirect_rules var
home resolv.conf wpa_cli
ipv6_client_info settings zcip
admin@Readyshare:/tmp#
Click to expand...
 
john9527 said:
Sorry, is QOS enabled? It has to be on to generate the files and rules.
Click to expand...

Just re-enabled QOS


Readyshare login: admin
Password:


ASUSWRT-Merlin RT-AC68U_3.0.0.4 Thu Sep 17 09:01:11 UTC 2015
admin@Readyshare:/tmp/home/root# cat /tmp/mangle_rules_ipv6
*mangle
:pREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:QOSO - [0:0]
-A QOSO -j CONNMARK --restore-mark --mask 0x7
-A QOSO -m connmark ! --mark 0/0xff00 -j RETURN
-A QOSO -p tcp --dport 80 -m connbytes --connbytes 0:524287 --connbytes-dir both --connbytes-mode bytes -j CONNMARK --set-return 0x1/0x7
-A QOSO -p tcp --dport 80 -m connbytes --connbytes 0:524287 --connbytes-dir both --connbytes-mode bytes -j RETURN
-A QOSO -p tcp --dport 443 -m connbytes --connbytes 0:524287 --connbytes-dir both --connbytes-mode bytes -j CONNMARK --set-return 0x1/0x7
-A QOSO -p tcp --dport 443 -m connbytes --connbytes 0:524287 --connbytes-dir both --connbytes-mode bytes -j RETURN
-A QOSO -p tcp --dport 80 -m connbytes --connbytes 524288: --connbytes-dir both --connbytes-mode bytes -j CONNMARK --set-return 0x4/0x7
-A QOSO -p tcp --dport 80 -m connbytes --connbytes 524288: --connbytes-dir both --connbytes-mode bytes -j RETURN
-A QOSO -p tcp --dport 443 -m connbytes --connbytes 524288: --connbytes-dir bot
h --connbytes-mode bytes -j CONNMARK --set-return 0x4/0x7
-A QOSO -p tcp --dport 443 -m connbytes --connbytes 524288: --connbytes-dir bot
h --connbytes-mode bytes -j RETURN
-A QOSO -m mac --mac-source 00:18:61:26:8f:23 -j CONNMARK --set-return 0x1/0x7
-A QOSO -m mac --mac-source 00:18:61:26:8f:23 -j RETURN
-A QOSO -d ff00::/8 -j CONNMARK --set-return 0x6/0x7
-A QOSO -d ff00::/8 -j RETURN
-A QOSO -d /64 -j CONNMARK --set-return 0x6/0x7
-A QOSO -d /64 -j RETURN
-A POSTROUTING -o br0 -j QOSO
-A QOSO -j CONNMARK --set-return 0x4/0x7
-A FORWARD -o eth0 -j QOSO
-A OUTPUT -o eth0 -j QOSO
-A QOSO -j RETURN
-A PREROUTING -i eth0 -j CONNMARK --restore-mark --mask 0x7
COMMIT
admin@Readyshare:/tmp/home/root#
 
****QOS disabled

Readyshare login: admin
Password:


ASUSWRT-Merlin RT-AC68U_3.0.0.4 Thu Sep 17 09:01:11 UTC 2015
admin@Readyshare:/tmp/home/root# nvram show | grep ipv6_prefix
ipv6_prefix=2600:8800:a880:14::
ipv6_prefix_length=64
size: 47294 bytes (18242 left)
ipv6_prefix_s=
ipv6_prefix_length_s=64
ipv6_prefix_len_wan=64
admin@Readyshare:/tmp/home/root#

***QOS enabled

Readyshare login: admin
Password:


ASUSWRT-Merlin RT-AC68U_3.0.0.4 Thu Sep 17 09:01:11 UTC 2015
admin@Readyshare:/tmp/home/root# nvram show | grep ipv6_prefix
ipv6_prefix=2600:8800:a880:14::
ipv6_prefix_length=64
ipv6_prefix_s=
size: 47295 bytes (18241 left)
ipv6_prefix_length_s=64
ipv6_prefix_len_wan=64
admin@Readyshare:/tmp/home/root#
 
Don't ask me how it corrected itself...but here is the most recent speedtest with QOS on. QOS is set for 45/5 Mb/s. I did not power off or reboot the router!
1109658684.png


Maybe it took a QOS off/QOS on cycle since QOS was previously on with a 6to4 relay setting before the native IPv6 today.
 
Last edited:
kolodzij said:
Maybe it took a QOS off/QOS on cycle since QOS was previously on with a 6to4 relay setting before the native IPv6 today.
Click to expand...
I think you have hit upon it. It looks like they replaced a reboot with another set of restarts for the ARM based routers when changing IPv6 types....but it's not obvious it's causing a proper restart of qos. I'll queue this one up for a future release. In the meantime, a reboot after changing IPv6 types should clear things up.
 
OK I have done a little more research on this and believe there is still a problem with QOS and native IPv6. I have verified this with multiple sites and it only occurs on lan connections, wireless connections QOS work fine. A post from 4/28/2014 on the ASUS RT68U support forum outlines the identical problem.


The following are a wired gigabit lan connection to a RT-68P

QOS ON -native IPv6
1110401044.png


QOS OFF - native IPv6

1110489024.png


Same wired lan connection with 6to4 and QOS ON

3e9838e9c05297a9b977e3c66f0c0328.png
 
that is very odd, if ipv6 QoS was broken I expect the result would be QoS not working rather than a very small speed. Sadly I dont have native ipv6 currently so cannot test it but when I did have it some months ago I dont recall having this issue.
 
@kolodzij

I've been thinking about this since I saw your post, and have a new hypothesis. The fix I applied was tested by other native users so I know the fix works.

The data you had previously posted showed that the IPv6 prefix value was set both before and after starting QOS, but the QOS startup couldn't read the prefix from nvram. The exact same code is used independent of the IPv6 mode, so I don't think there is any problem there.

Now, turning on QOS causes a reboot (I think to make sure CTF is set properly) and the QOS rules are actually generated early in the reboot process. So my guess is that while Cox may have enabled native IPv6, they are slow in setting it up, and when the QOS rules are set, IPv6 isn't fully up and the QOS rule generation has no prefix to read.

For a test, when QOS is already on and you have the problem go to the main QOS page and slightly change either the upload or download bandwidth setting and hit Save (I think you may not even have to change anything before hitting Save, but let's play it safe). This will regenerate the QOS rules and restart QOS without causing a restart of IPv6. I'm betting this will correct things..
 
john9527 said:
@kolodzij

I've been thinking about this since I saw your post, and have a new hypothesis. The fix I applied was tested by other native users so I know the fix works.

The data you had previously posted showed that the IPv6 prefix value was set both before and after starting QOS, but the QOS startup couldn't read the prefix from nvram. The exact same code is used independent of the IPv6 mode, so I don't think there is any problem there.

Now, turning on QOS causes a reboot (I think to make sure CTF is set properly) and the QOS rules are actually generated early in the reboot process. So my guess is that while Cox may have enabled native IPv6, they are slow in setting it up, and when the QOS rules are set, IPv6 isn't fully up and the QOS rule generation has no prefix to read.

For a test, when QOS is already on and you have the problem go to the main QOS page and slightly change either the upload or download bandwidth setting and hit Save (I think you may not even have to change anything before hitting Save, but let's play it safe). This will regenerate the QOS rules and restart QOS without causing a restart of IPv6. I'm betting this will correct things..
Click to expand...

Nope, still no go on Lan ports, IPv6 QOS works fine on wireless, that's the part that puzzles me. I have uploaded the system log after I modified the QOS speeds followed by a reboot. BTW I have verified this on 2 separate machines.

PS When I modified and saved the QOS parameters I lost IPv6 connectivity and had to restart
so perhaps your theory is still possible.
 

Attachments

  • syslog.txt
    27.4 KB · Views: 573
Last edited:
Here is some of the file content that may be helpful while the router is in this state.
 

Attachments

  • mfiles.txt
    4 KB · Views: 487
You must log in or register to reply here.

Similar threads

D
[Alpha] Gnuton 3006.102.2_2-gnuton1
Replies
0
Views
386
DJones
D
D
Release GNUton [Official Fork] 388.8_2 Release
2
Replies
35
Views
8K
bennor
B
RMerlin
Release Asuswrt-Merlin 386.14 is now available for AC models
11 12 13
Replies
240
Views
39K
Tech9
Tech9
D
Release GNUTON- 388.7_1 release [Official FORK]
Replies
4
Views
3K
MatteoPV
M
D
[Alpha] 3004.388.8_4-gnuton0_alpha1
Replies
0
Views
491
DJones
D
Similar threads
Thread starter Title Forum Replies Date
D Release GNUton [Official Fork] 388.8_2 Release Asuswrt-Merlin 35
D Release GNUTON- 388.7_1 release [Official FORK] Asuswrt-Merlin 4
J How do I use GNUton's fork for my DSL-AX82U please. Asuswrt-Merlin 6
M Asuswrt-Merlin with Nextcloud's share folder functionality Asuswrt-Merlin 1
visortgw Asuswrt Merlin 3006.102.3 Alpha1 for GT-BE98 Pro Asuswrt-Merlin 38
A ASUSwrt-Merlin connection to modem as Access Point and/or Bridge Asuswrt-Merlin 6
kaotic2499 Please add Asuswrt-merlin to GT-BE98 (Non-pro) version Asuswrt-Merlin 22
RMerlin Release Asuswrt-Merlin 3004.388.8_4 is now available Asuswrt-Merlin 160
RMerlin Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices Asuswrt-Merlin 97
B Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14 Asuswrt-Merlin 1

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Total: 715 (members: 10, guests: 705)
Top