Wrong ordering in OpenFlow 1.0 Datapath unique ID
Summary
In OpenFlow 1.0 messages with type OFPT_FEATURES_REPLY (6) is the ordering of the Datapath unique ID the wrong way round.
Steps to reproduce
(How one can reproduce the issue - this is very important)
What is the current bug behavior?
In Wireshark the upper 48 bits are the MAC addr and the lower 16 bits are the implementers part as you can see in the first screenshot.
What is the expected correct behavior?
The unique ID begins with the implementers part and ends with the MAC addr as you can see the MAC in Ethernet header. In the second screenshot is the according part from OpenFlow Specifications.
Sample capture file
OpenFlow_Features_Reply.pcapng
Relevant logs and/or screenshots
Build information
Version 4.0.6 (v4.0.6-0-gac2f5a01286a).
Compiled (64-bit) using Microsoft Visual Studio 2022 (VC++ 14.32, build 31332),
with GLib 2.72.3, with PCRE2, with zlib 1.2.12, with Qt 5.15.2, with libpcap,
with Lua 5.2.4, with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.10.1, with
Kerberos (MIT), with MaxMind, with nghttp2 1.46.0, with brotli, with LZ4, with
Zstandard, with Snappy, with libxml2 2.9.14, with libsmi 0.4.8, with
QtMultimedia, with automatic updates using WinSparkle 0.5.7, with AirPcap, with
SpeexDSP (using bundled resampler), with Minizip, with binary plugins.
Running on 64-bit Windows (22H2), build 22621, with Intel(R) Core(TM) i7-8565U
CPU @ 1.80GHz (with SSE4.2), with 16139 MB of physical memory, with GLib 2.72.3,
with PCRE2 10.40 2022-04-14, with Qt 5.15.2, with Npcap version 1.71, based on
libpcap version 1.10.2-PRE-GIT, with c-ares 1.18.1, with GnuTLS 3.6.3, with
Gcrypt 1.10.1, with nghttp2 1.46.0, with brotli 1.0.9, with LZ4 1.9.3, with
Zstandard 1.5.2, without AirPcap, with light display mode, without HiDPI, with
LC_TYPE=German_Germany.utf8, binary plugins supported.
Edited by Elmenhorster