I was wondering if someone can explain following and if able to reproduce similar behaviour.
I have computer connected by wire to eth4. This port is added to bridge and eth1 is wan interface connected to. ISP
I have collected 4 different packet captures using packet sniffer tool on every interface in any direction.
Tested using following command:
curl --local-port 63666 http://example.com
ETH4 Workstation directly connected to 951G-2HnD. ( no ingress traffic only egress from workstation)
Bridge (both direction traffic visible )
WAN. (both direction traffic visible )
4 ALL interfaces. (stream 6 is on eth4 from client to router and stream 7 is from router wan IP to destination.)
As you could see in the packet capture taken on ALL interfaces there is small mess and I do not understand that.
Can someone reproduce similar and explain what is happening there?
Why after first SYN packet there is Out-Of-Order one.
It’s coming from the fact that if you capture a packet on both a bridge and its member port, all the actual fields of the packet are identical for the packet captured on the member port and the packet captured on the bridge. So Wireshark can see the newer packet as a duplicate of the older one. Hence the TCP dissector marks it as an out-of-order one (some months/years ago, it was marking it as “retransmission”, which is formally wrong, but that’s cosmetics).
Mikrotik cannot write the interface name into the packet metadata as it uses .pcap format where no metafield for interface ID is provided, but even if it could, I’m afraid it wouldn’t change much - Wireshark’s TCP dissector was ignoring the information about source interface when I checked that last time.
you need to use FIFO or better: FIFO based PCQ with 4 classifiers checked (enabled) which are: dst-ip, src-ip, dst-port and src-port.
I call it PCQ-FULL
this way packets will be in order. you may increase buffer (cache) as much as your router’s HW resources allow to increase throughput.
do not use SFQ or others. First in must be first out. Especially for VOIP, live streams and online-gaming.
do not drop invalid packets in forward chain if they are NAT’d (or if LAN clients have global IP). Because modern Operating systems have ability to re-order ooo packets.
I’m not moderator, I’m just wondering how your instructions (which are valid, BTW) apply to issue where @OP saw (spurious!) OOO packets and retransmissions in wireshark analysis. Which makes your post pretty much off-topic. It’s important to check the discussion itself, only responding to topic title is sometimes extremely wrong as OPs sometimes make wrong topic titles.
And you did resurrect already dead (and buried) thread …
So you’re hunting dusty topics that are not solved? for what purpose? The user which started this topic didn’t join for more than a year, he might as well started fishing as a hobby instead of networking, since then.