Hi again,
First of all, perhaps we should move this discussion to bluez-devel.
As I can see in lines 462-470 of core/l2cap.c, either the bind() fails if t=
he=20
PSM is in use, or it succeeds if it is free. I think this is where the code=
=20
for the case l2_bdaddr->psm=3D=3D0 should be added, changing the value to s=
ome=20
free PSM.
In this case, I am thinking of adding a 8192 byte array in l2cap.c, which=20
records (per bit) the PSMs which are in use. This idea is similar to the wa=
y=20
the kernel tracks the signals which should be masked per process. One would=
=20
then:
// 0xFFFF PSMs available =3D 8192 bytes
#define MAX_PSM_NDX 8192
// Record PSM use here in the following array:
unsigned char psm_use[MAX_PSM_NDX];
// Code which should be added to l2cap.c in l2cap_sock_bind()
for (i=3D513; i<MAX_PSM_NDX; i++) { // start a 513 to skip reserved PSMs
if (psm_use[i] < 255) { // a bit which is not set means there is a free PS=
M
// bit ops to locate the first 0 bit
// change the ls->psm value to that bit's index
// set the bit to 1 to record it as in use
}
}
Then, I suppose that code must be added to set the bit back to 0 when close=
()=20
is called, plus in accept() when new sockets are created for clients. I can=
't=20
think of any other points of interaction.
On Friday 07 February 2003 23:36, Marcel Holtmann wrote:
> Hi Alexandros,
>
> > Yes, but according to the Bluetooth spec, PSMs ranging from 0x1001
> > through 0xFFFF can be dynamically allocated. How can I choose one witho=
ut
> > "trial-and-error" (i.e. trying to bind() through all options until it
> > does not fail).
> >
> > For example, in IP protocols such as TCP/UDP, calling bind() with a por=
t
> > number equal to zero will cause the underlying implementation to
> > automatically select a free port which you may later find out using
> > getsockname(). This is why I tried this with L2CAP. I think it will be =
a
> > nice feature to have.
>
> nice idea.
>
> Max, what do you think about this?
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
--=20
To err is human, but to forgive is beyond the scope of the Operating System=
...
=C1=EB=DD=EE=E1=ED=E4=F1=EF=F2 =CA=E1=F1=F5=F0=DF=E4=E7=F2
=D0=E1=ED=E5=F0=E9=F3=F4=DE=EC=E9=EF =C8=E5=F3=F3=E1=EB=DF=E1=F2
=D4=EC=DE=EC=E1 =CC=E7=F7/=EA=FE=ED =C7/=D5, =D4=E7=EB=E5=F0=E9=EA=EF=E9=ED=
=F9=ED=E9=FE=ED & =C4=E9=EA=F4=FD=F9=ED
Alexandros Karypidis
University of Thessaly
Computer & Communications Engineering dept.
At 03:00 PM 2/18/2003, Marcel Holtmann wrote:
>Hi Max,
>
>> >I think about something like a special way to bind psm 0 and all
>> >incoming connections which are not associated with a bounded psm go to
>> >this application. So you can listen on all PSM with only one call.
>> >
>> >I want use this for one of my projects, but I can also work around this
>> >problem. So my question is if this makes sense to you and how much
>> >modifications in the L2CAP core may be needed ?
>> Modifications would be simple. But that feature doesn't make sense to me.
>
>I will try to explain for what it will be good. I want to do something
>which can be described like "L2CAP Forwarding Proxy over Ethernet". So
>the only special PSM is the one for SDP, all others (mainly over 0x1000)
>would be used dynamicly and forwarded to other devices over another
>medium like ethernet. For this I only want to have two listen calls, one
>for all not bound PSM's and one for SDP.
For that you should probably hack hcidump and forward L2CAP packets.
The problem with your approach is that connection to _any_ PSM will always
succeed even if that PSM is not active.
i.e.
1. accept()
2. try to forward
3. forward fails
4. close connection
That will confuse device that tries to connect to you because it will
assume that this PSM is in fact open but server closed connection
because of an error or something.
>How much we have to change for something like this?
l2cap_get_sock_by_psm() will have to be modified slightly.
But we're not going to do that ;-).
Max
Hi Max,
> >I think about something like a special way to bind psm 0 and all
> >incoming connections which are not associated with a bounded psm go to
> >this application. So you can listen on all PSM with only one call.
> >
> >I want use this for one of my projects, but I can also work around this
> >problem. So my question is if this makes sense to you and how much
> >modifications in the L2CAP core may be needed ?
> Modifications would be simple. But that feature doesn't make sense to me.
I will try to explain for what it will be good. I want to do something
which can be described like "L2CAP Forwarding Proxy over Ethernet". So
the only special PSM is the one for SDP, all others (mainly over 0x1000)
would be used dynamicly and forwarded to other devices over another
medium like ethernet. For this I only want to have two listen calls, one
for all not bound PSM's and one for SDP.
How much we have to change for something like this?
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 06:12 AM 2/17/2003, Marcel Holtmann wrote:
>Hi Max,
>
>> >What about a l2cap daemon like inetd ?
>> What about it ?
>
>I think about something like a special way to bind psm 0 and all
>incoming connections which are not associated with a bounded psm go to
>this application. So you can listen on all PSM with only one call.
>
>I want use this for one of my projects, but I can also work around this
>problem. So my question is if this makes sense to you and how much
>modifications in the L2CAP core may be needed ?
Modifications would be simple. But that feature doesn't make sense to me.
Max
Hi Max,
> >What about a l2cap daemon like inetd ?
> What about it ?
I think about something like a special way to bind psm 0 and all
incoming connections which are not associated with a bounded psm go to
this application. So you can listen on all PSM with only one call.
I want use this for one of my projects, but I can also work around this
problem. So my question is if this makes sense to you and how much
modifications in the L2CAP core may be needed?
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 07:26 PM 2/11/2003 +0200, Alexandros Karypidis wrote:
>An alternative which I may suggest is to define a socket option which may be
>set using setsockopt(), previously to calling bind(). Then, one might do this
>via:
>
> enable = 1;
> s = socket (...);
> setsockopt (s, SOL_SOCKET, BT_DYNAMIC_PSM, &enable, sizeof(enable));
> bind (s, ... );
Yeah, I think this would be an acceptable solution which doesn't brake current API.
Servers would have to enable DYNAMIC_PSM socket option and bind to PSM 0.
Why don't you go ahead implement that and send me a patch.
Max
At 06:22 PM 2/11/2003 +0200, Alexandros Karypidis wrote:
>On Monday 10 February 2003 22:49, Max Krasnyansky wrote:
>
>> [...]
>> Currently psm zero means that socket doesn't have PSM assigned to it.
>> bind(psm==0) means that application doesn't need PSM it's simply wants to
>> bind it's socket to some BD address. Which is exactly what L2CAP clients
>> need. So you proposing a change that will brake current bind() interface.
>> Well I guess it won't really break it but it will allocated PSM for all
>> client apps which doesn't make any sense.
>
>Ok, from another e-mail you sent in this thread I realize that I should not
>consider the PSM as the equivalent of a port number. CIDs are closer to that
>notion. Sorry, I've only started using Bluetooth for a week now and since IP
>is all I've ever known, I'm trying (perhaps too much) to find analogies.
That's perfectly ok. No need to apologize.
>> Why do you think we need dynamic PSM allocation ? l2cap already allocates
>> CIDs dynamically. I don't see why people would want the same thing for
>> PSMs.
>
>Well, assume that I need to run several server processes on a BT device. When
>each process launches, it needs to bind to a BDADDR:PSM entry point and
>accept() connections. Currently, I need to pre-assign this PSM value for each
>server process, as I have no other option.
>I would like to have a fixed
>BDADDR:PSM value for only one "special" server and have the others bind() to
>a BDADDR:I_DONT_CARE_PSM pair. Then, clients could inquire and obtain the
>PSMs of the other servers from the "special" server at the well-known entry
>point. It would be very much like a custom "service contact-address
>discovery" method.
Same problem (I don't really consider it a problem btw) exists in IP. Client has to
know server's port number. What if the PSM you picked for discovery service is used
by some other service ?
btw That discovery method is called SDP in Bluetooth. You don't have to invent you own.
>Basically, my problem is that when you have a device where you can
>install/remove services created from various manufacturers, there must exist
>a global agreement about PSM allocations. For example, suppose I install 2
>services which are manufactured from entities A and B. Now, A decides that it
>will receive connections on PSM 15000 and B chooses 16004. No problem. If by
>pure bad luck they had chosen the same PSM, I would be unable to run both
>concurrently.
That's exactly the reason why I don't consider it a problem in Bluetooth world.
There are very few applications exist for Bluetooth. The chances that two different
proprietary apps pick the same PSM are very slim. Vendors can apply and
reserve official PSM for well known apps. IP managed that pretty well.
>Ideally, each would obtain an arbitrary PSM when it was launched and publish its contact
>address via some other mechanism.
Actually I don't think that this is ideal :). Simply because you have to do yet another
connection to obtain PSM and Bluetooth connections already take too long (mostly baseband).
But I'm not against the idea of dynamic PSMs. We just have to decide what's the best way
to implement them.
Max
At 01:01 PM 2/11/2003 +0100, Marcel Holtmann wrote:
>Hi,
>
>> Now if people really want dynamic PSMs. We could introduce something like
>> bind(psm == 0xffff).
>
>I think this is not a good idea, because 0xffff is a valid PSM according
>to the spec.
And 10 is illegal ;-) (l2test uses 10)
>But what about bind it with PSM 0 and the listen call assign a dynamic
>PSM if it is bind with PSM 0 ?
Nop. That'd be wrong. Application has to obtain and register dynamic PSM
with SDP. Normally you have to do that after bind(). Because as soon as
you call listen() l2cap will start accepting incoming connections and put
them into sk accept queue. So connection may be accepted while app is doing
SDP registration. It will sit in accept queue and probably timeout right
when app call accept().
>What about a l2cap daemon like inetd ?
What about it ?
Max
On Tuesday 11 February 2003 14:01, Marcel Holtmann wrote:
> > Now if people really want dynamic PSMs. We could introduce something like
> > bind(psm == 0xffff).
>
> I think this is not a good idea, because 0xffff is a valid PSM according
> to the spec.
That is true. A simple problem that may arrise is that, suppose I write a
program which binds to PSM 0xffff. This is my PSM of choice and I am not
using BlueZ. However, if I try to port my program to a Linux architecture
which uses BlueZ, my program may compile but will not run correctly. BlueZ
would redirect it to another PSM ands clients would make connection attempts
to 0xffff which would fail.
> But what about bind it with PSM 0 and the listen call assign a dynamic
> PSM if it is bind with PSM 0 ?
That is what I was suggesting BUT: in IP, there is no way that a conneted
socket will ever return port==0. This is why it may be used as a special
value for bind().
In BT however, there is no "illegal" PSM value. I do not know this, but Max
mentioned that a client by default uses PSM zero if he does not specify one.
Indeed, in the test I mentioned in previous e-mails, using getsockname() will
return PSM 0 when you connect() without previously calling bind(). Plus, one
may explicitly bind() to PSM==0 and then connect() on the basis of current
behavior and instead get another PSM because of this change. Quoting Max:
"Currently psm zero means that socket doesn't have PSM assigned to it.
bind(psm==0) means that application doesn't need PSM it's simply wants to
bind it's socket to some BD address. Which is exactly what L2CAP clients need.
So you proposing a change that will brake current bind() interface. Well I
guess it won't really break it but it will allocated PSM for all client apps
which doesn't make any sense."
An alternative which I may suggest is to define a socket option which may be
set using setsockopt(), previously to calling bind(). Then, one might do this
via:
enable = 1;
s = socket (...);
setsockopt (s, SOL_SOCKET, BT_DYNAMIC_PSM, &enable, sizeof(enable));
bind (s, ... );
--
To err is human, but to forgive is beyond the scope of the Operating System...
Alexandros Karypidis
University of Thessaly
Computer & Communications Engineering dept.
On Monday 10 February 2003 23:13, Max Krasnyansky wrote:
> At 06:14 PM 2/8/2003 +0200, Alexandros Karypidis wrote:
> >BTW, it dawned on me that:
> >
> >1) connect() succeeds even if bind() wasn't previously called for the
> > client socket.
> >2) accept() also produces a new socket.
> >
> >I assumed that these operations evidently select a free PSM for the
> > sockets they use/produce. I could not find any such thing in the code
> > however (but I don't really know the BlueZ code).
> >
> >Then, I did the simple tests of:
> >
> >A. Calling getsockname() after a connect() with no previous bind()
> >B. Calling getsockname() after a accept()
> >
> >Case A reported PSM zero (0) !!! This is clearly a bug!
>
> No it's _not_.
> L2CAP PSM != TCP/UDP port. Although it may look like it's the same thing.
> It's not.
Ok, I get this now.
> [...]
> L2CAP PSM identifies a protocol or a service. CID identifies a logical
> channel. Since both client and server sockets use the _same_ protocol they
> must have the same PSM.
>
> TCP/UDP
> [client port]:[client IP] ---> [server port]:[server IP]
>
> L2CAP
> [service PSM]:[client CID] ---> [service PSM]:[server CID]
>
> See the difference ?
> Don't ask me why L2CAP designers didn't stick to common port concept.
> Bluetooth spec is full of "innovations" ;-).
Ok. The problem with this design from my viewpoint is that this design assumes
that a service always uses the same PSM. It assumes that there is no reason
why I would not want to run the service on PSM A at one point and some time
later on PSM B. More specifically, it assumes that I may not even care which
PSM I will be providing the service from, as I might use some "other means"
to coordinate this with clients (see my previous e-mail).
> So the current code is correct.
>
> Now if people really want dynamic PSMs. We could introduce something like
> bind(psm == 0xffff).
As Marcel already pointed out, this would not adhere to the specs... :(
I think dynamic PSMs are a good idea. The add capability. If only there is a
way to add them without "breaking" anything it may be worth doing so! Anyway,
I'm not trying to insist too much or anything -- I'm just throwing around
some ideas which make sense to me.
--
To err is human, but to forgive is beyond the scope of the Operating System...
Alexandros Karypidis
University of Thessaly
Computer & Communications Engineering dept.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Monday 10 February 2003 22:49, Max Krasnyansky wrote:
> [...]
> Currently psm zero means that socket doesn't have PSM assigned to it.
> bind(psm==0) means that application doesn't need PSM it's simply wants to
> bind it's socket to some BD address. Which is exactly what L2CAP clients
> need. So you proposing a change that will brake current bind() interface.
> Well I guess it won't really break it but it will allocated PSM for all
> client apps which doesn't make any sense.
Ok, from another e-mail you sent in this thread I realize that I should not
consider the PSM as the equivalent of a port number. CIDs are closer to that
notion. Sorry, I've only started using Bluetooth for a week now and since IP
is all I've ever known, I'm trying (perhaps too much) to find analogies.
> Why do you think we need dynamic PSM allocation ? l2cap already allocates
> CIDs dynamically. I don't see why people would want the same thing for
> PSMs.
Well, assume that I need to run several server processes on a BT device. When
each process launches, it needs to bind to a BDADDR:PSM entry point and
accept() connections. Currently, I need to pre-assign this PSM value for each
server process, as I have no other option. I would like to have a fixed
BDADDR:PSM value for only one "special" server and have the others bind() to
a BDADDR:I_DONT_CARE_PSM pair. Then, clients could inquire and obtain the
PSMs of the other servers from the "special" server at the well-known entry
point. It would be very much like a custom "service contact-address
discovery" method.
Basically, my problem is that when you have a device where you can
install/remove services created from various manufacturers, there must exist
a global agreement about PSM allocations. For example, suppose I install 2
services which are manufactured from entities A and B. Now, A decides that it
will receive connections on PSM 15000 and B chooses 16004. No problem. If by
pure bad luck they had chosen the same PSM, I would be unable to run both
concurrently. Ideally, each would obtain an arbitrary PSM when it was
launched and publish its contact address via some other mechanism.
Sorry for the long e-mail. I hope I've explained clearly what "bothers" me. :)
Hi,
> Now if people really want dynamic PSMs. We could introduce something like
> bind(psm == 0xffff).
I think this is not a good idea, because 0xffff is a valid PSM according
to the spec.
But what about bind it with PSM 0 and the listen call assign a dynamic
PSM if it is bind with PSM 0 ?
What about a l2cap daemon like inetd ?
Regards
Marcel
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
At 06:14 PM 2/8/2003 +0200, Alexandros Karypidis wrote:
>BTW, it dawned on me that:
>
>1) connect() succeeds even if bind() wasn't previously called for the client
>socket.
>2) accept() also produces a new socket.
>
>I assumed that these operations evidently select a free PSM for the sockets
>they use/produce. I could not find any such thing in the code however (but I
>don't really know the BlueZ code).
>
>Then, I did the simple tests of:
>
>A. Calling getsockname() after a connect() with no previous bind()
>B. Calling getsockname() after a accept()
>
>Case A reported PSM zero (0) !!! This is clearly a bug!
No it's _not_.
L2CAP PSM != TCP/UDP port. Although it may look like it's the same thing. It's not.
>Case B reported PSM 5000. This is the PSM where the server socket on which
>accept() was called was bound. So:
>
> clsock = accept (srvsock, ...);
>
>Produces a clsock whose PSM is equal to that of srvsock. I don't know if this
>is correct or not.
Yes it is correct.
L2CAP PSM identifies a protocol or a service. CID identifies a logical channel.
Since both client and server sockets use the _same_ protocol they must have the
same PSM.
TCP/UDP
[client port]:[client IP] ---> [server port]:[server IP]
L2CAP
[service PSM]:[client CID] ---> [service PSM]:[server CID]
See the difference ?
Don't ask me why L2CAP designers didn't stick to common port concept.
Bluetooth spec is full of "innovations" ;-).
So the current code is correct.
Now if people really want dynamic PSMs. We could introduce something like
bind(psm == 0xffff).
Max
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
>As I can see in lines 462-470 of core/l2cap.c, either the bind() fails if the
>PSM is in use, or it succeeds if it is free. I think this is where the code
>for the case l2_bdaddr->psm==0 should be added, changing the value to some
>free PSM.
>
>In this case, I am thinking of adding a 8192 byte array in l2cap.c, which
>records (per bit) the PSMs which are in use. This idea is similar to the way
>the kernel tracks the signals which should be masked per process. One would
>then:
>
> // 0xFFFF PSMs available = 8192 bytes
>#define MAX_PSM_NDX 8192
>// Record PSM use here in the following array:
>unsigned char psm_use[MAX_PSM_NDX];
>// Code which should be added to l2cap.c in l2cap_sock_bind()
>for (i=513; i<MAX_PSM_NDX; i++) { // start a 513 to skip reserved PSMs
> if (psm_use[i] < 255) { // a bit which is not set means there is a free PSM
> // bit ops to locate the first 0 bit
> // change the ls->psm value to that bit's index
> // set the bit to 1 to record it as in use
> }
>}
>
>Then, I suppose that code must be added to set the bit back to 0 when close()
>is called, plus in accept() when new sockets are created for clients. I can't
>think of any other points of interaction.
Currently psm zero means that socket doesn't have PSM assigned to it.
bind(psm==0) means that application doesn't need PSM it's simply wants to
bind it's socket to some BD address. Which is exactly what L2CAP clients need.
So you proposing a change that will brake current bind() interface. Well I guess
it won't really break it but it will allocated PSM for all client apps which
doesn't make any sense.
Why do you think we need dynamic PSM allocation ? l2cap already allocates CIDs
dynamically. I don't see why people would want the same thing for PSMs.
Max
BTW, it dawned on me that:
1) connect() succeeds even if bind() wasn't previously called for the clien=
t=20
socket.
2) accept() also produces a new socket.
I assumed that these operations evidently select a free PSM for the sockets=
=20
they use/produce. I could not find any such thing in the code however (but =
I=20
don't really know the BlueZ code).
Then, I did the simple tests of:
A. Calling getsockname() after a connect() with no previous bind()
B. Calling getsockname() after a accept()
Case A reported PSM zero (0) !!! This is clearly a bug!
Case B reported PSM 5000. This is the PSM where the server socket on which=20
accept() was called was bound. So:
clsock =3D accept (srvsock, ...);
Produces a clsock whose PSM is equal to that of srvsock. I don't know if th=
is=20
is correct or not.
On Saturday 08 February 2003 17:40, Alexandros Karypidis wrote:
> Hi again,
>
> First of all, perhaps we should move this discussion to bluez-devel.
>
> As I can see in lines 462-470 of core/l2cap.c, either the bind() fails if
> the PSM is in use, or it succeeds if it is free. I think this is where th=
e
> code for the case l2_bdaddr->psm=3D=3D0 should be added, changing the val=
ue to
> some free PSM.
>
> In this case, I am thinking of adding a 8192 byte array in l2cap.c, which
> records (per bit) the PSMs which are in use. This idea is similar to the
> way the kernel tracks the signals which should be masked per process. One
> would then:
>
> // 0xFFFF PSMs available =3D 8192 bytes
> #define MAX_PSM_NDX 8192
> // Record PSM use here in the following array:
> unsigned char psm_use[MAX_PSM_NDX];
> // Code which should be added to l2cap.c in l2cap_sock_bind()
> for (i=3D513; i<MAX_PSM_NDX; i++) { // start a 513 to skip reserved PSMs
> if (psm_use[i] < 255) { // a bit which is not set means there is a free
> PSM // bit ops to locate the first 0 bit
> // change the ls->psm value to that bit's index
> // set the bit to 1 to record it as in use
> }
> }
>
> Then, I suppose that code must be added to set the bit back to 0 when
> close() is called, plus in accept() when new sockets are created for
> clients. I can't think of any other points of interaction.
>
> On Friday 07 February 2003 23:36, Marcel Holtmann wrote:
> > Hi Alexandros,
> >
> > > Yes, but according to the Bluetooth spec, PSMs ranging from 0x1001
> > > through 0xFFFF can be dynamically allocated. How can I choose one
> > > without "trial-and-error" (i.e. trying to bind() through all options
> > > until it does not fail).
> > >
> > > For example, in IP protocols such as TCP/UDP, calling bind() with a
> > > port number equal to zero will cause the underlying implementation to
> > > automatically select a free port which you may later find out using
> > > getsockname(). This is why I tried this with L2CAP. I think it will b=
e
> > > a nice feature to have.
> >
> > nice idea.
> >
> > Max, what do you think about this?
> >
> > Regards
> >
> > Marcel
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Bluez-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-users
--=20
To err is human, but to forgive is beyond the scope of the Operating System=
...
=C1=EB=DD=EE=E1=ED=E4=F1=EF=F2 =CA=E1=F1=F5=F0=DF=E4=E7=F2
=D0=E1=ED=E5=F0=E9=F3=F4=DE=EC=E9=EF =C8=E5=F3=F3=E1=EB=DF=E1=F2
=D4=EC=DE=EC=E1 =CC=E7=F7/=EA=FE=ED =C7/=D5, =D4=E7=EB=E5=F0=E9=EA=EF=E9=ED=
=F9=ED=E9=FE=ED & =C4=E9=EA=F4=FD=F9=ED
Alexandros Karypidis
University of Thessaly
Computer & Communications Engineering dept.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
http://www.vasoftware.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel