Cellular Network Infrastructure » OsmoGSMTester

What about using the usb path if available?

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

would be really great to have this indeed.

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.

Waiting for review at ofono ml: https://lists.ofono.org/pipermail/ofono/2018-February/017892.html

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

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.