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

The real bug is it shouldn't allow port-range values as it is not implemented.
Or just add this feature T2798

For this we create text files as the group-config includes (they contain route and other per group config directives, generally around security).

In T3008#78303, @jack9603301 wrote:

Does anyone understand the meaning of these performance data? I don’t know the unit of these data

If I change the double-quotes to single-quotes for all the rules in that firewall, I get this (no changes detected):

@foxbox Will be fixed in the next rolling release.

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

Messaged

@BiMW Can you re-check it?

Not reproducible, VyOS 1.4-rolling-202109300217

set service ipoe-server authentication radius dynamic-author key 'ssss'
set service ipoe-server authentication radius dynamic-author server '192.168.122.11'
set service ipoe-server authentication radius nas-ip-address '192.168.122.11'
set service ipoe-server authentication radius server 192.168.122.11 key 'ciscoradiuskey'
set service ipoe-server interface eth1 client-subnet '192.0.2.0/24'

@FileGo Can you replace double-quotes with single-quotes?

Fixed

sever@sever:~$ ssh [email protected]

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

In T3896#107997, @Viacheslav wrote:

@SquirePug Can you share more details, which templates and parameters did you edit?

Present in 1.4 and 1.3.0-epa1

set service pppoe-server authentication radius server 192.0.2.1 acct-port
Possible completions:
   <1-65535>    Numeric IP port (default: 1813)

@c-po in 1.3.0-epa1 works fine.

What about 1.3.0-epa1?

Re-opened, the same bug in VyOS 1.4-rolling-202109300217

sever@sever:~/docker$ ssh [email protected]

@SquirePug Can you share more details, which templates and parameters did you edit?

Obviously in a perfect world we get "unique" and "stable". I do think giving stability priority makes sense.

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

@lucasec the reason for switching to the platform UUID instead of building up out own one was that it was not "unique".

I surveyed all the hardware I have to see what kind of UUIDs they report:

Implemented in

The DUID is presented in binary inside /var/lib/dhcpv6/dhcp6c_duid to read it back into ASCII use: hexdump -e '"%07.7_ax " 1/2 "%04x" " " 14/1 "%02x:" "\n"' /var/lib/dhcpv6/dhcp6c_duid

You are right @NikolayP but opening an entire subtree might be a bit of overkill.

Unfortunately reverting back the public key did not lead to any good results either.

not yet , we 've been trying with different CT but it's not solve the main problem . I understand that disabling conntrack is not possible because is used for nat.

Perhaps the command should be changed a bit
MSS is a property of the TCP protocol, not IP:

@dmbaturin Did you get my email? If not, please let me know and I will send it again

@RyVolodya can you check a new image and close this task if it was fixed?

Is any work around for this scenario ?

We usually communicate via https://vyos.slack.com

or matrix

sure I will just create a separate VM with a clean VyOS and the card - you got some sort of irc or discord to communicate?

Although a cluster ID might be helpful the real problem is that the routes are reflected to all peers – not just ones that are route reflector clients:

and It's the way to set on Vyos:

set protocols bgp <asn> parameters cluster-id <id>