[Morgano]

Hi I am new here.
Thank you for the efforts with mode switching!

My Modem: Huawei E367 which contain 3 devices: modem + drive with Win&Mac drivers + flash card interface (unpopulated)

System: Mandriva 2010.2 with kernel 2.6.38.8-desktop-nrj.69mib running on Lenovo Thinkpad T61.

Status:
1) Mandriva control center finds the device but tells me Please insert SIM.

2) Modem (yes with SIM card inside...) tested OK on another laptop with XP.
( sidenote: It do NOT work with XP in VirtualBox 4.0.8. Installer worked only when i copied the folder to desktop first. But it fail connect anyways. )

3) Fooled around with usb_modeswitch, upgraded to latest (v 1.1.8 and data) and tried amongst other:

Code: Select all

# usb_modeswitch -c /etc/usb_modeswitch.d/12d1:1446

Looking for target devices ...
 Found devices in target mode or class (1)
Looking for default devices ...
 No devices in default mode or class found. Nothing to do. Bye.

Still not working.

Found in target mode means it already is switched i suppose?

Then i shold go barking at another tree I guess...
Suggestions?
Thanks
/Morgan

[Josh]

Found in target mode means it already is switched i suppose?

Absolutely right. You can check if the auto-switch worked by calling "dmesg" and looking for a line with "disconnect".

Regarding your SIM problem, I have no other advice than to try out some other tools for setting up a connection. The most basic one being "wvdial", but there is also UMTSmon and others.

[Morgano]

Thanks for the info and suggestion.
Will try other tools and report back later.
Now to Midsummer celebrations, one of the most loved weekends in Sweden

[tpalomaki]

Hi,

I have investigated this and related issues on CentOS 6.0,
with kernel 2.6.32-71.29.1.el6.x86_64 on HP Pavilion dv7-3197eo.
With the same 3G USB dongle, E367 (12d1:1446). USB_ModeSwitch is 1.2.0 (latest when posting this).

(Partially Working method, applies only to reboot with the dongle already in switched mode:
- Add 'modprobe usbserial vendor=0x12d1 product=0x1506' to /etc/rc.local, and then booting with the dongle attached.)


Working method (manual):
- Run 'modprobe usbserial vendor=0x12d1 product=0x1506' before or after usb_modeswitch execution, does not matter when.
- Run usb_modeswitch about 2-3 seconds after inserting the dongle to USB slot, before the microSD folder opens (if you have a microSD in there), and before you see 'Nov 18 13:45:38 localhost usb_modeswitch: switching 12d1:1446 (Huawei Technologies: HUAWEI Mobile)' in /var/log/messages.

EDIT: the second method makes the dongle available in Gnome NetworkManager, in the Wireless Broadband section, fully working.. No need to resort to some other programs.


The timing is critical in this for some reason, and this is also the reason the UDEV execution of the usb_modeswitch wont work.. Its executed too late.

You can examine the outputs by trying to manually run usb_modeswitch repeatedly while inserting the 3G dongle, and waiting for the folders and responses to pop up. The response will vary from "nothing to do" to "driver found (freeze)" to "success" to "failure" to "no driver found".





ADDITIONAL INFO:

I'm have been using this command;
usb_modeswitch -v 0x12d1 -p 0x1446 -H -s 5 -c /etc/usb_modeswitch.d/huawei.conf

with the configuration file /etc/usb_modeswitch.d/huawei.conf
(almost the same as in the /usr/share/usb_modeswitch folder, all non-necessary lines removed):
------ clip -----
########################################################
# Huawei, newer modems

;DefaultVendor= 0x12d1
;DefaultProduct=0x1446

#TargetVendor= 0x12d1
#TargetProductList="1001,1406,140b,140c,1412,141b,1433,14ac,1506"

#CheckSuccess=20

MessageEndpoint = 0x01
MessageContent="55534243123456780000000000000011062000000100000000000000000000"
------ clip ------



Cheers,
Tapio

[Josh]

