You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
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?
All reactions