[OpenWrt-Devel] Add support for AVM Fritzbox 7360 SL

2016-05-06 Thread Sebastian Ortwein 

Hey

I have tried do get openwrt working on my Fritzbox. Openwrt will start 
Network and VDSL Modem is working. But WLAN ist not working. The Chip is 
supported bei the ath9k driver. Any hint how I can get Wifi working ?


The board is based on a Lantiq vr9 soc.

Here are my bootlogs and patches against Openwrt.

root@OpenWrt:/# dmesg
[0.00] Linux version 4.4.7 (sebastian@sebastian-desktop) (gcc 
version 5.3.0 (OpenWrt GCC 5.3.0 r49296) ) #1 Fri May 6 22:23:36 UTC 2016

[0.00] SoC: xRX200 rev 1.1
[0.00] bootconsole [early0] enabled
[0.00] CPU0 revision is: 00019555 (MIPS 34Kc)
[0.00] MIPS: machine is FRITZ7360SL - 1&1 HomeServer
[0.00] Determined physical RAM map:
[0.00]  memory: 0800 @  (usable)
[0.00] Initrd not found or empty - disabling initrd
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x07ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x07ff]
[0.00] Initmem setup node 0 [mem 
0x-0x07ff]

[0.00] On node 0 totalpages: 32768
[0.00] free_area_init_node: node 0, pgdat 804d6390, node_mem_map 
81007a80

[0.00]   Normal zone: 256 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 32768 pages, LIFO batch:7
[0.00] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 
bytes.
[0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, 
linesize 32 bytes

[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  
Total pages: 32512

[0.00] Kernel command line: console=ttyLTQ0,115200 init=/etc/preinit
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 
bytes)

[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Writing ErrCtl register=00064202
[0.00] Readback ErrCtl register=00064202
[0.00] Memory: 123376K/131072K available (3764K kernel code, 
164K rwdata, 1144K rodata, 1184K init, 211K bss, 7696K reserved, 0K 
cma-reserved)

[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] NR_IRQS:256
[0.00] CPU Clock: 500MHz
[0.00] clocksource: MIPS: mask: 0x max_cycles: 
0x, max_idle_ns: 7645041786 ns
[0.12] sched_clock: 32 bits at 250MHz, resolution 4ns, wraps 
every 8589934590ns

[0.007862] Calibrating delay loop... 332.54 BogoMIPS (lpj=665088)
[0.042318] pid_max: default: 32768 minimum: 301
[0.047171] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.053731] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
bytes)
[0.03] clocksource: jiffies: mask: 0x max_cycles: 
0x, max_idle_ns: 764504178510 ns

[0.076441] pinctrl core: initialized pinctrl subsystem
[0.082322] NET: Registered protocol family 16
[0.091448] pinctrl-xway 1e100b10.pinmux: Init done
[0.096999] dma-xway 1e104100.dma: Init done - hw rev: 7, ports: 7, 
channels: 28

[0.206470] dcdc-xrx200 1f106a00.dcdc: Core Voltage : 1016 mV
[0.347018] usbcore: registered new interface driver usbfs
[0.352523] usbcore: registered new interface driver hub
[0.357878] usbcore: registered new device driver usb
[0.363254] PCI host bridge to bus :00
[0.367244] pci_bus :00: root bus resource [mem 
0x1c00-0x1cff]

[0.374158] pci_bus :00: root bus resource [io 0x1d80-0x1d8f]
[0.381101] pci_bus :00: root bus resource [??? 0x flags 0x0]
[0.387957] pci_bus :00: No busn resource found for root bus, 
will use [bus 00-ff]

[0.395990] pci :00:00.0: [15d1:0011] type 01 class 0x06
[0.396028] ifx_pcie_rc_class_early_fixup: fixed pcie host bridge to 
pci-pci bridge
[0.413669] ifx_pcie_fixup_resource: fixup host controller 
:00:00.0 (15d1:0011)

[0.421261] pci :00:00.0: PME# supported from D0 D3hot
[0.421831] pci :01:00.0: [168c:ff1c] type 00 class 0x02
[0.421921] pci :01:00.0: reg 0x10: [mem 0x-0x 64bit]
[0.422076] pci :01:00.0: supports D1
[0.422096] pci :01:00.0: PME# supported from D0 D1 D3hot
[0.422408] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
[0.422448] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01
[0.422506] pci :00:00.0: BAR 8: assigned [mem 0x1c00-0x1c0f]
[0.429195] pci :01:00.0: BAR 0: assigned [mem 
0x1c00-0x1c00 64bit]

[0.436557] pci :00:00.0: PCI bridge to [bus 01]
[0.441574] pci :00:00.0:   bridge window [mem 0x1c00-0x1c0f]
[0.448451] ifx_pcie_bios_map_irq port

Re: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh

2016-05-06 Thread Daniel Golle 
Hi Chun-Yeow,

On Sat, May 07, 2016 at 01:31:24AM +0800, Yeoh Chun-Yeow wrote:
> I think that it is alright if we solely depends on the wap_supplicant
> for both open mesh and secured mesh.

That would certainly work just as well, however, it would require
that people have wpa_supplicant-mesh or wpad-mesh installed even if
all they need is an unencrypted 802.11s mesh which doesn't require
that. As people might already use 802.11s unencrypted on devices
with 4megs of flash and only wpad-mini installed, that would break
their currently working use-case.
Eventhough the current way of deciding whether or not to use
wpa_supplicant (the same also applies to station mode) makes the
setup scripts a bit more complex, in my opinion it's worth that
extra complexity to at least allow basic functionality without
the overhead of running a full-blown authenticator in scenarious
where it isn't needed.

On another page, I agree that we should drop authsae in favour of
wpa_supplicant's SAE support in the long run. For now, this hasn't
happened because wpa_supplicant's SAE support received less testing
compared to authsae. The current hybrid setup allows to easily
replace one for the other, thus making regression testing trivial.

With regard to your patch, I suggest to only set HT and VHT paramters
for unencrypted networks and leave it to wpa_supplicant to set them
for encrypted ones. Once tested that setting the parameters with
authsae already running doesn't break things, setting them in that
case can also be enabled in a follow-up patch.



Cheers


Daniel

> 
> 
> Chun-Yeow
> 
> On Sat, May 7, 2016 at 1:16 AM, Daniel Golle  wrote:
> > On Sat, May 07, 2016 at 01:01:30AM +0800, Yeoh Chun-Yeow wrote:
> >> authsae and wpa_supplicant only trigger if secured mesh.
> >> wpa_supplicant should work correctly for VHT80 but don't think
> >> authsae.
> >>
> >> But this patch is intended to allow open mesh to support VHT80.
> > So maybe only enable it if $key isn't set and leave a comment in place
> > that testing is needed before enabling it for authsae and/or
> > wpa_supplicant.
> > It might well break authsae and wpa_supplicant already handles up to
> > VHT160, see
> > http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=a65efbfb243dda41518720f14724db055444bb56
> > and
> > http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=d06a35052f182d3aebc7b7e1c780cca7b386997d
> > so no need to set it here again.
> >
> >
> >>
> >> Thanks
> >>
> >> 
> >> Chun-Yeow
> >>
> >> On Sat, May 7, 2016 at 12:53 AM, Daniel Golle  
> >> wrote:
> >> > Hi Chun-Yeow,
> >> >
> >> > On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote:
> >> >> Add support of VHT80 setting for mesh interface
> >> >>
> >> >> Signed-off-by: Chun-Yeow Yeoh 
> >> >> ---
> >> >>  .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 
> >> >> +++---
> >> >>  1 file changed, 17 insertions(+), 16 deletions(-)
> >> >>
> >> >> diff --git 
> >> >> a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
> >> >> b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> >> >> index 02c195e..d680ac2 100644
> >> >> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> >> >> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> >> >> @@ -473,7 +473,7 @@ mac80211_prepare_vif() {
> >> >>   esac
> >> >>
> >> >>   case "$mode" in
> >> >> - monitor|mesh)
> >> >> + monitor)
> >> >>   [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set 
> >> >> channel "$channel" $htmode
> >> >>   ;;
> >> >>   esac
> >> >> [...]
> >> >
> >> >> @@ -566,7 +566,7 @@ mac80211_setup_adhoc() {
> >> >>   mcval=
> >> >>   [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval 
> >> >> "$mcast_rate"
> >> >>
> >> >> - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq 
> >> >> $bssid \
> >> >> + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq 
> >> >> $bssid \
> >> >>   ${beacon_int:+beacon-interval $beacon_int} \
> >> >>   ${brstr:+basic-rates $brstr} \
> >> >>   ${mcval:+mcast-rate $mcval} \
> >> >> @@ -612,7 +612,8 @@ mac80211_setup_vif() {
> >> >>   mcval=
> >> >>   [ -n "$mcast_rate" ] && 
> >> >> wpa_supplicant_add_rate mcval "$mcast_rate"
> >> >>
> >> >> - iw dev "$ifname" mesh join "$mesh_id" 
> >> >> ${mcval:+mcast-rate $mcval}
> >> >> + mac80211_setup_bss_htmode
> >> >
> >> > have you tested this with authsae AND wpa_supplicant as well?
> >> > I haven't look into it but suspect that wpa_supplicant might expect
> >> > those things to be set via its configuration file instead of using
> >> > iw dev ...
> >> >
> >> > Cheers
> >> >
> >> > Daniel
___

Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)

2016-05-06 Thread Roman Yeryomin 
On 6 May 2016 at 21:43, Roman Yeryomin  wrote:
> On 6 May 2016 at 15:47, Jesper Dangaard Brouer  wrote:
>>
>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2]
>> closed Felix'es OpenWRT email account (bad choice! emails bouncing).
>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project
>> is in some kind of conflict.
>>
>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349
>>
>> [2] 
>> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335
>
> OK, so, after porting the patch to 4.1 openwrt kernel and playing a
> bit with fq_codel limits I was able to get 420Mbps UDP like this:
> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256

Forgot to mention, I've reduced drop_batch_size down to 32

> This is certainly better than 30Mbps but still more than two times
> less than before (900).
> TCP also improved a little (550 to ~590).
>
> Felix, others, do you want to see the ported patch, maybe I did something 
> wrong?
> Doesn't look like it will save ath10k from performance regression.
>
>>
>> On Fri, 6 May 2016 11:42:43 +0200
>> Jesper Dangaard Brouer  wrote:
>>
>>> Hi Felix,
>>>
>>> This is an important fix for OpenWRT, please read!
>>>
>>> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024,
>>> without also adjusting q->flows_cnt.  Eric explains below that you must
>>> also adjust the buckets (q->flows_cnt) for this not to break. (Just
>>> adjust it to 128)
>>>
>>> Problematic OpenWRT commit in question:
>>>  http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e
>>>  12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from 
>>> causing too much cpu load with higher speed (#21326)")
>>>
>>>
>>> I also highly recommend you cherry-pick this very recent commit:
>>>  net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()")
>>>  https://git.kernel.org/davem/net-next/c/9d18562a227
>>>
>>> This should fix very high CPU usage in-case fq_codel goes into drop mode.
>>> The problem is that drop mode was considered rare, and implementation
>>> wise it was chosen to be more expensive (to save cycles on normal mode).
>>> Unfortunately is it easy to trigger with an UDP flood. Drop mode is
>>> especially expensive for smaller devices, as it scans a 4K big array,
>>> thus 64 cache misses for small devices!
>>>
>>> The fix is to allow drop-mode to bulk-drop more packets when entering
>>> drop-mode (default 64 bulk drop).  That way we don't suddenly
>>> experience a significantly higher processing cost per packet, but
>>> instead can amortize this.
>>>
>>> To Eric, should we recommend OpenWRT to adjust default (max) 64 bulk
>>> drop, given we also recommend bucket size to be 128 ? (thus the amount
>>> of memory to scan is less, but their CPU is also much smaller).
>>>
>>> --Jesper
>>>
>>>
>>> On Thu, 05 May 2016 12:23:27 -0700 Eric Dumazet  
>>> wrote:
>>>
>>> > On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote:
>>> > > On 5 May 2016 at 19:12, Eric Dumazet  wrote:
>>> > > > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote:
>>> > > >
>>> > > >>
>>> > > >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>>> > > >> quantum 1514 target 5.0ms interval 100.0ms ecn
>>> > > >>  Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0)
>>> > > >>  backlog 0b 0p requeues 0
>>> > > >>   maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>> > > >>   new_flows_len 0 old_flows_len 0
>>> > > >
>>> > > >
>>> > > > Limit of 1024 packets and 1024 flows is not wise I think.
>>> > > >
>>> > > > (If all buckets are in use, each bucket has a virtual queue of 1 
>>> > > > packet,
>>> > > > which is almost the same than having no queue at all)
>>> > > >
>>> > > > I suggest to have at least 8 packets per bucket, to let Codel have a
>>> > > > chance to trigger.
>>> > > >
>>> > > > So you could either reduce number of buckets to 128 (if memory is
>>> > > > tight), or increase limit to 8192.
>>> > >
>>> > > Will try, but what I've posted is default, I didn't change/configure 
>>> > > that.
>>> >
>>> > fq_codel has a default of 10240 packets and 1024 buckets.
>>> >
>>> > http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413
>>> >
>>> > If someone changed that in the linux variant you use, he probably should
>>> > explain the rationale.
>>
>> --
>> Best regards,
>>   Jesper Dangaard Brouer
>>   MSc.CS, Principal Kernel Engineer at Red Hat
>>   Author of http://www.iptv-analyzer.org
>>   LinkedIn: http://www.linkedin.com/in/brouer
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)

2016-05-06 Thread Roman Yeryomin 
On 6 May 2016 at 15:47, Jesper Dangaard Brouer  wrote:
>
> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2]
> closed Felix'es OpenWRT email account (bad choice! emails bouncing).
> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project
> is in some kind of conflict.
>
> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349
>
> [2] 
> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335

OK, so, after porting the patch to 4.1 openwrt kernel and playing a
bit with fq_codel limits I was able to get 420Mbps UDP like this:
tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256

This is certainly better than 30Mbps but still more than two times
less than before (900).
TCP also improved a little (550 to ~590).

Felix, others, do you want to see the ported patch, maybe I did something wrong?
Doesn't look like it will save ath10k from performance regression.

