We Solved It! Return of the PAL Problem

Remember what I was saying about the campus networking issue I've been discussing? Long story short: My phone connects to our PEAP and THAWTE protected campus network just fine, but once I am on, the network cannot do anything. But only with Android. Windows is happy with PAL2.0. iOS is happy with PAL2.0, and if I recall the last time I booted the poor, battery-starved old Linux laptop I have in my bookcase at work, desktop Linux is happy with PAL2.0.

But Android is not. Which is annoying.

I have of course went to the helpdesk, and that's where it gets a bit interesting. There's two groups I've hit: the helpdesk, who have found this problem across different Android versions, across different carriers, different handset manufacturers, without finding any common indicator, and the networking group, who, without more to go on, have entered the go away kid, you bother me zone, considering it a failure in user configuration.

I feel I should point out that, for the most part, my co-worker Rick keeps his Android phone all but off when he's in the office. I, on the other hand, tend to hook my phone into my Greater Audio System (Windows and another 1/8" cable [either laptop or phone, depending] run into a y-cable plugged into the audio-in of my Linux box, which I config to go direct to the audio out, because I don't have a mixer, and then into a speaker and to my headphones) so I can get my phone's notification beeps and podcasts along with the other audio I have at work. So I use the network and feel it when it isn't available. So, while I was pushed by usage, for Rick it was a question of curiosity. Which seems to be enough.

When you think about networking, if you think about networking, you probably think about your IP address akin to a phone number, which kinda works and kinda doesn't. Assume we have an address of 8.8.8.8 (which I don't: that's the IP address of Google's open DNS server, which I kinda like). I can directly connect to any machine on my subnet, which could easily be 8.8.8.7 and 8.8.8.15 or further out, and if I can't find what I want on my local network, the traffic goes out the gateway to the hierarchically higher network. (There can also be down, in addition to up, but that's not important right now.)

One way to look around the local network is by using MAC addresses and routing tables, but that's too low level for this discussion. We use subnet masks. It's a series of 1s and 0s, in that order, which is used to tell if IP address A is in the same subnet as IP address B. A common netmask would look like 11111111111111111111111100000000. Clearly, that's hard for people to deal with, so we would write that as 255.255.255.0. First, each of those four breaks out 8 spaces, which are binary representations of positive integers between 0 and 255. Here's a table of what the allowed numbers are:

00000000	0
10000000	128
11000000	192
11100000	224
11110000	240
11111000	248
11111100	252
11111110	254
11111111	255

So, if the subnet mask is, 255.255.0.0, that means the mask in binary is 11111111 11111111 00000000 00000000. The digit that share a space with 1 will be the same if the IP address is on the same subnet, and different if it's 0. Google's 8.8.8.8 would be 00001000 00001000 00001000 00001000, the neighbor 8.8.8.9 would be 00001000 00001000 00001000 00001001. Diff's at the end, in the zero space, and thus same subnet. 8.9.8.8 would be 00001000 00001001 00001000 00001000, and that diff would be in the ones, and thus different.

The subnet mask sent out by DHCP was 255.255.240.0. iOS and Windows are just peachy with that. Rick noticed that the IP addresses were a little higher than he would expect. He suggested that we enter in static IP addresses based upon what we got via DHCP (using a tool like ifconfig to tell you it all) but with 224 as the third octet, and it worked like a charm. Go us!