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 > >
