The message looks fine to me, but where did you get the DMS client ID from if this is the first message you send?
A client ID is required for all QMI subsystems except CTL. This has to be allocated using a CTL “Allocate CID” request. You seem to be using DMS client ID #1 without having allocated it. The normal response to that will be complete silence.
For a simple start testing basic QMI transport, I’d recommend using the CTL “Get Version Info” request. This should always work for all QMI devices.
Yes, that is normal and indicates that the transfer is indeed working. The message is a CTL “Sync” indication, which QMI devices seem to send when booting. The exact meaning is unknown to me as the docs are not public, but I’m guessing that it’s just informing the host about the device reboot. Saying somthing like “all state has been reset”.
Sending a CTL “Sync” request to the device will have pretty much the same effect: It resets all state.
Actually, can you tell me what documents tell about CTL service, so I can ask Sierra’s liaison for the document? I went though all the documents I have received, and I can find the details of different types of services but of CTL.
The CTL support is the main difference between the GobiNet driver which Sierra documents and the qmi_wwan driver. The GobiNet driver handles all the necessary CTL in the driver, so the SDK does not have to care. The driver provides a pair of ioctls for allocating and releasing CIDs, but it does not provide any generic access to the CTL subsystem. So there is no need for Sierra to provide any documentation for it. But they are probably documenting some way to call the ioctls? Or maybe that’s implicit when you access a new subsystem?
Qualcomm has documented the CTL system of course. Their document number is 80-VB816-3, titled “QMI Control Service (QMI_CTL)”. But that’s all I know about that. My request for a copy was politely denied
So for now, all the CTL documentation we have is what we can scrape from the GobiNet driver and the CodeAurora project. You can find some docs, in the form of headers and code, inside the open source GobiAPI: codeaurora.org/patches/quic … 347.tar.gz
But I guess that one of the first things you should decide for a new FreeBSD driver is whether to make the userspace API compatible to GobiNet or qmi_wwan. Or both? Or something completely different?