[Cerowrt-devel] Fwd: FW: Memorial service for David Mills

[Dave Taht via Cerowrt-devel]

-- Forwarded message -
From: Dave Hart 
Date: Thu, Mar 7, 2024 at 3:18 PM
Subject: Fwd: FW: Memorial service for David Mills
To: , NTP WG , <
time-n...@lists.febo.com>, NANOG 


The University of Delaware is hosting a memorial service for "Father Time"
David Mills this coming Monday at 3:00pm local time.  With Sunday's leap
ahead in local time, that's 17:00 UTC, Noon US Pacific time.  There will be
a live stream:  https://sites.udel.edu/udlive/mills/

Cheers,
Dave Hart
Dr. David L. Mills Memorial Service
11 Mar 2024, 13:00 – 11 Mar 2024, 16:00
(GMT+00:00) Coordinated Universal Time
Mitchell Hall



Memorial Service for David MillsMonday, March 11 | 3 p.m.
Mitchell Hall





David Mills, a retired University of Delaware professor known as the
“father time” of the Internet, *passed away*

on
January 17, 2024. Dr. Mills is survived by his wife Beverly Mills, his
daughter Eileen Schnitzler, his son Keith Mills, and his brother Gregory
Mills.

You’re invited to join the Mills family and the University of Delaware
College of Engineering for a secular memorial for Dr. David Mills at 3 p.m.
on March 11 in Mitchell Hall.

Dr. Mills, who held appointments in UD’s College of Engineering in the
departments of electrical and computer engineering and computer and
information sciences, is most well-known for developing the network time
protocol, the system that allows computers on a network to synchronize
their time. Along with being a pioneer of the early Internet, he is
remembered for his curiosity, knowledge and enthusiasm.

The impact of Dr. Mills’ work was recognized by several professional
societies—Dr. Mills was a member of the National Academy of Engineering,
the Internet Society (ISOC), the American Association for the Advancement
of Science and he was a Fellow of both the Association for Computing
Machinery and the Institute of Electrical and Electronic Engineering.

Outside of his career’s many achievements, Dr. Mills’ hobbies included
running an amateur radio station (W3HCF) out of his home in Newark. He was
also a member of the American Radio Relay League, the Radio Society of
Great Britain and the Amateur Satellite Organization.

*Please let us know if you’ll attend.*




*Read the New York Times obituary*


*Copyright © 2024 University of Delaware College of Engineering, All rights
reserved.*
You are receiving this email message as a member of the University of
Delaware College of Engineering community.

*Our mailing address is:*

University of Delaware College of Engineering

102 DuPont Hall

Newark, Delaware 19716







-- 
https://www.youtube.com/watch?v=N0Tmvv5jJKs Epik Mellon Podcast
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] slashdot on home routers

[Dave Taht via Cerowrt-devel]

https://slashdot.org/story/24/02/03/0451258/ask-slashdot-can-you-roll-your-own-home-router

-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [PATCH net v2 2/2] net: dqs: add NIC stall detector based on BQL

[Dave Taht via Cerowrt-devel]

-- Forwarded message -
From: Breno Leitao 
Date: Wed, Jan 31, 2024 at 5:32 AM
Subject: [PATCH net v2 2/2] net: dqs: add NIC stall detector based on BQL
To: , , ,
, Steven Rostedt , Masami
Hiramatsu , Mathieu Desnoyers
, Andrew Morton

Cc: , , Randy
Dunlap , Bjorn Helgaas ,
Jonathan Corbet , Johannes Berg
, Simon Horman , Thomas
Weißschuh , open list:TRACING



From: Jakub Kicinski 

softnet_data->time_squeeze is sometimes used as a proxy for
host overload or indication of scheduling problems. In practice
this statistic is very noisy and has hard to grasp units -
e.g. is 10 squeezes a second to be expected, or high?

Delaying network (NAPI) processing leads to drops on NIC queues
but also RTT bloat, impacting pacing and CA decisions.
Stalls are a little hard to detect on the Rx side, because
there may simply have not been any packets received in given
period of time. Packet timestamps help a little bit, but
again we don't know if packets are stale because we're
not keeping up or because someone (*cough* cgroups)
disabled IRQs for a long time.

We can, however, use Tx as a proxy for Rx stalls. Most drivers
use combined Rx+Tx NAPIs so if Tx gets starved so will Rx.
On the Tx side we know exactly when packets get queued,
and completed, so there is no uncertainty.

This patch adds stall checks to BQL. Why BQL? Because
it's a convenient place to add such checks, already
called by most drivers, and it has copious free space
in its structures (this patch adds no extra cache
references or dirtying to the fast path).

The algorithm takes one parameter - max delay AKA stall
threshold and increments a counter whenever NAPI got delayed
for at least that amount of time. It also records the length
of the longest stall.

To be precise every time NAPI has not polled for at least
stall thrs we check if there were any Tx packets queued
between last NAPI run and now - stall_thrs/2.

Unlike the classic Tx watchdog this mechanism does not
ignore stalls caused by Tx being disabled, or loss of link.
I don't think the check is worth the complexity, and
stall is a stall, whether due to host overload, flow
control, link down... doesn't matter much to the application.

We have been running this detector in production at Meta
for 2 years, with the threshold of 8ms. It's the lowest
value where false positives become rare. There's still
a constant stream of reported stalls (especially without
the ksoftirqd deferral patches reverted), those who like
their stall metrics to be 0 may prefer higher value.

Signed-off-by: Jakub Kicinski 
Signed-off-by: Breno Leitao 
---
 .../ABI/testing/sysfs-class-net-queues| 23 +++
 include/linux/dynamic_queue_limits.h  | 35 +++
 include/trace/events/napi.h   | 33 ++
 lib/dynamic_queue_limits.c| 58 +
 net/core/net-sysfs.c  | 62 +++
 5 files changed, 211 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-net-queues
b/Documentation/ABI/testing/sysfs-class-net-queues
index 5bff64d256c2..45bab9b6e3ae 100644
--- a/Documentation/ABI/testing/sysfs-class-net-queues
+++ b/Documentation/ABI/testing/sysfs-class-net-queues
@@ -96,3 +96,26 @@ Description:
Indicates the absolute minimum limit of bytes allowed to be
queued on this network device transmit queue. Default value is
0.
+
+What:
/sys/class/net//queues/tx-/byte_queue_limits/stall_thrs
+Date:  Jan 2024
+KernelVersion: 6.9
+Contact:   net...@vger.kernel.org
+Description:
+   Tx completion stall detection threshold. Kernel will guarantee
+   to detect all stalls longer than this threshold but may also
+   detect stalls longer than half of the threshold.
+
+What:
/sys/class/net//queues/tx-/byte_queue_limits/stall_cnt
+Date:  Jan 2024
+KernelVersion: 6.9
+Contact:   net...@vger.kernel.org
+Description:
+   Number of detected Tx completion stalls.
+
+What:
/sys/class/net//queues/tx-/byte_queue_limits/stall_max
+Date:  Jan 2024
+KernelVersion: 6.9
+Contact:   net...@vger.kernel.org
+Description:
+   Longest detected Tx completion stall. Write 0 to clear.
diff --git a/include/linux/dynamic_queue_limits.h
b/include/linux/dynamic_queue_limits.h
index 407c2f281b64..288e98fe85f0 100644
--- a/include/linux/dynamic_queue_limits.h
+++ b/include/linux/dynamic_queue_limits.h
@@ -38,14 +38,21 @@

 #ifdef __KERNEL__

+#include 
 #include 

+#define DQL_HIST_LEN   4
+#define DQL_HIST_ENT(dql, idx) ((dql)->history[(idx) % DQL_HIST_LEN])
+
 struct dql {
/* Fields accessed in enqueue path (dql_queued) */
unsigned intnum_queued; /* Total ever queued */
unsigned intadj_limit;  /* limit + num_completed */
unsigned intlast_obj_cnt;   /* Count at last queuing */

+   unsigned long   history_head;
+   

[Cerowrt-devel] flint 2 benchmarks

[Dave Taht via Cerowrt-devel]

https://www.ozbargain.com.au/node/812219

-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] anyone using sunshine?

[Dave Taht via Cerowrt-devel]

https://arstechnica.com/gaming/2023/04/nvidias-gamestream-is-dead-sunshine-and-moonlight-are-better-replacements/

-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] dual 10Gbit SFP - 650 bucks

[Dave Taht via Cerowrt-devel]

https://store.minisforum.com/products/minisforum-ms-01


-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: OpenWrt One - celebrating 20 years of OpenWrt

[Dave Taht via Cerowrt-devel]

-- Forwarded message -
From: John Crispin 
Date: Tue, Jan 9, 2024 at 5:52 AM
Subject: OpenWrt One - celebrating 20 years of OpenWrt
To: OpenWrt Development List 
Cc: 


tl;dr

In 2024 the OpenWrt project turns 20 years! Let's celebrate this
anniversary by launching our own first and fully upstream supported
hardware design.

If the community likes the idea outlined below in greater details, we
would like to start a vote.

---

The idea

It is not new. We first spoke about this during the OpenWrt Summits in
2017 and also 2018. It became clear start of December 2023 while
tinkering with Banana Pi style devices that they are already pretty
close to what we wanted to achieve in ’17/‘18. Banana PIs have grown in
popularity within the community. They boot using a self compiled Trusted
Firmware-A (TF-A)and upstream U-Boot (thx MTK/Daniel) and some of the
boards are already fully supported by the upstream Linux kernel. The
only nonopen sourcecomponents are the 2.5 GbE PHYandWi-Fi firmware
blobsrunning on separate cores that areindependent of the main SoC
running Linuxand the DRAM calibration routines which are executed early
during boot.

I contacted three project members (pepe2k, dangole, nbd) on December 6th
to outline the overall idea. We went over several design proposals, At
the beginning we focused on the most powerful (and expensive)
configurations possible but finally ended up with something rather
simple and above all,feasible. We would like to propose the following as
our "first" community driven HW platform called "OpenWrt One/AP-24.XY".

Together with pepe2k (thx a lot) I discussed this for many hours and we
worked out the following project proposal. Instead of going insane with
specifications, we decided to include some nice features we believe all
OpenWrt supported platforms should have (e.g. being almost
unbrickablewith multiple recovery options, hassle-free system console
access, on-board RTC with battery backup etc.).

This is our first design, so let's KiSS!


Hardwarespecifications:

* SOC: MediaTek MT7981B
* Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)
* DRAM: 1 GiB DDR4
* Flash: 128 MiB SPI NAND+ 4 MiB SPI NOR
* Ethernet: 2x RJ45 (2.5 GbE + 1 GbE)
* USB (host): USB 2.0 (Type-A port)
* USB (device, console): Holtek HT42B534-2 UART to USB (USB-C port)
* Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1)
* Buttons: 2x (reset + user)
* Mechanical switch: 1x for boot selection (recovery, regular)
* LEDs: 2x (PWM driven), 2x ETH Led (GPIO driven)
* External hardware watchdog: EM Microelectronic EM6324 (GPIO driven)
* RTC: NXP PCF8563TS (I2C) with battery backup holder(CR1220)
* Power: USB-PD-12V on USB-C port (optional802.3at/afPoE via RT5040 module)
* Expansion slots: mikroBUS
* Certification: FCC/EC/RoHS compliance
* Case: PCB size is compatible to BPi-R4 and the case design can be re-used
* JTAG for main SOC: 10-pin 1.27 mm pitch (ARM JTAG/SWD)
* Antenna connectors: 3x MMCX for easy usage, assembly and durability
* Schematics: these will be publicly available (license TBD)
* GPL compliance: 3b. "Accompany it with a written offer ... to give any
third party ... a complete machine-readable copy of the corresponding
source code"
* Price: aiming for below 100$


How will the device be distributed?

OpenWrt itself cannot handle this for a ton of reasons. This is why we
spoke with the SFC early. The idea is that BPi will distribute the
device using the already established channels and for every device sold
a donation will be made to ourSFC earmarked fund for OpenWrt. This money
can then be used to cover hosting expenses or maybe an OpenWrt summit.

SFC is committed to working with us in various ways on this project —
including making sure OpenWrt'strademark is properly respected, that
this router isabeautiful example of excellent GPL/LGPL compliance,
andthatthis becomes a great promotional opportunity for our project and
FOSS generally!


FAQ

* Why are there are 2 different flash chips?
- the idea is to make the device (almost!) unbrickable and very easy to
recover
- NAND will hold the main loader (U-Boot) and the Linux image and will
be the default boot device
- NOR will be write-protected by default (with WP jumper available on
the board) and will hold a recovery bootloader (and other essential
data, like Wi-Fi calibration)
- a dedicated boot select switch will allow changing between NOR and NAND

* What will the M.2 slot be used for?
- we will use M.2 with M-key for NVMe storage. There is a
work-in-progress patch to make PCIe work inside the U-Boot bootloader.
This will allow booting other Linux distributions such as Debian and
Alpine directly from NVMe

* Why is there no USB 3.x host port on the device?
- the USB 3.x and PCIe buses are shared in the selected SoC silicon,
hence only a single High-Speed USB port is available

* What is the purpose of the console USB-C port?
- Holtek UART to USB bridge with CDC-ACM support on USB-C makes the
device ultra easy to 

[Cerowrt-devel] nanopu

[Dave Taht via Cerowrt-devel]

Looks like a possibly good base for a high speed network processor.

https://www.usenix.org/conference/osdi21/presentation/ibanez


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [NetDev-People] Cambium cnPilot 190W: New life for old hardware, improving reliability & performance with OpenWrt, fq_codel & cake

[Dave Taht via Cerowrt-devel]

From ewaste to something great.

-- Forwarded message -
From: Ignacio Ocampo via people 
Date: Sun, Oct 15, 2023 at 1:47 PM
Subject: [NetDev-People] Cambium cnPilot 190W: New life for old
hardware, improving reliability & performance with OpenWrt, fq_codel &
cake
To: 
Cc: Ignacio Ocampo 


Hi there, I'm new on this distribution list. But wanted to share this
article I post about improving the reliability and performance of old
hardware with new software. It has to do with Linux Kernel, FQ_Codel
and Cake, and building an OpenWrt image.

https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cake/

-- 
Ignacio Ocampo

___
people mailing list -- peo...@netdevconf.info
To unsubscribe send an email to people-le...@netdevconf.info


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] packet captures of sony's new 80Mbit service?

[Dave Taht via Cerowrt-devel]

Anyone got a ps4 or ps5 and can take a packet capture at their router?
Dying to know if it is cubic or bbr in particular

https://entertainment.slashdot.org/story/23/10/05/154219/sonys-high-bitrate-movie-service-is-now-available-on-ps5-and-ps4
-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] vyos w/fq_codel and cake

