Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 6854] tn3270 dissector: decoding WCC and SF attribute byte

Date: Fri, 6 Apr 2012 15:22:28 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6854

--- Comment #10 from Bill Meier <wmeier@xxxxxxxxxxx> 2012-04-06 15:22:28 PDT ---
(In reply to comment #8)
> 
> Issues I noticed in this version:
> 
> ...
> 
> 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).

The comment was mine...   :)

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.

Currently the telnet code removes the escapes in a number of specific cases
rather than doing it once first before processing specific cases.

(You'll see what I mean if you look at the packet-telnet.c code).

I'm not sure if a new tvb should always be created whether or not there are any
escapes; To do so might be the simplest.

(I haven't gotten to working on this change because I got delayed by the work
to fix the 5250 dissector ....).

If you've the time, a patch is welcome...

(I'll look at the local mode Read Buffer issue).

Thanks again....

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