Hi,

I am having difficulty connecting to a particular website. It runs a BB.
When I try to post my browser never gets a reply. The site is used by
other people who are not having any problems. The site admin has not
found a problem at his end. I can connect to the rest of the site okay.

I can ping up to his main router (80.232.30.38), although he appears not
to respond to pings.

I would like some advice/suggestions on how to track down where the
packets are getting lost.

I run a couple of linux boxes NATed behind a Dlink modem.

There is an ipgrab log of a failed connection at
http://www.hindley.org.uk/~mark/ipgrab.http.txt. This was with nothing
in my router firewall apart from the single source NAT rule.

Let me know if any more info would be ful.

Thanks,

Mark

In article <v9uj24-sio.ln1@titan.hindleynet>,
Mark Hindley <mark@hindley.spamnospam.uklinux.net> wrote:

>I am having difficulty connecting to a particular website. It runs a BB.
>When I try to post my browser never gets a reply. The site is used by
>other people who are not having any problems. The site admin has not
>found a problem at his end. I can connect to the rest of the site okay.

Possibly an MTU problem? When you post is probably the only time
you are sending them large packets. Are you on a DSL line or
using IPSec or PPTP or L2TP (or is the site?) Do you have your
firewall set up to permit incoming ICMP unreachable ?

Walter Roberson <roberson@hushmail.com> wrote:

> Possibly an MTU problem? When you post is probably the only time
> you are sending them large packets. Are you on a DSL line or
> using IPSec or PPTP or L2TP (or is the site?) Do you have your
> firewall set up to permit incoming ICMP unreachable ?

Thanks.

I am on ADSL. GDMT, PPPoA, VC encap.

I hadn't changed the default MTU, so NAT->modem MTU was 1500. I have
just tried to reduce it to the same as the modem (1476), but no change.
Just on the off chance I reduced it further to 512 and the post worked!
I was gobsmacked! I had never realised that a bad MTU would actually
hose a connection, I thought you just got lots of fragmentation and it
was slow.

So, how do I work out what should the MTU be?

Mark

In article <orck24-fet.ln1@titan.hindleynet>,
Mark Hindley <mark@hindley.spamnospam.uklinux.net> wrote:

>I hadn't changed the default MTU, so NAT->modem MTU was 1500. I have
>just tried to reduce it to the same as the modem (1476), but no change.
>Just on the off chance I reduced it further to 512 and the post worked!
>I was gobsmacked! I had never realised that a bad MTU would actually
>hose a connection, I thought you just got lots of fragmentation and it
>was slow.

When your outgoing packet reaches a device (logical or physical)
where the outgoing MTU is smaller than what you are trying to
transmit, then the device may drop the packet and should send
you back an ICMP Fragmentation-Needed response. If the IP
"Don't Fragment" option is *not* set, then the device has the option
of fragmenting and sending the fragments onwards, but if the
IP "Don't Fragment" option *is* set, then the device "must not"
fragment the packet, and must drop it, and should send you the ICMP
message. (I do not recall at the moment whether those 'should'
for the ICMP are "should" or "must" -- I can't recall at the moment
whether simply throwing away the packet is permitted for unreliable
streams such as UDP; I suspect it is a "must" because it works at
the IP level, not at the protocol level.)

So if your system sends out a packet that is too large for another
device to handle and it decides not to fragment or your packets have
the flag to not fragment them, then the other device should be sending
back an ICMP. However, it is by no means unknown for administrators to
not understand the process and accidently or unthinkingly block the
return of those ICMP. (The problem could even be in the firewall or
router closest to you.) When those ICMP do not get back to the
originating host, the originating host doesn't know that it needs
to reduce the outgoing MTU and retransmit; the effect is as if
the remote side simply did not respond (or as if the packet had
randomly disappeared.)


>So, how do I work out what should the MTU be?

Check around your system to see if you can enable "Path MTU Discovery".

Meanwhile, there's trial and error ;-)

You can use 'ping' and specify the packet length to see what the
largest ping is that you can get through.

On Sun, 12 Nov 2006 20:58:00 +0000, Walter Roberson wrote:

>>So, how do I work out what should the MTU be?
>
> Check around your system to see if you can enable "Path MTU Discovery".
>
> Meanwhile, there's trial and error ;-)
>
> You can use 'ping' and specify the packet length to see what the
> largest ping is that you can get through.

If you cannot ping (because it is blocked) have a look at hping2 which can
do the same at tcp port 80. Unix only unfortunately.

M4
--
Redundancy is a great way to introduce more single points of failure.

Mark Hindley <mark@hindley.spamnospam.uklinux.net> wrote:

> I am on ADSL. GDMT, PPPoA, VC encap.

> I hadn't changed the default MTU, so NAT->modem MTU was 1500. I have
> just tried to reduce it to the same as the modem (1476), but no change.
> Just on the off chance I reduced it further to 512 and the post worked!

The "modem" likely sees the entire IP datagram as data. If so then
"NAT->modem MTU" should be 1476-20-32=1424 (overhead of 20 IP header,
32 TCP header - as seen in the ipgrab file). That assumes any other
encapsulation occurs in or beyond the modem.

--
Clifford Kite
/* I hear and I forget. I see and I remember. I do and I understand.
--Confucius, 551-479 BC */

Mark Hindley wrote:

> I hadn't changed the default MTU, so NAT->modem MTU was 1500. I have
> just tried to reduce it to the same as the modem (1476), but no change.
> Just on the off chance I reduced it further to 512 and the post worked!
> I was gobsmacked! I had never realised that a bad MTU would actually
> hose a connection, I thought you just got lots of fragmentation and it
> was slow.
>
> So, how do I work out what should the MTU be?
>
> Mark

Now that you know what the problem is, you should be able to explain it
to the administrators of that site and hopefully they can fix it.

ICMP is mandatory, not optional. It is *required* for TCP to work
correctly. The site is most likely a path MTU black hole. (Unless the
problem is with your provider, which is probably less likely though not
impossible.)

Someone is dropping packets that exceed the MTU without returning a
*valid* 'fragmentation needed but DF bit set' datagram. *Or* someone is
dropping/filtering *valid* 'fragmentation needed but DF bit set'
datagrams. Two common causes of this are bone-headed firewall
configurations that block all ICMP and bone-headed router
configurations that return ICMP datagrams with invalid (not permitted
on the public Internet) source addresses.

DS