The PPE driver registers its DSA switch, and with it attaches every user
port's PHY, before the root filesystem is mounted. A PHY driver that is
only available as a module therefore always loses the race:
phy_attach_direct() finds no matching driver, falls back to genphy_c45
and binds it with device_bind_driver(), and nothing rebinds the PHY when
the real driver shows up later.
On the boards with an Aquantia 10G PHY that leaves the AQR running under
the generic Clause 45 driver. It never loads its firmware, from the nvmem
cell or otherwise, and its system interface is never configured, so the
10G port does not pass traffic. Boards that provision the firmware from
flash have therefore never had that path execute at all.
The driver was built in until commit 8c3bcc198936 ("ipq807x: move AQR
driver from built-in to kmod"), which made it a module so that
IS_REACHABLE(CONFIG_HWMON) would evaluate true and the temperature
sensors in the AQR would be usable as thermal zones. That was correct at
the time: the ethernet driver then attached PHYs from userspace, so a
module was in place early enough, and hwmon was not built in.
Neither still holds. HWMON is compiled in on this target, so building the
PHY driver in keeps its hwmon support, and the PPE driver attaches PHYs
from its own probe. Build it in, as is already done for the AT803X and
QCA807X PHYs here.
CRC_ITU_T, which the driver selects for the firmware image
checksum, follows it from module to built-in.
Both symbols go in the ipq807x and ipq60xx config-default rather than
the target's per-kernel config. Every board with an AQR is on one of
those two subtargets and ipq50xx has none, and a subtarget's
config-default is merged for whichever kernel version the target
builds, so the 6.18 kernel picks them up as well.
kmod-phy-aquantia goes with it. The package builds empty once the symbol
is built in, because KernelPackage/install skips a module listed in
modules.builtin, but ModuleAutoLoad still runs and would ship
/etc/modules.d/18-phy-aquantia naming a module that no longer exists.
Drop it from the subtarget defaults and from the one ipq60xx device
that listed it, matching AT803X_PHY and QCA807X_PHY which carry no
kmod on this target.
Reported-by: Rye Sears <xlighting2017@users.noreply.github.com>
Tested-by: Rye Sears <xlighting2017@users.noreply.github.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24420
Signed-off-by: Robert Marko <robimarko@gmail.com>
The existing interrupt handling of the ethernet driver worked
well until the driver implemented receive fragment handling.
This change uncovered a constellation that did not exist before.
A received packet is written into the page pool with multiple
fragments. On RTL93xx the head-of-line (HOL) feature limits
the number of receivable fragments perfectly. There will never
be a "buffer full" situation where the hardware only encounters
ring buffers that are held by the Linux kernel. On RTL83xx
this is slightly different:
- The driver programs free floating rings
- Only the ownership flag of the ring buffer decides if the
hardware can hand over a packet to the CPU.
- So the hardware can receive a packet even if it does not
completely fit into the available fragments.
With this there is a small chance that
- The buffer has less space than a just received packet
- The hardware generates an overflow (RUN OUT) interrupt
- With no completely received packet the hardware DOES NOT
generate a receive (DONE) interrupt.
So it is not sufficient to just look on the DONE interrupts.
The RUN OUT interrupts must be inspected as well. As the
current logic is quite cryptic enhance this as follows:
- Provide new RTL83xx/RTL93xx specific helpers
- Add new callbacks to the driver configuration structure
- Link the configuration with the new helpers
- Use the callbacks where needed.
While we are here:
- Enable only interrupts for active receive rings. Until
now the driver activated all receive interrupts (8/32)
although it supports only 2 rings.
- Use DIV_ROUND_UP instead of classic division for register
calculation.
Link: https://github.com/openwrt/openwrt/pull/24538
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The zynq target now supports 6.18 kernel as testing.
Compile-tested: all boards
Runtime-tested: Antminer S9
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
This is an automatically generated commit which aids following Kernel patch
history, as git will see the move and copy as a rename thus defeating the
purpose.
For the original discussion see:
https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Split naming convention: rxeq_* accessors control equalizer state
(get/set a coefficient, toggle adapt); rxcal_* functions run an actual
calibration procedure (measure, decide, retry). 930x's accessor layer
predates this split and still used rxcal_ throughout; rename it to
match the convention already applied consistently on 931x.
dfe_taps_adapt/dfe_disable move too - despite looping over TAP1-4,
they just apply a fixed control action with no measurement or
decision-making, same as the single-coefficient accessors. init,
fgcal, leq_adapt_lock and vth_tap0_adapt_lock stay rxcal_ - they're
the calibration-flow entry points that call these accessors as
building blocks, and the *_adapt_lock ones specifically read back a
result to decide what to lock in.
Also rename 931x's dfe_disable_5g to rxeq_dfe_disable_5g for the same
reason - it's a fixed control action, not a calibration procedure.
Link: https://github.com/openwrt/openwrt/pull/24542
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
symErr reads 0 both when the link is clean and when there's no signal
at all to decode errors from - the counter only increments when the
PCS is actively decoding something and finds a mismatch, so a dead
link and a healthy one are indistinguishable from symErr alone.
Confirmed on hardware: symErr read 0x0 while the port had no link.
Add rtpcs_931x_sds_10gr_link_up(), reading the same status bit as the
vendor SDK's _phy_rtl9310_linkSts_get() default case, and require it
alongside a low symErr count before declaring a calibration check
successful. A link that isn't actually up yet now keeps the retry
loop going instead of being misread as a clean, working link.
Also observed on hardware: the retry budget sometimes runs out while
symErr is still nonzero, but the link comes up and works fine anyway -
the count just hasn't fully settled within the budget. Since that's
not an actual problem, keep the final message at dev_dbg when
link_up is true; only warn when the link genuinely never came up.
Link: https://github.com/openwrt/openwrt/pull/24542
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
rxcal_fiber_adapt() locked in whatever a single rxeq_vth_get() call
returned after a fixed 200ms adapt window - no check that the reading
was representative rather than a transient/noisy excursion. Observed
on hardware: whenever the locked VTH wasn't 0xa (the reset baseline),
the link behaved worse; recalibrating a link that was already working
could leave it worse than before, which a single unlucky sample
locked in as final is a plausible cause of.
RTL930x's own analogous case (leq_adapt_lock) already avoids exactly
this by sampling 10 times over ~100ms and averaging rather than
trusting one read. Do the same here: settle for 100ms, then sample
VTH 10 times over ~100ms and lock in the rounded average, using
DIV_ROUND_CLOSEST() rather than an open-coded round-to-nearest.
Link: https://github.com/openwrt/openwrt/pull/24542
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
reset_leq_dfe() wrote reset values for LEQ and VTH/TAP0-4 before setting
their manual-mode enable mask, matching the vendor SDK's own instruction
order. On a first-ever call this is harmless, but calibration may leave
those in continuous live auto-adapt when it returns, so on a second
calibration attempt those fields can still be adapt-driven at the moment
reset_leq_dfe() writes "0" into them - the adapt engine can overwrite
that write before the enable-mask lands a few instructions later, locking
in whatever it had drifted to instead of the intended baseline.
Set the manual-mode enable mask first instead, so the fields are
guaranteed passive before their reset values are written, regardless
of what state a previous calibration pass left them in.
Testing on hardware suggests that this matters at least for VTH/TAP0-4,
showing a drift of coefficients throughout multiple calibration runs
without this change. With this change, it remains stable across runs.
Link: https://github.com/openwrt/openwrt/pull/24542
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add some debugging aid to the RX calibration, making it easier to spot
eventual issues caused by calibration. While the calibration has been
tested, this happened only on a small set of devices.
Adds rtpcs_931x_sds_rxeq_leq_get_coef() to read back where LEQ
auto-adapt actually settles in rxcal_leq_adapt(), mirroring what
rxcal_fiber_adapt() already does for VTH. Shares the existing
930x gray-to-binary helper since it's pure bit math, not
variant-specific. Promote it to a generic helper instead of
930x-specific.
Link: https://github.com/openwrt/openwrt/pull/24542
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Replace the plain field writes in rtpcs_931x_sds_reset_leq_dfe() with
the rxeq_* setters, now that both wire-up commits have given them real
calibration callers. Keeps the register-level detail out of the reset
sequence and gives it named accessors instead of raw write_bits() calls.
Some bits touched by the original reset writes fall outside any known
coefficient field (reg 0xd bits [1:0], reg 0x12 bits [15:12]/[3:0]).
These are kept as separate, explicitly commented raw writes rather than
folded into the setters, since the setters are scoped to match the
vendor SDK's real per-field accessors and narrowing them silently would
drop those undocumented-but-required bits.
Link: https://github.com/openwrt/openwrt/pull/24542
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Port the vendor SDK's _phy_rtl9310_fiber_adapt() as
rtpcs_931x_sds_rxcal_fiber_adapt(), dispatched from post_config for
RTPCS_SDS_ATTACH_FIBER when hw_mode is 10GBase-R (1G/100M fiber isn't
calibrated by the vendor SDK either).
Add the rxeq_tap_*/rxeq_vth_* setters (set_value, set_adapt) needed to
drive it: fiber calibration runs VTH/TAP0 auto-adapt for 200ms, then
samples the auto-adapted VTH and locks it in, forces TAP0 to a fixed
value (31, per the vendor SDK), and re-locks manual mode, before letting
DFE TAP1-4 auto-adapt freely and verifying via a symbol-error recheck
loop.
Sampling VTH needs the SerDes' debug-readback routing. Add
rtpcs_931x_sds_set_debug() and rxeq_vth_get() for it, mirroring
_phy_rtl9310_dbg_set()/_phy_rtl9310_dfe_get().
The final symbol-error recheck deliberately deviates from the vendor
SDK's shape (adapt once, recheck 3x at 150ms, require exactly 0):
symErr's field is only 8 bits wide and reads as a saturated 0xff right
after rx_reset(), which looks like "link hasn't relocked yet" rather
than a genuine error count - 10G optical relock can plausibly take
longer than 150ms. Instead, recheck more times with more patience per
check and no reset in between (so a settling link isn't interrupted),
and tolerate a small nonzero symbol-error count rather than requiring
exactly 0.
rtpcs_931x_sds_fiber_get_symerr() already existed but was unused;
wire it up alongside the existing rtpcs_931x_sds_clear_symerr().
Link: https://github.com/openwrt/openwrt/pull/24542
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Add post_config, run after activate() like on RTL930x, dispatching RX
calibration by attachment. Port the vendor SDK's _phy_rtl9310_leq_adapt()
as rtpcs_931x_sds_rxcal_leq_adapt() for the PHY-attached case, built on
new rxeq_leq_set_coef()/rxeq_leq_set_adapt() setters and the
existing but unused rx_reset().
Add rtpcs_931x_sds_dfe_disable_5g() for the one-shot operation the SDK
issues before calibrating PHY-attached and PCB-adapt ports. Presumably,
this quiesces DFE auto-adapt on the 5G companion analog block to prevent
it from interfering with DFE adaption during calibration.
Fiber and DAC attachments remain a TODO in post_config's dispatch.
Link: https://github.com/openwrt/openwrt/pull/24542
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The patch adds a pre-check to tcp_gro_receive() so that an skb which
cannot be pulled up to the GRO offset is flushed instead of reaching the
BUG() in __skb_pull(). Upstream has since fixed the same bug inside the
callee, which leaves the pre-check with nothing to protect:
commit f2bb3434544454099a5b6dec213567267b05d79d
("net: add pskb_may_pull() to skb_gro_receive_list()")
skb_gro_receive_list() now rejects the short skb itself and pulls with
skb_pull() rather than the __skb_pull() that carries the BUG(). It is
the only function the is_flist branch of tcp_gro_receive() calls, so no
path is left uncovered. The fix is present in both pinned kernels,
6.12.100 and 6.18.41.
Dropping the pre-check also restores upstream's intended handling: on
failure skb_gro_receive_list() sets NAPI_GRO_CB(skb)->flush, so the skb
is delivered through the normal receive path instead of being held as a
new GRO head. Short-circuiting on the local flush skipped that.
The patch keeps applying cleanly only because the fix landed in a
different function.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24524
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
There is no need to have the swconfig binary when DSA is in use.
Both of these devices have a single switch.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24543
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The per-partition branch of w_init() tested econet,enable-remap on the parent
nand node (np) instead of the partition being iterated (part_np). That branch
only runs when np does not carry the property, so the test was always false and
the loop skipped every partition. As a result econet,enable-remap on a
partition node was a silent no-op: no partition ever registered a remap range,
and "enable-remap set for ..." was never printed.
Read the property from part_np so per-partition enable-remap works as
documented. Boards that place the property on a partition now register that
range; boards that place it on the nand node are unaffected.
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24399
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Fixes arm64 build failures by replacing <linux/uio.h> with POSIX <sys/uio.h>
to avoid header redefinition conflicts.
gnulib's fcntl.h ends up including glibc's fcntl.h and fcntl-linux.h
which includes glibc's types/struct_iovec.h,
thats where the redefinition happens.
the lines that use <linux/uio.h> are antiquated and were never necessary.
it can be traced back to the original 2014 change that added the file with aarch64 support
in upstream commit 66637fa21044ac0058b25522f473669e73de328b
it was never necessary to use the linux header over the glibc headers,
as elfutils only needs the iovec struct and that struct was present since glibc 2.0 in the 1990s
Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24539
Signed-off-by: Robert Marko <robimarko@gmail.com>
Update to Git HEAD (2026-07-31) and switch to 7.2 kernel based
driver. We also introduced a new patch 204-* to correct the driver
version number.
Upstream merged patches:
- 005-ath10k-ct-fix-missing-prototypes-warnings-on-6.12-ke.patch
Tested on QCA9887 and IPQ4019.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/24529
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Restore the original mac80211.sh behavior by setting noscan when
fixed_freq is enabled for sta, adhoc and mesh modes. This ensures
correct channel width operation for fixed-frequency links and
matches the legacy mac80211.sh behavior.
Signed-off-by: Omar Avelar <host.omar@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21443
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Comfast CF-WA933[1] is an outdoor dual-band WiFi 6 access
point/router. They also OEM their routers for other providers. This PR
adds support based on, and substantially updates, the downstream device
definition[2] from Wayru, one such white label client.
It can be powered by a 12V DC barrel jack (standard 5.5x2.5mm, center
positive) or via 802.3af POE.
Hardware summary:
- SoC: MediaTek MT7981A
- RAM: 256 MiB
- Flash: SPI-NAND 128 MiB (Factory uses 64M; see details below to use
the full 128M!)
- WiFi (MT7976DA): dual-band 802.11ax
- Ethernet (MT7531AE): 3x gigabit: 1x WAN + 2x LAN (labeled lan1/lan2).
- Button: reset
- LEDs: Power (always on), WLAN, WAN, LAN1, LAN2
- Serial: Internal header (Four unpopulated headers, clearly labeled)
MAC addresses on the tested unit:
- Label: 40:a5:ef:f0:5e:0f
- LAN: 40:a5:ef:f0:5e:0f Factory 0xe000
- WAN: 40:a5:ef:f0:5e:10 Factory 0xe000 + 1
- 2.4 GHz: 40:a5:ef:f0:5e:11 Factory 0x0004
- 5 GHz: 40:a5:ef:f0:5e:13 Factory 0x8000 + 1
The serial number is stored as an ASCII string at Factory 0xe100.
Disassembly:
Unscrew the six 3mm hex bolts on the dome and the six 5mm bolts on the
side of the arm, then lift the dome. For reassembly, make sure the large
O ring is in the groove in the dome.
OpenWrt installation:
1. Connect to Ethernet on the WAN port. Manually set your IP address to
192.168.1.10 (important!)
2. Upload the OpenWrt sysupgrade image at http://192.168.1.1
The default U-Boot partition layout does not expose the full flash
capacity. Change the mtdparts U-Boot environment variable before
rebooting and then installing the image for the 128 MiB variant through
the same bootloader recovery/upgrade page.
Method 1: Using the serial console
1. Disassemble the unit and connect to the serial console (115200 8N1).
Leave 3.3V disconnected.
2. On the boot loader, go straight to "0. U-Boot console"
3. Then enter:
setenv mtdparts 'nmbm0:1024k(bl2),512k(u-boot-env),2048k(factory),2048k(fip),117248k(ubi)'
saveenv
reset
Method 2: From OpenWrt using uboot-envtools
apk add uboot-envtools
fw_setenv mtdparts 'nmbm0:1024k(bl2),512k(u-boot-env),2048k(factory),2048k(fip),117248k(ubi)'
reboot
Return to vendor firmware:
1. If you have changed the mtdparts environment variable, undo the
change by setting:
mtdparts 'nmbm0:1024k(bl2),512k(u-boot-env),2048k(factory),2048k(fip),65536k(ubi)'
2. Re-enter the same bootloader recovery/upgrade page.
3. Upload a stock COMFAST firmware image, e.g. from
http://www.comfast.com.cn/index.php?m=content&c=index&a=show&catid=85&id=773
[1]: https://comfastgroup.com/product/cf-wa933/
[2]: https://github.com/Wayru-Network/wayru-os/tree/main/profiles/prometheus
Signed-off-by: Guillaume RISCHARD <git@stereo.lu>
Link: https://github.com/openwrt/openwrt/pull/22379
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
When images are built with CONFIG_ALL_KMODS=y which are all buildbot built
images, then the STMMAC_ETH driver will get demoted to a module.
This is due to ALL_KMODS including kmod-ptp which selects the full PTP 1588
support instead of just the auto selected PTP_1588_CLOCK_OPTIONAL.
That causes PTP_1588_CLOCK_OPTIONAL to get deselected, STMMAC driver built
as a module instead of being built-in and then its not shipped in the device
images leading to no working wired networking.
So, lets simply enable full PTP 1588 support as built-in into the kernel so
that STMMAC does not get demoted to a module and restores wired networking.
Signed-off-by: Robert Marko <robimarko@gmail.com>
The GL.iNet GL-AXT1800 (ipq6018) requests a 40,000 ns (25 kHz) PWM
period for its four-wire fan:
pwms = <&pwm 1 40000 0>;
with the IPQ6018 PWM node clocked at 100 MHz. ipq_pwm_apply() pins
pwm_div at its maximum and derives only pre_div from the requested
period:
pre_div = period_ns * clk_rate / (NSEC_PER_SEC * (pwm_div + 1));
if (!pre_div)
return -ERANGE;
For 40,000 ns at 100 MHz this is floor(0.061) == 0, so the driver
deterministically returns -ERANGE and pwm-fan fails to probe on every
boot:
pwm-fan pwm-fan: failed to enable PWM
pwm-fan pwm-fan: Failed to configure PWM: -34
pwm-fan pwm-fan: probe with driver pwm-fan failed with error -34
Probe returns before the tachometer IRQ is requested and before
fan-supply is claimed, so the board loses fan RPM reporting and the
vcc_fan 5V regulator stays disabled. The fan never spins and the DTS
cooling-maps (trips at 50/75/100 C) have no cooling device to bind to.
This is the same defect fixed for qualcommbe in commit 8db23dc91a
("qualcommbe: fix pwm period calculation") by Kenneth Kasilag, whose
rationale explicitly calls out 25 kHz four-wire fan PWM. qualcommax
carries its own copy of the pwm-ipq driver and was not covered by that
fix. The patch added here is that work backported to qualcommax, with
authorship preserved; the base driver differs slightly between targets
so the hunks were rebased onto the qualcommax copy.
Confirmed on hardware. The board was tested on the 6.12 kernel, which
this target has since dropped; the pwm-ipq driver source is identical
under 6.12 and 6.18, so the patch and its effect are unchanged. Before,
driving the PWM directly from userspace on a GL-AXT1800 running
r35591-d0110a25ed:
# echo 40000 > period; echo 1 > enable -> write error (-ERANGE)
# echo 2700000 > period; echo 1 > enable -> succeeds
After building and flashing an image with this patch, pwm-fan probes
cleanly and the fan is verified spinning by its own tachometer:
/sys/class/hwmon/hwmon7/name = pwmfan
/sys/devices/platform/pwm-fan/hwmon/hwmon7/fan1_input = 3548
/sys/class/regulator/regulator.3 (vcc_fan) = enabled
/sys/class/thermal/cooling_device1 = pwm-fan
and no PWM errors remain in dmesg.
Link: 8db23dc91a
Signed-off-by: Stephane Lepain <stephanelepain@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24479
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add a patch to fix boot hang on some devices after 7cc31af7bd
("realtek: convert to generic machine initialization"), reusing
upstream's implementation of Realtek board setup. The issue came up on a
Linksys LGS352C device, causing total silence and a hang after
rt-loader's last line "Booting kernel from 0x80100000 ...".
While the OpenWrt downstream version operated on the plain appended
device tree using a pointer, the upstream implementation copies the FDT
into a 16 KiB buffer. Given the following survey, this may be too small
for some devices:
rtl9311_linksys_lgs352c: 21278 bytes
rtl9313_ubnt_usw-pro-xg-8-poe: 12809 bytes
rtl9313_hasivo_f5800w-12s-plus: 13103 bytes
rtl9313_xikestor_sks8300-12x-v1: 13630 bytes
rtl9313_zyxel_xs1930-12f: 14488 bytes
rtl9313_zyxel_xs1930-12hp: 15234 bytes
rtl9313_hasivo_s1300wp-8xgt-4s-plus: 15341 bytes
To fix this, the patch increases the buffer size, leaving some more
headroom for further outliers.
Fixes: 7cc31af7bd ("realtek: convert to generic machine initialization")
Assisted-by: Claude:claude-sonnet-5
Link: https://github.com/openwrt/openwrt/pull/24541
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
The patch relaxes buf_verify()'s "Non-matching signing type" check so
that an rsa-sha2-256 signature is accepted against an ssh-rsa key.
Dropbear no longer needs the help: both sides of that comparison are now
taken from the wire's own algorithm names, so a compliant client
satisfies expect_sigtype == sigtype unaided.
Tracing the provenance in 2026.92, since it is what the removal rests
on. svr-authpubkey.c:113 reads the algorithm name out of the
SSH_MSG_USERAUTH_REQUEST and :126 turns it into sigtype with
signature_type_from_name(); that value is what :233 hands to buf_verify()
as expect_sigtype. signkey.c:655 parses the type name out of the
signature blob through the same signature_type_from_name(), and :659
compares the two. Neither is derived from the key format found in
authorized_keys: :132 maps the signature type back to the key algorithm
with signkey_type_from_signature() purely for the checkpubkey() lookup.
RFC 8332 section 3 has a client using rsa-sha2-256 send that name in the
userauth request and in the signature both, so the two agree and the
check passes - with an ssh-rsa key in authorized_keys, which is the case
the patch was written for.
Confirmed rather than reasoned: built pristine 2026.92 with this
package's defaults (DROPBEAR_RSA 1, DROPBEAR_RSA_SHA1 0) and logged in
over publickey with an OpenSSH client pinned to
PubkeyAcceptedAlgorithms=rsa-sha2-256. It succeeds, and the server
reports "Pubkey auth succeeded ... with ssh-rsa key" - an ssh-rsa entry
in authorized_keys, an rsa-sha2-256 signature, no patch.
Keeping the patch has an effect of its own. With DROPBEAR_RSA_SHA1 0,
signature_type_from_name("ssh-rsa") falls through to
signkey_type_from_name() and returns DROPBEAR_SIGNKEY_RSA, which is 0.
That is not DROPBEAR_SIGNATURE_NONE, so the patch's own "No signature
type" guard passes it, and expect_sigtype == DROPBEAR_SIGNATURE_RSA_SHA256
skips the type check. buf_rsa_verify() then calls rsa_pad_em(), whose
switch has no case for 0 and ends in default: assert(0), so the process
aborts. Upstream's unconditional check rejects the mismatch instead.
It is also narrower than upstream's in a second way: the replacement
sits inside #if DROPBEAR_RSA / #if DROPBEAR_RSA_SHA256, while the check
it displaces is unconditional. An ECDSA or Ed25519 only build therefore
has no expect_sigtype check at all today, only the "No signature type"
guard. Dropping the patch restores the check for every configuration,
not just this package's default one.
buf_verify() runs only after checkpubkey() has succeeded, so the abort
needs a key already listed in the target's authorized_keys - post-auth,
not an authentication bypass.
The patch's extra DROPBEAR_SIGNATURE_NONE guard is not lost with it:
svr-authpubkey.c rejects that case before buf_verify() is reached.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24525
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
netis N6 V2 is a MT7981B-based router, hardware-compatible with
netis NX32U (confirmed via bootloader cross-flash). GPIO mappings
not covered by the vendor DTS were verified against NX32U and via
live link/carrier testing on switch ports, plus direct LED-toggle
confirmation on the physical device.
Hardware:
SoC: MediaTek MT7981B (Filogic 820)
RAM: 256 MiB DDR3 (ESMT M15T2G16128A-AZR1-EFB, DDR3-1866)
Flash: 128 MiB SPI-NAND
Ethernet: 4x 1GbE (mt7531 switch: wan, lan1, lan2, lan3),
2.5GbE internal CPU-switch link (gmac0, 2500base-x)
WiFi: MT7981 integrated 2.4GHz + MT7976C 5GHz radio,
802.11ax, 2x2 MU-MIMO, HE160 supported (confirmed live;
vendor firmware ships with HE80 for the AX1800 rating)
USB: 1x USB 3.0 (vbus GPIO 23, active high)
Buttons: mesh/rfkill (GPIO 0), reset (GPIO 1)
LEDs: power (GPIO 4), status (GPIO 5), wan (GPIO 9),
wlan 2.4GHz (GPIO 34, phy0tpt trigger),
wlan 5GHz (GPIO 35, phy1tpt trigger),
usb (GPIO 13, usbport trigger)
all active low
UART: 115200n8, uart0
MAC addresses:
Interface | Source | Offset | Address (this unit)
------------|------------------|----------|--------------------
WAN | Factory mac-base | 0x1fef26 | 30:07:5c:dc:7a:d2
LAN/CPU | Factory mac-base | 0x1fef20 | 30:07:5c:dc:7a:d0 (label)
WiFi 2.4GHz | radio calibration (auto) | 30:07:5c:dc:7a:d1
WiFi 5GHz | radio calibration (auto) | b2:07:5c:dc:7a:d1
LAN address matches the label on the device enclosure. WAN uses
macaddr_factory_1fef26 on switch port@0, LAN/CPU uses
macaddr_factory_1fef20 on port@6 (mt7531 switch). WiFi MACs are not
set explicitly in DTS -- mt76 derives them from the radio's own
calibration data, confirmed live to match the stock firmware value.
The USB LED (GPIO 13) was missed in the initial GPIO mapping pass --
it isn't referenced anywhere in the vendor DTS or any other board
signal, so it went unnoticed until manual GPIO toggling (`gpio clear
13` at the U-Boot prompt) confirmed it live on the physical device.
The USB LED on GPIO 13 uses the usbport trigger with trigger-sources
on both xhci ports, hence kmod-usb-ledtrig-usbport in DEVICE_PACKAGES.
The included U-Boot defenv for this board also avoids a silent
failure in ubi_write_production/ubi_write_recovery: these call
`ubi remove <vol>` without first detaching/reattaching the UBI
device, which fails silently on a busy volume while the boot script
proceeds as if it succeeded. Worked around here by adding
`ubi detach ; ubi part ubi ;` before the remove, a pattern already
used in other boards' defenvs (see issue #18231). Only this board's
defenv is touched -- other boards' defenv files are unchanged.
Known upstream issue (not specific to this port): probing
u-boot-env-layout on the ubootenv/ubootenv2 UBI volumes logs
"Invalid calculated CRC32" on every boot, see mediatek/filogic
issues #21876 and #22383.
Installation:
Requires network access to stock firmware SSH (enabled by default)
and a TFTP server on the same subnet.
1. Set up a TFTP server on your PC at 192.168.1.254, serving the
files from this release.
2. SSH into stock firmware: ssh root@192.168.1.1
3. Copy bl31-uboot.fip to the router and write it to the FIP
partition: mtd write bl31-uboot.fip FIP
4. Erase the ubi partition: mtd erase ubi
5. Reboot. The new bootloader will detect the missing production
image and automatically fetch initramfs-recovery.itb via TFTP.
6. Once recovery has booted, SSH in again and sysupgrade to the
production image: sysupgrade squashfs-sysupgrade.itb
Signed-off-by: Murad Rabadanov <the21.21@mail.ru>
Link: https://github.com/openwrt/openwrt/pull/24089
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The an7581/an7583 configs enable redundant environment support,
but do not define CONFIG_ENV_OFFSET_REDUND.
When running `saveenv`, U-Boot tries to write the redundant environment
to MMC. Without a valid redundant environment offset, the data may be
written to an incorrect location and overwrite critical boot data such
as the GPT, BL2/preloader or BL31+U-Boot FIP.
This causes the board to fail booting after saving the environment.
Define CONFIG_ENV_OFFSET_REDUND so the redundant environment is stored
at a valid eMMC offset and no longer corrupts the bootchain.
Signed-off-by: Yalei Zang <yalei.zang@airoha.com>
Link: https://github.com/openwrt/openwrt/pull/24397
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Pack the BL2 and BL31+U-Boot artifacts as Airoha AN7583 is currently
supported in upstream U-Boot and bootloader files can be used for
unfused boards.
Signed-off-by: Yalei Zang <yalei.zang@airoha.com>
Link: https://github.com/openwrt/openwrt/pull/24397
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Backport four upstream commits that convert mutex_init() calls to
devm_mutex_init() in the Realtek DSA driver family. With
CONFIG_DEBUG_MUTEXES enabled, mutex_destroy() must be called before a
mutex is discarded; using the devm variant handles this cleanup
automatically and avoids leaking a warning on driver removal/failure.
Added patches (applied to both backport-6.12 and backport-6.18):
- 944-01: net: dsa: realtek: rtl8365mb: use devm_mutex_init for mib_lock
- 944-02: net: dsa: realtek: use devm_mutex_init for regmap lock
- 944-03: net: dsa: realtek: use devm_mutex_init for vlan_lock
- 944-04: net: dsa: realtek: use devm_mutex_init for l2_lock
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/24486
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Move the DASAN H660GM-A root filesystem from a raw squashfs in the tclinux
partition to UBI, following the layout already used by the en751221
ChinaMobile GS3101.
tclinux is split into an explicit 4MB tclinux_kernel partition holding the
raw LZMA kernel and a tclinux_rootfs partition covering the remainder. The
latter is concatenated with the unused "unknown" partition into a single UBI
volume, giving 153MB on the Airtel variant and 41MB on the Generic one. The
two regions are not adjacent, so this needs mtd virtual concat, which is
enabled for the subtarget.
The TRX plus UBI image recipe is identical to the one the GS3101 uses, so
factor it out into a Device/tclinux-ubi template instead of duplicating it.
The .trx is written linearly into tclinux by the vendor installer, so an
oversized image would run past its end into tclinux_slave and destroy the
vendor firmware in the alternate slot. FACTORY_SIZE guards against this and
is set to the size of the partition the .trx is written into.
Existing installations have to be reflashed with the .trx rather than
sysupgraded, since the ubi MTD only appears once the new device tree is
running.
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24398
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
This site no longer provide GNOME mirror services.
Signed-off-by: Zhi You <yuzhii0718@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/24498
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Hardware:
- SoC: MediaTek MT7981B
- CPU: 2x 1.3 GHz Cortex-A53
- Flash: 256 MiB ESMT F50L2G41XA
- RAM: DDR3, 512 MiB
- WLAN: 2.4 GHz, 5 GHz (MediaTek MT7976CN, 802.11ax)
- 1x WAN MT7531 (JXD 2531Z) 10/100/1000 Mbps
- 4x LAN 2x MT7530 (JXD 2529S) 10/100/1000 Mbps
- USB 3.0 port
- Buttons: Reset, WPS
- 8x LEDs: 2x Red, 6x Blue
- Serial console: no need to solder. 115200 8n1
- Power: 12 VDC, 1.5 A
The DTS inherits WBR3000UAX because WR3000U is almost the same.
The only difference is size of NAND and factory UBI length.
+---------+-------------------+-----------+
| | MAC | Algorithm |
+---------+-------------------+-----------+
| WAN | D4:0D:AB:xx:xx:x1 | label+1 |
| LAN | D4:0D:AB:xx:xx:x0 | label |
| WLAN 2g | D4:0D:AB:xx:xx:x0 | label |
| WLAN 5g | D6:0D:AB:xx:xx:x1 | label+1 |
+---------+-------------------+-----------+
There are 2 ways to install OpenWrt:
- via an intermediate RSA-signed vendor's image or
- via UART && TFTPd
Migration to OpenWrt via OEM firmware:
- Download the migration image from
https://drive.google.com/drive/folders/1BKVarlwlNxf7uJUtRhuMGUqeCa5KpMnj
(The folder is Cudy's official "Cudy Intermediary OpenWrt Firmware" resource)
- Upload the migration image via OEM web interface
- After flashing, OpenWrt is accessible via http://192.168.1.1
- Flash the official OpenWrt image
Install using UART & TFTP:
- Connect to UART.
- Connect to LAN and set your IP to 192.168.1.88/24.
- Configure a TFTP server to serve
openwrt-mediatek-filogic-cudy_wr3000u-v1-initramfs-kernel.bin file
and run the TFTP server.
- Press reset and power-on the router. Hold the reset button for 5 seconds
- TFTP error: 'File not found' appears and MTK console becomes available
- Enter the following commands in the console:
setenv bootfile openwrt-mediatek-filogic-cudy_wr3000u-v1-initramfs-kernel.bin
tftpboot
bootm
- After booting to initramfs, via http://192.168.1.1 flash
openwrt-mediatek-filogic-cudy_wr3000u-v1-squashfs-sysupgrade.bin
- After flashing, OpenWrt is accessible via http://192.168.1.1
If you fail to flash the device,
you can use TFTP to flash back to the original firmware:
- Download the original firmware from
https://www.cudy.com/pages/download-center/wr3000u-256mb-1-0
- Connect to LAN and set your IP to 192.168.1.88/24.
Configure a TFTP server and an recovery.bin firmware file
- With the router off, press the RESET button.
While the router is turning on,
the button should continue to be pressed for at least 5 seconds
- After 1-2 minutes the original firmware is available on http://192.168.10.1
Signed-off-by: Dmitry Mostovoy <stavultras@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24447
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Downgrade rtldsa_931x_print_matrix from pr_info to pr_debug to reduce
the massive amount printed during boot (64 lines). There doesn't seem
any benefit right now for keeping this at info level. And RTL931X is
the only variant that uses info-level print right now, all others
already use pr_debug.
Debug output can be activated individually for people who need this for
testing/debugging.
Link: https://github.com/openwrt/openwrt/pull/24507
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
edma_probe() assigns a random address unconditionally, so the conduit
changes its MAC on every boot, and with it every DSA user port that has
no address of its own and therefore inherits the conduit's.
The conduit is a DMA engine behind the switch and has no address of its
own, which is why no board describes one for it. Take the address from
the switch this conduit serves instead: its ports carry the board's
addresses, either from DT or patched in by the bootloader, so this needs
nothing added per board. Keep the random address for the case where the
switch describes no address either.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
Link: https://github.com/openwrt/openwrt/pull/24512
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
nf_flow_table.ko now links in the flowtable path discovery code
(nft_flow_route() and friends), which was moved out of
nft_flow_offload.c and references nf_tables symbols directly. This
makes nf_flow_table.ko depend on nf_tables.ko at load time, so
kmod-nf-flow needs kmod-nft-core.
Upstream: 93d7a7ed0734 ("netfilter: flowtable: move path discovery infrastructure to its own file")
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/24419
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The IXP4xx firmware is now in linux-firmware so use these images
instead and drop the special microcode builder package.
Apply a change to the github labeler at the same time as the special
ixp4xx microcode package no longer exists after this.
Link: https://github.com/openwrt/openwrt/pull/24422
Signed-off-by: Linus Walleij <linusw@kernel.org>
