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

[bluetooth-dev] Inexplicable failed CRC check



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