Re: [OpenWrt-Devel] [Battlemesh] the cerowrt project's letter to the fcc about the wifi lockdown is nearly final

2015-10-06 Thread Linus Lüssing 
On Tue, Oct 06, 2015 at 04:21:38PM +0200, Benjamin Henrion wrote:
> On Tue, Oct 6, 2015 at 3:49 PM, Linus Lüssing  
> wrote:
> > On Tue, Oct 06, 2015 at 02:13:36AM +0200, Dave Taht wrote:
> >> Comment away!
> >
> > There are many good points made in this text.
> >
> > I like the Volkswagen example and the suggestion to require
> > opening up the firmware.
> >
> > For the latter, had been thinking about that before briefly,
> > but kind of dismissed it early, basically because the reasoning in
> > my head was that FCC shouldn't make any requirements regarding
> > the form of the software at all. They should only regulate the
> > result.
> 
> Blobs cannot be trusted to do the right thing.

I know (and I guess we all do here?). I don't get the purpose of
this comment, sorry :(.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] comgt-ncm: Add possibility to choose PDP context type

2015-10-06 Thread Andreas Fritiofson 
>> Date: Sun, 20 Sep 2015 23:52:32 +0300
>> Subject: Re: [OpenWrt-Devel] [PATCH] comgt-ncm: Add possibility to
>> choose PDP context type
>> From: sami at olmari.fi
>> To: malaakso at elisanet.fi
>> CC: openwrt-devel at lists.openwrt.org
>>
>> This is not working with Huawei E3276, only "option pdptype 'IP' works,
>> IPV6 and IPV4V6... I do not have IPv6 offered from ISP currently,
>> should it matter. At attachment there is clips from the log using each
>> option type, most important clip here, same for IPV4V6 (aka no option
>> set):
>>
>> Sun Sep 20 20:32:10 2015 daemon.notice netifd: wan (2935): sending ->
>> AT+CGDCONT=1,"IPV6","opengate"
>> Sun Sep 20 20:32:11 2015 daemon.notice netifd: wan (2935): Error
>> running AT-command
>> Sun Sep 20 20:32:11 2015 daemon.notice netifd: wan (2935): Failed to
>> initialize modem
>>
>> There is also some random other errors seen on log on _working_
>> connection, I don't know do they bear any importance, as system works.
>> Anything I could do to make it work so that it wouldn't at least fail?
>>
>>   Sami Olmari
>>
>> P.S. I've updated wiki with this new option information :)
>>
>
> Hi,
>
> If you don't have IPv6 from your ISP, then that is expected. That doesn't
change
> the fact that my patch does introduce a regression for those without
IPv6, them
> having to manually disable it (setting ipv6 to 0 selects "IP" by
default). I'll have to
> think the defaults through again, most likely changing PDP type "IP" to
be the
> default unless IPv6 is explicitely _enabled_.
>
> Thanks for reporting!
>
> Matti

Hi there!

I noticed this regression today after upgrading to trunk. I don't think
this is the complete answer though.

I have the same E3276 dongle and I *do* have IPv6 from my ISP (Tele2,
Sweden). The same SIM-card in a B593s-22 router gets me a native IPv6
connection.

I see the exact same error in the logs and I've verified that E3276 doesn't
accept IPV6 (or IPV4V6, or ... ) as the second parameter by manually echo
-e 'AT+CGDCONT=1,"IPV6","internet.tele2.se",""\r' > /dev/cdc-wdm0. Only
"IP" works.

Is the AT+CGDCONT command the correct way to select the PDP type on Huawei
NCM dongles? What info is that based on?

If there's something you want me to try, just shout.

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

[OpenWrt-Devel] [PATCH] kobs-ng: Fix build for musl

2015-10-06 Thread Pushpal Sidhu 
Fixes https://dev.openwrt.org/ticket/20077

Signed-off-by: Pushpal Sidhu 
---
 ...-mtd-fix-implicit-declaration-of-offsetof.patch | 25 +++
 .../004-mtd-define-missing-type-in-musl.patch  | 28 ++
 2 files changed, 53 insertions(+)
 create mode 100644 
package/boot/kobs-ng/patches/003-mtd-fix-implicit-declaration-of-offsetof.patch
 create mode 100644 
package/boot/kobs-ng/patches/004-mtd-define-missing-type-in-musl.patch

