This is still a issue i build a new image with https://github.com/vyos/vyos-1x/commit/911fe645928750f3ce38061a94c9b6db50db0749 and it was spitting out errors :/

Sorry, I have a question, why are there different codes for operation mode fetch configuration tree and configuration mode fetch configuration tree? Is it because of the uncertainty of the mode of action in the user's actions (such as the possibility of abruptly terminating the command)?

Service still with no description VyOS 1.3-beta-202103170443

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

I think vlan range should be 1-4094

Works correct for q, but still show backtrace by Ctrl+C

:Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/ppp-server-ctrl.py", line 74, in <module>
    main()
  File "/usr/libexec/vyos/op_mode/ppp-server-ctrl.py", line 63, in main
    print(output)
KeyboardInterrupt

Lets change except BrokenPipeError: to except:

@juesor there is a difference in an IPv6 address you explicitly mention as 2606:ab00:abe1::2/127 and an IPv6 EUI64 address.

@juesor, please try my command; it doesn't have ipv6 or eui64 in it and I just double-checked that it works on 1.3.

Is it something with the eui64 in the syntax ?

This is a p2p link between vyos and a VM.

Ok so the IP assignment of the p2p on eth0 needs to be

Assign it with set interfaces ethernet eth0 address 2006:ab00:abe1::2/127

Ok so I need to allocate a /127 to the eth interfaces.

VyOS 1.2.7-rc1 reports:

@Viacheslav . Ok this is not a problem, because we have a workaround with pseudo ethernet interfaces

set interfaces pseudo-ethernet peth1 source-interface 'eth1'
set service pppoe-server interface peth1 
set service pppoe-server interface eth1 vlan-id '50'
set service pppoe-server interface eth1 svlan 1000 vlan-range '1-4095'

Now all looks good and works properly, but need to add better help value

vyos@vyos# set service pppoe-server interface eth3 vlan-id 
Possible completions:
   <text>       VLAN monitor for the automatic creation of vlans (user per vlan)

There are two versions that have been developed, reasonably feature complete, pending testing. One presents an OpenAPI schema of application/x-www-form-urlencoded (multipart forms); the other, application/json. The latter uses middleware (strictly speaking, a custom request and route class, instead of the Starlette middleware capability, although that may change) to intercept multipart requests, so as to remain backwards compatible.

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

https://github.com/jestabro/vyos-1x/tree/stdout_redirected

@dmbaturin, don't forget to backport the other two PRs to 1.3:
https://github.com/vyos/vyatta-cfg-firewall/pull/20
https://github.com/vyos/vyos-1x/pull/730

Waiting on backport to 1.3.

@dmbaturin please cherry-pick this to equuleus. Successfully tested on VyOS-1.3-RC1

Thanks, @erkin --- I'm sure you can cherry-pick from 1.4 to 1.3; 'backporting' is not quite the right word, as it is development branch to stable branch. I really like this solution to the mess that was remote.py.

In T3409#89863, @runar wrote:

What about this? https://docs.vyos.io/en/latest/configuration/firewall/index.html?highlight=Mss#tcp-mss-clamping

I'll give backporting a try. It should be doable as long as Paramiko is in our reach. If not, I'll see if I can cobble together something to check for hostname resolution failure.

What about this? https://docs.vyos.io/en/latest/configuration/firewall/index.html?highlight=Mss#tcp-mss-clamping