1. 03 12月, 2011 1 次提交
  2. 22 11月, 2011 2 次提交
  3. 08 11月, 2011 2 次提交
    • A
      Bluetooth: Use miliseconds for L2CAP channel timeouts · f3f668b0
      Andrzej Kaczmarek 提交于
      Timers set by __set_chan_timer() should use miliseconds instead of
      jiffies. Commit 942ecc9c updated
      l2cap_set_timer() so it expects timeout to be specified in msecs
      instead of jiffies. This makes timeouts unreliable when CONFIG_HZ
      is not set to 1000.
      Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      f3f668b0
    • A
      Bluetooth: Revert: Fix L2CAP connection establishment · 4dff523a
      Arek Lichwa 提交于
      This reverts commit 33060542.
      The commit introduces regression when two 2.1 devices attempt
      establish rfcomm channel. Such connection is refused since there's
      a security block issue on l2cap. It means the link is unencrypted.
      
      2011-09-16 18:08:46.567616 < ACL data: handle 1 flags 0x00 dlen 24
          0000: 14 00 40 00 06 00 02 00  0f 35 03 19 12 00 ff ff
      ..@......5....˙˙
          0010: 35 05 0a 00 00 ff ff 00                           5....˙˙.
      2011-09-16 18:08:46.572377 > HCI Event: Number of Completed Packets
      (0x13) plen 5
          handle 1 packets 1
      2011-09-16 18:08:46.577931 > ACL data: handle 1 flags 0x02 dlen 88
          L2CAP(d): cid 0x0040 len 84 [psm 0]
            0000: 07 00 02 00 4f 00 4c 35  4a 35 48 09 00 00 0a 00
      ....O.L5J5H.....
            0010: 01 00 00 09 00 01 35 03  19 12 00 09 00 05 35 03
      ......5.......5.
            0020: 19 10 02 09 00 09 35 08  35 06 19 12 00 09 01 02
      ......5.5.......
            0030: 09 02 00 09 01 02 09 02  01 09 00 0a 09 02 02 09
      ................
            0040: 00 00 09 02 03 09 00 00  09 02 04 28 01 09 02 05
      ...........(....
            0050: 09 00 02 00                                       ....
      2011-09-16 18:08:46.626057 < HCI Command: Authentication Requested
      (0x01|0x0011) plen 2
          handle 1
      2011-09-16 18:08:46.627614 > HCI Event: Command Status (0x0f) plen 4
          Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
      2011-09-16 18:08:46.627675 > HCI Event: Link Key Request (0x17) plen 6
          bdaddr 00:00:F2:6A:29:69
      2011-09-16 18:08:46.634999 < HCI Command: Link Key Request Reply
      (0x01|0x000b) plen 22
          bdaddr 00:00:F2:6A:29:69 key 58CD393179FC902E5E8F512A855EE532
      2011-09-16 18:08:46.683278 > HCI Event: Command Complete (0x0e) plen 10
          Link Key Request Reply (0x01|0x000b) ncmd 1
          status 0x00 bdaddr 00:00:F2:6A:29:69
      2011-09-16 18:08:46.764729 > HCI Event: Auth Complete (0x06) plen 3
          status 0x00 handle 1
      2011-09-16 18:08:46.764821 < ACL data: handle 1 flags 0x00 dlen 12
          0000: 08 00 01 00 02 05 04 00  03 00 41 00              ..........A.
      2011-09-16 18:08:46.764851 > HCI Event: Command Status (0x0f) plen 4
          Unknown (0x00|0x0000) status 0x00 ncmd 2
      2011-09-16 18:08:46.768117 > HCI Event: Number of Completed Packets
      (0x13) plen 5
          handle 1 packets 1
      2011-09-16 18:08:46.770894 > ACL data: handle 1 flags 0x02 dlen 16
          L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0041 result 3 status 0
            Connection refused - security block
      2011-09-16 18:08:49.000691 < ACL data: handle 1 flags 0x00 dlen 12
          0000: 08 00 01 00 06 06 04 00  40 00 40 00              ........@.@.
      2011-09-16 18:08:49.015675 > HCI Event: Number of Completed Packets
      (0x13) plen 5
          handle 1 packets 1
      2011-09-16 18:08:49.016927 > ACL data: handle 1 flags 0x02 dlen 12
          L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
      2011-09-16 18:08:51.009480 < HCI Command: Disconnect (0x01|0x0006) plen
      3
          handle 1 reason 0x13
          Reason: Remote User Terminated Connection
      2011-09-16 18:08:51.011525 > HCI Event: Command Status (0x0f) plen 4
          Disconnect (0x01|0x0006) status 0x00 ncmd 1
      2011-09-16 18:08:51.123494 > HCI Event: Disconn Complete (0x05) plen 4
          status 0x00 handle 1 reason 0x16
          Reason: Connection Terminated by Local Host
      Signed-off-by: NArek Lichwa <arkadiusz.lichwa@tieto.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      4dff523a
  4. 03 11月, 2011 4 次提交
  5. 01 11月, 2011 2 次提交
    • J
      Bluetooth: Set HCI_MGMT flag only in read_controller_info · dafbde39
      Johan Hedberg 提交于
      The HCI_MGMT flag should only be set when user space requests the full
      controller information. This way we avoid potential issues with setting
      change events ariving before the actual read_controller_info command
      finishes.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      dafbde39
    • S
      Bluetooth: Increase HCI reset timeout in hci_dev_do_close · e1b6eb3c
      Szymon Janc 提交于
      I've noticed that my CSR usb dongle was not working if it was plugged in when
      PC was booting. It looks like I get two HCI reset command complete events (see
      hcidump logs below).
      The root cause is reset called from off_timer. Timeout for this reset to
      complete is set to 250ms and my bt dongle requires more time for replying with
      command complete event. After that, chip seems to reply with reset command
      complete event for next non-reset command.
      
      Attached patch increase mentioned timeout to HCI_INIT_TIMEOUT, this value is
      already used for timeouting hci_reset_req in hci_dev_reset().
      
      This might also be related to BT not working after suspend that was reported
      here some time ago.
      
      Hcidump log:
      
      2011-09-12 23:13:27.379465 < HCI Command: Reset (0x03|0x0003) plen 0
      2011-09-12 23:13:27.380797 > HCI Event: Command Complete (0x0e) plen 4
          Reset (0x03|0x0003) ncmd 1
          status 0x00
      2011-09-12 23:13:27.380859 < HCI Command: Read Local Supported Features (0x04|0x000
      3) plen 0
      2011-09-12 23:13:27.760789 > HCI Event: Command Complete (0x0e) plen 4
          Reset (0x03|0x0003) ncmd 1
          status 0x00
      2011-09-12 23:13:27.760831 < HCI Command: Read Local Version Information (0x04|0x00
      01) plen 0
      2011-09-12 23:13:27.764780 > HCI Event: Command Complete (0x0e) plen 12
          Read Local Version Information (0x04|0x0001) ncmd 1
          status 0x00
          HCI Version: 1.1 (0x1) HCI Revision: 0x36f
          LMP Version: 1.1 (0x1) LMP Subversion: 0x36f
          Manufacturer: Cambridge Silicon Radio (10)
      Signed-off-by: NSzymon Janc <szymon@janc.net.pl>
      Signed-off-by: NGustavo F. Padovan <padovan@profusion.mobi>
      e1b6eb3c
  6. 30 10月, 2011 2 次提交
    • E
      vlan: allow nested vlan_do_receive() · 6a32e4f9
      Eric Dumazet 提交于
      commit 2425717b (net: allow vlan traffic to be received under bond)
      broke ARP processing on vlan on top of bonding.
      
             +-------+
      eth0 --| bond0 |---bond0.103
      eth1 --|       |
             +-------+
      
      52870.115435: skb_gro_reset_offset <-napi_gro_receive
      52870.115435: dev_gro_receive <-napi_gro_receive
      52870.115435: napi_skb_finish <-napi_gro_receive
      52870.115435: netif_receive_skb <-napi_skb_finish
      52870.115435: get_rps_cpu <-netif_receive_skb
      52870.115435: __netif_receive_skb <-netif_receive_skb
      52870.115436: vlan_do_receive <-__netif_receive_skb
      52870.115436: bond_handle_frame <-__netif_receive_skb
      52870.115436: vlan_do_receive <-__netif_receive_skb
      52870.115436: arp_rcv <-__netif_receive_skb
      52870.115436: kfree_skb <-arp_rcv
      
      Packet is dropped in arp_rcv() because its pkt_type was set to
      PACKET_OTHERHOST in the first vlan_do_receive() call, since no eth0.103
      exists.
      
      We really need to change pkt_type only if no more rx_handler is about to
      be called for the packet.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Reviewed-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a32e4f9
    • A
      ipv6: fix route lookup in addrconf_prefix_rcv() · 14ef37b6
      Andreas Hofmeister 提交于
      The route lookup to find a previously auto-configured route for a prefixes used
      to use rt6_lookup(), with the prefix from the RA used as an address. However,
      that kind of lookup ignores routing tables, the prefix length and route flags,
      so when there were other matching routes, even in different tables and/or with
      a different prefix length, the wrong route would be manipulated.
      
      Now, a new function "addrconf_get_prefix_route()" is used for the route lookup,
      which searches in RT6_TABLE_PREFIX and takes the prefix-length and route flags
      into account.
      Signed-off-by: NAndreas Hofmeister <andi@collax.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14ef37b6
  7. 29 10月, 2011 1 次提交
  8. 28 10月, 2011 1 次提交
  9. 27 10月, 2011 1 次提交
  10. 26 10月, 2011 2 次提交
    • D
      caif: Fix BUG() with network namespaces · 08613e46
      David Woodhouse 提交于
      The caif code will register its own pernet_operations, and then register
      a netdevice_notifier. Each time the netdevice_notifier is triggered,
      it'll do some stuff... including a lookup of its own pernet stuff with
      net_generic().
      
      If the net_generic() call ever returns NULL, the caif code will BUG().
      That doesn't seem *so* unreasonable, I suppose — it does seem like it
      should never happen.
      
      However, it *does* happen. When we clone a network namespace,
      setup_net() runs through all the pernet_operations one at a time. It
      gets to loopback before it gets to caif. And loopback_net_init()
      registers a netdevice... while caif hasn't been initialised. So the caif
      netdevice notifier triggers, and immediately goes BUG().
      
      We could imagine a complex and overengineered solution to this generic
      class of problems, but this patch takes the simple approach. It just
      makes caif_device_notify() *not* go looking for its pernet data
      structures if the device it's being notified about isn't a caif device
      in the first place.
      
      Cc: stable@kernel.org
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Acked-by: NSjur Brændeland <sjur.brandeland@stericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08613e46
    • T
      b0691c8e
  11. 25 10月, 2011 12 次提交
  12. 24 10月, 2011 7 次提交
  13. 22 10月, 2011 1 次提交
  14. 21 10月, 2011 2 次提交