Get wireless clients via API

Hallo and welcome to the UTM Community!

The correct syntax at the command line as root is:

cc get_objects awe client

Cheers - Bob

Hallo and welcome to the UTM Community!

The correct syntax at the command line as root is:

cc get_objects awe client

Cheers - Bob

Hi BAlfson,

thank for your reply, but this is basically the same of what I tried and described - and so is the result :) 'get_wireless_status' is the one that is working (and the one that I'm using now). Everything else results in any empty list. I agree with you: The command SHOULD return the clients, but it does not - for me, this looks like a bug.

Cheers

Daniel

I don't think it's a bug, Daniel - it's always worked fine for me on multiple clients' UTMs.  In order to debug this issue, you would need to post the entries and responses at the command line after becoming root.

Cheers - Bob

hm... ok, I checked a few customer devices

All devices are running Wireless Protection with AP and/or APX series accesspoints. On 3 out of 7, it worked. All of the other devices returned an empty list. When it works, the REST Interface also returns data. 'get_wireless_status' works on 7 out of 7. Please see the (non working) output below:

1) Non-Interactive (using your command)
=======================================
sophos-sg:/root # cc get_objects awe client
[]

2) Curl on API
==============

curl -X GET --header 'Accept: application/json' --header 'Authorization: Basic xxxxxxxxxxxxxxx' 'sophos-sg:4444/.../'

Response Body
[]

Response Code
200

3) Non Interactive using get_wireless_status:
==============================================

sophos-sg:/root # cc get_wireless_status
{
'clients' => {
'xx:xx:xx:xx:xx:xx' => {
'ap' => 'A40000000000000',
'connected_time_sec' => 222261,
'connected_time_str' => '02:13:44:21',
'hwaddr' => 'xx:xx:xx:xx:xx:xx',
'ip' => '192.168.21.209',
'last_rxrate_bps' => 75706368,
'last_rxrate_str' => '72.2 Mbit/s',
'last_txrate_bps' => 68157440,
'last_txrate_str' => '65.0 Mbit/s',
'lastseen_str' => '2020-11-11 19:58:14',
'lastseen_ts' => '1605121094',
'mesh_id' => '',
'mesh_mode' => 'none',
'name' => 'somename',
'radio_id' => 0,
'signal_per' => 68,
'ssid' => 'myssid',
'vendor' => 'somevendor'
},
'yy:yy:yy:yy:yy:yy' => {

[ .. more output .. ]

So I stick with 'its a bug' but there must be some sort of condition that triggers it.

The first thing that came into my mind was the software version, but that does not seem to be true:

SG115, single, 9.705-3: not working
SG125, single, 9.605-1: working
SG230, cluster, 9.705-3: working
SG210, cluster, 9.702-1: not working
SG310, cluster, 9.705-3: not working
SG310, cluster, 9.702-1: working
SG430, cluster, 9.702-1: not working

Cheers
Daniel

Hallo Daniel,

I agree, there's something strange going on.  I bet the developers would like to see this case - have you opened one with Support?  Please let us know what you learn.

Cheers - Bob

Hi Daniel,

i have the same issue. Do you have a solution already?

Best Regards,
Jochen

Hi Jochen,

no, I don't have a solution for this. What I did was writing my own webservice that executes cc commands via remote ssh connection to the SG. Not the coolest solution but I works...

Regards,

Daniel