06 Sep, 2012

1 commit


20 Aug, 2012

1 commit

  • After cfg80211 got a P2P Device abstraction, add
    support to mac80211. Whether it really is supported
    or not will depend on whether or not the driver has
    support for it, but mac80211 needs to change to be
    able to support drivers that need a P2P Device.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

13 Jul, 2012

1 commit


09 Jul, 2012

1 commit

  • The management frame and remain-on-channel APIs will be
    needed in the P2P device abstraction, so move them over
    to the new wdev-based APIs. Userspace can still use both
    the interface index and wdev identifier for them so it's
    backward compatible, but for the P2P Device wdev it will
    be able to use the wdev identifier only.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

24 Jun, 2012

1 commit


21 Jun, 2012

1 commit

  • When a remain-on-channel item is deleted, we remove it
    from the list and then start the next item. However,
    if it wasn't actually the first item then calling
    ieee80211_start_next_roc() is wrong as it will start
    the first item -- even if that was already started.

    Fix the two places that do this and add a warning to
    prevent the problem from reoccurring.

    Reported-by: Eliad Peller
    Signed-off-by: Johannes Berg

    Johannes Berg
     

20 Jun, 2012

1 commit


11 Jun, 2012

1 commit


07 Jun, 2012

2 commits

  • Redesign all the off-channel code, getting rid of
    the generic off-channel work concept, replacing
    it with a simple remain-on-channel list.

    This fixes a number of small issues with the ROC
    implementation:
    * offloaded remain-on-channel couldn't be queued,
    now we can queue it as well, if needed
    * in iwlwifi (the only user) offloaded ROC is
    mutually exclusive with scanning, use the new
    queue to handle that case -- I expect that it
    will later depend on a HW flag

    The bigger issue though is that there's a bad bug
    in the current implementation: if we get a mgmt
    TX request while HW roc is active, and this new
    request has a wait time, we actually schedule a
    software ROC instead since we can't guarantee the
    existing offloaded ROC will still be that long.
    To fix this, the queuing mechanism was needed.

    The queuing mechanism for offloaded ROC isn't yet
    optimal, ideally we should add API to have the HW
    extend the ROC if needed. We could add that later
    but for now use a software implementation.

    Overall, this unifies the behaviour between the
    offloaded and software-implemented case as much
    as possible.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • The IDLE handling in HW off-channel is broken right
    now since we turn off IDLE only when the off-channel
    period already started. Therefore, all drivers that
    use it today (only iwlwifi!) must support off-channel
    while idle, so playing with idle isn't needed at all.

    Off-channel in general, since it's no longer used for
    authentication/association, shouldn't affect PS, so
    also remove that logic.

    Also document a small caveat for reporting TX status
    from off-channel frames in HW remain-on-channel.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

05 Jun, 2012

1 commit

  • When any interface goes down, it could be the one that we
    were doing a remain-on-channel with. We therefore need to
    cancel the remain-on-channel and flush the related work
    structs so they don't run after the interface has been
    removed or even destroyed.

    It's also possible in this case that an off-channel SKB
    was never transmitted, so free it if this is the case.
    Note that this can also happen if the driver finishes
    the off-channel period without ever starting it.

    Cc: stable@kernel.org
    Reported-by: Nirav Shah
    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

05 Jan, 2012

