Re: [LEDE-DEV] [PATCH 2/5] br2684ctl: set the MAC address configured for the atm bridge using

2016-07-03 Thread Mathias Kresin 

Hey Felix,

first off all, I've to admin that don't have much knowledge about ATM 
and the more I read about ATM the more I get confused.


The biggest flaw of my patchset is, that I've never described which 
issue I'm trying to fix.


It has been tried for ages now to fix a race condition between applying 
a MAC address to the nas interface and requesting an ip-address via dhcp 
over nas0 for the DGN3500. Which results in an invalid MAC used by the 
dhcp client.


All attempts to fix the issue had either side effects on other boards or 
got broken over time.


03.07.2016 09:47 Felix Fietkau:

On 2016-07-02 17:00, Mathias Kresin wrote:

If an ESI is set, it will be used as MAC address for the nas0
interface.

According to the ESI man page, changes to the ESI are not automatically
propagated throughout the system and therefore esi should be used
early during system.

Setting the ESI before creating the nas interface should be early enough
for all following services.

Signed-off-by: Mathias Kresin 

I'm not sure the atm-bridge section is the right place for the MAC
address. ESI can only be set once per ATM device, whereas the same ATM
device can have multiple atm-bridge instances.


I'm still convinced that the atm-bridge is the right place to set the 
MAC. By setting the ESI, the created nas interface is using the desired 
MAC address right from the beginning. No chance for race conditions.


Albeit you told me already that it's possible to have multiple 
atm-bridges for the same atm device, I've realized how it's working only 
now.


In theory adding support for multiple atm-bridge instances is easy. The 
esi command has a parameter which allows to force overwriting an 
existing ESI.


Using the br2684ctl command in background mode on the command line

/usr/sbin/esi -f "11223344556b" 0 && /usr/sbin/br2684ctl -b -c "0" -e 
"llc" -p "1" -a "0.7.35" -S /lib/netifd/br2684-up && /usr/sbin/esi -f 
"11223344556c" 0 && /usr/sbin/br2684ctl -b -c "1" -e "llc" -p "1" -a 
"0.8.30" -S /lib/netifd/br2684-up


works as expected. The resulting nas interfaces are having the desired 
MAC addresses:


nas0  Link encap:Ethernet  HWaddr 11:22:33:44:55:6B
nas1  Link encap:Ethernet  HWaddr 11:22:33:44:55:6C

But so far I wasn't able to get the same logic working in the brctl2684 
init script. The second esi call is executed before the first nas 
interface is created, with the result that both nas interfaces are using 
the same MAC address. I can only guess that it's related to the fact 
that br2684ctl is started in foreground mode using the exec command + 
the way procd is working.


Any help on this is highly welcome.

Mathias

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH V3] Re: procd: patch to support busybox mkfs.ext2

2016-07-03 Thread Luke McKee 
On 07/03/2016 01:24 PM, John Crispin wrote:
> Hi,
>
> few comments
>
> 1) the patch needs to be split into 2, ext2 change/lzo change
> 2) send them inline please and not as attachement
> 3) the V3 needs to be in the subject prefix [PATCH V3] procd: ...
> 4) the Signed-off-by: line is missing
>
>   John

Hi John,

1) no can do. You are going to merge it into your project git page
anyway, unless openwrt locked you out of your own project you are a
maintainer of on git. In which case reply with the rebuke to  2) ok
I fired up thunderbird, google mail destroys patches in plain text mode
3) done 4) done

Don't blame me for the long email. I thought I was already done earlier
but .

I have tested this with lede trunk with v2 of the patch. V3 is the same
just with a #ifdef, lz4 (faster less compression). It definitely works.
It has 4mb flash.

140k of text files generated in my setup and placed in /tmp turned into
7.1k - neat! - however tmpfs has garbage collection zram doesn't exit
unless you create a cron job that will dd if=/dev/zero bs=4096
of=/tmp/zero.bin count=sizeofreespace; rm /tmp/zero.bin. Deleting a file
from /tmp doesn't allow memory reclamation like with tmpfs. Under normal
use it will take a long time for this to really fill up, especially if
ext2 is over-writing the same files & inodes. Zram module estimates
there is 28meg of /tmp storage which is more than you'd get with tmpfs.
My tp-link has 32mb ram 28 usable.

Secure deletion on ext4 was never popular: https://lwn.net/Articles/462437/

Also of NOTE is tmpfs is STILL getting mounted. People with this feature
on could in theory disable tmpfs. John you might want to look into
disabling the tmpfs mount of ZRAM_TMPFS mounted instead.

John:

Constraints for the Makefile for procd to go with this I didn't submit,
because I'm not sure config stanzas like package stanzas can have
DEPENDS. Maybe you have to make it a fake package or something that
really just passes on the defines to gcc so you can set up package
dependencies.

=

1) Thou shall turn on CONFIG_BUSYBOX_CONFIG_MKFS_EXT2=y

Justification: ~15-20k binary vs 350k (with stripping) for mkfs.ext2 and
if you want the proper mkfs.ext4 etc you can install it in your overlay
- extroot. Busybox mkfs.ext2 and e2fsprogs are configured not to collide
with each-other.  This patch makes the need for e2fsprogs libext2
redundant. Not having this (like we do right now) will flood the bug
reports with idiots (like me) wondering why they bricked their router
when it can't mount /tmp.

2) Debatable: Thou shall disable zram-swap, zram-swap shall block this
PROC_ZRAM_TMPFS option.

Justification: Right now they both want to use /dev/zram0, but the
system will have no space for running apps if they are both running at
the same time. You need to allocate 1/3 ram to each at best. That will
have be a new compile time option in a further patch, that I will
release should someone make the argument for wanting both of these.

You either want 1 of 3 possible setups. #1 This patch. Best for people
who need to opkg -d ram a lot of stuff #2 tmpfs and progs BOTH can use
zram-swap which makes it a better overall choice, after thinking about
this patch it isn't worth it as much as just using zram-swap. But better
have a working feature than a broken one as it exists in buildroot now
Or #3 Assuming you have a fast storage device connected to your openwrt
(most don't but some NASes do) ZSWAP kernel will dynamically use free
memory to offer a pre-swap cache, and allow compressed data (lzo/lz4) to
be wrote to swap. It may require an actual initialized swap device to
work. I haven't RTFMed yet.

3) Debatable: LZ4 should be on by default. (My two cents)

Justification: It's almost compresses well as LZO but it's less CPU
intensive for those without Floating point SMID's which is most home
routers. So put some help about that in the Makefile. LZ4 is included as
a dependency to the zram.ko module and will be loaded at early boot by
modprobe / procd. Contrary to  rumors circulating on openwrt's trac it
actually works :) https://dev.openwrt.org/ticket/22666#comment:3

4) Highly recommended: Makefile should block option if your kernel isn't
4.4.

Justification: https://dev.openwrt.org/ticket/21705 & above

5) Stop openwrt folks trying to patch the kernel to make two zram
devices by default because you can hot-add them.

https://dev.openwrt.org/ticket/19586#comment:10

Here's the patch

-


procd: remove dependency on bloated e2fsprogs/libext2 and use
CONFIG_BUSYBOX_CONFIG_MKFS_EXT2=y

At a minimum (see accompanying email on mailing list) advising my two
cents on the pros and cons of this patch
you need to add a configuration option to the Makefile if you want lz4
support

config PROCD_ZRAM_TMPFS
bool
default n
prompt "Mount /tmp using zram."
endmenu

 &

ifeq ($(CONFIG_PROCD_ZRAM_TMPFS_LZ4),y)

Re: [LEDE-DEV] [PATCH 2/5] br2684ctl: set the MAC address configured for the atm bridge using

2016-07-03 Thread Felix Fietkau 
On 2016-07-02 17:00, Mathias Kresin wrote:
> If an ESI is set, it will be used as MAC address for the nas0
> interface.
> 
> According to the ESI man page, changes to the ESI are not automatically
> propagated throughout the system and therefore esi should be used
> early during system.
> 
> Setting the ESI before creating the nas interface should be early enough
> for all following services.
> 
> Signed-off-by: Mathias Kresin 
I'm not sure the atm-bridge section is the right place for the MAC
address. ESI can only be set once per ATM device, whereas the same ATM
device can have multiple atm-bridge instances.

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 3/5] lantiq: pass MAC address to the ATM bridge helper

2016-07-03 Thread Mathias Kresin 

Am 03.07.2016 um 08:31 schrieb John Crispin:

Hi,

On 02/07/2016 17:00, Mathias Kresin wrote:

Signed-off-by: Mathias Kresin 
---
  target/linux/lantiq/base-files/etc/board.d/02_network | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/lantiq/base-files/etc/board.d/02_network 
b/target/linux/lantiq/base-files/etc/board.d/02_network
index c271e62..3bb4e6e 100755
--- a/target/linux/lantiq/base-files/etc/board.d/02_network
+++ b/target/linux/lantiq/base-files/etc/board.d/02_network
@@ -163,7 +163,7 @@ WBMR300)
  esac

  if [ -n "$(ls /lib/modules/`uname -r`/ltq_atm*)" ]; then
-   ucidef_add_atm_bridge "$vpi" "$vci" "$encaps" "$payload"
+   ucidef_add_atm_bridge "$vpi" "$vci" "$encaps" "$payload" "$wan_mac"
  fi

  if grep -qE "system type.*: (VR9|xRX200)" /proc/cpuinfo; then
@@ -177,7 +177,7 @@ fi
  ucidef_set_interface_wan "$interface_wan" "pppoe"

  [ -n "$lan_mac" ] && ucidef_set_interface_macaddr lan "$lan_mac"