[Dave Taht via Cerowrt-devel]

After successfully having got them to switch the default over to
fq_codel last week,
I started looking over their very old skool traffic shaping policies.
Does anyone here use vyos? I used to really like it, but kind of went
pure openwrt, and now very little at all.

https://forum.vyos.io/t/qos-qoe-support-in-vyos/12376/2

https://docs.vyos.io/en/latest/configuration/trafficpolicy/index.html


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] zimablade

[Dave Taht via Cerowrt-devel]

https://www.zimaboard.com/blade/

-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] so many more davids vs goliath

[Dave Taht via Cerowrt-devel]

https://www.cnet.com/home/internet/features/internet-for-the-people-the-movement-for-affordable-community-led-broadband/

I was not aware nycmesh had grown so.

-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] cyber-trust mark program

[Dave Taht via Cerowrt-devel]

https://www.whitehouse.gov/briefing-room/statements-releases/2023/07/18/biden-harris-administration-announces-cybersecurity-labeling-program-for-smart-devices-to-protect-american-consumers/


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [Rpm] Fwd: Firewalla App 1.56 Beta (part 1): Wi-Fi Test, CAKE and more

[Dave Taht via Cerowrt-devel]

anyone here have a firewalla?

-- Forwarded message -
From: Frantisek Borsik via Rpm 
Date: Wed, Sep 6, 2023 at 9:12 AM
Subject: [Rpm] Fwd: Firewalla App 1.56 Beta (part 1): Wi-Fi Test, CAKE and
more
To: Jeremy Austin via Rpm 


CAKE is in 拾 good job, Dave!


All the best,

Frank
Frantisek (Frank) Borsik

https://www.linkedin.com/in/frantisekborsik
Signal, Telegram, WhatsApp: +421919416714
iMessage, mobile: +420775230885
Skype: casioa5302ca
frantisek.bor...@gmail.com


-- Forwarded message -
From: Firewalla 
Date: Wed, 6 Sep 2023 at 5:18 PM
Subject: Firewalla App 1.56 Beta (part 1): Wi-Fi Test, CAKE and more
To: 




*Quick News*



   - Gold SE
   

   beta wave 1 has shipped. Wave 2 coming soon.
   - The Firewalla Rack Mount
   

   Pre-Sale is on now! Tooling going through testing.


*Firewalla App 1.56 BETA Release, Part 1*


*Firewalla App version 1.56 *
*is
now available to beta users on iOS and Android!* Here are some of the new
features in this update:



   - Wi-Fi Performance Test Tool
   - Smart Queue - CAKE (Public Beta)
   - Local Port in Smart Queue Rules
   - Server Certificate in AnyConnect
   - and more ...

Note that some new features require box version 1.977 or above, currently
available on Firewalla Gold SE production version, Gold Beta version,
Purple, Purple SE, and Blue Plus Early Access versions.


*Wi-Fi Test Tool (Requires Box 1.977) *


Our new *Wi-Fi Test* tool makes it easy to find the best and worst Wi-Fi
spots around your house. When your phone is connected to Firewalla’s local
network, you can use this feature to test the connection from your phone to
your box. You can switch between download, upload, and ping latency tests.
For step-by-step instructions, check out our video tutorial

.


If you’re connected to the *VPN Server*
,
the feature will be displayed as *VPN Test* instead of Wi-Fi Test. VPN Test
will show you the speed from your phone to your Firewalla box via VPN.


*Smart Queue - CAKE (Public Beta)*


CAKE (Common Applications Kept Enhanced) is a shaping-capable queue
discipline which uses both AQM and FQ.


Smart Queue - CAKE is now available for all Gold, Purple, and Purple SE
boxes. To switch to CAKE, tap *Smart Queue* on the box's main screen,
tap *Queue
Type* -> *CAKE*, and save. For step-by-step instructions, check out our video
tutorial

.

   - CAKE is best used with low-speed Internet.
   - CAKE is in Public Beta. If you have any feedback, please post it here
   

   .



*Local Port in Smart Queue Rules*


We now support specifying a *Local Port* as the target in *Smart Queue
Rules*. Check out our video tutorial

for step-by-step instructions.

[Cerowrt-devel] fcc commish engages on hackernews

[Dave Taht via Cerowrt-devel]

really made my day:

https://news.ycombinator.com/item?id=37392676

-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Mofi still shipping Barrier Breaker (14.07)

[Dave Taht via Cerowrt-devel]

On Sun, Sep 3, 2023 at 10:14 AM Robert Marko  wrote:
>
> On Sun, 3 Sept 2023 at 19:05, Dave Taht  wrote:
> >
> > The qsdk is on openwrt 15.
>
> You won't believe it but they made it to 19.07 from the 12.0 release,
> and it seems they are preparing for 21.02.

It would be so nice if they tried to keep up with 23.x and released no
more than 6 months behind. But I should be filled with joy at hearing
19.07 is in there.

In other news, I have no idea what openwrt version this was but tplink
is vulnerable at least.

https://nvd.nist.gov/vuln/detail/CVE-2023-1389

>
> Regards,
> Robert
> >
> > On Sun, Sep 3, 2023 at 9:51 AM Philip Prindeville
> >  wrote:
> > >
> > > Hi all,
> > >
> > > As we work on the 23.05 release, I was stunned to receive a Mofi 
> > > MOFI4500-4GXeLTE-V3 router with 14.07 installed on it as part of my 
> > > Unlimitedville enrollment.
> > >
> > > I thought, "wow, this must have been sitting in a warehouse a while!  I'd 
> > > better update it."  So I went to the company's support site, grabbed the 
> > > latest image, flashed it, rebooted and... still running 14.07.
> > >
> > > For those of you too young to remember, Barrier Breaker was released 
> > > 10/2014 and included the 3.10.14 kernel (released 6/2013).
> > >
> > > How is this not cyber security malpractice?  A firewall is your first 
> > > line of defense against cyber attacks.  If your firewall has long known, 
> > > well documented vulnerabilities and exploits, you might as well not have 
> > > a firewall at all.
> > >
> > > I wrote them asking why there wasn't a more recent, more secure release 
> > > of the firewall firmware and this was their response:
> > >
> > >
> > > > Dear Philip,
> > > > You dint seem to know what you are talking about and should leave 
> > > > software to Profesionals like us and relax
> > >
> > >
> > > I hope that most of the companies that use our software are more 
> > > diligent, and don't incur repetitional damage to our efforts by 
> > > continuing to ship EOL firmware.
> > >
> > > I get that not every company has kernel developers in-house, and frankly, 
> > > providing an updated kernel release for their SoC is the manufacturer's 
> > > responsibility, and MediaTek has not been responsive in this respect (for 
> > > the longest time they were shipping a 2.6.36 SDK!).  Some of the larger 
> > > vendors (TPLink, ActionTec, Linksys, DLink, Netgear, et al) or their ODM 
> > > partners have the option to hold their feet to the fire and make orders 
> > > contingent on updated SDK's...  I doubt that Mofi does the sort of volume 
> > > that gives them any leverage.
> > >
> > > But I regress.
> > >
> > > Class Action suits are becoming more prevalent with computer and 
> > > networking equipment manufacturers, as the public becomes aware of the 
> > > increasing cyber security threats as well as manufacturers' implied 
> > > responsibility to address vulnerabilities in a timely fashion as they 
> > > become aware of them.
> > >
> > > I'm calling this out because I honestly hope it's the far outlier in our 
> > > ecosystem, and not the rule.
> > >
> > > Sadly,
> > >
> > > -Philip
> > >
> > >
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-de...@lists.openwrt.org
> > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> >
> >
> > --
> > Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> > Dave Täht CSO, LibreQos
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-de...@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Mofi still shipping Barrier Breaker (14.07)

[Dave Taht via Cerowrt-devel]

The qsdk is on openwrt 15.

On Sun, Sep 3, 2023 at 9:51 AM Philip Prindeville
 wrote:
>
> Hi all,
>
> As we work on the 23.05 release, I was stunned to receive a Mofi 
> MOFI4500-4GXeLTE-V3 router with 14.07 installed on it as part of my 
> Unlimitedville enrollment.
>
> I thought, "wow, this must have been sitting in a warehouse a while!  I'd 
> better update it."  So I went to the company's support site, grabbed the 
> latest image, flashed it, rebooted and... still running 14.07.
>
> For those of you too young to remember, Barrier Breaker was released 10/2014 
> and included the 3.10.14 kernel (released 6/2013).
>
> How is this not cyber security malpractice?  A firewall is your first line of 
> defense against cyber attacks.  If your firewall has long known, well 
> documented vulnerabilities and exploits, you might as well not have a 
> firewall at all.
>
> I wrote them asking why there wasn't a more recent, more secure release of 
> the firewall firmware and this was their response:
>
>
> > Dear Philip,
> > You dint seem to know what you are talking about and should leave software 
> > to Profesionals like us and relax
>
>
> I hope that most of the companies that use our software are more diligent, 
> and don't incur repetitional damage to our efforts by continuing to ship EOL 
> firmware.
>
> I get that not every company has kernel developers in-house, and frankly, 
> providing an updated kernel release for their SoC is the manufacturer's 
> responsibility, and MediaTek has not been responsive in this respect (for the 
> longest time they were shipping a 2.6.36 SDK!).  Some of the larger vendors 
> (TPLink, ActionTec, Linksys, DLink, Netgear, et al) or their ODM partners 
> have the option to hold their feet to the fire and make orders contingent on 
> updated SDK's...  I doubt that Mofi does the sort of volume that gives them 
> any leverage.
>
> But I regress.
>
> Class Action suits are becoming more prevalent with computer and networking 
> equipment manufacturers, as the public becomes aware of the increasing cyber 
> security threats as well as manufacturers' implied responsibility to address 
> vulnerabilities in a timely fashion as they become aware of them.
>
> I'm calling this out because I honestly hope it's the far outlier in our 
> ecosystem, and not the rule.
>
> Sadly,
>
> -Philip
>
>
> ___
> openwrt-devel mailing list
> openwrt-de...@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] the network is devolving

[Dave Taht via Cerowrt-devel]

I see 100Mbit printers... and now 10Mbit single pair for 1km distance
is becoming a thing

https://electricui.com/blog/spe-sensor-node

-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] 1024 cores, locking

[Dave Taht via Cerowrt-devel]

https://semiengineering.com/implementing-fast-barriers-for-a-shared-memory-cluster-of-1024-risc-v-cores/


-- 
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [PATCH 00/10] Introduce STM32 Firewall framework

[Dave Taht via Cerowrt-devel]

-- Forwarded message -
From: Gatien Chevallier 
Date: Wed, Jul 5, 2023 at 11:29 AM
Subject: [PATCH 00/10] Introduce STM32 Firewall framework
To: , ,
, ,
, ,
, ,
, , ,
, ,
, ,
, , ,
, , ,
, , ,

Cc: , ,
,
,
, ,
, ,
, ,
, ,
, ,
, , Gatien
Chevallier 


Introduce STM32 Firewall framework for STM32MP1x and STM32MP2x
platforms. STM32MP1x(ETZPC) and STM32MP2x(RIFSC) Firewall controllers
register to the framework to offer firewall services such as access
granting.

This series of patches is a new approach on the previous STM32 system
bus, history is available here:
https://lore.kernel.org/lkml/20230127164040.1047583/

The need for such framework arises from the fact that there are now
multiple hardware firewalls implemented across multiple products.
Drivers are shared between different products, using the same code.
When it comes to firewalls, the purpose mostly stays the same: Protect
hardware resources. But the implementation differs, and there are
multiple types of firewalls: peripheral, memory, ...

Some hardware firewall controllers such as the RIFSC implemented on
STM32MP2x platforms may require to take ownership of a resource before
being able to use it, hence the requirement for firewall services to
take/release the ownership of such resources.

On the other hand, hardware firewall configurations are becoming
more and more complex. These mecanisms prevent platform crashes
or other firewall-related incoveniences by denying access to some
resources.

The stm32 firewall framework offers an API that is defined in
firewall controllers drivers to best fit the specificity of each
firewall.

For every peripherals protected by either the ETZPC or the RIFSC, the
firewall framework checks the firewall controlelr registers to see if
the peripheral's access is granted to the Linux kernel. If not, the
peripheral is configured as secure, the node is marked populated,
so that the driver is not probed for that device.

The firewall framework relies on the feature-domain-controller device
tree bindings: https://lore.kernel.org/lkml/0c0a82bb-18ae-d057-562b.
It is used by peripherals to reference a domain controller, in this
case a firewall feature domain. The bus uses the ID referenced by
the feature-domains property to know where to look in the firewall
to get the security configuration for the peripheral. This allows
a device tree description rather than a hardcoded peripheral table
in the bus driver.

The STM32 ETZPC device is responsible for filtering accesses based on
security level, or co-processor isolation for any resource connected
to it.

The RIFSC is responsible for filtering accesses based on Compartment
ID / security level / privilege level for any resource connected to
it.

STM32MP13/15/25 SoC device tree files are updated in this series to
implement this mecanism.

Oleksii Moisieiev (1):
  dt-bindings: Document common device controller bindings

Gatien Chevallier (9):
  dt-bindings: bus: add device tree bindings for RIFSC
  dt-bindings: bus: add device tree bindings for ETZPC
  dt-bindings: treewide: add feature-domains description in binding
files
  firewall: introduce stm32_firewall framework
  bus: rifsc: introduce RIFSC firewall controller driver
  arm64: dts: st: add RIFSC as a domain controller for STM32MP25x boards
  bus: etzpc: introduce ETZPC firewall controller driver
  ARM: dts: stm32: add ETZPC as a system bus for STM32MP15x boards
  ARM: dts: stm32: add ETZPC as a system bus for STM32MP13x boards

 .../bindings/bus/st,stm32-etzpc.yaml  |   90 +
 .../bindings/bus/st,stm32-rifsc.yaml  |  101 +
 .../bindings/crypto/st,stm32-hash.yaml|4 +
 .../devicetree/bindings/dma/st,stm32-dma.yaml |4 +
 .../bindings/dma/st,stm32-dmamux.yaml |4 +
 .../feature-domain-controller.yaml|   84 +
 .../devicetree/bindings/i2c/st,stm32-i2c.yaml |4 +
 .../bindings/iio/adc/st,stm32-adc.yaml|4 +
 .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml  |4 +
 .../bindings/iio/dac/st,stm32-dac.yaml|4 +
 .../bindings/media/cec/st,stm32-cec.yaml  |4 +
 .../bindings/media/st,stm32-dcmi.yaml |4 +
 .../memory-controllers/st,stm32-fmc2-ebi.yaml |4 +
 .../bindings/mfd/st,stm32-lptimer.yaml|4 +
 .../bindings/mfd/st,stm32-timers.yaml |5 +
 .../devicetree/bindings/mmc/arm,pl18x.yaml|4 +
 .../devicetree/bindings/net/stm32-dwmac.yaml  |4 +
 .../bindings/phy/phy-stm32-usbphyc.yaml   |4 +
 .../bindings/regulator/st,stm32-vrefbuf.yaml  |4 +
 .../devicetree/bindings/rng/st,stm32-rng.yaml |4 +
 .../bindings/serial/st,stm32-uart.yaml|4 +
 .../bindings/sound/st,stm32-i2s.yaml  |4 +
 .../bindings/sound/st,stm32-sai.yaml  |4 +
 .../bindings/sound/st,stm32-spdifrx.yaml  |4 +
 .../bindings/spi/st,stm32-qspi.yaml   |4 +
 .../devicetree/bindings/spi/st,stm32-spi.yaml |4 +
 .../devicetree/bindings/usb/dwc2.yaml |

