Re: [OpenWrt-Devel] ar71xx update to v3.18

[John Crispin]

On 16/02/2015 01:17, Michaël Zweers wrote:
> It builds oke now,
> 
> but its doesn't boot on my device. i don't get to see any (informative)
> boot error's (see log).
> 
> 
> 
> John Crispin schreef op 15-2-2015 om 22:16:
>>
>>
>> On 15/02/2015 21:44, Michaël Zweers wrote:
>>>
>>> Hello,
>>>
>>> I got a error message (kernel compile log included) when building v3.18
>>> for wr703n.
>>>
>>> If you need additional info let me know.
>>>
>>>
>>
>> please retry, i just pushed a fix
>>


can some one confirm that wr703n fails to boot ? if so i will go to the
shop today and get one.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Retry 6rd if wan is down

[Steven Barth]

What does that "sleep 60" do for you here? It doesn't look very sane to me.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx update to v3.18

[Bruno Randolf]

Hi!

Tested on OM2P and TP-Link WDR3600, looks good: boots, nothing obviously
broken, wifi works, eth works, but I have not ran it more than 10
minutes each.

Greetings,
bruno

On 02/15/2015 07:49 PM, John Crispin wrote:
> Hi,
> 
> i just pushed the v3.18 support for ar71xx. i have tested this on
> carambola2, unifi and wndr4300. the default is still at 3.14. please
> start testing on more hardware.
> 
> to do so you need to set the kernel to 3.18 in
> target/linux/ar71xx/Makefile as the default is still at 3.14.
> 
> 902-unaligned_access_hacks.patch was rebased, however there might be new
> places in the stack that need the hack applied. testing for this is also
> welcome.
> 
>   John
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx update to v3.18

[Michaël Zweers]

I can confirm that it does work, i don't no where or why it didn't the
previous time. I did a clean clone and used a clean config and now
everything looks to be oké.

Bootlog is attached:
confirmed working:

Boot:   Yes
Ethernet:   Yes
WiFI:   Yes
Luci:   Yes (used to scan for wifi)

If you want me to test something else or something specific please let
me know.

John Crispin schreef op 16-2-2015 om 9:10:
> 
> 
> On 16/02/2015 01:17, Michaël Zweers wrote:
>> It builds oke now,
>>
>> but its doesn't boot on my device. i don't get to see any (informative)
>> boot error's (see log).
>>
>>
>>
>> John Crispin schreef op 15-2-2015 om 22:16:
>>>
>>>
>>> On 15/02/2015 21:44, Michaël Zweers wrote:

 Hello,

 I got a error message (kernel compile log included) when building v3.18
 for wr703n.

 If you need additional info let me know.


>>>
>>> please retry, i just pushed a fix
>>>
> 
> 
> can some one confirm that wr703n fails to boot ? if so i will go to the
> shop today and get one.
> 
*
*U-Boot 1.1.4MGZ MOD_V1  (Jun 24 2014)*
*

AP121 (AR9331) U-Boot for TL-WR703N

DRAM:   32 MB DDR 16-bit
FLASH:  Winbond W25Q128 (16 MB)
CLOCKS: 400/400/200/33 MHz (CPU/RAM/AHB/SPI)

LED on during eth initialization...

Hit any key to stop autobooting:  0

Booting image at: 0x9F02

   Image name:   OpenWrt r44459
   Image type:   MIPS Linux Kernel Image (lzma compressed)
   Data size:1205952 Bytes = 1.2 MB
   Load address: 0x8006
   Entry point:  0x8006

Uncompressing kernel image... OK!
Starting kernel...

[0.00] Linux version 3.18.7 (user@HartOfGold) (gcc version 4.8.3 
(OpenWrt/Linaro GCC 4.8-2014.04 r44459) ) #1 Mon Feb 16 10:26:18 CET 2015
[0.00] bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019374 (MIPS 24Kc)
[0.00] SoC: Atheros AR9330 rev 1
[0.00] Determined physical RAM map:
[0.00]  memory: 0200 @  (usable)
[0.00] Initrd not found or empty - disabling initrd
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x01ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x01ff]
[0.00] Initmem setup node 0 [mem 0x-0x01ff]
[0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 
bytes
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 8128
[0.00] Kernel command line:  board=TL-WR703N console=ttyATH0,115200 
rootfstype=squashfs,jffs2 noinitrd
[0.00] PID hash table entries: 128 (order: -3, 512 bytes)
[0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Writing ErrCtl register=
[0.00] Readback ErrCtl register=
[0.00] Memory: 28324K/32768K available (2627K kernel code, 131K rwdata, 
544K rodata, 208K init, 193K bss, K reserved)
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:51
[0.00] Clocks: CPU:400.000MHz, DDR:400.000MHz, AHB:200.000MHz, 
Ref:25.000MHz
[0.00] Calibrating delay loop... 265.42 BogoMIPS (lpj=1327104)
[0.08] pid_max: default: 32768 minimum: 301
[0.08] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.09] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.10] NET: Registered protocol family 16
[0.10] MIPS: machine is TP-LINK TL-WR703N v1
[0.38] Switched to clocksource MIPS
[0.38] NET: Registered protocol family 2
[0.39] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[0.39] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[0.39] TCP: Hash tables configured (established 1024 bind 1024)
[0.40] TCP: reno registered
[0.40] UDP hash table entries: 256 (order: 0, 4096 bytes)
[0.41] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[0.42] NET: Registered protocol family 1
[0.42] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.44] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[0.44] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) 
(CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[0.45] msgmni has been set to 55
[0.45] io scheduler noop registered
[0.46] io scheduler deadline registered (default)
[0.46] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
[0.47] ar933x-uart: ttyATH0 at MMIO 0x1802 (irq = 11, base_baud = 
1562500) is a AR933X UART
[0.48] console [ttyATH0] enabled
[0.48] console [ttyATH0] enabled
[

Re: [OpenWrt-Devel] looking for at91 test hardware

[Nicolas FERRE]

John Crispin  openwrt.org> writes:

> 
> Hi,
> 
> does anyone have one of these ->
> http://www.atmel.com/tools/ATSAMA5D3-XPLD.aspx
> that he wants to donate so that i have something to test at91 images on

Hi Josh,

Of course, I can surely do something for you ;-)

Let's arrange the shipment in private.
(Thanks to Maxime Ripard for the "heads-up").

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

Re: [OpenWrt-Devel] looking for at91 test hardware

[John Crispin]

On 16/02/2015 11:52, Nicolas FERRE wrote:
> John Crispin  openwrt.org> writes:
> 
>>
>> Hi,
>>
>> does anyone have one of these ->
>> http://www.atmel.com/tools/ATSAMA5D3-XPLD.aspx
>> that he wants to donate so that i have something to test at91 images on
> 
> Hi Josh,
> 
> Of course, I can surely do something for you ;-)
> 
> Let's arrange the shipment in private.
> (Thanks to Maxime Ripard for the "heads-up").
> 
> Bye,
> 


Hi Nicolas,

