[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] IP forwarding to/from PPP working for one netif, but no
Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another
Tue, 11 Feb 2020 01:20:35 -0800
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2
On 1/31/2020 4:48 PM, Sylvain Rochet wrote:
Or how host3/C could be configured for routing a subnet (now
184.108.40.206/32) that is essentially "private" between host2/B and
host1/A. That is the "192.168.0.0/24 via 172.16.1.1" route in your
example, or "220.127.116.11/32 via 10.0.0.016" in my case.
It seems like what I actually do want is NAT capability on host2, so
that the host1<->host2 connection would be abstracted away. But it
looks like there are only a few few-years-old implementations of NAT
for lwip. Uh oh. I would really like to avoid trying to integrate that
in from an old branch of lwip.
Any idea if I can get this to work without needing to try to bring up
It it were me and if I don't need Host2 to reach "outside" and Host1
software can't be changed, I would just write a big hack to forward
relevant packets (e.g. no DHCP, no ARP, IP) to the PPP link, pushing the
DHCP assigned address to the PPP peer Host1 so NAT is not necessary at
all and nothing have to be done for Host1 to send packets to "outside".
And if it were me and if I need Host2 to reach "outside" and Host1
software can't be changed, I would write a quick'n'dirty ARP Proxy
support, probably at the Ethernet low level driver. Note, in this case,
it is normal for the PPP link to be within the Host2/Host3 subnet, it is
actually mandatory. But doing so won't work if you need DHCP support
because you need DHCP server to offer two addresses (one for Host2, one
for Host1), so you need two MAC addresses and two DHCP clients running.
It's way more difficult than just hacking the forwarding and sharing the
But, above all, if it were me, I would just write a TCP or UDP proxy on
Host2. Host1 would then only establish TCP or UDP sessions to Host2 with
a home made proxy protocol (basically packets with two destination IP
fields), and Host2 would create the real session to the outside world.
Host1 ----------------- Host2 ------------ Host3 ------ Internet
192.168.0.1 192.168.0.2 10.0.200.113 192.0.2.1
real-dst: 192.0.2.1 (in TCP payload, e.g. at the
beginning of the TCP session)
TCP2 (created on the fly using payload hidden real-dst):
Wow, thanks for all the good ideas.
I can mostly change the code on both Host1 and Host2 here, but I am
really trying to do this with minimal changes to the upper layers,
especially on Host1. As described: end up with a transparently "working"
internet connection there.
The ARP proxy case is fascinating. Since Host1 used to be a fully
internet connected device, it has everything it would need, i.e. a DHCP
client, DNS client, etc. If I could make Host2 appear to represent two
devices with two valid (IEEE registered) MAC addresses and the network
operator was OK with two DHCP clients existing in one physical box, that
seems like a good solution.
But: modifying the low-level ethernet driver seem daunting.
The TCP proxy case also seems quite interesting, since it should be all
app layer code, and only need a TCP listener and TCP client.
Alas, we also need UDP for DNS. For TCP, it would be easy enough to
start the stream with the target IP:port and a verifier, but for UDP,
the datragram would have to be dissected, deal with the IP
But here's the good news: I found a patch to add NAPT functionality to
lwip, I am sure it has been linked to somewhere in this mailing list before:
Seems pretty interesting, and it seems like it is almost working, too.
This would be a great solution, since then I can run a private static IP
subnet between Host1 <-> Host2, and to the upstream router, it should
just look like a single device Host2 (other than NAT detection via TTL
or other methods).
The part that I am stuck on presently is that Host2 has no knowledge of
how to route packets from PPP out to the WAN, say, 18.104.22.168.
Between ip4_forward, IP_FORWARD, ip4_route_src, LWIP_HOOK_IP4_ROUTE,
LWIP_HOOK_IP4_ROUTE_SRC, and the ESP32 port modifications, I am not
quite sure where to make the right intervention. It is ... a lot to take in.
As far as I understand the standard usage of the stack for a single
netif, outgoing packets elide the entire forwarding/routing system
because they are specified to be transmitted on a particular netif? Is
Fundamentally, I only have eth0 and pp1 (to use the lwip netif naming
system) and anything not specifically with IP dest = eth0 or pp1 should
be sent on towards Host2's gateway (after NAT source address IP rewriting).
Is that logically complete, and if so, where should it be implemented?
- Re: [lwip-users] IP forwarding to/from PPP working for one netif, but not another,
Andrew Pullin <=