[jira] [Resolved] (MYNEWT-843) BLE Host - Missing local IRK functionality
[ https://issues.apache.org/jira/browse/MYNEWT-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-843. Resolution: Fixed Fixed in https://github.com/apache/mynewt-core/pull/593 > BLE Host - Missing local IRK functionality > -- > > Key: MYNEWT-843 > URL: https://issues.apache.org/jira/browse/MYNEWT-843 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Priority: Major > > The host needs a few improvements involving the local identity resolving key > (IRK): > 1. Expose function to set the local IRK to a specified value > (`ble_hs_test_util_set_our_irk()` is currently private). > 2. Create a function to randomly generate a new IRK. > 3. When a new local IRK is created, automatically persist it to the store. > 4. On startup, restore the persisted IRK from the store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (MYNEWT-873) newt crashes during 'newt install'
[ https://issues.apache.org/jira/browse/MYNEWT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-873. Resolution: Fixed > newt crashes during 'newt install' > -- > > Key: MYNEWT-873 > URL: https://issues.apache.org/jira/browse/MYNEWT-873 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Newt >Affects Versions: v1_3_0_rel >Reporter: Marko Kiiskila >Assignee: Sterling Hughes >Priority: Major > > There might, or might not have been, an attempt to run 'newt install' before > for this project. > Network was slow, so they might've stopped the fetch in the middle. But I'm > not certain > of that. > nu@mc-117:~/myproj$ newt install > panic: runtime error: invalid memory address or nil pointer dereference > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce] > goroutine 1 [running]: > mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162 > mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc420094e10, > 0x0, 0x1, 0x2, 0x0, 0x0, 0x0, 0x1) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/repo.go:796 > +0x5e > mynewt.apache.org/newt/newt/project.(*Project).loadRepo(0xc420064ae0, > 0xc4200157a0, 0x12, 0xc4200cc0e0, 0x1, 0x1) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:427 > +0x51c > mynewt.apache.org/newt/newt/project.(*Project).loadConfig(0xc420064ae0, 0x0, > 0xc42007dbc0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:505 > +0x421 > mynewt.apache.org/newt/newt/project.(*Project).Init(0xc420064ae0, > 0xc420014184, 0x10, 0x1c, 0x8363c0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:544 > +0xed > mynewt.apache.org/newt/newt/project.NewProject(0xc420014184, 0x10, > 0xc420014184, 0x10, 0x0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:135 > +0x58 > mynewt.apache.org/newt/newt/project.LoadProject(0xc420014184, 0x10, > 0xc420057bd8, 0xc420062080, 0xc42180) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:719 > +0x7d > mynewt.apache.org/newt/newt/project.initProject(0xc420014184, 0x10, > 0xc420014184, 0x10) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:74 > +0x39 > mynewt.apache.org/newt/newt/project.initialize(0x4, 0xc420057c90) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:92 > +0x89 > mynewt.apache.org/newt/newt/project.TryGetProject(0x4, 0xc420019138, 0x4) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:100 > +0x22 > mynewt.apache.org/newt/newt/cli.TryGetProject(0x0) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/util.go:208 > +0x26 > mynewt.apache.org/newt/newt/cli.installRunCmd(0xc420161200, 0xb6fcf8, 0x0, > 0x0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/project_cmds.go:76 > +0x26 > mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420161200, > 0xb6fcf8, 0x0, 0x0, 0xc420161200, 0xb6fcf8) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636 > +0x234 > mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200ced80, > 0xc42016e000, 0xc42016e900, 0xc42016e6c0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722 > +0x2fe > mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200ced80, > 0xc42007d290, 0xc420057f10) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681 > +0x2b > main.main() > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac > gnu@mc-117:~/myproj$ cd .. > gnu@mc-117:~$ cd adafruit/ > gnu@mc-117:~/adafruit$ cd myproj/ > gnu@mc-117:~/adafruit/myproj$ newt install > panic: runtime error: invalid memory address or nil pointer dereference > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce] > goroutine 1 [running]: > mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162 > mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc4200aae10, > 0x0, 0x1, 0x2, 0x0, 0x0, 0x0, 0x1) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/repo.go:796 > +0x5e > mynewt.apache.org/newt/newt/project.(*Project).loadRepo(0xc42009ea80, > 0xc4200a71a0, 0x12, 0xc4200e20e0, 0x1, 0x1) > >
[jira] [Reopened] (MYNEWT-873) newt crashes during 'newt install'
[ https://issues.apache.org/jira/browse/MYNEWT-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins reopened MYNEWT-873: > newt crashes during 'newt install' > -- > > Key: MYNEWT-873 > URL: https://issues.apache.org/jira/browse/MYNEWT-873 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Newt >Affects Versions: v1_3_0_rel >Reporter: Marko Kiiskila >Assignee: Sterling Hughes >Priority: Major > > There might, or might not have been, an attempt to run 'newt install' before > for this project. > Network was slow, so they might've stopped the fetch in the middle. But I'm > not certain > of that. > nu@mc-117:~/myproj$ newt install > panic: runtime error: invalid memory address or nil pointer dereference > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce] > goroutine 1 [running]: > mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162 > mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc420094e10, > 0x0, 0x1, 0x2, 0x0, 0x0, 0x0, 0x1) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/repo.go:796 > +0x5e > mynewt.apache.org/newt/newt/project.(*Project).loadRepo(0xc420064ae0, > 0xc4200157a0, 0x12, 0xc4200cc0e0, 0x1, 0x1) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:427 > +0x51c > mynewt.apache.org/newt/newt/project.(*Project).loadConfig(0xc420064ae0, 0x0, > 0xc42007dbc0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:505 > +0x421 > mynewt.apache.org/newt/newt/project.(*Project).Init(0xc420064ae0, > 0xc420014184, 0x10, 0x1c, 0x8363c0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:544 > +0xed > mynewt.apache.org/newt/newt/project.NewProject(0xc420014184, 0x10, > 0xc420014184, 0x10, 0x0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:135 > +0x58 > mynewt.apache.org/newt/newt/project.LoadProject(0xc420014184, 0x10, > 0xc420057bd8, 0xc420062080, 0xc42180) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:719 > +0x7d > mynewt.apache.org/newt/newt/project.initProject(0xc420014184, 0x10, > 0xc420014184, 0x10) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:74 > +0x39 > mynewt.apache.org/newt/newt/project.initialize(0x4, 0xc420057c90) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:92 > +0x89 > mynewt.apache.org/newt/newt/project.TryGetProject(0x4, 0xc420019138, 0x4) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/project/project.go:100 > +0x22 > mynewt.apache.org/newt/newt/cli.TryGetProject(0x0) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/util.go:208 > +0x26 > mynewt.apache.org/newt/newt/cli.installRunCmd(0xc420161200, 0xb6fcf8, 0x0, > 0x0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/cli/project_cmds.go:76 > +0x26 > mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420161200, > 0xb6fcf8, 0x0, 0x0, 0xc420161200, 0xb6fcf8) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636 > +0x234 > mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200ced80, > 0xc42016e000, 0xc42016e900, 0xc42016e6c0) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722 > +0x2fe > mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200ced80, > 0xc42007d290, 0xc420057f10) > > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681 > +0x2b > main.main() > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac > gnu@mc-117:~/myproj$ cd .. > gnu@mc-117:~$ cd adafruit/ > gnu@mc-117:~/adafruit$ cd myproj/ > gnu@mc-117:~/adafruit/myproj$ newt install > panic: runtime error: invalid memory address or nil pointer dereference > [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x75d4ce] > goroutine 1 [running]: > mynewt.apache.org/newt/newt/repo.(*Version).ToNuVersion(...) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/version.go:162 > mynewt.apache.org/newt/newt/repo.(*Repo).CheckNewtCompatibility(0xc4200aae10, > 0x0, 0x1, 0x2, 0x0, 0x0, 0x0, 0x1) > /tmp/mynewt.YXJAfVKhPc/src/mynewt.apache.org/newt/newt/repo/repo.go:796 > +0x5e > mynewt.apache.org/newt/newt/project.(*Project).loadRepo(0xc42009ea80, > 0xc4200a71a0, 0x12, 0xc4200e20e0, 0x1, 0x1) > >
[jira] [Assigned] (MYNEWT-882) Newt - Problems with spaces in paths
[
https://issues.apache.org/jira/browse/MYNEWT-882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins reassigned MYNEWT-882:
--
Assignee: Christopher Collins (was: Sterling Hughes)
> Newt - Problems with spaces in paths
>
>
> Key: MYNEWT-882
> URL: https://issues.apache.org/jira/browse/MYNEWT-882
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Christopher Collins
>Priority: Major
>
> A user from the #general slack channel (Anup) reported an issue involving
> spaces in path names.
> The summary is:
> {noformat}
> 2018/01/07 18:57:21.699 [DEBUG]
> o=repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c:24:10: fatal
> error: syscfg/syscfg.h: No such file or directory
> {noformat}
> {noformat}
> -IBhattacharjee/dev/myproj/bin/targets/nucleof401_boot/generated/include
> {noformat}
> The full include path should be: {{C:/msys64/home/Anup
> Bhattacharjee/dev/myproj/bin/targets/nucleof401_boot/generated/include}}
> The full build log is here:
> https://mynewt.slack.com/files/U8P49MQ83/F8P7W856W/-.txt
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MYNEWT-888) Build error if FLASH_AREA_IMAGE_1 is undefined
[
https://issues.apache.org/jira/browse/MYNEWT-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-888:
---
Description:
In {{flash_map.c}}, {{flash_area_id_from_image_slot()}} and
{{flash_area_id_to_image_slot()}} unconditionally reference the
{{FLASH_AREA_IMAGE_1}} macro. This causes build errors for a BSP using the
[single setup|http://mynewt.apache.org/latest/os/modules/split/split/].
These functions should be modified to only reference these constants in the
unified and split setups.
was:
In {{flash_map.c}},{{flash_area_id_from_image_slot()}} and
{{flash_area_id_to_image_slot()}} unconditionally reference the
{{FLASH_AREA_IMAGE_1}} macro. This causes build errors for a BSP using the
[single setup|http://mynewt.apache.org/latest/os/modules/split/split/].
These functions should be modified to only reference these constants in the
unified and split setups.
> Build error if FLASH_AREA_IMAGE_1 is undefined
> --
>
> Key: MYNEWT-888
> URL: https://issues.apache.org/jira/browse/MYNEWT-888
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Image Mgmt
>Affects Versions: 1.3
>Reporter: Christopher Collins
>Assignee: Marko Kiiskila
>Priority: Minor
>
> In {{flash_map.c}}, {{flash_area_id_from_image_slot()}} and
> {{flash_area_id_to_image_slot()}} unconditionally reference the
> {{FLASH_AREA_IMAGE_1}} macro. This causes build errors for a BSP using the
> [single setup|http://mynewt.apache.org/latest/os/modules/split/split/].
> These functions should be modified to only reference these constants in the
> unified and split setups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MYNEWT-882) Newt - Problems with spaces in path in Windows
Christopher Collins created MYNEWT-882:
--
Summary: Newt - Problems with spaces in path in Windows
Key: MYNEWT-882
URL: https://issues.apache.org/jira/browse/MYNEWT-882
Project: Mynewt
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes
A user from the #general slack channel (Anup) reported an issue involving
spaces in path names.
The summary is:
{noformat}
2018/01/07 18:57:21.699 [DEBUG]
o=repos/apache-mynewt-core/boot/bootutil/src/bootutil_misc.c:24:10: fatal
error: syscfg/syscfg.h: No such file or directory
{noformat}
{noformat}
-IBhattacharjee/dev/myproj/bin/targets/nucleof401_boot/generated/include
{noformat}
The full include path should be: {{C:/msys64/home/Anup
Bhattacharjee/dev/myproj/bin/targets/nucleof401_boot/generated/include}}
The full build log is here:
https://mynewt.slack.com/files/U8P49MQ83/F8P7W856W/-.txt
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-857) BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-857:
---
Summary: BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
(was: BLE Controller - incompatibility with iOS 11)
This seems to be a link layer issue, so I don't believe the version of iOS is a
factor.
Lance, I have a few more questions if you don't mind:
1. Which iPhone model are you seeing this issue with?
2. Just to make sure - you weren't seeing this issue with older iPhones?
3. Did commenting out the call to {{ble_ll_ctrl_proc_start()}} help at all, or
is the behavior the same?
> BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
> --
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet
> #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295629#comment-16295629
]
Christopher Collins commented on MYNEWT-857:
I did some additional testing:
*Master:* iPhone 8 running iOS 11, lightblue
*Slave:* nRF52dk running bleprph
Unfortunately, I get the same results:
* With an unmodified NimBLE slave, the iPhone controller seems to get stuck
after the slave initiates the Slave Feature Request link layer procedure.
Service discovery does not occur and lightblue eventually times out.
* When I comment out the call to {{ble_ll_ctrl_proc_start()}}, the full connect
procedure (including MTU exchange, service discovery, etc.) completes without
issue.
I ran the "commented out" test 47 times with no issues.
h3. Initial failed attempt (unmodified NimBLE stack):
{noformat}
02 [ts=15624ssb, mod=4 level=1] GAP procedure initiated: advertise;
disc_mode=2 adv_channel_map=0 own_addr_type=0 adv_filter_policy=0
adv_itvl_min=0 adv_itvl_max=0
002100 [ts=16406224ssb, mod=64 level=1] connection established; status=0
handle=1 our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
002110 [ts=16484344ssb, mod=64 level=1]
004020 [ts=31406224ssb, mod=64 level=1] connection updated; status=531 handle=1
our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
004029 [ts=31476532ssb, mod=64 level=1]
004030 [ts=31484344ssb, mod=64 level=1] disconnect; reason=531 handle=1
our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
004039 [ts=31554652ssb, mod=64 level=1]
004040 [ts=31562464ssb, mod=4 level=1] GAP procedure initiated: advertise;
disc_mode=2 adv_channel_map=0 own_addr_type=0 adv_filter_policy=0
adv_itvl_min=0 adv_itvl_max=0
{noformat}
h3. With call to {{ble_ll_ctrl_proc_start()}} commented out:
{noformat}
02 [ts=15624ssb, mod=4 level=1] GAP procedure initiated: advertise;
disc_mode=2 adv_channel_map=0 own_addr_type=0 adv_filter_policy=0
adv_itvl_min=0 adv_itvl_max=0
000611 [ts=4773388ssb, mod=64 level=1] connection established; status=0
handle=1 our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
000620 [ts=4843696ssb, mod=64 level=1]
000649 [ts=5070308ssb, mod=64 level=1] mtu update event; conn_handle=1 cid=4
mtu=256
000695 [ts=5429660ssb, mod=64 level=1] subscribe event; conn_handle=1
attr_handle=14 reason=1 prevn=0 curn=0 previ=0 curi=1
001156 [ts=9031248ssb, mod=64 level=1] connection updated; status=531 handle=1
our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
001165 [ts=9101556ssb, mod=64 level=1]
001166 [ts=9109368ssb, mod=64 level=1] subscribe event; conn_handle=1
attr_handle=14 reason=2 prevn=0 curn=0 previ=1 curi=0
001169 [ts=9132804ssb, mod=64 level=1] disconnect; reason=531 handle=1
our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
001178 [ts=9203112ssb, mod=64 level=1]
001179 [ts=9210924ssb, mod=4 level=1] GAP procedure initiated: advertise;
disc_mode=2 adv_channel_map=0 own_addr_type=0 adv_filter_policy=0
adv_itvl_min=0 adv_itvl_max=0
001651 [ts=12898380ssb, mod=64 level=1] connection established; status=0
handle=1 our_ota_addr_type=0 our_ota_addr=00:13:50:00:ff:ff our_id_addr_type=0
our_id_addr=00:13:50:00:ff:ff peer_ota_addr_type=1
peer_ota_addr=73:5d:7d:24:e7:61 peer_id_addr_type=1
peer_id_addr=73:5d:7d:24:e7:61 conn_itvl=24 conn_latency=0
supervision_timeout=72 encrypted=0 authenticated=0 bonded=0
001660 [ts=12968688ssb, mod=64 level=1]
001690 [ts=13203112ssb, mod=64 level=1] mtu update event; conn_handle=1 cid=4
[jira] [Comment Edited] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209721#comment-16209721
]
Christopher Collins edited comment on MYNEWT-857 at 12/16/17 6:47 PM:
--
Hmm, that's interesting. Maybe the problem isn't the type of PDU that gets
sent, but how early it gets sent. I have attached a pcap file
({{ios2nimble-no-feat.pcap}}) showing the successful connect (with the feature
exchange commented out). The CONNECT_REQ is at packet #285718.
was (Author: ccollins476):
Hmm, that's interesting. Maybe the problem isn't the type of PDU that gets
sent, but how early it gets sent. I have attached a pcap file
{{ios2nimble-no-feat.pcap}} showing the successful connect (with the feature
exchange commented out). The CONNECT_REQ is at packet #285718.
> BLE Controller - incompatibility with iOS 11
>
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet
> #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209721#comment-16209721
]
Christopher Collins edited comment on MYNEWT-857 at 12/16/17 6:46 PM:
--
Hmm, that's interesting. Maybe the problem isn't the type of PDU that gets
sent, but how early it gets sent. I have attached a pcap file
{{ios2nimble-no-feat.pcap}} showing the successful connect (with the feature
exchange commented out). The CONNECT_REQ is at packet #285718.
was (Author: ccollins476):
Hmm, that's interesting. Maybe the problem isn't the type of PDU that gets
sent, but how early it gets sent. I have attached a pcap file showing the
successful connect (with the feature exchange commented out). The CONNET_REQ
is at packet #285718.
> BLE Controller - incompatibility with iOS 11
>
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet
> #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-857:
---
Description:
Master: iPhone running iOS 11
Slave: NimBLE device
The iPhone successfully establishes a connection to the NimBLE device, but the
CoreBluetooth {{didConnect()}} callback does not get called. A packet trace
(see attached {{ios2nimble.pcap}} file) shows that the iPhone never initiates
service discovery.
The problem seems to occur when the NimBLE controller initiates the Feature
Exchange Procedure immediately after connection establishment. The
{{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
{{ble_ll_conn_created()}}, the iOS device is able to connect and perform
service discovery, resulting in the CoreBluetooth callback being executed.
In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet
#6211.
was:
Master: iPhone running iOS 11
Slave: NimBLE device
The iPhone successfully establishes a connection to the NimBLE device, but the
CoreBluetooth {{didConnect()}} callback does not get called. A packet trace
(see attached) shows that the iPhone never initiates service discovery.
The problem seems to occur when the NimBLE controller initiates the Feature
Exchange Procedure immediately after connection establishment. The
{{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
{{ble_ll_conn_created()}}, the iOS device is able to connect and perform
service discovery, resulting in the CoreBluetooth callback being executed.
In the attached pcap file, the CONNECT_REQ is at packet #6211.
> BLE Controller - incompatibility with iOS 11
>
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet
> #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293905#comment-16293905
]
Christopher Collins edited comment on MYNEWT-857 at 12/16/17 6:44 PM:
--
Lance, that is disappointing to hear. Could you estimate the frequency of the
intermittent issue (e.g., 1 out of 10 connections)? The problem seemed to be
fully resolved for me when I removed the call to {{ble_ll_ctrl_proc_start()}},
but I admit that I only tried it a few times before declaring success. I don't
have access to a new iOS device at the moment, but I can try some more tests
during the week.
Do you happen to have a Bluetooth sniffer? A trace (e.g., pcap file) which
captures the intermittent issue would be quite helpful.
was (Author: ccollins476):
Lance, that is disappointing to hear. Could you estimate the frequency of the
intermittent issue (e.g., 1 out of 10 connections)?
Do you happen to have a Bluetooth sniffer? A trace (e.g., pcap file) which
captures the intermittent issue would be quite helpful.
> BLE Controller - incompatibility with iOS 11
>
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached) shows that the iPhone never initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file, the CONNECT_REQ is at packet #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293905#comment-16293905
]
Christopher Collins commented on MYNEWT-857:
Lance, that is disappointing to hear. Could you estimate the frequency of the
intermittent issue (e.g., 1 out of 10 connections)?
Do you happen to have a Bluetooth sniffer? A trace (e.g., pcap file) which
captures the intermittent issue would be quite helpful.
> BLE Controller - incompatibility with iOS 11
>
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached) shows that the iPhone never initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file, the CONNECT_REQ is at packet #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-287) Host Flow Control
[ https://issues.apache.org/jira/browse/MYNEWT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-287: --- Fix Version/s: (was: v1_3_0_rel) v1_4_0_rel > Host Flow Control > - > > Key: MYNEWT-287 > URL: https://issues.apache.org/jira/browse/MYNEWT-287 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) > Components: Nimble > Environment: Using nimble from an external host stack >Reporter: Johan Hedberg >Assignee: Christopher Collins > Fix For: v1_4_0_rel > > > If the Nimble controller part is connected to an external host stack the host > may need to control the flow of ACL packets from the controller to the host. > This is particularly important for resource-constrained hosts that have a > limited amount of RX ACL data buffers. > The Bluetooth core specification provides a standard feature to accomplish > this called Host Flow Control. (Vol 2, Part E, Section 4.2). To implement > this the controller needs to support the "Set Controller To Host Flow > Control", "Host Buffer Size" and "Host Number Of Completed Packets" HCI > commands. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-869) net/nimble/host unittest failures
[ https://issues.apache.org/jira/browse/MYNEWT-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-869: --- Description: tcore/pullsset the following syscfg variables: OS_MEMPOOL_CHECK: description: 'Whether to do stack sanity check of mempool operations' value: 1 OS_MEMPOOL_POISON: description: 'Whether to do write known pattern to freed memory' value: 1 (gdb) run Starting program: /Users/marko/src2/incubator-mynewt-blinky/repos/apache-mynewt-core/bin/targets/unittest/net_nimble_host_test/app/net/nimble/host/test/net_nimble_host_test.elf [New Thread 0x1303 of process 64395] warning: unhandled dyld version (15) [pass] ble_att_clt_suite/ble_att_clt_test_tx_find_info [pass] ble_att_clt_suite/ble_att_clt_test_rx_find_info [pass] ble_att_clt_suite/ble_att_clt_test_tx_read [pass] ble_att_clt_suite/ble_att_clt_test_rx_read [pass] ble_att_clt_suite/ble_att_clt_test_tx_read_blob [pass] ble_att_clt_suite/ble_att_clt_test_rx_read_blob [pass] ble_att_clt_suite/ble_att_clt_test_tx_read_mult [pass] ble_att_clt_suite/ble_att_clt_test_rx_read_mult [pass] ble_att_clt_suite/ble_att_clt_test_tx_write [pass] ble_att_clt_suite/ble_att_clt_test_tx_prep_write [pass] ble_att_clt_suite/ble_att_clt_test_rx_prep_write [pass] ble_att_clt_suite/ble_att_clt_test_tx_exec_write [pass] ble_att_clt_suite/ble_att_clt_test_tx_mtu [pass] ble_att_svr_suite/ble_att_svr_test_mtu [pass] ble_att_svr_suite/ble_att_svr_test_read [pass] ble_att_svr_suite/ble_att_svr_test_read_blob [pass] ble_att_svr_suite/ble_att_svr_test_read_mult [pass] ble_att_svr_suite/ble_att_svr_test_write [pass] ble_att_svr_suite/ble_att_svr_test_find_info [pass] ble_att_svr_suite/ble_att_svr_test_find_type_value [pass] ble_att_svr_suite/ble_att_svr_test_read_type [pass] ble_att_svr_suite/ble_att_svr_test_read_group_type [pass] ble_att_svr_suite/ble_att_svr_test_prep_write [pass] ble_att_svr_suite/ble_att_svr_test_prep_write_tmo [pass] ble_att_svr_suite/ble_att_svr_test_notify [pass] ble_att_svr_suite/ble_att_svr_test_indicate [pass] ble_att_svr_suite/ble_att_svr_test_oom [pass] ble_gap_test_suite_wl/ble_gap_test_case_wl_good [pass] ble_gap_test_suite_wl/ble_gap_test_case_wl_bad_args [pass] ble_gap_test_suite_wl/ble_gap_test_case_wl_ctlr_fail [pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_bad_args [pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_good [pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_ltd_mismatch [pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_hci_fail [pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_dflts [pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_already [pass] ble_gap_test_suite_disc/ble_gap_test_case_disc_busy [pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_good [pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_bad_args [pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_dflt_params [pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_already [pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_done [pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_busy [pass] ble_gap_test_suite_conn_gen/ble_gap_test_case_conn_gen_fail_evt [pass] ble_gap_test_suite_conn_cancel/ble_gap_test_case_conn_cancel_good [pass] ble_gap_test_suite_conn_cancel/ble_gap_test_case_conn_cancel_bad_args [pass] ble_gap_test_suite_conn_cancel/ble_gap_test_case_conn_cancel_ctlr_fail [pass] ble_gap_test_suite_conn_terminate/ble_gap_test_case_conn_terminate_bad_args [pass] ble_gap_test_suite_conn_terminate/ble_gap_test_case_conn_terminate_good [pass] ble_gap_test_suite_conn_terminate/ble_gap_test_case_conn_terminate_ctlr_fail [pass] ble_gap_test_suite_conn_terminate/ble_gap_test_case_conn_terminate_hci_fail [pass] ble_gap_test_suite_conn_find/ble_gap_test_case_conn_find [pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_bad_args [pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_dflt_params [pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_good [pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_ctlr_fail [pass] ble_gap_test_suite_adv/ble_gap_test_case_adv_hci_fail [pass] ble_gap_test_suite_stop_adv/ble_gap_test_case_stop_adv_good [pass] ble_gap_test_suite_stop_adv/ble_gap_test_case_stop_adv_hci_fail [pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_conn_good [pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_conn_bad [pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_conn_hci_fail [pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_conn_l2cap [pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_peer_good [pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_req_good [pass] ble_gap_test_suite_update_conn/ble_gap_test_case_update_req_hci_fail [pass]
[jira] [Created] (MYNEWT-864) Newt - Cannot specify multiple-argument cflags
Christopher Collins created MYNEWT-864:
--
Summary: Newt - Cannot specify multiple-argument cflags
Key: MYNEWT-864
URL: https://issues.apache.org/jira/browse/MYNEWT-864
Project: Mynewt
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes
Fix For: v1.3
For example:
{noformat}
pkg.cflags:
- '-include /usr/local/extra-includes'
{noformat}
The entire item, including the space, gets passed to gcc as a single argument.
We need a way to specify multiple arguments for a single flag.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-859) Newt crashes on invalid target setting
[
https://issues.apache.org/jira/browse/MYNEWT-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-859:
---
Description:
(Pull request: https://github.com/apache/mynewt-newt/pull/106)
If a target's {{target.yml}} file contains a setting whose value is not a
string and not an integer, newt panics with a stack trace like this:
{noformat}
goroutine 1 [running]:
mynewt.apache.org/newt/newt/target.(*Target).Load(0xc42052c540, 0xc42049c070,
0x3000100, 0x0)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:88
+0x831
mynewt.apache.org/newt/newt/target.LoadTarget(0xc42049c070, 0x8, 0xc42045a680,
0x6)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:63
+0x5b
mynewt.apache.org/newt/newt/target.buildTargetMap(0x0, 0x8)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:281
+0xe9
mynewt.apache.org/newt/newt/target.GetTargets(0x7fff5fbffbfa)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:301
+0x48
mynewt.apache.org/newt/newt/cli.ResolveTarget(0x7fff5fbffbf3, 0x8, 0x0)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/util.go:86
+0x9d
mynewt.apache.org/newt/newt/cli.ResolveTargetsOrAll(0xc420041300, 0x1, 0x1,
0x1103d5d, 0xc42007a16c, 0xc42004fbf0, 0x11035c2, 0xc42007a16c, 0x14fb9d8)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/util.go:125
+0xda
mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420089440, 0xc420041300, 0x1,
0x1, 0x0)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:118
+0x90
mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420089440,
0xc420041300, 0x1, 0x1)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404
+0x5f
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420089440,
0xc4200412c0, 0x1, 0x1, 0xc420089440, 0xc4200412c0)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
+0x234
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420088fc0,
0x5, 0x25, 0x14ea8fa)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
+0x2fe
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420088fc0,
0x14ea8fa, 0x5)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
+0x2b
main.main()
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/newt.go:170
+0x1ac
Add Comment
{noformat}
The code responsible for the panic is here in {{func (target *Target) Load()}}
{noformat}
settings := v.AllSettings()
for k, v := range settings {
var ok bool
target.Vars[k], ok = v.(string)
if !ok {
target.Vars[k] = strconv.Itoa(v.(int))
}
}
{noformat}
was:
If a target's {{target.yml}} file contains a setting whose value is not a
string and not an integer, newt panics with a stack trace like this:
{noformat}
goroutine 1 [running]:
mynewt.apache.org/newt/newt/target.(*Target).Load(0xc42052c540, 0xc42049c070,
0x3000100, 0x0)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:88
+0x831
mynewt.apache.org/newt/newt/target.LoadTarget(0xc42049c070, 0x8, 0xc42045a680,
0x6)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:63
+0x5b
mynewt.apache.org/newt/newt/target.buildTargetMap(0x0, 0x8)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:281
+0xe9
mynewt.apache.org/newt/newt/target.GetTargets(0x7fff5fbffbfa)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:301
+0x48
mynewt.apache.org/newt/newt/cli.ResolveTarget(0x7fff5fbffbf3, 0x8, 0x0)
[jira] [Commented] (MYNEWT-860) Newt - Empty `pkg.yml` file causes target to be built as split image
[
https://issues.apache.org/jira/browse/MYNEWT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16222906#comment-16222906
]
Christopher Collins commented on MYNEWT-860:
Specifically, an empty {{pkg.yml}} file causes problems because it describes a
package with no name. When there is a package whose name is {{""}}, it matches
some unset settings. In this case, the target being built does not specify a
{{target.loader}} value, as it is not a split image. However, newt thinks the
target actually specifies the unnamed packages as its loader, so it attempts to
build a split image.
The fix is to ignore packages with no name (and warn the user).
> Newt - Empty `pkg.yml` file causes target to be built as split image
>
>
> Key: MYNEWT-860
> URL: https://issues.apache.org/jira/browse/MYNEWT-860
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Christopher Collins
>
> 1. Create a directory in your project:
> {noformat}
> mkdir blah
> {noformat}
> 2. Create an empty {{pkg.yml}} file in the directory:
> {noformat}
> touch blah/pkg.yml
> {noformat}
> 3. Build a non-split-image target.
> Newt will compile everything twice, as if it were building a split image.
> Then it will fail in an unpredictable way, e.g.:
> {noformat}
> Error: In file included from apps/krang/src/main.c:23:0:
> repos/apache-mynewt-core/sys/sysinit/include/sysinit/sysinit.h:28:25: fatal
> error: split/split.h: No such file or directory
> #include "split/split.h"
> {noformat}
> {noformat}
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12a71d4]
> goroutine 1 [running]:
> mynewt.apache.org/newt/newt/pkg.(*LocalPackage).Name(...)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
> mynewt.apache.org/newt/newt/builder.(*Builder).TestExePath(0xc4205307e0, 0x0,
> 0x0)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179 +0x34
> mynewt.apache.org/newt/newt/builder.(*Builder).CompileCmdsPath(0xc4205307e0,
> 0xc420308920, 0x0)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:198 +0xad
> mynewt.apache.org/newt/newt/builder.(*Builder).Build(0xc4205307e0, 0x0, 0x0)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/build.go:601 +0xa20
> mynewt.apache.org/newt/newt/builder.(*TargetBuilder).buildLoader(0xc420518120,
> 0x0, 0x0)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:319
> +0xc6
> mynewt.apache.org/newt/newt/builder.(*TargetBuilder).Build(0xc420518120,
> 0xc420518120, 0x0)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:372
> +0x16d
> mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420090b40, 0xc420048d50, 0x1,
> 0x1, 0x0)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:160
> +0x2c9
> mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420090b40,
> 0xc420048d50, 0x1, 0x1)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404 +0x5f
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420090b40,
> 0xc420048d10, 0x1, 0x1, 0xc420090b40, 0xc420048d10)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
> +0x234
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200906c0,
> 0x5, 0x25, 0x1399e93)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
> +0x2fe
> mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200906c0,
> 0x1399e93, 0x5)
>
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
> +0x2b
> main.main()
> /Users/ccollins/go/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-860) Newt - Empty `pkg.yml` file causes target to be built as split image
[
https://issues.apache.org/jira/browse/MYNEWT-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-860:
---
Description:
1. Create a directory in your project:
{noformat}
mkdir blah
{noformat}
2. Create an empty {{pkg.yml}} file in the directory:
{noformat}
touch blah/pkg.yml
{noformat}
3. Build a non-split-image target.
Newt will compile everything twice, as if it were building a split image. Then
it will fail in an unpredictable way, e.g.:
{noformat}
Error: In file included from apps/krang/src/main.c:23:0:
repos/apache-mynewt-core/sys/sysinit/include/sysinit/sysinit.h:28:25: fatal
error: split/split.h: No such file or directory
#include "split/split.h"
{noformat}
{noformat}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12a71d4]
goroutine 1 [running]:
mynewt.apache.org/newt/newt/pkg.(*LocalPackage).Name(...)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
mynewt.apache.org/newt/newt/builder.(*Builder).TestExePath(0xc4205307e0, 0x0,
0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
+0x34
mynewt.apache.org/newt/newt/builder.(*Builder).CompileCmdsPath(0xc4205307e0,
0xc420308920, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:198
+0xad
mynewt.apache.org/newt/newt/builder.(*Builder).Build(0xc4205307e0, 0x0, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/build.go:601
+0xa20
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).buildLoader(0xc420518120,
0x0, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:319
+0xc6
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).Build(0xc420518120,
0xc420518120, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:372
+0x16d
mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420090b40, 0xc420048d50, 0x1,
0x1, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:160 +0x2c9
mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420090b40,
0xc420048d50, 0x1, 0x1)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404 +0x5f
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420090b40,
0xc420048d10, 0x1, 0x1, 0xc420090b40, 0xc420048d10)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
+0x234
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200906c0,
0x5, 0x25, 0x1399e93)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
+0x2fe
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200906c0,
0x1399e93, 0x5)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
+0x2b
main.main()
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac
{noformat}
was:
1. Create a directory in your project:
{noformat}
mkdir blah
{noformat}
2. Create an empty {pkg.yml} file in the directory:
{noformat}
touch blah/pkg.yml
{noformat}
3. Build a non-split-image target.
Newt will compile everything twice, as if it were building a split image. Then
it will fail in an unpredictable way, e.g.:
{noformat}
Error: In file included from apps/krang/src/main.c:23:0:
repos/apache-mynewt-core/sys/sysinit/include/sysinit/sysinit.h:28:25: fatal
error: split/split.h: No such file or directory
#include "split/split.h"
{noformat}
{noformat}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12a71d4]
goroutine 1 [running]:
mynewt.apache.org/newt/newt/pkg.(*LocalPackage).Name(...)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
mynewt.apache.org/newt/newt/builder.(*Builder).TestExePath(0xc4205307e0, 0x0,
0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
+0x34
mynewt.apache.org/newt/newt/builder.(*Builder).CompileCmdsPath(0xc4205307e0,
0xc420308920, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:198
+0xad
mynewt.apache.org/newt/newt/builder.(*Builder).Build(0xc4205307e0, 0x0, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/build.go:601
+0xa20
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).buildLoader(0xc420518120,
0x0, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:319
+0xc6
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).Build(0xc420518120,
0xc420518120, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:372
+0x16d
mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420090b40,
[jira] [Created] (MYNEWT-860) Newt - Empty `pkg.yml` file causes target to be built as split image
Christopher Collins created MYNEWT-860:
--
Summary: Newt - Empty `pkg.yml` file causes target to be built as
split image
Key: MYNEWT-860
URL: https://issues.apache.org/jira/browse/MYNEWT-860
Project: Mynewt
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Components: Newt
Reporter: Christopher Collins
Assignee: Christopher Collins
1. Create a directory in your project:
{noformat}
mkdir blah
{noformat}
2. Create an empty {pkg.yml} file in the directory:
{noformat}
touch blah/pkg.yml
{noformat}
3. Build a non-split-image target.
Newt will compile everything twice, as if it were building a split image. Then
it will fail in an unpredictable way, e.g.:
{noformat}
Error: In file included from apps/krang/src/main.c:23:0:
repos/apache-mynewt-core/sys/sysinit/include/sysinit/sysinit.h:28:25: fatal
error: split/split.h: No such file or directory
#include "split/split.h"
{noformat}
{noformat}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x12a71d4]
goroutine 1 [running]:
mynewt.apache.org/newt/newt/pkg.(*LocalPackage).Name(...)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
mynewt.apache.org/newt/newt/builder.(*Builder).TestExePath(0xc4205307e0, 0x0,
0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:179
+0x34
mynewt.apache.org/newt/newt/builder.(*Builder).CompileCmdsPath(0xc4205307e0,
0xc420308920, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/paths.go:198
+0xad
mynewt.apache.org/newt/newt/builder.(*Builder).Build(0xc4205307e0, 0x0, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/build.go:601
+0xa20
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).buildLoader(0xc420518120,
0x0, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:319
+0xc6
mynewt.apache.org/newt/newt/builder.(*TargetBuilder).Build(0xc420518120,
0xc420518120, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/builder/targetbuild.go:372
+0x16d
mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420090b40, 0xc420048d50, 0x1,
0x1, 0x0)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:160 +0x2c9
mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420090b40,
0xc420048d50, 0x1, 0x1)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404 +0x5f
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420090b40,
0xc420048d10, 0x1, 0x1, 0xc420090b40, 0xc420048d10)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
+0x234
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc4200906c0,
0x5, 0x25, 0x1399e93)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
+0x2fe
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc4200906c0,
0x1399e93, 0x5)
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
+0x2b
main.main()
/Users/ccollins/go/src/mynewt.apache.org/newt/newt/newt.go:170 +0x1ac
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (MYNEWT-805) Better support for private repos
[ https://issues.apache.org/jira/browse/MYNEWT-805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-805. Resolution: Fixed > Better support for private repos > > > Key: MYNEWT-805 > URL: https://issues.apache.org/jira/browse/MYNEWT-805 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: Newt >Reporter: Todd Mitton >Assignee: Todd Mitton >Priority: Minor > > A password or personal access token must be specified in project.yml for > `newt install` to access a private repo. This makes it hard to use private > repos in automated environments because it would require checking in the > clear text password/token. > We should add support for getting the password/token from an env variables. > CI systems like jenkins, travis, etc. securely store secrets and make them > available to builds through env variables. > Even better then env variables is to use ssh instead of https. Private repos > can be accessed via ssh, and newt can simply use the local ssh agent when > accessing the private repo. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-859) Newt crashes on invalid target setting
Christopher Collins created MYNEWT-859:
--
Summary: Newt crashes on invalid target setting
Key: MYNEWT-859
URL: https://issues.apache.org/jira/browse/MYNEWT-859
Project: Mynewt
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Components: Newt
Reporter: Christopher Collins
Assignee: Sterling Hughes
Fix For: v1_3_0_rel
If a target's {{target.yml}} file contains a setting whose value is not a
string and not an integer, newt panics with a stack trace like this:
{noformat}
goroutine 1 [running]:
mynewt.apache.org/newt/newt/target.(*Target).Load(0xc42052c540, 0xc42049c070,
0x3000100, 0x0)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:88
+0x831
mynewt.apache.org/newt/newt/target.LoadTarget(0xc42049c070, 0x8, 0xc42045a680,
0x6)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:63
+0x5b
mynewt.apache.org/newt/newt/target.buildTargetMap(0x0, 0x8)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:281
+0xe9
mynewt.apache.org/newt/newt/target.GetTargets(0x7fff5fbffbfa)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/target/target.go:301
+0x48
mynewt.apache.org/newt/newt/cli.ResolveTarget(0x7fff5fbffbf3, 0x8, 0x0)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/util.go:86
+0x9d
mynewt.apache.org/newt/newt/cli.ResolveTargetsOrAll(0xc420041300, 0x1, 0x1,
0x1103d5d, 0xc42007a16c, 0xc42004fbf0, 0x11035c2, 0xc42007a16c, 0x14fb9d8)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/util.go:125
+0xda
mynewt.apache.org/newt/newt/cli.buildRunCmd(0xc420089440, 0xc420041300, 0x1,
0x1, 0x0)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:118
+0x90
mynewt.apache.org/newt/newt/cli.AddBuildCommands.func1(0xc420089440,
0xc420041300, 0x1, 0x1)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/cli/build_cmds.go:404
+0x5f
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).execute(0xc420089440,
0xc4200412c0, 0x1, 0x1, 0xc420089440, 0xc4200412c0)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:636
+0x234
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc420088fc0,
0x5, 0x25, 0x14ea8fa)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:722
+0x2fe
mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra.(*Command).Execute(0xc420088fc0,
0x14ea8fa, 0x5)
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/vendor/github.com/spf13/cobra/command.go:681
+0x2b
main.main()
/private/tmp/mynewt-newt-20170911-92237-1eg3req/mynewt-newt-mynewt_1_2_0_tag/gopath/src/mynewt.apache.org/newt/newt/newt.go:170
+0x1ac
Add Comment
{noformat}
The code responsible for the panic is here in {{func (target *Target) Load()}}
{noformat}
settings := v.AllSettings()
for k, v := range settings {
var ok bool
target.Vars[k], ok = v.(string)
if !ok {
target.Vars[k] = strconv.Itoa(v.(int))
}
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-858) Test package lflags ignored by `newt test`
[
https://issues.apache.org/jira/browse/MYNEWT-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-858:
---
Description:
If you add the following to a test package:
{noformat}
pkg.lflags:
- "-foo"
{noformat}
and then test the package with `newt test`, the flag does not get passed to gcc
during linking.
Newt currently only reads lflags from the following package types:
* target
* app
* bsp
* compiler
At the very least, the test package's lflags should be used when a unit test is
linked via {{newt test}}. Alternatively, it may make more sense to gather the
lflags from all constituent packages during the link phase.
was:
If you add the following to a test package:
{noformat}
pkg.lflags:
- "-foo"
{noformat}
and then test the package with `newt test`, the flag does not get passed to gcc
during linking.
Newt currently only reads lflags from the following package types:
* target
* app
* bsp
* compiler
At the very least, the test package's lflags should be used when a unit test is
linked via {newt test}. Alternatively, it may make more sense to gather the
lflags from all constituent packages during the link phase.
> Test package lflags ignored by `newt test`
> --
>
> Key: MYNEWT-858
> URL: https://issues.apache.org/jira/browse/MYNEWT-858
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Sterling Hughes
> Fix For: v1_3_0_rel
>
>
> If you add the following to a test package:
> {noformat}
> pkg.lflags:
> - "-foo"
> {noformat}
> and then test the package with `newt test`, the flag does not get passed to
> gcc during linking.
> Newt currently only reads lflags from the following package types:
> * target
> * app
> * bsp
> * compiler
> At the very least, the test package's lflags should be used when a unit test
> is linked via {{newt test}}. Alternatively, it may make more sense to gather
> the lflags from all constituent packages during the link phase.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16209721#comment-16209721
]
Christopher Collins edited comment on MYNEWT-857 at 10/18/17 5:42 PM:
--
Hmm, that's interesting. Maybe the problem isn't the type of PDU that gets
sent, but how early it gets sent. I have attached a pcap file showing the
successful connect (with the feature exchange commented out). The CONNET_REQ
is at packet #285718.
was (Author: ccollins476):
Hmm, that's interesting. Maybe the problem isn't the type of PDU that gets
sent, but how early it gets sent. I have attached a pcap file showing the
successful connect (with the feature exchange commented out).
> BLE Controller - incompatibility with iOS 11
>
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached) shows that the iPhone never initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file, the CONNECT_REQ is at packet #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-857:
---
Attachment: ios2nimble-no-feat.pcap
Hmm, that's interesting. Maybe the problem isn't the type of PDU that gets
sent, but how early it gets sent. I have attached a pcap file showing the
successful connect (with the feature exchange commented out).
> BLE Controller - incompatibility with iOS 11
>
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached) shows that the iPhone never initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file, the CONNECT_REQ is at packet #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list
[ https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-842. Resolution: Fixed > BLE Host - Handle failure to add entry to resolving list > > > Key: MYNEWT-842 > URL: https://issues.apache.org/jira/browse/MYNEWT-842 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_3_0_rel > > > (Pull request: https://github.com/apache/mynewt-core/pull/596) > If an attempt to add a peer's IRK to the resolving list fails, the failure is > not reported, and the operation is not reattempted. Adding to the resolving > list fails if the host is scanning or advertising at the time, so this is a > common occurrence. > I am not sure what the best solution is to this problem. I have a few ideas > (order of increasing complexity): > 1. The host stops all active GAP procedures before trying to add the entry to > the resolving list. The application must restart interrupted procedures as > needed. > 2. The host passes the necessary information up to the application. It is > then up to the application to populate the resolving list when possible (or > not). > 3. The host remembers the failed attempt and retries when in a suitable state > (i.e., when advertising, scanning, and connecting has stopped). > 4. The host temporarily suspends all GAP activity, adds the entry to the > resolving list, and resumes GAP activity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-851) newt - Private repo password displayed by `git remote -v`
[
https://issues.apache.org/jira/browse/MYNEWT-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins resolved MYNEWT-851.
Resolution: Fixed
> newt - Private repo password displayed by `git remote -v`
> -
>
> Key: MYNEWT-851
> URL: https://issues.apache.org/jira/browse/MYNEWT-851
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1.3
>
>
> (Pull request: https://github.com/apache/mynewt-newt/pull/101)
> For private repos, the user's login and password are part of the repo URL.
> E.g.,
> {noformat}
> wes@~/dev/work/repos/private-repo$ git remote -v
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git
> (fetch)
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git
> (push)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
Christopher Collins created MYNEWT-857:
--
Summary: BLE Controller - incompatibility with iOS 11
Key: MYNEWT-857
URL: https://issues.apache.org/jira/browse/MYNEWT-857
Project: Mynewt
Issue Type: Task
Security Level: Public (Viewable by anyone)
Components: Nimble
Reporter: Christopher Collins
Fix For: v1.3
Attachments: ios2nimble.pcap
Master: iPhone running iOS 11
Slave: NimBLE device
The iPhone successfully establishes a connection to the NimBLE device, but the
CoreBluetooth {{didConnect()}} callback does not get called. A packet trace
(see attached) shows that the iPhone never initiates service discovery.
The problem seems to occur when the NimBLE controller initiates the Feature
Exchange Procedure immediately after connection establishment. The
{{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
{{ble_ll_conn_created()}}, the iOS device is able to connect and perform
service discovery, resulting in the CoreBluetooth callback being executed.
In the attached pcap file, the CONNECT_REQ is at packet #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list
[ https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-842: --- Fix Version/s: v1_3_0_rel > BLE Host - Handle failure to add entry to resolving list > > > Key: MYNEWT-842 > URL: https://issues.apache.org/jira/browse/MYNEWT-842 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_3_0_rel > > > (Pull request: https://github.com/apache/mynewt-core/pull/596) > If an attempt to add a peer's IRK to the resolving list fails, the failure is > not reported, and the operation is not reattempted. Adding to the resolving > list fails if the host is scanning or advertising at the time, so this is a > common occurrence. > I am not sure what the best solution is to this problem. I have a few ideas > (order of increasing complexity): > 1. The host stops all active GAP procedures before trying to add the entry to > the resolving list. The application must restart interrupted procedures as > needed. > 2. The host passes the necessary information up to the application. It is > then up to the application to populate the resolving list when possible (or > not). > 3. The host remembers the failed attempt and retries when in a suitable state > (i.e., when advertising, scanning, and connecting has stopped). > 4. The host temporarily suspends all GAP activity, adds the entry to the > resolving list, and resumes GAP activity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MYNEWT-851) newt - Private repo password displayed by `git remote -v`
[
https://issues.apache.org/jira/browse/MYNEWT-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins reassigned MYNEWT-851:
--
Assignee: Christopher Collins (was: Sterling Hughes)
> newt - Private repo password displayed by `git remote -v`
> -
>
> Key: MYNEWT-851
> URL: https://issues.apache.org/jira/browse/MYNEWT-851
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1.3
>
>
> (Pull request: https://github.com/apache/mynewt-newt/pull/101)
> For private repos, the user's login and password are part of the repo URL.
> E.g.,
> {noformat}
> wes@~/dev/work/repos/private-repo$ git remote -v
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git
> (fetch)
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git
> (push)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-851) newt - Private repo password displayed by `git remote -v`
[
https://issues.apache.org/jira/browse/MYNEWT-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-851:
---
Summary: newt - Private repo password displayed by `git remote -v` (was:
newt - Private repo password displayed by `git status`)
> newt - Private repo password displayed by `git remote -v`
> -
>
> Key: MYNEWT-851
> URL: https://issues.apache.org/jira/browse/MYNEWT-851
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Sterling Hughes
> Fix For: v1.3
>
>
> For private repos, the user's login and password are part of the repo URL.
> E.g.,
> {noformat}
> wes@~/dev/work/repos/private-repo$ git remote -v
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git
> (fetch)
> origin
> https://wes3:[password-redacted]@github.com/PrivateRepo/private-repo.git
> (push)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MYNEWT-850) testutil - revisit output options
Christopher Collins created MYNEWT-850: -- Summary: testutil - revisit output options Key: MYNEWT-850 URL: https://issues.apache.org/jira/browse/MYNEWT-850 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Components: Misc Reporter: Christopher Collins Fix For: v1_3_0_rel Options for text output during `newt test` are limited or incorrect in many cases. 1. Provide a mechanism for miscellaneous output (e.g., intermediate calculations). 2. Allow for a "verbose test mode" - Prints all test results and any intermediate output contained in the unit tests. This should be possible without newt's `-v` option, which prints out a bunch of unrelated text. 3. The `ts_print_results` option in the `ts_config` struct is redundant. We should just use the pass and fail callbacks to print results. ...and possibly more. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list
[ https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-842: --- Description: (Pull request: If an attempt to add a peer's IRK to the resolving list fails, the failure is not reported, and the operation is not reattempted. Adding to the resolving list fails if the host is scanning or advertising at the time, so this is a common occurrence. I am not sure what the best solution is to this problem. I have a few ideas (order of increasing complexity): 1. The host stops all active GAP procedures before trying to add the entry to the resolving list. The application must restart interrupted procedures as needed. 2. The host passes the necessary information up to the application. It is then up to the application to populate the resolving list when possible (or not). 3. The host remembers the failed attempt and retries when in a suitable state (i.e., when advertising, scanning, and connecting has stopped). 4. The host temporarily suspends all GAP activity, adds the entry to the resolving list, and resumes GAP activity. was: If an attempt to add a peer's IRK to the resolving list fails, the failure is not reported, and the operation is not reattempted. Adding to the resolving list fails if the host is scanning or advertising at the time, so this is a common occurrence. I am not sure what the best solution is to this problem. I have a few ideas (order of increasing complexity): 1. The host stops all active GAP procedures before trying to add the entry to the resolving list. The application must restart interrupted procedures as needed. 2. The host passes the necessary information up to the application. It is then up to the application to populate the resolving list when possible (or not). 3. The host remembers the failed attempt and retries when in a suitable state (i.e., when advertising, scanning, and connecting has stopped). 4. The host temporarily suspends all GAP activity, adds the entry to the resolving list, and resumes GAP activity. > BLE Host - Handle failure to add entry to resolving list > > > Key: MYNEWT-842 > URL: https://issues.apache.org/jira/browse/MYNEWT-842 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > > (Pull request: > If an attempt to add a peer's IRK to the resolving list fails, the failure is > not reported, and the operation is not reattempted. Adding to the resolving > list fails if the host is scanning or advertising at the time, so this is a > common occurrence. > I am not sure what the best solution is to this problem. I have a few ideas > (order of increasing complexity): > 1. The host stops all active GAP procedures before trying to add the entry to > the resolving list. The application must restart interrupted procedures as > needed. > 2. The host passes the necessary information up to the application. It is > then up to the application to populate the resolving list when possible (or > not). > 3. The host remembers the failed attempt and retries when in a suitable state > (i.e., when advertising, scanning, and connecting has stopped). > 4. The host temporarily suspends all GAP activity, adds the entry to the > resolving list, and resumes GAP activity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list
[ https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-842: --- Description: If an attempt to add a peer's IRK to the resolving list fails, the failure is not reported, and the operation is not reattempted. Adding to the resolving list fails if the host is scanning or advertising at the time, so this is a common occurrence. I am not sure what the best solution is to this problem. I have a few ideas (order of increasing complexity): 1. The host stops all active GAP procedures before trying to add the entry to the resolving list. The application must restart interrupted procedures as needed. 2. The host passes the necessary information up to the application. It is then up to the application to populate the resolving list when possible (or not). 3. The host remembers the failed attempt and retries when in a suitable state (i.e., when advertising, scanning, and connecting has stopped). 4. The host temporarily suspends all GAP activity, adds the entry to the resolving list, and resumes GAP activity. was: If an attempt to add a peer's IRK to the resolving list fails, the failure is not reported, and the operation is not reattempted. Adding to the resolving list fails if the host is scanning or advertising at the time, so this is a common occurrence. I am not sure what the best solution is to this problem. I have a few ideas (order of increasing complexity): 1. The host passes the necessary information up to the application. It is then up to the application to populate the resolving list when possible (or not). 2. The host remembers the failed attempt and retries when in a suitable state (i.e., when advertising, scanning, and connecting has stopped). 3. The host temporarily suspends all GAP activity, adds the entry to the resolving list, and resumes GAP activity. > BLE Host - Handle failure to add entry to resolving list > > > Key: MYNEWT-842 > URL: https://issues.apache.org/jira/browse/MYNEWT-842 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > > If an attempt to add a peer's IRK to the resolving list fails, the failure is > not reported, and the operation is not reattempted. Adding to the resolving > list fails if the host is scanning or advertising at the time, so this is a > common occurrence. > I am not sure what the best solution is to this problem. I have a few ideas > (order of increasing complexity): > 1. The host stops all active GAP procedures before trying to add the entry to > the resolving list. The application must restart interrupted procedures as > needed. > 2. The host passes the necessary information up to the application. It is > then up to the application to populate the resolving list when possible (or > not). > 3. The host remembers the failed attempt and retries when in a suitable state > (i.e., when advertising, scanning, and connecting has stopped). > 4. The host temporarily suspends all GAP activity, adds the entry to the > resolving list, and resumes GAP activity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup
[ https://issues.apache.org/jira/browse/MYNEWT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-841. Resolution: Fixed > BLE Host - Populate resolving list with persisted IRKs at startup > - > > Key: MYNEWT-841 > URL: https://issues.apache.org/jira/browse/MYNEWT-841 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > > (Pull request: https://github.com/apache/mynewt-core/pull/593) > Identity information gets persisted during pairing, but it is never restored > after a reboot. At startup (and on stack reset), the host should populate > the resolving list with the persisted entries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list
[ https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins reassigned MYNEWT-842: -- Assignee: Christopher Collins > BLE Host - Handle failure to add entry to resolving list > > > Key: MYNEWT-842 > URL: https://issues.apache.org/jira/browse/MYNEWT-842 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > > If an attempt to add a peer's IRK to the resolving list fails, the failure is > not reported, and the operation is not reattempted. Adding to the resolving > list fails if the host is scanning or advertising at the time, so this is a > common occurrence. > I am not sure what the best solution is to this problem. I have a few ideas > (order of increasing complexity): > 1. The host passes the necessary information up to the application. It is > then up to the application to populate the resolving list when possible (or > not). > 2. The host remembers the failed attempt and retries when in a suitable state > (i.e., when advertising, scanning, and connecting has stopped). > 3. The host temporarily suspends all GAP activity, adds the entry to the > resolving list, and resumes GAP activity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup
[ https://issues.apache.org/jira/browse/MYNEWT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins reassigned MYNEWT-841: -- Assignee: Christopher Collins > BLE Host - Populate resolving list with persisted IRKs at startup > - > > Key: MYNEWT-841 > URL: https://issues.apache.org/jira/browse/MYNEWT-841 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > > (Pull request: https://github.com/apache/mynewt-core/pull/593) > Identity information gets persisted during pairing, but it is never restored > after a reboot. At startup (and on stack reset), the host should populate > the resolving list with the persisted entries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup
[ https://issues.apache.org/jira/browse/MYNEWT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-841: --- Description: (Pull request: https://github.com/apache/mynewt-core/pull/593) Identity information gets persisted during pairing, but it is never restored after a reboot. At startup (and on stack reset), the host should populate the resolving list with the persisted entries. was:Identity information gets persisted during pairing, but it is never restored after a reboot. At startup (and on stack reset), the host should populate the resolving list with the persisted entries. > BLE Host - Populate resolving list with persisted IRKs at startup > - > > Key: MYNEWT-841 > URL: https://issues.apache.org/jira/browse/MYNEWT-841 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins > > (Pull request: https://github.com/apache/mynewt-core/pull/593) > Identity information gets persisted during pairing, but it is never restored > after a reboot. At startup (and on stack reset), the host should populate > the resolving list with the persisted entries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list
[ https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-842: --- Description: If an attempt to add a peer's IRK to the resolving list fails, the failure is not reported, and the operation is not reattempted. Adding to the resolving list fails if the host is scanning or advertising at the time, so this is a common occurrence. I am not sure what the best solution is to this problem. I have a few ideas (order of increasing complexity): 1. The host passes the necessary information up to the application. It is then up to the application to populate the resolving list when possible (or not). 2. The host remembers the failed attempt and retries when in a suitable state (i.e., when advertising, scanning, and connecting has stopped). 3. The host temporarily suspends all GAP activity, adds the entry to the resolving list, and resumes GAP activity. was: If an attempt to add a peer's IRK to the resolving list fails, the failure is not reported, and the operation is not reattempted. Adding to the resolving list fails if the host is scanning or advertising at the time, so this is a common occurrence. I am not sure what the best solution is to this problem. I have a few ideas (order of increasing complexity): 1. The host passes the necessary information up to the application. It is then up to the application to populate the resolving list when possible, if desired. 2. The host remembers the failed attempt and retries when in a suitable state (i.e., when advertising, scanning, and connecting has stopped). 3. The host temporarily suspends all GAP activity, adds the entry to the resolving list, and resumes GAP activity. > BLE Host - Handle failure to add entry to resolving list > > > Key: MYNEWT-842 > URL: https://issues.apache.org/jira/browse/MYNEWT-842 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins > > If an attempt to add a peer's IRK to the resolving list fails, the failure is > not reported, and the operation is not reattempted. Adding to the resolving > list fails if the host is scanning or advertising at the time, so this is a > common occurrence. > I am not sure what the best solution is to this problem. I have a few ideas > (order of increasing complexity): > 1. The host passes the necessary information up to the application. It is > then up to the application to populate the resolving list when possible (or > not). > 2. The host remembers the failed attempt and retries when in a suitable state > (i.e., when advertising, scanning, and connecting has stopped). > 3. The host temporarily suspends all GAP activity, adds the entry to the > resolving list, and resumes GAP activity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list
[ https://issues.apache.org/jira/browse/MYNEWT-842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-842: --- Description: If an attempt to add a peer's IRK to the resolving list fails, the failure is not reported, and the operation is not reattempted. Adding to the resolving list fails if the host is scanning or advertising at the time, so this is a common occurrence. I am not sure what the best solution is to this problem. I have a few ideas (order of increasing complexity): 1. The host passes the necessary information up to the application. It is then up to the application to populate the resolving list when possible, if desired. 2. The host remembers the failed attempt and retries when in a suitable state (i.e., when advertising, scanning, and connecting has stopped). 3. The host temporarily suspends all GAP activity, adds the entry to the resolving list, and resumes GAP activity. was: If an attempt to add a peer's IRK to the resolving list fails, the failure is not reported, and the operation is not reattempted. Adding to the resolving list fails if the host is scanning or advertising at the time, so this is a common occurrence. I am not sure what the best solution is to this problem. I have a few ideas: 1. The host should pass the necessary information up to the application. It is up to the application to populate the resolving list when possible. 2. The host should remember the failed attempt and retry when it is in a suitable state (i.e., when advertising, scanning, and connecting has stopped). > BLE Host - Handle failure to add entry to resolving list > > > Key: MYNEWT-842 > URL: https://issues.apache.org/jira/browse/MYNEWT-842 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins > > If an attempt to add a peer's IRK to the resolving list fails, the failure is > not reported, and the operation is not reattempted. Adding to the resolving > list fails if the host is scanning or advertising at the time, so this is a > common occurrence. > I am not sure what the best solution is to this problem. I have a few ideas > (order of increasing complexity): > 1. The host passes the necessary information up to the application. It is > then up to the application to populate the resolving list when possible, if > desired. > 2. The host remembers the failed attempt and retries when in a suitable state > (i.e., when advertising, scanning, and connecting has stopped). > 3. The host temporarily suspends all GAP activity, adds the entry to the > resolving list, and resumes GAP activity. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-843) BLE Host - Missing local IRK functionality
Christopher Collins created MYNEWT-843: -- Summary: BLE Host - Missing local IRK functionality Key: MYNEWT-843 URL: https://issues.apache.org/jira/browse/MYNEWT-843 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Components: Nimble Reporter: Christopher Collins The host needs a few improvements involving the local identity resolving key (IRK): 1. Expose function to set the local IRK to a specified value (`ble_hs_test_util_set_our_irk()` is currently private). 2. Create a function to randomly generate a new IRK. 3. When a new local IRK is created, automatically persist it to the store. 4. On startup, restore the persisted IRK from the store. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-842) BLE Host - Handle failure to add entry to resolving list
Christopher Collins created MYNEWT-842: -- Summary: BLE Host - Handle failure to add entry to resolving list Key: MYNEWT-842 URL: https://issues.apache.org/jira/browse/MYNEWT-842 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Components: Nimble Reporter: Christopher Collins If an attempt to add a peer's IRK to the resolving list fails, the failure is not reported, and the operation is not reattempted. Adding to the resolving list fails if the host is scanning or advertising at the time, so this is a common occurrence. I am not sure what the best solution is to this problem. I have a few ideas: 1. The host should pass the necessary information up to the application. It is up to the application to populate the resolving list when possible. 2. The host should remember the failed attempt and retry when it is in a suitable state (i.e., when advertising, scanning, and connecting has stopped). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup
[ https://issues.apache.org/jira/browse/MYNEWT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-841: --- Component/s: Nimble > BLE Host - Populate resolving list with persisted IRKs at startup > - > > Key: MYNEWT-841 > URL: https://issues.apache.org/jira/browse/MYNEWT-841 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins > > Identity information gets persisted during pairing, but it is never restored > after a reboot. At startup (and on stack reset), the host should populate > the resolving list with the persisted entries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-841) BLE Host - Populate resolving list with persisted IRKs at startup
Christopher Collins created MYNEWT-841: -- Summary: BLE Host - Populate resolving list with persisted IRKs at startup Key: MYNEWT-841 URL: https://issues.apache.org/jira/browse/MYNEWT-841 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Reporter: Christopher Collins Identity information gets persisted during pairing, but it is never restored after a reboot. At startup (and on stack reset), the host should populate the resolving list with the persisted entries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-185) Clearly Define Linker script requirements
[ https://issues.apache.org/jira/browse/MYNEWT-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-185. Resolution: Fixed > Clearly Define Linker script requirements > - > > Key: MYNEWT-185 > URL: https://issues.apache.org/jira/browse/MYNEWT-185 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Reporter: Paul Dietrich >Assignee: Christopher Collins > Fix For: v1_2_0_rel > > > When building a BSP, you need a linker script. If we move the startup code > the MCU, we need to clearly define what variables need to be created in the > linker script -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-822) newtmgr - Native BLE - reconnect on immediate supervision timeout
[ https://issues.apache.org/jira/browse/MYNEWT-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-822: --- Description: (Pull request: https://github.com/apache/mynewt-newtmgr/pull/16) The first data packet to be exchanged over a BLE connection has a high probability of triggering a disconnect. The sending controller uses this packet to determine if the connection attempt was successful in the first place, and it does not get retried if it gets dropped. In the case of newtmgr, the first data packet gets sent during ATT MTU negotiation. The bhd (blehostd) transports recover from a disconnect during ATT MTU negotiation by reopening the session. The ble transports (native BLE) do not recover from such a disconnect. We should add the same recovery logic for the ble transports that has already been implemented for bhd. was: The first data packet to be exchanged over a BLE connection has a high probability of triggering a disconnect. The sending controller uses this packet to determine if the connection attempt was successful in the first place, and it does not get retried if it gets dropped. In the case of newtmgr, the first data packet gets sent during ATT MTU negotiation. The bhd (blehostd) transports recover from a disconnect during ATT MTU negotiation by reopening the session. The ble transports (native BLE) do not recover from such a disconnect. We should add the same recovery logic for the ble transports that has already been implemented for bhd. > newtmgr - Native BLE - reconnect on immediate supervision timeout > - > > Key: MYNEWT-822 > URL: https://issues.apache.org/jira/browse/MYNEWT-822 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: Newtmgr >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_2_0_rel > > > (Pull request: https://github.com/apache/mynewt-newtmgr/pull/16) > The first data packet to be exchanged over a BLE connection has a high > probability of triggering a disconnect. The sending controller uses this > packet to determine if the connection attempt was successful in the first > place, and it does not get retried if it gets dropped. > In the case of newtmgr, the first data packet gets sent during ATT MTU > negotiation. The bhd (blehostd) transports recover from a disconnect during > ATT MTU negotiation by reopening the session. > The ble transports (native BLE) do not recover from such a disconnect. We > should add the same recovery logic for the ble transports that has already > been implemented for bhd. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-821) newtmgr - Try harder to recover from disconnect during image upload
Christopher Collins created MYNEWT-821: -- Summary: newtmgr - Try harder to recover from disconnect during image upload Key: MYNEWT-821 URL: https://issues.apache.org/jira/browse/MYNEWT-821 Project: Mynewt Issue Type: Improvement Security Level: Public (Viewable by anyone) Components: Newtmgr Reporter: Christopher Collins Assignee: Christopher Collins An image upgrade consists of two phases: 1. Erase slot 2. Upload image On nRF boards, both phases cause the processor to stall while flash is being accessed. Such stalls can cause any established BLE connections to terminate due to "supervision timeout." Currently, the newtmgr tool automatically recovers from a disconnect during the first phase (erase). However, it does not recover from such a disconnect during the upload phase. Newtmgr should be improved to use the same reconnect logic during the second phase that it already uses during the first phase. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-411) newtmgr needs to be its own git repo
[ https://issues.apache.org/jira/browse/MYNEWT-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-411. Resolution: Fixed > newtmgr needs to be its own git repo > > > Key: MYNEWT-411 > URL: https://issues.apache.org/jira/browse/MYNEWT-411 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > repo created already in ASF. As a part of the unification efforts, we should > breakout newtmgr/connectivity tools from newt build tool. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-76) Add newt command to show a summary of licenses used in the stack
[ https://issues.apache.org/jira/browse/MYNEWT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-76: -- Fix Version/s: (was: v1_1_0_rel) > Add newt command to show a summary of licenses used in the stack > > > Key: MYNEWT-76 > URL: https://issues.apache.org/jira/browse/MYNEWT-76 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: Newt >Reporter: Aditi Hilbert >Assignee: Christopher Collins >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYNEWT-268) BLE - enable factory reset
[ https://issues.apache.org/jira/browse/MYNEWT-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075574#comment-16075574 ] Christopher Collins commented on MYNEWT-268: Pull request: https://github.com/apache/mynewt-core/pull/380 > BLE - enable factory reset > -- > > Key: MYNEWT-268 > URL: https://issues.apache.org/jira/browse/MYNEWT-268 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) >Reporter: Aditi Hilbert >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > The settings need to be stored in flash (sysvars). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYNEWT-757) Inconsistent tags among newt, blinky, and core
[
https://issues.apache.org/jira/browse/MYNEWT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073872#comment-16073872
]
Christopher Collins commented on MYNEWT-757:
*newt:*
Change newtutil.go from:
{noformat}
var NewtBlinkyTag string = "develop"
{noformat}
To:
{noformat}
var NewtBlinkyTag string = "mynewt_1_1_0_tag"
{noformat}
*blinky:*
Change project.yml from:
{noformat}
repository.apache-mynewt-core:
type: github
vers: 1-latest
user: apache
repo: mynewt-core
{noformat}
To:
{noformat}
repository.apache-mynewt-core:
type: github
vers: 1.1.0
user: apache
repo: mynewt-core
{noformat}
Of course, this should only be done after the 1.1.0 tag is created in all
repos, and apache-mynewt-core's repository.yml file is ammended to contain a
"1.1.0" reference to the proper tag.
> Inconsistent tags among newt, blinky, and core
> --
>
> Key: MYNEWT-757
> URL: https://issues.apache.org/jira/browse/MYNEWT-757
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Szymon Janc
> Fix For: v1_1_0_rel
>
>
> * "newt install" should download the corresponding version of blinky.
> * Blinky's project.yml should specify the corresponding version of core.
> Currently, the versions don't match up properly:
> * In master: newt specifies blinky's develop tag
> * In develop: blinky's project.yml specifies core's 1-latest tag.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-749) BLE Host - Crash during key persistence if key-dist settings are 0
[
https://issues.apache.org/jira/browse/MYNEWT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-749:
---
Description:
(Pull request: https://github.com/apache/mynewt-core/pull/370)
If BLE_SM_BONDING is enabled, but one of the the following settings is 0:
* BLE_SM_OUR_KEY_DIST
* BLE_SM_THEIR_KEY_DIST
then Mynewt crashes when pairing completes. Here is an example stack trace:
{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0,
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0 __assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0,
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x000181f8 in ble_store_persist_sec (obj_type=,
value_sec=) at net/nimble/host/src/ble_store.c:92
#2 0x000177ca in ble_sm_persist_keys (proc=0x181f9 )
at net/nimble/host/src/ble_sm.c:565
#3 ble_sm_process_result (conn_handle=conn_handle@entry=1,
res=res@entry=0x2000165c ) at
net/nimble/host/src/ble_sm.c:860
#4 0x0001792c in ble_sm_enc_event_rx (conn_handle=,
evt_status=, encrypted=1) at net/nimble/host/src/ble_sm.c:1042
#5 0x00017942 in ble_sm_enc_change_rx (evt=evt@entry=0x20001698
) at net/nimble/host/src/ble_sm.c:1051
#6 0x000153be in ble_hs_hci_evt_encrypt_change (event_code=,
data=0x20004c20 "\b\004", len=) at
net/nimble/host/src/ble_hs_hci_evt.c:163
#7 0x00015438 in ble_hs_hci_evt_process (data=0x20004c20 "\b\004") at
net/nimble/host/src/ble_hs_hci_evt.c:593
#8 0x9016 in os_eventq_run (evq=) at
kernel/os/src/os_eventq.c:172
#9 0x879e in main () at apps/bleprph/src/main.c:301
{noformat}
was:
# (Pull request:
If BLE_SM_BONDING is enabled, but one of the the following settings is 0:
* BLE_SM_OUR_KEY_DIST
* BLE_SM_THEIR_KEY_DIST
then Mynewt crashes when pairing completes. Here is an example stack trace:
{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0,
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0 __assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0,
e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x000181f8 in ble_store_persist_sec (obj_type=,
value_sec=) at net/nimble/host/src/ble_store.c:92
#2 0x000177ca in ble_sm_persist_keys (proc=0x181f9 )
at net/nimble/host/src/ble_sm.c:565
#3 ble_sm_process_result (conn_handle=conn_handle@entry=1,
res=res@entry=0x2000165c ) at
net/nimble/host/src/ble_sm.c:860
#4 0x0001792c in ble_sm_enc_event_rx (conn_handle=,
evt_status=, encrypted=1) at net/nimble/host/src/ble_sm.c:1042
#5 0x00017942 in ble_sm_enc_change_rx (evt=evt@entry=0x20001698
) at net/nimble/host/src/ble_sm.c:1051
#6 0x000153be in ble_hs_hci_evt_encrypt_change (event_code=,
data=0x20004c20 "\b\004", len=) at
net/nimble/host/src/ble_hs_hci_evt.c:163
#7 0x00015438 in ble_hs_hci_evt_process (data=0x20004c20 "\b\004") at
net/nimble/host/src/ble_hs_hci_evt.c:593
#8 0x9016 in os_eventq_run (evq=) at
kernel/os/src/os_eventq.c:172
#9 0x879e in main () at apps/bleprph/src/main.c:301
{noformat}
> BLE Host - Crash during key persistence if key-dist settings are 0
> --
>
> Key: MYNEWT-749
> URL: https://issues.apache.org/jira/browse/MYNEWT-749
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/mynewt-core/pull/370)
> If BLE_SM_BONDING is enabled, but one of the the following settings is 0:
> * BLE_SM_OUR_KEY_DIST
> * BLE_SM_THEIR_KEY_DIST
> then Mynewt crashes when pairing completes. Here is an example stack trace:
> {noformat}
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=file@entry=0x0, line=line@entry=0, func=func@entry=0x0,
> e=e@entry=0x0) at kernel/os/src/arch/cortex_m4/os_fault.c:137
> 137asm("bkpt");
> (gdb) whe
> #0 __assert_func (file=file@entry=0x0, line=line@entry=0,
> func=func@entry=0x0, e=e@entry=0x0) at
> kernel/os/src/arch/cortex_m4/os_fault.c:137
> #1 0x000181f8 in ble_store_persist_sec (obj_type=,
> value_sec=) at net/nimble/host/src/ble_store.c:92
> #2 0x000177ca in ble_sm_persist_keys (proc=0x181f9
> ) at net/nimble/host/src/ble_sm.c:565
> #3 ble_sm_process_result (conn_handle=conn_handle@entry=1,
> res=res@entry=0x2000165c
[jira] [Assigned] (MYNEWT-411) newtmgr needs to be its own git repo
[ https://issues.apache.org/jira/browse/MYNEWT-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins reassigned MYNEWT-411: -- Assignee: Christopher Collins (was: Marko Kiiskila) > newtmgr needs to be its own git repo > > > Key: MYNEWT-411 > URL: https://issues.apache.org/jira/browse/MYNEWT-411 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: v1_0_0_beta1 >Reporter: Sterling Hughes >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > repo created already in ASF. As a part of the unification efforts, we should > breakout newtmgr/connectivity tools from newt build tool. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-287) Host Flow Control
[ https://issues.apache.org/jira/browse/MYNEWT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-287: --- Fix Version/s: (was: v1_1_0_rel) v1_2_0_rel > Host Flow Control > - > > Key: MYNEWT-287 > URL: https://issues.apache.org/jira/browse/MYNEWT-287 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) > Components: Nimble > Environment: Using nimble from an external host stack >Reporter: Johan Hedberg >Assignee: Christopher Collins > Fix For: v1_2_0_rel > > > If the Nimble controller part is connected to an external host stack the host > may need to control the flow of ACL packets from the controller to the host. > This is particularly important for resource-constrained hosts that have a > limited amount of RX ACL data buffers. > The Bluetooth core specification provides a standard feature to accomplish > this called Host Flow Control. (Vol 2, Part E, Section 4.2). To implement > this the controller needs to support the "Set Controller To Host Flow > Control", "Host Buffer Size" and "Host Number Of Completed Packets" HCI > commands. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-791) syscfg - Only apply conditional overrides if condition is true
[
https://issues.apache.org/jira/browse/MYNEWT-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins resolved MYNEWT-791.
Resolution: Fixed
> syscfg - Only apply conditional overrides if condition is true
> --
>
> Key: MYNEWT-791
> URL: https://issues.apache.org/jira/browse/MYNEWT-791
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-newt/pull/73)
> This commit fixes a bug involving conditional overrides of syscfg values. In
> the following syscfg listing:
> {noformat}
> syscfg.vals.MY_SETTING:
> LOG_LEVEL: 255
> {noformat}
> LOG_LEVEL should only get set to 255 if MY_SETTING is defined with a true
> value (nonzero and non-empty-string). However, the actual behavior is that
> LOG_LEVEL gets overridden if MY_SETTING is defined at all, regardless of its
> value.
> The fix is to only apply the override if the condition is true.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYNEWT-790) syscfg - Allow a package to override its own setting
[
https://issues.apache.org/jira/browse/MYNEWT-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-790:
---
Description:
(Pull request: https://github.com/apache/incubator-mynewt-newt/pull/74)
PKG-A can only override a setting defined by PKG-B if PKG-A has a greater
priority than PKG-B. If PKG-A's priority is less than or equal to PKG-B's, the
override attempt is rejected and reported as a priority violation.
This commit relaxes that rule slightly: a package can override settings that it
itself defines.
This behavior is needed for making a setting's default value conditional on
another setting. For example:
{noformat}
syscfg.defs:
TIMER_0:
description: 'NRF52 Timer 0'
value: 1
TIMER_3:
description: 'NRF52 Timer 3'
value: 0
# Use timer 3 instead of timer 0 if target wants to use the low
# power clock.
syscfg.vals.BLE_LP_CLOCK:
TIMER_0: 0
TIMER_3: 1
{noformat}
was:
(Pull request: https://github.com/apache/incubator-mynewt-newt/pull/74)
PKG-A can only override a setting defined by PKG-B if PKG-A has a greater
priority than PKG-B. If PKG-A's priority is less than or equal to PKG-B's, the
override attempt is rejected and reported as a priority violation.
This commit relaxes that rule slightly: a package can override settings that it
itself defines.
This behavior is needed for making a setting's default value conditional on
another setting. For example:
{noformat}
syscfg.defs:
TIMER_0:
description: 'NRF52 Timer 0'
value: 1
TIMER_3:
description: 'NRF52 Timer 3'
value: 0
# Use timer 3 instead of timer 0 if target wants to use the low
# power clock.
syscfg.vals.BLE_LP_CLOCK:
TIMER_0: 0
TIMER_1: 1
{noformat}
> syscfg - Allow a package to override its own setting
> -
>
> Key: MYNEWT-790
> URL: https://issues.apache.org/jira/browse/MYNEWT-790
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Labels: doc
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-newt/pull/74)
> PKG-A can only override a setting defined by PKG-B if PKG-A has a greater
> priority than PKG-B. If PKG-A's priority is less than or equal to PKG-B's,
> the override attempt is rejected and reported as a priority violation.
> This commit relaxes that rule slightly: a package can override settings that
> it itself defines.
> This behavior is needed for making a setting's default value conditional on
> another setting. For example:
> {noformat}
> syscfg.defs:
> TIMER_0:
> description: 'NRF52 Timer 0'
> value: 1
> TIMER_3:
> description: 'NRF52 Timer 3'
> value: 0
> # Use timer 3 instead of timer 0 if target wants to use the low
> # power clock.
> syscfg.vals.BLE_LP_CLOCK:
> TIMER_0: 0
> TIMER_3: 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MYNEWT-790) syscfg - Allow a package to override its own setting
Christopher Collins created MYNEWT-790:
--
Summary: syscfg - Allow a package to override its own setting
Key: MYNEWT-790
URL: https://issues.apache.org/jira/browse/MYNEWT-790
Project: Mynewt
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Components: Newt
Reporter: Christopher Collins
Assignee: Christopher Collins
Fix For: v1_1_0_rel
(Pull request: https://github.com/apache/incubator-mynewt-newt/pull/74)
PKG-A can only override a setting defined by PKG-B if PKG-A has a greater
priority than PKG-B. If PKG-A's priority is less than or equal to PKG-B's, the
override attempt is rejected and reported as a priority violation.
This commit relaxes that rule slightly: a package can override settings that it
itself defines.
This behavior is needed for making a setting's default value conditional on
another setting. For example:
{noformat}
syscfg.defs:
TIMER_0:
description: 'NRF52 Timer 0'
value: 1
TIMER_3:
description: 'NRF52 Timer 3'
value: 0
# Use timer 3 instead of timer 0 if target wants to use the low
# power clock.
syscfg.vals.BLE_LP_CLOCK:
TIMER_0: 0
TIMER_1: 1
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYNEWT-756) mpstats (on nrf51) hangs indefinately
[
https://issues.apache.org/jira/browse/MYNEWT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16057958#comment-16057958
]
Christopher Collins commented on MYNEWT-756:
I believe it is failing because your newtmgr client is using a lower BLE MTU.
Incoming data gets distributed among mbufs according to how it was fragmented
by the sender. On my macbook, Mac OS uses an MTU of 104, while the "new"
newtmgr uses something between 256 and 517, depending on how both peers are
configured.
I was able to get mpstats working on a 16kB nRF51dk using an MTU of 104 with
the following settings:
{noformat}
MSYS_1_BLOCK_COUNT: 22
MSYS_1_BLOCK_SIZE: 110
{noformat}
Could you give that a try and let me know if it works?
> mpstats (on nrf51) hangs indefinately
> -
>
> Key: MYNEWT-756
> URL: https://issues.apache.org/jira/browse/MYNEWT-756
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Jacob
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> I believe core is failing before sending the last packet, as neither newtmgr
> or node-newtmgr receives that packet.
> Jacobs-MacBook-Air:newtmgr jacobrosenthal$ GODEBUG=cgocheck=0 newtmgr mpstats
> -cnimble_bleprph -t -ldebug
> 2017/05/11 22:28:46 [DEBUG] BLE Connection devaddr:[]
> 2017/05/11 22:28:46 [DEBUG] State:PoweredOn
> 2017/05/11 22:28:46 [DEBUG] scanning...
> 2017/05/11 22:28:46 [DEBUG] Peripheral Discovered: , Address:[0 0 0 0 0 0]
> Address Type:0
> 2017/05/11 22:28:47 Unhandled event: xpc.Dict{"kCBMsgId":53,
> "kCBMsgArgs":xpc.Dict{"kCBMsgArgDeviceUUID":xpc.UUID{0x2f, 0xd, 0xcb, 0x60,
> 0xf, 0x3e, 0x47, 0x52, 0xb7, 0x74, 0x13, 0x29, 0x3a, 0x3, 0xd4, 0xd0},
> "kCBMsgArgATTMTU":104}}
> 2017/05/11 22:28:47 [DEBUG] Peripheral Connected
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Service Found
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Characteristic Found
> 2017/05/11 22:28:47 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0
> Group:0 Seq:0 Id:3 Data:[]}
> 2017/05/11 22:28:47 [DEBUG] Serializing request &{Op:0 Flags:0 Len:0 Group:0
> Seq:0 Id:3 Data:[]} into buffer [0 0 0 0 0 0 0 3]
> 2017/05/11 22:28:47 [DEBUG] Tx packet dump:
> 00 00 00 00 00 00 00 03 ||
> 2017/05/11 22:28:47 [DEBUG] Write BLE Packet:buf:: len::8
> 2017/05/11 22:28:47 [DEBUG] Read BLE
> Packet:buf::l?brcfmpools?fmsys_1?fblksiz$enblks
>
> enfreecmin?wble_hci_ram_evt_hi_pool?fblksizHenblkse len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
> 01 00 02 6c 00 00 00 03 bf 62 72 63 00 66 6d 70 |...l.brc.fmp|
> 0010 6f 6f 6c 73 bf 66 6d 73 79 73 5f 31 bf 66 62 6c |ools.fmsys_1.fbl|
> 0020 6b 73 69 7a 19 01 24 65 6e 62 6c 6b 73 0c 65 6e |ksiz..$enblks.en|
> 0030 66 72 65 65 09 63 6d 69 6e 00 ff 77 62 6c 65 5f |free.cmin..wble_|
> 0040 68 63 69 5f 72 61 6d 5f 65 76 74 5f 68 69 5f 70 |hci_ram_evt_hi_p|
> 0050 6f 6f 6c bf 66 62 6c 6b 73 69 7a 18 48 65 6e 62 |ool.fblksiz.Henb|
> 0060 6c 6b 73 02 65|lks.e|
> 2017/05/11 22:28:47 [DEBUG] Deserialized response &{Op:1 Flags:0 Len:620
> Group:0 Seq:0 Id:3 Data:[191 98 114 99 0 102 109 112 111 111 108 115 191 102
> 109 115 121 115 95 49 191 102 98 108 107 115 105 122 25 1 36 101 110 98 108
> 107 115 12 101 110 102 114 101 101 9 99 109 105 110 0 255 119 98 108 101 95
> 104 99 105 95 114 97 109 95 101 118 116 95 104 105 95 112 111 111 108 191 102
> 98 108 107 115 105 122 24 72 101 110 98 108 107 115 2 101]}
> 2017/05/11 22:28:47 [DEBUG] Read BLE
> Packet:buf::nfreecmin?wble_hci_ram_evt_lo_pool?fblksizHenblkenfrecmi?rble_hs_hci_ev_pool?fblksizenblks
> len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
> 6e 66 72 65 65 02 63 6d 69 6e 00 ff 77 62 6c 65 |nfree.cmin..wble|
> 0010 5f 68 63 69 5f 72 61 6d 5f 65 76 74 5f 6c 6f 5f |_hci_ram_evt_lo_|
> 0020 70 6f 6f 6c bf 66 62 6c 6b 73 69 7a 18 48 65 6e |pool.fblksiz.Hen|
> 0030 62 6c 6b 73 08 65 6e 66 72 65 65 08 63 6d 69 6e |blks.enfree.cmin|
> 0040 08 ff 72 62 6c 65 5f 68 73 5f 68 63 69 5f 65 76 |..rble_hs_hci_ev|
> 0050 5f 70 6f 6f 6c bf 66 62 6c 6b 73 69 7a 10 65 6e |_pool.fblksiz.en|
> 0060 62 6c 6b 73 0a|blks.|
> 2017/05/11 22:28:47 [DEBUG] Read BLE Packet:buf::enfree
> cmin
> ?pble_hs_conn_pool?fblksizTenblksenfreecmin?sble_l2cap_chan_pool?fblksizenblksenfr
> len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
> 65 6e 66 72 65 65 0a 63 6d 69 6e 09 ff 70 62 6c |enfree.cmin..pbl|
> 0010 65 5f 68 73 5f 63 6f 6e 6e 5f 70 6f 6f 6c bf 66 |e_hs_conn_pool.f|
> 0020 62 6c 6b 73 69
[jira] [Resolved] (MYNEWT-787) serial boot loader - newtmgr buffer overruns
[ https://issues.apache.org/jira/browse/MYNEWT-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-787. Resolution: Fixed > serial boot loader - newtmgr buffer overruns > > > Key: MYNEWT-787 > URL: https://issues.apache.org/jira/browse/MYNEWT-787 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/340) > The serial boot loader fails to process some newtmgr commands: > 1. The image list response is too large for the outgoing buffer. > 2. The "new" newtmgr sends large image chunks in its image upload requests. > These chunks are too large for the serial boot loader's input buffer. > The fixes are as follows: > 1. Increase the outgoing buffer size from 48 to 80. > 2. Increase the incoming buffer size from 128 to 512. > 3. Return an error rather than overrun the output buffer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-787) serial boot loader - newtmgr buffer overruns
[ https://issues.apache.org/jira/browse/MYNEWT-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-787: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/340) The serial boot loader fails to process some newtmgr commands: 1. The image list response is too large for the outgoing buffer. 2. The "new" newtmgr sends large image chunks in its image upload requests. These chunks are too large for the serial boot loader's input buffer. The fixes are as follows: 1. Increase the outgoing buffer size from 48 to 80. 2. Increase the incoming buffer size from 128 to 512. 3. Return an error rather than overrun the output buffer. was: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/340) The serial boot loader fails to process some newtmgr commands: 1. The image list response is too large for the outgoing buffer. 2. The "new" newtmgr sends large image chunks in its image upload requests. These chunks are too large for the serial boot loader's input buffer. The fixes are as follows: 1. Increase the outgoing buffer size from 48 to 128. 2. Increase the incoming buffer size from 128 to 512. 3. Return an error rather than overrun the output buffer. > serial boot loader - newtmgr buffer overruns > > > Key: MYNEWT-787 > URL: https://issues.apache.org/jira/browse/MYNEWT-787 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/340) > The serial boot loader fails to process some newtmgr commands: > 1. The image list response is too large for the outgoing buffer. > 2. The "new" newtmgr sends large image chunks in its image upload requests. > These chunks are too large for the serial boot loader's input buffer. > The fixes are as follows: > 1. Increase the outgoing buffer size from 48 to 80. > 2. Increase the incoming buffer size from 128 to 512. > 3. Return an error rather than overrun the output buffer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-787) serial boot loader - newtmgr buffer overruns
[ https://issues.apache.org/jira/browse/MYNEWT-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-787: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/340) The serial boot loader fails to process some newtmgr commands: 1. The image list response is too large for the outgoing buffer. 2. The "new" newtmgr sends large image chunks in its image upload requests. These chunks are too large for the serial boot loader's input buffer. The fixes are as follows: 1. Increase the outgoing buffer size from 48 to 128. 2. Increase the incoming buffer size from 128 to 512. 3. Return an error rather than overrun the output buffer. was: The serial boot loader fails to process some newtmgr commands: 1. The image list response is too large for the outgoing buffer. 2. The "new" newtmgr sends large image chunks in its image upload requests. These chunks are too large for the serial boot loader's input buffer. The fixes are as follows: 1. Increase the outgoing buffer size from 48 to 128. 2. Increase the incoming buffer size from 128 to 512. 3. Return an error rather than overrun the output buffer. > serial boot loader - newtmgr buffer overruns > > > Key: MYNEWT-787 > URL: https://issues.apache.org/jira/browse/MYNEWT-787 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/340) > The serial boot loader fails to process some newtmgr commands: > 1. The image list response is too large for the outgoing buffer. > 2. The "new" newtmgr sends large image chunks in its image upload requests. > These chunks are too large for the serial boot loader's input buffer. > The fixes are as follows: > 1. Increase the outgoing buffer size from 48 to 128. > 2. Increase the incoming buffer size from 128 to 512. > 3. Return an error rather than overrun the output buffer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-787) serial boot loader - newtmgr buffer overruns
Christopher Collins created MYNEWT-787: -- Summary: serial boot loader - newtmgr buffer overruns Key: MYNEWT-787 URL: https://issues.apache.org/jira/browse/MYNEWT-787 Project: Mynewt Issue Type: New Feature Security Level: Public (Viewable by anyone) Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel The serial boot loader fails to process some newtmgr commands: 1. The image list response is too large for the outgoing buffer. 2. The "new" newtmgr sends large image chunks in its image upload requests. These chunks are too large for the serial boot loader's input buffer. The fixes are as follows: 1. Increase the outgoing buffer size from 48 to 128. 2. Increase the incoming buffer size from 128 to 512. 3. Return an error rather than overrun the output buffer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-786) newtmgr - BLE support that doesn't require blehostd
Christopher Collins created MYNEWT-786: -- Summary: newtmgr - BLE support that doesn't require blehostd Key: MYNEWT-786 URL: https://issues.apache.org/jira/browse/MYNEWT-786 Project: Mynewt Issue Type: New Feature Security Level: Public (Viewable by anyone) Components: Newtmgr Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel newtmgr currently supports BLE as a transport via blehostd, a NimBLE host running in a simulated OS. This implementation works, but it comes with the following issues: * Inability to use the built-in Bluetooth controller in MacOS. * Hassle of setting up and configuring blehostd. The task captured in this ticket is to add a second form of BLE support to newtmgr which addresses these shortcomings. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-755) newtmgr panic: runtime error: cgo argument has Go pointer to Go pointer
[ https://issues.apache.org/jira/browse/MYNEWT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-755. Resolution: Won't Fix Ah, I see. Sorry... somehow I missed that you were using a BLE connection profile. The gatt library (what newtmgr uses for BLE connectivity) doesn't work in Mac OS. That is why you're seeing that ugly crash dump. We could add a proper error message instead of the crash, but I don't think it matters too much in this case because we'll be replacing that version of newtmgr with one that actually does work in Mac OS: https://github.com/apache/incubator-mynewt-newtmgr > newtmgr panic: runtime error: cgo argument has Go pointer to Go pointer > --- > > Key: MYNEWT-755 > URL: https://issues.apache.org/jira/browse/MYNEWT-755 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Newtmgr >Reporter: Jacob >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > Googling seems to indicate maybe it needs refactoring? > https://github.com/ry/v8worker/issues/31 > Ive tried back to mynewt_1_0_0_b2_tag and it still happens so I think its > tied to again either xcode update or maybe a go point release? > Jacobs-MacBook-Air:newtmgr jacobrosenthal$ go version > go version go1.7.5 darwin/amd64 > My xcode is 8.3.2 > But I can confirm the listed workaround is to use GODEBUG=cgocheck=0 works > but I get (possibly unrelated?) unhandled xpc events as well -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-310) newt should globally namespace remote repositories
[ https://issues.apache.org/jira/browse/MYNEWT-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-310: --- Fix Version/s: (was: v1_1_0_rel) > newt should globally namespace remote repositories > -- > > Key: MYNEWT-310 > URL: https://issues.apache.org/jira/browse/MYNEWT-310 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) >Reporter: Sterling Hughes >Assignee: Christopher Collins > > Right now remote repositories can have conflicting names (e.g. somebody else > could reserve apache-mynewt-core, and newt wouldn't have a way of resolving > the conflict.) > Need some form of global namespacing on repository descriptors, whether using > the DNS name (ala go), or some other sort of registry. > This will become important once inter-repository dependencies and mirroring > come into play. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MYNEWT-190) Support automatically sending failure logs for newt
[ https://issues.apache.org/jira/browse/MYNEWT-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins reassigned MYNEWT-190: -- Assignee: (was: Christopher Collins) Fix Version/s: (was: v1_1_0_rel) > Support automatically sending failure logs for newt > > > Key: MYNEWT-190 > URL: https://issues.apache.org/jira/browse/MYNEWT-190 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: Newt >Reporter: Sterling Hughes > > When newt fails to build, or users experience newt failures. There should be > an option to create a log bundle that can be sent to Mynewt, or automatically > posted and create JIRA ticket in the Mynewt ASF system. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (MYNEWT-120) Add generation of IDE project files into newt
[ https://issues.apache.org/jira/browse/MYNEWT-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins reassigned MYNEWT-120: -- Assignee: (was: Christopher Collins) Fix Version/s: (was: v1_1_0_rel) > Add generation of IDE project files into newt > - > > Key: MYNEWT-120 > URL: https://issues.apache.org/jira/browse/MYNEWT-120 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: Newt >Reporter: Sterling Hughes >Priority: Minor > > Add support for generating IDE project files from the newt tool: > - Eclipse > - Sublime > - Makefile -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-325) BLE Host - Allow ECC to be delegated to the controller
[ https://issues.apache.org/jira/browse/MYNEWT-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-325: --- Fix Version/s: (was: v1_1_0_rel) > BLE Host - Allow ECC to be delegated to the controller > -- > > Key: MYNEWT-325 > URL: https://issues.apache.org/jira/browse/MYNEWT-325 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins >Priority: Minor > > The host currently does all ECC operations in software using the tinycrypt > library. We need to: > * Implement the ECC HCI commands in the host and controller. > * Create a build option which: > ** Enables ECC functionality in the controller. > ** Disables ECC functionality in the host. > ** Makes the host use the HCI commands rather than call into tinycrypt. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-38) Implement ECC correction in NFFS
[ https://issues.apache.org/jira/browse/MYNEWT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-38: -- Fix Version/s: (was: v1_1_0_rel) > Implement ECC correction in NFFS > > > Key: MYNEWT-38 > URL: https://issues.apache.org/jira/browse/MYNEWT-38 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) > Components: NFFS >Reporter: Sterling Hughes >Assignee: Christopher Collins > > Data stored in NFFS files should optionally have ECC coding applied to them > to correct for data corruption. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-301) nffs corrupt
[ https://issues.apache.org/jira/browse/MYNEWT-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-301: --- Fix Version/s: (was: v1_1_0_rel) > nffs corrupt > > > Key: MYNEWT-301 > URL: https://issues.apache.org/jira/browse/MYNEWT-301 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: NFFS >Affects Versions: v1_0_0_beta2 >Reporter: Marko Kiiskila >Assignee: Christopher Collins > Attachments: bad_arduino_nffs.bin, bad_arduino_nffs.bin2 > > > happened on arduino, bootloader does not come up as NFFS is asserting. > (gdb) bt > #0 __assert_func (file=0x742a "nffs_restore.c", line=229, func=0x0 > <_sfixed>, > e=0x0 <_sfixed>) at os_fault.c:113 > #1 0x22ac in nffs_restore_find_file_ends () at nffs_restore.c:285 > #2 nffs_restore_full (area_descs=area_descs@entry=0x2000736c) > at nffs_restore.c:1160 > #3 0x04ca in nffs_detect (area_descs=area_descs@entry=0x2000736c) > at nffs.c:605 > #4 0x01e8 in setup_for_nffs () at boot.c:80 > #5 main () at boot.c:160 > (gdb) up -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-37) Implement FS compression in NFFS
[ https://issues.apache.org/jira/browse/MYNEWT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-37: -- Fix Version/s: (was: v1_1_0_rel) > Implement FS compression in NFFS > > > Key: MYNEWT-37 > URL: https://issues.apache.org/jira/browse/MYNEWT-37 > Project: Mynewt > Issue Type: New Feature > Security Level: Public(Viewable by anyone) > Components: NFFS >Reporter: Sterling Hughes >Assignee: Christopher Collins > > Compression should be supported in NFFS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-13) NFFS does not work on STM32F3 or NXP MK64F12
[ https://issues.apache.org/jira/browse/MYNEWT-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-13: -- Fix Version/s: (was: v1_1_0_rel) > NFFS does not work on STM32F3 or NXP MK64F12 > > > Key: MYNEWT-13 > URL: https://issues.apache.org/jira/browse/MYNEWT-13 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: NFFS >Reporter: Marko Kiiskila >Assignee: Christopher Collins >Priority: Minor > > STM32F3 flash writes are done 2 bytes at a time. MK64F12 flash alignment is > 8. NFFS should take into account alignment restrictions underlying storage > has. > E.g. add alignment requirement in struct hal_flash. Add an HAL flash API call > to query this. NFFS would then use this when writing/reading blocks of data > from flash. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-338) NFFS - Can't delete from a completely full file system
[ https://issues.apache.org/jira/browse/MYNEWT-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-338: --- Fix Version/s: (was: v1_1_0_rel) > NFFS - Can't delete from a completely full file system > -- > > Key: MYNEWT-338 > URL: https://issues.apache.org/jira/browse/MYNEWT-338 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: NFFS >Reporter: Christopher Collins >Assignee: Christopher Collins > > Deleting a file or directory requires writing an inode to the disk. If the > disk is completely full, there is not room for the deletion record, and the > delete attempt will fail with an FS_EFULL error. > It should be sufficient to always ensure that at least one area has room for > a deletion record. All deletion records are the same size. Once a deletion > record is written, the previous inode entry and all children inodes or > constituent data blocks can be removed during garbage collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MYNEWT-343) nffs crash at bootloader
[
https://issues.apache.org/jira/browse/MYNEWT-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-343:
---
Fix Version/s: (was: v1_1_0_rel)
> nffs crash at bootloader
>
>
> Key: MYNEWT-343
> URL: https://issues.apache.org/jira/browse/MYNEWT-343
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: NFFS
> Environment: Arduino Zero with NFFS
>Reporter: Marko Kiiskila
>Assignee: Christopher Collins
> Attachments: arduino_nffs.bin, nffs-inode-invalid-id.bin
>
>
> System asserts. I was switching between images.
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=, line=,
> func=, e=) at os_fault.c:124
> 124 asm("bkpt");
> (gdb) bt
> #0 __assert_func (file=, line=,
> func=, e=) at os_fault.c:124
> #1 0x105e in nffs_hash_remove (entry=entry@entry=0x20001ad8)
> at nffs_hash.c:179
> #2 0x2ff2 in nffs_block_delete_from_ram (
> block_entry=block_entry@entry=0x20001ad8) at nffs_block.c:266
> #3 0x26f2 in nffs_restore_sweep () at nffs_restore.c:353
> #4 0x283e in nffs_restore_full (area_descs=area_descs@entry=0x2000736c)
> at nffs_restore.c:1400
> #5 0x04ca in nffs_detect (area_descs=area_descs@entry=0x2000736c)
> at nffs.c:606
> #6 0x01e8 in setup_for_nffs () at boot.c:93
> #7 main () at boot.c:173
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (MYNEWT-759) Change BLE-over-CoAP UUID from 128-bit to 16-bit
[ https://issues.apache.org/jira/browse/MYNEWT-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-759. Resolution: Won't Fix This will be part of the cloud connector package, not the 1.1.0 release. > Change BLE-over-CoAP UUID from 128-bit to 16-bit > > > Key: MYNEWT-759 > URL: https://issues.apache.org/jira/browse/MYNEWT-759 > Project: Mynewt > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > The plan is to reserve a 16-bit UUID with the Bluetooth SIG. In the > meantime, we will use the (arbitrarilly chosen) UUID 0x9923. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-664) coredownload newtmgr command should indicate core size in first response
[ https://issues.apache.org/jira/browse/MYNEWT-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-664. Resolution: Fixed > coredownload newtmgr command should indicate core size in first response > > > Key: MYNEWT-664 > URL: https://issues.apache.org/jira/browse/MYNEWT-664 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/312) > This would be analogous to the "image upload", "file upload", and "file > download" commands. Each of these indicate the total number of bytes in the > first packet. > This change involves a backwards compatible modification to the NMP protocol. > Compatibility is maintained because this change only requires the addition > of a new field, not the modification or removal of existing fields. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (MYNEWT-752) Error in setting the "permanent" flag upon confirm with hash during image upgrade
[ https://issues.apache.org/jira/browse/MYNEWT-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-752. Resolution: Fixed > Error in setting the "permanent" flag upon confirm with hash during image > upgrade > - > > Key: MYNEWT-752 > URL: https://issues.apache.org/jira/browse/MYNEWT-752 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Aditi Hilbert >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > This is an issue seen during image upgrade. When doing a "confirm" with a > hash, newtmgr always marks the "permanent" flag for Slot 1 image to "true", > irrespective of which image the hash matches. > This works fine when we skip the "test" step during image upgrade and we > issue a "confirm" with a hash of the new image in Slot 1. > However, if we do the "test" step (when the new image is swapped into Slot > 0), and we then do a "confirm" with a hash of the new image and reboot, the > device marks the old image in Slot 1 as "permanent" and swaps it back to Slot > 0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MYNEWT-778) newt - "newt run" fails for native targets
Christopher Collins created MYNEWT-778: -- Summary: newt - "newt run" fails for native targets Key: MYNEWT-778 URL: https://issues.apache.org/jira/browse/MYNEWT-778 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Components: Newt Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel This issue seems to have been introduced by MYNEWT-694. If the user runs "newt run" without specifying a version number, newt prompts the user for a version number and uses it to build an image. This behavior is correct most of the time, but it is incorrect for sim targets. Sim targets use plain elf files, not image files, so newt shouldn't prompt the user for a version number in this case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-364) Don't use bash scripts
[
https://issues.apache.org/jira/browse/MYNEWT-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-364:
---
Fix Version/s: (was: v1_1_0_rel)
> Don't use bash scripts
> --
>
> Key: MYNEWT-364
> URL: https://issues.apache.org/jira/browse/MYNEWT-364
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Affects Versions: v0_9_0
> Environment: Ubuntu 14.10 using the Docker version of newt
>Reporter: Tim
>Assignee: Christopher Collins
>
> The download and debug scripts are currently written using Bash. That is
> unfortunate because Bash is very error-prone and scripts tend to be buggy.
> Also, it makes distribution on Windows much harder.
> You're already using Go, I'd suggest rewriting them using that. Alternatives
> are Python, Powershell, Lua, etc.
> I've rewritten nrf52_download.sh in Go (below; compiled but not tested). It
> was very easy, and is only 7 lines longer (due to extra error
> checking/reporting).
> The main downside is the size - 2.7 MB, but it can be reduced to 523 kB by
> stripping debug symbols and compressing it with upx. I think that is
> reasonable for now. You can combine debug and download scripts for further
> savings if necessary.
> {code}
> // Licensed to the Apache Software Foundation (ASF) under one
> // or more contributor license agreements. See the NOTICE file
> // distributed with this work for additional information
> // regarding copyright ownership. The ASF licenses this file
> // to you under the Apache License, Version 2.0 (the
> // "License"); you may not use this file except in compliance
> // with the License. You may obtain a copy of the License at
> //
> // http://www.apache.org/licenses/LICENSE-2.0
> //
> // Unless required by applicable law or agreed to in writing,
> // software distributed under the License is distributed on an
> // "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> // KIND, either express or implied. See the License for the
> // specific language governing permissions and limitations
> // under the License.
> package main
> import (
> "fmt"
> "io/ioutil"
> "log"
> "os"
> "os/exec"
> "strings"
> )
> func main() {
> if len(os.Args) == 1 {
> log.Fatalf(`
> Usage: {} [features...]
> - bsp_directory_path is absolute path to hw/bsp/bsp_name
> - binary is the path to prefix to target binary, .elf.bin appended to this
> name is the raw binary format of the binary.
> - features are the target features. So you can have e.g. different
> flash offset for bootloader 'feature')
> `, os.Args[0])
> }
> if len(os.Args) < 3 {
> log.Fatal("Need binary to download")
> }
> // Look for 'bootloader' from 3rd arg onwards (in the features)
> isBootloader := false
> if len(os.Args) > 3 {
> for i := range os.Args[3:] {
> if os.Args[i] == "bootloader" {
> isBootloader = true
> }
> }
> }
> basename := os.Args[2]
> flashOffset := 0x8000
> filename := basename + ".img"
> if isBootloader {
> flashOffset = 0
> filename = basename + ".elf.bin"
> }
> gdbCmdFile := ".gdb_cmds"
> log.Printf("Downloading %s to %#x", filename, flashOffset)
> // XXX for some reason JLinkExe overwrites flash at offset 0 when
> // downloading somewhere in the flash. So need to figure out how to
> tell it
> // not to do that, or report failure if gdb fails to write this file
> gdbCmds := fmt.Sprintf(`
> shell /bin/sh -c 'trap \"\" 2;JLinkGDBServer -device nRF52 -speed 4000 -if
> SWD -port -singlerun' &
> target remote localhost:
> restore %s binary %#x
> quit
> `, filename, flashOffset)
> err := ioutil.WriteFile(gdbCmdFile, []byte(gdbCmds), 0664)
> if err != nil {
> log.Fatalf("Error writing to %s: %v", gdbCmdFile, err)
> }
> defer os.Remove(gdbCmdFile)
> msgs, err := exec.Command("arm-none-eabi-gdb", "-x",
> gdbCmdFile).CombinedOutput()
> ioutil.WriteFile(".gdb_out", msgs, 0664)
> if err != nil {
> log.Fatalf("Error running gdb: %v", err)
> }
> smsgs := string(msgs)
> if strings.Contains(smsgs, "error") ||
> strings.Contains(smsgs, "failed") ||
> strings.Contains(smsgs, "unknown / supported") ||
> strings.Contains(smsgs, "No such file or directory") {
> os.Exit(1)
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
[ https://issues.apache.org/jira/browse/MYNEWT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-774. Resolution: Fixed > Intermittent serial errors in newtmgr messages on Arduino Zero > -- > > Key: MYNEWT-774 > URL: https://issues.apache.org/jira/browse/MYNEWT-774 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/323) > Using the nmgr_shell transport (newtmgr over shell), some incoming commands > get dropped. The problem seems to be caused by an exhaustion of shell events. > By default, the shell only allocates a single event. > The sequence looks like this: > # Client sends newtmgr command to device. > # Console passes newtmgr command to shell. > # Shell allocates the only event and fills it with the data. > # Shell processes event, hands data to newtmgr code. > # Newtmgr processes command and sends response. > # Client sees response and sends follow-up command. > # Console passes newtmgr command to shell. > # Shell has no events left; drops incoming command. > # Initial event gets freed. > By changing the default event count from 1 to 2, we ensure there is always a > spare event available. Since we will never send the second response before > freeing the first event, two events is sufficient. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
[ https://issues.apache.org/jira/browse/MYNEWT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-774: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/323) Using the nmgr_shell transport (newtmgr over shell), some incoming commands get dropped. The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. was: Using the nmgr_shell transport (newtmgr over shell), some incoming commands get dropped. The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. > Intermittent serial errors in newtmgr messages on Arduino Zero > -- > > Key: MYNEWT-774 > URL: https://issues.apache.org/jira/browse/MYNEWT-774 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/323) > Using the nmgr_shell transport (newtmgr over shell), some incoming commands > get dropped. The problem seems to be caused by an exhaustion of shell events. > By default, the shell only allocates a single event. > The sequence looks like this: > # Client sends newtmgr command to device. > # Console passes newtmgr command to shell. > # Shell allocates the only event and fills it with the data. > # Shell processes event, hands data to newtmgr code. > # Newtmgr processes command and sends response. > # Client sees response and sends follow-up command. > # Console passes newtmgr command to shell. > # Shell has no events left; drops incoming command. > # Initial event gets freed. > By changing the default event count from 1 to 2, we ensure there is always a > spare event available. Since we will never send the second response before > freeing the first event, two events is sufficient. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
[ https://issues.apache.org/jira/browse/MYNEWT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-774: --- Description: Using the nmgr_shell transport (newtmgr over shell), some incoming commands get dropped. The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. was: The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. > Intermittent serial errors in newtmgr messages on Arduino Zero > -- > > Key: MYNEWT-774 > URL: https://issues.apache.org/jira/browse/MYNEWT-774 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > Using the nmgr_shell transport (newtmgr over shell), some incoming commands > get dropped. The problem seems to be caused by an exhaustion of shell events. > By default, the shell only allocates a single event. > The sequence looks like this: > # Client sends newtmgr command to device. > # Console passes newtmgr command to shell. > # Shell allocates the only event and fills it with the data. > # Shell processes event, hands data to newtmgr code. > # Newtmgr processes command and sends response. > # Client sees response and sends follow-up command. > # Console passes newtmgr command to shell. > # Shell has no events left; drops incoming command. > # Initial event gets freed. > By changing the default event count from 1 to 2, we ensure there is always a > spare event available. Since we will never send the second response before > freeing the first event, two events is sufficient. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
[ https://issues.apache.org/jira/browse/MYNEWT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-774: --- Description: The problem seems to be caused by an exhaustion of shell events. By default, the shell only allocates a single event. The sequence looks like this: # Client sends newtmgr command to device. # Console passes newtmgr command to shell. # Shell allocates the only event and fills it with the data. # Shell processes event, hands data to newtmgr code. # Newtmgr processes command and sends response. # Client sees response and sends follow-up command. # Console passes newtmgr command to shell. # Shell has no events left; drops incoming command. # Initial event gets freed. By changing the default event count from 1 to 2, we ensure there is always a spare event available. Since we will never send the second response before freeing the first event, two events is sufficient. > Intermittent serial errors in newtmgr messages on Arduino Zero > -- > > Key: MYNEWT-774 > URL: https://issues.apache.org/jira/browse/MYNEWT-774 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > The problem seems to be caused by an exhaustion of shell events. By > default, the shell only allocates a single event. > The sequence looks like this: > # Client sends newtmgr command to device. > # Console passes newtmgr command to shell. > # Shell allocates the only event and fills it with the data. > # Shell processes event, hands data to newtmgr code. > # Newtmgr processes command and sends response. > # Client sees response and sends follow-up command. > # Console passes newtmgr command to shell. > # Shell has no events left; drops incoming command. > # Initial event gets freed. > By changing the default event count from 1 to 2, we ensure there is > always a spare event available. Since we will never send the second > response before freeing the first event, two events is sufficient. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-775) Crash due to unaligned accesses during CoAP parsing.
[ https://issues.apache.org/jira/browse/MYNEWT-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-775: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/322) Some code assumes that an mbuf's om_data pointer is suitably aligned for struct pointer access. was: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/322) Some code assumes that an mbuf's om_data pointer is suitable aligned for struct pointer access. > Crash due to unaligned accesses during CoAP parsing. > > > Key: MYNEWT-775 > URL: https://issues.apache.org/jira/browse/MYNEWT-775 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/322) > Some code assumes that an mbuf's om_data pointer is suitably aligned for > struct pointer access. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-775) Crash due to unaligned accesses during CoAP parsing.
Christopher Collins created MYNEWT-775: -- Summary: Crash due to unaligned accesses during CoAP parsing. Key: MYNEWT-775 URL: https://issues.apache.org/jira/browse/MYNEWT-775 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel Some code assumes that an mbuf's om_data pointer is suitable aligned for struct pointer access. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-774) Intermittent serial errors in newtmgr messages on Arduino Zero
Christopher Collins created MYNEWT-774: -- Summary: Intermittent serial errors in newtmgr messages on Arduino Zero Key: MYNEWT-774 URL: https://issues.apache.org/jira/browse/MYNEWT-774 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-770) Sim - Share sig/no-sig implementation for all sim architectures
[ https://issues.apache.org/jira/browse/MYNEWT-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-770. Resolution: Fixed > Sim - Share sig/no-sig implementation for all sim architectures > --- > > Key: MYNEWT-770 > URL: https://issues.apache.org/jira/browse/MYNEWT-770 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/306) > In MYNEWT-745, sim was split into two implementations: > * signals > * no-signals > The above change was applied to the i386 version of sim, but not to the other > sim implementations (ARMv7 and MIPS). > This ticket is for extracting the signals and no-signals code into a > standalone package that can be used by all sim implementations. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-550) ble_gattc_indicate_custom to parallel ble_gattc_notify_custom
[ https://issues.apache.org/jira/browse/MYNEWT-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-550. Resolution: Fixed > ble_gattc_indicate_custom to parallel ble_gattc_notify_custom > - > > Key: MYNEWT-550 > URL: https://issues.apache.org/jira/browse/MYNEWT-550 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Affects Versions: v1_0_0_beta1, v1_0_0_beta2 >Reporter: Simon Ratner >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > Would be very handy to send arbitrary indications, and seems like an omission > since the corresponding notify api is there. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-661) BLE Host - SC:yes, lgcy:no - device never responds to pairing rsp.
[
https://issues.apache.org/jira/browse/MYNEWT-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins resolved MYNEWT-661.
Resolution: Fixed
Thanks, Łukasz. It looks good.
{noformat}
007743 compat> b sec start conn=1
008183 module: 0, command: b
008184 [ts=63937440ssb, mod=4 level=0] looking up peer sec; peer_addr_type=0
peer_addr=0x34 0x22 0x00 0x99 0x99 0x99
008187 [ts=63960876ssb, mod=4 level=0] host tx hci data; handle=1 length=11
008189 [ts=63976500ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0b 0x00
0x07 0x00 0x06 0x00 0x01 0x03 0x00 0x09 0x10 0x07 0x07
008193 [ts=64007812ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x0018
len=0
008195 [ts=64023436ssb, mod=4 level=0] 0x18 0x20 0x00
008196 [ts=64031248ssb, mod=4 level=0] Command complete: cmd_pkts=1 ogf=0x8
ocf=0x18 status=0 rand=0xc213c8492ede7859
008199 [ts=64054684ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x0018
len=0
008202 [ts=64078120ssb, mod=4 level=0] 0x18 0x20 0x00
008203 [ts=64085932ssb, mod=4 level=0] Command complete: cmd_pkts=1 ogf=0x8
ocf=0x18 status=0 rand=0x07be2ac5aa1e6e57
008206 compat> Number of Completed Packets: num_handles=1
008210 [ts=64140616ssb, mod=4 level=0] handle:1 pkts:1
008215 [ts=64179676ssb, mod=4 level=0] ble_hs_hci_evt_acl_process():
conn_handle=1 pb=2 len=11 data=0x07 0x00 0x06 0x00 0x02 0x03 0x00 0x01 0x10
0x07 0x07
008219 [ts=64210924ssb, mod=4 level=0] rxed sm command: pair rsp; conn=1
io_cap=3 oob_data_flag=0 authreq=0x01 mac_enc_key_size=16 init_key_dist=7
resp_key_dist=7
008223 [ts=64242172ssb, mod=4 level=0] host tx hci data; handle=1 length=6
008225 [ts=64257796ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x06 0x00
0x02 0x00 0x06 0x00 0x05 0x03
008228 encryption change event; status=1027 handle=1 our_ota_addr_type=0
our_ota_addr=0a:45:00:11:22:33 our_id_addr_type=0 our_id_addr=0a:45:00:11:22:33
peer_ota_addr_type=0 peer_ota_addr=99:99:99:00:22:34 peer_id_addr_type=0
peer_id_addr=99:99:99:00:22:34 conn_itvl=40 conn_latency=0
supervision_timeout=256 encrypted=0 authenticated=0 bonded=0
008241 [ts=64382788ssb, mod=4 level=0] Number of Completed Packets:
num_handles=1
008243 [ts=64398412ssb, mod=4 level=0] handle:1 pkts:1
{noformat}
(we get an authreq error now.)
> BLE Host - SC:yes, lgcy:no - device never responds to pairing rsp.
> --
>
> Key: MYNEWT-661
> URL: https://issues.apache.org/jira/browse/MYNEWT-661
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Configure device A with the following settings:
> {noformat}
> BLE_SM_LEGACY: 0
> BLE_SM_SC: 1
> {noformat}
> Configure device B with the opposite settings:
> {noformat}
> BLE_SM_LEGACY: 1
> BLE_SM_SC: 0
> {noformat}
> # Connect the two devices.
> # Device A initiates pairing.
> The result is: device A never responds to B's paring response. Instead, it
> does nothing and allows the pairing procedure to time out.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MYNEWT-752) Error in setting the "permanent" flag upon confirm with hash during image upgrade
[
https://issues.apache.org/jira/browse/MYNEWT-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039890#comment-16039890
]
Christopher Collins commented on MYNEWT-752:
(Pull request: https://github.com/apache/incubator-mynewt-core/pull/313)
h3. Before fix:
{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph
--name nimble-bleprph image test
5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
Images:
slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: bd42be9757549d4209ce873ab68f7cd290a9c494398d39af6b5702ec66aafb7d
slot=1
version: 2.2.2.2
bootable: true
flags: pending
hash: 5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
Split status: N/A (0)
{noformat}
(reset device)
{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph
--name nimble-bleprph image list
Images:
slot=0
version: 2.2.2.2
bootable: true
flags: active
hash: 5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
slot=1
version: 0.0.0
bootable: true
flags: confirmed
hash: bd42be9757549d4209ce873ab68f7cd290a9c494398d39af6b5702ec66aafb7d
Split status: N/A (0)
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph
--name nimble-bleprph image confirm
5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
Images:
slot=0
version: 2.2.2.2
bootable: true
flags: active confirmed
hash: 5ff2addc0fb7bde71fd03dd161834e61ded2041652c37196f180b12091c2ff55
slot=1
version: 0.0.0
bootable: true
flags: pending permanent
hash: bd42be9757549d4209ce873ab68f7cd290a9c494398d39af6b5702ec66aafb7d
Split status: N/A (0)
{noformat}
h3. After fix:
{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph
--name nimble-bleprph image test
817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
Images:
slot=0
version: 0.0.0
bootable: true
flags: active confirmed
hash: 1c71f96bcff94e6f2307f9b28bd0249fa73f0bb0819a99ee5bacc4db4e2179e3
slot=1
version: 2.2.2.2
bootable: true
flags: pending
hash: 817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
Split status: N/A (0)
{noformat}
(reset device)
{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph
--name nimble-bleprph image list
Images:
slot=0
version: 2.2.2.2
bootable: true
flags: active
hash: 817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
slot=1
version: 0.0.0
bootable: true
flags: confirmed
hash: 1c71f96bcff94e6f2307f9b28bd0249fa73f0bb0819a99ee5bacc4db4e2179e3
Split status: N/A (0)
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph
--name nimble-bleprph image confirm
817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
Images:
slot=0
version: 2.2.2.2
bootable: true
flags: active confirmed
hash: 817b16111d40151345566e73a2a2f999fd2efd65d43a1a98cdccd991ee0be775
slot=1
version: 0.0.0
bootable: true
flags:
hash: 1c71f96bcff94e6f2307f9b28bd0249fa73f0bb0819a99ee5bacc4db4e2179e3
Split status: N/A (0)
{noformat}
> Error in setting the "permanent" flag upon confirm with hash during image
> upgrade
> -
>
> Key: MYNEWT-752
> URL: https://issues.apache.org/jira/browse/MYNEWT-752
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Reporter: Aditi Hilbert
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> This is an issue seen during image upgrade. When doing a "confirm" with a
> hash, newtmgr always marks the "permanent" flag for Slot 1 image to "true",
> irrespective of which image the hash matches.
> This works fine when we skip the "test" step during image upgrade and we
> issue a "confirm" with a hash of the new image in Slot 1.
> However, if we do the "test" step (when the new image is swapped into Slot
> 0), and we then do a "confirm" with a hash of the new image and reboot, the
> device marks the old image in Slot 1 as "permanent" and swaps it back to Slot
> 0.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MYNEWT-772) BLE Host - Initial set-event-mask specifies reserved bits
[
https://issues.apache.org/jira/browse/MYNEWT-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins resolved MYNEWT-772.
Resolution: Fixed
> BLE Host - Initial set-event-mask specifies reserved bits
> -
>
> Key: MYNEWT-772
> URL: https://issues.apache.org/jira/browse/MYNEWT-772
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> (Pull request: https://github.com/apache/incubator-mynewt-core/pull/307)
> The host intends to enable the following events at start up:
> {noformat}
> /**
> * Enable the following events:
> * 0x0001 Inquiry Complete Event
> * 0x0002 Inquiry Result Event
> * 0x0004 Connection Complete Event
> * 0x0008 Connection Request Event
> * 0x0010 Disconnection Complete Event
> * 0x0020 Authentication Complete Event
> * 0x0040 Remote Name Request Complete Event
> * 0x0080 Encryption Change Event
> * 0x0100 Change Connection Link Key Complete Event
> * 0x0200 Master Link Key Complete Event
> * 0x0400 Read Remote Supported Features Complete Event
> * 0x0800 Read Remote Version Information Complete Event
> * 0x1000 QoS Setup Complete Event
> * 0x2000 Reserved
> * 0x4000 Reserved
> * 0x8000 Hardware Error Event
> * 0x0001 Flush Occurred Event
> * 0x0002 Role Change Event
> * 0x0004 Reserved
> * 0x0008 Mode Change Event
> * 0x0010 Return Link Keys Event
> * 0x0020 PIN Code Request Event
> * 0x0040 Link Key Request Event
> * 0x0080 Link Key Notification Event
> * 0x0100 Loopback Command Event
> * 0x0200 Data Buffer Overflow Event
> * 0x0400 Max Slots Change Event
> * 0x0800 Read Clock Offset Complete Event
> * 0x1000 Connection Packet Type Changed Event
> * 0x2000 QoS Violation Event
> * 0x4000 Page Scan Mode Change Event [deprecated]
> * 0x8000 Page Scan Repetition Mode Change Event
> * 0x0001 Flow Specification Complete Event
> * 0x0002 Inquiry Result with RSSI Event
> * 0x0004 Read Remote Extended Features Complete Event
> * 0x0800 Synchronous Connection Complete Event
> * 0x1000 Synchronous Connection Changed Event
> * 0x8000 Encryption Key Refresh Complete Event
> * 0x2000 LE Meta-Event
> */
> {noformat}
> It does this by setting the following bit mask: {{0x20009fff}}. This
> mask is incorrect; it should be: {{0x20009807}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MYNEWT-664) coredownload newtmgr command should indicate core size in first response
[ https://issues.apache.org/jira/browse/MYNEWT-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-664: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/312) This would be analogous to the "image upload", "file upload", and "file download" commands. Each of these indicate the total number of bytes in the first packet. This change involves a backwards compatible modification to the NMP protocol. Compatibility is maintained because this change only requires the addition of a new field, not the modification or removal of existing fields. was: This would be analogous to the "image upload", "file upload", and "file download" commands. Each of these indicate the total number of bytes in the first packet. This change involves a backwards compatible modification to the NMP protocol. Compatibility is maintained because this change only requires the addition of a new field, not the modification or removal of existing fields. > coredownload newtmgr command should indicate core size in first response > > > Key: MYNEWT-664 > URL: https://issues.apache.org/jira/browse/MYNEWT-664 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/312) > This would be analogous to the "image upload", "file upload", and "file > download" commands. Each of these indicate the total number of bytes in the > first packet. > This change involves a backwards compatible modification to the NMP protocol. > Compatibility is maintained because this change only requires the addition > of a new field, not the modification or removal of existing fields. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-773) Implement oic_serial in "new" newtmgr
[ https://issues.apache.org/jira/browse/MYNEWT-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-773. Resolution: Fixed > Implement oic_serial in "new" newtmgr > - > > Key: MYNEWT-773 > URL: https://issues.apache.org/jira/browse/MYNEWT-773 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Newtmgr >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > The old newtmgr > (https://github.com/apache/incubator-mynewt-newt/tree/master/newtmgr) > supports OMP (newtmgr over CoAP) over serial. > The new newtmgr > (https://github.com/apache/incubator-mynewt-newtmgr/tree/master/newtmgr) > lacks this feature. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-756) mpstats (on nrf51) hangs indefinately
[
https://issues.apache.org/jira/browse/MYNEWT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16039502#comment-16039502
]
Christopher Collins commented on MYNEWT-756:
Thanks, Jacob. When I try with those msys settings (8 / 149), the device does
not hang and I always receive the NOMEM response. Here is my target:
{noformat}
targets/bleprph-nrf51dk
app=apps/bleprph
bsp=hw/bsp/nrf51dk
build_profile=optimized
syscfg=BLE_LL_CFG_FEAT_LE_ENCRYPTION=0:BLE_PUBLIC_DEV_ADDR=(uint8_t[6]){0x1c,
0x22, 0x00, 0x99, 0x99,
0x99}:BLE_SM_LEGACY=0:BLE_SM_SC=0:LOG_LEVEL=0:MSYS_1_BLOCK_COUNT=8:MSYS_1_BLOCK_SIZE=149
{noformat}
Could you please paste your target so I can try with your settings?
> mpstats (on nrf51) hangs indefinately
> -
>
> Key: MYNEWT-756
> URL: https://issues.apache.org/jira/browse/MYNEWT-756
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: Newt
>Reporter: Jacob
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> I believe core is failing before sending the last packet, as neither newtmgr
> or node-newtmgr receives that packet.
> Jacobs-MacBook-Air:newtmgr jacobrosenthal$ GODEBUG=cgocheck=0 newtmgr mpstats
> -cnimble_bleprph -t -ldebug
> 2017/05/11 22:28:46 [DEBUG] BLE Connection devaddr:[]
> 2017/05/11 22:28:46 [DEBUG] State:PoweredOn
> 2017/05/11 22:28:46 [DEBUG] scanning...
> 2017/05/11 22:28:46 [DEBUG] Peripheral Discovered: , Address:[0 0 0 0 0 0]
> Address Type:0
> 2017/05/11 22:28:47 Unhandled event: xpc.Dict{"kCBMsgId":53,
> "kCBMsgArgs":xpc.Dict{"kCBMsgArgDeviceUUID":xpc.UUID{0x2f, 0xd, 0xcb, 0x60,
> 0xf, 0x3e, 0x47, 0x52, 0xb7, 0x74, 0x13, 0x29, 0x3a, 0x3, 0xd4, 0xd0},
> "kCBMsgArgATTMTU":104}}
> 2017/05/11 22:28:47 [DEBUG] Peripheral Connected
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Service Found
> 2017/05/11 22:28:47 [DEBUG] Newtmgr Characteristic Found
> 2017/05/11 22:28:47 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0
> Group:0 Seq:0 Id:3 Data:[]}
> 2017/05/11 22:28:47 [DEBUG] Serializing request &{Op:0 Flags:0 Len:0 Group:0
> Seq:0 Id:3 Data:[]} into buffer [0 0 0 0 0 0 0 3]
> 2017/05/11 22:28:47 [DEBUG] Tx packet dump:
> 00 00 00 00 00 00 00 03 ||
> 2017/05/11 22:28:47 [DEBUG] Write BLE Packet:buf:: len::8
> 2017/05/11 22:28:47 [DEBUG] Read BLE
> Packet:buf::l?brcfmpools?fmsys_1?fblksiz$enblks
>
> enfreecmin?wble_hci_ram_evt_hi_pool?fblksizHenblkse len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
> 01 00 02 6c 00 00 00 03 bf 62 72 63 00 66 6d 70 |...l.brc.fmp|
> 0010 6f 6f 6c 73 bf 66 6d 73 79 73 5f 31 bf 66 62 6c |ools.fmsys_1.fbl|
> 0020 6b 73 69 7a 19 01 24 65 6e 62 6c 6b 73 0c 65 6e |ksiz..$enblks.en|
> 0030 66 72 65 65 09 63 6d 69 6e 00 ff 77 62 6c 65 5f |free.cmin..wble_|
> 0040 68 63 69 5f 72 61 6d 5f 65 76 74 5f 68 69 5f 70 |hci_ram_evt_hi_p|
> 0050 6f 6f 6c bf 66 62 6c 6b 73 69 7a 18 48 65 6e 62 |ool.fblksiz.Henb|
> 0060 6c 6b 73 02 65|lks.e|
> 2017/05/11 22:28:47 [DEBUG] Deserialized response &{Op:1 Flags:0 Len:620
> Group:0 Seq:0 Id:3 Data:[191 98 114 99 0 102 109 112 111 111 108 115 191 102
> 109 115 121 115 95 49 191 102 98 108 107 115 105 122 25 1 36 101 110 98 108
> 107 115 12 101 110 102 114 101 101 9 99 109 105 110 0 255 119 98 108 101 95
> 104 99 105 95 114 97 109 95 101 118 116 95 104 105 95 112 111 111 108 191 102
> 98 108 107 115 105 122 24 72 101 110 98 108 107 115 2 101]}
> 2017/05/11 22:28:47 [DEBUG] Read BLE
> Packet:buf::nfreecmin?wble_hci_ram_evt_lo_pool?fblksizHenblkenfrecmi?rble_hs_hci_ev_pool?fblksizenblks
> len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
> 6e 66 72 65 65 02 63 6d 69 6e 00 ff 77 62 6c 65 |nfree.cmin..wble|
> 0010 5f 68 63 69 5f 72 61 6d 5f 65 76 74 5f 6c 6f 5f |_hci_ram_evt_lo_|
> 0020 70 6f 6f 6c bf 66 62 6c 6b 73 69 7a 18 48 65 6e |pool.fblksiz.Hen|
> 0030 62 6c 6b 73 08 65 6e 66 72 65 65 08 63 6d 69 6e |blks.enfree.cmin|
> 0040 08 ff 72 62 6c 65 5f 68 73 5f 68 63 69 5f 65 76 |..rble_hs_hci_ev|
> 0050 5f 70 6f 6f 6c bf 66 62 6c 6b 73 69 7a 10 65 6e |_pool.fblksiz.en|
> 0060 62 6c 6b 73 0a|blks.|
> 2017/05/11 22:28:47 [DEBUG] Read BLE Packet:buf::enfree
> cmin
> ?pble_hs_conn_pool?fblksizTenblksenfreecmin?sble_l2cap_chan_pool?fblksizenblksenfr
> len::101
> 2017/05/11 22:28:47 [DEBUG] Rx packet dump:
> 65 6e 66 72 65 65 0a 63 6d 69 6e 09 ff 70 62 6c |enfree.cmin..pbl|
> 0010 65 5f 68 73 5f 63 6f 6e 6e 5f 70 6f 6f 6c bf 66 |e_hs_conn_pool.f|
> 0020 62 6c 6b 73 69 7a 18 54 65 6e 62 6c 6b
[jira] [Created] (MYNEWT-773) Implement oic_serial in "new" newtmgr
Christopher Collins created MYNEWT-773: -- Summary: Implement oic_serial in "new" newtmgr Key: MYNEWT-773 URL: https://issues.apache.org/jira/browse/MYNEWT-773 Project: Mynewt Issue Type: Bug Security Level: Public (Viewable by anyone) Components: Newtmgr Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel The old newtmgr (https://github.com/apache/incubator-mynewt-newt/tree/master/newtmgr) supports OMP (newtmgr over CoAP) over serial. The new newtmgr (https://github.com/apache/incubator-mynewt-newtmgr/tree/master/newtmgr) lacks this feature. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-550) ble_gattc_indicate_custom to parallel ble_gattc_notify_custom
[ https://issues.apache.org/jira/browse/MYNEWT-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037985#comment-16037985 ] Christopher Collins commented on MYNEWT-550: I have created a pull request which implements this feature: https://github.com/apache/incubator-mynewt-core/pull/310 > ble_gattc_indicate_custom to parallel ble_gattc_notify_custom > - > > Key: MYNEWT-550 > URL: https://issues.apache.org/jira/browse/MYNEWT-550 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Affects Versions: v1_0_0_beta1, v1_0_0_beta2 >Reporter: Simon Ratner >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > Would be very handy to send arbitrary indications, and seems like an omission > since the corresponding notify api is there. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MYNEWT-760) Switch testbench app over to CoAP (from plain NMP)
[ https://issues.apache.org/jira/browse/MYNEWT-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16037937#comment-16037937 ] Christopher Collins commented on MYNEWT-760: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/309) Currently, the testbench app uses plain newtmgr. The task is to modify the app so that newtmgr messages are sent via CoAP instead. > Switch testbench app over to CoAP (from plain NMP) > -- > > Key: MYNEWT-760 > URL: https://issues.apache.org/jira/browse/MYNEWT-760 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-750) BLE Host - Ignore pairing attempt from already bonded peer
[ https://issues.apache.org/jira/browse/MYNEWT-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-750: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/287) If a device is already bonded, the host should not allow the same device to pair again. Currently, the host blindly proceeds with the pairing operation. This should not be allowed because the second peer could be an imposter masquerading as the original. I propose the following behavior in such a scenario: # Host notifies application of the duplicate pairing attempt via the gap event callback. The callback would specify a new event code that specifically indicates a duplicate pairing attempt. # The gap event callback would return an error code indicating which of the following behaviors to perform: ## Retry: Return BLE_GAP_REPEAT_PAIRING_RETRY after deleting the conflicting bond. The stack will verify the bond has been deleted and continue the pairing procedure. If the bond is still present, this event will be reported again. ## Ignore: Return BLE_GAP_REPEAT_PAIRING_IGNORE. The stack will silently ignore the pairing request. was: If a device is already bonded, the host should not allow the same device to pair again. Currently, the host blindly proceeds with the pairing operation. This should not be allowed because the second peer could be an imposter masquerading as the original. I propose the following behavior in such a scenario: # Host notifies application of the duplicate pairing attempt via the gap event callback. The callback would specify a new event code that specifically indicates a duplicate pairing attempt. # The gap event callback would return an error code indicating which of the following behaviors to perform: ## Retry: Return BLE_GAP_REPEAT_PAIRING_RETRY after deleting the conflicting bond. The stack will verify the bond has been deleted and continue the pairing procedure. If the bond is still present, this event will be reported again. ## Ignore: Return BLE_GAP_REPEAT_PAIRING_IGNORE. The stack will silently ignore the pairing request. > BLE Host - Ignore pairing attempt from already bonded peer > -- > > Key: MYNEWT-750 > URL: https://issues.apache.org/jira/browse/MYNEWT-750 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/287) > If a device is already bonded, the host should not allow the same device to > pair again. Currently, the host blindly proceeds with the pairing operation. > This should not be allowed because the second peer could be an imposter > masquerading as the original. > I propose the following behavior in such a scenario: > # Host notifies application of the duplicate pairing attempt via the gap > event callback. The callback would specify a new event code that > specifically indicates a duplicate pairing attempt. > # The gap event callback would return an error code indicating which of the > following behaviors to perform: > ## Retry: Return BLE_GAP_REPEAT_PAIRING_RETRY after deleting the conflicting > bond. The stack will verify the bond has been deleted and continue the > pairing procedure. If the bond is still present, this event will be reported > again. > ## Ignore: Return BLE_GAP_REPEAT_PAIRING_IGNORE. The stack will silently > ignore the pairing request. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-743) BLE Host - Persist bonding material to sys/config.
[ https://issues.apache.org/jira/browse/MYNEWT-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-743: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/280) > BLE Host - Persist bonding material to sys/config. > -- > > Key: MYNEWT-743 > URL: https://issues.apache.org/jira/browse/MYNEWT-743 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/280) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-751) BLE Host - Policy for SM key overflow
[ https://issues.apache.org/jira/browse/MYNEWT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-751: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/279) The BLE host needs a way to handle the case where a security store write fails because the maximum number of entries have already been written. Currently, the host simply fails to persist the record and returns an error code. I propose the following behavior in such a scenario: # Host checks that there is sufficient storage for a bond before it starts a pairing operation. Any currently-active pairing procedures should be included in the total number of bonds. # If there is insufficient space, host notifies application of the issue via a callback. # The callback would return an error code indicating which of the following behaviors to perform: ## Reject the pairing request. ## Proceed with the pairing operation (presumably the application would delete a security record to make room before returning from the callback). was: The BLE host needs a way to handle the case where a security store write fails because the maximum number of entries have already been written. Currently, the host simply fails to persist the record and returns an error code. I propose the following behavior in such a scenario: # Host checks that there is sufficient storage for a bond before it starts a pairing operation. Any currently-active pairing procedures should be included in the total number of bonds. # If there is insufficient space, host notifies application of the issue via a callback. # The callback would return an error code indicating which of the following behaviors to perform: ## Reject the pairing request. ## Proceed with the pairing operation (presumably the application would delete a security record to make room before returning from the callback). > BLE Host - Policy for SM key overflow > - > > Key: MYNEWT-751 > URL: https://issues.apache.org/jira/browse/MYNEWT-751 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/279) > The BLE host needs a way to handle the case where a security store write > fails because the maximum number of entries have already been written. > Currently, the host simply fails to persist the record and returns an error > code. > I propose the following behavior in such a scenario: > # Host checks that there is sufficient storage for a bond before it starts a > pairing operation. Any currently-active pairing procedures should be > included in the total number of bonds. > # If there is insufficient space, host notifies application of the issue via > a callback. > # The callback would return an error code indicating which of the following > behaviors to perform: > ## Reject the pairing request. > ## Proceed with the pairing operation (presumably the application would > delete a security record to make room before returning from the callback). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