>
> On Fri, 6 May 2016 11:42:43 +0200
> Jesper Dangaard Brouer  wrote:
>
>> Hi Felix,
>>
>> This is an important fix for OpenWRT, please read!
>>
>> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024,
>> without also adjusting q->flows_cnt.  Eric explains below that you must
>> also adjust the buckets (q->flows_cnt) for this not to break. (Just
>> adjust it to 128)
>>
>> Problematic OpenWRT commit in question:
>>  http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e
>>  12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from 
>> causing too much cpu load with higher speed (#21326)")
>>
>>
>> I also highly recommend you cherry-pick this very recent commit:
>>  net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()")
>>  https://git.kernel.org/davem/net-next/c/9d18562a227
>>
>> This should fix very high CPU usage in-case fq_codel goes into drop mode.
>> The problem is that drop mode was considered rare, and implementation
>> wise it was chosen to be more expensive (to save cycles on normal mode).
>> Unfortunately is it easy to trigger with an UDP flood. Drop mode is
>> especially expensive for smaller devices, as it scans a 4K big array,
>> thus 64 cache misses for small devices!
>>
>> The fix is to allow drop-mode to bulk-drop more packets when entering
>> drop-mode (default 64 bulk drop).  That way we don't suddenly
>> experience a significantly higher processing cost per packet, but
>> instead can amortize this.
>>
>> To Eric, should we recommend OpenWRT to adjust default (max) 64 bulk
>> drop, given we also recommend bucket size to be 128 ? (thus the amount
>> of memory to scan is less, but their CPU is also much smaller).
>>
>> --Jesper
>>
>>
>> On Thu, 05 May 2016 12:23:27 -0700 Eric Dumazet  
>> wrote:
>>
>> > On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote:
>> > > On 5 May 2016 at 19:12, Eric Dumazet  wrote:
>> > > > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote:
>> > > >
>> > > >>
>> > > >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>> > > >> quantum 1514 target 5.0ms interval 100.0ms ecn
>> > > >>  Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0)
>> > > >>  backlog 0b 0p requeues 0
>> > > >>   maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>> > > >>   new_flows_len 0 old_flows_len 0
>> > > >
>> > > >
>> > > > Limit of 1024 packets and 1024 flows is not wise I think.
>> > > >
>> > > > (If all buckets are in use, each bucket has a virtual queue of 1 
>> > > > packet,
>> > > > which is almost the same than having no queue at all)
>> > > >
>> > > > I suggest to have at least 8 packets per bucket, to let Codel have a
>> > > > chance to trigger.
>> > > >
>> > > > So you could either reduce number of buckets to 128 (if memory is
>> > > > tight), or increase limit to 8192.
>> > >
>> > > Will try, but what I've posted is default, I didn't change/configure 
>> > > that.
>> >
>> > fq_codel has a default of 10240 packets and 1024 buckets.
>> >
>> > http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413
>> >
>> > If someone changed that in the linux variant you use, he probably should
>> > explain the rationale.
>
> --
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   Author of http://www.iptv-analyzer.org
>   LinkedIn: http://www.linkedin.com/in/brouer
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Guest who is using openwrt (was Fwd: Build failed in Jenkins: PandoraBoxFireware » PandoraBox_Build_Beta » MT7628,Linux #14)

2016-05-06 Thread Daniel Dickinson 
Hi List,

For your amusement.  Anyone want to PandoraBox is using OpenWrt ;-)

(That is I have no affilation with PandoraBox; their CI screwed up).

Regards,

Daniel


 Forwarded Message 
Subject: Build failed in Jenkins: PandoraBoxFireware »
PandoraBox_Build_Beta » MT7628,Linux #14
Date: Sat, 7 May 2016 01:23:20 +0800 (CST)
From: Pandorabox Continuous Integration 
To: Lintel , Shawn , j...@mein.io,
arylo.o...@gmail.com, hannu.ny...@iki.fi,
christian.schoeneb...@gmail.com, open...@daniel.thecshore.com,
luca.deberna...@gmail.com, banglang.hu...@foxmail.com,
freif...@it-solutions.geroedel.de, ke...@koconnor.net

See


Changes:

[kevin] luci-mod-admin-full: Add option to set anonymous_identity field

[openwrt] luci-base: utils: Make checklib return a boolean

[christian.schoenebeck] fix problem not correctly handling "Bind
Network" field

[hannu.nyman] luci-app-transmission: remove dependency on
transmission-daemon

[hannu.nyman] luci-base: read odhcpd leasefile location via uci

[luca.debernardi] luci-mod-admin-full: fix wrong dsl stats visualization

[jo] luci-base: fix luci.model.network.ignore_interface()

[jo] luci-base: add more ignore patterns to luci.model.network

[jo] luci-base: fix syntax error in luci.model.network

[hannu.nyman] luci-app-adblock: match adblock 1.1.0

[hannu.nyman] luci-app-adblock: adjust to change in option name

[hannu.nyman] i18n: sync translations

[hannu.nyman] luci-mod-admin-full: dnsmasq options quietdhcp and
sequential_ip

[freifunk] freifunk-profiles: remove depreciated profiles

--
[...truncated 280325 lines...]
 #define __NR_recvmmsg   (__NR_Linux + 335)
 ^
In file included from
/mnt/sdb:24:0,
 from
/mnt/sdb:22,
 from
/mnt/sdb:61,
 from util/util.h:58,
 from tests/dso-data.c:1:
/mnt/sdb:1017:0:
note: this is the location of the previous definition
 #define __NR_recvmmsg (4000 + 335)
 ^
In file included from util/../perf.h:4:0,
 from util/symbol.h:8,
 from tests/dso-data.c:10:
/mnt/sdb:359:0:
warning: "__NR_fanotify_init" redefined [enabled by default]
 #define __NR_fanotify_init  (__NR_Linux + 336)
 ^
In file included from
/mnt/sdb:24:0,
 from
/mnt/sdb:22,
 from
/mnt/sdb:61,
 from util/util.h:58,
 from tests/dso-data.c:1:
/mnt/sdb:1020:0:
note: this is the location of the previous definition
 #define __NR_fanotify_init (4000 + 336)
 ^
In file included from util/../perf.h:4:0,
 from util/symbol.h:8,
 from tests/dso-data.c:10:
/mnt/sdb:360:0:
warning: "__NR_fanotify_mark" redefined [enabled by default]
 #define __NR_fanotify_mark  (__NR_Linux + 337)
 ^
In file included from

Re: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh

2016-05-06 Thread Yeoh Chun-Yeow 
I think that it is alright if we solely depends on the wap_supplicant
for both open mesh and secured mesh.


Chun-Yeow

