1. 05 6月, 2010 1 次提交
  2. 04 6月, 2010 3 次提交
  3. 03 6月, 2010 2 次提交
  4. 25 5月, 2010 2 次提交
  5. 20 5月, 2010 1 次提交
  6. 19 5月, 2010 1 次提交
  7. 18 5月, 2010 6 次提交
  8. 16 5月, 2010 3 次提交
  9. 13 5月, 2010 2 次提交
  10. 11 5月, 2010 4 次提交
    • P
      ipv6: ip6mr: support multiple tables · d1db275d
      Patrick McHardy 提交于
      This patch adds support for multiple independant multicast routing instances,
      named "tables".
      
      Userspace multicast routing daemons can bind to a specific table instance by
      issuing a setsockopt call using a new option MRT6_TABLE. The table number is
      stored in the raw socket data and affects all following ip6mr setsockopt(),
      getsockopt() and ioctl() calls. By default, a single table (RT6_TABLE_DFLT)
      is created with a default routing rule pointing to it. Newly created pim6reg
      devices have the table number appended ("pim6regX"), with the exception of
      devices created in the default table, which are named just "pim6reg" for
      compatibility reasons.
      
      Packets are directed to a specific table instance using routing rules,
      similar to how regular routing rules work. Currently iif, oif and mark
      are supported as keys, source and destination addresses could be supported
      additionally.
      
      Example usage:
      
      - bind pimd/xorp/... to a specific table:
      
      uint32_t table = 123;
      setsockopt(fd, SOL_IPV6, MRT6_TABLE, &table, sizeof(table));
      
      - create routing rules directing packets to the new table:
      
      # ip -6 mrule add iif eth0 lookup 123
      # ip -6 mrule add oif eth0 lookup 123
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      d1db275d
    • P
      6bd52143
    • P
      f30a7784
    • P
      ipv6: ip6mr: move unres_queue and timer to per-namespace data · c476efbc
      Patrick McHardy 提交于
      The unres_queue is currently shared between all namespaces. Following patches
      will additionally allow to create multiple multicast routing tables in each
      namespace. Having a single shared queue for all these users seems to excessive,
      move the queue and the cleanup timer to the per-namespace data to unshare it.
      
      As a side-effect, this fixes a bug in the seq file iteration functions: the
      first entry returned is always from the current namespace, entries returned
      after that may belong to any namespace.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      c476efbc
  11. 10 5月, 2010 11 次提交
  12. 08 5月, 2010 4 次提交
    • N
      ipv4: remove ip_rt_secret timer (v4) · 3ee94372
      Neil Horman 提交于
      A while back there was a discussion regarding the rt_secret_interval timer.
      Given that we've had the ability to do emergency route cache rebuilds for awhile
      now, based on a statistical analysis of the various hash chain lengths in the
      cache, the use of the flush timer is somewhat redundant.  This patch removes the
      rt_secret_interval sysctl, allowing us to rely solely on the statistical
      analysis mechanism to determine the need for route cache flushes.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ee94372
    • J
      mac80211: improve HT channel handling · 0aaffa9b
      Johannes Berg 提交于
      Currently, when one interface switches HT mode,
      all others will follow along. This is clearly
      undesirable, since the new one might switch to
      no-HT while another one is operating in HT.
      
      Address this issue by keeping track of the HT
      mode per interface, and allowing only changes
      that are compatible, i.e. switching into HT40+
      is not possible when another interface is in
      HT40-, in that case the second one needs to
      fall back to HT20.
      
      Also, to allow drivers to know what's going on,
      store the per-interface HT mode (channel type)
      in the virtual interface's bss_conf.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0aaffa9b
    • J
      cfg80211/mac80211: better channel handling · f444de05
      Johannes Berg 提交于
      Currently (all tested with hwsim) you can do stupid
      things like setting up an AP on a certain channel,
      then adding another virtual interface and making
      that associate on another channel -- this will make
      the beaconing to move channel but obviously without
      the necessary IEs data update.
      
      In order to improve this situation, first make the
      configuration APIs (cfg80211 and nl80211) aware of
      multi-channel operation -- we'll eventually need
      that in the future anyway. There's one userland API
      change and one API addition. The API change is that
      now SET_WIPHY must be called with virtual interface
      index rather than only wiphy index in order to take
      effect for that interface -- luckily all current
      users (hostapd) do that. For monitor interfaces, the
      old setting is preserved, but monitors are always
      slaved to other devices anyway so no guarantees.
      
      The second userland API change is the introduction
      of a per virtual interface SET_CHANNEL command, that
      hostapd should use going forward to make it easier
      to understand what's going on (it can automatically
      detect a kernel with this command).
      
      Other than mac80211, no existing cfg80211 drivers
      are affected by this change because they only allow
      a single virtual interface.
      
      mac80211, however, now needs to be aware that the
      channel settings are per interface now, and needs
      to disallow (for now) real multi-channel operation,
      which is another important part of this patch.
      
      One of the immediate benefits is that you can now
      start hostapd to operate on a hardware that already
      has a connection on another virtual interface, as
      long as you specify the same channel.
      
      Note that two things are left unhandled (this is an
      improvement -- not a complete fix):
      
       * different HT/no-HT modes
      
         currently you could start an HT AP and then
         connect to a non-HT network on the same channel
         which would configure the hardware for no HT;
         that can be fixed fairly easily
      
       * CSA
      
         An AP we're connected to on a virtual interface
         might indicate switching channels, and in that
         case we would follow it, regardless of how many
         other interfaces are operating; this requires
         more effort to fix but is pretty rare after all
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f444de05
    • J
      mac80211: fix BSS info reconfiguration · ac8dd506
      Johannes Berg 提交于
      When reconfiguring an interface due to a previous
      hardware restart, mac80211 will currently include
      the new IBSS flag on non-IBSS interfaces which may
      confuse drivers.
      
      Instead of doing the ~0 trick, simply spell out
      which things are going to be reconfigured.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ac8dd506