Oh Wow, that is something i did not expect. i am currently updating all
targets in openwrt to v3.18 and while doing so i noticed that i do not
own any recent AT91 hardware. I previously used an acmesystems board but
gave it away a while ago for an art installation.

totally awesome, put a big smile on my face

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

Re: [OpenWrt-Devel] ar71xx update to v3.18

[John Crispin]

On 16/02/2015 11:05, Michaël Zweers wrote:
> I can confirm that it does work, i don't no where or why it didn't the
> previous time. I did a clean clone and used a clean config and now
> everything looks to be oké.
> 
> Bootlog is attached:
> confirmed working:
> 
> Boot: Yes
> Ethernet: Yes
> WiFI: Yes
> Luci: Yes (used to scan for wifi)
> 
> If you want me to test something else or something specific please let
> me know.
> 


ok, you got me scared for a moment ;)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: enables rt288x PCIe

[ngc-IIJ]

To choose whether bulid or not RT288x PCIe bus driver, CONFIG_SOC_RT2880 is 
wrong.
Here is its fix, and enables PCIe bus driver for some targets which have 2nd 
WiFi chipset via PCIe bus.

signed-off-by: n...@ff.iij4u.or.jp

--- 
a/target/linux/ramips/patches-3.14/0031-PCI-MIPS-adds-rt2880-pci-support.patch  
2015-01-05 20:51:44.539050748 +0900
+++ 
b/target/linux/ramips/patches-3.14/0031-PCI-MIPS-adds-rt2880-pci-support.patch  
2015-02-09 19:42:12.609019758 +0900
@@ -19,7 +19,7 @@ Signed-off-by: John Crispin https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: Buffalo WZR-AGL300NH target support

[ngc-IIJ]

I got work with this patch.
Ethernet switch (includes VLAN), WiFi connected via PCIe, LEDs, buttons.

In mtd partion map of DTS file, I renamed Linux firmware regions (kernel + root 
squashfs) to “firmware”because it allows kernel to split kernel and roots and 
rootfsdata.


signed-off-by: n...@ff.iij4u.or.jp
——
--- a/target/linux/ramips/base-files/etc/board.d/02_network 2015-01-05 
20:51:44.510050748 +0900
+++ b/target/linux/ramips/base-files/etc/board.d/02_network 2015-02-11 
12:20:00.751290483 +0900
@@ -235,6 +235,12 @@ ramips_setup_interfaces()
ucidef_add_switch_vlan "switch1" "2" "4 6t"
;;
 
+   wzr-agl300nh)
+   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 5t"
+   ucidef_add_switch_vlan "switch0" "2" "0 5t"
+   ;;
*)
RT3X5X=`cat /proc/cpuinfo | egrep "(RT3.5|RT5350)"`
if [ -n "${RT3X5X}" ]; then
--- a/target/linux/ramips/base-files/etc/diag.sh2015-01-05 
20:51:44.511050748 +0900
+++ b/target/linux/ramips/base-files/etc/diag.sh2015-02-07 
19:38:52.882546591 +0900
@@ -164,6 +164,9 @@ get_status_led() {
wli-tx4-ag300n)
status_led="buffalo:blue:power"
;;
+   wzr-agl300nh)
+   status_led="buffalo:green:router"
+   ;;
wl-351)
status_led="wl-351:amber:power"
;;
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh2015-01-05 
20:51:44.512050748 +0900
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh2015-02-07 
19:38:52.882546591 +0900
@@ -96,6 +96,7 @@ platform_check_image() {
wl-351 | \
wl341v3 | \
wli-tx4-ag300n | \
+   wzr-agl300nh | \
wmr300 |\
wnce2001 | \
wr512-3gn |\
--- a/target/linux/ramips/dts/WZR-AGL300NH.dts  1970-01-01 09:00:00.0 
+0900
+++ b/target/linux/ramips/dts/WZR-AGL300NH.dts  2015-02-11 11:40:50.188586711 
+0900
@@ -0,0 +1,135 @@
+/dts-v1/;
+
+/include/ "rt2880.dtsi"
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "WZR-AGL300NH", "ralink,rt2880-soc";
+   model = "Buffalo WZR-AGL300NH";
+
+   palmbus@30 {
+   gpio0: gpio@600 {
+   status = "okay";
+   };
+   };
+
+   pinctrl {
+   state_default: pinctrl0 {
+   gpio {
+   ralink,group = "i2c", "uartlite", "mdio";
+   ralink,function = "gpio";
+   };
+   };
+   };
+
+   cfi@1f00 {
+   compatible = "cfi-flash";
+   reg = <0x1f00 0x80>;
+
+   bank-width = <2>;
+   device-width = <2>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "uboot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+   partition@3 {
+   label = "uboot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0x3b>;
+   };
+   };
+
+   ethernet@40 {
+   status = "okay";
+   mtd-mac-address = <&factory 0x4>;
+
+port@0 {
+   ralink,fixed-link = <1000 1 1 1>;
+   };
+
+   mdio-bus {
+   status = "okay";
+   phy0: ethernet-phy@0 {
+   phy-mode = "mii";
+   reg = <0>;
+   };
+   };
+   };
+
+   rtl8366s {
+   compatible = "realtek,rtl8366s";
+   gpio-sda = <&gpio0 1 0>;
+   gpio-sck = <&gpio0 2 0>;
+   };
+
+   wmac@48 {
+   ralink,mtd-eeprom = <&factory 0>;
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <100>;
+   wps {
+   label = "wps";
+   gpios = <&gpio0 0 1>;
+   linux,code = <0x211>;
+   };
+   router {
+   label = "router_switch";
+   gpios = <&gpio0 7 0>;
+   linux,code = <0x100>;
+   };
+   reset {
+

Re: [OpenWrt-Devel] [PATCH] oxnas: fix itb generation

[Daniel Golle]

On Mon, Feb 16, 2015 at 07:49:54AM +0100, Dirk Neukirchen wrote:
> - according to imx6 Makefile and u-Boot documentation is itb 
>   and probably should not be changed
> - this fixes build error if CONFIG_TARGET_ROOTFS_INCLUDE_FIT is set
>   (missing .itb file)
> - use DTS_DIR (like in imx6 Makefile)
> 
> only compile tested
> 
> Signed-off-by: Dirk Neukirchen 
Acked-by: Daniel Golle 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx update to v3.18

[Ted Hess]

A couple of Ubiquiti RouterStation Pros running custom build from r44462. 
One is wifi bridge other is full-router.

So far all is OK (<1hr operation).

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

[OpenWrt-Devel] [PATCH][v2] BB : kirkwood : Seagate GoFlex Net "Board Name" and cleanup

[L. D. Pinney]

Add the diag.sh file for failsafe LEDs. 
Cleanup uci-defaults for network and LEDs.
Sets the "fault" LEDs in uci-defaults to off
Add the GoFlex Net "Board Name" 
Remove kmod-rtc-marvell from default packages, as the GoFlex net does not have 
a Real Time Clock.

V2 adds led "name" in uci-defaults missing from V1.

Signed-off-by: L. D. Pinney 
---
 target/linux/kirkwood/base-files/etc/diag.sh | 37 
+
 target/linux/kirkwood/base-files/etc/uci-defaults/01_leds| 17 
++---
 target/linux/kirkwood/base-files/etc/uci-defaults/02_network | 13 -
 target/linux/kirkwood/base-files/lib/kirkwood.sh |  4 
 target/linux/kirkwood/profiles/110-nas.mk|  2 +-
 5 files changed, 56 insertions(+), 17 deletions(-)

diff --git a/target/linux/kirkwood/base-files/etc/diag.sh 
b/target/linux/kirkwood/base-files/etc/diag.sh
new file mode 100755
index 000..29445d5
--- /dev/null
+++ b/target/linux/kirkwood/base-files/etc/diag.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+# Copyright (C) 2014 OpenWrt.org
+
+. /lib/functions/leds.sh
+. /lib/kirkwood.sh
+
+get_status_led() {
+   case $(kirkwood_board_name) in
+   dockstar|\
+   goflexnet|\
+   pogo_e02)
+   status_led="status:orange:fault"
+   ;;
+   ea4500)
+   status_led="ea4500:white:health"
+   ;;
+   esac
+}
+
+set_state() {
+   get_status_led
+
+   case "$1" in
+   preinit)
+   status_led_blink_preinit
+   ;;
+   failsafe)
+   status_led_blink_failsafe
+   ;;
+   preinit_regular)
+   status_led_blink_preinit_regular
+   ;;
+   done)
+   status_led_on
+   ;;
+   esac
+}
diff --git a/target/linux/kirkwood/base-files/etc/uci-defaults/01_leds 
b/target/linux/kirkwood/base-files/etc/uci-defaults/01_leds
index 07c1a0e..9961913 100644
--- a/target/linux/kirkwood/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/kirkwood/base-files/etc/uci-defaults/01_leds
@@ -9,22 +9,25 @@
 board=$(kirkwood_board_name)
 
 case "$board" in
