Related
After the update the 3g Icon keeps popping up when I am on wifi. going on and off. Its like something is using 3g only even though I have a solid wifi connection.
Anybody else see this?
I don't have 2.3.3 yet, but I know the phone will do that when an app wants to grab a network location or has restrictions on transmitting/receiving data over WiFi; 3G will pop up for a second or two while it uses the connection, then disappear again when it's done.
I had a small problem and then reloaded the network and all is good.
Mine is doing the same thing as we speak... How do you reload the network?
Sent from my Nexus S using XDA App
same. solid wifi signal, yet 3g was also on...
I Did however have issues with a MiFi Dongle with my nexus but I think it might have been the coverage area. Speedtest would give me low latency but ok with my girlfriends blackberry
I have the same issue...
same here
Guys, try switching to a different carrier in network settings, this should fail and kill your connection. Then switch back to the correct one for your sim card.
moon-unit said:
Guys, try switching to a different carrier in network settings, this should fail and kill your connection. Then switch back to the correct one for your sim card.
Click to expand...
Click to collapse
worked for me! thanks
unfortunately doesn't work for me
Happens here as well and it seems it's GPS/NetworkLocation related. That's what comes up in the log about every 20 seconds:
Code:
I/GPS ( 111): on_request_connection: successfully called
...
I/GPS ( 111): assist_gps_data_conn_open: successfully called
I/GPS ( 111): gps_engine_status_update: called acquire_wakelock_cb
I/GPS ( 111): assist_gps_data_conn_closed: called
I/GPS ( 111): on_supl_session_ended: successfully called
I/GPS ( 111): gps_engine_status_update: called release_wakelock_cb
When the screen is off it seems to stop after a while and then doesn't come back until I open an application that uses location (Maps, GPS Status) and then it will again do it every 20 seconds.
I switched to 2g for a while. Now back on 3g and with wifi on it isn't doing it (for now...)
Sent from my Nexus S using XDA App
mine has the same issue..sometimes it just going but coming back again right after..
Same poblem here, sometime it won't even connect to google services (green icons), google need to fix this issue, was this update even tested.
Anyone with this issue/bug could you please report it in the thread linked below over at the google mobile forum.
Nexus S, WiFi/3G issue after updating to Android 2.3.3 / I9020XXKB1 / GRI40
Thanks!
same problem, reported as well
I killed gpsd daemon by kill command and nexus returned to normal operation (gpsd restarted automatically).
Upd. I was one time solution, the bug reappeared after reboot.
The location update request every 20 secs seems be normal.
If you look at the logcat, even with 3g enabled and wifi disabled, you can see that the location request is still happening every 20 secs.
The difference with 2.3.3 is that every time the location request is occurring, the 3g icon pops up.
So I don't think there is anything wrong, but it is annoying and causes the UI to hiccup for a sec, so I hope google can push out a fix for it.
mlotz said:
Happens here as well and it seems it's GPS/NetworkLocation related. That's what comes up in the log about every 20 seconds:
Code:
I/GPS ( 111): on_request_connection: successfully called
...
I/GPS ( 111): assist_gps_data_conn_open: successfully called
I/GPS ( 111): gps_engine_status_update: called acquire_wakelock_cb
I/GPS ( 111): assist_gps_data_conn_closed: called
I/GPS ( 111): on_supl_session_ended: successfully called
I/GPS ( 111): gps_engine_status_update: called release_wakelock_cb
When the screen is off it seems to stop after a while and then doesn't come back until I open an application that uses location (Maps, GPS Status) and then it will again do it every 20 seconds.
Click to expand...
Click to collapse
Nexus S 2.3.3 wi-fi..
..is more powerfull than 2.3.2?
Hi,
I recently noticed then even when I have in Location & Security settings disabled "Use wireless networks" phone tries to connect non stop to bcmls2.glpals.com port 7275 which is server for LBS as specified in gps.conf.
The connection succeeds but no data transfer happens and it just keeps going forever on wifi or data connection whatever is available.
At same time in log appear messages:
E/GPS (107): [on_request_connection][line = 1061]: Failed with NO SESSION SLOT.
System is stock 2.3.3.
Anybody saw something like this ?
Where you able to debug this?
I've installed aLogCat today on my NS, and I'm seing a lot of entries like that: "[on_request_connection][line = 1061]: Failed with NO SESSION SLOT"
Anyway to know what's responsible for this?
Tks
Same here with Nexus S, is there any way to catch what application is responsible for the log spit?
I'm having the exact same entry:
[on_request_connection][line = 1061]: Failed with NO SESSION SLOT
This occurs when I'm trying to download an Application from the Market when connected to Wifi. The download just stalls and never really initiates. When I'm off of Wifi, but on 3G, though, the download goes through flawlessly.
Anyone know what's going on?
file it as a bug to google
Done: code.google.com/p/android/issues/detail?id=16185
Hadn't debug it.
But in order to prevent it from generating traffic all the time replaced bcmls2.glpals.com with 127.0.0.1
4/20/11 Update: Added a second workaround for the libsecgps synchronization bug that otherwise allows multiple GPS requests to be sent to the RIL, causing the GPS to crash on assistance downloads (via GPS Status & Toolbox) and on application switch/exit. Details on this and the assistance workarounds, which are complementary to each other, follow below.
To folks with GPS problems:
If your GPS reliably works after a reboot, but ceases to work after appreciable uptime, it's quite likely that one or both of these workarounds will address the issue. Try the crash workaround first, as all EC05 Epics are vulnerable to the libsecgps synchronization bug, whereby the GPS crashes and is only recoverable by a full power cycle. If you continue to have issues, the assistance workaround may further help by keeping your assistance data fresh.
If your GPS rarely or never works in EC05, even outdoors with clear skies, even after a reboot, it's quite possible the assistance workaround will help. But please post in the thread or PM me first, as I'm interested in obtaining a boot-time logcat that would confirm the exact issue you're suffering.
Summary of issues discovered and/or resolved in this thread:
NTP/XTRA data doesn't download/inject on boot (jdelano; addressed by assistance workaround).
Synchronization bug with RIL that causes the GPS to crash (slwelsh; addressed by crash workaround).
Stale ephemeris (from XTRA data) after a few hours to a day of uptime. Possibly addressed by assistance workaround, needs confirmation (aero1, buggerritt, slwelsh?).
Time until ephemeris becomes stale differs across devices. Unknown cause, although a separate workaround exists to improve this to a day or longer (buggerritt).
4/11/11 Update: Fixed the update.zips so they actually flash in ClockworkMod. Apparently /system needs to be mounted, which it already is in stock recovery.
GPS assistance workaround:
Attached is a platform source patch against android-cts-2.2_r2 that, hopefully, works-around most assistance-related EC05 GPS problems by modifying the GPS location provider to download & inject time (NTP) and assistance (XTRA) data every time the "Use GPS satellites" setting is enabled. Also attached is a smali patch against EC05's /system/framework/framework.odex that implements this workaround in bytecode.
Finally, attached are testkey-recovery (e.g., ClockworkMod) flashable "update.zip"s including modified a modified framework.odex or framework.jar for: (i) the EC05 stock ROM, (ii) deodexed (framework-unmodified) ROMs, (iii) SyndicateROM Frozen 1.1.0 and (iv) midNIGHT ROM 5.2. All three implement the GPS workaround, and the first two also contain the TWS bug fix and ringer volume control mod. I'll try to take requests for additional ROMs as I can.
Assistance workaround directions:
Once flashed, keep the "Use GPS satellites" setting/notification widget toggle off until you're ready to use GPS. While having (any) active data connection, toggle GPS on and wait about five seconds before attempting a GPS fix.
Alternatively, if you always keep the GPS toggle on, toggle it off & on again to download new assistance data when you have difficulty getting a fix.
Assistance background:
In Froyo, the Epic GPS works in "standalone mode" with various types of supplemental assitance data pushed ("injected") by the GPS location provider if they're available. This includes:
XTRA (ephemeris & almanac) data: Downloaded and pushed automatically on reboot after a network connection is established.
NTP time: Nominally pushed after reboot and every four hours thereafter.
Location: Location data from other providers (e.g., cellular, wifi, etc.).
The XTRA ephemeris data, combined with a rough estimate of current location and an accurate (NTP-synced) clock, provides the GPS receiver with precise orbital positions of each satellite, allowing the receiver to quickly lock onto them even in weak signal (e.g., indoor) conditions or in the present of multipath (e.g., high-rise buildings). The gpsonextra servers appear to update XTRA data every hour at half-past. It's ephemeris data is (to the best I can discern) supposed to be valid for one week, although it's speculated that the Epic GPS may consider this data stale after a much shorter period of time, perhaps a few days, and in some cases, no more than a few hours.
The almanac data provides the GPS receiver with coarse orbital parameters of each satellite, allowing the receiver to locate the satellites reasonably quickly when outdoors with clear sky visibility. However, in absence of recent ephemeris (e.g., from XTRA or a previous fix), the receiver must download the current ephemeris from each satellite. Satellites broadcast their own ephemeris every 30 seconds, and thus, the receiver requires 30-60 seconds of strong signal from each satellite in order to obtain its ephemeris and lock onto it. The ephemeris broadcast from the satellite is valid for five hours, much less than that of the XTRA data. Each satellite also broadcasts the almanac data for the entire constellation every 12.5
minutes, and this data is valid for a few months.
This all means that, an Epic with recent XTRA data, NTP sync, and location estimate should be able to lock onto any visible satellite quickly (less than 10 seconds), possibly even indoors, whereas an Epic with stale ephemeris will fall back to using almanac data and should fix within a minute outdoors with clear sky visibility. Thus, Epics that take a long time to fix or can't fix indoor likely suffer from stale ephemeris. However, as long as these phones retain a GPS fix for at least fifteen minutes once every month or so, their almanac data will be fresh enough to operate indefinitely in this degraded mode.
Assistance workaround details:
XTRA data is downloaded automatically on boot, but it isn't downloaded again unless requested by the GPS receiver. Although this data is supposed to be valid for one week, folks report that their Epics take a long time to fix (30+ seconds) after a day, or even just a few hours of uptime, suggesting that the ephemeris downloaded at boot data becomes stale.
I don't know the root cause of why this data becomes stale, although it seems that temporarily downgrading and obtaining fixes in DI18 will improve the amount of time the ephemeris is considered valid to a day or longer in instances where it's only good for a few hours.
The idea behind this workaround is to exploit a simple heuristic: by activating the GPS toggle the user intends to use GPS for a while, so that's (probably) the best time to download new assistance data. Even if the toggle is left on all the time, it's an intuitive means to "reset" the GPS that most users will try, so it should download new assistance data every time. So while this might not directly fix the stale-ephemeris issue, hopefully this workaround will make the current and future assistance problems less relevant since they're easily bypassed.
A second issue is that NTP time and/or XTRA data often fails to be acquired on boot. The GPS location provider waits until there's an available network connection before connecting to the NTP and XTRA servers. However the "network available" notification doesn't quite work right, and the initial NTP request may happen before DNS resolvers are registered and the NTP request fails hostname lookup. While I never observed a failed XTRA download on my phone due to lookup failure, this seems to be the case with others. If you have trouble acquiring a fix even after a reboot, failed XTRA downloads may be to blame.
Since this workaround doesn't attempt to do NTP/XTRA until the GPS is enabled, this should no longer be an issue. However, to ensure it works in most instances when the GPS is left enabled across a reboot, I've added a network-notification settle delay of 5 seconds, which should be long enough (2.5 seconds is the longest it took my phone to settle) that NTP/XTRA will work on boot in that instance.
GPS crash workaround:
Attached is a platform source patch against android-cts-2.2_r2's liblog that avoids the GPS crash that happens when multiple GPS requests are sent via libsecgps to the RIL, which occurs during assistance downloads (via GPS Status & Toolbox) and on application switch/exit.
Also attached is a testkey-recovery (e.g., ClockworkMod) flashable "update.zip"s including a patched liblog.so for all EC05 (stock, deodexed, and custom) ROMs. I've also attached a "backout" update.zip that replaces liblog.so with the original EC05 version, should anyone wish to revert to it.
Crash workaround directions:
None, it works automatically once flashed.
Crash background:
The Epic's GPS receiver is integrated into the baseband, and communication with it is done via the Radio Interface Layer (RIL). The native library, libsecgps.so, implements various GPS-oriented commands (open, stop, location_fix, inject_time, xtra_set_data, and others) as requests, via the RIL, to be performed by the baseband processor and GPS receiver.
When a GPS app runs, location_fix requests are issued (synchronously) by a native library timer once every second while the app is actively seeking fixes. When a GPS app is closed or suspended, a stop request is issued to the GPS to cease fixing on satellites. Regarding these stop requests, it's important to note that: stops are often asynchronous, being the result of user action; and there appears to be no locking to ensure that a stop request is performed outside a location_fix cycle.
That is, a stop may come: (i) just prior to a location_fix request being issued, (ii) just after a request is issued but before it's sent to the baseband, (iii) after the baseband receives the request and performs the fix, and (iv) after the resulting location data is sent back (which completes a location_fix cycle).
A stop performed outside a location_fix cycle (iv) is most preferable, but due to the length of a location_fix cycle (~0.7 s) this happens only a third of the time. Most often, a stop if performed while a fix is actively being performed (iii) which results in a harmless recoverable error. However, if a stop is performed just before a location_fix is issued (i) or just after (ii), before the baseband can fully receive it, then the two requests may collide, throwing the baseband-side GPS functionality into an unrecoverable error state that is resolved only by a power cycle.
The critical window here is approximately 60 ms wide, meaning that the GPS crashes with 5% probability during a stop, or any other asynchronous request that occurs while the GPS is actively fixing. In other words, on average, every 20 GPS app closes/suspsends results in a GPS crash. For folks who use the GPS once or twice the day during a long navigation session, a crash may rarely be observed. For folks who use various GPS-utilizing apps throughout the day, crashes happen regularly after a day or two of uptime on average.
It's also worth noting that an XTRA download issues 40 xtra_set_data requests in a short window of time (~7 s). While these are safe outside an active fix (e.g., on boot or GPS toggle w/assistance workaround), if an assistance download is performed during active GPS use, e.g., via GPS Status & Toolbox, the GPS almost always crashes and the download fails. This is actually why GPS Status's assistance features appear not to work in Froyo, although with the crash workaround, I believe they do.
GPS workaround details:
Ultimately the GPS crash is due to insufficient locking in libsecgps that enables the interleaving of simultaneous requests to the RIL. Although we've observed instances where libsecgps appears to defer requests, it's locking behavior is insufficient to prevent interleaving in many instances.
For illustrative purposes, here's an excerpt of the log statements produced by libsecgps when properly processing a location_fix request:
Code:
...
D/libgps ( 2931): send_ril_gps_location_fix_req: start_mode 1
D/libgps ( 2931): newGpsRequest: new gps req 0x4303c8 cmd 5, idx 1
D/libgps ( 2931): send_ril_gps_request: cmd 0x05 plen 18
D/libgps ( 2931): ril_gps_wait_for_ril: req 0x4303c8 wait 1000
D/libgps ( 2931): ril_gps_wait_for_ril: +++entering
D/libgps ( 2931): ril_gps_wait_for_ril: current tv_sec 1302648124 tv_nsec 519263548
D/libgps ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302648125 tv_nsec 519263548
D/libgps ( 2931): onRawReqComplete: oem_function_id 0x0E cmd 0x05 len 4
D/libgps ( 2931): process_response: req 0x4303c8 cmd 0x05 plen 1
D/libgps ( 2931): recv_ril_gps_location_fix_req: status 0
D/libgps ( 2931): ril_gps_wakeup: 0x4303c8
D/libgps ( 2931): ril_gps_wakeup: Entered critsec
D/libgps ( 2931): ril_gps_wakeup: Left critsec
D/libgps ( 2931): ril_gps_wait_for_ril: (n=0, r=0)
D/libgps ( 2931): removeGpsRequest : removed req with cmd 5
...
The newGpsRequest function is called by the issuing thread for each request. Requests are then sent to the RIL (send_ril_gps_request) and the issuing thread waits on a condition varible (ril_gps_wait_for_ril). The RIL wakes up (ril_gps_wakeup), sends the request to the baseband, and signals the issuing thread to wake again. The issuing thread then deletes the request (removeGpsRequest).
For comparison, here's an excerpt of the log when a stop request interleaves a location_fix:
Code:
...
D/libgps ( 2931): send_ril_gps_stop_req:
D/libgps ( 2931): newGpsRequest: new gps req 0x3900f8 cmd 6, idx 2
D/libgps ( 2931): send_ril_gps_location_fix_req: start_mode 1
D/libgps ( 2931): newGpsRequest: new gps req 0x390958 cmd 5, idx 1
D/libgps ( 2931): send_ril_gps_request: cmd 0x05 plen 18
D/libgps ( 2931): ril_gps_wait_for_ril: req 0x390958 wait 1000
D/libgps ( 2931): ril_gps_wait_for_ril: req 0x3900f8 wait 1000
D/libgps ( 2931): ril_gps_wait_for_ril: +++entering
D/libgps ( 2931): ril_gps_wait_for_ril: +++entering
D/libgps ( 2931): ril_gps_wait_for_ril: current tv_sec 1302652321 tv_nsec 191173085
D/libgps ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302652322 tv_nsec 191173085
D/libgps ( 2931): ril_gps_wait_for_ril: current tv_sec 1302652321 tv_nsec 210846213
D/libgps ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302652322 tv_nsec 210846213
D/libgps ( 2931): ril_gps_wait_for_ril: (n=110, r=0)
E/libgps ( 2931): ril_gps_wait_for_ril: pthread_cond_timedwait error. (n=110, r=0)
E/libgps ( 2931): RIL Request: ERROR 1 (n=110, r=0)
D/libgps ( 2931): removeGpsRequest : removed req with cmd 6
D/libgps ( 2931): ril_gps_wait_for_ril: (n=110, r=0)
E/libgps ( 2931): ril_gps_wait_for_ril: pthread_cond_timedwait error. (n=110, r=0)
E/libgps ( 2931): RIL Request: ERROR 1 (n=110, r=0)
D/libgps ( 2931): removeGpsRequest : removed req with cmd 5
...
This time, a second newGpsRequest (location_fix) appears before the first (stop) request completes. Both threads appear to send their requests to the RIL, but the RIL never wakes up (no ril_gps_wakeup). Although it likely does, sees invalid data in its request buffer, and dies or something. Meanwhile the two issuing threads wait on the condition variable, which is never signaled. Eventually the condition variable times out and the request fail. At this point, the GPS has effectively crashed, as any subsequent GPS request to the RIL fails with the same error.
Fixing this synchronization bug involves either repairing the existing libsecgps locking logic, or adding new logic to prevent the interleaving of two or more requests. Unfortunately it's quite difficult to diagnose, repair, patch, and subsequently maintain said patch for source-code-less native libraries.
However, as libsecgps frequently makes use of logging statements, as illustrated above, during the processing of GPS requests, we can instrument the logging library to hijack the log calls and provide the necessary synchronization. Since libsecgps uses the logging routines provided by liblog, a library unmodified-by-Samsung for which we have source code, this is where the workaround code is placed.
Specifically, this workaround modifies liblog's __android_log_print's to look for logging messages made by libsecgps (libgps). Each newGpsRequest log statement signifies the creation of a request. When a second request (newGpsRequest statement) is encountered before an outstanding request completes, liblog defers the request by forcing the issuing thread to wait on a condition variable that's later signaled by the completion of RIL receiving the first request (ril_gps_wakeup). This prevents two requests from interleaving, and provides the necessary synchronization to prevent a GPS crash.
Final notes:
At this point the assistance workaround has been tested by multiple parties, some of whom have reported an improvement in GPS fix times, and none of whom have reported side-effects or adverse behavior.
The crash workaround has been tested by myself and slwelsh for three days now without either of us experiencing a crash or side-effects. At this point, I invite others to test the crash workaround, particularly if you experience them on a frequent basis as well.
As usual, please keep a copy of Odin and a stock/custom ROM tar file on hand, just in case something silly happens and your phone is bricked.
Also, while we've had a lot of feedback on folks's GPS issues already in this thread, I'd still appreciate feedback on whether these workarounds help you, or if you have a different GPS-related problem that you believe is not yet addressed by these.
Assistance workaround (mirror links, do not require forum login):
platform_gps_xtra_on_enable.diff
platform_gps_xtra_on_enable_smali.diff
tws_fix_ringer_vib_silent_gps-EC05-odex.zip
tws_fix_ringer_vib_silent_gps-EC05-deodex.zip
gps_xtra_on_enable-SRF110.zip
gps_xtra_on_enable-midNIGHT52.zip
Crash workaround (mirror links, do not require forum login):
platform_gps_request_sync.diff
gps_request_sync-EC05.zip
orig_liblog-ECO5.zip (to backout the crash workarond)
Wow, nice work
Isn't this just doing what the app GPS status already does?
Does the phone still pull data even if use wireless networks is NOT checked? I've tested my gps a few times WITHOUT it checked and I'm getting a lock to 10 meter accuracy in under 5 seconds while indoors.
I thought the GPS app doesn't work properly for our phones? I could be wrong though
theimpaler747 said:
Isn't this just doing what the app GPS status already does?
Click to expand...
Click to collapse
Sent From My Evo Killer!!!
musclehead84 said:
I thought the GPS app doesn't work properly for our phones? I could be wrong though
Sent From My Evo Killer!!!
Click to expand...
Click to collapse
Huh, not sure.... either way, nicely done
Before I flash yet another piece of code on my phone, I'd like to know if this mod will do something more or different than the "Reset GPS State" and "Download Assistance Data" commands in the GPS Status and Tools app. I've tried those buttons numerous times with no results, so I am reluctant to flash a mod that doesn't do anything different, as I can't see how it will behave differently.
Also, could you please post the instructions for backing this mod out in the event that it does not fix the problem?
Thanks.
-Sean
theimpaler747 said:
Isn't this just doing what the app GPS status already does?
Click to expand...
Click to collapse
I'm not sure exactly what GPS Status & Toolkit does, but this suggests that the "Download Assistance Data" approach should be the similar. Although it's possible that the API GPS Status uses to do that doesn't work for other reasons.
One difference might be that GPS Status downloads new assistance data after attempting to start a fix, which happens when starting the application. Whereas this workaround (can) download assistance data before attempting a fix. I don't know if this is the case, but I understand how new assistance data might be ignored by the GPS while a fix is attempted, and even shortly thereafter.
mrzood said:
Does the phone still pull data even if use wireless networks is NOT checked? I've tested my gps a few times WITHOUT it checked and I'm getting a lock to 10 meter accuracy in under 5 seconds while indoors.
Click to expand...
Click to collapse
I believe the XTRA data is downloaded on boot regardless of that setting, although I've not confirmed that. However, what may be different is that with that setting disabled, location data is never injected.
Are you consistently getting fixes without "Wireless networks" and not with it? Is this when using 3G data, 4G data, wifi, or all of the above?
If it's with wifi, is the location data for your access point accurate? That is, if you pull up Maps with "Wireless networks" enabled, wifi on, and GPS disabled, is your location on the map accurate or far off?
musclehead84 said:
I thought the GPS app doesn't work properly for our phones? I could be wrong though
Click to expand...
Click to collapse
It definitely didn't under DI18/Eclair, although I don't believe Eclair supported the XTRA download interface. I've not tried it since upgrading to Froyo.
slwelsh said:
Before I flash yet another piece of code on my phone, I'd like to know if this mod will do something more or different than the "Reset GPS State" and "Download Assistance Data" commands in the GPS Status and Tools app. I've tried those buttons numerous times with no results, so I am reluctant to flash a mod that doesn't do anything different, as I can't see how it will behave differently.
Click to expand...
Click to collapse
Have you tried them under Froyo, or just in Eclair?
This workaround doesn't do "Reset GPS State". It should do somthing similar to "Download Assistance Data". The two differences is that I've confirmed this workarond actually downloads assistance data, I'm not sure that GPS Status does. The second is that the assistance data is, nominally, downloaded and pushed before a GPS fix is attempted (in recent history), wheras the GPS Status approach does it after a recent fix is attempted, which may influence whether the data is actually used.
slwelsh said:
Also, could you please post the instructions for backing this mod out in the event that it does not fix the problem?
Click to expand...
Click to collapse
If you're running EC05 stock, before installing this, make a backup copy of "/system/framework/framework.odex" to "/data/local/tmp". If nothing else, this can be done with an "adb shell":
Code:
cat /system/framework/framework.odex > /data/local/tmp/framework.odex
sync
then go ahead and install the appropriate update.zip.
If you wish to backout the modification, make sure "USB debugging" is enabled and reboot into ClockworkMod. Connect the USB cable, pull up an "adb shell", and run:
Code:
cat /data/local/tmp/framework.odex > /system/framework/framework.odex
sync
then reboot. Once rebooted, feel free to delete the backup /data/local/tmp/framework.odex.
If you're running a deodexed ROM instead of stock, replace "framework.odex" with "framework.jar" in the above directions. Note that replacing "framework.jar/odex" is best done in recovery since it's not used then. If you replace it while the phone is running under a normal boot, it should still take, but it might cause your phone to panic and reboot.
Alternatively, you can replce "framework.odex" or "framework.jar" in one of the update.zips with the copy from your phone and install that update.zip from ClockworkMod. Or if you prefer, I can prepare an update.zip containing the appropriate file in place--which ROM?
mkasick said:
Have you tried them under Froyo, or just in Eclair?
Click to expand...
Click to collapse
Just FroYo. I'd have to roll back to Eclair to try any of this (or even see if my GPS has problems on that release).
This workaround doesn't do "Reset GPS State". It should do somthing similar to "Download Assistance Data". The two differences is that I've confirmed this workarond actually downloads assistance data, I'm not sure that GPS Status does. The second is that the assistance data is, nominally, downloaded and pushed before a GPS fix is attempted (in recent history), wheras the GPS Status approach does it after a recent fix is attempted, which may influence whether the data is actually used.
Click to expand...
Click to collapse
Fair enough, that sounds like a good reason to at least give this patch a try. My GPS reliably stops working within a day or two after boot, so, in theory, just toggling GPS off and then back on again should inform us whether this patch resolves my issue.
... Or if you prefer, I can prepare an update.zip containing the appropriate file in place--which ROM?
Click to expand...
Click to collapse
I'm on SRF 1.1.0 now, although I had exactly the same issues on stock EC05 delivered as an OTA update to the DI18 that came on the phone.
-Sean
Also, it would be really helpful for folks who do find they have problems, to start CatLog's log recording feature before enabling GPS, then enable and attempt a fix, stop the log record, and send the recorded log if the fix didn't work.
Or if you run into a bad fix when not actively recording, you can still run CatLog and save its latest buffer, although it might not contain information from far enough back to be useful, hence recording is preferred.
If you're concerned about the contents of the log, you can filter for lines containing "gps" (case insensitive, please) after pulling it to a workstation.
slwelsh said:
Just FroYo. I'd have to roll back to Eclair to try any of this (or even see if my GPS has problems on that release).
Click to expand...
Click to collapse
I don't think it's worth doing that. Eclair's GPS problems are well known, Froyo does things completely differently.
slwelsh said:
I'm on SRF 1.1.0 now, although I had exactly the same issues on stock EC05 delivered as an OTA update to the DI18 that came on the phone.
Click to expand...
Click to collapse
SRF shouldn't make a difference. Did you want an update.zip for SRF's stock framework.jar, or were the above directions sufficient?
Also, reinstalling SRF will get rid of it, but that's a bit more of a hassle.
Bonsia version?
i'd love to check this out; any chance of a Bonsai version?
midNight is based off of Bonsai.
I have aLogCat installed; I'll run it it and capture what my GPS does (gps only use networks is turn off) and then what it captures after flashing this fix.
If you think what would be useful to you.
mkasick said:
... Did you want an update.zip for SRF's stock framework.jar, or were the above directions sufficient?
Click to expand...
Click to collapse
I think I can get by with the directions. That said, I would not turn you down if you wanted to post a flashable back-out zip.
I flashed your mod this morning. In order to capture useful data, I am leaving my GPS on full-time, so that when it fails, I can turn recording on in CatLog before attempting to toggle. If experience is any guide, that will be sometime in the next 48 hours. Whatever happens, I will post the results here.
-Sean
jdelano said:
i'd love to check this out; any chance of a Bonsai version?
midNight is based off of Bonsai.
Click to expand...
Click to collapse
I take it you are having GPS fix problems on Bonsai? I ask because in several other threads there are posts from Bonsai users (and developers) stating that Bonsai does not suffer from this same GPS problem. To the point where I had been considering switching from SRF to Bonsai just to get rid of the GPS issues.
-Sean
slwelsh said:
I take it you are having GPS fix problems on Bonsai? I ask because in several other threads there are posts from Bonsai users (and developers) stating that Bonsai does not suffer from this same GPS problem. To the point where I had been considering switching from SRF to Bonsai just to get rid of the GPS issues.
-Sean
Click to expand...
Click to collapse
I'm using midNIGHT Rom which is based off of bonsai, and i have absolutely 0 gps issues. I get a lock within a few seconds.
jdelano said:
i'd love to check this out; any chance of a Bonsai version?
Click to expand...
Click to collapse
To avoid complications, I'll only post modified frameworks for ROMs found in the Development section of this site. But if you want, feel free to send me a copy of /system/framework/framework.jar from your phone and I'll patch it for you. I'll PM details.
Also, I did add a modified framework for midNIGHT ROM 5.2 to the OP. It's in the "mirror links" section to avoid too many large attachments.
jdelano said:
I have aLogCat installed; I'll run it it and capture what my GPS does (gps only use networks is turn off) and then what it captures after flashing this fix.
Click to expand...
Click to collapse
Does aLogCat allow active recording, or only postmortem capture? I didn't see an active recording option when I checked. The postmortem capture didn't contain enough history. Either way, if you do use aLogCat, please make sure to use the "time" format in the settings--logs are much more useful with timestamps.
slwelsh said:
That said, I would not turn you down if you wanted to post a flashable back-out zip.
Click to expand...
Click to collapse
Alright, I'll try to get to it in a bit. OK, here it is:
orig_framework-SRF110.zip
slwelsh said:
In order to capture useful data, I am leaving my GPS on full-time, so that when it fails, I can turn recording on in CatLog before attempting to toggle.
Click to expand...
Click to collapse
Prior to this modification, did you leave GPS on all the time? Off most of the time? If both, did the issues happen in either case, or with only one of them?
slwelsh said:
I ask because in several other threads there are posts from Bonsai users (and developers) stating that Bonsai does not suffer from this same GPS problem.
Click to expand...
Click to collapse
It's not clear to me exactly how widespread the EC05 GPS problems are. Before I wrote this, I only had bad fixes a good three or so times. I probably wouldn't have thought much of it except other folks were reporting issues too.
In which case, it wouldn't surprise me that no Bonsai users have experienced the issue. That's not quite the same as definitively saying that Bonsai users can't sufffer from it.
It's also not clear to me that the problems are limited to EC05 either. Some folks haven't been able to get fixes from as far back as DK28--I'm actually rather curious to know if this helps them or not.
mkasick said:
To avoid complications, I'll only post modified frameworks for ROMs found in the Development section of this site. But if you want, feel free to send me a copy of /system/framework/framework.jar from your phone and I'll patch it for you. I'll PM details.
Also, I did add a modified framework for midNIGHT ROM 5.2 to the OP. It's in the "mirror links" section to avoid too many large attachments.
Does aLogCat allow active recording, or only postmortem capture? I didn't see an active recording option when I checked. The postmortem capture didn't contain enough history. Either way, if you do use aLogCat, please make sure to use the "time" format in the settings--logs are much more useful with timestamps.
Click to expand...
Click to collapse
yes aLogCat has a start and stop logging option. with active recording.
my gps locks but its not very close and if i have use networks it grabs the next town over.
Thanks for the zip; I'll give it a go (doing a backup before hand of course) ...
mkasick said:
Alright, I'll try to get to it in a bit. OK, here it is
Click to expand...
Click to collapse
Thanks.
Prior to this modification, did you leave GPS on all the time? Off most of the time? If both, did the issues happen in either case, or with only one of them?
Click to expand...
Click to collapse
I've tried it both ways and problems happen either way.
My issue is the one where I can get 7-12 bird fixes in under two seconds when the GPS is working, and it works fine after reboot for an indeterminate period of time. When it fails, not only do I not get a fix, but I see no birds, either. The symptom is almost as if the GPS receiver is powered off. As near as I can tell, it does not matter how long I leave the GPS on after this happens, it will never see a single bird.
Furthermore, there have been times when a simple reboot (from SRF's reboot option on the shutdown menu) does not fix the problem (although some times it does) and I have to actually "power off" then restart.
Neither toggling GPS nor using the tools in GPS Status to reset the A-GPS state or download assistance data fixes it. GPSCLRX has no effect. And I have tried various configurations of /etc/gps.conf and /data/secgps.conf all with no success.
It's not clear to me exactly how widespread the EC05 GPS problems are. ... It's also not clear to me that the problems are limited to EC05 either. Some folks haven't been able to get fixes from as far back as DK28 ...
Click to expand...
Click to collapse
I've had this problem since the day I got my phone. It came with DI18 on it, and I was told that FroYo was going to fix it. The OTA EB13 rollout had been suspended the day before I got the phone, so I patiently waited for the rollout to resume, resisting the temptation to flash a ROM or even root the phone until I had the OTA FroYo update from Sprint.
Of course, when Sprint resumed the OTA rollout it was with EC05. My problem did not go away. A quick check of the forums revealed that users who had the EB13 upgrade had their GPS problems resolved under EB13, only to have them return under EC05. By this time, I only had a day or two left under the 30-day return policy to make a decision, and I figured that if they had fixed the problems under EB13 that surely there would eventually be a way to fix them under EC05. I am beginning to regret that decision, since I use LBS apps constantly and they are a key reason for me to have a smartphone in the first place.
Thanks so much for all your assistance. I have given up on Sprint/Samsung fixing this in any kind of reasonable timeframe and I have high hopes that the development community will figure this out and resolve it soon.
-Sean
slwelsh said:
My issue is the one where I can get 7-12 bird fixes in under two seconds when the GPS is working, and it works fine after reboot for an indeterminate period of time.
Click to expand...
Click to collapse
OK, I've seen that before. I've also had problems where the GPS will eventually see satellites and fix, but it takes a rather long time, upwards of five minutes. The latter mostly happened under DI18, I don't think I've waited around long enough to differentiate between the two problems the few times it's happened in EC05.
slwelsh said:
Furthermore, there have been times when a simple reboot (from SRF's reboot option on the shutdown menu) does not fix the problem (although some times it does) and I have to actually "power off" then restart.
Click to expand...
Click to collapse
This is actually quite interesting.
To my knowledge, a "reboot" only reboots the Hummingbird CPU. I suspect (but have not confirmed) that the baseband CPU actually stays running throughout. Or at least, when I have had occasional wonky-radio issues, a simple "reboot" would not clear them. It requires a full device powerdown, which should reset the baseband as well.
It's relevant because, the stock EC05 behaior is to download XTRA data on reboot. It wasn't clear to me before whether GPS issues were being resolved as a function of receiving new XTRA data, or as a function of a baseband reset. However, if you find that a "reboot" doesn't always fix the GPS problems, that suggests that once it's in a sad state, it's possible that only a baseband reset will fix it. Alternatively, it may also be that a "reboot" doesn't always download new XTRA data, if it's attempted before a network connection is fully up.
I suppose we'll find out in a day or two, but if it is the case that the GPS won't recover from it's "sad state" without a power cycle, we might be able to keep it from ever reaching its sad state by keeping the assistance data fresh before attempting fixes. This would require consciously toggling the GPS before attempting a fix if one hasn't been performed in a long time. So, if you do run into a problem in the next day or two, this might be worth trying next.
slwelsh said:
I've had this problem since the day I got my phone.
Click to expand...
Click to collapse
I suppose it's also possible that some Epics just have bad GPS chips. If so, the existence of a separate assistance problem that was present in DI18 for so long makes it difficult to differentiate between the two. Hopefully this isn't the case.
Anyways, let's see what logcat says.
I thought I was smart, until this mystery completely stumped me. I've sought out as much data as possible, but I'm utterly puzzled as to what is causing the problem. I would be really curious to see if anyone can digest my data and come up with a conclusion! My phone is the Sensation 4G.
The Problem:
- Certain (but not all) HTTPS websites requiring SSL don't work and create an error #107 (screenshot below).
- The most notable example is Twitter's HTTPS site, but there are lots of others.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
When it Happens:
- The error does not occur on my phone, if I switch to WiFi, or use someone else's SIM.
- The error does not occur on the Galaxy Note (stock), using my SIM.
- The problem occurs on the HTC Desire Z (CM9), using my SIM.
- The problem occurs on my phone, regardless of ROM used. It happens in ICS (AOSP), and in JB (CM10).
- The problem occurs in both Chrome and the stock browser.
Table Summarizing My Data:
Observations / Theories:
- It cannot be my SIM (or the account), because my SIM inserted into a Galaxy Note had no problem.
- It cannot be the Sensation 4G hardware, because the problem doesn't occur with WiFi, and the problem also occurs on the Desire Z hardware.
- It cannot be HTC phones in general, because the Desire Z has no problem with the Wifi or with a Rogers SIM.
- It cannot be ROM related, because the problem occurs in CM9, CM10, and AOSP.
But these observations don't actually lead to a conclusions about what the problem could be caused by.....
NEW INFORMATION:
A new development has lead me to believe that this must be a more widespread problem than I initially suspected. I think there's a common/persistant problem with CyanogenMod that affects certain SSL connections on Bell Mobility's network. What's this new development?
- I bought a brand new phone 2 days ago. A Galaxy SII HD LTE.
- This also means I got a brand new SIM card because the new phone required MicroSIM
- I didn't migrate anything from my old phone.
And here's the kicker. The new phone, with the new SIM, running a fresh install of CM9, also cannot connect to certain SSL sites. The same error #107 occurs, and just like before, if I switch the new phone onto WiFi, there are no problems. Similarly, if I leave the phone with the stock ICS, no problems.
At this stage, the ONLY common denominators are:
- Bell Mobility network
- CyanogenMod 9 or 10
And since the Bell Mobility network can be ruled out (since the stock OS on this phone works, as do other Bell Mobility phones), the problem must be something to do with CyanogenMod.
I have some additional data / clues to add to the mix here:
As I mentioned previously, no problem occurs over WIFI, but the problem occurs if I switch to mobile data. So I took a logcat of the failure (error 107 when trying to retrieve https://www.twitter.com) over mobile data, followed by another logcat of the problem not occurring over wifi.
The problem occurring (mobile data):
Code:
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/IInputConnectionWrapper( 1701): getExtractedText on inactive InputConnection
W/ThrottleService( 348): unable to find stats for iface rmnet0
E/chromium( 1701): [ERROR:ssl_client_socket_openssl.cc(803)] handshake failed; returned -1, SSL error code 1, net_error -107
E/chromium( 1701): [ERROR:ssl_client_socket_openssl.cc(803)] handshake failed; returned -1, SSL error code 1, net_error -107
Everything working fine (wifi):
(I redacted a few portions that seemed to be unique IDs in URLs. I replace the IDs with "--redacted--")
Code:
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
I/dalvikvm( 1701): Jit: resizing JitTable from 4096 to 8192
D/dalvikvm( 1701): GC_CONCURRENT freed 6169K, 68% free 5376K/16643K, paused 8ms+12ms, total 185ms
I/chromium( 1701): [INFO:CONSOLE(17)] "Revision: --redacted--", source: https://mobile.twitter.com/ (17)
D/ChromeBrowserSyncAdapter( 1701): no delayed sync
I/chromium( 1701): [INFO:CONSOLE(0)] "Creating Application Cache with manifest https://mobile.twitter.com/cache/manifest", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Checking event", source: (0)
W/chromium( 1701): [WARNING:spdy_session.cc(1117)] Received data frame for invalid stream 13
I/chromium( 1701): [INFO:CONSOLE(463)] "Loaded: 1787", source: https://mobile.twitter.com/ (463)
I/chromium( 1701): [INFO:CONSOLE(462)] "Started: 1855", source: https://mobile.twitter.com/ (462)
I/chromium( 1701): [INFO:CONSOLE(53)] "appcache: checking", source: https://mobile.twitter.com/ (53)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Downloading event", source: (0)
I/chromium( 1701): [INFO:CONSOLE(53)] "appcache: downloading", source: https://mobile.twitter.com/ (53)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (0 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/framework/core/assets/m_spinner_black.png", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (1 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/applications/m5/views/core/timelines/assets/dotted-pattern.png", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (2 of 12) https://mobile.twitter.com/i/templates/m5", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (3 of 12) https://mobile.twitter.com/", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (4 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/framework/core/assets/twitter_logo.png", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (5 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/plugins/defer/pullrefresh/assets/pulltorefresh_bg.png", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (6 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/applications/m5/assets/sprite_mobile.png", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (7 of 12) https://mobile.twitter.com/assets/m5_defer.js", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (8 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/framework/core/assets/m_spinner_white.png", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (9 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/applications/m5/views/core/profile/assets/bg_profile_empty.png", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (10 of 12) https://mobile.twitter.com/assets/m5_defer_ssl.css", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (11 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/applications/m5/views/core/timelines/assets/list-gap.png", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (12 of 12) ", source: (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Cached event", source: (0)
I/chromium( 1701): [INFO:CONSOLE(467)] "appcache: cached", source: https://mobile.twitter.com/ (467)
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
This thread hasn't seemed to attract attention, but some new information has lead me to the conclusion that this is really a problem someone should look at.
In a nutshell, I've bought a brand new phone, with a brand new SIM, and installed a fresh CM9. The problem is present in this new phone also. The only common denominator, apart from the mobile carrier (which can be ruled out for reasons discussed in the OP), is CyanogenMod.
Check out the bottom of the OP, under "New Information" in red.
I have the same issues running an AOSP version of Android 4.2 (Paranoid Android 2.99.4) on my Galaxy Nexus. I use the Bell network as well and regularly get SSL errors. Once I switch to wifi I don't receive the errors.
xraycat said:
I have the same issues running an AOSP version of Android 4.2 (Paranoid Android 2.99.4) on my Galaxy Nexus. I use the Bell network as well and regularly get SSL errors. Once I switch to wifi I don't receive the errors.
Click to expand...
Click to collapse
I have talked to one other person (in real life) that has this issue too. For an issue that wouldn't naturally come up in conversation, it's pretty noteworthy that I've found even one other person with this issue (I'm not in a big population center, nor do I talk about phones with random people frequently). Just a passing acquaintance, so not somebody I could grill about the specifics. But he verified that he was running CM, and that the issue only occurred when using his Bell sim, and cell data. It didn't happen when using wifi, nor when on holidays using a foreign cell network.
So, there is something about CM that doesn't behave well with bell in certain situations. It's clear that some SSL sites do in fact work. That might seem like inconsistency, but it's not. The sites that don't work, CONSISTENTLY don't work. Twitter is the easiest example to point to, because it's a mainstream site that everyone recognizes. But there are tons of sites, that fall victim to this same issue when running on the Bell network with CM.
It's very frustrating that nobody has shown any interest in trying to figure this out.
Here's an interesting update:
- I tried an experiment, and setup a VPN to tunnel my mobile data through. I just signed up for one of those $5 per month anonymizer services that gives you a PPTP connection (is that what it's called?). Anyway, the minute I flip it on, everything works. Still using mobile data from Bell, but tunneling it through a VPN. No problems. The minute I turn back OFF the VPN and just use the straight Bell data, back to problems.
- It's not a permanent fix (because it's costing me $5 a month), but it's an easy workaround until someone takes an interest in this issue and helps sort it out. I've done everything I can, and even posted logcats. At this stage, finding a resolution is a few degrees above my comprehension level.
Hello guys !
I'm the owner of a Nexus 4 (on Virgin, which is Bell's network), and while this is not the good forum, I am concerned by this bug.
Running CM10 nightly, I have this SSL error.
It's really a OS problem, as you guys figured it out. Except that this time, the stock rom works perfectly.
Sadly, I'll have to go back to vanilla, since it also breaks some apps.
If you only need a workaround for websites, consider using Firefox. It has it's own SSL implementation, and it works perfectly.
I hear you. Firefox helps, but as you've pointed out THE SSL/BELL FLAW IN CYANOGENMOD ALSO BREAKS APPS! For example, eBay. The eBay app obviously uses the OS SLL stack behind the scenes, because CM9 and CM10, when using Bell, break the eBay app.
Frankly, its really frustrating. Most people can change almost anything about their smartphone setup at will, EXCEPT their carrier (without paying dearly).
There is basically no way to use a custom CM rom on Bell, until someone addresses this. Unfortunately, I am a nobody on this forum, so until someone important notices the problem, I suspect the answer is to use vanilla factory roms, or avoid Bell (if you have that option)
Sad
Sent from my SGH-I757M using xda app-developers app
I'm starting to think that this is "easily" fixable.
I just installed an AOKP rom over my CM10 without erasing my settings and the SSL bug was STILL here. Once I wiped /data, the SSL bug was gone. So it's not really a CM codebase bug, as in a fautly lib, but some of it's settings that's broken. I'll investigate more since I have access to working/non working roms and get back to you guys.
EDIT : Ok, so I removed both the Proxy and it's port (they BOTH need to be undefined) from the pda.bell.ca APN and saved the changes. I can now access everything.
Too bad I had to sacrifice all of my music/pictures/app/settings for this, but heh. I hope it works for you ! Someone needs to report this to the CM team.
Dream_Team said:
I'm starting to think that this is "easily" fixable.
I just installed an AOKP rom over my CM10 without erasing my settings and the SSL bug was STILL here. Once I wiped /data, the SSL bug was gone. So it's not really a CM codebase bug, as in a fautly lib, but some of it's settings that's broken. I'll investigate more since I have access to working/non working roms and get back to you guys.
EDIT : Ok, so I removed both the Proxy and it's port (they BOTH need to be undefined) from the pda.bell.ca APN and saved the changes. I can now access everything.
Too bad I had to sacrifice all of my music/pictures/app/settings for this, but heh. I hope it works for you ! Someone needs to report this to the CM team.
Click to expand...
Click to collapse
You, sir, have solved the problem.
I can confirm that on a previously "SSL-bug-ridden" CM9 rom, simply un-setting the Proxy, and the Port, has resolved the issue completely!
Brilliant!
rhd-android said:
You, sir, have solved the problem.
I can confirm that on a previously "SSL-bug-ridden" CM9 rom, simply un-setting the Proxy, and the Port, has resolved the issue completely!
Brilliant!
Click to expand...
Click to collapse
Here's an annoying side-effect.
If you disable the proxy entry in the APN settings, you can't have LTE anymore
more of the same
same issue on chinese made generic MTK6589 based "Star S7589" phone.
SSL error 107 errors.
from "about phone" page:
Model number: v89_jbl1a698
Android Version: 4.2.1
Baseband Version: MOLY.WR8.W1248.MD.WG.MP.V6.P4, 22013/04/12 17:49
Kernel Version: 3.4.5 [email protected] #1 Mon Apr 22 11:15:49 CST 2013
Build number: v89_jbl1a698_20130422
After seeing this error, I installed Kurt Huwig's SSL Verify from the app store:
url to play store -> play.google.com/store/apps/details?id=de.huwig.sslverify&hl=en
Here is the screenshot (aborted because every last site returned "certificate mismatch"):
url to screenshot -> dumpt.com/img/viewer.php?file=s1tppuca9avpxtxqg50p.jpg
This is the 2nd phone from this vendor. 1st one wouldnt stay connected to the tower so I never had a chance to encounter this issue.
I am quite concerned about the possibility of these certificate chain errors reflecting intentional preloaded MITM capability.
I'm no newb to tech, security, or electronics, but my understanding of the CA chain is far from that of a developer. But one of the more paranoid of my friends, with equal or greater astuteness in the field of network security, had previously suggested that a lot of chinese phones come with pre-installed kernel vulnerabilities where certain syscalls run natively as root.
So needless to say, I'm posting this here in hopes that someone could offer an explanation for the output of SSL Verify that reflects a harmless, unintentional, and perhaps ubiquitous flaw in certain codebases (as has been suggested above) as opposed to, my worst fear, an imminent threat to whatever percentage of the android devices have this vulnerability.
EDIT:
I just tried creating a new APN (even though I am an AT&T customer the APN is [email protected]) with only the most minimal of parameters (both proxy fields blank etc.) when compared to the default which is presumably supplied by the tower/provider.
But regardless of whether this solves the SSL error 107 issue, running SSL Verify still shows the same list of certificates/signatures as mismatched as in the screenshot.
However I note, when watching the program run, that it is not ALL the domains that SSL verify checks - but it is at least half of them. If anyone has a rational explanation for this - or knows of another app I could install to attempt to verify the output - please let me know.
rhd-android said:
Here's an annoying side-effect.
If you disable the proxy entry in the APN settings, you can't have LTE anymore
Click to expand...
Click to collapse
I just tested it and I'm good to go on LTE. Maybe check your ROM's modem to make sure they included the right bands for your model? I know I had to flash over an AT&T modem configuration on a ROM that said it worked flawlessly with the Canadian models.
I was having the same issue and the APN edit fixed it. Good work OP!
A fun quirk I had before was my longer texts being split 160 character bites when the phone should have been using the newer long SMS (which is a type of MSS lol). I worked on that for months. SIM was the issue and it didn't even know its own phone number lol. I finally got a replacement SIM this week after being dicked around for months.
Now if someone can just get SMS delivery reports working, all would be well in the world...
rhd-android said:
You, sir, have solved the problem.
I can confirm that on a previously "SSL-bug-ridden" CM9 rom, simply un-setting the Proxy, and the Port, has resolved the issue completely!
Brilliant!
Click to expand...
Click to collapse
Recently loaded CM 10.1 on my Galaxy S3 (i747M) on Bell. Came across this issue and this thread helped me out.
Thanks to all.
Ed
Well,
Erasing Proxy and port saving and rebooting did not solve the problem for me.
Bell I747 running CM10.2 d2att (android 4.3.1)
Chrome beta 33.0.1750.70
After rebooting the phone, values in Proxy and Port come back to their old values.
My SSL problem happens when I try to do a search from the address bar directly. It loads a blank page, I hit refresh and then the SSL error is displayed.
When you do a search in chrome, it does it via h t t p s : / / ...
My Mobile network settings at a glance:
Network mode: GSM/WCDMA/LTE
Roaming mode: home only
CDMA subscription: NV
Access point name: pda.bell.ca
Proxy is getting its old value again and again: web.wireless.bell.ca
Port: 80
APN type: default, *
Bearer: unspecified
EDIT:
Changing "bearer" setting to LTE crashed the phone after I turned off the display and then back on again. Force rebooted (Power+Vol Down), crashed on reboot once, then came back to life and now it works normally. I don't have the SSL error anymore...
Go figure.
This thread fixed my Ssl issues. Cm11, Galaxy s4, on Bell.
Deleted port/proxy, also set bearer to lte (just incase).
Works flawless now. Signed up to xda to say thanks.
Dream_Team said:
I'm starting to think that this is "easily" fixable.
Ok, so I removed both the Proxy and it's port (they BOTH need to be undefined) from the pda.bell.ca APN and saved the changes. I can now access everything.
Click to expand...
Click to collapse
Thank you so much for figuring this out! It was bugging me on CM11 on my Nexus 4 and I thought I was just going to have to live with it!
Thank you, thank you, thank you, THANK YOU! Been trying to figure this out for 6 months, since I got Bell...
I'm having this issue on a Nexus 6, stock OS, APN has no proxy or port set, by default. The odd thing is that this worked when I got the phone and in the last couple of weeks, stopped working.
On the Bell network with HTC One M8 on Sense 6 and Android 5.0.1 and couldn't go to certain sites due to SSL error connection and recently also an app.
Removing Proxy value (web.wireless.bell.ca) and Port 80 fixed it for me so far! Thanks!
Remove Proxy and Port from your access point
I don't think that there is a problem in CM codebase. Try removing the Port and Proxy from your mobile access point
I was flashing a JB 4.1.2 ROM several days ago when I noticed that my Desire S doesn't connect to my home WiFi network. As I played with the router settings before that and I didn't have the time to troubleshoot it at that time, I ignored the incident. Next day, I saw that I'm not able to connect to my work WiFi network either...then I've started to wonder what happened.
The long story short, is that I frequently flash several ROMs that are all CM10 derivates: CM10 builds from nk111, Andromadus ROM by Flinny, Paranoid by djpbx (current ROM). I usually flash every new release/build and test it to see if I encounter bugs/issues. Now I am not able to connect to any WiFi with ANY ROM...I don't remember the exact moment from which this happened but since then, I've tried with ROMs on which WiFi worked before like IceColdSandwich ported from Lord ClockaN's ROM, several CM10 builds (newer or older), even with Sense based ROMs (I've tried Fallout and Sabsa Prime). With or without full wipe, doesn't make any difference.
On all I got the same thing: WiFi "see"the surrounding networks but doesn't connect...it's not even say "Authenticating" or "Acquiring IP address". I've tried all the settings in Advanced TAB (WiFi frequency band, WiFi region), I tried with different security options (WEP, WPA, WPA2), I tried with hidden network as well as with visible (SSID is transmitted), I even tried with open network. No success at all. Network is saved but that's all. On hidden networks It says network is not in range, on visible ones is not connecting at all.
I've tried to change radio...I've used the last one (20.4801.30.0822U_3822.10.08.04), I've flashed also the one I was using before and which DID WORK (20.48.30.0822U_3822.09.08.20)...nothing.
I've tried with or without a SIM (I read on a thread that it could influence)
I was hoping to solve it but it seems I was not able to do it. Don't know if it's something hardware related either, but since I can see the visible WiFi networks, at least the scanning part is working. Just that it does not connect. And it was working before, at least with some of the ROMs I've flashed
Now I end up with a Desire S without WiFi. Everything else works: BT, sensors, mobile data and so on. I don;t understand what happened, anyone that can give me clues or what else to check, please let me know. Phone is out of warranty and I exclude the "send it to repair center"" option. I'll do that only as last resort and when I'm going to buy a new phone.
NOTE: To avoid extra questions: I am S-Off, current radio 20.48.30.0822U_3822.09.08.20. I've also posted the problem initailly in Andromadus thread and attached a logcat HERE
I have the same problem with my desire s. BT and WIFI don't have mac adres id.
I am not sure it this much related, but I had plenty of such siituations while porting the Wireless driver into my kernel.
It was a permmission issiue (when certain files were created with certain permission another ramdisk with another permissions was not able to start the WiFi.) Usually a full wipe should fix this. Do not restore any wifi data with Titanium. Use 4EXT recovery if you are still on CWM
Once I managed to fix this by starting WiFi hotspot (on Sense 4 ROM) then stop it and start WiFi. Hope this helps
I've gone through the obvious (for me at least) things. I didn't post here without trying them first. Full wipe, gone through initial setup wizard, then first thing added a WiFi network... Nothing restored with TB or anything else, nothing installed, just flashed the ROM + GAPPS + aGPS patch then setup manually everything. When I've flashed Sabsa Prime I've even setup WiFi dirrectly from the initial setup wizard when it was asking how do I connect to internet. Still nothing
Later edit: I've tried to setup a WiFi access point from mobile (WiFi tethering). The access point is created but not visible to any device. It seems like the "emitting" part is not working, only the "reception" is ok.
Code:
[COLOR="Red"]15:25:47.265 Error hostapd 4245 Configuration file: /data/misc/wifi/hostapd.conf
15:25:47.812 Debug Tethering 1670 sendTetherStateChangedBroadcast 1, 0, 0
15:25:47.920 Warning hostapd 4245 wlan0: Could not connect to kernel driver
15:25:47.920 Error hostapd 4245 Using interface wlan0 with hwaddr d4:20:6d:be:66:76 and ssid 'RapierAP'[/COLOR]
15:25:47.920 Debug CommandListener 1431 Setting iface cfg
15:25:47.920 Debug CommandListener 1431 Trying to bring up wlan0
15:25:47.920 Debug Tethering 1670 Tethering wlan0
15:25:47.920 Debug Tethering 1670 InitialState.processMessage what=2
15:25:47.920 Debug Tethering 1670 sendTetherStateChangedBroadcast 0, 0, 0
15:25:47.920 Debug Tethering 1670 Tethered wlan0
15:25:47.920 Debug Tethering 1670 sendTetherStateChangedBroadcast 0, 1, 0
15:25:47.920 Debug Tethering 1670 MasterInitialState.processMessage what=1
15:25:48.030 Debug TetherController 1431 Setting IP forward enable = 1
15:25:48.030 Debug TetherController 1431 Starting tethering services
15:25:48.030 Debug TetherController 1431 Tethering services running
15:25:48.030 Info dnsmasq 4247 started, version 2.51 cachesize 150
15:25:48.030 Info dnsmasq 4247 compile time options: no-IPv6 GNU-getopt no-DBus no-I18N DHCP no-scripts no-TFTP
15:25:48.030 Warning dnsmasq 4247 warning: no upstream servers configured
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.48.2 -- 192.168.48.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.47.2 -- 192.168.47.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.46.2 -- 192.168.46.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.45.2 -- 192.168.45.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.44.2 -- 192.168.44.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.43.2 -- 192.168.43.254, lease time 1h
15:25:48.031 Info dnsmasq 4247 DHCP, IP range 192.168.42.2 -- 192.168.42.254, lease time 1h
15:25:48.031 Info dnsmasq 4247 read /etc/hosts - 1 addresses
When starting WiFi, I get the following:
Code:
[COLOR="Red"]15:32:47.517 Error WifiHW 1670 Unable to open connection to supplicant on "wlan0": No such file or directory[/COLOR]
15:32:48.171 Verbose SCREEBL 2762 --> ROTATION_0
15:32:48.171 Verbose SCREEBL 2762 --> Orientation IN BOUNDS: 5.0 < 5.00065256449902 < 90.0
15:32:49.596 Debug Tethering 1670 sendTetherStateChangedBroadcast 1, 0, 0
15:32:49.703 Debug Beautiful Widgets 4120000 WIFI_STATE_CHANGED_ACTION
15:32:49.810 Error WifiConfigStore 1670 configuration found for missing network, ignored
It seems a problem with the wlan0 which is not found...
Rapier said:
I've gone through the obvious (for me at least) things. I didn't post here without trying them first. Full wipe, gone through initial setup wizard, then first thing added a WiFi network... Nothing restored with TB or anything else, nothing installed, just flashed the ROM + GAPPS + aGPS patch then setup manually everything. When I've flashed Sabsa Prime I've even setup WiFi dirrectly from the initial setup wizard when it was asking how do I connect to internet. Still nothing
Click to expand...
Click to collapse
I know that you are here from quite some time and into this things and has no intention to offend you. Have you tried a backup and format of the SDcard? I saw this as a solution in one of the official ICS threads.
And what is the logcat saying when you enable WiFi?
Sent from my HTC Desire S
amidabuddha said:
I know that you are here from quite some time and into this things and has no intention to offend you. Have you tried a backup and format of the SDcard? I saw this as a solution in one of the official ICS threads.
And what is the logcat saying when you enable WiFi?
Sent from my HTC Desire S
Click to expand...
Click to collapse
No, no, please, no offence taken. Sorry if it sounded this way. But as you said, I'm here for some time and learned alot (thanks to this wonderful community) and I just wanted to say that I've tried through the "normal" ways. The logcat is as you see in my previous post (last code quote). There are only some rows because the rest are related to other things....
I've taken another logcat while starting up WiFi and then scan. Attached
I'll also try to format sdcard. This indeed is something I didn't try yet (I thought is not related). Wouldn't be the same thing if I just take out the card completely? For the test purpose I don't care what files are there and if some apps won''t work
Rapier said:
No, no, please, no offence taken. Sorry if it sounded this way. But as you said, I'm here for some time and learned alot (thanks to this wonderful community) and I just wanted to say that I've tried through the "normal" ways. The logcat is as you see in my previous post (last code quote). There are only some rows because the rest are related to other things....
I've taken another logcat while starting up WiFi and then scan. Attached
I'll also try to format sdcard. This indeed is something I didn't try yet (I thought is not related). Wouldn't be the same thing if I just take out the card completely? For the test purpose I don't care what files are there and if some apps won''t work
Click to expand...
Click to collapse
From your first logcat:
E/WifiHW ( 1674): Unable to open connection to supplicant on "/data/system/wpa_supplicant/wlan0": No such file or directory
and you have noticed the other one yourself:
Error WifiHW 1670 Unable to open connection to supplicant on "wlan0": No such file or directory
It seems like a permission issue to me not a hardware fault. LIke I mentioned the same happened to me several times (WiFi works, sees the networks but refuses to connect) What is strange that usually a data wipe/clean install solves this.
Actually I think yours is not seeing the networks (scanning):
"configuration found for missing network, ignored"
Not sure is this possible but your /data partition seems not wiped properly. Can you make a factory reset on your current rom?
Hi I see you are posting again "from over the air"
Have you solved it or using another device?
Sent from my HTC Desire S
amidabuddha said:
Hi I see you are posting again "from over the air"
Have you solved it or using another device?
Sent from my HTC Desire S
Click to expand...
Click to collapse
I wish...unfortunately not . I have mobile data (3G/HSDPA) with 1.5 GB traffic and 7.2 Mbps speed. It's enough for browsing the forum, even to download ROMs and updates.
Now I've noticed that not only WiFi is not workind...BT is not working as well. Cannot connect to my car kit and it was working before with almost all the ROMs.Since I first noticed the WiFi problem, I didn't try BT so I think the problem came in the same moment for both. I realy hope that is not something hardware related and it can be fixed. But I just don't know what else to check/do. I wanted to buy an One S but I didn't receive an answer from my carrier yet.
Rapier said:
I wish...unfortunately not . I have mobile data (3G/HSDPA) with 1.5 GB traffic and 7.2 Mbps speed. It's enough for browsing the forum, even to download ROMs and updates.
Now I've noticed that not only WiFi is not workind...BT is not working as well. Cannot connect to my car kit and it was working before with almost all the ROMs.Since I first noticed the WiFi problem, I didn't try BT so I think the problem came in the same moment for both. I realy hope that is not something hardware related and it can be fixed. But I just don't know what else to check/do. I wanted to buy an One S but I didn't receive an answer from my carrier yet.
Click to expand...
Click to collapse
Maybe trying the latest firmware (from the thread that keeps your recovery and hboot). This is the last resort before going for hardware check I suppose...
Sent from my HTC Desire S