You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by GitBox <gi...@apache.org> on 2019/11/14 18:56:16 UTC

[GitHub] [mynewt-nimble] haukepetersen opened a new pull request #650: host/l2cap_coc: fix receiving of frames with size 1

haukepetersen opened a new pull request #650: host/l2cap_coc: fix receiving of frames with size 1
URL: https://github.com/apache/mynewt-nimble/pull/650
 
 
   In the current code, receiving L2CAP COC frames is broken for a number of specific packet sizes `(n * BLE_L2CAP_COC_MPS) - 1`, e.g. for an L2CAP `MPS` value of `250`, all packets with size `249`, `499`, `749`, ... will not be received correctly. 
   
   Reason (as I analyzed it so far): the call to `ble_hs_mbuf_pullup_base()` in the beginning of `ble_l2cap_coc_rx_fn()` expects the incoming frame to have at least 2 bytes of payload. However, continuation frames might have a payload of 1 byte, leading to the `ble_hs_mbuf_pullup_base()` call failing and thereby to error-exit the whole receive function. This way, the actually correct l2cap payload is never appended to the receive buffer and so the packet in the reassembly buffer is never completed...
   
   This PR proposes a crude fix to this problem, by only calling `ble_hs_mbuf_pullup_base()` in case the received payload is >= 2. I verified the fix in my raw-l2cap-flooding setup -> with the fix I can successfully transfer those payloads that lead to frames with size 1.
   
   However, I don't quite comprehend what `ble_hs_mbuf_pullup_base()` is actually good for, so I don't now if this proposed fix has any bad side effects. So please review careful and let me know about better approaches to fix this :-)

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services