1. 27 2月, 2009 10 次提交
    • M
      Bluetooth: Fix double L2CAP connection request · 6a8d3010
      Marcel Holtmann 提交于
      If the remote L2CAP server uses authentication pending stage and
      encryption is enabled it can happen that a L2CAP connection request is
      sent twice due to a race condition in the connection state machine.
      
      When the remote side indicates any kind of connection pending, then
      track this state and skip sending of L2CAP commands for this period.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      6a8d3010
    • M
      Bluetooth: Fix race condition with L2CAP information request · 984947dc
      Marcel Holtmann 提交于
      When two L2CAP connections are requested quickly after the ACL link has
      been established there exists a window for a race condition where a
      connection request is sent before the information response has been
      received. Any connection request should only be sent after an exchange
      of the extended features mask has been finished.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      984947dc
    • M
      Bluetooth: Use general bonding whenever possible · 0684e5f9
      Marcel Holtmann 提交于
      When receiving incoming connection to specific services, always use
      general bonding. This ensures that the link key gets stored and can be
      used for further authentications.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      0684e5f9
    • M
      Bluetooth: Add SCO fallback for eSCO connection attempts · efc7688b
      Marcel Holtmann 提交于
      When attempting to setup eSCO connections it can happen that some link
      manager implementations fail to properly negotiate the eSCO parameters
      and thus fail the eSCO setup. Normally the link manager is responsible
      for the negotiation of the parameters and actually fallback to SCO if
      no agreement can be reached. In cases where the link manager is just too
      stupid, then at least try to establish a SCO link if eSCO fails.
      
      For the Bluetooth devices with EDR support this includes handling packet
      types of EDR basebands. This is particular tricky since for the EDR the
      logic of enabling/disabling one specific packet type is turned around.
      This fix contains an extra bitmask to disable eSCO EDR packet when
      trying to fallback to a SCO connection.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      efc7688b
    • M
      Bluetooth: Pause RFCOMM TX when encryption drops · 8c84b830
      Marcel Holtmann 提交于
      A role switch with devices following the Bluetooth pre-2.1 standards
      or without Encryption Pause and Resume support is not possible if
      encryption is enabled. Most newer headsets require the role switch,
      but also require that the connection is encrypted.
      
      For connections with a high security mode setting, the link will be
      immediately dropped. When the connection uses medium security mode
      setting, then a grace period is introduced where the TX is halted and
      the remote device gets a change to re-enable encryption after the
      role switch. If not re-enabled the link will be dropped.
      
      Based on initial work by Ville Tervo <ville.tervo@nokia.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8c84b830
    • M
      Bluetooth: Replace RFCOMM link mode with security level · 9f2c8a03
      Marcel Holtmann 提交于
      Change the RFCOMM internals to use the new security levels and remove
      the link mode details.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9f2c8a03
    • M
      Bluetooth: Replace L2CAP link mode with security level · 2af6b9d5
      Marcel Holtmann 提交于
      Change the L2CAP internals to use the new security levels and remove
      the link mode details.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2af6b9d5
    • M
      Bluetooth: Add enhanced security model for Simple Pairing · 8c1b2355
      Marcel Holtmann 提交于
      The current security model is based around the flags AUTH, ENCRYPT and
      SECURE. Starting with support for the Bluetooth 2.1 specification this is
      no longer sufficient. The different security levels are now defined as
      SDP, LOW, MEDIUM and SECURE.
      
      Previously it was possible to set each security independently, but this
      actually doesn't make a lot of sense. For Bluetooth the encryption depends
      on a previous successful authentication. Also you can only update your
      existing link key if you successfully created at least one before. And of
      course the update of link keys without having proper encryption in place
      is a security issue.
      
      The new security levels from the Bluetooth 2.1 specification are now
      used internally. All old settings are mapped to the new values and this
      way it ensures that old applications still work. The only limitation
      is that it is no longer possible to set authentication without also
      enabling encryption. No application should have done this anyway since
      this is actually a security issue. Without encryption the integrity of
      the authentication can't be guaranteed.
      
      As default for a new L2CAP or RFCOMM connection, the LOW security level
      is used. The only exception here are the service discovery sessions on
      PSM 1 where SDP level is used. To have similar security strength as with
      a Bluetooth 2.0 and before combination key, the MEDIUM level should be
      used. This is according to the Bluetooth specification. The MEDIUM level
      will not require any kind of man-in-the-middle (MITM) protection. Only
      the HIGH security level will require this.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8c1b2355
    • M
      Bluetooth: Add support for deferring RFCOMM connection setup · bb23c0ab
      Marcel Holtmann 提交于
      In order to decide if listening RFCOMM sockets should be accept()ed
      the BD_ADDR of the remote device needs to be known. This patch adds
      a socket option which defines a timeout for deferring the actual
      connection setup.
      
      The connection setup is done after reading from the socket for the
      first time. Until then writing to the socket returns ENOTCONN.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      bb23c0ab
    • M
      Bluetooth: Add global deferred socket parameter · c4f912e1
      Marcel Holtmann 提交于
      The L2CAP and RFCOMM applications require support for authorization
      and the ability of rejecting incoming connection requests. The socket
      interface is not really able to support this.
      
      This patch does the ground work for a socket option to defer connection
      setup. Setting this option allows calling of accept() and then the
      first read() will trigger the final connection setup. Calling close()
      would reject the connection.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c4f912e1
  2. 23 2月, 2009 1 次提交
    • E
      netns: Remove net_alive · ce16c533
      Eric W. Biederman 提交于
      It turns out that net_alive is unnecessary, and the original problem
      that led to it being added was simply that the icmp code thought
      it was a network device and wound up being unable to handle packets
      while there were still packets in the network namespace.
      
      Now that icmp and tcp have been fixed to properly register themselves
      this problem is no longer present and we have a stronger guarantee
      that packets will not arrive in a network namespace then that provided
      by net_alive in netif_receive_skb.  So remove net_alive allowing
      packet reception run a little faster.
      
      Additionally document the strong reason why network namespace cleanup
      is safe so that if something happens again someone else will have
      a chance of figuring it out.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce16c533
  3. 18 2月, 2009 2 次提交
  4. 16 2月, 2009 6 次提交
  5. 15 2月, 2009 1 次提交
  6. 14 2月, 2009 5 次提交
  7. 13 2月, 2009 1 次提交
    • A
      net: don't use in_atomic() in gfp_any() · 99709372
      Andrew Morton 提交于
      The problem is that in_atomic() will return false inside spinlocks if
      CONFIG_PREEMPT=n.  This will lead to deadlockable GFP_KERNEL allocations
      from spinlocked regions.
      
      Secondly, if CONFIG_PREEMPT=y, this bug solves itself because networking
      will instead use GFP_ATOMIC from this callsite.  Hence we won't get the
      might_sleep() debugging warnings which would have informed us of the buggy
      callsites.
      
      Solve both these problems by switching to in_interrupt().  Now, if someone
      runs a gfp_any() allocation from inside spinlock we will get the warning
      if CONFIG_PREEMPT=y.
      
      I reviewed all callsites and most of them were too complex for my little
      brain and none of them documented their interface requirements.  I have no
      idea what this patch will do.
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99709372
  8. 10 2月, 2009 1 次提交
  9. 05 2月, 2009 1 次提交
  10. 02 2月, 2009 1 次提交
  11. 01 2月, 2009 1 次提交
  12. 30 1月, 2009 10 次提交