linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Elvis Pfützenreuter" <elvis.pfutzenreuter@gmail.com>
To: bluez-devel@lists.sourceforge.net
Subject: [Bluez-devel] Problem of data loss with a particular dongle brand
Date: Fri, 16 Dec 2005 15:13:31 -0300	[thread overview]
Message-ID: <8c9e090512161013h6782f187k@mail.gmail.com> (raw)

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

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)

--
Elvis

[-- Attachment #2: server --]
[-- Type: application/octet-stream, Size: 1102 bytes --]

#!/usr/bin/python

import bluetooth
import md5
import random

ssk = bluetooth.BluetoothSocket( bluetooth.RFCOMM )
		
ssk.bind(("", 9))
ssk.listen(1)
# bluetooth.advertise_service( ssk, "Boo", provider="EPx", description="Test for Boo", profiles=[ bluetooth.SERIAL_PORT_PROFILE ], service_classes = [ bluetooth.SERIAL_PORT_CLASS ] )

f = open("/dev/urandom")

while 1:
	(sk, addr) = ssk.accept()
	exit = 0
	while not exit:
		buf = ""
		
		while buf.find("abracadabra") < 0:
			# print "Reading...", 
			nowbuf = sk.recv(4096)
			if not nowbuf:
				exit = 1
			# print "Received %d bytes " % len(nowbuf),
			buf += nowbuf
	
		print "RECV: Len = %d, MD5 = %s" % (len(buf), md5.new(buf).hexdigest())
		
		buf = ""
		lbuf = random.randint(8888,32000)
		while len(buf) < lbuf:
			buf += f.read(lbuf - len(buf))

		buf += "abracadabra"
		
		print "TO SEND: Len = %d, MD5 = %s" % (len(buf), md5.new(buf).hexdigest())

		while buf:
			# print "Sending... ",
			# xbuf = buf[0:500]
			xbuf = buf
			sent = sk.send(xbuf)
			# print "Sent %d bytes " % sent,
			buf = buf[sent:]

	print "Closing"
	sk.close()







[-- Attachment #3: client --]
[-- Type: application/octet-stream, Size: 837 bytes --]

#!/usr/bin/python

import bluetooth
import md5
import random
import time
import sys

sk = bluetooth.BluetoothSocket(bluetooth.RFCOMM)
sk.connect(("00:20:E0:CB:3C:44", 9))

f = open("/dev/urandom")

while 1:
	buf = ""
	lbuf = random.randint(8888,32000)
	while len(buf) < lbuf:
		buf += f.read(lbuf - len(buf))

	buf += "abracadabra"
	
	print "TO SEND: Len = %d, MD5 = %s" % (len(buf), md5.new(buf).hexdigest())

	while buf:
		# print "Sending... ",
		sent = sk.send(buf)
		# print "Sent %d bytes " % sent,
		buf = buf[sent:]

	print "Now receiving"

	buf = ""
	while buf.find("abracadabra") < 0:
		# print "Receiving... ",
		nowbuf = sk.recv(4096)
		if not nowbuf:
			sys.exit(0)
		# print "Received %d bytes " % len(nowbuf),
		buf += nowbuf

	print "RECV: Len = %d, MD5 = %s" % (len(buf), md5.new(buf).hexdigest())
	
	time.sleep(1)






[-- Attachment #4: log.client.badside.gz --]
[-- Type: application/x-gzip, Size: 155026 bytes --]

[-- Attachment #5: log.server.goodside.gz --]
[-- Type: application/x-gzip, Size: 204654 bytes --]

             reply	other threads:[~2005-12-16 18:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-16 18:13 Elvis Pfützenreuter [this message]
2006-01-19 17:19 ` [Bluez-devel] Fwd: Problem of data loss with a particular dongle brand Elvis Pfützenreuter
2006-01-20  1:47 ` [Bluez-devel] " Marcel Holtmann

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=8c9e090512161013h6782f187k@mail.gmail.com \
    --to=elvis.pfutzenreuter@gmail.com \
    --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).