htc – doncho.net

DHCP nightmares at Kamelija hotel

Posted on 8/17/20118/17/2011 by Doncho

It’s your first hours after arriving at a (questionable) quality 2* hotel. You look around a bit scared, but at least there’s hope in you: there’s (some) free wireless Internet access in (some) designated areas around the bar.

You see happy people using it and also your friend’s phone (HTC Desire S) is doing more than fine. You think: now it’s the right time to go and complain (or brag, depending on your state) that I’m finally on vacation!

Alas…

When you try to connect with your Samsung Galaxy Tab 7, you see that it finds correctly your wireless network, authenticates without any problem, but hangs on “Acquiring IP address…” state. And it never finishes connecting.

You think “well, it’s because the wireless router is quite busy, I’ll wait”. You keep waiting for some time, and retry. And you get the same. Then you restart your tablet, hoping that it’ll fix the issue. It doesn’t.

Shit!

You now think “Yes, but I have my top-notch Samsung Galaxy S II phone, which will save the day! You try the same with you phone and… you get the same result. The phone “performs” (if that can be named “performance”) the same like the tablet, hanging at “Acquiring IP address…” message, and giving up after some time. You even discover (and that’s for another anti-Samsung rant!) that your phone after restarts allows itself to auto-enable your roaming data access, so it can check for its shitty Samsung updates. Bad, bad, BAD! It’s good I captured that on time and completely disabled mobile data access (they made it sane enough not to auto-enable that as well)!

And then you start getting desperate. Internet abstinence starts building up and you no longer enjoy your time here!

Luckily, you have also your notebook. You pull it out, and it works like a charm. Since the beginning. All great and smooth!

You think “well, at least my PC is OK”, but you’re not one of the people, who get comfortable with such compromise. After all, your Foursquare mayorship on this hotel depends on the ability of your Android devices to get some bits from this damn wireless router (otherwise, your overpriced roaming internet fees will enslave you for ages). Plus, you use you mobile devices more often than your notebook and they (logically) have more battery juice for you!

So you start looking for solutions.

Firstly, you scream to all your Facebook and Twitter friends, hoping that someone will help.

Secondly (until you wait for the help), you go to XDA Developers. You build up your best search query and dig. Then you dig more. Then you dig even more, until you find this forum post archive. Inside there you read that:

It’s an existing issue with the DHCP client of (some) devices. Obviously, Samsung’s devices you have are part of the problem;
And also that if you delete “/data/misc/dhcp/dhcp_list” from your device, you might get it working.

However, both your devices are not rooted and obviously the forum post is too old, because even if they were, you cannot find such file, residing at this place. Not to speak that this is “too much of a Linux way of solving things”.

Although you’ve no problem resolving things “like in Linux”, you prefer to make it in a saner way. That’s why you kept reading, until you discover WiFi Static: the soluiton of Android DHCP issues. This great application allows you to specify static IP addresses for given wireless networks, already in your wireless network list.

Why this works?

The problem, as it manifests itself, is with the fact that your device (or your router, since it could be a router issue too, and I think that’s what is in this case) cannot get (or give) an IP address correctly. Your authentication and MAC-address-level communication works, but you can’t get to TCP/IP, since you can’t get the precious address (sorry, my TCP/IP guru friends, that’s how a developer explains TCP/IP ). By default you’ve no way to specify “fixed IP address” in Android, and you’re screwed!

This app fixes that deadly case. Once you add the setting for the given Access Point, after you connect to this access point, the “Acquiring IP address…” is skipped or cancelled and the parameters, which you specify, are set instead. This simply means that if you set the parameters correctly, it works. If, however, you specify the parameters incorrectly, you can get screwed even worse . But we all hope that once you decide to mangle with such things, you know what you’re doing. Not “Linux way” of resolving things, but still requires some advanced user magic there.

The router at the hotel had standard “192.168.1.xx” setup, which means:

IP Address is any address you luckily guess (I user 192.168.1.111-192.168.1.114, since I saw that the router gives 192.168.1.50 and above for the “legal” devices that can get it)
Gateway is, of course, your router at 192.168.1.1
Network mask is the default 255.255.255.0
DNS1 is your gateway 192.168.1.1, and for DNS 2 I set the Google DNS server at 8.8.8.8

