Hello guys,
I've spent the last 6 hours hitting my head against the wall to get
proxy to work.
I've been able to create a port, and register it, by calling CreateProxy
and then proxy.Enable() but it seems that there's no way to tell when
you get a new connection, or I'm wrong?
What I want to do is rather simple, make a simple spp server in python,
so I started using the serial service. I know I can go the old rfcomm
socket way, but would like to avoid it.
BTW shouldn't CreateProxy accept 'ssp' along with 128 UUID?
Thanks,
Manuel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> go and write up a proper proposal for that API and make an
> implementation.
>
Ok I had investigated, and you're right, it doesn't make any sense to
make a DBUS api. We will need a socket anyway, so it's easier using the
socket interface.
I will write some simple samples and put them on the wiki so others can
use them.
Thanks,
Manuel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >From our experience using RFCOMM ttys is not a good idea. The bluetooth
> rfcomm tty driver in the kernel is too unreliable in certain situations. We
> actually have to patch our device kernels in order to get it working somewhat
> correctly.
>
I know that RFcomm tty is a bit buggy, I've been investigating on ways
to implement a user-space tty device, but I can't find anything that can
apply to a 2.6 kernel. There's a hole framework but for the 2.4 branch.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Manuel,
>> how do you wanna transfer the data? D-Bus is not for data transfer
> Via a dev file the same way the rfcomm tool does, we just create
> /dev/rfcomm# or maybe new socket?
>
> I think the main idea is hiding the hole socket functionality, so
> maybe
> creating a new socket for accessing to the established connection
> doesn't make any sense. But maybe creating a node on runtime and then
> telling the programmer over d-bus that the connection status makes
> sense.
>
> Ideas? I don't think I'm fully out of the path.
go and write up a proper proposal for that API and make an
implementation.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Manuel,
> Ok if it's not there why not creating it? I can do it I think. Is there
> any convention on how to do this? Any API proposal?
>
> I would say it should be something like:
> methods:
> listenRFcomm
> closeRFcomm
>
> signals:
> RFcommConnected
> RfcommDisconnected
>
> Does it make any sense at all? I would say that maybe not, but it might
> be a good idea to have an rfcomm wrapper. Something that creates the
> rfcomm port, makes the connection and then just returns the rfcomm
> device. Ideas?
>>From our experience using RFCOMM ttys is not a good idea. The bluetooth
rfcomm tty driver in the kernel is too unreliable in certain situations. We
actually have to patch our device kernels in order to get it working somewhat
correctly.
The CreateProxy is still your best bet, or you can use bluetooth rfcomm
sockets and do it yourself.
Regards,
-Denis
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> how do you wanna transfer the data? D-Bus is not for data transfer
Via a dev file the same way the rfcomm tool does, we just create
/dev/rfcomm# or maybe new socket?
I think the main idea is hiding the hole socket functionality, so maybe
creating a new socket for accessing to the established connection
doesn't make any sense. But maybe creating a node on runtime and then
telling the programmer over d-bus that the connection status makes sense.
Ideas? I don't think I'm fully out of the path.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Manuel,
>> You can't really do that over D-Bus. Use the native RFCOMM sockets
>> from the Bluetooth library.
>>
> Ok if it's not there why not creating it? I can do it I think. Is
> there
> any convention on how to do this? Any API proposal?
>
> I would say it should be something like:
> methods:
> listenRFcomm
> closeRFcomm
>
> signals:
> RFcommConnected
> RfcommDisconnected
>
> Does it make any sense at all? I would say that maybe not, but it
> might
> be a good idea to have an rfcomm wrapper. Something that creates the
> rfcomm port, makes the connection and then just returns the rfcomm
> device. Ideas?
how do you wanna transfer the data? D-Bus is not for data transfer.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
> in the most cases this is a hardware port. It can be emulated, but
> that is not the usual case.
>
Ouu ok. Not good for me then.
> You can't really do that over D-Bus. Use the native RFCOMM sockets
> from the Bluetooth library.
>
Ok if it's not there why not creating it? I can do it I think. Is there
any convention on how to do this? Any API proposal?
I would say it should be something like:
methods:
listenRFcomm
closeRFcomm
signals:
RFcommConnected
RfcommDisconnected
Does it make any sense at all? I would say that maybe not, but it might
be a good idea to have an rfcomm wrapper. Something that creates the
rfcomm port, makes the connection and then just returns the rfcomm
device. Ideas?
Thanks,
Manuel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Manuel,
>> the proxy is what it is called. A proxy. So you need to have a
>> Unix,TCP or TTY server to connect to.
>>
> Ok good, what would be a TTY server in this case? I can imagine a TCP
> server, but a TTY server? Never heard of it.
in the most cases this is a hardware port. It can be emulated, but
that is not the usual case.
> Maybe it wasn't CreateProxy the one I should be using. I just need to
> create an RFcomm port, and then wait until someone connects to it,
> should I use createPort then?
You can't really do that over D-Bus. Use the native RFCOMM sockets
from the Bluetooth library.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
> the proxy is what it is called. A proxy. So you need to have a
> Unix,TCP or TTY server to connect to.
>
Ok good, what would be a TTY server in this case? I can imagine a TCP
server, but a TTY server? Never heard of it.
Maybe it wasn't CreateProxy the one I should be using. I just need to
create an RFcomm port, and then wait until someone connects to it,
should I use createPort then?
Thanks,
Manuel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Manuel,
> I've spent the last 6 hours hitting my head against the wall to get
> proxy to work.
>
> I've been able to create a port, and register it, by calling
> CreateProxy
> and then proxy.Enable() but it seems that there's no way to tell when
> you get a new connection, or I'm wrong?
>
> What I want to do is rather simple, make a simple spp server in
> python,
> so I started using the serial service. I know I can go the old rfcomm
> socket way, but would like to avoid it.
the proxy is what it is called. A proxy. So you need to have a
Unix,TCP or TTY server to connect to.
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Pierre-Yves,
> I've observed the same thing: rfcomm ttys are not reliable. I've
> reported several time Oopses related to them, and so far each time one
> Oops/Warning/Bug is fixed, another one happens. Basically, I know no
> kernel version which is robust regarding rfcomm ttys.
We haven't observed this in the newer kernels, but I'm sure they exist.
>
> At the moment I'm looking for a reliable alternative to the ttys. From
> what I understand, using an rfcomm socket instead of the ttys would be a
> solution, as they are reputed more reliable. But going the socket's way
> would mean abandonning the DBus API and linking against the bluetooth
> lib, or am I mistaken? My application is currently only accessing BlueZ
> through this DBus API, and it is indeed a great API. It would be sad to
> have to abandon that to get reliable rfcomm functionnality.
>
> I've no experience at all with the rfcomm sockets from the Bluetooth
> library (so take what I say with the required amount of salt). Wouldn't
> a solution be to allow opening sockets through the DBus serial service,
> instead of the current rfcomm ttys-only approach? I'm talking mostly
> about the ConnectService and ConnectServiceFromAdapter in the serial
> manager hierarchy.
Using sockets is fairly trivial, there are plenty of examples of how to use
RFCOMM sockets in the bluez-utils. Look under test/rctest.c for instance.
You don't need to link against libbluetooth if you don't want to (e.g. for
GPL license reasons), however you will have to re-invent some functionality
yourself (e.g. Address parsing, etc).
You will need some form of socket no matter what you do (e.g. use Bluetooth
sockets directly, or use the Serial Proxy, which will still require unix
domain or tcp sockets)
As a shameless plug, Qtopia has a much simplified socket API:
http://doc.trolltech.com/qtopia4.3/qtopiabluetooth.html.
>
> Denis, could you also expand further about the kind of patching you
> perform on your kernels, regarding rfcomm tty's reliability?
See my patch submission from a few days ago. Basically the current bugs are
that tty doesn't do proper echoing and data can get lost during socket->tty
adaptation (so a serious problem for HFP, GPS, etc)
-Denis
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Manuel,
> You don't need to link against bluez AFAIK, you only link against the
> sockets library which is included in libc. I'll try to write a wiki page
> today, the other day I had some troubles with my electric power
> provider, and forgot to make the wiki page.
That would be great! A I said, I've no idea about rfcomm sockets, so
example code would help me get up to speed.
> But I've been able to write 2 examples on as master, the other as slave
> using python and dbus, and I have C code around I can use too.
Very promising :-)
Best Regards,
Pierre-Yves
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Pierre-Yves,
You don't need to link against bluez AFAIK, you only link against the
sockets library which is included in libc. I'll try to write a wiki page
today, the other day I had some troubles with my electric power
provider, and forgot to make the wiki page.
But I've been able to write 2 examples on as master, the other as slave
using python and dbus, and I have C code around I can use too.
Cheers,
Manuel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
>>>From our experience using RFCOMM ttys is not a good idea. The bluetooth
> rfcomm tty driver in the kernel is too unreliable in certain situations. We
> actually have to patch our device kernels in order to get it working somewhat
> correctly.
I've observed the same thing: rfcomm ttys are not reliable. I've
reported several time Oopses related to them, and so far each time one
Oops/Warning/Bug is fixed, another one happens. Basically, I know no
kernel version which is robust regarding rfcomm ttys.
At the moment I'm looking for a reliable alternative to the ttys. From
what I understand, using an rfcomm socket instead of the ttys would be a
solution, as they are reputed more reliable. But going the socket's way
would mean abandonning the DBus API and linking against the bluetooth
lib, or am I mistaken? My application is currently only accessing BlueZ
through this DBus API, and it is indeed a great API. It would be sad to
have to abandon that to get reliable rfcomm functionnality.
I've no experience at all with the rfcomm sockets from the Bluetooth
library (so take what I say with the required amount of salt). Wouldn't
a solution be to allow opening sockets through the DBus serial service,
instead of the current rfcomm ttys-only approach? I'm talking mostly
about the ConnectService and ConnectServiceFromAdapter in the serial
manager hierarchy.
Denis, could you also expand further about the kind of patching you
perform on your kernels, regarding rfcomm tty's reliability?
Regards,
Pierre-Yves
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel