-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Martin,
On 4/5/14, 8:35 AM, Martin Gainty wrote: > > > >> Date: Sat, 5 Apr 2014 06:57:23 -0400 From: dcker...@verizon.net >> To: users@tomcat.apache.org 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 > > MG> ipconfig/flushdns *should* flush the ips and the dns entries to > test use a browser that doesnt cache dns entries (like firefox) Firefox sure does cache DNS entries. Just Google for "firefox dns cache" and you'll find many recipes for flushing the cache. > go to address bar > > about:config network.dnsCacheExpirationGracePeriod > > http://kb.mozillazine.org/Network.dnsCacheExpiration You just gave instructions to alter Firefox's DNS cache. (!!) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTQD3AAAoJEBzwKT+lPKRYpR0P/jp9BUFs5BasKJZIkGHoj1bA T1ACjBJYxSEzBKxZPFMKh+UQhNl00FitoSnjzB4YWHT2A814S0P/6DVFn8+dh6Qe CYqEFD2L6xhwMfqPcysEU9K2UtdFV/E5uSqS2pysNb399YIA4dagRYCy92YcBH9K HFLKvbJ/wwM7GqaHfvqeoSUJ4aJUGF08pnwBPwW+3tpM9jYu5qZelgAsGQrhJ2uS jWok1Zcvl1qbXOciNTb6DKJklwLoI5hsp5C7Y7LdRV3Ner9nZ/zWuaVfGPrXL+XW +lfbo0S10datHBJl5afFOcusvFSU7cHmhBljkK1QfzAg4OyYt+OpNRFCWFoy1KSU yVgVcEcKy3TH5P+lmN5NCvXv3J9TKB5eOqLL/Kws6TVj+sLMb8pJTGum/Nzs2es3 i+//gBQLS9sQVF42HEC+QDc4Vp1346ICsTpYku1Tv+NeexG7xZyHDmAgBjF7IfnV s2ihdQ0quT9gK6RyGYyNNcm5k8NCJwYgWiytmz0dBq2Kr+s2P4r9+hI8n6QU5c7F Fm4MgsI48SgP9M8Pv4MMtJ5/GOKvLUzX3/bT4N9M9JW4tudelhYyGJ0M1bY6VBw0 yLlNtfLTbB4G9G0YNsnMEDQ+IptHm1G5bM+sUzAeUfuDshaKTOygPWC1fCb5DUNd /Eilbqa1uw/wtEvXLBeM =LsAW -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
