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

Re: [bluetooth-dev] Bug fix in rfcomm.c



Hi,

I am now trying to do the same thing using Ericsson bluetooth modules instead of the HCI emulation.
During HCI initialisation, the HCI_WRITE_SCAN_ENABLE command is not sent to the BT module on the server side, so the module never goes in PAGE_SCAN mode.
Adding a write_scan_enable(3) after hci_init() in the test_bench on the server side results in a successfull connection.

brgds

David.

Mattias Ågren wrote:

> Hi,
> this problem is known and will be fixed, until then a new tar ball with a temp fix for this including lots of other bugfixes will hopefully be released today. (we have lots of people on vacation and until next week 'support' will be a little slow...)
>
> brgds
> Mattias Ågren,
> AXIS Communications AB
>
> > -----Original Message-----
> > From: David LIBAULT [mailto:dli@xxxxxxx.fr]
> > Sent: Tuesday, July 25, 2000 4:02 PM
> > To: bluetooth-dev@xxxxxxx.com
> > Subject: [bluetooth-dev] Bug fix in rfcomm.c
> >
> >
> > Hi all,
> >
> > I am using bluetooth_20000607.tgz from developer.axis.com. I have
> > modified the test_bench.c so that it works with the rfcomm stack api
> > (probably test_bench.c has not been updated yet...), and
> > built the stack
> > in user mode using hci emulation.
> > Everything builds properly.
> >
> > One test_bench works as a server on /dev/ttyS0 and another
> > one works as
> > a client on /dev/ttyS1. These two ports are linked together
> > using a null
> > modem cable.
> > The client tries to setup an rfcomm channel and send 1024
> > bytes through
> > that channel.
> >
> > After the L2CAP  and RFCOMM connections open, the client tries to send
> > the 1024 bytes packet. This is the end of the debug output from the
> > client :
> >
> > Sending 1024 bytes of data
> >           RFCOMM rfcomm_send_data: Will try to send 1024 bytes
> >           RFCOMM rfcomm_send_data 668 bytes
> >     L2CAP l2cap_send_data : hdl : 0, rcid : 64, len:673
> >           RFCOMM rfcomm_send_data 356 bytes
> >     L2CAP l2cap_send_data : hdl : 0, rcid : 64, len:361
> >     L2CAP l2cap_receive_data : 10 bytes, hci_handle : 0
> >     L2CAP l2cap_receive_data : New frame len:6 cid:1
> >     L2CAP l2cap_receive_data : Signal data !
> >     L2CAP signal_handler : received 6 bytes first cmd->len=2
> >     L2CAP signal_handler : Single command
> >     L2CAP signal_handler : got l2cap packet (2 bytes) with ID : 2
> >     L2CAP signal_handler : Got response : 0x1 id:2
> >     L2CAP signal_handler : Got command reject -     L2CAP Not
> > recognized
> > cmd reject reason
> >
> > The server complains because the MTU has been exceeded :
> >
> >    L2CAP l2cap_receive_data : 677 bytes, hci_handle : 0
> >     L2CAP get_lcon : lcid 64 con_list.count = 1
> >     L2CAP l2cap_cmdrej : Signalling MTU exceeded
> >     L2CAP l2cap_receive_data : 339 bytes, hci_handle : 0
> >     L2CAP l2cap_receive_data : New frame len:361 cid:64
> >     L2CAP l2cap_receive_data : 365 bytes, hci_handle : 0
> >     L2CAP get_lcon : lcid 64 con_list.count = 1
> >           RFCOMM rfcomm_receive_data: 361 bytes, our cid is 64
> >           RFCOMM rfcomm_receive_data: Long UIH packet received
> >           RFCOMM rfcomm_receive_data: long packet length 164
> >           RFCOMM crc_check: check_sum = 0x70
> >           RFCOMM crc_check : calc fcs 0xcf
> >           RFCOMM crc_check: CRC OK :-)
> >           RFCOMM rfcomm_receive_data : UIH on serverchannel 0
> >           RFCOMM parse_mcc: Received Remote line status
> >
> > Note that the RFCOMM_MTU is defined as 672.
> > It looks like the segmentation of packets does not work properly...
> > In line 890 of rfcomm.c the calculation of the size of the packet
> > segment does not look quit robust yet (see the FIXME comment).
> >
> > These are my questions :
> >
> > - Has anyone already experienced this kind of problem in the same
> > conditions and/or in other conditions ?
> > - Has anyone fixed the problem already ?
> > - Can I just fix the problem and distribute a patch ?
> >
> > Thank you all.
> >
> > David.
> >