We are making progress... I see I don't set the veth into up state... Also we have things left over from before. Can you reboot before next test?
Change the section in the script where I set up the veths to have this:
if [ $USEVETHDOWN = "yes" ] ; then
ip link show lanveth || ip link add lanveth type veth peer name lanbrport
LAN=lanveth
ip link set lanbrport master $LANBR
ip route flush table 100
ip route add default via $LAN table 100
ip rule add iif $WAN table 100
ip link set lanveth up
ip link set lanbrport up
fi
notice those two ip link set lanveth up and ip link set lanbrport up
Mr. dlakelan, is there a video tutorial on how to work on it step by step because I am not fluent in the English language and there is a high probability that I make mistakes and my router may be damaged or spoiled and it does not work well .
Thank you for your reply. I hope if the time allows you to make a video, I will be happy or one of the users. Sorry for asking many questions. Does the method work for fiber-optic internet? Thanks again
Yes the script works for any kind of internet connection with a fixed speed. It wouldn't work well with something like LTE that could change speeds all the time.
Any possible way to implement a sort of anti-jitter? WISP is the only available option I have right now, but gateway ping times range anywhere from 2ms to 80ms+ during heavy traffic times, super jittery. Average pings are 5-15ms with 30-40ms spikes every 3-10s. Being able to implement a synthetic delay, let's say 20ms during ONLY these average, less jittery pings(5-15ms), would average those pings out to 25-35ms. Then ideally when the jitter start coming on, have no delay. I assume that constant pings would have to be monitored to a server(Gateway, Google?) to dynamically switch this delay on and off when jitter is present. Something like this would theoretically raise the average latency, but reduce jitter, hopefully creating smoother gameplay.
Even though the queue works best and gives priority to voice traffic, there are times when the priority queue is empty and a packet of another class is served. Packets of guaranteed bandwidth classes should be processed according to their configured weight. If a priority voice packet arrives in the output queue while these packets are being processed, the VoIP packet may wait a considerable time before being sent. If we assume that a VoIP packet will have to wait behind a data packet, and the data packet can be, at most, equal in size to the MTU (1500 bytes for serial interfaces and 4470 bytes for high speed serial interfaces ), we can calculate the wait time based on the link speed.
For example, for a link speed of 64 kbps and an MTU size of 1500 bytes, we have:
Serialization delay = (1500 bytes * 8 bits / byte) / (64,000 bits / sec) = 187.5 ms
Therefore, a VoIP packet may need to wait up to 187.5 msec before it can be sent if it is delayed behind a single 1500 byte packet on a 64 kbit / s link. VoIP packets are typically sent every 20 ms. With an end-to-end delay budget of 150ms and strict jitter requirements, a deviation of more than 180ms is unacceptable.
You need a mechanism that ensures that the size of a transmission unit is less than 10ms. All packets with a serialization delay greater than 10 ms must be fragmented into 10 ms chunks. A 10ms chunk or chunk is the number of bytes that can be sent over the link in 10ms. You can calculate the size using the link speed:
Fragmentation size = (0.01 second * 64,000 bps) / (8 bits / byte) = 80 bytes
It takes 10 ms to send an 80 byte packet or fragment over a 64 kbit / s link.
On low speed links where a 10 ms packet is smaller than the MTU, fragmentation is required. Simple fragmentation is insufficient, because if the VoIP packet has to wait for all fragments of a single large data packet, the VoIP packet will still be delayed beyond the end-to-end time limit. The VoIP packet must be interleaved or inserted between the data packet fragments.
If you get the following error when manually run the script..
* Zone 'lan'
- Using automatic conntrack helper attachment
* Zone 'wan'
Warning: iptc_commit(): No chain/target/match by that name
* Populating IPv6 filter table
From system Log....
Sun Jul 11 11:43:18 2021 kern.info kernel: [ 9184.407896] xt_CT: No such helper "sip"
Install package kmod-nf-nathelper-extra
//////////////////////// After package installation.
* Zone 'lan'
- Using automatic conntrack helper attachment
* Zone 'wan'
* Populating IPv6 filter table
Thank you for your help Mr. Dopam-IT_1987 for the video, its explanation and its application in a simple way. I also thank Mr. dlakelan for the great effort he made to make the script and the help