tpalomaki, one question about version 1.2.0:

Did you use the source code from this site or did you install a Fedora/CentOS/Redhat pack?

[tpalomaki]

tpalomaki, one question about version 1.2.0:

Did you use the source code from this site or did you install a Fedora/CentOS/Redhat pack?

Hi Josh,

I did use the latest source package from this site.

After a bit of testing: the trick is to do kernel unbind/bind (echo -n "2-1.1" > /sys/bus/usb/drivers/usb/unbind [ bind ]).
And immediately after that run the modeswitch manually ONCE and have the usbserial loaded with the above parameters.

This now works every time assuming the slow E367 has had the time to turn on, which takes 2-3 seconds after plugging in. Kernel unbind/bind removes the slow reconnect part and allows usb_modeswitch to work.

Note I still have the default UDEV rules.d dispatcher running on the background, but the usb_modeswitch needs to be executed before that one runs. Even with the unbind/bind trick.

-Tapio

[Josh]

O.K., it's better to use the source than a Fedora package - they fiddle around with the setup which potentially breaks things even more.

I see that you may be using a hub (internal or external). In that case I recommend trying the beta version of 1.2.1:
http://www.draisberghof.de/usb_modeswit ... ta.tar.bz2
http://www.draisberghof.de/usb_modeswit ... xx.tar.bz2

I tried to make it more robust when it comes to hubs. Maybe some of your quirks are going away if you use it.

[tpalomaki]

Hi,

Just a quick reply. I'm not using external usb hubs, and this same thing is replicated on two laptops. An old one running AMD x64 and a new one running Intel i7, both CentOS 6 x64...

I will try those packages asap.

Thanks.

[tpalomaki]

Nope, still the same.

Is there any way to capture usb_modeswitch log output while in udev mode? There is nothing in /var/log/usb_modeswitch_1-3:1.0 which could indicate the problem.. So far usb_modeswitch works perfectly if its ran by hand in console after unbind/bind (which can be run by UDEV or in the console)..

I'm running the script on background with &, and it has 15 seconds of sleep, and the storage devices appear before usb_modeswitch runs. But I do remember udev will not continue before the scripts have completed. I assume udev wont release some part of the device.. and/or udev waits for any related background process to complete.. but cannot confirm because of the missing logs.

[Josh]

You do have the tcl package installed, right?

To test run "tclsh". If successful, enter "exit".

[tpalomaki]

Yes I do. Shoot

[Josh]

I'm not sure if I read you correctly - do you get anything in the log or don't you get a log at all?

If you do get a log, try to disable all your custom scripts for a moment, remove the usbserial module (modprobe -r) and then just plug in and see the log after a moment.
If the switch went well according to the log, the bottom lines are crucial. They should say something about the driver.

[tpalomaki]

I do not see the log while udev executes usb_modeswitch.

EDIT: I do see the typical usb attach messages in /var/log/messages, and also:
"usb_modeswitch: switching 12d1:1446" (tries to change)
and
"usb_modeswitch: switched to 12d1:1506" (if successfull)

I do see the log while running it manually.
This is the case with both the original setup provided by you and with the modifications made by me.

PS. I have set EnableLogging=1 in both /etc/usb_modeswitch.conf and /usr/share/usb_modeswitch/12d1:1446

[Josh]

I was confused because you mentioned /var/log/usb_modeswitch_1-3:1.0 (which is the log file to be expected). So there is nothing in that file?

I'm at a loss why the wrapper should work (as the syslog messages indicate) but not produce a log output ...

[tpalomaki]

There are some old stuff in it, but nothing new is written (tail -f <file>).
I'm at loss too, and I have no idea where to get any debugging info..
Well.. at least my scripts [echo "" >> ~/log.txt ] outputs get logged to a file, but redirecting usb_modeswitch in the same manner produces nothing.

EDIT: when run from command-line, then it will push the usb_modeswitch output to the same logfile.
UDEV calling environment should be running the scripts without the command line environment.

Any ideas?