I'm trying to figure out how to run a XDP code:
#include <linux/bpf.h>
int main() {
return XDP_PASS;
}
I'm trying to have XDP drop all the packets.
So I compiled it as :
clang -target bpf -c xdp.c -o xdp.o
and my interface name is enp5s0.
So I tried to sort of attach the code to that interface by typing :
ip -force link set dev enp5s0 xdpdrv obj xdp.o sec .text
Then I get the following error :
mkdir /sys/fs/bpf/tc/ failed: Permission denied
Continuing without mounted eBPF fs. Too old kernel?
Prog section '.text' rejected: Operation not permitted (1)!
- Type: 6
- Instructions: 2 (0 over limit)
- License :
Verifier analysis:
Error fetching program/map!
and I have no idea what is wrong.. I'm trying to get a hold of XDP and I've been trying to fix this problem for three days but no result.... I would really appreciate it if you guys would help me out!
can you check kernel version . it should be above 4.8
Do you run ipas superuser? Can you try to run ip -force link set dev enp5s0 xdp obj xdp.o sec .text instead of ip -force link set dev enp5s0 xdpdrv obj xdp.o sec .text? The first use xdp in best effort mode. Maybe your device driver doesn't support XDP-driver.
Another tip: you can specify the section of code you want with SEC("name_section") and then you use name_section instead of .text
Related
In order to use the hcsr-04 ultrasonic sensor using BBB's PRU, I have tried this git :
https://github.com/HudsonWerks/Range-Sensor-PRU
I get the error "the PRU failed to open", when I try to start "rangepru".
Doing some research, I feel like that is because my PRU is not initialized and that I should do : "echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.8/slots" to correct it.
But with the recent debian versions (4.x), the cape manager changed and I found the file "slots" at:
/sys/devices/platform/bone_capemgr/slots ; BUT, there is no way to open, modify it :
- using "nano" I get "slots.swp Permission denied"
- and by typing the correct echo command (modified from the one above) : I get : "write error: No such file or directory"
Best regards,
Elrise
You are probably missing a suitable device tree driver.
Try to follow the instructions on:
https://github.com/luigif/hcsr04
related to the compilation and installation of the driver.
If you have a proper development environment, executing make install should do everything for you.
PC: Debian 9.4.0, x64, ip 192.168.1.10
Qt: Qt Creator 4.6.1 Based on Qt5.11.0
BeagleBone Black: Debian 9.3.0, armv7, ip 192.168.1.20
I cross-compiled an GUI application for the BeagleBone Black on my PC and I can execute it successfully on my BeagleBone.
But when I remotely debug the application with F5(Menu: Debug->Start Debugging), I encounter an issue as follow.
QXcbConnection: Could not connect to display
The application crashes in main() at the line:
QApplication a(argc, argv);
The following are the details when compiling and debugging:
debug details:
Checking available ports...
Found 101 free ports.
Starting gdbserver...
Debugging starts
Listening on port 10001
Remote debugging from host 192.168.1.10
Process /home/debian/gdb/armtest3 created; pid = 13981
Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Could not load shared library symbols for 25 libraries, e.g. /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
-----------------armtest3 start------------
QXcbConnection: Could not connect to display
compile output:
09:31:33: Running steps for project armtest3...
09:31:33: Configuration unchanged, skipping qmake step.
09:31:33: Starting: "/usr/bin/make"
make: Nothing to be done for 'first'.
09:31:33: The process "/usr/bin/make" exited normally.
09:31:33: The remote file system has 218 megabytes of free space, going ahead.
09:31:33: Deploy step finished.
09:31:33: Trying to kill "/home/debian/gdb/armtest3" on remote device...
09:31:37: Remote application killed.
09:31:37: Deploy step finished.
09:31:37: No deployment action necessary. Skipping.
09:31:37: Deploy step finished.
09:31:37: Elapsed time: 00:04.
The following are my BeagleBone Kit：
BeagleBone Kit configuration
main.c
main.c
#include "mainwindow.h"
#include <QApplication>
#include <iostream>
#include <QDateTime>
#include <QDebug>
using namespace std;
int main(int argc, char *argv[])
{
cout << "-----------------armtest3 start------------" << endl;
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
Relevant question: QXcbConnection: Could not connect to display, when trying to debug Linux app with Qt Creator
When you deploy your application and run it from within the X11 system on device itself, you're finding it works because here it has access to the DISPLAY environment variable which (briefly put) tells it where to display itself. This environment variable has been set further up the process tree in your X session.
When you launch a program via the debugger, Qt Creator is connecting to the remote device (via your settings in Tools > Options > Devices), and running the program via ssh. In this context your program no longer knows where to display itself, as obviously it can't display in ssh. It faults on the line you indicated because this is where the XCB subsystem is trying to determine which X-Server to connect to for this purpose.
So to answer your question: you need to manually provide the DISPLAY environment variable when remote debugging.
An easy way to test this is to go to Projects Mode, find the kit you are using to build for the remote device, and select the Run settings. Under this, you should find an Run Environment section. Here you can add a new variable called DISPLAY and set its value to the identifier of the display you are running on (I'm guessing you'll want :0.0, indicating the first available screen on localhost, although you should read about the DISPLAY variable e.g. here or here).
A longer-term, potentially better solution would be to set the same variable in the settings of your Kit (Tools > Options > Build & Run > Kits > Environment). This will then apply for future programs you create using this.
I want to run ifup eth0 and ifdown eth0 without sudo by using Linux capabilitiesFor the same issue I have written code for the same main.c
int main{
FILE ,*fp;
fp = popen("ifdown eth0","r");
if(fp==NULL)
{
printf("popen falied\n")
}
pclose(fp);
}
If I have set capabilities to binary like following :
sudo setcap -v cap_chown,cap_dac_override,cap_fowner,cap_dac_read_search,cap_net_admin+epi main
all the capabilities are set it is verified by using getcap command
getcap main
main = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_net_admin+eip
If run above code I get following reply :
./main ifdown: failed to open lockfile /run/network/ifstate.eth0:
Permission denied
Can somebody help me on this?
Capabilities don't work the way you think they do. They are attached to an executable file, and are reset when you execute a new file.
Your executable might have the permissions it need to change interface status, but not to run an external program that does so, which is what popen does.
I don't like it either, but that's the way it is.
If you've already written a program for doing what you want, you might as well go ahead and set uid on it. That will work as expected.
Folks,
i wrote a char driver for my i2c device. It is working on Android 4.0.3 using Linux kernel 3.0.8.
When I try to access the driver using ioctl() with my native Android app. I get a permission denied error.
If I create the device file using the following command I don't get the permission error.
mknod /dev/barcodescan c 100 0
I don't want to have to manually issue this command all the time but instead that the module does it on startup. I wrote the following code but I get a permission denied error.
How can I setup permission in this code?
ret= register_chrdev(MAJOR_NUMBER,"barcode",&fops );
if(ret) {
pr_info(KERN_ERR "%s:register chrdev failed\n",__FILE__);
return ret;
}
i2c_dev_class = class_create(THIS_MODULE,"barcode");
if (IS_ERR(i2c_dev_class)) {
ret = PTR_ERR(i2c_dev_class);
class_destroy(i2c_dev_class);
}
I assume that you are building your own Android image.
In that case, you need to edit init.rc to add lines like this to make sure that your device node is automatically created at boot:
mknod /dev/barcodescan c 100 0
chown system system /dev/barcodescan
You may want to change system:system to some other account and/or add more permissions with chmod, for example using chmod 666, but this is not recommended.
Following this question, how do I launch instruments with iPhone simulator as a device.
I tried this:
$ instruments -t /Developer/Platforms/iPhoneOS.platform/Developer/Library/Instruments/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate -w iphonesimulator5.0 MyApp.app
But I get this error:
Instruments Usage Error : Device failed to become ready for use.
-w <deviceID> is used only when you wish to specify a hardware device as the destination (the 'deviceID' here is the Identifier of the device, found in the Organizer of Xcode).
Instead of using -w, you can specify a flag during the build to force instruments to use iPhone. Details can be found here.
I was doing it as follows:
1.I created a template in which I was calling my UI Automation Main file that Triggers running all the scripts.
EX:
//Main.js file will run auto.js scripts
//auto.js is my main file in which I am running all the scripts
//Main.js file
#import "auto.js"
auto.run();
//Now open terminal and run the following command.
1. Go to the directory where you saved your template
2.Copy the location where you simulator (full path) is
Than run the command below:
instruments -t ./NameOfYourTemplate.tracetemplate /Users/swathyvalluri/Debug-iphonesimulator/MyApp.app
Note : Create a new file in the template and copy the contents into it what ever you want to put, otherwise it will look for Main.js file in your locally and will fail when running it on another server.
Please let me know if you need more help :)
Device id means here UDID of the device.
Also see the link below, it is very useful :
http://lemonjar.com/blog/?p=69