Database Users

Wifi conn with router stoppped while JJ was updating weather

That is interesting, because it was not the first time.
While working on the internet with my Toshiba all of a sudden I get the remark that no connection could be made with my Linksys B router.
Did a repair and everything was fine.
My Jasjar was just laying on the table, not being used.
Opened my JJ and found out that my pocketweather update was three minutes old. So the JJ had triggered the router.
Too much of a coincidence?
I work on different locations, and also my linksys G router and an old Sitecom at the office had given me minor problems.
I will now try not to use my JJ Wifi for a while and see if the problem comes back.
It is good to know that I never ever had problems with any of tjhose routers for a long period.
Could the Jasjar give problems?
Huib

Have had a similar thing caused by both devices grabbing the same IP. For example,
- PDA in use and allocated an address by the router's DHCP server. PDA then turned itself off due to inactivity.
- A while later, turned on Laptop. Router allocated the same IP address to laptop, since as far as it was concerned, that IP was now free.
- PDA caused to turn on by a scheduled task, such as timed PocketWeather update. Since the PDA still has the original IP allocated, it will immediately try to regain that IP. Depending upon the router/DHCP server, this may be permitted, in which case the laptop will lose it's IP.

Also strange things with WAN IP
astage said:
Have had a similar thing caused by both devices grabbing the same IP. For example,
- PDA in use and allocated an address by the router's DHCP server. PDA then turned itself off due to inactivity.
- A while later, turned on Laptop. Router allocated the same IP address to laptop, since as far as it was concerned, that IP was now free.
- PDA caused to turn on by a scheduled task, such as timed PocketWeather update. Since the PDA still has the original IP allocated, it will immediately try to regain that IP. Depending upon the router/DHCP server, this may be permitted, in which case the laptop will lose it's IP.
Click to expand...
Click to collapse
Yes, absolutely. Could be the case. I did check the DHCP table this morning. But both PC and JJ had a new but different number.
Now however I could force another error, which again I never had before and happened on two different Linksys routers.
Looking at the Linksys status I see
Firmware Version: 1.45.10, Apr 15 2004
Login: Disable
LAN:
(MAC Address: 00-06-25-98-47-00)
IP Address: 192.168.1.1
Subnet Mask: 255.255.255.0
DHCP server: Enabled
WAN:
(MAC Address: 00-06-25-98-47-01)
IP Address: 0.0.0.0
Subnet Mask: 0.0.0.0
Default Gateway: 0.0.0.0
DNS: 0.0.0.0
My Static IP address has disappeared!. Also when doing the setup again (without giving it a confirming "save") I see "optain IP automatically, where it should be "fixed WAN IP".
Switching off and on the router, without doing any setup solves the problem. So no big deal.
I am afraid that my little Jasjar buddy is doing sneeky things with my router.
Huib

I see a somewhat similar problem here :
http://forum.xda-developers.com/viewtopic.php?t=33328&highlight=wifi+router
Close proximity interference? Maybe working wit a Mac address table could solve it?
I do use WEP however.
I am not such a heavy WIFI user with my JJ so I let it rest for a while.
Huib

Flaky WiFi. Any solutions?

I can't seem to keep either of our Heros connected to WiFi reliably. It works fine when first turned on, then after 10 or 15 minutes I can't connect to anything. The Hero still shows itself as connected, excellent signal strength, and a valid IP config for my network. All other devices on my network continue to work just fine. Rebooting the phone usually, but not always, gets me another 10 minutes of WiFi connectivity.
I'm running DamageControl with the 2.41.04.02.02 radio. My wife's Hero is, aside from installing Handcent, exactly as it came out of the box. Both display the same symptoms. The problem is also the same regardless of which of my 3 access points I use.
I've spent 2 solid days googling this problem and come up empty handed. Does anybody know of a good solution to this?

Have you tried setting up Static IPs for your phones? To do this, hold down on the WiFi connection and select Advanced Settings.

Yep. I've been building and maintaining corporate networks for over 20 years. The very first thing I did was make sure the phone had valid IP configuration.
I also have the WiFi set to never sleep, per a suggestion I stumbled across on another board. Seems to make no difference.
This is extremely frustrating since both my wife and I rely heavily on data connectivity for our jobs. Living in an area where we're roaming and have 1x data *at best*, WiFi is completely non-optional for us.
Can you recommend a good ssh server for the phone? I'd like to log in and see what it's doing. From the symptoms I've observed it seems like either the DNS config or the routing tables are flaking out.

