Not sure but is this PR related?
"base-files: bring up vlan interface too #2734"
https://github.com/openwrt/openwrt/pull/2734
On 6/19/21 8:36 AM, Hauke Mehrtens wrote:
Adapt the preinit_config_board() to the board.json network changes. It
now looks for the device and the ports variables to con
> -Original Message-
> Sent: 6/17/21 1:33 AM
> To: openwrt-devel@lists.openwrt.org
> Cc: Ansuel Smith
> Subject: [PATCH 21.02] ipq806x: backport cpufreq changes to 5.4
>
In the time since submitting this, I've continued testing this
change on my ZyXEL NBG6817. I'm reasonably confident t
With the introduction of `squashfs-tools-ng` the `squashfskit4` fork is
no longer required.
Signed-off-by: Paul Spooren
---
tools/squashfskit4/Makefile | 41 --
.../patches/0001-fix-version.sh.patch | 21 -
...002-fix-build-failure-against-gcc-10
Let the newly added `squasfs-tools-ng` handle the squashfs file
creation.
Signed-off-by: Paul Spooren
---
include/image.mk | 23 ---
tools/Makefile | 6 +++---
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/include/image.mk b/include/image.mk
index a7473a
Hi all,
Some long time ago I created a PR[1] on GitHub to replace our (stalled)
fork of squashfs-tools (called squashfskit[2]) with a reimplementation
called squashfs-tools-ng[3].
The main developer was thankfully very helpful in the process of
integrating squashfs-tools-ng into the OpenWrt build
The `squashfs-tools-ng` is a reimplementation of `squashfs-tools` of
which a fork called `squashfskit` is currently used withn OpenWrt.
Signed-off-by: Paul Spooren
---
tools/squashfs-tools-ng/Makefile | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 tools/squ
On 6/20/21 6:56 AM, Adrian Schmutzler wrote:
sysupgrade metadata is not flashed to the device, so check-size
should be called _before_ adding metadata to the image.
While at it, do some obvious wrapping improvements.
Signed-off-by: Adrian Schmutzler
---
Acked-by: Paul Spooren
I'm wonderi
sysupgrade metadata is not flashed to the device, so check-size
should be called _before_ adding metadata to the image.
While at it, do some obvious wrapping improvements.
Signed-off-by: Adrian Schmutzler
---
target/linux/ath79/image/Makefile | 2 +-
target/linux/ath79/image/common-m
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Branch: refs/heads/master
Home
On 6/20/21 10:32 AM, DENG Qingfang wrote:
On Sat, Jun 19, 2021 at 08:36:10PM +0200, Hauke Mehrtens wrote:
On a DSA switch the ports have an upper device, the CPU device, e.g.
eth0. This device has to be in up state to bring up the lower devices
like lan1.
Parse the link device from "ip link sho
On 6/20/21 4:30 PM, Sven Roederer wrote:
Am Samstag, 19. Juni 2021, 20:36:10 CEST schrieb Hauke Mehrtens:
On a DSA switch the ports have an upper device, the CPU device, e.g.
eth0. This device has to be in up state to bring up the lower devices
like lan1.
Parse the link device from "ip link sho
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sat, Jun 19, 2021 at 8:39 PM Ha
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Sat, Jun 19, 2021 at 8:39 PM Ha
> Hi,
>
> the hardware documentation is very poor, not much more than advertisement for
> the SoCs, e.g. for the RTL8380
> https://manualzz.com/doc/31627850/draft-datasheet
> it does not mention these special VLAN properties.
>
> All the code is based on the GPL drops. However, the latest ones
Am Samstag, 19. Juni 2021, 20:36:10 CEST schrieb Hauke Mehrtens:
> On a DSA switch the ports have an upper device, the CPU device, e.g.
> eth0. This device has to be in up state to bring up the lower devices
> like lan1.
>
> Parse the link device from "ip link show" and bring it into up stated
> b
>
> Hi,
>
> Thank you for the links, I was not aware of this strange problem.
>
> Do you have access to a documentation of any of these chips or only some
> source code?
>
> We could add some special handling for these chips in the failsafe mode, let
> me look into this.
>
> Hauke
>
Hi,
On 6/20/21 11:01 AM, Birger Koblitz wrote:
Hi,
On 19.06.21 14:25, Hauke Mehrtens wrote:
Hi,
I am unable to send and receive packets directly on the lan1 interface when it
is not part of a bridge.
In wireshark on a connected host I do not see any packets from this device, but
the link is
Hi,
On 19.06.21 14:25, Hauke Mehrtens wrote:
> Hi,
>
> I am unable to send and receive packets directly on the lan1 interface when
> it is not part of a bridge.
>
> In wireshark on a connected host I do not see any packets from this device,
> but the link is up.
>
> When I use OpenWrt's defa
On Sat, Jun 19, 2021 at 08:36:10PM +0200, Hauke Mehrtens wrote:
> On a DSA switch the ports have an upper device, the CPU device, e.g.
> eth0. This device has to be in up state to bring up the lower devices
> like lan1.
>
> Parse the link device from "ip link show" and bring it into up stated
> be
On 19/06/2021 10:37, Baptiste Jonglez wrote:
Hi,
On 03-06-21, Andre Heider wrote:
This is required by some APIs, e.g. matrix's media upload [0].
[0]
https://matrix.org/docs/spec/client_server/latest#post-matrix-media-r0-upload
@@ -484,6 +485,7 @@ static int usage(const char *progname)
20 matches
Mail list logo
