[thomasschaefer]

Hi,

The Stick huawei E398 (Telekom Speedstick LTE /Vodafone K5005) has the ID
12d1 1505

Under windows the device is switched to 12d1 1506.

With the commands

usb_modeswitch -v 12d1 -p 1505 -V 12d1 -P 1506 -M "55534243123456780000000000000011062000000100000000000000000000"

modprobe option vendor=0x12d1 product=0x1506

I get the same result.

After that I can access the /dev/ttyUSB0 with minicom and put in some AT-commands.

But dial-in with the scripts as done with older gsm-modems does not work.


My first question:

How to automate the steps? Are they right?

What about smart dealing with the cd-rom and SD-card?

Is pppd with /dev/ttyUSB0 "state of the art"? I ask this, because Windows has two different drivers - a modem and a network-adapter, like ethernet-LAN.

If I can do some contribution by testing or similar, let me know.

Regards,
Thomas

[Josh]

I'm not really well informed about the driver situation for non-ppp interfaces. I know there is an effort for Samsung LTE sticks, but I fear that modem chipset makers may introduce proprietary protocols and leave the ground of generally usable serial ports.

The case of the Samsung device may be exemplary though: the connection is initiated by AT commands on a serial interface, but the data stream is then built up over a different interface.
See this for details:
https://github.com/mkotsbak/Samsung-GT- ... nux-driver

Huawei is providing a customised Linux driver which seems to operate as a mix of ppp and network. Engineers of this corporation contacted me and urged the usage of the "MessageContent" that you are issuing. They assured me that the first interface (ttyUSB0) will work as before for creating ppp connections.
This is probably not true for LTE technology though.

It would be interesting to see what your device will do if you feed it the old "MessageContent". To see the differences, use "lsusb -v -d <vendor:product>".
Here is the string used originally:
"55534243123456780000000000000011060000000000000000000000000000"

If there are indeed differences in the resulting mode, try again connecting through ttyUSB0.

[thomasschaefer]

Huawei is providing a customised Linux driver which seems to operate as a mix of ppp and network. Engineers of this corporation contacted me and urged the usage of the "MessageContent" that you are issuing.

Do you know where they are providing this driver? I asked also t-mobile, they have no linux-software.

The M-code was taken from your website

They assured me that the first interface (ttyUSB0) will work as before for creating ppp connections.
This is probably not true for LTE technology though.

The problem is, there is nothing to see. The pppd sends "LCP ConfReq..." 26 times then the stick makes a reset.

It would be interesting to see what your device will do if you feed it the old "MessageContent". To see the differences, use "lsusb -v -d <vendor:product>".
Here is the string used originally:
"55534243123456780000000000000011060000000000000000000000000000"

I tried both messages. They differ:

Code: Select all

2c2
< Bus 001 Device 005: ID 12d1:140c Huawei Technologies Co., Ltd. 
---
> Bus 001 Device 007: ID 12d1:1506 Huawei Technologies Co., Ltd. 
12c12
<   idProduct          0x140c 
---
>   idProduct          0x1506 
14,15c14,15
<   iManufacturer           3 Huawei Technologies
<   iProduct                2 HUAWEI Mobile
---
>   iManufacturer           4 Huawei Technologies
>   iProduct                3 HUAWEI Mobile
21,22c21,22
<     wTotalLength          161
<     bNumInterfaces          6
---
>     wTotalLength          193
>     bNumInterfaces          7
24c24
<     iConfiguration          1 Huawei Configuration
---
>     iConfiguration          2 Huawei Configuration
35,36c35,36
<       bInterfaceSubClass    255 Vendor Specific Subclass
<       bInterfaceProtocol    255 Vendor Specific Protocol
---
>       bInterfaceSubClass      1 
>       bInterfaceProtocol      1 
73c73
<       bNumEndpoints           3
---
>       bNumEndpoints           2
75,76c75,76
<       bInterfaceSubClass    255 Vendor Specific Subclass
<       bInterfaceProtocol    255 Vendor Specific Protocol
---
>       bInterfaceSubClass      1 
>       bInterfaceProtocol      2 
82,91d81
<         bmAttributes            3
<           Transfer Type            Interrupt
<           Synch Type               None
<           Usage Type               Data
<         wMaxPacketSize     0x0040  1x 64 bytes
<         bInterval               5
<       Endpoint Descriptor:
<         bLength                 7
<         bDescriptorType         5
<         bEndpointAddress     0x84  EP 4 IN
115,116c105,106
<       bInterfaceSubClass    255 Vendor Specific Subclass
<       bInterfaceProtocol    255 Vendor Specific Protocol
---
>       bInterfaceSubClass      1 
>       bInterfaceProtocol      3 
121c111
<         bEndpointAddress     0x85  EP 5 IN
---
>         bEndpointAddress     0x84  EP 4 IN
142a133,155
>       bNumEndpoints           1
>       bInterfaceClass       255 Vendor Specific Class
>       bInterfaceSubClass      1 
>       bInterfaceProtocol      9 
>       iInterface              0 
>       ** UNRECOGNIZED:  05 24 00 10 01
>       ** UNRECOGNIZED:  0d 24 0f 01 00 00 00 00 08 06 01 00 00
>       ** UNRECOGNIZED:  05 24 06 03 04
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x85  EP 5 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               5
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        4
>       bAlternateSetting       0
145,146c158,159
<       bInterfaceSubClass    255 Vendor Specific Subclass
<       bInterfaceProtocol    255 Vendor Specific Protocol
---
>       bInterfaceSubClass      1 
>       bInterfaceProtocol      8 
171c184
<       bInterfaceNumber        4
---
>       bInterfaceNumber        5
201c214
<       bInterfaceNumber        5
---
>       bInterfaceNumber        6

If there are indeed differences in the resulting mode, try again connecting through ttyUSB0.

Dial-in via /dev/ttyUSB0 still fails.

Regards,
Thomas

[Josh]

If I were you I would look at the dial-in setup again.

I googled and found hints that the device is in fact working with the serial port:

http://www.spinics.net/lists/linux-usb/msg49372.html
http://www.spinics.net/lists/linux-usb/msg42161.html

The first link has a patch for "option" and some information about the device.

Here is one about possible connection problems:

http://www.spinics.net/lists/linux-ppp/msg01118.html

[thomasschaefer]

If I were you I would look at the dial-in setup again.

I googled and found hints that the device is in fact working with the serial port:

If found these hints too. I compared the at-commands from windows with my ones.

Of course. Under Windows the modem-driver also works. With linux I can see the progress of the script until the pppd takes over the connection.

Here is one about possible connection problems:

http://www.spinics.net/lists/linux-ppp/msg01118.html

He is some steps farther. My first LCP request stays unanswered.

I will continue to search.

Despite /dev/ttyUSB0 and ppp is working sooner or later also for me.