[Cerowrt-devel] Fwd: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt

[Dave Taht via Cerowrt-devel]

-- Forwarded message -
From: Steffen Vogel 
Date: Thu, Jun 22, 2023, 1:46 AM
Subject: Re: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt
To: Juliusz Chroboczek 
Cc: 


Hi Juliusz,



Its great to see that the RTT draft has been reactivated!

I already started to support its first version it in my Go implementation
which I am

Planning to use for routing in VPN overlay networks.



I’ve given the updated draft a first read. Here are my comments so far.

Sorry if that’s not the correct approach for submitting a review.

I am a newcomer to the whole RFC process.







# Section 1 + 3: Negative feedback loop



The introductory section says:



> Since this causes a negative feedback loop, special care is needed to
ensure

> that the resulting network is reasonably stable.



This statement is repeated in Section 3:



> Second, using the RTT signal for route selection gives rise to a negative
feedback loop: [...]



However, in my understanding a control loop is usually qualified as negative

if it dampens systems responses and hence promotes stability.



This is also in line with the definition on Wikipedia:



> Negative feedback (or balancing feedback) occurs when some function of the

> output of a system, process, or mechanism is fed back in a manner that
tends

> to reduce the fluctuations in the output, whether caused by changes in the

> input or by other disturbances.



Source: https://en.wikipedia.org/wiki/Negative_feedback



Should this working be replaced with "positive feedback"?



# Section 2.1: Clock properties



The draft permits clocks to be stepped to support reboots of nodes.

However, I think it would wise to recommend the use monotonic system clocks

where available. E.g. CLOCK_MONOTONIC vs CLOCK_REALTIME on Linux systems.



Otherwise, time adjustments by NTP clients or leap-seconds might

impede the protocol operation if the clocks are stepped by a seconds or
fractions thereof.



# Section 2.1: Clock origin



Maybe replace the term clock "origin" with "epoch"?



Here are a few definitions which I think match the intended meaning in this
context:



- "In computing, an epoch is a date and time from which a computer measures
system time."

   (https://en.wikipedia.org/wiki/Epoch_(computing))



- "In a computing context, an epoch is the date and time relative to which
a computer's clock and timestamp values are determined"

   (https://www.techtarget.com/searchdatacenter/definition/epoch)



- "an instant of time or a date selected as a point of reference"

   (Merriam Webster)



- "a precise date to which information, such as coordinates, relating to a
celestial body is referred (astrology)"

   (Collins Dictionary)



# Section 5: Unit of timestamp fields



Section 5 defines the 32-bit timestamp as follows:



> Timestamps are encoded as 32-bit unsigned integers, expressed in units of
one microsecond, counting from an arbitrary origin. Timestamps wrap around
every 4295 seconds, or slightly more than one hour.



While, section 2.3 defines the timestamp as follows:



> Timestamp values are a count of milliseconds stored as a 32-bit unsigned
integer; thus, they wrap around every 50 days or so.



I think having a millisecond resolution of the timestamps is a bit too
coarse for some use cases.

I would recommend to go with microseconds as defined in Section 5.



# Section 9: Hyperlink in reference



I am a newcomer to writing RFCs, but I was wondering why the URL of

the rerence [DELAY-BASED] is not put into <>.

In the html-ized view of the IETF datatracker, the link is not converted to

a hyperlink.



# Typos



- Section 2.1:

  - Old: "This extesion extends every etry in the Neighbour Table with the
following data"

  - New: "This **extension** extends every **entry** in the Neighbour Table
with the following data



- Section 2.2:

 - Old: Additionally, it ocasionally sends a set of IHU messages, at most
one per neighbour [...].

  - New: Additionally, it **occasionally** sends a set of IHU messages, at
most one per neighbour [...].



- Section 2.2:

  - Old: This is illustrated in the followsing sequence diagram

  - New: This is illustrated in the **following** sequence diagram



- Section 2.3:

  - Old: Similary, the node compares the Hello's timestamp with the Receive
Timestamp recorded in the Neighbour Table

  - New: **Similarly**, the node compares the Hello's timestamp with the
Receive Timestamp recorded in the Neighbour Table



Please let me know if I can support the process of getting this draft into
a standard in any other way 



Best regards,

Steffen



*From: *babel  on behalf of Donald Eastlake <
d3e...@gmail.com>
*Date: *Thursday, 22. June 2023 at 04:10
*To: *Juliusz Chroboczek 
*Cc: *
*Subject: *Re: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt



Hi Juliusz,



Thanks for reactivating this draft !


Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic 

[Cerowrt-devel] Fwd: OpenWrt 23.05.0-rc1 first release candidate

[Dave Taht via Cerowrt-devel]

-- Forwarded message -
From: Hauke Mehrtens 
Date: Fri, Jun 9, 2023 at 9:34 AM
Subject: OpenWrt 23.05.0-rc1 first release candidate
To: , OpenWrt Development List



Hi,

The OpenWrt community is proud to announce the first release candidate
of the upcoming OpenWrt 23.05 stable series.
OpenWrt 23.05.0-rc1 incorporates over 3900 commits since branching the
previous OpenWrt 22.03 release and has been under development for over
one year.

This is just a release candidate and not the final release yet.

Download firmware images using the OpenWrt Firmware Selector:
   * https://firmware-selector.openwrt.org/?version=23.05.0-rc1
Download firmware images directly from our download servers:
   * https://downloads.openwrt.org/releases/23.05.0-rc1/targets/


Highlights in OpenWrt 23.05.0:
==

Many new devices added
==

OpenWrt 23.05 supports over 1750 devices. Support for over 160 new
devices was added in addition to the device support by OpenWrt 22.03.

  * The ipq807x target for the Qualcomm IPQ807x Wifi 6 SoCs was added

Highlights of device support


  * Switched ipq40xx target to DSA
  * VDSL support on AVM FRITZ!Box 7530
  * Support for devices with 2.5G PHYs
* Netgear WAX206 (MT7622)
* Asus (TUF Gaming) AX4200 (MT7986A)
* Netgear WAX218 (IPQ8074)
* Xiaomi AX9000 (IPQ8074)
* Dynalink DL-WRX36 (IPQ8074)
  * Improved DSL statistics on ubus and in LuCI


Switch from wolfssl to mbedtls as default
=

OpenWrt switched the default cryptographic library from wolfssl to
mbedtls. This library is used for HTTPS/TLS in the Webserver providing
LuCI and for the cryptographic operations in hostapd. mbedtls provides
security updates in their LTS branch without changing the application
binary interface (ABI) of the library. wolfssl provides a stable ABI
only for a very limited subset of functions. mbedtls allows us to update
only mbedtls without the need to recompile and upgrade all users of mbedtls.


Core components update
==

Core components have the following versions in 23.05.0-rc1:

  * Updated toolchain:
* musl libc 1.2.4
* glibc 2.37
* gcc 12.3.0
* binutils 2.40
  * Updated Linux kernel
* 5.15.114 for all targets
  * Network:
* hostapd master snapshot from March 2023
* dnsmasq 2.89
* dropbear 2022.82
  * cfg80211/mac80211 from kernel 6.1.24
  * System userland:
* busybox 1.36.1

-

Full release notes and upgrade instructions are available at
https://openwrt.org/releases/23.05/notes-23.05.0-rc1

In particular, make sure to read the regressions and known issues before
upgrading:
https://openwrt.org/releases/23.05/notes-23.05.0-rc1#known_issues

For a detailed list of all changes since 22.03.0, refer to
https://openwrt.org/releases/23.05/changelog-23.05.0-rc1

To download the 23.05.0-rc1 images, navigate to:
https://downloads.openwrt.org/releases/23.05.0-rc1/targets/
Use OpenWrt Firmware Selector to download:
https://firmware-selector.openwrt.org/?version=23.05.0-rc1

As always, a big thank you goes to all our active package maintainers,
testers, documenters and supporters.

Have fun!

The OpenWrt Community

---

To stay informed of new OpenWrt releases and security advisories, there
are new channels available:

   * a low-volume mailing list for important announcements:
https://lists.openwrt.org/mailman/listinfo/openwrt-announce

   * a dedicated "announcements" section in the forum:
https://forum.openwrt.org/c/announcements/14

   * other announcement channels (such as RSS feeds) might be added in
the future, they will be listed at https://openwrt.org/contact
___
openwrt-devel mailing list
openwrt-de...@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] nist publishes cybersecurity guidelines

[Dave Taht via Cerowrt-devel]

https://www.nist.gov/system/files/documents/2023/04/24/NIST%20Cybersecurity%20Framework%202.0%20Core%20Discussion%20Draft%204-2023%20final.pdf

-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] industrial lte/wifi router with cake

[Dave Taht via Cerowrt-devel]

The hardware from this company looks sturdy, but that is all I know about it.

https://wiki.teltonika-networks.com/view/RUTX11

https://wiki.teltonika-networks.com/view/RUTX11_Traffic_Shaping

-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] risc-v 2 ethernet port router

[Dave Taht via Cerowrt-devel]

Well, I do not know if it is fq_codel capable. A lot of folk have been
missing on adding in BQL support of late, and as to whether it has the
horsepower to do SQM at these rates is undetermined - I have generally felt
gobs of cache were required to do soft rate shaping.

Secondly, you can always add a 3rd ethernet port via usb nowadays.

As for heat, unknown. I am happy to see risc-v becoming ever more capable,
I do keep hoping we will see a wifi chip built around it.

On Sun, May 7, 2023 at 9:09 AM Michael Richardson  wrote:

> Dave Taht via Cerowrt-devel  wrote:
> >
> https://www.cnx-software.com/2023/05/06/lichee-pi-4a-risc-v-sbc-raspberry-pi-4-th1520-processor/
>
> } Sipeed has just started taking orders for the Lichee Pi 4A (8GB RAM + 8GB
> } flash) for $119.00 on Aliexpress, and the 16GB RAM version is scheduled
> for
> } next month. Additional information can be found on the product page.
>
> It's quite a lot of computer.  The price is not great, but if it's a Gb/s
> fq_codel box you want, then it's probably fine.  I don't really like the
> small form factor as a home router, btw: the cables will be heavier than
> the
> box, and it will all fall on the floor behind the TV, where it will gather
> dust :-)
> I'd want a big hunk of steel that would stay where I put it, and I'm okay
> if it
> also dissipates some heat.
>
>
> Five years ago, I built a dozen OrangePIZero's with two extra USB ethernets
> in a 3D printed box.  So, a total of three ethernets.  I meant to build a
> hundred of them.  The most complex topology one can build with two
> ethernets
> is a circle.  Three ethernets opens one up to all sorts of trees, etc.
> This was for RFC8994 testing.   So I continue to look for ~$20 boxes that
> could easily do more than two ethernets.  I don't need high speed, but it's
> nice to have. I do need auto-MDX, which GbE PHYs all offer.  One reason I
> didn't proceed was that I still haven't gotten beyond what I can do in
> VMs. (i.e. my software is not ready)
> At the time, OpenWRT did not do well with the various switch-port
> extensions
> that got one 4-5 ethernets: they were will custom jobs, but now they are
> mostly all do DSA, so a 12-port Zyxel would seem to satisfy my needs.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works|IoT
> architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
>

-- 
Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] apophis 2029 meeting may 10-12

[Dave Taht via Cerowrt-devel]

Occasionally I abuse my lists to point at my other passions in life. Not
apologizing. Both Jim Gettys and I have been huge asteroid exploration
advocates for years. The Apophis passby in 2029 is a huge opportunity for
good science, and there is an interesting planning meeting for it may 10-12
here, that I hope to sit in on:

https://www.hou.usra.edu/meetings/apophis2023/technical_program/

Very good paper on many possibilities here:
https://www.lpi.usra.edu/sbag/documents/Apophis_SAT.pdf - developing
capabilities that could apply to many other NEOs, rapidly.

I used to hit reload on Lance Benners work on rendezvous costs to the known
NEO population regularly, although this url has now vanished, this is what
those looked like two years go

https://web.archive.org/web/20200303050925/https://echo.jpl.nasa.gov/~lance/delta_v/delta_v.rendezvous.html

Flyby (or impact!) is even cheaper of course:
https://web.archive.org/web/20210131151035/https://echo.jpl.nasa.gov/~lance/delta_v.flyby.html

I wish I knew more about spacecraft busses, cpus and capabilities today!

I return y'all now to worrying about the internet.

-- 
Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] risc-v 2 ethernet port router

[Dave Taht via Cerowrt-devel]

https://www.cnx-software.com/2023/05/06/lichee-pi-4a-risc-v-sbc-raspberry-pi-4-th1520-processor/


-- 
Podcast:
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] openwrt work with ripe

[Dave Taht via Cerowrt-devel]

https://www.ripe.net/about-us/staff/careers-at-the-ripe-ncc/vacancy/274472

-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] docker agents for samknows tests

[Dave Taht via Cerowrt-devel]

https://samknows.com/technology/agents

-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] meshtastic chat over LoRa

[Dave Taht via Cerowrt-devel]

Pretty neat idea. Anyone here fiddling with LoRa?

https://meshtastic.org/2.0

https://matrix.org/blog/2023/04/28/this-week-in-matrix-2023-04-28

-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] APUs EOLed

[Dave Taht via Cerowrt-devel]

https://www.pcengines.ch/eol.htm

These were good boxes. RIP.

-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] can bus attack

[Dave Taht via Cerowrt-devel]

