From: Arınç ÜNAL
The Huasifei WS1208V2 is an AC1200 router featuring 5 Ethernet ports with a
Quectel RM520N-GL cellular modem which supports QMI and MBIM modes.
Specifications:
- MT7621AT, 256 MiB RAM, 16 MiB SPI Flash
- MT7603EN 2.4 GHz & MT7612EN 5 GHz WLAN
- Quectel RM520N-GL Cellular Modem
On 3.02.2023 16:03, Hauke Mehrtens wrote:
On 1/27/23 14:57, arinc9.u...@gmail.com wrote:
From: Arınç ÜNAL
The Huasifei WS1208V2 is an AC1200 router featuring 5 Ethernet ports
with a
Quectel RM520N-GL cellular modem which supports QMI and MBIM modes.
Specifications:
- MT7621AT, 256 MiB RAM,
Hi
On 2023-02-03, Sebastian Moeller wrote:
> MVEBU devices are not supported in kernel 5.10 based OpenWrt22.03.3 due to a
> bug.
> The fix is already in 5.15, but seems to intrusive to backport.
> Current snapshot builds are on kernel 5.15 already and the issue does not
> exist anymore.
> So
The tool supports three modes that ingest an existing safeloader image:
-i (image info), -x (extract payloads), and -z (convert to sysupgrade).
These modes all re-implement image parsing, so refactor the code to make
sure there is only one place this is performed.
Signed-off-by: Sander Vanheule
An incompatible image type is now used, e.g. for the TL-WPA8631P v4,
which has a header containing 0x3C extra bytes. This image type can be
identified by the first four bytes of the image header being "?NEW".
Only detection is implemented at this moment, as the full header format
is not yet
The vendor info in the safeloader header for some images (e.g. Archer
C60 v3) starts with "fw-type:Cloud" instead of a big endian data length.
Only detection is implemented at this moment, as the full header format
is not yet understood.
Signed-off-by: Sander Vanheule
---
Some images may contain ASCII vendor info at the start of the image
header. Detect this image type, and display the info when requested.
Signed-off-by: Sander Vanheule
---
src/tplink-safeloader.c | 42 +
1 file changed, 42 insertions(+)
diff --git
When the soft-version partition contents are checked for a text-format
version string, isascii() is used to check the contained bytes. This
also returns true on control characters, which includes terminating
NULL characters.
After checking if the data is a string, use the actual string length for
A number of data offsets are used as plain numbers throughout the code.
This is a bit fragile, and the magic numbers make the code harder to
read. Use a set of macros instead.
Signed-off-by: Sander Vanheule
---
src/tplink-safeloader.c | 39 ++-
1 file
To ensure the stock rootfs ends up at the correct offset, the preceding
kernel partition is padded with 0xff, corresponding to erased flash.
Since on sysupgrade all the required flash space is anyway rased before
writing the new image, it is not necessary to also pad after the second
and last part
The partition table parser supports two table types, which only differ
in the starting ID of a table entry. Selection of which type to parse is
performed with a plain integer, but this makes code harder to read.
Replace the integer by an enum to make type selection more obvious.
While touching
Instead of only free()-ing the allocated data block, also clear the name
and size of a payload entry to indicate that it's become invalid.
Signed-off-by: Sander Vanheule
---
src/tplink-safeloader.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git
TP-Link is playing fast and loose with the safeloader format, having
resulted in different types of images with their specific quirks.
A new incompatible format is currently used in the wild, which places
the payload partition table at a different offset, causing the image
parsers to fail. [1]
Current code only skips all-zero partition table entries, but nameless
partitions with zero size don't make much sense either. Assume that any
entry without a partition name is invalid, and stop processing entry
lists at that point.
Signed-off-by: Sander Vanheule
---
src/tplink-safeloader.c |
MVEBU devices are not supported in kernel 5.10 based OpenWrt22.03.3 due to a
bug.
The fix is already in 5.15, but seems to intrusive to backport.
Current snapshot builds are on kernel 5.15 already and the issue does not exist
anymore.
So the easy ways forward are:
1) stick to 22.03.2
2) switch
Flagged broken:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=a0bae2fef8bdd4f76767e1b29deb1adf279403e9
due to broken switch behaviour, which is resolved with kernel 5.15,
backport ID'ed but too invasive.
On 2023-02-03 13:53, Mark Thurston wrote:
The latest image available for
The latest image available for Turris Omnia (mvebu) is 22.03.2
(https://openwrt.org/toh/turris/turris_omnia). I was surprised to see 22.03.3
is not available for this target. Is there anything that I can do to help make
a built 22.03.3 image available for general download?
I'm happy to put in
On 2/3/23 08:18, Rafał Miłecki wrote:
Another step in my NAT performance debugging.
I realized that my OpenWrt 21.02 based bcm53xx builds can't reach 940
Mb/s because I have qos-scripts installed.
It happens even with QoS interface disabled:
qos.wan.enabled='0'
and with QoS disabled in
On Fri, Feb 3, 2023 at 5:02 PM Paul Spooren wrote:
>
> Hey all,
>
> We’re still using OpenSSL 1.1.x within OpenWrt and during the last developer
> meeting we were wondering if anyone is working on porting it over to v3.x? If
> so please share your status, thanks!
It's been on my to-do list for
Hey all,
We’re still using OpenSSL 1.1.x within OpenWrt and during the last developer
meeting we were wondering if anyone is working on porting it over to v3.x? If
so please share your status, thanks!
Best,
Paul
___
openwrt-devel mailing list
Hi Ansuel (or others),
On Wed, Jan 25, 2023 at 10:18 PM Brian Norris
wrote:
>
> Commit 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan
> option") had two problems:
>
> 1. The strcmp() aborted when the param *matched* 1; we wanted the
>inverse
> 2. It was too aggressive
I dont use qos-scripts, but sqm-scripts. That said, cake peers into
the nat table to balance the traffic better.
On Fri, Feb 3, 2023 at 8:23 AM Rafał Miłecki wrote:
>
> Another step in my NAT performance debugging.
>
> I realized that my OpenWrt 21.02 based bcm53xx builds can't reach 940
> Mb/s
Another step in my NAT performance debugging.
I realized that my OpenWrt 21.02 based bcm53xx builds can't reach 940
Mb/s because I have qos-scripts installed.
It happens even with QoS interface disabled:
qos.wan.enabled='0'
and with QoS disabled in general:
/etc/init.d/qos stop
(disable & reboot
On 1/27/23 14:57, arinc9.u...@gmail.com wrote:
From: Arınç ÜNAL
The Huasifei WS1208V2 is an AC1200 router featuring 5 Ethernet ports with a
Quectel RM520N-GL cellular modem which supports QMI and MBIM modes.
Specifications:
- MT7621AT, 256 MiB RAM, 16 MiB SPI Flash
- MT7603EN 2.4 GHz &
Hi,
the patch was white-space mangled and the Signed-off-by didn't match the
author. It also introduced syntax errors in fw4.uc so it seems it hasn't been
runtime tested at all.
Superseded by https://git.openwrt.org/e6e82a5 and
https://git.openwrt.org/30ee17a.
signature.asc
Description:
Hi,
the patch was whitespace mangled and didn't apply. After fixing it up
manually, the Signed-off-by didn't match the author. Also the fixed option
wasn't use anywhere so the fix was rather incomplete (or not useful by itself).
It is superseded by https://git.openwrt.org/39e8c70 now.
Regards,
26 matches
Mail list logo
