1. 15 3月, 2014 5 次提交
  2. 13 3月, 2014 1 次提交
  3. 11 3月, 2014 2 次提交
  4. 07 3月, 2014 3 次提交
  5. 01 3月, 2014 4 次提交
  6. 28 2月, 2014 11 次提交
  7. 27 2月, 2014 12 次提交
    • A
      Bluetooth: Create hci_req_add_le_passive_scan helper · 8ef30fd3
      Andre Guedes 提交于
      This patches creates the public hci_req_add_le_passive_scan helper so
      it can be re-used outside hci_core.c in the next patch.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8ef30fd3
    • A
      Bluetooth: Connection parameters and resolvable address · a9b0a04c
      Andre Guedes 提交于
      We should only accept connection parameters from identity addresses
      (public or random static). Thus, we should check the address type
      in hci_conn_params_add().
      
      Additionally, since the IRK is removed during unpair, we should also
      remove the connection parameters from that device.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a9b0a04c
    • A
      Bluetooth: Introduce LE auto connect options · 9fcb18ef
      Andre Guedes 提交于
      This patch introduces the LE auto connection options: HCI_AUTO_CONN_
      ALWAYS and HCI_AUTO_CONN_LINK_LOSS. Their working mechanism are
      described as follows:
      
      The HCI_AUTO_CONN_ALWAYS option configures the kernel to always re-
      establish the connection, no matter the reason the connection was
      terminated. This feature is required by some LE profiles such as
      HID over GATT, Health Thermometer and Blood Pressure. These profiles
      require the host autonomously connect to the device as soon as it
      enters in connectable mode (start advertising) so the device is able
      to delivery notifications or indications.
      
      The BT_AUTO_CONN_LINK_LOSS option configures the kernel to re-
      establish the connection in case the connection was terminated due
      to a link loss. This feature is required by the majority of LE
      profiles such as Proximity, Find Me, Cycling Speed and Cadence and
      Time.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9fcb18ef
    • A
      Bluetooth: Introduce LE auto connection infrastructure · a4790dbd
      Andre Guedes 提交于
      This patch introduces the LE auto connection infrastructure which
      will be used to implement the LE auto connection options.
      
      In summary, the auto connection mechanism works as follows: Once the
      first pending LE connection is created, the background scanning is
      started. When the target device is found in range, the kernel
      autonomously starts the connection attempt. If connection is
      established successfully, that pending LE connection is deleted and
      the background is stopped.
      
      To achieve that, this patch introduces the hci_update_background_scan()
      which controls the background scanning state. This function starts or
      stops the background scanning based on the hdev->pend_le_conns list. If
      there is no pending LE connection, the background scanning is stopped.
      Otherwise, we start the background scanning.
      
      Then, every time a pending LE connection is added we call hci_update_
      background_scan() so the background scanning is started (in case it is
      not already running). Likewise, every time a pending LE connection is
      deleted we call hci_update_background_scan() so the background scanning
      is stopped (in case this was the last pending LE connection) or it is
      started again (in case we have more pending LE connections). Finally,
      we also call hci_update_background_scan() in hci_le_conn_failed() so
      the background scan is restarted in case the connection establishment
      fails. This way the background scanning keeps running until all pending
      LE connection are established.
      
      At this point, resolvable addresses are not support by this
      infrastructure. The proper support is added in upcoming patches.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a4790dbd
    • A
      Bluetooth: Introduce hdev->pend_le_conn list · 77a77a30
      Andre Guedes 提交于
      This patch introduces the hdev->pend_le_conn list which holds the
      device addresses the kernel should autonomously connect. It also
      introduces some helper functions to manipulate the list.
      
      The list and helper functions will be used by the next patch which
      implements the LE auto connection infrastructure.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      77a77a30
    • A
      Bluetooth: Refactor HCI connection code · 04a6c589
      Andre Guedes 提交于
      hci_connect() is a very simple and useless wrapper of hci_connect_acl
      and hci_connect_le functions. Addtionally, all places where hci_connect
      is called the link type value is passed explicitly. This way, we can
      safely delete hci_connect, declare hci_connect_acl and hci_connect_le
      in hci_core.h and call them directly.
      
      No functionality is changed by this patch.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      04a6c589
    • A
      Bluetooth: Stop scanning on LE connection · 2acf3d90
      Andre Guedes 提交于
      Some LE controllers don't support scanning and creating a connection
      at the same time. So we should always stop scanning in order to
      establish the connection.
      
      Since we may prematurely stop the discovery procedure in favor of
      the connection establishment, we should also cancel hdev->le_scan_
      disable delayed work and set the discovery state to DISCOVERY_STOPPED.
      
      This change does a small improvement since it is not mandatory the
      user stops scanning before connecting anymore. Moreover, this change
      is required by upcoming LE auto connection mechanism in order to work
      properly with controllers that don't support background scanning and
      connection establishment at the same time.
      
      In future, we might want to do a small optimization by checking if
      controller is able to scan and connect at the same time. For now,
      we want the simplest approach so we always stop scanning (even if
      the controller is able to carry out both operations).
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      2acf3d90
    • A
      Bluetooth: Declare le_conn_failed in hci_core.h · 06c053fb
      Andre Guedes 提交于
      This patch adds the "hci_" prefix to le_conn_failed() helper and
      declares it in hci_core.h so it can be reused in hci_event.c.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      06c053fb
    • A
      Bluetooth: Create hci_req_add_le_scan_disable helper · b1efcc28
      Andre Guedes 提交于
      This patch moves stop LE scanning duplicate code to one single
      place and reuses it. This will avoid more duplicate code in
      upcoming patches.
      Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      b1efcc28
    • E
      tcp: switch rtt estimations to usec resolution · 740b0f18
      Eric Dumazet 提交于
      Upcoming congestion controls for TCP require usec resolution for RTT
      estimations. Millisecond resolution is simply not enough these days.
      
      FQ/pacing in DC environments also require this change for finer control
      and removal of bimodal behavior due to the current hack in
      tcp_update_pacing_rate() for 'small rtt'
      
      TCP_CONG_RTT_STAMP is no longer needed.
      
      As Julian Anastasov pointed out, we need to keep user compatibility :
      tcp_metrics used to export RTT and RTTVAR in msec resolution,
      so we added RTT_US and RTTVAR_US. An iproute2 patch is needed
      to use the new attributes if provided by the kernel.
      
      In this example ss command displays a srtt of 32 usecs (10Gbit link)
      
      lpk51:~# ./ss -i dst lpk52
      Netid  State      Recv-Q Send-Q   Local Address:Port       Peer
      Address:Port
      tcp    ESTAB      0      1         10.246.11.51:42959
      10.246.11.52:64614
               cubic wscale:6,6 rto:201 rtt:0.032/0.001 ato:40 mss:1448
      cwnd:10 send
      3620.0Mbps pacing_rate 7240.0Mbps unacked:1 rcv_rtt:993 rcv_space:29559
      
      Updated iproute2 ip command displays :
      
      lpk51:~# ./ip tcp_metrics | grep 10.246.11.52
      10.246.11.52 age 561.914sec cwnd 10 rtt 274us rttvar 213us source
      10.246.11.51
      
      Old binary displays :
      
      lpk51:~# ip tcp_metrics | grep 10.246.11.52
      10.246.11.52 age 561.914sec cwnd 10 rtt 250us rttvar 125us source
      10.246.11.51
      
      With help from Julian Anastasov, Stephen Hemminger and Yuchung Cheng
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Larry Brakmo <brakmo@google.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      740b0f18
    • H
      ipv6: yet another new IPV6_MTU_DISCOVER option IPV6_PMTUDISC_OMIT · 0b95227a
      Hannes Frederic Sowa 提交于
      This option has the same semantic as IP_PMTUDISC_OMIT for IPv4 which
      got recently introduced. It doesn't honor the path mtu discovered by the
      host but in contrary to IPV6_PMTUDISC_INTERFACE allows the generation of
      fragments if the packet size exceeds the MTU of the outgoing interface
      MTU.
      
      Fixes: 93b36cf3 ("ipv6: support IPV6_PMTU_INTERFACE on sockets")
      Cc: Florian Weimer <fweimer@redhat.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0b95227a
    • H
      ipv4: yet another new IP_MTU_DISCOVER option IP_PMTUDISC_OMIT · 1b346576
      Hannes Frederic Sowa 提交于
      IP_PMTUDISC_INTERFACE has a design error: because it does not allow the
      generation of fragments if the interface mtu is exceeded, it is very
      hard to make use of this option in already deployed name server software
      for which I introduced this option.
      
      This patch adds yet another new IP_MTU_DISCOVER option to not honor any
      path mtu information and not accepting new icmp notifications destined for
      the socket this option is enabled on. But we allow outgoing fragmentation
      in case the packet size exceeds the outgoing interface mtu.
      
      As such this new option can be used as a drop-in replacement for
      IP_PMTUDISC_DONT, which is currently in use by most name server software
      making the adoption of this option very smooth and easy.
      
      The original advantage of IP_PMTUDISC_INTERFACE is still maintained:
      ignoring incoming path MTU updates and not honoring discovered path MTUs
      in the output path.
      
      Fixes: 482fc609 ("ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE")
      Cc: Florian Weimer <fweimer@redhat.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b346576
  8. 25 2月, 2014 2 次提交