Creating a veth pair across namespaces now is a multistep process.
Doing it in one shot with this change is clearer as current
namespace never sees peer IF. Also, moving peer into a namespace
may be rather slow, so better avoided.
When deserializing a link related netlink message, if no network namespace id
attribute is specified, we need to set it to -1 otherwise it defaults to 0
which is a valid id. Using NewLinkAttrs sets the default values and allows
the user to distinguish an empty value from a missing value
For 4.20 and newer kernels VethPeerIndex() causes a stack corruption as
the kernel is copying more data to golang user space than originally
expected. This is due to a recent kernel commit where it extends veth
driver's ethtool stats for XDP:
https://git.kernel.org/torvalds/c/d397b9682c1c808344dd93b43de8750fa4d9f581
The VethPeerIndex()'s logic is utterly wrong to assume ethtool stats are
never extended in the driver. Unfortunately there is no other way around
in golang than to add serialize/deserialize helpers to have a dynamically
sized ethtoolStats with a uint64 data array that has the size of the previous
result from the ETHTOOL_GSSET_INFO query. This ensures we don't run into
a buffer overflow triggered by kernel's copy_to_user() in ETHTOOL_GSTATS
query (ethtool_get_stats() in kernel). Now, for the deserialize operation
we really only care about the peer's ifindex which is always stored in
the first uint64.
Fixes: 54ad9e3a4c ("Two new functions: LinkSetBondSlave and VethPeerIndex")
Reported-by: Jean Raby <jean@raby.sh>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: phob0s <git@phob0s.pl>
It's not needed for retrieving the veth peer ifindex, and we already
get the set count via earlier ETHTOOL_GSSET_INFO call. Both are copying
veth_get_sset_count() up to user space in veth case (which is the only
user of this anyway).
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
This PR refers to PR@lebauce and add some changes.
- Added some tests to retrieve bond slave information.
- Link.BondSlave is changed to LinkSlave interface.
- BondSlaveState.String() returns UPPER case. (same as iproute2)
- BondSlaveMiiStatus.String() returns UPPER case. (same as iproute2)
- Add a new Link type, IPoIB, that exposes the following IPoIB attributes:
* IFLA_IPOIB_PKEY
* IFLA_IPOIB_MODE
* IFLA_IPOIB_UMCAST
- Suppport Deserialize for IPoIB link attributes in LinkDeserialize()
- Support IPoIB attributes in LinkAdd()
Today netlink package supports Get/Set of a VF's max TX rate
via IFLA_VF_TX_RATE netlink attribute.
This patch add support to Get/Set of a VFs min and max TX rate
via IFLA_VF_RATE netlink attribute.
- Add support to set min/max tx rate for VF via IFLA_VF_RATE
- Added IFLA_VF_RATE min/max tx rate attributes to netlink.VfInfo
including parsing support in netlink.parseVfInfo()
NOTE: According to [1] IFLA_VF_RATE takes precedence over
IFLA_VF_TX_RATE. Dealing with the co-existance of these
netlink attributes is left for the user to handle.
[1]https://lists.openwall.net/netdev/2014/05/22/42
iproute2's own netlink library asserts that the sockaddr sender pid
has to be the one of the kernel [0]. It also doesn't bail out on pid
mismatch but only skips the message instead. We've seen cases where
the latter had a pid 0; in such case we should skip to the next nl
message instead of hard bail out.
[0] https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/lib/libnetlink.c
rtnl_dump_filter_l(), __rtnl_talk_iov()
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
This deserializes the tx queue, and rx queue count on link
deserialization. We already supported it on serialization.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
For tuntap interfaces, return a TunTap Interface instead of
a Generic link when retrieving the interface.
Use netlink extended attributes to populate the Link attributes
for the tuntap link.
In case of older tun driver which does not provide these
attributes, use sysfs to retrieve these attributes.
This commit also adds Owner and Group attributes for the TunTap
Link.
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
XFRM interfaces are available in Linux Kernel 4.19+
When an IF_ID is applied to a XFRM policy and state, the corresponding
traffic will be sent through the virtual interface with the same IF_ID.
Currently each call to Receive() allocates 64K buffer on the heap
for the data to receive from a netlink socket. This is rather costly
considering that in most cases only fraction of this memory is actually
needed.
A quick fix is to make sure that the large buffer does not "escape" -
i.e. that it is sufficient to have it allocated on the stack.
Then only the prefix of the buffer that was actually used
is copied to the heap.
Fix for issue: #379
Signed-off-by: Milan Lenco <milan.lenco@pantheon.tech>
chg: addtl comment and made minor logic optimization as disscussed in PR #296
chg: flipped Persist to NonPersist
chg: comments, only unpersist tuntap if flag is set
chg: tuntap persist optional, allow empty intfc name
chg: added conditional build
Signed-off-by: Ralph Schmieder <ralph.schmieder@gmail.com>
