enableHid.sh not working

[kontez]

Hey, I followed your guide 1:1 and I have problems with the enableHid.sh, since at startup nothing happens I decided to run it manually and I get these errors:

pi@raspberrypi:~ $ sudo ./enableHid.sh
/home/pi/hid.sh: line 20: echo: write error: Device or resource busy
/home/pi/hid.sh: line 21: echo: write error: Device or resource busy
/home/pi/hid.sh: line 22: echo: write error: Device or resource busy
/home/pi/hid.sh: line 23: echo: write error: Device or resource busy 
ln: failed to create symbolic link ‘configs/c.1/hid.usb0’: File exists 
ls: write error: Device or resource busy

I also tried to power the pi and execute it via ssh over wifi since I thought the problem may be in the connected USB, but the errors are the same. Any known issues that may be causing this?

Thanks! :)

---

Edit from @aidantwoods: This appears to be a bug upstream, here are your options: https://github.com/aidantwoods/RPi0w-keyboard/issues/1#issuecomment-315045349

[aidantwoods]

Looks like the /dev/hidg0 device already exists by that error message, was ./enableHid.sh run at boot as-well?

[aidantwoods]

Just to clarify, enableHid.sh should only need to be run once per boot (and it looks like it's already been run), what happens when you try to send keystrokes with hid_gadget_test ?

[kontez]

Hey Aidan, thanks for the quick reply
Yes, enableHid.sh is executed at boot, in my rc.local I have

sudo /home/pi/enableHid.sh
sudo chmod -R 777 /dev/hidg0

as specified in your writeup.

The output of echo 'a' | /home/pi/hid_gadget_test /dev/hidg0 keyboard is: /dev/hidg0: No such file or directory

In /dev/ there is no hidgX device either:

pi@raspberrypi:~ $ ls /dev/ | grep hidg
pi@raspberrypi:~ $

The lines in the hid.sh where the command fails, are:

echo 1 > functions/hid.usb0/protocol
echo 1 > functions/hid.usb0/subclass
echo 8 > functions/hid.usb0/report_length
...

Thanks again!

[aidantwoods]

If you disable enableHid.sh running at boot and run it manually do you get any error messages? The one's you're currently getting all appear to be caused by the script being run twice (but something else must be failing initially if you don't see /dev/hidg0)

[kontez]

Sorry for the delay, I disabled enableHid.sh at boot and ran it manually after startup, the onyl error message I get is:

pi@raspberrypi:~ $ sudo /home/pi/enableHid.sh
ls: write error: Device or resource busy
pi@raspberrypi:~ $ ls /dev/ | grep hidg
pi@raspberrypi:~ $

[aidantwoods]

Hmm, looks like the last line of hid.sh isn't running properly for some reason in that case.

Tried Googling for "ls /sys/class/udc ls: write error: Device or resource busy" and a few results seem to be with RPis, no solution I can see immediately from a search though.

Have you got anything plugged into the OTG port on the Pi when you execute this?

Just to double check, your pi isn't running in some other OTG at the same time, e.g. emulating a network over USB ethernet?

Could you print out the contents of your /boot/config.txt and /etc/modules files?

[kontez]

I have nothing plugged in, only the USB cable from the Pi to the PC on the data usb port.
This is my /boot/config.txt:

pi@raspberrypi:~ $ cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxtreadme
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on

dtoverlay=dwc2

And this is my /etc/modules:

pi@raspberrypi:~ $ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
dwc2

The Pi should be the same model as yours as I bought the kit you linked on your blog! Thanks!

[aidantwoods]

Hmm... as far as I can tell those files are identical to mine

Do these commands match your output?

Also, perhaps try adding g_hid on a new line in /etc/modules (shouldn't really need it because of the modprobe in the hid.sh script).

[aidantwoods]

Could you confirm you're using raspbian jessie too? I'm using the lite (GUI-less version) (though I can't see why the other would have drivers absent).

And also that this matches up (I can't see why any of this would be missing, since it's meant to be bundled with the OS).

[kontez]

I downloaded the latest raspian jessie lite I could find when installing it, it's the 2017-04-10. The commands do not match your output:

pi@raspberrypi:~ $ uname -r
4.9.24+
pi@raspberrypi:~ $ lsmod | egrep -i 'libcomposite|hid'
libcomposite           49619  3 usb_f_ecm,g_ether,usb_f_rndis
udc_core               40356  5 usb_f_ecm,dwc2,u_ether,usb_f_rndis,libcomposite

the last one matches though

[aidantwoods]

Possibly something has been broken in the newer OS, unfortunate if that's the case. I'll try and investigate that.

In the meantime (if the problem is stemming from the newer kernel) you might be able to fix it by downgrading your kernel version to the 4.4.x branch (though I'd advise taking an image of the SD card prior, incase the Pi isn't bootable after doing that – that way you can revert the change by just re-imaging the SD card with your backup, instead of having to setup from scratch).

You should be able to install 4.4.50+ by running

sudo rpi-update 52241088c1da59a359110d39c1875cda56496764

[kontez]

I'll try it asap Thanks again!

[kontez]

the pi died after that haha are there any other ways I could roll back to an older kernel?

[aidantwoods]

Ha, yeah... not entirely surprised by that 😉

I guess you could always use an older OS – just out of question, where did you get this OS from?

Download page I'm looking at gives the current version release dated such that it's likely the version I picked up, and kernel version at 4.4

https://www.raspberrypi.org/downloads/raspbian/

[kontez]

I probably updated it during the setup, I can try with a fresh setup! Unfortunately I don't have a lot of time, so the replies are delayed sometimes, sorry for that. Thanks for your help!

[Ax3l-91]

Hello all, any news @aidantwoods? I have the same issues :( Thanks a lot for your help

[aidantwoods]

Hi there @Ax3l-91

Are you also using the 4.9 kernel, or is the problem replicated on 4.4? (check with uname -r).

[Ax3l-91]

Hello, Yes on 4.4.50+, I've tried everything, on 4.9 as weel, I've ls: write error: Device or resource busy. I don't know know to do... I also view many topics on rc-local issues because it doesn't execute scripts, when I check his status I've that : sudo systemctl status rc-local.service

`rc-local.service - /etc/rc.local Compatibility Loaded: loaded (/lib/systemd/system/rc-local.service; static) Drop-In: /etc/systemd/system/rc-local.service.d └─ttyoutput.conf Active: failed (Result: exit-code) since sam. 2017-06-10 16:46:11 CEST; 18s ago Process: 712 ExecStart=/etc/rc.local start (code=exited, status=2)

juin 10 16:46:11 raspberrypi sudo[714]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAN....sh juin 10 16:46:11 raspberrypi sudo[714]: pam_unix(sudo:session): session opened for user...=0) juin 10 16:46:11 raspberrypi sudo[719]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAN....sh juin 10 16:46:11 raspberrypi sudo[719]: pam_unix(sudo:session): session opened for user...=0) juin 10 16:46:11 raspberrypi sudo[719]: pam_unix(sudo:session): session closed for user root juin 10 16:46:11 raspberrypi sudo[714]: pam_unix(sudo:session): session closed for user root juin 10 16:46:11 raspberrypi systemd[1]: rc-local.service: control process exited, code...s=2 juin 10 16:46:11 raspberrypi systemd[1]: Failed to start /etc/rc.local Compatibility. juin 10 16:46:11 raspberrypi systemd[1]: Unit rc-local.service entered failed state.

Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended. Hint: Some lines were ellipsized, use -l to show in full`

I don't know if it's related or not... I added sh on sudo /home/pi/hid.sh to recognize the command...

[aidantwoods]

Cheers for going through the steps on both kernel versions, looks like the version I used to set everything up was released on 2017-03-02 (so not the current latest). I'll try and set aside some time to see if I can reproduce this starting from a clean install of the latest raspbian.

Will report back on what I find. :)

[aidantwoods]

I was able to reproduce the script not working on the later kernel version. Looks very much like a bug to me.

I've put together an install script that should work right off the bat on a clean install of jessie (the specific version I'm working with is dated 2017-04-10), which has a working internet connection.

Make sure that if you used the OTG port as an initial communication channel to the Pi (as described here https://gist.github.com/gbaman/975e2db164b3ca2b51ae11e45e8fd40a) that you go into /boot/cmdline.txt and remove modules-load=dwc2,g_ether (after setting up another communication channel of course, i.e. broadcast or connect to a WiFi network).

After you've got all that sorted, the following should setup everything this will automatically download and install the kernel version 4.4.50+ if you are not already running it.

BACKUP IF NECESSARY BEFORE RUNNING THIS

Also, make sure rpi-update is installed (sudo apt-get install rpi-update) if you are not running the correct kernel version before running these.

gpg --recv-keys 9A6A8EFAA512BBB9
wget https://gist.githubusercontent.com/aidantwoods/87b720761fd88973b7740b4b425fd66a/raw/4e23f1d59ebe59796064d7be756c74ed36050c05/install-hid.sh.asc
gpg -o install-hid.sh -d install-hid.sh.asc && chmod +x install-hid.sh && ./install-hid.sh

After that

sudo reboot

And after reboot, check you are able to run sudo ./hid.sh and maybe do an ls /dev/hidg0 for good measure that the hid device was created. You should then be able to pick back up on the guide to set that to start at boot etc...

If you'd like to see my entire build process starting right after writing jessie to the pi, see this gist (where /Volumes/boot on my local machine is the mounted SD card's boot partition).

Here's the final screenshot where I ask the Pi to send the keystroke "a", and an "a" appears back in my terminal (Pi is plugged in to my machine).

[aidantwoods]

@Ax3l-91 you mentioned you were having issues on 4.4.50+, could you confirm that the OTG port is not in use at time of running the script to setup the Pi as a HID?

If so, could you prevent it running on boot and run the ./hid.sh script manually, and let me know any output you get?

[aidantwoods]

@kontez

the pi died after that haha

I tried upgrading to the latest kernel available, and then using rpi-update to drop back down to 4.4.50+ (using the same command I posted earlier). I managed to have to Pi boot fine after that, so not entirely sure what happened. Did you encounter any errors during the kernel installation process?

If you start from a fresh install of jessie then the kernel will be at the correct version anyway (I observed it updating if you do an apt-get update && apt-get upgrade though).

[Ax3l-91]

Hello @aidantwoods, Thank you! All run right now, my OTG port should run at the same time...

[Ax3l-91]

Hi again @aidantwoods,

I wanted to try your quack.php script but I have this error relative to this line: function translate(string $l) : array PHP Parse error: syntax error, unexpected ':', expecting '{' in /home/pi/quack.php on line 47

Thanks in advance for your help!

[aidantwoods]

~~Hi @Ax3l-91,~~

~~Looks like you're running an old version of PHP?~~

~~The colon denotes a return type declaration, which need ≥ PHP 7 (http://php.net/manual/en/migration70.new-features.php#migration70.new-features.return-type-declarations)~~

~~You can either remove the return type declarations (remove the colon and the type from the lines they are on), or update PHP to a recent version :)~~

---

~~If you wanted to update PHP, I think I just compiled from source on the Pi (think I recall 7 not being available on apt-get when I checked). But this script designed to configure it on Kali (another debian distribution) should work fine on the Pi (haven't tested it though so possible it doesn't grab all the needed dependencies).~~

~~https://gist.github.com/aidantwoods/bb26af07588c7fa6c68be237a1caf22c~~

~~You'd just need to cd php* and then run make, (make test if you like), and sudo make install after that.~~

~~(though for the quack.php script it'll run on a bare bones install of PHP without all the usual config options – so you could easily compile from source too).~~

---

I've copied that answer over to #2 so it's a little more searchable incase anyone else runs into the same issue, let me know over there if that answer helps/you need more info :)

[julianwieg]

Hi, same issue with "2017-06-21-raspbian-jessie-lite.zip" and yes I was clever enough to go into cmdline.txt and remove the modules-load=dwc2,g_ether string I used for headless setup after troubleshooting why the script fails at line #20 root@duckypi:/sys/kernel/config/usb_gadget/g1# echo 1 > functions/hid.usb0/protocol bash: echo: write error: Device or resource busy

So what is the solution or workaround now? Is to go to kernel 4.4.50+ and use the install script you mentioned above?

Bit confusing with all the replies going on :) Thanks

[aidantwoods]

Hi @julianwieg,

Workaround/fix is using the earlier kernel. If you've set everything else up already then you only need install 4.4.50+. If you happen to start again from scratch then the install script I mentioned will just run through all the setup steps that you've likely already done, as well as installing the known good kernel.

[julianwieg]

Worked but does anyone else have Windows initially say: USB device not recognised/not working error and then 4 5 seconds later the "not working" device in Device Manager disappears and a new HID device appears? That for all intense and purposes is not very stealthy :)

What I did to get it working:

1. So I did a fresh install of Jessie with kernel 4.4.50+ from https://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2017-03-03/
2. Setup Wifi Hotspot aka AP per another website linked on your blog/website
3. Followed your guide on your blog/website
4. https://github.com/anbud/DroidDucky
5. https://github.com/theresalu/rspiducky -> copy usleep.c into pi home dir. make usleep.c move usleep into the bin directory so its available to the scripts. also rename/copy the hid_gadget test app to - to _ as the droidducky uses another naming convention so the droidducky script cannot call/use the hid_gadget app otherwise due to the wrong name.

[aidantwoods]

Great to hear that worked!

does anyone else have Windows initially say: USB device not recognised/not working error and then 4 5 seconds later the "not working" device in Device Manager disappears and a new HID device appears? That for all intense and purposes is not very stealthy :)

Shall we move this to a separate issue? As you mentioned, this one is already quite hard to follow 😉

[aidantwoods]

I'll leave this open, since I suspect it's a bug others will run into. For anyone arriving, the available options for a workaround/fix are:

1. Use working kernel version, before this (probably a bug) was introduced: https://github.com/aidantwoods/RPi0w-keyboard/issues/1#issuecomment-309244795
2. Report this as an issue upstream

I haven't reported upstream, but anyone who wishes to is welcome to do so :)