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

Groups > comp.os.linux.misc > #12014 > unrolled thread

weirdness with TCP timeouts?

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

Contents

  weirdness with TCP timeouts? The Natural Philosopher <tnp@invalid.invalid> - 2014-09-08 11:25 +0100
    Re: weirdness with TCP timeouts? Tim Watts <tw_usenet@dionic.net> - 2014-09-08 17:35 +0100
      Re: weirdness with TCP timeouts? The Natural Philosopher <tnp@invalid.invalid> - 2014-09-08 17:54 +0100
        Re: weirdness with TCP timeouts? The Natural Philosopher <tnp@invalid.invalid> - 2014-09-08 18:06 +0100
    Re: weirdness with TCP timeouts? Johnny <johnny@invalid.net> - 2014-09-08 13:25 -0500
      Re: weirdness with TCP timeouts? The Natural Philosopher <tnp@invalid.invalid> - 2014-09-08 19:27 +0100
    Re: weirdness with TCP timeouts? Chick Tower <c.tower@deadspam.com> - 2014-09-19 02:33 +0000
      Re: weirdness with TCP timeouts? The Natural Philosopher <tnp@invalid.invalid> - 2014-09-19 06:30 +0100

#12014 — weirdness with TCP timeouts?

I have googled my socks off, but cant find this exact problem mentioned 
anywhere.

So here goes with a summary.

For multifarious reasons I am bringing up a new desktop based on MINT 17 
MATE Qiana. Nice release.  But that's bye the bye.

Most stuff works well - better than 14 - and what was obscure was sorted 
by googling ..

I ended up with three problems two solved by workarounds and one I cant 
get a handle on.
(the "I have an active printjob icon gets stuck in the notification area 
if a networked printer is in use. Solved by not having the print monitor 
daemon running at all)

The second issue was that ssh sessions to my remote server were timing 
out. They never used to, but I pulled the ssh keepalive down to a couple 
of minutes and now the session stays up.

The third issue I cant get around is that when accessing 
news.albanasi.net/119 as I do to chat here, Thunderbird is ALSO 
experiencing some weirdness.

IF I leave Thunderbird alone, it collects all the headers automatically, 
and then I click on an article to retrieve the actual post. Except that 
it nearly always fails on the first attempt, and never on any subsequent 
ones.

The message is 'connection refused'..

Now I may be guilty of some leap of conclusions that the data doesn't 
warrant, but it seems to me that perhaps all of these issues are related 
to a new kernel with maybe a different way of handling sockets than the old.

That is in some way sockets are being closed inside the kernel in ways 
they shouldn't be. And applications are not being notified that they 
have closed.

IN short my fevered imagination is considering the possibility that TCP 
timeouts in the kernel have changed in  unexpected ways, so that 
connections that used to exist, have been silently dropped.


3.13.0-24 is the current kernel version.

(I did have one other massively irritating issue with networking, and 
that was unbelievably slow NFS mounting, but that proved to be an NFS4 
connections being attempted against an NFS3 server.

Solved by adding -o nfsvers=3 to the mount scripts.)


Any light that can be shed on this gratefully appreciated

The problem is of course that with the jump from mint 14 to 17, not only 
has the kernel changed, but my hardware and the applications, so it's 
hard to know where to look.

I would remark that apart from this and a few other issues that are 
understood and accepted and are down to hardware limitations (being 
addressed with a credit card)  and a few things that are getting a bit 
too 'make it simple for noobs' for my taste, that this is the best linux 
distro I have ever loaded up. In terms of 'all the tools I need for the 
work I do, and no eye candy that I didn't pick myself'. So I am keen to 
get it tuned up to my taste.




-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [next] | [standalone]

#12026

On 08/09/14 11:25, The Natural Philosopher wrote:

> The second issue was that ssh sessions to my remote server were timing
> out. They never used to, but I pulled the ssh keepalive down to a couple
> of minutes and now the session stays up.

As that is possibly a reproducible and simple problem, could you put the 
timeout up and run a tcpdump against it until it dies and see if 
anything happens at the end?

> That is in some way sockets are being closed inside the kernel in ways
> they shouldn't be. And applications are not being notified that they
> have closed.
>
> IN short my fevered imagination is considering the possibility that TCP
> timeouts in the kernel have changed in  unexpected ways, so that
> connections that used to exist, have been silently dropped.

Not aware of anyhing which means bugger all here -

Just one observation - have you changed the device that provides your 
NAT (if any) to the internet recently? NAT clearing sessions could cause 
these symptoms

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

#12031

On 08/09/14 17:35, Tim Watts wrote:
> On 08/09/14 11:25, The Natural Philosopher wrote:
>
>> The second issue was that ssh sessions to my remote server were timing
>> out. They never used to, but I pulled the ssh keepalive down to a couple
>> of minutes and now the session stays up.
>
> As that is possibly a reproducible and simple problem, could you put the
> timeout up and run a tcpdump against it until it dies and see if
> anything happens at the end?
>

Mmm tcpdump is a thought.

as is netstat..

netstat -a | grep ESTABLISHED
tcp        0      0 192.168.0.6:37903       my.private.server:ssh 
ESTABLISHED
tcp        0      0 192.168.0.6:55445       four.schnuerpel.eu:nntp 
ESTABLISHED
tcp        0      0 192.168.0.6:667         tempest:nfs 
ESTABLISHED
tcp        0      0 192.168.0.6:55463       four.schnuerpel.eu:nntp 
ESTABLISHED
tcp6       0      0 ip6-localhost:41281     ip6-localhost:ipp 
ESTABLISHED
tcp6       0      0 ip6-localhost:ipp       ip6-localhost:41281 
ESTABLISHED

