Ok, I ended up modifying /usr/sbin/usb_modeswitch_dispatcher, because changing redirects in /lib/dev/usb_modeswitch had no effect.
And I noticed it takes 20 seconds to show anything in /var/log/usb_modeswitch_1:3.1.0, and all the output is dropped in one moment.. So I cancel the no-output statement.
Anyways, I replaced the usb_modeswitch calling line "set report [ <xxxxxxxxx> 2>@ /dev/null ]" with <xxxxxxxxx> >> /root/usblog2.txt and got the following in /root/usblog2.txt:
------ clip -----
Looking for target devices ...
No devices in target mode or class found
Looking for default devices ...
Found devices in default mode, class or configuration (1)
Accessing device 042 on bus 001 ...
Skipping the check for the current configuration
Using first interface: 0x00
Using endpoints 0x01 (out) and 0x81 (in)
USB description data (for identification)
-------------------------
Manufacturer: Huawei Technologies
Product: HUAWEI Mobile
Serial No.: not provided
-------------------------
Looking for active driver ...
No driver found. Either detached before or never attached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
Sending the message returned error -110. Trying to continue
Resetting response endpoint 0x81
Resetting message endpoint 0x01
Checking for mode switch (max. 20 times, once per second) ...
Searching for target devices ...
......
Searching for target devices ...
No new devices in target mode or class found
Mode switch has failed. Bye.
fail:
------ clip -----
After executing:
echo -n "1-3" >> /sys/bus/usb/drivers/unbind
echo -n "1-3" >> /sys/bus/usb/drivers/bind
I get the PIN pad and this in the "active driver section":
------- clip ------
Looking for active driver ...
OK, driver found ("usb-storage")
OK, driver "usb-storage" detached
OK, message succesfully sent
Resetting response endpoint 0x81
Resetting message endpoint 0x01
Device is gone, skipping any further commands
------- clip -------
(and Found & Succeeded).
Btw, there is 4 /lib/udev/usb_modeswitch calls and 2 /usr/sbin/usb_modeswitch_dispatcher calls after it tries to send the switch message.
So, the basic issue is, the usb driver cannot load before udev call has completed, for some reason.
Changing 40-usb_modeswitch.rules to 60-usb_modeswitch.rules, and running "udevadm control --reload-rules" had no effect, still cannot find the driver.
Running usb_modeswitch manually after this does not work! Only by running unbind & bind gets it working. Then usb_modeswitch finds the driver all by itself with udev, without even manually calling it! I hope this helps to pinpoint the issue.
And I noticed it takes 20 seconds to show anything in /var/log/usb_modeswitch_1:3.1.0, and all the output is dropped in one moment.. So I cancel the no-output statement.
Anyways, I replaced the usb_modeswitch calling line "set report [ <xxxxxxxxx> 2>@ /dev/null ]" with <xxxxxxxxx> >> /root/usblog2.txt and got the following in /root/usblog2.txt:
------ clip -----
Looking for target devices ...
No devices in target mode or class found
Looking for default devices ...
Found devices in default mode, class or configuration (1)
Accessing device 042 on bus 001 ...
Skipping the check for the current configuration
Using first interface: 0x00
Using endpoints 0x01 (out) and 0x81 (in)
USB description data (for identification)
-------------------------
Manufacturer: Huawei Technologies
Product: HUAWEI Mobile
Serial No.: not provided
-------------------------
Looking for active driver ...
No driver found. Either detached before or never attached
Setting up communication with interface 0
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
Sending the message returned error -110. Trying to continue
Resetting response endpoint 0x81
Resetting message endpoint 0x01
Checking for mode switch (max. 20 times, once per second) ...
Searching for target devices ...
......
Searching for target devices ...
No new devices in target mode or class found
Mode switch has failed. Bye.
fail:
------ clip -----
After executing:
echo -n "1-3" >> /sys/bus/usb/drivers/unbind
echo -n "1-3" >> /sys/bus/usb/drivers/bind
I get the PIN pad and this in the "active driver section":
------- clip ------
Looking for active driver ...
OK, driver found ("usb-storage")
OK, driver "usb-storage" detached
OK, message succesfully sent
Resetting response endpoint 0x81
Resetting message endpoint 0x01
Device is gone, skipping any further commands
------- clip -------
(and Found & Succeeded).
Btw, there is 4 /lib/udev/usb_modeswitch calls and 2 /usr/sbin/usb_modeswitch_dispatcher calls after it tries to send the switch message.
So, the basic issue is, the usb driver cannot load before udev call has completed, for some reason.
Changing 40-usb_modeswitch.rules to 60-usb_modeswitch.rules, and running "udevadm control --reload-rules" had no effect, still cannot find the driver.
Running usb_modeswitch manually after this does not work! Only by running unbind & bind gets it working. Then usb_modeswitch finds the driver all by itself with udev, without even manually calling it! I hope this helps to pinpoint the issue.
If you get the actual log output in /var/log, there is no more need for all that redirection fiddling. The report that you collected separately will be contained in the log. The long delay is caused by the failed success check which takes max. 20 seconds if you don't set a different value in the config file. Try "CheckSuccess=10" if you don't want to wait so long.
Regarding the report itself, there are at least two conspicious issues:
First, there is no driver active when usb_modeswitch checks the device initially. The "usb-storage" driver should already have bound. Some devices need this to complete the mode switching afterwards.
If your "usb-storage" module is present and known to work, there may be a timing issue.
Second, the bulk transfer with the switching command is not transmitted correctly. It gets a timeout error (110). This can have countless causes, from missing initialization to buggy firmware.
The next thing to try is a remedy for potential timing issues. Try to add the "WaitBefore" parameter to the config file. This has helped with other quirky devices before. A wait of 4-5 seconds should be enough for a first test. usb_modeswitch will give the device time to settle before it does anything serious.
Regarding the report itself, there are at least two conspicious issues:
First, there is no driver active when usb_modeswitch checks the device initially. The "usb-storage" driver should already have bound. Some devices need this to complete the mode switching afterwards.
If your "usb-storage" module is present and known to work, there may be a timing issue.
Second, the bulk transfer with the switching command is not transmitted correctly. It gets a timeout error (110). This can have countless causes, from missing initialization to buggy firmware.
The next thing to try is a remedy for potential timing issues. Try to add the "WaitBefore" parameter to the config file. This has helped with other quirky devices before. A wait of 4-5 seconds should be enough for a first test. usb_modeswitch will give the device time to settle before it does anything serious.
I did try WaitBefore 2 weeks ago, and no success.
Now I got it working for udev with another wrapper script around /lib/udev/usb_modeswitch script, which does exactly what I described earlier (unbind, bind, delegating to usb_modeswitch).
What I have been experiencing now:
1) I tried to reboot with the wrapper script and it locked for 180sec.. because udevadm --settle says the script did not terminate.. queue contains usb/1-3 device... so I need to look into that in a moment. Seems to be an internal issue of the script, because commenting out usb_modeswitch did not solve it.
2) Also during the boot tests, usb_modeswitch was able to do the switch, but said: "Could not reset endpoint (probably harmless): -71" and the PIN entry did not popup, and the modem did not work.This was fixed with some random reboots, replugging of E367 and plugging/unlocking the SIM in another Windows machine.
EDIT: does anyone have any idea why I get two PIN entry windows for the E367? the other is for SIM, and presumably the other is for E367 unlock.. but the device is already unlocked..
Now I got it working for udev with another wrapper script around /lib/udev/usb_modeswitch script, which does exactly what I described earlier (unbind, bind, delegating to usb_modeswitch).
What I have been experiencing now:
1) I tried to reboot with the wrapper script and it locked for 180sec.. because udevadm --settle says the script did not terminate.. queue contains usb/1-3 device... so I need to look into that in a moment. Seems to be an internal issue of the script, because commenting out usb_modeswitch did not solve it.
2) Also during the boot tests, usb_modeswitch was able to do the switch, but said: "Could not reset endpoint (probably harmless): -71" and the PIN entry did not popup, and the modem did not work.This was fixed with some random reboots, replugging of E367 and plugging/unlocking the SIM in another Windows machine.
EDIT: does anyone have any idea why I get two PIN entry windows for the E367? the other is for SIM, and presumably the other is for E367 unlock.. but the device is already unlocked..