Subject: Re: poor man's demand-dial
To: None <email@example.com>
From: Terry Moore <firstname.lastname@example.org>
Date: 03/21/1995 12:18:39
> I applied those patches to my -current sources and installed the new
> pppd and chat. It did not seem to help. It is still reliably the
> case that when the modem drops, pppd fails to notice and die as it should.
> Perhaps the problem is hardware-specific. I am using the i386 ast/com driver.
> Has anyone else but me seen lossage like this with any serial port?
> I tried to investigate by setting a breakpoint on ttymodem in ddb, but
> using ddb locked my keyboard so I could not really pursue it. (That
> problem is definitely hardware-specific, and I will whine about it on
> port-i386, not here.)
I saw a very problem. I was using the "proxyarp" option in my ppp "options"
file. I turned that off; the problem went away.
Pppd is structured as a background thread, with a bunch of things that
are driven asynchronously based on signal delivery. The flaw in pppd is
that if asked to do "proxyarp", the background thread hangs in a loop
trying to honor it. Meanwhile, the events that cause net traffic are
being processed; so pppd (apart from consuming lots of useless cycles)
operates correctly. The HUP event is also processed in the foreground;
a flag is set that would cause the background thread to exit. However,
the background thread is not looking at that flag; instead it's looping
doing IOCTLs on net interfaces.
I didn't further diagnosing why it was failing; perhaps it has
to do with the only working ethernet interface on my machine being "ed2". I
rather suspect that it might work if "ed0" was active, as it appears to
be looping through the interfaces in turn. I was more interested
in stopping the behavior, and I don't really need "proxyarp", so....