From: Simon Wunderlich <sw@simonwunderlich.de>
To: Sujith Manoharan <sujith@msujith.org>
Cc: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>,
"ath9k-devel@lists.ath9k.org" <ath9k-devel@lists.ath9k.org>,
linux-wireless@vger.kernel.org,
Antonio Quartulli <antonio@meshcoding.com>
Subject: IBSS can't beacon after rejoin / regression in TSF syncing code?
Date: Fri, 24 Jan 2014 18:26:44 +0100 [thread overview]
Message-ID: <201401241826.45121.sw@simonwunderlich.de> (raw)
Hi Sujith and list(s),
we have found a regression in the IBSS creation/joining part of mac80211 which
is appearently connected to the TSF-syncing patches introduced last year[1].
It prevents beaconing of an adhoc member after rejoining a cell when this cell
is currently empty. The problem is present in at least 3.10 and 3.13.
To reproduce, use two adhoc peers and let them join/leave in the following
order:
station 1: join
station 2: join
station 2: leave
station 1: leave
station 1: join
now we would expect that station 1 sends beacons, but it doesn't. After
inspecting the code, station 1 actually selected the "old" ibss network and
waits for a beacon to sync the tsf which is never received, as all members
already left the network. An easy workaround is to set the IBSS creator always
to true.
Since this kind of "race condition" could be solved in various ways, e.g. a
timeout in ibss code, timeout in ath9k, ... i'd like to hear your opinions or
ideas how to fix it.
Thanks,
Simon
[1] mac80211: Notify new IBSS network creation
(c13a765bd96f4e2f52d218ee6e5c0715380eeeb8)
ath9k: Fix IBSS joiner mode (1a6404a1d8497692f31808319d662c739033c491)
[2] actual commands I used:
iw dev wlan0 ibss join "rejointest" 5180 HT40+ fixed-freq 02:de:ad:be:ee:ef
iw dev wlan0 ibss leave
next reply other threads:[~2014-01-24 17:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 17:26 Simon Wunderlich [this message]
2014-01-27 4:25 ` IBSS can't beacon after rejoin / regression in TSF syncing code? Sujith Manoharan
2014-01-27 13:27 ` Simon Wunderlich
2014-01-27 13:34 ` Simon Wunderlich
2014-01-28 1:41 ` Sujith Manoharan
2014-01-28 7:29 ` Antonio Quartulli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201401241826.45121.sw@simonwunderlich.de \
--to=sw@simonwunderlich.de \
--cc=antonio@meshcoding.com \
--cc=ath9k-devel@lists.ath9k.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mathias.kretschmer@fokus.fraunhofer.de \
--cc=sujith@msujith.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).