[mythtv-users] directly connecting HDHR to spare LAN port

[Stephen Worthington]

On Tue, 14 Jun 2022 10:31:23 +0200, you wrote:

>Hoi Stephen,
>
>Tuesday, June 14, 2022, 6:04:00 AM, you wrote:
>
>> On Mon, 13 Jun 2022 15:05:53 -0400, you wrote:
>
>>>I have a NUC with  2 RJ45 ports on the back. One is 2.5Gb and the other is
>>>1Gb.  Is there a simple way to connect a HDHomeRun Connect tuner to one of
>>>these ports so it would work with Mythtv and eliminate any record problems
>>>that I'm having from being network related??
>>>
>>>Jim A
>
>> Just assign a static IP address to the Ethernet port you want the HDHR
>> to connect on, and set up a DHCP server on that port which assigns IP
>> addresses on the same subnet as the static IP.  So, if your main
>> subnet is using say 192.168.10.0/24 as the address range, you might
>> choose to use 192.168.11.0/24 for the new subnet.  The static IP
>> address for the port on the NUC might be 192.168.11.254 and the DHCP
>> assigned addresses 192.168.11.1-192.168.11.249.
>
>> Make sure that the subnet addresses you choose are not used anywhere
>> else on your network.  It pays to document all the subnets on your
>> network somewhere so you do not in the future re-use addresses.  I do
>> this in my DNS server config files, but a simple text file is fine, as
>> long as you can remember where it is.
>
>> If you need access to the HDHR from elsewhere on your network, then
>> you will likely need to be able to tell your router to add a route to
>> the new subnet via the NUC's main IP address.  Not all consumer level
>> routers can actually do this.  Or if your router can do RIP or OSPF
>> routing protocols (unlikely in a consumer grade router), it is better
>> to set up RIP or (preferably) OSPF on the NUC and let the routes be
>> handled automatically.  In Ubuntu, the normal software used for this
>> is Quagga, which has subprograms it runs for each of the various
>> routing protocols.
>
>> For Ubuntu, this looks like a decent guide to setting up a DHCP
>> server:
>
>> https://www.linuxfordevices.com/tutorials/ubuntu/dhcp-server-on-ubuntu
>
>For routing through the NUC being possible you have to enable routing
>by its kernel.
>It either has a file /etc/sysctl.conf or a directory /etc/sysctl.d
>with zero or more conf files. Here you can set kernel parameters.
>I have set:
>
>net.ipv4.ip_forward = 1
>net.ipv4.conf.default.rp_fiter = 1
>net.ipv4.conf.all.rp_filter = 1
>
>which together with the router settings mentioned by Stephen makes my
>hdhr4 accessible from elsewhere on my network. To use the hdhr tools
>replace the id with the ip. 
>
>Tot mails,
>  Hika                            mailto:hikavdh at gmail.com

Those net.ipv4 options are not sufficient to make the HDHR address
routeable from the rest of the network.  The "net.ipv4.ip_forward=1"
option is necessary to allow packets to be routed through the NUC
between the two Ethernet ports.  It is likely already on by default.
The "rp_filter" options are to control reverse path filtering, to
prevent spoofed packets with invalid source addresses from being
accepted by the NUC.  I think the default for those settings is 2
which means that if a packet is received on an interface, it will be
accepted if the source address is reachable on any interface on the
device.  Setting them to 1 causes packets to be accepted only if the
source address is reachable from the interface it arrived on, which is
a bit more secure, but can cause problems on more complex networks
with asymmetrical routing (where packets can arrive over more than one
path).  In a simple network like Jim's, either 1 or 2 is fine, and if
it is already defaulted to 2, I would just leave it set to that.

Those net.ipv4 options only affect routing within the device (the NUC
in this case) - in order for the rest of the network to know that the
NUC has a subnet available on another port than the one connected to
the main network, there needs to be routing information available to
the other devices on the network, or for the main network router to be
know the new subnet exists, even if all the other devices do not. That
requires a routing table entry on the router, and for best efficiency,
also on all devices.

Using the example subnets of 192.168.10.0/24 for the main subnet and
192.168.11.0/24 for the new HDHR subnet, lets say that the main router
is on address 192.168.10.254, the NUC is on 192.168.10.12, the HDHR is
on 192.178.11.1 and a device wanting to access the HDHR is on
192.168.10.35.  If 192.168.10.35 wants to send a packet to the HDHR on
192.168.11.1, it will look up its routing table to see the best match.
If it happens to be running OSPF or RIP and has received the
information about the new subnet from the NUC, then its routing table
will have an entry saying that to send packets to 192.168.11.0/24, it
should send them to the NUC on 192.168.10.12.  If it does not have
that entry, the packet it is sending will only match to its default
route, which will point to the main router, so it will send the packet
to the main router on 192.168.10.254.  The main router will then look
up its routing table, and find that it has a route saying that the
192.168.11.0/24 packets are to be sent to the NUC on 192.168.10.12 and
it will do that.  But if the main router does not have that routing
table entry (either as a manually set up static route, or via OSPF or
RIP), it will only match the packet with its default route, and try to
send it over its WAN port to the wider Internet, which is not where
the packet should go.  And the firewall rules on the WAN port will see
a packet with a 192.168.0.0/16 destination address and drop the packet
as that address block is not routeable over the Internet.  So the
packet will never get to the NUC to be routed on to the HDHR.