Ubiquiti Unifi Binding Feature Discussion

rzwarts · November 6, 2018, 3:30pm

Thanks! This will take some time, but I will get it working… There’s so much more you can get from unifi.

Dim · November 6, 2018, 3:35pm

true

check this post #451 out also: Ubiquiti Unifi Binding Feature Discussion - #451 by mgbowman

Matthew was recently discussing feature improvements and asking opinions here

rzwarts · November 6, 2018, 3:39pm

Matthew,

I was pointed to your posting for features and as I am missing atleast a few (like 802.1x) and am willing to help you with coding let’s get together… I have coding experience just not using github. And compiling on mac will be a new one for me… (see my PM).

havaak · November 6, 2018, 4:04pm

That is true when talking about local networks, but not possible in regards to remote networks.

regards

Han

KurtS · November 6, 2018, 9:55pm

Hi all,

I have a device in my WiFi (iphone XR) which seems to flap between APs and which shows some strange behaviour: It is connecting to an AP and disconnect continuously.
Other Iphones or devices do not show that kind of characteristics.

Is there a way to surpress this behaviour from binding-side, so it won’t turn on/off my presence detection continuously?

Here’re the logs:

2018-11-06 22:44:57.693 [vent.ItemStateChangedEvent] - unifi_XRiPhone_online changed from ON to OFF
2018-11-06 22:44:57.722 [vent.ItemStateChangedEvent] - unifi_XRiPhone_AP changed from AP_DG to UNDEF
2018-11-06 22:44:57.741 [vent.ItemStateChangedEvent] - unifi_XRiPhone_online changed from OFF to ON
2018-11-06 22:44:57.749 [ome.event.ItemCommandEvent] - Item 'PresenceEGKG' received command OFF
2018-11-06 22:44:57.764 [vent.ItemStateChangedEvent] - unifi_XRiPhone_AP changed from UNDEF to AP_DG
2018-11-06 22:44:57.771 [ome.event.ItemCommandEvent] - Item 'PresenceOGDG' received command ON
2018-11-06 22:44:57.778 [ome.event.ItemCommandEvent] - Item 'PresenceOGDG' received command OFF
2018-11-06 22:44:57.782 [ome.event.ItemCommandEvent] - Item 'PresenceEGKG' received command OFF
2018-11-06 22:44:57.796 [vent.ItemStateChangedEvent] - PresenceOGDG changed from ON to OFF

thanks in advance for your guidance,
Kurt

pahansen · November 6, 2018, 10:37pm

Does it flap continuously? Or will it settle on the AP eventually? It might be easier to add some delay to your presence rule to allow the flapping to finish before checking the actual state and setting Presence.

mgbowman · November 7, 2018, 4:22am

@KurtS this looks like very odd behavior as from your log it seems to happen within the same ‘refresh’ period

Your unifi_XRiPhone_AP goes from AP_DG to UNDEF back to AP_DG in a matter of 50ms.

Sent you a PM.

mgbowman · November 7, 2018, 4:25am

I sent @rzwarts a PM to try and help him , but quick question - anybody else use 802.1X in their environment?

mgbowman · November 7, 2018, 4:25am

Never thought about it like that… +1 for wired clients then

jmccoy555 · November 7, 2018, 10:22am

Yep, for authentication and VLAN assignment.

mgbowman · November 7, 2018, 5:52pm

So I’ve had a few moments to look at the code and I want your opinions on a possible solution…

What if the mac parameter on the client thing configuration became identity where you’re permitted to put either the MAC address (as is now) or the 802.1X identity?

This would require the least amount of code changes as all the logic is exactly the same, I would just index the respective caches by both the mac parameters and the 802.1X identity (assuming non-null) that get returned by the controller.

What do you guys think?

Dim · November 7, 2018, 5:54pm

sounds good!

mgbowman · November 7, 2018, 5:57pm

Another possible solution would be to index & lookup by hostnames.

rzwarts · November 7, 2018, 6:09pm

Sounds good… But with one exception… I would need to differentiate between different clients using the same login. So if that would be a option it sounds good

The offer still stands to help

mgbowman · November 7, 2018, 6:12pm

Next thing you’re going to tell me is you need this for multiple clients that all have random MAC addresses?

If that’s the case, the best solution would be hostnames.

I sent you a PM.

rzwarts · November 7, 2018, 6:14pm

No I’m not going to make it harder maybe slightly. But just putting in my 2 cents if you are going to implement it, better take all the use cases…

mgbowman · November 7, 2018, 6:24pm

On a more serious note, you actually make a good point to an issue with using 802.1X by itself…

I log into the wifi with my laptop using the identity ‘mgb’ (mac address = AA:BB:CC:DD:EE:FF)
I log into the wifi with my phone using the identity ‘mgb’ (mac address = 11:22:33:44:55:66)

The identity is not unique and therefore cannot be used as a unique identifier / index. It would have to be some combination of MAC address (even if it’s just vendor prefix) + 802.1X identity.

I’m wondering if using hostnames wouldn’t just be easier all around. The 802.1X identifiers are not included in the insights data, the hostnames are.

I’m still with @Dim…

rzwarts · November 7, 2018, 7:11pm

Although I’m also not happy with the Mac changing. It’s a given. So I will have to find a way

And on Mac addresses and 802.1X. Even on a laptop you have 2 addresses wifi and lan

mgbowman · November 8, 2018, 3:49am

Yes but now you’re talking about tracking a wireless client vs a wired client.

Since an 802.1X identity could be used with multiple clients, I think the best way to handle this would be to add an optional hostname parameter. If the client cannot be found directly by MAC address, it could either simply fallback to the hostname or a combination of the vendor OUI (AA:BB:CC:xx:xx:xx) + hostname.

Either way, if you guys think there’s a benefit to having a 8021.x property from the perspective of automation, that can easily be added. I just don’t think it can be used to identify a specific wireless client.

Thoughts?

mgbowman · November 8, 2018, 5:25pm

I found a way… install build #11

org.openhab.binding.unifi-2.3.0-SNAPSHOT.jar

Everybody else can just stay with the build they are on as I reverted these changes… this is a “workaround” for @rzwarts as the permanent solution is for him to fix his phone.

From the link @pauli_anttila posted:

Starting in Android 8.0, Android devices use random MAC addresses when probing for new networks while not currently associated to a network.

In Android 9, a developer option can be enabled (it is disabled by default) to cause the device to use a randomized MAC address when connecting to a Wi-Fi network. A different randomized MAC address is used per SSID.

What I understand from that is Android 8 uses a random MAC when probing for Wi-Fi networks (aka it’s not connected to Wi-Fi … no phone searches for Wi-Fi networks while it’s currently associated). In Android 9, you can enable a (disabled by default) developer option that uses a random mac per SSID … I highly doubt it actually uses a random one every time it connects to an already remembered network. Of course, if you “forget the network” and re-associate, a new address would be generated - but I don’t think it generates a new once every time it connects to a previously remembered network.

I’ve worked in networking for a long time and this is the first time I’ve ever heard of a device using a random MAC address every time it associates to a network. This is simply not normal.

You’re more than welcome to take the code and use it how you see fit, but I do not think this hostname support should be in the binding just for 1 edge case that appears to be a faulty device. I think having a MAC address required and an optional hostname will just confuse users.

That’s my 0,02€ (or $0.02 for those of you using freedom units)

Matthew