Geek Taco

Network May Be Monitored By A Third Party (a.k.a. Android KitKat scary warning message part 3)

2015-01-26T09:51:00.000-08:00

I guess people care about this annoying warning message that Android has thrown on us. No other blog post here has generated anywhere near the number of hits that this issue has generated. So, to all of your that have found my blog and read what I have to say, I thank you!

Unfortunately, Google doesn't seem to care about this issue. (Newsflash! Google doesn't care about making certificates easy to use on Android. And, by extension, they don't care to make wireless authentication on Android usable either! I could write volumes on my experiences trying to get things improved. But, I fear that it would inspire depression in anyone that read it.) So, we need to do something to try to GET them to care!

There have been several bugs opened about this problem, and most of those bugs have been closed with various reasons that make no sense. (Which is what I base my claim that they don't care on.) Some of the other people on the Internet that agree with me that this is a problem have continued to open new bugs to continue to push the problem and make Google listen. If you care about this problem, PLEASE go to the Google bug tracker, and at least star the issue. If you have the time, you might consider posting a comment to the bug that outlines why this issue causes you grief, and what changes you would like to see made in order to improve the situation. (If you are only going to complain, do us all a favor and just star the issue. If you want to complain, and offer suggestions on how to improve things, please post a comment!)

I'll even make it easy for you. The URL (with link!) to the current version of the bug is at : https://code.google.com/p/android/issues/detail?id=82036 .

As you make your feelings known, please consider this. There is actual value in having a warning like this, if you are the kind of person that values privacy and is against network operators using man-in-the-middle tactics to monitor what you are doing. And, thanks to stupid legislation here in the US, if you are attending a K-12 school that provides Internet access, you SHOULD care about this very much! US law requires the schools to snoop on students as a condition to continue to receive funding! I'm lazy, so I am not going to track down the exact law that requires this, but I know it is true because of my day job. (Not going to say any more than that because my opinion might get me in trouble.)

Because I would prefer that people being snooped on are given any warning that it could be happening, I am actually in favor of the warning message that was added. However, I have problems with how it was implemented. I think there are a few tweaks that could be made to the implementation that would take this from being a pointlessly scary warning message to a valuable warning message, and an opportunity to educate at least a few people on some of the security issues that are associated with installing new root CA certificates on any device or OS. Also, as I have stated before, I don't like people that complain about a problem without offering solutions!

So, here are my suggestions on how to transform the annoying mess that is the "scary certificate warning message" in to something useful and significantly less annoying :

Don't show the message (ever) if the certificate is used with 802.1X on a Wi-Fi connection -- Starting with Android 4.3, the "Credential Store" (a.k.a. Certificate store, or key store) has been split in to two parts. One part holds the certificates that will be used for authentication on Wi-Fi networks. The other part holds certificates that are used for VPN connections, web site connections, and everything else. Since you *HAVE* to install a certificate in order to securely use a Wi-Fi connection, showing this warning message is pointless. The other alternative is not to use a certificate to validate the Wi-Fi network, which leaves you WIDE open to anyone doing a man-in-the-middle. So, the scary warning actually has the potential to make users LESS secure by making them remove the certificates necessary to secure their networks! Google must recognize this on some level, because they don't show the warning if an app uses the Wifi API to install certificates.
When you tap the warning, give useful information -- Right now, when you tap the warning, you are taken to the security settings screen. This is COMPLETELY useless. The user is expecting to be given more information on what this warning is all about. Take them to a screen that explains what the potential issues are with installing a new CA certificate. Explain clearly what the problem is, and don't try to scare them in to submission. Try to give the user enough information to allow them to make a good decision about leaving the certificate installed. Also, provide links to more detailed information so that those that are really curious can really dig in and understand the problems.
Allow users to get rid of the warning -- Right now, you can dismiss the warning, but it comes back any time you install another CA cert, or anytime you reboot your device. This behavior is annoying. Tell me once, let me decide what to do, and then leave me alone! Anything else is a bad user experience. When the user taps the warning to get more information about what it is about, they should also be given two check boxes. One check box should allow them to dismiss the warning just for the current certificate, the other should allow them to block ever showing it again. There really are two types of users where this warning is concerned. There are those that already understand the risks, and those that don't care. The purpose of the warning to to try to get some of those that don't care to actually start to care. But, annoying the crap out of them is only going to make them hate the issue so much that they will never care.

If my three suggestions above were implemented, I suspect most people would no longer hate the warning message as much as they do now. It also gives the power back to the user, which is what I always thought Android was supposed to be about.

I understand that in addition to warning users that they may be causing themselves problems, they are probably also trying to cover their butts should a bunch of users get hacked and complain in the media, or worse, try to sue. However, I really believe that showing the warning once is more than enough for Google to cover their butts on this.

In the unlikely event that someone from Google reads this, and wants me to put my money where my mouth is, I will offer to submit patches to the AOSP project to implement all of the things above. HOWEVER, given my previous experiences with submitting patches to AOSP, I will be expecting a promise that the code will eventually be included. By "eventually", I mean that someone from Google will be assigned to review my code, and comment on it until the code is in the right state to be fully included in AOSP and eventually the main Android builds. (As an aside, while I have tried not to give out any information on this blog about who I am, I am sure that Google has the ability to look up my e-mail address based on this blog being hosted on Blogger. There is also someone on the Android dev team that knows me, and someone on the Android security team that knows me. So, it should be easy enough to verify that I know what I am talking about, and it should be easy to reach out to me.)

How does this wireless authentication stuff work anyway?

2013-11-27T08:39:00.000-08:00

My last couple of posts have been calling out some of the issues with wireless authentication on Android. But, in my day job I deal with authentication on the most common operating systems you would see in the wild. If you were only to read my blog posts this far, you would probably believe that Android is the worst device for wireless authentication there is. The truth is, every operating system I have come across does something stupid when it comes to wireless authentication.

But, perhaps the worst component of authentication on wireless networks is the complete lack of understanding that most people have of how it works. Now, you can argue that you don't need to know how your engine works in order to drive a car, so you don't really need to know how wireless authentication works in order to use your computer. And, in general, I would agree with you. However, most people would agree with me that knowing more about how their engine works results in an engine that generally works better because those people know what to look for and what types of behaviors can cause them trouble down the line. With wireless authentication, it is also the same thing. However, if you destroy the engine on your car, you will be out a lot of money to fix it or replace the car. If you screw up with your authentication the damage can be far worse, and far more expensive. So, do yourself a favor and learn a bit more about how the authentication on your wireless networks work.

My goal in this blog entry is to try to boil down the authentication process in to plain English, while mapping some of the technical jargon in to something that an average person can understand. As a result, this blog entry will be very long. But, hang in there with me. I think it will be worth it.

We are going to look specifically at user name and password based authentication on networks. This type of authentication is commonly used on enterprise wireless networks. However, it can also be used on wired networks. In fact, the method of authentication used in these networks was designed originally to be used on wired networks. It was adapted to work with wireless networks, and that is where it seems to have found the most success. This standard is called IEEE 802.1X. Some people may now be yelling at their screen, "Nuh uh! WPA-Enterprise or WPA2-Enterprise is used on wireless networks, not this 802.1X stuff!" Those people are both right and wrong at the same time. The WPA specifications outline how to use the encryption keys that are generated during an authentication with 802.1X. So, we will be focusing on 802.1X, and leaving the encryption key stuff for another time.

There are two ways that an authentication starts. One is that the network recognizes that you have connected to it and sends a request to start the authentication. The other is the client machine (i.e. your laptop or phone) sends a message to the network requesting that it start the authentication process. Both methods result in the network sending an identity request to the client station. The station responds to this request with a message that contains some form of identification. Because of the way that 802.1X has evolved, this identification is often referred to as the "outer identity" or "anonymous identity". This terminology is technically questionable, but seems to be what the industry has settled on. Probably because the "proper" terminology would just be confusing to anyone that doesn't understand how the various authentication methods works. So, we will use the "outer identity" or "anonymous identity" to reference this through the rest of this blog post.

Following this identity request, the network will send a challenge message to start the authentication. If you have ever configured authentication for a wireless network, and seen the choices such as (EAP-)PEAP, (EAP-)TTLS, (EAP-)TLS, this is where those settings come in to play. The challenge message that the network sends includes an identifier that tells the client what type of authentication the network wants to use. If the client is configured to allow that type of authentication, the process proceeds. If not, then the client will respond to the network asking for a different type of authentication. If the network allows the type of authentication the client requests then it sends another challenge, this time identifying the authentication method requested by the client.

At this point, the details of the methods used for authentication diverge wildly depending on which authentication system you use. But, the basic ideas are all the same. So, rather than dive in to the details of the various authentication protocols, we will discuss what the goals of the authentication are, and then work backwards.

The network, the client, and the user each have specific goals when they enter the authentication. Those goals are :

The networks wants to make sure the client is someone that is allowed to use the network.
The client wants to make sure that it doesn't provide its credentials to anyone other than the networks that it believes it can trust.
The user just wants to get on the network, everything else be damned.

So basically, the client and the network want to make sure that both the network and the user are protected. But, as usual, the user is the weak link as they will probably do just about anything to gain access to the network. (Facebook statuses won't update themselves!) This is one of the biggest failures in the design of the various authentication protocols. For methods such as PEAP or TTLS, the user has the ability to gut the security of the connection as an easy way of gaining access to the network.

So, if we ignore the desires of the user and focus on the security aspects of the authentication, how do the goals of the network and the client get met?

The first step is for the network to identify itself to the client. Currently, this is done using a word that strikes terror in to most network administrators. "Certificates". Certificates really aren't as scary as most admins think they are, but that is a topic for another blog entry. For the purposes of this discussion, the network provides a certificate to the client that the client can run some checks on to verify that the network is who it claims to be. (Side note : There are a lot of potential security issues with certificates and this type of authentication. But, that is beyond the scope of this post.) If the client decides it doesn't trust the certificate it will either send a message to the network indicating it doesn't like it, or simply disconnect from the network. Assuming it does trust the certificate, various pieces of information are used to generate cartographic keys that allow all of the future messages to be encrypted when they cross the network. This layer of encryption is usually referred to as the "inner tunnel" or sometimes just "the tunnel".

At this point, if the client believes it can trust the network, it will fulfill the desires of the network by proving it should be allowed access to the network. This is usually done by using a second authentication method "inside the tunnel". This portion of the authentication is known in most documentation as "phase 2" or "the inner phase". At this point of the authentication, the client sends the user name and password back to the server using the encryption keys that were generated by the certificate exchange. It is believed that the encryption set up by the certificate exchange is pretty secure, since it is basically the same type of encryption that is used when you purchase something from a secure web site.

Taking a quick side trip back to the beginning of the authentication, it should now be more clear why the initial identity the network requests is called the "outer identity". However, it isn't any more clear why it might be called the "anonymous identity". The reason it can be called that is because the specifications for PEAP and TTLS explicitly state that the first identity request can be answered with an identity of "anonymous" because the users actual user name will be passed to the network using encryption later in the process. The idea is that by returning "anonymous" for the first identity it makes it a little harder for a bad guy to use that identity to target a specific user, since the first identity is sent over the network with no encryption. (Side note : The first identity isn't always sent unencrypted. There are situations where it is encrypted, but the working assumption in the standards is that it is unencrypted.)

Once the user name and password are sent to the network, the network can decide if it wants to allow the client to access the network. If the client is allowed, then the network sends a success message and opens the network up to be used. If the client is not allowed, then the network sends a failure message and blocks the client from using the network.

While I don't want to get in to many of the security aspects of this type of authentication, I do want to point out the weakest link. There is an assumption that the client will validate the certificate the server provides to it. There are a lot of places that can go wrong, but by far the biggest one is the user disabling the checking of that certificate at all. Sadly, some devices like the Nook tablets and Windows RT both default to not checking the certificate, or in the case of the Nook doesn't even allow the user to configure checking the certificate! (Note : I have not looked at the latest Nooks, so it is possible this issue has been resolved.) If the client doesn't verify the certificate, then the client will send the user name and password to any device that pretends to be the wireless network the user wants to connect to. Depending on the authentication method used, this could mean that the password is sent to the bad guy with no encryption, or only lightly hashed.

Hopefully someone finds this post useful. 802.1X authentication can quickly go from something that seems simple enough to a wildly complex set of decisions with potentially huge negative consequences. In the coming months, I plan to go in to more of a "deep dive" on the different authentication methods and what the known risks are with each of those methods.

Scary Warning Message on KitKat Part 2

2013-11-26T15:43:00.000-08:00

It always amazes me which posts of mine tend to generate the most traffic. Not that my blog gets a ton of traffic, but once in a while I get spikes of traffic to a specific post and it surprises me a little. My previous post on KitKat seems to be one of those that has caused a bit of a spike. So, I figured a follow up might be interesting.

A couple of hours ago, a coworker sent me a link to Android issue 62076. Gotta say, I was quite surprised to see a link to my blog as supporting evidence! I was equally surprised to see that the bug was marked "Works as Intended" and closed. I read through the statements on how it is intended to work, and came to the conclusion that if it does indeed work that way, this may not be as big a deal as I thought. But, what was being claimed didn't seem to match up with my experience using KitKat.

For those who don't want to sift through the bug chatter, here is a snip of the response from one of the Android team members :

The "User" portion of the trusted credential store is non-system CA certificates that have been installed and are trusted by the browser and other things that use the system Trusted Certificate Store. This warning is about protecting the user of the device.

Note that EAP-TLS and other Wi-Fi modes do not need to install a CA certificate to the Trusted Certificate Store. If you include your CA certificate in a PKCS#12 bundle when installing the credentials and select "Wi-Fi" as the destination for those credentials, you will not get this warning. You can also create a program that adds Wi-Fi credentials and configurations programmatically using the new WifiEnterpriseConfig API (see http://developer.android.com/reference/android/net/wifi/WifiEnterpriseConfig.html).

Asking for exceptions does not make sense. There is a process for getting a CA into the trusted list of browsers and operating systems. Please see http://www.mozilla.org/projects/security/certs/policy/ for an example of the process that needs to be followed.

This all seems pretty reasonable, although arguing that you can write an app to install certificates in a way that doesn't cause scary messages seems to be a bit of a stretch for most people. But, lets run with the claim for the PKCS#12 bundle for installing the certificates for a second.

Lets start with a little test. First, go download a root CA certificate from a known CA provider. You might need to search around a bit to find one, or you can just use the GeoTrust certificate that I will be using as I run through this test. I used the first certificate on the list, which is the "Equifax Secure Certificate Authority" certificate. Next, lets convert that certificate to a PKCS#12 bundle so that we can attempt to install it. You can either try to figure out the magical incantations to do it using OpenSSL, or you could just hop over to the SSL Shopper.com converter that I will be using.

Whoops. You mean we have to have a private key to create the bundle that we need to install a root CA in a way that doesn't trigger that scary warning message?! Awww, c'mon!

A little bit of searching will quickly turn up that a PKCS#12 bundle is intended to store a user certificate and any supporting CA certificates it may need. Further, even if you could get a PKCS#12 file with just the CA certificates in it, the code in the Android certificate installer would prevent you from using it. (I have spent FAR too much time digging around in that code. So you may have to trust me on this one.)

Okay, so lets assume for a second that we are using an EAP-TLS network, and so we can create a PKCS#12 bundle that contains a user certificate and private key. According to the statement from the bug, we should be able to do this, and as long as we select the "Wi-Fi" store, we should be good to go. As I happened to have a small home grown CA set up on a Linux box, I tried this method. After going through the install, I still saw the scary icon in the shade. But, how could that be? If the bug was closed because it works as intended, and someone with an @android.com e-mail address says the way it is intended to work shouldn't be showing that scary icon, we must have done something wrong. Did I maybe forget to select "Wi-Fi" for the target store? So, I decided to try again. The first thing I would do is go an clear the "Credential Store" by going to Settings->Security->Clear Credentials. Then, I tried it again, and again got the icon for the scary warning. But this time, I made extra sure that I had selected the "Wi-Fi" store like the bug resolution said to. Interesting...

While poking around with KitKat, I remembered coming across another location that I could use to install certificates. If you go to Settings->WiFi, select the menu button at the bottom and select "Advanced" there is another option in that menu to install certificates. But, before we do that, we need to clear out the certificates we had already installed. So, we go to Settings->Security->Clear Credentials, but the option to clear the credentials isn't available. Does this mean that the certificates weren't installed? If you tap on "Trusted Credentials" and then select the "User" tab, you would find that the certificates you had installed are actually listed. So, either the "Clear Credentials" option has a bug that prevents it from being used when a user has installed certificates to the "Wi-Fi" store, or the certificates are installed someplace other than the "normal" user key store. The response to the bug indicated they were installed elsewhere, so lets assume that is the case. (A quick aside. They are actually stored in the same place as they always were, but they are flagged with a different user ID. So, it could easily be argued that we are dealing with a bug. Exactly what the bug is would depend on your view of how things should work, but the fact that historically using "Clear Credentials" has cleared all of the certificates that were installed on the "User" tab would seem to indicate that the same should continue to be true.)

Okay, so the only way to get rid of them appears to be to tap each certificate listed, scroll down and tap the "Remove" button. Fair enough, lets do that. Now, we are ready to install certificates using the installed option located in the advanced section of the WiFi settings. Doing so acts almost the same as installing them through the security menu. The only difference is that you are not given the option to install to the "Wi-Fi" store. So, I guess we have to assume that it is going there by default when you install this way. (Another aside, testing this on the emulator shows that it does go in to the "Wi-Fi store".)

But, look at that, the scary warning is showing up again!

Well crap. Now what? Lets try the other option outlined. Let's write our own code. But first, lets take a look at this bug. Uh oh. Looks like that isn't an option either. And I won't even bother to point out that the API doesn't allow for certificate chaining. So, even if it DID work, most people would be outta luck using it anyway.

So there you have it. This is not a bug. It works as intended. Which means that you have *NO* way to access an authenticated wireless network without seeing a scary warning that someone might be monitoring your traffic.

But, before I go, let me relate a story that happened to me a few years ago that, while tangentially related seems like it makes a good warning. Several years ago, I was on a conference call with a large mobile phone provider from the UK, and higher-ups at a phone manufacturer that had significant market share at the time. I'm leaving out names because I suspect neither party would be overly happy to be identified publicly. During this call, the mobile phone provider was asking the manufacturer for APIs to support a product they wanted to deploy. No matter how they asked, or how they threatened, the manufacturer kept telling the provider that they didn't need those APIs because the product they wanted to use would be obsoleted by something they were working on. After getting off the call, I talked to my boss (who was also on the call) and said, "Ignoring what your customers want seems to be a good way to kill a company." In the years since that call, the manufacturer ignored more of what its customers wanted, and its market share has declined to a point that is shameful. It doesn't matter how big your company is, or how your market share is today, if you ignore what your customers want, you will eventually die.

Since there seems to be some interest in how the wireless authentication all fits together on Android, I plan to post additional information here. If you want to know far more about the certificate internals of Android than any reasonable person would, you might want to check back.

Android KitKat : Network may be monitored by an unknown third party

2013-11-06T07:40:00.003-08:00

Update 1/26/2015 - Google has refused to take this issue seriously. They have closed several bugs posted on the Android bug tracker. Fortunately, there are some other people out there that agree that the current implementation is broken. Unfortunately, Google doesn't seem to think that it is worth fixing. Since I know a lot of people find this page while looking for information on this annoying warning, I would encourage you to go to the current bug on the Android bug tracker, and star it to show Google that you want this resolved! Perhaps if enough of us star it, Google will start to pay attention. You can find the current open bug here.

Let me start by making the disclaimer that these observations are based on an AOSP build of Android KitKat on a Galaxy Nexus. (My Nexus 5 isn't due for two more days.) However, things like this that exist in AOSP tend to also exist in the release builds.

Along with all of the great new features in KitKat, Google has introduced what is probably the WORST security hole possible. A ham-fisted implementation of certificate pinning.

Certificate pinning itself is a good idea. It verifies that when you visit a web site, it provides you with the same certificate every time. In general, certificates shouldn't be changing on web sites, and if one does you should be made aware of it.

So, how could certificate pinning be a security hole then? By creating a situation where a harmless certificate creates a scary, and unnecessary, warning message. When you install any certificate in to the key store, you get a warning icon in the bar at the top of the screen. Pulling down the shade presents the following screen :

Let's consider the average user at this point. Given the revelations about all of the snooping by various governments, it seems that a warning like this would make uninformed users very concerned. (And, lets face it, there are very few informed users when it comes to 802.1X on Android.) But, okay, maybe I am freaking out over nothing. What happens when we tap the warning?

Hmm... Maybe not. So, the assumption that an uninformed user is to draw based on this is that having any form of third party "trusted credential" installed means that a 3rd party will probably be monitoring my traffic.

I'm going to skip over the obvious irony here that something from Google is warning me that a 3rd party might be monitoring the web sites I visit, and reading my e-mail. (If the irony is lost on you, you may want to do some research.)

Google seems to be trying to argue that the only safe type of certificate is one that comes pre-installed on your device. Which is a downright silly argument no matter how you slice it. But, lets go ahead and let that one slide. Being the security minded individual that I am, I make sure that all of my network connections are as secure as possible. So, I make the (probably bad) assumption that purchasing a certificate for my RADIUS server from a public CA will provide me what I need in order to have a secure wireless network.

Once I get the network setup, I try to connect my Android device to the network. Now, being that we have paid even a little attention to the security issues around wireless networks, we know that we need to validate the server certificate in order to have a secure connection. No problem, we purchased from a public CA, so we will just select that in the configuration settings. But, you can't. The pre-installed certificates on Android can't be used with 802.1X authentication. Okay, no problem. I'll just install the CA certificate on my device and then use that. Oh, what is this scary message?

Now, those of us that understand the meaning of this message will just dismiss it. But, let's assume that you aren't a techno savvy individual that has enough time to spend learning about security. This warning is going to freak you out! If this conversation hasn't happened on a message board yet, it will soon :

"Hey, I got the upgrade to KitKat, and it is great! But, now I get this warning saying that someone is monitoring my network connection! How do I make that go away!? I don't want someone monitoring my network connection!"

"Getting rid of that warning is easy. Go to Settings->Security->Clear credentials. After that, the warning will go away."

"Thanks! The warning is gone. But now I can't connect to my wifi network! HELP!"

"Not a problem. Go in to the configuration for your wifi network and change the 'CA certificate' setting to '(undefined)'. Problem solved!"

"Perfect! That solved my problem! Thanks!"

And somehow Google either didn't consider this case, or they really want to decrease the security of wireless networks.

Anyway, if you happen across this post while looking for how to make this scary looking warning go away, and you use a secure wifi network, please just swipe the warning out of the shade. It is really nothing to worry about. (I'll do a follow-up post in the next week or so about how authentication on wifi works and why you should care.)

Edit 11/26/2013 : A coworker pointed out that my blog post was referenced in a bug posted to the Android bug tracker. The same bug post had a response from someone using an @android.com e-mail address outlining why this issue isn't a problem. I tested their solutions and wrote about it here.

My Insane Arcade System Build (Part 8)

2013-10-13T15:32:00.003-07:00

Dunno how many parts this will get up to, but it will probably be quite a few as I slowly lumber toward the completion of this "little" project.

But, back to the gear. Let's talk joysticks. Since I want everything to light up, the sources I had for sticks was pretty limited. Basically, it looks like Paradise Arcade Shop was pretty much my only choice. This isn't necessarily a bad thing as they send candy when they fill an order!

As you can see, the box was a tad hammered when I got it :

Of course, this was not likely the fault of Paradise, but of the postal system. But, it did make me a tad nervous about how the sticks inside would look.

Fortunately, nothing appeared off when I opened the box :

Inside, there was the previously mentioned candy (top right), and 5 individually wrapped sticks with RGB LED ball tops.

For a better look :

The micro switches in the sticks seem to click pretty loud, which hopefully will be a non-issue once the sticks are nicely mounted inside their wooden control panel box. (Spoiler Alert : They are fine once they are mounted.)

I wired up each of the sticks to an Ultimarc LED controller and a mini-PAC to make sure that they worked. Of the 5 sticks I bought, 4 of them worked perfect. One stick had a burned out red LED, which gave me the opportunity to find out how customer service is with Paradise Arcade.

I sent an e-mail and got a quick response asking if I had used resistors in line with the LEDs to avoid burning them out. According to the documentation for the PACLED64 boards from Ultimarc, there is no need for resistors in line, so I responded letting them know which controller I was using and that the documentation specifically said I didn't need resistors. (I took High School digital electronics, so I knew that resistors were usually used. So I made sure to check the docs.)

After that, I didn't get a response for the better part of the week. In frustration I posted to the Arcade Controls forum asking if anyone had any issues with Paradise in the past. A couple people said that they had, but calling them on the phone solved the problems quickly. (As an aside, most people had not had any issues.) I called and left a message asking for a status update on getting a new set of LEDs for that stick, and within an hour had an e-mail indicating that the LED was being shipped along with an apology for it taking so long to respond. Perhaps they were on vacation or something? Whatever it was, I did post back to the forum that the problem was resolved to my satisfaction, and I would be happy to order from them again. (As I am writing this after the control panel is all put together, I can safely say that I actually did order from them again. More on that in a later post.)

One thing that I thought was really cool about these sticks is the restrictor plate comes built in to them. As you can see in the image below, the plate fits three ways. The default way allows for fully 8-way movement. Flip it one way and the stick becomes a 4-way stick. Flip it the other way, and it appears to become a 2-way stick! (I didn't plan on using a 2-way stick, so I can't comment on how well that works.) As I was shopping for sticks, it seemed that most of them required the restrictor plate be purchased in addition to the stick, so this seemed like a pretty good value.

The sticks themselves seem to be pretty well built. I am FAR from an expert in this area, but they feel like they could easily handle the kind of moderate beating they are likely to get from guests at my house.

So, in short, I would recommend these sticks.

My Insane Arcade System Build (Part 7)

2013-09-21T12:00:00.000-07:00

Among all of the stuff that has shown up, are the light guns. I took a lot of pictures of these because the pictures on the ArcadeGuns.com web site left me with some questions about button layout.

But, lets get to the pictures. The guns showed up in a pretty standard USPS priority mail box. It shipped two day priority from the ArcadeGuns.com folks.

Inside, the guns were wrapped in bubble wrap and surrounded with packing peanuts. As usual, the packing peanuts got everywhere when I opened the box, which was a pain. But, beyond that, everything seemed to be packed snugly in the box.

As you can see, the guns were each wrapped in bubble wrap, as was the IR bar that goes along with them. Because the IR bar will end up going behind the plexi-glass of the cabinet, I saved myself a few bucks and ordered it without the case.

The IR bar itself really doesn't have much to it. It is made up of 6 IR LEDs and a few resistors. One nice feature is that the cable can easily be disconnected from the IR bar. I suspect this will make things a bit easier when it comes time to install this in the cabinet.

The guns themselves are where I had a few questions while looking at the ArcadeGuns.com site. With some digging, I was able to find pictures that lead me to believe that there were two buttons on the guns. One is where the hammer would be on a revolver, the other is in the center of the grip.

I am not sure how much I'll like having the button on the grip. It seems like it would be easy to hit. But, I guess it can always be programmed not to do anything. (Or to reload, which would make accidentally hitting it a bonus!)

The mold of the gun is also interesting :

If you look at the Ultimarc web store, you can find the kit to build your own light gun. It is really small. So, obviously most of the casing of the gun is to make it comfortable in your hands. The really interesting piece to me is the section right in front of the trigger. It seems unlikely that piece holds any kind of circuitry in the gun. Perhaps ArcadeGuns.com is thinking of adding a recoil feature in the future? Or, I guess it could also be just to even out the weight of the gun in your hand.

I have not had a chance yet to try the guns out on a game. But, one other thing I was curious about was how the buttons feel. I remember from my younger days, playing "Operation Wolf" on the 8-bit Nintendo with the zapper. The trigger on the zapper was really loud and and made a snapping sound each time you pulled it. This didn't seem like a big deal for games like Duck Hunt where you only pulled the trigger once in a while, but on games like Operation Wolf, where you pull the trigger rapidly, it was really noisy, and felt as though you were going to break the trigger mechanism in the gun! Fortunately, these guns are nothing like that.

Each of the switches on this gun seem to be fairly soft. They make a rubberized "squishing/clicking" sound when you press them. Very similar to the buttons on remote unlock systems for cars, but probably a little softer. Overall, I expect they will be pretty quiet when in use. And, while I am unsure how much I am going to like having a trigger that soft, there does seem to be enough forward force on the trigger so that you could easily tell when you have pulled the trigger fully. Also, while the trigger looks rather large, it doesn't seem to need to be pulled back very far before you hear the clicking of the switch inside. I am guessing that for rapid fire games like Operation Wolf, these guns will be comfortable, and not feel like they are going to break like the old NES zapper did.

Finally, as you can probably tell from the picture above, there is quite a bit of USB cord on these guns. I am very hopeful that there is enough that I can string it through the cabinet and get to the USB ports on the PC inside. But, I won't know that until the cabinet is complete, which is probably still a couple of months away.

My Insane Arcade System Build (Part 6)

2013-09-20T12:00:00.000-07:00

Boy, oh boy! Orders have been working their way to my house! Probably enough for a few more posts!

Lets start with a few simple things. I don't have panels that make up the control panel from North Coast yet. Those will probably be here in the next week or so. However, I figured it is never too early to start looking at things to make it pretty. So, while looking around for T-molding, I came across t-molding.com. T-molding.com will send you some samples to look at, so I took them up on it and ordered samples of the 5/8" molding to get a feel for how the colors looked. Here is a picture of the samples :

The one on the farthest left looks like an issue with the camera, but it is actually black with a silver stripe. It looks really cool, but I am not sure it will look good on a cabinet that is already black. I'm leaning toward the light blue right now, but have to wait until the first parts of the cabinet show up to be sure.

My order from AllElectronics.com came packed in a pretty typical shipping package from the USPS.

Inside was the goodies that I will need to make the connections to the sticks and buttons. Which basically boils down to quick connect pieces, a few DSub connectors, and some wire. It all came packed in a large plastic bag wrapped with some brown packing paper. When it is unpacked, it looks like this :

I elected to get a wiring that matches the colors used on a standard molex power connector on a computer. This is because the PACLED64s need power and come with a molex connector. It seems it will be easiest to keep the colors all the same.

While not the most exciting stuff, it is all necessary to complete the project. And, since I wanted to document everything involved in it, you get this exciting post! Enjoy!

My Insane Arcade System Build (Part 5)

2013-09-19T16:59:00.000-07:00

We have narrowed down the buttons that we want, but really need to understand how we are going to light them before we make a final decision. It is probably easiest to buy the buttons and the LED controllers from the same place as you would expect that they have been tested to work together. So, since we previously established that we were down to the Groovy Game Gear and Ultimarc buttons, it makes sense to look at the controllers they sell as well.

Groovy Game Gear sells the LED-Wiz32 which can control 32 LEDs. Ultimarc has the PACLED64 that can contol 64 LEDs. If you will recall, we have 43 buttons, plus 5 sticks, and 1 track ball that we need to light. So, we have 49 LEDs total that need to be lit. So, we can order 2 LED-Wiz32s or 1 PACLED64, right?

Not so fast there. The devil is in the details. If you read carefully, you will discover that 1 single color LED uses fewer leads than 1 RGB LED. A single color LED has 2 leads. An RGB LED has 4! In addition, the RGB LED needs one lead for each of the three colors, and one lead for ground. So, we can think of an RGB LED as actually being 3 single color LEDs, which changes the math a bit. We still have 49 physical LEDs, but since we want to be able to control all three colors in the RGB LEDs, we actually need controls for 49*3, or 147 LEDs. This means that we need 5 LED-Wiz32s, or 3 PACLED64 boards to drive all of those colors.

Suddenly, the pricing for getting all of this light looks a bit different. However, there is another factor to consider that is more aesthetic. The PACLED64 requires power in addition to the USB cable, where the LED-Wiz32 seems to pull its power from the USB bus. So, the PACLED64 is going to require some extra wires be extended in to your control panel to light all of the buttons. However, the LED-Wiz32 will either require additional USB cables going in to the control panel, or a powered USB hub to be installed. However, one thing to be aware of with powered USB hubs is most HUBs aren't built to provide maximum power to all of the ports on the hub. So, finding a hub to use with the LED-Wiz32 may well be a guess and check type of proposition.

My decision ultimately came down to cost and difficulty. While I am not jazzed about pulling extra power wires in to the control panel to power the PACLED64, I am even less jazzed about finding a USB hub with enough power in it to feed the LED-Wiz32. Not to mention, both basically require pulling power in to the control panel to run the LEDs. Then, factor in the cost difference between the two, and I elected to go with the PACLED64. However, it is important to note that my decision was based purely on cost. How well either board works is something I don't have the money to compare. So, I am taking a roll of the dice that they both perform similarly.

So, I elected to purchase the LED controller and buttons from Ultimarc. However, there was an issue when I went to order them. I needed 43, but the on-line site claimed they only had 20. So, I shot a quick e-mail over to Andy at Ultimarc to ask when more buttons would be in. Andy responded within 24 hours saying that it was an issue with the web site, and he had plenty in stock. The issue was fixed, and I was able to order.

So, the only other things that I needed to sort out is getting the quick connects and wire ordered. In part 1, I mentioned that I ordered those parts from AllElectronics.com. The order was pretty much a couple spools of wire, a couple hundred quick connects in a couple of sizes to be safe, and some 24 pin D-Sub connectors (both male and female).

The D-Subs probably seem to come out of left field. Why the heck would you need them!? Well, back in part 1 of this effort, I mentioned that I wanted to have the option to wire in a JAMMA harness in the future, so that I could collect the hardware versions of my favorite games. I figure that if I solder all of the wires from the switches in to some D-Sub connectors then I can later wire a JAMMA harness to the opposite gender D-Sub connectors, and I have a quick way to switch between the systems. How well this idea works remains to be seen. However, I figure worst case I end up wasting some time to add some flexibility to the overall project.

My Insane Arcade System Build (Part 4)

2013-09-18T16:34:00.000-07:00

Since I decided to go with the U-HID for the primary control method, it seemed that my best option for a trackball and a spinner was to just order them from Ultimarc. Groovy Game Gear had a much less expensive spinner, which was enticing, but it was unclear how hard it would be to hook to the U-HID, so I decided to pay a bit more and go with the spinner from Ultimarc. The Ultimarc spinner appears to be the same price as the one at Groovy Game Gear until you realize that you need to purchase the spinner cap in addition to the spinner at Ultimarc. Then it becomes more expensive. If you are more confident in your wiring abilities than I am, you can save yourself some money here and order from Groovy Game Gear.

For the trackball, I really liked the idea of not having to deal with a top mount plate. Ultimarc has a track ball kit that doesn't require a top mount kit. However, if you go back and look at the pictures for the Ultimate Quad control panel at North Coast Custom Arcades, you will see that it is clearly cut to be used with the top mount plate. Reading through the various bits of information that I could find, it also became unclear to me if the ball on the Ultimarc U-trak would be too big to fit in the control panel. It was also unclear if using that track ball would be considered "custom" by North Coast, which would add an additional charge to the purchase of the control panel kit. However, after talking to the guys at North Coast, I was told that it was not an additional charge, but to get the panel cut for the U-trak track ball, I needed to specify that I planned to use that track ball in the comments section of the order. (Which is a good reason to know what you are ordering before you do it!) They also told me that the U-trak is what they used in their own builds, so it should work great.

So, we now have the leg work done for all of the controls except the RGB LED buttons. Finding the right buttons ended up taking a lot more time than I had expected. First, I had to try to track down who I could actually order the buttons from, and what kind of buttons are available. Ultimarc, Groovy Game Gear, and Paradise Arcade Shop all had RGB buttons. Ultimarc and Groovy Game Gear also appeared to have controllers to run the LEDs. (Paradise Arcade Shop appeared to sell a controller as well, but it wasn't in stock.) Ultimarc and Groovy Game Gear sold the complete RGB buttons as a kit, while Paradise Arcade Shop sold the buttons and the RGB lights separately. With Paradise Arcade shop, they sell at least two different types of RGB LED inserts. It was unclear to me which inserts went with which buttons. However, a quick e-mail to them asking if a certain button and light worked together resulted in an answer that I had picked the correct light to match with the button.

I quickly discovered that I had too many choices of buttons, for my desired goal. So, I set about trying to narrow down which ones I wanted. Paradise Arcade Shop has a video on their site about lighted buttons that shows the difference in how buttons can look based on where the LED inside them is positioned. This was good information that I had not considered previously. After watching the video, I decided that I wanted buttons that didn't have a significant "hot spot" in the button. Having a hot spot when the button is pushed is probably less of an issue, since it will be under your finger, but having hot spots when the button is not pushed could result in the buttons not looking as good as I would like.

So, how do I figure out how the different buttons look? Fortunately, someone on the Arcade Control Forms had the same question, and did some testing to find out. You can find the post about the different buttons here. As a quick aside, there seems to be a lot more than just how the buttons look that will factor in to how much you like them. As I was researching everything there was a lot of discussion about the different types of switches that were used in the buttons. If you think you are going to be picky about how your buttons respond, I suggest you do some reading on that. For me, I figured I would go with whatever the default is with the buttons and replace the switches later if I don't like them.

After looking at the forum post, I came to the conclusion that I didn't want clear buttons. This shrunk my choices a little bit. However, after looking at the site for Paradise Arcade Shop, I discovered that the non-translucent buttons weren't in stock, which basically brought me down to a decision between the Groovy Game Gear, and the Ultimarc buttons. But, like the controller for the buttons and sticks, it makes sense to understand how we are going to control the LEDs before we make a final decision.

My Insane Aracde System Build (Part 3)

2013-09-17T16:12:00.000-07:00

With the sticks selected and ordered, it was time to move on to the next most easy thing. The light guns. If you search around a lot, you will discover that there are a surprising number of options for light guns out there. Since I plan to use a CRT monitor, I really wanted the classic optical light guns to go along with it. However, it seems that those just aren't that easy to get integrated with a build like this. (Not to say it is impossible, just that it is currently beyond the skills of this newbie.) So, I looked at what was available, did some research, and found a few sets of guns.

At least one set of guns was wireless. While this sounds like it would be cool, the thought of keeping batteries in the darn things just sounds like a pain. And, to keep things as authentic as possible, I really wanted something with a wire hanging, just like it would in the arcade. So, I eventually narrowed myself down to the Arcade Guns light guns, and the AimTrak gun from Ultimarc. From what I could find, the Ultimarc AimTrak guns sound like they work really well. I also liked the option of being able to add a recoil function to them to keep things even more authentic. However, two things kept me from getting the AimTrak guns. 1) They only had the black ones in stock when I tried to order. 2) Adding the recoil functionality requires soldering skills that are probably beyond mine.

After digging in a bit more, I found that the Arcade Guns light guns actually use the AimTrak internals. They also had the red and blue kits in stock, which would more closely match what I remember from my arcade days. On closer look, I also think I like the button positioning on the Arcade Guns units. So, I went ahead and ordered a set of those. I also opted to save myself a few bucks by ordering the IR bar without a case. I plan to install it directly in to my cabinet.

As a quick aside, I spoke to the folks at North Coast Custom Arcades, and was assured that once I get my system all assembled, there will be enough space around the control panel to put the light gun cables through. But, I'll get to the discussions with them in another post.

Ordering the remaining parts ended up becoming an interesting exercise in finding the controller components I wanted, mixed with pricing, and what was available. While asking some questions on the Arcade Controls Forum, I discovered that there are multiple ways to "implement" a joystick in a MAME cabinet. You can wire a stick up to send keyboard codes to your computer, or you can wire it up to look to the machine like a standard USB joystick. It seems to me that the key difference in which method you want to use is based on how you intend to use the sticks, and if they are analog sticks. If the sticks are only going to be used for emulators, then it shouldn't matter which method you use. However, if you are using analog sticks, then key presses won't provide the full sweep of options that you would get from an analog stick. So, the "correct" answer is largely a matter of what hardware you use, and how you plan to use it. For my build, I wanted the maximum possible flexibility. After digging around, I came upon the Ultimarc U-HID controller, which seems to be programmable to allow it to show up as either a joystick, or key presses. However, it is unclear if it would work with an analog joystick, or even how programmable it is. But, knowing that I plan to primarily use emulators, I should be fine with whatever it ends up being able to do.

However, one aspect to consider with the controllers is how many devices and switches you need to control. We know that we have 43 buttons, with one switch each. We also know that we have 5 sticks. Each stick is going to have 4 switches for a total of 20 switches. So, we will have 63 switches plus a track ball and spinner. Since the U-HID only has 50 controls, we will either need 2 of them, or 1 of them and 1 of something else. (As I write this, I realized I only ordered 1! Looks like I need to figure out how to support the remaining 13 switches + track ball and spinner! More on that later, I guess..)

My Insane Aracde System Build (Part 2)

2013-09-16T15:33:00.000-07:00

As with all "simple" projects, this one got out of hand in a hurry. The first thing I needed to do was to figure out all of the things I didn't know I needed to know about. That is always a fun thing. So, with a little Googleing, I tracked down the Arcade Controls Forum. This place is an insane wealth of information about every aspect of arcade game systems you could imagine. Perhaps the worst thing about the forum is that there is SO MUCH information that it can be really hard to track down exactly what you are looking for. However, when I couldn't find what I wanted to know, I found that registering and asking a question in the forum usually netted useful information, with few exceptions.

But, lets start with a quick recap of what we know, and what we need to figure out.

1. The arcade cabinet will be a North Coast Custom Arcade Ultimate Arcade II Cabinet kit.
2. The control panel (where the sticks and buttons are installed) will be North Coast Custom Arcade Ultimate Quad kit. (I chose not to have the pinball buttons added, as the size of the control panel seemed like it would put them too far apart for comfort.)
3. I want RGB lighted sticks, buttons, and trackball.
4. I need some kind of computer to run it all.
5. I want the computer to boot up and be ready to play without needed to use a keyboard or mouse.

Tracking down a computer was pretty easy. I have an old AMD Phenom 1.9 Ghz Quad Core system that badly needed to be upgraded to support my wife's need for the latest versions of PhotoShop. So, I ordered parts for a new system from NewEgg, and decided to convert the old system to be my arcade machine.

With the machine figured out, I needed to get the parts ordered so that I could start to assemble my control panel. After doing some Google searches, and reading through a bunch of posts on the Arcade Controls Forum, I game up with a list of a few places to order parts for the control panel.

Ultimarc - Has quite a good selection of buttons, sticks, trackballs, and light guns. The web site was also reasonably easy to navigate for a newbie like me.
Groovy Game Gear - Also has a good selection of buttons, sticks, and trackballs. The web site was also reasonably easy to navigate for a newbie, but did take a bit more effort as they seemed to have a larger selection than Ultimarc.
Paradise Arcade Shop - Has one of the largest selections of buttons and sticks of all the places I looked. The web site was a bit more difficult to navigate for a newbie. But, once you figure out who the different vendors for sticks and buttons are, it becomes a bit easier to understand the layout.
Arcade Guns - Strangely enough, it is a source for light guns for building arcade systems. With deeper digging, you will find they use the same innards as the Ultimarc guns. However, the button layout, and shells are different. They also don't seem to offer a recoil add-on like Ultimarc does.

Finally, you will need a bunch of wire and quick connects. While some of the shops above offer these things, I found they were a tad cheaper at AllElectronics.com.

But, before I could start going crazy with the credit card, I needed to figure out exactly what parts I wanted to use so I could be sure that the control panel kit fit them all correctly. The easiest thing to do is figure out a list of all of the obvious parts that are needed to assemble the control panel. If you go to the page for the North Cost Custom Arcade Ultimate Quad kit, and scroll down a bit, you can find a template that is to be used to design an overlay for the panel. The overlay graphic is perfect for getting a count of what we need. By my count, we need the following :

43 (total) buttons. 7 for each of the 8-way stick positions, 4 for players 1-4, 4 for coin inputs for the 4 players, and 7 more for the trackball, 4-way sitck, and asteroids buttons.
1 spinner
1 track ball
4 8-way sticks
1 4-way stick
2 light guns (not part of the control panel, but we need them anyway)

Then, of course, we need all of the gear to actually wire up those devices to be used by the computer.

But, lets start with the easy decision. Of all of the places I listed, the only one that had the RGB LED joysticks that I wanted was Paradise Arcade Shop. At Paradise Arcade Shop, they sell complete sticks with the RGB LEDs, along with kits to add RGB LEDs to other sticks. Since I am a newbie to all of this, I opted to go with the Paradise Arcade sticks, rather than buy other sticks and retro fit them with kits. One thing that was really unclear to me is if they offered a 4-way stick, or if I would need to customize one to work. So, I e-mailed them to see what they had to say, while I continued to research 4-way sticks. In my research, I discovered that most 8 way sticks could have a restrictor plate inserted in them that would convert them to a 4-way stick. In addition, I discovered that both 4 way and 8 way sticks only use 4 switches for control. 8 way sticks were just able to hit 2 switches at once, where 4 way sticks couldn't. So, there is not a lot of difference between the two. However, many comments on the Internet indicated that a stick in 8 way mode can cause strange behavior on emulators with a game that is made for a pure 4 way stick. So, I wanted to make sure I had a "pure" 4 way stick for those games.

After more research, and an e-mail response from Paradise Arcade Shop, I found that the 8 way LED sticks actually include the restrictor plate to force the stick to a 4 way, or even a 2 way stick. (Bonus!) So, the decision on which sticks to buy was complete. I ordered 5 of the RGB LED sticks from Paradise Arcade Shop.

My Insane Arcade System Build (Part 1)

2013-09-15T15:29:00.000-07:00

I am a child of the 80s and 90s. When I was young, there was very little in the world better than spending an insane amount of time playing video games. The grocery stores near my house had a hand full of different game systems that I would save my quarters to go play. I had my favorites, but in general I was a huge fan of having a hand full of change and landing in an arcade full of cabinets. The more games the better.

I remember distinctly thinking to myself, "When I am old enough to own a house, the whole basement will be decked out with every game I can get my hands on!" My basement would rival the arcades I grew up with.

Unfortunately, like many childhood dreams, I didn't end up becoming filthy rich enough to own the 10,000+ sq.ft. house I would need to store all of those systems, let alone have enough cash to buy them all. I did, however amass a large collection of home video game systems and games that I plan to have in a prominent place once I finish my basement.

Which brings me to the fun part. I must have talked about my arcade dream enough, that my wife picked up on how much I would love to own a cabinet. When it came time to finish the basement, I started looking in to what it would cost to have one, and promptly told her it was just too much money. She insisted that it was something I get because I have dreamed of it for so long. So, I started looking. While I would love to have a JAMMA cabinet and start to collect boards, I figured I would start with a MAME cabinet that I could easily rewire to support JAMMA boards in the future.

And thus began my hunt for the ultimate home arcade system. The first thing I needed to do was figure out the parameters for the system I wanted. My wife started by telling me what she would require to allow me to display the cabinet in the basement once it was finished :

1. It can't look like a crappy home built system made from parts found at the hardware store. -- While there are lots of folks on the Internet that have the skills to build something that looks great using parts from the hardware store, I know I am not one of them. So, reality dictates that I start to look at what I could buy pre-made.

2. It *HAS* to play light gun games. -- While dating, and even on our honeymoon, my wife and I loved to play games like House of the Dead and Area 51. If she is going to let me build this, she insisted that her favorite games be playable.

Simple enough, right? I figured I would just buy a pre-made system and then tweak it for my own needs. I was aware of the X-Arcade systems, so I figured I would start there. This looked like a nice system, and having tried out the X-Arcade controller at Fry's years ago, it seemed like it would be a great first system. However, the more I thought about it, the more I realized that I wanted a 4 player system. So, I started to look around at other places such as Dream Arcades, and North Coast Custom Arcades.

I loved the North Coast Ultimate Arcade II cabinet with the 4 player controls. Even more, I loved the pictures of that system using the RGB LED lighted buttons and sticks. But, my concern was how hard it was going to be to move a fully assembled system down in to my basement, along with the cost of buying that unit outright. So, I decided to purchase the various parts, and put it together myself. It should be much easier to move individual pieces of the system in to the basement. In addition, I could order the control panel now and start to put it together while I wait for the basement work to be finished. When the basement is nearly done, I can order the main cabinet along with the other large and heavy pieces like the monitor.

Pretty simple, right?

Why all the Google Glass hate?

2013-05-27T20:39:00.001-07:00

I suspect I am opening a can of worms here, and will probably end up getting flamed wildly in the comments telling me that I am stupid or whatever else. However, I can't help but notice that most of the complaints about Google Glass are either based on a completely flawed understanding of what Glass is, and can do, or fears of a surveillance society that already exists in much worse ways.

Let me start by saying, I have Google Glass. But, I also take my privacy really seriously. I don't have a Facebook account and have requested that anyone I know not post pictures of my family to Facebook or any other social networking sites without my approval. I do have a twitter account, but I don't ever use it. I got it so that I could develop some software for a friend that he wanted to use with twitter. I also take the time to go to as many sites like Spokeo as possible and ask them to remove my information. When a store asks me for anything but the money to pay for my purchase my response is "Why?". Finally I am the bane of TSA's existence because I believe that if some stranger playing police officer hasn't touched my junk, the flight will almost certainly have some horrible ending. So, I always opt out. While I am sure there is more I can do to protect my privacy, hopefully you will understand that I take my privacy very seriously.

When Google Glass was originally announced I had some concerns about privacy myself. However, because of the industry I am in, I need to stay on top of the latest technology when it incorporates wireless networks. What I have found in Glass is far less concerning than what I had imagined in my mind. (You'll have to trust me. The technology in your mind is far superior to what currently exists!) So, I would like to address some of the paranoid fantasies that people have about Glass.

I don't want to have a conversation with someone wearing Glass. They could be checking Facebook, or Twitter, or something else and not paying attention to me.

Let me start with the obvious. It doesn't matter if you have Glass or not. If someone would rather be checking Facebook or Twitter while talking to you, you are either boring to talk to or that person isn't worth talking to.

However, this is really a non-issue with Glass for several reasons. First, contrary to what people seem to think, Glass does not provide a heads up display (HUD). Rather, when properly worn the screen is just above your line of sight. To see the screen, you have to look up. If you are really engaged in a conversation with someone, you will notice if they start looking up. But, lets assume for a second that you don't manage to notice that someone is looking up. The second reason it is a non-issue is that the Glass cube above your eye will light up when it is turned on. The amount it lights up allows for someone standing close enough to you to have a conversation will clearly see that you have something up on the screen. In fact, it is light enough that when my sister used my Glass, I was able to see enough of the screen while looking at her to tell her how to navigate!

But, lets go crazy and assume that you have some kind of weird spot blindness that prevents you from seeing the screen and noticing it is on. There are currently two ways to interact with Glass. You can reach up to the side of your head and use the touch pad on the frame, or you can nod your head to wake it up and then speak to it. Again, you will notice if someone is using Glass while talking to them. If you don't, then you should question why you are talking to that person as you aren't engaged with them enough to notice.

But, since Glass is always recording and streaming data to Google, people will always be able to see what I am doing!

Let me ask you this. Can your cell phone record an entire day of video? No? Then, consider that the battery in your cell phone is larger than the entire volume of Glass, even if you include the frames which have not electronics in them! But maybe Glass is using some super secret system that uses less power than a cell phone which allows you to record all day! The specs for Glass are openly available. The hardware in Glass is basically the same as an under-clocked Galaxy Nexus. Don't know about you, but the battery on my Galaxy Nexus lasts about a day when I use it lightly. During heavy usage, like when I was at Google I/O, I am lucky to get half a day. In addition, I tried recording video constantly while at I/O just to see how long it would last. At about 55 minutes, Glass powered down. (I had taken one or two pictures prior to recording, so I would put the actual recording time around 1 hour total on a fully charged battery.)

The fact is that Glass doesn't have the hardware that would be needed to record video all day. And when you consider the weight issues with a pair of glasses, it is unlikely that such a device will exist in the near term. Sure, you could wear a backpack full of batteries that connect to the micro USB port on Glass and probably get more recording done, but would you? In reality, if someone really wants to record constantly, they will use a device that doesn't do anything but record. Why waste battery power on processing other stuff when all you want to do is record video?

Okay, but when Glass is used to take a picture, the picture is uploaded to Google where they can tag my face and determine where I am.

This argument just floors me. My response to it is, "And so does every other device that you have that can take a picture!" But, you argue "Not my camera that isn't Internet connected!" That is true for the automatically uploaded portion. But, lets face it. Most pictures will eventually find their way on line. Plus, even with all of the steps I take trying to keep myself from being tagged in pictures, doing a Google Image Search on my name turns up at least one picture that is of me. (Granted, it is over a decade old, but that is really beside the point.) Your friends will tag you in the pictures, maybe you should start there. Plus, governments and big business already know what you look like. They already know what size your underwear is, what health problems you have, and where you like to get takeout from. Google generally doesn't care where you are, or what you are doing. (Not to mention they already have that information based on the location of your cell phone.) And, given the number of various types of cameras all over our world, there is a pretty good chance that you were recording by someone else at the exact same time. In the world we live in, there is only one place that you can be sure you aren't be recorded. Your home. (And even that may be questionable at times.) When you are in the bathroom you can be somewhat more assured that no one is recording you, but are you sure? There are cases all over the place about people hiding cameras in all kinds of bathrooms around the world.

Thank you! You brought up the bathroom issue. I don't want someone filming my junk while I am using the can or doing something else I don't want people to see!

A few years ago, a friend showed me a video that was recorded, in secret, of a guy playing Guitar Hero at Best Buy, jumping around like a rock star would on stage. This video was recorded on a normal cell phone camera. For videos in the bathroom, you don't have to search very hard to find articles about the early days of cell phone cameras and people taking pictures of other naked people while in a locker room. Yet, today, people go in to locker rooms all the time with a cell phone and it doesn't bother people much. They may keep an eye on that person to make sure they don't do anything that appears to be taking a picture. But, in reality it is easy enough to modify a cell phone so that it doesn't make a sound when taking a picture.

Then, there is this :

http://www.allpredatorcalls.com/i-kam-xtreme-3-0-mega-pixel-video-recording-sunglasses-4-gb-internal-memory-expandable-to-32gb-flat-black-frame-50029/?gclid=CKPvhO61t7cCFStp7AodZGQAUg

Yup, $99 for a set of glasses with a camera built in that you would probably look at and think to yourself "those are ugly" and go on your way. If you search around, I know you can find other similar glasses that are even less obvious that you would never notice. Basically, this problem already exists. The main difference with Glass is that the glasses upload the images to Google, and Google never deletes anything. So, Glass would make it easier to throw someone in jail when they went around using the camera for something it wasn't intended. Further, with the current generation of Glass, it is plainly obvious that someone is wearing it!

But, in addition to this already being easily (and far less expensively) available, my point is that there are societal norms that people will conform to. I have never worn my Glass glasses in to a bathroom outside of my house. *IF* I ever did, you can be sure that I would point them at the ceiling so that they couldn't possibly be recording anything. But, in general, I would leave them with my wife or stuff them in a bag. I realize that not everyone would think of this, but people will eventually catch on after someone makes a comment to them in the bathroom. In short, this is already an existing problem, but not one that people with any common courtesy would run in to.

Okay, but what about creep shots? Guys taking pictures of girls chests (or worse) when they are unaware of it. (Like I saw in the parody video on YouTube.)

First, please refer to the question above. It is already easily done with existing technology in ways that are FAR less obvious. But, I have also overheard conversations where some dude-bro was talking about how he pretended to be texting so that he could get a shot of the cans on some "hottie" across the room. It doesn't matter if the camera is obviously pointed at you, you don't know what someone is doing and will usually not confront them unless they make a mistake that convinces you they are doing something. Cameras are on the back of the phone, taking pictures without someone knowing is a reality in out lives. We deal with it with cell phones, why is Glass any different?

But, I would argue that the real problem here is societal. Why do the dude-bros think this type of behavior is okay in the first place? The deeper issue is that they view women as objects meant to excite them. As a male, I understand that looking at women and assessing their attractiveness is built in to us. We all do it, and I believe it is a primal instinct that we have that was used to make sure the best genes survived in to the future. The question is, what do we do after that? If you don't find yourself thinking, "Gee, I bet she wouldn't be too happy that I just rated her in my mind based on how she looks." then you may want to reconsider how you treat people in general. But, I'll get off my feminist soap box as I could easily go on and on about things like that.

Short version, people need to teach their children that everyone is a person with thoughts and feelings. Objectifying anyone in a way they don't approve of is wrong.

But, the difference is that with Glass nobody would know you were taking a picture or recording video.

This argument is interesting, and when taken at face value doesn't work. There are two ways to take pictures build in to Glass. The first requires that you reach up and press a button on the frames to take the picture. The second is to wake the device up and say, "Okay glass, take a picture". You would notice both of these things just like you would notice someone using a phone to take a picture.

But, there is the hack out there that lets people take pictures of you just by winking. That is more subtle, but I would bet still requires that Glass be awake before it would work. Waking Glass up requires tapping the frame or jerking your head up. Then, there is the issue of strange people winking at you. And finally, see the spy glasses link above. The problem already exists, and while I agree that it is disturbing it really isn't a good reason not to allow Glass to exist. Rather, Google should take this criticism to heart and make a small modification that would make a huge difference. Put a super bright LED on the glasses that is connected to the camera with hardware such that the camera cannot be operated without the LED being on. Most people wouldn't have the expertise to disconnect the LED in such tiny electronics. And of the few that do, most wouldn't waste the time. The remaining tiny percentage is people that have real issues and will do inappropriate things no matter what you try to do to stop them.

Okay, but when people have to use their cell phones to take a picture or video, there is the time needed to pull it out of their pocket before they start recording.

As I have already stated, Glass doesn't record all the time. So, something has to be done to it to wake it up and make it take a picture. So taking a picture with Glass probably isn't much faster than taking it with a cell phone. In fact, there are many phones out there that have a dedicated button for taking pictures. Those devices can probably take a picture FASTER than Glass can.

But, I also noticed something interesting while wandering around downtown San Francisco during the Google I/O 2013. Most of the people walking around already had their phones in their hands. Granted, there were a lot of people playing Ingress, which would account for some of it. But, for the people that looked like they actually lived there, most of them had their phones out. And a good number of those phones were iPhones, which currently can't play Ingress.

If you already have your phone in your hand, the time needed to take a picture usually drops. I would argue that you may be able to take a picture faster using a phone already in your hand than reaching up, waking up Glass, and telling it to take a picture. Add to that, the fact that even after pressing the button there is a noticeable lag before Glass takes the picture, and you may realize that for "OMG this is happening NOW" pictures you are probably still better off with your phone!

Yeah, but I heard that Glass constantly uploads your location when they are on.

Again, another argument that floors me. First, Glass only uploads your location once every 10 minutes. Granted, that is a setting that Google should allow people to turn on and off, but they already have that information anyway. Your cell phone has a GPS in it, and there is nothing that would stop Google from turning it on every 10 minutes and uploading your location. (Who knows, they may already!) Then, there is location data from cell towers and wifi access points. Even without turning on the GPS, you can be triangulated to a very small area for a possible location. Small enough that it doesn't matter if it is pinpoint accurate. They can find you if they want. If you are REALLY concerned about this, you should turn off your phone, never use the Internet, and move out to a cabin in the woods somewhere and have no contact with the outside world.

They already know where you are, and what you are doing. And they have tweaked the laws so that it is perfectly legal. That ship has sailed.

Okay, but what about the ads? I don't want ads popping up throughout my day!

In the current developer specification, showing ads is forbidden. If a developer started to provide unwanted ads with Glass, I think it would sink the whole system. I realize that Google makes most of its money off of advertising. However, I think they also see that people don't want to be bugged by ads all the time.

I honestly believe that Google will continue to keep the "no ads" requirement in their apps. Glass doesn't have a large enough screen to stick a banner add at the bottom where it is out of the way and still have it be readable. So, ads would have to take over the whole screen for some amount of time. Further, if ads popped up randomly throughout the day, early adopters would throw Glass in a drawer and tell people not to buy it. I am honestly not sure how Google intends to make money off of Glass. It is possible that the revenue they get from selling Android apps is enough of an incentive to do the same thing on Glass. But, if Google wants Glass to be successful, they need to make it something people want to use. Annoying ads popping up at random would kill the user experience.

Yeah, but the glasses themselves look really stupid and ugly.

Perhaps one of the silliest comments I have heard. I would agree that most of the time the glasses look silly. I suspect Google agrees and that is why they are working with a sunglasses designer to make the final product look better. However, when Glass is worn with the included sunglasses shades, they really don't look as horrible. I wore them with the sunglasses shade today going through a drive-thru and nobody seemed to care.

Which brings me to perhaps the most important point of that argument. If it were illegal to have bad fashion sense, many of us would already be in jail. Further, if it were up to me to decide what looked good, most "high fashion" would land people in jail. Fortunately, for the entire world, bad fashion choices won't land you in jail, and usually won't have people mocking you. (Unless you are still in High School, or perhaps the fashion industry.)

We can hope that once Glass is released to the public that it looks better. If it doesn't, that may well kill the project.

But Glass doesn't do anything my cell phone can't. And how come Google owns the glasses even after I paid for them?

In general, I agree. Which I consider to be an argument for why people freaking out about Glass is silly. At the same time, I also see why it is a valid argument for not using or having Glass. What this argument fails to take in to consideration is what state Glass is currently in.

There is a reason that existing versions of Glass cost $1500+tax. The same reason accounts for why you are not allowed to resell them. Not surprisingly, that same reason accounts for why the software is rough around the edges and loaning Glass is not allowed. (Even though one of the Glass developers made a comment at I/O about asking someone with Glass if you could try it.) Glass is not a finished product! Google wants to get it in the hands of people that will be excited for the potential sooner rather than later. (Which means developers.) Those developers will experiment with things and create new apps for it. The same developers will give feedback to Google about what is good, and what isn't. And hopefully the final product will be better because of it!

Consider the case of Microsoft and their recently announced Xbox One. Do a search for "Microsoft Durango". You will quickly find out that there are a LOT of developers that had access to the development platform long before it was released. You may even come across an article talking about the "zebra stripes" on the console. The developers needed access to the development kits early on. I am sure they signed agreements preventing them from letting non-developers from seeing the prototype hardware along with giving Microsoft piles of cash while the agreement said that Microsoft obtained ownership of the development kit. In the console industry, the quantity and quality of the launch titles can really help or hurt the adoption of the new hardware. Microsoft wants to get developers working on top quality titles as early as possible so they can be successful. At the same time, they are giving those developers an unfinished product to work with so that they can create those titles. Google is doing the same thing with Glass. The high price is because so few were made, and to keep out people that probably won't contribute to the success of Glass. It was primarily available through a developer conference so that developers would get it, and provide feedback while working on new uses for the technology.

I would almost bet money that once the final version of Glass is announced that Google stops caring if you resell the developer versions. It is just that right now, they want to keep the audience to a group of people that will forgive them for having the software not be polished while hopefully contributing to its success.

Okay, but I don't want Google snooping on me!

The EFF recent put out a report on the privacy policies of various companies. Of Google, Apple, and Microsoft, Google ranked the highest for privacy. Hopefully this means that the snooping they are doing isn't as bad as other companies are. (Source : https://www.eff.org/who-has-your-back-2013 )

But, there is also something that Google has going for it. Glass runs Android! Given the significant number of custom Android ROMs out in the wild, it is reasonable to believe that something similar will happen with Glass. Google also has a history of making their hardware fairly easy to unlock for people that know what they are doing. So, I suspect that if Glass is successful there will be a vibrant custom ROM scene. That scene will probably have at least one "anti-Google" ROM in it that strips out any reporting that Google may have put in. And the best part is, I don't think Google will really care!

Wow. You actually read this far! I am impressed. I would imagine that at this point you are either thinking, "You know, he has a point." Or, you are so pissed off at my obvious lack of understanding of the situation that you could throw your computer out the window. Please feel free to ask questions and make constructive comments in the comments area of this post. If you read this whole thing, hopefully you have come away with the impression that I don't believe that Glass is a perfect product. In addition, if Glass were released today, it would be a huge flop. But, I would love to know what I am missing, that doesn't already exist in the world in an easier and less expensive solution, that makes Glass so scary it should be banned or hated so much?

PPPoE with Zyxel Q1000Z and Cisco 2600 router with CenturyLink DSL

2012-09-04T08:34:00.000-07:00

Comcast's service broke and their customer support was rude one too many times, so I switched to CenturyLink. Being that I am not a "normal" customer by any stretch of the imagination, I wanted to set up something a bit more advanced than a simple NATted connection. Specifically, I wanted to get an IPv6 tunnel to Hurricane Electric while also keeping my corporate VPN connection up and running. (Ideally, get my VPN running on the same box as the tunnel and other services.) I have an old Cisco 2621 kicking around that seems it should be up to the task.

Getting this going was surprisingly difficult. Initially, I had the 2600 plugged in behind Q1000Z with the 2600 running in NAT mode providing access to the networks in my house. I was double NATted because the Q1000Z didn't seem to want to set up static routes in any sane way. Obviously, not an ideal setup.

There are numerous configurations around the net on how to do PPPoE from a Cisco device to a possible non-Cisco remote end. (I say "possible" because CenturyLink doesn't advertise what their back-end network looks like. Not surprising since most people wouldn't understand it anyway.) Most of these configurations look very similar to each other.

The configuration that finally worked for me is this (some important information replaced with Xs, you will have to fill in your own values. Also, the configuration has been edited to remove irrelevant settings.) :

!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname frontdoor-with-v6
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip subnet-zero
!
!
ip name-server X.X.X.X
ip name-server X.X.X.X
ip name-server X.X.X.X
!
ip cef
vpdn enable
!
vpdn-group 1
request-dialin
protocol pppoe
!
interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.0
ip nat inside
no ip mroute-cache
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
speed 100
half-duplex
pppoe enable
pppoe-client dial-pool-number 1
!
interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
encapsulation ppp
ip tcp adjust-mss 1450
no ip mroute-cache
dialer pool 1
dialer-group 1
ppp authentication pap chap callin optional
ppp chap hostname XXXXXXX@qwest.net
ppp chap password 0 XXXXXXXXX
ppp pap sent-username XXXXXXXXXX password 0 XXXXXXXXXXXX
!
ip nat inside source list 1 interface Dialer1 overload
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
ip route 10.1.0.0 255.255.0.0 192.168.0.2
!
access-list 1 permit 10.1.0.0 0.0.255.255
dialer-list 1 protocol ip permit
!
end

Most of this is taken almost verbatim from the numerous example sites. However, when I originally set this up, FastEthernet0/1 was set to auto for both speed and duplex. When the 2600 was set up in NAT mode behind the Q1000Z, the auto mode worked fine. But, once I got the PPPoE session up, I got lots of random drop-outs in my connectivity. Some things worked fine, others would load slowly, and still others just plain wouldn't work. After digging around forever, I found a site that suggested setting the speed and duplex to 100-half instead of auto. There were no obvious signs on a duplex mismatch on the Cisco side of the link, and the Zyxel didn't have any obvious way to look for errors. So, I decided to give it a shot and see what happened.

Strangely enough, it worked. My connectivity was nice and speedy again, and all sites are coming up correctly.

Hopefully this helps someone else that might be struggling to get a similar setup going. Next, for the v6 tunnel and the VPN.

Code coverage with Android and EMMA

2012-07-19T09:52:00.000-07:00

Recently, I have been looking in to tools in Android that would help me improve code quality and find bugs before putting the product out. I picked up a copy of Diego Torres Milano's "Android Application Testing Guide" as a good place to get me started. Since there are a lot of tools out there, and not all of them support Android, it was a useful guide to tools that should be working.

One of the tools I was looking in to is code coverage. Over the years, EMMA has been integrated with the Android build tools, which is supposed to make it easier to use. Unfortunately, if you don't use them just the right way they can end up being a horrid time suck trying to figure out why your instrumented build just isn't working.

For my testing, I was using the latest tools available as of this writing. (That would be ADT 20) Lots of the information available on the Internet is for older versions of tools that don't use the same commands as ADT 20. I also started with the most basic app I could, and set it up so that I had an easy way to intentionally miss some code, or make sure I hit it all. The code looked something like this :

@Override
public void onCreate(Bundle savedInstanceState) {
String appname = "unknown.app";
super.onCreate(savedInstanceState); setContentView(R.layout.activity_main);
}

public void testme() {
System.out.println("This is a test!");
}

A pretty simple "app" that mostly comes out of the Android tools when you create a new project. The "testme()" method is there because it will allow us to explicitly call some code (or not) to let us see that code coverage is really working.

Next, I created a test app using the Android tools and created a new test case. The test case extends ActivityInstrumentationTestCase2, as it will start up the activity we want to test in a state that is easy to use. The test class looked something like this :

public class MyTest extends ActivityInstrumentationTestCase2 {
public MyTest()
{
super(TestActivity.class);
}

public void testCodeCoverage()
{
}

The "TestActivity" referenced in the above code is the name of the Activity that we created earlier. Also, note that our test doesn't actually do anything. For now, this is okay. When the MyTest class is run, ActivityInstrumentationTestCase2 will create the activity, which will result in the onCreate() method being called. So, once we have our code coverage running, we will have a block of code that was covered, and a block that was not.

At this point, we are going to use the command line. We also need to make sure that we have a fairly current version of Apache Ant ready to use. For my tests I was using 1.8.2.

At the command line, we want to convert our apps to use Ant for building. To do this, we need to use the "android" command that is included in the SDK. (On Windows, it is "android.bat") We need to run two commands, one to convert the "TestActivity" app and one to convert the "MyTest" test project. The command will look something like this :

android update project --path /path/to/TestActivityProject --name TestActivityProject --target android-16

The "--name" parameter should be set to whatever you named your project, and "--target" should be set to the API level that you want to test with. The "--path" parameter requires the FULL path name to your project. So, if you are on windows it might be something like "c:\users\foo\workspace\TestActivityProject" I tested with an Android 4.1 VM, so I chose "android-16". The version you use isn't too important, unless you plan to use Ant to make your final builds.

Next, to convert the test project :

android update test-project --main ../TestActivityProject --path /path/to/MyTestProject

The "--main" parameter confused me a bit at first. It should be a relative path from the directory you store "MyTestProject" in, to the path of "TestActivityProject". If you are using Eclipse and putting your code in a workspace, you should normally need to use ../.

Finally, we are ready to build and run our test. Go in to the directory for "TestActivityProject" and run "ant". (If ant isn't in your path, you may need to use a full path to ant instead.)

But, whats this? We get a help screen like the following :

Android Ant Build. Available targets:
help: Displays this help.
clean: Removes output files created by other targets.
The 'all' target can be used to clean dependencies
(tested projects and libraries)at the same time
using: 'ant all clean'
debug: Builds the application and signs it with a debug key.
The 'nodeps' target can be used to only build the
current project and ignore the libraries using:
'ant nodeps debug'
release: Builds the application. The generated apk file must be
signed before it is published.
The 'nodeps' target can be used to only build the
current project and ignore the libraries using:
'ant nodeps release'
instrument:Builds an instrumented package and signs it with a
debug key.
test: Runs the tests. Project must be a test project and
must have been built. Typical usage would be:
ant [emma] debug install test
emma: Transiently enables code coverage for subsequent
targets.
install: Installs the newly build package. Must either be used
in conjunction with a build target (debug/release/
instrument) or with the proper suffix indicating
which package to install (see below).
If the application was previously installed, the
application is reinstalled if the signature matches.
installd: Installs (only) the debug package.
installr: Installs (only) the release package.
installi: Installs (only) the instrumented package.
installt: Installs (only) the test and tested packages (unless
nodeps is used as well.
uninstall: Uninstalls the application from a running emulator or
device. Also uninstall tested package if applicable
unless 'nodeps' is used as well.

This is where I really screwed up and spent a lot of time scratching my head. Since we want to use EMMA, we need an instrumented build, right? So the command that we need is "ant emma instrument install test" to get a build, install it, and run the test in it.

While this seems like the most intuitive answer, you will quickly find out that it doesn't work. Everything will compile and install fine, and we can assume that the resulting apps are instrumented. However, when it gets down to running the test, you will be greeted with something like this :

[echo] Running tests ...
[exec] INSTRUMENTATION_RESULT: shortMsg=java.lang.IllegalAccessError
[exec] INSTRUMENTATION_RESULT: longMsg=java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation [exec] INSTRUMENTATION_CODE: 0

Hmm.. Something didn't work. This is where I spent a ton of time trying different combinations and searching to understand what was going on. Finally, as I was giving up, I noticed a browser page that I had already opened that said for EMMA code coverage, we need to run "ant emma debug install test". I didn't think it would work, but I gave it a shot. Crazy as it is, it DID work! (I literally spent 7 hours trying to figure out what the above error message was all about.)

Once your instrumented build is run, the necessary coverage files will be downloaded, and a coverage.html file will be created in your test project's "bin" directory. Opening that up should show that your onCreate() method ran all of its code, but the testme() method wasn't touched at all. If you go in to the testCodeCoverage() method in the test app, you should be able to add the line "getActivity().testme()" and then run the instrumented build again. This time, you should get 100% code coverage.

Hopefully, this post saves someone out there a significant portion of their time getting started with code coverage!

Trouble in Android Wifi land

2011-10-10T15:21:00.001-07:00

It has been a while since I posted last, but there are some issues with how Android handles the WPA/WPA2-Enterprise modes. Hopefully making these issues a little more public will help get them fixed. (And, before you start throwing things, yes, Google is aware of these issues.)

Let's start with an easy, common issue. Self signed certificates. There are many tutorials on the net about how to configure WPA/WPA2-Enterprise using self signed certificates. I would imagine that for any IT person that is trying to wrap their heads around 802.1X/WPA/WPA2-Enterprise, they are one of the first stops. Hopefully, Android isn't running on their primary test device.

If you attempt to use a self signed certificate on Android, it will usually fail. I have run across the occasional device that doesn't have this problem, but 'stock' Android like that found on the Nexus series generally has this problem.

Not being able to use self signed certificates is annoying, and it leads us nicely in to the next Android annoyance. To paraphrase, "If an Android fails to authenticate, and nobody is watching the logs, did the authentication actually fail?" I think the best answer is, "If I didn't get my network access, then yes, it failed." However, because Android didn't tell you that it failed, you may be sitting there for some time before you realize something is wrong.

Let's jump back to the self signed certificate issue I mentioned above. I like to say that in the event of an error case, the program usually has some idea of what went wrong. It just needs to present that information to the user in a useful way. This case is no different.

Under the hood, Android uses wpa_supplicant to handle authentication 802.11 management and authentication. In the self signed certificate case, wpa_supplicant will produce an error such as this :

TLS: Certificate verification failed, error 18 (self signed certificate)

This error is usually surrounded with a bunch of OpenSSL error codes so many people just "check out" when reading the logs, and don't notice it. On Android, it is a little bit worse. This error message is buried in a log that the average user probably doesn't even know exists. So, how does the user know what went wrong?

In this example, the user figures it out after sitting there for a while and they don't get a connection to the network. But, once they have come to the conclusion that they can't get on the network, what are they supposed to do? Worse, what is the helpdesk call going to sound like? I need you to summon your best red-neck, inbred, hillbilly with buck teeth accent and said, "It's broke". ("It don't work" is another wonderfully helpful description.)

Since most users have a really short attention span, at this point they wander off to complain to anyone they can that the network is broken. When a coworker or friend says, "Yeah, but it works for me." that will change to "Wireless is broken on Android."

The reality is that Android's wireless is NOT broken. Well, maybe not very broken. When the wireless hardware is behaving itself, wpa_supplicant does a fine job of getting you connected. You just have to be running something like CatLog, or have a development environment set up that will let you run "adb logcat". Then, you have to know enough about 802.1X authentications, and certificates to be able to recognize the one log line that tells you everything you need to know about the failure. That should be easy enough. (In case you are missing my sarcasm, consider trying to talk your mom through figuring this out over the phone.)

While I use the self-signed certificate issue as an example of the problem, it is just the tip of the iceberg. Other similar issues, that you won't hear about, include :

The certificate isn't yet valid.
The certificate is no longer valid.
Your authentication failed.
MS-CHAPv2 messages such as 'invalid password', or 'your password has expired'.
And many, MANY others.

Let's assume that you understand these issues, have the tools to figure them out when they happen, and work in a small enough business that the helpdesk can go through this dance with everyone in the company. Out of nowhere, you get slammed with an issue you CAN'T fix!

Here, you will find your next issue. Section F, item 2 basically says that CAs can no longer sign certificates with their root certificate. Or, in other words, all certificates have to be signed by an intermediate CA cert. Now, I understand that Microsoft isn't a standards setting body, so CAs don't have to comply with these rules. However, as Microsoft is still a dominant OS provider, CAs that don't comply won't be allowed in the shipping Microsoft cert store. Based on this, it is pretty reasonable to assume that most CAs will follow these rules.

The problem this creates for Android shows itself when you try to install a chain of certificates on Android. I was unable to find any sane way that worked. Digging in the Android source code seems to indicate that cert chains can be installed using PKCS#12 certificate bundles. However, Android seems to insist that PKCS#12 certificate bundles contain a user cert. In other words, if you are using anything but EAP-TLS, you probably can't use PKCS#12 bundles to get your certificates in the store.

It may seem reasonable that creating a PEM file that has multiple certificates in it would get around this issue. However, if you try that, you are presented with the following dialog :

Note that the dialog indicates that there is only one CA certificate that will be installed. If you complete the installation, and set up a new wireless authentication using this certificate, you will find the connection doesn't work. If you happen to have CatLog, or a development machine around you will see in the logs that the certificate chain failed to validate.

If you can't use self signed certificates, and can only buy certificates that are chained, it starts to become clear that the 802.1X/WPA-Enterprise/WPA2-Enterprise authentication on Android is darn near unusable. You either need to find a CA that is willing to go against Microsoft. Or, you have to choose not to use certificates in your authentications. (Which, is a *BAD* idea!)

I just want to restate that Google has been made aware of these issues. However, it was recent enough that they probably haven't had time to do anything about it, let alone get anything fixed and released. Also, since I get really annoyed with people that like to complain, but don't offer any real solutions, I will be submitting patches to Google that will hopefully start to fix some of these issues. At a minimum, hopefully Google can use my patches as a jumping off point for a good fix.

Color changing rounded rectangles and Android

2011-04-11T10:03:00.000-07:00

I recently came across an interesting problem. I needed to have a rounded rectangle as the background of one of my widgets, but I needed to allow the border color of the rounded rectangle to be set by a configuration setting.

Before the color changing requirement showed up, I was using a 9-patch to create my rounded rectangle. It was simple, and worked quite well. So, after some digging I came to the conclusion that I would need to change the colors in the 9-patch image in order to achieve my goals. I ended up burning a lot of time trying to figure out how to do this. (It isn't as simple as changing the colors in a normal .png file, unfortunately.)

While digging, I came across this post that hinted that I might not need the 9-patch to do what I wanted. But, the documentation for the shape XML is pretty much non-existent. Which made things hard.

A little more digging found an article that linked to this page. This provided me the attributes for the XML that allow me to do what I needed to do. So, I set out to give it a shot. I started with a rounded rectangle with a white background and a black line around the outside. The XML looked like this :

<shape android="http://schemas.android.com/apk/res/android" shape="rectangle">
<solid color="#ffffffff">
<stroke width="2dip" color="#ff000000">
<corners radius="75dip">
</corners></stroke></solid></shape>

When I created the XML file in eclipse, there wasn't an option to create a shape XML file. So, I picked one of the other types, and just deleted what was automatically created, and replaced it with the code above. However, I also needed to move the XML file so that it was in the drawable directory. (If you are like I was, you are thinking, "But an XML file isn't a drawable!" But, you'll just have to trust me.)

This provided me the basic rounded rectangle that I needed. But, changing colors on-the-fly was still an issue. After a bit of digging, I found that using this XML to create a drawable would give me everything I needed to get the job done.

I decided to set the background for the layout that contained everything I was going to use. (Which is why I am using a LinearLayout instead of some other widget. But, any widget that allows a background to be set should work.)

For a test, I changed my onCreate() method to include this code :

workareaLayout = (LinearLayout)findViewById(R.id.rightColumnInner);

GradientDrawable sd = (GradientDrawable)this.getResources().getDrawable(R.drawable.roundrect);
sd.setColor(0xff00ff00);
sd.setStroke(10, 0xffff0000);
workareaLayout.setBackgroundDrawable(sd);

This created a nice rounded rectangle that is suitable for Christmas. (It has a green background with a large red border.)

The sd.setColor() call sets the background color for the rectangle. The color is an ARGB value, so we start with 0xff since we don't want any transparency. The 00ff00 portion indicates that we want to be the brightest green we can have.

The sd.setStroke() call specifies the width of the border line, along with the color. For this example, the width is 10, and the color is bright red, with no transparency. The documentation isn't clear what a width of "10" means. (Is it pixels? Or one of the other measures commonly used in Android development?) But, it appears that it is probably pixels.

And with that, you should have the ability to create all kinds of crazy rounded rectangles. However, keep in mind that this same method should work for other types of shapes that can be created with the shape XML.

Getting ADB to work with the Samsung Tablet

2010-11-11T10:11:00.000-08:00

It is a neat little device, the Samsung Galaxy Tablet. However, as soon as I got one, I wanted to hook it to my computer and run some of my code on it. Easy enough, right? Well, not exactly.

After fighting with it for several hours yesterday, I gave up and called it a day. This morning I posted to the Android developers list looking for help. Then, on a hunch, I installed the Samsung Galaxy S driver pack, and managed to make progress.

I downloaded the driver from here. Make sure that you click on the link that says "Softpedia Secure Download" as there seem to be a lot of ads on the page that try to get you to install other crap.

Once you have the driver downloaded, unzip it someplace. (I threw it on the desktop, because it was easy.) Then, open the control panel, go to System, then Device Manager, and find the SAMSUNG_Android device that should be listed in the "Unknown Devices" section. Right click the device, and select "Update Driver Software...".

Next, select the option to "Browse my computer for driver software", then enter the path to the "USB Drivers" directory you extracted from the download. Make sure that the "Include subfolders" option is checked, and click Next.

At this point, the main USB driver should be found. After waiting a second, you should see a couple of new USB devices show up in the "Unknown Devices" section. One will be a modem interface, the other is the ADB interface that we want to use.

If you follow the same procedure above on these new devices you should be able to get the correct drivers installed. Once all of the drivers are installed, you should be ready to go! Running "adb devices" should show your Samsung tablet.

Fancy List Items in a ListView

2010-10-17T14:04:00.000-07:00

A while ago, I was working on a project where I wanted to be able to have Android show a ListView, with custom entries in the list. In most other languages and toolkits, doing this is a bit of a pain. You have to implement a special painter to pain the list cell in just the right way. Unless you are a pretty die-hard developer for that toolkit you may find yourself horribly confused as to how to handle the situation.

Fortunately, Android made this REALLY easy. If you know how to do a layout for a form, you know almost everything you need to know in order to make a fancy list item.

First, you want to create a small layout that specifies how a single list entry should look. For my purposes, I wanted to have a single line of large text, with smaller text below. I also wanted the large text to be bright white, and the smaller text to be a darker gray color. Finally, the smaller text should be indented on both sides to indicate that it is subordinate to the larger text.

No problem! A basic linear layout will do the job nicely. My final layout looks like this :

<linearlayout android="http://schemas.android.com/apk/res/android" layout_height="wrap_content" layout_width="fill_parent" orientation="vertical">
<textview layout_height="wrap_content" id="@+id/LargeText" text="Large Text" textcolor="@color/white" textsize="25dip" layout_width="fill_parent"></textview>
<textview layout_height="wrap_content" layout_width="fill_parent" layout_marginright="10dip" layout_marginleft="10dip" id="@+id/SmallText" text="Smaller Text" textcolor="#c0c0c0"></textview>
</linearlayout>

Easy enough. Now that we have that, we need to actually write some code that will use it. I find it easiest to create a convenience class that lets me manipulate the list easily. So, I create a class called MultiLineList, that looks something like this :

import java.util.ArrayList;
import java.util.HashMap;

import android.app.Activity;
import android.widget.SimpleAdapter;

public class MultiLineList {

private ArrayList<HashMap<String,String>> list = new ArrayList<HashMap<String,String>>();
private Activity parentActivity;
private SimpleAdapter taskAdapter;

public MultiLineList(Activity parent)
{
parentActivity = parent;

taskAdapter = new SimpleAdapter(parentActivity, list,
R.layout.multi_item_layout, new String[] { "largetext","smalltext" },
new int[] { R.id.LargeText, R.id.SmallText } );
}

public void clear()
{
list.clear();
}

public void addItem(String largeText, String smallText)
{
HashMap<String,String> item = new HashMap<String,String>();
item.put("largetext", largeText);
item.put("smalltext", smallText);
list.add(item);
}

public SimpleAdapter getData()
{
return taskAdapter;
}
}

In the constructor, we create a SimpleAdapter that we use to map our text in to the different rows of the list view we will show the user. "R.layout.multi_item_layout" is the name of the layout we created above. (You may need to change this if you called your layout something else.) The two strings, followed by the two ints give us a mapping in a hash table for how to identify the two different TextEdits that we put in the layout. There is nothing special about only having two items. We could easily have 10 strings and 10 matching ints. What is important is that each string has a corresponding int that maps to a text edit in your layout.

The addItem() method is where the good stuff happens. As part of creating the SimpleAdapter in the constructor, we told it to use the "list" variable to get its data out of. So, the addItem() method allows us to easily put new text in to the list to be used. So, calling addItem("I am big", "I am not") would give us a single entry in the list view that contained the text "I am big" in the large font, and "I am not" in the small font.

Now that we have all of the ground work in place, it is time to put the pieces together. Moving forward, I am going to assume that you have a basic form set up with a list view configured in it. Also, that a ListView variable points to it called "listView". From there, using our fancy list widgets would look something like this :

myList = new MultiLineList(this);
myList.addItem("Large 1", "Small 1");
myList.addItem("Large 2", "Small 2");

listView.setAdapter(myList.getData());

Now, the next time out list view is drawn, it will contain two items in the list. The first one will have "Large 1" in the larger text, and "Small 1" in the smaller text. The second one will contain "Large 2" in the larger text, and "Small 2" in the smaller text.

From this simple example, you should be able to easily expand your list items to contain any just about any widget type you would want. But, I leave that up to you to experiment with.

Its all about the layers..

2010-08-07T14:35:00.000-07:00

For an Android project I am currently working on, I wanted to take an image of the last state of my game board, and overlay another image on it. While this seems like a simple thing it wasn't terribly simple to figure out. (Though, it is surprisingly simple to implement.)

To make this easy, lets assume you have two bitmaps. We will call them bitmap1, and bitmap2. Also to make it easy, we will assume they are stored as drawables in your Eclipse project.

It is also important to note that bitmap2 must have some transparent areas on it. If bitmap2 is completely opaque, you won't see any of bitmap1, and this code will be a waste of effort. (Since you could just draw bitmap2 by itself.)

The first thing we want to do is get our drawables stored in Bitmap objects. These bitmap objects should be called bitmap1 and bitmap2. This is easily done with the following code :


  BitmapDrawable draw1 = (BitmapDrawable)res.getDrawable(R.drawable.bitmap1);
  Bitmap bitmap1 = draw1.getBitmap();

  BitmapDrawable draw2 = (BitmapDrawable)res.getDrawable(R.drawable.bitmap2);
  Bitmap bitmap2 = draw2.getBitmap();

That was easy. Now, we have to figure out how to combine the two. This is where things start to get a little less obvious. After Googling around, I found several different methods that could do it. But, the method I am going to use below seemed the most straightforward to me.

First, the code, then the explanation :



  Bitmap layers = Bitmap.createBitmap(bitmap1.getWidth(), bitmap1.getHeight(), bitmap1.getConfig());
  Canvas c = new Canvas(layers);
  c.drawBitmap(bitmap1, new Matrix(), null);
  c.drawBitmap(bitmap2, new Matrix(), null);

Believe it or not, you now have a merged bitmap in memory. (But how? It looks like all I did was draw on a canvas!?)

Simple, if you look at the Canvas class, you will find that one of the constructors allows you to pass in a Bitmap object. When you do this, anything that is drawn on the canvas is put in to the Bitmap that was passed in. So, in our example above, if we wanted to see the result, we could draw the Bitmap object 'layers' to the screen, and we would have the image of bitmap2 laid over bitmap1.

Or, to look at it another way. If you were working with a SurfaceView, and wanted to draw the bitmaps there, you would create a Canvas object, draw the two bitmaps in order, and pass the Canvas to the SurfaceView where it would be drawn. The code here does the same basic thing. However, instead of having the code drawn immediately on the SurfaceView, you have the output sent to a Bitmap.

But, lets look at some assumptions in this code real quick. When we create the 'layers' Bitmap object, we have to tell the Bitmap object a little bit about the bitmap we want to create. Specifically, we have to tell it what the size of the bitmap is, and what the configuration of the bitmap is. The size is fairly obvious. But, in the sample code above, we are assuming that either the two bitmaps are the same size, or that bitmap2 is smaller than bitmap1. If bitmap1 is actually smaller than bitmap2, then the final bitmap will be the same size as bitmap1, and bitmap2 will be clipped to fit. But what about the configuration? What is that? The configuration is a value that tells the bitmap what kind of data it will be storing. Or, another way to look at it, how big each pixel will be in memory. Without getting in to a bunch of detail, under normal circumstances, you will want to use ARGB_8888.

Why the heck would you ever do this? Well, if you needed a composite image that would be used repeatedly in your program you could either try to draw it in real-time every time it was needed, or draw it once and just reuse the drawing. If the image is more than a few pixels, recreating the overlay each time could be an expensive operation. Caching the result and using that instead can save you a fair bit of processing time that you can use for other cool effects in your program!

The right way to do databases in Android

2010-07-12T19:41:00.000-07:00

Feel free to comment below on what a loser I am. I am sitting in a cabin outside of Yellowstone National Park, writing a blog entry about doing databases on Android. However, I do think I should get a little geek cred as I am posting it from an EDGE connection on T-Mobile across the FroYo wireless tether. But, anyway...

When I first started working with Android, I found a simple tutorial on how to build SQLite databases. A few weeks ago, I was trying to track down the information again for project for my day job. After searching a bit, I was unable to find the original tutorial, but I found one that was a little better. The newer tutorial pointed me toward a much better way to handle databases.

In the Android SDK is a class called SQLiteOpenHelper. This class has two methods that Eclipse will force you to implement. The first is onCreate(), the second is onUpdate().

The onCreate() method is automagically called when you instantiate your descendant class, and the target database doesn't exist. In this method, you should issue all of the necessary SQLite commands to create the tables in your database. But, hold on a second. How can you put tables in the database when you didn't specify the database name? Simple, when the class is instantiated, the database name is passed in. The SQLiteOpenHelper class then takes care of creating the database for you, before the onCreate() method is called.

The onUpdate() method is also really handy and cool. When you instantiate the descendant class, you also pass in a database version number. If the version number you pass in is higher than the version number when the database was created, the onUpdate() method is called with version number stored in the database, and the version number presented when the class is instantiated. onUpdate() is responsible for issuing the correct SQLite commands needed to bring the database up to the schema version specified when the class was instantiated.

Okay, so blah, blah, blah.. Sample code!?


public class DBOpenHelper extends SQLiteOpenHelper {

    private final String MY_DATA_TABLE = "t_Data";
    private final String MY_DATA2_TABLE = "t_Data2";
 
 public DBOpenHelper(Context context, String name, CursorFactory factory,
   int version) {
  super(context, name, factory, version);
 }

 @Override
 public void onCreate(SQLiteDatabase myDB) {

  /* Create a Table in the Database. */
  myDB.execSQL("CREATE TABLE IF NOT EXISTS "
      + MY_DATA_TABLE
      + " (mystring1 VARCHAR, mystring2 VARCHAR);");
  
  myDB.execSQL("CREATE TABLE IF NOT EXISTS "
    + MY_DATA2_TABLE
    + " (mystring3 VARCHAR);");
 }

 @Override
 public void onUpgrade(SQLiteDatabase arg0, int arg1, int arg2) {
  // We don't use this just yet.
 }

}

Great! So the database gets created, but how do we actually use it?

Well, I am glad you asked. The SQLiteOpenHelper has methods that will return a handle to the database in either read only, or read/write flavors. So, if we wanted to use our open helper to create the database, and add a record to the second table, it would look something like this :



public void addDbData()
{
     DBOpenHelper dbHelper = new DBOpenHelper(this, "my_database", null, 1);
     SQLiteDatabase myDb = dbHelper.getWriteableDatabase();   // Open for write.

     // Now, use the normal SQLiteDatabase methods to work with the DB.
     myDb.execSQL("insert into " + MY_DATA2_TABLE + " set mystring3='Foo!';");
}

After you call addDbData(), you will now have a new database created with the name 'my_database', with schema version 1. The MY_DATA2_TABLE will also contain a single record containing the string "Foo!".

Two things worth pointing out in the addDbData() method. First, if you only want to read data from your database, you can change "getWriteableDatabase()" to "getReadableDatabase()". Second, always be sure you close your database after you are finished with it! The Java garbage collector won't do it for you, and you will get leak errors sent to your logcat console.

I am not going to get in to the update method of the SQLiteOpenHelper. I leave that as an exercise for you.

Something simple. Get text from a ListView.

2010-06-09T11:55:00.000-07:00

Perhaps this topic is considered too simple for most people, which is why there aren't more postings about it. But, it seems like a useful thing to know. Specifically, when you are using a ListView with the android.R.layout.simple_list_item_1 view, how the heck do you get the text from the item clicked in the OnItemClickListener class?

It is pretty simple. The second parameter of the onItemClick is a View that contains just the item that was clicked. (Or tapped, whatever.) If you used Eclipse to automagically generate the callback method for you, the variable will be named "arg1", which is what we will assume for this example.

Inside of the onItemClick method, you can figure out the text using the following code :

String s = ((TextView)arg1.findViewById(android.R.id.text1)).getText().toString();

Pretty simple, huh? But, the code doesn't quite explain itself. So, I'll take a stab at it.

A ListView is exactly what the name says. It is a list of views. When you create the ArrayAdapter that you will use to display the data, you also tell the ArrayAdapter what view it should use. In our case, we chose "android.R.layout.simple_list_item_1" so we could use a simple array for the data. What we are doing is referencing a very simple layout that only displays a single line of text. I am sure if you Google around you can find the XML definition.

Inside the layout is a single definition. It is a TextView named "text1". Since it is a built-in layout, we will find the layout information under "android.R", instead of just "R" where our layout definitions show up.

So, by executing findViewById() on the view that was clicked, and passed in as "arg1", we can get the text that the user clicked on.

Pretty simple huh?

Basic graphics with Android

2010-05-31T15:49:00.000-07:00

I have been working on a small game, and come across a real lack of useful information on how to develop a non-real time game. (i.e. A game that is entirely event driven.)

I started with the usual route, attempting to use existing UI objects to create the look that I wanted. However, I was unable to get the look and behavior that I wanted. So, I looked closer at the Lunar Lander sample in the Android SDK. The problem is that the Lunar Lander sample was perfect if you wanted to develop a real-time game. But, I didn't.

So, what to do? After much Googling, I found suggestions that what I really wanted to do was create a specialized view that would contain my game board. Doing this turned out to be easier than I thought it would. Using the Eclipse wizards, I created a new class that would be my game board view. The class was derived from the View class. The simplistic class would look something like this :


package com.example.simplegame;

public class BoardView extends View {
 public BoardView(Context context) {
  super(context);

 }
 
 public BoardView(Context context, AttributeSet attrib)
 {
  super(context, attrib);
  
 }
}

Now, let me save you some time and pain. When I started this effort, I used "super(context)" inside the second constructor. Doing that will prevent you from using findViewById() to get a pointer to the view in your form.

Okay, so now we have a basic class set up. But, it doesn't actually do anything useful. What we really wanted to do is have a small blue box drawn on our view. So how do we do that?

Simple. We add an onDraw() method to our class. onDraw() takes a single parameter, with is of type Canvas. The canvas is what we will draw on, and what will ultimately be shown on the screen. As previously stated, we want to draw a simple blue square on the screen, so our onDraw method should look something like this :


 @Override
 protected void onDraw(Canvas canvas) {
  super.onDraw(canvas);
  
  Paint p = new Paint();
                p.setAntiAlias(true);
                p.setARGB(255, 0, 0, 255);

                canvas.drawRect(0, 0, 10, 10, p);
         }

Before we move on to talk about how to use our new View in a form, I want to point out a little bit more information on how onDraw() works. According to the Android documentation, you should assume that the canvas passed in to onDraw() is blank. (That is, you should never rely on anything you have previously drawn to still exist on the canvas.) Because of this, you will need to redraw your entire view each time onDraw() is called. In our sample, we draw the blue square each time onDraw() is called.

Now that we have a new view class set up, we need to figure out how to put it in a form, and use it. To make things easy, I first created a simple form with a generic View that fills the entire screen. It looks something like this :


<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:layout_width="fill_parent" android:layout_height="fill_parent">
<View android:id="@+id/View01" android:layout_width="fill_parent" android:layout_height="fill_parent"></View>
</LinearLayout>

Now that we have our layout, we need to modify it to include our custom view. To do this, we change the <View> tags to be <com.example.simplegame.BoardView>. If you then take this class, and this form and wrap it in some boiler plate code that would display the form, you will get a form with a small blue square in the top left corner of the screen.

If you do some experimenting, you will find that you get the blue square on the screen even if you don't establish a pointer to the BoardView object in the form. While it may seem strange at first, if you think about it you will realize that all of the objects on a form exist as soon as the form is inflated. The findViewById() call is simply giving you a pointer to the object that already exists in memory. Therefore, the onDraw() method is called, even if your main program doesn't have a pointer to the view.

Meru configuration, part 1

2010-05-19T18:41:00.000-07:00

As promised, I am going to give the QuickPhones phone a shot with the Meru gear. But first, I need to get the gear set up.

A quick rundown of what my configuration will look like :
1 - Meru MC 500 controller running version 3.4-103 software
1 - Meru MN-AP320
1 - Meru MN-AP201RH

I powered up the unit, and plugged in to it via a USB->Serial dongle. As the instructions indicated, I set up the serial port to 115200,8,N,1. I watched as the controller booted some flavor of Linux, and then hung on the "Starting Meru 3.4-103 wireless LAN services ...". After sitting for a while, I figured something was wrong, so I power cycled the box to see if it would come up a little quicker. (It didn't.)

I figured there was something wrong with my unit, so I pulled up a text editor to start writing my blog entry about how much I would have loved to write the entry about the QuickPhones with Meru. While I was getting everything together, the console spit out an error message, and then prompted me for a login.

I went ahead and put the default admin/admin username and password and got the console prompt back. At the console prompt, I ran the "setup" process. After answering the normal questions (ip address, gateway, netmask, etc.) the unit asked if it could reboot. (So I let it. Shocking, huh?)

Fortunately, it rebooted a lot faster than the initial boot. After a minute, I was able to log in and was back at the command prompt.

Normally, I am the kind of person that hates to configure gear with the web interface. But, in this case I decided to make an exception since the goal is not to evaluate the Meru gear, but rather to see if the phone works better on it. I fired up Firefox, and hit the web page. At this point, I was informed that I needed to use Internet Expoliter to access the UI on the box. (As an aside, I am sure that the version of code I am using is older. But, I still have to say, REALLY!? *sigh*)

Since I am already inflicting punishment on myself, I figured I would give IE 8 x64 a shot. When I hit the web site, I was first told that the certificate on the unit was suspicious (which is normal on gear like this), and after telling IE it was okay to continue, I was prompted for the username and password.

The UI that was displayed is reasonably clean, but doesn't show any useful information initially. (Probably because I don't have any APs it can talk to.) So, I pulled out the AP201RH. The first thing I noticed is that the AP appeared to want power over ethernet (PoE). So, I tried plugging it in to port 2 on the controller in hopes that it would power on. But, it seems that either port 2 doesn't do PoE, or there is some configuration setting that I need to enable before it will do it. Again, since I really want to get to the QuickPhones testing, I just took the AP in to another room that had a PoE port that I knew would work.

I managed to get the AP201RH up and running easily enough. So I plugged in the AP-320 so I could get it configured and ready to rock. Unfortunately, the AP-320 is running a different version of code, and try as I might, I am unable to upgrade, or downgrade it. Since the controller sees the AP as an AP-100, I am guessing this is a good thing.

Unfortunately, this is a dead end for this effort. I'll have to see if I can track down my friend at Meru to see if I can get some help. (The gear I have is test gear, so I don't have a maintenance contract to get the latest versions of code.)

I hope to have more in the coming weeks, assuming I can reconnect with an old friend.

Stupid Android ListView tricks

2010-05-17T18:39:00.000-07:00

I recently made some major changes to the Movie Track app that I put out. What started as an app that I did for my own use seems to have gained a few users. So, I decided to upgrade the look and feel a bit. In the process of this, I changed several of the screens from using a ListActivity to using a normal XML layout that contained a ListView. After mucking around with all of the settings to get things looking the way I wanted, I ran in to an interesting snag.

Everything displayed the way I wanted it to, but to "click" on an item that was in the ListView, you had to actually "click" on the text of the ListView, and not just on the row in the ListView. Perhaps I am a perfectionist at some level, but this annoyed me to no end.

Much Google later, I couldn't find the answer on how to do it. So, I started to mess with settings. A hair-brained idea or two later, I decided to try changing the ListView's layout-width from "wrap_content" to "fill_parent". Amazingly enough, that did exactly what I wanted!

Sure, this was a bit of a "duh" experience, and a newbie mistake. But, I figured I would publish it here in case some other developer runs across the same thing, and gets as frustrated as I was getting!