1. 27 Feb, 2009 6 commits
    • Randy Dunlap's avatar
      wireless: fix for CONFIG_NL80211=n · 13e967b2
      Randy Dunlap authored
      Add empty function for case of CONFIG_NL80211=n:
      net/wireless/scan.c:35: error: implicit declaration of function 'nl80211_send_scan_aborted'
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Sujith's avatar
      mac80211: Extend the rate control API with an update callback · 81cb7623
      Sujith authored
      The AP can switch dynamically between 20/40 Mhz channel width,
      in which case we switch the local operating channel, but the
      rate control algorithm is not notified. This patch adds a new callback
      to indicate such changes to the RC algorithm.
      Currently, HT channel width change is notified, but this callback
      can be used to indicate any new requirements that might come up later on.
      Signed-off-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: split IBSS/managed code · 46900298
      Johannes Berg authored
      This patch splits out the ibss code and data from managed (station) mode.
      The reason to do this is to better separate the state machines, and have
      the code be contained better so it gets easier to determine what exactly
      a given change will affect, that in turn makes it easier to understand.
      This is quite some churn, especially because I split sdata->u.sta into
      sdata->u.mgd and sdata->u.ibss, but I think it's easier to maintain that
      way. I've also shuffled around some code -- null function sending is only
      applicable to managed interfaces so put that into that file, some other
      functions are needed from various places so put them into util, and also
      rearranged the prototypes in ieee80211_i.h accordingly.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: fix aggregation for hardware with ampdu queues · 96f5e66e
      Johannes Berg authored
      Hardware with AMPDU queues currently has broken aggregation.
      This patch fixes it by making all A-MPDUs go over the regular AC queues,
      but keeping track of the hardware queues in mac80211. As a first rough
      version, it actually stops the AC queue for extended periods of time,
      which can be removed by adding buffering internal to mac80211, but is
      currently not a huge problem because people rarely use multiple TIDs
      that are in the same AC (and iwlwifi currently doesn't operate as AP).
      This is a short-term fix, my current medium-term plan, which I hope to
      execute soon as well, but am not sure can finish before .30, looks like
       1) rework the internal queuing layer in mac80211 that we use for
          fragments if the driver stopped queue in the middle of a fragmented
          frame to be able to queue more frames at once (rather than just a
          single frame with its fragments)
       2) instead of stopping the entire AC queue, queue up the frames in a
          per-station/per-TID queue during aggregation session initiation,
          when the session has come up take all those frames and put them
          onto the queue from 1)
       3) push the ampdu queue layer abstraction this patch introduces in
          mac80211 into the driver, and remove the virtual queue stuff from
          mac80211 again
      This plan will probably also affect ath9k in that mac80211 queues the
      frames instead of passing them down, even when there are no ampdu queues.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      mac80211: disallow moving netns · 076ae609
      Johannes Berg authored
      mac80211 currently assumes init_net for all interfaces,
      so really will not cope well with network namespaces,
      at least at this time.
      To change this, we would have keep track of the netns
      in addition to the ifindex, which is not something I
      want to think about right now.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Vasanthakumar Thiagarajan's avatar
      mac80211: Make sure non-HT connection when IEEE80211_STA_TKIP_WEP_USED is set · 53d6f81c
      Vasanthakumar Thiagarajan authored
      It is possible that some broken AP might send HT IEs in it's
      assoc response even though the STA has not sent them in assoc req
      when WEP/TKIP is used as pairwise cipher suite. Also it is important
      to check this bit before enabling ht mode in beacon receive path.
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  2. 25 Feb, 2009 5 commits
  3. 24 Feb, 2009 3 commits
    • Joe Perches's avatar
      tcp_scalable: Update malformed & dead url · a52b8bd3
      Joe Perches authored
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Josef Drexler's avatar
      netfilter: xt_recent: fix proc-file addition/removal of IPv4 addresses · 325fb5b4
      Josef Drexler authored
      Fix regression introduded by commit 079aa88f (netfilter: xt_recent: IPv6 support):
      From http://bugzilla.kernel.org/show_bug.cgi?id=12753:
      Problem Description:
      An uninitialized buffer causes IPv4 addresses added manually (via the +IP
      command to the proc interface) to never match any packets. Similarly, the -IP
      command fails to remove IPv4 addresses.
      In the function recent_entry_lookup, the xt_recent module does comparisons of
      the entire nf_inet_addr union value, both for IPv4 and IPv6 addresses. For
      addresses initialized from actual packets the remaining 12 bytes not occupied
      by the IPv4 are zeroed so this works correctly. However when setting the
      nf_inet_addr addr variable in the recent_mt_proc_write function, only the IPv4
      bytes are initialized and the remaining 12 bytes contain garbage.
      Hence addresses added in this way never match any packets, unless these
      uninitialized 12 bytes happened to be zero by coincidence. Similarly, addresses
      cannot consistently be removed using the proc interface due to mismatch of the
      garbage bytes (although it will sometimes work to remove an address that was
      added manually).
      Reading the /proc/net/xt_recent/ entries hides this problem because this only
      uses the first 4 bytes when displaying IPv4 addresses.
      Steps to reproduce:
      $ iptables -I INPUT -m recent --rcheck -j LOG
      $ echo + > /proc/net/xt_recent/DEFAULT
      $ cat /proc/net/xt_recent/DEFAULT
      src= ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      [At this point no packets from are being logged.]
      $ iptables -I INPUT -s -m recent --set
      $ cat /proc/net/xt_recent/DEFAULT
      src= ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      src= ttl: 255 last_seen: 126184 oldest_pkt: 4 125434, 125684, 125934, 126184
      [At this point, adding the address via an iptables rule, packets are being
      logged correctly.]
      $ echo - > /proc/net/xt_recent/DEFAULT
      $ cat /proc/net/xt_recent/DEFAULT
      src= ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      src= ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
      $ echo - > /proc/net/xt_recent/DEFAULT
      $ cat /proc/net/xt_recent/DEFAULT
      src= ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      src= ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
      [Removing the address via /proc interface failed evidently.]
      Possible solutions:
      - initialize the addr variable in recent_mt_proc_write
      - compare only 4 bytes for IPv4 addresses in recent_entry_lookup
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
    • Jesper Dangaard Brouer's avatar
      Doc: Refer to ip-sysctl.txt for strict vs. loose rp_filter mode · d18921a0
      Jesper Dangaard Brouer authored
      The IP_ADVANCED_ROUTER Kconfig describes the rp_filter
      proc option.  Recent changes added a loose mode.
      Instead of documenting this change too places, refer to
      the document describing it:
      I'm considering moving the rp_filter description away
      from the Kconfig file into ip-sysctl.txt.
      Signed-off-by: default avatarJesper Dangaard Brouer <hawk@comx.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 23 Feb, 2009 2 commits
  5. 22 Feb, 2009 13 commits
  6. 21 Feb, 2009 1 commit
  7. 20 Feb, 2009 2 commits
  8. 18 Feb, 2009 6 commits
  9. 17 Feb, 2009 1 commit
    • David S. Miller's avatar
      net: Kill skb_truesize_check(), it only catches false-positives. · 92a0acce
      David S. Miller authored
      A long time ago we had bugs, primarily in TCP, where we would modify
      skb->truesize (for TSO queue collapsing) in ways which would corrupt
      the socket memory accounting.
      skb_truesize_check() was added in order to try and catch this error
      more systematically.
      However this debugging check has morphed into a Frankenstein of sorts
      and these days it does nothing other than catch false-positives.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 16 Feb, 2009 1 commit