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

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