udev mapping rule doesn't allow container to start

[FuzzyMistborn]

Not sure if this is an RTL_433 issue or a docker issue, but to get around the issue where the /dev/bus/usb path changes I'm trying to create a udev rule to map the device id to /dev/rtl433 and then pass that through to the container. However, the container doesn't seem to like that as I get this error:

rtl_433 version 20.11-117-g445ddda5 branch master at 202104251151 inputs file rtl_tcp RTL-SDR,
Use -h for usage help and see https://triq.org/ for documentation.,
Trying conf file at "rtl_433.conf"...,
Trying conf file at "/root/.config/rtl_433/rtl_433.conf"...,
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...,
Trying conf file at "/etc/rtl_433/rtl_433.conf"...,
Publishing MQTT data to XXXXXXXXX port 1883,
Publishing device info to MQTT topic "rtl_433[/model][/id]".,
Registered 2 out of 186 device decoding protocols [ 40-41 ],
No supported devices found.,

I suspect it's because RTL_433 is set to look for something on the /dev/bus/usb path. When I try to map /dev/rtl433 to something like.... /dev/bus/usb/001/004 I get this instead:

rtl_433 version 20.11-117-g445ddda5 branch master at 202104251151 inputs file rtl_tcp RTL-SDR,
Use -h for usage help and see https://triq.org/ for documentation.,
Trying conf file at "rtl_433.conf"...,
Trying conf file at "/root/.config/rtl_433/rtl_433.conf"...,
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...,
Trying conf file at "/etc/rtl_433/rtl_433.conf"...,
Publishing MQTT data to 192.168.30.12 port 1883,
Publishing device info to MQTT topic "rtl_433[/model][/id]".,
Registered 2 out of 186 device decoding protocols [ 40-41 ],
usb_open error -4,

If I map it to the match USB path of /dev/bus/usb it works. Which kinda defeats the point of a udev rule. Is there a way around this?

[hertzg]

I would ask about how rtl_433 and the driver that you use (I'm assuming rtl-sdr as you have not specified the command, only output) at https://github.com/merbanan/rtl_433.

But trying to be helpful here, Have you tried using the -d option to specify the input device forrtl_433 and the matching --device option for docker run to expose that device inside the container?
Both of them should give you the flexibility you need and use the manualy mapped path.

In the second example, the usb_open error -4, could be libusb complaining about wrong udev rule maybe or something has claimed it already? 🤷‍♂️ Hard to say from these outputs.

LIBUSB_ERROR_NO_DEVICE | No such device (it may have been disconnected)

Quotes from https://github.com/merbanan/rtl_433#running

[-d <RTL-SDR USB device index> | :<RTL-SDR USB device serial> | <SoapySDR device query> | rtl_tcp | help]

and

		= Input device selection =
	RTL-SDR device driver is available.
  [-d <RTL-SDR USB device index>] (default: 0)
  [-d :<RTL-SDR USB device serial (can be set with rtl_eeprom -s)>]
	To set gain for RTL-SDR use -g <gain> to set an overall gain in dB.
	SoapySDR device driver is available.
  [-d ""] Open default SoapySDR device
  [-d driver=rtlsdr] Open e.g. specific SoapySDR device
	To set gain for SoapySDR use -g ELEM=val,ELEM=val,... e.g. -g LNA=20,TIA=8,PGA=2 (for LimeSDR).
  [-d rtl_tcp[:[//]host[:port]] (default: localhost:1234)
	Specify host/port to connect to with e.g. -d rtl_tcp:127.0.0.1:1234

[FuzzyMistborn]

I appreciate the help. Again I wasn't sure if this was rtl-433 related or the container. Figured since it's going to be a limitation on the container (ie having to change what device is passed through) I'd raise it here but I have no issue going over to rtl-433 if that's the right spot to go.

Correct I'm running rtl-sdr, here's my docker-compose snippet:

  rtl433:
    image: hertzg/rtl_433:latest
    container_name: rtl433
    devices:
      - /dev/bus/usb/001/006
    command:
      - -Fmqtt://192.168.XXXX:1883,user=XXXX,pass=XXXXXX,retain=1,devices=rtl_433[/model][/id]
    restart: always

I did try to play with the -d flag but even trying to use the serial number -d :000001 doesn't work.

[hertzg]

There's also --device-cgroup-rule for docker that could help you, seems to be pretty recent addition. I'm going to close this for now as I don't see this as an issue with this repository but feel free to continue with your findings, I'm curious how you will solve this.

A quick search turned some interesting leads that I would investigate:

• https://docs.docker.com/compose/compose-file/compose-file-v2/#device_cgroup_rules
• Add support --device-cgroup-rule option docker/compose#5622
• https://dev.to/jeetparekh/accessing-devices-from-inside-a-docker-container-without-using-the-privileged-flag-1dd8

[FuzzyMistborn]

Thank you for those links. I tried them and still had no luck. Going to give up for now as I don't restart all that often so hopefully it isn't a bit issue. I'll keep trying though.

[hertzg]

I currently have it setup so that the sdr device is always assigned /dev/bus/usb/001/004 (at boot) on the PI, the rtl_433 serves as a "bridge" between 433Mhz radio waves and MQTT.

[FuzzyMistborn]

How did you do that? udev rule mapping it to that path? All I'm looking for is consistency between reboots, the specific path doesn't matter to me.

[hertzg]

The more I dig into this topic the more I realise I'm lucky 😅. In my case I just have the sdr device connected to the Pi4 port (don't remember which one exactly), I do not restart it at all and it seems to have not been renumerated for the past year or so.

How did you do that?

Nothing, I just not touch the PI at all, I know it's not a solution but so far (about a year) It has kept its id.

The doc mentions that

Stable identifiers are available, for user mode applications that want to use them.

But unfortunately I do not know where and how to access them.

Quote from Linux usbfs docs:

What files are in "devtmpfs"?
Conventionally mounted at /dev/bus/usb/, usbfs features include:

/dev/bus/usb/BBB/DDD ... magic files exposing the each device's configuration descriptors, and supporting a series of ioctls for making device requests, including I/O to devices. (Purely for access by programs.)
Each bus is given a number (BBB) based on when it was enumerated; within each bus, each device is given a similar number (DDD). Those BBB/DDD paths are not "stable" identifiers; expect them to change even if you always leave the devices plugged in to the same hub port. Don't even think of saving these in application configuration files. Stable identifiers are available, for user mode applications that want to use them. HID and networking devices expose these stable IDs, so that for example you can be sure that you told the right UPS to power down its second server. Pleast note that it doesn't (yet) expose those IDs.

Source: https://github.com/torvalds/linux/blob/ef1244124349fea36e4a7e260ecaf156b6b6b22a/Documentation/driver-api/usb/usb.rst#what-files-are-in-devtmpfs

[FuzzyMistborn]

Sorry I haven't had time to keep working on this. Interestingly I rebooted my server by accident this morning and everything came back up fine. So it may not be as big an issue as I thought.

[CharlesGodwin]

@hertzg @FuzzyMistborn
I know you closed this but I too have the problem of my radio device wandering between reboots. I had another implementation of RTL_433 at a different location that didn't have this problem, so I checked.

I have found that this works. It seems rtl_433 works it out

   devices:
      - /dev/bus/usb

[FuzzyMistborn]

Interesting. That definitely would work. My other issue that's more particular to me is that I run things inside linux containers (LXC) so I have to pass through devices to the container. I'd prefer not to pass every USB device through for security reasons. But that's a clever solution.

[CharlesGodwin]

I'm using this on a pi 4 using docker compose. Not quite the same. Charles Godwin

…

________________________________ From: Fuzzy ***@***.***> Sent: Saturday, May 29, 2021 7:29:56 PM To: hertzg/rtl_433_docker ***@***.***> Cc: Charles W Godwin ***@***.***>; Comment ***@***.***> Subject: Re: [hertzg/rtl_433_docker] udev mapping rule doesn't allow container to start (#14) Interesting. That definitely would work. My other issue that's more particular to me is that I run things inside linux containers (LXC) so I have to pass through devices to the container. I'd prefer not to pass every USB device through for security reasons. But that's a clever solution. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#14 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AE6AIH2I3FZBB6OA5OZUISTTQF2HJANCNFSM44UCVXGA>.

[hertzg]

Following up on the quote from kernel about "stable" ids. I was able to only find usb_make_path method from Linux-USB Host Side API, not sure if there is a userspace program that makes use if that api.

[CharlesGodwin]

I have read an article that discusses how to do it for USB serial devices. I use it for a RS485 dongle but it doesn't seem to work for this application. Want to read it, I can dig it up