Re: [Bluez-users] How do I obtain a free PSM automatically?

Re: [Bluez-users] How do I obtain a free PSM automatically?

[Stephen Crane]

On Fri, 2003-02-07 at 21:25, Marcel Holtmann wrote:
> Hi Alexandros,
> 
> > I was assuming that the setting the psm field to zero would get you a 
> > dynamically assigned free PSM on the local host:
> > 
> >   addr.l2_family = AF_BLUETOOTH;
> >   bacpy(&addr.l2_bdaddr, BDADDR_ANY);  
> >   addr.l2_psm = htobs(0);
> > 
> > Calling bind() for this address succeeds.
> > Calling listen() afterwards fails and perror() gives: "Invalid argument"
> 
> you can't listen on PSM 0, because such PSM did not exists. You have to
> choose one.

It would be nice if it had the expected semantics (i.e., those of IP sockets).
I think this is a bug.

In the meantime, here is some code:

   for (;;) {
      while (psm++ < 0xffff)
         if ((psm & 0x0001) && !(psm & 0x0100))
            break;
      if (psm == 0x10000) {
         // no resources
         close(s);
         return -EBUSY;
      }
      addr.l2_psm = htobs(psm);
      if (0 == bind(s, (struct sockaddr *)&addr, sizeof(addr)))
         break;
      if (errno != EADDRINUSE) {
         int e = -errno;
         close(s);
	 return e;
      }
   }

Enjoy,
Steve
-- 
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

Re: [Bluez-users] How do I obtain a free PSM automatically?

[Alexandros Karypidis]

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
> Bluez-users@lists.sourceforge.net
> 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.

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Alexandros Karypidis]

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
> > Bluez-users@lists.sourceforge.net
> > 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Max Krasnyansky]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Alexandros Karypidis]

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.

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Maksim Yevmenkin]

Alexandros Karypidis wrote:
> 
> 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().

there is a reason why clients use PSM 0. consider the following example:

1) servers listens on PSM "X"
2) *two* clients want to connect.
3) client1: creates socket and bind()s it to PSM "X" -> OK
4) client2: creates socket and bind()s it to PSM "X" -> EBUSY (or INUSE)

however in real life this is a valid scenario. you may have many
channels on the same PSM. PSM 0 means "any PSM", i think Bluetooth
spec even says so, when it discusses L2CAP connectionless traffic,
i.e. L2CA_Enable_Connectionless_Traffic.

> 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, ... );

something like that probably will work. however i still do not see
why you need this. PSM stands for "Protocol/Service Multiplexor",
so think of it as "well known port". currently all clients look for
services they understand. so even if you write some service and
give it new PSM no existing client will ever look for it (because
existing clients do not know how to use it). bottom line: you have
to write both: server and client, and since you control both ends
it just plain easy to agree on PSM.

thanks,
max

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Max Krasnyansky]

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

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Max Krasnyansky]

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

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Max Krasnyansky]

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

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Max Krasnyansky]

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

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Alexandros Karypidis]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Max Krasnyansky]

>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

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Alexandros Karypidis]

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. :)

Re: [Bluez-devel] How do I obtain a free PSM automatically?

[Maksim Yevmenkin]

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.
> 
> > 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.

life sucks, isn't it? :) http://www.iana.org/ is in control of "well
known"
IP ports, but nothing prevents you from running HTTP server on port 23
and telnet on port 80. i presume http://www.bluetooth.org/ or something
like this will assign PSM to different manufacturers. but again there is
no way you can control decisions made by the particular manufacturer.
everybody should play nice :)

i agree you have control over the IP ports (most of the time). but
nobody
will run public web server on any port other then 80 (or 443). you can
not
run two *different* web servers bound to the same IP and port (IP
aliases
and virtual servers do not count :)

if you have more then one BT device, you can bound each service to
particular
device on the same PSM.

thanks,
max

Re: [Bluez-devel] How do I obtain a free PSM automatically?

[Max Krasnyansky]

At 10:04 AM 2/11/2003 -0800, Maksim Yevmenkin wrote:
>> 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.
>
>life sucks, isn't it? :) http://www.iana.org/ is in control of "well known"
>IP ports, but nothing prevents you from running HTTP server on port 23
>and telnet on port 80. i presume http://www.bluetooth.org/ or something
>like this will assign PSM to different manufacturers. but again there is
>no way you can control decisions made by the particular manufacturer.
>everybody should play nice :)
>
>i agree you have control over the IP ports (most of the time). but nobody
>will run public web server on any port other then 80 (or 443). you can not
>run two *different* web servers bound to the same IP and port (IP aliases
>and virtual servers do not count :)

You can really tell if person has "ALL IP" mentality :).
I'm that kind of person myself. 

btw Originally PSM was supposed to be assigned by Bluetooth SIG. ie. Just like
well known IP port. And then some "clever" people came up with the idea of dynamic
PSMs (probably the same people decided that PSM field needs 'an extension 
bit' and made half of the PSMs space invalid). Unfortunately those "clever" 
people didn't realize that [dynamic PSM]:[dynamic CID] is stupid. 
When you add [dynamic DLCI] op top for RFCOMM sessions it becomes ridiculous :).
And I'm not even sure what to call it when you add [dynamic OBEX channel] ;-)

Anyhow, we may have to provide dynamic PSM and DLCI service just because it may 
become a common thing on other platforms and stacks.

Max
 

Re: [Bluez-devel] How do I obtain a free PSM automatically?

[Maksim Yevmenkin]

Max Krasnyansky wrote:
> 
> At 10:04 AM 2/11/2003 -0800, Maksim Yevmenkin wrote:
> >> 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.
> >
> >life sucks, isn't it? :) http://www.iana.org/ is in control of "well known"
> >IP ports, but nothing prevents you from running HTTP server on port 23
> >and telnet on port 80. i presume http://www.bluetooth.org/ or something
> >like this will assign PSM to different manufacturers. but again there is
> >no way you can control decisions made by the particular manufacturer.
> >everybody should play nice :)
> >
> >i agree you have control over the IP ports (most of the time). but nobody
> >will run public web server on any port other then 80 (or 443). you can not
> >run two *different* web servers bound to the same IP and port (IP aliases
> >and virtual servers do not count :)
> 
> You can really tell if person has "ALL IP" mentality :).
> I'm that kind of person myself.

i was trying to explain it in "IP terms" since orignal post
was about comparing IP and Bluetooth :)  i'm trying to keep
my mind open :)
 
> btw Originally PSM was supposed to be assigned by Bluetooth SIG. ie. Just like
> well known IP port. And then some "clever" people came up with the idea of dynamic
> PSMs (probably the same people decided that PSM field needs 'an extension
> bit' and made half of the PSMs space invalid). Unfortunately those "clever"
> people didn't realize that [:[dynamic CID] is stupid.

well there is nothing *really* wrong with extenstion. i think
it is just a safeguard. however i think this is way to optimistic.
i just can't imagine that Bluetooth can ever use up all 65536
or even 32768) PSMs. IP has lived with 65536 ports since the
day one. i missed "dynamic PSM" stuff. was it somewhere is spec?

> When you add [dynamic DLCI] op top for RFCOMM sessions it becomes ridiculous :).
> And I'm not even sure what to call it when you add [dynamic OBEX channel] ;-)

whoa! i missed them too :) what exactly dynamic DLCI and 
dynamic OBEX channel mean? does it mean that user select
channel (DLCI) and give to server app? or does it mean
that server app itself somehow figures out available DCLI
and get it? 

and what the hell is dynamic OBEX channel? OBEX works
over RFCOMM so it needs RFCOMM channel (DLCI), right?

> Anyhow, we may have to provide dynamic PSM and DLCI service just because it may
> become a common thing on other platforms and stacks.

examples please :) what platforms/stacks do support these
features? how they use it? 

thanks,
max

Re: [Bluez-devel] How do I obtain a free PSM automatically?

[Max Krasnyansky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; CHARSET=us-ascii, Size: 3403 bytes --]

At 12:01 PM 2/11/2003 -0800, Maksim Yevmenkin wrote:
>> btw Originally PSM was supposed to be assigned by Bluetooth SIG. ie. Just like
>> well known IP port. And then some "clever" people came up with the idea of dynamic
>> PSMs (probably the same people decided that PSM field needs 'an extension
>> bit' and made half of the PSMs space invalid). Unfortunately those "clever"
>> people didn't realize that [:[dynamic CID] is stupid.
>
>well there is nothing *really* wrong with extenstion. 
In Bluetooth case there is :). They simply reduced available number of PSMs by half.
Current spec does not permit PSM field to be longer than two bytes.
Actually it's not even half it a quarter because first bit of the second byte must 
always be 0. So only 16384 out of 65535 are available.

>i think it is just a safeguard. however i think this is way to optimistic.
>i just can't imagine that Bluetooth can ever use up all 65536
>or even 32768) PSMs. IP has lived with 65536 ports since the
>day one. 
My point exactly.

>i missed "dynamic PSM" stuff. was it somewhere is spec?
Here is PSM definition from 1.1 spec
----
Protocol/Service Multiplexor (PSM): 2 octets (minimum)
The PSM field is two octets (minimum) in length. The structure of the PSM
field is based on the ISO 3309 extension mechanism for address fields. All
PSM values must be ODD, that is, the least significant bit of the least signifi-cant
octet must be ’1’. Also, all PSM values must be assigned such that the
least significant bit of the most significant octet equals ’0’. This allows the
PSM field to be extended beyond 16 bits. PSM values are separated into
two ranges. Values in the first range are assigned by the Bluetooth SIG and
indicate protocols. The second range of values are dynamically allocated
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and used in conjunction with the Service Discovery Protocol (SDP). The
dynamically assigned values may be used to support multiple implementa-tions
of a particular protocol

PSM value Description
0x0001   Service Discovery Protocol
0x0003   RFCOMM
0x0005   Telephony Control Protocol
<0x1000 RESERVED
[0x1001-0xFFFF] DYNAMICALLY ASSIGNED
        ^^^^^^^^^^^^^^^^^^^
----
btw Fellas according to the extension bit rules 0xFFFF is illegal PSM. 
0xfeff is the last legal one.

>> When you add [dynamic DLCI] op top for RFCOMM sessions it becomes ridiculous :).
>> And I'm not even sure what to call it when you add [dynamic OBEX channel] ;-)
>
>whoa! i missed them too :) what exactly dynamic DLCI and 
>dynamic OBEX channel mean? does it mean that user select
>channel (DLCI) and give to server app? or does it mean
>that server app itself somehow figures out available DCLI
>and get it? 
Same as PSM. Server allocates RFCOMM channel number dynamically and registers it with SDP.

>and what the hell is dynamic OBEX channel? OBEX works
>over RFCOMM so it needs RFCOMM channel (DLCI), right?
OBEX has Connection Id and stuff. So it also does it's own multiplexing.

>> Anyhow, we may have to provide dynamic PSM and DLCI service just because it may
>> become a common thing on other platforms and stacks.
>
>examples please :) what platforms/stacks do support these features? 
I believe Widcomm BTW supports it.
And if I remember correctly Palm OS stack has something like that too.

>how they use it? 
Server dynamically allocates PSM and registers it with SDP.

Max

Re: [Bluez-devel] Re: [Bluez-users] How do I obtain a free PSM automatically?

[Max Krasnyansky]

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