GNU bug report logs - #23547
debbugs.gnu.org MTU / icmp black hole issue

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23547 in the body.
You can then email your comments to 23547 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: debbugs.gnu.org MTU / icmp black hole issue
Date: Mon, 16 May 2016 10:47:51 +0800

Package: debbugs.gnu.org

Just received the following bug report, which I'm forwarding here.

---------- Forwarded message ----------
From: Janne Snabb <snabb <at> epipe.com>
Date: Sun, May 15, 2016 at 5:28 PM
Subject: debbugs.gnu.org MTU / icmp black hole issue

Hi,

I was wondering why my email to debbugs.gnu.org was stuck.

After researching with tcpdump and ping it appears that this server is
using or is behind a network which uses MTU which is smaller than normal
but it is not advertising that correctly in TCP MSS and not informing
the client about blackholed backets with icmp. The advertised TCP MSS
value is too high. Packets that big end up in a black hole and the email
delivery TCP connection stalls. There may be some icmp blackholing
involved as well.

Just FYI. It would be a good idea to fix this. The current setup is very
broken.

I was able to work around this issue and get my email (including this
one) delivered by using sysctl -w net.ipv4.tcp_mtu_probing=1 on client side.

--
Janne Snabb
snabb <at> epipe.com

Message #10 received at 23547 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: snabb <at> epipe.com
Cc: 23547 <at> debbugs.gnu.org
Subject: Re: bug#23547: debbugs.gnu.org MTU / icmp black hole issue
Date: Mon, 16 May 2016 03:24:39 -0400

> After researching with tcpdump and ping it appears that this server is
> using or is behind a network which uses MTU which is smaller than normal
> but it is not advertising that correctly in TCP MSS and not informing
> the client about blackholed backets with icmp. The advertised TCP MSS
> value is too high. Packets that big end up in a black hole and the email
> delivery TCP connection stalls. There may be some icmp blackholing
> involved as well.

Thanks for the report.
Sadly, I only understand about one word in three, so I have no idea what
to do to fix this. :(
Can anyone help?

Message #13 received at 23547 <at> debbugs.gnu.org (full text, mbox):

From: Lisa Marie Maginnis <lisam <at> fsf.org>
To: 23547 <at> debbugs.gnu.org
Subject: Re: bug#23547: debbugs.gnu.org MTU / icmp black hole issue
Date: Mon, 16 May 2016 14:30:18 -0400

> After researching with tcpdump and ping it appears that this server is
> using or is behind a network which uses MTU which is smaller than normal
> but it is not advertising that correctly in TCP MSS and not informing
> the client about blackholed backets with icmp. The advertised TCP MSS
> value is too high. Packets that big end up in a black hole and the email
> delivery TCP connection stalls. There may be some icmp blackholing
> involved as well.

Hello,

Thanks for your report. We have resolved this issue on our end by lowering
the TCP MSS value advertised on connections coming out of the network in 
question.

We are currently using an MSS of 1394 to accomedate links with an MTU less
than 1500. If you are still seeing this issue, let us know!

Thanks & Happy Hackingz,

-- 
~Lisa Marie Maginnis
Senior System Administrator
Free Software Foundation
http://fsf.org http://gnu.org
GPG Key: 61EEC710

Message #18 received at 23547 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 23547 <at> debbugs.gnu.org
Subject: Re: bug#23547: debbugs.gnu.org MTU / icmp black hole issue
Date: Mon, 16 May 2016 14:51:40 -0400

For the record, this was manifesting in the exim logs as
"SMTP data timeout (message abandoned)"

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.