no, you still need veth!
but did you tried the firewall fixes?
Oh i see now, the post with lot of lines for sysctl? I think i missed that post! O.o
"sysctl: error: 'net.bridge.bridge-nf-call-arptables' is an unknown key" for the last 5 entries, the others seem to be acknowledged.
Ill see if this changes stuff.
Edit: Nope, not working. I suspect its the aforementioned error from sysctl, which would indicate netfilter kernel module is not loaded? I installed it and such, hard to find info on the web on it.
No problem,i think you see this because arptables is not installed.
did you tired to make firewall look like this!
I have arptables though, those messages conern me as it seemed to solve your issue in your other thread! But if sysctl cant even recognize them...
I will try this firewall setting 
what about changing the veth1 mac to be same as the bridge(br-lan) mac?!
EDIT:
i have a better way to change mac address:
ip link set br-lan address 00:00:00:00:00:00
if it refused to change mac try to set that mac on veth1
EDIT2:
or make veth1 mac same as your br-lan mac!
Actually, so far so good. Fingers crossed. (With firewall settings change)
1 Like
SO, it's working!???
amazing!, i posted that firewall fix in a few posts ago, but i think you didn't saw it.
try if there's some traffic goes in/out veth!
I'm not sure. I've been problem free for 5 mins now so far after reboot, just running script and no MAC stuff since changing firewall like your screenshot!
I will have to see for a few hours before I start cheering 
1 Like
hhaah. i'm glad to see it working!
if it's work for more than 5mins without problems, it's mean it will work forever!
after that you can set iptables and other stuffs!
you can go to interface and see if there traffic on veth0!
Got traffic:
veth0 Link encap:Ethernet HWaddr 36:83:9F:8D:F1:E0
inet6 addr: fe80::3483:9fff:fe8d:f1e0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2947 errors:0 dropped:0 overruns:0 frame:0
TX packets:7695 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:357164 (348.7 KiB) TX bytes:27702872 (26.4 MiB)
veth1 Link encap:Ethernet HWaddr 9E:0F:C4:BA:5E:05
inet6 addr: fe80::9c0f:c4ff:feba:5e05/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:7695 errors:0 dropped:0 overruns:0 frame:0
TX packets:2947 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:27702872 (26.4 MiB) TX bytes:357164 (348.7 KiB)I think upstream goes directly to WAN yes? Without Veth.
But yes, still working after reboot with script at startup!
1 Like
yeah it's fine now.
upstream goes directly to wan.
only downstream goes to veth then to lan.
lets go to next step!
Heh, I think I know how to set it up from here with SQM on Eth1.2 and Veth 
That part was actually easy, with DSCP tagging xD
Thanks man, really appreciated!
Should I keep using DSCP EF rather than CS6 for inbound packets? I only really care about my game(s) for maximum priority, I dont really care much about prioritizing any other traffic. Just maximum priority for my game UDP -> and -<
I saw in your first post this though, which confused me:
net.core.default_qdisc=fq_codel
I should use cake_layer for my SQM's no?
Great!, your welcome anytime.
it's better to use CS6 instead of EF, also enable wmm on wifi, if willing to play on wifi, i'm always play on wifi and there's no lag, openwrt wifi is great!
you need some settings for sqm, i will show you here.
The default queuing discipline to use for network devices. This allows overriding the default of pfifo_fast with an alternative. Since the default queuing discipline is created without additional parameters so is best suited to queuing disciplines that work well without configuration like stochastic fair queue (sfq), CoDel (codel) or fair queue CoDel (fq_codel). Don’t use queuing disciplines like Hierarchical Token Bucket or Deficit Round Robin which require setting up classes and bandwidths. Note that physical multiqueue interfaces still use mq as root qdisc, which in turn uses this default for its leaves. Virtual devices (like e.g. lo or veth) ignore this setting and instead default to noqueue. Default: pfifo_fast
you will use cake disc in sqm settings, also you are free to use tcp BBR instead of cubi or reno.
Well yeah on second thought I might need some help with SQM.
I notice after reboot, the upload limit is applied on eth1.2, but on Veth1 the downstream limit is not applied, i suspect, and probably logically because SQM starts before the script starts, and Veth interface is not created until script runs. So the SQM cannot apply onto a nonexisting/working interface!
What did you use for solution on this? Run SQM after script started? Or add veth to br-lan in LuCi so it exists already?
/etc/config/sqm
config queue 'wan'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option enabled '1'
option debug_logging '0'
option verbosity '5'
option qdisc 'cake'
option qdisc_advanced '1'
option qdisc_really_really_advanced '1'
option squash_dscp '0'
option squash_ingress '0'
option download '0'
option script 'layer_cake.qos'
option linklayer 'ethernet'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '64'
option interface 'eth1.2'
option upload '10000'
option eqdisc_opts 'diffserv4 nat dual-srchost rtt 170ms'
option overhead '50'
option linklayer_adaptation_mechanism 'cake'
option iqdisc_opts 'diffserv4 nat dual-dsthost rtt 170ms autorate-ingress'
config queue
option debug_logging '0'
option verbosity '5'
option ingress_ecn 'ECN'
option tcMTU '2047'
option tcTSIZE '128'
option enabled '1'
option download '0'
option qdisc 'cake'
option qdisc_advanced '1'
option squash_dscp '0'
option squash_ingress '0'
option egress_ecn 'ECN'
option qdisc_really_really_advanced '1'
option linklayer 'ethernet'
option linklayer_advanced '1'
option tcMPU '64'
option linklayer_adaptation_mechanism 'cake'
option script 'layer_cake.qos'
option interface 'veth0'
option upload '30000'
option eqdisc_opts 'diffserv4 nat dual-dsthost rtt 170ms'
option iqdisc_opts 'diffserv4 nat dual-srchost rtt 170ms autorate-ingress'
option overhead '54'
config queue
option debug_logging '0'
option verbosity '5'
option qdisc 'cake'
option qdisc_advanced '1'
option ingress_ecn 'ECN'
option qdisc_really_really_advanced '1'
option enabled '1'
option squash_dscp '0'
option squash_ingress '0'
option egress_ecn 'ECN'
option interface 'eth0'
option upload '16000'
option script 'piece_of_cake.qos'
option iqdisc_opts 'dual-srchost'
option eqdisc_opts 'dual-dsthost'
option linklayer 'ethernet'
option overhead '8'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '64'
option linklayer_adaptation_mechanism 'cake'
option download '0'
1 Like
simply do like this in startup script:
sleep 5
./root/net.sh
sleep 5
/etc/init.d/sqm restart
Ah yeah, good solution! will do that.
I see in that config, you use Veth0? Is that because data flows from Veth0 to Veth1? And this is how SQM can alter packets in between?
1 Like
YES, wan-->veth0-->veh1 -br-lan-
now you can copy paste to /etc/config/sqm , i just edit it according to your upload/download speeds.
i will back to you after launch!
Ah im starting to get it all now heh.
I already did it wrong by applying SQM to Veth1 then, that would not shape my packets even if it did limit downstream. K, will check config.
No problem. you should measure your RTT by using this app https://play.google.com/store/apps/details?id=at.alladin.rmbt.android&hl=en
then ask @moeller0 about overhead!