Wireshark unable to parse ERSPAN from HP Comware platforms
Huawei GRE ERSPAN is not decoded properly
Add a pref to FORCE to decode directly Ethernet frame in GRE (with no ERSPAN Header)
svn path=/trunk/; revision=39687
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_OID
Note: Encoding field set to ENC_NA only if the field was previously TRUE|FALSE|ENC_LITTLE_ENDIAN|ENC_BIG_ENDIAN
svn path=/trunk/; revision=39260
keys to have _uint in their names, to match the routines that handle
dissector tables with string keys. (Using _port can confuse people into
thinking they're intended solely for use with TCP/UDP/etc. ports when,
in fact, they work better for things such as Ethernet types, where the
binding of particular values to particular protocols are a lot
stronger.)
svn path=/trunk/; revision=35224
indicate that the last 4 bytes of both types are similar.
So the extra bytes in type III are inserted before those
last bytes.
svn path=/trunk/; revision=34238
- Add decoding of direction bit for version 2 (type III) erspan.
Me:
- Decode the original direction bit as unknown in case of version 2.
- The original unknown3 value seems to indicate whether the packet
was too long to fit into a single mtu (trunkated).
- "Timestamp(s)" -> "Timestamp"
svn path=/trunk/; revision=34221
(1) Trailing/leading spaces are removed from 'name's/'blurb's
(2) Duplicate 'blurb's are replaced with NULL
(3) Empty ("") 'blurb's are replaced with NULL
(4) BASE_NONE, NULL, 0x0 are used for 'display', 'strings' and 'bitmask' fields
for FT_NONE, FT_BYTES, FT_IPv4, FT_IPv6, FT_ABSOLUTE_TIME, FT_RELATIVE_TIME,
FT_PROTOCOL, FT_STRING and FT_STRINGZ field types
(5) Only allow non-zero value for 'display' if 'bitmask' is non-zero
svn path=/trunk/; revision=28770
1. Priority field decode.
The 802.1q tag field of a frame is separated from its frame body in
a ERSPAN packet.
Current packet-cisco-erspan.c decodes only the vlan id field of the
802.1q tag.
This patch can also decode the priority field of the 802.1q tag.
2. Direction of a captured frame decode.
A ERSPAN packet includes the additional information of the direction
a captured frame as below.
If a caputred frame comes from outside to a switch port, this means an
'Incoming' frame. If a caputred frame goes out of a switch port,
this is an 'Outgoing' frame.
Added an extra unknown value for the bit between direction and spanid.
svn path=/trunk/; revision=22649
Chris Maynard