osx - I won't open some websites on my MacBook Pro. What could be an issue?
2014-07
user984621
For example some-websites.com. If I put it to the browser, I get this:
I know about 3 other websites that returns the same "error". If I try ping in terminal, I get this:
...
Request timeout for icmp_seq 196
ping: sendto: Host is down
...
--- some-websites.com ping statistics ---
202 packets transmitted, 0 packets received, 100.0% packet loss
When I put on load the same URL on iPhone, iPad or a different PC, it's working well.
Why I cannot load this URL on my MacBook Pro? Where to start with looking for the issue?
Thank you guys.
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.