The C Source, Patches and (shudder!) Bugs
Post Reply
tjjh89017
Posts: 4
Joined: 31 Jul 2022, 15:26

udev should not be triggered again in "change" event

Post by tjjh89017 » 31 Jul 2022, 15:49

I tested Huawei ME909s-821 LTE module and found a bug in usb-modeswitch-data's udev rules.
I attached the patch in this thread.

Root cause:
Huawei ME909s only needs to change configuration.
If I override Configuration in /etc/usb_modeswitch.d/12d1:15c1 with Configuration=3
usb-modeswitch will not change ID/product.
and udev's rules is incorrect.
It will be triggered again, and kill/stop the first systemctl restart usb_modeswitch@<DEV>.service
Configuration will not be applied correctly and leave it as Configuration=0 (unconfigurated).

I used echo 3 >/sys.../bConfigurationValue.
It will be rollback because the above reason. (udev will be triggered again and again)

I executed usb_modeswitch maually it will complain this device is unconfigurated.

Fix:
Udev "match" is AND operatation.

Code: Select all

SUBSYSTEM!="usb", ACTION!="add",, GOTO="modeswitch_rules_end"
It will match device is usb and return FALSE in this match.
It will never check the ACTION.

Fix it with

Code: Select all

SUBSYSTEM!="usb", GOTO="modeswitch_rules_end"
ACTION!="add", GOTO="modeswitch_rules_end"
It works fine and properly again.

Thanks a lot
Date Huang
Attachments
0001-Avoid-udev-rule-being-triggered-again-in-change-even.patch
(1.15 KiB) Downloaded 378 times

dominicburton
Posts: 1
Joined: 11 Nov 2022, 17:55

Re: udev should not be triggered again in "change" event

Post by dominicburton » 11 Nov 2022, 18:40

I found that the Huawei ME909s-821 LTE module does not work on Ubuntu 18.04. I believe it is because of the usb-modeswitch-data's udev rules.

mikhailnov
Posts: 1
Joined: 03 Feb 2023, 11:52

Re: udev should not be triggered again in "change" event

Post by mikhailnov » 03 Feb 2023, 11:57

Thanks for your patch. It helps to make this modem Huawei ME906s LTE M.2 Module work. I have made an a bit different version of it:

From 98b596d73f789b6a787e89c7dd908fa1c5954042 Mon Sep 17 00:00:00 2001
From: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
Date: Mon, 30 Jan 2023 15:43:47 +0300
Subject: [PATCH] Call usb_modeswitch only on "add" event

Modern Linux kernel have the following events:

Code: Select all

static const char *kobject_actions[] = {
	[KOBJ_ADD] =		"add",
	[KOBJ_REMOVE] =		"remove",
	[KOBJ_CHANGE] =		"change",
	[KOBJ_MOVE] =		"move",
	[KOBJ_ONLINE] =		"online",
	[KOBJ_OFFLINE] =	"offline",
	[KOBJ_BIND] =		"bind",
	[KOBJ_UNBIND] =		"unbind",
};
(from Linux 6.1, lib/kobject_uevent.c)

Changelog of systemd (udev) 247 says that new events appeared and changes were made in udev:
https://github.com/systemd/systemd/blob/v247/NEWS#L5

Calling usm_modeswitch makes sense only on "add" event and makes no sense on "bind" (which means that a kernel module supporting this device has been assiciated with it), "unbind", "change" (which means quite a lot of situations) etc.

It was called multiple times for Huawei ME906s LTE M.2 modem which prevented it from working properly. It works now.

Based on solution from Date Huang <tjjh89017@hotmail.com> at viewtopic.php?f=2&t=3034&p=19976

Co-authored-by: Date Huang <tjjh89017@hotmail.com>
Co-authored-by: SgAkErRu <sulmpx60@yandex.ru>

Code: Select all


---
 40-usb_modeswitch.rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/40-usb_modeswitch.rules b/40-usb_modeswitch.rules
index dae3e3a..16f404b 100644
--- a/40-usb_modeswitch.rules
+++ b/40-usb_modeswitch.rules
@@ -3,13 +3,13 @@
 # Works with usb_modeswitch versions >= 2.4.0. Slash before %k parameter
 # is for compatibility only. Versions >= 2.5.0 don't need it.
 #
-ACTION!="add|change", GOTO="modeswitch_rules_end"
+ACTION!="add", GOTO="modeswitch_rules_end"
 
 # Adds a symlink "gsmmodem[n]" to the lowest ttyUSB port with interrupt
 # transfer; checked against a list of known modems, or else no action
 KERNEL=="ttyUSB*", ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK+="%c"
 
-SUBSYSTEM!="usb", ACTION!="add",, GOTO="modeswitch_rules_end"
+SUBSYSTEM!="usb", GOTO="modeswitch_rules_end"
 
 # Generic entry for most Huawei devices, excluding Android phones
 ATTRS{idVendor}=="12d1", ATTRS{manufacturer}!="Android", ATTR{bInterfaceNumber}=="00", ATTR{bInterfaceClass}=="08", RUN+="usb_modeswitch '%b/%k'"
-- 
2.35.2
Attachments
0001-Call-usb_modeswitch-only-on-add-event.patch
(2.37 KiB) Downloaded 204 times

x260
Posts: 1
Joined: 19 Mar 2023, 19:56

Re: udev should not be triggered again in "change" event

Post by x260 » 19 Mar 2023, 20:07

mikhailnov wrote: 03 Feb 2023, 11:57 Thanks for your patch. It helps to make this modem Huawei ME906s LTE M.2 Module work. I have made an a bit different version of it:

From 98b596d73f789b6a787e89c7dd908fa1c5954042 Mon Sep 17 00:00:00 2001
From: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
Date: Mon, 30 Jan 2023 15:43:47 +0300
Subject: [PATCH] Call usb_modeswitch only on "add" event

Modern Linux kernel have the following events:

Code: Select all

static const char *kobject_actions[] = {
	[KOBJ_ADD] =		"add",
	[KOBJ_REMOVE] =		"remove",
	[KOBJ_CHANGE] =		"change",
	[KOBJ_MOVE] =		"move",
	[KOBJ_ONLINE] =		"online",
	[KOBJ_OFFLINE] =	"offline",
	[KOBJ_BIND] =		"bind",
	[KOBJ_UNBIND] =		"unbind",
};
(from Linux 6.1, lib/kobject_uevent.c)

Changelog of systemd (udev) 247 says that new events appeared and changes were made in udev:
https://github.com/systemd/systemd/blob/v247/NEWS#L5

Calling usm_modeswitch makes sense only on "add" event and makes no sense on "bind" (which means that a kernel module supporting this device has been assiciated with it), "unbind", "change" (which means quite a lot of situations) etc.

It was called multiple times for Huawei ME906s LTE M.2 modem which prevented it from working properly. It works now.

Based on solution from Date Huang <tjjh89017@hotmail.com> at viewtopic.php?f=2&t=3034&p=19976

Co-authored-by: Date Huang <tjjh89017@hotmail.com>
Co-authored-by: SgAkErRu <sulmpx60@yandex.ru>

Code: Select all


---
 40-usb_modeswitch.rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/40-usb_modeswitch.rules b/40-usb_modeswitch.rules
index dae3e3a..16f404b 100644
--- a/40-usb_modeswitch.rules
+++ b/40-usb_modeswitch.rules
@@ -3,13 +3,13 @@
 # Works with usb_modeswitch versions >= 2.4.0. Slash before %k parameter
 # is for compatibility only. Versions >= 2.5.0 don't need it.
 #
-ACTION!="add|change", GOTO="modeswitch_rules_end"
+ACTION!="add", GOTO="modeswitch_rules_end"
 
 # Adds a symlink "gsmmodem[n]" to the lowest ttyUSB port with interrupt
 # transfer; checked against a list of known modems, or else no action
 KERNEL=="ttyUSB*", ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK+="%c"
 
-SUBSYSTEM!="usb", ACTION!="add",, GOTO="modeswitch_rules_end"
+SUBSYSTEM!="usb", GOTO="modeswitch_rules_end"
 
 # Generic entry for most Huawei devices, excluding Android phones
 ATTRS{idVendor}=="12d1", ATTRS{manufacturer}!="Android", ATTR{bInterfaceNumber}=="00", ATTR{bInterfaceClass}=="08", RUN+="usb_modeswitch '%b/%k'"
-- 
2.35.2
I have Lenovo Thinkpad X260 laptop and Huawei Technologies Co., Ltd. ME906s LTE M.2 Module (12d1:15c1).
I could not use the modem with Fedora 37's Linux 6.1.18 kernel.
After applied your patch to my /lib/udev/rules.d/40-usb_modeswitch.rules file, it worked!

I think this patch should applied to usb_modeswitch itself.

tjjh89017
Posts: 4
Joined: 31 Jul 2022, 15:26

Re: udev should not be triggered again in "change" event

Post by tjjh89017 » 10 Apr 2023, 19:23

mikhailnov wrote: 03 Feb 2023, 11:57 Thanks for your patch. It helps to make this modem Huawei ME906s LTE M.2 Module work. I have made an a bit different version of it:

From 98b596d73f789b6a787e89c7dd908fa1c5954042 Mon Sep 17 00:00:00 2001
From: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
Date: Mon, 30 Jan 2023 15:43:47 +0300
Subject: [PATCH] Call usb_modeswitch only on "add" event

Modern Linux kernel have the following events:

Code: Select all

static const char *kobject_actions[] = {
	[KOBJ_ADD] =		"add",
	[KOBJ_REMOVE] =		"remove",
	[KOBJ_CHANGE] =		"change",
	[KOBJ_MOVE] =		"move",
	[KOBJ_ONLINE] =		"online",
	[KOBJ_OFFLINE] =	"offline",
	[KOBJ_BIND] =		"bind",
	[KOBJ_UNBIND] =		"unbind",
};
(from Linux 6.1, lib/kobject_uevent.c)

Changelog of systemd (udev) 247 says that new events appeared and changes were made in udev:
https://github.com/systemd/systemd/blob/v247/NEWS#L5

Calling usm_modeswitch makes sense only on "add" event and makes no sense on "bind" (which means that a kernel module supporting this device has been assiciated with it), "unbind", "change" (which means quite a lot of situations) etc.

It was called multiple times for Huawei ME906s LTE M.2 modem which prevented it from working properly. It works now.

Based on solution from Date Huang <tjjh89017@hotmail.com> at viewtopic.php?f=2&t=3034&p=19976

Co-authored-by: Date Huang <tjjh89017@hotmail.com>
Co-authored-by: SgAkErRu <sulmpx60@yandex.ru>

Code: Select all


---
 40-usb_modeswitch.rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/40-usb_modeswitch.rules b/40-usb_modeswitch.rules
index dae3e3a..16f404b 100644
--- a/40-usb_modeswitch.rules
+++ b/40-usb_modeswitch.rules
@@ -3,13 +3,13 @@
 # Works with usb_modeswitch versions >= 2.4.0. Slash before %k parameter
 # is for compatibility only. Versions >= 2.5.0 don't need it.
 #
-ACTION!="add|change", GOTO="modeswitch_rules_end"
+ACTION!="add", GOTO="modeswitch_rules_end"
 
 # Adds a symlink "gsmmodem[n]" to the lowest ttyUSB port with interrupt
 # transfer; checked against a list of known modems, or else no action
 KERNEL=="ttyUSB*", ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK+="%c"
 
-SUBSYSTEM!="usb", ACTION!="add",, GOTO="modeswitch_rules_end"
+SUBSYSTEM!="usb", GOTO="modeswitch_rules_end"
 
 # Generic entry for most Huawei devices, excluding Android phones
 ATTRS{idVendor}=="12d1", ATTRS{manufacturer}!="Android", ATTR{bInterfaceNumber}=="00", ATTR{bInterfaceClass}=="08", RUN+="usb_modeswitch '%b/%k'"
-- 
2.35.2
Hi @mikhailnov

Please note some devices will switch mode and change the device id and need to trigger udev rule again.
and change event might need this command to be executed

Code: Select all

