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>
- Basic DHCPv6 client, request a lease and verify Linux installs a
default route from the Router Advertisements (option not included
in DHCPv6), hence the 'enable-ra' option to dnsmasq. Also verify
DNS resolution over IPv6, including the resolvconf dance
- Prefix delegation, verifies that the client can actually request
and receives a prefix from a DHCPv6 server. We don't do anything
with it today though
Two new DHCP server implementations, the basic test relies on dnsmasq
and the prefix delegation test requires an ISC based dhcp server with
server side support for ipv6 prefix delegation. We could reuse the
latter for both tests, but this way we get compatibility testing.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The put_config() retry loop was catching and printing RpcError
exceptions but never re-raising them after exhausting retries.
This caused tests to silently continue despite configuration
failures, masking validation errors.
Now properly propagates errors after all retries are exhausted,
matching the error handling behavior of the RESTCONF backend.
Fixes#1250
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
If ping succeed but fail to check if netconf port is open,
the testsystem will hang forever.
This will allow totally broken images to be loaded at the device.
The xpath_to_uri() method only processed the first predicate in XPath
expressions with multiple [key='value'] patterns. Each re.sub() call
was performed on the original xpath instead of the result the previous
substitutions, causing subsequent predicates to be ignored.
Example XPath that would fail:
/infix-firewall:firewall/zone[name='untrusted']/interface[.='e2']
Would incorrectly convert to:
/infix-firewall:firewall/zone[name='untrusted']/interface=e2
Instead of the correct RESTCONF URL:
/infix-firewall:firewall/zone=untrusted/interface=e2
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Before this change:
ok 2 - Configure basic end-device firewall
not ok 3 - Verify unused interface assigned to default zone
# Exiting (2025-09-25 11:33:00)
# Traceback (most recent call last):
# File "/home/jocke/src/x-misc/test/./case/infix_firewall/basic/test.py", line 127, in <module>
# assert unused_if not in public_zone["interface"], \
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# AssertionError: Unused interface e4 should be in default zone 'public', got interfaces: ['e2', 'e3', 'e5', 'e7', 'e8']
After this change:
ok 2 - Configure basic end-device firewall
not ok 3 - Verify unused interface assigned to default zone
# Exiting (2025-09-25 11:35:00)
# File "/home/jocke/src/x-misc/test/./case/infix_firewall/basic/test.py", line 127, in <module>
# assert unused_if not in public_zone["interface"], \
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# Unused interface e4 should be in default zone 'public', got interfaces: ['e2', 'e3', 'e5', 'e7', 'e8']
Slightly shorter and arguably easier to read for a non-pythonic human.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
A very common pattern in our tests is:
if (condition):
print(f"the condition failed with {output}")
test.fail()
This change allows us to write:
if (condition):
test.fail(f"the condition failed with {output}")
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Libyang is smart, it "fixes" the timezone for you, this was overriden by a
hack in netconf.py and restconf.py, but what you really want is to see
in operational what the current timezone is.
Do not allow the topology matcher to setup a LAG where one link is
running at 10G while the other one runs at 1G, since the bond will
never use the 1G port as long as there the 10G link is up.
To run LAG tests on hardware, we have to make sure that the chosen
links are running at the same speed. We do not want to require a
specific link speed from the logical topology, as the real requirement
is merely that the two (or however many) links are of the _same_
speed, not any _particular_ speed.
Rather than having to complicate the topology matcher, let it take
care of the common pattern of matching requirements to provided
features, then let tests pass custom node/edge matchers for the
complicated cases.
Unclear if the libyang merge operation actually does it's job of merging
all the data properly in the restconf backend.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When first starting up the YANG models are downloaded. Initially all
were printed on the test console, so this was later changed to become
a sort of progress output. However, that broke tap output, causing a
missing leading '#' for the final "YANG models downloaded." message.
Thist patch drops the output entirely from the netconf transport, it
was never added to the restconf transport.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Example use:
@infamy.test_argument("--mode", help="one of 'static' or 'lacp'")
class TestArgs(infamy.ArgumentParser):
pass
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit adds two SVGs for previewing the virtual test topologies.
quad: fix a lot of copy-paste mistakes, rename nodes and ports to their
correct names. Replace shell comments with C++ style comments,
not all tools, e.g., dotty, support shell comments. The neato
absolute positioning has also been fixed to make it possible to
see all the edges, to facilitate this the used ports have been
swapped around a abit. Colors are used according to the schema
agreed on for tests. Finally, a second link for lag tests have
been added between dut2 and dut3.
dual: coloring similar to quad, update to new edge attribute matcher.
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.
Implemented logic to check if the system supports required services.
Logical edges with 'requires' fields are mapped only if physical edges
provide corresponding services. If not, the test is skipped.
This ensures that tests only run when the required services are available
in the test system configuration.
Fixes#654
Being able to check for a TCP based service is generally useful, not
only for NETCONF. Therefore, break it out to a separate function that
allows any port to be queried.
Using `sys.argv[0]` does not quite achieve the effect we want, namely
that any (test-case, $PYTHONHASHSEED) tuple should always default to
the same transport.
For example, the following two examples should always use the same
transport:
$ make PYTHONHASHSEED=1337 test-sh
infamy0:test$ ./case/ietf_system/hostname/test.py
$ make PYTHONHASHSEED=1337 test-sh
infamy0:test$ cd ./case/ietf_system/hostname
infamy0:hostname$ ./test.py
But, since their argv[0]'s are different, they don't.
Therefore use the _last two components_ of argv[0]'s full path
instead. This should:
- Spread the allocation over an entire suite run, since the
penultimate component is usually the test name.
- Keep the allocation stable when test code is modified (which is
common during debugging of failing tests)
- Avoid instabilities stemming from the local storage location (i.e.,
home directory names etc.)
The somewhat clumsy construct of resolving a logical port name to its
physical counterpart has been with us from Infamy's inception:
_, physical_port = env.ltop.xlate(logical_node, logical_port)
This is needlessly verbose. Since devices already have access to the
mappings which applies to it, make them easy to access:
target = env.attach("target")
# Get physical port names via the subscript operator
target["data0"]
* Use new cleanup in infamy to ensure the boot order gets restored
* Use new boot order in operational and use RPC to set boot order
to remove all SSH commands.
If a test need to clean up itself disregarding test status,
it can add an optional test-cleanup phase.
This is useful if the test in some circomstances leave the device in a
bad state. This can be used to restore the unit to its ordinary state.
Furl answers the question "is this URL serving the content I expect?"
Sometimes, we might be asking a server that in the middle of being
reconfigured, is crashing, is buggy, etc. - in which case it might RST
the connection. In that case the answer to the question is "False" and
not "BURN IT ALL DOWN!!"
Joachim Wiberg