Revamping Noisebridge WiFi inside 272

Hello Noisebridge community and potential space WiFi users. :wave:

With the help of some generous hardware and time donations by @SuperQ, he and I took some time this weekend to improve the WiFi and network inside of The Space.


  • We would like to change the WiFi name and would like to make the transition as painless as possible.
    The new network name is “Noisebridge” with a password of “noisebridge”.
  • If you need to set or to input a password for something at Noisebridge, use noisebridge and make sure it is only accessible on the local network. This helps keep the space hackable and accessible to new folks.

Currently, it appears that there is a single Cisco/Meraki AP serving the whole space with an ESSID of “Noisebridge Cap”. While this seems to be covering the space decently with low density clients, this solution appears to require a cloud-based management system and doesn’t have a clear path to scaling up our coverage. The “Cap” vs “Capp” spelling is also a bit of splinter in my mind.

We currently plan to switch to using Ubiquiti Unifi products, as they can be managed locally without any cloud dependencies, and deliver a relatively high performance-to-price ratio. This seems like a good balance that lets us easily add more access points for more coverage in the future, as well as creating a network that survive some vandalism or a lost AP.

What was built out:

  • There are 4x new Unifi Wifi 6 Lite APs installed in 272 Capp: two upstairs and two downstairs.
  • A new managed 24 port POE Unifi switch was installed in downstairs rack.
  • We have also rebuilt and imaged a PC to act as a server for space-local services: colt.noise
    • The main impetus for building colt instead of using pegasus was needing a 64-bit OS for the Unifi Network management application.
    • The Unifi Network application is available at inside the space. Login noisebridge, password noisebridge
  • A new WiFi ESSID was configured in Unifi:
    • ESSID: Noisebridge
    • Authentication: WPA2 password noisebridge
      • The rationale around adding a password was that it adds some basic link-layer encryption to prevent casual snooping. While local ARP/ND poisoning is still totally possible, it’s at least an active attack.
      • WPA2 was chosen to avoid any compatibility issues with older, embedded clients. Ideally we could upgrade to WPA3 if there are no issues.

Now that we have a locally-manageable network set up, we would like to figure out a nice transition to get users off of Noisebridge Cap and onto Noisebridge.

Proposed next steps:

  • Put out feelers to see if anybody has special feelings about the current Cisco/Meraki AP and if it can be replaced.
  • Print out some attention-grabbing signs with WiFi details and a WiFi QR code for mobiles.
  • Setup a second ESSID in Unifi called “Noisebridge Cap” with no auth (to match the existing config)
  • Disconnect the Cisco/Meraki AP
  • Track “Noisebridge Cap” client names in the Unifi Network application for a couple weeks and work to migrate anything that is still connecting to the old network


  • The downstairs rear AP is only pulling a 100 Mbit link, but should be Gigabit. Cable probably requires re-termination.
1 Like
  • IPv6 is mostly working in the space with stateless router advertisements and routing. I think IPv4 is still needed for DNS; we could setup DHCPv6 later.
  • The Noisebridge Cap ESSID has been setup on the new Unifi-based WiFi, and the old Meraki AP has been returned to @Chaz
    • The Unifi Network app on colt.noise can see which clients are still connecting to the “Noisebridge Cap” network. Maybe we can try and migrate them gracefully?
  • dnsmasq was setup to integrate with DHCP such that you can just ping <hostname>.noise in the space and it should more or less just work.
1 Like

Sounds like a good plan. A little bit of WPA can’t hurt too much? Also we have a ton of routers, I could see having an open network and a password…

Now that we have this Unifi based system, we aren’t even limited by routers or access point hardware: we can configure any number of ESSIDs that we want.
However, it comes with a tradeoff/catch: beacons of the network names are transmitted at the slowest configured rate for the cell. In order to keep backwards compatibility with old clients, this is quite slow and takes up valuable air-channel time that could be used sending high-speed packets.

So the questions to the community becomes these:

  • Does link-layer encryption with a static, known passphrase provide a false sense of security for users, or does it raise the bar to prevent passive traffic sniffing?
  • Do we want to maintain compatibility with “ancient” WiFi hardware? With all the old, weird gear in the space, it wouldn’t shock me to learn that we have some 802.11g and 802.11b clients still out there somewhere.
  • With an open network, do we want to provide Internet and LAN access to anybody in the neighborhood? Anonymous misbehavior attracting DMCA complaints might cause consternation with Monkeybrains over time, but their goodwill is valuable to us and is worth protecting.