Git Product home page Git Product logo

upf-bpf's Introduction

πŸ“ NOTE 1: This is still an experimental project. The releases were just for quick access of the artifacts presented in the publications (See docs folder.)

πŸ“ NOTE 2: There is task force to improve and integrate the upf-bpf project inside the OAI 5G UPF. See here for more information.

5G UPF using BPF/XDP

An open source C++ library powered by BPF/XDP for user planes in the mobile core network (5G/LTE).

The key pillars of this project are:

  • In-kernel fast packet processing
  • Flexible and programmable dataplane
  • Portable to different systems

These points are achieved mainly by BPF/XDP and CO-RE (Compile Once - Run Everywhere) technologies.

This project is based on the following 3GPP Technical Specification:

  • LTE; 5G; Interface between the Control Plane and the User Plane nodes (3GPP TS 29.244 version 16.5.0 Release 16)
  • 5G; System architecture for the 5G System (5GS) (3GPP TS 23.501 version 16.5.0 Release 16)

The main goal is to enable in-kernel fast packet processing in third-party UPF/5G or SPGWu/LTE components in order to:

  1. Boost them for those which does not have any fast packet processing enabled, or
  2. Co-locate them with other fast packet processing solutions (e.g. DPDK)

Possible scenarios that take advantage of this type of technology: MEC, 5G NPN (Non Public Networks), on-premise, 5G enterprise, and much more.

Design

The library is divided in layers:

  • Management Layer: An user space layer responsible to receive requests from the third-party UPF/SPGWu components to manage PFCP sessions and BPF programs lifecycle
  • Datapath Layer: A kernel space layer representing by BPF/XDP programs responsible to handle the user traffic (datapath) for fast packet processing

The high level design is shown in figure below.

drawing

The library has a component, called PFCP Session Manager, which is a C++ API responsible for managing PFCP (Packet Forwarding Control Protocol) sessions. This layer selects the highest PDR and its rules for each PFCP session to compose the datapath Linux kernel. It is the eBPF Program Manager, which is responsible for loading/unloading the BPF programs. The BPF program is mapped to each rule defined in highest precedence PDR (e.g. FAR) for each PFCP session created. The fast path is composed of three main functions: Parser, Detection (both in entry BPF section) and Rule. The image below shows this in more detail.

drawing

  • Parser: responsible to parse the GTP and UDP packets
  • Detector: responsible for matching the Packet Detection Information (TEID, source interface and UE IP address) with the header of the packet. If matches, so the rules of the PFCP session context must be applied
  • Rule: responsible to encapsulate the logic of one rule (e.g. FAR, QER, BAR, etc). Depending on the PFCP session context, it might have more than one rule available in the datapath.

The FAR is mandatory according to the 3GPP specification

A low-level design (Datapath Layer) is shown below.

drawing

Activity Diagrams

Figure: PFCP session creation activity diagram in Management Layer.

drawing

Figure: On new packet received activity diagram in Datapath Layer. There are two pipeline: one with only the FAR and the other one with QER and FAR.

drawing

Features

As described in 3GPP TS 29.244, the Information Elements (IEs) are part of the PFCP context. The PFCP context is created by sending a PFCP Session Establishment Request message. The main features supported in this project are:

Management Layer - CRUD

  • PFCP Session
  • PDR (Packet Detection Rule)
  • FAR (Forwarding Action Rule)

Fast Datapath Layer

  • UDP and GTP parse
  • Traffic detection based on PDR
  • Traffic forwarding based on FAR

The logical data model between PFCP Session and IEs is shown in the image below. For more detail, see 3GPP TS 29.244 version 16.5.0 Release 16.

drawing

🚧 Future Work

  • QER (QoS Enforcement Rule)
  • CO-RE for tracing.
  • PoC with OpenAirInterface

Main Dependencies

Core

  • libbpf
  • bpftool
  • spdlog
  • clang >= version 3.4.0
  • llvm >= version 3.7.1
  • kernel-headers => version 5.4
  • cmake >= 3.16

Test

  • trex v2.86
  • sysstat (mpstat)
  • ethtool
  • gtest

First Steps

First of all, make sure you have installed git-lfs. The LFS repository is used to store the bpftool binary.

After downloaded and installed it, clone this repository:

