libqmi-glib

[Bjørn Mork]

Aleksander Morgado <aleksander at lanedo.com> writes:

> Hey hey,
>
>> 
>>> Anyway, today I noticed more features added.  Unfortunately one of them
>>> is not going to work: You allow the client to exit after starting a
>>> connection, releasing the WDS client ID.  That's not supported.  You
>>> have to keep the client ID while the connection is up. Once the client
>>> ID is released, the connection goes down.
>> 
>> And then I noticed the --client-no-release-cid option.  I'm more than a
>> bit slow.
>> 
>
> Yes, that's the option to avoid releasing the CID when qmicli exits;
> then you can use --client-cid=X to recover it the next time you call qmicli.

Yes, I noticed.

>> That will make it work. Probably best to bundle it with --wds-start-network, 
>> but then again I guess this is a test utility for people supposed to
>> know what they're doing.
>> 
>
> If you run --wds-start-network WITH --wds-follow-network; the program
> will keep running with the connection open until you do Ctrl+C. In that
> way, you don't need to play with --client-no-release-cid, --client-cid
> and --wds-stop-network, as that is done for you automatically.

Yes, that's how I have been using it until now.  Works really well, and
you get the indications as well.  And I found the poll error in the
driver because the file was open when my laptop was suspended ;-)

> If you still want the qmicli to exit, while keeping the CID unreleased
> and all that, try to use the new `qmi-network' script, where you can just:
>   $> qmi-network /dev/cdc-wdm0 start
>   $> qmi-network /dev/cdc-wdm0 status
>   $> qmi-network /dev/cdc-wdm0 stop
>
> That  will keep the packet data handle and CID in a state file under
> /tmp; quite similar to what you did in your script. Note that that
> script is still quite untested, I wrote it last Friday.

Will try.

Note that I don't necessarily believe what I did necessarily is a good
solution.  I was concerned with integrating the script into my local
Debian networking config, and saving the state like that was a quick and
dirty way to achieve that.  I don't think it fits most users
requirements.

But having something like this for testing is certainly useful.

> One last thing; if you ever get the 'exhausted client IDs' error, you
> can just run qmicli with --device-open-sync, which will run the SYNC
> request as a step while opening the QmiDevice.

Yes, I know.

BTW, there was a request for a quick way to detect QMI devices on
linux-usb today, and I revisited the idea about a libusb based method.
I took a quick look at qmi-device.{c,h} with the intent to try to make
something, but found that it would take me more time than I had, given
my severely limited knowledge of C and glib... So I coded another quick
and dirty hack instead.  In perl.  Attaching it, as it still may be
useful to someone here too.

A libusb based device type for libqmi-glib would be a much nicer
solution, though.  But something like that will never be anything but a
test utility (since there won't be any network device) so I guess there
isn't much point in putting a lot of work into it.  The perl script may
suffice. 


Bjørn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: qmiver.pl
Type: text/x-perl
Size: 6047 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20120513/35b440b4/attachment.pl>