Re: EAP
On 13/12/12 15:55, David Peterson wrote: I am troubleshooting potential issues on a WiMax system. Typically we have the FR server on a LAN link but some customers have WAN links. My thought is disconnects on a re-auth session causing outages. I guess it might be WAN RTT. To an extent, it depends on the WiMax client, NAS and server configuration as well as RTT. You'll want to look at the radius request timeout on the WiMax NAS and the EAP timeout on the WiMax client. tcpdump might be a good thing to look into - see if you can see re-transmits. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP
On 13/12/12 15:43, David Peterson wrote: Hmm so if say the wireless inserted 55-65ms of latency and we have another 50ms of WAN latency it could cause some real issues with EAP. It shouldn't cause issues - but you will observe the latency (as well clients when authenticating). Most EAP timers are on the order of seconds, not sub-second. Just be aware of the various timers, and don't tune them aggressively. Obviously if you can co-locate a RADIUS server with the NAS, this is preferable. Clearly not possible for eduroam, but if you have the option. What kind of deployment are you doing? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP
I am troubleshooting potential issues on a WiMax system. Typically we have the FR server on a LAN link but some customers have WAN links. My thought is disconnects on a re-auth session causing outages. David -Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: Thursday, December 13, 2012 10:53 AM To: David Peterson-WirelessConnections; FreeRadius users mailing list Subject: Re: EAP On 13/12/12 15:43, David Peterson wrote: > Hmm so if say the wireless inserted 55-65ms of latency and we have > another 50ms of WAN latency it could cause some real issues with EAP. It shouldn't cause issues - but you will observe the latency (as well clients when authenticating). Most EAP timers are on the order of seconds, not sub-second. Just be aware of the various timers, and don't tune them aggressively. Obviously if you can co-locate a RADIUS server with the NAS, this is preferable. Clearly not possible for eduroam, but if you have the option. What kind of deployment are you doing? <>- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP
Hi, >I wanted to ping the Eduroam people about EAP over WAN links. Are there >considerations that can cause connectivity issues that I should be >examining? depends on how fast your authentication backend is and what your NAS timers are set to. if your backend takes around 1 second to auth and your NAS has a 2s timeout, then the EAP roundtrip time etc could cause that to fail if you have yoru NAS set to eg 5s RADIUS timeout instead then things should be okay... in eduroam we deal with/prpxy EAP authentications from the other side of the world...sites with too low timers on the NAS kit or with slow backend authentication soon find the problems. alan PS I know of a couple of APs that sit on the end of remote ISP links and can happily do EAP authentication remotely proxied by a tier of RADIUS servers - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP
Hmm so if say the wireless inserted 55-65ms of latency and we have another 50ms of WAN latency it could cause some real issues with EAP. David -Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: Thursday, December 13, 2012 10:36 AM To: David Peterson-WirelessConnections; FreeRadius users mailing list Subject: Re: EAP On 13/12/12 15:22, David Peterson wrote: > I wanted to ping the Eduroam people about EAP over WAN links. Are > there considerations that can cause connectivity issues that I should > be examining? Well... maybe. EAP is lockstep, so round-trip time is a factor - if your RTT is 100ms and your EAP exchange sends 10 packets, it will take a *minimum* of 1 second to authenticate. In addition, since a given source/dest ip/port can only have 255 radius packets outstanding (because the ID field is 1 byte) a flurry of re-authentications might necessitate multiple proxy sockets (I can't remember if FreeRADIUS opens new ones for you automatically when the ID space is full). But TBH this is a pretty theoretical problem. Packet loss is an issue, because you'll then suffer retransmits and the timers for these on most supplicants are slow. So avoid lossy links. I guess in theory bit-error-rate is a factor if you have a "dirty" link, since the packet may/will fail Message-Authenticator checks and have to be retransmitted. In short - the usual list of stuff with WAN links. <>- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP
I wanted to ping the Eduroam people about EAP over WAN links. Are there considerations that can cause connectivity issues that I should be examining? David <>- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP
On 13/12/12 15:22, David Peterson wrote: I wanted to ping the Eduroam people about EAP over WAN links. Are there considerations that can cause connectivity issues that I should be examining? Well... maybe. EAP is lockstep, so round-trip time is a factor - if your RTT is 100ms and your EAP exchange sends 10 packets, it will take a *minimum* of 1 second to authenticate. In addition, since a given source/dest ip/port can only have 255 radius packets outstanding (because the ID field is 1 byte) a flurry of re-authentications might necessitate multiple proxy sockets (I can't remember if FreeRADIUS opens new ones for you automatically when the ID space is full). But TBH this is a pretty theoretical problem. Packet loss is an issue, because you'll then suffer retransmits and the timers for these on most supplicants are slow. So avoid lossy links. I guess in theory bit-error-rate is a factor if you have a "dirty" link, since the packet may/will fail Message-Authenticator checks and have to be retransmitted. In short - the usual list of stuff with WAN links. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: share information between authorize and authenticate sections (rlm_perl & rlm_python)
Yes, just found this attribute. Thanks. Works well with Perl :), but not with
Python :(
- Mail original -
De: "Phil Mayers"
À: freeradius-users@lists.freeradius.org
Envoyé: Jeudi 13 Décembre 2012 13:05:23
Objet: Re: share information between authorize and authenticate sections
(rlm_perl & rlm_python)
On 12/12/12 22:04, laurent.fe...@free.fr wrote:
> Hello,
>
> If someone can advise me...
> How to share information between the authorize() function and the
> authenticate() function within a perl or python script ?
Just set an attribute:
authorize {
update request {
Tmp-String-0 := "%{some:expansion}"
}
...
}
authenticate {
Auth-Type XXX {
if (Tmp-String-0 == "a") {
module_a
}
else {
module_b
}
}
}
...re-work as appropriate for your use-case.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: refowarding the radius request when authentication fails
ok. Maybe within a rlm_perl script i recreate a radius packet to send it to another radius server. Thanks. I will try... - Mail original - De: "Phil Mayers" À: freeradius-users@lists.freeradius.org Envoyé: Jeudi 13 Décembre 2012 13:03:54 Objet: Re: refowarding the radius request when authentication fails On 12/12/12 22:14, laurent.fe...@free.fr wrote: > Hello, > > in the authentication step, i try several authentication against otp > server, but if all are failed if the user is not know, i would like > to re forward the radius request to another radius server. The server can't do that, because it doesn't work for many authentication types. If you want to do that, you'll have to implement it yourself, and ensure that your auth type can be "re-tried". - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: share information between authorize and authenticate sections (rlm_perl & rlm_python)
On 12/12/12 22:04, laurent.fe...@free.fr wrote:
Hello,
If someone can advise me...
How to share information between the authorize() function and the
authenticate() function within a perl or python script ?
Just set an attribute:
authorize {
update request {
Tmp-String-0 := "%{some:expansion}"
}
...
}
authenticate {
Auth-Type XXX {
if (Tmp-String-0 == "a") {
module_a
}
else {
module_b
}
}
}
...re-work as appropriate for your use-case.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: refowarding the radius request when authentication fails
On 12/12/12 22:14, laurent.fe...@free.fr wrote: Hello, in the authentication step, i try several authentication against otp server, but if all are failed if the user is not know, i would like to re forward the radius request to another radius server. The server can't do that, because it doesn't work for many authentication types. If you want to do that, you'll have to implement it yourself, and ensure that your auth type can be "re-tried". - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: share information between authorize and authenticate sections (rlm_perl & rlm_python)
Hi, > in perl, i could write some new attributes in RAD_CHECK ??, then > authenticate() will access them. > in python, attributes are read only, so i cannot use them to pass information > to authenticate(). > A simple database, like redis, could be a solution by adding info with the id > of the request (with Message-Authenticator as key)? we use and update private internal FreeRADIUS attributes alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