2 commits

  • ieee80211_offchannel_enable_all_ps function is no longer used
    and looks like its logic is extensively handled in
    ieee80211_offchannel_stop_vifs

    Signed-off-by: Mohammed Shafi Shajakhan
    Signed-off-by: John W. Linville

    Mohammed Shafi Shajakhan
     
  • If the vif is stopped while it is offchannel (e.g. right
    after p2p negotiation) the SDATA_STATE_OFFCHANNEL flag
    is never get cleared, resulting in various bad effects
    (e.g. GO can't start beaconing).

    Fix it by clearing the SDATA_STATE_OFFCHANNEL flag
    even if the vif is stopped.

    Signed-off-by: Eliad Peller
    Signed-off-by: John W. Linville

    Eliad Peller
     

01 Dec, 2011

1 commit

  • The on-channel work optimisations have caused a
    number of issues, and the code is unfortunately
    very complex and almost impossible to follow.
    Instead of attempting to put in more workarounds
    let's just remove those optimisations, we can
    work on them again later, after we change the
    whole auth/assoc design.

    This should fix rate_control_send_low() warnings,
    see RH bug 731365.

    Cc: stable@vger.kernel.org
    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

23 Nov, 2011

1 commit


18 Nov, 2011

1 commit

  • Some drivers (e.g. ath9k) assume that it's safe to go into low-power mode
    immediately after the idle state changes. To support that, mac80211 even
    calls drv_flush() before that happens.
    In some instances, mac80211 sent a packet right after recalculating the
    idle state, this patch fixes that.

    Signed-off-by: Felix Fietkau
    Signed-off-by: John W. Linville

    Felix Fietkau
     

01 Nov, 2011

1 commit


05 Feb, 2011

1 commit

  • This should decrease un-necessary flushes, on/off channel work,
    and channel changes in cases where the only scanned channel is
    the current operating channel.

    * Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
    and is-scanning flags instead.

    * Add helper method to determine if we are currently configured
    for the operating channel.

    * Do no blindly go off/on channel in work.c Instead, only call
    appropriate on/off code when we really need to change channels.
    Always enable offchannel-ps mode when starting work,
    and disable it when we are done.

    * Consolidate ieee80211_offchannel_stop_station and
    ieee80211_offchannel_stop_beaconing, call it
    ieee80211_offchannel_stop_vifs instead.

    * Accept non-beacon frames when scanning on operating channel.

    * Scan state machine optimized to minimize on/off channel
    transitions. Also, when going on-channel, go ahead and
    re-enable beaconing. We're going to be there for 200ms,
    so seems like some useful beaconing could happen.
    Always enable offchannel-ps mode when starting software
    scan, and disable it when we are done.

    * Grab local->mtx earlier in __ieee80211_scan_completed_finish
    so that we are protected when calling hw_config(), etc.

    * Pass probe-responses up the stack if scanning on local
    channel, so that mlme can take a look.

    Signed-off-by: Ben Greear
    Signed-off-by: John W. Linville

    Ben Greear
     

06 Jan, 2011

2 commits


17 Sep, 2010

2 commits

  • The beacon monitor should be disabled when going off channel
    to prevent spurious warnings and triggering connection
    deterioration work such as sending probe requests. Re-enable
    the beacon monitor once we come back to the home channel.

    This patch has fixes for stable kernels [2.6.34+].

    Cc: stable@kernel.org
    Cc: Paul Stewart
    Cc: Amod Bodas
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • When we go offchannel mac80211 currently leaves alive the
    connection idle monitor. This should be instead postponed
    until we come back to our home channel, otherwise by the
    time we get back to the home channel we could be triggering
    unecesary probe requests. For APs that do not respond to
    unicast probe requests (Nexus One is a simple example) this
    means we essentially get disconnected after the probes
    fails.

    This patch has stable fixes for kernels [2.6.35+]

    Cc: stable@kernel.org
    Cc: Paul Stewart
    Cc: Amod Bodas
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     

28 Aug, 2010

1 commit

  • Somebody noticed this problem, and I outlined
    to them how to fix it, but haven't heard back
    from them. So while I was adding the state
    field I figured I could use it to fix it.

    The problem, as I understand it, is that when
    we go offchannel while the driver has a queue
    stopped, the driver will likely start draining
    the queue and then enable it while offchannel.
    This in turn will enable the interface queue,
    and that leads to transmitting data frames on
    the wrong channel.

    Fix this by keeping track of offchannel status
    per interface, and not enabling the interface
    queues on interfaces that are offchannel when
    the driver enables a queue.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

16 Jan, 2010

1 commit

  • When ieee80211_offchannel_return is called, it needs to re-enabled TX
    queues that have been stopped in ieee80211_offchannel_stop_beaconing or
    ieee80211_offchannel_stop_station. It happens if we are doing a scan with an
    IBSS interface. In this case, the interface stopped transmitting.

    Signed-off-by: Benoit Papillault
    Signed-off-by: John W. Linville

    Benoit Papillault
     

07 Jan, 2010

1 commit


29 Dec, 2009

2 commits