[mythtv-users] directly connecting HDHR to spare LAN port
Hika van den Hoven
hikavdh at gmail.com
Tue Jun 14 15:14:47 UTC 2022
Tuesday, June 14, 2022, 4:17:25 PM, you wrote:
> On Tue, 14 Jun 2022 10:31:23 +0200, you wrote:
>>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??
>>> 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
>>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.
>> 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 188.8.131.52 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.
If you want to check the current kernel parameters, you can check them
in /proc/sys/ followed by the parameter name with the dots replaced by
"/". Use the cat command to read a current value. You can change then
ad-hoc with the echo command. Setting it that way it will only last
till the next reboot.
Gives on my Gentoo system with self-build kernel 0 by default, as do
the other two.
Any build with a secured kernel will have routing disabled by default.
Hika mailto:hikavdh at gmail.com
"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"
De lerende Mens
More information about the mythtv-users