-"dockstar")
-   ucidef_set_led_default "health" "status:green:health" "1"
-   ucidef_set_led_default "fault" "status:orange:fault" "1"
+"dockstar"|\
+"pogo_e02")
+   ucidef_set_led_default "health" "health" "status:green:health" "1"
+   ucidef_set_led_default "fault" "fault" "status:orange:fault" "0"
;;
 "ea4500")
ucidef_set_led_default "health" "ea4500:white:health" "1"
ucidef_set_led_default "pulse" "ea4500:white:pulse" "1"
;;
+"goflexnet")
+   ucidef_set_led_default "health" "health" "status:green:health" "1"
+   ucidef_set_led_default "fault" "fault" "status:orange:fault" "0"
+   ucidef_set_led_default "status" "status" "status:white:misc" "0"
+   ;;
 "ib62x0")
ucidef_set_led_default "health" "ib62x0:green:os" "1"
ucidef_set_led_default "fault" "ib62x0:red:os" "1"
;;
-"pogo_e02")
-   ucidef_set_led_default "health" "status:green:health" "1"
-   ucidef_set_led_default "fault" "status:orange:fault" "1"
-   ;;
+
 *)
;;
 esac
diff --git a/target/linux/kirkwood/base-files/etc/uci-defaults/02_network 
b/target/linux/kirkwood/base-files/etc/uci-defaults/02_network
index e795d65..cff31a8 100644
--- a/target/linux/kirkwood/base-files/etc/uci-defaults/02_network
+++ b/target/linux/kirkwood/base-files/etc/uci-defaults/02_network
@@ -28,15 +28,10 @@ board=$(kirkwood_board_name)
 ucidef_set_interface_loopback
 
 case "$board" in
-"dockstar")
-   set_lan_dhcp "eth0"
-   ;;
-"iconnect")
-   set_lan_dhcp "eth0"
-   ;;
-"ib62x0")
-   set_lan_dhcp "eth0"
-   ;;
+"dockstar"|\
+"goflexnet"|\
+"iconnect"|\
+"ib62x0"|\
 "pogo_e02")
set_lan_dhcp "eth0"
;;
diff --git a/target/linux/kirkwood/base-files/lib/kirkwood.sh 
b/target/linux/kirkwood/base-files/lib/kirkwood.sh
index ba080f4..e2a84a7 100755
--- a/target/linux/kirkwood/base-files/lib/kirkwood.sh
+++ b/target/linux/kirkwood/base-files/lib/kirkwood.sh
@@ -17,6 +17,10 @@ kirkwood_board_detect() {
name="dockstar"
;;
 
+   "Seagate GoFlex Net")
+   name="goflexnet"
+   ;;
+
"Iomega Iconnect")
name="iconnect"
;;
diff --git a/target/linux/kirkwood/profiles/110-nas.mk 
b/target/linux/kirkwood/profiles/110-nas.mk
index eff5952..daad904 100644
--- a/target/linux/kirkwood/profiles/110-nas.mk
+++ b/target/linux/kirkwood/profiles/110-nas.mk
@@ -25,7 +25,7 @@ define Profile/GOFLEXNET
   NAME:=Seagate GoFlexNet
   PACKAGES:= \
kmod-ata-core kmod-ata-marvell-sata \
-   kmod-rtc-marvell kmod-usb2 kmod-usb-storage \
+   kmod-usb2 kmod-usb-storage \
uboot-envtools
 endef
 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://l

Re: [OpenWrt-Devel] looking for at91 test hardware

[Owen Kirby]

John,

I have been working with the AT91 target with a few boards, one of which 
is our own custom Q70 board (http://www.exegin.com/pdf/q70_v01.pdf - if 
you will pardon the crummy datasheet), and I have also been testing the 
generic AT91 images on the Atmel AT91SAM9G20-EK.


We don't have any boards with the ATSAMA5D3, but if you would like I 
would be more than happy to send you a couple of the Atmel eval boards 
and some of our Q70 units to test images on.


Cheers,
Owen

On 15-02-15 11:42 PM, John Crispin wrote:

Hi,

does anyone have one of these ->
http://www.atmel.com/tools/ATSAMA5D3-XPLD.aspx
that he wants to donate so that i have something to test at91 images on

John
___
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] General questions about the direction of switch drivers

[Charlie Smurthwaite]

I'm writing a driver for a family of 24 port gigabit switches, with a
wide array of interesting hardware features. Creating basic VLAN
membership and tagging functionality under the swconfig framework has
been quite easy, and this framework has been excellent for this.

However, I would like to support a lot more of the functionality of this
hardware, and see other devices with advanced layer2 and layer3
switching supported in the future, so I wanted some opinion on the
direction things are taking.

Specifically I am looking for opinion on whether the swconfig framework
is suitable for more advanced functionality, or whether there was likely
to be a move to any other upstream framework for switch devices,
particularly those with more advanced functionality. The types of
functionality I am currently interested in supporting are:

* VLAN membership an tagging
* Packet and byte counters
* Security settings and filtering rules
* STP
* Layer 3 functionality (hardware IPv4 and IPv6 routing tables)
* Hardware NAT / firewall

Some of this functionality may simply require configuration, where other
functions require the active involvement of the CPU.

Thanks,

Charlie


Charlie Smurthwaite aTech Media

tel. 01202 901 222 (ext. 603) email. 
char...@atechmedia.com web. 
atechmedia.com

aTech Media Limited is a registered company in England and Wales. Registration 
Number 5523199. Registered Office: Unit 9 Winchester Place, North Street, 
Poole, Dorset, BH15 1NX. VAT Registration Number: GB 868 861 560. This e-mail 
is confidential and for the intended recipient only. If you are not the 
intended recipient, be advised that you have received this e-mail in error and 
that any use, dissemination, forwarding, printing, or copying of this e-mail is 
prohibited. If you have received this e-mail in error, please notify the sender.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx update to v3.18

[Paul Blazejowski]

On Mon, 2015-02-16 at 08:10 +0100, John Crispin wrote:
> 
> On 16/02/2015 00:15, Paul Blazejowski wrote:
> > 00 KHz AUTO), (N/A, 2000 mBm), (0 s)
> > [   21.73] cfg80211:   (549 KHz - 573 KHz @ 16 KHz),
> > (N/A, 2000 mBm), (0 s)
> > [   21.74] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz),
> > (N/A, 2000 mBm), (N/A)
> > [   21.75] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz),
> > (N/A, 0 mBm), (N/A)
> > [   22.17] ath9k ar934x_wmac: Direct firmware load for
> > soc_wmac.eeprom failed with error -2
> > [   22.18] ath: phy0: Unable to load EEPROM file soc_wmac.eeprom
> > [   22.19] ath9k ar934x_wmac: failed to initialize device
> > [   22.19] ath9k: probe of ar934x_wmac failed with error -22
> > [   22.20] PCI: Enabling device :00:00.0 ( -> 0002)
> > [   22.22] ath9k :00:00.0: Direct firmware load for
> > pci_wmac0.eeprom failed with error -2
> > [   22.23] ath: phy1: Unable to load EEPROM file pci_wmac0.eeprom
> > [   22.23] ath9k :00:00.0: Failed to initialize device
> > [   22.24] ath9k: probe of :00:00.0 failed with error -22
> > [   29.76] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> 
> probably related to this -> https://dev.openwrt.org/ticket/18992
> 
> do a "cat /tmp/sysinfo/*" please

nope sir, just replied to your other mail...but here it is again:

root@router:~# cat /tmp/sysinfo/*
wndr3700v4
NETGEAR WNDR3700v4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[David Lang]

On Mon, 16 Feb 2015, Charlie Smurthwaite wrote:


I'm writing a driver for a family of 24 port gigabit switches, with a
wide array of interesting hardware features. Creating basic VLAN
membership and tagging functionality under the swconfig framework has
been quite easy, and this framework has been excellent for this.

However, I would like to support a lot more of the functionality of this
hardware, and see other devices with advanced layer2 and layer3
switching supported in the future, so I wanted some opinion on the
direction things are taking.

Specifically I am looking for opinion on whether the swconfig framework
is suitable for more advanced functionality, or whether there was likely
to be a move to any other upstream framework for switch devices,
particularly those with more advanced functionality. The types of
functionality I am currently interested in supporting are:

* VLAN membership an tagging
* Packet and byte counters
* Security settings and filtering rules
* STP
* Layer 3 functionality (hardware IPv4 and IPv6 routing tables)
* Hardware NAT / firewall

Some of this functionality may simply require configuration, where other
functions require the active involvement of the CPU.


A work-around for many of the items other than the basic VLAN membership and 
tagging is to force the traffic between the different switch ports to go through 
the CPU by putting the different ports on different VLANs and then using the 
kernel bridging/firewalling/etc features. You can't do this between switch ports 
that are trunked (exposeing the VLAN tags), but other than the cpu load and 
admin confusion, it works very well to just do this in the kernel. How much of 
the "functions that requrie active involvement of the CPU" end up 
being a variation of this?


I am curious as to what other switch device frameworks are out there.

It's worth noting that the vast majority of OpenWRT devices have a single switch 
in them, and that switch is typically not the fanciest (although the march of 
technology mens that every year it's going to be better than it used to be)


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

Re: [OpenWrt-Devel] ar71xx update to v3.18

[John Crispin]

On 16/02/2015 21:47, Paul Blazejowski wrote:
> On Mon, 2015-02-16 at 08:10 +0100, John Crispin wrote:
>>
>> On 16/02/2015 00:15, Paul Blazejowski wrote:
>>> 00 KHz AUTO), (N/A, 2000 mBm), (0 s)
>>> [   21.73] cfg80211:   (549 KHz - 573 KHz @ 16 KHz),
>>> (N/A, 2000 mBm), (0 s)
>>> [   21.74] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz),
>>> (N/A, 2000 mBm), (N/A)
>>> [   21.75] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz),
>>> (N/A, 0 mBm), (N/A)
>>> [   22.17] ath9k ar934x_wmac: Direct firmware load for
>>> soc_wmac.eeprom failed with error -2
>>> [   22.18] ath: phy0: Unable to load EEPROM file soc_wmac.eeprom
>>> [   22.19] ath9k ar934x_wmac: failed to initialize device
>>> [   22.19] ath9k: probe of ar934x_wmac failed with error -22
>>> [   22.20] PCI: Enabling device :00:00.0 ( -> 0002)
>>> [   22.22] ath9k :00:00.0: Direct firmware load for
>>> pci_wmac0.eeprom failed with error -2
>>> [   22.23] ath: phy1: Unable to load EEPROM file pci_wmac0.eeprom
>>> [   22.23] ath9k :00:00.0: Failed to initialize device
>>> [   22.24] ath9k: probe of :00:00.0 failed with error -22
>>> [   29.76] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>
>> probably related to this -> https://dev.openwrt.org/ticket/18992
>>
>> do a "cat /tmp/sysinfo/*" please
> 
> nope sir, just replied to your other mail...but here it is again:
> 
> root@router:~# cat /tmp/sysinfo/*
> wndr3700v4
> NETGEAR WNDR3700v4
> 

Hi Paul

looks like the WNDR3700v4 and WNDR4300 use a eeprom hack for the mac. i
have a wndr4300 in the office. will try to reproduce the bug on that
tomorrow. i'll let you know if there is anything to test.

Thanks for testing,
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Alternatives do TDMA

[bkil]

Dear Fernando,

You should have posted this question to OpenWrt-User, but I will answer it here.

I haven't personally deployed such a configuration, yet. I don't think
you can do much besides enabling RTS/CTS at every CPE (client). Much
fewer connected clients will be supported compared to a TDMA system.

