jdh@raistlin.udev.cdc.com (jd holmbeck x-3255) (03/09/91)
Has anyone been able to use the Eudora POP mail client on the Mac side of
A/UX? We have several Mac IIs with A/UX 2.0 and Apple Ethernet cards. We
have our POP and SMTP servers on another UNIX machine. We installed
Eudora on the Mac side of our A/UX machines. We can connect to the
POP server and get mail with no problems. We can connect to the SMTP
server and send small (about two line) messages with no problems.
However, we cannot send large messages to the SMTP server. Eudora
appears to send to first part of the message and then issues the
following alert box:
That pesky MacTCP is acting up
again.
The WDS pointer was 0.
tcp.c 115
OK
After clicking OK, Eudora tries to QUIT the connection with the SMTP
server but it times out after 20 seconds.
We tried using other SMTP servers, but we got the same response whether
the server was on a Sun, a MIPS, or an A/UX machine.
We can send large messages from non-A/UX Macs whether through an
Ethernet Card or through Apple Talk and a GatorBox. We can also
send large messages on A/UX using TechMail.
Does anyone have any ideas how we might get around this problem (other
than getting rid of A/UX or using TechMail)?
Thanks for any insight
Jeff Holmbeck
Control Data Corporation
jdh@udev.cdc.com
(612)482-3255kdb@macaw.intercon.com (Kurt Baumann) (03/14/91)
In article <31174@shamash.cdc.com>, jdh@raistlin.udev.cdc.com (jd holmbeck x- 3255) writes: > Path: intercon!uupsi!cmcl2!hsdndev!wuarchive!uunet!timbuk!shamash!jdh@raistlin.udev.cd c.com > From: jdh@raistlin.udev.cdc.com (jd holmbeck x-3255) > Newsgroups: comp.sys.mac.comm,comp.unix.aux > Subject: Eudora POP mail client and A/UX 2.0 > Message-ID: <31174@shamash.cdc.com> > Date: 8 Mar 91 18:37:24 GMT > Sender: usenet@shamash.cdc.com > Reply-To: jdh@raistlin.udev.cdc.com (jd holmbeck x-3255) > Followup-To: comp.sys.mac.comm > Organization: Control Data Corp., Arden Hills, MN > Lines: 39 > > > After clicking OK, Eudora tries to QUIT the connection with the SMTP > server but it times out after 20 seconds. > We have run into some problems with MacTCP not closing connections when being run in the Mac partion of A/UX. I don't know if this is related to the problems you have been having but it does point to some things that need to be worked on with MacTCP and A/UX. I am sure that Apple is aware of these. > We tried using other SMTP servers, but we got the same response whether > the server was on a Sun, a MIPS, or an A/UX machine. > > We can send large messages from non-A/UX Macs whether through an > Ethernet Card or through Apple Talk and a GatorBox. We can also > send large messages on A/UX using TechMail. > > Does anyone have any ideas how we might get around this problem (other > than getting rid of A/UX or using TechMail)? > Sure get in touch with us and take a look at TCP/Connect II with mail SMTP/POP2 and POP3. Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.
dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/14/91)
>> After clicking OK, Eudora tries to QUIT the connection with the SMTP >> server but it times out after 20 seconds. >We have run into some problems with MacTCP not closing connections when being >run in the Mac partion of A/UX. There is some sort of BAD THING happening around connection closure. I find that 3com's EtherLink SE board exhibits similar (but not identical) symptoms under MacOS. A race condition seems to exist sometime during the Close/Receive/Release process; if you slow it down (by tracing with a debugger, for example) the problem goes away. (Fun, fun, fun to debug.) I also find that the exact same calling sequence and timing works with some services, but not others. SMTP seems to be a problem, whereas POP3 is not. It may have something to do with the order in which the final dance is done by the various servers. I think the answer is going to involve packet dumps and analysis (yuck), unless someone who knows would like to pipe up. I hate to point fingers, and it may indeed be my fault, but I *think* this is a bug with a big Apple painted on its back. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/15/91)
John Norstad writes: >Steve Dorner writes: >> A race condition seems to exist sometime during the Close/Receive/Release >> process; if you slow it down (by tracing with a debugger, for example) >> the problem goes away. (Fun, fun, fun to debug.) > >That's called a "Heisenbug". They're the most interesting kind :-) I'll have to remember that one. Anyway, problem solved. The bug did indeed have a large Apple painted on it, but the area with the bite showed (alas) part of my face. The problem will be fixed as soon as my trusty alpha testers earn their keep. The faint of heart should stop reading now. When you close a MacTCP connection, you must do the following: - Close your side. - Read data until the other side closes. - Release the connection. Due to a missing "!", I was neglecting the read data step. So, what was happening was: 1. I close. 2. I release. 3. The SMTP final message arrives. 4. THE MAC EXPLODES Step #4 is Apple's fault; unsolicited packets seem to put MacTCP in quite a tizzy. MacTCP sends a Reset Connection (good), but then dies like a dog (bad). A robust TCP implementation would tolerate my mistake. The reason this is timing dependent is that if step #3 (final SMTP message) happens to arrive in MacTCP before step #2 (connection is released), there is no problem. The sensitivity of the 3com card to this problem is probably due to it having a different method of 'interleaving' sends and receives. Now, I'll fess up to neglecting to read all the data for the connection ("Bad Steve! Bad!"), and fix Eudora by, say, Monday. I'd like Apple to do the same for MacTCP (yeah, right). -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
schiffer@stsci.EDU (Skip Schiffer) (03/18/91)
Steve Dorner writes >When you close a MacTCP connection, you must do the following: > >- Close your side. >- Read data until the other side closes. >- Release the connection. Just to add fuel to the fire (:-) ) I noted that using NCSA Telnet with MacTCP can result in a crash and burn of the Mac if you have the following scenario: - open telnet session on host - crash macintosh (maybe by doing my typical development :-)) - open new telnet session on host - note that there are two session on host - kill old session - B O O M It sure sounds as if this problem is the same as the one that Steve indicates and means that the MacTCP problem is not just with Eudora. -- | F. H. Schiffer 3rd | | | schiffer@stsci.edu | I speak for myself alone. | | scivax::schiffer | |
amanda@visix.com (Amanda Walker) (03/19/91)
dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:
When you close a MacTCP connection, you must do the following:
- Close your side.
- Read data until the other side closes.
- Release the connection.
Due to a missing "!", I was neglecting the read data step.
<"thud" sound of head hitting desk>
Well, that explains a long-standing weirdness. Funny, I always assumed
that a TCPRelease would actually make the stream go away, whatever
state it was in. Silly me.
--
Amanda Walker amanda@visix.com
Visix Software Inc. ...!uunet!visix!amanda
--
"There is always something more important than what you are doing."
-- Sriram Ramkrishnaowen@raven.phys.washington.edu (Russell Owen) (03/19/91)
In article <2369@stsci.EDU> schiffer@stsci.EDU (Skip Schiffer) writes: >...using NCSA Telnet with MacTCP can result in a crash and burn of the Mac >if you have the following scenario: > > - open telnet session on host > - crash macintosh (maybe by doing my typical development :-)) > - open new telnet session on host > - note that there are two session on host > - kill old session > - B O O M I haven't seen this (yet, anyway). I have to kill sessions left over -- usually from Mac crashes (sigh), but sometimes from the connection dying -- and I've never had it cause me any trouble. My config: System 6.0.5, NCSA/BYU Telnet 2.3.4, MacTCP 1.0.1, various Macs (one with an ethernet card). The other end is a VAX running Multinet software (very reliable). Is the problem intermittant, or does it happen every time? -- Russell owen@raven.phys.washington.edu
schiffer@stsci.EDU (Skip Schiffer) (03/19/91)
In article <2369@stsci.EDU> schiffer@stsci.EDU (Skip Schiffer) writes: >...using NCSA Telnet with MacTCP can result in a crash and burn of the Mac >if you have the following scenario: The system is an SE/30, system 6.0.5, using multifinder, NCSA Telnet 2.4 beta 9, MacTCP 1.0.1 and an Ether+ SCSI Ethernet box. The crashs are approximately 80% with both a Sun Unix box (BSD? Unix) and VAX with Mulitnet. Note none of the crashes are immediate. The only _safe_ manner I have found to eliminate the extra sessions is to log into the VAX with the LAT connection tool and either kill the session on the VAX or "Set host" to the Unix box and kill the session. Provided Telnet is not running, there is no crash. (if it is open with no sessions the system crashes when you open a session.) The 80% figure is what makes me assume that the problem is likely to be the timing one which Steve points out. Note that both the VAX and the SUN are usually very heavily loaded, whereas my SE/30 normally does not have any background processing occuring. In addition the fact that I use the LAT tool through the Ethernet box sort of exonerates the everything downstream of MacTCP. -- | F. H. Schiffer 3rd | | | schiffer@stsci.edu | I speak for myself alone. | | scivax::schiffer | |
mcdougal@cs.uchicago.edu (03/19/91)
In article <18640@milton.u.washington.edu> owen@raven.phys.washington.edu (Russell Owen) writes: >I haven't seen this (yet, anyway). I have to kill sessions left over -- >usually from Mac crashes (sigh), but sometimes from the connection dying -- >and I've never had it cause me any trouble. My config: System 6.0.5, NCSA/BYU >Telnet 2.3.4, MacTCP 1.0.1, various Macs (one with an ethernet card). >The other end is a VAX running Multinet software (very reliable). I don't think NCSA/BYU Telnet 2.3.4 uses MacTCP, does it? -Tom (McDougal@cs.uchicago.edu)