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

[John Crispin]

Hi,

still pending not had time to look into this. it'll take me a moment as
i am not familiar with the code so i need to find a free moment to
properly review this, sorry for the delay

John

On 16/12/2016 08:51, Nikolay Ledovskikh wrote:
> 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 :
>> Matti Laakso  writes:
>>> On 12.12.2016 08:52, Petr Štetiar wrote:
 Matti Laakso  [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
> 
> 
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Nikolay Ledovskikh]

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 :
> Matti Laakso  writes:
>> On 12.12.2016 08:52, Petr Štetiar wrote:
>>> Matti Laakso  [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

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

[Bjørn Mork]

Matti Laakso  writes:
> On 12.12.2016 08:52, Petr Štetiar wrote:
>> Matti Laakso  [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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Matti Laakso]

On 12.12.2016 08:52, Petr Štetiar wrote:

Matti Laakso  [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?


Matti

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Petr Štetiar]

Matti Laakso  [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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Nikolay Ledovskikh]

OK. It seems I missed something when doing cleanup.
Your patch is 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 Suqmi -s -d /dev/cdc-wdm0 --set-client-id wds
2 --stop-network 0x --autoconnect
4980 root  1000 Suqmi -s -d /dev/cdc-wdm0 --get-pin-status
5020 root  1000 Suqmi -s -d /dev/cdc-wdm1 --set-client-id wds
2 --stop-network 0x --autoconnect
5090 root   992 Suqmi -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.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Nikolay Ledovskikh]

> Are all modems the same? Do they have same firmware versions? Are you sure
> that the mapping of different /dev/cdc-wdmX nodes always stay the same? It
> could be that on some boot the modem with the Megafon SIM gets /dev/cdc-wdm0
> and on the second boot it gets /dev/cdc-wdm1 or some other number. Using
> autoconnect may ignore the APN, and the modems seem to work correctly. If
> you remove the APN options, does it work then?
Yes, all the same hw and fw. And mapping is not changing.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Matti Laakso]

Hi Nikolay,

On 09.12.2016 11:57, Nikolay Ledovskikh wrote:

I'm using multiple modems

config interface 'wan1'
 option proto 'qmi'
 option device '/dev/cdc-wdm0'
 option apn 'internet.megafon.ru'
 option ipv6 '0'
 option metric '1'

config interface 'wan2'
 option proto 'qmi'
 option device '/dev/cdc-wdm1'
 option apn 'internet.beeline.ru'
 option ipv6 '0'
 option metric '2'

And 2 more modems


Are all modems the same? Do they have same firmware versions? Are you 
sure that the mapping of different /dev/cdc-wdmX nodes always stay the 
same? It could be that on some boot the modem with the Megafon SIM gets 
/dev/cdc-wdm0 and on the second boot it gets /dev/cdc-wdm1 or some other 
number. Using autoconnect may ignore the APN, and the modems seem to 
work correctly. If you remove the APN options, does it work then?




And with your patch logread shows endlessly:
Fri Dec  9 09:38:15 2016 daemon.notice netifd: wan3 (18612): Command
failed: Permission denied
Fri Dec  9 09:38:15 2016 daemon.notice netifd: Interface 'wan3' is now down
Fri Dec  9 09:38:15 2016 daemon.notice netifd: Interface 'wan3' is
setting up now
Fri Dec  9 09:38:15 2016 daemon.notice netifd: wan4 (18611): Waiting
for network registration
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan4 (18611): Starting
network wan4
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan3 (18625): Waiting
for network registration
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan4 (18611): Unable to
connect IPv4
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan3 (18625): Starting
network wan3
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan4 (18655): Stopping
network wan4
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan4 (18655): Command
failed: Permission denied


Just a note, the "Command failed: Permission denied" error is unrelated.

Matti



About cgdcont:
1'st modem:
at+cgdcont?
+CGDCONT: 1,"IP","internet.megafon.ru","0.0.0.0",0,0
+CGDCONT: 3,"IP","internet.megafon.ru","0.0.0.0",0,0

