Marking packets globally within kernel

I have AP with multiple wifi interfaces and bridges like br0, br101

I try to mark packet for qos for example

br0 -----> eth0 ath0

br101 ----> eth0.101 ath1 ath2

but to my notice marking don't carry from one bridge interface to another.
so mostly aim is to have global marking or packet somehow.
I can write kernel module to update sk_buff if needed.
I don't want to update any IP packet field for this marking as much possible.

I use MAC SNAT as marking flow but is that okay to change source MAC ??
I still think it should be oaky as this is L2-L3 device and changing source MAC shouldn't be problem as IP-MAC resolution is done by ARP. L2 device has equal right to do MAC SNAT similar to L3 device to IP SNAT.
But it would be definitely better if MAC SNAT can be avoided with some global marking.

anyone has idea what can be used to achieve global packet marking ??
thanks in advance.

How are you "marking" them?

I'm not sure why you think this is necessary.

Why are are you changing the MAC addresses?

Can you explain why you are marking Internal packets; and what you wish to accomplish?

just to get per SSID traffic so I can treat them differently in firewall, qos and other process once marked

Wouldn't it be easier for this traffic to have different IPs?

Then you can easilly QoS via the IP addresses.

traffic need to identify by SSID and not IP

In that case, use the receive interface for inbound packets, and the transmit interface for outbound packets.

Each SSID on each radio should be on its own interface.

Since you would need "stable" interface names for this, and the WiFi interface names are often dynamically generated, you can name them in /etc/config/wireless with option ifname

1 Like

yes, marking works within bridge but not for next bridge.

"Next bridge" isn't very clear -- how are they "connected" that the packets seem to be leaving the kernel?

its mostly L2 device - eth0 is WAN port to ISP Router/Gateway other ports (SSID ) local

Still not clear, but nothing you've said suggests that the packets have left the control of the kernel on a single box.

As long as the packets are on a single device and haven't been routed through a physical or virtual loopback cable, virtual Ethernet link or other craziness, as previously stated, the ingress and egress interfaces will allow you to identify packets received from a given SSID, and those destined for a given SSID.

Without other information about why this does not work in your situation, it will be nearly impossible to provide further guidance.

1 Like