[aldi7talk]

You really should be more accurate. Every character counts when writing programs.

The path to usb_modeswitch is /usr/sbin/usb_modeswitch. Check again in that folder.
What you are calling in your script is itself annother little script, a 'wrapper' to start usb_modeswitch (the binary program).

I strongly recommend using a decent file manager to quickly have a look at programs and scripts (so you see which is which).
I'm using Midnight Commander which has largely the same functions (and key commands) as Total Commander for Windows.

It's a terminal program, but if you enlarge your terminal window you'll get a neat interactive surface. I'm using the Fixedsys TTF font with all of my terminals (in Windows too), which delivers excellent readability. YMMV.

Thank you, I should be more accurate, that's correct. I overlooked sbin. In the meanwhile I found it. I changed the code, but it didn't work. The result of the second command (lbusb | grep 7e19) should be known before the third command is launched. Otherwise it won't work. I found this out by copying the three commands at once in a terminal. I have to do it rule by rule. Could this be the problem with the script? Is it possible to stop the script after the second command until the result is known and then go further with the third command?

[Josh]

It's not clear what you need that "lsusb" command for ...

This script is started by udev, from a rule that triggers only if a device is attached where the ID matches. That is the whole point of these "rules".

So once the script is started, you already know that the correct device is connected and discovered by the system.

The order of the remaining two commands is not important. You can load the serial driver before doing the mode switch - but remember to run "modprobe" with the full path as well. Check the result of "which modprobe".

[aldi7talk]

It's not clear what you need that "lsusb" command for ...

This script is started by udev, from a rule that triggers only if a device is attached where the ID matches. That is the whole point of these "rules".

So once the script is started, you already know that the correct device is connected and discovered by the system.

The order of the remaining two commands is not important. You can load the serial driver before doing the mode switch - but remember to run "modprobe" with the full path as well. Check the result of "which modprobe".

Thank you Josh, it works!

"which modprobe" gave me /sbin/modprobe. I added this to the code and copied the dlink_script in the rules.d directory. I changed the path to the script in 40-usb_modeswitch.rules. I restarted the computer and after 70 seconds the screen where I have to fill in my sim card pin code appeared. Fill in the pin code and...it works. Thank you very much!

[jeanhuveneers]

HI LOM ,

FortiGate is working fine with 2 line.

Cent OS is also working.

I've also trying to get it working on a Fortigate. But look like i'm missing something becaese it is not working for me.
I added the 4 lines to modem_list.conf file. It's detected but not responding to AT commanda (read time out).

Can you please provide your configuration?

Regards,

Jean

I've finally got it (DLink DWM-221) working on a Fortigate 40C and 30D (FortiOS 5.2.4) with following lines of config:
config system 3g-modem custom
edit 1
set vendor "MobileConnect"
set model "MobileConnect"
set vendor-id 2001
set product-id a401
set init-string "555342435b000000000000000001061e000000000000000000000000000000"
next
edit 2
set vendor "Dlink"
set model "221"
set vendor-id 2001
set product-id a401
set class-id 08
set init-string "555342435c000000000000000001061b000000010000000000000000000000"
next
edit 3
set vendor "dlink"
set model "221"
set vendor-id 2001
set product-id a401
set class-id 08
set init-string "555342435d000000000000000001061b000000020000000000000000000000"
next
edit 4
set vendor "Dlink"
set model "DWM-221"
set vendor-id 2001
set product-id 7e19
next
end
config system modem
set wireless-port 3
end

Regards,

Jean

[dan]

Just in the case someone's curious how the switching is done on Windows by vendor supplied binaries.

It's not switched by a device driver but user level application itself (WirelessModem.exe). It use neither vendor id nor device id to identify device. It just enumerate all logical drives using following alghoritm:

For every logical drive from A:\ to Z:\ do {

• drive type != 5 (DRIVE_CDROM) => skip drive
• (TotalNumberOfClusters <= 0) => skip drive
• no ?:\InstallPackageD file found => skip drive
• consider ?:\InstallPackageD to be .ini file. Fetch value of key "STRING" in [Magic] section. Is it "su7993cka91nedc70xlampdqax862318x" ? => switch drive

}

Switch drive: the mciSendCommand(...,MCI_SET,MCI_SET_DOOR_OPEN,0) is called to do it.

It results (on Windows 7) in 55 53 42 43 10 60 D3 0B 00 00 00 00 00 01 06 1B 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 (StopUnit)


Observed on Wireless.exe version 2.0.1.1819 (19.8.2014).

[toto1234]

If you use procmon to look at what WirelessModem.exe is doing, it just sends a DeviceIoControl(IOCTL_STORAGE_EJECT_MEDIA) to the CD-ROM drive.

It turns out you can do the same on Linux - eject /dev/sr1 works fine for me.

[thomasschaefer]

Thank you all for solving the switch-problem.

For me "eject" only did work once.

Recent usb_modeswitch (Opensuse/Tumbleweed) did work without problems.

The device works with qmi.

https://lists.freedesktop.org/archives/ ... 01572.html


Thomas