diff --git 
a/package/boot/kobs-ng/patches/003-mtd-fix-implicit-declaration-of-offsetof.patch
 
b/package/boot/kobs-ng/patches/003-mtd-fix-implicit-declaration-of-offsetof.patch
new file mode 100644
index 000..01353aa
--- /dev/null
+++ 
b/package/boot/kobs-ng/patches/003-mtd-fix-implicit-declaration-of-offsetof.patch
@@ -0,0 +1,25 @@
+From f3f836c78f27c7b302b4c1ae49c44109f313ad44 Mon Sep 17 00:00:00 2001
+From: Pushpal Sidhu 
+Date: Thu, 24 Sep 2015 10:28:17 -0700
+Subject: [PATCH] mtd: fix implicit declaration of 'offsetof'
+
+Signed-off-by: Pushpal Sidhu 
+---
+ src/mtd.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/mtd.c b/src/mtd.c
+index 2974814..986b0ae 100644
+--- a/src/mtd.c
 b/src/mtd.c
+@@ -26,6 +26,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+-- 
+2.5.3
+
diff --git 
a/package/boot/kobs-ng/patches/004-mtd-define-missing-type-in-musl.patch 
b/package/boot/kobs-ng/patches/004-mtd-define-missing-type-in-musl.patch
new file mode 100644
index 000..6d23312
--- /dev/null
+++ b/package/boot/kobs-ng/patches/004-mtd-define-missing-type-in-musl.patch
@@ -0,0 +1,28 @@
+From 370d73f4437c4bc3b0d1518768a593b0c44ea429 Mon Sep 17 00:00:00 2001
+From: Pushpal Sidhu 
+Date: Thu, 24 Sep 2015 10:34:29 -0700
+Subject: [PATCH] mtd: define missing type in musl
+
+Signed-off-by: Pushpal Sidhu 
+---
+ src/mtd.h | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/src/mtd.h b/src/mtd.h
+index 99d7887..db5561b 100644
+--- a/src/mtd.h
 b/src/mtd.h
+@@ -31,6 +31,10 @@
+ #include "BootControlBlocks.h"
+ #include "rom_nand_hamming_code_ecc.h"
+ 
++#ifndef loff_t
++#define loff_t off_t
++#endif
++
+ 
//--
+ // Re-definitions of true and false, because the standard ones aren't good
+ // enough?
+-- 
+2.5.3
+
-- 
2.6.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Weird problem with WLAN on RT3662F+RT5392L and iwinfo crash

2015-10-06 Thread Piotr Dymacz 
Hello,

I'm working on support for for Jensen AL3000DG v2 device (ramips
target, currently build on r47048).
The device is similar (but not exactly the same) to Edimax R-6475ND
and Asus RT-N56U.

Short specification:
- RT3662F (for 5 GHz radio)
- RT5392L (for 2,4 GHz radio)
- RTL8367R Gbps switch
- 8 MB SPI NOR FLASH
- 64 MB DDR2 RAM
- 2x PCB antennas (with 2x SE5005L PA for 5 GHz radio)

