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

[Sylvain Rochet]

Hi Andrew,

On Fri, Jan 31, 2020 at 12:11:56AM -0800, Andrew Pullin wrote:
> On 1/30/20 11:42 AM, Sylvain Rochet wrote:
> > 
> > 10.0.0.1/32 and 10.0.0.2/32 are within 10.0.0.0/16 subnet, that
> > shouldn't be a problem here, this is usually a bad practice and it
> > should be avoided. This is a problem for hosts on 10.0.0.0/16 that don't
> > know there is a hole in the subnet, since there are only 3 hosts here,
> > which is an expection rather than the rule, it is safe by luck.
> 
> This seems relatively easy to fix: I can just change the PPP-negotiated IP's
> to 11.0.0.0/32, so the host1 and host2 devices are on a different subnet on
> the PPP side.

11.0.0.0/32 is outside RFC1918 private subnets, using it sounds like a 
bad idea.


> As for the /32, I am unsure if I need to change that. Do I?

The netmask is only meaningful for layer 2 with a broadcast domain (e.g. 
Ethernet), PPP is point to point, there is only one peer, netmask as no 
meaning.

(To be fair that's not entirely true, it use to be used for PPP to 
provide more than one IPv4 addresses to customers, but I don't think 
it's still used in the wild, and it's still not a broadcast domain, it's 
just a pool of addresses.)


> Darn. I saw some code for "UNUSED - PROXY ARP", but it was all removed with
> #if 0 blocks.

You are lost in the wrong place ;-), ARP Proxy support have to live in 
the Ethernet ARP driver, and that support does not exist. What you saw 
is just PPP support to add a Proxy ARP rule into the Ethernet driver 
(basically no more than one function call :-), it is not the ARP Proxy 
support.


> Here is where I am starting to get worried about how I am possibly going
> make this solution work.
> I am trying to, in general, get my host1 device connected to the outside
> world via host2's connection to host3.
> 
> The motivation for doing this via IP stacks is because my host1 (PPP client)
> already has a ton of code implemented using TCP/IP; host1 is a piece of
> hardware that used to have its own MAC/PHY, but is now being repurposed.
> Being able to re-use all of that code without having to remap every function
> at a high-level to some other mechanism (say, AT commands, also needing
> host2 implementations) will be a huge boon.
> 
> My knowledge here is clearly limited, but is there a general or dynamic way
> to set up the routes I would need here?
> 
> Since I want to be able to attach host2 to any existing network and have
> this system work, I think this is what I would need.
> 
> I do not know how host2/B could pass the information needed to host1/A to
> configure the next hop route, or "172.16.1.0/24 via 192.168.0.2" in your
> example. This seems like it would require a mechanism for host2/B to
> disclose to host1/A what IP address it gets (say, via DHCP) on it's eth0
> side.

It exists… it's called OSPF… but… erm… don't expect that to be available 
behind a set-top box or whatever "gateway/router" used by ISP.

I'm running OSPF at home but I'm not the regular ISP customer :-)


> Or how host3/C could be configured for routing a subnet (now 
> 11.0.0.0/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 "11.0.0.0/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 
> NAT?

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 
same address.

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
<---TCP1---------------->   <---TCP2--------------------------->

TCP1:
src: 192.168.0.1
dst: 192.168.0.2
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):
src: 10.0.200.113
dst: 192.0.2.1


Sylvain

signature.asc
Description: Digital signature