Re: [OpenWrt-Devel] [PATCH] odhcpd: add network dependent start trigger

2019-02-24 Thread Hans Dedecker
Hi, On Sun, Feb 24, 2019 at 7:06 AM Eric Luehrsen wrote: > > Recent (20190207) changes to odhcpd makee it dependent on OpenWrt > logical interfaces. Boot time race conditions may make odhcpd binding Even before the most recent changes odhcpd was dependent on OpenWRT logical interfaces nothing

Re: [OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part

2019-02-24 Thread Sven Eckelmann
On Monday, 25 February 2019 02:24:56 CET Gui Iribarren wrote: > have you considered, to simplify backwards compatibility, to keep proto > "batadv" as it currently is (hardif) and naming "batadv_mesh" the new proto? It was one of the goals to *not* name the batadv hardif interface proto

Re: [OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part

2019-02-24 Thread Gui Iribarren via openwrt-devel
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- agree on the current mess, and

Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions

2019-02-24 Thread Jeff Kletsky
On 2/24/19 4:21 PM, Andreas Ziegler wrote: Hi Jeff, thanks for your suggested change! Although i agree with your change regarding USB GPIO, i don't with the other part. Using stock/vendor firmware, GPIO 12 is a green system/status LED and GPIO 14 is a red wifi LED. I just sent a patch to the

Re: [OpenWrt-Devel] [PATCH 2/2] ath79: GL.iNet AR300M family: Correct DTS LED definitions

2019-02-24 Thread Andreas Ziegler
Hi Jeff, thanks for your suggested change! Although i agree with your change regarding USB GPIO, i don't with the other part. Using stock/vendor firmware, GPIO 12 is a green system/status LED and GPIO 14 is a red wifi LED. I just sent a patch to the list which fixes this in ar71xx target, maybe

[OpenWrt-Devel] [PATCH] ar71xx: GL.iNet AR300M family: correct LED definitions

2019-02-24 Thread Andreas Ziegler
remove USB as this is no LED but power control rename WiFi LED with correct color red (like in stock firmware) set middle LED to be used for LAN link/activity Signed-off-by: Andreas Ziegler --- target/linux/ar71xx/base-files/etc/board.d/01_leds | 1 +

[OpenWrt-Devel] [PATCH] ath79: make TP-Link revision naming consistent

2019-02-24 Thread David Bauer
This commit makes the TP-Link hardware-revision naming consistent to match the one used by the vendor. TP-Link refers to the different revisions as "vX" not "Version X". Signed-off-by: David Bauer --- target/linux/ath79/dts/ar9132_tplink_tl-wr1043nd-v1.dts | 2 +-

[OpenWrt-Devel] ath9k: fix dynack in IBSS mode

2019-02-24 Thread Joe Ayers
First of all, thanks for contributing this fix. I've incorporated into the http://www.arednmesh.org project, just getting into our nightly builds now. A comment and a couple questions... The MAX_DELAY was way too short for our community, had to increase that significantly. We commonly have

[OpenWrt-Devel] [sdwalker/sdwalker.github.io] cdf1fd: This week's update

2019-02-24 Thread Stephen Walker
Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: cdf1fd80183e56db9d5ccabdaa35f9aa449846a6 https://github.com/sdwalker/sdwalker.github.io/commit/cdf1fd80183e56db9d5ccabdaa35f9aa449846a6 Author: Stephen Walker Date: 2019-02-24 (Sun, 24 Feb

[OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part

2019-02-24 Thread Sven Eckelmann
batman-adv allows to configure three different objects: * batadv hardif - network interface used by batadv meshif to transport the batman-adv packets - its master interface is set to the batadv meshif * batadv (meshif/softif) - virtual interface that emulates a normal 802.3 interface

[OpenWrt-Devel] [PATCH] mac80211: rt2x00: fix crash on release_firmware

2019-02-24 Thread Stanislaw Gruszka
Fix crash due to passing invalid r2x00dev->eeprom_file pointer to release_firmware(). Since we copy eeprom data with EEPROM_SIZE in rt2800_read_eeprom() we can use eeprom_file->size as marker if the file was crated by request_firmware(). Cc: Felix Fietkau , Cc: Daniel Golle Signed-off-by: