#StackBounty: #raspbian #kernel #led #driver Editing heartbeat LED trigger

Bounty: 50

I am trying to edit the timer of heartbeat trigger on RPi Zero. I have found original .c file of kernel driver here https://github.com/raspberrypi/linux/blob/rpi-5.4.y/drivers/leds/trigger/ledtrig-heartbeat.c. But when I look into my Pi’s kernel drivers, in directory with triggers /lib/modules/5.4.51+/kernel/drivers/leds/trigger there are only three triggers and none of them are heartbeat : ledtrig-camera.ko ledtrig-netdev.ko ledtrig-transient.ko. So I am assuming the heartbeat trigger is defined elsewhere.

Where can I find and edit the heartbeat trigger of led ?


Get this bounty!!!

#StackBounty: #raspbian #audio #audio-playback No sounds playing from USB external speaker on Raspberry Pi

Bounty: 50

I’m trying to get some sound to play via an external USB connected speaker from my Rasp Pi 3 Model B.

aplay -L 

gives me this entry (along with many others)

default:CARD=Device
USB2.0 Device, USB Audio
Default Audio Device

So, I tried running:

aplay -D default:CARD=Device piano2.wav

But end up with the following

Playing WAVE 'piano2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
aplay: pcm_write:2053: write error: Input/output error

I’m not even sure where to being to troubleshoot this. Thoughts on why this error is thrown?

More info. aplay -l gives me

   **** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Device [USB2.0 Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


Get this bounty!!!

#StackBounty: #raspberry-pi #symlink #raspbian #cifs Access windows symbolic link from linux cifs

Bounty: 50

I have created symbolic link of the mapped drive (DOS share) on Windows 7 computer 200.90.12.25. Trying to access this from Linux (Raspberry PI) using CIFS command, I get mount error(5): Input/output error. CIFS command and dmesg attached below.

I cannot access the DOS share from Linux because of NETBEUI. Line diagram shown below for reference.

enter image description here

CIFS command

sudo mount -t cifs -o user=username,guest,vers=2.0 //200.90.12.25/DOSA /home/pi/myNAS/myShare

dmesg (also on the Linux client)

[1027098.510573] FS-Cache: Duplicate cookie detected
[1027098.510583] FS-Cache: O-cookie c=c6d9fc6c [p=33027f2d fl=222 nc=2 na=1]
[1027098.510588] FS-Cache: O-cookie d=e8ce4e52 n=203d934d
[1027098.510592] FS-Cache: O-key=[8] '020001bd0a090c12'
[1027098.510606] FS-Cache: N-cookie c=435e27ec [p=33027f2d fl=2 nc=0 na=1]
[1027098.510611] FS-Cache: N-cookie d=e8ce4e52 n=9f19c9a0
[1027098.510614] FS-Cache: N-key=[8] '020001bd0a090c12'
[1027098.515854] CIFS VFS: cifs_mount failed w/return code = -5

any alternative solution much appreciated.


Get this bounty!!!

#StackBounty: #audio #raspberry-pi #sound-card #raspbian #alsa Clone sound from Chromium to ALSA Loopback and also speakers

Bounty: 50

I have working setup on my RPi3 B+ with Raspbian where is sound from Chromium browser send directly to ALSA Loopback device (enabled by snd-aloop kernel module) by this Chromium’s parameter:

--alsa-output-device='plug:front'

This sound is successfully recorded from Loopback capture device hw:0,1.

But I also need this sound be played by external speakers which are connected to line-out (jack).
How Can be this done? Can you help me? How I can clone sound output?

# uname -a
Linux rpi3 4.19.114-v7+ #1303 SMP Tue Apr 7 15:44:16 BST 2020 armv7l GNU/Linux

# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
  Subdevices: 7/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 7/7
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
card 1: ALSA [bcm2835 ALSA], device 1: bcm2835 IEC958/HDMI [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

# cat /proc/asound/cards
 0 [Loopback       ]: Loopback - Loopback
                      Loopback 1
 1 [ALSA           ]: bcm2835_alsa - bcm2835 ALSA
                      bcm2835 ALSA


Get this bounty!!!

#StackBounty: #debian #raspbian #hostapd #wpa How to switch off "Not RRM Network" messages

Bounty: 50

My system’s logs are being swamped by these messages:

wpa_supplicant[390]: RRM: Ignoring radio measurement request: Not RRM network

I have searched extensively; I’ve even found the sources for wpa_supplicant here: git clone git://w1.fi/hostap.git
But I’m not fluent in C and have no clue how to proceed.
Can anybody suggest how I can suppress or avoid these messages or switch off this functionality?

EDIT: This is on Raspbian (Debian flavor for Raspberry Pi) Buster, which has wpa_supplicant v2.8-devel. It is communicating with a Fritz!Box AP; I mention this because I’m getting the feeling that could be relevant.


Get this bounty!!!

#StackBounty: #raspbian #image OS image made using Pi-Gen lacks JPEG support in GTK

Bounty: 50

I recently started using Pi-Gen to generate customized prebuilt Raspberry OS images for use with a RaspberryPI 4. I use the build-docker.sh script on a Linux Mint VM.

However, in a test run with minimal changes (the config file only sets the IMG_NAME variable), which should have created a "vanilla" image almost identical to the official one available for download from raspberrypi.org, I ended up with a desktop where no pictures were displayed (i.e. the background is grey, and all taskbar icons are replaced by the "broken document" symbol).

The files themselves (JPEG images, e.g. in /usr/share/rpd-wallpaper/) are present, but when I try to open one with gpicview I get an error message stating

Couldn’t recognize the image file format for file "/usr/share/rpd-wallpaper/temple.jpg"

although displaying the file in the web-browser works fine

I do not have that problem when using the OS image downloaded from the official location instead.

Some googling showed that this happened even with the official image some time ago, and that the libgdk-pixbuf2, specifically the JPEG support, may be the problem.

But in my case the libgdk-pixbuf2 is already the latest version (so reinstalling, as suggested in one post, wouldn’t help), and actually the very same as present on the official OS image:

  • $ apt-cache show libgdk-pixbuf2.0-0 gives the same output on both images:
    Package: libgdk-pixbuf2.0-0
    Source: gdk-pixbuf
    Version: 2.38.1+dfsg-1
    Architecture: armhf
    Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
    Installed-Size: 471
    Depends: libc6 (>= 2.11), libglib2.0-0 (>= 2.48.0), libjpeg62-turbo (>= 1.3.1), libpng16-16 (>= 1.6.2-1), libtiff5 (>= 4.0.3), libx11-6, shared-mime-info, libgdk-pixbuf2.0-common (= 2.38.1+dfsg-1)
    Recommends: libgdk-pixbuf2.0-bin
    Multi-Arch: same
    
  • $ apt-cache policy libgdk-pixbuf2 shows that the installation status is the same on both images.

So, does anyone know why the Pi-Gen might end up with a setting where GDK (apparently) lacks JPEG support, and what to do about it?


Get this bounty!!!

#StackBounty: #networking #ping #packetloss #raspbian Debugging network issue

Bounty: 50

I’ve had this issue ever since I got this new router and flashed it with dd-wrt.
It’s not really impactful (I’ll describe the scenario) but I’m curious about it…

This is the diagram of the network setup:

  • Manjaro Linux running on VMware Fusion (in a Mac/OSX host) connected through WiFi
  • 3 raspberry Pis (running Raspbian) connected to switch 1 (and then router)
  • 1 NAS (WDCloud) connected to switch 1
  • 1 raspberry Pi connected to switch 2 (which is connected to switch 1)

Given the setup, the issue:

  • Mac over WiFi, Manjaro VM in bridged mode
    • Pinging any of the 4 Pis shows packet loss in under 5min – sometimes 20%, sometimes more
    • Pinging the NAS shows no packet loss at all
  • Mac over WiFi, Manjaro VM in NAT
    • no packet loss on any scenario
  • Mac over LAN, Manjaro VM in NAT or Bridged mode
    • no packet loss on any scenario

So, my initial guess was that it was something related to Fusion bridged mode because pinging directly from Mac (host) never had any loss (nor using the VM with NAT).

  • Tried Virtualbox, same happens (bridged shows packet loss, NAT does not).
  • Played a lot with DDWRT WiFi settings but nothing seemed to make any difference.

Realized that pinging NAS had no packet loss so it looked like something only in the Bridged+WiFi+Raspberry combination, so I ran tcpdump icmp on one of the raspberries and started pinging from the VM

Ping output in the VM:

64 bytes from  (192.168.1.22): icmp_seq=13 ttl=64 time=2.40 ms
64 bytes from  (192.168.1.22): icmp_seq=14 ttl=64 time=2.50 ms
===> lost sequences 15 to 42 <===
64 bytes from  (192.168.1.22): icmp_seq=43 ttl=64 time=34.1 ms
64 bytes from  (192.168.1.22): icmp_seq=44 ttl=64 time=2.31 ms

tcpdump output in the Pi:

01:24:42.397835 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 13, length 64                                    
01:24:42.397919 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 13, length 64                                      
01:24:43.399899 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 14, length 64                                    
01:24:43.399948 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 14, length 64                                      
01:24:44.404887 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 15, length 64                                    
01:24:45.422542 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 16, length 64                                    
===> requests hit but no replay is sent... <===
01:25:12.044102 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 42, length 64                                    
01:25:13.068516 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 43, length 64                                    
01:25:13.099164 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 43, length 64                                      
01:25:14.071065 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 44, length 64                                    
01:25:14.071129 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 44, length 64                                      

Conclusion (I think): ping requests hit the raspberry Pi but no replies are sent (for that period, about 30s).
I’m using ping as it is the easiest to show/test packet loss, but this also happens with TCP as SSH sessions hang now and then.

Any hints on what to check on the raspberry pi configuration to understand why it’s not sending the ICMP replies? It makes it look related to the Pi, but why would this not happen in the other scenarios (Mac WiFi + VM bridged), as the Pi remains constant?


Get this bounty!!!

#StackBounty: #raspbian #sensor #hat #sense-hat How to detect list of available sensors and actuators reside on a HAT?

Bounty: 50

I have been working with many HATs along with Raspberry Pi such as Sense HAT, Pimoroni Enviro pHAT; and so on. However, HATs report its existence to the device tree in /proc/device-tree/hat and /sys/firmware/devicetree/base/hat (see details from here). I could extract few information (such as product, vendor; and so on) that were answered in that Q/A. I could enlist the list of sensors (i.e temperature, pressure, humidity; and so on) available on a HAT from vendor/manufacturer end (through website/guidelines) manually. The complexity increases as the number of HATs increases. Anyway, is it possible to read these information (list of available sensors on a HAT) either from PROM / EPROM / EEPROM?


Get this bounty!!!

#StackBounty: #raspbian #ssh Raspicast is unable to connect using an SSH key file

Bounty: 50

I have installed Raspicast on my Android smartphone and tried to connect to the Raspberry using a key file. I have tried both the Linux SSH key format (id_rsa file) and Putty key format (*.ppk file), which are known to work. There is no passphrase for those files, they are both unencrypted.

Raspicast won’t connect with either key file, failing with the same message:

Unable to connect!

Anyone knows what Raspicast expects? Is there a different app for screencasting on a Raspberry that actually works?


Get this bounty!!!

#StackBounty: #debian #wildcards #raspbian #dash dash not expanding glob wildcards in chroot

Bounty: 50

I’m working with a copy of Raspbian, installed with pi-gen. Pi-gen runs in a Docker container with a volume for the filesystem, running debootstrap and custom scripts inside a chroot to the volume.

I’m running a shell inside the Raspbian filesystem using chroot and qemu-arm-static, but without Docker.

I noticed that the mkinitramfs script was not working. I traced the problem back to dash, which the script is running in.

For some reason dash is not expanding filename wildcards in commands:

# echo /*
/*
# ls /
bin boot dev etc home lib media mnt opt proc root run sbin sys tmp usr var

This happens in all folders inside the chroot and also in scripts.
This breaks a lot of stuff.

However, wildcard expansion works normally in filesystems bind-mounted inside the chroot, such as /proc and /run. Also, path expansion using the same dash binary works inside a different chroot.

I’ve already tried set +f and set +o noglob with no luck. The noglob option is definitely not on:

# set -o
Current option settings
errexit         off
noglob          off
ignoreeof       off
interactive     on
monitor         on
noexec          off
stdin           on
xtrace          off
verbose         off
vi              off
emacs           off
noclobber       off
allexport       off
notify          off
nounset         off
nolog           off
debug           off

I’m running version 0.5.8-2.4 of the dash package from http://raspbian.raspberrypi.org/raspbian stretch/main armhf. The host machine is running Kali Linux 2019.1 with kernel 4.19.0-kali4-amd64.

Has anyone seen a similar problem before? What could I use as a workaround?

Update: The following is the relevant part of the strace dump in a working chroot:

read(0, "echo /*n", 8192)              = 8
openat(AT_FDCWD, "/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents(3, /* 11 entries */, 32768)    = 264
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
write(1, "/bin /dev /etc /lib /pls /proc /"..., 46) = 46

The same in the non-working chroot:

read(0, "echo /*n", 8192)              = 8
openat(AT_FDCWD, "/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents64(3, /* 20 entries */, 32768)  = 488
close(3)                                = 0
write(1, "/*n", 3)                     = 3


Get this bounty!!!