[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)
[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=16037833#comment-16037833
]
Christopher Collins commented on MYNEWT-756:
This works for me on the nRF51dk. One possibility is that your device is
running out of mbufs. The mpstat command is actually quite mbuf-hungry because
it generates such a large response. Unfortunately, we need the mpstat command
to determine if this is the case!
Are you building with a reduced mbuf size or count? For the record, here is
the target I used:
{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=1:STATS_NAMES=1
{noformat}
And here is the mpstat output:
{noformat}
[ccollins@ccollins-mac:~/repos/mynewt/core]$ newtmgr -c ble-nimble-bleprph -n
nimble-bleprph mpstat
name blksz cnt free min
ble_att_svr_entry_pool20 3700
ble_att_svr_prep_entry_pool12 64 64 64
ble_gap_update24111
ble_gattc_proc_pool56444
ble_gatts_clt_cfg_pool16200
ble_hci_ram_evt_hi_pool72220
ble_hci_ram_evt_lo_pool72888
ble_hs_conn_pool84100
ble_hs_hci_ev_pool16 10 109
ble_l2cap_chan_pool28300
ble_l2cap_sig_proc_pool20111
msys_1 292 1298
{noformat}
> 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:
>
[jira] [Updated] (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 updated MYNEWT-772:
---
Description:
(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}}.
was:
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
[jira] [Updated] (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 updated MYNEWT-772:
---
Description:
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}}.
was:
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
[jira] [Created] (MYNEWT-772) BLE Host - Initial set-event-mask specifies reserved bits
Christopher Collins created MYNEWT-772:
--
Summary: 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
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 in incorrect; it should be: {{0x20009807}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MYNEWT-770) Sim - Share sig/no-sig implementation for all sim architectures
Christopher Collins created MYNEWT-770: -- Summary: 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 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] [Comment Edited] (MYNEWT-765) os_mbuf memory corruption on native platform
[
https://issues.apache.org/jira/browse/MYNEWT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025576#comment-16025576
]
Christopher Collins edited comment on MYNEWT-765 at 5/26/17 12:52 AM:
--
In addition, the double free issue
(https://github.com/apache/incubator-mynewt-core/pull/292) was causing a
problem. After merging that PR, everything looks good to me.
I am going to merge the above PR now. If you test this again, be sure to grab
the latest from master.
was (Author: ccollins476):
Looks like I spoke too soon - I'm seeing another issue after letting it run for
several minutes:
{noformat}
(gdb) p ble_hci_uart_acl_pool
$4 = {mp_block_size = 292, mp_num_blocks = 1000, mp_num_free = -1467022310,
mp_min_free = 983, mp_membuf_addr = 1290240, mp_list = {stqe_next = 0xc0be0
}, {slh_first = 0x13b248}, name = 0x3d0a1
"ble_hci_uart_acl_pool"}
{noformat}
{{mp_num_free}} shouldn't be negative! I am going to keep looking at this.
Hopefully this and the memory corruption issue are related.
(The issues I mentioned in the above comment are still valid.)
> os_mbuf memory corruption on native platform
>
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file
> {{net/nimble/host/src/ble_hs_log.c}} when receiving notifications at high
> rate. Tested using *bsncent* app from
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn and *bsnprph* also
> from https://github.com/apache/incubator-mynewt-core/tree/bsnbranch
> Data from HCI command overwrites the os_mbuf struct instead of being written
> to {{om->om_data}}. I tried to catch that memory violation earlier in code,
> but somehow it is only triggered in the {{ble_hs_log_mbuf}} function.
> h4. How to reproduce:
> 1. Build and flash *bsnprph* app from
> https://github.com/apache/incubator-mynewt-core/tree/bsnbranch with the
> following configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsnprph
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> {quote}
> 2. Build *bsncent* app from
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following
> configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsncent
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
> {quote}
> 3. It is possible to reproduce it using Mynewt controller (but then another
> issue shows up sometimes, described below) or some other controller like PTS
> with some hacks in ble_hs_startup.c to start controller.
> 4. Run *bsncent* app from 32bit Ubuntu
> Here is the backtrace from GDB:
> {quote}
> Program received signal SIGSEGV, Segmentation fault.
> __memcpy_sse2_unaligned () at
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> 651 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file
> or directory.
> (gdb) bt
> #0 __memcpy_sse2_unaligned () at
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> #1 0x80009fc0 in os_mbuf_copydata (m=0x8008fb6c, off=0, len=1,
> dst=0x800746c7 ) at
> repos/apache-mynewt-core/kernel/os/src/os_mbuf.c:722
> #2 0x8001fb5a in ble_hs_log_mbuf (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_log.c:32
> #3 0x8001f18c in ble_hs_hci_evt_acl_process (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_hci_evt.c:631
> #4 0x80018c1f in ble_hs_process_rx_data_queue ()
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:195
> #5 0x80019020 in ble_hs_event_data (ev=0x80075aec )
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:379
> #6 0x80007009 in os_eventq_run (evq=0x80074908 )
> at repos/apache-mynewt-core/kernel/os/src/os_eventq.c:172
> #7 0x80002308 in main (argc=0, argv=0x0) at
> repos/apache-mynewt-core/apps/bsncent/src/main.c:457
> {quote}
> h4. Another issue
> Actually, there is also a second problem. When using *blehci* as the
> controller the communication between central and peripheral freezes somewhere
> around GATT discovery most of the time. It happens quiet randomly.
> To reproduce it:
> 1. Build and flash *blehci* app from
>
[jira] [Comment Edited] (MYNEWT-765) os_mbuf memory corruption on native platform
[
https://issues.apache.org/jira/browse/MYNEWT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025576#comment-16025576
]
Christopher Collins edited comment on MYNEWT-765 at 5/26/17 12:02 AM:
--
Looks like I spoke too soon - I'm seeing another issue after letting it run for
several minutes:
{noformat}
(gdb) p ble_hci_uart_acl_pool
$4 = {mp_block_size = 292, mp_num_blocks = 1000, mp_num_free = -1467022310,
mp_min_free = 983, mp_membuf_addr = 1290240, mp_list = {stqe_next = 0xc0be0
}, {slh_first = 0x13b248}, name = 0x3d0a1
"ble_hci_uart_acl_pool"}
{noformat}
{{mp_num_free}} shouldn't be negative! I am going to keep looking at this.
Hopefully this and the memory corruption issue are related.
(The issues I mentioned in the above comment are still valid.)
was (Author: ccollins476):
Looks like I spoke too soon - I'm seeing another issue after letting it run for
several minutes:
```
(gdb) p ble_hci_uart_acl_pool
$4 = {mp_block_size = 292, mp_num_blocks = 1000, mp_num_free = -1467022310,
mp_min_free = 983, mp_membuf_addr = 1290240, mp_list = {stqe_next = 0xc0be0
}, {slh_first = 0x13b248}, name = 0x3d0a1
"ble_hci_uart_acl_pool"}
```
`mp_num_free` shouldn't be negative! I am going to keep looking at this.
Hopefully this and the memory corruption issue are related.
(The issues I mentioned in the above comment are still valid.)
> os_mbuf memory corruption on native platform
>
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file
> {{net/nimble/host/src/ble_hs_log.c}} when receiving notifications at high
> rate. Tested using *bsncent* app from
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn and *bsnprph* also
> from https://github.com/apache/incubator-mynewt-core/tree/bsnbranch
> Data from HCI command overwrites the os_mbuf struct instead of being written
> to {{om->om_data}}. I tried to catch that memory violation earlier in code,
> but somehow it is only triggered in the {{ble_hs_log_mbuf}} function.
> h4. How to reproduce:
> 1. Build and flash *bsnprph* app from
> https://github.com/apache/incubator-mynewt-core/tree/bsnbranch with the
> following configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsnprph
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> {quote}
> 2. Build *bsncent* app from
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following
> configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsncent
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
> {quote}
> 3. It is possible to reproduce it using Mynewt controller (but then another
> issue shows up sometimes, described below) or some other controller like PTS
> with some hacks in ble_hs_startup.c to start controller.
> 4. Run *bsncent* app from 32bit Ubuntu
> Here is the backtrace from GDB:
> {quote}
> Program received signal SIGSEGV, Segmentation fault.
> __memcpy_sse2_unaligned () at
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> 651 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file
> or directory.
> (gdb) bt
> #0 __memcpy_sse2_unaligned () at
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> #1 0x80009fc0 in os_mbuf_copydata (m=0x8008fb6c, off=0, len=1,
> dst=0x800746c7 ) at
> repos/apache-mynewt-core/kernel/os/src/os_mbuf.c:722
> #2 0x8001fb5a in ble_hs_log_mbuf (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_log.c:32
> #3 0x8001f18c in ble_hs_hci_evt_acl_process (om=0x8008fb6c)
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs_hci_evt.c:631
> #4 0x80018c1f in ble_hs_process_rx_data_queue ()
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:195
> #5 0x80019020 in ble_hs_event_data (ev=0x80075aec )
> at repos/apache-mynewt-core/net/nimble/host/src/ble_hs.c:379
> #6 0x80007009 in os_eventq_run (evq=0x80074908 )
> at repos/apache-mynewt-core/kernel/os/src/os_eventq.c:172
> #7 0x80002308 in main (argc=0, argv=0x0) at
> repos/apache-mynewt-core/apps/bsncent/src/main.c:457
> {quote}
> h4. Another issue
> Actually, there is also a second
[jira] [Comment Edited] (MYNEWT-765) os_mbuf memory corruption on native platform
[
https://issues.apache.org/jira/browse/MYNEWT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021734#comment-16021734
]
Christopher Collins edited comment on MYNEWT-765 at 5/23/17 11:26 PM:
--
{quote}
2. Build bsncent app from
https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following
configuration:
app=@apache-mynewt-core/apps/bsncent
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug
syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
{quote}
MCU_NATIVE_USE_SIGNALS should probably be set to 0 here (not 1). From
{{hw/mcu/native/syscfg.yml}}:
{noformat}
MCU_NATIVE_USE_SIGNALS:
description: >
Whether to use POSIX signals to implement context switches. Valid
values are as follows:
1: More correctness; less stability. The OS tick timer will
cause a high-priority task to preempt a low-priority task.
This causes stability issues because a task can be preempted
while it is in the middle of a system call, potentially
causing deadlock or memory corruption.
0: Less correctness; more stability. The OS tick timer only
runs while the idle task is active. Therefore, a sleeping
high-priority task will not preempt a low-priority task due
to a timing event (e.g., delay or callout expired).
However, this version of sim does not suffer from the
stability issues that affect the "signals" implementation.
Unit tests should use 1. Long-running sim processes should use 0.
{noformat}
Setting this to 0 causes sim to use the new behavior implemented in
{{9864f55e53df0b945fa3482d9b9ea63109c09123}}.
Hopefully this is the problem. With this setting equal to 1, I have seen
memory corruption like this (typically when mmap() or sbrk() gets longjmped out
of (called via malloc()).
was (Author: ccollins476):
{quote}
2. Build bsncent app from
https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following
configuration:
app=@apache-mynewt-core/apps/bsncent
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug
syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
{quote}
MCU_NATIVE_USE_SIGNALS should probably be set to 0 here (not 1). From
{{hw/mcu/native/syscfg.yml}}:
{noformat}
MCU_NATIVE_USE_SIGNALS:
description: >
Whether to use POSIX signals to implement context switches. Valid
values are as follows:
1: More correctness; less stability. The OS tick timer will
cause a high-priority task to preempt a low-priority task.
This causes stability issues because a task can be preempted
while it is in the middle of a system call, potentially
causing deadlock or memory corruption.
0: Less correctness; more stability. The OS tick timer only
runs while the idle task is active. Therefore, a sleeping
high-priority task will not preempt a low-priority task due
to a timing event (e.g., delay or callout expired).
However, this version of sim does not suffer from the
stability issues that affect the "signals" implementation.
Unit tests should use 1. Long-running sim processes should use 0.
{noformat}
Setting this to 0 causes sim to use the new behavior implemented in
{{9864f55e53df0b945fa3482d9b9ea63109c09123}}.
Hopefully this is the problem. With this setting equal to 0, I have seen
memory corruption like this (typically when mmap() or sbrk() gets longjmped out
of (called via malloc()).
> os_mbuf memory corruption on native platform
>
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
> Issue Type: Bug
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file
> {{net/nimble/host/src/ble_hs_log.c}} when receiving notifications
[jira] [Commented] (MYNEWT-765) os_mbuf memory corruption on native platform
[
https://issues.apache.org/jira/browse/MYNEWT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021734#comment-16021734
]
Christopher Collins commented on MYNEWT-765:
{quote}
2. Build bsncent app from
https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following
configuration:
app=@apache-mynewt-core/apps/bsncent
bsp=@apache-mynewt-core/hw/bsp/native
build_profile=debug
syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
{quote}
MCU_NATIVE_USE_SIGNALS should probably be set to 0 here (not 1). From
{{hw/mcu/native/syscfg.yml}}:
{noformat}
MCU_NATIVE_USE_SIGNALS:
description: >
Whether to use POSIX signals to implement context switches. Valid
values are as follows:
1: More correctness; less stability. The OS tick timer will
cause a high-priority task to preempt a low-priority task.
This causes stability issues because a task can be preempted
while it is in the middle of a system call, potentially
causing deadlock or memory corruption.
0: Less correctness; more stability. The OS tick timer only
runs while the idle task is active. Therefore, a sleeping
high-priority task will not preempt a low-priority task due
to a timing event (e.g., delay or callout expired).
However, this version of sim does not suffer from the
stability issues that affect the "signals" implementation.
Unit tests should use 1. Long-running sim processes should use 0.
{noformat}
Setting this to 0 causes sim to use the new behavior implemented in
{{9864f55e53df0b945fa3482d9b9ea63109c09123}}.
Hopefully this is the problem. With this setting equal to 0, I have seen
memory corruption like this (typically when mmap() or sbrk() gets longjmped out
of (called via malloc()).
> os_mbuf memory corruption on native platform
>
>
> Key: MYNEWT-765
> URL: https://issues.apache.org/jira/browse/MYNEWT-765
> Project: Mynewt
> Issue Type: Bug
> Environment: bsncent app on native 32-bit Ubuntu 17.04
>Reporter: Michał Narajowski
>Priority: Minor
>
> h4. General description:
> There is a segmentation fault error in function {{ble_hs_log_mbuf}} in file
> {{net/nimble/host/src/ble_hs_log.c}} when receiving notifications at high
> rate. Tested using *bsncent* app from
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn and *bsnprph* also
> from https://github.com/apache/incubator-mynewt-core/tree/bsnbranch
> Data from HCI command overwrites the os_mbuf struct instead of being written
> to {{om->om_data}}. I tried to catch that memory violation earlier in code,
> but somehow it is only triggered in the {{ble_hs_log_mbuf}} function.
> h4. How to reproduce:
> 1. Build and flash *bsnprph* app from
> https://github.com/apache/incubator-mynewt-core/tree/bsnbranch with the
> following configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsnprph
> bsp=@apache-mynewt-core/hw/bsp/nrf52dk
> build_profile=optimized
> {quote}
> 2. Build *bsncent* app from
> https://github.com/rymanluk/incubator-mynewt-core/tree/bsn with the following
> configuration:
> {quote}
> app=@apache-mynewt-core/apps/bsncent
> bsp=@apache-mynewt-core/hw/bsp/native
> build_profile=debug
> syscfg=BLE_HS_DEBUG=1:BLE_MAX_CONNECTIONS=5:BLE_SM_BONDING=1:BLE_SM_IO_CAP=BLE_HS_IO_KEYBOARD_DISPLAY:BLE_SM_LEGACY=1:BLE_SM_MITM=1:BLE_SM_OUR_KEY_DIST=7:BLE_SM_SC=1:BLE_SOCK_LINUX_DEV=0:BLE_SOCK_USE_LINUX_BLUE=1:BLE_SOCK_USE_TCP=0:LOG_LEVEL=0:MCU_NATIVE_USE_SIGNALS=1:OS_MAIN_STACK_SIZE=512:SHELL_TASK=1
> {quote}
> 3. It is possible to reproduce it using Mynewt controller (but then another
> issue shows up sometimes, described below) or some other controller like PTS
> with some hacks in ble_hs_startup.c to start controller.
> 4. Run *bsncent* app from 32bit Ubuntu
> Here is the backtrace from GDB:
> {quote}
> Program received signal SIGSEGV, Segmentation fault.
> __memcpy_sse2_unaligned () at
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> 651 ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S: No such file
> or directory.
> (gdb) bt
> #0 __memcpy_sse2_unaligned () at
> ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:651
> #1 0x80009fc0 in os_mbuf_copydata (m=0x8008fb6c, off=0, len=1,
> dst=0x800746c7 ) at
> repos/apache-mynewt-core/kernel/os/src/os_mbuf.c:722
> #2 0x8001fb5a in
[jira] [Created] (MYNEWT-760) Switch testbench app over to CoAP (from plain NMP)
Christopher Collins created MYNEWT-760: -- Summary: 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 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-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 updated MYNEWT-759: --- Issue Type: Improvement (was: Bug) > 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 >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.3.15#6346)
[jira] [Created] (MYNEWT-759) Change BLE-over-CoAP UUID from 128-bit to 16-bit
Christopher Collins created MYNEWT-759: -- Summary: 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: Bug 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.3.15#6346)
[jira] [Assigned] (MYNEWT-742) OIC requires some manual steps to initialize
[
https://issues.apache.org/jira/browse/MYNEWT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins reassigned MYNEWT-742:
--
Assignee: Christopher Collins
> OIC requires some manual steps to initialize
>
>
> Key: MYNEWT-742
> URL: https://issues.apache.org/jira/browse/MYNEWT-742
> Project: Mynewt
> Issue Type: Bug
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> E.g.,
> {noformat}
> static const oc_handler_t omgr_oc_handler = {
> .init = omgr_app_init,
> };
> int
> main(int argc, char **argv)
> {
> /* ... */
> oc_main_init((oc_handler_t *)_oc_handler);
> oc_ble_coap_gatt_srv_init();
> }
> {noformat}
> If possible, it would be good if these calls happened automatically when the
> OS starts. Unfortunately, the user will still need to configure the library
> with an oc_handler.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MYNEWT-758) BLE Host - OOB security for SC
Christopher Collins created MYNEWT-758: -- Summary: BLE Host - OOB security for SC Key: MYNEWT-758 URL: https://issues.apache.org/jira/browse/MYNEWT-758 Project: Mynewt Issue Type: Bug Components: Nimble Reporter: 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: 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: ## Reject the pairing request. ## Delete the original bond and proceed with the pairing operation. Summary: BLE Host - Ignore pairing attempt from already bonded peer (was: BLE Host - Reject pairing attempt from already bonded peer) > 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 > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > 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] [Assigned] (MYNEWT-750) BLE Host - Reject 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 reassigned MYNEWT-750: -- Assignee: Christopher Collins > BLE Host - Reject pairing attempt from already bonded peer > -- > > Key: MYNEWT-750 > URL: https://issues.apache.org/jira/browse/MYNEWT-750 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > 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: > ## Reject the pairing request. > ## Delete the original bond and proceed with the pairing operation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-757) Inconsistent tags among newt, blinky, and core
Christopher Collins created MYNEWT-757: -- Summary: Inconsistent tags among newt, blinky, and core Key: MYNEWT-757 URL: https://issues.apache.org/jira/browse/MYNEWT-757 Project: Mynewt Issue Type: Bug Components: Newt Reporter: Christopher Collins Assignee: Sterling Hughes 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.3.15#6346)
[jira] [Resolved] (MYNEWT-753) newt - generated sysinit file inconsistent
[ https://issues.apache.org/jira/browse/MYNEWT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-753. Resolution: Fixed > newt - generated sysinit file inconsistent > -- > > Key: MYNEWT-753 > URL: https://issues.apache.org/jira/browse/MYNEWT-753 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > In the generated sysinit C file, calls to initialization functions are sorted > by stage number. Within a stage number, the ordering is random, and varies > from one build to the next. The randomness comes from Golang's random > iteration of maps. > This is bad because it prevents repeatable builds, and causes unnecessary > rebuilds. > The fix is to sort alphabetically by package name within a stage number. So, > * First sort by stage number > * Then sort by package name. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-745) Sim - deadlock involving system calls
[
https://issues.apache.org/jira/browse/MYNEWT-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins resolved MYNEWT-745.
Resolution: Fixed
> Sim - deadlock involving system calls
> -
>
> Key: MYNEWT-745
> URL: https://issues.apache.org/jira/browse/MYNEWT-745
> Project: Mynewt
> Issue Type: Bug
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
> Attachments: main.c
>
>
> The problem appears to occur when a system call is interrupted by a sim
> context switch. Because a sim context switch is implemented as a signal
> handler that never returns (it calls longjmp()), the system call is left
> unfinished. In some cases, it seems the system call acquired some resources
> that it never got a chance to release, leading to deadlock on a subsequent
> system call. For whatever reason, when the original system call is resumed
> (i.e., when Mynewt switch back to the original task), the syscall is unable
> to recover.
> In sim, a context switch is triggered by delivery of a SIGURG signal. A few
> events generate this signal:
> # A task calls an OS function with the potential to switch tasks (e.g.,
> os_eventq_get(), os_mutex_release(), etc.).
> # An OS tick occurs.
> The problem appears to occur when an OS tick generates the SIGURG signal.
> The OS ticker is implemented via an itimer, which generates the SIG_ALRM
> signal on each tick. The SIG_ALRM handler advances the OS time, and then
> calls os_sched(), potentially generating a SIGURG signal. If the current
> task happened to be in the middle of a syscall when the tick timer expired,
> the SIGURG signal gets handled before the syscall returns.
> Here is a stack trace showing a context switch in the middle of a system call:
> {noformat}
> (gdb) whe
> #0 0x0804a3bd in ctxsw_handler (sig=23)
> at kernel/os/src/arch/sim/os_arch_sim.c:150
> #1
> #2 0xf7ffdbe7 in __kernel_vsyscall ()
> #3 0x08097630 in __lll_lock_wait_private ()
> #4 0x080923b0 in __tz_convert ()
> #5 0x08091673 in localtime ()
> #6 0x0809162c in ctime ()
> #7 0x08048a5a in task1_handler (arg=0x0) at apps/slinky/src/main.c:162
> #8 0x0804a2c8 in os_arch_task_start (sf=0x8160314, rc=1)
> at kernel/os/src/arch/sim/os_arch_sim.c:88
> #9 0x0804ad90 in os_arch_frame_init ()
> at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
> #10 0x0804ad90 in os_arch_frame_init ()
> at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
> {noformat}
> Attached is a simple Mynewt app that can be used to replicate this issue
> (main.c).
--
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: 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. # 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 entry to make room before returning from the callback). This raises two issues: # The pre-check for sufficient storage only works if pairing operations are limited to one at a time. Perhaps the check could include pairing operations in progress in the count of written entries. # There isn't an API for the management of persisted security material. The application would probably need the following functions: ** query the system about which bonds are persisted. ** delete a specified bond from persistence. 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. # If there is insufficient space, host notifies application of the issue via the gap event callback. The callback would specify a new event code that specifically indicates security storage exhaustion. # The gap event 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 entry to make room before returning from the callback). This raises two issues: # The pre-check for sufficient storage only works if pairing operations are limited to one at a time. Perhaps the check could include pairing operations in progress in the count of written entries. # There isn't an API for the management of persisted security material. The application would probably need the following functions: ** query the system about which bonds are persisted. ** delete a specified bond from persistence. > BLE Host - Policy for SM key overflow > - > > Key: MYNEWT-751 > URL: https://issues.apache.org/jira/browse/MYNEWT-751 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > 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. > # 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 entry to make room before returning from the callback). > This raises two issues: > # The pre-check for sufficient storage only works if pairing operations are > limited to one at a time. Perhaps the check could include pairing operations > in progress in the count of written entries. > # There isn't an API for the management of persisted security material. The > application would probably need the following functions: > ** query the system about which bonds are persisted. > ** delete a specified bond from persistence. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-754) BLE Host - Store management API additions
[ https://issues.apache.org/jira/browse/MYNEWT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-754: --- Component/s: Nimble > BLE Host - Store management API additions > - > > Key: MYNEWT-754 > URL: https://issues.apache.org/jira/browse/MYNEWT-754 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > The store API supports all the necessary operations: read, write, and delete. > However, some convenience functions are sorely lacking: > * Retrieve list of bonded peers > * Delete bond -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (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 reassigned MYNEWT-751: -- Assignee: Christopher Collins > BLE Host - Policy for SM key overflow > - > > Key: MYNEWT-751 > URL: https://issues.apache.org/jira/browse/MYNEWT-751 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > 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. > # If there is insufficient space, host notifies application of the issue via > the gap event callback. The callback would specify a new event code that > specifically indicates security storage exhaustion. > # The gap event 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 entry to make room before returning from the callback). > This raises two issues: > # The pre-check for sufficient storage only works if pairing operations are > limited to one at a time. Perhaps the check could include pairing operations > in progress in the count of written entries. > # There isn't an API for the management of persisted security material. The > application would probably need the following functions: > ** query the system about which bonds are persisted. > ** delete a specified bond from persistence. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-753) newt - generated sysinit file inconsistent
Christopher Collins created MYNEWT-753: -- Summary: newt - generated sysinit file inconsistent Key: MYNEWT-753 URL: https://issues.apache.org/jira/browse/MYNEWT-753 Project: Mynewt Issue Type: Bug Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel In the generated sysinit C file, calls to initialization functions are sorted by stage number. Within a stage number, the ordering is random, and varies from one build to the next. The randomness comes from Golang's random iteration of maps. This is bad because it prevents repeatable builds, and causes unnecessary rebuilds. The fix is to sort alphabetically by package name within a stage number. So, * First sort by stage number * Then sort by package name. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-751) BLE Host - Policy for SM key overflow
Christopher Collins created MYNEWT-751: -- Summary: BLE Host - Policy for SM key overflow Key: MYNEWT-751 URL: https://issues.apache.org/jira/browse/MYNEWT-751 Project: Mynewt Issue Type: Bug Components: Nimble Reporter: Christopher Collins Fix For: v1_1_0_rel 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. # If there is insufficient space, host notifies application of the issue via the gap event callback. The callback would specify a new event code that specifically indicates security storage exhaustion. # The gap event 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 entry to make room before returning from the callback). This raises two issues: # The pre-check for sufficient storage only works if pairing operations are limited to one at a time. Perhaps the check could include pairing operations in progress in the count of written entries. # There isn't an API for the management of persisted security material. The application would probably need the following functions: ** query the system about which bonds are persisted. ** delete a specified bond from persistence. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-750) BLE Host - Reject pairing attempt from already bonded peer
Christopher Collins created MYNEWT-750: -- Summary: BLE Host - Reject pairing attempt from already bonded peer Key: MYNEWT-750 URL: https://issues.apache.org/jira/browse/MYNEWT-750 Project: Mynewt Issue Type: Bug Components: Nimble Reporter: Christopher Collins Fix For: v1_1_0_rel 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: ## Reject the pairing request. ## Delete the original bond and proceed with the pairing operation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-749) BLE Host - Crash during key persistence if key-dist settings are 0
Christopher Collins created MYNEWT-749:
--
Summary: 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
Components: Nimble
Reporter: Christopher Collins
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}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (MYNEWT-745) Sim - deadlock involving system calls
[
https://issues.apache.org/jira/browse/MYNEWT-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins reassigned MYNEWT-745:
--
Assignee: Christopher Collins
> Sim - deadlock involving system calls
> -
>
> Key: MYNEWT-745
> URL: https://issues.apache.org/jira/browse/MYNEWT-745
> Project: Mynewt
> Issue Type: Bug
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
> Attachments: main.c
>
>
> The problem appears to occur when a system call is interrupted by a sim
> context switch. Because a sim context switch is implemented as a signal
> handler that never returns (it calls longjmp()), the system call is left
> unfinished. In some cases, it seems the system call acquired some resources
> that it never got a chance to release, leading to deadlock on a subsequent
> system call. For whatever reason, when the original system call is resumed
> (i.e., when Mynewt switch back to the original task), the syscall is unable
> to recover.
> In sim, a context switch is triggered by delivery of a SIGURG signal. A few
> events generate this signal:
> # A task calls an OS function with the potential to switch tasks (e.g.,
> os_eventq_get(), os_mutex_release(), etc.).
> # An OS tick occurs.
> The problem appears to occur when an OS tick generates the SIGURG signal.
> The OS ticker is implemented via an itimer, which generates the SIG_ALRM
> signal on each tick. The SIG_ALRM handler advances the OS time, and then
> calls os_sched(), potentially generating a SIGURG signal. If the current
> task happened to be in the middle of a syscall when the tick timer expired,
> the SIGURG signal gets handled before the syscall returns.
> Here is a stack trace showing a context switch in the middle of a system call:
> {noformat}
> (gdb) whe
> #0 0x0804a3bd in ctxsw_handler (sig=23)
> at kernel/os/src/arch/sim/os_arch_sim.c:150
> #1
> #2 0xf7ffdbe7 in __kernel_vsyscall ()
> #3 0x08097630 in __lll_lock_wait_private ()
> #4 0x080923b0 in __tz_convert ()
> #5 0x08091673 in localtime ()
> #6 0x0809162c in ctime ()
> #7 0x08048a5a in task1_handler (arg=0x0) at apps/slinky/src/main.c:162
> #8 0x0804a2c8 in os_arch_task_start (sf=0x8160314, rc=1)
> at kernel/os/src/arch/sim/os_arch_sim.c:88
> #9 0x0804ad90 in os_arch_frame_init ()
> at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
> #10 0x0804ad90 in os_arch_frame_init ()
> at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
> {noformat}
> Attached is a simple Mynewt app that can be used to replicate this issue
> (main.c).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MYNEWT-745) Sim - deadlock involving system calls
[
https://issues.apache.org/jira/browse/MYNEWT-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-745:
---
Description:
The problem appears to occur when a system call is interrupted by a sim context
switch. Because a sim context switch is implemented as a signal handler that
never returns (it calls longjmp()), the system call is left unfinished. In
some cases, it seems the system call acquired some resources that it never got
a chance to release, leading to deadlock on a subsequent system call. For
whatever reason, when the original system call is resumed (i.e., when Mynewt
switch back to the original task), the syscall is unable to recover.
In sim, a context switch is triggered by delivery of a SIGURG signal. A few
events generate this signal:
# A task calls an OS function with the potential to switch tasks (e.g.,
os_eventq_get(), os_mutex_release(), etc.).
# An OS tick occurs.
The problem appears to occur when an OS tick generates the SIGURG signal. The
OS ticker is implemented via an itimer, which generates the SIG_ALRM signal on
each tick. The SIG_ALRM handler advances the OS time, and then calls
os_sched(), potentially generating a SIGURG signal. If the current task
happened to be in the middle of a syscall when the tick timer expired, the
SIGURG signal gets handled before the syscall returns.
Here is a stack trace showing a context switch in the middle of a system call:
{noformat}
(gdb) whe
#0 0x0804a3bd in ctxsw_handler (sig=23)
at kernel/os/src/arch/sim/os_arch_sim.c:150
#1
#2 0xf7ffdbe7 in __kernel_vsyscall ()
#3 0x08097630 in __lll_lock_wait_private ()
#4 0x080923b0 in __tz_convert ()
#5 0x08091673 in localtime ()
#6 0x0809162c in ctime ()
#7 0x08048a5a in task1_handler (arg=0x0) at apps/slinky/src/main.c:162
#8 0x0804a2c8 in os_arch_task_start (sf=0x8160314, rc=1)
at kernel/os/src/arch/sim/os_arch_sim.c:88
#9 0x0804ad90 in os_arch_frame_init ()
at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
#10 0x0804ad90 in os_arch_frame_init ()
at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
{noformat}
Attached is a simple Mynewt app that can be used to replicate this issue
(main.c).
was:
The problem appears to occur when a system call is interrupted by a sim context
switch. Because a sim context switch is implemented as a signal handler that
never returns (it calls longjmp()), the system call is left unfinished. In
some cases, it seems the system call acquired some resources that it never got
a chance to release, leading to deadlock on a subsequent system call.
Sim has protections in place to prevent this problem from happening.
Specifically, a context switch is triggered by delivery of a SIGURG signal, and
SIGURG is only sent from within the SIGALARM signal handler. These handlers
are configured such that all signals are blocked until the handlers complete (I
am not sure how this works for the SIGURG handler, considering it never
returns).
My initial guess was that a pending SIGURG signal does not get delivered as
soon as it is unblocked at the end of the SIGALARM handler. However, a simple
test using sigpending() and sleep prove that this is not the case.
Here is a stack trace showing a context switch in the middle of a system call:
{noformat}
(gdb) whe
#0 0x0804a3bd in ctxsw_handler (sig=23)
at kernel/os/src/arch/sim/os_arch_sim.c:150
#1
#2 0xf7ffdbe7 in __kernel_vsyscall ()
#3 0x08097630 in __lll_lock_wait_private ()
#4 0x080923b0 in __tz_convert ()
#5 0x08091673 in localtime ()
#6 0x0809162c in ctime ()
#7 0x08048a5a in task1_handler (arg=0x0) at apps/slinky/src/main.c:162
#8 0x0804a2c8 in os_arch_task_start (sf=0x8160314, rc=1)
at kernel/os/src/arch/sim/os_arch_sim.c:88
#9 0x0804ad90 in os_arch_frame_init ()
at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
#10 0x0804ad90 in os_arch_frame_init ()
at kernel/os/src/arch/sim/os_arch_stack_frame.s:98
{noformat}
Attached is a simple Mynewt app that can be used to replicate this issue
(main.c).
> Sim - deadlock involving system calls
> -
>
> Key: MYNEWT-745
> URL: https://issues.apache.org/jira/browse/MYNEWT-745
> Project: Mynewt
> Issue Type: Bug
>Reporter: Christopher Collins
> Fix For: v1_1_0_rel
>
> Attachments: main.c
>
>
> The problem appears to occur when a system call is interrupted by a sim
> context switch. Because a sim context switch is implemented as a signal
> handler that never returns (it calls longjmp()), the system call is left
> unfinished. In some cases, it seems the system call acquired some resources
> that it never got a chance to release, leading to deadlock on a subsequent
> system call. For whatever reason, when the original system call is resumed
> (i.e., when Mynewt switch back to the
[jira] [Created] (MYNEWT-743) BLE Host - Persist bonding material to sys/config.
Christopher Collins created MYNEWT-743: -- Summary: 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 Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-742) OIC requires some manual steps to initialize
Christopher Collins created MYNEWT-742:
--
Summary: OIC requires some manual steps to initialize
Key: MYNEWT-742
URL: https://issues.apache.org/jira/browse/MYNEWT-742
Project: Mynewt
Issue Type: Bug
Reporter: Christopher Collins
Fix For: v1_1_0_rel
E.g.,
{noformat}
static const oc_handler_t omgr_oc_handler = {
.init = omgr_app_init,
};
int
main(int argc, char **argv)
{
/* ... */
oc_main_init((oc_handler_t *)_oc_handler);
oc_ble_coap_gatt_srv_init();
}
{noformat}
If possible, it would be good if these calls happened automatically when the OS
starts. Unfortunately, the user will still need to configure the library with
an oc_handler.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MYNEWT-736) NimBLE - UART transport can't send multi-buf chains
[ https://issues.apache.org/jira/browse/MYNEWT-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-736. Resolution: Fixed > NimBLE - UART transport can't send multi-buf chains > --- > > Key: MYNEWT-736 > URL: https://issues.apache.org/jira/browse/MYNEWT-736 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > The UART transport assumes outgoing ACL data packets consist of a single > mbuf. If the chain contains multiple buffers, the later part of the outgoing > packet consists of all zeros. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-740) Text parsing package
Christopher Collins created MYNEWT-740: -- Summary: Text parsing package Key: MYNEWT-740 URL: https://issues.apache.org/jira/browse/MYNEWT-740 Project: Mynewt Issue Type: Improvement Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel Code to parse numbers and byte strings is duplicated in a lot of apps. It would be good to create a general purpose package that does this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-718) newt - Build failure under 32-bit OS
[
https://issues.apache.org/jira/browse/MYNEWT-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins resolved MYNEWT-718.
Resolution: Fixed
> newt - Build failure under 32-bit OS
>
>
> Key: MYNEWT-718
> URL: https://issues.apache.org/jira/browse/MYNEWT-718
> Project: Mynewt
> Issue Type: Bug
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> {noformat}
> From: F Campos
>
>
>
> To: d...@mynewt.incubator.apache.org
> Date: Sat, 8 Apr 2017 19:06:24 +0100
> Subject: mynewt, build on ubuntu
>
>
>
> Hi,
> when building the mynewt on ubuntu I have an error on go builder:
> *syscfg/syscfg.go:965: constant 4294967295 overflows int*
> Seems that the SYSCFG_INTERRUPT_PRIO_MAX is too big for the variable "int"
> *Linux Version:*
> lsb_release -a
> Distributor ID: Ubuntu
> Description: Ubuntu 14.04.4 LTS
> Release: 14.04
> Codename: trusty
> *Go version:*
> go version
> go version go1.7 linux/386
> Filipe
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MYNEWT-711) testbench - Add BLE peripheral support
Christopher Collins created MYNEWT-711: -- Summary: testbench - Add BLE peripheral support Key: MYNEWT-711 URL: https://issues.apache.org/jira/browse/MYNEWT-711 Project: Mynewt Issue Type: Improvement 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-709) nffs - Occasional unit test failures
[
https://issues.apache.org/jira/browse/MYNEWT-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins resolved MYNEWT-709.
Resolution: Fixed
> nffs - Occasional unit test failures
>
>
> Key: MYNEWT-709
> URL: https://issues.apache.org/jira/browse/MYNEWT-709
> Project: Mynewt
> Issue Type: Bug
> Components: NFFS
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> {noformat}
> 03/31/2017, 18:42:11.997 Executing test:
> /home/jenkins/workspace/0-testall-sim/newt_ci_templates/bin/targets/unittest/fs_nffs_test/app/fs/nffs/test/fs_nffs_test.elf
> 03/31/2017, 18:42:13.802 Test failure (fs/nffs/test):
> 03/31/2017, 18:42:13.803 [pass] nffs_test_suite/nffs_test_unlink
> 03/31/2017, 18:42:13.804 [pass] nffs_test_suite/nffs_test_mkdir
> 03/31/2017, 18:42:13.805 [pass] nffs_test_suite/nffs_test_rename
> 03/31/2017, 18:42:13.805 [pass] nffs_test_suite/nffs_test_truncate
> 03/31/2017, 18:42:13.806 [pass] nffs_test_suite/nffs_test_append
> 03/31/2017, 18:42:13.807 [pass] nffs_test_suite/nffs_test_read
> 03/31/2017, 18:42:13.808 [pass] nffs_test_suite/nffs_test_open
> 03/31/2017, 18:42:13.809 [pass] nffs_test_suite/nffs_test_overwrite_one
> 03/31/2017, 18:42:13.809 [pass] nffs_test_suite/nffs_test_overwrite_two
> 03/31/2017, 18:42:13.810 [pass] nffs_test_suite/nffs_test_overwrite_three
> 03/31/2017, 18:42:13.811 [pass] nffs_test_suite/nffs_test_overwrite_many
> 03/31/2017, 18:42:13.812 [pass] nffs_test_suite/nffs_test_long_filename
> 03/31/2017, 18:42:13.813 [pass] nffs_test_suite/nffs_test_large_write
> 03/31/2017, 18:42:13.813 [pass] nffs_test_suite/nffs_test_many_children
> 03/31/2017, 18:42:13.814 [pass] nffs_test_suite/nffs_test_gc
> 03/31/2017, 18:42:13.815 [pass] nffs_test_suite/nffs_test_wear_level
> 03/31/2017, 18:42:13.816 [pass] nffs_test_suite/nffs_test_corrupt_scratch
> 03/31/2017, 18:42:13.817 [pass]
> nffs_test_suite/nffs_test_incomplete_block
> 03/31/2017, 18:42:13.817 [FAIL] nffs_test_suite/nffs_test_corrupt_block
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.818 [FAIL] nffs_test_suite/nffs_test_corrupt_block
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.819 [FAIL] nffs_test_suite/nffs_test_corrupt_block
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.820 [pass] nffs_test_suite/nffs_test_large_unlink
> 03/31/2017, 18:42:13.821
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.821 [pass] nffs_test_suite/nffs_test_large_system
> 03/31/2017, 18:42:13.822
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.823 [pass] nffs_test_suite/nffs_test_lost_found
> 03/31/2017, 18:42:13.824
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.824 [pass] nffs_test_suite/nffs_test_readdir
> 03/31/2017, 18:42:13.825
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.826 [pass] nffs_test_suite/nffs_test_split_file
> 03/31/2017, 18:42:13.827
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.828 [pass] nffs_test_suite/nffs_test_gc_on_oom
> 03/31/2017, 18:42:13.828
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.829 [pass] nffs_test_suite/nffs_test_unlink
> 03/31/2017, 18:42:13.830
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.831 [pass] nffs_test_suite/nffs_test_mkdir
> 03/31/2017, 18:42:13.832
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.832 [pass] nffs_test_suite/nffs_test_rename
> 03/31/2017, 18:42:13.833
> |repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
> assertion: i < nffs_test_num_touched_entries
> 03/31/2017, 18:42:13.834 [pass]
[jira] [Created] (MYNEWT-709) nffs - Occasional unit test failures
Christopher Collins created MYNEWT-709:
--
Summary: nffs - Occasional unit test failures
Key: MYNEWT-709
URL: https://issues.apache.org/jira/browse/MYNEWT-709
Project: Mynewt
Issue Type: Bug
Components: NFFS
Reporter: Christopher Collins
Assignee: Christopher Collins
Fix For: v1_1_0_rel
{noformat}
03/31/2017, 18:42:11.997Executing test:
/home/jenkins/workspace/0-testall-sim/newt_ci_templates/bin/targets/unittest/fs_nffs_test/app/fs/nffs/test/fs_nffs_test.elf
03/31/2017, 18:42:13.802Test failure (fs/nffs/test):
03/31/2017, 18:42:13.803[pass] nffs_test_suite/nffs_test_unlink
03/31/2017, 18:42:13.804[pass] nffs_test_suite/nffs_test_mkdir
03/31/2017, 18:42:13.805[pass] nffs_test_suite/nffs_test_rename
03/31/2017, 18:42:13.805[pass] nffs_test_suite/nffs_test_truncate
03/31/2017, 18:42:13.806[pass] nffs_test_suite/nffs_test_append
03/31/2017, 18:42:13.807[pass] nffs_test_suite/nffs_test_read
03/31/2017, 18:42:13.808[pass] nffs_test_suite/nffs_test_open
03/31/2017, 18:42:13.809[pass] nffs_test_suite/nffs_test_overwrite_one
03/31/2017, 18:42:13.809[pass] nffs_test_suite/nffs_test_overwrite_two
03/31/2017, 18:42:13.810[pass] nffs_test_suite/nffs_test_overwrite_three
03/31/2017, 18:42:13.811[pass] nffs_test_suite/nffs_test_overwrite_many
03/31/2017, 18:42:13.812[pass] nffs_test_suite/nffs_test_long_filename
03/31/2017, 18:42:13.813[pass] nffs_test_suite/nffs_test_large_write
03/31/2017, 18:42:13.813[pass] nffs_test_suite/nffs_test_many_children
03/31/2017, 18:42:13.814[pass] nffs_test_suite/nffs_test_gc
03/31/2017, 18:42:13.815[pass] nffs_test_suite/nffs_test_wear_level
03/31/2017, 18:42:13.816[pass] nffs_test_suite/nffs_test_corrupt_scratch
03/31/2017, 18:42:13.817[pass]
nffs_test_suite/nffs_test_incomplete_block
03/31/2017, 18:42:13.817[FAIL] nffs_test_suite/nffs_test_corrupt_block
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.818[FAIL] nffs_test_suite/nffs_test_corrupt_block
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.819[FAIL] nffs_test_suite/nffs_test_corrupt_block
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.820[pass] nffs_test_suite/nffs_test_large_unlink
03/31/2017, 18:42:13.821
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.821[pass] nffs_test_suite/nffs_test_large_system
03/31/2017, 18:42:13.822
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.823[pass] nffs_test_suite/nffs_test_lost_found
03/31/2017, 18:42:13.824
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.824[pass] nffs_test_suite/nffs_test_readdir
03/31/2017, 18:42:13.825
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.826[pass] nffs_test_suite/nffs_test_split_file
03/31/2017, 18:42:13.827
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.828[pass] nffs_test_suite/nffs_test_gc_on_oom
03/31/2017, 18:42:13.828
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.829[pass] nffs_test_suite/nffs_test_unlink
03/31/2017, 18:42:13.830
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.831[pass] nffs_test_suite/nffs_test_mkdir
03/31/2017, 18:42:13.832
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.832[pass] nffs_test_suite/nffs_test_rename
03/31/2017, 18:42:13.833
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.834[pass] nffs_test_suite/nffs_test_truncate
03/31/2017, 18:42:13.835
|repos/apache-mynewt-core/fs/nffs/test/src/nffs_test_utils.c:458| failed
assertion: i < nffs_test_num_touched_entries
03/31/2017, 18:42:13.835[pass] nffs_test_suite/nffs_test_append
[jira] [Updated] (MYNEWT-708) Lock scheduler during init
[
https://issues.apache.org/jira/browse/MYNEWT-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-708:
---
Description:
Now that main() runs after the OS is started, tasks may preempt the main task
as soon as they are created. If such a task expects all packages to have been
initialized, then a crash or other unpredictable behavior will occur.
Here is an example crash that happens when the BLE link layer task runs before
the host package is fully initialized:
{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
{noformat}
was:
Now that main() runs after the OS is started, tasks may preempt the main task
as soon as they are created. If such a task expects all packages to have been
initialized, then a crash or other unpredictable behavior will occur.
Here is an example crash that happens when the BLE link layer task runs before
the host package is fully initialized:
{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
(gdb)
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
{noformat}
> Lock scheduler during init
> --
>
> Key: MYNEWT-708
> URL: https://issues.apache.org/jira/browse/MYNEWT-708
> Project: Mynewt
> Issue Type: Bug
>Reporter: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> Now that main() runs after the OS is started, tasks may preempt the main task
> as soon as they are created. If such a task expects all packages to have
> been initialized, then a crash or other unpredictable behavior will occur.
> Here is an example crash that happens when the BLE link layer task runs
> before the host package is fully initialized:
> {noformat}
> Program received signal SIGTRAP, Trace/breakpoint trap.
> __assert_func (file=, line=, func= out>, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
> 137asm("bkpt");
> (gdb) whe
> #0 __assert_func (file=, line=,
> func=, e=) at
> kernel/os/src/arch/cortex_m4/os_fault.c:137
> #1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
> net/nimble/transport/ram/src/ble_hci_ram.c:91
> #2 0xea5e in ble_ll_hci_send_noop () at
> net/nimble/controller/src/ble_ll_hci.c:106
> #3 0xa438 in ble_ll_task (arg=) at
> net/nimble/controller/src/ble_ll.c:1008
> #4 0x in ?? ()
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MYNEWT-708) Lock scheduler during init
Christopher Collins created MYNEWT-708:
--
Summary: Lock scheduler during init
Key: MYNEWT-708
URL: https://issues.apache.org/jira/browse/MYNEWT-708
Project: Mynewt
Issue Type: Bug
Reporter: Christopher Collins
Fix For: v1_1_0_rel
Now that main() runs after the OS is started, tasks may preempt the main task
as soon as they are created. If such a task expects all packages to have been
initialized, then a crash or other unpredictable behavior will occur.
Here is an example crash that happens when the BLE link layer task runs before
the host package is fully initialized:
{noformat}
Program received signal SIGTRAP, Trace/breakpoint trap.
__assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
137asm("bkpt");
(gdb) whe
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
(gdb)
#0 __assert_func (file=, line=, func=, e=) at kernel/os/src/arch/cortex_m4/os_fault.c:137
#1 0x00019f2e in ble_hci_trans_ll_evt_tx (hci_ev=) at
net/nimble/transport/ram/src/ble_hci_ram.c:91
#2 0xea5e in ble_ll_hci_send_noop () at
net/nimble/controller/src/ble_ll_hci.c:106
#3 0xa438 in ble_ll_task (arg=) at
net/nimble/controller/src/ble_ll.c:1008
#4 0x in ?? ()
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MYNEWT-702) BLE Host - duplicate connection update entries
[ https://issues.apache.org/jira/browse/MYNEWT-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-702. Resolution: Fixed > BLE Host - duplicate connection update entries > -- > > Key: MYNEWT-702 > URL: https://issues.apache.org/jira/browse/MYNEWT-702 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > If the application calls ble_gap_update_params() while an update connection > procedure for that connection is already in progress, the existing entry gets > re-inserted in the ble_gap_update_entries list. This yields a cycle in the > list, causing the host task to loop endlessly during iteration. > More details: > # Host initiates a connection update procedure; creates an entry and inserts > it into the list (ble_gap_update_entries). > # Host attempts to initiate a second connection update procedure for the same > connection. Since an existing update procedure is ongoing, this attempt > fails with a status code of BLE_HS_EALREADY. > # On detecting the error, the ble_gap_update_params() function tries to clean > up (goto done). Part of this cleanup involves freeing the update entry that > got allocated earlier in the function but never got inserted into the list. > In this case, no entry was allocated, but it looks like one was, because the > entry pointer was used to detect a duplicate entry. Consequently, the entry > is freed but never removed from the list! > # The host initiates a third connection update procedure for the same > connection. This time, no duplicate is detected because the entry in the > list got corrupted when it was freed, making its connection handle value > indeterminate. The host allocates the same entry from the pool, populates > it, and inserts it into the list. Now the same entry is in the list twice, > creating a cycle. When the host iterates this list, it loops forever. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-696) NMP datetime response uses inconsistent format
[ https://issues.apache.org/jira/browse/MYNEWT-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-696. Resolution: Fixed > NMP datetime response uses inconsistent format > -- > > Key: MYNEWT-696 > URL: https://issues.apache.org/jira/browse/MYNEWT-696 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > If the time was set with a time zone, the datetime response includes the time > zone at the end of the string. Otherwise, no time zone is present. > This inconsistency makes parsing more difficult. The fix is to report UTC as > the time zone if none was explicitly specified. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-702) BLE Host - duplicate connection update entries
[ https://issues.apache.org/jira/browse/MYNEWT-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-702: --- Description: If the application calls ble_gap_update_params() while an update connection procedure for that connection is already in progress, the existing entry gets re-inserted in the ble_gap_update_entries list. This yields a cycle in the list, causing the host task to loop endlessly during iteration. More details: # Host initiates a connection update procedure; creates an entry and inserts it into the list (ble_gap_update_entries). # Host attempts to initiate a second connection update procedure for the same connection. Since an existing update procedure is ongoing, this attempt fails with a status code of BLE_HS_EALREADY. # On detecting the error, the ble_gap_update_params() function tries to clean up (goto done). Part of this cleanup involves freeing the update entry that got allocated earlier in the function but never got inserted into the list. In this case, no entry was allocated, but it looks like one was, because the entry pointer was used to detect a duplicate entry. Consequently, the entry is freed but never removed from the list! # The host initiates a third connection update procedure for the same connection. This time, no duplicate is detected because the entry in the list got corrupted when it was freed, making its connection handle value indeterminate. The host allocates the same entry from the pool, populates it, and inserts it into the list. Now the same entry is in the list twice, creating a cycle. When the host iterates this list, it loops forever. was:If the application calls ble_gap_update_params() while an update connection procedure for that connection is already in progress, the existing entry gets re-inserted in the ble_gap_update_entries list. This yields a cycle in the list, causing the host task to loop endlessly during iteration. > BLE Host - duplicate connection update entries > -- > > Key: MYNEWT-702 > URL: https://issues.apache.org/jira/browse/MYNEWT-702 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > If the application calls ble_gap_update_params() while an update connection > procedure for that connection is already in progress, the existing entry gets > re-inserted in the ble_gap_update_entries list. This yields a cycle in the > list, causing the host task to loop endlessly during iteration. > More details: > # Host initiates a connection update procedure; creates an entry and inserts > it into the list (ble_gap_update_entries). > # Host attempts to initiate a second connection update procedure for the same > connection. Since an existing update procedure is ongoing, this attempt > fails with a status code of BLE_HS_EALREADY. > # On detecting the error, the ble_gap_update_params() function tries to clean > up (goto done). Part of this cleanup involves freeing the update entry that > got allocated earlier in the function but never got inserted into the list. > In this case, no entry was allocated, but it looks like one was, because the > entry pointer was used to detect a duplicate entry. Consequently, the entry > is freed but never removed from the list! > # The host initiates a third connection update procedure for the same > connection. This time, no duplicate is detected because the entry in the > list got corrupted when it was freed, making its connection handle value > indeterminate. The host allocates the same entry from the pool, populates > it, and inserts it into the list. Now the same entry is in the list twice, > creating a cycle. When the host iterates this list, it loops forever. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-702) BLE Host - duplicate connection update entries
Christopher Collins created MYNEWT-702: -- Summary: BLE Host - duplicate connection update entries Key: MYNEWT-702 URL: https://issues.apache.org/jira/browse/MYNEWT-702 Project: Mynewt Issue Type: Bug Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel If the application calls ble_gap_update_params() while an update connection procedure for that connection is already in progress, the existing entry gets re-inserted in the ble_gap_update_entries list. This yields a cycle in the list, causing the host task to loop endlessly during iteration. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-700) BLE Host - Race condition: disconnect + att-tx
Christopher Collins created MYNEWT-700: -- Summary: BLE Host - Race condition: disconnect + att-tx Key: MYNEWT-700 URL: https://issues.apache.org/jira/browse/MYNEWT-700 Project: Mynewt Issue Type: Bug Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel Some parts of the ATT code assume a peer is still connected after an initial check. This assumption leads to a race condition when a task other than the host task is doing the transmitting (e.g., tx of unsolicited notification). It is possible that the peer gets disconnected after the tx function is called, but before it completes. When this occurs, an assertion fails (ble_att_conn_chan_find()). The fix is to remove this assumption. Always check that the connection / channel lookup succeeds before accessing the returned pointers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-657) Ability to configure per-module log level at compile time
[ https://issues.apache.org/jira/browse/MYNEWT-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-657: --- Description: Currently, the log level can only be configured globally (via the LOG_LEVEL syscfg setting). It would be useful if each module had its own log level. Unfortunately, I don't know of a better way to do this than to define module-specific versions of all the LOG_... macros. was:Currently, the log level can only be configured globally (via the LOG_LEVEL syscfg setting). It would be useful if each module had its own log level. Summary: Ability to configure per-module log level at compile time (was: Ability to configure log level per module) > Ability to configure per-module log level at compile time > - > > Key: MYNEWT-657 > URL: https://issues.apache.org/jira/browse/MYNEWT-657 > Project: Mynewt > Issue Type: Improvement >Reporter: Christopher Collins > Fix For: v1_1_0_rel > > > Currently, the log level can only be configured globally (via the LOG_LEVEL > syscfg setting). It would be useful if each module had its own log level. > Unfortunately, I don't know of a better way to do this than to define > module-specific versions of all the LOG_... macros. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-677) NMP: Include next_index in log show response
[
https://issues.apache.org/jira/browse/MYNEWT-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins resolved MYNEWT-677.
Resolution: Fixed
> NMP: Include next_index in log show response
>
>
> Key: MYNEWT-677
> URL: https://issues.apache.org/jira/browse/MYNEWT-677
> Project: Mynewt
> Issue Type: Bug
> Components: Newtmgr
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The next_index value (index of next log entry to be written) is useful for
> determining if a device's flash has been wiped since the last time logs were
> scoured.
> The new value is at the top-level of the log show response with the following
> name: {{next_index}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MYNEWT-677) NMP: Include next_index in log show response
[
https://issues.apache.org/jira/browse/MYNEWT-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Collins updated MYNEWT-677:
---
Description:
The next_index value (index of next log entry to be written) is useful for
determining if a device's flash has been wiped since the last time logs were
scoured.
The new value is at the top-level of the log show response with the following
name: {{next_index}}.
was:The next_index value (index of next log entry to be written) is useful
for determining if a device's flash has been wiped since the last time logs
were scoured.
> NMP: Include next_index in log show response
>
>
> Key: MYNEWT-677
> URL: https://issues.apache.org/jira/browse/MYNEWT-677
> Project: Mynewt
> Issue Type: Bug
> Components: Newtmgr
>Reporter: Christopher Collins
>Assignee: Christopher Collins
> Fix For: v1_1_0_rel
>
>
> The next_index value (index of next log entry to be written) is useful for
> determining if a device's flash has been wiped since the last time logs were
> scoured.
> The new value is at the top-level of the log show response with the following
> name: {{next_index}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MYNEWT-677) NMP: Include next_index in log show response
Christopher Collins created MYNEWT-677: -- Summary: NMP: Include next_index in log show response Key: MYNEWT-677 URL: https://issues.apache.org/jira/browse/MYNEWT-677 Project: Mynewt Issue Type: Bug Components: Newtmgr Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel The next_index value (index of next log entry to be written) is useful for determining if a device's flash has been wiped since the last time logs were scoured. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-676) Reboot counter value inconsistent
Christopher Collins created MYNEWT-676: -- Summary: Reboot counter value inconsistent Key: MYNEWT-676 URL: https://issues.apache.org/jira/browse/MYNEWT-676 Project: Mynewt Issue Type: Bug Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel The value that gets logged to the reboot log is one greater than the actual reboot counter (the value retrieved via "newtmgr config reboot/reboot_cnt"). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-674) newt - Remove use of new io.SeekCurrent symbol
[ https://issues.apache.org/jira/browse/MYNEWT-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-674. Resolution: Fixed > newt - Remove use of new io.SeekCurrent symbol > -- > > Key: MYNEWT-674 > URL: https://issues.apache.org/jira/browse/MYNEWT-674 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > This constant was added in go 1.7. A lot of package manager repos only carry > go 1.6, so the use of this constant makes newt unbuildable for a lot of users. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-674) newt - Remove use of new io.SeekCurrent symbol
Christopher Collins created MYNEWT-674: -- Summary: newt - Remove use of new io.SeekCurrent symbol Key: MYNEWT-674 URL: https://issues.apache.org/jira/browse/MYNEWT-674 Project: Mynewt Issue Type: Bug Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel This constant was added in go 1.7. A lot of package manager repos only carry go 1.6, so the use of this constant makes newt unbuildable for a lot of users. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-673) testbench app reports some fails as passes
[ https://issues.apache.org/jira/browse/MYNEWT-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-673. Resolution: Fixed > testbench app reports some fails as passes > -- > > Key: MYNEWT-673 > URL: https://issues.apache.org/jira/browse/MYNEWT-673 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (MYNEWT-660) newt - Quotes get stripped from syscfg values when they are written
[ https://issues.apache.org/jira/browse/MYNEWT-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins reassigned MYNEWT-660: -- Assignee: Christopher Collins (was: Sterling Hughes) Summary: newt - Quotes get stripped from syscfg values when they are written (was: newt - Quotes get stripped from yaml files when they are written) > newt - Quotes get stripped from syscfg values when they are written > --- > > Key: MYNEWT-660 > URL: https://issues.apache.org/jira/browse/MYNEWT-660 > Project: Mynewt > Issue Type: Bug > Components: Newt >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-671) UART support in sim
[ https://issues.apache.org/jira/browse/MYNEWT-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-671. Resolution: Fixed > UART support in sim > --- > > Key: MYNEWT-671 > URL: https://issues.apache.org/jira/browse/MYNEWT-671 > Project: Mynewt > Issue Type: Bug >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > Currently, sim always maps UARTs to ptys. This change allows the application > to specify a file (e.g., /dev/...) to map a UART to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-671) UART support in sim
Christopher Collins created MYNEWT-671: -- Summary: UART support in sim Key: MYNEWT-671 URL: https://issues.apache.org/jira/browse/MYNEWT-671 Project: Mynewt Issue Type: Bug Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel Currently, sim always maps UARTs to ptys. This change allows the application to specify a file (e.g., /dev/...) to map a UART to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MYNEWT-670) NMP: Make max chunk size configurable
[ https://issues.apache.org/jira/browse/MYNEWT-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins resolved MYNEWT-670. Resolution: Fixed > NMP: Make max chunk size configurable > - > > Key: MYNEWT-670 > URL: https://issues.apache.org/jira/browse/MYNEWT-670 > Project: Mynewt > Issue Type: Improvement > Components: Newtmgr >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > Currently, the largest image or file chunk that a Mynewt device can receive > is hardcoded at 400 bytes. Furthermore, the largets CBOR attribute that we > can decode is 300 bytes long.This is not great because this number is > independent of the transport MTU, so the client has no way of knowing the > limit. > The fix is to create three new compile-time settings: > * CBORATTR_MAX_SIZE > * FS_UPLOAD_MAX_CHUNK_SIZE > * IMGMGR_MAX_CHUNK_SIZE > and set them to 512 by default. This value is large enough to accommodate > full-size BLE packets. > This is still not a perfect solution because these values are not tied to the > MTU in any way. One way to truly solve this would be to have an "NMP MTU" > that the client can discover. That would be a pretty big change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-670) NMP: Make max chunk size configurable
[ https://issues.apache.org/jira/browse/MYNEWT-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-670: --- Description: Currently, the largest image or file chunk that a Mynewt device can receive is hardcoded at 400 bytes. Furthermore, the largets CBOR attribute that we can decode is 300 bytes long.This is not great because this number is independent of the transport MTU, so the client has no way of knowing the limit. The fix is to create three new compile-time settings: * CBORATTR_MAX_SIZE * FS_UPLOAD_MAX_CHUNK_SIZE * IMGMGR_MAX_CHUNK_SIZE and set them to 512 by default. This value is large enough to accommodate full-size BLE packets. This is still not a perfect solution because these values are not tied to the MTU in any way. One way to truly solve this would be to have an "NMP MTU" that the client can discover. That would be a pretty big change. was: Currently, the largest image or file chunk that a Mynewt device can receive is hardcoded at 400 bytes. This is not great because this number is independent of the transport MTU, so the client has no way of knowing the limit. The fix is to create two new compile-time settings: * FS_UPLOAD_MAX_CHUNK_SIZE * IMGMGR_MAX_CHUNK_SIZE and set them to 512 by default. This value is large enough to accommodate full-size BLE packets. This is still not a perfect solution because these values are not tied to the MTU in any way. One way to truly solve this would be to have an "NMP MTU" that the client can discover. That would be a pretty big change. Summary: NMP: Make max chunk size configurable (was: image / fs NMP: Make max chunk size configurable) > NMP: Make max chunk size configurable > - > > Key: MYNEWT-670 > URL: https://issues.apache.org/jira/browse/MYNEWT-670 > Project: Mynewt > Issue Type: Improvement > Components: Newtmgr >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > Currently, the largest image or file chunk that a Mynewt device can receive > is hardcoded at 400 bytes. Furthermore, the largets CBOR attribute that we > can decode is 300 bytes long.This is not great because this number is > independent of the transport MTU, so the client has no way of knowing the > limit. > The fix is to create three new compile-time settings: > * CBORATTR_MAX_SIZE > * FS_UPLOAD_MAX_CHUNK_SIZE > * IMGMGR_MAX_CHUNK_SIZE > and set them to 512 by default. This value is large enough to accommodate > full-size BLE packets. > This is still not a perfect solution because these values are not tied to the > MTU in any way. One way to truly solve this would be to have an "NMP MTU" > that the client can discover. That would be a pretty big change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MYNEWT-670) image / fs NMP: Make max chunk size configurable
Christopher Collins created MYNEWT-670: -- Summary: image / fs NMP: Make max chunk size configurable Key: MYNEWT-670 URL: https://issues.apache.org/jira/browse/MYNEWT-670 Project: Mynewt Issue Type: Improvement Components: Newtmgr Reporter: Christopher Collins Assignee: Christopher Collins Fix For: v1_1_0_rel Currently, the largest image or file chunk that a Mynewt device can receive is hardcoded at 400 bytes. This is not great because this number is independent of the transport MTU, so the client has no way of knowing the limit. The fix is to create two new compile-time settings: * FS_UPLOAD_MAX_CHUNK_SIZE * IMGMGR_MAX_CHUNK_SIZE and set them to 512 by default. This value is large enough to accommodate full-size BLE packets. This is still not a perfect solution because these values are not tied to the MTU in any way. One way to truly solve this would be to have an "NMP MTU" that the client can discover. That would be a pretty big change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
