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

Re: [bluetooth-dev] Inexplicable failed CRC check



Try setting
DEF_RFCOMM_MTU to 123

//Stefan

Dan Morris wrote:

> At one point I had ppp working fine with two Ericsson modules connecting
> over an old version of the stack; I'm trying to get the October 31 stack
> working now, and I'm having some problems that I can't seem to figure out...
> maybe someone has a suggestion or has dealt with a similar problem?
>
> The symptoms...
>
> On the server side, I get a perfectly pleasing :
>
> > ppp
> close_device
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyBT0
>
> On the client side, after connecting (successfully, according to
> /var/log/messages), I get :
>
> > ppp
> close_device
> Using interface ppp0
> Connect: ppp0 <--> /dev/ttyBT0
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb77c0548> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb77c0548> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb77c0548> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb77c0548> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb77c0548> <pcomp> <accomp>]
> sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb77c0548> <pcomp> <accomp>]
>
> etc., etc.  This is similar to a problem that people have had a few times on
> this list, which boiled down to just a ppp-options problem.  In fact the
> last time I had the same problem, it was just a ppp-options problem.  But
> here's the output from /var/log/messages on the server side, which repeats
> once each time the client sends a ConfReq (with unecessary data omitted) :
>
> cslab8e kernel: bt_receive_lower_stack : (4) (...)
> cslab8e kernel: L2CAP l2cap_receive_data :  got 55 bytes on hci_handle : 1
> cslab8e kernel: l2cap_receive_data :  (55) (...)
> cslab8e kernel: L2CAP l2cap_receive_data : New frame len:51 cid:64
> cslab8e kernel: L2CAP get_lcon : lcid 64 con_list.count = 1
> cslab8e kernel: process_frame :  (51) (...)
> cslab8e kernel: L2CAP get_upper: Try to retrieve psm 0x3
> cslab8e kernel: L2CAP get_upper: Actually got psm:0x3
> cslab8e kernel: rfcomm_receive_data: (51) (...)
> cslab8e kernel: RFCOMM rfcomm_receive_data: 51 bytes, our cid is 64
> cslab8e kernel: RFCOMM rfcomm_receive_data: Short UIH pkt received
>
> (here's the odd part)
>
> cslab8e kernel: crc_check: (2)
> cslab8e kernel:    0x03 0xef
> cslab8e kernel:   RFCOMM crc_check: CRC check OK
> cslab8e kernel:   RFCOMM rfcomm_receive_data: UIH on serv_channel 0
> cslab8e kernel:   RFCOMM process_mcc: Received a non supported command
> cslab8e kernel: L2CAP l2cap_send_data : hdl : 1, rcid : 64, len:8
> cslab8e kernel: l2cap_send_data :  (12) (...)
> cslab8e kernel:    0x08 0x00 0x40 0x00 0x03 0xef 0x09 0x11 0x03 0x7f 0x70 0xaa
> cslab8e kernel: BT DATA <--|X|     17
> cslab8e kernel:
> cslab8e kernel: bt_write_lower_driver : (17)
> cslab8e kernel:    0x02 0x01 0x20 0x0c 0x00 0x08 0x00 0x40 0x00 0x03 0xef 0x09
>                                    0x11 0x03 0x7f 0x70
> cslab8e kernel:    0xaa
> cslab8e kernel: BT DATA -->|X|      8
>
> "Non supported command"... hmmm... let's see what's going on on the client
> side (again, unecessary data omitted)...
>
> btlinux kernel: l2cap_send_data :  (55) (...)
> btlinux kernel: bt_write_lower_driver : (60) (...)
> btlinux kernel:           RFCOMM rfcomm_send_data: sent 47 bytes
> btlinux kernel: bt_receive_lower_stack : (8)
> btlinux kernel:    0x04 0x13 0x05 0x01 0x01 0x00 0x05 0x00
> btlinux kernel: bt_receive_lower_stack : (17)
> btlinux kernel:    0x02 0x01 0x20 0x0c 0x00 0x08 0x00 0x40 0x00 0x03 0xef 0x09
>                    0x11 0x03 0x7f 0x70 0xaa
> btlinux kernel: L2CAP l2cap_receive_data :  got 12 bytes on hci_handle : 1
> btlinux kernel: l2cap_receive_data :  (12)
> btlinux kernel:    0x08 0x00 0x40 0x00 0x03 0xef 0x09 0x11 0x03 0x7f 0x70 0xaa
> btlinux kernel:     L2CAP l2cap_receive_data : New frame len:8 cid:64
> btlinux kernel: process_frame :  (8)
> btlinux kernel:    0x03 0xef 0x09 0x11 0x03 0x7f 0x70 0xaa
> btlinux kernel:     L2CAP get_upper: Try to retrieve psm 0x3
> btlinux kernel:     L2CAP get_upper: Actually got psm:0x3
> btlinux kernel: rfcomm_receive_data: (8)
> btlinux kernel:    0x03 0xef 0x09 0x11 0x03 0x7f 0x70 0xaa
> btlinux kernel:           RFCOMM rfcomm_receive_data: 8 bytes, our cid is 64
> btlinux kernel:           RFCOMM rfcomm_receive_data: Short UIH pkt received
> btlinux kernel: crc_check: (2)
> btlinux kernel:    0x03 0xef
> btlinux kernel: BT SYS:  ERROR :crc_check: CRC check failed
>
> So 8 bytes gets to RFCOMM... the same 8 bytes that left the other side...
> but the CRC check fails... wazzup with that?  Any hints as to why the CRC
> check fails, which I imagine is why data is not getting up to ppp to allow
> the ppp connection to complete?
>
> Thanks for any information that anyone can provide...
>
> -Dan
>
> Dan Morris
> http://techhouse.brown.edu/dmorris
>
> Tiqit Computers
> http://www.tiqit.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
> the body of a message to majordomo@xxxxxxx.com

-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com