Accounting multicast + unacknowledge mode and conflicting packet
I think that's what FreeRADIUS does. The log indicates ... Error: Received conflicting packet from client ... Giving up on old request. And in the source code of FreeRADIUS (process.c: 1765) we have request_done (request, FR_ACTION_CANCELLED); which cancels the old conflicting accounting and then retains only the new It would be interesting to have at least more information about the canceled accounting because in the log we just have the Radius client, its port and the Radius packet ID. See line 1776 in process.c ERROR ("Received conflicting packet from" "client% s port% d - ID:% u due to" "unfinished request in module% s. Giving up on old request.", client-> shortname, packet-> src_port, packet-> id, old_module); In addition I do not know if the canceled accounting is in the accounting logs. There is too little information to possibly make a corrective post-processing of this cancellation
On Apr 22, 2019, at 10:21 AM, François RAGUIN <fraguin@wanadoo.fr> wrote:
I think that's what FreeRADIUS does.
As the main author, yes, that *is* what it does. I'm not lying to you.
The log indicates ... Error: Received conflicting packet from client ... Giving up on old request. And in the source code of FreeRADIUS (process.c: 1765) we have request_done (request, FR_ACTION_CANCELLED); which cancels the old conflicting accounting and then retains only the new
It would be interesting to have at least more information about the canceled accounting because in the log we just have the Radius client, its port and the Radius packet ID.
That's the available information. What else do you want?
See line 1776 in process.c ERROR ("Received conflicting packet from" "client% s port% d - ID:% u due to" "unfinished request in module% s. Giving up on old request.", client-> shortname, packet-> src_port, packet-> id, old_module); In addition I do not know if the canceled accounting is in the accounting logs.
Exactly.
There is too little information to possibly make a corrective post-processing of this cancellation
Perhaps I was unclear. There is *no way* to do any "corrective post-processing". What you want is impossible. a) add more capacity to the FR + DB system, so it can handle the load b) change the FR source code to allow these conflicting packets, with some unknown other side-effects. Those are your choices. Alan DeKok.
I was thinking of post-processing in downstream applications that consume Radius accouting. The problems are very punctual in percentage, but we are investigating the performance of the database and the GGSN to open more source ports. It would have been interesting, however, to have the following information in the "Received conflicting packet" logs: Acct-Status-Type, User-Name, and Framed-IP-Address
Message du 22/04/19 16:27 De : "Alan DeKok" A : "François RAGUIN" , "FreeRadius users mailing list" Copie à : Objet : Re: Accounting multicast + unacknowledge mode and conflicting packet
On Apr 22, 2019, at 10:21 AM, François RAGUIN wrote:
I think that's what FreeRADIUS does.
As the main author, yes, that *is* what it does. I'm not lying to you.
The log indicates ... Error: Received conflicting packet from client ... Giving up on old request. And in the source code of FreeRADIUS (process.c: 1765) we have request_done (request, FR_ACTION_CANCELLED); which cancels the old conflicting accounting and then retains only the new
It would be interesting to have at least more information about the canceled accounting because in the log we just have the Radius client, its port and the Radius packet ID.
That's the available information. What else do you want?
See line 1776 in process.c ERROR ("Received conflicting packet from" "client% s port% d - ID:% u due to" "unfinished request in module% s. Giving up on old request.", client-> shortname, packet-> src_port, packet-> id, old_module); In addition I do not know if the canceled accounting is in the accounting logs.
Exactly.
There is too little information to possibly make a corrective post-processing of this cancellation
Perhaps I was unclear. There is *no way* to do any "corrective post-processing". What you want is impossible.
a) add more capacity to the FR + DB system, so it can handle the load
b) change the FR source code to allow these conflicting packets, with some unknown other side-effects.
Those are your choices.
Alan DeKok.
On Apr 22, 2019, at 11:08 AM, François RAGUIN <fraguin@wanadoo.fr> wrote:
I was thinking of post-processing in downstream applications that consume Radius accouting. The problems are very punctual in percentage, but we are investigating the performance of the database and the GGSN to open more source ports.
That's good.
It would have been interesting, however, to have the following information in the "Received conflicting packet" logs: Acct-Status-Type, User-Name, and Framed-IP-Address
The conflicting packets will be random, so that information doesn't really matter. You can update the log message to add whatever information you want. But it does require source code changes. Alan DeKok.
Hello, We added Acct-Status-Type + Framed-IP-Address + Calling-Station-Id in the log "Received conflicting". This is to inform applications that consume downstream Radius accounting. And this while waiting to solve our punctual problems of slow database. Below is the code for lines 1777 - 1781 of the process.c file before and after modification. I do not know the function fr_pair_find_by_num very well. I do not know if there is documentation, but if you have a few minutes, could you look at my code and tell me if there are flagrant errors. Thank you Lines 1777 - 1781 of origin ===================================================== ERROR("Received conflicting packet from " "client %s port %d - ID: %u due to " "unfinished request in module %s. Giving up on old request.", client->shortname, packet->src_port, packet->id, old_module); Lines replaced by the lines below ===================================================== char buffer[INET_ADDRSTRLEN]; char const *call_num, *acct_type = NULL; VALUE_PAIR *vpcli, *vpip, *stype; stype = fr_pair_find_by_num(request->packet->vps, PW_ACCT_STATUS_TYPE, 0, TAG_ANY); vpip = fr_pair_find_by_num(request->packet->vps, PW_FRAMED_IP_ADDRESS, 0, TAG_ANY); vpcli = fr_pair_find_by_num(request->packet->vps, 0, PW_CALLING_STATION_ID, TAG_ANY); if (vpip && vpcli && stype ) { vp_prints_value(buffer, sizeof(buffer), vpip, '"'); call_num = vpcli->vp_strvalue; acct_type = stype->vp_strvalue; ERROR("Received conflicting packet from " "client %s port %d - ID: %u MSISDN: %s IP-Client: %s ACCT-TYPE: %s due to " "unfinished request in module %s. Giving up on old request.", client->shortname, packet->src_port, packet->id, call_num, buffer, acct_type, old_module);
Message du 22/04/19 17:21 De : "Alan DeKok" A : "François RAGUIN" , "FreeRadius users mailing list" Copie à : Objet : Re: Accounting multicast + unacknowledge mode and conflicting packet
On Apr 22, 2019, at 11:08 AM, François RAGUIN wrote:
I was thinking of post-processing in downstream applications that consume Radius accouting. The problems are very punctual in percentage, but we are investigating the performance of the database and the GGSN to open more source ports.
That's good.
It would have been interesting, however, to have the following information in the "Received conflicting packet" logs: Acct-Status-Type, User-Name, and Framed-IP-Address
The conflicting packets will be random, so that information doesn't really matter.
You can update the log message to add whatever information you want. But it does require source code changes.
Alan DeKok.
On Apr 23, 2019, at 4:35 PM, François RAGUIN <fraguin@wanadoo.fr> wrote:
We added Acct-Status-Type + Framed-IP-Address + Calling-Station-Id in the log "Received conflicting". This is to inform applications that consume downstream Radius accounting. And this while waiting to solve our punctual problems of slow database.
OK.
Below is the code for lines 1777 - 1781 of the process.c file before and after modification. I do not know the function fr_pair_find_by_num very well. I do not know if there is documentation, but if you have a few minutes, could you look at my code and tell me if there are flagrant errors.
char buffer[INET_ADDRSTRLEN]; char const *call_num, *acct_type = NULL; VALUE_PAIR *vpcli, *vpip, *stype;
stype = fr_pair_find_by_num(request->packet->vps, PW_ACCT_STATUS_TYPE, 0, TAG_ANY); vpip = fr_pair_find_by_num(request->packet->vps, PW_FRAMED_IP_ADDRESS, 0, TAG_ANY); vpcli = fr_pair_find_by_num(request->packet->vps, 0, PW_CALLING_STATION_ID, TAG_ANY);
if (vpip && vpcli && stype ) { vp_prints_value(buffer, sizeof(buffer), vpip, '"'); call_num = vpcli->vp_strvalue; acct_type = stype->vp_strvalue;
You need to initialize the buffer if the "vpip" isn't found. And you need to check if the call_num and acct_type attributes have been found. There is no guarantee that they will be in a packet. It's best to have a buffer for each one, and do something like: char vpip_buffer[128]; char call_buffer[512]; char acct_buffer[128]; vpip_buffer[0] = 0; call_buffer[0] = 0; acct_buffer[0] = 0; vpip = fr_pair_find_by_num(request->packet->vps, PW_FRAMED_IP_ADDRESS, 0, TAG_ANY) if (vpip) { char buffer[16]; vp_prints_value(buffer, sizeof(buffer), vpip, '"'); snprintf(vpip_buffer, sizeof(vpip_buffer), "IP-Client: %s ", buffer); } and do similar things for the other attributes. Note that you *can't* look at acct_type->vp_strvalue, because it's an integer attribute. You have to look at acct_type->vp_integer. You can then do: ERROR("Received conflicting packet from " "client %s port %d - ID: %u %s%s%s due to " "unfinished request in module %s. Giving up on old request.", client->shortname, packet->src_port, packet->id, call_buffer, chip_buffer, acct_buffer, old_module); That way your server won't crash if it receives packets without a Calling-Station-Id. Alan DeKok.
Hello Alan, i have tested your code on process.c file but when i start freeradius server and when i receive a conflicting packet i get this error: Apr 27 02:04:14 kernel: radiusd[7252]: segfault at 28 ip 00000000004322e1 sp 00007ffcd8d6aa00 error 4 in radiusd[400000+64000] VALUE_PAIR *vpip; char vpip_buffer[128]; vpip_buffer[0] = 0; vpip = fr_pair_find_by_num(request->packet->vps, PW_FRAMED_IP_ADDRESS, 0, TAG_ANY); if (vpip) { char buffer[16]; vp_prints_value(buffer, sizeof(buffer), vpip, '"'); snprintf(vpip_buffer, sizeof(vpip_buffer), "IP-Client: %s ", buffer); } ERROR("Received conflicting packet from " "client %s port %d - ID: %u %s due to " "unfinished request in module %s. Giving up on old request.", client->shortname, packet->src_port, packet->id, vpip_buffer, old_module); the server crashs Thanks Bassem Le mer. 24 avr. 2019 à 12:42, Alan DeKok <aland@deployingradius.com> a écrit :
On Apr 23, 2019, at 4:35 PM, François RAGUIN <fraguin@wanadoo.fr> wrote:
We added Acct-Status-Type + Framed-IP-Address + Calling-Station-Id in the log "Received conflicting". This is to inform applications that consume downstream Radius accounting. And this while waiting to solve our punctual problems of slow database.
OK.
Below is the code for lines 1777 - 1781 of the process.c file before and after modification. I do not know the function fr_pair_find_by_num very well. I do not know if there is documentation, but if you have a few minutes, could you look at my code and tell me if there are flagrant errors.
char buffer[INET_ADDRSTRLEN]; char const *call_num, *acct_type = NULL; VALUE_PAIR *vpcli, *vpip, *stype;
stype =
fr_pair_find_by_num(request->packet->vps, PW_ACCT_STATUS_TYPE, 0, TAG_ANY);
vpip = fr_pair_find_by_num(request->packet->vps,
PW_FRAMED_IP_ADDRESS, 0, TAG_ANY);
vpcli =
fr_pair_find_by_num(request->packet->vps, 0, PW_CALLING_STATION_ID, TAG_ANY);
if (vpip && vpcli && stype ) { vp_prints_value(buffer, sizeof(buffer), vpip,
'"');
call_num = vpcli->vp_strvalue; acct_type = stype->vp_strvalue;
You need to initialize the buffer if the "vpip" isn't found. And you need to check if the call_num and acct_type attributes have been found. There is no guarantee that they will be in a packet.
It's best to have a buffer for each one, and do something like:
char vpip_buffer[128]; char call_buffer[512]; char acct_buffer[128];
vpip_buffer[0] = 0; call_buffer[0] = 0; acct_buffer[0] = 0;
vpip = fr_pair_find_by_num(request->packet->vps, PW_FRAMED_IP_ADDRESS, 0, TAG_ANY) if (vpip) { char buffer[16]; vp_prints_value(buffer, sizeof(buffer), vpip, '"'); snprintf(vpip_buffer, sizeof(vpip_buffer), "IP-Client: %s ", buffer); }
and do similar things for the other attributes. Note that you *can't* look at acct_type->vp_strvalue, because it's an integer attribute. You have to look at acct_type->vp_integer.
You can then do:
ERROR("Received conflicting packet from " "client %s port %d - ID: %u %s%s%s due to " "unfinished request in module %s. Giving up on old request.", client->shortname, packet->src_port, packet->id, call_buffer, chip_buffer, acct_buffer, old_module);
That way your server won't crash if it receives packets without a Calling-Station-Id.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 26, 2019, at 7:07 PM, Bassem Mettichi <mettichi@gmail.com> wrote:
i have tested your code on process.c file but when i start freeradius server and when i receive a conflicting packet i get this error:
Well, debug it. This is free software. That means you get the software for free. It doesn't mean you get free customizations that are useful only to you. Alan DeKok.
participants (3)
-
Alan DeKok -
Bassem Mettichi -
François RAGUIN