[PATCH] Infineon: Add support for Infineon / Intel modems

[Paul Bartell]

Hey Aleksander,

On Fri, Jun 2, 2017 at 3:58 AM, Aleksander Morgado
<aleksander at aleksander.es> wrote:
> Hey Paul,
>
>>
>> I spent a little more time debugging the HL7588 today. This modem
>> seems to designed for phone-type SIM cards that have a context for MMS
>> in the PDP context #1 slot (my combination of SIM card and network has
>> the internet APN in this slot). It seems to lock configuration of this
>> PDP context unless I run +HBHV=3,1 (pdp_unlock_mode) and detach from
>> the network. Setting different +CGAUTO modes does not appear to affect
>> the outcome.
>>
>
> +CGAUTO configures settings for nw-initiated operations; not sure if
> it applies here.
>
>> Regardless, once the modem is attached to a network, I am not able to
>> deactivate the PDP context without the modem detaching and reattaching
>> itself to the network (see the attached log mm_hl7588_cgdeact.log
>> ).This causes ModemManager to cancel any ongoing connection attempts.
>>
>
> I would say that this is because the context that is flagged as active
> is the default LTE bearer and requesting to detach from it triggers
> network unregistration as well, something like that.
>
>> Sometimes a connection attempt succeeds without first detaching from
>> the network (I tried a build without the DIAL_3GPP_CONTEXT_STEP_DETACH
>> step), but often this is accompanied with no DNS addresses. The modem
>> returns +XDNS: 1, "0.0.0.0", "0.0.0.0". Querying the modem again after
>> 30-60 seconds again returns no DNS servers. When this occurs,
>> sometimes traffic will pass when I bring up the NCM interface, other
>> times it will simply not pass any traffic.
>>
>
> This is weird indeed. Although, if we're looking at the default EPS
> bearer connection, it may make sense that no DNS is really required at
> that point.

Ah. That was the missing piece of the puzzle. I removed the
XDNS_DISABLE step from the disconnect steps and everything seems to
work properly now. The modem appears to save the last XDNS request
(+XDNS=0,1) for each CID across activations and reboots. So for the
default bearer case, the XDNS setting will take effect upon
deactivation or detachment from the network or a module reboot.

>
>> As a better workaround, I made a build which does the following: (log
>> is mm_hl7588_cgact_cgatt.log).
>> 1. Disables +CGREG message handlers
>> 2. Sends a +CGACT=0,1 to "deactivate" the context instead of detaching
>> from the network. In the broken firmware implementation (like the
>> HL7588), this detaches, then immediately reattaches to the network. In
>> a well-behaved firmware, this would simply deactivate the PDP context.
>> 3. Re-enables +CGREG handling once the bearer has been connected
>> successfully or upon cancellation.
>>
>
> This may not be any broken firmware; registration to the LTE network
> implies connection to the default EPS bearer.
>
>> Does this seem like an acceptable way to work around this issue? An
>> alternative would be to add an extra step that re-enables +CGREG
>> handling immediately after deactivating the context. Or is there a
>> better way to prevent ModemManager from canceling the connection
>> attempt?
>>
>
> I'm not sure how well we can handle this; we shouldn't really ignore
> registration updates happening during a connection attempt... I
> understand the problem you're facing, but I wonder if the solution
> goes from some other way.
>
> Are you sure you need to use the "broadband" APN? Can you request
> connection to some other APN, or even the blank "" one? It may happen
> that we just need to leave that context autoconnected as it is and
> just go on and request connection through a different context. This
> would be similar to how the u-blox Toby modem works.

AT&T uses the default bearer for internet connectivity which uses the
broadband APN (broadband.mnc410.mcc310.gprs when +HBHV=3,0 is set).

Verizon uses their vzwims APN for the default bearer in context #1.

>
> Actually, I went and took a look at the +HBHV command in the reference
> and found the <show_orig_apn> setting that I believe clarifies a lot
> the issue here. The reference says:
>
> ===========
> <show_orig_apn> Enables showing the original APN saved in non-volatile
> memory (updated by AT+CGDCONT); this is effective for PDP  context 1
> (LTE default bearer) with PDP context reading (AT+CGDCONT?)
> 0: Disabled. Shows APN given by the network (e.g.
> "ltemobile.apn.mnc720.mcc302.gprs", "vzwims.mnc480.mcc311.gprs")
> 1: Enabled. Shows the original APN saved in non-volatile memory
> ===========
>
> What you see there is that PDP context 1 is used here for the LTE
> default bearer; and "broadband" is the non-volatile name stored in
> memory, your modem probably has setting "1" for that parameter. So,
> when you try to request activation of the context with APN "broadband"
> via ModemManager, you end up trying to activate the context associated
> to the default LTE bearer, and as you have seen, disconnecting it ends
> up triggering unregistration messages. If you had the
> <show_orig_apn>=0, this wouldn't happen, because instead of seeing
> "broadband" in the +CGDCONT? response you would see the APN given by
> the network (e.g. "ltemobile.apn.mnc720.mcc302.gprs") and that
> wouldn't collide with the "broadband" APN you're requesting).

It's "broadband.mnc410.mcc310.gprs" which does collide with the
broadband APN, but as I explained above, +XDNS request settings are
cached, so It should be fine now.

>
> So, I would say that you could try to remove the registration URCs
> disabling/enabling logic and retry with a different APN, not the
> "broadband" one. What do you think?
>
> BTW; are you testing with a HL7588 for Verizon or for AT&T (or some
> other)? Looks like they come with different settings by default.

I've been testing both variants. There are a few settings which are
different and separate firmware versions. Loading new firmware is
surprisingly painless using Sierra specific AT commands (AT+WDSD).

>
>> Regarding +XDNS parsing: Ths is another broken part of the HL75xx
>> firmware. The return value from this command often contains duplicate
>> addresses (specifically when used with an IPV4V6 dual-stack context).
>>
>> +XDNS: 3, "198.224.166.135", "198.224.167.135"
>> +XDNS: 3, "198.224.166.135", "198.224.166.135"
>> +XDNS: 3, "198.224.166.135", "198.224.167.135"
>> +XDNS: 3, "198.224.166.135", "2001:4888:53:FF00:524:D:0:0"
>> +XDNS: 3, "198.224.166.135", "2001:4888:52:FF00:528:D:0:0”
>>
>> An IPv4-only or IPv6-only context tends to returns only one or two DNS
>> server addresses in a single line.
>>
>
> Hah, that really is broken; yes we do need proper unit tests to cover
> all good and bad cases, now more important than ever.
>
>> I will send an updated patch that takes into account your other
>> comments in the next few days.
>
> One other thing I found out while browsing the AT reference... instead of doing
>    AT+CGACT=1,<cid>
>    AT+XDATACHANNEL=1,1,"/USBCDC/<acm_id>","/USBHS/NCM/<ecm_id>",2,<cid>
>    AT+CGDATA="M-RAW_IP"
>
> Could you try just this?
>    AT+XCEDATA=<cid>,<ecm_id>
>

With +KUSBCOMP=0, only NCM interfaces are available, so +XCEDATA
returns error 100 always. This could be different with a different USB
composition that has ECM interfaces.

>
> Thanks!
>
> --
> Aleksander