Properties for Network interface

Marcel Holtmann marcel at holtmann.org
Mon Jan 4 04:53:43 EST 2010


Hi guys,

so with all the changes (already merged and pending) we have the
Interface and BSS interfaces pretty much in shape. They looks pretty
good and are easy to use.

The Network interface is still a pain in the butt. So right now it
contains two properties:

	Properties	: dict of wpa_supplicant network block
	Enabled		: boolean if network is enabled or not

The properties of properties is not a good idea here. I think what we
have to do is define our own set of properties for networks and then
match them up to internal wpa_supplicant details. This will keep the API
clean and remove some of the confusions. Especially the all strings
values are pretty bad. Also this way the API can be consistent and
property names used in BSS or Capabilities match up.

I am not sure about all possible security configuration, but in the end
we can add them later on when needed. So lets start a proposal.

	SSID		: array{byte}
	Mode		: string	("infrastructure" or "ad-hoc")
	Protocol	: string	("rsn", "wpa" or "")
	KeyMgmt		: string	(like in Capabilities)
	AuthAlg		: array{string}	(like in Capabilities)
	Pairwise	: array{string}	(like in Capabilities)
	Group		: string	(like in Capabilities)
	KeyIndex	: byte
	Key0		: array{byte}
	PSK		: array{byte}
	Priority	: byte

So the SSID and Mode are pretty clear I guess. I do prefer to have the
SSID as byte array. Since that way we could actually match them up with
the results BSSs. Converting a string into a hex SSID is always simpler
than the other way around.

For Protocol and KeyMgmt, I am not sure if it would make sense to
provide an array of possible option. I guess not. The "" in Protocol
would allow to auto-detect RSN or WPA and that should be fine.

For Group, I assume we never have to provide a list of valid options. So
just providing the group cipher or "" for automatic should be enough. In
case of Pairwise, I am not sure how much useful it is to provide a list
of valid option. Or just only allow one or "" for automatic.

The AuthAlg should support multiple options. I have used "OPEN SHARED"
often to not have to bother with the details. And I think it is best to
leave this up to wpa_supplicant or the kernel instead of having the
client to figure this out. If not, then we could clearly make this a
string.

For the Key[1-4] and PSK we should use the hex version and the client
has to convert them. I really dislike the magic with detecting that it
is a string or not.

Some of these properties could be actually read-write when the network
is not connected. For example Priority is a good candidate that might be
changed at runtime.

Thoughts?

Regards

Marcel




More information about the HostAP mailing list