Accounting multicast + unacknowledge mode and conflicting packet

[Bassem Mettichi]

Hello,

i think the solution is to ignore conflicting packets and not process them
and print them to detail file, but how we can configure freeradius to
ignore these conflicting packetes from GGSN ?

Thanks
Bassem

Le lun. 22 avr. 2019 à 14:08, Alan DeKok <aland at deployingradius.com> a
écrit :

> On Apr 22, 2019, at 9:00 AM, François RAGUIN <fraguin at wanadoo.fr> wrote:
> >
> > Our GGSN is configured to send Radius accounting in multicast to
> multiple servers and ignore accounting response (unacknowledge mode).
>
>   OK.
>
> > In this case, GGSN (which sends several thousand requests per second)
> reuses emitter UDP port and Radius ID pairs rather quickly.
>
>   Then the GGSN is probably broken.  It's not difficult to open more
> source ports.
>
> > On the FreeRadius side, we then encounter multiples cases of "Received
> conflicting packet" in the logs.
>
>   Because FreeRADIUS implements the RFCs correctly.
>
> > Would it not be possible for FreeRadius to process all Accounting, in
> this particular case where the GGSN is configured in unacknowledge mode?
>
>   Sure.  Just make sure that it takes almost no time to process packets.
>
>   i.e. dump the packets to a detail file, and do nothing else:
>
> preacct {
> }
>
> accounting {
>         detail
>         do_not_respond
> }
>
>   Then, configure a detail file reader to post-process the detail files.
>
>   But realistically, this is unfriendly behaviour on the part of the
> GGSN.  Plus, you'e likely doing complex processing of the accounting
> packets, which is slow.
>
>   It's not trivial to change FreeRADIUS to handle this case.  It's
> unusual, and could break normal packet processing.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html