The idea of a (emulated) networkdevice (with dhcp and Router Advertisements/ dhcp6) sounds not bad to me.
Why the trouble with fake telefone numbers(always *99#), apn and some other ugly things. The mobile-ISP configures the device/SIM and the user makes plug & play.
Independent of that, there should be a generic configuration/monitoring-interface, may be via at-commands.



Regards,
Thomas

[thomasschaefer]

It would be interesting to see what your device will do if you feed it the old "MessageContent". To see the differences, use "lsusb -v -d <vendor:product>".
Here is the string used originally:
"55534243123456780000000000000011060000000000000000000000000000"

If there are indeed differences in the resulting mode, try again connecting through ttyUSB0.

After some attempts - I found a working combination. As already mentioned the message above results in four serial devices. /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2 and /dev/ttyUSB3.

0 and 3 answer to at-commands.
1 and 2 don't.

But, only /dev/ttyUSB3 also works together wit pppd.

Thanks a lot for all the hints in this forum!

For the moment it is ok.

The next topic will be IPv6.
(end of the year2011 t-mobile enables IPv6, the stick should work with it)

Regards,

Thomas Schäfer

[Josh]

O.K., you collected some important knowledge here. Correct me if I'm wrong:

1. The modem works via standard serial ppp

2. For switching, the "old" variant for Huawei is required. The "new" variant will not make the device usable.

3. Only port ttyUSB3 (interface 4) is able to build up a connection

If you confirm that, I'll add some documentation about this thing to the usb_modeswitch main page.

[thomasschaefer]

Your summary is accurately fitting to my experience.

Additionally: I did the latest tests with kernel 3.0.0 (rc6,rc7 and final), so the option-driver worked without patches (also loaded automatically)

Regards,
Thomas

[thomasschaefer]

The Deutsche Telekom has published a driver for linux

http://www.t-mobile.de/downloads/neu/li ... .00.00.zip

The zip-file has to be renamed from .zip to .tar.gz or .tgz


Within the next days I will give it a chance.

Regards,
Thomas Schäfer

[thomasschaefer]

http://www.t-mobile.de/downloads/neu/li ... .00.00.zip

seems to be not complete. There is a kernel-module "hw_cdc_driver.ko" (only for a small range of kernel-versions), some rules for udev and some binary-only helper programs.

But I am not able to use it for a working connection.

All I can see, is:
ifconfig
eth0 Link encap:Ethernet Hardware Adresse 00:1E:10:1F:00:01
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

ip link
8: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:1e:10:1f:00:01 brd ff:ff:ff:ff:ff:ff

The device will be switched from
idVendor=12d1, idProduct=1505
to
idVendor=12d1, idProduct=1506

has now three usb-serial-devices:

/dev/ttyUSB0
/dev/ttyUSB1
/dev/ttyUSB2
/dev/ttyUSB_utps_diag
/dev/ttyUSB_utps_modem
/dev/ttyUSB_utps_pcui


Sorry, that the thread becomes slowly off topic.


Regards,
Thomas Schäfer

[Josh]

I think this is the known Linux package which may be contained on some of the newer Huawei sticks. There is a mode switching tool included ("HWActivator") which seems to do some additional stuff apart from switching (I just had annother look into the binary - interesting).

The target device is the same as with the "new" Huawei command from usb_modeswitch.

The point is that the port named "ttyUSB_utps_modem" is supposed to work with a normal ppp connection. You might want to try again, even if it is just renamed from ttyUSB by an udev rule.

[thomasschaefer]

The point is that the port named "ttyUSB_utps_modem" is supposed to work with a normal ppp connection. You might want to try again, even if it is just renamed from ttyUSB by an udev rule.

That is not the problem. Your usb_modeswitch (with the "old" message) is reliable. It works well. But I am also interested in the "ethernet"-emulation solution. The windows-version prefers the networkcard-driver instead of the classic modem-driver.
There must be reasons for that.

Yesterday I have seen the interface eth0 with Huawei-MAC-address, but I was not able to use it.

The stick doesn't support ipv6 via ppp in the modem-mode with vodafone-test-simcards. Other built-in-modules have IPv6 on Windows, but also only without modem-mode as "LAN".

By the way it is a wonder, that the driver compiles. (changing charsets, crlf-endings...)

I will ask the seller again. They promised IPv6-support to the end of the year.

Regards,
Thomas Schäfer

[Josh]

I think you got it right: the IPv6 migration may be behind the network emulation thing. Speed is probably not a problem yet with USB 2.0.

I myself am looking forward to test the IP6 environment that T-Online intends to set up soon.

Regarding the Huawei driver: my contacts with the engineer (Ma Rui) did not enforce the impression that this maker is interested in much engagement within the Linux community. Their only interest seemed to be to port their Mobile Partner frontend to Linux very quickly.

[thomasschaefer]

Their only interest seemed to be to port their Mobile Partner frontend to Linux very quickly.

That must be the thing what I am missing in the package. There is the switch tool, the hw_cdc_driver, but no script/program using it.

T-online is a different place. www, dns, and mx work already with ipv6. But no progress since 8.June 2011.

Regards,
Thomas

[thomasschaefer]

Yesterday I found a LTE-Cell and my script stopped working.

Does anybody know, if there are AT-commands to force the stick to use 3G-networks/umts?

Regards,

Thomas Sch?fer