https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6854
--- Comment #8 from Michael Wojcik <michael.wojcik@xxxxxxxxxxxxxx> 2012-04-06 14:43:25 PDT ---
Definitely looks better (and I agree that this dissector was already a
substantial piece of work).
Issues I noticed in this version:
1. The dissector doesn't recognize a local-mode Read Buffer command. This
appears as a record with only a single byte of Telnet data, with the value 02,
followed by the Telnet EOR sequence and optionally preceded by the TN3270E
five-byte header. So it typically looks like this in the data stream:
00 00 00 00 00 02 ff ef
The dissector interprets it as:
TN3270 Protocol
TN3270E Header (Data Type: 3270_DATA)
Bogus value: 2
Command: End of Record
which is correct except for the "Bogus value" bit. 2 is a legal 3270 command;
it's Read Buffer for locally-attached terminals. (See the IBM 3174 Functional
Description, section 2.1.4.)
The problem seems to be in dissect_outbound_stream() in tn3270-packet.c, which
doesn't include any of the outbound 3270 read commands in its switch statement.
2. The dissector is confused if an escaped 0xff byte appears in some places in
the TN3270 data. Since TN3270 is Telnet plus special sauce, 0xff is the Telnet
IAC (Interpret As Command) byte and has to be escaped by doubling it in the
data stream.
I have a test that includes a Read Partition Query command. That test has two
cases of escaped 0xff bytes. One is the Partition ID, and the dissector
recognizes the doubled 0xff there and handles it. The other, though, is in the
Query List, and it causes the dissector to throw an exception and flag it as a
malformed packet.
The packet ends with a6 ff ff ff ef: query codes a6 and ff, with the latter
escaped, followed by the Telnet EOR. The dissector says:
...
Query Reply: Implicit Partition (0xa6)
[Malformed Packet: TN3270]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Message: Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]
The query code 0xff is valid - it's the code for "Query Reply (Null)".
It appears there's special code to handle the 0xff when it's the Partition ID
(in function dissect_read_partition(), where there's an "XXX" comment
suggesting that the Telnet base dissector should handle escaped 0xff bytes).
I haven't identified the problem with the code, but perhaps the escaped byte is
causing the dissector to increment offset one too many times in the loop at the
end of dissect_read_partition().
3. There's a similar escaped-0xff bug when processing a reply from a Read
Partition Query. In my case, the terminal emulator responded with, among other
things, the Coded Graphic Character Set Identifier 0x000000000006c0ff. Because
the last byte is 0xff and it's being sent via Telnet, the 0xff had to be
escaped, but the dissector wasn't expecting that and took the second 0xff byte
as the start of the next field, leading it to report an unknown Structured
Field type.
Resolving all of these cases with 0xff escaping may be tricky. If I get a
chance, I'll look at the dissector source to see if there's a single place
where they could be handled (possibly by doing so in the Telnet dissector, as
suggested by that comment in the source).
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
