Merlin 380.68_4 : workaround for broken QOS bandwidth limiter

[Jacques]

Hi,

From my experiences, bandwidth limiter is the most efficient way to reduce latency for my SIP phone. I have a slow 4.3 Mbit/s DL and 1 Mbit/s UL connection. Limiting DL to 3Mbit/s and upload to 0.7 Mbit/s for the whole range of available IP addresses, make my phone calls perfectly smooth. Unfortunately, after upgrading to 380.68_4 it seems that bandwidth limiter didn't work anymore.

In fact, it seems that the whole QOS configuration is reset if you change something which is linked to Trend Micros's DPI engine (advanced stats, AI protection, Apps analysis, ...). If you don that, you have to re-enter from scratch the bandwidth limiter configuration to make it work again :

1. turn off the "Enable QOS" switch
2. turn it on again
3. re-enter the client rule (for me it is: 192.168.1.2-199 | 3 | 0.7)
4. Click on "Apply"

This re-enables QOS and it is rebooting persistent.

Hope this can help.

Jacques

 

[fitnesspm]

5. Reboot router (didn't work for me without a reboot)

Thank you so much, i just tired a factory restore and everything for the last 2 hours! I was about to install an older patch version but after coming across this, I'm glad this temporary fix works!

What a bad bug!!! I've had everyone in my house complain about lag problems where I told him that QOS is on... :\

Please fix in next patch!!!

 

[Sinner]

yeh I was playing with that and noticed that as well.. didn't realize what caused it though. but while messing with settings at some point qos was totally not working and couldn't get it back on.. ty for that ill try it

 

[tsunami2311]

Hi,

From my experiences, bandwidth limiter is the most efficient way to reduce latency for my SIP phone. I have a slow 4.3 Mbit/s DL and 1 Mbit/s UL connection. Limiting DL to 3Mbit/s and upload to 0.7 Mbit/s for the whole range of available IP addresses, make my phone calls perfectly smooth. Unfortunately, after upgrading to 380.68_4 it seems that bandwidth limiter didn't work anymore.

In fact, it seems that the whole QOS configuration is reset if you change something which is linked to Trend Micros's DPI engine (advanced stats, AI protection, Apps analysis, ...). If you don that, you have to re-enter from scratch the bandwidth limiter configuration to make it work again :

1. turn off the "Enable QOS" switch
2. turn it on again
3. re-enter the client rule (for me it is: 192.168.1.2-199 | 3 | 0.7)
4. Click on "Apply"

This re-enables QOS and it is rebooting persistent.

Hope this can help.

Jacques

wait can we actually define range of ip's to be bandwidth limited by simple puting
Client "192.168.1.9-50" | Speed "15/15" or Client "192.168.1.9-192.168.1.50" | Speed "15/15"

I think i give it try next time I have to redo my ac66u router this would make my life so much easier, cause everything in the DHCP range is for wifi only everything else below that range is wired or not limited.

I did noticed IF i say have 11 rules there and delete "client 4" and remake it to give it a slightly hight or lower limit. and hit apply it dont work. I have turn off qos limiting and turn back and redo everything for it to work.

 

[miguelos]

woah, and I thought I have broken router
For me whole QoS was breaking (lsometimes like clearing nvram) - and for me worked installing 380.59 (via restoration tool) and on top of it (from GUI) 380.68_4
see : https://www.snbforums.com/threads/qos-bug.41903

 

[Sinner]

this is very good to know cuz ive been trying to get this working as well. hope merlin can maybe update 380.68_4 to correct this issue. I'm not sure id want to revert to the security vulnerablities

 

[st3v3n]

Gents, Glad to know that others have located and worked this same buggy issue. I finally had to resolve disabling all the trend items and auto-QoS, though it never was the irritant it had become. I went through all manner of sequences, some drastic tests, before going with manual/traditional QoS. This won't work or those who depend on trend micro or have so many devices and family member. In the end, it was just easier and faster for me to go mark I eye-ball everything as it fired up, using wireshark, and adjusting manual bandwidth, profiles. I'm happy with my results while it works, though not with the bug. Someone in another thread some time back reversed their total up/down bandwidth, which worked for them. I tried doing that but it didn't fix anything. Thanks for the input.

 

[gmangt4]

I have same issue on latest build too on RT-AC68U, glad to know not just me....when I try to set it it asks for every device to be setup as a separate rule, how did you set the IP address range? As thats what I would like to do,
cheers

 

[e38BimmerFN]

You can use the routers DMZ for phone device as well. I use the DMZ for my microcell. QoS isn't really needed since VoIP doesn't use a lot of bandwidth...

 

[st3v3n]

I gave everything it's own static IP on the LAN DHCP-Server page, under address/IP/hostname, then set everything up to router through the opnvpn tunnel page, under policy rules, if I follow you. The voip can route to VPN also, or point to WAN or other elsewhere, just enter the address before you add it. Very few, if any regular sip or voip providers have any form of even mild encryption on their networks these days.

If it's actuall sip/voip, not iphpne type traffic, and the openvpn tunnel isn't bogged down, if there aren't many devices and/or video streaming going at the same time, you can have a decent conversation routing voip through the open tunnel, but then again, it can drop without warning; always be nice, granny is listening. Almost no voip providers offer any info on this topic, and won't talk about it if asked. If it works, then it works, YMMV. If your vpn tunnel or provider's traffic is heavy, the conversation will be full of strange echos; imagine gargling on the titanic, and the conversation won't be that private. Wireless traffic doesn't fair well over openvpn tunnels, not as well as a hardlined phone over the tunnel.

In the olden days, with Cisco voip switches that you can still buy, the switch sat between the modem and router in the physical DMS. Now, router puts it there for you, or you route it to WAN where it goes to your voip's network and servers. The ISPs pick up/tag all clear voip traffic, and If they want, they and others can and do listen to it. Re all wannabe spooks with poodles (with due respect to poodles everywhere), the DMZ or WAN is always the easiest way to route a voip call. Whatever you're comfortable with. Using a decent iphone or highend android type model cell phone, with Signal, Viber and similar apps, Wi-Fi calling through a VPN tunnel is pretty painless if it's not heaviier encryption, and you remember to pause your video or other traffic. With the apps handling privacy, just route the Wi-Fi calls to WAN and it will be better. Many pages exist where you can find libraries all about voip. A friend started his own voip business after he came back from service overseas; he was a real wizard at it (nice BMer BTW).

I didn't use tricks to have adequate bandwidth for openvpn and/or voip calling. It can co-exist and be clear enough for use, but it's not for everyone. Depending on your own bandwidth, how far you are from data centers, servers etc, it's not going to equal hardline or good cell quality. Calls will drop. It's only my opinion that manually managing your QoS works better than letting auto-QoS do the same job. It never worked well when I tried to be comfortable with trend micro running at the same time on the AC3200. If voip sits at the top of QoS, it's not using much, if there's not an active call, a mere dribble of signals so to speak. A friend used her tmobile Asus/TMAC1900 router exclusively for her private iphone and cellphone calls, never converted it to an actual router. When her hubby was torrenting one evening, she'd be yelling at him to knock it off so she could use her phone. Funny stuff, didn't mean to stray off-thread. Cheers