diff options
author | Arne Schwabe <arne@rfc2549.org> | 2012-10-26 14:41:24 +0200 |
---|---|---|
committer | Arne Schwabe <arne@rfc2549.org> | 2012-10-26 14:41:24 +0200 |
commit | fd1dbd411e61ad12e79fab7d700782dd76135232 (patch) | |
tree | 632f8087651bc1d8694b0bf78e2725fc17291f8a /res | |
parent | 2a17ef5099efd05fe69c0e1eaf8b8445fc178304 (diff) |
- Increase Version
- Add FAQ Entry for energy consumption
Diffstat (limited to 'res')
-rw-r--r-- | res/layout/faq.xml | 8 | ||||
-rw-r--r-- | res/values/strings.xml | 2 |
2 files changed, 10 insertions, 0 deletions
diff --git a/res/layout/faq.xml b/res/layout/faq.xml index dc59131..c4fd57f 100644 --- a/res/layout/faq.xml +++ b/res/layout/faq.xml @@ -34,6 +34,14 @@ <TextView style="@style/faqhead" + android:text="@string/battery_consumption_title" /> + + <TextView + android:id="@+id/faq_battery" + style="@style/faqitem" /> + + <TextView + style="@style/faqhead" android:text="@string/tap_mode" /> <TextView diff --git a/res/values/strings.xml b/res/values/strings.xml index 69fb9e3..a0d1a4f 100644 --- a/res/values/strings.xml +++ b/res/values/strings.xml @@ -227,4 +227,6 @@ <string name="translation">Translation</string> <string name="openvpn_log">OpenVPN Log</string> <string name="import_config">Import OpenVPN configuration</string> + <string name="battery_consumption_title">Battery consumption</string> + <string name="baterry_consumption">In my personal tests the main reason for high battery consumption of OpenVPN are the keepalive packets. Most OpenVPN servers have a configuration directive like \'keepalive 10 60\' which translates to a keepalive packet from client to server and server to client every ten seconds. <p> While these packets are small and do not use much traffic, they keep the mobile radio network busy and increase the energy consumption. <p> This keepalive setting cannot be changed on the client. Only the system administrator of the OpenVPN can change the setting. <p> Unfortunatly using a keepalive larger than 60 seconds with udp has problems with some NAT gateways which terminate the state for a connnection after a short timeout (60s in my tests). Using TCP with long keepalive timeout works but has the TCP over TCP problem. (See <a href=\"http://sites.inka.de/bigred/devel/tcp-tcp.html\">Why TCP Over TCP Is A Bad Ide</a>)</string> </resources> |