That shows that t'bird IS keeping nntp alive.

My guess is that the far end or the local end is timing out...

MM. a few other other  connections have popped up there in later scans.

I wonder WTF is going on..


>> That is in some way sockets are being closed inside the kernel in ways
>> they shouldn't be. And applications are not being notified that they
>> have closed.
>>
>> IN short my fevered imagination is considering the possibility that TCP
>> timeouts in the kernel have changed in  unexpected ways, so that
>> connections that used to exist, have been silently dropped.
>
> Not aware of anyhing which means bugger all here -
>
> Just one observation - have you changed the device that provides your
> NAT (if any) to the internet recently? NAT clearing sessions could cause
> these symptoms

No, that's been the same throughout.



-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

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

#12032

On 08/09/14 17:54, The Natural Philosopher wrote:
> On 08/09/14 17:35, Tim Watts wrote:
>> On 08/09/14 11:25, The Natural Philosopher wrote:
>>
>>> The second issue was that ssh sessions to my remote server were timing
>>> out. They never used to, but I pulled the ssh keepalive down to a couple
>>> of minutes and now the session stays up.
>>
>> As that is possibly a reproducible and simple problem, could you put the
>> timeout up and run a tcpdump against it until it dies and see if
>> anything happens at the end?
>>
>
> Mmm tcpdump is a thought.
>
> as is netstat..
>
> netstat -a | grep ESTABLISHED
> tcp        0      0 192.168.0.6:37903       my.private.server:ssh
> ESTABLISHED
> tcp        0      0 192.168.0.6:55445       four.schnuerpel.eu:nntp
> ESTABLISHED
> tcp        0      0 192.168.0.6:667         tempest:nfs ESTABLISHED
> tcp        0      0 192.168.0.6:55463       four.schnuerpel.eu:nntp
> ESTABLISHED
> tcp6       0      0 ip6-localhost:41281     ip6-localhost:ipp ESTABLISHED
> tcp6       0      0 ip6-localhost:ipp       ip6-localhost:41281 ESTABLISHED
>
> That shows that t'bird IS keeping nntp alive.
>
> My guess is that the far end or the local end is timing out...
>
> MM. a few other other  connections have popped up there in later scans.
>
> I wonder WTF is going on..
>
>
Further to that, I got the error again, one nntp connection vanished  on 
successful reconnection two more appeared.

Hmm.




-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

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

#12041

On Mon, 08 Sep 2014 11:25:37 +0100
The Natural Philosopher <tnp@invalid.invalid> wrote:

> The third issue I cant get around is that when accessing 
> news.albanasi.net/119 as I do to chat here, Thunderbird is ALSO 
> experiencing some weirdness.
> 
> IF I leave Thunderbird alone, it collects all the headers
> automatically, and then I click on an article to retrieve the actual
> post. Except that it nearly always fails on the first attempt, and
> never on any subsequent ones.
> 
> The message is 'connection refused'..

Albasani.net has been having problems for the last three or four days. 

I have received the same message several times.

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

#12042

On 08/09/14 19:25, Johnny wrote:
> On Mon, 08 Sep 2014 11:25:37 +0100
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> The third issue I cant get around is that when accessing
>> news.albanasi.net/119 as I do to chat here, Thunderbird is ALSO
>> experiencing some weirdness.
>>
>> IF I leave Thunderbird alone, it collects all the headers
>> automatically, and then I click on an article to retrieve the actual
>> post. Except that it nearly always fails on the first attempt, and
>> never on any subsequent ones.
>>
>> The message is 'connection refused'..
>
> Albasani.net has been having problems for the last three or four days.
>
> I have received the same message several times.
>
Hmm.

I have found a 3.13 kernel bug report referring to TCP connections being 
dropped.

Well wait and see would seem to be order of the day





-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

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

#12127

On 2014-09-08, The Natural Philosopher <tnp@invalid.invalid> wrote:
> IF I leave Thunderbird alone, it collects all the headers automatically, 
> and then I click on an article to retrieve the actual post. Except that 
> it nearly always fails on the first attempt, and never on any subsequent 
> ones.

I don't use Thunderbird for Usenet posts, and I don't use Mint (or
Ubuntu or Debian) for Usenet, but I have noticed that Thunderbird is
acting differently sometimes when I try to retrieve my e-mail.  Sometimes
it says "connecting" for a long time but my dial-up modem's lights don't
flash at all.  If I click the Get Mail button again, then T-bird does
what it's supposed to do.  Granted, this is a pretty vague reply,  and
it might be that Google Mail is doing something differently than it used
to and causing my delay, but you don't seem to have considered a possibly 
newer version of T-bird as being the cause.
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

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

#12128

On 19/09/14 03:33, Chick Tower wrote:
> On 2014-09-08, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> IF I leave Thunderbird alone, it collects all the headers automatically,
>> and then I click on an article to retrieve the actual post. Except that
>> it nearly always fails on the first attempt, and never on any subsequent
>> ones.
>
> I don't use Thunderbird for Usenet posts, and I don't use Mint (or
> Ubuntu or Debian) for Usenet, but I have noticed that Thunderbird is
> acting differently sometimes when I try to retrieve my e-mail.  Sometimes
> it says "connecting" for a long time but my dial-up modem's lights don't
> flash at all.  If I click the Get Mail button again, then T-bird does
> what it's supposed to do.  Granted, this is a pretty vague reply,  and
> it might be that Google Mail is doing something differently than it used
> to and causing my delay, but you don't seem to have considered a possibly
> newer version of T-bird as being the cause.
>
I am coming around to it.

I noticed that the persistent sockets shown by netstat actually were 
being replaced periodically.

So T'bird itself is closing and opening sockets..


-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [standalone]

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

csiph-web