[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] Line collision between SDP and RF_COMM



If you are running bttest you can always use lcid_disconnect to
disconnect the sdp_link.

Best Regards
Anders Johansson

> -----Original Message-----
> From: Ran Zhou [mailto:Ran.Zhou@xxxxxxx.uk]
> Sent: Monday, February 04, 2002 6:26 PM
> To: Anders Torbjörn Johansson
> Cc: Bluetooth-dev
> Subject: RE: [bluetooth-dev] Line collision between SDP and RF_COMM
> 
> 
> On Mon, 4 Feb 2002 17:44:03 +0100  Anders_Torbjörn_Johansson 
> <anders.t.johansson@xxxxxxx.com> wrote:
> 
> > Hello Ran,
> > 
> > 
> > > 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.
> Hi, Anders
> Is't possible to put SDP disconnection functinality first.
> 
> Many Thanks
> 
> Ran
> > 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 :).
> > 
> > Best Regards
> > Anders Johansson
> >  
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe 
> bluetooth-dev" in
> > the body of a message to majordomo@xxxxxxx.com
> 
> ----------------------
> Ran Zhou
> Centre for Communications Research
> University of Bristol
> c/o: PACT
> University Gate                            Tel:  +44 117 915 1278
> Park Row                                   Fax:  +44 117 954 5206
> Bristol BS1 5UB                          
> United Kingdom                             Email: 
> Ran.Zhou@xxxxxxx.uk
> 
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com