On Wed, Apr 20, 2005 at 05:39:46PM +0200, Richard Braun wrote:
> You need to do to things :
>  o ! /sbin/pppoectl pppoe0 max-auth-failure=0 (in ifconfig.pppoe0)
>  o options PPPOE_TERM_UNKNOWN_SESSIONS (in your kernel config file)
> 
> The first tells the pppoe driver to never give up trying to connect. 

This is not what it does.

You can check with "pppoectl -d pppoe0" if there are any authentication
failures involved.

> The
> second tells the driver (at compile time) to delete any unknown sessions
> encountered. Usually this can happen, and has the effect that, as the BAS
> still has a reference to your connection (though there is no more connection
> at your side), trying to establish a new connection doesn't succeed.

I would be interested in any evidence that this might happen in legitimate
ways - it sounds pretty unlikely that both the PPP LCP termination 
request and the pppoe PADT packet got lost.

If this is realy what happens, we could keep a (short) list of previously
used (by ourselfs) session IDs and kill those when we encounter packets
for them later.

Whenever I have seen situations similar to the one discussed here,
I have not received any replies from the concentrator any more. You can
check this with tcpdump on the ethernet (or in your case: tap) interface.

I suppose the ATM "connection" dropped, somehow, and I need to reset the
modem to establish a new one. I've never had to do any magic to the NetBSD
part - just wait for the next retry after the modem synced.

Martin