Tested in latest 1.5-rolling-202401190024 release, the commit fails when duplicate static-mapping is configured as expected.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 19 2024
@sdev Quick question on this issue.
Jan 18 2024
I've traced the issue back to a USB device that creates an Ethernet interface on the OS. I suspect that the issue was caused by the USB device not being ready by the time ddclient tried to start and bind to configured interfaces, causing the boot time configuration to fail. Given that this is an edge case that would rarely occur, and now that I have replaced the USB device with an actual Ethernet device, I'm happy to close this bug report.
set firewall auto-ruleset ssh-server enable set firewall auto-ruleset ssh-server interface 'eth7 eth8'
Deprecated commands are deleted.
It should be reimplemented if it is needed in a separate feature request/task
PR https://github.com/vyos/vyos-1x/pull/2852 basic implementation
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
Let's not close it now, as we do not fully understand the cause
That doesn't seem to insert missing leaf nodes, so I rebuilt the installation by copy/paste of commands from existing VM, and it migrated the routes as expected upon upgrade to 1.4-rc2.
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'
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'
Incorrect firewall setting block the communication
We agree not to implement this, at least in the proposed format.
Close it as wontfix.
Waiting for the stable release Release v2.20
In T5947#172846, @kevinrausch wrote:Well, it didn't start on 1.3.2, so I don't know how the empty leaf nodes could have disappeared over time.
Is there a way to force a full rewrite of the config.boot before attempting upgrades?
I can not reproduce it with the above commands. Even not getting any IP address on the DHCP interface lets ddclient start
Jan 17 2024
Well, it didn't start on 1.3.2, so I don't know how the empty leaf nodes could have disappeared over time.
Your original config looks corrupted.
For example
Loopback entry:
loopback lo
Expected entry:
loopback lo { }
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.
So, the problem seems to be with empty leaf nodes missing from my baseline config.
Sounds like a great solution to me, happy to review your PR.
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?
@kevinrausch I cannot reproduce it, all works fine.
before update
vyos@r1# run show conf com | match route6 set protocols static interface-route6 2001:db8::/64 next-hop-interface lo set protocols static table 10 interface-route6 2001:db8::/64 next-hop-interface tun0 set protocols static table 20 interface-route6 2001:db8::/64 next-hop-interface tun1 [edit] vyos@r1# [edit] vyos@r1# run show version
Performed these steps:
- clean, checkout 1.3.5, build, push to internal web host
- rollback VM to 1.3.2 working baseline
- save vyos132.cfg
- add system image https://removed/vyos-1.3.5-private-amd64.iso
- reboot
- compare 1, no changes to config as expected
- add system image https://cdn.vyos.io/1.4.0-rc1/vyos-1.4.0-rc1-amd64.iso
- reboot
- compare 1, confirm routes dropped per T5947 description
- load vyos132.cfg
- compare 1, observe routes have been migrated as expected, below