Hi Brian,

Just to keep you up to date with goings on.

Over the past few days I have been running tcpdump / wireshark on the server 
and client machines, going over the pcap files and getting my users to note 
down when they have problems.

There seems to be a consistant pattern. Below is a sample of the dump files 
around the time of connection problems:

Client Machine:
 185156 2007-07-04 16:32:27.708162 192.168.10.6          192.168.10.93         
IMAP     Response: 58 OK IDLE completed
 185157 2007-07-04 16:32:27.737345 192.168.10.93         192.168.10.6          
IMAP     Request: 59 check
 185158 2007-07-04 16:32:27.738016 192.168.10.6          192.168.10.93         
TCP      [TCP ACKed lost segment] imap2 > 1665 [RST] Seq=10795 Len=0
 185159 2007-07-04 16:32:27.785269 192.168.10.93         192.168.10.6          
TCP      1879 > imap2 [SYN] Seq=0 Len=0 MSS=1460
 185160 2007-07-04 16:32:27.785929 192.168.10.6          192.168.10.93         
TCP      imap2 > 1879 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
 185161 2007-07-04 16:32:27.800737 192.168.10.93         192.168.10.6          
IMAP     Request: DONE
 185162 2007-07-04 16:32:27.801389 192.168.10.6          192.168.10.93         
TCP      [TCP ACKed lost segment] imap2 > 1627 [RST] Seq=42544 Len=0
 185163 2007-07-04 16:32:27.829501 192.168.10.93         192.168.10.6          
TCP      1880 > imap2 [SYN] Seq=0 Len=0 MSS=1460
 185164 2007-07-04 16:32:27.830151 192.168.10.6          192.168.10.93         
TCP      imap2 > 1880 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
 185165 2007-07-04 16:32:28.069810 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: 58 OK IDLE completed
 185166 2007-07-04 16:32:28.252800 192.168.10.93         192.168.10.6          
TCP      1879 > imap2 [SYN] Seq=0 Len=0 MSS=1460
 185167 2007-07-04 16:32:28.253473 192.168.10.6          192.168.10.93         
TCP      imap2 > 1879 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
 185168 2007-07-04 16:32:28.362154 192.168.10.93         192.168.10.6          
TCP      1880 > imap2 [SYN] Seq=0 Len=0 MSS=1460
 185169 2007-07-04 16:32:28.362823 192.168.10.6          192.168.10.93         
TCP      imap2 > 1880 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
 185170 2007-07-04 16:32:28.690274 192.168.10.93         192.168.10.6          
TCP      1879 > imap2 [SYN] Seq=0 Len=0 MSS=1460
 185171 2007-07-04 16:32:28.691019 192.168.10.6          192.168.10.93         
TCP      imap2 > 1879 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0
 185172 2007-07-04 16:32:28.789758 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: 58 OK IDLE completed
 185176 2007-07-04 16:32:28.909008 192.168.10.93         192.168.10.6          
TCP      1880 > imap2 [SYN] Seq=0 Len=0 MSS=1460
 185177 2007-07-04 16:32:28.909679 192.168.10.6          192.168.10.93         
TCP      imap2 > 1880 [RST, ACK] Seq=0 Ack=1 Win=0 Len=0

Server:
 128758 2007-07-04 16:30:41.738417 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: * 12 FETCH (FLAGS (NonJunk))
 129079 2007-07-04 16:31:28.246725 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: * BYE Disconnected for inactivity.
 129623 2007-07-04 16:32:28.034431 192.168.10.93         192.168.10.6          
IMAP     Request: DONE
 129624 2007-07-04 16:32:28.034988 192.168.10.6          192.168.10.93         
IMAP     Response: 58 OK IDLE completed
 129625 2007-07-04 16:32:28.396856 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: 58 OK IDLE completed
 129626 2007-07-04 16:32:29.116820 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: 58 OK IDLE completed
 129627 2007-07-04 16:32:30.556778 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: 58 OK IDLE completed
 129630 2007-07-04 16:32:33.436668 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: 58 OK IDLE completed
 129633 2007-07-04 16:32:39.196422 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: 58 OK IDLE completed
 129722 2007-07-04 16:32:50.716508 192.168.10.6          192.168.10.93         
IMAP     [TCP Retransmission] Response: 58 OK IDLE completed

It looks to me like there may be some network timing issues which are causing 
the client machine to reset the connection. This might explain another reason 
why I am not seeing a problem as most of the client machines have 100m/b 
cards but my predecessor built the IT managers workstation and of course put 
all the really good kit in it which means I have a Gigabit network card (or 
so I discovered when I plugged the cable into the nice new gigabit network 
switch ). I had assumed that the problem was related to the OS not the 
hardware, guess it's true what they say about ass u me ( well me anyway ).

To test the timing theory I have put a 100m/b card into the server along with 
the gigabit card, half the client machines are connecting through the 100m/b 
and the other half through the gigabit. Once again watch this space.

Thank you for all your help and suggestions thus far, hopefully I'm getting 
close to nailing this once and for all.


On Friday 29 June 2007 20:35, Brian Candler wrote:
>
> OK. Well there are several ways the session might be dropped:
>
> (1) SYN and RST.
>
> The connection was never accept()ed. Typically this means that nothing is
> listening on that port. Using telnet you'd see:
>
>
> (2) The connection is setup (SYN, SYN ACK, ACK) but then immediately torn
> down (FIN exchange)
>

>
>
> (3) The connection is setup, a response is immediately generated by the
> daemon, and the connection is torn down.

>
> (4) The connection is set up, a normal IMAP exchange starts to take place,
> but something goes wrong later on (e.g. client tries to authenticate, and
> server rejects the authentication request)
>
>
> Using your tcpdump info, if you know which client suffered the problem and
> at what time, you can find which of these scenarios applies to you.
>
> Note that you can filter the tcpdump output when reading it, e.g.
>
>     tcpdump -r mylog.pcap -nX host 1.2.3.4
>
> If you can replicate the problem using telnet to port 143 on the command
> line, then seeing *exactly* what response you get back will also
> distinguish these cases. So if it happens again, copy-paste it into an
> E-mail.

>
> Regards,
>
> Brian.

-- 
Regards,

Adrian

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Courier-imap mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap

Reply via email to