Wifi Constantly Dropping in Lion

emteek wrote:

I have the issue, and I'm running 10.6.8. Wifi bars stay dark. Macbook connection drops out. All other devices in the house (voip, PC, android phone) stay connected so my router is still operational. Macbook connection is restored when I cycle power on its airport software switch. I just discovered this forum. I have been running Snow Leopard for almost a year and am just noticing this wifi issue (or whatever it is) in the last week. Perhaps it has been laying dormant or has been very infrequent that I haven't noticed it until now. I need a solid connection for school (taking online tests, etc.). I have made some router changes (increased security) in the last week and will investigate returning back to WEP from WPA among other changes. Fixing a problem that appears intermittently is more difficult than something that can be repeatedly broken in a predictable pattern, and stays broken. The problem occured several times this afternoon but I do not know how to trigger it.

Can you try changing MTU as well to see if the additional security, changed the size of data in packets to create problems that MTU reduction might fix? Try 1490, 1480 or something in that neighborhood.

The fact that bars stay dark, implies that the "WiFi" signal between your router and your computer is staying up, but some other bits of data packet contents, is not flowing. One of the things that seems easiest to check, is simple packet routing. When the network is not functioning, but the bars stay black, can you open a terminal window and see if the command "ping -n 8.8.8.8" (type this and hit return), reports successful pings, or does it timeout? If it works, that implies the network is functioning at a packet flow level. You can leave it running for a while to see if there is some kind of periodic loss of packet flow.

Next, if that works, then try doing "dig -x 8.8.8.8" to see if your DNS server will report back the "PTR" record for 8.8.8.8. You should see output like the following:

$ dig -x 8.8.8.8

; <<>> DiG 9.8.3-P1 <<>> -x 8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36969

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;8.8.8.8.in-addr.arpa. IN PTR

;; ANSWER SECTION:

8.8.8.8.in-addr.arpa. 10892 IN PTR google-public-dns-a.google.com.

;; Query time: 59 msec

;; SERVER: 10.0.0.1#53(10.0.0.1)

;; WHEN: Thu Nov 22 21:55:45 2012

;; MSG SIZE rcvd: 82

The underlined line above shows that the query was succesful.

If both of these work, but you web browsing still does not work, then check you WiFi settings under the Advanced details. Click the DNS tab, and see if there are any entries in there which seem suspect. The above query, can be altered slightly, to "test" the shown DNS servers, to see if one is just not functioning correctly. You can use "dig @<ip-address> -x 8.8.8.8" to see if a particular server works.

My "router" performs DNS proxy functions, so it's IP address is shown in the list of DNS servers. It is 10.0.0.1, and so if I type "dig @10.0.0.1 -x 8.8.8.8", I can test it explicitly. If there is just one router in the list, then the first query, "dig -x 8.8.8.8", would of tested it already.

thanks for responding!

lost radio again, bars are full strength, can't ping 8.8.8.8.

have to figure out what you mean by MTU.

i'm typing this on my (groan) windows machine that is happy as can be, albeit wired

some more details

I can't ping my router 192.168.1.1 either (times out)

airport status under network is 'connected' with a 'green' color status

connecting an ethernet cable from the macbook to the router instantly gets the internet back

network status appears 'green' for both ethernet and airport

i can check mail, etc.

removing the ethernet cable instantly breaks the connection, ethernet goes 'red'

some hardware details

running a dlink DI-624 router, firmware version 2.76 (its the latest)

I have a new router from my ISP but my ibook didn't work with it so I went back to the old router (dlink)

maybe i can install some radio monitoring software or attempt to update the wireless card's firmware?

i have not tried as others have to set a periodic ping to keep the radio operational

Figured out how to change the ethernet MTU under both ethernet and airport to 1480, it was set to 1500

Here are my airport radio stats under system profiler for the macbook

Software Versions:

Menu Extra: 6.2.2 (622.2)

configd plug-in: 6.2.5 (625.6)

System Profiler: 6.0.1 (601.1)

Network Preference: 6.2.2 (622.2)

AirPort Utility: 5.6.1 (561.3)

IO80211 Family: 3.2 (320.1)

Interfaces:

en1:

Card Type: AirPort Extreme (0x14E4, 0x88)

Firmware Version: Broadcom BCM43xx 1.0 (5.10.131.42.4)

Locale: FCC

Country Code: US

Supported PHY Modes: 802.11 a/b/g/n

Supported Channels: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64, 149, 153, 157, 161, 165

Wake On Wireless: Supported

Status: Connected

Current Network Information:

21146:

PHY Mode: 802.11g

BSSID: x:xx:xx:xx:xx:xx

Channel: 11

Country Code: US

Network Type: Infrastructure

Security: WPA Personal

Signal / Noise: -65 dBm / -91 dBm

Transmit Rate: 54

There are five other wireless networks within range, on channels 1,2 and 6.

emteek wrote:

Here are my airport radio stats under system profiler for the macbook

Okay, that looks like a decent RSSI/SNR, -65 dBm/-91 dBm. And since the bars stay black, it sounds like the wireless is staying up.

Okay, since the ping is not working to 8.8.8.8, let alone just to the router, that sounds like extreme packet loss or something related to misdirected packets. If you type "route get 8.8.8.8", does it return the interface that is your WiFi?

$ route get 8.8.8.8

route to: google-public-dns-a.google.com

destination: default

mask: default

gateway: 10.0.0.1

interface: en1

flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>

recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire

0 0 0 0 0 0 1500 0

The interface shown, can be inspected for status with something like the following, substuting "en1" for whichever interface is shown above.

$ ifconfig | grep -A4 en1

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500

ether 00:23:6c:9a:14:ec

inet6 fe80::223:6cff:fe9a:14ec%en1 prefixlen 64 scopeid 0x5

inet 10.0.0.6 netmask 0xffffff00 broadcast 10.0.0.255

media: autoselect

status: active

fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078

All of that information indicates whether the interface is actually capable of passing traffic. The "status: active" and there being an "inet" line with an appropriate IP address for your network, which you said was 192.168.1.0/24.

gphonei wrote:

If you type "route get 8.8.8.8", does it return the interface that is your WiFi?

with the wired ethernet rj45 connected to the router...

$ route get 8.8.8.8

route to: google-public-dns-a.google.com

destination: default

mask: default

gateway: 192.168.1.1

interface: en0

flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>

recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire

0 0 0 0 0 0 1480 0

$ ifconfig | grep -A4 en0

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1480

ether 00:1b:63:a4:4c:7c

inet6 fe80::21b:63ff:fea4:4c7c%en0 prefixlen 64 scopeid 0x4

inet 192.168.1.104 netmask 0xffffff00 broadcast 192.168.1.255

media: autoselect (100baseTX <full-duplex>)

status: active

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1480

removing rj45 wired connection (resort to default airport radio, which isn't operational unless I cycle power...which I purposefully haven't done so it will stay 'broken')

$ route get 8.8.8.8

route to: google-public-dns-a.google.com

destination: default

mask: default

$ ifconfig | grep -A4 en0

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1480

ether 00:1b:63:a4:4c:7c

media: autoselect

status: inactive

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1480

cheers if you can make sense of this 🙂

192.168.1.1 is my router

192.168.1.104 is my macbook

emteek wrote:

...

removing rj45 wired connection (resort to default airport radio, which isn't operational unless I cycle power...which I purposefully haven't done so it will stay 'broken')

$ route get 8.8.8.8

route to: google-public-dns-a.google.com

destination: default

mask: default

$ ifconfig | grep -A4 en0

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1480

ether 00:1b:63:a4:4c:7c

media: autoselect

status: inactive

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1480

cheers if you can make sense of this 🙂

192.168.1.1 is my router

192.168.1.104 is my macbook

Your wired network interface was en0. The Airport/WiFi adapter is probably en1. Can you do

ifconfig | grep -A4 en1

and show what that returns?

gphonei wrote:

Your wired network interface was en0. The Airport/WiFi adapter is probably en1. Can you do

ifconfig | grep -A4 en1

and show what that returns?

roger that.

$ ifconfig | grep -A4 en1

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1480

ether 00:1d:4f:f6:e3:a7

inet6 fe80::21d:4fff:fef6:e3a7%en1 prefixlen 64 scopeid 0x5

inet 192.168.1.102 netmask 0xffffff00 broadcast 192.168.1.255

media: autoselect

status: active

fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 2030

the airport radio is back up and running since the macbook woke from sleep

"route get 8.8.8.8" with the wired connection disconnected shows the interface is en1 (radio)

emteek wrote:

gphonei wrote:

Your wired network interface was en0. The Airport/WiFi adapter is probably en1. Can you do

ifconfig | grep -A4 en1

and show what that returns?

roger that.

$ ifconfig | grep -A4 en1

en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1480

ether 00:1d:4f:f6:e3:a7

inet6 fe80::21d:4fff:fef6:e3a7%en1 prefixlen 64 scopeid 0x5

inet 192.168.1.102 netmask 0xffffff00 broadcast 192.168.1.255

media: autoselect

status: active

fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 2030

the airport radio is back up and running since the macbook woke from sleep

"route get 8.8.8.8" with the wired connection disconnected shows the interface is en1 (radio)

okay, that seems to indicate the right information to say that your wireless is "up" and should be functioning as you said it did come back up. If you can check this the next time it fails, the important thing is the "status", to make sure it is active, and then the "inet" line to make sure an address is allocated. If you have an Apple store near by, and have Apple Care still going, I'd suggest taking your router and your computer to the Apple store to show them that you can't ping your router even though it says it's up.

The problem, of course, is that it might take some time for it to fail again once you power everything up at the store.

If you look around with Google, you should be able to find the instructions for turning on wireless debug logging which could tell you more about what is happening in the hardware. If you need some pointers or direct instructions, I can get that together for you at some point.

gphonei wrote:

If you need some pointers or direct instructions, I can get that together for you at some point.

Appreciate all the help. I don't have Apple Care, unfortunately. It might be of some value to keep the macbook running when the wireless conks out and take it to a free wifi zone and see if it would connect which would isolate my environment (router, interference). There are many signals floating around and my router channel hops between 1 and 11 it seems, although my signal is typically -20 dBm higher than anyone else.

before I take this problem out for a ride, i'd like to become smarter about it first. I just started running wireshark partly because I don't have the Lion wifi diagnostics (I crashed this thread with snow leopard, hopefully no one is offended or led down the wrong path because of it) and also because i have used wireshark in the past, not skillfully, but nevertheless, i at least know it is one of the better protocol analyzers out there. i am more of a hardware person, so networks are like spaghetti to me but i'm willing to try stuff.

if you are familiar with wireshark or have another preferred tool, kindly point out where i might intelligently start sniffing.

So I am a little unclear as to the nature of the problem people are having. It seems that most people are experiencing the actual wifi bar signal indicator saying there is no connection.

If that is the case, it is different from the problem I am having. My problem is that the black wifi bars remain all the way full, but every so often I just lose connection to the internet. I remain connected to my router but can no longer contact any online servers. sometimes the problem persists only a short time, other times it is for quite a while. I have tried messing around with different DNS settings, because this seems to be the most likely culprit, but to no avail.

If this is the same as the majority of the problems being reported here then disregard this and I'll implement the solutions listed here. If it is infact different then any help would be appreciated.

Chaoguy, you're in the right place. A lot of us here have this same symptom. Black bars stay solid full strength, but no traffic is passing. The workaround is to click on the Wifi bars and click "Turn Wi-Fi Off", wait a few seconds and then turn it back on. This should bring it back for a little while.

No one really knows what the main cause for this is. Some people don't have the issue at all. I suspect that it has something to do with the router that you're using, and the signals being sent to it by your internet provider. If the levels are slightly off, the WiFi may be dropping packets. Wired to Ethernet, we don't see this problem. It only seems to show up with Wifi. My Windows machine next to my iMac doesn't have the problem, but of course it uses different hardware and software that may not be as "sensitive" to these wacky signal issues coming from the router. I've tried using a USB wifi dongle (so that's new hardware and software running it) and still had the issue. I think it's something in OS X that is making it so sensitive to signals for some reason. In my opinion, the fix will be in an update to either the routers firmware, or to OS X, or just cleaning up the signal by my cable operator.

Okay thanks a bunch. It's really strange because I get the problem every so often at my home, but we recently went on vacation to stay with family and the problem was horribly magnified so that I would only be transmitting data the few seconds after restarting the wifi. My work around was to leave the wifi diagnostics tool up and use it whenever the signal cut out, after running it there was a 50/50 chance it would say the connection was okay and it would start working again or it would tell me to restart the router, which was absolutely not the problem, as my brother with an older MacBook but also on lion had zero issues. I'll see how the problem is when I get home where it is more of a minor incovience than an infuriating enigma.

emteek wrote:

gphonei wrote:

If you need some pointers or direct instructions, I can get that together for you at some point.

Appreciate all the help. I don't have Apple Care, unfortunately. It might be of some value to keep the macbook running when the wireless conks out and take it to a free wifi zone and see if it would connect which would isolate my environment (router, interference). There are many signals floating around and my router channel hops between 1 and 11 it seems, although my signal is typically -20 dBm higher than anyone else.

before I take this problem out for a ride, i'd like to become smarter about it first. I just started running wireshark partly because I don't have the Lion wifi diagnostics (I crashed this thread with snow leopard, hopefully no one is offended or led down the wrong path because of it) and also because i have used wireshark in the past, not skillfully, but nevertheless, i at least know it is one of the better protocol analyzers out there. i am more of a hardware person, so networks are like spaghetti to me but i'm willing to try stuff.

if you are familiar with wireshark or have another preferred tool, kindly point out where i might intelligently start sniffing.

If you haven't tried yet, try setting your router to a fixed channel. Either 1, 6 or 11. It sounds like 1 or 11 would be best for your area if your router is hopping around and not picking 6, which is usually full of all the "default" configured routers.

Wireshark, will show you where everyone is at, and help with signal level analysis. In using it, the things that would be most interesting, would be to watch for spikes in the noisefloor or in reduction in RSSI, which could indicate that the radio environment is fluctuating with other signals comming and going. When that occurs, the things to suspect, are wireless telephones, baby monitors, and TV signal extenders and similar things which just might be on for a short period of time.

Other people have reported problems with channel switching causing loss of service often enough to create problems like yours. They've switched to a fixed channel to keep the radio from hopping around. Some have had to try several different ones before finding a solution. The channels are not "separate", but rather overlap in usage, and 802.11n should be on 1, 6 or 11 because it uses adjacent channels for more bandwidth, to provide higher data rates.

Regarding debugging the failed connections, there are instructions on the forums for using lower level, command line activity, to turn on debugging for the network layers.

$ sudo /usr/libexec/airportd debug +alluserland +alldriver +allvendor

will turn on debugging. The various system log files will contain the information about what is happening.

$ sudo /usr/libexec/airportd debug -alluserland -alldriver -allvendor

will turn it off. Search for these commands to see others people experiences and some other comments on their use. In the later versions of OS-X, there are more friendly things for debugging the connection issues.

Chaoguy wrote:

Okay thanks a bunch. It's really strange because I get the problem every so often at my home, but we recently went on vacation to stay with family and the problem was horribly magnified so that I would only be transmitting data the few seconds after restarting the wifi. My work around was to leave the wifi diagnostics tool up and use it whenever the signal cut out, after running it there was a 50/50 chance it would say the connection was okay and it would start working again or it would tell me to restart the router, which was absolutely not the problem, as my brother with an older MacBook but also on lion had zero issues. I'll see how the problem is when I get home where it is more of a minor incovience than an infuriating enigma.

Some people have talked about having blutooth generated interference. If your blutooth is on, try turning it off. Also, when the symptom stays the same, and seems to worsen or improve as you change locations, it can indicate that you are taking the problem with you. However, it can also mean that there is just a common cause in multiple places.

If the tool tells you to restart the router, I'd guess that means that it loss "sight" of the router, but otherwise detected a working "network". Since there are so many layers of things going on, it really can be frustrating to drill through all the issues to find the root cause.

Did you find, and were you able to try the "ping" tests when the "internet is not working?" In particular, the Google public DNS server, 8.8.8.8, is pretty much always reachable, so if you open terminal window, and run "ping -n 8.8.8.8", that will let you know if the network path is up for simple packet flows. The '-n' says don't use DNS to find the name of 8.8.8.8, just use the IP address as is. If that works while the internet is not working, then that can start to point at other, higher level ISP or specific protocol problems.

The DNS services can be tested with "dig" from the terminal. Try stuff like "dig -x 8.8.8.8" and "dig @8.8.8.8 -x 8.8.8.8" to compare, and see if your configured DNS servers (the first dig) are working when the "internet is down", vs forcing googles server to be used (second dig).

Finally, you might try installing "firefox", or "chrome" browsers, and when safari doesn't work, try one of them to see if something changes.

Also, since HTTP is on port 80, you can, in the terminal window, type

telnet www.google.com 80

to see if you can simply connect. If that works, then type "GET /" and hit return, and see what data is returned.