git clone https://github.com/navarrothiago/upf-bpf.git

After cloning the repository, configure your env.sh file (on the repository root folder) to match your dev or test environment, using the .env.sample.sh file as a template

The project uses a docker container to build the UPF library. The command below will provision the docker image with all the project dependencies.

πŸ“ You'll need the Docker Container Runtime package and the Docker Compose utility to set up the dev or test environment

make docker-build

After that, run the container with:

make docker-run

You can also use the vscode development container feature to build the image and login into the container. Check here to understand how to open the devcontainer.json file.

Inside the container, compile the dependencies with

make setup

Build and Installation

The library is built and installed with

make install

The package folder is created with the headers, library and some binaries for testing.

package
β”œβ”€β”€ bin       # Contains binaries for testing
β”œβ”€β”€ include   # Contains headers
β”œβ”€β”€ lib       # Contains libupf_xdp.a library
└── tests     # Contains scripts for testing

How to Test

The test is based on RFC2544-like measurements. The testbed is composed of two servers: Trex Traffic Generator and HTTP API + upf-bpf.

Requirements:

  • Both machines with Ubuntu 20.04.02 LTS installed with Linux kernel v5.4.0-72-generic. One machine is used to generate user traffic with TRex Traffic Generator and the other is the DUT (Device Under Test) where the upf-bpf is deployed.
  • Both machine contains two NICs
    • For the Trex traffic generator, both NICs drivers must support DPDK. Check out the Table 5 - Supported NICs
    • For DUT, both NICs drivers must support XDP. Check out here.

Test environment:

drawing

Network topology:

drawing

Setup Trex Traffic Generator Server

This machine must have installed the Trex traffic generator. You can check the trex manual or you can based on the scripts that are called when make trex is executed (unstable).

Setup HTTP API + upf-bpf Server

After running make install inside the docker container, copy the application ./package/bin/api to the DUT machine. Your host must have kernel >= v5.4.

Steps:

  1. Run Trex Traffic Generator
  2. Run HTTP API + upf-bpf
  3. Configure interfaces (/configure)
  4. Create PFCP Session context (/createSession)
  5. Configure the number of Rx queue in DUT
  6. Generate the GTP/UDP flows (pkt size = 64B)
  7. Collects metrics (CPU load, packet loss, throughput)

For step 1, see the trex manual

For step 2, run HTTP API + upf-bpf with:

sudo ./bin/api 10.1.1.27 80

For steps 3 and 4, there are Postman files are available: Uplink and Downlink. Check the JSON message for each step.

For steps 5, 6 and 7, it was implemented a Python script to automate the process. The script executes the test case varying the number of the rx queue. In the end, a report is generated based on JSON format with all the metrics (i.e throughput and CPU load) for each execution. The flows leverage the Trex Field Engine to generate the flows. You can also generate the flow manually in the Trex Traffic Generator server.

In order to execute the script, run the following command inside the docker container:

export PYTHONPATH='/workspaces/tests/trex/trex_client/interactive/'

# example to generate GTP flow with 12mpps of throughput.
./tests/trex/test_cases/run.py -m 12mpps -p <password_trex_server> -f gtp
# example to generate UDP flow with 100% of throughput.
./tests/trex/test_cases/run.py -m 100% -p <password_trex_server> -f udp

πŸ“ The env.sh file must be configured properly in order to have a successful execution.

There is a tmux session script available here that were developed to a specific scenario. Some parameters are hardcoded. Feel free to change according to your needs. If you need any help, open an issue or contact me. PR are welcome!!

drawing

⚠️ Some scripts were developed to work in one environment. As you can see in .env.sample.sh, there are variables to configure the jump server, trex version, GTP and UDP interfaces (downlink and uplink), etc. You might face some problems when trying to execute some of them, because they were not exhaustive tests in other environments.

UTs

Some UTs were developed for the Session Management layer. You can execute inside the container:

make config-veth-pair
make build-tests
make run-session-manager-tests

If you face any problem, feel free to open an issue or contact me.

πŸš€ Benchmark

Setup: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 32GiB of the DRAM, 15M of L3 cache, 6 cores (hyper-threading disabled), dual-port 82599ES 10-Gigabit SFI/SFP+ NIC. Both machines have Ubuntu 20.04.02 LTS installed with Linux kernel v5.4.0-72-generic.

