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

[Aleksander Morgado]

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.

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

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

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.

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


Thanks!

-- 
Aleksander