Control: tags -1 confirmed upstream Control: forwarded -1 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12502 Control: severity -1 wishlist
Hi, On Tue, 1 Sep 2015 09:12:02 +0200 "Ph. Marek" <[email protected]> wrote: > Package: tshark > Version: 1.12.7+g7fc8978-1 > Severity: normal > > 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.) 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] ... ... Cheers, Balint
