Hi,

    I am trying to use a raspberry pi (3B running gentoo 32bit, openrc)
to create a routed link between two access points (the rpi acting as a
client to both AP's) so I can access the monitoring port (6607, modbus)
from homeassistant.  One AP is an Huawei inverter with a built in
"island" access point that sets a default route to itself on clients via dhcp.  I have a normal gentoo based Access Point for the house that also
sets a default route via dhcp.  What I need is a single default route to
my home network via the rpi from the Huawei inverter.

Both AP's connect ok from the rpi but the routing is wrong - I can ping
in both directions from the rpi, but only sometimes from devices further
hops away - can openrc even do this?  My experimenting so far is hit and miss.  Trying to static route or override the default routes doesn't
survive a network glitch, and half the time doesn't seem to "take" at all.

A working example I could adapt would be great!

BillK

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/31/22 7:21 AM, William Kenworthy wrote:

Hi,

Hi,

I am trying to use a raspberry pi ... to create a routed link
between two access points ... so I can access the monitoring port ...
from homeassistant.

I'm distilling this down to a Gentoo system participating in two two
LANs, both of which are connected as DHCP clients. -- Correct me if
I've distilled too much. -- And you want other systems on either LAN
to use this system as a communications path to systems on the opposing LAN.

Both AP's connect ok from the rpi but the routing is wrong - I can
ping in both directions from the rpi, but only sometimes from devices
further hops away - can openrc even do this?

This seems like a classic routing issue. To me, it's not even an OpenRC
issue in any way other than how to add static routes /after/ the network
is brought up via DHCP.

My experimenting so far is hit and miss. Trying to static route
or override the default routes doesn't survive a network glitch,
and half the time doesn't seem to "take" at all.

Ya. At a higher level, this can be non-obvious how to do this as it's
niche routing configuration.

A working example I could adapt would be great!

I don't have an example off hand. -- Seeing as I use static IPs on
almost all of my machines, I don't even know if OpenRC supports adding a
static route /after/ bringing an interface up with DHCP.

I do know that the DHCP protocol supports adding additional options / definitions / parameters (?term?) to specify -- what I've been
describing as -- static routes. That way DHCP clients will learn about
these additional routes and install them in their local routing table.
Though I don't know if you will have the necessary control over /both/
DHCP servers that's needed to do this.

Presuming that you don't have control over /both/ DHCP servers (as
control over /both/ will be needed), I'm going to fall back and suggest
what I call the "Customer Interface Router".

Specifically, set up port forwarding on the Pi such that when clients on
LAN1 connect to $PORT on the Pi, the traffic is DNATed to the
HomeAssistant on LAN2 /and/ the traffic is SNATed to the LAN2 interface
on the Pi. Thus every system on each LAN thinks that it's talking to a directly attached system in the same LAN. There is no need for routing
in this case.

I typically only use the C.I.R. when there are reasons that more proper
routing can't be configured. The C.I.R. is an abstraction layer that
allows either side to operate almost completely independently of each
other, save for IP conflicts between each directly attached LAN.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/31/22 10:17 AM, Grant Taylor wrote:

I do know that the DHCP protocol supports adding additional options / definitions / parameters (?term?) to specify ... static routes.

In case others are interested in this, a few pointers about using it.

ISC's DHCP server has two options for advertising routes that clients
should install;

subnet ... netmask ... {
...
option cidr-static-route ...;
...
ms-static-route ...;
...
}

Both *-static-route options use the same format and the format took a
little bit to wrap my head around. It consists of sets of <netmask
length>, followed by the <network bits>, followed by the router. E.g.

option cidr-static-route 10, 100, 64, 192, 0, 2, 123, 0, 192, 0, 2, 1;

That says:

- 100.64.0.0/10 is reachable via 192.0.2.123
- 0/0 is reachable via 192.0.2.1

ProTip: Go ahead and add the default gateway 0/0 route to the
*-static-route entries as some clients ignore the option routers entry
when *-static-route option is present.

I have multiple macOS, iOS, Windows 10, Linux, and other esoteric things correctly using a route to a lab / sandbox subnet via a system that
isn't the LAN's default gateway.

Finally: This seems to be a well defined DHCP standard, but seemingly
not well known option by the various people that I've discussed this with.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks for the detailed reply - my response is inline:

On 1/4/22 00:17, Grant Taylor wrote:

On 3/31/22 7:21 AM, William Kenworthy wrote:

Hi,

Hi,

I am trying to use a raspberry pi ...  to create a routed link
between two access points ...  so I can access the monitoring port
... from homeassistant.

I'm distilling this down to a Gentoo system participating in two two
LANs, both of which are connected as DHCP clients.  --  Correct me if
I've distilled too much.  --  And you want other systems on either LAN
to use this system as a communications path to systems on the opposing
LAN.

Correct, though I only need systems on the home network side (from at
least two VLANs) to access through the rpi - this device, as well as
some other "untrusted", cloud devices are on their own VLAN) - the
inverter is an island and I need to access just that one port.

Both AP's connect ok from the rpi but the routing is wrong - I can
ping in both directions from the rpi, but only sometimes from devices
further hops away - can openrc even do this?

This seems like a classic routing issue.  To me, it's not even an
OpenRC issue in any way other than how to add static routes /after/
the network is brought up via DHCP.

Agree - I would describe it as a two gateway and related routing issues
with something resetting/re-configuring of the routing tables into a nonsensical state when I try and manually manipulate them.

I did forget to mention I use ospfd (frr) to propagate routes (a
complex, multi VLAN network) which works fine - its openrc setting the
wrong routes on the rpi which then get propagated - thats not central to
this issue though. 

My experimenting so far is hit and miss.  Trying to static route or
override the default routes doesn't survive a network glitch, and
half the time doesn't seem to "take" at all.

Ya.  At a higher level, this can be non-obvious how to do this as it's
niche routing configuration.

A working example I could adapt would be great!

I don't have an example off hand.  --  Seeing as I use static IPs on
almost all of my machines, I don't even know if OpenRC supports adding
a static route /after/ bringing an interface up with DHCP.

It does, but its either set the network configuration manually which
kept getting extra routes added - in particular the inverter sends the
gateway which dhcpd adds then I have to delete ... and gets undone at
the next network glitch (hostile wifi environment plus weak signal).

I do know that the DHCP protocol supports adding additional options / definitions / parameters (?term?) to specify -- what I've been
describing as -- static routes.  That way DHCP clients will learn
about these additional routes and install them in their local routing
table. Though I don't know if you will have the necessary control over
/both/ DHCP servers that's needed to do this.

Unfortunately, the inverter is a black box :(

Presuming that you don't have control over /both/ DHCP servers (as
control over /both/ will be needed), I'm going to fall back and
suggest what I call the "Customer Interface Router".

I cant control the inverter network. 

Specifically, set up port forwarding on the Pi such that when clients
on LAN1 connect to $PORT on the Pi, the traffic is DNATed to the HomeAssistant on LAN2 /and/ the traffic is SNATed to the LAN2
interface on the Pi.  Thus every system on each LAN thinks that it's
talking to a directly attached system in the same LAN.  There is no
need for routing in this case.

I have not tried this as I thought it would also run into the two
default gateway issue ... I'll try this next!

I typically only use the C.I.R. when there are reasons that more
proper routing can't be configured.  The C.I.R. is an abstraction
layer that allows either side to operate almost completely
independently of each other, save for IP conflicts between each
directly attached LAN.

I have now been given api credentials but they don't say if it runs on
the inverter or a remote site ... more reading! At this stage all I need
is simple monitoring that I can process using software.

Thanks,

BillK






--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)