summaryrefslogtreecommitdiff
path: root/res
diff options
context:
space:
mode:
authorArne Schwabe <arne@rfc2549.org>2012-10-26 14:41:24 +0200
committerArne Schwabe <arne@rfc2549.org>2012-10-26 14:41:24 +0200
commitfd1dbd411e61ad12e79fab7d700782dd76135232 (patch)
tree632f8087651bc1d8694b0bf78e2725fc17291f8a /res
parent2a17ef5099efd05fe69c0e1eaf8b8445fc178304 (diff)
- Increase Version
- Add FAQ Entry for energy consumption
Diffstat (limited to 'res')
-rw-r--r--res/layout/faq.xml8
-rw-r--r--res/values/strings.xml2
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. &lt;p> While these packets are small and do not use much traffic, they keep the mobile radio network busy and increase the energy consumption. &lt;p> This keepalive setting cannot be changed on the client. Only the system administrator of the OpenVPN can change the setting. &lt;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 &lt;a href=\"http://sites.inka.de/bigred/devel/tcp-tcp.html\">Why TCP Over TCP Is A Bad Ide&lt;/a>)</string>
</resources>