Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 6854] tn3270 dissector: decoding WCC and SF attribute bytes incorrectly

[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 18 on bug 6854 from Guy Harris

(In reply to Bill Meier from comment #10)
> I believe the right answer is that the telnet dissector needs to create a
> new tvb with the escapes removed before handing the new tvb to the tn3270
> dissector (or, I expect, the tn5250 dissector).
> 
> There's code already in the telnet dissector to remove the escape in certain
> cases; the telnet code needs to be refactored a bit so that the escapes are
> removed once before *any* "application" processing of the stream is done.

The Telnet code needs to be changed so that it:

  searches for an IAC in the tvbuff it's been handed;

  if it doesn't find one, dissects the rest of the tvbuff by:

      putting lines from that segment into the protocol tree if this isn't
tn3270 or tn5520;

      handling the rest of the segment to the tn3270 dissector if this is
tn3270;

      handing the rest of the segment to the tn5520 dissector if this is
tn5520;

  which completes the dissection of the tvbuff;

  if it does find one, dissects everything up to the IAC in the fashion
described above, and then dissects the command - requesting that the parent
dissector (the TCP dissector) do whatever reassembly is necessary to get the
entire command into the tvbuff;

  if the command is IAC:

    just shows the IAC IAC as a command if this is neither tn3270 nor tn5520;

    shows the IAC IAC as a command and then constructs a 1-byte tvbuff
containing an IAC and hands it to the tn3270 dissector or the tn5520 dissector,
as appropriate, otherwise;

  if there's more stuff in the tvbuff, loops back.

The tn3270 and tn5520 dissectors need to do their *own* reassembly of
multi-byte sequences split across tvbuffs, as the Telnet dissector has no clue
what those sequences might look like; this means that they need to be able to
return a "NEEDS MOAR DATA" indication back to the Telnet dissector, which will,
if it sees such an indication, return a "need another segment" indication back
to the TCP dissector.

The tn3270 and tn5520 dissectors should *not* be doing their own handling of
IAC; they should only see an octet with the value 0xFF if there's an actual
0xFF in the data stream, and they should see one 0xFF for every 0xFF in the
data stream, i.e. one 0xFF for every IAC IAC pair in the Telnet session.

---

      You are receiving this mail because:

• You are watching all bug changes.