The FCC's Equipment Authorization Search is Captivating (If You're Into That Sort Of Thing)

Being an amateur radio operator and paperwork originator for a few licensed point-to-point network links, I occasionally find myself in the FCC's Universal Licensing System (ULS). Trolling around in the ULS can be kinda fun (when you're really, really bored) if you want to get information on different kinds of valid and expired licenses for everything from public safety to TV stations to IT-related transmitters.

For those of us in the Wi-Fi world, there is another FCC resource that holds a treasure trove of information on every piece of gear ever certified for use in the US. The EAS (Equipment Authorization Search) is your gateway to RF testing reports, internal and external photos of a particular access point, wireless router, etc, and basically the whole "how it came to be" story for each device.

An example- the BlueSocket model 1800v2  access point.

1. Go to the EAS front door.

2. In "Applicant Name" field, enter BlueSocket. (I've not had much luck with any of the other fields, even when I have the absolute specific information that should go in them.) You may want to adjust the "show ___ records at a time" field from the default of 10, to something like 50 or 100.

3. Click "Start Search" at bottom of page.

4. You'll be presented with a table of fairly obvious values- some will be one page, and some will span dozens of pages depending on manufacturer. For BlueSocket, there are only 32 entries and finding my 1800v2 in FCC ID column is pretty easy.

NOTE- Each piece of equipment has Summary or Detail available. Being geeky, we want Detail, as that is where the good stuff is. If multiple entries for same device, pick most current date.

5. You'll be rewarded with a table of contents like this:

OET Exhibits List

14 Matches found for FCC ID TIH-BSAP1800V2

	View Attachment	Exhibit Type	Date Submitted to FCC	Display Type	Date Available
	Ad Hoc letter	Cover Letter(s)	03/17/2010	pdf	03/17/2010
	Request for Confidentiality	Cover Letter(s)	03/17/2010	pdf	03/17/2010
	PoA	Cover Letter(s)	03/17/2010	pdf	03/17/2010
	External Photos	External Photos	03/17/2010	pdf	03/17/2010
	Label Location Info	ID Label/Location Info	03/17/2010	pdf	03/17/2010
	Internal Photos	Internal Photos	03/17/2010	pdf	03/17/2010
	Monopole MPE 11an	RF Exposure Info	03/17/2010	pdf	03/17/2010
	MPE PIFA 11an	RF Exposure Info	03/17/2010	pdf	03/17/2010
	Monopole Test Report	Test Report	03/17/2010	pdf	03/17/2010
	Monopole Test Report 11an	Test Report	03/17/2010	pdf	03/17/2010
	PIFA Test Report	Test Report	03/17/2010	pdf	03/17/2010
	Monopole Test Setup Photos	Test Setup Photos	03/17/2010	pdf	03/17/2010
	PIFA TEst Setup Photos	Test Setup Photos	03/17/2010	pdf	03/17/2010
	USer Manual	Users Manual	03/17/2010	pdf	03/17/2010

And from there, you can see more than you ever imagined you could care about a wireless device. The Internal Photos and Test Setup Photos tend to be the most interesting, at least to me. Enjoy!

When Good Wireless Feels Bad

If my client device doesn't connect to your WLAN, your network must have a problem.

My iPad keeps getting dropped by your network.

I keep losing my Internet, your network sucks.

Ever hear anything along these lines? Sure, sometimes wireless networks do have problems. Access points crap out. Controllers fail. A switch glitches, and PoE isn't sent to an AP. But on enterprise-grade hardware running proper code, these sorts of issues should be the exception. At the same time, even when "the problem" lives on the client device itself, it still feels like a network issue to the user.


With a daily load on my own WLAN that peaks around 16K, I see every kind of client device under the sun. Thankfully, we have a generally very healthy environment despite the relative complexity that comes with supporting any and every device type in a multi-SSID/security type environment. But trouble does hit the individual user on occasion; hence the purpose of this blog.

Even when the WLAN is running perfectly at each cell and all the way through the network's important parts (DHCP, DNS, RADIUS, credential store, routing, etc), these are among the many factors can still make the wireless network "feel" crappy to individual clients:

• OS upgrade causes trouble in wireless adapter


• Wireless driver dated, needs update


• Windows wireless driver not best fit for client, need Intel/Broadcom latest version


• IPv6 getting in the way of IPv4


• Client "sticks" to APs that common sense says it shouldn't


• On dual-mode devices (cellular data and Wi-Fi), each side of device occasionally causes trouble for the other


• Client device requires legacy data rates not supported by WLAN


• Client supplicant for 802.1x network gets corrupted, mis-configured


• Local interference (usually in 2.4 GHz) causes issues


• Client device clings to weak/poor 5 GHz connection when solid 2.4 GHz available


• Client device has static IP address set from previous network use


• User changes network password but doesn't update supplicant config


• Too small of an Internet pipe for user load


• Trouble on the Internet, out in ISP land, impacting specific destinations


• Client device is laden with malware that gets in the way of Internet access

You get the picture... there are many conditions that can impact the individual client, or a specific group of like client devices, and what worked yesterday may have been changed today by an OS update or patch.

Thankfully, when critical network building blocks do fail, we can either rely on our good instrumentation (you have that, right?) to tell us we lost a switch, or controller, or AP, etc. Or we can correlate based on good trouble report gathering (always happens, yes?) that there is something similar among users having issues- maybe a common AD grouping that RADIUS services are  borking on or the like. Good logs help, too.

Regardless of what is causing the pain, many clients instantly blame the network. Some can't fathom that their shiny, expensive device could be imperfect in any way or that the mothership would ever send them a patch that wasn't properly QA'd. It can be frustrating, but is also just part of the wireless support experience.

Things get easier if you have the rare environment where client types are tightly controlled and the BYOD water has yet to spill over the dam. For the rest of us, being aware of not only the health of the network but also of the various ills that can hit the client end of wireless (and what to do and how to communicate about them) is an absolute must. 

At the recent Wireless Field Day 4, I discussed this topic with my fellow delegates in a conference room in Building 4 of the Cisco Campus in San Jose.

Here's a bit more on specific frustrations with the WLAN, from factors that are largely out of the admin's hands.