[Bluez-devel] Regarding a2recv

[Bluez-devel] Regarding a2recv

[Mayank Batra]

Henryk,

Did you try what I suggested you in my mail titled 'A
small Query' ?

That is, swap the message_type and packet_type fields
of the structure

struct avdtp_header {
	uint8_t packet_type:2;
	uint8_t message_type:2;
	uint8_t transaction_label:4;
	uint8_t signal_id:6;
	uint8_t rfa0:2;
} __attribute__ ((packed));

in the file a2dp.h

i.e. make it look like the following:
struct avdtp_header {
	uint8_t message_type:2;
	uint8_t packet_type:2;
	uint8_t transaction_label:4;
	uint8_t signal_id:6;
	uint8_t rfa0:2;
} __attribute__ ((packed));


Once you swap them, I feel that a2recv will work for
you.
If it doesn't work, send me a copy of the dump.

Regards,

Mayank

________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Marcel Holtmann]

Hi Mayank,

> Did you try what I suggested you in my mail titled 'A
> small Query' ?
> 
> That is, swap the message_type and packet_type fields
> of the structure
> 
> struct avdtp_header {
> 	uint8_t packet_type:2;
> 	uint8_t message_type:2;
> 	uint8_t transaction_label:4;
> 	uint8_t signal_id:6;
> 	uint8_t rfa0:2;
> } __attribute__ ((packed));
> 
> in the file a2dp.h
> 
> i.e. make it look like the following:
> struct avdtp_header {
> 	uint8_t message_type:2;
> 	uint8_t packet_type:2;
> 	uint8_t transaction_label:4;
> 	uint8_t signal_id:6;
> 	uint8_t rfa0:2;
> } __attribute__ ((packed));
> 
> 
> Once you swap them, I feel that a2recv will work for
> you.

this is correct. After checking the specs, the message_type are the
first two bits and then packet_type follows.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Brad Midgley]

Mayank,

Good job finding that error.

Sorry I was slow to figure out what you were saying and didn't get it. I 
made the fix.

If you show us the output of 'cvs diff' you'll be able to make these 
things clear with less effort on your part:

$ cvs diff a2dp.h
Index: a2dp.h
===================================================================
RCS file: /cvsroot/bluetooth-alsa/btsco/a2dp.h,v
retrieving revision 1.3
diff -u -b -B -w -p -r1.3 a2dp.h
--- a2dp.h      2 May 2005 16:01:19 -0000       1.3
+++ a2dp.h      5 May 2005 14:34:20 -0000
@@ -38,8 +38,8 @@ struct sbc_frame_header {
  /* packet components */

  struct avdtp_header {
-       uint8_t packet_type:2;
         uint8_t message_type:2;
+       uint8_t packet_type:2;
         uint8_t transaction_label:4;
         uint8_t signal_id:6;
         uint8_t rfa0:2;

Brad

Mayank Batra wrote:
> Henryk,
> 
> Did you try what I suggested you in my mail titled 'A
> small Query' ?
> 
> That is, swap the message_type and packet_type fields
> of the structure
> 
> struct avdtp_header {
> 	uint8_t packet_type:2;
> 	uint8_t message_type:2;
> 	uint8_t transaction_label:4;
> 	uint8_t signal_id:6;
> 	uint8_t rfa0:2;
> } __attribute__ ((packed));
> 
> in the file a2dp.h
> 
> i.e. make it look like the following:
> struct avdtp_header {
> 	uint8_t message_type:2;
> 	uint8_t packet_type:2;
> 	uint8_t transaction_label:4;
> 	uint8_t signal_id:6;
> 	uint8_t rfa0:2;
> } __attribute__ ((packed));
> 
> 
> Once you swap them, I feel that a2recv will work for
> you.
> If it doesn't work, send me a copy of the dump.
> 
> Regards,
> 
> Mayank
> 
> ________________________________________________________________________
> Yahoo! India Matrimony: Find your life partner online
> Go to: http://yahoo.shaadi.com/india-matrimony
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Henryk Plötz]

[-- Attachment #1.1: Type: text/plain, Size: 2672 bytes --]

Moin,

Am Thu, 5 May 2005 13:45:12 +0100 (BST) schrieb Mayank Batra:

> Did you try what I suggested you in my mail titled 'A
> small Query' ?

Ah no, but luckily Brad did. However, that wasn't the problem. The
problem was that a2recv didn't correctly fill out the transaction
label. When responding to a request one must use the same transaction
label that the other side used.

I don't fully understand the logic behind what init_request() in
a2recv.c does to the transaction_label, but it's most likely wrong.

I therefore introduced a function init_response() that takes the header
of the command that was received and creates a positive response header.
init_request() is then used nowhere anymore, so I #if 0'd it. I also
went through a hcidump of the (now working) stream setup phase and
compared it to the AVDTP spec. Most of it looks correct now, except for
Open Stream Response and Start Stream Response, which are too long (I'm
not sure what to do about that as the additional byte(s) are reserved in
the struct open_stream_rsp and struct start_stream_rsp for the case of
an error).

So now I made it to "Sent start stream confirm" but not further as the
audio dongle doesn't seem to start streaming. The last three packets I
see in an hcidump are

1115349894.700415 > ACL data: handle 41 flags 0x02 dlen 7
    L2CAP(d): cid 0x0040 len 3 [psm 25]
      AVDTP(s): Start cmd: transaction 5
        ACP SEID 1
1115349894.700472 < ACL data: handle 41 flags 0x02 dlen 8
    L2CAP(d): cid 0x0041 len 4 [psm 25]
      AVDTP(m): ver 1 ext cc 2 pt 7 seqn 0 time 1090519040 ssrc 40962
1115349894.709416 > HCI Event: Number of Completed Packets (0x13) plen 5
  0000: 01 29 00 01 00                                    .)...

(The second packet is actually an almost proper Start Stream Response 
that's only decoded wrong by hcidump. hcidump -R shows
1115349894.700472 < 0000: 02 29 20 08 00 04 00 41  00 52 07 00 00
which is correct, except for the two trailing zeros.)

After that things sit still for about 6 seconds and then I get

1115351711.667759 > HCI Event: Disconn Complete (0x05) plen 4
  0000: 00 28 00 08                                       .(..

I have attached a dump of the whole process (and the beginning of 
the reconnections that the dongle tries after the failure).

Anyways: I have committed the changed transaction_label handling to 
CVS, so please check that it doesn't break your already working 
devices.

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #1.2: iphono_to_a2rcv --]
[-- Type: application/octet-stream, Size: 2434 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-devel] Regarding a2recv

[Mayank Batra]

Henryk,

> Ah no, but luckily Brad did. However, that wasn't
> the problem. The
> problem was that a2recv didn't correctly fill out
> the transaction
> label. When responding to a request one must use the
> same transaction
> label that the other side used.

I believe that should have been a problem because
interchanding packet_type and message_type does make a
lot of difference to the avdtp packet.

Also, I agree that the init_request() function was not
much thought after while it was being written.
 
> I don't fully understand the logic behind what
> init_request() in
> a2recv.c does to the transaction_label, but it's
> most likely wrong.

Yes, we can simply copy the transation label given by
the source in the response.

> I therefore introduced a function init_response()
> that takes the header
> of the command that was received and creates a
> positive response header.
> init_request() is then used nowhere anymore, so I
> #if 0'd it. I also
> went through a hcidump of the (now working) stream
> setup phase and
> compared it to the AVDTP spec. Most of it looks
> correct now, except for
> Open Stream Response and Start Stream Response,
> which are too long (I'm
> not sure what to do about that as the additional
> byte(s) are reserved in
> the struct open_stream_rsp and struct
> start_stream_rsp for the case of
> an error).
 
> So now I made it to "Sent start stream confirm" but
> not further as the
> audio dongle doesn't seem to start streaming. The
> last three packets I
> see in an hcidump are

Why doesn't the streaming start?
 
> Anyways: I have committed the changed
> transaction_label handling to 
> CVS, so please check that it doesn't break your
> already working 
> devices.

I'll do that.


Mayank

________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Henryk Plötz]

[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

Moin,

Am Sun, 8 May 2005 13:50:39 +0100 (BST) schrieb Mayank Batra:

> I believe that should have been a problem because
> interchanding packet_type and message_type does make a
> lot of difference to the avdtp packet.

Yes, it does.

I now completely restructured the a2recv code into something that more
closely resembles a socket server application. Basically it is now a
giant endless loop that is blocking in select() on the serverfd and
optionally the cmdfd and streamfd (should they be open) and as soon as
there is data to read or a connection to accept I am reading it.

There is also an internal state like that from the AVDTP spec and I'm
treating incoming packets based on that state. This will allow any
sequence of AVDTP_DISCOVER, AVDTP_GET_CAPABILITIES, AVDTP_OPEN, etc.
commands to occur and also makes it possible to have the server handle
more than one connection during its lifetime (only one at a time, of
course).

The code is currently completely lacking any error handling, and simply
ignores the offending packet (or exits), so that should be added. I also
don't like the structs used for the avdtp signalling packets, I think
there should only be one struct that includes a struct avdtp_header and
a union with all the other optional signalling contents. Then there
would have to be specialised read()/write() functions which figure out
(based on the header) how long the packet actually is and automatically
send/receive that many bytes. However, that would also require
modification of a2play so I thought I'd ask first.

That would make it easier to send rejection messages (which may differ
from the acceptance message in length) and do proper error handling.

> Why doesn't the streaming start?

If I only knew ...
The current code shows me that the stream connection is correctly
established and the start streaming response is sent. Then after some
seconds I get a read error on the command fd with error message
"Connection timed out". 

Again, please check that I didn't break your devices. I can only test
with a2play. There might also still be some flaws in the state handling
since this is slightly more complex than the original straight linear
design.

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-devel] Regarding a2recv

[Marcel Holtmann]

Hi Henryk,

> > Why doesn't the streaming start?
> 
> If I only knew ...
> The current code shows me that the stream connection is correctly
> established and the start streaming response is sent. Then after some
> seconds I get a read error on the command fd with error message
> "Connection timed out". 

I suspect that it is waiting for a role switch to happen.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Henryk Plötz]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

Moin,

Am Mon, 09 May 2005 02:01:36 +0200 schrieb Marcel Holtmann:

> I suspect that it is waiting for a role switch to happen.

Either that isn't it or I'm doing it wrong. There should be two
principal ways to archieve this, right? 

a) hciconfig hci0 lm master
If I do this I don't get a complete connection at all. hcidump shows
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:08:F4:35:05:3C role 0x00
    Role: Master
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Role Change (0x12) plen 8
> HCI Event: Connect Complete (0x03) plen 11
but nothing shows up on a2recv. 

b) (I got this from the bthid code)
getsockopt(fd, SOL_L2CAP, L2CAP_LM, &opt, &len)
opt |= L2CAP_LM_MASTER;
setsockopt(fd, SOL_L2CAP, L2CAP_LM, &opt, sizeof(opt))

I'm not sure on which fd I should apply this. If I do it on the streamfd
right after it has been established the behaviour is just as normal
(e.g. 6 second hang, then disconnect).

If I do it with the listening socket right in the beginning I get the
same as with hciconfig above. (I swear I got a "Role change not allowed"
message from kdebluetoothd somewhere in between, but I can't reproduce
that.)

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-devel] Regarding a2recv

[Marcel Holtmann]

Hi Henryk,

> Am Mon, 09 May 2005 02:01:36 +0200 schrieb Marcel Holtmann:
> 
> > I suspect that it is waiting for a role switch to happen.
> 
> Either that isn't it or I'm doing it wrong. There should be two
> principal ways to archieve this, right? 
> 
> a) hciconfig hci0 lm master
> If I do this I don't get a complete connection at all. hcidump shows
> > HCI Event: Connect Request (0x04) plen 10
> < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
>     bdaddr 00:08:F4:35:05:3C role 0x00
>     Role: Master
> > HCI Event: Command Status (0x0f) plen 4
> > HCI Event: Role Change (0x12) plen 8
> > HCI Event: Connect Complete (0x03) plen 11
> but nothing shows up on a2recv. 
> 
> b) (I got this from the bthid code)
> getsockopt(fd, SOL_L2CAP, L2CAP_LM, &opt, &len)
> opt |= L2CAP_LM_MASTER;
> setsockopt(fd, SOL_L2CAP, L2CAP_LM, &opt, sizeof(opt))
> 
> I'm not sure on which fd I should apply this. If I do it on the streamfd
> right after it has been established the behaviour is just as normal
> (e.g. 6 second hang, then disconnect).
> 
> If I do it with the listening socket right in the beginning I get the
> same as with hciconfig above. (I swear I got a "Role change not allowed"
> message from kdebluetoothd somewhere in between, but I can't reproduce
> that.)

