1. 08 1月, 2010 1 次提交
  2. 07 1月, 2010 1 次提交
    • J
      net: RFC3069, private VLAN proxy arp support · 65324144
      Jesper Dangaard Brouer 提交于
      This is to be used together with switch technologies, like RFC3069,
      that where the individual ports are not allowed to communicate with
      each other, but they are allowed to talk to the upstream router.  As
      described in RFC 3069, it is possible to allow these hosts to
      communicate through the upstream router by proxy_arp'ing.
      
      This patch basically allow proxy arp replies back to the same
      interface (from which the ARP request/solicitation was received).
      
      Tunable per device via proc "proxy_arp_pvlan":
        /proc/sys/net/ipv4/conf/*/proxy_arp_pvlan
      
      This switch technology is known by different vendor names:
       - In RFC 3069 it is called VLAN Aggregation.
       - Cisco and Allied Telesyn call it Private VLAN.
       - Hewlett-Packard call it Source-Port filtering or port-isolation.
       - Ericsson call it MAC-Forced Forwarding (RFC Draft).
      Signed-off-by: NJesper Dangaard Brouer <hawk@comx.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      65324144
  3. 04 1月, 2010 1 次提交
  4. 29 12月, 2009 2 次提交
    • J
      cfg80211: add remain-on-channel command · 9588bbd5
      Jouni Malinen 提交于
      Add new commands for requesting the driver to remain awake
      on a specified channel for the specified amount of time
      (and another command to cancel such an operation). This
      can be used to implement userspace-controlled off-channel
      operations, like Public Action frame exchange on another
      channel than the operation channel.
      
      The off-channel operation should behave similarly to scan,
      i.e. the local station (if associated) moves into power
      save mode to request the AP to buffer frames for it and
      then moves to the other channel to allow the off-channel
      operation to be completed. The duration parameter can be
      used to request enough time to receive a response from
      the target station.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9588bbd5
    • J
      mac80211: split up and insert custom IEs correctly · 8e664fb3
      Johannes Berg 提交于
      Currently, we insert all user-specified IEs before the HT
      IE for association, and after the HT IE for probe requests.
      For association, that's correct only if the user-specified
      IEs are RSN only, incorrect in all other cases including
      WPA. Change this to split apart the user-specified IEs in
      two places for association: before the HT IE (e.g. RSN),
      after the HT IE (generally empty right now I think?) and
      after WMM (all other vendor-specific IEs). For probes,
      split the IEs in different places to be correct according
      to the spec.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e664fb3
  5. 27 12月, 2009 1 次提交
  6. 24 12月, 2009 7 次提交
  7. 23 12月, 2009 18 次提交
  8. 22 12月, 2009 1 次提交
    • J
      mac80211: fix peer HT capabilities · 9a418af5
      Johannes Berg 提交于
      I noticed yesterday, because Jeff had noticed
      a speed regression, cf. bug
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2138
      that the SM PS settings for peers were wrong.
      Instead of overwriting the SM PS settings with
      the local bits, we need to keep the remote bits.
      
      The bug was part of the original HT code from
      over two years ago, but unfortunately nobody
      noticed that it makes no sense -- we shouldn't
      be overwriting the peer's setting with our own
      but rather keep it intact when masking the peer
      capabilities with our own.
      
      While fixing that, I noticed that the masking of
      capabilities is completely useless for most of
      the bits, so also fix those other bits.
      
      Finally, I also noticed that PSMP_SUPPORT no
      longer exists in the final 802.11n version, so
      also remove that.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9a418af5
  9. 19 12月, 2009 1 次提交
  10. 18 12月, 2009 7 次提交