HL7650 credentials - 30 chars max or 64 chars?


#1

The AT command guide (I checked multiple revisions) says that WPPP will only accept up to 30 characters for a username or password. However, trial and error shows it will take 64:

> AT+WPPP=1,1,"1234567890123456789012345678901234567890123456789012345678901234","test"
< OK
> AT+WPPP=1,1,"12345678901234567890123456789012345678901234567890123456789012345","test"
< ERROR
> AT+WPPP?
< +WPPP: 1,1,"1234567890123456789012345678901234567890123456789012345678901234","test"

The behavior seems to be the same across multiple firmware versions (3.14, 3.21, 3.26…).

I have a customer with 40-character usernames (user@example.org format; both the users and domain are long), and the modem is failing to authenticate, and I’m trying to identify the cause.

If the limit is 30, why does the error only start above 64? (And why is it so low?)

If the limit is 64, why does the documentation say 30?

Thanks.


#2

Hi mkchk,

It should be a document issue. The limit is 64 bytes for the username and password.
We will ask for a document update.
Thank you for test.


#3

Hi mkchk,

Please try the following to see you can succeed the authenticate or not.
AT+CGDCONT=1,“IP”,“APN”
AT+WPPP=1,1,“username”,“pass” //PAP
or AT+WPPP=2,1,“username”,“pass” //CHAP
AT+CGACT=1
AT+CGACT=0


#4

Hi,

I have already tried both PAP and CHAP.

This is drifting off topic, but are there any known issues with PAP mode? For example, is there a case where the modem ignores the user setting and uses CHAP anyway? CHAP is known not to work on this particular network, but some modems/devices with “auto” mode will try CHAP repeatedly and never connect, and have to be forced to PAP only.

Is there a debugging mode that shows more information than AT+CEER?

Thanks.


#5

I’ve also noticed that CGATT can fail (ie. returns ERROR immediately without trying to attach), but there’s nothing in the documentation that says what the failure conditions are:

> AT+CGATT=0
< ERROR
> AT+CGATT=1
< ERROR

If I switch the error mode with CMEE, it reports “+CME ERROR: invalid mobile class”. AT+CEER gives “no report”.

This seems to occur at random, and rebooting the modem often doesn’t help.


#6

Hi mkchk,

So far, I did not hear such issue on HL7650, +WPPP setting should work.
If any issue, please provide STT traces.

About AT+CGATT=0/1 returns +CME ERROR: invalid mobile class, I can see the same as you. I’ll report it to our R&D. Please let me know if it’s a blocking issue for you.


#7

Hi,

The CGATT issue doesn’t seem to be a major problem. When using a known working SIM and credentials, it will eventually get a connection (using ATD and PPP), even if I can see CGATT failing in the logs.

I have successfully tested a 46 character username, so that confirms that the limit is much higher than 30.

By the way, I found a strange issue if WPPP is used but the username/password isn’t wrapped in double quotes and the first character of the password is a digit. The rest of the string gets converted to lowercase, resulting in failed authentication:

AT+WPPP=1,1,test@example.org,123ABC

OK

AT+WPPP?

+WPPP: 1,1,"test@example.org",“123abc”

OK

The example does use quotes, but a note clarifying the importance of quotes below WPPP would be helpful.

On that note, is there an escape code in case the password contains "? Are there any other characters that aren’t allowed?

Thanks.


#8

I’m not sure how to do this.


#9

Hi mkchk,

Did you get your HL7650 via Sierra distribution channel? If no, please advise where you bought it. Thanks.


#10

Hi,

I believe we purchase the modules from M2M Connectivity.


#11

Good afternoon mkchk,

I received a support request on this from M2M Connectivity, however they closed the support request very shortly after lodging it. Is this still an open enquiry?

Regards,
Tyrone


#12

Hi Tyrone,

A new ticket is updated on the portal.

Regards,
Kushani


#13

Good evening @mkchk

The configuration of AT+WPPP doesn’t matter as the authentication for PPP dialup is managed by the dialup process and manager.
We’ve tested with the HL7650 and successfully created PAP and CHAP based dialups (respectively) in Windows.

Windows based PPP dialup - PAP authentication

See screenshot:
Windows_PPP_PAP_ONLY

Windows PPP dial up succeed with PAP ONLY : ATD*99#
C:\WINDOWS\System32>ipconfig
PPP adapter Dial-up Connection:
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 10.28.93.204
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 0.0.0.0
C:\WINDOWS\System32>ping 8.8.8.8 -S 10.28.93.204
Pinging 8.8.8.8 from 10.28.93.204 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=219ms TTL=41
Reply from 8.8.8.8: bytes=32 time=157ms TTL=41
Reply from 8.8.8.8: bytes=32 time=385ms TTL=41
Reply from 8.8.8.8: bytes=32 time=120ms TTL=41
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 120ms, Maximum = 385ms, Average = 220ms
C:\WINDOWS\System32>

Windows based PPP dialup - CHAP authentication

See screenshot:
Windows_PPP_CHAP_ONLY

Windows PPP dial up succeed with CHAP ONLY: ATD*99#
C:\WINDOWS\System32>ipconfig
PPP adapter Dial-up Connection:
Connection-specific DNS Suffix . :
IPv4 Address. . . . . . . . . . . : 10.238.72.135
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 0.0.0.0
C:\WINDOWS\System32>ping 8.8.8.8 -S 10.238.72.135
Pinging 8.8.8.8 from 10.238.72.135 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=1702ms TTL=248
Reply from 8.8.8.8: bytes=32 time=564ms TTL=248
Reply from 8.8.8.8: bytes=32 time=218ms TTL=248
Reply from 8.8.8.8: bytes=32 time=155ms TTL=248
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 155ms, Maximum = 1702ms, Average = 659ms
C:\WINDOWS\System32>

Regards,
Tyrone

PS. Thanks to @Sierra_klin1 for helping to look into this! :+1:


#14

Hi,

I’ve had a very different experience. If the correct settings aren’t set with WPPP, then no PPP negotiation ever takes place as the ATD command hangs and never returns CONNECT. PPP seems only to be there as an easy way to get IP running over a virtual serial port, with the “real” authentication always being done by the modem firmware.

In any case, I have provided Kushani with debug traces. I hope we can get this sorted out quickly.