On Jan 12, 2021, at 1:48 PM, adrian.p.smith@bt.com wrote:
We are running 3.0.15 and are seeing occasional issues when a large accounting packet is passed to our REST server:
It appears that a buffers gets a bit full and if this occurs when an attribute name is written, but not the value, the next chunk starts with the value of the NEXT AVP instead of the one that was being processed when the buffer got full:
That code is ~9 years old and I believe you're the first person to hit that bug, congratulations! It happens when the value has been written, there's no bytes remaining in the output buffer, and there are more attributes to encode. Which may not sound that uncommon, but the length of the value needs to fit perfectly in the output buffer in order for this to happen. The correct fix is to add an encoding state to represent the separator '&', but I don't want to accidentally break anything else. The bad but functional fix is to check if we can write the separator before advancing the pair cursor. https://github.com/FreeRADIUS/freeradius-server/commit/3dd36aa1058343e3e7a99... With the fix applied you'll notice that the debug output indicates the value has been encoded twice, but in reality it'll only occur in the POST data once. Because that code has been stable for so long you might just be able to apply the diff directly to 3.0.15, or you can wait for the next stable release and upgrade. There's also a bit of a crappy work around. If you adjust the 'chunk' parameter for a given section (maybe set it to 900) you can reduce the amount of buffer that's filled before the encoding callback returns. As this is such an edgy edge case it's likely that you won't hit it with a different output buffer size. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2