https://github.com/vyos/vyos1x-config/pull/11

I see the issue. Whitespace is fine in a tag node name as long as the name is quoted, however ConfigTree.to_string() does not re-quote the name, hence on the next migration script, parsing the config file will throw an error. I will investigate the proper solution.

There is an example of how we build ocserv for 1.3 https://github.com/vyos/vyos-build/commit/2e1eac5980720d060834540e717f4f8a1189b9b0

The similar request T3896

@n.fort Create please PR for 1.3

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:

Works as expected in a recent rolling (e.g. 1.4-rolling-202208021045)

The root issue is wpa_supplicant shipped in Debian does not contain commit https://w1.fi/cgit/hostap/commit/?id=46c635910a724ed14ee9ace549fed9790ed5980b which adds a new configuration file option named:

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

To solve the issue with MTU over DHCP we can use some new options like mtu for example:

set interfaces ethernet eth0 dhcp-options mtu

Working as expected in VyOS 1.3.1-S1

Change DUID to IAID_DUAID was in T1470
Not sure which format we should to use

It's applied but masked by another part, looking into it. A brief workaround is to just change the description on br0 and commit - then the bridge vlan is re-created.

@c-po Bug exists after reboot (tested in 1.4)

@Viacheslav can you save your config and reboot?

I have it working between VyOS 1.4-rolling-202207280217 (kernel 5.10.133) and VyOS 1.3-stable-202207280515 (kernel 5.4.205)

Will it work if you replace this https://github.com/vyos/vyos-1x/blob/4168e03721b2a9595de4090fddf1280d39ccce4c/python/vyos/ifconfig/interface.py#L1378-L1379

sudo nano -c +1385 /usr/lib/python3/dist-packages/vyos/ifconfig/interface.py

with:

I have no proof now of any obvious negative issues. Moreover, in my personal opinion - if some protocol or interface type requires a default MTU that is not assigned to it by the kernel, this is the problem that should be solved by configuration script for that particular interface.

Tested locally and receive sflow with agent IP of the configured ip/interface/vrf.

Will it affect also tunnels/openvpn/wireguard/vxlan etc?
If you get rid of the default MTU values you get more pain.

It seems not related to kernel and definitely another bug

vyos@r14# run show conf com | match bri
set interfaces bridge br0 enable-vlan
set interfaces bridge br0 member interface eth1 allowed-vlan '5-50'
set interfaces bridge br0 member interface eth1 native-vlan '5'
[edit]
vyos@r14# 
[edit]
vyos@r14# run show bridge vlan 
port              vlan-id  
br0               1 PVID Egress Untagged
[edit]
vyos@r14#

That's XPN support but GCM-AES-256 was added back in 2018 in https://w1.fi/cgit/hostap/commit/?id=1ff8605775

I installed wpa_supplicant version 2.10. But it did not help.
I compared debugs of wpa_supplicant and found the difference

Modyfing file pointed by @Viacheslav , makes ipv6 peer option available.
But while testing config, it's not possible to insert an ipv6 address: validator rejects input.
Validator used: syntax:expression: exec "/opt/vyatta/sbin/vyatta-policy.pl --check-peer-syntax $VAR(@)"; "peer must be either an IP or local"

It seems wpa_supplicant doesn't support GCM-AES-256
https://w1.fi/wpa_supplicant/devel/dir_4261af1259721e3e39e0d2dd7354b511.html

I have just tested it again. Macsec does not work.

Also cipher changes require a reboot. Nice bug - thanks for this riddle ;)

Also, there are no any Inbound/Outbound packets with aes-256

vyos@r14:~$ sudo ip -s macsec show
7: macsec1: protect on validate strict sc off sa off encrypt off send_sci on end_station off scb off replay off 
    cipher suite: GCM-AES-256, using ICV length 16
    TXSC: eeb5e212f04f0001 on SA 0
    stats: OutPktsUntagged InPktsUntagged OutPktsTooLong InPktsNoTag InPktsBadTag InPktsUnknownSCI InPktsNoSCI InPktsOverrun
                         0              0              0           0            0                0           0             0
    stats: OutPktsProtected OutPktsEncrypted OutOctetsProtected OutOctetsEncrypted
                          0                0                  0                  0
    offload: off 
vyos@r14:~$

But service starts without issues:

vyos@r14:~$ sudo systemctl status [email protected]
● [email protected] - WPA supplicant daemon (macsec-specific version)
     Loaded: loaded (/lib/systemd/system/[email protected]; disabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-07-18 20:07:16 EEST; 18min ago
   Main PID: 1802 (wpa_supplicant)
      Tasks: 1 (limit: 9411)
     Memory: 4.4M
        CPU: 101ms
     CGroup: /system.slice/system-wpa_supplicant\x2dmacsec.slice/[email protected]
             └─1802 /sbin/wpa_supplicant -c/run/wpa_supplicant/vxlan1.conf -Dmacsec_linux -ivxlan1

@a.apostoliuk Could you specify how to reproduce this bug?
Some CLI config examples and/or some pings that indicate the issue.

The similar issue and for the 1.3.1-S1

vyos@vyos# run show version

You can get duid data from python
https://github.com/vyos/vyos-1x/blob/44b1bdd3273dce4e74a5474c401ac7107950635b/src/op_mode/show_dhcpv6.py#L95-L97
Replace format_hex_string(lease.host_identifier_string) to `lease.duid
and lease_display_fields['iaid_duid'] = 'IAID_DUID'
https://github.com/vyos/vyos-1x/blob/44b1bdd3273dce4e74a5474c401ac7107950635b/src/op_mode/show_dhcpv6.py#L44

Confirmed working on "current" branch.

OK, I just noticed the merge to "current" branch.

I'd be glad to help test it, but I checked the repos and didn't see where it got merged in?

I re-created a new VM and it is Not reproducing
I closed it

Interface virtio

vyos@r1# run show interfaces ethernet eth1 physical 
Settings for eth1:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Supported FEC modes: Not reported
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: Other
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        Link detected: yes
Ring parameters for eth1:
Pre-set maximums:
RX:             256
RX Mini:        0
RX Jumbo:       0
TX:             256
Current hardware settings:
RX:             256
RX Mini:        0
RX Jumbo:       0
TX:             256

Pull request for VyOS 1.4