Disable the hyper-threading with echo off > /sys/devices/system/cpu/smt/control

Downlink Uplink
drawing drawing
drawing drawing

Check the Jupyter notebook to see how the graphics are generated.

πŸ“ For more graphics, check this folder.

Time spent to inject BPF program into the kernel after receive the PFCP Establishement Request message.

Version BPF section BPF Insn Injection (ms)
v1.0.0 PFCP Session 402 27
v2.0.0 FAR 272 1

πŸ“ The main reason is due the logic related to lookup the PDR is implemented in the control plane (Management Layer) in v2.0.0 and in the data plane in v1.0.0. The PFCP session was composed with only one FAR.

Jupyter Notebook

The data collected for uplink (GTP decapsulation) and downlink (GTP encapsulation) e2e testing are available:

Firstly, you need to install the python dependencies:

# create our virtual environment
python3 -m venv env
# activate our virtual environment
source env/bin/activate
# install dependencies
pip3 install -r requirements.txt

Now, you can execute notebook using Jupyter.

Tree

β”œβ”€β”€ build: Generated build directory.
β”œβ”€β”€ cmake: Cmake files configuration directory
β”œβ”€β”€ extern: Submodule repositories
β”œβ”€β”€ include: Include files
β”œβ”€β”€ samples: Samples like XDP BPF hello world
β”œβ”€β”€ src: Source files directory
β”œβ”€β”€ tests: UTs, HTTP API srcs, scripts for testing, trex installation
β”œβ”€β”€ Makefile: Encapsulate cmake calls for build, run samples, clean, etc
└── README.md: Readme file

Trex Traffic Generator

If you faced FileNotFoundError: [Errno 2] No such file or directory: b'liblibc.a' when executing trex, for instance:

 cd tests/scripts/../trex/v2.87; sudo ./trex-console --port 1235 --async_port 1236

Create a symbolic from libc.a -> liblibc.a (Manjaro)

sudo ln -s -f /usr/lib64/libc.a /usr/lib64/liblibc.a

Contribute

If you think this could be better, please open an issue or start a discussion.

PRs ARE WELCOME πŸ‘

⭐ BibTeX

The paper is available here.

@INPROCEEDINGS{Amar2110:Kernel,
AUTHOR="Thiago Arruda Navarro do Amaral and Raphael {Vicente Rosa} and David Moura
and Christian {Esteve Rothenberg}",
TITLE="An {In-Kernel} Solution Based on {XDP} for {5G} {UPF:} Design, Prototype
and Performance Evaluation",
BOOKTITLE="2021 1st Joint International Workshop on Network Programmability and
Automation (NetPA 2021)",
ADDRESS="Izmir, Turkey, Turkey",
DAYS=24,
MONTH=oct,
YEAR=2021,
KEYWORDS="5G; XDP; UPF",
ABSTRACT="The edge computing infrastructure can scale from datacenters to single
device. The well-known technology for fast packet processing is DPDK, which
has outstanding performance regarding the throughput and latency. However,
there are some drawbacks when the usage is done in the edge: (i) the
polling mechanism for packet processing keeps the CPU exclusively occupied
even if there is no traffic, leading to wasted resources; and (ii) DPDK
interface becomes unavailable for the applications inside the host, so the
integration between a non-DPDK application and a DPDK application becomes a
hard task. In this paper, we propose an open-source in-kernel 5G UPF
solution based on 3GPP Release 16 to be deployed in a restrictive
environment like MEC, where MEC host and UPF are collocated with the Base
Station, sharing the same computational and network resources. The solution
leverages the eBPF/XDP, a novel Linux kernel technology for fast packet
processing. We show it can scale and achieve 10 Mpps using only 60\% of the
CPU with 6 cores."
}

πŸ““ Contacts

ℹ️ References

upf-bpf's People

Contributors

marcofaltelli avatar navarrothiago avatar rpierini avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

upf-bpf's Issues

Implement redirect XDP action in UL direction after match the rules

Using dummy rules.
setup-for-GPDU-debug-issue-2-upf-bpf (1)
The environment was based on [8].
It is not possible to redirect packet from NIC to Wifi using XDP [5].

  • Create a redirect sample
  • Refactor redirect sample (Makefiles, etc)
  • Implement redirect in UPF UL direction (Only IPv4)

References:

  1. Red Hat - Presensation
  2. Sample Kernel - xdp_redirect_map_kern.c
  3. XDP-Project
  4. Linux Plumbers Conferece - XDP
  5. Stackoverflow - How to forward packet between NIC and WIFI using XDP
  6. Netconf - Veth XDP Container
  7. LWN - Generic XDP
  8. LWN - Implement XDP bpf_redirect
  9. Linux Plumblers Conference 2018 - XDP now with REDIRECT

Design gRPC API

The idea is to create an gRPC API to enables integration with UPF/SPGWu that is not implemented with C++.

Implement Forwarding Action Rules (FAR)

The apply rules path diagram is available here.
Uplink data flow using GTP GPDU.

Test Case:

  • CP: Create Packet Detection Rule (PDR)
  • CP: Map Tunnel Endpoint ID (TEID) to PDR in userland
  • CP: Map Session Endpoint ID (SEID) to Session in userland
  • CP: Insert in the maps used to store PDRs by teid (key)
  • Generate traffic GPDU traffic, filling the teid with the same value of the previous steps (see here for more details)
  • UP:Filter GPDU in XDP
  • UP: Restore the PDRs by TEID received from GPDU
  • UP: For each PDR, match the PDRs attribuites accoding to data flow (UP, DL):
    • The TEID from GTP GPDU with the TEID stored in PDR.
    • Source IP from IP header with source address stored in PDI.
    • Interface from PDI with ACCESS or CORE interface (it depends on if it is UL or DL).
  • UP: Restore the Session by SEID available in matched PDR
  • UP: Apply the Forwarding Action Rules (FAR)
  • CP: Check the output

Error: redefinition of 'struct bpf_insn' using pcapplusplus

