[LEDE-DEV] A state of network acceleration

Getting better network performance (mostly for NAT) using some kind of acceleration was always a hot topic and people are still looking/asking for it. I'd like to write a short summary and share my understanding of current state so that: 1) People can undesrtand it better 2) We can have some rough

Re: [LEDE-DEV] A state of network acceleration

On 17 January 2018 at 16:25, Rafał Miłecki wrote: > The problem with all existing implementations was they used various > non-upstream patches for kernel integration. Some were less invasive, > some a bit more. They weren't properly reviewed by kernel developers > and usually

Re: [LEDE-DEV] A state of network acceleration

Hi Rafal, On Wed, Jan 17, 2018 at 04:25:10PM +0100, Rafał Miłecki wrote: > Getting better network performance (mostly for NAT) using some kind of > acceleration was always a hot topic and people are still > looking/asking for it. I'd like to write a short summary and share my > understanding of

[LEDE-DEV] [PATCH 0/5] x86: add support for microcode update

Hi, This series will add support for microcode update on x86 targets, in light of the recent security issues. While other distributions use an early initramfs approach to update the microcode as early as possible, in OpenWrt the earliest place where we can do this is preinit. The Intel

[LEDE-DEV] [PATCH 1/5] x86: enable microcode loading for Intel and AMD

Enable for 4.9 and 4.14. Signed-off-by: Zoltan HERPAI --- target/linux/x86/config-4.14 | 5 - target/linux/x86/config-4.9 | 5 - 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/target/linux/x86/config-4.14 b/target/linux/x86/config-4.14 index

[LEDE-DEV] [PATCH 4/5] firmware: add microcode package for Intel

Compiling the Intel microcode package results in a microcode.bin and a microcode-64.bin. As we can decide based on the subtarget which should be used, we'll only split the required .bin file with iucode-tool. Instead of using the large microcode.bin/microcode-64.bin, the splitted ucode files

[LEDE-DEV] [PATCH 3/5] tools: add iucode-tool

Add tool to "compile" Intel microcode files. The tool will be compiled for host (to split the microcode.dat) and for target (to forcibly reload the microcode or scan the system if required). Signed-off-by: Zoltan HERPAI --- package/system/iucode-tool/Makefile | 47

[LEDE-DEV] [PATCH 2/5] firmware: add microcode package for AMD64

Signed-off-by: Zoltan HERPAI --- package/firmware/linux-firmware/x86.mk | 9 + 1 file changed, 9 insertions(+) create mode 100644 package/firmware/linux-firmware/x86.mk diff --git a/package/firmware/linux-firmware/x86.mk b/package/firmware/linux-firmware/x86.mk new

Re: [LEDE-DEV] DDNS for ipv6

Am 16.01.2018 um 21:07 schrieb e9hack: > Hi Christian, > > I revert all ddns related changes. It looks like that the changes are not the > root cause. I check my old log files. The > issue did start with my build from 16th of December. > > Independently of this, I'm the opinion, ddns for ipv6

Re: [LEDE-DEV] [PATCH] procd: add timing to start/stop logging

On 16/01/18 10:49, Karl Vogel wrote: Shows how long an initd task took, for example: procd: stop /etc/init.d/dropbear running - took 0.088824 us procd: Update service dnsmasq procd: Update instance dnsmasq::dnsmasq procd: running /etc/init.d/dnsmasq running procd: start

Re: [LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

On 17/01/18 10:54, Koen Vandeputte wrote: On 2018-01-17 10:43, Karl Vogel wrote: Shows how long an initd task took, for example:   procd: stop /etc/init.d/dropbear running - took 0.088824s   procd: Update service dnsmasq   procd: Update instance dnsmasq::dnsmasq   procd: running

[LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

Shows how long an initd task took, for example: procd: stop /etc/init.d/dropbear running - took 0.088824s procd: Update service dnsmasq procd: Update instance dnsmasq::dnsmasq procd: running /etc/init.d/dnsmasq running procd: start /etc/init.d/dnsmasq running procd: stop /etc/init.d/dnsmasq

Re: [LEDE-DEV] [PATCH] jshn: add functionality to read big JSON

Citeren John Crispin : On 07/01/18 18:08, Christian Beier wrote: The existing read functionality feeds the complete JSON to jshn as a cmdline argument, leading to `-ash: jshn: Argument list too long` errors for JSONs bigger than ca. 100KB. This commit adds the ability to

Re: [LEDE-DEV] [PATCH] ar71xx: add support for Ubiquiti Litebeam M5

Hello Arne, Minor thing inline, below. On 16.01.2018 21:43, Arne Zachlod wrote: [...] +lbe-m5) + ucidef_set_led_netdev "lan" "LAN" "ubnt:green:lan" "eth0" + ucidef_set_led_wlan "wlan" "WLAN" "ubnt:green:wlan" "phy0tpt" + ucidef_set_led_default "sys" "SYS" "ubnt:green:sys"

[LEDE-DEV] ipq806x Netgear R7500 uboot

Hi, I've lost my original uboot environment settings and would like to ask for your help. Since it's been a while from when I was playing with the hardware the uboot env is all messed up and I'd like to start over from scratch. Would someone please send me "env print" from within the

Re: [LEDE-DEV] [PATCH] ar71xx: add support for Ubiquiti Litebeam M5

On 16/01/18 21:43, Arne Zachlod wrote: Specification: - SoC: Atheros AR9342 - Flash: 8 MiB - RAM: 64 MiB - UART: 1x UART on PCB - 115200 8N1 - Ethernet: 1 x 100 Mbit with passive PoE (24V/0.2A) Doesn't work: * Flash via TFTP with Uiquiti Uboot Installation via vendor firmware: - upload

Re: [LEDE-DEV] [PATCH] jshn: add functionality to read big JSON

On 07/01/18 18:08, Christian Beier wrote: The existing read functionality feeds the complete JSON to jshn as a cmdline argument, leading to `-ash: jshn: Argument list too long` errors for JSONs bigger than ca. 100KB. This commit adds the ability to read the JSON directly from a file if

Re: [LEDE-DEV] ipq806x Netgear R7500 uboot

On Wed, Jan 17, 2018 at 4:28 AM, Thomas Reifferscheid wrote: > Hi, I've lost my original uboot environment settings and would like to ask > for your help. > Since it's been a while from when I was playing with the hardware the uboot > env is all messed up and I'd like to

[LEDE-DEV] [PATCH v2] ar71xx: add support for Ubiquiti Litebeam M5

Specification: - SoC: Atheros AR9342 - Flash: 8 MiB - RAM: 64 MiB - UART: 1x UART on PCB - 115200 8N1 - Ethernet: 1 x 100 Mbit with passive PoE (24V/0.2A) Doesn't work: * Flash via TFTP with Uiquiti Uboot Installation via vendor firmware: - upload factory image via webinterface Signed-off-by:

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 3/5] tools: add iucode-tool

There is another intel ucode generator in Archlinux repo, it seems the code is more elegant and don't require additional dependency. Do you have any idea? https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/intel-ucode Best Regards, Syrone Wong On Thu, Jan 18, 2018 at 3:41

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/5] x86: add support for microcode update

On January 17, 2018 11:41:01 AM PST, Zoltan HERPAI wrote: >Hi, > >This series will add support for microcode update on x86 targets, >in light of the recent security issues. > >While other distributions use an early initramfs approach to update >the microcode as early as

Re: [LEDE-DEV] TDR / VeriPHY

On January 17, 2018 6:06:54 PM PST, "Denis Periša" wrote: >Hi all, > >I've searched three days in a row and I cannot find any more info on >software cable tester for linux/openwrt. > >Many my devices support this feature as in original firmware (Mikrotik >for example) I can

[LEDE-DEV] TDR / VeriPHY

Hi all, I've searched three days in a row and I cannot find any more info on software cable tester for linux/openwrt. Many my devices support this feature as in original firmware (Mikrotik for example) I can see cable pairs and which cable wire is not connected and such. Even length of the

[LEDE-DEV] [PATCH] ar71xx: Orders the names of the devices alphabetically.

Signed-off-by: Arne Zachlod --- target/linux/ar71xx/base-files/etc/board.d/01_leds | 236 ++--- .../ar71xx/base-files/etc/board.d/03_gpio_switches | 12 +- target/linux/ar71xx/base-files/etc/diag.sh | 40 ++-- 3 files changed, 144 insertions(+), 144

[LEDE-DEV] [PATCH v3] procd: add timing to start/stop logging

Shows how long an initd task took, for example: procd: stop /etc/init.d/dropbear running - took 0.088824s procd: Update service dnsmasq procd: Update instance dnsmasq::dnsmasq procd: running /etc/init.d/dnsmasq running procd: start /etc/init.d/dnsmasq running procd: stop /etc/init.d/dnsmasq

Re: [LEDE-DEV] [PATCH] ipq806x: replace linux, part-probe with a proper partitions subnode

On 16/01/18 20:34, Stefan Lippers-Hollmann wrote: Hi On 2018-01-11, Rafał Miłecki wrote: From: Rafał Miłecki This solution is more upstream compatible as it only requires specifying of_match_table in the parser code and doesn't depend on linux,part-probe which is solution

Re: [LEDE-DEV] [PATCH] ar71xx: add support for Ubiquiti Litebeam M5

Hi John, I ordered the device between the already existing bullet and the rocket-ti. To me this looks like the order already in place and the right spot because it is alphabetical for the manufacturer. In case that this is not the right thing to do maybe we should refactor the whole file, because

Re: [LEDE-DEV] [PATCH] jshn: add functionality to read big JSON

On 17/01/18 10:44, Arjen de Korte wrote: Citeren John Crispin : On 07/01/18 18:08, Christian Beier wrote: The existing read functionality feeds the complete JSON to jshn as a cmdline argument, leading to `-ash: jshn: Argument list too long` errors for JSONs bigger than ca.

Re: [LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

On 2018-01-17 10:43, Karl Vogel wrote: Shows how long an initd task took, for example: procd: stop /etc/init.d/dropbear running - took 0.088824s procd: Update service dnsmasq procd: Update instance dnsmasq::dnsmasq procd: running /etc/init.d/dnsmasq running procd: start

Re: [LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

John Crispin writes: > On 17/01/18 10:54, Koen Vandeputte wrote: >> >> >> On 2018-01-17 10:43, Karl Vogel wrote: >>> Shows how long an initd task took, for example: >>> >>> procd: stop /etc/init.d/dropbear running - took 0.088824s >>> procd: Update service dnsmasq >>>

Re: [LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

On 2018-01-17 11:11, Karl Vogel wrote: John Crispin writes: On 17/01/18 10:54, Koen Vandeputte wrote: On 2018-01-17 10:43, Karl Vogel wrote: Shows how long an initd task took, for example: procd: stop /etc/init.d/dropbear running - took 0.088824s procd: Update