smoketest for nptv6

Unfortunately this is not possible with WIDE DHCPv6 client

I have consulted some documents of vyos about DNAT of IPv4, and I don't understand why there seems to be SNAT content in the DNAT IPv4 syntax of vyos, and what is the meaning of supporting the prefix format address setting of dsddr in DNAT syntax? Is there something wrong with me?

Use cases for sNPT testing

The main idea to add some automation logic for calculation:

vyos@vyos# set system sysctl profile 
Possible completions:
   <text>       Sysctl profile
   Profile1     
   Profile2     
   auto

Fixed in latest rollings

Fixed in latest rolling.

Hi @jack9603301 , in normal condition all scripts and files should be migrated from /config/ directory on the migration process.

Just to make this a bit clearer. A short how-to to reproduce the bug in 1.3-rolling-202008031114 with empty config:

set firewall ipv6-name WAN6_IN6
set firewall ipv6-name WAN6_LOCAL6
set interfaces tunnel tun1 6rd-prefix '2607:FA48:6ED8::/45'
set interfaces tunnel tun1 6rd-relay-prefix '24.225.128.0/17'
set interfaces tunnel tun1 address '2607:FA48:6ED8:8A50::1/60'
set interfaces tunnel tun1 description 'Videotron 6rd Tunnel'
set interfaces tunnel tun1 encapsulation 'sit'
set interfaces tunnel tun1 firewall in ipv6-name 'WAN6_IN6'
set interfaces tunnel tun1 firewall local ipv6-name 'WAN6_LOCAL6'
set interfaces tunnel tun1 mtu '1480'
set interfaces tunnel tun1 multicast 'disable'
set interfaces tunnel tun1 parameters ip ttl '255'
set interfaces tunnel tun1 remote-ip '24.225.128.1'
set interfaces tunnel tun1 local-ip '24.225.136.165'
commit

leads to the error:

Can not set "local" for tunnel sit tun1 at tunnel creation

and the same but without the local-ip option leads to the Python traceback.

This could be closed in its current form, i'll open a new ticket om the missing parts

Works like a charm when commit is reverted.

Most of the services have been migrated to systemd and the configuration files have been moved to /run so they won't survive a reboot.

Wireless interface is entirely rewritte in rolling - please retest and open appropriate new bug reports when situation persists.

I guess this can be considered complete @runar ?

Fixed in latest versions

Fixed in latest versions.

@hagbard this is a great idea - I did not thought about it.

Works fine on latest rolling, thx!

Works as expected