porting to world radio chips from conexant

[alfred hitch]

Hi Jouni, All,

1) I do intend to make it open source .

2) I went thru broadcom code and mapping it now with my cards structures .. 

3) I now understand (*hope so -;) ) the relavance and what all I have
to   pass apart from API structure population .. i.e what all events
..

I had a small observation, if one could please clarify .. 
in the wpa_supplicant_asocinfo.

The header file which had structure defintion for wpa_even_data, 
mentions that
req_ie, resp_ie
becaon_ie,  are all optional ..

But, in this function code, I see that  we are free'ing any data which
wud have been part of wpa_s , without checking that the driver while
passing this event filled in the correct i.e's or not ..

infact mapping it with drover_broadcom.c
I see that assoc info driver gives to this funciton is copied into
"resp"_ie while wpa_supplicant_asocinfo function is using p =
data->asoc_info.req_ies .
This indicates usage of req_ies, which has like not even been
populated in driver ?
same for beacon frames , driver doesnt passes and we are free'ing and
memcpy'ing ..

Also, if I could ask, of all these 3 (optional ?) ie's which one will
be needed defintely ..
In the sense that from where else can supplicant gather info on ie's
and so I could skip giving here .. ??
scan result population I will with wpa_ie ..
This will be resp_ie right .. 
so that leaves req_ie ,, infact do we need in wpa_s AP's ie, or our
request IE, ?
This is what I could guess, please correct me if I am wrong:

in wpa_s
ap_wpa_ie refers to AP's beacon / resp_ie .. 
ap_rsn_ie .. for RSN case, same meaning as above
assoc_wpa_ie, .. what we just sent in association request ?? req_ie 

Cheers,
Alfred



On 5/17/05, Jouni Malinen <jkmaline at cc.hut.fi> wrote:
> On Mon, May 16, 2005 at 05:39:59AM -0400, alfred hitch wrote:
> 
> > I intend to port the wpa supplicant to conexant workd radio chips.
> 
> Are you planning on making this available under an open source license?
> 
> > 2) The current driver we have doesnt supports wireless extensions, so
> > I also intend to leave the driver that ways and map the stuff in wpa
> > supplicant driver file. README mentions that wireless extensions
> > support is optional, and I am inclined to believe so (for my good)
> > -;) .
> > Anyone conform that there are no hidden surprises / pitfalls in not
> > using wireless extension calls ?
> 
> As long as you are willing to implement the driver interface code
> (driver_*.c) in wpa_supplicant, you do not need to use Linux wireless
> extensions. As an example, driver_broadcom.c does not use wireless
> extensions.
> 
> > 3) I could see api's for setting keys and other ie,.capability etc ..
> > from supplicant to driver,
> > but I some how missed where / how does the authentication /
> > association time handshake messages flow from driver to supplicant,
> > what all messages from driver I need to provide to supplicant ??
> 
> All data frames (i.e., EAPOL packets) need to be provided to supplicant.
> In addition to this, you will need to generate association events
> (wpa_supplicant_event() calls with EVENT_ASSOC parameter. Depending on
> the driver/firmware implementation, you may have to generate
> EVENT_ASSOCINFO events to get WPA IE information from the AssocReq (if
> driver/firmware generated it). In addition, wpa_supplicant needs to be
> able to get WPA IE from Beacon/ProbeResp frames through the scan
> results.
> 
> --
> Jouni Malinen                                            PGP id EFC895FA
> _______________________________________________
> HostAP mailing list
> HostAP at shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap
>