On Tue, Oct 4, 2016 at 10:48 PM, Dan Williams wrote:
> (ttyUSB2): --> 'AT^SYSCFG?'
> (ttyUSB2): <--
> '^SYSCFG:14,2,400380,1,2OK'
> couldn't load current allowed/preferred modes: 'No SYSCFG combination
> found matching the current one (14,2)'
>
> 14,2 means "WCDMA-only; acquire WCDMA then GS
(ttyUSB2): --> 'AT^SYSCFG?'
(ttyUSB2): <--
'^SYSCFG:14,2,400380,1,2OK'
couldn't load current allowed/preferred modes: 'No SYSCFG combination
found matching the current one (14,2)'
14,2 means "WCDMA-only; acquire WCDMA then GSM" which is somewhat
non-sensical. The supported modes parsing does
On Thu, Sep 29, 2016 at 3:38 PM, Aleksander Morgado
wrote:
> [PATCH 1/5] core: allow identifying devices by a user-provided 'uid'
> [PATCH 2/5] core: new kernel device object instead of an explicit...
> [PATCH 3/5] core: allow disabling auto-scan and notifying ports one...
> [PATCH 4/5] core: use
Carlo Lobrano writes:
> Hi everybody,
>
> I tried the steps Bjørn suggested and it worked, even if I'm not sure about
> some points.
>
> Firstly, I can get the address of api.ipify only if the eth (or another
> connection) is still up, not sure if this is expected or you got that IP
> from one of
Hi everybody,
I tried the steps Bjørn suggested and it worked, even if I'm not sure about
some points.
Firstly, I can get the address of api.ipify only if the eth (or another
connection) is still up, not sure if this is expected or you got that IP
from one of the mbim connections.
Secondly, and
