Using with open-mesh / cloudtrax devices

[natrat22]

Having a major issue

I'm putting Firstspot into an existing resort that had a previous wifi system which uses 30 or so open-mesh devices (OM2P range).

These devices have multiple SSIDs but the guest wifi is on SSID2 which is bridged to the network LAN. This means that open-mesh devices that are plugged in with a cable to the switch which is plugged into the Visitor NIC receive a LAN IP from firstspot itself.

At first when i plugged in, all the open-mesh devices went offline and couldn't be seen via the cloudtrax.com management interface. This obviously is because they are on the visitor LAN and hadn't logged in to Firstspot. I whitelisted the WLAN MAC address for the open-mesh devices in Firstspot and they now report to cloudtrax successfully.

However, anybody connecting to the guest wifi does not get taken to the portal page. They receive an IP address in the range given out by firstspot (10.27.7.x) and DHCP/DNS etc is the 10.27.7.1 interface (which is also pingable) but are not directed to the portal and no DNS resolution works at all.

Replacing 30 devices with a more standard non-cloud mesh setup is not an option here. I just need to get it operational and I'll have an order for you guys, so i'm in need of quite urgent help

cheers
nathan

[alan]

Can the FirstSpot machine resolve DNS? Note that FirstSpot DNS server is a just relay, and it uses on the "first" DNS entry of Internet Network Interface as source.

If you still have issues, please run the following commands in the FirstSpot server and post the output here:

ipconfig/all
nslookup apple.com
_________________
~ Patronsoft Limited ~

[natrat22]

Yes the Firstspot server has no issues with internet itself.

I'm making progress. There seems still to be some level of communication problem between the devices and cloudtrax though. I'm wondering if the LAN MAC of the open-mesh devices that are plugged in with a cable also needs adding?

[alan]

Normally you don't need to put any client side network devices MAC in the FirstSpot Client Pass-through, unless your open-mesh devices (client side network devices) need to access the Internet directly.

Note that you need restart FirstSpot if you change the Client Pass-through list.
_________________
~ Patronsoft Limited ~

[natrat22]

I think i've found a bug that has been driving me mad.

I have a open-mesh device that is the first entry in MAC whitelist (the devices do need internet directly as they report to a cloud control system which is the only way ton configure their SSIDs etc).

I've been trying to work out why it appears to be online but isn't.

The MAC address of the device is ac:86:74:27:a9:80.

In the DHCP allocation table the first entry is for a device ac:86:74:27:a9:81 (note 81 as the last pair, not 80).

There is no device in this network that has that MAC address, the only device close to it is ac:86:74:27:a9:80. Despite being plugged into the switch connected to the visitor NIC, ac:86:74:27:a9:80 is *not* appearing in the DHCP allocation table.

I think there may be a bug in DHCP allocation in relation to MAC whitelisting, and the device listed in DHCP allocation as ac:86:74:27:a9:81 is actually ac:86:74:27:a9:80.


Help

[natrat22]

I'm also seeing two MAC addresses in the DHCP table in FirstSpot ending in B that are identical to two open-mesh device MAC addresses except they end in 8? Coincidence?

[natrat22]

ok that looks like it was a coincidence. But the original issue with the 80/81 seems true, i can't use that device on the network. I've grabbed another unit that is further down the MAC whitelist and plugged it into the same por and it shows up in DHCP fine and also works.

[alan]

First, DHCP assignment (stored in the file dhcpservice.ini) is not related to our Client Pass-through feature within FirstSpot.

At this point, my guess is there is no problem in our DHCP server. It is just your mesh-devices did ask for IPs.

Alternatively, you can try is to reset FirstSpot DHCP existing client IP assignment by:
- stop FirstSpot
- rename the file dhcpservice.ini under FirstSpot\dhcp directory to something else
- start FirstSpot
_________________
~ Patronsoft Limited ~

[natrat22]

Not sure how you can conclude that. I've got a MAC ID in the DHCP allocation table that doesn't exist on the network one number off the device that isn't working.

That device does work if it is just connected via the wifi mesh instead of cabled (the device then doesn't get a LAN IP from the visitor NIC as such then), so i've worked around it but I suspect theres still a bug.

Getting there slowly.

[alan]

We need more information. It will be great if you can send us the client device IP configuration review.

Our ideal situation is that :

1) in the visitor network side only FirstSpot DHCP server is active. That way we won't confuse which DHCP server give out the IP address

2) for your fixed mesh devices (not client devices like PC or smartphone), we normally recommend that you use fixed IP instead. You need add those IP in the FirstSpot DHCP -> Excluded IP list (only if those IPs are in the same subnet as our Visitor Network Interface IP).
_________________
~ Patronsoft Limited ~

[natrat22]

Unfortunately with open-mesh devices you have no control over the IPs the cloudtrax system gives them, it gives them addresses in its own ranges. There's no static IP options.

Only the open-mesh boxes connected via LAN cables to the switch/visitor NIC get an address from the Firstspot DHCP and are visible in the DHCP allocation table. As the open-mesh device SSID is bridged to the LAN interface (ie the visitor NIC) devices connecting to the open-mesh boxes get a Firstspot assigned IP address without issue.

I know its not ideal using these open-mesh boxes, but the large resort already has 36 of them and isn't willing to spend $4000+ AUD for new non-cloud controlled AP hardware.

Anyway i have worked around the dodgy MAC/DHCP issue by moving that device into the non wired mesh; another open-mesh box in its place works fine. The only difference between them is the location they appear in the Client MAC filter table, but you say they are unrelated so who knows what that issue is. If i see it again or ever am in a position to be able to test I will.

One other small issue - when connecting to Firstspot, if the user tries to browse to a https page they get a error and are not taken to the portal. If they try to browse to a non secured http address t hey are successfully directed to the portal page. Is that an easy fix?

[alan]

This is a limitation of https. FirstSpot has no easy way to decode the https and then forward to our captive portal login page. The workaround is to "trust" the FirstSpot web page in the browser setting.
_________________
~ Patronsoft Limited ~

[natrat22]

Heres an example of the DHCP bug. Right now I just plugged in a single open-mesh AP to the system and this is its DHCP allocation table result. It is the bottom entry:

AC-86-74-5E-96-21 10.20.7.115 unknown Dynamic Wed Aug 03 21:17:29 2016 Fri Aug 05 21:17:29 2016

That is the current time right now in the lease obtain time. Right now it is the only device connected.

The MAC in the table there is incorrect - the correct last digit is 20, not 21. Once again it has added 1 and the device is not functioning on the internet. Pretty sure this is a bug?

[natrat22]

Heres an example of the DHCP issue. Right now I just plugged in a single open-mesh AP to the system and this is its DHCP allocation table result. It is the bottom entry:

AC-86-74-5E-96-21 10.20.7.115 unknown Dynamic Wed Aug 03 21:17:29 2016 Fri Aug 05 21:17:29 2016

That is the current time right now in the lease obtain time. Right now it is the only device connected.

The MAC in the table there has the last digit as 21 whereas the device label says 20.

Now i'm suspecting that the label is talking about thw MAC of the wifi interface, and the +1 is the MAC of the LAN interface that the cable is plugged into. does that sound likely? If i whitelist that address i suspect the devices will then work.

[natrat22]

I've fixed it but i'm not sure where the problem is. I added the other MAC to the whitelist but that didn't fix anything (i did restart firstspot).

The only other change I did between when it was working and when it wasn't was setting bandwidth throttling on the dispatcher to No throttling. I've just turned global throttling on again (but a high amount 5000/5000) and now the AP is working.