[Cellular] User authentication and PPP mode

[trowbridgec]

Description

We have been given some test Stream (Pelion Connectivity) SIMs which require the use of a username and password (in addition to the APN) in order to successfully connect. This can be achieved using the AT+CGAUTH command which is wrapped by the do_user_authentication() function in AT_CellularContext.cpp.

The problem here is that if you're using PPP mode (i.e. NSAPI_PPP_AVAILABLE is defined), then do_user_authentication() is never called in the find_and_activate_context() function. Also, since do_user_authentication() is marked as protected, you cannot call it from a user application to workaround this. Therefore, in order to get the Stream SIMs (or any SIM which requires a username and password) to work, we had to manually call the AT+CGAUTH command and rely on the internal non-volatile settings storage of the cellular module.

Is there harm in changing the find_and_activate_context() function to call do_user_authentication() in PPP mode? Is a better solution to make do_user_authentication() public so that it can be called in user applications? Is there a different way to pass in a username and password in PPP mode?

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

[trowbridgec]

@maclobdell

[40Grit]

@ARMmbed/mbed-os-wan

[40Grit]

@ARMmbed/mbed-os-wan

[40Grit]

@0xc0170 ^^^^^^ @ mention failure

[0xc0170]

@ARMmbed/mbed-os-wan

[AriParkkila]

@trowbridgec In PPP we don't activate any context but leave it to PPP stack in AT_CellularContext::open_data_channel.

[trowbridgec]

Ah, I see now that open_data_channel() does use the username and password! I also received a hint from @maclobdell that you have to prefix the APN with the authentication type (e.g. CHAP:stream.co.uk for Stream SIMs). I didn't do that the last time I tried the Stream SIMs, so I'll have to give it a try and report back.

[AriParkkila]

@trowbridgec any update, can we close this?

[0xc0170]

cc @40Grit

[trowbridgec]

I need to try this again.

I did re-try this, but simply adding CHAP to the front of the APN doesn't signal the cell module to use CHAP authentication; I need to call the set_authentication() function first. Unfortunately, our application is using an older version of mbed-os at the moment that doesn't include the set_authentication() function yet, so I can't test it right away until we update (probably once 5.14 drops).

We did have a call with the Stream folks and were able to determine that we weren't setting the username and password correctly and were getting denied connection due to that. Our Stream contact was able to temporarily force the credentials for us, and the SIM connected like a charm.

[linlingao]

I can confirm this is an issue. The Stream SIM would not even pass the register with network state if AT+CGAUTH is not sent. In PPP mode, do_user_authentication is bypassed. Even if we don't bypass it, it is still too late. Note that, this needs to be sent once only.

[AriParkkila]

@trowbridgec Mbed OS 5.14 is now released, can you retest?

@linlingao I'm not sure what you mean with "register with network"? AT+CGAUTH requires so you must already have been registered to a cellular network first. In PPP mode, PPP should take care of authentication.

[linlingao]

@AriParkkila That's exactly the point. AT+CGAUTH should be sent AFTER registration with the cellular network. But the SIM would not register with the network unless AT+CGAUTH is sent BEFORE. This appears to be the 1st workaround to get stream SIMs to work. The other workaround is to write a profile using a mobile phone. I'm not sure if the issue is in the cellular stack. I'm still investigating this.

[AnttiKauppila]

@linlingao Any progress?

[trowbridgec]

It's possible that this functionality is only applicable for the Telit ME910 (which we are using; I haven't tried other cell modules), but, as @linlingao said, it seems as though you need to call AT+CGAUTH AFTER the module powers up and BEFORE registration. In my opinion, the ideal place to do this would be in find_and_activate_context() in AT_CellularContext:

nsapi_error_t AT_CellularContext::find_and_activate_context()
{
    _at.lock();

    nsapi_error_t err = NSAPI_ERROR_OK;

    // try to find or create context of suitable type
    if (get_context()) {
#if NSAPI_PPP_AVAILABLE
 <<<<<<<<<<<<<<<<<< ADD THIS LINE BELOW <<<<<<<<<<<<<<<<<<<<<
        err = do_user_authentication();
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
        _at.unlock();
        // in PPP we don't activate any context but leave it to PPP stack
        return err;
#else
        // try to authenticate user before activating or modifying context
        err = do_user_authentication();
#endif // NSAPI_PPP_AVAILABLE
    } else {
        err = NSAPI_ERROR_NO_CONNECTION;
    }

    if (err != NSAPI_ERROR_OK) {
        _at.unlock();
        tr_error("Failed to activate network context! (%d)", err);
        return err;
    }

    // do check for stack to validate that we have support for stack
    if (!get_stack()) {
        _at.unlock();
        tr_error("No cellular stack!");
        return NSAPI_ERROR_UNSUPPORTED;
    }

    _is_context_active = false;
    _is_context_activated = false;

    _is_context_active = _nw->is_active_context(NULL, _cid);

    if (!_is_context_active) {
        activate_context();
    }

    err = (_at.get_last_error() == NSAPI_ERROR_OK) ? NSAPI_ERROR_OK : NSAPI_ERROR_NO_CONNECTION;

    // If new PDP context was created and failed to activate, delete it
    if (err != NSAPI_ERROR_OK && _new_context_set) {
        delete_current_context();
    } else if (err == NSAPI_ERROR_OK) {
        _is_context_active = true;
    }

    _at.unlock();

    return err;
}

