Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
IEEE8021_VAP(9)	       FreeBSD Kernel Developer's Manual       IEEE8021_VAP(9)

     net80211_vap -- 802.11 network layer virtual radio	support

     #include <net80211/ieee80211_var.h>

     ieee80211_vap_setup(struct	ieee80211com *,	struct ieee80211vap *,
	 const char name[IFNAMSIZ], int	unit, int opmode, int flags,
	 const uint8_t bssid[IEEE80211_ADDR_LEN],
	 const uint8_t macaddr[IEEE80211_ADDR_LEN]);

     ieee80211_vap_attach(struct ieee80211vap *, ifm_change_cb_t media_change,
	 ifm_stat_cb_t media_stat);

     ieee80211_vap_detach(struct ieee80211vap *);

     The net80211 software layer provides a support framework for drivers that
     includes a	virtual	radio API that is exported to users through network
     interfaces	(aka vaps) that	are cloned from	the underlying device.	These
     interfaces	have an	operating mode (station, adhoc,	hostap,	wds, monitor,
     etc.) that	is fixed for the lifetime of the interface.  Devices that can
     support multiple concurrent interfaces allow multiple vaps	to be cloned.

     The virtual radio interface defined by the	net80211 layer means that
     drivers must be structured	to follow specific rules.  Drivers that	sup-
     port only a single	interface at any time must still follow	these rules.

     The virtual radio architecture splits state between a single per-device
     ieee80211com structure and	one or more ieee80211vap structures.  Vaps are
     created with the SIOCIFCREATE2 request.  This results in a	call into the
     driver's ic_vap_create method where the driver can	decide if the request
     should be accepted.

     The vap creation process is done in three steps.  First the driver	allo-
     cates the data structure with malloc(9).  This data structure must	have
     an	ieee80211vap structure at the front but	is usually extended with
     driver-private state.  Next the vap is setup with a call to
     ieee80211_vap_setup().  This request initializes net80211 state but does
     not activate the interface.  The driver can then override methods setup
     by	net80211 and setup driver resources before finally calling
     ieee80211_vap_attach() to complete	the process.  Both these calls must be
     done without holding any driver locks as work may require the process

     A vap is deleted when an SIOCIFDESTROY ioctl request is made or when the
     device detaches (causing all associated vaps to automatically be
     deleted).	Delete requests	cause the ic_vap_delete	method to be called.
     Drivers must quiesce the device before calling ieee80211_vap_detach() to
     deactivate	the vap	and isolate it from activities such as requests	from
     user applications.	 The driver can	then reclaim resources held by the vap
     and re-enable device operation.  The exact	procedure for quiescing	a de-
     vice is unspecified but typically it involves blocking interrupts and
     stopping transmit and receive processing.

     Drivers are responsible for deciding if multiple vaps can be created and
     how to manage them.  Whether or not multiple concurrent vaps can be sup-
     ported depends on a device's capabilities.	 For example, multiple hostap
     vaps can usually be supported but many devices do not support assigning
     each vap a	unique BSSID.  If a device supports hostap operation it	can
     usually support concurrent	station	mode vaps but possibly with limita-
     tions such	as losing support for hardware beacon miss support.  Devices
     that are capable of hostap	operation and can send and receive 4-address
     frames should be able to support WDS vaps together	with an	ap vap.	 But
     in	contrast some devices cannot support WDS vaps without at least one ap
     vap (this however can be finessed by forcing the ap vap to	not transmit
     beacon frames).  All devices should support the creation of any number of
     monitor mode vaps concurrent with other vaps but it is the	responsibility
     of	the driver to allow this.

     An	important consequence of supporting multiple concurrent	vaps is	that a
     driver's iv_newstate method must be written to handle being called	for
     each vap.	Where necessary, drivers must track private state for all vaps
     and not just the one whose	state is being changed (e.g. for handling bea-
     con timers	the driver may need to know if all vaps	that beacon are
     stopped before stopping the hardware timers).

     ieee80211(9), ifnet(9), malloc(9)

FreeBSD	13.0			August 4, 2009			  FreeBSD 13.0


Want to link to this manual page? Use this URL:

home | help