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 <bj...@mork.no>: > Matti Laakso <malaa...@elisanet.fi> writes: >> On 12.12.2016 08:52, Petr Štetiar wrote: >>> Matti Laakso <malaa...@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. _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