-[ -n "$wan_mac" ] && ucidef_set_interface_macaddr wan "$wan_mac"
+[ -n "$wan_mac" ] && [ "$interface_wan" != "nas0" ] && ucidef_set_interface_macaddr wan 
"$wan_mac"



this is a bit quirky and will break devices that can support atm/ptm or
that have 2 atm interfaces. is there no better way to detect if this is
a atm bridge ?

John



This quirk is used to ensure that during creating the initial network 
configuration a MAC is only set for an atm bridge and never for the 
(resulting) nas0 device.


I may got the purpose of the file wrong. But to my understanding it is 
used to create the initial network config. The logic in the file as it 
is neither allows to create multiple atm bridges nor allows to enable 
atm & ptm at the same time.


The resulting default /e/c/network is nearly the same as before. Only 
the mac is moved for ATM only devices from the nas0 interface to atm 
bridge (and will be inherit via ATM bridge to the nas0 interface).


Furthermore, for xrx200 devices the MAC is now added to the atm bridge 
as well and will be used as soon as someone switches from the initial 
configured ptm to atm.


Therefore, at least with the generated default network config I don't 
see the mentioned problems.


Mathias

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] procd: patch v3 to support busybox mkfs.ext2

2016-07-03 Thread John Crispin 
Hi,

few comments

1) the patch needs to be split into 2, ext2 change/lzo change
2) send them inline please and not as attachement
3) the V3 needs to be in the subject prefix [PATCH V3] procd: ...
4) the Signed-off-by: line is missing

John

On 03/07/2016 08:14, Luke McKee wrote:
> To quote Arjen:
> If the only reason to switch to ext2 is to remove the journal, why not
> just add
> 
>  -O ^has_journal
> 
> to the mount options?
> 
> 
> 
> That's not a mount option. That's a tune2fs option.
> 
> Journaling isn't the the only problem. The biggest problem is BLOAT.
> You need libext2+e2fsprogs in a 4MB flash root image with the current
> zram setup.
> Would someone want /tmp on zram if they had to add all this to the 4MB
> squashfs image.
> 
> -rw-r--r-- 1 lmc users 199739 Jul  3 06:15 e2fsprogs_1.43.1-1_mips_24kc.ipk
> -rw-r--r-- 1 lmc users 151873 Jul  3 06:15 libext2fs_1.43.1-1_mips_24kc.ipk
> 
> The simple answer is most openwrt users would say no to this feature
> do to how it's implemented.
> 
> I actually was going for ext2 like the original patch, but I was sold
> that ext4 can mount ext2 formatted filesystems (without a journal)
> (see man ext4). The ext4 filesystem driver vs ext2 does bloat a bit,
> but I don't mind it as I can mount ext4 over nbd for my extroot.
> 
> Busybox is only 40k of source including the headers. mkfs.ext4 is 360k
> compressed!
> https://git.busybox.net/busybox/tree/util-linux/mkfs_ext2.c
> 
> Also -O ^has_journal is an tune2fs option not a mount option. And that
> tune2fs feature isn't in busybox, hence the bloat issue.
> 
> "BusyBox v1.24.2 () multi-call binary.
> 
> Usage: tune2fs [-c MAX_MOUNT_COUNT] [-i DAYS] [-C MOUNT_COUNT] [-L
> LABEL] BLOCKDEV
> 
> Adjust filesystem options on ext[23] filesystems"
> Busybox tune2fs is useless.
> 
> So 90% of the userbase with size constrained flash file-systems will
> want to use busybox mkfs.ext2 instead. busybox mkfs.ext2 and mkfs.ext2
> don't conflict because the package installs in /usr/sbin and busybox
> installs in /sbin
> 
> I move that the feature be dependent ONLY on busybox mkfs.ext2.
> Busybox mount isn't required because procd includes sys/mount.h
> In order words set the path to /sbin/mkfs.ext2 (busybox)
> 
> Attached is the new patch. Allow users in the Makefile configuration
> to choose to use LZ4 (more speed ~15% less compression) if they so
> desire.
> John can do the makefile if and when he merges the patch.
> 
> I'm out of the debate now, I got it in my
> lede/packgaes/system/procd/patches/ directory :) I'm happy
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Lede r881 - how to get better Wireless performace ?

2016-07-03 Thread David Lang 

On Sun, 3 Jul 2016, Dennis Schneck wrote:


Hello,
i use a TP Link Archer C7 v2 with LEDE r811.
But the Wireless performace (2,4GHz) is not optimal.
Are the parameter or something else to tune the performace ?
If use other Firmware in the same Environment get better transfer rates.
 
CPU use is near 10% at the speed test.
Free memory near 95MB


you don't give us any information here.

what is not optimal? what are you trying to do? what speed are you getting? what 
speed are you expecting to get? how many things are using overlapping wifi 
channels in your area? were you getting better speeds before an upgrade (or 
with other firmware)?

The odds are that the problem is just too many people using overlapping channels 
in your area, and other than changing to a less used channel, there isn't 
anything much you can do to solve it.


David Lang___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev