Build Information:
Version 1.12.6 (v1.12.6-0-gee1fce6f from master-1.12)
Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 17 2015), with
AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz, with 16337MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
Wireshark is Open Source Software released under the GNU General Public License.
Using Wireshark Sample capture file - Ethernet_Pause_Frame.caphttps://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=Ethernet_Pause_Frame.capUsing Version 1.12.6 the decode of the frames appears to be decode as Priority Flow Control (PFC) frame instead of standard PAUSE flow control. Version 1.6.5 and 1.10.0 decodes correctly.
I cannot reproduce your issue with a newly installed Wireshark 1.12.6 (with the default preferences). By any chance, have you configured 'Decode As' so that Ethertype 0x8808 is decoded as something else than MAC Control? Could you post an image showing your dissection?
I do not have an "decode as" configured..... It's almost as though the ethertype of 0x8808 is seen as MAC Control but then the opcode to distinguish between Priority Flow Control (opcode 0x0101) and traditional PAUSE (0x0001) is not being checked. There may be other differences as we this but this is just what seems to be happening.
Let me know if I can provide any additional information that may help.
This change also added a systematic timestamp field after the opcode. From what I can see in the 802.3 2012 table 31A-1, this field is not supposed to be present with opcode 0x0001, 0x0101 or 0xFFFE. So there seems to be a bug here.
(In reply to Pascal Quantin from comment #6)
> (In reply to Bill Meier from comment #4)
> > (I'll take a look at this)
>
> OK Bill, I will let you continue on this :)
Actually, you're ahead of me doing the same research I was doing (looking at the spec, etc) so I'm happy to let you continue... :)
(In reply to Bill Meier from comment #7) > (In reply to Pascal Quantin from comment #6) > > (In reply to Bill Meier from comment #4) > > > (I'll take a look at this) > > > > OK Bill, I will let you continue on this :) > > Actually, you're ahead of me doing the same research I was doing (looking at > the spec, etc) so I'm happy to let you continue... :) > > OK ? OK I will give it a try then (unless you feel very interested by this one ;), I just had my comment almost written when I saw your post so I considered I should still publish it).Nathan, could you clarify my query in comment #5? Apart from the timestamp bug I'm gonna fix, were you simply puzzled by the field name?
(In reply to Pascal Quantin from comment #8) > (In reply to Bill Meier from comment #7) > > (In reply to Pascal Quantin from comment #6) > > > (In reply to Bill Meier from comment #4) > > > > (I'll take a look at this) > > > > > > OK Bill, I will let you continue on this :) > > > > Actually, you're ahead of me doing the same research I was doing (looking at > > the spec, etc) so I'm happy to let you continue... :) > > > > OK ? > > OK I will give it a try then (unless you feel very interested by this one > ;), I just had my comment almost written when I saw your post so I > considered I should still publish it). > > Nathan, could you clarify my query in comment #5? Apart from the timestamp > bug I'm gonna fix, were you simply puzzled by the field name? So the two key items are 1)the pause time is not be decoded correctly (the frame in the attached screenshot if decoded correctly should have a pause time of 65535 quanta and 2)the timestamp field is not valid for a standard Pause (non Priority Flow Control).As you noted the terminology being used does not seem to be consistent with the IEEE 802.3 spec terms associated with flow control frames.I think make the terminology consistent would certain reduce the chance of any confusion.But the primary objective would be the proper decode