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

[Bjørn Mork]

Matti Laakso <malaakso at elisanet.fi> writes:
> On 12.12.2016 08:52, Petr Štetiar wrote:
>> Matti Laakso <malaakso at elisanet.fi> [2016-12-09 11:35:35]:
>>
>>> On 09.12.2016 11:27, Petr Štetiar wrote:
>>>> I knew, that there's only one profile defined, operator has deleted all other
>>>> profiles, there's currently only one APN defined.
>>>>
>>>>    AT+CGDCONT?
>>>>    +CGDCONT: 1,"IPV4V6","","0.0.0.0",0,0
>>> Well, there's no APN defined (it's an empty string), and who knows,
>>> maybe the modem ignores the APN provided via QMI when enabling
>>> autoconnect... Does your working Czech SIM card have a valid APN string?
>> It's getting quite strange as my Czech SIM gives me the same reply:
>>
>>    +CGDCONT: 1,"IPV4V6","","0.0.0.0",0,0
>>
>> -- ynezz
>
> Just shooting in the dark here, but maybe this operator accepts empty
> APN and somehow maps it to the correct one?

Some operators do, and some don't.  Which is why the empty APN string
*may* work.  It's generally not a good idea to depend on it, though.
The APN string often selects a specific service, with specific
bandwidth, QoS, firewall rules etc.  So even in cases where the empty
string "works", the result might be suboptimal.

In any case: Testing with empty or random APN strings will give
inconsistent results.  It can for example be the reason why
autoconnect fails, while a manual connection with an explicit APN
works. Or why autoconnect works with one operator but not with another.

For some background and better understanding of how the APN mapping in
an operator network is done, it might be useful to look at the config
examples for typical PGW/GGSNs (this is for StarOS, which is now owned
by Cisco):
http://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/20/MME/b_20_MME_Admin/b_20_MME_Admin_chapter_0101.pdf



Bjørn