[jira] [Created] (MYNEWT-755) newtmgr panic: runtime error: cgo argument has Go pointer to Go pointer
Jacob created MYNEWT-755: Summary: 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 Components: Newtmgr Reporter: Jacob Assignee: Sterling Hughes 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.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-752) Error in setting the "permanent" flag upon confirm with hash during image upgrade
Aditi Hilbert created MYNEWT-752: Summary: 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 Reporter: Aditi Hilbert Assignee: Christopher Collins 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] [Commented] (MYNEWT-526) Gap params update succeeds, but times out immediately after
[ https://issues.apache.org/jira/browse/MYNEWT-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16006440#comment-16006440 ] ASF subversion and git services commented on MYNEWT-526: Commit 9f3452cab921043743b9512c55e248acdb676d5d in incubator-mynewt-core's branch refs/heads/master from [~andk] [ https://git-wip-us.apache.org/repos/asf?p=incubator-mynewt-core.git;h=9f3452c ] nimble/ll: Add option to schedule connection with non-zero WindowOffset Devices based on TI CC254x with older stack version have bug where connection parameters are not updated properly on slave device if transmitWindowOffset in CONNECT_IND was set to 0 (and apparently this applies to 1 as well). To workaround this, we allow to use larger transmitWindowOffset in CONNECT_IND - by default this is set to 0, for old TI CC254x IOP should be set to at least 2. This also fixes MYNEWT-526. > Gap params update succeeds, but times out immediately after > --- > > Key: MYNEWT-526 > URL: https://issues.apache.org/jira/browse/MYNEWT-526 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Affects Versions: v1_0_0_beta1 > Environment: macos sierra, gcc version 5.4.1 20160919 >Reporter: Jacob >Assignee: Łukasz Rymanowski > Attachments: polar_mynewt.pcap, polar_mynewt.pcap, > polar_mynewt_with_android_param.pcapng > > > Modification of blecent, connecting and subscribing to my polar HRM. > My monitor (consistently) connects and subscribes and gets notifications for > like 30 seconds before it does a successful gap params update, and then > promptly times out. > I havent confirmed this yet but grammar wise you do seem to be mixing terms, > timeout_multiplier and supervision_timeout are separate things in the spec > l2cap_params->timeout_multiplier = params->supervision_timeout; > Perhaps the timeout_multiplier should be multiplied by 10ms to get the > supervision_timeout? > 3924:[ts=30656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 > handle=0x0011 > 3926:[ts=30671832ssb, mod=64 level=1] received notification; conn_handle=1 > attr_handle=17 attr_len=4 > 3928:[ts=30687456ssb, mod=64 level=1] 0x16:0x00:0xee:0x02 > 3929:[ts=30695268ssb, mod=64 level=1] pkthdr_len=16; om_len=4 > ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=13 data=0x09 0x00 0x04 0x00 > 0x1b 0x11 0x00 0x16 0x55 0xda 0x02 0xc9 0x02 > 4052:[ts=31656208ssb, mod=4 level=0] rxed att command: notify req; conn=1 > handle=0x0011 > 4054:[ts=31671832ssb, mod=64 level=1] received notification; conn_handle=1 > attr_handle=17 attr_len=6 > 4056:[ts=31687456ssb, mod=64 level=1] 0x16:0x55:0xda:0x02:0xc9:0x02 > 4057:[ts=31695268ssb, mod=64 level=1] pkthdr_len=16; om_len=6 > ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00 > 0x12 0x01 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 > 4148:[ts=32406224ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x01 > 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02 > 4151:[ts=32429660ssb, mod=4 level=1] GAP procedure initiated: connection > parameter update; conn_handle=1 itvl_min=250 itvl_max=400 latency=1 > supervision_timeout=600 min_ce_len=16 max_ce_len > 4156:[ts=32468720ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x13 > len=14 > 4158:[ts=32484344ssb, mod=4 level=0] 0x13 0x20 0x0e 0x01 0x00 0xfa 0x00 0x90 > 0x01 0x01 0x00 0x58 0x02 0x10 0x00 0x00 0x03 > 4159:[ts=32492156ssb, mod=4 level=0] Command Status: status=0 cmd_pkts=1 > ocf=0x13 ogf=0x8 > 4162:[ts=32515592ssb, mod=4 level=0] host tx hci data; handle=1 length=10 > 4163:[ts=32523404ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0a 0x00 > 0x06 0x00 0x05 0x00 0x13 0x01 0x02 0x00 0x00 0x00 > 4171:[ts=32585900ssb, mod=4 level=0] Number of Completed Packets: > num_handles=1 > 4173:[ts=32601524ssb, mod=4 level=0] handle:1 pkts:1 > 4178:[ts=32640584ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1 > pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x56 0xc0 0x02 > 4181:[ts=32664020ssb, mod=4 level=0] rxed att command: notify req; conn=1 > handle=0x0011 > 4183:[ts=32679644ssb, mod=64 level=1] received notification; conn_handle=1 > attr_handle=17 attr_len=4 > 4185:[ts=32695268ssb, mod=64 level=1] 0x16:0x56:0xc0:0x02 > 4186:[ts=32703080ssb, mod=64 level=1] pkthdr_len=16; om_len=4 LE Connection > Update Complete. handle=1 itvl=400 latency=1 timeout=600 > 4978:[ts=38890568ssb, mod=4 level=0] Disconnection Complete: status=0 > handle=1 reason=8 > 4980:[ts=38906192ssb, mod=64 level=1] disconnect; reason=520 handle=1 > our_ota_addr_type=0 our_ota_addr=0c:0c:0c:0c:0c:0c our_id_addr_type=0 > our_id_addr=0c:0c:0c:0c:0c:0c peer_ota_addr_type=0 > peer_ota_addr=00:22:d0:2a:e4:a3 peer_id_addr_type=0 > peer_id_addr=00:22:d0:2a:e4:a3 conn_itvl=400
