| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This is preparation for allowing the device object to be correctly set up even
when we don't have the full service records but only the remote UUID's.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Since it's important for us to find out what profiles a device has in order to
populate the device object with the correct D-Bus interfaces insist on doing
SDP even if got disconnected from the device. Since the timer is only 2 seconds
the chances are that device will still be around and the connection will be
successfull. This situation can happen if the remote device acts as an
initiator for dedicated bonding and brings down the ACL before our timer goes
off.
|
| |
|
|
|
|
|
|
|
| |
Some devices will hide their service secords when they are connected so we
incorrectly think that they have removed support for the profile. A simple
solution is not to try to do this detection when we are doing reverse service
discovery.
|
|
|
|
|
|
|
|
|
| |
The original code seems to try to handle the situation of two opposite directed
pairing attempts (remote side starts dedicated bonding with us but someone
calls CreatePairedDevice on our side at the same time). I'm not sure how likely
this actually is or if it can even succeed, but the existing logic in the code
was nevertheless wrong. After this patch is at least in theory makes sense to
me (and is better commented if I forget what I was thinking when I wrote it).
|
| |
|
|
|
|
|
|
|
|
| |
In theory a headset could be in a connected state when the driver for it gets
unregistered. Do proper cleanup in this case (call headset_set_state(hs,
DISCONNECTED)). Currently this happens even in practice due to a bug where we
incorrectly assume that a device has removed a profile when in fact it's just
hiding it while it's connected.
|
| |
|
|
|
|
|
|
|
| |
We can't initialize dev->sink in the AVDTP server callback since at this point
we don't know if the remote device will be acting in audio source or audio sink
role. So, do the initialization when we get the SetConfiguration command since
then we can check the type of the SEP that was selected.
|
|
|
|
|
|
| |
If we haven't done SDP yet the data structures will be uninitialized. This
patch makes sure that the structures are properly initialized if we get an
incoming connection before service discovery has been done.
|
|
|
|
|
| |
This is needed in preparation of supporting remotely initated audio device
pairing and connections (when we haven't done SDP to the remote device yet).
|
|
|
|
|
|
| |
Basicly reverts the previous commit since data calls just don't make sense with
HFP. Check for proper voice call dial string and pass the number without the
terminating semicolon to the telephony driver.
|
| |
|
|
|
|
|
|
|
| |
Voice call ATD requests have a semicolon at the end of the string while data
call requests don't. So detect this and don't copy the semicolon to the
currently active number (possible sent back to the headset in subsequent
operations).
|
|
|
|
|
|
| |
Without this fix we segfault if a device pairs and connects to us before we
have completed service discovery to it. Underneath is a more fundamental
problem of how we initialize our data structures and this still needs fixing.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
We got one segfault due to hs == NULL but I couldn't figure out how on earth in
could happen. The best I can do right now is to have an assert to catch it
instead of a direct segfault.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
In theory the device might have been removed if the D-Bus client exited before
the remote side accepted the pairing. This is just a short term fix since
security.c is still storing the link key. In the long run we should move the
link key storing to dbus-hci.c and only do it when we get auth complete or
connect complete.
|
|
|
|
|
|
| |
Without this fix the temporary flag was never cleared (for the auto-accept
case) and so the device was incorrectly removed at the end of the bonding
process.
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
> ACL data: handle 11 flags 0x02 dlen 34
L2CAP(d): cid 0x0040 len 30 [psm 1]
SDP SSA Req: tid 0x6c len 0x19
pat uuid-16 0x110a (AudioSource) uuid-16 0x0100 (L2CAP) uuid-16 0x0019 (AVDTP)
max 100
aid(s) 0x0004 (ProtocolDescList) 0x0009 (BTProfileDescList) 0x0311 (SuppFeatures)
cont 00
< ACL data: handle 11 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 1]
SDP SSA Rsp: tid 0x6c len 0x5
count 2
cont 00
Without this fix even searching for the L2CAP UUID fails.
|
|/ |
|
| |
|
|\ |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
| |
The pending connect is still needed when rfcomm_connect_cb gets informed of the
failed connect attempt.
|
| |
|
| |
|
|\ |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|