Hi there. I'm trying to get on the net with the lsppp ver. 1.0 packet driver using an external Zoom 2949L 56K modem on com port 1. The problem I'm having is that nothing will use the connection except for IRC101 client. I've tried jpirc as well as other trumpet dos clients with the trumpet stack loaded. I tried bobcat as well. I don't have anything else loaded on this laptop right now so I can't try them yet. lsppp is definately getting the correct info from my isp so the connection should work. Here's the batch file I'm using:

@echo off
cd \internet
lsppp /M:at&fb3 /m:576,576 /x /dl:6023854855 /B:19200 /n:1 /U:my_username /P:my_password
call ip-up.bat
call pathcfg.bat
cd \

Thanks in advance for any help someone might be able to provide.

Hi,

I'd use "WatTCP" applications: LSPPP is a Class-1
Waterloo TCP/IP packet-driver and the Trumpet shim
complicates your configuration when not necessary.

Salutations,

Michel Samson
a/s Bicéphale

You appear to missing the Vector !!!

Thanks for the replys. Lsppp doesn't need to have the vector (interupt) specified as it will search for a free vector starting at 0x60. Since 0x60 is free on this laptop it sets up there. The trumpet stack is setting up at 0x61 and is finding Lsppp quite well. From there it is configuring itself automatically off of the packet driver. And no it is not a shim but a tcp/ip stack and a buggy one at that. It's configuration doesn't bother wattcp at all since it's automatic. It just has the annoying habit of crashing the pc every now and then. I'm just interested in it right now as a diagnostic tool. Originally I once needed the trumpet stack to run JPIRC as it was the only dos IRC client that had a ident server built in. My current ISP has an ident server running so I can use any dos IRC client now. Anyway nothing is working except for trumpet's irc client which is built around some other tcp/ip stack rather than the trumpet one. None of the wattcp apps are working either such as the Bobcat browser. I'm beginning to suspect either a bios or a dos issue as another serial port program is having some minor problems getting the modem to set the baud rate. Lsppp is having this problem as well. Now matter what baud rate I set, the modem connects at 56K speed. Niether this other program or this modem normally behave this way when on other pc's. I've been able to get the modem to connect with .V34 with the B3 option in the init string in Lsppp. Perhaps if I address the serial port directly then all of my problems will go away. I'll give that a try and post back the results.

Hi,

I think you seem to suspect the serial-port but it
doesn't indicate that the dialing fails so i'm not
too confident it is going to help at all: i built
my own external dialer to manage a few PPP packet-
drivers and EPPPD/LSPPP appeared to have a problem
with the syntax to address the serial-port on some
of my old machines. I don't have fresh records at
hand but here's a rough equivalent of what this is
like (the stuff is old)... Lets say i use Go.BAT:

_____________________________________________________[Go.BAT]_
CLS
Rem GoTo No_COMTool
Rem Terminal session (Manual Mode Dialing)
ECHO.
ECHO UART 16550 - FIFO trigger-level set to 8 bytes
ECHO.
ECHO Phone-Modem dialing in progress...
ECHO.
ECHO ([Alt]+[E] to exit, [Ctrl]+[C] to cancel)
COMTool 2F8 3 ^B1 ^F81 ^T5

:No_COMTool
ECHO.
ECHO Loading in progress...
ECHO.
SET LSPPP=/U:"UserName" /P:PassWord
C:\PPP\LSPPP.EXE /B:57600 /b:02F8 /F:8 /i:3 /N:xxx.xxx.xxx.xxx
IF EXIST IP-Up.BAT CALL IP-Up.BAT
IF EXIST IP-Up.BAT DEL IP-Up.BAT
SET DNS1=xxx.xxx.xxx.xxx
SET DNS2=xxx.xxx.xxx.xxx
SET DOMAIN=domain.ext
ECHO.
ECHO Creating `C:\PPP\WatTCP.CFG'...
ECHO ppp=1>C:\PPP\WatTCP.CFG
ECHO my_ip=%MYIP%>>C:\PPP\WatTCP.CFG
ECHO gateway=%REMIP%>>C:\PPP\WatTCP.CFG
ECHO netmask=%NETMASK%>>C:\PPP\WatTCP.CFG
ECHO nameserver=%DNS1%>>C:\PPP\WatTCP.CFG
ECHO nameserver=%DNS2%>>C:\PPP\WatTCP.CFG
ECHO domainlist=%DOMAIN%>>C:\PPP\WatTCP.CFG
SET WATTCP.CFG=C:\PPP
ECHO.

It's from remnants remaining on a DOS partition, i
tried to simplify this by removing most extraneous
parts. Setting your FIFO trigger-level can really
help on slow PCs so i left the terminal mode which
is handy for debugging the PPP init phase, anyway:
a few systems return the IP numbers before chicken
tracks (ASCII character #125/"}") begin to arrive.

Of course, there's a short timeout delay with most
ISPs since nobody uses manual dialing anymore; it
is possible the PPP sessions will abort quickly if
one fails to react to the #125 characters in time.

Once you know the MoDem is connecting and your PPP
session has been established you only have to deal
with the LSPPP settings or the WatTCP environment,
it seems to work but others might benefit from the
comment so i had to dissect the connection process
in successive parts (MoDem, PPP, Packet-Driver)...

Salutations,

Michel Samson
a/s Bicéphale

No actually I was looking at the bios as the culprit for the baud rate problem. I was thinking that if the modem is running faster than the serial port then that could be the problem. Looks like it is not though. I found out that the trumpet stack doesn't auto config itself but uses switches for that. It just displays some stuff from the packet driver on the screen without configuring its self. I just used those switches in a batch file using the dos environment variables and now it is working. I decided to use your wattcp copnfig as it sure is better than any other method but still it's not working yet. I'll have to post the .cfg files later. As for the Trumpet irc client, I don't know what tcp/ip stack it uses but it autoconfigures itself off of the dos environment varibles.

I won't have to post my wattcp.cfg files after all. wattcp only works with the fifo used. I got everything up and running now. Thanks Bicephale.

Hi,

Oh, it works! Well, lets post this for the others.

Reading about your misfortune i thought the Novell/
NetWare DOS ODI sub-set found in `DR-WebSpyder' may
open the door to a suitable IRC client alternative;
it turns out that a `LAN WorkPlace for DOS' version
of Trumpet IRC v1.01 rev A (`IRCLWP') is available:

