I've been working on a PPP<->ethernet bridge with STM32H7 and lwip 2.2.x.
I hit a couple of bugs that I have submitted patches for:
The first one is fairly clear I think, and was just missing handling of header reservation for VJ compression. It meant that quite a few packets were lost when space for the ethernet header couldn't be added on forward from PPP -> ethernet.
The 2nd was a puzzle to me. The patch I've done makes it work and stops us getting zero checksums out for forwarded IP packets, but I do wonder if we should just remove that whole block of code. The remaining code will only trigger if the interface supports hardware checksumming, but what is the advantage of zeroing the checksums even in that case? It just seems to be adding code for no reason. I've left it in for my patch as I don't have any hardware with checksumming support to test, but I can re-submit with a patch to just remove the whole block if someone can confirm the zeroing is indeed pointless.
The final patch is to allow for proxyarp, which really is extremely useful in a PPP<->ethernet bridge. The current proxyarp code in lwip ppp is commented out and I think it is much more complex than it needs to be anyway. The patch I've done puts the responsibility on the ethernet interface by adding netif_add_proxyarp(). That takes a bit more work in the application code to setup, but is much simpler inside lwip.
proxyarp patch here:
The only other issue I hit is in the routing code. The code always selects the first interface that matches, but if you add the ethernet interface first then you will never route to the PPP interface.
For now I've used this extremely ugly hack in my application code:
extern struct netif *netif_list;
LWIP_TCPIP_LOCK();
if (netif_list != nullptr &&
netif_list->next != nullptr &&
netif_list->next->next == pppif) {
netif_list->next->next = nullptr;
pppif->next = netif_list;
netif_list = pppif;
}
LWIP_TCPIP_UNLOCK();
that just re-orders the interfaces so the PPP interface is found before the ethernet interface. I'm curious if someone has a better solution. Maybe we need a function which sorts the interfaces with most specific mask before less specific masks?
Cheers, Tridge