Q: Wifi Constantly Dropping in Lion

WSR wrote:

 

As Steve Jobs used to say... "It Just Works".

There should be no need for effing about with networks.

And for so many people, it does just work.  It just works for me.  I did see some of the "will not reconnect on awake" problem, but nothing else.  If your effing network is an effing network, then fix it.

eliasfromnewyork wrote:

 

This issue was persistent in early Lion releases, but had been fixed at later upgrades. Upgrade your machine to 10.7.5, this issue is fixed now.

Not true at all, my early 2008 macbook still has serious issues. Both on 2.4 and 5.0 ghz networks, while using dhcp or static ip's, using opendns/google dns servers, or whatever. I've tried every solution out there and none is working for me. It really ****** me off to no end this isn't fixed after all this time.

Can't confirm.

Happel wrote:

 

eliasfromnewyork wrote:

 

This issue was persistent in early Lion releases, but had been fixed at later upgrades. Upgrade your machine to 10.7.5, this issue is fixed now.

 

Not true at all, my early 2008 macbook still has serious issues. Both on 2.4 and 5.0 ghz networks, while using dhcp or static ip's, using opendns/google dns servers, or whatever. I've tried every solution out there and none is working for me. It really ****** me off to no end this isn't fixed after all this time.

Can you give specifics about what you see happening?  Do your airport "bars" go grey when your network is not working, or do the stay black?  Also, if you are seeing a message in your browser window, can you type the text you see there, into here so that I might be able to understand which type of service is actually failing?

When you try to connect to a web page, does it immediately fail, or does it hang for a bit and then fail?

I changed my router to channel 10 and it worked no problem

@gphonei. I agree with you (no spectrum analyzer etc.); all I meant to say is that my WiFi is not really bad either - no gross misconfiguration, proper channel distribution (no overlap), signal powerful enough etc. Again, all other devices work well enough (no flap).

I know how to use tcpdump but I simply know there are retransmissions on my WiFi as I can see my AP statistics. Drops are not bad enough to be noticeable on a voip call though -- I could stay on VoIP calls for hours without problem before upgrading to ML.

The WiFi is also very stable (no flap) when I have a very clean connection in some part of the house.

It indeed seems that ML is a lot more sensitive to WiFi mishaps and tears down the connection when the retransmission count gets too high ("high" being apparently very relative) or something to that effect.

At this point, it seems some channels are more affected than others (channel 6 in particular) but this is not certain.

I will try to figure the number of retransmissions needed to flap the link but this will take time as I am busy.

I temporarily fixed my problem by swapping channels between AP's to have the "steadier" channels near the place I work.

At this stage however, I would expect Apple to know about the problem and issue a fix. The interface  flaps even under very light load (e.g. simply some call manager packets and periodic upgrade checks) when I sit at the same place I could VoIP from on SL.

Practically, I do not see myself requesting the airport or coffee shop to swap channel around just for me. Can you just picture the situation ? :-)

I also do not even see how AirPlay is going to work better by just disassociating and reconnecting on the same AP and same channel seconds later. If this is not a bug, the design does not make much sense either.

Sorry; I know this is not very quantitative but I switched from Linux to Mac to "just work" and I really do not have much time to troubleshoot these days. I will sit on my workaround until I have time to do better (probably doing an air capture from a 2nd computer).

TotallyFred wrote:

 

@gphonei. I agree with you (no spectrum analyzer etc.); all I meant to say is that my WiFi is not really bad either - no gross misconfiguration, proper channel distribution (no overlap), signal powerful enough etc. Again, all other devices work well enough (no flap).

 

I know how to use tcpdump but I simply know there are retransmissions on my WiFi as I can see my AP statistics. Drops are not bad enough to be noticeable on a voip call though -- I could stay on VoIP calls for hours without problem before upgrading to ML.

 

The WiFi is also very stable (no flap) when I have a very clean connection in some part of the house.

 

It indeed seems that ML is a lot more sensitive to WiFi mishaps and tears down the connection when the retransmission count gets too high ("high" being apparently very relative) or something to that effect.

At this point, it seems some channels are more affected than others (channel 6 in particular) but this is not certain.

 

I will try to figure the number of retransmissions needed to flap the link but this will take time as I am busy.

 

I temporarily fixed my problem by swapping channels between AP's to have the "steadier" channels near the place I work.

 

At this stage however, I would expect Apple to know about the problem and issue a fix. The interface  flaps even under very light load (e.g. simply some call manager packets and periodic upgrade checks) when I sit at the same place I could VoIP from on SL.

 

Practically, I do not see myself requesting the airport or coffee shop to swap channel around just for me. Can you just picture the situation ? :-)

 

I also do not even see how AirPlay is going to work better by just disassociating and reconnecting on the same AP and same channel seconds later. If this is not a bug, the design does not make much sense either.

 

Sorry; I know this is not very quantitative but I switched from Linux to Mac to "just work" and I really do not have much time to troubleshoot these days. I will sit on my workaround until I have time to do better (probably doing an air capture from a 2nd computer).

It really seems to me, that there is less tollerance of particular types of errors, and this is very visible in some places because of the local environment.  All I can do is speculate.  Sounds like you've found something to work for now, but it would be great for Apple to do something, if at all possible, to reduce the drops due to network errors.

Indeed, the drops are not helping anyone have a better experience, let alone make AirPlay more viable.

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. 

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?