Guest Portal Access Expires Early about unifi-api-client HOT 25 CLOSED

Hmmm, strange. What does the event say when the guest device was authorised?

I've never seen this behaviour by the way.

from unifi-api-client.

Attached an exported a log from the database.

guests_logging_export.txt

from unifi-api-client.

Without knowing which timezone your controller is in and which device is displaying these issues I have no way of troubleshooting.

BTW, I had requested the initial event for an auth (so from the events collection) which had expired too soon, not the log entries. Something like this:

    {
        "_id": "5acbbc0fa402c6717ac278da",
        "admin": "Admin[hotspot_user]",
        "datetime": "2018-04-09T19:16:31Z",
        "guest": "00:cd:fe:dd:55:44",
        "is_admin": true,
        "key": "EVT_AD_GuestAuthorizedFor",
        "minutes": "20160",
        "msg": "Guest[00:cd:fe:dd:55:44] is authorized by Admin[hotspot_user] for 20160 minutes",
        "site_id": "56ee74bceaa0990c8a62a0ea",
        "subsystem": "wlan",
        "time": 1523301391654
    }

from unifi-api-client.

BTW, I am not here to troubleshoot issues with the controller itself which is why I need to see this information. If the API request was issued correctly, it is better to use the UBNT forums for this question.

from unifi-api-client.

Hey, sorry about that - I totally understand, we've been working with the unifi team as well. So far what we've done is:

1. changed the authorize_guest to authorize the ap: ( $request_id , 43200 , null , null , null , $request_ap );

2. We have upgraded Unifi to the latest version.

I am now being told occasionally people aren't being authorized right away; so we're noticing its multiple issues (1) The clients are intermittently not logged in on the first try. Some times they need to try 2 or 3 times before getting access and (2) The clients are not being logged in for the full 30 days; after 24 hours users are required to reconnect.

The response i'm getting from the guest_authorize is "true" - do you want the callback from a different request? the ->login() request?

from unifi-api-client.

Thats strange behavior, haven’t seen that before.

What I asked for is the object in the event collection which was created upon the auth of a device with which you observe these issues. That’s just to confirm the auth came through as planned.

from unifi-api-client.

I have seen issues with empty values for up/down speed parameters. What happens if you just request 5Mbps for up/down as well?

from unifi-api-client.

Just to clarify (as I am not on-site) - the event collection object is in the Unifi controller? I will reach out and get you this information ASAP

from unifi-api-client.

Yes, it’s exposed through the API. You can always use the API Browser tool to quickly browse various collections: https://github.com/Art-of-WiFi/UniFi-API-browser

from unifi-api-client.

Sorry, is there a way to grab this from the Controller or do we need to set up a program and check it out? This is run on an internal server at an external location - any simple way of grabbing this information would be extremely helpful

from unifi-api-client.

Yes, you can do this through the API using this function:
https://github.com/Art-of-WiFi/UniFi-API-client/blob/master/src/Client.php#L1867

Then cycle through the results looking for the MAC address of a device that displays the issues.

from unifi-api-client.

Here's an example of one of the clients that tried to log in multiple times:

[1725] => stdClass Object
    (
        [_id] => 5ad0deabe4b0df9028fbed1a
        [ap_from] => 04:18:d6:80:82:92
        [ap_to] => 04:18:d6:20:77:ec
        [channel] => 149
        [channel_from] => 149
        [channel_to] => 149
        [datetime] => 2018-04-13T16:45:25Z
        [guest] => 00:56:cd:c8:e5:3d
        [key] => EVT_WG_Roam
        [msg] => Guest[00:56:cd:c8:e5:3d] roams from AP[04:18:d6:80:82:92] to AP[04:18:d6:20:77:ec] from "channel 149(na)" to "channel 149(na)" on "CLUB-GUEST"
        [radio] => na
        [radio_from] => na
        [radio_to] => na
        [site_id] => 53fe3af7cb76adad4e7af883
        [ssid] => CLUB-GUEST
        [subsystem] => wlan
        [time] => 1523637925340
    )



[1692] => stdClass Object
    (
        [_id] => 5ad0df02e4b0df9028fbee14
        [ap] => 04:18:d6:20:77:ec
        [channel_from] => 149
        [channel_to] => 11
        [datetime] => 2018-04-13T16:45:43Z
        [guest] => 00:56:cd:c8:e5:3d
        [key] => EVT_WG_RoamRadio
        [msg] => Guest[00:56:cd:c8:e5:3d] roams from "channel 149(na)" to "channel 11(ng)" at AP[04:18:d6:20:77:ec]
        [radio_from] => na
        [radio_to] => ng
        [site_id] => 53fe3af7cb76adad4e7af883
        [subsystem] => wlan
        [time] => 1523637943258
    )



