On 1/3/20 1:46 AM, Petr Štetiar wrote:
> Fixes following deficiencies:
>
> * unhandled read() errors
> * everything bundled in one long function, which is hard to follow and
>reason about
> * JSON parser errors are being ignored, anything else then
>json_tokener_continue is fatal error
On 1/5/20 11:40 AM, Petr Štetiar wrote:
> Hauke Mehrtens [2020-01-04 20:41:44]:
>
> Hi,
>
> thanks for the review!
>
>> Please annotate the function with:
>> __attribute__ ((format (printf, 2, 3)));
>
> Done.
>
>>> + va_start(va, fmt);
>
On 1/5/20 2:43 PM, m...@adrianschmutzler.de wrote:
> On 11/28/19 7:11 PM, Adrian Schmutzler wrote:
>> Hi Hauke,
>>
>>> The following are still on kernel 4.9:
>>> * ar7
>>> * ixp4xx
>>> * orion
>>
>> There are patches (actually from you, May 2019) on the list w
supported_devices
attribute to allow renaming. Do the renaming of the target between 19.07
and master like it is done for some other boards.
I tested the following sysupgrades successfully without -F
18.06 -> 19.07
19.07 -> master
master -> 19.07
Signed-off-by: Hauke Mehrtens
---
target/linux/ram
On 1/5/20 3:17 PM, Hauke Mehrtens wrote:
> Without this change sysupgrade from 18.06 to 19.07 is only possible with
> the -F option.
> In OpenWrt 18.06 the nand_do_platform_check() function is called with
> the board name mir3g only, if the tar does not use mir3g it will fail.
> Op
On 1/5/20 5:37 PM, m...@adrianschmutzler.de wrote:
> Hi Hauke,
>
>> -Original Message-----
>> From: Hauke Mehrtens [mailto:ha...@hauke-m.de]
>> Sent: Sonntag, 5. Januar 2020 15:18
>> To: openwrt-devel@lists.openwrt.org
>> Cc: m...@adrianschmutzle
]
[522413.129459] ra = 004197ef in dnsmasq[40+23000]
This is happening in blockdata_write() when block->next is
dereferenced, but I am not sure if this is related to this problem or if
this is a different problem. I am unable to reproduce this problem.
Signed-off-by: Hauke Mehrt
On 1/2/20 1:04 AM, Eneas Queiroz wrote:
>
> On Wed, Jan 1, 2020 at 6:54 PM Hauke Mehrtens <mailto:ha...@hauke-m.de>> wrote:
>
> I will shift both releases (18.06.6 and 19.07.0 final) to Monday 6.
> January to get some security fixes in, please get your changes i
On 1/6/20 5:39 PM, e9hack wrote:
> Am 06.01.2020 um 17:20 schrieb Petr Štetiar:
>> e9hack [2020-01-06 16:59:47]:
>>
>>> it looks like that uhttpd/luci/rpcd is broken again. The call 'ubus call
>>> luci-rpc getWirelessDevices' does fail 'Command failed: Request timed out'.
>>
>> can you provide lit
On 12/24/19 4:48 PM, Hauke Mehrtens wrote:
> Hi,
>
> I would like to tag 18.06.6 release in the evening of Wednesday 1.
> January and then start the builders.
>
> I would like to tag 19.07 final release on Friday 3. January and the
> start the builders on Saturday or Sunda
On 1/7/20 9:09 PM, Eneas Queiroz wrote:
> On Mon, Jan 6, 2020 at 1:59 PM Hauke Mehrtens wrote:
>>
>> I cherry-picked it, but WPA3 still does not work for me.
>>
>> Hauke
>
> TLDR: WPA3 support with wolfssl is still not ideal.
>
> WPA3 success was reported
On 1/7/20 12:39 PM, Adrian Schmutzler wrote:
> Hi Hauke,
>
> since you seem to have a mir3g, maybe you can look into the following MAC
> address issue/question when you find some time:
>
> For the mir3g, 02_network sets the lan_mac to factory 0xe006, while the
> address from 0xe000 set to ðerne
On 1/7/20 12:32 PM, Adrian Schmutzler wrote:
> Hi Hauke,
>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
>> Behalf Of Hauke Mehrtens
>> Sent: Sonntag, 5. Januar 2020 14:54
>> To: m...@adrianschmutzler
On 1/5/20 5:37 PM, Piotr Dymacz wrote:
> Hi Adrian, Tom,
>
> On 05.01.2020 16:57, m...@adrianschmutzler.de wrote:
>>> -Original Message-
>>> From: Tom Psyborg [mailto:pozega.tomis...@gmail.com]
>>> Sent: Sonntag, 5. Januar 2020 16:33
>>> To: m.
On 10/27/19 6:44 PM, Hauke Mehrtens wrote:
> This is a follow up patch on this discussion on the mailing list:
> https://patchwork.ozlabs.org/patch/1041647/
>
> This allows to activate PIE only for some packages where we thing it is
> necessary and not only globally for all of t
On 1/8/20 7:24 AM, Petr Štetiar wrote:
> Hauke Mehrtens [2020-01-07 23:21:19]:
>
> Hi,
>
> thanks for your work.
>
>>> Hauke Mehrtens (6):
>>> buildsystem: Make PIE ASLR option tristate
>>> dnsmasq: Activate PIE by default
>>> dropbea
Hi,
The OpenWrt community is proud to announce the first stable release of
the OpenWrt 19.07 stable version series. It incorporates 3954 commits
since the previous release 18.06.0 and 85 commits since the previous
release candidate 19.07.0-rc2.
An upgrade from OpenWrt 18.06 to OpenWrt 19.07 is su
Hi,
The OpenWrt Community is proud to announce the sixth service release of
the stable OpenWrt 18.06 series. OpenWrt 18.06.6 incorporates security
updates for base packages, new versions of the Linux kernel, a bug fix
related to signature verification, and fixes for various devices.
Some sel
Hi,
I meet with jow about 2 weeks ago and we talked about a lot of OpenWrt
related stuff, one of the topics was the release after 19.07.
As the 19.07 release is now done, I would like to follow up on this topic.
We thought that the time between the 19.07 branch and the final release
was way too
und in the staging directory.
Signed-off-by: Hauke Mehrtens
---
include/kernel.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/kernel.mk b/include/kernel.mk
index 38331768ed..b1b1e9e9c8 100644
--- a/include/kernel.mk
+++ b/include/kernel.mk
@@ -114,6 +114,7 @@ KERNEL_
On 1/16/20 11:05 AM, Petr Štetiar wrote:
> Hauke Mehrtens [2020-01-16 00:00:33]:
>
> Hi,
Hi,
Sorry for answering so late, was busy with other stuff.
>> My preferred timeline would the the following:
>> * Beginning of February: freeze master for big changes (adding new
&g
On 1/16/20 12:48 PM, Petr Štetiar wrote:
> Peter Geis [2020-01-15 21:15:41]:
>
> Hi,
Hi,
> tl;dr I'm going to vote in favor of skipping release with 4.19 and focus on
> 5.4 kernel.
>
> The 19.07 release was delayed by a few months, so this has affected the
> subsequent release as well. The pla
On 1/19/20 6:56 PM, Hannu Nyman wrote:
> Hauke Mehrtens kirjoitti 19.1.2020 klo 19.17:
>> On 1/16/20 11:05 AM, Petr Štetiar wrote:
>>
>>> BTW it's still master + 2 stable releases which will receive the
>>> support? Once
>>> the 20.y is out,
On 4/18/21 9:33 PM, Alberto Bursi wrote:
On 18/04/21 20:51, Etienne Champetier wrote:
Le sam. 17 avr. 2021 à 17:47, Sven Roederer a
écrit :
Am Samstag, 17. April 2021, 16:45:01 CEST schrieb Sven Roederer:
On my Ubuntu 16.04 based build-system I also have build-failures for
meson
using Pyt
Since OpenWrt 21.02 we use https for our download server, detect these
URLs too.
Signed-off-by: Hauke Mehrtens
---
To use the https URLs I have to provide the URL manually now:
./maketag.sh -k F1B767859CB2EBC7 -v 21.02.0-rc1 -u
https://downloads.openwrt.org/releases
makebranch.sh | 2
On 4/19/21 8:59 AM, Andre Heider wrote:
On 19/04/2021 08:51, Florian Eckert wrote:
Hello,
If there are some other bugs in the 21.02 branch which are fixed in
master, we can backport the fixed as long as they are not so big. If
there is something missing, just ask on the mainling list.
Since
Hi,
The OpenWrt community is proud to announce the first release candidate
of the upcoming OpenWrt 21.02 stable version series. It incorporates
over 5800 commits since branching the previous OpenWrt 19.07 release and
has been under development for about one and a half year.
WPA3 support inc
On 4/22/21 7:08 AM, DENG Qingfang wrote:
The new EEE patch is accepted upstream, so backport it and replace the
current one.
Cc: René van Dorst
Signed-off-by: DENG Qingfang
---
...-mt7530-Add-support-for-EEE-features.patch | 120 +
...-mt7530-Add-support-for-EEE-features.pat
On 5/1/21 4:01 PM, DENG Qingfang wrote:
Hi Hauke,
On Sat, May 1, 2021 at 9:48 PM Hauke Mehrtens wrote:
These patches are now applied in a different order compared to the
upstream kernel, could you please have a look.
I think we should move 0600~0602 patches to backport-5.4, then apply
On 5/1/21 7:53 PM, Ilya Lipnitskiy wrote:
On Sat, May 1, 2021 at 7:32 AM DENG Qingfang wrote:
Hi Hauke,
On Sat, May 1, 2021 at 10:06 PM Hauke Mehrtens wrote:
Yes, I think that is a good idea.
Will you prepare a patch?
While trying that, I found some patches in pending-5.4 that are also
This backports a fix for the low priority CVE-2021-28831:
decompress_gunzip.c in BusyBox through 1.32.1 mishandles the error bit
on the huft_build result pointer, with a resultant invalid free or
segmentation fault, via malformed gzip data.
Signed-off-by: Hauke Mehrtens
---
package/utils
The removed patches were applied upstream and are not needed any more.
Signed-off-by: Hauke Mehrtens
---
I will create an official backports release soon, this is only for testing for
now.
package/kernel/mac80211/Makefile | 6 +-
.../ath/500-ath9k_eeprom_debugfs.patch
ltq-vdsl-app.
Log in addition the following error message:
* pkg_hash_check_unresolved: can not find dependency ltq-dsl-base for
ltq-vdsl-app
Signed-off-by: Hauke Mehrtens
---
I am not sure if this would happen in normal cases too and spam the
error log, I only saw this in an error case
Signed-off-by: Hauke Mehrtens
---
package/network/utils/ltq-dsl-base/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/network/utils/ltq-dsl-base/Makefile
b/package/network/utils/ltq-dsl-base/Makefile
index aae07bc29925..2ff069ca4dc7 100644
--- a/package/network/utils/ltq
This backports a fix from dropbear 2020.81.
CVE-2020-36254 description:
scp.c in Dropbear before 2020.79 mishandles the filename of . or an empty
filename, a related issue to CVE-2018-20685.
Signed-off-by: Hauke Mehrtens
---
.../patches/001-fix-CVE-2020-36254.patch | 21
The removed patches were applied upstream.
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/Makefile | 6 +-
.../ath/500-ath9k_eeprom_debugfs.patch| 4 +-
.../ath/512-ath9k_channelbw_debugfs.patch | 4 +-
.../patches/ath/530-ath9k_extra_leds.patch| 10
When the channels property
was set nothing changes.
Revert "mac80211: create channel list for fixed channel operation"
This reverts commit cfd2f3bf6f4825b66e9a4ca9cba7c65b93eb89c7.
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 3 ---
fix the image builder for some of these packages.
Signed-off-by: Hauke Mehrtens
---
package/firmware/amd64-microcode/Makefile | 2 ++
package/firmware/cypress-nvram/Makefile| 2 ++
package/firmware/intel-microcode/Makefile | 2 ++
package/firmware/layerscape/fman-ucode
On 5/3/21 2:38 PM, Baptiste Jonglez wrote:
Hi,
On 02-05-21, Hauke Mehrtens wrote:
When a package is not installed because it has unresolved dependencies
normally we get only an error message like this:
* pkg_hash_fetch_best_installation_candidate: Packages for ltq-vdsl-app
found, but
Hi David,
On 5/3/21 1:14 AM, David Bauer wrote:
Hi Hauke,
On 5/3/21 12:23 AM, Hauke Mehrtens wrote:
This change removes setting the channels property by default to the
channel property if nothing else is specified.
When hostapd detects a DFS alarm and it has to switch channels allow
hostapd
Hi,
OpenWrt 21.02 currently ships with wolfssl and LuCI for http.
It would be nice to also have https support included in the default images.
To add this the following packages have to be added:
* luci-ssl (969 Bytes ipkg)
* px5g-wolfssl (5216 bytes ipkg)
For me the images increased by 2.2
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key which is used to sign the master feeds.
If one of the other keys would be compromised this would not affect
users of master snapshot builds.
Signed-off-by: Hauke Mehrtens
---
As far as I know the
On 5/14/21 12:17 PM, Paul Spooren wrote:
Hi,
On 5/13/21 1:32 AM, Hauke Mehrtens wrote:
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key which is used to sign the master feeds.
If one of the other keys would be compromised this would not affect
On 5/15/21 1:34 AM, Daniel Golle wrote:
On Fri, May 14, 2021 at 11:31:27PM +0200, Hauke Mehrtens wrote:
On 5/14/21 12:17 PM, Paul Spooren wrote:
Hi,
On 5/13/21 1:32 AM, Hauke Mehrtens wrote:
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key
On 5/16/21 2:30 AM, Fernando Frediani wrote:
On 15/05/2021 18:57, Alberto Bursi wrote:
If HTTPS is still an optional it makes no sense to treat it
differently from all other optional packages.
The only moment it should be included by default is when it becomes
mandatory, and the HTTP interfa
On 5/14/21 4:22 PM, Etienne Champetier wrote:
Hi All,
Le ven. 14 mai 2021 à 05:00, Petr Štetiar a écrit :
Fernando Frediani [2021-05-11 20:13:18]:
Hi,
I am no sure https support should still be something by default in the
images as it's not something really essential
to me it's like dis
On 5/15/21 4:44 PM, Daniel Golle wrote:
On Sat, May 15, 2021 at 04:28:58PM +0200, Hauke Mehrtens wrote:
On 5/15/21 1:34 AM, Daniel Golle wrote:
On Fri, May 14, 2021 at 11:31:27PM +0200, Hauke Mehrtens wrote:
On 5/14/21 12:17 PM, Paul Spooren wrote:
Hi,
On 5/13/21 1:32 AM, Hauke Mehrtens
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key which is used to sign the OpenWrt 21.02 feeds.
If one of the other keys would be compromised this would not affect
users of 21.02 release builds.
Signed-off-by: Hauke Mehrtens
---
package/system
From: Petr Štetiar
49283916005d usign: add 21.02 release build pubkey
bc4d80f064f2 gpg: add OpenWrt 21.02 signing key
Signed-off-by: Petr Štetiar
(cherry picked from commit 1bf6d70e60fdb45d81a8f10b90904cef38c73f70)
---
package/system/openwrt-keyring/Makefile | 6 +++---
1 file changed, 3 inser
.
Signed-off-by: Hauke Mehrtens
---
package/system/openwrt-keyring/Makefile | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/package/system/openwrt-keyring/Makefile
b/package/system/openwrt-keyring/Makefile
index 6f3aa65622..037809a667 100644
--- a/package/system/openwrt
On 5/16/21 3:26 PM, Hauke Mehrtens wrote:
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key which is used to sign the OpenWrt 21.02 feeds.
If one of the other keys would be compromised this would not affect
users of 21.02 release builds.
Signed
This applies the FragAttack patches also to ath10k-ct.
Signed-off-by: Hauke Mehrtens
---
I do not have a ath10k device close here at the moment, it would be nice
if someone could check if this works fine.
package/kernel/ath10k-ct/Makefile | 2 +-
...PN-replay-protection-for
On 5/16/21 11:04 PM, Sven Roederer wrote:
Hannu,
thanks for your support to narrow this down.
Am Sonntag, 2. Mai 2021, 18:43:20 CEST schrieb Hannu Nyman:
Sounds like a bug, but it should be named something like "Misleading opkg
catch-all error message 'incompatible architecture' "
Made http
.hpp:52:56: error: ISO C++17 does not allow dynamic exception specifications
52 | const section &get_section(unsigned int i) const throw
(std::out_of_range) { return *sections.at(i); };
Signed-off-by: Hauke Mehrtens
---
tools/mklibs/Makefile | 1 +
1 file changed, 1 insertion(+)
diff
On 4/19/21 11:16 PM, Paul Spooren wrote:
On 4/19/21 9:45 AM, Hauke Mehrtens wrote:
Since OpenWrt 21.02 we use https for our download server, detect these
URLs too.
Signed-off-by: Hauke Mehrtens
---
Can't you kick out anything lede-project related while at it?
I will have a look a
On 5/17/21 8:10 PM, Paul Spooren wrote:
On 5/16/21 3:57 PM, Hauke Mehrtens wrote:
On 5/16/21 3:26 PM, Hauke Mehrtens wrote:
Instead of adding all public signature keys from the openwrt-keyring
repository only add the key which is used to sign the OpenWrt 21.02
feeds.
If one of the other
On 5/18/21 7:03 PM, Robert Marko wrote:
5.10.37 introduced a lot of DVFS changes for Armada 37xx from 5.13 kernel.
Unfortunately commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/cpufreq/armada-37xx-cpufreq.c?h=v5.10.37&id=a13b110e7c9e0dc2edcc7a19d4255fc88ab
On 5/15/21 1:10 AM, David Adair wrote:
This provides a way to override the ccache ENABLE_DOCUMENTATION=OFF
setting and restore previous behavior. It is optional since the
default required to disable the doc build (and avoid the non-ascii
character build failures) is !="y".
It could potentially
On 4/18/21 9:46 AM, Daniel Danzberger wrote:
The firmware consists of 2 images:
- cpt8x-mc-ae.out
- cpt8x-mc-se.out
Both are required and requests by the kernel module 'cptpf'
(drivers/crypto/cavium/cpt) to provide hardware crpyto support
on cavium platforms like the octeontx
Signed-off-by:
On 5/22/21 5:00 PM, André Valentin wrote:
The bootloader happily accepts this.
But devices need a fresh reinstall because of resulting ubi partition
changes. Therefore a sysupgrade will brick your device.
Please install a fresh factory image via bootloader.
Alternatively, you can flash sysupgra
Hi,
The network configuration migration in the 21.02 branch results in a
broken network configuration.
When I start with the following old network configuration:
-
config interface 'lan'
option type 'bridge'
option ifn
list ports 'lan0'
list ports 'lan1'
-
Fixes: 74be304e541f ("treewide: use "device" option in UCI "interface"
sections")
Signed-off-by: Hauke Mehrtens
---
.../resources/view/network/in
ke of simplicity and reliability use 2 steps migration. The
downside is that users may get prompted twice to migrate.
Reported-by: Hauke Mehrtens
Fixes: 74be304e541f ("treewide: use "device" option in UCI "interface"
sections")
Signed-off-by: Rafał Miłecki
Tested-
On 5/29/21 10:25 PM, e9hack wrote:
Hi,
it looks like that Luci->Network->Interfaces is broken. It shows a
NotFountError (Resource not found) message. My build from 22.05. forces
me to convert something related to network configuration. Afterwards,
this dialogue shows the interface configura
Hi,
The OpenWrt community is proud to announce the second release candidate
of the upcoming OpenWrt 21.02 stable version series. It incorporates
over 5800 commits since branching the previous OpenWrt 19.07 release and
has been under development for about one and a half year.
Changes between
On 5/9/21 7:32 PM, Birger Koblitz wrote:
realtek: Fix buffer length calculation on RTL8380 with CRC offload
Fixes the buffer and packet length calculations for Ethernet TX on
the RTL8380 SoC when CRC calculation offload is enabled.
CRC-offload is always done by the SoC, but additional CRC
calcul
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/Makefile | 6 +++---
...rolling-support-for-various-chipsets.patch | 2 +-
...700-mwl8k-missing-pci-id-for-WNR854T.patch | 2 +-
...940-mwl8k_init_devices_synchronously.patch | 4 ++--
.../100-remove-cryptoapi
On 6/6/21 9:56 AM, Hannu Nyman wrote:
Paul Spooren kirjoitti 5.6.2021 klo 22.49:
Sounds good to me. Do you mind investigate what other packages are
affected
I went through the ~60 instances of "nonshared" packages in the main
OpenWrt repo, and found that toggling six packages to nonshared wo
ltq-vdsl-app.
Log in addition the following error message:
* pkg_hash_check_unresolved: cannot find dependency ltq-dsl-base for
ltq-vdsl-app
Signed-off-by: Hauke Mehrtens
---
I am not sure if this would happen in normal cases too and spam the
error log, I only saw this in an error case.
Could
On 6/8/21 1:10 PM, Bjørn Mork wrote:
Tested-by: Bjørn Mork
Unrelated, but confused the hell out of me:
I tested this by sysupgrading from a master based installation using a
5.10 kernel. And ended up with a tmpfs overlay because of:
[9.833676] UBIFS (ubi0:1): Mounting in unauthenticated
m_na502.dts
create mode 100644 target/linux/ramips/dts/mt7621_tplink_archer-a6-v3.dts
create mode 100644 target/linux/ramips/dts/mt7621_tplink_archer-c6u-v1.dts
create mode 100644 target/linux/ramips/dts/mt7621_zyxel_nr7101.dts
create mode 100644 tools/firmware-utils/src/zytrx.c
Acke
Hi,
The OpenWrt community is proud to announce the third release candidate
of the upcoming OpenWrt 21.02 stable version series. It incorporates
over 5800 commits since branching the previous OpenWrt 19.07 release and
has been under development for about one and a half year.
Changes between O
Hi,
I am unable to send and receive packets directly on the lan1 interface
when it is not part of a bridge.
I have seen this on today's OpenWrt master.
I changed the OpenWrt network configuration like this:
--
root@OpenWrt:/# cat /etc/config/network
config interface '
network in failsafe on systems with DSA work.
Signed-off-by: Hauke Mehrtens
---
package/base-files/files/lib/preinit/10_indicate_preinit | 6 ++
1 file changed, 6 insertions(+)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/l
Some interfaces have a VLAN modifier like :t in lan1:t, this modifier
should be removed from the interface before calling preinit_ip_config().
Signed-off-by: Hauke Mehrtens
---
package/base-files/files/lib/preinit/10_indicate_preinit | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package
rk for
bridges")
Signed-off-by: Hauke Mehrtens
---
.../files/lib/preinit/10_indicate_preinit | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_in
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
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
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
On 6/21/21 12:42 AM, Paul Spooren wrote:
Not sure but is this PR related?
"base-files: bring up vlan interface too #2734"
https://github.com/openwrt/openwrt/pull/2734
This looks like a different problem, I am not sure if we run into it
with our current code.
Hauke
OpenPGP_0x93DD20630910B5
On 6/21/21 3:58 PM, Rafał Miłecki wrote:
On 19.06.2021 20:36, 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 configure the LAN
network.
This works with swconfig configurations.
Fixes: FS#3866
Some interfaces have a VLAN modifier like :t in lan1:t, this modifier
should be removed from the interface before calling preinit_ip_config().
Signed-off-by: Hauke Mehrtens
---
package/base-files/files/lib/preinit/10_indicate_preinit | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package
show
port vlan-id
lan1 1 PVID Egress Untagged
switch1 PVID Egress Untagged
Signed-off-by: Hauke Mehrtens
---
.../lib/preinit/05_set_preinit_iface_realtek| 13 +
.../lib/preinit/98_remove_preinit_realtek | 6 ++
2 files
rk for
bridges")
Signed-off-by: Hauke Mehrtens
---
.../base-files/files/lib/preinit/10_indicate_preinit | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/package/base-files/files/lib/preinit/10_indicate_preinit
b/package/base-files/files/lib/preinit/10_in
opening
user port"
* use ifname variable in preinit_config_board
* Added "realtek: Fix failsafe mode"
* Added "base-files: bring up vlan interface too"
Hauke Mehrtens (4):
kernel: Backport patch to automatically bring up DSA master when
opening user port
base-file
From: Luiz Angelo Daros de Luca
Vlan subinterface was never brought up when using vlan-based preinit network.
Tested forcing ifname="" before preinit_ip() on a Tp-Link Archer C5v4.
Signed-off-by: Luiz Angelo Daros de Luca
---
package/base-files/files/lib/preinit/10_indicate_preinit | 3 +++
1
Without this patch we have to manually bring up the CPU interface in
failsafe mode.
This was backported from kernel 5.12.
Signed-off-by: Hauke Mehrtens
---
...425-at803x-allow-sgmii-aneg-override.patch | 2 +-
...cally-bring-up-DSA-master-when-openi.patch | 85 +++
...r-when-a
On 6/26/21 10:15 AM, Hannu Nyman wrote:
Looks like the packages buildbot is somehow stuck. No new builds has
been uploaded since Tuesday 22nd.
https://downloads.openwrt.org/snapshots/packages/
Buildbot status shows only janitor activity for the last four days.
https://buildbot.openwrt.org/maste
On 6/24/21 11:13 PM, Sven Roederer wrote:
Am Sonntag, 20. Juni 2021, 17:11:08 CEST schrieb Hauke Mehrtens:
On 6/20/21 4:30 PM, Sven Roederer wrote:
The Rb750 is DSA, so it seems there is still something wrong. I'll retest
with current master soon, to rule out issues based on 21.02-rc3.
("mac80211: remove patches stripping down crypto support")
Signed-off-by: Hauke Mehrtens
---
package/kernel/lantiq/ltq-deu/Makefile | 2 +-
target/linux/lantiq/image/ar9.mk | 15 ++-
target/linux/lantiq/image/danube.mk| 1 -
target/linux/lantiq/xrx200/target.mk
should already have the priority for build resources.
It is probably a good idea to switch some of the resources there are
also much less commits in the 19.07 branch.
Hauke
On 2021-06-26 13:59, Hauke Mehrtens wrote:
On 6/26/21 10:15 AM, Hannu Nyman wrote:
Looks like the packages buildbot is some
On 6/27/21 9:38 AM, Martin Blumenstingl wrote:
Hi Hauke,
On Sun, Jun 27, 2021 at 12:55 AM Hauke Mehrtens wrote:
When the ltq_deu_vr9 kernel module is loaded, hostapd does not start any
more. it fails with thgis error message:
daemon.err hostapd: nl80211: kernel reports: key addition failed
-managed-switches/57875
I did not have time to test it so far, though.
Birger
On 22/06/2021 00:45, Hauke Mehrtens wrote:
The RTL8380-RTL9300 switches only forward packets when VLAN ID 1 is
configured. Do not use the standard failsafe configuration for DSA
accessing the default port directly
On 6/28/21 12:13 AM, Aleksander Bajkowski wrote:
Kestrel says here[1] that he has managed to fix the ltq-deu driver.
1.
https://github.com/openwrt/openwrt/commit/e85180d90ed01ef4fb89675702622a9cabf3b092
Thank you for the link.
I also saw this pull request:
https://github.com/openwrt/openwrt
Hi,
In general the 21.02-rc3 looks good, but we still have some problems.
Currently we still have these problem:
- IPv6 broken with flow offloading (according to reports, potentially
related to hw flow offloading)
- PPPoE allegedly broken (according to reports, not fully reproducible,
likely
OpenWrt.
Best,
Rich
Hauke
On Jul 17, 2021, at 11:45 AM, Hauke Mehrtens wrote:
Hi,
In general the 21.02-rc3 looks good, but we still have some problems.
Currently we still have these problem:
- IPv6 broken with flow offloading (according to reports, potentially related
to hw
Hi Hans,
On 7/17/21 5:45 PM, Hauke Mehrtens wrote:
Hi,
In general the 21.02-rc3 looks good, but we still have some problems.
Currently we still have these problem:
- DHCPv6 broken if lease times < 12h chosen
- https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candid
On 7/22/21 6:54 PM, Arınç ÜNAL wrote:
Avoid 88W8964 firmware 9.3.2.12 for Wi-Fi instabilities it causes on Linksys
WRT3200ACM & WRT32X until fixes on master branch are backported to
openwrt-21.02.
Which changes in master which are not backported are fixing this problem?
Hauke
__
On 7/20/21 11:51 AM, Gocool.. wrote:
If the "logread" process is blocked in write call or stopped by
pressing "CTRL+Z", the logd starts to buffer all the messages
in the write buffer. Since there is no limit in w.max_buffers,
the logd consumes all the system memory at a point of time which
trigge
Hi Robert,
Could you plase comment on this?
Hauke
On 7/19/21 1:46 PM, Josef Schlehofer wrote:
Based on the discussion on the mailing list [1], the patch which was
reverted, it reverts only one patch without the subsequent ones.
This leads to the SoC scaling issue not using a CPU parent clock,
801 - 900 of 1860 matches
Mail list logo
