PPP over 4G

IoT Modules Legacy HL Series
1

I am using the HL7692 and PPP.
The module is automatically selecting 2G instead of 4G, presumable due to signal levels.

In this case (using my Keil TCP/IP stack) I can send ATDT99**1# to start my PPP connection, negotiate the connection OK and transfer data etc OK. It all works OK.

If I then force the module to select 4G (AT+KSRAT=5) then the unit registers with 4G ok. However, when I initiate a PPP connection, the connection negotiation fails with Conf_Rej IP Address Rejected.

Any ideas on why this could be? Could it be caused by a low 4G signal or is it because my stack only supports IPv4 - perhaps 2G works with IPv4 but 4G only works with IPv6?

2

Gary,

I have heard recently that EE is migrating their newer SIM cards (need to have been bought in the last 3 months) to IPv6 where all of the previous ones have been IPv4 to date. 2G is almost certainly going to be left on IPv4.I have just tested my HL7692 on EE (SIM card around 1 year old on PAYG) with PPP using a Linux desktop, I did this for both LTE and 2G and they both worked fine, coming back with IPv4 addresses.

Something you could check when the unit powers up and attaches to LTE is the below

at+cgdcont?
at+cgpaddr=1

If the unit powers up, attaches to LTE and brings the default bearer up (normal LTE operation) it will be assigned an IP address, the above commands will tell you what this address is and consequently if it is an IPv4 or v6 one, that might highlight your problem.

Regards

Matt

3

Hi Matt,

Thanks. My EE Sim is over 6 months old at least.

I get the following response with 2G (AT+KSRAT=1 or 9):
AT+CGDCONT?
+CGDCONT: 1,“IP”,“everywhere”,“0.0.0.0”,0,0,0,0,0,0
AT+CGPADDR=1
+CGPADDR: 1,“0.0.0.0”

If I force to 4G then I get the following (AT+KSRAT=5):
AT+CGDCONT?
+CGDCONT: 1,“IP”,“everywhere”,“0.0.0.0”,0,0,0,0,0,0
AT+CGPADDR=1
+CGPADDR: 1,“31.114.24.227”

This has confused me, I would expect it to be the other way round as 2G works with PPP and 4G doesn’t.
Note that my PPP client uses DHCP and I am using V2.18 firmware.

Regards
Gary

4

Gary,

On 2G you don’t get an IP address until you start a session on LTE you get it when you attach (as everything on LTE is IP based) so the results are consistent.

Given that you have an IPv4 address for the default bearer on LTE it probably means that the SIM is on the EE IPv4 addressing structure so I don’t think it is going to be an IPv6 issue as I would expect the IP address from the cgpaddr command to be passed back to the host system when the PPP session is started.

What are the options returns with the configure reject? Are you adding a username and password somewhere in the dial up sequence? Any other differences in the dial up routine?

Regards

Matt

5

Hi Matt,

Yes, I am adding a username and password (eesecure, secure) during PPP connection negotiation. I am using the PPP client in Keil’s Middleware Library and it all works OK on 2G (it is not aware of whether it is on 2G or 4G). However, it always fails on 4G, even though the same settings/parameters are being used. The following is returned:

041.7 PPP:*** Processing IPCP frame ***
041.7 PPP: Code : Conf_Rej
041.7 PPP: Id_Val: 0x01
041.7 PPP: Length: 10
041.7 PPP-ERR: IP Address Rejected

I have ruled out bad 4G signal, as I am at a different location today and 4G auto registers OK with a decent signal.

Regards
Gary

6

Gary,

The IP address rejected is a bit odd. Is it coming from the HL’s PPP stack or the keil one? The unit will have one already assigned to it so should be passing it straight back. Is there any significant difference between the IP addresses on

FYI with my EE SIM I do not bother with any username and pass words, just the ‘eezone’ APN although it is a PAYG SIM.

Regards

Matt

7

Hi Matt,

The PPP trace is from Keil’s stack. I am not sure how PPP works - does the Keil PPP stack communicate with a PPP stack in the HL or the network?

Your last post seemed to have an incomplete sentence “Is there any significant difference between the IP address on” …

I tried APN of “eezone” with no username/password and it did not work at all, not even on 2G. It failed at an earlier stage. I googled “eezone” and it seems to be used for MMS. “everywhere” seems to be the one used for IP. I have been using “everywhere” with “eesecure” and “secure” and this has worked fine on 2G. If I use a blank username and password then it also works ok on 2G but not 4G. I am using a contract SIM, not PAYG.

Regards
Gary

8

Gary,

The PPP link is between the HL and the application processor, the unit effectively acts as a proxy as far as the network is concerned. I have checked and the APN I used was using the ‘everywhere’ APN but I have not used a username and password, you might want to give that a try.

Re the IP address question, from the 2G negotiation you should have the IP address and you should be able to see the default bearer IP address from the at+cgpaddr=1 command, it was here I was wondering about to see if they are completely different.

Regards

Matt

9

Hi Matt,

2G works OK with or without username/password. 4G does not work either way - IP Rejected.

2G (after power cycle):
AT+CGATT=1 (and AT+CGDCONT?) show 0.0.0.0
During PPP negotiation the PPP trace shows 31.100.175.71
PPP session completes OK
AT+CGATT=1 (and AT+CGDCONT?) now show 31.114.29.179

4G (after power cycle):
AT+CGATT=1 (and AT+CGDCONT?) show 89.192.140.186
During PPP negotiation the PPP trace shows IP Rejected
PPP session aborts
AT+CGATT=1 (and AT+CGDCONT?) now show 31.65.159.207

Does this offer any clues?

Thanks
Gary

10

Gary,

On my system I am seeing the below.

2G (restricted using KSRAT)

  • Prior to session unit is attached to the network and CGDCONT shows no IP address, obviously no PPP interface up on the system.
  • Session started. CGDCONT IP address shown as 100.113.58.27, this is also propagated to the Linux system as well.

LTE

  • Prior to data session being started CGDCONT default bearer IP is shown to be 100.118.76.190.
  • Data session is started using pppd the above IP address is then propagated through to the Linux system on a PPP interface.

The above and your IP addresses from the network clearly show that the 2G and LTE sessions are running through different subnets, etc. The clear difference here that I can see is that your system is assigning different IP addresses to the network interface rather than using the IP address the unit is sending to it during the PPP negotiation, I suspect this is going to be a configuration setting in the Keil stack somewhere.

Can you do the test on a full Linux host to confirm unit/SIM/network functionality as I suspect it will work and it can then be narrowed down to the the config of the external stack.

Regards

Matt

11

Hi Matt,

I don’t have Linux boxes to try it on.

However, I have just had it fail on 2G too and can see a pattern…

On 2G, AT+CGPADDR=1 shows 0.0.0.0 and most of the time (not always) it is also this after a 2G PPP session terminates. However, sometime it shows an IP address, even when on 2G (it returns to 0.0.0.0 eventually). A PPP session when AT+CGPADDR=1 shows a valid IP address will fail with IP Address Rejected, even if on 2G. I suspect this is why 4G always fails, because 4G always has an IP address before the PPP connection starts.

My PPP stack has limited configuration, one option (which is enabled at compile-time) does the following:
// Obtain Client IP address automatically
// This option only applies when PPP Dial-up is used to dial
// to remote PPP Server. If checked, network connection
// dynamically obtains an IP address from remote PPP Server.

Therefore I am wondering whether if the HL already has an IP address, as shown by AT+CGPADDR=1, then something in the PPP negotiation upsets my PPP stack - perhaps it is trying to obtain an IP address from the network but it already has one (shown by AT+CGDADDR).

Regards
Gary

12

Gary,

Possibly but without a full log file it is difficult to confirm this as I would expect the two negotiations to be fairly similar, the unit already having an IP address is transparent to the application until it initiates the session, from an application point of view I would say the major difference would be the speed with which the session is started.

You could do the Linux test with a bootable USB key. but the 2G failure does put a different slant on it.

Regards

Matt

13

Matt,

Could you please briefly explain the following regarding CGPADDR=1

On power-up this usually shows 0.0.0.0 because the unit registers to 2G. Sometime later it might go to 4G (+CREG returns Act of 7) and CGPADDR=1 now shows an IP address. The unit may then fall back to 2G (+CREG returns AcT of 3) but CGPADDR=1 still shows an IP address - it does not revert back to 0.0.0.0.

A subsequent PPP session will then fail with IP Address Rejected (not sure why yet), and then CGPADDR=1 shows 0.0.0.0. A subsequent PPP session will then succeed.

Why does CGPADDR shows 0.0.0.0 for 2G and then an IP address for 4G and then an IP address for 2G and then revert to 0.0.0.0 after attempting to start a PPP session?

Regards
Gary

14

Gary,

Assuming the unit is not starting and stopping data sessions and just switching between 2G and LTE. When on 2G I would not expect the CGPADDR or CGDCONT commands to have an IP address populated where as when on LTE I would expect to see them populated.

From the testing have just done it is doing exactly that as shown below.he field is not populated when switching between 2G to LTE and back again.

at+cops?
+COPS: 0,2,"23430",0
OK
at+cgpaddr=1
+CGPADDR: 1,"0.0.0.0","0:0:0:0:0:0:0:0"
OK
at+cgdcont?
+CGDCONT: 1,"IPV4V6","everywhere","",0,0,0,0,0,0
OK
at+ksrat=9
OK
at+cops?
+COPS: 0,2,"23430",7
OK
at+cgpaddr=1
+CGPADDR: 1,"19.5.246.41"
OK
at+cgdcont?
+CGDCONT: 1,"IP","everywhere","19.5.246.41",0,0,0,0,0,0
OK
at+ksrat=1
OK
at+cops?
+COPS: 0,2,"23430",0
OK
at+cgdcont?
+CGDCONT: 1,"IPV4V6","everywhere","",0,0,0,0,0,0
OK
at+cgpaddr=1
+CGPADDR: 1,"0.0.0.0","0:0:0:0:0:0:0:0"
OK

Regards

Matt

15

Hi Matt,

Shown below (V2.18) is a trace when using 2G. You will see that CGPADDR=1 is giving an IP address - it should be 0.0.0.0 shouldn’t it ?

00000266.85:>AT+CSQ;+CESQ;+CREG?;+CGREG?;+CEREG?;+COPS?;+CGDCONT?;+CGPADDR=1
00000266.86:<+CSQ: 8,99
00000266.87:<+CESQ: 14,99,255,255,255,255
00000266.90:<+CREG: 2,1,“0895”,“991D”,3
00000266.93:<+CGREG: 2,1,“0895”,“991D”,3,“01”
00000266.96:<+CEREG: 2,0
00000266.98:<+COPS: 0,0,“EE”,0
00000266.99:<+CGDCONT: 1,“IP”,“everywhere”,“89.192.138.227”,0,0,0,0,0,0
00000267.06:<+CGPADDR: 1,“89.192.138.227”
00000267.09:<OK

Regards
Gary

16

Gary,

Assuming you have not started a PPP session I would expect it to be yes.

Regards

Matt

17

Matt

My point is that +CGPADDR shows it is NOT 0.0.0.0, why? It is registered to 2G and there is no PPP session active so why does it have an IP address?

Gary

18

Gary,

I understand the point, I do not know why, I have just upgraded my unit to 2.18 and it seems to be fine for me (not helpful for you) but it is not what I am seeing. I am entering the commands in manually so there is a few seconds between tech selection and the commands going in 10-20 seconds maybe so it might be that there is a lag if you are doing it in an automated fashion.

at+cops?
+COPS: 0,2,"23430",7

OK
at+cgmr
RHL769x.2.18.171000.201703171915.x7120m_1

OK
at+cgpaddr=1
+CGPADDR: 1,"100.117.194.1"

OK
at+cgdcont?
+CGDCONT: 1,"IP","EVERYWHERE","100.117.194.1",0,0,0,0,0,0

OK
at+ksrat=1
OK
at+cops?
+COPS: 0,2,"23430",0

OK
at+cgdcont?
+CGDCONT: 1,"IPV4V6","","",0,0,0,0,0,0

OK
at+cgpaddr=1
+CGPADDR: 1,"0.0.0.0","0:0:0:0:0:0:0:0"

OK
at+ksrat=9
OK
at+cops?
+COPS: 0,2,"23430",0

OK
at+cops?
+COPS: 0,2,"23430",7

OK
at+cgpaddr=1
+CGPADDR: 1,"100.117.194.1"

OK
at+cgdcont?
+CGDCONT: 1,"IP","EVERYWHERE","100.117.194.1",0,0,0,0,0,0

OK

Regards

Matt

19

Hi Matt,

I will do more tests to confirm but I suspect the following is what causes AT+CGPADDR to return an IP address for 2G:

2G auto-selected
AT+CGPADDR=1 returns 0.0.0.0
PPP session starts/ends OK
AT+CGPADDR=1 returns 0.0.0.0
4G auto selected
AT+CGPADDR=1 returns an ip address
PPP session aborts with “IP Address Rejected”
AT+CGPADDR=1 returns an ip address
2G auto-selected
AT+CGPADDR=1 returns an ip address

My unit is often switching between 2G/4G and I think a failed 4G PPP session causes the IP address to get “stuck”, even after subsequently auto-switching back to 2G. Thereafter, AT+CGPADDR=1 returns an IP address, even for 2G.

Regards
Gary

20

Hi Matt,

This does appear to be the case.

Also see the attached file showing a trace of PPP negotiation, working on 2G but failing on 4G with IP Address Rejected.

Regards
Gary
ppp_2g_4g_ip_reject.xlsx (12.2 KB)