If you are capturing on your desktop computer or the like, then the tag isn't there yet, it has to hit the router and get put on before sent out to the WAN. If you're capturing on the WAN interface of the router, then you'll see tags on the output towards the WAN but not on the incoming (because it gets put on between receiving and outputting to veth0). There's no single interface where you'll see all the tags
In the system where you use layer cake on both WAN and LAN/veth it makes sense to tag both directions, this lets you prioritize things both directions. For example in your game you want hit registration to be good, so you want your clicks and button presses to be sent out to the game server with low latency and high reliability. so you tag them in the router and prioritize their output on WAN. But you also want the feedback from the game server to get to you quickly, so you tag packets from the game server and prioritize them in the veth so they go before your other background traffic.
I'm not sure where AF13 falls in the cake diffserv implementation, it looks like it might be "best effort" which is maybe fine, but you might also choose to put it in Video tin with say CS3 if you want to prioritize it over other best effort stuff.
Your suggestion that it's an intermittent DNS resolving issue is interesting but so far not necessarily definite. The fact that it occurs with veth only suggests perhaps an issue with routing or iptables getting screwed up in the slightly strange routing that we use in the veth setup. Some more debugging with logs or packet captures is what's needed here. Can you reproduce the issue reliably and under what circumstances? What are the symptoms? So far, it's too vague even what your problem is.
True, it could just be new routes screwing up intermittently and not necessarily DNS.
Wel yeah, i can reproduce consistently once the veth is up and running. Symptom is one time opening website works, few seconds later i cant open the next new website and simply get 'Page not found'.
One thing I know is that my continuous ping to a random external wan IP keeps working in windows." without interruption. Before and after initiating script / veth
go to firewall then and in general settings make input,output,forward to accept,also do it for lan and wan.
lets see if it will fix the problem.
also open the /etc/sysctl.conf and paste the following
When you get page not found, can you from a command line run some kind of DNS lookup of the website DNS name and see what happens (not sure what OS your computer is running but either "host" or "nslookup" are candidates for command line DNS lookup commands).
static int cake_config_diffserv4(struct Qdisc *sch)
{
/* Further pruned list of traffic classes for four-class system:
*
* Latency Sensitive (CS7, CS6, EF, VA, CS5, CS4)
* Streaming Media (AF4x, AF3x, CS3, AF2x, TOS4, CS2, TOS1)
* Best Effort (CS0, AF1x, TOS2, and those not specified)
* Background Traffic (CS1)
*
* Total 4 traffic classes.
as you said i will switch to CS3, then lets see!
but i think i should lower the connbyte number to a lower,cause my download speed is 1 mbps!
BTW: diffserv8 is not needed most of times?!
At 1Mbps let's say you want your connections to become bulk after they're receiving for 10 seconds continuously, so connbytes should be 10000000/8 = 1250000 bytes or more so the quantity you put is in the right range. If you want to make it more quickly become bulk, you could do say 5 seconds = 625000 bytes
So Im now on latest snapshot, redid all the above on first post, still same situation ha! Looks like no DNS issue after all. If i try to reping to an IP address and no DNS name it sometimes work sometimes not. So its just initiating the socket which fails half the time.
2018-11-27 21:05:29.319: From 192.168.1.1: port unreachable; bytes=56 seq=0001 TTL=64 ID=dccd time=0.277ms
2018-11-27 21:05:30.335: From 192.168.1.1: port unreachable; bytes=56 seq=0002 TTL=64 ID=dd07 time=0.402ms
2018-11-27 21:05:31.335: From 192.168.1.1: port unreachable; bytes=56 seq=0003 TTL=64 ID=dd5b time=0.320ms
2018-11-27 21:05:32.335: From 192.168.1.1: port unreachable; bytes=56 seq=0004 TTL=64 ID=ddb5 time=0.397ms
2018-11-27 21:05:33.336: From 192.168.1.1: port unreachable; bytes=56 seq=0005 TTL=64 ID=ddee time=0.388ms
2018-11-27 21:05:34.351: From 84.241.225.42: bytes=28 seq=0006 TTL=57 ID=6f4a time=22.932ms
2018-11-27 21:05:35.351: From 84.241.225.42: bytes=28 seq=0007 TTL=57 ID=70d6 time=24.988ms
2018-11-27 21:05:36.351: From 84.241.225.42: bytes=28 seq=0008 TTL=57 ID=72de time=22.741ms
2018-11-27 21:05:37.352: From 84.241.225.42: bytes=28 seq=0009 TTL=57 ID=7481 time=22.763ms
2018-11-27 21:05:38.352: From 84.241.225.42: bytes=28 seq=000a TTL=57 ID=76a2 time=24.922ms
Takes like 5 seconds before it works for instance.