Title: RE: change in tcp follow stream "save as" [x3]
Thanks for the good suggestion that was made to check one of the recent dev [probably dev] builds. As was pointed out, there have been changes in this area. To keep this e-mail trail from getting too large, I'm going to cut off some of the not essential things in my original e-mail, which is appended.
I chose to check the tcp follow stream, and save as, in build ending in "..svn-13316", using both the "ASCII" and "Raw" radio buttons.
Yes! Yes!
The addition of the "Raw" button to the follow tcp stream in the "..svn-13316" build restores the ability to preserve the binary content of the data in the followed frame conversation.
I also want to congratulate whomever has done the follow tcp stream display rendering speed up when going between formats [ascii to hex dump, for example]. Great!
I presume these considerable enhancements will be in 0.10.10?
Ron Norton
-----Original Message-----
From: Ron Norton
Sent: Saturday, February 05, 2005 9:35 AM
To: 'ethereal-users@xxxxxxxxxxxx'
Subject: change in tcp follow stream "save as"
[..]
One of the unique and very useful features in our situation is the "tcp follow stream". This is a great aid because it has allowed following a set of frames connected to a job whose aggregated, intact, packet data content we needed to be able to use for diagnosis by resending the data content.
Often that content of interest in our case is a mix of both ASCII and binary. The windows driver for some of the devices we manufacture happens to output a PCX image in various situations.
[..]
For ethereal 0.9.7-0.10.3 using "save as" on such an ASCII tcp follow stream display produces a saved file that has both the ASCII and binary data intact. In our case, using a binary editor on the saved file then allowes recovery and viewing of the embedded-in-job pcx image for correctness.
[..]
For 0.10.5 through 0.10.9 the "tcp follow stream, save as.." file output has been changed, either intentionally or unintentionally.
What occurs in the "save as" file output from 0.10.5 and up is that the characters displayed in the ASCII display are what you get in the "save as file". This means a null, for example, gets saved in the file as a 2E, because a 2E, or the period, is used in the ASCII display for a non-printable value which destroys it's utility to us.
My questions:
-- is/was this "save as.." behavior change intentional, or
-- is there a means to work around this I am not aware of in 0.10.5 and up, or?
Any feedback from anyone would be greatly appreciated. Clearly we'd like to be able to take advantage of the newer build features/fixes as the come also. Right now, have to keep two versions installed.
Ron Norton