* [Bluez-users] rfcomm device blocking/data available behaviour
@ 2006-06-16 13:23 Dave Marples
2006-06-16 15:40 ` Dave Marples
0 siblings, 1 reply; 3+ messages in thread
From: Dave Marples @ 2006-06-16 13:23 UTC (permalink / raw)
To: bluez-users
Folks,
I've got a problem using rfcomm to a generic BT device (actually a SE
K750i phone, but that's just what I'm using for an example). It looks
to me like a bug in the rfcomm/socket interface, but what do I know?
The problem seems to be that blocking/select on a rfcomm serial port
isn't working correctly. This is using Ubuntu Dapper (latest release)
and I've checked the bluetooth/rfcomm directory against patch 2.6.16-mh3
to ensure that all of the current changes are in there, and they are (in
fact, only core.c has changed, and that's mostly beautification).
The easiest way to create the problem is as follows;
1) In /etc/bluetooth/rfcomm.conf establish a connection to the phone;
rfcomm3 {
bind yes;
# Bluetooth address of the device
device xx:xx:xx:xx:xx:xx;
# RFCOMM channel for the connection
channel 1;
# Description of the connection
comment "K750i";
}
2) ...then cat /dev/rfcomm3
Obviously, at this point nothing happens.
3) _RING_ the phone
The output from the 'cat' job goes crazy, and never finishes.
Another way to create the problem is the following (using python);
fd=open("/dev/rfcomm3","r+")
fd.write("ATZ\n")
while 1:
c=fd.read(1)
print "Got",len(c),"Detail:",ord(c),c
Can anyone help? I'm stuck here....it's quite possible I'm doing
something _really_ silly, but I need someone to hold a mirror up to be
able to see that...
Regards
DAVE
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Bluez-users] rfcomm device blocking/data available behaviour
2006-06-16 13:23 [Bluez-users] rfcomm device blocking/data available behaviour Dave Marples
@ 2006-06-16 15:40 ` Dave Marples
2006-06-17 10:19 ` Marcel Holtmann
0 siblings, 1 reply; 3+ messages in thread
From: Dave Marples @ 2006-06-16 15:40 UTC (permalink / raw)
To: BlueZ users
Folks,
Replying to myself here, but moving over to the python library, the
following code _works_;
import bluetooth
s=bluetooth.BluetoothSocket( bluetooth.RFCOMM )
s.connect(("xx:xx:xx:xx:xx:xx",1))
s.send('ATZ\r')
while 1:
c=s.recv(1)
print "Got",len(c),"Detail:",ord(c),c
...so, I can only conclude that it's something to do with the device
emulation side of things. Hope this is helpful to someone.
Regards
DAVE
Dave Marples wrote:
> Folks,
>
> I've got a problem using rfcomm to a generic BT device (actually a SE
> K750i phone, but that's just what I'm using for an example). It looks
> to me like a bug in the rfcomm/socket interface, but what do I know?
>
> The problem seems to be that blocking/select on a rfcomm serial port
> isn't working correctly. This is using Ubuntu Dapper (latest release)
> and I've checked the bluetooth/rfcomm directory against patch 2.6.16-mh3
> to ensure that all of the current changes are in there, and they are (in
> fact, only core.c has changed, and that's mostly beautification).
>
> The easiest way to create the problem is as follows;
>
> 1) In /etc/bluetooth/rfcomm.conf establish a connection to the phone;
>
> rfcomm3 {
> bind yes;
> # Bluetooth address of the device
> device xx:xx:xx:xx:xx:xx;
> # RFCOMM channel for the connection
> channel 1;
> # Description of the connection
> comment "K750i";
> }
>
> 2) ...then cat /dev/rfcomm3
>
> Obviously, at this point nothing happens.
> 3) _RING_ the phone
>
> The output from the 'cat' job goes crazy, and never finishes.
>
> Another way to create the problem is the following (using python);
>
> fd=open("/dev/rfcomm3","r+")
> fd.write("ATZ\n")
> while 1:
> c=fd.read(1)
> print "Got",len(c),"Detail:",ord(c),c
>
> Can anyone help? I'm stuck here....it's quite possible I'm doing
> something _really_ silly, but I need someone to hold a mirror up to be
> able to see that...
>
> Regards
>
> DAVE
>
>
>
> _______________________________________________
> Bluez-users mailing list
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Bluez-users] rfcomm device blocking/data available behaviour
2006-06-16 15:40 ` Dave Marples
@ 2006-06-17 10:19 ` Marcel Holtmann
0 siblings, 0 replies; 3+ messages in thread
From: Marcel Holtmann @ 2006-06-17 10:19 UTC (permalink / raw)
To: BlueZ users
Hi Dave,
> Replying to myself here, but moving over to the python library, the
> following code _works_;
>
> import bluetooth
>
> s=bluetooth.BluetoothSocket( bluetooth.RFCOMM )
> s.connect(("xx:xx:xx:xx:xx:xx",1))
> s.send('ATZ\r')
> while 1:
> c=s.recv(1)
> print "Got",len(c),"Detail:",ord(c),c
>
> ...so, I can only conclude that it's something to do with the device
> emulation side of things. Hope this is helpful to someone.
the RFCOMM TTY devices are not in raw mode by default. You need to do
that by yourself. However every application should now what's the best
mode to use the device and cat is simply too dumb.
Regards
Marcel
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-06-17 10:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-16 13:23 [Bluez-users] rfcomm device blocking/data available behaviour Dave Marples
2006-06-16 15:40 ` Dave Marples
2006-06-17 10:19 ` Marcel Holtmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox