Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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
share|improve this question
    
Can you post a routing table from OSX? Hopefully netstat -rn –  Paul Aug 15 '12 at 4:23
    
@Paul I added it to the description above. –  Peter Meth Aug 15 '12 at 13:57
    
You have a strange route for the 5.0.0.0/8 network there, which is likely to be the source of the problem. Can you disable hamachi and try again? –  Paul Aug 15 '12 at 22:42
    
Wow, you're a genius. I uninstalled hamachi and things started working. –  Peter Meth Aug 16 '12 at 2:24
    
@Paul If you care to put in an answer I will mark it as accepted. –  Peter Meth Aug 16 '12 at 2:31

2 Answers 2

up vote 10 down vote accepted

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.

share|improve this answer
    
uninstalling hamachi solved the issue. great explanation. this is exactly what i was looking for. –  Peter Meth Aug 16 '12 at 13:19

An alternative will be to switch your Hamachi client to IPv6.

I did it under Mountain Lion 10.8.1 (same issue, unable to access pear.php.net), and I can now access it without issues and at the same time keep my office and home computers still connected.

To switch to IPv6, just go to "LogMeIn Hamachi > Preferences > Settings > Advanced settings > Peer connections > IP protocol mode" and switch to "IPv6 only". Reconnect again and try to access to pear.php.net.

Using last Hamachi client version here, 2.1.0.322 for OSX

share|improve this answer
    
good point. i will give that a try. i haven't used hamachi much lately so I have lived without it since deleting it, but I can see one day needing it again. –  Peter Meth Aug 30 '12 at 13:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.