osx - Why can't I route to some sites from my MacBook Pro that I can see from my iPad?
2014-04
Robert Atkins
Possible Duplicate:
Mac OS X traceroute not even reaching router gateway
I am on M1 Cable (residential) broadband in Singapore.
I have an intermittent problem routing to some sites from my MacBook Pro—often Google-related sites (arduino.googlecode.com and ajax.googleapis.com right now, but sometimes even gmail.com.) This prevents StackExchange chat from working, for instance. Funny thing is, my iPad can route to those sites and they're on the same wireless network! I can ping the sites, but not traceroute to them which I find odd.
That I can get through via the iPad implies the problem is with the MBP. In any case, calling M1 support is... not helpful.
I get the same behaviour when I bypass the Airport Express entirely and plug the MBP directly into the cable modem. Can anybody explain a) how this is even possible and b) how to fix it?
mella:~ ratkins$ ping ajax.googleapis.com
PING googleapis.l.google.com (209.85.132.95): 56 data bytes
64 bytes from 209.85.132.95: icmp_seq=0 ttl=50 time=11.488 ms
64 bytes from 209.85.132.95: icmp_seq=1 ttl=53 time=13.012 ms
64 bytes from 209.85.132.95: icmp_seq=2 ttl=53 time=13.048 ms
^C
--- googleapis.l.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.488/12.516/13.048/0.727 ms
mella:~ ratkins$ traceroute ajax.googleapis.com
traceroute to googleapis.l.google.com (209.85.132.95), 64 hops max, 52 byte packets
traceroute: sendto: No route to host
1 traceroute: wrote googleapis.l.google.com 52 chars, ret=-1
*traceroute: sendto: No route to host
traceroute: wrote googleapis.l.google.com 52 chars, ret=-1
^C
mella:~ ratkins$
The traceroute from the iPad goes (and I'm copying this by hand):
10.0.1.1
119.56.34.1
172.20.8.222
172.31.253.11
202.65.245.1
202.65.245.142
209.85.243.156
72.14.233.145
209.85.132.82
From the MBP, I can't traceroute to any of the IPs from 172.20.8.222 onwards.
RedGrittyBrick
Firstly, the traceroute: sendto: No route to host message is your primary clue. Your MacBook Pro's network configuration isn't fully functional. Perhaps the MacBook is configured with some static settings that overide the settings that are obtainable by DHCP from your cable broadband modem or router?
Secondly MacBooks and iPads run different operating systems. It is possible that this has some bearing on the problem. Either in the way these devices pick up wireless settings or in the way tracert/traceroute work (normally they use ICMP protocol but some variants use TCP - it is possible that ICMP is blocked at some router/firewall)
On the Macbook Pro, can you get it to display it's network settings - chiefly default gateway and DNS servers? E.g. ifconfig -a
If you can see the equivalent informatio on the iPad - look for differences.
Robert Atkins
Turns out this was the answer (tl;dr, nuke Peerguardian from orbit.)
Randall
I have been having problems connecting with my Wi-Fi. It is weird, the ping times to the router (<30 feet away) seem to surge, often getting over 10 seconds before slowly coming back down. You can see the trend below. I'm on a MacBook Pro and have done the normal stuff (reset the PRAM and SMC, changed wireless channels, etc.). It happens across different routers, so I think it must be my laptop, but I don't know what it could be.
The RSSI value hovers around -57, but I've seen the transmit rate flip between 0, 48 and 54. The signal strength is ~60% with 9% noise. Currently, there are 17 other wireless networks in range, but only one in the same channel.
1 - How can I figure out what's going on?
2 - How can I correct the situation?
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=254 time=781.107 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=254 time=681.551 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=254 time=610.001 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=254 time=544.915 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=254 time=547.622 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=254 time=468.914 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=254 time=237.368 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=254 time=229.902 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=254 time=11754.151 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=254 time=10753.943 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=254 time=9754.428 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=254 time=8754.199 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=254 time=7754.138 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=254 time=6754.159 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=254 time=5753.991 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=254 time=4754.068 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=254 time=3753.930 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=254 time=2753.768 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=254 time=1753.866 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=254 time=753.592 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=254 time=517.315 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=254 time=1.315 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=254 time=1.035 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=254 time=4.597 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=254 time=18010.681 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=254 time=17010.449 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=254 time=16010.430 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=254 time=15010.540 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=254 time=14010.450 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=254 time=13010.175 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=254 time=12010.282 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=254 time=11010.265 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=254 time=10010.285 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=254 time=9010.235 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=254 time=8010.399 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=254 time=7010.144 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=254 time=6010.113 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=254 time=5010.025 ms
64 bytes from 192.168.1.1: icmp_seq=35 ttl=254 time=4009.966 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=254 time=3009.825 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=254 time=16000.676 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=254 time=15000.477 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=254 time=14000.388 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=254 time=13000.549 ms
64 bytes from 192.168.1.1: icmp_seq=44 ttl=254 time=12000.469 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=254 time=11000.332 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=254 time=10000.339 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=254 time=9000.338 ms
64 bytes from 192.168.1.1: icmp_seq=48 ttl=254 time=8000.198 ms
64 bytes from 192.168.1.1: icmp_seq=49 ttl=254 time=7000.388 ms
64 bytes from 192.168.1.1: icmp_seq=50 ttl=254 time=6000.217 ms
64 bytes from 192.168.1.1: icmp_seq=51 ttl=254 time=5000.084 ms
64 bytes from 192.168.1.1: icmp_seq=52 ttl=254 time=3999.920 ms
64 bytes from 192.168.1.1: icmp_seq=53 ttl=254 time=3000.010 ms
64 bytes from 192.168.1.1: icmp_seq=54 ttl=254 time=1999.832 ms
64 bytes from 192.168.1.1: icmp_seq=55 ttl=254 time=1000.072 ms
64 bytes from 192.168.1.1: icmp_seq=58 ttl=254 time=1.125 ms
64 bytes from 192.168.1.1: icmp_seq=59 ttl=254 time=1.070 ms
64 bytes from 192.168.1.1: icmp_seq=60 ttl=254 time=2.515 ms
dubiousjim
In earlier Mac laptops it was easy to get at the wifi card (just under the easily-opened keyboard), I don't know whether this is still true.
If it is, I'd recommend unplugging and replugging the connector to that card. In years past, others had problems like this that were solved by reseating that connector.
Peter Mortensen
That ping output is crazy. It's like nothing gets through for 16-18 seconds, and then suddenly it all comes through at once. Even if there were problems with 802.11n frame aggregation and Block Acks, I wouldn't expect everything to get queued and stay queued for 18 seconds and then suddenly all come through. It's also very strange to see out-of-order packets on a single-hop network.
Do you have access to a spectrum analyzer, such as a Metageek Wi-Spy? If you're using the 2.4 GHz band, the $99 Wi-Spy 2.4i is fun thing to have, and very useful for seeing if your neighbor's microwave oven is knocking out the entire band for several seconds at a time.
By the way, do an ifconfig en1 and make sure you don't see PROMISC in the list of interface flags. Some wireless cards don't handle promiscuous mode very well. Even if you don't run things like tcpdump and Wireshark, sometimes poorly written network applications will accidentally set promscuous mode when they didn't really mean to, because they made the wrong calls to libpcap or BPF.
- What version of Mac OS X are you running?
- What's the make/model/hardware-revision/firmware-version of your access point?
- Is the firmware on your access point up to date?
- Do you just have the one access point at this time, or do you have multiple APs "extending the network" wirelessly?
I know you've tried different channels, but have you tried different bands? For instance, if you've been doing this all in the 2.4 GHz band -- channels 1-11, plus perhaps 12, 13, and even 14 in some regions -- it would be interesting to know if the problem goes away if you switch the AP to the 5 GHz band (channel 36 and above).
On Snow Leopard, you can run this to enable lots of AirPort debug logs:
sudo /usr/libexec/airportd debug +AllUserland +AllVendor +AllDriver
Then watch what gets logged to /var/log/kernel.log and /var/log/system.log.
Leopard doesn't have as much logging for this, but you can enable it like this:
sudo /usr/libexec/airportd -d
Leopard doesn't have the separate kernel.log, so it'll probably all go to system.log.
Does the problem go away when you're connected to the AC power adapter as opposed to battery? Modern Mac laptops automatically enable 802.11 powersave mode when on battery. Powersave mode can increase latency some; usually on the order of 100 ms, not even a full second. But it would still be interesting to know if running from AC power makes a difference.