linux/bpf.h:65:8: error: redefinition of 'struct bpf_insn'
 struct bpf_insn {
        ^~~~~~~~
In file included from /usr/include/pcap/pcap.h:51:0,
                 from /usr/include/pcap.h:43,
                 from /usr/local/include/pcapplusplus/PcapDevice.h:17,
                 from /usr/local/include/pcapplusplus/PcapLiveDevice.h:5,
                 from /usr/local/include/pcapplusplus/PcapLiveDeviceList.h:5,
                 from /workspaces/openair-cn-cups/test/integration/spgwu_tests.cpp:12:
/usr/include/pcap/bpf.h:238:8: note: previous definition of 'struct bpf_insn'
 struct bpf_insn {

here suggest to define PCAP_DONT_INCLUDE_PCAP_BPF_H, but here suggest avoiding this approach.

PoC with OpenAirInterface (OAI) SPGWu

Because the upf-bpf is a C++ library, a good candidate to do this integration is the OpenAirInterface's SPGWu, which is also implemented using C++. Here is some suggestion of task for this PoC:

  • Deploy the OAI spgwu
  • Create/Find a component to send the PFCP messages to spgwu [1][2]
  • Test OAI with the setup below
  • Compile the OAI with upf-bpf library
  • Test OAI + upf-bpf with the same setup

[1] - I didnt find any open source tool that could be a PFPC client (e.g. here).
[2] - I have some hardcoded implementation. Check here. The idea is to inject the ITTI messages in SPGWu. The ITTI is a m

The test case description is defined here.

image

After run sample, tracer is not working

Run sample using make run-samples and the output was:

# tracer: nop
#
# entries-in-buffer/entries-written: 0/0   #P:8
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |     

make the environment's deps explicit in the README

Hello!

I tried to blindly follow the instructions in the First Steps part of the README to set up the environment, and there were some issues that may be interesting to review:

  1. It's necessary to install at least the "Make" and "Docker" packages (seems obvious, but maybe not to someone new) to make it possible to run the commands and build the containers
  2. If the files that's copied in the docker/build_docker script doesn't exists, the script fails with an errorn1. I believe the RSA keys are important for the build (I didn't analyze the script deeply), but the .gitconfig and ssh_config may be optional. Isn't it better to test if those files exists and add some notes or external link in the docs about how to generate them?

I'm not used to Github, but if I can help with those, please let me know :)

Implement debug messages for G-PDU packets

The idea is create a basic implemantion in order to trace GTP G-PDU packets with debug messages.

  • If packet is GTP GPDU print a message: "GTP GPDU received"
  • If not, print a message: "Non GTP GPDU received".

Test environment:
setup-for-GPDU-debug-issue-2-upf-bpf

Test Case:

  • Open terminal in Linux #0
  • Build, load and run program with make run in Linux #0
  • Generate GTP G-PDU using Scapy with gtpu-traffic-generator.py in Linux #1
  • Open other terminal tab in Linux #0
  • Run sudo tcpdump -i <NIC1 INTEFACE>, where NIC1 INTERFACE is the network interface
  • Open other terminal tab in Linux #0
  • Run sudo cat /sys/kernel/debug/tracing/trace | grep "GPDU" in Linux #0
  • Check if there is a message GTP GPDU received

Code reference:

Create repository with BPF hello world sample using cmake and XDP

GTP packet generation

Hi,
Can I use the run.py file itself to generate the gtp packets or do I need to setup the Upf-bpf and run according to Doc.

def create_gtp_pkt_flow(size, ip_min, ip_max, nflows, field):
print("{} flow will be generated...".format(nflows))
base_pkt = Ether()/IP(src="172.20.16.99", dst="192.168.15.12")/UDP(dport=2152) / \
GTP_U_Header(teid=100) / \
IP(src="10.10.10.10", dst="10.1.3.27", version=4)/UDP(dport=1234)
pad = max(0, size - len(base_pkt)) * 'x'
return STLPktBuilder(pkt=base_pkt/pad, vm=create_vm(ip_min, ip_max, nflows, field))

Iam new to this if there is any way to generate gtp packets directly from run.py can you please help me with this. what are the args to be passed while running.

how to work with free5gc

If free5gc' NF as control plane, how to configure this UPF-BPF, for example: N3 INTERFACE 、 N6 INTERFACE、 N4 INTERFACE

Implement DL data path

Based on Federico Parolo Thesis (Prototyping an eBPF-based 5G Mobile Gateway)

  1. Check if incoming packet is an IP packet with an associated TEID.
  2. Lookup the destination address to find the IP of the tunnel endpoint.
  3. Lookup PDRs based on the destination address
  4. Push external headers: the IP header with the IP of the current interface as source address and the IP of the remote base station as destination address, the UDP header with destination port 2152 and the GTP header with the TEID read from packet metadata.
  5. Send the packet out of the interface.

Implement logic to get session by SEID available in stored hash map

Implement logic to get session by SEID. The SEID is available in PDR stored inside the hash map (TEID->PDR).

Test Case:

  • Map TEID to PDR in userland
  • Map SEID to Session in userland
  • Insert in the maps used to store PDRs by teid (key)
  • Generate traffic GPDU traffic, filling the teid with the same value of the previous steps (see here for more details)
  • Filter GPDU in XDP
  • Restore the PDR by TEID received from GPDU
  • Restore the Session by SEID available in restored PDR
  • Check Session retostored

References:

Encapsulate includes and library in a cmake config

The ideia is to make easier the usable of the framework
Includes:

include_directories(${SRC_TOP_DIR}/../build/ext/upf-bpf/include)
include_directories(${SRC_TOP_DIR}/../build/ext/upf-bpf/src)
include_directories(${SRC_TOP_DIR}/../build/ext/upf-bpf/src/bpf)
include_directories(${SRC_TOP_DIR}/../build/ext/upf-bpf/build/src/bpf/skel)

Libraries:

${SRC_TOP_DIR}/../build/ext/upf-bpf/build/src/libupf_xdp.a 
${SRC_TOP_DIR}/../build/ext/upf-bpf/extern/libbpf/src/libbpf.a 
elf 
z

Implement logic to lookup PDR based on GTP G-PDU received

TODO:

  • Create struct create_pdr based on PFCP TS 29 244
  • Create BPF maps: teid (key) -> PDR (value)

Test Case:

  • Associate PDR with some teid in userland
  • Insert in the maps used to store PDRs by teid (key)
  • Generate traffic GPDU traffic, filling the teid with the same value of the previous steps (see here for more details)
  • Filter GPDU in XDP
  • Restore the PDR by teid received from GPDU
  • Compare the teid received with the valeu which was filled

References:

Clean up environment

The idea is to load the environment variable before run the scripts.

  • Check README
  • Check compilation (docker and library)

AddressSanitizer: SEGV on unknown address 0x000000000000

Compiled in ubuntu 18.04 and run in ubuntu 20.04

[ebpf@india] ~/package/bin $ cd /home/ebpf/package; sudo ip link set dev enp3s0f1 xdp off; sudo ip link set dev enp3s0f0 xdp off; sudo ./bin/api 10.1.1.27 80                                 
[sudo] password for ebpf:                                                                                                                                                                     
Sorry, try again.                                                                                                                                                                             
[sudo] password for ebpf:                                                                                                                                                                     
[2021-05-23 14:21:02.602] [upf_logger] [info] [220681.901196864] (/workspaces/tests/api/Server.cpp:26) Running server on endpoint 10.1.1.27:80                                                
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] [bgn] Controller::setup                                                                                                     
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] [bgn] RulesUtilitiesImpl::RulesUtilitiesImpl                                                                                
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] [end] RulesUtilitiesImpl::RulesUtilitiesImpl                                                                                
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] (/workspaces/tests/api/Controller.cpp:37) GTP interface: enp3s0f0                                                           
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] (/workspaces/tests/api/Controller.cpp:38) UDP interface: enp3s0f1                                                           
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] [bgn] &UserPlaneComponent::getInstance                                                                                      
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] [bgn] UserPlaneComponent::UserPlaneComponent                                                                                
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] [end] UserPlaneComponent::UserPlaneComponent                                                                                
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] [end] &UserPlaneComponent::getInstance                                                                                      
[2021-05-23 14:21:05.601] [upf_logger] [debug] [220681.849340160] [bgn] UserPlaneComponent::setup                                                                                             
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [bgn] UPFProgram::UPFProgram                                                                                                
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [bgn] ProgramLifeCycle<upf_xdp_bpf_c>::ProgramLifeCycle(std::function<BPFSkeletonType *()>, std::function<                  
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [end] ProgramLifeCycle<upf_xdp_bpf_c>::ProgramLifeCycle(std::function<BPFSkeletonType *()>, std::function<                  
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [end] UPFProgram::UPFProgram                                                                                                
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [bgn] &SignalHandler::getInstance                                                                                           
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [end] &SignalHandler::getInstance                                                                                           
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [bgn] SignalHandler::enable                                                                                                 
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [end] SignalHandler::enable                                                                                                 
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [bgn] UPFProgram::setup                                                                                                     
[2021-05-23 14:21:05.602] [upf_logger] [debug] [220681.849340160] [bgn] *ProgramLifeCycle<upf_xdp_bpf_c>::open                                                                                
libbpf: sec 'xdp_entry_point': failed to find program symbol at offset 0                                                                                                                      
libbpf: failed to initialize skeleton BPF object 'upf_xdp_bpf_c': -4001                                                                                                                       
[2021-05-23 14:21:05.603] [upf_logger] [debug] [220681.849340160] [end] *ProgramLifeCycle<upf_xdp_bpf_c>::open                                                                                
[2021-05-23 14:21:05.603] [upf_logger] [debug] [220681.849340160] [bgn] UPFProgram::initializeMaps                                                                                            
[2021-05-23 14:21:05.603] [upf_logger] [debug] [220681.849340160] [bgn] *ProgramLifeCycle<upf_xdp_bpf_c>::getBPFSkeleton                                                                      
[2021-05-23 14:21:05.603] [upf_logger] [debug] [220681.849340160] [end] *ProgramLifeCycle<upf_xdp_bpf_c>::getBPFSkeleton                                                                      
ASAN:DEADLYSIGNAL                                                                                                                                                                             
=================================================================                                                                                                                             
==220681==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x56545cca2b82 bp 0x7f40329fc3f0 sp 0x7f40329fc180 T2)    
==220681==The signal is caused by a READ memory access.
==220681==Hint: address points to the zero page.
    #0 0x56545cca2b81 in std::_MakeUniq<BPFMaps>::__single_object std::make_unique<BPFMaps, bpf_object_skeleton*&>(bpf_object_skeleton*&) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../
../include/c++/7.5.0/bits/unique_ptr.h:821
    #1 0x56545cca2b81 in UPFProgram::initializeMaps() /workspaces/src/programs/UPFProgram.cpp:88
    #2 0x56545cca1d67 in UPFProgram::setup() /workspaces/src/programs/UPFProgram.cpp:28
    #3 0x56545cc82d46 in UserPlaneComponent::setup(std::shared_ptr<RulesUtilities>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basi
c_string<char, std::char_traits<char>, std::allocator<char> > const&) /workspaces/src/UserPlaneComponent.cpp:95
    #4 0x56545cc61213 in Controller::setup(nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned l
