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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
