1. 28 2月, 2009 4 次提交
    • J
      mac80211: split IBSS/managed code · 46900298
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      46900298
    • J
      mac80211: fix aggregation for hardware with ampdu queues · 96f5e66e
      Johannes Berg 提交于
      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
      this:
       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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      96f5e66e
    • J
      mac80211: disallow moving netns · 076ae609
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      076ae609
    • V
      mac80211: Make sure non-HT connection when IEEE80211_STA_TKIP_WEP_USED is set · 53d6f81c
      Vasanthakumar Thiagarajan 提交于
      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: NVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      53d6f81c
  2. 25 2月, 2009 6 次提交
  3. 24 2月, 2009 4 次提交
    • J
      netfilter: xt_recent: fix proc-file addition/removal of IPv4 addresses · 325fb5b4
      Josef Drexler 提交于
      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.
      
      Details:
      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 +169.254.156.239 > /proc/net/xt_recent/DEFAULT
      $ cat /proc/net/xt_recent/DEFAULT
      src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      
      [At this point no packets from 169.254.156.239 are being logged.]
      
      $ iptables -I INPUT -s 169.254.156.239 -m recent --set
      $ cat /proc/net/xt_recent/DEFAULT
      src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      src=169.254.156.239 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 -169.254.156.239 > /proc/net/xt_recent/DEFAULT
      $ cat /proc/net/xt_recent/DEFAULT
      src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      src=169.254.156.239 ttl: 255 last_seen: 126992 oldest_pkt: 10 125434, 125684, 125934, 126184, 126434, 126684, 126934, 126991, 126991, 126992
      $ echo -169.254.156.239 > /proc/net/xt_recent/DEFAULT
      $ cat /proc/net/xt_recent/DEFAULT
      src=169.254.156.239 ttl: 0 last_seen: 119910 oldest_pkt: 1 119910
      src=169.254.156.239 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: NPatrick McHardy <kaber@trash.net>
      325fb5b4
    • J
      Doc: Refer to ip-sysctl.txt for strict vs. loose rp_filter mode · d18921a0
      Jesper Dangaard Brouer 提交于
      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:
       Documentation/networking/ip-sysctl.txt
      
      I'm considering moving the rp_filter description away
      from the Kconfig file into ip-sysctl.txt.
      Signed-off-by: NJesper Dangaard Brouer <hawk@comx.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d18921a0
    • E
      net: amend the fix for SO_BSDCOMPAT gsopt infoleak · 50fee1de
      Eugene Teo 提交于
      The fix for CVE-2009-0676 (upstream commit df0bca04) is incomplete. Note
      that the same problem of leaking kernel memory will reappear if someone
      on some architecture uses struct timeval with some internal padding (for
      example tv_sec 64-bit and tv_usec 32-bit) --- then, you are going to
      leak the padded bytes to userspace.
      Signed-off-by: NEugene Teo <eugeneteo@kernel.sg>
      Reported-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      50fee1de
    • C
      netns: build fix for net_alloc_generic · ebe47d47
      Clemens Noss 提交于
      net_alloc_generic was defined in #ifdef CONFIG_NET_NS, but used
      unconditionally. Move net_alloc_generic out of #ifdef.
      Signed-off-by: NClemens Noss <cnoss@gmx.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ebe47d47
  4. 23 2月, 2009 10 次提交
  5. 22 2月, 2009 3 次提交
    • D
      netns: fix double free at netns creation · 486a87f1
      Daniel Lezcano 提交于
      This patch fix a double free when a network namespace fails.
      The previous code does a kfree of the net_generic structure when
      one of the init subsystem initialization fails.
      The 'setup_net' function does kfree(ng) and returns an error.
      The caller, 'copy_net_ns', call net_free on error, and this one
      calls kfree(net->gen), making this pointer freed twice.
      
      This patch make the code symetric, the net_alloc does the net_generic
      allocation and the net_free frees the net_generic.
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@free.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      486a87f1
    • H
      tcp: Always set urgent pointer if it's beyond snd_nxt · 7691367d
      Herbert Xu 提交于
      Our TCP stack does not set the urgent flag if the urgent pointer
      does not fit in 16 bits, i.e., if it is more than 64K from the
      sequence number of a packet.
      
      This behaviour is different from the BSDs, and clearly contradicts
      the purpose of urgent mode, which is to send the notification
      (though not necessarily the associated data) as soon as possible.
      Our current behaviour may in fact delay the urgent notification
      indefinitely if the receiver window does not open up.
      
      Simply matching BSD however may break legacy applications which
      incorrectly rely on the out-of-band delivery of urgent data, and
      conversely the in-band delivery of non-urgent data.
      
      Alexey Kuznetsov suggested a safe solution of following BSD only
      if the urgent pointer itself has not yet been transmitted.  This
      way we guarantee that when the remote end sees the packet with
      non-urgent data marked as urgent due to wrap-around we would have
      advanced the urgent pointer beyond, either to the actual urgent
      data or to an as-yet untransmitted packet.
      
      The only potential downside is that applications on the remote
      end may see multiple SIGURG notifications.  However, this would
      occur anyway with other TCP stacks.  More importantly, the outcome
      of such a duplicate notification is likely to be harmless since
      the signal itself does not carry any information other than the
      fact that we're in urgent mode.
      
      Thanks to Ilpo Järvinen for fixing a critical bug in this and
      Jeff Chua for reporting that bug.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7691367d
    • H
      ipv6: fix sparse warning: Using plain integer as NULL pointer · 66da8c52
      Hannes Eder 提交于
      Fix this sparse warning:
        net/ipv6/xfrm6_state.c:72:26: warning: Using plain integer as NULL pointer
      Signed-off-by: NHannes Eder <hannes@hanneseder.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      66da8c52
  6. 21 2月, 2009 1 次提交
  7. 20 2月, 2009 2 次提交
  8. 19 2月, 2009 2 次提交
  9. 18 2月, 2009 5 次提交
  10. 16 2月, 2009 3 次提交