bruce
132
Both R&D and I have tested (different USB drive), and USB 2.0 has not been reproduced. 
mkdr
133
I have a USB 3.0 hub connected to the Brume 2 USB 3.0 port, this one:
https://www.amazon.de/dp/B0CD1BHXPZ
And on it a Sandisk USB 3.0 flash drive 32GB
and a USB 2.0 printer (which is off though all the time). I also installed the package p910nd as print server, not sure if that has anything to do with it. The issue was introduced with 4.7.0 on Brume 2 and also seems to exist in 4.7.4.
I never changed the setting to usb 2.0 though. For me the problem is with the default setting.
bruce
134
Hi,
I don't have a USB Hub here, but directly connect the USB drive to USB, and it will be automatically mounted after router restarted. It has not been reproduced.
Under factory settings, please try to remove the USB Hub and directly connect to the Sandisk drive to the Brume USB port. Will the restart automatically mount?
oly
135
OpenWrt 24.10.0-rc5, r28304-6dacba30a7
-----------------------------------------------------
root@GL-MT6000:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 54.5M 54.5M 0 100% /rom
tmpfs 491.5M 3.4M 488.2M 1% /tmp
/dev/loop0 7.2G 202.3M 7.0G 3% /overlay
overlayfs:/overlay 7.2G 202.3M 7.0G 3% /
tmpfs 512.0K 4.0K 508.0K 1% /dev
/dev/sda1 14.3G 14.0K 13.5G 0% /tmp/mountd/disk1_part1
root@GL-MT6000:~# date
Wed Apr 30 17:06:04 EEST 2025
root@GL-MT6000:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.69 xhci-hcd xHCI Host Controller
Bus 001 Device 002: ID 058f:6387 Generic Mass Storage
Bus 002 Device 001: ID 1d6b:0003 Linux 6.6.69 xhci-hcd xHCI Host Controller
root@GL-MT6000:~#
Renato
136
Does removing the USB Hub and connecting the USB Flash Drive directly to Brume change this behaviour?
Alex84
137
GL-MT6000, after upgrade to 4.7.5-op24, keeping the settings - The =gl.inet UI (nginx) is not accessible, returning a "Connection_refused" error; Luci UI (uhttpd) works as it should.
Looking at the logs, it seems that nginx fails to start with the following:
2025/05/03 11:59:24 [emerg] 20197#0: dlopen() "/usr/lib/nginx/modules/ngx_http_lua_module.so" failed (Error loading shared library /usr/lib/nginx/modules/ngx_http_lua_module.so: No such file or directory) in /etc/nginx/module.d/ngx_http_lua.module:1
The module file is present.
Uboot-flashing with same version results in a working UI; After reinstalling the needed packages using opkg, and restoring needed settings - the problem returns.
That exact setup worked perfectly on 4.7.0-op24.
Where is the regression? What am I doing wrong?
List of manually installed packages:
luci-lib-base
ddns-scripts-services
luci-lib-ip
luci-lua-runtime
bark-router-client
ucode-mod-lua
ddns-scripts
luci-app-ddns
luci-ssl-openssl
socat
ddns-scripts-cloudflare
acme-acmesh
luci-i18n-ddns-zh-cn
nginx-mod-lua
luci-i18n-acme-zh-cn
luci-app-samba4
luci-lib-nixio
liblucihttp-lua
luci-lib-jsonc
acme-common
acme-acmesh-dnsapi
wget-ssl
acme
luci-app-acme
Any help would be greatly appreciated 
mkdr
138
That is not an option. It is a normal usb 3.0 hub, which I also need because I have multiple usb devices on the Brume. I just rebooted my Brume 2 yesterday again a few times, and now today I notice the usb device is again missing
Removing the flash drive and plugging in back, and it is back.
oly
139
@GL.iNet Staff I don't know if it's a bug or if in this OP24 version the GUI interface does not automatically appear in the web browser page when we first time configuring the router without having to access the page manually, the second observation is that the page (Select Network ModeExit Network Guide) does not open automatically after the GUI interface is active in the first configuration phase, from what I see in all versions of Stable, Beta Firmware, these work
Hi, thank you for your feedback, we have confirmed these two issues and will fix them in the next version
2 Likes
I see that the date of this firmware has been updated to 2025-5-19.
Version number is still 4.7.5-op24
What are the changes from version dated 2025-4-18?
1 Like
oly
142
The latest version brings many improvements and bug fixes, well done!
1 Like
Excellent!
Installed - all good so far.
Version number does not seem to reflect the significance of the changes.
Base OP change should update the version number...
1 Like
Hello,
If I may, what for are you using an USB disk ? (probably an USB Key)
Ha great !
I was about to install a vanillia OpenWRT 
I just flash this release 4.7.5-op24 (2025-5-19) over the 4.7.7 (2025-04-15) (op21) version without erasing settings. I wanted to see if it worked fine and if not, I'll reflash without keeping settings this time.
But for now, all I can see is that flashing this 4.7.5-op24, I was told that this was an older version than 4.7.7 (2025-04-15) (op21) I had, OK? it seem logical since the version number is less.
I just had to reboot the Flint2 in order to get internet access with the Wifi, but for this, it may be my mac in which I changed the DNS for the test.
FOr now, every thing seems to be working. I tested the wireguard server. Soon I'll test the OpenVPN Server. I can still connect in SSH with my SSH Key.
What should I test in order to see if there is some casualty by keeping settings ?
And, I may know the answer, but is it safe to upgrade all those packet with opkg?
root@GL-MT6000:~# opkg list-upgradable
lua-eco-mqtt - 3.7.0-r2 - 3.9.0-r1
lua-eco-ssl - 3.7.0-r2 - 3.9.0-r1
lua-eco-nl80211 - 3.7.0-r2 - 3.9.0-r1
libiperf3 - 3.10-r1 - 3.17.1-r4
ip-full - 6.3.0-r1 - 6.11.0-r1
lua-eco-md5 - 3.7.0-r2 - 3.9.0-r1
luci-mod-system - 25.103.51521~2ac26e5 - 25.137.37373~691440a
luci-theme-bootstrap - 25.103.51521~2ac26e5 - 25.137.37373~691440a
zerotier - 1.10.3-r1 - 1.14.1-r2
lua-eco - 3.7.0-r2 - 3.9.0-r1
luci-mod-status - 25.103.51521~2ac26e5 - 25.137.37373~691440a
lua-cjson - 2.1.0-r1 - 2.1.0-r4
lua-cjson-lua5.3 - 2.1.0-r1 - 2.1.0-r4
luci-app-firewall - 25.103.51521~2ac26e5 - 25.137.37373~691440a
tailscale - 1.66.4-r1 - 1.80.3-r1
lua-eco-log - 3.7.0-r2 - 3.9.0-r1
smstools3 - 3.1.21-r2 - 3.1.21-r4
luci-app-package-manager - 25.103.51521~2ac26e5 - 25.137.37373~691440a
luci-i18n-package-manager-zh-cn - 25.103.51521~2ac26e5 - 25.137.37373~691440a
luci-proto-ppp - 25.103.51521~2ac26e5 - 25.137.37373~691440a
luci-mod-admin-full - 25.103.51521~2ac26e5 - 25.137.37373~691440a
luci-base - 25.103.51521~2ac26e5 - 25.137.37373~691440a
rtty-openssl - 8.0.1-r1 - 8.1.2-r1
mt7986-wo-firmware - 20241110-r1 - 20241110-r2
luci-proto-ipv6 - 25.103.51521~2ac26e5 - 25.137.37373~691440a
eip197-mini-firmware - 20241110-r1 - 20241110-r2
openvpn-openssl - 2.6.13-r1 - 2.6.14-r1
lua-eco-ip - 3.7.0-r2 - 3.9.0-r1
vsftpd-tls - 3.0.3-r3 - 3.0.5-r2
lua-eco-netlink - 3.7.0-r2 - 3.9.0-r1
lua-eco-http - 3.7.0-r2 - 3.9.0-r1
tc-tiny - 6.3.0-r1 - 6.11.0-r1
tor - 0.4.8.9-r1 - 0.4.8.12-r1
lua-eco-socket - 3.7.0-r2 - 3.9.0-r1
luci-i18n-base-zh-cn - 25.103.51521~2ac26e5 - 25.137.37373~691440a
tor-geoip - 0.4.8.9-r1 - 0.4.8.12-r1
luci - 25.103.51521~2ac26e5 - 25.137.37373~691440a
luci-light - 25.103.51521~2ac26e5 - 25.137.37373~691440a
lua-eco-ubus - 3.7.0-r2 - 3.9.0-r1
libexpat - 2.6.3-r1 - 2.7.1-r1
luci-mod-network - 25.103.51521~2ac26e5 - 25.137.37373~691440a
lua-eco-base64 - 3.7.0-r2 - 3.9.0-r1
lua-eco-dns - 3.7.0-r2 - 3.9.0-r1
jsonfilter - 2024.01.23~594cfa86-r1 - 2025.04.18~8a86fb78-r1
iperf3 - 3.10-r1 - 3.17.1-r4
luci-i18n-firewall-zh-cn - 25.103.51521~2ac26e5 - 25.137.37373~691440a
I'm not confortable with all of outdated package...
Is there some I must not update?
I remember with 4.6.x or before, when I do an opkg upgrade, I broke the GL.Inet interface, and I had to install an old version of ubus...something in order to get my GL interface back.
I just hope there will an acceleration in the update of the firmware 
I agree with that.
4 Likes
My log file is filling up with this:
Tue May 20 19:23:21 2025 daemon.err eco[22588]: call wifi.get_config fail with http code: 302
Any ideas?
In LUCI, there is this warning:
Legacy rules detected
There are legacy iptables rules present on the system. Mixing iptables and nftables rules is discouraged and may lead to incomplete traffic filtering.
Is this normal?
Anyone has this too?
Good, we getting there, hopefully I can get out 4.6.6-op24 soon 
1 Like
Hi again,
For the warning "Legacy rules detected", I've got this:
root@GL-MT6000:~# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -m set --match-set GL_MAC_BLOCK src -j DROP
root@GL-MT6000:~# ip6tables -S
-ash: ip6tables: not found
It seems this ipatble rules doesn't exists in nft version.
Can the old iptable rules be deleted without consequences?
Or must it be converted into nft?
1 Like
bruce
150
iptables may not be adapted well, but it does not affect the router networking, actually the rules didi not take effect.
Temporary workaround:
iptables -w -D FORWARD -m set --match-set GL_MAC_BLOCK src -j DROP
iptables -w -t mangle -D PREROUTING -j VPN_SER_POLICY
1 Like
Hello @bruce
Thanks for your answer.
If it doesn't take effect, can I simpply remove it?
Does the workaround you gave me remove the rule?
What does the rule with VPN_SER_POLICY do?
I use the flint2's VPN server to conect to my lan with wireguard or OpenVPN.
