From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] Problem of data loss with a particular dongle brand
Date: Fri, 20 Jan 2006 02:47:54 +0100 [thread overview]
Message-ID: <1137721674.17336.151.camel@localhost> (raw)
In-Reply-To: <8c9e090512161013h6782f187k@mail.gmail.com>
Hi Elvis,
unfortunately the original messages did make it to the list.
> I suffered a problem with data loss in RFCOMM connections, but I
> managed to discover that it just happens when a cheapo dongle I have
> is in the *receiving* side. I have 2 exactly equal dongles and both
> cause the same problem.
>
> It happens when the sender sends a big buffer at once (> 1500 bytes).
> If the server makes repeated cals to send() with around 500 bytes
> each, the problem does not happen. Perhaps the hardware is flawed
> and/or perhaps Bluez is not handling this dongle correctly.
> When both sides are "good" BT interfaces, (either Bluez or
> smartphone), problem does not happen also.
>
> I am attaching the hcidump -X sessions of communication with the
> problem (bad dongle and good BT interface sides), as well the Python
> scripts that are my guinea pigs for these tests.
>
> root@dosmtc17:/bkpz # hciconfig -a
> hci0: Type: USB
> BD Address: 00:11:67:04:D2:32 ACL MTU: 678:8 SCO MTU: 48:10
> UP RUNNING PSCAN ISCAN
> RX bytes:3610 acl:17 sco:0 events:190 errors:0
> TX bytes:59930 acl:129 sco:0 commands:25 errors:0
> Features: 0xff 0xff 0x8d 0x78 0x08 0x18 0x00 0x00
> Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
> Link policy: RSWITCH HOLD SNIFF PARK
> Link mode: SLAVE ACCEPT
> Name: 'dosmtc17-0'
> Class: 0x100100
> Service Classes: Object Transfer
> Device Class: Computer, Uncategorized
> HCI Ver: 1.2 (0x2) HCI Rev: 0x1ae LMP Ver: 1.2 (0x2) LMP Subver: 0x1ae
> Manufacturer: Integrated System Solution Corp. (57)
I actually never really found the reason why the ISSC dongles are so
damn crappy. Maybe their USB interface is broken. Try to load the
hci_usb driver with isoc=0 to disable the SCO support and its ISOC
transfers.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
prev parent reply other threads:[~2006-01-20 1:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-16 18:13 [Bluez-devel] Problem of data loss with a particular dongle brand Elvis Pfützenreuter
2006-01-19 17:19 ` [Bluez-devel] Fwd: " Elvis Pfützenreuter
2006-01-20 1:47 ` Marcel Holtmann [this message]
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=1137721674.17336.151.camel@localhost \
--to=marcel@holtmann.org \
--cc=bluez-devel@lists.sourceforge.net \
/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;
as well as URLs for NNTP newsgroup(s).