On Sat, May 7, 2016 at 1:16 AM, Daniel Golle  wrote:
> On Sat, May 07, 2016 at 01:01:30AM +0800, Yeoh Chun-Yeow wrote:
>> authsae and wpa_supplicant only trigger if secured mesh.
>> wpa_supplicant should work correctly for VHT80 but don't think
>> authsae.
>>
>> But this patch is intended to allow open mesh to support VHT80.
> So maybe only enable it if $key isn't set and leave a comment in place
> that testing is needed before enabling it for authsae and/or
> wpa_supplicant.
> It might well break authsae and wpa_supplicant already handles up to
> VHT160, see
> http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=a65efbfb243dda41518720f14724db055444bb56
> and
> http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=d06a35052f182d3aebc7b7e1c780cca7b386997d
> so no need to set it here again.
>
>
>>
>> Thanks
>>
>> 
>> Chun-Yeow
>>
>> On Sat, May 7, 2016 at 12:53 AM, Daniel Golle  wrote:
>> > Hi Chun-Yeow,
>> >
>> > On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote:
>> >> Add support of VHT80 setting for mesh interface
>> >>
>> >> Signed-off-by: Chun-Yeow Yeoh 
>> >> ---
>> >>  .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 
>> >> +++---
>> >>  1 file changed, 17 insertions(+), 16 deletions(-)
>> >>
>> >> diff --git 
>> >> a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
>> >> b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
>> >> index 02c195e..d680ac2 100644
>> >> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
>> >> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
>> >> @@ -473,7 +473,7 @@ mac80211_prepare_vif() {
>> >>   esac
>> >>
>> >>   case "$mode" in
>> >> - monitor|mesh)
>> >> + monitor)
>> >>   [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set 
>> >> channel "$channel" $htmode
>> >>   ;;
>> >>   esac
>> >> [...]
>> >
>> >> @@ -566,7 +566,7 @@ mac80211_setup_adhoc() {
>> >>   mcval=
>> >>   [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate"
>> >>
>> >> - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq 
>> >> $bssid \
>> >> + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq 
>> >> $bssid \
>> >>   ${beacon_int:+beacon-interval $beacon_int} \
>> >>   ${brstr:+basic-rates $brstr} \
>> >>   ${mcval:+mcast-rate $mcval} \
>> >> @@ -612,7 +612,8 @@ mac80211_setup_vif() {
>> >>   mcval=
>> >>   [ -n "$mcast_rate" ] && 
>> >> wpa_supplicant_add_rate mcval "$mcast_rate"
>> >>
>> >> - iw dev "$ifname" mesh join "$mesh_id" 
>> >> ${mcval:+mcast-rate $mcval}
>> >> + mac80211_setup_bss_htmode
>> >
>> > have you tested this with authsae AND wpa_supplicant as well?
>> > I haven't look into it but suspect that wpa_supplicant might expect
>> > those things to be set via its configuration file instead of using
>> > iw dev ...
>> >
>> > Cheers
>> >
>> > Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh

2016-05-06 Thread Daniel Golle 
On Sat, May 07, 2016 at 01:01:30AM +0800, Yeoh Chun-Yeow wrote:
> authsae and wpa_supplicant only trigger if secured mesh.
> wpa_supplicant should work correctly for VHT80 but don't think
> authsae.
> 
> But this patch is intended to allow open mesh to support VHT80.
So maybe only enable it if $key isn't set and leave a comment in place
that testing is needed before enabling it for authsae and/or
wpa_supplicant.
It might well break authsae and wpa_supplicant already handles up to
VHT160, see
http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=a65efbfb243dda41518720f14724db055444bb56
and
http://w1.fi/cgit/hostap/commit/wpa_supplicant/mesh.c?id=d06a35052f182d3aebc7b7e1c780cca7b386997d
so no need to set it here again.


> 
> Thanks
> 
> 
> Chun-Yeow
> 
> On Sat, May 7, 2016 at 12:53 AM, Daniel Golle  wrote:
> > Hi Chun-Yeow,
> >
> > On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote:
> >> Add support of VHT80 setting for mesh interface
> >>
> >> Signed-off-by: Chun-Yeow Yeoh 
> >> ---
> >>  .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 
> >> +++---
> >>  1 file changed, 17 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
> >> b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> >> index 02c195e..d680ac2 100644
> >> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> >> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> >> @@ -473,7 +473,7 @@ mac80211_prepare_vif() {
> >>   esac
> >>
> >>   case "$mode" in
> >> - monitor|mesh)
> >> + monitor)
> >>   [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set 
> >> channel "$channel" $htmode
> >>   ;;
> >>   esac
> >> [...]
> >
> >> @@ -566,7 +566,7 @@ mac80211_setup_adhoc() {
> >>   mcval=
> >>   [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate"
> >>
> >> - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq 
> >> $bssid \
> >> + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq 
> >> $bssid \
> >>   ${beacon_int:+beacon-interval $beacon_int} \
> >>   ${brstr:+basic-rates $brstr} \
> >>   ${mcval:+mcast-rate $mcval} \
> >> @@ -612,7 +612,8 @@ mac80211_setup_vif() {
> >>   mcval=
> >>   [ -n "$mcast_rate" ] && 
> >> wpa_supplicant_add_rate mcval "$mcast_rate"
> >>
> >> - iw dev "$ifname" mesh join "$mesh_id" 
> >> ${mcval:+mcast-rate $mcval}
> >> + mac80211_setup_bss_htmode
> >
> > have you tested this with authsae AND wpa_supplicant as well?
> > I haven't look into it but suspect that wpa_supplicant might expect
> > those things to be set via its configuration file instead of using
> > iw dev ...
> >
> > Cheers
> >
> > Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh

2016-05-06 Thread Yeoh Chun-Yeow 
authsae and wpa_supplicant only trigger if secured mesh.
wpa_supplicant should work correctly for VHT80 but don't think
authsae.

But this patch is intended to allow open mesh to support VHT80.

Thanks


Chun-Yeow

On Sat, May 7, 2016 at 12:53 AM, Daniel Golle  wrote:
> Hi Chun-Yeow,
>
> On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote:
>> Add support of VHT80 setting for mesh interface
>>
>> Signed-off-by: Chun-Yeow Yeoh 
>> ---
>>  .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 
>> +++---
>>  1 file changed, 17 insertions(+), 16 deletions(-)
>>
>> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
>> b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
>> index 02c195e..d680ac2 100644
>> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
>> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
>> @@ -473,7 +473,7 @@ mac80211_prepare_vif() {
>>   esac
>>
>>   case "$mode" in
>> - monitor|mesh)
>> + monitor)
>>   [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set 
>> channel "$channel" $htmode
>>   ;;
>>   esac
>> [...]
>
>> @@ -566,7 +566,7 @@ mac80211_setup_adhoc() {
>>   mcval=
>>   [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate"
>>
>> - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq 
>> $bssid \
>> + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq $bssid 
>> \
>>   ${beacon_int:+beacon-interval $beacon_int} \
>>   ${brstr:+basic-rates $brstr} \
>>   ${mcval:+mcast-rate $mcval} \
>> @@ -612,7 +612,8 @@ mac80211_setup_vif() {
>>   mcval=
>>   [ -n "$mcast_rate" ] && 
>> wpa_supplicant_add_rate mcval "$mcast_rate"
>>
>> - iw dev "$ifname" mesh join "$mesh_id" 
>> ${mcval:+mcast-rate $mcval}
>> + mac80211_setup_bss_htmode
>
> have you tested this with authsae AND wpa_supplicant as well?
> I haven't look into it but suspect that wpa_supplicant might expect
> those things to be set via its configuration file instead of using
> iw dev ...
>
> Cheers
>
> Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh

2016-05-06 Thread Daniel Golle 
Hi Chun-Yeow,

On Sat, May 07, 2016 at 12:35:17AM +0800, Chun-Yeow Yeoh wrote:
> Add support of VHT80 setting for mesh interface
> 
> Signed-off-by: Chun-Yeow Yeoh 
> ---
>  .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 
> +++---
>  1 file changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
> b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> index 02c195e..d680ac2 100644
> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> @@ -473,7 +473,7 @@ mac80211_prepare_vif() {
>   esac
> 
>   case "$mode" in
> - monitor|mesh)
> + monitor)
>   [ "$auto_channel" -gt 0 ] || iw dev "$ifname" set 
> channel "$channel" $htmode
>   ;;
>   esac
> [...]

> @@ -566,7 +566,7 @@ mac80211_setup_adhoc() {
>   mcval=
>   [ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate"
> 
> - iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq $bssid 
> \
> + iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq $bssid \
>   ${beacon_int:+beacon-interval $beacon_int} \
>   ${brstr:+basic-rates $brstr} \
>   ${mcval:+mcast-rate $mcval} \
> @@ -612,7 +612,8 @@ mac80211_setup_vif() {
>   mcval=
>   [ -n "$mcast_rate" ] && wpa_supplicant_add_rate 
> mcval "$mcast_rate"
> 
> - iw dev "$ifname" mesh join "$mesh_id" 
> ${mcval:+mcast-rate $mcval}
> + mac80211_setup_bss_htmode

have you tested this with authsae AND wpa_supplicant as well?
I haven't look into it but suspect that wpa_supplicant might expect
those things to be set via its configuration file instead of using
iw dev ...

Cheers

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

[OpenWrt-Devel] [PATCH] mac80211.sh: add support of VHT80 for mesh

2016-05-06 Thread Chun-Yeow Yeoh 
Add support of VHT80 setting for mesh interface

Signed-off-by: Chun-Yeow Yeoh 
---
 .../mac80211/files/lib/netifd/wireless/mac80211.sh | 33 +++---
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 02c195e..d680ac2 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -473,7 +473,7 @@ mac80211_prepare_vif() {
esac

case "$mode" in
-   monitor|mesh)
+   monitor)
[ "$auto_channel" -gt 0 ] || iw dev "$ifname" set 
channel "$channel" $htmode
;;
esac
@@ -495,40 +495,40 @@ mac80211_setup_supplicant() {
wpa_supplicant_run "$ifname" ${hostapd_ctrl:+-H $hostapd_ctrl}
 }

-mac80211_setup_adhoc_htmode() {
+mac80211_setup_bss_htmode() {
case "$htmode" in
-   VHT20|HT20) ibss_htmode=HT20;;
+   VHT20|HT20) bss_htmode=HT20;;
HT40*|VHT40|VHT160)
case "$hwmode" in
a)
case "$(( ($channel / 4) % 2 ))" in
-   1) ibss_htmode="HT40+" ;;
-   0) ibss_htmode="HT40-";;
+   1) bss_htmode="HT40+" ;;
+   0) bss_htmode="HT40-";;
esac
;;
*)
case "$htmode" in
-   HT40+) ibss_htmode="HT40+";;
-   HT40-) ibss_htmode="HT40-";;
+   HT40+) bss_htmode="HT40+";;
+   HT40-) bss_htmode="HT40-";;
*)
if [ "$channel" -lt 7 
]; then
-   
ibss_htmode="HT40+"
+   
bss_htmode="HT40+"
else
-   
ibss_htmode="HT40-"
+   
bss_htmode="HT40-"
fi
;;
esac
;;
esac
-   [ "$auto_channel" -gt 0 ] && ibss_htmode="HT40+"
+   [ "$auto_channel" -gt 0 ] && bss_htmode="HT40+"
;;
VHT80)
-   ibss_htmode="80MHZ"
+   bss_htmode="80MHZ"
;;
NONE|NOHT)
-   ibss_htmode="NOHT"
+   bss_htmode="NOHT"
;;
-   *) ibss_htmode="" ;;
+   *) bss_htmode="" ;;
esac

 }
@@ -566,7 +566,7 @@ mac80211_setup_adhoc() {
mcval=
[ -n "$mcast_rate" ] && wpa_supplicant_add_rate mcval "$mcast_rate"

-   iw dev "$ifname" ibss join "$ssid" $freq $ibss_htmode fixed-freq $bssid 
\
+   iw dev "$ifname" ibss join "$ssid" $freq $bss_htmode fixed-freq $bssid \
${beacon_int:+beacon-interval $beacon_int} \
${brstr:+basic-rates $brstr} \
${mcval:+mcast-rate $mcval} \
@@ -612,7 +612,8 @@ mac80211_setup_vif() {
mcval=
[ -n "$mcast_rate" ] && wpa_supplicant_add_rate 
mcval "$mcast_rate"

-   iw dev "$ifname" mesh join "$mesh_id" 
${mcval:+mcast-rate $mcval}
+   mac80211_setup_bss_htmode
+   iw dev "$ifname" mesh join "$mesh_id" freq 
"$freq" "$bss_htmode" ${mcval:+mcast-rate $mcval}
fi

for var in $MP_CONFIG_INT $MP_CONFIG_BOOL 
$MP_CONFIG_STRING; do
@@ -622,7 +623,7 @@ mac80211_setup_vif() {
;;
adhoc)
wireless_vif_parse_encryption
-   mac80211_setup_adhoc_htmode
+   mac80211_setup_bss_htmode
if [ "$wpa" -gt 0 -o "$auto_channel" -gt 0 ]; then
mac80211_setup_supplicant || failed=1
else
--
2.3.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: add WT3020 with 16MB flash

2016-05-06 Thread Dmitry Antonov 
A little HW-mod applied to WT3020 makes it more usable.

Some people can buy it and need an updated OpenWRT.


Signed-off-by: Dmitry Antonov 
---

diff --git a/openwrt_wt3020-16MB/target/linux/ramips/dts/WT3020-16M.dts
b/openwrt_wt3020-16MB/target/linux/ramips/dts/WT3020-16M.dts
new file mode 100644
index 000..ff13560
--- /dev/null
+++ b/openwrt_wt3020-16MB/target/linux/ramips/dts/WT3020-16M.dts
@@ -0,0 +1,102 @@
+/dts-v1/;
+
+/include/ "mt7620n.dtsi"
+
+/ {
+   compatible = "wt3020", "ralink,mt7620n-soc";
+   model = "Nexx WT3020";
+
+   palmbus@1000 {
+   gpio2: gpio@660 {
+   status = "okay";
+   };
+
+   gpio3: gpio@688 {
+   status = "okay";
+   };
+
+   spi@b00 {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <0 0>;
+   linux,modalias = "m25p80", "w25q128";
+   spi-max-frequency = <1000>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0xfb>;
+   };
+   };
+   };
+   };
+
+   ehci@101c {
+   status = "okay";
+   };
+
+   ohci@101c1000 {
+   status = "okay";
+   };
+
+   ethernet@1010 {
+   mtd-mac-address = < 0x4>;
+   mediatek,portmap = "w";
+   };
+
+   wmac@1018 {
+   ralink,mtd-eeprom = < 0>;
+   };
+
+   pinctrl {
+   state_default: pinctrl0 {
+   default {
+   ralink,group = "ephy", "wled", "pa", "i2c", 
"wdt", "uartf";
+   ralink,function = "gpio";
+   };
+   };
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+
+   reset {
+   label = "reset";
+   gpios = < 1 1>;
+   linux,code = <0x198>;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   power {
+   label = "wt3020:blue:power";
+   gpios = < 0 0>;
+   };
+   };
+};
diff --git a/openwrt/target/linux/ramips/image/Makefile
b/openwrt_wt3020-16MB/target/linux/ramips/image/Makefile
index 6e0349f..1d78c86 100644
--- a/openwrt/target/linux/ramips/image/Makefile
+++ b/openwrt_wt3020-16MB/target/linux/ramips/image/Makefile
@@ -145,24 +145,28 @@ endef
 # $(1) = squashfs/initramfs
 # $(2) = lowercase board name
 # $(3) = dts file
+# $(4) = uImage header name field
 ralink_default_fw_size_4M=3866624
 BuildFirmware/Default4M/squashfs=$(call
BuildFirmware/OF,$(1),$(2),$(3),$(ralink_default_fw_size_4M),$(4))
 BuildFirmware/Default4M/initramfs=$(call
BuildFirmware/OF/initramfs,$(1),$(2),$(3),$(4))

 # Build images for default ralink layout for 8MB flash
 # kernel + roots = 0x7b
-# $(1) = squashfs/initramfs
-# $(2) = lowercase board name
-# $(3) = dts file
-# $(4) = uImage header name field
+# parameters' descriptions the same as "... for 4MB flash"
 ralink_default_fw_size_8M=8060928
 BuildFirmware/Default8M/squashfs=$(call
BuildFirmware/OF,$(1),$(2),$(3),$(ralink_default_fw_size_8M),$(4))
 BuildFirmware/Default8M/initramfs=$(call
BuildFirmware/OF/initramfs,$(1),$(2),$(3),$(4))

-ralink_default_fw_size_16M=16121856
+# Build images for default ralink layout for 16MB flash
+# kernel + roots = 0xfb
+# parameters' descriptions the same as "... for 4MB flash"
+ralink_default_fw_size_16M=16449536
 BuildFirmware/Default16M/squashfs=$(call
BuildFirmware/OF,$(1),$(2),$(3),$(ralink_default_fw_size_16M),$(4))

Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-06 Thread Daniel Dickinson 
On 16-05-06 07:53 AM, Imre Kaloz wrote:
> On Thu, 05 May 2016 18:24:09 +0200, Daniel Dickinson
>  wrote:
> 
>> On 16-05-05 12:21 PM, Jonathan Bennett wrote:
>> [snip]
>>> > The changes that the Lede guys are suggesting would be welcome,
>>> but
>>> > splitting the project and community with an ugly fork is very
>>> much not
>>> > welcome.
>>>
>>> Let's just say that there are strong personalities who haven't been
>>> working well together and that this has been a long time coming;
>>> perhaps
>>> if something like using a mediator had been considered before
>>> things got
>>> to this point it would have helped.  At this point I'm not sure
>>> there is a
>>> solution unless both sides are willing to bend a little (I'm
>>> really not
>>> sure who has been flexible and who has not, but as I have said I
>>> suspect
>>> a large part of the issue is that 'management' (who aren't and
>>> don't,
>>> really) has overruled those doing the majority of the work and in an
>>> open source project that doesn't fly).
>>>
>>> I don't disagree.  I just see the current state of Openwrt/Lede as a
>>> mess for the community.
>>
>> I agree, I just don't see how the LEDE team could have avoided it
>> without giving up and accepting the broken status quo.
> 
> I hope you realize the LEDE team created most of that status quo.

In part that is why I came to my senses and realized that in my attempts
to understand the situation and make sense if it with insufficient
information that I made guesses and had impressions that may not be
accurate, and that calmer headers needed to prevail.

I am not totally convinced that LEDE is really going to be different,
for this very reason.  As I've said elsewhere, at this point time is
what will show the truth or falsehood of the claims made.

Regards,

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

[OpenWrt-Devel] Apology (was Re: Introducing the LEDE project)

2016-05-06 Thread Daniel Dickinson 
Hi Imre,

I'm doing this a lot lately.  I'm sorry for publicly making guesses,
stating impressions that were not fair to you.  I do not know what the
truth is and trying divine the information with the little information I
have doesn't work, and is not fair.

Sorry.

Regards,

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

[OpenWrt-Devel] [PATCH] mtd: add -c option for specifying amount of data to be used for checksum

2016-05-06 Thread Rafał Miłecki 
So far fixtrx was calculating checksum over amount of data matching
partition erase size. It was mostly a workaround of checksum problem
after changing anything in initial TRX content (e.g. formatting JFFS2).
Its main purpose was to make bootloader accept modified TRX. This didn't
provide much protection of flash data against corruption.

This new option lets caller request calculating checksum over a bigger
amount of data. It may be used e.g. to include whole kernel data for
checksum and hopefully make bootloader go info failsafe mode if
something goes wrong.

Signed-off-by: Rafał Miłecki 
---
 package/system/mtd/src/mtd.c | 16 +---
 package/system/mtd/src/mtd.h |  2 +-
 package/system/mtd/src/trx.c | 21 -
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/package/system/mtd/src/mtd.c b/package/system/mtd/src/mtd.c
index dae0514..f206c4f 100644
--- a/package/system/mtd/src/mtd.c
+++ b/package/system/mtd/src/mtd.c
@@ -737,6 +737,8 @@ static void usage(void)
if (mtd_fixtrx) {
fprintf(stderr,
"-o offset   offset of the image header in the 
partition(for fixtrx)\n");
+   fprintf(stderr,
+   "-c datasize amount of data to be used for checksum 
calculation (for fixtrx)\n");
}
fprintf(stderr,
 #ifdef FIS_SUPPORT
@@ -769,7 +771,7 @@ int main (int argc, char **argv)
int ch, i, boot, imagefd = 0, force, unlocked;
char *erase[MAX_ARGS], *device = NULL;
char *fis_layout = NULL;
-   size_t offset = 0, part_offset = 0, dump_len = 0;
+   size_t offset = 0, datasize = 0, part_offset = 0, dump_len = 0;
enum {
CMD_ERASE,
CMD_WRITE,
@@ -793,7 +795,7 @@ int main (int argc, char **argv)
 #ifdef FIS_SUPPORT
"F:"
 #endif
-   "frnqe:d:s:j:p:o:l:")) != -1)
+   "frnqe:d:s:j:p:o:c:l:")) != -1)
switch (ch) {
case 'f':
force = 1;
@@ -853,6 +855,14 @@ int main (int argc, char **argv)
usage();
}
break;
+   case 'c':
+   errno = 0;
+   datasize = strtoul(optarg, 0, 0);
+   if (errno) {
+   fprintf(stderr, "-d: illegal numeric 
string\n");
+   usage();
+   }
+   break;
 #ifdef FIS_SUPPORT
case 'F':
fis_layout = optarg;
@@ -967,7 +977,7 @@ int main (int argc, char **argv)
break;
case CMD_FIXTRX:
if (mtd_fixtrx) {
-   mtd_fixtrx(device, offset);
+   mtd_fixtrx(device, offset, datasize);
 }
case CMD_RESETBC:
if (mtd_resetbc) {
diff --git a/package/system/mtd/src/mtd.h b/package/system/mtd/src/mtd.h
index 751b0d0..52074fc 100644
--- a/package/system/mtd/src/mtd.h
+++ b/package/system/mtd/src/mtd.h
@@ -25,7 +25,7 @@ extern void mtd_parse_jffs2data(const char *buf, const char 
*dir);
 /* target specific functions */
 extern int trx_fixup(int fd, const char *name)  __attribute__ ((weak));
 extern int trx_check(int imagefd, const char *mtd, char *buf, int *len) 
__attribute__ ((weak));
-extern int mtd_fixtrx(const char *mtd, size_t offset) __attribute__ ((weak));
+extern int mtd_fixtrx(const char *mtd, size_t offset, size_t datasize) 
__attribute__ ((weak));
 extern int mtd_fixseama(const char *mtd, size_t offset) __attribute__ ((weak));
 extern int mtd_resetbc(const char *mtd) __attribute__ ((weak));
 #endif /* __mtd_h */
diff --git a/package/system/mtd/src/trx.c b/package/system/mtd/src/trx.c
index 00c4d6c..2a41e0f 100644
--- a/package/system/mtd/src/trx.c
+++ b/package/system/mtd/src/trx.c
@@ -148,7 +148,7 @@ trx_check(int imagefd, const char *mtd, char *buf, int *len)
 #endif
 
 int
-mtd_fixtrx(const char *mtd, size_t offset)
+mtd_fixtrx(const char *mtd, size_t offset, size_t datasize)
 {
int fd;
struct trx_header *trx;
@@ -165,22 +165,25 @@ mtd_fixtrx(const char *mtd, size_t offset)
exit(1);
}
 
+   if (!datasize)
+   datasize = erasesize;
+
block_offset = offset & ~(erasesize - 1);
offset -= block_offset;
 
-   if (block_offset + erasesize > mtdsize) {
+   if (block_offset + datasize > mtdsize) {
fprintf(stderr, "Offset too large, device size 0x%x\n", 
mtdsize);
exit(1);
}
 
-   buf = malloc(erasesize);
+   buf = malloc(datasize);
if (!buf) {
perror("malloc");
exit(1);

Re: [OpenWrt-Devel] reboot

2016-05-06 Thread Imre Kaloz 

On Fri, 06 May 2016 12:50:32 +0200, John Crispin  wrote:


the reboot was not meant to be hostile or disruptive to OpenWrt. we are
just code nerds and messed up the politics of the launch at some places,
which in itself shows one of the reasons that motivated the reboot. the
whole idea is to give up our control over parts of the politics and
attract a new generation. a small none elected crowd has been making
decisions that essentially are not ours to make but effect us all. these
decisions have been made largely behind closed doors.


You were part of the "small none elected crowd".


the whole thing started by the workload becoming unbearable on a few. we
felt the need to simply stop or make drastic changes. giving up and just
letting it all bitrot seemed to be the easy way out, but we did feel
that we had a debt to our own heritage. simply leaving seemed bad and
unfair on the community. we decided to get the project back on track
instead.


So instead of exercising your right as a release manager or Felix his as  
the lead developer you've prepared LEDE. And don't tell me you didn't have  
the power, fro example procd and netifd were introduced without voting or  
everyone's agreement for example. Don't get me wrong, we're talking about  
how changes were introduced, not the nature of these changes.



we’ll be the first to agree that things where not peachy at times. this
however does not boil down to one single event, one single person or one
single flamewar. we are just many strong minded people that had
different opinions on many matters. due to the governance rules that we
setup and created and the way in which we managed the project it was
hard to mitigate these problems.


Not true. You had the power, yet you didn't use it. You could have called  
for a vote but you did not.



the reason for not involving everyone at the start is pretty simple and
nerdy. when the idea came up we just looked at who was the most active
in the various software trees the last 6 months and proposed our idea to
the 5 most active core devs and power users. it was a simple choice of
numbers and perceived activity. the feedback was rather overwhelming and
things just picked up a certain momentum leading to the status quo. i
guess the excitement for fixing long standing issues just took over.


Sure, playing democracy is easy if only the ones you agree on have the  
right to be included in decisions.



i have been asked by luka why we consider this a reboot rather than a
fork. i actually had to think about that one. a fork for me means that
one party splits with a second. that was not our intent. we wanted to
split with the errors we have done ourselves in the past and the wrong
management decision that were made at times. the gap between core
developers, power users and endusers had grown way too big. hence i
consider this more a “We are forking ourselves” or as we put it,
rebooting the system.


Again, as RM and LD, plus having the right to call a vote you had all the  
power you could need to make these changes in openwrt. Even the ones you  
turned down but introduced as modernization in LEDE.



to sum it up, my personal reasoning why i endorse this … the now 20 year
olds like social media, github, clouds and what nots. for me to continue
shaping a development and political system that they should use in their
future to run on their routers when i am already double their age is not
ideal. the next generation should be given the freedom to shape their
own future and learn from their mistakes the same way we shaped our
future and learned form our mistakes. i sincerely hope that the reboot
will encourage people to step up and not only have good ideas of what
should be fixed but will start to shape their future themselves


This is so full of political pr it makes me remember "make America great  
again"..




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

Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-06 Thread Imre Kaloz 
On Thu, 05 May 2016 17:44:43 +0200, Daniel Petre   
wrote:





On 05/05/2016 06:38 PM, Jonathan Bennett wrote:

There is plenty of blame to go around, I think.  Seems like the Lede
guys should have had the decency to at least inform the Openwrt
leadership privately that they were planning this venture.


If i read correctly the feedback from the LEDE guys (and many of the  
people in here) then it seems EVEN THEY did not had any serious real  
feedback since a while ago from the main OpenWrt "headquarters".


So.. what do you do when you ask (probably several times) and do not get  
any answer at all.. ?


They were in charge. When the lead developer and the release manager claim  
they had no power to change the way (yet both procd and netifd got  
introduced without prior discussion or agreement), you know something is  
fishy.



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

Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-06 Thread Imre Kaloz 
On Thu, 05 May 2016 18:24:09 +0200, Daniel Dickinson  
 wrote:



On 16-05-05 12:21 PM, Jonathan Bennett wrote:
[snip]
> The changes that the Lede guys are suggesting would be welcome,  
but
> splitting the project and community with an ugly fork is very  
much not

> welcome.

Let's just say that there are strong personalities who haven't been
working well together and that this has been a long time coming;  
perhaps
if something like using a mediator had been considered before  
things got

to this point it would have helped.  At this point I'm not sure
there is a
solution unless both sides are willing to bend a little (I'm really  
not
sure who has been flexible and who has not, but as I have said I  
suspect
a large part of the issue is that 'management' (who aren't and  
don't,

really) has overruled those doing the majority of the work and in an
open source project that doesn't fly).

I don't disagree.  I just see the current state of Openwrt/Lede as a
mess for the community.


I agree, I just don't see how the LEDE team could have avoided it
without giving up and accepting the broken status quo.


I hope you realize the LEDE team created most of that status quo.


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

[OpenWrt-Devel] reboot

2016-05-06 Thread John Crispin 
the reboot was not meant to be hostile or disruptive to OpenWrt. we are
just code nerds and messed up the politics of the launch at some places,
which in itself shows one of the reasons that motivated the reboot. the
whole idea is to give up our control over parts of the politics and
attract a new generation. a small none elected crowd has been making
decisions that essentially are not ours to make but effect us all. these
decisions have been made largely behind closed doors.

the whole thing started by the workload becoming unbearable on a few. we
felt the need to simply stop or make drastic changes. giving up and just
letting it all bitrot seemed to be the easy way out, but we did feel
that we had a debt to our own heritage. simply leaving seemed bad and
unfair on the community. we decided to get the project back on track
instead.

we’ll be the first to agree that things where not peachy at times. this
however does not boil down to one single event, one single person or one
single flamewar. we are just many strong minded people that had
different opinions on many matters. due to the governance rules that we
setup and created and the way in which we managed the project it was
hard to mitigate these problems.

the reason for not involving everyone at the start is pretty simple and
nerdy. when the idea came up we just looked at who was the most active
in the various software trees the last 6 months and proposed our idea to
the 5 most active core devs and power users. it was a simple choice of
numbers and perceived activity. the feedback was rather overwhelming and
things just picked up a certain momentum leading to the status quo. i
guess the excitement for fixing long standing issues just took over.

i have been asked by luka why we consider this a reboot rather than a
fork. i actually had to think about that one. a fork for me means that
one party splits with a second. that was not our intent. we wanted to
split with the errors we have done ourselves in the past and the wrong
management decision that were made at times. the gap between core
developers, power users and endusers had grown way too big. hence i
consider this more a “We are forking ourselves” or as we put it,
rebooting the system.

to sum it up, my personal reasoning why i endorse this … the now 20 year
olds like social media, github, clouds and what nots. for me to continue
shaping a development and political system that they should use in their
future to run on their routers when i am already double their age is not
ideal. the next generation should be given the freedom to shape their
own future and learn from their mistakes the same way we shaped our
future and learned form our mistakes. i sincerely hope that the reboot
will encourage people to step up and not only have good ideas of what
should be fixed but will start to shape their future themselves

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

Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-06 Thread Valent Turkovic 
I'm an outsider, have nothing to do with OpenWrt developement but
still work on few projects which depend on OpenWrt as awesome project
that enables us to do our projects (wifi mesh networking) but also do
professional jobs for clients using OpenWrt as embedded os for lots of
different applications.

We have "suffered" both on volunteers side (wifi mesh) and on
professional side by infrastructure failing... mirrors, wiki, forum...
you name it, all of it was down quite a lot in last few years, and on
IRC or mailing list you couldn't get concrete and timely answers. This
is a HUGE red flag for any size project.

Also even if we hd really good developers who know what they were
doing (I'm not that one) we couldn't get patches into trunk without
knowing somebody in the inside circle who has commit access, so
patches would get ignored... and kept in our own git... this is also a
really huge red flag.

I have convinced companies that I work for to donate money towards
OpenWrt so you have some budget for infrastructure, and I'm sure that
there are lots of other people who could also get some funding, but
answers I got on IRC were really dissapointing - that there is now was
to give donations towards better infrastructure or any other kind of
collecting funds...

These are all signs of poorly managed open source project/community
and I welcome any change in any direction that aims to fix any of
these issues... so fork away and make things better. Go LEDE team!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Introducing the LEDE project

2016-05-06 Thread Roman Yeryomin 
On 6 May 2016 at 03:53, Luka Perkov  wrote:
>>On 2016-05-05 20:22, mbm wrote:
>>> On 5/5/2016 7:40 AM, Felix Fietkau wrote:
 Many of the changes that we previously tried to introduce were often
 squashed by internal disagreements. Resulting discussions often turned
 toxic quickly and led to nothing being done to address the issues.
 Setting up the LEDE project was our way of creating a testbed for
 changes that we believe are important for the survival of the project.
>>>
>>> Change is not easy. Discussions need to happen. The problem is simply
>>> kicking out people you didn't agree with by starting a new organization
>>> in secret; you've created the public perception that we're somehow
>>> against you when really we all want the same things.
>>
>> Years of internal discussion led nowhere. Maybe it helps now that we're
>> making the whole issue public.
>
> For the sake of transparency, we've had public discussions, about a number of
> things, for example switching to Git:
>
> - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html
> - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036480.html
> - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036486.html
> - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036500.html
>
> And based on these inputs from you the switch was not made even though several
> OpenWrt developers wanted to switch.
>
> Also, server outages can happen to anybody:
> - https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038547.html
>
> However, we do not want to point fingers. What we do want is to make a great
> community around OpenWrt and to drive innovation - just like it has been done
> for more then a decade now.
>
> There has been a long history - mostly good, sometimes bad - since the project
> started from a garage project, to now having a project used by an awesome
> amount of users. This can be seen from the constructive discussions in this
> list on a daily basis, and in this very thread. Also, the project is used as
> the main SDK by many silicon vendors internally, and by vast number of
> companies on the embedded market.
>
> We are open for a discussion and would like to keep the OpenWrt's and it's
> community interests in the first place. Splitting the project does not make
> sense. Do you agree?
>
 We appreciate your effort to have an open discussion about this,
 however the sudden deletion of our widely published openwrt.org email
 addresses somewhat undermines this. We will not respond in kind and we
 will continue to maintain the critical parts of OpenWrt infrastructure
 that we control.
>>>
>>> Let's be clear on this subject; no commit access was revoked, you still
>>> have full read and write access to the entire OpenWrt tree.
>>>
>>> Email forwarding was temporarily disabled following the LEDE announcement
>>> - LEDE's own rules prohibit project based email addresses
>> No, they don't. They state that the LEDE project won't provide project
>> email addresses. Interpreting that as meaning that we shouldn't be able
>> to access our openwrt.org addresses is more than a bit of a stretch.
>
> In any case, due to the events that happened and the fact that the OpenWrt 
> name
> is being used in a manner opposite of the projects best interest, we felt that
> these actions were needed in order to avoid the further damages to the 
> project.
>
>>> - It's unclear if LEDE still represents OpenWrt
>> So? Asking us to not send any further emails about LEDE from our
>> openwrt.org addresses should have been enough.
>
> Actually, this was discussed on #lede-adm.

IRC history is hard to follow, I'd better assume that something not
written here never happened.

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

Re: [OpenWrt-Devel] [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658

2016-05-06 Thread Gareth Parker 
I sent them one too and got a response back almost immediately:


Hi Gareth,

Thanks for getting in touch with us!

I'll check with my internal team and get back to you once I have any updates. 

Thanks!
Vann T
Ubiquiti Networks



That was a few hours ago, it will be interesting to see if they do give up the 
source code.  I could also try contacting our local authorized distributor here 
in NZ and see if they can help.


-Original Message-
From: OpenWrt [mailto:openwrt-devel@lists.openwrt.org] 
Sent: Friday, 6 May 2016 7:34 p.m.
Cc: openwrt-tick...@lists.openwrt.org
Subject: Re: [OpenWrt] #20982: jffs2-error / nanostation M5 xw / r47658

#20982: jffs2-error / nanostation M5 xw / r47658
+
  Reporter:  bittorf@…  |  Owner:  developers
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  packages   |Version:  Trunk
Resolution: |   Keywords:
+

Comment (by LeSpocky):

 Replying to [comment:33 gareth41@…]:
 > I tried loading trunk over 5.6.2 and could not save any settings.  It's  
 > something to do with this new u-boot version.  I think someone needs to  get 
 > hold of the source code of new u-boot from UBNT and analyze it,  shouldn't 
 > be too difficult given its GPL licensed and providing that UBNT  comply.

 I sent a mail to Ubiquiti support today requesting those sources, but  after 
reading http://libertybsd.net/ubiquiti/ and
 http://community.ubnt.com/t5/Business-Talk/Any-update-on-GPL-licence-
 violation/m-p/1428448#M47832 I'm not so sure if this will work out. :-/

--
Ticket URL: 
OpenWrt 
Opensource Wireless Router Technology
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel