I’m attempting to build a PPP driver for +TCP, I have it at the point of IP packets, the LCP and IPCP layers have completed.

I’m probably missing some concepts, feel free to enlighten me.

Anyway, ARP isn’t really applicable to PPP links, but ARP seems to have to initial resolve before anything can happen. Any suggestions how to bypass or make this work?

I think I’ll have to fiddle with ethernet headers to make this work too.

Guess I’ll answer myself.

It looks like the best method is to write an ARP proxy, basically intercept and reply to ARP packets. In this case, I set mac addresses for a gateway and local IP, then set the gateway IP to, then intercept any gateway IP ARP requests and return the correct MAC. For this to work correctly
otherwise it won’t store in the arp table, and the cache never hits.

As I understand you are trying to implement PPP over Ethernet (PPPoE).
PPP is a layer 2 protocol which essentially means that this need a routing table entry to be present.
In usual TCP/UDP communication the routing table entry is being populated using ARP.
In case of PPP, the source and destination will be fixed and a routing table entry can be created during the PPP socket init. The only limitation in this method is that the remote IP and MAC will have to be pre-known.
A usual practice followed by systems using PPoE together with other protocols is to use a 5 tuple based routing table (Local-IP/Local-Mac/Remote-IP/Remote-Mac/Protocol). This way a normal ARP can be used to populate the routing table , just that the protocol field will be PPPoE.

This is PPP over serial, using a cellular modem.

In this case, ARP serves no useful purpose, it would be best if all traffic could just be treated like remote traffic.

Some type of switch maybe, like
ipconfigARP_DISABLE = 1
and it would use some default gateway mac for all outbound frames.

I think PPP is useful, its a more standard way of communicating with LTE modems and one can use standard freertos TCP api.

Yes I agree, ARP serves no purpose. But, a routing table entry is still needed for all routing needs. Hence, the first method that I had suggested can be used, where an entry can be added directly to the routing table.

Just to add , the procedure is called proxyARP where we manually create a routing table entry. However, this can be avoided altogether if we do not want to support routing or differentiate between different types of traffic.

Is this a FreeRTOS function? I’m not seeing this anywhere.

proxyARP is not yet supported in FreeRTOS-plus-TCP stack.
I was suggesting that you can implement the same for PPP functionality.