Using Raspberry Pi Access Point to Track Devices

I’ve been looking recently at ways to measure population movements across a large outdoor area. There are various ways of doing this: we watch them, we ask them, or we infer. Watching is a popular option at stadia, city centres and large events. Automated footfall cameras can track movements and figure out how many people walk past a certain point in any period. Put enough cameras up and you can get a pretty good plan.

However, this merely measures numbers of people. There is no connectivity. 200 people walk past point A, 400 past point B. Does that mean 600 in total at two locations, or did some of those in point A also walk past point B?

This got me thinking about technical solutions (of course) and fairly quickly I got to wireless networks. Back in 2008, I wrote about a scheme in Portsmouth’s Gunwharf Quays to track mobile devices. At the time I think the company was using bluetooth but since then we’ve had an astounding growth in smartphone usage. Wifi is pretty much standard and – I would perhaps wager – more likely to be turned on.

Keen to see how this might be implemented, I did some research into how mobile phones discover wifi networks and found an interesting behaviour. Every few seconds or minutes, your phone will send out a signal “who’s there” to probe local wifi networks. Any active access points will respond accordingly with their network name “Hi I’m BtHub_12345”. This surprised me a little, as the device itself has to ask for wifi – I was expecting the access points to broadcast themselves and send out signals every few seconds. It seems this is to conserve battery.

Anyway, having established this, it seemed likely the device would be giving its MAC address away. To clarify, the MAC address is the hardware-level identifier for network devices. It’s a bit like a serial number, so when two devices talk to each other they address each other by their MAC address so they know who’s who. MAC addresses are supposed to be unique, so no two devices should ever have the same address.

Curious to see how easy this would be, I have started to build a Raspberry Pi device that is capable of this. It seems possible – hostapd allows the Pi to act as a wifi network access point. This forms the basis for tools such as Karma (which achieves a lot more than I need) and clearly has the capability to show probe requests

There are also some privacy issues that need to be tackled. What are the legal aspects of tracking MAC addresses? It seems that, provided the addresses are not tied to individuals, we do not need disclosure. Indeed, my aim is to aggregate data from the start. Once a path has been created, any trackable information should likely be discarded. I’ll touch on these too.

Tracking Devices via Raspberry Pi (Part Two)

In the last post I described how it could be possible to build a simple tracking device using a Raspberry Pi acting as a wireless network access point. In this post, I try it out for real. This isn’t a detailed technical run-down, just the basics.

It seems to get this working you’ll need just a Raspberry Pi (Model B has extra USB + LAN so is easier to configure) and a USB Wireless dongle. I started off with the Nano-USB TP-Link WN725N but this isn’t supported by the default drivers. I managed to get it working thanks tothis thread on the Pi forums, which describes recompiling direct from Realtek’s website.

However, it seems that the Realtek drivers don’t have the necessary hooks for responding to probe requests. My guess is this is usually handled at a lower level and hostapd merely makes use of callbacks to customise the handling of these requests. I didn’t really fancy rewriting large chunks of code to support it, so I opted for Plan B, which is an Edimax 7711USn (the big white thing in the picture).

   The Edimax does seem to work with the default nl80211 drivers and sure enough, when I fired up debug mode, the probe requests came through.

   By default, the probe requests only appear with some really high debug level (makes sense – they’re usually not that useful) and running in this mode would surely generate a whole load of debug messages I wouldn’t need. The second snag is that there is no timestamp with these messages.

   So, next step was to recompile hostapd with some customisations. At this stage, I merely wanted proof-of-concept so I moved the probe request notifications up to INFO level and added a timestamp using some existing functions. I then ran the program for a little while et voila, the requests started coming in. The screenshot below shows the requests being made (MAC address partially obscured) and the timestamp (a second counter).

These requests will be coming from all sorts of wifi-enabled devices: my phone, my laptop, phones of passers-by. The key thing is that I did nothing to these devices to enable this – they automatically scan for wifi networks and this device is merely visualising it.

In little under forty minutes there were 1720 probe requests from sixteen separate devices. I’d call that a proven concept.

All in, the Raspberry Pi setup cost around thirty pounds. This is for a single device. My original plan was to see how this could be used for tracing paths through a space, such as a city or stadium. For this to work, one would need many more devices, both to triangulate the devices and to provide blanket wifi coverage.

The theory is: with enough of these devices in the right place it should be possible with reasonable accuracy to work out where people are, and where they go. At thirty quid* a pop, this needn’t be a hugely expensive task.

As it turns out, this is precisely the sort of work going on both in the commercial and development world:

CreepyDOL is a networked tracking tool – sniffs network traffic and tracks users. As the name suggests, the powers ‘in the wrong hands’ are creepy indeed.

Wifi tracking of the kind I describe has been in use for a couple of years now, and it’s already used to track customers in supermarkets.

Sure enough, just as I was working on my project, The Register published an article about how Asda and EE in the UK are using wifi to achieve precisely this.

There are quite obvious privacy implications to all of this. MAC addresses are unique and, even if we can’t directly identify someone from them, it may be possible to get their identity from all the clues available (such as where they shop, where they dwell, and by sniffing wifi traffic). Privacy is a huge concern and any technique such as this – even if used with the best intentions and no direct logging – must still be dealt with with care. Last year, it was widely reported that wifi trackers were embedded in some of London’s bins. Officials ordered the company to stop amid privacy concerns, and – despite the company’s protestations that all is anonymous – it has clearly hit a nerve with privacy advocates. There may well be no attempt whatsoever to track individuals, but a poorly executed plan will be met with harsh criticism irrespective of the actual risks.

I have a couple more articles planned to follow up these points – any comments are most welcome.

* There are, of course, all kinds of additional costs: You probably want a case, decent power, and public liability insurance. The Raspberry Pi is also not likely to be a great choice in the long run, for reasons which I hope to pick up later.

Source: https://www.yetanotherblog.com/2014/03/25/using-raspberry-pi-access-point-to-track-devices/