# Static device symlink in /dev/



## aonishenko (Jun 13, 2017)

Hi!

I use FreeBSD 11. I have USB modem, which connects in the usb port. Sometimes it jumps from /dev/cua0.0 to /dev/cua0.1 and my ppp process crashes.
Is it possible to create static device link in /dev/ folder according to device id and vendor id?


----------



## aragats (Jun 13, 2017)

You can add your rules to /etc/devd.conf. There are already entries with vendor/product id in that file, just copy, paste and adjust for your needs.


----------



## First_Law_of_Unix (Sep 14, 2022)

I'm trying to do the same thing as to OP, but for webcams. I have 6 USB cams and would like static symlinks to /dev/video0, /dev/video1, /dev/video2... so that the cams will never change with the symlinks in placed.

Did a lot of googling and couldn't find any examples which seems understandable to me.

Thanks.


----------



## Phishfry (Sep 14, 2022)

First_Law_of_Unix said:


> Did a lot of googling



mer already nudged you in the right direction:








						How to automatically execute commands that require "su" privileges during user login.
					

Hello,  I couldn't find any information from the web on how to make a shell script which can automatically execute commands that require "su" privileges during user login.  I have read that I can store the shell script at "/etc/profile.d/" location which did not exist by default and I had to...




					forums.freebsd.org
				




USB addresses are unreliable and you must use help. devd in this case.





						devd(8)
					






					www.freebsd.org


----------



## First_Law_of_Unix (Sep 14, 2022)

Thanks,

I have an issue that the 6 USB cams all have identical vendor, hardware. model and serial names... so what are my options to make the cam connected to lets say USB port 1 to always and surely be /dev/video0?

The devd help section doesn't provide any info which I can understand easily for my situation.


----------



## Phishfry (Sep 14, 2022)

Look for a unique identifier:
`usbconfig dump_device_desc`

And use that in devd.conf instead of VID/PID


----------



## Phishfry (Sep 14, 2022)

First_Law_of_Unix said:


> iSerialNumber = 0x0006 <HU123450>


Like this.


----------



## First_Law_of_Unix (Sep 14, 2022)

Output for cam details:


```
usbconfig -d ugen2.2 dump_device_desc
```


```
ugen2.2: <USB3.0 HD Audio Capture USB3.0 HD Video Capture> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)

  bLength = 0x0012

  bDescriptorType = 0x0001

  bcdUSB = 0x0200

  bDeviceClass = 0x00ef  <Miscellaneous device>

  bDeviceSubClass = 0x0002

  bDeviceProtocol = 0x0001

  bMaxPacketSize0 = 0x0040

  idVendor = 0xeba4

  idProduct = 0x7588

  bcdDevice = 0x0328

  iManufacturer = 0x0001  <USB3.0 HD Audio Capture>

  iProduct = 0x0002  <USB3.0 HD Video Capture>

  iSerialNumber = 0x0006  <HU123450>

  bNumConfigurations = 0x0001
```



```
usbconfig -d ugen4.2 dump_device_desc
```


```
ugen4.2: <USB3.0 HD Audio Capture USB3.0 HD Video Capture> at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)

  bLength = 0x0012

  bDescriptorType = 0x0001

  bcdUSB = 0x0200

  bDeviceClass = 0x00ef  <Miscellaneous device>

  bDeviceSubClass = 0x0002

  bDeviceProtocol = 0x0001

  bMaxPacketSize0 = 0x0040

  idVendor = 0xeba4

  idProduct = 0x7588

  bcdDevice = 0x0328

  iManufacturer = 0x0001  <USB3.0 HD Audio Capture>

  iProduct = 0x0002  <USB3.0 HD Video Capture>

  iSerialNumber = 0x0006  <HU123450>

  bNumConfigurations = 0x0001
```


----------



## First_Law_of_Unix (Sep 14, 2022)

First_Law_of_Unix said:


> iSerialNumber = 0x0006 <HU123450>





Phishfry said:


> Like this.



