Radius Integration Problem

[iesreza]

Environment:

• ntopng edge v.6.3.240904 (Ubuntu 20.04.6 LTS)

What happened:
We noticed several issues with NTOPNG integration with RADIUS.
1- NTOPNG disconnects the users and change the group into captivepass after about 30 minutes of inactivity. This behaviour happens when the user is still present on the network but does not do any internet traffic. we already asked to remove auto disconnect in #8728

2- We have introduced a radius proxy to fill the consumption tracking gap regarding to #8706 and during integration we have noticed NTOPNG reports wrong pool (group) for some devices while do Interim Update on radius.
In the provided example the user pool is gnvcrewstar while in the packet as provided marked as captivepass.

MAC stats API response:

#/lua/mac_stats.lua?ifid=0&host=46%3A54%3ADB%3A7A%3A8B%3AEF

{"dhcp.rcvd":0,"num_hosts":1,"dhcp.sent":0,"devtype":0,"arp_requests.sent":0,"packets.rcvd":94491386804.0,"bytes.rcvd":2375207182,"location":"lan","bytes.ndpi.unknown":0,"seen.last":1727266389,"throughput_trend_bps":1,"throughput_pps":103.52180480957,"pool":7,"fingerprint":"","throughput_trend_pps":1,"packets.sent":98785415790.0,"mac":"46:54:DB:7A:8B:EF","arp_replies.sent":0,"special_mac":false,"bytes.sent.anomaly_index":37,"packets.sent.anomaly_index":33,"packets.rcvd.anomaly_index":33,"bytes.rcvd.anomaly_index":64,"flows.dropped":114416,"arp_replies.rcvd":0,"source_mac":true,"throughput_bps":121767.9609375,"duration":78283,"arp_requests.rcvd":0,"bytes.sent":498405083,"seen.first":1727188107,"bridge_seen_iface_id":2}

Radius Recieved Packet:

#Interim update: Username:captivepass MAC:46:54:DB:7A:8B:EF IP:10.1.0.71 Input:2311503 Output:486658 SessionTime:80109

04a50090f9c4fcc43cc50d943fbfb697d4c2bbc7280600000003010d63617074697665706173732c1432393737343630383335343637333335333708060a0100471f1334363a35343a44423a37413a38423a454657066e663a30050600000000370666f3fdd92f0600200a2030060011d08b2a060023454f2b0600076d022e06000138ed29060000000004067f000001

3- Changing the pool (group) from dashboard does not trigger any RADIUS accounting request.

[lucaderi]

Hi @iesreza, next time please open individual tickets if possible.

1. If you are using one of the latest dev versions (Sept builds are ok) you can find a preference that allows you to set the cache duration for MAC addresses. As you can see it is honoured in the picture
   
   

2. In radius messages the username is not the pool name. Please explain

3. With /lua/rest/v2/set/pool/members.lua you trigger the radius start (connectivity = start) and stop (connectivity = reject). Changing a pool does not affect radius as they are two unrelated things. If this is what you need a start/reject message is required

[iesreza]

Hi @iesreza, next time please open individual tickets if possible.

1. If you are using one of the latest dev versions (Sept builds are ok) you can find a preference that allows you to set the cache duration for MAC addresses. As you can see it is honoured in the picture
   
   
2. In radius messages the username is not the pool name. Please explain
3. With /lua/rest/v2/set/pool/members.lua you trigger the radius start (connectivity = start) and stop (connectivity = reject). Changing a pool does not affect radius as they are two unrelated things. If this is what you need a start/reject message is required

Hi @lucaderi, regarding to above:
1- About cache settings, we have applied 1 hour cache for Local Host Idle Timeout and Local Hosts Cache Duration, Active Local Hosts Cache and Mac Address Cache Duration and still after 30 minutes we face disconnection in case the device does not do traffic.

2- It was my mistake in explnation, you are right. However in case of a logged in user instead of recieving username inside Interim Update message, we recieve captivepass as i explained above. note the user is already authenticated via following api:

data := map[string]interface{}{
"associations": map[string]interface{}{
	lease.MacAddress: map[string]interface{}{
		"group":        pool,
		"connectivity": "pass",
		"username":     username,
		"password":     password,
	},
},
}

resp, err := curl.Post( settings.NTOPNG.BasePath+"/lua/rest/v2/set/pool/members.lua", curl.BodyJSON(data), curl.BasicAuth{
    Username: settings.NTOPNG.Username, Password: settings.NTOPNG.Password,
})

3- About third request i try to explain the case: Rarely it is possible throgh the dashboard the group of user get changed to captivepass. in this case user will lose connectivity and we have no way to track and sync between radius and ntopng. so one solution could be having accounting or CoA message in case of change in group so we can align both radius and ntopng. However at the moment we achievied same result by priodically prompting host info.

[lucaderi]

As of 1. Can you please check if the MAC address corresponding to the host is still in ntopng's memory?

[iesreza]

With the latest version of ntop, we are currently testing the disconnect issue. Since reproducing the problem and completing the test takes some time, we can skip disconnect issue for now. If the issue persists, I will open a separate ticket.

Regarding the incorrect username in the interim update, I have attached the request to nedge along with another example of an Interim Update.

Assign user to group:

POST /lua/rest/v2/set/pool/members.lua HTTP/1.1
Host: 127.0.0.1:3000
User-Agent: Go-http-client/1.1
Content-Length: 136
Authorization: Basic YWRtaW46aWVzaXRhbGlhMjAyMA==
Content-Type: application/json; charset=UTF-8
Cookie: session_3000_0=; session_3000_0=
Accept-Encoding: gzip
{"associations":{"0E:F5:5F:BC:96:A1":{"connectivity":"pass","group":"gnvstarplus","password":"924202105446","username":"924202105446"}}}
=================================
HTTP/1.1 200 OK
Connection: close
Access-Control-Allow-Methods: GET, POST, HEAD
Access-Control-Allow-Origin: *
Cache-Control: max-age=0, no-cache, no-store
Content-Type: application/json
Last-Modified: Fri, 09 September 2024 12:38:16 GMT
Pragma: no-cache
Server: ntopng 6.3.240904 [Ubuntu 20.04.6 LTS [x86_64]]
Set-Cookie: tzname=CET; path=/ HttpOnly; SameSite=lax
Set-Cookie: session_3000_0=; max-age=3600; path=/;  HttpOnly; SameSite=lax
Set-Cookie: timezone=-3600; path=/ HttpOnly; SameSite=lax
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
{"rsp":{"associations":{"0E:F5:5F:BC:96:A1":{"password":"924202105446","status":"OK","connectivity":"pass","group":"gnvstarplus","username":"924202105446"}}},"rc_str":"OK","rc":0,"rc_str_hr":"Success"}

Interim Update Packet:

Interim update: Username:captivepass MAC:0E:F5:5F:BC:96:A1 IP:10.1.0.50 Input:268 Output:126 SessionTime:22
041d00908f1b296e5bf4abd271499bb2eea5b6d9280600000003010d63617074697665706173732c1432353334383038353131333136383436383008060a0100321f1330453a46353a35463a42433a39363a413157066e663a30050600000000370666f6a74e2f06000001a93006000001ff2a060000010c2b060000007e2e060000001629060000000004067f000001

[lucaderi]

Hi @iesreza it looks like the group and the username are swapped in the interim update. We have just checked the code and we didn't find a swap between the two.

• here https://github.com/ntop/ntopng/blob/dev/scripts/lua/rest/v2/set/pool/members.lua#L92 we received the start and in https://github.com/ntop/ntopng/blob/dev/scripts/lua/modules/radius_handler.lua#L82 we save data when start is received
• here https://github.com/ntop/ntopng/blob/dev/scripts/callbacks/minute-delayed/system/radius_accounting.lua#L40 we send the interim update reading the above data

We have made some tests as follows

• curl -u admin:admin1 -H "Content-Type: application/json" -d '{"associations": {"AC:1F:6B:AD:6A:2D" : {"group" : "captivepass", "connectivity" : "pass", "username" : "904945985341", "password" : "9049459
  85341"}}}' http://192.168.2.225:3000/lua/rest/v2/set/pool/members.lua

• curl -u admin:admin1 -H "Content-Type: application/json" -d '{"associations": {"B8:27:EB:4D:44:C8" : {"group" : "captivepass", "connectivity" : "pass", "username" : "904945985341", "password" : "904945985341"}}}' http://192.168.2.225:3000/lua/rest/v2/set/pool/members.lua

And data seems to be correct

• 
• 

As you are calling members.lua we would like you to double-check from your end if the parameters are correct and the data in redis is written properly as shown above. Can you please do this and report?

[MatteoBiscosi]

The issue seems fixed as of now.