Hi,
I have been using NetSentry to monitor my monthly data usage and it always shows three network interfaces:
eth0 - this is WiFi (stupid name, should probably have been wlan0, but on the other hand - who am I to question the wisdom of Sammy)
pdp0 - this seems to be some kind of mobile data
svnet0 - this also seems to be some kind of mobile data
I've always assumed that the reason for both svnet0 and pdp0 to exist was that one was used for 3G traffic and the other one for 2G traffic or something like that. At the end of a month I would normally have had roughly two times as much traffic on pdp0 as on svnet0.
I then installed DroidStats since it has a lot more features that I wanted to try. However, when comparing the two apps I could see that the mobile data counter shown by DroidStats only takes pdp0 into account and this made me start wondering if DroidStats was missing something or if svnet0 interface is actually something else.
I was looking a bit in the NetSentry bug tracker and some people there seem to suggest that one of the interfaces are related to tethering but that makes no sense for me since I don't use the phone for any kind of tethering.
So here's the question: Can somebody shed some light on what these two interfaces are?
Thank you
Hi,
I am the developer of DroidStats and the questition is very good and brought my also a lot of headache (saw the NetSentry issue also a long time ago) . Only pdp0 is used. But a qualified answer would be interesting, especially from people doing some low level stuff. I am also interested in concrete answers to that problem. Maybe to email (Because I don't check here too often) [email protected]
Regards,
Michael
Nitromouse said:
Hi,
I am the developer of DroidStats and the questition is very good and brought my also a lot of headache (saw the NetSentry issue also a long time ago) . Only pdp0 is used. But a qualified answer would be interesting, especially from people doing some low level stuff. I am also interested in concrete answers to that problem. Maybe to email (Because I don't check here too often) [email protected]
Regards,
Michael
Click to expand...
Click to collapse
Hi both of you.
I have done a few small tests here I used the BT5 chroot solution and I tried various configurations of the various connectivity solutions to see what cause the tx and rx packet numbers to change significantly
switched off wifi and data, tried bluetooth nothing, gps a couple of packets, then finally made a call packets went up significantly
since mobile calls are all VoIP based (loosely at least) this is the answer
This interface is used for call traffic and therefore does not need monitoring by your app
At least thats my guess based on five minutes playing around.
Hope this helps
pdp0 is an interface to packet data APN using GERAN/UTRAN connections on the device.
bash-3.2# ls -l /sys/class/net/svnet0/pdp/
-rw-rw-r-- 1 root root 4096 Nov 4 13:40 activate
-rw-rw-r-- 1 root root 4096 Nov 4 13:40 deactivate
-rw-rw-r-- 1 root root 4096 Nov 4 13:40 resume
-rw-rw-r-- 1 root root 4096 Nov 4 13:40 suspend
pdp0 is connected and disconnected using special interface svnet0 (cdc_svnet module). I'm diggin' into it right now and will post with further details.
I'd like to tweak the tcp.rmem settings that come stock. The maximum buffer size (110208 bytes) is quite low for a high speed connection.
I've tried build.prop, init.rc, and init.local.rc. I checked the results with "sysctl -a | grep tcp".
/system/build.prop - no effect (is everybody around the web enjoying placebo?)
net.tcp.buffersize.default=4096,87380,524288,4096,16384,110208
net.tcp.buffersize.wifi=4096,87380,524288,4096,16384,110208
/system/etc/init.local.rc - doesn't seem to be used by the OS?
setprop net.tcp.buffersize.default 4096,87380,524288,4096,16384,110208;
setprop net.tcp.buffersize.wifi 4096,87380,524288,4096,16384,110208;
/init.rc - is seemingly recreated on each boot with some predefined numbers
setprop net.tcp.buffersize.default 4096,87380,524288,4096,16384,110208;
setprop net.tcp.buffersize.wifi 4096,87380,524288,4096,16384,110208;
[in these values the first three #s are receive (min,start,max), second three are send (min,start,max)]. TCP auto adjusts between min and max.
issuing the setprop commands by terminal works but that isn't really ideal.
Are these the default values? What optimized values should we set from the terminal?
You could try smanager to run a script that changes the values.
Sent from my BNTV250 using XDA
defaults are (init.rc):
setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208
setprop net.tcp.buffersize.wifi 4095,87380,110208,4096,16384,110208
the first 110208 in these is the max allowed tcp receive buffer size and it really isn't ideal for say a 10+ mbps connection. A value of 262144 would be more appropriate. Even 524288 perhaps for 20-30 mbps though a 63mbps wifi connection is probably too slow for this to be beneficial.
good idea on just using a custom script.....
I have successfully set up V6 Supercharger Script on CM9 so I would assume it should work on CM7 if that's what you are running. If you want to go that route. May be placebo effect but it seemed to make an improvement in many areas.
Sent from my CM9 Nook Tablet using Tapatalk
swaaye said:
defaults are (init.rc):
setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208
setprop net.tcp.buffersize.wifi 4095,87380,110208,4096,16384,110208
the first 110208 in these is the max allowed tcp receive buffer size and it really isn't ideal for say a 10+ mbps connection. A value of 262144 would be more appropriate. Even 524288 perhaps for 20-30 mbps though a 63mbps wifi connection is probably too slow for this to be beneficial.
good idea on just using a custom script.....
Click to expand...
Click to collapse
I believe (and this is not a 100% sure guarantee) that the stock values are set in the source, in the driver code for the linux networking stack. If that's the case, the easiest way is to run the aforementioned script to just set it to different values on boot.
Can you get values through, say,
Code:
cat /proc/sys/net/ipv4/tcp_mem
?
The default allocated memory is based on system ram. But, if you're on a ~10mbps connection, you're not going to notice much of a pickup over stock with 26kb of tcp buffer. I mean, on a 10MBPS connection you should have low latency (well under 100ms), increasing the buffer won't 'speed it up'.
However, this site recommends setting it to 12MB (12582912), to increase performance on higher-latency connections (essentially, not local connections). Try that?
Hello,
I'm new to the forum, and I've tried to get this working on my own, but I'm stumped and am hoping someone out there can help me out.
I just bought a shiny new Nexus 7 tablet and would like to tether it to my Galaxy S III phone. I'm currently on a pay as you go plan on my phone where I have an "internet browsing" plan (via SpeakOut). This appears to limit my data services so I can't tether my tablet to the phone and get internet service on the tablet. Tethering works fine if the phone is connected to WiFi, an option I don't have when I'm on the train, doing my commute to work.
So, I've been trying to get OpenVPN set up at home to route all my mobile traffic through that and get tethering working for the tablet. But, I'm stuck with getting the tablet to route traffic over the VPN tunnel. The phone itself has no problems connecting and using the VPN link, but the tethered tablet (via WiFi or Bluetooth) gets no service. The best I can do is ping the phone and traceroutes go to the phone, but never get past it.
I've tried to read the man pages for OpenVPN, but each example uses its own IP blocks and it makes piecing it all together really confusing. In any case, I'm hoping someone here can help me out with this setup.
Here's my setup:
Code:
HOME LAN NET: 192.168.1.0/24
HOME GATEWAY: 192.168.1.1
OPENVPN NET: 10.8.0.0/24
OPENVPN SERVER
LAN IP: 192.168.1.116
VPN (internal) IP: 10.8.0.1
VPN (external) IP: 10.8.0.2
PHONE
VPN IP: 10.8.0.6
WIFI TETHER NET: 192.168.43.0/24
WIFI TETHER IP: 192.168.43.1
TABLET
WIFI TETHER IP: 192.168.43.150
Here is my OpenVPN server.conf file:
Code:
port 1194
proto tcp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
route 192.168.43.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
and the client config file for the phone:
Code:
iroute 192.168.43.0 255.255.255.0
Please note, the OpenVPN server is a Mac running OS X 10.7.5 so I use the following script to set up the environment:
Code:
#!/bin/sh
sysctl -w net.inet.ip.fw.enable=1
sysctl -w net.inet.ip.forwarding=1
killall -9 natd
natd -interface en1 -u
ipfw -f flush
ipfw add divert natd ip from any to any via en1
here's my routing table on the server (netstat -rn):
Code:
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGSc 10 31915 en1
10.8/24 10.8.0.2 UGSc 0 0 tun0
10.8.0.2 10.8.0.1 UH 2 0 tun0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 0 765 lo0
169.254 link#5 UCS 0 0 en1
192.168.1 link#5 UCS 3 0 en1
192.168.1.1 98:fc:11:82:7d:4b UHLWIi 11 8799 en1 1171
192.168.1.116 127.0.0.1 UHS 2 153 lo0
192.168.1.120 0:1f:e2:88:af:a9 UHLWIi 0 1678 en1 1165
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 1 98 en1
192.168.43 10.8.0.2 UGSc 0 0 tun0
and the output of ipfw list:
Code:
00100 divert 8668 ip from any to any via en1
65535 allow ip from any to any
Any help with getting this running would be appreciated. Note, NEITHER the phone or tablet is rooted and I'd prefer to keep it that way, if possible. Secondly, I'd prefer to get the tethering set up via Bluetooth, so any guidance on that would be helpful, too. I have no idea how to inspect Bluetooth connectivity, though. Or, if you know a better way to get this tethering to work that doesn't involve OpenVPN I'd love to hear it.
Thanks!
Squeaky
Solution see cross-link
See http://forum.xda-developers.com/showpost.php?p=33749904&postcount=10
Recommended app, i use it to tether all the time
https://play.google.com/store/apps/details?id=com.opengarden.android.MeshClient&hl=en
In a browser google resolves to an address in the 208.54.0.0/16 IP address block (example 208.54.38.51). This range is not owned by Google as far I know and actually resolves to tmodns.net, which is owned by T-Mobile.
Looking through Afwall+ firewall logs shows that before connecting to any Google services, for example downloading an app through the play store, the phone connects with an IP in the same 208.54.0.0/16 range. Using IPTABLES to block this range prevents me from being able to do things like access Google in the browser and download apps through the play store.
If I start transparent proxying through Tor I can connect to Google correctly as well as download apps with no problems.
Can anyone confirm that this happens on their T-Mobile phone? Is there anyway I can prevent this without having to go through Tor? Perhaps by using IPTABLES to redirect any connections to the 208.54.0.0/16 block to an IP owned by Google.
I also have my DNS set to use Google's DNS servers so that shouldn't be the issue. It seems like it's happening inside of T-Mobile's internal 10.*.*.* network before the phone connects to the outside Internet.
Code:
[email protected]:/ $ nslookup google.com
Server: 8.8.4.4
Address 1: 8.8.4.4 google-public-dns-b.google.com
Name: google.com
Address 1: 2404:6800:4005:c00::64
Address 2: 208.54.38.49 m312636d0.tmodns.net
Address 3: 208.54.38.48 m302636d0.tmodns.net
Address 4: 208.54.38.53 m352636d0.tmodns.net
Address 5: 208.54.38.57 m392636d0.tmodns.net
Address 6: 208.54.38.51 m332636d0.tmodns.net
Address 7: 208.54.38.54 m362636d0.tmodns.net
Address 8: 208.54.38.50 m322636d0.tmodns.net
Address 9: 208.54.38.59 m3b2636d0.tmodns.net
Address 10: 208.54.38.55 m372636d0.tmodns.net
Address 11: 208.54.38.52 m342636d0.tmodns.net
Address 12: 208.54.38.56 m382636d0.tmodns.net
Address 13: 208.54.38.58 m3a2636d0.tmodns.net
[email protected]:/ $ nslookup google.com 66.244.95.20
Server: 66.244.95.20
Address 1: 66.244.95.20 brian-vm.suso.org
Name: google.com
Address 1: 2404:6800:400a:803::1008
Address 2: 208.54.38.49 m312636d0.tmodns.net
Address 3: 208.54.38.48 m302636d0.tmodns.net
Address 4: 208.54.38.53 m352636d0.tmodns.net
Address 5: 208.54.38.57 m392636d0.tmodns.net
Address 6: 208.54.38.51 m332636d0.tmodns.net
Address 7: 208.54.38.54 m362636d0.tmodns.net
Address 8: 208.54.38.50 m322636d0.tmodns.net
Address 9: 208.54.38.59 m3b2636d0.tmodns.net
Address 10: 208.54.38.55 m372636d0.tmodns.net
Address 11: 208.54.38.52 m342636d0.tmodns.net
Address 12: 208.54.38.56 m382636d0.tmodns.net
Address 13: 208.54.38.58 m3a2636d0.tmodns.net
Because I'm blocking the 208.54.0.0/16 IP range in the iptables I can't connect to Google unless I use a direct IP like 74.125.228.3 for example.
Earlier today it started working correctly but soon went back to the way described in my first post.
I did a nslookup using two different DDNS servers.
When I run a traceroute, with or without the firewall enabled, it hops through T-Mobile's network then dies before even reach the T-Mobile tmodns.net Google server.
I'm just curious this of ordinary behavior for T-Mobile. I would rather directly connect to Google owned IP addresses.
Code:
[email protected]:/ $ su
traceroute -v google.com
traceroute to google.com (208.54.38.52), 30 hops max, 38 byte packets
1 10.170.227.192 (10.170.227.192) 36 bytes to (null) 236.960 ms 286.452 ms 269.902 ms
2 10.170.227.137 (10.170.227.137) 76 bytes to (null) 279.829 ms 319.824 ms 329.807 ms
3 10.162.37.124 (10.162.37.124) 36 bytes to (null) 269.846 ms 249.833 ms 259.821 ms
4 10.162.37.113 (10.162.37.113) 76 bytes to (null) 259.902 ms 279.785 ms 259.878 ms
5 10.170.205.11 (10.170.205.11) 76 bytes to (null) 659.813 ms 269.880 ms 259.800 ms
6 10.177.17.125 (10.177.17.125) 76 bytes to (null) 629.853 ms 269.756 ms 369.844 ms
7 10.177.26.106 (10.177.26.106) 36 bytes to (null) 329.907 ms 539.814 ms 683.135 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
Bare with me I'm new.
Whilst researching the input event system in the kernel, I came across the need to access the input handlers that have already been registered with an IRQ lane given only the irq lane (just the integer). Is there a method to access ALL event handlers associated with an IRQ? I am looking to map each list of handlers from a given input device (say mouse) to each possible event that the device could make.