Hi,
> 1.)Radiator has to fix AuthRADSEC. The user has to choose to use
>extended-Ids in the Proxy-State Attribut if the upstream proxy
>will handle this. By default it should use 8 Bit Identifiers.
>
> 2.)radsecproxy has to fix the self generated Access-Rejects.
>I
Hi,
Am 15.07.2013 09:15, schrieb a.l.m.bu...@lboro.ac.uk:
> Hi,
>
>> 1272017248108...@wlan.mnc001.mcc262.3gppnetwork.org
>
> 3gppnetwork realms are invalid. ..just like hotmail, gmail, yahoo etc -
> until a notice comes from eduroam stating that these realms now have agreed
> relationship, they ar
Hi,
> status-server musnt be proxiedits only for the first-hop check of
> a remote proxy and not the end target - but that surely isnt the issue?
> a Status-Server message is easy to deal with - you just send something back
> to show you are alive - RADIATOR has been sending a basic statts pag
Hi,
> 1272017248108...@wlan.mnc001.mcc262.3gppnetwork.org
3gppnetwork realms are invalid. ..just like hotmail, gmail, yahoo etc -
until a notice comes from eduroam stating that these realms now have agreed
relationship, they are public realms and not within the private scheme of
eduroam.
> RF
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
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 )
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 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:
