Mac dialup TCP/IP problems

(the issue is no longer relevant; this document is still online for archival purposes only)
Last major update 1/11/1997
Minor additions 4/30/1998

Everyone who follows groups such as comp.sys.mac.comm has seen reports of problems with sending letters longer than a few lines from Eudora. In the hope of narrowing this down, I would like to collect descriptions of such experiences. The "fixes" and suggestions I've seen on the Net have not been totally satisfactory.

Note that everything points to an interaction between MacTCP/OT, PPP/SLIP driver, and possibly network routing software; Eudora is almost certainly not the culprit (a victim, if anything...) Please don't blame it or its authors for the problems you are having.

If you are not sure whether your particular problem falls in this category, here are the usual symptoms:

Sending a message of similar length from Netscape's built-in mailer also results in bad karma (usually a crash, corrupted preferences, etc.) Don't test this with Netscape, since the consequences seem to be much worse than with Eudora.

I believe that this problem is related to the one seen in Netscape, where sending a longer request to the Web server (e.g. a complex query to AltaVista or similar) consistently brings up the "document contains no data" alert, while shorter queries work OK.


I've had over 40 full reports (and many more less precise ones) so far, and they don't show a clear pattern. The predominance of Global Village modems in the reports I received is probably due to the popularity of this brand, but there may also be some bugs in their firmware/software which contribute to the problem.

There also have been no reports from those who use John Nagle's Simple PPP.

In a few cases the glitch started showing up all of a sudden; people who had no problems sending longer messages, and apparently haven't changed their configuration at all, started getting the error consistently. This makes me suspect that the problem may be manifesting itself only with certain types of PPP and SLIP servers, and may suddenly appear when the service provider installs a new server.

Several people suggested fixes that seemed to work for them: reduce computer-modem speed to 14.4 kbps; trash the (presumably corrupted) PPP preferences file; make sure AppleTalk is disabled; make sure the LAP-M error correction is on; zap the PRAM (start up with command, option, p and r keys down).

One report indicated that disabling "MTU Path Discovery" in the OT 1.1.1 PPP panel fixed the problem (at the expense of reduced upload speed).


Added 4/30/98 Rich Inacker reports consistent problems with one specific ISP, and a fix for that case: using the OT Advanced Tuner utility to reduce the maximum segment size (related to MTU) to 536 bytes. He offers to send the Tuner configuration file on request. Thanks!

In addition to this Steve Dorner himself recommends running the following AppleScript: "tell application "eudora" to set setting 5816 to 256". I wasn't able to try it, because the only "broken" setup I had access to miraculously fixed itself a few weeks ago. I've had one report which indicated that this trick didn't help.

I was recently able to "fix" a Performa 6216 CD with a Global Village Teleport Gold II by adding %C0 to the modem init string in MacSLIP modem definitions. That command according to GV manuals disables data compression. However, I had tried this on the same computer before, with no luck, so there must have been another factor involved. Moreover, I was just informed that after turning VM on everything got royally messed up, and after turning it off Eudora stopped sending long messages again.

I am including more recent observations (mostly in technical jargon) below.



If you have experienced this problem, and if you are willing to spend a few minutes, please fill out the form below. Please refrain from submitting comments that only say "there's nothing wrong with modem XXX and software XXX, it works for me." The problem is real and has been affecting many people.

Your personal information will never be used for anything other than (possibly) me contacting you with a request for more details or clarification. Naturally, you can leave those fields blank if you don't believe this assurance.

It would also be helpful if you could enable extended logging in Eudora, and then send me a log of one or two failed send attempts. To do so, please download the suitable Eudora Plug-in by clicking on this link. Your browser should be able to handle decoding from the BinHex format. Put the resulting file LOG_TRANS+NAV in the Eudora Folder (inside the System Folder) and restart Eudora. However, by now I have a pretty clear idea of what is happening on the Eudora side, so this isn't too important.

(the form is no longer active)

Your name: E-mail address:

Mac type: specific model: MacOS version:

Serial driver name and version (e.g. FreePPP 1.0.4):

Modem make and type (internal or external?):

Modem control software, if any, and version:

Modem init string:

Hardware handshaking used:

TCP/IP driver: version:

Eudora version:

Exact text of the error message Eudora shows:

Netscape version:

Have you found any solution which works for you?

Other comments (anything that might be relevant):

Thanks again.


More details

Graham Wilmott, while tracking down the "send problem", noticed incorrect behavior involving the so-called MTU value in network packets. MTU is the "maximum transfer unit", a number that the network devices negotiate to make sure that none of them sends more data in a single packet than the others are willing to process. Its normal value is 1460, but in some circumstances (lousy modem connection, busy network) there may be a request to lower it. Experts should ignore my simplifications, please.

Seeing exactly what happens is difficult because there many elements are involved in sending a mail message through a dial-up link, and I have access to only a few of them:

  Eudora -> MacTCP or OT -> PPP or SLIP driver -> local modem ->
  -> remote modem -> PPP or SLIP server -> routers -> SMTP server
On a few occasions I managed to reproduce the problem and I ran some traces on my network. The problem seems to occur when one element in this chain instructs others to lower the MTU value (e.g. to just under 500 bytes). The first packet larger than this (which in an SMTP transaction is the first fragment of the body of the letter, if the text exceeds 5 or so lines) is sent to the server with an incorrect size, and everything stalls.

From Eudora's point of view, everything goes well until it sends the terminator sequence (period-newline-newline) and expects the SMTP server to acknowledge the receipt with "DATA OK". But the server doesn't acknowledge it, because the first large packet is not transmitted correctly. The server never sees the subsequent data! Eudora waits for a while and then puts up an error message.

From the mail server's side, only a garbled fragment of the first large packet is seen, and nothing else. The server thinks that the client's link went down, and after a timeout period logs this as "connection reset by peer".

As Graham discovered, there are times when the MTU negotiation does work, and all parties agree to the lower value. The transfer then succeeds. This seems to be the case when the SMTP host is on a different subnet than the sending Mac, as if MacTCP or PPP drivers ignored the MTU negotiation with hosts on the same subnet, but paid attention to it when the subnet is different. However, I could not reproduce this: when my connections failed, they failed no matter which server I tried, so this cannot be the full story.

Moreover, I still don't understand the failure: it would make sense if the network side requested the lower MTU, the Mac ignored it, and sent packets which were too large and caused some sort of overruns. But some traces indicate that it is the Mac that requests the lower value. When that request is honored by the network side, everything works. The failure seems to occur when that request never makes it to the network end; but that shouldn't matter - the server side doesn't send any data longer than a few bytes during the transaction.

To diagnose this problem fully, one would ideally have to have: a sniffer next to the dialup server, a serial port monitor on the Mac, a debugging version of MacTCP and FreePPP, and finally the ability to reproduce the failure with some regularity. I don't have access to any of it, so my chances of success are slim. All information which might shed light on this is very welcome!

behr@math.niu.edu