Interesting interpretation of the standard. Guess it's time to go bare metal again
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed Search
Apr 18 2025
Apr 18 2025
rchrist updated the task description for T7371: VyOS DHCP Server shared-network concept and behaviour is not properly documented.
Nov 14 2024
Nov 14 2024
rchrist added a comment to T6873: DHCP Option 66 (tftp-server-name) should accept arbitrary strings.
rchrist added a comment to T6873: DHCP Option 66 (tftp-server-name) should accept arbitrary strings.
This is not a bug, this is according to RFC
Nov 13 2024
Nov 13 2024
rchrist updated the task description for T6873: DHCP Option 66 (tftp-server-name) should accept arbitrary strings.
rchrist updated the task description for T6873: DHCP Option 66 (tftp-server-name) should accept arbitrary strings.
May 1 2024
May 1 2024
In T6281#185620, @c-po wrote:You probably should get the wireguard interface running in your default VRF first and see if traffic properly passes - once that's working for oyu you can move it into a VRF. Please not only the decrypted side of the WireGuard interface will reside in the VRF. The side passing encrypted packets ALWAYS is in the default VRF (Linux Kernel)
Apr 29 2024
Apr 29 2024
In T6281#185394, @c-po wrote:Please note that the Wireguard tunnel itself is sourced from the default VRF. Only the "inner side" of the tunnel runs in VRF wan.
There is no possibility to source the wireguard interface from
- Another VRf
- A discrete source IP
- A discrete source interface
This can only be handled by applying fwmark values and policy based routing - this is a WireGuard design thing.
Running into this issue on VyOS 1.5-rolling-202404280021
set protocols static route xxx.xxx.74.149/32 dhcp-interface eth1.999