On 10 Mar 2003, Brad Hards <[EMAIL PROTECTED]> wrote: > > You could decode the STAT result as a waitstatus. > This is still to come. I need to think about presentation for this.
Status: exited 0 (0x00000000) Status: exited 1 (0x00000100) Status: killed by signal 2 (0x00000002) Look at sys/wait.h to find out how to decode it. > > In the summary line packet list I think the best thing to show for the > > request is the whole compiler command line; for the response probably > > the decoded status and perhaps the error messages. > Response is a bit harder - I recall seeing packets for the response where the > SOUT part was in a different packet to SERR. I still like the idea of > labelling them with indicative contents. Yes, that could easily happen if there are many errors. It's quite possible that the argv could span multiple packets if they're long or if the MTU is short. You really need to reassemble the TCP stream and work from there. Any alignment with packet boundaries is purely accidental. I don't know how hard this is in Ethereal, if it can't be done then I guess we just need to put up with only decoding the first packet. > I am working on it, but I have a few things that are more important (GF > birthday on Tues, horseriding on Wed, UUNITE and ANSP meetings on Thurs :) to > take care of before the weekend, which is when I am likely to get back it it. > An interim patch is attached - feedback welcome. Hopefully this can get > through to distcc. There's no rush. The other thing that would be very cool, but which is probably not very practical at the moment, is that it would be great if Ethereal could decode distcc-over-ssh. Ethereal would need to be able to be told to treat the contents of the ssh stdin/stdout streams as a distcc stream. I don't know if anyone is considering this kind of recursive dissector. -- Martin
