evading the wifi router ban

Wifi router ban

I currently live in student family housing at the University of California, Berkeley. Several years ago, Berkeley IT announced a new policy for wifi routers:

Effective July 1, 2024, use of personal routers will no longer be permitted at UVA [student family housing], as is the case in all other campus housing. Residents who continue to use a personal router after this date may be notified to shut off the wireless broadcast or risk having the router blocked from usage on the campus network.

In other words, Berkeley IT is banning wifi routers.¹

The motivation for this policy is interesting. There was a community meeting last year where someone from the student helpdesk told us personal routers had created a “dog-eat-dog world” of radio interference that could be solved only if everyone switched to campus managed wifi (eduroam).

I believe this is probably true in the undergraduate dorms, but I’m skeptical it affects family housing. Our unit is a two-story condo, much larger than a dorm room, and in the five years we’ve lived here I’ve seen zero evidence of radio interference from our neighbors. The access points all choose different radio channels, and everything works fine.

It’s sad because there are some things you can do with a personal wifi router that simply aren’t possible on campus managed wifi. Think about devices that discover each other over the LAN² (printers, Sonos, Roomba, etc.), mDNS, DHCP reservations, or local ad-blocking DNS like Pi-hole.³ And, at least in our apartment, we’ve found eduroam to be much less reliable than the Netgear R7000P I bought in 2018.

The challenge

A few neighbors asked me how Berkeley IT could enforce this ban. What if, hypothetically, someone decided to use a personal wifi router anyway? How would anyone ever know?

So here’s the challenge I set myself: configure a wifi router to evade detection by the campus IT department. The wifi router doesn’t need to be completely hidden (after all, it’s emitting radio waves that anyone nearby can receive), but it should at least avoid detection from an adversary that probably isn’t trying very hard.

Really, I wanted an excuse to play with OpenWrt, a Linux distribution for wifi routers. And somehow that spiraled into a sewing project with camouflage fabric, pom-poms, and googly eyes. I’ll admit it’s a bit silly, but ask yourself, is it any sillier than trying to ban wifi routers?

Rogue AP detection

Berkeley uses Aruba access points, one of which is installed in our upstairs bedroom. Aruba has a feature called “Rogue AP detection” which is supposed to automatically identify unauthorized wifi access points on the network.⁴ I’m not sure if Berkeley IT plans to use this specific feature, but the documentation at least provides a starting point.

From what I understand, there are three main heuristics:

• MAC address OUI: The first 24 bits of a MAC address is an organizationally unique identifier (OUI) assigned by IEEE to the device manufacturer. In order for a device to connect to Berkeley’s wired network, the MAC address for its WAN interface must be registered with the university. If the OUI of this MAC address was assigned to a vendor like NetGear or TP-Link, that’s a good hint that the device is a personal wifi router.

• Wireless/wired MAC address match: Wifi APs broadcast 802.11 frames containing the BSSID, which is the MAC address of the wireless interface. Aruba can receive and compare the BSSIDs to MAC addresses on the wired side. The BSSID and wired MAC address “match” if the two addresses differ by at most one – this very likely indicates that a wifi AP is plugged into the Berkeley wired network.

• Signal Strength: A wifi AP with signal strength greater than -75 dBm may be classified as a suspected rogue AP. Signals below this threshold are considered “interfering,” but not necessarily rogue (for example, a wifi signal from a neighboring building).

I’m definitely not an expert in wireless networking, so it’s possible there are other heuristics I’m missing. For the purposes of this post, though, I’ll focus on these three – all of which, it turns out, can be controlled using Linux/OpenWrt.

The other risk to mitigate is an IT or maintenance person physically entering the apartment, seeing the wifi router, and reporting it.⁵ It’s certainly possible to sniff wifi traffic with a radio receiver, but I don’t expect that level of sophistication – the much more likely case is someone responding to an IT support call noticing the wifi network on their laptop or phone, or a maintenance person entering the apartment during a fire alarm inspection and seeing the router.

Cheap router from eBay, installing OpenWrt

To experiment with OpenWrt, I bought a cheap wifi router on eBay.

I chose this model (TP-Link Archer A6) because it was listed as “supported” on the OpenWrt “table of hardware” page and because it cost less than $40 USD. Capitalism is amazing sometimes.

Installing OpenWrt went really smoothly. I simply downloaded the firmware from the OpenWrt site and installed it using the router’s web portal. I then configured ssh and was off to the races.

MAC spoofing

ip link shows the interfaces and MAC addresses configured by default:

It’s a bit hard to see, but there are two MAC addresses, exactly one bit apart:

Usually MAC addresses are assigned by the device manufacturer. However, the Linux networking stack is responsible for writing the headers in the L2 frames, including the src and dst MAC addresses. It’s therefore trivial in Linux to overwrite the src MAC address⁶ with whatever you want:

