See below ...
Joe.
> -----Original Message-----
> From: Michael Polak [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, 24 February 2001 4:25
> To: [EMAIL PROTECTED]
> Subject: Re: LSPPP 0.71
>
> da Silva, Joe wrote:
>
> > OK, David has sent me a copy of LSPPP 0.71, which
> > closes STDOUT before "going resident" ...
>
> Are you sure it is compatible with all DOS flavours ?
> I vote rather for modifying Arachne scripting to not require
> redirection of PPP log to file. I think logging option is
> best solution, and Arachne will just type lsppp.log>>ppp.log,
> and we are done.
>
[da Silva, Joe]
I have seen nothing to suggest this stuff is "DOS version
specific". Also, I have tested this stuff with DR-DOS 6.0,
DR-DOS 7.02+ and M$-DOS 3.2 ...
As for your proposed solution, I think it is a little
bit convoluted, for no real reason. I believe problems
should be solved, not "worked around". The problem
is LSPPP (haven't checked EPPPD ...) not closing
STDOUT before going resident. That is being fixed, so
no convoluted "work around" is required of Arachne.
Also, _if_ EPPPD needs it, I'm sure Bernie will be
happy to add this fix to EPPPD, after all, he has made
*much* more substantial changes to it already! ;-)
> I would also appreciate some API for detection of modem line
> status - currently, Arachne is not able to detect whether PPP
> conenction was lost, or not. Arachne should be able to detect it,
> so termin.com 0x60 can be called, and connection automaticaly
> re-initiated. In Linux, it is easy to see whether PPP inteface
> is up or down...
>
[da Silva, Joe]
Well, for OSI model, I guess everything must pass
through the packet driver API. So, I had a look at
the packet driver spec., and the only thing there
that _might_ be suitable is the CANT_SEND result
code, when sending out data ...
If you don't care about OSI model, then it is quite
easy to find this information from the Carrier Detect
status of the UART. Since Arachne always knows
the address of the UART, it can access this itself,
bypassing the PPP packet driver for this ...
> > You will be pleased to know, this solves all the "file
> > sharing violation" problems when LSPPP's output is
> > redirected to PPP.LOG and, contrary to Clarence's
> > fears, does not make STDOUT disappear (for other
> > applications or COMMAND.COM) when the output
> > is either not redirected, or is redirected to NUL. :-)
>
> Well, if it work for all DOSes...
>
[da Silva, Joe]
See above ...
>
> > BTW, David has also fixed the "packet driver statistics"
> > (aka "TCP/IP statistics") ... :-)
>
> And what about connectivity statistics ? I don't know much
> about it, all this DTR up/down stuff, but I would like to
> be able to check whether remote party hung up the connection...
>
[da Silva, Joe]
Well, DTR is an output from the PC to the modem,
so I think the signal you want is CD. The only "gotcha"
is that I don't know if some systems might not use
(or provide) the CD signal. IIRC, LSPPP has the option
to ignore CD, so this suggests that indeed some
systems don't use it ...
> > One minor problem has been introduced, which David
> > will no doubt rectify shortly, in that LSPPP 0.71 does
> > not return a zero "errorlevel", even when everything
> > is fine ... Oh, well! :-/
>
> I think I will stuck with 0.7 for Arachne 1.71. I am sorry
> I haven't started testing yet...
>
[da Silva, Joe]
Why??? LSPPP 0.71 fixes two important bugs. Sure,
it introduces a minor bug, but IIRC, Arachne doesn't
check the "errorlevel" returned by the PPP packet
driver (EPPPD), so it probably won't even notice this.
David says he will fix this little problem too, so the
next public release should be perfect! <g>