subliminalurge said:
…Can you recommend a good ssh server for the phone? I'd like to log in and see what it's doing. From the symptoms I've observed it seems like either the DNS config or the routing tables are flaking out.
Click to expand...
Click to collapse
I don't mean to dis your experience. It's always been my practice to answer in forums assuming novice status unless otherwise apparent.
I normally set DNS1 to the router address and let the router handle the job. Can't you SSH locally to test the local WiFi network?
Edit: Sorry... I see you meant an SSH Server for the phone. It should be built into the ROM isn't it?

There is a setting that some how gets set to turn wifi off when it goes to sleep.
Go to Menu > Settings > Wireless and Networks > WiFi Settings > Menu > Advanced > WiFi Sleep Policy > Change from After 15 minutes to Never or Never when plugged in.
Edit:
Disregard just saw your other post saying you have done this.

No worries. I also find it's usually better to oversimplify than to be overly technical when you're unsure of the audience.
What do you mean by "ssh locally"? The local WiFi network is working just fine. I have 3 laptops, 2 iPhones, an iPod touch, and a PS3 connected to it right now, all accessing the Internet just fine. I also have 2 Heros that have no access through the same network.
What I want to do is log in to a command prompt on the phone itself (which is essentially just a small Linux computer) and troubleshoot the network configuration from there. I've pretty much exhausted what can be done through the gui utilities on the phone.

I'm not sure if the 2.1 builds have dropbear installed. If so, it shouldn't be too difficult to enable the built-in ssh server. MoDaCo ROMs not only had it built-in, but enabled out of the box.

Cool. I'll look into getting that up and going.
Logged in through adb, here's where it's at.
Code:
# busybox ifconfig
busybox ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1097 errors:0 dropped:0 overruns:0 frame:0
TX packets:1097 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:101782 (99.3 KiB) TX bytes:101782 (99.3 KiB)
tiwlan0 Link encap:Ethernet HWaddr 00:23:76:BF:F2:A0
inet addr:192.168.5.229 Bcast:192.168.5.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1090 (1.0 KiB) TX bytes:2000 (1.9 KiB)
This is valid for my lan.
Code:
# busybox route
busybox route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.5.0 * 255.255.255.0 U 0 0 0 tiwlan0
default 192.168.5.1 0.0.0.0 UG 0 0 0 tiwlan0
#
This is also valid.
Let's take DNS out of the equation and ping an IP address. (OpenDNS server. It is up and responding to pings from my laptop at the same time I execute this command.)
Code:
# ping -c 3 208.67.222.222
ping -c 3 208.67.222.222
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
From 192.168.5.229 icmp_seq=2 Destination Host Unreachable
From 192.168.5.229 icmp_seq=3 Destination Host Unreachable
--- 208.67.222.222 ping statistics ---
3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2002ms
#
Not good. The packet isn't even leaving the phone.
Let's just try the router itself.
Code:
# ping -c 3 192.168.5.1
ping -c 3 192.168.5.1
PING 192.168.5.1 (192.168.5.1) 56(84) bytes of data.
From 192.168.5.229 icmp_seq=1 Destination Host Unreachable
From 192.168.5.229 icmp_seq=3 Destination Host Unreachable
--- 192.168.5.1 ping statistics ---
3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2000ms
#
And finally....
Code:
# ping -c 3 192.168.5.229
ping -c 3 192.168.5.229
PING 192.168.5.229 (192.168.5.229) 56(84) bytes of data.
64 bytes from 192.168.5.229: icmp_seq=1 ttl=64 time=0.427 ms
64 bytes from 192.168.5.229: icmp_seq=2 ttl=64 time=0.428 ms
64 bytes from 192.168.5.229: icmp_seq=3 ttl=64 time=0.427 ms
--- 192.168.5.229 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.427/0.427/0.428/0.016 ms
#
Well, at least the phone can ping itself...
I'll dig in deeper later, but I can now say for certain that this is NOT an IP configuration issue. The phone and access point aren't communicating on the hardware level (although according to the settings screen, the phone thinks it is).
Off the top of my head my best guess right now is that it's going to take some kernel level tweaking to get this resolved.

