Re: [OpenWrt-Devel] Bumping ar71xx to 4.14

[Arjen de Korte]

Citeren Koen Vandeputte :


Hi All,

Regarding bumping ar71xx to 4.14, from my point of view all known  
issues seem to be fixed.
Therefore, I'm planning to actually make 4.14 the default for this  
target mid next week.


If you still have issues which would not allow this, please let me  
know asap. (and provide a log of the issue please)



Testing it can be done by either:
- Checking out master tree, and altering  
"target/linux/ar71xx/Makefile" --> KERNEL_PATCHVER:=4.9  to  
KERNEL_PATCHVER:=4.14
- Checking out my staging tree (branch ar71xx_414) which has 4.14  
enabled by default. [1]


Just installed on a Netgear WNDR4300v1 -> OK.


Thanks,

Koen

[1]  
https://git.openwrt.org/?p=openwrt/staging/xback.git;a=shortlog;h=refs/heads/ar71xx_414


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v1] 6in4: add maxtry option to make more persistent updating HE endpoint

[Arjen de Korte]

Citeren Kevin Darbyshire-Bryant :


Add option 'maxtry' to 6in4 interface definition.  Defaults to 3.

Defines maximum number of attempts to update Hurricane Electric
tunnel endpoint address.  Originally unconfigurable and hard coded to 3.

Each update attempt has a 5 second timeout.


I don't think this is a good idea. While I recognize that the update  
is accepted only on the third (and final) try, just upping the number  
of tries is not the solution.


It looks to me that the updates are failing, because the script runs  
too soon. Adding a fixed delay of 15 seconds before it runs, will  
always update on the first try.


So rather than just trying more often, it might be better to fix an  
apparent race condition here.



Signed-off-by: Kevin Darbyshire-Bryant 
---
 package/network/ipv6/6in4/files/6in4.sh | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/package/network/ipv6/6in4/files/6in4.sh  
b/package/network/ipv6/6in4/files/6in4.sh

index 941dc43d68..dce37eb3b3 100755
--- a/package/network/ipv6/6in4/files/6in4.sh
+++ b/package/network/ipv6/6in4/files/6in4.sh
@@ -31,8 +31,8 @@ proto_6in4_setup() {
local iface="$2"
local link="6in4-$cfg"

-	local mtu ttl tos ipaddr peeraddr ip6addr ip6prefix ip6prefixes  
tunlink tunnelid username password updatekey
-	json_get_vars mtu ttl tos ipaddr peeraddr ip6addr tunlink tunnelid  
username password updatekey
+	local mtu ttl tos ipaddr peeraddr ip6addr ip6prefix ip6prefixes  
tunlink tunnelid username password updatekey maxtry
+	json_get_vars mtu ttl tos ipaddr peeraddr ip6addr tunlink tunnelid  
username password updatekey maxtry

json_for_each_item proto_6in4_add_prefix ip6prefix ip6prefixes

[ -z "$peeraddr" ] && {
@@ -98,7 +98,7 @@ proto_6in4_setup() {

local 
url="$http://ipv4.tunnelbroker.net/nic/update?hostname=$tunnelid;
local try=0
-   local max=3
+   local max="${maxtry:-3}"

(
set -o pipefail
@@ -134,6 +134,7 @@ proto_6in4_init_config() {
proto_config_add_string "username"
proto_config_add_string "password"
proto_config_add_string "updatekey"
+   proto_config_add_int "maxtry"
proto_config_add_int "mtu"
proto_config_add_int "ttl"
proto_config_add_string "tos"





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] procd: Fix compile error with GCC8

[Arjen de Korte]

Citeren John Crispin :


On 21/06/18 22:58, Rosen Penev wrote:

error: ‘%d’ directive output may be truncated writing between 2 and 10
bytes into a region of size 3 [-Werror=format-truncation=]
snprintf(fd_buf, sizeof(fd_buf), "%d", wdt_fd);
^~~
note: directive argument in the range [0, 2147483647]
snprintf(fd_buf, sizeof(fd_buf), "%d", wdt_fd);
   ^
note: ‘snprintf’ output between 3 and 11 bytes into a destination of size
3
snprintf(fd_buf, sizeof(fd_buf), "%d", wdt_fd);

Signed-off-by: Rosen Penev 
---
 watchdog.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/watchdog.c b/watchdog.c
index ec10ba6..efe30f1 100644
--- a/watchdog.c
+++ b/watchdog.c
@@ -144,8 +144,9 @@ char* watchdog_fd(void)
 {
static char fd_buf[3];
 -  if (wdt_fd < 0)
+   if (wdt_fd < 0 || wdt_fd > 99)
return NULL;
+
snprintf(fd_buf, sizeof(fd_buf), "%d", wdt_fd);

imho the %d should be changed to %ld or something similar.


That's not the problem here. The fd_buf is only large enough to store  
values between 0 and 99 (inclusive). Although this will fix the  
compilation warning/error, I'm slightly worried that this may confuse  
callers when the filedescriptor is > 99. Before this patch, you'd get  
a truncated value (the first two digits), after there will be no  
difference between an error condition (wdt_fd < 0) or a filedescriptor  
that is too large to fit in the static fd_buf.


The wdt_fd is defined as an 'int', so %d is appropriate here.


return fd_buf;



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Moving the mailing lists

[Arjen de Korte]

Citeren Torbjörn Jansson :

On 23 May 2018 15:45:47 GMT+02:00, "Andrey Jr. Melnikov"  
 wrote:

John Crispin  wrote:

Hi All,



In order to bring the OpenWrt mailing list back to operational

status,

we are moving them to the infradead server. The 2 current LEDE lists
will be renamed



* lede-dev->openwrt-dev



* lede-adm -> openwrt-adm



the old names will get redirected to the new ones, so mails sent to
either of the LEDE ones will pop up on the OpenWrt ones.


lede-devel working without subscribe, old openwrt-devel requied
subscribtion. What policy on new openwrt-devel?

[...]


lets hope for a smooth transition ...


PS: Remove this annoying tag '[OpenWrt-Devel]' from subject. XXI
century in
the world - all email clients already know how filters messages based
on
List-Id header.



Not everyone, plus lede mailing list also had prefix on subject line.

But one thing that is a little anoying after the move is that for  
some mails I get same thing twice and I'm not sure why.


Most likely because people are still cross-posting to lede-dev and  
openwrt-devel (like you just did). Being the same list now, this means  
you'll get the same thing twice.





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] stdout and putchar() behavior in musl

[Arjen de Korte]

Citeren Ram Chandra Jangir :


Hi,

Did anyone observed stdout and putchar() behavior differences between musl &
uClibc?

I have below code snippet :

int main(void){
int c;
while((c=getchar())!= 'e') {
putchar(c+1);
}
return 0;
}

When I use uClibc/gcc, I can see writing c+1 from putchar() happening
immediately. But when I use musl, character(c+1) gets printed on console
only if I exit from the program by entering 'e'.
I guess printing character using putchar family on stdio is having bug(or
different implementation) in musl. Has anybody faced this issue? Any
workaround?


Apparently in uClibc stdout is unbuffered and in musl it is buffered.  
Either is allowed in the C-standard (it is  not specified) so this is  
not a bug. If you want each character to be output immediately, you  
probably need to add flush(stdout).

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

[Arjen de Korte]

Citeren Felix Fietkau <n...@openwrt.org>:


On 2016-01-25 20:26, Arjen de Korte wrote:

Citeren Felix Fietkau <n...@openwrt.org>:


On 2016-01-25 19:14, Arjen de Korte wrote:

Citeren Felix Fietkau <n...@openwrt.org>:


On 2016-01-24 17:35, Felix Fietkau wrote:

On 2016-01-24 13:06, Christian Schoenebeck wrote:
I'm currently looking on ddns-scripts and still got  
certificate problems

I'm on r48470 including ca-certificates package installed

root@OpenWrt:~# uclient-fetch -O-
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Downloading
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Connecting to 62.201.160.30:443
Connection error: Server hostname does not match SSL certificate

What platform and ustream-ssl variant are you using?
I can't reproduce this.


Similar problem here:

# uclient-fetch -O-
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Downloading
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Connecting to 2001:868:100:901:53::2:443
Connection error: Invalid SSL certificate

I'm using the libustream-mbedtls library on a WNDR4300 (=ar71xx).

What OpenWrt version are you using?


Powered by LuCI Master (git-16.023.59693-6123974) / OpenWrt Designated
Driver r48463

Please try current trunk.


No change (r48548), error message is identical. I use the following versions:

libuclient - 2016-01-28-2e0918c7e0612449024c8d44fb2d7a33f5f3
uclient-fetch - 2016-01-28-2e0918c7e0612449024c8d44fb2d7a33f5f3
libmbedtls - 2.2.1-1
libustream-mbedtls - 2016-01-25-173aca2acf16b367f9a130efe677189854784b78

Regards, Arjen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Changeset 48456

[Arjen de Korte]

Citeren Chris Marchesi :


I noticed changeset 48456, which reverts 48276, which I put in to get the
full 128MB flash on a WNDR3700v4.


Yup, this badly breaks the WNDR4300, which is almost the same  
hardware, but apparently has different boot code in it.



Looks like the issue was the fact that it changed the location of
caldata_backup.


Not necessarily the location of the caldata_backup. After reverting  
the commit (and with the caldata_backup still containing nonsense),  
the WNDR4300 boots normally. So it looks like it is not the contents  
of caldata_backup that cause this, but the fact that it is in a  
different location.



I had a few questions about this:

1) I did a bit more research and it looks like caldata is actually device
firmware data that is not touched by firmware updates/etc, is that the same
for caldata_backup, ie: it was added there by the manufacturer?


Yes. As far as I know, this stores some device specific settings like  
MAC addresses and such. You can clearly see the MAC addresses of the  
wlan-0 and wlan-1 for instance by looking at the contents with a hex  
file viewer. The caldata and caldata_backup partitions should contain  
the same info.



2) I'd imagine that if this is the case, then I should stop using this MTD
layout ASAP as well. What's the easiest way to restore the state of
caldata_backup after rolling back?


By executing the following two commands in a shell on the device:

# dd if=/dev/mtd2 of=/tmp/caldata.bin

This command writes 512 blocks of data from the (hopefully pristine)  
caldata partition to a backup file.


# mtd -e caldata_backup write /tmp/caldata.bin caldata_backup

The second command will first erase the caldata_partition and then  
write the contents of the backup you just made to it. BE CAREFUL!  
Double check if you write to the correct partition.



3) Given all of this, is there any real hope for getting the full flash
available on these routers for OpenWRT by default?


It depends on what you want to use it for. As far as I know, in the  
OEM firmware it can be used for additional user data storage. My  
suggestion would be to keep the existing partitions as they are and  
just mount the reserved data as additional partition (for instance  
under /srv or /var/).



Looks like this has been a question that has come up more than a few times
- I referenced a thread in my original post but I found another issue from
the tracker here: https://dev.openwrt.org/ticket/17316. If it's not going
to be possible, maybe a note in the wiki or something would be a good idea,
so that there can be a final word on the question.
PS: Is there a page in the wiki that clearly outlines what caldata is and
its importance? I couldn't find it here:
https://wiki.openwrt.org/doc/techref/flash.layout

Sorry for introducing the regression!

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

[Arjen de Korte]

Citeren Felix Fietkau <n...@openwrt.org>:


On 2016-01-25 19:14, Arjen de Korte wrote:

Citeren Felix Fietkau <n...@openwrt.org>:


On 2016-01-24 17:35, Felix Fietkau wrote:

On 2016-01-24 13:06, Christian Schoenebeck wrote:

I'm currently looking on ddns-scripts and still got certificate problems
I'm on r48470 including ca-certificates package installed

root@OpenWrt:~# uclient-fetch -O-
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Downloading
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Connecting to 62.201.160.30:443
Connection error: Server hostname does not match SSL certificate

What platform and ustream-ssl variant are you using?
I can't reproduce this.


Similar problem here:

# uclient-fetch -O-
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Downloading
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Connecting to 2001:868:100:901:53::2:443
Connection error: Invalid SSL certificate

I'm using the libustream-mbedtls library on a WNDR4300 (=ar71xx).

What OpenWrt version are you using?


Powered by LuCI Master (git-16.023.59693-6123974) / OpenWrt Designated  
Driver r48463

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

[Arjen de Korte]

Citeren Felix Fietkau :


On 2016-01-24 17:35, Felix Fietkau wrote:

On 2016-01-24 13:06, Christian Schoenebeck wrote:

I'm currently looking on ddns-scripts and still got certificate problems
I'm on r48470 including ca-certificates package installed

root@OpenWrt:~# uclient-fetch -O-  
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Downloading  
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'

Connecting to 62.201.160.30:443
Connection error: Server hostname does not match SSL certificate

What platform and ustream-ssl variant are you using?
I can't reproduce this.


Similar problem here:

# uclient-fetch -O-  
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'
Downloading  
'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com=8.8.8.8'

Connecting to 2001:868:100:901:53::2:443
Connection error: Invalid SSL certificate

I'm using the libustream-mbedtls library on a WNDR4300 (=ar71xx).

Regards, Arjen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Discussion: Replace BUSYBOX NSLOOKUP by hostip package

[Arjen de Korte]

Citeren Christian Schoenebeck :

For some (good) reason you decided to remove wget from BusyBox and  
replace it by uclient-fetch.

Why not also remove nslookup from BusyBox.
- If compiled with musl it malfunction with given dns-server


Correct. It will completely ignore the [SERVER] argument from nslookup  
[HOST] [SERVER] (see [1] & [2]). Either nslookup.c from BusyBox should  
be changed to allow overriding the list of nameservers from  
/etc/resolv.conf (which are the only ones used with the musl library)  
or patched to allow this argument only when compiled against a library  
that actually supports this. I have little hope that musl can be  
convinced to make such functionality available. Note that in many  
cases one can workaround this issue by creating a new /etc/resolv.conf  
with the nameserver(s) to use. By default dnsmasq will not use this  
file, so this will only influence resolving locally (not on clients  
connected).



- use hostip package instead. Tiny and functional


It's not as big as bind-host, but I wouldn't call it tiny either (on  
ar71xx at least). The hostip package (~30k) requires libsodium  
(~120k), which is much higher than the additional size of nslookup in  
BusyBox (which is essentially just a bunch of calls to stuff which is  
already in the libc). Adding the functionality in BusyBox nslookup  
will increase the size of BusyBox somewhat, but not nearly by that  
much. If needed, I can write this.



What do you think?


I think adding this functionality to BusyBox will be far cheaper in  
terms of size used. Since for many people the [SERVER] argument is not  
going to be used anyway, so switching to hostip by default seems  
overkill. For the time being, people that need this functionality  
should either use a modified /etc/resolv.conf (if possible) or use  
bind-host instead.


Regards, Arjen

[1] https://dev.openwrt.org/ticket/18333
[2] https://dev.openwrt.org/ticket/20893
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set

[Arjen de Korte]

Citeren Felix Fietkau <n...@openwrt.org>:


On 2016-01-23 01:25, Felix Fietkau wrote:

On 2016-01-23 00:45, Arjen de Korte wrote:

It also behaves differently with the http://dyn.dns.he.net servers
(returning a Connection failure, despite also returning a result). See
below:

# /bin/uclient-fetch -O-
'https://dyn.dns.he.net/nic/update?hostname=example.com=munged=1.2.3.4'
Downloading
'https://dyn.dns.he.net/nic/update?hostname=example.com=munged=1.2.3.4'
Connecting to 2001:470:0:193::3000:443
Writing to stdout
nochg 1.2.3.4Connection error: Connection failed

I'm not too concerned about the first, but the latter is a bit
inconvenient. I suspect the HE servers close the connection
immediately after sending the result and that this is not expected.

I'll make an account and look into that soon.


Figured it out. It was a mix of two things:

- Needed to change ustream-ssl to treat SSL close notification as EOF
- The he.net HTTP server sends \n as linebreak instead of \r\n

I've changed the code to deal with both issues, it should work now, as
of r48463. Please test.


The above mentioned problems seem to be fixed. I can now successfully  
send the update to the HE servers. I do notice another issue however.  
When using the -O  option, the output file is not truncated  
before writing data. This is undesireable if the file already contains  
data and less than the existing data is written. After the new data is  
written, the remaining old data is still there. A strategically placed  
O_TRUNC flag will probably fix this.


Regards, Arjen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt-Commits] r48276 - trunk/target/linux/ar71xx/image

[Arjen de Korte]

This doesn't look good. This patch will move the location of the  
'caldata_backup' partition from the factory default location


0x01fc-0x0200 : "caldata_backup"

to

0x07fc-0x0800 : "caldata_backup"

But since the data of this partition is not moved beforehand, the  
previous location will be overwritten by the larger "firmware"  
partition and the new location will probably contain nothing but FF.  
While I agree it is a waste to not use the 96 MB in location  
0x0200-0x0800, just moving the "caldata_backup"  
partition to a new location and hope for the best is not a good  
solution.


Regards, Arjen

Citeren openwrt-comm...@openwrt.org:


Author: nbd
Date: 2016-01-17 12:16:56 +0100 (Sun, 17 Jan 2016)
New Revision: 48276

Modified:
   trunk/target/linux/ar71xx/image/Makefile
Log:
ar71xx: Use full 128MB flash on Netgear WNDR4300 and WNDR3700v4

Change MTD on WNDR4300 and WNDR3700v4 to fully utilize the 128MB flash.

Credit to @Tuochenlyu on GitHub.

Signed-off-by: Chris Marchesi 

Modified: trunk/target/linux/ar71xx/image/Makefile
===
--- trunk/target/linux/ar71xx/image/Makefile	2016-01-17 11:16:52 UTC  
(rev 48275)
+++ trunk/target/linux/ar71xx/image/Makefile	2016-01-17 11:16:56 UTC  
(rev 48276)

@@ -1581,7 +1581,7 @@
  
wnr2000v4_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(u-boot-env)ro,3776k(firmware),64k(art)ro
  
r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-backup),512k(config),512k(pot),2048k(kernel),122240k(ubi),25600k@0x1a(firmware),2048k(language),3072k(traffic_meter)
  
tew823dru_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(nvram)ro,15296k(firmware),192k(lang)ro,512k(my-dlink)ro,64k(mac)ro,64k(art)ro

-wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k@0x6c(firmware),256k(caldata_backup),-(reserved)
+wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),120832k(ubi),122880k@0x6c(firmware),256k(caldata_backup),-(reserved)
  
zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k@0x5(firmware)
  
mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
  
mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro

___
openwrt-commits mailing list
openwrt-comm...@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-commits

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Memory leak in mac80211?

[Arjen de Korte]

Citeren Felix Fietkau <n...@openwrt.org>:


On 2015-12-20 11:52, Arjen de Korte wrote:

Since commit 47771 it seems my WNDR4300 router suffers from a memory
leak. Before then, the amount of free memory was always around 75%,
but since then it steadily decreases until it runs out of memory and
reboots. The process then starts all over again. After a couple of
days of 'git bisect'ing, I found this to be the commit that introduced
this phenomenon. See attached kmemleak.txt file for more information.
I don't know how to go on from here to aid in debugging what is going
on. Is there something else I can provide to help finding how to solve
this?

Please copy http://nbd.name/990-remove_full_ap_client_state.patch to
package/kernel/mac80211/patches and try again.


Still no joy, see attached kmemleak output. In about four hours time,  
free memory decreased by about 10% (of 128 MB). Is there anything else  
I can do to aid in finding the cause? This is with r47953 by the way,  
with the above mentioned patch included (I checked in the build_dir,  
the patch applied successfully.


Best regards,
Arjen


kmemleak.txt.gz
Description: GNU Zip compressed data
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 1/3] ramips: Fix whitespace in the switch driver.

[Arjen de Korte]

Citeren "Vittorio G (VittGam)" :


Hi,

On 11/12/2015 10:32:08 CET, John Crispin wrote:

1) the subject and description dont match.


Well, the description is an addition to the subject, but okay.


2) why would we want to intermingle the portmap and register init
variables. they are 2 different things. imho that is not correct


Because there are two __be32's used to fetch data from the device
tree; one is used only once for the portmap, while the other is
used three times, for the two registers and for the led_polarity.
Maybe the name should be tmp instead, but I think that the variable
should be just one here.


You're trying to outsmart the compiler in order to save space? Any  
compiler from the last decade will take notice of the scope in which  
variables are used and will reuse stack (or register) space if the  
value they hold is no longer needed/used. I'm with John here, clarity  
in the naming of variables is much more important.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: reset m25p80 when shutdown

[Arjen de Korte]

Citeren Weijie Gao :


2015-11-08 4:42 GMT+08:00 Shonn Lu :


Signed-off-by: Shonn Lu 
---
 .../0064-reset-m25p80-when-shutdown.patch  | 24
++
 1 file changed, 24 insertions(+)
 create mode 100644
target/linux/ramips/patches-3.18/0064-reset-m25p80-when-shutdown.patch

diff --git
a/target/linux/ramips/patches-3.18/0064-reset-m25p80-when-shutdown.patch
b/target/linux/ramips/patches-3.18/0064-reset-m25p80-when-shutdown.patch
new file mode 100644
index 000..76f916a
--- /dev/null
+++
b/target/linux/ramips/patches-3.18/0064-reset-m25p80-when-shutdown.patch
@@ -0,0 +1,24 @@
+--- a/drivers/mtd/devices/m25p80.c
 b/drivers/mtd/devices/m25p80.c
+@@ -319,6 +319,12 @@
+ {
+   struct m25p *flash = spi_get_drvdata(spi);
+
++//play4fun: add spi flash reset code
++  flash->command[0] = 0x66;
++  spi_write(flash->spi, flash->command, 1);
++  flash->command[0] = 0x99;
++  spi_write(flash->spi, flash->command, 1);
++
+   /* Clean up MTD stuff. */
+   return mtd_device_unregister(>mtd);
+ }
+@@ -382,6 +388,8 @@
+   .id_table   = m25p_ids,
+   .probe  = m25p_probe,
+   .remove = m25p_remove,
++  //  play4fun add shutdown method to reset spi flash
++  .shutdown = m25p_remove,
+
+   /* REVISIT: many of these chips have deep power-down modes, which
+* should clearly be entered on suspend() to minimize power use.
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



This is not enough for w25q256.


It is.


The Extended Address Register (EAR) must be cleared, or the higher half
16MB may be accessed in 3-byte addressing mode, and this will cause a boot
failure.


From the W25Q256FV datasheet (page 23):

"Upon  power  up  or  after  the  execution  of  a  Software/Hardware   
Reset,  the  Extended  Address  Register

values will be cleared to 0."

So sending the device a software reset, should be sufficient as the  
EAR will be cleared.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] lantiq: fix use of IRQF_DISABLED in lantiq kmods

[Arjen de Korte]

Citeren Mathias Kresin :


The IRQF_DISABLED flag was removed in kernel 4.1 with commit
"genirq: Remove the deprecated 'IRQF_DISABLED' request_irq() flag  
entirely" [1].


Therefore the compilation of ltq-hcd and ltq-vmmc kmods fails.

[1]  
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d8bf368d0631d4bc2612d8bf2e4e8e74e620d0cc


Signed-off-by: Mathias Kresin 

---

The issue was reported in https://dev.openwrt.org/ticket/20679 and the
patch was successfully test by an affected user.

 package/kernel/lantiq/ltq-hcd/src/ifxhcd.c |  2 +
 package/kernel/lantiq/ltq-hcd/src/ifxusb_cif_h.c   |  8 +++
 .../lantiq/ltq-vmmc/patches/200-compat.patch   | 65  
++

 .../lantiq/ltq-vmmc/patches/200-linux-310.patch| 33 ---
 .../lantiq/ltq-vmmc/patches/400-falcon.patch   | 12 ++--
 ...2C-MIPS-lantiq-add-FALC-ON-i2c-bus-master.patch |  8 +--
 6 files changed, 85 insertions(+), 43 deletions(-)
 create mode 100644 package/kernel/lantiq/ltq-vmmc/patches/200-compat.patch
 delete mode 100644  
package/kernel/lantiq/ltq-vmmc/patches/200-linux-310.patch


diff --git a/package/kernel/lantiq/ltq-hcd/src/ifxhcd.c  
b/package/kernel/lantiq/ltq-hcd/src/ifxhcd.c

index be0a91d..14dc7a1 100644
--- a/package/kernel/lantiq/ltq-hcd/src/ifxhcd.c
+++ b/package/kernel/lantiq/ltq-hcd/src/ifxhcd.c
@@ -702,7 +702,9 @@ int ifxhcd_init(ifxhcd_hcd_t *_ifxhcd)
 * IRQ line, and calls ifxusb_hcd_start method.
 */
retval = usb_add_hcd(syshcd, _ifxhcd->core_if.irq, 0
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,1,0)
   |IRQF_DISABLED
+#endif


Why the conditional compile statement? The IRQF_DISABLED has been a  
NOOP since kernel 2.6.35, so it should be safe to remove for all  
current versions of OpenWRT. So this really should be


-  |IRQF_DISABLED

instead.

Arjen


   |IRQF_SHARED
   );
if (retval < 0)
diff --git a/package/kernel/lantiq/ltq-hcd/src/ifxusb_cif_h.c  
b/package/kernel/lantiq/ltq-hcd/src/ifxusb_cif_h.c

index e9e67bf..0219fff 100644
--- a/package/kernel/lantiq/ltq-hcd/src/ifxusb_cif_h.c
+++ b/package/kernel/lantiq/ltq-hcd/src/ifxusb_cif_h.c
@@ -778,7 +778,9 @@ void ifxusb_vbus_free(ifxusb_core_if_t *_core_if)
//   | 
IRQF_TRIGGER_HIGH
//   | 
IRQF_TRIGGER_LOW
//   | 
IRQF_TRIGGER_PROBE
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,1,0)
 | 
IRQF_DISABLED
+#endif
//   | 
IRQF_SAMPLE_RANDOM
//   | 
IRQF_SHARED
 | 
IRQF_PROBE_SHARED
@@ -806,7 +808,9 @@ void ifxusb_vbus_free(ifxusb_core_if_t *_core_if)
//   | 
IRQF_TRIGGER_HIGH
//   | 
IRQF_TRIGGER_LOW
//   | 
IRQF_TRIGGER_PROBE
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,1,0)
 | 
IRQF_DISABLED
+#endif
//   | 
IRQF_SAMPLE_RANDOM
//   | 
IRQF_SHARED
 | 
IRQF_PROBE_SHARED
@@ -1009,7 +1013,9 @@ void ifxusb_vbus_free(ifxusb_core_if_t *_core_if)
//| IRQF_TRIGGER_HIGH
//| IRQF_TRIGGER_LOW
//| IRQF_TRIGGER_PROBE
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,1,0)
  | IRQF_DISABLED
+#endif
//| IRQF_SAMPLE_RANDOM
//| IRQF_SHARED
  | IRQF_PROBE_SHARED
@@ -1174,7 +1180,9 @@ void ifxusb_vbus_free(ifxusb_core_if_t *_core_if)
//| IRQF_TRIGGER_HIGH
//| IRQF_TRIGGER_LOW
//| IRQF_TRIGGER_PROBE
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,1,0)
  | IRQF_DISABLED
+#endif
//  

Re: [OpenWrt-Devel] [PATCH 2/2] packages: Remove dependencies to kmod-ipv6

[Arjen de Korte]

Citeren John Crispin <blo...@openwrt.org>:


Hi,

On 20/09/2015 10:54, Arjen de Korte wrote:

Since r46834, IPv6 support is builtin if selected. Therefor, dependencies
on kmod-ipv6 can no longer be fulfilled, since it is not a module anymore.

