Re: OpenWrt 21.02.0 Fourth release candidate - DSA docs
Hi Perry. On 17/09/2021 15:27, Perry wrote: Hi all, On 9/17/21 1:30 PM, Rich Brown wrote: 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. This is not always the case. For example, it is possible to have a tun or tap interface which does not have a corresponding ip address. This is more than just a device, because layer 3 packets can arrive on such an interface. Another example, from Freifunk, are mesh (either Ad-Hoc or 802.11s) interfaces. These are interfaces which have a static IP address, but the netmask is 255.255.255.255. This is not a network in the sense most people are used to using, but still a completely valid configuration. This is a very good point. For example, I use WireGuard without any IP address used on the interface. Although you can assign more than one subnet (or none at all) on the interface, each entry under "config interface" still represents the communication between a group of devices that was divided from another group of devices communicating with each other, in other words, a network. I can configure DHCP, firewall or e.g. wireguard related options on it. Why do I create another "network" on OpenWrt? Maybe I want to separate my network from the guest network, maybe I need to create another network which uses PPPoE or DHCP for ISP communication, or I want to use WireGuard VPN, etc. That's why the "network" term fits in the best. Throughout LuCI, it can be seen that they're already called networks. - firewall - zone settings: "Covered networks" - wireless: Choose the network(s) you want to attach to this wireless interface I think staying with the terminology "device" and "interface" is the right way to go. Greets, Perry 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 ___ 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.0 Fourth release candidate - DSA docs
Hello Paul.
On 18/09/2021 15:36, Paul D wrote:
On 2021-09-17 13:27, Perry wrote:
Hi all,
On 9/17/21 1:30 PM, Rich Brown wrote:
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.
This is not always the case. For example, it is possible to have a tun
or tap interface which does not have a corresponding ip address. This
is more than just a device, because layer 3 packets can arrive on such
an interface.
Another example, from Freifunk, are mesh (either Ad-Hoc or 802.11s)
interfaces. These are interfaces which have a static IP address, but
the netmask is 255.255.255.255. This is not a network in the sense most
people are used to using, but still a completely valid configuration.
I think staying with the terminology "device" and "interface" is the
right way to go.
Greets,
Perry
Largely agree - device --> hardware device --> hwdev
interface ? GUI is an interface. NIC is an interface. This is
abstract. Trying to make it concrete is just confusing. Specify:
You're confusing the term "network interface" with others ("GUI
interface" in this case). The term "interface", when used in computer
networking, means that it's short for the term "network interface".
A Network Interface Card (NIC) is not a network interface by itself. The
software creates a network interface that uses the NIC to connect to a
network. Let's give swconfig & DSA as an example. A switch port is not a
network interface by itself. Here's how DSA & swconfig make use of the
switch ports;
- DSA would set up each switch port as a network interface. (wan, lan1,
lan2, etc.)
- swconfig on the other hand would rather set up a vlan network
interface to make use of the switch ports. (eth0.1, eth0.2, etc.)
When you run ip link, whether by Linux or Cisco's computer networking
terms, what you see on each entry is a network interface. Network
interfaces can be created by making use of physical devices (a NIC, a
wireless radio) and/or logical features of the software (vlan, tunnelling).
L3interface
L4interface
MLinterface (multi layer)
Bridge interface, wireless interface, 802.1q vlan interface, veth
interface, tunnel interface or the ones above... These are all called
network interfaces in the most generic form.
Throughout LuCI, it can be seen that they're already called interfaces.
- wireless: Choose the network(s) you want to attach to this wireless
interface
- (whilst choosing the interface for a network) Tunnel Interface, Alias
Interface.
This terminology desperately needs disambiguating (just an observation,
not a criticism), at least away from single word terms.
But currently it seems to be:
-device is the hardware
-interface is hardware configured to operate at some network layer
What do Linux (kernel) devs use?
___
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.0 Fourth release candidate - DSA docs
Hey Rich. On 17/09/2021 14:30, Rich Brown wrote: 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. Sadly, both definitions are wrong. A network device is not the physical connections but the physical hardware that is used to convey bits/frames to other computers. A physical hardware is not a networking protocol. It cannot abide on any of the OSI layers. A network interface provides the means on the software to connect to a network. Routers route packets (and they're not necessarily have to be Internet Protocol packets). It cannot abide on any of the OSI layers. 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. I don't see why not. Changing "config device" to "config interface" won't work with older configs so we can keep it as is and document it properly on LuCI & the wiki as you said. However, we can change "config interface" to "config network". Then, automatically migrate "config interface" entries to "config network" on older configs. Best regards, 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
Re: OpenWrt 21.02.0 Fourth release candidate - DSA docs
On 2021-09-17 13:27, Perry wrote: Hi all, On 9/17/21 1:30 PM, Rich Brown wrote: 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. This is not always the case. For example, it is possible to have a tun or tap interface which does not have a corresponding ip address. This is more than just a device, because layer 3 packets can arrive on such an interface. Another example, from Freifunk, are mesh (either Ad-Hoc or 802.11s) interfaces. These are interfaces which have a static IP address, but the netmask is 255.255.255.255. This is not a network in the sense most people are used to using, but still a completely valid configuration. I think staying with the terminology "device" and "interface" is the right way to go. Greets, Perry Largely agree - device --> hardware device --> hwdev interface ? GUI is an interface. NIC is an interface. This is abstract. Trying to make it concrete is just confusing. Specify: L3interface L4interface MLinterface (multi layer) This terminology desperately needs disambiguating (just an observation, not a criticism), at least away from single word terms. But currently it seems to be: -device is the hardware -interface is hardware configured to operate at some network layer What do Linux (kernel) devs use? ___ 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
Hi all, On 9/17/21 1:30 PM, Rich Brown wrote: > 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. This is not always the case. For example, it is possible to have a tun or tap interface which does not have a corresponding ip address. This is more than just a device, because layer 3 packets can arrive on such an interface. Another example, from Freifunk, are mesh (either Ad-Hoc or 802.11s) interfaces. These are interfaces which have a static IP address, but the netmask is 255.255.255.255. This is not a network in the sense most people are used to using, but still a completely valid configuration. I think staying with the terminology "device" and "interface" is the right way to go. Greets, Perry > > 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 > ___ 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
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.0 Fourth release candidate - DSA docs
-- What this mail is trying to accomplish? Change "interface" and "device" networking terms on LuCI/UCI and OpenWrt Wiki. -- Device and Interface Confusion With DSA, each switch port became an interface, and that produced the need of configuring interfaces. This confusion became more prevalent after mid-2020, when the ability of creating interfaces & using bridge VLAN filter feature of the Linux kernel using UCI/LuCI was implemented on OpenWrt. 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”. UCI treats “config interface” as configuring networks but “config device” as configuring interfaces. If one heads to Network → Wireless and assign a wireless interface to a network, LuCI literally calls the networks under Network → Interfaces as “Network”. Therefore I propose these changes to LuCI & UCI: -- UCI Syntax - config interface -> config network - config device -> config interface -- LuCI - Rename "Interfaces" on the section tab and the heading to "Networks" - Rename "Devices" to "Interfaces" --- About the DSA documentation... I believe DSA & Bridge VLAN filtering feature should be properly distinguished on the wiki to prevent confusion. I'll work on this along with other things on the documentation with Rich. Cheers. Arınç On 22/08/2021 18:15, Arınç ÜNAL wrote: Hello. (This is my new email address that I use from now on. I'm also testing a new mail client, sorry if my reply is unintentionally garbled.) On 22/08/2021 17:11, Rich Brown wrote: 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. "Upgrading to OpenWrt 21.02.0" looks inclusive enough in my humble opinion. However, I think that the DSA Mini-Tutorial & Converting to DSA pages are absolutely not good enough for a release. I've got a lot of points to make, so I'm going to write another email about it in the upcoming days. Arınç ___ 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
Hello. (This is my new email address that I use from now on. I'm also testing a new mail client, sorry if my reply is unintentionally garbled.) On 22/08/2021 17:11, Rich Brown wrote: 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. "Upgrading to OpenWrt 21.02.0" looks inclusive enough in my humble opinion. However, I think that the DSA Mini-Tutorial & Converting to DSA pages are absolutely not good enough for a release. I've got a lot of points to make, so I'm going to write another email about it in the upcoming days. Arınç ___ 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
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
> Hi Arınç, > > Thanks for working on a swconfig to DSA migration script. > I would prefer not to delay the final 21.02 release further. We should fix the > IPv6 flow offload problems and then do the final 21.02 release. +1 > Such a migration script also needs testing, user will have all sorts of > strange > configurations, so I would assume that we would need 2 months for testing > after the initial version is ready. > For 21.02 we should work on the DSA documentation which Rafal and Rich > already did and continue like it is now. Not all targets are migrated to DSA > yet, so a migration script would still be useful for the next release or we > could > integrate it into a later minor release. > > Hauke openpgp-digital-signature.asc Description: PGP signature ___ 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
Dear list, Is anyone else experiencing LAN ports going down and up intermittently? Tue Aug 3 15:10:37 2021 kern.info kernel: [40216.869351] mt7530 mdio-bus:1f lan1: Link is Up - 100Mbps/Full - flow control off Tue Aug 3 15:10:54 2021 kern.info kernel: [40234.277374] mt7530 mdio-bus:1f lan1: Link is Down Tue Aug 3 15:10:57 2021 kern.info kernel: [40237.349616] mt7530 mdio-bus:1f lan1: Link is Up - 100Mbps/Full - flow control off Tue Aug 3 15:16:01 2021 kern.info kernel: [40541.482137] mt7530 mdio-bus:1f lan1: Link is Down It does not happen constantly, but when it does happen it happens every few minutes and it causes connectivity issues. I am having this issue on OpenWrt 21.02 (I am on the rc4 branch at the moment), I am in touch with other people experiencing the same issue, I am not sure if it's something that happens only on the models having this driver mt7530 or is happening on more models and I'm not 100% sure it happens only on OpenWrt 21.02 but I am experiencing it only on OpenWrt 21 for the moment so I thought it would be worth to share this information here and hear more opinions regarding it. Thanks in advance. Best regards Federico Capoano ___ 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
Hey Hauke. On Tue, Aug 10, 2021 at 8: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. Not all targets are migrated to > DSA yet, so a migration script would still be useful for the next > release or we could integrate it into a later minor release. Fair enough. I wrote the Converting to DSA page of the DSA documentation and continue improving it. It should be good enough for users to recreate their swconfig configuration for DSA until the script is ready to be shipped. ___ 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
On 8/8/21 1:43 PM, Arınç ÜNAL wrote: Congrats! Before we get to the final release, the DSA migration script should be included. Looks like I'm going to hire someone to write the script for me. I know DSA, not changing text on configuration files with awk, grep, etc. Want to give a hand? Please let me know. I still plan to update the converting to DSA page here: https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa Cheers. Arınç Hi Arınç, Thanks for working on a swconfig to DSA migration script. I would prefer not to delay the final 21.02 release further. We should fix the IPv6 flow offload problems and then do the final 21.02 release. Such a migration script also needs testing, user will have all sorts of strange configurations, so I would assume that we would need 2 months for testing after the initial version is ready. For 21.02 we should work on the DSA documentation which Rafal and Rich already did and continue like it is now. Not all targets are migrated to DSA yet, so a migration script would still be useful for the next release or we could integrate it into a later minor release. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ 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
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Removing openwrt-announce from the distribution :-) Am Sonntag, 8. August 2021, 13:43:39 CEST schrieb Arınç ÜNAL: > Congrats! Before we get to the final release, the DSA migration script > should be included. > Looks like I'm going to hire someone to write the script for me. I > know DSA, not changing text on configuration files with awk, grep, > etc. > Want to give a hand? Please let me know. > > I still plan to update the converting to DSA page here: > https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa > > Cheers. > Arınç -- Rainer Dorsch Beatus-Widmann-Str. 5 72138 Kirchentellinsfurt 07157/734133 --- End Message --- ___ 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
Congrats! Before we get to the final release, the DSA migration script should be included. Looks like I'm going to hire someone to write the script for me. I know DSA, not changing text on configuration files with awk, grep, etc. Want to give a hand? Please let me know. I still plan to update the converting to DSA page here: https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa Cheers. Arınç ___ 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
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
