Detecting Un-fair Wireless Usage

I had the pleasure this weekend of being one of the judges for my county’s Educational Technology Fair (the winners of which then feed up to the state Educational Tech Fair). Students from across the county bring their creations to the hosting school and get a chance to show off what they’ve created – things like Web 2.0, animated multimedia, 3D computer modelling, robotics, digital photography, programming, and more – the same categories that are used in the Georgia Educational Technology Fair. Different from a Science Fair where the end project is what’s being judged, Tech Fair judges interview the students about the projects and what they learned in the process – which also gives us a chance to understand how deeply the student understands their project.

I have been a judge for the last four years now – it’s exhausting mentally, verbally, and physically, but it’s wonderful to see some of the amazing ideas that children have, and the things they can create. You might not think that kids in grades 3-12 would be capable of writing Python scripts, mastering Photoshop or building complex robotic devices, but I’m amazed every year at how advanced some of the projects are.

I mention this in part because I would encourage anybody who has the opportunity to volunteer as a judge for this kind of event to get involved if you can – the judges at the country level at least tend to be mostly teachers and some (fewer) parents. The children seem to get a lot out of it too, so I would similarly encourage them to participate and get inspired to create a project. The other reason I mention this is to share a little story about one of the projects I saw.

The Project

The project in question was kind of fun – an iRobot Create (which, yes, comes from the same company as the infamous Roomba) with a small form factor PC and associated battery pack mounted on top, then an Xbox Kinect video sensor on top of that. The PC was running Ubuntu, took a feed form the Kinect and sent control signals to the iRobot, so everything was self-contained on this little moving unit. So far, so good.

In order to make the iRobot perform the chosen tasks, it’s necessary to gain access to the mini-PC on the robot and enter commands to execute the scripts that actually make it do something (reading from the camera, moving the robot, and so forth). To do this, the mini-PC had a wireless card and was acting as an AP. The student brought with him a laptop with a wireless card, and that laptop was configured to associate to the mini-PC’s wireless network so that he could then ssh over to the mini PC remotely and start typing commands.

The only problem is, when they set it up in the judging room, it simply didn’t work. At first, they thought maybe it was a channel conflict with the school’s wireless, but the laptop was so close to the mini-PC you’d think it should have been able to drown out any other signals anyway.

Problem Solved

After consulting with the Fair organizers, the solution finally came to light – the school’s WiFi was also equipped with a WIPS (Wireless Intrustion Protection System) which was identifying the mini-PC’s AP as a rogue, and was taking counter-measures against it, successfully making it unusable. The solution? I was at the point of suggesting that since everything was battery powered, we took the project up to the recreation area and tried it there, away from the school’s WiFi. To our relief (since it was cold out) we didn’t have to do that; after some digging, somebody managed to find a crossover cable, and handily both the mini-PC and the laptop had an Ethernet port that they could use to directly connect the laptop to the mini-PC. This wasn’t ideal, as now the robot couldn’t move beyond the length of the Ethernet cable – but at least the student was able to demonstrate the project.

Wait, A Rogue Wireless AP?

The question I had after this was explained to me was, “Wait – why was this considered to be a rogue AP?” The mini-PC wasn’t bridging to the school’s wired network, and it wasn’t using the same SSID as the school’s own WiFi, so wasn’t going to steal any clients. So why was this determined by the WIPS to be worthy of countermeasures? Maybe the signal was so strong (much stronger than a ‘neighbor’ AP signal would be) it was determined to be a rogue regardless of how it was being used. I doubt I’ll ever find out.

Still, it’s good to see that WIPS can actually work, but it does reinforce the necessity of ensuring that the policies configured for automatic countermeasure deployment are actually what you wanted.Hopefully it won’t be a problem for anybody next year. We were lucky this time that somebody found a cable, and that the student was using a laptop with a network port (something a MacBook Air, for example, would have been lacking).

Maybe the lesson here is to have a backup plan where WiFi is concerned? And maybe we just found something that could be put in the notes as a warning for next year’s entrants, because I’m sure we’ll be seeing more use of wireless connections as the range of robotic projects expands each year.

Despite all these setbacks – including the stress of missing the original judging slot, having to troubleshoot a failing project, and having to install a workaround, the student – who was in 5th or 6th grade – still did a great job executing his demo and explaining the project to us, apparently unfazed.

Seriously, these children are amazing.