Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.os.linux.networking > #2945 > unrolled thread

TCP connections freezing unexplicably

Started byStefan Monnier <monnier@iro.umontreal.ca>
First post2014-05-11 22:52 -0400
Last post2014-05-13 09:26 -0400
Articles 4 — 3 participants

Back to article view | Back to comp.os.linux.networking


Contents

  TCP connections freezing unexplicably Stefan Monnier <monnier@iro.umontreal.ca> - 2014-05-11 22:52 -0400
    Re: TCP connections freezing unexplicably Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-05-12 10:21 +0000
      Re: TCP connections freezing unexplicably Richard Kettlewell <rjk@greenend.org.uk> - 2014-05-12 20:35 +0100
        Re: TCP connections freezing unexplicably Stefan Monnier <monnier@iro.umontreal.ca> - 2014-05-13 09:26 -0400

#2945 — TCP connections freezing unexplicably

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2014-05-11 22:52 -0400
SubjectTCP connections freezing unexplicably
Message-ID<jwvy4y73fb1.fsf-monnier+comp.os.linux.networking@gnu.org>
I have a problem where TCP connections to a machine of mine tend to
freeze in a way I can't explain.

Here are the symptoms:
- I ssh into the machine, and right in the middle of some output the
  connection just freezes.  If I have other simultaneous SSH connections
  multiplexed over the same underlying TCP connection, they freeze
  as well.
- I connect via imap-over-ssl to that same machine, and similarly the
  connection randomly hangs.
- As mentioned, those hangs seem to happen when there is activity,
  rather than when the connection is idle.
- One TCP connection freezing does not prevent other TCP connections
  from working just fine.  E.g. if I have two SSH connections (not
  multiplexed over the same TCP connection), one might freeze while the
  other keeps working fine.
- This happens when connecting from various different places (e.g. from
  home behind a NAT router, from a server with no NAT in sight, ...).
- I can somewhat reproduce the freeze at will, by connecting over ssh
  and then doing "du /home" (which generates a fair bit of output).
  Maybe I'll have to do "du /home" a second or a third time, but I've
  never needed more to reproduce the problem.
- There's nothing magical about "du", the freeze also happens in many
  other cases.
- "dmesg" is desperately silent.

Some more info about the context:

This machine is connected to the Internet via its eth0 with a fixed
routable IPv4 address.  It is running Debian stable over Linux-3.4
(well, the linux-sunxi variant of it, but that shouldn't make much
difference here, hopefully).

Other than its eth0 interface it has two more network interfaces:
- an ethernet USB dongle (name "eth-usb").
- a tun0 handled by OpenVPN.
Each of those uses a local non-routable (192.168.x.x) network, so
it uses NAT to provide Internet access to those machines connected over
one of those two interfaces.
The iptables setup is very simple, see below.

The SSH and IMAP-over-SSL connections I talk about above all come from
the Internet (i.e. over the eth0 interface).

Any idea where the problem might be coming from?  How could I try to
track it down?


        Stefan


# iptables -t nat -vL
Chain PREROUTING (policy ACCEPT 605K packets, 65M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 595K packets, 65M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 2104 packets, 147K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 11 packets, 874 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2296  161K MASQUERADE  all  --  any    eth0    anywhere             anywhere            
# iptables -vL       
Chain INPUT (policy ACCEPT 1109K packets, 189M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 1925 packets, 417K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 97455 packets, 29M bytes)
 pkts bytes target     prot opt in     out     source               destination         
# 

[toc] | [next] | [standalone]


#2946

FromJorgen Grahn <grahn+nntp@snipabacken.se>
Date2014-05-12 10:21 +0000
Message-ID<slrnln185s.2t7.grahn+nntp@frailea.sa.invalid>
In reply to#2945
On Mon, 2014-05-12, Stefan Monnier wrote:
>
> I have a problem where TCP connections to a machine of mine tend to
> freeze in a way I can't explain.

Two things to start with:
- 'netstat -s' -- monitor the machine-global counters for TCP and see if
  some unusual one starts increasing.  Both on client and host would
  be nice.
  (Even nicer if you could monitor this per socket and avoid the
  background noise, but I don't think you can.)
- tcpdump.  You probably should specify a filter, e.g. 'icmp or tcp
  port XXXXX'.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]


#2947

FromRichard Kettlewell <rjk@greenend.org.uk>
Date2014-05-12 20:35 +0100
Message-ID<wwvd2fidc35.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf87AxnpFoA.invalid>
In reply to#2946
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Mon, 2014-05-12, Stefan Monnier wrote:

>> I have a problem where TCP connections to a machine of mine tend to
>> freeze in a way I can't explain.
>
> Two things to start with:
> - 'netstat -s' -- monitor the machine-global counters for TCP and see if
>   some unusual one starts increasing.  Both on client and host would
>   be nice.
>   (Even nicer if you could monitor this per socket and avoid the
>   background noise, but I don't think you can.)
> - tcpdump.  You probably should specify a filter, e.g. 'icmp or tcp
>   port XXXXX'.

Specifically, tcpdump both endpoints of a connection concurrently and
see if they both see the same thing.

My wild stab in the dark is that the problem is MTU-related.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]


#2950

FromStefan Monnier <monnier@iro.umontreal.ca>
Date2014-05-13 09:26 -0400
Message-ID<jwvoaz1yfte.fsf-monnier+comp.os.linux.networking@gnu.org>
In reply to#2947
> My wild stab in the dark is that the problem is MTU-related.

The netstat output didn't help me very much, and before I got to the
tcpdump approach, I took a look at the MTU aspect, which made me think
of comparing the setup (including ifconfig and ethtool's output) to the
one from another machine which used to work in the exact same situation.

It turns out that it's probably a bug in the ethernet card's driver.
At least after playing around with "ethtool -s eth0 speed 100 duplex
full" and "ethtool -s eth0 speed 1000 duplex full", the freezes are
now gone.

Thanks for putting me on the right path,


        Stefan

[toc] | [prev] | [standalone]


Back to top | Article view | comp.os.linux.networking


csiph-web