[LEDE-DEV] [PATCH] kernel: update 4.4 to 4.4.90

2017-10-05 Thread Kevin Darbyshire-Bryant 
No patch refresh required.

Compile & run tested: ar71xx Archer C7 v2

Signed-off-by: Kevin Darbyshire-Bryant 
---
 include/kernel-version.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index 3d32017..bf38d86 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -3,11 +3,11 @@
 LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .71
-LINUX_VERSION-4.4 = .89
+LINUX_VERSION-4.4 = .90
 LINUX_VERSION-4.9 = .52
 
 LINUX_KERNEL_HASH-3.18.71 = 
5abc9778ad44ce02ed6c8ab52ece8a21c6d20d21f6ed8a19287b4a38a50c1240
-LINUX_KERNEL_HASH-4.4.89 = 
a81d1b1306e4fddee5d6f7219090a616073b02f4069e44522a9c0454b17f2b67
+LINUX_KERNEL_HASH-4.4.90 = 
6826ccd213ac79bbfd47e63912e89ef7ec70324b7aa3684a4d4560fc2b436331
 LINUX_KERNEL_HASH-4.9.52 = 
ffdd034f1bf32fa41d1a66a347388c0dc4c3cff6f578a1e29d88b20fbae1048a
 
 ifdef KERNEL_PATCHVER
-- 
2.7.4


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

Re: [LEDE-DEV] [PATCH] firewall3: Enable TCP_ECN by default.

2017-10-05 Thread Kevin Darbyshire-Bryant 



On 03/10/17 18:22, David Lang wrote:

On Tue, 3 Oct 2017, Kevin Darbyshire-Bryant wrote:

It's tempting to set it to 1 (like I have for the past year+) and be 
damned :-)


So what is the failure mode and how will people who experience failures 
know what they need to change?


David Lang


I'd anticipate increased initial connection latency rather than complete 
failure, suggested by this extract from wiki:


Beginning with version 4.1 of the Linux kernel, released in June 2015, 
the tcp_ecn_fallback mechanism, as specified in RFC 3168 section 
6.1.1.1, is enabled by default when ECN is enabled (the value of 1). The 
fallback mechanism attempts ECN connectivity in the initial setup of 
outgoing connections, with a graceful fallback for transmissions without 
ECN capability, mitigating issues with ECN-intolerant hosts or firewalls.


https://tools.ietf.org/html/rfc3168


They'd need to add/change if absolutely necessary:

/etc/config/firewall

config defaults
option tcp_ecn '2'  <--- from '1'


rfc extract:


6.1.1.1.  Middlebox Issues

   ECN introduces the use of the ECN-Echo and CWR flags in the TCP
   header (as shown in Figure 3) for initialization.  There exist some
   faulty firewalls, load balancers, and intrusion detection systems in
   the Internet that either drop an ECN-setup SYN packet or respond with
   a RST, in the belief that such a packet (with these bits set) is a
   signature for a port-scanning tool that could be used in a denial-
   of-service attack.  Some of the offending equipment has been
   identified, and a web page [FIXES] contains a list of non-compliant
   products and the fixes posted by the vendors, where these are
   available.  The TBIT web page [TBIT] lists some of the web servers
   affected by this faulty equipment.  We mention this in this document
   as a warning to the community of this problem.

   To provide robust connectivity even in the presence of such faulty
   equipment, a host that receives a RST in response to the transmission
   of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared.
   This could result in a TCP connection being established without using
   ECN.

   A host that receives no reply to an ECN-setup SYN within the normal
   SYN retransmission timeout interval MAY resend the SYN and any
   subsequent SYN retransmissions with CWR and ECE cleared.  To overcome
   normal packet loss that results in the original SYN being lost, the
   originating host may retransmit one or more ECN-setup SYN packets
   before giving up and retransmitting the SYN with the CWR and ECE bits
   cleared.

   We note that in this case, the following example scenario is
   possible:

   (1) Host A: Sends an ECN-setup SYN.
   (2) Host B: Sends an ECN-setup SYN/ACK, packet is dropped or delayed.
   (3) Host A: Sends a non-ECN-setup SYN.
   (4) Host B: Sends a non-ECN-setup SYN/ACK.

   We note that in this case, following the procedures above, neither
   Host A nor Host B may set the ECT bit on data packets.  Further, an
   important consequence of the rules for ECN setup and usage in Section
   6.1.1 is that a host is forbidden from using the reception of ECT
   data packets as an implicit signal that the other host is ECN-
   capable.



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

[LEDE-DEV] [PATCH v2] generic: swconfig: add mode led attribute

2017-10-05 Thread Kevin Darbyshire-Bryant 
Add sysfs 'mode' attribute to swconfig controlled LEDs.

swconfig 'link state' LEDs blink in the presence of port traffic.  This
behaviour becomes more obvious as switches start to support
get_port_stats() e.g. commits 0369e358916ef092a1644334f5dd1412051b68a4,
3056d09b4046e0eb0f6de0f3f5432cd9fa86fc51,
4ddbc43cc15c2fa128a2f169964ef7eb508cf2c5,
4d8a66d9346373c2a7fcac5bdae3f662a9dbd9df.