The biggest bug with the early fq_codel deployment was that it dropped
from head and fq'd which led to the prospect of messages sent out of
order on the can protocol, which was not designed for that.. After
much thought, we ended up overriding the default fq_codel qdisc, for a
fifo, for the can bus devices, but there were a few years there where
fq_codel was the default for can, in openwrt, which sometimes keeps me
awake at night.

This set of security bugs is bigger and essentially a message flood
attack on a FIFO, making it possible to steal a car via accessing the
headlamp, using a 10 dollar adaptor. Fascinating reading.

https://kentindell.github.io/2023/04/03/can-injection/


--
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] secure by design and default?

[Dave Taht via Cerowrt-devel]

https://www.washingtonpost.com/politics/2023/04/13/us-launches-secure-software-push-with-new-guidelines/

-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [PATCH] net/sched: sch_qfq: prevent slab-out-of-bounds in qfq_activate_agg

[Dave Taht via Cerowrt-devel]

 888100043180 dead0122

[   84.600764] raw:  80020002 0001

[   84.601009] page dumped because: kasan: bad access detected
[   84.601187]
[   84.601241] Memory state around the buggy address:
[   84.601396]  88810f676800: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   84.601620]  88810f676880: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   84.601845] >88810f676900: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   84.602069]   ^
[   84.602243]  88810f676980: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   84.602468]  88810f676a00: fc fc fc fc fc fc fc fc fc fc fc fc
fc fc fc fc
[   84.602693] 
==
[   84.602924] Disabling lock debugging due to kernel taint

Signed-off-by: Gwangun Jung 
---
 net/sched/sch_qfq.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index cf5ebe43b3b4..02098a02943e 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -421,15 +421,16 @@ static int qfq_change_class(struct Qdisc *sch,
u32 classid, u32 parentid,
} else
weight = 1;

-   if (tb[TCA_QFQ_LMAX]) {
+   if (tb[TCA_QFQ_LMAX])
lmax = nla_get_u32(tb[TCA_QFQ_LMAX]);
-   if (lmax < QFQ_MIN_LMAX || lmax > (1UL << QFQ_MTU_SHIFT)) {
-   pr_notice("qfq: invalid max length %u\n", lmax);
-   return -EINVAL;
-   }
-   } else
+   else
lmax = psched_mtu(qdisc_dev(sch));

+   if (lmax < QFQ_MIN_LMAX || lmax > (1UL << QFQ_MTU_SHIFT)) {
+   pr_notice("qfq: invalid max length %u\n", lmax);
+   return -EINVAL;
+   }
+
inv_w = ONE_FP / weight;
weight = ONE_FP / inv_w;

--
2.34.1



-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] thunderberry

[Dave Taht via Cerowrt-devel]

https://www.tomshardware.com/news/thunderberry5-sbc-to-take-on-raspberry-pi

The circuit diagram does not really show how the 802.11ac wifi is hooked up

-- 
Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] new beaglebone

[Dave Taht via Cerowrt-devel]

Modestly weird to see 10Mbit ethernet making a comeback, and all these
other non-wifi wireless interfaces, and quad-core A53s.

https://beagleboard.org/play

-- 
Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] very good blog on "thread"

[Dave Taht via Cerowrt-devel]

https://framebyframewifi.net/2023/03/02/a-look-at-a-real-world-thread-network/


-- 
Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] USA national security strategy announced

[Dave Taht via Cerowrt-devel]

https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf

at least they mentioned IPV6.

-- 
A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] lan reassignment rfc

[Dave Taht via Cerowrt-devel]

https://forum.openwrt.org/t/rfc-automatic-lan-subnet-reassignment-upon-conflict-with-wan/120938


-- 
A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [tsvwg] CONGRESS is about ready to go

[Dave Taht via Cerowrt-devel]

-- Forwarded message -
From: Martin Duke 
Date: Tue, Feb 21, 2023 at 9:25 AM
Subject: [tsvwg] CONGRESS is about ready to go
To: 


Hello transport enthusiasts,

I'm pleased to announce that all the pieces are in place to move
forward with congress, the working group focused on congestion control
and related topics.

(1) If you haven't already done so, and are interested, please
subscribe to the congress mailing list:
https://www.ietf.org/mailman/listinfo/congress. This is the last time
I'll crosspost (Bcc:) to multiple WG lists, and I encourage others to
stop as well.

(2)  Although the proposed charter has no formal standing at this
time, I'm initiating a "last call". Please have a look and file issues
by the end of this week:
https://github.com/martinduke/congestion-control-charter
The only recent additions to the scope are Fair Queueing and rate
pacing. I'd like to hand this to Zahed, our sponsoring AD, to run
through the IESG process next week.


-- 
A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Amazon ENX driver lacks BQL

[Dave Taht via Cerowrt-devel]

Does anyone out there know how it does the magic it does?

Related question:

https://github.com/amzn/amzn-drivers/issues/262

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] bss coloring

[Dave Taht via Cerowrt-devel]

I am not sure if ANYTHING is using this right yet. What definition of
right is there?

https://www.linkedin.com/feed/update/urn:li:activity:7020947951426428928/


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] really lovely live plots of bandwidth, queue depth, marks and drops in libreqos

[Dave Taht via Cerowrt-devel]

Wearing my theorist hat... and looking at all the ISP plans
https://payne.taht.net is now emulating (click on bandwidth test,
then a plan)

I had never, actually, seen in detail, how cake and fq_codel actually
behave at this range of "plans", starting 2011 with packet captures,
and ns2/ns3 emulations, and mostly working with devices that were
barely capable of pushing 100Mbit, gradually moving up to 1Gbit by
2015 or so. It originally took weeks to get through the packet
captures, then hours to get through and analyze a full range of flent
tests... I'd heard rumors of people pushing cake past 40Gbit, but not
seen anything for myself...

... and now, using herbert's latest rust tooling and his "bifrost" XDP
bridge... and the ebpf pping code with so many contributors... I can
devise a test and watch the results in real time, at a 30ms sample
rate, sufficient, to see slow start, web traffic, voip, and/or other
misbehaviors[1]

To see a shaped cake transparent middlebox *pushing* 10Gbits
successfully (the theory should scale, but cpu requirements at the
time I stopped working on cake (about 5 years ago) were too much to
test with) as I just did just now on a mere 16 core box, was really
amazing. Being able to *measure* real 10Gbit traffic while only eating
30% of one of those cores, is also amazing.

Our debloated future looks brighter every day. The (GPLv2) code for
LibreQos - continues to evolve. Please join in at:
https://github.com/LibreQoE - In particular I'd like to find
someone(s) with rust and/or python experience to help out? And does
anyone have 2.5gbit box they could try? I'm pretty sure a pretty
pedestrian, arm box, should be able to run this at 2.5Gbit, if
xdp/ebpf are available on it. Anyone have tests to suggest?

[1] and so far, the only misbehaviors I've spotted are related to a
syn timeout on one of the more gnarly tests

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: Ethernet switch with linux/openwrt and DSA

[Dave Taht via Cerowrt-devel]

One of the things I find terrifying is knowing that new products are
still being delivered with linux 2.6 underneath.



-- Forwarded message -
From: Janusz Dziedzic 
Date: Thu, Dec 22, 2022 at 8:26 AM
Subject: Re: Ethernet switch with linux/openwrt and DSA
To: Luiz Angelo Daros de Luca 
Cc: Jan Hoffmann , OpenWrt Development List



czw., 22 gru 2022 o 02:24 Luiz Angelo Daros de Luca
 napisał(a):
>
> > Thanks all!
> > Finally buy: D-LINK DGS-1210-48 G1.
> >
> > U-Boot 2011.12.(2.1.5.67086)-Candidate1 (Apr 13 2017 - 13:58:11)
> >
> > Board: RTL839x CPU:700MHz LXB:200MHz MEM:400MHz
> > DRAM:  128 MB
> > SPI-F: 1x32 MB
> >
> > Next:
> >  - connected serial cable
> >  - stop in uboot
> >  - boot from 
> > tftp/openwrt-realtek-rtl839x-d-link_dgs-1210-52-initramfs-kernel.bin
> >  - next simple scp/sysupgrade
> > openwrt-realtek-rtl839x-d-link_dgs-1210-52-squashfs-sysupgrade.bin
>
>
> Great news! Interesting, is it the same model as 1210-52 but with the
> extra ports as non combo? Or are SFP+ still combo ports with 45-48
> ports? Currently 49-52 they are disabled in -52 variant but they might
> introduce a problem if someone gets that fixed and they are missing in
> your device. Ports are statically defined in the DTS file and they
> might brick the device if missing.
>
Ports 49-52 seems to be "shared" I have both eth and sfp ports with
same numbers (btw eth ports 49-52 don't work correctly)

> Did you try the image1 firmware? It should work from the web interface
> but you need to write it to the image1, not image2 slot. If it is that
> close to F1 series, might be able to dual boot the device back to the
> original firmware. If that doesn't work, we might need to change some
> flags in the dlink image generator. Is the original firmware shared
> between -f1 and -g1 series?
>
From original GUI/SW wasn't able to change image1/image2 - only config1/config2.
Because of that decide to run directly from uboout and RAM via tftp -
just to check if will up correctly.
But original SW show double mtds for kernel/rootfs - so maybe only GUI issue?

Linux version 2.6.19 (jonathan@210Server) (gcc version 3.4.4
mipssde-6.03.00-20051020) #2 PREEMPT Fri Oct 6 14:29:30 CST 2017
CPU revision is: 00019555
Determined physical RAM map:
 memory: 0200 @  (usable)
User-defined physical RAM map:
 memory: 0790 @  (usable)
Built 1 zonelists.  Total pages: 30734
Kernel command line: console=ttyS0,115200 mem=121M noinitrd
root=/dev/mtdblock4 rw rootfstype=squashfs csb=0x0157CCD6
cso=0x0794DD64 csf=0x42662D12 sfin=,32MB,8376352;8335392
Primary instruction cache 32kB, physically tagged, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, linesize 32 bytes.
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
Cache parity protection disabled
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 120320k/123904k available (1786k kernel code, 3460k reserved,
393k data, 104k init, 0k highmem)
Mount-cache hash table entries: 512
Checking for 'wait' instruction...  available.
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 4096 bind 2048)
TCP reno registered
squashfs: version 3.3 (2007/10/31) Phillip Lougher
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 1 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x0 (irq = 31) is a 16550A
Probe: SPI CS1 Flash Type MX25L25635F
Creating 9 MTD partitions on "Total SPI FLASH":
0x-0x0008 : "BOOT"
0x0008-0x000c : "BDINFO"
0x000c-0x0010 : "BDINFO2"
0x0010-0x0028 : "KERNEL1"
0x0028-0x00e8 : "ROOTFS1"
0x00e8-0x0100 : "KERNEL2"
0x0100-0x0104 : "SYSINFO"
0x0104-0x01c4 : "ROOTFS2"
0x01c4-0x0200 : "JFFS2"
TCP cubic registered

> I would include a new DTS file/firmware generation, even if it only
> includes/copies -52 variant. It would make the lives of newcomers much
> easier.
>

G1 - have dedicated SW - DGS-1210-48-G1-7-00-B006.hex

BTW, this switch have some issues with IPv6?

Simple remove lan2 from switch/bridge and configure manually - connect
my device directly to eth2 port.
Seems IPv4 works correctly - while IPv6 not (ping6 ff02::1%lan2 - no answer).
Same config (with removed lan2 from bridge) works perfectly with
mt7530 (also dsa) on my mt7621 board.

Or we miss 

[Cerowrt-devel] Fwd: Remote code execution bug in FreeBSD's ping (CVE-2022-23093)

[Dave Taht via Cerowrt-devel]

ping.

-- Forwarded message -
From: Mike Lewinski via NANOG 
Date: Thu, Dec 1, 2022 at 9:16 AM
Subject: Remote code execution bug in FreeBSD's ping (CVE-2022-23093)
To: na...@nanog.org 


Ooof.

https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc

Some hope here: "The ping process runs in a capability mode sandbox on
all affected versions of FreeBSD and is thus very constrainted in how
it can interact with the rest of the system at the point where the bug
can occur."

Lots of other things are based on FreeBSD and may be affected,
including firewalls like pfsense and OPNsense and possibly Junos. At
the least I expect host discovery is ramping up by now.


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] bare metal FOSS program w/equinix

[Dave Taht via Cerowrt-devel]

