Hi Folks,
I don't wanna make big words about it, but after 8 months there are new
releases of the BlueZ libs and utils packages. So let the changelogs
speak for themselfs:
BlueZ libs 2.5:
Add decoding of Bluetooth 1.2 features.
Add link manager version parameter for Bluetooth 1.2.
Add new company identifiers.
Support for transmit power level.
Support for park, sniff and hold mode.
Support for role switch.
Support for reading the clock offset.
Use R1 for default value of pscan_rep_mode.
BlueZ utils 2.4:
hcitool changes:
Increase number of inquiry responses.
Support for transmit power level.
Minor updates.
hciconfig changes:
Display all 8 bytes of the features.
Add support for reading and writing of IAC.
Correct decoding class of device.
Use Ericsson revision command for ST Microelectronics devices.
Display AVM firmware version with 'revision' command.
New code for CSR specific revision information.
hciattach changes:
Support for ST Microelectronics specific initialization.
Support for 3Com card version 3.0.
Support for TDK, IBM and Socket cards.
Support for initial baud rate.
Update man pages.
Fixes for some memory leaks.
For the BlueZ libs I don't plan another release, because the new major
version of the Bluetooth library is making good progress. But for the
BlueZ Utils I want to make another release that addresses the problems
with the pin_helper program. I think the C based bluez-pin is a good
idea and maybe we should also integrate the DBus support into the next
release. So I like to get comments on this and if you have patches,
please resend them.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Charles,
> I will happily write a script that create daily or weekly snapshots
> and provide them on my page if it would help to get it into your company.
if you want to do Michal a favour, tar the current CVS and send it to
him via email.
> Or would it be easier if I call them "beta-something" ? :-)
No, we are not in beta testing stage.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Fri, 2003-12-19 at 11:22, Michal Semler (volny.cz) wrote:
> Dne p=E1tek 19 prosinec 2003 10:19 jste napsal(a):
> > Hi Michal,
> >
> > > GREAT work Marcel! :)
> >
> > thanks, but it was not alone my work.
> >
> > > Now we want release of HID support for keyboards and mouses etc :)
> >
> > you already know my answer to this. The official HID support will com=
e
> > with the release of the new Bluetooth library. However nobody said th=
at
> > the CVS code is not usable. I posted some comments on how to install =
and
> > use this new stuff without breaking your current setup. And Charles p=
ut
> > together a small online HOWTO on installing the CVS version
> >
> > http://www.bueche.ch/comp/mx900/mx900.html
>=20
> I looked at that site a day before :)
> But in our company we can't use CVS versions - company's politics :(
> So I would be very satified with some beta version :) released to direc=
t=20
> download
I will happily write a script that create daily or weekly snapshots=20
and provide them on my page if it would help to get it into your company.=
=20
Or would it be easier if I call them "beta-something" ? :-)
It's reminding me a CEO decision a few years back, with a policy=20
like "all Opensource products must be shutdown immediately". We followed=20
the rules and stopped an internal BIND and the internal apache Web server=
immediately.
No need to tell you we had a fun time watching them running around. The
policy was then fixed in very short time :-)
Charles
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Dne p=E1tek 19 prosinec 2003 10:19 jste napsal(a):
> Hi Michal,
>
> > GREAT work Marcel! :)
>
> thanks, but it was not alone my work.
>
> > Now we want release of HID support for keyboards and mouses etc :)
>
> you already know my answer to this. The official HID support will come
> with the release of the new Bluetooth library. However nobody said that
> the CVS code is not usable. I posted some comments on how to install and
> use this new stuff without breaking your current setup. And Charles put
> together a small online HOWTO on installing the CVS version
>
> http://www.bueche.ch/comp/mx900/mx900.html
I looked at that site a day before :)
But in our company we can't use CVS versions - company's politics :(
So I would be very satified with some beta version :) released to direct=20
download
M.
>
> Regards
>
> Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Marcel,
The corresponding RPM packages are now there too.
Cheers,
Steve
On Thu, 2003-12-18 at 23:55, Marcel Holtmann wrote:
> Hi Folks,
>
> I don't wanna make big words about it, but after 8 months there are new
> releases of the BlueZ libs and utils packages. So let the changelogs
> speak for themselfs:
>
> BlueZ libs 2.5:
> Add decoding of Bluetooth 1.2 features.
> Add link manager version parameter for Bluetooth 1.2.
> Add new company identifiers.
> Support for transmit power level.
> Support for park, sniff and hold mode.
> Support for role switch.
> Support for reading the clock offset.
> Use R1 for default value of pscan_rep_mode.
>
> BlueZ utils 2.4:
> hcitool changes:
> Increase number of inquiry responses.
> Support for transmit power level.
> Minor updates.
> hciconfig changes:
> Display all 8 bytes of the features.
> Add support for reading and writing of IAC.
> Correct decoding class of device.
> Use Ericsson revision command for ST Microelectronics devices.
> Display AVM firmware version with 'revision' command.
> New code for CSR specific revision information.
> hciattach changes:
> Support for ST Microelectronics specific initialization.
> Support for 3Com card version 3.0.
> Support for TDK, IBM and Socket cards.
> Support for initial baud rate.
> Update man pages.
> Fixes for some memory leaks.
>
> For the BlueZ libs I don't plan another release, because the new major
> version of the Bluetooth library is making good progress. But for the
> BlueZ Utils I want to make another release that addresses the problems
> with the pin_helper program. I think the C based bluez-pin is a good
> idea and maybe we should also integrate the DBus support into the next
> release. So I like to get comments on this and if you have patches,
> please resend them.
>
> Regards
>
> Marcel
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
Hi Michal,
> GREAT work Marcel! :)
thanks, but it was not alone my work.
> Now we want release of HID support for keyboards and mouses etc :)
you already know my answer to this. The official HID support will come
with the release of the new Bluetooth library. However nobody said that
the CVS code is not usable. I posted some comments on how to install and
use this new stuff without breaking your current setup. And Charles put
together a small online HOWTO on installing the CVS version
http://www.bueche.ch/comp/mx900/mx900.html
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
GREAT work Marcel! :)
Now we want release of HID support for keyboards and mouses etc :)
Michal
Dne p=E1tek 19 prosinec 2003 00:55 Marcel Holtmann napsal(a):
> Hi Folks,
>
> I don't wanna make big words about it, but after 8 months there are new
> releases of the BlueZ libs and utils packages. So let the changelogs
> speak for themselfs:
>
> BlueZ libs 2.5:
> Add decoding of Bluetooth 1.2 features.
> Add link manager version parameter for Bluetooth 1.2.
> Add new company identifiers.
> Support for transmit power level.
> Support for park, sniff and hold mode.
> Support for role switch.
> Support for reading the clock offset.
> Use R1 for default value of pscan_rep_mode.
>
> BlueZ utils 2.4:
> hcitool changes:
> Increase number of inquiry responses.
> Support for transmit power level.
> Minor updates.
> hciconfig changes:
> Display all 8 bytes of the features.
> Add support for reading and writing of IAC.
> Correct decoding class of device.
> Use Ericsson revision command for ST Microelectronics
> devices. Display AVM firmware version with 'revision' command. New code f=
or
> CSR specific revision information.
> hciattach changes:
> Support for ST Microelectronics specific initialization.
> Support for 3Com card version 3.0.
> Support for TDK, IBM and Socket cards.
> Support for initial baud rate.
> Update man pages.
> Fixes for some memory leaks.
>
> For the BlueZ libs I don't plan another release, because the new major
> version of the Bluetooth library is making good progress. But for the
> BlueZ Utils I want to make another release that addresses the problems
> with the pin_helper program. I think the C based bluez-pin is a good
> idea and maybe we should also integrate the DBus support into the next
> release. So I like to get comments on this and if you have patches,
> please resend them.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Tue, 2004-01-06 at 14:15, Marcel Holtmann wrote:
> > Maybe the P800's just gone crazy :( Oh well.
>
> I don't think so, because if the ACL link is still connected we should
> answer the SABM command. Looks for me like a scheduling bug in our
> implementation. You got this with 2.4.23-mh1 and 2.6.0-mh2, right? I
> think I had some similar problem, but I can't remember where I got it or
> how to reproduce it.
Yes, I had it with both kernels. (Though my testing with 2.6 is
somewhat limited due to the lockup problem I was getting.)
> BTW is the P800 so stupid that it searches for the SP record, but
> connects back to channel 1. To what channel do you connect on the P800
> to trigger the callback.
Well, no, this all used to work. It seems odd that it happens to me and
nobody else. I trigger it by connecting to whichever channel the P800
runs SP on. At the moment that's channel 2, though it does shift around
sometimes.
Though in this case it does connect back to channel 1 it refuses to do
the PPP dance with it, so I'm unsure what's going on there. It just
hangs up after a whle.
And now, it has just worked properly for the first time in days! And
now it seems to be working about 50% of the time.
Thanks for your help, Marcel.
-- Edd
Hi Edd,
> > maybe the P800 is buggy. Run a second dund on channel 1 to see if it
> > connects.
>
> Well, that worked once or twice! Now we're back to the problem of
> being stalled at this stage...
>
> > ACL data: handle 0x0029 flags 0x02 dlen 18
> L2CAP(s): Config rsp: scid 0x0041 flags 0x0000 result 0 clen 4
> MTU 672
> > ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x41 len 4 [psm 3]
> RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
>
> Maybe the P800's just gone crazy :( Oh well.
I don't think so, because if the ACL link is still connected we should
answer the SABM command. Looks for me like a scheduling bug in our
implementation. You got this with 2.4.23-mh1 and 2.6.0-mh2, right? I
think I had some similar problem, but I can't remember where I got it or
how to reproduce it.
BTW is the P800 so stupid that it searches for the SP record, but
connects back to channel 1. To what channel do you connect on the P800
to trigger the callback.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
> On Tue, 2004-01-06 at 13:20, Marcel Holtmann wrote:
> > maybe the P800 is buggy. Run a second dund on channel 1 to see if it
> > connects.
>
> Well, that worked once or twice! Now we're back to the problem of
> being stalled at this stage...
>
> > ACL data: handle 0x0029 flags 0x02 dlen 18
> L2CAP(s): Config rsp: scid 0x0041 flags 0x0000 result 0 clen 4
> MTU 672
> > ACL data: handle 0x0029 flags 0x02 dlen 8
> L2CAP(d): cid 0x41 len 4 [psm 3]
> RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
>
> Maybe the P800's just gone crazy :( Oh well.
The UA which should be sent in response to this SABM command doesn't get
sent. I don't know why but this has nothing to do with your phone. the SABM
cmd looks ok...
Regards,
--
Xavier Garreau <[email protected]>
Prim'Time Technology
http://www.prim-time.fr/
On Tue, 2004-01-06 at 13:20, Marcel Holtmann wrote:
> maybe the P800 is buggy. Run a second dund on channel 1 to see if it
> connects.
Well, that worked once or twice! Now we're back to the problem of
being stalled at this stage...
> ACL data: handle 0x0029 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x0000 result 0 clen 4
MTU 672
> ACL data: handle 0x0029 flags 0x02 dlen 8
L2CAP(d): cid 0x41 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
Maybe the P800's just gone crazy :( Oh well.
-- Edd
Hi Edd,
> > this only happens when rfcomm_connect_ind() returns false and this means
> > that we can't create the new socket. In most cases this is because there
> > is no listen socket for it. Do /proc/bluetooth/rfcomm show the listen
> > socket on that channel? Do you use the same channel number in your SDP
> > record as for dund?
>
> sdptool browse ff:ff:ff ....
>
> Service Name: Serial Port
> Service RecHandle: 0x804ee30
> Service Class ID List:
> "Serial Port" (0x1101)
> Protocol Descriptor List:
> "L2CAP" (0x0100)
> "RFCOMM" (0x0003)
> Channel: 3
> Profile Descriptor List:
> "Serial Port" (0x1101)
> Version: 0x0100
>
>
> strace dund --listen --persist --channel 3 --nodetach
maybe the P800 is buggy. Run a second dund on channel 1 to see if it
connects.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Tue, 2004-01-06 at 12:37, Marcel Holtmann wrote:
> this only happens when rfcomm_connect_ind() returns false and this means
> that we can't create the new socket. In most cases this is because there
> is no listen socket for it. Do /proc/bluetooth/rfcomm show the listen
> socket on that channel? Do you use the same channel number in your SDP
> record as for dund?
sdptool browse ff:ff:ff ....
Service Name: Serial Port
Service RecHandle: 0x804ee30
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
Profile Descriptor List:
"Serial Port" (0x1101)
Version: 0x0100
strace dund --listen --persist --channel 3 --nodetach
socket(0x1f /* PF_??? */, SOCK_STREAM, 3) = 5
bind(5, {sa_family=0x1f /* AF_??? */,
sa_data="\0\0\0\0\0\0\3\243\20@\6\0\0\0"}, 10) = 0
listen(5, 10) = 0
accept(5,
cat /proc/bluetooth/rfcomm
sk 00:00:00:00:00:00 00:00:00:00:00:00 4 3
sk 69:DD:D0:05:40:00 6D:15:24:98:80:00 9 4
Lastly, BlueZ<->BlueZ seems to work fine. And OBEX from the P800 to BlueZ
works. It's weird.
-- Edd
Here's another hcidump, which shows the SDP response...
> HCI Event: Connect Request(0x04) plen 10
< HCI Command: Accept Connection Request(0x01|0x0009) plen 7
> HCI Event: Command Status(0x0f) plen 4
> HCI Event: Connect Complete(0x03) plen 11
< HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4
> HCI Event: Command Complete(0x0e) plen 6
< HCI Command: Change Connection Packet Type(0x01|0x000f) plen 4
> HCI Event: Command Status(0x0f) plen 4
> HCI Event: Connection Packet Type Changed(0x1d) plen 5
> ACL data: handle 0x0028 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0061
< ACL data: handle 0x0028 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0061 result 0 status 0
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0028 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 0
< ACL data: handle 0x0028 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0061 flags 0x0000 result 0 clen 0
< ACL data: handle 0x0028 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0061 flags 0x0000 clen 0
> HCI Event: Number of Completed Packets(0x13) plen 5
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0028 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x0000 result 0 clen 0
> ACL data: handle 0x0028 flags 0x02 dlen 17
L2CAP(d): cid 0x40 len 13 [psm 1]
SDP SS Req: tid 0x1 len 0x8
pat uuid-16 0x1101 (SP)
max 0x14
cont 00
< ACL data: handle 0x0028 flags 0x02 dlen 18
L2CAP(d): cid 0x61 len 14 [psm 1]
SDP SS Rsp: tid 0x1 len 0x9
cur 0x1 tot 0x1 hndl 0x804d838
cont 00
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0028 flags 0x02 dlen 21
L2CAP(d): cid 0x40 len 17 [psm 1]
SDP SA Req: tid 0x2 len 0xc
hndl 0x804d838
max 0xc8
aid(s) 0x0001 (SrvClassIDList)
cont 00
< ACL data: handle 0x0028 flags 0x02 dlen 22
L2CAP(d): cid 0x61 len 18 [psm 1]
SDP SA Rsp: tid 0x2 len 0xd
cnt 0xa
aid 0x0001 (SrvClassIDList)
uuid-16 0x1101 (SP)
cont 00
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0028 flags 0x02 dlen 21
L2CAP(d): cid 0x40 len 17 [psm 1]
SDP SA Req: tid 0x3 len 0xc
hndl 0x804d838
max 0xc8
aid(s) 0x0004 (ProtocolDescList)
cont 00
> HCI Event: Max Slots Change(0x1b) plen 3
< ACL data: handle 0x0028 flags 0x02 dlen 31
L2CAP(d): cid 0x61 len 27 [psm 1]
SDP SA Rsp: tid 0x3 len 0x16
cnt 0x13
aid 0x0004 (ProtocolDescList)
uuid-16 0x0100 (L2CAP)
uuid-16 0x0003 (RFCOMM) uint 0x3
cont 00
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0028 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0062
< ACL data: handle 0x0028 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0062 result 0 status 0
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0028 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0041 flags 0x0000 clen 0
< ACL data: handle 0x0028 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0062 flags 0x0000 result 0 clen 0
< ACL data: handle 0x0028 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0062 flags 0x0000 clen 4
MTU 1024
> HCI Event: Number of Completed Packets(0x13) plen 5
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0028 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x0000 result 0 clen 4
MTU 672
> ACL data: handle 0x0028 flags 0x02 dlen 8
L2CAP(d): cid 0x41 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> ACL data: handle 0x0028 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x0062
< ACL data: handle 0x0028 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0062
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0028 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0061
< ACL data: handle 0x0028 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0061
> HCI Event: Number of Completed Packets(0x13) plen 5
> HCI Event: Disconn Complete(0x05) plen 4
Hi Xavier,
> You said dund was running on channel 3, which is the same as dlci 6 as =
the
> P800 get the Direction bit set to 1, being the session initiator (BT sp=
ec.
> =A75.4). The SE P800 is aking for a connection on dlci 2 which is refus=
ed, of
> course.
>=20
> Am I right RFCOMM gurus ?
yes, this is correct. The channel numbers of the SDP record and dund
must match.
Do anyone have an old Symbian Bluetooth phone (Nokia 7650, 3650, Sony
Ericsson P800, P900) for me so I can implement the mRouter stuff to get
rid of these stupid setups?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
> > > > ACL data: handle 0x002a flags 0x02 dlen 8
> > > L2CAP(d): cid 0x41 len 4 [psm 3]
> > > RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> > > < ACL data: handle 0x002a flags 0x02 dlen 8
> > > L2CAP(d): cid 0x169 len 4 [psm 3]
> > > RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> > > > HCI Event: Number of Completed Packets(0x13) plen 5
> > > > ACL data: handle 0x002a flags 0x02 dlen 18
> > > L2CAP(d): cid 0x41 len 14 [psm 3]
> > > RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len =
8
> > > dlci 2 frame_type 0 credit_flow 15 pri 0 ack_timer 0 frame_si=
ze
> > > 667 max_retrans 0 credits 3
> > > < ACL data: handle 0x002a flags 0x02 dlen 8
> > > L2CAP(d): cid 0x169 len 4 [psm 3]
> > > RFCOMM(s): DM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x73
Hi,
You said dund was running on channel 3, which is the same as dlci 6 as th=
e
P800 get the Direction bit set to 1, being the session initiator (BT spec=
.
=A75.4). The SE P800 is aking for a connection on dlci 2 which is refused=
, of
course.
Am I right RFCOMM gurus ?
Regards,
--=20
Xavier Garreau <[email protected]>
Prim'Time Technology
http://www.prim-time.fr/
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Edd,
> > > > ACL data: handle 0x002a flags 0x02 dlen 18
> > > L2CAP(d): cid 0x41 len 14 [psm 3]
> > > RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
> > > dlci 2 frame_type 0 credit_flow 15 pri 0 ack_timer 0 frame_size
> > > 667 max_retrans 0 credits 3
> > > < ACL data: handle 0x002a flags 0x02 dlen 8
> > > L2CAP(d): cid 0x169 len 4 [psm 3]
> > > RFCOMM(s): DM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x73
> >
> > how long is the time between these two packets?
>
> no perceptible delay between these two.
this only happens when rfcomm_connect_ind() returns false and this means
that we can't create the new socket. In most cases this is because there
is no listen socket for it. Do /proc/bluetooth/rfcomm show the listen
socket on that channel? Do you use the same channel number in your SDP
record as for dund?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Sun, 2004-01-04 at 10:38, Marcel Holtmann wrote:
> Hi Edd,
>
> > No, I've not tried BlueZ<->BlueZ, it happened with my SE P800 connecting
> > back to BlueZ.
> >
> > Occasionally it gets a bit further, then hangs:
> >
> > > ACL data: handle 0x002a flags 0x02 dlen 8
> > L2CAP(d): cid 0x41 len 4 [psm 3]
> > RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> > < ACL data: handle 0x002a flags 0x02 dlen 8
> > L2CAP(d): cid 0x169 len 4 [psm 3]
> > RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> > > HCI Event: Number of Completed Packets(0x13) plen 5
> > > ACL data: handle 0x002a flags 0x02 dlen 18
> > L2CAP(d): cid 0x41 len 14 [psm 3]
> > RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
> > dlci 2 frame_type 0 credit_flow 15 pri 0 ack_timer 0 frame_size
> > 667 max_retrans 0 credits 3
> > < ACL data: handle 0x002a flags 0x02 dlen 8
> > L2CAP(d): cid 0x169 len 4 [psm 3]
> > RFCOMM(s): DM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x73
>
> how long is the time between these two packets?
no perceptible delay between these two.
> Is there really a
> listening socket for this channel?
strace shows dund running accept() on the socket, so I guess so.
-- Edd
Hi Edd,
> No, I've not tried BlueZ<->BlueZ, it happened with my SE P800 connecting
> back to BlueZ.
>
> Occasionally it gets a bit further, then hangs:
>
> > ACL data: handle 0x002a flags 0x02 dlen 8
> L2CAP(d): cid 0x41 len 4 [psm 3]
> RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> < ACL data: handle 0x002a flags 0x02 dlen 8
> L2CAP(d): cid 0x169 len 4 [psm 3]
> RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> > HCI Event: Number of Completed Packets(0x13) plen 5
> > ACL data: handle 0x002a flags 0x02 dlen 18
> L2CAP(d): cid 0x41 len 14 [psm 3]
> RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
> dlci 2 frame_type 0 credit_flow 15 pri 0 ack_timer 0 frame_size
> 667 max_retrans 0 credits 3
> < ACL data: handle 0x002a flags 0x02 dlen 8
> L2CAP(d): cid 0x169 len 4 [psm 3]
> RFCOMM(s): DM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x73
how long is the time between these two packets? Is there really a
listening socket for this channel?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Michal,
> > this is more problematic than you think. The general problem is money of
> > course, because a qualification is expensive.
>
> Hmmmm when there was man telling us about BT on our uni, he told us, that
> qualification is free???? Are you really sure with payments???
there is at minimum the listing fee of 7500 $ and you have to pay a BQB
to run the needed tests.
> > the biggest problem is that I don't have access to protocol and profile
> > testers. We have to know what tests fail and what we pass. If we know
> > how to run these test the whole qualification process can be done by
> > everyone.
>
> Where can be RFCs of tests taken? Only in Ericsson?
For example with a Rhode & Schwarz PTW60 or the BITE from Cetecom. In
some cases the Tracer/Trainer from CATC would be enough to be sure that
our implementation passes the qualification tests.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Dne sobota 03 leden 2004 00:35 Marcel Holtmann napsal(a):
> Hi Michal,
>
> > > I am no expert for this, but my understanding is that we can't use the
> > > Bluetooth logo until the stack got its qualification. I think the best
> > > way is to replace this logo. Maybe we should start an official BlueZ
> > > logo contest.
> >
> > Hmmm and why not to get it to qualificate? I think it's free and without
> > payment?
>
> this is more problematic than you think. The general problem is money of
> course, because a qualification is expensive.
Hmmmm when there was man telling us about BT on our uni, he told us, that
qualification is free???? Are you really sure with payments???
But from my point of view
> the biggest problem is that I don't have access to protocol and profile
> testers. We have to know what tests fail and what we pass. If we know
> how to run these test the whole qualification process can be done by
> everyone.
Where can be RFCs of tests taken? Only in Ericsson?
Michal
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Sat, 2004-01-03 at 17:10, Marcel Holtmann wrote:
> this can never be a libs problem, because L2CAP and RFCOMM are only
> kernel related. However having this problem is somekind odd. Do it only
> happens on BlueZ <-> BlueZ connections?
No, I've not tried BlueZ<->BlueZ, it happened with my SE P800 connecting
back to BlueZ.
Occasionally it gets a bit further, then hangs:
> ACL data: handle 0x002a flags 0x02 dlen 8
L2CAP(d): cid 0x41 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 0x002a flags 0x02 dlen 8
L2CAP(d): cid 0x169 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x002a flags 0x02 dlen 18
L2CAP(d): cid 0x41 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
dlci 2 frame_type 0 credit_flow 15 pri 0 ack_timer 0 frame_size
667 max_retrans 0 credits 3
< ACL data: handle 0x002a flags 0x02 dlen 8
L2CAP(d): cid 0x169 len 4 [psm 3]
RFCOMM(s): DM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x73
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x002a flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x0169
< ACL data: handle 0x002a flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0169
> HCI Event: Number of Completed Packets(0x13) plen 5
-- Edd
Hi Edd,
> > I have a problem that I believe is caused by the new libs.
>
> Agh, I suck. On a different machine it happens whatever libs I have
> (2.4.23-mh1). Sorry for the conflicting error reports. But I still
> have the difficulty. :( Maybe extra cosmic rays are bombarding my house
> this weekend.
this can never be a libs problem, because L2CAP and RFCOMM are only
kernel related. However having this problem is somekind odd. Do it only
happens on BlueZ <-> BlueZ connections?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Sat, 2004-01-03 at 16:32, Edd Dumbill wrote:
> I have a problem that I believe is caused by the new libs.
Agh, I suck. On a different machine it happens whatever libs I have
(2.4.23-mh1). Sorry for the conflicting error reports. But I still
have the difficulty. :( Maybe extra cosmic rays are bombarding my house
this weekend.
-- Edd
I have a problem that I believe is caused by the new libs.
Here's what happens: I contact the P800's bluetooth serial port as usual
and look for it connecting back to dund (yes, I have the SP record).
Unfortunately dund never gets to hear from it. dund's running on
channel 3.
Reverting the libs seemed to fix this (was running linux/ppc
2.4.22-ben2). I've also seen the problem under 2.4.23-mh1 and 2.6.0
kernels. So I don't think it's kernel-specific.
Here's what hcidump shows:
[ successful SDP interrogation ]
> ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x00e4
< ACL data: handle 0x0029 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x00e4 result 0 status 0
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0041 flags 0x0000 clen 0
< ACL data: handle 0x0029 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x00e4 flags 0x0000 result 0 clen 0
< ACL data: handle 0x0029 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x00e4 flags 0x0000 clen 4
MTU 1024
> HCI Event: Number of Completed Packets(0x13) plen 5
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0029 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x0000 result 0 clen 4
MTU 672
> ACL data: handle 0x0029 flags 0x02 dlen 8
L2CAP(d): cid 0x41 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
[a long wait here while nothing happens]
> ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x00e4
< ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x00e4
> HCI Event: Number of Completed Packets(0x13) plen 5
> ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x00e3
< ACL data: handle 0x0029 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x00e3
> HCI Event: Number of Completed Packets(0x13) plen 5
> HCI Event: Disconn Complete(0x05) plen 4
Hi Michal,
> > I am no expert for this, but my understanding is that we can't use the
> > Bluetooth logo until the stack got its qualification. I think the best
> > way is to replace this logo. Maybe we should start an official BlueZ
> > logo contest.
>
> Hmmm and why not to get it to qualificate? I think it's free and without
> payment?
this is more problematic than you think. The general problem is money of
course, because a qualification is expensive. But from my point of view
the biggest problem is that I don't have access to protocol and profile
testers. We have to know what tests fail and what we pass. If we know
how to run these test the whole qualification process can be done by
everyone.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Dne p=E1tek 02 leden 2004 12:24 Marcel Holtmann napsal(a):
> Hi Edd,
>
> > > I am looking forward to include the bluez-pin as default pin-helper
> > > program. Do you have included the DBUS patch for hcid? If yes, please
> > > mail me the version you have used.
> >
> > No, I didn't include this patch.
>
> I have no coding experiences with DBUS at the moment, but I already
> decided to make DBUS the default method for the new Bluetooth security
> manager.
>
> > Btw, the bluez-pin source seems to include a PNG of the Bluetooth logo
> > -- I was under the impression that only qualified software can use
> > this. If so, we need to find some other logo to distribute, don't we?
>
> I am no expert for this, but my understanding is that we can't use the
> Bluetooth logo until the stack got its qualification. I think the best
> way is to replace this logo. Maybe we should start an official BlueZ
> logo contest.
Hmmm and why not to get it to qualificate? I think it's free and without=20
payment?
Michal
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Edd,
> > I am looking forward to include the bluez-pin as default pin-helper
> > program. Do you have included the DBUS patch for hcid? If yes, please
> > mail me the version you have used.
>
> No, I didn't include this patch.
I have no coding experiences with DBUS at the moment, but I already
decided to make DBUS the default method for the new Bluetooth security
manager.
> Btw, the bluez-pin source seems to include a PNG of the Bluetooth logo
> -- I was under the impression that only qualified software can use
> this. If so, we need to find some other logo to distribute, don't we?
I am no expert for this, but my understanding is that we can't use the
Bluetooth logo until the stack got its qualification. I think the best
way is to replace this logo. Maybe we should start an official BlueZ
logo contest.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Fri, 2004-01-02 at 11:04, Marcel Holtmann wrote:
> I am looking forward to include the bluez-pin as default pin-helper
> program. Do you have included the DBUS patch for hcid? If yes, please
> mail me the version you have used.
No, I didn't include this patch.
Btw, the bluez-pin source seems to include a PNG of the Bluetooth logo
-- I was under the impression that only qualified software can use
this. If so, we need to find some other logo to distribute, don't we?
-- Edd
Hi Edd,
> > For the BlueZ libs I don't plan another release, because the new major
> > version of the Bluetooth library is making good progress. But for the
> > BlueZ Utils I want to make another release that addresses the problems
> > with the pin_helper program. I think the C based bluez-pin is a good
> > idea and maybe we should also integrate the DBus support into the next
> > release. So I like to get comments on this and if you have patches,
> > please resend them.
>
> For a while now the Debian packages have brought in the DBUS/GTK
> bluez-pin implementation as the default, and I've had no complaints at
> all. DBUS seems to be really catching on as the way to do things like
> this.
I am looking forward to include the bluez-pin as default pin-helper
program. Do you have included the DBUS patch for hcid? If yes, please
mail me the version you have used.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Thu, 2003-12-18 at 23:55, Marcel Holtmann wrote:
> Hi Folks,
>
> I don't wanna make big words about it, but after 8 months there are new
> releases of the BlueZ libs and utils packages.
I just uploaded these to Debian sid. Sorry for the delay, but the
holiday season and the recent Debian break-in delayed me.
> For the BlueZ libs I don't plan another release, because the new major
> version of the Bluetooth library is making good progress. But for the
> BlueZ Utils I want to make another release that addresses the problems
> with the pin_helper program. I think the C based bluez-pin is a good
> idea and maybe we should also integrate the DBus support into the next
> release. So I like to get comments on this and if you have patches,
> please resend them.
For a while now the Debian packages have brought in the DBUS/GTK
bluez-pin implementation as the default, and I've had no complaints at
all. DBUS seems to be really catching on as the way to do things like
this.
-- Edd