Signed-off-by: Arjen de Korte <arjen+open...@de-korte.org>
---
 ipv6/tayga/Makefile | 2 +-
 libs/libwebsockets/Makefile | 2 +-
 net/lispmob/Makefile| 2 +-
 net/openvswitch/Makefile| 2 +-



these are all in the feed. please send a PR via github if you have not
done so already


I don't even have an account on github, so no, this hasn't been done  
already. Guess I'll be on a steep learning curve to get this fixed.  
I'll look into fixing this through github later today.


Arjen


4 files changed, 4 insertions(+), 4 deletions(-)


diff --git a/ipv6/tayga/Makefile b/ipv6/tayga/Makefile
index ba0d196..d68a271 100644
--- a/ipv6/tayga/Makefile
+++ b/ipv6/tayga/Makefile
@@ -19,7 +19,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/tayga
   SECTION:=net
   CATEGORY:=Network
-  DEPENDS:=+ip +kmod-ipv6 +kmod-tun
+  DEPENDS:=+ip @IPV6 +kmod-tun
   TITLE:=Out-of-kernel stateless NAT64 implementation for Linux
   URL:=http://www.litech.org/tayga/
   MAINTAINER:=Ondrej Caletka <ond...@caletka.cz>
diff --git a/libs/libwebsockets/Makefile b/libs/libwebsockets/Makefile
index d9952e6..9e827d7 100644
--- a/libs/libwebsockets/Makefile
+++ b/libs/libwebsockets/Makefile
@@ -27,7 +27,7 @@ CMAKE_INSTALL:=1
 include $(INCLUDE_DIR)/package.mk
 include $(INCLUDE_DIR)/cmake.mk

-CMAKE_OPTIONS += $(if $(CONFIG_PACKAGE_kmod-ipv6),,-DLWS_IPV6=)
+CMAKE_OPTIONS += $(if $(CONFIG_IPV6),,-DLWS_IPV6=)

 CMAKE_OPTIONS += -DLWS_WITHOUT_TESTAPPS=ON

diff --git a/net/lispmob/Makefile b/net/lispmob/Makefile
index 4742dee..3f9ea0c 100644
--- a/net/lispmob/Makefile
+++ b/net/lispmob/Makefile
@@ -33,7 +33,7 @@ define Package/lispd
   CATEGORY:=Network
   TITLE:=Locator/ID separation protocol (using TUN)
   URL:=https://github.com/LISPmob
-  DEPENDS:= +librt +libopenssl +confuse +kmod-tun +uci +kmod-ipv6
+  DEPENDS:= +librt +libopenssl +confuse +kmod-tun +uci @IPV6
   $(call Package/lispd/default)
 endef

diff --git a/net/openvswitch/Makefile b/net/openvswitch/Makefile
index 86e6c52..903fdac 100644
--- a/net/openvswitch/Makefile
+++ b/net/openvswitch/Makefile
@@ -98,7 +98,7 @@ define KernelPackage/openvswitch
   SUBMENU:=Network Support
   TITLE:=Open vSwitch Kernel Package
   KCONFIG:=CONFIG_BRIDGE
-  DEPENDS:=+kmod-stp +kmod-ipv6 +kmod-gre +kmod-lib-crc32c  
+kmod-vxlan @($(SUPPORTED_KERNELS))
+  DEPENDS:=+kmod-stp @IPV6 +kmod-gre +kmod-lib-crc32c +kmod-vxlan  
@($(SUPPORTED_KERNELS))

   FILES:= \
$(PKG_BUILD_DIR)/datapath/linux/openvswitch.$(LINUX_KMOD_SUFFIX)
   AUTOLOAD:=$(call AutoLoad,21,openvswitch)


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] Configure IPv6 kernel options in config/Config-kernel.in

[Arjen de Korte]

Revision 46834 changed IPv6 support from a module to builtin. But
since the configuration of the IPv6 kernel options was left in
package/kernel/linux/modules/netsupport.mk, this means that an
empty kmod-ipv6 module was still being generated (not packaged).

This patch moves the configuration of the IPv6 kernel options to
config/Config-kernel.in to remove this last bit of the module.

Note that CONFIG_IPV6_PRIVACY was dropped (enabled by default
since Linux v3.13), so this option is no longer needed.

See 
https://github.com/torvalds/linux/commit/5d9efa7ee99eed58388f186c13cf2e2a87e9ceb4

Signed-off-by: Arjen de Korte <arjen+open...@de-korte.org>
---
 config/Config-kernel.in| 23 +++
 package/kernel/linux/modules/netsupport.mk | 22 --
 2 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/config/Config-kernel.in b/config/Config-kernel.in
index 2572bf4..4082e1e 100644
--- a/config/Config-kernel.in
+++ b/config/Config-kernel.in
@@ -544,3 +544,26 @@ config KERNEL_SECCOMP
default n
help
  Build kernel with support for seccomp.
+
+#
+# IPv6 configuration
+#
+
+config KERNEL_IPV6
+   def_bool IPV6
+
+if KERNEL_IPV6
+
+   config KERNEL_IPV6_MULTIPLE_TABLES
+   def_bool y
+
+   config KERNEL_IPV6_SUBTREES
+   def_bool y
+
+   config KERNEL_IPV6_MROUTE
+   def_bool y
+
+   config KERNEL_IPV6_PIMSM_V2
+   def_bool n
+
+endif
diff --git a/package/kernel/linux/modules/netsupport.mk 
b/package/kernel/linux/modules/netsupport.mk
index b81d9b4..7a7ca43 100644
--- a/package/kernel/linux/modules/netsupport.mk
+++ b/package/kernel/linux/modules/netsupport.mk
@@ -453,28 +453,6 @@ endef
 $(eval $(call KernelPackage,iptunnel6))
 
 
-define KernelPackage/ipv6
-  SUBMENU:=$(NETWORK_SUPPORT_MENU)
-  TITLE:=IPv6 support
-  DEPENDS:=@IPV6
-  HIDDEN:=1
-  DEFAULT:=y
-  KCONFIG:= \
-   CONFIG_IPV6=y \
-   CONFIG_IPV6_PRIVACY=y \
-   CONFIG_IPV6_MULTIPLE_TABLES=y \
-   CONFIG_IPV6_MROUTE=y \
-   CONFIG_IPV6_PIMSM_V2=n \
-   CONFIG_IPV6_SUBTREES=y
-endef
-
-define KernelPackage/ipv6/description
- Kernel modules for IPv6 support
-endef
-
-$(eval $(call KernelPackage,ipv6))
-
-
 define KernelPackage/sit
   SUBMENU:=$(NETWORK_SUPPORT_MENU)
   DEPENDS:=@IPV6 +kmod-iptunnel +kmod-iptunnel4
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Configure IPv6 kernel options in config/Config-kernel.in

[Arjen de Korte]

Citeren John Crispin <j...@phrozen.org>:


On 22/09/2015 19:31, Arjen de Korte wrote:

Revision 46834 changed IPv6 support from a module to builtin. But
since the configuration of the IPv6 kernel options was left in
package/kernel/linux/modules/netsupport.mk, this means that an
empty kmod-ipv6 module was still being generated (not packaged).

This patch moves the configuration of the IPv6 kernel options to
config/Config-kernel.in to remove this last bit of the module.

Note that CONFIG_IPV6_PRIVACY was dropped (enabled by default
since Linux v3.13), so this option is no longer needed.

See  
https://github.com/torvalds/linux/commit/5d9efa7ee99eed58388f186c13cf2e2a87e9ceb4


Signed-off-by: Arjen de Korte <arjen+open...@de-korte.org>
---
 config/Config-kernel.in| 23 +++
 package/kernel/linux/modules/netsupport.mk | 22 --
 2 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/config/Config-kernel.in b/config/Config-kernel.in
index 2572bf4..4082e1e 100644
--- a/config/Config-kernel.in
+++ b/config/Config-kernel.in
@@ -544,3 +544,26 @@ config KERNEL_SECCOMP
default n
help
  Build kernel with support for seccomp.
+
+#
+# IPv6 configuration
+#
+
+config KERNEL_IPV6
+   def_bool IPV6
+
+if KERNEL_IPV6
+
+   config KERNEL_IPV6_MULTIPLE_TABLES
+   def_bool y
+
+   config KERNEL_IPV6_SUBTREES
+   def_bool y
+
+   config KERNEL_IPV6_MROUTE
+   def_bool y
+
+   config KERNEL_IPV6_PIMSM_V2
+   def_bool n
+
+endif
diff --git a/package/kernel/linux/modules/netsupport.mk  
b/package/kernel/linux/modules/netsupport.mk

index b81d9b4..7a7ca43 100644
--- a/package/kernel/linux/modules/netsupport.mk
+++ b/package/kernel/linux/modules/netsupport.mk
@@ -453,28 +453,6 @@ endef
 $(eval $(call KernelPackage,iptunnel6))


-define KernelPackage/ipv6
-  SUBMENU:=$(NETWORK_SUPPORT_MENU)
-  TITLE:=IPv6 support
-  DEPENDS:=@IPV6
-  HIDDEN:=1
-  DEFAULT:=y
-  KCONFIG:= \
-   CONFIG_IPV6=y \
-   CONFIG_IPV6_PRIVACY=y \
-   CONFIG_IPV6_MULTIPLE_TABLES=y \
-   CONFIG_IPV6_MROUTE=y \
-   CONFIG_IPV6_PIMSM_V2=n \
-   CONFIG_IPV6_SUBTREES=y
-endef
-
-define KernelPackage/ipv6/description
- Kernel modules for IPv6 support
-endef
-
-$(eval $(call KernelPackage,ipv6))
-
-