http://www.dossolutions.pwp.blueyonder.co.uk/progs/lwpextra.zip
(1881448 Bytes)

I've seen no mention of `NTCPDrv v3.1'/`TCP201.ZIP'
relatively to `IRCLWP.EXE' (1994-Feb-7), this seems
to be an EtherNet/Class-1 & SLIP/Class-6 compatible
client but the binary would need `\TCP\RESOLV.CFG',
actually... It reminds me of an old 495 lines long
post i made elsewhere after i discovered that there
was a way to "recycle" the `DR-WebSpyder' ShareWare
archive to support some WatTCP/DOS ODI applications
(Arachne's Digest archive shows that Luis Loeff and
perhaps a few others did the same). `DR-WebSpyder'
has become rare but here's a place where to get it:

http://evolt.m.flirble.org/dr-webspyder/2.0/DRWEBDEM.EXE
(1387560 Bytes, 1998-Sep-3)

One big problem with Caldera's Dialer r1.00 is that
PAP authentification failed if there were lowercase
(or maybe it was uppercase?) letters in a UserName/
PassWord string. Other than that, it works swiftly
and it's easy on memory as it loads high in chunks.

The WatTCP support is from Caldera's `Pkt2ODI' shim
instead of the more familiar `ODIPkt' one. It felt
quite a bit tricky but was possible, as i recall...

One last thing, `NTCPDrv.EXE' relies on a different
set of DOS environment variables than those i shown
in my sample. Namely, these Trumpet variables are:

IP instead of MyIP (SET IP=%MYIP%)
GateWay instead of RemIP (SET GATEWAY=%REMIP%)
DNS instead of DNS1 (SET DNS=%DNS1%)
NetMask (unchanged)
Domain (unchanged)

Which should also remind you to take a peek at your
`WatTCP.CFG' configuration file to make certain the
settings are right and to look at the actual values
of your DOS environment variables (lack of reserved
memory space for this purpose may cause trouble)...

Salutations,

Michel Samson
a/s Bicéphale

Yes I noticed the differences with various apps using slightly different names for the settings. Bobcat seems to accept my_ip or ip while minitel and ftp that comes with bobcat seem to accept my_ip only. As for ODI, my guess is thats it's for LANS mainly. How well does it work with a dial up ISP? I'm just wanting to know because I was trying to get Wolverine to work in WFW 3.11. I'll consider a post in the win3.1 forum to discuss this further.

Hi Arcosanti,

I don't know which build of Trumpet's IRC would be
working best but i did try both DOS ODI and WatTCP
SoftWare after i done some recycling with DRWebDem
and the performance compared well to that of EPPPD
or LSPPP. I mostly focused on TelNet applications
that allowed Kermit/ZMoDem transfers and FTP also,
this is all i depended on in the good old days: i
was able to surf the Web by TelNetting to a remote
Lynx browser and i could do the same for IRC once.

I never played with LANs back then. I ran Trumpet
WinSock (instead of Wolverine) if i was desperate:
i confess i wasn't really a Windows enthousiast...

My field of expertise differs quite a bit from the
topic you suggest, i'm afraid i may be of no help!

For a better idea about my former hobby, there's a
page about the DrWebDem diskette which remained on
line after i changed of ISP. You can see it here:

http://public.sogetel.net/bicephale/eng/drwebdem.htm

I called it "The Novell/Caldera NetWare components
from DR_WEB-Spyder...", i took care to mention the
NetWare origin because that's what the executables
pointed at when i used them but the reference to a
LAN ends there. Having DOS ODI was nice as we can
evaluate KALI using IPXODI, etc, but that's all...

Having a Class-1 WatTCP-compatible shim only gives
the user a wider selection of applications and the
DialUp PPP session doesn't have to be interrupted.

Oh, one remark about a persistent typo which still
buggs me to this day: "domainlist" should read as
"domainslist", it seems. Anyway, have a good day!

Salutations,

Michel Samson
a/s Bicéphale