The Critical Engineering Working Group Bengt Sjölen
Gordan Savicic

Packetbridge / Packetbrücke (2012-2015)

Wireless geographical network intervention


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.


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.

The wireless signal is captured and replied throughout all the 14 frequency ranges designated in the 2.4 GHz range. (including the 14th frequency which is only allowed in Japan):

802.11b Channel 1 2412MHz 802.11b Channel 2 2417Mhz 802.11b Channel 3 2422Mhz 802.11b Channel 4 2427Mhz 802.11b Channel 5 2432Mhz 802.11b Channel 6 2437Mhz 802.11b Channel 7 2442Mhz 802.11b Channel 8 2447Mhz 802.11b Channel 9 2452Mhz 802.11b Channel 10 2457Mhz 802.11b Channel 11 2462Mhz 802.11b Channel 12 2467Mhz 802.11b Channel 13 2472Mhz 802.11b Channel 14 2484Mhz (Japan only)

PHASE I (uni-directional): Haus der Kulturen Berlin - Weise7 Neukoelln

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.

PHASE II (bi-directional): SEMA Seoul Museum of Art - Digital Media City

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.

PHASE III (bi-directional intercontinental): Ljubljana - Seoul - Ljubljana

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
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:


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):

iw phy0 interface add mon0 type monitor
iw mon0 set channel 1
ifconfig mon0 up
Please note that the above commands, as well as all hexinject invocations below, need to be run as root or using sudo.

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:

The relay will now, for each 2.4GHz wifi channel frequency, run a relay port at the frequency in MHz + 1 so there will be relays on port 2413, 2418, 2423 etc up until 2473 and then finally 2485. If your device is not set to Japanese region however it will refuse to use the last one, channel number 14.

On the capturing device, where $SERVER and $PORT is the ip-number or name and port on the relay, run:
./hexinject -s -f "type mgt subtype beacon" -l 386 -i mon0 | netcat -v $SERVER $PORT
On the injecting device run the following, with same $SERVER and $PORT as above:
netcat -v $SERVER $PORT | ./hexinject -l 386 -p -C -i mon0
At the location of the injecting device you should now be able to see live network beacons from the remote location and in a sufficiently beacon-sparse environment - where the remote location provides more beacons than the local - you should be able trick wifi geolocation services that you are in the remote location.


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):

./slowcat DMC-2412 0|./hexinject -l 386 -p -C -i mon0
The 0 here means sleep 0 seconds between lines, but that still slows down enough. If you want to playback recordings for all channels on the same channel you could for example just cat them together and shuffle the order to mix them with shuf or sort -R:
cat DMC-*|shuf > DMC-allchannels
and then playback DMC-allchannels instead.


If you want to create your own recordings you can use the script above. You need to set up monitor mode as described above first. You need to run a 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:

where $DURATION is the number of seconds you want the recording to last and $NAME is the name of the recording. will then record from the relay to 14 different files named e.g. $NAME-2413 which you can then use for playback as described above.
(If you do create your own recordings we'd be happy if you choose to share them with us!)




Video documentation (2012)

Packetbridge / Packetbrücke (2012-2015) from CriticalEngineering on Vimeo.


We had a lot of discussions with our studio members Julian Oliver and Danja Vasiliev. Our investigation and experiments started in 2011 during Transmediale where we exchanged beacon frames between Sao Paulo and Berlin. Thanks to and Codedcultures for hosting a workshop in Weise7 and props to Leo Peschta and Selena Savic who helped us with the design and production of the 3d-printed cases. (3d-printing in 2011 wasn't as reliable as it is today).

10 September 2012,