Re: Disconnect reason message Nimble / BTShell
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 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 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 >>>
Re: Disconnect reason message Nimble / BTShell
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 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 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 >>
Re: Disconnect reason message Nimble / BTShell
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 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 >
Re: Disconnect reason message Nimble / BTShell
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
Disconnect reason message Nimble / BTShell
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. 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
