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
On 07/14/2013 11:30 AM, Karl Gaissmaier wrote:
> Please fix this, if you UseExtendedIds in AuthBy RADIUS you should
> always WARN if the Proxy-State is stripped or mangled.
Good point. It's a good idea make this separate from getting an unknown
reply, which is currently logged for the both cases.
On 07/13/2013 11:30 PM, Karl Gaissmaier wrote:
> there is a missing whitespace in the documentation:
Noted, thanks!
> 5.51.1
> DefaultResult
> Specifies how to reply to any request for which there is no more
> specific result. The
> default is to IGNORE.
> # Accept everything not otherwise spec
On 07/10/2013 12:50 PM, Karl Gaissmaier wrote:
> a SIGHUP to a running radiator (Version 4.11) opens an additional socket
> for AuthByRADSEC:
Fixed in the latest patches.
Thanks for reporting this,
Heikki
--
Heikki Vatiainen
Radiator: the most portable, flexible and configurable RADIUS serve
Hi Heikki,
it's sunday, really I can wait for answers from your
team after weekend ;-)
Am 14.07.2013 10:54, schrieb Heikki Vatiainen:
> On 07/14/2013 11:30 AM, Karl Gaissmaier wrote:
>
>> Please fix this, if you UseExtendedIds in AuthBy RADIUS you should
>> always WARN if the Proxy-State is strip
On 07/14/2013 12:17 PM, Karl Gaissmaier wrote:
> it's sunday, really I can wait for answers from your
> team after weekend ;-)
Heh, I thought I'd save you some work since I understood you were gointo
to work on the debug log and PacketTrace patch.
The Proxy-State mangling is a bit problematic, t
Hi Heikki,
Am 14.07.2013 11:35, schrieb Heikki Vatiainen:
> On 07/14/2013 12:17 PM, Karl Gaissmaier wrote:
>
>> it's sunday, really I can wait for answers from your
>> team after weekend ;-)
>
> Heh, I thought I'd save you some work since I understood you were gointo
> to work on the debug log and
Am 14.07.2013 11:35, schrieb Heikki Vatiainen:
> On 07/14/2013 12:17 PM, Karl Gaissmaier wrote:
>
>> it's sunday, really I can wait for answers from your
>> team after weekend ;-)
>
> Heh, I thought I'd save you some work since I understood you were gointo
> to work on the debug log and PacketTrace
Hi radiator team,
now I proved my suspicion, that the upstream radsecproxy is stripping
the radiator proxy-state, at least in status-server requests.
I used monkey patching in AuthBy RADSEC, just quick and dirty
to get the result (you know, it's sunday):
> Sun Jul 14 16:56:43 2013 009313: DEBUG:
Am 14.07.2013 17:28, schrieb Karl Gaissmaier:
...
> Worse, it seems that buggy clients with unroutable @Realms trigger
> answers with proxy-state stripped. So I get NoreplyTimeouts for
> any buggy client request and my upstream connections break away.
>
> Seems that all german @Realms in eduroam u
Hi
As an end site you really shouldn't be sending invalid realms to your national
proxy... but there does seem to be something odd gong on here. . their system
should be just sending back a straight access reject. If radsecproxy doesn't
like extended proxy id (or the config doesn't allow it )
Hi Alex, hi radiator team,
Am 14.07.2013 19:48, schrieb Alan Buxey:
> Hi
>
> As an end site you really shouldn't be sending invalid realms to your
> national proxy... but there does seem to be something odd gong on here.
I sent it to test this situation. As an eduroam ServiceProvider I don't
know
Hi radiator team,
I looked over the radsecproxy sources and sorry to say it:
*Currently the radsecproxy and AuthRADSEC are incompatible!*
Whenever radsecproxy *generates* a reply message (Access-Reject or
Access-Accept on Satus-Server) it never copies the Proxy-State
Attribute from the request p
Hello,
> Maybe someone can trigger the authors of radsecproxy too, to start
> implementing Proxy-State RFC 2865 conform when *generating* responses.
> Seems it makes everthing right on proxying but not on generating
> packets.
Status-Server is defined in RFC5997. It uses a distinct command-code -
Hello,
Am 15.07.2013 07:47, schrieb Stefan Winter:
> Hello,
>
>> Maybe someone can trigger the authors of radsecproxy too, to start
>> implementing Proxy-State RFC 2865 conform when *generating* responses.
>> Seems it makes everthing right on proxying but not on generating
>> packets.
>
> Status-S
15 matches
Mail list logo
