Flint firmware 4.1.0 release6 is out

Upgraded to 4.1.0 release6 but IPTV with igmproxy+VLC doesn’t work with flint. Occasionally there is some stuttering sound and sometimes even a still image. With Archer C7 and ZyXEL NBG6617 + OpenWRT 22.03.2 I can actually watch TV. After two years ipq6xxx support is still a nightmare. I love my Creta AR750 and I have high expectations for my two Brume2 MT2500 that were handed over to FedEx today.

Can you try this firmware again? Thank.

Hi Jerry, Last time I upgraded a GliNet device with firmware from the forum, it bricked my Flint and I had to acquire a new one. I would like to fix the issue but would prefer to remain in the official beta code land.

We need help to verify if it is compatible with Huawei E3372. If you can help that is great!

But if you don’t want to risk, that is fine.

The appropriate process for loading the firmware appears not to be the “UPGRADE” feature on the UI. Firmware uploads successfully then… RED WARNING “Testing the firmware with sysupgrade failed”. Point me to the loafing process and I will give it a go.

This guy did it in a Slate AXT1800 … GL-AXT1800 with e3372h in stick mode. No comgt-ncm package - #16 by JerryZhao … I’m waiting for my E3372 and for my wife to bring my Router back … in the meantime flash away :slight_smile:

openwrt-ipq807x-glinet_axt1800-squashfs-sysupgrade loaded on a SLATE AX successfully enables tethering with a Wuawei 3372h. It WORKS!!!.

I am writing this via an “UPGRADED” SLATE that only has access to the internet via a Wuawei 3372h. If you could port this functionality to FLINT and SLATE AX firmware (and BLUME while you are at it)

1 Like

Awesome; is your E3372h in “Hilink” mode (which I read somewhere has worked before in plain Tethering (vs Modem) mode) or have you flashed it to “Stick Mode” (which I understand uses NCM; whatever that is).

btw love the phonetic usage of the W in Wuawei. The real device does start with an H though; unless you’re purposely trying to circumvent some web-crawlers …

The Tethering interface was set as a backup / failover to a primary ethernet link. I am looking to have the flint work a little like the cheap boxes Optus use in Australia to provide NBN access. The NBN presents an ethernet connection in the home and the Optus boxes have a SIM slot for mobile failover. NBN is down frequently and so am I unless I can get the flint to failover to something like a 3372.

The 3372 is “routing” and presents the 192.168.8.0/24 network to the Slate. I have not played with flashing it

The LOG for the FLINT (still running 4.1b6) is shown below in a more readable format.
The interface comes up but then reports “The interface is connected, but the Internet can’t be accessed with IPv4 protocol” and does not appear to route packets.
:
Tue Nov 29 18:31:17 2022 daemon.notice netifd: Interface ‘tethering’ is enabled
Tue Nov 29 18:31:17 2022 daemon.notice netifd: Network device ‘eth5’ link is up
Tue Nov 29 18:31:17 2022 daemon.notice netifd: Interface ‘tethering’ has link connectivity
Tue Nov 29 18:31:17 2022 daemon.notice netifd: Interface ‘tethering’ is setting up now
Tue Nov 29 18:31:17 2022 kern.err kernel: [55858.931034] cdc_ether 1-1:1.0 eth5: kevent 12 may have been dropped
Tue Nov 29 18:31:17 2022 kern.err kernel: [55858.931076] cdc_ether 1-1:1.0 eth5: kevent 12 may have been dropped
Tue Nov 29 18:31:17 2022 daemon.notice netifd: tethering (24604): udhcpc: started, v1.33.2
Tue Nov 29 18:31:17 2022 daemon.notice netifd: tethering (24604): udhcpc: sending discover
Tue Nov 29 18:31:17 2022 daemon.notice netifd: tethering (24604): udhcpc: sending select for 192.168.8.147
Tue Nov 29 18:31:17 2022 daemon.notice netifd: tethering (24604): udhcpc: lease of 192.168.8.147 obtained, lease time 86400
Tue Nov 29 18:31:17 2022 daemon.info avahi-daemon[3901]: Joining mDNS multicast group on interface eth5.IPv4 with address 192.168.8.147.
Tue Nov 29 18:31:17 2022 daemon.info avahi-daemon[3901]: New relevant interface eth5.IPv4 for mDNS.
Tue Nov 29 18:31:17 2022 daemon.info avahi-daemon[3901]: Registering new address record for 192.168.8.147 on eth5.IPv4.
Tue Nov 29 18:31:17 2022 daemon.notice netifd: Interface ‘tethering’ is now up
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: reading /tmp/resolv.conf.d/resolv.conf.auto
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using only locally-known addresses for domain test
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using only locally-known addresses for domain onion
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using only locally-known addresses for domain localhost
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using only locally-known addresses for domain local
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using only locally-known addresses for domain invalid
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using only locally-known addresses for domain bind
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using only locally-known addresses for domain lan
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using nameserver 198.142.152.164#53
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using nameserver 198.142.152.165#53
Tue Nov 29 18:31:17 2022 daemon.info dnsmasq[7062]: using nameserver 192.168.8.1#53
Tue Nov 29 18:31:17 2022 user.notice mwan3[24624]: Execute ifup event on interface tethering (eth5)
Tue Nov 29 18:31:18 2022 user.notice mwan3[24624]: Starting tracker on interface tethering (eth5)
Tue Nov 29 18:31:18 2022 daemon.info avahi-daemon[3901]: Joining mDNS multicast group on interface eth5.IPv6 with address fe80::21e:10ff:fe1f:0.
Tue Nov 29 18:31:18 2022 daemon.info avahi-daemon[3901]: New relevant interface eth5.IPv6 for mDNS.
Tue Nov 29 18:31:18 2022 daemon.info avahi-daemon[3901]: Registering new address record for fe80::21e:10ff:fe1f:0 on eth5.*.
Tue Nov 29 18:31:20 2022 user.info mwan3rtmon[3816]: Detect rtchange event.
Tue Nov 29 18:31:20 2022 user.notice firewall: Reloading firewall due to ifup of tethering (eth5)

Do you mean hilink (tethering) mode?

Problem with WireGuard - Unable to connect to server as client, while the same config works on other devices.
Tue Nov 29 12:06:00 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Tue Nov 29 12:06:05 2022 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=REKEY-TIMEOUT SHLVL=2 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/

Let me know how your testing went - theres another user in forum with exact issue after firmware update.

The 3372 is as shipped and has worked on earlier v3 software in “Tethering” mode. The device presents IP Network 192.168.8.0/24 with a default gateway of 192.168.8.1 to the FLINT. 4.1Bx does not work. Old v3 code did work.

Just remind me you want before and after speed test on Flint 3.x to 4.x right?

correct - as couple users are having same issue.

I noticed some older devices (2.4ghz compatible only) can’t connect to the Flint after the update. However, openning a seperate 2.4ghz Guest channel allows the devices to be connected successfully. I think there might be some bug with the dual 2.4ghz/5ghz auto switching in the latest firmware.
EDIT: I found the issue. Changing the Wi-Fi security of the 2.4Ghz from WPA2/WPA3 to WPA2 only solved this issue for me.

1 Like

still no wifi fix thats mad that slow 5g speed

If you look at firmware 3.214, under wireless in LuCi one sees that AX band is actually not there. So I am thinking that GL.iNET was using a prototype AC build and when it rolled to openwrt 21.02 that supported AX it broke.

If you go into LuCi and change the wireless 5g interface from AX to AC the speed should come back.

A number of other brands running openwrt builds are also affected.

Just waiting on a AX fix