I Sing the Wireless Notwork

[serinde]

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 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.

Comments

[xlerb.livejournal.com]

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.

Uh, what? The choice of link layer shouldn't make one bit of difference to DHCP; and if they think there are mobile devices that support 802.11a *only* (and would thus be left out in the cold), that'd be news to me.

That some college/university IT departments are, uh, sufficiently lacking in clue as to pull the stunts described above is, ahem, *not* news to me. (Not the current lot (either level of them), so much, but the ones before that.)

[spride.livejournal.com]

That indeed is their contention. They assert Blackberries only try A, and on seeing no A, go into a huff and capitulate. Said assertion runs:

1. Influx of Blackberries all sending DHCP_DISCOVER on 802.11a


2. Wireless system's own DHCP server work queue fills up


3. Wireless system DHCP daemon crashes. Woe.


4. Notworks asserts Blackberry does not use b or g. Shut off a and you remove the source of the problem


5. Notworks also changes from vendor's DHCP daemon to Windows 2003 DHCP server


6. Notworks calls vendor and has them remote in and 'disable' a


7. Large numbers of Macs fail to associate


8. I tell them to put A back on. As soon as they do, my MacBook Pro can once again associate, get address, authenticate, Profit!


9. While my back was turned Notworks has turned off A again, it seems

So that's the first pile of WTF on my plate tomorrow. Off sick today.

[syringavulgaris.livejournal.com]

Late breaking news: they have obeyed the decree of King Log, and have fixed the shit. All our lapdogs are connecting now. (Hacker-Boy noticed that the "a" light on the APs was blinking before, and isn't now. Isn't that coincidental.)

Don't know about Tiger, haven't had a delivery from the library yet.

[arkham1010.livejournal.com]

wouldnt it have been easier to fix the shit in the first place?

[syringavulgaris.livejournal.com]

FUNNY YOU SHOULD MENTION.

[xlerb.livejournal.com]

Notworks asserts Blackberry does not use b or g.

The BlackBerry web site disagrees with them (http://na.blackberry.com/eng/ataglance/networks/#tab_tab_wifirequirements), as it happens.

[simonb.livejournal.com]

You could try giving iStumbler (http://www.istumbler.net/) a go - people have reported some luck with using that. There also appear to be a number of 3rd party drivers around which can be installed to give the option of disabling 802.11a.

[spride.livejournal.com]

Is that you, Mr Banton?

[jayeye.livejournal.com]

Whoever said that crackberries only do 802.11a (the 5GHz band) is taking controlled substances. In any case, the physical layer has nothing to do with your DHCP server, unless for some odd reason your access points are what's commonly called "wireless routers" (maybe they found them cheap on ebay) and they are letting *those* handle dhcp requests.

[syringavulgaris.livejournal.com]

These guys are as dumb as a bag of assholes. And they seem to have no interest in understanding the technologies they are meant to be administering.

At some point I may recount the tale of How the Chief Stooge Claimed That We Block All File Sharing, So All Of Those DMCA Notices Must Be Bogus.

[xlerb.livejournal.com]

...wow. Yeah, I got nothing on that.