> -----Original Message----- > From: David Kerber [mailto:dcker...@verizon.net] > Sent: Saturday, April 05, 2014 5:57 AM > To: Tomcat Users List > Subject: Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does > not work > > ... > > >>>>> but > >>>>>> if the server is a *nix implementation, the better diag tool > >>>>>> might be dig. And yes, I would not expect the address 0.0.0.0 on > >>>>>> a client to connect to the localhost. That is a special case > >>>>>> address > >>>> meaning > >>>>>> "local network". If anything, it would be sending packets out > the > >>>>>> NIC card, not via loopback. > >>>>> 0.0.0.0 means "all IPv4 interfaces available" and only applies > for > >>>>> binding a server socket. You can never connect to "0.0.0.0" > >>>>> as a client. > >>>>> > >>>> Chris - It actually has a different meaning based on use. For > >>>> binding to a socket in the local IP stack, it means what you say. > >>>> In the routing table, it means the default route. In > >>>> firewalls/routers, it probably means something completely > >>>> different. When used as a destination address, it means what I > >>>> said. How the IP stack/hardware deals with it is dependent on the > >>>> implementation. The RFCs specify that it should be treated the > same > >>>> as the broadcast address, but local network only, and not > routable. > >>>> That may be for received packets only, as I've seen other > >>>> references that it should never be used on-the-wire, unless as the > >>>> source address in protocols like DHCP. In any event, definitely > not > >>>> expect the 0.0.0.0. address to get any response, either local host > >>>> or otherwise. For the OP's specific problem, s/he need to see how > >>>> "localhost" is resolving. Most systems define it in the local > >>>> "hosts" file, either /etc/hosts > >>>> (*nix) or c:\Windows\system32\etc\hosts. Not sure for other > >>>> systems. Jeff > >>> Make that C:\Windows\system32\drivers\etc\hosts. > >>> > >>> I did a test and it appeared that ping didn't rely on the entry > >>> being there, but it could have been a cached result. > >> Way back in the day when I had the misfortune to use Windows > >> regularly for stuff like this, I seem to recall that almost nothing > >> short of a reboot would cause the "hosts" file to be re-read. > >> > >> - -chris > > > > > > If I remember correctly, the Windows resolver cache may be cleared > > from a command prompt with ipconfig and that should include entries > > from the hosts file. Seems like I may have had to restart the > browser > > though to see any changes to the hosts file. > > ipconfig /flushdns >
>From empirical testing over the years, I'm pretty sure that Microsoft >implements multiple levels of DNS caching. I'm positive that the IE browser >will cache some information on its own. I've had DNS failures that would not >resolve at the browser level after being fixed until I restarted the browser. >I could resolve with nslookup, ping, etc., but the browser would still report >an error. Even the "ipconfig /flushdns" would not fix it for IE. If only the >kids at MS would do things the correct and consistent way, life would be >easier for all of us. On my previously referenced test, I modified the hosts table to use 127.0.0.10 for the localhost entry. Ping picked it up right away, but reported results were from 127.0.0.1, which I'm sure was probably because of the initialized value pulled from the hosts table at boot. Did not try, do not care, but it might have replied from the 10 address after a reboot. Note, I did not expect to see a change on an nslookup, since that tool is designed to query the DNS servers directly, bypassing the resolver. It's a test tool for the DNS system, not the resolver sub-system. This has gotten way of topic, so last word on my part. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
