SOLUTION:
If any of you are having dhcp-related issues (e.g. if WiFi status, after displaying "Connecting to YOUR-AP", says 'Unsuccessful') with some routers, the solution - or at least, the one that worked for me after much trial and error - is to replace /system/lib/libnetutils.so with the 1.0 version (attached). Before, you had to either (a) set up a static dhcp lease for your nook in your router (b) use an app like WiFi Static to have your Nook not use dhcp at all.
If you're having this issue, please try this out to confirm the fix works. Please make sure to remove any static dhcp lease assignments that you've set up for your Nook before chiming in.
(Just realized that I hit the wrong button and nothing attached. Old libnetutils is now attached to this post and can also be found here!)
Code:
## backup the 1.1 file somewhere, change name to keep track
adb pull /system/lib/libnetutils.so libnetutils_1.1.so
## remount /system as writable
adb shell mount -o rw,remount /dev/block/mmcblk0p5 /system
## push the 1.0 file attached (assuming you're in same directory)
adb push libnetutils.so /system/lib/
## fix permissions (ownership is already correct, root.root)
adb shell chmod 644 /system/lib/libnetutils.so
## reboot
adb reboot
If it doesn't work - I have no answers for you. I do NOT recommend you try patching the framework, or pushing over wpa_supplicant from 1.0. The former did not change anything and the latter prevents the Nook from associating with your AP after waking up from standby entirely. Replacing /system/etc/wifi/tiwlan_drv.ko or /system/bin/dhcpcd also did not change anything.
My initial half-solutions, speculations, and meanderings, in which I figured out everything that, uh, didn't work, make up the rest of this post and thread
NOTE:
I did have one instance of WiFi reporting it was 'Unsuccessful' (which has been about dhcp) when coming out of standby (as opposed to 'Disconnected' - which is a wpa_supplicant problem). When I checked the logs, wpa_supplicant was complaining that it could not find a suitable AP though, so maybe it is about wpa_supplicant. If the problem persists or happens again, I will try replacing libwpa_client.so with the 1.0 one to see if that changes anything, even though 'Unsuccessful' has referred to dhcp.
Ugh. It looks like downloading and compiling the Android source code/decompiling some .so drivers might be on the horizon. If that's the case, then I'm out, at least for a while. In any case, turning wifi on and off isn't that much of a hassle.
-----------------------------------------------------------------------------
Hey all,
It hasn't been discussed here very much, but over at B&N's official forums, a good amount of people have been complaining that their Nook hasn't been able to connect to their WiFi, both at home and out and about, after the 1.1.0 update. Particularly, Verizon FiOS customers with the stock ActionTec MI424-WR router have been affected - myself included.
Looking at my logs, it looked like DHCP was timing out for some reason. So at first, I went into my FiOS router and had it assign a 'static' IP to my Nook explicitly; this worked fine. Then, realizing that this would only work on this single router and wouldn't cure what ails me if it turns out the same issue comes up on the road. So I poked around in the market and found an app that'll allow me to do what I can already do with my stock Android phone, and have the nook assign itself a Static IP when detecting certain APs. Now that's not going to work if you have no other way to connect to the AP than your Nook AND you do not know the ip address of the AP, but it's still helpful.
Investigation:
As the rest of the thread suggests, I've been poking around the N2E internals in an effort to figure out just what it is got changed in the wifi/dhcp stack between 1.0 and 1.1, and after some testing, I've come closer to isolating the issue!
Replacing /system/lib/libnetutils.so with its 1.0 versions gets dhcp to 'work' again! In other words, without any additional configuration whatsoever!
Unfortunately, I think that something might still be awry. Every once in a while, the WiFi state will change to 'disconnected'. I'm not sure if this is normal behavior or what, but I don't think it is, because it's been happening with 20-30 mins of a successful connection to the router, and did not occur when I was just having the router assign a static ip via dhcp or when I wasn't using dhcp at all. But, perhaps that's the way it worked with 1.0...I really don't know, because I've never really used 1.0 on a regular basis. In fact, I haven't used the nook with dhcp on a regular basis, and am basically flying blind here.
The WiFi handling stack inside /system/framework/framework.jar has also changed. But taking the wifi folder from the 1.0 framework.jar and rebuilding the 1.1 jar based on that has had no effect on any issue - it did not help dhcp work, and nor did it prevent the WiFi from changing to 'disconnected'.
While diff indicates that /system/etc/wifi/tiwlan_drv.ko has also changed, replacing it with the 1.0 version has no effect on any of the above issues.
I did some more digging around and it seems like wpa_supplicant and dhcpcd in /system/bin/ also have slightly different binaries in 1.1.0. But when I replaced them with the binaries from 1.0.0 (but using the 1.1.0 tiwlan_drv.ko), it didn't work, and DHCP still doesn't complete successfully. I have no reason to believe that using the older driver would magically fix anything - doesn't this sound like some configuration issue somewhere?
The thing is, I'm not quite sure where these configuration files or dbs would be. I dug around a bit more and found that wpa_supplicant refers to the wpa_supplicant.conf in /data/misc/wifi (the one in /system/etc/wifi doesn't seem to ever get updated). But this has no bearing on what goes on with dhcpcd, and I haven't been able to find out what, if anything, controls it
Any takers?
Also, the reason I thought that it still worked was that the static configuration that WiFi Static makes for you is not deleted by default when WiFi Static is uninstalled. To shut off static ip, the settings table at
/data/data/com.android.providers.system/databases/settings.db has to be modified so that the entry with name "wifi_use_static_ip" should have a it's value="0", not "1".
Probably it will not help, but in my experience Nook couldn't connect when my router (Siemens SLI 5300) has secured with WPA-AES key. Then i've made some experiments and i found out that using WPA2-AES key it works without any problems. 1.1 firmware of course.
domi.nos said:
Probably it will not help, but in my experience Nook couldn't connect when my router (Siemens SLI 5300) has secured with WPA-AES key. Then i've made some experiments and i found out that using WPA2-AES key it works without any problems. 1.1 firmware of course.
Click to expand...
Click to collapse
"Connect" and "obtaining IP address" is two different things.
I did some digging trough the sources today but couldn't find anything obvious in regards to the dhcp issue.
As this seem to be quite a common issue I'm a little surprised that B&N hasn't released some sort of fix yet.
With that said, I've only experienced this once, and that was with 1.0.1
ros87 said:
"Connect" and "obtaining IP address" is two different things.
I did some digging trough the sources today but couldn't find anything obvious in regards to the dhcp issue.
As this seem to be quite a common issue I'm a little surprised that B&N hasn't released some sort of fix yet.
With that said, I've only experienced this once, and that was with 1.0.1
Click to expand...
Click to collapse
Roger-
So did I miss anything? It looks like everything related to wlan/dhcpcd can be found in:
/system/bin (binaries for loading wifi driver, wpa_supplicant, and dhcpcd)
/system/etc/wifi (wifi driver, minor configuration)
/system/etc/dhcpcd (minor configuration)
/data/misc/wifi (wpa_supplicant.conf that actually gets used)
/data/data/com.android.providers.system/databases/settings.db
I'm not quite sure what to look for in the settings.db. That database corresponds to this part of the android api though:
http://developer.android.com/reference/android/provider/Settings.System.html
I'm also not sure how to actually configure what calls wpa_supplicant and dhcpcd. Looking at my logs, it looks like a few different services are on the scene, mostly reporting what did what, I guess? But I don't know how to configure them or which of them spawns wpa_supplicant or dhcpcd. Here's the log I posted a few weeks ago, again, for convenience (don't have to click the link from above):
Code:
I/wpa_supplicant( 2539): CTRL-EVENT-SCAN-RESULTS Ready
I/wpa_supplicant( 2539): Trying to associate with FIOS_ROUTER_MAC_ADDRESS (SSID='MYSSID' freq=2462 MHz)
I/wpa_supplicant( 2539): CTRL-EVENT-STATE-CHANGE id=-1 state=3
V/WifiMonitor( 805): Event [Trying to associate with FIOS_ROUTER_MAC_ADDRESS (SSID='MYSSID' freq=2462 MHz)]
V/WifiMonitor( 805): Event [CTRL-EVENT-STATE-CHANGE id=-1 state=3]
V/WifiStateTracker( 805): Changing supplicant state: DISCONNECTED ==> ASSOCIATING
D/NetworkStateTracker( 805): setDetailed state, old =DISCONNECTED and new state=CONNECTING
D/ConnectivityService( 805): ConnectivityChange for WIFI: CONNECTING/CONNECTING
I/wpa_supplicant( 2539): CTRL-EVENT-STATE-CHANGE id=2 state=4
I/wpa_supplicant( 2539): Associated with FIOS_ROUTER_MAC_ADDRESS
I/wpa_supplicant( 2539): CTRL-EVENT-STATE-CHANGE id=2 state=5
V/WifiMonitor( 805): Event [CTRL-EVENT-STATE-CHANGE id=2 state=4]
V/WifiStateTracker( 805): Changing supplicant state: ASSOCIATING ==> ASSOCIATED
D/NetworkStateTracker( 805): setDetailed state, old =CONNECTING and new state=CONNECTING
V/WifiMonitor( 805): Event [Associated with FIOS_ROUTER_MAC_ADDRESS]
V/WifiMonitor( 805): Event [CTRL-EVENT-STATE-CHANGE id=2 state=5]
I/wpa_supplicant( 2539): CTRL-EVENT-STATE-CHANGE id=2 state=5
I/wpa_supplicant( 2539): CTRL-EVENT-STATE-CHANGE id=2 state=6
I/wpa_supplicant( 2539): WPA: Key negotiation completed with FIOS_ROUTER_MAC_ADDRESS [PTK=CCMP GTK=CCMP]
I/wpa_supplicant( 2539): CTRL-EVENT-STATE-CHANGE id=2 state=7
I/wpa_supplicant( 2539): CTRL-EVENT-CONNECTED - Connection to FIOS_ROUTER_MAC_ADDRESS completed (auth) [id=2 id_str=]
V/WifiStateTracker( 805): Changing supplicant state: ASSOCIATED ==> FOUR_WAY_HANDSHAKE
D/NetworkStateTracker( 805): setDetailed state, old =CONNECTING and new state=AUTHENTICATING
D/ConnectivityService( 805): ConnectivityChange for WIFI: CONNECTING/AUTHENTICATING
V/WifiMonitor( 805): Event [CTRL-EVENT-STATE-CHANGE id=2 state=5]
V/WifiStateTracker( 805): Changing supplicant state: FOUR_WAY_HANDSHAKE ==> FOUR_WAY_HANDSHAKE
V/WifiMonitor( 805): Event [CTRL-EVENT-STATE-CHANGE id=2 state=6]
V/WifiStateTracker( 805): Changing supplicant state: FOUR_WAY_HANDSHAKE ==> GROUP_HANDSHAKE
D/NetworkStateTracker( 805): setDetailed state, old =AUTHENTICATING and new state=AUTHENTICATING
V/WifiMonitor( 805): Event [WPA: Key negotiation completed with FIOS_ROUTER_MAC_ADDRESS [PTK=CCMP GTK=CCMP]]
V/WifiMonitor( 805): Event [CTRL-EVENT-STATE-CHANGE id=2 state=7]
V/WifiStateTracker( 805): Changing supplicant state: GROUP_HANDSHAKE ==> COMPLETED
V/WifiMonitor( 805): Event [CTRL-EVENT-CONNECTED - Connection to FIOS_ROUTER_MAC_ADDRESS completed (auth) [id=2 id_str=]]
V/WifiStateTracker( 805): New network state is CONNECTED
W/BluetoothHeadset( 805): Proxy not attached to service
D/WifiStateTracker( 805): DhcpHandler: DHCP request started
D/NetworkStateTracker( 805): setDetailed state, old =AUTHENTICATING and new state=OBTAINING_IPADDR
D/dhcpcd ( 2546): dhcpcd 4.0.15 starting
D/dhcpcd ( 2546): hardware address = NOOK_MAC_ADDRESS
D/dhcpcd ( 2546): executing `/system/etc/dhcpcd/dhcpcd-run-hooks', reason PREINIT
D/WsprService( 862): Received android.net.wifi.STATE_CHANGE action.
D/SettingsWifiEnabler( 862): Received network state changed to NetworkInfo: type: WIFI[], state: CONNECTING/OBTAINING_IPADDR, reason: (unspecified), extra: (none), roaming: false, failover: false, isAvailable: true
D/dhcpcd ( 2546): host does not support a monotonic clock - timing can skew
D/dhcpcd ( 2546): broadcasting for a lease
D/dhcpcd ( 2546): sending DHCP_DISCOVER with xid 0x834efe68, next in 2.52 seconds
D/ConnectivityService( 805): ConnectivityChange for WIFI: CONNECTING/OBTAINING_IPADDR
D/SurfaceFlinger( 805): Frame buffer posted; elapsed time = 15 msecs
D/SurfaceFlinger( 805): Frame buffer posted; elapsed time = 18 msecs
D/dhcpcd ( 2546): sending DHCP_DISCOVER with xid 0x834efe68, next in 3.12 seconds
I/WifiStateTracker( 805): DhcpHandler: DHCP request failed: Timed out waiting for DHCP to finish
I/wpa_supplicant( 2539): CTRL-EVENT-STATE-CHANGE id=2 state=8
V/WifiMonitor( 805): Event [CTRL-EVENT-STATE-CHANGE id=2 state=8]
V/WifiStateTracker( 805): Changing supplicant state: COMPLETED ==> DORMANT
D/WifiStateTracker( 805): Deconfiguring interface and stopping DHCP
D/dhcpcd ( 2546): received SIGTERM, stopping
I/wpa_supplicant( 2539): CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
I/wpa_supplicant( 2539): CTRL-EVENT-STATE-CHANGE id=-1 state=8
V/WifiMonitor( 805): Event [CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys]
V/WifiMonitor( 805): Event [CTRL-EVENT-STATE-CHANGE id=-1 state=8]
D/NetworkStateTracker( 805): setDetailed state, old =OBTAINING_IPADDR and new state=FAILED
I/wpa_supplicant( 2539): succeeded in stopping the last periodical scan
E/wpa_supplicant( 2539): Start periodical(connection) scan.
D/NookWifiManager( 1045): Cannot connect to pre-configured networks
D/DeviceManagerBroadcastReceiver( 1097): action (com.nook.intent.action.OOBE_WIFI_ENABLE_RESPONSE)
D/NookWifiManager( 1097): Cannot connect to pre-configured networks
D/NookWifiManager( 1116): Cannot connect to pre-configured networks
V/WfDownloader( 1116): +WifiManagerObserver: Wifi status: FAILURE__FAILED_TO_ASSOCIATE
V/WfDownloader( 1116): -WifiManagerObserver
V/WifiStateTracker( 805): New network state is DISCONNECTED
V/WifiStateTracker( 805): Changing supplicant state: DORMANT ==> DORMANT
D/ConnectivityService( 805): ConnectivityChange for WIFI: DISCONNECTED/FAILED
V/ConnectivityService( 805): Attempt to connect to WIFI failed.
D/WsprService( 862): Received android.net.wifi.STATE_CHANGE action.
D/SettingsWifiEnabler( 862): Received network state changed to NetworkInfo: type: WIFI[], state: DISCONNECTED/FAILED, reason: (unspecified), extra: (none), roaming: false, failover: false, isAvailable: true
There is also the following in /init.rc. But shouldn't that only get run once?
service wlan_loader /system/bin/tiwlan_loader \
-f /system/etc/wifi/firmware.bin \
-i /system/etc/wifi/tiwlan.ini \
-e /rom/devconf/WiFiBackupCalibration
disabled
oneshot
service ifcfg_ti /system/bin/ifconfig tiwlan0 up
disabled
oneshot
service wpa_supplicant /system/bin/wpa_supplicant -Dtiwlan0 -itiwlan0 -c/data/misc/wifi/wpa_supplicant.conf -dd
socket wpa_tiwlan0 dgram 660 wifi wifi
disabled
oneshot
service dhcpcd /system/bin/dhcpcd -ABKL -d tiwlan0
disabled
oneshot
# TI WLAN Soft AP related services and configuration
service wlan_ap_loader /system/bin/tiap_loader \
-f /system/etc/wifi/softap/firmware_ap.bin \
-i /system/etc/wifi/softap/tiwlan_ap.ini
disabled
oneshot
service udhcpd /system/bin/udhcpd /system/etc/udhcpd/udhcpdWlan.conf
disabled
oneshot
service hostapd /system/bin/hostapd -dd /data/misc/wifi/hostapd.conf
disabled
oneshot
service keystore /system/bin/keystore /data/misc/keystore
user keystore
group keystore
socket keystore stream 666I haven't got an earlier version of init.rc to compare this to.
Is there any way to specify that dhcpcd let DHCP_DISCOVER actions take longer? I thought it was supposed to take 60 seconds by default, so it is being configured otherwise elsewhere. But where??? Right now it sort of gives up right away.
-e
LastSilmaril said:
Roger-
So did I miss anything? It looks like everything related to wlan/dhcpcd can be found in:
Click to expand...
Click to collapse
Well, we don't have the sources for the kernel module, nor the binaries, so I was just looking at the kernel stuff.
My guess is that it is some miniscule thing somewhere, but not in kernel nor the configs as far as I can see.
Well if it's not in the kernel that's good right? And by kernel, do you mean the kernel itself or the driver?
I found a manpage for dhcpcd; the following switches are being passed to dhcpcd in init.rc:
http://roy.marples.name/cgi-bin/man-cgi?dhcpcd
-A, --noarp
Don't request or claim the address by ARP. This also disables
IPv4LL.
-B, --nobackground
Don't run in the background when we acquire a lease. This is
mainly useful for running under the control of another process,
such as a debugger or a network manager.
-K, --nolink
Don't receive link messages for carrier status. You should only
have to use this with buggy device drivers or running dhcpcd
through a network manager.
-L, --noipv4ll
Don't use IPv4LL (aka APIPA, aka Bonjour, aka ZeroConf).
So as the lack of much standalone configuration files for dhcpcd has already hinted, uh, this doesn't seem to be a dhcpcd config issue.
I'm not sure how to be able to write to init.rc (so I can add "-t 30" to see if that'll do anything). I don't know what partition it's on but cannot just write it back to root (read-only filesystem). Setting system to writable makes no difference, so we can assume it's not hiding on there somewhere. There is a copy of it at /data/local/tmp/init.rc but just modifying that does nothing; /init.rc is not a symlink to /data/local/tmp/init.rc.
This thing might be helpful, but is a bit over my head.
http://blog.linuxconsulting.ro/2010/04/porting-wifi-drivers-to-android.html
LOL, I've been pushing and pulling things without giving a second thought to proper permissions. Can somebody please run ls -l on the following files and post what the proper permissions are supposed to be? I haven't run into issues yet, but I don't want to muck things up.
Code:
/system/etc/wifi/tiwlan0-drv.ko
/system/bin/wpa_supplicant
/system/bin/dhcpcd
/system/etc/dhcpcd/dhcpcd-run-hooks
really? I'm surprised more people here aren't completely up in arms about this issue, which is a matter of basic usability. I've even come across someone with an e2000 with dd-wrt with issues, so it's not just old routers/crippled ISP routers that this is happening to. BN is completely unresponsive, so it's up to us!
LastSilmaril said:
LOL, I've been pushing and pulling things without giving a second thought to proper permissions. Can somebody please run ls -l on the following files and post what the proper permissions are supposed to be? I haven't run into issues yet, but I don't want to muck things up.
Code:
/system/etc/wifi/tiwlan0-drv.ko
/system/bin/wpa_supplicant
/system/bin/dhcpcd
/system/etc/dhcpcd/dhcpcd-run-hooks
Click to expand...
Click to collapse
Correct permissions (per my backup) are:
1. /system/bin/dhcpcd
755, root.shell
2. /system/bin/wpa_supplicant
755, root.shell
3. /system/etc/wifi/tiwlan_drv.ko
644, root.root
4. /system/etc/dhcpcd/dhcpcd-run-hooks
550, dhcp.shell
Also, the diffing I did that led me to think that wpa_supplicant and dhcpcd had changed may not have been accurate, since it may be that the Linux Reader extracting program I was using mucks with the files. When I compare the file sizes of wpa_supplicant and dhcpcd between my 1.0.0 and 1.1.0 backups, I found no difference. The difference is there between the WiFi drivers though - that's something that's definitely changed. But simply dropping it in *still* does not work. It's maddening...
LastSilmaril said:
The difference is there between the WiFi drivers though - that's something that's definitely changed. But simply dropping it in *still* does not work. It's maddening...
Click to expand...
Click to collapse
I don't think this is a problem for that many users of the NST, you might find 20 - 30 reports on the net, maybe a hundred if you really go at it, but that still is just a fraction of the NST owners. So don't expect to see much interest in this topic I'm afraid.
Now, the tiwlan drivers are not unique to the NST, they are part of the omap3 platform and maintained by TI and you might want to look for similar problems there and even updated sources (if the tiwlan module is at fault at all).
ros87 said:
I don't think this is a problem for that many users of the NST, you might find 20 - 30 reports on the net, maybe a hundred if you really go at it, but that still is just a fraction of the NST owners. So don't expect to see much interest in this topic I'm afraid.
Now, the tiwlan drivers are not unique to the NST, they are part of the omap3 platform and maintained by TI and you might want to look for similar problems there and even updated sources (if the tiwlan module is at fault at all).
Click to expand...
Click to collapse
That's exactly the problem Roger - I'm not sure how it is they are at fault if dumping in the old 1.0.0 driver does not help matters...but I can't seem to find anything else that's changed! In the meantime I mucked things up poking around, and decided to go back to stock 1.1.0 and am now re-rooting.
In the meantime though, I'm not sure where exactly to poke around; do you know what version of OMAP3 is in the nook?
(BTW- does anybody know a way around the 'sideloaded books on sdcard do not persist in shelves' problem? Happens in all firmwares, stock or rooted...)
-e
...how do we 'decompile' (meh...) stuff in android?
I have discovered apktool.
Poking around framework.jar under smali/android/net/wifi, there are several changes in there in comparison to the framework from 1.0.
1) BnIpConfig.smali and friends are not in 1.0 (at least not in android/net/wifi)
2) WifiStateTracker$DhcpHandler.smali is 3KB bigger in 1.1.
and many more...
Could this finally be it? I'm tempted to simply dump the android/net/wifi folder in from 1.0 and see what happens (love being fully backed up).
Also, /system/lib/libnetutils.so has changed.
I'm a little bit uneasy messing with this, but I've got backup upon backup now, including several CWM backups, so I'm gonna press on!
I think I may have finally figured it out, after some further testing. Nothing to do with patching framework.jar. But, last time I thought it worked, status would change to 'Disconnected' for no apparent reason after a few minutes. If I'm still connected to WiFi in two hours, I'll post a solution and instructions.
LastSilmaril said:
I think I may have finally figured it out, after some further testing. Nothing to do with patching framework.jar. But, last time I thought it worked, status would change to 'Disconnected' for no apparent reason after a few minutes. If I'm still connected to WiFi in two hours, I'll post a solution and instructions.
Click to expand...
Click to collapse
EDIT: ...Yup, it's definitely disconnecting at some point. I'm not sure if this is normal behavior or what, but somehow I doubt it.
OK, quick update...
1) First, it seems that the only file with any relevance (and this makes sense) is libnetutils.so. The older binaries of dhcpcd and wpa_supplicant are not necessary to get the dhcp to complete.
2)WiFi intermittently switching to 'disconnected' is because of a failure to associate with the AP - not anything to do with dhcp. Why it has to associate again - what causes the 'Disconnect event' - I do not know. But as my wpa_supplicant when this was happening was from 1.0 (and the failure to associate was unambiguously reported by wpa_supplicant), I decided to push back the stock 1.1 wpa_supplicant. Let's see if anything changes as a result. If so, then this whole masturbatory thread will have turned out to be about one measly file
Hello,
I am currently running codefireX SR14. My provider is Petro-Canada Mobility. I am having issues when tethering through their "unlimited browsing service" Basically this service only allows http/SSL TCP traffic on ports 80/443.
Anyhow, I've been using autoproxy and this has allowed me greater functionality of most apps. Here lies the problem. When I attempt to tether (wifi hotspot or USB) Traffic is not being forwarded at all from the hotspot gateway. As a result, connected hosts cannot access the internet. After doing some initial troubleshooting, I have concluded the issue appears to be the OS itself.
Regardless of the situation, the hotspot gateway will not forward traffic with autoproxy connected, disconnected, or if I use my Junos VPN.
As a result I have 2 questions:
1)How does the Android tether operate?
2)Are there any "Backend" options I can access someone to force the gateway to forward traffic through autoproxy or my Junos VPN?
I have included the trouble shooting results below:
When tethered:
My PC IP = 192.168.43.83
gateway = 192.168.43.1
Ping to gateway is ok:
>ping 192.168.43.1
Pinging 192.168.43.1 with 32 bytes of data:
Reply from 192.168.43.1: bytes=32 time=23ms TTL=64
Reply from 192.168.43.1: bytes=32 time=2ms TTL=64
Reply from 192.168.43.1: bytes=32 time=1ms TTL=64
Reply from 192.168.43.1: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.43.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
This means my PC can reach the gateway fine (with autoproxy on and off) With that in mind, I try to ping the Petro-Canada proxy server:
Proxy server IP = 10.128.1.69
Ping to Proxy server fails
>ping 10.128.1.69
Pinging 10.128.1.69 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.128.1.69:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
This happens regardless if autoproxy is connected or disconnected. What this means is that the gateway traffic on my phone is not being properly forwarded.
When I usb tether it's the same issue:
PC IP:192.168.42.142
Gateway:192.168.42.129
Ping to gateway is ok:
>ping 192.168.42.129
Pinging 192.168.42.129 with 32 bytes of data:
Reply from 192.168.42.129: bytes=32 time<1ms TTL=64
Reply from 192.168.42.129: bytes=32 time<1ms TTL=64
Reply from 192.168.42.129: bytes=32 time<1ms TTL=64
Reply from 192.168.42.129: bytes=32 time<1ms TTL=64
Ping statistics for 192.168.42.129:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Ping to Proxy server fails
>ping 10.128.1.69
Pinging 10.128.1.69 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.128.1.69:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
This happens regardless if autoproxy is connected or disconnected. What this means is that the gateway traffic on my phone is not being properly forwarded.
At this point I believe the issue to be Android OS. I am running Jellybean 4.2.2, I also have Junos VPN installed, and I have full internet from my phone when connected (all ports tcp/udp) through Petro-Canada unlimited browsing. I still run into the same issue where trying to ping any outside IP results in a timeout. (i.e Google DNS 8.8.8.8)
I fixed the issue. I'm not sure if it's the ROM or my provider.