You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by jo...@mediacombb.net on 2026/07/09 18:58:55 UTC
TS API Proposal: Masks for Firewall Marks
Hi [ mailto:dev@trafficserver.apache.org, | dev@trafficserver.apache.org, ]
I am proposing to extend two existing APIs to support a mask for setting firewall marks. The TS APIs already provide the ability to set the packet firewall mark on the client or server-side connection. The proposed APIs will allow additionally specifying a bitmask to limit which bits of the mark are modified. The mask will behave the same way as the optional mask in the `--set-mark` argument to the Linux `iptables` command. This is useful if different projects (or potentially different ATS plugins) need to set marks on the same connection for different purposes. A (possibly incomplete) list of masks used by various projects is maintained at [ https://github.com/fwmark/registry | https://github.com/fwmark/registry ] .
These are the existing APIs:
TSReturnCode TSHttpTxnClientPacketMarkSet(TSHttp txnp, int mark);
TSReturnCode TSHttpTxnServerPacketMarkSet(TSHttp txnp, int mark);
I propose to add a function overload for each of these:
TSReturnCode TSHttpTxnClientPacketMarkSet(TSHttp txnp, int mark, int mask);
TSReturnCode TSHttpTxnServerPacketMarkSet(TSHttp txnp, int mark, int mask);
The proposed change is ABI-compatible.
Does this seem reasonable? Are there any concerns with this proposal?
Regards,
Josiah VanderZee
Re: TS API Proposal: Masks for Firewall Marks
Posted by jo...@mediacombb.net.
We have realized this API is not needed, because ATS sets the default mark at the socket-level. Tools such as `iptables` set the per-packet mark.
From: "me myself" <jo...@mediacombb.net>
To: "dev" <de...@trafficserver.apache.org>
Sent: Thursday, July 9, 2026 1:58:55 PM
Subject: TS API Proposal: Masks for Firewall Marks
Hi [ mailto:dev@trafficserver.apache.org, | dev@trafficserver.apache.org, ]
I am proposing to extend two existing APIs to support a mask for setting firewall marks. The TS APIs already provide the ability to set the packet firewall mark on the client or server-side connection. The proposed APIs will allow additionally specifying a bitmask to limit which bits of the mark are modified. The mask will behave the same way as the optional mask in the `--set-mark` argument to the Linux `iptables` command. This is useful if different projects (or potentially different ATS plugins) need to set marks on the same connection for different purposes. A (possibly incomplete) list of masks used by various projects is maintained at [ https://github.com/fwmark/registry | https://github.com/fwmark/registry ] .
These are the existing APIs:
TSReturnCode TSHttpTxnClientPacketMarkSet(TSHttp txnp, int mark);
TSReturnCode TSHttpTxnServerPacketMarkSet(TSHttp txnp, int mark);
I propose to add a function overload for each of these:
TSReturnCode TSHttpTxnClientPacketMarkSet(TSHttp txnp, int mark, int mask);
TSReturnCode TSHttpTxnServerPacketMarkSet(TSHttp txnp, int mark, int mask);
The proposed change is ABI-compatible.
Does this seem reasonable? Are there any concerns with this proposal?
Regards,
Josiah VanderZee