Re: strange TCP problem looks like PMTU but isn't

2016-04-29 Thread Chris Samuel via luv-main 
On Thursday, 28 April 2016 10:46:31 AM AEST Russell Coker via luv-main wrote:

>  but "ping -M want -s 1400 8.8.8.8" works without any problems

I usually use "-M do" for that sort of testing.

The "tracepath" program will also show you the MTU along the route (as long as 
UDP isn't being blocked).

...and from bitter experience I would suggest doing the same test in the 
reverse direction; at work we were having problems for a while with sites 
outside using jumbo frames until we learnt that the uni had asymetric routing 
and the return path had a different MTUon one segment to the incoming path.

Oh, and some bright spark had decided that they could save IP's by using 
RFC1918 addresses on those segments and so the router was sending out PMTUD 
ICMP's with addresses that would get dropped at the border. :-/

Good luck!
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: strange TCP problem looks like PMTU but isn't

2016-04-29 Thread Duncan Roe via luv-main 
On Thu, Apr 28, 2016 at 10:46:31AM +1000, luv-main wrote:
> I've got a Linux system running remotely that has a strange TCP problem, when
> it sends (not receives) a large packet the connection hangs.  For example if I
> ssh in and run commands with small amounts of output everything is fine, but 
> if
> I run "ls -l /" then the connection hangs forever.
>
> My first thought was PMTU discovery, but "ping -M want -s 1400 8.8.8.8" works
> without any problems and also setting the MTU on the only Ethernet device to
> unusually low values (I tried as low as 400 bytes) didn't make any difference.
>
> Any ideas as to what I should try next?
>
> The system in question is a fairly standard AMD64 desktop PC running
> Debian/Jessie.
>
Start a tcpdump to a file before issue ls -l.

Suspect you will see packet not being acknowledged, likely due to faulty
hardware somewhere.

Cheers ... Duncan.
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: strange TCP problem looks like PMTU but isn't

2016-04-28 Thread Trent W. Buck via luv-main 
Russell Coker via luv-main writes:

> I've got a Linux system running remotely that has a strange TCP
> problem, when it sends (not receives) a large packet the connection
> hangs.  For example if I ssh in and run commands with small amounts of
> output everything is fine, but if I run "ls -l /" then the connection
> hangs forever.

I had a problem like that once where an ancient OpenBSD (or Solaris?)
router was poorly configured.  I was told to turn off window scaling on
the Linux boxes behind it:

sysctl net/ipv4/tcp_window_scaling=0

Eventually, I fixed it properly, by throwing away the broken router.


Not sure if that's just broken PMTUD.

___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Re: strange TCP problem looks like PMTU but isn't

2016-04-28 Thread John Mann via luv-main 
Hi,

On 28 April 2016 at 10:46, Russell Coker via luv-main 
wrote:

> I've got a Linux system running remotely that has a strange TCP problem,
> when
> it sends (not receives) a large packet the connection hangs.  For example
> if I
> ssh in and run commands with small amounts of output everything is fine,
> but if
> I run "ls -l /" then the connection hangs forever.
>
> My first thought was PMTU discovery, but "ping -M want -s 1400 8.8.8.8"
> works
> without any problems and also setting the MTU on the only Ethernet device
> to
> unusually low values (I tried as low as 400 bytes) didn't make any
> difference.
>

I would have tried a mtu that would need fragmentation.
1400 is unlikely to trigger fragmentation.

>From a host with Jumbo packet connectivity:

$ ping -M want -s 2000 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 2000(2028) bytes of data.
>From 113.197.15.115 icmp_seq=1 Frag needed and DF set (mtu = 1500)
2008 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=12.6 ms
2008 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=12.5 ms
2008 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=12.9 ms


> Any ideas as to what I should try next?
>

Probe to find the real path mtu is  "ping -M do"
and see whether you get back an ICMP packet-too-big
 or if the ICMPs get dropped somewhere.

>From home on ADSL

johnm@tower:~$ ping -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
>From 150.101.154.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492
ping: local error: Message too long, mtu=1492

johnm@tower:~$ ping -M do -s 1464 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1464(1492) bytes of data.
1472 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=50.2 ms
1472 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=49.4 ms
1472 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=49.2 ms

Thanks,
John


> The system in question is a fairly standard AMD64 desktop PC running
> Debian/Jessie.
>
> --
> My Main Blog http://etbe.coker.com.au/
> My Documents Bloghttp://doc.coker.com.au/
> ___
> luv-main mailing list
> luv-main@luv.asn.au
> https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
>



-- 
*John Mann*
Network Architect, Infrastructure Automation & Delivery

*Infrastructure Services, eSolutions*
​Monash University
738 Blackburn Road
Clayton VIC 3168
Australia

T: +61 3 9905 4774
M: +61 419 568 470
E: john.m...@monash.edu
W: monash.edu
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

strange TCP problem looks like PMTU but isn't

2016-04-27 Thread Russell Coker via luv-main 
I've got a Linux system running remotely that has a strange TCP problem, when 
it sends (not receives) a large packet the connection hangs.  For example if I 
ssh in and run commands with small amounts of output everything is fine, but if 
I run "ls -l /" then the connection hangs forever.

My first thought was PMTU discovery, but "ping -M want -s 1400 8.8.8.8" works 
without any problems and also setting the MTU on the only Ethernet device to 
unusually low values (I tried as low as 400 bytes) didn't make any difference.

Any ideas as to what I should try next?

The system in question is a fairly standard AMD64 desktop PC running 
Debian/Jessie.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main