Freeradius-Users Digest, Vol 113, Issue 28

[Rui Ribeiro]

Hi Emma,

For debbuging problems I usually use raddebug, and then only more difficult
ones, or to send the output to the list are the ones that deserve running
in full debug mode.

Regards,
Rui Ribeiro


>
> Message: 3
> Date: Mon, 8 Sep 2014 09:21:23 +0000
> From: "Cardinal-Richards, Emma" <e.cardinal-richards at ucl.ac.uk>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: RE: EAP Session problems
> Message-ID:
>         <
> 7a18137e1a7c4d51b84031b037eb9166 at AM3PR01MB209.eurprd01.prod.exchangelabs.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> > On 8 Sep 2014, at 09:18, Cardinal-Richards, Emma <e.cardinal-
> > richards at ucl.ac.uk> wrote:
> > > I'm experiencing a problem with EAP sessions/new conversations not
> > starting when I'm using the Janet testing as shown below.
> >
> > I'm not sure I fully understand your current configuration - are you
> saying
> > that you're routing test.ucl.ac.uk from your production radius servers,
> via the
> > national proxies, back to your pre-production servers?
>
> I believe that's the process of the test as per the guidance from JANET
> here?  This is for testing purposes, not our final configuration.
>
> "ORPS Testing
> Setting an ORPS to testdev allows organisations to bring up a test box and
> for it to only be sent specific test traffic during logic/rules checking
> etc. eduroam administrators will need to generate such test traffic
> themselves, eg. by using rad_eap_test with the username '
> testuser at test.youruniversity.ac.uk' to do a 'loopback test' to the new
> systems. This can be done by using your live systems:
>
> 'testuser at test.youruniversity.ac.uk' -> Production ORPS -> NRPS ->
> Testdev ORPS
>
> For this test realm handling facility to work eduroam administrators do
> NOT have to specifically configure a 'test' sub-realm (eg.'
> test.youruniversity.ac.uk') in the Realms section of eduroam Support."
>
> https://community.ja.net/library/janet-services-documentation/orps-role-designation-features-eduroamuk-support-server
>
> I was just concerned that this behaviour would mean our roaming clients
> would fail to authenticate back to us when they're visiting another
> institution.
>
> >
> > The issue seems to be that your client is responding too slowly:
> >
> > > Finished request 0.
> > > Going to the next request
> > > Waking up in 4.9 seconds.
> > > Cleaning up request 0 ID 1 with timestamp +17
> >
> > Increase the cleanup delay in radiusd.conf and requests should complete -
> > but over 5 seconds is an obscenely long time, things should be much
> faster.
>
> Dropping it to 3 seconds fixes it..
>
> > Could you give an overview of where the requests being transmitted to the
> > NRPS are originating from?
>
> Sorry do you mean the client? I tested from my Linux (Ubuntu) laptop and
> my colleagues Windows 7 laptop with the same behaviour.
>
> >
> > > The other odd behaviour is that despite getting a REJECT from this
> testdev
> > server, I get authenticated by our production ORPS using
> > 'username at test.ucl.ac.uk' which is not a declared local realm on the
> > production ORPS.
> >
> > We'd need to see a log from the production servers to investigate this.
>
> Just wondering is this technically correct behaviour (will have to
> organise a specific time to run it in debug on our live servers..) my
> 'test' user gets authenticated on my test ORPS so the NRPS tell my
> production ORPS (as if they are another institution I'm visiting) to allow
> me on the network?
>
> Regards,
> Emma
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140908/2d0326a6/attachment.html>