[Bluez-devel] Problem of data loss with a particular dongle brand

[Bluez-devel] Problem of data loss with a particular dongle brand

[Elvis Pfützenreuter]

[-- 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 --]

[Bluez-devel] Fwd: Problem of data loss with a particular dongle brand

[Elvis Pfützenreuter]

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

Sending again...

---------- Forwarded message ----------
From: Elvis Pfützenreuter <elvis.pfutzenreuter@gmail.com>
Date: 16/12/2005 15:13
Subject: Problem of data loss with a particular dongle brand
To: bluez-devel@lists.sourceforge.net


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: 1103 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: 838 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 --]

Re: [Bluez-devel] Problem of data loss with a particular dongle brand

[Marcel Holtmann]

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