summaryrefslogtreecommitdiffstats
path: root/net/bluetooth/l2cap.c
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: Add L2CAP option for max transmit valueMarcel Holtmann2009-12-031-1/+5
| | | | | | For testing purposes it is important to modify the max transmit value. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix 'SendRRorRNR' to send the ReqSeq valueGustavo F. Padovan2009-12-031-0/+2
| | | | | | | | | | | | | | | SendRRorRNR needs to acknowledge received I-frames (actually every packet needs to acknowledge received I-frames by sending the proper packet sequence number), so ReqSeq is set to the next I-frame number sequence to be pulled by the reassembly function. SendRRorRNR tells the remote side about local busy conditions, it sends a Receiver Ready frame if local busy is false or a Receiver Not Ready if local busy is true. ReqSeq is the packet's field to send the number of the acknowledged packets. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Implement RejActioned flagGustavo F. Padovan2009-12-031-3/+35
| | | | | | | | | | | | | | RejActioned is used to prevent retransmission when a entity is on the WAIT_F state, i.e., waiting for a frame with F-bit set due local busy condition or a expired retransmission timer. (When these two events raise they send a frame with the Poll bit set and enters in the WAIT_F state to wait for a frame with the Final bit set.) The local entity doesn't send I-frames(the data frames) until the receipt of a frame with F-bit set. When that happens it also set RejActioned to false. RejActioned is a mandatory feature of ERTM spec. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix sending ReqSeq on I-framesGustavo F. Padovan2009-12-031-2/+6
| | | | | | | | | | | | | | | | | As specified by ERTM spec an ERTM channel can acknowledge received I-frames(the data frames) by sending an I-frame with the proper ReqSeq value (i.e. ReqSeq is set to BufferSeq). Until now we aren't setting the ReqSeq value on I-frame control bits. That way we can save sending S-frames(Supervise frames) only to acknowledge receipt of I-frames. It is very helpful to the full-duplex channel. ReqSeq is the packet sequence number sent in an acknowledgement frame to acknowledge receipt of frames up to (ReqSeq - 1). BufferSeq controls the receiver buffer, it is used to delay acknowledgement of new frames to not cause buffer overflow. BufferSeq value is not increased until frames are pulled by reassembly function. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix unset of SrejActioned flagGustavo F. Padovan2009-12-031-1/+1
| | | | | | | | | | | | | | | | | | | SrejActioned is a flag that when set prevents local side to retransmit a I-frame(the data frame) already retransmitted. The local entity can retransmit again only when it receives a SREJ frame with the F-bit set. SREJ frame - Selective Reject frame - is sent when an entity wants the retransmission of a specific I-frame that was lost or corrupted. This bug can put ERTM in an unknown state once the entity can't retransmit. A frame with the Final bit set is expected when the local side sends a frame with the Poll bit set due to a local busy condition or a retransmission timer expired. (Receipt of P-bit shall always be replied by a frame with the F-bit set). pi->conn_state keeps informations about many ERTM flags including SrejActioned. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Initialize variables and timers for both channel's sidesGustavo F. Padovan2009-12-031-18/+36
| | | | | | | | | | | Fix ERTM's full-duplex channel to work as specified by ERTM spec. ERTM needs to handle state vars, timers and counters to send and receive I-frames(the data frames), i.e., for both sides of data communication. We initialize all of them to the default values here. Full-duplex channel is a mandatory feature of ERTM spec. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* net: Move && and || to end of previous lineJoe Perches2009-11-301-10/+10
| | | | | | | | | | | Not including net/atm/ Compiled tested x86 allyesconfig only Added a > 80 column line or two, which I ignored. Existing checkpatch plaints willfully, cheerfully ignored. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'master' of ↵David S. Miller2009-11-171-4/+9
|\ | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/can/Kconfig
| * Bluetooth: Fix regression with L2CAP configuration in Basic ModeGustavo F. Padovan2009-11-161-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Basic Mode is the default mode of operation of a L2CAP entity. In this case the RFC (Retransmission and Flow Control) configuration option should not be used at all. Normally remote L2CAP implementation should just ignore this option, but it can cause various side effects with other Bluetooth stacks that are not capable of handling unknown options. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: Select Basic Mode as default for SOCK_SEQPACKETGustavo F. Padovan2009-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | The default mode for SOCK_SEQPACKET is Basic Mode. So when no mode has been specified, Basic Mode shall be used. This is important for current application to keep working as expected and not cause a regression. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* | net: check kern before calling security subsystemEric Paris2009-11-061-1/+1
| | | | | | | | | | | | | | | | | | | | Before calling capable(CAP_NET_RAW) check if this operations is on behalf of the kernel or on behalf of userspace. Do not do the security check if it is on behalf of the kernel. Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: pass kern to net_proto_family create functionEric Paris2009-11-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | The generic __sock_create function has a kern argument which allows the security system to make decisions based on if a socket is being created by the kernel or by userspace. This patch passes that flag to the net_proto_family specific create function, so it can do the same thing. Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'master' of ↵David S. Miller2009-10-271-3/+6
|\| | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/net/sh_eth.c
| * bluetooth: static lock key fixDave Young2009-10-201-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When shutdown ppp connection, lockdep waring about non-static key will happen, it is caused by the lock is not initialized properly at that time. Fix with tuning the lock/skb_queue_head init order [ 94.339261] INFO: trying to register non-static key. [ 94.342509] the code is fine but needs lockdep annotation. [ 94.342509] turning off the locking correctness validator. [ 94.342509] Pid: 0, comm: swapper Not tainted 2.6.31-mm1 #2 [ 94.342509] Call Trace: [ 94.342509] [<c0248fbe>] register_lock_class+0x58/0x241 [ 94.342509] [<c024b5df>] ? __lock_acquire+0xb57/0xb73 [ 94.342509] [<c024ab34>] __lock_acquire+0xac/0xb73 [ 94.342509] [<c024b7fa>] ? lock_release_non_nested+0x17b/0x1de [ 94.342509] [<c024b662>] lock_acquire+0x67/0x84 [ 94.342509] [<c04cd1eb>] ? skb_dequeue+0x15/0x41 [ 94.342509] [<c054a857>] _spin_lock_irqsave+0x2f/0x3f [ 94.342509] [<c04cd1eb>] ? skb_dequeue+0x15/0x41 [ 94.342509] [<c04cd1eb>] skb_dequeue+0x15/0x41 [ 94.342509] [<c054a648>] ? _read_unlock+0x1d/0x20 [ 94.342509] [<c04cd641>] skb_queue_purge+0x14/0x1b [ 94.342509] [<fab94fdc>] l2cap_recv_frame+0xea1/0x115a [l2cap] [ 94.342509] [<c024b5df>] ? __lock_acquire+0xb57/0xb73 [ 94.342509] [<c0249c04>] ? mark_lock+0x1e/0x1c7 [ 94.342509] [<f8364963>] ? hci_rx_task+0xd2/0x1bc [bluetooth] [ 94.342509] [<fab95346>] l2cap_recv_acldata+0xb1/0x1c6 [l2cap] [ 94.342509] [<f8364997>] hci_rx_task+0x106/0x1bc [bluetooth] [ 94.342509] [<fab95295>] ? l2cap_recv_acldata+0x0/0x1c6 [l2cap] [ 94.342509] [<c02302c4>] tasklet_action+0x69/0xc1 [ 94.342509] [<c022fbef>] __do_softirq+0x94/0x11e [ 94.342509] [<c022fcaf>] do_softirq+0x36/0x5a [ 94.342509] [<c022fe14>] irq_exit+0x35/0x68 [ 94.342509] [<c0204ced>] do_IRQ+0x72/0x89 [ 94.342509] [<c02038ee>] common_interrupt+0x2e/0x34 [ 94.342509] [<c024007b>] ? pm_qos_add_requirement+0x63/0x9d [ 94.342509] [<c038e8a5>] ? acpi_idle_enter_bm+0x209/0x238 [ 94.342509] [<c049d238>] cpuidle_idle_call+0x5c/0x94 [ 94.342509] [<c02023f8>] cpu_idle+0x4e/0x6f [ 94.342509] [<c0534153>] rest_init+0x53/0x55 [ 94.342509] [<c0781894>] start_kernel+0x2f0/0x2f5 [ 94.342509] [<c0781091>] i386_start_kernel+0x91/0x96 Reported-by: Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by: Dave Young <hidave.darkstar@gmail.com> Tested-by: Oliver Hartkopp <oliver@hartkopp.net> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net: mark net_proto_ops as constStephen Hemminger2009-10-071-1/+1
|/ | | | | | | All usages of structure net_proto_ops should be declared const. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Make setsockopt() optlen be unsigned.David S. Miller2009-10-011-2/+2
| | | | | | | | | | | | This provides safety against negative optlen at the type level instead of depending upon (sometimes non-trivial) checks against this sprinkled all over the the place, in each and every implementation. Based upon work done by Arjan van de Ven and feedback from Linus Torvalds. Signed-off-by: David S. Miller <davem@davemloft.net>
* Bluetooth: Add support for L2CAP 'Send RRorRNR' actionGustavo F. Padovan2009-08-261-6/+14
| | | | | | | | When called, 'Send RRorRNR' should send a RNR frame if local device is busy or a RR frame otherwise. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Handle L2CAP case when the remote receiver is busyGustavo F. Padovan2009-08-261-2/+23
| | | | | | | Implement all issues related to RemoteBusy in the RECV state table. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Acknowledge L2CAP packets when receiving RR-frames (F-bit=1)Gustavo F. Padovan2009-08-261-1/+5
| | | | | | | | Implement the Recv ReqSeqAndFBit event when a RR frame with F bit set is received. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use proper *_unaligned_le{16,32} helpers for L2CAPGustavo F. Padovan2009-08-241-2/+2
| | | | | | | Simplify more conversions to the right endian with the proper helpers. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add locking scheme to L2CAP timeout callbacksGustavo F. Padovan2009-08-241-0/+4
| | | | | | | | Avoid race conditions when accessing the L2CAP socket from within the timeout handlers. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Full support for receiving L2CAP SREJ framesGustavo F. Padovan2009-08-231-1/+29
| | | | | | | Support for receiving of SREJ frames as specified by the state table. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add support for L2CAP SREJ exceptionGustavo F. Padovan2009-08-231-24/+196
| | | | | | | | | | When L2CAP loses an I-frame we send a SREJ frame to the transmitter side requesting the lost packet. This patch implement all Recv I-frame events on SREJ_SENT state table except the ones that deal with SendRej (the REJ exception at receiver side is yet not implemented). Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add support for FCS option to L2CAPGustavo F. Padovan2009-08-221-6/+95
| | | | | | | | | | | | | Implement CRC16 check for L2CAP packets. FCS is used by Streaming Mode and Enhanced Retransmission Mode and is a extra check for the packet content. Using CRC16 is the default, L2CAP won't use FCS only when both side send a "No FCS" request. Initially based on a patch from Nathan Holstein <nathan@lampreynetworks.com> Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Enable Streaming Mode for L2CAPGustavo F. Padovan2009-08-221-9/+73
| | | | | | | | Streaming Mode is helpful for the Bluetooth streaming based profiles, such as A2DP. It doesn't have any error control or flow control. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add support for Retransmission and Monitor TimersGustavo F. Padovan2009-08-221-4/+82
| | | | | | | | | | | L2CAP uses retransmission and monitor timers to inquiry the other side about unacked I-frames. After sending each I-frame we (re)start the retransmission timer. If it expires, we start a monitor timer that send a S-frame with P bit set and wait for S-frame with F bit set. If monitor timer expires, try again, at a maximum of L2CAP_DEFAULT_MAX_TX. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Initial support for retransmission of packets with REJ framesGustavo F. Padovan2009-08-221-14/+43
| | | | | | | | | | | | When receiving an I-frame with unexpected txSeq, receiver side start the recovery procedure by sending a REJ S-frame to the transmitter side. So the transmitter can re-send the lost I-frame. This patch just adds a basic support for retransmission, it doesn't mean that ERTM now has full support for packet retransmission. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add support for Segmentation and Reassembly of SDUsGustavo F. Padovan2009-08-221-16/+154
| | | | | | | | | | | | | | ERTM should use Segmentation and Reassembly to break down a SDU in many PDUs on sending data to the other side. On sending packets we queue all 'segments' until end of segmentation and just the add them to the queue for sending. On receiving we create a new SKB with the SDU reassembled. Initially based on a patch from Nathan Holstein <nathan@lampreynetworks.com> Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add initial support for ERTM packets transfersGustavo F. Padovan2009-08-221-49/+335
| | | | | | | | | | | | | | This patch adds support for ERTM transfers, without retransmission, with txWindow up to 63 and with acknowledgement of packets received. Now the packets are queued before call l2cap_do_send(), so packets couldn't be sent at the time we call l2cap_sock_sendmsg(). They will be sent in an asynchronous way on later calls of l2cap_ertm_send(). Besides if an error occurs on calling l2cap_do_send() we disconnect the channel. Initially based on a patch from Nathan Holstein <nathan@lampreynetworks.com> Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Create separate l2cap_send_disconn_req() functionGustavo F. Padovan2009-08-221-30/+16Star
| | | | | | | | The code for sending a disconnect request was repeated several times within L2CAP source code. So move this into its own function. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add configuration support for ERTM and Streaming modeGustavo F. Padovan2009-08-221-28/+234
| | | | | | | | | | | Add support to config_req and config_rsp to configure ERTM and Streaming mode. If the remote device specifies ERTM or Streaming mode, then the same mode is proposed. Otherwise ERTM or Basic mode is used. And in case of a state 2 device, the remote device should propose the same mode. If not, then the channel gets disconnected. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add L2CAP RFC option if ERTM is enabledMarcel Holtmann2009-08-221-3/+20
| | | | | | | When trying to establish a connection with Enhanced Retransmission mode enabled, the RFC option needs to be added to the configuration. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Allow setting of L2CAP ERTM via socket optionMarcel Holtmann2009-08-221-4/+33
| | | | | | | | | To enable Enhanced Retransmission mode it needs to be set via a socket option. A different mode can be set on a socket, but on listen() and connect() the mode is checked and ERTM is only allowed if it is enabled via the module parameter. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add module option to enable L2CAP ERTM supportMarcel Holtmann2009-08-221-2/+10
| | | | | | | | Since the Enhanced Retransmission mode for L2CAP is still under heavy development disable it by default and provide a module option to enable it manually for testing. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove pointless endian conversion helpersMarcel Holtmann2009-06-081-9/+10
| | | | | | | | The Bluetooth source uses some endian conversion helpers, that in the end translate to kernel standard routines. So remove this obfuscation since it is fully pointless. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add basic constants for L2CAP ERTM support and use themMarcel Holtmann2009-06-081-3/+3
| | | | | | | | | This adds the basic constants required to add support for L2CAP Enhanced Retransmission feature. Based on a patch from Nathan Holstein <nathan@lampreynetworks.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix errors and warnings in L2CAP reported by checkpatch.plGustavo F. Padovan2009-06-081-27/+43
| | | | | | | | | | | This patch fixes the errors without changing the l2cap.o binary: text data bss dec hex filename 18059 568 0 18627 48c3 l2cap.o.after 18059 568 0 18627 48c3 l2cap.o.before Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove unnecessary variable initializationMarcel Holtmann2009-06-081-1/+1
| | | | | | | | | The initial value of err is not used until it is set to -ENOMEM. So just remove the initialization completely. Based on a patch from Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use macro for L2CAP hint mask on receiving config requestGustavo F. Padovan2009-06-081-1/+1
| | | | | | | | Using the L2CAP_CONF_HINT macro is easier to understand than using a hardcoded 0x80 value. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use macros for L2CAP channel identifiersGustavo F. Padovan2009-06-081-9/+9
| | | | | | | | Use macros instead of hardcoded numbers to make the L2CAP source code more readable. Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Remove some pointless conditionals before kfree_skb()Wei Yongjun2009-02-271-2/+1Star
| | | | | | | Remove some pointless conditionals before kfree_skb(). Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Permit BT_SECURITY also for L2CAP raw socketsMarcel Holtmann2009-02-271-2/+2
| | | | | | | | | Userspace pairing code can be simplified if it doesn't have to fall back to using L2CAP_LM in the case of L2CAP raw sockets. This patch allows the BT_SECURITY socket option to be used for these sockets. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Disallow usage of L2CAP CID setting for nowMarcel Holtmann2009-02-271-6/+10
| | | | | | | | | | In the future the L2CAP layer will have full support for fixed channels and right now it already can export the channel assignment, but for the functions bind() and connect() the usage of only CID 0 is allowed. This allows an easy detection if the kernel supports fixed channels or not, because otherwise it would impossible for application to tell. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix authentication requirements for L2CAP security checkMarcel Holtmann2009-02-271-10/+20
| | | | | | | | | | | The L2CAP layer can trigger the authentication via an ACL connection or later on to increase the security level. When increasing the security level it didn't use the same authentication requirements when triggering a new ACL connection. Make sure that exactly the same authentication requirements are used. The only exception here are the L2CAP raw sockets which are only used for dedicated bonding. Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Ask upper layers for HCI disconnect reasonMarcel Holtmann2009-02-271-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <marcel@holtmann.org>
* Bluetooth: Add CID field to L2CAP socket address structureMarcel Holtmann2009-02-271-21/+34
| | | | | | | | | | | | | | 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 <marcel@holtmann.org>
* Bluetooth: Request L2CAP fixed channel list if availableMarcel Holtmann2009-02-271-9/+31
| | | | | | | | | | 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 <marcel@holtmann.org>
* Bluetooth: Don't enforce authentication for L2CAP PSM 1 and 3Marcel Holtmann2009-02-271-1/+4
| | | | | | | | | | | | | | | | | 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 <marcel@holtmann.org>
* Bluetooth: Fix double L2CAP connection requestMarcel Holtmann2009-02-271-0/+8
| | | | | | | | | | | 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 <marcel@holtmann.org>
* Bluetooth: Fix race condition with L2CAP information requestMarcel Holtmann2009-02-271-3/+14
| | | | | | | | | | 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 <marcel@holtmann.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-09 19:12:57 +0200