[RussianNeuroMancer]

Hello!

I trying to figure out how to get Snapdragon X12 LTE (labelled as HP lt4220) working with usb-modeswitch 2.5.2 on Ubuntu 18.10.

Original modem state: https://paste.fedoraproject.org/paste/p ... iOMIqIGyeQ

I tried to add /usr/share/usb_modeswitch/03f0:0857 with Configuration=0 and following rule:

Code: Select all

ATTR{idVendor}=="03f0", ATTR{idProduct}=="0857", RUN+="usb_modeswitch '/%k'"

However, usb-modeswitch wasn't able to switch configuration: https://paste.fedoraproject.org/paste/j ... iPVkXEm44A

Then I tried Configuration=3 instead and it works: https://paste.fedoraproject.org/paste/Y ... gZQ4P5-N3g

So I guess HP lt4220 can be addaded to database now?

[Josh]

The log you linked is somewhat strange.

It shows that there is code in the wrapper to bind driver modules to the freshly mode-switched device.
However, that code was removed entirely with version 2.4.0.

Also, that log output shows the cause why "Configuration=0" didn't work:

Code: Select all

Device may have an MBIM configuration, check driver ...
 no MBIM driver found, switch to legacy modem mode

The script looks for the MBIM driver here:
/lib/modules/<your-kernel-version>/kernel/drivers/net/usb/cdc_mbim...

Since it didn't find anything with that name, it didn't even start to look for a MBIM mode in the device.

[RussianNeuroMancer]

The log you linked is somewhat strange.

It shows that there is code in the wrapper to bind driver modules to the freshly mode-switched device.
However, that code was removed entirely with version 2.4.0.

Just in case, here is source code of binary that I run: https://launchpad.net/ubuntu/+archive/p ... rig.tar.xz

Also, that log output shows the cause why "Configuration=0" didn't work:

Code: Select all

Device may have an MBIM configuration, check driver ...
 no MBIM driver found, switch to legacy modem mode

The script looks for the MBIM driver here:
/lib/modules/<your-kernel-version>/kernel/drivers/net/usb/cdc_mbim...

Since it didn't find anything with that name, it didn't even start to look for a MBIM mode in the device.

I checked this:

1. I set Configuration=0 and then power cycle tablet, usb-modeswitch failed to apply Configuration=0: https://paste.fedoraproject.org/paste/m ... tur2qi1huw
2. Then without reboot I changed Configuration to 3, and did "sudo systemctl status usb_modeswitch@2-3.service"
3. Configuration was applied succesfully and MBIM driver was found, here is log:
https://paste.fedoraproject.org/paste/8 ... edJuiADcHw
And here is dmesg of whole process, where you can see MBIM driver loading: https://paste.fedoraproject.org/paste/H ... UfvWALlQIg

Code: Select all

~$ ls /lib/modules/4.19.0-041900-generic/kernel/drivers/net/usb | grep cdc
cdc_eem.ko
cdc_ether.ko
cdc_mbim.ko
cdc_ncm.ko
cdc-phonet.ko
cdc_subset.ko
huawei_cdc_ncm.ko

[LOM]

The log you linked is somewhat strange.

It shows that there is code in the wrapper to bind driver modules to the freshly mode-switched device.
However, that code was removed entirely with version 2.4.0.

Obviously not removed in Ubuntu's homehacked version of usb_modeswitch..
They seem to have their own version of usb_modeswitch.tcl as well.
Let them clean up their own bugs, I'm sure that the official usb_modeswitch will find the cdc_mbim driver and will select the mbim configuration, it has been proved working for a lot of devices under various linux systems.

[LOM]

Then I tried Configuration=3 instead and it works: https://paste.fedoraproject.org/paste/Y ... gZQ4P5-N3g

So I guess HP lt4220 can be addaded to database now?

It can be added with Configuration=0 in the device config file.

Config #2 is selected by the linux usb core as default and it will work for users who has an older kernel without mbim support, we should not change that default.

[RussianNeuroMancer]

Obviously not removed in Ubuntu's homehacked version of usb_modeswitch..
They seem to have their own version of usb_modeswitch.tcl as well.
Let them clean up their own bugs, I'm sure that the official usb_modeswitch will find the cdc_mbim driver and will select the mbim configuration, it has been proved working for a lot of devices under various linux systems.

Ok, filled bugreport to them: https://bugs.launchpad.net/ubuntu/+sour ... ug/1800794

It can be added with Configuration=0 in the device config file.

Thanks!

[Josh]

Just in case, here is source code of binary that I run: https://launchpad.net/ubuntu/+archive/p ... rig.tar.xz

I don't think that this is what you are running. This is the original Debian source package which uses the script dispatcher. Ubuntu replaces it with their binary dispatcher.

So as LOM stated, there is not much we can do here. For testing purposes, you can try to install the latest version from the source available here.

As there are no complicated dependencies (apart from installing the "tcl" and "libusb1-devel" packages), it's no problem to re-install the Ubuntu package afterwards.

[Josh]

To clarify for the Ubuntu bug report reference:

The usb_modeswitch_dispatcher has a built-in function to "auto-treat" modems that conform to the MBIM standard. These modems usually provide multiple USB configurations (as opposed to 'modes').

One of these configurations implements the MBIM interface, annother provides a fall-back modem interface ('serial').
usb_modeswitch first checks for the availability of the MBIM driver (module "cdc_mbim"); if present, the modem is checked for an MBIM configuration. If one or both of these conditions are not met, the choice of configuration is left to the USB core which ends up using the serial modem configuration.

The configuration value of "0" in the usb_modeswitch config file (data package) indicates this automatic treatment.

[RussianNeuroMancer]

Just in case, here is source code of binary that I run: https://launchpad.net/ubuntu/+archive/p ... rig.tar.xz

I don't think that this is what you are running. This is the original Debian source package which uses the script dispatcher. Ubuntu replaces it with their binary dispatcher.

Replaced source have to be somewhere, maybe in patches folder of usb-modeswitch_2.5.2+repack0-2ubuntu1.debian.tar.xz from this page?

[Josh]

Yes, there is "dispatcher-c-rewrite.patch" in that folder. That's the dispatcher of Ubuntu.

If you want to help with finding the issue, see the function definition of "check_mbim_available". That's where the path for checking the availability of "cdc_mbim" is created.

You can just let it log the resulting path string to see if it is correct. The error must be somewhere there.

[RussianNeuroMancer]

Yes, there is "dispatcher-c-rewrite.patch" in that folder. That's the dispatcher of Ubuntu.

If you want to help with finding the issue, see the function definition of "check_mbim_available". That's where the path for checking the availability of "cdc_mbim" is created.

You can just let it log the resulting path string to see if it is correct. The error must be somewhere there.

I am not developer really, but I tried to look into this. Something like this could work or I did some stupid mistake here?

Code: Select all

check_mbim_available (void)
{
	int kver_fd = -1;
	ssize_t read_count;
	char kversion[100];
	char *cdc_mbim_module_path;
+	string check_path;
	struct stat buf;

	kver_fd = open(OSRELEASE_FILE, O_RDONLY);
	if (kver_fd > -1) {
		read_count = read(kver_fd, &kversion, 100);
		if (read_count > 0) {
			asprintf(&cdc_mbim_module_path, "%s/%s/%s",
			         MODULES_PATH,
			         kversion,
			         CDC_MBIM_DRIVER_PATH);
+			check_path = cdc_mbim_module_path;
+			modeswitch_log("\Let's check cdc_mbim_module_path : %s\n", check_path);
			if (!stat(cdc_mbim_module_path, &buf))
				goto success;
			if (!stat(CDC_MBIM_SYS_PATH, &buf))
				goto success;
		}
	}

	free(cdc_mbim_module_path);
	return 0;
success:
	free(cdc_mbim_module_path);
	return 1;
}

[Josh]

I am not developer really, but I tried to look into this. Something like this could work

Almost.

There is no "string" data type in C, but you don't need it as the actual string is already present:
char* cdc_mbim_module_path;

So you would need only the logging line, just where you placed it (after the "asprintf" line):

Code: Select all

check_mbim_available (void)
{
   int kver_fd = -1;
   ssize_t read_count;
   char kversion[100];
   char *cdc_mbim_module_path;
   struct stat buf;

   kver_fd = open(OSRELEASE_FILE, O_RDONLY);
   if (kver_fd > -1) {
      read_count = read(kver_fd, &kversion, 100);
      if (read_count > 0) {
         asprintf(&cdc_mbim_module_path, "%s/%s/%s",
                  MODULES_PATH,
                  kversion,
                  CDC_MBIM_DRIVER_PATH);
+        modeswitch_log("\n -> Let's check cdc_mbim_module_path : %s\n", cdc_mbim_module_path);
         if (!stat(cdc_mbim_module_path, &buf))
            goto success;
         if (!stat(CDC_MBIM_SYS_PATH, &buf))
            goto success;
      }
   }

   free(cdc_mbim_module_path);
   return 0;
success:
   free(cdc_mbim_module_path);
   return 1;
}

Don't kill me if it doesn't work right away ...

[RussianNeuroMancer]

There is no "string" data type in C, but you don't need it as the actual string is already present:
char* cdc_mbim_module_path;

So you would need only the logging line, just where you placed it (after the "asprintf" line):
Don't kill me if it doesn't work right away ...

It works, thank you!

Here is log of run with with Configuration=0: https://paste.fedoraproject.org/paste/Z ... rTIACRwO9Q

I checked, and file cdc_mbim.ko is indeed present in this location. So maybe problem not with path, but with the way, how it's verified if MBIM driver is present?

[Josh]

I assume the line break in the path output was done by the pastebin webpage, right?

I agree that the search did not succeed somehow. I have no idea why though. It's really a case for the Ubuntu maintainser.

[RussianNeuroMancer]

I assume the line break in the path output was done by the pastebin webpage, right?

No, line break came from this:

Code: Select all

#define OSRELEASE_FILE "/proc/sys/kernel/osrelease"

which contain this:

Code: Select all

~$ cat /proc/sys/kernel/osrelease 
4.19.0-041900-generic
~$ cat /proc/sys/kernel/osrelease | hexdump
0000000 2e34 3931 302e 302d 3134 3039 2d30 6567
0000010 656e 6972 0a63                         
0000016

As I understand 0a is line break.

So we find potential suspect?