[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] Line collision between SDP and RF_COMM
> a litter doubt about this. 63 is max channels for RF_comm connection
> for each line.
Well, one line = one DLCI. The current implementation doesn't work as it
should. The main problem is that we have assigned the line for ONE
rfcomm session (multiplexer), it should really be assigned in the DLCI object.
This mean that we can't have multiple lines in the same multiplexer.
Some months ago I redesigned the rfcomm layer but unfourtanly I didn't
released it and now there is a lot of other changed which means that
the merge will take some time :(. The line is assigned when a client
connects (when we got connect_ind from the l2cap layer) and if the
client then try to send another SABM message for another DLCI the
later one will not get a line on the serverside. This is behaviour
is fine when running an accesspoint which only use one of the DLCI:s
and as a result only one of the lines but other applications maybe
need to connect multiple lines between the units.
I saw some earlier posts about problems with running multiple
DLCI:s between two units. When you are using rf_conn it should
be no problem as each rf_conn command will result in another
l2cap channel and therefore a new multiplexer (we are only
running one line / multiplexer). But if you use another stack
which are using the same l2cap and rfcomm session to connect
another DLCI (which is the correct behaviour) we probably have
a potential problem as we already
set the first line for the first DLCI and calling bt_register_rfcomm
in bluetooth.c will result in a line busy (as the line is set in the
multiplexer object and not in the DLCI).
I'll see if I have some spare time to merge the new code later
this week. By the way I saw in the specs that we can only
have up to 60 open emulated ports (62, 63 reserved) :).
> > MAX_NBR_OF_CONNECTIONS is however used to limit number of
> > basebandconnections. But as you say it will probably be a
> > waste of resources to have more than 7 lines at the same time.
> It will cause another collision here if you set
> MAX_NBR_CONNECTIONS > 7
> because we just got 7 ttyBTX devices.
True :) and there is no hardware that supports more than 7 slaves either ;).
I saw that we don't send a proper reply when we running out of lines either.
Just a comment: fixme :).
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org