Gary,
I might be missing something but I am failing to see what is causing the failure of the LTE session?
Regards
Matt
Hi Matt,
See row 11 (highlighted in red) in the spreadsheet attached to my last post. You will see that the IP Address is rejected during PPP negotiation on 4G but not 2G, causing the PPP session to abort. I am not sure whether this is an issue with the Keil PPP stack or with the HL7692, but it all works OK with 2G.
Also, any thoughts regarding the “stuck” IP address? - when the 4G PPP negotiation fails and if the module then reverts back to 2G then +CGPADDR still returns an IP address, it doesn’t go back to 0.0.0.0 for 2G.
Regards
Gary
Gary,
I just did the following (all on my Ubuntu desktop).
- Power HL7 up, it attaches to LTE.
- Check APN (its EVERYWHERE as set by the network), CREG. CGREG, etc. Also CGDCONT/CGPADDR=1 and they both have IP addresses assigned.
- Start a PPP session off with the unit (using the UART).
- IP address is passed back to the PC and I start pinging 8.8.8.8 successfully.
- On the USB port I sent the command at+ksrat=1 to force the unit to 2G which it then did.
- Immediately the pings failed and the IP address was dropped from the CGDCONT CID.
I did the same but starting off from 2G the setting KSRAT to LTE and the session did successfully hand over up to LTE keeping the same IP address as well.
This indicates the following
- That the IP address is not held at all when switching between networks
- EE is unable to handover data sessions LTE to 2G but can 2G to LTE, this is odd though as it normally works the other way around.
I am still not sure where or why the reject is coming from the unit (which is what your log implies), I have not managed to get it to fail yet.
Regards
Matt
Hi Matt,
I have also send my IP Address Reject trace to Keil, the TCP/IP stack (PPP client) vendor I am using, as I am not sure whether this is a Keil issue, Sierra Wireless issue or an EE issue. The response I had was …
Best Regards
Gary
Gary,
Thats going to be a problem, its a PPP session, its pretty standard (as per the 3GPP specs. Beyond that we do not have any other documentation like options it does or does not support especially given it generically works on everything else.
Regards
Matt
Hi Matt,
I can make it work by doing the following:
AT+CGATT=0;+CGDCONT=1,“IP”,“everywhere”
ATDT99**1#
+++ATH
AT+CGATT=1
Detaching before PPP and re-attaching after, seems to work. I don’t get an IP Address Reject. Any ideas why?
Regards
Gary
Gary,
The unit is on LTE at this point?
Regards
Matt
Hi Matt,
It was on LTE before I did AT+CGATT=0. I am not sure what the latter does in terms of LTE - it made my PPP work but would AT+CGATT=0 have caused it to switch to 2G ?
Alsi is it possible for you to send me a wireshark trace of your PPP session working over Linux? It would be much appreciated as I could then send this to Keil for them to confirm whether it is a problem with their PPP stack?
Regards
Gary
Gary,
Yes sending at+cgatt=0 does push the unit back to 2G, it cannot be on LTE without being packet switch attached.
The wireshark log file is a little difficult as the PPP interface does not exist until it is brought up and as a result cannot be monitored until after we need it to be. I have attached the extract from the syslog file.
Regards
Matt
Hi Matt,
I didn’t see the attachment in your last post.
I have made a bit of a breakthrough…
Keeping AT+CGATT=1 (i.e. without my workaround described earlier)
My sequence for each PPP session was:
ATZ
ATE0V1
AT+CGDCONT=1,“IP”,“everywhere”
ATDT99**1#
This worked fine for 2G but resulted in an IP Address Reject for 4G.
If I send AT+CGDCONT=1,“IP”,“everywhere” just the once on power-up and then use the following sequence before each PPP session then it works OK on 4G too:
ATZ
ATE0V1
ATDT99**1#
It seems that sending AT+CGDCONT=1,“IP”,“everywhere” just before initiating a PPP session was the cause of the problem.
However, sometimes my module starts up on 4G but with IP address 0.0.0.0 and even with the above fix, 4G PPP will fail with IP Address Reject if IP address is 0.0.0.0. After the PPP session fails the module then seems to get an IP address and PPP will then work on the next attempt.
Therefore, this raises 2 questions:
- Why does my module sometimes startup on 4G but with an IP address of 0.0.0.0, causing PPP to fail ?
- Could it be that when I was sending AT+CGDCONT so soon before dialling PPP that the IP address momentarily went back to 0.0.0.0, causing PPP failure ?
Regards
Gary
Gary,
LTE is different to 2G in that the network tells the unit what APN to use where in 2G you have to tell the unit. When LTE tells the unit during the attach process it is stored in CGDCONT profile 1, I always saw the APN ‘EVERYWHERE’ in profile 1 when I just let it attach of its own accord, I then perform the dial up. Alternatively I set the APN to ‘everywhere’ prior to it attaching to the network and it also works (on both 2G and LTE without changing it to upper case).
I guess it was creating a conflict somewhere either on the unit or within the network that you were ‘changing’ the APN on dial up. I would suggest reading CID 1 out in your code, if the APN is set leave it otherwise set it yourself.
Regards
Matt
Hi Matt
On power-up my unit shows
+CGDCONT: 1,“IP”,"",“31.99.77.185”,0,0,0,0,0,0
It does not show an APN but does show an IP address - should I set the APN in this case, or is the fact that it has an IP address enough?
Regards
Gary
Gary,
I seem to have recreated the problem and think I know what is going on.
- Power up the unit and it attaches to LTE (in this case EE).
- The unit shows CGDCONT profile 1 without an APN but with an IP address.
- Set the APN to the one you want to use i.e. eveywhere. CDGCONT now shows the APN but no IP address.
- Perform the dial up networking and it fails with an IP address failure.
I think step 3 is deleting/resetting information from the unit which then causes a conflict when the PPP dial up occurs. If you perform the above without running step 3 the connection succeeds, obviously this will not work for 2G where it needs to know the APN.
The solution to this is to make sure the APN is set either when the unit is on 2G or set it initially during any commissioning procedure and then rely on the unit storing it in flash (which it does automatically).
Note if the APN is set incorrectly in CID 1 then the unit is unable to attach to LTE and will stay on 2G, I have tested this on the MC products as well.
I have seen the APN being updated when it attaches to the LTE network I just cannot repeat or remember where this was or against which unit (I do a lot of different tests all day).
Regards
Matt
Hi Matt,
Thanks for the explanation and thankyou for your help this week.
Gary