On Fri, Oct 18, 2002 at 10:32:31AM +0900, Atsushi Onoe wrote:
> > When a STA sends a Reassociate Request to an AP, it is necessary for
> > the AP to confirm that the STA is already associated with an AP in the
> > ESS. The Reassociate Request contains a Current BSSID. Call the recipient
> > of the Request, the New AP, and its BSSID, the New BSSID.
> 
> OK.  I'm afraid how firm these API can be defined generally enough.
> 
> How about adding a knob to disable any state transitions within kernel,
> and "Host AP daemon" will receive and send all management frames via bpf?
> It requires to duplicate code from kernel to the daemon, but it will
> provide full flexibility as best as we can offer for future development
> and experiment.

  Full flexibility is good, however, 802.11 only provides for an AP
  client to move in a small state space, with usually a couple of
  possible transitions at each state. Thus a hostap daemon which uses
  bpf to receive and send 802.11 management messages will scarcely
  be more flexible than one which uses an API to answer the messages,
  unless the daemon wants to break the 802.11 standard.  Perhaps there
  is something I am missing?

  I see at two advantages to an hostap API over bpf.  One advantage to an
  hostap API is that it lets one reuse the code you have programmed, thus
  allowing one to thriftily program and operate a hostap daemon. Another
  advantage is that the constraints on perfect flexibility which an
  API will impose are beneficial. They protect against an AP that would
  misbehave by sending malformed or out-of-order responses.  There is a
  movement in UNIXes, and in operating systems generally, to run programs
  with bare minimum privileges. I think that examining and injecting all
  kinds of packets is a greater privilege than a hostap daemon will need.

  I believe an API for hostap daemons can be frugally implemented.  In a
  nutshell, the implementation will place a hook for hostap daemons in
  the ieee80211_recv_X methods, prior to the call to IEEE80211_SEND_MGMT,
  e.g.,

	if (ic->ic_hostapd) {
		IEEE80211_HOSTAPD_NOTIFY(ic, ni, resp, ...);
		return;
	}
        IEEE80211_SEND_MGMT(ic, ni, resp, IEEE80211_STATUS_SUCCESS);

  IEEE80211_HOSTAPD_NOTIFY queues the tuple (ni, resp) and sets a timer
  for it.  Then it sends a message to the daemon, who may elect to respond
  within the time-out interval to indicate success/failure, according to
  its policy.  If the timer expires before the hostap daemon responds,
  the 802.11 subsystem may send its own mgmt response, according to the
  default policy (permit/deny/drop).

  So you see, this simply results in the postponement of the call to
  IEEE80211_SEND_MGMT until the hostap daemon has a chance to intervene,
  and the postponement will only occur in the event that there is actually
  a daemon listening.

  In the 802.11 subsystem, I think that four lines of code per
  ieee80211_recv_X method, such as what I wrote above, will provide the
  hooks for the daemon API.  The ieee80211com will need a new member,
  ic_hostapd, too. Most of the remaining code will go into an optional
  module.

  Your thoughts?

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933