Home / server / Questions / 412214
Accepted
house9
Asked: 2012-07-29 19:28:47 +0800 CST

cannot access a site from Mac OSX Lion but can from other machines on network?

  • 772

SOLVED:

The issue is with the hamachi client, hamachi is hi-jacking all of the 5.0.0.0/8 address block

The fix on Mac

  • LogMeIn Hamachi > Preferences > Settings > Advanced > Peer Connections > IP protocol mode > IPv6 only (default is both)

If you can only connect to some of your network over IPv4 this 'fix' will NOT work for you

-----

A few weeks ago I started using a service - https://semaphoreapp.com I think they made DNS changes a week ago and ever since I cannot access the site from my Mac OSX Lion (10.7.4) machine (my main development machine)

but I can access the site from other machines on my network

  • ipad
  • windows machine
  • MacMini (10.6.8)

After some google searching I tried both of these

  • dscacheutil -flushcache
  • sudo killall -HUP mDNSResponder

but no go, I've contacted semaphoreapp as well, but nothing so far - also of interest, one of my colleagues has the exact same problem, cannot access via Mac OSX Lion but can via windows machine, we work remotely and are not on the same ISP

some additional info

Lion (10.7.4) cannot access site

host semaphoreapp.com
semaphoreapp.com has address 5.9.53.16

ping semaphoreapp.com
PING semaphoreapp.com (5.9.53.16): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
ping: sendto: Host is down
Request timeout for icmp_seq 7
....


traceroute semaphoreapp.com
traceroute to semaphoreapp.com (5.9.53.16), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
traceroute: sendto: No route to host
 3 traceroute: wrote semaphoreapp.com 52 chars, ret=-1
 *traceroute: sendto: Host is down
traceroute: wrote semaphoreapp.com 52 chars, ret=-1
....

and MacMini (10.6.8) can access it

host semaphoreapp.com
semaphoreapp.com has address 5.9.53.16

ping semaphoreapp.com
PING semaphoreapp.com (5.9.53.16): 56 data bytes
64 bytes from 5.9.53.16: icmp_seq=0 ttl=44 time=191.458 ms
64 bytes from 5.9.53.16: icmp_seq=1 ttl=44 time=202.923 ms
64 bytes from 5.9.53.16: icmp_seq=2 ttl=44 time=180.746 ms
64 bytes from 5.9.53.16: icmp_seq=3 ttl=44 time=200.616 ms
64 bytes from 5.9.53.16: icmp_seq=4 ttl=44 time=178.818 ms
....

traceroute semaphoreapp.com
traceroute to semaphoreapp.com (5.9.53.16), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  1.677 ms  1.446 ms  1.445 ms
 2  * LOCAL ISP  11.957 ms *
 3  etc...  10.704 ms  14.183 ms  9.341 ms
 4  etc...  32.641 ms  12.147 ms  10.850 ms
 5  etc....  44.205 ms  54.563 ms  36.243 ms
 6  vlan139.car1.seattle1.level3.net (4.53.145.165)  50.136 ms  45.873 ms  30.396 ms
 7  ae-32-52.ebr2.seattle1.level3.net (4.69.147.182)  31.926 ms  40.507 ms  49.993 ms
 8  ae-2-2.ebr2.denver1.level3.net (4.69.132.54)  78.129 ms  59.674 ms  49.905 ms
 9  ae-3-3.ebr1.chicago2.level3.net (4.69.132.62)  99.019 ms  82.008 ms  76.074 ms
10  ae-1-100.ebr2.chicago2.level3.net (4.69.132.114)  96.185 ms  75.658 ms  75.662 ms
11  ae-6-6.ebr2.washington12.level3.net (4.69.148.145)  104.322 ms  105.563 ms  118.480 ms
12  ae-5-5.ebr2.washington1.level3.net (4.69.143.221)  93.646 ms  99.423 ms  96.067 ms
13  ae-41-41.ebr2.paris1.level3.net (4.69.137.49)  177.744 ms
ae-44-44.ebr2.paris1.level3.net (4.69.137.61)  199.363 ms  198.405 ms
14  ae-47-47.ebr1.frankfurt1.level3.net (4.69.143.141)  176.876 ms
ae-45-45.ebr1.frankfurt1.level3.net (4.69.143.133)  170.994 ms
ae-46-46.ebr1.frankfurt1.level3.net (4.69.143.137)  177.308 ms
15  ae-61-61.csw1.frankfurt1.level3.net (4.69.140.2)  176.769 ms
ae-91-91.csw4.frankfurt1.level3.net (4.69.140.14)  178.676 ms  173.644 ms
16  ae-2-70.edge7.frankfurt1.level3.net (4.69.154.75)  180.407 ms
ae-3-80.edge7.frankfurt1.level3.net (4.69.154.139)  174.861 ms  176.578 ms
17  as33891-net.edge7.frankfurt1.level3.net (195.16.162.94)  175.448 ms  185.658 ms  177.081 ms
18  hos-bb1.juniper4.rz16.hetzner.de (213.239.240.202)  188.700 ms  190.332 ms  188.196 ms
19  hos-tr4.ex3k14.rz16.hetzner.de (213.239.233.98)  199.632 ms
hos-tr3.ex3k14.rz16.hetzner.de (213.239.233.66)  185.938 ms
hos-tr2.ex3k14.rz16.hetzner.de (213.239.230.34)  182.378 ms
20  * * *
21  * * *
22  * * *

