PDP Type needs to be IPV4V6 #12396

felser · 2020-02-07T22:02:09Z

1.Testing with Verizon and AT&T SIMs, PDP type is automatically set to IPV4V6.
2. Testing with AT&T IoT SIM, PDP type automatically sets to IP. It will connect
but not communicate. Setting a subsequent APN to IPV4V6 with the same APN communicates.

Summary of changes

Enable stack/PDP type IPV4V6 and not IPV4 for this platform. Verizon and AT&T LTE SIM cards automatically set the PDP type to IPV4V6. AT&T IoT SIM cards automatically set PDP type to IPV4 but mbed-os is not able to communicate with that setting passed to LWIP. With only IPV4V6 enabled, mbed-os will configure the next available context with IPV4V6 in the PDP type and set the APN included in the json file. This allows for successful communication.

Impact of changes

Migration actions required

Documentation

None

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers

1.Testing with Verizon and AT&T SIMs, PDP type is automatically set to IPV4V6. 2. Testing with AT&T IoT SIM, PDP type automatically sets to IP. It will connect but not communicate. Setting a subsequent APN to IPV4V6 with the same APN communicates.

ciarmcom · 2020-02-08T00:00:32Z

@felser, thank you for your changes.
@ARMmbed/mbed-os-wan @ARMmbed/mbed-os-maintainers please review.

AriParkkila · 2020-02-10T07:52:41Z

features/cellular/framework/targets/MultiTech/DragonflyNano/PPP/SARA4_PPP.cpp

