Some fields isn't updated in 'radmin> stats home_server acct'

[jpereira]

Hi,

I noticed that always when i receive the message

Fri Oct 23 05:25:42 2015 : ERROR: (463) ERROR: Failing proxied request for user "ec:88:92:86:06:12", due to lack of any response from home server 10.1.2.4 port 1

The field 'invalid or malformed' isn't updated in "radmin stats".

# radmin
radmin> stats home_server acct
requests        865
responses       857
dup             0
invalid         0
malformed       0
bad_authenticator       0
dropped         0
unknown_types   0
timeouts        0
last_packet     1445578085
elapsed.1us     0
elapsed.10us    0
elapsed.100us   0
elapsed.1ms     853
elapsed.10ms    62
elapsed.100ms   1
elapsed.1s      0
elapsed.10s     0
#

[arr2036]

Why would you expect it to be?

[jpereira]

@arr2036 It is helpful to collect metrics about "which" home_server has X invalid/... packets. And if something wrong happens... Like timeout/invalid/... during the Proxy over home_server.... I think that is necessary to increase some field.

Or we can add a new field like "failed". What do you think?

[jpereira]

In my example you can notice that has a gap between requests and response. so, (requests - responses) = X, In this case X will be "failed"

requests        865
responses       857
dup             0
invalid         0
malformed       0
bad_authenticator       0
dropped         0
unknown_types   0
timeouts        0

After check the code, I noticed that would be better to add a new field "failed".

[alandekok]

On Oct 23, 2015, at 1:30 AM, Jorge Pereira notifications@github.com wrote:

Hi,

I noticed that always when i receive the message

Fri Oct 23 05:25:42 2015 : ERROR: (463) ERROR: Failing proxied request for user "ec:88:92:86:06:12", due to lack of any response from home server 10.1.2.4 port 1

The field 'invalid or malformed' isn't updated in "radmin stats".

Because those fields have pre-defined meaning. And timeout isn't part of their meaning.

The "elapsed" fields are defined by FreeRADIUS

See the RADIUS MIB RFCs for definitions of the rest of the fields.

radmin

radmin> stats home_server acct
requests 865
responses 857
dup 0
invalid 0
malformed 0
bad_authenticator 0
dropped 0
unknown_types 0
timeouts 0
last_packet 1445578085
elapsed.1us 0
elapsed.10us 0
elapsed.100us 0
elapsed.1ms 853
elapsed.10ms 62
elapsed.100ms 1
elapsed.1s 0
elapsed.10s 0

—
Reply to this email directly or view it on GitHub.

[jpereira]

@alandekok I know about "elapsed.*", I said about handle the stats isn't count the error packets like:

Fri Oct 23 05:25:42 2015 : ERROR: (463) ERROR: Failing proxied request for user "ec:88:92:86:06:12", due to lack of any response from home server 10.1.2.4 port 1

You can notice that related to ACCT

  [-] Status Home-Server para: acct
requests        83525
responses       57782
dup             0
invalid         0
malformed       0
bad_authenticator       0
dropped         0
unknown_types   0
timeouts        0
last_packet     1445601846
elapsed.1us     0
elapsed.10us    0
elapsed.100us   0
elapsed.1ms     17161
elapsed.10ms    40781
elapsed.100ms   305
elapsed.1s      0
elapsed.10s     0

exist a gap between 83525 and 57782. But isn't counted by no field.

[alanbuxey]

errm, but your events are not error packets. they are not invalid packets.
they are a different thing altogether. the counters ARE working
correctly...you want counters for something else
entirely. your error message doesnt mean its invalid, error, unknown_type
or dropped. you;ve got a dodgy remote RADIUS server thus a new counter
needed 'no response' perhaps?

On 23 October 2015 at 13:08, Jorge Pereira notifications@github.com wrote:

@alandekok https://github.com/alandekok I know about "elapsed.*", I
said about handle the stats isn't count the error packets like:

Fri Oct 23 05:25:42 2015 : ERROR: (463) ERROR: Failing proxied request for user "ec:88:92:86:06:12", due to lack of any response from home server 10.1.2.4 port 1

You can notice that

[-] Status Home-Server para: acct
requests 83525
responses 57782
dup 0
invalid 0
malformed 0
bad_authenticator 0
dropped 0
unknown_types 0
timeouts 0
last_packet 1445601846
elapsed.1us 0
elapsed.10us 0
elapsed.100us 0
elapsed.1ms 17161
elapsed.10ms 40781
elapsed.100ms 305
elapsed.1s 0
elapsed.10s 0

exist a gap between 83525 and 57782. But isn't counted by no field.

—
Reply to this email directly or view it on GitHub
#1339 (comment)
.

[jpereira]

I agree with you @alanbuxey! make sense! @alandekok and @arr2036, what do you think?

What we can do about the "Proxy .* due lack packets"? Increase the current "timeout"?
We can add a new field? I believe that "no_response" sounds good! agree?

btw, I made in my repo!

[alandekok]

The "lack of response" message increments the "timeouts" field. See the code in process.c

[alandekok]

https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/src/main/process.c#L3924

[jpereira]

@alandekok ok, but maybe we have a bug. check the below output and notice that exist a gap between request x response. should be the timeouts?

  [-] Status Home-Server para: acct
requests        83525
responses       57782
dup             0
invalid         0
malformed       0
bad_authenticator       0
dropped         0
unknown_types   0
timeouts        0
last_packet     1445601846
elapsed.1us     0
elapsed.10us    0
elapsed.100us   0
elapsed.1ms     17161
elapsed.10ms    40781
elapsed.100ms   305
elapsed.1s      0
elapsed.10s     0

[jpereira]

I found the

[jpereira@jpereira-desktop freeradius-server.git]$ grep "proxy_.*_stats" src/include/stats.h
extern fr_stats_t       proxy_auth_stats;
extern fr_stats_t       proxy_acct_stats;
extern fr_stats_t       proxy_coa_stats;
extern fr_stats_t       proxy_dsc_stats;
[jpereira@jpereira-desktop freeradius-server.git]$

@alandekok This case will be a new section in "radmin" to print the "stats proxy". agree?

[alandekok]

Yes, the timeouts should be printed.

[alandekok]

Nice! I will push the "proxy" print.

Done.

[jpereira]

@alandekok I found another issue, I fixed in #1343

[jpereira]

@alandekok I found another issue.... more critical! #1346

[jpereira]

I checked about the numbers, and now after our fixes. It's completely correct! nice job! :)