From: Jouni Malinen <j@w1.fi>
To: Alina Friedrichsen <x-alina@gmx.net>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] Fixed BSSID step 3: Don't merge with the same BSSID
Date: Sat, 10 Jan 2009 11:16:59 +0200 [thread overview]
Message-ID: <20090110091659.GC1170@jm.kir.nu> (raw)
In-Reply-To: <20090109205315.277310@gmx.net>
On Fri, Jan 09, 2009 at 09:53:15PM +0100, Alina Friedrichsen wrote:
> As I see, only the sta_info_flush_delayed() call causes the problems. I can only disable this call in the ieee80211_sta_join_ibss() function, if the BSSID is the same. Do you think this would be better?
Yes, I think it would be better option than removing it and the reset_tsf()
call. Removing STA entries for other IBSS members in any merge case,
even if BSSID changes, does not sound correct in the first place. This
should really only be done if the SSID changes.
> > In other words, I would be fine if the calls to
> > ieee80211_sta_join_ibss() and ieee80211_ibss_add_sta() are replaced with
> > local->ops->reset_tsf() if BSSIDs are the same when
> > beacon_timestamp>rx_timestamp.
>
> This would be a way, too.
Looking at ieee80211_sta_join_ibss(), most of the stuff there should not
really be needed if BSSID remains the same and we are only syncing our
TSF. reset_tsf() call should be enough for that. Other parts of this
function, apart from sta_info_flush_delayed(), should be run if BSSID
changes. sta_info_flush_delayed() should be included only if SSID
changes (or maybe if we join back to the same IBSS after a long time,
but I'm not too concerned about that corner case).
I think bit more cleanup here by splitting ieee80211_sta_join_ibss()
into pieces and only calling some of them in the merge/timesync case
would be the best solution. For the particular problem that you are
seeing, the minimal change would probably be just to make
sta_info_flush_delayed() call conditional on SSID change (I don't think
this would need to be based on BSSID change).
--
Jouni Malinen PGP id EFC895FA
next prev parent reply other threads:[~2009-01-10 9:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-06 2:01 [PATCH] Fixed BSSID step 3: Don't merge with the same BSSID Alina Friedrichsen
2009-01-08 9:10 ` Jouni Malinen
2009-01-09 20:53 ` Alina Friedrichsen
2009-01-10 9:16 ` Jouni Malinen [this message]
2009-01-12 4:15 ` Alina Friedrichsen
2009-01-12 17:35 ` Jouni Malinen
2009-01-17 3:39 ` [PATCH] Fixed BSSID (timesync) Alina Friedrichsen
2009-01-17 3:51 ` Alina Friedrichsen
2009-01-17 22:12 ` [PATCH] Fixed BSSID step 3: Don't merge with the same BSSID Alina Friedrichsen
2009-01-20 15:10 ` Jouni Malinen
2009-01-20 18:56 ` Alina Friedrichsen
2009-01-21 8:45 ` Jouni Malinen
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=20090110091659.GC1170@jm.kir.nu \
--to=j@w1.fi \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=x-alina@gmx.net \
/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).