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

[Andrew Pullin]

On 1/30/20 11:42 AM, Sylvain Rochet wrote:
> There are no ARP in PPP, but whatever, this configuration is correct.
Roger that. At the very least, ARP is enabled on the NetX equivalent of 
a netif on the PPP-only host.
But it must be inactive and not accomplishing anything.
> 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.

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

> > 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
> Here is the real problem, you need a route on Host3 telling that
> 10.0.0.2/32 is behind 10.0.200.136 (or 10.0.200.113). You can also add a
> route for 10.0.0.1/32 but it's just a bonus.
>
> Without this route, Host3 don't know how to route the packet and will
> try to find an host on the 10.0.0.0/16 subnet using ARP. Then it's just
> luck, and depends on what Host3 and Host2 are doing:
>
> - If the packet is sent in a broadcast Ethernet frame by Host3 it might
> works if Host2 catches the packet and forwards it to Host1.
>
> - If the ARP request gets answered by Host2 when Host3 send their ARP
> request to find who is 10.0.0.2 on the 10.0.0.0/16 subnet, then it also
> works. This is known as ARP Proxy, lwIP does not support that.
>
> It's just luck, using lazy features of IP stack to make it works even if
> the configuration is broken should be avoided :-)
Darn. I saw some code for "UNUSED - PROXY ARP", but it was all removed 
with #if 0 blocks.
> > 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 guess the only reason it works with WiFi and not with Ethernet is
> because WiFi is intrinsically broadcast-based while Ethernet is switched
> (well, I hope so, unless you live in '90s :p). This is the "works
> because Host2 catches the broadcast packet" case I've said before.
Wow. What a situation ... good to know there is a rational explanation 
as to why it worked with seemingly no network setup difference.
> > 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.
> This is not "connection sharing", this is IP routing, not NAT !,
> "connection sharing" is usually used for hosts that do SNAT on their
> Interface facing Internet.
>
> IP routing needs a complete routing table on all hosts telling how to
> reach (i.e. which next-hop to use) every host of the whole network.
>
> Example with 2 subnets and 3 Hosts:
>
> A-eth0  --------------------- eth0-B-eth1 --------------------- eth0-C
>    192.168.0.1/24    192.168.0.2/24   172.16.1.1/24     172.16.1.2/24
>
> Host A routing table:
> 192.168.0.0/24 dev eth0
> 172.16.1.0/24 via 192.168.0.2
>
> Host B routing table:
> 192.168.0.0/24 dev eth0
> 172.16.1.0/24 dev eth1
>
> Host C routing table:
> 192.168.0.0/24 via 172.16.1.1
> 172.16.1.0/24 dev eth0
>
> dev = directly connected
> via = next-hop, gateway if you prefer
>
> What you could see is that each host have a similar routing table, just
> the next-hop changes. Default route is just a way to reduce the routing
> table size by removing all entries that have an identical next-hop.

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.

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?

Thanks,
Andrew Pullin