Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another

[Sylvain Rochet]

Hi Andrew,

On Tue, Jan 28, 2020 at 04:57:19PM -0800, Andrew Pullin wrote:
> Hi folks,
> 
> I am stuck on an issue here where I am trying to use lwip's IP_FORWARDING
> feature.
> I am trying to forward packets between a PPP server netif and a WAN
> interface. It is working on case, where the WAN-connected device is using
> WiFi, but then it fails to work in another case where the WAN device is
> configured to use an Ethernet interface.
> 
> This is to ultimately bring Ethernet connectivity to a device without
> Ethernet, but which can act as a PPP client (via UART).
> Lwip is running on a device with Ethernet and using the lwip PPP server
> implementation.
> 
> I have read the other threads involving PPP and forwarding, but I don't
> believe I have seen quite this same problem arise.
> 
> Here is how the devices are arranged for each case:
> 
> Working:
>    10.0.0.2 ------[UART]----------> 10.0.0.1 ------------------> 
> 10.0.200.121 ----------> 10.0.1.1 ---> WAN
> (PPP client)                    (PPP server, ESP32, lwip) (WiFi STA netif) 
>              ( router )
> 
> In this case, the WiFi netif reports the gateway IP correctly (10.0.1.1) and
> the netmask as 255.255.0.0
> 
> Not working:
>    10.0.0.2 ------[UART]----------> 10.0.0.1 ------------------> 
> 10.0.200.113 ----------> 10.0.1.1 ---> WAN
> (PPP client)                   (PPP server, ESP32, lwip)           
> (Ethernet netif)               ( router )
> 
> In this case, the Ethernet netif reports the gateway IP correctly (10.0.1.1)
> and the netmask as 255.255.0.0 , which appears to be the same as for the
> working WiFi netif case.
> 
> The addresses 10.0.0.1 and 10.0.0.2 on each side of the PPP are manually
> configured. They are hardcoded into the PPP server setup, and the client
> appears to be able to take it's 10.0.0.2 address via IPCP over PPP.
> 
> 
> To test that the WAN connection "works" for the PPP client, I am issuing
> pings from PPP client device.
> In the "working" case, I can ping 10.0.0.1, 10.0.1.1 (network gateway), and
> 8.8.8.8. All work.
> In the "not working" case on ethernet, I can ping 10.0.0.1 (just over the
> PPP link), but 10.0.1.1 and 8.8.8.8 appear unreachable.
> 
> Of course, I am building with IP_FORWARD defined to 1. Debug logs do reflect
> that forwarding is happening.
> There are several shims in the Espressif SDK over the actual lwip netif
> sets/calls.
> As far as I can see, the same setup is done for the ethernet netif as is for
> the wifi netif, but this is an obviously suspicious point.
> 
> In my case, I am using an ESP32 chip, and all of the lwip init and setup is
> done for me in the SDK.
> As far as I can see, the init for each adapter/netif type looks the same.
> 
> I have logs for each case, too:
> Working (wifi netif) - https://pastebin.com/RgqHa5CR
> Not working (ethernet netif) - https://pastebin.com/L80raiRF
> 
> One note here is: the PPP client is not running lwip. For hardware & legacy
> reasons, it is running another network stack with a totally different PPP
> client implementation.
> But, given that the working/not working is a function of the PPP server
> netif's, I did not suspect a mis-configuration issue in the PPP client.
> 
> Any insight here would be greatly appreciated. I am not too familiar with
> the deep under-the-hood details of network stacks.

I tried to understand but I failed. Before anything else, could you 
share the real network configuration of all network interfaces, the 
routing table on all hosts, and any speciafic features enabled on each 
interface (NAT, ARP-Proxy, …), for all configurations you tried ?

Example:

[Host1]ppp0 --- ppp0[Host2]eth0 --- eth0[Host3]eth1 --- Internet

Host1:
  running a PPP client, that's all we know
  ppp0: 10.0.0.2/32
  default route: ppp0
  no other route

Host2:
  running lwIP
  ppp0: 10.0.0.1/32
  eth0: 10.0.200.121/16
  default route: 10.0.1.1
  no other route

Host3:
  gateway ? to what ?
  eth0: 10.0.1.1/16
  eth1: public IPv4, facing Internet, set by DHCP, SNAT
  default route: set by DHCP, toward eth1
  no other route

Hint: the configuration above can't work, but I'm not sure this is what 
you currently have...

Sylvain

signature.asc
Description: Digital signature