Support is mostly done, everything seems to work, but during final
tests I encountered a strange problem with WiFi.
I'm not able to use 2,4 GHz radio without enabling 5 GHz radio at the
same time (this problem doesn't exist on OFW).

If I enable both radios in configuration, both are up and I'm able to
connect and use them. The same if I enable only 5 GHz radio (inside
RT3662F) - it's visible and working.
If I enable only 2,4 GHz radio (RT5392L) - it seems to be up (at least
iwinfo and iw report that - see below), but I don't see the SSID in
the air.

I would be grateful for any advice how to debug that.

Full bootlog is available at [1], iw list output at [2] and dts file at [3].

-

Some outputs, only 2,4 GHz radio enabled in config:

root@OpenWrt:/# iwinfo
wlan0 ESSID: "OpenWrt_2G"
  Access Point: 34:21:09:xx:xx:xx
  Mode: Master  Channel: 11 (2.462 GHz)
  Tx-Power: 20 dBm  Link Quality: unknown/70
  Signal: unknown  Noise: unknown
  Bit Rate: unknown
  Encryption: none
  Type: nl80211  HW Mode(s): 802.11bgn
  Hardware: 1814:3091 1814:3091 [Generic MAC80211]
  TX power offset: unknown
  Frequency offset: unknown
  Supports VAPs: yes  PHY name: phy0

wlan1 ESSID: unknown
  Access Point: 00:00:00:00:00:00
  Mode: Client  Channel: unknown (unknown)
  Tx-Power: 0 dBm  Link Quality: unknown/70
  Signal: unknown  Noise: unknown
  Bit Rate: unknown
  Encryption: unknown
  Type: nl80211  HW Mode(s): 802.11an
  Hardware: unknown [Generic MAC80211]
  TX power offset: unknown
  Frequency offset: unknown
  Supports VAPs: yes  PHY name: phy1

root@OpenWrt:/# cat /etc/config/wireless
config wifi-device  radio0
option type mac80211
option channel  11
option hwmode   11g
option path 'pci:00/:00:01.0/:01:00.0'
option htmode   HT20

config wifi-iface
option device   radio0
option network  lan
option mode ap
option ssid OpenWrt_2G
option encryption none

config wifi-device  radio1
option type mac80211
option channel  36
option hwmode   11a
option path '1018.wmac'
option htmode   HT20
option disabled 1

config wifi-iface
option device   radio1
option network  lan
option mode ap
option ssid OpenWrt_5G
option encryption none


[...]
[   15.55] PCI: Enabling device :01:00.0 ( -> 0002)
[   15.56] rt2800pci :01:00.0: failed to load eeprom property
[   15.57] ieee80211 phy0: rt2x00lib_request_eeprom_file: Info -
Loading EEPROM data from 'rt2x00pci_1_0.eeprom'.
[   15.64] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5392,
rev 0223 detected
[   15.65] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 5392 detected
[   15.67] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   15.67] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 3883,
rev 0400 detected
[   15.69] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 3853 detected
[   15.70] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[   24.19] ralink_soc_eth 1010.ethernet eth0: link up
(1000Mbps/Full duplex)
[   24.20] 8021q: adding VLAN 0 to HW filter on device eth0
[   24.22] device eth0.1 entered promiscuous mode
[   24.23] device eth0 entered promiscuous mode
[   24.25] br-lan: port 1(eth0.1) entered forwarding state
[   24.26] br-lan: port 1(eth0.1) entered forwarding state
[   26.26] br-lan: port 1(eth0.1) entered forwarding state
[   26.67] ieee80211 phy0: rt2x00lib_request_firmware: Info -
Loading firmware file 'rt2860.bin'
[   26.71] ieee80211 phy0: rt2x00lib_request_firmware: Info -
Firmware detected - version: 0.34
[   27.00] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   27.01] device wlan0 entered promiscuous mode
[   27.05] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   27.06] br-lan: port 2(wlan0) entered forwarding state
[   27.07] br-lan: port 2(wlan0) entered forwarding state
[   29.07] br-lan: port 2(wlan0) entered forwarding state
[...]

What's more, if I try scan on 2,4 GHz radio... I'm getting this
(r47048), no matter if the 5 GHz radio is enabled or not and only at
first invoke:

root@OpenWrt:/# iwinfo wlan0 scan
[ 1084.50] [ cut here ]
[ 1084.51] WARNING: CPU: 0 PID: 1087 at

Re: [OpenWrt-Devel] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

2015-10-06 Thread Hans Dedecker 
Hi,

The problem occurs in the following scenario where two hosts A and B are in
use on the lan and connected to a router which is doing masquerade on the
wan link.
Host A has a private IP@ (eg 192.168.1.10/24) while host B has a public IP@
(eg 172.18.16.240/24); the router has a public IP@ on the wan in the same
subnet as host B (eg 172.18.16.245/24).
A redirect rule is defined on the router to forward tcp service 8080 to
host A port 80 and translates into following iptables nat rules :

Chain delegate_prerouting (1 references)
 pkts bytes target prot opt in out source
destination
268 prerouting_rule  all  --  *  *   0.0.0.0/0
0.0.0.0/0/* user chain for prerouting */
132 zone_lan_prerouting  all  --  br-lan *   0.0.0.0/0
   0.0.0.0/0
0 0 zone_wan_prerouting  all  --  pppoe-wan *   0.0.0.0/0
 0.0.0.0/0

chain zone_wan_prerouting (1 references)
 pkts bytes target prot opt in out source
destination
0 0 prerouting_wan_rule  all  --  *  *   0.0.0.0/0
   0.0.0.0/0/* user chain for prerouting */
