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 56The 57.Nm net80211 58software layer provides a support framework for drivers that includes 59a template-based mechanism for dynamic update of beacon frames transmit 60in hostap, adhoc, and mesh operating modes. 61Drivers should use 62.Fn ieee80211_beacon_alloc 63to create an initial beacon frame. 64The 65.Vt ieee80211_beacon_offsets 66structure holds information about the beacon contents that is used 67to optimize updates done with 68.Fn ieee80211_beacon_update . 69.Pp 70Update calls should only be done when something changes that 71affects the contents of the beacon frame. 72When this happens the 73.Dv iv_update_beacon 74method is invoked and a driver-supplied routine must do the right thing. 75For devices that involve the host to transmit each 76beacon frame this work may be as simple as marking a bit in the 77.Vt ieee80211_beacon_offsets 78structure: 79.Bd -literal 80static void 81ath_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 88with the 89.Fn ieee80211_beacon_update 90call done before the next beacon is to be sent. 91.Pp 92Devices that off-load beacon generation may instead choose to use 93this callback to push updates immediately to the device. 94Exactly how that is accomplished is unspecified. 95One possibility is to update the beacon frame contents and extract 96the appropriate information element, but other scenarios are possible. 97.Sh MULTI-VAP BEACON SCHEDULING 98Drivers that support multiple vaps that can each beacon need to consider 99how to schedule beacon frames. 100There are two possibilities at the moment: 101.Em burst 102all beacons at TBTT or 103.Em stagger beacons 104over the beacon interval. 105Bursting beacon frames may result in aperiodic delivery that can affect 106power save operation of associated stations. 107Applying some jitter (e.g. by randomly ordering burst frames) may be 108sufficient to combat this and typically this is not an issue unless 109stations are using aggressive power save techniques 110such as U-APSD (sometimes employed by VoIP phones). 111Staggering frames requires more interrupts and device support that 112may not be available. 113Staggering beacon frames is usually superior to bursting frames, up to 114about eight vaps, at which point the overhead becomes significant and 115the channel becomes noticeably busy anyway. 116.Sh SEE ALSO 117.Xr ieee80211 9 118