Equinix has got a nice OSS supporting program going on now, if anyone
has a worthy project (doesn't need to be bloat related)

Sign up via: https://metal.equinix.com/ecosystem/oss/

I'm told there's a bunch of legacy (24 core!) servers to spare:
https://metal.equinix.com/developers/docs/hardware/legacy-servers/

For the first time we have a flent server that can crack 6Gb/sec, probably more.

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [PATCH net-next 4/6] net: ethernet: mtk_eth_soc: implement multi-queue support for per-port queues

[Dave Taht via Cerowrt-devel]

Fq everything

-- Forwarded message -
From: Felix Fietkau 
Date: Wed, Nov 16, 2022, 12:24 AM
Subject: [PATCH net-next 4/6] net: ethernet: mtk_eth_soc: implement
multi-queue support for per-port queues
To: , John Crispin , Sean Wang <
sean.w...@mediatek.com>, Mark Lee , Lorenzo
Bianconi , David S. Miller , Eric
Dumazet , Jakub Kicinski , Paolo
Abeni , Matthias Brugger ,
Russell King 
Cc: , <
linux-media...@lists.infradead.org>, 


When sending traffic to multiple ports with different link speeds, queued
packets to one port can drown out tx to other ports.
In order to better handle transmission to multiple ports, use the hardware
shaper feature to implement weighted fair queueing between ports.
Weight and maximum rate are automatically adjusted based on the link speed
of the port.
The first 3 queues are unrestricted and reserved for non-DSA direct tx on
GMAC ports. The following queues are automatically assigned by the MTK DSA
tag driver based on the target port number.
The PPE offload code configures the queues for offloaded traffic in the same
way.
This feature is only supported on devices supporting QDMA. All queues still
share the same DMA ring and descriptor pool.

Signed-off-by: Felix Fietkau 
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 281 
 drivers/net/ethernet/mediatek/mtk_eth_soc.h |  26 +-
 2 files changed, 258 insertions(+), 49 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 9e5545242216..e1cc813bbb6f 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -55,6 +55,7 @@ static const struct mtk_reg_map mtk_reg_map = {
},
.qdma = {
.qtx_cfg= 0x1800,
+   .qtx_sch= 0x1804,
.rx_ptr = 0x1900,
.rx_cnt_cfg = 0x1904,
.qcrx_ptr   = 0x1908,
@@ -62,6 +63,7 @@ static const struct mtk_reg_map mtk_reg_map = {
.rst_idx= 0x1a08,
.delay_irq  = 0x1a0c,
.fc_th  = 0x1a10,
+   .tx_sch_rate= 0x1a14,
.int_grp= 0x1a20,
.hred   = 0x1a44,
.ctx_ptr= 0x1b00,
@@ -114,6 +116,7 @@ static const struct mtk_reg_map mt7986_reg_map = {
},
.qdma = {
.qtx_cfg= 0x4400,
+   .qtx_sch= 0x4404,
.rx_ptr = 0x4500,
.rx_cnt_cfg = 0x4504,
.qcrx_ptr   = 0x4508,
@@ -131,6 +134,7 @@ static const struct mtk_reg_map mt7986_reg_map = {
.fq_tail= 0x4724,
.fq_count   = 0x4728,
.fq_blen= 0x472c,
+   .tx_sch_rate= 0x4798,
},
.gdm1_cnt   = 0x1c00,
.gdma_to_ppe= 0x,
@@ -614,6 +618,75 @@ static void mtk_mac_link_down(struct phylink_config
*config, unsigned int mode,
mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
 }

+static void mtk_set_queue_speed(struct mtk_eth *eth, unsigned int idx,
+   int speed)
+{
+   const struct mtk_soc_data *soc = eth->soc;
+   u32 ofs, val;
+
+   if (!MTK_HAS_CAPS(soc->caps, MTK_QDMA))
+   return;
+
+   val = MTK_QTX_SCH_MIN_RATE_EN |
+ /* minimum: 10 Mbps */
+ FIELD_PREP(MTK_QTX_SCH_MIN_RATE_MAN, 1) |
+ FIELD_PREP(MTK_QTX_SCH_MIN_RATE_EXP, 4) |
+ MTK_QTX_SCH_LEAKY_BUCKET_SIZE;
+   if (!MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2))
+   val |= MTK_QTX_SCH_LEAKY_BUCKET_EN;
+
+   if (IS_ENABLED(CONFIG_SOC_MT7621)) {
+   switch (speed) {
+   case SPEED_10:
+   val |= MTK_QTX_SCH_MAX_RATE_EN |
+  FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 103) |
+  FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 2) |
+  FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 1);
+   break;
+   case SPEED_100:
+   val |= MTK_QTX_SCH_MAX_RATE_EN |
+  FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 103) |
+  FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 3);
+  FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 1);
+   break;
+   case SPEED_1000:
+   val |= MTK_QTX_SCH_MAX_RATE_EN |
+  FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 105) |
+  FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 4) |
+  FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 10);
+   break;
+   default:
+   break;
+   }
+   } else {
+   switch (speed) {
+   case 

[Cerowrt-devel] r6s looks really really good

[Dave Taht via Cerowrt-devel]

https://www.cnx-software.com/2022/11/12/nanopi-r6s-review-unboxing-teardown-openwrt-22-03-iperf3/

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: Open-source software vs. the proposed Cyber Resilience Act

[Dave Taht via Cerowrt-devel]

-- Forwarded message -
From: Alex Band 
Date: Mon, Nov 14, 2022 at 1:56 AM
Subject: Open-source software vs. the proposed Cyber Resilience Act
To: North American Network Operators' Group 


The NLnet Labs foundation is closely following a legislative proposal by the
European Commission called the Cyber Resilience Act (CRA), affecting almost
all hardware and software offered on the European market.

In the nearby future, manufacturers of toasters, ice cream makers and
(open-source) software will have something in common: to make their products
available on the European market, they will need to affirm their compliance
with EU product legislation by affixing the CE marking.

We have published background information and our views here:

https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/

The current proposal would require developers of open-source software deemed
both ‘critical’ and a ‘commercial activity’ to jump through elaborate and
potentially costly compliance hoops to make their software available in the
EU. What defines a 'critical product' and a 'commercial activity' is key for
this discussion.

Please get in touch with us if you have concerns or this affects you. Maarten
Aertsen  is spearheading this initiative.

Kind regards,

Alex Band
NLnet Labs


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [ih] "The Real Origin of Cisco Systems" by Tom Rindfleisch

[Dave Taht via Cerowrt-devel]

I've written elsewhere about how I tried to take the death and
recycling of the linuxrouter project in stride, (
http://the-edge.blogspot.com/2003/06/wireless-connection.html ), not
quitting in a rage as dave cinege did - and I try not to express, too
often, how hard it has been to get anywhere on improving wifi.

I didn't know this history of cisco. Perversely, I feel better.

-- Forwarded message -
From: the keyboard of geoff goodfellow via Internet-history

Date: Wed, Nov 2, 2022 at 9:33 AM
Subject: [ih] "The Real Origin of Cisco Systems" by Tom Rindfleisch
To: Internet-history 


EXCERPT:

The following account of the real origins of Cisco Systems, as opposed to
the history often recounted in Cisco company literature, was written in
1999 by Tom Rindfleisch. Rindfleisch was Director of the SUMEX-AIM project
(1973-1990), under which the software for a powerful Internet router system
was developed and widely deployed at Stanford and elsewhere for research
purposes. That code found its way, without approval from the original
developers, to form the basis of the Cisco router...

Tom Rindfleisch
Last updated April 8, 1999

[...]
https://www.tcracs.org/tcrwp/1origin-of-cisco/

--
geoff.goodfel...@iconia.com
living as The Truth is True
--
Internet-history mailing list
internet-hist...@elists.isoc.org
https://elists.isoc.org/mailman/listinfo/internet-history


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] QDISC_DROP_REASON project

[Dave Taht via Cerowrt-devel]

There were, at last count, 2600+ places where packets could be dropped
in the linux kernel, and that doesn't account for just dropping
packets at the physical layer and (I don't think) on the rx ring.
DROP_REASON support has been migrating into the kernel, but not yet
for qdiscs, and were it there, it would provide a convenient
tracepoint for why it happened, be it congestive, overflow, or self
defense.

You can pull apart the packets and see where they were going or where
they came from, and so on.

And it's kind of bad to be dropping packets for any other reason,
elsewhere in the system.

Similarly I am seeing a LOT of ecn marking in the field that I am not
sure is correct or not, and there's not a good way to track that
presently.

I had a student lined up for this, but she dropped out. I'd much
rather teach someone how to do this pretty basic job inside the kernel
than do it myself, so if you know anyone with even modest kernel
skills willing to take it on with me, I'd appreciate it.

- https://github.com/rchac/LibreQoS/issues/143

On Fri, Oct 28, 2022 at 1:12 PM Dave Taht  wrote:
>
> There is a ton of grant money going around, and various funds are
> closing at the end of this month or the next. If you know talented
> people that are being laid off, or just want to practice their craft
> in any way to make for a better internet, please pass these links
> along. If you know of any other funding sources, please post? I'd like
> to get a stable floor back under make-wifi-fast in particular, and
> find folk willing to fund or help out (and test) on the libreqos.io
> project.
>
> NLNET is eu only and has two funds focused on privacy and security.
> They are typically good for 30-50k eu and run for a year, a very short
> (3 pages or less) application flies well with them. Closing december 1st:
>
> https://nlnet.nl/assure/
> https://nlnet.nl/entrust/
>
> NLNET has been a huge supporter of bufferbloat.net over the years,
> most recently funding my "cerowrt ii" project, which was a
> constructive failure, in that I lost way too much time to dealing with
> regressions in the stack to make the slightest bit of forward
> progress.
>
> In germany there' s this:
>
> https://forum.openwrt.org/t/germanys-sovereign-tech-fund/141089
>
> And in america, ARDC is very focused on wireless applications.
>
> https://www.ampr.org/grants/
>
> The NSF POSE grants program just closed (we didn't qualify), pouring
> 21m into various open source orgs, or so I hope.
>
> --
> This song goes out to all the folk that thought Stadia would work:
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
> Dave Täht CEO, TekLibre, LLC



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] grant funding avail for various open source projects

[Dave Taht via Cerowrt-devel]

There is a ton of grant money going around, and various funds are
closing at the end of this month or the next. If you know talented
people that are being laid off, or just want to practice their craft
in any way to make for a better internet, please pass these links
along. If you know of any other funding sources, please post? I'd like
to get a stable floor back under make-wifi-fast in particular, and
find folk willing to fund or help out (and test) on the libreqos.io
project.

NLNET is eu only and has two funds focused on privacy and security.
They are typically good for 30-50k eu and run for a year, a very short
(3 pages or less) application flies well with them. Closing december 1st:

https://nlnet.nl/assure/
https://nlnet.nl/entrust/

NLNET has been a huge supporter of bufferbloat.net over the years,
most recently funding my "cerowrt ii" project, which was a
constructive failure, in that I lost way too much time to dealing with
regressions in the stack to make the slightest bit of forward
progress.

In germany there' s this:

https://forum.openwrt.org/t/germanys-sovereign-tech-fund/141089

And in america, ARDC is very focused on wireless applications.

https://www.ampr.org/grants/

The NSF POSE grants program just closed (we didn't qualify), pouring
21m into various open source orgs, or so I hope.

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] 50 dollar x86 board

[Dave Taht via Cerowrt-devel]

I think I just found my new audio server.

https://ameridroid.com/products/atomic-pi

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: OpenWrt 22.03.2 second service release

[Dave Taht via Cerowrt-devel]

it is so wonderful how fast openwrt can respond to a zero-day.

-- Forwarded message -
From: Hauke Mehrtens 
Date: Mon, Oct 17, 2022 at 1:22 PM
Subject: OpenWrt 22.03.2 second service release
To: , OpenWrt Development List



Hi,

The OpenWrt community is proud to announce the newest stable release of
the OpenWrt 22.03 stable version series. It fixes security issues,
improves device support, and brings a few bug fixes.

Download firmware images using the OpenWrt Firmware Selector:
  * https://firmware-selector.openwrt.org/?version=22.03.2
Download firmware images directly from our download servers:
  * https://downloads.openwrt.org/releases/22.03.2/targets/


Main changes between OpenWrt 22.03.1 and OpenWrt 22.03.2:


Security fixes
==

  * mac80211/cfg80211: Security fixes for BSSID parsing
(CVE-2022-41674, CVE-2022-42719, CVE-2022-42720, CVE-2022-42721 and
 CVE-2022-42722)
* See Security Advisory 2022-10-17-1
* https://openwrt.org/advisory/2022-10-17-1


Device support
==

  * Support for the following devices was added:
* ZyXEL NWA50AX / NWA55AXE (ramips)
  * ramips/mediatek: backport NAND flash driver from master
  * mpc85xx: p1010: make TP-Link WDR4900 v1 build again


Various fixes and improvements
==

  * busybox: nslookup: Fix wrongly dropped DNS response on some platforms


Core components update
==

  * Update rpcd from 2022-08-24 to 2022-09-21
  * Update ucode from 2022-08-29 to 2022-10-07
  * Update firewall4 from 2022-09-01 to 2022-10-14


-

Full release notes and upgrade instructions are available at
https://openwrt.org/releases/22.03/notes-22.03.2

In particular, make sure to read the regressions and known issues before
upgrading:
https://openwrt.org/releases/22.03/notes-22.03.2#known_issues

For a detailed list of all changes since 22.03.1, refer to
https://openwrt.org/releases/22.03/changelog-22.03.2

To download the 22.03.1 images, navigate to:
https://downloads.openwrt.org/releases/22.03.2/targets/
Use OpenWrt Firmware Selector to download:
https://firmware-selector.openwrt.org/?version=22.03.2

As always, a big thank you goes to all our active package maintainers,
testers, documenters and supporters.

Have fun!

The OpenWrt Community

---

To stay informed of new OpenWrt releases and security advisories, there
are new channels available:

  * a low-volume mailing list for important announcements:
https://lists.openwrt.org/mailman/listinfo/openwrt-announce

  * a dedicated "announcements" section in the forum:
https://forum.openwrt.org/c/announcements/14

  * other announcement channels (such as RSS feeds) might be added in the
future, they will be listed at https://openwrt.org/contact

___
openwrt-devel mailing list
openwrt-de...@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] xmit_more?

[Dave Taht via Cerowrt-devel]

Did xmit_more basically end up on everything, or get subsumed by something else?

Recently we got bql up on the very impressive mvpp2 chip, and I am
wondering what other more modern chips were missed.

This was a good walk through memory lane:

https://lwn.net/Articles/615238/

-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] OTA exploitable wifi bugs

[Dave Taht via Cerowrt-devel]

They only shipped openwrt 22.03.1 yesterday...

On Thu, Oct 13, 2022 at 12:04 PM Etienne Champetier
 wrote:
>
> Fixes already commited by Felix Fietkau in master and 22.03
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=26f400210d6b3780fcc0deb89b9741837df9c8b8
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=f1de43d0a045a154c74281bc60bf1c44c990071b
>
> Le jeu. 13 oct. 2022 à 13:14, Dave Taht via Cerowrt-devel
>  a écrit :
> >
> > yuck. 0 days suck. Why couldn't they have sat on this for a while?
> >
> > On Thu, Oct 13, 2022 at 9:59 AM Matt Taggart via Cerowrt-devel
> >  wrote:
> > >
> > > https://www.openwall.com/lists/oss-security/2022/10/13/2
> > >
> > > Presumably openwrt and other router firmwares (FOSS and proprietary)
> > > will be effected?
> > > Also android and maybe TVs, etc? That's a whole lot of devices.
> > >
> > > Lots of updating in our futures... maybe this will help get newer SQM
> > > rolled out more (but maybe not enabled by default).
> > >
> > > Sorry, this is probably my fault, I just updated a bunch of stuff last
> > > night (after I washed my car causing it to rain).
> > >
> > > --
> > > Matt Taggart
> > > m...@lackof.org
> > > ___
> > > Cerowrt-devel mailing list
> > > Cerowrt-devel@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> >
> >
> > --
> > This song goes out to all the folk that thought Stadia would work:
> > https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
> > Dave Täht CEO, TekLibre, LLC
> > ___
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] OTA exploitable wifi bugs

[Dave Taht via Cerowrt-devel]

yuck. 0 days suck. Why couldn't they have sat on this for a while?

On Thu, Oct 13, 2022 at 9:59 AM Matt Taggart via Cerowrt-devel
 wrote:
>
> https://www.openwall.com/lists/oss-security/2022/10/13/2
>
> Presumably openwrt and other router firmwares (FOSS and proprietary)
> will be effected?
> Also android and maybe TVs, etc? That's a whole lot of devices.
>
> Lots of updating in our futures... maybe this will help get newer SQM
> rolled out more (but maybe not enabled by default).
>
> Sorry, this is probably my fault, I just updated a bunch of stuff last
> night (after I washed my car causing it to rain).
>
> --
> Matt Taggart
> m...@lackof.org
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: OpenWrt 21.02.4 fourth service release

[Dave Taht via Cerowrt-devel]

Both the current and prior openwrt releases had some CVEs. If you are
running the gui, you should upgrade...

I just turn the darn gui off, myself. I don't think but am unsure, if
these cve's effect ssh at all.

-- Forwarded message -
From: Hauke Mehrtens 
Date: Wed, Oct 12, 2022 at 3:22 PM
Subject: OpenWrt 21.02.4 fourth service release
To: , OpenWrt Development List



Hi,

The OpenWrt community is proud to announce the newest stable release of
the OpenWrt 21.02 stable version series. It fixes security issues,
improves device support, and brings a few bug fixes.

Download firmware images using the OpenWrt Firmware Selector:
  * https://firmware-selector.openwrt.org/?version=21.02.4
Download firmware images directly from our download servers:
  * https://downloads.openwrt.org/releases/21.04.4/targets/

The OpenWrt 21.02 stable series is in security maintenance only mode. It
is projected to go end of life on 6. April 2023 following the OpenWrt
Security support guidelines. We encourage all users of the OpenWrt 21.02
stable series to upgrade to OpenWrt 22.03.
https://openwrt.org/docs/guide-developer/security#support_status


Main changes between OpenWrt 21.02.3 and OpenWrt 21.02.4:


Security fixes
==

  * wolfssl: Fix security problem (CVE-2022-34293, CVE-2022-38152,
   CVE-2022-38153 and CVE-2022-39173)
* See Security Advisory 2022-10-04-1
  * zlib: Fix security problem (CVE-2022-37434)
  * openssl: Fix security problem (CVE-2022-1292, CVE-2022-2068 and
   CVE-2022-2097)


Device support
==

  * Support for the following devices was added:
* Wavlink WL-WN579X3
* Sitecom WLR-4100 v1 002
* Banana Pi M2 Berry
* YunCore AX820/HWAP-AX820
* MikroTik RouterBOARD hAP ac lite
* MikroTik RouterBOARD mAP
  * Youku YK1: speed up spi frequency for YK-L1, split YK1 to YK-L1
and YK-L1c
  * ZBTLink ZBT-WG2626: add reset GPIO for PCIe port 1
  * ZBTLink ZBT-WE1026 5G: fix watchdog reset
  * Asus RT-AC57U: fix WPS button level
  * Archer VR2600: fix switch ports numbering
  * ZyXEL NBG-419N v2: Fix booting
  * Linksys MR8300: add WAN port
  * ramips: several fixes and improvements to mt7620 Ethernet
  * bcm53xx:
* Disable GRO by default at kernel level
* Enable & setup packet steering
  * ipq40xx: fix ar40xx driver
  * bcm4908:
* Enable NVMEM U-Boot env data driver
* Backport mtd parser for Broadcom's U-Boot partition
* fix -EPROBE_DEFER support in bcm4908_enet


Various fixes and improvements
==

  * kernel:
* Fix IPv6 flow offloading (FS#3373)
* Backport LEDs driver for BCMBCA devices
* Backport mtd dynamic partition patch
* Fix possible mtd NULL pointer dereference
  * mac80211: fix QCA9561 PA bias
  * mac80211: disable ft-over-ds by default
  * mt76: backport fix encap offload ethernet type check
  * hostapd fixes and improvements:
* Add support for enabling link measurements
* Fix uninitialized pointer
  * zlib: backport null dereference fix
  * build system:
* Switch from xxd tool to xxdi.pl script
* Check TLS certificates by default when downloading over HTTPS
* feeds: use git-src-full to allow Git versioning
* Fix build warnings with grep-3.8
* Add compatibility with Python 3.11


Core components
===

  * Update Linux kernel from 5.4.188 to 5.4.215
  * Update openssl from 1.1.1n to 1.1.1q
  * Update wolfssl from 5.2.0 to 5.5.1
  * Update wireless-regdb from 2021.08.28 to 2022.08.12
  * Update intel-microcode from 20210608 to 20220809
  * Update exfat from 5.12.3 to 5.19.1
  * Update iwinfo from 2021-04-30 to 2022-04-26

-

Full release notes and upgrade instructions are available at
https://openwrt.org/releases/21.02/notes-21.02.4

In particular, make sure to read the regressions and known issues before
upgrading:
https://openwrt.org/releases/21.02/notes-21.02.4#known_issues

For a detailed list of all changes since 21.02.3, refer to
https://openwrt.org/releases/21.02/changelog-21.02.4

To download the 21.02.4 images, navigate to:
https://downloads.openwrt.org/releases/21.02.4/targets/
Use OpenWrt Firmware Selector to download:
https://firmware-selector.openwrt.org/?version=21.02.4

As always, a big thank you goes to all our active package maintainers,
testers, documenters and supporters.

Have fun!

The OpenWrt Community

---

To stay informed of new OpenWrt releases and security advisories, there
are new channels available:

  * a low-volume mailing list for important announcements:
https://lists.openwrt.org/mailman/listinfo/openwrt-announce

  * a dedicated "announcements" section in the forum:
https://forum.openwrt.org/c/announcements/14

  * other announcement channels (such as RSS feeds) might be added in the
future, they will be listed at https://openwrt.org/contact

[Cerowrt-devel] bcp38 + nftables

[Dave Taht via Cerowrt-devel]

I didn't clear the time to tackle this. I can get around to it in a
month or two, I think. Anyone actively using this and available to
test?

https://github.com/openwrt/packages/issues/16818

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/stacerte_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: OpenWrt 22.03.0 first stable release

[Dave Taht via Cerowrt-devel]

openwrt is our primary platform for developing and deploying new
network tech in general.

An ancient 10 year old release of openwrt was used in the first
starlink router, and a 7 year old release
in the 2nd generation one. I keep hoping they will get caught up in a
year or two more , which would help especially with their ipv6 and
bufferbloat problems.

Anyway... stablizing "my" (mostly wifi) bits of this release just cost
me 6 months of life, and
in the end we settled for stability more than performance. With that
goal achieved, we'been making progress over here -
https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/901

and we're always looking for more testers of the cake adaptive
bandwidth stuff on 5g and starlink, which hit 1.0:
https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/135379

For more details about this release see below, or take the plunge and
reflash an old router and give it to a friend that needs it. 1500+
routers are supported!

My thanks to all the thousands of volunteers and corporations that
make this enormous exercise in making hundreds of millions of lines of
code fly in less loose formation.

-- Forwarded message -
From: Hauke Mehrtens 
Date: Mon, Sep 5, 2022 at 4:30 PM
Subject: OpenWrt 22.03.0 first stable release
To: , 


Hi,

The OpenWrt community is proud to announce the first stable release of
the OpenWrt 22.03 stable version series. It incorporates over 3800
commits since branching the previous OpenWrt 21.02 release and has been
under development for about one year.

Download firmware image for your device (firmware selector):
  * https://firmware-selector.openwrt.org/?version=22.03.0
Download firmware images directly from OpenWrt download servers:
  * https://downloads.openwrt.org/releases/22.03.0/targets/


Highlights in OpenWrt 22.03.0
=

Firewall4 based on nftables
===
Firewall4 is used by default, superseding the iptables-based firewall3
implementation in the OpenWrt default images. Firewall4 uses nftables
instead of iptables to configure the Linux netfilter ruleset.

Firewall4 keeps the same UCI firewall configuration syntax and should
work as a drop-in replacement for fw3 with most common setups, emitting
nftables rules instead of iptables ones.

Including custom firewall rules through /etc/firewall.user still works,
but requires marking the file as compatible first, otherwise it is
ignored. Firewall4 additionally allows to include nftables snippets. The
firewall documentation
https://openwrt.org/docs/guide-user/firewall/firewall_configuration
explains how to include custom firewall rules with firewall4. Some
community packages that add firewall rules might not work for now, and
will need to be adapted to fw4: this will happen gradually throughout
the lifetime of the 22.03 release series.

The legacy iptables utilities are not included in the default images
anymore, but can be added back using opkg or the Image Builder if
needed. The transitional packages iptables-nft, arptables-nft,
ebtables-nft and xtables-nft can be used to create nftables rules using
the old iptables command line syntax.

Many new devices added
==
OpenWrt 22.03 supports over 1580 devices. Support for over 180 new
devices was added in addition to the device support by OpenWrt 21.02.
OpenWrt 22.03 supports more than 15 devices capable of Wifi 6 (IEEE
802.11ax) using the MediaTek MT7915 wifi chip.

More targets converted to DSA
=
The following targets or boards were migrated from swconfig to DSA with
OpenWrt 22.03 in addition to the systems already migrated with OpenWrt
21.02:

  * bcm53xx: All board using this target were converted to DSA
  * lantiq: All boards using the xrx200 / vr9 SoC
  * sunxi: Bananapi Lamobo R1 (only sunxi board with switch)

Dark mode in LuCI
=
The LuCI bootstrap design supports a dark mode. The default design
activates dark mode depending on the browser settings. Change it
manually at “System” -> “System” -> “Language and Style”.

Year 2038 problem handled
=
OpenWrt 22.03 uses musl 1.2.x, which changed the time_t type from 32 bit
to 64 bit on 32 bit systems, on 64 bit system it was always 64 bit long.
When a Unix time stamp is stored in a signed 32 bit integer it will
overflow on 19 January 2038. With the change to 64 bit this will happen
292 billion years later. This is a change of the musl libc ABI and needs
a recompilation of all user space applications linked against musl libc.
For 64 bit systems this was done when the ABI was defined many years
ago, the glibc ARC ABI already has a 64 bit time_t.

Core components update
==
Core components have the following versions in 22.03.0:

  * Updated toolchain:
* musl libc 1.2.3
* glibc 2.34
* gcc 11.2.0
* binutils 2.37
  * Updated Linux kernel
* 5.10.138 for all targets
  * Network:
* hostapd 2.10, dnsmasq 2.86, 

[Cerowrt-devel] openstick lte quad core

[Dave Taht via Cerowrt-devel]

https://hackaday.com/2022/08/03/hackable-20-modem-combines-lte-and-pi-zero-w2-power/
-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] binary blobs struck again

[Dave Taht via Cerowrt-devel]

lack of trust in turtles all the way own.

https://www.bleepingcomputer.com/news/security/exploit-out-for-critical-realtek-flaw-affecting-many-networking-devices/

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Reaching out to Greg KH for 6 year LTS kernel versions

[Dave Taht via Cerowrt-devel]

I am not on the openwrt-devel list from this acct... I tried to
resubscribe but its taking too long...

On Wed, Aug 10, 2022 at 1:29 PM Philip Prindeville
 wrote:
>
> Not to play the devil's advocate but... do we want old kernels hanging out 
> that long?

People are still shipping 3.3 kernels.

> Besides not encouraging people to update to new releases that mitigate 
> discovered CVE's, we'd also not pick up David Taht's excellent improvements 
> in Buffer Bloat.

People keep giving me too much credit. There have been dozens of core
contributors to this effort, 1000s of others, and we have billions of
machines (not enough routers, tho!)  now doing more of the right
things. I haven't made a technical contribution in years. I( got a
couple new things that I'd like to work on, but no funding). What was
once a 5-7 lag in embedded from devel to distribution now seems closer
to 10.

I've gone political in search of finding ways to get bufferbloat fixes
out there. Somehow convincing the world that in addition to burning
billions on fiber buildouts ISPs should be supplying better routers
has been a big goal, and I'm low on ideas on how to move forward on
that.

Certainly finding some way to get openwrt shippers like starlink to at
least  plan to upgrade to a modern openwrt rather than continue to
ship LEDE is very desirable... 6 year old kernels at FCS noo...

I thought ooka's new speedtest (which measures responsiveness on
up/downloads now) would provide a tipping point. Certainly also
preseem and libreqos are making an impact in the smaller ISP
markets...

In the last 6 months of coping with a string of regressions in
openwrt's wifi[1], I've reflected on the waddington effect a lot. If
you haven't heard of it, it applies a string of criteria to how and
why you o prevenntative maintenence on airplanes:

https://resources.savvyaviation.com/wp-content/uploads/articles_eaa/EAA_2011-03_the-waddington-effect.pdf

As for 6 years on a LTS kernel, my instinct is NO! Progress MUST
be made! We must keep working towards making kernel upgrades
continuous and easy. But think deeply on the waddington effect.

The cold and bitter reality though is if someone is willing to pay
someone(s) to maintain a kernel for that long, and it keeps up with
major security issues, it's no skin off our backs. I would prefer cash
be injected into better review ( there are 1500 open issues and 300+
outstanding https://github.com/openwrt/openwrt/pulls right now), we
found ways to attract, train, and retain good developers in "the FOSS
way", and more companies and governments using openwrt found ways to
support those, and "sufficiently rapid" change in the ever more
fossilized FOSS ecosystem.


[1] https://www.linkedin.com/feed/update/urn:li:activity:6963337312596369408/


>
> > On Aug 8, 2022, at 5:15 PM, Florian Fainelli  wrote:
> >
> > Hi,
> >
> > Greg KH has communicated a few times before on his blog [1] that he is 
> > seeking the help of individuals and company to help him maintain the LTS 
> > kernels and allow them to be made 6 years instead of just the usual 2 years.
> >
> > 5.10 is a 6 year LTS, but 5.15 is not listed as such, although it certainly 
> > would make sense for it to be since we use 5.15 in OpenWrt.
> >
> > It would be good for the project to have a designated contact who can 
> > communicate the kernel version plan ahead of time, or once a LTS is picked 
> > up, we could sign up people to do regular testing of the stable release 
> > candidates?
> >
> > Thoughts?
> >
> > [1]: 
> > http://kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/
> > --
> > Florian
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-de...@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>


--
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] turris omnia project fails to spin up and out

[Dave Taht via Cerowrt-devel]

I *really liked* the omnia.  Perhaps the last of its kind.

https://www.linkedin.com/feed/update/urn:li:activity:6962405304235913216/

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] openwrt-22-03-rc6 released

[Dave Taht via Cerowrt-devel]

It's my hope that the last of the major wifi bugs plaguing openwrt
have been quashed. Please test.

https://forum.openwrt.org/t/openwrt-22-03-0-rc6-sixth-release-candidate/133673

Especially if you are using the ath10k, 9k, or mt76 chips. For some
suggested tests see:

https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/830

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] 150ps 48 ports and FPGA

[Dave Taht via Cerowrt-devel]

So much cool hardware. so little time

https://ldatech.com/Platforms/NEO


-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] mqprio shaper for fq_codel

[Dave Taht via Cerowrt-devel]

