date:20131014

[OpenWrt-Devel] [PATCH] [packages] openvpn: make comp_lzo a parameter

2013-10-14 Thread Philipp Borgers

Possible parameters are yes, no and adaptive. See manpage for more information.

Signed-off-by: Philipp Borgers 
---
 package/network/services/openvpn/files/openvpn.config | 4 ++--
 package/network/services/openvpn/files/openvpn.init   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/network/services/openvpn/files/openvpn.config 
b/package/network/services/openvpn/files/openvpn.config
index 4a1f667..5cf0ba6 100644
--- a/package/network/services/openvpn/files/openvpn.config
+++ b/package/network/services/openvpn/files/openvpn.config
@@ -241,7 +241,7 @@ config openvpn sample_server
# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
-   option comp_lzo 1
+   option comp_lzo yes
 
# The maximum number of concurrently connected
# clients we want to allow.
@@ -389,7 +389,7 @@ config openvpn sample_client
# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
-   option comp_lzo 1
+   option comp_lzo yes
 
# Set log file verbosity.
option verb 3
diff --git a/package/network/services/openvpn/files/openvpn.init 
b/package/network/services/openvpn/files/openvpn.init
index eaf46c4..dee5925 100644
--- a/package/network/services/openvpn/files/openvpn.init
+++ b/package/network/services/openvpn/files/openvpn.init
@@ -78,7 +78,7 @@ start_instance() {
# append flags
append_bools "$s" \
auth_nocache auth_retry auth_user_pass_optional bind 
ccd_exclusive client client_cert_not_required \
-   client_to_client comp_lzo comp_noadapt disable \
+   client_to_client comp_noadapt disable \
disable_occ down_pre duplicate_cn fast_io float 
http_proxy_retry \
ifconfig_noexec ifconfig_nowarn ifconfig_pool_linear 
management_forget_disconnect management_hold \
management_query_passwords management_signal mktun mlock 
mtu_test multihome mute_replay_warnings \
@@ -91,7 +91,7 @@ start_instance() {
# append params
append_params "$s" \
cd askpass auth auth_user_pass auth_user_pass_verify 
bcast_buffers ca cert \
-   chroot cipher client_config_dir client_connect 
client_disconnect connect_freq \
+   chroot cipher client_config_dir client_connect 
client_disconnect comp_lzo connect_freq \
connect_retry connect_timeout connect_retry_max crl_verify dev 
dev_node dev_type dh \
echo engine explicit_exit_notify fragment group hand_window 
hash_size \
http_proxy http_proxy_option http_proxy_timeout ifconfig 
ifconfig_pool \
-- 
1.8.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

2013-10-14 Thread Ben West

Hi Felix,

I've tried testing both AA r38347 as-is, and also AA recompiled with the
back-ported copies of hostapd and mac80211 packages that you provided on
your git repo (thank you!).  Unfortunately, in both instances, I saw the
adhoc link between two Engenius EOC-1650 freeze entirely during a long wget
transfer.  That is, the transfer itself stalls, even ping packages don't
pass.  Several minutes after stopping the wget transfer, the adhoc returns
to normal.

Here are rate control stats on the remote node (i.e. the one not connected
to a wired LAN) before and after attempting the long wget transfer:

BEFORE

root@WasabiNet-mushmaus:~# cat
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
rate  throughput  ewma prob  this prob  this succ/attempt   success
attempts
   1 0.00.00.0 0(  5)
145783
   2 0.7   37.30.0 0(  1)
548 956
P  5.5   4.9   91.3  100.0 1(  1)
158 395
   D  11 6.0   59.1  100.0 0(  0)
267 643
   6 1.8   30.60.0 0(  0)
231 508
   9 3.3   37.20.0 0(  0)
349 727
  12 4.6   39.3   33.3 0(  0)
6411106
  C   18 6.0   34.80.0 0(  0)
351 698
 B2410.6   46.9  100.0 1(  1)
63 326
  36 4.6   14.20.0 0(  6)
156 627
  48 0.00.10.0 0(  0)
7712441
A 5424.2   52.3   33.3 1(  3)
8422721

Total packet count::ideal 5951  lookaround 664

AFTER

root@WasabiNet-mushmaus:~# cat
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
rate  throughput  ewma prob  this prob  this succ/attempt   success
attempts
   1 0.00.00.0 0(  6)
18   25581
   2 0.3   18.20.0 0(  0)
5641122
   5.5   3.3   62.0  100.0 0(  0)
4761159
  11 5.5   54.4  100.0 0(  0)
3391024
   6 2.2   37.7  100.0 0(  0)
39005892
   9 3.1   35.30.0 0(  0)
6141313
   D  12 7.9   67.0  100.0 0(  0)
6601374
  C   18 9.6   55.8   50.0 0(  0)
5361509
  24 3.7   16.5   33.3 0(  0)
2641248
  36 6.7   20.90.0 0(  0)
166 867
A   P 4827.9   67.2  100.0 0(  0)
16825160
 B5413.4   29.0   33.3 0(  0)
3788   10223

Total packet count::ideal 8510  lookaround 946

On both devices running AA r36669, long wget transfers work fine.  In my
instance, the transfers averaged to 415Bytes/sec over a single test that
moved 2GBytes.  For comparison, below are the rc_stats on this same device
running AA r36669, before and after a successful long transfer. I do notice
that r36669 reports 0 throughput at higher rates like 54Mbit/s, unlike
r38347.  Maybe throughput is being measured inaccurately?

BEFORE

root@WasabiNet-mushmaus:~# cat
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats

rate throughput  ewma prob   this prob  this succ/attempt   success
attempts
   1 0.5   52.2  100.0  0(  0)
25  39
   2 1.2   63.0  100.0  0(  0)
4   7
   5.5   3.1   58.9  100.0  0(  0)
4   6
 B  P 11 8.7   86.0  100.0  0(  0)
10  11
   6 4.0   66.8  100.0  0(  0)
5   6
   9 4.7   52.50.0  0(  0)
79 167
  C   12 7.3   62.2  100.0  0(  0)
4  11
A 1811.7   67.5   50.0  1(  2)
587 969
   D  24 5.0   22.2   19.9  0(  0)
4  34
  36 0.00.00.0  0(  0)
0  12
  48 0.00.00.0  0(  0)
0  12
  54 0.00.00.0  0(  0)
0  12

Total packet count::ideal 653  lookaround 72

AFTER

root@WasabiNet-mushmaus:~# cat
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
rate throughput  ewma prob   this prob  this succ/attempt   success
attempts
   1 0.00.00.0  0(  0)   1657
32236
   2 1.2   60.5  100.0  0(  0)   8632
16530
   5.5   1.6   31.30.0

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

2013-10-14 Thread Ben West

Also, sorry for typo: "transfers averaged to *415KBytes/sec* ..."


On Mon, Oct 14, 2013 at 10:55 AM, Ben West  wrote:

> Hi Felix,
>
> I've tried testing both AA r38347 as-is, and also AA recompiled with the
> back-ported copies of hostapd and mac80211 packages that you provided on
> your git repo (thank you!).  Unfortunately, in both instances, I saw the
> adhoc link between two Engenius EOC-1650 freeze entirely during a long wget
> transfer.  That is, the transfer itself stalls, even ping packages don't
> pass.  Several minutes after stopping the wget transfer, the adhoc returns
> to normal.
>
> Here are rate control stats on the remote node (i.e. the one not connected
> to a wired LAN) before and after attempting the long wget transfer:
>
> BEFORE
>
> root@WasabiNet-mushmaus:~# cat
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> rate  throughput  ewma prob  this prob  this succ/attempt   success
> attempts
>1 0.00.00.0 0(  5)
> 145783
>2 0.7   37.30.0 0(  1)
> 548 956
> P  5.5   4.9   91.3  100.0 1(  1)
> 158 395
>D  11 6.0   59.1  100.0 0(  0)
> 267 643
>6 1.8   30.60.0 0(  0)
> 231 508
>9 3.3   37.20.0 0(  0)
> 349 727
>   12 4.6   39.3   33.3 0(  0)
> 6411106
>   C   18 6.0   34.80.0 0(  0)
> 351 698
>  B2410.6   46.9  100.0 1(  1)
> 63 326
>   36 4.6   14.20.0 0(  6)
> 156 627
>   48 0.00.10.0 0(  0)
> 7712441
> A 5424.2   52.3   33.3 1(  3)
> 8422721
>
> Total packet count::ideal 5951  lookaround 664
>
> AFTER
>
> root@WasabiNet-mushmaus:~# cat
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> rate  throughput  ewma prob  this prob  this succ/attempt   success
> attempts
>1 0.00.00.0 0(  6)
> 18   25581
>2 0.3   18.20.0 0(  0)
> 5641122
>5.5   3.3   62.0  100.0 0(  0)
> 4761159
>   11 5.5   54.4  100.0 0(  0)
> 3391024
>6 2.2   37.7  100.0 0(  0)
> 39005892
>9 3.1   35.30.0 0(  0)
> 6141313
>D  12 7.9   67.0  100.0 0(  0)
> 6601374
>   C   18 9.6   55.8   50.0 0(  0)
> 5361509
>   24 3.7   16.5   33.3 0(  0)
> 2641248
>   36 6.7   20.90.0 0(  0)
> 166 867
> A   P 4827.9   67.2  100.0 0(  0)
> 16825160
>  B5413.4   29.0   33.3 0(  0)
> 3788   10223
>
> Total packet count::ideal 8510  lookaround 946
>
> On both devices running AA r36669, long wget transfers work fine.  In my
> instance, the transfers averaged to 415Bytes/sec over a single test that
> moved 2GBytes.  For comparison, below are the rc_stats on this same device
> running AA r36669, before and after a successful long transfer. I do notice
> that r36669 reports 0 throughput at higher rates like 54Mbit/s, unlike
> r38347.  Maybe throughput is being measured inaccurately?
>
> BEFORE
>
> root@WasabiNet-mushmaus:~# cat
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
>
> rate throughput  ewma prob   this prob  this succ/attempt   success
> attempts
>1 0.5   52.2  100.0  0(  0)
> 25  39
>2 1.2   63.0  100.0  0(  0)
> 4   7
>5.5   3.1   58.9  100.0  0(  0)
> 4   6
>  B  P 11 8.7   86.0  100.0  0(  0)
> 10  11
>6 4.0   66.8  100.0  0(  0)
> 5   6
>9 4.7   52.50.0  0(  0)
> 79 167
>   C   12 7.3   62.2  100.0  0(  0)
> 4  11
> A 1811.7   67.5   50.0  1(  2)
> 587 969
>D  24 5.0   22.2   19.9  0(  0)
> 4  34
>   36 0.00.00.0  0(  0)
> 0  12
>   48 0.00.00.0  0(  0)
> 0  12
>   54 0.00.00.0  0(  0)
> 0  12
>
> Total packet count::ideal 653  lookaround 72
>
> AFTER
>
> root@WasabiNet-mushmaus:~# cat
> /sys/kernel/debug/i

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

2013-10-14 Thread Felix Fietkau

Hi Ben,

please try copying this patch to package/mac80211/patches (with the new
version): http://nbd.name/990-ath5k_fix.patch
I checked the ath5k diff between the old and the new version, and the
only relevant change seems to be a rate control related rework.

- Felix

On 2013-10-14 5:56 PM, Ben West wrote:
> Also, sorry for typo: "transfers averaged to *415KBytes/sec* ..."
> 
> 
> On Mon, Oct 14, 2013 at 10:55 AM, Ben West  > wrote:
> 
> Hi Felix,
> 
> I've tried testing both AA r38347 as-is, and also AA recompiled with
> the back-ported copies of hostapd and mac80211 packages that you
> provided on your git repo (thank you!).  Unfortunately, in both
> instances, I saw the adhoc link between two Engenius EOC-1650 freeze
> entirely during a long wget transfer.  That is, the transfer itself
> stalls, even ping packages don't pass.  Several minutes after
> stopping the wget transfer, the adhoc returns to normal.
> 
> Here are rate control stats on the remote node (i.e. the one not
> connected to a wired LAN) before and after attempting the long wget
> transfer:
> 
> BEFORE
> 
> root@WasabiNet-mushmaus:~# cat
> 
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> rate  throughput  ewma prob  this prob  this succ/attempt  
> successattempts
>1 0.00.00.0 0(  5)   
> 145783
>2 0.7   37.30.0 0(  1)  
> 548 956
> P  5.5   4.9   91.3  100.0 1(  1)  
> 158 395
>D  11 6.0   59.1  100.0 0(  0)  
> 267 643
>6 1.8   30.60.0 0(  0)  
> 231 508
>9 3.3   37.20.0 0(  0)  
> 349 727
>   12 4.6   39.3   33.3 0(  0)  
> 6411106
>   C   18 6.0   34.80.0 0(  0)  
> 351 698
>  B2410.6   46.9  100.0 1(  1)   
> 63 326
>   36 4.6   14.20.0 0(  6)  
> 156 627
>   48 0.00.10.0 0(  0)  
> 7712441
> A 5424.2   52.3   33.3 1(  3)  
> 8422721
> 
> Total packet count::ideal 5951  lookaround 664
> 
> AFTER
> 
> root@WasabiNet-mushmaus:~# cat
> 
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> rate  throughput  ewma prob  this prob  this succ/attempt  
> successattempts
>1 0.00.00.0 0(  6)   
> 18   25581
>2 0.3   18.20.0 0(  0)  
> 5641122
>5.5   3.3   62.0  100.0 0(  0)  
> 4761159
>   11 5.5   54.4  100.0 0(  0)  
> 3391024
>6 2.2   37.7  100.0 0(  0) 
> 39005892
>9 3.1   35.30.0 0(  0)  
> 6141313
>D  12 7.9   67.0  100.0 0(  0)  
> 6601374
>   C   18 9.6   55.8   50.0 0(  0)  
> 5361509
>   24 3.7   16.5   33.3 0(  0)  
> 2641248
>   36 6.7   20.90.0 0(  0)  
> 166 867
> A   P 4827.9   67.2  100.0 0(  0) 
> 16825160
>  B5413.4   29.0   33.3 0(  0) 
> 3788   10223
> 
> Total packet count::ideal 8510  lookaround 946
> 
> On both devices running AA r36669, long wget transfers work fine. 
> In my instance, the transfers averaged to 415Bytes/sec over a single
> test that moved 2GBytes.  For comparison, below are the rc_stats on
> this same device running AA r36669, before and after a successful
> long transfer. I do notice that r36669 reports 0 throughput at
> higher rates like 54Mbit/s, unlike r38347.  Maybe throughput is
> being measured inaccurately?
> 
> BEFORE
> 
> root@WasabiNet-mushmaus:~# cat
> 
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> 
> rate throughput  ewma prob   this prob  this succ/attempt  
> successattempts
>1 0.5   52.2  100.0  0(  0)
> 25  39
>2 1.2   63.0  100.0  0(  0) 
> 4   7
>

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

2013-10-14 Thread Felix Fietkau

Hi Ben,

On 2013-10-14 9:01 PM, Ben West wrote:
> Hi Felix,
> 
> This is fabulous.  The adhoc link between the 2 Engenius nodes now
> passed the 2Gbyte transfer test, running AA r38347 with the hostapd +
> mac80211 backports/patches which you have provided.  In addition, I
> measured a mild speed increase from avg *423Kbytes/sec* with AA r36669
> to *505Kbytes/sec* with the patched AA r38347.
Thanks for testing. I've committed this fix to both trunk and 12.09, and
I've also submitted it to linux-wireless for upstream inclusion (you've
been Cc'd).

> For others following this thread, I'm including the bzipped diffs of my
> local AA r38347 build tree.  These diffs contain Felix's proposed
> backports to AA for the packages mac80211 and hostapd, including the
> ath5k rate control patch Felix just offered today.  Likewise, my hostapd
> diff also includes a patch to restore the "beacon_int" parameter in
> /etc/config/wireless, which has been mentioned in a couple other recent
> threads.
> 
> Are additional steps needed to get these backports committed into AA? 
> Including the beacon_int patch?
I'll look into it. At some point in the near future, I plan on
backporting the full mac80211 and hostapd packages to AA.

> Thank you!
> 
> P.S. Good meeting you earlier this month at IS4CWN.
Good meeting you too.

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

[OpenWrt-Devel] [PATCH] dropbear: add dropbear.nl mirror, provided by dropbear maintainer

2013-10-14 Thread Catalin Patulea


Signed-off-by: Catalin Patulea 
---
 package/network/services/dropbear/Makefile |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/network/services/dropbear/Makefile 
b/package/network/services/dropbear/Makefile
index f025c4d..02be761 100644
--- a/package/network/services/dropbear/Makefile
+++ b/package/network/services/dropbear/Makefile
@@ -13,7 +13,8 @@ PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_URL:= \
-   http://matt.ucc.asn.au/dropbear/releases/
+   http://matt.ucc.asn.au/dropbear/releases/ \
+   https://dropbear.nl/mirror/releases/
 PKG_MD5SUM:=6c1e6c2c297f4034488ffc95e8b7e6e9
 
 PKG_LICENSE:=MIT
-- 
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ar71xx / hang during early boot in kernel loader

2013-10-14 Thread Nicolás Echániz

El 13/10/13 16:57, Bastian Bittorf escribió:
>>> the board is ok, no need for replacing it. we have several 1000
>>> boards,
>>> and we see that everyday some of them are hanging in this situation
>>> (right after nightly reboot). statistically that means:
>>>
>>> if you reboot a board ever night, than it will 'hang' once a year.
>>> also read http://en.wikipedia.org/wiki/Soft_error
>>> and http://en.wikipedia.org/wiki/Single-event_upset
>>>
>> Hm. In this case, it matters. From your first message, I realized that
>> the same board constantly can not boot. And in such situation, would
>> be nice add capability of reboot to the mainstream loader.
>>
>> Allow me to ask, why do you reboot the equipment every night?
> 
> the only reason is 'cleanup' and fallback to normal operation if
> something very stupid happens. we deciced to use this "russian method",
> after realizing, that there is always one error more we did'nt catch.
> 
> we use a 'maintenance window' at ~4 o'clock to do that. it has
> more advantages, than disadvantages...


we came to the same conclusion and reboot every day at 5AM. There are
only 40 nodes but we never saw the symptom you described yet; maybe it's
just statistic luck :P
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] [packages] openvpn: make comp_lzo a parameter

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[OpenWrt-Devel] [PATCH] dropbear: add dropbear.nl mirror, provided by dropbear maintainer

Re: [OpenWrt-Devel] ar71xx / hang during early boot in kernel loader

7 matches

Site Navigation

Mail list logo

Footer information