1. 01 Dec, 2021 1 commit
  2. 30 Nov, 2021 2 commits
  3. 29 Nov, 2021 1 commit
  4. 26 Nov, 2021 1 commit
  5. 24 Nov, 2021 3 commits
  6. 23 Nov, 2021 1 commit
  7. 22 Nov, 2021 1 commit
  8. 20 Nov, 2021 2 commits
  9. 19 Nov, 2021 3 commits
  10. 18 Nov, 2021 7 commits
    • Filip Pokryvka's avatar
      environment: unify dump_status_{nmcli,nmtui} · e4d61153
      Filip Pokryvka authored
      It makes no sense to have this different anymore. `nmcli` missed wifi 
      list, should not cause much harm by adding it.
      e4d61153
    • Filip Pokryvka's avatar
      Revert "prepare/run: set -e in more places" · e5458565
      Filip Pokryvka authored
      This reverts commit 6408aa51.
      
      This needs more care, as it causes to fail multiple systems.
      e5458565
    • Lubomir Rintel's avatar
      prepare/run: set -e in more places · 6408aa51
      Lubomir Rintel authored and Vladimír Beneš's avatar Vladimír Beneš committed
      Trap bad error status in more places, making it less likely that test setup
      errors go unnoticed. The few places where we're okay with bad exit are
      handled explicitely.
      6408aa51
    • Lubomir Rintel's avatar
      envsetup: ensure debuginfo-install is present · 663cd94f
      Lubomir Rintel authored and Vladimír Beneš's avatar Vladimír Beneš committed
      It's used later on in local_setup_configure_nm_eth_part1().
      663cd94f
    • Lubomir Rintel's avatar
      Always log memory use · cd943595
      Lubomir Rintel authored
      Memory use is generally something we're interested in keeping track of
      even when the test succeed (e.g. to check for regressions across
      branches).
      cd943595
    • Lubomir Rintel's avatar
      openvpn: tolerate link-local IPv6 addresses in IPv4 tests · d9035fe5
      Lubomir Rintel authored and Vladimír Beneš's avatar Vladimír Beneš committed
      The VPN interface gets an IPv6 link-local address even when the server
      doesn't supply any other IPv6 addresses. Unless IPv6 is disabled, this
      is the correct behavior. It was always the case with both NetworkManager
      and the standalone openvpn client.
      
      Before NetworkManager/next, NetworkManager wouldn't expose these
      addresses on the VPN active connection. Given the address is actually
      there, the new behavior is better. It's also very unlikely to cause any
      unwanted effects.
      
      Adjust the tests to accomodate for that.
      d9035fe5
    • Lubomir Rintel's avatar
      ipsec: avoid disabling ipv6 for *swan tests · 2752d4ca
      Lubomir Rintel authored and Vladimír Beneš's avatar Vladimír Beneš committed
      Long ago, Libreswan's pluto got confused upon seeing tentative IPv6 addresses
      and we ended up disabling IPv6 globally for tests that involved it.
      
      We, however, have a test where Libreswan is used along with an IPv6 OpenVPN
      network. The afforementioned hack causes the OpenVPN tun device to be
      created with IPv6 off, causing the assertion that an IPv6 address is
      present to fail.
      
      This used to be okay because NetworkManager ended up setting disable_ipv6=0
      for said interface. This changed in NetworkManager/next branch and I
      believe we new behavior is perhaps more correct.
      
      Do away with the Libreswan hack, ensuring that the libreswan version we got
      is good enough.
      2752d4ca
  11. 16 Nov, 2021 4 commits
  12. 15 Nov, 2021 5 commits
  13. 14 Nov, 2021 1 commit
  14. 12 Nov, 2021 2 commits
  15. 11 Nov, 2021 1 commit
  16. 10 Nov, 2021 1 commit
  17. 09 Nov, 2021 1 commit
    • Beniamino Galvani's avatar
      ipv6: update @ipv6_preserve_addr_order to check kernel order · 0de0468c
      Beniamino Galvani authored
      Test @ipv6_preserve_addr_order checks if the order of addresses
      changes by looking at nmcli output. Howevev, it assumes that addresses
      added by NM are listed before temporary addresses added by kernel.
      
      This is the "ip address" order:
      
          inet6 cafe:cafe::aa7b:6be1:ab25:eed/64 scope global temporary dynamic
             valid_lft 3599sec preferred_lft 1799sec
          inet6 cafe:cafe::5677:8a6:99a0:30d6/64 scope global dynamic mngtmpaddr noprefixroute
             valid_lft 3599sec preferred_lft 1799sec
          inet6 dead:beef::e2b0:73c4:3033:10ef/64 scope global temporary dynamic
             valid_lft 3596sec preferred_lft 1796sec
          inet6 dead:beef::bbd0:7f21:f187:867f/64 scope global dynamic mngtmpaddr noprefixroute
             valid_lft 3596sec preferred_lft 1796sec
          inet6 fe80::e46d:7cb6:4a28:5cb7/64 scope link noprefixroute
      
      This is the nmcli order with NM from main branch:
      
        IP6.ADDRESS[1]:    cafe:cafe::5677:8a6:99a0:30d6/64
        IP6.ADDRESS[2]:    dead:beef::bbd0:7f21:f187:867f/64
        IP6.ADDRESS[3]:    cafe:cafe::aa7b:6be1:ab25:eed/64
        IP6.ADDRESS[4]:    dead:beef::e2b0:73c4:3033:10ef/64
        IP6.ADDRESS[5]:    fe80::e46d:7cb6:4a28:5cb7/64
      
      Note how the orders don't match.
      
      In the "next" branch, addresses in nmcli output are determined only by
      looking at kernel and so the output is the same as "ip". This seems
      more correct.
      
      The purpose of the test is to ensure that the address order doesn't
      change when receiving RAs. We can do that by looking at "ip"
      output. In this way, the test works with both "main" and "next"
      branches of NM.
      0de0468c
  18. 08 Nov, 2021 2 commits
  19. 05 Nov, 2021 1 commit