1. 03 11月, 2009 1 次提交
  2. 21 9月, 2009 1 次提交
  3. 29 8月, 2009 1 次提交
    • J
      cfg80211: clean up properly on interface type change · 3d54d255
      Johannes Berg 提交于
      When the interface type changes while connected, and the
      driver does not require the interface to be down for a
      type change, it is currently possible to get very strange
      results unless the driver takes special care, which it
      shouldn't have to.
      
      To fix this, take care to disconnect/leave IBSS when
      changing the interface type -- even if the driver may fail
      the call. Also process all events that may be pending to
      avoid running into a situation where an event is reported
      but only processed after the type has already changed,
      which would lead to missing events and warnings.
      
      A side effect of this is that you will have disconnected
      or left the IBSS even if the mode change ultimately fails,
      but since the intention was to change it and thus leave or
      disconnect, this is not a problem.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3d54d255
  4. 20 8月, 2009 1 次提交
  5. 14 8月, 2009 2 次提交
  6. 30 7月, 2009 4 次提交
  7. 25 7月, 2009 5 次提交
  8. 11 7月, 2009 13 次提交
  9. 04 6月, 2009 2 次提交
  10. 21 5月, 2009 1 次提交
    • J
      cfg80211: allow wext to remove keys that don't exist · e3da574a
      Johannes Berg 提交于
      Some applications using wireless extensions expect to be able to
      remove a key that doesn't exist. One example is wpa_supplicant
      which doesn't actually change behaviour when running into an
      error while trying to do that, but it prints an error message
      which users interpret as wpa_supplicant having problems.
      
      The safe thing to do is not change the behaviour of wireless
      extensions any more, so when the driver reports -ENOENT let
      the wext bridge code return success to userspace. To guarantee
      this, also document that drivers should return -ENOENT when the
      key doesn't exist.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e3da574a
  11. 14 5月, 2009 2 次提交
    • J
      nl80211: Add RSC configuration for new keys · faa8fdc8
      Jouni Malinen 提交于
      When setting a key with NL80211_CMD_NEW_KEY, we should allow the key
      sequence number (RSC) to be set in order to allow replay protection to
      work correctly for group keys. This patch documents this use for
      nl80211 and adds the couple of missing pieces in nl80211/cfg80211 and
      mac80211 to support this. In addition, WEXT SIOCSIWENCODEEXT compat
      processing in cfg80211 is extended to handle the RSC (this was already
      specified in WEXT, but just not implemented in cfg80211/mac80211).
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      faa8fdc8
    • J
      cfg80211: implement wext key handling · 08645126
      Johannes Berg 提交于
      Move key handling wireless extension ioctls from mac80211 to cfg80211
      so that all drivers that implement the cfg80211 operations get wext
      compatibility.
      
      Note that this drops the SIOCGIWENCODE ioctl support for getting
      IW_ENCODE_RESTRICTED/IW_ENCODE_OPEN. This means that iwconfig will
      no longer report "Security mode:open" or "Security mode:restricted"
      for mac80211. However, what we displayed there (the authentication
      algo used) was actually wrong -- linux/wireless.h states that this
      setting is meant to differentiate between "Refuse non-encoded packets"
      and "Accept non-encoded packets".
      
      (Combined with "cfg80211: fix a couple of bugs with key ioctls". -- JWL)
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      08645126
  12. 12 5月, 2009 1 次提交
    • J
      cfg80211: fix wext iw_freq parsing · 0b258582
      Johannes Berg 提交于
      The function to parse a struct iw_freq has a stupid bug,
      it returns NULL when the channel cannot be found at all,
      but NULL is supposed to mean "auto". Fix this by checking
      the return value of ieee80211_get_channel() and returning
      ERR_PTR(-EINVAL) if it returned NULL (channel not found).
      
      This fixes an issue where you could say (in IBSS mode)
      	iwconfig wlan0 channel 21
      and it would use channel 1 instead because that's the
      first available channel with IBSS allowed (which is what
      the "auto" setting uses).
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0b258582
  13. 23 4月, 2009 5 次提交
  14. 28 3月, 2009 1 次提交