This behavior does not seem to me very robust: it would be interesting to know why Windows 7 connection manager uses this strategy, but I was not able to find any documentation from Microsoft about that.

Immediately after the failing command, the modem sent an unsolicited notification, reporting to be attached to the packet network (due to the auto-attach), but the connection manager was not able to properly consider this notification to start the connection operation.

The connection manager did not retry to send the failing request again.

In the failing occasions, this request was failing. Why? Debugging MBIM modem…Īnalyzing deeper the working scenario, before sending the MBIM_CID_CONNECT, if the modem was not attached to the data packet service, Windows 7 connection manager sent the MBIM request MBIM_CID_PACKET_SERVICE SET with Action Attach, and the modem response was success. Going back to my issue, analyzing decoded MBIM packets I found that in the occasions in which the modem was not able to connect, the host (Windows 7) did not even try to setup a data connection. Having the MBIM specification at your fingertips, those tools can be used to shed some light over an unwanted and obscure modem behavior. With the help of usbpcap, an open source USB sniffer for Windows, it is possible to collect and decode MBIM packets.

Wireshark, a project started in the 1998, is a well known and appreciated network protocol analyzer. Since firmware modem traces could not be collected, I asked to collect usbcap logs during the issue, in order to leverage Wireshark capabilities for debugging MBIM modem issues.

Recently I was asked to explain why an MBIM based modem connected to a Windows 7 host was sometimes not able to setup a data connection after a Suspend (S3) / Resume transition.

Wireshark usb