Backport upstream commit dropping external definition of mbrtowc. The
said definition conflicts with one provided by GCC 15. Issue found on
24.10 SDK.
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
The Xiaomi MiWiFi 3A wireless router has a similar system architecture as the Xiaomi Mi 4A router, which is already officially supported by OpenWrt.
Product website: https://www.mi.com/miwifi3a
Device specification
--------------------
SoC: MT7628AN MIPS_24KEc @ 580 MHz 2.4G-bgn 2x2
WiFi: MT7612EN 5G-an, ac 80 MHz 2T2R
Flash: 16 MB
DRAM: 64 MB
Switch: MT7628AN (integrated in SoC)
Ethernet: 1 x 10 /100 Mbps
USB: None
Antennas: 2 x 2,4 GHz and 2 x 5 GHz (all are external and non-detachable)
LEDs: blue/red/amber
Buttons: Reset
Serial: 115200,8n1
MAC addresses as verified by OEM firmware:
------------------------------------------
use address source
LAN *:DD factory 0x28
WAN *:DD factory 0x28
2g *:DE factory 0x4
5g *:DF factory 0x8004
OEM firmware uses VLAN's to create the network interface for WAN and LAN.
Bootloader info:
----------------
The stock bootloader uses a "Dual ROM Partition System".
OS1 is a deep copy of OS2.
The bootloader starts OS2 by default.
To force start OS1 it is needed to set "flag_try_sys2_failed=1".
How to install:
---------------
1- Use OpenWRTInvasion to gain Telnet, SSH and FTP access: https://github.com/acecilia/OpenWRTInvasion
[IP: 192.168.31.1 | Username: root | Password: root | FTP-Port: 21]
2- Connect to router using telnet or ssh.
3- Backup all partitions. Use command "dd if=/dev/mtd0 of=/tmp/mtd0". Copy /tmp/mtd0 to computer using ftp.
4- Copy openwrt-ramips-mt76x8-xiaomi_miwifi-3a-squashfs-sysupgrade.bin to /tmp in router using ftp.
5- Enable UART access and change start image to OS1.
nvram set uart_en=1
nvram set flag_last_success=1
nvram set boot_wait=on
nvram set flag_try_sys2_failed=1
nvram commit
6- Erase OS1 & OS2 and install OpenWrt
mtd erase OS1
mtd erase OS2
mtd -r write /tmp/openwrt-ramips-mt76x8-xiaomi_miwifi-3a-squashfs-sysupgrade.bin OS1
Credits:
--------
This PR is based on the work of Zehao Zhang (Github: @ZZH-Finalize) that he had published in the PR: #15698
Signed-off-by: Olgun Demir <olgun.demir@mail.com.tr>
Link: https://github.com/openwrt/openwrt/pull/18427
(cherry picked from commit c3b8108a2b)
Link: https://github.com/openwrt/openwrt/pull/18550
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This commit adds support for Mercusys MR80X(EU) v3 router.
Device specification:
- SoC: Mediatek MT7981b, Cortex-A53, 64-bit
- RAM: 512MB
- Flash: SPI NAND GigaDevice GD5F1GQ5UEYIGY (128 MB)
- Ethernet: 4x 100/1000 Mbps LAN1,LAN2,LAN3 & WAN
- Wireless: 2.4GHz (802.11 b/g/n/ax)
- Wireless: 5GHz (802.11 a/n/ac/ax)
- LEDs: 1 orange and 1 green status LEDs, 4 green gpio-controlled LEDs
on ethernet ports
- Buttons: 1 (Reset)
- Bootloader: Main U-Boot - U-Boot 2022.01-rc4. Additionally, both UBI
slots contain "seconduboot" (also U-Boot 2022.01-rc4)
Installation (UART):
- Place OpenWrt initramfs-kernel image on tftp server with IP 192.168.1.2
- Attach UART, switch on the router and interrupt the boot process by
pressing 'Ctrl-C'.
- Set the uboot environment for startup.
setenv tp_boot_idx 0; setenv bootcmd bootm 0x46000000; saveenv
If the bootarg is set to boot from ubi1, also change it to ubi0.
- Load and run OpenWrt initramfs image.
setenv serverip 192.168.1.2; setenv ipaddr 192.168.1.1; tftpboot initramfs-kernel.bin; bootm
- Login as root via SSH (IP 192.168.1.1, port 22)
- Upload OpenWrt sysupgrade.bin image to the /tmp dir of the router
- Run sysupgrade:
sysupgrade -n /tmp/sysupgrade.bin
Recovery:
- Press Reset button and power on the router.
- Navigate to U-Boot recovery web server (http://192.168.1.1/) and
upload the OEM firmware.
Stock layout:
0x000000000000-0x000000200000 : "boot"
0x000000200000-0x000000300000 : "u-boot-env"
0x000000300000-0x000003500000 : "ubi0"
0x000003500000-0x000006700000 : "ubi1"
0x000006700000-0x000006f00000 : "userconfig"
0x000006f00000-0x000007300000 : "tp_data"
ubi0/ubi1 format:
U-Boot at boot checks that all volumes are in place:
+-------------------------------+
| Volume Name: uboot Vol ID: 0|
| Volume Name: kernel Vol ID: 1|
| Volume Name: rootfs Vol ID: 2|
+-------------------------------+
MAC addresses:
+---------+-------------------+-----------+
| | MAC | Algorithm |
+---------+-------------------+-----------+
| label | 94:0C:xx:xx:xx:12 | label |
| WAN | 94:0C:xx:xx:xx:13 | label+1 |
| LAN | 94:0C:xx:xx:xx:12 | label |
| WLAN 2g | 94:0C:xx:xx:xx:11 | label-1 |
| WLAN 5g | 94:0C:xx:xx:xx:10 | label-2 |
+---------+-------------------+-----------+
label MAC address was found in UBI partition "tp_data", file
"default-mac".
Signed-off-by: Schneider Azima <Schneider-Azima12@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/18181
(cherry picked from commit 7921e48d43)
Signed-off-by: Schneider Azima <Schneider-Azima12@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/18522
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The RPi 5 Compute Module expects the same NVRAM as the one from RPi 4
on a different file.
Signed-off-by: Dave Marquard <dave-atx@users.noreply.github.com>
Link: https://github.com/openwrt/openwrt/pull/18722
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 8774dd7761)
Instead of enabling RSS support, let's introduce a variant and let users
choose between both variants since it can cause network issues.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit cb3fc1aef9)
We need both ENABLE_RSS_SUPPORT and ENABLE_MULTIPLE_TX_QUEUE in order to
support multiple RX and TX queues.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 7615de6ef0)
We need both ENABLE_RSS_SUPPORT and ENABLE_MULTIPLE_TX_QUEUE in order to
support multiple RX and TX queues.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit a3e51a3956)
We need both ENABLE_RSS_SUPPORT and ENABLE_MULTIPLE_TX_QUEUE in order to
support multiple RX and TX queues.
Signed-off-by: Pavel Kubelun <be.dissent@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18509
[bump release, improve commit description and package changes]
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit d127963a46)
Disable ASPM support for this NIC, fixing strange behavior problems, such as
increased latency, strange uneven throughput, etc.
With this option disabled the NIC achieves stable performance.
Upsteam r8169 driver disables ASPM by default for this NIC.
Signed-off-by: Pavel Kubelun <be.dissent@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18509
[bump release, fix commit description, split 2nd tx queue part]
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit f99b39fd0c)
This allows the network interface naming to be stable, free from any
possible interaction from external USB network devices that might
claim usb* interface names.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit b5680bd113)
This allows the network interface naming to be stable, free from any
possible interaction from external USB network devices that might
claim usb* interface names.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 9bb151d0c6)
This allows the network interface naming to be stable, free from any
possible interaction from external USB network devices that might
claim usb* interface names.
Signed-off-by: Pavel Kubelun <be.dissent@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18509
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit ce9f539672)
This allows the network interface naming to be stable, free from any
possible interaction from external USB network devices that might
claim usb* interface names.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 617961403c)
This allows the network interface naming to be stable, free from any
possible interaction from external USB network devices that might
claim usb* interface names.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 7aeb837bf4)
Update ca-certificates to version 20241223
* Update Mozilla certificate authority bundle to version 2.70.
The following certificate authorities were added (+):
+ Telekom Security TLS ECC Root 2020
+ Telekom Security TLS RSA Root 2023
+ FIRMAPROFESIONAL CA ROOT-A WEB
+ TWCA CYBER Root CA
+ SecureSign Root CA12
+ SecureSign Root CA14
+ SecureSign Root CA15
The following certificate authorities were removed (-):
- Security Communication Root CA (closes: #1063093)
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
Link: https://github.com/openwrt/openwrt/pull/18468
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit c79572210f)
r8127 is an out of tree driver provided by Realtek for RTL8127 devices.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 851ea69d8e)
In recent glibc versions rpc functionality has been moved to a separate
library instead of glibc itself.
Depend on this library when rpc functionality is needed and glibc is
used.
Signed-off-by: Matthias Franck <matthias.franck@softathome.com>
Link: https://github.com/openwrt/openwrt/pull/17796
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 84e0900867)
For WIFI7 devices (such as mt7925e), the dev width is currently
always "20 MHz (no HT)" in monitor mode.
Add EHT and HE160 support to iw_htmode to fix this issue.
Additionally, the following changes are made:
1. Set iw_htmode to 160MHz for VHT160. The reason for the current
VHT160 setting is unclear and seems to have been in place for
over a decade (ibss_htmode [1]). If anyone knows its impact,
please inform me so I can restore it.
2. Modify MHZ to MHz. The original matching table in the current
iw tool uses MHz. Although the match is case-insensitive,
correcting this won't hurt.
[1]: 768d09be87
Signed-off-by: Ming Kuang <ming@imkuang.com>
Link: https://github.com/openwrt/openwrt/pull/18319
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 86eb1c0b5a)
The ath10k dt-binding property "qcom,coexist-support" was
explicitly defined as type uint8 since upstream commit
ed09c61eb19d ("dt-bindings: net: Convert ath10k to YAML").
Therefore, this hack patch no longer makes sense.
Link: ed09c61eb1
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/18393
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit da13174aa1)
Remove settings and depends that are not used anywhere.
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: #18291
(cherry picked from commit b6ff3d9afa)
Link: https://github.com/openwrt/openwrt/pull/18431
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
**Huasifei WH3000 eMMC / Fudy MT3000**
Portable Wi-Fi 6 travel router based on MediaTek MT7981A SoC.
MT7981B+MT7976CN+RTL8221B Dual Core 1.3GHZ
**Specifications**
SoC: Filogic 820 MT7981A (1.3GHz)
RAM: DDR4 1GB
Flash: eMMC 8GB
WiFi: 2.4GHz and 5GHz with 3 antennas
Ethernet:
1x WAN (10/100/1000M)
1x LAN (10/100/1000/2500M)
USB: 1x USB 3.0 port
Two buttons: power/reset and mode (BTN_0)
LEDS: blue, red, blue+red=pink
UART: 3.3V, TX, RX, GND / 115200 8N1
**Installation via U-Boot rescue**
1. Set static IP 192.168.1.2 on your computer and default route as 192.168.1.1
2. Connect to the WAN port and hold the reset button while booting the device.
3. Wait for the LED to blink 5 times, and release the reset button.
4. Open U-boot web page on your browser at http://192.168.1.1
5. Select the OpenWRT sysupgrade image, upload it, and start the upgrade.
6. Wait for the router to flash the new firmware.
7. Wait for the router to reboot itself.
**Installation via sysupgrade**
Just flash sysupgrade file via [LuCI upgrade page](http://192.168.1.1/cgi-bin/luci/admin/system/flash) without saving the settings.
**Installation via SSH**
Upload the file to the router `/tmp` directory, `ssh root@192.168.1.1` and issue a command:
```
sysupgrade -n /tmp/openwrt-mediatek-filogic-huasifei_wh3000-emmc-squashfs-sysupgrade.bin
```
**Factory MAC**
You can find your Factory MAC which is mentioned on the box at `/dev/mmcblck0p2` partition `factory` starting from `0x4`
```
dd if=/dev/mmcblk0p2 bs=1 skip=4 count=6 | hexdump -C
```
**Enlarging a partition**
Though device has 8GB eMMC, it uses only 2GB `/dev/mmcblck0p6` as `rootfs` for `/rom` and `/overlay` leaving `/dev/mmcblck0p7` as empty unused space.
```
sgdisk -p /dev/mmcblk0
```
```
Disk /dev/mmcblk0: 15269888 sectors, 7.3 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 2BD17853-102B-4500-AA1A-8A21D4D7984D
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 14942174
Partitions will be aligned on 1024-sector boundaries
Total free space is 11197 sectors (5.5 MiB)
Number Start (sector) End (sector) Size Code Name
1 8192 9215 512.0 KiB 8300 u-boot-env
2 9216 13311 2.0 MiB 8300 factory
3 13312 21503 4.0 MiB 8300 fip
4 21504 29695 4.0 MiB 8300 config
5 29696 62463 16.0 MiB 8300 kernel
6 62464 4256767 2.0 GiB 8300 rootfs
7 4257792 14940159 5.1 GiB 8300
```
You can fix that by loading into `initramfs-kernel`, deleting empty `mmcblck0p7` partition and resizing `mmcblck0p6`
```
sysupgrade -F /tmp/openwrt-initramfs-kernel.bin
```
Install and run cfdisk
```
opkg update && opkg install cfdisk
cfdisk /dev/mmcblck0
```
- Select `mmcblck0p7` -> Delete
- Select `mmcblck0p6` -> Resize -> Write -> yes -> Quit
You will not see any difference in `cat /proc/partitions` after that but just flash a `sysupgrade` and you'll get the whole 7.3GB space for the `/overlay`.
Co-developed-by: hecatae <horus.ra@gmail.com>
Signed-off-by: Fil Dunsky <filipp.dunsky@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18220
(cherry picked from commit 99ea96c297)
Link: https://github.com/openwrt/openwrt/pull/18434
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This PR adds support for netis NX31 router.
Specification
-------------
- SoC : MediaTek MT7981BA dual-core ARM Cortex-A53 1.3 GHz
- RAM : 256 MiB DDR3
- Flash : SPI-NAND 128 MiB (ESMT)
- WLAN : MediaTek MT7976CN dual-band WiFi 6
- 2.4 GHz : b/g/n/ax, MIMO 2x2
- 5 GHz : a/n/ac/ax, MIMO 2x2
- Ethernet : 10/100/1000 Mbps x3 (LAN, MediaTek MT7531AE)
10/100/1000 Mbps x1 (WAN, SoC internal phy)
- USB : No
- Buttons : Mesh, Reset
- LEDs : 1x Power (blue), unmanaged
1x Status (blue), gpio-controlled
1x WiFi 2.4 GHz (blue), gpio-controlled
1x WiFi 5 GHz (blue), gpio-controlled
3x LAN activity (blue), switch-controlled
1x WAN activity (blue), gpio-controlled
- Power : 12 VDC, 1 A
Installation
------------
1. Connect to the router using ssh (user: admin, pass: web interface
password)
2. Make mtd backup:
cat /dev/mtd0 | gzip -1 -c > /tmp/mtd0_spi0.0.bin.gz
cat /dev/mtd1 | gzip -1 -c > /tmp/mtd1_BL2.bin.gz
cat /dev/mtd2 | gzip -1 -c > /tmp/mtd2_u-boot-env.bin.gz
cat /dev/mtd3 | gzip -1 -c > /tmp/mtd3_Factory.bin.gz
cat /dev/mtd4 | gzip -1 -c > /tmp/mtd4_FIP.bin.gz
cat /dev/mtd5 | gzip -1 -c > /tmp/mtd5_ubi.bin.gz
3. Download mtd backup from the /tmp dir of the router to your PC using
scp protocol
4. Upload OpenWrt 'bl31-uboot.fip', 'preloader.bin' images to the /tmp
dir of the router using scp protocol
5. Write FIP and BL2 (replace bootloader):
mtd write /tmp/openwrt-mediatek-filogic-netis_nx31-bl31-uboot.fip FIP
mtd write /tmp/openwrt-mediatek-filogic-netis_nx31-preloader.bin BL2
6. Place OpenWrt
'openwrt-mediatek-filogic-netis_nx31-initramfs-recovery.itb' image on
the tftp server (IP: 192.168.1.254)
7. Erase 'ubi' partition and reboot the router:
mtd erase ubi
reboot
8. U-Boot automatically boot OpenWrt recovery image from tftp server to
the RAM
9. Upload OpenWrt 'sysupgrade.itb' image to the /tmp dir of the router
(IP: 192.168.1.1) using scp protocol
10. Connect to the router using ssh and run:
sysupgrade -n openwrt-mediatek-filogic-netis_nx31-squashfs-sysupgrade.itb
Return to stock
---------------
1. Unpack stock BL2 and FIP partitions backup
2. Upload stock BL2 and FIP partitions backup to the /tmp dir of the
router using scp protocol
3. Connect to the router using ssh and run:
apk update && apk add kmod-mtd-rw
insmod mtd-rw i_want_a_brick=1
mtd unlock BL2
mtd unlock FIP
4. Restore backup:
mtd write /tmp/mtd4_FIP.bin FIP
mtd write /tmp/mtd1_BL2.bin BL2
5. Erase ubi and reboot:
mtd erase ubi
reboot
6. Power off the router
7. Press Reset button and power on the router. Release the button after
~10 sec
8. Navigate to U-Boot recovery web server (http://192.168.1.1/) and
upload the OEM firmware
Recovery
--------
1. Place OpenWrt
'openwrt-mediatek-filogic-netis_nx31-initramfs-recovery.itb' image on
the tftp server (IP: 192.168.1.254)
2. Press “Reset” button and power on the router. After ~10 sec release
the button.
3. Use OpenWrt initramfs system for recovery
MAC addresses
-------------
+---------+-------------------+-----------+
| | MAC | Algorithm |
+---------+-------------------+-----------+
| LAN | dc:xx:xx:d1:xx:18 | label |
| WAN | dc:xx:xx:d1:xx:1a | label+2 |
| WLAN 2g | de:xx:xx:11:xx:19 | |
| WLAN 5g | de:xx:xx:71:xx:19 | |
+---------+-------------------+-----------+
The LAN MAC was found in 'Factory', 0x1fef20
The WAN MAC was found in 'Factory', 0x1fef26
The WLAN 2g/5g MAC prototype was found in 'Factory', 0x4
Signed-off-by: Mikhail Zhilkin <csharper2005@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18324
(cherry picked from commit d8002cb627)
Signed-off-by: Mikhail Zhilkin <csharper2005@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18438
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Backport two commits to resolve issues with ath1kk causing it to fail
driver registration on iommuless systems with DRAM outside of 32bit
addressing such as a 4GiB imx8mm:
commit 1bcd20981834 ("wifi: ath11k: Fix DMA buffer allocation
to resolve SWIOTLB issues")
commit eeadc6baf8b3 ("wifi: ath11k: Use dma_alloc_noncoherent
for rx_tid buffer allocation")
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Link: https://github.com/openwrt/openwrt/pull/17751
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit fa50e53aa9)
This allows the network interface naming to be stable, free from any
possible interaction from external USB network devices that might
claim usb* interface names.
(This was a real problem I encountered with a nanopi R6S device and
an external rtl8152 usb3 network controller - the USB controller would
claim the eth1 name, causing much confusion).
Signed-off-by: Michel Lespinasse <michel@lespinasse.org>
Link: https://github.com/openwrt/openwrt/pull/17638
(cherry picked from commit effcb6e4c3)
Link: https://github.com/openwrt/openwrt/pull/18347
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Fix compilation error for old stable version caused by
genlmsg_multicast_allns backport fix pushed middle version.
Version 5.15 version 0-169, 6.1 version 0-115, 6.6 version 0-58 have the
old genlmsg_multicast_allns version with flags variable.
Compiling backport project with these version result in a compilation
error. To handle this, introduce a backport function for the affected
kernel version.
Link: https://github.com/openwrt/openwrt/pull/18373
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
(cherry picked from commit 4039388149)
Do not verify the format of TLV. Leave that to lldpd.
These lldpd config entries:
config custom-tlv
list ports 'eth0'
option tlv 'replace oui 33,44,55 subtype 254 oui-info 55,55,55,55,55'
config custom-tlv
option tlv 'oui 33,44,44 subtype 232'
list ports 'br-lan'
list ports 'eth0'
config custom-tlv # oui-info truncated
option tlv 'add oui 33,44,33 subtype 66 oui-info 5555555555'
config custom-tlv
option tlv 'add oui 33,44,31 subtype 44'
config custom-tlv # invalid oui
option tlv 'add oui 3322 subtype 79'
config custom-tlv # invalid oui
option tlv 'oui 3312 subtype 74'
Produce the following lldpd.conf content:
configure ports eth0 lldp custom-tlv replace oui 33,44,55 subtype 254 oui-info 55,55,55,55,55
configure ports br-lan,eth0 lldp custom-tlv oui 33,44,44 subtype 232
configure lldp custom-tlv add oui 33,44,33 subtype 66 oui-info 5555555555
configure lldp custom-tlv add oui 33,44,31 subtype 44
configure lldp custom-tlv add oui 3322 subtype 79
configure lldp custom-tlv oui 3312 subtype 74
And lldpd (v1.0.13 on v22) logs the following:
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op replace oui 33:44:55 subtype fe
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:44 subtype e8
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:33 subtype 42
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:33 subtype 42
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:31 subtype 2c
Sat Mar 16 19:11:39 2024 daemon.info lldpd[10916]: custom TLV op add oui 33:44:31 subtype 2c
Sat Mar 16 19:11:39 2024 daemon.warn lldpcli[10915]: invalid OUI value '3322'
Sat Mar 16 19:11:39 2024 daemon.info lldpcli[10915]: an error occurred while executing last command
Sat Mar 16 19:11:39 2024 daemon.warn lldpcli[10915]: invalid OUI value '3312'
Sat Mar 16 19:11:39 2024 daemon.info lldpcli[10915]: an error occurred while executing last command
Sat Mar 16 19:11:39 2024 daemon.info lldpcli[10915]: lldpd should resume operations
( The last two TLV are invalid: their oui must be three hex bytes, comma
separated. Only the first hex byte of oui-info 5555555555 is used )
Depends on #14867 and its release version bump
Tested on: 22.03.6
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14872
(cherry picked from commit 8d1fe32c2c)
Link: https://github.com/openwrt/openwrt/pull/18343
Signed-off-by: Robert Marko <robimarko@gmail.com>
where csv = comma separated value(s)
Make the function more generic. Can use it for not only 'config'.
Now it can be used to parse interfaces for additional lldpd settings,
e.g. custom-tlv.
Tested on: 22.03.6
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/14872
(cherry picked from commit a015f59880)
Link: https://github.com/openwrt/openwrt/pull/18343
Signed-off-by: Robert Marko <robimarko@gmail.com>
Apparently U-Boot will discard whole node if requested pin function is
unknown to the driver. This resulted in inability to interact with
U-Boot on the said board, as U-Boot always assumed the recovery key
pressed and issued recovery procedure. Log snippet:
button_gpio gpio-keys: pinctrl_select_state_full: pinctrl_config_one: err=-38
reset button found
button pushed, resetting environment
Recovery procedure also booted recovery image, which didn't affect much
the 23.05.x release, since the root fs argument was valid, so changes
persisted. But as 24.10.x hit with fitblk, the board will boot only
recovery image (initramfs) because of default bootargs will reset on each
boot and U-Boot provided bootargs took precedence.
Fixes: 42eeb22450 ("uboot-mediatek: fix factory/reset button")
Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Link: https://patchwork.ozlabs.org/project/openwrt/patch/20250304164507.60511-1-tmn505@terefe.re/
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit f8a2e1c68b)
Debian Changelogs from 20240531:
local access.
- Mitigations for INTEL-SA-01079 (CVE-2024-23918)
Potential security vulnerabilities in some Intel Xeon processors
using Intel SGX may allow escalation of privilege. Intel disclosed
that some processor models were already fixed by a previous
microcode update.
- Updated mitigations for INTEL-SA-01097 (CVE-2024-24968)
Improper finite state machines (FSMs) in hardware logic in some
Intel Processors may allow an privileged user to potentially enable a
denial of service via local access.
- Mitigations for INTEL-SA-01103 (CVE-2024-23984)
A potential security vulnerability in the Running Average Power Limit
(RAPL) interface for some Intel Processors may allow information
disclosure. Added mitigations for more processor models.
* Updated Microcodes:
sig 0x000806f8, pf_mask 0x87, 2024-06-20, rev 0x2b000603, size 588800
sig 0x000806f7, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f6, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f5, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x000806f4, pf_mask 0x87, 2024-06-20, rev 0x2b000603
sig 0x00090672, pf_mask 0x07, 2024-05-29, rev 0x0037, size 224256
sig 0x00090675, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000b06f2, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000b06f5, pf_mask 0x07, 2024-05-29, rev 0x0037
sig 0x000906a3, pf_mask 0x80, 2024-06-03, rev 0x0435, size 223232
sig 0x000906a4, pf_mask 0x80, 2024-06-03, rev 0x0435
sig 0x000a06a4, pf_mask 0xe6, 2024-08-02, rev 0x0020, size 138240
sig 0x000b06a2, pf_mask 0xe0, 2024-05-29, rev 0x4123, size 220160
sig 0x000b06a3, pf_mask 0xe0, 2024-05-29, rev 0x4123
sig 0x000b06a8, pf_mask 0xe0, 2024-05-29, rev 0x4123
sig 0x000c06f2, pf_mask 0x87, 2024-06-20, rev 0x21000283, size 560128
sig 0x000c06f1, pf_mask 0x87, 2024-06-20, rev 0x21000283
* source: update symlinks to reflect id of the latest release, 20241112
* Update changelog for 3.20240910.1 and 3.20240813.1 with new information:
INTEL-SA-1103 was addressed by 3.20240813.1 for some processor models,
and not by 3.20240910. INTEL-SA-1079 was addressed by 3.20240910.1 for
some processor models.
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 15:37:40 -0300
intel-microcode (3.20241029.1) UNRELEASED; urgency=medium
* New upstream microcode datafile 20241029
- Not relevant for operating system microcode updates
- Only when loaded from firmware, this update fixes the critical,
potentially hardware-damaging errata RPL061: Incorrect Internal
Voltage Request on Raptor Lake (Core 13th/14th gen) Intel
processors.
* Updated Microcodes:
sig 0x000b0671, pf_mask 0x32, 2024-08-29, rev 0x012b, size 211968
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 14 Nov 2024 14:49:03 -0300
intel-microcode (3.20240910.1) unstable; urgency=medium
* New upstream microcode datafile 20240910 (closes: #1081363)
- Mitigations for INTEL-SA-01097 (CVE-2024-24968)
Improper finite state machines (FSMs) in hardware logic in some
Intel Processors may allow an privileged user to potentially enable a
denial of service via local access.
- Fixes for unspecified functional issues on several processor models
- The processor voltage limit issue on Core 13rd/14th gen REQUIRES A
FIRMWARE UPDATE. It is present in this release for sig 0xb0671, but
THE VOLTAGE ISSUE FIX ONLY WORKS WHEN THE MICROCODE UPDATE IS LOADED
THROUGH THE FIT TABLE IN FIRMWARE. Contact your system vendor for a
firmware update that includes the appropriate microcode update for
your processor.
* Updated Microcodes:
sig 0x00090672, pf_mask 0x07, 2024-02-22, rev 0x0036, size 224256
sig 0x00090675, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000b06f2, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000b06f5, pf_mask 0x07, 2024-02-22, rev 0x0036
sig 0x000906a3, pf_mask 0x80, 2024-02-22, rev 0x0434, size 222208
sig 0x000906a4, pf_mask 0x80, 2024-02-22, rev 0x0434
sig 0x000a06a4, pf_mask 0xe6, 2024-06-17, rev 0x001f, size 137216
sig 0x000b0671, pf_mask 0x32, 2024-07-18, rev 0x0129, size 215040
sig 0x000b06a2, pf_mask 0xe0, 2024-02-22, rev 0x4122, size 220160
sig 0x000b06a3, pf_mask 0xe0, 2024-02-22, rev 0x4122
sig 0x000b06a8, pf_mask 0xe0, 2024-02-22, rev 0x4122
sig 0x000b06e0, pf_mask 0x19, 2024-03-25, rev 0x001a, size 138240
* Update changelog for 3.20240813.1 with new information
* Update changelog for 3.20240514.1 with new information
* source: update symlinks to reflect id of the latest release, 20240910
-- Henrique de Moraes Holschuh <hmh@debian.org> Sat, 21 Sep 2024 16:40:07 -0300
intel-microcode (3.20240813.2) unstable; urgency=high
* Merge changes from intel-microcode/3.20240531.1+nmu1, which were left out
from 3.20240813.1 by an oversight, regressing merged-usr. Closes: #1060200
-- Henrique de Moraes Holschuh <hmh@debian.org> Sat, 17 Aug 2024 11:31:32 -0300
intel-microcode (3.20240813.1) unstable; urgency=medium
* New upstream microcode datafile 20240813 (closes: #1078742)
- Mitigations for INTEL-SA-01083 (CVE-2024-24853)
Incorrect behavior order in transition between executive monitor and SMI
transfer monitor (STM) in some Intel Processors may allow a privileged
user to potentially enable escalation of privilege via local access.
- Mitigations for INTEL-SA-01118 (CVE-2024-25939)
Mirrored regions with different values in 3rd Generation Intel Xeon
Scalable Processors may allow a privileged user to potentially enable
denial of service via local access.
- Mitigations for INTEL-SA-01100 (CVE-2024-24980)
Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel
Xeon Processors may allow a privileged user to potentially enable
escalation of privilege via local access.
- Mitigations for INTEL-SA-01038 (CVE-2023-42667)
Improper isolation in the Intel Core Ultra Processor stream cache
mechanism may allow an authenticated user to potentially enable
escalation of privilege via local access. Intel disclosed that some
processor models were already fixed by the previous microcode update.
- Mitigations for INTEL-SA-01046 (CVE-2023-49141)
Improper isolation in some Intel Processors stream cache mechanism may
allow an authenticated user to potentially enable escalation of
privilege via local access. Intel disclosed that some processor models
were already fixed by the previous microcode update.
- Mitigations for INTEL-SA-01079 (CVE-2024-23918)
Potential security vulnerabilities in some Intel Xeon processors
using Intel SGX may allow escalation of privilege. Intel released this
information during the full disclosure for the 20241112 update.
Processor signatures 0x606a6 and 0x606c1.
- Mitigations for INTEL-SA-01103 (CVE-2024-23984)
A potential security vulnerability in the Running Average Power Limit
(RAPL) interface for some Intel Processors may allow information
disclosure. Intel released this information during the full disclosure
for the 20240910 update. Processor signatures 0x5065b, 0x606a6,
0x606c1.
- Fix for unspecified functional issues on several processor models
- Fix for errata TGL068/ADL075/ICL088/... "Processor may hang during a
microcode update". It is not clear which processors were fixed by this
release, or by one of the microcode updates from 2024-05.
- Mitigations for INTEL-SA-01213 (CVE-2024-36293)
Improper access control in the EDECCSSA user leaf function for some
Intel Processors with Intel SGX may allow an authenticated user to
potentially enable denial of service via local access. Intel released
this information during the full disclosure for the 20250211 update.
Processor signature 0x906ec (9th Generation Intel Core processor).
* Updated microcodes:
sig 0x00050657, pf_mask 0xbf, 2024-03-01, rev 0x5003707, size 39936
sig 0x0005065b, pf_mask 0xbf, 2024-04-01, rev 0x7002904, size 30720
sig 0x000606a6, pf_mask 0x87, 2024-04-01, rev 0xd0003e7, size 308224
sig 0x000606c1, pf_mask 0x10, 2024-04-03, rev 0x10002b0, size 300032
sig 0x000706e5, pf_mask 0x80, 2024-02-15, rev 0x00c6, size 114688
sig 0x000806c1, pf_mask 0x80, 2024-02-15, rev 0x00b8, size 112640
sig 0x000806c2, pf_mask 0xc2, 2024-02-15, rev 0x0038, size 99328
sig 0x000806d1, pf_mask 0xc2, 2024-02-15, rev 0x0052, size 104448
sig 0x000806e9, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806e9, pf_mask 0x10, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806ea, pf_mask 0xc0, 2024-02-01, rev 0x00f6, size 105472
sig 0x000806eb, pf_mask 0xd0, 2024-02-01, rev 0x00f6, size 106496
sig 0x000806ec, pf_mask 0x94, 2024-02-05, rev 0x00fc, size 106496
sig 0x00090661, pf_mask 0x01, 2024-04-05, rev 0x001a, size 20480
sig 0x000906ea, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 105472
sig 0x000906eb, pf_mask 0x02, 2024-02-01, rev 0x00f6, size 106496
sig 0x000906ec, pf_mask 0x22, 2024-02-01, rev 0x00f8, size 106496
sig 0x000906ed, pf_mask 0x22, 2024-02-05, rev 0x0100, size 106496
sig 0x000a0652, pf_mask 0x20, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0653, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 98304
sig 0x000a0655, pf_mask 0x22, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0660, pf_mask 0x80, 2024-02-01, rev 0x00fe, size 97280
sig 0x000a0661, pf_mask 0x80, 2024-02-01, rev 0x00fc, size 97280
sig 0x000a0671, pf_mask 0x02, 2024-03-07, rev 0x0062, size 108544
sig 0x000a06a4, pf_mask 0xe6, 2024-04-15, rev 0x001e, size 137216
* source: update symlinks to reflect id of the latest release, 20240813
* postinst, postrm: switch to dpkg-trigger to run update-initramfs
-- Henrique de Moraes Holschuh <hmh@debian.org> Thu, 15 Aug 2024 14:41:50 -0300
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/18197
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit f4801cffc3)
d8b43985e4d7 ubus: fix token_create policy
7326459bd743 ubus: dump service information on network_get
6c9c8fbd8128 service: add @all as alias for all members, unless defined differently
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit 84909c62c8)
The fixes are only for the WRT1900X and WRT1200AC.
It contains:
Deletes the driver's ability to modify the debit table.
Remove skb_get(done_skb) in txdone
Reworking ISR
clean code
Napi replaces tasklet
Add rx_decrypt feature
Signed-off-by: Michael Trinidad <trinidude4@hotmail.com>
Link: https://github.com/openwrt/openwrt/pull/17997
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/18145
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
