By disabling QoS, SQM, Data Statistics functions, the wireless DL/UL works normally. (only disable SQM will do the job, by further disabling “Data Statistics”, the wireless DL/UL speed is even faster)
Limit wireless client DL/UL speed(1024000Kb/1024000Kb, it affects the UL speed to only 1xx Mb, the DL speed is normal.
That is to say, if the APPs, domain, IPs, etc. in the list are displayed (now is hidden), some people with ulterior motives (who did not know these illegal APPs and websites before) will now learn about these in detail through the list, which will cause us a risk of transmission, and these individuals could then try to use them surreptitiously.
Yes, but we really have no way to disclose which apps and websites of gambling are blocked in GUI (or anywhere). Just said that after discovering deficiencies or omissions, we will update the DPI signature DB ASAP to add them to the blocking group.
If there is a misjudgment, please submitted to us to update the signature DB.
If there is no detailed list, how can we to whitelist mechanism, yep, maybe we need to evaluate this.
Can you tell me where this database is held? I asked about identifiers and how the interactions take place. How is the data stored / transmitted? Are signature updates realtime or would we need to update the firmware for the effects to take place, I'm guessing the DB is held online which can be updated in realtime but again, how does this work whilst respecting privacy?
While I agree that not broadcasting lists can be a good idea for the reason you stated it also can be negative. Take any blocklist online, we can browse them (good or bad domains) depending on the list and have the same insights that you are suggesting is bad, but on the flip side we can see exactly what is being blocked. We can also debug by filtering through the lists to see what domain is blocked and give potential reasons as to why things are not loading.
And whilst on the subject of not loading sites etc could it be possible to include a personalised blocked page? The reason I suggest this is because when the blocked rules (apps) are applied and you try and visit said sites then you are just treated with a timeout page, this could then lead to troubleshooting why pages are not loading only to find out it was because of the blocklist.
In the current version, the DB is placed on the router locally.
In the later stage, the signature DB may be updated in the cloud, and then the DB will be pushed to the router to OTA, and data processing will still be done locally. (It may also be new other solutions)
If there is any interaction between the router local and cloud, we will definitely consider user privacy and security carefully.
I see, it is a good suggestion to provide another (new) setting interface about a whitelist list, and put this list at the highest priority, so that users can troubleshoot blocking problems; On the other hand, a user may want to block most of the domain list in a certain rule, but still want to customize allow a few of them, may this solution right?
Yes that would work. When I said about using a personalised blocked page I was aiming it at mini html / browser landing page that lets the client know about the restriction. I know these pages can sometimes be difficult to use as it requires redirecting certain traffic (https) to the custom landing page but maybe the glinet team can make it so it does this internally with a redirect to a static custom page on the router with no errors…
Great! Thanks for taking the time to read my suggestions. May I ask, when is the firmware going to be available for the Brume 2. I think the Brume 2 should have been one of the first devices to receive this since it's aimed as a security gateway and these are basically security gateway features.
The firmware plan for Brume2 is to add this feature with the standard firmware when it is upgraded to v4.9 (or v5.0).
Yes, it is indeed one of the first batch devices to get the standard firmware update.
Currently stage it is just preview and experience in advance.
It's not the physical ports. It's network ports. For example a game like counter strike 2 uses 27015-27050 range UDP Outbound ports for the multiplayer gameplay. So when the router detects the that port range in outboard being used, it can prioritize the game’s traffic on that port range. So an option that allows adding applications that may not be in the DPI by custom port range would be nice.
May I know if we have already selected for the Games category in the higher priority, but you want to customize the port (UDP) to bring it is at the highest priority, right?
Looking at Data Statistics - this was cool and a really good start.
What could make that really REALLY useful would be not to have just the "block or not" to send traffic Via - tying VPN policy mode with Data Statistics.
So do your vpn setup just like we do now, when that is done you can use those connections to direct traffic over wan or out trough VPN within Data Statistics, greatly simplifying the directing part of VPN policys...
Was using wired. Since someone mentioned the same problem in this thread I installed the sqm in luci to find out gl.inet chose to apply sqm to br-lan instead of the default WAN, this is why bandwidth limits are reversed in the main page.
After changing the sqm target to wan the gl.inet sqm page is now limiting the correct sides.
Also for the next release I suggest adding more features to your sqm page since it has many important dials you are missing. For example please consider using this Asus cake page as guidance where it includes most of the dials to fit your connection and usage. overhead, MPU, ack filter, fairness keywords are all important.