I didn't know mqprio could shape now, at least on some hw.

https://lore.kernel.org/netdev/20220727181039.19c76...@kernel.org/T/

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] battlemesh conference sept 19-22 in Rome

[Dave Taht via Cerowrt-devel]

I am giving a talk tentatively entitled "the meshy mess". This is a
pretty good technical conference consisting of a lot of core wifi
(openwrt), hackerspace, and community network people, and run on the
cheap, and one of the few routing interop events that exists. Hope to
see some of you in person! (In particular, they really, really want to
find a speaker - not me! - to talk deeply about starlink)

Call for Participation see:
https://www.battlemesh.org/BattleMeshV14/Talk_proposals


Topics:

Wireless Community Networks
Mesh Routing Protocol Development
Free hardware and free software for Community Networks
Community Networks that deploy Fiber-to-the-Home (FTTH) networks
TV white space as a precious network resource (radio spectrum)
How to organize a durable community structure?
How to involve non-technical people? To "digital stewardship" and beyond?
How to disseminate the spirit of community networks, knowledge etc?
Connecting rural areas: challenges and solutions
Public fiber networks: architecture, funding, private actors involved, oversight
Internet of Things (IoT) networks and their impact on society
Local Internet Exchange Points (IXPs) as a common infrastructure



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] netflix seeks low latency engineer

[Dave Taht via Cerowrt-devel]

https://jobicy.com/jobs/12345-sr-software-engineer-full-stack



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [PATCH net] pktgen: Fix the inaccurate bps calculation

[Dave Taht via Cerowrt-devel]

heh. Fastest way to change the observed speed of the internet I've yet seen.

-- Forwarded message -
From: 
Date: Fri, Jul 8, 2022 at 8:51 AM
Subject: [PATCH net] pktgen: Fix the inaccurate bps calculation
To: , , ,
, 
Cc: , Gao Feng 


From: Gao Feng 

The prior codes use 100 as divisor to convert to the Mbps. But it isn't
accurate, because the NIC uses 1024*1024 from bps to Mbps. The result of
the codes is 1.05 times as the real value, even it may cause the result is
more than the nic's physical rate.

Signed-off-by: Gao Feng 
---
 net/core/pktgen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 84b62cd7bc57..e5cd3da63035 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3305,7 +3305,7 @@ static void show_results(struct pktgen_dev
*pkt_dev, int nr_frags)
}

mbps = bps;
-   do_div(mbps, 100);
+   do_div(mbps, 1024 * 1024);
p += sprintf(p, "  %llupps %lluMb/sec (%llubps) errors: %llu",
 (unsigned long long)pps,
 (unsigned long long)mbps,
--
2.20.1



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] SONIC?

[Dave Taht via Cerowrt-devel]

I wonder how much of the datapath sonic can reach into

https://www.nextplatform.com/2020/05/12/is-microsofts-sonic-winning-the-war-of-the-noses/
-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] operating system noise in the linux kernel

[Dave Taht via Cerowrt-devel]

Measuring operating system noise more effectively is often on my mind.

https://bristot.me/operating-system-noise-in-the-linux-kernel/

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] google pivots to an open access model

[Dave Taht via Cerowrt-devel]

https://www.telecompetitor.com/google-fiber-embracing-open-access-model-to-reach-everyone/

I sure hope they ship quality CPE.

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [PATCH v2 2/2] igb: Make DMA faster when CPU is active on the PCIe link

[Dave Taht via Cerowrt-devel]

I have sometimes wondered if it were possible to speed up the apu2 more.

-- Forwarded message -
From: Kai-Heng Feng 
Date: Wed, May 25, 2022 at 2:03 PM
Subject: [PATCH v2 2/2] igb: Make DMA faster when CPU is active on the PCIe link
To: , 
Cc: , Kai-Heng Feng
, David S. Miller ,
Eric Dumazet , Jakub Kicinski ,
Paolo Abeni , Jeff Kirsher
, Carolyn Wyborny
, ,
, 


Intel I210 on some Intel Alder Lake platforms can only achieve ~750Mbps
Tx speed via iperf. The RR2DCDELAY shows around 0x2xxx DMA delay, which
will be significantly lower when 1) ASPM is disabled or 2) SoC package
c-state stays above PC3. When the RR2DCDELAY is around 0x1xxx the Tx
speed can reach to ~950Mbps.

According to the I210 datasheet "8.26.1 PCIe Misc. Register - PCIEMISC",
"DMA Idle Indication" doesn't seem to tie to DMA coalesce anymore, so
set it to 1b for "DMA is considered idle when there is no Rx or Tx AND
when there are no TLPs indicating that CPU is active detected on the
PCIe link (such as the host executes CSR or Configuration register read
or write operation)" and performing Tx should also fall under "active
CPU on PCIe link" case.

In addition to that, commit b6e0c419f040 ("igb: Move DMA Coalescing init
code to separate function.") seems to wrongly changed from enabling
E1000_PCIEMISC_LX_DECISION to disabling it, also fix that.

Fixes: b6e0c419f040 ("igb: Move DMA Coalescing init code to separate function.")
Signed-off-by: Kai-Heng Feng 
---
 drivers/net/ethernet/intel/igb/igb_main.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 68be2976f539f..c0d93fd19c1ed 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -9898,11 +9898,10 @@ static void igb_init_dmac(struct igb_adapter
*adapter, u32 pba)
struct e1000_hw *hw = >hw;
u32 dmac_thr;
u16 hwm;
+   u32 reg;

if (hw->mac.type > e1000_82580) {
if (adapter->flags & IGB_FLAG_DMAC) {
-   u32 reg;
-
/* force threshold to 0. */
wr32(E1000_DMCTXTH, 0);

@@ -9935,7 +9934,6 @@ static void igb_init_dmac(struct igb_adapter
*adapter, u32 pba)
/* Disable BMC-to-OS Watchdog Enable */
if (hw->mac.type != e1000_i354)
reg &= ~E1000_DMACR_DC_BMC2OSW_EN;
-
wr32(E1000_DMACR, reg);

/* no lower threshold to disable
@@ -9952,12 +9950,12 @@ static void igb_init_dmac(struct igb_adapter
*adapter, u32 pba)
 */
wr32(E1000_DMCTXTH, (IGB_MIN_TXPBSIZE -
 (IGB_TX_BUF_4096 + adapter->max_frame_size)) >> 6);
+   }

-   /* make low power state decision controlled
-* by DMA coal
-*/
+   if (hw->mac.type >= e1000_i210 ||
+   (adapter->flags & IGB_FLAG_DMAC)) {
reg = rd32(E1000_PCIEMISC);
-   reg &= ~E1000_PCIEMISC_LX_DECISION;
+   reg |= E1000_PCIEMISC_LX_DECISION;
wr32(E1000_PCIEMISC, reg);
} /* endif adapter->dmac is not disabled */
} else if (hw->mac.type == e1000_82580) {
--
2.34.1



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] A VLIW returns

[Dave Taht via Cerowrt-devel]

I still like vliws.But I find it hard to imagine how to keep this
beast fed. The L1 cache cannot possibly be big enough...

https://www.tomshardware.com/news/tachyum-teases-128-core-cpu-57-ghz-950w-16-ddr5-channels

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] DMARC policy change fix for lists.bufferbloat.net

[Dave Taht via Cerowrt-devel]

Over the past year or three the DMARC policy change to how mailing
lists were handled have been propagating across the net. I wasn't
paying attention. A lot of people have been auto-unsubscribed over the
last few months. I'm still working on improving the DMARC policy
here... and this is a test message of munging replies differently...

The bloat mailing list, which at its peak was above 550 people, is now
down to around 350, and for all I know the DMARC classifiers have been
tossing all the email that remains into your spam folders. If you've
been missing all the exciting, innovative debloating activity across
so many aspects of our project - the iab workshop last sept for
example, the new speedtest.net app, the improvements to wifi, news on
the latest broadband activities, etc, etc, our mailing list archives,
would be a good place to look to see when these problems really
started.

IF you have been missing emails from this domain, please contact me
privately so I can look over the logs. There's at least 3 different
behaviors happening - rejections, which is what I noticed, but 250
quarantine I had not, until today, and something that I cannot
describe, only curse at, as yet.

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] open sourcing more hardware designs

[Dave Taht]

https://hardware.slashdot.org/story/22/06/04/2356258/googles-plan-to-make-chip-development-more-like-open-source-software

I note that I was a big fan of te mill because of how wide it was. I
still have not the foggiest idea how to go about doing sane things
with packets at +100Gbps.

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] 2.5gbit for $59

[Dave Taht]

"LAN – 2x 2.5GbE RJ45 ports (via 2x Realtek RTL8125BG PCIe controller)
tested up to 2.35 Gbps (Rx) and 1.85 Gbps (Tx)
WAN – 1x Gigabit Ethernet RJ45 port (via Realtek RTL8211F) tested up
to 941 Mbps (Tx and Rx)"

My guess is - none of these at the same time. Still... $59!


https://www.cnx-software.com/2022/05/30/buy-nanopi-r5s-rockchip-rk3568-mini-router-sbc/


-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Minirouter with pi compute module 4

[Dave Taht]

I am sadly re-discovering there is not a single device on the market
outside the x86 universe that can actually forward a gbit in both
directions at the same time.


On Thu, May 19, 2022 at 1:36 PM Matt Taggart  wrote:
>
> This looks like an interesting router candidate
>
> https://www.seeedstudio.com/Dual-GbE-Carrier-Board-with-4GB-RAM-32GB-eMMC-RPi-CM4-Case-p-5029.html
>
> Description says:
> * one NIC is Broadcom BCM54210PE (from the CM4)
> * the other is "Microchip's LAN7800" behind usb3
> * 2 additional usb3 ports
> * the usb3 uses the CM4's PCIe 2.0 x1 (500MB/s)
> * wifi/BLE is the CM4's onboard, I think "Cypress CYW43455"?
>
> It sort of reminds me of the Espressobin device from a few years back,
> but much faster and the pi has a much larger installed base, better
> support, etc.
>
> --
> Matt Taggart
> m...@lackof.org
> ___
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] CFP for critical software

[Dave Taht]

I am, in general, tired of giving more than two talks a year, but this
one is far enough off to consider. That said, I do wish
more here stepped up to step up to the podium on any of these topics.
My time in this world is increasingly passed, and it's your internet
now.

https://linuxfoundation.smapply.io/prog/oss_eu_22/

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] 10 pts for more secure open source

[Dave Taht]

very happy to see this land today. Yesterday the new speedtest. Today,
also, landed the new NOLO program for 44B in broadband funds.

https://www.linuxfoundation.org/press-release/linux-foundation-openssf-gather-industry-government-leaders-open-source-software-security-summit/


-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] CFP: open source firmware summit in sweden in sept

[Dave Taht]

I think I might submit a talk. But would prefer someone closer...

https://talks.osfc.io/osfc2022/cfp

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] a foundation for flent?

[Dave Taht]

All:

I started this proposal two weeks back in an attempt to understand and
apply for support from the NSF "POSE" grants program. It's due
tomorrow, but there's no way I'll make that deadline. There's a phase
II proposal that could be put together by October if the right people
can be found, and there are other options like an DoE SBIR or
commercial investment, etc that could also be pursued.

I felt, in drafting this, that with a major investment into flents PR,
and outreach, and ease of use, we'd be able to train more folk about
ways to fix more networks. If anyone would like to comment, it's here.
I liked to think the rhetoric and the accomplishments we had so far
with toke's wonderful tool, should speak for themselves.

https://docs.google.com/document/d/19GPpuFG4p9uG1sR_jVW8O3ptpoBfuQJxPuo5lIZf7hc/edit?usp=sharing

If there is anyone out there deeply familiar with NSF processes, and
has some time before October to help, that would be great. Not only
that I've tried to identify "organizational" things that someone with
more talent at that (if anyone knows anyone) that someone(s) could
solve as part of it. [0]

Basically the crux of my thoughts driving this was in testing hotel
and personal networks all over the USA over the last few months, and
gathering a few individuals also, on our mailing lists, to also do
flent testing, revealed that 99% of all wifi networks kind of stink in
some respect or another, and also, sadly, discovering the huge
deployment of essentially buggy implementations of fq_codel now
fielded as part of the survey I just completed for NLNET.[3]

As happy as I am with speedtest.net's new "working latency" app for
ios (try it!!!) it doesn't let a network engineer or driver writer
"get in there" and optimize their code for better latency like flent's
tests do, and most of the testing "out there" is reduced to single
number summaries of iperf3, it seems. I love flent, it's been a great
tool, I would like to find ways to get 100k more people using it
regularly without having to do a lot of extra work, and the methods
and analytics into things like wireshark, also. It needn't be this
flent foundation idea. Certainly I'm going to try to find a conference
or three in the coming years to talk to it - perhaps nanog, certainly
a wifi conference, etc. Perhaps others can pursue that, too.

I've never wanted to establish a non-profit for bufferbloat.net,
principally because I'd hoped we'd be done by now! I'd tried to
establish a more generic educational foundation (icei.org, if anyone
wants to see it on archive.org), which failed, tried for a floor under
cerowrt to keep it going, failed, tried to keep make wifi-fast going,
failed... (and the entire internet failed during that key
interview[]1) - it's always been easier to just "do the work" on no
money and on the backs of so many willing volunteers, than do anything
structured around it. I keep circulating a proposal for an "upgrade in
place", in the hope that someone grasps the seemingly viable business
models in it. And so it goes.

Basically with a string of failures like the streak I've long been on,
there is one person to point to for why it doesn't happen. Me.
Bothering to make the effort to find funding that we could use to more
effectively change the world than we have so far is now a once every
other year activity for me. I'm very glad that companies like canopus,
preseem, and others did find business models that worked. Me, I had
basically "quit" last year (jim is also mostly retired), and if it
wasn't for apple taking up the cause and so much progress elsewhere
this past year, I'd have stayed quit. As it is, I'm trying to nerve
myself up for doing something useful for - the summer at least - and I
don't know what that is.

(anyone going to "mountain connect" in colorado, may 23-25th?) .

Somewhere, out there, someone else must have a brilliant idea to
finally eradicate the bufferbloat from the world.

[0] I do wish I could find a concept with a profit model. But I
imagine the demand for test tools like this on android/ios/windows is
quite low, and the amount of investment required to produce one, quite
high. The mythological VC with a heart of gold, or billionaire with a
few extra bucks, would be more ideal.

[1] I'd really like to at the very least get merch for everyone here
that said something like:
"I fixed the internet, and all I got was this lousy t-shirt".

[2] https://blog.cerowrt.org/post/bufferbloat_on_the_backbone/


