Subject: misc/11916: PPPD fails when re-connecting broken connection
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 01/07/2001 22:15:13
>Synopsis: PPPD fails to set up routes/interface when re-connecting
>Arrival-Date: Sun Jan 07 22:15:00 PST 2001
>Originator: Donald Lee
>Release: NetBSD 1.3.x, 1.4.x, and 1.5
icompute.com - small ISP
Many. I can reproduce this problem on MacPPC and 68K Macs
and under 1.3.x, 1.4.x, and 1.5 NetBSD.
System: NetBSD charm 1.5 NetBSD 1.5 (try1) #16: Sun Jan 7 20:28:22 CST 2001 donlee@charm:/usr/src/sys/arch/macppc/compile/try1 macppc
When using pppd in a dial-in mode, pppd needs to set up both
the pppx interface and a proxy-arp for the ethernet side
of the connection.
If the PPP connection is broken for some reason while
a socket is active, the proxy arp entry will persist
(probably because the remote connection is still trying to
use the socket) and this will prevent re-connection of
the PPP connection on the next dial-up.
This might seem fairly minor, but is really a pain
if you are trying to provide a reliable dialup service.
Any user who rudely disconnects his PPP session leaves
behind this problem, and there is no way I can find to
clean it up.
I've tried connect and disconnect scripts, and they don't do
The easiest way to reproduce this is to dial up to NetBSD with
PPP. (PPPD doing the serving, of course) Start an FTP
transfer to a third machine (some random ftp server that is
not the same as the pppd host). In the middle of the transfer,
disconnect from the ppp server. (hang up the phone)
When you try to re-connect (re-dial), you will notice that the
stock pppd will let you connect, and it will appear to
work, but you can't route packets between ppp and ethernet.
Notice that netstat -r shows the remote "PPP" address
listed as a "link #1" on the ethernet interface, and that
arp -a lists this address as "incomplete". (it should be
a permanent published proxy-only arp)
YOu can restore the dialup to health by killing the
disconnected ftpd on the remote machine, and by doing
an "arp -d PPPADDR" on the ppp host. (and maybe a
"route delete PPPADDR")
I have struggled with this for some time, and now have a
"fix" for it by doing a "system("arp -d HISADDR");" in
sifaddr() in pppd/sys-bsd.c, but the real fix is
surely something better.
It may be that this is *the* fix, but I looked at the
source to arp, and it looked like too much work to steal
the code. ;->