hostapd/wpa_supplicant - new development release v0.3.4

[Jouni Malinen]

On Fri, Jan 14, 2005 at 04:13:38PM +0100, Leonardo Maccari wrote:
> On Wed, Jan 12, 2005 at 04:38:59PM -0800, Jouni Malinen wrote:
> > The current version has only WPA-None and that "None" is indeed the
> > missing key management part.

> I'm trying with 3 machines in ad-hoc mode and it doesn't work, I guess
> this needs some per-machine code, like IV management, right? So I guess
> next big step should be having a per-machine configuration and then
> move authenticator SM into supplicant.

WPA-None would require per-peer station configuration/state information.
However, IEEE 802.11i has somewhat different requirements and since you
are talking about authenticator SM, I would assume you are looking into
IEEE 802.11i, not WPA-None. IEEE 802.11i does not need to store any
permanent per-station configuration apart from having the security
policy and PSK. WPA-None needs extra data since it does not have key
management functionality to take care of the packet number
initialization.

> something like: add a list of known stations to struct wpa_supplicant
> 
> wpa_supplicant_sta_info * 	sta_list
> 
> add a list of "associated" stations to struct wpa_supplicant
> 
> wpa_supplicant_sta_info * 	rsn_associated_sta_list

I don't see need for two lists.

> when a new station is encountered, after receiving a probe reply it should
> be added
> to the sta_list. the sta_list is to be refreshed every time a probe
> request is sent and probe replies are received (is this compliant?
> standard doesn't specify this kind of behaviuor to my memory).

Only the stations that have started authentication or to which the
station wants to send data would need to be kept in a list, i.e., only
the stations for which there is an active (or completed) 4-way
handshake.

> so there must be a wpa_supplicant_sta_info structure defined in
> wpa_supplicant_i.h which could be something similar to sta_info in hostapd
> code (stripped down of some pieces?).

Yes, something similar would be needed. Ideally, the WPA/RSN
authenticator code in hostapd would be made more modular so that it
could be shared by both hostapd and wpa_supplicant.

> it's unclear to me how to decide when to end such an rsna. apart from
> clear events, like deassociation or deauthentication, the standard doesn't
> seem to dictate when a station should consider a neighbour unreachable.

I would use a timeout to remove STA entries that have not been used for
a configurable time period.

-- 
Jouni Malinen                                            PGP id EFC895FA