Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

[Dave Taht]

I do not care one whit about CIP. It will lead to redhat-style
ossification and even further delusional consideration that Linux is
"done". The Linux foundation keeps losing its way. I would prefer
OpenWrt (and arm development in particular) continue to track the
newest kernels possible and indeed, somehow, push back into the
mainline kernel processes for older, embedded gear more than it has,
continuing to shrink needed bits as they come up.

As an example, 6.7 had had extensive profiling in it, which made the
tcp stack on AMD in particular more highly performant. But no work was
done that I know of to verify that ARM was not hurt, particularly arm
on older gear - but due to those patches being so beneficial, it looks
like ubuntu plans to ship 6.8 in april. Improvements to the tcp stack
are not openwrt´s primary use case, but being able to stay on top of
linux developments on arm gear is.

Perhaps rather than chasing LF unnecessarily, following a mainstream
distro more closely aligned with ARM might help.

As for 6.1 vs 6.6, having tooling, processing, people, and attitude in
place towards being always being able to go in 4 months to a new
kernel - of any sort - would be a win.

On Mon, Feb 5, 2024 at 5:38 AM Zoltan HERPAI  wrote:
>
> On Sat, 3 Feb 2024, Enrico Mioso wrote:
>
> > On Sat, Feb 03, 2024 at 07:02:44PM +0100, Christian Marangi (Ansuel) wrote:
> >> Il giorno sab 3 feb 2024 alle ore 18:55 Janusz Dziedzic
> >>  ha scritto:
> >>>
> >>> sob., 3 lut 2024 o 13:08 Hauke Mehrtens  napisał(a):
> 
>  Hi,
> 
>  I track the status of the Linux kernel 6.1 migration in this github
>  issue: https://github.com/openwrt/openwrt/issues/14546
> 
>  There are still many targets on kernel 5.15 without testing support for
>  kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to
>  get everything to 6.1 and more or less stable. Kernel 6.1 support is
>  also missing for some important targets like lantiq, realtek and ramips.
> 
> 
>  Which kernel should we use for the next major OpenWrt release?
>  We have two options and I would like to get some feedback on these:
> 
>  1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or
>  most of the targets are on kernel 6.1 by default.
>  2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or
>  most of the targets are on kernel 6.6 by default. Do not do any stable
>  OpenWrt release which supports kernel 6.1.
> 
>  Doing a OpenWrt release with multiple kernels cases too much maintenance
>  effort from my point of view based on previews experience.
> 
> 
>  I think with kernel 6.1 we can branch off at around May 2024. With
>  kernel 6.6 we could probably branch off around September 2024. The final
>  release will be out about 2 to 4 months later.
> 
>  Currently OpenWrt releases are about 1.5 years behind the Linux LTS
>  releases. When we use kernel 6.1 for the next release we will continue
>  to stay 1.5 years behind. When we switch to kernel 6.6 and do not do any
>  release with kernel 6.1 we will probably only stay 10 months behind
>  Linux LTS kernels.
> 
>  There is already a PR requiring kernel 6.6:
>  https://github.com/openwrt/openwrt/pull/14357
> 
> 
>  Currently I would prefer to use kernel 6.6 to get closer to the recent
>  Linux LTS releases.
> 
> >>>
> >>> 6.6 for sure if possible.
> >>>
> >>> Just curious - any reason to not support both or even 5.15? And target
> >>> could decide about it in mk?
> >>> Eg. newest ATH/QCA that base a lot on newest kernel and backports just
> >>> could choose it?
> >>> For older one we already have work done - so just change generic
> >>> patches directory into generic-kernel_ver?
> >>> Or this is more work and problems?
> >>>
> >>
> >> We usually try to stick to a common kernel across all target for stable 
> >> release
> >> for consistency and to prevent and handle regression in the generic target.
> >>
> >> Also it's really a way to force target on getting updated... If it
> >> wasn't for this
> >> reason we would probably have stuff stuck at 4.19.
> >>
> > Hello all,
> >
> > I would choose 6.1: to get more time for some things to stabilize out and 
> > because I am under the impression the kernel size is growing too fast and 
> > so we are accelerating hw obsolescence.
> > The 6.1 kernel has also been choosen by the Civil Infrastructure Platform, 
> > so it would get some attention and maintenance still.
> >
> > However, my preference / decision is for 6.6 in the end: especially after 
> > having felt the pain of developers who need to backport lots of stuff and 
> > for which the challenge becomes harder over time.
> > If we need more developers, making development less annoying is preferrable.
> > That said, it would be nice to enable only the needed kernel features for a 
> > subtarget, just to incrase 

Re: [VOTE] New member proposal: Robimarko (Robert Marko)

[Dave Taht]

I do not think I get a vote, but I am deeply grateful to everyone(s)
sorting out the QCA messes.

I did not know who was doing that. Thank you very much, robert & christian.


On Tue, Jan 30, 2024 at 2:36 PM Petr Štetiar  wrote:
>
> Christian Marangi (Ansuel)  [2024-01-30 19:15:54]:
>
> Hi,
>
> > Robert is active in OpenWrt since 2017 and with some recent stats, he
> > has more than 310 commits merged in OpenWrt.
> > He also have uncounted Reviewed-by tag on various PR and merged commits
> > and generally helps in everything related to IPQ (ipq806x, ipq40xx and
> > ipq807x) and some mvebu targets.
> >
> > He did the conversion of ipq40xx target to DSA and made possible the
> > introduction of the ipq807x target by sorting all the QSDK downstream
> > patch and pushing them upstream.
> >
> > With his help, also the ipq60xx is very close on getting merged and
> > actually used permitting support of even more device for OpenWrt.
> >
> > Also he is almost always reachable on IRC openwrt-devel and never had
> > a problem in coordinating and collaborating with him.
> >
> > I think Robert is a good addition to our team and would massively help
> > me (Ansuel) in maintaining each IPQ target and review all the related
> > PR on github and patchwork.
> > I would like to add Robert to the OpenWrt committers team.
>
> +1
>
> Thanks for taking care of that!
>
> Cheers,
>
> Petr
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Dave Taht]

On Thu, Jan 18, 2024 at 12:04 PM Gregers Baur-Petersen  wrote:
>
>
>
> On 18/01/2024 17.50, Dave Taht wrote:
> > tee-hee. For the record, I would prefer less (and less buggy) offloads
> > than offloads, and to work on scaling software better to multi-cores.

I had heard there was a mt76? mt79? feature where the completion
interrupt could be made to shape the pulls from the qdisc, essentially
doing hardware shaping. There is support for this in BQL for several
intel chips. True?

> >
> > I also would love to find a chip where fq_codel could be offloaded,
> > but with open source for the offload, since the nss drivers are
> > slightly broken...
> >
> > I also would like a pony.
> >
> Not sure if a pony is the extra addition/feature I need. I'm more of a
> dog person ;-)

OpenWrt One could use a logo...
>
> > On Thu, Jan 18, 2024 at 11:40 AM Chuanhong Guo  wrote:
> >>
> >> Hi!
> >>
> >> On Fri, Jan 19, 2024 at 12:23 AM Fernando Frediani  
> >> wrote:
> >>>
> >>> Hi, interesting. Is it enough to give it the necessary performance boost
> >>> when doing NAT ? Is it capable of doing it on the chip or does it do on
> >>> the CPU ? Reading about it seems to be a software thing although seems
> >>> there are hardware capable devices as well. How comparable is this to a
> >>> chip that has NAT offload capability ?
> >>
> >> MT7981 is such a chip with NAT offload capability, and the
> >> flow-offload driver mentioned in other threads is actually
> >> a driver for this hardware block.
> >> Since it's a cost-down MT7986 I would imagine this particular
> >> feature is the same between them:
> >>
> >> HW NAT
> >> − Etherent/WiFi
> >> − Wired speed
> >> − IPv4 routing, NAT, NAPT
> >> − IPv6 routing, DS-Lite, 6RD
> >>
> >> --
> >> Regards,
> >> Chuanhong Guo
> >>
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> >
> >
>
> --
>   -
>   Gregers Baur-Petersen
>   Anthropologist
>   -
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Dave Taht]

tee-hee. For the record, I would prefer less (and less buggy) offloads
than offloads, and to work on scaling software better to multi-cores.

I also would love to find a chip where fq_codel could be offloaded,
but with open source for the offload, since the nss drivers are
slightly broken...

I also would like a pony.

On Thu, Jan 18, 2024 at 11:40 AM Chuanhong Guo  wrote:
>
> Hi!
>
> On Fri, Jan 19, 2024 at 12:23 AM Fernando Frediani  
> wrote:
> >
> > Hi, interesting. Is it enough to give it the necessary performance boost
> > when doing NAT ? Is it capable of doing it on the chip or does it do on
> > the CPU ? Reading about it seems to be a software thing although seems
> > there are hardware capable devices as well. How comparable is this to a
> > chip that has NAT offload capability ?
>
> MT7981 is such a chip with NAT offload capability, and the
> flow-offload driver mentioned in other threads is actually
> a driver for this hardware block.
> Since it's a cost-down MT7986 I would imagine this particular
> feature is the same between them:
>
> HW NAT
> − Etherent/WiFi
> − Wired speed
> − IPv4 routing, NAT, NAPT
> − IPv6 routing, DS-Lite, 6RD
>
> --
> Regards,
> Chuanhong Guo
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Dave Taht]

On Mon, Jan 15, 2024 at 12:55 AM John Crispin  wrote:
>
> when did crowdfunding come into play here ? there is no intention of
> starting a crowdfunder.

A kickstarter is a good way to forecast demand.

You've captured the imagination of the geek community.

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

The original hits, by the original artists!

And upstream first, to build a better future, perhaps, in whatever you do next.

Please consider the idea.

>
>  John
>
> On 15.01.24 01:51, Kathy Giori wrote:
> > Or CrowdSupply <https://www.crowdsupply.com/> (founder Joshua Lifton).
> >
> > Or I could introduce you to BeagleBoard.org <http://BeagleBoard.org>
> > -- combo of the founder and the exec dir is quite an experienced pair,
> > well-aligned with OpenWrt principles, experienced with getting
> > high-volume hardware manufactured and sold (that is manufactured in
> > Asia). If you want to collaborate/co-brand with them, you'd have solid
> > experience behind the sales and distribution of the platform to
> > top-tier distributors (DigiKey, etc.). I already mentioned this
> > project to founder Jason Kridner and he'd be happy to have a chat.
> >
> > kathy
> >
> > p.s. perhaps you could organize a discussion of this platform at FOSDEM?
> >
> >
> > On Sun, Jan 14, 2024 at 7:05 AM Dave Taht  wrote:
> >
> > Can I recommend you do a kickstarter?
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Dave Taht]

Can I recommend you do a kickstarter?

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Dave Taht]

I have often tried to point out that what matters most in wifi is low
interference, better multiplexing across devices, and good bandwidth
*at range*. Up until very recently the 6ghz stuff mostly had terrible
bandwidth, jitter and latency at range, and everyone shipping it
bleeding into all the channels, futility compensating for lousy device
drivers, on stupid, unrealistic benchmarks.

So I at least do not feel a huge urge to get on the 6ghz bandwagon at
this time. I would actually, be happy cutting even more multiplexing
latency out of the ath9k chips, and there is much fat left to be cut
from the mt79 also, and the benefits of many people focused on
building on top of a single stable *inexpensive* platform and working
all the bugs out of it - that has a lot of shared characteristics with
the higher end gear - cannot be underestimated. I still have wndr3800s
running for years at a time, running openwrt.

To date most of the pi-alikes have had absolutely terrible wifi, often
only a single crappy antenna and connected via usb or worse i2c.
Fixing that would be marvellous. a 3x3 as in this board, *lust*

https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit

On Tue, Jan 9, 2024 at 1:17 PM Janusz Dziedzic
 wrote:
>
> wt., 9 sty 2024 o 18:59 Daniel Golle  napisał(a):
> >
> > On Tue, Jan 09, 2024 at 06:49:04PM +0100, Janusz Dziedzic wrote:
> > > wt., 9 sty 2024 o 18:02 Robert Marko  napisał(a):
> > > >
> > > > On Tue, 9 Jan 2024 at 17:53, Rafał Miłecki  wrote:
> > > > >
> > > > > On 9.01.2024 13:29, John Crispin wrote:
> > > > > > On 09.01.24 12:56, Robert Marko wrote:
> > > > > >> ---SNIP---
> > > > > >>
> > > > > >>> Why not 6GHz?
> > > > > >> 6GHz requires an external card, and I doubt you can fit that in the
> > > > > >> target price.
> > > > > >>
> > > > > >> Regards,
> > > > > >> Robert
> > > > > >
> > > > > > correct. as mentioned in the email, we wanted to start out small. 
> > > > > > also upstream mac80211 is still missing a bunch of 11be related 
> > > > > > features.
> > > > >
> > > > > 6 GHz doesn't imply 802.11be, does it? I'm really not sure.
> > > > >
> > > > > Does MediaTek have any 802.11ax solutions that cover both: 5 GHz and
> > > > > 6 GHz? Maybe it'd be worth checking if that's an option and then use
> > > > > voting to see if people care?
> > > >
> > > > You can use 6GHz as part of 802.11ax as well, but you need an external 
> > > > card or
> > > > you need to sacrifice the built-in 5GHz for 6GHz and that isn't really
> > > > a good idea
> > > > in my opinion.
> > > >
> > > Even will be 150$ it is still good price for router with 2.4/5/6GHz
> > > (MTK base ACER predator W6 is about 200$).
> > > Or at least add extra m2 AE Key slot - then we can put there mt7916
> > > card, as possible extension (eg.
> > > https://asiarf.com/product/wi-fi-6e-m-2-ae-key-module-mt7916-aw7916-aed/).
> > > What will be price in case of this extra m2 AE Key slot?
> >
> > You can use M.2 key adapters for that
> > https://www.delock.com/produkt/63343/merkmale.html
> >
> > An additional slot is *not* an option as we got only a single PCIe lane.
> >
> > Hopefully there are also going to be single-band (6 GHz only) 4T4R or
> > even 4T5R modules based on MT7916E available at some point...
>
> Seems bpi-r4 will use two miniPCIe slots for that:
> https://wiki.banana-pi.org/Getting_Started_with_BPI-R4#4.29_Wi-Fi7_NIC
>
> If we don't have two PCIe then probably no option for 6ghz
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos

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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Dave Taht]

Battery power capability? Parts of the world still have their power
flicker regularly. Others can be solar powered. What is the projected
power consumption of this device?

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

GPON project?

[Dave Taht]

Honestly, if progress is not made towards making GPON accessible in
FOSS, the next generation of fiber routers will be as locked down as
cablemodems are. While I do know of many ISPs using active ethernet
fiber instead, GPON is big in some places.

On Tue, Jan 9, 2024 at 7:39 AM Robert Marko  wrote:
>
> On Tue, 9 Jan 2024 at 13:38, Dave Taht  wrote:
> >
> > You should talk about this project at FOSSDEM!
> >
> > Two potential funders off the top of my head:
> >
> > https://nlnet.nl/funding.html
> > https://www.ardc.net/apply/
> > Ardc funded the latest round of the librerouter project in argentina,
> > which is also openwrt based, but intended for outdoor.
> >
> > a 10 year design life would be nice. Gpon support instead of a 2.5Gbit port?
>
> GPON support is non-existent in FOSS form basically.
>
> Regards,
> Robert
> >
> > The A53s are pretty weak. I would certainly like to see people squeeze
> > more performance out of these...
> >
> > I am more a software guy than hw,  I would like to see "matter" begin
> > to matter. 802.14 anyone? Also:
> > https://forum.openwrt.org/t/cerowrt-ii-would-anyone-care/110554
> >
> > Otherwise, I applaud. We could really use a reference router. I still
> > use (and love) my wndr3800s. Have not seen much reason to upgrade.
> > There´s still improvements to the ath9k feasible!
> >
> > On Tue, Jan 9, 2024 at 5:52 AM John Crispin  wrote:
> > >
> > > 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/a

Re: OpenWrt One - celebrating 20 years of OpenWrt

[Dave Taht]

You should talk about this project at FOSSDEM!

Two potential funders off the top of my head:

https://nlnet.nl/funding.html
https://www.ardc.net/apply/
Ardc funded the latest round of the librerouter project in argentina,
which is also openwrt based, but intended for outdoor.

a 10 year design life would be nice. Gpon support instead of a 2.5Gbit port?

The A53s are pretty weak. I would certainly like to see people squeeze
more performance out of these...

I am more a software guy than hw,  I would like to see "matter" begin
to matter. 802.14 anyone? Also:
https://forum.openwrt.org/t/cerowrt-ii-would-anyone-care/110554

Otherwise, I applaud. We could really use a reference router. I still
use (and love) my wndr3800s. Have not seen much reason to upgrade.
There´s still improvements to the ath9k feasible!

On Tue, Jan 9, 2024 at 5:52 AM John Crispin  wrote:
>
> 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 

packet captures of sony's new 80Mbit service?

[Dave Taht]

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

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

Re: Mofi still shipping Barrier Breaker (14.07)

[Dave Taht]

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-devel@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-devel@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-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Mofi still shipping Barrier Breaker (14.07)

[Dave Taht]

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-devel@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-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: a nuking the mac80211 changing codel parameters patch

[Dave Taht]

I cannot help but wonder what the results have been on people applying
this patch over the past 6 months?

On Tue, Dec 20, 2022 at 12:24 PM Dave Taht  wrote:
>
> This is the single, most buggy, piece of code in "my" portion of wifi
> today. It is so wrong, yet thus far I cannot get it out of linux or
> find an acceptable substitute. It makes it hard to sleep at night
> knowing this code has been so wrong... and now in millions , maybe
> even 10s of millions, of devices by now Since I've been ranting
> about the wrongness of this for years, I keep hoping that we can
> excise it, especially for wifi6 devices and even more especially on
> 6ghz spectrum... but just about everything, somehow, would benefit
> hugely if we could somehow do more of the right thing here.
>
> I'd tried, last time I got this bee in my bonnet, tried to nuke this call 
> here:
>
> https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/
>
> As it is, I really encourage folk, especially with mt79 and to some
> extent mt76 ac or ath10k, to try out the attached patch, measure tcp
> rtts, and throughput, etc. A slightly less aggressive patch might suit
> wifi-n
>
> Maybe there's a reason for keeping this code in linux wifi that I do
> not understand. But here are my pithy comments as to why this part of
> mac80211 is so wrong...
>
>  static void sta_update_codel_params(struct sta_info *sta, u32 thr)
>  {
> -   if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
>
> 1) sta->local->num_sta is the number of associated, rather than
> active, stations. "Active" stations in the last 50ms or so, might have
> been a better thing to use, but as most people have far more than that
> associated, we end up with really lousy codel parameters, all the
> time. Mistake numero uno!
>
> 2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016.
>
> -   sta->cparams.target = MS2TIME(50);
>
> This, by itself, was probably not too bad. 30ms might have been
> better, at the time, when we were battling powersave etc, but 20ms was
> enough,
> really, to cover most scenarios, even where we had low rate 2Ghz
> multicast to cope with. Even then, codel has a hard time finding any
> sane drop
> rate at all, with a target this high.
>
> -   sta->cparams.interval = MS2TIME(300);
>
> But this was horrible, a total mistake, that is leading to codel being
> completely ineffective in almost any scenario on clients or APS.
> 100ms, even 80ms, here, would be vastly better than this insanity. I'm
> seeing 5+seconds of delay accumulated in a bunch of otherwise happily
> fq-ing APs
>
> 100ms of  observed jitter during a flow is enough. Certainly (in 2016)
> there were interactions with powersave that I did not understand, and
> still don't, but
> if you are transmitting in the first place, powersave shouldn't be a
> proble.
>
> -   sta->cparams.ecn = false;
>
> At the time we were pretty nervous about ecn, I'm kind of sanguine
> about it now, and reliably indicating ecn seems better than turning it
> off for
> any reason.
>
> -   } else {
> -   sta->cparams.target = MS2TIME(20);
> -   sta->cparams.interval = MS2TIME(100);
> -   sta->cparams.ecn = true;
> -   }
>
> And if we aint gonna fiddle with these, we don't need these either.
>
> In production, on p2p wireless, I've had 8ms and 80ms for target and
> interval for years now, and it works great. It is obviously too low,
> for those that
> prize bandwidth over latency (I personally would prefer TXOPs shrink
> intelligently as well as bandwidth, as you add stations, some of which
> happens naturally by fq-codels scheduling mechanisms, others don't, I
> even run with 2ms txops by default on everything myself)
>
> +   return;
>
> Ideally we could kill this entire call off entirely.
>
>  }
>
> A pre-thx for anyone actually trying the attached patch and reporting
> back on any results.
>
> https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/
>
>
> --
> 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



-- 
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos

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

Re: Matter integration

[Dave Taht]

So wonderful to see matter begin to matter!

https://forum.openwrt.org/t/cerowrt-ii-would-anyone-care/110554

regrettably I am mostly retired from openwrt now and do not understand
the workflow.

On Thu, Jul 27, 2023 at 2:14 PM Karsten Sperling via openwrt-devel
 wrote:
>
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> -- Forwarded message --
> From: Karsten Sperling 
> To: openwrt-devel@lists.openwrt.org
> Cc:
> Bcc:
> Date: Fri, 28 Jul 2023 09:11:10 +1200
> Subject: Matter integration
> Hello,
>
> I’m part of an effort by the Connectivity Standards Alliance to bring support 
> for routers and access points into Matter.  Matter is an open-source 
> connectivity standard built to enable developers and device manufacturers to 
> build reliable and secure connected home devices [1][2].
>
> In this context we’re working on a reference implementation for 
> Matter-enabled routers / access points, which will be taking the form of an 
> OpenWRT feed.  Development on this has recently started at 
> https://github.com/project-chip/matter-openwrt.  We’re using OpenWRT as a 
> platform because of its open nature and great hardware support.  I wanted to 
> reach out to make the OpenWRT developer community aware of this effort, and 
> to invite you to collaborate with us if you’re interested.
>
> On a more concrete level, I would also like to ask for support for this small 
> PR on OpenWRT I’ve opened here: https://github.com/openwrt/openwrt/pull/13000
>
> The cross-platform nature of the Matter SDK combined with the fact that it 
> uses git sub-modules for dependency management results in the repo having a 
> LOT of sub-modules (about 70 direct, 130 total), only 4 of which are needed 
> when building within OpenWRT. Getting this PR merged would help us to get the 
> Matter SDK and related software to build cleanly under OpenWRT.
>
> Thanks!
>
> [1] https://buildwithmatter.com 
> [2] https://github.com/project-chip/connectedhomeip
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos

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

Re: Non-SoC target for ARM64

[Dave Taht]

I would like the comparative simplicity, size, and ease of
configuration in openwrt to make it up into more virtualized
environments, also.

On Thu, Jun 1, 2023 at 11:01 AM Philip Prindeville
 wrote:
>
> Hi,
>
> I'm thinking about the utility of being able to build a generalized ARM64 
> image (not "armvirt") for bring up on new platforms for testing.
>
> There are a lot of generalized computing platforms like the Ampere Altra 
> servers that you might want to use as in inbound Apache proxy server, a load 
> balancer, a traffic shaper, etc.
>
> Can we add a generic target for ARM64 just as x86_64 (or x86/64) is the 
> generic AMD64 target?
>
> I'd like something that I could easily run on a Graviton2 or Altra or Ten64, 
> etc.
>
> Also not clear to me why the various ARM targets like "layerscape", "imx", 
> "octeontx", etc. don't live under a common directory.
>
> Yes, ARM is more optimized for SoCs that have I/O on-chip and hence there's 
> less mix-n-match compared to x86, but it's not completely unheard of either.
>
> What do you all think of adding a generic target for aarch64?
>
> And how awful would refactoring arm and aarch64 be?
>
> Thanks,
>
> -Philip
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@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

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

ripe atlas probe openwrt work

[Dave Taht]

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

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

Re: OpenWrt vs Defense positions

[Dave Taht]

On Tue, May 2, 2023 at 6:24 AM Peter Naulls  wrote:

> > Another impression I have, is that the OpenWrt project is very important 
> > for many yet under-resourced.
> > There are some important tasks that would help with the long-term 
> > maintenance (e.g. merging of the mtk_nand for > > Does anyone know how much 
> > contributions come from people working for companies in OpenWrt?
>> Who knows. I will say that OpenWrt has formed a large part of my career.  As
> measured by patches (which frankly, is something of a time-consuming hurdle), 
> my
> contributions are very very small, but all my OpenWrt work has been under
> companies.

Embedded Linux was, until recently, my "career" since 1997 or so, when
I started working with the handhelds.org project, and later worked at
MontaVista. Very little of what I have done since 2003 was under
corporate aegis. CeroWrt, and the five years spent reworking the Linux
wifi stack in make-wifi-fast came out of my savings, mostly, with a
bit of support from comcast, nlnet, and gfiber. When I failed to get a
round of external funding to keep the project alive, after we heaved
the most core fq_codel bits over the wall, I gave up. There are still
bugs left over in that, hanging over my head, no-one else has been
able to solve.

The wifi industry as a whole took a major wrong turn that perhaps
wifi7 will get it out of, but I don´t know. There are so many other
problems in embedded linux today, not least of which is the failure to
keep up with mainline linux. Complexity collapse seems nigh!, and the
skills required to cross compile stuff seem to be fading. Of
particular irony for me persists in the initial joy I had felt upon
learning Starlink was using openwrt, only to find that even their most
recent product is leveraging... wait for it... LEDE, and so locked
down as to be impossible to upgrade.

Going back to the original subject of this thread, I would hope that
more cash spent on testing and securing openwrt would come from
*somewhere*.
>
>
>


-- 
Podcast: 
https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/
Dave Täht CSO, LibreQos

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

Re: OpenWrt vs Defense positions

[Dave Taht]

This is one of those uncomfortable situations. From where I sit (in
the USA), Germany is viewed as an ally. There is a big shutdown of
imports from China and Russia going on here; that also applies to
software. In the embedded world, OpenWrt is a world leader here, with
a reputation for quality and security second to none (except for the
far-too-long tail of folk using obsolete versions).

How a ragtag bunch of unincorporated (mostly?) peacenik hippie types
can co-exist with devices being built by militaries out of this stuff
I have few ideas. I prefer to shrink the world, and produce stable,
secure, software, for everyone that wants it, but I look at the
contentious places where it also goes (like space, or spacex) and
wonder how it will all end up, and who will maintain it, improve it,
or attempt to subvert it.

To me, all the tools we build, all the code we write, is best used to
create and maintain essential infrastructure, not tear it down.


On Mon, May 1, 2023 at 12:31 PM Peter Naulls  wrote:
>
>
> For those of you who track the small but very real OpenWrt job market, you may
> have seen there's a creep into Defense/Clearance jobs. Here's but one example:
>
> https://careers-bluehalo.icims.com/jobs/3844/job
>
> As a self-declared pacifist (and anyway, dual citizen which would limit my
> ability to get clearance), this is most certainly not for me, but I thought it
> should be something you guys might want to be aware of.
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
AMA March 31: https://www.broadband.io/c/broadband-grant-events/dave-taht
Dave Täht CEO, TekLibre, LLC

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

Re: OpenWrt Next Generation Ideas

[Dave Taht]

Off this enormous list:

https://forum.openwrt.org/t/cerowrt-ii-would-anyone-care/110554

"Matter" has begun to matter, I think. Where does openwrt stand on that?

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

Re: Unloading unused kernel modules (NAT speed)

[Dave Taht]

I dont use qos-scripts, but sqm-scripts. That said, cake peers into
the nat table to balance the traffic better.

On Fri, Feb 3, 2023 at 8:23 AM Rafał Miłecki  wrote:
>
> Another step in my NAT performance debugging.
>
> I realized that my OpenWrt 21.02 based bcm53xx builds can't reach 940
> Mb/s because I have qos-scripts installed.
>
> It happens even with QoS interface disabled:
> qos.wan.enabled='0'
> and with QoS disabled in general:
> /etc/init.d/qos stop
> (disable & reboot don't help neither)
>
> After quite some debugging I discovered that:
> 1. qos-scripts selects iptables-mod-conntrack-extra
> 2. iptables-mod-conntrack-extra selects kmod-ipt-raw
> 3. kmod-ipt-raw provides iptable_raw.ko
> 4. iptable_raw.ko slows down NAT
>
>
> I can bump NAT speed from 880 Mb/s to 940 Mb/s by doing:
>
> # rmmod iptable_raw
> unloading the module failed
> # /etc/init.d/firewall stop > /dev/null 2>&1
> # rmmod iptable_raw
> # /etc/init.d/firewall start > /dev/null 2>&1
>
>
> I'm wondering if there is any good solution to that. I can't think of
> anything clean and generic. Handling modprobe & rmmod directly in
> /etc/init.d/qos sounds really hacky. Any good ideas?
>
> --
> Rafał
>
> ___
> openwrt-devel mailing list
> openwrt-devel@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

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

mt76 ac/ax bugs

[Dave Taht]

I have been trying to characterize a very difficult bug in the ac and
ax support on a new mt76 product, where
for mu-mimo and related, it seems to be generating an invalid or
flipped mac address on small (but not large) packets, eventually
getting through.

This shows up in my flent data as huge swings in delay for tcp + voip
or ping - but not packet loss. Has anyone else seen this?

On Tue, Jan 24, 2023 at 12:00 PM Peter Naulls  wrote:
>
> On 1/24/23 14:48, Nick wrote:
> > Hey,
> > We have testing-support for 5.15 in almost all targets, so we may be able to
> > release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. 
> > We
> > are using GCC 12 as our default compiler version[2]. Binutils has been 
> > updated
> > to version 2.40. Could we fill out the Release Goals page [3]?
> > It would be great to see a new release.
> >
>
> I guess an actual release here is a few months off, and I don't know
> anything about the state of 23.x, but I have 2 mt7621 platforms that I should
> try and get included sooner rather than later, and probably a 3rd in a few
> months.
>
>
>
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@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

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

a nuking the mac80211 changing codel parameters patch

[Dave Taht]

This is the single, most buggy, piece of code in "my" portion of wifi
today. It is so wrong, yet thus far I cannot get it out of linux or
find an acceptable substitute. It makes it hard to sleep at night
knowing this code has been so wrong... and now in millions , maybe
even 10s of millions, of devices by now Since I've been ranting
about the wrongness of this for years, I keep hoping that we can
excise it, especially for wifi6 devices and even more especially on
6ghz spectrum... but just about everything, somehow, would benefit
hugely if we could somehow do more of the right thing here.

I'd tried, last time I got this bee in my bonnet, tried to nuke this call here:

https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/

As it is, I really encourage folk, especially with mt79 and to some
extent mt76 ac or ath10k, to try out the attached patch, measure tcp
rtts, and throughput, etc. A slightly less aggressive patch might suit
wifi-n

Maybe there's a reason for keeping this code in linux wifi that I do
not understand. But here are my pithy comments as to why this part of
mac80211 is so wrong...

 static void sta_update_codel_params(struct sta_info *sta, u32 thr)
 {
-   if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {

1) sta->local->num_sta is the number of associated, rather than
active, stations. "Active" stations in the last 50ms or so, might have
been a better thing to use, but as most people have far more than that
associated, we end up with really lousy codel parameters, all the
time. Mistake numero uno!

2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016.

-   sta->cparams.target = MS2TIME(50);

This, by itself, was probably not too bad. 30ms might have been
better, at the time, when we were battling powersave etc, but 20ms was
enough,
really, to cover most scenarios, even where we had low rate 2Ghz
multicast to cope with. Even then, codel has a hard time finding any
sane drop
rate at all, with a target this high.

-   sta->cparams.interval = MS2TIME(300);

But this was horrible, a total mistake, that is leading to codel being
completely ineffective in almost any scenario on clients or APS.
100ms, even 80ms, here, would be vastly better than this insanity. I'm
seeing 5+seconds of delay accumulated in a bunch of otherwise happily
fq-ing APs

100ms of  observed jitter during a flow is enough. Certainly (in 2016)
there were interactions with powersave that I did not understand, and
still don't, but
if you are transmitting in the first place, powersave shouldn't be a
proble.

-   sta->cparams.ecn = false;

At the time we were pretty nervous about ecn, I'm kind of sanguine
about it now, and reliably indicating ecn seems better than turning it
off for
any reason.

-   } else {
-   sta->cparams.target = MS2TIME(20);
-   sta->cparams.interval = MS2TIME(100);
-   sta->cparams.ecn = true;
-   }

And if we aint gonna fiddle with these, we don't need these either.

In production, on p2p wireless, I've had 8ms and 80ms for target and
interval for years now, and it works great. It is obviously too low,
for those that
prize bandwidth over latency (I personally would prefer TXOPs shrink
intelligently as well as bandwidth, as you add stations, some of which
happens naturally by fq-codels scheduling mechanisms, others don't, I
even run with 2ms txops by default on everything myself)

+   return;

Ideally we could kill this entire call off entirely.

 }

A pre-thx for anyone actually trying the attached patch and reporting
back on any results.

https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/


-- 
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
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 97d24e9..457209a 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2766,15 +2766,7 @@ unsigned long ieee80211_sta_last_active(struct sta_info *sta)
 
 static void sta_update_codel_params(struct sta_info *sta, u32 thr)
 {
-	if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
-		sta->cparams.target = MS2TIME(50);
-		sta->cparams.interval = MS2TIME(300);
-		sta->cparams.ecn = false;
-	} else {
-		sta->cparams.target = MS2TIME(20);
-		sta->cparams.interval = MS2TIME(100);
-		sta->cparams.ecn = true;
-	}
+	return;
 }
 
 void ieee80211_sta_set_expected_throughput(struct ieee80211_sta *pubsta,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

24 core buildbot server donation feasible

[Dave Taht]

Equinix's open source support program indicated a willingness to
contribute a bare metal buildbot server from this list:

https://metal.equinix.com/developers/docs/hardware/legacy-servers/

I don't know who does the buildbots these days?, but please, get in
touch with whoever does, ask them to sign up via:

https://metal.equinix.com/ecosystem/oss/

And let me know, and I'll expedite with the manager in charge.

-- 
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

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

Fwd: Open-source software vs. the proposed Cyber Resilience Act

[Dave Taht]

-- 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

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

Re: CVEs in OpenWrt 22.03

[Dave Taht]

On Tue, Oct 25, 2022 at 7:37 AM Peter Naulls  wrote:
>
> On 10/24/22 18:21, Hauke Mehrtens wrote:
>
> Hauke, thanks for replying!


As I said on a related thread - if an eu body can be found to care
more deeply on these issues, I'm pretty sure
30-50k of funding is available via one or more of nlnet's grant
programs. Applications for this round close december 1st.

https://nlnet.nl/

> >
> > I also prefer if the CVE number is named in the patch. If this is missing
> > somewhere you could send a patch or pull request to rename the patch.
>
> I'm afraid I don't have any explicit examples, but I'll let you know if
> find any.  There are some concerns with the older lua I mentioned below,
> but I'll need to come back to those. In any case, a suggestion for future
> CVE patches.
>
> >
> > The OpenWrt project does not have enough resources to maintain security 
> > patches
> > for the kernel on our own. OpenWrt relays on the LTS kernel maintenance and 
> > we
> > update to the most recent LTS version every few days or weeks in the 
> > maintained
> > branches. If some security patches are missing in the LTS kernel versions 
> > used
> > by OpenWrt it is probably best to approach the Linux stable team directly.
> >
> > See this blog post from Greg Kroah-Hartman, especially the "Keeping a secure
> > system" section:
> > http://kroah.com/log/blog/2018/02/05/linux-kernel-release-model/
>
> Yes, sure. And whether you or I agree with this or not is to some degree
> irrelevant, since what matters to the security people is that they see
> the bug fixed. In 90% of the cases I was able to dismiss CVEs
> since the subsystems in question are not in use by us (or most of OpenWrt
> for that matter. e.g, frame buffers), but some tricky ones remain.
>
> That said, there's a very large number of patches to the kernel in
> OpenWrt; mostly for new device function, pending fixes or whatnot;
> I guess few of these are actual security fixes.
>
> >> So, to user space:
> >>
> >> dnsmasq 2.86 - my pointing out that CVE-2021-45957 et al are false didn't 
> >> go
> >> over particularly well, even though they have been properly dismissed by
> >> the Simon Kelley and others.
> >
> > See my mail on the dnsmasq mailing list:
> > https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016161.html
>
> Yes, and was referred to and well understood by myself at least. Still, the
> objection is that Mitre have this as "disputed", which is rather unhelpful, 
> and
> that is what is being focused upon. Obviously I cannot fix something that 
> isn't
> broken and has no fix, so there's no satisfactory answer here to a security
> review beyond getting the CVEs dismissed from Mitre.
>
>
> >
> >> tcpdump 4.9.3 - CVE-2018-16303
> >
> > This CVE is not for tcpdump, but PDF-XChange Editor:
> > https://nvd.nist.gov/vuln/detail/CVE-2018-16303
>
> Sorry, trying to juggle lots of items here.
>
> https://nvd.nist.gov/vuln/detail/CVE-2018-16301
>
>
> >> Long since in OpenWrt patches.
> >>
> >> e2fsprogs 1.46.5 - CVE-2022-1304
> >
> > This is pretty hard to attack. You could provide a patch.
>
> This was the patch I provided here:
>
> >>
> >> I brought in this patch:
> >>
> >> diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c
> >> index b324c7b0..1a206a16 100644
>
> Yes, very large files on OpenWrt are unlikely without external
> media.
>
> >>
> >> If would be simply easier on the optics if I was able to ditch 5.1.5 in the
> >> build and just use 5.3 - is this possible; I'm sure there's been much
> >> discussion on this before, so please point me at that - will it break luci?
> >
> > An update to Lua 5.4 would be good, but I do not know which impact it has.
>
> Understood. I'm going to come back to this later in another post.
>
>
> >> There's much more, but that's quite enough for now.
> >
> > OpenWrt is a mostly volunteer run project. Especially (security) maintenance
> > does not get paid by companies. If you have some fixes tested patches would 
> > be
> > really helpful.
>
> Yes, I know, and to say my reliance upon OpenWrt over the years is 
> considerable
> would be an understatement, but my time is limited as well, and my focus
> must be on addressing specifics to the security review.  Still, I felt it
> better to at least have a partial discussion here, and do what little I can.
>
> I don't necessarily have time to roll patches in a format suitable
> for OpenWrt upstreaming; sometimes I think it's more constructive to simply
> point out what can be done, and have the maintainers do it. Maybe not ideal,
> but it's something.
>
> Look for some more posts on specific topics in the near future.
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@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, 

Re: SBOM Tool for OpenWRT to feed Dependency Track

[Dave Taht]

This work (cleaning up SBOM, clearly identifying CVEs, getting on top
of more) sounds like an *ideal* candidate for funding under the NLNET
entrust fund:

https://nlnet.nl/entrust/

Applications are easy, the amount available per project usually in the
range of 30-50k eu, and usually approval is very rapid.
Go for it! tell me what you called the proposal and I'll put in a good
word for you.

Somewhat related, I've been looking for someones in europe (for a
proposal to that fund) with xdp and ebpf experience to help both port
libreqos.io (or bracketqos) to openwrt, and also harden it against not
just DDOS attacks but malformed ecn usage.

On Mon, Oct 24, 2022 at 3:38 PM Hauke Mehrtens  wrote:
>
> On 10/18/22 16:38, Pfendtner Steffen wrote:
> > Hi,
> >
> > We decided to publish our internal fork of the Timesys SBOM Tool we found on
> > github. You find our version at: https://github.com/ads-tec/sbom-openwrt
> >
> > It takes a complete OpenWRT build tree as input and will generate a SBOM
> > in CycloneDX JSON Format for the currently configured image.
> > This SBOM can be fed into your personal dependency track instance.
> > See https://dependencytrack.org/ if you don't know what this is.
> >
> > In my opinion Dependency Track is much more usable compared to uscan.
> >
> > However Dependency Tack currently heavily relies on valid CPE ID. Thus you 
> > will
> > need to fix the CPE IDs in the OpenWRT package Makefiles - some are missing.
> > I think it would be a great security benefit for the OpenWRT ecosystem if we
> > get a best possible coverage of CPE IDs in the available Makefiles.
> >
> > I'll try to push our CPE ID additions upstream.
> >
> > Best regards,
> > Steffen Pfendtner
>
> Hi Steffen,
>
> Nice tool, do you have some "demo" output for a recent OpenWrt release
> somewhere?
>
> One advantage of uscan from my point of view is that I just have to open
> a website to see the results for OpenWrt master and the maintained
> branches and do not have to run some scripts and install some tooling
> myself.
>
> Having multiple tools for such tasks is always helpful. Normally every
> additional tool find additional problems.
>
> Adding the missing CPE IDs is no problem, someone just has to do it. If
> you already have some internal changes with additional CPE IDs it would
> be nice if you could send a patch or pull request adding them to OpenWrt
> master and then we can backport it to OpenWrt 22.03 too.
>
> Petr added the missing CPE IDs to 4 packages recently.
>
> Hauke
>
> ___
> openwrt-devel mailing list
> openwrt-devel@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

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

Re: CVEs in OpenWrt 22.03

[Dave Taht]

I feel your pain, and with the dual provenance of the openwrt kernel
(linux X.Y and usually a backport of mac80211) it gets harder.

(But other world vendors have it much, much harder, with their frankenkernels)

