OpenWrt Forum Archive

Topic: Can't connect Huawei E3276 in UMTS mode.

The content of this topic has been archived on 17 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi. I followed this guide: http://wiki.openwrt.org/doc/recipes/3gdongle .

Router: TP-Link TL-WDR3600
Modem: Huawei E3276
Firmware: OpenWrt Attitude Adjustment 12.09

I installed packages listed in the guide.

I didn't have 'generic converter now attached' in dmesg, and no /dev/ttyUSB* devices.

In /sys/kernel/debug/usb/devices:

P:  Vendor=12d1 ProdID=1506 Rev= 1.02
S:  Manufacturer=HUAWEI Technology

I inserted to /etc/rc.local:

echo '12d1 1506 ff' > /sys/bus/usb-serial/drivers/option1/new_id

Now I have /dev/ttyUSB0  and /dev/ttyUSB1 .

I didn't have 'CD-ROM' message in dmesg, neither /dev/sg0 device, so I skipped the step usb-modeswitch.

In /etc/config/network I can't add option "option pincode 1234", because my ISP didn't give it to me. My SIM card doesn't ask for PIN.

/etc/config/network:

config interface 'wan'
        option ifname  ppp0
        option device  /dev/ttyUSB0
        option apn     internet
        option service umts
        option proto   3g
        option username gdata
        option password gdata
May 25 22:24:37 OpenWrt local2.info chat[7137]: abort on (BUSY)
May 25 22:24:37 OpenWrt local2.info chat[7137]: abort on (NO CARRIER)
May 25 22:24:37 OpenWrt local2.info chat[7137]: abort on (ERROR)
May 25 22:24:37 OpenWrt local2.info chat[7137]: report (CONNECT)
May 25 22:24:37 OpenWrt local2.info chat[7137]: timeout set to 10 seconds
May 25 22:24:37 OpenWrt local2.info chat[7137]: send (AT&F^M)
May 25 22:24:37 OpenWrt local2.info chat[7137]: expect (OK)
May 25 22:24:47 OpenWrt local2.info chat[7137]: alarm
May 25 22:24:47 OpenWrt local2.info chat[7137]: Failed
May 25 22:24:47 OpenWrt daemon.err pppd[7133]: Connect script failed
May 25 22:24:48 OpenWrt daemon.info pppd[7133]: Exit.

Also, `gcom info` fails:

root@OpenWrt:/etc/usb_modeswitch.d# gcom info -d /dev/ttyUSB0
##### Wireless WAN Modem Configuration #####
Product text:
====

====
Manufacturer:           IMEI and Serial Number: comgt 22:28:36 -> -- Error Report --
comgt 22:28:36 -> ---->                       ^
comgt 22:28:36 -> Error @776, line 45, String is shorter than second argument. (7)

root@OpenWrt:/etc/usb_modeswitch.d# gcom info -d /dev/ttyUSB1
##### Wireless WAN Modem Configuration #####
Product text:
====
comgt 22:28:47 -> -- Error Report --
comgt 22:28:47 -> ---->                 ^
comgt 22:28:47 -> Error @187, line 10, Could not write to COM device. (1)

Huawei E3276 does not support PPP, so you cannot use the 3g-protocol with it. Instead, it uses the ncm-protocol, which is not yet supported in OpenWrt. See, e.g., http://patchwork.openwrt.org/patch/5049/.

What do you mean? When I plug it in windows, it has options to connect to 2g, 3g and 4g

I mean that the protocol PPP over UMTS (which is abbreviated as 3g in OpenWrt) is not supported in that modem.

Hi all,

  When you say that "ncm-protocol is not yet supported in OpenWrt", what do you mean by that?

  Will "ncm-protocol" probably be include in the Barrier Breaker since it's in the queue for it? That is what "patchwork.openwrt.org" is used for?

   If so, how can I contribute to make it faster to include ncm-protocol in OpenWRT? I have one Huawei E3276 and would like to see it working.

Patchwork is a repository of all patches submitted to OpenWrt by external developers. It is up to the internal developers to decide which patches to accept and which to reject. The patch I referred to above needs some changes and additional polishing before it can be accepted. I'd also like to see NCM-modems supported, so I'm planning to do the necessary work in the near future, but unfortunately right now I don't have hardware to test it on.

I have the hardware and I am disposed to make any tests ...

  Just tell me how I can help you and I'll do it, ok?

Followed this little guide http://forum.ubuntu.ru/index.php?topic= … msg1778537 (russian)
And now I'm posting this via the modem.