However, here are some other non-default settings you could test:
* coverage class/distance optimization
* try narrow 5-10MHz channels in case of a crowded neighborhood -
sometimes less is more
* if link speed is already maxed out for the closest nodes, you may
try to reduce their tx power while maintaining the link speed and
error rate, though I wouldn't expect much effect
* after you've measured the link margin and its fading characteristic
at each of your clients, you could consider increasing the mandatory
basic_rate and mcast_rate to reduce airtime a bit more
* you could experiment with increasing the beacon interval, though
each station should already sync and avoid interference with those,
and this could reduce stability
* you may increase dtim_period a bit - again not much effect
* consider blocking most kinds of broadcast/multicast packets if your
network doesn't need it
* compared to AP mode, 802.11s mesh mode has various promising
techniques for precise node coordination and time slot reservation in
the standard which may or may not have been implemented, so you should
have a look
* RTS/CTS should be enough, but another option would be to reduce max
packet size (fragmentation threshold), which will also gravely reduce
your throughput
* you may reduce the number of retries as a last resort and hope for
the upper layers to limit rate (black magic)
...

Hardware considerations:
* use good directional or sector antennas and/or shielding at the base
to reduce noise from the surrounding buildings
* 5GHz is less crowded
* the best solution would be to insert a few intermediary nodes to
form a mesh instead of a star topology - unslotted and uncoordinated
medium access has its limits
* or at least offload the clients to multiple hotspots operated at the
same location, but using different frequencies or polarization

Note that not all options are displayed on Luci, but you could add
them to /etc/config/wireless manually (some could require capability
overrides):
http://wiki.openwrt.org/doc/uci/wireless

An interesting hack come to mind. What if we turned the situation
around? You could operate each CPE in AP mode with a very long beacon
interval. The portal (gateway) itself would operate in multi-STA.
After some u-APSD/PS-POLL tweaking, you could power save on all but
one AP similar to how it's done by default on multi-frequency
multi-STA. The portal would essentially unmute a single CPE at a time
in a round-robin fashion. It sounds a bit quirky and it would surprise
me if the solution scaled beyond a few dozen CPEs, but it would
enforce a kind of TDMA and it might theoretically eliminate collisions
without RTS/CTS if that is your thing. Bandwidth utilization and
latency would leave much to be desired, however.

I'm all into radio propagation, so please do share your views and
findings about this question.

Regards

> Hi guys,
>
>What is the best alternative to TDMA when using OpenWRT and Outdoor /
>PtMP access ? Any specific configuration to be done in OpenWRT in order
>to deal with multiple clients in different ranges ?
>
>Thanks
>Fernando
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[Charlie Smurthwaite]

Hi David,

On 16/02/15 21:03, David Lang wrote:
A work-around for many of the items other than the basic VLAN 
membership and tagging is to force the traffic between the different 
switch ports to go through the CPU by putting the different ports on 
different VLANs and then using the kernel bridging/firewalling/etc 
features. You can't do this between switch ports that are trunked 
(exposeing the VLAN tags), but other than the cpu load and admin 
confusion, it works very well to just do this in the kernel. How much 
of the "functions that requrie active involvement of the CPU" end up 
being a variation of this?


It can certainly be done this way. In fact with my current driver, I 
could give every port on the switch a different VLAN, tag them all on 
the CPU port, and do all the real work in the kernel. However this has 
one serious drawback: poor throughput. A hardware switch can easily do 
multiple Gbps, whereas the CPU can probably only handle a couple of 
hundred Mbps.


With regard to "functions that requrie active involvement of the CPU", 
this is where it gets interesting. There is a huge difference in 
performance between the kernel managing the switch's MAC address table 
(telling it which port to send a particular destination MAC address to), 
or having the CPU manage the STP port status, and caching that for a 
period of time vs sending all the packets in full through the CPU.



I am curious as to what other switch device frameworks are out there.
Specifically, there is the new "switchdev" framework which I was 
recommended to look at, and looks good, but doesn't seem to be used much 
yet, and also openvswitch, which is a little different, but may be an 
option for some purposes.


It's worth noting that the vast majority of OpenWRT devices have a 
single switch in them, and that switch is typically not the fanciest 
(although the march of technology mens that every year it's going to 
be better than it used to be)
My thought is that the switch chips in devices are quickly improving, 
with many supporting a lot of functionality that currently goes unused. 
I understand this is often because it's unnecessary in a home/office 
router, or a primarily wireless device, but I think OpenWrt is a great 
platform and a great base to work on these primarily wired devices as well.


David Lang

Thanks :)

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

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[Dirk Neukirchen]

On 16.02.2015 22:03, David Lang wrote:
> On Mon, 16 Feb 2015, Charlie Smurthwaite wrote:
> 
>> Specifically I am looking for opinion on whether the swconfig framework
>> is suitable for more advanced functionality, or whether there was likely
>> to be a move to any other upstream framework for switch devices,
>> particularly those with more advanced functionality. The types of
>> functionality I am currently interested in supporting are:
>>

> I am curious as to what other switch device frameworks are out there.
> 
> It's worth noting that the vast majority of OpenWRT devices have a single 
> switch in them, and that switch is typically not the fanciest (although the 
> march of technology mens that every year it's going to be better than it used 
> to be)
> 
> David Lang
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 

Switch/"advanced functionality" questions are resurfacing often -
many devs probably know & hate that "HW-NAT" ticket
https://dev.openwrt.org/ticket/11779

There might be 2 interesting posts regarding current/future state and
development direction of In-Kernel drivers:

1) rejected in 2013: "net: phy: add Generic Netlink switch configuration API" 
link: http://lwn.net/Articles/571390/
The thread might be of (historical)/implementation interest

That thread mentions some other infrastructure in Kernel (Marvell DSA)
(that is not appropriate for OpenWrt according to devs)

2) since November 2014 there is a new switchdev api:
introduce rocker switch driver with hardware accelerated datapath api - phase 
1: bridge fdb offload
link: http://lwn.net/Articles/619446/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[Charlie Smurthwaite]

On 16/02/15 21:34, Dirk Neukirchen wrote:

There might be 2 interesting posts regarding current/future state and
development direction of In-Kernel drivers:

1) rejected in 2013: "net: phy: add Generic Netlink switch configuration API"
link: http://lwn.net/Articles/571390/
The thread might be of (historical)/implementation interest

That thread mentions some other infrastructure in Kernel (Marvell DSA)
(that is not appropriate for OpenWrt according to devs)

2) since November 2014 there is a new switchdev api:
introduce rocker switch driver with hardware accelerated datapath api - phase 
1: bridge fdb offload
link: http://lwn.net/Articles/619446/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Thank you very much. The existence of the 'switchdev' driver / framework 
is what lead me to think about this, so I might get to work on trying it 
this way.


The hardware NAT issue seems much more complicated, as there seem to be 
a lot of questions to be answered about integration (or not) with 
netfilter. I have no particular opinion on this, and will be focusing 
100% on the layer2 functionality to begin with.


I'll look closely at the "bridge fdb offload" post you mentioned as this 
seems like a cool integration to start with.