How does stack decide routing when EVDO & WiFi are available?

The subject pretty much says it all... if I have EV-DO available, and also have 802.11g available, how does the phone's network stack decide which route is better? Does it try to always use Wi-fi when available, on the theory that it avoids blocking incoming voice calls? Does it go as far as analyzing ping times and doing background traceroutes to see which route is more direct, reliable, and fastest? Does relative signal strength enter into the equation (ie, if I'm in the back yard & have a really marginal Wi-Fi signal, will it insist on trying to use it anyway to the exclusion of a potentially stronger EV-DO signal)?
I've tried to figure it out from observation. Originally, it seemed like it always tried to use WiFi whenever possible, but then I wrote a client-server app that tries to send traffic to my desktop PC at 192.168.x.x (which obviously can only route over wi-fi). The app worked sometimes, completely failed at others, and there seemed to be almost no discernible correlation between when it worked and when it failed.

Good question. Here's the routing table of a CDMA and 802.11x connected device. I don't see any metrics indicating one would be preferred over the other. Both tiwlan0 and rmnet0 are gateways. I wonder if the CDMA and WLAN interfaces receive some sort of preference elsewhere in the stack??
Code:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
108.100.55.xx * 255.255.255.252 U 0 0 0 rmnet0
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
default 108.100.55.xx 0.0.0.0 UG 0 0 0 rmnet0
#
EDIT: I just ran 3 traceroutes to external addresses, and tiwlan0's interface was used every time. It seems to me in a routing table, the first route that can satisfy a request is used. In this case, my 10.x default gateway satisfies a route to an external address, and in my traces, that's what got used. I didn't see variable behavior.

I've found that it will always try to use wifi when available, regardless of signal strength. However, my tests have been conducted in 2 placess. One with a strong 3G signal (-72 or better) but with an incredibly unreliable wifi signal, the other with a strong wifi signal (4 to 5 feet), but at -96 to -106 to roaming 3G signal. I've found that it will try to use Wifi in both cases.

Yeah, it's something I've googled a few times, but it seems to be one of the great unexplored issues. Occasional anecdotal observations, but nobody who really knows what's officially intended to happen has ever really blogged about it online At first, it seemed pretty obvious that it would probably try to always use WiFi when possible, but when my own app started dying randomly with no route to host errors (even when I was standing with the phone literally 5 feet from the access point's antenna), I started to wonder what was really going on behind the scenes.

bitbang3r said:
Does it go as far as analyzing ping times and doing background traceroutes to see which route is more direct, reliable, and fastest? Does relative signal strength enter into the equation (ie, if I'm in the back yard & have a really marginal Wi-Fi signal, will it insist on trying to use it anyway to the exclusion of a potentially stronger EV-DO signal)?
Click to expand...
Click to collapse
IP routes are decided on subnets, masks, metrics. In most routing devices, there isn't additional intelligence unless a routing protocol is invoked, and even then, the protocol algorithm determines the best route and that route is placed in the routing table (successors are saved and inserted in the event an active route goes down).
These are all static default and subnet specific routes. Can you open adb shell, show your route table, and run a few traces to various external and internal addresses?

bitbang3r said:
Yeah, it's something I've googled a few times, but it seems to be one of the great unexplored issues. Occasional anecdotal observations, but nobody who really knows what's officially intended to happen has ever really blogged about it online At first, it seemed pretty obvious that it would probably try to always use WiFi when possible, but when my own app started dying randomly with no route to host errors (even when I was standing with the phone literally 5 feet from the access point's antenna), I started to wonder what was really going on behind the scenes.
Click to expand...
Click to collapse
I honestly don't think signal strength has anything to do with it. It should be a routing table decision.
I'm going to try a little experiment...hang on.

