[Pan-users] Re: Pan "timing out"

[Duncan]

Ron Blizzard <address@hidden> posted
address@hidden, excerpted
below, on  Wed, 27 May 2009 23:45:44 -0500:

> I&#39;ve gone back to Pan (0.133 on CentOS 5.3) but now remember why I
> started using Thunderbird. For some reason Pan &quot;times out&quot;
> when I&#39;m writing a longer response (maybe 2 or 3 minutes). When I
> try to send the response Pan just goes into an endless
> &quot;Sending&quot; loop. My work around is to copy and save my
> response, quit out of Pan, restart Pan and respond again (by cutting and
> pasting). It drives me nuts because I&#39;ve got my newsgroups set up to
> just show unread messages and to mark all messages read when leaving the
> group.. <br> <br>My main news server is Motzarella (Charter doesn&#39;t
> work most of the time). But even when Charter is working, I think it
> does the same thing as Motzarella. It&#39;s like Pan loses connection
> (or, rather, is disconnected) and has no mechanism for reconnecting
> (until you restart it). Neither Opera, Thunderbird or KNode have this
> problem. <br> <br>Is there a setting, or configuration option that would
> fix this? I love the way Pan is set up (I use the Tabbed layout) but
> this &quot;timing out&quot; is extremely irritating.<br
> clear="all"><br>Thanks for any advice or pointers.<br> <br>-- <br>RonB
> -- Using CentOS 5.3<br>

[The below comes across a bit strong.  Please understand it's nothing 
personal.]

First, there's a reason pan doesn't do HTML.  HTML in mail and news is 
for spammers, crackers and other malware distributors trying to hide 
their evilness.  AOLers and others knowing no better are also known to 
use it.  At the same time, those who actually believe their message is 
worth reading on its own without having to be dressed up by fancy stuff 
don't need HTML to convey their message.

I'll let you decide which shoe fits, but I hope it's the latter, now that 
you've been asked, and you decide your messages are actually worth 
reading of their own merit, without the HTML garbage. =:^)

Even if you choose to use HTML mail elsewhere (and I'd recommend against 
it, I know /I/ wouldn't want to be known as /that/ kind of person), at 
least try to respect the pan list enough not to use it here.  (Among 
other reasons, some of us use pan to read the group via gmane, and it 
makes a mess of posts as you may be able to see above.)

.....

Meanwhile, pan sends keep-alives to keep the connection going.  While 
most servers time you out anyway after some length of time (typically 
10-15 minutes, low-end, depending on the server of course), normally you 
can simply reconnect when necessary, and while it might take a couple 
seconds to connect, no big deal.  I know that's the way it works here, 
and has always worked with all the servers I've used.

I know nothing about Charter, but I believe several regulars here use pan 
with motzarella, without the issue you've described.  Thus, it's likely 
to be either your ISP (possible) or more likely, something at your end 
(see below).

As for pan, I don't know of any way to shutoff the keep-alives and make 
it close connections immediately when it's not using them, without 
changing the source code itself.  (I just looked in the config files and 
didn't see anything there that looked likely to control that, either.)  
But, there's a couple things you might try.

First, how many connections do you have pan configured to use, and how 
many do your servers allow?  While you often want the four per server pan 
allows in the GUI if you're doing binaries, for text groups only, as with 
motzarella, two connections (or even one) should be fine.  I've never 
used motzarella myself, but I just checked and the web site says four 
connections allowed, so that may be what you are using.  Setting pan to 
one or two might allow you to grab another allowed connection when it 
times out -- provided pan knows it's timed out. (Are you getting an error 
in pan's error log, or not?  If so, pan knows it's timed out, otherwise, 
it doesn't, and it's obviously trying to use a stale connection that's 
timed out elsewhere.)

Second, it'll be a bit of a chore to do it manually, but you can probably 
use pan's offline feature to kill existing connections -- PROVIDED you do 
it before whatever times them out. IOW, if you wait until after pan's 
hanging, taking it offline's likely to hang as well due to the fact that 
the TCP close connection packets will get as hung as the attempt to send 
does, so you have to do it as soon as you stop actively using the 
connection.  I think there's a hotkey to toggle on/offline that should 
make it easier.  (I've long since made my own hotkey assignments here, 
and nearly equally long since forgot what the defaults were for most 
things, but IIRC it was L or maybe O.)  You should then be able to wait 
until you have a couple things ready to go if desired, and toggle it 
online to do them, then back off.  Doing it that way should close the 
connection properly, allowing a new one to open properly when you need it.

.....

Meanwhile, I have an educated guess at what the problem is.  Are you 
direct-connecting to your modem, or are you using a router (noting that 
some modems have a built-in router)?  The problem sounds to me very much 
like a mis-configured NAPT that has WAY too short a timeout on inactive 
TCP connections.  That's very typical of some cheap crap-quality routers, 
tho it's technically possible (but far less likely) to do it with a 
firewall on a direct-connected computer.

FWIW, such connection timeouts are often a full 24 hours, tho in low- 
resource many-dead-connections conditions something like an hour or two 
(or really, anything longer than the server timeout, typically 15 minutes 
as I mentioned up top) may be better, using less resources while long 
enough to work.  If you're correct in your time estimates and I'm correct 
in my guess, your TCP idle connection timeout may be five minutes or 
less, which, as you discovered, can be quite problematic. =:^(

Thus, unless it's crap-quality routing/NAPT at your ISP (and if you're 
behind NAPT at the ISP, they really /are/ crap!), I'd say odds strongly 
favor you running a presently mis-configured router.  Depending on what 
brand, model, and most importantly firmware it is, there's some chance 
the TCP timeout is configurable, and that'll fix it.  Alternatively, 
there may be a newer firmware available that will fix it.  Another 
alternative, provided it's a compatible router, would be upgrading to a 
community based firmware such as OpenWRT, DD-WRT, Tomato, etc, tho that's 
a significantly bigger step as you're often voiding the warranty doing 
something like that.

So let us know what sort of router you have, if any, and what firmware, 
and /possibly/ someone here can help.  You can also try the appropriate 
equipment forums at broadbandreports.com (aka dslreports.com).  They're 
actually more likely to be of help with this sort of thing, as it's 
really not a pan problem at that point, and some of those guys deal with 
fixing that sort of problem on their respective hardware all the time.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman