OSMC should honor DHCP option classless-static-route

In a non-flat network it is imperative to use existing mechanisms for coherently distribution network configuration to the nodes.

Static routes for internal networks come in handy if using e.g. OpenVPN on machines and still wanting to access services in other internal networks.

Static routes are best distributed using DHCP, eg. option 121 (classless-static-route).

macOS honors this option, Linux does, even Windows!

Osmc should be no exception to this!
Sure, it is possible to make a local configuration, even using the openvpn config file. That is not the point here. This file would need to be updated every time when the Osmc box is moved to a different internal network. That is not suitable and not the response I am looking for.

Why not just use a dhcp client that honors the pertinent options?

This is better raised with the ConnMan developers to see if something is missing there.

That is extremely vague. There isn’t a unified network management solution for Linux and won’t be for the foreseeable future.

If you wish to install a different DHCP client you can do so, but it’s not something we would directly support.

I am an OSMC customer, I just care about the functionality. How it gets there?

Maybe you raise it with the ConnMan team? Or you replace ConnMan with something else?
Thats your decision.

Still, the functionality is requested for OSMC, because that is where I would like it.
Thank you for understanding.

If there’s sufficient demand for this feature, I will look in to how we can implement it.

Our goal is to provide enough networking for domestic use cases. For more complex scenarios, you could configure this yourself, but it would be out of our remit. The simplest solution would likely be to install dhclient

understood. thanks for considering the request.

A way to implement this is to have the router that has the default route know about all the static routes and have it reflect them back to clients. This causes only a tiny delay, as only the first packet destined for a subnet is delayed…after that, the client adds the route to their routing table and will send directly to the gateway for that subnet.

1 Like

How exactly would you implement that using OpenWRT LUCI ?

Well half way there. Thats UCI, not LUCI :slight_smile: Would OpenWRT announce those routes to the subnets automatically?

Hi,

Well yes and no, as @nabsltd says there will be a tiny delay. Essentially when a devices trys to connect to a device on another a network, it goes to router as normally. The router then looks at its routing table and passes the static route the devices to allow the connection as needed, the devices should add these to there static routing table (until reboot). At least this is how I believe it works, more of a sys admin, than a network guy.

Thanks Tom.

Well not sure why I would need to configure the static routes, as there are already implicit routes per each subnet interface. Why would the router not announce those? Just asking, I really don’t know.

Hi,

I think that’s something openwrt devs need to answer.

Thanks Tom.

Routes aren’t announced based on the network connected to the NIC to allow the router to not pass traffic universally.

In other words, a router with 3 NICs might allow traffic from NIC A (e.g., the LAN) to NIC W (the WAN) and from NIC B (e.g., a DMZ) to NIC W, but never allow routing from NIC B to NIC A.

Because the rules for what traffic is to be allowed to pass from/to a pair of NICs could be very complicated, the routes to reflect back to a sender are manually listed somewhere. I don’t actually know how to do this on OpenWRT, so I can’t help with that.

1 Like

With a LAN that is well segmented into a number A of VLANs that would make A*(-1) static routes. With A over 4 thats just insane.

Hi,

That’s how vLans should work, the whole point its to segment and isolate the traffic, its manual intervention that allows communication between the vlans.

Thanks

1 Like

The whole purpose of VLANs is to allow you to segment hardware switches so that they can be used for more than one collision domain. For example, this allows you to buy one 48-port switch that fits in 1/4 the rack space of four 12-port switches but still have 4 different collision/broadcast networks.

If you want to have traffic move between different VLAN segments in a controlled way, it’s no different from wanting to do that with multiple switches. The only real way to do that is to have VLANs map to IP subnets and use routing.

Most enterprise switches have the ability to do the routing of VLANs inside the switch, so you don’t need to have actual router devices that pass the traffic. You just set up the rules in the switch instead of a separate router. The advantage to this is that it allows users to plug into any Ethernet jack in the enterprise and always have the same VLAN and subnet on their device, and routing is optimized so that packets traverse the minimum number of switches.

But, it still requires rules to be set up…there is no way to both separate and not separate traffic and have it magically work without a human creating the rules. Even something like BPG (which allows updating of routes on the fly) is still at some point controlled by rules written by a human.