The reverse lookups are fine, but tcpdump reveils something interesting:
12:34:04.960358 jumbuck.46901 > panda.pop3: S 1209979088:1209979088(0) win 8760 <mss 1460> 12:34:04.960440 panda.pop3 > jumbuck.46901: S 432051502:432051502(0) ack 1209979089 win 32430 <mss 1410> (DF) 12:34:05.007550 jumbuck.46901 > panda.pop3: . ack 1 win 9870 12:34:05.013684 panda.4888 > jumbuck.auth: S 441368347:441368347(0) win 32430 <mss 1410,sackOK,timestamp 53043748 0,nop,wscale 0> (DF) 12:34:08.005563 panda.4888 > jumbuck.auth: S 441368347:441368347(0) win 32430 <mss 1410,sackOK,timestamp 53044048 0,nop,wscale 0> (DF) 12:34:14.005821 panda.4888 > jumbuck.auth: S 441368347:441368347(0) win 32430 <mss 1410,sackOK,timestamp 53044648 0,nop,wscale 0> (DF) 12:34:26.006299 panda.4888 > jumbuck.auth: S 441368347:441368347(0) win 32430 <mss 1410,sackOK,timestamp 53045848 0,nop,wscale 0> (DF) 12:34:35.015067 jumbuck.auth > panda.4888: R 0:0(0) win 32430 12:34:35.029509 panda.pop3 > jumbuck.46901: P 1:41(40) ack 1 win 32430 (DF) 12:34:35.063977 jumbuck.46901 > panda.pop3: . ack 41 win 9870 12:35:57.713150 jumbuck.46901 > panda.pop3: P 1:6(5) ack 41 win 9870 12:35:57.713225 panda.pop3 > jumbuck.46901: . ack 6 win 32430 (DF) 12:36:00.672225 jumbuck.46901 > panda.pop3: F 6:6(0) ack 41 win 9870 12:36:00.672281 panda.pop3 > jumbuck.46901: . ack 7 win 32430 (DF) 12:36:00.672435 panda.pop3 > jumbuck.46901: P 41:69(28) ack 7 win 32430 (DF) 12:36:00.676562 panda.pop3 > jumbuck.46901: F 69:69(0) ack 7 win 32430 (DF) 12:36:00.715324 jumbuck.46901 > panda.pop3: R 1209979095:1209979095(0) win 9870 12:36:00.716028 jumbuck.46901 > panda.pop3: R 1209979095:1209979095(0) win 0 (DF) It appears to be sending a request to the auth protocol of the external machine - which it does 4 times before getting a response (the reason for the 30s delay). The problem with this is that there is no guarantee than an external machine does not block inbound access to the auth protocol (with many stateful firewalls this is normally the case - only open a port if there was an outbound connection first). Is there anyway to tell the pop daemon NOT to try to reconnect on the auth port ? Matt At Sunday, 08-09-02 12:16 (+1000), Martin wrote: >$author = "Matt Hyne" ; > > > > If I telnet to the POP port directly, I see that indeed the following > > occurs: > > > > > telnet <my_machine> pop > > Trying www.xxx.yyy.zzz... > > Connected to <my_machine>. > > Escape character is '^]'. > > +OK POP3 panda v2001.78rh server ready > > > > And it takes a good 20s before the +OK POP3 ... line is displayed. It is > > not latency on the link - telnet/ssh is immediate. > > > > I though it might be because of the auth/ident protocol so I check I can > > access this remotely, which I can. > > > > So I am at a bit of a loss to explain why this problem persists. Anyone > > else seeing this problem too (machine is a RH7.0 box) ? > >my guess is it is doing a reverse lookup on the IP you are connecting from >and it is timing out. try 'dig -x AAA.BBB.CCC.DDD' on the redhat box, >substituting in the IP of the machine you usually connect from... > >marty > >-- >You need only two tools. WD-40 and duct tape. If it doesn't move and >it should, use WD-40. If it moves and shouldn't, use the tape. >-- >SLUG - Sydney Linux User's Group - http://slug.org.au/ >More Info: http://lists.slug.org.au/listinfo/slug -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
