linux-toradex.git/include/net, branch tegra-9.12.7

Bluetooth: Increase timeout for legacy pairing from 10 seconds to 40 seconds.

2009-09-20T19:42:12+00:00

Legacy pairing is a bit of a problem because on the incoming end it is
impossible to know pairing has begun:

2009-09-18 18:29:24.115692 > HCI Event: Connect Request (0x04) plen 10
    bdaddr 00:23:D4:04:51:7A class 0x58020c type ACL
2009-09-18 18:29:24.115966 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:23:D4:04:51:7A role 0x00
    Role: Master
2009-09-18 18:29:24.117065 > HCI Event: Command Status (0x0f) plen 4
    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2009-09-18 18:29:24.282928 > HCI Event: Role Change (0x12) plen 8
    status 0x00 bdaddr 00:23:D4:04:51:7A role 0x00
    Role: Master
2009-09-18 18:29:24.291534 > HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 1 bdaddr 00:23:D4:04:51:7A type ACL encrypt 0x00
2009-09-18 18:29:24.291839 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
    handle 1
2009-09-18 18:29:24.292144 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
    bdaddr 00:23:D4:04:51:7A mode 1
2009-09-18 18:29:24.293823 > HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2009-09-18 18:29:24.303588 > HCI Event: Max Slots Change (0x1b) plen 3
    handle 1 slots 5
2009-09-18 18:29:24.309448 > HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 1
    Features: 0xff 0xff 0x2d 0xfe 0x9b 0xff 0x79 0x83
2009-09-18 18:29:24.345916 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 00:23:D4:04:51:7A mode 2 clkoffset 0x0000
2009-09-18 18:29:24.346923 > HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2009-09-18 18:29:24.375793 > HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 00:23:D4:04:51:7A name 'test'
2009-09-18 18:29:34.332190 < HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 1 reason 0x13

There are some mainline patches such as "Add different pairing timeout for
Legacy Pairing" but they do not address the HCI sequence above.

I think the real solution is to avoid using CreateBond(), and instead make
the profile connection immediately. This way both sides will use a longer
timeout because there is a higher level connection in progress, and we will
not end up with the useless HCI sequence above.

Signed-off-by: Nick Pelly

Bluetooth: Ensure that HCI sysfs add/del is preempt safe

2009-09-20T19:28:01+00:00

Use a different work_struct variables for add_conn() and del_conn() and
use single work queue instead of two for adding and deleting connections.

It eliminates the following error on a preemptible kernel:

[  204.358032] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[  204.370697] pgd = c0004000
[  204.373443] [0000000c] *pgd=00000000
[  204.378601] Internal error: Oops: 17 [#1] PREEMPT
[  204.383361] Modules linked in: vfat fat rfcomm sco l2cap sd_mod scsi_mod iphb pvr2d drm omaplfb ps
[  204.438537] CPU: 0    Not tainted  (2.6.28-maemo2 #1)
[  204.443664] PC is at klist_put+0x2c/0xb4
[  204.447601] LR is at klist_put+0x18/0xb4
[  204.451568] pc : []    lr : []    psr: a0000113
[  204.451568] sp : cf1b3f10  ip : cf1b3f10  fp : cf1b3f2c
[  204.463104] r10: 00000000  r9 : 00000000  r8 : bf08029c
[  204.468353] r7 : c7869200  r6 : cfbe2690  r5 : c78692c8  r4 : 00000001
[  204.474945] r3 : 00000001  r2 : cf1b2000  r1 : 00000001  r0 : 00000000
[  204.481506] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment kernel
[  204.488861] Control: 10c5387d  Table: 887fc018  DAC: 00000017
[  204.494628] Process btdelconn (pid: 515, stack limit = 0xcf1b22e0)

Signed-off-by: Roger Quadros 
Signed-off-by: Marcel Holtmann

net: socket ioctl to reset connections matching local address

2009-04-07T23:43:12+00:00

Introduce a new socket ioctl, SIOCKILLADDR, that nukes all sockets
bound to the same local address. This is useful in situations with
dynamic IPs, to kill stuck connections.

Signed-off-by: Brian Swetland 

net: fix tcp_v4_nuke_addr

Signed-off-by: Dima Zavin

Bluetooth: Ask upper layers for HCI disconnect reason

2009-04-07T00:39:29+00:00

Some of the qualification tests demand that in case of failures in L2CAP
the HCI disconnect should indicate a reason why L2CAP fails. This is a
bluntly layer violation since multiple L2CAP connections could be using
the same ACL and thus forcing a disconnect reason is not a good idea.

To comply with the Bluetooth test specification, the disconnect reason
is now stored in the L2CAP connection structure and every time a new
L2CAP channel is added it will set back to its default. So only in the
case where the L2CAP channel with the disconnect reason is really the
last one, it will propagated to the HCI layer.

The HCI layer has been extended with a disconnect indication that allows
it to ask upper layers for a disconnect reason. The upper layer must not
support this callback and in that case it will nicely default to the
existing behavior. If an upper layer like L2CAP can provide a disconnect
reason that one will be used to disconnect the ACL or SCO link.

No modification to the ACL disconnect timeout have been made. So in case
of Linux to Linux connection the initiator will disconnect the ACL link
before the acceptor side can signal the specific disconnect reason. That
is perfectly fine since Linux doesn't make use of this value anyway. The
L2CAP layer has a perfect valid error code for rejecting connection due
to a security violation. It is unclear why the Bluetooth specification
insists on having specific HCI disconnect reason.

Signed-off-by: Marcel Holtmann

Bluetooth: Add CID field to L2CAP socket address structure

2009-04-07T00:39:29+00:00

In preparation for L2CAP fixed channel support, the CID value of a
L2CAP connection needs to be accessible via the socket interface. The
CID is the connection identifier and exists as source and destination
value. So extend the L2CAP socket address structure with this field and
change getsockname() and getpeername() to fill it in.

The bind() and connect() functions have been modified to handle L2CAP
socket address structures of variable sizes. This makes them future
proof if additional fields need to be added.

Signed-off-by: Marcel Holtmann

Bluetooth: Request L2CAP fixed channel list if available

2009-04-07T00:39:29+00:00

If the extended features mask indicates support for fixed channels,
request the list of available fixed channels. This also enables the
fixed channel features bit so remote implementations can request
information about it. Currently only the signal channel will be
listed.

Signed-off-by: Marcel Holtmann

Bluetooth: Don't enforce authentication for L2CAP PSM 1 and 3

2009-04-07T00:39:29+00:00

The recommendation for the L2CAP PSM 1 (SDP) is to not use any kind
of authentication or encryption. So don't trigger authentication
for incoming and outgoing SDP connections.

For L2CAP PSM 3 (RFCOMM) there is no clear requirement, but with
Bluetooth 2.1 the initiator is required to enable authentication
and encryption first and this gets enforced. So there is no need
to trigger an additional authentication step. The RFCOMM service
security will make sure that a secure enough link key is present.

When the encryption gets enabled after the SDP connection setup,
then switch the security level from SDP to low security.

Signed-off-by: Marcel Holtmann

Bluetooth: Fix double L2CAP connection request

2009-04-07T00:39:29+00:00

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: Marcel Holtmann

Bluetooth: Fix race condition with L2CAP information request

2009-04-07T00:39:29+00:00

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: Marcel Holtmann

Bluetooth: Use general bonding whenever possible

2009-04-07T00:39:29+00:00

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: Marcel Holtmann