Quote from: nero355 on April 02, 2026, 05:15:44 PMWhat's so bad about these boxes? In comparison to the other ISP-provided devices, they are among the most flexible, most configurable and generally most "prosumer" I've seen. Of course they're not Open WRT and not close to OPNsense but that's not what they're meant to be, and they're good at what they do, update support is also better than most ISP-provided boxes. However, the flexibility is also being dumbed-down in the name of "Clean UI and pleasant user experience", making simple tasks unnecessarily complicated (like the removal of the "disable WLAN" option, which now you can only do by disabling every transmit band individually, and you can't disable ISDN/S0 at all), so now you need a FAQ for what used to be self-explanatory. Also, I think at some point ion the past they had firewall logs that seem to have vanished, or hidden extremely well. But what annoys me most about FritzOS is that they'll forward you to some AVM site from within their UI without so much as notifying you. This is, to me, a security hazard, the UI of an appliance must be entirely self-contained without external links unless these are explicitly declared.QuoteAVM's FritzboxI hate those things! :(
I know ISPs in Germany have flooded the country with them and some Dutch ISPs use them too, but still : Can we please get rid of those things ?!?!
Quote from: Greg_E on March 03, 2026, 09:45:42 PMHow long did it take Linux to really get rolling on x86? RISC-V is fairly new still.
Quote from: spooner.arthur on April 02, 2026, 05:43:56 PMMacht das Sinn?
Quote from: spooner.arthur on April 02, 2026, 05:43:56 PMUnd noch viel wichtiger, ist es dann überhaupt sicherer?
Quote from: OPNenthu on Today at 05:09:25 AMThis is my method too, but now she just blames me automatically even when it's not my fault :)
Quote from: OPNenthu on Today at 05:09:25 AMRegarding the Household test on the LibreQoS site, I asked ChatGPT what the test looks for and it gave an interesting response. It said that the houshold test falls down quickly when using FQ_CoDel because it cannot distinguish between flows. All traffic has equal priority so things like gaming, VoIP, etc. can get impacted quickly when there is traffic from multiple clients.
Quote from: OPNenthu on Today at 05:09:25 AMAs it's not available on FreeBSD, the best we can do is prioritize into queues. I guess for that to work with FQ_CoDel we would need multiple pipes right? Or maybe one pipe with no scheduler and instead use CoDel within priority queues?
QuoteHere is an overview of the FQ_CoDel algorithm that performs these tasks in parallel:
1. Separate every traffic flow's arriving packets into their own queue.
2. Remove a small batch of packets from a queue, round-robin style, and transmit that batch through the (slow) bottleneck link to the ISP. When each batch has been fully sent, retrieve a batch from the next queue, and so on.
3. Offer back pressure to flows that are sending "more than their share" of data.
This last step is the heart of the FQ_CoDel algorithm. It measures the time that a packet remains in a queue (its "sojourn time"). That's how it determines that a flow is using more than its share. If packets have been in a queue "too long" (that is, if their sojourn times exceed the target setting for longer than the interval), FQ_CoDel begins to mark or drop some of those packets to cause the sender to slow down.
Quote from: OPNenthu on Today at 05:09:25 AMI would be tempted to try this but I don't know how to match the traffic accurately. For example, how do we use rules to distinguish video streaming from regular downloads (both using HTTPS)? Are we supposed to match by destination, e.g. all YouTube.com -> send to high prio queue?
Quote from: OPNenthu on Today at 05:09:25 AMIf someone has a guide for that in OPNsense it would be great. I'm sometimes getting an 'F' on that test.
Quote from: nero355 on April 02, 2026, 05:15:44 PMThere is soo much already out there so what do you need exactly that they can not offer ?!