I've got a shiny new Samsung Captivate (Galaxy S) on AT&T.. working fairly well so far, besides the annoyances with the phone being locked down and the crappy bundled mail client (I've got loooots of email in my imap box, grin.) Phone is still stock; haven't had a chance to root it yet.
In any case, the issue I'm having is that the phone is setting an invalid netmask (255.0.0.0) on the wifi interface, instead of the proper one as served by dhcp (255.255.255.0).. this is preventing the phone from talking to other devices in 10/8.
Here's the DHCP response sent to the phone by my DHCP server:
Code:
Client-IP 10.20.0.120
Your-IP 10.20.0.120
Client-Ethernet-Address 00:26:37:xx:xx:xx
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 10.20.0.254
Lease-Time Option 51, length 4: 86400
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 10.20.0.254
Domain-Name-Server Option 6, length 8: 10.20.0.254,10.20.0.1
BR Option 28, length 4: 10.20.0.255
RN Option 58, length 4: 43200
RB Option 59, length 4: 75600
END Option 255, length 0
PAD Option 0, length 0, occurs 4
As you can see from the above, the phone was assigned 10.20.0.120 with a netmask of 255.255.255.0. I finally set up the android sdk, and fired up a shell with adb.. here's what it thinks its ip is:
Code:
$ ifconfig eth0
eth0: ip 10.20.0.120 mask 255.0.0.0 flags [up broadcast running multicast]
even odder, the properties on the phone has the correct netmask; output from 'getprop':
Code:
[dhcp.eth0.pid]: [3350]
[dhcp.eth0.reason]: [BOUND]
[dhcp.eth0.dns1]: [10.20.0.254]
[dhcp.eth0.dns2]: [10.20.0.1]
[dhcp.eth0.dns3]: []
[dhcp.eth0.dns4]: []
[dhcp.eth0.ipaddress]: [10.20.0.120]
[dhcp.eth0.gateway]: [10.20.0.254]
[dhcp.eth0.mask]: [255.255.255.0]
[dhcp.eth0.leasetime]: [86400]
[dhcp.eth0.server]: [10.20.0.254]
I suspect a firmware bug, but don't know for sure - anyone run into this before?
Appreciate any thoughts!
Same issue here. I posted about it here and on the ATT forums and sadly nobody has any suggestions other than reporting the bug to samsung. I did a bit of poking around in the console grepping 255.0.0.0 but didnt find any files. Im just gonna weather the storm and wait for the next firmware to be released. I have a shortcut to wifi settings and I just toggle the "static ip" option as needed.
FYI, there's also a post on ATT's forums about this.. I'm not allowed to link to it, but a Google search for "Samsung Captivate WiFi DHCP netmask issue" will get you to it..
Generally I dislike reviving old threads, but this appears unresolved and I've been encountering it on my Samsung Vibrant.
Can anyone confirm whether this happens with Froyo, or other Eclair-based handsets, or is it specific to Android 2.1 on Samsung GalaxyS?
When the Wifi DHCP assigns an IP in the 10.x.x.x block, (which is actually assigned with a /24 netmask) android puts the IP on the interface TWICE, with both /24 and an incorrect /8 subnet mask. ("ifconfig" is essentially a legacy command from linux kernel 2.2 era, when multiple IPs required aliased interfaces - with two IPs on one interface today "ifconfig" will only show the first one. Since kernel 2.4 days "ip" is the preferred tool)
$ busybox ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 5e:38:e9:7b:aa:6d brd ff:ff:ff:ff:ff:ff
3: tunl0: <NOARP> mtu 1480 qdisc noop state DOWN
link/ipip 0.0.0.0 brd 0.0.0.0
4: gre0: <NOARP> mtu 1476 qdisc noop state DOWN
link/gre 0.0.0.0 brd 0.0.0.0
30: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 5c:da:d4:09:fb:f3 brd ff:ff:ff:ff:ff:ff
inet 10.200.10.28/8 brd 10.255.255.255 scope global eth0
inet 10.200.10.28/24 brd 10.200.10.255 scope global eth0
inet6 2001:470:e130:98:5eda:d4ff:fe09:fbf3/64 scope global dynamic
valid_lft 2591705sec preferred_lft 604505sec
inet6 fe80::5eda:d4ff:fe09:fbf3/64 scope link
valid_lft forever preferred_lft forever
$
This causes me significant problems, as 10.200.10.0/24 is the wifi subnet, but 50 other 10.x.x.x subnets exist on the local network, and because it erroneously applies a /8 mask on the local interface I'm unable to reach anything on the 10.x.x.x networks outside of 10.200.10.x. (I have to manually go in and remove the first IP with the /8 subnet)
(Aside, as you might notice it correctly autoconfigured an ipv6 address, with 2001:470:e130::1/64 gateway running radvd - now if only apps like web browser understood ipv6...)
j
Hey guys,
I have successfully installed OpenVPN on my SGS I9000. Establishing a connection to the OpenVPN Server is no problem, but after this the traffic isn't routed through the VPN-connection and I don't know why
OpenVPN config:
Code:
client
dev tun
proto udp
remote 193.197.62.35 1195
remote 193.197.62.35 1196
remote 193.197.62.35 1197
remote 193.197.62.35 1198
remote-random
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca dhbw-openvpnca.txt
comp-lzo
verb 3
auth-user-pass
Can someone help me please?
Does nobody have an idea?
Hi
I'm using openvpn in tap mode, I had problems trying to set it up as tun. This is how the server is configured:
Code:
port 1194
proto udp
dev tap
dev-node tap-bridge
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
tls-auth ta.key 0 # This file is secret
dev-node tap-bridge
server-bridge 10.0.0.1 255.255.255.0 10.0.0.192 10.0.0.255
push "redirect-gateway def1"
keepalive 15 90
comp-lzo
persist-key
persist-tun
Modify server-bridge according to your local network configuration.
I excluded all certificate configuration
In addition to this I change the DNS after the VPN starts, otherwise I can't browse the internet. If you just need to connect to your local network the this is not required.
Client config is as follows:
Code:
client
dev tap
<connection>
remote VPN_IP 1194 udp
</connection>
nobind
user nobody
group nobody
persist-key
persist-tun
ca /sdcard/ca.crt
cert /sdcard/android.crt
key /sdcard/android.key
ns-cert-type server
tls-auth /system/etc/openvpn/ta.key 1
comp-lzo
Trouble routing traffic through OpenVPN
I have the same problem and need help resolving it. I use Samsung Infuse 4G, rooted, with the "Infused ROM" installed. I also installed OpenVPN by using "OpenVPN Installer" and use "OpenVPN Settings" for my connection settings. Everything seems to be nice and smooth. One thing I found is that on the Infused ROM, tun.ko that sits in /system/lib/modules does not work, but there is another one in /lib/modules/ which does work. Also, OpenVPN Settings inserts tun.ko module by using insmod, not modeprobe. If I tried to use modeprobe option, it is not working.
Anyway...
My OpenVPN connects without problems to my Tomato router at home. The problem is, that it does not route any traffic though the VPN tunnel. Any browsing that I do, I do outside of VPN, which is not what I expected.
I would appreciate any help with this.
Great discussion from the following thread:
http://forum.xda-developers.com/showthread.php?t=1191792
Thanks to know Static IP can temporary solve the connection problem.
BUT I found somethings:
1. A lot of 3.1 users upgraded to 3.2, BUT NOT ALL Users report such WiFi (grey icon / disconnect irregularly) problem.
2. A lot of people use DHCP, lot of lot users have no such problem. Some of us posted here are annoying with such WiFi problem, however, static IP can help.
3. Therefore the problem relates DHCP and Static IP.
My guess:
1. Maybe most of us (with WiFi problem) used DHCP BUT with IP reservation (I use reservation).
2. Most users (without WiFi problem (my friend's TF doesn't have grey problem)) use only the DHCP without IP reservation.
My testing and result:
1. Firstly, I disable the IP reservation (192.168.1.11) for the TF
2. Then set the DHCP range to 192.168.1.2 to 192.168.1.8 (1-7 for other devices)
3. Then I set the TF to DHCP
4. Finally, TF gets the 192.168.1.8
5. Then I use File Manager HD to get a 619MB file from my desktop to TF (Two times testing)
6. Wow, it's SMOOTH!!! Before DHCP with IP reservation...only can download around 100MB then disconnected. Now, no more disconnection
My conclusion (or you may try too):
With 3.2, don't set your router to have IP reservation with your TF, just set DHCP, MAC mapping (it's fine, no problem, WPA2-PSK (it's fine too).
Bros and Sis, if your TF faces WiFi problem after upgrading to 3.2, you may try my solution.
If your TF and router work well again with DHCP without IP reservation, my prediction is correct.
If my prediction is correct, please spread this message, to let TF fans, Xoom, Asus, Google to know it!
Please help to try and use back your DHCP.
Good Luck!
Just removed my IP reservation. Wifi icon now blue. Will let you know if this helps my disconnects
EEE Pad Transformer sent this
I have rooted 3.2 and no Wi-Fi problems. However, when I look at the syslog files from my router I see:
Code:
Aug 7 10:36:19 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:36:19 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
Aug 7 10:38:43 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:38:43 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
Aug 7 10:41:08 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:41:08 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
The Transformer is doing a DHCP request every 3 minutes or so. This is exceptionally frequent, and could cause the connection to drop if a) there are existing network problems that prevent the request from going through successfully or b) the DHCP server gets pissed off and stops responding.
PS: I obscured the MAC address in the log sample on purpose.
rtadams89 said:
I have rooted 3.2 and no Wi-Fi problems. However, when I look at the syslog files from my router I see:
Code:
Aug 7 10:36:19 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:36:19 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
Aug 7 10:38:43 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:38:43 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
Aug 7 10:41:08 tomato dnsmasq-dhcp[100]: DHCPREQUEST(br0) 192.168.10.128 14:da:XX:XX:XX:XX
Aug 7 10:41:08 tomato dnsmasq-dhcp[100]: DHCPACK(br0) 192.168.10.128 14:da:XX:XX:XX:XX Transformer-R
The Transformer is doing a DHCP request every 3 minutes or so. This is exceptionally frequent, and could cause the connection to drop if a) there are existing network problems that prevent the request from going through successfully or b) the DHCP server gets pissed off and stops responding.
PS: I obscured the MAC address in the log sample on purpose.
Click to expand...
Click to collapse
The transformer isn't doing any DHCP requests based on it's own logic. It is all based on the length of the lease at the router handing out the DHCP requests (which runs dhcpd). If you have control of the router, you can set the lease length. All the transformer does is find out that it's lease has expired and fetch the same one again (usually, based on arp tables, etc).
My router has the DHCP lease time fro non-static (static DHCP configured from the router, not static IP configured on the client) addresses set to 24 hours. For static DHCP address the lease time is infinite. In both cases, the Transformer does a DHCP request every 3 minutes or so.
rtadams89 said:
My router has the DHCP lease time fro non-static (static DHCP configured from the router, not static IP configured on the client) addresses set to 24 hours. For static DHCP address the lease time is infinite. In both cases, the Transformer does a DHCP request every 3 minutes or so.
Click to expand...
Click to collapse
In that case, it's just weird. Based on reading that, I looked at the router log at home and mine isn't doing that but of course I could see the original DHCP request. I'm running 3.2 US rooted (whatever latest build is of that), no custom ROM, and as far as DHCP, it is behaving.
Yeah, I could see how an endless series of requests could cause trouble for our cheap home routers. Is there any chance that something else on your network is spitting out dhcpd services? If I were going to try to troubleshoot it, I'd setup another wifi router(some older cheap one would do) on it's own network, disconnect from your primary router, and point it at the new / old one, and see what it did over there. With only the two players, it might be easier to tell. For that matter if you've got a phone with wifi tether, I guess that would be a good test.
Does the logcat on the TF also note these DHCP requests?
hachamacha said:
Is there any chance that something else on your network is spitting out dhcpd services?
Click to expand...
Click to collapse
No other DHCP servers on the network.
hachamacha said:
If I were going to try to troubleshoot it, I'd setup another wifi router(some older cheap one would do) on it's own network, disconnect from your primary router, and point it at the new / old one, and see what it did over there. With only the two players, it might be easier to tell. For that matter if you've got a phone with wifi tether, I guess that would be a good test.
Click to expand...
Click to collapse
I tether to my phoen via bluetooth, so I can't really check that and I don't have any other routers that would show me enough log detail to see that info. What I did do is disable the router's DHCP/DNS services and instead used one of my Linux VMs to handle those services on the network. Same problem.
hachamacha said:
Does the logcat on the TF also note these DHCP requests?
Click to expand...
Click to collapse
Yes.
What I have done though is remove the static DHCP lease for the transformer, and it let it be assigned completely randomly. I'm reviewing the logs now, but it seems to not be requesting a lease as often. I'm not sure if that is an issue with how the router is handing out "infinite" leases (I'm not sure if it just sets a lease expiration as some large value, or if it sets it as zero, or if it doesn't even send that parameter at all).
If I do this command:
#getprop | grep lease
I get back something like this:
response: *wlan0*lease* : 84600
----
I was wondering what your's shows? I got interested in this when I noticed init.ventana.rc kicking off dhcpcd (client daemon) that uses for config /system/etc/dhcpcd/dhcpcd.conf so poked around some more.
Looking at this man page:
http://roy.marples.name/cgi-bin/man-cgi?dhcpcd.conf
(sorry, but no clue if all those work on android)
It does make me wonder if the leasetime parameter works? It says this:
leasetime seconds
Request a leasetime of seconds.
The problem is usually that the busybox/hacked down versions of these utilities like dhcpcd involves drastically reduced functionality.
Apparently on mine, it is working as intended since 84600 seconds is the lease length ala my router and is what it shows as the 'given lease time' on my TF, so I wonder if at that level it is showing up the same.
I use a linux box to do my DHCPD duties. So far I've tried both mac address based allocation of address and just allowing my TF to get one from the pool - there didn't appear to be any difference between the two.
With the default lease time set to 600 seconds and the max set to 7200 I was getting a request for dhcp renewal every couple of mins :
Code:
08-06 09:53:37.660 D/DhcpStateMachine( 130): DHCP request on wlan0
08-06 09:53:38.060 D/DhcpStateMachine( 130): DHCP succeeded on wlan0
08-06 09:53:38.070 D/WifiStateMachine( 130): netId=0 Link configured: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy:
08-06 09:53:38.090 D/ConnectivityService( 130): addDefaultRoute for WIFI (wlan0), GatewayAddr=192.168.1.254
08-06 09:56:02.450 D/DhcpStateMachine( 130): DHCP renewal on wlan0
08-06 09:56:02.850 D/DhcpStateMachine( 130): DHCP succeeded on wlan0
08-06 09:56:02.850 D/WifiStateMachine( 130): Link configuration changed for netId: 0 old: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy: new: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy:
08-06 09:56:02.880 D/ConnectivityService( 130): addDefaultRoute for WIFI (wlan0), GatewayAddr=192.168.1.254
08-06 09:58:27.130 D/DhcpStateMachine( 130): DHCP renewal on wlan0
08-06 09:58:27.330 D/DhcpStateMachine( 130): DHCP succeeded on wlan0
08-06 09:58:27.340 D/WifiStateMachine( 130): Link configuration changed for netId: 0 old: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy: new: InterfaceName: wlan0 LinkAddresses: [192.168.1.17/24] Gateways: [192.168.1.254,] DnsAddresses: [192.168.1.101,192.168.1.254,] HttpProxy:
08-06 09:58:27.370 D/ConnectivityService( 130): addDefaultRoute for WIFI (wlan0), GatewayAddr=192.168.1.254
I then changed the default lease time and the max lease time to 84600 (24 hours) and am getting practically none of these ... only when I turn on my TF since I have the wifi set to disable on screen off. - And obviously I don't see my wifi indicator go grey or loose network connectivity.
My first question is why when the lease time is set to 600 seconds is it making the request after 2 mins ?
It looks to me like it is dropping at least part of its layer 3 config when it goes through this process.
I have used IP reservations since the very first connection to my router, which included MAC filtering. I have never had my connection drop, at least none that I'm aware of.
Mind you, I buy a new router every year, to improve performance, for better implementations of standards, better compatibility, etc.
Those having issues may want to test another router.
Sent from my Transformer TF101 using XDA Premium App
As long as I set my lease time to 24 hours I have no problems ... trouble is I don't get a say in that on public wifi hotspots ... this should just work ... it's not exactly a complicated protocol.
A renew should just update the expiry time on the lease on the DHCP server it shouldn't trigger a complete layer 3 reconfigure which is what appears to be happening.
You should be able to find 'tcpdump' for arm. (might be called tcpdump-arm), which is a pretty nice packet sniffer for linux (or whatever it's built for). With that and a tcpdump examples page, (or the man page), you could look over the packets that are going back and forth, but this isn't simple stuff if you're not well versed in what they ought to look like, and even if you are, it's not that easy.
Wireshark, used to be called ethereal, would be much easier, but the only thing I can find out there in the market so far is "shark for root", and "shark reader". These are better than nothing, probably require tcpdump, and might help, but are also just trying to stick tcpdump output into a GUI, which isn't that good.
Maybe if you can find the right tools this becomes a lot easier to at least nail down to a 'bug' or even a 'fix', but without knowing the actual problem in terms of data being passed, these things are tough.
I'm just guessing that somewhere on XDA, there is a sniffer that is better than what I've mentioned and like the others is free. I've not searched around yet.
A different tactic that would also be useful would be to setup a 'hub' or a couple of 'mirrored ports' but then the question becomes " who the hell has this stuff anymore? " It requires , perhaps, Cisco level gear , IOS mirroring commands, or a hub (which are out of 'style'). But with that, you could slap in a laptop running wireshark and do this. Oh crap. I totally forgot that this is wifi, not wired, so the last option isn't good unless you've got a dd-wrt router that will somehow allow all this. DD-WRT is really cool, so it might let you run a good sniffer itself right from the router.
thephm said:
As long as I set my lease time to 24 hours I have no problems ... trouble is I don't get a say in that on public wifi hotspots ... this should just work ... it's not exactly a complicated protocol.
A renew should just update the expiry time on the lease on the DHCP server it shouldn't trigger a complete layer 3 reconfigure which is what appears to be happening.
Click to expand...
Click to collapse
I'm in your camp - my lease time is 1 week.
And the answer to this problem most assuredly is NOT 'replace your router' (which coincidentally is also what Asus tech support told me). Next will be 'go ahead and drive to a different public WiFi'.
hachamacha said:
You should be able to find 'tcpdump' for arm. (might be called tcpdump-arm), which is a pretty nice packet sniffer for linux (or whatever it's built for). With that and a tcpdump examples page, (or the man page), you could look over the packets that are going back and forth, but this isn't simple stuff if you're not well versed in what they ought to look like, and even if you are, it's not that easy.
Wireshark, used to be called ethereal, would be much easier, but the only thing I can find out there in the market so far is "shark for root", and "shark reader". These are better than nothing, probably require tcpdump, and might help, but are also just trying to stick tcpdump output into a GUI, which isn't that good.
Maybe if you can find the right tools this becomes a lot easier to at least nail down to a 'bug' or even a 'fix', but without knowing the actual problem in terms of data being passed, these things are tough.
I'm just guessing that somewhere on XDA, there is a sniffer that is better than what I've mentioned and like the others is free. I've not searched around yet.
A different tactic that would also be useful would be to setup a 'hub' or a couple of 'mirrored ports' but then the question becomes " who the hell has this stuff anymore? " It requires , perhaps, Cisco level gear , IOS mirroring commands, or a hub (which are out of 'style'). But with that, you could slap in a laptop running wireshark and do this. Oh crap. I totally forgot that this is wifi, not wired, so the last option isn't good unless you've got a dd-wrt router that will somehow allow all this. DD-WRT is really cool, so it might let you run a good sniffer itself right from the router.
Click to expand...
Click to collapse
I do this stuff for a living and am a fully card carrying geek .... my home router is a Cisco 1800, I run a linux server as a DHCP/Mail/Web/anything else I can think of box. tcpdump is pretty straightforward for someone with a modicum of networking knowledge and running with the -w option will save the captured packets in a binary format suitable for opening in Wireshark which makes things even easier. I've already done all this on from the dhcp servers perspective ... the problem doesn't appear to be in the dhcp request/response packets but what the TF actually does with the packets higher up int the TCP stack. In my opinion the way to identify the problem is not more packet tracing but to look at the dhclient code and/or the kernel code in android 3.2 preferably with the diff's against android 3.1.
Android defect : http://code.google.com/p/android/issues/detail?id=18648
which has been assigned an owner
thephm said:
In my opinion the way to identify the problem is not more packet tracing but to look at the dhclient code and/or the kernel code in android 3.2 preferably with the diff's against android 3.1.
Android defect : http://code.google.com/p/android/issues/detail?id=18648
which has been assigned an owner
Click to expand...
Click to collapse
I actually think it got broken in the 3.1 update, FWIW. I ran just fine with my current setup on 3.0.
I believe mine worked correctly on 3.1 - I have only had mine about 2 weeks so I went straight to 3.1 and then very soon after that to 3.2 but when I upgraded to 3.2 I was on a foreign network so it wasn't a direct comparison.
thephm said:
I do this stuff for a living and am a fully card carrying geek .... my home router is a Cisco 1800, I run a linux server as a DHCP/Mail/Web/anything else I can think of box. tcpdump is pretty straightforward for someone with a modicum of networking knowledge and running with the -w option will save the captured packets in a binary format suitable for opening in Wireshark which makes things even easier. I've already done all this on from the dhcp servers perspective ... the problem doesn't appear to be in the dhcp request/response packets but what the TF actually does with the packets higher up int the TCP stack. In my opinion the way to identify the problem is not more packet tracing but to look at the dhclient code and/or the kernel code in android 3.2 preferably with the diff's against android 3.1.
Android defect : http://code.google.com/p/android/issues/detail?id=18648
which has been assigned an owner
Click to expand...
Click to collapse
Wow, a real Cisco router. I'm impressed. If you can afford electricity to run that thing, all is well. I realized after I'd replied that the tcpdump I'd put on my tf was the full featured one, not some android knockoff. It is a good tool.
I read up on the bug report and it seems you're right. I always hope that trouble leaves a telltale. I guess I've escaped it for some reason because I'm on 3.2 and haven't the issue. Probably the problem takes a number of ingredients to occur.
I'm glad the bug is longer an orphan.
Sent from my Transformer TF101 using XDA App
chupig said:
Bros and Sis, if your TF faces WiFi problem after upgrading to 3.2, you may try my solution.
Click to expand...
Click to collapse
Just unistall it to good old 3.1
My device also had the same issue with being unable to connect to the wifi, as a different method than the ones suggested earlier,
Just change the password protection method of your router,
Changing mine from WPA / WPA2 to WPA2 solved the problem for me, weirdly enough...
AlienCraB said:
My device also had the same issue with being unable to connect to the wifi, as a different method than the ones suggested earlier,
Just change the password protection method of your router,
Changing mine from WPA / WPA2 to WPA2 solved the problem for me, weirdly enough...
Click to expand...
Click to collapse
Very strange coz that is a lower layer of the connection ... I've never lost the "physical" connection to the wifi just the layer 3 connectivity (the ip address/default route) when using DHCP.
The purpose of this post is to explain how to tether with openvpn, which will hopefully avoid ATT's all seeing eyes, as well as prevent any detection during tethering.
All ATT will ever see is encrypted traffic between a connection that is initiated from my phone and ends at my vpn server. So the only way they would be able to determine if you are tethering, is if they are spying on you ala CIQ directly on your device, or your device phones home and tattles on you. That would open up a different can of worms and a **** storm would ensue.
This method requires a number of things.
* Openvpn server (preferably running on a static address, but will work with dynamic DNS services) with a reliable connection. I use a VPS server for $25 a month, but it is fast and reliable.
* Openvpn on your phone (any will work as long as it has the tun driver or tun built into the kernel(
* Some sort of gateway (your openvpn server can be running on it as well, or a seperate host), I use Freebsd/Openbsd. For linux, your on your own to figure out NAT and gateway functions.
Really, that is about it.
My Openvpn server config, you can set it up any way you like, but certain statements are required, specifically those in the hashed out box if you want your subnets to talk to each other, and route the traffic
Code:
port ****
proto tcp
dev tun
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/vps.server.crt
key /usr/local/etc/openvpn/keys/vps.server.key
dh /usr/local/etc/openvpn/keys/dh2048.pem
server 192.168.150.0 255.255.255.0
ifconfig-pool-persist ipp.txt
mode server
client-to-client
client-config-dir ccd
###############################################
# my phone and home subnets, can be any RFC1918 address space
# Advertise and note your home subnets in this section, unless you
# do not want the various subnets to talk to each other, then you
# can also remove the client-to-client statements
###############################################
push "route 192.168.15.0 255.255.255.0"
push "route 192.168.43.0 255.255.255.0"
route 192.168.15.0 255.255.255.0
route 192.168.43.0 255.255.255.0
###############################################
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
log-append /var/log/openvpn/openvpn.log
verb 4
My client config on my phone (change the remote statement to match your openvpn server host and port)
Code:
client
proto tcp
dev tun
remote vpn.example.com 1234
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
comp-lzo
/usr/local/etc/openvpn/ccd is where I have my client specific configs (match the location to that identified in the server.conf file for your vpn server). I also use certificates unique to each host that connects to my vpn, the names of the files in the "ccd" directory must match the name you gave the device when you created your certificates. I use easy-ssl to manage my certs.
for my phone, which I named "galaxy_s" I have the following (note the DNS option is optional, I was having problems with it so I just hardcoded 8.8.8.8, googles dns server into my network settings on my laptop)
/usr/local/etc/openvpn/ccd/galaxy_s
The iroute statement just tells the openvpn server what subnets you have behind your device, in this case the phone. I am guessing all of the android phones use 192.168.43.x as the NAT'd subnet, otherwise change it to whatever your phone is assigning.
Code:
push "redirect-gateway"
push "dhcp-option DNS 192.168.15.1"
iroute 192.168.43.0 255.255.255.0
The rest of the configurations are related to your primary gateway, which in my case also runs the openvpn server. I am using freebsd and pf, the configs needed for that are essentially natting statements, and firewall rules.
for pf, the following rules are what I use
I also trust all the traffic on my tun0 device, so I told pf to ignore it and pass all traffic
Code:
nat on $int from 192.168.150.0/24 to any -> $int/32
nat on $int from 192.168.43.0/24 to any -> $int/32
set skip on tun0
Hopefully this is useful to other folks, if not, let it be buried
THanks for an EXCELLENT guide!
Quick question. When I use this server conf file, my ssh on my local network hangs up and goes down.
In other words:
I am running openvpn on a home linux server. It is connected through a home router to the internet and has a network set up at 192.168.1.0.
Router is 192.168.1.1,
vpn server is on 192.168.1.51.
If I start openvpn, I cannot ssh from a local network (192.168.1.81) laptop. If I turn off openvpn I can. I changed your 192.168.15.0 addresses in server conf file to 192.168.1.0. I have a feeling it has to do with that.
Well, yes, you will need to modify the configs to suit your own address scheme. As for why you cannot ssh, I am not sure, is that .81 device on the same network as the openvpn server, or are you coming from a different network.
My setup has the gateway the same as the openvpn server simply due to the fact that I am using a Virtual Private Server (VPS) and I only have that as the 1 external static system.
I would check the route statements, I'm not sure, but you might have a routing loop that would be causing the problem, can you traceroute or ping, or use any other protocol/application to see if you can connect). If you set the default gateway of the openvpn server as the .1 address, and then you are trying to connect to another internal address, the .81, when you ssh from whatever device is connected to the openvpn server, it may attempt to connect to the gateway at .1 and then return back into your network to .81.
I could be wrong, it is hard to tell when you are not sitting at the actual systems.
Got it to work! Here's some tips for others
Thanks again for your help jvanbrecht. Last night I was able to sit down, get a better understanding of how it worked via openvpn's HOWTO, and get it running.
I did need to make a few mods for it to work in my configuration (as is expected since very few network configs are the same).
My configuration:
Single home network, say on 192.168.15.0.
Single router, at 192.168.15.1.
Home server hosting VPN on 192.168.15.51. It is running Ubuntu Maverick.
Skyrocket on subnet 192.168.43.0
My modifications:
Since I don't need direct access between VPN clients and my home subnetwork, in the server config I commented out:
Code:
#push "route 192.168.1.0 255.255.255.0"
#route 192.168.1.0 255.255.255.0
It was giving me some problems SSHing into my home server from a local network machine so this was the quick fix.
Initially it wasn't routing ALL traffic, just that directed from VPN client to the VPN server. So I added this to the server conf:
Code:
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.150.1"
In my home (tomato) router, I just port forwarded any TCP traffic on 1194 to the home server (192.168.15.51)
I think openvpn does this already. But just in case, I added an iptable nat entry to forward packet from VPN network to eth0 (my NIC). As root:
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward
And I added the following entry to /etc/rc.local so it persists on restart.
Code:
iptables -t nat -A POSTROUTING -s 192.168.150.0/24 -o eth0 -j MASQUERADE
Some debugging tips for others
Simplest way to verify HTTP traffic is being forwarded is, after connecting to vpn from phone, go to www.whatismyip.com. Make sure it matches your phone.
If you are having trouble connecting to the VPN, watch the openvpn log for errors. "tail -f /var/log/openvpn/openvpn.conf"
After connecting, make sure you can ping from your home server to the phone.
From Server: "ping 192.168.150.10"
From Phone: Open Terminal Emulator and type "ping 192.168.150.1"
You can also validate the traffic is forwarding through VPN by using traceroute. You can test both forwarding and DNS
From Phone: Open Terminal Emulator, type
Code:
su
For no-DNS test first:
Code:
traceroute 74.125.115.104
For DNS test:
Code:
traceroute www.google.com
For each, do your tests on the cell network (NOT home wifi) and verify that the route passes through your vpn server and doesn't bypass it completely.
Lastly to make sure traffic is being piped, you can monitor VPN traffic from your openvpn server by typing:
Code:
tcpdump -i tun0
jvanbrecht:
Do you have any recommendations about dropped connections? I noticed while testing that sometimes my openvpn connection would drop and my phone browsing would immediately default to the direct default cell provider connection.
Of course if tethering, this could be very bad.
Any tips on ensuring that if VPN is enabled, but no connection, that it won't ever try and route around it?
would using any vpn do the same thing? or something making this special ? any one tested this ?
It's been a few weeks since I tried the openvpn app. Back then everything seemed to be working well. But I tried again today and am having problems.
- I can access everything fine via vpn if my phone is connected to my local wifi where the vpn server resides.
- I can access IP addresses (e.g. the ip address of google.com) if connected to vpn via AT&T's 3G network
- I CANNOT access websites by their name (e.g. www.google.com) anymore.
It seems the DNS forwarding over VNC is messed up. Any tips on what the problem could be?
I still have the same settings as above, e.g. push "dhcp-option DNS 192.168.150.1"
Is it possible I need to do any additional configuration on my phone?
Is it possible to replace my router DNS address with a public one like google's "8.8.8.8" or "4.2.2.2"?
Any tips greatly appreciated!
Deleted. Please ignore. Still having issues.
So I had the opportunity to play around with my config (listed above) a bit more this evening. I was at a location where I had good external WiFi (Panera) along with 3G.
If I connect from my phone to my home VPN server over EXTERNAL WIFI (Panera), I have no problems with VPN. everything works flawlessly.
If I connect from my phone to my home VPN server over AT&T 3G network, it fails. Essentially it can't resolve any DNS queries. I can type in a website's IP address and surf that way, but I can't say type in "www.cnn.com" and get a page to load.
For the latter, when I watch the web queries using "tcpdump -i tun0", I see the requests go out from my phone to the websites, but they don't come back. For example, I see:
"192.168.150.10 > a.b.c.d (www.cnn.com)",
but I don't see:
"a.b.c.d (www.cnn.com) > 192.168.150.10"
Is it possible that AT&T is somehow blocking VPN via DNS? At first I thought my openvpn dns settings were messed up ... but it works across external wifi no problem.
---------- Post added at 01:24 AM ---------- Previous post was at 01:07 AM ----------
For those that are interested in the future, I think I narrowed down the issue:
It seems VPN connectivity is dependent on the AT&T Access Point Network (APN)
By default for my Skyrocket I was on the AT&T PTA APN wit settings:
Code:
APN: pta
MMSC: http://mmsc.mobile.att.net
MMS proxy: proxy.mobile.att.net
MMS Port: 80
...
I then switched to what is called the "AT&T Expanded" APN with settings:
Code:
APN: wap.cingular
User Name: [email protected]
(rest of settings somewhere here on xda ...)
... and that one worked perfectly.
I switched back and forth a few tiimes to confirm. It seems on pta, I can't resolve DNS over VPN. For the wap.cingular, I have no problems.
Anyone else can confirm this is most likely the issue I am seeing and that it can possibly make sense?