[1536] => stdClass Object
    (
        [_id] => 5ad0e05fe4b0df9028fbf218
        [ap] => 04:18:d6:20:77:ec
        [bytes] => 70521436
        [datetime] => 2018-04-13T16:46:59Z
        [duration] => 865
        [guest] => 00:56:cd:c8:e5:3d
        [hostname] => iSunny
        [key] => EVT_WG_Disconnected
        [msg] => Guest[00:56:cd:c8:e5:3d] disconnected from "CLUB-GUEST" (14m 25s connected, 67.25M bytes, last AP[04:18:d6:20:77:ec])
        [site_id] => 53fe3af7cb76adad4e7af883
        [ssid] => CLUB-GUEST
        [subsystem] => wlan
        [time] => 1523638019000
    )

Here is the mysql log we're keeping of the guest trying to log in (As you can see between 7:45 & 7:46 it didnt work and he had to try twice.:

+---------+---------------------+---------------+-------------------+
| guestid | timestamp | ip | mac_address |
+---------+---------------------+---------------+-------------------+
| 830 | 2018-04-13 09:33:01 | 10.195.21.172 | 00:56:cd:c8:e5:3d |
| 830 | 2018-04-13 07:46:16 | 10.195.21.104 | 00:56:cd:c8:e5:3d |
| 830 | 2018-04-13 07:45:37 | 10.195.21.104 | 00:56:cd:c8:e5:3d |
| 830 | 2018-02-01 06:14:52 | 10.195.21.237 | 00:56:cd:c8:e5:3d |
+---------+---------------------+---------------+-------------------+
4 rows in set (0.00 sec)

from unifi-api-client.

I actually meant the ones with key ‘EVT_AD_GuestAuthorizedFor’, the ones you shared look OK and don’t say much. Also without knowing how you are logging the MySQL data I cannot tell what is going on.

from unifi-api-client.

So in 16 hours you only had two new authorisations? And if 43200 minutes is the duration you are requesting the auth for I see nothing wrong.

This looks some issue unrelated to the API. To rule out the API client class you can always manually auth a guest device through the web UI.

from unifi-api-client.

BTW, I would suggest you remove the link to that file ASAP: it contains MAC addresses which are regarded as personal information here in Europe.

from unifi-api-client.

I had them run the test again to pull out more entries - this was from 30,000 events. At first glance these all look correct but let me know if you see anything

authentication.txt

from unifi-api-client.

Those all look fine to me. I think you have some other issue going on not related to the API. If you are only seeing this in a single site, test with another (sometimes sites that have been migrated get minimal corruptions) site or on another controller. Also check other components which could be blocking access such as firewalls, proxies etc.

from unifi-api-client.

Closing due to lack of feedback

from unifi-api-client.

Hey @malle-pietje,

After this comment, we left it with our customer to reach out to an IT firm (we found it out of scope from the requirements of this project); unfortunately they have not had much luck fixing this. Here is the timeline of what has been accomplished after us:

• Reached out to Unifi Support, they looked into it but ultimately said they couldn’t help us due to the fact that this is a custom portal / landing page
• Engaged Wizard IT to investigate. They suggested to try about 5 different things, we tried all of them, but none of them resolved the issue. Our work with Wizard IT on this is still ongoing
• Coordinated with Stargate (the server company); they advised it’s not a latency issue on their side
• Analyzed WiFi Spectrum, adjusted channels
• Updated the Unifi controller to the latest version
• Moved AP’s from POE injectors to managed switch (Lougheed)
• Various speedtests to / from clubs seem OK
• Monitoring pingtimes from AP’s to Unifi controller; looks OK
• Disabled 2.4 GHz spectrum at some clubs / APs
• Updated the AP’s to the latest version
• Added memory to the Unifi controller ( Currently 8CPU’s / 16Gb of memory)
• Factory reset AP’s and re-associate with the Unifi controller

They have asked us to take another look and see if we can help them move forward. Let me know if you have any other recommendations on what they should try!

Thanks in advance!

from unifi-api-client.

I’m afraid I’ve already provided my suggestions; with two other companies already involved there’s not much I can add from my end.

from unifi-api-client.

Hi sorry to bother you again, we researched this even more and found this:

1. [msg] => Guest[(Guest ID)] has connected to AP[(AP Id)] with ssid "Portal Name" on "channel 36(na)"
2. [msg] => Guest[(Guest ID)] has connected to AP[(AP Id)] with ssid "Portal Name" on "channel 36(na)"
3. [msg] => Guest[(Guest ID)] disconnected from "Portal Name" (22s connected, 0.00 bytes, last AP[(AP Id)])
4. [msg] => Guest[(Guest ID)] is unauthorized by Admin[admin]
5. [msg] => Guest[(Guest ID)] is authorized by Admin[admin] for 43200 minutes
6. [msg] => Guest[(Guest ID)] disconnected from "Portal Name" (2m 31s connected, 2.01M bytes, last AP[(AP Id)]
7. [msg] => Guest[(Guest ID)] has connected to AP[04:18:d6:02:ee:05] with ssid "Portal Name" on "channel 1(ng)"
8. [msg] => Guest[(Guest ID)] roams from AP[04:18:d6:02:ee:05] to AP[(AP Id)] from "channel 1(ng)" to "channel 36(na)" on "Portal Name"
9. [msg] => Guest[(Guest ID)] has connected to AP[(AP Id)] with ssid "Portal Name" on "channel 36(na)"
10. [msg] => Guest[(Guest ID)] has connected to AP[(AP Id)] with ssid "Portal Name" on "channel 36(na)"
11. [msg] => Guest[(Guest ID)] disconnected from "Portal Name" (22s connected, 0.00 bytes, last AP[(AP Id)])
12. [msg] => Guest[(Guest ID)] is unauthorized by Admin[admin]
13. [msg] => Guest[(Guest ID)] is authorized by Admin[admin] for 43200 minutes
14. [msg] => Guest[(Guest ID)] disconnected from "Portal Name" (2m 31s connected, 2.01M bytes, last AP[(AP Id)])
15. [msg] => Guest[(Guest ID)] has connected to AP[04:18:d6:02:ee:05] with ssid "Portal Name" on "channel 1(ng)"
16. [msg] => Guest[(Guest ID)] roams from AP[04:18:d6:02:ee:05] to AP[(AP Id)] from "channel 1(ng)" to "channel 36(na)" on "Portal Name"

As you can see, the same person is connecting and being disconnected shortly after - although the request appears to be correct. Any idea why Unifi would be dropping them so quickly?

from unifi-api-client.

Can you share the exact and full code you are using? Also it would help to have the timestamps for the events.

from unifi-api-client.

Which code are you referring to?

This is pulled from the $unifi->list_events(720, 0, 15000)

I have also attached the authorization code as well.

access.txt

Below are the events with timestamps applied.

1. [datetime] => 2018-09-19T17:01:08Z [msg] => Guest[(GuestID)] has connected to AP[04:18:d6:02:ee:5a] with ssid "GUEST-PORTAL" on "channel 36(na)"
2. [datetime] => 2018-09-19T17:01:08Z [msg] => Guest[(GuestID)] has connected to AP[04:18:d6:02:ee:5a] with ssid "GUEST-PORTAL" on "channel 36(na)"
3. [datetime] => 2018-09-19T17:01:30Z [msg] => Guest[(GuestID)] disconnected from "GUEST-PORTAL" (22s connected, 0.00 bytes, last AP[04:18:d6:02:ee:5a])
4. [datetime] => 2018-09-19T17:02:31Z [msg] => Guest[(GuestID)] is unauthorized by Admin[admin]
5. [datetime] => 2018-09-19T17:02:31Z [msg] => Guest[(GuestID)] is authorized by Admin[admin] for 43200 minutes
6. [datetime] => 2018-09-19T17:03:39Z [msg] => Guest[(GuestID)] disconnected from "GUEST-PORTAL" (2m 31s connected, 2.01M bytes, last AP[04:18:d6:02:ee:5a]
7. [datetime] => 2018-09-19T17:19:36Z [msg] => Guest[(GuestID)] has connected to AP[04:18:d6:02:ee:05] with ssid "GUEST-PORTAL" on "channel 1(ng)"

from unifi-api-client.

Just bumping this again :) thank you!

from unifi-api-client.

Hmm, the “unauthorized” lines are suspicious. Something/someone is executing an unauth command through the UI or API, and that command is not to be found in the code you shared.

Apart from this there’s not much I can do.

from unifi-api-client.