Packetbridge / Packetbrücke

INTRODUCTION

Packetbridge (Packetbrücke) explores simulating entire network situations by transferring electromagnetic infrastructure to a different physical space. The result is a revealing 'confusion' of devices and services reliant on this infrastructure.

Wireless network packets are directly captured from a specific location and tunneled through the Internet to a remote location, where they are released back into the air. In doing so, Packetbridge literally injects one electromagnetic representation of geographical space into another, effectively producing a new imaginary topography and, through this remediation, an “impossible reality”.

Packetbridge demonstrates that positioning systems based on WLAN are a site for intervention, expressing at the same moment they are vulnerable to location spoofing attacks. This effect is especially interesting, considering that we increasingly rely on an ever-growing number of wireless devices for localization, navigation and time-synchronization.

Since almost all networked devices within buildings rely on surrounding WIFI networks to determine their physical location, Packetbridge demonstrates their vulnerability to location spoofing attacks.

Formally speaking, the device resembles a sort of performance wherein the spectacle lies in its hidden architectural manifestation. Paradoxically, its manifestation through a sculpture (comprised of an excessive use of ethernet cables) emphasizes its topological dependence on the wired network topology.

PROCESS

The installation captures WIFI accesspoint beacon frames which are usually sent out by WIFI access points in regular intervals (between 50-250ms). Within these frames there is an ample of metainformation, such as the WIFI network name, its unique MAC address, its current channel (between 1-14), signal strengths, etc.

Packetbridge records these frames across 14 wireless access points running custom firmware (OpenWrt) and UNIX programs. We need 14 access points to represent each wireless frequency channel, which of there are 14 allowed worldwide. Further, the captured data is streamed to an external server which we simply call an "Internet packet relay". On the other end, we use again 14 wireless routers to inject the distant beacon frames into the real physical space; mirroring the electromagnetic landscape from abroad.

The fact that beacon frames are constantly being sent and replayed is visually emphasized trough blue EL-wires wrapped around the Ethernet cables. The wires are being lit up each time a packet is transmitted over the associated cable thus visualizing network traffic and beacon-actvity, and thereby injection/invasion per channel.

We intend to simplify the installation and to put the entire wifi "logic" into a small battery-powered handheld device.

The project has been relocating packets at several occassions in Berlin, Seoul and Ljubljana between 2012 and 2015.

During the Transmediale festival in 2012 we launched the project with an uni-directional installation. Packets were captured in our studio in Neukoelln and being "replayed" in Haus der Kulturen der Welt. Visitors using Google Maps or other location-aware services got immediately redirected to the area around our studio in Neukoelln 8km away from their current physical position.

For the occassion of the Media Biennale we installed Packetbridge in Seoul (South Korea) at two different spots in the city. Fortunately, we had time to work on improving the recording and playback scripts. We managed to setup a bi-directional packet exchange; meaning that packets from one location got sent to the other one and vica-versa. Even though, there were a gazillion of WIFI accesspoints inside of the museum, the geo-relocation was working. The system got obviously so confused that if you were looking onto your map, you were being teleported between the two locations.

For a solo-show in the Aksioma Gallery we tried to cycle beacon frames from several recordings. One part of Packetbridge was hosted in Ljudmila, sending beacon frames back to Aksioma gallery. There, in front of the gallery holding a normal Android smartphone, we could see WIFI networks constantly changing from the ones in Seoul and the ones in Ljudmila. The marker on Google maps was literally flying between the two cities.

The diagram shows the skeleton of a beacon frame. Each packet is composed by a MAC header, a mandatory field and optional fields that are sent only when there is a reason to do so.

Our first experiments were conducted using wireshark and pycap. Here a screenshot of a beacon frame in wireshark:

Here's the source for our modified hexinject-min.tar.gz. Download, untar and run make to compile. Make sure you have libpcap and headers installed.
Here's the compiled file for our modified hexinject (Thanks to Danja Vasiliev).
Here's the python script for running the relay between 2 locations packetbruecke-relay.py.
Here's the shell script for outputting a file line by line repeatedly and more slowly so that we don't flood the network interface: slowcat
Here's the shell script for recording live data from devices in a location feeding a relay: record.sh.

Recording from Digital Media City, Seoul: DMC.tar.gz (452Kb)
Recording from Seoul Museum of Art, Seoul: SMA.tar.gz (576Kb)
Recording from Ljudmila, Ljubljana: Ljudmila.tar.gz (387Kb)

You need two devices in two different locations. One that will capture and one that will inject. For both of them we can set up a monitor interface to use and select channel this way (selecting channel 1 in this case and assuming you want to use the first phy/radio):

You also need a device to relay through which may be one of the above devices if it has a public IP and is not firewalled. Start the relay with:

If you just want to try to playback a recording you still need to setup monitor mode as above and then you can download one of the tar-files with recordings above, untar them and then replay one of the files with the following command(sending recording from channel 1 at 2412 MHz from Digital Media City):

If you want to create your own recordings you can use the record.sh script above. You need to set up monitor mode as described above first. You need to run a packetbruecke-relay.py and you need to have hexinject instances running on capturing devices as decribed above for each channel you want to record, ie piping to netcat that feeds to the relay. With overlapping channels you should probably get descent coverage capturing on channel 3, 7 and 11. On the same machine as you are running the relay (just because it connects to localhost) you can then run: