Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

So, as a side project I'm going to try and figure out why the wifi APs in my building exhibit the following behavior:
- They typically allow all types of computers to connect without issues
- Sometimes Apples can't get an IP address but will still connect to the AP's signal
- Less often, PCs can't connect to the wifi (same as above - yes signal, no IP addy)
- Don't let Raiders fans on no matter the time of day!

My first thought was that the DHCP leases were all taken up when the Apples would try to connect, and it was just their unlucky timing, but I would then try to log on with a PC that had a new, unleased MAC address and it would work...

Could this be something to do with interoperability between an apple wifi card, and the APs? Different parts of the DHCP lease being taken up first? The fact that the Seattle Mariners might actually be good this year??

If this hasn't used up everyone's patience (with my crappy sports jokes), something else I could use some help with:
- We don't have the model or type of AP -> This is because there is no documentation available for them, and they literally look like small white boxes with no writing on them. Also, the company that installed them is out of business, so the situation might be that no docs will ever be on the way. -- Do you guys have any ideas on how to figure out what we have?

Thanks as always for all the help, and I'm looking forward to the day when I know enough to start contributing back to the site, Josh

share|improve this question
    
I'm curious to know how this has gone for you. Any updates? –  Spiff Mar 26 '10 at 23:52
add comment

2 Answers

A trick to determine the vendor of an unmarked (or physically inaccessible) AP is to learn its BSSID (which is basically the MAC address of the AP's 802.11 wireless NIC). The first half (the first 3 bytes == 6 hex digits) of a typical MAC address in an IEEE OUI (Organizationally Unique Identifier). You can look up the OUI to company mapping on the IEEE website.

An easy way to find the BSSID of any AP you can associate to is to option-click the AirPort menu extra (the AirPort icon menu in the menubar) while associated. You'll see several extra pieces of diagnostic information in grey, including the BSSID. So if the BSSID show up as, say, "0:1f:f3:12:34:56", the OUI is "00:1f:f3". The IEEE lookup on the page linked above doesn't like colons, so either remove them like "001ff3" or replace them with hyphens like "00-1f-f3". Note that Mac OS X often drops the the leading zero in any given byte in a MAC address, so if any byte of the MAC address only has one digit, you'll have to put the leading zero back in before searching for it on the IEEE OUI lookup.

Some times an OUI lookup fails to conclusively identify the manufacturer of an AP. For example, if the 2's place bit of the first byte of the MAC address is set, that's the "local" bit, which means that the MAC address is "locally administered", which means it's not a real guaranteed-globally-unique MAC address, but one that was "made up", perhaps by the network administrator who configured the AP. Other times, the OUI lookup will tell you who made the wireless NIC card of the AP, or who made the chipset on the card, but not who made the AP itself.

If the OUI lookup approach doesn't work for you, take a picture of the AP and post it. Maybe someone here will recognize it. Also, what cables can you see going into the APs? Do you see one or more coax cables but no Ethernet cable? Then the box you're looking at is probably just an external antenna, and the real AP is out of view, perhaps above the drop-ceiling. You could also be looking at some other piece of building infrastructure, like an industrial-style smoke detector, heat detector, a motion sensor for automatic lights, or an antenna for some completely unrelated wireless technology (like an indoor cell signal repeater). Just because your Wi-Fi signal strength is good near that box doesn't mean that box is your actual AP. I learned that lesson the hard way -- I misidentified a mostly-unmarked white antenna enclosure as being the AP in a building because my Wi-Fi signal strength was strong near it, and didn't realize that it was an antenna for an indoor cell signal repeater, and the real AP happened to be hidden above the drop ceiling two meters farther down the hall.

If your APs turn out to be Cisco boxes running in lightweight mode, beware of these Cisco bugs:

CSCsy73154—The access point does not forward the DHCP offer to the client.
...which is sometimes called:
CSCsz22901—The access point does not forward the DHCP offer to the client, so the client fails to get an IP address.

My site was running Cisco APs in lightweight mode (specifically 1252s in B/G/N + A/N HT20 mode, but I don't know that it matters), in conjunction with various models of Cisco Wireless LAN Controllers (WLCs) and Wireless Service Modules (WiSMs).

Even without any security enabled on a certain network, some Mac clients would sometimes fail to get DHCP leases. 802.11 monitor-mode packet traces, in conjunction with wired Ethernet packet traces between the APs and the controllers (showing the unencrypted LWAPP session) showed that the clients were successfully associating and sending their DHCP Discover packets, and the DHCP server was replying with a DHCP Offer, and the WLC/WiSM was forwarding that DHCP Offer to the Cisco AP, but the Cisco AP was never forwarding that DHCP Offer along to the client.

These issues were fixed in the following Cisco WLC/WiSM software releases from the summer of 2009:
4.2.207.0 (not to be confused with 4.2.205.0 which does NOT have the fix)
5.2.193.0
6.0.x.x -- I believe any public 6.x release has the fix.

If your site is running a 5.0.x.x or 5.1.x.x release on your Cisco WLCs/WiSMs, you'll need to evaluate upgrading to 5.2 or 6.0, because I think if Cisco was ever going to fix this for those build series, they would have done so by now.

share|improve this answer
add comment

You can try NetStumbler: it's a wifi sniffer and will likely tell/show you how it's configured and possibly what's going on. I do know that my Macbook running OS X Tiger had a hard time with WPA2 when I had a D-Link wireless router -- I had to switch it to WEP with MAC address filtering just to connect.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.