@@ -32,9 +32,9 @@ static const intptr_t cellular_properties[AT_CellularDevice::PROPERTY_MAX] = {
    1,  // AT_CSMP
    1,  // AT_CMGF
    1,  // AT_CSDH
-    1,  // PROPERTY_IPV4_STACK
+    0,  // PROPERTY_IPV4_STACK


Should probably define all IPV4, IPV6 and IPV4V6 to 1, or AT_CellularContext::get_context() fails to find IPV4/IPV6 only contexts.

Enabling IPV4 results in failed communication with AT&T IoT SIMs. The ublox radio automatically populates context 1 with IP as the PDP type and doesn't allow the user to change it to IPV4V6. If mbed detects a PDP type of IPV4, it sets the LWIP stack to IPV4 which fails to communicate. However if the LWIP stack is set/forced to IPV4V6 communication is successful. With the change I made, mbed sets context 2 with the same APN as context 1 but PDP type as IPV4V6. Though probably not ideal, it works with all the SIM cards we have. I plan to put a note on our mbed page describing where and why users might need to change this setting.

@felser Do you mean that the initial context PDP type is IP, but it has actually just IPV6 address? Can you have traces with cellular.debug-at: true?

It seems your modem allows multiple contexts with the same APN name, but that's not a generic case. It could be better to force the initial context to IPV4V6? For that, you need to disable initial context activation (e.g. AT+CIPCA could work if you are not in LTE), or detach from the network, delete the one modem created and create a new PDP with IPV4V6 before attaching again.

Here is an example of what it returns from AT+CGDCONT?...
+CGDCONT: 1,”IP”,”m2m.com.attz”,”10.254.68.252”,0,0,0,0
I was unable to find a way to force context 1 to be IPV4V6. Every time I change it then register it goes back to IP. I don't see the command AT+CIPCA or any other command in the ublox manual to disable initial context activation. I'm not sure I'd want to use that if I could given that this change appears to work without complication.

The radio (kind of) allows multiple contexts with the same APN. According to ublox, after I sent them debug capture with their debug tool, the call on CID 2 is actually routed to CID 1. So all this change is really doing is telling mbed to use IPV4V6 stack.

Our code is specific to this ublox radio. We have no other radio on this platform. This change is working well for all SIMs I have tested.

FYI, I can connect and send data on context 1 using the radio stack or Windows dial up networking but mbed-os does not work. At one point I edited the AT_CellularContext code to force IPV4V6 to the nsapi_ppp_connect(...) call. That works on context 1.

0xc0170 · 2020-02-10T15:46:46Z

CI started

mbed-ci · 2020-02-10T18:15:28Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts

0xc0170 · 2020-02-11T08:36:09Z

Moved to needs: review to finalize the reivew

AriParkkila · 2020-02-12T06:07:29Z

@ARMmbed/team-ublox please comment

fahimalavi · 2020-02-12T06:52:35Z

First apologies, some more information is required

What exact SARA-R4xx version you are using ?
Have you set and enabled mnoprofiles feature ?

felser · 2020-02-12T14:34:49Z

This is the SARA-R410-02B. If I recall correctly, setting +UMNOPROF to AT&T or letting it auto select didn't matter.

fahimalavi · 2020-02-13T13:02:21Z

Without MNO =1 (SIM ICCID select), the parameters shouldn't change. If you had set +UMNOPROF to AT&T then inserting AT&T IoT sim shouldn't change parameters. If user has selected MNO=1 (SIM ICCID select) ?
If the SIM is not inserted or the SIM IIN does not match any MNO, the last valid MNO remains active and is consequently shown with those parameters.
Can you send response for AT&V (Reports a summary of the current configuration and of the stored user profiles. ) ?

felser · 2020-02-13T17:28:59Z

With +UMNOPROF=0, the context still changes. Even worse, if I set +UMNOPROF=2, it locks up the radio serial port! The second problem is something we are working on with Steve Brown at ublox. Please see the attached. Note: I had previously been using and AT&T SIM that provide a context populated as IPV4V6 and APN = phone.
ublox_at&t_IoT.txt

felser · 2020-02-13T19:53:03Z

UPDATE: When changing +UMNOPROF from 0 to 2, PSM mode gets enabled. That's what appeared to cause the serial port lock up. However, once set to 2 with PSM disabled, the PDP type is still over written. So with +UMNOPROF 0 or 2, the PDP type changes from IPV4V6 to IP with my IoT SIM installed.

fahimalavi · 2020-02-14T07:17:43Z

At line 96 in logs, user is setting PDNType and APN between sending +UMNOPROF and reboot commands. That is why your APN is incorrect later at line 109. Please follow the procedure specified in AT command manual for setting MNOProfile. I have verified the behavior using AT&T sim.
As you have specified "Every time I change it then register it goes back to IP". CGDCONT read command returns the current settings for each defined context. Look like from network you are allowed for IPv4 only.

0xc0170 · 2020-02-14T09:27:30Z

CI restarted

mbed-ci · 2020-02-14T11:21:05Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts

PDP Type needs to be IPV4V6

77218f0

1.Testing with Verizon and AT&T SIMs, PDP type is automatically set to IPV4V6. 2. Testing with AT&T IoT SIM, PDP type automatically sets to IP. It will connect but not communicate. Setting a subsequent APN to IPV4V6 with the same APN communicates.

ciarmcom requested review from a team February 8, 2020 00:00

ciarmcom added the needs: review label Feb 8, 2020

AriParkkila suggested changes Feb 10, 2020

View reviewed changes

0xc0170 approved these changes Feb 10, 2020

View reviewed changes

mergify bot added needs: CI and removed needs: review labels Feb 10, 2020

mergify bot added ready for merge and removed needs: CI labels Feb 10, 2020

0xc0170 added needs: review and removed ready for merge labels Feb 11, 2020

0xc0170 requested a review from a team February 12, 2020 13:06

fahimalavi approved these changes Feb 14, 2020

View reviewed changes

0xc0170 added needs: CI and removed needs: review labels Feb 14, 2020

mergify bot added the ready for merge label Feb 14, 2020

mergify bot removed the needs: CI label Feb 14, 2020

0xc0170 added the release-version: 6.0.0-alpha-2 Second pre-release version of 6.0.0 label Feb 14, 2020

0xc0170 merged commit 3d038e5 into ARMmbed:master Feb 14, 2020

mergify bot removed the ready for merge label Feb 14, 2020

PDP Type needs to be IPV4V6 #12396

PDP Type needs to be IPV4V6 #12396

Uh oh!

Conversation

felser commented Feb 7, 2020

Summary of changes

Impact of changes

Migration actions required

Documentation

Pull request type

Test results

Reviewers

Uh oh!

ciarmcom commented Feb 8, 2020

Uh oh!

AriParkkila Feb 10, 2020

Choose a reason for hiding this comment

Uh oh!

felser Feb 10, 2020

Choose a reason for hiding this comment

Uh oh!

AriParkkila Feb 11, 2020

Choose a reason for hiding this comment

Uh oh!

felser Feb 11, 2020

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Feb 10, 2020

Uh oh!

mbed-ci commented Feb 10, 2020

Test run: SUCCESS

Uh oh!

0xc0170 commented Feb 11, 2020

Uh oh!

AriParkkila commented Feb 12, 2020

Uh oh!

fahimalavi commented Feb 12, 2020

Uh oh!

felser commented Feb 12, 2020

Uh oh!

fahimalavi commented Feb 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

felser commented Feb 13, 2020

Uh oh!

felser commented Feb 13, 2020

Uh oh!

fahimalavi commented Feb 14, 2020

Uh oh!

0xc0170 commented Feb 14, 2020

Uh oh!

mbed-ci commented Feb 14, 2020

Test run: SUCCESS

Uh oh!

Uh oh!

fahimalavi commented Feb 13, 2020 •

edited

Loading