Next, you'll need to set up an Ethernet Packet Driver. Or, perhaps, an Ethernet Packet Driver emulator for dial-up PPP. If you have a '386 or later based PC, your choice is clear. You'll want to get LSPPP v1.0, dated 10/23/03. It is available from: http://members.tripod.com/~ladsoft/lsppp/ . Well, this directory seems to have gotten lost somewhere short of its ten year mark. As of December 2014, the LADSoft Home Page still is there. But, its link to "PPP TSR" (near the bottom of the page) only gets you LSPPP v0.9 . Here is my mirror of the version 1.0 site, made a week or so after it was published, in October 2003.
After my ISP merged into Ikano Communications in August 2004, LSPPP v1.0 became the only DOS PPP software I have that continued to work with their access points. I think that must be because the Ikano access points are using the PPP authentication variation known as "CHAP with password encryption". LSPPP is the only free PPP software I know of that works with this variation. I think most ISPs are moving toward using this variation, if they aren't there already.
I run LSPPP v1.0 daily on my '486DX based PC, Bashful.
To make Bashful an Internet firewall/gateway for my home network, I run two
other programs along with LSPPP. These are another Packet Driver, for
Bashful's Ethernet card, to provide an interface to my home network.
And, the
NAPT Internet Extender program.
(This site hasn't been working lately.)
Here is a partial mirror, for much of the site, made in March 2002.
NAPT provides Network Address/Port Translation. That makes all the PCs on my home network look, to the Internet, like multiple sessions running on a single large machine. This function is necessary because each dial-up Internet connection is provided with just a single IP address. NAPT also blocks all incoming logical connection requests that I haven't explicitly allowed in its configuration file. This protects Windows system(s), that might happen to be running on my home network, from Internet hackers!
As previous versions of LSPPP didn't work with a configuration file, I have become used to wrapping my long LSPPP command in a small DOS BATch file. I use the following LSPPP command in such a BATch file on Bashful:
@LSPPP /z /dl:P8200022 /n:2 /B:57600 /m:1500,1500 /U:%1 /P:%2
Note that LSPPP's options are case sensitive. The /U and /P options copy my Userid and Password from the BATch file's command line parameters. The @ character keeps them from being redisplayed as the BATch file's LSPPP command gets run. The /z option requests a debug log file. The /dl: option may not need that P (for Pulse dialing). The /n:2 option indicate's that Bashful's modem is set up as COM2. The /B: option tells LSPPP what speed to use for contacting the modem. As the operation seems plenty fast when the modem makes a 56 K bits/sec. connection, I haven't felt any need to try 115200 there. I've had the /m: option shown, from the beginning as well. So, I'm not sure if it is really necessary.
When my younger boy wanted to set up a similar gateway for use with Earthlink, he started with a similar BATch file and LSPPP command. He needed to change the /n: option to indicate that his gateway PC's modem is at COM3. Of course, he also changed the /d option's 'phone number. But, he got LCP timeout messages. So, he added /A and /L options to lengthen the timeouts. LSPPP still didn't seem to be making his modem dial out. So, he then added an /i option and changed the /dl: option to /dfl:. At that point, LSPPP started working for him. It may be possible to take back one or more of the options he added before it started working. His final LSPPP command (which necessarily must be a single long line) reads:
@LSPPP /z /dfl:1,7033504492 /n:3 /i:4 /B:57600 /A:10,10 /L:10,10 /m:1500,1500 /U:%1 /P:%2
Previous versions of LSPPP have had trouble with '86/'88 and/or '286 processors. So, during the last week of March 2005, I tested LSPPP v1.0 on my oldest PC, Zeke, which then had a switch selectable choice of 8088 and 80286 processors. This time, it worked fine on Zeke's 8088. And, it seemed to connect and go resident on Zeke's '286. But, as soon as I tried to do anything with it on the '286, one or another of my usually reliable WATTCP based applications wound up hanging. I think I've heard that some people are able to use LSPPP with their '286 based systems. So, your mileage may vary. Zeke's modem tops out at 14,400 or 19,200 bits/sec.. So, I've reduced its /B: option, accordingly. Trying to use 38400 on Zeke might be asking for trouble. Here is the LSPPP command I am trying to use on Zeke:
@LSPPP /z /dl:P8200022 /n:2 /B:19200 /m:1500,1500 /U:%1 /P:%2
LSPPP v1.0 provides BOOTP service, even if your ISP's remote access server doesn't. That provides your IP address, which is likely to change from session to session, and the other needed TCP/IP configuration information to your BOOTP using DOS Internet applications. It also provides an IP-UP.BAT file to ease the set up of applications that can't or won't use BOOTP.
Before LSPPP v1.0 came out, DOSPPP06 used to be my favorite PPP package. It never had trouble with old processors. Unlike LSPPP's all in one approach, DOSPPP06 breaks down into two components. CHAT.EXE handles the dialing and Login authentication, if that is being used. EPPPD.EXE handles the rest of the PPP session set up and the Packet Driver emulation. This package includes versions of EPPPD said to support CHAP. However, those lack password encryption.
Want some good background information and help with setting up DOSPPP06? As we are on well trodden soil here (Oops. Sorry, Garrett!), I'll simply refer you to my master: tvdog, Jeffrey L. Hayes. tvdog's Web pages contain a lot of references to documents at the oldskool FTP site. Fortunately, it came back from the dead in 2003. If you find this FTP site hard to contact, see the sections entitled: "FTP Client Hang" and "New Understanding of mss= Configuration" near the end of my history.txt for DosLynx v0.24b. The section entitled: "FTP Client Issues", in my history.txt for DosLynx v0.25b, has an update on this story. These history.txt documents may now be found in my DosLynx versions 0.2xb Documentation Package. It is offered from the end of this site's DosLynx Complete section. What it all boils down to is that you may have to increase the value configured for mss=, if your FTP client is having trouble with the oldskool FTP site. Also, the problem(s) that DosLynx was having with it have all been corrected in version 0.25b!
If you are having trouble getting DOSPPP06, LSPPP, or some other DOS communications package to work with your modem, you've come to the right place. Or, if you simply want to find out what kind of UARTs your serial ports have, there's help with that here too. You'll need to get some small simple diagnostic programs that can check your serial ports and modems and give you second and third opinions on their configuration.
I've tested about twenty of these to present here. I have weeded-out all the ones that didn't seem to reliably indicate both UART type and IRQ setup on their first screen. That leaves me with just four programs worth talking about. (If you know of any others worthy of coverage here, I hope you'll let me know about them.)
IP (IP132.ZIP) (Freeware) appears to be a promotional offering originally from the (now departed?) MEL's Diner BBS. Strangely enough, it still seems to be the all around most reliable and most applicable simple little program that I've found. Its main weakness seems to be in the area of reporting IRQs above 7. IP v1.32 appears to report the use of IRQ 2 when IRQ 9 is configured. (This might be deemed a special feature.) And, it appears to report the use of IRQ 10 when any IRQ above 9 is configured. However, IP is the only program able to report anything about the configuration of IRQ(s) above 9, that I know of.
COMTEST (wizard.zip) (Freeware) promotes Jon Krahmer and his FaxMail for Windows software. (wizard.zip was last seen from Jon's Web site in 2008.) Here is a mirror of it from March 2003. If you are interested in base I/O addresses, you'll have to use a chart or another program like IRQCHECK (below) along with COMTEST. Because, it only reports COM and IRQ numbers on its first screen. COMTEST (also known as FaxModem Wizard COM-Port/FaxModem Tester v9.51.01) also offers to probe your Fax Modem for its attributes, if you like. Like IP and IRQCHECK, COMTEST reports IRQ 2 for IRQ 9. COMTEST appears to be incapable of reporting any use of an IRQ above 9. COMTEST leaves a report file, COMTEST.TXT, in every directory you happen to run it from. (You may want to RENAME the COMTEST.TXT file that comes in wizard.zip to, say, COMTEST.DOC before it gets overlaid by one of those reports.) I won't say anything about the startling screech that COMTEST puts out on your PC's speaker as it exits.
IRQCHECK (irqcheck.zip) (Freeware) has a screen presentation that is a bit flashier than IP's. However, on faster machines ('486s at 16 BogoMIPS and up), its IRQ detection becomes intermittent or (on a '586 at 60 BogoMIPS) may fail completely. Another program that may be offered from the same Web site is said to be patched to fix this problem. Well, one octet in it is changed. But, that doesn't seem to help its IRQ detection. On machines that aren't too fast for it, IRQCHECK appears to report IRQ 2 for IRQ 9, as IP and COMTEST do. IRQCHECK appears to be incapable of reporting any use of an IRQ above 9. Even on faster machines, IRQCHECK makes a good companion for IP and COMTEST. Lately I've been using several alternating runs of IP, COMTEST, and IRQCHECK for uncovering the absolute truth.
COMPORT /I (comprt25.zip) (Shareware), with its smooth screen presentation and apparent reliability, gave me an even better first impression than any of the first three. But, in spite of its Shareware status, COMPORT v2.5 seems to require a '286 or later processor! It appears to report the use of IRQ 9 for IRQ 9, as I expect. (I guess that's why I'm still listing it here!) But, only when it succeeds with IRQ 9. Its reporting of IRQ 9 seems to be intermittent on at least one of my faster machines. COMPORT /I appears to be incapable of reporting any use of an IRQ above 9. This program also reports on your parallel port(s).
If these simple diagnostics can't report both the IRQ and the COM port or base I/O address you expect for your modem or the serial port it is attached-to, you can't expect a communications package like DOSPPP06 or LSPPP to work with it, either. In that case, you need to work on your modem or its port's configuration. (Given the limitations of the diagnostics noted above, this statement implies that you probably should avoid trying to configure your modem or its port for an IRQ above 7.) If Windows can identify your modem while these DOS diagnostics can't, you'll have to treat it as a WinModem.
But, what should you do if your communications package doesn't seem to work while the diagnostics report just what you expect? Well, the obvious thing is to recheck your communications package's configuration. Also, consider that the ability to work with less than completely standard hardware configurations and system states is something that may vary quite a bit from one package to another. In some cases, reconfiguring the modem, from a less standard setup to a COM2 setup, has solved all my problems with a difficult communications package.
The following talks about serial port(s), mostly. If you are using an external modem, it will be attached to one of your PC's serial ports. If you are using an internal modem, it will have electronics that make it look like another serial port. So, wherever I say serial port(s) you may read that as serial port(s) or modem(s).
"COM2" may mean more than just a base I/O address of 02F8h and an IRQ of 3, by the way. COM2 also may mean that the first two words stored at memory address 0040: 0000 must contain 03F8 02F8. (When you check with DEBUG, this will look like: F8 03 F8 02 because of Intel octet ordering.) And, that the less significant (right hand) hex digit of the octet stored at memory address 0040: 0011 must be 4 or more.
These memory areas are initialized by your BIOS when you Boot your PC. The four words starting at 0040: 0000 are expected to be a list of the base I/O addresses for your installed serial ports. The octet at 0040: 0011 is part of the BIOS equipment summary word. The less significant (right hand) hex digit of that octet is expected to be two times the number of serial ports listed at 0040: 0000. Some software checks these and gets confused if they aren't quite right. Other software appears to have been written by programmers that weren't too familiar with these things. You are especially likely to have trouble in this area if you have a software configured modem in your PC.
This trouble comes because your BIOS won't be able to detect your modem before it has been configured. But, you won't be able to run your modem configuration software, even by putting it in AUTOEXEC.BAT, until after your BIOS has done all of its configuration work. It will be up to your modem configuration software to update these memory areas when it configures your modem. Here are two kinds of problems you can have:
First, if your BIOS detects two or more serial ports, the second word at 0040: 0000 will get filled-in before your modem configuration software has a chance to configure your modem for COM2. The easiest way to avoid this problem is to disable all of your serial ports except the one configured for COM1. You may be using it for a serial port connected mouse. Having done that and reBooted, your DEBUG report should look like:
C:\>DEBUG
-D 0040: 0
0040:0000 F8 03 00 00 00 00 00 . . .
0040:0010 xx x2 . . .
0040:0020 . . .
Then, after your modem configuration software has run and configured your modem for COM2, your DEBUG report should look like:
C:\>DEBUG
-D 0040: 0
0040:0000 F8 03 F8 02 00 00 00 . . .
0040:0010 xx x4 . . .
0040:0020 . . .
Did I leave you stuck in DEBUG? Use DEBUG's Q(uit) command to get out of it.
Once you have your communications package working with your modem configured as COM2, you might revisit trying to configure the serial ports you disabled to make way for your modem. At that point you'll be more patient, knowing that you do have a way to make your communications package and modem work together!
Believe it or not, a second kind of problem that you can have is that your modem configuration software doesn't bother to update the octet at memory location 0040: 0011. I have seen modem configuration software that didn't bother. If your post modem configuration DEBUG report shows that has happened, use DEBUG's E(nter) command to make the needed update manually. Once you have seen your communications package and modem working together, you can look for a way to automate this update. After you get the hang of writing little text scripts to be used as redirected input to DEBUG, you will find this the easiest way to go.
One of the diagnostics reviewed above might also correct these memory locations for you. Use DEBUG to see if any of them do. Unfortunately, this approach may lead to another problem. The very diagnostic that corrects your BIOS memory contents may leave your system or modem in a slightly strange state, in some other way, that keeps your communications package from working!
So, here is my final advice on this subject: Assume that using any of these diagnostics, for whatever reason, might keep your troublesome communications package from working. Until after you have reBooted and reconfigured your modem manually, again. Before you conclude that your troublesome communications package isn't working with a given hardware setup, make sure you've tested it at least once when no diagnostics have been run since Booting.
Once you have a working Ethernet Packet Driver or Ethernet Packet Driver emulator, you'll be ready to use quite a number of DOS Internet Software applications by simply following their individual set up instructions.
See you on the 'net.
Fred C. Macall K8GIV
27 October 2021
