CISCO_ACCOUNTING_HACK
in rlm_sql.c this portion of code is causing problems combined with the "buffered_sql/detail" server. I don't actually use Ciscos but Juniper ERXes and this still happens. nevertheless by returning RLM_MODULE_NOOP it causes the buffered sql home server to try to send the packet for ever resulting in the detail file never being processed. I'm not sure what would be appropriate fix here, the only way to disable this section is to go in src/modules/rlm_sql/conf.h and remove the define manually. Maybe a configure script option would be nice. Or maybe returning RLM_MODULE_OK, but in a sense it wouldn't be true since the module did in fact do nothing. #ifdef CISCO_ACCOUNTING_HACK /* * If stop but zero session length AND no previous * session found, drop it as in invalid packet * This is to fix CISCO's aaa from filling our * table with bogus crap */ if ((pair = pairfind(request->packet->vps, PW_ACCT_SESSION_TIME)) != NULL) acctsessiontime = pair->vp_integer; if (acctsessiontime <= 0) { radius_xlat(logstr, sizeof(logstr), "stop packet with zero session length. [user '%{User-Name}', nas '%{NAS-IP-Address}']", request, NULL); radlog_request(L_ERR, 0, request, "%s", logstr); sql_release_socket(inst, sqlsocket); ret = RLM_MODULE_NOOP; } #endif
hi, you should not hit this issue if your kit os okay. there shouldnt be stops with zero session lengths etc. most of us buffer our SQL accouting stanza with plenty of protecting padding to ensure its only called when conditions are sane... perhaps such a config should be supplied with FreeRADIUS as a default? alan
On 17-Aug-09, at 1:32 PM, Alan Buxey wrote:
you should not hit this issue if your kit os okay.
huh? Not following the above sentence at all.
there shouldnt be stops with zero session lengths etc.
I agree, but it's still technically possible to connect and disconnect within less than 1 second. And well Cisco and Juniper do definitely send Stops with zero session lengths.
most of us buffer our SQL accouting stanza with plenty of protecting padding to ensure its only called when conditions are sane...
perhaps such a config should be supplied with FreeRADIUS as a default?
perhaps. Do you have some kind of example? I don't think it's documented. -Gabriel
Hi,
you should not hit this issue if your kit os okay.
huh? Not following the above sentence at all.
typo: you should not hit this issue if your kit (NAS) is okay
perhaps. Do you have some kind of example? I don't think it's documented.
eg accounting { # Only let accounting be done to detail module if session time is not zero! if (Acct-Session-Time != 0) { detail } else { ok } } the 'ok' is to let accounting carry on with no failure if the session time IS zero alan
On 17-Aug-09, at 1:47 PM, Alan Buxey wrote:
Hi,
you should not hit this issue if your kit os okay.
huh? Not following the above sentence at all.
typo:
you should not hit this issue if your kit (NAS) is okay
Now that makes more sense.
perhaps. Do you have some kind of example? I don't think it's documented.
eg
accounting { # Only let accounting be done to detail module if session time is not zero! if (Acct-Session-Time != 0) { detail } else { ok }
}
the 'ok' is to let accounting carry on with no failure if the session time IS zero
Thanks. Didn't think of that. The issue really wasn't obvious that's really my beef. Since I think I only have maybe one or two Acct-Stops with an Acct- Session-Time of 0. And well, my detail file kept growing and growing without being processed and nothing pointed to it being the problem. Now on another note (not sure If I should create a separate thread about this) in detail.c /* * Cap delay at 4 packets/s. If the end system can't * handle this, then it's very broken. */ if (data->delay_time > (USEC / 4)) data->delay_time= USEC / 4; My (and most) SQL servers are capable of handling more than 4 SQL queries per second. Maybe that setting shouldn't be so static? -Gabriel
Hi,
Now on another note (not sure If I should create a separate thread about this)
in detail.c
/* * Cap delay at 4 packets/s. If the end system can't * handle this, then it's very broken. */ if (data->delay_time > (USEC / 4)) data->delay_time= USEC / 4;
My (and most) SQL servers are capable of handling more than 4 SQL queries per second. Maybe that setting shouldn't be so static?
hmm....perhaps a setting in sql.conf or such? I can see many people setting it to silly values and then complaining..... :-) alan
Gabriel Blanchard wrote:
Now on another note (not sure If I should create a separate thread about this)
in detail.c
/* * Cap delay at 4 packets/s. If the end system can't * handle this, then it's very broken. */ if (data->delay_time > (USEC / 4)) data->delay_time= USEC / 4;
My (and most) SQL servers are capable of handling more than 4 SQL queries per second. Maybe that setting shouldn't be so static?
The delay is inter-packet delay. i.e. time between reading two consecutive packets from the detail file. This code sets the *maximum* delay. It's capped at .25s. The *minimum* delay is whatever your SQL server can handle. Alan DeKok.
On 17-Aug-09, at 7:32 PM, Alan DeKok wrote:
The delay is inter-packet delay. i.e. time between reading two consecutive packets from the detail file.
This code sets the *maximum* delay. It's capped at .25s.
The *minimum* delay is whatever your SQL server can handle.
OK. I did find another problem though. I added some debugging code to confirm this. When you set the load_factor to 100, it caps the delay_time at 1/10th of a second. data->delay_time = (data->srtt * (100 - data->load_factor)) / (data-
load_factor); if (data->delay_time == 0) data->delay_time = USEC / 10;
My debugging code showing the delay time Tue Aug 18 08:19:30 2009 : Info: data->delay_time: 100000 I then set my load_factor to 90, the delay time was far lower. Tue Aug 18 08:21:26 2009 : Info: data->delay_time: 27 Sure setting the load_factor to 100 never is a good idea. But it shouldn't make it slower.
Gabriel Blanchard wrote:
When you set the load_factor to 100, it caps the delay_time at 1/10th of a second.
Ah... that's probably not good.
data->delay_time = (data->srtt * (100 - data->load_factor)) / (data->load_factor); if (data->delay_time == 0) data->delay_time = USEC / 10;
My debugging code showing the delay time Tue Aug 18 08:19:30 2009 : Info: data->delay_time: 100000 ... Sure setting the load_factor to 100 never is a good idea. But it shouldn't make it slower.
I'll see if I can fix it. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
Gabriel Blanchard