Enable 'tc' of iproute2 package on YOCTO - yocto

We're trying to enable Traffic Control (tc) on YOCTO (warrior dist.), while it seems that tc was indeed built into the YOCTO image, when trying to apply a tc filter command we're getting this error:
Error: TC classifier not found
This is the full command that I'm trying:
tc filter add dev ${interface} protocol ip parent 1:0 prio 1 u32 match ip dst ${board_ip} match ip dport ${dport} 0xffff flowid 1:${port_id}
Before that I issue a tc qdisc and tc class commands that are okay.
The kernel that I'm using is 4.19.35-imx8mq+g82acfd1 and it's built (make modules_prepare all)
Thanks in advance!
Nadav.

In order to enable tc we've followed the guidelines in this article:How to enable tc command when building a kernel using Yocto recipes
But as it turns out, in addition to this, one would need to make sure that the specific filters that are going to be used are also enabled. In my case it I needed to enable also NET_CLS_U32 option.

Related

DPDK Switch Representation testpmd flow commands not working

My question is related to a question I asked earlier.
Forward packets between SR-IOV Virtual Function (VF) NICs
Basically what I want to do is use 4 SR-IOV functions of Intel 82599ES and direct traffic between VFs as I need. The setup is something like this (don't mind the X710, I use 82599ES now)
For the sake of simplicity at testing I'm only using one VM running warp17 to generate traffic, send it though VF1 and receive it back from VF3. Since the new dpdk versions have a switching function as described in https://doc.dpdk.org/guides-18.11/prog_guide/switch_representation.html?highlight=switch
, I'm trying to use 'testpmd' to configure switching. But it seems to be test pmd doesn't work with any flow commands I enter. All I get is "Bad argument". For example it doesn't work with this command,
flow create 1 ingress pattern / end actions port_id id 3 / end
My procedure is like this,
Bind my PF(82599ES) with igb_uio driver
Create 4 VFs using following command,
echo "4" | sudo tee /sys/bus/pci/devices/0000:65:00.0/max_vfs
Bind 2 VFs to vfio_pci driver using,
echo "8086 10ed" | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id
sudo ./usertools/dpdk-devbind.py -b vfio-pci 0000:65:10.0 0000:65:10.2
Use PCI passthough to bind VFs to VM and start the VM
sudo qemu-system-x86_64 -enable-kvm -cpu host -smp 4 -hda WARP17-disk1.qcow2 -m 6144 \
-display vnc=:0 -redir tcp:2222::22
-net nic,model=e1000 -net user,name=mynet0
-device pci-assign,romfile=,host=0000:65:10.0
-device pci-assign,romfile=,host=0000:65:10.2
Run testpmd with PF and 2 port representators of VFs
sudo ./testpmd --lcores 1,2 -n 4 -w 65:00.0,representor=0-1 --socket-mem 1024 --socket-mem 1024--proc-type auto --file-prefix testpmd-pf -- -i --port-topology=chained
Am I doing something wrong or is this the nature of testpmd?
My dpdk version is 18.11.9
please note 82599ES uses ixgbe and X710 uses i40e PMD. Both are different and have different properties. As per the documentation comparing ixgbe PMD (http://doc.dpdk.org/guides/nics/ixgbe.html) and i40e PMD (http://doc.dpdk.org/guides/nics/i40e.html) the Flow director functionality that is for the ingress packets (packets received from the external port into ASIC). The function Floating VEB is the feature that you need to use. But this is only present in X710 and not in 82599ES.
To enable VEB one needs to use -w 84:00.0,enable_floating_veb=1 in X710. But this limits your functionality that you will not able to receive and send on physical port.
the best option is to use 2 * 10Gbps, where dpdk-0 is used wrap7/pktgen/trex and dpdk-1 is used by vm-1/vm-2/vm-3. the easiest parameter is to control DST MAC address matching to VF.
setup:
create necessary vf for port-0 and port-1
share the VF to relevant VM.
bind dpdk vf ports to igb_uio.
from traffic generator port-0 in relevant mac address of VF.
[P.S.] this is the information we have discussed over skype.

API Connect 2018 VMware deployment: "host is missing traffic interface" error

I am trying to use InstallAssist (apicup) on ubuntu box to prepare the configuration file (apiconnect-up.yml) as part of creating an OVA file for management(mgmt) subsys.
I am having an issue with defining interfaces for the host (myhost.domain):
When I try apicup hosts list mgmt command, I get the following:
apicmgt01.lab
* host is missing traffic interface
* host is missing public interface
Device IP/Mask Gateway
eth0 192.168.10.166/255.255.255.0 192.168.10.1
The command I used to create the interfaces, based on IBM KC, is this:
picup iface create mgmt apicmgt01.lab eth0 192.168.10.166/255.255.255.0 192.168.10.1
I tried to google how exactly I need to set the those "traffic" and "public" interfaces with no success.
Note:
IBM knowledge reference mentions public_iface_id right after the command "apicup iface create mgmt ..." but it's not mentioned anywhere in the command itself nor anywhere else in the entire page!
With the scarce resource about the topic, I am struggling to get this part done. Any help will be very much appreciated.
I was just struggling with that, too.
If you run apicup subsys get mgmt you can see close to the output's beginning, there are values for public-iface and traffic-iface.
Make sure it's set to the correct value by running apicup subsys set mgmt public-iface=<iface_name> and apicup subsys set mgmt traffic-iface=<iface_name>.

Why does BitBake error if it can't find www.example.com?

BitBake fails for me because it can't find https://www.example.com.
My computer is an x86-64 running native Xubuntu 18.04. Network connection is via DSL. I'm using the latest versions of the OpenEmbedded/Yocto toolchain.
This is the response I get when I run BitBake:
$ bitbake -k core-image-sato
WARNING: Host distribution "ubuntu-18.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
ERROR: OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:
Fetcher failure for URL: 'https://www.example.com/'. URL https://www.example.com/ doesn't work.
Please ensure your host's network is configured correctly,
or set BB_NO_NETWORK = "1" to disable network access if
all required sources are on local disk.
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
The networking issue, the reason why I can't access www.example.com, is a question for the SuperUser forum. My question here is, why does BitBake rely on the existence of www.example.com? What is it about that website that is so vital to BitBake's operation? Why does BitBake post an Error if it cannot find https://www.example.com?
At this time, I don't wish to set BB_NO_NETWORK = "1". I would rather understand and resolve the root cause of the problem first.
Modifying poky.conf didn't work for me (and from what I read, modifying anything under Poky is a no-no for a long term solution).
Modifying /conf/local.conf was the only solution that worked for me. Simply add one of the two options:
#check connectivity using google
CONNECTIVITY_CHECK_URIS = "https://www.google.com/"
#skip connectivity checks
CONNECTIVITY_CHECK_URIS = ""
This solution was originally found here.
For me, this appears to be a problem with my ISP (CenturyLink) not correctly resolving www.example.com. If I try to navigate to https://www.example.com in the browser address bar I just get taken to the ISP's "this is not a valid address" page.
Technically speaking, this isn't supposed to happen, but for whatever reason it does. I was able to work around this temporarily by modifying the CONNECTIVITY_CHECK_URIS in poky/meta-poky/conf/distro/poky.conf to something that actually resolves:
# The CONNECTIVITY_CHECK_URI's are used to test whether we can succesfully
# fetch from the network (and warn you if not). To disable the test set
# the variable to be empty.
# Git example url: git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=master
CONNECTIVITY_CHECK_URIS ?= "https://www.google.com/"
See this commit for more insight and discussion on the addition of the www.example.com check. Not sure what the best long-term fix is, but the change above allowed me to build successfully.
If you want to resolve this issue without modifying poky.conf or local.conf or any of the files for that matter, just do:
$touch conf/sanity.conf
It is clearly written in meta/conf/sanity.conf that:
Expert users can confirm their sanity with "touch conf/sanity.conf"
If you don't want to execute this command on every session or build, you can comment out the line INHERIT += "sanity" from meta/conf/sanity.conf, so the file looks something like this:
Had same issue with Bell ISP when accessing example.com gave DNS error.
Solved by switching ISP's DNS IP to Google's DNS (to avoid making changes to configs):
https://developers.google.com/speed/public-dns/docs/using

Disable a standard systemd service in Yocto build

I need to start my own systemd service, let's call it custom.service. I know how to write a recipe for it to be added and enabled on boot:
SYSTEMD_SERVICE_${PN} = "custom.service"
SYSTEMD_AUTO_ENABLE_${PN} = "enable"
However, it conflicts with one of the default systemd services - systemd-timesyncd.service.
Is there a nice preferred way to disable that default systemd service in my bitbake file even though the systemd_XX.bb actually enables it?
I can create a systemd_%.bbappend file to modify the systemd settings, but I can't locate the place where one service can be disabled leaving all others enabled.
The working solution I found is to remove the timesyncd altogether using
PACKAGECONFIG_remove = "timesyncd"
But I wonder if this is a appropriate way and if there is a way to just disable it, but leave in the system.
How about adding a .bbappend recipe for the conflicting service you want disabled. In it, you would add:
SYSTEMD_AUTO_ENABLE_${PN} = "disable"
If the system runs fine with the other package removed, then removing the package is a preferred solution. Fewer packages means a simpler system.
Usually you would set SYSTEMD_AUTO_ENABLE_${PN} = "disable" and that would let the service be part of image but disabled on boot. However for systemd which provides a lot of default service units this may not be a solution you might want to deploy. You could surgically delete the symlink in etc which will ensure that service is not started automatically on boot but the .service file is still part of image. So add following to systemd_%.bbappend file in your layer
do_install_append() {
rm -rf ${D}${sysconfdir}/systemd/system/sysinit.target.wants/systemd-timesyncd.service
}
There are other ways to disable this e.g. using systemd presets as described here
Use the systemd.preset — Service enablement presets and in particular following steps.
Create a .bbappend file meta-xxx/recipes-core/systemd/systemd_%.bbappend with this content:
do_configure_append() {
#disabling autostart of systemd-timesyncd
sed -i -e "s/enable systemd-timesyncd.service/disable systemd-timesyncd.service/g" ${S}/presets/90-systemd.preset
}
In my yocto-based Linux distribution (yocto zeus release) above steps are enough to disable the service which remains installed.
In the output distribution previous steps modify the file /lib/systemd/system-preset/90-systemd.preset.
After the modification, in that file, appear the row: disable systemd-timesyncd.service and this row substitutes the raw: enable systemd-timesyncd.service
At this link there are some information about the topic: systemd.preset — Service enablement presets.
Other useful.
I was not able to use SYSTEMD_AUTO_ENABLE_${PN} = "disable" in this context.
For other recipes (for example dnsmasq_2.82.bb) the previous assignment works correctly and I have used it to enable (or disable) a service in the yocto distribution.
I think the "official" way to do this is to have something like this somewhere in your project:
PACKAGECONFIG_append_pn-systemd = "--disable-timesyncd"
This does basically the same you already suggested. To simply not enable the service you have to do it manually since you can modify the auto enable only per recipe.

Adding queues to switch of ofsoftswitch13 implementation doesnt work

Im trying to add queues (bound to ports) to several switches of an emulated network environment by mininet.
The used switch implemention is ofsoftswitch13
Command to start mininet:
sudo mn --custom mininet-mesh-topology.py --topo test --controller remote,ip=192.168.56.1,port=6653 --switch=user,protocols=OpenFlow13 --link tc
When i try using:
sudo dpctl unix:/tmp/s1 queue-mod 1 1 10
it returns :
SENDING (xid=0xF0FF00F0):
expmodqueue{port="1", queue={q="1", props=[minrate{rate="10"}]}}
RECEIVED (xid=0xF0FF00F0):
error{type="QUEUE_OP_FAILED", code="EPERM", dlen="56"}
The error message indicates, that there is probably a permission error,
but I dont know how to solve this.
Flow inserting / modification works as expected, whether done by dpctl or an sdn controller.
Can anyone help ?
I managed now to solve my own question.
For those, who are interested:
The ofsoftswitch13 utilizes two main components:
ofprotocol
ofdatapath
It appears that default settings of mininet includes the usage of the ´´no--slicing´´ option within the ofdatapath cmd, which prevents me from adding queues.
So the basic solution is to run ofdatapath without the mentioned option flag.
As I create my virtual network with mininet, i had to change one line of mininet python files.
In ./mininet/mininet/node.py change the line 923 from:
def __init__( self, name, dpopts='--no-slicing', **kwargs ):
to
def __init__( self, name, dpopts='', **kwargs ):
Afterwards rebuild mininet with
sudo make install
If you use now mininet to create your network, the mentioned flag isnt used anymore and adding queues is possible!
Hope it helps, if anyone struggles the same issue.
Thanks for sharing your answer!
I just figured that《RYU SDN Framework》provides another way to solve this question(chapter 12.4):
class SliceableSwitch(UserSwitch):
def __init__(self,name,**kwargs):
UserSwitch.__init__(self,name, dpopts='', **kwargs)
Similar to your way, but no need to rebuild mininet.