From hsu@clinet.fi  Wed Feb 28 08:37:29 1996
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA20320
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 28 Feb 1996 08:37:01 -0800 (PST)
Received: from katiska.clinet.fi (root@katiska.clinet.fi [194.100.0.4]) by hauki.clinet.fi (8.7.3/8.6.4) with ESMTP id SAA01155 for <FreeBSD-gnats-submit@freebsd.org>; Wed, 28 Feb 1996 18:36:14 +0200 (EET)
Received: (root@localhost) by katiska.clinet.fi (8.7.3/8.6.4) id SAA15192; Wed, 28 Feb 1996 18:36:14 +0200 (EET)
Message-Id: <199602281636.SAA15192@katiska.clinet.fi>
Date: Wed, 28 Feb 1996 18:36:14 +0200 (EET)
From: Heikki Suonsivu <hsu@clinet.fi>
Reply-To: hsu@clinet.fi
To: FreeBSD-gnats-submit@freebsd.org
Subject: /kernel: arpresolve: can't allocate llinfo for 194.100.0.30
X-Send-Pr-Version: 3.2

>Number:         1049
>Category:       kern
>Synopsis:       /kernel: arpresolve: can't allocate llinfo for 194.100.0.30
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    fenner
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb 28 08:40:01 PST 1996
>Closed-Date:    Fri Oct 25 15:29:28 PDT 1996
>Last-Modified:  Fri Oct 25 15:29:48 PDT 1996
>Originator:     Heikki Suonsivu
>Release:        FreeBSD 2.2-CURRENT i386
>Organization:
Clinet, Espoo, Finland
>Environment:

	A terminal server built on top of FreeBSD.  I tried to install
-current into it, and in addition to becoming more unstable it also looses
entries in its arp tables.

>Description:

Feb 28 18:03:55 osku /kernel: arpresolve: can't allocate llinfo for 194.100.0.30
Feb 28 18:04:30 osku last message repeated 3 times

If I try manually enter the hardware address of the 194.100.0.30, I get

set: can only proxy for 194.100.0.30

The problem disappears when I shut down gated, but after starting gated
again the arp entry for 194.100.0.30 disappears with 30 seconds. 

>How-To-Repeat:

I don't know exact pattern which causes this.

>Fix:
	


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->fenner 
Responsible-Changed-By: fenner 
Responsible-Changed-When: Wed Feb 28 10:43:30 PST 1996 
Responsible-Changed-Why:  
fenner has been mucking with arp/routing stuff 
State-Changed-From-To: open->analyzed 
State-Changed-By: fenner 
State-Changed-When: Wed Apr 3 10:42:51 PST 1996 
State-Changed-Why:  
This is caused by a host route with the host itself as the destination. 
These routes have two known causes: 

- gated/routed installs them.  This is bogus behavoir on their part. 
- A host route to a host on your own subnet via a gateway that sends 
redirects.  The gateway will send a redirect pointing at the host itself. 

This behavior changed from a potential race condition to a common occurrence 
when my fix for some other ARP behavior was committed.  IP routes with the 
destination == the gateway must not be allowed in the routing table because 
they interfere with the creation of ARP entries.  The original add is easy 
enough to prevent in in_addroute(), but the second case is not so 
straightforward.  Also, there may be other ways to create these routes. 

It may be that the proper solution is for the ARP code to check if it's 
one of these bogus routes that is in the way of adding the ARP entry and 
to delete it if so.  The problem with that solution is that gated and ARP 
will probably fight and keep overwriting each other's routing table entries. 
State-Changed-From-To: analyzed->feedback 
State-Changed-By: fenner 
State-Changed-When: Tue Jul 9 18:35:28 PDT 1996 
State-Changed-Why:  
The recent changes to net/route.c (rev 1.34) and net/rtsock.c (rev 1.20) 
should eliminate the source of these errors.  Please try them. 
State-Changed-From-To: feedback->closed 
State-Changed-By: fenner 
State-Changed-When: Fri Oct 25 15:29:28 PDT 1996 
State-Changed-Why:  
Lack of feedback. 
>Unformatted:
