Sometimes the mmc deivce may come up later than kernel attempts to
mount rootfs, resulting kernel panic. Enable rootwait to fix it.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
(cherry picked from commit a0645675d4)
Make sure patch sequence number is unique by moving patch
440-add-jdcloud_re-cp-03.patch -> 441-add-jdcloud_re-cp-03.patch
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
(cherry picked from commit 2302a7c5ad)
(cherry picked from commit 9f739daf05)
When the DHCPv6 client sends a DHCPv6 Solicit with both IA_NA and IA_PD
options, and if the server replies with a status code = NoAddrsAvailable
in the IA_NA option, then currently the DHCPv6 client sends a new
Solicit with only the IA_PD option despite the fact that a prefix was
sent by the server in the previous Advertise.
This behavior is described in
https://datatracker.ietf.org/doc/html/rfc7550#section-4.2
The client must handle the case of a server that does not offer both
valid IA_NA and IA_PD options when both are requested, according to RFC
7550. It should not send a new Solicit, but a Request. The client should
however ignore the Advertise message if none of the IA_NA and IA_PD
options are offered by the server.
References: PCF-1390
Signed-off-by: Matthias FRANCK <matthias.franck@softathome.com>
Netifd is not longer responsible for configuring the gateway. The TR181 components took over this task.
Signed-off-by: Matthias FRANCK <matthias.franck@softathome.com>
- Remove syslog-ng config option that creates a logrotate conf. This
option was causing a duplicate config error in syslog.
- Remove the script from base-files that adds logrotate cron job.
- Add logrotate package. It was selected by the removed config options
before.
- Adapt logrotate test to include separated logs
Signed-off-by: Yüce Kürüm <yuce.kurum@mind.be>
Signed-off-by: Yüce Kürüm <yuce.kurum_ext@softathome.com>
(cherry picked from commit c13ed76075)
A segfault could arise when a NAK is send to a client that requested an
address in an old range. Here we check that the variable have valid
memory to be allocated.
References: PCF-557, !144
Signed-off-by: Alexandre Fiset <alexandre.fiset_ext@softathome.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 84c467fc9b)
Refresh patch automatically so it applies cleanly after dnsmasq bump to
version v2.87.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 5fd6832a63)
For the complete functionality of ambiorix dhcpv4-manager plugin, we
would need this patch included in prplOS. This patch exposes the
requested options of the client, expands the information in the
broadcasted events in ubus, and introduces a method in dnsmasq ubus
object called leases().
* Add dnsmasq networkid to the events.
* Expose DHCPREQUEST options.
* 'leases' ubus method to retrieve the list of leases.
The purpose of the patch is to be able to synchronize with leases
from dnsmasq using ubus only. The ubus 'leases' method can be called
once and then subscribe to the events based on the dhcp packets
received.
The ubus events remain as they were, just add the parameter of the
networkid to identify the pool to which they belong in the config,
and the requested dhcp options from the client.
The patch is included temporarily, upstreaming process is being tracked
via JIRA ticket PCF-557.
References: !144
References: PCF-557
Signed-off-by: Eduardo Aguilar <eduardo.aguilar_ext@softathome.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [commit description]
(cherry picked from commit 953282dc48)
Signed-off-by: Petr Štetiar <ynezz@true.cz> [rebased onto dnsmasq v2.86]
(cherry picked from commit c0b3fa868d)
We've 3 downstream patches for procd which were cherry-picked from 22.03
release and this commit rebases them onto the procd from OpenWrt 23.05.
Signed-off-by: Petr Štetiar <petr.stetiar@prplfoundation.org>
Mount systemd cgroup virtual controller at boot, so they can be used to
run systemd based containers.
Signed-off-by: Matthias FRANCK <matthias.franck_ext@softathome.com>
(cherry picked from commit 69ec728452918e6679b1de74a954c00df0d7c96e)
Set clone_children flag in cpuset, so it inherits the configured defaults of the parent.
Signed-off-by: Matthias FRANCK <matthias.franck_ext@softathome.com>
(cherry picked from commit 58da6b91b3208438d561638618abb2703c230d0b)
Properly mount cgroups in a root tmpfs where every controller is mounted
in a seperate subdirectory, recommended by the kernel documentation of
cgroupsv1.
Signed-off-by: Matthias FRANCK <matthias.franck_ext@softathome.com>
(cherry picked from commit af84ad24a6acd355ec39c8355eccb02e47b3bec6)
We've now prplOS version available, so lets make it available in build
artifacts as well.
References: PCF-691
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 8cf5efccf9)
According to TR181, setting the RSEnable parameter to false should result in no router solicitation messages to be sent from the interface. This seems not the case, the messages are always seen regardless of the parameter value.
To solve this patch odhcp6c to not automatically sends Router Sollicitations as well.
This patch should be properly reworked to make it upstreamable. This progress is tracked in PCF-950
(cherry picked from commit 0f87c3f5a3)
To translate the logical interface name (e.g. lan) to the physical name (e.g. br-lan)
- first odhcpd will look in /etc/config/dhcp for dhcp.lan.ifname or dhcp.lan.networkid
- then, if compiled with WITH_UBUS, odhcpd will look at /etc/config/network and the interface name is overruled even if not found
This patch should be upstreamed. This is tracked in PCF-951.
Signed-off-by: Matthias FRANCK <matthias.franck_ext@softathome.com>
(cherry picked from commit be95bc06b6)
For now services and hosts are not linked, umdns need to be modified to allow that link witch is required by tr181
This patch should be upstreamed, this progress is tracked in PCF-952.
Signed-off-by: Matthias FRANCK <matthias.franck_ext@softathome.com>
(cherry picked from commit 637e7e319d)
Currently two IPv6 related tests ipv6_app_114 (FTP) and ipv6_app_124
(TFTP) fails due to disabled automatic conntrack helper, so fix it by
enabling it explicitly.
Fixes: PCF-840
References: PCF-671
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 4b76442e50)
(cherry picked from commit 1d6070b9ac)
I've just discovered broken networking on x86/64 QEMU target due to
changes introduced in commit 484946872e ("base-files: board.d: add
guest bridge to default network config"), where guest bridge touches
network configuration and thanks to that x86/64 QEMU is not getting
default network configuration applied, which creates incomplete network
configuration. So fix it by moving guest bridge configuration past
default network configuration.
Fixes: 484946872e ("base-files: board.d: add guest bridge to default network config")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit f8d96184e8)
(cherry picked from commit 8e6657045d)
Backport cron job setup from commit fb0a7d7bcc ("profiles: prpl: fix
various issues in syslog-ng and tr069-manager").
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 2a93b42897)
With the recent addition of several kernel module dependencies needed by
tr181-qos manager we've started experiencing issues with command prompt
detection in labgrid's shelldriver component.
It's likely related to longer kernel module loading times, which is then
having impact on delayed and longer kernel messages output on serial
console, thus interleaving labgrid command markers with kernel messages
and causing command prompt detection unreliable.
Current serial console loglevel is set to debug log level (KERN_DEBUG=7)
which makes kernel output very verbose and in some corner cases it's
causing interleaving of messages on serial console which makes currently
controlling of the DUT via labgrid framework very unreliable.
Fixing this properly via PCF-617 upstream in the labgrid framework is
going to take some time, so as a temporary workaround we're going to
decrease default kernel log level to warning (KERN_WARNING=4) which
limits kernel log output to the serial console a lot. Those kernel log
messages are not lost, they're still available in syslog's messages log
file.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit c57924854a)
(cherry picked from commit fdf99433f1)
It was decided to rename project name from prplWrt to prplOS, so change
default hostname to prplOS as well.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit c7f349bb00)
(cherry picked from commit d26279279e)
Project was renamed in 8/2021 so let's update the welcome banner as well.
Closes PCF-639
Signed-off-by: Olaf Wachendorf <olaf.wachendorf@maxlinear.com>
(cherry picked from commit a03b397f68)
(cherry picked from commit 24a271688f)
It was decided, that prplOS should ship with guest bridge in default
config.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 484946872e)
(cherry picked from commit 9c3661be64)
This test verifies large DNS responses using EDNS0 option, where the
test prepares DNS entry with 200 IPv4 matching records that requires a
UDP response slightly less (3274) than EDNS maximum payload size of 4096
octets. This packet is ignored as current maximum payload size is set to
1232 octets, so fix this by increasing the value to maximum payload size.
References: PCF-548
References: https://tools.ietf.org/html/rfc6891
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit b6d1adce51)
(cherry picked from commit b34446900f)
cdrouter_firewall_508: Verify outbound packets are not forwarded if the
source address is not a prefix of the interior network
This test ensures that the random martian address assigned to the LAN
client in step 2 is outside of lanIp/lanMask, does not match any static
routes configured with staticRouteLanNetwork and is not within any of
the following reserved IP ranges: 0.0.0.0/8,
127.0.0.0/8, 169.254.0.0/16, 192.88.99.0/24, 224.0.0.0/4,
240.0.0.0/4, 255.255.255.255/32.
Make the test pass by setting `rp_filter` to strict mode. Strict mode as
defined in RFC3704 Strict Reverse Path Each incoming packet is tested
against the FIB and if the interface is not the best reverse path the
packet check will fail. By default failed packets are discarded.
Current recommended practice in RFC3704 is to enable strict mode to
prevent IP spoofing from DDos attacks. If using asymmetric routing or
other complicated routing, then loose mode is recommended.
References: PCF-548
References: https://tools.ietf.org/html/rfc3704
References: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit b9ad7cbf75)
(cherry picked from commit 4a593e72e3)
Changes:
2a768c4 wireless-regdb: Update regulatory rules for Mongolia (MN) on 6GHz
04875d9 wireless-regdb: Update regulatory rules for Saudi Arabia (SA) on 6GHz
b7bced8 wireless-regdb: Update regulatory rules for South Africa (ZA) on 6GHz
7bc8615 wireless-regdb: Update regulatory info for Thailand (TH) on 6GHz
f901fa9 wireless-regdb: Update regulatory info for Malaysia (MY) for 2022
d72d288 wireless-regdb: Update regulatory info for Morocco (MA) on 6GHz
414face wireless-regdb: Update regulatory info for Chile (CL) on 6GHz
1156a08 wireless-regdb: Update regulatory info for Mexico (MX) on 6GHz
cc6cf7c wireless-regdb: Update regulatory info for Iceland (IS) on 6GHz
ce03cc0 wireless-regdb: Update regulatory info for Mauritius(MU) on 6GHz
7e37778 wireless-regdb: Update regulatory info for Argentina (AR) on 6GHz
56f3a43 wireless-regdb: Update regulatory info for United Arab Emirates (AE) on 6GHz
3cb8b91 wireless-regdb: Update regulatory info for Colombia (CO) on 6GHz
3682ce5 wireless-regdb: Update regulatory info for Costa Rica (CR) for 2021
dd4ffe7 wireless-regdb: Update regulatory info for Dominican Republic (DO) on 6GHz
f8ef7da wireless-regdb: Update regulatory info for Liechtenstein (LI) on 6GHz
a9ecabe wireless-regdb: Update regulatory info for Jordan (JO) for 2022
5a9fdad wireless-regdb: Update regulatory info for Kenya (KE) for 2022
19326c3 wireless-regdb: Update regulatory info for Macao (MO) for 2024
4838054 wireless-regdb: update regulatory database based on preceding changes
Link: https://github.com/openwrt/openwrt/pull/15921
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 0a24fd9155)
The firmware blobs have all different licenses from the different
manufacturers of the binary blobs. This information is contained in the
upstream 'linux-firmware' repositroy.
This commit extends the package handling so that this information can be
added as an additional argument during packages generation.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
(cherry picked from commit 5c14de1d7e)
Link: https://github.com/openwrt/openwrt/pull/15918
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Update the deprecated license information from GPL-2.0 to GPL-2.0-only
as written in the COPYING file of the linux source tree.
Also add the 'COPYING' file to the PKG_LICENSE_FILES variable.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
(cherry picked from commit 879826154f)
Link: https://github.com/openwrt/openwrt/pull/15918
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Netgear EAX12, EAX11v2, EAX15v2 are wall-plug 802.11ax (Wi-Fi 6)
extenders that share the SoC, WiFi chip, and image format with the
WAX202.
Specifications:
* MT7621, 256 MiB RAM, 128 MiB NAND
* MT7915: 2.4/5 GHz 2x2 802.11ax (DBDC)
* Ethernet: 1 port 10/100/1000
* UART: 115200 baud (labeled on board)
All LEDs and buttons appear to work without state_default.
Installation:
* Flash the factory image through the stock web interface, or TFTP to
the bootloader. NMRP can be used to TFTP without opening the case.
Revert to stock firmware:
* Flash the stock firmware to the bootloader using TFTP/NMRP.
References in GPL source:
https://www.downloads.netgear.com/files/GPL/EAX12_EAX11v2_EAX15v2_GPL_V1.0.3.34_src.tar.gz
* target/linux/ramips/dts/mt7621-rfb-ax-nand.dts
DTS file for this device.
Signed-off-by: Wenli Looi <wlooi@ucalgary.ca>
(cherry picked from commit 32ea8a9a7e)
General specification:
SoC Type: MediaTek MT7620A (580MHz)
ROM: 8 MB SPI-NOR (MX25L6406E)
RAM: 64 MB DDR (W9751G6KB-25)
Switch: MediaTek MT7530
Ethernet: 5 ports - 5×100MbE (WAN, LAN1-4)
Wireless: 2.4 GHz (MediaTek RT5390): b/g/n
Wireless: 5 GHz (MediaTek MT7610EN): ac/n
Buttons: 2 button (POWER, WPS/RESET)
Bootloader: U-Boot 1.1.3
Power: 12 VDC, 0.5 A
MACs:
| LAN | [Factory + 0x04] - 2 |
| WLAN 2.4g | [Factory + 0x04] - 1 |
| WLAN 5g | [Factory + 0x8004] - 3 |
| WAN | [Factory + 0x04] - 2 |
OEM easy installation:
1. Use a PC to browse to http://192.168.0.1.
2. Go to the System section and open the Firmware Update section.
3. Under the Local Update at the right, click on the CHOOSE FILE...
4. When a modal window appears, choose the firmware file and click on
the Open.
5. Next click on the UPDATE FIRMWARE button and upload the firmware image.
Wait for the router to flash and reboot.
OEM installation using the TFTP method (need level converter):
1. Download the latest firmware image.
2. Set up a Tftp server on a PC (e.g. Tftpd32) and place the firmware
image to the root directory of the server.
3. Power off the router and use a twisted pair cable to connect the PC
to any of the router's LAN ports.
4. Configure the network adapter of the PC to use IP address 192.168.0.180
and subnet mask 255.255.255.0.
5. Connect serial port (57600 8N1) and turn on the router.
6. Then interrupt "U-Boot Boot Menu" by hitting 2 key (select "2: Load
system code then write to Flash via TFTP.").
7. Press Y key when show "Warning!! Erase Linux in Flash then burn new
one. Are you sure? (Y/N)"
Input device IP (192.168.0.1) ==:192.168.0.1
Input server IP (192.168.0.180) ==:192.168.0.180
Input Linux Kernel filename () ==:firmware_name
The router should download the firmware via TFTP and complete flashing in
a few minutes.
After flashing is complete, use the PC to browse to http://192.168.1.1 or
ssh to proceed with the configuration.
Signed-off-by: Alexey Bartenev <41exey@proton.me>
(cherry picked from commit ce998cb6e1)
Specification:
- MT7981 CPU using 2.4GHz and 5GHz WiFi (both AX)
- MT7531 switch
- 512MB RAM
- 128MB NAND flash with two UBI partitions with identical size
- 1 multi color LED (red, green, blue, white) connected via GCA230718
- 3 buttons (WPS, reset, LED on/off)
- 1 1Gbit WAN port
- 4 1Gbit LAN ports
Disassembly:
- There are four screws at the bottom: 2 under the rubber feets, 2 under the label.
- After removing the screws, the white plastic part can be shifted out of the blue part.
- Be careful because the antennas are mounted on the side and the top of the white part.
Serial Interface
- The serial interface can be connected to the 4 pin holes on the side of the board.
- Pins (from front to rear):
- 3.3V
- RX
- TX
- GND
- Settings: 115200, 8N1
MAC addresses:
- WAN MAC is stored in partition "Odm" at offset 0x81
- LAN (as printed on the device) is WAN MAC + 1
- WLAN MAC (2.4 GHz) is WAN MAC + 2
- WLAN MAC (5GHz) is WAN MAC + 3
Flashing via Recovery Web Interface:
- The recovery web interface always flashes to the currently active partition.
- If OpenWrt is flahsed to the second partition, it will not boot.
- Ensure that you have an OEM image available (encrypted and decrypted version). Decryption is described in the end.
- Set your IP address to 192.168.200.10, subnetmask 255.255.255.0
- Press the reset button while powering on the device
- Keep the reset button pressed until the LED blinks red
- Open a Chromium based and goto http://192.168.200.1 (recovery web interface)
- Download openwrt-mediatek-filogic-dlink_aquila-pro-ai-m30-a1-squashfs-recovery.bin
- The recovery web interface always reports successful flashing, even if it fails
- After flashing, the recovery web interface will try to forward the browser to 192.168.0.1 (can be ignored)
- If OpenWrt was flashed to the first partition, OpenWrt will boot (The status LED will start blinking white and stay white in the end). In this case you're done and can use OpenWrt.
- If OpenWrt was flashed to the second partition, OpenWrt won't boot (The status LED will stay red forever). In this case, the following steps are reuqired:
- Start the web recovery interface again and flash the **decrypted OEM image**. This will be flashed to the second partition as well. The OEM firmware web interface is afterwards accessible via http://192.168.200.1.
- Now flash the **encrypted OEM image** via OEM firmware web interface. In this case, the new firmware is flashed to the first partition. After flashing and the following reboot, the OEM firmware web interface should still be accessible via http://192.168.200.1.
- Start the web recovery interface again and flash the OpenWrt recovery image. Now it will be flashed to the first partition, OpenWrt will boot correctly afterwards and is accessible via 192.168.1.1.
Flashing via U-Boot:
- Open the case, connect to the UART console
- Set your IP address to 192.168.200.2, subnet mask 255.255.255.0. Connect to one of the LAN interfaces of the router
- Run a tftp server which provides openwrt-mediatek-filogic-dlink_aquila-pro-ai-m30-a1-initramfs-kernel.bin.
- Power on the device and select "7. Load image" in the U-Boot menu
- Enter image file, tftp server IP and device IP (if they differ from the default).
- TFTP download to RAM will start. After a few seconds OpenWrt initramfs should start
- The initramfs is accessible via 192.168.1.1, change your IP address accordingly (or use multiple IP addresses on your interface)
- Perform a sysupgrade using openwrt-mediatek-filogic-dlink_aquila-pro-ai-m30-a1-squashfs-sysupgrade.bin
- Reboot the device. OpenWrt should start from flash now
Revert back to stock using the Recovery Web Interface:
- Set your IP address to 192.168.200.2, subnetmask 255.255.255.0
- Press the reset button while powering on the device
- Keep the reset button pressed until the LED blinks red
- Open a Chromium based and goto http://192.168.200.1 (recovery web interface)
- Flash a decrypted firmware image from D-Link. Decrypting an firmware image is described below.
Decrypting a D-Link firmware image:
- Download https://github.com/RolandoMagico/firmware-utils/blob/M32/src/m32-firmware-util.c
- Compile a binary from the downloaded file, e.g. gcc m32-firmware-util.c -lcrypto -o m32-firmware-util
- Run ./m32-firmware-util M30 --DecryptFactoryImage <OriginalFirmware> <OutputFile>
- Example for firmware M30A1_FW101B05: ./m32-firmware-util M30 --DecryptFactoryImage M30A1_FW101B05\(0725091522\).bin M30A1_FW101B05\(0725091522\)_decrypted.bin
Flashing via OEM web interface is not possible, as it will change the active partition and OpenWrt is only running on the first UBI partition.
Controlling the LEDs:
- The LEDs are controlled by a chip called "GCA230718" which is connected to the main CPU via I2C (address 0x40)
- I didn't find any documentation or driver for it, so the information below is purely based on my investigations
- If there is already I driver for it, please tell me. Maybe I didn't search enough
- I implemented a kernel module (leds-gca230718) to access the LEDs via DTS
- The LED controller supports PWM for brightness control and ramp control for smooth blinking. This is not implemented in the driver
- The LED controller supports toggling (on -> off -> on -> off) where the brightness of the LEDs can be set individually for each on cycle
- Until now, only simple active/inactive control is implemented (like when the LEDs would have been connected via GPIO)
- Controlling the LEDs requires three sequences sent to the chip. Each sequence consists of
- A reset command (0x81 0xE4) written to register 0x00
- A control command (for example 0x0C 0x02 0x01 0x00 0x00 0x00 0xFF 0x01 0x00 0x00 0x00 0xFF 0x87 written to register 0x03)
- The reset command is always the same
- In the control command
- byte 0 is always the same
- byte 1 (0x02 in the example above) must be changed in every sequence: 0x02 -> 0x01 -> 0x03)
- byte 2 is set to 0x01 which disables toggling. 0x02 would be LED toggling without ramp control, 0x03 would be toggling with ramp control
- byte 3 to 6 define the brightness values for the LEDs (R,G,B,W) for the first on cycle when toggling
- byte 7 defines the toggling frequency (if toggling enabled)
- byte 8 to 11 define the brightness values for the LEDs (R,G,B,W) for the second on cycle when toggling
- byte 12 is constant 0x87
Comparison to M32/R32:
- The algorithms for decrypting the OEM firmware are the same for M30/M32/R32, only the keys differ
- The keys are available in the GPL sources for the M32
- The M32/R32 contained raw data in the firmware images (kernel, rootfs), the R30 uses a sysupgrade tar instead
- Creation of the recovery image is quite similar, only the header start string changes. So mostly takeover from M32/R32 for that.
- Turned out that the bytes at offset 0x0E and 0x0F in the recovery image header are the checksum over the data area
- This checksum was not checked in the recovery web interface of M32/R32 devices, but is now active in R30
- I adapted the recovery image creation to also calculate the checksum over the data area
- The recovery image header for M30 contains addresses which don't match the memory layout in the DTS. The same addresses are also present in the OEM images
- The recovery web interface either calculates the correct addresses from it or has it's own logic to determine where which information must be written
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
(cherry picked from commit 29cca6cfee)
Add basic support for the LED driver for GCA230718.
- I didn't find any documentation or driver for it, so the information below is purely based on my investigations
- If there is already I driver for it, please tell me. Maybe I didn't search enough
- I implemented a kernel module (leds-gca230718) to access the LEDs via DTS
- The LED controller supports PWM for brightness control and ramp control for smooth blinking. This is not implemented in the driver
- The LED controller supports toggling (on -> off -> on -> off) where the brightness of the LEDs can be set individually for each on cycle
- Until now, only simple active/inactive control is implemented (like when the LEDs would have been connected via GPIO)
- Controlling the LEDs requires three sequences sent to the chip. Each sequence consists of
- A reset command (0x81 0xE4) written to register 0x00
- A control command (for example 0x0C 0x02 0x01 0x00 0x00 0x00 0xFF 0x01 0x00 0x00 0x00 0xFF 0x87 written to register 0x03)
- The reset command is always the same
- In the control command
- byte 0 is always the same
- byte 1 (0x02 in the example above) must be changed in every sequence: 0x02 -> 0x01 -> 0x03)
- byte 2 is set to 0x01 which disables toggling. 0x02 would be LED toggling without ramp control, 0x03 would be toggling with ramp control
- byte 3 to 6 define the brightness values for the LEDs (R,G,B,W) for the first on cycle when toggling
- byte 7 defines the toggling frequency (if toggling enabled)
- byte 8 to 11 define the brightness values for the LEDs (R,G,B,W) for the second on cycle when toggling
- byte 12 is constant 0x87
Signed-off-by: Roland Reinl <reinlroland+github@gmail.com>
(cherry picked from commit 0682974aa8)
Alexander reported following:
iwlwifi 0000:00:14.3: Detected crf-id 0x3617, cnv-id 0x20000302 wfpm id 0x80000000
iwlwifi 0000:00:14.3: PCI dev a0f0/0074, rev=0x351, rfid=0x10a100
iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-77.ucode failed with error -2
It seems, that as of the current date, the highest firmware API version
supported by Linux 6.8-rc7 is still 77.
Closes: #14771
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 8db83d4cc0)
[Reduce to API version 72 for older mac80211]
Link: https://github.com/openwrt/openwrt/pull/15898
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This contains a fix for:
CVE-2024-28960: An issue was discovered in Mbed TLS 2.18.0 through 2.28.x
before 2.28.8 and 3.x before 3.6.0, and Mbed Crypto. The PSA Crypto
API mishandles shared memory.
(cherry picked from commit 360ac07eb9)
Link: https://github.com/openwrt/openwrt/pull/15898
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