ong, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > >&, nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<c
har, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer, std::vector<unsigned char, std::allocator<unsigned char> > >
&) /workspaces/tests/api/Controller.cpp:40
    #5 0x56545cbcec83 in operator() /workspaces/tests/api/Server.cpp:35
    #6 0x56545cbcf69f in _M_invoke /usr/include/c++/7/bits/std_function.h:316
    #7 0x56545cbea2a2 in std::function<void (httplib::Request const&, httplib::Response&)>::operator()(httplib::Request const&, httplib::Response&) const /usr/include/c++/7/bits/std_function
.h:706
    #8 0x56545cbdde8c in httplib::Server::dispatch_request(httplib::Request&, httplib::Response&, std::vector<std::pair<std::__cxx11::basic_regex<char, std::__cxx11::regex_traits<char> >, st
d::function<void (httplib::Request const&, httplib::Response&)> >, std::allocator<std::pair<std::__cxx11::basic_regex<char, std::__cxx11::regex_traits<char> >, std::function<void (httplib::R
equest const&, httplib::Response&)> > > > const&) /usr/local/include/httplib.h:4881
    #9 0x56545cbddbe8 in httplib::Server::routing(httplib::Request&, httplib::Response&, httplib::Stream&) /usr/local/include/httplib.h:4859
    #10 0x56545cbdf436 in httplib::Server::process_request(httplib::Stream&, bool, bool&, std::function<void (httplib::Request&)> const&) /usr/local/include/httplib.h:5099
    #11 0x56545cbdf774 in httplib::Server::process_and_close_socket(int)::{lambda(httplib::Stream&, bool, bool&)#1}::operator()(httplib::Stream&, bool, bool&) const /usr/local/include/httpli
b.h:5131
    #12 0x56545cbec747 in bool httplib::detail::process_server_socket<httplib::Server::process_and_close_socket(int)::{lambda(httplib::Stream&, bool, bool&)#1}>(int, unsigned long, long, lon
g, long, long, long, httplib::Server::process_and_close_socket(int)::{lambda(httplib::Stream&, bool, bool&)#1})::{lambda(bool, bool&)#1}::operator()(bool, bool&) const /usr/local/include/htt
plib.h:2012
    #13 0x56545cbf6d95 in bool httplib::detail::process_server_socket_core<bool httplib::detail::process_server_socket<httplib::Server::process_and_close_socket(int)::{lambda(httplib::Stream
&, bool, bool&)#1}>(int, unsigned long, long, long, long, long, long, httplib::Server::process_and_close_socket(int)::{lambda(httplib::Stream&, bool, bool&)#1})::{lambda(bool, bool&)#1}>(int
, unsigned long, long, httplib::Server::process_and_close_socket(int)::{lambda(httplib::Stream&, bool, bool&)#1}) /usr/local/include/httplib.h:1994
    #14 0x56545cbec804 in bool httplib::detail::process_server_socket<httplib::Server::process_and_close_socket(int)::{lambda(httplib::Stream&, bool, bool&)#1}>(int, unsigned long, long, lon
g, long, long, long, httplib::Server::process_and_close_socket(int)::{lambda(httplib::Stream&, bool, bool&)#1}) /usr/local/include/httplib.h:2013
    #15 0x56545cbdf82a in httplib::Server::process_and_close_socket(int) /usr/local/include/httplib.h:5131
    #16 0x56545cbdd0ae in httplib::Server::listen_internal()::{lambda()#1}::operator()() const (/home/ebpf/package/bin/api+0x19b0ae)
    #17 0x56545cbf6226 in std::_Function_handler<void (), httplib::Server::listen_internal()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (/home/ebpf/package/bin/api+0x1b4226)
    #18 0x56545cbe6c39 in std::function<void ()>::operator()() const /usr/include/c++/7/bits/std_function.h:706
    #19 0x56545cbd2da7 in httplib::ThreadPool::worker::operator()() (/home/ebpf/package/bin/api+0x190da7)
    #20 0x56545cc1a700 in void std::__invoke_impl<void, httplib::ThreadPool::worker>(std::__invoke_other, httplib::ThreadPool::worker&&) (/home/ebpf/package/bin/api+0x1d8700)
    #21 0x56545cc110ff in std::__invoke_result<httplib::ThreadPool::worker>::type std::__invoke<httplib::ThreadPool::worker>(httplib::ThreadPool::worker&&) (/home/ebpf/package/bin/api+0x1cf0
ff)
    #22 0x56545cc5fc3b in decltype (__invoke((_S_declval<0ul>)())) std::thread::_Invoker<std::tuple<httplib::ThreadPool::worker> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) (/home/ebpf/package
/bin/api+0x21dc3b)
    #23 0x56545cc5fb01 in std::thread::_Invoker<std::tuple<httplib::ThreadPool::worker> >::operator()() (/home/ebpf/package/bin/api+0x21db01)
    #24 0x56545cc5f961 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<httplib::ThreadPool::worker> > >::_M_run() (/home/ebpf/package/bin/api+0x21d961)
    #25 0x7f4035fb9d83  (/lib/x86_64-linux-gnu/libstdc++.so.6+0xd6d83)
    #26 0x7f4036470608 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x9608)
    #27 0x7f4035df8292 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x122292)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/unique_ptr.h:821 in std::_MakeUniq<BPFMaps>::__single_object std::make_unique<BPFMaps, bpf_object_skeleton*&>(bpf_object_skeleton*&)
