Hi Michael. The problem I was referring to, with PPP.LOG remaining open, was not really a problem _within_ Arachne, but rather with DOS redirection. That is, the redirection of LSPPP's output to PPP.LOG (called directly or indirectly, by ARACHNE.BAT). I suppose the same thing would happen with redirection of EPPPD's output to PPP.LOG, unless this does it's own redirection (instead of letting COMMAND.COM (?) do it)? I suspect however, that the problem _does_ exist when using EPPPD too, because this would explain the strange connect behaviour I would sometimes get, if my first dial attempt failed (IIRC). Perhaps Bernie can tell us if EPPPD does it's own redirection, or whether it let's DOS do it ... I noticed this effect because I normally run SHARE - however there are more subtle effects of this problem for those that don't run SHARE. It's good that you will be supporting LSPPP directly in Arachne and also that you will favour the BOOTP method in future, rather than the PPP.LOG method. Much better, IMHO. :-) Joe. > -----Original Message----- > From: Michael Polak [SMTP:[EMAIL PROTECTED]] > Sent: Monday, 19 February 2001 7:25 > To: [EMAIL PROTECTED] > Subject: Re: Back to the future (LSPPPCFG revisited) > > Da Silva, Joe wrote: > > > Some of you may recall, a little while ago, a consensus was reached, > > that the 'lspppcfg' package should redirect the output of 'lsppp' to > > the 'ppp.log' file ... > > > > Alas, as it "turns out", the consensus view was flawed (oh, well!), > > because when the 'lsppp' program "goes resident", the 'ppp.log' file > > then remains "open". Because the 'ppp.log' file is read and written > > by other applications, these operations can either get muddled or be > > blocked (depending on whether 'share' is loaded). > > > > Arachne is solving this by using sopen() to open ppp.log... > with some flags to deny_noone...., or something like that.. > I can check it. > > > Therefore, the 'cfg-ppp' program (in the 'lspppcfg' package) has > > been updated again, so that the 'lsppp' output is redirected to > > 'nul' (as previously). However, to be more informative, a message > > is now added to the 'ppp.log' file to indicate the success/failure > > of 'lsppp' in establishing a PPP link. In addition, the user can > > still redirect the output of 'lsppp' to the 'ppp.log' file, for > debugging > > purposes, by issuing the command "SET DEBUG=PPP" at the > > DOS prompt, before invoking Arachne. Ironically, redirecting the > > output of 'lsppp' to 'ppp.log' should not cause any problems when > > the PPP link fails, because then 'lsppp' does not "go resident". > > > > In addition, the 'cfg-ppp' program now has a new option, called > > 'update', which will update an existing 'lspppcfg' installation, > > while preserving any configuration changes that have been made > > since the previous installation. Simply unzip the 'lspppcfg.zip' > > file into your Arachne directory, and type "cfg-ppp update". > > I think my solution for lsppp will be anyway complete transfer from > PPP.LOG method to IP_Address bootp; in that case, PPP.LOG will > be closed after MINITERM exits. >
