Hi Carl,
Hi Heimo,
Hi Howard S.,
About "Modem Connections Problems -- One Solution" of Feruary 13
and 14:
CN> Dale suggested trying the LSPPP dialer/packet driver instead...
HS> I initially experienced various connection problems and error
HS> messages... I simply adjusted the timeout to a minute... ...in my
HS> trusty chat script, and virtually all my problems went away.
This may sound like deja vu but lets repeat myself again: my worst
experience with DOS InterNet was related to the ~ISP~ Dialing procedure.
Sometimes my ~ISP~ would seem to have a pool of disparate ~PPP~ servers;
the DOS user i am didn't know what options to select until i was already
connected - i had to choose the type of LogIn "on the spot" so i wrote a
macro/script file of which it was the function to decide for me. Manual
setups were too slow and the ~ISP~ often hanged-on before i was ready...
In my mind, terminal emulation SoftWare is essential as part of any
external dialer; it can be a nice way to find out where it fails. I've
pushed this idea even further by configuring the packet-driver from that
external dialer, in a _dynamic_ way - clearly seperating the ~PPP~/~PAP~
sequence from the MoDem CONNECT sequence should ease trouble-shooting...
That is why i would suggest to anybody who is experiencing problems
that he first connects to the ~ISP~ with nothing but a terminal emulator
so that it's possible to see what he's having exactly (no MoDem CONNECT,
the serial-port isn't found, no user prompt, no chicken tracks, etc.)...
Most of the time, my ~ISP~ now allows me to authenticate thru any method
i prefer (~TTY~/"terminal" vs ~PAP~/~CHAP~) but that wasn't true before.
HS> If I try to connect a few seconds later, I often get in.
That's what i was forced to do when i decided to write a macro. :>
Is it possible your ~ISP~ would be like mine?... A capture of the LogIn
screens would tell. After enough time, one will acquire an overview and
that might reveal to him a pattern where one LogIn screen corresponds to
a given type of LogIn, which calls for the proper packet-driver options,
euh... but if he's not that lucky then it won't... The mileage varies.
If a guy uses more than one ~ISP~, as i have, a full-blown external
dialer solution would be a nice way to deal with this troublesome phase.
HC> ...LSppp... ...the author (David Lindauer) is actively working on
HC> it. ...two sorts of problems: (a) with the built-in dialer...
Please, tell me, W0rm didn't seem to be the right guy to address on
this and since you seem to be in touch with the author, do you know if a
couple ideas from a simple user may be of any interrest to mr. Lindauer?
HC> BTW, epppd has shown to be problematic too...
There's one thing i observed with `EPPPD' lately (my ~ISP~ might be
playing tricks on me again, oh dear!), euh... It causes a "division-by-
zero" error at times (if i can remember this correctly). They gave me a
lot to think about with the LogIn phase, i hope Sympatico isn't trying a
new type of ~PPP~ server which would work only with a `Windows' machine!
%-b,
In your opinion, is there anything about the v0.6 alleged bug which
would have something to do with the `Windows' frenzy? I sort of wonder.
8^o
HC> One reason to migrate to LSppp (besides of its significantly smaller
HC> footprint) was epppd's memory leak when used with the Lynxes.
Nice to know, i haven't removed the `LSPPP' part from my macro yet.
:)
HC> Correction: the URL at my wweb-plas for the "good" version (05...
Hummm... Just a thought: is the source-code available as well?...
I know the v0.6 source-code can be found, what about the previous one???
Salutations, :)
Michel Samson
www3.sympatico.ca/bicephale
a/s Bicephale
... And then there were none, a footnote in the history of the InterNet!
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
