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

  • 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:

    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```

    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)
    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 script containing the following:

    /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```

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

    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>

  • 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...

  • 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.

  • 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.

  • 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.

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

  • 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.

  • @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.

  • 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  ;)

  • @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

  • 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.

  • Firmware is 22.436.09.00.1080

  • 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.

  • 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,

  • 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>

  • Solved,  I integrated the script into rc.bootup right before the Interface configuration.


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

Log in to reply