Ok, I disable CDMA and checked the route table:
Code:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
# ping google.com
PING google.com (74.125.95.106) 56(84) bytes of data.
64 bytes from iw-in-f106.1e100.net (74.125.95.106): icmp_seq=1 ttl=50 time=223 ms
^C
Note, ping still works and the Sprint 108.x network and associated default gw are gone.
Interestingly, when I re-enabled CDMA, the 108.x default route wasn't added back into the table and the mobile network wouldn't connect until I disabled wi-fi.
Code:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
Ping still works though:
Code:
# ping google.com
PING google.com (74.125.95.99) 56(84) bytes of data.
64 bytes from iw-in-f99.1e100.net (74.125.95.99): icmp_seq=1 ttl=50 time=1453 ms
64 bytes from iw-in-f99.1e100.net (74.125.95.99): icmp_seq=2 ttl=50 time=449 ms
Once I disabled wi-fi:
Code:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
108.101.213.xx * 255.255.255.252 U 0 0 0 rmnet0
default 108.101.213.xx 0.0.0.0 UG 0 0 0 rmnet0
Turning wi-fi back on places the tiwlan0 default back in the table above rmnet0 and traceroute went back to my 10.x gateway. This is very deterministic and exactly what I'd expect except for rmnet0 not coming back up with wi-fi enabled. It should...
Code:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
108.101.213.xxx * 255.255.255.252 U 0 0 0 rmnet0
10.0.0.0 * 255.0.0.0 U 0 0 0 tiwlan0
default 10.1.1.254 0.0.0.0 UG 0 0 0 tiwlan0
default 108.101.213.xxx 0.0.0.0 UG 0 0 0 rmnet0

The metric field in route on linux decides the weight on multiple routes, but android doesn't set it properly. Hope that makes sense.
It Is how a ' normal' linux kernel decides.

kkruse said:
The metric field in route on linux decides the weight on multiple routes, but android doesn't set it properly. Hope that makes sense.
It Is how a ' normal' linux kernel decides.
Click to expand...
Click to collapse
That's great, but the tests I ran showed deterministic behavior.
What's your source for this statement? Whether or not metrics are being used, the behavior I saw showed corresponding routing behavior.
Care to elaborate?

PPTP VPN Problem

Has anyone else had trouble with the VPN on the Atrix?
The issue I have is that, my VPN connects, and indicates it is connected, however once connected I cannot ping any computers on the other side of the VPN. (I can however ping the VPN gateway) And I cannot get my company email.
I have encryption enabled, without it enabled it will not connect. I searched around and people had similar problems with the droid X, but the only solution I found was to install pppd from the SDK over the one on the phone. I tried this but got the exact same results.
My phone is rooted, and I can ssh into it, I also have the SDK and can get an adb shell. I will happily upload any logs or iptables that will aid someone in helping me solve this. Just give me the commands and I'll show you what it outputs.
Thanks

Sounds like a DNS issue, try pinging the computers by their IP address.

joemommasfat said:
Has anyone else had trouble with the VPN on the Atrix?
The issue I have is that, my VPN connects, and indicates it is connected, however once connected I cannot ping any computers on the other side of the VPN. (I can however ping the VPN gateway) And I cannot get my company email.
I have encryption enabled, without it enabled it will not connect. I searched around and people had similar problems with the droid X, but the only solution I found was to install pppd from the SDK over the one on the phone. I tried this but got the exact same results.
My phone is rooted, and I can ssh into it, I also have the SDK and can get an adb shell. I will happily upload any logs or iptables that will aid someone in helping me solve this. Just give me the commands and I'll show you what it outputs.
Thanks
Click to expand...
Click to collapse
Same problem here. This is the first GSM Android phone that I have ever tested that has this problem and I have tested nearly all of the good ones.

Now, I am no network admin, so first off, if I am posting any sensitive info, or anything that may open me up to hacks, please inform me. Second, I don't entirely understand these numbers, but here is the output of my 'route -n', and below that, my 'ifconfig'
192.168.59.68 is my phone on my home wifi. 192.168.59.128 should no be anything. I believe 192.168.101.50 is the local address of the VPN on the remote network (since 101 is not defined in my home network). The ifconfig makes me think 192.168.101.50 patches me through to a local ip of 192.168.101.52 on the remote network. I can ping 192.168.101.52, but not 192.168.101.50.
On the remote network I should also be able to ping subdomain 192.168.155.*, and reach the mail server there, but I cannot.
Now if this helps with any debugging, the same thing happens over 3g and wireless, but if I put the same sim card in my old iphone, I can ping 192.168.155.* and get my company email just fine when connected to the same vpn.
I have also posted the same output from my dd-wrt router, which I have configured to connect to the VPN. The routes look a little different there, and I'm hoping someone with a little more networking knowledge can help me understand/fix my problem.
Thank you.
Code:
$ route -n
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.101.50 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.59.128 192.168.101.50 255.255.255.128 UG 0 0 0 ppp0
192.168.59.0 192.168.101.50 255.255.255.128 UG 0 0 0 ppp0
192.168.59.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.101.50 128.0.0.0 UG 0 0 0 ppp0
128.0.0.0 192.168.101.50 128.0.0.0 UG 0 0 0 ppp0
0.0.0.0 192.168.59.1 0.0.0.0 UG 0 0 0 eth0
below is my ifconfig
Code:
$ ifconfig
ifconfig
eth0 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.59.68 Bcast:192.168.59.255 Mask:255.255.255.0
inet6 addr: fe80::42fc:89ff:fe15:39fa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:97 errors:0 dropped:0 overruns:0 frame:0
TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20724 (20.7 KB) TX bytes:7897 (7.8 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:839 errors:0 dropped:0 overruns:0 frame:0
TX packets:839 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:45205 (45.2 KB) TX bytes:45205 (45.2 KB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.101.52 P-t-P:192.168.101.50 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1396 Metric:1
RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:98 (98.0 B) TX bytes:1592 (1.5 KB)
On my dd-wrt router, which connects and passes data:
Code:
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.101.50 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.155.0 0.0.0.0 255.255.255.0 U 0 0 0 ppp0
192.168.59.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth1
Code:
eth1 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16749239 errors:0 dropped:0 overruns:0 frame:11718459
TX packets:12308018 errors:2 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:187162042 (178.4 MiB) TX bytes:1249060681 (1.1 GiB)
Interrupt:2 Base address:0x5000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:98 errors:0 dropped:0 overruns:0 frame:0
TX packets:98 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9479 (9.2 KiB) TX bytes:9479 (9.2 KiB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.101.51 P-t-P:192.168.101.50 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1392 Metric:1
RX packets:828 errors:0 dropped:0 overruns:0 frame:0
TX packets:1123 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:304252 (297.1 KiB) TX bytes:79111 (77.2 KiB)

I'm thinking on moving from my blackberry (which has served me well, but just isn't as dynamic as i need it to be) to an ATRIX.
I had a Samsung Captivate for about 3 days, and returned it because I couldn't get VPN to work.
During my research, I came across this on the web...
code.google.com/p/android/issues/detail?id=4706
(Can't link, too new here just put http in front)
It looks like PPTP VPN Is BROKEN in Android and Google refuses to do a thing about it.
I have a PPTP VPN Server setup on Windows 2003, A separate one on 2008, one on Ubuntu Linux, and also one on a m0n0wall router. NOT A SINGLE ONE WORKS with Android, but has no issues with any other platform.
I hope they get their act together. I need to find someone with Gingerbread out there who can see if maybe they fixed it on 2.3.

jpasint said:
Same problem here. This is the first GSM Android phone that I have ever tested that has this problem and I have tested nearly all of the good ones.
Click to expand...
Click to collapse
I have this also, and have worked my way up past AT&T 2nd & 3rd level support, was passed to Motorola support, worked up through 2nd and 3rd level, and currently have an assigned "support engineer."
He confirmed they have a known bug in their VPN stack filed in their bug tracking system, but no fix release date listed yet.
In reading through a logcat from a failed VPN session I found one of the services crashed with a dump when I disconnected, and that got their attention - I couldn't tell what it meant, but the engineer was impressed with whatever it said, and sounded a bit miffed they hadn't caught the bug before release.
I tried this on the display model in an AT&T store, and got the same result, proving it wasn't just my phone or a side effect of rooting.

Man, thanks gwoozy! Somebody with some free time I guess. Hopefully they'll fix this ASAP.
I never had any success with PPTP with any CDMA droids but every GSM droid I've ever tried worked flawless except sadly the Atrix.
Thanks again for doing the leg work bro.
Joe

I haven't had much luck in the past with PPTP on android while using wap.cingular APN. It worked just fine though when I used isp.cingular via my BB SIM. YMMV

agentdr8 said:
I haven't had much luck in the past with
PPTP on android while using wap.cingular APN. It worked just fine though when I used isp.cingular via my BB SIM. YMMV
Click to expand...
Click to collapse
But if you're on WiFi then the APN doesn't matter so I don't think the wap.cingular could be an issue.
I do remember those days when the isp.cingular and wap.cingular did make the difference for VPN to work or not.
Joe

To follow up, as I see several other people have this same problem - Motorola support does not have a fix, and has no idea if they will EVER have a fix. They are mystified as to what the problem is, and could only point to a Google/Android bug:
code.google.com android project issue 4706
(I can't post external links yet)
which isn't what we are reporting. However, I could see this kind of behavior once I did this:
Root the phone (I know, but the Motorola Level 3 support person working my case suggested it)
Modify the routing tables after connecting to VPN (via an adb shell, su to root)
I had to add a route for the ppp gateway interface - Moto's kernel/Android code didn't make that one
Delete spurious routes for the VPN interface
Add a specific route for the network behind the VPN
Then I could ping an IP address behind the VPN connection and see a response, and even resolve names via the DNS server behind the VPN.
HOWEVER - as soon as I tried to do anything from Android, instead of the command line, such as open a web page in the browser hosted on the server I was currently pinging, everything stopped working - no packet traffic any more.
DNS - fail. PING - suddenly stopped reporting received packets, when it had been chugging along just fine.
That may be the Android bug above, I don't know. But I had to modify the IP routing tables to even see that.
So I will have to trade the Atrix in tomorrow for an HTC. Not worth any more of my time.
I miss Cyanogenmod 6 (which I have on my old G1), running Android 2.2.1 with kernel 2.6.35. Never any problems with that. interesting that free/open has been more stable and error-free for me than a company with a 30-year history with mobile phones.

I can't get PPTP or L2TP VPN work on Atrix 4G, that's strange.

I can't get PPTP VPN to work on the Dell Streak running Froyo. It connects to the host but no data flow. L2TP works fine.

VPN working for me after the new update.
Anyone else?

Yes, I can confirm it is working now

Interesting. I have the update and PPTP vpn still doesn't work for me. Granted it stays connected and works for about 20-30 seconds, but then all traffic fails.
I'm trying to connect to a m0n0wall, and a Windows Server 2003 RAS.
Either way, same result on both. What are you connecting to?

Pptp VPN works for me now too on 1.57

Are either of you rooted?

I am rooted and on 1.57 and PPTP VPN works for me too. I doubt rooted has anything to do with it though.

Yea, I doubt that rooting has anything to do with it as well. Guess I'll keep looking into it.

jsylvia007 said:
Are either of you rooted?
Click to expand...
Click to collapse
I am not rooted.
Joe

Android-device as an ethernet-router

The scenario: I have a rooted lollipop-TV-Box (S905) with Wifi, Ethernet (RJ45) and USB. The box is connected to internet via a wifi-router. Nearby I have a orange pi running with armbian (a debian-derivate for arm) with ethernet and USB but not wifi. I want to connect the orangepi via TVBOX-ethernet to the router to internet. This is my prefered solution. Alternativly I could also use a USB-connection between box and orangepi, but thats not prefered due to speed-reasons and the need for an additional client on the orangepi that are required for most usb-tethering solutions, and the box has no usb-tehering capabilities

I tried it the Linux-way on a linux-Machine with a shell-script. The wlan-net is 192.168.0.x the lan is 192.168.1.x. The wlan-ip in the Android/Linux router is 192.168.0.13 the lan in the same device is 192.168.1.2, the connected lan-client-ip is 192.168.2.4
the routing is Internet-(Wifi)-Gateway 192.168.0.1->Android/Linux-Box 192.168.0.13/192.168.1.2->192.168.2.4 and vice-versa
on lan-client:
ip route:
default via 192.168.1.2 dev eth0 proto static metric 1024
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.4
on Android/Linux-Router
192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.13 metric 600
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 metric 100
I also enabled forwarding and set the forward-tables with iptables
With the Linux-Box as a router everything works like a charm, with Android not, when I ping the lan-ip of the client from the Android box (ping 192.168.1.4) the reply is network unreachable from the external internet-server
PING 192.168.1.4 (192.168.1.4) 56(84) bytes of data.
From 84.116.198.82: icmp_seq=7 Destination Net Unreachable
From 84.116.198.82: icmp_seq=8 Destination Net Unreachable
From 84.116.198.82: icmp_seq=17 Destination Net Unreachable
I have to specify the interface with ping -I eth0 192.168.1.4, then it works, although this should already be specified by the local routes, like if the local request is routed over the public gateway. Looks like in Android the local routing is overriden by a hidden route to the default gateway