• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Static mapping of USB-devices
#1
Hi,

we would like to map our usb devices to non-changing names in order to ensure that we always refer to the correct devices, even if one of the attached devices is unplugged or fails (imagine a device with 5-10 connected usb devices, accessing them through node-red).

On a stand-alone system without any constraints, we would use UDEV.

Do you have any suggestion how can we achieve this on the netPI?

Regards,

Dennis
  Reply
#2
Well Dennis,

have you collected any experience yet with static names on a standard Raspberry PI already? I am asking cause if there is no solution on a standard Raspberry Pi then netPI will not do better.

Additionally with netPI there is Docker and mapping USB devices into a container is a static mapping of the "/dev/" USB device into the container when it starts. So in case a USB got lost and reconnected again it may be that it is no more available in a container. This is not a problem of Docker itself, but lies in the type of implemention we support the socalled "priviledge" mode of Docker on netPI. We have restricted it cause of security reasons and it does not map automatically ALL "/dev's" into the container as it would normally do it.

So from the basic point of view I would say netPI with default Hilscher software on will not support your task. You need a blank netPI without SD card where you can run a Raspbian OS yourself with and implement the software you need without restrictions we have with netPI standard software ... and then we are back to the question "have you tried it on a standard Raspberry Pi" already since netPI without Hilscher software is 100% a RPi3B but in an industrial version.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
Hey Armin,

this is what we do on a stock rasbian:

1) figure out the serial number of the attached device:


Code:
$ udevadm info --name=/dev/ttyUSB1 --attribute-walk

2) create a rule for static mapping in /etc/udev/rules.d/10-usb-serial.rules
Code:
SUBSYSTEM=="tty", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", ATTRS{serial}=="xxxxxxxxxx",  SYMLINK+="ttyUSB_MyDevice1"

3) load the new rule (only required before reboot)

Code:
sudo udevadm trigger


4) verify
Code:
$ ls -l /dev/ttyUSB_MyDevice1

now, you can adress the device as ttyUSB_MyDevice1 instead of ttyUSB0 or whatever it might be mapped to.
  Reply
#4
Understood and will work well.

The problem with standard netPI is that you need to define rules such as

Code:
/etc/udev/rules.d/10-usb-serial.rules

you need access to netPI's host Linux which is not possible from a container's point view using the standard netPI and its restricted Docker.

This is only possible with a netPI coming without our preloaded software and not SD card.

You need to get in touch with Hilscher sales team. I could hand over your email address to them and they will get in touch with you in order to get an "open" netPI.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#5
Hey Armin,

we now think about two solutions to the problem.

1) Try to get a docker-container with UDEV running in this context of restricted-privileged mode. I assume that sysfs is not accessible in this scenario?

2) You could update the firmware with a modified udev rule system for usb-devices to be mapped in a subfolder of /dev/ like /dev/usb which would allow docker to safely mount the device folder for usb devices, without compromising the whole fs. It may also be possible that way to add dynamic udev/udev-like functionality to the docker container with that.
  Reply
#6
Hello,

1.) the /sys/ file system is mapped into a container if you configure a container in mode "privileged" during its start. We need it for example to access standard GPIOs in a container under folder /sys/class/gpio

2.) I like the idea. So one could easily map /dev/usb into the container instead of concrete /dev/ttyxxx/ devices. My question is then do all USB serial device appear as "ttyxxx" devices and are we able to construct a rules file that covers all those USB devices without specifying specific vendor and product codes. I have to get in touch with the development team.

By the way have you already ordered a netPI device?
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#7
I started testing. I created the simplest udev you can think of

Code:
SUBSYSTEM=="tty", SYMLINK+="/usb/%k"

While I was inserting now my serial USB to RS232 converter into my netPI with this ruleset active I saw next to the standard /dev/ttyUSB0 device now also a device under /dev/usb/ttyUSB0. So it is pretty much what we want to see.

But then it came to disillution. I loaded a Raspbian Container with mapped device /dev/usb/ can guess what ... docker does not start and reports "/dev/usb: not a device node".

I searched on the internet for the reason and found the hint https://docs.docker.com/engine/reference...dline/run/ that using the --device option cannot be used for ephemeral devices. Others have that problem too. The reason is that SYMLINK creates just a symbolik link and seems not to have the same properties as the real device.


Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#8
We already have a lovely netpi device. I'm currently not able to test it, but I researched a bit on the topic and their are still some options to try:

Instead of mounting a --device,

1) according to this post [1] it might work to set the --privileged flag and mount /dev/bus/usb and then work manually on it with a script like in [2]
2) mounting the /dev/usb/ as volume as well as /run/udev [3] such that udevadm is able to retrieve information from the hosts udev system
3) combination of 1) and 2)
4) maybe it is possible to use udev inside the container by providing fine-grained access to required host system directories...

We'd also need this functionality for serial devices.

It would be an improvement, if the USB devices would be present in the container dynamically without compromising the host system and featuring udev metadata for manual processing, although udev.rules like creation of device symlinks (maybe with modified script from 1)) would be better.

EDIT:

OK, I did test with the hilschernetpi/rpi-raspbian image and saw that both /dev/bus/usb and /run/udev is not allowed to be mounted as volumes. So if we stick to the idea of bringing usb and serial devices into something like /dev/usb and /dev/serial which can then be mounted as a volume(?) we could then maybe make the symlink to hold the ID information according to an answer in [3] with a udev.rule like this: "SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"" So maybe it is possible to populate the information for the symlink.

As I understand it, the udev info is not present within the container for SYMLINK+= dev paths because /run/udev is not present in the container. Since we cannot get access to this, might it be possible to use udev on the host system and work around the problem by invoking a script via udev.rule for every usb/serial device which additionally to symlinking into /dev/usb creates a yaml file with the udevadm info content? This would be enough to programmatically check devices and read their information from something like node-red. What do you think?

[1] https://stackoverflow.com/questions/2422...ial-device
[2] https://www.guidodiepen.nl/2016/05/notif...container/
[3] https://stackoverflow.com/questions/4175...-container
  Reply
#9
(May-15th-2019, 10:06 AM)deme Wrote: OK, I did test with the hilschernetpi/rpi-raspbian image and saw that both /dev/bus/usb and /run/udev is not allowed to be mounted as volumes.

Well this is correct. netPI (restricted) Docker disables

* volume bind mapping of any host volumes
* automatic mapping of all /dev/'s into the container in "priviledged" mode

in order to never allow containerized applications - even if enabled in netPI's portainer.io web GUI - to compromise netPI's Host linux and give access to the SD card.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#10
Docker has also detected the dynamic USB device as a problem and came with a new flag you can set during container's start.

Read on the chapter "Dealing with dynamically created devices" here https://docs.docker.com/engine/reference...ne/create/.

Unfortunately the currently used netPI's portainer.io web GUI version cannot configure the flag "device-cgroup-rule" (and it's in the stars if it ever will) and hence solutions provided here https://github.com/th3mis/docker-usb-sync will not run on standard netPI even if you would have a udev rule host access. This solution receates a container whenver a USB device is plugged in and maps in the new device into the container. Nice idea by the way.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  USB Port Mapping DSongra 5 3,823 March-10th-2022, 09:20 AM
Last Post: Armin@netPI
  Ethercat master mapping SteP 1 2,246 March-2nd-2020, 12:42 PM
Last Post: Armin@netPI
  [SOLVED] Faulty devices description file from Github Whatzittoya13 5 3,395 March-11th-2019, 11:58 AM
Last Post: Armin@netPI
  Updating of many devices remotely Johannes 6 4,530 November-1st-2018, 12:35 PM
Last Post: Johannes
  [SOLVED] USB Serial device mapping into Container hannes 12 13,305 August-27th-2018, 04:50 PM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 2 Guest(s)