0 0 DNAT   tcp  --  *  *   0.0.0.0/0
0.0.0.0/0tcp spt:8080 /* @redirect[0] */ to:192.168.1.10:80


TCP traffic on pppoe-wan interface with as destination port 172.18.16.245
will be redirected to 192.168.1.10 as expected but if host B runs a similar
tcp service on port 8080 it will be unreachable as traffic directed to
172.18.16.240 will also be re-directed to 192.168.1.10.
The patch tries to fix this issue by using the wan IP address in the
zone_wan_prerouting lookup; in this case traffic destined for 172.18.16.240
will not be redirected.
Chain delegate_prerouting (1 references)
 pkts bytes target prot opt in out source
destination
187 prerouting_rule  all  --  *  *   0.0.0.0/0
0.0.0.0/0/* user chain for prerouting */
187 zone_lan_prerouting  all  --  br-lan *   0.0.0.0/0
   0.0.0.0/0
0 0 zone_wan_prerouting  all  --  pppoe-wan *   0.0.0.0/0
 172.18.16.245

Chain zone_wan_prerouting (1 references)
 pkts bytes target prot opt in out source
destination
0 0 prerouting_wan_rule  all  --  *  *   0.0.0.0/0
   0.0.0.0/0/* user chain for prerouting */
0 0 DNAT   tcp  --  *  *   0.0.0.0/0
0.0.0.0/0tcp spt:8080 /* @redirect[0] */ to:192.168.1.10:80

Output of  fw3 print diff before/after the patch

< iptables -t nat -D delegate_prerouting -i pppoe-wan -j zone_wan_prerouting
< iptables -t nat -A delegate_prerouting -i pppoe-wan -j zone_wan_prerouting
---
> iptables -t nat -D delegate_prerouting -i pppoe-wan -d
172.18.16.245/255.255.255.255 -j zone_wan_prerouting
> iptables -t nat -A delegate_prerouting -i pppoe-wan -d
172.18.16.245/255.255.255.255 -j zone_wan_prerouting

Bye,
Hans

On Thu, Oct 1, 2015 at 10:05 PM, Jo-Philipp Wich  wrote:

> Hi,
>
> wouldn't this break port forwards to hosts not being within the range of
> the on-link lan subnet?
>
> I also read the patch description three times and still am not sure what
> that change attempts to achive.
>
> Can you further explain the problem please and provide a before/after
> "fw3 print" diff so that I better understand your proposed solution?


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

[OpenWrt-Devel] [PATCH v4 1/3] ramips: Add DTS files for HiWiFi HC5x61 models

2015-10-06 Thread Comman Kang 
HiWiFi HC5661/5761/5861 models are manufactured by http://www.hiwifi.com. These 
models have similar hardware specs(MT7620A + 128M DDR2 + 16M flash). This patch 
adds support for them.

The original author is Justin Liu (rss...@gmail.com). I ported the patch to 
trunk and submitted it here with his approval.

Sorry for this last minute change, I had screwed with versioning and sent an 
old patch, which has a extra line in .dtsi file, which breaks the build.  Just 
removing the first 2 lines from HC5XXX.dtsi and everything work fine.

Sorry again.

v4 fix
  1: Fixed compilation problem caused by /dts-v1/; line in HC5XXX.dtsi file.

Signed-off-by: Xiaoning Kang 


diff --git a/target/linux/ramips/dts/HC5661.dts 
b/target/linux/ramips/dts/HC5661.dts
new file mode 100644
index 000..b9a717b
--- /dev/null
+++ b/target/linux/ramips/dts/HC5661.dts
@@ -0,0 +1,32 @@
+/dts-v1/;
+
+/include/ "HC5XXX.dtsi"
+
+/ {
+   compatible = "HC5661", "ralink,mt7620a-soc";
+   model = "HiWiFi HC5661";
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   system {
+   label = "hc5661:blue:system";
+   gpios = < 9 1>;
+   };
+
+   internet {
+   label = "hc5661:blue:internet";
+   gpios = < 11 1>;
+   };
+
+   wlan2g {
+   label = "hc5661:blue:wlan2g";
+   gpios = < 0 1>;
+   };
+
+   wlan5g {
+   label = "hc5661:blue:wlan5g";
+   gpios = < 7 1>;
+   };
+   };
+};
diff --git a/target/linux/ramips/dts/HC5761.dts 
b/target/linux/ramips/dts/HC5761.dts
new file mode 100644
index 000..a10904c
--- /dev/null
+++ b/target/linux/ramips/dts/HC5761.dts
@@ -0,0 +1,32 @@
+/dts-v1/;
+
+/include/ "HC5XXX.dtsi"
+
+/ {
+   compatible = "HC5761", "ralink,mt7620a-soc";
+   model = "HiWiFi HC5761";
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   system {
+   label = "hc5761:blue:system";
+   gpios = < 9 1>;
+   };
+
+   internet {
+   label = "hc5761:blue:internet";
+   gpios = < 11 1>;
+   };
+
+   wlan2g {
+   label = "hc5761:blue:wlan2g";
+   gpios = < 0 1>;
+   };
+
+   wlan5g {
+   label = "hc5761:blue:wlan5g";
+   gpios = < 7 1>;
+   };
+   };
+};
diff --git a/target/linux/ramips/dts/HC5861.dts 
b/target/linux/ramips/dts/HC5861.dts
new file mode 100644
index 000..05857ea
--- /dev/null
+++ b/target/linux/ramips/dts/HC5861.dts
@@ -0,0 +1,92 @@
+/dts-v1/;
+
+/include/ "HC5XXX.dtsi"
+
+/ {
+   compatible = "HC5861", "ralink,mt7620a-soc";
+   model = "HiWiFi HC5861";
+
+   ethernet@1010 {
+   status = "okay";
+   mtd-mac-address = < 0x4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins _pins _pins>;
+   ralink,port-map = "w";
+
+   port@4 {
+   status = "okay";
+   phy-handle = <>;
+   phy-mode = "rgmii";
+   };
+
+   port@5 {
+   status = "okay";
+   phy-handle = <>;
+   phy-mode = "rgmii";
+   };
+
+   mdio-bus {
+   status = "okay";
+
+   phy4: ethernet-phy@4 {
+   reg = <4>;
+   phy-mode = "rgmii";
+   };
+
+   phy5: ethernet-phy@5 {
+   reg = <5>;
+   phy-mode = "rgmii";
+   };
+   };
+   };
+
+   gsw@1011 {
+   ralink,port4 = "gmac";
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   system {
+   label = "hc5861:blue:system";
+   gpios = < 9 1>;
+   };
+
+   wlan2g {
+   label = "hc5861:blue:wlan2g";
+   gpios = < 11 1>;
+   };
+
+   internet {
+   label = "hc5861:blue:internet";
+   gpios = < 0 1>;
+   };
+
+   wlan5g {
+   label = "hc5861:blue:wlan5g";
+   gpios = < 7 1>;
+   };
+
+   turbo {
+   label = "hc5861:blue:turbo";
+   gpios = < 10 1>;
+   };
+   };
+
+   gpio_export {
+   compatible = "gpio-export";
+   #size-cells = <0>;
+
+   usbpower {
+

[OpenWrt-Devel] [PATCH] Hostapd: wait longer for inactive client probe (empty data frame)

2015-10-06 Thread Dmitry Ivanov 
Hostapd: wait longer for inactive client probe (empty data frame).

One second is not enough for some devices to ackowledge null data frame
which is sent at the end of ap_max_inactivity interval. In particular,
this causes severe Wi-Fi instability with Apple iPhone which may take
up to 3 seconds to respond.

Signed-off-by: Dmitry Ivanov 
---
 .../hostapd/patches/470-wait-for-nullfunc-longer.patch| 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 
package/network/services/hostapd/patches/470-wait-for-nullfunc-longer.patch

diff --git 
a/package/network/services/hostapd/patches/470-wait-for-nullfunc-longer.patch 
b/package/network/services/hostapd/patches/470-wait-for-nullfunc-longer.patch
new file mode 100644
index 000..e6bbddd
--- /dev/null
+++ 
b/package/network/services/hostapd/patches/470-wait-for-nullfunc-longer.patch
@@ -0,0 +1,11 @@
+--- a/src/ap/sta_info.h
 b/src/ap/sta_info.h
+@@ -179,7 +179,7 @@ struct sta_info {
+  * AP_DISASSOC_DELAY seconds. Similarly, the station will be deauthenticated
+  * after AP_DEAUTH_DELAY seconds has passed after disassociation. */
+ #define AP_MAX_INACTIVITY (5 * 60)
+-#define AP_DISASSOC_DELAY (1)
++#define AP_DISASSOC_DELAY (3)
+ #define AP_DEAUTH_DELAY (1)
+ /* Number of seconds to keep STA entry with Authenticated flag after it has
+  * been disassociated. */
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] the cerowrt project's letter to the fcc about the wifi lockdown is nearly final

2015-10-06 Thread Linus Lüssing 
On Tue, Oct 06, 2015 at 02:13:36AM +0200, Dave Taht wrote:
> Comment away!

There are many good points made in this text.

I like the Volkswagen example and the suggestion to require
opening up the firmware.

For the latter, had been thinking about that before briefly,
but kind of dismissed it early, basically because the reasoning in
my head was that FCC shouldn't make any requirements regarding
the form of the software at all. They should only regulate the
result.

Actually this text and the VW example convinced me :). And yes,
now I think with that we can push even further, suggesting to
require open and modifiable source code (for the wifi part at
least). The VW example gives us the opportunity and strategic
advantage to be able to demandn more without sounding
unreasonable.

~

Some quotations and remarks:

"'It is our view that the rules appear to regulate the "means" not
the "ends"'"
-> So does the alternate approach in the end, but in the opposite
   "extreme"

"This software contains built-in configurations to ensure that
radios are used in compliance with the local laws and
regulations."
-> "ensure" seems to be a too strong word to me

"is a natural target for both criminal exploitation and
cyberwarfare"
-> Just my personal taste, but I don't like using the word "war"
   for mere economical power play between nations as it seems
   to soften the original meaning of "war", meaning to kill people
   (don't like the term "cryptowars" either - maybe that taste
   might have cultural roots; the word "war" is never used in
   German language in contexts like these while it seems more
   common in the US and probably other countries too?)
   
"It is currently limiting our attempts to fix the ath9k and mt76
devices"
-> What is meant by that exactly? ath9k is open source, binary
   firmwares can't be the issue you mean here... - with "it
   is limiting", do you mean "new, emerging devices with locked
   firmwares are limiting..."? Maybe clarify the "it"?

"If the Commission does not intend to prohibit the upgrade or
replacement of firmware in Wi-Fi devices, rules would be welcomed
that actually encouraged non-destructive interpretations by
equipment vendors."
-> That one might need explanations too. Actually, I think it is
   explained later, with citatitons of vendors. But ending the
   paragraph there leaves a questions mark for quite a while.

~

Not sure how much time is left to work on the text - content wise
everything seems to be in there. Structually maybe a guiding
thread could be worked out a little more. The beginning is good
and mentions and summarizes the main points well. Some points and
explanations seem to be repeated several times after that though.
Maybe things could be "unbloated" a little here and there ;).

Also the recommendations are not quite clear at some points to me.
The "Alternate Approach" and "Recommendations" sections are clear
by mandating open and modifiable firmwares for the wifi parts at
least. But some other parts seem to allude to different
suggestions. For instance as of writing this email, the draft also
contains:

"The portion of the source code that controls the radio is very
small compared to the entirety of the underlying operating system,
Graphical User Interface, routing and switching code, and all the
other functions that make up a modern Wi-Fi router. As such,
restricting the entire firmware to carries with it a lot of
collateral damage by also preventing improvements to these other
parts."

Which seems to reverse the recommendation.


Thanks for this great draft and the work you guys have put into it
so far!

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

Re: [OpenWrt-Devel] [PATCH] Hostapd: wait longer for inactive client probe (empty data frame)

2015-10-06 Thread Felix Fietkau 
On 2015-10-06 14:13, Dmitry Ivanov wrote:
> Hostapd: wait longer for inactive client probe (empty data frame).
> 
> One second is not enough for some devices to ackowledge null data frame
> which is sent at the end of ap_max_inactivity interval. In particular,
> this causes severe Wi-Fi instability with Apple iPhone which may take
> up to 3 seconds to respond.
> 
> Signed-off-by: Dmitry Ivanov 
Applied, thanks. Please also submit this upstream!

Here's the same reminder as the last few times, I made a bit more flashy
this time, hoping that you'll read it ;)

*** FRIENDLY REMINDER, PLEASE READ! ***
* Please do NOT repeat the patch subject in the message body! *
***

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