2'nd modem:
at+cgdcont?
+CGDCONT: 1,"IP","internet.beeline.ru","0.0.0.0",0,0
+CGDCONT: 3,"IP","internet.beeline.ru","0.0.0.0",0,0

And 2 more modems

Only one (wan2) gets up and connected to network. What I'm doing wrong

2016-12-09 12:35 GMT+03:00 Matti Laakso :

On 09.12.2016 11:27, Petr Štetiar wrote:

Matti Laakso  [2016-12-09 10:23:24]:


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.

Thanks for the additional hints. Details about my modem:

   ATI
   Quectel
   EC20
   Revision: EC20EQAR02A05E2G

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?

Matti



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

Great, I've missed this patch. Going to take a look at it.

-- ynezz








___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Nikolay Ledovskikh]

We are using sierra MC7710, MC7304.

2016-12-09 14:41 GMT+03:00 Nikolay Ledovskikh :
>> I agree fully. That's why I added the autoconnect option in my last patch
>> and defaulted it to disabled.
>>
>> Matti
>
> So, what we get: uqmi exit with 'Call failed'.
>
> --
> Best regards, Nikolay Ledovskikh.



-- 
Best regards, Nikolay Ledovskikh.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Nikolay Ledovskikh]

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

So, what we get: uqmi exit with 'Call failed'.

-- 
Best regards, Nikolay Ledovskikh.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Nikolay Ledovskikh]

I'm using multiple modems

config interface 'wan1'
option proto 'qmi'
option device '/dev/cdc-wdm0'
option apn 'internet.megafon.ru'
option ipv6 '0'
option metric '1'

config interface 'wan2'
option proto 'qmi'
option device '/dev/cdc-wdm1'
option apn 'internet.beeline.ru'
option ipv6 '0'
option metric '2'

And 2 more modems

And with your patch logread shows endlessly:
Fri Dec  9 09:38:15 2016 daemon.notice netifd: wan3 (18612): Command
failed: Permission denied
Fri Dec  9 09:38:15 2016 daemon.notice netifd: Interface 'wan3' is now down
Fri Dec  9 09:38:15 2016 daemon.notice netifd: Interface 'wan3' is
setting up now
Fri Dec  9 09:38:15 2016 daemon.notice netifd: wan4 (18611): Waiting
for network registration
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan4 (18611): Starting
network wan4
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan3 (18625): Waiting
for network registration
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan4 (18611): Unable to
connect IPv4
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan3 (18625): Starting
network wan3
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan4 (18655): Stopping
network wan4
Fri Dec  9 09:38:16 2016 daemon.notice netifd: wan4 (18655): Command
failed: Permission denied


About cgdcont:
1'st modem:
at+cgdcont?
+CGDCONT: 1,"IP","internet.megafon.ru","0.0.0.0",0,0
+CGDCONT: 3,"IP","internet.megafon.ru","0.0.0.0",0,0

2'nd modem:
at+cgdcont?
+CGDCONT: 1,"IP","internet.beeline.ru","0.0.0.0",0,0
+CGDCONT: 3,"IP","internet.beeline.ru","0.0.0.0",0,0

And 2 more modems

Only one (wan2) gets up and connected to network. What I'm doing wrong?

2016-12-09 12:35 GMT+03:00 Matti Laakso :
> On 09.12.2016 11:27, Petr Štetiar wrote:
>>
>> Matti Laakso  [2016-12-09 10:23:24]:
>>
>>> 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.
>>
>> Thanks for the additional hints. Details about my modem:
>>
>>   ATI
>>   Quectel
>>   EC20
>>   Revision: EC20EQAR02A05E2G
>>
>> 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?
>
> Matti
>
>
>>
>>> I agree fully. That's why I added the autoconnect option in my last
>>> patch and defaulted it to disabled.
>>
>> Great, I've missed this patch. Going to take a look at it.
>>
>> -- ynezz
>
>



-- 
Best regards, Nikolay Ledovskikh.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Matti Laakso]

On 09.12.2016 11:27, Petr Štetiar wrote:

Matti Laakso  [2016-12-09 10:23:24]:


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.

