This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Connections to Moto E4 fail with 0x3d Connection Terminated Due To MIC Failure

I'm working on porting our connectivity application from SDK11/SD132v2.0.0 to SDK14/SD132v5.0.0.

Currently, though most Android phones I've tried can connect, the Moto E4 exhibits strange behavior on only the SDK14 version, where it will connect and then very shortly thereafter (before a GATT message can be sent, and sometimes before the LL feature handshake is completed) disconnect with HCI error 0x3d, connection terminated due to MIC failure. This software is not designed to use security on the link layer at all so I'm confused about how this would occur.

I've attached a pcap of a successful connection on SDK11/SD132v2.0.0 and a typical failed connection on SDK14/SD132v5.0.0.

My only working hypothesis is the phone behaving differently due to different advertised capabilities from the new softdevice. So I have two questions:

  1. In general, has anybody seen this before or know why it's happening?
  2. For further debugging, is there a way I can alter the LL feature flags the device advertises?

SDK11-SD132v2-0-0.pcapng

SDK14-SD132v5-0-0.pcapng

Parents
  • I ended up fixing this in a fairly unexpected way.

    The fix ended up being delay connection parameter negotiation until after attribute discovery by setting the connection parameter module's start_on_notify_cccd_handle to a handle that is always set to notify after connection.

    I still don't know for sure why starting conn param negotiation immediately after a connection was established broke things on the moto e4, but I suspect its LE controller really wanted to go through its feature discovery and enumeration sequence unbothered. Either way, the problem is solved.

Reply
  • I ended up fixing this in a fairly unexpected way.

    The fix ended up being delay connection parameter negotiation until after attribute discovery by setting the connection parameter module's start_on_notify_cccd_handle to a handle that is always set to notify after connection.

    I still don't know for sure why starting conn param negotiation immediately after a connection was established broke things on the moto e4, but I suspect its LE controller really wanted to go through its feature discovery and enumeration sequence unbothered. Either way, the problem is solved.

Children
No Data
Related