Huawei E3276 LTE Stick (partial) solution - help needed [solved]

weimaraner

Greetings fellow pfSensers,

after losing some hours of sleep on the E3276 LTE stick, I combined a few tutorials to get the bloody thing to work on my pfSense box.

I used information from the following tutorials:
http://sysmagazine.com/posts/187702/
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=3&t=2161

To get the thing working in the first place, I installed usb_modeswitch

pkg install usb_modeswitch

on draisberghof they described the following to work:

usb_modeswitch -v 12d1 -p 14fe -J -R -W

however, using usbconfig , I found out, that my E3276 uses a different product-id

to identify your product id use```
usbconfig


example output:
ugen0.1: <ohci root="" hub="" ati="">at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen1.1: <ehci root="" hub="" ati="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.1: <ohci root="" hub="" ati="">at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen3.1: <ehci root="" hub="" ati="">at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen4.1: <ohci root="" hub="" ati="">at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen5.1: <ohci root="" hub="" ati="">at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen6.1: <ehci root="" hub="" ati="">at usbus6, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen6.2: <flash card="" readerwriter="" generic="">at usbus6, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)
ugen1.2: <huawei mobile="" huawei="" technology="">at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

use```
usbconfig -d <yourport>dump_device_desc</yourport> 
```to find out your idProduct, in my case```
usbconfig -d 1.2 dump_device_desc

example output:

bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0002
bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0040
idVendor = 0x12d1
idProduct = 0x1f01
bcdDevice = 0x0102
iManufacturer = 0x0002 <huawei technology="">iProduct = 0x0001 <huawei mobile="">iSerialNumber = 0x0000 <no string="">bNumConfigurations = 0x0001

in my case the following command results in a successful modeswitch, and a new USB ethernet device is recognized by the platform:

/usr/local/sbin/usb_modeswitch -v 12d1 -p 1f01 -J -R -W

pfSense can utilize this USB ethernet device (in my case ue0), all you need to do is to configure it as WAN interface and let DHCP assign everything you need - you don't even need PPP for it to work.

So far so good, the blood thing finally works. However, I have trouble persisting the modeswitch.

The sysmagazine article provides some guidance on how to get devd to perform a script upon recognizing the device, unfortunately this is where I am stuck.

I've created the suggested 3G.sh script containing the following:

#!/bin/sh
/usr/local/sbin/usb_modeswitch -v 12d1 -p 1f01 -J -R -W

sleep 12
/usr/local/sbin/usb_modeswitch -v 12d1 -p 1f01 -J -R -W

the script itself works and performs the modeswitch as expected.

In addition I've ammended the```
/etc/devd.conf

attach 10 {
device-name "ugen[0-9]+";
match "vendor" "0x12d1";
match "product" "0x1f01";
action "/usr/local/sbin/3G.sh";
};


Unfortunately unplugging and replugging the stick will not perform the modeswitch, it will remain in USB mass media mode.

The code in devd.conf is ammended at the end of the config file.

Any hints on how to persist the modeswitch?</no></huawei></huawei></huawei></flash></ehci></ohci></ohci></ehci></ohci></ehci></ohci>

Guest

The sierra module use AT commands to switch VID/PID. They use a command structure like this:
AT!UDPID? –--Querys the pid in use
AT!UDPID=? ---Shows available PID to switch to
AT!UDPID=xxxx ---Switches module to PID provided

There is another similar thread on here with Huewei AT command structure PDF Guide.
Find the AT command they use and it will persist.If such a thing exists. Let us know if you find something similar..

Also if comfortable with Linux there are some tricks over there with qmicli and nmcli

There is a fresh Xubuntu beta with all the newest modem tricks for a live boot troubleshooting...

weimaraner

actually right now I don't need to send any AT commands to the modem to work, it will just register as a new ethernet interface, which together with DHCP configuration will just work.

The problem is to run the script performing the modeswitch once the stick is recognized or as an alternative during boot.

Guest

I just glanced at their commands and there is nothing similar. Sierra has their AT!UD commands password protected although that cat is out of the bag…

Also looks like the Linux folks are using usbmodeswitch at boot in a script or udev rule.

AndrewZ

I don't think usbmodeswitch is needed here at all.
Assuming you have 21.X firmware on your modem you can change the so called composition by AT^SETPORT command as I mentioned earlier.
Your composition should be "FF;12,16". For explanation send AT^SETPORT=? to the modem.

Guest

That sounds right..Good Job on that..The AT guide I was looking at does not cover that command.

weimaraner

Andrew, I am not using PPP at all, the stick now is recognized as USB ethernet interface and pfSense (2.2.4) uses it like one of the onboard interfaces.

The whole WAN connection is handled by the embedded system on the stick.

The setup itself works fine with pfSense 2.2.4, I can browse the web with the stick being the only WAN connection on pfSense.

All I need to do is persist it, so the modeswitch is performed during boot.

AndrewZ

@weimaraner:

I am not using PPP at all

That's clear ;) The command I mentioned is used to enable NDIS (network card), not RAS (PPP).

The whole WAN connection is handled by the embedded system on the stick.

Sounds like you're on 22.X firmware and your modem operates in HiLink mode. In this case the modem itself works as a NAT router, so your pfsense box is now behind a NAT or two.

weimaraner

Since I am behind a NAT from the provider anyway (WAN IP on the stick being RFC1918), I don't mind another NAT - all I need is WAN ;)

AndrewZ

@weimaraner
Please confirm you're on 22.X firmware.
In that case you potentially can disable modem's storage capabilities by setting NVRAM items directly.

If you have com port enabled try to read the active composition by sending at^setport?
Then try to read NVRAM by AT^NVRD=50091

weimaraner

actually the chatscripts failed every time I tried any PPP configuration, directly connecting to the devices cuau0 or cuau1 using cu didn't work either.

weimaraner

Firmware is 22.436.09.00.1080

AndrewZ

While it looks technically possible to make it working in HiLink mode, having in mind the time required for all the operations I would recommend to switch from 22.X to 21.X firmware and then use PPP. Potentially this will be slower than NDIS or HiLink but you will get supported and well documented configuration.
With HiLink you will need to flash your modem with modified web gui first, then enable com port from that gui, then access that port from the terminal and modify NVRAM item. No guarantee it will work at the end. Unfortunately I do not have enough time myself now to go from 21 to 22 and test everything.

weimaraner

Well.. actually it works, I can access the Internet through the E3276 on my pfSense with firmware 22 in ethernet (HiLink?) mode.

All I need now is a way to persist the modeswitch (e.g. execute it every time freebsd recognizes the stick). Since I am not really familiar with devd, I was hoping somebody would have a solution for this,

weimaraner

so far I tried executing

/usr/local/sbin/usb_modeswitch -v 12d1 -p 1f01 -J -R -W

via <earlyshellcommand>and an executable script in /usr/local/etc/rc.d

Unfortunately both options execute the modeswitch after the firewall is already started, so pfSense will enter into the interface configuration as ue0 is missing.

Any suggestions to execute the modeswitch prior to pfsense starting?</earlyshellcommand>

weimaraner

Solved, I integrated the 3G.sh script into rc.bootup right before the Interface configuration.

shell_exec('/usr/local/sbin/3G.sh');

dvv06

@weimaraner Спасибо модем Huawei E8372h-153 определяется как ue0 интефейс успешно и это не приводик к переназначению существующих интерфейсов