- Run this command: AT^SETPORT="A1,A2;10,12,13,A2" (permanently turns off CD-ROM)
(this makes the device unusable on windows. To revert: AT^SETPORT="A1,A2;12,16,A1,A2" )
- replug
- still have to echo "12d1 1506" > /sys/bus/usb-serial/drivers/option1/new_id

difference: now I have 3 ttyUSB devices instead of one.

- just in case, changed phone number to *99# in /etc/chatscripts/3g.chat

connected.

config interface 'wan_3g'
    option proto '3g'
    option device '/dev/ttyUSB0'
    option service 'umts'
    option apn 'internet'
    option username 'gdata'
    option password 'gdata'

(Last edited by basinilya on 27 May 2014, 21:58)

Hi,

I have configured an OpenWrt following this link: https://sites.google.com/site/variousop … wei-e3267.

It almost worked. The only think that I had to do was that I had to run and "ifconfig wwan0 up".

After the ifconfig, my router had established the 4G connection.

Now I'm trying to understand why the interface is not being "up" automatically.

Any help would be appreciated.

I suspect that the DHCP script distributed with that package is slightly out-of-date.

Can you try my version of NCM support:
- Remove the ncm-packages you installed from the link above.
- Make sure that 'comgt' is still installed.
- Download http://ltl.tkk.fi/~malaakso/misc/runcommand.gcom to /etc/gcom
- Download http://ltl.tkk.fi/~malaakso/misc/ncm.sh to /lib/netifd/proto (edit: and use chmod to make it executable)

You can use the same config as with the NCM support above.

If you have problems, show the output of 'logread', and I'll try to fix it.

(Last edited by snk on 15 Jun 2014, 06:57)

ronaldoafonso wrote:

I have configured an OpenWrt following this link: https://sites.google.com/site/variousop … wei-e3267.

Tried that. My router reboots. I thought it was a power issue, but a hub with external power does not help.

Sat Jun 14 12:36:42 2014 daemon.notice netifd: Interface 'mobile' is setting up now
Sat Jun 14 12:36:44 2014 user.notice root: Detected huawei E3276. Using driver huawei_e3276.
Sat Jun 14 12:36:45 2014 daemon.notice netifd: mobile (2014): Dongle initialization complete.
Sat Jun 14 12:36:46 2014 daemon.notice netifd: mobile (2014): WWAN mode set to 'lte'
Sat Jun 14 12:36:48 2014 daemon.notice netifd: mobile (2014): WWAN connection established.
Sat Jun 14 12:37:08 2014 kern.info kernel: [  360.670000] IPv6: ADDRCONF(NETDEV_UP): wwan0: link is not ready
Sat Jun 14 12:37:08 2014 kern.info kernel: [  360.680000] cdc_ncm: wwan0: 150 mbit/s downlink 150 mbit/s uplink
Sat Jun 14 12:37:08 2014 kern.info kernel: [  360.680000] cdc_ncm: wwan0: network connection: connected
Sat Jun 14 12:37:08 2014 kern.info kernel: [  360.690000] IPv6: ADDRCONF(NETDEV_CHANGE): wwan0: link becomes ready
Sat Jun 14 12:37:08 2014 daemon.notice netifd: Interface 'mobile' is now up

I think then comes some sort of a kernel panic, but how to check it?

I'll try to reproduce on x86 vbox

If you guys could try my version of NCM support above, and help me get it working perfectly, I could hopefully get it upstreamed like QMI recently.

I'm trying yours. But it's not called! When I do `ifup`, it should be called like this:

./ncm.sh ncm setup mobile {"proto":"ncm","ifname":"wwan0","auto":false,"device":"\/dev\/ttyUSB0","mode":"lte","apn":"internet","authtype":"none","delay":"20","ifname":["wwan0"]}

but nothing happens. I know it, because I added at the beginning of this file:

printf "'%s' " "$0" "$@" | logger -t durak

(Last edited by basinilya on 14 Jun 2014, 19:51)

BTW, I just used SerialMon on Windows to sniff the AT commands used by Megafon (a fork of Mobilepartner). Surprisingly, no "NDISUP". And the windows DHCP client is not used - the ip is assigned statically.

(Last edited by basinilya on 14 Jun 2014, 20:42)

basinilya wrote:

I'm trying yours. But it's not called! When I do `ifup`, it should be called like this:

./ncm.sh ncm setup mobile {"proto":"ncm","ifname":"wwan0","auto":false,"device":"\/dev\/ttyUSB0","mode":"lte","apn":"internet","authtype":"none","delay":"20","ifname":["wwan0"]}

but nothing happens. I know it, because I added at the beginning of this file:

printf "'%s' " "$0" "$@" | logger -t durak

