@matthewr Thanks for confirming!
Closing it as resolved now. Feel free to reopen or create a new one if this bug remains again.

Here's the generated configuration from /run/conntrackd/conntrackd.conf:

# Synchronizer settings
Sync {
    Mode FTFW {
        DisableExternalCache on
    }
    Multicast {
        IPv4_address 225.0.0.50
        Group 3780
        IPv4_interface 192.168.15.3
        Interface bond0.110
        SndSocketBuffer 104857600
        RcvSocketBuffer 104857600
        Checksum on
    }
}
Helper {
    Type rpc inet tcp {
        QueueNum 3
        Policy rpc {
            ExpectMax 1
            ExpectTimeout 300
        }
    }
    Type rpc inet udp {
        QueueNum 4
        Policy rpc {
            ExpectMax 1
            ExpectTimeout 300
        }
    }
    Type tns inet tcp {
        QueueNum 5
        Policy tns {
            ExpectMax 1
            ExpectTimeout 300
        }
    }
}

Fixed in https://github.com/vyos/vyos-1x/commit/84b520dd580b7725de4c9e62b11ec490cb8d3f4f. The 1.4.0-epa2 build was created before the patch was applied.

Just in case it helps, after a migration from 1.3 to 1.4.0-epa2, the migrated config ends up as:-

https://github.com/vyos/vyos-1x/pull/3140

See T6131 for a report of the VTUN/OSPF issue with a simple lab config, which occurs separately from a migration.

https://github.com/vyos/vyos-1x/pull/3139

We'll update the key and make a post about it soon, sorry for the lengthy mix-up.

comments above are for https://vyos.net/get/nightly-builds/

Bumped into another instance of this issue:

curl -k --location --request POST "https://$VYOS_HOST/configure" --form key="$VYOS_KEY" --form data='[{"op":"set","path":["policy", "access-list", "2", "rule", "5", "description", "2024-03-16T14:52:44Z"]}]'
{"success": false, "error": "[[policy]] failed\nCommit failed\n", "data": null}

@jestabro I have tested my usecase now and it seems the problem is fixed and the API no longer segfaults. Thank you so much for the fix and the fantastic turn around on this.

Should add the ability to view the default action log would be nice as well.

PR for 1.5: https://github.com/vyos/vyos-1x/pull/3137

I can download the image and add it from path just fine, e.g this works fine:

Proper would be to throw out chrony and use ntpsec instead which supports proper filtering.

Given that Chrony only allows one bind address, versus ntpd which allows multiple, a "wontfix" sounds like the correct answer! :-)

@m.serdienis Add set of configuration commands to reproduce.

The issue is which to choose if there are multiple, thus removing all, chrony will listen on all interfaces.

Most likely won't fix
https://chrony-project.org/doc/3.4/chrony.conf.html

I don't think it is expected to get speed to the node itself.
A router is generally used for forwarding traffic. It is better to use iperf to check the speed between 2 hosts.

There do already exists tasks regarding commit and boot times such as: https://vyos.dev/T5388

@Apachez the original issue was related nft

If use nftables natively as:

I wouldnt call 1m37s of commit time for a single line of configchange as "resolved"...

Also probably related: https://forum.vyos.io/t/long-commit-time-for-multiple-vrfs/14053