Conclusion!

My friends at Facebook did not fail me. They pointed to the same solution, just at the same time when I was reading about it in XDA Developers. Which made me feel great, because first my friends care for my pain and second, because it proved that Facebook can be of some help sometimes .
Thank you all!
The same problem manifests itself on the following devices:
1. My friend’s Windows 7 notebook. She could not connect unless I set her up with static IP configuration (and reminded her to tell me to remove that setting at the end of our holiday).
2. My both Android devices (fixed with WiFi Static already).
3. My wife’s HTC 7 Trophy Windows Phone 7 phone. Unfortunately, this is the only device which I could not fix and I doubt someone would. Microsoft decided to cut our arms in this direction, wisely knowing that no one can configure a router that stupidly, so their mighty OS would not work with it. Wrong!

My final conclusion is that the router at this hotel sucks! Like most of the things here, it’s not configured correctly (or it just sucks as a device) and its DHCP server works quite selectively. I do not know how many other people have the same problem, but my egoistic nature pushes my hopes high. The more people have the issue, more bandwidth will be free for my holiday needs .

Photo (cc) ETC@USC

Samsung/Google Nexus S Battery and Processor Drain Issue

Posted on 2/20/20112/20/2011 by Doncho

This turned out to be very long post, go here if you just care for the summary, not the details!

Recently, I obtained my new (company) phone, Google Nexus S. I was very excited, because all reviews, statistics, etc. showed that it must be great, full with newest OS and functionalities device. I got the phone from DeliveryShop, who delivered it to me directly from USA’s BestBuy shops.

The first days I was quite happy pal, I had great, new toy to play with and I had not seen any issues so far. I loaded the phone with many apps, and it was behaving more than satisfactory. Plus, the device is very slick, with nice black, curved design. Very, very nice looking.

After few days with the phone I noticed the first issue: my contacts suddently became very slow to search through. It was taking literally 5-10 seconds after I type the name to get the first (not so narrow) results, and another 5-10 seconds to see actually what I was looking for. It seemed I was not alone: the same issue “My nexus S runs out of battery real fast and slows down on contact search” you can read at the Google Mobile forums (and more than once, actually). I was very astonished why this happens, I was also quite irritated. Come on, they’ve got to be kidding me to wait for more than 10 seconds for search! And on a phone, coming from the considered to be top SEARCH company in the world!

Two days later, however, I had more issues to worry about! My phone battery was draining like crazy. Imagine this scenario: I unplug my phone at 98-100% at 07:30, then I travel to work. When I sit on my desk at 08:15 (45 min later), my battery is at 88-90%. I.e., 10% for 45 minutes. Isn’t that just great?

The contacts issue was bad, but at leats bearable (to a degree). This second thing, however, seemed ridiculous! 4 hours battery live for top-notch 2011 model phone is just a big no-no! And I mean – BIG no-no!

The only thing I could research during the week was the phone’s battery report statistics. I saw that the app, which was draining the battery, was… “Android OS”. Great, isn’t it? And the phone tools so far (the system built-in tool and Processor Monitor Widget) did not give me any more information past that. And just “Android OS” using processor at 100% was not good and detailed enough information to me. I needed to know what’s exactly there, but I had no time to research the issue during the week (I noticed the problem Tuesday).
Additionally (and of course), the phone was getting quite warm. It was good, if I needed ellectrical pillow, but since this was just a phone, it was not good at all. The device was getting very warm just above the “Google(tm)” sign, where the camera was placed.

Three days later, however, my irritation was beyound any imagination. I had to constantly seek power source when I was not on a go. And even then, the phone seemed not to be able to charge well via USB: the battery drain was bigger than the USB charge current in most of the cases, so while connected to USB, the phone just… discharged itself slower! But still discharged! During these two days I ended my working day one time with 8% charge, and another time with just 5% charge. No-no!

So I decided that I have no other choice but to start researching the issue. I could not find better analytics app at that time, so Friday afternoon I just did factory reset of my device, paired it to brand new Google account, dedicated to the phone, and installed the minimum set of applications I needed.

Apart from that, I also installed one of the recommended analysis tools: OSMonitor seemed quite good choice. After I installed it, it showed (on the factory reset phone) that the processor usage is normal. OSMonitor also supported notification icon with the current processor usage, similar to the Windows applications Process Explorer or Task Manager. Which was also good, because just with the power button and lighting my screen I could check if the processor is being drained.

After Friday reset all seemed OK, until… this morning (Sunday morning). I woke up just to find out that the processor is again at 100%, my contacts are slow than hell, the phone is sluggish (what you’d expect from computer with 100% idle time going to some app?) and the battery is being graciously drained. This time I was furious! However, this time I also had the right tool installed!

OSMonitor showed that the processor is being busy with the “init” process. If you’re curious what this process is, Wikipeia has very good article about the “init” process. XDA-Developers confirmed my opinion that by no means the “init” process should constantly be at 90-100% processor usage, so I had my main suspect!

Although I had the suspect, it seemed invulnerable. Killing the process immediately brought it back (which is normal for the *nix architecture), again at 90-100%, hungrier for power and battery than ever. Reboot of the device, however, seemed to resolve the issue. Further digging in the XDA forums showed me that some users actually used this technique to “resolve” their problem, other users just returned the device to BestBuy.

The “resolution” did not work for me, neither did the BestBuy return (although I’m almost sure that if I insist, DeliveryShop would assist me with the return and getting new device). But I did not want that, so I continued my search.

My searches immediately pointed me to the Google Code Issue 13130: The process “/ INIT” uses between 70% to 98% CPU. Although having its root from HTC Legend Froyo devices (Nexus S is with Gingerbread), the issue seemed the same like what I was experiencing. In the discusion there people suggested to turn on USB Debugging option (found at Settings => Applications => Development). Somehow this option mitigated the problem (at least to the major amount of people complaining). My option was not switched on, so I did switch it on.

During my searches I also found information that “Google are aware of this issue, but we’re still waiting for the patch”. Well, daaah! I hope they’re fast enough.

I also found one quite interesting speculation about the possible root cause of the issue: in (archived) Google Nexus One Support Forum they’re connecting the init processor usage with pending alarms. I.e., if you have pending alarm set (which I did not had Friday evening and my phone was OK Saturday morning), then the issue does not arise. If you have any pending alarms set (which I had Saturday evening), then you have quite good chance to see the 100% processor usage on the next morning (which I did see this morning, although my alarm was for Monday). So in case the USB Debugging does not resolve my issue, it seems I have still one shot left: to switch to another “alarm application” rather than the included with the phone. But again, this is just a speculation (but still worth checking).

I hope very much that at least one of the workarounds works for me. I will really hate if I have to return my nice Nexus S phone. I really love the phone and I’ll really miss it!

To Summarize

The issue manifestates with Froyo and later based phones (Samsung/Google Nexus S, HTC Legend) with the following symptoms:

The phone discharges its battery very quick, approximately for 4-6 hours in my case
The phone gets significantly hot and stays hot.
The phone contacts search (or any other activity, which counts on idle processor time) is slowed down a lot

The issue has no official hotfix from Google at the present moment (Feb 20th 2011).

You can try one of the following workarounds:

Switch on “USB Debugging”, which you can find at “Settings” => “Applications” => “Development”. This is used for development purposes mainly, but mitigates the issue for most of the people.
If you use standard built-in Clock alarms, you must delete them all (turning off might not work!) and use different alarms software.

At the moment I’m trying the “USB Debugging” option only. Will keep you posted (if I have nerve and time) about how it’s going.

But at the moment I can only say (ironically): “Good job, Google”! It was more than five years since I had to spend almost full day trying to fix an issue, which I should not find at all in a high-class device like your Nexus S! By the way, when my wife saw what I was doing, the only thing she cared for was: “No matter how this turns, you will NOT get back from me my phone, right?” (she’s using my Windows 7 Phone, HTC 7 Trophy).

Image (cc) rakh1