I don't know what guidelines are coming out of this effort
(https://openssf.org/ ) is anyone in openwrt part of those processes?

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

Various grant programs that could help

[Dave Taht]

I wanted to point out that various governments are making big internet
investments and establishing grant programs. I'm not aware in any
detail what is going on in europe (?), but recognition of the long
term maintenance and security problems our internet has today is now
at high levels, and putting a floor under the best orgs and people
doing the best work (such as openwrt) has to be on at least some
minds.

Not only is there the huge NTIA broadband program in the USA, but for
the first time the NSF has actually created
a program that is oriented more to how open source engineering works,
called POSE. There's a 1.5m phase two grant
process closing in october, and if anyone here would like to
collaborate on a proposal for POSE, doing something worthwhile,
please let me know offlist. Details here:
https://www.nsf.gov/pubs/2022/nsf22062/nsf22062.jsp

Less arduous than the NSF...

ARDC is doing a great job of finding things worth doing in the
wireless world. Recently they funded some of the LibreRouter project.
see https://grants.ardc.net

And read more about it here:

https://www.ampr.org/new-grants-management-system-to-make-applying-for-and-tracking-grants-easier/

nlnet has always been a great source of small grants:
https://nlnet.nl/project/current.html - they funded, in small part,
my efforts on this openwrt release (although I was supposed to be
working on something else!)

https://nlnet.nl/project/current.html

the comcast innovation fund is out of money for the year... :(





On Sat, Aug 13, 2022 at 6:13 AM Robert Marko  wrote:
>
> On Fri, 12 Aug 2022 at 23:12, Florian Fainelli  wrote:
> >
> > On 8/12/22 13:28, Robert Marko wrote:
> > > On Fri, 12 Aug 2022 at 21:45, Florian Fainelli  
> > > wrote:
> > >>
> > >> On 8/12/22 11:09, Robert Marko wrote:
> > >>> On Fri, 12 Aug 2022 at 19:54, Florian Fainelli  
> > >>> wrote:
> > 
> >  On 8/10/22 13:32, Robert Marko wrote:
> > > On Wed, 10 Aug 2022 at 22:30, Philip Prindeville
> > >  wrote:
> > >>
> > >> Not to play the devil's advocate but... do we want old kernels 
> > >> hanging out that long?
> > >>
> > >> 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.
> > >
> > > I have to agree with this.
> > > What would be the benefit for OpenWrt with having LTS kernels
> > > supported for 6 years?
> > 
> >  One aspect I could see is take for instance a device that is widely
> >  popular amongst our user base as was TI's ar7 for instance a while 
> >  back,
> >  and for which we might have done a Linux 5.4, or 5.10 version at the
> >  time but we do not wish to continue to maintain.
> > >>>
> > >>> I dont see how this is related to LTS kernel support.
> > >>
> > >> OK maybe I need to spell out my example more clearly. Let us say that we
> > >> have a release in 2019 of OpenWrt that supported TI AR7 based upon the
> > >> Linux 5.4 kernel.
> > >>
> > >> Fast forward to 2022, we decide to abandon TI AR7 in master and we stop
> > >> supporting it entirely for future releases. A very bad Linux security
> > >> problem show up, and because we care about our users, we keep updating
> > >> the LTS kernel that was used in the 2019.x release up until, say the
> > >> said kernel stops being supported. If that support time frame was 6
> > >> years, then we would really be helping our users.
> > >>
> > >> Maybe the wider discussion to be had, is:
> > >>
> > >> - when and how do we decide to deprecate a given Linux port, I assume it
> > >> is when no more users show up or maybe more realistically when OpenWrt
> > >> developers just cannot keep up with updating those devices because they
> > >> no longer use those themselves
> > >>
> > >> - how long do we want to keep supporting past OpenWrt releases with
> > >> kernel updates, 2 years, 3/4 years, 6 years to match the kernel
> > >> lifecycle they are based upon?
> > >
> > > As an idea, I understand this, it would basically be an "LTS" OpenWrt
> > > release that
> > > would receive security-only updates.
> > >
> > > However, we had a long discussion on the IRC today and the resources are 
> > > spread
> > > rather thin even currently with 2 or 3 releases being supported.
> > >
> > > If its gonna be a volunteer kind of no guarantees release, then maybe
> > > but I dont see
> > > how we can manage that as well.
> >
> > That is fair, if we are spread too thin, and clearly we are, then yes, I
> > agree we should focus on the latest releases and people who cannot
> > update for whatever reason, be it now unsupported hardware, or high
> > availability or whatever should find out a solution. It's open source
> > after all :)
> >
> >
> > >>
> > >>
> > >>>
> > 
> >  Being able to continue to deliver stable kernel updates in a stable
> >  OpenWrt branch could be a good way for users to pick up their next xDSL
> > 

D.C. Circuit Upholds FCC 2020 Order in 5.9 GHz Band.

[Dave Taht]

any of our hw capable of using this new band?

-- Forwarded message -
From: Louis Peraertz 
Date: Fri, Aug 12, 2022 at 11:27 AM
Subject: [WISPAMembers] Court Victory! D.C. Circuit Upholds FCC 2020
Order in 5.9 GHz Band.
To: 


Today, the United States Court of Appeals for the District of Columbia
Circuit (D.C. Circuit) issued an opinion that is great news for WISPA
operator members.  It upheld the Federal Communications Commission’s
(FCC) November 2020 Order and Further Notice of Proposed Rulemaking
(FNPRM) that allocated 45 megahertz of spectrum for unlicensed use and
30 megahertz of spectrum for Cellular Vehicle-To-Everything (C-V2X)
technologies.

In 1999, the FCC assigned 75 megahertz band of spectrum, from 5.850 to
5.925 GHz, for use by intelligent transportation systems.  In 2019,
however, at the request of WISPA and several other entities, the FCC
initiated a rulemaking proceeding to reallocate a portion of that
spectrum band for unlicensed use.  The rationale for the FCC
initiating that proceeding was that, in the intervening 20 years,
intelligent transportation systems did not develop as the FCC had
hoped they would.  In fact, as of 2020, no commercially marketed
vehicles used the 5.9 GHz band to provide vehicle safety features.

In November 2020, the FCC adopted an Order that would allow entities
to use 45 megahertz of spectrum on an unlicensed basis for indoor
operations.  With regard to unlicensed use of the spectrum for outdoor
operations, the FCC issued an FNPRM that sought comment on a number of
technical issues.  The FCC explicitly said, however, that, until it
resolved those pending issues in the FNPRM, entities could continue to
file for Special Temporary Authority grants or seek waivers to use
this 5.9 GHz spectrum for unlicensed operations outdoors.
The Intelligent Transportation Society of America, and other entities,
who wanted the FCC to continue to allocate 75 megahertz of spectrum
for intelligent transportation systems filed a petition for review
with the D.C. Circuit.  In their briefs, these entities argued, among
other things, that:  (1) the FCC’s Order violated the Transportation
Equity Act (which required the FCC to consult with the Department of
Transportation when allocating spectrum for the needs of intelligent
transportation systems); (2) the FCC failed to adequately explain that
30 megahertz of spectrum was sufficient for intelligent transportation
systems in the future; (3) the FCC lacks the automotive safety
expertise that the Department of Transportation has, so the Court
should not defer to the FCC’s judgment with regard to the 5.9 GHz
band; and (4) the FCC failed to consider the possibility that
unlicensed devices in the lower 45 megahertz would interfere with
communications in the upper 30 megahertz.

The D.C. Circuit panel of three judges that considered these arguments
unanimously rejected all of them.  I have attached a PDF version of
the Court opinion.  I am also attaching a regulatory guidance memo I
prepared that summarizes the FCC’s November 2020 Order and FNPRM.
That memorandum includes a link to the FCC’s Order and FNPRM.
Hopefully, this Court opinion persuades the FCC to efficiently resolve
the remaining issues in the FNPRM and adopt an Order that will allow
WISPs to use 45 megahertz of this 5.9 GHz spectrum for outdoor
operations without having to apply for Special Temporary Authority
grants or waivers.



Posted by Louis Peraertz to: "Member's Forum board, "Court Victory!
D.C. Circuit Upholds FCC 2020 Order in 5.9 GHz Band." topic.


Attachments
[D.C. Circuit Court Decision Upholding FCC 2020 5.9 GHz Order and
FNPRM. 8.12.2022. 115 PM.pdf]
[Regulatory Guidance Memo On 5.9 GHz. Order and FNPRM. 5,2021. 3 PM.pdf]

You are opted-in to the [Member's Forum] board.
This board is email-list enabled -- replying to this email will send
your message to the entire message board.
For best results if replying, please do so with a clean message (with
no reply or forward history in the message body).

If you want to stop receiving these emails please click here: opt-out
and unsubscribe


-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

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

Re: Reaching out to Greg KH for 6 year LTS kernel versions

[Dave Taht]

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-devel@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

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

anyone here on the starlink beta? How's the bloat? other features?

[Dave Taht]

I figure that getting the starlink terminal working at all
was a greater challenge than tackling the bufferbloat issue. I've long
worried of
course, that the mac layer on this thing was going to be very weird,
and since they were working with qca they'd end up burying everything
in the network offload processors, even though at present speeds the
cpu they are using is *loafing*, I'm not as optimistic as jon morton is as to
how easy the port of cake or fq_codel would be to their hardware as it
is variable bandwidth and thus needs bql-like backpressure.

Since there doesn't seem to be a gpl drop yet I don't know a lot more,
however there was a teardown of the hw and jim's posting and a start
at testing on reddit - the dslreports test was flawed in that ping did
not work at all

https://www.reddit.com/r/Starlink/comments/k0dwon/starlink_and_bufferbloat_testing/

rate limiting with sqm works beautifully:

https://www.reddit.com/r/Starlink/comments/jxkef9/ahat_is_your_starlinks_bufferbloat_score/

and the starlink teardown was good:
https://www.reddit.com/r/hardware/comments/kchxl8/starlink_teardown_and_analysis/

So I  think that this hardware actually has fq_codel AND hw rate limiting
in it... and openwrt... But pure either algo is not the right thing
for a starlink up or downlink
which is variable rate.

It would of course be great if somehow we could get loud enough for
musk to tweet back or hire a few of us to help 'em get it right I
had a friend of mine send him a suitably inscribed copy of toke's
"bufferbloat and beyond" via interoffice mail... :) but finding someone
up there more focused on the terminal software itself would be better.
I mean low latency should be their bread and butter and while Im sad
that the early tests are dismal, I am pretty confident that ultimately
they will get it right.

Me, well, I live on a sailboat these days, and would really like
to be using this service. And making it
way better, and adding cool features to the product.
-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

d...@taht.net  CTO, TekLibre, LLC Tel: 1-831-435-0729

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

[OpenWrt-Devel] fq_codel and sch_cake improvements for openwrt

[Dave Taht]

I have been busy on other stuff than embedded routing for quite some
time, but I'd like to start folding in some new stuff into openwrt
related to fq_codel starting in the next week or so (I am currently in
prague, heading to berlin next week) - with some new code that looks
quite promising in the out of tree

https://github.com/dtaht/fq_codel_fast
and
https://github.com/dtaht/sch_cake repos.

repos, related to the new SCE concept, that we spoke about also, at
ietf. Some background on that here:

https://lwn.net/SubscriberLink/783673/0e7d178ea322e386/

Anybody got any time to hang with me next week? Is it too late for the freeze?

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

[OpenWrt-Devel] OpenWrt and HOMENET talk at IETF recording

[Dave Taht]

Is now up here:

https://www.youtube.com/watch?v=y-7G2ItPwco=5m55

I was unaware of how far behind homenet had fallen on the openwrt
integration front until ted talked to me... and I then "threatened to
help". :P

The outline of all that remains in homenet left to do is in his talk.


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

Re: [OpenWrt-Devel] EU feedback on "Upload of software on radio equipment"

[Dave Taht]

Eric Luehrsen  writes:

> On 3/4/19 6:35 PM, Hauke Mehrtens wrote:
>> Hi,
>>
>> The European commission asked for feedback on the Radio Equipment
>> Directive (RED) regarding the restrictions on "Upload of software on
>> radio equipment"
>>
>> I posted here a comment in the name of the OpenWrt project:
>> https://ec.europa.eu/info/law/better-regulation/initiatives/ares-2018-6621038/feedback/F240894_en?p_id=380919
>> The deadline for comments was 4. March.
>>
>> Thank you for the help and also the others who posted feedback to the
>> European commission.
>>
>> More details can be found here:
>> https://fsfe.org/activities/radiodirective/
>>
>> Hauke
>
> Historical Reference
>
> US FCC attempted a similar thing a few years ago and it received some
> backlash. They chose to revise the interpretation instructions for
> the rule. Although a regulation (FCC rule) is flexible and less
> worrisome. Bad legislation can hang around for a long time.
>
> FCC NPRM:
> https://docs.fcc.gov/public/attachments/FCC-15-92A1.pdf
> FCC Informal News:
> https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates
> FCC Revised Interpretation:
> https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g%3D%3D=594280%20D02%20U-NII%20Device%20Security%20v01r03_number=39498
> Credible Response:
> https://ecfsapi.fcc.gov/file/60001333550.pdf

I appreciate y'all citing that ex parte brief of mine to the FCC.  I
have not been paying much attention to what's going on in the EU of
late, and would appreciate a brief on what's happening there now.

I will be at netdevconf and IETF in prague march 16th-31st, and still
have a few spare bunks on the houseboat if anyone going needs a place to
crash. Otherwise, I could make a detour to berlin, afterwards.

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

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

Re: [OpenWrt-Devel] [PATCH] build: Activate ASLR PIE by default

[Dave Taht]

Hauke Mehrtens  writes:

> On 2/13/19 11:51 PM, Felix Fietkau wrote:
>> On 2019-02-13 23:15, Hauke Mehrtens wrote:
>>> This will build all executable as Position Independent Executables (PIE)
>>> by default. PIE executable can make full use of Address Space Layout
>>> Randomization (ASLR) because all sections can be placed at random
>>> offsets of the executed program. This makes it harder to exploit bugs
>>> in our binaries.
>>>
>>> This will increase the size of executable, libraries are already build
>>> position independent and their size will not change.
>>>
>>> This increases the size of the resulting images by about 3% on MIPS BE.
>>> I tested this with the default configuration for the lantiq xrx200
>>> target.
>>>
>>> The size of the initramfs binaries increased by 2.88%:
>>> Without PIE:
>>> 5.303.716 openwrt-lantiq-xrx200-bt_homehub-v5a-initramfs-kernel.bin
>>> With PIE:
>>> 5.456.339 openwrt-lantiq-xrx200-bt_homehub-v5a-initramfs-kernel.bin
>>>
>>> With PIE activated the executable are getting bigger, here are some
>>> examples from the lantiq mips_24kc target:
>>>
>>> Without PIE:
>>> 112.309 /bin/opkg
>>> 299.061 /bin/busybox
>>> 456.549 /usr/sbin/wpad
>>>
>>> With PIE:
>>> 142.496 /bin/opkg   (26.87% increase)
>>> 388.404 /bin/busybox(29.87% increase)
>>> 580.128 /usr/sbin/wpad  (27.06% increase)
>>>
>>> With PIE activated the sections of the binaries are loaded to
>>> different offsets for each program instance like shown here:
>>>
>>> root@OpenWrt:/# cat /proc/self/maps
>>> 555c4000-55622000 r-xp  00:02 1030   /bin/busybox
>>> 55631000-55632000 r-xp 0005d000 00:02 1030   /bin/busybox
>>> 55632000-55633000 rwxp 0005e000 00:02 1030   /bin/busybox
>>> 55633000-55634000 rwxp  00:00 0
>>> 77ee2000-77f04000 r-xp  00:02 331/lib/libgcc_s.so.1
>>> 77f04000-77f05000 r-xp 00012000 00:02 331/lib/libgcc_s.so.1
>>> 77f05000-77f06000 rwxp 00013000 00:02 331/lib/libgcc_s.so.1
>>> 77f06000-77f9a000 r-xp  00:02 329/lib/libc.so
>>> 77fa9000-77fab000 rwxp 00093000 00:02 329/lib/libc.so
>>> 77fab000-77fad000 rwxp  00:00 0
>>> 7fb26000-7fb47000 rw-p  00:00 0  [stack]
>>> 7fefb000-7fefc000 r-xp  00:00 0
>>> 7ff0a000-7ff0b000 r--p  00:00 0  [vvar]
>>> 7ff0b000-7ff0c000 r-xp  00:00 0  [vdso]
>>> root@OpenWrt:/# cat /proc/self/maps
>>> 5561d000-5567b000 r-xp  00:02 1030   /bin/busybox
>>> 5568a000-5568b000 r-xp 0005d000 00:02 1030   /bin/busybox
>>> 5568b000-5568c000 rwxp 0005e000 00:02 1030   /bin/busybox
>>> 5568c000-5568d000 rwxp  00:00 0
>>> 77e8e000-77eb r-xp  00:02 331/lib/libgcc_s.so.1
>>> 77eb-77eb1000 r-xp 00012000 00:02 331/lib/libgcc_s.so.1
>>> 77eb1000-77eb2000 rwxp 00013000 00:02 331/lib/libgcc_s.so.1
>>> 77eb2000-77f46000 r-xp  00:02 329/lib/libc.so
>>> 77f55000-77f57000 rwxp 00093000 00:02 329/lib/libc.so
>>> 77f57000-77f59000 rwxp  00:00 0
>>> 7fd1c000-7fd3d000 rw-p  00:00 0  [stack]
>>> 7fefb000-7fefc000 r-xp  00:00 0
>>> 7ff6-7ff61000 r--p  00:00 0  [vvar]
>>> 7ff61000-7ff62000 r-xp  00:00 0  [vdso]
>>> root@OpenWrt:/#
>>>
>>> Signed-off-by: Hauke Mehrtens 
>>> ---
>>>
>>> I would like to get some comments if we should activate PIE by default.
>>> The advantage is that it will be harder to exploit OpenWrt, but on the 
>>> other hand the binaries are getting bigger. We could also restrict this 
>>> to some CPU types, but as targets share the binaries it is not really 
>>> possible to do this based on the target.
>>>
>>> I am not sure if this should go into the next release or wait for later.
>>>
>>> This could also break some packages, as it is possible to activate PIE 
>>> by default for some time many bugs are already fixed, but probably not 
>>> all of them.
>> I think this is a lot of extra bloat. Maybe we can add a restricted PIE
>> mode where packages can opt-in individually?
>
> So we should probably make it a chose with 3 options:
> 1. No PIE
> 2. Use PIE for exposed binaries
> 3. Use PIE for all binaries

I hate that we have to make choices like this for space reasons. Option
2 will help but means attackers will try to go after something else.
By exposed, you mean "on the network", I guess? 


>
> Then we need something in addition to the existing PKG_ASLR_PIE we
> already have to deactivate it.
>
> Do we want a generic name like this:
> PKG_CRITICAL
> or something specific to PIE:
> PKG_ASLR_PIE_PREFERED
>
> Hauke
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[OpenWrt-Devel] netdevconf + ietf airbnb share in prague?

[Dave Taht]

I might be going to either or both of these conferences. I am curious
if anyone else is going and would like to split an airbnb?

https://netdevconf.org/0x13/ has quite a lot of interest to openwrt
folk - in my case the wireless workshop, bpf, and l4s talks are of
note. I've got a talk at netdevconf *maybe* on opening up the 240/4
IPv4 address space.

Netdevconf is march 20-22nd, ietf is 23-

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

Re: [OpenWrt-Devel] MIPS stack security and other problems

[Dave Taht]

Hauke Mehrtens  writes:

> On 12/18/18 12:46 PM, Hauke Mehrtens wrote:
>> On 12/17/18 1:54 AM, Dave Taht wrote:
>>>
>>> A pretty deep look at home MIPS and arm routers, and a surprising bug in 
>>> Linux/MIPS - by mudge and co:
>>>
>>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
>>>
>>> I have no idea if current openwrt, or what prior releases... are subject to
>>> the problems they outline.
>>
>> In the second paper "Build Safety of Software in 28 Popular Home Router"
>> [0] they checked the "security" of multiple popular devices, by checking
>> if they activate ASLR, Non stack Exec, Relro and stack guards. The best
>> device was the Linksys wrt32x and this is based on OpenWrt with not so
>> many modifications. ;-) Just something like Samba downgrade to 3.0.37.
>> The paper also wonders why the other Linksys devices like the wrt1900ac
>> are much worse, but they probably do not use OpenWrt or a much older
>> version. The GPL source code tar.gz of the Linksys wrt32x, begins with
>> cloning from https://github.com/openwrt/openwrt.git
>>
>>
>> It is also interesting how different this approve to security checking
>> is to what the German BSI published in the "BSI TR-03148: Secure
>> Broadband Router:" [1].
>> You can build a device which scores 100% in the one and 0% in the other,
>> there is no overlap. ;-)
>>
>> Hauke
>>
>>
>> [0]:
>> https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf
>> [1]:
>> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile=2
>
> It looks like they ran checksec from
> http://github.com/slimm609/checksec.sh on the root file system of the
> devices and came up with these results. The numbers for the Linksys
> wrt32x look very similar to current OpenWrt master, even for MIPS
> CPUs.
>
> I attached two outputs of checksec to this mail from the lantiq target
> with a MIP24Kc CPU. One with master and the current default
> configuration and one with master + activated ASLR configuration
> option.
>
> You can generate these yourself like this:
> ../checksec.sh/checksec -d build_dir/target-mips_24kc_musl/root-lantiq/

This might be a useful tool to make more obvious security issues to
future builders of openwrt.

>
> ASLR increases the image size by about 2.8%:
> Without ASLR: 5.386.965 bytes
> With ASLR:5.540.565 bytes

To me this seems worth it on the larger flash sizes.

> This is caused by increased user space binary size, see for example
> busybox binary which is 7% bigger:
> Without ASLR: 425.532 bytes
> With ASLR:457.336 bytes
>
> The fortified function count does not work with fortify-headers, but
> only with glibc. With glibc some function calls are getting replaced
> with calls to *_chk functions which are taking extra arguments, this
> is done by some glibc header magic. For musl libc OpenWrt uses
> fortify-headers which overwrites the original functions and inlined
> some extra security checks into the calling application. The result
> should be similar, so I assume that we have at least in most places
> similar security for the glibc fortified functions.
> I checked this by compiling an test application and checked the
> assembler code, it contained some extra size checks.
>
> It looks like the detection does not work correctly for kernel modules.
>
> Currently RELRO is not activated for the following libraries:
>   root-lantiq/usr/lib/libbz2.so.1.0
>   root-lantiq/usr/lib/libbz2.so.1.0.6
>   root-lantiq/lib/libgcc_s.so.1
> this looks like a bug.
>
> For libgcc_s.so.1 also NX is disabled, which is not good.

Hmm. Does gcc still actually contain executable code in this segment?

> Some binaries do not use a stack canary, I assume that these binaries
> just do not have an array on the stack which could be exploited. The
> compiler adds stack canaries only to functions which the compiler
> thinks need it.
>
> ASLR is deactivated for root-lantiq/sbin/vdsl_cpe_control, because
> this application does not link any more when ASLR is activated, this
> is a bug in the package build system.
>
> Hauke
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] MIPS stack security and other problems

[Dave Taht]

Still... "Friends don't let friends run factory firmware".


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

Re: [OpenWrt-Devel] MIPS stack security and other problems

[Dave Taht]

Going back to my ancient cerowrt box, the stack space is actively being
relocated on this version, but marked executable...

7f8d4000-7f8f5000 rwxp  00:00 0  [stack]
7fff7000-7fff8000 r-xp  00:00 0  [vdso]

but there doesn't appear to be a vfp area on this ancient version of
openwrt.

... so it it appears to me that the paper is correct - two mips
"bugfixes" arrived at almost exactly the same time. The first, fixed
executable stacks and heaps, which already did ASLR, the second added an
executable vfpu area in a fixed location. Sigh.

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

Re: [OpenWrt-Devel] MIPS stack security and other problems

[Dave Taht]

Cutting this down a bit

>> Do the common MIPS CPUs support non executable stacks at all?

?

>> cpu_has_rixi is set to 0 for the ath79 SoCs for example, for lantiq some

Should this show up in /proc/cpuinfo? Or where?

>> automatic detection is done, but I haven't checked the result.
> ramips has RIXI enabled by default. This is the result for procd:

>> @Dave: From which device did you get the map and which kernel is used there?

I wanted to note that the exploit of vfpu hard codes a mips little endian return
statement, haven't got around to fiddling with big-endian. 

Since everybody is looking at procd, here's a look at 3 platforms.

* The first map I think I got was from Reboot (17.01.4,
  r3560-79f57e422d), or perhaps it was from the edgerouter X, which I
  talk to further down in this message

To clarify:

On a:

root@lupin-jeff:/proc/1# cat /proc/cpuinfo 
system type : Qualcomm Atheros QCA956X ver 1 rev 0
machine : Ubiquiti UniFi-AC-LITE
processor   : 0
cpu model   : MIPS 74Kc V5.0
BogoMIPS: 385.84
wait instruction: yes
microsecond timers  : yes
tlb_entries : 32
extra interrupt vector  : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 
0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented: mips16 dsp dsp2
shadow register sets: 1
kscratch registers  : 0
package : 0
core: 0
VCED exceptions : not available
VCEI exceptions : not available

we get

root@lupin-jeff:/proc/1# cat maps
0040-0040b000 r-xp  1f:04 999/sbin/procd
0041a000-0041b000 r--p a000 1f:04 999/sbin/procd
0041b000-0041c000 rw-p b000 1f:04 999/sbin/procd
0041c000-0041e000 rwxp  00:00 0 
00815000-0083c000 rwxp  00:00 0  [heap]
77d32000-77d54000 r-xp  1f:04 611/lib/libgcc_s.so.1
77d54000-77d55000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
77d56000-77d67000 r-xp  1f:04 633/lib/libjson_script.so
77d67000-77d68000 r--p 1000 1f:04 633/lib/libjson_script.so
77d68000-77d69000 rw-p 2000 1f:04 633/lib/libjson_script.so
77d6a000-77d7b000 r-xp  1f:04 655/lib/libblobmsg_json.so
77d7b000-77d7c000 r--p 1000 1f:04 655/lib/libblobmsg_json.so
77d7c000-77d7d000 rw-p 2000 1f:04 655/lib/libblobmsg_json.so
77d7e000-77d94000 r-xp  1f:04 300/usr/lib/libjson-c.so.2.0.2
77d94000-77d95000 r--p 6000 1f:04 300/usr/lib/libjson-c.so.2.0.2
77d95000-77d96000 rw-p 7000 1f:04 300/usr/lib/libjson-c.so.2.0.2
77d96000-77da9000 r-xp  1f:04 658/lib/libubus.so
77da9000-77daa000 r--p 3000 1f:04 658/lib/libubus.so
77daa000-77dab000 rw-p 4000 1f:04 658/lib/libubus.so
77dac000-77dc3000 r-xp  1f:04 614/lib/libubox.so
77dc3000-77dc4000 r--p 7000 1f:04 614/lib/libubox.so
77dc4000-77dc5000 rw-p 8000 1f:04 614/lib/libubox.so
77dc6000-77e58000 r-xp  1f:04 653/lib/libc.so
77e65000-77e66000 r--p  00:00 0  [vvar]
77e66000-77e67000 r-xp  00:00 0  [vdso]
77e67000-77e69000 rw-p 00091000 1f:04 653/lib/libc.so
77e69000-77e6b000 rwxp  00:00 0 
7ff12000-7ff33000 rw-p  00:00 0  [stack]

However a specific check for ALSR - watching the dynamic relos go for
"cat", at least, everything except the first two (which is normal), are
being relocated, and there appears to be no vfpu map here.

root@lupin-jeff:/proc/1# cat /proc/self/maps
0040-0044b000 r-xp  1f:04 879/bin/busybox
0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
7742a000-7744c000 r-xp  1f:04 611/lib/libgcc_s.so.1
7744c000-7744d000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
7744e000-774e r-xp  1f:04 653/lib/libc.so
774ed000-774ee000 r--p  00:00 0  [vvar]
774ee000-774ef000 r-xp  00:00 0  [vdso]
774ef000-774f1000 rw-p 00091000 1f:04 653/lib/libc.so
774f1000-774f3000 rwxp  00:00 0  # this DOES relocate
7f9ef000-7fa1 rw-p  00:00 0  [stack]

So I think this processor + build are doing the "right thing".

* However, this a wndr3800 with OpenWrt 18.06.1, r7258-5eb055306f

system type : Atheros AR7161 rev 2
machine : NETGEAR WNDR3700/WNDR3800/WNDRMAC
processor   : 0
cpu model   : MIPS 24Kc V7.4
BogoMIPS: 452.19
wait instruction: yes
microsecond timers  : yes
tlb_entries : 16
extra interrupt vector  : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 
0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented: mips16
shadow register sets: 1
kscratch 

Re: [OpenWrt-Devel] MIPS stack security and other problems

[Dave Taht]

Hauke Mehrtens  writes:

> On 12/17/18 1:54 AM, Dave Taht wrote:
>> 
>> A pretty deep look at home MIPS and arm routers, and a surprising bug in 
>> Linux/MIPS - by mudge and co:
>> 
>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
>> 
>> I have no idea if current openwrt, or what prior releases... are subject to
>> the problems they outline.
>
> In the second paper "Build Safety of Software in 28 Popular Home Router"
> [0] they checked the "security" of multiple popular devices, by checking
> if they activate ASLR, Non stack Exec, Relro and stack guards. The best
> device was the Linksys wrt32x and this is based on OpenWrt with not so
> many modifications. ;-) Just something like Samba downgrade to 3.0.37.
> The paper also wonders why the other Linksys devices like the wrt1900ac
> are much worse, but they probably do not use OpenWrt or a much older
> version. The GPL source code tar.gz of the Linksys wrt32x, begins with
> cloning from https://github.com/openwrt/openwrt.git
>
>
> It is also interesting how different this approve to security checking
> is to what the German BSI published in the "BSI TR-03148: Secure
> Broadband Router:" [1].
> You can build a device which scores 100% in the one and 0% in the other,
> there is no overlap. ;-)

It isn't really something I can put smiley faces about.

How many of the 28 can be reflashed with modern openwrt?

>
> Hauke
>
>
> [0]:
> https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf
> [1]:
> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile=2

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

Re: [OpenWrt-Devel] MIPS stack security and other problems

[Dave Taht]

John Crispin  writes:

> On 17/12/2018 23:18, Dave Taht wrote:
>> Rosen Penev  writes:
>>
>>> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:
>>>>
>>>> A pretty deep look at home MIPS and arm routers, and a surprising
>>>> bug in Linux/MIPS - by mudge and co:
>>>>
>>>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
>>>>
>>>> I have no idea if current openwrt, or what prior releases... are subject to
>>>> the problems they outline.
>>> As of kernel 4.14.88, I see the same problems.
>> Well, I see that the stack, at least, on kernel 4.4.92 on mips and
>> 4.14 on openwrt 18.06...
>>
>> is mapped rw only, with no execute bit.
>>
>> That doesn't mean the other other flaws discussed in the paper don't
>> exist, but at least current openwrt HEAD is using the right gcc version
>> to turn the right linkage on. Someone here with wy more expertise in
>> the compiler, here, should take a hard look at this and the paper.
>>
>>
>> root@lupin-jeff:~# cat /proc/self/maps
>> 0040-0044b000 r-xp  1f:04 879/bin/busybox
>> 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
>> 77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
>> 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
>> 771a6000-77238000 r-xp  1f:04 653/lib/libc.so
>> 77245000-77246000 r--p  00:00 0  [vvar]
>> 77246000-77247000 r-xp  00:00 0  [vdso]
>> 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
>> 77249000-7724b000 rwxp  00:00 0 # is this the heap?
>> 7fe06000-7fe27000 rw-p  00:00 0  [stack]
>>
>>
>>>> ___
>>>> openwrt-devel mailing list
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> Dave,
>
> too lazy to read thd pdf, in a nutshell whats the issue and what do we
> need to do do to mitigate it ?

From the paper: (It's the second comment regarding ALSR bypass via a
deterministic segment that concerns me most). They are claiming that the
emulation segment at

7000-8000 rwxp  00:00 0 

is a bad idea, in the paper. Which openwrt has.


