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" <[email protected]> To: "dev" <[email protected]> Sent: Thursday, July 9, 2026 1:58:55 PM Subject: TS API Proposal: Masks for Firewall Marks Hi [ mailto:[email protected], | [email protected], ] 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
