Hi. On Tue, Oct 03, 2017 at 04:04:56AM -0400, Gene Heskett wrote: > On Tuesday 03 October 2017 03:02:42 Reco wrote: > > > ip -r n s > returns this unsorted list: > rock64Sheldon.coyote.den dev eth0 lladdr 3e:1b:98:17:e3:8c STALE > scanner.coyote.den dev eth0 lladdr 30:05:5c:8a:2d:c8 STALE > picnc.coyote.den dev eth0 lladdr b8:27:eb:d3:47:2d STALE > lathe.coyote.den dev eth0 lladdr 38:60:77:cd:f3:2f STALE > router.coyote.den dev eth0 lladdr 4c:e6:76:ad:34:0a STALE > GO704.coyote.den dev eth0 lladdr 00:1a:a0:a7:a8:d4 STALE > shop.coyote.den dev eth0 lladdr 38:60:77:4e:38:1b STALE > > No clue why it should mark them all as stale except they've been up since > the last power failure. This room is the only UPS and not all of it is > on the UPS. I also have a 20kw nat-gas standby in the backyard, so > failures are just short enough to screw up the auto-reboot settings.
STALE has nothing to do with it. A typical ARP record (MAC-IP correspondence) has very limited lifetime (30 seconds by default IIRC). STALE shows you that this host haven't send any packets to these hosts in last 30 seconds. Also, ip-neighbour(8). > >Frankly I'm not surprised that it failed to resolve 224.0.0.251. Nobody > >sane would add a DNS record for this anyway. > > I think thats from avahi, is definitely is not anything I have > configured. Multicasts are not anything that *anyone* should configure. The whole idea of them is that your L2 network segment configures by itself. Reco
