Fixing WiFi for Fun and Profit

Recently, a buddy and I had the opportunity to help fix the WiFi at a couple of local bars, both part of a larger chain. Being an Ottawa local, this sounded like a great gig - I love a good patio, and beer doesn’t hurt either.

First Location: The Heritage Building

The first location was an old heritage building with a large, scenic patio. After talking with the general manager, I learned they were running a creative setup with both wired and wireless networking gear: a combination of WiFi routers turned into switches with SSIDs combined so devices like ordering iPads and payment terminals could seamlessly roam between all access points to serve the bar’s patrons from anywhere.

The issue turned out to be straightforward but problematic. One access point wasn’t in bridge mode, which meant devices connected to it were on their own subnet and couldn’t communicate with other devices, including the server that runs the restaurant’s ordering system and all the order printers. I assigned manual DHCP leases to the order printers so that when they’re eventually reset for whatever reason, they’d still receive the same IP address and keep working with the restaurant management server.

I also hooked up a new WiFi router on the other side of the bar to boost signal coverage. Thankfully, it’s a very open and airy space, so the signal travels far without much interference from other networks.

Second Location: The Museum Patio Bar

The second location was another patio bar in downtown Ottawa, situated off of a museum. It’s wide open and secluded, which should have made this an easy job to configure the network and make sure the signal is strong everywhere. However, it turned into a larger issue when we discovered that the internet had been working but then stopped a few days before we were scheduled to show up. The bar was set to open the next day, so fixing the internet became the top priority or else they may have to delay opening.

I found myself hanging out in the bar’s small office right off the kitchen while the team was busy testing menus, training new cooks, refreshing landscaping, and fixing deck boards — lots going on all at once. We immediately became “the IT guys” to everyone who saw us working. Roles were clearly defined as the patio was brought back to life after a long winter.

We couldn’t get the gateway router to dynamically receive a DHCP address, so we tried setting the static address, gateway, and subnet provided by the museum’s uplink. No luck. We connected the bar’s computer directly to the incoming ethernet and tried the same configurations, but still nothing worked.

At this point, I headed back home to grab an old Linux laptop with a built-in ethernet jack. Using ChatGPT for guidance, I started testing whether ARP was even working. Basically checking if there was another device on the other side of the ethernet and fiber run that was responding. Running tcpdump -i en2ps0 arp was incredibly helpful in confirming what the issue was, as it showed me the raw ARP requests going across the network. I could see my computer sending messages, but nothing was coming back. Not a good sign. This was likely something that required the museum’s IT team to resolve. Probably a broken cable or misconfiguration on their end.

We ended up forming a contingency plan with the general manager for the bar to open the next day. The plan combined the restaurant management software’s ability to work offline with a credit card payment terminal that used cellular service.

On the plus side, we enjoyed a pint of beer on the patio as the first patrons of the season.

Museum Part Two: Success

We later found out it was indeed a fiber optic cable issue, which the museum’s IT team confirmed and fixed. With internet restored, we returned to focus on getting the newly installed WiFi mesh network set up using the same WiFi SSID, testing signal strength and speeds, and confirming all ordering tablets and payment terminals were connected properly.

After setting up the mesh network, I used WiFiman from Ubiquiti to test signal strength and roaming capabilities throughout the entire bar. We achieved great signal strength everywhere, so devices shouldn’t have any connectivity issues regardless of location. We did notice that internet speed was 30 Mbps down — not blazing fast by today’s standards, but absolutely sufficient for payment processing devices and streaming some Spotify music. Hopefully employees don’t jump on the network and stream too many videos on their breaks, which could slow things down.

I noticed something interesting during the speed tests: when connected to some WiFi access points, I’d get the full 30 Mbps, but others only delivered 8-10 Mbps. Digging into the WiFi mesh settings, I discovered two of the three access points had link speeds of 10 Mbps instead of 100 Mbps — definitely the bottleneck. We narrowed this down to one device being directly connected to the main POE switch (the 100 Mbps one), while the troublesome ones (10 Mbps) were located on the far side of the bar. These problematic access points were using very cheap PoE switches to provide ethernet and power to other devices at a satellite ordering station and bar.

We determined that everything should function well enough even with the 10 Mbps limitation, but if there are slowness or connectivity issues on the far side of the bar, those cheap PoE switches should be the first thing to replace.

Last but not least, we finished that afternoon with a well-deserved pint on the patio.