eap_sim_db_receive is not called
mctiew at yahoo.com
Wed Sep 14 18:44:30 EDT 2011
--- On Wed, 9/14/11, Jouni Malinen <j at w1.fi> wrote:
> This works just fine when using hostapd as the EAP/RADIUS
> server, so I'm
> assuming you are talking about using libeap.so in some
> other context.
> > Likely eloop is not initialized correctly but I have
> called eloop_init() and eloop_run() in the initialization,
> but yet eloop mechanism inside eap_sim_db does not seem to
> be working.
> > Is there any other functions which I must also call to
> startup the eloop properly ?
> eloop_init() and eloop_run() are the key functions. In
> eap_sim_db.c needs to register the read socket with
> Are you sure that eloop_run() is running? How is eloop
> integrated with
> whatever program you are using to run libeap.so?
OK I have found out why. Two points :-
1. Basically if one calls eloop_run() early, when there is
nothing registered, then the function runs to completion
and exited. So it was as good as not called.
2. eloop_run() is a blocking function when something is registered,
so in the hostapd code it daemonized everything else and keep
its main thread to service eloop_run(). Which means when I
used it in libeap.so I also have to provide a thread to service
After realizing the above I created a thread to service eloop_run()
AFTER eap_sim_db_receive() has been registered and now
eap_sim_db_receive() called when there is data incoming.
But I still failed to get the radius client to authenticate properly
due to the PENDING reply behaviour - as I posted in freeradius maillist.
What I am not sure now is the purpose of the callback function in
the context of using libeap.so for realtime radius client-server
authentication. Maybe I did not do this correctly and the caused
the failed radius authentication.
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.
More information about the HostAP