[OpenWrt-Devel] netifd: problem setting routes for alias-networks
when setting an alias network via network.@alias[0]=alias network.@alias[0].interface=lan network.@alias[0].proto=static network.@alias[0].ipaddr=192.168.10.2 network.@alias[0].netmask=255.255.255.0 and adding a route 'myroute' on top of this, the route will not be established on bootup network.myroute=route network.myroute.interface=lan network.myroute.target=192.168.0.0 network.myroute.netmask=255.255.255.0 network.myroute.gateway=192.168.10.1 maybe a order problem? first there must be the alias, then the route... bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
On 2013-09-15 10:20 AM, Bastian Bittorf wrote: when setting an alias network via network.@alias[0]=alias network.@alias[0].interface=lan network.@alias[0].proto=static network.@alias[0].ipaddr=192.168.10.2 network.@alias[0].netmask=255.255.255.0 and adding a route 'myroute' on top of this, the route will not be established on bootup network.myroute=route network.myroute.interface=lan Try network.myroute.interface=alias - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Patch][packages] peervpn: update peervpn to 0-036 and change peervpn to VPN menu
Update the peervpn package in feeds and change the location in menuconfig to VPN submenu --- net/peervpn/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/peervpn/Makefile b/net/peervpn/Makefile index 695191c..ff930e6 100644 --- a/net/peervpn/Makefile +++ b/net/peervpn/Makefile @@ -8,18 +8,20 @@ include $(TOPDIR)/rules.mk PKG_NAME:=peervpn -PKG_VERSION:=0-023 +PKG_VERSION:=0-036 PKG_RELEASE:=1 PKG_BUILD_DIR :=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION) PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL :=http://www.peervpn.net/files +PKG_MD5SUM:=38fe86fed7ec341887220626cd102ec1 include $(INCLUDE_DIR)/package.mk define Package/peervpn SECTION:=net CATEGORY:=Network + SUBMENU:=VPN TITLE:=PeerVPN the open source peer-to-peer VPN URL:=http://www.peervpn.net/ DEPENDS:=+libopenssl +ip -- 1.8.1.2 smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k (ad-hoc?) problems in compat-wireless trunk as of sept 6/2
On 2013-09-09 1:29 PM, Nicolás Echániz wrote: I have kept testing this and was able to reproduce the same problem every time. The performance perception when the network is at rush hour is very unstable so I tried to reproduce traffic conditions during late night. I sent multiple netperfs through different routes and while the netperfs were running turned of one node. Latency climbed to the thousands and it took a while for it to stabilize again. Then I turned off another node, latency went sky high again for some seconds until I lost conectivity and could monitor no more. I waited more than 15 minutes for the net to be reachable again from my local node. (Nodes are automatically reset when they cannot reach the network gateway for more than 15 minutes) All ping tests are done on fe80 local IPv6 addresses so no routing protocol is involved in case someone's wondering. Also, from what I see (iw station dump), routers are associated but can send no data. I've committed some fixes that might be related to this issue. Please test current OpenWrt trunk. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] kernel update to 3.10.12
Hello, can we have 3.10.12 updated to OpenWrt trunk and patches refreshed please? I managed to manually compile 3.10.11 without 030-timer_list_fix.patch which seems to be fixed upstream but some more patch reworking is required for 3.10.12 : - 670-ipv6-allow-rejecting-with-source-address-failed-policy.patch - 902-unaligned_access_hacks.patch Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
* Felix Fietkau n...@openwrt.org [15.09.2013 11:58]: Try network.myroute.interface=alias uci changes looks now like this: network.cfg114d8f=alias network.cfg114d8f.interface=lan network.cfg114d8f.proto=static network.cfg114d8f.ipaddr=192.168.10.2 network.cfg114d8f.netmask=255.255.255.0 network.cfg12c8b4=route network.cfg12c8b4.interface=alias network.cfg12c8b4.target=192.168.0.0 network.cfg12c8b4.netmask=255.255.255.0 network.cfg12c8b4.gateway=192.168.10.1 the alias-IP is applied, the route is not. i'am sure i make a mistake, but which? manually it's working: ip route add 192.168.0.0/24 via 192.168.10.1 bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
On 2013-09-15 12:16 PM, Bastian Bittorf wrote: * Felix Fietkau n...@openwrt.org [15.09.2013 11:58]: Try network.myroute.interface=alias uci changes looks now like this: network.cfg114d8f=alias network.cfg114d8f.interface=lan network.cfg114d8f.proto=static network.cfg114d8f.ipaddr=192.168.10.2 network.cfg114d8f.netmask=255.255.255.0 network.cfg12c8b4=route network.cfg12c8b4.interface=alias network.cfg12c8b4.target=192.168.0.0 network.cfg12c8b4.netmask=255.255.255.0 network.cfg12c8b4.gateway=192.168.10.1 the alias-IP is applied, the route is not. i'am sure i make a mistake, but which? I probably should have written alias instead of alias. The alias section needs a name (it's considered an interface by netifd), and the route 'interface' option needs to point at that alias section name. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
* Felix Fietkau n...@openwrt.org [15.09.2013 12:52]: I probably should have written alias instead of alias. The alias section needs a name (it's considered an interface by netifd), and the route 'interface' option needs to point at that alias section name. thank you. it works like this: uci add network alias uci set network.@alias[-1].interface=lan uci set network.@alias[-1].bla=... ... uci add network route uci set network.@route[-1].interface=cfg164d8f uci set network.@route[-1].bla=... ... i have to point to the handle 'uci add $section' gives me. what does not work is: uci set network.@route[-1].interface=@[-2] why not? also in http://wiki.openwrt.org/doc/uci/network#aliases there is warning for 'deprecated'. what is the better way? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
On 2013-09-15 1:25 PM, Bastian Bittorf wrote: * Felix Fietkau n...@openwrt.org [15.09.2013 12:52]: I probably should have written alias instead of alias. The alias section needs a name (it's considered an interface by netifd), and the route 'interface' option needs to point at that alias section name. thank you. it works like this: uci add network alias uci set network.@alias[-1].interface=lan uci set network.@alias[-1].bla=... ... uci add network route uci set network.@route[-1].interface=cfg164d8f uci set network.@route[-1].bla=... Bad idea. The cfg164d8f name is not guaranteed to stay constant with changes to the section, so you should name the alias section instead of relying on autogenerated names on anonymous sections. i have to point to the handle 'uci add $section' gives me. what does not work is: uci set network.@route[-1].interface=@[-2] why not? Because netifd looks up names internally, it does not use the uci extended lookup syntax. also in http://wiki.openwrt.org/doc/uci/network#aliases there is warning for 'deprecated'. what is the better way? You can create an interface section, and use @lan as ifname. The alias syntax will stay supported though. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
* Felix Fietkau n...@openwrt.org [15.09.2013 13:54]: uci add network alias uci set network.@alias[-1].interface=lan uci set network.@alias[-1].bla=... uci add network route uci set network.@route[-1].interface=cfg164d8f uci set network.@route[-1].bla=... Bad idea. The cfg164d8f name is not guaranteed to stay constant with changes to the section, so you should name the alias section instead of relying on autogenerated names on anonymous sections. which commands should i use for naming the alias section? i tried e.g. uci set network.@alias[-1].name=test can you please write down the commands in the right order? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why is everyone patching broadcom-wl-5.100.138
2013/9/15 James Hilliard james.hillia...@gmail.com: From what I'm seeing everyone is patching broadcom-wl around this(http://mirror2.openwrt.org/sources/broadcom-wl-5.100.138.tar.bz2) driver for the Netgear WNDR4500 for pretty much everything broadcom-wl related. What's the point of making a bunch of patches for this file when you could just use one of the many other broadcom-wl drivers that are actually designed for the target device already. I have attached broadcom-wl for the linksys/cisco e3000/wrt610nv2 which should support fully simultaneous dual-band N on both 2.4 and 5ghz channels. Please include that wl.ko you extracted in your OpenWrt build (or just wget it, whatever) and try to load it. I can even help you with the command: insmod wl.ko Let us know when you succeed ;) -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
On 2013-09-15 2:35 PM, Bastian Bittorf wrote: * Felix Fietkau n...@openwrt.org [15.09.2013 13:54]: uci add network alias uci set network.@alias[-1].interface=lan uci set network.@alias[-1].bla=... uci add network route uci set network.@route[-1].interface=cfg164d8f uci set network.@route[-1].bla=... Bad idea. The cfg164d8f name is not guaranteed to stay constant with changes to the section, so you should name the alias section instead of relying on autogenerated names on anonymous sections. which commands should i use for naming the alias section? i tried e.g. uci set network.@alias[-1].name=test can you please write down the commands in the right order? If you run uci without arguments, it'll print a command line help :) - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
* Felix Fietkau n...@openwrt.org [15.09.2013 19:50]: which commands should i use for naming the alias section? i tried e.g. uci set network.@alias[-1].name=test can you please write down the commands in the right order? If you run uci without arguments, it'll print a command line help :) really, it does not help here, otherwise i would'nt ask: maybe i misunderstand uci - IMHO the question is: how can i name an anonymous section? i want to give my 'alias' a name, e.g. 'myalias' and use this name as an reference for another construction (the route). is this the right way to do? i read the uci reference again and again, but i cannot find the answer. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
On 2013-09-15 7:55 PM, Bastian Bittorf wrote: * Felix Fietkau n...@openwrt.org [15.09.2013 19:50]: which commands should i use for naming the alias section? i tried e.g. uci set network.@alias[-1].name=test can you please write down the commands in the right order? If you run uci without arguments, it'll print a command line help :) really, it does not help here, otherwise i would'nt ask: maybe i misunderstand uci - IMHO the question is: how can i name an anonymous section? From the command line help: rename config.section[.option]=name - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
* Felix Fietkau n...@openwrt.org [15.09.2013 21:59]: maybe i misunderstand uci - IMHO the question is: how can i name an anonymous section? From the command line help: rename config.section[.option]=name 8-) ok, i could believe it - so one can NOT name a section, but must generate an unamed/anonymous section and afterwards rename this like: uci add network alias uci set network.@alias[-1].interface=lan ... uci set network.@route[-1].interface=agoodname uci add network route uci set network.@route[-1].interface=agoodname ... it's working and we send congratulations for breaking the barrier today with r38000++ of OpenWrt 8-) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] netifd: problem setting routes for alias-networks
On 2013-09-15 10:23 PM, Bastian Bittorf wrote: * Felix Fietkau n...@openwrt.org [15.09.2013 21:59]: maybe i misunderstand uci - IMHO the question is: how can i name an anonymous section? From the command line help: rename config.section[.option]=name 8-) ok, i could believe it - so one can NOT name a section, but must generate an unamed/anonymous section and afterwards rename this like: uci add network alias uci set network.@alias[-1].interface=lan ... uci set network.@route[-1].interface=agoodname uci add network route uci set network.@route[-1].interface=agoodname ... it's working and we send congratulations for breaking the barrier today with r38000++ of OpenWrt 8-) You can also do 'uci set network.agoodname=alias' - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] diag: Add WRT310N v1 gpio leds and buttons
Signed-off-by: Flavio Silveira f...@terra.com.br
---
package/kernel/broadcom-diag/src/diag.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/package/kernel/broadcom-diag/src/diag.c
b/package/kernel/broadcom-diag/src/diag.c
index 3f58718..a71731d 100644
--- a/package/kernel/broadcom-diag/src/diag.c
+++ b/package/kernel/broadcom-diag/src/diag.c
@@ -83,6 +83,7 @@ enum {
WRT160NV1,
WRT160NV3,
WRT300NV11,
+ WRT310NV1,
WRT350N,
WRT600N,
WRT600NV11,
@@ -379,6 +380,18 @@ static struct platform_t __initdata platforms[] = {
},
.platform_init = bcm57xx_init,
},
+ [WRT310NV1] = {
+ .name = Linksys WRT310N V1,
+ .buttons= {
+ { .name = reset, .gpio = 1 6 }, // Reset on
back panel
+ { .name = ses,.gpio = 1 8 }, // Reserved
on top panel
+ },
+ .leds = {
+ { .name = power, .gpio = 1 1, .polarity =
NORMAL }, // Power LED
+ { .name = ses_amber, .gpio = 1 3, .polarity =
REVERSE }, // Security Amber
+ { .name = ses_blue, .gpio = 1 9, .polarity =
REVERSE }, // Security Blue
+ },
+ },
[WRT350N] = {
.name = Linksys WRT350N,
.buttons= {
@@ -1382,6 +1395,8 @@ static struct platform_t __init *platform_detect(void)
return platforms[WRT160NV3];
case BCM47XX_BOARD_LINKSYS_WRT300NV11:
return platforms[WRT300NV11];
+ case BCM47XX_BOARD_LINKSYS_WRT310NV1:
+ return platforms[WRT310NV1];
case BCM47XX_BOARD_LINKSYS_WRT54G3GV2:
return platforms[WRT54G3GV2_VF];
case BCM47XX_BOARD_LINKSYS_WRT610NV1:
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why is everyone patching broadcom-wl-5.100.138
I thought that a number of routers could not use b43 and brcmsmac and had to use the actual broadcom-wl driver more or less as provided by broadcom. My email was only in reference the ones that run wl.ko like mine does(which is what it is using right now although on shibbytomato). In the wiki it is saying there are compatibility issues with the broadcom-wl drivers with a number of routers and it appeared to me that only one version of broadcom-wl(without patches) was actually available to be compiled for OpenWRT which was the reason for many problems. I was under the impression that the wl_ap.o wl_apsta.o and wl_sta.o binary's were not really kernel specific and only wl.ko is kernel specific, is that correct? On Sun, Sep 15, 2013 at 11:24 AM, Hauke Mehrtens ha...@hauke-m.de wrote: On 09/15/2013 05:40 PM, James Hilliard wrote: From what I'm seeing everyone is patching broadcom-wl around this(http://mirror2.openwrt.org/sources/broadcom-wl-5.100.138.tar.bz2) driver for the Netgear WNDR4500 for pretty much everything broadcom-wl related. That is wrong! broadcom-wl-5.100.138.tar.bz2 is just used to extract the ucode and use that ucode with b43 and brcmsmac. The proprietary Broadcom driver OpenWrt uses are these, the actual file depends on the endianes. http://mirror2.openwrt.org/sources/broadcom-wl-5.10.56.27.3_mips.tar.bz2 http://mirror2.openwrt.org/sources/broadcom-wl-5.10.56.27.3_mipsel.tar.bz2 To verify this see package/kernel/broadcom-wl/Makefile Like everyone already told you in IRC this driver is *not* based on the GPL release by some vendor, but this is a version specially modified for OpenWrt by someone with access to the source code of the proprietary wifi driver. Most of the patches we apply on top of this driver are there to make the open source part compile with more recent kernel versions, see package/kernel/broadcom-wl/patches/ What's the point of making a bunch of patches for this file when you could just use one of the many other broadcom-wl drivers that are actually designed for the target device already. The driver designed for this device do not work with the kernel OpenWrt uses, that is a big point in my opinion. I have attached broadcom-wl for the linksys/cisco e3000/wrt610nv2 which should support fully simultaneous dual-band N on both 2.4 and 5ghz channels. Please do not attaches such bug files. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kernel update to 3.10.12
On 09/15/2013 12:05 PM, Daniel Petre wrote: Hello, can we have 3.10.12 updated to OpenWrt trunk and patches refreshed please? We appreciate your interest in this. Feel free to send in patches. Regards mirko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
Hi Gabor, [resend, forgot mailing list in to list] In the early reference driver of the NAND controller, the data from the DMA has been swapped. On later reference drivers, this swapping has been removed. To match with the reference driver, the current ar934x-nfc driver does not swaps the data by default. If U-Boot on the WNDR4300 swaps the data then that can cause ECC errors in all NAND pages. If that is the problem, swapping must be enabled in the ar934x-nfc driver as well by an 'ath79_nfc_set_swap_dma(true)' call before ath79_register_nfc(). See the mach-rb2011.c file [1] for example. I enabled this swapping, but without luck. Still can't mount filesystems flashed using U-boot. I guess that Netgears driver somehow uses the EC header differently (is this done in software?) Currently, I need to boot initramfs to flash/create root filesystems. But this has also advantages, since I can use all those UBI utilities... UBI/squahsfs should be working, at least it has been tested by Free Electrons [2] on older kernels. In my opinion, it makes no sense to use JFFS2 on an UBI volume. That would complicate things with no good reason. For JFFS2, two immediate layers are needed in order to make it work on UBI volumes whereas UBIFS can work directly on that. Agree IMHO, the optimal solution would be the following: Add direct support to squashfs in order to be able to use that on top of plain UBI volumes. Create two UBI volumes and use squashfs on the first and UBIFS on the second volume. This would be much cleaner solution than the 'ubi-gluebi-mtdblock-squashfs' combination. I'm going to try squashfs on UBI. I see that Free Electrons refers with squashfs-ubiblk to that combination. As far as I can see, it should be easy as referring to the UBI volume as root device (e.g. /dev/ubiblk0_0). One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. Hm, but this would still change CRC, wouldn't it? The kernel command line is fixed in U-Boot, so we would have to generate an image with fixed (e.g. CONFIG_CMDLINE_OVERRIDE=y) cmdline. Any other idea? Is this the first Netgear target which encounters this problem? We are using the patch-cmdline tool to inject a board specific command line into the kernel for almost all boards [4]. Ok ic. As far as I see theres no root= configuration injected. Does the kernel has some hard coded defaults? -- Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [DATA][NO PATCH] bcm47xx: detect Linksys E1200 V2
Could you handle that Hauke?
[07:23] Lightsword boot_hw_model=E1200
[07:23] Lightsword boot_hw_ver=2.0
[07:25] Lightsword boardrev=0x1155
[07:25] Lightsword boardtype=0x058e
So it should sth like
{{BCM47XX_BOARD_LINKSYS_E1200V2, Linksys E1200 V2}, E1200, 2.0},
--
Rafał
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
