iFires

10 July 2008

So today marks the launch the 3G version of the iPhone.  Working around the folks that have been very busy working to launch this new phone, I’ve been exposed to a new set of nouns that I never knew existed before.

As a rule, most new phones don’t require a lot of extra work on the part of the cellular carrier.  You need to make sure that the device capabilities are entered and working in your SMSCs (text messages or SMS), your WAP Gateways (Internet web pages, although a lot of phone go direct now a days), and your MMSCs (picture messages). That the radio side of the network will work with the handset…all the usual things. Other than that is just the usual amount of coordination to make sure all the stores have the new phones in time.

But iPhones are a bit different.  There is a belief that they are going to be flying off the shelves and be selling at a phenomenal rate….like more and faster than last time.  So we have all been busy with meetings to make sure everything in the system can handled the anticipated load.  But these aren’t just any meetings….they are iMeetings. With iAgendas on iConference iCalls.

The closer we got to today, the more iMeetings we had.  Some were iFires in that someone felt some parts of the system needed to be corrected ASAP before today.  I guess when I have my iLunch today I’ll take a peek at the iSystem and see if it iCrashed. :)

Now if only Mr. Jobs would put an MMS client on the iPhone…..or is that an iMMS iClient ;)

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
 | Posted by MobileDataGuy | Categories: Cellphones, Opinions, OtherStuff |

In the course of working on Mobile Data systems, there are times when we need to figure out what is going to and from a particular handset or mobile device. The problem is that when the system you are trying to troubleshoot has tens of millions of devices connecting to it through proxy servers, its a lot like a needle-in-the-haystack kind of problem.

We had to narrow the potential number of packets that we would be capturing using tcpdump to something under a GB of disk space. If we just did a generic capture, we would only get about four seconds of traffic….which would not be very helpful for our troubleshooting efforts. So we needed a way to reduce the packets just down to the HTTP ‘GET’ packets, and the HTTP response codes.

After digging around the tcpdump man pages for awhile, I came up with the following parameters to just capture those packets:

tcpdump -i eth0 -n -s 1400 -W troubleshoot.cap host {localhost IP} and \( tcp[20:2] = 18245 or tcp[20:2] = 18516 \)

  • The “-i eth0″ tells it to capture off the eth0 network device.
  • “-n” tells it not to expand the IP addresses into domain name. (Optional)
  • “-s 1400″ captures 1400 bytes of each packet.
  • “-W troubleshoot.cap” is the capture file.
  • {localhost IP} would be where you substitute the IP address of the host you are capturing from.
  • Now the meat of the command: the “tcp[20:2]” tells tcpdump to look at the 20th byte of the TCP field and get two bytes from there. 18245 => 0×4745 => “GE” as in “GET”. My version of tcpdump only allows for 1,2 or 4 bytes to be compared, so I settled for two. 18516 => 0×4854 = “HT” as in “HTTP”.

This should significantly reduce the number of packets captured. But be aware — getting tcpdump to look inside the TCP field of the IP packets requires a lot of CPU cycles to process all the incoming packets.

Here’s a sample of a capture using the command above (and its only off my local office web server, so you won’t find any cellphone company secrets here):

21:02:58.807323 IP 192.168.22.27.55133 > 192.168.22.44.80: P 3493:4074(581) ack 1146 win 16138
0×0000: 4500 026d 7a60 4000 8006 d092 c0a8 161b E..mz`@………
0×0010: c0a8 162c d75d 0050 fe3a b4da 2337 2b65 …,.].P.:..#7+e
0×0020: 5018 3f0a 3e7c 0000 4745 5420 2f73 6d2f P.?.>|..GET./sm/
0×0030: 696d 6167 6573 2f70 6c75 732e 706e 6720 images/plus.png.
0×0040: 4854 5450 2f31 2e31 0d0a 486f 7374 3a20 HTTP/1.1..Host:.
0×0050: 3139 19
21:02:58.808107 IP 192.168.22.44.80 > 192.168.22.27.55133: P 1146:1337(191) ack 4074 win 3500
0×0000: 4500 00e7 5d80 4000 4006 2ef9 c0a8 162c E…].@.@……,
0×0010: c0a8 161b 0050 d75d 2337 2b65 fe3a b71f …..P.]#7+e.:..
0×0020: 5018 0dac 0c06 0000 4854 5450 2f31 2e31 P…….HTTP/1.1
0×0030: 2033 3034 204e 6f74 204d 6f64 6966 6965 .304.Not.Modifie
0×0040: 640d 0a44 6174 653a 2057 6564 2c20 3233 d..Date:.Wed,.23
0×0050: 204a .J

If you are counting out the packets by hand, the tcp[] option starts its counting at zero.

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
 | Posted by MobileDataGuy | Categories: Cellphones, HowTos, Radio Data |

So being a Mobile Data company, we of course decided that we needed a way to see our site while mobile.

This site can be viewed by your PDA web browser in a format that is a single column view. This is done automatically.

From your mobile phone:  Point your WAP browser to  http://m.exonets.com/

SociBook del.icio.us Digg Facebook Google Yahoo Buzz StumbleUpon
 | Posted by MobileDataGuy | Categories: Cellphones, HowTos, PDAs |