From: Fabien Chevalier <fchevalier@silicom.fr>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Johan Hedberg <johan.hedberg@nokia.com>,
BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [PATCH] Fix bogus avdtp error codes management
Date: Tue, 18 Sep 2007 10:57:38 +0200 [thread overview]
Message-ID: <46EF9302.50403@silicom.fr> (raw)
In-Reply-To: <1190104027.5525.128.camel@aeonflux.holtmann.net>
[-- Attachment #1.1: Type: text/plain, Size: 1838 bytes --]
Hi All,
The attached patch makes sure that the correct error code is returned to
the upper layers.
The issue with the current cvs's code is that EIO would be returned
whatever the error code returned by the L2CAP layer is, as
getsockopt(sk, SOL_SOCKET, SO_ERROR, ....) would never be called.
The result of this patch is that you now see the reason of the failure
in daemon log in case of L2CAP issue, such as:
Sep 18 10:32:53 tannat audio[16934]: avdtp_ref(0x806d230): ref=2
Sep 18 10:32:53 tannat audio[16934]: a2dp_source_request_stream:
selected SEP 0x806a400
Sep 18 10:32:53 tannat audio[16934]: avdtp_ref(0x806d230): ref=3
Sep 18 10:32:53 tannat audio[16934]: stream creation in progress
Sep 18 10:33:13 tannat audio[16934]: connect(): Host is down (112)
As for the POLLOUT thing, i must say i'm confused..., and don't really
see the link with the patch :-(
I guess it works already as the GIOChannels heavily rely on it.
Can any of you apply this patch ?
Cheers,
Fabien
> Hi Johan,
>
>
>>> While trying to fix this cross case issue, i came with an issue with the
>>> way error codes are handled
>>> in avdtp.c.
>>> The issue is basically that the part of the code that retrieves the
>>> exact error value is never executed
>>> due to premature return.
>>>
>> Looks fine to me if it works. However, I'd like to hear some comment
>> from Marcel as well. At least my connect(2) manpage implies that a
>> non-blocking connect should always produce a POLLOUT on connection
>> completion regardless if the result was failure or success. So it seems
>> bluez may be behaving differently than other socket types in this
>> respect.
>>
>
> if that is so, then we have to fix the kernel. Can someone write me a
> simple reproducer or better send me a patch for the kernel.
>
> Regards
>
> Marcel
>
>
>
>
>
[-- Attachment #1.2: Type: text/html, Size: 2372 bytes --]
[-- Attachment #2: fchevalier.vcf --]
[-- Type: text/x-vcard, Size: 253 bytes --]
begin:vcard
fn:Fabien CHEVALIER
n:CHEVALIER;Fabien
org:SILICOM
adr:;;4 rue de Jouanet; RENNES ATALANTE;;35700;FRANCE
email;internet:fchevalier@silicom.fr
title:Software & Studies Engineer
tel;work:+33 (0) 2 99 84 17 17
version:2.1
end:vcard
next prev parent reply other threads:[~2007-09-18 8:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 17:41 [PATCH] Fix bogus avdtp error codes management Fabien Chevalier
2007-09-18 8:15 ` Johan Hedberg
2007-09-18 8:27 ` [Bluez-devel] " Marcel Holtmann
2007-09-18 8:57 ` Fabien Chevalier [this message]
2007-09-18 9:09 ` Johan Hedberg
2007-09-18 12:00 ` [Bluez-devel] " Fabien Chevalier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46EF9302.50403@silicom.fr \
--to=fchevalier@silicom.fr \
--cc=bluez-devel@lists.sourceforge.net \
--cc=johan.hedberg@nokia.com \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox