Can you try building from a clean build, e.g. use make distclean?
On 2/13/24 11:56, Koen Vandeputte wrote:
Hi Nick,
Regarding commit:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4a3f430d726e0713f4936844f26ccaf5077ef881
I'm seeing this when building:
Any idea how to fix
+1
Best
Nick
On 1/30/24 19:15, Christian Marangi (Ansuel) wrote:
Robert is active in OpenWrt since 2017 and with some recent stats, he
has more than 310 commits merged in OpenWrt.
He also have uncounted Reviewed-by tag on various PR and merged commits
and generally helps in everything related
Thanks a lot! I am very happy. :)
However, I just discussed with Paul that "until 16" indicates that you
may still vote on the 16th of May. I recommend waiting until those last
hours have passed in order to ensure fairness for people who may still
wish to vote.
Best
Nick
On 5/1
On 5/4/23 17:51, Stijn Segers wrote:
Hi,
Robert Marko schreef op 3 mei 2023 11:21:32 CEST:
On Wed, 3 May 2023 at 11:08, Nick wrote:
I would also love to see a release. It is now already delayed more than
a month [0] (actual branching should be happening end of march).
However, I don't have
On 5/3/23 19:23, Aleksander Bajkowski wrote:
W dniu 03.05.2023 o 19:11, Nick pisze:
On 5/3/23 11:07, Nick wrote:
I will also try to fetch me some lantiq device from somewhere to
support fixing the fdb issues and re-adding it back to 23.X or
fixing it before the branch.
I organized myself
On 5/3/23 11:07, Nick wrote:
I will also try to fetch me some lantiq device from somewhere to
support fixing the fdb issues and re-adding it back to 23.X or fixing
it before the branch.
I organized myself now a **FRITZ!Box 7320** and **TP Link TD-W8970**. So
if anyone wants me to test
to support fixing the fdb issues and re-adding it back to
23.X or fixing it before the branch.
If you branch soon, you could probably also give a talk about the new
OpenWrt release at Battlemesh v15. ;)
Bests
Nick
[0] - https://openwrt.org/meetings/20230124
On 5/1/23 18:01, Paul Spooren
/openwrt/openwrt/pull/12515#issuecomment-1531686673
Bests
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
NLA_S8 is used by newer hostapd versions. Directly add all NLA_S*
definitions.
Signed-off-by: Nick Hainke
---
attr.c | 4 ++
include/netlink/attr.h | 122 +
2 files changed, 126 insertions(+)
diff --git a/attr.c b/attr.c
index eae91e5
On 3/30/23 11:43, Nick wrote:
On 3/19/23 20:25, Hauke Mehrtens wrote:
On 3/15/23 14:37, Nick Hainke wrote:
NLA_S8 is used by newer hostapd versions.
Signed-off-by: Nick Hainke
---
attr.c | 1 +
include/netlink/attr.h | 35 +++
2 files
On 3/19/23 20:25, Hauke Mehrtens wrote:
On 3/15/23 14:37, Nick Hainke wrote:
NLA_S8 is used by newer hostapd versions.
Signed-off-by: Nick Hainke
---
attr.c | 1 +
include/netlink/attr.h | 35 +++
2 files changed, 36 insertions(+)
diff
On 3/15/23 07:30, Christian Marangi wrote:
On Wed, Mar 15, 2023 at 02:37:43PM +0100, Nick Hainke wrote:
NLA_S8 is used by newer hostapd versions.
Signed-off-by: Nick Hainke
What is the target project of this patch?
libnl-tiny
___
openwrt-devel
NLA_S8 is used by newer hostapd versions.
Signed-off-by: Nick Hainke
---
attr.c | 1 +
include/netlink/attr.h | 35 +++
2 files changed, 36 insertions(+)
diff --git a/attr.c b/attr.c
index eae91e5..abde67f 100644
--- a/attr.c
+++ b/attr.c
Maybe we could also add rust support to the release:
https://github.com/openwrt/packages/pull/19863
Bests
Nick
On 2/5/23 18:13, Hauke Mehrtens wrote:
On 1/24/23 20:48, Nick wrote:
Hey,
We have testing-support for 5.15 in almost all targets, so we may be
able to release it shortly [0]? WIP
As far as I know, device support can be backported from master into the
release branch. So you are able to add the device support if a release
already happened.
Bests
Nick
On 1/24/23 20:56, Peter Naulls wrote:
On 1/24/23 14:48, Nick wrote:
Hey,
We have testing-support for 5.15 in almost all
page [3]?
It would be great to see a new release.
Bests
Nick
[0] - https://github.com/openwrt/openwrt/issues/10672
[1] - https://github.com/openwrt/openwrt/pull/11011
[2] -
https://github.com/openwrt/openwrt/commit/d9de5252a44e208cecaa1e2edad3d1615b84302c
[3] - https://openwrt.org/docs/guide
oject/linux-wireless/patch/20180723160300.58024-3-...@nbd.name/
These are just some examples. However, I think it would be beneficial to
get closer to upstream mac80211 again?
Bests
Nick
___
openwrt-devel mailing list
openwrt-devel@lis
is enabled
Signed-off-by: Nick Hainke
---
device.c | 9 +
device.h | 3 +++
system-linux.c | 20
3 files changed, 32 insertions(+)
diff --git a/device.c b/device.c
index b3d0e85..88a192f 100644
--- a/device.c
+++ b/device.c
@@ -63,6 +63,7 @@ static co
Sorry, I did a typo when creating the PR. Fixed with:
https://github.com/openwrt/packages/pull/19368
Bests
Nick
On 9/14/22 17:12, e9hack wrote:
Hi,
commit "ae48be8e2157bc7c352b3b6d30c026fafdae4867 / iperf3: add shared
libiperf library and link iperf3 dynamically" is wrong. The ins
ge benefit having the upstream status with a
link to a mailinglist in the patch header.
What do you think?
Bests
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
.
Note: currently only seen in the TP-Link Deco S4R v2, whose support
for factory images is only theoretical since all known OEM firmwares
require vendor-signed firmware updates, but that should not stop us
from generting valid factory images.
Signed-off-by: Nick French
---
src/tplink-safeloader.c
On Sun, Aug 14, 2022 at 08:04:01AM +0200, Sander Vanheule wrote:
> Hi,
>
> On Sat, 2022-08-13 at 13:51 -0500, Nick French wrote:
> > Support creating images for TP-Link Deco S4R v2.
> >
> > Original partition layout from OEM image:
> > partition fs-uboot base 0x
-system' partitions were merged into 'firmware'
to make use of the automatic mtd split.
Signed-off-by: Nick French
---
src/tplink-safeloader.c | 43 +
1 file changed, 43 insertions(+)
diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
index
It was not cherry-picked to 21.02:
https://github.com/openwrt/openwrt/pull/10363
Bests
Nick
On 7/31/22 19:35, Hauke Mehrtens wrote:
On 7/24/22 15:28, Sakura Industries wrote:
In the ubus support patch for bss transition management responses,
the target_bssid variable is left uninitialized
Hi Joerg,
Where is this stated?
If I check the following Cisco link, this is not constrained in this
way on their products:
https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9100ax-access-points/wpa3-dep-guide-og.html
If I check the Wi-Fi alliance spec at
I don't want to spam the mailing list by repeating issues, but there is
still a serious issue with the ath79 ubnt-xm devices, that they will not
allow sysupgrade anymore due to OOM-Killer killing sysupgrade.
https://github.com/openwrt/openwrt/pull/4879
Bests,
Nick
On 3/19/22 12:07, Hauke
ity, like showing mesh routing protocols on the
front page, building WireGuard tunnels, etc. ... So remove the Freifunk
Repository, but let's work/maintain together.
Bests
Nick
[0] - https://github.com/freifunk-berlin/bbb-configs
___
openwrt-devel mail
Sysupgrade is broken on ath79 ubnt-xm, due to oom-killer killing sysupgrade.
We have two options:
1) Finding more processes to kill before doing sysupgrade
2) Move ath79 ubnt-xm to tiny like I did in the PR:
https://github.com/openwrt/openwrt/pull/4879
Bests
Nick
On 2/20/22 23:57, Hauke
Is fixed by:
https://github.com/openwrt/openwrt/pull/4882
On 12/25/21 22:02, Nick wrote:
Thanks for your answer, but it did not help. :/
I will look at the change-log again and see if something changed.
On 12/25/21 19:46, David Bauer wrote:
Hi Nick,
On 12/25/21 16:49, Nick wrote:
The flash
I think I fixed it accidentally by this PR:
https://github.com/openwrt/openwrt/pull/4879
The flash memory is not enough anymore using 5.10. I would be happy if
it could be merged, soon. Otherwise ubnt-xm targets are broken in master.
Bests
Nick
On 12/25/21 22:02, Nick wrote:
Thanks for your
Thanks for your answer, but it did not help. :/
I will look at the change-log again and see if something changed.
On 12/25/21 19:46, David Bauer wrote:
Hi Nick,
On 12/25/21 16:49, Nick wrote:
The flash-chip mx25l6405d that is contained in the Ubiquity
Nanostation M5 (XM) is not able to write
The flash-chip mx25l6405d that is contained in the Ubiquity Nanostation
M5 (XM) is not able to write to the flash with kernel 5.10. Probably,
caused by invalid block protection clearing. For example the logread
contains a lot of those messages:
jffs2: Newly-erased block contained word
Thanks a lot. However, a user still report that hostapd is crashing:
https://github.com/berlin-open-wireless-lab/DAWN/issues/151#issuecomment-949558177
Bests
Nick
On 10/21/21 17:13, David Bauer wrote:
Hi Nick,
On 10/21/21 11:31, Nick wrote:
Is someone massively utilizing the ubus interface
.
See:
https://github.com/berlin-open-wireless-lab/DAWN/issues/151#issuecomment-948192240
Bests
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
will also update the forum post with the
information! :)
Bests
Nick
On 10/13/21 10:51, Felix Fietkau wrote:
On 2021-10-13 07:53, Nick wrote:
Since I saw there were some new patches, e.g., procd, fixing
blob_buf_free() calls.
I asked several months ago: "Should you call blob_buf_free()
d. However, I would move the global
definitions to local ones?
https://git.openwrt.org/?p=project/libubox.git;a=blob;f=examples/json_script-example.c;h=6d93059a412e3c829c29df1b41c9dece8852499d;hb=HEAD#l10
Bests
Nick
On 10/13/21 07:53, Nick wrote:
Since I saw there were some new patches, e.g., pro
answer. I think blob_buf_init() is freeing memory
if it is the same buf?
Any suggestions how to use blob_buf_free?
Bests
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Why am I now allowed to edit my own bug reports on
https://bugs.openwrt.org/? (Polynomdivision)
Can someone give me the permission to do so? Why is it not default
permission for everyone?
Bests
Nick
___
openwrt-devel mailing list
openwrt-devel
On 9/30/21 21:43, Daniel Golle wrote:
On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote:
On 30/09/2021 01:19, Nick wrote:
On 9/29/21 22:28, Hauke Mehrtens wrote:
kernel 5.10:
We should get all targets to kernel 5.10. All targets which are not
on kernel 5.10 when we branch off
to release in 2022?
Bests
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
("WiFi Streaming" is just a more descriptive name for the desired wifi
behaviour.
The wifi keeps streaming packets without waiting for ACKS/Block ACKs.)
I'm working with ath10k-ct, the boot announceent shows:
[ 17.250943] ath10k_pci :00:00.0: qca988x hw2.0 target 0x4100016c
chip_id
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Yep. Thanks. Just added another patch that is fixing the issue. I went
to some internet sources and code to see how other people handle the
issue and seems like everyone is just subtracting 1. Now you also wrote
the same. :)
Bests,
Nick
On 8/31/21 10:59 AM, Felix Fietkau wrote:
On 2021-08
+1 for finally releasing. Our wireless mesh community is testing OpenWrt
21.02-snapshot now for months.
Only some trouble with ipq40xx soc, but we have workarounds for it.
On 8/29/21 12:53 PM, Adrian Schmutzler wrote:
Hi,
-Original Message-
From: openwrt-devel
Also on mt7621 Xiaomi Mi 3G v2.
On 7/26/21 8:42 PM, Chad Monroe wrote:
On Mon, Jul 26, 2021 at 10:14 AM Klaus Kudielka
wrote:
> I tried to run OpenWrt with a bleeding-edge net-next kernel (commit
0e804326759d), then noticed that only the first port of a bridge is
brought up automatically,
init#L36
However, the packages are missing:
- procd-ujail
- procd-seccomp
Installing procd-seccomp is fixing the issue. I would do a PR, but I'm
unsure what is the correct way of solving this issue.
Bests,
Nick
___
openwrt-devel mailing list
openw
Hi all,
Is this expected to contain thekelleys.org.uk?
+ [ $dbus -gt 0 ] && xappend
"--enable-dbus=uk.org.thekelleys.$instance_name"
Best,
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.o
://gist.github.com/PolynomialDivision/443e53d4dc08994a9affe3174a792d75
You can also reproduce by using our repro:
https://github.com/Freifunk-Spalter/bbb-configs
And then
ansible-playbook play.yml --tags image --limit schreiner-core
Bests,
Nick
On 7/2/21 10:48 AM, Petr Štetiar wrote:
Nick [2021
There was a update of libubus:
https://github.com/openwrt/openwrt/commit/3c574750854488ff463b2069a5d23d9c44f2a3dc
However this still "broke" 21.02-rc3 and SNAPSHOT (imagebuilder)?
Why does it break "21.02-rc3"? Packages are not recompiled?
On 7/1/21 3:09 PM, Petr Štetiar wrote:
Hi,
this
Can we move qos-scripts to packages feed?
https://github.com/openwrt/openwrt/tree/master/package/network/config/qos-scripts
Bests,
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt
Hi Hauke,
I wonder if it is worth also opening an issue for this over at
https://github.com/greearb/ath10k-ct/issues ?
Best,
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
I also made a PR updating some parts of the Makefile:
https://github.com/openwrt/openwrt/pull/4187/files
On 5/19/21 10:03 PM, Nick wrote:
Why is the git repro of opkg still
https://git.openwrt.org/project/opkg-lede.git ?
Can we change it back to https://git.openwrt.org/project/opkg
/da95c9aa17814d691a7fed6e8297fb29c5600c27#diff-8d00b3da40f45f370892fc2ffea1aa5ac6d4637e38e17766819993cd9a265c6e
Bests
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
There is a PR for the package:
https://github.com/openwrt/packages/pull/15615
On 5/13/21 9:00 AM, e9hack wrote:
Hi,
I've trouble to build libgpg-err since the update from 1.39 to 1.42.
Compilation does fail because the auto generated file gpg-error.h
contains wrong syntax in macro
> > Regarding ath10k-ct, what kernel-versions of the ath10k-ct driver need to
> > be patched?
> > Is 4.19 the oldest that owrt will consume?
> I think so. 4.19 is used by OpenWrt 19.07 and I don't think we'll update
> anything older than that.
So, to summarise, the 4.19, 5.4 and 5.10 branch
Nice thanks for the fast reply! :)
Bests,
Nick
On 4/10/21 6:39 PM, Daniel Golle wrote:
Hi Nick,
On Sat, Apr 10, 2021 at 01:31:21PM +0200, Nick wrote:
There is an error in the current umds project: "UMDNS: does not start on
master with seccomp"
https://bugs.openwrt.org/index.php?do=
There is an error in the current umds project: "UMDNS: does not start on
master with seccomp"
https://bugs.openwrt.org/index.php?do=details_id=3355
It is affecting several other projects that make use of umdns.
Is someone working on it?
B
Also interesting:
https://github.com/openwrt/openwrt/pull/1773#issuecomment-459230119
On 2/17/21 11:02 AM, David Bauer wrote:
Hi,
On 2/17/21 9:20 AM, Perry wrote:
Hello,
I thought the kernel size issue was resolved by
1e41de2f48e284c9d6658f9403365651178f6826
Also, the linked PR #1773 has a
need only minor changes.
Bests,
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Maybe I will just inject via ubus a prefix, that is not reflected by the
config, like the
"UBUS_METHOD("add_prefix", handle_add_prefix, prefix_attrs)"
At the end that gives me the flexibility I need without the need to
insert absolute timestamps.
Best,
Nick
On 2/6/21 9:
n from now + 120s.
Setting this as abs time-span will prevent a reload or restart of the
daemon setting the value again to now + 120.
Bests,
Nick
On 2/6/21 9:14 PM, Hans Dedecker wrote:
On Sat, Jan 30, 2021 at 5:33 PM Nick Hainke <mailto:vinc...@systemli.org>> wrote:
Until now
valid_lifetime '05 Jan 2021 23:00:00'
option preferred_lifetime '05 Jan 2021 23:00:00'
If the valid_lifetime is in the past, the preferred lifetime and valid
lifetime are set to 1 minute.
Signed-off-by: Nick Hainke
---
README | 8 --
src/config.c| 69
Ah okay. I see no problem anymore. :)
But jow is the maintainer and author of owipcalc. I would even say that
this tool could also be useful on other paltforms and not only OpenWrt.
I would take care of that if jow is fine with it.
Bests,
Nick
On 1/22/21 1:43 PM, Adrian Schmutzler wrote
Is it okay to push c-code into packages feed, if it is not patch
related? (never saw this)
On 1/22/21 10:51 AM, Adrian Schmutzler wrote:
This is a helpful utility, but it does not have any dependencies
in this repository. Move it to packages feed.
Cc: Jo-Philipp Wich
Cc: Nick Hainke
Signed
etime" is
set.
I will test the changes and send them via mailing list again.
Bests,
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
On 12/12/20 8:20 PM, Hans Dedecker wrote:
Hi,
On Wed, Dec 2, 2020 at 3:33 PM wrote:
From: Nick Hainke
seg6_enabled - Bool
Accept or drop SR-enabled IPv6 packets on this interface.
More Information:
https://www.kernel.org/doc/html/latest/networking/seg6-sysctl.html
Now you can set
Do we really have to "CONFIG_PROC_STRIPPED=y" by default?
I wrote an prometheus-node-exporter and right now a collectd plugin, to
get ipv6 interface statistics.
For that I use "/proc/net/snmp6" and "/proc/net/dev_snmp6/...".
The above flag disables those two statistics.
I'm very interested in
Okay, thanks! :)
I will send a new patch, adding some kernel option there.
On 12/2/20 12:34 PM, Petr Štetiar wrote:
vinc...@systemli.org [2020-12-02 12:25:58]:
Hi,
diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4
index 10d14f6be5..942777b41e 100644
---
;.
On 11/27/20 10:05 PM, Andreas Oberritter wrote:
Hi Nick,
On Fri, 27 Nov 2020 09:43:58 +0100
Nick wrote:
The current ipq40xx network stack does no longer work for a few targets:
- Zyxel
- Fritz!Box 4040
- Fritz!Box 7530
- ZyXEL NBG6617
- GL-B1300
- ...
Can we please finally add my PR?
The current ipq40xx network stack does no longer work for a few targets:
- Zyxel
- Fritz!Box 4040
- Fritz!Box 7530
- ZyXEL NBG6617
- GL-B1300
- ...
Can we please finally add my PR? I introduced a kernel flag that is
about switching between the different options
1. Port Isolation
2. Nested
I added a kernel flag to differentiate between both driver versions.
https://github.com/openwrt/openwrt/pull/3596
I would backport this to 19.07 if it gets accepted.
On 11/20/20 3:30 PM, Baptiste Jonglez wrote:
Hi,
On 20-11-20, Adrian Schmutzler wrote:
-Original Message-
From:
Can we somehow get to the same naming convention, again?
In OpenWrt it is: QCA998X-firmware-... directly in /.
On the ct server it is QCA998X/firmware-...?
Bests,
Nick
On 11/8/20 10:55 PM, Ben Greear wrote:
> I tried to copy them all back into place...could have made mistakes since
> owrt
)_FIRMWARE_FILE_CT_HTT)
+ URL_FILE:=$(call CT_FIRMWARE_FILE_HTT,$(1))
endef
QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019
On 11/7/20 6:54 PM, Nick wrote:
> I fixed the hash values: https://github.com/openwrt/openwrt/pull/3573
> Not sure why the hash is suddenly dif
It is the firmware that is broken and just contains 0s.
On 11/7/20 6:54 PM, Nick wrote:
> I fixed the hash values: https://github.com/openwrt/openwrt/pull/3573
> Not sure why the hash is suddenly different for all firmware files?
>
> ___
>
I fixed the hash values: https://github.com/openwrt/openwrt/pull/3573
Not sure why the hash is suddenly different for all firmware files?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
the cell_density to 3 only has effect where legacy_rates is 0,
else this has the same effect as being configured with a cell_density of 2.
Where specified, the basic_rate and supported_rates options continue to
override both the cell_density and legacy_rates options.
Signed-off-by: Nick Lowe
blocktrron helped me to fix the jffs2 error! :)
https://github.com/openwrt/openwrt/pull/3536
I don't require 4.19 kernel for ath79 anymore.
On 10/14/20 1:31 PM, Nick wrote:
>> the last time I tried with IPQ40xx a 5.4 kernel the switch was not working
>> correctly [1].
> The
the cell_density to 3 only has effect where legacy_rates is 0,
else this has the same effect as being configured with a cell_density of 2.
Where specified, the basic_rate and supported_rates options continue to
override both the cell_density and legacy_rates options.
Signed-off-by: Nick Lowe
ffs2
error is still present.
So the device is still broken with 5.4 kernel. Especially, this device
is not contained in 19.07. :/
On 10/10/20 4:14 PM, Nick wrote:
> On 10/9/20 2:19 PM, Adrian Schmutzler wrote:
>
>> Based on the response here, one might remove 4.19 even earlier th
On 10/9/20 2:19 PM, Adrian Schmutzler wrote:
> Based on the response here, one might remove 4.19 even earlier then if nobody
> actually needs it anymore.
The 5.4 kernel breaks a lot of my devices. I still build master with
4.19 kernel.
There is this jffs2 error on ubiquity devices [0] and the
> As briefly mentioned on IRC, I have concerns that this might interfere with
> clients using buggy wireless implementations. I've noticed 802.11g clients
> not connecting / listing networks which do not offer a 6 Mbit/s basic rate.
Yes, completely agree. This setting does have interoperability
,
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
the cell_density to 3 only has effect where legacy_rates is 0,
this has the same effect as being configured with a cell_density of 2.
Where specified, the basic_rate and supported_rates options continue to
override both the cell_density and legacy_rates options.
Signed-off-by: Nick Lowe
---
.../network
seen due to the DMA burst size value meaning
different things between Wave 1 and Wave 2 hardware.
The issue resolved is that a value of 0 for the DMA burst size has a
different meaning and instruction depending on the generation.
Cheers,
Nick
On Sun, Aug 30, 2020 at 1:45 PM Baptiste Jonglez
At the first start after flashing, there is often a "mount_root: failed
to sync jffs2 overlay2".
This problem only occurs with the 5.4 kernel. If I build a 4.19 kernel
with master, it works.
We have tested
- FRITZ!Box 4040 (ipq40xx)
- Nanobeam AC Gen2 (ath79)
- Nanostation AC loco (ath79)
On the
or:
https://github.com/berlin-open-wireless-lab/DAWN/issues/109#issuecomment-657483908
Bests,
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
, Nick wrote:
> Here is a PR that is fixing the issue. Why is that not merged? :/
>
> https://github.com/OLSR/olsrd/pull/79/files
>
> On 07.06.20 22:03, Rosen Penev wrote:
>>> Le 7 juin 2020 à 1:00 PM, Nick a écrit :
>>>
>>> I can not compile olsrd daemo
Here is a PR that is fixing the issue. Why is that not merged? :/
https://github.com/OLSR/olsrd/pull/79/files
On 07.06.20 22:03, Rosen Penev wrote:
>
>> Le 7 juin 2020 à 1:00 PM, Nick a écrit :
>>
>> I can not compile olsrd daemon with gcc9.
>>> #define isNaN(x) (
I can not compile olsrd daemon with gcc9.
> #define isNaN(x) (x != x)
> ...
> if (!isNaN(gpsdata->fix.time)) {
Here fix.time is a struct timespec.
The call is just wrong, or? Why should I check a struct for a valid float?
___
openwrt-devel mailing list
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 ---
FWIW, I’m able to use this modem
Thanks for your quick reply. :)
Should I update the umdns Makefile in the openwrt.git, too?
On 05.04.20 10:00, Kevin Darbyshire-Bryant wrote:
> Merged.
> Thank you!
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
>
This driver enables hardware monitoring support using the sensors
found in many Fintek Super-IO chips.
Signed-off-by: Nick Bowler
---
v2: Added @TARGET_x86 dependency
package/kernel/linux/modules/hwmon.mk | 15 +++
1 file changed, 15 insertions(+)
diff --git a/package/kernel
This driver enables support for the watchdog timers found in many
Fintek Super-IO chips.
Signed-off-by: Nick Bowler
---
v2: Added @TARGET_x86 dependency
package/kernel/linux/modules/other.mk | 16
1 file changed, 16 insertions(+)
diff --git a/package/kernel/linux/modules
This driver enables support for the GPIO capabilities found in many
Fintek Super-IO chips.
Signed-off-by: Nick Bowler
---
v2: Added @TARGET_x86 dependency
package/kernel/linux/modules/other.mk | 16
1 file changed, 16 insertions(+)
diff --git a/package/kernel/linux/modules
dependency to these drivers.
Nick Bowler (3):
kernel: package f71882fg hwmon driver
kernel: package f71808e-wdt driver
kernel: package gpio-f7188x driver
package/kernel/linux/modules/hwmon.mk | 15 +
package/kernel/linux/modules/other.mk | 32 +++
2 files
On 2020-03-21, Daniel Golle wrote:
> On Wed, Mar 18, 2020 at 11:27:09PM -0400, Nick Bowler wrote:
>> This series enables packaging of the Linux hwmon, watchdog and gpio
>> drivers that support multiple Fintek Super-IO chips. In particular,
>> the Fintek F71869A is used on th
that with the patch.
On 22.03.20 11:56, Nick Hainke wrote:
> Subscribe to beacon reports through ubus.
> Can be used for hearing map and client steering purposes.
>
> First enable rrm:
> ubus call hostapd.wlan0 bss_mgmt_enable '{"beacon_report":True}'
>
> Subscri
tapd.wlan0 rrm_beacon_req '{"addr":"00:xx:xx:xx:xx:xx",
"op_class":0, "channel":1,"duration":1,"mode":2,"bssid":"ff:ff:ff:ff:ff:ff",
"ssid":""}'
Signed-off-by: Nick Hainke
---
...
This driver enables support for the watchdog timers found in many
Fintek Super-IO chips.
Signed-off-by: Nick Bowler
---
package/kernel/linux/modules/other.mk | 15 +++
1 file changed, 15 insertions(+)
diff --git a/package/kernel/linux/modules/other.mk
b/package/kernel/linux
This series enables packaging of the Linux hwmon, watchdog and gpio
drivers that support multiple Fintek Super-IO chips. In particular,
the Fintek F71869A is used on the Jetway NF99FL board and the stock
OpenWRT kernels appear to completely lack drivers for this chip.
Nick Bowler (3):
kernel
1 - 100 of 145 matches
Mail list logo
