> 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....

Best regards,
Terry Moore
Databook Inc.