After reading some documentation asking question specialist and searching i found that this is the expected behavior with cellular modems, most of them are not negotiating an IP interface for their side, IPCP RFC is permissive and does not disallow doing so from what I remember. As you can see in the
trace it is only a notification that we are using a dummy address because the peer did not provide one, it can then be safely ignored.
The thing is, PPP are non-broadcast interface type, there is only one single peer, as such we do not need to discover the data link address of the next hop IP router, therefore we don’t need the other side IP address to forward IP packets to the peer.
If you look at how PPP netif interface input and output are wired in lwIP (ppp_input() in low level PPP drivers and output callbacks in ppp_netif_init_cb()), you will see that we don’t need any data link resolution protocol, the network layer is wired straight to the PPP interface.
On the modem side, the PPP session is coupled to the cellular PDP session at the data link layer, it is either piggy backed on a previously existing PDP session or to a new one when PPP starts. PDP is non-broadcast as well so it does not need a data link discovery protocol
on the bridge.
Then the log that we see in the trace is the expected behavior.
Someone has an idea how to added web-sockets layer to lwip ppp (SAM4E device -> TCP/IP stack (lwip) -> PPP(lwip) -> serial (lwip))-> websockets)
–
Said