This blinking can be confusing/distracting if the switch has other LEDs
used to indicate traffic.  Provide a 'mode' sysfs attribute that
controls the blink on traffic behaviour.

mode - either "none" (LED is off) or a space separated list of one or more:

link: LED's normal state reflects whether the link is up (has carrier) or not
tx:   LED blinks on transmitted data
rx:   LED blinks on receive data

Note that 'link' considers any port speed mask that may be applicable.
e.g. if an LED is configured to indicate 1Gbit link speed and mode is
set to 'link rx tx' but the port is connected at 100Mbit then the LED
will not light or blink. A mode of 'tx rx' will blink in the presence of
traffic only if the port matches the rate (if configured)
This maintains compatibility with existing behaviour.

Attribute is 'link tx rx' by default for backwards compatible behaviour.

Many thanks to Thibaut Varene for providing a more sensible led_event
routine after I had mangled the original, and other coding style hints.

Signed-off-by: Kevin Darbyshire-Bryant 
Acked-by: Thibaut VARENE 
---
 .../generic/files/drivers/net/phy/swconfig_leds.c  | 157 ++---
 1 file changed, 137 insertions(+), 20 deletions(-)

diff --git a/target/linux/generic/files/drivers/net/phy/swconfig_leds.c 
b/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
index 20b9a12..91824b7 100644
--- a/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
+++ b/target/linux/generic/files/drivers/net/phy/swconfig_leds.c
@@ -29,6 +29,15 @@
 SWCONFIG_LED_PORT_SPEED_100 | \
 SWCONFIG_LED_PORT_SPEED_1000)
 
+#define SWCONFIG_LED_MODE_LINK 0x01
+#define SWCONFIG_LED_MODE_TX   0x02
+#define SWCONFIG_LED_MODE_RX   0x04
+#define SWCONFIG_LED_MODE_TXRX (SWCONFIG_LED_MODE_TX   | \
+SWCONFIG_LED_MODE_RX)
+#define SWCONFIG_LED_MODE_ALL  (SWCONFIG_LED_MODE_LINK | \
+SWCONFIG_LED_MODE_TX   | \
+SWCONFIG_LED_MODE_RX)
+
 struct switch_led_trigger {
struct led_trigger trig;
struct switch_dev *swdev;
@@ -36,7 +45,8 @@ struct switch_led_trigger {
struct delayed_work sw_led_work;
u32 port_mask;
u32 port_link;
-   unsigned long long port_traffic[SWCONFIG_LED_NUM_PORTS];
+   unsigned long long port_tx_traffic[SWCONFIG_LED_NUM_PORTS];
+   unsigned long long port_rx_traffic[SWCONFIG_LED_NUM_PORTS];
u8 link_speed[SWCONFIG_LED_NUM_PORTS];
 };
 
@@ -50,6 +60,7 @@ struct swconfig_trig_data {
bool prev_link;
unsigned long prev_traffic;
enum led_brightness prev_brightness;
+   u8 mode;
u8 speed_mask;
 };
 
@@ -113,18 +124,16 @@ swconfig_trig_port_mask_store(struct device *dev, struct 
device_attribute *attr,
return ret;
 
write_lock(_data->lock);
-
changed = (trig_data->port_mask != port_mask);
+   trig_data->port_mask = port_mask;
+   write_unlock(_data->lock);
+
if (changed) {
-   trig_data->port_mask = port_mask;
if (port_mask == 0)
swconfig_trig_set_brightness(trig_data, LED_OFF);
-   }
-
-   write_unlock(_data->lock);
 
-   if (changed)
swconfig_trig_update_port_mask(led_cdev->trigger);
+   }
 
return size;
 }
@@ -135,11 +144,14 @@ swconfig_trig_port_mask_show(struct device *dev, struct 
device_attribute *attr,
 {
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct swconfig_trig_data *trig_data = led_cdev->trigger_data;
+   u32 port_mask;
 
read_lock(_data->lock);
-   sprintf(buf, "%#x\n", trig_data->port_mask);
+   port_mask = trig_data->port_mask;
read_unlock(_data->lock);
 
+   sprintf(buf, "%#x\n", port_mask);
+
return strlen(buf) + 1;
 }
 
@@ -153,11 +165,14 @@ static ssize_t swconfig_trig_speed_mask_show(struct 
device *dev,
 {
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct swconfig_trig_data *trig_data = led_cdev->trigger_data;
+   u8 speed_mask;
 
read_lock(_data->lock);
-   sprintf(buf, "%#x\n", trig_data->speed_mask);
+   speed_mask = trig_data->speed_mask;
read_unlock(_data->lock);
 
+   sprintf(buf, "%#x\n", speed_mask);
+
return strlen(buf) + 1;
 }
 
@@ -186,6 +201,79 @@ static ssize_t

[LEDE-DEV] Available for consulting services/contracting

2017-10-05 Thread Philip Prindeville 
Hi all,

I’m available for LEDE/OpenWrt contracting work (platform bring-up, adding new 
packages, porting applications to the LEDE environment, customization, etc) if 
there’s such a need.

I’m on LinkedIn: https://www.linkedin.com/in/philipprindeville/ and GitHub as 
pprindeville, of course.

Please contact me out-of-band.

Thanks,

-Philip


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

Re: [LEDE-DEV] No wireless on TDW8970 due to lack of PCI_SUPPORT

2017-10-05 Thread Mathias Kresin 

05.10.2017 09:00, David Woodhouse:

I updated my TDW8970 from 17.01.1 to 17.01.3 last night and it came up
without wireless. It looks like I *couldn't* enable kmod-ath9k.

Config at http://david.woodhou.se/tdw8970.config-20171005


Your config works for me with 17.01.3. kmod-ath9k is selected as build-in.

I'm using 17.01.3 on a different xrx200 board with ath9k and ath10k 
without the reported issue. The PCI_SUPPORT flag is derived from the 
kernel config (CONFIG_PCI?) which is the same for all xrx200 boards.


Something in your local tree/build_dir is most likely dirty. Try to 
remove the tmp/ dir and if it doesn't fix the issue do a distclean.


Btw. your config looks a bit more custom than necessary to me. Could it 
be that you are using the same .config instead only the output of 
./scripts/diffconfig.sh + make defconfig as base for new builds?


Mathias

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

[LEDE-DEV] No wireless on TDW8970 due to lack of PCI_SUPPORT

2017-10-05 Thread David Woodhouse 
I updated my TDW8970 from 17.01.1 to 17.01.3 last night and it came up
without wireless. It looks like I *couldn't* enable kmod-ath9k.

This (adding pci feature) didn't seem to help:

--- a/target/linux/lantiq/xrx200/target.mk
+++ b/target/linux/lantiq/xrx200/target.mk
@@ -1,7 +1,7 @@
 ARCH:=mips
 SUBTARGET:=xrx200
 BOARDNAME:=XRX200
-FEATURES:=squashfs atm nand ubifs
+FEATURES:=squashfs nand pci
 CPU_TYPE:=24kc


This did, but obviously isn't the right solution:

--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -194,7 +194,7 @@ endef
 define KernelPackage/ath
   $(call KernelPackage/mac80211/Default)
   TITLE:=Atheros common driver part
-  DEPENDS+= @PCI_SUPPORT||USB_SUPPORT||TARGET_ar71xx||TARGET_ath25 
+kmod-mac80211
+  DEPENDS+= +kmod-mac80211
   FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath.ko
   MENU:=1
 endef
@@ -222,7 +222,7 @@ define KernelPackage/ath9k-common
   TITLE:=Atheros 802.11n wireless devices (common code for ath9k and ath9k_htc)
   URL:=https://wireless.wiki.kernel.org/en/users/drivers/ath9k
   HIDDEN:=1
-  DEPENDS+= @PCI_SUPPORT||USB_SUPPORT||TARGET_ar71xx +kmod-ath 
+@DRIVER_11N_SUPPORT +@DRIVER_11W_SUPPORT +@KERNEL_RELAY
+  DEPENDS+= +kmod-ath +@DRIVER_11N_SUPPORT +@DRIVER_11W_SUPPORT +@KERNEL_RELAY
   FILES:= \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k_common.ko \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k_hw.ko
@@ -232,7 +232,7 @@ define KernelPackage/ath9k
   $(call KernelPackage/mac80211/Default)
   TITLE:=Atheros 802.11n PCI wireless cards support
   URL:=https://wireless.wiki.kernel.org/en/users/drivers/ath9k
-  DEPENDS+= @PCI_SUPPORT||TARGET_ar71xx +kmod-ath9k-common
+  DEPENDS+= +kmod-ath9k-common
   FILES:= \
$(PKG_BUILD_DIR)/drivers/net/wireless/ath/ath9k/ath9k.ko
   AUTOLOAD:=$(call AutoProbe,ath9k)


Config at http://david.woodhou.se/tdw8970.config-20171005





smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/3] mktplinkfw2: use hw rev for board detection too

2017-10-05 Thread Mathias Kresin 

05.10.2017 01:20, Sergey Ryazanov:

On Mon, Oct 2, 2017 at 2:33 AM, Sergey Ryazanov  wrote:

Some boards have identical hardware id and differ only in hardware
revision (e.g. Acher C20 and Archer C20i). Such case confuse image
inspection code and it selects wrong board info structure.

Rework the board detection code to make it consider the hw revision
field. Now it returns best match board info:
* if possible then return board info with matched hw_id & hw_rev
* otherwise return first board info with matched hw_id (fallback to old
   behaviour)



This patch by some cause is not picked up by patchwork. Should I resend it?


Hey Sergey,

please hold on with resending the patch.

At the moment I'm reviewing 
https://github.com/lede-project/source/pull/1399 which will make your 
patch obsolete by removing the code you're patching.


The PR drops any hardcoded board params from mktplinkfw2.c in favour of 
commandline arguments, to provide only one way of creating tp-link 
images. It has the nice benefit that this file most likely doesn't need 
to be touched any more if new tp-link boards gets added.


Would be nice if you can give the PR a try to test for regressions.

Mathias

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