03-04-2019 03:00 PM
What does this experience feature contribute to the controller?
It is not accurate, shows poort performance but in realtime the network is good.
When is the new firmware releases for the AP'S that fixes all of this?
03-05-2019 11:32 AM
I'm also getting reports from clients reporting poor connectivity - they are apparently having lots of issues, having to reboot devices in order to get them to connect.
I'm seeing devices connected but with self assigned IP's, these problems are on sites that never previously had any issues.
I'm running controller 5.10.17 on a VPS with around 600-700 AP's mostly running F/W 4.021.9965
03-06-2019 12:06 PM
I sort by signal strength when I look for connectivity issues, not this (at present) unexplained and undocumented "WiFi Experience" feature. I have found the best way to deal with this is to disable the column completely until Ubiquiti fixes the problem.
03-07-2019 05:16 AM
I have the same problem... bunch of Shelly1 WiFi relays working great on 2.4Mhz, but wifi experience is 0%, so I have average experience of 33%.
I haven't tried new controller update 5.10.19 though, because I had problems updating to 5.10.17 (devices wouldn't adopt) and want to make sure it is fixed before updating again.
03-07-2019 03:04 PM
I'm testing beta firmware 188.8.131.5210 on a few access points to see if it resolves the issues we're seeing. I've put it on a few AP's today and am awaiting feedback from the end users.
Upgraded an in-wall remotely earlier where the customer could connect phone but not two iPads, he could connect immediately after f/w upgrade.
I'm also seeing problems with Macs.
I'm not prepared to roll this firmware out to around 700 Ap's before I'm completely convinced it's going to sort all the problems though. Would be much nicer to have a confirmed stable firmware release addressing the issues so we could run a rolling upgrade across all of our sites.
Currently I can't show a customer the dashboard showing rubbish WiFi experience, especially on sites that were working perfectly before the "upgrade"
03-08-2019 03:30 AM
Fun Fact here: 0% wifi experience with "DHCP Timeout", but when I (win10) release and review the lease, I get a propper IP from my USG4p. Apers only on one client...
5.10.19 on docker
03-11-2019 07:42 AM
I found this on reddit
"So we are having some luck by changing settings->wireless networks->affected network (edit)->802.11 rate and beacon -> uncheck "DTIM use default values" and setting it from 1 to 3. We are investigating now WHY this is fixing the problem, but some people are claiming that this was modified a few versions back from 3 to 1 and it has to do with the network card going to sleep even when in use."
I havn't tried it yet to see if it helps.
03-11-2019 08:21 AM
BTW _ I know nothing about the setting but have read this
- A delivery traffic indication map is a kind of traffic indication map (TIM) which informs the clients about the presence of buffered multicast/broadcast data on the access point. It is generated within the periodic beacon at a frequency specified by the DTIM Interval. Beacons are packets sent by an access point to synchronize a wireless network. Normal TIMs that are present in every beacon are for signaling the presence of buffered unicast data. After a DTIM, the access point will send the multicast/broadcast data on the channel following the normal channel access rules (CSMA/CA). This helps to have minimum collision and in effect, increased throughput. In cases where there is not much interference, or where the number of clients is limited, the DTIM interval has little or no significance. Usually a value of 1 or 2. Also see Wi-Fi as established by the Wi-Fi Alliance.
- The higher the DTIM period, the longer a client device may sleep and therefore the more power that a particular client device may potentially save.
- When the DTIM period is 2, a client device in power-save mode will awaken to receive every other beacon fram
- Client devices in wireless networks may have conflicting requirements for power consumption and communication throughput when in power-save mode. For example, laptop computers may require relatively high communication throughput and may have low sensitivity to power consumption. Therefore, a relatively low DTIM period, for example 1, may be suitable for these devices. Pocket devices, however, may require relatively low communication throughput and may be operated by batteries of relatively low capacity. Therefore, a higher DTIM period, for example 8, may be suitable for pocket devices.
Am I reading this correct:
- The lower the DTIM setting the higher the DTIM rate (ie 1 = 1 DTIM for 1 AP Beacon and; 2 = 1 DTIM for every 2 Beacons = half beacon rate, etc...)
- The more DTIM's/Beacon, the more constant multicast/broadcast traffic on a network?
- The higher the DTIM setting, the more memory consumed (more broadcast/multicast packet buffering) on the APs?
Has anyone tried this? What about setting 2, instead of 3?
03-12-2019 01:54 AM
I'm from Austria and have the same issues.
I have do the update from 184.108.40.206 to 220.127.116.11 and the same problems with the Wifi Clients "Please check that your DHCP server is accessible and properly configured" ...
It's possible to make a downgrade?