On 1/29/20 5:42 AM, Sylvain Rochet wrote:
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
Uh-oh, I think I did a poor job of explaining it. Although you seem to
have surmised most of it.
The full rundown:
Host1:
- Micontroller device with no MAC or PHY
- running NetX IP stack
- Runs a PPP client, specifically PPPoS using TTL UART
- default route: ppp0
- ppp0 is the only network interface available
- ARP is supported and enabled
- IP 10.0.0.2 is assigned during PPP negotiation
Host2:
- Micontroller device, ESP32
- has both WiFi and Ethernet PHY hardware (IP101GRI Ethernet PHY),
used mutually exclusively
- Running lwIP
- WiFi and Ethernet are independently verified to work to reach
WAN from this host
- PPPoS server
- ppp0 : 10.0.0.1/32
- IP for server and client are hard-coded in
- I believe it is /32, as the netmask is reported as
255.255.255.255
- When running w/ WiFi:
- wlan0 : ip 10.0.200.136/16 (IP and /16 from DHCP server)
- When running w/ Ethernet:
- eth0 : ip 10.0.200.113/16 (IP and /16 from DHCP server)
- Routing is unknown. lwIP built with IP_FORWARD enabled.
- default route: wlan0 or eth0 (assumed)
- ARP is enabled.
WiFi AP's:
- AP only (no routing)
- Connected to Host3 by Ethernet
- MACs 0c:8d:db:6e:f0:03 or 0c:8d:db:6e:f0:88 (can't control
association)
Host3:
- Router (pfSense)
- DHCP server runs here
- Routes to WAN, does NAT, eth0 <-> eth1
- default route: set by DHCP, toward eth1
- no other route (as far as I know)
- Intranet WiFi AP's are connected via switch to eth0
- Intranet Ethernet devices are connected via switch to eth0
- eth0 : 10.0.1.1/16 , facing intranet, MAC 00:e0:67:18:54:95
- eth1 : IP from ISP, facing public IPv4 internet, MAC
00:e0:67:18:54:94
Layout:
Host1 <-----------------> Host2 <-------------------------> Host3
<---------> public internet
PPPoS Ethernet
or
Host1 <-----------------> Host2 <----------------> WiFi AP
<------------------> Host3 <-------> public internet
PPPoS WiFi Ethernet
For the case of using the WiFi connection, there are separate WiFi
AP's in the way.
Other than that, the two cases are host2 connecting to the local
subnet via wlan0 or connecting via eth0.
I am not manually adding any static routes in either Host1 or Host2.
I was worried that Host2 would not be able to accomplish the
"connection sharing" until I found the IP_FORWARDING option. That
initially worked with Host2 using WiFi without any manually added
static routes.
Unless I am missing something being changed in the config, that is the
config both both the case of Host2 using wlan0 and for using eth0. The
only change I can observe is that host2 IP is given a different IP by
host3 DHCP.
Very interesting that you already see something wrong ... that means I
am likely missing something obvious. I certainly hope it is something
simple to tweak to make this work over host2's eth0!
Unfortunately, I have no ability to do debug on the ESP32, so I cannot
check how the stack is really behaving when checking if anything needs
to be forward.
Using the ETHARP_TRUST option does not appear to have an effect, either.
I did not enable Proxy ARP in either case, and it doesn't look like
the drivers around netif enable it, either.
As far as I know, NAT is only running in Host3, which is the router
between the whole subnet and the public internet.
I regenerated the logs with ARP logging and with relative timestamps,
in case that helps:
Host2 using wlan0, host1 is able to ping 8.8.8.8 and 10.0.1.1 :
https://pastebin.com/GJkSsPbb
Host2 using eth0, host1 is not able to ping 8.8.8.8 and 10.0.1.1 :
https://pastebin.com/riE345HN
The help is really appreciated.
Thanks,
Andrew Pullin
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users