Looks like Chris and my responses crossed paths a bit here. However, I want to clarify a few things:
1) All packets sent get sent with a 24-bit CRC. This includes all forms of packets sent by the controller (advertisements and data channel PDU’s). 2) The MIC only gets appended to data channel PDU’s and only when the connection is encrypted (and not for empty PDU’s but that is a bit esoteric). A corrupt packet should fail the CRC check and get discarded. The CRC is checked before a MIC is checked. While it is possible to get a false positive it is extremely unlikely (one in millions). This is why any MIC failure causes a connection to get terminated: it implies that one side of the correction does not have the expected security material or there is a bad actor. > On Feb 5, 2019, at 1:08 PM, Christopher Collins <ch...@runtime.io> wrote: > > On Tue, Feb 05, 2019 at 03:22:52PM -0500, Copper Dr wrote: >> The 573 is interesting also as my application has nothing to do with a mic. >> I'm writing and receiving notifications. > > MIC is short for Message Integrity Check. Every packet that gets sent > contains a MIC, so this error could result from any given receive. > However, a corrupt packet with an invalid MIC should not cause the > connection to terminate; the packet should just get retransmitted. I am > not really sure what would cause the controller to terminate a > connection with this error code. > >> >> I'm doing a >> gatt-write conn=2 no_rsp=1 attr=25 value=10:01:00:00:01:10:02:10:03:53:56 >> then waiting for a response >> notification rx event; attr_handle=25 indication=0 len=13 >> data=0x10:0x01:0x00:0x00:0x01:0x10:0x02:0x00:0x00:0x10:0x03:0xa6:0x03 >> >> These are the config values I built with. I disabled debug and logging and >> enabled all the BLE feature sets. I found these out looking over a webpage >> about how to test all the code paths in NimBLE. I figured out where they >> are documented now and should revisit. I have a large list of errors or >> documentation items that need added that I plan to take on. > > That's great! > > Chris > >> >> syscfg.vals: >> BLE_EDDYSTONE: 1 >> BLE_EXT_ADV: 1 >> BLE_EXT_ADV_MAX_SIZE: 1650 >> BLE_HCI_EVT_BUF_SIZE: 257 >> BLE_HS_DEBUG: 0 >> BLE_L2CAP_COC_MAX_NUM: 2 >> BLE_LL_CFG_FEAT_LE_2M_PHY: 1 >> BLE_LL_CFG_FEAT_LE_CODED_PHY: 1 >> BLE_LL_CFG_FEAT_LL_PRIVACY: 1 >> BLE_LL_CONN_INIT_MAX_TX_BYTES: 251 >> BLE_LL_DIRECT_TEST_MODE: 1 >> BLE_MAX_CONNECTIONS: 32 >> BLE_MONITOR_RTT: 1 >> BLE_MONITOR_RTT_BUFFER_SIZE: 2048 >> BLE_MULTI_ADV_INSTANCES: 5 >> BLE_SM_BONDING: 1 >> BLE_SM_LEGACY: 1 >> BLE_SM_SC: 1 >> BLE_STORE_MAX_BONDS: 32 >> CONSOLE_UART_BAUD: 460800 >> CONSOLE_MAX_INPUT_LEN: 4096 >> CONSOLE_UART_TX_BUF_SIZE: 1024 >> CONSOLE_UART_RX_BUF_SIZE: 1024 >> CONSOLE_ECHO: 0 >> CONSOLE_RTT_INPUT_POLL_INTERVAL_MAX: 10 >> CONSOLE_TICKS: 0 >> LOG_LEVEL: 255 >> LOG_CLI: 0 >> CONFIG_CLI: 0 >> CONFIG_CLI_DEBUG: 0 >> METRICS_CLI: 0 >> STATS_CLI: 0 >> STATS_NAMES: 0 >> >> On Tue, Feb 5, 2019 at 3:02 PM Christopher Collins <ch...@runtime.io> wrote: >> >>> Hi Fred, >>> >>> On Tue, Feb 05, 2019 at 02:25:43PM -0500, Copper Dr wrote: >>>> I'm trying to figure out how to decode these disconnections. >>>> >>>> Reason 688 (0x02B0) and 573 (0x023D) >>>> >>>> I checked >>>> >>> http://mynewt.apache.org/latest/network/docs/ble_hs/ble_hs_return_codes.html >>>> and the disconnect code does not make any sense. >>>> >>>> The 573 is the one I'm really interested in it happened just before >>> 65,535 >>>> commands were sent and is repeatable. >>> >>> I agree - 688 (0x2b0) does not make sense. This is not a valid error >>> code, so there must be some memory corruption or some other bug at play >>> here. >>> >>> As you noticed, 573 (0x23d) is a legitimate error code: >>> BLE_ERR_CONN_TERM_MIC. I don't know if there is a relation to the >>> number 65535, but that would be an interesting bug! I will let one of >>> the controller experts chime in. >>> >>> Chris >>> >>>> >>>> >>>> disconnect; reason=688 handle=1 our_ota_addr_type=0 >>>> our_ota_addr=01:02:03:04:05:06 our_id_addr_type=0 >>>> our_id_addr=01:02:03:04:05:06 peer_ota_addr_type=1 >>>> peer_ota_addr=cb:a9:46:52:45:44 peer_id_addr_type=1 >>>> peer_id_addr=cb:a9:46:52:45:44 conn_itvl=40 conn_latency=0 >>>> supervision_timeout=256 encrypted=1 authenticated=1 bonded=1 >>>> >>>> disconnect; reason=573 handle=2 our_ota_addr_type=0 >>>> our_ota_addr=01:02:03:04:05:06 our_id_addr_type=0 >>>> our_id_addr=01:02:03:04:05:06 peer_ota_addr_type=1 >>>> peer_ota_addr=cb:a9:42:31:30:30 peer_id_addr_type=1 >>>> peer_id_addr=cb:a9:42:31:30:30 conn_itvl=40 conn_latency=0 >>>> supervision_timeout=256 encrypted=1 authenticated=1 bonded=1 >>>> >>>> >>>> Thanks, >>>> >>>> Fred Angstadt >>>
