| Bug ID |
12502
|
| Summary |
Please align columns in tshark's output
|
| Product |
Wireshark
|
| Version |
1.12.7
|
| Hardware |
x86
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Enhancement
|
| Priority |
Low
|
| Component |
TShark
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
>From the bug report at Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797641
--------------8<------------------
Running "tshark -r" on some pcap file gives badly formatted output; while some
columns have a sane width, others are simply wrong.
Here's a shortened output:
| 8 66 03:14:31.106506 0.047926 192.168.72.206 -> 192.168.72.38
| 9 85 03:14:34.624295 3.565715 192.168.72.38 -> 192.168.72.61
| 10 95 03:14:34.626556 3.567976 192.168.72.61 -> 192.168.72.38
| 11 66 03:14:34.626576 3.567996 192.168.72.38 -> 192.168.72.61
This would look good so far ... but as soon as the number of bytes in a packet
isn't 2 digits long, or we get more than 999 packets, the output gets
unreadable:
| 12 85 03:14:34.628704 3.570124 192.168.72.38 -> 192.168.72.61
| 18 4410 03:14:40.900369 9.841789 192.168.72.206 -> 192.168.72.38
|994 1514 03:14:42.639231 11.580651 192.168.72.206 -> 192.168.72.38
|995 78 03:14:42.639237 11.580657 192.168.72.38 -> 192.168.72.206
|996 1514 03:14:42.639240 11.580660 192.168.72.206 -> 192.168.72.38
|997 66 03:14:42.639247 11.580667 192.168.72.38 -> 192.168.72.206
|998 1514 03:14:42.639249 11.580669 192.168.72.206 -> 192.168.72.38
|999 1514 03:14:42.639252 11.580672 192.168.72.206 -> 192.168.72.38
|1000 2962 03:14:42.639255 11.580675 192.168.72.206 -> 192.168.72.38
|1001 78 03:14:42.639255 11.580675 192.168.72.38 -> 192.168.72.206
|1002 1514 03:14:42.639258 11.580678 192.168.72.206 -> 192.168.72.38
|1003 1514 03:14:42.639260 11.580680 192.168.72.206 -> 192.168.72.38
IMO the packet numbers should be formatted as %5d, and the number of bytes %4d
or %5d. The IP addresses might make sense to be given as %-15s; for IPv4 this
would be the maximum length, and IPv6 addresses' lengths are too widely
variable (and can get too long) to reserve all space.
I'm aware that I could pass my own format options as well; but the default
output should already by useable. For comparision, here's "tcpdump -r":
|03:14:40.900965 IP 192.168.72.206.59036 > 192.168.72.38.7798: Flags [.],
|03:14:40.900972 IP 192.168.72.38.7798 > 192.168.72.206.59036: Flags [.],
|03:14:40.900976 IP 192.168.72.206.59036 > 192.168.72.38.7798: Flags [.],
|03:14:40.900982 IP 192.168.72.38.7798 > 192.168.72.206.59036: Flags [.],
|03:14:40.901235 IP 192.168.72.206.59036 > 192.168.72.38.7798: Flags [.],
|03:14:40.901243 IP 192.168.72.38.7798 > 192.168.72.206.59036: Flags [.],
|03:14:40.901245 IP 192.168.72.206.59036 > 192.168.72.38.7798: Flags [.],
(Yes, completely different output, yadda yadda yadda. That's why I want to use
tshark and not tcpdump. But the output is much easier to navigate, as eg. the
time is aligned.)
--------------8<------------------
I'd like to add that during capturing the IP addresses are aligned to some
extent but not perfectly:
$ tshark -i eth0
...
31 17.719239387 17.0.2.9 -> 74.125.276.189 TLSv1.2 112 Application Data
32 17.746877469 17.0.2.9 -> 74.125.276.189 TLSv1.2 338 Application Data
33 17.762580156 74.125.276.189 -> 17.0.2.9 TCP 68 https → 41898 [ACK] ...
34 17.790731320 74.125.276.189 -> 17.0.2.9 TCP 68 https → 41898 [ACK] ...
...
You are receiving this mail because:
- You are watching all bug changes.