BayouCity.Net - Modem Support

Cardinal (cheap, not a great modem but not bad)
Logicode (not cheap, great reviews)
PPI's. (not cheap, good reviews)

Winsock Tuning

Winsock/ppp connections should use:
(Bracketed values are the defaults)
MTU: 256 (1500)
TCP RWIN: 848 (4096)
TCP MSS: 212 (1460)
TCP RTO MAX: 60 (60)

Probably not related, but notice you have a Diamond video card, which uses an S3 graphics chip. There has been lots of problems with the S3 chip interfering with modems on Com4 -- an address conflict. So if your modem is on Com4, just for the heck of it try moving it to another com port.

It worked!

Another modem tip for users getting disconnects.

Try setting S10 to something extreme: 255 (Modem waits for 25.5 seconds after losing carrier before it disconnects). This is a bit over kill though sometimes 120 fixes the problem.

MAC modem: zoomv.32bis
init string: ATS0=0QOV1&C1&D2&Q5&Q4 Flow Control: none

From: Zoom Technical Support
Re: Dropoffs

Have your users include S10=100 in their init strings and consider buying a line noise filter from places such as Radio Shack. Lower speeds also help but that usually does not receive a favorable response. Attached below are instructions for checking the extent of line noise which exists on the line.

Try this neat little noise line test from a communications program (like COMit or the Windows Terminal accessory.) This is a feature your modem has built in and is called the E.Q.M. The modem decides what speed to connect at based on the E.Q.M.'s evaluation of your phone line at that given moment.

In the terminal screen, initialize your modem by typing:
AT&F&C1&D2S95=44 [carriage return]
after you get an OK response type:
ATDT and then a local phone number you want to connect to.
i.e. ATDT5551212 [carriage return]
after the modem connects it will display the Carrier Speed along with some other info. At that point type:
+++
you should get back an OK. Then type:
AT%Q <carriage return
you'll get back a number.

This is the relative noise level based on the carrier speed you established earlier. Now type: A/
you'll get another number. Keep typing A/ so you can get a feel for how the noise levels fluctuate on your line. What does this all mean?

If your levels are between 2-15 you have clean phone lines for that speed. If you reach 30 you have significant line noise. Above 30 is a LOT of noise and beyond 50 you risk getting disconnected.

Here's a hypothetical situation. Let's say you connected at 21600 and you measured noise levels of 47 average, that means that your modem tried connecting at 28.8 first measured levels of 120, fell back to the next lower speed of 26.4k, measured levels of 95, fell back to 24k measured 78, etc. until it reached a speed whose noise level was acceptable, in this case 21.6k.

This means that if you had forced the modem to connect at 19.2 or even 14.4 you probably would have measured noise levels of 17. The rule here is 'The higher the speed, the more significant noise becomes.' The same actual noise measured in a 14.4 connect is way lower than that measured in a 28.8 connect. You can even force your modem to connect higher than it wants to by using an Fn command and measure the levels to convince yourself. And all of this noise is of course inaudible to the human ear.

This is why you can't connect at 28.8 in your area. Try it out and see for yourself. By the way, that same modem in a different location with clearer line will always connect at 28.8.

Many of you have written to the list about a weird Macintosh bug that prevents you from reaching some sites. This only occurs if you are using a Macintosh running Classic AppleTalk, or MacTCP. It's a bug that has been affecting Pipeline users since the first patch release after 4.5. 4.5 naked does not have this bug but all releases after it have the bug.

MacTCP has always had this problem. OT does not have this problem. There is a FIX! A person from the Electric Magic Corporation over in San Francisco took it upon himself to write a patch for MacTCP 2.0.6 that patches the code to fix the problem. We've run the patch in-house for weeks without any problems.

It is publicly available at ftp://ftp.emagic.com/pub/mactcp_fix.sit.hqx

And for those of you who would like to read about it FIRST, here's a few excerpts from the README:

What's wrong with MacTCP?

I won't go into all the gory details, but whenever MacTCP needs to send a packet to another machine it has to decide whether to: 1) Send it to a specific machine on the local network
2) Send it to the gateway machine
3) Broadcast it on the local network

The routine inside MacTCP that determines whether a particular destination is a broadcast address or not is called broadcastAddr, and it gets it wrong. Instead of checking the net portion of an address against the destination (to determine if the destination machine is on the local network) and *then* checking to see if it is a broadcast address, it checks for the broadcast portion first.

What this means is that if you're in a subnetted environment, and your machine attempts to send a packet (UDP, TCP or raw IP) to a machine on a *different* network, and that machine has an address whose host part matches the broadcast address of your subnet, then the packet is broadcast on the local network instead of being forwarded to the gateway. So the packet never gets to its real destination, and you can't communicate. This affects TCP, UDP and ICMP packets equally (I checked).

What does this mean?

As you can imagine, if you've followed the above, this makes it impossible for a machine running MacTCP to send a packet to another machine elsewhere on the Internet if that machine's IP address has all 1's in the portion of it's address corresponding to the zeroes in MacTCP's netmask.

What does the patch do? The patch simply replaces the implementation of the broadcastAddr routine in MacTCP 2.0.6 with one that does the checks in the correct order. That's it. It's not an overly complex routine, it doesn't allocate memory, and it doesn't write data anywhere, so the worst it could do, if faulty would be return an incorrect flag, causing unwanted broadcasts, and failed connections.

In the package you will find a file broadcastFix.c, containing the source code for the fix, please feel free to check it out. I've checked this out on several machines here, without any problems (and with the benefit of making our server reachable by people who previously could never connect). This patch works on a copy of MacTCP 2.0.6. Do not attempt to patch any other version.

webmaster@bayoucity.net Updated 07/04/07