Merged and looks working

Wontfix due the old firewall backend.
Do not have those bugs for 1.4/1.5

It is mostly impossible to use tags as each tag requires the same packages/binaries which were relevant for each tag

@Rhongomiant Is it still relevant?

Wontfix due to the old backend.

Still relevant for 1.3.5

vyos@r1# commit
[ vpn ipsec site-to-site peer TST2 tunnel 0 ]
VPN configuration error: Can not use local-subnet or remote-subnet when using transport mode

Needs to revisit
Close it for now, as the parent task is closed.

Fixed in 1.3.5

vyos@r1# set interfaces ethernet eth1 address '203.0.113.1/24'
[edit]
vyos@r1# 
[edit]
vyos@r1# set interfaces tunnel tun0 address '100.64.0.1/30'
[edit]
vyos@r1# set interfaces tunnel tun0 encapsulation gretap
[edit]
vyos@r1# set interfaces tunnel tun0 source-address '203.0.113.1'
[edit]
vyos@r1# set interfaces tunnel tun0 mtu '1500'
[edit]
vyos@r1# set interfaces tunnel tun0 multicast 'enable'
[edit]
vyos@r1# set interfaces tunnel tun0 parameters ip ttl '64'
[edit]
vyos@r1# set interfaces tunnel tun0 remote '203.0.113.2'
[edit]
vyos@r1# set system sysctl custom net.ipv4.conf.tun0.accept_local value '1'
[edit]
vyos@r1# commit
[edit]
vyos@r1# sudo sysctl net.ipv4.conf.tun0.accept_local
net.ipv4.conf.tun0.accept_local = 1
[edit]
vyos@r1#

Close it as wontfix for 1.3.
We use KEA-DHCP-server for 1.5
Reopen it for KEA task if it is necessary.

Fixed and not actual bug for 1.5:

vyos@r4# set interfaces bridge br0 member interface eth1.10
[edit]
vyos@r4# set interfaces ethernet eth1 vif 10 address 100.64.0.1/24
[edit]
vyos@r4# commit
[ interfaces ethernet eth1 ]
Cannot assign address to interface "eth1.10" as it is a member of bridge
"br0"!

Wontfix due to the old backend implementation.

The minimal options were increased

There are no other reports
close it

PR was rejected

Mark as wont fix as we do not maintain the MIBs, should be fixed by upstream

Stil reproduced

vyos@r1# run show ver

Seems fixed

vyos@r1# save scp://vyos:superpass@192.168.122.14:/home/vyos
Saving configuration to 'scp://vyos:superpass@192.168.122.14:/home/vyos'...
Host '192.168.122.14' not found in known hosts.
Fingerprint: 5e466b0c69fae2aa89723849a331d0b7
Do you wish to continue? [y/N] y
Done
[edit]
vyos@r1# 
vyos@r1# run show version

Both tasks were solved
Reopen it if necessary

There are no responses from the author.
Reopen it if it sill bug

We have not planed for the near future.
Reopen if necessary.

Still bug for 1.3.5

set protocols bgp 4200010000 address-family ipv6-unicast redistribute connected
set protocols bgp 4200010000 address-family ipv6-unicast redistribute static
set protocols bgp 4200010000 neighbor 2001:db8::2 address-family ipv6-unicast
set protocols bgp 4200010000 neighbor 2001:db8::2 peer-group 'CUST_CR_IPV6'
set protocols bgp 4200010000 peer-group CUST_CR_IPV6 address-family ipv6-unicast
set protocols bgp 4200010000 peer-group CUST_CR_IPV6 remote-as '65500'

IGMP was migrated to PIM https://github.com/vyos/vyos-1x/commit/383231dae8c01ea58d0c956688ecd87f739be97e

Impossible with FRR

r1# conf t
r1(config)# no ipv6 prefix-list PUB seq 10 permit 2001:db8::/32 le
% Command incomplete: no ipv6 prefix-list PUB seq 10 permit 2001:db8::/32 le
r1(config)#

If the problem exists, it should be fixed on accel-ppp site.
I am not sure that I can help here as it is written on C

Create a new task and provide links and examples for the KEA-DHCP-server implementation if it is supported.
ISC-DHCP-server is deprecated.

ISC-DHCP is deprecated, and we do not expect new updates.
The 1.5 is migrated to KEA-DHCP
Close it as wontfix

Since it didn't function properly in either Quagga or FRR...
I suggest addressing this issue to the upstream codebase, as we currently do not maintain SNMP MIBs. Your attention to this matter would be greatly appreciated.

Since it didn't function properly in either Quagga or FRR...
I suggest addressing this issue to the upstream codebase, as we currently do not maintain SNMP MIBs. Your attention to this matter would be greatly appreciated.

After some research, I have concluded that the error was caused by the string's violation of RFC 3986, which recommends using percent encoding instead. I'll look into the feasibility of implementing percent encoding/decoding (which urllib natively supports) for spicy characters if there's demand, but the recommended method in VyOS right now is using the protocol-agnostic REMOTE_USERNAME and REMOTE_PASSWORD environment variables, which bypass the URL decoding step. The alternative would involve messing with urllib.parse's internal parser to implement a laxer and less greedy regexp to accept passwords like this, which is probably a bad idea.

Seems fixed:
Before reboot:

set interfaces ethernet eth1 description 'LAN'
set interfaces ethernet eth1 hw-id '52:54:00:04:33:2b'
set interfaces ethernet eth1 vif 20 address 'dhcp'
set interfaces ethernet eth1 vif 20 disable

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

The commit in question was added after the VyOS 1.3.5 release

PR https://github.com/vyos/vyatta-op-vpn/pull/38

It is still a bug and was reproduced in T5926

Deleting was described there T3843 and seems steel relevant

This issue seems to appear only with 1.3 but not with 1.4