Still problems with hanging connections

[olaf.krause]

I still have problems with dialup connections that will not be closed because the request "hangs". This problem was almost fixed with the latest version but sometimes a POP3 Request hangs.

I use visnetic latest antivir and a ISDN Dialup connection.

The problem is not really reproducable it happens every second day. But of course it is very important because I have to pay for every minute and if the connection is not closed it will get very expensive (today the connection was enabled >2h before I manually closed it.

[Pascal]

I still have problems with dialup connections that will not be closed because the request "hangs". This problem was almost fixed with the latest version but sometimes a POP3 Request hangs.

I use visnetic latest antivir and a ISDN Dialup connection.

The problem is not really reproducable it happens every second day. But of course it is very important because I have to pay for every minute and if the connection is not closed it will get very expensive (today the connection was enabled >2h before I manually closed it.

Are all the appropriate session timeouts (Default 60 seconds) set ? A second alternative is to edit the dialup profile properties, to make it timeout after a higher level of apparent inactivity. (Some ISPs send keep alives, which is counted as traffic. Dial-up connections use a calculated value to determine if it is allowed to disconnect or not - e.g. if < 60KB received in a minute, we can disconnect. This is configurable, so you might want to try and tweak that a bit.

[olaf.krause]

In normal operation everything works fine - the dialup is closed. But sometimes a pop3 proxysession hangs. There is NO traffic, but the session is displayed in the gatekeeper activity window. If I terminate that session the connection will be closed after approx. 60sec (my timeout).

I see this error since ~5.1 it was improved in 5.2.2

1. Fixed POP3 proxy. Recent changes to support scanning had introduced a problem where small messages (able to fit entirely into a single TCP packet) had been nagled to the POP3 server response. This would mainly affect users on slow links (i.e. dialups) downloading very small messages (less than 1400 bytes).

As pop3 client I use Mercury which collects all the e-mails of different accounts and stores them into Mercurys local IMAP account.

[adrien]

So once the pop3 session hangs it no longer times out?

Normally if you can manually terminate a session from GateKeeper, that means it has not hung (its thread is still processing messages). Therefore the normal session timeout processing should also work, since it terminates sessions in the same way as GateKeeper does.

If it doesn't do this, that might indicate that a mail client is sending NOOP commands to keep the connection alive?

There should be a setting in Mercury to alter this behaviour if this is the case.. can't see why any mail client would bother though, but it is in the protocol.

Adrien

[olaf.krause]

So once the pop3 session hangs it no longer times out?

yes

Normally if you can manually terminate a session from GateKeeper, that means it has not hung (its thread is still processing messages).

Terminating it via Gatekeeper works.

I now enabled the proxy server debug and also the mercury session logs. Hopefully I can send you the log the next time it happens.

[olaf.krause]

Here the promised log:


Wingate:
**************************
03/22/04 06:43:11 192.168.0.1 Guest 0000114215 Created:
03/22/04 06:43:12 192.168.0.1 Guest 0000114215 Requested: POP3: xyz at pop.1und1.de
03/22/04 07:03:01 192.168.0.1 Guest 0000114215 Traffic 6654 84 71 6638 1190s
03/22/04 07:03:01 192.168.0.1 Guest 0000114215 Terminated exit code 2
03/22/04 07:03:01 192.168.0.1 Guest 0000115382 Created:
03/22/04 07:03:02 192.168.0.1 Guest 0000115382 Requested: POP3: xyz at pop.puretec.de
03/22/04 07:03:02 192.168.0.1 Guest 0000115382 Traffic 63 62 47 47 1s
03/22/04 07:03:02 192.168.0.1 Guest 0000115382 Terminated exit code 1
********************

In Mercury Log:
....
06:43:18.491: >> > Betreff: xxx <cr><lf>
06:43:18.491: >> ><cr><lf>
06:43:18.491: >> <cr><lf>
06:43:18.491: >> <cr><lf>
06:43:18.491: >> <cr><lf>
06:43:18.491: >> <cr><lf>
06:43:18.491: >> <cr><lf>
06:43:18.491: >> .<cr><lf>
06:43:18.491: << DELE 1<cr><lf>
06:43:19.882: >> +OK<cr><lf>
06:43:19.882: << RETR 2<cr><lf>
06:43:19.282: >> +OK 1223 octets<cr><lf>
06:43:36.271: >> X-Scanning: 20 sec<cr><lf>
06:43:57.300: >> X-Scanning: 40 sec<cr><lf>
.... all twenty seconds
07:02:58.941: >> X-Scanning: 1180 sec<cr><lf>
07:03:01.345: << QUIT<cr><lf>
07:03:01.345: 7: Socket read error 10053 (ECONNABORTED)
07:03:01.345: --- Connection closed normally at Mon Mar 22 07:03:01 2004. ---
*********************** end mercury
I terminated the session at 07:03 manually with gatekeeper. After this every things seems to work well again.

[olaf.krause]

Hi,

please comment the log I send. I'm using visnetic 4.4.3.1

[Pascal]

The X-scanning headers you are seeing are inserted when the session is busy scanning the data for the mail message. Is that a particularly large email that caused that behaviour ?

[olaf.krause]

no the email was <10kb.
After terminating the job in Gatekeeper and retry retrieving it it took only a few seconds to get the email.