[RFT] Kernels for next release
Hi all, Kernels for the next release are looking pretty good; except for six targets we got everything running on 5.10! Thanks to everyone who contributed and tested! The following five target support Kernel 5.10 and need testing: - ath25 - bcm63xx - layerscape - octeon - octeontx If you own the targets hardware please consider testing the new Kernel and report back! There is an overview on GitHub[1] linking all PRs. If you don’t use GitHub please respond to this email. Kernel 5.10 is a hard blocker for the next OpenWrt release. Only arc770 lacks Kernel 5.10 support. I’m in contact with people working on it, patches should be available soon. Since arc770 hardware is a bit rare we lacked proper testing in the past. In case there would be any *free* demo hardware available, would anyone be interested in working and testing arc770? Apart from that, happy new year to everyone! Sunshine, Paul [1] https://github.com/aparcar/openwrt/issues/15 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] openssl: bump to 1.1.1m
This is a bugfix release. Changelog:
*) Avoid loading of a dynamic engine twice.
*) Fixed building on Debian with kfreebsd kernels
*) Prioritise DANE TLSA issuer certs over peer certs
*) Fixed random API for MacOS prior to 10.12
Patches were refreshed.
Signed-off-by: Eneas U de Queiroz
---
Tested on mediatek/Linksys E8450 using hostapd & nginx.
package/libs/openssl/Makefile | 6 +++---
...perlasm-ppc-xlate.pl-add-linux64v2-flavour.patch | 13 +++--
.../patches/100-Configure-afalg-support.patch | 2 +-
3 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
index 0512abdc48..9e7482117d 100644
--- a/package/libs/openssl/Makefile
+++ b/package/libs/openssl/Makefile
@@ -9,9 +9,9 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=openssl
PKG_BASE:=1.1.1
-PKG_BUGFIX:=l
+PKG_BUGFIX:=m
PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX)
-PKG_RELEASE:=2
+PKG_RELEASE:=1
PKG_USE_MIPS16:=0
ENGINES_DIR=engines-1.1
@@ -26,7 +26,7 @@ PKG_SOURCE_URL:= \
ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/ \
ftp://ftp.pca.dfn.de/pub/tools/net/openssl/source/old/$(PKG_BASE)/
-PKG_HASH:=0b7a3e5e59c34827fe0c3a74b7ec8baef302b98fa80088d7f9153aa16fa76bd1
+PKG_HASH:=f89199be8b23ca45fc7cb9f1d8d3ee67312318286ad030f5316aca6462db6c96
PKG_LICENSE:=OpenSSL
PKG_LICENSE_FILES:=LICENSE
diff --git
a/package/libs/openssl/patches/001-crypto-perlasm-ppc-xlate.pl-add-linux64v2-flavour.patch
b/package/libs/openssl/patches/001-crypto-perlasm-ppc-xlate.pl-add-linux64v2-flavour.patch
index bdc0509f8c..e52a3d52ea 100644
---
a/package/libs/openssl/patches/001-crypto-perlasm-ppc-xlate.pl-add-linux64v2-flavour.patch
+++
b/package/libs/openssl/patches/001-crypto-perlasm-ppc-xlate.pl-add-linux64v2-flavour.patch
@@ -1,7 +1,7 @@
-From 34ab13b7d8e3e723adb60be8142e38b7c9cd382a Mon Sep 17 00:00:00 2001
+From Mon Sep 17 00:00:00 2001
From: Andy Polyakov
Date: Sun, 5 May 2019 18:25:50 +0200
-Subject: [PATCH] crypto/perlasm/ppc-xlate.pl: add linux64v2 flavour
+Subject: crypto/perlasm/ppc-xlate.pl: add linux64v2 flavour
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
@@ -14,12 +14,8 @@ endian nowadays (Adélie Linux, Void Linux, possibly Gentoo,
etc.)
Reviewed-by: Paul Dale
Reviewed-by: Richard Levitte
(Merged from https://github.com/openssl/openssl/pull/8883)
- crypto/perlasm/ppc-xlate.pl | 8
- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/crypto/perlasm/ppc-xlate.pl b/crypto/perlasm/ppc-xlate.pl
-index e52f2f6ea6..5fcd0526df 100755
--- a/crypto/perlasm/ppc-xlate.pl
+++ b/crypto/perlasm/ppc-xlate.pl
@@ -49,7 +49,7 @@ my $globl = sub {
@@ -49,7 +45,7 @@ index e52f2f6ea6..5fcd0526df 100755
my $mtspr = sub {
my ($f,$idx,$ra) = @_;
if ($idx == 256 && $no_vrsave) {
-@@ -320,7 +320,7 @@ while($line=<>) {
+@@ -318,7 +318,7 @@ while($line=<>) {
if ($label) {
my $xlated = ($GLOBALS{$label} or $label);
print "$xlated:";
@@ -58,6 +54,3 @@ index e52f2f6ea6..5fcd0526df 100755
if ($TYPES{$label} =~ /function/) {
printf "\n.localentry %s,0\n",$xlated;
}
---
-2.31.1
-
diff --git a/package/libs/openssl/patches/100-Configure-afalg-support.patch
b/package/libs/openssl/patches/100-Configure-afalg-support.patch
index 98944103b5..d8789f4b45 100644
--- a/package/libs/openssl/patches/100-Configure-afalg-support.patch
+++ b/package/libs/openssl/patches/100-Configure-afalg-support.patch
@@ -12,7 +12,7 @@ diff --git a/Configure b/Configure
index 5a699836f3..74d057c219 100755
--- a/Configure
+++ b/Configure
-@@ -1545,7 +1545,9 @@ unless ($disabled{"crypto-mdebug-backtrace"})
+@@ -1548,7 +1548,9 @@ unless ($disabled{"crypto-mdebug-backtrace"})
unless ($disabled{afalgeng}) {
$config{afalgeng}="";
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[WIP,RFC] general improvements for map-t and other protocols
This is my first post on the mailing list, so if I'm wrong please let me know. I would like to discuss a number of improvements that I would like to implement on openwrt to better integrate this technology. So I would like to understand with you what changes could be useful to the community and what is a patch only for my ISP. Since December 2021 my ISP offers IPv4 connectivity through MAP-T. The configuration arrives via DHCP and is now automatic on Openwrt. The share ratio which can be 1:16 or 1:1. The CPE provided automatically opts out from 1:16 to 1:1 if you activate: - DMZ - Port forwarding - UPNP Let's move on to the improvements I've made and would like to integrate: - The map.sh script of the "map" module now creates a json structure in the "data" field [1], in this structure there is all the information of the interface configuration: the type of map, the prefix of the BR, the various FMRs and the shared v4 address. For an example of the generated JSON: https://pastebin.com/raw/7WQ30LVy - Luci allows a protocol to generate the DOM for its state [2], so a protocol could override the general behavior of the "luci-mod-network" module. This is used together with the new JSON structure [3] to show the user the range of associated ports and other useful information. For the visual results: https://i.ibb.co/FB7FHVd/immagine.png https://i.ibb.co/PmGVNFg/immagine.png. As you may have noticed, the default overview behavior is overridden [4] and the "EDIT" key is changed to "Status" if the interface is "virtual" and does not have an associated UCI node. If the button is pressed, a modal is opened with the call to the new "renderStatus" function of the protocol. Alternatively, if the protocol has an associated UCI node, a "Status" TAB is populated in the classic modal. [5][6] - We have added to odhcp6c the possibility to prefix to send an IA_PREFIX [7], this can be useful as my ISP foresees this behavior. (The v6 prefix also determines the port range and v4, so being able to request the same prefix is very important to firewall rules). To date, this function can be configured in the "Request IPv6-prefix of length" in Luci with the format: "v6-pd\len:IADID". I would therefore like to discuss whether it might be worth splitting this option into several fields. For now it has not been done for reasons of backward compatibility. All this still needs to be tested, especially with MAP-E to see if there may be some kind of regression. For this we have a local lab where we do all the tests. Now we come to the sore keys: - miniupnp should be configured at runtime when the map interface goes UP. Specifically, the range of ports to whitelist, and the shared IPv4. Being MAP a "tunnel", it does not have an IPv4 assigned to the interface and therefore miniupnp thinks it is not active (miniupnp uses the IP to understand if an interface is up or down [8]). Passing an IPv4 address is also quite simple to implement, but it would be a specific implementation for this protocol so I don't know how to go about it. I'll have to add a parser in the init.d script to read the interface JSON described in the point above. Specifically unlike Luci, netifd does not have a method for extracting data resolved by a protocol. Netifd only takes care of configuring or deactivating an interface. It would therefore be necessary to define a standard JSON structure for the protocols so a single parser can be implemented for other protocols as well. This might be useful for DDNS and other packages that require access to the WAN IP. My idea was to implement ubus into miniupnp to get the device status and interface IP using the conventional JSON structure described above. - Due to the overhead the MAP-T process sometimes makes connections to hangs/stalls. My ISP supports mini jumbo frames, so in my case I can set WAN6 that way. It would therefore be necessary to make a firewall rule to do MSS clamping if the MTU of the uplink interface is set to 1500. So far I have not seen any way in fw3 to do this. The auto generated rule seems hard-coded. The ISP CPE has that rule set [9], and it seems that other users that have MAP have the MTU manually set [10]. - When Share ratio is 1:1 the port set is not necessary and the CPE has a full port range available. Non TCP/UDP protocols fail to work in 1:1 ratio; to make them work we assign the calculated IP address [11] to the MAP interface. I'm not sure if this is the correct way to go but it is working. (tested with GRE) I also wish the whole team a happy new year! Thanks in advance for any feedback, Nicolò References: [1]: https://github.com/hitech95/openwrt/commit/6ed00a53325008f586f36c6e136bf06b950ba419 [2]: https://github.com/hitech95/openwrt_luci/commit/a401a42d0d8023909abfe6c2c3a3db141f12178e [3]: https://github.com/hitech95/openwrt_luci/commit/6dd7beb3d244eb5370a9732dd5e4f675352a2be9 [4]:
