Accounting multicast + unacknowledge mode and conflicting packet

[François RAGUIN]

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.
> 
>