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

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.

More updates to come…


In-Car Web Cameras

Today and yesterday I’ve been spending a little bit of time putting together a Raspberry Pi-based webcam for my car. The idea is straightforward enough, I want something recording the road around me just in case – we’re not quite at Russian levels but it’s a precaution I’d prefer to take. It also might come in handy if meteors fall or the sea comes in.

Using motion, a Creative LiveCam and the instructions I found here I set up something which appears to work reasonably well and doesn’t instantly fill up the paltry 4GB card I have in the Raspberry Pi.

For those not yet aware, Raspberry Pis are very cheap computers – of the order of £20 – which can be powered from a phone charger (mains or, in this case, in-car) – which makes them incredibly good for fiddling about on projects like these.

I have the camera capturing at 1280×960 at one frame/second. This seems to give a reasonable balance between quality, sense of motion and processing capability. When the car is stationery and there is no visible activity it does nothing, however if motion is detected in the image the device begins to record both higher quality images and video.


I also have a small wifi dongle in the device, which means I can upload the images automatically when I’m in range of the home wifi, and I can use wifi triangulation to figure out where the car is (poor man’s GPS, basically).

Technical issues so far:

  • Supplying power to the Raspberry Pi is a bit tricky. I’m using the car stereo which has a reasonably clean 5V. The Pi resets when I start the car which isn’t particularly surprising, but I risk corrupting the on-board storage if I do this.
  • The webcam is not really ideal. It’s good for indoor videoconferencing and will return to that job shortly. If I spend a few more quid I should be able to get a better quality image and decent night imagery.

However, technical issues are only one part of this experiment. I’m also trying to consider the social aspects. For one, the webcam is pretty obvious (and glows blue when operating). This is a good deterrent – but might attract undue interest.

I will also be driving in places where photography is usually forbidden – UK customs tend to frown on these things (I don’t particularly think the French care less, they’re so laid back 🙂 )- so I would be well advised to tip the camera away at the cross-channel port.

Finally – and this is the bit that really interests me – there is the data that could be collected. What right do I have to record others’ movements? In public it’s fair game provided I’m not using these for profit but consideration needs to be made particularly on private land and overseas.

However, this kind of capture really fascinates me … imagine for a moment if these devices uploaded to the web – to some kind of central processing house (much like Google Goggles or Waze might aggregate your data to learn or otherwise use it). These images could be used in some form of Google Street View (albeit poor quality!), to build a remarkable timeline of environments’ development, or by law enforcement officers to track cars based on your numberplate (ANPR).

If nothing else, the more cameras there are on the road, the more often we will capture extraordinary events on video. For me though, this continues to be an interesting little technical side-project, hopefully with some positive benefits and some food for thought.

Quick Thinking

I’m currently managing a friend’s WordPress blog while they bugger off on a round-the-world trip. Goodness me they get a lot of spam.

Within a minute or so of turning off Spam Karma (it causes problems with the comment count, apparently) I/he had 15 new comments, all spam. So, without FTP access I quickly put in a hack to the comments page thusly:

<textarea name="quack" id="comments"></textarea>

<script type="text/javascript">

document.getElementById('comments').name = 'comments';

Nice and simple – a bit of Javascript that renames the comments field so it can be submitted correctly (if you fail to run the script, the comment fails). I know there are accessibility issues and all the smartarses who turn off their Javascript are stopped from commenting, but desperate times call for desperate measures. It’s quick & dirty, and for most people (this guy doesn’t get a massive amount of traffic) it works OK.

Anyway, I went to bed last night feeling smug that I’d robbed a load of spammers of their precious links. This morning I took a look: 38 new comments. They’ve already made their way around it.

This suggests one of three things:

  1. The spammers caught the error and changed their behaviour to suit. Doubt it, it’d be easier for them to move onto other blogs.
  2. They execute Javascript (maybe it’s a full-on Firefox session with a plugin script?. Likely, and rather smart!
  3. My code is rubbish and never worked in the first place. Never impossible.

Anyway, kudos to those guys for not being thwarted by a simple script! Now, let’s see what happens when I get Spam Karma re-enabled or I activate Akismet…

Update 22 Sept: Ignore the above. My code is rubbish. If the spammers do a simple POST to the server they will succeed, since I’d never updated the server-side code to match the client. Best bet for this hack would’ve been to rename the field both on the form and in the server code to something unpredictable (‘quack’ is just fine…) and not bother with the Javascript, Spammers would ignorantly continue to assume the field is ‘comments’ and their posts would fail. Thanks Brian and Neil T

A while ago I wrote a blog host service which included a more sophisticated spam filter. It would scramble all the fields client-side, include a couple of hashes and would only accept the comment as-is if all the hashes matched the server’s own records. It stopped blind POSTs and bots that did not use Javascript. It also cleverly spotted genuine users who might not have been able to run the Javascript (since there was a larger platform accessibility was a concern), and used timing information to identify real users (who take their time) versus bots (who tend to write/post immediately or in a regular pattern).

It worked for nearly 2 years without a single automated spam comment getting through (many tens of thousands were stopped; no false positives either). Manual spam got in, but was minimal. Finally the spammers changed their ways and (I guess) began using full browser sessions to post their spam – once they do that you need to start looking at content analysis or other methods.

Hack Attempt

Just noticed an attempt to find unprotected admin/phpMyAdmin interfaces on one of our servers. The script appears to try common URLs (below) for PMA, presumably in the hope that the admin has left it wide open. As ever, keep those doors locked and secured!