The 'default' attribute is useful to change the default value for those
protocol attributes that are not explicitely set in the configuration of
the component.
Issue #2738
Each supported protocol now has an attribute with the name of the protocol in
the config tag. Each of these attributes accepts one of four possible values:
* no - do not print out this protocol
* name - print only the protocol name
* default - print a short summary of the most important header values
* all - print all available header values
Example:
! <config eth="name"
! arp="all"
! ipv4="default"
! dhcp="no"
! icmp="all"
! udp="no"
! tcp="default"
! ... />
Corresponding output example:
! ETH IPV4 10.0.2.212 > 10.0.2.55 time 7158 ms (Δ 11 ms)
! ETH IPV4 10.0.2.55 > 10.0.2.201 TCP 80 > 49154 flags ' time 6976 ms (Δ 5 ms)
! ETH ARP hw 1 prot 2048 hwsz 6 protsz 4 op 1 srcmac 02:02:02:02:02:01 srcip 10.0.2.212 dstmac 00:00:00:00:00:00 dstip 10.0.2.55 time 7074 ms (Δ 98 ms)
Issue #2738
Nitpicker's 'Session:focus' call used to trigger a one-off focus change
at call time. This focus change did not pass the same code paths as a
focus change triggered by a "focus" ROM update, which led to
inconsistencies.
This patch changes the implementation of 'Session::focus' such that the
relationship of the caller and the focused session is preserved after
call time. Whenever the calling session is focused in the future, the
specified session will receive the focus instead. So 'Session::focus'
represents no longer a single operation but propagates the information
about the inter-session relationship. This information is taken into
account whenever the focus is evaluated regardless of how the change is
triggered.
This makes the focus handling in scenarios like the window manager more
robust.
Issue #2746
Relative motion events with a motion vector of (0,0) should not exists.
They cause jittery movements of nitpicker's pointer position. This
patch filters out such events.
Our static okl4 system-integration configuration specifies a fixed RAM
range from 32 to 800 MiB, which must be satisfied by Qemu or strange
errors happen due to accesses beyond RAM. (Fixes current issues with
nic_router.run.)
This tests ping with simple IP forwarding, ping with NAPT as well as
forwarding of ICMP "Destination Unreachable" messages through the NIC
router.
Issue #2732
The 'ping' component continuously sends ICMP Echo requests to a given IP host
and waits for the corresponding ICMP Echo replies. For each successfull ICMP
Echo handshake it prints a short statistic. By now, it can be used only with a
static IP configuration. The size of the ICMP data field can be configured. It
gets filled with the letters of the alphabet ('a' to 'z') repeatedly.
Issue #2732
Originally, the timeout framework caused deadlocks when acquiring the same
lock from different timeout handlers. This use case is now tested in the
timeout test.
Fixes#2704
To handle all pending timeouts in the context of scheduling a timeout
was only necessary because the Timeout framework once made use of the
Alarm framework. The method Alarm_scheduler::schedule_absolute took an
absolute deadline as argument and we couldn't change this beause the
Alarm framework was also used without the Timeout framework. We had to
calculate this absolute deadline with the now time of the Timeout
framework but the Alarm framework has its own now time that is always a
bit behind the one of the Timeout framework. This lead to bad decisisons
when finding the right position for the new timeout. Now, we can call
schedule_absolute with a relative duration and thereby fix the problem.
When we schedule an absolute timeout without considering the small time
difference, the end-time for the timeout that is calculated using the
local time value is also smaller than the expected end-time. This can
also lead to directly triggering timeouts that should have triggered
with a certain delay.
As it is not trivial to update the local time value while scheduling a
timeout _without_ calling other timeout handlers, we simply raise the
duration of the new timeout by the age of the local time value.
Issue #2704
This fixes the problem that large timeouts, when rescheduled, are interpreted
to be from the last now_period instead of, what would be right, the next
now_period. This occured if there were multiple pending alarms at the head of
the queue and the reschedule of the first one was done with the other outdated
deadlines still in place.
Issue #2704
Instead of taking the absolute deadline of a timeout as argument from
outside (where it is calculated with a freshly requested now time), we
now take a relative duration as argument and calculate the deadline with
the scheduler-internal now time (which can be a little bit outdated).
This enables us to schedule timeouts without updating the internal now time
and thereby handle all pending timeouts.
Issue #2704
Integrate the code of the Alarm framework directly into the Timeout
framework. The former Alarm-framework methods are all private to the
corresponding classes of the Timeout framework and get prefixed with
'_alarm__'. The latter avoids name clashes and makes it easier to
simplify the code later.
Issue #2704
In the domain class there were several places where output was generated
not conforming to the typical output format of the router ("[domain]
event: parameters").
Issue #2670
When having an interface that yet is not attached to a domain, then a new
configuration comes in and the interface receives a domain name (via the
policy tag) but the corresponding domain doesn't exist, an exception
Domain_tree::No_match is thrown but was not caught and handled until now.
Issue #2670
This follows the guidelines in RFC 5508 to enable forwarding of ICMP
"Destination Unreachable" that correspond to an existing link state in
the NIC router. It also serves as blueprint for forwarding ICMP error
messages in general (They are merely not enabled because we don't test
them).
Issue #2732
By now, the 'verbose packets' output when sending packets was printed after
finish sending the packet. This makes following the packet flow harder if you
have multiple components that print such information.
Issue #2732
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