All six cams have the same serial number. Previous post gave details just for two different connected cams. Is it possible maybe to try to change the serial number is they are not hard coded into the webcam device?


----------



## Phishfry (Sep 14, 2022)

Chicoms got you. I have nothing.


----------



## First_Law_of_Unix (Sep 14, 2022)

Phishfry said:


> Chicoms got you. I have nothing.


It's gunna get better... wait until I bring posts about the $3 mediatek dual core 64bit flagship ARM processors SoC, extremely powerful, used in many tablets and have 4K H.265 built in transcoding.

So the only unique thing about the cam details is the "ugen" identifier... you're saying that it's not reliable to do syslinks based on "ugen"?

I see that there is a software to permanently change the serial number on Windows 10..., it would be so silly for FreeBSD and Linux users going back to their old dusty stash to find their copy of Windows 10 and installing it just to do this implementation:








						How We Can Make Multiple USB Camera Modules More Identifiable: Solution To Duplicate Device Names and /dev/video Problems - Arducam
					

Using Multiple Camera Modules in Linux and Windows Can Be Convenient and Problematic At the Same Time Bandwidth aside, there are many situations where using more than 2 camera modules with your hardware of choice Read more…




					www.arducam.com


----------



## Phishfry (Sep 14, 2022)

First_Law_of_Unix said:


> you're saying that it's not reliable to do syslinks based on "ugen"?


ugens can shift with reboots.
They don't usually but they can.
This is why on USB storage we use labels. You really don't want to link to ugens.
I mean if its just for you it will work 99% of the time maybe.
CAM1 might shift to CAM6, no big deal right?


----------



## Phishfry (Sep 14, 2022)

That was sarcasm. It is a big deal and I don't have any answers.

Firmware flasher for the cameras to issue usb serial number would be ideal.
Good luck with that.


----------



## First_Law_of_Unix (Sep 14, 2022)

Phishfry said:


> CAM1 might shift to CAM6, no big deal right?


Oh no... it is a great big deal. I guess I have to find ways to distinguish programmatically of the cams. I guess I'll try to change the serial number or prevent ugen swapping some how.

Edit:


Phishfry said:


> That was sarcasm.


Thats good to know...


----------



## Phishfry (Sep 14, 2022)

Storage is a little different in that you can brute force disk names with /boot/device.hints.

IPCams have onvif. When it works it is really great stuff.


----------



## ralphbsz (Sep 14, 2022)

First_Law_of_Unix said:


> Oh no... it is a great big deal. I guess I have to find ways to distinguish programmatically of the cams. I guess I'll try to change the serial number ...


In a nutshell, you are the victim of a vendor of low-quality hardware. Putting distinct serial numbers on different devices is sort of the minimum amount of effort you should expect.

Here's a crazy idea: Can you control the lighting of the area the cameras look at from the computer? Then you could distinguish by turning the lights of in one room at a time, and checking which camera goes dark.


----------



## Tieks (Sep 14, 2022)

First_Law_of_Unix said:


> I guess I'll try to change the serial number or prevent ugen swapping some how.


Changing the serial number could be hard. In my experience the ugen's will always remain the same unless you reboot after plugging in an (additional) device. Or after you changed the BIOS-settings concerning USB.
I think I would just connect and configure the cameras as planned. Then make a script that checks the availability of `/dev/video0` up to `/dev/video5`. Run that script at boot or from cron. If the devices are there, they will usually show up in the same order, that is, the same camera at the same ugen.


----------



## mer (Sep 14, 2022)

My experience is similar to Tieks as long as you don't change the ports things are plugged into, the ugen stays the same.  Why?  It seems to be related to the whole USB topology as things are discovered.  Start at the root controller on the motherboard, start walking down it's ports, find a hub, walk it's ports, etc.  I've seen the same behavior on bunch of different Linux distros/kernel versions.

As pointed out, if you muck with BIOS settings you could change it, sometimes changing kernels affected it.
And I've also run into the same "just put the same serial number on everything so we can't identify anything".

A helper script is a good idea, makes it easy to test the logic and assignment.


----------



## First_Law_of_Unix (Sep 15, 2022)

ralphbsz said:


> In a nutshell, you are the victim of a vendor of low-quality hardware. Putting distinct serial numbers on different devices is sort of the minimum amount of effort you should expect.
> 
> Here's a crazy idea: Can you control the lighting of the area the cameras look at from the computer? Then you could distinguish by turning the lights of in one room at a time, and checking which camera goes dark.



The hardware is not too bad, it actually gets the job done for it's purpose, I believe the hardware is fine but the only issue seems to be software organization, seems like the Manufacturer just rapid produce the capture cards without putting effort to serializing each device. It all boils done for getting the job done with acceptable quality, the hardware I am using for the capture cards costs around $20 (costs much less if I bought the IC chips and make my own PCBs) but to get proper professional capture cards will cost around $200, whats even worst about professional capture cards is that the IC chips they uses are all super secretive and patented, impossible to buy them in discrete parts, so it means I can not gain any benefits to learn easily how and why these devices work at the hardware level so that I can design and make my own devices. I need six of these(actually need more), so 6 x $200 thats $1,200 I need to spend for prototyping my PC DVR concept. In my opinion $1,200 is way over kill for a security DVR system for my home, I am simply paying profits with that price. Now it is a big issue for not having the hardware being serialized, but thankfully with the help of software there are ways to able to distinguish which capture device is which with the help of machine vision. I actually like challenging nuisances, it brings new knowledge to fix problems for both hardware and software and make better and lower cost products in the future.
Hardware in China are actually mature and super advanced (its why USA is blocking their tech in the world) and with the ridiculous low prices the're selling would be super silly to not learn and find solutions of it's nuisances, imagine the profits you could make with your idea using it's low cost hardware which is super advanced. This is my ideology in prototyping and making products from scratch. If the chips does the job at one tenth of the price and only wished something could be better about it, simply call the manufacturer and they will work with you so long you buy bulk order.



Tieks said:


> Changing the serial number could be hard. In my experience the ugen's will always remain the same unless you reboot after plugging in an (additional) device. Or after you changed the BIOS-settings concerning USB.
> I think I would just connect and configure the cameras as planned. Then make a script that checks the availability of `/dev/video0` up to `/dev/video5`. Run that script at boot or from cron. If the devices are there, they will usually show up in the same order, that is, the same camera at the same ugen.


Thanks.



mer said:


> My experience is similar to Tieks as long as you don't change the ports things are plugged into, the ugen stays the same.  Why?  It seems to be related to the whole USB topology as things are discovered.  Start at the root controller on the motherboard, start walking down it's ports, find a hub, walk it's ports, etc.  I've seen the same behavior on bunch of different Linux distros/kernel versions.
> 
> As pointed out, if you muck with BIOS settings you could change it, sometimes changing kernels affected it.
> And I've also run into the same "just put the same serial number on everything so we can't identify anything".
> ...


I hope this is the case. Thanks.


----------



## Phishfry (Sep 15, 2022)

First_Law_of_Unix said:


> Hardware in China are actually mature and super advanced (its why USA is blocking their tech in the world) and with the ridiculous low prices the're selling would be super silly to not learn and find solutions of it's nuisances,


The nuisance you speak of is called cloning.
They are good at cloning other peoples work.
Designing products not so much.
That is my view. Greedy companies chose to offshore and sacrificed thier designs.
Now you can buy a 20 dollar capture dongle that this manufacturing company surely did not design.
If they did they would have a firmware flasher available for you.


----------



## First_Law_of_Unix (Sep 15, 2022)

Phishfry said:


> That is my view. Greedy companies chose to offshore and sacrificed thier designs.



You're right but end of the day it's somehow helping me (and millions of others) greatly in not spending $1,200 to begin with, it's all about the money. All I'm doing is taking this cloning shenanigans to my great advantage. Why should we ever care if something _iniquitous_ is happening to the fat katz which ends up being a good thing for us?


----------

