Re: OpenWrt One - celebrating 20 years of OpenWrt

[Rich Brown]

Excellent news. Thanks!

> On May 27, 2024, at 9:43 AM, John Crispin  wrote:
> 
> 
> On 27.05.24 15:27, Paul D wrote:
>> I guess this isn't often discussed unless one is dealing with large
>> volume - but does the case include keyhole screw cutouts, those
>> specially made holes that accommodate screws for non horizontal mounting
>>  using a couple of screws? These would make life easier for some - as
>> the ruggedized heat-sink ish case in the renders probably requires
>> special anchoring for wall mount.
> 
> This is already done for the case. there will be key hole screw cutouts on 
> the bottom plane.
> 
> 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 One - keyhole screw cutouts

[Rich Brown]

+1 (I know this is not a vote.) But this would be a terrific addition. Sorry 
for the late feedback on this

> On May 27, 2024, at 9:27 AM, Paul D  wrote:
> 
> I guess this isn't often discussed unless one is dealing with large volume - 
> but does the case include keyhole screw cutouts, those specially made holes 
> that accommodate screws for non horizontal mounting using a couple of screws? 
> These would make life easier for some - as the ruggedized heat-sink ish case 
> in the renders probably requires special anchoring for wall mount. 
> 
> 
> See attached. 
> 
>> I have attached two pictures of the final case design these should arrive 
>> with the ODM this week.
> 
> ___
> 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: Install LuCI for snapshots builds

[Rich Brown]

+1 - I endorse installing LuCI in snapshot builds.

- A significant fraction of people will wind up installing LuCI anyway.
- It's a FAQ on the forum. "I just installed a snapshot build, but there's no 
web GUI." (This even bites me from time to time...)
- LuCI poses less of a space concern (in the days of 4MByte Flash, it might 
have made a difference - no more.)
- People who're intentionally working on small Flash systems are rolling their 
own builds anyway.
- It's one fewer configuration option in our build process

Thanks for asking about this, Paul.

Rich

> On May 7, 2024, at 5:24 PM, Paul Spooren  wrote:
> 
> Hi all,
> 
> For some reason (resource usage?) our snapshot builds do not include the LuCI 
> web interface. I think it’s an advantage to have LuCI installed in snapshot 
> images since a) it installed for all releases anyway and b) often it’s just 
> nice to have the web interface directly available.
> 
> Is anyone against having the interface installed by default? I remember from 
> multiple (in-person) discussion with fellow developers, that they’d prefer it 
> being installed.
> 
> If it’s an oversight I’d like to see it added to the default packages (via 
> the builedbot config), if there’s a reason to keep it from snapshots, I’d 
> like to understand the details.
> 
> Thanks,
> Paul
> ___
> 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: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?

[Rich Brown]

Thank you Felix for the careful review.

> On Feb 5, 2024, at 3:28 PM, Felix Baumann via openwrt-devel 
>  wrote:
> 
> I would do an estimate if I could. I don't think it's possible to do one 
> without building images. Especially since OpenWrt will grow a bit as well 
> till any release is done.
> But I also wouldn't worry too much about this if I were you :)

I raised these (admittedly imprecise) points to see whether we are approaching 
any thresholds that would eliminate support for a large number of devices (like 
the transition away from 4/32 devices). If no threshold is looming, that's 
great.

If there were, I am voicing my support for moving to 6.6 now so that dev's 
don't have to do much the same work twice in the next 1-2 years.

Thanks again.

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

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

[Rich Brown]

> On Feb 5, 2024, at 5:35 AM, Zoltan HERPAI  wrote:
> 
> 
> One thing I fully agree with Hauke is that we should pick one (and only one) 
> kernel for the next release, whenever that is. If we need to drop targets to 
> achieve it (no maintainer stepping up or lack of storage on the devices), so 
> be it.

+1. 

To aid in the analysis, I copy/pasted the Table of Hardware into a spreadsheet 
to see what we would be losing. I started with 
https://openwrt.org/toh/views/toh_extended_all

The resulting spreadsheet is at: 
https://docs.google.com/spreadsheets/d/1j_Yv62tdYzvA4iU216W3B0XHswXv2U2LrxQ0QOB5-vE/edit?usp=sharing

The tabs are:

- Original Data - as copy/pasted from the Table of Hardware. Cells are 
protected to prevent inadvertent changes.
The rest of the spreadsheet is unprotected and you should feel free to 
modify it/make new tabs
- Sorted by Curr Release - same data, but sorted by Current Release column 
(Column I)
- 23.0x-only devices - removes the rows for 22.0x and earlier, and current 
release = blank
- Changelog - changes from original data to produce current state

Observations:

- There are ~2200 devices listed in the ToH
- There are ~880 devices that are only supported in 22.0x and earlier
- There are ~330 devices that have the empty string as the Supported Current 
Release
- Virtually all the devices in the last two items (22.0x and earlier, and empty 
string) have been discontinued/unavailable from before 2020

Can someone who knows more about our devices make a judgement whether we would 
lose an appreciable fraction of devices by switching to a kernel that might not 
fit/work? Thanks.

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

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

[Rich Brown]

+1  Thanks 

> On Jan 30, 2024, at 1:15 PM, Christian Marangi (Ansuel) 
>  wrote:
> 
> 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.
> 
> The vote shall be concluded within 14 days. (13/02/2024)
> 
> ___
> openwrt-adm mailing list
> openwrt-...@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm


___
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

[Rich Brown]

> On Jan 18, 2024, at 12:11 PM, Dave Taht  wrote:
> 
> OpenWrt One could use a logo...

Could we get the designer of the current OpenWrt logo/wordmark to augment it 
with the word "One"?

See: 
https://github.com/openwrt/branding/blob/master/logo/openwrt_logo_text_horizontal_blue_and_dark_blue.svg
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt Next Generation Ideas-User Experience

[Rich Brown]

Thanks Arınç for opening this discussion about improving the development 
process. I would like to expand the discussion to include what, if any, changes 
we'd like to make in the user experience for OpenWrt.

The first one I would propose is "Automatic renumbering of LAN in case of 
conflict with WAN". It uses mDNS (say, "openwrt.lan") instead of 192.168.1.1 
for initial connection to the router. The behavior was carefully outlined by 
@psherman in this forum article.

https://forum.openwrt.org/t/automatic-renumbering-of-lan-in-case-of-conflict-with-wan/115752/51

Making this change would dramatically simplify the "new user experience" (and 
its documentation) because newcomers would not have to deal with all the subnet 
information before they can even get started.

My request: I'm not a developer. Is there someone on the list who would be 
interested to take this on? Thanks.

Rich

> On Mar 31, 2023, at 5:44 AM, Arınç ÜNAL  wrote:
> 
> Hi all,
> 
> These are the ideas I've been thinking about for the future of OpenWrt for a 
> while. It looks complete enough to share it with all of you.
> 
> I'm willing to put a great deal of effort to get as much out-of-tree patches 
> on mainline Linux as possible.
> 
> You can make a comment on Notion or discuss it here, I'm wondering if the 
> ideas are feasible and how well it would benefit the people maintaining 
> OpenWrt.
> 
> https://arinc9.notion.site/OpenWrt-next-gen-ideas-6db745e7584b4823950291c96f2326bb
> 
> Arınç
> 
> ___
> 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: Automatic LAN Subnet Reassignment PLUS mDNS name

[Rich Brown]

Thank you Imre for bringing this up again. I have also notified the author of 
that RFC (Peter Sherman, @psherman on the forums) that this discussion is going 
on so he can offer opinions. You can read the RFC at: 
https://forum.openwrt.org/t/rfc-automatic-lan-subnet-reassignment-upon-conflict-with-wan/120938

I strongly support this automatic LAN subnet assignment, primarily as an aid 
for newcomers. I wrote an early version of "Getting started with OpenWrt", and 
a horrendous amount of text goes toward setting up the proper LAN subnet. 

With these TWO changes - Automatic LAN assignment PLUS mDNS name - the 
instructions become:

1. Install OpenWrt on the router using the manufacturers instructions, and the 
image you retrieve from the Firmware Selector
2. Connect the WAN port to your ISP's gear
3. Connect your laptop to one of the LAN ports with Ethernet
4. Point your browser to "openwrt.lan"

The advantages (for newcomers, and for documentation writers) seem clear to me. 
I ask the collective wisdom of this group: what are the disadvantages? Many 
thanks.

Rich

> On Feb 27, 2023, at 8:08 AM, Imre Kaloz  wrote:
> 
> Hi Rich,
> 
> Basic (v4 only) version of these (as well automatic wan proto detection) was 
> implemented and rejected some years ago :)
> 
> Both are quite easy to do, that version used the following hotplug script:
> 
> ===
> #!/bin/sh
> 
> if [ "$INTERFACE" = "wan" ] && [ "$ACTION" = "ifup" ]
> then
># Get subnets for lan and wan
>lan_subnet=$(uci get network.lan.ipaddr | cut -d '.' -f3)
>wan_subnet=$(ifconfig wan | grep -w "inet" | awk '{print $2}' | cut -d 
> ':' -f2 | cut -d '.' -f3)
> 
># If subnet is the same, randomize lan IP
>if [[ $lan_subnet == $wan_subnet ]]; then
>rn=$(awk 'function rn(n) { return int(rand()*n); } BEGIN {{ 
> srand(); }{ printf("%d.%d", rn(254), rn(254))}}')
>uci set network.lan.ipaddr=10.$rn.1
>uci commit network
> 
># Restart network to refresh changes
>/etc/init.d/network restart
>fi
> fi
> ===
> 
> Setup of redirection ran as an init script:
> 
> ===
> #!/bin/sh
> 
> START=55
> boot() {
> 
> lanip=$(uci get network.lan.ipaddr)
> 
> grep -q "myrouter.local/$lanip" /etc/config/dhcp
> if [ $? -eq 1 ] ; then
> # add a redirect myrouter.local to our IP
>uci add_list dhcp.@dnsmasq[0].address="/myrouter.local/$lanip"
>uci commit dhcp
> fi
> }
> ===
> 
> 
> Best,
> Imre
> 
> 
> From: openwrt-adm  on behalf of Rich 
> Brown 
> Sent: Monday, February 21, 2022 22:38
> To: OpenWrt Project Administration; openwrt-devel@lists.openwrt.org
> Cc: Richard E. Brown
> Subject: Automatic LAN Subnet Reassignment
> 
> There is a new RFC on the OpenWrt forum proposing "Automatic LAN Subnet 
> Reassignment" 
> https://forum.openwrt.org/t/rfc-automatic-lan-subnet-reassignment-upon-conflict-with-wan/120938
>  The RFC responds to the advice given at last week's OpenWrt-Adm meeting 
> (https://etherpad.wikimedia.org/p/ZlZiTcud3wufcSX9-1jD)
> 
> The intent of the proposal is for the default configuration to assign a LAN 
> subnet that avoids a conflict with the WAN subnet, and provide a mDNS name 
> such at OpenWrt.lan for connections.
> 
> I have two requests:
> 
> 1) Please make comments on the technical merits of the proposal on the 
> OpenWrt forum at the link above.
> 
> 2) If the proposal seems to make sense, please consider the process by which 
> we would incorporate this into the main release (likely, not for 22.0x, but 
> perhaps the next release?)
> 
> Thank you.
> 
> Rich
> 
> 
> 
> ___
> openwrt-adm mailing list
> openwrt-...@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm


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

Re: DSA Terminology

[Rich Brown]

Let me rephrase to be sure if I understand correctly:

> On Sep 13, 2022, at 3:56 PM, Jo-Philipp Wich  wrote:
> 
> 
> This cannot be done in a sane manner though as it would render future versions
> entirely backwards incompatible.
> 
> Renaming `config interface` to `config network` makes sense and can be
> implemented easily. However we would still need to treat `config interface` as
> synonym for it in the forseeable future in order to retain compatibility,
> which means that we cannot reuse `interface` for something else.
> 
> So changing `config interface` to `config network` would be possible assuming
> that `config device` remains `config device` (or is renamed to something other
> than `interface`).
> 
> At the same time, the `wifi-iface` section type in /e/c/network should be
> changed to `wifi-network` in order to remain consistent.

I am assuming that the code that processes /etc/config/network and 
/etc/config/wireless is the difficulty. It would be possible to change names on 
labels in the GUI, and to update the documentation with the new terms. But we 
need to be able to handle existing configuration files - either to accept them, 
convert them, or give cogent error messages.

That code could retain the current "config device..." to refer to things that 
move bits (that is, things we have defined as "interfaces" in this current 
discussion) No change to uci processing would be necessary.

That code could use "config network" as a new synonym for things that were 
formerly "interfaces". uci would need to treat "network" in the same way as it 
formerly handled "interface"

That code could treat "config wifi-network" as a new synonym for "config 
wifi-iface" (for parallelism with the new "network").

The problem: "config interface" (and the similar "wifi-iface"). We're switching 
the word "interface" (and "iface") that has been used in config files from one 
concept to another. This could leave the config files with ambiguous commands.

How could the code that reads those configuration files handle the presence of 
"interface/iface" keywords? Thanks.

Rich



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

Re: DSA Terminology

[Rich Brown]

Hello Arınç,

Thank you for persisting in correcting my understanding. I appreciate the link 
to the dsa.rst document. I now realize that as you and jow have said, "DSA is 
simply a way to give each port of a switch its own name" so it can be 
configured. 

But if I'm reading it right, there's a clash between your definitions (say, in 
https://openwrt.org/playground/arinc9/network.interfaces) and the LuCI 
interface and the /etc/config/wirelsss terminology. If I'm reading it right, 
"config device" controls the configuration of interfaces, while "config 
interface" does what your DSA terminology calls "networks". Is this correct?

If my observation is correct, how can we correct the terminology across all of 
OpenWrt? Thanks.

Rich

PS I edited the DSA Mini-tutorial to strike through the entire Terminology 
section pending the outcome of this discussion. Thanks again.

> On Sep 11, 2022, at 6:45 PM, Arınç ÜNAL  wrote:
> 
> On 12.09.2022 00:28, Rich Brown wrote:
>> I think I see where I went wrong. I have updated the definitions in the DSA 
>> Terminology page to incorporate what I understand from this conversation. 
>> See: 
>> https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#terminology
>> Is this getting closer to a set of good definitions? Thanks.
> 
> It's much better than before. Though, the terminology section explains 
> computer networking rather than DSA.
> 
> Interfaces and networks are beyond any sort of classification under any OSI 
> layer.
> 
> Interface is what makes the data transfer happen. It's not a protocol you can 
> classify under an OSI layer.
> 
> Network is the representation of computers (anything with the ability of 
> computing) sending data to each other through interfaces. It represents the 
> EVERY THING of communication.
> 
> Each network entry on OpenWrt would mean that your router is a part of that 
> network connected through an interface. Then, you can configure your computer 
> (call this our router) to transmit and receive data in certain way.
> 
> For this network which we're connected to, through this interface:
> Send data with this IP address, analyse received data for this range of IP 
> addresses and act different when something we defined matches. Send data with 
> this MAC address, listen for this MAC address on the received data. Send DHCP 
> packets, listen for DHCP packets, etc. Does this make sense?
> 
> Getting back to DSA, DSA doesn't have much to do with any of these. Like it's 
> said multiple times in this thread (under a few different subjects), at its 
> core, it creates a network interface for each switch port. This documentation 
> should be enough to explain the terminology.
> 
> https://github.com/torvalds/linux/blob/master/Documentation/networking/dsa/dsa.rst
> 
> On top of this, I'd like to give two configuration examples for any ethernet 
> interfaces, including the interfaces created by DSA.
> 
> - One without bridge VLAN filtering
>  - Only lan interfaces on the bridge, VLAN-unaware forwarding.
>- Keep wan interface separate.
>  - No bridge, use each interface separately.
> 
> - One with bridge VLAN filtering
>  - All interfaces on the bridge, VLAN-aware forwarding.
> 
> My "Converting to DSA" page already follows the second configuration.
> 
> Arınç
> 
>> Rich
>>> On Sep 10, 2022, at 9:47 AM, Arınç ÜNAL  wrote:
>>> 
>>> On 10.09.2022 14:59, Rich Brown wrote:
>>>> I got the following definitions from Arınç, I am taking the liberty of 
>>>> opening this to the entire list, so we can refine these definitions 
>>>> together. I include some questions in-line to clarify the definitions.
>>>>>>> As a start, certain terms have cropped up multiple times in this 
>>>>>>> discussion. Could I ask for definitions for the following terms?
>>>>>>> 
>>>>>>> Network:
>>>>> 
>>>>> A network represents a group of computers communicating with each other.
>>>>Are there other constraints for what comprises a network? For example, 
>>>> which of these would be considered to be "a network" in our DSA discussion?
>>>>- Computers in the same subnet range
>>> 
>>> That's a network.
>>> 
>>>>- Computers on the same VLAN
>>> 
>>> That's a network.
>>> 
>>>>- Computers physically attached to a switch or bridge (perhaps on 
>>>> different subnets)
>>> 
>>> That'd be multiple networks but I guess that's technically a single network 
>>> since computers on differe

Re: DSA Terminology

[Rich Brown]

I think I see where I went wrong. I have updated the definitions in the DSA 
Terminology page to incorporate what I understand from this conversation. See: 
https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#terminology 

Is this getting closer to a set of good definitions? Thanks.

Rich

> On Sep 10, 2022, at 9:47 AM, Arınç ÜNAL  wrote:
> 
> On 10.09.2022 14:59, Rich Brown wrote:
>> I got the following definitions from Arınç, I am taking the liberty of 
>> opening this to the entire list, so we can refine these definitions 
>> together. I include some questions in-line to clarify the definitions.
>>>>> As a start, certain terms have cropped up multiple times in this 
>>>>> discussion. Could I ask for definitions for the following terms?
>>>>> 
>>>>> Network:
>>> 
>>> A network represents a group of computers communicating with each other.
>>  Are there other constraints for what comprises a network? For example, 
>> which of these would be considered to be "a network" in our DSA discussion?
>>  - Computers in the same subnet range
> 
> That's a network.
> 
>>  - Computers on the same VLAN
> 
> That's a network.
> 
>>  - Computers physically attached to a switch or bridge (perhaps on 
>> different subnets)
> 
> That'd be multiple networks but I guess that's technically a single network 
> since computers on different subnets can still communicate with each other at 
> the second layer.
> 
> The means of delivering data in between (switch, bridge etc.) is also 
> expected on the examples above.
> 
>>  - Are there other synonyms for "network"?
> 
> I don't believe so.
> 
>>>>> Network Interface:
>>> 
>>> A network interface is the point of interconnection, implemented on the 
>>> software, between computers.
>>  - I had earlier written "... physical connections that convey 
>> bits/frames to other computers ... such as individual Ethernet switch ports, 
>> wireless radios, USB networking devices, VLANs, or virtual ethernets."
>>  - How much of this is correct? What should be added or removed?
>>  - What about bridges, tunnels, alias interfaces - include or exclude 
>> them? Why?
>>  - Must a network interface to be "implemented in software"?
> 
> That's what a network interface is. It's a software term.
> 
>>  - Or do you mean that the network interface is the "software 
>> representation" of a physical connection?
> 
> Software representation of interconnection, doesn't have to be physical.
> 
>>>>> Interface:
>>> 
>>> Short for network interface.
>>  - Can we *always* treat this as a synonym for "network interface"?
> 
> I believe so.
> 
>>>>> Device:
>>> 
>>> Another term for network interface, used a lot on Linux kernel development.
>>  - Can we *always* treat this as a synonym for "network interface"?
> 
> No. Outside of Linux driver development, I don't see this widely used in 
> computer networking software.
> 
>>>>> Netdev:
>>> 
>>> A mailing list for all network-related Linux stuff. 
>>> https://docs.kernel.org/process/maintainer-netdev.html#what-is-netdev
>>  - Is "netdev" used commonly in DSA/OpenWrt as a formal term?
>>  - If not (and if we need to rename something in config files), could 
>> the term "netdev" provide a new word that isn't ambiguous?
> 
> I don't understand what you're getting at?
> 
> Arınç


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

Re: DSA Terminology

[Rich Brown]

> On Sep 10, 2022, at 7:52 AM, David Lang  wrote:
> 
> There is a difference between a physical device that passes bits and the 
> logical interface that communicates with a network range. A given physical 
> devices can have multiple logical interfaces on them, and a logical interface 
> can use multiple physical devices to communicate (i.e. it's not a 1:1 
> relationship between logical interfaces and physical devices.

Yes, this is a complicated field of study. No only is physical : logical 
interface not 1:1 but the way we create more layers (VLANs, tunnels, etc) only 
increases the flexibility (and complexity).

> LUCI is inconsistant and sometimes calls physical devices 'interfaces' and 
> sometimes calls logical interfaces 'interfaces'

And this adds another opportunity for confusion :-(

> I would have to go back over this thread to give a better definition for each 
> term, but they are not all names for the same thing as described below (well, 
> they can be in simple configurations, but much more complex configurations 
> are possible, and as people start using the power, the confusion of terms 
> causes problems)

That's why I'm striving to find solid definitions for the base terms, so we can 
build on them and use them to create comprehensible documentation. Thanks, all.

Rich Brown


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

Re: DSA Terminology

[Rich Brown]

I got the following definitions from Arınç, I am taking the liberty of opening 
this to the entire list, so we can refine these definitions together. I include 
some questions in-line to clarify the definitions.

>>> As a start, certain terms have cropped up multiple times in this 
>>> discussion. Could I ask for definitions for the following terms?
>>> 
>>> Network:
> 
> A network represents a group of computers communicating with each other.
Are there other constraints for what comprises a network? For example, 
which of these would be considered to be "a network" in our DSA discussion?
- Computers in the same subnet range 
- Computers on the same VLAN 
- Computers physically attached to a switch or bridge (perhaps on 
different subnets) 
- Are there other synonyms for "network"?

>>> Network Interface:
> 
> A network interface is the point of interconnection, implemented on the 
> software, between computers.

- I had earlier written "... physical connections that convey 
bits/frames to other computers ... such as individual Ethernet switch ports, 
wireless radios, USB networking devices, VLANs, or virtual ethernets." 
- How much of this is correct? What should be added or removed?
- What about bridges, tunnels, alias interfaces - include or exclude 
them? Why?
- Must a network interface to be "implemented in software"? 
- Or do you mean that the network interface is the "software 
representation" of a physical connection?

>>> Interface:
> 
> Short for network interface.
- Can we *always* treat this as a synonym for "network interface"?

>>> Device:
> 
> Another term for network interface, used a lot on Linux kernel development.
- Can we *always* treat this as a synonym for "network interface"?

>>> Netdev:
> 
> A mailing list for all network-related Linux stuff. 
> https://docs.kernel.org/process/maintainer-netdev.html#what-is-netdev
- Is "netdev" used commonly in DSA/OpenWrt as a formal term?
- If not (and if we need to rename something in config files), could 
the term "netdev" provide a new word that isn't ambiguous?

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

Re: DSA Terminology

[Rich Brown]

Thanks for all this discussion. I have read everyone's notes carefully, but I 
feel as if I am falling farther and farther behind. 

I don't understand the distinctions between the terms that everyone is using. 
(The networking field is replete with synonyms for the same thing: "interface" 
(and device, port, jack, socket, interface, etc.) might refer to that hole in 
the back of a computer that receives an RJ-45 connector. And "interface" (and 
network, subnet, address range and others) might apply to the 192.168.1.1 .. 
255 concept. I think that's what's happening here.)

Perhaps I have missed a glossary for these terms. Just point me to one that 
works for this DSA discussion. If there isn't one, we need to make one. 

As a start, certain terms have cropped up multiple times in this discussion. 
Could I ask for definitions for the following terms? 

Network: 

Interface:

Network Interface:

Device:

Netdev:

Other terms?

Once we have agreement on the terms/concepts above, we can begin to talk about 
how those names should be reflected in /etc/config/network and 
/etc/config/wireless and in the LuCI web GUI. Many thanks

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

Re: DSA Terminology

[Rich Brown]

Hi jow, thanks for weighing in. I'm glad that I'm not unnecessarily confused - 
the naming *is* inconsistent. It sounds as if different "contexts" have varying 
definitions for the terms "interface", "network", "device", etc... (LuCi, 
/etc/config/network, the kernel.org article about DSA configuration, others?)

When this has happened to me in other lives, it was useful to pause and agree 
on what we would *like* the end state to be. We can then figure out the 
technical means to get there. In parallel, we can work on definitions and 
descriptions that support the end state.

Regrettably, I don't understand enough about this to make a stab at it. Anyone 
want to leap in? Thanks.

Rich

PS I changed the subject line to "DSA Terminology" since that's really what 
we're talking about

> On Sep 7, 2022, at 5:12 PM, Jo-Philipp Wich  wrote:
> 
> Hi,
> 
>>> I wrote this mostly because the LuCI interface itself makes a distinction
>>> between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the
>>> best way to describe what goes there.
>> 
>> I agree that there are inconsistencies in LuCI. The only place I see the
>> terminology correctly stated is on the wireless section:
>> 
>> Network: Lists all entries on the Interfaces section.
>> 
>>> Choose the network(s) you want to attach to this wireless interface or >
>> fill out the custom field to define a new network.
>> 
>> Which correctly states that:
>> 
>> Interfaces section should be called Networks.
>> Devices section should be called Interfaces.
> 
> I agree that there's inconsistencies, I eventually want to clean that up.
> Part of the terminology stems from uci itself, where `config interface`
> declares logical *networks* while *interfaces* (as in Linux netdevs) are
> referred to as `config device` (and `config wifi-*iface*` for wireless, which
> probably should be named differently too).
> 
> Personally I am fine with rebranding the logical network entities (lan, wan,
> loopback etc.) to "networks" but I am unsure about renaming what is currently
> "devices" to "interfaces" as it would then intersect with the current meaning
> of interfaces...
> 
> Anyhow, so while I agree that:
> 
>> Interfaces section should be called Networks.
>> Devices section should be called Interfaces.
> 
> ... it will directly contradict /etc/config/network, where networks are called
> `config interface` and interfaces are called `config device` likely leading to
> even more confusion.
> 
> 
> ~ Jo
> 
> ___
> 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: DSA Mini-tutorial

[Rich Brown]

> On Sep 6, 2022, at 5:33 PM, Florian Fainelli  wrote:
> 
>> I don't see much content to document DSA. All DSA does is creating a network 
>> interface for each switch port. What I think should be properly documented 
>> is the Bridge VLAN filtering feature. I have made some efforts to do that on 
>> my playground here:
>> https://openwrt.org/playground/arinc9/start
>> ...
> 
> Maybe this is enough to reference since it contains basic use cases, and not 
> so basic ones, too:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst
> -- 

I have the sense that the terminology surrounding DSA is very murky. But in the 
DSA Mini-tutorial, 
(https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) I made a 
distinction between "Devices" and "Interfaces in the Terminology section.

- Devices are things that 'send bits' without regard for IP address or subnets

- Interfaces correspond to IP subnet ranges, and the routing function within 
the router moves packets between interfaces.

I wrote this mostly because the LuCI interface itself makes a distinction 
between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the 
best way to describe what goes there.

Perhaps we could get the designer of the LuCI interface and other networking 
gurus to weigh in on how to describe this. Thanks.

Rich

PS I don't have a dog in this fight. If the entire Mini-tutorial were scrapped, 
and replaced with a description of what's true and correct, I would be happy. 
Thanks again
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

re: DSA Mini-tutorial

[Rich Brown]

Hello Arınç (and the rest of the list),

It's good to hear from you again.

> On Sep 4, 2022, at 5:32 PM, Arınç ÜNAL  wrote:
>
>  I don't see much content to document DSA. All DSA does is creating a network 
> interface for each switch port. What I think should
> be properly documented is the Bridge VLAN filtering feature. I have made some 
> efforts to do that on my playground here:
> 
> https://openwrt.org/playground/arinc9/start

I had not looked at your pages recently but we should make sure all the 
information makes it out of the playground into the main wiki.

I see that we have slightly different definitions for "interface" and "device" 
in DSA. Here are the versions:

DSA Mini-Tutorial - Terminology:

https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#terminology

Playground - Definition of a Network Interface

https://openwrt.org/playground/arinc9/network.interfaces#definition_of_a_network_interface
 

Because I don't really know about DSA, I don't know how important it is to call 
an Ethernet switch port a "device" or whether it's OK simply to call it an 
"Ethernet interface".

How could we start to merge all these documents? Thanks.

Rich

PS Thoughts from other readers would be welcome!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

DSA Mini-tutorial still marked as Work In Progress

[Rich Brown]

Folks,

The DSA Mini-tutorial on the Wiki 
(https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) is still 
marked as a "Work In Progress"

I should know - I wrote this up as we were getting ready to ship 21.02, and I 
thought that we should have something about DSA on the wiki. But I don't really 
know anything about DSA - I simply pieced the article together from a few forum 
posts. And I never received any direct feedback or saw any updates to the wiki 
page. 

I was "makin' a lot of stuff up" as I wrote that page. It's the best I could 
do, but nothing that's written there should be taken as gospel. The italics 
near the top indicate areas of uncertainty. I also was guessing about the 
difference between device and interface definitions. 

Here's my request: 

It would do my heart good to have someone who's knowledgeable about DSA read 
through the page and either make direct corrections, or send me a note and I'll 
make them.  Thanks.

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

[Rich Brown]

> On Aug 12, 2022, at 5:12 PM, Florian Fainelli  wrote:
> 
>> 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 :)

I've been lurking in this discussion, but thought I would throw in this 
perspective:

Who is asking for this? Could we ask them to quantify the benefit (to them) of 
a six-year LTS?

Would they be willing to fund the effort required? (Some companies decide that 
Red Hat or Ubuntu are critical to their business, and hire people/assign 
developers to work to support those distributions...)

Thanks for listening.

Rich

(Sorry for any duplicates - original message was in Rich Text...)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Seeking RPM Server package for OpenWrt

[Rich Brown]

Bjørn,

Thanks for these comments.

> On Mar 23, 2022, at 8:34 AM, Bjørn Mork  wrote:
> 
> There is no need to read anything from a file or device.  You can just
> serve the same memory buffer in a loop.

That might satisfy Paul Spooren's concern.

> I did a quick look at the document and it seems under-specified.  Page
> after page with blah-blah, but
> - not defining Content-Type for any of the URLs
> - not defining ciphers or any other TLS options, despite the rather
>  restrictive TLSv1.3 requirment
> - no config examples for common web servers
> - no actual client algorithm
> 
> The last point is obviously the biggest problem.  You can do whatever
> you want when implementng this, so the results from different clients
> will not be comparable at all.
> 
> IMHO it's better let this soak for a while until they've reversed the
> blah-blah to content ratio.  This doesn't look like a finished protocol.

Although I took an editorial pass over an earlier version of the RFC, I'm not 
in a position to address your questions. 

Let me propose this process for continuing the conversation. With this 
response, I'm cc'ing:

- openwrt-devel
- RPM mailing list
- named individuals

Not everyone is subscribed to both lists, but cc'ing everyone who responds 
should keep everyone included.

Thank you.

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

Fwd: Seeking RPM Server package for OpenWrt

[Rich Brown]

Hi Paul,

> The spec wants a 8GB file which seems a bit much for common home routers. We 
> could look into reading from /dev/zero since the body content isn’t relevant 
> but still the device is likely slower at offering the content than your 
> laptop can chew. A dedicated device could be required.
> 
> Did you ask upstream about your idea? Maybe they have something in mind 
> already.

Good point. But it's worse than that :-)

It's also possible low-powered CPUs won't be able to keep up with the data 
stream, so won't achieve saturation...

Still, I figured I would ask for help to see if it might be possible to try. 
Thanks!

Rich

(Also cc:d to RPM list)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Seeking RPM Server package for OpenWrt

[Rich Brown]

The Apple "RPM Tool" is great for measuring network responsiveness.

High numbers from the tool (measured in round-trips per minute - or "RPM") show 
your network is responsive, even when it's heavily loaded with traffic. This 
also implies you have low "bufferbloat" - which is good.

There are several RPM clients available:

* `/usr/bin/networkQuality` on macOS Monterey
* an iOS 15 version described at https://support.apple.com/en-gb/HT212313
* a golang implementation at https://github.com/network-quality/goresponsiveness
* a Docker implementation in the same repository

BUT... These all test against servers "out on the internet". There's another 
interesting test to be had: testing against the local router. 

This is useful because it would help test the responsiveness of the Wi-Fi 
network/drivers of your router. It would allow you to measure whether in fact, 
you actually are too far from the router, and whether moving closer would help. 

My request... Is anyone interested in creating an OpenWrt package that 
implements an RPM server? 

Fundamentally, an RPM server is an HTTPS server that responds to the four URLs 
described on Page 12 of the Responsiveness spec at: 
https://github.com/network-quality/draft-ietf-ippm-responsiveness/blob/master/draft-ietf-ippm-responsiveness.pdf

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

Automatic LAN Subnet Reassignment

[Rich Brown]

There is a new RFC on the OpenWrt forum proposing "Automatic LAN Subnet 
Reassignment" 
https://forum.openwrt.org/t/rfc-automatic-lan-subnet-reassignment-upon-conflict-with-wan/120938
 The RFC responds to the advice given at last week's OpenWrt-Adm meeting 
(https://etherpad.wikimedia.org/p/ZlZiTcud3wufcSX9-1jD) 

The intent of the proposal is for the default configuration to assign a LAN 
subnet that avoids a conflict with the WAN subnet, and provide a mDNS name such 
at OpenWrt.lan for connections.

I have two requests:

1) Please make comments on the technical merits of the proposal on the OpenWrt 
forum at the link above.

2) If the proposal seems to make sense, please consider the process by which we 
would incorporate this into the main release (likely, not for 22.0x, but 
perhaps the next release?)

Thank you.

Rich



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

Re: Release goals for 22.XX

[Rich Brown]

Paul, Rafał, 

I think our emails passed in the ether... 
(http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html)

As I said in that message, I am very aware of the time constraints of the 
volunteers for OpenWrt. And I don't mean to suck the conversation into "grand 
strategies" without any endpoint. 

Let's focus on our next step. In my earlier note, I asked:

1) What would prevent us from accomplishing the 22.XX Release Goals in March 
2022? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx) 

