The MIC stands for “message integrity check”. If you are using Link Layer encryption, which is seems like you are given some of the output you displayed in your email (supervision_timeout=256 encrypted=1 authenticated=1 bonded=1), there is a 4-byte MIC appended to every PDU sent by the link layer. If the MIC check fails the connection gets terminated with that error code. I agree with Chris: this is very disturbing. I do believe there were some issues that got fixed in nimble related to this so it might be in a merged PR that you are not currently using.
> On Feb 5, 2019, at 12:22 PM, Copper Dr <copp...@gmail.com> wrote: > > The 573 is interesting also as my application has nothing to do with a mic. > I'm writing and receiving notifications. > > 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. > > 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 >>
