Subject: kern/12826: default -iface route is sometimes ignored
To: None <firstname.lastname@example.org>
From: Martin Husemann <email@example.com>
Date: 05/04/2001 09:10:42
>Synopsis: default -iface route is sometimes ignored
>Arrival-Date: Fri May 04 00:10:01 PDT 2001
>Originator: Martin Husemann
>Release: 1.5U, cvs updated around April 28
System: NetBSD night-porter.duskware.de 1.5U NetBSD 1.5U (PORTER) #1: Sun Apr 29 11:55:20 MEST 2001 firstname.lastname@example.org:/usr/src/sys/arch/i386/compile/PORTER 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
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 0.0.0.1, in which case it will accept any
Since my remote address varies, I set the interface to
ifconfig pppoe0 0.0.0.0 0.0.0.1 up
(meaning: accept any local and remote address). To make this my default
route, I do
route add -net default 0.0.0.1 -iface
After the system is up I get this:
Destination Gateway Flags Refs Use Mtu Interface
default 0.0.0.1 US 1 512 1494 pppoe0
0.0.0.1 126.96.36.199 UH 0 0 1494 pppoe0
127.0.0.1 127.0.0.1 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.