>Number:         11916
>Category:       misc
>Synopsis:       PPPD fails to set up routes/interface when re-connecting
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 07 22:15:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Donald Lee
>Release:        NetBSD 1.3.x, 1.4.x, and 1.5
>Organization:
	icompute.com - small ISP
>Environment:
	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


>Description:
	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 job.
>How-To-Repeat:
	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")
>Fix:
	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. ;->
>Release-Note:
>Audit-Trail:
>Unformatted: