Slate AX and Huawai E3372h - tethering mode not working

Hi there,

I just received my Slate AX and everything is working really well, I got what I hoped for.

The only issue is that I cannot successfully use the Huawei LTE dongle (E3372h-320) I just bought for my slate.
The dongle is working fine when connected to a computer, it’s in Hilink mode and the computer got an IP address from the dongle (192.168.8.x).

If I connect the dongle to the slate, the tethering option appears and shows the dongle as eth3 (iOS).
When I press connect, nothing is happening, I cannot get any connection.

If I go to the luci interface, I can see the eth3 interface appearing in the tether zone, but there’s no address assigned from DHCP nor any traffic sent or receive.

The LAN subnet of the slate has been changed from the default 192.168.8.0/24, so it’s not in conflict with the Huawei dongle.

Tethering is working fine if I plug my phone with a USB connection, but I would obviously want to use a dongle for that.

It seems that this Huawei dongle should be working in tethering mode without too many troubles, do you have any idea why that wouldn’t be ok with the slate?

Many thanks for your help.

Do you have system log?

Hello,

This is what we can see in the log when trying to connect tethering:

Mon Jul 11 14:50:32 2022 kern.info kernel: [  275.244474] usb 1-1: new high-speed USB device number 2 using xhci-hcd
Mon Jul 11 14:50:32 2022 kern.info kernel: [  275.386768] usb-storage 1-1:1.0: USB Mass Storage device detected
Mon Jul 11 14:50:32 2022 kern.info kernel: [  275.387061] scsi host0: usb-storage 1-1:1.0
Mon Jul 11 14:50:32 2022 kern.info kernel: [  275.467919] usb 1-1: USB disconnect, device number 2
Mon Jul 11 14:50:33 2022 kern.info kernel: [  275.914476] usb 1-1: new high-speed USB device number 3 using xhci-hcd
Mon Jul 11 14:50:33 2022 kern.info kernel: [  276.125660] cdc_ether 1-1:1.0 eth3: register 'cdc_ether' at usb-xhci-hcd.0.auto-1, CDC Ethernet Device, 00:1e:10:1f:00:00
Mon Jul 11 14:50:36 2022 daemon.err mqtt[5889]: url = https://gslb-eu.goodcloud.xyz/gslb/getbucket?deviceType=1&mac=xxxxxxxx&sn=xxxxxxxx&ddns=xxxxxxxx&timestamp=1657543831&sign=7af8a1243f20ba9236d395f61d681c39
Mon Jul 11 14:50:36 2022 daemon.err mqtt[5889]: utils_NLB failed!
Mon Jul 11 14:50:44 2022 daemon.err mqtt[5889]: url = https://gslb-eu.goodcloud.xyz/gslb/getbucket?deviceType=1&mac=xxxxxxxx&sn=xxxxxxxx&ddns=xxxxxxxx&timestamp=1657543839&sign=4f8d01bf422e28044db35afa364ec0bc
Mon Jul 11 14:50:44 2022 daemon.err mqtt[5889]: utils_NLB failed!
Mon Jul 11 14:50:53 2022 daemon.err mqtt[5889]: url = https://gslb-eu.goodcloud.xyz/gslb/getbucket?deviceType=1&mac=xxxxxxxx&sn=xxxxxxxx&ddns=xxxxxxxx&timestamp=1657543848&sign=818546d2f9c03584dace85b96dd69d9f
Mon Jul 11 14:50:53 2022 daemon.err mqtt[5889]: utils_NLB failed!
Mon Jul 11 14:51:01 2022 daemon.err mqtt[5889]: url = https://gslb-eu.goodcloud.xyz/gslb/getbucket?deviceType=1&mac=xxxxxxxx&sn=xxxxxxxx&ddns=xxxxxxxx&timestamp=1657543856&sign=a117b0c1025f52a83a85cfafe2dfb20e
Mon Jul 11 14:51:01 2022 daemon.err mqtt[5889]: utils_NLB failed!
Mon Jul 11 14:51:05 2022 daemon.notice netifd: Interface 'tethering' is enabled
Mon Jul 11 14:51:05 2022 daemon.notice netifd: Network device 'eth3' link is up
Mon Jul 11 14:51:05 2022 daemon.notice netifd: Interface 'tethering' has link connectivity
Mon Jul 11 14:51:05 2022 daemon.notice netifd: Interface 'tethering' is setting up now
Mon Jul 11 14:51:05 2022 kern.info kernel: [  308.159173] IPv6: ADDRCONF(NETDEV_UP): eth3: link is not ready
Mon Jul 11 14:51:05 2022 daemon.notice netifd: tethering (16066): udhcpc: started, v1.33.1
Mon Jul 11 14:51:05 2022 daemon.notice netifd: tethering (16066): udhcpc: sending discover
Mon Jul 11 14:51:07 2022 daemon.info avahi-daemon[3704]: Joining mDNS multicast group on interface eth3.IPv6 with address fe80::21e:10ff:fe1f:0.
Mon Jul 11 14:51:07 2022 daemon.info avahi-daemon[3704]: New relevant interface eth3.IPv6 for mDNS.
Mon Jul 11 14:51:07 2022 daemon.info avahi-daemon[3704]: Registering new address record for fe80::21e:10ff:fe1f:0 on eth3.*.
Mon Jul 11 14:51:08 2022 daemon.notice netifd: tethering (16066): udhcpc: sending discover
Mon Jul 11 14:51:09 2022 daemon.err mqtt[5889]: url = https://gslb-eu.goodcloud.xyz/gslb/getbucket?deviceType=1&mac=xxxxxxxx&sn=xxxxxxxx&ddns=xxxxxxxx&timestamp=1657543864&sign=458f7e9178725eee9075ae67b95a9f31
Mon Jul 11 14:51:09 2022 daemon.err mqtt[5889]: utils_NLB failed!
Mon Jul 11 14:51:11 2022 daemon.notice netifd: tethering (16066): udhcpc: sending discover
Mon Jul 11 14:51:17 2022 daemon.err mqtt[5889]: url = https://gslb-eu.goodcloud.xyz/gslb/getbucket?

And no traffic at all on the eth3 interface:

image

I also tried to disable IPv6 and forced the link to be active on the tethering interface, but no more success:

Mon Jul 11 19:11:46 2022 daemon.info dnsmasq[20464]: read /etc/hosts - 4 addresses
Mon Jul 11 19:11:46 2022 daemon.info dnsmasq[20464]: read /tmp/hosts/dhcp.cfg01411c - 7 addresses
Mon Jul 11 19:11:46 2022 daemon.info dnsmasq-dhcp[20464]: read /etc/ethers - 0 addresses
Mon Jul 11 19:11:48 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:11:49 2022 daemon.err mqtt[21592]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:11:49 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:11:50 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:11:50 2022 daemon.info dnsmasq[20464]: read /etc/hosts - 4 addresses
Mon Jul 11 19:11:50 2022 daemon.info dnsmasq[20464]: read /tmp/hosts/dhcp.cfg01411c - 7 addresses
Mon Jul 11 19:11:50 2022 daemon.info dnsmasq-dhcp[20464]: read /etc/ethers - 0 addresses
Mon Jul 11 19:11:50 2022 daemon.info samba4-server: io_uring module found, enabling VFS io_uring. (also needs Kernel 5.4+ Support)
Mon Jul 11 19:11:51 2022 daemon.err mqtt[22003]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:11:51 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:11:52 2022 daemon.info samba4-server: io_uring module found, enabling VFS io_uring. (also needs Kernel 5.4+ Support)
Mon Jul 11 19:11:52 2022 daemon.info dnsmasq[20464]: read /etc/hosts - 4 addresses
Mon Jul 11 19:11:52 2022 daemon.info dnsmasq[20464]: read /tmp/hosts/dhcp.cfg01411c - 7 addresses
Mon Jul 11 19:11:52 2022 daemon.info dnsmasq-dhcp[20464]: read /etc/ethers - 0 addresses
Mon Jul 11 19:11:54 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:11:55 2022 daemon.err mqtt[23240]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:11:55 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:11:55 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:11:57 2022 daemon.err mqtt[23552]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:11:57 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:07 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:07 2022 daemon.notice netifd: Interface 'tethering' is setting up now
Mon Jul 11 19:13:07 2022 daemon.notice netifd: tethering (27055): udhcpc: started, v1.33.1
Mon Jul 11 19:13:07 2022 daemon.notice netifd: tethering (27055): udhcpc: sending discover
Mon Jul 11 19:13:08 2022 daemon.err mqtt[27093]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:13:08 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:08 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:10 2022 daemon.err mqtt[27288]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:13:10 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:10 2022 daemon.notice netifd: tethering (27055): udhcpc: sending discover
Mon Jul 11 19:13:13 2022 daemon.notice netifd: tethering (27055): udhcpc: sending discover
Mon Jul 11 19:13:15 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:16 2022 daemon.err mqtt[27793]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:13:16 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:17 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:18 2022 daemon.err mqtt[28023]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:13:18 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:27 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:28 2022 daemon.err mqtt[28728]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:13:28 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:29 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:30 2022 daemon.err mqtt[28933]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:13:30 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:44 2022 daemon.notice netifd: tethering (27055): udhcpc: received SIGTERM
Mon Jul 11 19:13:44 2022 daemon.notice netifd: tethering (27055): udhcpc: entering released state
Mon Jul 11 19:13:44 2022 daemon.notice netifd: tethering (27055): Command failed: Permission denied
Mon Jul 11 19:13:44 2022 daemon.notice netifd: Interface 'tethering' is now down
Mon Jul 11 19:13:44 2022 daemon.notice netifd: Interface 'tethering' is disabled
Mon Jul 11 19:13:44 2022 user.notice mwan3[29602]: Execute ifdown event on interface tethering (unknown)
Mon Jul 11 19:13:46 2022 daemon.notice netifd: Interface 'tethering' is enabled
Mon Jul 11 19:13:51 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:52 2022 daemon.err mqtt[30563]: output json = ["cloud-batch-manage", "bind_info", {}]
Mon Jul 11 19:13:52 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf
Mon Jul 11 19:13:53 2022 daemon.err mqtt[5889]: get mac = 94:83:c4:1c:51:bf

The logs shows that the router cannot get DHCP address from the modem.

I have a E3276 and it works OK with Slate AX.

Are you able to try change settings in the Huawei modem and check if there is anything related to dhcp and lan etc.? Maybe mac address lock or something.

No, there’s no option at all for the DHCP server or any LAN parameter.

I’ve discovered a strange behaviour:

  • If I connect the dongle to the slate without a SIM card in it, I can activate the tethering option in the slate and I get an IP address from the DHCP server on the dongle. I can then reach the WebUI (192.168.8.1) from the stick.
  • If I insert the SIM card while the slate is connected to the dongle, the SIM card is not recognized, so I cannot activate the LTE connection.
  • If I unplug the stick and plug it back again in the slate, same behaviour as previously, I see some LTE activity on the stick, but I cannot get any IP address for the slate.

Really weird :roll_eyes:

Is there any settings e.g. force the dongle works on 4G, not 3G and 2G?

No, there’s no setting for that.

I tried with the auto-connection to cellular network deactivated, but that didn’t change anything.

I’m gonna return the stick to the shop and buy an E3276, hoping it will be more plug&play.

Pls ask them for hilink version.

Hello,

I returned the E3372h and bought a 3276 instead.
I can confirm that it is now working with that dongle.

Is there any plan to make a device like the Slate AX with 4G/5G integrated?
That would become the perfect gear for me.

2 Likes

Good suggestions. Thanks!

1 Like

Dear Pinus, dear GL.iNet-team

I have exactly the same situation like you. I bought a E3372h-320 because of some users who had good experiences with the stick. But with my AXT1800 it shows the same problems:

  • AXT1800 and E3372h-320 are in different networks (192.168.6.x / 192.168.8.x)
  • without a sim card, the web interface can be reached via the slate
  • with a sim card, the slate receives an IP, but no tethering is possible
  • with a sim card, I cannot reach the web interface of the E3372 but the E3372h-320 indicates via the blue LED that it is connected to the internet via lte
  • the stick works without any problems on a laptop

The E3276 does not have these problems? Are there sub-versions of this, as with the E3372, that I should be aware of?

Thank you very much!
SHC

Pls open your own thread than opening a 2-year old post.

What is the IP that you got?

Hi,
yes, I know that this is a very old thread. But since I had exactly the same symptoms, I thought it might be useful in this case. Sorry if the thought was wrong.

I have now tested further and have come to a point where it suddenly worked for a moment, but I don't know why. I...

  • restarted the router several times
  • disconnected and reconnected the LTE stick several times
  • did the whole thing with and without the SIM card inserted
    => This did not change anything. No working tethering-connection available

=> If no SIM-card is inserted I have access to the menu of the lte-stick
=> If a SIM-card is inserted I have no access to the menu of the lte-stick (HiLink-Stick)

Finally, I inserted the SIM into the running LTE stick. This did bring up a message telling me to restart (disconnect) the stick, but strangely enough, a connection to the router was established afterwards and I can now use the internet via tethering.

But, only for a 20-30 minutes. Then it told me again:

IP of AXT1800: 192.168.6.1
IP of E3372: 192.168.8.1
IP of AXT1800 via E3372: 192.168.8.109

Unfortunately, I don't really understand why this is the case. Sometimes it is connecting to the internet and I can use the internet as normal. And then it shows the above mentioned error message. I'll therefore continue testing and see if I can figure out why. I'll be sure to report back here. Which log would be helpful for you?

I think this is the part of the log you need, right?