ip link set dev $DEVICE address $MAC

To make these changes persistent in OpenWrt, I added option macaddr to the ‘wan’ interface in /etc/config/network:

config interface 'wan'
        option device 'eth0.2'
        option proto 'dhcp'
        option macaddr 'e8:80:88:29:45:1e'

then applied the change with service network restart.

The MAC address “e8:80:88:29:45:1e” is the same MAC address from my laptop’s Ethernet interface, so from the perspective of the wired network this looks like I’m plugging my laptop into the wired network (which is allowed). The OUI is “e8:80:88”, which Wireshark identifies as “LCFC(HeFei) Electronics Technology co., ltd”. Definitely not a wifi router.

For the wifi side, I edited /etc/config/wireless to use a randomly-generated, “locally administered” address:

option macaddr '02:00:00:85:D1:28'

The first octet 0x02 is 00000010 in binary. Setting the second least significant bit in this octet (called the “U/L” bit) marks the address as “locally administered,” meaning that is assigned by a network administrator (me) rather than by the NIC manufacturer. The rest of the bits are chosen randomly. An Aruba AP could sniff this MAC address, but it would have no way to associate it with any address on the wired network.

I didn’t try this, but it’s also possible to periodically regenerate new MAC addresses in a cron job or init script. This technique, called “MAC address randomization” prevents an adversary from tracking the MAC address over time, and it is often used by mobile hotspots to protect privacy.⁷

Spoofing the MAC address defeats the first two rogue AP heuristics. The MAC address OUI no longer matches any wifi vendor, and the wifi/wired MAC addresses appear to come from two completely different devices.

Radio signal strength

The final heuristic is radio signal strength. To measure this, I ran a program called Kismet to observe the signal from my laptop’s wifi radio. With the default settings, I measured around -41 dBm from 3 feet away from the router. From the other side of the apartment, about 34 feet away, the signal decreased to -62 dBm. Weaker, but still stronger than the -75 dBm threshold for rogue AP detection described in the Aruba documentation.

Fortunately, OpenWrt can configure the radio signal strength using a setting called txpower. I edited /etc/config/wireless to set txpower to “1” and ran wifi reload to apply the new setting. Measuring the signal again from 34 feet away, I saw that it had dropped to -79 dBm, just below the target threshold!

Of course, using a weak signal could cause dropped frames, which would reduce throughput and increase latency. To test the performance impact, I ran some iperf benchmarks⁸ from my laptop to the wifi router:

Setting txpower lower does reduce throughput a bit, but distance from the router is a much larger factor. Even the lowest-throughput configuration (34 feet away, downstairs, with txpower=1) was perfectly usable for web browsing. Not bad!

SSID obfuscation

I wanted to reduce the likelihood of a maintenance or Berkeley IT person noticing the wifi network on their phone or laptop if they happened to be near the apartment. The simplest thing to do was to give the network an unassuming SSID, like “Neighborhood Wifi”. The name kind of makes me laugh. I’m not sure I would even notice something like “Neighborhood Wifi” in a list, especially with a weak signal:

It’s also possible to “hide” the SSID, which prevents the access point from broadcasting the SSID name. Anyone sniffing radio traffic could still see the SSID requested by the client, but at least laptops and phones wouldn’t show the SSID in the list of available networks.

Camouflage

Of course, a wifi router still looks like a wifi router. Further concealment is necessary. My wife and daughter were more than happy to take me to Joann Fabrics.

My wife taught me a trick me to sew the “tubes” covering the antennae: sew the stitch on the “inside” of the tube, then turn it inside-out.

She also showed me a technique for “cinching” the top, but I couldn’t seem to figure it out, so after a few failed attempts she took over.

My 5-year-old daughter knew how to make pom-poms from yarn, so that was her contribution to the project. Also the googly eyes.

I was surprised by how well it blends into the surroundings. I mean, it’s almost invisible to the naked eye.

Conclusion

Could Berkeley IT enforce the ban on personal wifi routers? I seriously doubt it, at least for someone motivated enough to install and configure OpenWrt. At the end of the day, the behavior of the wifi router is determined by software. With Linux, one can easily use techniques like MAC address spoofing to evade detection.

Speaking of Linux, I had a lot of fun playing with OpenWrt, which was much easier to install than I expected. After many years of proprietary and limited router web UIs, it was incredibly refreshing to have ssh access to a real Linux distribution!

I’ll end this post with a small disclaimer for anyone from UC Berkeley who might be reading this. As of today, the ban has not yet gone into effect, so as far as I’m aware all the experiments in this post are 100% in compliance with the current policy. Also – and not entirely coincidentally – I’m moving out of this apartment before July anyway. So long and thanks for all the fish!