Thank you, for your ideas.
Ray Olszewski wrote: > > If I had to *guess*, my guess would be that what you logged is an icmp reply > from a router on the path to some host you were trying to reach. The router > in question is *supposed* to be AT&T's route to the address you were trying > to reach, but it actually cannot reach it. (For example, it is a dial-up IP > address not in use at the moment you tried to reach it.) Yes, that makes sense, except that this box has _no_ reason -- that I know about -- for contacting the outside world. It is a development-only box, from which I have never accessed anything outside of my own internal network. > At 09:20 AM 5/1/02 -0500, Michael D. Schleif wrote: > [...] > >[1] My question is, *how* can an icmp packet get through DCD _and_ get > >to an internal, NAT'ed system ??? > > By being a reply to an outgoing icmp (or other) packet. If you enable icmp > NAT'ing, the router can handle this just fine. I don't actually recall, but > I'd expect stock DCD to work that way. > > [...] > >[4] Strange message logged this morning: > > > > # grep icmp /var/log/syslog > > May 1 07:02:55 Frigg icmplogd: destination unreachable from > >[12.244.72.230] > > May 1 07:09:19 Frigg icmplogd: destination unreachable from > >[12.244.72.230] > > I assume this log is on a NAT'd host, not on the router itself. Yes -- on Frigg. > >[5] 12.244.72.230 is somewhere on AT&T network; but, doesn't have a dns > >name nor reverse lookup: > > Not unusual for routers. OK, that, too, makes sense . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . .
