hi,
I am trying to open multiple connections by connecting to OBEX push
servers on different mobiles using single blue tooth adapter. The steps that
i am taking right now are as follows:-
i) Detecting bluetooth devices.
ii) Sending data to any detected device through a different process (i do a
fork in the main program). This new process first sets up a RFCOMM channel
to the devices OBEX push server and then sends data to it through using open
obex API.
But the above scheme is not working correctly. Can someone tell me the
mistake i am making and how should i correct it. Please help me as i find
my self quite clueless abt to how to proceed now. Also it would be great
help if anyone can even give me a direction in which i should proceed now.
Eagerly waiting for reply.Thanks in advance.
bye bye
Marcel Holtmann wrote:
> Check /sys/class/bluetooth/rfcomm that you really have a listening
> RFCOMM socket on the right channel after starting dund.
How do I check this? In that directory I have "hci0", which is a soft
link, and three other files "l2cap", "rfcomm", "rfcomm_dlc". How
do I check they are correct?
Also, I have to own up to something silly: when some of your
statements seemed to imply that most of this should work
without special configuration, I put the original config
files in place, but didn't notice that dund was off by
default. I'll post some new dumps with that corrected.
Cheers,
Paul.
-------------------------------------------------------------------------
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,
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
> > ACL data: handle 42 flags 0x02 dlen 17
> > ACL data: handle 42 flags 0x01 dlen 1
> L2CAP(d): cid 0x0041 len 14 [psm 3]
> RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
> dlci 4 frame_type 0 credit_flow 15 pri 32 ack_timer 0
> frame_size 1024 max_retrans 0 credits 7
> < ACL data: handle 42 flags 0x02 dlen 8
> L2CAP(d): cid 0x0203 len 4 [psm 3]
> RFCOMM(s): DM: cr 1 dlci 4 pf 1 ilen 0 fcs 0xbc
>
> And why a DM for channel 4 is sent as a response of a PN CMD for dlci 0 ?
> Should this not happen ? There must be some problem of the command that
> was received. Maybe we've got a corrupted command for dlci 4 and that hcidump
> didn't show it up.
actually that is the wrong interpretation. The PN CMD is sent on the
multiplexer DLCI 0 and it is sent for DLCI 4. This means we try to open
RFCOMM channel 2. The following DM is an indication that no service is
listening on RFCOMM channel 2. Hence my request to check the actual
registered listening sockets via /sys/class/bluetooth/rfcomm.
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
> > ACL data: handle 42 flags 0x02 dlen 12
> L2CAP(s): Disconn req: dcid 0x0041 scid 0x0203
> < ACL data: handle 42 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0203
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
>
> This is really strange.
No, it is not.
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 1/3/07, Paul Gardiner <[email protected]> wrote:
> > ACL data: handle 42 flags 0x02 dlen 8
> L2CAP(d): cid 0x0041 len 4 [psm 3]
> RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> < ACL data: handle 42 flags 0x02 dlen 8
> L2CAP(d): cid 0x0203 len 4 [psm 3]
> RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
here we have established the RFCOMM session(control channel).
> HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
> > ACL data: handle 42 flags 0x02 dlen 17
> > ACL data: handle 42 flags 0x01 dlen 1
> L2CAP(d): cid 0x0041 len 14 [psm 3]
> RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
> dlci 4 frame_type 0 credit_flow 15 pri 32 ack_timer 0
> frame_size 1024 max_retrans 0 credits 7
> < ACL data: handle 42 flags 0x02 dlen 8
> L2CAP(d): cid 0x0203 len 4 [psm 3]
> RFCOMM(s): DM: cr 1 dlci 4 pf 1 ilen 0 fcs 0xbc
And why a DM for channel 4 is sent as a response of a PN CMD for dlci 0 ?
Should this not happen ? There must be some problem of the command that
was received. Maybe we've got a corrupted command for dlci 4 and that
hcidump
didn't show it up.
> HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
> > ACL data: handle 42 flags 0x02 dlen 12
> L2CAP(s): Disconn req: dcid 0x0041 scid 0x0203
> < ACL data: handle 42 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0203
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
This is really strange.
Marcel Holtmann wrote:
> Hi Paul,
>
>>>>> And once again "hcidump -X -V" is your friend in showing what
>>>>> actually happens on the Bluetooth chip level.
>>>> Are there people on this list that might be willing to look over
>>>> a posted dump then? My problem with DUN produced a trace, but
>>>> I gave up on it because there was no way I could understand
>>>> it. Is it worth my posting a dump?
>>> depends on what level the problem actually is. If it is hidden somewhere
>>> in the PPP part it is unlikely that you get a fast answer. If it is
>>> something obvious you might get your problem solved very quickly. So it
>>> is always worth posting the hcidump.
>> Great. Thanks for at least having a look. I think the problem is
>> early on because I get nothing in my logs from dund.
Thanks for taking a look.
> even if some howtos tell you to use sdptool to add a service record.
> Simply don't do that. The dund will do it for you when needed and with
> the correct attributes.
As you say, I got that from a howto, but I also had signs it was
needed, in that if I don't issue that command then my S100 wont
consider using the Bluez device as a modem. The device appears
in the S100's list of all bluetooth devices, but when trying to
create a new "Network Connection", Bluez doesn't appear in the
list of bluetooth devices that should be considered for that
use.
That and your statement above would imply that dund is
not seeing fit to add a service record, or it is adding
one with a different set of attributes, which the S100
doesn't like. Any idea why that might be?
> Check /sys/class/bluetooth/rfcomm that you really have a listening
> RFCOMM socket on the right channel after starting dund.
Will do. Thanks.
> And since you connect from a Windows OS, it might do something crazy or
> expect something strange and that could be the reason why it is not
> working.
Yeah I see what you mean, but it can't be insurmountable because all
this was working with the earlier version of Bluez that was shipped
with opensuse 10.1.
Cheers,
Paul.
-------------------------------------------------------------------------
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 Paul,
> >>> And once again "hcidump -X -V" is your friend in showing what
> >>> actually happens on the Bluetooth chip level.
> >> Are there people on this list that might be willing to look over
> >> a posted dump then? My problem with DUN produced a trace, but
> >> I gave up on it because there was no way I could understand
> >> it. Is it worth my posting a dump?
> >
> > depends on what level the problem actually is. If it is hidden somewhere
> > in the PPP part it is unlikely that you get a fast answer. If it is
> > something obvious you might get your problem solved very quickly. So it
> > is always worth posting the hcidump.
>
> Great. Thanks for at least having a look. I think the problem is
> early on because I get nothing in my logs from dund.
even if some howtos tell you to use sdptool to add a service record.
Simply don't do that. The dund will do it for you when needed and with
the correct attributes.
Check /sys/class/bluetooth/rfcomm that you really have a listening
RFCOMM socket on the right channel after starting dund.
And since you connect from a Windows OS, it might do something crazy or
expect something strange and that could be the reason why it is not
working.
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
Marcel Holtmann wrote:
> Hi Paul,
>
>>> And once again "hcidump -X -V" is your friend in showing what
>>> actually happens on the Bluetooth chip level.
>> Are there people on this list that might be willing to look over
>> a posted dump then? My problem with DUN produced a trace, but
>> I gave up on it because there was no way I could understand
>> it. Is it worth my posting a dump?
>
> depends on what level the problem actually is. If it is hidden somewhere
> in the PPP part it is unlikely that you get a fast answer. If it is
> something obvious you might get your problem solved very quickly. So it
> is always worth posting the hcidump.
Great. Thanks for at least having a look. I think the problem is
early on because I get nothing in my logs from dund.
Here it is:
HCI sniffer - Bluetooth packet analyzer ver 1.33
device: hci0 snap_len: 1028 filter: 0xffffffff
> HCI Event: Connect Request (0x04) plen 10
bdaddr 00:09:2D:08:BC:57 class 0x100114 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:09:2D:08:BC:57 role 0x01
Role: Slave
> HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 42 bdaddr 00:09:2D:08:BC:57 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 42
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
bdaddr 00:09:2D:08:BC:57 mode 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
> HCI Event: Max Slots Change (0x1b) plen 3
handle 42 slots 5
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0200
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0200 result 0 status 0
Connection successful
> HCI Event: Command Status (0x0f) plen 4
Unknown (0x00|0x0000) status 0x00 ncmd 1
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
handle 42 policy 0x0f
Link policy: RSWITCH HOLD SNIFF PARK
> HCI Event: Command Complete (0x0e) plen 6
Write Link Policy Settings (0x02|0x000d) ncmd 1
status 0x00 handle 42
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
handle 42 ptype 0xcc18
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
Change Connection Packet Type (0x01|0x000f) status 0x00 ncmd 1
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:09:2D:08:BC:57 mode 2 clkoffset 0x0000
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
status 0x00 handle 42 ptype 0xff1e
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 2-DH1 2-DH3 2-DH5 3-DH1 3-DH3
3-DH5
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 42
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 4096
< ACL data: handle 42 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0200 flags 0x00 result 0 clen 0
Success
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0200 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 00:09:2D:08:BC:57 name 'Pocket_PC2'
> ACL data: handle 42 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 17
> ACL data: handle 42 flags 0x01 dlen 17
> ACL data: handle 42 flags 0x01 dlen 2
L2CAP(d): cid 0x0040 len 32 [psm 1]
SDP SSA Req: tid 0x0 len 0x1b
pat uuid-128 00001103-0000-1000-8000-00805f9b34fb
max 4088
aid(s) 0x0004 (ProtocolDescList)
cont 00
< ACL data: handle 42 flags 0x02 dlen 52
L2CAP(d): cid 0x0200 len 48 [psm 1]
SDP SSA Rsp: tid 0x0 len 0x2b
count 40
record #0
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) > <
uuid-16 0x0003 (RFCOMM) uint 0x2 > >
record #1
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) > <
uuid-16 0x0003 (RFCOMM) uint 0x2 > >
cont 00
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0201
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0201 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0200
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0200
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 0
< ACL data: handle 42 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0201 flags 0x00 result 0 clen 0
Success
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0201 flags 0x00 clen 4
MTU 1013
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0201 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
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 17
> ACL data: handle 42 flags 0x01 dlen 1
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
dlci 4 frame_type 0 credit_flow 15 pri 32 ack_timer 0
frame_size 1024 max_retrans 0 credits 7
< ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0201 len 4 [psm 3]
RFCOMM(s): DM: cr 1 dlci 4 pf 1 ilen 0 fcs 0xbc
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x0201
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0201
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0202
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0202 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 4096
< ACL data: handle 42 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0202 flags 0x00 result 0 clen 0
Success
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0202 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 17
> ACL data: handle 42 flags 0x01 dlen 17
> ACL data: handle 42 flags 0x01 dlen 2
L2CAP(d): cid 0x0040 len 32 [psm 1]
SDP SSA Req: tid 0x0 len 0x1b
pat uuid-128 00001103-0000-1000-8000-00805f9b34fb
max 4088
aid(s) 0x0004 (ProtocolDescList)
cont 00
< ACL data: handle 42 flags 0x02 dlen 52
L2CAP(d): cid 0x0202 len 48 [psm 1]
SDP SSA Rsp: tid 0x0 len 0x2b
count 40
record #0
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) > <
uuid-16 0x0003 (RFCOMM) uint 0x2 > >
record #1
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) > <
uuid-16 0x0003 (RFCOMM) uint 0x2 > >
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0203
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0203 result 0 status 0
Connection successful
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0202
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0202
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 0
< ACL data: handle 42 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0203 flags 0x00 result 0 clen 0
Success
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0203 flags 0x00 clen 4
MTU 1013
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
> ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0203 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
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 17
> ACL data: handle 42 flags 0x01 dlen 1
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
dlci 4 frame_type 0 credit_flow 15 pri 32 ack_timer 0
frame_size 1024 max_retrans 0 credits 7
< ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0203 len 4 [psm 3]
RFCOMM(s): DM: cr 1 dlci 4 pf 1 ilen 0 fcs 0xbc
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x0203
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0203
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 42 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 42 reason 0x16
Reason: Connection Terminated by Local Host
-------------------------------------------------------------------------
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 Paul,
> > And once again "hcidump -X -V" is your friend in showing what
> > actually happens on the Bluetooth chip level.
>
> Are there people on this list that might be willing to look over
> a posted dump then? My problem with DUN produced a trace, but
> I gave up on it because there was no way I could understand
> it. Is it worth my posting a dump?
depends on what level the problem actually is. If it is hidden somewhere
in the PPP part it is unlikely that you get a fast answer. If it is
something obvious you might get your problem solved very quickly. So it
is always worth posting the hcidump.
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
Marcel Holtmann wrote:
> And once again "hcidump -X -V" is your friend in showing what
> actually happens on the Bluetooth chip level.
Are there people on this list that might be willing to look over
a posted dump then? My problem with DUN produced a trace, but
I gave up on it because there was no way I could understand
it. Is it worth my posting a dump?
Cheers,
Paul.
-------------------------------------------------------------------------
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 Tue, 2 Jan 2007 18:16:28 +0530
"siddhant tewari" <[email protected]> wrote:
> With linux being one of the major players in embedded domain and bluez
> being an official protocol of linux there is definitely a great need for
> multi connection support. You have suggested that somebody with a thorough
> understanding of bluetooth and its protocol should start to fork the full
> development of bluetooth support in linux , but that somebody cannot be at
> least me at this instance as i am just a starter and it took some effort
> from my side to even get the idea of what u wrote ... i think it should be
> someone like you who has such a clear picture of the problem or to be more
> precise really understands the problem well , who can initiate such
> development... all i can say is that i am ready to work if somebody can
> guide me ....
I'd love to start a fork and am thinking about it since a long time
and each time I crash on BlueZ. Unfortunately, I lack the fundings to
do so, as this is certainly not a job for a weekend.
> Please tell me what are the other options parallel to bluez and is it really
> advisable to use them .
>
> I am stuck at this problem and i dont like leaving it as such.
As I told you, there is no other way. If there was, I wouldn't have
started a complete user-space bluetooth stack spending already many
months on that. And unfortunately, I'm not allowed to share my code so
far (I wish I was).
Well, besides the two options (giving up or doing it yourself), there
might be a third one: It seems that they are working now on flow
control which is quite related to multi-connections. At least it
should. Meaning: you can wait until they think it's somehow useable
and try then. But you'll always be stuck on a fundamentally broken
design and depend on the help of a not so benevolent dictator. And I
wouldn't expect to see mainstream kernels with this code before mid
2007. If you watch out for what is said about bluetooth, we can expect
a significant increase in complexity regarding implementations. At
latest then, BlueZ will have to change anyway. Maybe then, you'll be
able to use it. This may take a couple of years.
-------------------------------------------------------------------------
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,
> Obviously, BlueZ didn't learn to deal with more than one connection at
> the same time yet. They are still thinking that everybody has a
> desktop computer with KDE (or Windows, as dbus being a derivate from
> gtk, is specially designed to be platform independent) and just a
> single cellphone or PDA at home. Of course, large companies like Nokia
> are not really affected by these problems, as a cellphone is so small
> that it can't deal with much more than one thing at the same time
> anyway. But this may change in some future.
that is FUD. BlueZ can deal with as many connections as the chip allows
us to establish.
> So your only choice is to not use libbluetooth. Marcel is right when
> he says that this implies a lot of work, as you will have to implement
> each protocol layer yourself. But as these are quite badly designed in
> BlueZ, there is really no fix for it. If the BlueZ developers had a
> different way of dealing with users (just look at their answers) the
> many thousands of hours of work we are doing each one on his own could
> go into this project. So, we are alone here. Your choices like mine or
> anybody else's who is trying to serious work with bluetooth, is either
> to give up or to do the work.
Badly designed protocol layers. We provide BSD socket based access to
them which is one of the most intuitive interfaces. Did you ever looked
at other stacks and their API?
> But be aware, that re-writing the protocol stack may not be
> enough. I've done so and am having bad troubles because BlueZ
> developers think that an exclusive usage over a socket can be
> implemented by the concept of a raw socket. This is not true. Even
> using raw sockets the kernel will interfere in your programming,
> meaning that it is quite possible that we will have to replace also
> the kernel modules, which would make 100% of BlueZ code unusable. Not
> regulating mutually interfering accesses to one and the same ressource
> is pure Windows philosophy, where each program, starting with
> kernel.dll thinks it owns the complete device. Raw sockets allow to do
> low leve things, but they don't guarantee that someone else wont undo
> what ever my program has done a second earlier. Even if this someone
> else is the kernel herself.
>
> I've suggested the use of an exclusive flag with the HCI sockets, when
> Marcel answered, that the kernel does NOT interfere when I open that
> socket in raw. This is just not true. Marcel (who should know as he
> wrote this monster) asked what exactly happens. Here it is:
>
> If your program is already active and you plug in an USB bluetooth
> dongle, the kernel issues several informational queries to the
> device. It needs to do so, as a raw socket doesn't imply that there
> couldn't be more than one processes accessing the same device (there
> is no exclusivity), while a second process might want to use a cooked
> socket. In my case, I know that there will be no other process,
> specially not hcid or dbus, but the kernel doesn't, and still issues
> these commands. Thus, I need to expect anything to happen, just for
> the USB dongle having been plugged in. This raises the level of
> complexity of my program by a power of magnitud. Also, Marcel himself
> said, that whenever a major version number is increased, we can not
> trust that the behaviour wont change incompatibly with the previous
> version (besides the use of dbus and apparently the inability to
> multitask). Did anybody see any reasoning why dbus is defended so
> stiff neckedly? Or why nobody cares to work on a design which actually
> matches what bluetooth specifications persue?
I actually have no real idea what your complaints are. The raw HCI
socket is different from an adapter in raw mode. I mentioned that
multiple times, but you don't seem to understand the difference. And
again, everybody who wants to do direct HCI programming is better off
writing their own stack. Leave the HCI handling to the kernel or hcid
and concentrate on real applications.
> Much worse is what happens if you create a connection. Until you get
> the connection complete event, everything is fine. But then, the
> kernel will issue several commands, ignoring any commands of yours
> until it's done. Among those is HCI_Write_Link_Policy_Settings. At
> this point it seems to be impossible to achieve for instance a role
> switch. Also, the kernel has no way to know what my program is trying
> to do, and thus can not know which is the link policy I need.
>
> You see, everybody doing things like you and me (and I've seen more
> than just a few more out there) is just out of luck. The best would be
> somebody starting to fork the full development of Bluetooth support in
> Linux, but this time with a well thought design based on a thorough
> understanding of bluetooth and it's protocols.
Be my guest and start the fork. When you think you understand
everything, I will show you bits and pieces you haven't thought about.
At some point you will realize that various parts of the Bluetooth
specification have their own problems.
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,
> With linux being one of the major players in embedded domain and
> bluez being an official protocol of linux there is definitely a great
> need for multi connection support. You have suggested that somebody
> with a thorough understanding of bluetooth and its protocol should
> start to fork the full development of bluetooth support in linux , but
> that somebody cannot be at least me at this instance as i am just a
> starter and it took some effort from my side to even get the idea of
> what u wrote ... i think it should be someone like you who has such a
> clear picture of the problem or to be more precise really understands
> the problem well , who can initiate such development... all i can say
> is that i am ready to work if somebody can guide me ....
please don't blindly believe everything that is posted on the mailing
list. You don't even have to believe me. BlueZ is fully multi adapter
and multi connection capable. However you need also a chip that supports
it and in some cases even a host stack on the other side that works
correctly. And once again "hcidump -X -V" is your friend in showing what
actually happens on the Bluetooth chip level.
> Please tell me what are the other options parallel to bluez and is it
> really advisable to use them .
There is no real alternative, but please be my guest and write something
new. At some point you will realize that developing a Bluetooth host
stack is not much fun anymore.
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 Cris,
With linux being one of the major players in embedded domain and bluez
being an official protocol of linux there is definitely a great need for
multi connection support. You have suggested that somebody with a thorough
understanding of bluetooth and its protocol should start to fork the full
development of bluetooth support in linux , but that somebody cannot be at
least me at this instance as i am just a starter and it took some effort
from my side to even get the idea of what u wrote ... i think it should be
someone like you who has such a clear picture of the problem or to be more
precise really understands the problem well , who can initiate such
development... all i can say is that i am ready to work if somebody can
guide me ....
Please tell me what are the other options parallel to bluez and is it really
advisable to use them .
I am stuck at this problem and i dont like leaving it as such.
regards
siddhant
On 1/2
/07, Cris <[email protected]> wrote:
>
> On Tue, 2 Jan 2007 15:59:19 +0530
> "siddhant tewari" <[email protected]> wrote:
>
> > hi cris,
> > I tried similar thing using OBEX push client and the thing
> that
> > happened is exactly what u apprehended ...
> > -> One thread waited for the other to get completed .... sad blues
> > behavior.....this is exactly what is creating trouble in my application
> ...
>
> Obviously, BlueZ didn't learn to deal with more than one connection at
> the same time yet. They are still thinking that everybody has a
> desktop computer with KDE (or Windows, as dbus being a derivate from
> gtk, is specially designed to be platform independent) and just a
> single cellphone or PDA at home. Of course, large companies like Nokia
> are not really affected by these problems, as a cellphone is so small
> that it can't deal with much more than one thing at the same time
> anyway. But this may change in some future.
>
> So your only choice is to not use libbluetooth. Marcel is right when
> he says that this implies a lot of work, as you will have to implement
> each protocol layer yourself. But as these are quite badly designed in
> BlueZ, there is really no fix for it. If the BlueZ developers had a
> different way of dealing with users (just look at their answers) the
> many thousands of hours of work we are doing each one on his own could
> go into this project. So, we are alone here. Your choices like mine or
> anybody else's who is trying to serious work with bluetooth, is either
> to give up or to do the work.
>
> But be aware, that re-writing the protocol stack may not be
> enough. I've done so and am having bad troubles because BlueZ
> developers think that an exclusive usage over a socket can be
> implemented by the concept of a raw socket. This is not true. Even
> using raw sockets the kernel will interfere in your programming,
> meaning that it is quite possible that we will have to replace also
> the kernel modules, which would make 100% of BlueZ code unusable. Not
> regulating mutually interfering accesses to one and the same ressource
> is pure Windows philosophy, where each program, starting with
> kernel.dll thinks it owns the complete device. Raw sockets allow to do
> low leve things, but they don't guarantee that someone else wont undo
> what ever my program has done a second earlier. Even if this someone
> else is the kernel herself.
>
> I've suggested the use of an exclusive flag with the HCI sockets, when
> Marcel answered, that the kernel does NOT interfere when I open that
> socket in raw. This is just not true. Marcel (who should know as he
> wrote this monster) asked what exactly happens. Here it is:
>
> If your program is already active and you plug in an USB bluetooth
> dongle, the kernel issues several informational queries to the
> device. It needs to do so, as a raw socket doesn't imply that there
> couldn't be more than one processes accessing the same device (there
> is no exclusivity), while a second process might want to use a cooked
> socket. In my case, I know that there will be no other process,
> specially not hcid or dbus, but the kernel doesn't, and still issues
> these commands. Thus, I need to expect anything to happen, just for
> the USB dongle having been plugged in. This raises the level of
> complexity of my program by a power of magnitud. Also, Marcel himself
> said, that whenever a major version number is increased, we can not
> trust that the behaviour wont change incompatibly with the previous
> version (besides the use of dbus and apparently the inability to
> multitask). Did anybody see any reasoning why dbus is defended so
> stiff neckedly? Or why nobody cares to work on a design which actually
> matches what bluetooth specifications persue?
>
> Much worse is what happens if you create a connection. Until you get
> the connection complete event, everything is fine. But then, the
> kernel will issue several commands, ignoring any commands of yours
> until it's done. Among those is HCI_Write_Link_Policy_Settings. At
> this point it seems to be impossible to achieve for instance a role
> switch. Also, the kernel has no way to know what my program is trying
> to do, and thus can not know which is the link policy I need.
>
> You see, everybody doing things like you and me (and I've seen more
> than just a few more out there) is just out of luck. The best would be
> somebody starting to fork the full development of Bluetooth support in
> Linux, but this time with a well thought design based on a thorough
> understanding of bluetooth and it's protocols.
>
> -------------------------------------------------------------------------
> 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 Tue, 2 Jan 2007 15:59:19 +0530
"siddhant tewari" <[email protected]> wrote:
> hi cris,
> I tried similar thing using OBEX push client and the thing that
> happened is exactly what u apprehended ...
> -> One thread waited for the other to get completed .... sad blues
> behavior.....this is exactly what is creating trouble in my application ...
Obviously, BlueZ didn't learn to deal with more than one connection at
the same time yet. They are still thinking that everybody has a
desktop computer with KDE (or Windows, as dbus being a derivate from
gtk, is specially designed to be platform independent) and just a
single cellphone or PDA at home. Of course, large companies like Nokia
are not really affected by these problems, as a cellphone is so small
that it can't deal with much more than one thing at the same time
anyway. But this may change in some future.
So your only choice is to not use libbluetooth. Marcel is right when
he says that this implies a lot of work, as you will have to implement
each protocol layer yourself. But as these are quite badly designed in
BlueZ, there is really no fix for it. If the BlueZ developers had a
different way of dealing with users (just look at their answers) the
many thousands of hours of work we are doing each one on his own could
go into this project. So, we are alone here. Your choices like mine or
anybody else's who is trying to serious work with bluetooth, is either
to give up or to do the work.
But be aware, that re-writing the protocol stack may not be
enough. I've done so and am having bad troubles because BlueZ
developers think that an exclusive usage over a socket can be
implemented by the concept of a raw socket. This is not true. Even
using raw sockets the kernel will interfere in your programming,
meaning that it is quite possible that we will have to replace also
the kernel modules, which would make 100% of BlueZ code unusable. Not
regulating mutually interfering accesses to one and the same ressource
is pure Windows philosophy, where each program, starting with
kernel.dll thinks it owns the complete device. Raw sockets allow to do
low leve things, but they don't guarantee that someone else wont undo
what ever my program has done a second earlier. Even if this someone
else is the kernel herself.
I've suggested the use of an exclusive flag with the HCI sockets, when
Marcel answered, that the kernel does NOT interfere when I open that
socket in raw. This is just not true. Marcel (who should know as he
wrote this monster) asked what exactly happens. Here it is:
If your program is already active and you plug in an USB bluetooth
dongle, the kernel issues several informational queries to the
device. It needs to do so, as a raw socket doesn't imply that there
couldn't be more than one processes accessing the same device (there
is no exclusivity), while a second process might want to use a cooked
socket. In my case, I know that there will be no other process,
specially not hcid or dbus, but the kernel doesn't, and still issues
these commands. Thus, I need to expect anything to happen, just for
the USB dongle having been plugged in. This raises the level of
complexity of my program by a power of magnitud. Also, Marcel himself
said, that whenever a major version number is increased, we can not
trust that the behaviour wont change incompatibly with the previous
version (besides the use of dbus and apparently the inability to
multitask). Did anybody see any reasoning why dbus is defended so
stiff neckedly? Or why nobody cares to work on a design which actually
matches what bluetooth specifications persue?
Much worse is what happens if you create a connection. Until you get
the connection complete event, everything is fine. But then, the
kernel will issue several commands, ignoring any commands of yours
until it's done. Among those is HCI_Write_Link_Policy_Settings. At
this point it seems to be impossible to achieve for instance a role
switch. Also, the kernel has no way to know what my program is trying
to do, and thus can not know which is the link policy I need.
You see, everybody doing things like you and me (and I've seen more
than just a few more out there) is just out of luck. The best would be
somebody starting to fork the full development of Bluetooth support in
Linux, but this time with a well thought design based on a thorough
understanding of bluetooth and it's protocols.
-------------------------------------------------------------------------
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 cris,
I tried similar thing using OBEX push client and the thing that
happened is exactly what u apprehended ...
-> One thread waited for the other to get completed .... sad blues
behavior.....this is exactly what is creating trouble in my application ...
i will be doing more r n d based on ur suggestion and will definitely mail
the results ... really nice to see someone taking interest in the problem
..... also can u tell me what part of the bluez code i should look for to
make such thing supported or what do u think where the problem can be (any
intutive insight will be helpful as i am just a starter) ... i am ready to
put lot of efforts to solve this problem if its possible for me to do so ...
thanks for the reply
regards
siddhant
On 1/2/07, Cris <[email protected]> wrote:
>
> On Tue, 2 Jan 2007 13:46:08 +0530
> "siddhant tewari" <[email protected]> wrote:
>
> > hi,
> > Honest thanks to u for ur reply. Just a small question:
> > what i am trying is technically possible???
> > I dont have any problem in sending the code but it would be great
> pain
> > for others to understand my code and some effort for me as well in
> making it
> > more understandable for others.
>
> Hi Siddhant,
>
> If the question, whether it is technically possible, refers to the
> specifications of bluetooth, the answer is yes. Being a master (i.e.,
> the device initiating the connections) you can connect to up to 7
> other different bluetooth devices. But if the question refers to
> BlueZ, I can't tell you for sure. A few months ago I tested this and
> it failed not too gracefully. This is one of the reasons why I don't
> use libbluetooth anymore.
>
> However, there is a simple way to test it. Obex push and obex ftp are
> different profiles, but technically they use exactly the same methods
> (hci, l2cap, rfcomm, obex). Thus if one works, the other will work as
> well and vice verse. But the usage of obex ftp is much easier. Obex
> ftp uses BlueZ to set up a connection the `BlueZ' way. If you prepare
> two sessions of obex ftp to different peers but with the same file,
> and launch them as fast as you can at the same time, they must arrive
> approximately at the time. Just make sure that the peers have similar
> hardware and transmission conditions. In any case, obexftp does show
> you activity, which must be visible for both at the same time. If one
> is waiting until the other is done, you've still got the original, sad
> blues behaviour. As there is no bit of code you wrote to do so, there
> is also no bit of a chance that you committed any error. So, there is
> no need to publish your code.
>
> I'd be curious to know the result.
>
> -------------------------------------------------------------------------
> 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 Tue, 2 Jan 2007 13:46:08 +0530
"siddhant tewari" <[email protected]> wrote:
> hi,
> Honest thanks to u for ur reply. Just a small question:
> what i am trying is technically possible???
> I dont have any problem in sending the code but it would be great pain
> for others to understand my code and some effort for me as well in making it
> more understandable for others.
Hi Siddhant,
If the question, whether it is technically possible, refers to the
specifications of bluetooth, the answer is yes. Being a master (i.e.,
the device initiating the connections) you can connect to up to 7
other different bluetooth devices. But if the question refers to
BlueZ, I can't tell you for sure. A few months ago I tested this and
it failed not too gracefully. This is one of the reasons why I don't
use libbluetooth anymore.
However, there is a simple way to test it. Obex push and obex ftp are
different profiles, but technically they use exactly the same methods
(hci, l2cap, rfcomm, obex). Thus if one works, the other will work as
well and vice verse. But the usage of obex ftp is much easier. Obex
ftp uses BlueZ to set up a connection the `BlueZ' way. If you prepare
two sessions of obex ftp to different peers but with the same file,
and launch them as fast as you can at the same time, they must arrive
approximately at the time. Just make sure that the peers have similar
hardware and transmission conditions. In any case, obexftp does show
you activity, which must be visible for both at the same time. If one
is waiting until the other is done, you've still got the original, sad
blues behaviour. As there is no bit of code you wrote to do so, there
is also no bit of a chance that you committed any error. So, there is
no need to publish your code.
I'd be curious to know the result.
-------------------------------------------------------------------------
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 will try my best and in case i am not able move anything i will post
the code.
thanks
siddhant
On 1/2/07, Marcel Holtmann <[email protected]> wrote:
>
> Hi,
>
> > Honest thanks to u for ur reply. Just a small question:
> > what i am trying is technically possible???
>
> start with "hcidump -X -V" and look out for any error messages from the
> HCI layer.
>
> > I dont have any problem in sending the code but it would be great
> > pain for others to understand my code and some effort for me as well
> > in making it more understandable for others.
>
> That is your choice, but without the code it is kinda hard to actually
> fully understand what you are trying to achieve and how.
>
> 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,
> Honest thanks to u for ur reply. Just a small question:
> what i am trying is technically possible???
start with "hcidump -X -V" and look out for any error messages from the
HCI layer.
> I dont have any problem in sending the code but it would be great
> pain for others to understand my code and some effort for me as well
> in making it more understandable for others.
That is your choice, but without the code it is kinda hard to actually
fully understand what you are trying to achieve and how.
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,
Honest thanks to u for ur reply. Just a small question:
what i am trying is technically possible???
I dont have any problem in sending the code but it would be great pain
for others to understand my code and some effort for me as well in making it
more understandable for others.
Again thanking u for the advise.
regards
siddhant
On 1/2/07, Marcel Holtmann <[email protected]> wrote:
>
> Hi,
>
> > I am trying to open multiple connections by connecting to OBEX
> > push servers on different mobiles using single blue tooth adapter. The
> > steps that i am taking right now are as follows:-
> >
> > i) Detecting bluetooth devices.
> > ii) Sending data to any detected device through a different process (i
> > do a fork in the main program). This new process first sets up a
> > RFCOMM channel to the devices OBEX push server and then sends data to
> > it through using open obex API.
> >
> > But the above scheme is not working correctly. Can someone tell me
> > the mistake i am making and how should i correct it. Please help me as
> > i find my self quite clueless abt to how to proceed now. Also it
> > would be great help if anyone can even give me a direction in which i
> > should proceed now.
>
> you should start using "hcidump -X -V" as root to see what actually
> happens. And without seeing the code, we can't tell you anything.
>
> 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,
> I am trying to open multiple connections by connecting to OBEX
> push servers on different mobiles using single blue tooth adapter. The
> steps that i am taking right now are as follows:-
>
> i) Detecting bluetooth devices.
> ii) Sending data to any detected device through a different process (i
> do a fork in the main program). This new process first sets up a
> RFCOMM channel to the devices OBEX push server and then sends data to
> it through using open obex API.
>
> But the above scheme is not working correctly. Can someone tell me
> the mistake i am making and how should i correct it. Please help me as
> i find my self quite clueless abt to how to proceed now. Also it
> would be great help if anyone can even give me a direction in which i
> should proceed now.
you should start using "hcidump -X -V" as root to see what actually
happens. And without seeing the code, we can't tell you anything.
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