Subject: kern/12826: default -iface route is sometimes ignored
To: None <>
From: Martin Husemann <>
List: netbsd-bugs
Date: 05/04/2001 09:10:42
>Number:         12826
>Category:       kern
>Synopsis:       default -iface route is sometimes ignored
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 04 00:10:01 PDT 2001
>Originator:     Martin Husemann
>Release:        1.5U, cvs updated around April 28
System: NetBSD 1.5U NetBSD 1.5U (PORTER) #1: Sun Apr 29 11:55:20 MEST 2001 i386
Architecture: i386
Machine: i386

I am not sure this is not some very stupid pilot error, or something broken
in my own code (or systematic failure due to the gross hack involved in
the configuration).

For all net/if_spppsubr.c based in-kernel PPP interfaces, we inherited from
FreeBSD a hack how to configure the acceptable remote addresses. You can
either ifconfig a concrete remote address, in which case PPP will only accept
this address, or you set it to, in which case it will accept any
remote address.

Since my remote address varies, I set the interface to

  ifconfig pppoe0 up

(meaning: accept any local and remote address). To make this my default
route, I do

  route add -net default -iface

After the system is up I get this:

Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default              US          1      512   1494  pppoe0        UH          0        0   1494  pppoe0          UH          3     2318  33228  lo0

and everything works. When the ppp connection terminates and comes up again,
the default route sticks to that interface and everything works fine.

But sometimes the system stops sending packets out via the pppoe interface
(i.e. tcpdump on the pppoe interface does not show any outgoing packets).

Actually this may, of course, be some interface driver bug. I thing I
remember seeing this problem from time to time with ISDN ppp interfaces (also
based on if_spppsubr.c) too, but this does not tell anything.

I have to rewire some serial stuff and attach a kernel debugger to that 
router, wait for this to happen again and then do further investigations.
This is a reminder PR for me to do so ;-)

But maybe this already rang a bell for someone who can explain the behaviour?


Run above configuration for some time and watch traffic stall.
It is not reliably reproduceable.

No idea.