If you've been programming for a while, modifying software isn't as scary and intimidating as you'd think.
For exmple, I had wpa_supplicant always crap out at a few coffee shops here in LA. It tried to associate but didn't wait long enough.
I ran it with the "-v" option and saw a line that said something like:
"Waiting 5 seconds".
I downloaded the source code and searched for that message:
grep -r Waiting * | grep second
I got 5 results or so. I opened up the code and I saw a line like this, right above the debug message.
timeout = 5000;
I added a 0 (making it 50 seconds) and saved the file. I ran ./configure && make and killed /usr/bin/wpa_supplicant, then used my copy and like magic, it started working. Go me!
I think any average non-wizard programmer could have probably done the same. I didn't have to know all any big-picture detail of wpa_supplicant's design nor did I have to know the 802.11[anything] protocol. No need to do packet dissection or anything like that.
I looked at the screen, I grepped for where the problem was and I added a 0. Fixed.
It took all of 20 minutes or so. A lot less time then the productivity I had already lost by putting up with the issue in the first place. [1]
Those kinds of experiences are the kind that make me stick with linux.
I have an identical problem with the same networks on my s3. I'm guessing it's because of the same thing. But my stock install of the developer-unfriendly OS has made the barrier to doing the same process much much higher.
I had a different, but also easily solvable problem on a MBP once in 2012. I tried the same process. But the man pages were half a page long and dated 10 years ago. The developer documentation was non-existent, the source code was inaccessible, and everyone that was experiencing the problem were unsophisticated users who recommended things like "going to the mac store".
Basically, I was stuck with the problem. I would have had to have been in my top form hacking zone to even find out what and where to mod; and then I'd have to write assembly to fix it; using tricks to maintain byte alignment, function pointers, all that noise.
After a few experiences like that I realized the machine in my hands was a sophisticated consumer appliance.
That's nice. But what I really wanted was a "feasibly reprogrammable" computer.
---
[1] Here's another example: I had an idea for a way to switch application windows where you type in string matches of the window names, all these weird UI ideas... The problem was I couldn't program in X - I had no idea how to do that.
Good thing is that I didn't need to. Because of the openness of the system, I was able to execute my idea with a perl script; calling programs to move around and manipulate windows.
The existing tools gave me enough control, power, and information, in order to execute this sophisticated idea; and all without having to learn xlib (which I intend to do one day). It's become part of my must-have list for my long-term environments. Here's the link https://github.com/kristopolous/alttab . I still don't know exactly how to create an x window.
I'm convinced that although initially daunting, the "here's the blueprints" philosophy of linux actually makes sophisticated ideas simpler to execute, however counter-intuitive that sounds.