Search Linux Wireless

Re: [PATCH] mac80211: fix rate_control_send_low warnings for delbas

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 28, 2010 at 10:20 PM, Vasanthakumar Thiagarajan
<vasanth@xxxxxxxxxxx> wrote:
> On Wed, Sep 29, 2010 at 05:28:35AM +0530, Luis R. Rodriguez wrote:
>> On Tue, Sep 28, 2010 at 4:02 PM, Jouni Malinen <j@xxxxx> wrote:
>> > On Tue, Sep 28, 2010 at 03:29:45PM -0700, Luis R. Rodriguez wrote:
>> >
>> >> Added support for cfg80211/mac80211 to cleanly roam between two BSSes
>> >> on an ESS by allowing the station to reassociate to an old AP and
>> >> only when that is done drop the old association. What we forgot to
>> >> take into consideration is that when we disassociate with the older
>> >> AP we may need to transmit frames to that AP and those frames may
>> >> actually be intended to go under a different channel and even sometimes
>> >> a completely separate band than the new APs.
>> >
>> > which frames are you talking about here?
>>
>> ieee80211_send_delba()
>>
>> > When reassociating to a new BSS
>> > in an ESS, there should be no need to transmit frames to the old AP
>> > anymore, i.e., we are never associated with more than one BSS (when
>> > talking about a single vif). We could just drop any potential TX frame
>> > to the old AP after the moment the new AP is marked associated.
>>
>> That's the goal of this patch.
>
> From my debugging, this happens when cleaning up BA session for old
> AP but on a different channel

Right.

> (where we just authenticated with another AP)

Not sure I get this part.

> just before starting association with the new AP.

Right, but when we are already switched to the new channel, and the
reason is that when we try to send a frame we never kept track of the
peer's original channel. Now, I also see the teardown happen right
before mac80211 tells us its associated to the new AP as well but it
not sure what cfg80211 thinks at that point. At least the cfg80211
patch's intention seemed to be to allow association to both, and
tearing down the association to the other once you completed
association to the other. I do see, what you describe though too --
only authentication to the new AP, and right before association, we
send the teardown. The problem is though that when we send the
teardown we are already set on the new channel.

> Though local->work_work takes care of moving to right channel,

When we TX a frame we use  local->hw.conf.channel which would be the
new AP's channel, this is wrong, but we never kept track of the peer's
original channel so there no way to know the original channel.

> it is possible that cfg80211 receives NL80211_CMD_ASSOCIATE before
> local->work_work configures the hw back to old AP's channel (that
> is what happening in our case).

And how would mac80211 or cfg80211 know what channel that was?

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux