1. 18 6月, 2006 20 次提交
  2. 06 6月, 2006 2 次提交
    • D
      [PATCH] softmac: Fix handling of authentication failure · 6ae15df1
      Daniel Drake 提交于
      My router blew up earlier, but exhibited some interesting behaviour during
      its dying moments. It was broadcasting beacons but wouldn't respond to
      any authentication requests.
      
      I noticed that softmac wasn't playing nice with this, as I couldn't make it try
      to connect to other networks after it had timed out authenticating to my ill
      router.
      
      To resolve this, I modified the softmac event/notify API to pass the event
      code to the callback, so that callbacks being notified from
      IEEE80211SOFTMAC_EVENT_ANY masks can make some judgement. In this case, the
      ieee80211softmac_assoc callback needs to make a decision based upon whether
      the association passed or failed.
      Signed-off-by: NDaniel Drake <dsd@gentoo.org>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6ae15df1
    • D
      [PATCH] softmac: complete shared key authentication · 76ea4c7f
      Daniel Drake 提交于
      This patch finishes of the partially-complete shared key authentication
      implementation in softmac.
      
      The complication here is that we need to encrypt a management frame during
      the authentication process. I don't think there are any other scenarios where
      this would have to happen.
      
      To get around this without causing too many headaches, we decided to just use
      software encryption for this frame. The softmac config option now selects
      IEEE80211_CRYPT_WEP so that we can ensure this available. This also involved
      a modification to some otherwise unused ieee80211 API.
      Signed-off-by: NDaniel Drake <dsd@gentoo.org>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      76ea4c7f
  3. 01 6月, 2006 1 次提交
  4. 23 5月, 2006 1 次提交
  5. 20 5月, 2006 2 次提交
  6. 13 5月, 2006 1 次提交
    • S
      [NEIGH]: Fix IP-over-ATM and ARP interaction. · bd89efc5
      Simon Kelley 提交于
      The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff>
      ARP table, using the standard neighbour-table code. The
      neigh_table_init function adds this neighbour table to a linked list
      of all neighbor tables which is used by the functions neigh_delete()
      neigh_add() and neightbl_set(), all called by the netlink code.
      
      Once the ATM neighbour table is added to the list, there are two
      tables with family == AF_INET there, and ARP entries sent via netlink
      go into the first table with matching family. This is indeterminate
      and often wrong.
      
      To see the bug, on a kernel with CLIP enabled, create a standard IPv4
      ARP entry by pinging an unused address on a local subnet. Then attempt
      to complete that entry by doing
      
      ip neigh replace <ip address> lladdr <some mac address> nud reachable
      
      Looking at the ARP tables by using 
      
      ip neigh show
      
      will reveal two ARP entries for the same address. One of these can be
      found in /proc/net/arp, and the other in /proc/net/atm/arp.
      
      This patch adds a new function, neigh_table_init_no_netlink() which
      does everything the neigh_table_init() does, except add the table to
      the netlink all-arp-tables chain. In addition neigh_table_init() has a
      check that all tables on the chain have a distinct address family.
      The init call in clip.c is changed to call
      neigh_table_init_no_netlink().
      
      Since ATM ARP tables are rather more complicated than can currently be
      handled by the available rtattrs in the netlink protocol, no
      functionality is lost by this patch, and non-ATM ARP manipulation via
      netlink is rescued. A more complete solution would involve a rtattr
      for ATM ARP entries and some way for the netlink code to give
      neigh_add and friends more information than just address family with
      which to find the correct ARP table.
      
      [ I've changed the assertion checking in neigh_table_init() to not
        use BUG_ON() while holding neigh_tbl_lock.  Instead we remember that
        we found an existing tbl with the same family, and after dropping
        the lock we'll give a diagnostic kernel log message and a stack dump.
        -DaveM ]
      Signed-off-by: NSimon Kelley <simon@thekelleys.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd89efc5
  7. 06 5月, 2006 4 次提交
  8. 04 5月, 2006 3 次提交
  9. 30 4月, 2006 1 次提交
  10. 26 4月, 2006 1 次提交
  11. 25 4月, 2006 4 次提交