WiFi Deployment for Hack Oldham 2


#1

Hi. I’m a new member who’s a huge Linux/*BSD, infosec and networking geek. I overheard you guys talking about what would be the best WiFi deployment solution for the new space. I’m definitely not an expert in this area, but I have some experience gained through casual interest, i.e. trying to understand how the WiFi network at my university worked, messing around with OpenWRT routers at home, playing with the Linux wireless stack, etc.

Wireless Repeaters vs Bridges

aka “Can we get away with multiple routers using the same ESSID and key”

Before I can answer the above question, I must first explain the difference between an Access Point, a Wireless Repeater and a Wireless Bridge. A Wireless Repeater does exactly what it says on the tin. It amplifies an existing wireless signal by re-transmitting packets to and from an existing Access Point. This is great when you’re simply looking to extend the range of an existing wireless network, i.e. when you have an area in your house where the signal from your router doesn’t reach. Since wireless repeaters simply rebroadcast an existing signal (meaning that all repeaters must operate on the same wireless frequency and channel), they improve the range, but do nothing to increase the number of concurrent users connected to your wireless network. There are also obvious latency and reliability issues associated with using multiple repeaters.

If you want to increase the number of clients on your wireless network without compromising latency/speed, you need what’s called a Wireless Bridge. Each bridge can operate independently on its own wireless frequency and channel, meaning better speeds for multiple clients. Unlike a regular commodity wireless router, a wireless bridge is supposed to be connected to an existing local-area network and not directly to the Internet. The clients connected to the wireless bridge get an IP from and can talk to other clients on the existing network, whereas with a regular AP, they would be put on a separate NAT, only being able to communicate with the clients connected to the same wireless AP.

Most commodity routers do not include bridging functionality. Even if you replace the firmware with something like OpenWRT/LEDE, most open-source Linux wireless drivers do not support bridging wireless adapters in client mode (there are third-party patches out there, but not officially supported by OpenWRT). Therefore, in most enterprise deployments, you won’t get away with using multiple APs using the same ESSID and key. With OpenWRT, there is the possibility of creating a wireless “pseudo-bridge” using relayd, but you will still be left with a half-baked solution compared to using an Access Point Controller.

Access Point Controllers

A Wireless controller provides a single configuration interface for all Wireless Access Points on your network and also acts as a switch for all wireless traffic. They allow for scaling your wireless network with additional APs as needed, and eliminate the need to re-architecture your wired network to host a wireless one. They also provide roaming and load-balancing functionality. With a “controller-less” wireless network (i.e. the multiple APs with the same ESSID scenario), it is up to the client to decide when to switch to an access point with the stronger signal. A controller can force a client to switch to a different AP, ensuring a smooth transition. In theory, wireless devices should be able to make their own judgement where it comes to deciding which AP to connect to, but in practice, most devices will “hang on” to the same AP until the signal gets very weak. This may result in a noticeable handoff period lasting a few seconds. While most PC operating systems allow the user to adjust the signal strength threshold, most mobile users are out of luck here. Letting the controller manage the roaming between APs really makes a night and day difference - there is zero noticeable latency to users. It’s like replacing a hard drive with an SSD - once you felt the difference, you never want to go back.

Alternatives to hardware-based AP controllers

Most access point controllers come as an expensive hardware appliance. I don’t have any personal experience with their products (my university used Cisco* APs), but I’ve heard good things about a company called Ubiquity* and their Unifi series of products. Unlike their competitors, their AP controller is software-based and available free of charge. It can run on anything, from a custom-built server, to an old PC and even a Raspberry Pi. Anything that runs Java. They do have support for all the features that you would expect, like zero-handoff roaming. Looking at Amazon, their APs seem a bit more expensive, but for a relatively small space (small as in not a multi-storey office building) like Hack Oldham 2, eliminating the cost of a hardware-based AP controller, the overall cost of the initial deployment should be a lot less. There are also companies like XClaim* that offer cloud-based AP controller solutions for entry-level enterprise deployments.

*Note that I’m not endorsing any of those companies. I started this thread to share what knowledge I (and maybe other people) have in this area, to help you make the best decision. :slight_smile:


#2

Yes, I was thinking of sticking all the AP traffic on a separate subnet

Not sure if I follow you there? Did you mean VLAN? I’d love to do that, but unsure that cheapo spare routers we have are capable of doing that?[quote=“tjg1, post:1, topic:578”]
Therefore, in most enterprise deployments, you won’t get away with using multiple APs using the same ESSID and key
[/quote]

Was hoping to do WPA2 enterprise with LDAP backend like what mostly all enterprise deployments do. Possibility of a guest network, but maybe more of 1st floor than basement. Not really thought that one through much, maybe run a basic firewall on it to stop abuse?

I don’t see us needing to worry about this? Wireless controllers are mainly used for mobility and load balancing of many users. We have not checked the coverage/number of APs yet, but can’t imagine it being many… however, speeds might be an issue, but something to worry about as and when I think. Client based handover should be good enough. But again, experimentation might prove me wrong there.

I just hope we can get our commodity ISP routers to work in our configuration. Cheaper (free) the better! :slight_smile: Unless cisco want to sponsor us and install a proper enterprise setup hehe


#3

Could we possibly install some form of Ethernet which could be linked to certain areas to avoid issues with wireless speed?


#4

comms room to workshop (clean side) isn’t far, so would be a simple enough thing to do. Might need to source a long cable, mind.


#5

maybe one cable and a switch? For example you could just plug - for those that still have- an ethernet cable in


#6

yes, depending on the needs of the clean side, a mini switch, or even a larger one can be put there. Although, at this point in time, other things need priority and how the space will be used is likely to morph as we start to move in.

I made a 3d model/video of the new space to give you an idea


#7

This page explains it better than I can do (Routed Client Mode vs Bridged Mode): https://wiki.openwrt.org/doc/howto/clientmode

Whether it’s something you need to worry about, it really depends on the number of concurrent users and the number of APs needed. Ubiquity has a network planner on their website: https://design.ubnt.com/#/


#8

Haha, it is a little basic :slight_smile: It is hard to do wireless planning without detailed models or physical testing in the environment. In high density developments, it isn’t distance you are mainly concerned with, but instead the error rates. Sharing the spectrum means more collisions and background ‘noise’, meaning failed packets and retransmissions (which, in a 802.11 world, means downgrading the bit rate, potentially down to 1Mb/s from 54Mb/s


#9

Are you planning to wire an ethernet backbone for WiFi or use WDS? Ignoring the issues with client roaming and having to manage each AP individually, with a wired backbone, it’s possible to have multiple controller-less APs with the same ESSID and key.


#10

if all goes to plan, it should be easy to wire in the APs with an ethernet backbone. The overhead ducts/wire racking are already there.

As I already mentioned, we will be using WPA2 enterprise with a LDAP backend. Meaning the network name will be the same and we do not need to mess about with shared keys, since everyone would have their own login.

Not knowing if wifi chipsets actually implement roaming features (and i’ve looked, they dont tell you diddly squat other than the main n/g/ac amendments), we will just have to suck it and see. I do not foresee us needing to have a complex setup here. The only issue I see us having is using random hardware for the APs and bottleneck in the network due to daisy-chaining. Again, we will have to see how it goes and plan accordingly.


#11

Just +1 to say ubiquiti unifi AP are good. They’re about £100 each, but setup is pretty quick and you can manage them centrally. You can also set up multple SSIDs really easily and tie them to a different VLAN, so you can easily separate guest/member/e.g. IP CCTV . They’ve got a decent antenna, and can cope with a good number of simultaneous users too.

Again, depends on how much you value tinkering time (and how you want to spend it)-- and setting up a load of AP/routers and also maintenance of it in the future.

LDAP RADIUS sounds good option too, and having it tied to authoritative list of all members of the space sounds good.


#12

It would be nice to have a pot of money to put into infra/wifi. My planning/assumption so far is that it will be tinkering to the extreme at first, then hopefully expanding this to a proper deployment if successful/over time.