[linlingao]

We're experiencing similar issue on Telit LE910 as well. We may need to do this for all Telit modules. On the LE910, CGAUTH is not supported, we issue PDPAUTH to get it to work. I think doing this in find_and_activate_context is likely too late. The recommendation from a cellular expert is to issue CGAUTH/PDPAUTH first, then reboot the module.

[0Grit]

@linlingao have you opened a ticket with Telit? They are generally pretty responsive. Open a ticket through ts-americas@telit.com feel free to copy us.

[linlingao]

Please have a look at https://www.telit.com/wp-content/uploads/2017/12/Telit_IP_Easy_User_Guide_r23.pdf This spec is for LE910. On page 53, there's a sequence for power on. It seems we need to send APN/authentication for CID=1 (default CID without actual context) then detach and attach again. I suspect the same sequence is needed for ME910. I've sent an email to Telit to confirm. In the meantime, I'll try if I can do a factory reset on my modem. But @loverdeg-ep if you have a board that doesn't already have authentication saved, it would be helpful to know if this sequence works.

[0Grit]

I'm awaiting a flight back from TechCon. @trowbridgec might be able to assist.

[linlingao]

I've done some extensive investigation on this issue since we've been observing different behaviors in Stream SIM provisioning with various roaming networks. Finally, all these observations seem to converge, thanks to the help from Jerry and Ricky from the connectivity team. (1) Different Stream SIMs may behave differently in provision depending on the service enabled on the SIM. I'm aware of two different types pertinent to provisioning. (a) SIMs with fixed IP support might not require CGAUTH during registration. In my testing, SIMs with fixed IP are able to register and attach with AT&T's CATM1. The hypothesis is, AT&T fills authentication for Stream if authentication is left blank. However, per conversations with Ricky, some roaming networks do not do this, so he recommends we ALWAYS send authentication during registration. (b) SIMs without fixed IP support, a.k.a. dynamic IP may register with GSM network without authentication. For example, in my testing, I see my SIM is provisioned with T-Mobile GSM network. However, CGAUTH is required for LTE, so it's not possible to register with LTE networks without authentication. (2) The existence of authentication parameters in the non-volatile storage on the modem also plays a role. (a) Modem with authentication parameters saved in its non-volatile storage is able to acquire PDP context at power on without having to explicitly send CGAUTH. As a result, SIMs with or without fixed IP support get provisioned quickly and successfully. (b) Out-of-box modem without authentication saved requires CGAUTH during registration in most cases, with the exception of using fixed IP SIM on some roaming networks.

In summary, we need a fix in our cellular state machine to send CGAUTH so that Stream SIMs can work with ALL roaming networks and on out-of-box modems. I think the best place to add the code is in state state_sim_pin().

Perhaps something like: if (_network.is_active_context()) { // check if context was already activated tr_debug("Active context found."); _status |= ACTIVE_PDP_CONTEXT; } else { _network.power_on_authentication() // new function to send CGAUTH or PDGAUTH }

@AnttiKauppila Would you like a PR?

[linlingao]

Telit support confirmed CGAUTH is needed at power on for CID 1. Email from Telit:

"Hi Lin,

Sorry for the delay. For ME910C1-** please use (as you suspected):

AT+CGAUTH=,,, Set command allows the TE to specify authentication parameters for a PDP context identified by the (local) context identification parameter , used during the PDP context activation and the PDP context modification procedures.

I attached the latest AT manual.

We didn't update the IP easy guide to also cover the ME910.

Yes you will need to detach/reattach to have the settings take effect if you change them after attaching without the set USER,PASSWORD If you set the APN in CID 1 and the AUTH parameters the next power cycle you should be set."

[40Grit]

@linlingao You able to do the PR or should we? @trowbridgec

[linlingao]

@40Grit Please go ahead and submit a PR. I'd like to review it though.

[trowbridgec]

@maclobdell

[0Grit]

@trowbridgec has been extremely busy

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers. Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2168

[ciarmcom]

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.