If the remote DNS server address value of a DHCP server changes, the affected
interfaces do a link down/up to inform all DHCP clients that they should
re-request their DHCP info.
Issue #2730
The dns_server_from attribute of the dhcp-server tag has effect only if
the dns_server attribute of the same tag is not set. If this is the
case, the dns_server_from attribute states the domain from whose IP
config to take the DNS server address. This is useful, for instance, if
the stated domain receives the address of a local DNS server via DHCP.
Whenever the IP config of the stated domain becomes invalid, the DHCP
server switches to a mode where it drops all requests unanswered until
the IP config becomes valid again.
Issue #2730
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
The Interface constructor previously tried to attach to a domain. This
might include sending a DHCP request to get the domain a valid IP config.
But in order to achieve this, the constructor used a pure virtual method
of Interface which crashes due to the unfinished vtable. To fix this bug,
the attach attempt was moved to a new Interface::init method.
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
A very basic test of the re-configurability. It overwrites the configuration
once without making any changes, once with removing all domains except
uplink, and a third time recovering to the initial configuration to see if
the clients keep going as soon as their domains are back.
Fixes#2670
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
The for_each method of the List wrapper remembers the next list item
before calling the functor on the current one, so, the current one can
be destroyed during the functor.
Ref #2670
Clients can connect at any time to the NIC router. The interfaces (sessions)
get attached to the appropriate domain as soon as it appears. This implies
that interfaces can also be detached from a domain without beeing destructed
when the domain disappears. All user dependent states of an interface such as
the link states, DHCP allocations and ARP information get lost when the
interface gets detached.
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
We disable super-page I/O mappings because our unmap code does not flush
local mappings from core and, thus, breaks later re-mappings of
different page size.
Issue #2547
Switch port I/O based PCI config space access to memory-mapped IO. The
base address of the PCI configuration space is acquired by mapping the
ACPI ROM and reading the first <bdf> node. An exception is thrown if the
first <bdf> node is not for PCI domain zero or if multiple <bdf> nodes
exist. This is to reduce complexity and also because multiple PCI
domains are rare.
The PCI configuration space is accessed via I/O mem dataspace which is
created in the platform_drv root and then passed on to the PCI session,
device components and finally to the actual PCI config access instances.
The memory access code is implemented in a way to make it work with Muen
subject monitor (SM) device emulation and also general x86 targets. On
Muen, the simplified device emulation code (which works also for Linux)
always returns 0xffff in EAX to indicate a non-existing device.
Therefore, EAX is enforced in the assembly templates.
Fixes#2547
The KIP address range resides in virtual memory while io_mem alloc
manages physical-address ranges.
The patch enables the use of ECAM/MMCONF for PCI configuration.
Issue #2547
