Re: [OpenWrt-Devel] [PATCH RFC] Add support for Ubiquiti Unifi Outdoor Plus
Citeren Kirill Berezin :
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] Rebooting boards with > 16M SPI flash
Citeren Paul Fertser : Hi John, John Crispin 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] Rebooting boards with > 16M SPI flash
Citeren Paul Fertser : Arjen de Korte writes: Citeren Paul Fertser : 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. Imagine there's a bug in the kernel that made it hang for real. Then you're counting on the watchdog (usually SoCs come with one integrated) to cleanly reboot the whole system. If the flash is used in QSPI or whatever other mode that doesn't allow a dedicated reset line then it needs to be powercycled on hardware level to ensure reliable operation, I think. Exactly. If you're designing for rock bottom low cost (I'm a hardware engineer), the SPI flash used will not have a dedicated reset line. That is why helpdesks will always tell in case of problems to power off a device for 30-60 seconds and then switch it back on again. In many cases, a watchdog reset is not equivalent to a power on reset. Best 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
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] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
Citeren Felix Fietkau : On 2016-01-22 22:29, edgar.sol...@web.de wrote: On 22.01.2016 16:20, Felix Fietkau wrote: On 2016-01-22 16:03, edgar.sol...@web.de wrote: On 22.01.2016 14:32, Weedy wrote: Question: The busybox binary (for me) goes from 366,401 bytes to 300,327 with the removal of wget from it. Therefore, the uclient-fetch binary swapout causes a 46,379 byte increase in size. I assume the desire to move to uclient-fetch from busybox is for the SSL support? If so, it still does not support SSL without also building ustream-ssl. yeah. an ssl capable wget (whatever it's called) out of the box would be greatly appreciated. @Felix: is that on the table? It's already done. With uclient-fetch, you can simply install any ustream-ssl variant (along with ca-certificates if you want to have proper validation), and it'll immediately be SSL capable. That was my main motivation behind replacing wget with ustream-ssl. The aforementioned size increase is probably either a bug or a measurement error (see my other mail regarding that subject). nice! is there a possibility to create a wget wrapper? i assume not everyone is familiar with uclient-fetch, so at least a stub noting to use uclient-fetch might probably help when users are confused that wget isn't there. You keep asking for things that are already there :) The uclient-fetch package provides a symlink to wget and it is fully command line compatible as well. Users don't have to change their habits and scripts that don't hardcode the path will continue to work as well. Not entirely. It (r48456) segfaults on receiving a 301 redirect for http->https: # /bin/uclient-fetch -O- 'http://de-korte.org/robots.txt' Downloading 'http://de-korte.org/robots.txt' Connecting to 2001:470:7ad2::10:80 Segmentation fault 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&password=munged&myip=1.2.3.4' Downloading 'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=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. For example, the following works as expected: # /bin/uclient-fetch -O- 'https://de-korte.org/robots.txt' Downloading 'https://de-korte.org/robots.txt' Connecting to 2001:470:7ad2::10:443 Writing to stdout User-agent: * Disallow: / (null) 100% |***|27 0:00:00 ETA Download completed (27 bytes) Regards, Arjen ___ 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
Citeren Felix Fietkau : 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&password=munged&myip=1.2.3.4' Downloading 'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=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] uclient-fetch & SSL WAS:Re: DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
Citeren Felix Fietkau : On 2016-01-23 20:54, Arjen de Korte wrote: Citeren Felix Fietkau : 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&password=munged&myip=1.2.3.4' Downloading 'https://dyn.dns.he.net/nic/update?hostname=example.com&password=munged&myip=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. Should be fixed in r48465 Indeed. Thanks! 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
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] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
Citeren Christian Schoenebeck : 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&ip=8.8.8.8' Downloading 'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com&ip=8.8.8.8' Connecting to 62.201.160.30:443 Connection error: Server hostname does not match SSL certificate The certificate is valid, but update.spdns.de uses a wildcard certificate (which technically is OK). subject=/serialNumber=YnFcKoUlVu1DhcIaoJxVwNDp/tTAKrDm/OU=GT17804807/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=*.spdns.de issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA But you won't get an exact match on the hostname, so this is something that probably requires fixing. GNU wget works as expected root@OpenWrt:~# wget -O- 'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com&ip=8.8.8.8' --2016-01-24 13:01:39-- https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com&ip=8.8.8.8 Resolving update.spdns.de... 62.201.160.30, 2001:868:100:901:53::2 Connecting to update.spdns.de|62.201.160.30|:443... connected. HTTP request sent, awaiting response... 401 Unauthorized Authentication selected: Basic realm="spdns nic update" Reusing existing connection to update.spdns.de:443. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: 'STDOUT' - [<=>] 0 --.-KB/s invalidip - [ <=>] 10 --.-KB/sin 0s 2016-01-24 13:01:39 (1.20 MB/s) - written to stdout [10] What did I wrong ? Thanks Christian ___ 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] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
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&ip=8.8.8.8' Downloading 'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com&ip=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&ip=8.8.8.8' Downloading 'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com&ip=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] DD: CONFIG_BUSYBOX_DEFAULT_WGET is not set
Citeren Felix Fietkau : On 2016-01-25 19:14, Arjen de Korte wrote: 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&ip=8.8.8.8' Downloading 'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com&ip=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&ip=8.8.8.8' Downloading 'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com&ip=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] Changeset 48456
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
Citeren Felix Fietkau : On 2016-01-25 20:26, Arjen de Korte wrote: Citeren Felix Fietkau : On 2016-01-25 19:14, Arjen de Korte wrote: 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&ip=8.8.8.8' Downloading 'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com&ip=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&ip=8.8.8.8' Downloading 'https://myuser:myp...@update.spdns.de/nic/update?hostname=myhost.example.com&ip=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] stdout and putchar() behavior in musl
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
[OpenWrt-Devel] [PATCH] package: Remove dependencies to kmod-ipv6
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 --- 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 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 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 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 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 Lightweight 4over6 configuration support MAINTAINER:=Steven Barth endef diff --git a/package/network/ipv6/odhcp6c/Makefile b/package
[OpenWrt-Devel] [PATCH 2/2] packages: Remove dependencies to kmod-ipv6
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 --- 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 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] Configure IPv6 kernel options in config/Config-kernel.in
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 --- 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
Citeren John Crispin : 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 --- 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
Re: [OpenWrt-Devel] [PATCH 2/2] packages: Remove dependencies to kmod-ipv6
Citeren John Crispin : 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 --- 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 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
Re: [OpenWrt-Devel] [PATCH] lantiq: fix use of IRQF_DISABLED in lantiq kmods
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 //| IRQF_S
Re: [OpenWrt-Devel] 回复： [OpenWrt-Users] 回复： How to disable the Internal PA in the mt7620a ?
Citeren Soulkey : Sorry, Could you tell me how to disable the Internal Pa in mt7620 soc ? I am very eager to get your help. Thank you. Soulkey This is not MediaTek support. Be patient. You've made your point that you are in a hurry, but unless you can get a direct answer from the vendor (MediaTek), be aware that the only way to find out how to do this, is reverse engineering. If someone is already working on that, it takes time. If not, you'll have to do that yourself. Karl O. Pinc 于 2015年11月4日, 星期三, 下午 9:25 写道： On Wed, 4 Nov 2015 08:40:34 + (UTC) Soulkey wrote: I send this email to openwrt-devel@lists.openwrt.org, openwrt-us...@lists.openwrt.org, Yes. Do not cross post to 2 lists. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein ___ 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] [PATCH] ramips: reset m25p80 when shutdown
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(&flash->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 1/3] ramips: Fix whitespace in the switch driver.
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
[OpenWrt-Devel] Memory leak in mac80211?
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? Best regards, Arjen unreferenced object 0x86469200 (size 2048): comm "softirq", pid 0, jiffies 8710 (age 1140.290s) hex dump (first 32 bytes): 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b backtrace: [<800f4934>] create_object+0x134/0x274 [<800f1f38>] __kmalloc+0x1bc/0x1dc [<80247324>] ag71xx_fill_rx_buf+0x68/0xf8 [<80247e54>] ag71xx_poll+0x280/0x3d8 [<802677e0>] net_rx_action+0x110/0x2c4 [<80083ca8>] __do_softirq+0x16c/0x298 [<80083ff0>] irq_exit+0x54/0x70 [<80060830>] ret_from_irq+0x0/0x4 unreferenced object 0x86985160 (size 176): comm "softirq", pid 0, jiffies 8873 (age 1138.660s) hex dump (first 32 bytes): 80 3c 1b 20 80 3c 1b 20 00 00 00 00 00 00 00 00 .<. .<. 00 00 00 00 85 c0 21 00 40 00 40 00 00 01 00 00 ..!.@.@. backtrace: [<800f4934>] create_object+0x134/0x274 [<800f205c>] kmem_cache_alloc+0x104/0x120 [<8025e304>] __build_skb+0x40/0xc0 [<8025e3a0>] build_skb+0x1c/0x9c [<80247d1c>] ag71xx_poll+0x148/0x3d8 [<802677e0>] net_rx_action+0x110/0x2c4 [<80083ca8>] __do_softirq+0x16c/0x298 [<80083ff0>] irq_exit+0x54/0x70 [<80060830>] ret_from_irq+0x0/0x4 [<8006f104>] r4k_wait_irqoff+0x18/0x20 [<800a0320>] cpu_startup_entry+0x110/0x138 [<803e2bc8>] start_kernel+0x468/0x488 unreferenced object 0x86a1f6e0 (size 176): comm "softirq", pid 0, jiffies 18273 (age 1044.660s) hex dump (first 32 bytes): 85 74 b9 40 85 74 b9 40 00 00 00 00 00 00 00 00 .t.@.t.@ 87 5b 7a 00 85 c0 21 00 40 00 40 00 00 02 00 00 .[z...!.@.@. backtrace: [<800f4934>] create_object+0x134/0x274 [<800f205c>] kmem_cache_alloc+0x104/0x120 [<8025bda4>] __alloc_skb+0x60/0x184 [<802fe844>] ndisc_alloc_skb+0x5c/0x150 [<802ffc64>] ndisc_send_ns+0xd8/0x190 [<802ffe4c>] ndisc_solicit+0x130/0x16c [<80271314>] neigh_probe+0x54/0x7c [<80275a7c>] neigh_timer_handler+0x1a8/0x260 [<800aaa28>] call_timer_fn.isra.3+0x24/0x80 [<800aac2c>] run_timer_softirq+0x1a8/0x1e8 [<80083ca8>] __do_softirq+0x16c/0x298 [<80083ff0>] irq_exit+0x54/0x70 [<80060830>] ret_from_irq+0x0/0x4 unreferenced object 0x857a9500 (size 512): comm "softirq", pid 0, jiffies 18273 (age 1044.660s) hex dump (first 32 bytes): 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b backtrace: [<800f4934>] create_object+0x134/0x274 [<800f41d0>] __kmalloc_track_caller+0x1b8/0x1d8 [<8025bce0>] __kmalloc_reserve.isra.3+0x40/0xa4 [<8025bdcc>] __alloc_skb+0x88/0x184 [<802fe844>] ndisc_alloc_skb+0x5c/0x150 [<802ffc64>] ndisc_send_ns+0xd8/0x190 [<802ffe4c>] ndisc_solicit+0x130/0x16c [<80271314>] neigh_probe+0x54/0x7c [<80275a7c>] neigh_timer_handler+0x1a8/0x260 [<800aaa28>] call_timer_fn.isra.3+0x24/0x80 [<800aac2c>] run_timer_softirq+0x1a8/0x1e8 [<80083ca8>] __do_softirq+0x16c/0x298 [<80083ff0>] irq_exit+0x54/0x70 [<80060830>] ret_from_irq+0x0/0x4 unreferenced object 0x8730b840 (size 176): comm "softirq", pid 0, jiffies 62787 (age 599.520s) hex dump (first 32 bytes): 85 6a b7 48 85 6a b7 48 00 00 00 00 00 00 00 00 .j.H.j.H 87 5b 7a 00 85 c0 21 00 40 00 40 00 00 02 00 00 .[z...!.@.@. backtrace: [<800f4934>] create_object+0x134/0x274 [<800f205c>] kmem_cache_alloc+0x104/0x120 [<8025bda4>] __alloc_skb+0x60/0x184 [<802fe844>] ndisc_alloc_skb+0x5c/0x150 [<802ffc64>] ndisc_send_ns+0xd8/0x190 [<802ffe4c>] ndisc_solicit+0x130/0x16c [<80271314>] neigh_probe+0x54/0x7c [<80275a7c>] neigh_timer_handler+0x1a8/0x260 [<800aaa28>] call_timer_fn.isra.3+0x24/0x80 [<800aac2c>] run_timer_softirq+0x1a8/0x1e8 [<80083ca8>] __do_softirq+0x16c/0x298 [<80083dfc>] run_ksoftirqd+0x28/0x48 [<80098ea0>] smpboot_thread_fn+0x148/0x178 [<80096f48>] kthread+0xdc/0xe8 [<80060878>] ret_from_kernel_thread+0x14/0x1c unreferenced object 0x85685800 (size 512): comm "softirq", pid 0, jiffies 62787 (age 599.530s) hex dump (first 32 bytes): 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b backtrace: [<800f4934>] create_object+0x134/0x274 [<800f41d0>] __kmalloc
Re: [OpenWrt-Devel] Memory leak in mac80211?
Citeren Felix Fietkau : 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] Bumping ar71xx to 4.14
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] Moving the mailing lists
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] [PATCH] procd: Fix compile error with GCC8
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] [PATCH v1] 6in4: add maxtry option to make more persistent updating HE endpoint
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] desperately seeking info on this weird MT7620A/MT7610EN dev board
Citeren "Robert P. J. Day" : On Tue, 7 Oct 2014, Aaron Z wrote: On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day 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. Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel 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
Citeren "Robert P. J. Day" : On Wed, 8 Oct 2014, Arjen de Korte wrote: Citeren "Robert P. J. Day" : >On Tue, 7 Oct 2014, Aaron Z wrote: > > >On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day > >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
Re: [OpenWrt-Devel] [OpenWrt-Commits] r44899 - trunk/package/network/config/netifd
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 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 # 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] Rebuilding for specific hardware, example ar71xx/image for TP-Link TL-WR841ND
Citeren Jean-Michel Pouré - GOOZE : 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] Rebuilding for specific hardware, example ar71xx/image for TP-Link TL-WR841ND
Citeren Jean-Michel Pouré - GOOZE : 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] Multiple OpenWrt devices collectively managed?
Citeren Janne Cederberg : 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
[OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
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
Citeren 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. 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] DHCPv6 flash renumbering patches with HE tunnel breaks
Citeren Steven Barth : 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
Citeren Steven Barth : 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
Re: [OpenWrt-Devel] DHCPv6 flash renumbering patches with HE tunnel breaks
Citeren Steven Barth : 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
Citeren Steven Barth : 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
Citeren Steven Barth : 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
Citeren Steven Barth : 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]: valid_lft -173 Mar 30 19:24:46 host.example.com NetworkManager[750]: preferred_lft -173 Mar 30 19:54:47 host.example.com NetworkManager[750]: valid_lft -1973 Mar 30 19:54:47 host.example.com NetworkManager[750]: preferred_lft -1973 Mar 30 20:24:46 host.example.com NetworkManager[750]: valid_lft -3772 Mar 30 20:24:46 host.example.com NetworkManager[750]: preferred_lft -3772 Mar 30 20:54:46 host.example.com NetworkManager[750]: valid_lft -5573 Mar 30 20:54:46 host.example.com NetworkManager[750]: preferred_lft -5573 Mar 30 21:24:47 host.example.com NetworkManager[750]: valid_lft -7373 Mar 30 21:24:47 host.example.com NetworkManager[750]: preferred_lft -7373 Mar 30 21:54:46 host.example.com NetworkManager[750]: valid_lft -9172 Mar 30 21:54:46 host.example.com NetworkManager[750]: preferred_lft -9172 Mar 30 22:24:46 host.example.com NetworkManager[750]: valid_lft -10972 Mar 30 22:24:46 host.example.com NetworkManager[750]: preferred_lft -10972 Mar 30 22:54:46 host.example.com NetworkManager[750]: valid_lft -12773 Mar 30 22:54:46 host.example.com NetworkManager[750]: 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
Citeren Steven Barth :
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
Citeren Arjen de Korte :
Citeren Steven Barth :
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] Dirty Diamond
+1 Citeren Hartmut Knaack : 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