"Timeline Key:
(A)
2001: Linux introduces FPU emulation in kernel 2.4.3.4. This puts code on the 
stack and
executes it there requiring the stack be marked as readable, writable, and 
executable.
(B)
2016 July:  a new page was introduced to execute branch delay slot 
instructions. This
was introduced to remove the code being inserted and executed on the program 
stack.
However, this fix introduced a new fixed location segment that can be used to 
bypass
ASLR defenses.
3
(C)
2016 August:  a patch to make the stack and heap non-execute was introduced, if 
a
PT_GNU_STACK was present. However, as noted in the patch none of the toolchains
used to build executables created a PT_GNU_STACK and the stack would remain
executable until this was addressed in compiler toolchains.
4
In summary, Linux MIPS binaries have been easier to exploit by way of classic 
stack overflow
attacks for over a decade, and continue to be so according to our examination 
of toolchain
patches. Additionally, the fix that moved FPU emulation off the stack created a 
separate DEP
and 
​
ASLR exposure.  Even if patches were introduced today for both the kernel and 
the
toolchains, the lag in adoption implies it could be years before Linux MIPS 
devices can be
expected to have basic DEP and ASLR.
"

Their proof of concept for exploiting this on mipsel is:

include 
#include 
#include 
#include 

int main(void) {
// set a pointer to the vfpu emulation page address
void* p = (void *)0x7000;
printf("%p\n", (void*)p);
// construct a function pointer from p
void (*func_ptr)(void) = p;
// 'jr $ra' mips32el instruction bytes
char code[] = {0x08, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x00, 0x00};
// copy the instruction to the vfpu page
memcpy(p, code, 8);
// call the function pointer, this should then directly return back
(*func_ptr)();
// print out the current maps of the process
char cmd[200];
sprintf(cmd, "cat /proc/%d/maps", getpid());
system(cmd);
return 0;
}


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

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

Re: [OpenWrt-Devel] MIPS stack security and other problems

[Dave Taht]

Rosen Penev  writes:

> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:
>>
>>
>> A pretty deep look at home MIPS and arm routers, and a surprising
>> bug in Linux/MIPS - by mudge and co:
>>
>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
>>
>> I have no idea if current openwrt, or what prior releases... are subject to
>> the problems they outline.
> As of kernel 4.14.88, I see the same problems.

Well, I see that the stack, at least, on kernel 4.4.92 on mips and
4.14 on openwrt 18.06...

is mapped rw only, with no execute bit.

That doesn't mean the other other flaws discussed in the paper don't
exist, but at least current openwrt HEAD is using the right gcc version
to turn the right linkage on. Someone here with wy more expertise in
the compiler, here, should take a hard look at this and the paper.


root@lupin-jeff:~# cat /proc/self/maps
0040-0044b000 r-xp  1f:04 879/bin/busybox
0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
771a6000-77238000 r-xp  1f:04 653/lib/libc.so
77245000-77246000 r--p  00:00 0  [vvar]
77246000-77247000 r-xp  00:00 0  [vdso]
77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
77249000-7724b000 rwxp  00:00 0 # is this the heap?
7fe06000-7fe27000 rw-p  00:00 0  [stack]


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

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

[OpenWrt-Devel] MIPS stack security and other problems

[Dave Taht]

A pretty deep look at home MIPS and arm routers, and a surprising bug in 
Linux/MIPS - by mudge and co:

https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html

I have no idea if current openwrt, or what prior releases... are subject to
the problems they outline.

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

Re: [OpenWrt-Devel] IPv6 and comcast fails

[Dave Taht]

Russell Senior  writes:

> Works for me, on current HEAD*, with ar71xx (netgear wndr3800). Can
> you include your /etc/config/network and any other relevant
> configuration details?
>
> * $ git describe
> reboot-8373-gbc3d47cd12

Good to hear.

Is yours configured as a bridge anywhere? My apu2 (x86) is not.

I can reconfigure a wndr3800 "out of the box" with both head and
stable and try that in a night or two on the network where the
arm is working. (production network can't fiddle)

As per the bug report, I see no responses to my ip6 queries.

Had 24 days of uptime...

apu2:

root@office:~# ifstatus wan6
{
"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcpv6",
"device": "eth0",
"data": {

}
}

I should see at least *some* ipv6 traffic here?

root@office:~# tcpdump -i eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:41:55.339916 IP6 fe80::20d:b9ff:fe43:a06c.546 > ff02::1:2.547: dhcp6
solicit
every x seconds...

... that's it.

ip6tables -F as well as -P whatever ACCEPT

Tried both reqprefix 56 and 60.

config interface 'wan6' 
option ifname 'eth0'   
option proto 'dhcpv6'  
option reqprefix '56'   
option dns '2001:558:feed::1 2001:558:feed::2'

...

while I'm here, have you had any success in getting a relay to work?

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

[OpenWrt-Devel] IPv6 and comcast fails

[Dave Taht]

We have confirmed fails for mips and x86 for even seeing any
ipv6 traffic on a comcast uplink, thus dhcpv6pd fails.

See:

https://bugs.openwrt.org/index.php?do=details_id=1763


And

https://forum.openwrt.org/t/openwrt-18-06-rc1-doesnt-obtain-ipv6-address/16759/6

It was bisected back a few months in the latter bug report.

However, I DO have ipv6 prefix delegation working on an arm a15
box running the current stable release.

Is there anything we can try to reconfigure (for ipv6 mcast?) to
even see these packets? Clue?


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

[OpenWrt-Devel] the "right" rbtree lib for openwrt?

[Dave Taht]

I'm in search of the "right" rbtree library to use to solve this bug in babel

https://github.com/dtaht/babeld/issues/31

I'm leaning towards libdict at the moment, but there are dozens. any
opinions? I wouldn't mind storing the red bit in the pointer,
across 36 different platforms

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

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

Re: [OpenWrt-Devel] Wshaper package dependencies fail with snapshot image-builder

[Dave Taht]

wshaper was just retired in favor of sqm-scripts and qos-scripts.

See

https://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die/

for why.


On Tue, Feb 7, 2017 at 1:14 AM, Mangesh Bhamre  wrote:
> Hello OpenWRT team,
>
> I am trying to build ramips/7620 router firmware with wshaper and
> luci-app-wshaper package.  Build fails due to dependency error.
>
> --
>  * satisfy_dependencies_for: Cannot satisfy the following dependencies for
> luci-app-wshaper:
>  * wshaper *
>  * opkg_install_cmd: Cannot install package wshaper.
> Makefile:146: recipe for target 'package_install' failed
> -
>
> Please provide a fix.
>
>
> Regards,
> Mangesh Bhamre
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] [Babel-users] Babeld now has procd support on OpenWRT/LEDE

[Dave Taht]

On Fri, Jan 13, 2017 at 8:11 AM, L. D. Pinney <ldpin...@yahoo.com> wrote:
> Go back to playing the guitar and smoking dopethat's what you do best.

I look forward very much to doing more of that... after lede ships.

In the interim, I have two fairly large testbeds setup to test lede -
the ATF patch, the dnsmasq-dnssec code, the bcp38 code, the dhcpv6-pd
code, the new bridging code, and babel integration are all high on my
list, along with sch_cake and the sqm-scripts. I have 5 lede platforms
under test - the archer c7v2, wndr3800, linksys 1200ac, uap-lite, and
picostation, with two more that I plan to add after testing interop
(edgerouter and an apu2). There are also 3 different brands of
cablemodem in the loop. Test clients include a dozen hackerboards
(kernels going back to 3.10), OSX, and Linux.

I'm perpetually testing edge cases and things that seem like they
should work, but don't. While things are vague and confusing (like,
babel-1.8's behavior being confusing in some instances) - and a piece
of a puzzle lands (like not restarting it as much, thus causing less
route retractions and floods) - I do tend to dump partial state about
the rathole I may have been going down.

I've been trying to come up with tests for understanding the true
effects of the multicast-unicast bridging code, for wifi primarily,
and simplifying. At the moment I'm more trying to test 3 layers of
lede dhcp-pd (bridged and routed scenarios) across gear that needs to
interop...

... instead of dealing with how all that feeds into babel source
specific routing - which is a combination of interactions between
netifd, babeld, and multicast/bridging.

>
> STOP CROSS POSTING YOU FSCKin' Clown Boy

If these projects want to write "no cross posting ever" into the
rules, I will gladly comply.

I hope you get your caps-lock key fixed.

I'm going to just filter out all further postings from you into my trash folder.


>
> On Saturday, January 14, 2017 12:06 AM, Dave Taht <dave.t...@gmail.com>
> wrote:
>
>
> On Fri, Jan 13, 2017 at 4:08 AM, L. D. Pinney <ldpin...@yahoo.com> wrote:
>> DAVE :
>>
>> WILL YOU PLEASE STOP YOUR FSCKin' CROSS POSTING ???
>
> I did not start the cross-post in this case.
>
>> This is UNRELATED to the OpenWrt / LEDE DEV mailing list...as the change
>> has
>> been merged.
>
> Interop with routing protocols... and networking in general... does
> exist outside of the openwrt universe. In my case I am deeply
> concerned about what happens against older, deployed versions of
> Linuxes (and other OSes) with the new multicast-unicast bridge
> conversion code in lede. Babel tends to use it, and I am also testing
> (in lede!), as per the below, the dhcpv6-pd code, interop-ing with
> several devices.
>
>> F O
>
> I'm really sorry that you hate cross posting so much. It must be
> terrible to have to elide additional responses or deal with bounce
> messages on every 20th email from me. And it must be wonderful to be
> living in a world where all you have is openwrt/lede devices on the
> network and modern kernels everywhere.
>
>>
>> On Friday, January 13, 2017 5:20 AM, Dave Taht <dave.t...@gmail.com>
>> wrote:
>>
>>
>> On Thu, Jan 12, 2017 at 1:01 PM, Baptiste Jonglez
>> <bapti...@bitsofnetworks.org> wrote:
>>> Hi,
>>>
>>> Here is yet another OpenWRT-related change for babeld: I just merged
>>> procd
>>> support for babeld [2], after more than two years of lingering [1].
>>>
>>> The only user-visible changes should be:
>>>
>>> - babeld now logs to the system log (visible with "logread") instead of a
>>>  file in /var/log.  This is nice for embedded devices, where you don't
>>>  want to write too much to the filesystem.  It is still possible to
>>>  explicitly configure babeld to use a log file;
>>>
>>> - babeld is now restarted automatically whenever it crashes;
>>>
>>> - the usual procd niceties: calling "/etc/init.d/babeld reload" will
>>>  restart babeld only if the configuration has changed.
>>>
>>>
>>> Please test babeld 1.8.0-2 and report any resulting breakage.  I would
>>> like this change (and the other compatibility change) to make it into the
>>> upcoming LEDE release, which is due to happen quite soon.
>>
>> Groovy.
>>
>> lede can dynamically insert/delete routes into tables from netifd
>> babeld can pull routes from "protos" but not tables.
>>
>> I spoke with hedecker (? can't remember his email) about somehow
>> having a field to export routes into kernel protos in the lede network
>> file, he indicated he'd look at it in 

Re: [OpenWrt-Devel] [LEDE-DEV] [Babel-users] Babeld now has procd support on OpenWRT/LEDE

[Dave Taht]

On Fri, Jan 13, 2017 at 4:08 AM, L. D. Pinney <ldpin...@yahoo.com> wrote:
> DAVE :
>
> WILL YOU PLEASE STOP YOUR FSCKin' CROSS POSTING ???

I did not start the cross-post in this case.

> This is UNRELATED to the OpenWrt / LEDE DEV mailing list...as the change has
> been merged.

Interop with routing protocols... and networking in general... does
exist outside of the openwrt universe. In my case I am deeply
concerned about what happens against older, deployed versions of
Linuxes (and other OSes) with the new multicast-unicast bridge
conversion code in lede. Babel tends to use it, and I am also testing
(in lede!), as per the below, the dhcpv6-pd code, interop-ing with
several devices.

> F O

I'm really sorry that you hate cross posting so much. It must be
terrible to have to elide additional responses or deal with bounce
messages on every 20th email from me. And it must be wonderful to be
living in a world where all you have is openwrt/lede devices on the
network and modern kernels everywhere.

>
> On Friday, January 13, 2017 5:20 AM, Dave Taht <dave.t...@gmail.com> wrote:
>
>
> On Thu, Jan 12, 2017 at 1:01 PM, Baptiste Jonglez
> <bapti...@bitsofnetworks.org> wrote:
>> Hi,
>>
>> Here is yet another OpenWRT-related change for babeld: I just merged procd
>> support for babeld [2], after more than two years of lingering [1].
>>
>> The only user-visible changes should be:
>>
>> - babeld now logs to the system log (visible with "logread") instead of a
>>  file in /var/log.  This is nice for embedded devices, where you don't
>>  want to write too much to the filesystem.  It is still possible to
>>  explicitly configure babeld to use a log file;
>>
>> - babeld is now restarted automatically whenever it crashes;
>>
>> - the usual procd niceties: calling "/etc/init.d/babeld reload" will
>>  restart babeld only if the configuration has changed.
>>
>>
>> Please test babeld 1.8.0-2 and report any resulting breakage.  I would
>> like this change (and the other compatibility change) to make it into the
>> upcoming LEDE release, which is due to happen quite soon.
>
> Groovy.
>
> lede can dynamically insert/delete routes into tables from netifd
> babeld can pull routes from "protos" but not tables.
>
> I spoke with hedecker (? can't remember his email) about somehow
> having a field to export routes into kernel protos in the lede network
> file, he indicated he'd look at it in a few weeks.
>
> (I wanted to get away from ever having to revise the conf file
> dynamically, but it looks like not this release. Not having to restart
> babeld as per the above is a nice improvement though and I'll get on
> testing it this weekend. At the moment I'm going through some mild
> hell with dhcpv6-pd on comcast and adding "sonic" fiber (with a HE
> ipv6 tunnel. Will hopefully have 4 source specific gateways to play
> with here)
>
> In other other news the "rabeld" backport of the gentler route switch
> change loses kernel routes on the vyatta (3.10 based) OS in the
> edgerouter. :(. That said, haven't tested mainline babeld there yet.
> It seems to work on debian.
>
> For those fiddling with edgerouter's default 1.9.x OS, backports of
> cake, iproute, and rabeld are presently here:
> https://build.lochnair.net/
>
>
>> Baptiste
>>
>> [1] https://github.com/openwrt-routing/packages/pull/55
>> [2] https://github.com/openwrt-routing/packages/pull/250
>
>>
>> ___
>> Babel-users mailing list
>> babel-us...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
>
> ___
> Lede-dev mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Babel-users] Babeld now has procd support on OpenWRT/LEDE

[Dave Taht]

On Thu, Jan 12, 2017 at 1:01 PM, Baptiste Jonglez
 wrote:
> Hi,
>
> Here is yet another OpenWRT-related change for babeld: I just merged procd
> support for babeld [2], after more than two years of lingering [1].
>
> The only user-visible changes should be:
>
> - babeld now logs to the system log (visible with "logread") instead of a
>   file in /var/log.  This is nice for embedded devices, where you don't
>   want to write too much to the filesystem.  It is still possible to
>   explicitly configure babeld to use a log file;
>
> - babeld is now restarted automatically whenever it crashes;
>
> - the usual procd niceties: calling "/etc/init.d/babeld reload" will
>   restart babeld only if the configuration has changed.
>
>
> Please test babeld 1.8.0-2 and report any resulting breakage.  I would
> like this change (and the other compatibility change) to make it into the
> upcoming LEDE release, which is due to happen quite soon.

Groovy.

lede can dynamically insert/delete routes into tables from netifd
babeld can pull routes from "protos" but not tables.

I spoke with hedecker (? can't remember his email) about somehow
having a field to export routes into kernel protos in the lede network
file, he indicated he'd look at it in a few weeks.

(I wanted to get away from ever having to revise the conf file
dynamically, but it looks like not this release. Not having to restart
babeld as per the above is a nice improvement though and I'll get on
testing it this weekend. At the moment I'm going through some mild
hell with dhcpv6-pd on comcast and adding "sonic" fiber (with a HE
ipv6 tunnel. Will hopefully have 4 source specific gateways to play
with here)

In other other news the "rabeld" backport of the gentler route switch
change loses kernel routes on the vyatta (3.10 based) OS in the
edgerouter. :(. That said, haven't tested mainline babeld there yet.
It seems to work on debian.

For those fiddling with edgerouter's default 1.9.x OS, backports of
cake, iproute, and rabeld are presently here:
https://build.lochnair.net/

> Baptiste
>
> [1] https://github.com/openwrt-routing/packages/pull/55
> [2] https://github.com/openwrt-routing/packages/pull/250
>
> ___
> Babel-users mailing list
> babel-us...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Slow DNSMasq with > 100, 000 entries in additional addresses file

[Dave Taht]

On Sat, Dec 31, 2016 at 12:15 AM, TheWerthFam <thewerth...@gmail.com> wrote:
> Quick report -
> So I didn't test pihole per say, but used that method of storing the
> blacklist into the hosts file for dnsmasq to use.  Dnsmasq must use a
> different storage method for its hosts file. I loaded 850439 entries in the
> hosts file and restarted dnsmasq. I uses 1/2 as much memory than if loaded
> as a conf-file like adblock does.  And its super fast and virtually non
> existent cpu usage.  DNS lookups perform just like it should.   Though the
> hosts file is now returning an IP address I specified for the blocked hosts
> - would have been nice to do the nxdomain.  Think this will work for my
> needs, I can put a second IP address on the router and run pixelserv on it
> or something like that.

Good to know. I'm still interested in finding more
"read-only-thus-discardable data" methods for protecting home networks
and routers, this for example:

https://plus.google.com/u/0/107942175615993706558/posts/635rm12isPq?sfc=true

> Cheers
> Derek
>
>
>
> On 12/29/2016 11:11 AM, Dave Taht wrote:
>>
>> On Thu, Dec 29, 2016 at 8:09 AM, TheWerthFam <thewerth...@gmail.com>
>> wrote:
>>>
>>> Right now I'd rather not customize the code.  There are two directions
>>> I'm
>>> going to try first.
>>> Give unbound a try to serve DNS, keeping Dnsmasq for DHCP.  If that
>>> doesn't
>>> work try converting the list to a hosts file pointing to a local pixelsrv
>>> address.  There are some other blog posts that indicate that the hosts
>>> file
>>> can handle a lot more entries.  Like https://github.com/pi-hole/pi-hole
>>> Maybe just run pi-hole on openwrt.
>>
>> Well, I've had a bit of fun feeding large blocklists into cmph. Using
>> the "chd" algorithm, it creates an index file from a 24MB blocklist
>> into a 800K one. (but you still need the original data and a secondary
>> index) I also fiddled a bit with bloom filters, which strike me as
>> appropo. It seems feasible to establish a large dataset of read-only
>> data with a fast index (that can be discarded in low memory
>> situations, rather than swapped out)
>>
>> I'll take a look at pi-hole...
>>
>>> Cheers
>>> Derek
>>>
>>>
>>> On 12/28/2016 02:21 PM, Dave Taht wrote:
>>>>
>>>> On Tue, Dec 27, 2016 at 11:03 PM, TheWerthFam <thewerth...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Thanks for the feedback, I'll look into NFQUEUE.  I'm forcing the use
>>>>> of
>>>>> my
>>>>> dns by iptables.  I'm also using a transparent squid and e2guardian to
>>>>> filter content.  I like the idea of the dns based blacklist to add some
>>>>> filtering capabilities since I don't want to try and filter https types
>>>>> sites.  I know no solution in perfect.
>>>>
>>>> I've been thinking about this, and given the large amount of active
>>>> data in a very small memory space have been thinking that another
>>>> approach would be more fruitful. Convert the giant table into a
>>>> "minimally perfect hash", and mmap it into memory read-only, so it can
>>>> be discarded under memory pressure, unlike ipset, squid, or dnsmasq
>>>> based approaches.
>>>>
>>>>
>>>>> Cheers
>>>>>Derek
>>>>>
>>>>>
>>>>>
>>>>> On 12/27/2016 01:53 PM, philipp_s...@redfish-solutions.com wrote:
>>>>>>>
>>>>>>> On Dec 26, 2016, at 10:32 AM, TheWerthFam <thewerth...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Using the adblock set of scripts to block malware and porn sites. The
>>>>>>> porn sites list is 800,000 entries, about 10x the number of sites
>>>>>>> adblock
>>>>>>> normally uses.  With the full list of malware and porn domains
>>>>>>> loaded,
>>>>>>> dnsmasq takes 115M of memory and normally sits around 50% CPU usage
>>>>>>> with
>>>>>>> moderate browsing usage.  CPU and RAM usage isn't really a problem
>>>>>>> other
>>>>>>> than lookups are slow now. Platform is cc 15.05.1 r49389 on banana pi
>>>>>>> r1.
>>>>>>>
>>>>>>> The adblock script takes the different lists, creates files in
>>>&g

Re: [OpenWrt-Devel] Slow DNSMasq with > 100, 000 entries in additional addresses file

[Dave Taht]

On Thu, Dec 29, 2016 at 8:09 AM, TheWerthFam <thewerth...@gmail.com> wrote:
> Right now I'd rather not customize the code.  There are two directions I'm
> going to try first.
> Give unbound a try to serve DNS, keeping Dnsmasq for DHCP.  If that doesn't
> work try converting the list to a hosts file pointing to a local pixelsrv
> address.  There are some other blog posts that indicate that the hosts file
> can handle a lot more entries.  Like https://github.com/pi-hole/pi-hole
> Maybe just run pi-hole on openwrt.

Well, I've had a bit of fun feeding large blocklists into cmph. Using
the "chd" algorithm, it creates an index file from a 24MB blocklist
into a 800K one. (but you still need the original data and a secondary
index) I also fiddled a bit with bloom filters, which strike me as
appropo. It seems feasible to establish a large dataset of read-only
data with a fast index (that can be discarded in low memory
situations, rather than swapped out)

I'll take a look at pi-hole...

> Cheers
>    Derek
>
>
> On 12/28/2016 02:21 PM, Dave Taht wrote:
>>
>> On Tue, Dec 27, 2016 at 11:03 PM, TheWerthFam <thewerth...@gmail.com>
>> wrote:
>>>
>>> Thanks for the feedback, I'll look into NFQUEUE.  I'm forcing the use of
>>> my
>>> dns by iptables.  I'm also using a transparent squid and e2guardian to
>>> filter content.  I like the idea of the dns based blacklist to add some
>>> filtering capabilities since I don't want to try and filter https types
>>> sites.  I know no solution in perfect.
>>
>> I've been thinking about this, and given the large amount of active
>> data in a very small memory space have been thinking that another
>> approach would be more fruitful. Convert the giant table into a
>> "minimally perfect hash", and mmap it into memory read-only, so it can
>> be discarded under memory pressure, unlike ipset, squid, or dnsmasq
>> based approaches.
>>
>>
>>> Cheers
>>>   Derek
>>>
>>>
>>>
>>> On 12/27/2016 01:53 PM, philipp_s...@redfish-solutions.com wrote:
>>>>>
>>>>> On Dec 26, 2016, at 10:32 AM, TheWerthFam <thewerth...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Using the adblock set of scripts to block malware and porn sites. The
>>>>> porn sites list is 800,000 entries, about 10x the number of sites
>>>>> adblock
>>>>> normally uses.  With the full list of malware and porn domains loaded,
>>>>> dnsmasq takes 115M of memory and normally sits around 50% CPU usage
>>>>> with
>>>>> moderate browsing usage.  CPU and RAM usage isn't really a problem
>>>>> other
>>>>> than lookups are slow now. Platform is cc 15.05.1 r49389 on banana pi
>>>>> r1.
>>>>>
>>>>> The adblock script takes the different lists, creates files in
>>>>> /tmp/dnsmasq.d/ entries looking like
>>>>> local=/domainnottogoto.com/   one entry per line.  The goal is to
>>>>> return
>>>>> NXDOMAIN to entries in the lists. Lists are sorted and with unique
>>>>> entries.
>>>>>
>>>>> I've tried increasing the cachesize to 10,000 but that made no change.
>>>>> Tried neg-ttl=3600 with default negative caching enabled with no
>>>>> change.
>>>>>
>>>>> Are there dnsmasq setting that will improve the performance?  or should
>>>>> it be configured differently to achieve this goal?
>>>>> Perhaps unbound would be better suited?
>>>>>
>>>>> Cheers
>>>>>  Derek
>>>>
>>>>
>>>> Not to rain on your parade, but the obvious defeat of this solution
>>>> would
>>>> be to point to an external website which does DNS lookups for you, and
>>>> then
>>>> edit the URL to have an IP address in place of the host name.
>>>>
>>>> I would use netfilter’s NFQUEUE and make a user-space decision based on
>>>> packet-destination (since it seems you’re filtering outbound traffic
>>>> requests).
>>>>
>>>> After all, it’s not the NAME you don’t want to talk to… it’s the HOST
>>>> that
>>>> bears that NAME.
>>>>
>>>> -Philip
>>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>>
>>
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Slow DNSMasq with > 100, 000 entries in additional addresses file

[Dave Taht]

On Tue, Dec 27, 2016 at 11:03 PM, TheWerthFam  wrote:
> Thanks for the feedback, I'll look into NFQUEUE.  I'm forcing the use of my
> dns by iptables.  I'm also using a transparent squid and e2guardian to
> filter content.  I like the idea of the dns based blacklist to add some
> filtering capabilities since I don't want to try and filter https types
> sites.  I know no solution in perfect.

I've been thinking about this, and given the large amount of active
data in a very small memory space have been thinking that another
approach would be more fruitful. Convert the giant table into a
"minimally perfect hash", and mmap it into memory read-only, so it can
be discarded under memory pressure, unlike ipset, squid, or dnsmasq
based approaches.


> Cheers
>  Derek
>
>
>
> On 12/27/2016 01:53 PM, philipp_s...@redfish-solutions.com wrote:
>>>
>>> On Dec 26, 2016, at 10:32 AM, TheWerthFam  wrote:
>>>
>>> Using the adblock set of scripts to block malware and porn sites. The
>>> porn sites list is 800,000 entries, about 10x the number of sites adblock
>>> normally uses.  With the full list of malware and porn domains loaded,
>>> dnsmasq takes 115M of memory and normally sits around 50% CPU usage with
>>> moderate browsing usage.  CPU and RAM usage isn't really a problem other
>>> than lookups are slow now. Platform is cc 15.05.1 r49389 on banana pi r1.
>>>
>>> The adblock script takes the different lists, creates files in
>>> /tmp/dnsmasq.d/ entries looking like
>>> local=/domainnottogoto.com/   one entry per line.  The goal is to return
>>> NXDOMAIN to entries in the lists. Lists are sorted and with unique entries.
>>>
>>> I've tried increasing the cachesize to 10,000 but that made no change.
>>> Tried neg-ttl=3600 with default negative caching enabled with no change.
>>>
>>> Are there dnsmasq setting that will improve the performance?  or should
>>> it be configured differently to achieve this goal?
>>> Perhaps unbound would be better suited?
>>>
>>> Cheers
>>> Derek
>>
>>
>> Not to rain on your parade, but the obvious defeat of this solution would
>> be to point to an external website which does DNS lookups for you, and then
>> edit the URL to have an IP address in place of the host name.
>>
>> I would use netfilter’s NFQUEUE and make a user-space decision based on
>> packet-destination (since it seems you’re filtering outbound traffic
>> requests).
>>
>> After all, it’s not the NAME you don’t want to talk to… it’s the HOST that
>> bears that NAME.
>>
>> -Philip
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Talks between OpenWrt and LEDE

[Dave Taht]

On Wed, Dec 21, 2016 at 12:29 PM, David Lang  wrote:
> On Wed, 21 Dec 2016, Kathy Giori wrote:
>
>> From a PR perspective, I strongly suggest keeping the term OpenWrt as
>> part of the branding of the project moving forward. It can just be
>> cosmetic (web site, etc.) but the name has so much history, and
>> positive connotation, that you don't want to lose that brand attached
>> to the development moving forward.
>
>
> I agree, I think this is an obvious choice to make. OpenWRT has a lot of
> name recognition, it would be foolish to throw that away.

Just to take the other side for rhetorical purposes, a purpose of a
re-branding exercise is to show a change in the "product" or
organisation behind it. OpenWrt is widely known... as a bleeding edge,
sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt
and Tomato get a lot more press for some reason. So do things like
Yocto. If lede were to succeed in meeting its other goals, coherently,
preserving "lede" and moving forward as a separate project does make
sense.

> David Lang
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] BT Home Hub 5 support

[Dave Taht]

since broadcom was sold to another company recently is there any sign
we'll see open drivers for the BCM4360 ?

On Tue, Nov 29, 2016 at 5:11 AM, Mauro M.  wrote:
> Hello,
>
> From the OpenWrt wiki page: https://wiki.openwrt.org/toh/bt/homehub_v5a
> I understand that support for BT Home Hub 5 was included in DD trunk.
>
> I pulled the latest trunk source 50013 from git, but the image is not built
> under bin/lantiq as expected.
>
> As deducted from the firmware images available on-line
> (openwrt-lantiq-xrx200-BTHOMEHUBV5A-install-uImage-initramfs) I am using:
> Target System (Lantiq)  --->
> Subtarget (XRX200)  --->
> Target Profile (Default Profile)  --->
>
> There is nothing else other than Default Profile. I was expecting to find a
> specific BTHOMEHUB5 configuration.
>
> I run a grep on the code and I found  the following:
>
> ./target/linux/lantiq/image/Makefile:Image/BuildKernel/Profile/BTHOMEHUBV5A=$(call
> Image/BuildKernel/Template,BTHOMEHUBV5A)
> ./target/linux/lantiq/image/Makefile:Image/Build/Profile/BTHOMEHUBV5A=$(call
> Image/BuildNAND/$(1),$(1),BTHOMEHUBV5A)
> ./target/linux/lantiq/image/Makefile:define LegacyDevice/BTHOMEHUBV5A
> ./target/linux/lantiq/image/Makefile:LEGACY_DEVICES += BTHOMEHUBV5A
> ./target/linux/lantiq/base-files/etc/board.d/01_leds:BTHOMEHUBV5A)
> ./target/linux/lantiq/base-files/etc/board.d/02_network:BTHOMEHUBV5A)
> ./target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata:
> BTHOMEHUBV5A)
> ./target/linux/lantiq/dts/BTHOMEHUBV5A.dts:model = "BTHOMEHUBV5A - BT
> Home Hub 5A";
>
> However I am not sure how to activate the build.
> Please could you help?
>
> Thank you in advance,
> Mauro
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] RFC netifd: UCI parameter to sort name servers in resolv.conf.auto

[Dave Taht]

One other point about provider order in dnsmasq.

dnsmasq added long ago the facility (particularly for reverse lookups
on ipv6) to bind source addresses to destination dns servers. This
solves a portion of this problem. Stuff coming in from one ipv6
network gets dns lookups out the right network (I don't remember all
the syntax now, I can go look)

Openwrt/lede would need to get away from using resolv.conf to do this
stuff more right, which is ok by me since it isn't up to this job.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] shutting down gb10 soon from the build cluster

[Dave Taht]

I can no longer afford to contribute ~$850/month to the openwrt and
lede projects' build clusters, so gb10 will be "going away" as soon as
travis tells me it's migrated off of, or aug 10th, whichever is
sooner.

It is still my hope that some sane way of funding the continuous
integration system and the maintainers of it emerges, as per this old
conversation here:

https://lists.openwrt.org/pipermail/openwrt-devel/2015-December/037781.html

but I've got to cut things back. It appears that the current openwrt
build cluster is sizeable enough for the load, currently, and gb10,
will not be especially missed.

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt] openwrt build system costs: support of or foundation over?

[Dave Taht]

ing openwrt better.
how would y'all like to spend it? ".

"We also have one time grants available for X and Y amounts - How have
you been supporting openwrt, how can we thank you?"

> If you and the OpenWrt team could explain the situation
> better, what's hosted where, what the costs are and I understand the
> situation better, I can recommend to prpl leadership that funding be
> considered.

My take on it was about 1.7k/month of google compute got all basic
builds done for everything in under 12 hours each. Arguably more than
one cluster should be used (security/safety/redundancy) and more than
one linux distro used to build it, and if there were ways to get the
build time down, or just test build new stuff faster, great...


> Eric
>
> On Mon, Dec 7, 2015 at 12:51 PM, Dave Taht <dave.t...@gmail.com> wrote:
>>
>> I am still not sure what prpl is for. Nor, what happens to donated
>> funds, if any...
>>
>> I have long wanted some non-profit org to serve as an intermediary
>> between the profit centered corps and the developers. I don't think
>> SPI or prpl is doing this right. Linaro sort of used to...
>>
>> There needs to be some sort of translation between the three parties
>> of real needs. A corp is used to paying X for Y, in particular, not
>> fuzzy donations...
>>
>> As sort of a test case for what I'm trying to explain, there are a few
>> people that contribute towards keeping the Continuous Integration and
>> build system of openwrt up and running, both in terms of hardware, and
>> time.
>>
>> Many have been doing it longer than I have, but for most of the last 4
>> years a lot of the visible hardware came from me (snapon, huchra,
>> gb-XX).
>>
>> For 14 months of that, courtesy of a google cloud grant that expired
>> last year, I was running 6(?) boxes at a cost of about $1750/month, +
>> 2 donated boxes from isc.org - and builds popped out in half a day for
>> everything.  I liked it
>>
>> I had to shut all but one machine off after that grant expired, and
>> isc has (sadly) just shut down their free non-profit hosting service
>> also... huchra is nearly gone, snapon has moved to sweden behind a fw
>> where it can't act as a host...
>>
>> ... and recently I see that the lack of enough machines in the build
>> system was annoying enough to at least one party to start up a new
>> box...
>>
>> ... but - dang it! -  the benefits of CI for openwrt should be
>> *obvious to everyone that uses it*. Especially including some big
>> corps for which the opex of a few thousand dollars a month isn't even
>> noticeable.
>>
>> HP supports debian's build cluster, for example.
>>
>> Now, of late, I've had a devil of a time keeping the lights on. My
>> contribution to the cluster costs me $220/month that I would rather
>> spend on... food, and fixing wifi in general, etc [1]
>>
>> So... I'd like it if there was some org(s) were paying these costs
>> (and for everyone else contributing a box themselves) rather than me.
>> That is a "support of" sort of thing, where control remains in the
>> hands of engineers that care. (In fact, I don't have to care, travis
>> takes care of the problems, I just pay the opex bill)
>>
>> If some org were to "take over" this responsibility, the control slips
>> to that org - gains management - and other BS - and the CI might not
>> get done as well.
>>
>> If some org were to however, take a wishlist of existing costs from
>> existing developers, turn that into a budget, present that to willing
>> commercial orgs, and turn that around to the requesting dev (and
>> publicly), then everyone's lives would be better. X for Y with the
>> help of Z.
>>
>> Mine, and (I think) most of openwrt folk's resistance to
>> "organizations" comes from the top down attempt at exerting control in
>> exchange for money.
>>
>> ...
>>
>> Certainly the build system could get done better! I was very happy
>> seeing benchmarks go by with how much faster they could be done... and
>> doing that right does involve human resources that might want to get
>> paid also... the main reason why gb-10 still exists is because it was
>> weeks of time to get it running in the first place, and easy to
>> replicate, and I'd hate to lose those invested weeks were more grant
>> money to arrive...
>>
>> Now: I have no intention of shutting down gb-10, but I came within
>> hours of having to do so, last month. Got saved by a shuttleworth
>> flash grant...
>>
>&

[OpenWrt-Devel] Fwd: [homenet] Protocol Action: 'Home Networking Control Protocol' to Proposed Standard (draft-ietf-homenet-hncp-10.txt)

[Dave Taht]

While I'm dreaming of steadier funding for things I care about,
ietf homenet wg's work is nearly complete.

*most* of the work is already done in openwrt to make all the ietf
homenet proposed standards work, and indeed, be the default in
openwrt. However nobody is funded anymore to take it further, and it
would be nice to see builds taking place and tested automagically - to
finally bring the dream of always interoperable, ipv6 capable cpe and
home routers, plugged in, every which way - a reality.

There are still many details left to make it happen well and be a
truly usable set of interoperable standards - I have a huge list of
things still not encapsulated or negotiated right within the hncp
stack, such as wifi channel selection and uplink bandwidth, and babel
is in need of some love, there are some state machine bugs that need
squashing.

-- Forwarded message --
From: The IESG 
Date: Tue, Dec 8, 2015 at 3:09 PM
Subject: [homenet] Protocol Action: 'Home Networking Control Protocol'
to Proposed Standard (draft-ietf-homenet-hncp-10.txt)
To: IETF-Announce 
Cc: homenet-cha...@ietf.org, m...@townsley.net,
draft-ietf-homenet-h...@ietf.org, The IESG ,
home...@ietf.org, terry.mander...@icann.org, rfc-edi...@rfc-editor.org


The IESG has approved the following document:
- 'Home Networking Control Protocol'
  (draft-ietf-homenet-hncp-10.txt) as Proposed Standard

This document is the product of the Home Networking Working Group.

The IESG contact persons are Brian Haberman and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/





Technical Summary

This document describes the Home Networking Control Protocol (HNCP),
an extensible distributed configuration protocol for “unmanaged”
(e.g., functions that are not configured manually or by a central
management server of some kind) home network devices. The intent is to
provide a distributed protocol for flooding of basic configuration
state essential to IP network functionality.

HNCP is described as a profile of and extension to the Distributed
Node Consensus Protocol (DNCP).  HNCP enables discovery of network
topology and borders, automated configuration of addresses (using the
algorithm defined in draft-ietf-homenet-prefix-assignment-08), name
resolution, and service discovery.

Working Group Summary

The earliest roots of HNCP are in draft-acee-ospf-ospfv3-autoconfig-00
(Oct 2011) which was eventually published as Standards Track RFC 7503,
 with the expectation that other documents would define
HOMENET-specific TLVs to be carried inside OSPFv3.

Strong resistance from the WG (as well as open source router software
developers) to this tight coupling between a specific routing protocol
and network configuration led to the split of HNCP as a standalone
protocol first defined in draft-stenberg-homenet-hncp-00.

Later, DNCP (generic aspects of HNCP concerning synchronization of
state among a set of nodes using Trickle[RFC6206]) were split from the
main HNCP document to allow for modularity and potential reuse. After
this final split, the HNCP document describes the HOMENET-specific
TLVs and the DNCP profile used to synchronize them across the home
network.

Document Quality

  Are there existing implementations of the protocol?

The reference “hnetd” implementation is at
https://github.com/sbyx/hnetd/ (project homepage at
http://www.homewrt.org/doku.php).

There is a second (fully independent and interoperable) implementation
available at https://github.com/jech/shncpd developed entirely from
the specification documents without referal to the reference
implementation.

There is a partial third implementation, though not fully independent,
available here: https://github.com/fingon/pysyma


  Have a significant number of vendors indicated their plan to
  implement the specification?


The reference implementation has been a part of routing feed of
OpenWrt since Barrier Breaker (14.07) release in July, 2014.

Google Nest, Comcast Xfinity, D-Link, Freebox, Technicolor, and Cisco
have all expressed interest in implementing and/or shipping HNCP. HNCP
is referenced in version 1.0 of the Thread Specification (Nest,
Samsung, etc.)

“Homenet” running either the early OSPF version and later HNCP (with
DNCP) has been demonstrated publicly at 9 IETF BnB events (every BnB
since BnB began, plus at least one “pre BnB” event), HNCP split off
from OSPF has been demontrated at the last 5 IETF BnB events. In
addition to IETF, Homenet Implementations have been presented at:

3 IPv6 World Congress events in Paris
1 CES Event in Las Vegas
1 Cablelabs Meeting in Denver, Co

Are there any reviewers that merit special mention as having done a
thorough review,  e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course

Re: [OpenWrt-Devel] Fwd: [homenet] Protocol Action: 'Home Networking Control Protocol' to Proposed Standard (draft-ietf-homenet-hncp-10.txt)

[Dave Taht]

On Tue, Dec 8, 2015 at 6:48 PM, L. D. Pinney <ldpin...@gmail.com> wrote:
> Why has this been cross posted to the OpenWrt Development List?
>
> I fail to see any relevance to the usual and prevailing use of this list.

Well, I do keep hoping more folk within openwrt actually try the
hnet-full and babel packages.  and unless someone actually pokes at
the list(s), once in a while, nothing happens. hnet includes a pretty
radical set of changes to how firewalling, ip address assignment and
dns are done...

If there is a better list to poke at, let me know. Sorry to be annoying.

> On Tue, Dec 8, 2015 at 10:52 AM, Dave Taht <dave.t...@gmail.com> wrote:
>>
>> While I'm dreaming of steadier funding for things I care about,
>> ietf homenet wg's work is nearly complete.
>>
>> *most* of the work is already done in openwrt to make all the ietf
>> homenet proposed standards work, and indeed, be the default in
>> openwrt. However nobody is funded anymore to take it further, and it
>> would be nice to see builds taking place and tested automagically - to
>> finally bring the dream of always interoperable, ipv6 capable cpe and
>> home routers, plugged in, every which way - a reality.
>>
>> There are still many details left to make it happen well and be a
>> truly usable set of interoperable standards - I have a huge list of
>> things still not encapsulated or negotiated right within the hncp
>> stack, such as wifi channel selection and uplink bandwidth, and babel
>> is in need of some love, there are some state machine bugs that need
>> squashing.
>>
>> -- Forwarded message --
>> From: The IESG <iesg-secret...@ietf.org>
>> Date: Tue, Dec 8, 2015 at 3:09 PM
>> Subject: [homenet] Protocol Action: 'Home Networking Control Protocol'
>> to Proposed Standard (draft-ietf-homenet-hncp-10.txt)
>> To: IETF-Announce <ietf-annou...@ietf.org>
>> Cc: homenet-cha...@ietf.org, m...@townsley.net,
>> draft-ietf-homenet-h...@ietf.org, The IESG <i...@ietf.org>,
>> home...@ietf.org, terry.mander...@icann.org, rfc-edi...@rfc-editor.org
>>
>>
>> The IESG has approved the following document:
>> - 'Home Networking Control Protocol'
>>   (draft-ietf-homenet-hncp-10.txt) as Proposed Standard
>>
>> This document is the product of the Home Networking Working Group.
>>
>> The IESG contact persons are Brian Haberman and Terry Manderson.
>>
>> A URL of this Internet Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/
>>
>>
>>
>>
>>
>> Technical Summary
>>
>> This document describes the Home Networking Control Protocol (HNCP),
>> an extensible distributed configuration protocol for “unmanaged”
>> (e.g., functions that are not configured manually or by a central
>> management server of some kind) home network devices. The intent is to
>> provide a distributed protocol for flooding of basic configuration
>> state essential to IP network functionality.
>>
>> HNCP is described as a profile of and extension to the Distributed
>> Node Consensus Protocol (DNCP).  HNCP enables discovery of network
>> topology and borders, automated configuration of addresses (using the
>> algorithm defined in draft-ietf-homenet-prefix-assignment-08), name
>> resolution, and service discovery.
>>
>> Working Group Summary
>>
>> The earliest roots of HNCP are in draft-acee-ospf-ospfv3-autoconfig-00
>> (Oct 2011) which was eventually published as Standards Track RFC 7503,
>>  with the expectation that other documents would define
>> HOMENET-specific TLVs to be carried inside OSPFv3.
>>
>> Strong resistance from the WG (as well as open source router software
>> developers) to this tight coupling between a specific routing protocol
>> and network configuration led to the split of HNCP as a standalone
>> protocol first defined in draft-stenberg-homenet-hncp-00.
>>
>> Later, DNCP (generic aspects of HNCP concerning synchronization of
>> state among a set of nodes using Trickle[RFC6206]) were split from the
>> main HNCP document to allow for modularity and potential reuse. After
>> this final split, the HNCP document describes the HOMENET-specific
>> TLVs and the DNCP profile used to synchronize them across the home
>> network.
>>
>> Document Quality
>>
>>   Are there existing implementations of the protocol?
>>
>> The reference “hnetd” implementation is at
>> https://github.com/sbyx/hnetd/ (project homepage at
>> http://www.homewrt.org/doku.php).
>>
>> There is a second (fully indepe

[OpenWrt-Devel] openwrt build system costs: support of or foundation over?

[Dave Taht]

I am still not sure what prpl is for. Nor, what happens to donated
funds, if any...

I have long wanted some non-profit org to serve as an intermediary
between the profit centered corps and the developers. I don't think
SPI or prpl is doing this right. Linaro sort of used to...

There needs to be some sort of translation between the three parties
of real needs. A corp is used to paying X for Y, in particular, not
fuzzy donations...

As sort of a test case for what I'm trying to explain, there are a few
people that contribute towards keeping the Continuous Integration and
build system of openwrt up and running, both in terms of hardware, and
time.

Many have been doing it longer than I have, but for most of the last 4
years a lot of the visible hardware came from me (snapon, huchra,
gb-XX).

For 14 months of that, courtesy of a google cloud grant that expired
last year, I was running 6(?) boxes at a cost of about $1750/month, +
2 donated boxes from isc.org - and builds popped out in half a day for
everything.  I liked it

I had to shut all but one machine off after that grant expired, and
isc has (sadly) just shut down their free non-profit hosting service
also... huchra is nearly gone, snapon has moved to sweden behind a fw
where it can't act as a host...

... and recently I see that the lack of enough machines in the build
system was annoying enough to at least one party to start up a new
box...

... but - dang it! -  the benefits of CI for openwrt should be
*obvious to everyone that uses it*. Especially including some big
corps for which the opex of a few thousand dollars a month isn't even
noticeable.

HP supports debian's build cluster, for example.

Now, of late, I've had a devil of a time keeping the lights on. My
contribution to the cluster costs me $220/month that I would rather
spend on... food, and fixing wifi in general, etc [1]

So... I'd like it if there was some org(s) were paying these costs
(and for everyone else contributing a box themselves) rather than me.
That is a "support of" sort of thing, where control remains in the
hands of engineers that care. (In fact, I don't have to care, travis
takes care of the problems, I just pay the opex bill)

If some org were to "take over" this responsibility, the control slips
to that org - gains management - and other BS - and the CI might not
get done as well.

If some org were to however, take a wishlist of existing costs from
existing developers, turn that into a budget, present that to willing
commercial orgs, and turn that around to the requesting dev (and
publicly), then everyone's lives would be better. X for Y with the
help of Z.

Mine, and (I think) most of openwrt folk's resistance to
"organizations" comes from the top down attempt at exerting control in
exchange for money.

...

Certainly the build system could get done better! I was very happy
seeing benchmarks go by with how much faster they could be done... and
doing that right does involve human resources that might want to get
paid also... the main reason why gb-10 still exists is because it was
weeks of time to get it running in the first place, and easy to
replicate, and I'd hate to lose those invested weeks were more grant
money to arrive...

Now: I have no intention of shutting down gb-10, but I came within
hours of having to do so, last month. Got saved by a shuttleworth
flash grant...

At the moment I am just sending the personal - not a single !@#!
corporate - donations I get at the below url to keep it running, and
not thinking about it very hard - but I just reached for some spare
cash to buy a new board, and came up empty.

it's the meta problem, of keeping infrastructure beneath the devs, in
general, with a minimal amount of overstructure on top, that's bugging
me today.

thx for listening. ideas?


Dave Täht
Keeping the lights on for open routers
[1] https://www.patreon.com/dtaht?ty=h
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4] ramips: add support for MQmaker WiTi board

[Dave Taht]

Is this the one with the promising 802.11ac chipset?

If so, how do I get a few?

If not, how do I get one? :)

