Analysing an HTTP connection between a Nokia 6600 and a production apache server

June. 4th, 2008 10:28 by sdelucaPermalink | TrackBack: — exists for 10 years & 5 months ago

I have come accross an issue about one phone that is not handling cookies correctly. In order to understand where the bug was -- either the Nokia 6600 or our server, I needed to trace the apache response header sent by my service I wanted to check the Set-Cookie headers.

First of all, looking at apache trace feature didn't give me much help, I've basically found nothing.

I turned to a low-level tool, tcpdump: this is a tool that enable root to capture any UDP/TCP packets right from the network interface of the server.

Installing tcpdump is pretty easy on debian, just do the following:

$ apt-get install tcpdump

I was most interested in capturing HTTP protocol. But our production server handles hundred of thousands users communication so we must filter the right connection out of all this "mess".

Looking at the apache log, you can easily found the IP of the Bouygtel GSM gateway, in our case it was:

As I am interested in HTTP only protocol, I filtered this by using the "port http" option.

Here is the command line I used to capture the HTTP communication:

tcpdump "port http and (src host or dst host" -s 0 -A -w nokia6600ascii.txt

The "-s 0" option tells tcpdump not to drop some packets. The "-w " just ask tcpdump to write the capture in the specified file. And the -A tells it to ASCIIfied the dump.

As a result I've got the following catpure:

$more nokia6600ascii.txt

??Gb`GET /?page=intro&channel=Buzz-Flirt-IN-testmcs HTTP/1.1
Accept: audio/wav, audio/x-wav, audio/basic, audio/x-au, audio/au, audio/x-basic, video/mp4, video/mpeg4, 
video/3gpp, application/vnd.rn-realmedia, audio/AMR-WB, audio/AMR, application/sdp, audio/sp-midi, audi
o/x-beatnik-rmf, audio/midi, application/java-archive, text/, application/vnd.wap.wmlc, 
text/vnd.wap.wml, application/vnd.wap.wbxml, application/vnd.wap.wmlscriptc, text/html, applic
ation/vnd.wap.xhtml+xml, application/xhtml+xml, , application/x-wallet-appl.user-data-provision, application/vnd.met.ticket, 
application/vnd.symbian.install, audio/x-pn-realaudio-plugin, audio/x-pn-realaudio, audio/mpegurl, audio/x-mpegurl,
 text/x-co-desc, application/vnd.oma.dd+xml, application/, text/vnd.symbian.wml.dtd, application/java,
 video/3gp, audio/rmf, audio/x-rmf, audio/x-midi, application/x-java-archive, application/vnd.oma.drm.message, 
application/x-x509-ca-cert, text/plain, text/X-vCard, text/calendar, text/x-vCalendar, text/css, image/*
Accept-Charset: iso-8859-1, utf-8, iso-10646-ucs-2; q=0.6
Accept-Encoding: gzip;q=1.0, identity; q=0.8
Accept-Language: fr
Cookie: PHPSESSID=40551094df2c98748c211e7ddb053b73
User-Agent: Nokia6600/1.0 (4.09.1) SymbianOS/7.0s Series60/2.0 Profile/MIDP-2.0 C~QFHJ?BB^L??NEH@@{?[yP??P"W??0?V6??i,
Profile: ""

Gb??HTTP/1.1 302 Found
Date: Wed, 04 Jun 2008 08:25:34 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: nbvisit=1; expires=Fri, 04-Jul-2008 08:25:34 GMT; path=/;
Set-Cookie: lastvisit=1212567934; expires=Fri, 04-Jul-2008 08:25:34 GMT; path=/;
Set-Cookie: rigoler=-1; expires=Fri, 04-Jul-2008 08:25:34 GMT; path=/;
Set-Cookie: AB_ID=1212567934-2213; expires=Fri, 04-Jul-2008 08:25:34 GMT; path=/;
Set-Cookie: AB_firstvisit=1212567934; expires=Fri, 04-Jul-2008 08:25:34 GMT; path=/;
Set-Cookie: AB_nbofvisit=1; expires=Fri, 04-Jul-2008 08:25:34 GMT; path=/;
Set-Cookie: AB_lastvisit=1212567934; expires=Fri, 04-Jul-2008 08:25:34 GMT; path=/;
Set-Cookie: AB_color=gray; expires=Fri, 04-Jul-2008 08:25:34 GMT; path=/;
Location: /?tapeshdah=40551094df2c98748c211e7ddb053b73&redirect=intro&channel=Buzz-Flirt-IN-testmcs&&sdlredirfrom=intro
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 27
Content-Type: text/html

Note that in the dump there still are some binary chars not filtered out by the -A option, but those chars doesn't prevent us to read the HTTP code.

As you can see, we've got the Set-Cookie headers that shows the server has the right behavior.

Should we conclude that this phone with the given firmware mishandles HTTP protocol?

Looking further at the dump, I noticed that the PHPSSESID was correctly handled by the client. So why? This cookie ws written without any expiration date:

Set-Cookie: PHPSESSID=c407903eb49ce37939be4758962edf09; path=/

This is odd. I then modified my own cookies, now passing them without expiration date, and guess what... It works!

Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: lastvisit=1212570224; path=/ Set-Cookie: rigoler=-1; path=/ Set-Cookie: AB_nbofvisit=2; path=/ Set-Cookie: AB_lastvisit=1212570224; path=/

And the next equest from the phone had my cookies:

Cookie: PHPSESSID=f26738a51499297134b51e8e8195a59a; nbvisit=1; lastvisit=1212lZF3BB^L??NE4?@@?@[yP??P??? V??????g? Ge?Đ'1(lZFH^dd?NF?ӣ*EV?@2?;P??[y??P???? VƀO??} ?'1(Ge?T570218; AB_ID=1212570218-bdad; AB_firstvisit=1212570218; AB_nbofvisit=1; AB_lastvisit=1212570218; AB_color=reset

Looking at the RFC didn't make me know if I did something wrong. If you know why, tell me in the comment section.