- How do we see the time between now and March playing out?
- Are there things we should leave out? Or should the release date be shifted?

I would invite everyone to weigh in. Thanks.

Rich

cc: OpenWrt-adm

> On Oct 6, 2021, at 10:14 AM, Paul D  wrote:
> 
> 
> Wise words from the experienced!
> 
> If making a yearly release is unattainable, isn't making point releases more 
> achievable? Even if it's adding a single commit, point releases send a signal 
> to the outside world that the project is still active, and e.g. that security 
> is in focus. Any point release can be done for trivial amendments and GUI 
> fixes. ( I do not make light of the steps involved in doing a release ). The 
> idea being that at least these point releases can be done regularly.
> 
> 
> So the 'yearly' release is unattainable: is this largely due to the amount of 
> new material that goes into the 'main/master/head' branch that needs to be 
> picked and normalized and made stable (if that's how I might summarize making 
> all the platforms behave consistently)? I would be fine without regular 
> yearly releases. nightlies are available etc.
> 
> 
> 
> On 2021-10-06 07:58, Rafał Miłecki wrote:
>> On 30.09.2021 03:34, Rich Brown wrote:
>>> My desire would be to name our next release "22.03", with a target release 
>>> date in March 2022. And we should name the following release "22.09" with a 
>>> release date in September. And so on - every six months (or whatever 
>>> interval we believe we can sustain for the long term.)
>> This is absolutely undoable. We have too little manpower and too little
>> people actually interested in preparing releases. It takes testing,
>> checking feedback, reviewing bug reports, debugging issues, backporting
>> changes. That is a lot of work.
>> Every time we have a discussion about releases there comes an idea of
>> time-based releases. Also a lot of people have opinions on when to
>> branch and how to proceed with development.
>> When it comes to actually working on a release there are very people
>> that stay involved.
>> ___
>> 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: Release goals for 22.XX

[Rich Brown]

> On Oct 6, 2021, at 1:58 AM, Rafał Miłecki  wrote:
> 
> On 30.09.2021 03:34, Rich Brown wrote:
>> My desire would be to name our next release "22.03", with a target release 
>> date in March 2022. And we should name the following release "22.09" with a 
>> release date in September. And so on - every six months (or whatever 
>> interval we believe we can sustain for the long term.)
> 
> This is absolutely undoable. We have too little manpower and too little
> people actually interested in preparing releases. It takes testing,
> checking feedback, reviewing bug reports, debugging issues, backporting
> changes. That is a lot of work.
> 
> Every time we have a discussion about releases there comes an idea of
> time-based releases. Also a lot of people have opinions on when to
> branch and how to proceed with development.
> 
> When it comes to actually working on a release there are very people
> that stay involved.

I am so pleased that you are pushing back against my suggestion, especially 
since you are actually *doing* the work. (I have not, and probably will never 
contribute any code to OpenWrt. But I've been writing software for 40 years, 
and have watched a lot of projects struggle with their goals.)

I advocate for regular releases because:

- It keeps the project fresh. We look like a "living project" and attract new 
users and new developers
- Our users get new features in stable versions on a regular basis
- It gives our users confidence in us
- It makes us proud to ship software

BUT... you point out the very real problem - limited available time for people 
who can actually do the work.

This leads me to think about how we can preserve our most precious resources - 
time and attention. Some questions:

1) What would prevent us from accomplishing the 22.XX Release Goals in March 
2022? (https://openwrt.org/docs/guide-developer/releases/goals/22.xx) 

- How do we see the time between now and March playing out?
- Are there things we should leave out? Or should the release date be shifted?

2) How important is it to update kernels regularly? In the abstract, I know 
there's a balance between backporting critical bug fixes and important features 
to the current (older) kernel vs the effort to move (and test) our entire code 
base to a new kernel.

- But what real-world implications does this have for OpenWrt? 
- What's the balance (in time/effort) between those two activities?
- How do we balance the *value* of new kernel features vs what we could create 
if we spent the time on other projects?

3) Architecture support. There's a certain amount of pride that "OpenWrt runs 
just about everywhere". (I agree - this is an astonishing accomplishment.) 
But... now the attention from skilled developers is scarce.

- Does support of this broad variety of architectures add to the developer 
effort? 
- Should we ever drop architectures from support?
- How would we decided to do this?
- Can we make a "guesstimate" of how much time we'd save if we drop 
architectures?

4) How quickly should we embrace new devices? In the forum, and to a certain 
extent on openwrt-devel, I see notes like "Hey, I just found this sexy device 
quad-core device with 128M Flash and 512M RAM. And it's only US$17! Can you 
make OpenWrt run on it?"

- Does a task like this take any effort from "core developers"?
- Does a task like this increase our testing effort?
- Does a task like this create an on-going maintenance/support obligation?
- If so, do we need a process to decide whether to take on a new device?

5) I am fully aware that OpenWrt is driven by volunteers. We contribute because 
a particular piece of the puzzle seems interesting or fun. We can't "force" 
anyone to do anything.

- How can we construct OpenWrt goals (kernel, packages, releases, 
documentation, build system, all of it...) to match projects that excite our 
group?
- What would it mean to attract new people to "fill in the gaps" of our project.

I don't imagine that we'll come with answers to all these on the mailing list. 
Perhaps Hauke will add them to the next online meeting. Thanks for listening.

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

Re: Suggestion: Explicitly warn to not use GitHub web UI for patches

[Rich Brown]

> On Oct 5, 2021, at 10:24 AM, Paul D  wrote:
> 
> Write this up into an FAQ/howto on openwrt.org (this is, after all, the OWRT 
> way)

Yes, it's always more powerful (and useful) to tell people what TO do, instead 
of what NOT to do.

I contribute very occasionally, and by trial and error, I *think* I have found 
the procedure. (And if it's not right, or not optimal, I would be delighted to 
learn how to do it better...)

- In Github, fork the official repo into my personal Github account
- Clone my personal copy of the repo to my laptop
- Create a branch for my changes on my laptop

- Monkey around, improve the world, then...

- Squash my commits so that there's only one change (optional, but it tends to 
improve the commit messages)
- Push my commits back to my personal repo
- From my personal Github account, create a PR for my branch back to the 
official OpenWrt repo

Do I have the gist of it? Many thanks.

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

Re: Release goals for 22.XX

[Rich Brown]

(I'm cc'ing both openwrt-devel and openwrt-adm since both will be involved in 
the decision)

> On Sep 29, 2021, at 4:28 PM, Hauke Mehrtens  wrote:
> 
> The OpenWrt 21.02 release is done and we should plan the next release.
> We already talked about this in the last meeting, see 
> https://openwrt.org/meetings/20210920
> 
> To monitor the current state I created this wiki page based on the wiki page 
> from the previous release:
> https://openwrt.org/docs/guide-developer/releases/goals/22.xx

Thanks for creating this page. If I understand it correctly, we are talking 
about:

1. All targets to kernel 5.10 (I think we said we'd drop support for those that 
cannot move to 5.10)
2. Import/backport mac80211 from the 5.15 kernel
3. GCC 11.2 & musl 1.2.x (done)
4. Switch to firewall4 by default
5. Switch lantiq target to DSA (done)
6. (Minor? No?) changes to LuCI
7. Nothing else

Questions:

- Is this a correct summary of what we're talking about for the next release?

- Could we accomplish all this by year-end? Who would be over-burdened by 
choosing that target date?

- If this is feasible, we could branch in January, with a generous time for 
several RC's, with a plan to ship 22.03 in March.

- What (if anything) would be left out if we "only did this"?

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

Re: Release goals for 22.XX

[Rich Brown]

Hauke: My thanks also for writing up those note.

My desire would be to name our next release "22.03", with a target release date 
in March 2022. And we should name the following release "22.09" with a release 
date in September. And so on - every six months (or whatever interval we 
believe we can sustain for the long term.)

For each release, we need to work backwards, and make the feature freeze for 
the March release in, say, early January so the first RC can come out in 
January, we can have a few RCs leading up to a final release sometime within 
60-75 days. 

The reasons to do this:

- Some people can only use stable releases because of their business needs or 
their personality. (Or because we tell them "Only Use Stable!") Regular 
releases let them use the newest features. 

- Contrarily, a long release cycle "traps" new stuff behind something that 
"isn't quite done."

- We don't waste time producing and testing patched versions of the previous 
release. There were seven patch releases in the 19.07 series (running from 
January 2020 through August 2021). A regular release schedule could have 
avoided many of these.

- Having a firm feature freeze date decreases stress. If a particular feature 
is done/substantially working, it goes in. If it's not quite ready, it can skip 
this release, and get into the next release. (The alternative is what I think 
happened with DSA. It was a big change: there were a large number of problems 
that took a long time to iron out. That kept pushing out the date...)

- Customers (our users, our industry partners) gain confidence in projects that 
can meet their deadlines. Imre noted that "industry is using the snapshots..." 
but I suspect the extended schedule just worries other vendors.

Does this need a vote? Thanks.

Rich

> On Sep 29, 2021, at 4:28 PM, Hauke Mehrtens  wrote:
> 
> Hi,
> 
> The OpenWrt 21.02 release is done and we should plan the next release.
> We already talked about this in the last meeting, see 
> https://openwrt.org/meetings/20210920
> 
> To monitor the current state I created this wiki page based on the wiki page 
> from the previous release:
> https://openwrt.org/docs/guide-developer/releases/goals/22.xx
> 
> I would like to get an overview about the "big" changes, if an additional 
> board is added or something is improved we do not need to plan it.
> 
> I would like to get the following:
> 
> kernel 5.10:
> We should get all targets to kernel 5.10. All targets which are not on kernel 
> 5.10 when we branch off should get removed.
> 
> Kernel version for all targets:
> Kernel 5.10 (only):
> bmips
> Kernel 5.10 (5.4 still present):
> bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86
> Testing 5.10:
> apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta
> mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi tegra
> Kernel 5.4 only:
> arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap pistachio 
> uml zynq
> 
> toolchain:
> We already updated the toolchain in master to GCC 11.2, binutils 2.37 and 
> musl 1.2.2. This looks good to me. Minor version updates of musl libc later 
> should be ok. gdb and glibc could also be update later if someone wants to do 
> it.
> 
> mac80211:
> I would like to update the mac80211 version we use to match the code from 
> kernel 5.15 or whatever will be the next LTS kernel. I haven't started yet.
> 
> DSA:
> We will migrate some more boards to DSA, the lantiq/xrx200 target is using 
> DSA in master now. It looks like some boards with qca8k would switch. These 
> changes should be local to one target or even board anyway. The 
> infrastructure is already provided. This can continue without much 
> coordination and we can see what is finished when we branch.
> 
> firewall4:
> OpenWrt master contains firewall4 optionally which uses nftables instead of 
> iptables. It uses the same configuration as firewall3, the old configuration 
> should still work. Custom iptables extensions should also still work when we 
> use iptables-nft which supports the iptables user interface and generates 
> nftables rules, even Debian stable uses iptables-nft by default. Flow 
> offloading (software and hardware) is supported by upstream kernel when 
> nftables is used, we are currently using a patch to make it "work" with 
> iptables too.
> 
> We have to activate it by default and deactivate firewall3.
> We probably need some minor modifications to LuCi to show the current 
> nftables firewall status. This is not device depended like DSA, we can easily 
> test this on one device and it should work the same way on all others.
> 
> LuCi:
> What is still needed in LuCi?
> 
> 
> Is there anything else which is blocking, should be added or needs a 
> discussion?
> 
> Hauke
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___

Re: OpenWrt 21.02.0 Fourth release candidate - DSA docs

[Rich Brown]

Hi Arınç

> On Sep 17, 2021, at 3:17 AM, Arınç ÜNAL  wrote:
> 
> The current naming used on LuCI/UCI is inaccurate and confusing. The 
> “interfaces” under Network → Interfaces actually represent networks. The 
> actual interfaces are called “device”.

I agree that the terminology is confusing. I really struggled with the names 
when I added them into the preface to the DSA Mini-tutorial 
(https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial). I did some 
research looking at the original DSA documentation: it didn't offer much in the 
way of definitions. So I followed my usual practice of documenting the lingo of 
whatever application I'm using.

After looking hard at how LuCI seemed to work, I wrote:


• Devices are physical connections that convey bits/frames to other 
computers. They operate at layer 2 in the protocol stack, have a MAC address 
along with several other configurable parameters...

• Interfaces route IP packets and operate at layer 3 in the protocol 
stack. An interface is associated with a single device that sends/receives its 
packets. Interfaces get their IP address parameters by the choice of protocol...
-

I haven't heard any corrections from others about these assertions, so I am 
hopeful that I got those definitions right. 

When you say that "interfaces... actually represent networks" I think you mean 
that they're "subnets" (and have a subnet address range, IP address, and other 
characteristics). Is that what you mean? Although I'm neither a Linux OS or 
network expert, I can see an explanation for using the terms "devices" and 
"interfaces" as defined above.

In this case, I believe it will be difficult to change the terminology used in 
OpenWrt/LuCI. I think that train has left the station. Perhaps our efforts will 
be best used toward documenting the syntax and GUI as it is today, so that 
people can configure their gear the way they want.

Best regards,

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

Re: OpenWrt 21.02 status

[Rich Brown]

On Aug 29, 2021, at 6:31 AM, Hannu Nyman  wrote:
> 
> Hauke Mehrtens wrote at Sun Aug 29 02:53:47 PDT 2021:
> 
> We have now reverted back to the old "let's wait long for branching and then 
> wait even longer for the actual release".
> 
> The reality is the same than earlier: almost all devs and enthusiasts are 
> already with master where interesting new stuff happens, so 21.02 rots 
> quietly waiting for the release. The prolonged wait serves nobody :-(

I agree that we should release 21.02.0 in its current state.  We can then plan 
for a (relatively quick) 21.02.1 that addresses known issues and/or 
recently-discovered problems.

Do we need a formal Call for Vote on this? If so, I offer this wording:

---
We should release OpenWrt 21.02.0 in the current state (I need help specifying 
the exact commit to use). It has one known problem: hardware flow offloading 
may not work in certain cases. Disabling flow offloading provides a working 
device, possibly with decreased performance.
---

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

Re: OpenWrt 21.02.0 Fourth release candidate - DSA docs

[Rich Brown]

All,

> On Aug 10, 2021, at 1:10 PM, Hauke Mehrtens  wrote:
> 
> ... For 21.02 we should work on the DSA documentation which Rafal and Rich 
> already did and continue like it is now...

Maybe I'm worrying needlessly, but I want to say I'm concerned about those DSA 
pages on the wiki. 

They may look polished, but there are open (unanswered) questions in the text. 
I suspect they're WRONG in many places. I do not know enough to make any 
further changes to the documents:

DSA Mini-Tutorial: 
https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial

Converting to DSA: 
https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa

Upgrading to OpenWrt 21.02.0: 
https://openwrt.org/docs/guide-user/network/dsa/upgrading-to-2102

Is anyone willing to assure me that these are "good enough" for a release? If 
not, how shall we get these pages "up to snuff?" Thanks.

Rich

cc: OpenWrt-devel, OpenWrt-adm



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

Re: OpenWrt 21.02.0 Fourth release candidate

[Rich Brown]

Congratulations on RC4. I'm getting excited.

The release notes (below) have some steps for upgrading to 21.02. Is there any 
information in 
https://openwrt.org/docs/guide-user/network/dsa/upgrading-to-2102 that should 
be incorporated there? 

Thanks.

> On Aug 4, 2021, at 3:38 PM, Hauke Mehrtens  wrote:
> 
> Hi,
> 
> The OpenWrt community is proud to announce the fourth release candidate of 
> the upcoming OpenWrt 21.02 stable version series. It incorporates over 5800 
> commits since branching the previous OpenWrt 19.07 release and has been under 
> development for about one and a half year.
> 
> Changes between OpenWrt 21.02.0-rc3 and 21.02.0-rc4
> 
> Software updates
> * Linux kernel: updated to version 5.4.137 (from 5.4.124 in
>   v21.02.0-rc3)
> * mt76: Update to version 2021-06-06 (from 2021-05-15 in v21.02.0-rc3)
> * wireguard: Update with recent Linux stable fixes
> * exfat: Update to version 5.12.3 (from 5.10.1 in v21.02.0-rc3)
> 
> Misc changes
> * failsafe: Fixes failsafe network configuration with swconfig and DSA:
>   FS#3866
> * odhcpd: fix invalid DHCPv6 ADVERTSIE with small configured leasetime
> * ugps: parse $GPZDA and $GPGLL sentences, improve interoperability
>   with kplex
> * netifd: WDS with bridge-vlan fixed
> 
> Device support
> * New devices MikroTik RouterBOARD 912UAG-2HPnD and Joy-IT JT-OR750i
> * Device fixes for TP-Link CPE, MikroTik RouterBOARDs and
>   AVM FRITZRepeater 1200
> 
> Known issues
> * Some packets from IPv6 streams are getting dropped in software and
>   hardware flow offloading: FS#3373
> 
> 
> Full release notes and upgrade instructions are available at
> https://openwrt.org/releases/21.02/notes-21.02.0-rc4
> 
> In particular, make sure to read the regressions and known issues before 
> upgrading:
> https://openwrt.org/releases/21.02/notes-21.02.0-rc4#known_issues
> 
> For a detailed list of all changes since 21.02.0-rc3, refer to
> https://openwrt.org/releases/21.02/changelog-21.02.0-rc4
> 
> To download the 21.02.0-rc4 images, navigate to:
> https://downloads.openwrt.org/releases/21.02.0-rc4/
> 
> - ---
> 
> To stay informed of new OpenWrt releases and security advisories, there
> are new channels available:
> 
> * a low-volume mailing list for important announcements:
>  https://lists.openwrt.org/mailman/listinfo/openwrt-announce
> 
> * a dedicated "announcements" section in the forum:
>  https://forum.openwrt.org/c/announcements/14
> 
> * other announcement channels (such as RSS feeds) might be added in the
>  future, they will be listed at https://openwrt.org/contact
> 
> 
> As always, a big thank you goes to all our active package maintainers, 
> testers, documenters, and supporters.
> 
> Have fun!
> 
> The OpenWrt Community
> 
> ___
> 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 21.02 status - DSA documentation status

[Rich Brown]

Folks,

I made a start at documentation for the DSA networking in 21.02. I now realize 
that I have neither the knowledge necessary to write good docs, nor will I have 
the time to organize this work.

Consequently, I have to step back from the following pages:

Upgrading to OpenWrt 21.02.0: https://openwrt.org/playground/richb/to2102

DSA Mini-Tutorial: https://openwrt.org/playground/richb/dsa-mini-tutorial

Converting to DSA: https://openwrt.org/playground/richb/converting-to-dsa

I've already had some help from Arınç ÜNAL (and from Rafał Miłecki's early 
draft), but I would hope a small team could come together to get this 
information together before we release 21.02. Thanks.

Rich

> On Jul 17, 2021, at 5:04 PM, Rich Brown  wrote:
> 
> Hauke and all,
> 
> Thanks for the hard work to corral all those outstanding bug reports.
> 
> As we move forward, I want to be sure the documentation side is as good as 
> the software... I have these comments/questions:
> 
> 1) I created a new "Upgrading to OpenWrt 21.02.0" page at:
> https://openwrt.org/playground/richb/to2102 I distilled the announcement page 
> (https://openwrt.org/releases/21.02/notes-21.02.0) to make this checklist for 
> people that won't read that entire page.
> 
> Did I get the new page right? Please feel free to edit and make it correct.
> 
> 2) I was pretty fuzzy about what people should do if their target did migrate 
> to DSA. Do we have a guide to help those people through the transition?
> 
> 3) Is there any OpenWrt document that describes how DSA affects the files in 
> /etc/config and how it affects LuCI? Do we need to worry that a bunch of 
> people will glibly upgrade, then be knocked off the air?
> 
> As always, I really appreciate all the effort that goes into OpenWrt.
> 
> Best,
> 
> Rich
> 
>> On Jul 17, 2021, at 11:45 AM, Hauke Mehrtens  wrote:
>> 
>> Hi,
>> 
>> In general the 21.02-rc3 looks good, but we still have some problems.
>> 
>> Currently we still have these problem:
>> 
>> - IPv6 broken with flow offloading (according to reports, potentially 
>> related to hw flow offloading)
>> - PPPoE allegedly broken (according to reports, not fully reproducible, 
>> likely related to hw flow offloading too)
>> - https://bugs.openwrt.org/index.php?do=details_id=3909
>> - https://bugs.openwrt.org/index.php?do=details_id=3835
>> - 
>> https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552
>> - DHCPv6 broken if lease times < 12h chosen
>> - 
>> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137
>> - 
>> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162
>> - WDS with bridge-vlan broken (missing backport from master)
>> - cron jobs are triggered in UTC even when the system uses a different time 
>> zone:
>> - 
>> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/184
>> 
>> Thank you Jo for collecting most of them.
>> These problems should at least get some investigation and better should get 
>> fixed before the final release.
>> 
>> In addition there are multiple problems with specific device, if they get 
>> fixed it would be nice otherwise we just leave it like it is now.
>> 
>> The problem fixed here was also reported in 21.02:
>> https://git.openwrt.org/ba5bd8e556b2e7573d27b16e005ba287e066f795
>> @Kevin: Any objections to backport this change to 21.02? Are there any other 
>> changes needed?
>> 
>> @John: Did you look into the IPv6 Flow offloading problem?
>> 
>> I would like to get some of them fixed or at least investigated and then do 
>> the final or a rc4, depending of the number of changes.
>> I will try to find some time in the next days to investigate some of these 
>> problems.
>> 
>> 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

Supporting DSA on the OpenWrt Forum

[Rich Brown]

As I learn more about DSA, I want to make two requests to help out people who 
support OpenWrt on the forums. 

For the next several years, a question of the form, "I just upgraded my router 
from X to Y, and the networking stopped working...", will mean we have to 
figure out if this could be a swconfig -> DSA conversion problem.

To simplify our lives, I have two requests:

1) The firmware should display an unambiguous indicator about DSA. Since the 
firmware "knows" whether it's present or not, it can put that information in a 
known place. My suggestion: Put "DSA" at the end of the "build string" (I'm not 
sure of the correct name), like this:

At end of LuCI string: Powered by LuCI openwrt-21.02 branch 
(git-21.163.64918-ba57ec5) / OpenWrt 21.02.0-rc3 r16172-2aba3e9784 DSA
At end of ssh banner string: OpenWrt 21.02.0-rc3, r16172-2aba3e9784 DSA 

I am open to other options: my only request is that I can explain to newcomers 
how to get the information with a single sentence. (Forgive me if a DSA 
indicator is already present, but I have not seen one to date.)

2) It would be good to add a field about DSA to the TOH. I would name it "DSA 
Supported Since". Legal values would be "-" (not supported), "21.02-rc1", 
"23.07", etc. This gives an indication about DSA when upgrading, and forum 
supporters can look up the device to get a hint of whether DSA might be 
involved.

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

Re: OpenWrt 21.02 status

[Rich Brown]

Hi Arınç 

> On Jul 20, 2021, at 12:23 AM, Arınç ÜNAL  wrote:
> 
> I believe I could try to make one, I have a pretty good understanding
> of swconfig and DSA configuration. If someone can help me out with
> writing the script, I believe we can pull it off as a team effort.

I am in need of expertise in DSA & swconfig. Specifically, the draft DSA 
Mini-Tutorial (at https://openwrt.org/playground/richb/dsa-mini-tutorial) has a 
sentence that begins:

> If you are upgrading your OpenWrt device to 21.02 or later, you should read …

but there's only a placeholder article now.

Would you be able to start an outline for the "converting to DSA" page? We can 
all collaborate on it to flesh it out. Thanks.

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

OpenWrt DSA Mini-Tutorial

[Rich Brown]

I have updated the DSA Mini-tutorial in the playground: 
https://openwrt.org/playground/richb/dsa-mini-tutorial

I finished the first section ("Bridging all LAN ports"), and I am going to stop 
editing now, because:

1) I need someone else to look at the overall format of the document
2) I made some bold assertions and simplifications of the language in the 
document. But because I don't really understand DSA, I may be totally wrong...
3) If it's not right, we won't have to patch up the remainder, that is 
substantially unchanged from the Forum post.

Please check it out and either change it, or let me know what needs to be 
fixed. Thanks.

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

Re: OpenWrt 21.02 status

[Rich Brown]

>> 1) I created a new "Upgrading to OpenWrt 21.02.0" page at:   
>> https://openwrt.org/playground/richb/to2102 I distilled the announcement 
>> page (https://openwrt.org/releases/21.02/notes-21.02.0) to make this 
>> checklist for people that won't read that entire page.
>> Did I get the new page right? Please feel free to edit and make it correct.
> 
> Yes looks good, we should probably integrate this somehow in the release 
> notes, so that people do not have to read everything.

Thanks. I hasten to point out that I was just guessing / making stuff up in 
places. Please check every word, VERY CAREFULLY. (Remember, some readers will 
study it line by line. If it's not totally correct, they're going to do the 
wrong thing...)

https://openwrt.org/playground/richb/to2102 

>> 2) I was pretty fuzzy about what people should do if their target did 
>> migrate to DSA. Do we have a guide to help those people through the 
>> transition?
> 
> We do not support a migration and people have to start with a new fresh 
> installation. Doing a backup and restoring some settings manually works.

Then I think this is a big deal for people with interesting network 
configurations (maybe for everyone except those with a vanilla bridged LAN?) If 
they just install, I suspect they're going to be off the air, and we'll receive 
continuing "21.02 broke my router" complaints. Is this something we can detect 
automatically? 

In any event, we need to have good documentation about:
- Whether or not you need to worry - either by examining LuCi or by 
examining /etc/config/network
- How you make the transition from swconfig to DSA
- How you recover if you made the switch and now want to get back to 
the same configuration

>> 3) Is there any OpenWrt document that describes how DSA affects the files in 
>> /etc/config and how it affects LuCI? Do we need to worry that a bunch of 
>> people will glibly upgrade, then be knocked off the air?
> 
> Rafał created this forum post:
> https://forum.openwrt.org/t/mini-tutorial-for-dsa-network-config/96998
> 
> It would be nice if someone could create a wiki page based on this.

Maybe something like this? 
https://openwrt.org/playground/richb/dsa-mini-tutorial

It would be really great if Rafał (and others) could review the words on this 
page ASAP to make sure that a) I copy/pasted it correctly, and b) that the text 
is still correct.

Thanks.

Rich



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

Re: OpenWrt 21.02 status

[Rich Brown]

Hauke and all,

Thanks for the hard work to corral all those outstanding bug reports.

As we move forward, I want to be sure the documentation side is as good as the 
software... I have these comments/questions:

1) I created a new "Upgrading to OpenWrt 21.02.0" page at:  
https://openwrt.org/playground/richb/to2102 I distilled the announcement page 
(https://openwrt.org/releases/21.02/notes-21.02.0) to make this checklist for 
people that won't read that entire page.

Did I get the new page right? Please feel free to edit and make it correct.

2) I was pretty fuzzy about what people should do if their target did migrate 
to DSA. Do we have a guide to help those people through the transition?

3) Is there any OpenWrt document that describes how DSA affects the files in 
/etc/config and how it affects LuCI? Do we need to worry that a bunch of people 
will glibly upgrade, then be knocked off the air?

As always, I really appreciate all the effort that goes into OpenWrt.

Best,

Rich

> On Jul 17, 2021, at 11:45 AM, Hauke Mehrtens  wrote:
> 
> Hi,
> 
> In general the 21.02-rc3 looks good, but we still have some problems.
> 
> Currently we still have these problem:
> 
> - IPv6 broken with flow offloading (according to reports, potentially related 
> to hw flow offloading)
> - PPPoE allegedly broken (according to reports, not fully reproducible, 
> likely related to hw flow offloading too)
>  - https://bugs.openwrt.org/index.php?do=details_id=3909
>  - https://bugs.openwrt.org/index.php?do=details_id=3835
>  - 
> https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552
> - DHCPv6 broken if lease times < 12h chosen
>  - 
> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137
>  - 
> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162
> - WDS with bridge-vlan broken (missing backport from master)
> - cron jobs are triggered in UTC even when the system uses a different time 
> zone:
>  - 
> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/184
> 
> Thank you Jo for collecting most of them.
> These problems should at least get some investigation and better should get 
> fixed before the final release.
> 
> In addition there are multiple problems with specific device, if they get 
> fixed it would be nice otherwise we just leave it like it is now.
> 
> The problem fixed here was also reported in 21.02:
> https://git.openwrt.org/ba5bd8e556b2e7573d27b16e005ba287e066f795
> @Kevin: Any objections to backport this change to 21.02? Are there any other 
> changes needed?
> 
> @John: Did you look into the IPv6 Flow offloading problem?
> 
> I would like to get some of them fixed or at least investigated and then do 
> the final or a rc4, depending of the number of changes.
> I will try to find some time in the next days to investigate some of these 
> problems.
> 
> 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 developer / paid work

[Rich Brown]

I respectfully ask the participants in this conversation to take it off-line 
from the OpenWrt Developer list. Thank you.

Rich Brown



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

Re: [PATCH] Fix tx-queue-size on NBG6817 (allows MTU changes).

[Rich Brown]

> On Sep 21, 2020, at 8:02 PM, Jacek Milewicz  wrote:
> 
> 
> 
> On 22/09/2020 00:06, Ansuel Smith wrote:
>>> 
>>> 
>>> On 19/09/2020 15:06, Paul Oranje wrote:
 See below, regards,
 Paul
 
 
> Op 15 sep. 2020, om 21:56 heeft jacekow...@jacekowski.org het volgende 
> geschreven:
 The subject does not to comply with the rules for that, it should at least 
 start with the target, better would be:
   ipq806x: fix tx-queue-size on NBG6817
>>> 
>>> I was not aware of that.
>>> 
> From: Jacek Milewicz 
> 
> Fixes FS#3285 for NBG6817 only.
 Why is that ?
>>> 
>>> Because on IPQ806x SoC it is impossible to detect correct value,
>>> therefore it has to be set for each device in device tree (which is what
>>> this patch is doing).
>>> 
>>> On most IPQ806x devices correct value has to be determined manually by
>>> trying few most common values and seeing what works (4k seems to be most
>>> common).
>>> 
>> Can I ask you how you found out and how to check if a bad value is set?
>> Is this set by default on the OEM firmware? Any test or something?
> 
> OEM firmware runs older kernel that does not check for tx-fifo-depth at all 
> (https://patchwork.kernel.org/patch/11283121/ - this patch, dated December 
> 2019 added the check). There is only few values that the driver will accept 
> (256,512,1k,2k,4,8k,16k), so the easiest way to check is set it to highest 
> (16k) and then try increasingly higher MTU to check at what point does it 
> start dropping packets or crashing (and it seems like 4k is fairly common 
> value on this SoC).

This all sounds like valuable, hard-won information that deserves to be 
documented in the code.

> ___
> 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: [RFC] self-signed certificates for LuCI

[Rich Brown]

Besides the "project management" concerns expressed in my earlier note, I also 
share Karl Palsson's worries...

> On Sep 1, 2020, at 9:04 AM, Karl Palsson  wrote:
> 
> With this change, the very first thing users see is a browser
> warning telling the user very very very bad things about what
> they would have to do to continue, and we are simply going to
> train users to "just click through the warnings" I see that as a
> serious step backwards for security and society as a whole.

I see the last sentence as the most important one. Training people to, "Just 
click through..." without an ounce of preparation (making them check a 
box/install a cert/etc.) is BAD. 

Sorry for the apolyptic language. But we can hold this off 'til after we 
release 20.0x to be sure we have all our ducks in a row. Thanks for listening.

Rich



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

Re: [PATCH] uhttpd: Increase default certificate validate from 2 to 10 years

[Rich Brown]

Forgive me for chiming in now, for I have not been following the discussion 
closely.

Is this change (specifically, using these certs for "ordinary operation" of 
OpenWrt) being considered for the 20.0x release? Would it delay the RC1 release 
in any way?

If so, I believe we should move it off that critical path, since there's a lot 
of uncertainty here. (We already have plenty in 20.0x - I worry that adding 
more tasks/features will push us to 20.1x, or worse.)  If it's not included in 
20.0x, we can definitely continue the experiments in snapshot to see whether 
its benefits are worth the difficulties. Thanks for listening.

Rich

> On Sep 1, 2020, at 9:57 AM, Karl Palsson  wrote:
> 
> 
> Yousong Zhou  wrote:
>> It's worth mentioning that recent versions of macos since 10.15
>> have a restriction on certificate validity period, self-signed
>> or not. It's a strong restriction that the browser ui will have
>> no buttons or knobs to bypass the certificate validation,
>> rendering such sites inaccessible. I remembered it's also a
>> system wide enforcement that chrome on macos also respects
>> this.
>> 
>> [1] Requirements for trusted certificates in iOS 13 and macOS
>> 10.15, https://support.apple.com/en-us/HT210176
>> 
>>> TLS server certificates must have a validity period of 825 days or fewer 
>>> (as expressed in the NotBefore and NotAfter fields of the certificate).
>> 
>> [2] About upcoming limits on trusted certificates,
>> https://support.apple.com/en-us/HT211025
>> 
>>> TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC 
>>> must not have a validity period greater than 398 days.
>> 
> 
> Are they blocking or planning to block non-http sites? This would
> be further arguments that self-signed certs by default for luci
> are actively bad.
> 
> Latest reference I can find for chromium is that HTTP will be
> marked as insecure, but not with the click through horror show of
> self signed certs.
> 
> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
> 
> Sincerely,
> Karl Palsson___
> 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: image size on 20.xx builds -- what about a new SMALL target

[Rich Brown]

I'm cc'ing the OpenWrt-Adm list on this as well, because I smell a policy 
decision looming. Some thoughts:

1) In my opinion, we should not aim for a third (Tiny/Small/Normal) build for 
20.xx. We don't need any more hurdles to overcome before we ship an RC1 version.

2) I had not understood how "close to the wire" we are with 8MByte machines. 
(That is, vendors reserving 1.5MBytes+ for their own purposes, leaving us with 
a max of 6.5Mbytes...)

3) Instead of creating an entire new "Small" build, with its attendant new 
directories, enormous load on the build infrastructure, etc., I wonder if we 
should spend the engineering time improving the chef.libremesh.org ImageBuilder 
facility. This has the following good attributes:
- People can build an image of whatever size they want, to their own 
specifications
- It gives us information about the popularity of various devices, and 
their common configurations
- We would no longer need to guess what features to put into the 
"default" stable release
- I also envision an enhancement to chef.libremesh.org that lets you 
preview the size of already-built images that contain the packages you have 
specified. This dramatically helps with caching, and makes the user experience 
vastly better as well. Someone can either wait a long time while their image 
builds, or they can just download one that's pre-built, potentially with a few 
extra packages.

Thoughts? Thanks.

Rich

> On Aug 3, 2020, at 8:40 AM, Henrique de Moraes Holschuh  
> wrote:
> 
> On 02/08/2020 19:11, Daniel Golle wrote:
>> On Sun, Aug 02, 2020 at 11:49:54PM +0200, Bjoern Franke wrote:
>>> Hi,
>>> 
 
 Your Filesystem has a size of 5.81M. MT7620 has a kernel size of around 
 2M, which exceeds the available space on flash.
>>> 
>>> On 19.07.3, the listed lineup of packages has 5.54M and it fits:
>>> 
>>> Exportable Squashfs 4.0 filesystem, xz compressed, data block size 262144
>>> compressed data, compressed metadata, compressed fragments,
>>> no xattrs, compressed ids
>>> duplicates are removed
>>> Filesystem size 5674.78 Kbytes (5.54 Mbytes)
>>> 35.35% of uncompressed filesystem size (16051.56 Kbytes)
>>> Inode table size 13736 bytes (13.41 Kbytes)
>>> 22.46% of uncompressed inode table size (61170 bytes)
>>> Directory table size 17662 bytes (17.25 Kbytes)
>>> 44.53% of uncompressed directory table size (39661 bytes)
>>> 
>>> 
>>> 
 You can try to remove other packages (such as ppp) from the image. 
 Stripping LuCI should also save a lot of space, given you only
 need it for the initial installation.
 
>>> 
>>> Yes, but I was wondering why the image gets 300Kb bigger on 20.xx.
>> Apart from the usual kernel growth we have also enabled a bunch of
>> previously disabled kernel features on targets which are not marked
>> as SMALL_FLASH[1]. MT7620 is a mixed bag in that regard and it would
>> make sense to split it similar to ath79 into a 'tiny' and a 'generic'
>> variant. The 'mt7620-generic' variant could then also ship with NAND
>> support and support for Xiami miRouter 3. The 'mt7620-tiny' variant
>> would have SMALL_FLASH set and hence come without the features
>> enabled in [1] which should give us ~ 200kB.
>> [1]: 
>> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fcb41decf6c622482b20af45a77e62db8d95046e
> 
> This sort of commit can easily be a problem even for 8MiB FLASH devices.
> 
> (Some?) vendors are adding a lot of cruft we can't simply jettison from 
> FLASH, e.g. the dual-bootloaders and "http recovery" stuff on TP-Link Archer 
> C60v3 and later, and I understand, several other of their models.
> 
> That effectively reduces usable FLASH enough to matter on 8MiB devices. It is 
> already a problem on OpenWrt 19.07 -- for anything that needs FLASH-filling 
> monsters like OpenSSL and ca-certificates, at least.
> 
> IMO, if things keep going that way (and there is no reason to believe they 
> would not -- or should not, for that matter), we would truly benefit from a 
> SMALL variant soon (not just TINY).  And by soon, I do mean OpenWrt 20.x if 
> at all possible :-(
> 
> Note that I AM NOT speaking against changes that end up increasing core 
> openwrt size.  I am just stating that such changes show the need of one or 
> two knobs for anything that is not possible to build as a "module" 
> kernel-side or as an optional package *and* isn't something you'd strictly 
> need on smaller devices.
> 
> There's TINY, but it removes too much -- being the single true/false knob 
> that exists ATM -- and it seems to be really set up for devices with 
> something like 3-5MiB usable FLASH.  It is also too useful to drop/repurpose, 
> so I am *not* suggesting that.
> 
> A new SMALL could target 5.5MiB to ~6.5MiB *usable* FLASH, IMHO.  One would 
> look at everything that is !TINY to see if it should also be !SMALL, and 
> review for !SMALL what already landed that increases the static kernel size 
> and 

Re: Restoring (old) config backups and

[Rich Brown]

>> On Aug 1, 2020, at 10:05 AM, Paul Oranje  wrote:
>> 
>>> Actually, my solution implements the config "on device" as a uci parameter, 
>>> so the "on device" version is actually not the version of the firmware 
>>> installed, but of the config installed. Therefore, one may indeed go that 
>>> road to prevent flashing an incompatible backup. However, I don't think you 
>>> can use it for much else.
>>> 
>>> Despite, I still have received no positive feedback about that change at 
>>> all, so I'm not sure whether it will go in at all.
>> Good reason to chime in. That proposal for compatibility checks seemed very 
>> well thought over and as such I would welcome its implementation.
>> Bye,
>> Paul

I seem to have lost the thread on this. Is there documentation on this 
proposal? (I will note that I, too am in favor of restoring prior configs.)

Extra credit if there were a way to restore the previous set of installed 
packages. (Or should we change our way of thinking, and simply recommend Moritz 
Warning's Firmware Selector from now on?)

Many thanks!

Rich



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

Re: [OpenWrt-Devel] RFC: versions.json

[Rich Brown]

Thanks for all these good ideas. A summary of my thoughts:

- Use of JSON. Not really risky - there'll be JSON parsers for the foreseeable 
future. And sticking in a version field makes it possible to evolve. My primary 
concern is that we use a SINGLE straightforward format and create tooling that 
writes in that format. (I wouldn't want to have multiple programs that attempt 
to make sense of the directory structure of downloads.openwrt.org...)

- Backporting to 18.x. I am agnostic here. 

- There are several tricky issues regarding upgrade policies. I am fairly 
certain the JSON file should encode the possible version numbers. I am agnostic 
on the policies - I almost always install Stable releases, so I don't know the 
pitfalls. Does the JSON file also need to incorporate upgrade policies as well? 
For example,
- Whether to offer to upgrade to xx.yy.z+1, or xx.yy+1.0?
- Whether to offer to upgrade to xx.yy.z+n, skipping interim (possibly 
crashing) releases?
- etc...

- The JSON file should definitely contain a URL to "about this upgrade" and 
perhaps also a changelog, etc.

- If a flawless upgrade experience required a more capable device, I am 
personally willing to give up on 4/32 devices (and maybe even 8/64 devices - 
although I'm sure I'll hear about their popularity) 

- I like the idea of the progressive rollout, where a small number of devices 
get randomly selected to test new stable versions at the outset. This limits 
the damage and heartache from a bum update. After we get confidence in a 
particular release, we can open the floodgates.

- I like the idea of a callback that says "I got home safely, Mom". If there's 
a significant divergence between the number of auto-upgrade downloads and the 
successful upgrade messages, we can investigate/halt the upgrade process.

- re: performing the upgrade check on login. That check should never 
hinder/hang the login. That said, a person's attention to the router is still a 
good trigger for queueing a process to make the check. (Weekly/daily checks are 
fine, but it would be annoying if it checked seconds after I log in, and I 
never heard about it 'til the next time I looked...)

- And finally: what changes to the initial "pseudo-wiki-page" (below) would be 
necessary from what we've decided so far? Thanks.

Rich


== OpenWrt Automatic Upgrades ==

OpenWrt can check for newer versions of its firmware and offer to upgrade 
automatically. These automatic upgrades restore the router to substantially the 
same state, except running newer firmware. In particular, the upgrade process 
preserves both the settings (implementing the "Keeps settings..." checkbox) and 
the hand-installed packages that aren't part of the standard image.

When this features is enabled, every LuCI web login or SSH login triggers a 
version check. If upgrades are available, the firmware displays a notice 
specifying the various options, with a link to a page that gives information 
about that particular upgrade, and the steps for applying that upgrade. 

When "Upgrade" is initiated, the router downloads the new image along with all 
necessary packages. After all files have been retrieved successfully, a final 
human confirmation begins the upgrade process.

The web GUI indicates that the upgrade process has started, and periodically 
attempts to make connections back to the login page. The SSH interface gives a 
"Initiating upgrade to " message before severing the SSH connection.


> On Mar 2, 2020, at 5:43 AM, Paul Spooren  wrote:
> 
> Hi,
> 
 A first step could be to establish a *versions.json* file at the root of
 downloads.openwrt.org! The file would allow to check if a device still runs
 the latest release. JSON seems common enough and is well supported by LuCIs
 JavaScript implementation and also via jshn.sh on a CLI/script level.
>>> I'm wondering whether this JSON is really needed, wouldn't just some kind of
>>> unified symlink/directory structure would work as well? I mean, why to care
>>> about another JSON file content if the same could be achieved otherwise.
>> It's true that the actual representation (symlink/directory structure, JSON 
>> file, a massive text file listing every release, etc) doesn't matter. In 
>> some way, they're all "convertible" to the other forms.
>> 
>> But we are creating an API here. People want to write software against that 
>> API, knowing they never will have to tweak their software because a new 
>> version or important branch, etc arises.
>> 
>> What matters is that OpenWrt pick ONE FORMAT to be the canonical 
>> representation of this information, and that our build system automatically 
>> create data IN THAT ONE FORMAT as a matter of course, so that everyone can 
>> rely on it for their needs.
> It's might be a risky bet, but I could imagine JSON is around for the next 
> years to come. It's also easier extendable than other formats using dicts. 
> Something like `metadata_version: 1` 

Re: [OpenWrt-Devel] RFC: versions.json

[Rich Brown]

>> A first step could be to establish a *versions.json* file at the root of
>> downloads.openwrt.org! The file would allow to check if a device still runs
>> the latest release. JSON seems common enough and is well supported by LuCIs
>> JavaScript implementation and also via jshn.sh on a CLI/script level.
> 
> I'm wondering whether this JSON is really needed, wouldn't just some kind of
> unified symlink/directory structure would work as well? I mean, why to care
> about another JSON file content if the same could be achieved otherwise.

It's true that the actual representation (symlink/directory structure, JSON 
file, a massive text file listing every release, etc) doesn't matter. In some 
way, they're all "convertible" to the other forms. 

But we are creating an API here. People want to write software against that 
API, knowing they never will have to tweak their software because a new version 
or important branch, etc arises.

What matters is that OpenWrt pick ONE FORMAT to be the canonical representation 
of this information, and that our build system automatically create data IN 
THAT ONE FORMAT as a matter of course, so that everyone can rely on it for 
their needs. 

> Do we need to care about archive releases?

Older versions of the firmware (pre-20.xx) won't know how to interpret the API 
data, so we don't need to cater to those older images. However, in the future 
when Stable is 23.07.2, and you encounter a 20.07.1 machine, you'd like to it 
to show you the upgrade options based in its image.

Do the choices below cover the waterfront for a complete set of useful names? 
(Let's assume that 19.07.2 has been released, and that there are two RCx 
builds: 19.07.3-rc1 and 20.07.0-rc2...)


> snapshot  -> snapshot
> release/candidate -> 20.07.0-rc2
release/candidate -> 19.07.3-rc1
> release/current   -> 19.07.2
release/previous -> 19.07.1
> release/previous  -> 18.06.7
release/previous -> 18.06.6
...
release/previous -> 18.06.0
release/endoflife -> 17.01.6
...
release/endoflife -> 17.01.0
release/endoflife -> 15.05.
release/endoflife -> 14.07
...
release/endoflife -> 0.9 (all the way back to White Russian...)

>> Update check script should look for the closest version found in the same
>> channel. So a *stable* 19.12.3 device updates to 19.12.5 
> 
> Wouldn't it be safer to upgrade first to 19.12.4? :-)

This is an interesting and important question, but it's orthogonal to the 
question of an API that represents the variety of builds that are available.

Thanks.

- Rich

>> This could also introduce channels like "stable" (latest point release),
>> "testing" (rcN) and "unstable" (snapshots). As a dict is used the *versions*
>> array could be extended without losing compatibility.
> 
> Déjà vu[1]? :-) 
> 
> 1. http://lists.infradead.org/pipermail/openwrt-devel/2019-August/018646.html
> 
> -- ynezz
> 
> ___
> openwrt-adm mailing list
> openwrt-...@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-adm


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

Re: [OpenWrt-Devel] New OpenWrt logo proposal [Was: Re: [RFC]new "corporate identity" for OpenWrt & static rendering]

[Rich Brown]

In hopes of guiding this conversation toward the forum, I reposted Nishant 
Sharma's comment there... 
https://forum.openwrt.org/t/help-pre-select-new-openwrt-project-logo-in-the-poll/52674/9

> On Jan 15, 2020, at 12:00 AM, Nishant Sharma  wrote:
> 
> Hi Petr,
> 
> On 14/01/20 4:57 PM, Petr Štetiar wrote:
>> Petr Štetiar  [2020-01-08 22:47:28]:
>> 
>> 1. 
>> https://forum.openwrt.org/t/help-pre-select-new-openwrt-project-logo-in-the-poll/52674
> 
> All of them are nice and I have voted for the one I liked. I have a
> thought here.
> 
> As far as I see and use, OpenWrt doesn't stand just for wireless
> freedom, though that's the most popular use case. It is being used as a
> base for various functions related but not limited to meshing, routing,
> network security, IoT and anything or everything that one can imagine or
> implement with additional packages. It gives us such a "freedom" and
> helps us protect our "privacy".
> 
> The logo "H" represents the versatility, but misses the wireless.
> 
> Regards,
> Nishant
> 
> ___
> openwrt-adm mailing list
> openwrt-...@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-adm


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

[OpenWrt-Devel] Congratulations on 19.07-rc1

[Rich Brown]

I saw an notice for an update to the OpenWrt wiki:

Announcement for 19.07-rc1: https://openwrt.org/releases/start
Release Notes: https://openwrt.org/releases/19.07/notes-19.07.0-rc1

Thanks to all who helped to move us off top-dead-center.

Rich

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

Re: [OpenWrt-Devel] Did they check security of OpenWrt?

[Rich Brown]

> On Aug 20, 2019, at 5:32 PM, Rosen Penev  wrote:
>> Can anyone speak to whether OpenWrt builds use any/all of those techniques 
>> called out to provide additional security? OpenWrt's modern kernel provides 
>> a bunch of security. That may be good enough, even if builds don't use all 
>> those techniques. And if we have implemented them, we can further 
>> differentiate ourselves from vendor firmware...Thanks.
> OpenWrt uses several flags like -fstack-protector and format
> hardening...

Excellent! That covers a couple of the flags listed below. Can we say anything 
about any of the other tests?

> ... Issues are more nuanced than this though. These same people
> several months ago mentioned a serious ASLR weakness with MIPS.
> Patches went in the kernel for it.

Does this mean that snapshot builds (with current kernels) now protect against 
that MIPS vulnerability? What about the stable builds?

> There are probably more issues like
> those for different platforms.

> At the end of the day, most people use x86 and ARM. That's where most
> of the eyes are.

There are a lot of experts on various architectures on this list. Can they 
speak to other issues?

Late entry: I was going to volunteer to start a wiki page for this information, 
but I started to read the Security page 
(https://openwrt.org/docs/guide-developer/security 
#os_and_package_hardening) 
and see that it speaks directly to these issues:

- the checksec.sh script seems to look for the flags mentioned below
- there's a list of build-hardening options for the compiler
- and more... 

What statements/assertions can we make about whether these are used to create 
release or snapshot builds? Thanks to all who can contribute info.

Rich

 My questions were more about OpenWrt. How would our current builds stack 
 up under the criteria used in the report's table? It listed:
 
 - Stack Guards
 - ASLR
 - RELRO
 - Fortify SRC
 - Non-Exec Stack
 
 And are there other security practices that we enforce that would make an 
 OpenWrt system more secure?

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

Re: [OpenWrt-Devel] Did they check security of OpenWrt?

[Rich Brown]

Dmitry,

> On Aug 20, 2019, at 11:58 AM, Dmitry Tunin  wrote:
> 
> Rich,
> 
> OpenWrt is a Linux distro. It has all security as any other one. All
> CVE are timely addressed.
> There is no need for special tests.

Yes, but... Virtually all the other vendor's firmware are "Linux distro's" as 
well. And if I understand the CITL scan process, it shows lots of bad build 
practices in the vendor firmware source code.

Can anyone speak to whether OpenWrt builds use any/all of those techniques 
called out to provide additional security? OpenWrt's modern kernel provides a 
bunch of security. That may be good enough, even if builds don't use all those 
techniques. And if we have implemented them, we can further differentiate 
ourselves from vendor firmware...Thanks.

Rich


> вт, 20 авг. 2019 г. в 18:34, Rich Brown :
>> 
>> Hi Vincent,
>> 
>> I don't know whether the article, or its underlying report from Cyber 
>> Independent Testing Lab - CITL, is a joke or not. (Although, I'll agree that 
>> any firmware using 18-year old kernels is on its face a security joke.)
>> 
>> My questions were more about OpenWrt. How would our current builds stack up 
>> under the criteria used in the report's table? It listed:
>> 
>> - Stack Guards
>> - ASLR
>> - RELRO
>> - Fortify SRC
>> - Non-Exec Stack
>> 
>> And are there other security practices that we enforce that would make an 
>> OpenWrt system more secure?
>> 
>> If OpenWrt compares favorably, it occurs to me that we could invite CITL to 
>> review OpenWrt builds (on hundreds of routers) and update their report...
>> 
>> Thanks.
>> 
>> Rich
>> 
>>> On Aug 20, 2019, at 9:43 AM, Vincent Wiemann  
>>> wrote:
>>> 
>>> Hi Rich,
>>> 
>>> the article is a joke. I'm not talking about the researchers, but about 
>>> citing a statement like:
>>> „However, those same firmware binaries did not employ other common security
>>> features like ASLR or stack guards, or did so only rarely,“
>>> 
>>> Look at the source-code of the mentioned vendors. They partially use 18 
>>> years old kernel code and
>>> Telnet-like management interfaces.
>>> 
>>> Regards,
>>> 
>>> Vincent
>>> 
>>> 
>>> On 20.08.19 13:21, Rich Brown wrote:
>>>> Hi folks,
>>>> 
>>>> You've probably seen the Slashdot article about (lack of) security gains 
>>>> in router firmware. 
>>>> https://yro.slashdot.org/story/19/08/16/2050219/huge-survey-of-firmware-finds-no-security-gains-in-15-years
>>>>  The original article on Security Ledger is at: 
>>>> https://securityledger.com/2019/08/huge-survey-of-firmware-finds-no-security-gains-in-15-years/
>>>> 
>>>> Two questions:
>>>> 
>>>> 1) Does anyone know if the researchers looked at OpenWrt?
>>>> 
>>>> 2) If not, how would OpenWrt stable or snapshot have fared in the 
>>>> analysis? Do we enable stack guards, ASLR, etc. on all builds?
>>>> 
>>>> Thanks.
>>>> 
>>>> Rich
>>>> ___
>>>> 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] Did they check security of OpenWrt?

[Rich Brown]

Hi Vincent,

I don't know whether the article, or its underlying report from Cyber 
Independent Testing Lab - CITL, is a joke or not. (Although, I'll agree that 
any firmware using 18-year old kernels is on its face a security joke.)

My questions were more about OpenWrt. How would our current builds stack up 
under the criteria used in the report's table? It listed:

- Stack Guards
- ASLR
- RELRO
- Fortify SRC
- Non-Exec Stack

And are there other security practices that we enforce that would make an 
OpenWrt system more secure?

If OpenWrt compares favorably, it occurs to me that we could invite CITL to 
review OpenWrt builds (on hundreds of routers) and update their report...

Thanks.

Rich

> On Aug 20, 2019, at 9:43 AM, Vincent Wiemann  
> wrote:
> 
> Hi Rich,
> 
> the article is a joke. I'm not talking about the researchers, but about 
> citing a statement like:
> „However, those same firmware binaries did not employ other common security
> features like ASLR or stack guards, or did so only rarely,“
> 
> Look at the source-code of the mentioned vendors. They partially use 18 years 
> old kernel code and
> Telnet-like management interfaces.
> 
> Regards,
> 
> Vincent
> 
> 
> On 20.08.19 13:21, Rich Brown wrote:
>> Hi folks,
>> 
>> You've probably seen the Slashdot article about (lack of) security gains in 
>> router firmware. 
>> https://yro.slashdot.org/story/19/08/16/2050219/huge-survey-of-firmware-finds-no-security-gains-in-15-years
>>  The original article on Security Ledger is at: 
>> https://securityledger.com/2019/08/huge-survey-of-firmware-finds-no-security-gains-in-15-years/
>> 
>> Two questions:
>> 
>> 1) Does anyone know if the researchers looked at OpenWrt?
>> 
>> 2) If not, how would OpenWrt stable or snapshot have fared in the analysis? 
>> Do we enable stack guards, ASLR, etc. on all builds?
>> 
>> Thanks.
>> 
>> Rich
>> ___
>> 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] Did they check security of OpenWrt?

[Rich Brown]

Hi folks,

You've probably seen the Slashdot article about (lack of) security gains in 
router firmware. 
https://yro.slashdot.org/story/19/08/16/2050219/huge-survey-of-firmware-finds-no-security-gains-in-15-years
 The original article on Security Ledger is at: 
https://securityledger.com/2019/08/huge-survey-of-firmware-finds-no-security-gains-in-15-years/

Two questions:

1) Does anyone know if the researchers looked at OpenWrt?

2) If not, how would OpenWrt stable or snapshot have fared in the analysis? Do 
we enable stack guards, ASLR, etc. on all builds?

Thanks.

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

Re: [OpenWrt-Devel] Special features request!

[Rich Brown]

Hi,

Thanks for writing to us about OpenWrt. I think you misunderstand the right 
place to ask your questions. Please accept our advice for a good way to 
proceed. Here is how I understand your request:

1) You are looking to modify the base OpenWrt release. This seems to be an 
interesting set of features.

2) You do not presently have the technical skills (or enough time) to do this 
work yourself, so you are looking for someone to help.

3) Once you have a sense of how much work these tasks will require, you will 
crowd-fund the project.

The OpenWrt developer and admin lists (that you wrote to) are not the proper 
place to ask these questions. A better place to ask would be to post a note to 
the OpenWrt Forum (forum.openwrt.org <http://forum.openwrt.org/>) in the 
Developer category to see if there is interest from someone who would be 
willing to work with you to create an estimate and the desired software 
modifications.

Best regards,

Rich Brown

> On Jul 17, 2019, at 9:13 PM, SkullFace  wrote:
> 
> Hi
> 
> 
> I would like to ask openwrt team to add some special features that i need.
> 
> I will use crowd funding to collect the money!
> 
> 1-I need full control over Lantiq xDsl firmware using both GUI and CLI.
> 
> 2-I want to override Line Config enforced by DSLAM/DLM, [SNR, Power, 
> Interleaving, G.INP, BitSwap, Vectoring, Rate Adaptationetc].
> 
> 3-more advanced, stable and configurable VPN clients/Servers, Proxy 
> Client/Servers, Obfuscating Proxy clients/Servers.
> 
> 4-Advanced Luci Addons for CLI only packages.
> 
> 5-Stable per user bandwidth monitor and limiter.
> 
> 6-Per user speed limit/propriety.
> 
> 7-Support for other unsupported  xDsl Chips
> 
> 8-Support for the wide spead ISP routers.
> 
> So i wanted to publish a Patreon page to cover the costs, however i cant 
> complete and publish the page without knowing the money required to finish 
> these tasks and/or hire more programmers to help finish the tasks quicker.
> 
> How much money is required to accomplish the tasks 1-3?! and how much time is 
> needed?
> 
> Thanks
> 
> 
> 
> ___
> openwrt-adm mailing list
> openwrt-...@lists.openwrt.org
> http://lists.infradead.org/mailman/listinfo/openwrt-adm

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

Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches

[Rich Brown]

I was about to recommend the Download Stats page at 
https://downloads.openwrt.org/stats/ as a first cut...

> Would it be possible to get some download stats for release/snapshot images,
> so we can get some rough numbers about popularity of devices in the wild?

BUT... that page doesn't seem to be collecting any stats since 21 Nov 2018. 
OpenWrt Admin's are cc'd on this note.

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

Re: [OpenWrt-Devel] Not quite getting IPv6 tunnel to work

[Rich Brown]

I'm sorry that I didn't make my question clear. The script has all bogus
values (including the user id).

I *do* have the tunnel working - I can ping/traceroute v6 hosts from the
router.

I think there's a problem routing from a device on an interface through the
router. Any ideas what I should check next? Thanks.

Rich Brown
Hanover, NH USA


 Date: Thu, 24 May 2012 13:06:25 +0200
 From: Jo-Philipp Wich x...@subsignal.org
 To: OpenWrt Development List openwrt-devel@lists.openwrt.org
 Subject: Re: [OpenWrt-Devel] Not quite getting IPv6 tunnel to work
 Message-ID: 4fbe1631.4040...@subsignal.org
 Content-Type: text/plain; charset=ISO-8859-1

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Your username looks wrong. It is supposed to be the 32 byte md5 sum
 representing your user id, you can find it in your tunnelbroker.net
 profile page. tb4... for sure does *not* look like an md5 hash.

 ~ Jow

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

[OpenWrt-Devel] What is CeroWrt? (was: Not quite getting IPv6 tunnel to work)

[Rich Brown]

CeroWrt is a platform for experimenting with solutions to the problem,
Daddy, why is the Internet slow today? CeroWrt has implemented the new
CoDel (Controlling Delay) algorithm for fair queueing and reducing the
amount of data buffered by the router. From the Overview page at
http://www.bufferbloat.net/projects/cerowrt

---
CeroWrt is a project built on the OpenWrt firmware to resolve the endemic
problems of bufferbloat in home networking today, and to push forward the
state of the art of edge networks and routers. Projects include proper IPv6
support, tighter integration with DNSSEC, and most importantly, reducing
bufferbloat in both the wired and wireless components of the stack.
---

With CoDel (pronounced coddle), we're seeing good responsiveness of small
packet traffic through the CeroWrt routers even when doing heavy file
transfers. So you don't hose your gaming/VoIP traffic if somebody else
uploads or downloads files.

Dave Täht has done the lion's share of the work to get this going, and has
been actively pushing the changes back into the OpenWrt trunk so that
others can benefit from these changes. You can read more at:

Bufferbloat Overview: http://www.bufferbloat.net/
CeroWrt Wiki: http://www.bufferbloat.net/projects/cerowrt/wiki
CoDel article: http://queue.acm.org/detail.cfm?id=2209336

Best regards,

Rich Brown
Hanover, NH USA
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel