dhcp-helper is working perfectly fine with GRE tunnels, see my feature request https://phabricator.vyos.net/T3340
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feb 18 2021
Well, they do work together.
In T2898#87573, @jack9603301 wrote:@wsapplegate Have you finished a patch yet?
Yep, got bitten by that too. It's due to some interface types being absent from src/validators/interface-name. Luckily, the solution is pretty easy, here's a patch which adds l2tpeth and friends to that validator:
Feb 17 2021
@dmbaturin @zsdc Perhaps we could discuss the possibility of changing the dhcp(v6) server to a better server (and what feature changes might exist), which I hope will address the older ISC's better support for interfaces such as PPPOE and the latest dhcp(v6) standard
DHCPd shold be vonsistent for both v4 and v6 - running different daemons is simply bad.
Currently, vyos-configd will explicitly report ConfigError to the console; however, non-fatal warnings or information will not be reported. An example of a non-fatal warning is:
SolarFlare modules present in the kernel for 1.3 and 1.4
vyos@vyos:~$ sudo modinfo sfc filename: /lib/modules/5.10.14-amd64-vyos/kernel/drivers/net/ethernet/sfc/sfc.ko license: GPL description: Solarflare network driver author: Solarflare Communications and Michael Brown <mbrown@fensystems.co.uk> alias: pci:v00001924d00001B03sv*sd*bc*sc*i* alias: pci:v00001924d00000B03sv*sd*bc*sc*i* alias: pci:v00001924d00001A03sv*sd*bc*sc*i* alias: pci:v00001924d00000A03sv*sd*bc*sc*i* alias: pci:v00001924d00001923sv*sd*bc*sc*i* alias: pci:v00001924d00000923sv*sd*bc*sc*i* alias: pci:v00001924d00001903sv*sd*bc*sc*i* alias: pci:v00001924d00000903sv*sd*bc*sc*i* alias: pci:v00001924d00000813sv*sd*bc*sc*i* alias: pci:v00001924d00000803sv*sd*bc*sc*i* alias: pci:v000010EEd00001100sv*sd*bc*sc*i* alias: pci:v000010EEd00000100sv*sd*bc*sc*i* depends: mdio retpoline: Y intree: Y name: sfc vermagic: 5.10.14-amd64-vyos SMP mod_unload modversions parm: vf_max_tx_channels:Limit the number of TX channels VFs can use (uint) parm: max_vfs:Reduce the number of VFs initialized by the driver (int) parm: mcdi_logging_default:Enable MCDI logging on newly-probed functions (bool) parm: rx_refill_threshold:RX descriptor ring refill threshold (%) (uint) parm: irq_adapt_low_thresh:Threshold score for reducing IRQ moderation (uint) parm: irq_adapt_high_thresh:Threshold score for increasing IRQ moderation (uint) parm: interrupt_mode:Interrupt mode (0=>MSIX 1=>MSI 2=>legacy) (uint) parm: rss_cpus:Number of CPUs to use for Receive-Side Scaling (uint) parm: efx_separate_tx_channels:Use separate channels for TX and RX (bool) parm: phy_flash_cfg:Set PHYs into reflash mode initially (bool) parm: debug:Bitmapped debugging message enable value (uint)
Feb 16 2021
Looks good on 1.4-rolling-202102162107 (including migration from self-built 1.2.0-rolling+202102162120).
The translation is working properly now but it is not showing in the command output:
Maybe we should consider using a better proxy server to complete the dhcpv6 agent
Feb 15 2021
Somehow this was lost in translation in my git repo....
Nackported to 1.3 equuleus
Yes, I very much like this, and is what I am imaging with 3., above.
With this new information I see little to none reason to keep the key_mangling() workaround. If we manage to transform all nodes into "proper" syntax we can one day drop it.
PR https://github.com/vyos/vyatta-cfg-firewall/pull/20 is still pending to clean up the following log entry:
@c-po this is an excellent idea, and a useful reference for the bracket notation; this will need a bit of design of how best to slice the problem:
- keeping key_mangling but excluding on tag nodes
- removing key_mangling completely
- removing on a case by case basis with the existing argument to get_config_dict()