Hi radiator team,
still debugging the nasty bug between radsecproxy and Radiator in
the eduroam connection between uni-ulm.de and radiusX.dfn.de, sigh!
I have the problem with 'AuthBy RADSEC', where always extendid IDs are
used. If someone is stripping/mangling the Proxy-State, the reply can't
be mapped to the request and the warning is printed:
> WARNING: Unknown reply received in AuthRADSEC for request from 127.0.0.1:2083
The missing request Id can't mapped, therefore the additional blank in
the warning between 'request <> from'.
There is never a PacketTrace so see the buggy answer. A patch will come
soon to dump this, but wait and read to the end of my message.
Now I looked for the Radiator behavior for AuthBy RADIUS with
extended Ids and stripping Proxy-State. Wondering, it worked!
... But only for the first 256 Requests (8-Bits, 0xff mask in code)
and after that I got the same/similar warning:
> WARNING: Unknown reply received in AuthRADIUS for request 0 from
> 127.0.0.1:1900
...
> WARNING: Unknown reply received in AuthRADIUS for request 1 from
> 127.0.0.1:1900
You see, now the request Id is used from the 8-Bit Packet-Identifier,
but could notbe mapped to the Proxy-State ExtendedId, since the 8 Bits
wrapped:
> Proxy-State = OSC-Extended-Id=256
...
> Proxy-State = OSC-Extended-Id=257
This is not optimal, since it works for a while after starting radiusd
and after 256 requests you get spurious errors.
Please fix this, if you UseExtendedIds in AuthBy RADIUS you should
always WARN if the Proxy-State is stripped or mangled.
And sure, we need better packet dumps in this case to see the
sent/missing/mangled attributes in the reply packet.
Best Regards
Charly
--
Karl Gaissmaier
Universität Ulm / Germany
_______________________________________________
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
