nic_router: config attribute 'dns_config_from'

WARNING: BREAKS CONFIG COMPATIBILITY!

This commit changes the configuration interface of the NIC router in a way that
may break systems that use the component without proper adjustment!

How to adjust:
At each occurrence of the 'dns_server_from' attribute in a NIC router
configuration replace the attribute name with 'dns_config_from'. The attribute
value remains unaltered.

DETAILED DESCRIPTION

The new attribute name 'dns_config_from' reflects that also other aspects of
the DNS configuration of the denominated domain are used by the DHCP server
that holds the attribute. This commit is a preparation for forwarding also the
domain name (DHCP option 15) with the mechanism behind the attribute.

Ref #4246
This commit is contained in:
Martin Stein 2021-08-05 13:31:13 +02:00 committed by Christian Helmuth
parent 1111472af7
commit fa64aae7f8
18 changed files with 59 additions and 59 deletions

View File

@ -94,7 +94,7 @@ append config {
<domain name="downlink" interface="10.0.3.1/24">
<dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2" dns_server_from="uplink"/>
<dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2" dns_config_from="uplink"/>
<tcp dst="0.0.0.0/0"><permit-any domain="uplink" /></tcp>
<udp dst="0.0.0.0/0"><permit-any domain="uplink" /></udp>

View File

@ -105,7 +105,7 @@ set config {
<domain name="downlink" interface="10.0.3.1/24">
<dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2" dns_server_from="uplink"/>
<dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2" dns_config_from="uplink"/>
<tcp dst="0.0.0.0/0"><permit-any domain="uplink" /></tcp>
<udp dst="0.0.0.0/0"><permit-any domain="uplink" /></udp>

View File

@ -101,7 +101,7 @@ void Sculpt::Network::_generate_nic_router_config()
xml.attribute("ip_first", "10.0.1.2");
xml.attribute("ip_last", "10.0.1.200");
if (_nic_target.type() != Nic_target::LOCAL) {
xml.attribute("dns_server_from", "uplink"); }
xml.attribute("dns_config_from", "uplink"); }
});
if (uplink_exists) {

View File

@ -112,7 +112,7 @@ install_config {
<domain name="downlink" interface="10.0.3.1/24">
<dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2" dns_server_from="uplink"/>
<dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2" dns_config_from="uplink"/>
<tcp dst="0.0.0.0/0"><permit-any domain="uplink" /></tcp>
<udp dst="0.0.0.0/0"><permit-any domain="uplink" /></udp>

View File

@ -103,7 +103,7 @@ install_config {
<dhcp-server ip_first="10.0.3.2"
ip_last="10.0.3.2"
dns_server_from="uplink"/>
dns_config_from="uplink"/>
<tcp dst="0.0.0.0/0"><permit-any domain="uplink" /></tcp>
<udp dst="0.0.0.0/0"><permit-any domain="uplink" /></udp>

View File

@ -205,7 +205,7 @@ proc test_7_config { } {
<domain name="downlink" interface="100.2.3.1/24">
<dhcp-server ip_first="100.2.3.2"
ip_last="100.2.3.10"
dns_server_from="uplink"/>
dns_config_from="uplink"/>
<tcp dst="10.13.0.0/16">
<permit port="2345" domain="uplink" />

View File

@ -84,7 +84,7 @@ append config {
<dhcp-server ip_first="10.0.3.2"
ip_last="10.0.3.2"
dns_server_from="uplink"/>
dns_config_from="uplink"/>
<tcp dst="0.0.0.0/0"><permit-any domain="uplink" /></tcp>
<udp dst="0.0.0.0/0"><permit-any domain="uplink" /></udp>

View File

@ -15,7 +15,7 @@
<domain name="default" interface="10.0.1.1/24">
<dhcp-server ip_first="10.0.1.2"
ip_last="10.0.1.200"
dns_server_from="uplink"/>
dns_config_from="uplink"/>
<tcp dst="0.0.0.0/0"><permit-any domain="uplink"/></tcp>
<udp dst="0.0.0.0/0"><permit-any domain="uplink"/></udp>
<icmp dst="0.0.0.0/0" domain="uplink"/>

View File

@ -193,7 +193,7 @@ append_if [expr ![nic_router_2_managed]] config {
<dhcp-server ip_first="10.0.3.2"
ip_last="10.0.3.2"
dns_server_from="uplink"/>
dns_config_from="uplink"/>
</domain>

View File

@ -457,7 +457,7 @@ or like this:
! <dhcp-server ip_first="10.0.1.80"
! ip_last="10.0.1.100"
! ip_lease_time_sec="3600"
! dns_server_from="home_lan" />
! dns_config_from="home_lan" />
! ...
!
! </domain>
@ -474,13 +474,13 @@ option 6 entry to its clients. These addresses might be of any IP subnet. The
addresses in the DHCP option 6 entry in the DHCP replies will have the same
order as the <dns-server> tags in the configuration.
The 'dns_server_from' attribute from the second example takes effect only when
The 'dns_config_from' attribute from the second example takes effect only when
the <dhcp-server> tag does not contain any <dns-server> sub-tags. The attribute
states the domain from whose IP config to take the list of propagated DNS
server addresses. Note that the order of DNS server adresses is not altered
thereby. This is useful in scenarios where these addresses must be obtained
dynamically through the DHCP client of another domain. An implication of the
'dns_server_from' attribute is that the link state of all interfaces at the
'dns_config_from' attribute is that the link state of all interfaces at the
domain with the DHCP server becomes bound to the validity of the IP config of
the domain that is stated in the attribute.

View File

@ -144,7 +144,7 @@
<xs:attribute name="ip_first" type="Ipv4_address" />
<xs:attribute name="ip_last" type="Ipv4_address" />
<xs:attribute name="ip_lease_time_sec" type="Seconds" />
<xs:attribute name="dns_server_from" type="Domain_name" />
<xs:attribute name="dns_config_from" type="Domain_name" />
</xs:complexType>
</xs:element><!-- dhcp-server -->

View File

@ -72,7 +72,7 @@ Dhcp_server::Dhcp_server(Xml_node const node,
Domain_tree &domains)
:
Dhcp_server_base(node, domain, alloc),
_dns_server_from(_init_dns_server_from(node, domains)),
_dns_config_from(_init_dns_config_from(node, domains)),
_ip_lease_time (_init_ip_lease_time(node)),
_ip_first(node.attribute_value("ip_first", Ipv4_address())),
_ip_last(node.attribute_value("ip_last", Ipv4_address())),
@ -108,7 +108,7 @@ void Dhcp_server::print(Output &output) const
_dns_servers.for_each([&] (Dns_server const &dns_server) {
Genode::print(output, "DNS server ", dns_server.ip(), ", ");
});
try { Genode::print(output, "DNS server from ", _dns_server_from(), ", "); }
try { Genode::print(output, "DNS config from ", _dns_config_from(), ", "); }
catch (Pointer<Domain>::Invalid) { }
Genode::print(output, "IP first ", _ip_first,
@ -124,9 +124,9 @@ bool Dhcp_server::dns_servers_equal_to_those_of(Dhcp_server const &dhcp_server)
}
Ipv4_config const &Dhcp_server::_resolve_dns_server_from() const
Ipv4_config const &Dhcp_server::_resolve_dns_config_from() const
{
return _dns_server_from().ip_config();
return _dns_config_from().ip_config();
}
@ -174,19 +174,19 @@ void Dhcp_server::free_ip(Domain const &domain,
}
Pointer<Domain> Dhcp_server::_init_dns_server_from(Genode::Xml_node const node,
Pointer<Domain> Dhcp_server::_init_dns_config_from(Genode::Xml_node const node,
Domain_tree &domains)
{
if (!_dns_servers.empty()) {
return Pointer<Domain>();
}
Domain_name dns_server_from =
node.attribute_value("dns_server_from", Domain_name());
Domain_name dns_config_from =
node.attribute_value("dns_config_from", Domain_name());
if (dns_server_from == Domain_name()) {
if (dns_config_from == Domain_name()) {
return Pointer<Domain>();
}
try { return domains.find_by_name(dns_server_from); }
try { return domains.find_by_name(dns_config_from); }
catch (Domain_tree::No_match) { throw Invalid(); }
}
@ -196,7 +196,7 @@ bool Dhcp_server::ready() const
if (!_dns_servers.empty()) {
return true;
}
try { return _dns_server_from().ip_config().valid(); }
try { return _dns_config_from().ip_config().valid(); }
catch (Pointer<Domain>::Invalid) { }
return true;
}

View File

@ -68,7 +68,7 @@ class Net::Dhcp_server : private Genode::Noncopyable,
{
private:
Pointer<Domain> const _dns_server_from;
Pointer<Domain> const _dns_config_from;
Genode::Microseconds const _ip_lease_time;
Ipv4_address const _ip_first;
Ipv4_address const _ip_last;
@ -78,10 +78,10 @@ class Net::Dhcp_server : private Genode::Noncopyable,
Genode::Microseconds _init_ip_lease_time(Genode::Xml_node const node);
Pointer<Domain> _init_dns_server_from(Genode::Xml_node const node,
Pointer<Domain> _init_dns_config_from(Genode::Xml_node const node,
Domain_tree &domains);
Ipv4_config const &_resolve_dns_server_from() const;
Ipv4_config const &_resolve_dns_config_from() const;
public:
@ -108,9 +108,9 @@ class Net::Dhcp_server : private Genode::Noncopyable,
template <typename FUNC>
void for_each_dns_server_ip(FUNC && functor) const
{
if (_dns_server_from.valid()) {
if (_dns_config_from.valid()) {
_resolve_dns_server_from().for_each_dns_server(
_resolve_dns_config_from().for_each_dns_server(
[&] (Dns_server const &dns_server) {
functor(dns_server.ip());
});
@ -138,7 +138,7 @@ class Net::Dhcp_server : private Genode::Noncopyable,
** Accessors **
***************/
Domain &dns_server_from() { return _dns_server_from(); }
Domain &dns_config_from() { return _dns_config_from(); }
Genode::Microseconds ip_lease_time() const { return _ip_lease_time; }
};

View File

@ -254,7 +254,7 @@ void Domain::init(Domain_tree &domains)
try {
dhcp_server.
dns_server_from().ip_config_dependents().insert(this);
dns_config_from().ip_config_dependents().insert(this);
}
catch (Pointer<Domain>::Invalid) { }
@ -334,7 +334,7 @@ void Domain::deinit()
try {
Dhcp_server &dhcp_server = _dhcp_server();
_dhcp_server = Pointer<Dhcp_server>();
try { dhcp_server.dns_server_from().ip_config_dependents().remove(this); }
try { dhcp_server.dns_config_from().ip_config_dependents().remove(this); }
catch (Pointer<Domain>::Invalid) { }
destroy(_alloc, &dhcp_server);
}

View File

@ -37,7 +37,7 @@ The "unmanaged" variant creates the following setup:
| +-------------------+ |
| ^ |
| | Built-in |
| | DHCP info |
| | DNS config |
| | forwarding |
| | |
| | |
@ -64,14 +64,14 @@ Downlink 1 does a "down-up" sequence in order to advise all connected DHCP
clients to reset. DHCP Client 1 does so and receives the updated information
for its domain Uplink.
But the domain Uplink is also watched by Downlink 2 for additional DHCP
information through the router-internal forwarding mechanism (currently only
DNS server addresses, see attribute 'dns_server_from'). Therefore, the reset of
DHCP Client 1 also causes the link state of Downlink 2 to go "down" until DHCP
But the domain Uplink is also watched by Downlink 2 for a DNS configuration
through the router-internal forwarding mechanism (currently only DNS server
addresses, see attribute 'dns_config_from'). Therefore, the reset of DHCP
Client 1 also causes the link state of Downlink 2 to go "down" until DHCP
Client 1 finishes re-requesting DHCP. This causes DHCP Client 2 in the test
client (os/src/test/nic_router_dhcp/manager) to reset and re-request both the
basic DHCP info (originating from DHCP Server 2) and the updated additional
DHCP info (originating from DHCP Server 1) as soon as Downlink 2 is "up" again.
client (os/src/test/nic_router_dhcp/manager) to reset and re-request all DHCP
information from DHCP Server 2 and thereby apply the updated DNS configuration
(originating from DHCP Server 1) as soon as Downlink 2 is "up" again.
The test terminates successfully when the test client has printed a certain
sequence of successively received DHCP setups to the serial output. It fails,
@ -82,9 +82,9 @@ Managed test scenario
#####################
The "managed" variant of test differs only in one detail from the "unmanaged"
variant: It doesn't use the router-internal mechanism for forwarding additional
DHCP information from the domain Uplink to domain Downlink 2. Instead, it
achieves the forwarding through an additional manager component
variant: It doesn't use the router-internal mechanism for forwarding DNS
configurations from domain Uplink to domain Downlink 2. Instead, it achieves
the forwarding through an additional manager component
(os/src/test/nic_router_dhcp/manager):
@ -129,25 +129,25 @@ ROM server. The initial router configuration written by the manager is
basically the same as the static NIC-Router-2 configuration in the "unmanaged"
scenario with the small addition that it causes the router to report its state.
Now, each time that the DCHP info of domain Uplink changes, NIC Router 2
generates a new state report reflecting the updated DHCP info. The manager
receives the state update through its ROM session with the Report ROM server.
Now, the manager checks whether the additional DHCP info of domain Uplink
was affected by the update. If so, it generates a new router configuration
injecting the new additional DHCP info into DHCP Server 2.
Now, each time that the DNS configuration of domain Uplink changes, NIC Router
2 generates a new state report reflecting the update. The manager receives the
state update through its ROM session with the Report ROM server. The manager
checks whether the DNS configuration of domain Uplink was affected by the
update. If so, it generates a new router configuration injecting the new DNS
configuration into DHCP Server 2.
Note that the test manager takes care not to create endless feedback-response
loops by re-configuring the router only when the interesting part of the router
state changes (the additional DHCP info of domain Uplink). The test manager
reduces re-configuration even further by doing it only when the DHCP info at
domain Uplink became valid. This means that it skips the short periods where
DHCP Client 1 is waiting for the re-request to finish and no DHCP info is
available. It's fine for DHCP Server 2 to stay with the outdated information
during this time as no basic DHCP information is affected and routing via
Uplink remains blocked until DHCP finished anyway.
state changes (the DNS configuration of domain Uplink). The test manager
reduces re-configuration even further by doing it only when the DNS
configuration at domain Uplink became valid. This means that it skips the short
periods where DHCP Client 1 is waiting for the re-request to finish and no DNS
configuration is available. It's fine for DHCP Server 2 to stay with the
outdated information during this time as no basic DHCP information is affected
and routing via Uplink remains blocked until DHCP finished anyway.
The rest of the process remains the same as in the "unmanaged" variant. The
"managed" approach has the benefit that the forwarding of additional DHCP info
"managed" approach has the benefit that the forwarding of DNS configurations
can be adapted to scenarios with special requirements. For instance, one might
want to filter information in order to restrict or protect the client behind
the router.

View File

@ -404,7 +404,7 @@ append_if $use_nic_session config {
<domain name="downlink" interface="10.0.3.1/24">
<dhcp-server ip_first="10.0.3.55" ip_last="10.0.3.155" dns_server_from="uplink"/>
<dhcp-server ip_first="10.0.3.55" ip_last="10.0.3.155" dns_config_from="uplink"/>
<tcp dst="0.0.0.0/0"><permit-any domain="uplink" /></tcp>
<udp dst="0.0.0.0/0"><permit-any domain="uplink" /></udp>

View File

@ -159,7 +159,7 @@ set config_of_app {
<domain name="downlink" interface="10.0.3.1/24">
<dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2" dns_server_from="uplink"/>
<dhcp-server ip_first="10.0.3.2" ip_last="10.0.3.2" dns_config_from="uplink"/>
<tcp dst="0.0.0.0/0"><permit-any domain="uplink" /></tcp>
<udp dst="0.0.0.0/0"><permit-any domain="uplink" /></udp>

View File

@ -114,7 +114,7 @@ set config_of_app {
<domain name="downlink" interface="10.0.3.1/24" verbose_packets="no">
<dhcp-server ip_first="10.0.3.100" ip_last="10.0.3.200" dns_server_from="uplink"/>
<dhcp-server ip_first="10.0.3.100" ip_last="10.0.3.200" dns_config_from="uplink"/>
<tcp dst="0.0.0.0/0"><permit-any domain="uplink" /></tcp>
<udp dst="0.0.0.0/0"><permit-any domain="uplink" /></udp>