I am stumped by this issue. I have 2 separate Macs that cannot access pear.php.net at all by name or IP.
Here are the symptoms and steps that I took to try to resolve/narrow down this issue.
$ ping -c 4 pear.php.net
PING euk1.php.net (5.77.39.20): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- euk1.php.net ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 4 5.77.39.20
PING 5.77.39.20 (5.77.39.20): 56 data bytes
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: Host is down
Request timeout for icmp_seq 1
ping: sendto: Host is down
Request timeout for icmp_seq 2
--- 5.77.39.20 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
From a Windows PC on the same network (I even used the same ethernet cable just to be sure)
c:\>ping pear.php.net
Pinging euk1.php.net [5.77.39.20] with 32 bytes of data:
Reply from 5.77.39.20: bytes=32 time=102ms TTL=51
Reply from 5.77.39.20: bytes=32 time=102ms TTL=51
Reply from 5.77.39.20: bytes=32 time=100ms TTL=51
Reply from 5.77.39.20: bytes=32 time=102ms TTL=51
Ping statistics for 5.77.39.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 100ms, Maximum = 102ms, Average = 101ms
- Both machines are running OSX 10.7
- Tried both wired and wifi, same result
- Tried one of the Macs on a different network, same result
- Tried with firewall on and off, same result
- Have not had this problem with any other site / IP
- Tried to open both pear.php.net and 5.77.39.20 in a browser, got 404
Edit: In response to Paul's comment
$netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 18 0 en1
5 link#8 UC 2 0 ham0
5.255.255.255 ff:ff:ff:ff:ff:ff UHLWbI 0 10 ham0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 3 152 lo0
169.254 link#5 UCS 0 0 en1
192.168.0 link#5 UCS 4 0 en1
192.168.0.1 0:1b:6c:69:19:8f UHLWIi 28 634 en1 1141
192.168.0.192 127.0.0.1 UHS 0 0 lo0
192.168.0.194 0:21:a0:50:4d:70 UHLWIi 0 498 en1 669
192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 10 en1
Internet6:
Destination Gateway Flags Netif Expire
::1 link#1 UHL lo0
2620:9b::/96 link#8 UC ham0
2620:9c::5f7:6deb 7a:7c:5:f7:6d:eb UHL lo0
fe80::%lo0/64 fe80::1%lo0 UcI lo0
fe80::1%lo0 link#1 UHLI lo0
fe80::%en0/64 link#4 UCI en0
fe80::205:ff:fee1:a1a2%en0 0:5:0:e1:a1:a2 UHLWIi en0
fe80::%en1/64 link#5 UCI en1
fe80::1240:d3ff:feaf:8974%en1 10:40:d3:af:89:74 UHLI lo0
fe80::%ham0/64 link#8 UCI ham0
fe80::7879:5ff:fec7:6deb%ham0 7a:79:5:c7:6d:eb UHLI lo0
ff01::%lo0/32 fe80::1%lo0 UmCI lo0
ff01::%en0/32 link#4 UmCI en0
ff01::%en1/32 link#5 UmCI en1
ff01::%ham0/32 link#8 UmCI ham0
ff02::%lo0/32 fe80::1%lo0 UmCI lo0
ff02::%en0/32 link#4 UmCI en0
ff02::%en1/32 link#5 UmCI en1
ff02::%ham0/32 link#8 UmCI ham0
Answer
You have a route for the 5.0.0.0/8 network there leading to the ham0 interface.
This is the hamachi interface. When Hamachi started their service, they chose the 5.0.0.0/8 network as their pool of addresses to avoid conflicting with any existing ranges. However, hamachi were never allocated this range.
In the past couple of months, RIPE (who are responsible for this range) have started selling blocks in the 5/8 network. This was inevitable with the quickly depleting numbers of ipv4 addresses, yet hamachi are still using this block.
If you want to access services in this range, then you will need to uninstall hamachi - or at least disable it while accessing those blocks. You could also manually delete the route each time.
The real fix will be for hamachi to purchase a block that they are entitled to use, or to switch to ipv6.
No comments:
Post a Comment