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:
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?
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
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?
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.
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.
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:
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?
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 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 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!
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.
Yes, it has been resolved. The main issue was the password-becoming-lowercase quirk described above, which was slightly more complicated than I thought. The double quote fix still worked.
