[LEDE-DEV] [PATCH] uqmi: Add support for specifying profile index

[Matti Laakso]

On 12/09/2016 04:35 PM, Nikolay Ledovskikh wrote:
> Tested your patch. It's working, but only after startup.
>
> When you disconnect modem from usb we have old cids saved.
> Then we connect modems back, modems won't bring up automatically
> (and I suppose they souldn't). And when we try to bring interface up we are
> falling into situation with locked up uqmi:
> 4912 root      1000 S    uqmi -s -d /dev/cdc-wdm0 --set-client-id wds
> 2 --stop-network 0xffffffff --autoconnect
> 4980 root      1000 S    uqmi -s -d /dev/cdc-wdm0 --get-pin-status
> 5020 root      1000 S    uqmi -s -d /dev/cdc-wdm1 --set-client-id wds
> 2 --stop-network 0xffffffff --autoconnect
> 5090 root       992 S    uqmi -s -d /dev/cdc-wdm1 --get-pin-status
> If we now kill all this uqmi processes, we then bring interfaces up :(
> Maybe it's all because of saved cids?
>
> Other case, when only modem's usb data lines are disconnected, without
> loosing power. This case we don't have locked up uqmi and manual 'ifup $iface'
> works. Saved cids released successfully.

Indeed, if one disconnects power from the modem, the interface somehow
stays up and the cid's stay in memory. Then when one tries to stop the
network with an unallocated cid after the modem again has power, uqmi
hangs. I think disconnecting the modem should tear down the interface as
well, but I'm not sure how to achieve that.

>
> 2016-12-09 15:02 GMT+03:00 Felix Fietkau <nbd at nbd.name>:
>> On 2016-12-03 23:05, Matti Laakso wrote:
>>> Update uqmi to latest version, which brings about support for
>>> specifying a call profile index instead of APN. A specific index
>>> different from 1 must be used for some service provider and modem
>>> combinations.
>>>
>>> Also make autoconnect optional and default it to off due to it not
>>> working with statically configured IPv6.
>>>
>>> Signed-off-by: Matti Laakso <malaakso at elisanet.fi>
>> I think autoconnect should default to on for IPv4, as long as we don't
>> have anything running on the host to replace it.
>>
>> If the autoconnect does not work with the device for some reason, you at
>> least notice it immediately (and realize you have to do some monitoring
>> of the connection).
>>
>> If autoconnect defaults to off and the device will simply stay
>> disconnected on the first network outage, that's a pretty bad default,
>> especially in cases where the device could just reconnect on its own.
>>
>> - Felix
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>