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 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
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
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
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 '
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
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
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
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/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
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 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
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/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
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-
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
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
on support optionally.
To use the Python support in gdb some extra python files are needed,
install them too. While at it also install other shared files which we
did not install before.
If gdb is built without Python support the python folder does not
exists.
Signed-off-by: Hauke Mehrtens
---
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
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/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 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/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 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
.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 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
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 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
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
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
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
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/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/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/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
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
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
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
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
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
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 ---
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
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
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
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
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
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
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
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 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
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/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
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/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
On 4/7/21 12:29 AM, Hauke Mehrtens wrote:
Hi,
How do we want to go forward with OpenWrt 21.02-rc1?
* I think the base system is ok.
* The http (original wolfssl) problem reported by jow is fixed
* LuCI in the 21.02 branch still misses DSA support, this was merged
into master some time ago as
On 4/9/21 5:48 PM, Rui Salvaterra wrote:
These have long been obsolete. For reference, here's the Linux version where
each symbol has been dropped:
CONFIG_IP6_NF_QUEUE - 3.5
CONFIG_IP6_NF_TARGET_LOG - 3.4
CONFIG_IP_NF_MATCH_DSCP - 2.6.19
CONFIG_NF_CONNTRACK_IPV4 - 4.19
CONFIG_NF_CONNTRACK_IPV6 -
On 4/13/21 6:03 AM, Rosen Penev wrote:
For some reason, fortified mempcpy does not work with GCC 10.3. It
worked with GCC 10.2.
Some output with tvheadend:
error: 'mempcpy' undeclared here (not in a function);
did you mean 'memccpy'?
144 | _FORTIFY_FN(mempcpy) void *mempcpy(void *__d,
const voi
On 4/13/21 10:02 AM, Linus Walleij wrote:
On Mon, Apr 12, 2021 at 8:32 PM Christian Lamparter wrote:
Hmm, when building this with the BUILDBOT config (CONFIG_BUILDBOT)
and throw in the CONFIG_ALL_* for userspace + kernel modules for
good measure. It fails with the default world build (without
Signed-off-by: Bjørn Mork
Acked-by: Hauke Mehrtens
---
.../realtek/base-files/etc/board.d/02_network | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
b/target/linux/realtek/base-files/etc/board.d/0
Hi,
On 4/11/21 7:51 PM, Martin Blumenstingl wrote:
Hello everyone,
you are included in this email because you have previously worked on
patches for the Lantiq SoCs upstream.
In the past updating the kernel version for the lantiq target in
OpenWrt was an unpleasant task.
There are many out-of-t
valgrind does not compile any more when using a GCC 10 for MIPS with
soft float. Just remove the parts which are generating assembler which
would not work.
Signed-off-by: Hauke Mehrtens
---
.../patches/130-mips_fix_soft_float.patch | 68 +++
1 file changed, 68 insertions
Signed-off-by: Hauke Mehrtens
---
toolchain/gcc/Config.version| 2 +-
toolchain/gcc/common.mk | 4 ++--
.../patches/{10.2.0 => 10.3.0}/002-case_insensitive.patch | 0
.../gcc/patches/{10.2.0 => 10.3.0}/010-documentation
removed
with kernel 5.10, probably because of the same problems. I think it is
not needed anyway as the compiler should automatically optimize the
calls to memset(), memcpy() and memmove() even when not explicitly
telling the compiler to use the build in variant.
Signed-off-by: Hauke Mehrtens
---
I
On 4/7/21 12:29 AM, Hauke Mehrtens wrote:
Hi,
How do we want to go forward with OpenWrt 21.02-rc1?
* I think the base system is ok.
* The http (original wolfssl) problem reported by jow is fixed
* LuCI in the 21.02 branch still misses DSA support, this was merged
into master some time ago as
On 4/7/21 12:29 AM, Hauke Mehrtens wrote:
Hi,
How do we want to go forward with OpenWrt 21.02-rc1?
* I think the base system is ok.
* The http (original wolfssl) problem reported by jow is fixed
* LuCI in the 21.02 branch still misses DSA support, this was merged
into master some time ago as
Hi,
How do we want to go forward with OpenWrt 21.02-rc1?
* I think the base system is ok.
* The http (original wolfssl) problem reported by jow is fixed
* LuCI in the 21.02 branch still misses DSA support, this was merged
into master some time ago as far as I understood.
Jow reported this end
eader
libcap: bump to 2.48
lldpd: add libcap dependency
Acked-by: Hauke Mehrtens
I am not a lldpd user so I can not say if we should make it depend on
libcap, but I saw some packages which has implicit dependencies.
Hauke
___
openwrt-devel mailing
On 4/4/21 11:06 PM, Daniel González Cabanelas wrote:
The crypto engine in Armada 370 SoCs is currently broken. It can be
checked installing the required packages for testing openssl with hw
acceleration:
opkg install openssl-util
opkg install kmod-cryptodev
opkg install libopenssl-devcr
On 8/31/20 10:51 PM, Rosen Penev wrote:
On Aug 31, 2020, at 9:41 AM, Hauke Mehrtens wrote:
On 8/31/20 11:35 AM, Petr Štetiar wrote:
Rosen Penev [2020-08-31 02:06:50]:
I compile with target GCC 10, not host.
Then as you can see its probably some issue with GCC 10 for that target
On 3/30/21 10:53 AM, Paul Spooren wrote:
The ./usign folder is added to every OpenWrt image, it should only
contain the most necessary keys. At this point it contains both a
selection of personal developer keys and keys of EOL releases.
Remove them all and only keep the 21.02 key.
A future comm
On 4/3/21 4:53 PM, Sven Roederer wrote:
Happy easter all and thanks for branching 21.02.
Holidays and lockdown give me some time to keep-up with OpenWrt. During this I
found that 21.02 is still missing the kernel-CONFIG for RTC_DRV_JZ4740
Can someone cherry-pick 55ed4bf6d7bf80b705d015c3b73f772d
commit should add a "next release" key, which is later renamed
to the next release name (e.g. 21.08). This approach should allow secure
upgrade between releases.
Signed-off-by: Paul Spooren
Acked-by: Hauke Mehrtens
---
This commit should be merged into a `openwrt-21.02` branch whi
The CONFIG_USERIO option is unset in multiple target configurations. On
the sunxi target it is activated. Move the kernel configuration option
to the generic kernel configuration.
Signed-off-by: Hauke Mehrtens
---
target/linux/gemini/config-5.4 | 1 -
target/linux/generic/config
Instead of deactivating this in every target config, deactivate it once
in the generic kernel config. I was asked for this config option in a
x86 64 build in OpenWrt 21.02.
Signed-off-by: Hauke Mehrtens
---
target/linux/generic/config-5.10| 1 +
target/linux/generic/config-5.4
On 3/21/21 10:17 PM, Daniel Golle wrote:
Users complained that building images for various mvebu Linksys devices
fails when using the ImageBuilder, it complains about the package
'mwlwifi-firmware-88w8964' not being found.
Turns out the package builds fine in mvebu/cortex-a9 images build, but
is
. This should be easier than trying to
recover the state.
We saw this problem when /ubus/ was not installed, but the browser tried
to access it. Then uhttpd returned a 404, but the next request done in
this connection also failed with a HTTP 400, bad request.
Fixes: FS#3378
Signed-off-by: Hauke
Instead of doing uci commit and reload_config for each setting do it
only once when one of these options was changed. This should make it a
little faster when both conditions are taken.
Signed-off-by: Hauke Mehrtens
---
package/network/services/uhttpd/files/ubus.default | 10 ++
1 file
On 3/20/21 2:05 PM, Jo-Philipp Wich wrote:
Hi Hauke,
thanks for looking into it!
I have a couple of remarks...
[...]
[ "$(uci -q get uhttpd.main.ubus_socket)" = "/var/run/ubus.sock" ] && {
uci set uhttpd.main.ubus_socket='/var/run/ubus/ubus.sock'
uci commit uhttpd
+ re
accessing it without reloading uhttpd.
Signed-off-by: Hauke Mehrtens
---
package/network/services/uhttpd/Makefile | 2 +-
package/network/services/uhttpd/files/ubus.default | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/package/network/services/uhttpd/Makefile
b
On 3/20/21 8:28 PM, Hauke Mehrtens wrote:
When we run into an error like a 404 Not Found the request body is not
read and will be parsed as part of the next request. The next Request
will then fail because there is unexpected data in it.
When we run into such a problem with a request body close
. This should be easier than trying to
recover the state.
We saw this problem when /ubus/ was not installed, but the browser tried
to access it. Then uhttpd returned a 404, but the next request done in
this connection also failed with a HTTP 400, bad request.
Signed-off-by: Hauke Mehrtens
On 3/20/21 1:32 PM, Hauke Mehrtens wrote:
Without this change the config is only committed, but the uhttpd daemon
is not reloaded. This reload is needed to apply the config. Without the
reload of uhttpd, the ubus server is not available over http and returns
a Error 404.
This caused problems
Instead of doing uci commit and reload_config for each setting do it
only once when one of these options was changed. This should make it a
little faster when both conditions are taken.
Signed-off-by: Hauke Mehrtens
---
package/network/services/uhttpd/files/ubus.default | 10 ++
1 file
accessing it without reloading uhttpd.
There is another bug in uhttpd that it does not discard the request data
when it returned a http error 404 for a post request and interpret it as
part of the next request on the same TCP connection.
Signed-off-by: Hauke Mehrtens
---
package/network/services
On 3/13/21 6:52 AM, Rosen Penev wrote:
With kernel 5.10, exfat is out of staging and in tree.
Added small hack to make it work with kernel 5.4 as well.
Signed-off-by: Rosen Penev
---
package/kernel/linux/modules/fs.mk | 20
1 file changed, 20 insertions(+)
When build
This fixes writing to the U-Boot environment by making the partition
writable and setting the correct flash sector size of 128K.
Signed-off-by: Hauke Mehrtens
---
package/boot/uboot-envtools/files/mediatek| 2 +-
target/linux/mediatek/dts/mt7622-buffalo-wsr-2533dhp2.dts | 1 -
2
On 3/12/21 9:55 PM, Adrian Schmutzler wrote:
Hi,
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Hauke Mehrtens
Sent: Mittwoch, 10. März 2021 00:52
To: openwrt-devel@lists.openwrt.org
Cc: musashino.o...@gmail.com; Hauke Mehrtens
On 3/10/21 10:03 AM, INAGAKI Hiroshi wrote:
Hi Hauke,
On 2021/03/10 8:52, Hauke Mehrtens wrote:
These patches are adding support for different TRX magics and later
support for the Buffalo WSR-2533DHP2.
This was developed mostly by INAGAKI Hiroshi and I did some fixes and
cleaned the patches up
it.
Specifications (v1)
---
* SoC: MT7622 (4x4 2.4 GHz Wifi)
* Wifi: MT7615 (4x4 5 GHz Wifi)
* Flash: Winbond W29N01HZ 128MB SLC NAND
* Ethernet: Realtek RTL8367S (4 x 1GBit/s, SoC via 2.5GBit/s)
Co-Developed-by: Hauke Mehrtens
Signed-off-by: Hauke Mehrtens
---
pac
This fixes some bugs in the mtk parallel nand driver introduced in 5.10.
This patch was send upstream.
Signed-off-by: Hauke Mehrtens
---
...Fix-WAITRDY-break-condition-and-time.patch | 36 +++
1 file changed, 36 insertions(+)
create mode 100644
target/linux/mediatek/patches
Buffalo uses the TRX format with a different magic, add support for
this.
It is planned to send these patches upstream.
Cc: Rafał Miłecki
Signed-off-by: Hauke Mehrtens
---
...trx-Allow-to-specify-trx-magic-in-DT.patch | 75 +++
...ove-dependency-to-BRCM-architectures.patch
From: INAGAKI Hiroshi
Buffalo uses the TRX header with a different magic and even changes this
magic with different devices. This change allows to specify the header
to use as a command line argument.
This is needed for the Buffalo WSR-2533DHP2 based on mt7622.
Co-Developed-by: Hauke Mehrtens
till I found out why kernel 5.10 is not booting. Now kernel
5.10 is working fine with this device. I can also remove the kernel 5.4
patches.
@Hiroshi: Could you please give your Signed-off-by if you are fine with this.
Hauke Mehrtens (3):
mediatek: Fix mtk parallel nand driver
tools: otrx
This allows to specify an own magic instead of using the default magic
value TRX_MAGIC. If no own magic is specified the default one will be
used.
Signed-off-by: Hauke Mehrtens
---
tools/firmware-utils/src/otrx.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git
On 3/1/21 3:54 PM, Hannu Nyman wrote:
Apparently autoconf-lean, merged into the toolchain during last weekend,
causes problems with various packages at buildbot.
I am not sure if that is due to underlying problems in the specific
failing packages, or due to a wrong site config from autoconf-le
On 2/24/21 4:50 PM, k_ronny wrote:
with u-boot v2020.07 some variables have been renamed so this patch needs to be
adjusted
otherwise at least with macOS as build system there are build errors
Signed-off-by: k_ronny
---
package/boot/uboot-envtools/patches/001-compile.patch | 4 ++--
1 file
On 2/27/21 6:00 PM, Bjørn Mork wrote:
Hauke Mehrtens writes:
I used the wrong AAHI magic and it was possible to falsh the image
over the Web UI, buit the image did not boot, it was unable to find
the root fs for me.
That's odd. Didn't work in my tests, but I've only tested
On 2/24/21 1:49 AM, sotu...@gmail.com wrote:
From: Zheng Qian
When luci unchecked the igmp snoop option for a bridge, it
just delete the igmp_snooping key from the config file.
So netifd can't change /sys/devices/virtual/net/br-lan/bridge/multicast_snooping from "1"
to "0".
This patch will se
401 - 500 of 1860 matches
Mail list logo