share/man/man9/ieee80211_beacon.9

   1 .\"
   2 .\" Copyright (c) 2009 Sam Leffler, Errno Consulting
   3 .\" All rights reserved.
   4 .\"
   5 .\" Redistribution and use in source and binary forms, with or without
   6 .\" modification, are permitted provided that the following conditions
   7 .\" are met:
   8 .\" 1. Redistributions of source code must retain the above copyright
   9 .\"    notice, this list of conditions and the following disclaimer.
  10 .\" 2. Redistributions in binary form must reproduce the above copyright
  11 .\"    notice, this list of conditions and the following disclaimer in the
  12 .\"    documentation and/or other materials provided with the distribution.
  13 .\"
  14 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
  15 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  16 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  17 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  18 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  19 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  20 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  21 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  22 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  23 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  24 .\" SUCH DAMAGE.
  25 .\"
  26 .\" $FreeBSD: src/share/man/man9/ieee80211_beacon.9,v 1.2 2009/09/18 00:33:47 brueffer Exp $
  27 .\"
  28 .Dd April 28, 2010
  29 .Dt IEEE80211_BEACON 9
  30 .Os
  31 .Sh NAME
  32 .Nm ieee80211_beacon
  33 .Nd 802.11 beacon support
  34 .Sh SYNOPSIS
  35 .In net/if.h
  36 .In net/if_media.h
  37 .In netproto/802_11/ieee80211_var.h
  38 .Pp
  39 .Ft "struct mbuf *"
  40 .Fo ieee80211_beacon_alloc
  41 .Fa "struct ieee80211_node *"
  42 .Fa "struct ieee80211_beacon_offsets *"
  43 .Fc
  44 .\"
  45 .Ft int
  46 .Fo ieee80211_beacon_update
  47 .Fa "struct ieee80211_node *"
  48 .Fa "struct ieee80211_beacon_offsets *"
  49 .Fa "struct mbuf *"
  50 .Fa "int mcast"
  51 .Fc
  52 .\"
  53 .Ft void
  54 .Fn ieee80211_beacon_notify "struct ieee80211vap *" "int what"
  55 .Sh DESCRIPTION
  56 The
  57 .Nm net80211
  58 software layer provides a support framework for drivers that includes
  59 a template-based mechanism for dynamic update of beacon frames transmit
  60 in hostap, adhoc, and mesh operating modes.
  61 Drivers should use
  62 .Fn ieee80211_beacon_alloc
  63 to create an initial beacon frame.
  64 The
  65 .Vt ieee80211_beacon_offsets
  66 structure holds information about the beacon contents that is used
  67 to optimize updates done with
  68 .Fn ieee80211_beacon_update .
  69 .Pp
  70 Update calls should only be done when something changes that
  71 affects the contents of the beacon frame.
  72 When this happens the
  73 .Dv iv_update_beacon
  74 method is invoked and a driver-supplied routine must do the right thing.
  75 For devices that involve the host to transmit each
  76 beacon frame this work may be as simple as marking a bit in the
  77 .Vt ieee80211_beacon_offsets
  78 structure:
  79 .Bd -literal
  80 static void
  81 ath_beacon_update(struct ieee80211vap *vap, int item)
  82 {
  83         struct ieee80211_beacon_offsets *bo = &ATH_VAP(vap)->av_boff;
  84         setbit(bo->bo_flags, item);
  85 }
  86 .Ed
  87 .Pp
  88 with the
  89 .Fn ieee80211_beacon_update
  90 call done before the next beacon is to be sent.
  91 .Pp
  92 Devices that off-load beacon generation may instead choose to use
  93 this callback to push updates immediately to the device.
  94 Exactly how that is accomplished is unspecified.
  95 One possibility is to update the beacon frame contents and extract
  96 the appropriate information element, but other scenarios are possible.
  97 .Sh MULTI-VAP BEACON SCHEDULING
  98 Drivers that support multiple vaps that can each beacon need to consider
  99 how to schedule beacon frames.
 100 There are two possibilities at the moment:
 101 .Em burst
 102 all beacons at TBTT or
 103 .Em stagger beacons
 104 over the beacon interval.
 105 Bursting beacon frames may result in aperiodic delivery that can affect
 106 power save operation of associated stations.
 107 Applying some jitter (e.g. by randomly ordering burst frames) may be
 108 sufficient to combat this and typically this is not an issue unless
 109 stations are using aggressive power save techniques
 110 such as U-APSD (sometimes employed by VoIP phones).
 111 Staggering frames requires more interrupts and device support that
 112 may not be available.
 113 Staggering beacon frames is usually superior to bursting frames, up to
 114 about eight vaps, at which point the overhead becomes significant and
 115 the channel becomes noticeably busy anyway.
 116 .Sh SEE ALSO
 117 .Xr ieee80211 9