Motorola Droid Full Solution Updated
- Thread starter LindaLoo
- Start date
digimonkid_2000
New member
"Fake" is a less than technical term, but CONNECT was designed for HTTPS. Most proxies only allow CONNECT on port 443 for this reason, making u2nl useless, although some of them are wide open to allow for general tunneling. I'm sure that Cricket is fine with it being used as a general tunnel or they wouldn't have opened it so wide.
The issue here isn't your intent, or the original purpose of the protocol though. It is speed, cpu, and battery consumption. Data will always travel from your Droid to the Cricket proxy, if it is going to work at all.
The question is, do you want a 15 megabyte youtube video to be downloaded in a tcp connection that goes from your Droid to the Cricket proxy, and then back from the Cricket proxy into your Droid?
Or a connection that goes from your Droid, back in to your Droid using loopback on port 1025 (u2nl), and then back out your Droid into the Cricket proxy, then back from the Cricket proxy into u2nl, and then finally passed off from u2nl to the YouTube app over the loopback network interface?
Every chunk of that video data has to go back through u2nl. There is no need for it when the YouTube app is perfectly capable of talking to the Cricket proxy on its own. U2nl is designed for apps like the instant messengers that don't use http, and need to use the proxy but aren't capable of doing it themselves. That extra step of being passed through u2nl on loopback is good in cases like that because without it the program wouldn't work at all.
The issue here isn't your intent, or the original purpose of the protocol though. It is speed, cpu, and battery consumption. Data will always travel from your Droid to the Cricket proxy, if it is going to work at all.
The question is, do you want a 15 megabyte youtube video to be downloaded in a tcp connection that goes from your Droid to the Cricket proxy, and then back from the Cricket proxy into your Droid?
Or a connection that goes from your Droid, back in to your Droid using loopback on port 1025 (u2nl), and then back out your Droid into the Cricket proxy, then back from the Cricket proxy into u2nl, and then finally passed off from u2nl to the YouTube app over the loopback network interface?
Every chunk of that video data has to go back through u2nl. There is no need for it when the YouTube app is perfectly capable of talking to the Cricket proxy on its own. U2nl is designed for apps like the instant messengers that don't use http, and need to use the proxy but aren't capable of doing it themselves. That extra step of being passed through u2nl on loopback is good in cases like that because without it the program wouldn't work at all.
guamerica1
New member
Here are the results of test.sh:
Code:
iptables -t nat -A OUTPUT -o ppp0 -p tcp -d 172.29.100.15 --dport 80 -j DNAT --to-destination 172.29.100.15:80
iptables -t nat -A OUTPUT -o ppp0 -p tcp --dport 80 -j DNAT --to-destination 10.132.25.254:8080
iptables -t nat -A OUTPUT -o ppp0 -p tcp ! -d 10.132.25.254 ! --dport 8080 -j REDIRECT --to-port 1025So does it still work for you if you comment out the MMS lines?
It works for token according to his PM's. Everything seems to be detected right. Your ppp0, his rmnet0. The correct IP addresses. I don't see a u2nl line there but I'm guessing it just didn't paste.
All I can say is experiment with it and try to include more details about what works and what doesn't, and when (like with certain lines commented out). This really isn't much different than what we were using before.
There are lots of variables and resolving hostnames and stuff, but once it comes down to the iptables and u2nl lines, most of it is the same. If you are still having problems, try to see what differences caused the problem by changing things back.
Some examples, remove the --dport $PROXYPORT part of the last iptables line, or comment out the first iptables line completely, or the second one, or both of them. Each should be attempted on its own, and there is no need to reboot between experiments.
It works for token according to his PM's. Everything seems to be detected right. Your ppp0, his rmnet0. The correct IP addresses. I don't see a u2nl line there but I'm guessing it just didn't paste.
All I can say is experiment with it and try to include more details about what works and what doesn't, and when (like with certain lines commented out). This really isn't much different than what we were using before.
There are lots of variables and resolving hostnames and stuff, but once it comes down to the iptables and u2nl lines, most of it is the same. If you are still having problems, try to see what differences caused the problem by changing things back.
Some examples, remove the --dport $PROXYPORT part of the last iptables line, or comment out the first iptables line completely, or the second one, or both of them. Each should be attempted on its own, and there is no need to reboot between experiments.
I don't remember if I already mentioned this, but it is worth mentioning again anyway.
The test scripts are _only_ useful to show what the iptables and u2nl lines look like when the real autostart script runs. If wrong devices (ppp0/rmnet0) or ip addresses show up with the test scripts, that shows why the real autostart.sh is broken.
The test scripts are not functional. In fact, running them will break networking. Be sure to do all real networking tests using the autostart.sh from the beta folder, or a script you modified from that.
The test scripts are _only_ useful to show what the iptables and u2nl lines look like when the real autostart script runs. If wrong devices (ppp0/rmnet0) or ip addresses show up with the test scripts, that shows why the real autostart.sh is broken.
The test scripts are not functional. In fact, running them will break networking. Be sure to do all real networking tests using the autostart.sh from the beta folder, or a script you modified from that.
Yves Saint Laurant
New member
As an update, so far the new "Beta" scripts for me are not working. Only the origonal script with hardcoded ip's is working.
i have tested on an HTC rom and a Cyanogen based rom, both fail, i wasnt able to obtain the results from the test scripts in cyanogen, but i can report back later if we need.
im going to tinker some more later tonight but i have to work my entire weekend this week so my test/play time is limited, but ill report back if i get something working with the new scripts.
If they are working for the droid then awesome, ill just need to find out what needs to be tweaked for the eris/hero/evo/incredible, also once this is fully working im going to try to incorporate a flash that universally works as well.
Awesome work by the way !! your work/dedication is amazing
i have tested on an HTC rom and a Cyanogen based rom, both fail, i wasnt able to obtain the results from the test scripts in cyanogen, but i can report back later if we need.
im going to tinker some more later tonight but i have to work my entire weekend this week so my test/play time is limited, but ill report back if i get something working with the new scripts.
If they are working for the droid then awesome, ill just need to find out what needs to be tweaked for the eris/hero/evo/incredible, also once this is fully working im going to try to incorporate a flash that universally works as well.
Awesome work by the way !! your work/dedication is amazing
Bride2Be 10-17-09
New member
Thanks for experimenting on this token. We have no deadlines here, so don't worry about it.
I moved the scripts to old/2 and started a new series. autostart.sh is the same as before.
beta1.sh is modified to get rid of all of the dynamic things like device and ip address detection. It is like the old scripts, but it uses the new iptables rules. It uses the motorola (standard) ppp0, so to use it on a htc device you need to change that to rmnet0 by hand. That will be true for all of the beta scripts. If this script works, it means the dynamic part of the new script is failing on your phone.
beta2.sh is the same, but becomes even closer to the old scripts by changing the rule that forwards all traffic that isn't going to Cricket's proxy on the proxy port to u2nl, and being less specific. It forwards it if it isn't going to Cricket's proxy, but doesn't care about the port.
beta3.sh is the same as beta2.sh, but with the MMS iptables rule removed.
beta4.sh is the same as beta3.sh, but without the "forward web traffic straight to Cricket's proxy" rule. This is almost exactly the same as the old script.
beta5.sh is the same as beta4.sh, but replaces -p tcp with -p 6, so it is exactly the same as the old scripts. Other than forwarding output from the kill command to /dev/null.
Try them in any order you want. I ordered them so that if you go from 1 to 5, you should come across useful information quicker if it suddenly starts working.
That's pretty disappointing to hear. I can't really say what it means, but it looks like everything worked like it should. That is until it stopped. Nothing new about the script should cause it to stop. It runs and closes just like before. Are you sure it stays off permanently? This doesn't make sense. Maybe the new scripts will help us.
I recommend trying a few different sites before you are sure it's dead, and also try the market and youtube app
I moved the scripts to old/2 and started a new series. autostart.sh is the same as before.
beta1.sh is modified to get rid of all of the dynamic things like device and ip address detection. It is like the old scripts, but it uses the new iptables rules. It uses the motorola (standard) ppp0, so to use it on a htc device you need to change that to rmnet0 by hand. That will be true for all of the beta scripts. If this script works, it means the dynamic part of the new script is failing on your phone.
beta2.sh is the same, but becomes even closer to the old scripts by changing the rule that forwards all traffic that isn't going to Cricket's proxy on the proxy port to u2nl, and being less specific. It forwards it if it isn't going to Cricket's proxy, but doesn't care about the port.
beta3.sh is the same as beta2.sh, but with the MMS iptables rule removed.
beta4.sh is the same as beta3.sh, but without the "forward web traffic straight to Cricket's proxy" rule. This is almost exactly the same as the old script.
beta5.sh is the same as beta4.sh, but replaces -p tcp with -p 6, so it is exactly the same as the old scripts. Other than forwarding output from the kill command to /dev/null.
Try them in any order you want. I ordered them so that if you go from 1 to 5, you should come across useful information quicker if it suddenly starts working.
That's pretty disappointing to hear. I can't really say what it means, but it looks like everything worked like it should. That is until it stopped. Nothing new about the script should cause it to stop. It runs and closes just like before. Are you sure it stays off permanently? This doesn't make sense. Maybe the new scripts will help us.
I recommend trying a few different sites before you are sure it's dead, and also try the market and youtube app
doakpersoncat
New member
i went in order from beta 1 - 4, i stopped at 4 because 4 is where i got internet working in the browser/widgets again.
awesome work, going to inspect the scripts more and see if i can find what is causing it to fail.
awesome work, going to inspect the scripts more and see if i can find what is causing it to fail.
The Plague
New member
So if you take the new autostart script (beta/autostart.sh) and comment out the middle iptables line, does that work?
I mean like this:
I mean like this:
Code:
iptables -t nat -A OUTPUT -o $INTERFACE -p tcp -d $MMSIP --dport $MMSPORT -j DNAT --to-destination $MMSIP:$MMSPORT
#iptables -t nat -A OUTPUT -o $INTERFACE -p tcp --dport 80 -j DNAT --to-destination $PROXYIP:$PROXYPORT
iptables -t nat -A OUTPUT -o $INTERFACE -p tcp ! -d $PROXYIP ! --dport $PROXYPORT -j REDIRECT --to-port 1025that works like a champ
Verified Browser (HTTP and HTTPS) - Widgets - Market - Maps - Gmail - all working fine with that line commented out.
MMS did not send, ill have to tinker a few, i have been modifying my MMS so that very well could be on my end, and cricket sometimes goes up and down for me even with known good settings.
Verified Browser (HTTP and HTTPS) - Widgets - Market - Maps - Gmail - all working fine with that line commented out.
MMS did not send, ill have to tinker a few, i have been modifying my MMS so that very well could be on my end, and cricket sometimes goes up and down for me even with known good settings.
Surprising. So this means that the Cricket proxy doesn't support transparent proxying. Unfortunately everything still has to go through u2nl. The good thing is that the rest appears to work. This will be great news for dealers who get angry customers coming in when the wap server changes IP addresses.
The last test is the MMS stuff. I'd like to not have MMS go through u2nl or the proxy. That test can't be done if your MMS isn't working right now, so don't worry about it.
To anyone reading the thread at this point, it looks like beta/autostart.sh is safe to use, and probably better than the normal one. If it works for you and MMS still works too, please try mmstest1.sh and mmstest2.sh and tell me which one breaks your MMS.
Thanks to everyone who has helped so far.
The last test is the MMS stuff. I'd like to not have MMS go through u2nl or the proxy. That test can't be done if your MMS isn't working right now, so don't worry about it.
To anyone reading the thread at this point, it looks like beta/autostart.sh is safe to use, and probably better than the normal one. If it works for you and MMS still works too, please try mmstest1.sh and mmstest2.sh and tell me which one breaks your MMS.
Thanks to everyone who has helped so far.
You can try commenting out the line above the last one you commented out to see if that fixes MMS, but I doubt it.
I just realized I said your name earlier when I meant to say insane66 had it working. I think the transparent proxying might only work in some areas. It is probably best to keep it all going through u2nl to be safe.
I just realized I said your name earlier when I meant to say insane66 had it working. I think the transparent proxying might only work in some areas. It is probably best to keep it all going through u2nl to be safe.
mms is working fine for me, looks like a temporary hiccup in crickets network. (i only commented the ONE line you specified earlier)
my MMS APN settings are as follows:
replace the Red xxxxxxxxxx with your telephone number
im going to experiment and go back to the previous known good MMS settings that do not require the telephone number (more generic that work in a universal patch) and see if i can get that working before i roll out a new flash
my MMS APN settings are as follows:
Code:
im going to experiment and go back to the previous known good MMS settings that do not require the telephone number (more generic that work in a universal patch) and see if i can get that working before i roll out a new flash