On Thu, Dec 3, 2015 at 12:17 PM, John Crispin  wrote:
> offtopic ... my 2 samples of this board just arrived :) i know what i
> will be testing later on today
>
> On 03/12/2015 12:13, Felix Fietkau wrote:
>> On 2015-12-03 07:20, Sebastian Careba wrote:
>>> The board is based on mt7621AT cpu, and has 16mb nor flash, 256mb of ram, 2 
>>> sata ports, microsd card slot, 1 USB 3.0 port and at least one 2.4 and one 
>>> 5 ghz antenna. This is the 4th submission that fixes the naming scheme for 
>>> Mqmaker WiTi board.
>>> Patch v1 added initial support for MQmaker WiTi board. The device tree is 
>>> based on PBR-M1.
>>> Patch v2 changed the flash chip ID (w25q256 to gd25q128).
>>> Patch v3 fixed the left-out entry for WiTi in 02_network.
>>>
>>> Signed-off-by: Sebastian Careba 
>>> ---
>>>  .../patches-3.18/999-add_gd25q128_support.patch|  13 ++
>>>  .../linux/ramips/base-files/etc/board.d/02_network |   1 +
>>>  target/linux/ramips/base-files/etc/diag.sh |   1 +
>>>  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
>>>  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
>>>  target/linux/ramips/dts/WITI.dts   | 142 
>>> +
>>>  target/linux/ramips/image/Makefile |   7 +-
>>>  target/linux/ramips/mt7621/profiles/mqmaker.mk |  20 +++
>>>  8 files changed, 187 insertions(+), 1 deletion(-)
>>>  create mode 100644 
>>> target/linux/generic/patches-3.18/999-add_gd25q128_support.patch
>>>  create mode 100644 target/linux/ramips/dts/WITI.dts
>>>  create mode 100644 target/linux/ramips/mt7621/profiles/mqmaker.mk
>>>
>>> diff --git 
>>> a/target/linux/generic/patches-3.18/999-add_gd25q128_support.patch 
>>> b/target/linux/generic/patches-3.18/999-add_gd25q128_support.patch
>>> new file mode 100644
>>> index 000..e9c380b
>>> --- /dev/null
>>> +++ b/target/linux/generic/patches-3.18/999-add_gd25q128_support.patch
>>> @@ -0,0 +1,13 @@
>>> Index: linux-3.18.23/drivers/mtd/devices/m25p80.c
>>> ===
>>> --- linux-3.18.23.orig/drivers/mtd/devices/m25p80.c
>>> +++ linux-3.18.23/drivers/mtd/devices/m25p80.c
>>> @@ -352,7 +352,7 @@ static const struct spi_device_id m25p_i
>>>  {"en25q64"},{"en25qh128"},  {"en25qh256"},
>>>  {"f25l32pa"},
>>>  {"mr25h256"},   {"mr25h10"},
>>> -{"gd25q32"},{"gd25q64"},
>>> +{"gd25q32"},{"gd25q64"},{"gd25q128"},
>>>  {"160s33b"},{"320s33b"},{"640s33b"},
>>>  {"mx25l2005a"}, {"mx25l4005a"}, {"mx25l8005"},  {"mx25l1606e"},
>>>  {"mx25l3205d"}, {"mx25l3255e"}, {"mx25l6405d"}, {"mx25l12805d"},
>> Please drop this patch (see below).
>>
>>> --- /dev/null
>>> +++ b/target/linux/ramips/dts/WITI.dts
>>> @@ -0,0 +1,142 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "mt7621.dtsi"
>>> +
>>> +/ {
>>> +compatible = "mediatek,mt7621-eval-board", "mediatek,mt7621-soc";
>>> +model = "MQmaker WiTi";
>>> +
>>> +memory@0 {
>>> +device_type = "memory";
>>> +reg = <0x0 0x1000>;
>>> +};
>>> +
>>> +chosen {
>>> +bootargs = "console=ttyS0,57600";
>>> +};
>>> +
>>> +sdhci@1013 {
>>> +status = "okay";
>>> +};
>>> +
>>> +palmbus@1E00 {
>>> +spi@b00 {
>>> +status = "okay";
>>> +
>>> +m25p80@0 {
>>> +#address-cells = <1>;
>>> +#size-cells = <1>;
>>> +compatible = "gd25q128";
>> Please use 'jedec,spi-nor' here, so you don't have to patch in the
>> device id for this chip.
>>
>> - Felix
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] buildbot: gb15 fails to upload due to host keys

[Dave Taht]

On Mon, Nov 23, 2015 at 11:07 AM, Zoltan HERPAI  wrote:
> Hannu A Nyman wrote:
>>
>> Well, both gb15 and buildslave2 still fail to upload binaries, and as they
>> are making 9 of the 22 concurrent builds, almost half of the compiled
>> binaries are discarded. Sad.
>>
>> Logs from today:
>>
>> http://buildbot.openwrt.org:8010/builders/x86.kvm_guest/builds/119/steps/shell_11/logs/stdio
>>
>> http://buildbot.openwrt.org:8010/builders/brcm2708/builds/126/steps/shell_11/logs/stdio
>>
>>  Upload Snapshot to Openwrt
>>  Host key verification failed.
>>  rsync: connection unexpectedly closed (0 bytes received so far) [sender]
>>  rsync error: unexplained error (code 255) at io.c(605) [sender=3.0.9]
>
> gb15 is fixed now.

I note that I have long been paying for the google openwrt build
cluster out of my own pocket (after the google grant expired last year
- which was costing 1700/month for 5? 6? servers), but I had cut it
down to just gb10, which is cost me about $250/month.

I am hoping some more grant money arrives (not a lot!) next year.

I was unaware of gb15 (not coming out of my account, thankfully), and
am glad someone else is covering costs on it...

IF there is a need to turn around openwrt builds even quicker, (how
much quicker can it be done?) we can re-scale up my old google cluster
if there is funding for it from somewhere. I can keep the one server
I'm contributing up and running indefinitely. Or... ?

I have always wished we could do a full build in under 3 hours, and
could circulate package changes around in minutes, rather than in a
full build.



>
> Regards,
>
> -w-
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] dan gillmor nails why I just did what I did

[Dave Taht]

From:

http://www.slate.com/blogs/future_tense/2015/10/15/trans_pacific_partnership_could_thwart_computer_security_research_and_tinkering.html

"Surely our government isn't insane enough to thwart research designed
to keep us safer in the emerging “Internet of Things.” Yet tell that,
for starters, to the automobile industry, where one of the world's
largest car makers, Volkswagen, cheated on emissions testing by
tweaking its software. This crime against humanity—not an
exaggeration, given the massive contribution this may have made to
accelerating climate change—was discovered by researchers who, by good
luck, discovered that VW's cars had been spewing vastly more
pollutants than the company claimed for years. This almost certainly
would have been uncovered much earlier had the industry not relied on
the Digital Millennium Copyright Act to “protect” its software from
analysis; the DMCA made it illegal to circumvent “digital restrictions
management.” Yet the automakers continue to adamantly oppose any
exception to the DMCA.

This TPP provision, assuming it's in the final document—won't it be
great when our government allows us to actually see it?—is just one of
the many, many terrible “intellectual property” arrangements aimed at
giving corporations greater control over their customers. When
software is part of a product, as it is in so many things today and
almost everything tomorrow, the very concept of ownership becomes an
abstraction for the alleged buyer. And when we risk harsh penalties
for even attempting to repair a device that's defective, whether
that's because of the seller's incompetence or venality, we are in a
totally untenable, and frighteningly insecure, position.

We need to be going in precisely the opposite direction, and a
too-little-noticed proposal this week shows how it might be done. A
group of security experts looked into the absolutely horrifying, and
willful, lack of security in devices most of us use every
day—especially the Wi-Fi routers that let us share one Internet
connection among a variety of devices—and asked the Federal
Communications Commission to intervene.

In a letter to the FCC and a press release explaining their goals,
more than 250 people, including Vint Cerf, one of the Internet's
creators, implored the agency to make these crucial devices more
secure by forcing manufacturers to be more open about how they work.
Among other things, the security experts asked the FCC to require that
device makers a) provide public access to “source code”—the
programming instructions that operate the device—so that it can be
analyzed; b) provide ongoing security updates in timely ways; and c)
be prevented from selling devices that don't comply with those and
other rules designed to ensure security.

The FCC should make this happen yesterday. Then, regulators and
Congress should extend the compelling logic of this proposal to other
devices—notably cars and mobile phones—that are notoriously riddled
with flaws.

Meanwhile, it's vital that Congress not agree to the TPP as it's
currently written. Thankfully, the deal is in trouble. Let's hope the
odd-couple combination of a corporate-dominated Obama administration
and a Republican-controlled Congress doesn't override common sense and
the public good."

Scientists and Engineers have a mandate to obey physical law. Lawyers,
and lobbyists, not so much.

Dave Täht
I just lost several years of my life to making wifi better. And the
FCC wants to mess all that up. https://www.gofundme.com/savewifi
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] how we hope to fix wifi and the internet

[Dave Taht]

I think many of those here would be delighted to read about our
proposal to washington dc, and other regulators of wifi in the world.

http://www.businesswire.com/news/home/20151014005564/en/Global-Internet-Experts-Reveal-Plan-Secure-Reliable

I note our main servers got completely slammed, you can
get the letter from this alternate url, instead.

http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf

-- 
Dave Täht
Do you want faster, better, wifi? https://www.patreon.com/dtaht
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Last call for signatures to the FCC on the wifi lockdown issue

[Dave Taht]

The CeroWrt project's letter to the FCC on how to better manage the
software on wifi and home routers vs some proposed regulations is now
in last call for signatures. The final draft of our FCC submittal is
here:

https://docs.google.com/document/d/15QhugvMlIOjH7iCxFdqJFhhwT6_nmYT2j8xAscCImX0/edit?usp=sharing

The principal signers (Dave Taht and Vint Cerf), are joined by many
network researchers, open source developers, and dozens of developers
of aftermarket firmware projects like OpenWrt.

Prominent signers currently include:

Jonathan Corbet, David P. Reed, Dan Geer, Jim Gettys, Phil Karn, Felix
Fietkau, Corinna "Elektra" Aichele, Randell Jesup, Eric S. Raymond,
Simon Kelly, Andreas Petlund, Sascha Meinrath, Joe Touch, Dave Farber,
Nick Feamster, Paul Vixie, Bob Frankston, Eric Schultz, Brahm Cohen,
Jeff Osborn, Harald Alvestrand, and James Woodyatt.

If you would like to join our call for substituting sane software
engineering practices over misguided regulations, the window for
adding your signature to the letter closes at 11:59AM ET, today,
Friday, 2015-10-08.

Sign via webform here: http://goo.gl/forms/WCF7kPcFl9

We are at approximately 170 signatures as I write.

For more details on the controversy we are attempting to address, or
to submit your own filing to the FCC see:

https://libreplanet.org/wiki/Save_WiFi
https://www.dearfcc.org/

Sincerely,

Dave Täht
CeroWrt Project Architect
Tel: +46547001161
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] the cerowrt project's letter to the fcc about the wifi lockdown is nearly final

[Dave Taht]

see:

https://docs.google.com/document/d/1E1D1vWP9uA97Yj5UuBPZXuQEPHARp-AhRqUOeQB2WPk/edit?usp=sharing

for more details.

We still have a boatload of footnotes (help?) to add back in properly,
and there are no doubt other problems we will catch in the morning.
Comment away!

As we are hard up against deadlines, and I no longer expect
substantial changes, all new offers of signature will be considered
final.

signatures are now being collected via: http://goo.gl/forms/WCF7kPcFl9
- the 70+ that have already committed need to be contacted again to
approve this draft.


-- 
Dave Täht
Do you want faster, better, wifi? https://www.patreon.com/dtaht
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ar71xx: fix 100/10mbps ethernet link issues on mynet range extender

[Dave Taht]

TX delay setting? What else can it do?

My dream has been to find a way to set the tx completion interrupt
to only return with a soft set rate. So if I had a gigE connection
but my uplink was only 10Mbits, it would return the interrupt
after 1.3ms had expired.

this would let me get away entirely from using software rate limiting
with htb, just program a register once with the uplink rate, and
let bql and fq_codel handle the rest.

On Wed, Jun 03, 2015 at 05:20:22PM +0200, Christian Lamparter wrote:
 The mynet range extender hardware is suffering from ethernet
 link loss when booting with a recent openwrt image. This only
 happens on 100mbps links, with 1Gbps speed the link was fine.
 
 The cause of the problem is that the AR8035 PHY (aka F1E)
 requires turning on and off the special TX delay setting
 depending on the speed of the link.
 
 The 10mbps mode only needed the proper pll value, which was
 extracted from the vendor code.
 
 Reported-by: Pascal Paradis
 Signed-off-by: Christian Lamparter chunk...@googlemail.com
 ---
  .../ar71xx/files/arch/mips/ath79/mach-mynet-rext.c | 20 
  ...t-phy-at803x-allow-to-configure-via-pdata.patch | 53 
 --
  2 files changed, 69 insertions(+), 4 deletions(-)
 
 diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c 
 b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
 index 02d168e..3d48ca8 100644
 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
 +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
 @@ -14,6 +14,7 @@
  #include linux/platform_device.h
  #include linux/ath9k_platform.h
  #include linux/ar8216_platform.h
 +#include linux/platform_data/phy-at803x.h
  
  #include asm/mach-ath79/ar71xx_regs.h
  
 @@ -124,6 +125,21 @@ static struct gpio_keys_button mynet_rext_gpio_keys[] 
 __initdata = {
   },
  };
  
 +static struct at803x_platform_data mynet_rext_at803x_data = {
 + .disable_smarteee = 0,
 + .enable_rgmii_rx_delay = 1,
 + .enable_rgmii_tx_delay = 0,
 + .fixup_rgmii_tx_delay = 1,
 +};
 +
 +static struct mdio_board_info mynet_rext_mdio0_info[] = {
 +{
 +.bus_id = ag71xx-mdio.0,
 +.phy_addr = 4,
 +.platform_data = mynet_rext_at803x_data,
 +},
 +};
 +
  static void mynet_rext_get_mac(const char *name, char *mac)
  {
   u8 *nvram = (u8 *) KSEG1ADDR(MYNET_REXT_NVRAM_ADDR);
 @@ -169,12 +185,16 @@ static void __init mynet_rext_setup(void)
  
   ath79_register_mdio(0, 0x0);
  
 + mdiobus_register_board_info(mynet_rext_mdio0_info,
 + ARRAY_SIZE(mynet_rext_mdio0_info));
 +
   /* LAN */
   mynet_rext_get_mac(et0macaddr=, ath79_eth0_data.mac_addr);
  
   /* GMAC0 is connected to an external PHY on Port 4 */
   ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
   ath79_eth0_data.phy_mask = BIT(4);
 + ath79_eth0_pll_data.pll_10   = 0x1313; /* athrs_mac.c */
   ath79_eth0_pll_data.pll_1000 = 0x0e00; /* athrs_mac.c */
   ath79_eth0_data.mii_bus_dev = ath79_mdio0_device.dev;
   ath79_register_eth(0);
 diff --git 
 a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
  
 b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
 index babc695..d046ede 100644
 --- 
 a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
 +++ 
 b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
 @@ -32,6 +32,14 @@
   #define AT803X_DEBUG_SYSTEM_MODE_CTRL   0x05
   #define AT803X_DEBUG_RGMII_TX_CLK_DLY   BIT(8)
   
 +@@ -50,6 +60,7 @@ MODULE_LICENSE(GPL);
 + struct at803x_priv {
 + bool phy_reset:1;
 + struct gpio_desc *gpiod_reset;
 ++int prev_speed;
 + };
 + 
 + struct at803x_context {
  @@ -61,6 +71,43 @@ struct at803x_context {
   u16 led_control;
   };
 @@ -120,16 +128,53 @@
   return 0;
   }
   
 +@@ -258,6 +334,8 @@ static int at803x_config_intr(struct phy
 + static void at803x_link_change_notify(struct phy_device *phydev)
 + {
 + struct at803x_priv *priv = phydev-priv;
 ++struct at803x_platform_data *pdata;
 ++pdata = dev_get_platdata(phydev-dev);
 + 
 + /*
 +  * Conduct a hardware reset for AT8030 every time a link loss is
 +@@ -287,6 +365,26 @@ static void at803x_link_change_notify(st
 + } else {
 + priv-phy_reset = false;
 + }
 ++}
 ++if (pdata-fixup_rgmii_tx_delay 
 ++phydev-speed != priv-prev_speed) {
 ++switch (phydev-speed) {
 ++case SPEED_10:
 ++case SPEED_100:
 ++at803x_dbg_reg_set(phydev,
 ++AT803X_DEBUG_SYSTEM_MODE_CTRL,
 ++AT803X_DEBUG_RGMII_TX_CLK_DLY);
 ++break;
 ++case SPEED_1000:
 ++

Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt

[Dave Taht]

On Wed, Oct 08, 2014 at 11:10:46PM +0300, Hannu Nyman wrote:
 Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014:
  So I don't know where to go. Certainly I'd like to see the battle
 hardened sqm scripts (which are more flexible than the C code above)
 get more widely used and in BB.
 
 SQM seems to work ok with the current Chaos Calmer trunk.

Well, for now... I'd expect the delta to break eventually...

 
 I have included your SQM in my trunk WNDR3700/3800 community build (
 https://forum.openwrt.org/viewtopic.php?id=28392 ) and it works ok.
 Arokh has also picked it up for his build (
 https://forum.openwrt.org/viewtopic.php?id=50914 ). So you might get
 more feedback sooner or later, if users of our builds really do try
 it.

Excellent. I'd *really* like to get some testers doing ingress shaping
at above 60-80mbits, which seems to be a brick wall we've hit on
the ar71xx and octeon, on other platforms like the arm and x86.

A tool we use a lot is netperf-wrapper.

 I feel that the best way to get wider testing and real-life usage
 for SQM would be to create a pull request in the new packages feed
 in Github, to get both the SQM itself and the Luci frontend included
 there. Being available in the packages feed would create more
 interest for the package. If it proves to work ok, the devs might
 then import it into the core Openwrt repo (where the old qos-scripts
 is).

I went to sleep pre BBrc1. I woke up, and everything was in github.

It's still not clear to me how I'd build cero from frozen BB sources,
rather than the evolving github packages.

 
 
 Ps. For my own build I made a slight modification to the Luci menu item, as 
 pure SQM does not say much. I changed it to SQM QoS.
 

Yes, SQM by itself doesn't mean enough.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt

[Dave Taht]

On Thu, Oct 09, 2014 at 01:01:48AM +0200, Stephan Günther wrote:
 Hi,
 
 On Wed, Oct 8, 2014 at 10:10 PM, Hannu Nyman hannu.ny...@iki.fi wrote:
  Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014:
  So I don't know where to go. Certainly I'd like to see the battle hardened
  sqm scripts (which are more flexible than the C code above) get more widely
  used and in BB.
 
  SQM seems to work ok with the current Chaos Calmer trunk.
 
 Works for mee too, and performs much better than the old luci-app-qos.
 I would love to see this as part of OpenWrt.

OK. I don't see it feasible to retire qos-scripts as that has less dependencies
than sqm does - sqm needs ip and tc to function.

But I'd certainly like to see it available in the main openwrt repo by default.

And: I'd like the next version to do what sqm does, in pure c,
at line rate OR software rate limited, faster, better,
smaller... 
 
 I did some RRUL test using netperf-wrapper on my ADSL 15/1Mbps PPPoE
 link and it looks good in the graphs. I also have an 6in4 tunnel

I always love it when people post their results and the .json.gz files
for the various netperf-wrapper tests somewhere. It has been good to 
build an ever increasing database of valid tests and valid setups, given
that things like speedtest.net are so lame.

Examples:

http://burntchrome.blogspot.com/2014_05_01_archive.html

http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html

While I'm at it there were a couple manefestos along the way.

This explains exactly where and why wondershaper was flawed:

http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die

And this talks to the need for fq + aqm on *everything*

http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/

(I was unhappy qos-scripts just disabled ecn entirely. ECN is looking
 safely deployable in a fq'd system IMHO).

Last manefesto above does not go into the (slight) remaining need for a few 
levels
of classification, one reason is here:

http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-b.pdf

It is my hope that by explaining the why of sqm we could 
come up with something better before making it available
at larger scale.

 inside PPPoE and IIRC fq_codel should detect these ipv6 flows. RRUL

fq_codel dissects the headers for ipip, ipv6, gre and another protocol
I forget, correctly, and fq's them correctly. 

However my head explodes as to what happens or which
device should be used when that is further encapsulated.

 looks good at IPv6. Had this running at home for some days now, with
 moderate traffic and no issues so far.

Well loading it up is the only way to tell if you're winning.

 But I was wondering which interface to select luci-app-sqm, as no
 tunnel intefaces are shown here. So i used the ethernet interface
 instead of the PPPoE link. Is this fine? Minutes ago, I did a quick
 test and applied SQM to the PPPoE link by fixing luci-base to return
 also the virtual interfaces in net:get_interfaces(). But i didn't
 notice any difference or my test was too sloppy.

Well, sebastian just made a few SQM changes also in the ceropackages
repo and PPPoe over atm makes my head hurt. See cerowrt-devel
for more list. 

I'm a huge believer in measurements, and netperf-wrapper has been
the closest thing the Internet has ever had to one that accurately
measures latency under load. Recently it was proven to scale all
the way to 40GigE. 

Things like speedtest are increasingly inaccurate above 20mbits,
and doesn't measure induced latency at all...

and netalyzer, being written in java, doesn't get past 20mbits
either.

 
 --
 Stephan
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Barrier Breaker 14.07 Final

[Dave Taht]

Congrats everyone!

Here's to a faster, bufferbloat-free and ipv6 enabled
Internet!

On Thu, Oct 02, 2014 at 02:59:08PM +0200, Steven Barth wrote:
 The OpenWrt developers are proud to announce the final release
 of OpenWrt Barrier Breaker.
 
   ___ __
  |   |.-.-.-.|  |  |  |..|  |_
  |   -   ||  _  |  -__| ||  |  |  ||   _||   _|
  |___||   __|_|__|__||||__|  ||
   |__| W I R E L E S S   F R E E D O M
  -
  BARRIER BREAKER (14.07)
  -
   * 1/2 oz Galliano Pour all ingredients into
   * 4 oz cold Coffeean irish coffee mug filled
   * 1 1/2 oz Dark Rum   with crushed ice. Stir.
   * 2 tsp. Creme de Cacao
  -
 
 http://downloads.openwrt.org/barrier_breaker/14.07/
 
 Important changes since RC3
 * various ath9k related fixes
 * a few board related fixes
 * fixes for packages depdending on curl
 * per feed download folders
 
 Important changes since RC2
 * NAT  firewall throughput improvements
 * Security updates for OpenSSL  PolarSSL
 * Minor fixes in DHCP  DHCPv6 handling
 * Configuration support for GRE tunnels
 * Various other fixes
 
 Important changes since RC1
 * fix a long standing ath9k deadlock bug
 * all feeds are now built
 * image builder now works and RC2 contains all board specific images
 * various board/stability fixes
 
 ** Highlights since Attitude Adjustment **
 Default configuration and images
 
 * Linux kernel updated to version 3.10
 * Procd: new preinit, init, hotplug and event system written in C
 * Native IPv6-support
 - RA  DHCPv6+PD client and server
 - Local prefix allocation  source-restricted routes
   (multihoming)
 * Filesystem improvements
 - Added support for sysupgrade on NAND-flash
 - Added support for filesystem snapshot and rollback
 - Rewritten mounting system in C for rootfs and block devices
 * UCI configuration improvements
 - Support for testing configuration and rollback to working
   last working state
 - Unified change trigger system to restart services on-demand
 - Added a data validation layer
 * Networking improvements
 - Netifd now handles setup and configuration reload of
   wireless interfaces
 - Added reworked event support to allow obsoleting network
   hotplug-scripts
 - Added support for dynamic firewall rules and zones
 - Added support for transparent multicast to unicast
   translation for bridges
 - Various other fixes and improvements
 
 Additional highlights selectable in the package feeds or SDK
 * Extended IPv6-support
 - Added DS-Lite support and improved 6to4, 6in4 and 6rd-support
 - Experimental support for Lightweight 4over6, MAP-E and MAP-T
 - Draft-support for self-managing home networks (HNCP)
 * rpcd: new JSONRPC over HTTP-frontend for remote access to ubus
 * mdns: new lightweight mdns daemon (work in progress)
 * Initial support for the musl C standard library
 * Support for QMI-based 3g/4g modems
 * Support for DNSSEC validation
 * Added architecture for package signing and SHA256 hashing
 * ... and many more cool things
 
 Package feed reorganization
 For quite a while already we are not very satisfied with the quality
 of the packages-feed. To address this, we decided to do a fresh start
 on GitHub. The new feed https://github.com/openwrt/packages should be
 used from now on and package maintainers are asked to move their
 packages there. For the final release we will still build the old
 packages feed but it will be necessary to enable it manually in the
 opkg package list to be usable.
 Additionally we would like to give a big thank you to all of our
 package
 maintainers working on our various feeds.
 
 New build servers
 We would like to express our gratitude to Imagination Technology for
 funding the 2 build servers that we used for the release.
 
 Whats next ?
 We aim at releasing Chaos Calmer (CC) before the end of the year. The
 CC release will use 3.14 or a newer LTS kernel as baseline.
 
 
 Have fun!
 The OpenWrt developer team
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] How to properly add an unreachable route?

[Dave Taht]

I have been trying to simplify my babel setup. I have
8 /27s out of a single /24 that I would like not
to have to expose to the universe.

I have 172.21.2.0/27, 172.21.2.64/27 etc
on each of the 8 devices I have.

But there is no need to export each /27, as these
are out of a single /24.

The way to do that is to setup /etc/babel.conf to only
let /24s out...

redistribute ip 0.0.0.0/0 le 24 allow
redistribute local deny

(this can also easily be expressed in the /etc/config/babeld
 file)

And at the moment, I add this to /etc/firewall.user
to add the covering route locally. 

ip route add unreachable 172.21.2.0/24 proto static

Boom, I go from exporting 16 routes to 1.

Where I'm stuck is on how to express the above line
inside of uci and luci. Luci demands both a specific
interface name and a numeric destination, if you are
trying this via the route method.

If you try the otherwise promising uci newfangled rule method
by adding something like this to /etc/config/network

config rule
option dest   '172.21.2.0/24'
option action 'unreachable'

You end up bricking the router's network setup.

http://wiki.openwrt.org/doc/uci/network#routing.actions
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt

[Dave Taht]

On Sun, Mar 30, 2014 at 02:24:44PM -0400, Weedy wrote:
 On Sat, Mar 29, 2014 at 2:56 PM, Dave Täht dave.t...@bufferbloat.netwrote:
 
  From: Dave Taht dave.t...@bufferbloat.net
 
  This adds support for the bufferbloat project's Smart Queue Management
  (SQM) system, which improves over openwrt's qos-scripts in the following
  ways
 
  + Uses HTB with two models for managing traffic
a simplest one that merely uses fq_codel, and a three tier one that does
some basic and tunable packet prioritization.
 
  + Works with ipv6 and ipv4 correctly (unlike qos-scripts)
  + extensive support for fixing ADSL and PPOe framing problems
  + Partial support for key diffserv markings
  + highly tuned fq_codel implementation especially for low bandwidths
  + Tested heavily on cable modems and on dsl devices
 
  It is a disimprovement in that:
 
  - There are no built-in tricks for doing l7 classification,
  or other forms of packet inspection.
 
  - We haven't explored hfsc all that much, prefering to rely
  on the predictable behavior of htb + fq_codel for everything
 
  - And there is support for a few qdiscs that are not in the linux
  kernel mainline that remain experimental.
  ---
   net/sqm-scripts/Makefile   |   48 +++
   net/sqm-scripts/files/etc/config/sqm   |   11 +
   net/sqm-scripts/files/etc/init.d/sqm   |   23 ++
   net/sqm-scripts/files/usr/lib/sqm/functions.sh |  335
  
   net/sqm-scripts/files/usr/lib/sqm/run.sh   |   67 
   net/sqm-scripts/files/usr/lib/sqm/simple.qos   |  187 +++
   net/sqm-scripts/files/usr/lib/sqm/simple.qos.help  |1 +
   net/sqm-scripts/files/usr/lib/sqm/simplest.qos |   84 +
   .../files/usr/lib/sqm/simplest.qos.help|1 +
   net/sqm-scripts/files/usr/lib/sqm/stop.sh  |   22 ++
   10 files changed, 779 insertions(+)
   create mode 100644 net/sqm-scripts/Makefile
   create mode 100644 net/sqm-scripts/files/etc/config/sqm
   create mode 100755 net/sqm-scripts/files/etc/init.d/sqm
   create mode 100644 net/sqm-scripts/files/usr/lib/sqm/functions.sh
   create mode 100755 net/sqm-scripts/files/usr/lib/sqm/run.sh
   create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simple.qos
   create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simple.qos.help
   create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simplest.qos
   create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simplest.qos.help
   create mode 100755 net/sqm-scripts/files/usr/lib/sqm/stop.sh
 
  diff --git a/net/sqm-scripts/files/etc/config/sqm
  b/net/sqm-scripts/files/etc/config/sqm
  new file mode 100644
  index 000..547d321
  --- /dev/null
  +++ b/net/sqm-scripts/files/etc/config/sqm
  @@ -0,0 +1,11 @@
  +
  +config queue 'ge00'
  +option enabled '0'
  +option interface 'ge00'
  +option download '2'
  +option upload '4000'
  +option qdisc 'fq_codel'
  +option script 'simple.qos'
  +option qdisc_advanced '0'
  +option linklayer 'none'
  +
 
 
 How hard is this to config from the command line/vim?

There are a few more options than this (for DSL compensation, ecn
and advanced configuration), the above would work if you changed
enabled to '1' and the device from ge00 to your wan device. (not
the wan firewall rule, presently. )

It does help to have a sane long term and realistic measurement of your
network using something like the rrul test rather than the oft-gamed speedtest.

http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310

You are right, we should fully document all the variables in this file.
Until recently they were kind of in flux.

 I've never needed or really wanted luci on my box, I just use vim. Going by
 this patch, there is either nothing to config or no examples. I would think
 shipping a roughly equivalent config to what ships in qos-scripts would be
 a good start to get people testing.

/etc/init.d/sqm start,stop etc work as expected.

 IE: highest priority: small ARP, DNS, and SSH packets

The SQM default is local DNS and ntp. fq_codel automagically optimizes
for other sparse flows like arp, ssh, mosh, tcp syn, synack, etc,
no need to do that via classification.

 normal: HTTP, HTTPS

So you want to deprioritize vpn, smtp, rsync, dropbox, http on odd ports,
caching servers, etc, all in favor of the web gods?

we just toss all that into the normal (best effort bin) and let fq_codel
sort it out.

 bulk: everything else.

We do respect the diffserv marking of CS1 (background) and toss it
into the background queue.

 Side note: Will SQM do bandwidth slicing? Or at least handle hostile
 environments better? I say hostile as in roommates or maybe teenage kids.
 Multiple people/devices thinking they are entitled to the entire WAN
 bandwidth at all times.

fq_codel does fair (well, we call it flow) queuing.

https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00

[OpenWrt-Devel] ceropackages feed

[Dave Taht]

All the packages I just submitted are currently maintained in the
ceropackages-3.10 repo on github.

https://github.com/dtaht/ceropackages-3.10.git

so you can add that feed to your feeds.conf if you like, and do a

./scripts/feeds update
./scripts/feeds install sqm-scripts luci-app-sqm bcp38

and enable them to be built and give 'em a shot that way, rather
than trying the patches I just submitted.

There are a ton of other packages in that repo of varying 
quality and specificity to CeroWrt, possibly worth
browsing through also.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] getting more randomness by improving MIPS get_cycles()

[Dave Taht]

In light of the whole nsa hoo-ra (stuff like this)

https://plus.google.com/u/0/117091380454742934025/posts/SDcoemc9V3J

Ted Tso has pointed out to me that apparently mips' does not have a working 
generic get_cycles() call,  but instead returns 0 in all cases.

e.g: In arch/mips/include/asm/timex.h:

typedef unsigned int cycles_t;

static inline cycles_t get_cycles(void)
{
return 0;
}

Um.

get_cycles() is used in innumerable places in random.c.

This is double plus ungood... I am REALLY hoping I'm merely misreading 
the code...

An example:

(see drivers/char/random.c for how often it is used)

/*
 * Add device- or boot-specific data to the input and nonblocking
 * pools to help initialize them to unique values.
 *
 * None of this adds any entropy, it is meant to avoid the
 * problem of the nonblocking pool having similar initial state
 * across largely identical devices.
 */

void add_device_randomness(const void *buf, unsigned int size)
{
unsigned long time = get_cycles() ^ jiffies;

...

So, what blocks having a working get_cycles in common mips architectures?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] bloatie-bloat-bloat?

[Dave Taht]

On Sun, Sep 08, 2013 at 11:37:40AM +0200, Felix Fietkau wrote:
 On 2013-09-08 11:26 AM, Russell Senior wrote:
  
  I have a number of (admittedly) ancient Netgear WGT634U's in the field
  doing duty as free-wifi hotspots.  Recent builds of our standard set
  of tools have become unhappy in the last year or so.  For example,
  here are the RES memory sizes of processes on our workload, comparing
  r37911 (current) with r34240 (circa Nov 18, 2012):
  
  r37911  r34240
  
  RSS  commandRSS  command
  3700 gateway3000 gateway (nocatauth, w/ perl)
  1400 snmpd  1240 snmpd
  1196 openvpn3400 openvpn

Wow. Is that sort of benefit available if I switched to polarssl
for everything (dropbear? webserver?)

  736  olsrd  628  olsrd 
  732  olsrd  572  olsrd 
  664  netifd 268  netifd
  656  procd  76   init   
  104  init  
  108  rcS   
  632  top612  top   
  532  dropbear   540  dropbear  
  496  ash480  ash   
  492  logread168  syslogd   
  488  hostapd392  hostapd   
  456  crond  332  crond 
  448  udhcpc * (used static config, so no udhcpc)
  248  hotplug2  
  420  dropbear   188  dropbear  
  384  logger 172  logger
  164  logger
  380  sh  
  376  dnsmasq440  dnsmasq   
  372  radvd  188  radvd 
  256  radvd  320  radvd 

radvd has been obsoleted by either dnsmasq or the 6relayd stuff.

  364  ntpclient  200  ntpclient 

Not clear to me which ntp you are using...

  280  ubusd  56   ubusd  
  272  sleep   
  224  askfirst
  68   ??
  84   watchdog   
  -   -
  15956   14048 
  
  Today's resident size is almost 2 megabytes larger than a year ago,
  even after a substantial improvement in the openvpn size (I switched
  to polarssl).
  
  Admittedly, the numbers are just a convenience sample (r37911 just
  booted, r34240 has been up for 44 days) and might not be a fair
  comparison in all cases.  But, the direction here seems to be making
  the WGT634U less viable for us.
  
  Are these numbers illuminating at all?
 The increase in individual processes is interesting, but you made one
 mistake here: Adding up the RSS numbers does not yield the total memory
 usage, but a gross overestimation of it.
 Much of the memory use is coming from uClibc and other shared libraries,
 and most of that is shared in RAM as well.
 To fix that counting error, you can enable CONFIG_PROC_PAGE_MONITOR in
 your kernel config. This enables /proc/pid/smaps, which contains a Pss
 value for each mapping. For all shared parts, the memory amount is
 divided by the number of processes sharing it.
 
 - Felix
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 7/8] mac80211: add full diffserv support to wireless

[Dave Taht]

On Mon, Oct 01, 2012 at 07:28:11PM +0200, Felix Fietkau wrote:
 On 2012-10-01 6:49 PM, Dave Täht wrote:
  From: Dave Taht dave.t...@bufferbloat.net
  
  This moves all but EF marked traffic out of the VO queue,
  allowing for aggregation of other forms of traffic.
  
  It more aggressively uses the VI queue for interactive-ish
  traffic.
 Please propose this for upstream inclusion on linux-wireless@. I'd like
 to see the feedback there before I consider merging it to OpenWrt.

OK. Honestly I wanted feedback from openwrt first because this patch
originally exposed several problems in the VI queue handling on the ath9k,
and I suspect that other chipsets (like iwl) have hidden problems in VI
queue handling as well.

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

Re: [OpenWrt-Devel] [PATCH 5/8] Reduce skb truesize on common qdiscs under load

[Dave Taht]

On Mon, Oct 01, 2012 at 10:44:56AM -0700, Sebastian Moeller wrote:
 Hi Felix,
 
 
 On Oct 1, 2012, at 10:26 , Felix Fietkau wrote:
 
  On 2012-10-01 6:49 PM, Dave Täht wrote:
  From: Dave Taht dave.t...@bufferbloat.net
  
  After queue lengths start getting out of hand, try to preserve memory
  by shortening skbs to their truesize on the common pfifo, codel, and
  fq_codel qdiscs.
  
  Arguably (128) should be a configureable param
  I think this is a bad idea, at least on routers. 'Preserving memory'
  here involves copying buffer data, which is really horrible for
  performance. The memory bus is a tough bottleneck when routing at high
  speed…
 
   But the in severe situations the alternative is OOM - watchdog based 
 reboot; under these circumstances limping along and recover later once the 
 memory pressure is over sounds better than rebooting? (At least in cerowrt 
 the OOM reboot cycle could be easily initiated by a simple UDP flood through 
 the router. Now, while this is abusive, it is way better if the router 
 survives this and recovers with out a reboot, IMHO). This change along with a 
 few others Dave made turned cerowrt robust against UDP flooding which I think 
 is the right thing to do. Since this only triggers once memory gets scarce, 
 think of this as a defense mechanism in a situation where performance will 
 suffer anyway...
 
 best
   Sebastian

As I noted, openwrt's workaround of a txqueuelen of 30 on wifi means this 
check will never be hit. It also means that fq_codel can't be applied at
all to the openwrt wifi queues, as 30 is not deep enough to do any good.

(cerowrt is presently using a latency/bandwidth compromise of a shortened
 driver queue and a longer fq_codel based txqueue - and we're painfully 
aware that far more work is needed to make wireless-n stop being so
darn bloated and unresponsive: 

http://www.bufferbloat.net/projects/cerowrt/wiki/Fq_Codel_on_Wireless )

So, it IS possible to run a box with tons of SSIDs easily out of memory
with the larger txqueuelens cero is using, and this patch helped that.

Other devices (such as ethernet and qos'd devices)
have longer queues by default, where this memory saving optimization
*might* help

It would be interesting if more folk would abuse their openwrt routers
heavily using the current (2.6) version of netperf, to fully exercise
the 4 hardware wifi queues, or the multiple qos queues. 

Tests like this showed up a hw queue bug in ath9k (long since
fixed) and appears to mess up iwl (on a laptop) somewhat, and it would
be good to blow up more drivers and devices... in addition to running
older versions of openwrt out of memory.

What I typically do is a bunch of udp flooding and tcp flooding,
along the lines of this, using the netperf 2.6 distro, and exercising
each hw queue thusly. 

# netserver runs here
SERVER1=somewhere
SERVER2=somewhere.else

DUR=120

# on clients connected through the router via
# wifi, etc

(
# Flood BE with tcp in both directions
netperf -l$DIR -H$SERVER1 -tTCP_MAERTS 
netperf -l$DIR -H$SERVER2 -tTCP_MAERTS 
netperf -l$DIR -H$SERVER1 -tTCP_STREAM 
netperf -l$DIR -H$SERVER2 -tTCP_STREAM 
# Beat up on the BK, BE, VO, VI hw queues
netperf -l$DIR -Y CS1,CS1 -H$SERVER2 -tUDP_STREAM 
netperf -l$DIR -Y CS0,CS0 -H$SERVER2 -tUDP_STREAM 
netperf -l$DIR -Y EF,EF -H$SERVER2 -tUDP_STREAM 
netperf -l$DIR -Y CS5,CS5 -H$SERVER2 -tUDP_STREAM 
) 

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

Re: [OpenWrt-Devel] [PATCH v2] [RFC] Add Kernel 3.4 to AR71xx platform.

[Dave Taht]

On Fri, Sep 28, 2012 at 02:29:56PM +0200, Oliver wrote:
 On Friday 28 September 2012 14:30:45 Felix Fietkau wrote:
  3.6 is going to be released soon, I think we should go for that once
  we've taken care of branching for release.
  
  - Felix
 
 +1 to that.

+1 to that too. It seems possible this will be a long-term stable release,
which 3.3 is not.

It would be nice if we could expend effort on making the ar71xx arch more
part of the mainline kernel, too. As best as I recall that was seriously
bottlenecked on device tree support, when last I looked.

 
 Do you by any chance have a kernel repo in which you maintain the OpenWRT 
 patch-set? I realise of course that the buildenv expects quilt-style, but for 
 porting, merging, cherry-picking etc, Git is second to none. I've setup a 
 repo 
 over at GitHub, if anyone else is using Git to maintain kernel patches, a 
 remote URI would be much appreciated!
 
 Regards,
 Oliver
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Linux 3.3.x has been EOLed ; time to move on ?

[Dave Taht]

On Wed, Aug 01, 2012 at 08:40:52PM +0200, Hartmut Knaack wrote:
 Hi,
 my impression is, that a kernel version makes it into trunk if it is either a 
 long term kernel, or it brings essential new functions. For 3.3 this was most 
 certainly the introduction of BQL code. Keeping in mind that our main targets 
 are network routers, the bufferbloat issue probably concerns most of the 
 maintainers.

I have been away from my mail for a while.

Van Jacobson gave a great talk about bufferbloat, BQL, codel, and fq_codel
at last week's ietf meeting. Well worth watching. At the end he outlines
the deployment problems in particular.

http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSVAREAchapter=part_3

Far more interesting than this email! 

While we have made great progress towards addressing bufferbloat in openwrt, it
is only barely addressed in the openwrt QoS system, (it would be nice
if fq_codel ran on all interfaces with BQL support), BQL support only exists
for a few drivers in the openwrt tree...

And fixing wifi with similar techniques is going to take months and
months longer to do, even if we could get the chipset makers focused on
the problem.

http://www.bufferbloat.net/projects/cerowrt/wiki/Fq_Codel_on_Wireless

So the upcoming 3.3 release of openwrt is a start, only, towards fixing
bufferbloat. I'm very happy we made so much progress in a year, with
perhaps another year of effort and we'll have it thoroughly licked in linux
and in openwrt. That leads towards difficult decision-making for declaring
a stable release this year for openwrt.

The current trunk of openwrt is unquestionably better than last years
release, and deserves wider use.

As for the long term support issue for 3.3, it does concern me very
much that 3.3 is already EOL'd.

I would like it if openwrt planned on a stable release on the next go-round
built around a kernel that has long term support (perhaps 3.8?).

I do note that openwrt's 3.3 is not actually 3.3 to a large extent,
it has wireless-next, and the fq_codel implementation
from linux 3.5, and tons and tons of patches for driver and chipset
support that haven't made it up to mainline.

There are 160 generic linux patches, and for the ar71xx architecture
*alone* there are 136 patches, and 95 new driver related files.

It would be good if efforts were expended to merge up the
enormous patch burden into the kernel mainline, so as to make it
easier to move openwrt forward in conjuction with it.

The patch burden is the enormous problem impeding progress forward, and
makes bi-directional patching from the Linux kernel head much harder as
time goes by...

The patch burden and driver collisions in the arm world got
so bad 2 years ago that linaro was formed to fix it. That effort
has largely been successful and it would help a lot to do something similar
here.

It would be my hope that those that build products around openwrt would
recognise this infrastructural problem and step up.

(side note, the bufferbloat.net effort has loaned 4 boxes to the buildbot
 system and it would be very helpful in terms of cycle time if the buildbot
 cluster could be even more dramatically expanded)

IMHO, I think it's worth creating a stable release now, but also working
hard towards being able to create another stable release on a new kernel
base *this year* - which is going to be hard due to these other problems.


 
 Emmanuel Deloget schrieb:
  Hello, 
 
  I understand that a lot of effort has been pushed in making 
  Linux 3.3 the trunk kernel, and I understand that I probably 
  missed long (IRC?) discussions on this very subject, but since 
  3.3.8 is going to be the last supported kernel in the 3.3.x 
  branch it might be a good idea to move on to another, more 
  recent kernel version - and to do it slightly better. Not 
  that anything is really bad, but there were obviously better 
  choices that 3.3 at the time it came up. 
 
 
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Codel: avoid a nul rec_inv_sqrt

[Dave Taht]

One condition before codel_Newton_step() was not good if
we never left the dropping state for a flow. As a result
rec_inv_sqrt was 0, instead of the ~0 initial value.

codel control law was then set to a very aggressive mode, dropping
many packets before reaching 'target' and recovering from this problem.

Brought over from 3.5-stable
---
 ...one-condition-to-avoid-a-nul-rec_inv_sqrt.patch |   68 
 1 file changed, 68 insertions(+)
 create mode 100644 
target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch

diff --git 
a/target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
 
b/target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
new file mode 100644
index 000..210a58c
--- /dev/null
+++ 
b/target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
@@ -0,0 +1,68 @@
+From patchwork Mon Jul 30 06:52:21 2012
+Content-Type: text/plain; charset=utf-8
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: codel: refine one condition to avoid a nul rec_inv_sqrt
+Date: Sun, 29 Jul 2012 20:52:21 -
+From: Eric Dumazet eric.duma...@gmail.com
+X-Patchwork-Id: 173968
+Message-Id: 1343631141.2626.13293.camel@edumazet-glaptop
+To: David Miller da...@davemloft.net
+Cc: netdev net...@vger.kernel.org, Anton Mich lp2...@gmail.com
+
+From: Eric Dumazet eduma...@google.com
+
+One condition before codel_Newton_step() was not good if
+we never left the dropping state for a flow. As a result
+rec_inv_sqrt was 0, instead of the ~0 initial value.
+
+codel control law was then set to a very aggressive mode, dropping
+many packets before reaching 'target' and recovering from this problem.
+
+To keep codel_vars_init() as efficient as possible, refine
+the condition to make sure rec_inv_sqrt initial value is correct
+
+Many thanks to Anton Mich for discovering the issue and suggesting
+a fix.
+
+Reported-by: Anton Mich lp2...@gmail.com
+Signed-off-by: Eric Dumazet eduma...@google.com
+
+---
+include/net/codel.h |8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+
+
+--
+To unsubscribe from this list: send the line unsubscribe netdev in
+the body of a message to majord...@vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
+
+diff --git a/include/net/codel.h b/include/net/codel.h
+index 550debf..389cf62 100644
+--- a/include/net/codel.h
 b/include/net/codel.h
+@@ -305,6 +305,8 @@ static struct sk_buff *codel_dequeue(struct Qdisc *sch,
+   }
+   }
+   } else if (drop) {
++  u32 delta;
++
+   if (params-ecn  INET_ECN_set_ce(skb)) {
+   stats-ecn_mark++;
+   } else {
+@@ -320,9 +322,11 @@ static struct sk_buff *codel_dequeue(struct Qdisc *sch,
+* assume that the drop rate that controlled the queue on the
+* last cycle is a good starting point to control it now.
+*/
+-  if (codel_time_before(now - vars-drop_next,
++  delta = vars-count - vars-lastcount;
++  if (delta  1 
++  codel_time_before(now - vars-drop_next,
+ 16 * params-interval)) {
+-  vars-count = (vars-count - vars-lastcount) | 1;
++  vars-count = delta;
+   /* we dont care if rec_inv_sqrt approximation
+* is not very precise :
+* Next Newton steps will correct it quadratically.
-- 
1.7.9.5

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

[OpenWrt-Devel] [PATCH] gpsd: update to 3.7

[Dave Taht]

The openwrt specific patches have been merged into gpsd 3.7 and
are no longer needed.
---
 net/gpsd/Makefile |4 ++--
 net/gpsd/patches/001-add-staging-prefix.patch |   10 --
 net/gpsd/patches/002-no_rpath.patch   |   11 ---
 3 files changed, 2 insertions(+), 23 deletions(-)
 delete mode 100644 net/gpsd/patches/001-add-staging-prefix.patch
 delete mode 100644 net/gpsd/patches/002-no_rpath.patch

diff --git a/net/gpsd/Makefile b/net/gpsd/Makefile
index 47dd279..ca4983a 100644
--- a/net/gpsd/Makefile
+++ b/net/gpsd/Makefile
@@ -8,12 +8,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=gpsd
-PKG_VERSION:=3.6
+PKG_VERSION:=3.7
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=http://download-mirror.savannah.gnu.org/releases/gpsd
-PKG_MD5SUM:=064a5ad75593f8c3ea3fe85010647832
+PKG_MD5SUM:=52d9785eaf1a51298bb8900dbde88f98
 
 PKG_BUILD_DEPENDS:=libncurses libusb-1.0
 
diff --git a/net/gpsd/patches/001-add-staging-prefix.patch 
b/net/gpsd/patches/001-add-staging-prefix.patch
deleted file mode 100644
index b88171b..000
--- a/net/gpsd/patches/001-add-staging-prefix.patch
+++ /dev/null
@@ -1,10 +0,0 @@
 a/SConstruct
-+++ b/SConstruct
-@@ -200,6 +200,7 @@ import_env = (
- 'PATH',# Required for ccache and Coverity scan-build
- 'PKG_CONFIG_PATH', # Set .pc file directory in a crossbuild
- 'STAGING_DIR', # Required by the OpenWRT build.
-+'STAGING_PREFIX',  # Required by the OpenWRT build.
- )
- envs = {}
- for var in import_env:
diff --git a/net/gpsd/patches/002-no_rpath.patch 
b/net/gpsd/patches/002-no_rpath.patch
deleted file mode 100644
index 38ba782..000
--- a/net/gpsd/patches/002-no_rpath.patch
+++ /dev/null
@@ -1,11 +0,0 @@
 a/SConstruct
-+++ b/SConstruct
-@@ -269,8 +269,6 @@ def installdir(dir, add_destdir=True):
- 
- # Honor the specified installation prefix in link paths.
- env.Prepend(LIBPATH=[installdir('libdir')])
--if env[shared]:
--env.Prepend(RPATH=[installdir('libdir')])
- 
- # Give deheader a way to set compiler flags
- if 'MORECFLAGS' in os.environ:
-- 
1.7.9.5

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

[OpenWrt-Devel] ubnt rocket gps supported?

[Dave Taht]

I am thinking through a prototype deployment of a bunch of outdoor
radios, gps and sensors, with fq_codel, and its successors,
for location, environmental sensing and precision time.

Does the on-board gps on the ubiquity rocket-m gps work in openwrt?
(any details on it so as I can make it work would be helpful)

Are there any other openwrt supported devices with an integral gps supported?

Are there any outdoor radios with a usb port?

(yes, I'm aware I can build or buy a case for something like a
routerstation pro or routerboard, I
 was looking for something more or less like a nanostation M5 with a USB port)

-- 
Dave Täht
SKYPE: davetaht
http://ronsravings.blogspot.com/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] reminder: buildbot slave ready for action

[Dave Taht]

Last I'd heard travis was off on a well deserved vacation... as am I.

snapon.lab.bufferbloat.net can also be tossed into the buildbot system.
It's a 6 core box, but only has a single drive.

Does anyone else have a grip on the buildbot system?

On Tue, May 22, 2012 at 6:36 PM, Daniel Golle dgo...@allnet.de wrote:
 i got a box ready to participate in as a buildbot slave.
 it's a brand-new CentOS x86_64 install and I made sure all build-dependencies
 are present.
 please advise me on how it can serve the buildbot, it's waiting :)
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Codel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

[Dave Taht]

In looking over your test scripts and results, it seems possible you
have gso on.

ethtool -K the_device tso off
ethtool -K the_device gso off
ethtool -K the_device ufo off

Secondly, in the 100Mbit and below case, I have found BQL's estimates
to be persistently on the high side, and have generally found that a
byte queue limit of 3000 or 4500 produces optimal, consistent results.

Usually 1500 causes starvation. YMMV.

On Mon, May 21, 2012 at 10:49 PM, Tobias Diedrich
ranma+open...@tdiedrich.de wrote:
 Rick Jones wrote:
 On 05/20/2012 08:48 PM, Dave Taht wrote:
 Thx for the numbers!
 
 Could you do a TCP_RR while under load from UDP_STREAM?

 If you want to generate pretty pictures while doing so, you can
 probably tweak
 http://www.netperf.org/svn/netperf2/trunk/doc/examples/bloat.sh

 How about this:
 http://tdiedrich.de/~ranma/bufferbloat-rt3050/

 --
 Tobias                                          PGP: http://8ef7ddba.uguu.de



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Codel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

[Dave Taht]

I would really like people to clearly mark when they are using pfifo_fast,
codel, and fq_codel.

Secondly, I note that for utterly best results it is useful to ALSO have
htb on on ingress to a value only slightly lower than the rate under
test, and fq_codel attached to
the bin(s)

(an example of this is in the deBloat repo on github - both ingress.sh
and simple_qos.sh)

It would be nice if doing ingress was as simple as egress, maybe using some sort
of tbf + fq_codel

Otherwise for some benchmarks... at 100Mbit, you will see TCP_STREAM
behavior holding
the line at ~5ms, and TCP_MAERTS being in excess of 30ms, especially
when pfifo_fast is on the other
side. Or vice versa, depending on where you are running the test.

On Tue, May 22, 2012 at 2:22 AM, Rick Jones rick.jon...@hp.com wrote:
 On 05/21/2012 04:30 PM, Rick Jones wrote:

 I think my original ones had the unfortunate effect of putting lines on
 top of one another. Your's seem to put them pretty far apart (at least
 sometimes). We aught to be able to find some reasonable medium in there
 somewhere. I'm thinking if latency is the metric of greatest interest,
 we want that to have the full y axis, and then the peak bandwidth of the
 STREAM test be about half-way up?


 I've tweaked the bloat.sh script in a couple ways.  First, I changed how I
 compute the scaling factor, to implement what I described above. Second, I
 am using a negative value for the demo interval for the TCP_RR test.  This
 causes netperf to check if it is time to emit a result after each
 transaction rather than after what it thought would be the number of
 transactions in the interval.  In that way the latency line is much more
 robust in the face of a sudden bloating of the path.  The effect on
 transactions per second should be similar to that of enabling histograms.
  An example of a test across my 100 Mbit/s link to a laptop is attached.

 happy benchmarking,

 rick jones

 ___
 Codel mailing list
 co...@lists.bufferbloat.net
 https://lists.bufferbloat.net/listinfo/codel




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

[Dave Taht]

Thx for the numbers!

Could you do a TCP_RR while under load from UDP_STREAM?

On Mon, May 21, 2012 at 1:31 AM, Tobias Diedrich
ranma+open...@tdiedrich.de wrote:
 Tobias Diedrich wrote:
 Dave Taht wrote:
  In looking over the enormous stack of boards and drivers that openwrt
  supports, I see that many of the ethernet drivers don't yet support
  Linux 3.3's Byte Queue Limits, which are discussed here:
 
  http://lwn.net/Articles/454390/
 
  It would be good if more did. They improve network performance in the
  general case enormously, particularly when a link is not connected at
  it's peak wire speed.
 
  *Adding* support for BQL to an ethernet driver is trivial, here's an
  example of how.

 I tried adding BQL to the ramips ethernet driver, however I found
 some interesting behaviour while doing
 root@OpenWrt:~# netperf -l 120 -t UDP_STREAM -H myserver

 It looks like the briding code still needs to implement this as well?

 netperf UDP_STREAM:
 iface  limit_min   inflight  tx mbps  remote mbps  ping ms
 eth0   0           ~15000    95.71    95.71        ~10ms
 eth0   100     ~30   177.98   23.28(*)     ~30ms
 br0    0           ~15000    154.88   33.94(*)     ~120ms
 br0    100     ~30   170.92   25.57(*)     ~30ms

 (*) bwm-ng on the server showed ~100mbps incoming...
 [...]
 Haven't tried codel yet...

 Turns out, it works nicely with codel, even with the bridge:

 netperf:  netperf -l 120 -t UDP_STREAM -H myserver
 fq_codel: tc qdisc add dev eth0 handle 1: root fq_codel target 5ms

 iface  eth0 qdisc  bql  inflight  tx mbps    sys time  ping ms
 eth0   pfifo_fast  no   n/a       182.98(*)  96.43s    ~30ms
 eth0   fq_codel    no   n/a       177.98(*)  96.09s    ~30ms
 eth0   pfifo_fast  yes  ~15000    95.71      42.73s    ~10ms
 eth0   fq_codel    yes  ~15000    95.19      51.52s    ~4ms
 br0    pfifo_fast  yes  ~15000    155.19(*)  94.24s    ~120ms
 br0    fq_codel    yes  ~15000    90.92      65.52s    ~4ms

 (*) 100mbit link after the switch, ifconfig eth0 shows no drops,
    so I'm assuming they are getting dropped by the switch.

 --
 Tobias                                          PGP: http://8ef7ddba.uguu.de



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Codel explanation in Danish

[Dave Taht]

See:

http://www.linuxin.dk/node/19778 for the original text:

Via google translate:

Version 3.4 of Linux has not arrived yet, but 3.5 already appears to
be a very interesting version. There will be a vital improvement to
the handling of buffers in the network. More specifically, it is a new
algorithm that can correct bufferbloat problem. That is a congested
internet to a lesser extent will feel slow for example. ordinary web
browsing or gaming. 3.5 is therefore really one of those releases
where the average user can feel the difference kernel versionen.

A few days ago announced Kathleen Nichols and Van Jacobson their paper
a new algorithm for active queue management (AQM). Besides having
improvements in performance compared to previous algorithms, so the
new is also a huge advantage of not requiring difficult settings for
each use pattern. Previously it required networking expert to analyze
the individual traffic and set the AQM if you needed it. The new is it
just plug and play and AQM can now be used as default.

Shortly after the publication of paperen had scientists from cerowrt /
bufferbloat an implementation ready for linux. It has already been
included in git repoet for network-next, which is expected to be part
of Linux 3.5. The code is also also included in the development
version of openwrt and would also be found in the first release of
cerowrt, expected to come very soon. 


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

[Dave Taht]

In looking over the enormous stack of boards and drivers that openwrt
supports, I see that many of the ethernet drivers don't yet support
Linux 3.3's Byte Queue Limits, which are discussed here:

http://lwn.net/Articles/454390/

It would be good if more did. They improve network performance in the
general case enormously, particularly when a link is not connected at
it's peak wire speed.

*Adding* support for BQL to an ethernet driver is trivial, here's an
example of how.

http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/0103-BQL-support-added-to-ag71xx-driver.patch

* testing BQL* is also trivial - but will require the device to do.
I've been beat up by memory barrier issues and stuff like that, so it
pays to do the patch and then run serious tests through it, rather
than try it blind.

So, getting more BQL enabled ethernet drivers working would be good.

There is BQL support in many of the mainstream ethernet cards already,
see those for more examples of how to do it.

...

Anyway, as folk are hopefully aware by now, Kathie Nichols and Van
Jacobson have released a new no knobs AQM algorithm which can be
used by default on all interfaces - not just the uplink - in order to
manage bandwidth and latency far better than has ever been done
before.

If you haven't heard about it yet, please see
http://queue.acm.org/detail.cfm?id=2209336 for the paper.

Figure 7 shows the enormous differences in latency and buffering
behavior between drop tail (the current linux default), RED, and
Codel.

There's also been good coverage in lwn, jim gettys blog, arstechnica,
etc. I'd ignore slashdot.

Codel is a brand new algorithm, something truly new under the sun,
which doesn't happen every day. Kathie and Van been working on it for
over a decade and the bufferbloat/cerowrt team for over a year.

We took the wraps off the algorithm a few days ago.
We've made the code freely available under a dual BSD/GPL license.

AQM is not just for routers anymore, either, but it helps a lot there!

Versions of Codel for linux 3.3 and 3.4 (and ns2 and ns3 simulations) are here:

http://www.bufferbloat.net/projects/codel/wiki

Codel will work best on a BQL-enabled ethernet driver.
It will also work on devices with small numbers of ring buffers.

I look forward to hearing of early successes (and failures!) on
various bits of hardware. Certainly while codel + bql works well, htb
and hfsc in combination with various other technologies is not well
tested yet.

Codel is a RED replacement, and will work best when paired up with
QFQ, or the upcoming sfq-enabled version.

However by itself it's pretty darn good, and can be used on all
interfaces of a router, not just the uplink.

Work on characterizing wireless behavior is on-going. (some help on
that would be nice)

There is still a great deal of work ahead for the cerowrt project,
it's my hope that by sharing this stuff as soon as I felt the patches
were baked enough, that all those frustrated by network delays and
bufferbloat on supposedly fast hardware, would jump on it, on their
own hardware.

Our intent from day one was to get Codel into OpenWrt (and indeed, all
OSes) as fast as possible.

Unfortunately I kind of forgot about getting BQL on everything, everywhere, too!


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] BQL support in Ethernet drivers (and Kathie Nichols and Van Jacobson's new AQM, codel)

[Dave Taht]

On Thu, May 10, 2012 at 9:13 AM, John Crispin j...@phrozen.org wrote:
 On 10/05/12 17:57, Dave Taht wrote:
 In looking over the enormous stack of boards and drivers that openwrt
 supports, I see that many of the ethernet drivers don't yet support
 Linux 3.3's Byte Queue Limits, which are discussed here:

 http://lwn.net/Articles/454390/

 It would be good if more did. They improve network performance in the
 general case enormously, particularly when a link is not connected at
 it's peak wire speed.

 *Adding* support for BQL to an ethernet driver is trivial, here's an
 example of how.

 http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/0103-BQL-support-added-to-ag71xx-driver.patch

 * testing BQL* is also trivial - but will require the device to do.
 I've been beat up by memory barrier issues and stuff like that, so it
 pays to do the patch and then run serious tests through it, rather
 than try it blind.

 Hi,

 do you run specific tests or just hammer the unit ?

Hammering via any means is good - netperf, iperf, apache benchmarks, etc.

We have been using (and improving) netperf to exercise things like
classification and alternate tcp algorithms. You can get that from
netperf.org's svn, or

There is a version of that already packaged up in the openwrt
compatible ceropackages repository here:

https://github.com/dtaht/ceropackages-3.3

the new (to be 2.6) version of netperf is not backward compatible with
version 2.5, so all sides of the connection need to be running it.

useful tests are TCP_STREAM, TCP_MAERTS, and TCP_RR, run multiple
times simultaneously, for long periods. (memory barriers are hard to
hit). Codel shows up well in a simultaneous TCP_STREAM and TCP_RR test
vs pfifo_fast, too.

Iperf is a simpler substitute.


 john


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



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Add Lua bindings for libgps

[dave taht]

On 05/05/2012 01:17 PM, Felix Fietkau wrote:

On 2012-05-05 8:49 PM, Eric S. Raymond wrote:

Felix Fietkaun...@openwrt.org:

I merged scons build support in r31618. I was just about to merge
chrpath too, but it didn't build on my OSX box. When I found out what
chrpath is used for in the build system, I decided to not merge it at all.
If I understand the code that uses it in the gpsd build system
correctly, it seems to be an unnecessary hack that should be patched out
entirely.

It's necessary for dynamic linking.  It replaces the elaborate stuff libtool
does in an autotools-based build.

I really don't think we need it in OpenWrt, so I'm going to patch it
out. chrpath seems to need some ELF related stuff that isn't part of our
host build yet, and I think it is completely pointless to add all of
this for a piece of functionality that we don't need or want in OpenWrt
at all.

Works for me.


After fixing some madness wrt. scons platform detection (I'm beginning
to dislike scons even more than autoconf now)


That would be hard to imagine, but I feel your pain, I do, I do.


, I tried my patched gpsd
package and it seemed to find its libraries just fine.

Awesome.

I note that there was a great deal of churn happening after the 3.5 
release, I don't know if eric considers it 3.5 stable enough or not. 
Notably there was some stuff going by about endianness on the list that 
appeared to be ibm360 related, which I know is not a target platform 
(yet) for openwrt.


Does this mean I can retire the ceropackages version?

I note that the xorp package therein needed scons too.



- Felix


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

Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

[Dave Taht]

On Mon, Apr 30, 2012 at 3:49 AM, David Woodhouse dw...@infradead.org wrote:
 On Sun, 2012-04-22 at 14:48 -0700, Dave Täht wrote:


Thank you very much for the code review!

 +
 +-#define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))-words [3])
 ++#define tcp_flag_word2(tp) ( ((union tcp_word_hdr *)(tp))-words [3])
 ++#define tcp_flag_word(tp) ( __get_unaligned_cpu32union tcp_word_hdr 
 *)(tp))-words [3])))

 Ewww. And didn't you already make that union __packed anyway?

yes, ewww. I'll note that I don't like the define in the general case.
It is used both for assignment (once!) and for access , which is why
it got broken into two macros...


 +diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
 +index 22ef5f9..bf3f773 100644
 +--- a/net/ipv4/tcp.c
  b/net/ipv4/tcp.c
 +@@ -2834,7 +2834,7 @@ found:
 +
 +       p = *head;
 +       th2 = tcp_hdr(p);
 +-      tcp_flag_word(th2) |= flags  (TCP_FLAG_FIN | TCP_FLAG_PSH);
 ++      tcp_flag_word2(th2) = tcp_flag_word(th2) | flags  (TCP_FLAG_FIN | 
 TCP_FLAG_PSH);

 net/ipv4/tcp.c: In function 'tcp_gro_receive':
 net/ipv4/tcp.c:2837:82: warning: suggest parentheses around arithmetic in 
 operand of '|' [-Wparentheses]

 Have you posted these patches to the netdev list? And is the response
 going to be just make sure your network devices are receiving packets
 into sensibly-aligned buffers, and none of this is necessary?

Yes, that would be the answer I expect from the list.

There is no reason to try to push this stuff upstream.

 There's a reason a lot of Ethernet drivers pad the start of their skb by
 2 bytes before receiving the packet...

Tell it to however wired up this chip and shipped it in qty millions.
Actually that message was already received, successor chipsets from
this manufacturer did it up right.

I am somewhat forgiving in that. Compared to some arches I've worked
with the ar71xx is very solid. (for comparison, take the ep9302, where
a working toolchain didn't arrive until 2 years after the chip had
ceased production)

But this problem is a PITA, and as demonstrated, scribbling on these
core portions of the stack improves performance by an enormous amount.

 --
 dwmw2

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




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

[Dave Taht]

On Mon, Apr 30, 2012 at 7:49 AM, David Woodhouse dw...@infradead.org wrote:
 On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote:
 Tell it to however wired up this chip and shipped it in qty millions.
 Actually that message was already received, successor chipsets from
 this manufacturer did it up right.

 So the real problem is that the ar71xx doesn't allow you to DMA to
 addresses which aren't aligned to 4 bytes? Which network devices does
 that restriction apply to? All of them?


 Out of interest, have you done a performance comparison with just
 *moving* the packet when it arrives?

I did not. Felix did.



Fixing this issue has had a long, tortuous history...

this got tried and later backed out...

https://dev.openwrt.org/changeset/20892

- on ar724x, rx buffers can be aligned with an offset of 2, which
keeps the ip header aligned
- alignment offset is only added if the ar8216 workaround is not
active and the phy driver does not advertise its own packet alignment
- ar71xx and ar91xx can not handle rx alignment offsets, however
taking a hit on unaligned exceptions seems to have less overhead than
re-aligning the data for large packets
- use memmove to re-align small packets, if necessary

tested on ar9132, ar7240 and ar7242 based devices without ar8216 headers

Which got backed out here:

https://dev.openwrt.org/ticket/7236

So I'd certainly be willing to attempt realignment in the driver, and
sort of remember that it's like a one-liner to do nowadays...

but it is a 16 bit bus, and packets are dmaed, so getting the cpu
involved on every ethernet transfer strikes me as potentially very
bad.


 If this really is needed to work around hardware limitations, I don't
 see why *some* of it shouldn't be acceptable upstream. A config option
 to add '__packed' to various structures is fairly harmless, for
 example...

The __packed trick, so far as I know, is undefined gcc behavior. But, yea,
perhaps something more PC than this

#define F_ING_HW_ENGINEER_SAVED_A_PIN __packed


 --
 dwmw2



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

[Dave Taht]

On Mon, Apr 30, 2012 at 8:02 AM, Felix Fietkau n...@openwrt.org wrote:
 On 2012-04-30 4:49 PM, David Woodhouse wrote:
 On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote:
 Tell it to however wired up this chip and shipped it in qty millions.
 Actually that message was already received, successor chipsets from
 this manufacturer did it up right.

 So the real problem is that the ar71xx doesn't allow you to DMA to
 addresses which aren't aligned to 4 bytes? Which network devices does
 that restriction apply to? All of them?
 AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected.

I guess a long term issue is this patch needs to apply only to those arches,
somehow. It's silly to be hurtful to the successor arches.


 Out of interest, have you done a performance comparison with just
 *moving* the packet when it arrives?
 I did some tests before I did the first unaligned hack patch, I don't
 have the numbers anymore, but the results were horrible.

I'm still looking for the 'one liner to pass the driver to tell it to realign',
but was that the approach you were trying...


 If this really is needed to work around hardware limitations, I don't
 see why *some* of it shouldn't be acceptable upstream. A config option
 to add '__packed' to various structures is fairly harmless, for
 example...
 Makes sense

 - Felix



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

[Dave Taht]

On Mon, Apr 30, 2012 at 10:26 AM, Felix Fietkau n...@openwrt.org wrote:
 On 2012-04-30 5:08 PM, Dave Taht wrote:
 On Mon, Apr 30, 2012 at 8:02 AM, Felix Fietkau n...@openwrt.org wrote:
 On 2012-04-30 4:49 PM, David Woodhouse wrote:
 On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote:
 Tell it to however wired up this chip and shipped it in qty millions.
 Actually that message was already received, successor chipsets from
 this manufacturer did it up right.

 So the real problem is that the ar71xx doesn't allow you to DMA to
 addresses which aren't aligned to 4 bytes? Which network devices does
 that restriction apply to? All of them?
 AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected.

 I guess a long term issue is this patch needs to apply only to those arches,
 somehow. It's silly to be hurtful to the successor arches.


 Out of interest, have you done a performance comparison with just
 *moving* the packet when it arrives?
 I did some tests before I did the first unaligned hack patch, I don't
 have the numbers anymore, but the results were horrible.

 I'm still looking for the 'one liner to pass the driver to tell it to 
 realign',
 but was that the approach you were trying...
 I did test with such a one liner (or maybe it was a two liner), but I
 didn't keep the patch.
 I think it's quite normal that this approach is so much more expensive
 than adding the unaligned access hacks. The main bottleneck on these
 devices is the memory bus, and for normal traffic passed through the
 device as a router, the CPU does not have to touch much of the payload
 contents at all, since it's only touched by DMA.
 Doing a memmove to re-align the packet contents blows the dcache
 footprint out of proportion and significantly increases the amount of
 unnecessary memory bus traffic.

I agree it would blow up the dcache and be worse than what exists by a lot.

So, out of this conversation:

1) It would be nice to not have this patch take effect on any but the
ar71xx and ar91xx. As these share code in openwrt, doing it with a
compile time define

2) IF there existed another brain damaged ethernet chip on some other
arch, it would be worth coming up with a Kbuild option to enable
defining __packed generically as part of the network stack for those
arches. Something more
pithy than

#define F_ING_HW_ENGINEER_SAVED_PIN

would be needed tho.

#define UNALIGNED_ETHERNET

perhaps.

3) I don't like the tcp_hdr macro in general, but it looks like that
is an obsolete part of the patch anyway, so I'll try ripping it out.

4) get_unaligned_be32 seems like the right thing rather than
get_unaligned_cpu32?

5) I THINK the 'if aligned, do assembly version' for the checksums is
a win, but if item #2 is true, I'm not happy with the casts...

@@ -105,6 +141,9 @@ static inline __sum16 ip_fast_csum(const void
*iph, unsigned int ihl)
unsigned int csum;
int carry;

+   if ((unsigned int) iph  3)
+   return ip_fast_csum_unaligned(iph,ihl);
+


 - Felix



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx

[Dave Taht]

Would it be too much to ask for those expending time on this debate,
to expend a little extra time doing some code review and testing this
patch?

Or, like while the flames are being composed, merely sending data through it?

This particular patch improves ipv4 by over 10% especially when used
with the sfq and sfqred qdiscs, fixes encapsulation for ipsec (both
ipv4 and ipv6), and yes, more than doubles ipv6 performance on the
ag71xx.

Although simple in outline, it is pretty invasive into core bits of
the kernel. I wish it wasn't, but the alternatives (have the driver
rebuffer misaligned packets) were far worse for performance, and the
final patch isn't all that big.

I agree with felix's suggestion to not let __packed leak out of the
kernel headers, and will respin the patch for that. I'm dubious that
the check alignment and branch is actually all that useful in the ipv6
checksum code, too, on an arch with a small cache.

And I'm still trying to track down the last causes of traps in the
routing path, and several other ipv6 and ipv4 related bugs. I'm pretty
sure that the traps in the routing path have caused many a tcp reset
for me over the last year, under load.

http://www.bufferbloat.net/projects/cerowrt/issues/371

http://www.bufferbloat.net/projects/cerowrt/issues

http://www.bufferbloat.net/projects/cerowrt/issues/360


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] __packed can leak from the kernel headers into iptables so define

[Dave Taht]

On Tue, Apr 24, 2012 at 7:21 AM, David Woodhouse dw...@infradead.org wrote:
 On Mon, 2012-04-23 at 07:24 +0200, Felix Fietkau wrote:
 Maybe it would make sense to just use the long form
 __attribute__((packed)) instead of __packed in parts that are visible to
 userspace.

 Hm, 'make headers_install' should be performing that substitution
 anyway, shouldn't it?

 I don't quite see why this patch was needed in the first place.


The a) __packed portion or the b) patch to iptables?

a) Although most of the network headers are naturally 'packed', the
compiler by default issues aligned instructions for accessing them. In
the case of the ag71xx stuff dma-ing in from the ethernet device are
misaligned, and the cost on re-aligning them with a memmove (16 bit
bus!) proved to be very high.

https://dev.openwrt.org/changeset/20892/trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ag71xx_main.c

This alignment issue is one of the few flaws of this hardware, and was
fixed in successor chipsets.

Declaring key network headers __packed causes the compiler to issue
unaligned instructions to access the members. The basic ipv4 patch has
been in openwrt for nearly a year now. The remainder of the patch
finds casts to other types and makes sure they are also accessed
unaligned.

b) However __packed leaks out of the main network header file, and was
not defined by iptables to be the define it is in the kernel code.


 --
 dwmw2

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




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/2] __packed can leak from the kernel headers into iptables so define

[Dave Taht]

On Tue, Apr 24, 2012 at 7:50 AM, David Woodhouse dw...@infradead.org wrote:
 On Tue, 2012-04-24 at 07:47 -0700, Dave Taht wrote:
 b) However __packed leaks out of the main network header file, and was
 not defined by iptables to be the define it is in the kernel code.

 How? When you run 'make headers_install' to export kernel headers for
 use by userspace, it *sanitizes* them, which includes automatically
 changing any instance of __packed to __attribute__((packed)). See
 scripts/headers_install.pl

 If someone is using headers that they've just copied out of the kernel,
 instead of using 'make headers_install', they deserve all the breakage
 they get.


Hmm. OK. Well, it happened, so perhaps something in openwrt is doing
it wrong, or some pattern of mine while doing a build broke it.

I'll try a clean build later this week, with the iptables patch
removed. Certainly it's cleaner to use __packed everywhere it is used.

As for the former, I don't know enough of the innards of the openwrt
buildsystem to really even know where to look.

 --
 dwmw2

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




-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel