Re: Ethernet switch with linux/openwrt and DSA

2022-12-20 Thread Janusz Dziedzic
śr., 14 gru 2022 o 20:35 Jan Hoffmann  napisał(a):
>
> > Hi Janusz,
> >
> >  > Could I just buy (any experience):
> >  >
> >  > HP switch 1920-24G JG924A
> >  > Do I need to check any HW ver? Or any JG924A should work?
> >
> > The devices from HPE 1920 series with model numbers JG92xA are all
> > Realtek-based, and should be compatible with OpenWrt (make sure not to
> > get a device from the similarly-named 1920S-series though, as those are
> > not supported).
> >
> > Note that the HPE devices are only supported in master and support for
> > 1920-48G is not yet included.
>
> And to be clear, the models with PoE are also not supported (I forgot
> about those in the initial message).
>
> > For 1920-24G, the patches 2 and 5 from [1] are probably still necessary,
> > as the device will reset during boot otherwise. I should really send
> > updated versions of these to finally get that issue fixed.
> >

Thanks all!
Finally buy: D-LINK DGS-1210-48 G1.

U-Boot 2011.12.(2.1.5.67086)-Candidate1 (Apr 13 2017 - 13:58:11)

Board: RTL839x CPU:700MHz LXB:200MHz MEM:400MHz
DRAM:  128 MB
SPI-F: 1x32 MB

Next:
 - connected serial cable
 - stop in uboot
 - boot from 
tftp/openwrt-realtek-rtl839x-d-link_dgs-1210-52-initramfs-kernel.bin
 - next simple scp/sysupgrade
openwrt-realtek-rtl839x-d-link_dgs-1210-52-squashfs-sysupgrade.bin

root@OpenWrt:~# ubus call system board
{
"kernel": "5.10.156",
"hostname": "OpenWrt",
"system": "RTL8393",
"model": "D-Link DGS-1210-52",
"board_name": "d-link,dgs-1210-52",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"revision": "r21432-4c0919839d",
"target": "realtek/rtl839x",
"description": "OpenWrt SNAPSHOT r21432-4c0919839d"
}
}
root@OpenWrt:~#

BR
Janusz

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


Host dependency issues

2022-12-20 Thread quic_pkommu
Hi  Developers,
Hope all is well  

We are trying to enable selinux ,   21.02   where the default mtd-utils  (for 
NAND /ubifs ) are not supporting selinux . 
So  we moved to  mtd-utils 2.1.5 , where its fixed but we are seeing this build 
time  failure. 

Problem :
During mkfs.ubifs  host utility compilation   make system /autoconfig  is 
checking for thefollowing  depenecy as these are the first to get compile   
(libselinux is much later )
LIBSELINUX , 
SELinux/selinux.h
Selinux/label.h

So when compiling mtd-utils  this artifacts are  not found in the expected path 
 and  autoconfig  is assuming no-selinux and  disable SELinux . 
Where most of the include / Lib are in hostpkg which is not even created at 
that point of  time .
If I compile just mtd-utils post libselinux ( clean mtd-utils )  it works .
  . 

//LOG for config 
 #include 
configure:15186: result: no
configure:15186: WARNING: selinux/selinux.h: accepted by the compiler, rejected 
by the preprocessor!
configure:15186: WARNING: selinux/selinux.h: proceeding with the compiler's 
result
configure:15186: checking for selinux/selinux.h
configure:15186: result: yes
configure:15200: checking selinux/label.h usability
configure:15200: gcc -c -O2 
-I/local/mnt/workspace/rsiddoji/OWRT_Workspace/owrt/staging_dir/host/include  
-I/local/mnt/workspace/rsiddoji/OWRT_Workspace/owrt/staging_dir/hostpkg/include 
-I/local/mnt/workspace/rsiddoji/OWRT_Workspace/owrt/staging_dir/host/include  
conftest.c >&5
configure:15200: $? = 0
configure:15200: result: yes
configure:15200: checking selinux/label.h presence
configure:15200: gcc -E 
-I/local/mnt/workspace/rsiddoji/OWRT_Workspace/owrt/staging_dir/host/include  
conftest.c
conftest.c:25:10: fatal error: selinux/label.h: No such file or directory
#include 
  ^
compilation terminated.
configure:15200: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "mtd-utils"
| #define PACKAGE_TARNAME "mtd-utils"
| #define PACKAGE_VERSION "2.1.5"
| #define PACKAGE_STRING "mtd-utils 2.1.5"
| #define PACKAGE_BUGREPORT linux-...@lists.infradead.org
 End of log 


What we had tried :  

HOST_BUILD_DEPENDS:=libselinux/host
DEPENDS:=libselinux

## under define Package/mtd-utils/Default
DEPENDS:=@NAND_SUPPORT  +libselinux
But all this options seem to be used in enabling and disabling options at 
menuconfig level ,  

Is there a way that we can create a inter dependent , or make  selinux compile 
first and later the mtd-utils ? 


Regards,
Ravi, Prashanth.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH] base-files: Remove nand.sh dependency from emmc upgrade

2022-12-20 Thread Brian Norris
emmc_do_upgrade() relies on identify() from the nand.sh upgrade helper.
This only works because FEATURES=emmc targets also tend to include
FEATURES=nand.

Signed-off-by: Brian Norris 
---
 .../base-files/files/lib/upgrade/common.sh| 27 
 package/base-files/files/lib/upgrade/emmc.sh  |  2 +-
 package/base-files/files/lib/upgrade/nand.sh  | 32 ++-
 3 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 5af061f6a439..53b8865a5788 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -127,6 +127,33 @@ get_magic_fat32() {
(get_image "$@" | dd bs=1 count=5 skip=82) 2>/dev/null
 }
 
+identify_magic_long() {
+   local magic=$1
+   case "$magic" in
+   "55424923")
+   echo "ubi"
+   ;;
+   "31181006")
+   echo "ubifs"
+   ;;
+   "68737173")
+   echo "squashfs"
+   ;;
+   "d00dfeed")
+   echo "fit"
+   ;;
+   "4349"*)
+   echo "combined"
+   ;;
+   "1f8b"*)
+   echo "gzip"
+   ;;
+   *)
+   echo "unknown $magic"
+   ;;
+   esac
+}
+
 part_magic_efi() {
local magic=$(get_magic_gpt "$@")
[ "$magic" = "EFI PART" ]
diff --git a/package/base-files/files/lib/upgrade/emmc.sh 
b/package/base-files/files/lib/upgrade/emmc.sh
index c3b02864aa91..49cffe1c658b 100644
--- a/package/base-files/files/lib/upgrade/emmc.sh
+++ b/package/base-files/files/lib/upgrade/emmc.sh
@@ -58,7 +58,7 @@ emmc_copy_config() {
 }
 
 emmc_do_upgrade() {
-   local file_type=$(identify $1)
+   local file_type=$(identify_magic_long "$(get_magic_long "$1")")
 
case "$file_type" in
"fit")  emmc_upgrade_fit $1;;
diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index 1019b9927c02..3907d868f879 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -63,40 +63,12 @@ get_magic_long_tar() {
(tar xO${3}f "$1" "$2" | dd bs=4 count=1 | hexdump -v -n 4 -e '1/1 
"%02x"') 2> /dev/null
 }
 
-identify_magic() {
-   local magic=$1
-   case "$magic" in
-   "55424923")
-   echo "ubi"
-   ;;
-   "31181006")
-   echo "ubifs"
-   ;;
-   "68737173")
-   echo "squashfs"
-   ;;
-   "d00dfeed")
-   echo "fit"
-   ;;
-   "4349"*)
-   echo "combined"
-   ;;
-   "1f8b"*)
-   echo "gzip"
-   ;;
-   *)
-   echo "unknown $magic"
-   ;;
-   esac
-}
-
-
 identify() {
-   identify_magic $(nand_get_magic_long "$@")
+   identify_magic_long $(nand_get_magic_long "$@")
 }
 
 identify_tar() {
-   identify_magic $(get_magic_long_tar "$@")
+   identify_magic_long $(get_magic_long_tar "$@")
 }
 
 identify_if_gzip() {
-- 
2.35.1


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


[PATCH] base-files: upgrade: Fix export_partdevice() quoting

2022-12-20 Thread Brian Norris
$BOOTDEV_MAJOR may be empty for many of the uevents parsed in this
function. This condition thus tends to fail benignly (we just skip to
the next device), but it can really clutter the stage2 sysupgrade
stderr, since it looks like the "=" operand doesn't have an appropriate
left-hand argument.

Signed-off-by: Brian Norris 
---
 package/base-files/files/lib/upgrade/common.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index 53b8865a5788..af1182cb16a3 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -232,7 +232,7 @@ export_partdevice() {
while read line; do
export -n "$line"
done < "$uevent"
-   if [ $BOOTDEV_MAJOR = $MAJOR -a $(($BOOTDEV_MINOR + $offset)) = 
$MINOR -a -b "/dev/$DEVNAME" ]; then
+   if [ "$BOOTDEV_MAJOR" = "$MAJOR" -a $(($BOOTDEV_MINOR + 
$offset)) = "$MINOR" -a -b "/dev/$DEVNAME" ]; then
export "$var=$DEVNAME"
return 0
fi
-- 
2.35.1


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


a nuking the mac80211 changing codel parameters patch

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

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

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

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

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

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

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

2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016.

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

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

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

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

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

-   sta->cparams.ecn = false;

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

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

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

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

+   return;

Ideally we could kill this entire call off entirely.

 }

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

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


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 97d24e9..457209a 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2766,15 +2766,7 @@ unsigned long ieee80211_sta_last_active(struct sta_info *sta)
 
 static void sta_update_codel_params(struct sta_info *sta, u32 thr)
 {
-	if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
-		sta->cparams.target = MS2TIME(50);
-		sta->cparams.interval = MS2TIME(300);
-		sta->cparams.ecn = false;
-	} else {
-		sta->cparams.target = MS2TIME(20);
-		sta->cparams.interval = MS2TIME(100);
-		sta->cparams.ecn = true;
-	}
+	return;
 }
 
 void ieee80211_sta_set_expected_throughput(struct ieee80211_sta *pubsta,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[openwrt] Patch notification: 2 patches updated

2022-12-20 Thread Patchwork
Hello,

The following patches (submitted by you) have been updated in Patchwork:

 * openwrt: [1/2] trusted-firmware-a.mk: use correct CPE ID
 - 
http://patchwork.ozlabs.org/project/openwrt/patch/mailman.48547.1671559514.4154159.openwrt-de...@lists.openwrt.org/
 - for: OpenWrt development
was: New
now: Accepted

 * openwrt: [2/2] arm-trusted-firmware-sunxi: drop CPE ID
 - 
http://patchwork.ozlabs.org/project/openwrt/patch/mailman.48546.1671559514.4154159.openwrt-de...@lists.openwrt.org/
 - for: OpenWrt development
was: New
now: Accepted

This email is a notification only - you do not need to respond.

Happy patchworking.

--

This is an automated mail sent by the Patchwork system at
patchwork.ozlabs.org. To stop receiving these notifications, edit
your mail settings at:
  http://patchwork.ozlabs.org/mail/

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


[PATCH 1/2] trusted-firmware-a.mk: use correct CPE ID

2022-12-20 Thread stijn--- via openwrt-devel
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 ---
There are 2 different CPE IDs on the NVD website:
cpe:/a:arm:trusted_firmware-a
cpe:/o:arm:arm_trusted_firmware

The ID as currently used in trusted-firmware-a.mk does not exist. The
CPE ID using the arm_trusted_firmware product name only lists a few
records for versions 2.2 and 2.3 on the NVD site. The CPE ID using the
trusted_firmware-a product name lists many more records, and actually
has a CVE linked to it. Therefore, use the CPE ID using the
trusted_firmware-a product name.

Fixes: 104d60fe94ce ("trusted-firmware-a.mk: add PKG_CPE_ID")
Signed-off-by: Stijn Tintel 
---
 include/trusted-firmware-a.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/trusted-firmware-a.mk b/include/trusted-firmware-a.mk
index 0b37c0f943..082ada269c 100644
--- a/include/trusted-firmware-a.mk
+++ b/include/trusted-firmware-a.mk
@@ -1,5 +1,5 @@
 PKG_NAME ?= trusted-firmware-a
-PKG_CPE_ID ?= cpe:/a:arm:arm_trusted_firmware
+PKG_CPE_ID ?= cpe:/a:arm:trusted_firmware-a
 
 ifndef PKG_SOURCE_PROTO
 PKG_SOURCE = trusted-firmware-a-$(PKG_VERSION).tar.gz
-- 
2.38.2


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


[PATCH 2/2] arm-trusted-firmware-sunxi: drop CPE ID

2022-12-20 Thread stijn--- via openwrt-devel
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 ---
The CPE ID is already set in trusted-firmware-a.mk.

Signed-off-by: Stijn Tintel 
---
 package/boot/arm-trusted-firmware-sunxi/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/package/boot/arm-trusted-firmware-sunxi/Makefile 
b/package/boot/arm-trusted-firmware-sunxi/Makefile
index 430d78f7a3..178b3958b8 100644
--- a/package/boot/arm-trusted-firmware-sunxi/Makefile
+++ b/package/boot/arm-trusted-firmware-sunxi/Makefile
@@ -8,7 +8,6 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=arm-trusted-firmware-sunxi
-PKG_CPE_ID:=cpe:/o:arm:arm_trusted_firmware
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-- 
2.38.2


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


[PATCH v2] uboot-sunxi: use UUID of bootdev and bootpart

2022-12-20 Thread Jan-Niklas Burfeind
for the NanoPi R1 instead of the hardcoded `mmcblk0p2` to support its
multiple mmcs.

Fixes: e6d9f6fdff ("sunxi: add support for FriendlyARM NanoPi R1")
Co-authored-by: Karl Palsson 
Signed-off-by: Jan-Niklas Burfeind 
---
 package/boot/uboot-sunxi/Makefile| 1 +
 package/boot/uboot-sunxi/uEnv-anymmc.txt | 8 
 2 files changed, 9 insertions(+)
 create mode 100644 package/boot/uboot-sunxi/uEnv-anymmc.txt

diff --git a/package/boot/uboot-sunxi/Makefile 
b/package/boot/uboot-sunxi/Makefile
index 5c27407d15..e4e4089015 100644
--- a/package/boot/uboot-sunxi/Makefile
+++ b/package/boot/uboot-sunxi/Makefile
@@ -184,6 +184,7 @@ define U-Boot/nanopi_r1
   BUILD_SUBTARGET:=cortexa7
   NAME:=U-Boot for NanoPi R1 (H3)
   BUILD_DEVICES:=friendlyarm_nanopi-r1
+  UENV:=anymmc
 endef
 
 define U-Boot/orangepi_r1
diff --git a/package/boot/uboot-sunxi/uEnv-anymmc.txt 
b/package/boot/uboot-sunxi/uEnv-anymmc.txt
new file mode 100644
index 00..36e41c59b1
--- /dev/null
+++ b/package/boot/uboot-sunxi/uEnv-anymmc.txt
@@ -0,0 +1,8 @@
+setenv fdt_high 
+setenv mmc_rootpart 2
+part uuid mmc ${mmc_bootdev}:${mmc_rootpart} uuid
+setenv loadkernel fatload mmc \$mmc_bootdev \$kernel_addr_r uImage
+setenv loaddtb fatload mmc \$mmc_bootdev \$fdt_addr_r dtb
+setenv bootargs console=ttyS0,115200 earlyprintk root=PARTUUID=${uuid} rootwait
+setenv uenvcmd run loadkernel \&\& run loaddtb \&\& bootm \$kernel_addr_r - 
\$fdt_addr_r
+run uenvcmd
-- 
2.39.0


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


[PATCH] procd: add procd_unlock wrapper

2022-12-20 Thread Florian Eckert
Extend the procd shell wrapper lib with the missing funktion procd_unlock.
This could be used in scripts to unlock a previously locked section.

Signed-off-by: Florian Eckert 
---
 package/system/procd/files/procd.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/package/system/procd/files/procd.sh 
b/package/system/procd/files/procd.sh
index e41117fb2c..c8e5fd0325 100644
--- a/package/system/procd/files/procd.sh
+++ b/package/system/procd/files/procd.sh
@@ -59,6 +59,10 @@ procd_lock() {
fi
 }
 
+procd_unlock() {
+   flock -u 1000
+}
+
 _procd_call() {
local old_cb
 
-- 
2.30.2


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