AT+CHUP should release the active call if there's both a held and an
active call. So instead of looking for the first non-idle call look for a
call in ACTIVE state and only then for a non-idle one. Also rename the
find_active_call() to find_non_idle_call() to indicate what it's really
doing.
Calling stat() before dlopen() is useless since in theory the file can get
removed between the two calls and so dlopen() needs to be able to handle
ENOENT in any case.
In the case that the AVDTP session references weren't fully dropped when a
disconnection happens, in later reconnections the disconnect_timeout
function cound have a reference count higher than 1. These bugs naturally
need to fixed (and there's a proper error() call to log them) but we can
still handle the situation semi-cleanly instead of asserting and aborting
since the AVDTP session struct will just silently hang around and get
reused at the next connection attempt.
The regression was introduced by audio_device_request_authorization which
cause the authorization request to be added the list no matter what
btd_request_authorization returns.
The error being returned for hang up currently is
org.bluez.Error.ConnectionAttemptFailed which is not accurate since the
connection itself was already established.
This should fix it by translating the hang up to
org.bluez.Error.AuthenticationCanceled.
Like with the A2DP signalling channel this makes sure no process reads or
writes the SCO channel after bluetoothd wants it to be closed.
At the moment of writing this patch the kernel doesn't seem to handle this
right so a fix is needed on that side too for the intended effect to take
place.
This makes sure that no other process (e.g. pulseaudio) reads or writes
the stream channel after it is logically closed through the AVDTP
signalling channel.
Some headsets (Nokia HS-12W) connects first on avrcp and only then on hfp
so in case Trusted property is not set this will cause agent_authorize to
return -EBUSY and drop hfp connection.
The proper solution would be to group all connections requests only
sending one authorization so the agent either accept them all or not, but
that would require API changes which we are avoiding right now, so the
current fix only send one connection request which the reponse is used for
the rest of the connections.
Situations where both sides end up sending commands are rare but they can
happen. They are also not fatal since one side will usually just end up
getting a "SEP in bad state" error and give up its setup procedure while
the other sides setup succeeds.
If we have a command that's pending a reply for don't set the disconnect
timer after processing a command from the other device (this is especially
important since the timeout for our pending requests is longer than the
disconnect timeout (4 seconds vs. 1 second).
Add --udev option to bluetoothd, to allow it to be started on-demand
from udev.
When a new adapter appears, udev would launch bluetoothd --udev.
To avoid problems with udev, bluetoothd --udev would only return
an error exit code if it wasn't already running and a real error
occurred.
When no more Bluetooth adapter are present on the system, bluetoothd
will exit after a 30 second timeout.
We shouldn't call bt_cancel_discovery if we're withing a SDP callback so
always make sure that p->svclass is 0 before calling
pending_connect_finalize (which uses this value to determine whether
cancelation is needed). The glib-helper.c code should still safeguard
against this too and that's what the previous commit fixes.
HSP search should only be done in case of no HFP record is not found, in case
of error it should stop right there since the second attempt will probably lead
to tge very same error.
CreatePairedDevice should succeed if the pairing succeeds, but return only
after the SDP discovery is complete (either a success or a failure). Right
now the logic of the temporary flag and CancelDeviceCreation was such that
the device would be removed in the case of a successful pairing if the SDP
part failed.
This patch fixes the issue by clearing the temporary flag imediately after
a successful pairing but still allows CancelDeviceCreation to be called
after the pairing is complete but SDP isn't (i.e. Create*Device hasn't
returned anything yet). A new helper function for CancelDeviceCreation
called device_is_creating was added to allow easy checking of an ongoing
device creation.
