similar to: [Bug 1165] New: Feature Request - Clamp MTU to MSS

https://bugzilla.netfilter.org/show_bug.cgi?id=1058 Bug ID: 1058 Summary: Add clamp MSS to MTU Product: nftables Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: nft Assignee: pablo at netfilter.org Reporter:

current content below is annotated by some suggestions of things to add along with questions for those who know more than I do [in brackets] ================ # iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu This calculates the proper MSS for your link. [If I understand the code correctly ... - expert intervention invited] More precisely, this sets the

https://bugzilla.netfilter.org/show_bug.cgi?id=662 Phil Oester <netfilter at linuxace.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED CC| |netfilter at linuxace.com Resolution|

I sent the message below to this list over a week ago, and I haven''t seen any response. If this is not the correct forum for my question, can anyone suggest a better person or place to which I should direct it? Thank you, Jonathan Kamens ------- Start of forwarded message ------- From: Jonathan Kamens <jik@kamens.brookline.ma.us> To: lartc@mailman.ds9a.nl Subject: [LARTC] MSS

Hey, My internet is provided via ADSL using PPPoE. When I take a look at ifconfig''s output, I see that eth0 has an MTU of 1500, and ppp0 has an MTU of 1492. I don''t _think_ that rp-pppoe (my pppoe util) is clamping the MSS. I am noticing some latency when there''s a lot of bandwidth in use (but not >90%). What should I clamp, eth0/ppp0? How much? And what with,

Hi I have a (bizarre) problem with ssh, which someone has suggested may be down to the MSS value being too high. I know that within Shorewall I can clamp the MSS value to the MTU-40 value, but is there a way I can set MSS to a discreet value? I just want to (dis)prove the MSS theory at the moment (I know it isn''t a real fix). Thanks, Keith

Hello, I have an interesting question. I can''t find a solution anywhere to this problem. I have an adsl connection which is able to send a full data packet in about 150ms. I want to cut this time down to decrease latency while serving files, so I thought I''d try and reduce the packet size for the offending upload streams (my webserver). The trick is that I also want all other

Am 23.06.2020 08:43, schrieb Luca Bertoncello: And another thing, I discovered right now... > Could you suggest me something to restrict the problem? > Currently, I think the problem can be: > > 1) on Asterisk > 2) on my Gateway/Firewall A couple of years ago I added this entry in my firewall: /sbin/iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS

Hello Le 23/06/2020 à 09:06, Luca Bertoncello a écrit : > Am 23.06.2020 08:43, schrieb Luca Bertoncello: > > And another thing, I discovered right now... > >> Could you suggest me something to restrict the problem? >> Currently, I think the problem can be: >> >> 1) on Asterisk >> 2) on my Gateway/Firewall > > A couple of years ago I added this entry

Hello, if you need clampmss then it is highly probable there is a PMTU discovery problem. The clampmss does not work for UDP. I probably counted the size incorrectly. So you are able to ping with size 1464 and not with 1466. How about trying same ping sizes from the internet towards your site? I mean trying to ping from sites with higher MTU than yours without lower MTU links in the path. You

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=554 ------- Additional Comments From fhagur@gmail.com 2007-04-17 05:04 MET ------- I have been wondering about this bug and had similar problems myself here in my Debian system, linux-kernel 2.6.18 iptables 1.3.6. I too saw that some packets became transmitted illegally through the ppp0 interface, when they just shoudn't. What I

Hello, I am in the process of troubleshooting another problem and noticed a rather strange behavior with the openssh client. A client (OpenSSH 5.3) and a server (6.7p1) do the TCP handshake, the client announces a MSS of 1460 (its MTU is 1500), while the server announces a MSS of 1260 (its MTU is set to 1300). What troubles me is, that the client is sending the server a frame of 2034 bytes

Hello every one, first time poster, four month shorewaller ;) As the subject states, I''ve been experienced the infamous trouble described in the next excerpt from shorewall.conf # MSS CLAMPING # # Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU" # option. This option is most commonly required when your internet # interface is some

On 12/24/2014 09:16 PM, Lucas Stach wrote: > Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >> The Tegra124 and later Tegra SoCs have a sepatate rail gating register >> to enable/disable the clamp. The original function >> tegra_powergate_remove_clamping() is not sufficient for the enable >> function. So add a new function which is dedicated to the GPU rail

The Tegra124 and later Tegra SoCs have a sepatate rail gating register to enable/disable the clamp. The original function tegra_powergate_remove_clamping() is not sufficient for the enable function. So add a new function which is dedicated to the GPU rail gating. Also don't refer to the powergate ID since the GPU ID makes no sense here. Signed-off-by: Vince Hsu <vinceh at nvidia.com>

On 12/26/2014 04:34 AM, Lucas Stach wrote: > Am Donnerstag, den 25.12.2014, 10:28 +0800 schrieb Vince Hsu: >> On 12/24/2014 09:16 PM, Lucas Stach wrote: >>> Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >>>> The Tegra124 and later Tegra SoCs have a sepatate rail gating register >>>> to enable/disable the clamp. The original function

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=534 Summary: --mss in tcp.man Product: iptables Version: 1.3.5 Platform: i386 OS/Version: Debian GNU/Linux Status: NEW Severity: trivial Priority: P2 Component: iptables AssignedTo: laforge@netfilter.org ReportedBy:

On 01/05/2015 11:09 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: >> On 12/24/2014 09:16 PM, Lucas Stach wrote: >>> Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >>>> The Tegra124 and later Tegra SoCs have a sepatate rail gating register >>>> to enable/disable

On 01/06/2015 07:15 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Tue, Jan 06, 2015 at 10:11:41AM +0800, Vince Hsu wrote: >> On 01/05/2015 11:09 PM, Thierry Reding wrote: >>>> Old Signed by an unknown key >>> On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: >>>> On 12/24/2014 09:16 PM, Lucas Stach wrote:

https://bugzilla.netfilter.org/show_bug.cgi?id=917 Summary: Kernel OOPS on Kernel 3.14.2 Product: netfilter/iptables Version: unspecified Platform: x86_64 OS/Version: Debian GNU/Linux Status: NEW Severity: critical Priority: P5 Component: NAT AssignedTo: netfilter-buglog at lists.netfilter.org