[MindBender]

I hope you guy can help me out with the troubles I'm experiencing with a D-Link DWM-157 BW, ID 2001:a707 and firmware version 2.0.1EU.

The DWM-157 B1 is already supported, but ID 2001:a707 isn't in /lib/udev/rules.d/40-usb_modeswitch.rules yet. I have tried many configurations in the modeswitch rules and messages I have found on different forums, but to no avail. The DWM-157 is basically a The DWM-156 without an external antenna connector, and its ID is very close to D-Link DWM-156 A7 (2001:a707), but no cigar.

The problem is not that it won't switch mode; It does that with more than one option that I have tried. The problem is that it won't switch mode well. After it has switched, two of the ttyUSB ports confirm Hayes commands with an 'OK', and one seem to work until I start dialing. ATDT (and ATD) commands are replied with a very verbose (NOT) 'ERROR'. I have tried many variations on my vwdial configuration, but that turns out not to be the problem.

After endless trying and error, I installed the device on a Windows VM. I had Windows do the switching, test the dialup and everything worked fine. After that I moved the device - without power-cycled - from the Windows VM to my Linux VM. Linux listed the already switched device and dialup worked like a charm.

So I verbosely listed the device, both after a bad switched and after a good switch and compared the two. These are the differences:


Now the question is: Does anybody know the correct message I need to send to the device in order to get is switched right? Can anybody guide me into capturing this message from Windows switching the device (preferably without the need to order an Ellisys)?

[Image deleted, obsolete]
[Image Caption: D-Link DWM-157 B1 (2001:a707) FW 2.0.1EU usb listing, right switching vs wrong switching]

[LOM]

Now the question is: Does anybody know the correct message I need to send to the device in order to get is switched right? Can anybody guide me into capturing this message from Windows switching the device (preferably without the need to order an Ellisys)?

There is no need for you doing a Windows sniffing of switch message(s), 2001:a707 (switching to 2001:7d02) was added for support in usb_modeswitch 2 years ago so it is instead an update you'll have to do.

[MindBender]

There is no need for you doing a Windows sniffing of switch message(s), 2001:a707 (switching to 2001:7d02) was added for support in usb_modeswitch 2 years ago so it is instead an update you'll have to do.

I should have mentioned: I actually started with a freshly installed libusb-1.0, usb-modeswitch-2.2.1 and usb-modeswitch-data-20150115, below my steps for your review.

Code: Select all

cd ~/src
wget http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-2.2.1.tar.bz2
wget http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-data-20150115.tar.bz2
sudo apt-get install libusb-1.0
tar -xjvf usb-modeswitch-2.2.1.tar.bz2 
tar -xjvf usb-modeswitch-data-20150115.tar.bz2 
rm usb-modeswitch-2.2.1.tar.bz2 
rm usb-modeswitch-data-20150115.tar.bz2 
cd usb-modeswitch-2.2.1/
make
sudo make install
cd ../usb-modeswitch-data-20150115/
make
sudo make install

What's drew my attention first is that usb-modeswitch reports to be version 2.2.0, instead of 2.2.1, but it's in the code like that, so no harm there:

Code: Select all

#define VERSION "2.2.0"

The udev rules did indeed contain default vendorID and productID 2001:a707 after the update, but unfortunately the modem replied 'ERROR' upon Hayes command 'ATDT' (and 'ATD'). What threw me off were the differences in the lsusb dump. Because of these differences I started experimenting with other messages. And when that wasn't fruitful, I decided to post here.

Tonight, because of your reply, I have retraced all my steps on my workstation. The different lsusb -v outputs turn out to be a distraction: They are different because one was run on the Raspberry Pi and the other one on my Workstation. The Pi probably doesn't have CDC MBIM in it's Kernel, hence the difference.

But the problems persists and may even be a bit more mysterious now lsusb -v outputs of the usb_modeswitch switched device and the Windows switched device turn out to be identical. With the Windows switched device I can dial out:

Code: Select all

$ sudo wvdial truphone
--> WvDial: Internet dialer version 1.61
--> Initializing modem.
--> Sending: ATH
ATH
OK
--> Sending: ATE1
ATE1
OK
--> Sending: AT+CGDCONT=1,"IP","truphone.com"
AT+CGDCONT=1,"IP","truphone.com"
OK
--> Modem initialized.
--> Sending: ATDT*99***1#
--> Waiting for carrier.
ATDT*99***1#
CONNECT 21000000
--> Carrier detected.  Starting PPP immediately.
--> Starting pppd at Tue May 26 20:41:56 2015
--> Pid of pppd: 2486
--> Using interface ppp0
--> local  IP address 10.148.14.82
--> remote IP address 10.64.64.64
--> primary   DNS address 10.21.121.84
--> secondary DNS address 10.21.121.85

With the usb_modeswitch switched device I can not:

Code: Select all

$ sudo wvdial truphone
--> WvDial: Internet dialer version 1.61
--> Initializing modem.
--> Sending: ATH
ATH
OK
--> Sending: ATE1
ATE1
OK
--> Sending: AT+CGDCONT=1,"IP","truphone.com"
AT+CGDCONT=1,"IP","truphone.com"
OK
--> Modem initialized.
--> Sending: ATDT*99***1#
--> Waiting for carrier.
ATDT*99***1#
ERROR
OK
--> Invalid dial command.
--> Disconnecting at Tue May 26 20:45:02 2015

[Josh]

I assume that the Windows-switched modem was initialized with additional AT commands.

There is no other logical explanation - unless you are using different ports in those two dial attempts.

Maybe you can sniff out the Windows modem initialization.

[LOM]