Do you see wwan0 created by cdc_ncm in dmesg? Also verify that /lib/netifd/proto/ncm.sh is executable.

BTW, I just used SerialMon on Windows to sniff the AT commands used by Megafon (a fork of Mobilepartner). Surprisingly, no "NDISUP". And the windows DHCP client is not used - the ip is assigned statically.

DHCP is not mandatory, but the firmware of E3276 supports it as well. Missing NDISUP is strange, though.

snk wrote:

Do you see wwan0 created by cdc_ncm in dmesg? Also verify that /lib/netifd/proto/ncm.sh is executable.

wwan0 exists. For example, after `ifdown` /dev/ttyUSB0 becomes unusable by comgt and I can manually do `ifconfig wwan0 up` to re-enable it.

ncm.sh is executable. It's called once at boot:

'./ncm.sh' '' 'dump'

I tried with the following config

network.wan4g=interface
network.wan4g.device=/dev/ttyUSB0
network.wan4g.pincode=0000
network.wan4g.apn=internet
network.wan4g.proto=ncm
network.wan4g.ifname=wwan0

but using a dongle which doesn't support NCM (unfortunately I don't have any of those right now), and I'll get immediately after plugging in the dongle and wwan0 appearing

daemon.notice netifd: Interface 'wan4g' is enabled
daemon.notice netifd: Network device 'wwan0' link is up
daemon.notice netifd: Interface 'wan4g' has link connectivity
daemon.notice netifd: Interface 'wan4g' is setting up now
daemon.err ncm[2113]: Device is not supported.

So at least it is run in my case.

snk, will ncm.sh be called if you unplug the dongle? I guess the network manager thinks wwan0 is bad and this is why it doesn't call the script.

logread -f &
ifup mobile
Sun Jun 15 06:34:27 2014 daemon.notice netifd: Interface 'mobile' is enabled

The missing message is: daemon.notice netifd: Interface 'mobile' has link connectivity

(Last edited by basinilya on 15 Jun 2014, 07:35)

basinilya wrote:

snk, will ncm.sh be called if you unplug the dongle?

Yes:

daemon.notice netifd: Network device 'wwan0' link is down
daemon.notice netifd: Interface 'wan4g' has link connectivity loss
daemon.info ncm[2273]: Stopping network
daemon.info ncm[2273]: Device is not supported.
daemon.notice netifd: Interface 'wan4g' is now down
daemon.notice netifd: Interface 'wan4g' is disabled
basinilya wrote:

I guess the network manager thinks wwan0 is bad and this is why it doesn't call the script.

logread -f &
ifup mobile
Sun Jun 15 06:34:27 2014 daemon.notice netifd: Interface 'mobile' is enabled

The missing message is: daemon.notice netifd: Interface 'mobile' has link connectivity

It could be that E3276 only reports link connectivity once everything has been set up properly. Kind of a chicken-egg problem it seems. Maybe it needs to be triggered on appearance of ttyUSB0 like regular (PPP) 3G-dongles.

(Last edited by snk on 15 Jun 2014, 08:51)

ncm.sh from here is called, although it does requre additional `ifconfig wwan0 up`.

snk: I think netifd doesn't like the reply of your version of ncm.sh, when it calls 'dump'.
Maybe it's because I'm using yesterday's trunk. I can share my virtualbox image so you can test it. Will you?

snk wrote:

Can you try
http://ltl.tkk.fi/~malaakso/misc/ncm.sh to /lib/netifd/proto and
http://ltl.tkk.fi/~malaakso/misc/30-3g to /etc/hotplug.d/tty

This should bring ncm interfaces up regardless of wwan0 link status.

Mon Jun 16 15:19:52 2014 daemon.notice netifd: Interface 'mobile' is setting up now
Mon Jun 16 15:19:52 2014 user.notice durak: './ncm.sh' 'ncm' 'setup' 'mobile' '{"proto":"ncm","ifname":"wwan0","auto":false,"device":"\/dev\/ttyUSB0","apn":"internet","delay":"5","ifname":["wwan0"]}'
Mon Jun 16 15:19:52 2014 user.notice durak: './ncm.sh' 'ncm' 'setup' 'mobile' '{"proto":"ncm","ifname":"wwan0","auto":false,"device":"\/dev\/ttyUSB0","apn":"internet","delay":"5","ifname":["wwan0"]}'
Mon Jun 16 15:20:15 2014 daemon.notice netifd: mobile (2348): Timeout running AT-command
Mon Jun 16 15:20:15 2014 daemon.err ncm[2348]: Failed to initialize modem

The discussion might have continued from here.