this will break all targets still on v3.18


What part will be broken? I tried adm5120 with and without this patch  
and the kernel binaries had identical sizes (which leads me to believe  
they will be the same).


Arjen


 define KernelPackage/sit
   SUBMENU:=$(NETWORK_SUPPORT_MENU)
   DEPENDS:=@IPV6 +kmod-iptunnel +kmod-iptunnel4


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] packages: Remove dependencies to kmod-ipv6

[Arjen de Korte]

Since r46834, IPv6 support is builtin if selected. Therefor, dependencies
on kmod-ipv6 can no longer be fulfilled, since it is not a module anymore.

Signed-off-by: Arjen de Korte <arjen+open...@de-korte.org>
---
 ipv6/tayga/Makefile | 2 +-
 libs/libwebsockets/Makefile | 2 +-
 net/lispmob/Makefile| 2 +-
 net/openvswitch/Makefile| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/ipv6/tayga/Makefile b/ipv6/tayga/Makefile
index ba0d196..d68a271 100644
--- a/ipv6/tayga/Makefile
+++ b/ipv6/tayga/Makefile
@@ -19,7 +19,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/tayga
   SECTION:=net
   CATEGORY:=Network
-  DEPENDS:=+ip +kmod-ipv6 +kmod-tun
+  DEPENDS:=+ip @IPV6 +kmod-tun
   TITLE:=Out-of-kernel stateless NAT64 implementation for Linux
   URL:=http://www.litech.org/tayga/
   MAINTAINER:=Ondrej Caletka <ond...@caletka.cz>
diff --git a/libs/libwebsockets/Makefile b/libs/libwebsockets/Makefile
index d9952e6..9e827d7 100644
--- a/libs/libwebsockets/Makefile
+++ b/libs/libwebsockets/Makefile
@@ -27,7 +27,7 @@ CMAKE_INSTALL:=1
 include $(INCLUDE_DIR)/package.mk
 include $(INCLUDE_DIR)/cmake.mk
 
-CMAKE_OPTIONS += $(if $(CONFIG_PACKAGE_kmod-ipv6),,-DLWS_IPV6=)
+CMAKE_OPTIONS += $(if $(CONFIG_IPV6),,-DLWS_IPV6=)
 
 CMAKE_OPTIONS += -DLWS_WITHOUT_TESTAPPS=ON
 
diff --git a/net/lispmob/Makefile b/net/lispmob/Makefile
index 4742dee..3f9ea0c 100644
--- a/net/lispmob/Makefile
+++ b/net/lispmob/Makefile
@@ -33,7 +33,7 @@ define Package/lispd
   CATEGORY:=Network
   TITLE:=Locator/ID separation protocol (using TUN)
   URL:=https://github.com/LISPmob
-  DEPENDS:= +librt +libopenssl +confuse +kmod-tun +uci +kmod-ipv6
+  DEPENDS:= +librt +libopenssl +confuse +kmod-tun +uci @IPV6
   $(call Package/lispd/default)
 endef
 
diff --git a/net/openvswitch/Makefile b/net/openvswitch/Makefile
index 86e6c52..903fdac 100644
--- a/net/openvswitch/Makefile
+++ b/net/openvswitch/Makefile
@@ -98,7 +98,7 @@ define KernelPackage/openvswitch
   SUBMENU:=Network Support
   TITLE:=Open vSwitch Kernel Package
   KCONFIG:=CONFIG_BRIDGE
-  DEPENDS:=+kmod-stp +kmod-ipv6 +kmod-gre +kmod-lib-crc32c +kmod-vxlan 
@($(SUPPORTED_KERNELS))
+  DEPENDS:=+kmod-stp @IPV6 +kmod-gre +kmod-lib-crc32c +kmod-vxlan 
@($(SUPPORTED_KERNELS))
   FILES:= \
$(PKG_BUILD_DIR)/datapath/linux/openvswitch.$(LINUX_KMOD_SUFFIX)
   AUTOLOAD:=$(call AutoLoad,21,openvswitch)
-- 
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] package: Remove dependencies to kmod-ipv6

[Arjen de Korte]

Since r46834, IPv6 support is builtin if selected. Therefor, dependencies
on kmod-ipv6 can no longer be fulfilled, since it is not a module anymore.

Signed-off-by: Arjen de Korte <arjen+open...@de-korte.org>
---
 package/kernel/linux/modules/netfilter.mk | 6 +++---
 package/network/config/gre/Makefile   | 2 +-
 package/network/ipv6/6in4/Makefile| 2 +-
 package/network/ipv6/6rd/Makefile | 2 +-
 package/network/ipv6/6to4/Makefile| 2 +-
 package/network/ipv6/ds-lite/Makefile | 2 +-
 package/network/ipv6/map/Makefile | 2 +-
 package/network/ipv6/odhcp6c/Makefile | 2 +-
 package/network/services/dnsmasq/Makefile | 2 +-
 package/network/utils/xtables-addons/Makefile | 2 +-
 10 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/package/kernel/linux/modules/netfilter.mk 
b/package/kernel/linux/modules/netfilter.mk
index 3a436ac..e21895d 100644
--- a/package/kernel/linux/modules/netfilter.mk
+++ b/package/kernel/linux/modules/netfilter.mk
@@ -80,7 +80,7 @@ define KernelPackage/nf-conntrack6
   SUBMENU:=$(NF_MENU)
   TITLE:=Netfilter IPv6 connection tracking
   KCONFIG:=$(KCONFIG_NF_CONNTRACK6)
-  DEPENDS:=+kmod-ipv6 +kmod-nf-conntrack
+  DEPENDS:=@IPV6 +kmod-nf-conntrack
   FILES:=$(foreach mod,$(NF_CONNTRACK6-m),$(LINUX_DIR)/net/$(mod).ko)
   AUTOLOAD:=$(call AutoProbe,$(notdir $(NF_CONNTRACK6-m)))
 endef
@@ -454,7 +454,7 @@ $(eval $(call KernelPackage,ipt-led))
 
 define KernelPackage/ipt-tproxy
   TITLE:=Transparent proxying support
-  DEPENDS+=+kmod-ipt-conntrack +IPV6:kmod-ipv6 +IPV6:kmod-ip6tables
+  DEPENDS+=+kmod-ipt-conntrack +IPV6:kmod-ip6tables
   KCONFIG:= \
CONFIG_NETFILTER_TPROXY \
CONFIG_NETFILTER_XT_MATCH_SOCKET \
@@ -473,7 +473,7 @@ $(eval $(call KernelPackage,ipt-tproxy))
 
 define KernelPackage/ipt-tee
   TITLE:=TEE support
-  DEPENDS:=+kmod-ipt-conntrack +IPV6:kmod-ipv6
+  DEPENDS:=+kmod-ipt-conntrack
   KCONFIG:= \
CONFIG_NETFILTER_XT_TARGET_TEE
   FILES:= \
diff --git a/package/network/config/gre/Makefile 
b/package/network/config/gre/Makefile
index 217c276..49e7d19 100644
--- a/package/network/config/gre/Makefile
+++ b/package/network/config/gre/Makefile
@@ -42,7 +42,7 @@ endef
 define Package/grev6
 $(call Package/gre/Default)
   TITLE:=Generic Routing Encapsulation (IPv6) config support
-  DEPENDS:=@(PACKAGE_gre) +kmod-ipv6 +kmod-ip6-gre
+  DEPENDS:=@(PACKAGE_gre) @IPV6 +kmod-ip6-gre
 endef
 
 define Package/grev6/description
diff --git a/package/network/ipv6/6in4/Makefile 
b/package/network/ipv6/6in4/Makefile
index b7c2da7..2ffdfc0 100644
--- a/package/network/ipv6/6in4/Makefile
+++ b/package/network/ipv6/6in4/Makefile
@@ -17,7 +17,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/6in4
   SECTION:=net
   CATEGORY:=Network
-  DEPENDS:=+kmod-ipv6 +kmod-sit
+  DEPENDS:=@IPV6 +kmod-sit
   TITLE:=IPv6-in-IPv4 configuration support
   MAINTAINER:=Jo-Philipp Wich <x...@subsignal.org>
   PKGARCH:=all
diff --git a/package/network/ipv6/6rd/Makefile 
b/package/network/ipv6/6rd/Makefile
index cde7117..04d607e 100644
--- a/package/network/ipv6/6rd/Makefile
+++ b/package/network/ipv6/6rd/Makefile
@@ -17,7 +17,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/6rd
   SECTION:=net
   CATEGORY:=Network
-  DEPENDS:=+kmod-ipv6 +kmod-sit
+  DEPENDS:=@IPV6 +kmod-sit
   TITLE:=6rd configuration support
   MAINTAINER:=Steven Barth <cy...@openwrt.org>
   PKGARCH:=all
diff --git a/package/network/ipv6/6to4/Makefile 
b/package/network/ipv6/6to4/Makefile
index fcec90d..20605f6 100644
--- a/package/network/ipv6/6to4/Makefile
+++ b/package/network/ipv6/6to4/Makefile
@@ -17,7 +17,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/6to4
   SECTION:=net
   CATEGORY:=Network
