Feature #2509
closedofono: Find a way to have consistent paths for modems
100%
Description
Currently, paths for modem seems to be of the type "/" + modem_type + index (eg /sierra_1), where the index is calculated in way in which usually the same index is given to the same modem, but if the modem is re-plugged while ofono is running, then that modem re-appears in ofono with a new index.
In osmo-gsm-tester, we depend on the modem dbus path to identify them, and we require the path to stay the same as it's hardcoded in the config.
There should be some way by means of udev to gather some config specific for each modem (eg. usb device id), and use that instead of an increasing index. This way the path would remain stable. That would be the default name (eg. (/gobi_05c6_9215), but some udev rules could be applied to add a MODEM_NAME attribute to have any name for a path, (eg: /gobi_970010202, where the number is the imsi we know it is using).
I think this type of patch is going to be welcome in upstream if not yet available, and will free us from a lot of errors during tests.
Files
Updated by pespin over 6 years ago
I really don't care that much about what we use, as long as it's consistent to identify a given physical modem.
Updated by pespin about 6 years ago
- File 0001-udevng-Add-OFONO_PATHNAME-property-to-set-modem-dbus.patch 0001-udevng-Add-OFONO_PATHNAME-property-to-set-modem-dbus.patch added
- Status changed from New to In Progress
- Assignee changed from lynxis to pespin
I have a working patch for ofono which allows feeding the name used for the dbus path from a udev env variable intead of allocating it sequentially. In fact most of the code required was already in there, but the case to set a specific name was not being used by udevng.c backend.
udevng.c goes through all udev nodes and fills data structures in hashtable modem_list:
check_device -> check_usb_device -> add_device
Then it calls check_modem_list() to create the modems for each modem in the hashtable (calls function create_modem):
g_hash_table_foreach_remove(modem_list, create_modem, NULL); create_modem -> ofono_modem_create: modem->modem = ofono_modem_create(NULL, modem->driver);
struct ofono_modem *ofono_modem_create(const char *name, const char *type): if (name == NULL) snprintf(path, sizeof(path), "/%s_%d", type, next_modem_id); else snprintf(path, sizeof(path), "/%s", name);
How to use it:
$ cat /etc/udev/rules.d/90-local.rules SUBSYSTEMS=="usb", DEVPATH=="/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.1/3-1.1.4/3-1.1.4.1/3-1.1.4.1.1", ENV{OFONO_PATHNAME}="foo" $sudo udevadm control --reload-rules; sudo udevadm trigger $ sudo udevadm info -p /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.1/3-1.1.4/3-1.1.4.1/3-1.1.4.1.1 P: /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.1/3-1.1.4/3-1.1.4.1/3-1.1.4.1.1 N: bus/usb/003/026 E: BUSNUM=003 E: DEVNAME=/dev/bus/usb/003/026 E: DEVNUM=026 E: DEVPATH=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.1/3-1.1.4/3-1.1.4.1/3-1.1.4.1.1 E: DEVTYPE=usb_device E: DRIVER=usb E: ID_BUS=usb E: ID_MODEL=Qualcomm_Gobi_2000 E: ID_MODEL_ENC=Qualcomm\x20Gobi\x202000 E: ID_MODEL_FROM_DATABASE=Gobi 2000 E: ID_MODEL_ID=9205 E: ID_REVISION=0002 E: ID_SERIAL=Qualcomm_Incorporated_Qualcomm_Gobi_2000 E: ID_USB_INTERFACES=:ffffff: E: ID_VENDOR=Qualcomm_Incorporated E: ID_VENDOR_ENC=Qualcomm\x20Incorporated E: ID_VENDOR_FROM_DATABASE=Qualcomm, Inc. E: ID_VENDOR_ID=05c6 E: MAJOR=189 E: MINOR=281 E: OFONO_PATHNAME=foo <-------- E: PRODUCT=5c6/9205/2 E: SUBSYSTEM=usb E: TYPE=0/0/0 E: USEC_INITIALIZED=37021628322 *** start ofono *** $ mdbus2 -s org.ofono / /bluetooth /bluetooth/profile /bluetooth/profile/dun_gw /bluetooth/profile/hfp_ag /bluetooth/profile/hfp_hf /foo /mbm_0
I'll submit now the patch to ofono ml.
Updated by pespin about 6 years ago
- Status changed from In Progress to Feedback
Waiting for review at ofono ml: https://lists.ofono.org/pipermail/ofono/2018-February/017892.html
Updated by pespin about 6 years ago
My patch was not accepted but it triggered a discussion by which patches are submitted which export the sysfs path in the Modem interface properties (which means it can be easily obtained a list with something similar to mdbus2 -s org.ofono / GetModems()).
The patches were already merged in master. We Hence it neither to
1- Rebase our osmo-gsm-tester branch on top of current master
2- Cherry-pick patches to our branch:
4b1609c2d791ac73ff33751b7ca96316938414e6
895ca91d856ea3e8ca6e70fe77e11e8de4610bd8
1df92289d4e09a1e2db0b189b5153a4c238f98f1
Updated by pespin about 6 years ago
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
It took me a few hours, but I was finally able to rebase osmo-gsm-tester branch on top of current ofono master, which contains the fixes. We should really try better to havea more clean osmo-gsm-tester branch. It also looks like there's a few patches there which should be sent upstream. lynxis please have a look at the new branch to make sure I forgot something, and feel free to clean it up further.
I pushed the new osmo-gsm-tester branch as osmo-gsm-tester, and moved the old osmo-gsm-tester branch based on ofono 1.20 to be named "osmo-gsm-tester-1.20". I fetched manually the new osmo-gsm-tester branch in both prod and r&d main units, built it and installed it.
I created a patch for osmo-gsm-tester (e25cf04aeb320b4a859ba5b1337e953321880595, https://gerrit.osmocom.org/#/c/6858/) to discover the ofono path from sysfs path, and updated the resources.conf to use sysfs paths instead of ofono paths. It is now merged.