Paul Mackerras wrote: > > David L. Nicol <[EMAIL PROTECTED]> wrote: > > > Another annoyance with the current demand option is that "lock" no > > longer seems to work; instead of instantly crapping out on starting > > as pppd does without demand on second invocation, a ppp1 interface is > > invented and configured. (so I have dropped all the pppd invoking lines > > Of course. The "lock" option is concerned with a lock on the serial > port. When you start in demand mode, it doesn't need the serial port > right away. Maybe the serial port is locked now, but hopefully > whatever is using it will have finished by the time pppd wants to use > it. > > Paul. > > - > To unsubscribe from this list: send the line "unsubscribe linux-ppp" in > the body of a message to [EMAIL PROTECTED] When I read this, I thought - what about a prompt; ie. "Requested resource is in use: (w)ait for resource to become available, or (q)uit." Then I thought some more and decided this would be really sucky in some situations. ;-) Other thought was to check and see what has the resource locked; if it is pppn, output a message indicating that a route already exists, otherwise output that the resource is busy and we will wait for it. I don't see a real good reason for two pppd's to wait for the same resource: if I can get through via x.x.x.x, I should also be able to get through via n.n.n.n. The only sucky thing I can think of about this method is having to make chat and/or pppd a little smarter and knowing where to output the message so that the user invoking ppp will see it. If started from the console, send it to the console; if started from an X app, send it to the app and hope that it's smart enough to catch it? Ugh! It's starting to sound more sucky do to the chain involved in starting a ppp session: (X app) -> script -> chat -> pppd; who deals with the message and how does it get passed?? Starting to babble - Nite --- TimO - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to [EMAIL PROTECTED]
