Correct identification of ttyUSB

[AlexanderZhirov]

I have several ttyUSB* devices that I use in Dongle. The bottom line is that after the system is rebooted, they switch places, and they connect incorrectly in Asterisk. The whole dial plan does not work correctly because of this. Is there a way to correctly identify the devices according to the dongle.conf file? Or at least by the specified IMEI or serial number to connect this or that ttyUSB* device correctly?

P.S. If possible, provide a link to the code snippet when the connection occurs. I'll try to check something in the interval before connecting, is the specified device in the dongle.conf file the one we attached in /dev/ttyUSB*?

UPD1: I understand that reading the installed devices is here?

UPD2: Hmm, would it be correct to make an AT request to check the IMEI, does it correspond to what is specified in the configuration file? How correct is it to use this way?

[nobody43]

The bottom line is that after the system is rebooted, they switch places, and they connect incorrectly in Asterisk.

udev rules to make the names consistent?

[AlexanderZhirov]

The bottom line is that after the system is rebooted, they switch places, and they connect incorrectly in Asterisk.

udev rules to make the names consistent?

In any case, i will have to call a third-party utility to access the ttyUSB device to pull out information about the modem from there, because this can only be found out through the AT command. Therefore, I am looking for a more correct and at the same time simple way.

[AlexanderZhirov]

Guys, I have found a solution to this problem. Alas, we will have to use third-party mechanisms. I am currently writing a utility in C that will work as a daemon and, when connecting devices, will create symbolic links to devices in the form of identifiers unique to the modem (for example, IMEI). Thus, regardless of the sequence in which the devices are connected, links will be created with a static name, and thus you will not have to reconnect modems in the right order for correct identification inside Asterisk.

I will notify you about further work.

[AlexanderZhirov]

That's what happened. Regardless of the order in which USB modems are connected, symbolic links with the correct device IMEI indexes will be created. Thus, there will be no need to reconnect them in the event of a PC reboot.

[AlexanderZhirov]

Guys, I'm sharing my development. I checked and tested the calls at home - everything is OK. If you have any suggestions for improvement or participation, please welcome.

https://github.com/AlexanderZhirov/MPortLink

[wdoekes]

Looks nice.

I would suggest placing the IMEI links in a subpath though, e.g.: /dev/gsm/by-imei/342...17-0 -> ../../ttyUSB0

(gsm might be preferable to modem or dongle)

See /dev/disk/by-* for a similar example.

[AlexanderZhirov]

@wdoekes

Dec 21 13:51:02 solus mportlink[17764]: main: starting the mportlink daemon
Dec 21 13:51:26 solus mportlink[17764]: mpl_symlink_ports, dst_path: the symbolic link has been successfully created [/dev/dongle/358**********26-0 -> /dev/ttyUSB0]
Dec 21 13:51:26 solus mportlink[17764]: mpl_symlink_ports, dst_path: the symbolic link has been successfully created [/dev/dongle/358**********26-1 -> /dev/ttyUSB1]
Dec 21 13:51:41 solus mportlink[17764]: mpl_unlink_ports, dst_path: link was successfully deleted [/dev/dongle/358**********26-0]
Dec 21 13:51:41 solus mportlink[17764]: mpl_unlink_ports, dst_path: link was successfully deleted [/dev/dongle/358**********26-1]
Dec 21 13:51:48 solus mportlink[17764]: signals_handler: cancelling the operation...
Dec 21 13:51:48 solus mportlink[17764]: signals_handler: cancelling the main loop...
Dec 21 13:51:48 solus mportlink[17764]: main: stopping the mportlink daemon

[AlexanderZhirov]

I still have ideas for creating a cli and unbinding from the original ModemManager, because it blocks ports and Asterisk (dongle) throws errors on the busy device.