I tried to enter monitor mode with my wlan-usb stick on my raspberry pi following this two instructions:
https://github.com/hexameron/rtlwifi
https://stackoverflow.com/questions/16365487/kali-linux-on-raspberry-pi-wlan0-monitor-mode
I'm using the following wlan-stick:
Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
however, if I try to load the new driver with
modprobe rtl8192cu
i get the following error:
ERROR: could not insert 'rtl8192cu': Exec format error
any idea whats going wrong?
ERROR: could not insert 'rtl8192cu': Exec format error means that this module is not for your current kernel, you can recompile kernel with rtl8192cu module enabled and then install it. Don`t know if driver if this chipset in rpi kernel supports monitor mode.
This is kernel source - https://github.com/raspberrypi/linux
And instruction on building - http://elinux.org/RPi_Kernel_Compilation
Related
I have installed FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz on Raspberry pi 4b. And onto that installed cassandera3, for which the dependencies are java8, python. I am getting this error in the system logs.
with cqlsh >>>> i am getting the error on not connecting to "Local host ip ".
Kindly give your suggesstions to resolve this.
I have try a c++ program using curlpp libraries in my VM, my intention is when i execute the program, i can get a file via tftp.
I tested this program on the VM , this program managed to get a file from another VM.
However when i run this program in beaglebone yocto , it prompt following error:
Protocol "tftp" not supported or disabled in libcurl
FYI,the beaglebone can the ping and greb file from VM using busybox tftp.
I get the curlpp recipes from https://github.com/openembedded/meta-openembedded/blob/master/meta-networking/recipes-support/curlpp/curlpp_0.8.1.bb. Am i missing anything on this?
Add PACKAGECONFIG_append_pn-curl = " tftp" in local.conf
I'm using buildroot to compile a minimalistic linux with a 4.19-rt kernel. It is supposed to run on a raspberry pi 3b (arm processor). Additionally I want to run it on a x86_64 linux computer and found qemu as an emulation solution for that.
Building linux and kernel and running it on the raspi works. It boots, I can login and use it.
To test qemu I followed this instruction [1]. A recent raspbian with 4.19 kernel is booting fine so qemu seems to be installed correctly.
sudo qemu-system-arm -kernel ./qemu-rpi-kernel/kernel-qemu-4.19.50-buster -hda 2019-09-26-raspbian-buster-lite.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -dtb qemu-rpi-kernel/versatile-pb.dtb
Bringing 1. and 2. together fails. When I try to emulate any self build linux, qemu only shows a black screen and one CPU is using 100%.
I used the same sdcard.img that works on the real hardware. I also tried to recompile the whole system with a normal 4.19 kernel (without real time). And I tried to build a versatile system (make qemu_arm_versatile_defconfig && make). None of it works.
Command to start the emulation:
sudo qemu-system-arm -kernel zImage -drive format=raw,file=sdcard.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -append "root=/dev/mmcblk0p2 panic=1 rootfstype=ext4 rw" -serial stdio
My main problem is, that there is absolutly no useful output. The command outputs the following
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
audio: Failed to create voice `lm4549.out'
and opens a window for the graphics output (that does not show anything). The message also appears when emulating raspbian so it does not seem to be the reason.
When I run qemu with the prebuild raspbian but without the -dtb argument, I get a message like "Error: invalid dtb and unrecognized/unsupported machine ID". I would at least expect something like this with my self build code. But because there is no output I'm out of ideas what even to google for.
Does someone maybe have an idea what I'm doing wrong or how I get qemu to provide me any useful information on what went wrong?
[1] https://blog.agchapman.com/using-qemu-to-emulate-a-raspberry-pi/
The problem is that a kernel will only boot on a piece of Arm hardware if it is compiled for that hardware. Otherwise it will generally fail, usually by crashing before it is able to output anything useful.
In particular, the QEMU 'versatilepb' machine is completely different to the Raspberry Pi. Any working set of instructions that use that machine type are really running a kernel built to work with the versatilepb board and a raspi userspace/filesystem on top of that. You're trying to build a kernel that has support for only the raspi on a machine that isn't a raspi, which won't work.
It is possible to build a kernel that works on more than one piece of Arm hardware, if you compile in the support for both board types (all the device drivers for both, etc). If you want to go down that path, I would suggest looking at the differences between the kernel config for the kernel that works and your one, and add plausible looking missing things until you find out what is actually required.
Your attempt to boot on QEMU directly from sdcard.img will not work, because QEMU's versatilepb board model does not support direct boot from sdcard (this would require us to run some kind of BIOS/firmware image in the guest, which we don't have). For versatilepb you need to supply directly to QEMU the kernel, possibly an initrd, and definitely the correct dtb for the versatilepb.
You might instead try looking at QEMU's "raspi2" and "raspi3" board models, which really do model the hardware of Raspberry Pis. The disadvantages however are that these models are missing some features and are not very actively developed, so often newer kernels don't boot on them, and also since there is no USB controller model there is no way to get networking. (This is why most blog posts etc suggest using the 'versatilepb' -- userspace doesn't often really care about exactly what hardware it's running on, so unless you're trying to do kernel development you can just run a versatilepb kernel and take advantage of the features like networking that that QEMU model has.)
Advanced Linux Sound Architecture (ALSA) tries to open audio interface device . you must provide audio device in qemu . Because the kernel is compiled with ALSA audio driver and you have compiled sdl library in Buildroot.
We are running the latest raspibian on the raspberry pi board and have a kernel driver for a USB peripheral which is added externally (sudo insmod driverx.ko) after boot-up by connecting to the hardware using ssh (its a headless system).
The problem is as follows:
If the device is already connected to the system upon power-up then running sudo insmod driverx.ko leads to the terminal getting stuck (no response, Ctrl+C doesn't work). Running lsmod by starting another ssh session shows that the module is in use even though there is no code running that will use it.
If I plug the USB device after the system boots up then sudo insmod driverx.ko works normally, (the terminal is still active). Running lsmod subsequently shows that that module is loaded but not in use by anyone. I can then run my user code and everything is fine. Upon running my user code lsmod shows the kernel module is in use and the number of users is 1.
In our system the USB device will always be plugged in. The kernel version and the driver version are the same.
I can fill in more details but do not wish to bias or make this query un-readble.
Please advise on what could the problem be.
Thank you for your time and help.
Possibility is that, the device is already attached into some other driver during startup. If it’s the case, the device credential of your specific device has to be removed from the startup driver.
Check the USB device list before to insert your driver.
I am trying to configure LIRC to work with my Raspberry 2B and a circuit I build with a transistor and a IR transmitter as explained in this tutorial
After the installation of LIRC, I followed all the steps and I added these two lines in /etc/modules
lirc_dev
lirc_rpi gpio_out_pin=36
Then I typed this in /etc/lirc/hardware.conf
LIRCD_ARGS="--uinput"
LOAD_MODULES=true
DRIVER="default"
DEVICE="/dev/lirc0"
MODULES="lirc_rpi"
LIRCD_CONF=""
LIRCMD_CONF=""
After rebooting, I added the configuration of my Samsung remote (BN59-00516A) to /etc/lirc/lircd.conf
Then I restarted LIRC again but when I run a command to send a IR frequency
irsend SEND_ONCE Samsung_BN59-00865A KEY_POWER
it complains with the following error:
irsend: could not connect to socket
irsend: No such file or directory
I am guessing this is a problem with my device socket, because in the hardware.conf file I set
DEVICE = "/dev/lirc0"
(just because the tutorial states it), but lirc0 file isn't within the folder.
I couldn't find any other question related to this problem and google didn't help me much either. Does anyone have any hint on this?
After googling a lot, I found out an update is needed to have everything working properly. In my case I did:
apt-get update, apt-get upgrade, rpi-update
Also, as pointed out in this other tutorial, depending on the Raspberry firmware, you might need to add this to /boot/config.txt
dtoverlay=lirc-rpi,gpio_in_pin=XX,gpio_out_pin=YY
Substitute X and Y for whatever pins you're using!
I had a similar problem and I solved it with this command:
sudo lircd --device /dev/lirc0
If you set the value of LIRCD_ARGS in /etc/lirc/hardware.conf to "--device /dev/lirc0", it should start lircd appropriately, when /etc/init.d/lirc is started at boot.
you need to run lircd. It will create two files (lircd and lircd.pid) at /var/run/lirc/:
lircd
I got the same error messages. But had all configurations done. The restart of the lirc daemon solved this issue by typing
$ sudo /etc/init.d/lirc restart
I think is useful to say that the gpio_in_pin=XX,gpio_out_pin=YY part of the /etc/modules can be double checked with
dmesg | grep lirc
which results in something like
[ 3.437499] lirc_dev: IR Remote Control driver registered, major 244
[ 5.472916] lirc_rpi: module is from the staging directory, the quality is unknown, you have been warned.
[ 6.621156] lirc_rpi: auto-detected active high receiver on GPIO pin 22
[ 6.622515] lirc_rpi lirc_rpi: lirc_dev: driver lirc_rpi registered at minor = 0
[ 6.622528] lirc_rpi: driver registered!
for /etc/modules containing
lirc_dev
lirc_rpi gpio_in_pin=23 gpio_out_pin=22