Re: [OpenWrt-Devel] [PATCH] base-files: uci-defaults Actually generate a working ipv6 configuration by default.
Jo-Philipp Wich j...@openwrt.org writes: NACK to this patch, comments below. -set network.lan.ip6assign='60' +set network.lan.ip6assign='64' Cosmetical change, not needed. If less than a /60 is available, it will use less. As far as I can tell the logic here is broken. What does it mean to assign something less more than a /64 to an interface? The standard interface assignment on a ipv6 interface is a /64. My assumption was this was a broken conversion from a wide-dhcp configuration. -set network.wan6='interface' -set network.wan6.ifname='@wan' +set network.wan6='alias' +set network.wan6.interface='wan' Those are exactly equivalent, in fact you're replacing the current alias notation with the deprecated one. No they aren't equivalent the alias syntax works. The new stuff does not. The solution may be to fix the new alias syntax but as of when I sent this patch the code simply did not work. openwrt choked on this configuration until I changed it away from the ``new'' syntax that doesn't work. +set network.wan6.reqprefix='60' That's probably the only actual required change, please retest with only this. Already tested, before I sent this patch. Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: uci-defaults Actually generate a working ipv6 configuration by default.
Steven Barth cy...@openwrt.org writes: NAK. The default configuration works well. The default configuration does not work at all because the @wan syntax does not work. So no the default configuration does not work at ALL. If it does not please try to tell use why. You can set the reqprefix value if you like and if it makes your ISP give you a better / bigger prefix. That is what is required by the DHCPv6 RFC if you have any preconceptions of how much you want. So if you are by default going to delegate a /60 you should have reqprefix set to at least a /60 by default. Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Developing own packages with CMake
On Thu, Sep 12, 2013 at 6:01 PM, Karl Palsson ka...@tweak.net.au wrote: On Thu, Sep 12, 2013 at 05:55:33PM +0200, Yegor Yefremov wrote: Hi, Another useful feature is The source directory override mechanism as described here: http://free-electrons.com/blog/buildroot-2011-11/ Is it planned to integrate such a feature? Just add the following line to your package makefile: include $(INCLUDE_DIR)/package-version-override.mk This will add menus in make menuconfig to set the source path (and also the version as the name implies) Thanks. It is working like a charm. YMMD! This feature should be documented in the wiki. Yegor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: uci-defaults Actually generate a working ipv6 configuration by default.
I'm sorry but the @wan syntax does indeed work. It works for me and many other people using the new IPv6 stack. Could it be that you are using an old version of netifd for some reason? (e.g. you updated / installed only some of the new IPv6 packages on top of the 12.09 release). If there is still something wrong after updating please file a bug in Trac including the versions of the relevant packages including your config information. Also neither the DHCPv6 RFC nor the DHCPv6-PD RFC state something that a hint must be included and how big it needs to be. RFC 6204 says that one MAY include a hint and if so it must be big enough to assign a /64 to every downstream interface and should be configurable to a greater value. However we do not include a hint by default. You can however provide one if you like. Also please note that ip6assign=60 means that the network daemon should assign a prefix of AT MOST /60 to the interface, if there is only a /62 or /64 available it will assign the maximum available length. So I really don't see a problem here. -Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ar71xx] add wireless bgn led support for dir-825-c1
Hello list,
I checked the GPL code drop from D-Link and tried to get the wireless
and LAN switch LEDs to light up. I found some references in
AthSDK/www/DIR-825_C1/bsp.h as well as
AthSDK/www/DIR-825_C1/rootfs/etc/sysconfig/S2gpio.sh, but in the end I
only got the led for 2.4GHz to work. Anyway, here's the patch.
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
diff -Nur
openwrt.orig/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
openwrt.new/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
--- openwrt.orig/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
2013-09-12 23:56:18.864876903 +0200
+++ openwrt.new/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c
2013-09-13 10:37:40.226421755 +0200
@@ -34,6 +34,7 @@
#define DIR825C1_GPIO_LED_BLUE_WPS 15
#define DIR825C1_GPIO_LED_ORANGE_PLANET19
#define DIR825C1_GPIO_LED_BLUE_PLANET 18
+#define DIR825C1_GPIO_LED_WIFI_BGN 13
#define DIR825C1_GPIO_BTN_RESET17
#define DIR825C1_GPIO_BTN_WPS 16
@@ -76,6 +77,10 @@
.name = d-link:blue:planet,
.gpio = DIR825C1_GPIO_LED_BLUE_PLANET,
.active_low = 1,
+ }, {
+ .name = d-link:blue:wifi_bgn,
+ .gpio = DIR825C1_GPIO_LED_WIFI_BGN,
+ .active_low = 1,
},
};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [v2][ar71xx] Add support for Netgear WNR2200 wireless router
On 01.09.2013 20:14, Gabor Juhos wrote:
Yes, it is necessary. The coding style of the mach-wnr2200.c file is horrible:
Additionally, a board specific patch is missing from
'target/linux/ar71xx/patches-3.10'.
Thanks,
Gabor
I didn't have time earlier but here is v2.
checkpatch warns about line length on 2 occasions but
I don't think that breaking that line is really necessary
I don't have a WNR2200 so I cannot test but it compiles.
Some gpio is from dd-wrt but i left that commented out
Changes:
- fixed comments
- fixed indentation
- WNR220_GPIO_USB_POWER - WNR2200_GPIO_USB_POWER
- add linux/gpio.h dependency
- comment out gpio stuff from dd-wrt for now
Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de
---
target/linux/ar71xx/base-files/etc/diag.sh | 3 +
.../ar71xx/base-files/etc/uci-defaults/02_network | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
target/linux/ar71xx/config-3.10| 1 +
.../ar71xx/files/arch/mips/ath79/mach-wnr2200.c| 172 +
target/linux/ar71xx/generic/profiles/netgear.mk| 11 ++
target/linux/ar71xx/image/Makefile | 2 +
.../624-MIPS-ath79-WNR2200-support.patch | 39 +
8 files changed, 232 insertions(+)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
create mode 100644
target/linux/ar71xx/patches-3.10/624-MIPS-ath79-WNR2200-support.patch
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 7b790e2..f3fdb0a 100755
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -175,6 +175,9 @@ get_status_led() {
wnr2000)
status_led=wnr2000:green:power
;;
+ wnr2200)
+ status_led=wnr2200:amber:power
+ ;;
wnr612-v2)
status_led=wnr612v2:green:power
;;
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 176c485..cf56e46 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -169,6 +169,7 @@ tl-wr941nd)
tl-mr3420-v2 |\
tl-wr841n-v8 |\
wnr2000-v3 |\
+wnr2200 |\
wnr612-v2)
ucidef_set_interfaces_lan_wan eth1 eth0
ucidef_add_switch switch0 1 1
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index e7fbfbe..b7dd4af 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -516,6 +516,9 @@ ar71xx_board_detect() {
*WNR2000)
name=wnr2000
;;
+ *WNR2200)
+ name=wnr2200
+ ;;
*WNR612 V2)
name=wnr612-v2
;;
diff --git a/target/linux/ar71xx/config-3.10 b/target/linux/ar71xx/config-3.10
index 6c75f14..ae1a481 100644
--- a/target/linux/ar71xx/config-3.10
+++ b/target/linux/ar71xx/config-3.10
@@ -90,6 +90,7 @@ CONFIG_ATH79_MACH_WNDR3700=y
CONFIG_ATH79_MACH_WNDR4300=y
CONFIG_ATH79_MACH_WNR2000=y
CONFIG_ATH79_MACH_WNR2000_V3=y
+CONFIG_ATH79_MACH_WNR2200=y
CONFIG_ATH79_MACH_WP543=y
CONFIG_ATH79_MACH_WPE72=y
CONFIG_ATH79_MACH_WRT160NL=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
new file mode 100644
index 000..42b484a
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wnr2200.c
@@ -0,0 +1,172 @@
+/*
+ * NETGEAR WNR2200 board support
+ *
+ * Copyright (C) 2013 Aidan Kissane aidankissane at googlemail.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/gpio.h
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+#include asm/mach-ath79/ath79.h
+
+#include dev-ap9x-pci.h
+#include dev-eth.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include dev-m25p80.h
+#include dev-usb.h
+#include machtypes.h
+
+/*#define WNR2200_GPIO_LED_LAN1_AMBER ?? */
+#define WNR2200_GPIO_LED_LAN2_AMBER0
+#define WNR2200_GPIO_LED_LAN4_AMBER1
+#define WNR2200_GPIO_LED_WPS 5
+#define WNR2200_GPIO_LED_WAN_GREEN 7
+#define WNR2200_GPIO_LED_USB 8
+#define WNR2200_GPIO_LED_LAN3_AMBER11
+#define WNR2200_GPIO_LED_WAN_AMBER 12
+#define WNR2200_GPIO_LED_LAN1_GREEN13
+#define WNR2200_GPIO_LED_LAN2_GREEN14
+#define WNR2200_GPIO_LED_LAN3_GREEN15
+#define WNR2200_GPIO_LED_LAN4_GREEN16
+#define WNR2200_GPIO_LED_PWR_AMBER 21
+#define WNR2200_GPIO_LED_PWR_GREEN 22
+
+#define WNR2200_GPIO_USB_POWER 24
+
+/*#define WNR2200_GPIO_BTN_RESET ?? */
+/*#define WNR2200_GPIO_BTN_WIRELESS35 from
[OpenWrt-Devel] [PATCH] [ar71xx] change MAC address behavior of dir-825-c1
Hello list,
The current behavior is that all interfaces (LAN, WAN and Wifi0) get the
first MAC address in the mac mtd assigned (Wifi1 gets the MAC address of
the second MAC address plus 1).
Unfortunately the MAC address printed on the sticker on the bottom of
the router (the second MAC address in the mac mtd) is not used at all.
But for some use cases it appears to be vital that the printed MAC gets
assigned.
For testing I installed D-Link's firmware 304b01 (latest). It handles
MAC assignments the same way as OpenWrt does, except it assigns the
printed MAC to the WAN interface.
So I tried to come up with a way to do the same in OpenWrt. As the WAN
interface is a virtual interface there's no way to do this while loading
the driver. For the same reason I couldn't use the existing code in
lib/preinit, i.e. 05_set_iface_mac_ar71xx.
So I ended up with the following patch. Please consider it/tell me what
you think. Thanks!
Signed-off-by: Sebastian Kemper sebastian...@gmx.net
diff -Nur
openwrt.orig/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
openwrt.new/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
--- openwrt.orig/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
2013-09-12 23:54:58.491543186 +0200
+++ openwrt.new/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
2013-09-13 00:04:46.284856230 +0200
@@ -5,6 +5,18 @@
[ -e /etc/config/network ] exit 0
+fetch_wan_mac_from_mtd() {
+ local mtd_part=$1
+ local wan_env=$2
+ local mtd mac
+
+ mtd=$(grep $mtd_part /proc/mtd | cut -d: -f1)
+ [ -z $mtd ] return
+
+ mac=$(grep -m 1 $wan_env /dev/$mtd | cut -d= -f2)
+ [ ! -z $mac ] ucidef_set_interface_macaddr wan $mac
+}
+
touch /etc/config/network
. /lib/functions/uci-defaults.sh
@@ -193,7 +205,14 @@
ucidef_add_switch_vlan switch0 1 0 1 2 3 5t
;;
-dir-825-c1 |\
+dir-825-c1)
+ ucidef_set_interfaces_lan_wan eth0.1 eth0.2
+ fetch_wan_mac_from_mtd nvram wan_mac
+ ucidef_add_switch switch0 1 1
+ ucidef_add_switch_vlan switch0 1 0t 1 2 3 4
+ ucidef_add_switch_vlan switch0 2 0t 5
+ ;;
+
dir-835-a1 |\
wndr4300)
ucidef_set_interfaces_lan_wan eth0.1 eth0.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ping6: sendto: Operation not permitted
root@OpenWrt:/# ping6 www.google.de PING www.google.de (2a00:1450:4013:c00::5e): 56 data bytes ping6: sendto: Operation not permitted WTF, was soll der Mist und wie schalte ich das aus? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] change MAC address behavior of dir-825-c1
On 13.09.2013 12:57, Sebastian Kemper wrote: Hello list, The current behavior is that all interfaces (LAN, WAN and Wifi0) get the first MAC address in the mac mtd assigned (Wifi1 gets the MAC address of the second MAC address plus 1). Unfortunately the MAC address printed on the sticker on the bottom of the router (the second MAC address in the mac mtd) is not used at all. But for some use cases it appears to be vital that the printed MAC gets assigned. For testing I installed D-Link's firmware 304b01 (latest). It handles MAC assignments the same way as OpenWrt does, except it assigns the printed MAC to the WAN interface. So I tried to come up with a way to do the same in OpenWrt. As the WAN interface is a virtual interface there's no way to do this while loading the driver. For the same reason I couldn't use the existing code in lib/preinit, i.e. 05_set_iface_mac_ar71xx. What about changing something in file: mach-dir-825-c1.c ath79_init_mac(wmac1, mac1, 1); shouldn't that be the second MAC +1 - you can change that maybe? Is ath79_eth0_data / ath79_eth1_data used in another machine .c : ath79_init_mac(ath79_eth1_data.mac_addr, art+WNR2000V3_MAC1_OFFSET, 0); Maybe thats WAN on switch? 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] ping6: sendto: Operation not permitted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/13/2013 01:41 PM, Alina Friedrichsen wrote: root@OpenWrt:/# ping6 www.google.de PING www.google.de (2a00:1450:4013:c00::5e): 56 data bytes ping6: sendto: Operation not permitted WTF, was soll der Mist und wie schalte ich das aus? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel This is an english speaking mailing list. Your question is also not related to OpenWrt development. Please try the forum or OpenWrt-Users list. thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJSMvmQAAoJECHrh56PP4wptKcH/AxTNTZH4m/JAOxofrPjpeXz u0AoZVeZSK8JdU2CWgsMoABcDuBaxKPELUT1a1Wo9xTaTrjgj6GUT2RnQFfd9E0T LRVJiSY3EKzRswm3rFfmOcbB5/iZm4MEKj7tRYsIu1XGpz3n0wzkN/5BsGhR6PIN v5BkNwWIRbXLV1a65b1Im+IIv6b4Cygyud0hT72PF/7qMzna6RDRWHbfb7kun0hJ 6KJ4wKjCRlKFr3HoqokXH4eyuDw7+X2Go7hotK89Q2jj11VJkjAp63vx4ZhfNW5y e2BECr0G+msSpydGFv2ddCfw19BAmFaRm69ylx6shgS+6KcJwXLX80qQRtDYe+k= =UaH2 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
root@OpenWrt:/# ping6 www.google.de PING www.google.de (2a00:1450:4013:c00::5e): 56 data bytes ping6: sendto: Operation not permitted WTF, was soll der Mist und wie schalte ich das aus? I found the bug. Your PPPoE stuff don't set a IPv6 default route. Alina ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
On 13.09.2013 13:41, Alina Friedrichsen wrote: root@OpenWrt:/# ping6 www.google.de PING www.google.de (2a00:1450:4013:c00::5e): 56 data bytes ping6: sendto: Operation not permitted WTF, was soll der Mist und wie schalte ich das aus? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Diese Mailingliste benutzt die englische Sprache. Ich hatte den Fehler, da war es ein Fehler im Buildsystem. siehe die beiden Tickets: https://dev.openwrt.org/ticket/13879 https://dev.openwrt.org/ticket/13540 fixed in r37402 PS: Müsste es nicht WZF sein ? ;) English Translation: and how can I disable that? I did get that error at one point It was build-system related see the tickets and it was fixed in r37402 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] ping6: sendto: Operation not permitted
https://dev.openwrt.org/ticket/2372 It isn't closed. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
it was fixed in r37402 I use the trunk from yesterday. It isn't fixed. Alina ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
P.S.: You need a /etc/rc.local. Writing the stuff in /etc/firewall.user ist quick and dirty. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
On 2013-09-13 2:02 PM, Alina Friedrichsen wrote: https://dev.openwrt.org/ticket/2372 It isn't closed. Why are you posting a link to a 6 (!) year old closed ticket and claim that it isn't closed? If you're ever interested in sending emails that stand a chance of generating helpful responses without annoying people, please read http://www.catb.org/esr/faqs/smart-questions.html carefully and then spend some more time thinking about it. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
WTF, was soll der Mist und wie schalte ich das aus? What about providing some details? X does not work. WTF does not exactly make me want to answer your question. Whats the current configuration? Whats the output if ifstatus wan or whatever name your IPv6 PPPoE enabled ifaces uses. Also note that IPCP6 alone is not responsible for negotatiating default routes, for that you need to handle RAs on top of the PPPoE iface, using odhcp6c. Is it present in your image? Usually a wan6 alias is declared by default which takes care of doing the RA negotation after the underlying protocol completes. ~ Jow signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
This isn't the right place for it: /etc/firewall.user: (while true; do ip -6 route add default dev pppoe-wan; sleep 60; done) /dev/null 21 This is the right place (on Debian) for it: /etc/ppp/ipv6-up.d/defaultroute: ip -6 route add default via $PPP_REMOTE dev $PPP_IFACE ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
/etc/firewall.user: (while true; do ip -6 route add default dev pppoe-wan; sleep 60; done) /dev/null 21 This is the right place (on Debian) for it: /etc/ppp/ipv6-up.d/defaultroute: ip -6 route add default via $PPP_REMOTE dev $PPP_IFACE This is just an ugly hack. The proper way would be to rely on and deal with router advertisements sent via the established PPPoE link. ~ Jow signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
http://wiki.openwrt.org/doc/uci/network6#native.ipv6.connection ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ping6: sendto: Operation not permitted
Hi Jow! This is just an ugly hack. The proper way would be to rely on and deal with router advertisements sent via the established PPPoE link. My provider (Titan-DSL) do not send any Router Advertisements, DHCPv6 or such stuff. It only negotiate the link-local address and sends it's own IP on the remote side over PPPoE. Bye Alina ___ 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 Stefan, In between I found out that the driver works fine if I erase/write the NAND first using the driver itself. But when I try to flash something using the stock U-Boot bootloader, the driver still complains as outlined in my first message. Right now I have a running kernel and root filesystem generated using git master. I generated these files by altering the ar71xx generic subtarget (included UBIFS, NAND driver etc.) I then flashed the kernel using stock U-Boot. To flash the root fs I used the already working initramfs and generated the UBI volume by hand, then used ubiupdatevol to write the generated *.ubifs image. Due to manual flashing, the default boot commands don't work since magics and CRCs are wrong. Beside that, there is no overlay right now, I have a read/writeable root fs. My goal is to generate a easily flashable (TFTP recovery or whatever) image for this router. Since I'm new to OpenWRT development I might be wrong with all this, so please help me/correct me... When the image is written by U-Boot, the rootfs won't be readable by the ar934x kernel driver (my initial problem). Any idea how to work around this? 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. If this does not help, then I have no idea what causes the read failures. As far as I can see, there is only xburst which _use_ UBIFS right now. The ar71xx/nand target use YAFFS2 (at least this is what the kernel has included). The question is, should I include UBIFS to the NAND subtarget and transfer this device to this subtarget? Or should I create a new target (so there would be three generic = squashfs/jffs2, nand = YAFFS2, ubi = ubi/ubifs). The nand subtarget is mainly for Mikrotik devices. Those needs yaffs2 support in order to keep it compatible with RouterBOOT. The yaffs2 fs will not be used for other boards so a separate subtarget would be better. Which is the NAND fs combination for OpenWRT in future anyway? I see following combinations (rootfs/rootfs_data): - UBI/squashfs, UBI/JFFS2 (using gluebi, stacking of FS, are these tested and working combinations? Too complicated?) 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. - UBI/UBIFS(ro), UBI/UBIFS (I read that UBIFS doesnt allow to be a overlayfs since it lacks whiteout feature.. Is this true?) It is true for ubifs in mainline linux kernels. Overlayfs relies on symlink xattr support which is not present in mailine yet. We have a experimental patch for that in OpenWrt (see 550-ubifs-symlink-xattr-support.patch in target/linux/generic/patches-*). A more complete patchset has been posted to the linux-mtd list a few months ago [3], but i don't know the actual status of those patches. Additionally, there is a minor problem using UBIFS for the read only part. The resulting ubifs image is much larger than a corresponding squashfs image even if xz compression is used in ubifs. It is not a big problem because NAND flashes are usually larger than the generally used 4/8/16MB NOR flashes but it simply wastes space. 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. 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. 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]. Or maybe go straight forward and just wipe the whole device, flash a U-Boot without integrity checks, use the whole NAND... (would be a one way thing... is there a solution where user can do this without opening the device..) I don't want
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for TL-MR3040 v2 (correction)
2013.09.12. 23:17 keltezéssel, Mads Hansen írta: Changed two instances of TL-MR3040 to TL-MR3040-v1 and TL-MR3040-v2, respectively. The kernel uses the 'TL-MR3040' string to identify the board. I bet on that the resulting image won't work with this change. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] add wireless bgn led support for dir-825-c1
2013.09.13. 12:33 keltezéssel, Sebastian Kemper írta: Hello list, I checked the GPL code drop from D-Link and tried to get the wireless and LAN switch LEDs to light up. I found some references in AthSDK/www/DIR-825_C1/bsp.h as well as AthSDK/www/DIR-825_C1/rootfs/etc/sysconfig/S2gpio.sh, but in the end I only got the led for 2.4GHz to work. Anyway, here's the patch. Signed-off-by: Sebastian Kemper sebastian...@gmx.net Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for TL-MR3040 v2
2013.09.12. 15:03 keltezéssel, Mads Hansen írta: This patch adds support for building firmware images for the TP-Link TL-MR3040 v2. Tested and working on v2.1 hardware. Signed-off-by: Mads Hansen d...@taba.se Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 001/001] [brcm47xx] board detection, GPIO for Linksys E1000 V2.1
On 09/09/2013 07:18 PM, Zachary Catlin wrote: From: Zachary Catlin zcat...@indiana.edu This patch adds board detection for the Linksys E1000 V2.1 router, as well as GPIO support for same. Signed-off-by: Zachary Catlin zcat...@indiana.edu --- NOTE: This is identical to the patch I sent earlier today (local time), but the first time around my mail client messed up spaces in the diff. Trying again with a different client. This fixes bug #14135. Currently, wired networking isn't working on the router, and I haven't tried the wireless, but with this patch, OpenWRT successfully boots, and all the LEDs and buttons work properly. Thank you for the patch, it was committed in r37977. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ser2net: bump to 2.9.1
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com --- net/ser2net/Makefile |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ser2net/Makefile b/net/ser2net/Makefile index 2782972..c67e08f 100644 --- a/net/ser2net/Makefile +++ b/net/ser2net/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=ser2net -PKG_VERSION:=2.8 +PKG_VERSION:=2.9.1 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=@SF/ser2net -PKG_MD5SUM:=1cffbdaad221f19dcf82681472f7f947 +PKG_MD5SUM:=80011ac0e60bbdcb65f1d7a86251e3f3 PKG_FIXUP:=autoreconf PKG_INSTALL:=1 -- 1.7.7 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
