ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 2533] EBCDIC display for TN3270 packet

Date: Fri, 17 Jul 2009 11:52:43 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2533





--- Comment #15 from hoganrobert <robert@xxxxxxxxxxxxxxx>  2009-07-17 11:52:39 PDT ---
(In reply to comment #14)
> A question:
> 
> For the second of the two attached capture files: after I do a "decode-as" with
> "telnet" I see all the detailed TNB3270 decode AOK in packet-details and the
> bytes decoded as EBCDIC in packet-bytes.

The second capture attached to this bug (TN3270E.pcap) is a sample capture I
uploaded.  My results match yours.

> 
> For the first attached capture file: with no "decode-as" the protocol shows as
> telnet in the summary pane, the packet-details pane shows a telnet decode and
> the packet-bytes pane decodes the bytes as ASCII.
> 
> If I do a "decode-as" using TN3270: the protocol shows as TN3270 in the
> summary-pane, and the packet-bytes pane decodes the bytes as EBCDIC.
> 
> However: there's no telnet or tn3270 decode in the packet-details pane (only a
> decode up to the TCP layer).
> 
> Also: if I clear the "decode-as tn3270" the summary-pane reverts back to
> showing telnet as the protocol but the packet-bytes pane continues to decode
> the bytes as EBCDIC. The packet-details does revert to showing a telnet decode.
> 
> Am I doing something wrong when trying to display this capture ??
> 

No, you're doing nothing wrong. The problem with the first capture is that it
is partial. It is missing the telnet negotiation at the start so the TELNET
dissector has not been able to determine that it is a TN3270 session and pass
it on to the TN3270 dissector. My results match yours, and the results are as
expected. It is not possible for wireshark to identify a TN3270 session from a
mid-stream capture, it needs to get the beginning of the session to know that
the rest of it contains TN3270 data for dissection.

As to whether wireshark should be able to handle this - my opinion is that it
can't. TN3270 payloads are simply not distinguishable in their own right, at
least not without a lot of time-consuming and error-prone guesswork.

Hope this helps! (There's an additional capture on the wiki page if you want to
try it out too: http://wiki.wireshark.org/TN3270 )


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.