Thanks for the additional hints. Details about my modem:

  ATI
  Quectel
  EC20
  Revision: EC20EQAR02A05E2G

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?


Matti




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

Great, I've missed this patch. Going to take a look at it.

-- ynezz



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Petr Štetiar]

Matti Laakso  [2016-12-09 10:23:24]:

> 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.

Thanks for the additional hints. Details about my modem:

 ATI
 Quectel
 EC20
 Revision: EC20EQAR02A05E2G

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

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

Great, I've missed this patch. Going to take a look at it.

-- ynezz

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [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  writes:


Matti Laakso  [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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Petr Štetiar]

Bjørn Mork  [2016-12-08 16:11:18]:

Hi,

> 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?

Yep, good points, thanks.

> 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.

True.

-- ynezz

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Bjørn Mork]

Petr Štetiar  writes:

> Matti Laakso  [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? :-)

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

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Nikolay Ledovskikh]

> This autoconnect feature should burn in hell :-) The funny thing about this
> feature is, that the behaviour is network specific[1] also.

Maybe. I'm not too familiar with qmi proto. I just catched this
behaviour in our test
environment and found pdf that says:
"Gobi3000 devices, though, have the ability to reset and release all
Client IDs via a CTL Sync command"
And it works perfectly.

-- 
Best regards, Nikolay Ledovskikh.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Petr Štetiar]

Matti Laakso  [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? :-)

1. http://lists.infradead.org/pipermail/lede-dev/2016-October/003653.html

-- ynezz

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Nikolay Ledovskikh]

No. All this is not working if cid is not released for some reason.
For example: we have multiple modems with external power source, if usb DATA
cable connection is broken for some reason, the cid will not be released and new
network connection will not be established until you release the cid manually.

2016-12-08 16:39 GMT+03:00 Matti Laakso :
>> 
>> Add uqmi 'sync' command call to release stalled cid when preparing to
>> setup new connection. As a result it prevents 'POLICY MISMATCH' errors.
>>
>> Signed-off-by: Nickolay Ledovskikh > >
>> ---
>>  package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
>> b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
>> index fb4c339..3b24539 100755
>> --- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
>> +++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
>> @@ -85,6 +85,7 @@ proto_qmi_setup() {
>>
>>   # try to clear previous autoconnect state
>>   # do not reuse previous wds client id to prevent hangs caused by stale 
>> data
>> + uqmi -s -d "$device" --sync
>>   uqmi -s -d "$device" \
>>   --stop-network 0x \
>>   --autoconnect > /dev/null
>> --
>> 2.7.3
>>
>>
>
> I think my latest patch,
> http://lists.infradead.org/pipermail/lede-dev/2016-December/004433.html
> , should also fix this, since this is typically caused by IPv6
> autoconnect being enabled and trying to disable it with IPv4 client or
> vice versa. My patch adds separate commands for IPv4 and IPv6. That
> said, I don't like the autoconnect at all, it being so unpredictable
> across various models.
>
> Matti



-- 
Best regards, Nikolay Ledovskikh.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

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

[Matti Laakso]

> 
> Add uqmi 'sync' command call to release stalled cid when preparing to
> setup new connection. As a result it prevents 'POLICY MISMATCH' errors.
>
> Signed-off-by: Nickolay Ledovskikh  >
> ---
>  package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh 
> b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> index fb4c339..3b24539 100755
> --- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> +++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
> @@ -85,6 +85,7 @@ proto_qmi_setup() {
>  
>   # try to clear previous autoconnect state
>   # do not reuse previous wds client id to prevent hangs caused by stale 
> data
> + uqmi -s -d "$device" --sync
>   uqmi -s -d "$device" \
>   --stop-network 0x \
>   --autoconnect > /dev/null
> -- 
> 2.7.3
>
>

I think my latest patch,
http://lists.infradead.org/pipermail/lede-dev/2016-December/004433.html
, should also fix this, since this is typically caused by IPv6
autoconnect being enabled and trying to disable it with IPv4 client or
vice versa. My patch adds separate commands for IPv4 and IPv6. That
said, I don't like the autoconnect at all, it being so unpredictable
across various models.

Matti

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev