Project

General

Profile

Feature #2509

ofono: Find a way to have consistent paths for modems

Added by pespin 11 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
09/10/2017
Due date:
% Done:

100%

Estimated time:
Spec Reference:

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.

History

#1 Updated by lynxis 10 months ago

What about using the usb path if available?

#2 Updated by pespin 10 months ago

I really don't care that much about what we use, as long as it's consistent to identify a given physical modem.

#3 Updated by neels 10 months ago

would be really great to have this indeed.

#4 Updated by pespin 5 months ago

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.

#5 Updated by pespin 5 months ago

  • Status changed from In Progress to Feedback

#6 Updated by pespin 5 months 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

#7 Updated by pespin 5 months 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)