Re: I/O EOF Help - I'm stuck...
On Wed, 20 Apr 2005, Randall Gellens wrote: > > I'm beginning to believe that it was a client disconnect. It's very hard to > > tell why on the client machine ALL POP3 clients fail. Eudora, Outlook > > 2003, and a Telnet to port 110.. > > Interesting that all clients fail. It suggests something is getting between them and the actual pop3 session. Is there any antivirus stuff running? Most of the interceptor proxies on client machines are badly coded. AB
Re: I/O EOF Help - I'm stuck...
At 05:51 PM 4/20/2005, Clifton Royston wrote: On Wed, Apr 20, 2005 at 12:15:32PM -0700, Phil Kemp wrote: > It was definitley not a QUIT.. > > I'm beginning to believe that it was a client disconnect. It's very hard to > tell why on the client machine ALL POP3 clients fail. Eudora, Outlook > 2003, and a Telnet to port 110.. This sounds to me like you might still be running into the AV software issue. It is possible that Symantec (you did say it was Symantec NAV, right?) may have changed their MO for clientside POP filtering from changing the mail client settings in Eudora/etc. as they used to do, to silently performing TCP redirection to the NAV local proxy and rewriting the session commands on the fly so that they can do their spam and AV filtering. Norton intercepts ports 110 and 25, yes. Put up Qpopper on port 109 and see if that gets you running. If so, put up qpopper on port 995 and SMTP on 465 to work around issues with people running Norton AV. That's what we're doing to deal with users running Norton AV 2005. To debug this, or at least to verify if it's happening, you'll need to run tcpdump on the server POP session, while connecting to POP via telnet from the suspect box. If you're typing one thing, but you're seeing something quite different come across the wire and hit the POP server, then you can be fairly sure that something like that is going on inside the client machine. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect "I'm gonna tell my son to grow up pretty as the grass is green And whip-smart as the English Channel's wide..." -- 'Whip-Smart', Liz Phair
Re: I/O EOF Help - I'm stuck...
What type of net access do you have on this box. I know you said it had 2 interfaces, but what kind? Where's it go between there and the mailserver? Sounds like plain ole' connection issues to me. suspected culprits: pppoe mtu or dialup modem line noise if you are on an internet link. If it's on a lan, try plugging the XP box directly into the Redhat box with a crossover cable. If that works, then you've got somewhere to look next. Ken Phil Kemp wrote: It was definitley not a QUIT.. I'm beginning to believe that it was a client disconnect. It's very hard to tell why on the client machine ALL POP3 clients fail. Eudora, Outlook 2003, and a Telnet to port 110.. All net traffic is fine... ftp, http, CIFS.. They all work fine and at full bandwidth.. I'll look into the HUP on linux side... More when I get more data.. thanks PK On Wed, 20 Apr 2005 11:23:20 -0700, Randall Gellens wrote The log snippit starts with Qpopper cleaning up the connection. It would be helpful to see what happened prior to that point, especially what it was that made Qpopper start cleaning up. Was it a QUIT? A client disconnect? A HUP singal? -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- It wasn't as easy to get programs right as we had thought. --Wilkes, 1949 -- Phil Kemp [EMAIL PROTECTED]
Re: I/O EOF Help - I'm stuck...
On Wed, Apr 20, 2005 at 12:15:32PM -0700, Phil Kemp wrote: > It was definitley not a QUIT.. > > I'm beginning to believe that it was a client disconnect. It's very hard to > tell why on the client machine ALL POP3 clients fail. Eudora, Outlook > 2003, and a Telnet to port 110.. This sounds to me like you might still be running into the AV software issue. It is possible that Symantec (you did say it was Symantec NAV, right?) may have changed their MO for clientside POP filtering from changing the mail client settings in Eudora/etc. as they used to do, to silently performing TCP redirection to the NAV local proxy and rewriting the session commands on the fly so that they can do their spam and AV filtering. To debug this, or at least to verify if it's happening, you'll need to run tcpdump on the server POP session, while connecting to POP via telnet from the suspect box. If you're typing one thing, but you're seeing something quite different come across the wire and hit the POP server, then you can be fairly sure that something like that is going on inside the client machine. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect "I'm gonna tell my son to grow up pretty as the grass is green And whip-smart as the English Channel's wide..." -- 'Whip-Smart', Liz Phair
Re: I/O EOF Help - I'm stuck...
At 12:15 PM -0700 4/20/05, Phil Kemp wrote: It was definitley not a QUIT.. I'm beginning to believe that it was a client disconnect. It's very hard to tell why on the client machine ALL POP3 clients fail. Eudora, Outlook 2003, and a Telnet to port 110.. Interesting that all clients fail. I'd suggest a client-side trace or a TCP packet trace. Or, a kernel trace on the server side (run Qpopper on a new port and run it via ktrace, truss, or the equivalent on your platform). To enable client-side tracing in Eudora: On Macs, drag the "esoteric settings" plug-in (which comes with Eudora) from the "Extra Plugins" folder to the "Eudora Stuff" folder. Quit and restart Eudora. Then in your Eudora settings go to "Logging". Check "all bytes transferred". On Windows, move the "esoteric.epi" plug-in (which comes with Eudora) from the "extrastuff" folder to the same folder as the "eudora.exe" file. Quit and relaunch Eudora. Then in your Eudora settings go to "Logging". Check "all bytes sent" and "all bytes received".
Re: I/O EOF Help - I'm stuck...
It was definitley not a QUIT.. I'm beginning to believe that it was a client disconnect. It's very hard to tell why on the client machine ALL POP3 clients fail. Eudora, Outlook 2003, and a Telnet to port 110.. All net traffic is fine... ftp, http, CIFS.. They all work fine and at full bandwidth.. I'll look into the HUP on linux side... More when I get more data.. thanks PK On Wed, 20 Apr 2005 11:23:20 -0700, Randall Gellens wrote > The log snippit starts with Qpopper cleaning up the connection. It > would be helpful to see what happened prior to that point, > especially what it was that made Qpopper start cleaning up. Was it > a QUIT? A client disconnect? A HUP singal? > -- > Randall Gellens > Opinions are personal;facts are suspect;I speak for myself only > -- Randomly-selected tag: --- > It wasn't as easy to get programs right as we had thought. >--Wilkes, 1949 -- Phil Kemp [EMAIL PROTECTED]
Re: I/O EOF Help - I'm stuck...
The log snippit starts with Qpopper cleaning up the connection. It would be helpful to see what happened prior to that point, especially what it was that made Qpopper start cleaning up. Was it a QUIT? A client disconnect? A HUP singal? -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly-selected tag: --- It wasn't as easy to get programs right as we had thought. --Wilkes, 1949
Re: I/O EOF Help - I'm stuck...
On Mon, 18 Apr 2005, Phil Kemp wrote:
> See the attached file for the debug log output...
Well, it all looks "normal" to me until this line:
Apr 18 10:45:02 nakiska popper[24011]: I/O error flushing output to
client kemp at ...: Operation not permitted (1) [pop_send.c:689]
The relevant code of pop_send.c is:
664 /*
665 * Flush the output that might be buffered to client
666 */
667 void
668 pop_write_flush ( POP *p )
669 {
670 int rslt = 0;
...
681 rslt = fflush ( p->output );
...
684 if ( rslt == EOF ) {
...
689 pop_log ( p, POP_NOTICE, HERE, ... );
...
694 hangup = TRUE;
695 } /* flush failed */
...
700 }
Note particularly lines 681 and 684. I'm still left believing that
Qpopper at least has indications that the client has already left the
connection.
If I read your log extract correctly, this is from after a QUIT has been
issued. Do you have any (debug-level) logs of this happening during a
manual RETR request? Perhaps a similar level log of an entire session?
--
--
Sylvain Robitaille [EMAIL PROTECTED]
Systems analyst Concordia University
Instructional & Information TechnologyMontreal, Quebec, Canada
--
Re: I/O EOF Help - I'm stuck...
On Mon, 18 Apr 2005, Phil Kemp wrote: > Now for some reason that I cannot determine, the pop session abnormally > terminates at the point where the messages are being retrieved. Telnet > sessions to port 110 show that the login process succeeds, the LIST > command shows the messages. > > Once I issue the RETR command the connection drops. This is when issuing RETR during a telnet session to the POP server? Does it happen regardless of the message you're asking to RETR, or only with one (or more) specific message(s)? Are you able to verify that the mail spool isn't corrupted somehow? I'll be interested in seeing what more you find about this. I've seen what I think is similar behaviour as you describe, but from what I'm able to see it has always looked to me as though the *client* is dropping the connection ... -- -- Sylvain Robitaille [EMAIL PROTECTED] Systems analyst Concordia University Instructional & Information TechnologyMontreal, Quebec, Canada --
Re: I/O EOF Help - I'm stuck...
On Mon, 18 Apr 2005 15:23:19 -0400 (EDT), Sylvain Robitaille wrote > On Mon, 18 Apr 2005, Phil Kemp wrote: > > > Now for some reason that I cannot determine, the pop session abnormally > > terminates at the point where the messages are being retrieved. Telnet > > sessions to port 110 show that the login process succeeds, the LIST > > command shows the messages. > > > > Once I issue the RETR command the connection drops. > > This is when issuing RETR during a telnet session to the POP server? Yes.. > Does it happen regardless of the message you're asking to RETR, or only > with one (or more) specific message(s)? Any message > Are you able to verify that > the mail spool isn't corrupted somehow? Yes the spool is fine. openmail, elm, mutt, and mail all read it fine. > > I'll be interested in seeing what more you find about this. I've > seen what I think is similar behaviour as you describe, but from > what I'm able to see it has always looked to me as though the > *client* is dropping the connection ... See the attached file for the debug log output... Any guidance is most appreciated... Cheers PK > > -- > -- > Sylvain Robitaille [EMAIL PROTECTED] > > Systems analyst Concordia > University Instructional & Information TechnologyMontreal, > Quebec, Canada > -- -- Phil Kemp [EMAIL PROTECTED] Apr 18 10:45:02 nakiska popper[24011]: non-server mode; copying any new msgs back fromtemp drop (4) to spool (5) [pop_updt.c:823] Apr 18 10:45:02 nakiska popper[24011]: touchlock() called [pop_updt.c:831] for /var/mail/kemp.lock [maillock.c:612] Apr 18 10:45:02 nakiska popper[24011]: truncated temp drop (4) [pop_updt.c:865] Apr 18 10:45:02 nakiska popper[24011]: Unlinked [pop_updt.c:866] temp drop (/var/mail/.kemp.pop) [pop_updt.c:145] Apr 18 10:45:02 nakiska popper[24011]: mailunlock() called [pop_updt.c:868] for /var/mail/kemp.lock [maillock.c:579] Apr 18 10:45:02 nakiska popper[24011]: +OK Pop server at nakiska.pkemp.com signing off. [popper.c:360] Apr 18 10:45:02 nakiska popper[24011]: I/O error flushing output to client kemp at 63.200.73.211 [63.200.73.211]: Operation not permitted (1) [pop_send.c:689] Apr 18 10:45:02 nakiska popper[24011]: (v4.0.5) Ending request from "kemp" at (63.200.73.211) 63.200.73.211 [popper.c:377]
I/O EOF Help - I'm stuck...
I am using qpopper on a linux RH 7.1 system and had been having no problems with it up until a couple of weeks ago. I typically access the linux machine from a winXP box. Eudora worked fine, Outlook worked fine, telnet to port 110 worked fine. Now for some reason that I cannot determine, the pop session abnormally terminates at the point where the messages are being retrieved. Telnet sessions to port 110 show that the login process succeeds, the LIST command shows the messages. Once I issue the RETR command the connection drops. I have compiled in and turned on debug and have the log files. I hesitate to post them in case this is known issue. I have googled it and found spotty references but nothing definitive.. I should note that this behaviour is seen on two different net interfaces on the winxp box, with and without the firewall. I am running SP2, but the behaviour was also present on SP1. Disabling Symantec Virus does nothing either... I am completely stumped... BTW, Eudora happily sends email via SMTP and my web access is fine using browsers and other program Any help would be most appreciated.. Cheers Phil Kemp -- Phil Kemp [EMAIL PROTECTED]
