Re: issue with missing log api
Hi Chris,
that does the trick! Although I now run into a different
issue:
Compiling apps/s/src/events.cc
Compiling apps/s/src/console.cc
Error: In file included from
repos/apache-mynewt-core/kernel/os/include/os/os.h:132:0, from
apps/s/src/events.h:7, from apps/s/src/events.cc:1:
repos/apache-mynewt-core/kernel/os/include/os/os_mutex.h: In function
'os_error_t os_mutex_get_level(os_mutex*)':
repos/apache-mynewt-core/kernel/os/include/os/os_mutex.h:122:16: error:
invalid conversion from 'uint16_t {aka short unsigned int}' to
'os_error_t {aka os_error}' [-fpermissive] return mu->mu_level;
^~~~
I guess not a lot of folks check for C++ compatibility. But that's a bug I can
fix myself ;)
Thanks a lot,
Markus
On Tue, 5 Feb 2019 07:32:04 -0800
Christopher Collins wrote:
> Hi Markus,
>
> On Mon, Feb 04, 2019 at 08:34:50PM -0800, markus wrote:
> > I updated to the latest master from github (4fedf428) and now my
> > projects break with the error message:
> >
> > Building target targets/s
> > Error: Unsatisfied APIs detected:
> > * log, required by: sys/log/modlog
>
> To solve this issue without enabling logging, you can add
> `@apache-mynewt-core/sys/log/stub` to your app's list of dependencies
> (`pkg.deps`). This satisfies the `log` API requirement without
> pulling in any actual logging functionality.
>
> This is not a great fix--it does the job, but it is a hassle for the
> developer. A solution that does not require you to modify a `pkg.yml`
> file would be much better. I have a few ideas, but haven't
> implemented anything yet. We should definitely do something about
> this problem before the next release so others don't struggle with
> this one. Thanks for raising this issue.
>
> You are seeing this issue because logging has been integrated
> into several more core packages. I think most projects already use a
> log package and are unaffected, but that is just an assumption.
>
> By the way, the `newt target revdep ` command is a useful
> tool for debugging issues like this. In this case, it will tell you
> which package(s) depends on modlog.
>
> > Since I neither need nor want any logging in my app I figured I'll
> > turn it off by setting
> >
> > NEWT_FEATURE_LOGCFG: 0
> >
> > in syscfg.yml - unfortunately this results in a segfault in the newt
> > tool. Updating that to the latest master (bc272f6e) has the same
> > result.
>
> The `NEWT_FEATURE_[...]` settings should not be overridden. I
> probably would have tried the same thing :).
>
> Chris
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
Re: issue with missing log api
Hi Markus, On Mon, Feb 04, 2019 at 08:34:50PM -0800, markus wrote: > I updated to the latest master from github (4fedf428) and now my > projects break with the error message: > > Building target targets/s > Error: Unsatisfied APIs detected: > * log, required by: sys/log/modlog To solve this issue without enabling logging, you can add `@apache-mynewt-core/sys/log/stub` to your app's list of dependencies (`pkg.deps`). This satisfies the `log` API requirement without pulling in any actual logging functionality. This is not a great fix--it does the job, but it is a hassle for the developer. A solution that does not require you to modify a `pkg.yml` file would be much better. I have a few ideas, but haven't implemented anything yet. We should definitely do something about this problem before the next release so others don't struggle with this one. Thanks for raising this issue. You are seeing this issue because logging has been integrated into several more core packages. I think most projects already use a log package and are unaffected, but that is just an assumption. By the way, the `newt target revdep ` command is a useful tool for debugging issues like this. In this case, it will tell you which package(s) depends on modlog. > Since I neither need nor want any logging in my app I figured I'll > turn it off by setting > > NEWT_FEATURE_LOGCFG: 0 > > in syscfg.yml - unfortunately this results in a segfault in the newt > tool. Updating that to the latest master (bc272f6e) has the same > result. The `NEWT_FEATURE_[...]` settings should not be overridden. I probably would have tried the same thing :). Chris
