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: Sun, 26 Feb 2012 14:05:44 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6854

--- Comment #2 from Michael Wojcik <michael.wojcik@xxxxxxxxxxxxxx> 2012-02-26 14:05:41 PST ---
Created attachment 7900
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7900
Capture demonstrating problem

This attachment demonstrates the problem:

- Packet 15 contains a WCC of 0xc2. Per the /CICS Programmer's Guide/, 0xc2
means "WCC; this value unlocks the keyboard, but does not sound the alarm or
reset the MDTs" (as I mentioned in the bug report), but the dissector expands
this as "Reset, Keyboard restore, Reset MDTs". This is one of my examples from
the original bug report.

- Packet 38 contains a WCC of 0xc1, which is Reset MDT (and the two top bits
set for graphic conversion; they can also be decoded as NOP and Reset). The
dissector expands it as NOP, Keyboard Restore, Reset MDT - it looks almost
correct because 0xc1 is almost a binary palindrome, but again it's looking at
the bits in the wrong order.

- Packet 43 contains a WCC of 0xc8, which means the start-printer bit is set;
this one is easy to verify if you're running a terminal emulator that supports
local printing (mine does, in this case, and indeed the printer function is
activated). Again the dissector expands the WCC wrong because it has the bit
order reversed.

- For an example of the problem with attribute bits, see eg packet 23. At
offset 0x0041, there's an attribute byte with the value 0xf8. The dissector
expands this as "3270 Field Attribute: 0xf8, Display: Display Not Selector Pen
Detectable, Graphic Convert1, Graphic Convert2, Numeric, Protected, Reserved".
But the 8 in the lower nybble - the most significant of the four
less-significant bits - is not the "Reserved" bit, as the dissector claims.
It's the first of the two Display bits, so the Display value is actually 10
binary, which means "Intensified / pen not detectable". And indeed the data in
that field is displayed as bright (intensified).


Also, this trace shows another bug:

- Packet 28 contains (between the TN3270E header and the IAC EOR) 0x0f 0x20.
The 0x0f is a 3270 Erase All Unprotected command (using the encoding for a
locally-attached terminal); see Table 2-1 in the /3174 Establishment
Controller: Functional Description/ (GA23-0218). The 0x20 is the WCC, which
here has just the Printer1 bit set (for no obvious reason, but it's a no-op in
this case).

I hope this helps.

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