evading the wifi router ban

Photo of a wifi router covered with fabric in camouflage pattern with googly eyes

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.1

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 LAN2 (printers, Sonos, Roomba, etc.), mDNS, DHCP reservations, or local ad-blocking DNS like Pi-hole.3 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.4 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:

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.5 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.

Screenshot of “TP-Link Archer A6 AC1200 Gigabit Wi-Fi Wireless Router, Dual Band, NEW” eBay page, with price listed as US $37.99

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.

Screenshot of OpenWrt supported hardware page, with TP-Link Archer A6 v2 and v3 listed as supported

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:

Screenshot of terminal with output of ip link command. The interfaces eth0, wlan1, br-lan, eth0.1@eth0, and eth0.2@eth0 all have MAC address 98:DA:C4:F2:B8:DC and the interface phy-ap0 has MAC address 98:DA:C4:F2:B8:DD

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

MAC addressInterface(s)
98:DA:C4:F2:B8:DCLAN (both wired and wireless)
98:DA:C4:F2:B8:DDWAN (wired only)

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 address6 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.7

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 benchmarks8 from my laptop to the wifi router:

Bar chart with title “Throughput vs distance and txpower”. The x-axis is labeled “Throughput (MBits/sec)”, and chart has the following values: (1) 34 feet away, one floor below, txpower=23 had throughput 132 MBits/sec, (2) 34 feet away, one floor below, txpower=1 had throughput 128 MBits/sec, (3) 3 feet away, same floor, txpower=23 had throughput 312 MBits/sec, (4) 3 feet away, same floor, txpower=1 had throughput 293 MBits/sec

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:

Screenshot of GNOME “Visible Networks”. The currently connected network is called “Neighborhood Wifi” and connection strength is one out of 3 bars. Other networks in the list show full connection strength, including “eduroam”, “Berkeley-Visitor”, and “Berkeley-IoT”.

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.


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.

Picture of an employee from Joann Fabrics cutting camouflage fabric with a pair of scissors.

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.

Picture of camouflage fabric, a sewing needle, and stitches with green thread.

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.

Picture of camouflage fabric with green/white/black yarn pom-poms and two googly eyes glued on.

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

Picture of wifi router with camouflage, pom-poms, and googly eyes on top of grass with leaves in the background.


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!

  1. It’s unclear if the ban applies to other devices that act as wifi access points without connecting to the Berkeley network. For example, am I no longer allowed to put my iPhone in hotspot mode? ↩︎

  2. This morning they sent an email saying that “based on feedback from UVA residents” they plan to enable an Aruba feature called AirGroups that is supposed to address this use case. It’s a step in the right direction, but why did they wait until three weeks before the announced date of the ban to address this critical gap in functionality? ↩︎

  3. Incidentally, pi-hole.net is another site Berkeley IT has accidentally broken with misconfigured routing rules ↩︎

  4. See “Rogue AP Detection”, “Rogue AP Detection and Classification” and RAPIDS↩︎

  5. This isn’t exactly theoretical. We once had a maintenance person take a picture of a bidet in our bathroom and report us for violating the “no dishwashers” rule. Still not sure how they could believe we had a dishwasher in our toilet. ↩︎

  6. Perhaps MAC address spoofing is against some IT policy, but if so I couldn’t find it stated anywhere. The MAC addresses I used all belong to devices I own and registered with the university, so as far as I’m aware this is all aboveboard. ↩︎

  7. Rye, E., & Levin, D. (2024). Surveilling the Masses with Wi-Fi-Based Positioning Systems. arXiv preprint arXiv:2405.14975. ↩︎

  8. The exact command was iperf -c on my laptop and iperf -s from OpenWrt on the wifi router, using the 5Ghz band. Reported throughput is the median value from three trials in each configuration. The maximum throughput achieved (312 MBits/sec) was the same for both wifi and wired Ethernet, suggesting that at close range the main bottleneck in this test was the CPU of the router itself (presumably routing to the WAN uses hardware acceleration to bypass the CPU to achieve the Gigabit throughput TP-Link claimed for this model, but I didn’t test it). ↩︎