PKG_MIRROR_HASH is incorrect and the package check is currently failing.
Fixes: 4990ce613b7d ("ipq-wifi: update to 2024-02-17")
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Add support for the Intel E800 series of cards, with switchdev
support enabled for lower CPU usage.
Signed-off-by: Stephen Howell <howels@allthatwemight.be>
Link: https://github.com/openwrt/openwrt/pull/17564
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This service automatically establishes connections to any hosts that are members
of the same unet network, and allows publish/subscribe exchanges via ubus channels.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This is useful for keeping specific data on a device across factory reset.
It uses a separate partition (only UBI supported at the moment) to store
the data. The primary use case is storing sensitive data like cryptographic
keys for maintaining a device as part of a network.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This does not actually create a new private key. Instead, the salt is replaced,
and a xor key is generated which when merged with the key derived from the new
password transforms into the original private key.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
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: 42eeb22450f2 ("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>
Sets the boot flag for the i40e network device driver
to load it at a more early stage of the boot process.
With commit 0a47d518df0d758e8d3b31264cb0428d57c362c3,
I added a boot priority for the mlx4 and mlx5 drivers.
Also, increase those priorities because I think they
are too low since there is currently no "room" for
built-in network device drivers.
That can cause interface order, i.e., name inconsistencies,
when Mellanox ConnectX cards are inserted or removed.
Signed-off-by: Til Kaiser <mail@tk154.de>
Link: https://github.com/openwrt/openwrt/pull/17990
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
ZTE MF286 is an indoor LTE category 12 CPE router with simultaneous
dual-band 802.11ac plus 802.11n Wi-Fi radios and quad-port gigabit
Ethernet switch, FXS and external USB 2.0 port.
Software-wise it's compatible with previous MF286A, save for different
5GHz Wi-Fi board definition file, requiring a separate image.
Hardware highlights:
- CPU: QCA9563 SoC at 775MHz,
- RAM: 128MB DDR2,
- NOR Flash: MX25L1606E 2MB SPI Flash, for U-boot only,
- NAND Flash: W25N01GV 128MB SPI NAND-Flash, for all other data,
- Wi-Fi 5GHz: QCA9886 2x2 MIMO 802.11ac Wave2 radio,
- WI-Fi 2.4GHz: QCA9563 3x3 MIMO 802.11n radio,
- Switch: QCA8337v2 4-port gigabit Ethernet, with single SGMII CPU port,
- WWAN: MDM9250-based category 12 internal LTE modem
in extended mini-PCIE form factor, with 5 internal antennas and
2 external antenna connections, single mini-SIM slot.
- FXS: one external ATA port (handled entirely by modem part) with two
physical connections in parallel,
- USB: Single external USB 2.0 port,
- Switches: power switch, WPS, Wi-Fi and reset buttons,
- LEDs: Wi-Fi, Test (internal). Rest of LEDs (Phone, WWAN, Battery,
Signal state) handled entirely by modem. 4 link status LEDs handled by
the switch on the backside.
- Label MAC device: eth0
Internal modem of MF286C is supported via uqmi.
Console connection: connector X2 is the console port, with the following
pinout, starting from pin 1, which is the topmost pin when the board is
upright:
- VCC (3.3V). Do not use unless you need to source power for the
converer from it.
- TX
- RX
- GND
Default port configuration in U-boot as well as in stock firmware is
115200-8-N-1.
Installation:
Due to different flash layout from stock firmware, sysupgrade from
within stock firmware is impossible, despite it's based on QSDK which
itself is based on OpenWrt.
STEP 0: Stock firmware update:
As installing OpenWrt cuts you off from official firmware updates for
the modem part, it is recommended to update the stock firmware to latest
ath79: support ZTE MF286C
STEP 1: Booting initramfs image:
Method 1: using serial console (RECOMMENDED):
- Have TFTP server running, exposing the OpenWrt initramfs image, and
set your computer's IP address as 192.168.0.22. This is the default
expected by U-boot. You may wish to change that, and alter later
commands accordingly.
- Connect the serial console if you haven't done so already,
- Interrupt boot sequence by pressing any key in U-boot when prompted
- Use the following commands to boot OpenWrt initramfs through TFTP:
setenv serverip 192.168.0.22
setenv ipaddr 192.168.0.1
tftpboot 0x81000000 openwrt-ath79-nand-zte_mf286c-initramfs-kernel.bin
bootm 0x81000000
(Replace server IP and router IP as needed). There is no emergency
TFTP boot sequence triggered by buttons, contrary to MF283+.
- When OpenWrt initramfs finishes booting, proceed to actual
installation.
STEP 2: Backing up original software:
As the stock firmware may be customized by the carrier and is not
officially available in the Internet, IT IS IMPERATIVE to back up the
stock firmware, if you ever plan to returning to stock firmware.
It is highly recommended to perform backup using both methods, to avoid
hassle of reassembling firmware images in future, if a restore is
needed.
Method 1: after booting OpenWrt initramfs image via TFTP:
- Connect your USB-UART adapter
- Dump stock firmware located on stock kernel and ubi partitions:
ssh root@192.168.1.1: cat /dev/mtd9 > mtd3_ubiconcat0.bin
ssh root@192.168.1.1: cat /dev/mtd4 > mtd4_kernel.bin
ssh root@192.168.1.1: cat /dev/mtd9 > mtd5_ubiconcat1.bin
And keep them in a safe place, should a restore be needed in future.
Method 2: using stock firmware:
- Connect an external USB drive formatted with FAT or ext4 to the USB
port.
- The drive will be auto-mounted to /var/usb_disk
- Check the flash layout of the device:
cat /proc/mtd
It should show the following:
mtd0: 000a0000 00010000 "u-boot"
mtd1: 00020000 00010000 "u-boot-env"
mtd2: 00140000 00010000 "reserved1"
mtd3: 000a0000 00020000 "fota-flag"
mtd4: 00080000 00020000 "art"
mtd5: 00080000 00020000 "mac"
mtd6: 000c0000 00020000 "reserved2"
mtd7: 00400000 00020000 "cfg-param"
mtd8: 00400000 00020000 "log"
mtd9: 000a0000 00020000 "oops"
mtd10: 00500000 00020000 "reserved3"
mtd11: 00800000 00020000 "web"
mtd12: 00300000 00020000 "kernel"
mtd13: 01a00000 00020000 "rootfs"
mtd14: 01900000 00020000 "data"
mtd15: 03200000 00020000 "fota"
mtd16: 01d00000 00020000 "firmware"
Differences might indicate that this is NOT a MF286C device but
one of other variants.
- Copy over all MTD partitions, for example by executing the following:
for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do cat /dev/mtd$i > \
/var/usb_disk/mtd$i; done
"Firmware" partition can be skipped, it is a concatenation
of "kernel" and "rootfs".
- If the count of MTD partitions is different, this might indicate that
this is not a MF286C device, but one of its other variants.
- (optionally) rename the files according to MTD partition names from
/proc/mtd
- Unmount the filesystem:
umount /var/usb_disk; sync
and then remove the drive.
- Store the files in safe place if you ever plan to return to stock
firmware. This is especially important, because stock firmware for
this device is not available officially, and is usually customized by
the mobile providers.
STEP 3: Actual installation:
- Set your computer IP to 192.168.1.22/24
- scp the sysupgrade image to the device:
scp -O openwrt-ath79-nand-zte_mf286a-squashfs-sysupgrade.bin \
root@192.168.1.1:/tmp/
- ssh into the device and execute sysupgrade:
sysupgrade -n /tmp/openwrt-ath79-nand-zte_mf286a-squashfs-sysupgrade.bin
- Wait for router to reboot to full OpenWrt.
STEP 4: WAN connection establishment
Since the router is equipped with LTE modem as its main WAN interface, it
might be useful to connect to the Internet right away after
installation. To do so, please put the following entries in
/etc/config/network, replacing the specific configuration entries with
one needed for your ISP:
config interface 'wan'
option proto 'qmi'
option device '/dev/cdc-wdm0'
option auth '<auth>' # As required, usually 'none'
option pincode '<pin>' # If required by SIM
option apn '<apn>' # As required by ISP
option pdptype '<pdp>' # Typically 'ipv4', or 'ipv4v6' or 'ipv6'
For example, the following works for most polish ISPs
config interface 'wan'
option proto 'qmi'
option device '/dev/cdc-wdm0'
option auth 'none'
option apn 'internet'
option pdptype 'ipv4'
The required minimum is:
config interface 'wan'
option proto 'qmi'
option device '/dev/cdc-wdm0'
In this case, the modem will use last configured APN from stock
firmware - this should work out of the box, unless your SIM requires
PIN which can't be switched off.
If you have build with LuCI, installing luci-proto-qmi helps with this
task.
Restoring the stock firmware:
- Boot to initramfs as in step 3:
- Completely detach ubi0 partition using ubidetach /dev/ubi0_0
- Copy over the stock kernel image using scp to /tmp
- Erase kernel and restore stock kernel:
(scp mtd4_kernel.bin root@192.168.1.1:/tmp/)
mtd write kernel /tmp/mtd4_kernel.bin
rm /tmp/mtd4_kernel.bin
- Copy over the stock partition backups one-by-one using scp to /tmp, and
restore them individually. Otherwise you might run out of space in
tmpfs:
(scp -O mtd3_ubiconcat0.bin root@192.168.1.1:/tmp/)
mtd write ubiconcat0 /tmp/mtd3_ubiconcat0.bin
rm /tmp/mtd3_ubiconcat0.bin
(scp -O mtd5_ubiconcat1.bin root@192.168.1.1:/tmp/)
mtd write ubiconcat1 /tmp/mtd5_ubiconcat1.bin
rm /tmp/mtd5_ubiconcat1.bin
- If the write was correct, force a device reboot with
reboot -f
Quirks and known issues
- It was observed, that CH340-based USB-UART converters output garbage
during U-boot phase of system boot. At least CP2102 is known to work
properly.
- Kernel partition size is increased to 4MB compared to stock 3MB, to
accomodate future kernel updates - at this moment OpenWrt 5.10 kernel
image is at 2.5MB which is dangerously close to the limit. This has no
effect on booting the system - but keep that in mind when reassembling
an image to restore stock firmware.
- uqmi seems to be unable to change APN manually, so please use the one
you used before in stock firmware first. If you need to change it,
please use protocok '3g' to establish connection once, or use the
following command to change APN (and optionally IP type) manually:
echo -ne 'AT+CGDCONT=1,"IP","<apn>' > /dev/ttyUSB0
- The only usable LED as a "system LED" is the blue debug LED hidden
inside the case. All other LEDs are controlled by modem, on which the
router part has some influence only on Wi-Fi LED.
- GPIO5 used for modem reset is a suicide switch, causing a hardware
reset of whole board, not only the modem. It is attached to
gpio-restart driver, to restart the modem on reboot as well, to ensure
QMI connectivity after reboot, which tends to fail otherwise.
- Modem, as in MF283+, exposes root shell over ADB - while not needed
for OpenWrt operation at all - have fun lurking around.
The same modem module is used as in older MF286.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17620
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
PKG_MIRROR_HASH is incorrect and fails the download from mirrors.
Fixes: 0aaabffdea2c ("selinux-policy: update to version v2.6")
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
The CONFIG_NET_SWITCHDEV option is needed by CONFIG_DSA and some other
options. It is boolean, we have to compile it into the kernel it self.
Activate it for all targets in the generic configuration, it is already
activated for most of them. This allows to install DSA drivers as a
module.
On the ramips/mt7620 target the kernel would grown by 4.5kB.
For some small targets which do not support a DSA switch by default the
option is deactivated.
Link: https://github.com/openwrt/openwrt/pull/17668
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This has several advantages:
* reduction in the size of the kernel and the complete image. Individual
devices only need two of the four binaries. In combination with the second
commit it reduces kernel size by 64.2 kB and image size by 22.8 kB,
* the option to extend this package with firmware for future SoCs,
* combining the kernel and binary blobs with another licence may not be
fully compatible with the licence used by Linux. The current PHY firmware
is built into the kernel. This comit converts it to a package.
Tested on AVM 5490 and BT Home Hub 5A.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Link: https://github.com/openwrt/openwrt/pull/17669
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Zyxel LTE7490-M904 is an 802.3at PoE powered LTE outdoor (IP68) CPE
with integrated directional antennas.
Specifications:
- SoC: MediaTek MT7621AT
- RAM: 256 MB
- Flash: 128 MB MB NAND (MX30LF1G18AC)
- WiFi: MediaTek MT7603E 802.11b/g/n
- Switch: 1 LAN port (1 Gbps)
- LTE/3G/2G: Quectel EG18-EA LTE-A Cat. 18 connected by USB3 to SoC
- SIM: 1 micro-SIM slots under transparent cover
- Buttons: Reset, WLAN under same cover
- LEDs: Multicolour green/red/amber under same cover (visible)
- Power: 802.3at PoE via LAN port
The device is built as an outdoor ethernet to LTE bridge or router.
The wifi interface is intended for installation and/or temporary
management purposes only.
UART Serial:
57600N1, located on populated 5 pin header J5:
[o] GND
[ ] key - no pin
[o] RX
[o] TX
[o] 3.3V Vcc
Remove the SIM/button/LED cover and 12 screws holding the back plate
and antenna cover together. Be careful with the cables.
Installation from OEM web GUI:
- Log in as "admin" on OEM web GUI
- Upload OpenWrt initramfs-recovery.bin image on the
Maintenance -> Firmware page
- Wait for OpenWrt to boot and ssh to root@192.168.1.1
- Sysupgrade to the OpenWrt sysupgrade image and reboot
For more details about flashing see:
2449a63208 (ramips: mt7621: Add support for ZyXEL NR7101, 2021-04-19)
Main porting work done by Ernesto Castellotti <ernesto@castellotti.net>:
bf1c12f68b (ramips: add support for ZyXEL LTE7490-M904, 2023-12-20)
Signed-off-by: Eric Schäfer <eric@es86.de>
Link: https://github.com/openwrt/openwrt/pull/17485
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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>
Add support for Genexis Pulse EX400 / Inteno Pulse EX400. A branded
variant for the Finnish ISP DNA has already been added in fea2264d9fdd
(ramips: mt7621: Add DNA Valokuitu Plus EX400, 2023-07-31). This commit
adds support for the generic variants with Inteno and Genexis branding.
Inteno changed its name to Genexis and both brandings exist.
In terms of electronics, there is no difference between the DNA-branded
version and other brandings. LED markings on the case are different,
though. While the DNA-version has a "software-update" LED, the other
versions have a WPS LED. To reduce user confusion, create a separate
image.
Add the different device-tree with the different LED and rename things
to work the same way for both variants.
Specifications:
- Device: Genexis Pulse EX400 / Inteno Pulse EX400
- SoC: MT7621A
- Flash: 256 MB NAND
- RAM: 256 MB
- Ethernet: Built-in, 2 x 1 GbE
- Wifi: MT7603 2.4 GHz 2x2 MIMO, MT7615 5 GHz 4x4 MU-MIMO
- USB: 1x 2.0
- LEDs (GPIO): green/red status, green WPS
- LEDs (SX9512, unsupported): Broadband, Wi-Fi 2.4G, Wi-Fi 5G
- Buttons (GPIO): Reset
- Buttons (SX9512, unsupported): Wi-Fi 2.4G, Wi-Fi 5G, WPS
MAC addresses:
- LAN: U-Boot 'ethaddr' (label)
- WAN: label + 1
- 2.4 GHz: label + 6
- 5 GHz: label + 7
Serial:
There is a black block connector next to the red ethernet connector. It
is accessible also through holes in the casing.
Pinout (TTL 3.3V)
+---+---+
|Tx |Rx |
+---+---+
|Vcc|Gnd|
+---+---+
Firmware:
The vendor firmware is a fork of OpenWrt (Reboot) with a kernel version
4.4.93. The flash is arranged as below and there is a dual boot
mechanism alternating between rootfs_0 and rootfs_1.
+-------+------+------+-----------+-----------+
| | env1 | env2 | rootfs_0 | rootfs_1 |
| +------+------+-----------+-----------+
| | UBI volumes |
+-------+-------------------------------------+
|U-Boot | UBI |
+-------+-------------------------------------+
|mtd0 | mtd1 |
+-------+-------------------------------------+
| NAND |
+---------------------------------------------+
In OpenWrt rootfs_0 will be used as a boot partition that will contain the
kernel and the dtb. The squashfs rootfs and overlay are standard OpenWrt
behaviour.
+-------+------+------+-----------+--------+------------+
| | env1 | env2 | rootfs_0 | rootfs | rootfs_data|
| +------+------+-----------+--------+------------+
| | UBI volumes |
+-------+-----------------------------------------------+
|U-Boot | UBI |
+-------+-----------------------------------------------+
|mtd0 | mtd1 |
+-------+-----------------------------------------------+
| NAND |
+-------------------------------------------------------+
U-boot:
With proper serial access, booting can be halted to U-boot by pressing
any key. TFTP and flash writes are available, but only the first one has
been tested.
NOTE: Recovery mode can be accessed by holding down the reset button while
powering on the device. The led 'Update' will show a solid green light
once ready. A web server will be running at 192.168.1.1:80 and it will
allow flashing a firmware package. You can cycle between rootfs_0 and
rootfs_1 by pressing the reset button once.
Root password:
With the vendor web UI create a backup of your settings and download the
archive to your computer. Within the archive in the file
/etc/shadow replace the password hash for root with that of a password you
know. Restore the configuration with the vendor web UI and you will have
changed the root password.
SSH access:
You might need to enable the SSH service for LAN interface as by default
it's enabled for WAN only.
Installing OpenWrt:
With the vendor web UI, or from the U-Boot recovery UI, install the
OpenWrt factory image. Alternatively, ssh to the device and use
sysupgrade -n from cli.
Finalize by installing the OpenWrt sysupgrade image to get a fully
functioning system.
Reverting to the vendor firmware:
Boot with OpenWrt initramfs image
- Remove volumes rootfs_0, rootfs and rootfs_data and create vendor
volumes.
ubirmvol /dev/ubi0 -n 2
ubirmvol /dev/ubi0 -n 3
ubirmvol /dev/ubi0 -n 4
ubimkvol /dev/ubi0 -N rootfs_0 -S 990
ubimkvol /dev/ubi0 -N rootfs_1 -S 990
Power off and enter to the U-boot recovery to install the vendor
firmware.
Signed-off-by: Andreas Gnau <andreas.gnau@iopsys.eu>
Link: https://github.com/openwrt/openwrt/pull/17551
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently, logging level of the RADIUS server is a constant corresponding
to the highest verbosity (EXCESSIVE, ALL), but when running as a system
service, the output is discarded.
This commit makes logging verbosity configurable by `log_level` option
and redirects all logs to `logd`. Possible levels are defined in hostap
sources:
https://w1.fi/cgit/hostap/tree/src/utils/wpa_debug.h?id=012a893c469157d5734f6f33953497ea6e3b0169#n23
Their reference is inlined in `radius.config` file.
Default value for logging verbosity is INFO (even if the `-l` flag isn't
specified).
Signed-off-by: Dávid Benko <davidbenko@davidbenko.dev>
Link: https://github.com/openwrt/openwrt/pull/18089
Signed-off-by: Robert Marko <robimarko@gmail.com>
Even though IPv6 support for hostapd RADIUS server is implemented
(flag `-6`), it's not possible to enable it from configuration.
This commit adds this option and adapts init script.
Signed-off-by: Dávid Benko <davidbenko@davidbenko.dev>
Link: https://github.com/openwrt/openwrt/pull/18089
Signed-off-by: Robert Marko <robimarko@gmail.com>
Changes:
c7edc38f libnl-3.11.0 release
b75e27de lib/route: add support for bridge msti
8a73b245 lib/route: add support for bridge info boolopts
3b284a11 lib/route: extend bridge info support
a43a41cd lib/route: add missing bridge info getter functions
756d5161 lib/route: add missing entry in libnl-route-3.sym file
014c33a6 lib/route: add rtnl_neigh ext flags support
acf572b5 route: add support for getting permanent mac address of link
afafe78a lib/route: extend bridge flags
11597b73 xfrm: remove redundant check in xfrm_sa_update_cache()
2abfb089 xfrm: use the new _nl_auto_nl_object helper
831e9868 cache: use the new _nl_auto_nl_object helper
4b9daa6d add _nl_auto_nl_object helper
379a1405 black: fix "target-version" in "pyproject.toml"
8460c9b7 link/bonding: implement parsing link type
d60535c9 link/bonding: implement comparing bond links
22b6cf5c link/bonding: implement io_clone()
e1c75bff link/bonding: add getters for attributes
ee4612ca link/bonding: rename bn_mask to ce_mask
81c40cbb tests: optimize _nltst_assert_route_list_permutate() to short cut search through permutations
9f5fac78 tests: in _nltst_assert_route_list() accept arbitrary order
01f06b57 base: add _nl_swap() helper macro
5b570259 tests: ensure that there are all expected routes in _nltst_assert_route_list()
1aa16ea9 tests: print route list before failure in _nltst_assert_route_list()
7f099cf0 tests: add _nltst_objects_to_string() helper
e76d5697 tests: add _nltst_malloc0() and _nltst_sprintf() helpers
d94a3e81 tests: move definition of asserts in "tests/nl-test-util.h"
798278ea tests: use _nl_ptrarray_len() helper in _nltst_assert_route_list()
def89a2c base: add _nl_ptrarray_len() helper
64fad14b link: link_msg_parser(): keep link info instead of release and reacquire
b8d3cfb2 lib/attr: add nla functions for variable-length integers
2ae88c48 lib/attr: add NLA_{SINT|UINT} attribute types
Link: https://github.com/openwrt/openwrt/pull/18193
Signed-off-by: Nick Hainke <vincent@systemli.org>
It doesn't depend on either usb-net or usb-net-cdc-ncm. It does, however, depend
on mii. Fix thusly, and make it depend explicitly on usb, not usb-net.
While at it, add a conditional dependency on libphy, for future kernel versions.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Now that CONFIG_USB_NET_DRIVERS is unconditionally enabled, remove it from the
usb-net kconfig symbol list.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
This is an industrial 4G router equipped with OpenWrt 14.07 OEM
customized version
WARNING: The original firmware device tree is common to multiple
boards, and the device tree name is H9350. This submitted device
tree is a modified version, which deletes the non-this-device parts
and adds GPIO watchdog.
Specification:
- SoC: MediaTek MT7620A
- Flash: 16 MB
- RAM: 128 MB
- Power: DC 5V-36V 1.5A
- Ethernet: 1x WAN, 4x LAN (10/100 Mbps)
- Wireless radio: 802.11n 2.4g-only
- LED:
System/Power (RUN): GPIO/26 active-low
Ethernet: 1x WAN, 4x LAN
Modem 1: GPIO/66 active-low
RF 1 (Modem 1 Signal): GPIO/67 active-low
Modem 2: GPIO 71 active-low
RF 2 (Modem 2 Signal): GPIO/24 active-low
WLAN: GPIO/72 active-low
WPS: GPIO/12 active-low
- Button:
WPS / RESET: GPIO/34 active-low
- UART: 1x UART on PCB - 115200 8N1
- GPIO Watchdog: GPIO/62 mode=toggle timeout=1s
- PCIe: 2x miniPCIe for modem
- SIM Slots: 2x SIM Slots
Issue:
- No factory partition, eeprom is located
at /lib/firmware/mt7620a.eeprom
Flash instruction:
Using UART:
1. Configure PC with a static IP address and setup an TFTP server.
2. Put rootfs into the tftp directory.
3. Connect the UART line as described on the PCB.
4. Power up the device and press Ctrl+C to break auto boot.
5. Use `system 6` command and follow the instruction to set device
and tftp server IP address and input the rootfs file name.
U-boot will then load the rootfs and write it into
the flash.
6. Use `system 1` command and follow the instruction to set device
and tftp server IP address and input the firmware file name.
U-boot will then load the firmware once.
7. Login to LuCI and use LuCI upgrade firmware.
Original Firmware Dump / More details:
https://blog.gov.cooking/archives/research-hongdian-h8922-and-flash.html
Signed-off-by: Coia Prant <coiaprant@gmail.com>
Tested-by: Coia Prant <coiaprant@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17472
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The kmod-mlxsw-spectrum driver activated CONFIG_DCB indirectly already
on all targets which are building this driver. All other DCB capable
driver did not activate their DCB support.
CONFIG_DCB increases the uncompressed kernel size by about 7.8KB.
CONFIG_DCB is only needed some data center Ethernet cards and not used
on normal routers. Activate it only on the x86_64 and the armsr_arm64
target which are used on normal servers or in VMs.
Link: https://github.com/openwrt/openwrt/pull/17672
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
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>
This board is also as known as SuperElectron ZN-M5 and ZN-M8. However,
for ZN-M5 and ZN-M8, there's another version uses ZX279128 as CPU
chip, which is unsupported.
You can check it in "高级设置" > "系统日志" > "内核日志" page from webUI.
Hardware specification:
SoC: MediaTek MT7981B 2x A53
Flash: 128 MB SPI-NAND
RAM: 256MB
Ethernet: 4x 10/100/1000 Mbps
Switch: MediaTek MT7531AE
WiFi: MediaTek MT7976C
Button: Reset, WPS
Power: DC 12V 1A
Stock layout flash instructions:
Login into webUI and upload sysupgrade firmware in "系统管理" > "升级固件" page.
Remember to unselect "保留配置" ("Keep configurations") first before doing that.
OpenWrt U-Boot layout flash instructions:
1. Flash stock layout firmware first.
2. Connect to the device via SSH, and backup everything,
especially 'Factory' partition.
3. Unlock MTD partitions:
apk update && apk add kmod-mtd-rw
insmod mtd-rw i_want_a_brick=1
4. Write new BL2 and FIP:
mtd write openwrt-mediatek-filogic-cmcc_a10-ubootmod-preloader.bin BL2
mtd write openwrt-mediatek-filogic-cmcc_a10-ubootmod-bl31-uboot.fip FIP
5. Set static IP on your PC:
IP 192.168.1.254/24, GW 192.168.1.1
6. Serve OpenWrt initramfs image using TFTP server.
7. Cut off the power and re-engage, wait for TFTP recovery to complete.
8. After OpenWrt has booted, perform sysupgrade.
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Link: https://github.com/openwrt/openwrt/pull/18121
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
