[Bug] mtbuddy v1.10.1 сообщает, что TCPMSS=88 применён, но правило не создаётся в Debian 12 и Debian 13

[Kumarikus]

Hello!

I reproduced the same TCPMSS installation issue on two independent VPS servers:

Debian 12;
Debian 13;
mtbuddy v1.10.1;
mtproto.zig v1.10.1;
native installation, not Docker;
different hosting providers and different proxy ports.

The installation was performed with an explicit TCPMSS value:
sudo mtbuddy install
--port
--domain
--user
--tcpmss 88
--version v1.10.1
--yes

On both servers, the installer reported success:
✔ TCPMSS clamping applied
The final installation summary also showed:
✔ TCPMSS=88 (ClientHello fragmentation)

However, immediately after installation, no TCPMSS rule actually existed for either IPv4 or IPv6.
I checked this using:
sudo iptables -t mangle -S OUTPUT
sudo ip6tables -t mangle -S OUTPUT

Only the NFQUEUE rule was present:
-P OUTPUT ACCEPT
-A OUTPUT -p tcp -m tcp --sport -j NFQUEUE --queue-num 200 --queue-bypass

There was no rule containing TCPMSS or --set-mss 88.
An exact check also confirmed that the rule was missing:
sudo iptables -t mangle -C OUTPUT
-p tcp --sport
--tcp-flags SYN,ACK SYN,ACK
-j TCPMSS --set-mss 88

Result:
iptables: Bad rule (does a matching rule exist in that chain?).
The same result was returned by ip6tables.

On the Debian 12 server I additionally confirmed:
iptables v1.8.9 (nf_tables)
xt_TCPMSS module is loaded
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m

Therefore, the kernel and the iptables-nft backend support the TCPMSS target.
It appears that mtbuddy either does not execute the command correctly or does not check its exit status while still reporting success.

Questions:
Is this a known issue in mtbuddy v1.10.1?
Can the installer display the real iptables error instead of reporting success?

[sleep3r]

should be fixed in new versions