[PH8-P] IP messages not received by server while PPP negotiation gives an IP address | Telit Cinterion IoT Developer Community
April 5, 2017 - 5:04pm, 6473 views
I use a PH8-P REVISION 03.001 and succeed to get a PPP connection by UART but IP messages are not received by server (neither TCP connection nor ping request).
PPP negotiation gives an IP address but I get the following answer to AT^SMONI in command **** :
^SMONI: 3G,10812,22,-3.0,-80,208,01,080C,158FF78,26,34,NOCONN
Following commands are sent in initializing phase AT+CGATT=1, AT+CGREG?, AT+CGDCONT, ATD*99***1#, so is anything missing which could explain NOCONN ?
Thanks.
Hello,
During the PPP negotiation you should be able to see the connection with SMONI. But if there is no data transfer after that you can also see NOCONN state. Could you write some more about what device are you using with the module? Could you paste the logs and ATI1 reply? Maybe there's some other problem like DNS for example.
Regards,
Bartłomiej
Hello,
The device used is a STM32F767ZI and USART2 is connected to ASC0 with 115200 data rate.
Here is an extract of the log with SMONI
Thu Apr 06 16:48:17 2017-- ^SYSSTART
Thu Apr 06 16:48:18 2017-- (70) ATI1
Thu Apr 06 16:48:18 2017-- Cinterion
Thu Apr 06 16:48:18 2017-- PH8-P
Thu Apr 06 16:48:18 2017-- REVISION 03.001
Thu Apr 06 16:48:18 2017-- A-REVISION 01.001.07
Thu Apr 06 16:48:18 2017-- OK
Thu Apr 06 16:48:22 2017-- (17) AT+CGATT=1
Thu Apr 06 16:48:22 2017-- OK
Thu Apr 06 16:48:27 2017--
Thu Apr 06 16:48:34 2017-- (31) AT+CGREG?
Thu Apr 06 16:48:34 2017-- +CGREG: 0,1
Thu Apr 06 16:48:34 2017-- OK
Thu Apr 06 16:48:36 2017-- (56) AT+CGDCONT=1,"IP","ORANGE.M2M.SPEC","0.0.0.0",0,0
Thu Apr 06 16:48:36 2017-- OK
Thu Apr 06 16:48:42 2017-- send ATD
Thu Apr 06 16:48:43 2017-- CONNECT
...
Thu Apr 06 16:48:50 2017-- sent [IPCP ConfAck id=0x1]
Thu Apr 06 16:48:54 2017-- (71)
Thu Apr 06 16:48:54 2017-- ^SMONI: 3G,10812,22,-3.5,-77,208,01,080C,158FF78,25,37,NOCONN
and the TCP connection attempt with IP at numeric format
Thu Apr 06 17:21:35 2017-- netmask = 255.255.255.255
Thu Apr 06 17:21:35 2017-- local IP address 10.193.253.128
Thu Apr 06 17:21:35 2017-- remote IP address 10.64.64.64
Thu Apr 06 17:21:35 2017-- primary DNS address 192.168.10.110
Thu Apr 06 17:21:35 2017-- secondary DNS address 194.51.3.56
7eff0300214500002c00050000ff0600000ac1fd80500b54efc00120c90000196d00000000600208600000000002040218a02c7e
Thu Apr 06 17:21:54 2017-- TCP error (=>-13)
Best Regards,
Jean-Marc
Hello,
It seems that the PPP connection has been established. So the problem is probably somewhere else. The primary DNS has a private address but the secondary might be correct. Maybe some configuration, some routing settings on your device is not correct. Have you tried to connect to some other public hosts. Or maybe your server is not visible form the network that you dial in. Maybe you are using a private APN and you dial in to the network that has no access to the public internet or the opposite way - you are using the public APN and the server is located in the private network.
Regards,
Bartłomiej
Hello,
Since we have a B80 starter kit, is it possible to check server visibility by using second USB connector ("+5V PWR") from windows 10 host ? Should it work with AT^SDPORT=4 or 6? Do we new to use AT+CGDATA instead of ATD*99***1# ?
Regards,
Jean-Marc
Hello,
Of course you can use the USB to connect to Windows machine. You just need the modem interface to setup the dialup connection. You can also use AT+CGDATA command. Or you can use the Windows GUI to configure the connection.
Regards,
Bartłomiej
Hello,
I am afraid I don't understand why it could be routing settings issue on my device since there is only one network interface and PPP protocol is used.
I assume this is the responsibility of the other point to forward my ping request to the good gateway. Is there something I miss ?
Regards,
Jean-Marc
Hello,
So it is finally working in Windows as I understand?
Regards,
Bartłomiej
Hello,
It is working in Windows so the server is accessible.
But I am afraid I don't understand why it could be routing settings issue on my device since there is only one network interface and PPP protocol is used.
I assume this is the responsibility of the other point to forward my ping request to the good gateway. Is there something I miss ?
Regards,
Jean-Marc
Hello,
If it is working in Windows with the same configuration (and you get the similar addresses for the connection - please compare) then most probably the module is functioning correctly. I don't know your device and how the communication is implemented. There could be some routing problems in Linux for example. In your case maybe you just push the tcp packets to the ppp protocol directly and it may not be the case. But you probably use some programming components, libraries for ppp, tcp etc. and still maybe something is configured in a wrong way or the data is incorrectly formatted or there's some incompatibility.
According to your log it seems like some data packet is being sent to the TCP layer at least and there is an error 13 in a reply. Maybe you should just start from getting more debugging information from your software.
I expect that if the correct data packet would successfully have been sent through PPP to the provider's gateway it would also be routed to the destination address as in Windows test.
Regards,
Bartłomiej
lwIP stack is used and error 13 is issued when there is no reply to our TCP connection requests (SYN request).
With lwIP the data packets sent on ASC0 were checked : the data starting and ending with 7e in my log extract is one of those.
lwIP available PPP options are for authentification, addresses setting (PPP server), peer dns servers, LCP connection initiation, header compression, ACCM negotiation, PPP default interface selection (option enabled), so these options don't affect post IP adddress negotiation behavior.
But there is one main difference between windows and our device : AT^SDPORT configuration. Maybe an USB connection is mandatory between the device and the module. Is there any debug option such as received data counter or traces to check our packets are received on the good interface at modem side ?
Regards,
Jean-Marc
Pages