PPP/GPRS connection established - can send, but can't receive IP data (solved)

Embedded Devices NET+OS
1

We are using CC9P9215-module with NetOs 7.5.2 on a custom embedded platform. One of module’s serial ports is connected to a GSM-Modem (AirPrime SL6087 from SIERRA).
NetOS’s PPP-Stack is initialized and bound to modem’s serial port. In the following debug-outputs (from serial-driver’s level) you can see the successful LCP/Auth/IPCP negotiation-phases.

CONNECT 115200
LCP Req ->1 MRU:1500 ACCM:0 MAGIC:0x0 PFC AaCFC Auth:0xc023
LCP Req <-0 MAGIC:0xc1065e39 AaCFC PFC
LCP ACK <-1 MRU:1500 ACCM:0 MAGIC:0x0 PFC AaCFC Auth:0xc023
LCP ACK ->0 MAGIC:0xc1065e39 AaCFC PFC
Auth Req <-0 ID:PW=:
Auth ACK ->0 ACK=Welcome!
IPCP Req ->1 IP:192.168.111.111
IPCP Req <-0 IP:0.0.0.0 Compr:0x2d:15:1
IPCP Rej <-1 IP:192.168.111.111
IPCP Rej ->0 Compr:0x2d:15:1
IPCP Req ->2
IPCP Req <-1 IP:0.0.0.0
IPCP ACK <-2
IPCP NAK ->1 IP:10.21.128.45
IPCP Req <-2 IP:10.21.128.45
IPCP ACK ->2 IP:10.21.128.45

After reaching PPP_LL_OPEN_COMPLETE, a static route to 141.44.0.0/16 is applied to NetOS’s network stack.

The given ping-command produces the following debug-outputs (from serial-driver’s level):

IP Proto:1 10.21.128.45 -> 141.44.1.2 len:84
IP Proto:1 141.44.1.2 -> 10.21.128.45 len:84
IP Proto:1 10.21.128.45 -> 141.44.1.2 len:84
IP Proto:1 141.44.1.2 -> 10.21.128.45 len:84
IP Proto:1 10.21.128.45 -> 141.44.1.2 len:84
IP Proto:1 141.44.1.2 -> 10.21.128.45 len:84
IP Proto:1 10.21.128.45 -> 141.44.1.2 len:84
IP Proto:1 141.44.1.2 -> 10.21.128.45 len:84

So frames are transmitted by PPP via serial Port and GSM-Modem to the destination. Also the reply is received in reverse order.
We have assured, that all received bytes are read from the device-interface /dev/com7 by the PPP-stack, but the ping-command failed in this case. It appears that the PPP-stack is not giving the received IP frame to the IP layer.
Another ping on the same system to an Ethernet-bounded IP-address is successful.

Has anybody a similar problem and can give us some suggestions?

Regards,
Matthias

2

Hello again,

it seems that I’ve found the problem:

The ACCM (Asynchronous Control Character Map) was not negotiated properly. I used NetOS’s default value (LCP_DEFAULT_ACCM = 0xffffffff). In the example implementation the value is not set, because it equals the comparison value. See the code snippet:

— snip —
/* set up asynchronous control character map option */
u32_option = LCP_WANT_ACCM;
if (u32_option != LCP_DEFAULT_ACCM)
{
errorCode = PPPSetOption(…)
— snap —

So the NetOS PPP-stack and the service provider’s stack used different default character maps. I forced the value setting and the problem was solved.

Regards,
Matthias.