Couldn't reproduce in 1.3-rolling-20200319

Sorry, the task name was wrong, "save" resets it, "commit" doesn't. Personally I prefer if it'd stay the same, but I don't care if it resets it either.

The discussion says the container should be started with --privileged, as is documented in the vyos-build readme. Did you test it with --privileged?

Duplicate of T421

Still present in 1.3-20200319

The above commit fixes value help on tab (it displays correct quoted values, the script doesn't error any more) but the completion itself is still broken.

I opened the PR for our custom build of the package in vyos-build as well: https://github.com/vyos/vyos-build/pulls. I was waiting on testing results from anyone, but I went and tested it myself. The basic functionality works, I couldn't test the above bug. If it's merged and the new package build is added to CI, the above debian PR isn't needed (or our custom build isn't).

I ran into this today after upgrading to latest 1.3 rolling image. All interfaces were added and appeared to have the correct macs (the output of ip link matched what was in the config), but the physical interfaces to which they corresponded weren't right. I found this by looking at the link state of each interface and saw that two if them were swapped. The interface that should be eth2 was physically eth4 and vice versa, but the macs it was showing in ip link was wrong for that physical card, as if it were set to the other interface's mac erroneously.
I got the cards to detect properly after 2 reboots.

I haven't encountered this since, but the single 1.2 router is still on rc11, which has updated pdns-recursor 4.2, before being reverted: https://phabricator.vyos.net/R3:8c22ceead487b745d6b7c058c4d1c0a0eaa051c8 so it may still possibly be an issue in 1.2.
I've never encountered it on 1.3 rolling.

I'm not in the VyOS core team so I'm not able to make direct decisions on the resolution, but as I see it, there are several possible ways to approach this.

https://github.com/jjakob/vyos-build/tree/conntrack-tools-wip builds conntrack-tools from upstream git snapshot 20200301.

Fixed temporarily for now in https://phabricator.vyos.net/R3:1c4414dd363bdb268038ae238686be3e0b7f988b
We should re-add building it from upstream to fix T1538.

https://github.com/vyos/vyos-build/pull/84

@cpo I think you need to add it to CI in addition to vyos-build

Upstream still hasn't made a release with this patch: https://git.netfilter.org/conntrack-tools/commit/?id=c12fa8df76752b0a011430f069677b52e4dad164
So we could wait on upstream to release it and debian to package it, or build our own as we used to in 1.2.
It would be better to ask upstream to make a release as there's less work for us.

We don't build conntrack-tools in 1.3 (current/equuleus) any more, upstream Debian Buster conntrack and conntrackd packages are used. So as upstream gets patched, we'll pull in those patches automatically.
If I see things correctly, there are references to conntrack-tools in the build scripts that still need to be removed.

Sorry, I titled the task wrong. The error is in building conntrack-tools.

I think you're right, I couldn't find any package depending on it, vyatta-conntrack-sync only depends on conntrack.
I also found this https://phabricator.vyos.net/T1538 in which the conclusion is we should upgrade conntrack-tools.

https://github.com/vyos/vyos-build/pull/83

I personally don't mind the raw options, and there are other people using them too (T127, T1246, T1383, T1421, T1430).
There is no option for tls-crypt, just tls-auth. Also I'm experimenting with the various mtu options (tun-mtu, link-mtu, mssfix, fragment) and keepalive options (ping-restart, ping) that can't be set through the existing keepalive options (keepalive doesn't take 0 as a value if I want ping-restart 0 for example, and there's no way to not have keepalive be set with default vaules). So yeah, if all of these options were integrated, I personally wouldn't need the openvpn-options. But I think there are other places that use raw values with quotes that are affected by the autocompletion bug too, dhcp-server for example.

Tested with 1.3-rolling-202002091356, the issue is fixed. Thanks!

This is only the login section

login {
    user vyos {
        authentication {
            encrypted-password $6$***
            plaintext-password ""
            public-keys jernej@jernej {
                key ****************
                type ssh-ed25519
            }
        }
        level admin
    }
}

the config version line

/* Warning: Do not remove the following line. */
/* === vyatta-config-version: "broadcast-relay@1:cluster@1:config-management@1:conntrack@1:conntrack-sync@1:dhcp-relay@2:dhcp-server@5:dns-forwarding@2:firewall@5:interfaces@4:ipsec@5:l2tp@1:mdns@1:nat@4:ntp@1:pptp@1:qos@1:quagga@3:snmp@1:ssh@1:system@12:vrrp@2:vyos-accel-ppp@2:wanloadbalance@3:webgui@1:webproxy@2:zone-policy@1" === */
/* Release version: 1.3-rolling-201912110242 */

No, work would be needed to add the necessary logic to VyOS scripts.
This wasn't possible before the version of isc-dhcpd VyOS uses was
updated to one that supported PD length. But now it is at least
possible, before it wasn't possible at all.

I actually suggested using reload/SIGHUP. The problem is the very rapid reloads sent by the vyos script to systemd. start-stop-daemon is handled by systemd in Debian Buster, in Jessie it was still handled by sysvinit so it didn't have any limits. I suppose it uses some default restart limits/timeouts that can otherwise be adjusted in unit/service files. I suppose it could be converted to a native systemd service so the limits can be set if there is a corresponding setting that would fix the issue. Otherwise it'd be better if we don't use systemd to send SIGHUP at all and send the signal direclty to the daemon w/ pid read from pid file. Or switch to using frr for RAs - what's the progress on that?

@rps Great idea. A summary of some brainstorming that we had on Slack with @runar, @rps and @dmitry:

Is this only for crux or also for equuleus? There is also
https://phabricator.vyos.net/T1499
https://phabricator.vyos.net/T1584
https://phabricator.vyos.net/T291

This is confusing. While NTP used to work (listen on all interfaces) without any listen-address set, now it doesn't. This means any old config without listen-address set will now have a non-working NTP without any warning. There was no migration script to migrate the old behavior to the new. ntp should have a mandatory listen-address if this new behavior is kept.

If this is the issue I would replace the init.d call with systemctl since in 1.3 init.d/radvd is redirected to systemd anyway (maybe the bugs are present in this redirection so it's best to completely avoid it).
1.2 and earlier would still need to call init.d as-is.

VyOS 1.3 (rolling/equuleus) is now based on Debian Buster so has isc-dhcp-client 4.4.1.
According to the manual dhclient now has a command line option

--prefix-len-hint
When used in conjunction with -P, it directs the client to use the given length to use a prefix hint of, "::/length", when requesting new prefixes.

It was added in 4.3.6:
https://ftp.isc.org/isc/dhcp/4.4.1/dhcp-4.4.1-RELNOTES

Added explanation on how to use quotes inside raw parameters to the docs.
https://github.com/vyos/vyos-documentation/pull/163

Confirmed on 1.3-20191213, tcpdump on the router shows no advertisements until radvd is restarted with sudo systemctl restart radvd.

https://github.com/vyos/vyos-build/pull/70

This is fixed/was not present in 1.3-rolling.
1.2 is not possible to fix, the bug is in isc-dhcp which would need to be upgraded to a newer version.

This was discussed previously: https://phabricator.vyos.net/T1129
Use """ which will be replaced with quotes when generating the isc dhcpd config.
https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/dhcp_server.py#L813-L815

Sorry, I misunderstood your issue, indeed adding quotes inside the parameters is not possible now. A reimplementation would be needed.

https://github.com/vyos/vyos-1x/pull/182
We have to ship our own /etc/{init.d,default}/isc-dhcp{v4,v6}-server files since we can't overwrite the ones supplied by the debian package.

The current static-mapping-parameters can be used to add a quoted value, e.g.

static-mapping test {
                    ip-address x.x.x.x
                    mac-address yy:yy:yy:yy:yy:yy
                    static-mapping-parameters "option domain-name-servers 1.1.1.1, 9.9.9.9;"
                }

command

set service dhcp-server shared-network-name dhcpexample subnet 192.0.2.0/24 static-mapping example static-mapping-parameters "option domain-name-servers 192.0.2.11, 192.0.2.12;"

I'm experiencing the same issue of the service failing to start on 1.3.
The installation was first started with the default config in a VM that had a serial port. Then the installation was transferred to a physical machine without a serial port, and the whole /config directory was manually copied from the old installation on that machine. The machine was then rebooted. The result were the same errors in syslog/journal.
I believe the issue is that if the config.boot is manually replaced or edited on disk, the script that would normally be triggered on commit when deleting system console is never triggered, thus the service remains enabled, but there is no system console in the config to delete any more.

Crux needs a backport of show_dhcp.py from current, I fixed this in current

This is related/a duplicate of T1744

The replacement of special characters with backslash decimal happened on upgrade from 1.2.0-rc11 to 1.2.0-rolling+201906231514.

This is present in branches crux and current too, so adding tag for crux.
https://github.com/vyos/vyos-1x/commit/5848a4d6095e6d7bc70e34e0b7b7e2c3d8e3303f
https://github.com/vyos/vyos-1x/commit/6f954ab56768af9a07d8a1dc086f54ddefa58da7
https://github.com/vyos/vyos-1x/commit/5848a4d6095e6d7bc70e34e0b7b7e2c3d8e3303f

Via the process of elimination I found the culprit - comments with special characters in them, that at some point in the upgrade cycle got converted into backslash-escped decimal:

description "\197\160" # this was once Š
description "\196\140 \196\141" # Č č

\197\160 is C5 A0 which is U+0160, which was the original character.
So old versions allowed these characters in comments and worked fine with them, then at one point an upgrade converted them to backslash decimal UTF-8, which still worked until at some point they started causing the error.

https://github.com/vyos/vyatta-cfg-system/pull/109

@c-po I can't see the issue here, that seems like normal expected behavior (tabbing gives a list of all possible nodes, even the long ones?)
I agree that if there is a problem, it's for a separate issue and describe what the problem and expected behavior is in more detail there.

@c-po can you provide a way to reproduce your issue?