Time WAIT =
(1)Server wants to close connection, send you a FIN (terminate connection) message.
(2)You receive that message, and you send an AWK (acknoldge that message)
(3)You also sen a FIN that you are terminating this connection
(4) You are now in TIME WAIT for the server to send you last message that it AWK'd your termination aswell
This is done to prevent potential overlap when opening the new connection.
I do not think QOS should be able to go rouge with its setup. Your changes were correctly implemented and really minor from mine.
Hi. I've been using your script for couple days with good results but google photos goes to net control packet although I've included HTTPS filters indicated on page 9. I've also tried filtering port 443 by using custom rules without much success. Any idea ? Thanks
tc filter show dev br0 | grep "1:10" -A 1
I'm running it, since it's not a gui based script it should be fine, seems to work for me.
I'm running it, since it's not a gui based script it should be fine, seems to work for me.
Most likely yes. Just try it.
If it is going to netcontrol that means it is matching some filter rule, but not matching your custom rule.
Out of box these two filters point to net control
-0x80090000 (Management tools / protocols)
-0x80140000 (Network protocol)
You can run
Code:tc filter show dev br0 | grep "1:10" -A 1
To see which filter it is matching by looking at the success counter incrementation between successive calls.
So while you also added 0x8013, which also handles https traffic shown on page 9, I am willing to bet that google photos is instead matching either marks 0x8009 or 0x8014 instead. You will have to fix your custom rule instead so it performs a match and directs it to your desired container.
That's a terrible rule.
You will be moving all your net controls into the web container. Net controls are intended to the processed asap for a responsive internet.
You should try to figure out a better rule that would only catch the photos instead.
Maybe google has a set iprange for their photo severs. Try Whois/dns lookups for those domains to see the ranges they resolve too.
https://support.google.com/a/answer/2589954?visit_id=0-636379033563589379-2115053252&hl=en&rd=1
If not maybe dump the packets and see if they have a unique TOS/dscp mark or anything else you can filter on.
HTTPS traffic is rough. Trend micro identifies a suprising amount of https traffic.
Worst case just filter 443 tracfic for packets above a certain size. Get creative.
Note: When replacing existing rules, watch the PRIO definition since both those rules should not be prio 15.
8014 was an existing rule located at pref 23. To redefine its container destination you should of used pref23 instead of 15. By placing it on pref15 now you have a duplicate with the original on pref23 (the one on pref15 will get matched first).
I updated the table on page 9 to make this easier to which prefs factory rules are located at. This should be kept in mind when changing factory rule destinations.
Pref15 was a the first blank spot within ASUS's rules so thats where I put in 8013. That was arbitrary, more logically it should be at pref 22.
Hi,
Question, when I make any changes to the bandwidth allocations I am met with a string of errors saying "rate must be defined" or something along those lines. I am not sure what I am doing wrong here.
Secondly, where should I place the script once it's up and running so that it starts at router boot?
Thanks,
J
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!