Re: EAP module return code for proxy case [Re: help with EAP proxy]
Dave Mason [EMAIL PROTECTED] wrote: Just so I'm on the right page, I assume I should do the patch and submit it in the usual way? Yes. Also putting it on bugs.freeradius.org would help. If so, I'll clarify my understanding of what needs to happen. In eap.c/eap_start, I can return EAP_OK instead of EAP_NOOP for the proxy case. I dont see any other cases where EAP_OK is returned now. Then in rlm_eap.c/eap_authorize, in the switch statement for the eap_start return code, I can add an EAP_OK case that will return RLM_MODULE_OK. I can also add a config note in doc/rlm_eap. Sounds good. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP module return code for proxy case [Re: help with EAP proxy]
Just so I'm on the right page, I assume I should do the patch and submit it in the usual way? If so, I'll clarify my understanding of what needs to happen. In eap.c/eap_start, I can return EAP_OK instead of EAP_NOOP for the proxy case. I dont see any other cases where EAP_OK is returned now. Then in rlm_eap.c/eap_authorize, in the switch statement for the eap_start return code, I can add an EAP_OK case that will return RLM_MODULE_OK. I can also add a config note in doc/rlm_eap. Dave Alan DeKok wrote: Dave Mason [EMAIL PROTECTED] wrote: Along the way, I noticed that in the 1.0 server code, rlm_eap returns NOOP both for Access-Requests with an EAP-Message to be proxied and for Access-Requests with no EAP at all. It would be useful for me to write a configurable failover block in the authorize section of radiusd.conf that distinguishes between the two. Ok... Maybe it could return HANDLED in that case? No. That return code means there's a RADIUS reply packet ready to be sent to the client. Maybe RLM_MODULE_NOOP for no EAP-Message, and RLM_MODULE_OK for an EAP-Message which will be proxied. This should also be documented in the man page for rlm_eap. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP module return code for proxy case [Re: help with EAP proxy]
Dave Mason [EMAIL PROTECTED] wrote: Along the way, I noticed that in the 1.0 server code, rlm_eap returns NOOP both for Access-Requests with an EAP-Message to be proxied and for Access-Requests with no EAP at all. It would be useful for me to write a configurable failover block in the authorize section of radiusd.conf that distinguishes between the two. Ok... Maybe it could return HANDLED in that case? No. That return code means there's a RADIUS reply packet ready to be sent to the client. Maybe RLM_MODULE_NOOP for no EAP-Message, and RLM_MODULE_OK for an EAP-Message which will be proxied. This should also be documented in the man page for rlm_eap. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
help with EAP proxy
Hi, I'm using an old Freeradius server, v0.8.1, to proxy Access-Requests with EAP-Messages. The outbound proxy works fine, but the proxy response is getting mangled. The 1.0 server works fine, and I know the real solution is to pick it up, but with my current deadline I cant port the rest of my application to it yet, and hopefully I can pick up some new code to fix the bug. I found some new code in eap_authorize that prevents adding Auth-Type = EAP if the request is to be proxied. I also see the change in radiusd.conf to move suffix before eap in the authorize section. However, when the proxy response comes, the server calls the authorize and authenticate sections as usual, when I dont believe it should. rad_authenticate calls rad_check_password and somehow this succeeds, causing Access-Accept to be sent to the client, instead of Access-Challenge. Any idea how to prevent this? Here's a trace: rad_recv: Access-Request packet from host 127.0.0.1:33225, id=160, length=103 Thread 1 assigned request 0 --- Walking the entire request list --- Threads: total/active/spare threads = 5/1/4 Waking up in 5 seconds... Thread 1 handling request 0, (1 handled so far) User-Name = [EMAIL PROTECTED] Message-Authenticator = 0x1b676d3dcd9e39bf4e9f75afdfecd30f EAP-Message = 0x020100210131323935303233383230303032313330407472616e7361742e636f6d modcall: entering group authorize modcall[authorize]: module preprocess returns ok rlm_realm: Looking up realm transat.com for User-Name = [EMAIL PROTECTED] rlm_realm: Found realm transat.com rlm_realm: Proxying request from user 1295023820002130 to realm transat.com rlm_realm: Adding Realm = transat.com rlm_realm: Preparing to proxy authentication request to realm transat.com modcall[authorize]: module suffix returns updated modcall[authorize]: module eap returns noop users: Matched DEFAULT at 166 modcall[authorize]: module files returns ok modcall: group authorize returns updated Sending Access-Request of id 1 to 192.168.1.26:1812 User-Name = [EMAIL PROTECTED] Message-Authenticator = 0x EAP-Message = 0x020100210131323935303233383230303032313330407472616e7361742e636f6d NAS-IP-Address = 127.0.0.1 Proxy-State = 160 Thread 1 waiting to be assigned a request rad_recv: Access-Challenge packet from host 192.168.1.26:1812, id=1, length=99 Thread 2 assigned request 0 rl_next: returning NULL Waking up in 5 seconds... Thread 2 handling request 0, (1 handled so far) EAP-Message = 0x01020010120a0f0200020001 Message-Authenticator = 0x9495b4c9ad2b49368ee4713da30eb317 State = 0x7a09c5908c3a238a892edc7e82f3b9f3fb400829d375a96cc6ef2a15ea2f26170783 Proxy-State = 0x313630 modcall: entering group authorize modcall[authorize]: module preprocess returns ok rlm_realm: Proxy reply, or no user name. Ignoring. modcall[authorize]: module suffix returns noop modcall: entering group group modcall[authorize]: module eap returns noop modcall: group group returns noop users: Matched DEFAULT at 166 modcall[authorize]: module files returns ok modcall: group authorize returns ok rad_check_password: Found Auth-Type rad_check_password: Auth-Type = Accept, accepting the user Sending Access-Accept of id 160 to 127.0.0.1:33225 EAP-Message = 0x01020010120a0f0200020001 Message-Authenticator = 0x State = 0x7a09c5908c3a238a892edc7e82f3b9f3fb400829d375a96cc6ef2a15ea2f26170783 Finished request 0 Going to the next request Thread 2 waiting to be assigned a request --- Walking the entire request list --- Threads: total/active/spare threads = 5/0/5 Waking up in 1 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 160 with timestamp 40fbf3e7 Nothing to do. Sleeping until we see a request. As a reference, here's what the 1.0 server does: rad_recv: Access-Request packet from host 127.0.0.1:33225, id=169, length=103 --- Walking the entire request list --- Waking up in 31 seconds... Threads: total/active/spare threads = 5/0/5 Thread 1 got semaphore Thread 1 handling request 0, (1 handled so far) User-Name = [EMAIL PROTECTED] Message-Authenticator = 0xf27d915025b8dacb43dbdbe7cfa21444 EAP-Message = 0x020100210131323935303233383230303032313330407472616e7361742e636f6d Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module preprocess returns ok for request 0 modcall[authorize]: module chap returns noop for request 0 modcall[authorize]: module mschap returns noop for request 0 rlm_realm: Looking up realm transat.com for User-Name = [EMAIL PROTECTED] rlm_realm: Found realm transat.com rlm_realm: Proxying request from user 1295023820002130 to realm transat.com rlm_realm: Adding Realm = transat.com rlm_realm: Preparing to proxy authentication request to realm
EAP module return code for proxy case [Re: help with EAP proxy]
Hi, I found the answer in auth.c near the beginning of rad_authenticate. The trick is to return RLM_MODULE_HANDLED if the proxy reply is an Access-Challenge. Along the way, I noticed that in the 1.0 server code, rlm_eap returns NOOP both for Access-Requests with an EAP-Message to be proxied and for Access-Requests with no EAP at all. It would be useful for me to write a configurable failover block in the authorize section of radiusd.conf that distinguishes between the two. That is, if there is no EAP-Message, I'd like to run the sql module to check for Username/Password. If there is an EAP proxy going on, I could skip sql if eap returns something different than NOOP. Maybe it could return HANDLED in that case? To accomplish that with the current code, eap_start would return EAP_FOUND, which is misleading. Maybe there's a better way. Dave Dave Mason wrote: Hi, I'm using an old Freeradius server, v0.8.1, to proxy Access-Requests with EAP-Messages. The outbound proxy works fine, but the proxy response is getting mangled. The 1.0 server works fine, and I know the real solution is to pick it up, but with my current deadline I cant port the rest of my application to it yet, and hopefully I can pick up some new code to fix the bug. I found some new code in eap_authorize that prevents adding Auth-Type = EAP if the request is to be proxied. I also see the change in radiusd.conf to move suffix before eap in the authorize section. However, when the proxy response comes, the server calls the authorize and authenticate sections as usual, when I dont believe it should. rad_authenticate calls rad_check_password and somehow this succeeds, causing Access-Accept to be sent to the client, instead of Access-Challenge. Any idea how to prevent this? Here's a trace: deleted Dave - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html