On 19 Jun 2003 08:41:20 -0400, Greg Troxel writes:
>I have found the "can't allocate llinfo" error to arise when the arp
>code tried to create a routing table entry to record that an arp was
>sent (and eventually to hold the arp reply when it arrives later), but
>the call to add the entry fails.  The add can fail due to there being
>another entry in the routing table for the same address.  If, for
>example, you put in a host route for a.b.c.d, then allocating an arp
>entry would fail.

Yep that was what I did while trying to poke life into it.

>I have seen non-normal masks due to byte-swapping errors in ppp (on
>older FreeBSD).  If it happens again, you might scrutinize 'netstat
>-nr' from this point of view, and perhaps check the netstat source to
>make sure non-normal masks would be accurately displayed.

>This failure can happen if you are trying to run ospf p2mp on
>wireless, for example; I have not seen this happen in a wired network.

No routing protocols, just a static default route.  When all is
working I see:

# arp -na
? (A.B.C.1) at 00:10:67:00:f2:2c on le1
? (D.E.F.1) at 00:20:af:a4:9b:cf on le0
? (D.E.F.2) at 08:00:20:72:58:20 on le0
? (D.E.F.5) at 00:c0:4f:f8:98:71 on le0
? (D.E.F.8) at 00:c0:b7:92:6d:1f on le0
? (D.E.F.9) at 00:90:27:9a:49:54 on le0
? (D.E.F.10) at 00:c0:4f:22:e3:14 on le0
# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default            A.B.C.1            UGS         4  1350818      -  le1
A.B.C/24           link#2             UC          1        0      -  le1
A.B.C.1            00:10:67:00:f2:2c  UHLc        1     1100      -  le1
127                127.0.0.1          UGRS        0        0  33220  lo0
127.0.0.1          127.0.0.1          UH         13     1710  33220  lo0
D.E.F/26           link#1             UC          6        0      -  le0
D.E.F.1            00:20:af:a4:9b:cf  UHLc        4   133712      -  le0
D.E.F.2            08:00:20:72:58:20  UHLc        0      171      -  le0
...

Whereas when it wasn't working I first saw (console logs rule):

PING A.B.C.1 (A.B.C.1): 56 data bytes
ping: sendto: Host is down

Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default            A.B.C.1            UGS         4  8159875      -  le1
A.B.C/24           link#2             UC          1        0      -  le1
A.B.C.1            link#2             UHRLc       1    28371      -  le1
127                127.0.0.1          UGRS        0        0  33220  lo0
127.0.0.1          127.0.0.1          UH         12   185363  33220  lo0
D.E.F/26           link#1             UC          6        0      -  le0

and arp showed

? (A.B.C.1) at (incomplete) on le1

at which point I did indeed add a host route, which is probably why
things didn't recover when the g/w started working again.  

Thanks for the info!
--sjg