FR 2.1.x git + SoH: ASSERT FAILED xlat.c[1048]: outlen > 0

[Phil Mayers]

On 04/05/11 10:42, James J J Hooper wrote:
> Hi All,
>
> Sorry for the sketchy details....
>
> We got an
> ASSERT FAILED xlat.c[1048]: outlen > 0
> with a PEAP user. The bit of the -X I have is as below, and the soh
> virtual server config is attached. I have no further details at the
> moment because the client has gone away (and I've disabled SoH in the
> EAP module config in case they come back and knock it over again while
> I'm away).
>
> The same set-up has been fine with many other SoH clients previously.
>
> Can anyone point me in the right direction? ....The only think that came
> to mind was the packet getting a bit big with all those attributes?

 From what I can tell, that's a pretty hard error condition to produce. 
xlat.c:1048 is inside xlat_copy, which is the default "escaping" 
function when radius_xlat is called with a NULL final argument.

The assert means that there was no room left in the output buffer, but 
the very first check inside the while() loop in radius_xlat is:

   while (*p) {
           /* Calculate freespace in output */
           freespace = outlen - (q - out);
           if (freespace <= 1)
                   break;

A quick look at the code gives me the impression it should be pretty 
hard to trigger this error condition; I can't see how freespace < 1 ever 
allows xlat_copy to be called.

>
> Thanks,
> James
>
> ++++[updated] returns updated
> +++- if ((Calling-Station-Id) && "%{Calling-Station-Id}" =~
> /^%{config:policy.mac-addr}$/i) returns updated
> +++ ... skipping else for request 750: Preceding "if" was taken
> ++- policy create.uob-stripped-mac returns updated

The above policy: where is that? It's clearly not in your SoH virtual 
server - is this the inner-tunnel stuff? Can we see the config? I 
suspect something in the SoH is triggering this when it dumps the AVPs.