[jira] [Commented] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295499#comment-16295499
]
Lance Cohen commented on MYNEWT-857:
Chris, from all accounts from our iOS dev the issue appears to be very random
with no real pattern to it. He's reported that it can go for days without
triggering the failure mode that leads to the "stuck in connect" state while at
other times its triggered by just a few connections. So that makes capturing
this with a sniffer harder. We do have an Adafruit sniffer that we've used to
pipe data into Wireshark so I will try to see if I can capture a packet trace
when this failure mode occurs. Our target is the Red Bear 2 module (based on
nRF52). We're going to try and test with the "bleprph" example to see if the
issue can be reproduced on it as well, also with the top of master (our app is
currently based on MyNewt 1.2).
> BLE Controller - incompatibility with iOS 11
>
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet
> #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYNEWT-857) BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295986#comment-16295986
]
Lance Cohen commented on MYNEWT-857:
Hi Chris,
1. Models tested so far are iPhone 7 and X. We have some older versions (5 & 6)
which we will try to repro the issue on as well.
2. From our experience, the issue seems to be more related to iOS 11 rather
than phone hardware as prior to iOS11 ous phone-device interactions did not
trigger this issue. There are known high profile issues with iOS 11 (eg: the
likes of Garmin having problems - with phones losing connections etc) the
question is what could trigger the issue/state where the phone's BT stack goes
wacky. Apple should really address this but hopefully we can get to the bottom
of what triggers this state.
3. Unfortunately not, behavior is the same.
4. As mentioned we will try to isolate things and have a similar test setup to
yours testing with nRF52 and the running bleprph. I will provide an update on
this testing when I have one.
> BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
> --
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet
> #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MYNEWT-857) BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295986#comment-16295986
]
Lance Cohen edited comment on MYNEWT-857 at 12/19/17 1:21 AM:
--
Hi Chris,
1. Models tested so far are iPhone 7 and X. We have some older versions (5 & 6)
which we will try to repro the issue on as well.
2. From our experience, the issue seems to be more related to iOS 11 rather
than phone hardware as prior to iOS11 our phone-device interactions did not
trigger this issue. There are known high profile issues with iOS 11 (eg: the
likes of Garmin having problems - with phones losing connections etc) the
question is what could trigger the issue/state where the phone's BT stack goes
wacky. Apple should really address this but hopefully we can get to the bottom
of what triggers this state.
3. Unfortunately not, behavior is the same.
4. As mentioned we will try to isolate things and have a similar test setup to
yours testing with nRF52 and the running bleprph. I will provide an update on
this testing when I have one.
was (Author: lance_proxy):
Hi Chris,
1. Models tested so far are iPhone 7 and X. We have some older versions (5 & 6)
which we will try to repro the issue on as well.
2. From our experience, the issue seems to be more related to iOS 11 rather
than phone hardware as prior to iOS11 ous phone-device interactions did not
trigger this issue. There are known high profile issues with iOS 11 (eg: the
likes of Garmin having problems - with phones losing connections etc) the
question is what could trigger the issue/state where the phone's BT stack goes
wacky. Apple should really address this but hopefully we can get to the bottom
of what triggers this state.
3. Unfortunately not, behavior is the same.
4. As mentioned we will try to isolate things and have a similar test setup to
yours testing with nRF52 and the running bleprph. I will provide an update on
this testing when I have one.
> BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
> --
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet
> #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYNEWT-857) BLE Controller - incompatibility with iOS 11
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16293875#comment-16293875
]
Lance Cohen commented on MYNEWT-857:
Hi guys, just wanted to report that we've tested the proposed fix for this
issue (removing the call to `ble_ll_ctrl_proc_start()` in
`ble_ll_conn_created()`) and our iOS dev is still seeing intermitting cases
(that are hard to reproduce) where the iOS 11 is "totally stuck" and can never
connect to the device again, unless BT is toggled on the phone. He's tested
with iPhone 7 and iPhone X. Are there any further updates / proposed fixes to
this that we can try and test?
> BLE Controller - incompatibility with iOS 11
>
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached) shows that the iPhone never initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file, the CONNECT_REQ is at packet #6211.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYNEWT-857) BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
[
https://issues.apache.org/jira/browse/MYNEWT-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422915#comment-16422915
]
Lance Cohen commented on MYNEWT-857:
Hi [~jerobi], sounds like your experience with the iPhone X is fairly binary
w.r.t commenting out that line that Chris suggested. Our experience is
unfortunately not super easy to replicate its very intermittent / random. One
thing we did notice while trying to capture the packet sequence leading up to
and upon entering the BT "hang" state is there are *no* BT packets that are
transmitted from the iPhone - so its seems like the stack in this state is
permanently wedged until BT is restarted as you mentioned. Unfortunately,
capturing the sequence leading up to the hang has proven to be elusive.
> BLE Controller - incompatibility with iPhone 8 (and iPhone X?)
> --
>
> Key: MYNEWT-857
> URL: https://issues.apache.org/jira/browse/MYNEWT-857
> Project: Mynewt
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: Nimble
>Reporter: Christopher Collins
>Priority: Major
> Labels: NimBLE
> Fix For: v1.3
>
> Attachments: ios2nimble-no-feat.pcap, ios2nimble.pcap,
> nimble_ios_1033.btt, nimble_ios_1103.btt
>
>
> Master: iPhone running iOS 11
> Slave: NimBLE device
> The iPhone successfully establishes a connection to the NimBLE device, but
> the CoreBluetooth {{didConnect()}} callback does not get called. A packet
> trace (see attached {{ios2nimble.pcap}} file) shows that the iPhone never
> initiates service discovery.
> The problem seems to occur when the NimBLE controller initiates the Feature
> Exchange Procedure immediately after connection establishment. The
> {{LL_SLAVE_FEATURE_REQ}} PDU appears to cause a problem for the iOS device.
> When I comment out the call to {{ble_ll_ctrl_proc_start()}} at the bottom of
> {{ble_ll_conn_created()}}, the iOS device is able to connect and perform
> service discovery, resulting in the CoreBluetooth callback being executed.
> In the attached pcap file {{ios2nimble.pcap}}, the CONNECT_REQ is at packet
> #6211.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
