The warning "no interface connected to domain" was introduced when only one NIC
session at a time could be connected to a domain. It should help to track
packet drops that were caused by startup timing issues between servers and
clients. However, a user should watch the "NIC sessions" value of a domain
(verbose_domain_state) instead when debugging packet loss. With support for
multiple sessions per domain, even a non-empty domain may still miss the
session that connects the desired server.
Fix#2629
Previously, all packets that the router wanted to sent were first prepared to
their final state and then copied at once into the packet stream RAM. This is
fine for packets that the router only passes through with modifying merely
a few values. But for packets that the router writes from scratch on its own,
it is better to compose the packet directly in the packet stream RAM.
Fix#2626
Normally, Interface::send always takes the base and size of the RAM region
where a packet was composed and copies this finished packet at once into the
packet stream RAM. But we want to be able to also compose packets directly in
the packet stream RAM, so that no memcpy is needed. Thus, Interface::send now
takes a functor that describes how to compose the packet, then allocates the
packet stream RAM and applies the functor to this RAM. there is also a version
of Interface::send that provides the old behavior but with the new back end.
This way, we stay backwards-compatible.
Issue #2626
When composing an ARP packet for sending, it's pointless to use the Arp_packet
constructor as the constructor only checks whether the packet is malformed.
Issue #2618
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
In the context of link state objects we often used the term "close" were we
actually meant "dissolve". The term "close" originated from the TCP connection
state and is still used in TCP links in the correct manner.
Issue #2609
Act as hub for the interfaces at a domain. This also changes the roles of the
Domain and Interface classes. By now the Interface held the data structures for
the ARP cache, foreign ARP waiters, and the searchtrees for layer 3 links. All
these structures have moved to the Domain while the memory allocations and
lifetime management for the contents of these structures still come from from
the according Interface object. The mentioned data structures were also adapted
to fit the fact that they now may maintain objects of different interfaces.
Issue #2609
If an IPv4 packet targets an IP local to the domain it comes from and doesn't
target the routers IP of that domain, forward it to all other interfaces of
the domain without considering any other routing.
Issue #2609
Improve ARP handling code in general:
Make the several cases and their handling more clear by using a more
readable if/else statement structure. Drop gratuitous ARP requests.
Domain-local ARP:
Handle ARP packets that target local IPs other than the routers IP
(forward them to all other interfaces of the domain).
Issue #2609
IP allocations were renamed DHCP allocations without fixing the according
places in log messages and comments. This commit rectifies this omission.
Issue #2609
This patch makes service-announce messages depend on the configured
verbosity. It also omits "parent provides" title messages if no new
parent services are added during a config update.
Detect loops by walking hard-links at two different speeds and checking
for lapping. Tar link walking is no longer a recursive procedure.
Caught a loop created by GNU tar 1.29.
Fix#2611
If a client decides to spontaneously send a DHCP DISCOVER again, even though
he has received a still valid IP config from the router, we don't want to
discard the DISCOVER like it was done before but discard the IP config
assignment and offer a new one.
Issue #2534
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
The run tool now by default checks configurations with target-specific
XML schemata. Each component may define a config schema file in its
target.mk via the CONFIG_XSD variable. When the run tool has checked an
configuration of an init instance, it additionally goes through the
start nodes of the config. For each start node it checks whether there
is an XSD file that matches. If so, the run tool also checks the config
of the start node (if existant). This is done recursively. I.e., also
the child configs of a sub-init of a sub-init of the top-level init
receive a config check.
Issue #2600
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
Multi-wraps
-----------
Previously, on every new timeout, we programmed registers LR=timeout and
CMP=0. The counter than counted from LR down to 0, triggered the IRQ,
jumped back to LR, and counted down again. If one installed small
timeouts (< 1000 us), it was likely that the counter wrapped multiple
times before we were able to read it out. Initially, this was not a big
issue as the additional wraps were simply ignored and the amount of time
lost through this was not big. But when we want to do correct rate
limitation, multiple wraps cause an overflow in the additional
calculations, and this has a big effect on the resulting time value.
Thus, we now program the counter to start from ~0 and count down to 0.
We set CMP=~0-timeout so that the timer still triggers the IRQ at the right
time. The counter continues counting down after the IRQ has triggered until
we install a new timeout. We do not consider anymore that the counter wraps.
The maximum timeout is set to half the maximum counter value, so, we should
be able to install a new timeout before the counter wraps.
Rate limit for time updates
---------------------------
In the time span between two interrupts we have to remember how many ticks
we have already added to the time value. This is because at each call of
curr_time we can only see how many ticks have passed since the last call of
schedule_timeout and not since the last call of curr_time. But we want to
limit the rate of time updates in curr_time. With the member for ticks that
were already added since the last call to schedule_timeout we can then
calculate how many are yet to be added.
This patch supplements the existing 'hover' report with the information
whether or not the user has recently moved the pointer. This works
analogously to how the 'focus' report features the information about
recent button/keyboard activity.
Together, the 'hover' and 'focus' reports may be combined to observe
prolonged user inactivity, e.g. to activate a lock screen.
This patch enables nitpicker to use an external focus policy instead of
the traditional builtin click-to-focus policy. The external focus policy
is obtained from a 'focus' ROM. The focus ROM is expected to have a
'label' attribute with the value set to the label of the to-be focused
client.