you must do it on the HCI level at the correct time. Look at the
function hci_switch_role() for more details.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Henryk Plötz]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

Moin,

Am Mon, 09 May 2005 03:03:47 +0200 schrieb Marcel Holtmann:

> you must do it on the HCI level at the correct time. Look at the
> function hci_switch_role() for more details.

Ah, thanks, that does it. I copied and adapted the relevant code from
hcitool.c and it works like a charm. Problem is: When trying to do the
roleswitch the program can only run as root, which is not exactly what
I want. I committed it to cvs anyways, but it is #ifdef'd out. Compile
with -DROLESWITCH to use it.

This also gives nice insights as the audio dongle is not always sending
packets with the same size. They vary from 82 bytes to 634 (at least
that are the sizes I've seen up to now.)

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-devel] Regarding a2recv

[Marcel Holtmann]

Hi Henryk,

> > you must do it on the HCI level at the correct time. Look at the
> > function hci_switch_role() for more details.
> 
> Ah, thanks, that does it. I copied and adapted the relevant code from
> hcitool.c and it works like a charm. Problem is: When trying to do the
> roleswitch the program can only run as root, which is not exactly what
> I want. I committed it to cvs anyways, but it is #ifdef'd out. Compile
> with -DROLESWITCH to use it.

I know, but it is meant to be a root only command. Some time ago I had
the idea of adding an ioctl() to socket to change the role if no other
part of the HCI core objects. The same goes for the authentication and
the encryption mode. However I never did it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Brad Midgley]

Henryk

> I want. I committed it to cvs anyways, but it is #ifdef'd out. Compile
> with -DROLESWITCH to use it.

What do you think of making this code always compile in and run but 
report a warning and continue if the roleswitch call fails?

I think I understand now why the bluetake expects the headset to 
roleswitch. If the headset's radio can't have mixed slave/master 
connections open (scatternet?), then it needs the roleswitch in order to 
talk to a cellphone at the same time as the dongle. Is that right?

Brad


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Henryk Plötz]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

Moin,

Am Sun, 08 May 2005 22:29:26 -0600 schrieb Brad Midgley:

> What do you think of making this code always compile in and run but 
> report a warning and continue if the roleswitch call fails?

Would be fine with me. It's just that I wasn't sure whether a roleswitch
would break anything else.

> I think I understand now why the bluetake expects the headset to 
> roleswitch. If the headset's radio can't have mixed slave/master 
> connections open (scatternet?), then it needs the roleswitch in order
> to  talk to a cellphone at the same time as the dongle. Is that right?

Ah, thanks for clearing that up. I was wondering about that all the
time, and doubt that insisting on a roleswitch is something the spec
allows.

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-devel] Regarding a2recv

[Marcel Holtmann]

Hi Henryk,

> > I think I understand now why the bluetake expects the headset to 
> > roleswitch. If the headset's radio can't have mixed slave/master 
> > connections open (scatternet?), then it needs the roleswitch in order
> > to  talk to a cellphone at the same time as the dongle. Is that right?
> 
> Ah, thanks for clearing that up. I was wondering about that all the
> time, and doubt that insisting on a roleswitch is something the spec
> allows.

don't get me started on these things ;)

I have no idea how the current A2DP devices made it through the
qualification. If you check the record handles of the HP headphone than
you see that they are under 0x10000 and this is also violating the
specification. And the best example is the non-A2DP conform AVDTP
payload with 0xff 0xff of the Aiptek headphone.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Brad Midgley]

Henryk,

>>What do you think of making this code always compile in and run but 
>>report a warning and continue if the roleswitch call fails?
> 
> 
> Would be fine with me. It's just that I wasn't sure whether a roleswitch
> would break anything else.

Unless Marcel thinks it's a problem, I will make this the default 
behavior. We could provide a command-line switch to turn it off (or run 
it as non-root and the other end won't even notice you tried to switch :)

Brad


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Brad Midgley]

Henryk

> there should only be one struct that includes a struct avdtp_header and
> a union with all the other optional signalling contents. Then there
> would have to be specialised read()/write() functions which figure out
> (based on the header) how long the packet actually is and automatically
> send/receive that many bytes. However, that would also require
> modification of a2play so I thought I'd ask first.

I think this part sounds better, especially if Marcel thinks this is 
closer to what it will look like if/when it's "kernelized" :)

The only tricky part is the MAX_ADDITIONAL_CODEC stuff. Make sure we 
only try to send one codec when we're reporting our sink's capabilities 
and accept multiple codecs when we're reading capabilities.

Maybe what you're proposing will clean up the "optional" error codes in 
places like open_stream_rsp. The header would look different so you 
could distinguish the error codes and compute the size properly when 
sending. Be sure we accept the extended size with the error codes when 
receiving.

Brad


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Henryk Plötz]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

Moin,

Am Sun, 08 May 2005 22:29:40 -0600 schrieb Brad Midgley:

> The only tricky part is the MAX_ADDITIONAL_CODEC stuff. Make sure we 
> only try to send one codec when we're reporting our sink's
> capabilities  and accept multiple codecs when we're reading
> capabilities.

Ugh, yes. It would be possible to simple address infos[] beyond the
borders that are set by 1 + MAX_ADDITIONAL_CODEC if it is made sure that
there is that much space assigned. (If I recall correctly that's a
common technique to get varying length fields in structs.) However, from
the header it is not clear how many capabilities there will be, which is
something I don't like. We would have to resort to an all-zero seid_info
or something like that to denote the end of the packet (the read
function must than insert that, and the write function would have to
send up to that border).

> Maybe what you're proposing will clean up the "optional" error codes
> in places like open_stream_rsp. The header would look different so
> you could distinguish the error codes and compute the size properly
> when sending. 

That was exactly the idea.

> Be sure we accept the extended size with the error codes when
> receiving.

I'm not accustomed to bluetooth socket programming but I guess what I'm
doing currently (simply read() up to a maximum (mtu?) size, check the
returned size and optionally the header and cast the buffer to our
struct) is fine for that purpose.

-- 
Henryk Plötz
Grüße aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bluez-devel] Regarding a2recv

[Brad Midgley]

Henryk

> I'm not accustomed to bluetooth socket programming but I guess what I'm
> doing currently (simply read() up to a maximum (mtu?) size, check the
> returned size and optionally the header and cast the buffer to our
> struct) is fine for that purpose.

That's what I've been assuming too.

Brad


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Regarding a2recv

[Mayank Batra]

Henryk,

> I now completely restructured the a2recv code into
> something that more
> closely resembles a socket server application.
> Basically it is now a
> giant endless loop that is blocking in select() on
> the serverfd and
> optionally the cmdfd and streamfd (should they be
> open) and as soon as
> there is data to read or a connection to accept I am
> reading it.

Good job!

> There is also an internal state like that from the
> AVDTP spec and I'm
> treating incoming packets based on that state. This
> will allow any
> sequence of AVDTP_DISCOVER, AVDTP_GET_CAPABILITIES,
> AVDTP_OPEN, etc.
> commands to occur and also makes it possible to have
> the server handle
> more than one connection during its lifetime (only
> one at a time, of
> course).
> The code is currently completely lacking any error
> handling, and simply
> ignores the offending packet (or exits), so that
> should be added. I also
> don't like the structs used for the avdtp signalling
> packets, I think
> there should only be one struct that includes a
> struct avdtp_header and
> a union with all the other optional signalling
> contents. Then there
> would have to be specialised read()/write()
> functions which figure out
> (based on the header) how long the packet actually
> is and automatically
> send/receive that many bytes. However, that would
> also require
> modification of a2play so I thought I'd ask first.
> 
> That would make it easier to send rejection messages
> (which may differ
> from the acceptance message in length) and do proper
> error handling.

Even I tested a2recv with a2play and BlueSoleil.
It was working without much trouble, that is why I
didn't bother much about the error handling part.
What I needed at that time was a quick fix solution to
make an A2DP sink.

> 
> Again, please check that I didn't break your
> devices. I can only test
> with a2play. There might also still be some flaws in
> the state handling
> since this is slightly more complex than the
> original straight linear
> design.

Well, I haven't tested the restructured code yet. But
the one before this one was working fine.
 

Mayank

________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel