hostapd/wpa_supplicant - new development release v0.3.4

[Leonardo Maccari]

On Sat, Jan 15, 2005 at 10:52:47AM -0800, Jouni Malinen wrote:
> 
> 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

yes. As I said before, my aim is to have a 802.1X network using TKIP or
CCMP, 4-way handshake and so on (what's the right name for it? WPA2 ? I'm
not used to "wifi" terms) in ad-hoc networks. So I'm trying to figure out
which steps are to be made to go that direction.

> permanent per-station configuration apart from having the security
> policy and PSK. WPA-None needs extra data since it does not have key

where are the IV stored? and state machines?

> 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.

becouse 802.11 doesn't state any standard way to decide, in ad-hoc mode,
to which peer connect. So this must be some management decision and
based on that decision the host select some of the peers to connect to. It
could be "don't setup more than 3 security association", so if the host
receives 5 reply response on startup decides which one to consider, but
should still keep other peer information for later use. 

> 
> > 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.

It could be useful to keep knowledge of "near" stations, in case one of
the present link falls and the host wants to open a new connection
withouth probing again. This is even more useful if we imagine that this
kind of state information could be used by higher layer protocols, like
routing ones.

> 
> > 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.

in authenticator eapol_sm.h there is a struct eapol_state_machine which
contains other state machine structures. in wpa_supplicant eapol_sm.c
state machines are not explicitly defined but are identified as a single
variable of type enum identifying their state and sm variables are
elements of the struct itself.is there a reason for this change? 

if I make changes should I just submit them as a patch (which format) 
to the list?

> 
> > 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.

ok. 
since I'm trying to make up my mind on the way to go through the code to
reach my goal suggestions from the list are always really appreciated.

thanks,
leonardo.
-- 
   Key fingerprint = 3129 C583 F03B 2E73 0115  C040 3489 0185 B592 19FE
 Obviously -thisaintpartofmyaddress- is not part of my real email address