Great, thanks

It seems after this commit https://github.com/vyos/vyos-1x/commit/08cb762347208b21a8cbf81f7b35707d7e6dd4ac
I’ll take a look later

Got the PR working:

Using the pull requests filesystem copy, same place, new error:

vyos@vyos-515:~$ cat /var/log/vyatta/*log
cp[/opt/vyatta/config/tmp/new_config_1615]->[/opt/vyatta/config/tmp/tmp_1615/work]
cp w->tw failed[unknown exception]
cp[/opt/vyatta/config/tmp/new_config_2665]->[/opt/vyatta/config/tmp/tmp_2665/work]
cp w->tw failed[unknown exception]
vyos@vyos-515:~$ dpkg -l|grep vyatta-cfg
ii  libvyatta-cfg-dev                    0.102.0+vyos2+current5              amd64        libvyatta-cfg development package
ii  libvyatta-cfg1                       0.102.0+vyos2+current5              amd64        vyatta-cfg back-end library
ii  libvyatta-cfg1-dbgsym                0.102.0+vyos2+current5              amd64        debug symbols for libvyatta-cfg1
ii  vyatta-cfg                           0.102.0+vyos2+current5              amd64        VyOS configuration system
ii  vyatta-cfg-dbgsym                    0.102.0+vyos2+current5              amd64        debug symbols for vyatta-cfg
ii  vyatta-cfg-qos                       0.15.42+vyos2+current1              all          VyOS Qos configuration templates/scripts
ii  vyatta-cfg-system                    0.20.44+vyos2+current22             amd64        VyOS system-level configuration
vyos@vyos-515:~$ uname -r
5.15.59-amd64-vyos-sv
vyos@vyos-515:~$

If Linux maintainers backport the delta causing this to 5.10, it could become a rather pressing concern, but for now merely a show-stopper in terms of moving past 5.10LTS.

Created a pull request implementing a rudimentary fall-through-on-exception to standard API from the Boost version @ https://github.com/vyos/vyatta-cfg/pull/49
Have not built it yet, nor am i a formal C++ developer (hackers are informal everything developers and rarely formal anything developers), so would appreciate eyes on and sanity checks.
Exception can probably be scoped better to only trip on EXEDEV but i dont see a logical problem with falling-through like this on other errors (is this a bad assumption?).

PR https://github.com/vyos/vyos-1x/pull/1466
Let me know if there is what you are expecting,
requires more tests

set nat static rule 10 destination address '10.0.1.1'
set nat static rule 10 inbound-interface 'eth0'
set nat static rule 10 translation address '192.168.1.1'

@artooro Did you try listen-port option for this case?

set service https api gql
set service https api keys id KID key 'foo'
set service https api socket
set service https virtual-host foo listen-port '2580'

Check:

vyos@r14# sudo netstat -tulpn | grep nginx
tcp        0      0 0.0.0.0:2580            0.0.0.0:*               LISTEN      3570/nginx: master  
tcp6       0      0 :::2580                 :::*                    LISTEN      3570/nginx: master  
[edit]
vyos@r14#

@n.fort Create please PR for 1.3

@aserkin Will be present in the next rolling release.

@ajgnet Could you show routes after this bug?

sudo ip -6 route show
sudo ip -6 route get 2607:f8b0:4006:80d::200e

PR https://github.com/vyos/vyos-1x/pull/1465

PR https://github.com/vyos/vyos-1x/pull/1464

I've verified this behavior with 1.4-rolling-202207290217 and 1.4-rolling-202204250217.

PR https://github.com/vyos/vyos-1x/pull/1463
PR https://github.com/vyos/vyatta-cfg-system/pull/184

Hi Viacheslav
Sorry, i probably misspelled the config option. Actually it's availabe at [radius] section of accel-ppp.conf.
Below is the [radius] section from my /run/accel-pppd/l2tp.conf after i changed
/usr/libexec/vyos/conf_mode/vpn_l2tp.py:

What version you are using?

@aserkin Could you send an example of the required accel-ppp section? And how do you see this command in VyOS CLI?

Allow me to proof the opposite.

As remarked and as expected, this option is not enable by default.
Proofs:

• Fist scenario: no ping-check option introduced in configuration:

In T2518#127884, @jack9603301 wrote:

@ajgnet If you have a way to limit the dynamic prefix to a known prefix, then using 1:1 NAT66 prefix translation should work (only the host segment is dynamic)

Yes, would be great to fully support dynamic prefix when the prefix is not known

Will be fixed in https://github.com/vyos/vyos-1x/pull/1458

PR: https://github.com/vyos/vyos-1x/pull/1461

ping-check shouldn't be allowed by default
To enable it you have to set set service dhcp-server shared-network-name Lan01 ping-check
There is no configuration in generated .conf:

vyos@r14# cat /run/dhcp-server/dhcpd.conf | grep ping
[edit]
vyos@r14#

See also https://github.com/accel-ppp/accel-ppp/issues/57
Testing this patch, PPPoE session with the Phicomm router now stays up, the missing part after "else" is to remove IPv6 configuration from ppp interface (not sure how to do it properly).

diff
diff --git a/accel-pppd/ppp/ppp_ipv6cp.c b/accel-pppd/ppp/ppp_ipv6cp.c
index 1194b31..2bac31b 100644
--- a/accel-pppd/ppp/ppp_ipv6cp.c
+++ b/accel-pppd/ppp/ppp_ipv6cp.c
@@ -738,7 +738,10 @@ static void ipv6cp_recv(struct ppp_handler_t*h)
                        if (conf_ppp_verbose)
                                log_ppp_info2("recv [IPV6CP TermReq id=%x]\n", hdr->id);
                        ppp_fsm_recv_term_req(&ipv6cp->fsm);
-                       ap_session_terminate(&ipv6cp->ppp->ses, TERM_USER_REQUEST, 0);
+                       if (conf_ipv6 == IPV6_REQUIRE)
+                               ap_session_terminate(&ipv6cp->ppp->ses, TERM_USER_REQUEST, 0);
+                       else
+                               ppp_layer_passive(ipv6cp->ppp, &ipv6cp->ld);
                        break;
                case TERMACK:
                        if (conf_ppp_verbose)

I have tested macsec with gcm-aes-256. It works. (1.4-rolling-202208080217)

I have tested on 1.4-rolling-202208080217.
The first problem was fixed.
The second problem is not fixed

Log messages - http://91.224.224.43/phicomm/phicomm6.log
PPPoE server config:

Hello, This functionality for nat66 is described here:
https://phabricator.vyos.net/T4586

hi, you can set this to a subtask of my task

PR https://github.com/vyos/vyos-1x/pull/1462

PR checks if openconnect port is listened by another service https://github.com/vyos/vyos-1x/pull/1460

It is already present in 1.4

vyos@r14:~$ show conf com | match bgp
set protocols bgp listen limit '1000'
set protocols bgp listen range 192.0.2.0/24 peer-group 'FOO'
set protocols bgp local-as '65001'
set protocols bgp peer-group FOO remote-as '65001'

It appeared after this commit
It doesn't like this check https://github.com/vyos/vyos-1x/blob/2a10ffa4b5074be27458159fa94d6227d0e5c7f7/src/op_mode/openconnect-control.py#L63-L65
Check root user https://github.com/vyos/vyos-1x/blob/2a10ffa4b5074be27458159fa94d6227d0e5c7f7/python/vyos/util.py#L625-L626

Would it be an option to instead just add new listen-interface and upstream-interface statements, same as for dhcp-relay6? Then keep interface completely unchanged to avoid breaking weird usages, but add some deprecation notice to the CLI.

Currently thinking on how to implement this.
One option could be: