Age | Commit message (Collapse) | Author |
|
It makes no sense to have a parser for the ethtool values in ethtool.py
and ethernet.py - one instance ios more then enough!
(cherry picked from commit 0229645c8248decb5664056df8aa5cd5dff41802)
|
|
Only update the RX/TX ring-buffer settings if they are different from the ones
currently programmed to the hardware. There is no need to write the same value
to the hardware again - this could cause traffic disruption on some NICs.
(cherry picked from commit 29082959e0efc02462fba8560d6726096e8743e9)
|
|
Not all interface drivers have the ability to change the speed and duplex
settings. Known drivers with this limitation are vmxnet3, virtio_net and
xen_netfront. If this driver is detected, an error will be presented to the
user.
(cherry picked from commit cc742d48579e4f76e5d3230d87e22f71f76f9301)
|
|
Ethernet adapters have a discrete set of available speed and duplex settings.
Instead of passing every value down to ethtool and let it decide, we can do
this early in the VyOS verify() function for ethernet interfaces.
(cherry picked from commit 91892e431349ca0edb5e3e3023e4f340ab9b777f)
|
|
SSH keys used for remote login are supplied as base64 encoded data on the CLI.
The key is not validated, thus an invalid copy/pasted key will render the login
useless. This commit adds a custom and re-usable validator which check if the
data is properly base64 encoded.
(cherry picked from commit 00efce716912680354d47a2dca9769cd8c5c89ae)
|
|
(cherry picked from commit 5c29377fa91595088118419275f6d05b1fbfbd1d)
|
|
Deprecated in the Linux Kernel by commit 08a00fea6de277df12ccfadc21 ("net:
Remove references to NETIF_F_UFO from ethtool.").
|
|
An analysis of the code base from VyOS 1.2 -> 1.3 -> 1.4 revealed the following
"root-cause"
VyOS 1.2 uses the "old" node.def file format for:
* Generic Segmentation Offloading
* Generic Receive Offloading
So if any of the above settings is available on the configuration CLI, the
node.def file will be executed - this is how it works.
By default, this CLI option is not enabled in VyOS 1.2 - but the Linux Kernel
enables offloading "under the hood" by default for GRO, GSO... which will boost
the performance for users magically.
With the rewrite in VyOS 1.3 of all the interface related code T1579, and
especially T1637 this was moved to a new approach. There is now only one handler
script which is called whenever a user changes something under the interfaces
ethernet tree. The Full CLI configuration is assembled by get_interface_dict() -
a wrapper for get_config_dict() which abstracts and works for all of our
interface types - single source design.
The problem now comes into play when the gathered configuration is actually
written to the hardware, as there is no GSO, GRO or foo-offloading setting
defined - we behave as instructed and disable the offloading.
So the real bug originates from VyOS 1.2 and the old Vyatta codebase, but the
recent XML Python rewrites brought that one up to light.
Solution:
A configuration migration script will be provided starting with VyOS 1.3 which
will read in the CLI configuration of the ethernet interfaces and if not
enabled, will query the adapter if offloading is supported at all, and if so,
will enable the CLI nodes.
One might say that this will "blow" the CLI configuration but it only represents
the truth - which was masked in VyOS 1.2.
|
|
FRR: op-mode: T3776: rename "restart frr <daemon>" to "restart <daemon>"
|
|
As IS-IS is a new feature and the CLI configuration changed from 1.3 -> 1.4
(required by T3417) it makes sense to synchronize the CLI configuration for
both versions. This means backporting the CLI from 1.4 -> 1.3 to not confuse
the userbase already with a brand new feature.
As 1.3.0-epa1 is on the way and should not contain any CLI changes afterwards,
this is the perfect time.
|
|
(cherry picked from commit d9d923ea4e0bbe0cc154dc2fbdd626585b5d7449)
|
|
(cherry picked from commit 059307f924c604eb2bdeab19a2db8ce6d8e09f90)
|
|
|
|
|
|
(cherry picked from commit 19b16986515dcb58955e153025b24dc012faa574)
|
|
(cherry picked from commit d3ae6304a3eabcddba36452e9519ca7b56bb38af)
|
|
(cherry picked from commit 655876f4c22c0f4ea839a81f4af09d6016e19197)
|
|
(cherry picked from commit 1229665d353a070e14ee9cceafbfdb107d669745)
|
|
(cherry picked from commit 7e52a7079afb522d1456833023ad58fa8b05e880)
|
|
|
|
(cherry picked from commit 0f7833483c0fe4982747bbbace45a83fae793257)
|
|
|
|
|
|
|
|
In this commit we fix the do not fragment capability
for ping commands. Sorry for messing it up earlier :(
(cherry picked from commit d012c732a8902d4848e29f37fcede66a060e3c7f)
|
|
|
|
(cherry picked from commit d77a2f56ea7e76158c07f5829397be4555473e3d)
|
|
|
|
|
|
(cherry picked from commit 0d1ad777daf25ef415bf45032d41b587baf20781)
|
|
|
|
|
|
Re-issuing the same iproute2 commands can lead to errors, simply ignore
them and not raise a Python exception.
(cherry-picked from commit 9920f7340d60b51d32bad9dbd24a907718f72837)
|
|
(cherry-picked from commit 08614557b679c59495b3bf629f763f9a4cc0ed25)
|
|
It is easier to backport the entire vyos.ifconfig library from 1.4 instead of
backporting single pieces which are required to add new feature to the tunnel
interface section.
In addition that both libraries are now back in sync it will become much easier
to backport any other new feature introduced in VyOS 1.4!
|
|
|
|
|
|
|
|
|
|
vyos-1x-vmware: T3682: remove dhclient from ether-resume.py
|
|
to avoid trying to wait for a daemon that shouldn't even be running.
|
|
dhclient is already handled by netplug so it's removed to avoid double
renewing of dhcp leases.
|
|
|
|
|
|
(cherry picked from commit eb8cd3af91bac01a3f7f99b362c8105d69bb3c55)
|
|
|
|
because of typo
change from `bind_to_all` to `bind-to-all`
refer: interface-definitions/vrf.xml.in
(cherry picked from commit 8a78c790c1239eef533c7bbe12911aaeec4dc90f)
|
|
|
|
Executing iproute2 commands as unprivileged member of the openvpn group is now
handled via a sudoers file.
(cherry picked from commit 9c8facc69c09163b74bc428f1dbf8be030766758)
|
|
(cherry picked from commit 6b7b19c93f90839549dd668116c4da2f38cfdc66)
VyOS 1.3 will ship OpenVPN 2.5.1 and thus it is the perfect timing to still
remove this option before introducing it in a new LTS release.
|