OC200 don't refresh the list of users or show obsolete state of connection.
OC200 don't refresh the list of users or show obsolete state of connection.
My OC200 don't refresh users list correctly.
I need to use the reconnect device to be able to see if the device is still connected or moved out from the EAP Wifi connection.
Some users can be showed connected during days if I don't do this trick to verify if there are really still there.
I got actualy 7 remote Site & 1 local site managed by the OC200
there is a total of 34 EAP managed and approximatly max 200 users connected to the eap's park.
according the specification from OC200, I'm far from the limitation of the maximum amount of devices and users that can andle the OC200.
Is there a way to analyse the charge CPU & RAM in use with the OC200 ?
anyone meet the same issue than me ?
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Already discussed here: https://community.tp-link.com/en/business/forum/topic/198546
Please post the Connection History of a device for which you think it's not being automatically disconnected/de-listed.
For me it works perfectly as you can see below for a small hotel:
Status 17:00, 3 users total:
- First device is a stationary WiFi router (SOHO device) connected as a client to an EAP. The router serves as an AP for a single guest room in an annex. When re-connecting this WiFi router manually, it will re-appear again several minutes later in the user list.
Usually its active time equals the uptime of the whole system. - Second device is an iPad used by employees of the hotel. Its WiFi adapter is enabled for the whole work day.
- Third device is a Samsung smartphone from a hotel guest who did connect just 10 minutes before.
Status 17:50, 5 users total:
- The three users mentioned above and two new users (hotel guests) with iPhones, almost certainly just returning from work to the hotel.
Status 18:48, 2 users total:
- Only the stationary WiFi router and the employee's iPad are connected. Hotel guests are out for dinner.
- Their devices disappeared from the user list automatically, no manual intervention needed.
Maybe there is a setting which triggers a bug. But then you need to provide more information such as the OC200 setup, screenshots of the devices in question, trace of those devices in Insight logs, etc.
- Copy Link
- Report Inappropriate Content
Seems I can reproduce this issue.
I've never seen this before, but I've upgraded the firmware of my 245v3 and 225v1-Outdoor over the weekend to the latest available version.
Now I see clients still connected even when they left over a day ago.
- Copy Link
- Report Inappropriate Content
I use the software controller (3.2.6) and
- Copy Link
- Report Inappropriate Content
ASCII wrote
I use the software controller (3.2.6) and
EAP225-Outdoor(EU) 1.0 : 1.7.0 Build 20200113 Rel. 35383EAP245(EU) 3.0 : 2.4.0 Build 20200117 Rel. 39932
This is the important information, thank you! My observations are for OC v 3.2.6 and firmwares EAP225 v2.6.1 and EAP225-OD v1.6.1 only.
Maybe v1.7.0 introduced a new bug.
- Copy Link
- Report Inappropriate Content
I use the OC200 (3.0.4) and
EAP225-Outdoor(EU) 1.0 : 1.6.0 Build 20190722 Rel. 63596
EAP225-Wall(EU) 2.0 : 1.3.1 Build 20191022 Rel. 41502
EAP245(EU) 3.0 : 2.3.0 Build 20190731 Rel. 51932
EAP330(EU) 2.0 :1.4.0 Build 20180925 Rel. 37155
and I don't see how a screenshot of list of users will give you more info about the issue but in Insight yes.
Hre you will see a phone that was out of the site all day yesterday, but we see him into the insight log as connected during 10h 15m 19s
In fact this phone went out of the site at 2020-03-09 07:13:58 and came back at 17:45:08
Other question, the phone was there and connected all the night starting 2020-03-08 17:24:02 till 03-09 07:13:58...why we got only 5m 2s of duration con ?
and I can tell you that this phone was using app like messenger, facebook, whatsapp and push email all the night....then no sleeping mode for him.
same for this last night between 03-09 and 03-01, again only few minutes, but the phone was connected during all the night.
- Copy Link
- Report Inappropriate Content
Do you mean when the clients disconnect from the EAP, and after a long time, these clients still exist on the Controller page?
We had a test in our lab but we can not reproduce this issue, we are still not sure if this is a bug, but we will try to help you with your issue.
Please make sure these clients are truly disconnected from the AP.
(Note: Within 5 minutes of client disconnection, we can still see the information of these clients. After 5 minutes later, they will disappear from the Controller page.)
If you try to reboot the EAP, do the clients still exist on the Controller? Can you ping these clients successfully on the Omada Controller?
- Copy Link
- Report Inappropriate Content
Hi @Pascal,
sorry, I didn't expect a release of a new firmware for EAP225-OD so fast, so I missed to ask you in first place what firmware versions you are running. I probably can make tests with the new firmware next days, but are currently very busy with a new software project, so no promises about the exact date.
As for the Connection History IMO it shows valid values according to time stamps and duration for most of the time ranges, but I can't tell you why the phone was connected only 5m during the night between 03/08 and 03/09.
I know from our customer's complaints, that guests sometimes connect to a WiFi, but then the phone falls back to the cellular network, e.g. if the WiFi signal quality is getting weaker – this seems to happen often with iPhones when the user is moving around and/or covering the iPhone's »antenna« (the metal strap). Maybe such a fall-back from WiFi to cellular on the Samsung was the reason that there is no longer duration shown for the whole night? Could it be?
Regarding the first 5m period at 2020/03/08 17:24:02 this looks like band steering between the 2.4 GHz and 5 GHz radio to me, which counts as two connections.
Anyway, I would like add to your feature request for a graph of current CPU/memory load of Omada controller another feature request to show connect/disconnect timestamps in the client Connection History rather then just the disconnect timestamp.
@forrest, what do you think about showing connect/disconnect timestamps in Connection History for better readability?
There is also a feature request from this gentleman here: https://community.tp-link.com/en/business/forum/topic/198546?replyId=416904
- Copy Link
- Report Inappropriate Content
@forrest, what do you think about showing connect/disconnect timestamps in Connection History for better readability?
There is also a feature request from this gentleman here: https://community.tp-link.com/en/business/forum/topic/198546?replyId=416904
From the connection history, we can see the duration time of the connection, it is the same as the timestamps, and it is better to know the duration time of the clients, so we may not change this feature these days.
- Copy Link
- Report Inappropriate Content
@forrest, ok, then I will do it on the command line. It even has the advantage that I can process the data further, e.g. to create fancy graphs.
This is my script »clientHist«, find it attached to this post for download or copy/paste it between the snips.
Run it on the same server on which Omada controller is running.
Usage is: ./clientHist [site [macaddr]]
[Update: bug fix – if you downloaded before Fri, 2020-03-13, correct the line colored red below or download the attached script again.]
------------------ snip ------------------
#!/bin/sh
TZDIFF=1 # timezone correction - too lazy to fiddle with UTC ISODate in mongodb
case $# in
0) query='' ;;
1) query="site: '$1'" ;;
2) query="\$and: [ { site: '$1' }, { clientMac: '$2' } ]" ;;
*) echo "Usage: ${0##*/} [site [macaddr]]"; exit 1 ;;
esac
mongo --port 27217 tpeap --eval "
db.clienthistory.find(
{ $query },
{ clientMac: 1,
lastSeen: 1,
duration: 1,
_id: 0
}
).sort({ lastSeen: -1 }).forEach(function(doc) {
doc.firstSeen = new Date(doc.lastSeen.valueOf() + ($TZDIFF * 3600000) - (doc.duration*1000));
doc.lastSeen = new Date(doc.lastSeen.valueOf() + ($TZDIFF * 3600000));
doc.duration = NumberInt(doc.duration/3600)+'h'+NumberInt((doc.duration%3600)/60)+'m'+(doc.duration%60)+'s';
print(tojson(doc));
}
);"
------------------ snip ------------------
Proof: this is the GUI output for site »Mesh-Test« (MAC address anonymized):
This is the output from the script for site »Mesh-Test« (again MAC address anonymized, output shortened):
$ ./clientHist Vh0vdg5h 00-17-F2-XX-YY-ZZ
MongoDB shell version: 2.4.10
connecting to: 127.0.0.1:27217/tpeap
{
"clientMac" : "00-17-F2-XX-YY-ZZ",
"duration" : "0h0m49s",
"lastSeen" : ISODate("2020-02-14T15:47:38.519Z"),
"firstSeen" : ISODate("2020-02-14T15:46:49.519Z")
}
{
"clientMac" : "00-17-F2-XX-YY-ZZ",
"duration" : "0h53m38s",
"lastSeen" : ISODate("2020-02-13T15:36:04.792Z"),
"firstSeen" : ISODate("2020-02-13T14:42:26.792Z")
}
{
"clientMac" : "00-17-F2-XX-YY-ZZ",
"duration" : "1h28m39s",
"lastSeen" : ISODate("2020-02-10T12:12:01.129Z"),
"firstSeen" : ISODate("2020-02-10T10:43:22.129Z")
}
...
{
"clientMac" : "00-17-F2-XX-YY-ZZ",
"duration" : "0h6m40s",
"lastSeen" : ISODate("2019-12-30T17:13:09.814Z"),
"firstSeen" : ISODate("2019-12-30T17:06:29.814Z")
}
If you want to narrow down the results by specifying site and MAC address, you need to manually find out the sitename identifier if it is not the »Default« site. I was too lazy to implement this query in the script. If someone has more time, feel free to do include this:
$ mongo --port 27217 tpeap
MongoDB shell version: 2.4.10
connecting to: 127.0.0.1:27217/tpeap
> db.site.find().forEach(printjson);
{
"_id" : ObjectId("5cf7cd47d4ee23b6eae44446"),
"_class" : "com.tp_link.eap.domain.site.Site",
"name" : "Default",
"siteName" : "Default",
"systemDefault" : true
}
{
"_id" : ObjectId("5cf7cd47d4ee23b6eae44447"),
"_class" : "com.tp_link.eap.domain.site.Site",
"name" : "Mesh-Test",
"siteName" : "Vh0vdg5h",
"systemDefault" : false
}
> ^D
bye
$
- Copy Link
- Report Inappropriate Content
Hi @Pascal,
today I updated an EAP225 to firmware 2.7.0 and did run tests. Could not reproduce the effect you are seeing of absent clients not listed as disconnected.
Checked this with two iPhones, a Nexus 7 tablet and a MacBook. No matter whether WiFi is being disabled, Airplane mode is turned on or the network is marked forgotten, there is always a disconnected record in Omada controller appearing ~5 min. after the device did disconnect.
Tested with both, an OC200 and SW controller, made no difference, no clients left over.
Below is the log of the SW controller made with my clientHist script (MAC addresses replaced by names for anonymization).
I started the test at 14:37, disconnected the MacBook at 14:49, disconnected the (then sleeping) iPhones at ~15:35 / 15:36, reconnected the MacBook at 15:34, disconnected the Nexus at 15:44, disconnected the MacBook at 16:05, reconnected it at 16:26 and put it to sleep at 16:38.
Then I did wait for 7 minutes before I did wake up the MacBook again to check whether it had been disconnected (yes). But now it did not reconnect to the testing SSID, instead it connected to my standard network's SSID, so it did not re-appear again in the list below.
Reported values are equal to the web UI's connection history of each device:
Client Duration Connected Disconnected
MacBook 0h12m13s 2020-03-13 16:26:41 2020-03-13 16:38:54
MacBook 0h30m50s 2020-03-13 15:34:31 2020-03-13 16:05:21
Nexus 7 1h4m3s 2020-03-13 14:40:30 2020-03-13 15:44:33
iPhone4 0h57m50s 2020-03-13 14:38:30 2020-03-13 15:36:20
iPhone6 0h57m40s 2020-03-13 14:37:19 2020-03-13 15:34:59
MacBook 0h12m13s 2020-03-13 14:37:09 2020-03-13 14:49:22
I don't claim that there might be no buggy behavior with your particular controller settings, I just say that with a freshly set up test site in Omada controller I couldn't reproduce a buggy behavior of firmware v2.7.0 regarding absent clients not being shown as disconnected.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 3437
Replies: 11
Voters 0
No one has voted for it yet.