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

Nikolay Ledovskikh nledovskikh at gmail.com
Thu Dec 15 23:51:46 PST 2016


So. What about patch? 'sync' call allows us not to save cids in interface state.
And every time interface is up, it will be prepared correctly.

2016-12-12 12:28 GMT+03:00 Bjørn Mork <bjorn at mork.no>:
> 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



-- 
Best regards, Nikolay Ledovskikh.



More information about the Lede-dev mailing list