I've had my SGS4G for about a month now and, until recently, it seemed reliable in connecting to wifi networks, both open and WPA2/PSK. Recently, it has started to not be able to connect when "turning on" the wifi, generally through the pull-down from the status bar, or through WiFi Widget. Going to the Settings > Wireless and network > Wi-Fi settings page shows, when it had failed, "Error" under the "Wi-Fi" heading. Generally, if I try to turn it on from there, it will "try" for a while and usually result in "error" again. Sometimes returning to the home screen (Go Launcher, in my case) and trying again will result in a connection, but not consistently.
Stock kernel, firmware, etc.
Looking at the logs, it appears that the kernel module is not loading. For example
Code:
V/WifiProgressStore(18818): WifiProgressStore Created
E/WifiHW ( 2482): return of insmod (args:firmware_path=/system/etc/wifi/bcm4329_sta.bin nvram_path=/system/etc/wifi/nvram_net.txt dhd_watchdog_ms=10 dhd_poll=1) : ret = -1, Invalid argument
E/WifiService( 2482): Failed to load Wi-Fi driver.
as opposed to a "good" load
Code:
I/WifiHW ( 2482): [WIFI] Load Driver
I/WifiHW ( 2482): [WiFi.c] insmod() Start!!
I/WifiHW ( 2482): [WiFi.c] start init_module() Start!!
Removing WiFi Widget (com.rb.wifiwidget) has not resolved the situation.
Is this something that anyone else has run into?
Amusing update -- For a brief while, I was seeing both the WiFi and 4G emblems in the status bar.
I'm trying removing mirin browser, which has a wifi-state listener (who knows why) and will try killing DriveSmart if the problem persists.
jeffsf said:
I've had my SGS4G for about a month now and, until recently, it seemed reliable in connecting to wifi networks, both open and WPA2/PSK. Recently, it has started to not be able to connect when "turning on" the wifi, generally through the pull-down from the status bar, or through WiFi Widget. Going to the Settings > Wireless and network > Wi-Fi settings page shows, when it had failed, "Error" under the "Wi-Fi" heading. Generally, if I try to turn it on from there, it will "try" for a while and usually result in "error" again. Sometimes returning to the home screen (Go Launcher, in my case) and trying again will result in a connection, but not consistently.
Stock kernel, firmware, etc.
Looking at the logs, it appears that the kernel module is not loading. For example
Code:
V/WifiProgressStore(18818): WifiProgressStore Created
E/WifiHW ( 2482): return of insmod (args:firmware_path=/system/etc/wifi/bcm4329_sta.bin nvram_path=/system/etc/wifi/nvram_net.txt dhd_watchdog_ms=10 dhd_poll=1) : ret = -1, Invalid argument
E/WifiService( 2482): Failed to load Wi-Fi driver.
as opposed to a "good" load
Code:
I/WifiHW ( 2482): [WIFI] Load Driver
I/WifiHW ( 2482): [WiFi.c] insmod() Start!!
I/WifiHW ( 2482): [WiFi.c] start init_module() Start!!
Removing WiFi Widget (com.rb.wifiwidget) has not resolved the situation.
Is this something that anyone else has run into?
Amusing update -- For a brief while, I was seeing both the WiFi and 4G emblems in the status bar.
I'm trying removing mirin browser, which has a wifi-state listener (who knows why) and will try killing DriveSmart if the problem persists.
Click to expand...
Click to collapse
this happens to me all the time, i see 4g and wifi on and supposedly connected. I think we are going to need a patch from samsung to fix it. I love this phone but wifi on this thing is totally ridiculous
Ok I think I have found the cause of this problem. Everytime when my RAM runs low the Wifi have trouble turning on. Especially when I have less than 50MB Ram. If I go to Task Manager and free up some RAM the Wifi will start working again.
kirbychiu said:
Ok I think I have found the cause of this problem. Everytime when my RAM runs low the Wifi have trouble turning on. Especially when I have less than 50MB Ram. If I go to Task Manager and free up some RAM the Wifi will start working again.
Click to expand...
Click to collapse
I did the fota fix (frees up about 200 megs of ram) and I still have wifi connectivity issues...
Sent from my DAMN Galaxy 4G¡!
Success100 said:
I did the fota fix (frees up about 200 megs of ram) and I still have wifi connectivity issues...
Sent from my DAMN Galaxy 4G¡!
Click to expand...
Click to collapse
No I mean the RAM, not the internal storage. If you hold the home button and go to task manager, there is a RAM manager and it lets you clear up memory by closing down some apps. Wifi should work after that.
I experience these issues as well.
Galaxy S 4G
It's not an available RAM issue and killing DriveSmart does not resolve this (as suggested in another thread). Removing Mirin Browser and WiFi Widget did not resolve either.
Seems as if the wifi issue is a factor in the wifi not connecting. I just got the wifi error and clearing the ram made the wifi hooked right up
Sent from my DAMN Galaxy 4G¡!
Hello,
Wanted to see if someone found a solution for this?
I'm facing the same problem on a Vibrant, same messages in the logs.
Unrelated to RAM unfortunately.
Just curious, anyone here running JuiceDefender?
Thanks,
Sinan.
Hey all,
I just rooted my galaxy tab 2 10.1 GT-P5110 following the steps that are explained in the [How To] ROOT- Galaxy Tab 2 10.1 [GT-P5113 / 5100 / 5110] thread on this forum. But i noticed that sometimes the sound of the tab not work.
This happens sometimes and i don't know why or how this can happen, when i reboot my device the sound does not come back, but when i use the Bootloader functionallity in the Quickboot app, my sounds will come back after rebooting.
Anyone had the same problem or know a solution to this problem?
Wesley
No Problem on 5113
I rooted my 5113 and left it with the stock TouchWiz ROM for a few weeks and had no audio problems at all. Watched the entire second season of BlackAdder off of Netflix on it.
I have since gone to the CM9 image, and I have yet to have an issue with audio. I can't imagine activating root would cause such a problem, but you never know.
C'pn
no sound...
The strangest is when i does have audio, it will work correctly, the sound is as it suposed to be, but it looks like when my tablet is idle for a bit longer time ( minute of 5 or 10 maybe 15 ), this problem will occur. Is theire a posibillity that a docking station with keyboad has something to do with it?
strange got the exact same problem! also on 4.0.3 and rooted. And i have the keyboard from samsung as well. please tell me if you found a fix!
still not resolved the problem
No i did not found the solution aldready, and i also have the official samsung tab 2 keyboard docking station, i noticed that this problem will only occur when i have my tab in the dockig and its idle for a minute of 10 maybe 15.
Today i did not use my docking for testing, and all day long i just have my sound, so the problem is with the docking station.
Unfortionally i still not have a solution, but i keep looking and if i find one i will post it here..
Tomorrow i will lay my device onto the eclipse debugger, and see where the stacktrace goes if i reproduce this problem.. results i will post here..
Thnx for the tip gonne try that today i also got the original keybpoard im about to contact samsung monday
problem also before root?
i'm just hooked my device up to logcat in eclipse, but now i don't have the problem so just waiting for getting the problem.
yeah i was also doubting of contacting samsung, but i don't know if the problem also was theire before rooting my tab. in my opinion i did not have any trouble before root, but i don't know for sure..
Exact same over here but dont wanne unroot
logcat results
Today i reproduced the problem and logged it with the ecplise tool logcat and here are the results:
The moment i pushed my volume button to increase by 1 to recognize the point in logcat, and then i put it on lock, so you will hear the lock sound ( i did not hear the lock sound) , this where the results:
07-08 23:02:40.378: I/AudioHardwareTinyALSA(98): mMusicVolumeIndex=6
07-08 23:02:40.378: I/AudioHardwareTinyALSA(98): mMusicVolume=0.044668
07-08 23:02:41.480: D/dalvikvm(1125): GC_CONCURRENT freed 399K, 8% free 6722K/7239K, paused 4ms+1ms
07-08 23:02:43.378: W/AudioTrack(190): obtainBuffer timed out (is the CPU pegged?) 0xe9c150 user=00001400, server=00000400
07-08 23:02:44.370: W/PowerManagerService(190): Timer 0x0->0x0|0x0
07-08 23:02:44.378: W/AudioTrack(190): obtainBuffer timed out (is the CPU pegged?) 0xe9c150 user=00001400, server=00000400
07-08 23:02:44.948: E/Watchdog(190): [email protected] 764
07-08 23:02:45.378: W/AudioTrack(190): obtainBuffer timed out (is the CPU pegged?) 0xe9c150 user=00001400, server=00000400
07-08 23:02:46.386: W/AudioTrack(190): obtainBuffer timed out (is the CPU pegged?) 0xe9c150 user=00001400, server=00000400
07-08 23:02:47.386: W/AudioTrack(190): obtainBuffer timed out (is the CPU pegged?) 0xe9c150 user=00001400, server=00000400
07-08 23:02:48.386: W/AudioTrack(190): obtainBuffer timed out (is the CPU pegged?) 0xe9c150 user=00001400, server=00000400
07-08 23:02:49.394: W/AudioTrack(190): obtainBuffer timed out (is the CPU pegged?) 0xe9c150 user=00001400, server=00000400
07-08 23:02:50.394: W/AudioTrack(190): obtainBuffer timed out (is the CPU pegged?) 0xe9c150 user=00001400, server=00000400
07-08 23:02:51.394: W/AudioTrack(190): obtainBuffer timed out (is the CPU pegged?) 0xe9c150 user=00001400, server=00000400
07-08 23:02:52.378: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot write stream data: I/O error
07-08 23:02:52.378: W/AudioFlinger(98): write blocked for 9998 msecs, 55 delayed writes, thread 0x63f750
07-08 23:02:52.378: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
07-08 23:02:52.378: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
07-08 23:02:52.378: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
07-08 23:02:52.386: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
--- Here over 100 times the following ---
07-08 23:02:52.386: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
--- And then after that ---
07-08 23:02:55.370: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
07-08 23:02:55.386: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
07-08 23:02:55.402: D/AudioHardwareTinyALSA(98): Entering AudioStreamOutALSA standby mode
07-08 23:02:55.402: I/AudioHardwareTinyALSA(98): Close mHandle:6badf0
07-08 23:02:59.995: E/AlarmManagerService(190): android_server_AlarmManagerService_set to type=3, 73549.975000000
07-08 23:03:00.003: D/KeyguardUpdateMonitor(190): received broadcast android.intent.action.TIME_TICK
07-08 23:03:00.003: D/KeyguardUpdateMonitor(190): handleTimeUpdate
07-08 23:03:00.003: V/AlarmManager(190): ClockReceiver onReceive() ACTION_TIME_TICK
07-08 23:03:00.042: D/ClockWidget(190): Current time: 23:03
When playing a video also the video is lagging, and this is the result of playing the video:
07-08 23:12:44.214: V/AwesomePlayer(98): we're late by 374519 us (0.37 secs)
07-08 23:12:44.214: V/AwesomePlayer(98): we're late by 374519 us (0.37 secs) dropping one after 0 frames
07-08 23:12:44.230: V/AwesomePlayer(98): we're late by 346116 us (0.35 secs)
07-08 23:12:44.230: V/AwesomePlayer(98): we're late by 346116 us (0.35 secs) dropping one after 0 frames
07-08 23:12:44.245: V/AwesomePlayer(98): we're late by 316309 us (0.32 secs)
07-08 23:12:44.245: V/AwesomePlayer(98): we're late by 316309 us (0.32 secs) dropping one after 0 frames
07-08 23:12:44.253: V/AwesomePlayer(98): we're late by 285923 us (0.29 secs)
07-08 23:12:44.253: V/AwesomePlayer(98): we're late by 285923 us (0.29 secs) dropping one after 0 frames
07-08 23:12:44.261: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
07-08 23:12:44.261: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
07-08 23:12:44.269: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
07-08 23:12:44.269: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
07-08 23:12:44.269: E/AudioHardwareTinyALSA(98): TinyAudioStreamOut::write() failed: cannot prepare channel: Device or resource busy
Hope someone can see the problem or knows a solution...
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