Static device symlink in /dev/

A

aonishenko

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?
 
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.
 
First_Law_of_Unix said:
Did a lot of googling
Click to expand...

mer already nudged you in the right direction:
forums.freebsd.org

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 forums.freebsd.org

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

devd(8)

www.freebsd.org www.freebsd.org
 
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.
 
Output for cam details:

Code: 
usbconfig -d ugen2.2 dump_device_desc

Code: 
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


Code: 
usbconfig -d ugen4.2 dump_device_desc

Code: 
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
 
Phishfry said:
Chicoms got you. I have nothing.
Click to expand...
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:
www.arducam.com

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 is required, like when you are trying to build a DIY camera cluster, or a raspberry...
www.arducam.com www.arducam.com
 
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.
 
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 ...
Click to expand...
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.
 
First_Law_of_Unix said:
I guess I'll try to change the serial number or prevent ugen swapping some how.
Click to expand...
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.
 
  • Like
Reactions: mer
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.
 
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.
Click to expand...

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.
Click to expand...
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".

A helper script is a good idea, makes it easy to test the logic and assignment.
Click to expand...
I hope this is the case. Thanks.
 
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,
Click to expand...
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.
 
Phishfry said:
That is my view. Greedy companies chose to offshore and sacrificed thier designs.
Click to expand...

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?
 
You must log in or register to reply here.
Back
Top