Hi,
I try to setup openobex on my linux, but each time I send out obex
connect request, instead of getting a connect response, the device will
be reset, HCIDUMP is like below:
...
...
...
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 41 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 6 pf 1 ilen 0 fcs 0x18
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 6 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 0
> ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 6 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 0
< ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 6 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 0
> HCI Event: Number of Completed Packets (0x13) plen 5
> HCI Event: Number of Completed Packets (0x13) plen 5
> ACL data: handle 41 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 6 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 0
< ACL data: handle 41 flags 0x02 dlen 9
L2CAP(d): cid 0x0040 len 5 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 6 pf 1 ilen 0 fcs 0x93 credits 33
< ACL data: handle 41 flags 0x02 dlen 34
L2CAP(d): cid 0x0040 len 30 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 6 pf 0 ilen 26 fcs 0x8f
OBEX: Connect cmd(f): len 26 version 1.1 flags 0 mtu 1024
Target (0x46) = Sequence length 16
< HCI Command: Reset (0x03|0x0003) plen 0
The system I have is Linux 2.6.9-34, bluez-lib-2.25 and bluez-util-2.25,
bluez-hcidump-1.30, and openobex-1.0.1 version. I don't know who send
this reset, and why.
Thanks.
Lan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Andreas,
> further tests proofed that the problem described here are caused by
> the USB-hub used. It seems to be unable to handle the load and just
> breaks down. The same operations are working on other (higher quality) hubs.
>
> Watch out for lines like
>
> usb 1-1: USB disconnect, address 29
>
> in syslog and/or dmesg to check if your problem is similar. Make sure
> not to mess with real physical disconnects which produce the same log
> output.
does this also happens if you load the hci_usb driver with "isoc=0" to
disable all ISOC transfers.
> I guess the HCI_RESET is issued by bluez after the device comes back on.
This could be the case.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi,
further tests proofed that the problem described here are caused by
the USB-hub used. It seems to be unable to handle the load and just
breaks down. The same operations are working on other (higher quality) hubs.
Watch out for lines like
usb 1-1: USB disconnect, address 29
in syslog and/or dmesg to check if your problem is similar. Make sure
not to mess with real physical disconnects which produce the same log
output.
I guess the HCI_RESET is issued by bluez after the device comes back on.
Greetings
Andy
On Fri, 28 Jul 2006 13:39:33 +0200
Andreas Gaufer <[email protected]> wrote:
> Hi,
>
> I have evidence that this may be caused by the usb-part of these devices
> (B-Speech, Model: DataSpeed). Other devices (Level One, MDU-0025USB)
> don't show this problem on first sight. Both use BlueCore04, HCI 19.2.
>
> The tests where run using USB 2 Hub with 4 bt-devices pumping obex
> traffic at max possible speed and this Host Controller:
>
> 00:11.2 USB Controller: VIA Technologies, Inc. USB (rev 1e) (prog-if 00 [UHCI])
> Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
> Flags: bus master, medium devsel, latency 32, IRQ 12
> I/O ports at d400 [size=32]
> Capabilities: [80] Power Management version 2
>
> ## dmesg ##
> hub 1-1:1.0: port 2 disabled by hub (EMI?), re-enabling...
> usb 1-1.2: USB disconnect, address 31
> usb 1-1.2: new full speed USB device using address 34
> hub 1-1:1.0: port 3 disabled by hub (EMI?), re-enabling...
> usb 1-1.3: USB disconnect, address 32
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
> hub 1-1:1.0: cannot disable port 3 (err = -71)
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: cannot reset port 3 (err = -71)
> hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
> hub 1-1:1.0: cannot disable port 3 (err = -71)
> hub 1-1:1.0: cannot disable port 3 (err = -71)
> hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
> usb 1-1: USB disconnect, address 29
> usb 1-1.1: USB disconnect, address 30
> usb 1-1.2: USB disconnect, address 34
> usb 1-1.4: USB disconnect, address 33
> usb 1-1: new full speed USB device using address 37
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 4 ports detected
> usb 1-1.1: new full speed USB device using address 38
>
> Do you want one of these for your "nightmare chamber" marcel? ;)
>
> Lan, can you check your dmesg/syslog for usb related problems please.
>
> Greetings
>
> Andy
>
> On Fri, 28 Jul 2006 12:37:24 +0200
> Andreas Gaufer <[email protected]> wrote:
>
> > Hi,
> >
> > I guess I'm approaching the same or at least a related problem. I don't
> > feel like getting close the root of the problem yet but maybe the
> > attached output helps marcel or someone else to see clearer.
> >
> > I can't pretend that the reset in the attached log is not beeing sent from a
> > user-application but i felt like the oops is worth posting.
> >
> > Kernel used is 2.6.8.1 but i know that the thing happens also with 2.6.17.6.
> >
> > Hardware used:
> >
> > hci1: Type: USB
> > BD Address: 00:02:5B:00:BF:66 ACL MTU: 384:8 SCO MTU: 64:8
> > HCI 19.2
> > Chip version: BlueCore4-ROM
> > Max key size: 128 bit
> > SCO mapping: HCI
> > BD Address: 00:02:5B:00:BF:66 ACL MTU: 384:8 SCO MTU: 64:8
> > Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
> > <3-slot packets> <5-slot packets> <encryption> <slot offset>
> > <timing accuracy> <role switch> <hold mode> <sniff mode>
> > <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
> > <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
> > <power control> <transparent SCO> <broadcast encrypt>
> > <EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan>
> > <interlaced iscan> <interlaced pscan> <inquiry with RSSI>
> > <extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave>
> > <AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>
> > <AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps>
> > <EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features>
> >
> > I don't expect any feedback on this, I'll post in this thread if I find anything..
> >
> > Greetings
> >
> > Andy
> >
> >
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi,
I have evidence that this may be caused by the usb-part of these devices
(B-Speech, Model: DataSpeed). Other devices (Level One, MDU-0025USB)
don't show this problem on first sight. Both use BlueCore04, HCI 19.2.
The tests where run using USB 2 Hub with 4 bt-devices pumping obex
traffic at max possible speed and this Host Controller:
00:11.2 USB Controller: VIA Technologies, Inc. USB (rev 1e) (prog-if 00 [UH=
CI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 12
I/O ports at d400 [size=3D32]
Capabilities: [80] Power Management version 2
## dmesg ##
hub 1-1:1.0: port 2 disabled by hub (EMI?), re-enabling...
usb 1-1.2: USB disconnect, address 31
usb 1-1.2: new full speed USB device using address 34
hub 1-1:1.0: port 3 disabled by hub (EMI?), re-enabling...
usb 1-1.3: USB disconnect, address 32
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -71)
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: cannot reset port 3 (err =3D -71)
hub 1-1:1.0: Cannot enable port 3. Maybe the USB cable is bad?
hub 1-1:1.0: cannot disable port 3 (err =3D -71)
hub 1-1:1.0: cannot disable port 3 (err =3D -71)
hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 1-1: USB disconnect, address 29
usb 1-1.1: USB disconnect, address 30
usb 1-1.2: USB disconnect, address 34
usb 1-1.4: USB disconnect, address 33
usb 1-1: new full speed USB device using address 37
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.1: new full speed USB device using address 38
Do you want one of these for your "nightmare chamber" marcel? ;)
Lan, can you check your dmesg/syslog for usb related problems please.
Greetings
Andy
On Fri, 28 Jul 2006 12:37:24 +0200
Andreas Gaufer <[email protected]> wrote:
> Hi,
> =
> I guess I'm approaching the same or at least a related problem. I don't
> feel like getting close the root of the problem yet but maybe the
> attached output helps marcel or someone else to see clearer.
> =
> I can't pretend that the reset in the attached log is not beeing sent fro=
m a
> user-application but i felt like the oops is worth posting.
> =
> Kernel used is 2.6.8.1 but i know that the thing happens also with 2.6.17=
.6.
> =
> Hardware used:
> =
> hci1: Type: USB
> BD Address: 00:02:5B:00:BF:66 ACL MTU: 384:8 SCO MTU: 64:8
> HCI 19.2
> Chip version: BlueCore4-ROM
> Max key size: 128 bit
> SCO mapping: HCI
> BD Address: 00:02:5B:00:BF:66 ACL MTU: 384:8 SCO MTU: 64:8
> Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
> <3-slot packets> <5-slot packets> <encryption> <slot offs=
et> =
> <timing accuracy> <role switch> <hold mode> <sniff mode> =
> <park state> <RSSI> <channel quality> <SCO link> <HV2 pac=
kets> =
> <HV3 packets> <u-law log> <A-law log> <CVSD> <paging sche=
me> =
> <power control> <transparent SCO> <broadcast encrypt> =
> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan> =
> <interlaced iscan> <interlaced pscan> <inquiry with RSSI> =
> <extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slav=
e> =
> <AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL> =
> <AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps> =
> <EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features> =
> =
> I don't expect any feedback on this, I'll post in this thread if I find a=
nything..
> =
> Greetings
> =
> Andy
> =
> =
-- =
mit freundlichen Gr=FC=DFen / best regards,
Andreas Gaufer
Office: +49 951-700428-91
Fax: +49 951-700428-87
Mail: [email protected]
I fully agree with RFC 1855
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Lan,
> I try to setup openobex on my linux, but each time I send out obex
> connect request, instead of getting a connect response, the device will
> be reset, HCIDUMP is like below:
>
> ...
> ...
> ...
> > HCI Event: Number of Completed Packets (0x13) plen 5
> > ACL data: handle 41 flags 0x02 dlen 8
> L2CAP(d): cid 0x0040 len 4 [psm 3]
> RFCOMM(s): UA: cr 1 dlci 6 pf 1 ilen 0 fcs 0x18
> < ACL data: handle 41 flags 0x02 dlen 12
> L2CAP(d): cid 0x0040 len 8 [psm 3]
> RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
> dlci 6 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 0
> > ACL data: handle 41 flags 0x02 dlen 12
> L2CAP(d): cid 0x0040 len 8 [psm 3]
> RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
> dlci 6 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 0
> < ACL data: handle 41 flags 0x02 dlen 12
> L2CAP(d): cid 0x0040 len 8 [psm 3]
> RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
> dlci 6 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 0
> > HCI Event: Number of Completed Packets (0x13) plen 5
> > HCI Event: Number of Completed Packets (0x13) plen 5
> > ACL data: handle 41 flags 0x02 dlen 12
> L2CAP(d): cid 0x0040 len 8 [psm 3]
> RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
> dlci 6 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 0 b3 0 len 0
> < ACL data: handle 41 flags 0x02 dlen 9
> L2CAP(d): cid 0x0040 len 5 [psm 3]
> RFCOMM(d): UIH: cr 1 dlci 6 pf 1 ilen 0 fcs 0x93 credits 33
> < ACL data: handle 41 flags 0x02 dlen 34
> L2CAP(d): cid 0x0040 len 30 [psm 3]
> RFCOMM(d): UIH: cr 1 dlci 6 pf 0 ilen 26 fcs 0x8f
> OBEX: Connect cmd(f): len 26 version 1.1 flags 0 mtu 1024
> Target (0x46) = Sequence length 16
> < HCI Command: Reset (0x03|0x0003) plen 0
>
> The system I have is Linux 2.6.9-34, bluez-lib-2.25 and bluez-util-2.25,
> bluez-hcidump-1.30, and openobex-1.0.1 version. I don't know who send
> this reset, and why.
the reset is really strange. It comes from our side. What does
"hciconfig -a" say about your dongle.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Andreas,
> > > further tests proofed that the problem described here are caused by
> > > the USB-hub used. It seems to be unable to handle the load and just
> > > breaks down. The same operations are working on other (higher quality) hubs.
> > >
> > > Watch out for lines like
> > >
> > > usb 1-1: USB disconnect, address 29
> > >
> > > in syslog and/or dmesg to check if your problem is similar. Make sure
> > > not to mess with real physical disconnects which produce the same log
> > > output.
> >
> > does this also happens if you load the hci_usb driver with "isoc=0" to
> > disable all ISOC transfers.
> >
>
> Confuses me a bit... my kernel (2.6.8.1) says: kernel: hci_usb: Unknown parameter `isoc'
> my modinfo -p hci_usb says: "nothing".
this is a fairly old kernel. This also means that this can be a bug in
the USB subsystem. Move to the latest 2.6.17 or even 2.6.18-rc3 kernel.
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Mon, 31 Jul 2006 20:19:40 +0200
Marcel Holtmann <[email protected]> wrote:
> Hi Andreas,
Hi Marcel,
>
> > further tests proofed that the problem described here are caused by
> > the USB-hub used. It seems to be unable to handle the load and just
> > breaks down. The same operations are working on other (higher quality) hubs.
> >
> > Watch out for lines like
> >
> > usb 1-1: USB disconnect, address 29
> >
> > in syslog and/or dmesg to check if your problem is similar. Make sure
> > not to mess with real physical disconnects which produce the same log
> > output.
>
> does this also happens if you load the hci_usb driver with "isoc=0" to
> disable all ISOC transfers.
>
Confuses me a bit... my kernel (2.6.8.1) says: kernel: hci_usb: Unknown parameter `isoc'
my modinfo -p hci_usb says: "nothing".
> > I guess the HCI_RESET is issued by bluez after the device comes back on.
>
> This could be the case.
>
> Regards
>
> Marcel
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users