[LEDE-DEV] [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.

[Matti Laakso]

On 08.12.2016 17:11, Bjørn Mork wrote:
> Petr Štetiar <ynezz at true.cz> writes:
>
>> Matti Laakso <malaakso at elisanet.fi> [2016-12-08 15:39:57]:
>>
>> Hi,
>>
>>> I don't like the autoconnect at all, it being so unpredictable across
>>> various models.
>> This autoconnect feature should burn in hell :-) The funny thing about this
>> feature is, that the behaviour is network specific[1] also.
>>
>> I still can't find some time to dig more into this, like read the QMI docs
>> etc., but I'm still wondering how this could be possible. Maybe this
>> autoconnect setting is somehow transfered towards to the other end in network
>> operator's infrastructure?
>>
>> Bjørn, any idea? :-)

I don't think that the autoconnect setting is "transferred" to the 
network, rather it could be tied to a specific call profile index, which 
has the wrong APN. If your Slovakian SIM card has several predefined 
profiles, this could be the case. If your modem exposes a virtual serial 
port which accepts AT-commands, you could use AT+CGDCONT? to check.

> Closed source firmware does all sort of weird and unexpected stuff.
> That's why we use OpenWrt/LEDE on the routers, after all :)
>
> I don't think we can trust the modem firmware with complex features like
> autoconnect. There are too many things that can go wrong.  And we don't
> have any way to debug or fix any of those issues when they.happen inside
> the modem firmware "black box".  How do you tell the difference between
> autoconnect failed due to wrong APN from autoconnect failed due to low
> signal, for example?
>
> IMHO, we should depend on as few as possible of the most basic modem
> firmware features.  Any complex features like autoconnect can and should
> be implemented as services running on the host, using those basic
> features as building blocks.
>
>
> Bjørn

I agree fully. That's why I added the autoconnect option in my last 
patch and defaulted it to disabled.

Matti