Wired

Jouni Malinen jkmaline at cc.hut.fi
Thu Jun 3 22:49:00 EDT 2004


On Thu, Jun 03, 2004 at 09:13:11AM +0200, Gunter Burchardt wrote:

>  * Sending/Receiving 1x Packets (receive.c)

IEEE 802.11 encapsulation/decapsulation should be separated and the IEEE
802.1X/EAPOL code would only process EAPOL frames.

>  * Detecting of new stations/Detecting disapearing of a station.

- IEEE 802.11 authentication for Host AP driver with hostapd
- IWEVREGISTERED wireless events for IEEE 802.11 drivers with integrated
  IEEE 802.11 management
- EAPOL-Start for wired interfaces (and possible also wireless, if the
  driver does not support IWEVREGISTERED event)

>  * Enabling/Disabling of a port.

ieee802_1x_set_sta_authorized() could be modified to call a function
pointer and each network interface type (e.g., Host AP driver with
hostapd for IEEE 802.11 management, IEEE 802.11 driver with integrated
IEEE 802.11 management, wired Ethernet) would have its own handler
functions.

>  * Setting values for a port (eg. WEP-Keys)

Callback functions per interface type.

> First Point is easy. ieee802_1x_receive() exists allready.
> ieee802_1x_send_data() is 802.11 specific.

IEEE 802.11i pre-authentication required this to change already and
hostapd supports EAPOL over wired Ethernet interface because of this.
ieee802_1x_send() takes in EAP data and encapsulates it in EAPOL frame.
This is sent over Ethernet interface (rsn_preauth_send()) or IEEE 802.11
interface (ieee802_1x_send_data()).

> Did you see other interfaces? What is your opinion about this?

One thing I want to do is more of an internal implementation side issue.
I want to remove requirement for direct access to station table (struct
sta_info) from EAPOL/IEEE 802.1X/RADIUS code. After this, struct
sta_info would only be needed for the case where hostapd is taking care
of IEEE 802.11 auth/assoc. Wired interfaces and wireless drivers with
integrated IEEE 802.11 auth/assoc processing could use a simpler station
table (mostly, just the MAC address would be needed). All EAPOL state
would live in struct eapol_state_machine.

I have this in progress, so if you plan on changing more or less
anything in hostapd, the likelyhood of getting merging conflicts is
quite high now. In other words, checking CVS often and giving some
notification of planned changes before spending lot of time on them
would be recommended. In addition, I prefer going small step at a time,
so I would not like to receive multi-thousand line patch some day..
Short and simple patches more often is the way to go.

-- 
Jouni Malinen                                            PGP id EFC895FA



More information about the HostAP mailing list