any ideas?

EDIT: adding tcpdump

MacMini (which can connect) while running - ping semaphoreapp.com

sudo tcpdump -v -i en0 dst semaphoreapp.com
Password:
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:33:03.337165 IP (tos 0x0, ttl 64, id 20153, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->3129)!)
    192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 0, length 64
17:33:04.337279 IP (tos 0x0, ttl 64, id 26049, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->1a21)!)
    192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 1, length 64
17:33:05.337425 IP (tos 0x0, ttl 64, id 47854, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->c4f3)!)
    192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 2, length 64
17:33:06.337548 IP (tos 0x0, ttl 64, id 24772, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->1f1e)!)
    192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 3, length 64
17:33:07.337670 IP (tos 0x0, ttl 64, id 8171, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->5ff7)!)
    192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 4, length 64
17:33:08.337816 IP (tos 0x0, ttl 64, id 35810, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->f3ff)!)
    192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 5, length 64
17:33:09.337948 IP (tos 0x0, ttl 64, id 31120, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->652)!)
    192.168.0.6 > static.16.53.9.5.clients.your-server.de: ICMP echo request, id 61918, seq 6, length 64
^C
7 packets captured
1047 packets received by filter
0 packets dropped by kernel

OSX Lion (cannot connect) while running - ping semaphoreapp.com

# wireless
~ $ sudo tcpdump -v -i en1 dst semaphoreapp.com
Password:
tcpdump: listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
262 packets received by filter
0 packets dropped by kernel

and

# wired
~ $ sudo tcpdump -v -i en0 dst semaphoreapp.com
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
219 packets received by filter
0 packets dropped by kernel

above output after Request timeout for icmp_seq 25 or 30 times from ping. I don't know much about tcpdump, but to me it doesn't seem like the ping requests are leaving my machine?

domain-name-system

5 Answers

  1. Best Answer

    Are you running Hamachi on the machine which cannot connect to semaphoreapp.com?

    If you are, can I suggest that you disable Hamachi and retry the connection; you can find out more about the Hamachi block at:

    http://en.wikipedia.org/wiki/Hamachi_(software)#Criticism

    • 2

  2. DNS resolution looks fine as you can resolve the name to the correct IP address. I am able to access the site in Lion and Mountain Lion.

    You could try restarting your network interface.

    sudo ifconfig en0 down
sudo ifconfig en0 up

    Replacing en0 with the network interface in use. Use ifconfig with no arguments to figure out the correct interface.

    If you are using two network interfaces--wireless and wired, for example--that could be causing a problem.

    If you are using a VPN that could causing a problem. Basically look for any way in which networking on your Lion box may be configured differently than on your other hosts.

    And, lame as it may be, if you have not tried it a reboot may be in order :)

    • 0

  3. On Lion dscacheutil -flushcache is all that's needed to flush the cache. If that doesn't work then there could be something else in the path, such as proxies or systems with their own DNS cache, which are the issue. There may be little you could do about them other than give it a bit of time.

    If all else fails, get the IP address for the site from a machine that can connect and try using that. On a shared host you may not get the site you're after but at least you will be able to confirm connectivity. If that also gets nowhere you may have something on your systems that is blocking it, so check any kind of firewall application or system you may be running.

    • 0

  4. Yeah, I've seen this issue. Sometimes it's an MTU problem; specifically PMTU detection...

    Can you get to other https sites without incident? Can you try lowering your MTU in System Preferences -> Network -> Interface -> Advanced -> Hardware -> Configure Manually. Maybe set to 1460 or lower instead of the default 1500.

    Also see:

    https://apple.stackexchange.com/questions/39226/https-not-working-on-macbook-pro

    https://superuser.com/questions/413285/os-x-failure-in-path-maximum-transmission-unit-pmtu-black-hole-router-detectio

    • 0

  5. I'm glad you solved your problem, but an issue I discovered with Mac OSX networking is that putting more than one domain on a single line in your /etc/hosts file can cause random things to happen to your networking stack. I'm hoping this can help others that google there way to this question.

    So instead of doing this:

    127.0.0.1 mylocalsite myotherlocalsite localhost eviladnetworksite.com

    you must put them each on a line by themselves

    127.0.0.1 mylocalsite
127.0.0.1 myotherlocalsite
127.0.0.1 localhost
127.0.0.1 eviladnetworksite.com

    You must reboot after making this change to get an uncorrupted networking stack.

    Ref: http://stevegrunwell.com/blog/quick-tip-troubleshooting-etchosts-issues/

    • 0