I think this is one of those D-Link dongles which starts up in limited functionality mode, study the CFUN AT cmd.

[MindBender]

I assume that the Windows-switched modem was initialized with additional AT commands.
There is no other logical explanation - unless you are using different ports in those two dial attempts.

Yeah, you're right; That's the only possibility left behind.

Maybe you can sniff out the Windows modem initialization.

Pfew, that won't be easy; The timing has to be just right.

I think this is one of those D-Link dongles which starts up in limited functionality mode, study the CFUN AT cmd.

Thanks for the hint. I was already brushing up on my Hayes command set knowledge, but ATI4 didn't produce any useful configuration. It doesn't seem to be a typical D-Link thing though: The DWM-221 I purchased simultaneously works like a charm. But then again, there's probably no reason behind it; Who knows who developed the actual insides and configured the firmware. D-Link is probably just a trader for these things.

If anybody can suggest me a current 3G USB modem that works flawlessly on a Raspberry Pi, preferably not as wide as the DWM-221 so the neighbouring USB connector can still be used, and with an external antenna connector (or footprint for one on the PCB), please let me know! I will need quite a number of these in a data logger project and just buying a couple to test whichs works outweighs the effort and costs of getting a single type to work. A huawei E303 is already on it's way, but your suggestions are far more valuable than my random picks .

Thanks again for the hint: I'll study the suggested command right away! Others must be having the same problem...

Edit:
After your hints, my problem looks remarkably like this one:
http://www.draisberghof.de/usb_modeswit ... f=4&t=2238
I'll try it out tonight, when I'm at home.

[LOM]

Edit:
After your hints, my problem looks remarkably like this one:
http://www.draisberghof.de/usb_modeswit ... f=4&t=2238
I'll try it out tonight, when I'm at home.

Same hardware, both made by Mediatek.

[Josh]

In the Android tools "PPP Widget 1/2", I give the command "AT+CFUN=1" as part of the standard initialization. Some very old modems don't know this command, give back an error but work anyway.

Fairly recent modems know it, and there is no harm in issuing it every time just to be on the safe side.

[LOM]

In the Android tools "PPP Widget 1/2", I give the command "AT+CFUN=1" as part of the standard initialization. Some very old modems don't know this command, give back an error but work anyway.

Fairly recent modems know it, and there is no harm in issuing it every time just to be on the safe side.

There is a problem doing that, some Sierra modems hang when they get the CFUN cmd.
NetworkManager does it the correct way, it checks the CFUN status and doesn't issue the cmd if the dongle already is in full functionality mode.

[Josh]

I oversimplified things a bit, sorry. PPP Widget 2 does it the same way as Network Manager, checking with "AT+CFUN?" first.

[MindBender]

The problem was indeed in the AT+CFUN command. I am now setting it blindly with AT+CFUN=1,0 in /etc/wvdial.conf and that does the job.

To help others facing the same problem, below my /etc/wvdial.conf

Code: Select all

[Dialer Defaults]
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Modem Type = Analog Modem
; Phone = <Target Phone Number>
ISDN = 0
; Username = <Your Login Name>
Init1 = ATZ
; Password = <Your Password>
Modem = /dev/ttyUSB0
Baud = 9600

[Dialer truphone]
Modem = /dev/ttyUSB0
Baud = 21000000
Init1 = ATZ +CFUN=1,0
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP","truphone.com"
Phone = *99***1#
Stupid Mode = 1
Username = ''
Password = ''

I have added +CFUN=1,0 to the Init1 command string. I do know this isn't the way to go, but since I only use 1 type of modem I can safely do that.

One observation: Initially I had added it to the Init2 string and that works fine on my Ubuntu 14.04LTS workstation. On the Raspberry Pi however, that string produces and error. Moving the addition to the Init1 string 'solved' that problem. The modem doesn't seem to have a problem with 8 combined commands, so perhaps it has something to do with buffering.

I'm glad it works now! Thanks for all the help guys!

[Josh]

since I only use 1 type of modem I can safely do that

You are right, of course. If a developer doesn't know which hardware will be used with his system software, he has to consider all possibilities. If there is only one defined setup, all tweaks are legal

By the way, you can scrap the "init2" line alltogether from your configuration. These are old setup commands for analogue fax modems. Entirely obsolete now. I would recommend to use just one init line like this:

Init1=ATE1 +CFUN=1,0

The "E1" ("echo on") is probably useful for logging the whole exchange. Your "Init3" line can fill in as "Init2".

[MindBender]

By the way, you can scrap the "init2" line alltogether from your configuration. These are old setup commands for analogue fax modems. Entirely obsolete now. I would recommend to use just one init line like this:

Init1=ATE1 +CFUN=1,0

The "E1" ("echo on") is probably useful for logging the whole exchange. Your "Init3" line can fill in as "Init2".

Oh, thanks for the hint! Going through all commands to see what they mean was still on my list, but you're making it too easy for me .

And I should be looking this up in the documentation, but perhaps you can easily tell me: How can I get that increabilby useful /dev/gsmmodem[n] symlink? I've been reading the comments in /lib/udev/rules.d/40-usb_modeswitch.rules:

Code: Select all

# 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"

But it's not completely clear what I need to do; Adding , SYMLINK+="%c" behind the line of my modem doesn't seem to do the trick.

[LOM]

I think the gsmmodem symlink generation may be broken in ver 2.2.1 but you don't need it cause you "only use 1 type of modem"
You already know which port is the modem port.

[MindBender]

I think the gsmmodem symlink generation may be broken in ver 2.2.1 but you don't need it cause you "only use 1 type of modem"

And a USB serial port ending up as ttyUSB0 or ttyUSB4...