Bind to the configured system interfaces only. Switchport interfaces
are no longer ignored and uci interface values for LLDPD are honored.
Signed-off-by: Stephen Howell <howels@allthatwemight.be>
(cherry picked from commit 064b4999ad)
Link: https://github.com/openwrt/openwrt/pull/15299
Signed-off-by: Robert Marko <robimarko@gmail.com>
Init script reload with trigger to detect config file update.
Reload command added to attempt non-impactful lldpd reload where
lldpcli can be used to update config without process restart.
Config hash function used to track whether process restart is needed.
Signed-off-by: Stephen Howell <howels@allthatwemight.be>
(cherry picked from commit e483c247dc)
Link: https://github.com/openwrt/openwrt/pull/15299
Signed-off-by: Robert Marko <robimarko@gmail.com>
allow to overwrite the detected system capabilities e.g. if devices
does not operate as bridge.
Signed-off-by: Sebastian Pflieger <sebastian@pflieger.email>
(cherry picked from commit 3ce909914a)
Link: https://github.com/openwrt/openwrt/pull/15299
Signed-off-by: Robert Marko <robimarko@gmail.com>
The file contains the the /usr/lib path from the toolchain directory and
not from the target directory. The /usr/lib directory for the toolchain
is empty and the shared library is not in the specified paths. On RISCV
the linker of util-linux was finding the libncursesw.so in my host
system, tried to link against it and failed. Fix the .pc file.
Fixes: #15942
Co-authored-by: Thomas Weißschuh <thomas@t-8ch.de>
Link: https://github.com/openwrt/openwrt/pull/16018
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 91573ac145)
Link: https://github.com/openwrt/openwrt/pull/16390
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This updates mac80211 to version 6.1.110-1. This code is based on Linux
6.1.110 and contains all fixes included in the upstream wireless
subsystem from that kernel version. This includes many bugfixes and also
some security fixes.
The removed patches are already integrated in upstream Linux 6.1.110.
The following patches were integrated in upstream Linux:
subsys/311-v6.2-wifi-mac80211-fix-and-simplify-unencrypted-drop-chec.patch
subsys/312-v6.3-wifi-cfg80211-move-A-MSDU-check-in-ieee80211_data_to.patch
subsys/313-v6.3-wifi-cfg80211-factor-out-bridge-tunnel-RFC1042-heade.patch
subsys/314-v6.3-wifi-mac80211-remove-mesh-forwarding-congestion-chec.patch
subsys/315-v6.3-wifi-mac80211-fix-receiving-A-MSDU-frames-on-mesh-in.patch
subsys/316-v6.3-wifi-mac80211-add-a-workaround-for-receiving-non-sta.patch
subsys/321-mac80211-fix-mesh-forwarding.patch
subsys/322-wifi-mac80211-fix-mesh-path-discovery-based-on-unica.patch
subsys/329-wifi-mac80211-fix-receiving-mesh-packets-in-forwardi.patch
subsys/339-wifi-cfg80211-fix-receving-mesh-packets-without-RFC1.patch
subsys/350-v6.3-wifi-mac80211-Allow-NSS-change-only-up-to-capability.patch
subsys/351-v6.9-wifi-mac80211-track-capability-opmode-NSS-separately.patch
Link: https://github.com/openwrt/openwrt/pull/16368
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
OpenSSL 3.0.15 is a security patch release. The most severe CVE fixed in this release is Moderate.
This release incorporates the following bug fixes and mitigations:
* Fixed possible denial of service in X.509 name checks (CVE-2024-6119)
* Fixed possible buffer overread in SSL_select_next_proto() (CVE-2024-5535)
Added github releases url as source mirror
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16332
(cherry picked from commit 62d3773bf1)
Link: https://github.com/openwrt/openwrt/pull/16346
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This contains a fix for:
CVE-2024-45157:
Unlike previously documented, enabling MBEDTLS_PSA_HMAC_DRBG_MD_TYPE does
not cause the PSA subsystem to use HMAC_DRBG: it uses HMAC_DRBG only when
MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG and MBEDTLS_CTR_DRBG_C are disabled.
Link: https://github.com/openwrt/openwrt/pull/16367
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The path for linking libucode.so was not specified for the ucode binary.
This breaks execution of ucode in the host context.
Signed-off-by: David Bauer <david.bauer@uniberg.com>
(cherry picked from commit ae42ecaad4)
Empty trailing fields get lost when the lines are split and merged again
at colons, resulting in unparsable entries. Only use the split fields for
matching against the other file, but emit the original line unchanged
to fix the issue.
Fixes: de7ca7dafa ("base-files: merge /etc/passwd et al at sysupgrade config restore")
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
(cherry picked from commit 9bbaa6f2c0)
This patch fixes the list delimiter between 3GPP networks
passed to hostapd.
> list iw_anqp_3gpp_cell_net '262,001'
> list iw_anqp_3gpp_cell_net '262,002'
When passing a list of "iw_anqp_3gpp_cell_net" parameters via UCI,
hostapd would crash at startup:
> daemon.err hostapd: Line 73: Invalid anqp_3gpp_cell_net: 262,001:262,002
Using a semicolon as a delimiter, hostapd will start as expected.
Signed-off-by: Sarah Maedel <git@tbspace.de>
(cherry picked from commit 8de185a176)
Like other Ethernet drivers, print link speed and duplex mode
when the interface is up. Formatting output at the same time.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
(cherry picked from 5d2a008670)
Like other Ethernet drivers, print link speed and duplex mode
when the interface is up. Formatting output at the same time.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
(cherry picked from a57a3e5cc5)
Like other Ethernet drivers, print link speed and duplex mode
when the interface is up. Formatting output at the same time.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
(cherry picked from 2f846a3315)
Like other Ethernet drivers, print link speed and duplex mode
when the interface is up. Formatting output at the same time.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from fe0240f27e)
This log is noisy and useless, just ignore it.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
(cherry picked from 8d9893ff34)
This log is noisy and useless, just ignore it.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
(cherry picked from 2fd0102cc3)
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: Milinda Brantini <C_A_T_T_E_R_Y@outlook.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from bfeef9b3d7)
r8126 is an out of tree driver provided by Realtek for RTL8126 devices.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from 54623c6a1d)
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: Milinda Brantini <C_A_T_T_E_R_Y@outlook.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from f063f4620c)
r8125 is an out of tree driver provided by Realtek for RTL8125 devices.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from ddb4070c96)
r8168 is an out of tree driver provided by Realtek for RTL8168 devices.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
((cherry picked from commit 1565eeda4e)
r8101 is an out of tree driver provided by Realtek for RTL8101 devices.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit b72c4b5386)
Sometimes the mmc deivce may come up later than kernel attempts to
mount rootfs, resulting kernel panic. Enable rootwait to fix it.
Reported-by: Yangyu Chen <cyy@cyyself.name>
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Link: https://github.com/openwrt/openwrt/pull/15077
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The vendor U-Boot implementaion on Telenor branded ZyXEL EX5700
devices does not store its environment on flash. It is instead
kept in a memory region. This is persistent over reboots, but
not over power cycling.
The dual partition failsafe system used by the vendor U-Boot
requires the OS to modify a variable in this memory environment.
This driver allows the ordinary uboot-envtools to access a
memory region like it was a partition on NOR flash.
The specific vendor U-Boot adds a "no-map" /reserved-memory
section and a top level /ubootenv node pointing to the memory
environment. The driver uses this device specific fact to
locate the region. The matching and probing code will likely
have to be adjusted for any other devices to be supported.
Example partial device tree:
/ {
..
ubootenv {
memory-region = <&uenv>;
compatible = "ubootenv";
};
..
reserved-memory {
..
uenv: ubootenv@7ffe8000 {
no-map;
reg = <0 0x7ffe8000 0 0x4000>;
};
Signed-off-by: Bjørn Mork <bjorn@mork.no>
(cherry picked from commit b2e810f495)
This patch backports fixes for a security vulnerability impacting the
hostapd implementation of SAE H2E.
As upgrading hostapd would require more testing, the second mitigation
step which involves backporting several patches was adopted as outlined
in the official advisory[1].
An explanation of the impact of the vulnerability is provided from the
advisory[1]:
This vulnerability allows the attacker to downgrade the negotiated group
to another enabled group if both the AP and STA have enabled SAE H2E and
multiple groups. It should be noted that the H2E option is not enabled
by default and the attack is not applicable to the default option, i.e.,
hunting-and-pecking, since it does not have any downgrade protection for
group negotiation. In addition, the default configuration for enabled
SAE groups in hostapd is to enable only a single group, so the
vulnerability is not applicable unless hostapd has been explicitly
configured to enable more groups for SAE.
[1]: https://w1.fi/security/2024-2/sae-h2h-and-incomplete-downgrade-protection-for-group-negotiation.txt
Signed-off-by: Rany Hany <rany_hany@riseup.net>
Link: https://github.com/openwrt/openwrt/pull/16043
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit db7f70fe61)
Upstream removed SSB and BCMA, the drivers are now compiled against the
in kernel versions. No need to patch this for OpenWrt.
Link: https://github.com/openwrt/openwrt/pull/15983
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Backport 2 patches from upstream Linux to fix a Wifi throughput
problem.
Fixes: 323e249ce8 ("mac80211: Update to version 6.1.97-1")
Link: https://github.com/openwrt/openwrt/pull/16007
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This fixes multiple security problems:
* [Medium] CVE-2024-1544
Potential ECDSA nonce side channel attack in versions of wolfSSL before 5.6.6 with wc_ecc_sign_hash calls.
* [Medium] CVE-2024-5288
A private key blinding operation, enabled by defining the macro WOLFSSL_BLIND_PRIVATE_KEY, was added to mitigate a potential row hammer attack on ECC operations.
* [Low] When parsing a provided maliciously crafted certificate directly using wolfSSL API, outside of a TLS connection, a certificate with an excessively large number of extensions could lead to a potential DoS.
* [Low] CVE-2024-5991
In the function MatchDomainName(), input param str is treated as a NULL terminated string despite being user provided and unchecked.
* [Medium] CVE-2024-5814
A malicious TLS1.2 server can force a TLS1.3 client with downgrade capability to use a ciphersuite that it did not agree to and achieve a successful connection.
* [Medium] OCSP stapling version 2 response verification bypass issue when a crafted response of length 0 is received.
* [Medium] OCSP stapling version 2 revocation bypass with a retry of a TLS connection attempt.
Unset DISABLE_NLS to prevent setting the unsupported configuration
option --disable-nls which breaks the build now.
Link: https://github.com/openwrt/openwrt/pull/15948
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit 3a0232ffd3)
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>
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)
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)
increase size of ifmsh->mbss_changed
Signed-off-by: Felix Fietkau <nbd@nbd.name>
(cherry picked from commit 20bd3502d3)
Link: https://github.com/openwrt/openwrt/pull/15836
[Moved the patch to the end of the patch queue]
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Where it is clear which lincense the firmware package has, the missing
information are added.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [backport]
(cherry picked from commit 535d487c41)
Link: https://github.com/openwrt/openwrt/pull/15918
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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>
The lincense information for the packages mac80211 are missing.
This commit adds the missing information.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [backport]
(cherry picked from commit 3128157ec7)
Link: https://github.com/openwrt/openwrt/pull/15918
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The package has no licence information. So let's fix it.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
(cherry picked from commit 0da116f25b)
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>
