Re: keep alive losing connections

On Thu, Sep 11, 2008 at 10:24 AM, johnf <jfabiani(at)yolo(dot)com> wrote:
> On Thursday 11 September 2008 09:13:14 am Scott Marlowe wrote:
>> On Thu, Sep 11, 2008 at 10:07 AM, johnf <jfabiani(at)yolo(dot)com> wrote:
>> > Hi,
>> > I have read several of the posting on the list and I'm guessing I have a
>> > router issue because I get disconnected from the database after some idle
>> > time. I'm connecting remotely to a postgres 8.3.1 on openSUSE 11. My
>> > question is how can I determine what the real cause of dropping the
>> > connection. Is it my router or the firewall on the remote server, or
>> > something else?
>>
>> Hard to say really without running some kind of network analyzer like
>> wireshark (I think that's the new name) on both ends and watching for
>> RST packets.
>>
>> But, you can usually overcome this problem by setting a lower
>> tcp_keepalivetime, something like 900 (15 minutes) or 300 (5 minutes)
>> will usually do the trick, and has the added bonus of harvesting
>> connections left behind by processes that didn't properly disconnect
>> (crashed, lost network connection) more often than once every 2 hours.
>
> In my case the program is doing a long file transfer (nothing to do with the
> database) and when it returns I discover the connection has been closed. So
> I was really hoping to find an easy way of testing where the problem is
> happening. Like I said I think it has something to do with the router
> (wireless). But it is hard to tell what the cause is from the information
> provided by the list. Of course I understand the list is about popstgres and
> not routers. But the problem is a related subject I think. Spounds like I'm
> stuck without a solution for the moment. Thanks for the help.

My experience with wireless routers has been that the only ones I
trust are running one of the open source packages, like dd-wrt
openwrt, etc... The factory firmware on almost all the others is just
crap designed to get the cheapest product out the door with the
biggest margin with no concern for quality.