-- 
[3] FQ World Domination pending:
https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] NSF letter of collaboration?

[Dave Taht]

I am in the middle of writing up a proposal to put more of a floor
under flent. One requirement is
for a letter of collaboration (not support), if there is anyone out
there interested in participating,
please let me know?

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [babel] RFC 9229 on IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol

[Dave Taht]

yea!

-- Forwarded message -
From: 
Date: Fri, May 6, 2022 at 11:16 AM
Subject: [babel] RFC 9229 on IPv4 Routes with an IPv6 Next Hop in the
Babel Routing Protocol
To: , 
Cc: , , 


A new Request for Comments is now available in online RFC libraries.


RFC 9229

Title:  IPv4 Routes with an IPv6
Next Hop in the Babel Routing Protocol
Author: J. Chroboczek
Status: Experimental
Stream: IETF
Date:   May 2022
Mailbox:j...@irif.fr
Pages:  9
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-babel-v4viav6-08.txt

URL:https://www.rfc-editor.org/info/rfc9229

DOI:10.17487/RFC9229

This document defines an extension to the Babel routing protocol that
allows announcing routes to an IPv4 prefix with an IPv6 next hop,
which makes it possible for IPv4 traffic to flow through interfaces
that have not been assigned an IPv4 address.

This document is a product of the Babel routing protocol Working Group
of the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
babel mailing list
ba...@ietf.org
https://www.ietf.org/mailman/listinfo/babel


-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [Babel-users] ANNOUNCE: babeld-1.12

[Dave Taht]

I really like the 4 over 6 thing

-- Forwarded message -
From: Juliusz Chroboczek 
Date: Thu, May 5, 2022 at 5:06 AM
Subject: [Babel-users] ANNOUNCE: babeld-1.12
To: 


Dear all,

Babeld 1.12 is available from

  https://www.irif.fr/~jch/software/files/babeld-1.12.tar.gz
  https://www.irif.fr/~jch/software/files/babeld-1.12.tar.gz.asc

For more information about the Babel routing protocol, please see

  https://www.irif.fr/~jch/software/babel/

This version implements v4-via-v6 routing, which allows an IPv6-only
router to route IPv4 completely transparently.  The work is due to
Théophile Bastian, Toke Høyland-Jørgensen, and myself.  The protocol is
described in RFC 9229, which has not been published yet; in the meantime,
you may find the final draft at

  https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6-08

V4-via-v6 is enabled by default on Linux kernel 5.13 and later, which may
cause issues in your network:

  - IPv6-only routers will suddently start routing IPv4; if you rely on
IPv6-only routers to isolate you from the IPv4 Internet, this will no
longer work.  Please set up filtering rules and firewalls if you wish
to be isolated from the Internet.

  - IPv6-only routers will suddenly start sending ICMPv4 messages using
the IPv4 "dummy address" 192.0.0.8; please make sure your firewall
rules let through ICMPv4 packets with source equal to 192.0.0.8 lest
you suffer from PMTUD blackholes.  (This applies even if you're not
running Babel itself: filtering ICMPv4 packet-too-big is almost always
a mistake.)

The full changelog follows.

5 May 2022: babeld-1.12

  * Implement v4-via-v6 routing (RFC 9229), which allows a router with
IPv4 addresses only to route IPv4.  Thanks to Théophile Bastian.
  * Enable extended Netlink acks when available.
Thanks to Toke Høyland-Jørgensen.
  * Fix restoring of interface configuration to avoid unbounded memory
consumption.  Thanks to andrew-hoff.
  * Fix handling of deny filters in the install chain.

-- Juliusz


___
Babel-users mailing list
babel-us...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users


-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] logo: t-shirts, coffee cups, socks, hats

[Dave Taht]

It's been a couple years, has anyone come up with a good idea for
logos or slogans?

I'd always wanted to have given out a t-shirt at the completion of the
cake and make-wifi-fast projects, it's kind of traditional, but
lacking any artistic talent personally... or budget for it, never did.
At the moment I'm feeling terribly cynical so things like:

Skeleton with coffee cup: "Fixed Wifi in 2016. Still waiting for new
kernels to deploy".

Skeleton with cake with 6 candles in it: "When the upgrades are over,
everyone will have cake."

Came to mind first.  Also:

Mouldy barrel full of bugs, worms, spiders, CVE's and snakes: "Mmmm,
vintage kernel. Ship it!"

YES, I WANT CGNAT! PORT FORWARDING IS FOR PU$$IES.

Who needs IPv6? (picture of crowd of people of all sorts)

DNSSEC is for dummies that can't tell the difference between
paypal.com and paypall.com.

Other, equally cynical, or optimistic, messages and ideas sought?

-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: Realtek RTL8156 devices defaulting to CDC-NCM instead of vendor mode, resulting in reduced performance

[Dave Taht]

.6ms considered good.

-- Forwarded message -
From: Forest Crossman 
Date: Mon, May 2, 2022 at 3:49 PM
Subject: Realtek RTL8156 devices defaulting to CDC-NCM instead of
vendor mode, resulting in reduced performance
To: , , 
Cc: , 


Hi, all,

I recently purchased a pair of USB to 2.5G Ethernet dongles based on
the RTL8156, and have so far been very happy with them, but only after
adding some udev rules[0] to to take advantage of the r8152 driver by
switching the devices from their default CDC-NCM mode to the vendor
mode. I was prompted to use those rules to switch the driver because
one of the adapters (based on the RTL8156A) would get very hot, up to
120 F (49 C) even while idle, and the round-trip latency directly
between the pair of adapters was about 3 ms, and I couldn't help but
wonder if maybe the vendor mode might be more efficient.

After performing some tests of latency and power consumption, testing
first with both adapters in NCM mode and then again with both in
vendor mode, I proved my hunch correct. I discovered that, in a
disconnected state, the RTL8156A adapter used about half as much power
(0.64 W -> 0.30 W) while the RTL8156B adapter saw a 21% reduction in
power (0.34 W -> 0.27 W). Similarly, in a connected-but-idle state the
RTL8156A again saw about a 55% savings in power consumption (2.17 W ->
0.97 W) and a 40% savings in the RTL8156B adapter (0.94 W -> 0.56 W).
It was only under full load that the fewest power savings were seen,
with a reduction of only 15% in the RTL8156A (2.23 W -> 1.90 W) and no
savings for the RTL8156B (0.96 W). Similarly, round-trip latency while
idle went from 3 ms to 0.6 ms. I also tested under load and saw much
larger latency savings and reduced packet loss, but forgot to write
down the numbers (I can run the tests again if someone really wants me
too). Also, jumbo frames drastically reduced performance under NCM
mode, while vendor mode handled it like a champ (again, I forgot to
write down the numbers but can test again if asked).

So, with all the benefits I've seen from using these adapters in their
vendor mode, is there still a reason to let the kernel prefer their
NCM mode? It'd be nice to be able to get the maximum performance from
these adapters on any Linux system I plug them into, without having to
install a udev rule on every one of those systems.

If anyone would like to try replicating the results I listed here, or
to perform new tests, the specific RTL8156A adapter I used is the
Ugreen CM275[1] and the RTL8156B adapter is the Inateck ET1001[2].


Curious to hear your thoughts on this,

Forest


[0]: 
https://github.com/bb-qq/r8152/blob/160fb96d2319cdf64ae7597e8739972934ac83b2/50-usb-realtek-net.rules
[1]: https://www.amazon.com/gp/product/B081TY1WQX/
[2]: https://www.amazon.com/gp/product/B08VN3DGK6/


-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] achieved: dmca exceptions for jailbreaking routers

[Dave Taht]

I'd completely missed that this happened. Cerowrt was mentioned in the
original filing.

https://sfconservancy.org/news/2021/oct/28/2021-DMCA-final-exemptions-win/

Sometimes I think our FCC fight was an achievement ranking right up
with finally perfecting
fq_codel for wifi.

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] turris presentation

[Dave Taht]

I'm very pleased to see how far turris has got in producing secure,
updatable routers.

https://forum.turris.cz/t/wispamerica-2022-animal-farm-turristech-open-source-wi-fi-security/16978

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] backport a -2 line patch to openwrt?

[Dave Taht]

I am not spun up to do kernel builds and testing, and while this is
linux mainline now it's not
in openwrt. Anyone up to doing a build and testing a -2 line patch?

https://forum.openwrt.org/t/backport-ipv4-lowest-address-as-ordinary-unicast-address/124899

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] YADA and YATT draft

[Dave Taht]

This is totally worth reading just for the the 3D text diagrams. and more.

https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html


-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] android, sqm-autorate and lte and videoconferencing

[Dave Taht]

it's looking promising.

in trying to get an android to do better this recent ML paper crossed my desk:

https://arxiv.org/pdf/2007.02735.pdf

On Wed, Apr 6, 2022 at 1:38 PM Sebastian Moeller  wrote:
>
> Dear Dave, dear all
>
> please, let me introduce Andrew to this list, who is the driving force behind 
> CAKE-autorate's design and implementation (which started from a more 
> theoretical discussion in the OpenWrt forum before turning into something 
> tangible). There are other alternative approaches for the rate-tracking 
> problem many discussed in this longish forum thread: 
> https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848 (which is great 
> as this occasionally leads to quite interesting discussion about how the 
> different teams tackle common issues) but Andrew's autorate appears to the 
> fastest moving with low software requirements (every router should run bash 
> anyway ;) ).
>
> Kind Regards
> Sebastian
>
>
> > On Apr 6, 2022, at 17:43, Dave Taht  wrote:
> >
> > For the past several days,  I have been very successfully using
> > variants of the cake-autorate code to manage my connections on the
> > boat, for which I use a tether to my laptop.
> >
> > https://github.com/lynxthecat/CAKE-autorate
> >
> > Although this test claims my link was inadequate for a good videoconference
> >
> > https://www.waveform.com/tools/bufferbloat?test-id=964831e5-30f9-4695-bfbd-b58da0a759f3
> >
> > they have all been perfect (and that test was conducted during an
> > actual zoom conference). The code does not grab as much bandwidth as
> > it could, when available, but I'll settle for perfect
> > videoconferencing.
> >
> > Anyway... what I used to do was attach the phone to a router shared
> > boat-wide that did this stuff, but it would be nice to move the
> > algorithm directly into an android. My hope is that more modern
> > androids are running a recent enough kernel(?) to have cake, but it's
> > been a long time since I built anything for android, and am wondering
> > if there is a lte/5g tablet or phone or dedicated lte router "out
> > there" that can be hacked on?
> >
> >
> >
> > --
> > I tried to build a better future, a few times:
> > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
> >
> > Dave Täht CEO, TekLibre, LLC
> > ___
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
>


-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] wispa conference presentations

[Dave Taht]

I got a real education at the recent wisp conference about how the
fixed wireless market is functioning. They just put out all the
presentations at this link:

https://www.dropbox.com/sh/908gkt1z76aqtai/AAD30J834rfF3TkiGm3AZxeIa/WA2022?dl=0=

Of especial interest to those here might be the turris presentation,
'network neutrality again' and various papers on the costs and
problems there are in running fiber today.

Every other wisp I visited was already running preseem (fq_codel
middlebox), the other considering it, in the 50 devices in the home
presentation, over half the room used openwrt. It was a nice place to
be.

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] android, sqm-autorate and lte and videoconferencing

[Dave Taht]

For the past several days,  I have been very successfully using
variants of the cake-autorate code to manage my connections on the
boat, for which I use a tether to my laptop.

https://github.com/lynxthecat/CAKE-autorate

Although this test claims my link was inadequate for a good videoconference

https://www.waveform.com/tools/bufferbloat?test-id=964831e5-30f9-4695-bfbd-b58da0a759f3

they have all been perfect (and that test was conducted during an
actual zoom conference). The code does not grab as much bandwidth as
it could, when available, but I'll settle for perfect
videoconferencing.

Anyway... what I used to do was attach the phone to a router shared
boat-wide that did this stuff, but it would be nice to move the
algorithm directly into an android. My hope is that more modern
androids are running a recent enough kernel(?) to have cake, but it's
been a long time since I built anything for android, and am wondering
if there is a lte/5g tablet or phone or dedicated lte router "out
there" that can be hacked on?



-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] Fwd: [Babel-users] ANNOUNCE: babeld-1.11

[Dave Taht]

-- Forwarded message -
From: Juliusz Chroboczek 
Date: Wed, Mar 30, 2022, 1:10 PM
Subject: [Babel-users] ANNOUNCE: babeld-1.11
To: 


Dear all,

Babeld 1.11 is available from

  https://www.irif.fr/~jch/software/files/babeld-1.11.tar.gz
  https://www.irif.fr/~jch/software/files/babeld-1.11.tar.gz.asc

For more information about the Babel routing protocol, please see

  https://www.irif.fr/~jch/software/babel/

The main news in this version is support for MAC authentication, as
described in RFC 8967 [1].  This implementation has been verified to
interoperate with BIRD, and I've written a tutorial before.

[1] https://datatracker.ietf.org/doc/html/rfc8967
[2]
https://alioth-lists.debian.net/pipermail/babel-users/2021-June/003827.html

I'll use the opportunity to remind everyone that, due to the Russian
invasion of Ukraine, we are currently living one of the most dramatic
refugee crises in living history.  If you live in Europe, please consider
volunteering with one of the organisations taking care of the refugees,
and, if you own a secondary residence, please consider renting it out.
Wherever you are, please consider donating to the organisations taking
care of the refugees (at least in France, the Red Cross appears to be
doing a good job), or to pro-Ukrainian causes (such as the Ukrainian Red
Cross or the Ukrainian Army).

30 March 2022: babeld-1.11

  * Implemented MAC authentication (RFC 8967).  Thanks to Clara Dô,
Weronika Kołodziejak and Antonin Décimo.
  * Changed the interface of the add_filter function in order to simplify
integration in OpenWRT.  Thanks to Nick Hainke.

-- Juliusz

___
Babel-users mailing list
babel-us...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] starlink gen2 wifi made buildable

[Dave Taht]

tho still rife with binary blobs, at least now lede-17.01 can be
compiled for it.

https://github.com/olegkutkov/starlink-wifi-gen2/commit/aabbda684df21506c935abe62a8aa8b05a7f6385

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] vroom! cloud cpu fpga development

[Dave Taht]

of a "very high end RISC-V implementation, cloud server class, out of
order, super scalar, speculative, up to 8 IPC" over at
https://moonbaseotago.github.io/

It's not just interesting because of the goal but because AWS is
providing a low cost cloud based service for this sort of hardware
development.

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] librerouter fpga claims 100gbit

[Dave Taht]

https://www.liberouter.org/ndk/



-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel