Segmentation fault on conflicting packet

[Alan Dekok]

Milan Holub wrote:
> I'm using cvs build based on cvs head on May 29 2007.
> I'm running it under conditions close to production(40 auth
> requests/hour, 700 accounting requests/hour).

   That's a pretty low load, but still useful for testing.

> Most of the time it's doing well but I've observed already multiple
> times following behaviour:
> 
...
> 2007-05-31 06:18:14.885099500 Received conflicting packet from client <SHORTNAME> port 33499 - ID: 0 due to unfinished request 11920.Giving up on old request.

   The client appears to be broken, OR the checks for conflicting 
packets are broken.

> 2007-05-31 06:18:14.885168500 Failed to insert request 11921 in the list of live requests: discarding

   That's a pretty catastrophic error.  I'm not sure why it's happening, 
because the "conflicting packet" checks are *supposed* to delete the old 
request from the list of current packeys.

>>> SEQMENTATION FAULT...

   Ugh.  Maybe valgrind would help here.

> If you check the timeline we've received conclicting packet after
> 0.000696 sec. Which I think was a duplicate packet due to some network
> problem.

   If it really was a duplicate, then it shouldn't be "conflicting".  It 
should be marked 'duplicate".  The code should handle this, and it was 
tested to handle this.

> Packet 11920 was in the middle of processing(finished writing
> into detail file, but not yet written to database). Segmentation fault
> occured when another request was received.

   Because that code path isn't well tested.

> I was not able to simulate by sending duplicate packets via radclient. I
> think the sensitive part is receiving duplicate packet during the
> processing of original packet.

   valgrind.  Write a config that does "sleep 10", to slow down the 
processing to human speeds.  Then use a client to send *new* packets 
with same src/dst ip/port, and same RADIUS Id.

   Alan DeKok.