Hey,
>>
>> There's an ongoing discussion in the ModemManager package in github
>> related to how the MTU may be configured in the network interface
>> based on what the MM bearer object reports:
>> https://github.com/openwrt/packages/issues/11383
>>
>> E.g.:
>>
>> $ ip route show
>> default via
From: Linus Lüssing
16MB are not enough for ath10k to initialize three 4x4 AC Wave 2
PCIe cards
(168c:0046: Qualcomm Atheros QCA9984 802.11ac Wave 2 Wireless Network Adapter).
This leads to the following error when trying to initialize the third
one:
[ 16.742475] ath10k_pci 0002:01:00.0: pci
This new section allows us to assign mac specific key/vid settings to a
station.
Signed-off-by: John Crispin
---
config.c | 29
scripts/netifd-wireless.sh | 24 +++
wireless.c | 134 -
wireless.h
> -Original Message-
> From: Linus Lüssing [mailto:l...@simonwunderlich.de]
> Sent: Montag, 25. Mai 2020 12:14
> To: m...@adrianschmutzler.de; 'Linus Lüssing' ;
> openwrt-devel@lists.openwrt.org
> Cc: 'Sven Eckelmann'
> Subject: Re: [OpenWrt-Devel] [PATCH] layerscape: kernel: cma:
Hi all,
while there has been a lot of progress during the last months, there are still
a few target that have not been updated to 5.4 (at least as testing kernel) yet:
4.19:
cns3xxx
4.14:
ar71xx (to be removed)
arc770 (RFT patch:
On 2020-05-25 10:31, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> After more reviews is seems that blobmsg_for_each_attr() should not be
> used when dealing with untrusted data as it reads length from blob data
> itself. It means it can't be used in the blobmsg_check_array_len().
>
> Switch
On 25/05/2020 11:25, m...@adrianschmutzler.de wrote:
[...]
Despite, armv7 uses 64 MB ?
Hm, you're right. Not sure, I wouldn't increase the CMA buffer more as
needed though, as any unused CMA space is basically wasted, it can't be
used for caches etc right now.
But I can increase it to 64
This new section allows us to create apvlan settings for hostapd.
Signed-off-by: John Crispin
---
config.c | 42 ++-
scripts/netifd-wireless.sh | 42 ++-
wireless.c | 247 +++--
wireless.h | 23 +++-
4
Felix Fietkau [2020-05-25 10:51:36]:
Hi,
> I think your previous fix is completely fine as-is.
just FYI Rafał's fix triggered fuzzer CI failure[1], regression, I'm able to
reproduce it localy so it's not false positive. So perhaps there's some
additional check missing somewhere?
$ echo
We currently support three kernel versions on this target, let's
just get rid of the oldest one.
Cc: Rafał Miłecki
Signed-off-by: Adrian Schmutzler
---
target/linux/bcm47xx/config-4.14 | 215
...-Add-Luxul-XAP1500-XWR1750-WiFi-LEDs.patch | 86 ---
Hi Linus,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Linus Lüssing
> Sent: Montag, 25. Mai 2020 09:40
> To: openwrt-devel@lists.openwrt.org
> Cc: Linus Lüssing ; Sven Eckelmann
>
> Subject: [OpenWrt-Devel] [PATCH]
On Wednesday, 20 May 2020 09:39:45 CEST Sebastian Gottschall wrote:
[...]
> could somone clarify the state here and why it was dropped?
> the original patch i wrote does exclude the soc chipsets, but the patch
> was later reorganized and some part have been rewritten
> so i'm not sure if it
Am 25.05.2020 um 11:22 schrieb Sven Eckelmann:
On Wednesday, 20 May 2020 09:39:45 CEST Sebastian Gottschall wrote:
[...]
could somone clarify the state here and why it was dropped?
the original patch i wrote does exclude the soc chipsets, but the patch
was later reorganized and some part have
From: Rafał Miłecki
After more reviews is seems that blobmsg_for_each_attr() should not be
used when dealing with untrusted data as it reads length from blob data
itself. It means it can't be used in the blobmsg_check_array_len().
Switch back to using __blobmsg_for_each_attr() BUT pass correct
On 25.05.20 13:11, Zoltan HERPAI wrote:
Hi,
On 5/25/2020 12:42, m...@adrianschmutzler.de wrote:
Hi all,
while there has been a lot of progress during the last months, there
are still a few target that have not been updated to 5.4 (at least as
testing kernel) yet:
4.19:
cns3xxx
4.14:
On 2020-05-25 02:19, Eneas U de Queiroz wrote:
> Individual packages may turn off MIPS16 ISA individually with
> PKG_USE_MIPS16. However, they may link to a library compiled with
> MIPS16. In such cases, the -minterlink-mips16 is needed to ensure there
> are no direct jumps to code compiled with
Rafał Miłecki [2020-05-25 10:31:06]:
Hi,
> From: Rafał Miłecki
>
> After more reviews is seems that blobmsg_for_each_attr() should not be
> used when dealing with untrusted data as it reads length from blob data
> itself. It means it can't be used in the blobmsg_check_array_len().
>
> Switch
Hi,
On 5/25/2020 12:42, m...@adrianschmutzler.de wrote:
Hi all,
while there has been a lot of progress during the last months, there are still
a few target that have not been updated to 5.4 (at least as testing kernel) yet:
4.19:
cns3xxx
4.14:
ar71xx (to be removed)
arc770 (RFT patch:
On Mon, May 25, 2020 at 5:06 AM Felix Fietkau wrote:
>
> On 2020-05-25 02:19, Eneas U de Queiroz wrote:
> > Individual packages may turn off MIPS16 ISA individually with
> > PKG_USE_MIPS16. However, they may link to a library compiled with
> > MIPS16. In such cases, the -minterlink-mips16 is
Yes, it appears we can handle uclibc the same way
Uclibc-ng supports SSP in the library itself, so use of GCC_LIBSSP can
eliminated. I'll do some testing ...
config UCLIBC_HAS_SSP
bool "Support for GCC stack smashing protector"
depends on !HAVE_NO_SSP
help
Add
On 4/13/20 12:33 PM, Adrian Schmutzler wrote:
> Update config with make kernel_oldconfig and copy patch.
>
> Directly switch to kernel 5.4.
>
> Signed-off-by: Adrian Schmutzler
>
> ---
>
> I just stupidly copied/refreshed the patch and the config.
>
> Build-tested, run-test required as I
This patch adds support for 2 new uci sections.
config wifi-vlan
# iface is optional. if it is not defined the vlan will apply
# to all interfaces
option ifacedefault_radio0
option name guest
option vid 100
option network guest
config
blobmsg_check_attr_len was calling blobmsg_check_data for some, but not all
attribute types. These checks was missing for arrays and tables.
Additionally, the length check in blobmsg_check_data was a bit off, since
it was comparing the blobmsg data length against the raw blob attr length.
Fix
blobmsg_check_array_len expects the length of the full attribute buffer,
not just the data length.
Due to other missing length checks (fixed in the next commit), this did
not show up as a test failure
Signed-off-by: Felix Fietkau
---
blobmsg.c | 2 +-
1 file changed, 1 insertion(+), 1
blobmsg_hdr_valid_namelen was omitted when name==false
The blob_len vs blobmsg_namelen changes were not taking into account
potential padding between name and data
Signed-off-by: Felix Fietkau
---
blobmsg.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git
On Monday, 25 May 2020 11:22:13 CEST Sven Eckelmann wrote:
[...]
> And it still can with this OpenWrt version. But it doesn't seem to happen
> with
> the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000
> commits inbetween. So no idea what changed (just a timing thing or
Hey,
> >> There's an ongoing discussion in the ModemManager package in github
> >> related to how the MTU may be configured in the network interface
> >> based on what the MM bearer object reports:
> >> https://github.com/openwrt/packages/issues/11383
> >>
> >> E.g.:
> >>
> >> $ ip route show
>
On Mon, May 25, 2020 at 8:00 AM Aleksander Morgado
wrote:
> Other protocol handlers, like uqmi, are also able to setup the MTU,
> and instead of doing it via proto_send_update, they just do it like
> this:
>
> [ -n "$mtu" ] && {
> echo "Setting MTU to $mtu"
>
On 25.05.2020 17:19, Felix Fietkau wrote:
blobmsg_hdr_valid_namelen was omitted when name==false
The blob_len vs blobmsg_namelen changes were not taking into account
potential padding between name and data
Signed-off-by: Felix Fietkau
Tested-by: Rafał Miłecki
On 25.05.2020 17:19, Felix Fietkau wrote:
blobmsg_check_attr_len was calling blobmsg_check_data for some, but not all
attribute types. These checks was missing for arrays and tables.
Additionally, the length check in blobmsg_check_data was a bit off, since
it was comparing the blobmsg data
On 25.05.2020 17:19, Felix Fietkau wrote:
blobmsg_check_array_len expects the length of the full attribute buffer,
not just the data length.
Due to other missing length checks (fixed in the next commit), this did
not show up as a test failure
Signed-off-by: Felix Fietkau
Tested-by: Rafał
* MediaTek MT7620A (580 Mhz)
* 8 MB of FLASH
* 64 MB of RAM
* 2.4Ghz and 5.0Ghz radios both now functional
* 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
* UART header on PCB (57600 8n1)
* Green/Orange Power LEDs illuminating a Power-Button Lens
Green/Orange Internet LEDs GPIO controlled
* MediaTek MT7620A (580 Mhz)
* 8 MB of FLASH
* 64 MB of RAM
* 2.4Ghz and 5.0Ghz radios both now functional
* 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
* UART header on PCB (57600 8n1)
* Green/Orange Power LEDs illuminating a Power-Button Lens
Green/Orange Internet LEDs GPIO controlled
* MediaTek MT7620A (580 Mhz)
* 8 MB of FLASH * 64 MB of RAM
* 2.4Ghz and 5.0Ghz radios both now functional
* 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
* UART header on PCB (57600 8n1)
* Green/Orange Power LEDs illuminating a Power-Button Lens
Green/Orange Internet LEDs GPIO controlled
On Mon, May 25, 2020 at 04:57:36PM -0700, Heppler, J. Scott wrote:
>
> * MediaTek MT7620A (580 Mhz)
> * 8 MB of FLASH
> * 64 MB of RAM
> * 2.4Ghz and 5.0Ghz radios both now functional
> * 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
> * UART header on PCB (57600 8n1)
> * Green/Orange Power LEDs
On Mon, May 25, 2020 at 05:05:16PM -0700, Heppler, J. Scott wrote:
>
> * MediaTek MT7620A (580 Mhz)
> * 8 MB of FLASH
> * 64 MB of RAM
> * 2.4Ghz and 5.0Ghz radios both now functional
> * 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
> * UART header on PCB (57600 8n1)
> * Green/Orange Power LEDs
Gcc's libssp is a standalone userspace implementation of SSP that
makes gcc incompatible with kernel stack protection. Builds using
libssp cannot enable kernel stack protection due to the insertion
of an incompatible stack canary by libssp-enabled gcc.
All three C libraries supported by OpenWrt
Removes the standalone implementation of stack smashing protection
in gcc's libssp in favour of the native implementation in musl,
glibc and uClibc and introduces a uniform configuration interface.
This also makes kernel-level stack smashing protection available
for builds using non-musl libc
38 matches
Mail list logo
