* Account all RAM/CAP quota of a session except quota for metadata used in
core. The latter is considered when asking if a session can afford to make
an operation but it does not get accounted to always be able to pay back all
quota when a session closes. The general accounting mechanism is moved from
atop of the allocators down to the level of RAM/RM session operations.
* report statistics about session objects and quota if <report stats="yes"
quota="yes"/> is configured. (default is yes if <report> is present)
Issue #2953
The log messages covered by verbose_packet_drop were previously
configured by the verbose attribute. This isn't the case anymore. Now,
you can configure them as follows:
! <config verbose_packet_drop="no" ... >
! <domain verbose_packet_drop="no" ... />
! <config/>
The new attribute determines whether to log each packet drop and the
rational behind it. The <config> value affects all domains without a
<domain> local value.
Issue #2857
The ICMP-Echo-server functionality of the router has the following
configuration attributes (default values shown):
! <config icmp_echo_server="yes">
! <domain icmp_echo_server="yes" ... />
! </config>
The icmp_echo_server attribute configures whether the router answers ICMP Echo
requests that address the router. The <config> value affects all domains
without a <domain> local value.
Issue #2874
* Do not log events that are not critical (deadly) to the NIC router if not
configured to be verbose,
* Print almost all log lines with a prefix of the domain name they are
related to,
* And, do not use Genode::error and Genode::warning as they make it hard to
read the log with the domain name prefixes.
Fixes#2840
Introduce the uplink tag:
! <config>
! <uplink label="wifi" domain="uplink">
! <uplink label="wired" domain="wired_bridge">
! <uplink domain="wired_bridge">
! <config/>
For each uplink tag, the NIC router requests a NIC session with the
corresponding label or an empty label if there is no label attribute.
These NIC sessions get attached to the domain that is set in their
uplink tag as soon as the domain appears. This means their lifetime is
not bound to the domain. Uplink NIC sessions can be safely moved from
one domain to another without being closed by reconfiguring the
corresponding domain attribute.
Attention: This may render previously valid NIC router configurations
useless. A domain named "uplink" doesn't automatically request a NIC
session anymore. To fix these configurations, just add
! <uplink domain="uplink"/>
or
! <uplink label="[LABEL]" domain="uplink"/>
as direct subtag of the <config> tag.
Issue #2840
The term was used for the old configuration during the handling of a new
configuration but in other places it was already called old_config.
Issue #2840
Dissolve and destroy the invalid domain first before deinitializing all
domains for the next round. This way, the deinitialization is not done twice
for the invalid domain.
Issue #2840
Previously we were doing the initialization once over all domains,
remembered which of them became invalid and destroyed those afterwards.
This isn't sufficient. As soon as one domain becomes invalid we have to
dissolve/destroy this one, deinitialize all other domains again (as they
could contain references to the invalid domain) and retry to initialize
them from the beginning. We proceed with this until we have one run
without a domain becoming invalid. Then we can be sure that the last
initialization run did not create references to any invalid domain.
Issue #2840
Since the router MAC is allocated like the donwlink MACs it can't happen
anymore that these MACs clash, for instance due to nested routers. Thus,
the range of the MAC allocators of nested routers must not be exclusive
anymore which deprecates the 'mac_first' configuration attribute.
Issue #2795
The mac_first attribute tells the MAC-address allocator of the router
from which MAC address to start allocating. This is useful, for
instance, if you have nested nic_routers. In this case, identical
MAC-allocator settings have led to name clashes in the past, so, you
want to be able to configure them differently.
Issue #2732
This follows the guidelines in RFC 5508 to enable ICMP echo through a NAPT
channel of the NIC router. It serves also as blueprint for ICMP queries in
general (they are merely not enabled because we don't test them by now).
Issue #2732
Until now, the DHCP server of a domain was re-constructed each time the
IP config changed. This is not necessary as a domain that acts as DHCP
server must have a static IP config as it would be senseless to act as
DHCP server and client at the same time. Now, a configured DHCP server
is constructed only when the Domain gets constructed and stays alive
until the domain gets destructed. Furthermore, we now throw Domain::Invalid
if there is no static IP config plus a DHCP server configured. However, by
now, this exception is not caught as it is not trivial to destruct the
domain at this point.
Issue #2730
Instead of Pointer<T>::set use assignment operator with implicit constructor
from T-reference. Instead of Pointer<T>::unset use assignment operator with
Pointer<T>(). Instead of Pointer<T>::deref provide () operator.
Issue #2730
The router reacts as follows to a configuration change:
1) Construct new internal configuration representation (the old one stays
in place to be able to do comparisons in the following steps)
2) Iterate through all user-dependent objects (interfaces, link states, ARP
information, DHCP information) and re-check which remain valid with the
new configuration and which must be dismissed.
3) Adapt the objects that remain valid to the new configuration (re-write
references) and remove or detach the dismissed objects.
4) Do a link state DOWN at each interface and a link state UP at each
interface that remains attached to a domain.
5) Replace the old internal configuration representation with the new one
This way, the router keeps as much user dependent states as possible
while going through a configuration change. Thus, overwriting the old
configuration with an exact copy of itself is (almost) transparent to
clients of the router. Almost, because there are things the router must
do on every configuration handling, like re-scheduling the expiration
timeouts of links.
Ref #2670
This separates the decision wether to log the received and sent packets
from the 'verbose' attribute. This information is now only logged if
'verbose_packets' is switched on. If 'verbose' is switched on, only
routing decisions and optional hints are printed.
Ref #2670
The NIC router can now be configured to periodically send reports.
Configuration example (shows default values):
<config>
<report interval_sec="5" bytes="yes" config="yes">
</config>
If the 'report' tag is not available, no reports are send.
The attributes of the 'report' tag:
'bytes' : Boolean : Whether to report sent bytes and received bytes per
domain
'config' : Boolean : Whether to report ipv4 interface and gateway per
domain
'interval_sec' : 1..3600 : Interval of sending reports in seconds
Issue #2614
When this flag is set in the config tag, the NIC router will print a
short information to the log for each general state change of a domain.
This includes currently the IP-configuration state and the number of
connected NIC sessions. This a useful addition as the normal verbose
flag's purpose is a very deep insight into almost every activity in the
router, which is cool for debugging sophisticated problems but normally
floods the log and therefore discards this option for, e.g., desktop
systems. In such systems, the new verbosity is pretty discreet but
already gives a good hint on why packets may get dropped by the router
although the routing rules are correct.
Issue #2534
Replace former rtt_sec attribute of the <config> tag by more specific
(and still optional) attributes for timeouts used in the NIC router
(these are also the default values):
<config dhcp_discover_timeout_sec="10"
dhcp_request_timeout_sec="10"
dhcp_offer_timeout_sec="10"
udp_idle_timeout_sec="30"
tcp_idle_timeout_sec="600"
tcp_max_segm_lifetime_sec="30">
Details about the new attributes can be found in the README of the router.
Issue #2590
Do not use two times the RTT for the lifetime of links but use it as
it is configured to simplify the usage of the router. Internally, use
Microseconds/Duration type instead of plain integers.
Ref #2490
