Tested in latest 1.5-rolling-202401190024 release, the commit fails when duplicate static-mapping is configured as expected.

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

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

@sdev Quick question on this issue.

PR https://github.com/vyos/vyos-1x/pull/2852 basic implementation

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

Will be fixed in 1.4.0-rc3

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.

What are you expecting

This should pretty much explain it

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

Expecting minimal working config:

set qos policy shaper-hfsc SHAPE bandwidth '400mbit'
set qos policy shaper-hfsc SHAPE class 10 linkshare m2 '200mbit'
set qos policy shaper-hfsc SHAPE class 10 match DST ip destination address '192.0.2.1/32'
set qos policy shaper-hfsc SHAPE default linkshare m2 '111mbit'

See https://vyos.dev/T5958

It causes the issue with no qos config after update (from 1.3.5)
Before migration

set traffic-policy shaper-hfsc SHAPE-10mbit bandwidth '400mbit'
set traffic-policy shaper-hfsc SHAPE-10mbit class 10 linkshare m2 '200mbit'
set traffic-policy shaper-hfsc SHAPE-10mbit class 10 match MARK mark '10'
set traffic-policy shaper-hfsc SHAPE-10mbit default linkshare m2 '200mbit'

Waiting for the stable release Release v2.20

Sounds good. I'll do some updates and testing to see if I can move the chains to a dedicated inet table for upnp. The IPv6 use case is probably just to use UPnP/NAT-PMP/PCP to open firewall ports but for completion reasons I'll implement it.

Sounds like a great solution to me, happy to review your PR.

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

Sample config files here: https://github.com/networkupstools/nut/tree/master/conf

I think there are actually two aspects here.

Sure. I did some further testing and it looks like this is triggered if the client sends DHCP option 81 (FQDN). To reproduce:

Which user are you expecting? Hows to check from which user container was started?
Any idea for CLI?

1.4.0-rc2 also has opennhrp service stop after vyos startup. Can you please add a 1.4 tag to this issue?

@Daya @trae32566 Is it not the issue anymore?

I'd tag it as wontfix

Domain name was never configured for FRR in our templates

r4# conf t
r4(config)# domainname 
  WORD  This system's domain name
r4(config)#

Fixed for both VyOS 1.5-rolling-202401140026 and VyOS 1.4.0-rc2

@Nova_Logic Describe what exactly you want to do
Policy and firewalling are possible now

vyos@r4# set firewall ipv4 input filter rule 10 inbound-interface name eth1.v10
[edit]
vyos@r4# set policy route foo interface eth1.v10
[edit]
vyos@r4#

Personally I would prefer that the "automagic" firewall ruleset would be done optionally through method described in:

Good practise add a set of the commands to reproduce
Thanks

I've found some time to do some work on a fork of vyos-1x. I have a working patch to 1.5-rolling that does the following:

I am facing same issue here.
In my case, My laptop hostname is cn002472.xxx.com