KERNEL=="ttyUSB*", ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK+="%c"
I looked back to previous version and only modified one line to make sure the behavior is as same as the previous.
So could you help to check this line should be patched or not?
I don't have confidence about that.

Code: Select all

ACTION!="add|change", GOTO="modeswitch_rules_end"
Thanks your patch!

By the way, I think we should ask distro package maintainer to help us to contact the author.
I used email, contact me link below, but no luck.
We don't get any reply from the author.

carolynquin
Posts: 2
Joined: 09 Nov 2023, 06:52

Re: udev should not be triggered again in "change" event

Post by carolynquin » 09 Nov 2023, 06:57

In my yocto-base Linux distribution if I modify a rule about USB storage plug in (sorry not about network changes like in your question) and execute udevadm control --reload-rules the rule change doesn't need a reboot drift hunters

Edusistec
Posts: 1
Joined: 10 Jun 2024, 18:49

Re: udev should not be triggered again in "change" event

Post by Edusistec » 10 Jun 2024, 19:02

Hello,

I have had the problem you have been discussing and with your ideas I have modified the file: /lib/udev/rules.d/40-usb_modeswitch.rules and now it is like this:

# Works with usb_modeswitch versions >= 2.4.0. Slash before %k parameter
# is for compatibility only. Versions >= 2.5.0 don't need it.
#
ACTION!="add|change", GOTO="modeswitch_rules_end"

# Adds a symlink "gsmmodem[n]" to the lowest ttyUSB port with interrupt
# transfer; checked against a list of known modems, or else no action
KERNEL=="ttyUSB*", ATTRS{bNumConfigurations}=="*", PROGRAM="usb_modeswitch --symlink-name %p %s{idVendor} %s{idProduct} %E{PRODUCT}", SYMLINK+="%c"

SUBSYSTEM!="usb", GOTO="modeswitch_rules_end"
ACTION!="add", GOTO="modeswitch_rules_end"


I was able to get the modem to always be detected.
But now I have another problem, I get these errors.

May 28 08:21:31 IOT-RACK systemd[1]: Started Modem Manager.
May 28 08:21:33 IOT-RACK ModemManager[15575]: opening device...
May 28 08:21:33 IOT-RACK ModemManager[15575]: cannot connect to proxy: Could not connect: Connection refused
May 28 08:21:33 IOT-RACK ModemManager[15575]: spawning new mbim-proxy (try 1)...
May 28 08:21:33 IOT-RACK ModemManager[15575]: [/dev/cdc-wdm0] Read max control message size from descriptors file: 1024
May 28 08:21:34 IOT-RACK ModemManager[15575]: <info> [base-manager] couldn't check support for device '/sys/devices/platform/icssg0-eth': not supported by any plugin
May 28 08:22:03 IOT-RACK ModemManager[15575]: proxy configuration failed: closed
May 28 08:22:03 IOT-RACK ModemManager[15575]: [/dev/cdc-wdm0] channel destroyed
May 28 08:22:03 IOT-RACK ModemManager[15575]: <info> [device /sys/devices/platform/bus@100000/4020000.dwc3/4030000.usb/xhci-hcd.1.auto/usb3/3-1/3-1.2] creating modem with plugin 'huawei' and '2' ports
May 28 08:22:03 IOT-RACK ModemManager[15575]: <warn> [plugin/huawei] could not grab port cdc-wdm0: Cannot add port 'usbmisc/cdc-wdm0', unsupported
May 28 08:22:03 IOT-RACK ModemManager[15575]: <warn> [base-manager] couldn't create modem for device '/sys/devices/platform/bus@100000/4020000.dwc3/4030000.usb/xhci-hcd.1.auto/usb3/3-1/3-1.2': Failed to find p>

I'm not sure if I didn't follow your instructions correctly or if the change didn't quite fix the modem detection problem.

Please could someone give me some help.
Thanks in advance.

Josh
Site Admin
Posts: 6571
Joined: 03 Nov 2007, 00:30

Re: udev should not be triggered again in "change" event

Post by Josh » 11 Jul 2024, 11:56

It looks like this is a problem that's coming up after the mode switch. I don't think usb_modeswitch can make any change there.

What is the modem model? The USB ID?

Post Reply