Packet trace for SPDYv2?

[Peter Griess]

Hi,

Is there a repository of known-valid plaintext packet traces available for SPDYv2? I'm futzing around with a parser and am looking for test datasets which I can trust.

It looks like I could get this with the flip server (running it either in plaintext mode, or sing its certs to decrypt the TCP session using wireshark), but I've been having problems getting flip built and was hoping to make progress w/o that.

Thanks,
Peter
--

@pgriess / http://blog.std.in

[Peter Griess]

On Mon, Feb 21, 2011 at 10:04 PM, Peter Griess <p...@std.in> wrote:

It looks like I could get this with the flip server (running it either in plaintext mode, or sing its certs to decrypt the TCP session using wireshark), but I've been having problems getting flip built and was hoping to make progress w/o that.

I've switched gears and am trying to build mod_spdy (from which I'll grab a packet trace and decrypt with the server's private key), which is of course also failing to build.

This is what I see from top-of-trunk

# make
  CC(target) out/Debug/obj.target/base/third_party/chromium/src/base/setproctitle_linux.o
  CXX(target) out/Debug/obj.target/base/third_party/chromium/src/base/third_party/dmg_fp/dtoa.o
cc1plus: warnings being treated as errors
third_party/chromium/src/base/third_party/dmg_fp/dtoa.cc: In function 'void dmg_fp::hexnan(dmg_fp::U*, const char**)':
third_party/chromium/src/base/third_party/dmg_fp/dtoa.cc:1562: warning: array subscript has type 'char'
third_party/chromium/src/base/third_party/dmg_fp/dtoa.cc: In function 'double dmg_fp::strtod(const char*, char**)':
third_party/chromium/src/base/third_party/dmg_fp/dtoa.cc:3286: warning: converting to 'ULong' from 'double'
third_party/chromium/src/base/third_party/dmg_fp/dtoa.cc: In function 'char* dmg_fp::dtoa(double, int, int, int*, int*, char**)':
third_party/chromium/src/base/third_party/dmg_fp/dtoa.cc:3840: warning: converting to 'int' from 'double'
make: *** [out/Debug/obj.target/base/third_party/chromium/src/base/third_party/dmg_fp/dtoa.o] Error 1

I've tried to re-generate the build files using build/gyp_chromium like so, but then the generated Makefile is a no-op:

# python ./build/gyp_chromium -Dwerror=
# make
make: Nothing to be done for `all'.

Does anyone have advice for getting this stuff built?

[Mike Belshe]

Hi, Peter,

Sorry for the slow response.  It takes some time to configure my test setup to run without ssl.

Attached is a trace of a simulated SPDY connection for www.cnn.com.

The test was done over loopback, the server is running on port 8000.

Mike

[Peter Griess]

Thanks, Mike. That packet trace was exactly what I was looking for.

I didn't realize that these types of porting issues were more or less expected at this point. I'll just patch things up myself as I see problems in the future. Are you guys interested in portability patches (I'm building on CentOS 5)?

Peter

On Thu, Feb 24, 2011 at 10:22 AM, Mike Belshe <mbe...@google.com> wrote:

I just did a full checkout and build of mod-spdy and it worked just fine.

I'm guessing that particular error is just a minor porting difference between ubuntu (my distro) and your linux distro.

I had built on another distro once, and I think I ran into the same errors.  Here is the patch, which will build this file.

I suspect you'll run into other minor porting-related annoyances, you'll probably need to tweak a little.

I suspect a better linux ninja could find a better way to suppress these silly warnings!!!

Index: third_party/dmg_fp/dtoa.cc

===================================================================

--- third_party/dmg_fp/dtoa.cc (revision 67242)

+++ third_party/dmg_fp/dtoa.cc (working copy)

@@ -1559,7 +1559,7 @@

  CONST char *s;

  int c1, havedig, udx0, xshift;

 

- if (!hexdig['0'])

+ if (!hexdig[(int)'0'])    /* XXXMB*/

  hexdig_init();

  x[0] = x[1] = 0;

  havedig = xshift = 0;

@@ -3283,7 +3283,7 @@

 #ifdef Avoid_Underflow

  if (bc.scale && y <= 2*P*Exp_msk1) {

  if (aadj <= 0x7fffffff) {

- if ((z = aadj) <= 0)

+ if ((z = (ULong)aadj) <= 0)  /* XXXMB*/

  z = 1;

  aadj = z;

  aadj1 = bc.dsign ? aadj : -aadj;

@@ -3837,7 +3837,7 @@

  */

  dval(&eps) = 0.5/tens[ilim-1] - dval(&eps);

  for(i = 0;;) {

- L = dval(&u);

+ L = (int) dval(&u);  /* XXXMB*/

  dval(&u) -= L;

  *s++ = '0' + (int)L;

  if (dval(&u) < dval(&eps))

Mike

[Mike Belshe]

On Thu, Feb 24, 2011 at 8:27 AM, Peter Griess <p...@std.in> wrote:

Thanks, Mike. That packet trace was exactly what I was looking for.

I didn't realize that these types of porting issues were more or less expected at this point. I'll just patch things up myself as I see problems in the future. Are you guys interested in portability patches (I'm building on CentOS 5)?

That was what I had built on too.

I'm not familiar enough with the linux variants to know what is "normal" or not.  Patches are welcome.  See http://dev.chromium.org/

Mike

[Mike Belshe]