Thread T2 created by T0 here:
    #0 0x7f40364c2b3f in pthread_create (/lib/x86_64-linux-gnu/libasan.so.4+0x38b3f)
    #1 0x7f4035fba048 in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (/lib/x86_64-linux-gnu/libstdc++.so.6+0xd7048)
    #2 0x56545cc015b9 in void __gnu_cxx::new_allocator<std::thread>::construct<std::thread, httplib::ThreadPool::worker>(std::thread*, httplib::ThreadPool::worker&&) (/home/ebpf/package/bin/api+0x1bf5b9)
    #3 0x56545cbf11db in void std::allocator_traits<std::allocator<std::thread> >::construct<std::thread, httplib::ThreadPool::worker>(std::allocator<std::thread>&, std::thread*, httplib::ThreadPool::worker&&) (/home/ebpf/package/bin/api+0x1af1db)
    #4 0x56545cbf129c in void std::vector<std::thread, std::allocator<std::thread> >::_M_realloc_insert<httplib::ThreadPool::worker>(__gnu_cxx::__normal_iterator<std::thread*, std::vector<std::thread, std::allocator<std::thread> > >, httplib::ThreadPool::worker&&) (/home/ebpf/package/bin/api+0x1af29c)
    #5 0x56545cbe6d9d in void std::vector<std::thread, std::allocator<std::thread> >::emplace_back<httplib::ThreadPool::worker>(httplib::ThreadPool::worker&&) (/home/ebpf/package/bin/api+0x1a4d9d)
    #6 0x56545cbd2a14 in httplib::ThreadPool::ThreadPool(unsigned long) (/home/ebpf/package/bin/api+0x190a14)
    #7 0x56545cbda45f in httplib::Server::Server()::{lambda()#1}::operator()() const (/home/ebpf/package/bin/api+0x19845f)
    #8 0x56545cbf3b49 in std::_Function_handler<httplib::TaskQueue* (), httplib::Server::Server()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (/home/ebpf/package/bin/api+0x1b1b49)
    #9 0x56545cbebc69 in std::function<httplib::TaskQueue* ()>::operator()() const (/home/ebpf/package/bin/api+0x1a9c69)
    #10 0x56545cbdd107 in httplib::Server::listen_internal() (/home/ebpf/package/bin/api+0x19b107)
    #11 0x56545cbdb05f in httplib::Server::listen(char const*, int, int) (/home/ebpf/package/bin/api+0x19905f)
    #12 0x56545cbcf1ab in main /workspaces/tests/api/Server.cpp:46
    #13 0x7f4035cfd0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

==220681==ABORTING

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.