Will the Mudi 7 (GL-E5800) also get the 4.9 beta version? If so, when? Or will it only receive the final stable release? Or will it only get 4.10?
I'm asking because I'm also affected by the disconnection issue, and I saw there was a manual fix for it in another thread. Thanks for the response!"
Here's a thought ......... perhaps they are different people /departments and frontline staff look at the internet questions while the backroom people beaver away working hard on other issues?
I do not know how you formed the opinion thinking developers would waste time trawling through mundane and dumb forum posts.
I guess that thought did not cross your mind?
4.10 it has all the features of 4.9 and was close to be released on Friday last week, but so far nothing is released yet, I'm still waiting.
Thank you!
How do you know it was close to being released?
Surely you're not for real? So what? I guess it will be released when it is ready - it sounds like your nose is way out of joint and you have some self entitled reason to be so offended with the waiting.
IT was confirmed by a rep, what is with your bizzare attitude and assumptions
Obviously you seem to enjoy attacking others who don't even engage you in conversation, since it appears you have nothing better to do.
I have zero issues with waiting i just wanted it to be ready and not half baked, and your the one who is so offended by my post you decide to write and incoherent gibberish respond out of pure emotion and no point.
Which "warning" label are you referring to?
You can move your mouse over the label, and it should display the corresponding explanation:
Regarding the issue where devices cannot access the Internet through the VPN tunnel after their MAC address changes, could you please share screenshots of your current configuration so we can better understand the situation?
Please provide:
Some users do not want the router to keep historical records of devices. They can enable this option to automatically remove offline clients.
Currently, this is not available. The device's memory/storage may not be able to support keeping records for such a long period.
However, we will record this request and see whether there are other ways to implement it in the future.
If you have a symmetrical gigabit fiber Internet connection, SQM should generally not be necessary.
SQM is mainly useful when your network frequently reaches full utilization and you need to reduce bufferbloat and maintain lower latency under load.
You can find more details in our blog:
https://www.gl-inet.com/blogs/blog/how-to-reduce-bufferbloat-with-sqm-on-glinet-routers
I don't have a computer at the moment, but you got the orange triangle right. That's what I see with my phone. The message is: “The reserved IP is not in the same network segment as the current IP, the configuration does not take effect.”
I just tried to do a speed test, and maybe I'm doing something wrong, but devices on the main network are much faster than on the guest and IoT networks. What latency should I expect on fast.com? I'm currently getting the following: Unloaded - 16ms, Loaded - 787ms.
What's the reason for that?
With regards to the Guest and IoT networks, I notice there are fewer options to set compared to the main network. Do the Guest and IoT networks use the radio configuration settings from the main network, like bandwidth and channel?
Both Guest and IoT networks seem to have AP isolation enabled by default. Is there any benefit to enabling that for LAN too?
If this "warning" label appears when configuring a Reserved IP for a Guest / IoT device, then it should be a known issue.
The Reserved IP function itself should work normally, if the reserved IP address is still within the Guest / IoT network. We plan to optimize this warning message in future firmware versions.
Was this test performed after enabling SQM?
Currently, our SQM implementation only applies to the Main LAN network and does not yet support Guest / IoT networks.
This may be improved in future versions.
Yes.
When AP isolation is enabled, devices connected to the SSID cannot communicate with each other, which provides additional security.
Please note that this only applies to wireless clients. Wired-to-wired and wired-to-wireless communication will still work.
Normally, devices on the LAN network need to communicate with each other, so we do not recommend enabling AP isolation on the LAN network. The security benefit is also limited in most cases.
As I mentioned earlier, the warning label appears when configuring a reserved IP for a Guest/IoT device. So, are you saying that despite the warning, the reserved IP setting does work? What's actually causing this problem, and will there be a fix in the near future like v4.10? I'm actually surprised this is even a problem.
I didn't know that AP isolation doesn't apply to wired-to-wired and wired-to-wireless communication. Is this a potential security issue?
No, the test wasn't done on the guest or IoT network. It was done on the main network. Why wasn't SQM implemented on the guest and IoT networks?
What is the actual difference between guest and IoT networks? Is one more hardened and secured than the other?
I still don't understand what Block WAN Subnets do. Should I enable this?
You’re arguing against a point I never made.
At no point did I say that developers are wasting their time reading forum posts. I said that generic networking questions don’t require GL.iNet staff in the first place because they’re already covered by documentation and countless other resources. The official forum is far more valuable for product-specific questions, bug reports and feature requests.
Whether those replies come from developers, support staff or moderators is completely irrelevant to that argument.
So yes, that possibility did cross my mind. It just wasn’t the point.
I have v4.9.0-op24 beta2
Are you achieving maximum fiber optic transfer with DPI enabled?
We have a mechanism to check whether the user-configured Reserved IP is within the Main LAN subnet range. Obviously, if the IP address is outside the subnet range, the configuration will not take effect.
However, the current check does not consider the Guest / IoT network scenarios. Therefore, when configuring a Reserved IP for a Guest / IoT device, this warning message may appear even if the IP address is within the corresponding Guest / IoT subnet range.
This is only a display issue. The Reserved IP function itself should still work as expected, as long as the reserved IP is within the correct subnet range.
This is expected behavior, because by default the Guest / IoT networks do not provide wired access.
If you are referring to the difference between Unloaded and Loaded latency, then this is likely expected behavior.
The former measures latency when the network is idle, while the latter measures latency when the network is under load. It is expected that latency will increase under load.
We plan to optimize this in future versions, possibly around v4.11.
Currently, there is no significant difference in terms of security.
They mainly provide separate networks so that you can isolate different devices or use them for different purposes.
When enabled, it blocks access from Guest / IoT networks to subnets behind the WAN interface but still allow to Internet.
This is only needed when the GL.iNet router is used as a secondary/home auxiliary router and you do not want Guest / IoT devices to access the network behind your main router.
In other scenarios, such as when the GL.iNet router is directly connected to an ISP modem, there is no need to enable this option.
How do I know if the IP address is outside the subnet range? I don't even see an option to set the IP address. I only see the toggle to reserve it.
What's the point of the guest and IoT networks if there is no difference between them? Surely there has to be some difference.
If you are simply using the Reserved IP button, there is no need to worry about the address falling outside the subnet range.
You can specify a custom IP address under Admin Panel → Network → LAN → Address Reservation.
This is not the CPU usage percentage. It represents total CPU consumption per individual CPU core.
For multi-core devices (such as the MT6000 with a quad-core CPU), the value can exceed 1. For the MT6000, the reasonable maximum value is 4.
Reference:
https://serverfault.com/questions/346410/cpu-utilization-over-100-in-linux-system
In some cases, the value may even exceed the number of physical CPU cores if the currently running processes require more resources than the available limit.
Forgot to ask you, but what are the use cases for using the Brume 3 as a secondary/home auxiliary router? In which situations would anyone use the Brume 3 like that?
