frequent transitions for interface en1 - network traffic reduction measures

jroe wrote:
I would say the opposite is true . . . if all computers are working fine and a mac joins the network and the router crashes the mac is doing something it shouldn't be . . . . especially when it's only leopard macs causing the issue

That is completely incorrect.

There is nothing any client should be able to do to crash a router. If it does, it indicates a firmware issue in the router (and is then a vector for a denial of service attack on that particular brand and firmware revision of router.)

Many router manufacturers just test their hardware with Windows (and even worse, often only with their own Windows drivers), leaving firmware bug time bombs lying around for other operating systems to trip over.

"It works with Windows" or "It works with Tiger" can never be used as a definitive troubleshooting tool to assign blame.

I beg to differ - there are numerous things I can do with a Linux box and a wireless card to crash a router - why should a bad driver or software not be able to do the same??

That aside this is not a router issue . . . . In my case I have now run into this on 3 distinctly different peices of equipment - Other wireless clients continue to function fine but my leopard laptops cycles through connections over and over . . .

jroe wrote:
I beg to differ - there are numerous things I can do with a Linux box and a wireless card to crash a router - why should a bad driver or software not be able to do the same??

Right - but each of those crashes indicates your router has a *firmware bug*.

Nothing you should be able to do with your computer should be able to crash the router - that's the difference.

That aside this is not a router issue . . . . In my case I have now run into this on 3 distinctly different peices of equipment - Other wireless clients continue to function fine but my leopard laptops cycles through connections over and over . . .

That doesn't necessarily mean it's not a router issue; for example if they were all using the open source DD-WRT firmware, that firmware currently runs on multiple brands of routers, so a bug in it could affect multiple pieces of equipment.

I'm not trying to exonerate Apple, just point out that your problems are not definitive proof of a driver bug.

Alas, the only way we definitively do know something is a driver bug is when Apple fixes it. 😟

I understand you point - More information - since my last post I have rebuilt my system and the issues reoccur - the problem also happens on several different AP's including Apple Airport. It effects only my machine and not others on the network. It seems to be directly tied to Vmware fusion in my case - if I shut down vmware it seems to remedy the issue - upon reinstall it started reoccuring once vmware was reinstalled - Can anyone confirm whether this is the case on their end as well?

As the site is gone, here's the post on turning off the mDNSResponder - don't know if it actually helpls
By Ali Karbassi | November 6th, 2007 | How To, OS X

I recently upgrades to Leopard and the operating system has been great. After installing my core set of programs, I noticed that mDNSResponder was going nuts. Being that I am on an university network, there are hundreds on the current sub-network. By default, Leopard has a “feature” that lists all the local computers (windows or mac) that it finds. This is called Bonjour. You may know about this via iChat, or other programs. Sure, that’s nice, but does it take up lots processes. Again, this would be nice upon request, but the task is done repeatedly. The load on your system just gets out of hand.

After some research, I found that there is a Launch Daemon for this. Here’s how you turn it off, but don’t worry, you can turn it back on anytime, without restarts or anything.

Load up Terminal (Applications > Utilities > Terminal.app) and type the following.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

To turn it back on, just do the opposite:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

You can add my name to the list of affected users too. I'd already tried moving from DHCP to a static address before reading this thread. It improved things but hasn't eliminated the problem.

As suggest I've reported this to apple.com/feedback. I would suggest you all do the same. If you do, then please do two things:

1) Mention this thread, and cut and paste the URL into the feedback.
2) Cut and paste a sample of the error text written to system.log. Try and keep it down to 20 lines or so.

Good luck. Hope apple pick this one up as it's very visible.

This evening, a friend attempting to connect to my wifi N network (Freebox) with a mac book pro (OS 10.5.5) had the problem of losing connection (or no connection at all), and the "frequent transitions for interface en1..." log message. But no problem on my mac book pro.

We copied manually (by terminal) my IO80211Family.kext extension to his mac (in /System/Library/Extensions directory), and the connection became ok.

By "diff"-ing the two version, mine was 2.1.4 and his was 2.1.2

The version 2.1.4 is in the update "AirportExtremeUp 2008-004.dmg" (available on Apple download area since october the 29th).
http://support.apple.com/downloads/AirPortExtreme_Update_2008004

I suppose you should do this update (if you have not already done the update)

Note that AirPort Extreme Update 2008-004 updates several files besides just the IO80211Family.kext extension, so if your friend has not he should run the update itself.

I have a brand new MacBook Pro, with Leopard 10.5.6 on it - as of today - the up to date software.

I'm facing the same, and even more WiFi related troubles. These are not just troubles that may occure sometimes-- more precisely, WLAN just wont work almost always!

I have a ton of WiFi related messages (in addition to this), which can be viewed in the log (Console App -> All Messages). These messages indicate, that something is really bad.

The overall behavior of AirPort is strange. Just an example, which does in no way describe the whole issue: If I try to join a network with the correct password I may get an authentication error on the router side, and if try to join with a wrong password Preferences.App pretends that the access was successful- but I didn't get an IP address and are hence unable to connect to the Internet.

Since I suspect an issue in the KeyChain as well and for making things more investigable, I deleted the corresponding KeyChain entry, just to be sure, KeyChain will not provide a password.



Almost all attempts to join (with correct setting) will fail (about 90%). It looks like, on the client side, the connection attempts are timed out early (8 secs) while on the router these connection attempts are still active. On the router side these attempts time out later -- even if there was a connection established in the meantime with the same MAC address. It seems, the handshaking to establish a connection does not conform to the protocol.
1/11/09 1:40:44 PM SystemUIServer[99] Error joining <SSID>: Connection timeout (-6 timeout connecting)


I can get only a connection If the Mc Book Pro is close (2 Meters) to the WLAN router. Once a connection is established, I can move farther away.

A connection attempt typical produces this log:
1/11/09 1:53:56 PM kernel directed SSID scan fail
1/11/09 1:54:01 PM airportd[414] Error: Apple80211Associate() failed -6
1/11/09 1:54:01 PM System Preferences[302] Error: airportd MIG failed = -6 ((null)) (port = 22347)
1/11/09 1:54:01 PM airportd[414] Error: process commanddict() failed
1/11/09 1:54:01 PM System Preferences[302] Error joining <SSID>: Connection timeout (-6 timeout connecting)
1/11/09 1:54:07 PM kernel Auth result for: 00:1f:3f:12:c8:17 MAC AUTH succeeded
1/11/09 1:54:07 PM kernel Auth result for: 00:1f:3f:12:c8:17 Unsolicited Auth
1/11/09 1:54:07 PM kernel AirPort: Link Up on en1
1/11/09 1:54:12 PM kernel AirPort: Roam (DeAuth/DisAssoc)
1/11/09 1:54:21 PM System Preferences[302] Error: Apple80211Scan() error -6
1/11/09 1:54:21 PM System Preferences[302] Error: __performScan() failed (-6)



If a link is up, the initial bandwidth may be very poor, about 2k Bytes per sec.

If a link is up, the bandwidth may drop drastically from anywhere to <1000 Bytes per sec.

If a link is up, the connection may be closed sporadically. In this case a message may appear in the log:
1/11/09 2:30:28 PM kernel AirPort: No beacon for too long time
1/11/09 2:30:28 PM kernel AirPort: Link Down on en1

The scanning for networks is not reliable, there are many scan errors in the log.
1/11/09 2:31:53 PM SystemUIServer[104] Error: Apple80211Scan() error 6
1/11/09 2:31:53 PM SystemUIServer[104] Error: __performScan() failed (6)
1/11/09 2:31:53 PM SystemUIServer[104] Error: __performScan() failed (6)
1/11/09 2:31:58 PM SystemUIServer[104] Error: Apple80211Scan() error 6

1/11/09 2:31:58 PM SystemUIServer[104] Error: __performScan() failed (6)

The WLAN router is from AVM, which is usually working great. The settings are OK - both in the Router and in Preferences, and I already tried variations of them with no success (changing authentication and security mode, changing from 802.11g, to 802.11.g+b, etc.).


To say it politely, I am very disappointed due this issue - and never had such a nasty problem with an Apple device. I expect a fix.

Message was edited by: agonmac

Message was edited by: agonmac

The missed beacon messages almost always means either reception difficulties or interference in your area from other routers or other devices using the same frequency range as Wi-Fi.

I changed the channel on my router from Auto (which went to 1) to channel 11 and everything seems to be fine. This is after banging on all the other settings/hints in this post for hours.

I am seeing this in my logs with a dLink EBR 2310 wired router. It doesn't always coincide with a dropped connection.
The same messages occurred with a Linksys BEFSR41 wired router that the dLink replaced after it would lose its connection whenever a Youtube video played. I tried adjusting the MTU but nothing fixed it except rebooting the router.
The dLink was good for about a week, then started dropping the connection with no provocation. When this happens, Network Diagnostics shows red for Internet and Server but the router's interface doesn't show a dropped connection. In this case only restarting the modem is the only fix. Restarting the router doesn't do it.

I just wanted to say that I'm on OS-X 10.5.6 Leopard and I am having this exact problem and I've had it for a long time. I just stumbled upon this forum and read through this post and tried turning off IPv6 on all interfaces since I don't use it, and it appears to have fixed this problem for now, but I have only tested for a day.

If anyone else reads this though... these problems have occured for me on many computers, but they have only started occuring when I install a combination of software. The three software(s) I have installed and running when this condition occurs is ViscosityVPN (openvpn for osx), Vmware Fusion, and Little Snitch.

Obviously all three of these do significant things in regards to networking so it's very suspect that maybe it's not one of them, but a combination of them because only when I get all three of these installed do I see to exhibit these symptoms.

Any of you guys who posted here before, or in the future using either of these three programs also and have this problem? Maybe we can narrow this down to a possible fault in one of these pieces of software.

Cheers

Little Snitch has been reported numerous times as causing network problems on the Mac.