Summary: | net-analyzer/netselect no longer finds servers - no output | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Hal Engel <hvengel> |
Component: | Current packages | Assignee: | Gentoo Netmon project <netmon> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | cedk |
Priority: | High | ||
Version: | 2006.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Hal Engel
2006-10-09 10:57:11 UTC
for me it is working for ntp1.sf-bay.org : netselect -vv ntp1.sf-bay.org Running netselect to choose 1 out of 1 address. ............ ntp1.sf-bay.org 149 ms 17 hops 100% ok (10/10) [ 402] 402 ntp1.sf-bay.org It can be a firewall problem. As it is explain in the README netselect don't send ICMP message but UDP packets with "random-guess" TTL values. I checked my firewall (I have an external hardware firewall/router) and the only UDP ports I had open were for ntp (port 123). Looking in the netselect README I could not find what UDP port(s) it uses. So I opened all available UDP ports both in and out as a test and netselect still failed in exactly the same way. The strange thing is that this worked not that long ago as I had used it to select gentoo mirrors the last time I did a Gentoo install in July. But that was the last time I had used netselect until I installed ntp on a fresh Gentoo install the other day. My firewall configuration was exactly the same in July as it is today. Is there anything else I can try? what is the output of : netselect -vvv ntp1.sf-bay.org $ netselect -vvv ntp1.sf-bay.org Running netselect to choose 1 out of 1 address. ntp1.sf-bay.org - TIMEOUT ntp1.sf-bay.org - TIMEOUT ntp1.sf-bay.org - TIMEOUT ntp1.sf-bay.org - TIMEOUT ntp1.sf-bay.org - TIMEOUT ntp1.sf-bay.org - TIMEOUT ntp1.sf-bay.org 9999 ms 30 hops 0% ok It looks like the UDP packets are block because you have timeout When I check my router/firewall logs I find something interesting. It appears that I am getting back ICMP packets from the ntp server and these are being blocked by my firewall. Here are the messages in my firewall/router log: Oct/09/2006 13:30:05 Drop ICMP packet from WAN 192.83.249.28:3 xx.xx.xxx.xxx:3 Rule: Default deny Oct/09/2006 13:30:01 Drop ICMP packet from WAN 192.83.249.28:3 xx.xx.xxx.xxx:3 Rule: Default deny Oct/09/2006 13:29:58 Drop ICMP packet from WAN 192.83.249.28:3 xx.xx.xxx.xxx:3 Rule: Default deny 192.83.249.28 is ntp1.sf-bay.org and xx.xx.xxx.xxx is the address of my router (I changed this to hide my address). So it appears that my router/firewall is blocking some of the return packets. What I don't understand is if netselect is sending UDP packets why aren't the return packets also UDP? I drop all ping packets from the WAN at the firewall so this could affect ICMP packets. I turned this off and it didn't make any difference. The messages are still showing up in the firewall/router log and netselect times out. I think the :3 after the address means that this is using port 3. When I check my router/firewall logs I find something interesting. It appears that I am getting back ICMP packets from the ntp server and these are being blocked by my firewall. Here are the messages in my firewall/router log: Oct/09/2006 13:30:05 Drop ICMP packet from WAN 192.83.249.28:3 xx.xx.xxx.xxx:3 Rule: Default deny Oct/09/2006 13:30:01 Drop ICMP packet from WAN 192.83.249.28:3 xx.xx.xxx.xxx:3 Rule: Default deny Oct/09/2006 13:29:58 Drop ICMP packet from WAN 192.83.249.28:3 xx.xx.xxx.xxx:3 Rule: Default deny 192.83.249.28 is ntp1.sf-bay.org and xx.xx.xxx.xxx is the address of my router (I changed this to hide my address). So it appears that my router/firewall is blocking some of the return packets. What I don't understand is if netselect is sending UDP packets why aren't the return packets also UDP? I drop all ping packets from the WAN at the firewall so this could affect ICMP packets. I turned this off and it didn't make any difference. The messages are still showing up in the firewall/router log and netselect times out. I think the :3 after the address means that this is using port 3. So it is clear that the problem comes from your firwall. I think this bug can be closed. I am not sure about the source of the problem. It could be the firewall or it could be something else. But at this point I think closing this is OK. I will get a packet sniffer installed and do some more testing to see if I can get a better handle on what is happening. As explain above, it must be a firewall problem |