Why is this patch not reviewed?
On 31.05.2018 13:11, PolynomialDivision wrote:
> Add channel survey data.
>
> Signed-off-by: Nick Hainke
> ---
> include/iwinfo.h | 11 +++
> iwinfo_cli.c | 31 -
>
From 9cd22ed941e4c75b4c3622c50ca995fcb0d413ea Mon Sep 17 00:00:00 2001
From: PolynomialDivision
Date: Tue, 29 May 2018 00:10:01 +0200
Subject: [PATCH] iwinfo: add channel survey
Add channel survey data.
Signed-off-by: Nick Hainke
---
include/iwinfo.h | 11 +++
iwinfo_cli.c | 37
Hi,
I added some pull request that add the ht and vht support in the probe
requests in the ubus calls.
> https://github.com/openwrt/openwrt/pull/898
This request is open since Mai.
I would be very happy, if I would receive an answer. :)
___
Should I add something. Do I have to implement the lua bindings?
What's missing?
Or is this patch not suitable for the iwinfo lib?
On 06.06.2018 17:17, Nick wrote:
> I just followed the coding style...
>
> On 06.06.2018 16:11, Koen Vandeputte wrote:
>>
>> On 2018-06
Do u think we could add the channel utilization in the cmd tool?
You would have to do some averaging over a time period...
On 26.06.2018 21:14, Nick wrote:
> Here is the patch. It compiles.
> How can I test this? I'm not sure if I did everything correct.
> I never used lua. :/
I wanted to add this info too. See previous emails: "iwinfo: add channel
survey"
I think you are making the survey for all channels?
My attention was only a survey for the used channel.
On 03.07.2018 15:32, Daniel Danzberger wrote:
> Signed-off-by: Daniel Danzberger
> ---
> include/iwinfo.h |
ckages/issues/5180).
I don't know how to move on. Some ideas?
Best,
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
>
> On 2018-10-15 16:20, Nick wrote:
>> Hi,
>> did someone manage to follow the Readme.md?
>> I got several problems when compiling juci in Xubuntu 18.04.
>> First where was a Regex mismatch.
>> And then npm makes trouble.
>> Now there is a new issue:
&
Hi,
maybe it would even be possible to port the lua net_hints to a rpcd plugin. I
find this tool very useful. :) Does it consider mutlicast DNS?
I don't mean to move the source code to rpcd but changing the makefile/cmake as
its done for libiwinfo and the others Plugins.
Best,
Nick
Just compiled an Image with JUCI for WDR3600.
When trying to flash
> Invalid image, hardware ID mismatch, hw:4301 0001
> image:3601 0001.
Is someone using juci?
On 10/15/18 5:03 PM, Nick wrote:
> I just followed "Usage on OpenWrt".
Last Commit was on August 8.
On 10/16/18 3:50 PM, Outback Dingo wrote:
> On Tue, Oct 16, 2018 at 8:43 PM Nick wrote:
>> Just compiled an Image with JUCI for WDR3600.
>> When trying to flash
>>
>>> Invalid image, hardware ID mismatch, hw:4301 00
Hi,
why is the rrdns located under luci?
Can we make it consistent place rrdns somewhere else?
Furthermore we should change the Makefile of rpcd and the cmakefile that
rrdns ist listed automatically as rpcd plugin.
Right now its located under libraries.
So just add something like this to the end
iw has no c library. So if you want to do automatically switching or
stuff like this, I directly would have to use nl80211.
Would be nice to split iw into a libiw and cmd iw or something like this.
Bests,
Nick
On 21.05.19 19:34, John Crispin wrote:
>
> On 21/05/2019 17:44, Nick wrote:
&
If I extend iwinfo to allow setting interfaces into monitor mode, will
it be excepted?
Or is iwinfo just for getting information for an interface?
I use libiwinfo for abstraction for my own daemons.
Bests,
Nick
___
openwrt-devel mailing list
openwrt
Why are this patches not merged upstream?
You always have to rebase and solve merge conflicts if you work on 60
GHz. :/
I would really appreciate it if this is merged. And if there is a reason
why this stuff is not getting upstream, I volunteer to work on it.
Best,
Nick
On 08.11.19 19:14
I have several issues on a x86_64 testbed.
> https://github.com/openwrt/openwrt/pull/2417#issuecomment-575878911
I think, they are not directly related to the patches, but something is
strange, and make 60 ghz out-of-the-box not working on OpenWrt.
Espeically, the segmentation fault in the ubus
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
>
The current version has switched from 1.1.1d to 1.1.1e (PKG_BUGFIX).
So we should switch to 1.1.1e, but then patches won't apply or we add
> http://ftp.fi.muni.cz/pub/openssl/source/old/$(PKG_BASE)/ \
to the beginning of PKG_SOURCE_URL.
Currently, the package is **NOT** contained in:
>
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
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
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
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
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
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
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
, 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
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
;.
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?
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 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
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
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
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?
>
> ___
>
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
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
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
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
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
/da95c9aa17814d691a7fed6e8297fb29c5600c27#diff-8d00b3da40f45f370892fc2ffea1aa5ac6d4637e38e17766819993cd9a265c6e
Bests
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
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
://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
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:
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
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=
need only minor changes.
Bests,
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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
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
+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
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
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
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
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()
.
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
to release in 2022?
Bests
Nick
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/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
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
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 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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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/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
/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
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
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
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
Any suggestions? Is there any official branding?
--
*Captain Nick Shvelidze https://plus.google.com/+NickShvelidze*
*Pirrate.me http://Pirrate.me*
Tbilisi, Georgia
*Twitter: @shvelo96 http://www.twitter.com/shvelo96*
___
openwrt-devel mailing list
Good to see package feed on GitHub.
Would be great if there was a full OpenWRT source mirror on GitHub, for
some reason git.openwrt.org refuses connections on HTTPS, both from my home
and work IPs.
On Mon, Jul 14, 2014 at 1:12 PM, John Crispin j...@phrozen.org wrote:
The OpenWrt developers
Interesting, MicroPython is great. By the way, Luci2 doesn't use Lua at all.
On Mon, Jul 14, 2014 at 4:20 PM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
I wondered if it makes sense to post about MicroPython, but recent post
about Squirrel language prompted me to. So, there's a project
the parsing and increments the revision/version in the
makefile.
Signed-off-by: Nick Podolak sur4...@gmail.com
From c8dacaac47259dff35b04da64ef39f0525b8f591 Mon Sep 17 00:00:00 2001
From: Nick Podolak sur4...@gmail.com
Date: Wed, 20 Nov 2013 14:38:16 -0500
Subject: [PATCH] multiwan: fixes parsing
having to go through the headaches of putting certificates on every device.
It looks like this is supported by both Ruckus and Aerohive and their
corresponding terminology is Dynamic PSK or Private PSK.
Thanks for your help,
-Nick
___
openwrt-devel
2 patches are required to add NFQUEUE iptables target support: iptables and
kernel modules.
iptables is modified to include the NFQUEUE plugin/module and install the
libxt_NFQUEUE.so file in the installation process.
kernel module definition in netiflter.mk is modified to include the NFQUEUE
I have often found myself asking the same question.
I use the x86 build target, which should be pretty easy to manage from a
kernel perspective. Yet it's on 3.3 for attitude adjustment and 3.7 for
trunk. Both of which are end of life.
On Tue, Apr 2, 2013 at 11:08 AM, sylvain roger rieunier
I'm not going to reinvent the wheel analyzing how hard it is to say
how many features make it worth releasing new version. A lot of big
(and actively developed) projects are using cycling releases now
(including Linux kernel). And come one, OpenWrt is getting a lot of
patches almost daily.
On Wed, Apr 3, 2013 at 12:36 PM, Jonathan Bither jonbit...@gmail.comwrote:
May be the completely wrong idea, but what if there was an OpenWRT-Kernel
GIT repository holding the branches and modifications required for each
arch. Would allow easy updates and backports from a Trunk branch to an
To the original poster's point, it would be nice if at the very least the
site's SSL certificate, which is due for renewal shortly, supported the
downloads.openwrt.org URL.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
device clock divisor to 1 (full rate) results in all
further VLYNQ operations failing (including software reset), so the
device is never enabled. This patches changes the function to only
attempt divisors 2 through 8, and hence the device is successfully
enabled.
Signed-off-by: Nick Forbes [EMAIL
1 - 100 of 145 matches
Mail list logo
