This change exposes the macvlan mode to tests, unlocking support for running
certain types of tests on systems with only a single Ethernet port.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Introduce a parameter in IsolatedMacVlans to set interfaces up by
default. This removes the need to manually bring the interface up
inside the addip function.
If the callable threw an exception, then the process running inside
the netns would exit before sending back a value on the tx pipe, which
meant that `rx.recv()` would hang in the original process.
Make sure that we catch any exceptions, and send that instead of the
result over the pipe in those scenarios. Then in the original process,
re-raise the exception.
This is a specialized namespace, containing two ports,
which (hopefully) acts as completely transparent "bump-on-the-wire"
bridge.
Useful in scenarios where you want to test what happens when the flow
of packets between two nodes is disrupted. E.g., for testing fail-over
behavior in dynamic routing protocols, L2 redundancy, VRRP etc.
Now that we're using the `passthru` mode of MACVLANs, it seems we can
rely on the parent interface's promiscuity going down to 0 as an
indication that the kernel has completed the removal of the interface,
and will accept the creation of a new one.
When used as a context manager, __exit__ will be called even though
__enter__ might throw an exception half way through. So there is no
guarantee that the instance is on the cleanup list when we get to
stop().
This mode let's us receive all packets from the parent device, which
is automatically set in promiscuous mode, and let's the MACVLAN
transmit packets with any SA, which we need to implement a TPMR (or a
bridge or anything else we might dream up)
This is needed to create namespaces with MACVLANs from different
parent interfaces. The first consumer will be a Two-Port Mac
Relay (TPMR), so that we can control the flow of packets between two
nodes.
Story time:
In the days of yore, we generated PCAPs using tcpdump, which will
flush any buffered packets to its output file on reception of
SIGUSR2. Therefore we sent a USR2 before terminating the capture.
At some point, we switched over to use tshark to capture packets for
us, but the SIGUSR2 sayed in place.
It turns out, tshark will just die on USR2, abandoning the dumpcap
child it has created, which means the enclosing network namespace
can't be properly torn down.
Therefore:
Remove skip sending USR2 and just send TERM directly.
This tries to improve on the existing sniffer in a couple of ways:
- In addition to being usable as a context manager, also allow
explicitly starting and stopping the capture.
- Try to synchronize the start of the capture by snooping stderr and
wait for tcpdump to start up. This should eliminate the need for
sleeps before starting to send packets.
- By default, execute a safety sleep when terminating the capture to
ensure that any straggling packets have had time to arrive at their
destination.
By default, ping(1) will use a random ID in the ICMP packet. Allow
setting it to a fixed value instead.
This makes it easy to identify that particular packet in a packet
capture later on.
In test cases, it is common that we want to verify that a certain type
of traffic reaches a namespace. This has, up to this point, been
solved by the generic sniffer.Sniffer.
Try to improve the two most common use-cases...
1. Test if a flow reaches a namespace
2. Ensure that a flow does not reach a namespace
...by always exiting as soon as the first packet is received.
This saves time on positive tests, and the synchronous API allows it
to compose well with infamy.parallel().
QEMU systems seem work fine with the 5s timeout, whereas some physical
devices can't quite keep up with that.
Let the slower systems indicate that they need a bit more time without
punishing faster ones with a longer default.
It turns out that the semantics of ping's -c option does not match our
expectations. The manual says:
> Stop after sending count ECHO_REQUEST packets. With deadline option,
> ping waits for count ECHO_REPLY packets, until the timeout expires.
But in fact, something like an ICMP_DEST_UNREACH will also count as a
response, meaning that the process will terminate with non-zero
exitcode even though the deadline has not yet been crossed, rather
than keep waiting for an ECHO_REPLY.
To add some extra flavor: this is only the case for iputils' ping,
Busybox's implementation will hold out for a response until the
deadline expires.
Therefore, wrap the ping in an ugly retry loop.
Also, return the full available context from must{,_not}_reach on
failures, instead of just the output. This allows us to show the exit
code in the top-level exception handler.
Add a helper that lets you call a Python function (or lambda) in the
context of a network samespace.
Example:
with infamy.IsolatedMacVlan("eth0") as ns:
res = ns.call(lambda: subprocess.run(["ip", "link"],
capture_output=True))
print(res.stdout, f"\n[exitcode:{res.returncode}]")
The call to subprocess.run will be executed in the context of the
network namespace, and thus only list "lo" and the "iface"
macvlan.
The return value of the function passed to ns.call() is passed back
over a multiprocessing.Pipe, which requires that the object be
"picklable". This is true for most objects (even more complex ones
like the CompletedProcess object seen in the example above). Some
notable exceptions are things like file objects, sockets, etc.
The setns(2) syscall is unfortunately not available in current
versions of Python shipped with neither Ubuntu nor Alpine at the time
of this writing. Therefore, shoot from the hip, assume that we're
running on an x86_64 CPU, and just hotwire the syscall directly with
some constants we found in a dumpster.
* sniffer did not work correctly
* links did not come upp as quick as in qemu
* must_reach in netns was to narrow, increase timeout
* add wait function to handle poll