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

[Mattias Ågren <mattias@xxxxxxx.com>]

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