[Alpha] 386.2

[Vexira]

Classification supports Traditional QoS to a small extent. Cake stats aren’t as compatible with the design of the Classification page, which is designed around HTB stats.

So in other words I would need some sort of modification of sorts, which I'm guessing is not possible because it's closed source.

 

[Slawek P]

Not much difference between 386.1_2 and 386.2 alpha 1, cake being the only major change. The main course will be in alpha 2 which switches to 386_42095, and contains updated SDKs for all HND models among other things.

Thumbs up after 24h since upgrading. Thanks

 

[maghuro]

I'm using @Xentrk's selective routing. After installing the latest 386.2 alpha (w/cake) the RPDB rules are lost and selective routing is unusable. Reverted back to 386.1_2 and all is working well. Sorry, did not have time to capture the logs, but hopefully someone will...

EDIT: just realized that something similar was reported earlier in the thread - http://www.snbforums.com/threads/alpha-386-2.70020/post-669817

I'm not using xentrk selective routing right now, but have some policies applied and I confirm, they don't work.
The only way to use the vpn is to force everything to go through it, any rule don't work

 

[skeal]

My OVPN client on the current alpha also doesn't seem to be working right, my IP is wrong shouldn't be my ISP IP. AX88U

 

[Wistuplu]

As an example, I just setup an outbound iptables rule for Skype traffic to ensure it lands in the diffserv3 Voice tin. I set those packets as EF (Expedited Forwarding).
iptables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF

Dear Dave14305,

Just curious, would you care clarifying what you did (rules on router OR rules on the device that generates the traffic ?) and which results you observed (actual packets in the target tin, as evidenced by tc -s qdisc) ?

I experimented with this myself. I could only direct traffic to a specific diffserv tin of the router if I defined the rules on the Linux laptop that was generating the traffic. So, long before the processing of the packets in the router. When I had the iptables rules on the router itself, it was not changing the receiving tin in diffserv in the router. Based on what I read and partly understood, there is a challenge in the "timing" of the processing between those rules and cake. (https://forum.openwrt.org/t/ultimate-sqm-settings-layer-cake-dscp-marks-new-script/53209 ,
https://github.com/hisham2630/Ultim...SCP-marks-New-Script/blob/master/DSCP-ipv4.sh )

Below example of code I used. It was not meant to produce any real-life benefit. It was first meant to brutally test and understand how it worked

sudo iptables -t mangle --new-chain dscp_mark
sudo iptables -t mangle --flush dscp_mark
sudo iptables -t mangle -n --list

sudo iptables -t mangle --append POSTROUTING -j dscp_mark
sudo iptables -t mangle --append dscp_mark -p UDP -j DSCP --set-dscp-class AF41

While we are at it, for anyone's information, in my setup, although cake seemed to work fine overall, the statistics didn't always show clear performance differences between the lower priority tins (e.g. 1 or 2) vs the higher priority tins (e.g. 6 or 7). I mean some low priority tins with significant traffic had better (lower) pk_delay and av_delay than higher priority tins with significant traffic. (I emphasize "significant traffic" because a tin with only little traffic could have an irrelevant average, so to say). This might simply be a sign that there is little to no saturation on my line. It made me accept the simple "besteffort" approach.


Regarding the choice of RMerlin to use diffserv3, I can report that my Gigaset VoIP equipment does indeed tag traffic with DSCP. If memory serves, it was with "EF".


Fun fact regarding DSCP: NTP servers seem to be very creative at using the most exotic DSCP tags. Cisco apps like Webex and Jabber on Android seemed to properly tag traffic with AF41. Windows client will generally not generate tags, unless you mess with Windows GPOs. Whatsapp on Android would be rogue enough to use CS6 which is supposed to be for "Network Control" AFAIU.

Thank you to RMerlin, ttgapers, JackYazz and all members of this wonderful community.
Take care
W.

 

[BreakingDad]

Just wondering why this firmware is here, and not on Merlins site? is it just a preview edition ?

 

[John Fitzgerald]

Just wondering why this firmware is here, and not on Merlins site? is it just a preview edition ?

It is on his site , see "PRE-BETA TEST BUILDS": https://www.asuswrt-merlin.net/download

 

[BreakingDad]

It is on his site , see "PRE-BETA TEST BUILDS": https://www.asuswrt-merlin.net/download

Ahh great, thanks

 

[Marin]

My OVPN client on the current alpha also doesn't seem to be working right, my IP is wrong shouldn't be my ISP IP. AX88U

Same here as well (on the latest 386.2 alpha from Thursday). Despite the OVPN client1 being activated (as shown in GUI) the dnsleaktest.com still leaks my ISP’s IP and Okla’s speedtest still shows my ISP’s name.

 

[New2This]

Same here as well (on the latest 386.2 alpha from Thursday). Despite the OVPN client1 being activated (as shown in GUI) the dnsleaktest.com still leaks my ISP’s IP and Okla’s speedtest still shows my ISP’s name.

Mine was doing the same, But when I set my VPN to force traffic to =YES
It was able to use my VPN IP

 

[maxbraketorque]

.... The main course will be in alpha 2 which switches to 386_42095, and contains updated SDKs for all HND models among other things.

Interesting news. I've been cruising happily along on the 386.2 alpha bandwagon, but not sure I can afford to be among the first to try alpha2 when its posted.

 

[askan7]

I've been testing Cake and I'm getting of a lot better results with 386.2 alpha than I did with 386.1 + cake script. Thanks @RMerlin.

12/1 ADSL2+ with 32 packet overhead (tested with tool).

 

[bilboSNB]

VPN Client policy based rules also broken on mine, as others have stated forcing all internet over the VPN works fine.

 

[lilstone87]

Well I'm curious to see what the new build merge includes. As I currently hate the router log spam on my AX88U, of this message. As I do like to use the router log from time to time, to see if anything weird is happening. I get a lot of these messages everyday in my router log.

kernel: not mesh client, can't update it's ip

 

[Marin]

Mine was doing the same, But when I set my VPN to force traffic to =YES
It was able to use my VPN IP

Yep that worked, thank you. I guess, will wait for Policy Rules bug to be fixed.

 

[Blacklistedcard]

Latest commit from github repo. Running both AX88U and AC86U. So far no problems with latest build.

 

[bluepoint]

I spoke too soon, it's back! Openvpn 2.5.1 might be the fix, Ill wait for the next build.

Openvpn 2.5.1 is not the fix, it's still here it took longer(36 hrs) to show up.

 

[askan7]

Read/write speeds to USB drive seem to be back to 384.19 levels on this build. It was much slower on 386.1.

 

[heysoundude]

I have put in ridiculous hours trying to fine tune performance and I get "seems the same, maybe worse." I no longer talk about my efforts on that front.

You WILL hear from them (LOUDLY, in my case) if there are problems,,,so, no noise is good noise and don't poke that bear.

 

[ItsMeDude]

The latest build has been running trouble free for a two days on an AX88U (Skynet,/scMerlin/Scribe) with an AC68U mesh node.