-  DEPENDS:=+kmod-ipv6 +kmod-sit
+  DEPENDS:=@IPV6 +kmod-sit
   TITLE:=IPv6-to-IPv4 configuration support
   MAINTAINER:=Jo-Philipp Wich <x...@subsignal.org>
   PKGARCH:=all
diff --git a/package/network/ipv6/ds-lite/Makefile 
b/package/network/ipv6/ds-lite/Makefile
index 8c22c46..919ac7e 100644
--- a/package/network/ipv6/ds-lite/Makefile
+++ b/package/network/ipv6/ds-lite/Makefile
@@ -17,7 +17,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/ds-lite
   SECTION:=net
   CATEGORY:=Network
-  DEPENDS:=+kmod-ipv6 +kmod-ip6-tunnel +resolveip
+  DEPENDS:=@IPV6 +kmod-ip6-tunnel +resolveip
   TITLE:=Dual-Stack Lite (DS-Lite) configuration support
   MAINTAINER:=Steven Barth <ste...@midlink.org>
   PKGARCH:=all
diff --git a/package/network/ipv6/map/Makefile 
b/package/network/ipv6/map/Makefile
index f6f2cd6..af6f758 100644
--- a/package/network/ipv6/map/Makefile
+++ b/package/network/ipv6/map/Makefile
@@ -18,7 +18,7 @@ include $(INCLUDE_DIR)/cmake.mk
 define Package/map
   SECTION:=net
   CATEGORY:=Network
-  DEPENDS:=+kmod-ipv6 +kmod-ip6-tunnel +libubox +libubus 
+iptables-mod-conntrack-extra
+  DEPENDS:=@IPV6 +kmod-ip6-tunnel +libubox +libubus 
+iptables-mod-conntrack-extra
   TITLE:=MAP-E and Li

Re: [OpenWrt-Devel] Rebooting boards with 16M SPI flash

[Arjen de Korte]

Citeren Paul Fertser fercer...@gmail.com:


Hi John,

John Crispin blo...@openwrt.org writes:

looks good to me but i will run this past linux-mtd and ask them for an
opinion before merging it.


This patch was meant as a quick hack rather than a complete solution,
that's why I didn't bother adding proper commit message, S-o-b etc. But
since I'm the author, I can do that promptly, whenever that's needed.

The main limitation is that I checked only a single datasheet (likely
Winbond) so other models might require different treatment.


The way to exit 4-byte addressing mode, can be determined by looking  
at the SFDP (JEDEC Standard JESD216B). As you already suspected, there  
are many possibilities. The method required, can be derived from the  
16th DWORD from the JEDEC Basic Flash Parameter Table (page 28).



Another is
that such a patch is mostly a bad substitute for proper hardware design.


Not really. There may not be a hardware reset line if the flash is  
running in x4 data mode.


Regards, Arjen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH RFC] Add support for Ubiquiti Unifi Outdoor Plus

[Arjen de Korte]

Citeren Kirill Berezin ky...@rol.ru:


Hi Stefan,

I have a couple of suggestions.

First of all I think it will be better to initialize static  
variables in hsr_tune with zeroes :



