Entry tags:
I Sing the Wireless Notwork
Among the other causes of argh in the last two weeks has been the state of the campus wireless. The original[1] issue was fairly simple: the DHCP server kept falling over at the start of the term, apparently because it was bombarded by requests from all the Blackberries, Treos, iPhones, and God-knows-what that showed up with the returning student population.
So the stooges who someone has laughingly dubbed our networks group decided that the thing to do was to shut off 802.11a. Laptops, said they, would use b/g instead, and the mobile devices (which we don't guarantee will be okay on our network) will stop bugging our DHCP server constantly. OK, fine; I don't know enough to judge, but it seems reasonable.
Except that now, MacBooks won't connect. At all. The console on mine reports "-14 Access point full". They don't appear to have disabled a, so much as told it to report to any inquirers "sorry, we're full". Interestingly, my iMac will connect just fine. All PCs are okay. Booting my MacBook into XP gets an IP address from DHCP, at least, but I never get the authentication window. Myself and![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
spride and The Really Smart Support Tech and the Larval Hacker-Boy have spent a stupid amount of time working on this and defining the shape of it, because the Notwork Stooges first tried to claim that my laptop's hardware must be flakey, and then saying that "Apple must be broken so you should open a ticket with them". Yes. All MacBooks, everywhere, running 10.4.11 or 10.5.3 or 10.5.4 are flakey because they work fine anyplace but at Hunter. BRILLIANT
Anyways, we have a theory that what's happening is this:
1. A Mac connects to the wireless. It tries 802.11a.
2. Access point says "me so sorry, a is full"
3. If the Mac has an Broadcom wireless chipset, it says "okay, how about b/g?" and works.
4. If the Mac has an Atheros chipset, which most MacBooks do, it says "oooer, that's too bad" and doesn't roll over, apparently thinking that why would anyone have a AND b/g?.
But we can't find out for sure, because we can't look at the AP equipment or documentation or logs, and the Notwork Stooges don't want to do any work. (Whether the MacBook behavior described in step 4 is a bug, a feature, or a stupid misfeature is outside the scope of my current study.)
Fed up with this, I finally took it to The Bosses this morning, and a strong semi-public beatdown has been applied, so hopefully they will get up and fucking do their jobs instead of making four others do it for them.
[1] By "original", I mean "this iteration". There have been other delicious banquets of wireless Fail over the past month.
So the stooges who someone has laughingly dubbed our networks group decided that the thing to do was to shut off 802.11a. Laptops, said they, would use b/g instead, and the mobile devices (which we don't guarantee will be okay on our network) will stop bugging our DHCP server constantly. OK, fine; I don't know enough to judge, but it seems reasonable.
Except that now, MacBooks won't connect. At all. The console on mine reports "-14 Access point full". They don't appear to have disabled a, so much as told it to report to any inquirers "sorry, we're full". Interestingly, my iMac will connect just fine. All PCs are okay. Booting my MacBook into XP gets an IP address from DHCP, at least, but I never get the authentication window. Myself and
spride and The Really Smart Support Tech and the Larval Hacker-Boy have spent a stupid amount of time working on this and defining the shape of it, because the Notwork Stooges first tried to claim that my laptop's hardware must be flakey, and then saying that "Apple must be broken so you should open a ticket with them". Yes. All MacBooks, everywhere, running 10.4.11 or 10.5.3 or 10.5.4 are flakey because they work fine anyplace but at Hunter. BRILLIANTAnyways, we have a theory that what's happening is this:
1. A Mac connects to the wireless. It tries 802.11a.
2. Access point says "me so sorry, a is full"
3. If the Mac has an Broadcom wireless chipset, it says "okay, how about b/g?" and works.
4. If the Mac has an Atheros chipset, which most MacBooks do, it says "oooer, that's too bad" and doesn't roll over, apparently thinking that why would anyone have a AND b/g?.
But we can't find out for sure, because we can't look at the AP equipment or documentation or logs, and the Notwork Stooges don't want to do any work. (Whether the MacBook behavior described in step 4 is a bug, a feature, or a stupid misfeature is outside the scope of my current study.)
Fed up with this, I finally took it to The Bosses this morning, and a strong semi-public beatdown has been applied, so hopefully they will get up and fucking do their jobs instead of making four others do it for them.
[1] By "original", I mean "this iteration". There have been other delicious banquets of wireless Fail over the past month.