Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: sysupgrade for My Net Wi-Fi Range Extender
Hello Gabor,
On Friday 29 November 2013 22:03:01 Gabor Juhos wrote:
> Sorry for the delay.
I was about to hit [RESEND] ;-).
>
> > This patch enables the convenient sysupgrade feature for
> > WD's Wi-Fi Range Extender.
> >
> > The procedure is pretty much SOP. However, there is one
> > small trick to it: The customized u-boot loader verifies
> > the image's CRC32 against a reference each time the
> > device boots. Now, In case of a jffs2-root filesystem
> > the reference checksum would have to be updated every
> > time something on the fs changes... Obviously, this
> > wouldn't be very practial.
> >
> > Luckily, the bootloader check can be defeated by modifying
> > the TRX header after the flash.
> >
> > Signed-off-by: Christian Lamparter
> > ---
> > It seems the wrt160nl suffers from a similar issue. At least
> > there's an open ticket #8960 https://dev.openwrt.org/ticket/8960.
> >
> > As far as I can tell, the current sysupgrade code already tries
> > to fix the TRX header (even on my Archer C7?!) but it fails:
> >
> > Writing from to firmware ...
> > Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...
> > TRX header not found Error fixing up TRX header.
> >
> > This is because the current sysupgrade code doesn't know that
> > the TRX header has a offset (32 bytes from the beginning).
> > ---
> > .../ar71xx/base-files/lib/upgrade/mynet-rext.sh| 26
> > ++
> > .../ar71xx/base-files/lib/upgrade/platform.sh | 6 +
> > target/linux/ar71xx/image/Makefile | 3 +++
> > 3 files changed, 35 insertions(+)
> > create mode 100644 target/linux/ar71xx/base-files/lib/upgrade/mynet-rext.sh
> >
> > diff --git a/target/linux/ar71xx/base-files/lib/upgrade/mynet-rext.sh
> > b/target/linux/ar71xx/base-files/lib/upgrade/mynet-rext.sh
> > new file mode 100644
> > index 000..ea4eddd
> > --- /dev/null
> > +++ b/target/linux/ar71xx/base-files/lib/upgrade/mynet-rext.sh
> > @@ -0,0 +1,26 @@
> > +#!/bin/sh
> > +
> > +. /lib/functions.sh
> > +. /lib/ar71xx.sh
> > +
> > +get_image_magic() {
> > + local mtddev=$1
> > + dd bs=8 count=1 skip=0 if=$mtddev 2>/dev/null | hexdump -v -n 8 -e '1/1
> > "%02x"'
> > +}
>
> This function is not used anywhere.
Uh, that's right! (this needs to be fixes)
AFICT, there are apparently two incompatible devices WD devices.
Both start with the same 4-Byte "WDHN" magic. However after
that, things get complicated.
1. the Starfish Platform (this is my range extender) uses STFH
(the full magic is WDHNSTFH).
2. the Seahorse Platform uses SHRS (WDHNSHRS).
This is why for wd hardware we need to check all 8 bytes.
> > +
> > +mynet_rext_check_image() {
>
> The function can be used for the wrt160nl as well. It would be better to
> rename
> it to cybertan_check_image or something similar.
Thanks! [Don't forget to close the WRT160NL ticket ;-)]
> > + local magic="$(get_magic_long "$1")"
> > + local fw_magic=$(get_magic_long "`find_mtd_part \"firmware\"`")
> > +
> > + [ "$fw_magic" != "$magic" ] && {
> > + echo "Invalid image, ID mismatch, got:$magic, but
> > need:$fw_magic"
> > + return 1
> > + }
> > +
> > + return 0;
> > +}
>
> > +
> > +platform_do_upgrade_mynet_rext() {
> > + default_do_upgrade "$ARGV"
> > + mtd -o 32 fixtrx firmware
> > +}
>
> Although this works, but it causes an extra erase of the first block of the
> firmware partition. We should patch the sysupgrade file on the host while
> we are building that and we should skip this extra step.
>
> Can you try the attached patches instead please?
Didn't work. tried it twice, but sysupgrade bricked the device
(uboot complains about: Bad CRC).
However, it should be fixed now(tm).
I've attached my patches (add/merge them to your series):
0001-ar71xx-sysupgrade-for-My-Net-Wi-Fi-Range-Extender:
This is an update version of your 0003. Now, the script
really checks if all 8 byte matches.
[This replaces your 0003-ar71xx-sysupgrade...]
0002-firmware-utils-trx-fix-two-bugs: This fixes two bugs
in trx.c (The CRC32 wasn't calculated correctly if -F was
enabled).
0003-ar71xx-remove-trx-fixup: The preinit fixup is no longer
needed. We can delete the files and make the initial images
smaller.
Regards,
Christian>From fed5c7692f66f0f9ad49f9e2f4c1534eec541395 Mon Sep 17 00:00:00 2001
From: Gabor Juhos
Date: Fri, 29 Nov 2013 21:59:48 +0100
Subject: [PATCH 1/3] ar71xx: sysupgrade for My Net Wi-Fi Range Extender
This patch enables the convenient sysupgrade feature for
WD's Wi-Fi Range Extender.
Signed-off-by: Christian Lamparter
Patchwork: http://patchwork.openwrt.org/patch/4341/
[juhosg:
- rename 'mynet_rext_check_image' function to 'cybertan_check_image'
and move that into platform.sh,
- remove the the model specific 'platform_do_upgrade_mynet_rext' function,
- drop the mynet-rext.sh script,
- remove the image/Makefile change,
- update commit message]
[christian:
- check all 8 bytes of the firmware/device magic]
Signe
[OpenWrt-Devel] [PATCH] [ramips] Fix dts typos
Signed-off-by: Roman Yeryomin
---
target/linux/ramips/dts/WCR150GN.dts | 2 +-
target/linux/ramips/dts/rt3050.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/ramips/dts/WCR150GN.dts
b/target/linux/ramips/dts/WCR150GN.dts
index e59fc8d..976754e 100644
--- a/target/linux/ramips/dts/WCR150GN.dts
+++ b/target/linux/ramips/dts/WCR150GN.dts
@@ -3,7 +3,7 @@
/include/ "rt3050.dtsi"
/ {
- compatible = "WCR150GN", "ralink,rt3052-soc";
+ compatible = "WCR150GN", "ralink,rt3050-soc";
model = "Sparklan WCR-150GN";
pinctrl {
diff --git a/target/linux/ramips/dts/rt3050.dtsi
b/target/linux/ramips/dts/rt3050.dtsi
index 9f29aa0..dfce920 100644
--- a/target/linux/ramips/dts/rt3050.dtsi
+++ b/target/linux/ramips/dts/rt3050.dtsi
@@ -1,7 +1,7 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "ralink,rt3050-soc", "ralink,rt3050-soc",
"ralink,rt3350-soc";
+ compatible = "ralink,rt3050-soc", "ralink,rt3052-soc",
"ralink,rt3350-soc";
cpus {
cpu@0 {
--
1.8.3.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ramips] Fix initial network configuration for few boards
Argus ATP52B: ethernet didn't work because of unconfigured switch Sparklan WCR150GN: add switch config and make single port to be LAN Dlink DIR-645: seems to be a redundant case Signed-off-by: Roman Yeryomin --- .../linux/ramips/base-files/etc/uci-defaults/02_network | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/target/linux/ramips/base-files/etc/uci-defaults/02_network b/target/linux/ramips/base-files/etc/uci-defaults/02_network index 79ad4b8..63458ed 100755 --- a/target/linux/ramips/base-files/etc/uci-defaults/02_network +++ b/target/linux/ramips/base-files/etc/uci-defaults/02_network @@ -56,7 +56,6 @@ ramips_setup_interfaces() ;; 3g-6200n | \ - argus-atp52b | \ b2c | \ nw718 | \ psr-680w | \ @@ -72,13 +71,6 @@ ramips_setup_interfaces() ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 6t" ;; - dir-645) - ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" - ucidef_add_switch "switch0" "1" "1" - ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 6t" - ucidef_add_switch_vlan "switch0" "2" "0 6t" - ;; - dir-610-a1 | \ dir-300-b7 | \ dir-320-b1 | \ @@ -90,6 +82,8 @@ ramips_setup_interfaces() ucidef_add_switch_vlan "switch0" "2" "4 6t" ;; + argus-atp52b | \ + dir-645 | \ f5d8235-v1 | \ f5d8235-v2 | \ hg255d | \ @@ -136,7 +130,10 @@ ramips_setup_interfaces() ;; wcr-150gn) - ucidef_set_interfaces_lan_wan "eth0.2" "eth0.1" + ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" + ucidef_add_switch "switch0" "1" "1" + ucidef_add_switch_vlan "switch0" "1" "0 6t" + ucidef_add_switch_vlan "switch0" "2" "6t" ;; d105 | \ -- 1.8.3.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH: kernel][CONFIG: kernel] OpenWRT for Raspberry PI
From previous, it didn't work just that perfectly, in the kernel config file CONFIG_LOCALVERSION must be set to "" and in target/brcm2708/Makefile kernel version should be 3.12.1 - config file still should be config-3.12 Signed-off-by: Oskari Rauta ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][1/2] update Userspace support for the WA850/WA750
Once again this patch complains that it is corrupt, but for some reason the last line of the mbox file is missing. That seemed also be the case with other patches as well. this command does do the trick however, sed in this case only adds a newline to the end of the file when it is missing. wget http://patchwork.openwrt.org/patch/4487/mbox/ -O - | sed '$a\' | git am -s Maybe it is worth looking into, or maybe tell me what I do wrong? because the other patch was submitted the same way and it doesn't have issues. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][1/2] update Userspace support for the WA850/WA750
Signed-off-by: Martijn Zilverschoon 2013/11/29 Martijn Zilverschoon : > Sorry my mistake > > Signed-off-by: Martijn Zilverschoon diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index 95b30c1..5a8173f 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -180,11 +180,23 @@ tl-mr3420-v2) tl-wa750re) ucidef_set_led_netdev "lan" "LAN" "tp-link:orange:lan" "eth0" ucidef_set_led_wlan "wlan" "WLAN" "tp-link:orange:wlan" "phy0tpt" + ucidef_set_rssimon "wlan0" "4" "1" + ucidef_set_led_rssi "rssilow" "RSSILOW" "tp-link:orange:signal1" "wlan0" "1" "100" "0" "13" + ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMHIGH" "tp-link:orange:signal2" "wlan0" "20" "100" "-19" "13" + ucidef_set_led_rssi "rssimedium" "RSSIMEDIUM" "tp-link:orange:signal3" "wlan0" "40" "100" "-39" "13" + ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "tp-link:orange:signal4" "wlan0" "60" "100" "-59" "13" + ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "tp-link:orange:signal5" "wlan0" "80" "100" "-79" "13" ;; tl-wa850re) ucidef_set_led_netdev "lan" "LAN" "tp-link:blue:lan" "eth0" ucidef_set_led_wlan "wlan" "WLAN" "tp-link:blue:wlan" "phy0tpt" + ucidef_set_rssimon "wlan0" "4" "1" + ucidef_set_led_rssi "rssilow" "RSSILOW" "tp-link:blue:signal1" "wlan0" "1" "100" "0" "13" + ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMHIGH" "tp-link:blue:signal2" "wlan0" "20" "100" "-19" "13" + ucidef_set_led_rssi "rssimedium" "RSSIMEDIUM" "tp-link:blue:signal3" "wlan0" "40" "100" "-39" "13" + ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "tp-link:blue:signal4" "wlan0" "60" "100" "-59" "13" + ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "tp-link:blue:signal5" "wlan0" "80" "100" "-79" "13" ;; tl-wa901nd) ___ 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] AR71xx: Update profile for the wa750/wa850 to include rssileds by default
Signed-off-by: Martijn Zilverschoon diff --git a/target/linux/ar71xx/generic/profiles/tp-link.mk b/target/linux/ar71xx/generic/profiles/tp-link.mk index 5236f7f..5138c0c 100644 --- a/target/linux/ar71xx/generic/profiles/tp-link.mk +++ b/target/linux/ar71xx/generic/profiles/tp-link.mk @@ -142,7 +142,7 @@ $(eval $(call Profile,TLWA701)) define Profile/TLWA750 NAME:=TP-LINK TL-WA750RE - PACKAGES:= + PACKAGES:=rssileds endef define Profile/TLWA750/Description @@ -184,7 +184,7 @@ $(eval $(call Profile,TLWA830)) define Profile/TLWA850 NAME:=TP-LINK TL-WA850RE - PACKAGES:= + PACKAGES:=rssileds endef define Profile/TLWA850/Description ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][1/2] update Userspace support for the WA850/WA750
Sorry my mistake Signed-off-by: Martijn Zilverschoon diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index 95b30c1..5a8173f 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -180,11 +180,23 @@ tl-mr3420-v2) tl-wa750re) ucidef_set_led_netdev "lan" "LAN" "tp-link:orange:lan" "eth0" ucidef_set_led_wlan "wlan" "WLAN" "tp-link:orange:wlan" "phy0tpt" + ucidef_set_rssimon "wlan0" "4" "1" + ucidef_set_led_rssi "rssilow" "RSSILOW" "tp-link:orange:signal1" "wlan0" "1" "100" "0" "13" + ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMHIGH" "tp-link:orange:signal2" "wlan0" "20" "100" "-19" "13" + ucidef_set_led_rssi "rssimedium" "RSSIMEDIUM" "tp-link:orange:signal3" "wlan0" "40" "100" "-39" "13" + ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "tp-link:orange:signal4" "wlan0" "60" "100" "-59" "13" + ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "tp-link:orange:signal5" "wlan0" "80" "100" "-79" "13" ;; tl-wa850re) ucidef_set_led_netdev "lan" "LAN" "tp-link:blue:lan" "eth0" ucidef_set_led_wlan "wlan" "WLAN" "tp-link:blue:wlan" "phy0tpt" + ucidef_set_rssimon "wlan0" "4" "1" + ucidef_set_led_rssi "rssilow" "RSSILOW" "tp-link:blue:signal1" "wlan0" "1" "100" "0" "13" + ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMHIGH" "tp-link:blue:signal2" "wlan0" "20" "100" "-19" "13" + ucidef_set_led_rssi "rssimedium" "RSSIMEDIUM" "tp-link:blue:signal3" "wlan0" "40" "100" "-39" "13" + ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "tp-link:blue:signal4" "wlan0" "60" "100" "-59" "13" + ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "tp-link:blue:signal5" "wlan0" "80" "100" "-79" "13" ;; tl-wa901nd) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: sysupgrade for My Net Wi-Fi Range Extender
Hi Christian,
Sorry for the delay.
> This patch enables the convenient sysupgrade feature for
> WD's Wi-Fi Range Extender.
>
> The procedure is pretty much SOP. However, there is one
> small trick to it: The customized u-boot loader verifies
> the image's CRC32 against a reference each time the
> device boots. Now, In case of a jffs2-root filesystem
> the reference checksum would have to be updated every
> time something on the fs changes... Obviously, this
> wouldn't be very practial.
>
> Luckily, the bootloader check can be defeated by modifying
> the TRX header after the flash.
>
> Signed-off-by: Christian Lamparter
> ---
> It seems the wrt160nl suffers from a similar issue. At least
> there's an open ticket #8960 https://dev.openwrt.org/ticket/8960.
>
> As far as I can tell, the current sysupgrade code already tries
> to fix the TRX header (even on my Archer C7?!) but it fails:
>
> Writing from to firmware ...
> Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...
> TRX header not found Error fixing up TRX header.
>
> This is because the current sysupgrade code doesn't know that
> the TRX header has a offset (32 bytes from the beginning).
> ---
> .../ar71xx/base-files/lib/upgrade/mynet-rext.sh| 26
> ++
> .../ar71xx/base-files/lib/upgrade/platform.sh | 6 +
> target/linux/ar71xx/image/Makefile | 3 +++
> 3 files changed, 35 insertions(+)
> create mode 100644 target/linux/ar71xx/base-files/lib/upgrade/mynet-rext.sh
>
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/mynet-rext.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/mynet-rext.sh
> new file mode 100644
> index 000..ea4eddd
> --- /dev/null
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/mynet-rext.sh
> @@ -0,0 +1,26 @@
> +#!/bin/sh
> +
> +. /lib/functions.sh
> +. /lib/ar71xx.sh
> +
> +get_image_magic() {
> + local mtddev=$1
> + dd bs=8 count=1 skip=0 if=$mtddev 2>/dev/null | hexdump -v -n 8 -e '1/1
> "%02x"'
> +}
This function is not used anywhere.
> +
> +mynet_rext_check_image() {
The function can be used for the wrt160nl as well. It would be better to rename
it to cybertan_check_image or something similar.
> + local magic="$(get_magic_long "$1")"
> + local fw_magic=$(get_magic_long "`find_mtd_part \"firmware\"`")
> +
> + [ "$fw_magic" != "$magic" ] && {
> + echo "Invalid image, ID mismatch, got:$magic, but
> need:$fw_magic"
> + return 1
> + }
> +
> + return 0;
> +}
> +
> +platform_do_upgrade_mynet_rext() {
> + default_do_upgrade "$ARGV"
> + mtd -o 32 fixtrx firmware
> +}
Although this works, but it causes an extra erase of the first block of the
firmware partition. We should patch the sysupgrade file on the host while we are
building that and we should skip this extra step.
Can you try the attached patches instead please?
-Gabor
>From 72607d9a08f2cbc69e5bee31415a583f201e761d Mon Sep 17 00:00:00 2001
From: Gabor Juhos
Date: Fri, 29 Nov 2013 21:59:48 +0100
Subject: [PATCH 1/3] ar71xx: image: fix CyberTAN sysupgrade images
In the current sysupgrade images, the CRC32 value of
the TRX header covers the whole rootfs data. Due to
this, the CRC value should be changed during sysupgrade
otherwise the bootloader refuses to load the image on
the next boot.
Change the image generation to create sysupgrade images
where the CRC32 value covers the kernel data only. This
allows to skip the 'fixtrx' step during sysupgrade on
the target.
Signed-off-by: Gabor Juhos
---
target/linux/ar71xx/image/Makefile |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile
index 8511bba..dee4407 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -668,11 +668,15 @@ Image/Build/CyberTAN/loader=$(call Image/BuildLoader,$(1),gz,$(2),0x8006)
Image/Build/CyberTAN/buildkernel=$(call MkuImage,gzip,,$(KDIR)/loader-$(2).gz,$(KDIR_TMP)/vmlinux-$(2).uImage)
define Image/Build/CyberTAN
- $(STAGING_DIR_HOST)/bin/trx -o $(KDIR)/image.tmp -f $(KDIR_TMP)/vmlinux-$(2).uImage \
+ echo -n '' > $(KDIR_TMP)/empty.bin
+ $(STAGING_DIR_HOST)/bin/trx -o $(KDIR)/image.tmp \
+ -f $(KDIR_TMP)/vmlinux-$(2).uImage -F $(KDIR_TMP)/empty.bin \
-x 32 -a 0x1 -x -32 -f $(KDIR)/root.$(1)
-$(STAGING_DIR_HOST)/bin/addpattern -B $(2) -v v$(4) \
-i $(KDIR)/image.tmp \
-o $(call sysupname,$(1),$(2))
+ $(STAGING_DIR_HOST)/bin/trx -o $(KDIR)/image.tmp -f $(KDIR_TMP)/vmlinux-$(2).uImage \
+ -x 32 -a 0x1 -x -32 -f $(KDIR)/root.$(1)
-$(STAGING_DIR_HOST)/bin/addpattern -B $(2) -v v$(4) -g \
-i $(KDIR)/image.tmp \
-o $(call factoryname,$(1),$(2))
--
1.7.10
>From efbc511ab532c3ade0b4a33cce830e3ce567e4e3 Mon Sep 17 00:00:00 2001
From: Gabor Juhos
Date: Fri, 29 Nov 2013 21:59:48 +0100
Subject: [PATCH 2/3] ar71xx: image: unify CyberTAN macros
Make the Image/Build/CyberTAN macro more generic,
and
Re: [OpenWrt-Devel] [PATCH][2/2] AR71xx: Update profile for the wa750/wa850 to include rssileds by default
The patch is corrupt: > $ wget http://patchwork.openwrt.org/patch/4479/mbox/ -O - | git am -s > --2013-11-29 21:34:09-- http://patchwork.openwrt.org/patch/4479/mbox/ > Resolving patchwork.openwrt.org (patchwork.openwrt.org)... 188.40.166.11 > Connecting to patchwork.openwrt.org > (patchwork.openwrt.org)|188.40.166.11|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: unspecified [text/plain] > Saving to: `STDOUT' > > [ <=> > ] 1,184 --.-K/s in 0.001s > > 2013-11-29 21:34:09 (826 KB/s) - written to stdout [1184] > > Applying: AR71xx: Update profile for the wa750/wa850 to include rssileds by > default > fatal: corrupt patch at line 22 > Patch failed at 0001 AR71xx: Update profile for the wa750/wa850 to include > rssileds by default Also a Signed-off-by line is missing. Please fix it. 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][1/2] update Userspace support for the WA850/WA750
2013.11.29. 10:21 keltezéssel, Martijn Zilverschoon írta: > Patch for adding the default uci values of the rssileds application > for the tp-link -tl-wa850re and the tl-wa750re for the > The patch is corrupt: > $ wget http://patchwork.openwrt.org/patch/4478/mbox/ -O - | git am -s > --2013-11-29 21:29:57-- http://patchwork.openwrt.org/patch/4478/mbox/ > Resolving patchwork.openwrt.org (patchwork.openwrt.org)... 188.40.166.11 > Connecting to patchwork.openwrt.org > (patchwork.openwrt.org)|188.40.166.11|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: unspecified [text/plain] > Saving to: `STDOUT' > > [ <=> > ] 2,467 10.9K/s in 0.2s > > 2013-11-29 21:29:58 (10.9 KB/s) - written to stdout [2467] > > Applying: update Userspace support for the WA850/WA750 > fatal: corrupt patch at line 28 > Patch failed at 0001 update Userspace support for the WA850/WA750 Also a Signed-off-by line is missing. Please fix it. Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] add profile and build image for the Sitecom WLR-8100
2013.10.08. 10:56 keltezéssel, Dirk Neukirchen írta: > add profile and build image for the Sitecom WLR-8100 > > - partitions on factory fw are a bit strange > - unknown contained some strings in factory > - unknown2 contains some atheros (2nd art ?) > > Signed-off-by: Dirk Neukirchen 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: fix switch port map for the Sitecom WLR-8100
2013.11.27. 21:16 keltezéssel, Dirk Neukirchen írta: > There was no way to determine a working config, because > the switch (ar8337) was not working previously. > > Signed-off-by: Dirk Neukirchen 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][v2] generic: ar8216: add AR8337N switch support
2013.11.27. 21:13 keltezéssel, Dirk Neukirchen írta: > This patch is needed to use the switch inside the Sitecom WLR-8100; > it was unusable and detected as Generic-Phy before. > > since ar8337 is behaving like ar8327 > generally do the same thing > see: https://forum.openwrt.org/viewtopic.php?pid=214218#p214218 > forward-ported to trunk > > Signed-off-by: Dirk Neukirchen Applied with small changes. 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: rssi leds for My Net WiFi Range Extender
2013.11.24. 3:58 keltezéssel, Christian Lamparter írta: > The device has three extra LEDs which indicate the quality > of the wireless link. Thanks to rssileds, this feature now > works out of the box. > > Signed-off-by: Christian Lamparter 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 2/2] ar71xx: improve support for the My Net Wi-Fi Range Extender device
2013.11.24. 3:34 keltezéssel, Christian Lamparter írta: > This patch improves support for the device considerably. > > 1. The wifi didn't work in the initial release. This was because > the WMAC of the AR9340 is not connected to the antennas. > (However, it can pick up wifi signals, if they are strong enough!) > Instead there's a dedicated AR9300 chip on the same board, which > works. > > 2. Ethernet throughput is improved. iperf shows that the hardware > can sustain more than 200Mbit/s and no longer drops any packages > when the link is under load. > > Signed-off-by: Christian Lamparter 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 1/2] ag71xx: add F1E specific feature bit definitions to AR934X register file
2013.11.24. 3:31 keltezéssel, Christian Lamparter írta: > The F1E Phy (AR8035?) requires additional bits to be > set in order to provide a fast and reliable connection > over gigabit links. > > When enabled, the link doesn't suffer anymore from a small > package loss under load and the performance is improved > quite a bit as well. (203 mbit/s vs 112 mbit/s, iperf tcp). > > Signed-off-by: Christian Lamparter 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: user space support update tl-wr842n_v2 add default led support
2013.11.18. 22:13 keltezéssel, Martijn Zilverschoon írta: > Small update to uci_defaults/01_leds, to support the usb led > Signed-off-by: Martijn Zilverschoon 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: Kernel support update tl-wr842n_v2 added missing usb led
2013.11.18. 21:49 keltezéssel, Martijn Zilverschoon írta: > Just a small oversight my part, added the support for the USB led 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] USB instabilities on Atheros AR9344
On 29 Nov 2013 18:56, "Vittorio G (VittGam)" wrote: > > Also it could be a defective router; I once had a defective TL-MR3020 (AR9330-based) router that crashed on a 3G dongle with many different hubs and power adapters. I bought another router of the same model but more recent hardware revision, and the problem disappeared. > By crashed I mean that the dongle (or the whole USB hub if I use one) gets USB-disconnected and then it gets detected again. Best, Vittorio G ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] USB instabilities on Atheros AR9344
On 29 Nov 2013 18:56, "Vittorio G (VittGam)" wrote: > > Also it could be a defective router; I once had a defective TL-MR3020 (AR9330-based) router that crashed on a 3G dongle with many different hubs and power adapters. I bought another router of the same model but more recent hardware revision, and the problem disappeared. > Sorry, I meant TL-MR3220, which is still AR9330 based btw. No problems at all with any of the MR3020 I have. Best, Vittorio G ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] USB instabilities on Atheros AR9344
Hello Kristian, On 29 Nov 2013 16:41, "Kristian Evensen" wrote: > > Hello, > > I am currently working on an embedded project based on the Atheros > AR9344 SoC. As a prototype device, we are using the TP-Link TL-WDR4300 > router (http://wiki.openwrt.org/toh/tp-link/tl-wdr4300) and latest > OpenWRT trunk. The kernel is 3.10.18. > > We have over the last couple of weeks experienced a USB problem that > we have not been able to solve. The USB hub works fine most of the > time, but when event X happens, USB becomes unusable for extended > periods of time. We have to disable/enable the power on the USB port > (using GPIO) and then wait until a timeout expires/queue is flushed. Have you tried with stable AA? I have the same router but with AA, and I've attached quite a lot of USB devices to it (one 32GB Cruzer Fit pendrive as extroot, 2 powered hubs, 2 bus powered hard disks [one per hub], one self powered hard disk, and one DVB-T TV card) and I experience no problems at all. I also use a Huawei 3G dongle sometimes, and the coverage here is not so good, but I never experienced this kind of problem. Usually the USB bus on my router is quite busy, eg. at the same time there can be a DVB recording from the card to one hard disk, a file transfer from another hard disk to a LAN client via NFS, an incoming file transfer via SFTP from the WAN port to the third hard disk, and also one WLAN client using the 3G dongle when I need the 3G connection, and no problems occur at all. > > The devices we have been able to trigger event X with is different > 3G/LTE modems. We have not been able to figure out exactly what > triggers the event, but it happens when we move into areas with poor > or no coverage and then move back into coverage. We see the error both > with QMI-modems (qmi_wwan driver), AT-modems (option_serial driver) > and WebUI-modems (cdc_ether driver). When looking in dmesg after this > event has happened, the following messages appear based on the modem > type: > > QMI: > Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan > 1-1.1.2:1.4: nonzero urb status received: -71 > Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan > 1-1.1.2:1.4: wdm_int_callback - 0 bytes > > Serial: > [62979.28] option1 ttyUSB7: option_instat_callback: error -71 > > WebUI: > [ 1192.68] hub 1-1:1.0: cannot reset port 1 (err = -71) > [ 1192.69] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad? > > The common denominator seems to be the -71 error code, which is a > generic Protocol Error if I have understood correctly. When I search > for this error code, it seems that most problems have been due to > power. However, this seems not be the issue here. The modems are > connected to an active hub and event X happens with only a single > modem connected, so it seems unlikely that it is power. Are you sure it is not power related? You said that you moved between different areas during your tests, so if you are using some battery source for your tests, you might want to check with a multimeter that you're giving steady 12 V to the router and 5 V to the hub, even while there is the 1 A load from the 3G dongle. Even if you're running from AC you might want to check that the hub is really delivering the voltage and current requested, or you might want to try to switch to a different hub. Also it could be a defective router; I once had a defective TL-MR3020 (AR9330-based) router that crashed on a 3G dongle with many different hubs and power adapters. I bought another router of the same model but more recent hardware revision, and the problem disappeared. My TL-WDR4300 is HW ver 1.1 on the back sticker, by the way. > > In order to rule out the TP-Link router, we have also tested with > another router based on the same SoC (Netgear WNDR4300). The same > issue is seen. We also made some tests on a device with a different > SoC (Raspberry Pi, BCM2835) and do not see this issue. > > We have mostly focused on the QMI modems and when using dynamic > debugging, dmesg also contains these errors (repeated many times): > [ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/1514 retry 26 > [ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/64 retry 14 > > Each packet is, as expected, retried 32 times. The data we sent when > these messages appeared was normal TCP traffic, which explains the > packet sizes. If we leave the router alone long enough, it is able to > restart the modems (they disconnect and then connect). However, this > can take many minutes (I guess the packet queue has to be flushed?), > and while this happens the USB hub is blocked (no traffic can pass > through it). > > When running usbmon, we see the following around the time of the crash > (with QMI modem): > > 86abea80 1428742032 S Bi:1:115:7 -150 1514 < > 86abeb00 1428801536 C Bi:1:115:7 0 226 = 024b322c fd930250 f300 > 08004500 00d4bba7 4000fd06 08728027 245d2e0f > 86abeb00 1428801554 S Bi:1:11
Re: [OpenWrt-Devel] USB instabilities on Atheros AR9344
Hi Kristian, Le 29/11/2013 16:41, Kristian Evensen a écrit : > Hello, > > I am currently working on an embedded project based on the Atheros > AR9344 SoC. As a prototype device, we are using the TP-Link TL-WDR4300 > router (http://wiki.openwrt.org/toh/tp-link/tl-wdr4300) and latest > OpenWRT trunk. The kernel is 3.10.18. > > We have over the last couple of weeks experienced a USB problem that > we have not been able to solve. The USB hub works fine most of the > time, but when event X happens, USB becomes unusable for extended > periods of time. We have to disable/enable the power on the USB port > (using GPIO) and then wait until a timeout expires/queue is flushed. > > The devices we have been able to trigger event X with is different > 3G/LTE modems. We have not been able to figure out exactly what > triggers the event, but it happens when we move into areas with poor > or no coverage and then move back into coverage. We see the error both > with QMI-modems (qmi_wwan driver), AT-modems (option_serial driver) > and WebUI-modems (cdc_ether driver). When looking in dmesg after this > event has happened, the following messages appear based on the modem > type: > > QMI: > Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan > 1-1.1.2:1.4: nonzero urb status received: -71 > Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan > 1-1.1.2:1.4: wdm_int_callback - 0 bytes > > Serial: > [62979.28] option1 ttyUSB7: option_instat_callback: error -71 > > WebUI: > [ 1192.68] hub 1-1:1.0: cannot reset port 1 (err = -71) > [ 1192.69] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad? > > The common denominator seems to be the -71 error code, which is a > generic Protocol Error if I have understood correctly. When I search > for this error code, it seems that most problems have been due to > power. However, this seems not be the issue here. The modems are > connected to an active hub and event X happens with only a single > modem connected, so it seems unlikely that it is power. > > In order to rule out the TP-Link router, we have also tested with > another router based on the same SoC (Netgear WNDR4300). The same > issue is seen. We also made some tests on a device with a different > SoC (Raspberry Pi, BCM2835) and do not see this issue. > > We have mostly focused on the QMI modems and when using dynamic > debugging, dmesg also contains these errors (repeated many times): > [ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/1514 retry > 26 > [ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/64 retry 14 > > Each packet is, as expected, retried 32 times. The data we sent when > these messages appeared was normal TCP traffic, which explains the > packet sizes. If we leave the router alone long enough, it is able to > restart the modems (they disconnect and then connect). However, this > can take many minutes (I guess the packet queue has to be flushed?), > and while this happens the USB hub is blocked (no traffic can pass > through it). > > When running usbmon, we see the following around the time of the crash > (with QMI modem): > > 86abea80 1428742032 S Bi:1:115:7 -150 1514 < > 86abeb00 1428801536 C Bi:1:115:7 0 226 = 024b322c fd930250 f300 > 08004500 00d4bba7 4000fd06 08728027 245d2e0f > 86abeb00 1428801554 S Bi:1:115:7 -150 1514 < > 84895c00 1428802518 S Bo:1:115:5 -150 66 = 0250f300 024b 322cfd93 > 08004500 00349c42 40003f06 e6772e0f e6768027 > 84895c00 1428802660 C Bo:1:115:5 0 66 > > 86abeb80 1428982112 C Bi:1:115:7 0 1354 = 024b322c fd930250 f300 > 08004500 053cbbaa 4000fd06 04078027 245d2e0f > 86abeb80 1428982141 S Bi:1:115:7 -150 1514 < > 86abec00 1429021624 C Bi:1:115:7 0 226 = 024b322c fd930250 f300 > 08004500 00d4bbab 4000fd06 086e8027 245d2e0f > 86abec00 1429021653 S Bi:1:115:7 -150 1514 < > 84895480 1429022660 S Bo:1:115:5 -150 66 = 0250f300 024b 322cfd93 > 08004500 00349c43 40003f06 e6762e0f e6768027 > 84895480 1429022746 C Bo:1:115:5 0 66 > > 86b1dc00 1430690752 C Ii:1:115:6 0:16 8 = a101 0400 > 86b03d80 1430690765 S Ci:1:115:0 s a1 01 0004 1000 4096 < > 86b1dc00 1430690787 S Ii:1:115:6 -150:16 64 < > 86b03d80 1430691369 C Ci:1:115:0 0 39 = 01260080 03010400 0024001a > 001e0400 9f0c 1d0200db 0e110200 01050106 > 86abec80 1430896349 C Bi:1:115:7 -71 0 > 84895800 1431014639 S Bi:1:115:7 -150 1514 < > 86abed00 1431066817 C Bi:1:115:7 -71 0 > 84895480 1431184603 S Bi:1:115:7 -150 1514 < > 86abed80 1431307124 C Bi:1:115:7 -71 0 > 86b03c00 1431330567 S Co:1:115:0 s 21 00 0004 0012 18 = 0111 > 0301 0125 00100200 ff00 > 86b03c00 1431331498 C Co:1:115:0 0 18 > > 86b1dc00 1431332988 C Ii:1:115:6 0:16 8 = a101 0400 > 86b03d80 1431332996 S Ci:1:115:0 s a1 01 0004 1000 4096 < > 86b1dc00 1431333012 S Ii:1:115:6 -150:16 64 < > 86b03d80 1431333484 C Ci:1:115:0 0 58 = 01390080 03010200 0120002d > 00020400 01020092 05110400 01006e05 > 86b03c00 1431346879 S
[OpenWrt-Devel] USB instabilities on Atheros AR9344
Hello, I am currently working on an embedded project based on the Atheros AR9344 SoC. As a prototype device, we are using the TP-Link TL-WDR4300 router (http://wiki.openwrt.org/toh/tp-link/tl-wdr4300) and latest OpenWRT trunk. The kernel is 3.10.18. We have over the last couple of weeks experienced a USB problem that we have not been able to solve. The USB hub works fine most of the time, but when event X happens, USB becomes unusable for extended periods of time. We have to disable/enable the power on the USB port (using GPIO) and then wait until a timeout expires/queue is flushed. The devices we have been able to trigger event X with is different 3G/LTE modems. We have not been able to figure out exactly what triggers the event, but it happens when we move into areas with poor or no coverage and then move back into coverage. We see the error both with QMI-modems (qmi_wwan driver), AT-modems (option_serial driver) and WebUI-modems (cdc_ether driver). When looking in dmesg after this event has happened, the following messages appear based on the modem type: QMI: Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan 1-1.1.2:1.4: nonzero urb status received: -71 Thu Nov 21 09:44:53 2013 kern.err kernel: [ 490.60] qmi_wwan 1-1.1.2:1.4: wdm_int_callback - 0 bytes Serial: [62979.28] option1 ttyUSB7: option_instat_callback: error -71 WebUI: [ 1192.68] hub 1-1:1.0: cannot reset port 1 (err = -71) [ 1192.69] hub 1-1:1.0: Cannot enable port 1. Maybe the USB cable is bad? The common denominator seems to be the -71 error code, which is a generic Protocol Error if I have understood correctly. When I search for this error code, it seems that most problems have been due to power. However, this seems not be the issue here. The modems are connected to an active hub and event X happens with only a single modem connected, so it seems unlikely that it is power. In order to rule out the TP-Link router, we have also tested with another router based on the same SoC (Netgear WNDR4300). The same issue is seen. We also made some tests on a device with a different SoC (Raspberry Pi, BCM2835) and do not see this issue. We have mostly focused on the QMI modems and when using dynamic debugging, dmesg also contains these errors (repeated many times): [ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/1514 retry 26 [ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/64 retry 14 Each packet is, as expected, retried 32 times. The data we sent when these messages appeared was normal TCP traffic, which explains the packet sizes. If we leave the router alone long enough, it is able to restart the modems (they disconnect and then connect). However, this can take many minutes (I guess the packet queue has to be flushed?), and while this happens the USB hub is blocked (no traffic can pass through it). When running usbmon, we see the following around the time of the crash (with QMI modem): 86abea80 1428742032 S Bi:1:115:7 -150 1514 < 86abeb00 1428801536 C Bi:1:115:7 0 226 = 024b322c fd930250 f300 08004500 00d4bba7 4000fd06 08728027 245d2e0f 86abeb00 1428801554 S Bi:1:115:7 -150 1514 < 84895c00 1428802518 S Bo:1:115:5 -150 66 = 0250f300 024b 322cfd93 08004500 00349c42 40003f06 e6772e0f e6768027 84895c00 1428802660 C Bo:1:115:5 0 66 > 86abeb80 1428982112 C Bi:1:115:7 0 1354 = 024b322c fd930250 f300 08004500 053cbbaa 4000fd06 04078027 245d2e0f 86abeb80 1428982141 S Bi:1:115:7 -150 1514 < 86abec00 1429021624 C Bi:1:115:7 0 226 = 024b322c fd930250 f300 08004500 00d4bbab 4000fd06 086e8027 245d2e0f 86abec00 1429021653 S Bi:1:115:7 -150 1514 < 84895480 1429022660 S Bo:1:115:5 -150 66 = 0250f300 024b 322cfd93 08004500 00349c43 40003f06 e6762e0f e6768027 84895480 1429022746 C Bo:1:115:5 0 66 > 86b1dc00 1430690752 C Ii:1:115:6 0:16 8 = a101 0400 86b03d80 1430690765 S Ci:1:115:0 s a1 01 0004 1000 4096 < 86b1dc00 1430690787 S Ii:1:115:6 -150:16 64 < 86b03d80 1430691369 C Ci:1:115:0 0 39 = 01260080 03010400 0024001a 001e0400 9f0c 1d0200db 0e110200 01050106 86abec80 1430896349 C Bi:1:115:7 -71 0 84895800 1431014639 S Bi:1:115:7 -150 1514 < 86abed00 1431066817 C Bi:1:115:7 -71 0 84895480 1431184603 S Bi:1:115:7 -150 1514 < 86abed80 1431307124 C Bi:1:115:7 -71 0 86b03c00 1431330567 S Co:1:115:0 s 21 00 0004 0012 18 = 0111 0301 0125 00100200 ff00 86b03c00 1431331498 C Co:1:115:0 0 18 > 86b1dc00 1431332988 C Ii:1:115:6 0:16 8 = a101 0400 86b03d80 1431332996 S Ci:1:115:0 s a1 01 0004 1000 4096 < 86b1dc00 1431333012 S Ii:1:115:6 -150:16 64 < 86b03d80 1431333484 C Ci:1:115:0 0 58 = 01390080 03010200 0120002d 00020400 01020092 05110400 01006e05 86b03c00 1431346879 S Co:1:115:0 s 21 00 0004 000d 13 = 010c 0301 004d 00 86b03c00 1431347879 C Co:1:115:0 0 13 > 86b1dc00 1431348994 C Ii:1:115:6 0:16 8 = a101 0400 86b03d80 1431349002 S Ci:1:115:0 s a1 01 0004 1000 4096 < 86b1dc00 1431349021 S Ii:1:1
[OpenWrt-Devel] [RFC/RFT] netifd: Initial OpenVSwitch support
Add a new device type "ovs" to define openvswitch (pseudo-) bridges.
For setting up oppenvswitch bridges the "ovs-vsctl" utility is used
within system-ovs.* and might be replaced with plain JSON-RPC in the
future.
Signed-off-by: Helmut Schaa
---
This is a first RFC of openvswitch integration in netifd based on
netifd trunk. In parts its quite similar to the bridge code but due
to pseudo bridge support there's not much code to share.
I'd appreciate any testing beside my own :D
I don't really like calling the ovs-vsctl utility (see system-ovs.c)
but using JSON-RPC would add much more code & complexity and there is
no "easy-to-use" library yet that we could utilize. In the long term
all these forks should be replaced by proper IPC but for now it seems
good enough.
As next step I'd add another device-type "ovs-port" or similar to allow
definition of internal ovs ports and more complex port configurations
(for example adding eth0 as trunk port for vlan 1,2 and 3).
Thoughts?
Thanks,
Helmut
CMakeLists.txt | 2 +-
config.c | 2 +
config/network | 15 ++
device.h | 1 +
ovs.c | 664 +
system-linux.c | 6 +-
system-ovs.c | 115 ++
system-ovs.h | 31 +++
system.h | 2 +
9 files changed, 836 insertions(+), 2 deletions(-)
create mode 100644 ovs.c
create mode 100644 system-ovs.c
create mode 100644 system-ovs.h
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 65da3cf..e4190a0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -15,7 +15,7 @@ SET(SOURCES
interface.c interface-ip.c interface-event.c
iprule.c proto.c proto-static.c proto-shell.c
config.c device.c bridge.c vlan.c alias.c
- macvlan.c ubus.c wireless.c)
+ macvlan.c ubus.c wireless.c ovs.c system-ovs.c)
find_library(json NAMES json-c json)
diff --git a/config.c b/config.c
index bb0cd05..132817d 100644
--- a/config.c
+++ b/config.c
@@ -169,6 +169,8 @@ config_init_devices(void)
devtype = &tunnel_device_type;
else if (!strcmp(type, "macvlan"))
devtype = &macvlan_device_type;
+ else if (!strcmp(type, "ovs"))
+ devtype = &ovs_device_type;
}
if (!devtype)
diff --git a/config/network b/config/network
index b2985d3..aee4851 100644
--- a/config/network
+++ b/config/network
@@ -72,3 +72,18 @@ config route
option gateway 192.168.5.2
option interface wan
+# Basic OpenVSwitch
+config device
+option typeovs
+option namebr-ovs
+option ifname eth0
+option ovs_empty 1
+
+# Pseudo bridge on top of br-ovs (vlan 1000)
+config device
+option type ovs
+option name br-ovs1000
+option ovs_tag 1000
+option ovs_base br-ovs
+option ifname eth1
+
diff --git a/device.h b/device.h
index dbcaf77..24299a1 100644
--- a/device.h
+++ b/device.h
@@ -153,6 +153,7 @@ extern const struct device_type simple_device_type;
extern const struct device_type bridge_device_type;
extern const struct device_type tunnel_device_type;
extern const struct device_type macvlan_device_type;
+extern const struct device_type ovs_device_type;
void device_lock(void);
void device_unlock(void);
diff --git a/ovs.c b/ovs.c
new file mode 100644
index 000..29db26c
--- /dev/null
+++ b/ovs.c
@@ -0,0 +1,664 @@
+/*
+ * netifd - network interface daemon
+ * Copyright (C) 2013 Helmut Schaa
+ *
+ * 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
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include "netifd.h"
+#include "device.h"
+#include "interface.h"
+#include "system-ovs.h"
+
+enum {
+ OVS_ATTR_IFNAME,
+ OVS_ATTR_BASE,
+ OVS_ATTR_TAG,
+ OVS_ATTR_EMPTY,
+ __OVS_ATTR_MAX
+};
+
+static const struct blobmsg_policy ovs_attrs[__OVS_ATTR_MAX] = {
+ [OVS_ATTR_IFNAME] = { "ifname", BLOBMSG_TYPE_ARRAY },
+ [OVS_ATTR_BASE] = { "ovs_base", BLOBMSG_TYPE_STRING },
+ [OVS_ATTR_TAG] = { "ovs_tag", BLOBMSG_TYPE_INT32 },
+ [OVS_ATTR_EMPTY] = { "ovs_empty", BLOBMSG_TYPE_BOOL },
+};
+
+static const struct uci_blob_param_info ovs_attr_info[__OVS_ATTR_MAX] = {
+ [OVS_ATTR_IFNAME] = { .type = BLOBMSG_TYPE_STRING },
+};
+
+static const struct uci_blob_param_list ovs_attr_list = {
+ .n_params = __OVS_ATTR_MAX,
+ .params = ovs_attrs,
+ .info = ovs_attr_info,
+
+ .n_next = 1,
+ .next = { &device_attr_list },
+};
+
+static str
Re: [OpenWrt-Devel] [RFC] exFAT driver
2013/11/29, David Lang : > As I understand it, lawyers are looking over the situation with this driver > > before it gets included in the upstream kernel. > > David Lang > Then we must wait. Thanks for the info. Regards: José Vázquez ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netifd: Fix possible segfault in bridge code
On Fri, Nov 29, 2013 at 3:34 PM, Felix Fietkau wrote: > On 2013-11-29 15:22, Helmut Schaa wrote: >> Need to check calloc result. In case of failure the bridge member will be >> missing. >> >> Signed-off-by: Helmut Schaa > Pushed to git, thanks. > It will be committed to OpenWrt once I'm done with the integration of > the new wireless code. Thanks Felix. Helmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netifd: Fix possible segfault in bridge code
On 2013-11-29 15:22, Helmut Schaa wrote: > Need to check calloc result. In case of failure the bridge member will be > missing. > > Signed-off-by: Helmut Schaa Pushed to git, thanks. It will be committed to OpenWrt once I'm done with the integration of the new wireless code. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] exFAT driver
As I understand it, lawyers are looking over the situation with this driver before it gets included in the upstream kernel. David Lang On Fri, 29 Nov 2013, Wojciech Kromer wrote: Date: Fri, 29 Nov 2013 14:34:44 +0100 From: Wojciech Kromer Reply-To: OpenWrt Development List To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] [RFC] exFAT driver I'd like to have kernel exfat driver, esspecialy one that compiles with different kernel versions. This one is readonly and seems to be android specific. Just for start, I've tried it on two machines. After some small changes it compiles and: - works with 2.6.32 on debian - crashes with 2.6.38 on ubuntu Best regards. Accidentally found an exFAT driver in a kernel 2.6.34 source: https://github.com/Pivosgroup/buildroot-linux-kernel/tree/develop/fs/exfat The source of the driver inside the mentioned kernel can be downloaded here: http://www.munted.org.uk/programming/exfat.tar.bz2 If the inclusion of this driver is interesting i can test it, send the feedback and write a patch. Personally i'm not interested on it, but surely there are some people interested in this filesystem. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] netifd: Fix possible segfault in bridge code
Need to check calloc result. In case of failure the bridge member will be missing. Signed-off-by: Helmut Schaa --- bridge.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bridge.c b/bridge.c index 0e06cc2..4ef0d7e 100644 --- a/bridge.c +++ b/bridge.c @@ -318,6 +318,9 @@ bridge_create_member(struct bridge_state *bst, struct device *dev, bool hotplug) struct bridge_member *bm; bm = calloc(1, sizeof(*bm) + strlen(dev->ifname) + 1); + if (!bm) + return NULL; + bm->bst = bst; bm->dev.cb = bridge_member_cb; bm->dev.hotplug = hotplug; -- 1.8.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [package] fxload: fix build
should fix broken_package reported by buildbots since Kernel 3.7 headers are located in UAPI directory Signed-off-by: Dirk Neukirchen --- utils/fxload/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/fxload/Makefile b/utils/fxload/Makefile index f961d52..93e63c1 100644 --- a/utils/fxload/Makefile +++ b/utils/fxload/Makefile @@ -28,7 +28,7 @@ endef define Build/Compile $(call Build/Compile/Default, \ - CFLAGS="$(TARGET_CFLAGS) -I$(LINUX_DIR)/include" \ + CFLAGS="$(TARGET_CFLAGS) -I$(LINUX_DIR)/$(LINUX_UAPI_DIR)include" \ ) endef -- 1.8.4.4 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] [RFC] exFAT driver
I'd like to have kernel exfat driver, esspecialy one that compiles with different kernel versions. This one is readonly and seems to be android specific. Just for start, I've tried it on two machines. After some small changes it compiles and: - works with 2.6.32 on debian - crashes with 2.6.38 on ubuntu Best regards. Accidentally found an exFAT driver in a kernel 2.6.34 source: https://github.com/Pivosgroup/buildroot-linux-kernel/tree/develop/fs/exfat The source of the driver inside the mentioned kernel can be downloaded here: http://www.munted.org.uk/programming/exfat.tar.bz2 If the inclusion of this driver is interesting i can test it, send the feedback and write a patch. Personally i'm not interested on it, but surely there are some people interested in this filesystem. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] sysupgrade fails due to bad nand flash blocks
Hi all, I have a problem with sysupgrade failing prematurely because my nand flash contains bad blocks. This results in an incomplete rootfs image in flash upon reboot from sysupgrade. I am running an attitude adjustment derivative (svn r35400) for custom hardware. Uboot / the kernel seem to deal with bad flash blocks correctly, this only occurs when using mtd via sysupgrade. This is what I see: # sysupgrade openwrt-lpc32xx-JNRD6040--jffs2-sysupgrade.bin Saving config files... Sending TERM to remaining processes ... syslogd klogd hotplug2 ubusd netifd mrd6 dbus-daemon dnsmasq avahi-daemon Sending KILL to remaining processes ... Switching to ramdisk... Performing system upgrade... Unlocking firmware ... Writing from to firmware ... [e][ 502.56] nand_erase_nand: attempt to erase a bad block at page 0x2080 Failed to erase block Upgrade completed Rebooting system... [ 502.58] Restarting system. I found this ticket from a while ago that seems to cover this: https://dev.openwrt.org/ticket/11749 Looking at the latest version of mtd in trunk I can't see anything to address this issue - is this something that is not that common and so hasn't been observed on other hardware? Thanks, Matt ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Boot OpenWRT on RB433 "Lite" versions (RB433L , RB433UAHL)
Hello, I'm currently struggling with two similar Microtik routers: RB433L , RB433UAHL. I was trying hard to run my RB433GL version. The "L" versions have a lot of small, but hard to use differences. They are the Lite version of the well-known rb433, with a lower power consomption. It seems to be rather "Low cost", not "Low power", whatever doc says. Their amusing property is that the serial port seems present (RX/TX pads) but not initialized at boot, neither by Linux kernel or by the bootloader, which make debugging difficult (On the TX pad, I just get a suspicious periodic square signal after boot) Generally net-boot works, console also works fine after small patch. See my posts: https://forum.openwrt.org/viewtopic.php?id=42410 https://forum.openwrt.org/viewtopic.php?id=42298 I can't get any of them boot an OpenWRT image (trunk of today) using the netboot procedure described here: http://wp.ayufan.eu/2013/02/the-rb951g-and-openwrt/ (and elsewere). The router does bootp + tftp procedure and seems to ignore the ELF file I give it (I tried all of openwrt-ar71xx-mikrotik-vmlinux.elf openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf openwrt-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf openwrt-ar71xx-mikrotik-vmlinux-lzma.elf ) Please set correct file name in your DHCP server. The netboot procedure does work since I could send the microtik's NPK upgrade package and the routeur did flash itself. Try ask on mikrotik forum Apparently, one person did success in booting a kernel https://forum.openwrt.org/viewtopic.php?id=41490 , but no specific details on the file used not the procedure. I would be very happy to just get to the "kernel boot" point. Does anyone did play with this kind of hardware ? My "L" board is ot of order now, and I've decided not to by more... Main problem with all "L" versions is developing NAND driver. Best regards. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WD MyNet N750: ar9344 + ar8327 switch, unclear on phy/mdio/mac wiring
Bootloader code has been published as per my request. You can find it here: http://support.wdc.com/product/download.asp?groupid=1702&sid=178&lang=en Now we just need to find where they broke it :) - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [package] grub2: use freetype macros
including freetype header directly leads
to build error:
util/grub-mkfont.c:42:30: fatal error: freetype/ftsynth.h: No such file or
directory
Observed on Debian Testing, because new Freetype2
changed include location there
add a patch to grub - use provided #include macros documented:
http://www.freetype.org/freetype2/docs/reference/ft2-header_file_macros.html#FT_SYNTHESIS_H
Signed-off-by: Dirk Neukirchen
---
package/boot/grub2/Makefile | 1 +
package/boot/grub2/patches/101-freetype2_fix_mkfont.patch | 11 +++
2 files changed, 12 insertions(+)
create mode 100644 package/boot/grub2/patches/101-freetype2_fix_mkfont.patch
diff --git a/package/boot/grub2/Makefile b/package/boot/grub2/Makefile
index dd490ff..0f66354 100644
--- a/package/boot/grub2/Makefile
+++ b/package/boot/grub2/Makefile
@@ -18,6 +18,7 @@ PKG_MD5SUM:=e927540b6eda8b024fb0391eeaa4091c
HOST_BUILD_PARALLEL:=1
PKG_BUILD_DEPENDS:=grub2/host
+PKG_FIXUP:=autoreconf
include $(INCLUDE_DIR)/host-build.mk
include $(INCLUDE_DIR)/package.mk
diff --git a/package/boot/grub2/patches/101-freetype2_fix_mkfont.patch
b/package/boot/grub2/patches/101-freetype2_fix_mkfont.patch
new file mode 100644
index 000..fc9f146
--- /dev/null
+++ b/package/boot/grub2/patches/101-freetype2_fix_mkfont.patch
@@ -0,0 +1,11 @@
+--- a/util/grub-mkfont.c
b/util/grub-mkfont.c
+@@ -39,7 +39,7 @@
+ #include FT_FREETYPE_H
+ #include FT_TRUETYPE_TAGS_H
+ #include FT_TRUETYPE_TABLES_H
+-#include
++#include FT_SYNTHESIS_H
+
+ #undef __FTERRORS_H__
+ #define FT_ERROR_START_LIST const char *ft_errmsgs[] = {
--
1.8.4.4
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
[OpenWrt-Devel] [PATCH][2/2] AR71xx: Update profile for the wa750/wa850 to include rssileds by default
diff --git a/target/linux/ar71xx/generic/profiles/tp-link.mk b/target/linux/ar71xx/generic/profiles/tp-link.mk index 5236f7f..5138c0c 100644 --- a/target/linux/ar71xx/generic/profiles/tp-link.mk +++ b/target/linux/ar71xx/generic/profiles/tp-link.mk @@ -142,7 +142,7 @@ $(eval $(call Profile,TLWA701)) define Profile/TLWA750 NAME:=TP-LINK TL-WA750RE - PACKAGES:= + PACKAGES:=rssileds endef define Profile/TLWA750/Description @@ -184,7 +184,7 @@ $(eval $(call Profile,TLWA830)) define Profile/TLWA850 NAME:=TP-LINK TL-WA850RE - PACKAGES:= + PACKAGES:=rssileds endef define Profile/TLWA850/Description ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][1/2] update Userspace support for the WA850/WA750
Patch for adding the default uci values of the rssileds application for the tp-link -tl-wa850re and the tl-wa750re for the diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index 95b30c1..5a8173f 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -180,11 +180,23 @@ tl-mr3420-v2) tl-wa750re) ucidef_set_led_netdev "lan" "LAN" "tp-link:orange:lan" "eth0" ucidef_set_led_wlan "wlan" "WLAN" "tp-link:orange:wlan" "phy0tpt" + ucidef_set_rssimon "wlan0" "4" "1" + ucidef_set_led_rssi "rssilow" "RSSILOW" "tp-link:orange:signal1" "wlan0" "1" "100" "0" "13" + ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMHIGH" "tp-link:orange:signal2" "wlan0" "20" "100" "-19" "13" + ucidef_set_led_rssi "rssimedium" "RSSIMEDIUM" "tp-link:orange:signal3" "wlan0" "40" "100" "-39" "13" + ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "tp-link:orange:signal4" "wlan0" "60" "100" "-59" "13" + ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "tp-link:orange:signal5" "wlan0" "80" "100" "-79" "13" ;; tl-wa850re) ucidef_set_led_netdev "lan" "LAN" "tp-link:blue:lan" "eth0" ucidef_set_led_wlan "wlan" "WLAN" "tp-link:blue:wlan" "phy0tpt" + ucidef_set_rssimon "wlan0" "4" "1" + ucidef_set_led_rssi "rssilow" "RSSILOW" "tp-link:blue:signal1" "wlan0" "1" "100" "0" "13" + ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMHIGH" "tp-link:blue:signal2" "wlan0" "20" "100" "-19" "13" + ucidef_set_led_rssi "rssimedium" "RSSIMEDIUM" "tp-link:blue:signal3" "wlan0" "40" "100" "-39" "13" + ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "tp-link:blue:signal4" "wlan0" "60" "100" "-59" "13" + ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "tp-link:blue:signal5" "wlan0" "80" "100" "-79" "13" ;; tl-wa901nd) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
