Strange behavior with TCP source ports getting altered as packets cross br-lan into wlan1. Help!

I've been helping @hisham2630 with setting up an unusual QoS system using FireQOS. He has an ISP situation where he has lots of bandwidth from certain sites, and then only 1Mbit from other sites. We got the whole scheme set up correctly in terms of tagging with DSCP tags and policy routing over a virtual veth0 / veth1 pair so as to be able to shape traffic using the tags (normal inbound QoS happens in a IFB before those tags are set so we're using routed veth devices to be able to QoS on custom tags), and packets are being routed correctly... but ... he has "no internet". The packet capture showed why: although the internet packets come across veth0 to veth1 fine, veth1 is in br-lan and bridges to his wlan1, and the packets going over wlan1 towards his router have their source TCP port set to 1 which causes them all to be rejected.

What could be causing this strange behavior?

For reference here is the screenshot of the packet capture where I discovered what's up:

notice how in the 5th line the packet ports are 1 -> 11844 instead of 80 -> 11844

the same packet capture shows that the 80 -> 11844 is preserved in the veth so it's only once it's on the wlan1 interface that the port is mangled.

here's the setup: packets come in pppoe-wan and are tagged with DSCP then routed to veth0 using policy routing, where they go through a custom QoS queue we designed, they come out veth1 which is part of the br-lan bridge and then are bridged to wlan1 where his laptop is connected.... inbound packets are fine until they hit wlan1.

Help of any sort appreciated!

1 Like

now we are what is the problem,we disabled bridge firewalling in sysctl.conf:

# disable bridge firewalling by default
net.bridge.bridge-nf-call-arptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0

they should be 0,but when ebltables installed it will some how change it to 1.