Ron Blizzard <rb4cen...@gmail.com> posted f9d82c810905272145k223af0eei2d8b61f1ca08f...@mail.gmail.com, excerpted below, on Wed, 27 May 2009 23:45:44 -0500:
> I've gone back to Pan (0.133 on CentOS 5.3) but now remember why I > started using Thunderbird. For some reason Pan "times out" > when I'm writing a longer response (maybe 2 or 3 minutes). When I > try to send the response Pan just goes into an endless > "Sending" 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'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't > work most of the time). But even when Charter is working, I think it > does the same thing as Motzarella. It'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 "timing out" 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
