buffered_sql problem

Ricardo LarraƱaga ricardo.larranaga at gmail.com
Fri Aug 14 21:47:41 CEST 2015


Hello Alan, thanks a lot for your comments.

To answer your questions, the detail file is full of different packets (New
packets).
I did a search for Packet-Transmit-Counter > 16 both in the debug output
and in the detail file, but i don't see the attribute anywhere, which makes
me think that the packets are not being re transmitted.

I am trying to get a little bit more information about the issue, but it is
difficult.
I wanted to use raddebug when the issue is happening, but it looks like
radddebug is not showing inserts into the accounting database.
If i restart the server to use radiusd -X the server starts processing the
file, and the problem goes away.

Any recommendation on how to get more information would be great.


Thank you very much!


On Aug 12, 2015, at 3:02 PM, Ricardo LarraƱaga <ricardo.larranaga at gmail.com>
wrote:
> I tracked it to a session that only lasted 1 second. For this session i
had
> a complete accounting record in my database when a start packet came in.
> This is the first packet in my detail file, and after it , the detail file
> started increasing in size,

  With what data?  The same packet?  Or new packets?

> and my database did not receive any more
> accounting stops.

  That sounds like it's retrying the "bad" packet over and over.

  A simple fix is to put this into the virtual server handling the
accounting packets:

        if (Packet-Transmit-Counter > 16) {
                ok
        }
        else {
                ... everything that is there now
        }

  This tells the server to ignore packets that get retransmitted too many
times.  The only downside is that this may cause issues when a home server
is unavailable for long periods of time.

> I remember you mentioning that when there is any "nasty" packets in the
> detail file, the server gets stuck and you need to edit the file manually
> to remove the packets.

  Or, figure out what the bad packets are, and write a policy:

        if (bad packet...) {
                ... ignore it...
        }

  which is better.

> Is this an expected behavior? Shouldn't the server be able to process the
> packet without restarting the server, since it clearly can process it when
> you restart it.

  It should be able to process the packets.  Restarting shouldn't matter.

  As always, run in debugging mode to see what's going wrong.  Without
that, the report is "bad things happen, and I don't know when, and I don't
know why".  Those kind of bug reports are impossible to fix, and tend to
get ignored.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html


More information about the Freeradius-Users mailing list