eap_sim_db_receive is not called

[Ming-Ching Tiew]

--- On Sun, 9/18/11, Jouni Malinen <j at w1.fi> wrote:

> > 
> > I suspect because freeradius does not like the pending
> behaviour - so I
> > probably will look inside libeap.so to change the
> pending behaviour 
> > of eap_sim_db to a blocking one.
> 
> Unless you are planning on creating a new thread for every
> EAP-SIM
> authentication, that may not be very good idea..
>

I believe that's exactly the achitecture of freeradius.
I will have to ask the comments of the freeradius experts, 
as I have limited knowledge about freeradius but based
on what I understand, freeradius keeps a configurable pool 
of threads to service each radius client request. There is 
no pending, each thread is destined to service one particular 
request till completion, success or failure.
 
> What exactly are you trying to achieve here? It would
> likely be easier
> to just run hostapd as an external process for the
> authentication and
> proxy the queries through FreeRADIUS. Blocking the thread
> while waiting
> for SIM parameters does not sound like a good solution and
> getting the
> re-process-previous-EAP-message mechanism working may
> require
> considerable amount of design changes within FreeRADIUS.
> 

That's certainly one other possibility - perhaps the easier one.:)

But in terms of scalability, I would need some input here. 
Correctly me if I am wrong, but it appears to me that hostapd 
depends on event loop architecture to achieve concurrency, 
which fundamentally it is single threaded. Would this able to 
fully capitalize on the availability and abundance of 
multi-core multi-CPU machine to service as many requests as possible ?