Thanks for the links!

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

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[Michael Richardson]

First, there are a lot of discussions and papers at netdev01.org about the
various hardware switch management systems.  I point specifically to a talk
this morning:
 https://www.netdev01.org/sessions/19

I have stumbed my toe on 3800 with trying to build tagged switch ports where
I have a few ports with explicit VLAN tagging, joined together in the switch,
and also exposed to the host.  I think it should work, but I mostly just wound
up screwing up my CPU port.  I have some 3800 with serial consoles now so I
should try this out.

What would be ideal, and my impression is that this is where the industry
wants to go, is that one would use brctl and vconfig to build the switch
configuration that you want, and the drivers below would realize that the
switch can do that work, and would program things correctly.

openvswitch is about creating a virtual switch fabric in the CPU, which can
spread elsewhere --- the trend is though, that this too would be subject to
hardware offload.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[Joel Wirāmu Pauling]

I for one would love to see brctl and vconfig disappear completely in
favour of ovs-* based standard toolchain for all switch interaction.

Certainly in the Bigger iron area, and things like core and cumulus coupled
with SDN approaches and Openstack this is fast becoming defacto. I don't
see why with a bit of additional abstraction that ovs couldn't become the
default stack for mainline and certainly for OpenWRT it offers a lot more
versatility than the current brctl and vconfig tools.

I guess the biggest issue is getting ovs- offload to switch chipsets rather
than CPU bound softswitch. Maybe some sort of flag where unsupported
operations/modes which would end up being done on the CPU are
flagged/masked?

-Joel

On 16 February 2015 at 16:04, Michael Richardson  wrote:

>
> First, there are a lot of discussions and papers at netdev01.org about the
> various hardware switch management systems.  I point specifically to a talk
> this morning:
>  https://www.netdev01.org/sessions/19
>
> I have stumbed my toe on 3800 with trying to build tagged switch ports
> where
> I have a few ports with explicit VLAN tagging, joined together in the
> switch,
> and also exposed to the host.  I think it should work, but I mostly just
> wound
> up screwing up my CPU port.  I have some 3800 with serial consoles now so I
> should try this out.
>
> What would be ideal, and my impression is that this is where the industry
> wants to go, is that one would use brctl and vconfig to build the switch
> configuration that you want, and the drivers below would realize that the
> switch can do that work, and would program things correctly.
>
> openvswitch is about creating a virtual switch fabric in the CPU, which can
> spread elsewhere --- the trend is though, that this too would be subject to
> hardware offload.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[David Lang]

On Mon, 16 Feb 2015, Charlie Smurthwaite wrote:


Hi David,

On 16/02/15 21:03, David Lang wrote:
A work-around for many of the items other than the basic VLAN membership 
and tagging is to force the traffic between the different switch ports to 
go through the CPU by putting the different ports on different VLANs and 
then using the kernel bridging/firewalling/etc features. You can't do this 
between switch ports that are trunked (exposeing the VLAN tags), but other 
than the cpu load and admin confusion, it works very well to just do this 
in the kernel. How much of the "functions that requrie active involvement 
of the CPU" end up being a variation of this?


It can certainly be done this way. In fact with my current driver, I could 
give every port on the switch a different VLAN, tag them all on the CPU port, 
and do all the real work in the kernel. However this has one serious 
drawback: poor throughput. A hardware switch can easily do multiple Gbps, 
whereas the CPU can probably only handle a couple of hundred Mbps.


yep, this is a technique to be pulled out only when needed, but it's worth 
keeping in mind that you can mix this with the hardware if you don't need to do 
this between every port, you can group ports into different VLANs and use the 
CPU between them


With regard to "functions that requrie active involvement of the CPU", this 
is where it gets interesting. There is a huge difference in performance 
between the kernel managing the switch's MAC address table (telling it which 
port to send a particular destination MAC address to), or having the CPU 
manage the STP port status, and caching that for a period of time vs sending 
all the packets in full through the CPU.


how much of this functionality is exposed in the currently common switch 
chipsets?


I'm also wondering if the right answer for some of this could end up being a 
butchered version of the kernel bridging code that maintains all the 
configuration/state, but lets the hardware do the packet forwarding.



I am curious as to what other switch device frameworks are out there.
Specifically, there is the new "switchdev" framework which I was recommended 
to look at, and looks good, but doesn't seem to be used much yet, and also 
openvswitch, which is a little different, but may be an option for some 
purposes.


I've seen references to openvswitch, but I was under the impression that it 
didn't have any relationship with real hardware, it was just a way to 
configure/manage logical switches for VMs


It's worth noting that the vast majority of OpenWRT devices have a single 
switch in them, and that switch is typically not the fanciest (although the 
march of technology mens that every year it's going to be better than it 
used to be)
My thought is that the switch chips in devices are quickly improving, with 
many supporting a lot of functionality that currently goes unused. I 
understand this is often because it's unnecessary in a home/office router, or 
a primarily wireless device, but I think OpenWrt is a great platform and a 
great base to work on these primarily wired devices as well.


I think a lot of it is that there just isn't a huge amount of overlap between 
people who are experienced in dealing with complex wired environments and 
OpenWRT. I've had a lot of people dismiss the though of using OpenWRT hardware 
for things that they've traditionally used Cisco/HP switches for, but when 
desperation has forced them to give it a try, they've been very pleased with the 
results.


I'd love to see someone do a project with a small PC (Raspberry Pi or 
equivalent) that could take the cheap 8 port switches and unlock the power in 
the switch chipsets. I saw a post of someone who did this with an arduino, but 
even that was just pipeing a canned config into it. With something able to run a 
full software stack, lots of other things would become possible.


When you get your stuff working, I'd be very interested in knowing what switch 
it is you are reprogramming.


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

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[David Lang]

On Mon, 16 Feb 2015, Michael Richardson wrote:


I have stumbed my toe on 3800 with trying to build tagged switch ports where
I have a few ports with explicit VLAN tagging, joined together in the switch,
and also exposed to the host.  I think it should work, but I mostly just wound
up screwing up my CPU port.  I have some 3800 with serial consoles now so I
should try this out.


I've been using tagged and untagged switch ports on the 3800 for a few years now 
(I use them for the Scale conference and we have a rather complex wired 
infrastructure), the only problem I ran into was the issue of the ports being 
numbered backwards on the outside of the box.


For the conference, I use one port on the switch as my WAN port (trunked) and 
then configure the other three ports to specific VLANs. I configure the 'wan' 
port to be trunked as well, but generally only end up using it to daisy-chain 
another AP off of.


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

Re: [OpenWrt-Devel] General questions about the direction of switch drivers

[David Lang]

Having a more abstract way of managing this available is a nice option to have, 
but I would hate to loose the ability to set things explicitly.


Keeping in mind that we are primarily dealing with low-end devices, anything 
that requires more advanced chipsets just isn't going to happen. The chipsets 
will progress, but what gets put into the APs is going to be the cheapest swtich 
chipset that will do the job of a dumb switch. The fact that this cheapest 
chipset also happens to be able to do a lot more is a very nice bonus for us.


Remember that the vendors want to also offer the "Enterprise" APs with the 
advanced capabilities.


David Lang

On Mon, 16 Feb 2015, Joel Wirāmu Pauling wrote:


I for one would love to see brctl and vconfig disappear completely in
favour of ovs-* based standard toolchain for all switch interaction.

Certainly in the Bigger iron area, and things like core and cumulus coupled
with SDN approaches and Openstack this is fast becoming defacto. I don't
see why with a bit of additional abstraction that ovs couldn't become the
default stack for mainline and certainly for OpenWRT it offers a lot more
versatility than the current brctl and vconfig tools.

I guess the biggest issue is getting ovs- offload to switch chipsets rather
than CPU bound softswitch. Maybe some sort of flag where unsupported
operations/modes which would end up being done on the CPU are
flagged/masked?___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Alternatives do TDMA

[Fernando Frediani]

Hello bkil,

Many thanks for your detailed response.
I would gladly post it to openwrt-users if that worked, which doesn't 
seem to be the case as far as I know.


But also taking the opportunity in this devel list to ask if anyone 
worked of ever saw any work to develop a open TDMA implementation that 
could be merged to OpenWRT. I personally have read a while ago about 
some material that was developed for FreeBSD, but there wasn't much 
information really and no much other than that I could find unfortunately.


Regarding your response I was particularly interested in the RTS/CTS 
configuration and hear about optimal RTS Threshold values.
Also does that AP and Clients have to have exactly same RTS/CTS 
configuration and RTS Threshold values or only the AP is enough ?
This is more common in WISP providers, but would that be also for 
example in internal areas with many clients (e.g: a conference) where 
the clients aren't aware about having to enable the RTS/CTS protection 
and eventually the threshold ?


Regards,
Fernando

On 16/02/2015 19:24, bkil wrote:

Dear Fernando,

You should have posted this question to OpenWrt-User, but I will answer it here.

I haven't personally deployed such a configuration, yet. I don't think
you can do much besides enabling RTS/CTS at every CPE (client). Much
fewer connected clients will be supported compared to a TDMA system.

However, here are some other non-default settings you could test:
* coverage class/distance optimization
* try narrow 5-10MHz channels in case of a crowded neighborhood -
sometimes less is more
* if link speed is already maxed out for the closest nodes, you may
try to reduce their tx power while maintaining the link speed and
error rate, though I wouldn't expect much effect
* after you've measured the link margin and its fading characteristic
at each of your clients, you could consider increasing the mandatory
basic_rate and mcast_rate to reduce airtime a bit more
* you could experiment with increasing the beacon interval, though
each station should already sync and avoid interference with those,
and this could reduce stability
* you may increase dtim_period a bit - again not much effect
* consider blocking most kinds of broadcast/multicast packets if your
network doesn't need it
* compared to AP mode, 802.11s mesh mode has various promising
techniques for precise node coordination and time slot reservation in
the standard which may or may not have been implemented, so you should
have a look
* RTS/CTS should be enough, but another option would be to reduce max
packet size (fragmentation threshold), which will also gravely reduce
your throughput
* you may reduce the number of retries as a last resort and hope for
the upper layers to limit rate (black magic)
...

Hardware considerations:
* use good directional or sector antennas and/or shielding at the base
to reduce noise from the surrounding buildings
* 5GHz is less crowded
* the best solution would be to insert a few intermediary nodes to
form a mesh instead of a star topology - unslotted and uncoordinated
medium access has its limits
* or at least offload the clients to multiple hotspots operated at the
same location, but using different frequencies or polarization

Note that not all options are displayed on Luci, but you could add
them to /etc/config/wireless manually (some could require capability
overrides):
http://wiki.openwrt.org/doc/uci/wireless

An interesting hack come to mind. What if we turned the situation
around? You could operate each CPE in AP mode with a very long beacon
interval. The portal (gateway) itself would operate in multi-STA.
After some u-APSD/PS-POLL tweaking, you could power save on all but
one AP similar to how it's done by default on multi-frequency
multi-STA. The portal would essentially unmute a single CPE at a time
in a round-robin fashion. It sounds a bit quirky and it would surprise
me if the solution scaled beyond a few dozen CPEs, but it would
enforce a kind of TDMA and it might theoretically eliminate collisions
without RTS/CTS if that is your thing. Bandwidth utilization and
latency would leave much to be desired, however.

I'm all into radio propagation, so please do share your views and
findings about this question.

Regards


Hi guys,

What is the best alternative to TDMA when using OpenWRT and Outdoor /
PtMP access ? Any specific configuration to be done in OpenWRT in order
to deal with multiple clients in different ranges ?

Thanks
Fernando

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

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

Re: [OpenWrt-Devel] [Cerowrt-devel] [sqm-scripts] not started at boot?

[Sebastian Moeller]

Hi Toke, hi Alan,

On Feb 15, 2015, at 17:18 , Toke Høiland-Jørgensen  wrote:

> Sebastian Moeller  writes:
> 
>>  Not that I have shown great taste in the past, but I think it
>> would be somewhat cleaner to put the logic into the hot plug script
>> and keep run.sh “simple” (in the past I had introduced a large number
>> of leakage, especially of IFBs by not properly removing/stopping old
>> instances and was quite happy to have the take all active interfaces
>> down loop as a last defense against accidental leaks).
> 
> Well, the biggest issue I can see with not having any logic in run.sh is
> that in that case, *all* interfaces will be reconfigured when the
> hotplug event happens. However, I'm not sure exactly how common it is to
> have more than one interface configured for SQM, and if so, whether or
> not reconfiguring everything on every hotplug event (well, only for for
> SQM-enabled interfaces I suppose) is an issue.
> 
> The modifications to run.sh should keep it functioning the way it does
> currently if run 'manually' the shell or LUCI. Unless the $DEVICE
> env-var is set for some other reason...
> 
> 
>>  But I am now also running pppoe directly from cerowrt and see
>>  the same issue, sqm is confused when the pppoe interface
>>  temporarily goes away, so at least I can now test this issue ;)
> 
> Well, a first pass could be to see if the modified run.sh I sent last
> time around actually works... ;)

While I just had enough time to test this, and on my cerowrt 3.10.50-1 
this (in addition to Alan’s hotplug script) does not seem to properly restart 
SQM over a pppoe reconnect. I will need to find a bit more time to figure out 
where I misconfigured my system as I expect I should be able to recreate Alan’s 
success. But this means it will take me even longer to try to improve SQM’s 
smarts about what to restart…

Best Regards
Sebastian


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

[OpenWrt-Devel] [PATCH] linux/generic: enable open by fhandle syscalls

[Daniel Golle]

This is needed by many services to function properly and as
all modern distributions got it enabled, it starts to be a
de-facto standard.
The kernel binary size increases only a little:
On ARM systems comes down to 800 bytes uncompressed and about
200 bytes compressed size.
On MIPS systems it's about 1.2 kB size increase of the LZMA
compressed kernel.

Signed-off-by: Daniel Golle 
---
 target/linux/generic/config-3.10 | 4 ++--
 target/linux/generic/config-3.13 | 4 ++--
 target/linux/generic/config-3.14 | 4 ++--
 target/linux/generic/config-3.18 | 4 ++--
 target/linux/generic/config-3.19 | 4 ++--
 target/linux/generic/config-3.8  | 4 ++--
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/target/linux/generic/config-3.10 b/target/linux/generic/config-3.10
index 4299c57..4fa2363 100644
--- a/target/linux/generic/config-3.10
+++ b/target/linux/generic/config-3.10
@@ -829,7 +829,7 @@ CONFIG_EVENTFD=y
 # CONFIG_EWRK3 is not set
 CONFIG_EXPERIMENTAL=y
 CONFIG_EXPERT=y
-# CONFIG_EXPORTFS is not set
+CONFIG_EXPORTFS=y
 # CONFIG_EXT2_FS is not set
 # CONFIG_EXT2_FS_XATTR is not set
 # CONFIG_EXT2_FS_XIP is not set
@@ -927,7 +927,7 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
 # CONFIG_FCOE_FNIC is not set
 # CONFIG_FDDI is not set
 # CONFIG_FEALNX is not set
-# CONFIG_FHANDLE is not set
+CONFIG_FHANDLE=y
 CONFIG_FIB_RULES=y
 CONFIG_FILE_LOCKING=y
 # CONFIG_FIREWIRE is not set
diff --git a/target/linux/generic/config-3.13 b/target/linux/generic/config-3.13
index 8dff7e1..6e88c72 100644
--- a/target/linux/generic/config-3.13
+++ b/target/linux/generic/config-3.13
@@ -896,7 +896,7 @@ CONFIG_EVENTFD=y
 # CONFIG_EWRK3 is not set
 CONFIG_EXPERIMENTAL=y
 CONFIG_EXPERT=y
-# CONFIG_EXPORTFS is not set
+CONFIG_EXPORTFS=y
 # CONFIG_EXT2_FS is not set
 # CONFIG_EXT2_FS_XATTR is not set
 # CONFIG_EXT2_FS_XIP is not set
@@ -996,7 +996,7 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
 # CONFIG_FCOE_FNIC is not set
 # CONFIG_FDDI is not set
 # CONFIG_FEALNX is not set
-# CONFIG_FHANDLE is not set
+CONFIG_FHANDLE=y
 CONFIG_FIB_RULES=y
 CONFIG_FILE_LOCKING=y
 # CONFIG_FIREWIRE is not set
diff --git a/target/linux/generic/config-3.14 b/target/linux/generic/config-3.14
index 6e70ba7..a51b347 100644
--- a/target/linux/generic/config-3.14
+++ b/target/linux/generic/config-3.14
@@ -920,7 +920,7 @@ CONFIG_EVENTFD=y
 # CONFIG_EWRK3 is not set
 CONFIG_EXPERIMENTAL=y
 CONFIG_EXPERT=y
-# CONFIG_EXPORTFS is not set
+CONFIG_EXPORTFS=y
 # CONFIG_EXT2_FS is not set
 # CONFIG_EXT2_FS_XATTR is not set
 # CONFIG_EXT2_FS_XIP is not set
@@ -1021,7 +1021,7 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
 # CONFIG_FCOE_FNIC is not set
 # CONFIG_FDDI is not set
 # CONFIG_FEALNX is not set
-# CONFIG_FHANDLE is not set
+CONFIG_FHANDLE=y
 CONFIG_FIB_RULES=y
 CONFIG_FILE_LOCKING=y
 # CONFIG_FIREWIRE is not set
diff --git a/target/linux/generic/config-3.18 b/target/linux/generic/config-3.18
index 5487bdd..a7d8155 100644
--- a/target/linux/generic/config-3.18
+++ b/target/linux/generic/config-3.18
@@ -968,7 +968,7 @@ CONFIG_EVENTFD=y
 # CONFIG_EWRK3 is not set
 CONFIG_EXPERIMENTAL=y
 CONFIG_EXPERT=y
-# CONFIG_EXPORTFS is not set
+CONFIG_EXPORTFS=y
 # CONFIG_EXT2_FS is not set
 # CONFIG_EXT2_FS_XATTR is not set
 # CONFIG_EXT2_FS_XIP is not set
@@ -1070,7 +1070,7 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
 # CONFIG_FDDI is not set
 # CONFIG_FEALNX is not set
 # CONFIG_FENCE_TRACE is not set
-# CONFIG_FHANDLE is not set
+CONFIG_FHANDLE=y
 CONFIG_FIB_RULES=y
 CONFIG_FILE_LOCKING=y
 # CONFIG_FIREWIRE is not set
diff --git a/target/linux/generic/config-3.19 b/target/linux/generic/config-3.19
index a5405f4..001e4ca 100644
--- a/target/linux/generic/config-3.19
+++ b/target/linux/generic/config-3.19
@@ -974,7 +974,7 @@ CONFIG_EVENTFD=y
 # CONFIG_EWRK3 is not set
 CONFIG_EXPERIMENTAL=y
 CONFIG_EXPERT=y
-# CONFIG_EXPORTFS is not set
+CONFIG_EXPORTFS=y
 # CONFIG_EXT2_FS is not set
 # CONFIG_EXT2_FS_XATTR is not set
 # CONFIG_EXT2_FS_XIP is not set
@@ -1076,7 +1076,7 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
 # CONFIG_FDDI is not set
 # CONFIG_FEALNX is not set
 # CONFIG_FENCE_TRACE is not set
-# CONFIG_FHANDLE is not set
+CONFIG_FHANDLE=y
 CONFIG_FIB_RULES=y
 CONFIG_FILE_LOCKING=y
 # CONFIG_FIREWIRE is not set
diff --git a/target/linux/generic/config-3.8 b/target/linux/generic/config-3.8
index 343c0dd..b962315 100644
--- a/target/linux/generic/config-3.8
+++ b/target/linux/generic/config-3.8
@@ -802,7 +802,7 @@ CONFIG_EVENTFD=y
 # CONFIG_EWRK3 is not set
 CONFIG_EXPERIMENTAL=y
 CONFIG_EXPERT=y
-# CONFIG_EXPORTFS is not set
+CONFIG_EXPORTFS=y
 # CONFIG_EXT2_FS is not set
 # CONFIG_EXT2_FS_XATTR is not set
 # CONFIG_EXT2_FS_XIP is not set
@@ -897,7 +897,7 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
 # CONFIG_FCOE_FNIC is not set
 # CONFIG_FDDI is not set
 # CONFIG_FEALNX is not set
-# CONFIG_FHANDLE is not set
+CONFIG_FHANDLE=y
 CONFIG_FIB_RULES=y
 CONFIG_FILE_LOCKING=y
 # CONFIG_FIREWIRE is not set
-- 
2.3.0
___
openwr