Hotspot/Roaming/WDS/Mesh

RouterOS Wireless Networking
1

I think this one is going to be a challenge. There are similar scenarios on the MT forum & Wiki, but none are quite the same, nor seem to apply.

Our goal is to set up a network of MTs, each running a hotspot, and using 802.11a for backhaul. Using the configuration below, we are able to deploy any number of MTs that will “automatically” join the backhaul network:

In this simplified diagram, AP-1 is a mesh controller with a downlink to a landline, and AP-2 (and -3, -4 etc.) are mesh clients that use their A-radios for backhaul via AP-1. All MTs run hotspots, using the same RADIUS server. What we are unable to figure out is how to enable roaming between hotspots using a single authentication domain, without sacrificing key features of this configuration:

  • o There are no dedicated gateways/repeaters–every MT functions as a hotspot
    o Hotspot functionality is not centralized on one box, but distributed among all MTs
    o Separate channel for clients and inter-hotspot links–hotspots do not need to overlap
    o Including Ethernet ports in the bridge allows IP access whether wired or via A-radio

When a user has authenticated at one hotspot and then roams to another, we expected that the RADIUS server would recognize the client’s MAC address from the previous AP and authenticate it on the new AP automatically. But no matter what we try, authentication on one hotspot does not carry over to another; the user has to log in each time he roams to a new AP/hotspot. Enabling ‘login’ and ‘wireless’ Radius services (in addition to ‘hotspot’) makes no difference.

Starting with this configuration, if we add the G-radio to the bridge, the new port is listed as inactive. If we enable WDS on the G-radios, it seems to make no difference. If we run the hotspot on the bridge interface instead of the G-radio interface, and ether1 is still part of the bridge, the MT is no longer accessible by its ether1 interface (neither IP nor MAC).

Can what we are trying to do be done? If so, how do we get there from here? If not, what is the minimum that we need to change?

2

Greetings!

Part 1 - Roaming
I think you are going to have a choice:
a) roaming
or
b) distributed load on the hotspots

The RADIUS server keeps the mac addresses of the clients in the radacct database only. These are NOT used for any further authentication. Each hotspot interface tracks its own authenticated clients.

Part 2 - Mixing modes
The bridge is a-mode, according to your drawing. That is a 5GHz frequency. G-mode is 2.4GHz. They will not communicate with each other like b and g modes. All radios must be in the same mode to share the bridge.

3

Thanks Dude! Unfortunately, that may be a serious impediment to our business plan. :frowning: I thought RouterOS would be able to use the RADIUS server to carry authentication from one hotspot to the next, not just for the initial authentication within a single hotspot.

Sorry, I have corrected the diagram: only the A radios, their WDS interfaces, and the Ethernet interfaces are bridged. I am surprised that A- and B/G-radios cannot be bridged, because I’d think people would want to do just that, to forward client signals via backhaul with minimal interference. If you can bridge Ethernet and 802.11a, and Ethernet and 802.11b/g, I’d think bridging 802.11a and 802.11b/g should be just as easy. So much of this is counterintuitive!

So, if we want to build a single large, roam-able Wifi-enabled area, it sounds like we will need to set up our MTs to bridge client traffic to a central MT running a hotspot, using the b/g band to link MTs–is that correct? Can you think of any way, under that architecture, to put up different login/status pages based on the AP through which someone is connecting–or would that require a routed solution, as I suspect?

4

Darn! I was actually hoping someone was going to prove me incorrect. :frowning:

I have been trying this for a couple weeks now with no success. That does not mean I have given up tho. If I find a way, I will post another response.

“To roam, or not to roam. That is the question”.

EDIT: Here is my new plan. I have not tried it yet. I will set up a VAP on each AP that bypasses the individual hotspot gateways and uses a centralized gateway for roaming clients. The “fixed-base” clients would use the “real” AP and authenticate on the local gateway. But this could actually increase the load on the local AP to a point that it could be counter-productive.

Any other ideas?

5

Hey SurferTim, I reconfigured the backhaul radios (wlan1) from the A-band to G without breaking anything, but in order to add the client radios (wlan2) to the bridge, I had to enable WDS on them as well. And with WDS enabled on both radios, I could set the wlan1 radios back to A and keep them in the bridge. So at least the mixed-band option is back on the table.

Now each box has five ports that could be included in the bridge:

  • wlan1 (backhaul radio)
    wds1 (wlan1’s WDS)
    wlan2 (client radio)
    wds2 (wlan2’s WDS)
    ether1

I have been including each MT’s ether1 interface in the bridge, so I can administer each MT via its ether1 address, whether it is wired or wireless. But in setting up a bridged architecture with one centralized hotspot as suggested above, I have hit a snag: On the master AP, which is running the hotspot on the bridge, if I remove ether1 from the bridge, the other APs are no longer visible; if I include ether1, the master MT is no longer accessible via ether1–which takes the rest of the MTs off the net as well. I probably could come up with a routed (rather than bridged) solution to administration, but it wouldn’t be pretty.

6

Hmmm… Not sure why you are doing this way.
Why are you not using a Mikrotik Controller at the Data Source and then letting it control your users, then your AP’s only have to work with the client connection and back haul?
That way the controller would handle the DHCP and the Authentication and the AP units are only handling the end user and assisting in the traffic shaping your total number of users would increase. Not to mention the overhead of WDS when you are using 802.11a as a backhaul thus no WDS needed, just route the traffic…
Or I may have missed something somewhere…

7

Anyone continue this solution ? I’m looking also for hotspot roaming with wds in 3 storey building.. so when they move between floor still connected to AP

Thanks

8

Okay, I took a closer look at what you are doing, the idea is good, and now I understand the problem, unfortunately now the routing is over my head…

9

Hey WiFiTech,
We want to be able to serve different login pages (co-branding) at each location, and still allow roaming to other locations within our network, without making the user log in again. Not to mention the overhead of WDS when you are using 802.11a as a backhaul thus no WDS needed, just route the traffic.

10

We have a similar requirement: We want roaming users to be able to connect to another AP in our network and
not have to re-login.

To do this, we had to make a bridged network and put the hotspot on the gateway node. All of the other access
points in our network are bridged via WDS.

We use 5.8 GHz for backhaul and 2.4 GHz for access. Each box therefore has two radio cards. Both radios are bridged. We have WDS enabled on the 5.8 GHz radio. It’s not needed on the 2.4 AP radio since it’s not participating in the backhaul. We also bridge the ethernet port to allow local wired connections. Be sure to
set the mac address on each bridge using “administered mac address”. If you let it default, it will randomly pick
a mac address (well, actually it will pick the highest address) from among the 2 radios and ethernet. If you change a radio or disable an AP or ethernet, and that was the mac is was using, everything stops working. Pick an address yourself and add it as “Admin. MAC Address” on the bridges tab of Bridge window.

On the gateway box, ethernet-1 is the interface to the public Internet. We bridge ethernet-2 with the backhaul
and AP radios so we can use ethernet-2 for local wired-access with hotspot login required.

Problem: There seems to be no way for the hotspot to determine which AP the auth request is originating from. We therefore cannot serve up location specific pages. Our location specific pages are specific only to the hotspot, not the AP feeding that hotspot.

This is a problem for us, as it is to you. We also want to log which access point the connection came from, but
so far we have not found a way to do this. In a bridged network, all connections just ‘show up’ at the hotspot and
appear to originate from the wide-area bridged LAN.

I posted a question about this here http://forum.mikrotik.com/t/identifying-origin-node-in-wireless-bridged-network/17633/1 but got no solutions.

We have many networks like this. Each has a single hotspot serving many bridged AP’s. It works fine and the users can roam between nodes (on the same hotspot network) without re-logging in. We do serve up location specific pages, but they are specific to each hotspot network, not to each AP, which we would prefer.

If anyone has a way to identify which AP a client is on so the hotspot can serve up a location specific page, I’d also love to hear about it.

11

I’m trying to do something different.

Question: Can I use one wifi card in wifi2/wifi3 to connect to wifi wds master and to allow clients to use these ap’s or i have to add another card for clients.
topology.jpg

12

No extra card is needed. WDS is designed to do just that. You will loose half your wifi bandwidth when connecting through ap2 or ap3.

13

Thanks. I thought so but i wanted to check. My test equipement comming tomorow (two rb 532 with cm9) so i’ll try it.

14

Huston I have a problem :slight_smile:

I made hotspot and it’s working only when I set it on bridge1 interface. I don’t want to my wired clients use hotspot, only wifi.
I’ve tried to set a wds or wifi as interface but it wont :frowning:

15

Correct. You can setup EoIP tunnels to connect only what you want into a specific bridges.