Tue Sep  3 15:59:02 2024 daemon.notice netifd: tethering (16253): udhcpc: received SIGTERM
Tue Sep  3 15:59:02 2024 daemon.notice netifd: tethering (16253): udhcpc: entering released state
Tue Sep  3 15:59:02 2024 daemon.notice netifd: tethering (16253): Command failed: Permission denied
Tue Sep  3 15:59:02 2024 daemon.notice netifd: Interface 'tethering' is now down
Tue Sep  3 15:59:02 2024 daemon.info avahi-daemon[4013]: Interface eth3.IPv6 no longer relevant for mDNS.
Tue Sep  3 15:59:02 2024 daemon.info avahi-daemon[4013]: Leaving mDNS multicast group on interface eth3.IPv6 with address fe80::21e:10ff:fe1f:0.
Tue Sep  3 15:59:02 2024 daemon.notice netifd: Interface 'tethering' is disabled
Tue Sep  3 15:59:02 2024 daemon.info avahi-daemon[4013]: Withdrawing address record for fe80::21e:10ff:fe1f:0 on eth3.
Tue Sep  3 15:59:02 2024 daemon.notice netifd: Interface 'tethering' has link connectivity loss
Tue Sep  3 15:59:02 2024 user.notice firewall: Reloading firewall due to ifdown of tethering ()
Tue Sep  3 15:59:04 2024 user.notice kmwan: config json str={ "op": 3, "data": { "cells": [ "tethering" ] } }
Tue Sep  3 15:59:11 2024 daemon.notice netifd: Interface 'tethering' is enabled
Tue Sep  3 15:59:11 2024 daemon.notice netifd: Network device 'eth3' link is up
Tue Sep  3 15:59:11 2024 daemon.notice netifd: Interface 'tethering' has link connectivity
Tue Sep  3 15:59:11 2024 daemon.notice netifd: Interface 'tethering' is setting up now
Tue Sep  3 15:59:11 2024 kern.err kernel: [ 1410.135165] cdc_ether 1-1:1.0 eth3: kevent 12 may have been dropped
Tue Sep  3 15:59:11 2024 kern.err kernel: [ 1410.135200] cdc_ether 1-1:1.0 eth3: kevent 12 may have been dropped
Tue Sep  3 15:59:11 2024 daemon.notice netifd: tethering (17565): udhcpc: started, v1.33.2
Tue Sep  3 15:59:11 2024 daemon.notice netifd: tethering (17565): udhcpc: sending discover
Tue Sep  3 15:59:12 2024 daemon.info avahi-daemon[4013]: Joining mDNS multicast group on interface eth3.IPv6 with address fe80::21e:10ff:fe1f:0.
Tue Sep  3 15:59:12 2024 daemon.info avahi-daemon[4013]: New relevant interface eth3.IPv6 for mDNS.
Tue Sep  3 15:59:12 2024 daemon.info avahi-daemon[4013]: Registering new address record for fe80::21e:10ff:fe1f:0 on eth3.*.
Tue Sep  3 15:59:14 2024 daemon.notice netifd: tethering (17565): udhcpc: sending discover
Tue Sep  3 15:59:17 2024 daemon.notice netifd: tethering (17565): udhcpc: sending discover

I have carried out various restarts and tests in all possible combinations today.

E3372h-320

  • without sim card there is a connection to the router and I can also reach the HiLink menu via 192.168.8.1
  • with sim card the E3372h-320 dials into the 4G network (blue LED lights up), but the Internet is only sometimes and then only briefly forwarded to the router. The error message shown above is usually displayed.

E3372h-153 (different firmware)

  • without sim card there is a connection to the router (see above)
  • with sim card there is no connection to the router at all, not even an IP is distributed via DHCP. However, the stick dials in via 4G.

Now the question is whether I should test an E3276? At the moment I can only find it without HiLink, as a pure modem. Would that work better?


Additional information:
It seems that the connection works when the router and modem have cooled down or have not been switched on for a while. However, this is only an observation so far. After a few minutes, the connection is lost again and cannot be re-established even if the router or modem are restarted.
In the meantime, I suspected that it was due to the power supply and replaced the power supply unit - but this was obviously not the cause, as the behavior described above was repeated.


Here is mentioned a very similar problem:

I have found a workaround for the moment:

To be able to use an “E3372h-320” with the “GL-AXT1800”, any USB hub must be connected between the router and the stick. The hub can be active or passive, and USB2.0 or USB3.0 is not important. However, the data obviously has to pass through another USB chip for it to work securely. The tandem has now been running for 16 hours without any problems.

Without a hub in between, the connection is only established once for a few minutes, then breaks off and cannot be re-established.

Is this a problem caused by the stick or is there something that can be changed in the firmware? I have read a lot here and in the case of a similar problem with another router model, the problem was solved by the firmware. I use Firmware 4.6.2.

In the next few days I will also be testing a “ZTE MF79U” and will report back.

2 Likes

Hello,
I accidentally received a ZTE MF79N (instead of “U”), but according to the manufacturer, the sticks only differ in which provider they are/were manufactured for. Technically there is supposedly no difference.
However, I have the same “problem” with this stick. I can use it with a USB 2.0 or USB3.0 hub and it works as a tethering stick. Unfortunately, it is not recognized when connected directly to the AXT1800.

1 Like