Initialization of beacon transmission in IBSS mode depends
on whether a new BSS is being created or joined. When joining
an existing IBSS network, beaconing has to start only after
a TSF-sync has happened - this is explained in 11.1.4.
Introduce a new parameter in the BSS information structure to
indicate creator/joiner mode.
Signed-off-by: Sujith Manoharan <[email protected]>
---
include/net/mac80211.h | 2 ++
net/mac80211/ibss.c | 11 ++++++++---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 82558c8..512dc4b 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -223,6 +223,7 @@ enum ieee80211_rssi_event {
* @assoc: association status
* @ibss_joined: indicates whether this station is part of an IBSS
* or not
+ * @ibss_creator: indicates if a new IBSS network is being created
* @aid: association ID number, valid only when @assoc is true
* @use_cts_prot: use CTS protection
* @use_short_preamble: use 802.11b short preamble;
@@ -278,6 +279,7 @@ struct ieee80211_bss_conf {
const u8 *bssid;
/* association related data */
bool assoc, ibss_joined;
+ bool ibss_creator;
u16 aid;
/* erp related data */
bool use_cts_prot;
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 5f3620f..5c6c773 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -39,7 +39,8 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
const u8 *bssid, const int beacon_int,
struct ieee80211_channel *chan,
const u32 basic_rates,
- const u16 capability, u64 tsf)
+ const u16 capability, u64 tsf,
+ bool creator)
{
struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
struct ieee80211_local *local = sdata->local;
@@ -72,6 +73,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
/* if merging, indicate to driver that we leave the old IBSS */
if (sdata->vif.bss_conf.ibss_joined) {
sdata->vif.bss_conf.ibss_joined = false;
+ sdata->vif.bss_conf.ibss_creator = false;
netif_carrier_off(sdata->dev);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_IBSS);
}
@@ -197,6 +199,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
bss_change |= BSS_CHANGED_HT;
bss_change |= BSS_CHANGED_IBSS;
sdata->vif.bss_conf.ibss_joined = true;
+ sdata->vif.bss_conf.ibss_creator = creator;
ieee80211_bss_info_change_notify(sdata, bss_change);
ieee80211_sta_def_wmm_params(sdata, sband->n_bitrates, supp_rates);
@@ -249,7 +252,8 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
cbss->channel,
basic_rates,
cbss->capability,
- cbss->tsf);
+ cbss->tsf,
+ false);
}
static struct sta_info *ieee80211_ibss_finish_sta(struct sta_info *sta,
@@ -715,7 +719,7 @@ static void ieee80211_sta_create_ibss(struct ieee80211_sub_if_data *sdata)
__ieee80211_sta_join_ibss(sdata, bssid, sdata->vif.bss_conf.beacon_int,
ifibss->channel, ifibss->basic_rates,
- capability, 0);
+ capability, 0, true);
}
/*
@@ -1197,6 +1201,7 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
lockdep_is_held(&sdata->u.ibss.mtx));
RCU_INIT_POINTER(sdata->u.ibss.presp, NULL);
sdata->vif.bss_conf.ibss_joined = false;
+ sdata->vif.bss_conf.ibss_creator = false;
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON_ENABLED |
BSS_CHANGED_IBSS);
synchronize_rcu();
--
1.7.12
On Wed, 2012-09-26 at 09:12 +0530, Sujith Manoharan wrote:
> Initialization of beacon transmission in IBSS mode depends
> on whether a new BSS is being created or joined. When joining
> an existing IBSS network, beaconing has to start only after
> a TSF-sync has happened - this is explained in 11.1.4.
>
> Introduce a new parameter in the BSS information structure to
> indicate creator/joiner mode.
Interesting, I guess this makes sense. Never seemed to come up, maybe it
doesn't matter all that much since we sync once we receive some other
beacon, so worst case we just transmit a few spuriously?
johannes
On Wed, 2012-09-26 at 13:37 +0530, Sujith Manoharan wrote:
> Johannes Berg wrote:
> > That looks a bit different from what I thought though? Not really sure I
> > understand that though :-)
>
> The basic issue was that we were not initializing the timers based on
> the sync'd TSF.
>
> > What I'm thinking is that if you always just start beaconing, wouldn't
> > you just reset the beacon whenever you notice a higher TSF show up in
> > the network?
> >
> > Actually I think we call reset_tsf() or something like that? But all of
> > that has always seemed very quirky to me.
>
> Currently, I don't think we reset the beacon/timers for IBSS mode.
>
> For station mode, all of this is handled in ath9k using the
> PS_WAIT_FOR_BEACON/PS_BEACON_SYNC flags. For IBSS creator mode, there is
> no problem because mac80211 calls reset_tsf() in __ieee80211_sta_join_ibss().
> For joiner mode, drivers like ath9k need to do a beacon-sync (like station),
> before starting to pollute the environment with beacons, but there is no way to know
> if an existing IBSS network is being joined.
Right, makes sense. I have no objections to this patch, just wanted to
understand the issue better.
johannes
Johannes Berg wrote:
> Interesting, I guess this makes sense. Never seemed to come up, maybe it
> doesn't matter all that much since we sync once we receive some other
> beacon, so worst case we just transmit a few spuriously?
Yes, that was the reported problem:
http://www.spinics.net/lists/linux-wireless/msg96846.html
ath9k programs the TBTT timers etc. based on the HW TSF, but this needs to
be done after a sync has been done (in joiner mode, that is). We do it for
station mode, but IBSS needs to fixed.
Sujith
Johannes Berg wrote:
> Right, makes sense. I have no objections to this patch, just wanted to
> understand the issue better.
Ok, I'll submit it as a patch after some testing. Thanks for the review !
Sujith
Johannes Berg wrote:
> That looks a bit different from what I thought though? Not really sure I
> understand that though :-)
The basic issue was that we were not initializing the timers based on
the sync'd TSF.
> What I'm thinking is that if you always just start beaconing, wouldn't
> you just reset the beacon whenever you notice a higher TSF show up in
> the network?
>
> Actually I think we call reset_tsf() or something like that? But all of
> that has always seemed very quirky to me.
Currently, I don't think we reset the beacon/timers for IBSS mode.
For station mode, all of this is handled in ath9k using the
PS_WAIT_FOR_BEACON/PS_BEACON_SYNC flags. For IBSS creator mode, there is
no problem because mac80211 calls reset_tsf() in __ieee80211_sta_join_ibss().
For joiner mode, drivers like ath9k need to do a beacon-sync (like station),
before starting to pollute the environment with beacons, but there is no way to know
if an existing IBSS network is being joined.
Sujith
On Wed, 2012-09-26 at 12:59 +0530, Sujith Manoharan wrote:
> Johannes Berg wrote:
> > Interesting, I guess this makes sense. Never seemed to come up, maybe it
> > doesn't matter all that much since we sync once we receive some other
> > beacon, so worst case we just transmit a few spuriously?
>
> Yes, that was the reported problem:
> http://www.spinics.net/lists/linux-wireless/msg96846.html
That looks a bit different from what I thought though? Not really sure I
understand that though :-)
What I'm thinking is that if you always just start beaconing, wouldn't
you just reset the beacon whenever you notice a higher TSF show up in
the network?
Actually I think we call reset_tsf() or something like that? But all of
that has always seemed very quirky to me.
johannes