++static void hsr_tune(struct ath_hw* ah, int bw, int fq) {
++  static int initialized = 0;
++  static int last_bw = 0, last_fq = 0;


These static variables will be initialized to zero anyway, so the  
above is redundant (but may be clearer to read). See  
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf, §6.7.8  
sub-paragraph 10.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Dirty Diamond

[Arjen de Korte]

+1

Citeren Hartmut Knaack knaac...@gmx.de:


That Doodle poll turned out to be spamed/trolled, and everyone could even
change or delete other votes. Since this was just communicated over this
mailing list, and subscribers are at least basically verified, why not have a
good old fashioned poll?

Give your +1 answer on this mail if you prefer Dirty Diamond.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

Citeren Arjen de Korte arjen+open...@de-korte.org:


Citeren Steven Barth cy...@openwrt.org:


Is that okay with you or do you see any other issues?


One issue left. Since IPv6 is configured statically here, the  
preferred- and valid lifetimes are 'forever' (represented as  
0x). If the lifetime is forever, it should stay that way.  
See attached patch. It does not deal with the situation where  
addr[i].{preferred,valid}  now, in which case the value may need to  
be clamped to 0 or 1. I'm not sure if this can ever happen though.


Never mind the last remark, that situation is dealt with by the lines  
in between what I changed. If the preferred lifetime is less or equal  
than now, it skips this entirely. Which means that the patch as is  
should be enough.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

Citeren Steven Barth cy...@openwrt.org:


Is that okay with you or do you see any other issues?


One issue left. Since IPv6 is configured statically here, the  
preferred- and valid lifetimes are 'forever' (represented as  
0x). If the lifetime is forever, it should stay that way. See  
attached patch. It does not deal with the situation where  
addr[i].{preferred,valid}  now, in which case the value may need to  
be clamped to 0 or 1. I'm not sure if this can ever happen though.


I saw negative preferred- and valid lifetimes in my NetworkManager  
logs, because the latter has broken logging. These values are unsigned  
integers, but they are logged as signed integers (hence the negative  
values in the logs).
diff --git a/src/dhcpv6-ia.c b/src/dhcpv6-ia.c
index 74e3441..de44581 100644
--- a/src/dhcpv6-ia.c
+++ b/src/dhcpv6-ia.c
@@ -728,13 +728,19 @@ static size_t append_reply(uint8_t *buf, size_t buflen, uint16_t status,
 	m = i;
 
 			for (size_t i = 0; i  addrlen; ++i) {
-uint32_t prefix_pref = addrs[i].preferred - now;
-uint32_t prefix_valid = addrs[i].valid - now;
+uint32_t prefix_pref = addrs[i].preferred;
+uint32_t prefix_valid = addrs[i].valid;
 
 if (addrs[i].prefix  96 ||
 		addrs[i].preferred = (uint32_t)now)
 	continue;
 
+if (prefix_pref != UINT32_MAX)
+	prefix_pref -= now;
+
+if (prefix_valid != UINT32_MAX)
+	prefix_valid -= now;
+
 if (a-length  128) {
 	struct dhcpv6_ia_prefix p = {
 		.type = htons(DHCPV6_OPT_IA_PREFIX),
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

Citeren Steven Barth cy...@openwrt.org:

After thinking it through a bit more, I changed the default behavior  
to the following:
The preferred lifetime is now as given by the ISP, however the  
DHCPv6 server will only hand out the address with the highest  
preferred lifetime (= the ULA unless disabled).


Since I avoid ULA like the plague, this probably won't be a problem  
for me and global IPv6 addresses will be served. But I'm not convinced  
that favoring a ULA prefix (if available) over an ip6prefix is best at  
all times.


Thus flash renumbering should still work (since only the ULA-address  
cannot be changed immediately).


Is that okay with you or do you see any other issues?


Well, one thing that still worries me, is that the behavior of the  
DHCPv6 server is different depending on the state of the O flag. From  
a DHCPv6 client perspective, it shouldn't. When both M- and O-flag are  
set, it is up to the client to decide if it wants to use DHCPv6 or  
SLAAC. You've made it clear that there may be reasons not to use an  
adress provided by DHCPv6 and use SLAAC instead. But this should not  
be the only (or default) way of operation. There may be reasons other  
than broken IPv6 uplinks why network administrators choose to set both  
M- and O-flags. I think the other reasons are far more common (the  
lack of DHCPv6 support in Android is just one of them). Even with the  
changes pushed out today, odhcpd makes the assumption that the  
ip6prefix can't be relied upon if a ULA prefix is provided and I think  
that is just incorrect.


Arjen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

Citeren Steven Barth cy...@openwrt.org:


Is that okay with you or do you see any other issues?


I'm seeing negative preferred and valid lifetimes:

Mar 30 19:24:46 host.example.com NetworkManager[750]: infovalid_lft -173
Mar 30 19:24:46 host.example.com NetworkManager[750]: info 
preferred_lft -173
Mar 30 19:54:47 host.example.com NetworkManager[750]: info 
valid_lft -1973
Mar 30 19:54:47 host.example.com NetworkManager[750]: info 
preferred_lft -1973
Mar 30 20:24:46 host.example.com NetworkManager[750]: info 
valid_lft -3772
Mar 30 20:24:46 host.example.com NetworkManager[750]: info 
preferred_lft -3772
Mar 30 20:54:46 host.example.com NetworkManager[750]: info 
valid_lft -5573
Mar 30 20:54:46 host.example.com NetworkManager[750]: info 
preferred_lft -5573
Mar 30 21:24:47 host.example.com NetworkManager[750]: info 
valid_lft -7373
Mar 30 21:24:47 host.example.com NetworkManager[750]: info 
preferred_lft -7373
Mar 30 21:54:46 host.example.com NetworkManager[750]: info 
valid_lft -9172
Mar 30 21:54:46 host.example.com NetworkManager[750]: info 
preferred_lft -9172
Mar 30 22:24:46 host.example.com NetworkManager[750]: info 
valid_lft -10972
Mar 30 22:24:46 host.example.com NetworkManager[750]: info 
preferred_lft -10972
Mar 30 22:54:46 host.example.com NetworkManager[750]: info 
valid_lft -12773
Mar 30 22:54:46 host.example.com NetworkManager[750]: info 
preferred_lft -12773


From the above it looks like the T1 (and T2) timers are not affected,  
it's just that the preferred and valid lifetimes are off. Not sure if  
this is not a problem in NetworkManager, but I have no time to check  
this out now (I'll be away from my mail a couple of days).


Arjen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

Citeren Steven Barth cy...@openwrt.org:


The problem is that you try to be smart by abusing the ability to set
the address preferred lifetime lower than T1.  I don't dispute that it
is allowed by the RFC, but it is definitely not recommended.
There is no formal requirement (not even a SHOULD) that says  
otherwise. The recommendation made is usually based on the basis  
that DHCPv6 is your only source of addresses which it isn't for us.


That may be, but I think it is sufficiently hacky that it really not  
should be the default (or even only) mode of operation. I will provide  
a patch shortly to make this configurable.



Based on this, it should not come as an surprise that a number of
clients start behaving erratically if you set T1 much higher than the
preferred lifetime.  Don't do that. It causes problems.

You can of course continue to argue that not honouring T1 is a bug, but
that will not fix any of the failing clients.
Now we know that they actually don't. The clients behave well, that  
seemed to be a misunderstanding.


No, they don't. With regard to the renewal storms, that was a  
misunderstanding. But even with the latest odhcpd from trunk,  
especially webmail clients *will* see loss of connection, as the  
source IP on outgoing connections will be different 1 second of every  
T1 interval. Depending on the leasetime that is configured on the  
server, this may be infrequent enough to be hardly noticeable, or will  
lead to support calls. In my case, it was the latter.


Arjen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

Citeren Steven Barth cy...@openwrt.org:


Hello Arjen,

most likely, your DHCPv6 client implementation is faulty and you  
should probably file a bug for more than one reason.


In that case, I have a lot of bug reports to file, because none of the  
DHCPv6 clients I tried were happy with preferred lifetimes of 1 second  
on their leases (which includes Windows 7, 8.1 and openSUSE 13.2).  
Removing lines


813 if (!a-accept_reconf  iface-managed  RELAYD_MANAGED_NO_AFLAG 
814 addrs[i].prefix == 64)
815 n.preferred = htonl(1);

and all were good again. I'm still looking for why setting a preferred  
lifetime of 1 second is not going to render the IPv6 address that is  
provided in the reply by odhcpd useless.


If the DHCPv6 server sends values for T1 and / or T2 which are valid  
the client must honor them and not try to be smart about lifetimes  
of addresses.


I'm not sure if preferred lifetime  T1 and/or T2 is expected behavior  
of the DHCPv6 server. One second after receiving the address, clients  
can't use the address for new connections, but also can't renew (until  
T1) or rebind (until T2). And that's precisely what I'm seeing here.  
Note that the continuous renewals were only with the first patch  
applied, for the most recent version of odhcpd the clients will just  
give up on the DHCPv6 address after one second and use SLAAC instead.  
But this is not what I want (and I can't switch off SLAAC either,  
since I have also clients to support which don't do DHCPv6).


Besides you also get addresses with higher values for preferred  
lifetime using RAs so you always have usable IPv6 addresses, so if  
your network-manager / OS behaves sanely you shouldn't have any  
issues.


They don't have an issue with IPv6 connectivity, its the source  
address that is used *I* have a problem with.



A work-around for this is setting:
option ra_management 0
in the lan-section of /etc/config/dhcp which will cause most clients  
to not use DHCPv6 and rely on RAs only.


This is not an option, as the whole purpose of using DHCPv6 for  
address configuration is to give clients a fixed IPv6 address. This  
has worked correctly since Barrier Breaker was released, I see no  
reason why it no longer should.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

Citeren Steven Barth cy...@openwrt.org:

This breaks clients that need fixed IPs (in my case, mostly webmail  
clients).
I wonder why they are so sensitive to source-address changes since  
their old address is still valid and not deprecated so there is no  
need to switch.


Webmail clients usually don't keep a connection open to the server,  
hence every connection is a new one. The webmail server only sees the  
source IP, so even if the DHCPv6 address is still valid for the  
client, a re-login is needed because the source IP changes.


I would gladly send the DHCPv6 address with 0 preferred lifetime but  
Apple's DHCPv6 client has issues and discard addresses therefore the  
1.



I could create a patch for this, but for now I consider this a  
regression, rather than a feature that needs to be configurable. I  
fail to understand the reasons why this change, which deliberately  
breaks the outgoing addresses (even if only momentarily) was  
introduced.
The reason for this change is that no host seems to support DHCPv6  
reconfiguration so we cannot update clients whenever we see fit  
(e.g. ISP goes down / is switched / designates a different PD).  
Which means that in absence of that in worst case client  
connectivity is lost for T1 seconds.


I don't see how this fixes things then. When ra_management is '2'  
you'd still run into the exact same problem (just without the fallback  
to SLAAC). In contrast, if the ip6prefix is configured statically (as  
in my case), there is no chance this will ever happen, since changes  
will never happen unexpectedly.


I think this would be much better fixed by making the client renew its  
lease more frequently (by lowering the valid and preferred lifetimes).  
The present fix will also not work for anthing else than a /64.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

Citeren Steven Barth cy...@openwrt.org:

In that case, I have a lot of bug reports to file, because none of  
the DHCPv6 clients I tried were happy with preferred lifetimes of 1  
second on their leases (which includes Windows 7, 8.1 and openSUSE  
13.2).
Sorry, I cannot confirm this. I just tried it with both Windows 8.1  
and Debian testing (w/ network-manager) both didn't react strangely  
or tried to renew the lease every second. Connectivity was okay.


The constant refreshes were only with the first patch that introduced  
this behavior (sorry for the confusion), with the current odhcpd  
clients will indeed not attempt to renew continuously. But they won't  
be able to use the address provided by DHCPv6 for outgoing connections  
either. They will use the address from SLAAC most of the time, but at  
the time the lease is renewed, switch to the DHCPv6 address and back  
again to SLAAC 1 second later. Although the window of opportunity for  
this to happen may seem to be small, it is enough for webmail clients  
that happen to check for the source IP to require logging in again  
when this happens (twice in a row actually, as the source IP changes  
twice).


Besides you also get addresses with higher values for preferred  
lifetime using RAs so you always have usable IPv6 addresses, so if  
your network-manager / OS behaves sanely you shouldn't have any  
issues.


They don't have an issue with IPv6 connectivity, its the source  
address that is used *I* have a problem with.
Unless you disable RAs there is no way to tell the client which  
source address to pick anyway. If some OS use the DHCPv6 addresses  
by default then thats by chance.


True. But most OSes will pick either one and will stick to that.  
Windows seems to favor DHCPv6, while Linux by defaults selects SLAAC  
then. Both are OK with me. The problem I have with the current  
implementation in odhcpd, is that systems favoring DHCPv6 will switch  
between the two.



A work-around for this is setting:
option ra_management 0
in the lan-section of /etc/config/dhcp which will cause most  
clients to not use DHCPv6 and rely on RAs only.


This is not an option, as the whole purpose of using DHCPv6 for  
address configuration is to give clients a fixed IPv6 address. This  
has worked correctly since Barrier Breaker was released, I see no  
reason why it no longer should.
That still works. The client will just not use the address for  
outgoing traffic.


This breaks clients that need fixed IPs (in my case, mostly webmail clients).

I'm fine with making this configurable (current behavior as default)  
though and would welcome a patch for this. I could put it on my todo  
but don't really know when I have the time to deal with this.


I could create a patch for this, but for now I consider this a  
regression, rather than a feature that needs to be configurable. I  
fail to understand the reasons why this change, which deliberately  
breaks the outgoing addresses (even if only momentarily) was introduced.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

I use an IPv6 tunnel provided by Hurricane Electric to provide IPv6  
access for my LAN. HE tunnels are configured statically (no DHCPv6 /  
PD involved) and for the purpose of understanding what ranges are  
used, assume the following:


WAN - 2001:DB8:DEAD:BEEF::/64 (local tunnel endpoint at  
2001:DB8:DEAD:BEEF::2)
LAN - 2001:DB8:CAFE:BABE::/64 (note this is not a subnet of the  
WAN, I think this may be important here)


I use both SLAAC + DHCPv6 on the LAN. Devices with DHCPv6 capability  
are configured with IPv4+IPv6 addresses in /etc/config/network. This  
has worked flawlessly in Barrier Breaker so far. After migrating to  
Chaos Calmer, DHCPv6 was essentially broken. Devices that previously  
were using addresses configured through DHCPv6 are now using SLAAC only.


Looking in the logs of one of the DHCPv6 clients (a laptop using  
NetworkManager), I noticed that it was handed out a lease with a  
preferred lifetime of just one (1) second. Consequently, it would  
attempt to renew the lease it gets every second, causing intermittent  
IPv6 availability (if at all) and huge CPU spikes on the router at the  
times the client connected. Reverting back to the version of odhcpd  
from Barrier Breaker fixed both these problems and DHCPv6 was useable  
again.


Digging into the code, the following commit broke odhcpd in my router  
(Netgear WNDR4300):


dhcpv6: allow flash renumbering in hybrid management mode
 
https://github.com/sbyx/odhcpd/commit/a5ebe69d1bc387937bc5448534751123833585fd


Neither of the following two changes to the same part of this code  
fixed things:


dhcpv6: fix calculation of T1 and T2
 
https://github.com/sbyx/odhcpd/commit/b461334ab277b6e8fd1622ab7c8a655363bd3f6c


DHCPv6: enable flash-renumbering hack only for /64 prefixes
 
https://github.com/sbyx/odhcpd/commit/3b628005e66e90770b2757a4a02c1dee25ccb883


I'm not quite sure what problem these commits are trying to solve, but  
it looks to me that the logic behind it is somehow not working for me.  
For all intents and purposes, the IPv6 addresses I use are static, so  
I see no reason why it would be necessary to renumber addresses at all.


Any thoughts?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks

[Arjen de Korte]

Citeren Arjen de Korte arjen+open...@de-korte.org:

I use an IPv6 tunnel provided by Hurricane Electric to provide IPv6  
access for my LAN. HE tunnels are configured statically (no DHCPv6 /  
PD involved) and for the purpose of understanding what ranges are  
used, assume the following:


WAN - 2001:DB8:DEAD:BEEF::/64 (local tunnel endpoint at  
2001:DB8:DEAD:BEEF::2)
LAN - 2001:DB8:CAFE:BABE::/64 (note this is not a subnet of the  
WAN, I think this may be important here)


I use both SLAAC + DHCPv6 on the LAN. Devices with DHCPv6 capability  
are configured with IPv4+IPv6 addresses in /etc/config/network.


In /etc/config/dhcp of course.

This has worked flawlessly in Barrier Breaker so far. After  
migrating to Chaos Calmer, DHCPv6 was essentially broken. Devices  
that previously were using addresses configured through DHCPv6 are  
now using SLAAC only.


Looking in the logs of one of the DHCPv6 clients (a laptop using  
NetworkManager), I noticed that it was handed out a lease with a  
preferred lifetime of just one (1) second. Consequently, it would  
attempt to renew the lease it gets every second, causing  
intermittent IPv6 availability (if at all) and huge CPU spikes on  
the router at the times the client connected. Reverting back to the  
version of odhcpd from Barrier Breaker fixed both these problems and  
DHCPv6 was useable again.


Digging into the code, the following commit broke odhcpd in my  
router (Netgear WNDR4300):


dhcpv6: allow flash renumbering in hybrid management mode
 
https://github.com/sbyx/odhcpd/commit/a5ebe69d1bc387937bc5448534751123833585fd


Neither of the following two changes to the same part of this code  
fixed things:


dhcpv6: fix calculation of T1 and T2
 
https://github.com/sbyx/odhcpd/commit/b461334ab277b6e8fd1622ab7c8a655363bd3f6c


DHCPv6: enable flash-renumbering hack only for /64 prefixes
 
https://github.com/sbyx/odhcpd/commit/3b628005e66e90770b2757a4a02c1dee25ccb883


I'm not quite sure what problem these commits are trying to solve,  
but it looks to me that the logic behind it is somehow not working  
for me. For all intents and purposes, the IPv6 addresses I use are  
static, so I see no reason why it would be necessary to renumber  
addresses at all.


Any thoughts?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Rebuilding for specific hardware, example ar71xx/image for TP-Link TL-WR841ND

[Arjen de Korte]

Citeren Jean-Michel Pouré - GOOZE jmpo...@gooze.eu:


Le lundi 23 mars 2015 à 15:18 +0100, Arjen de Korte a écrit :

No, you have to run 'make menuconfig' and select the luci package in
there. In many cases, other packages are needed when you select a
package. This is exactly what menuconfig automates (so making
changes
by hand in the generated .config file is usually a bad idea, just
like
the top lines of this file will tell you).


Thanks, I got it now. So I should run make oldconfig when compiling
automatically everyday?


You could do that, but this is only needed when major changes are made  
in the tree. For instance, if you upgrade to a new version (you have a  
working .config that you used for building Barrier Breaker, but you  
now want to use that as a start when you want to migrate to Chaos  
Calmer). For keeping in sync with the daily changes in the trunk,  
you'll probably fine most of the time without it (subtle changes will  
be dealt by 'make silent_oldconfig' which is part of the build process).

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Rebuilding for specific hardware, example ar71xx/image for TP-Link TL-WR841ND

[Arjen de Korte]

Citeren Jean-Michel Pouré - GOOZE jmpo...@gooze.eu:


Le lundi 23 mars 2015 à 21:21 +0800, Yousong Zhou a écrit :

./scripts/feeds install pkgname will make those packages
visible/available/selectable in menuconfig (creating links in
package/feeds/feedsname/) as the prior update action only fetches them
down as is.


Thanks!

So I need to activate compilation with:
echo  .config 'CONFIG_PACKAGE_luci=y'


No, you have to run 'make menuconfig' and select the luci package in  
there. In many cases, other packages are needed when you select a  
package. This is exactly what menuconfig automates (so making changes  
by hand in the generated .config file is usually a bad idea, just like  
the top lines of this file will tell you).

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Multiple OpenWrt devices collectively managed?

[Arjen de Korte]

Citeren Janne Cederberg janne.cederb...@gmail.com:


Cool, this sparked a conversation :)
Yes, the background of the question was not a mesh network but a
network where all APs could be connected to the same switch for
example and from there to a DHCP server. A controller would control
which channels the APs operate on to minimize interference a) from
each other and b) from possible other networks. David Lang stated
exactly what I was attempting to convey.


David has 'some experience' with managing large wifi networks:

https://www.usenix.org/system/files/conference/lisa12/lisa12-final-32.pdf

Well written and even if you manage a small wifi network well worth reading.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt-Commits] r44899 - trunk/package/network/config/netifd

[Arjen de Korte]

I'm running trunk on a Netgear WNDR4300. On this router, a Hurricane  
Electric tunnel is configured to provide IPv6 access for the LAN. All  
was fine until this morning. Bisecting leads to the below commit to  
break IPv6 routing (IPv4 was still fine). Could it be that 6in4 needs  
to be modified after this commit?


Citeren openwrt-comm...@openwrt.org:


Author: cyrus
Date: 2015-03-20 08:50:45 +0100 (Fri, 20 Mar 2015)
New Revision: 44899

Modified:
   trunk/package/network/config/netifd/Makefile
Log:
netifd: device update fixes, improvements in policy routing

Signed-off-by: Steven Barth ste...@midlink.org

Modified: trunk/package/network/config/netifd/Makefile
===
--- trunk/package/network/config/netifd/Makefile	2015-03-19 21:51:44  
UTC (rev 44898)
+++ trunk/package/network/config/netifd/Makefile	2015-03-20 07:50:45  
UTC (rev 44899)

@@ -1,13 +1,13 @@
 include $(TOPDIR)/rules.mk

 PKG_NAME:=netifd
-PKG_VERSION:=2015-03-15
+PKG_VERSION:=2015-03-20
 PKG_RELEASE=$(PKG_SOURCE_VERSION)

 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL:=http://git.openwrt.org/project/netifd.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=45fd905c980e56b20770d4b34556749fbca53fcc
+PKG_SOURCE_VERSION:=2fb3d0e9205e2a4cea38062caefd7251f562866d
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
 PKG_MAINTAINER:=Felix Fietkau n...@openwrt.org
 # PKG_MIRROR_MD5SUM:=
___
openwrt-commits mailing list
openwrt-comm...@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-commits





smime.p7s
Description: S/MIME Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board

[Arjen de Korte]

Citeren Robert P. J. Day rpj...@crashcourse.ca:


On Wed, 8 Oct 2014, Arjen de Korte wrote:


Citeren Robert P. J. Day rpj...@crashcourse.ca:

On Tue, 7 Oct 2014, Aaron Z wrote:

 On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day rpj...@crashcourse.ca
 wrote:
 finally, given that this board looks like *someone's* dev board,
   would anyone know where it might have come from? there's no
   manufacturer name on it anywhere. in the ramips dts file MT7620a.dts,
   i can see a reference to a Ralink MT7620a + MT7610e evaluation
   board. might that be it? i'd post a pic but i signed an NDA, although
   since no one has any idea where the board came from, i'm not sure what
   i'd be disclosing by posting a pic.
  
 i'm open to any information i can get, particularly support for that
   MT7610EN radio chip. thanks muchly.
 Any chance that it has an FCC ID, chip model numbers or other
 regulatory body unique number on it that you could share?
 I realize that you are in Canada and its a off brand board but you
 never know, the OEM might have used the same FCC number when they
 cloned the board...

  ah, just noticed that /proc/cpuinfo identifies this as a HiWiFi JI2
Board, whatever the heck that is. google is not being particularly
helpful.

rday

p.s. just for the heck of it, i started a wiki page and recorded a
bunch of board info:

http://www.crashcourse.ca/wiki/index.php/OpenWrt_Pandora

Looking at the image posted earlier, it has several approval
markings, so that I wouldn't expect this to be a development board
(you don't spend time and money on approvals for development
boards). Isn't this just the internals of the Pandora's Hope router
(Pro version) marketed by http://www.cleanrouter.com/? The
screenshots from the manual on their site seem to confirm that it is
running some version of OpenWRT.


  i'm looking at this page:

http://www.cleanrouter.com/home/product

and the processor is shown as an atheros AR7161, though. also, the
pandoras hope router apparently has 4 wired ports, and this board has
only two. at the risk of abusing this mailing list a bit more, i took
a pic of the top of the board and attached it, if that helps.


Nevermind my babbling. You probably have a Baidu PandoraBox device in  
your hands.




Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday






smime.p7s
Description: S/MIME Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel