This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

tshark: printed fields changed from hex to decimal

0

I have a very simple script I use to print some fields from the handshake messages from SSL traffic (basically trying to make sure nobody is using apps that use obsolete versions of SSL). I have this running on two machines: one is Ubuntu 12.04.4, running tshark version 1.6.7, and another running is Windows 7, running tshark 1.10.9. Here's the command:

tshark -r pcap-file -E header=y -Tfields -e ip.src -e ip.dst -e ssl.handshake.ciphersuite -e ssl.handshake.version

On both hosts, this basically works, but on the Ubuntu the ciphersuite and version are printed in hex, while on Windows they're printed in decimal. This is inconvenient, to say the least.

Is there a way to convince 1.10.9 on Windows to print these values in hex?

asked 25 Aug '14, 13:17

Daniel%20Ellard's gravatar image

Daniel Ellard
11113
accept rate: 0%


2 Answers:

3

It's a bug, see bug 10318.

answered 26 Aug '14, 07:58

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k572
accept rate: 27%

While we probably shouldn't be changing formats between 1.10.5 and 1.10.8, hence the [unrelated] bug, there are no guarantees between 1.6.7 and 1.10.9. Formats change from time to time, usually for good reason, so this is something one simply has to deal with when using different major versions of the tool.

(26 Aug '14, 10:10) cmaynard ♦♦

Hmm, I'm pretty sure the bug is related: between 1.10.0 and 1.10.8 we stopped printing any fields in hex and started printing them all in decimal. I agree with the originator of the bug (and the fix) who think that's a regression.

(I agree with you that, in general, we may change individual fields from hex to decimal or vice-versa but the bug here is that everything is now decimal--if you use tshark.)

(26 Aug '14, 10:51) JeffMorriss ♦

If that's the case, then yes that's surely a bug. The bug description does not make it clear that it pertains to all fields though, but rather only to the gtp.teid field.

(26 Aug '14, 10:58) cmaynard ♦♦

Ah, yeah, I guess that's so. But if you look at the Summary or the change that broke it, it becomes pretty clear. (The fact that someone independently reported the bug--but submitting a change to fix it--also suggests the problem is wide spread.)

(26 Aug '14, 11:04) JeffMorriss ♦

Yup, that looks like the issue, and probably a lot of people using tshark are going to trip over this because it changes how many fields are printed.

In this particular case, it is very convenient to have the fields printed in hex because the relevant constants in the RFCs are given in hex, which makes it very easy to read. Having the numbers in decimal makes the output harder to interpret.

(26 Aug '14, 19:15) Daniel Ellard

1

Assuming you have cygwin running on Windows, one way might be to use awk and printf to do the conversion:

tshark -r pcap-file -E header=y -Tfields -e ip.src -e ip.dst -e ssl.handshake.ciphersuite -e ssl.handshake.version | awk '!/^($|#)/{printf "%s %s %x %x\n", $1,$2,$3,$4}'

If you don't have cygwin and don't want to install it, then there might be a way to accomplish the same thing using Powershell.

Apart from those ideas, using the same version of Wireshark on both systems should avoid the problem.

answered 26 Aug '14, 10:03

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142
accept rate: 20%

Yes, with a little futzing I could get the output the same.

It's not as convenient as having a script that works everywhere, however.

(26 Aug '14, 19:10) Daniel Ellard