Hey,
>
> As previously discussed, the disconnection code currently does no
> checking to verify that the modem has come back into command mode (it
> just drops DTR for a second, and hopes for the best) i.e.
>
> [Drop DTR]
> [end disconnect sequence, assuming modem is back in command mode]
>
>
>
>
Hi,
I have a HP Laptop with a HP branded UMTS modem HS3110 with ID
03f0:521d. I've seen the people in the CC list in two discussions
about linux support for this modem.
I have this modem working in MBIM/NCM mode with a modified umb(4) driver
in OpenBSD (at least it pings) and I'd like share my
On 07/08/17 23:05, Ben Chan wrote:
> This patch removes an unnecessary error check in the
> update_unlock_retries() where the error is never set.
Pushed to git master, mm-1-6, mm-1-4 and mm-1-2, thanks!
> ---
> src/mm-iface-modem.c | 18 ++
> 1 file changed, 6 insertions(+), 12 d
Hey,
On Tue, Aug 8, 2017 at 1:06 AM, Ben Chan wrote:
> This branch contains a series of patches to address the following
> issue observed on MBIM modems:
>
> After MMSimMbim performs a MBIM_CID_PIN set operation, it calls
> mm_iface_modem_update_lock_info() (through its base class MMBaseSim)
> to
On Mon, Aug 7, 2017 at 2:26 PM, Daniele Palmas wrote:
> 2017-08-07 11:04 GMT+02:00 Aleksander Morgado :
> >>>
> >>> As far as I know this happens only for Verizon customization that uses
> >>> SMS over IMS with 3GPP2 pdu.
> >>>
> Isn't this actually a bit weird, given that
> the LE866-SV
On Tue, Aug 8, 2017 at 4:10 PM, José wrote:
> On Mon, Aug 7, 2017 at 2:26 PM, Daniele Palmas wrote:
>> 2017-08-07 11:04 GMT+02:00 Aleksander Morgado :
>> >>>
>> >>> As far as I know this happens only for Verizon customization that uses
>> >>> SMS over IMS with 3GPP2 pdu.
>> >>>
>> Isn't this
On Tue, Aug 8, 2017 at 4:40 PM, Aleksander Morgado
wrote:
> Not really, no. LTE is 3GPP, so the LE866-SV is 3GPP, regardless of
> operator, we cannot change that or it wouldn't work in MM. What we
> need is a way to "switch to 3GPP2 SMS messaging" in 3GPP-only modems,
> either automagically (maybe
On Tue, Aug 8, 2017 at 12:43 AM, Aleksander Morgado
wrote:
> Hey,
>
> It really is unfortunate that the MBIM_CID_PIN query only reports the
> information of the "currently applicable" PIN type, although the truth
> is that that's the only useful one.
Yes, indeed. It would have been much better if
Hey,
>> It really is unfortunate that the MBIM_CID_PIN query only reports the
>> information of the "currently applicable" PIN type, although the truth
>> is that that's the only useful one.
>
> Yes, indeed. It would have been much better if MBIM_CID_PIN query
> could take a PIN type as argument.
On Tue, Aug 8, 2017 at 11:15 AM, Aleksander Morgado
wrote:
> Hey,
>
>>> It really is unfortunate that the MBIM_CID_PIN query only reports the
>>> information of the "currently applicable" PIN type, although the truth
>>> is that that's the only useful one.
>>
>> Yes, indeed. It would have been muc
It really is unfortunate that the MBIM_CID_PIN query only reports the
information of the "currently applicable" PIN type, although the truth
is that that's the only useful one.
>>>
>>> Yes, indeed. It would have been much better if MBIM_CID_PIN query
>>> could take a PIN type as argu
11 matches
Mail list logo
