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.