On Wed, 2019-07-03 at 11:23 +0200, Sven Eckelmann wrote: > > ~/tmp/wireshark/build/run/tshark -r /tmp/hwsim-test-logs/latest/wpas_mesh_max_peering.hwsim0.pcapng -T fields -e wlan.sa -e wlan.mesh.config.cap 'wlan.fc.type_subtype == 8' > 02:00:00:00:01:00 0x00000009 > 02:00:00:00:00:00 0x00000009 > 02:00:00:00:01:00 0x00000009 > 02:00:00:00:02:00 0x00000009 > 02:00:00:00:00:00 0x00000008 > 02:00:00:00:01:00 0x00000009 > 02:00:00:00:02:00 0x00000009 > 02:00:00:00:00:00 0x00000008 > > With wireshark 3.0.0: > > tshark -r /tmp/hwsim-test-logs/latest/wpas_mesh_max_peering.hwsim0.pcapng -T fields -e wlan.sa -e wlan.mesh.config.cap 'wlan.fc.type_subtype == 8' > 02:00:00:00:01:00 0x00000001 > 02:00:00:00:00:00 0x00000001 > 02:00:00:00:01:00 0x00000001 > 02:00:00:00:00:00 0x00000001 > 02:00:00:00:02:00 0x00000001 > 02:00:00:00:01:00 0x00000001 > 02:00:00:00:02:00 0x00000001 > 02:00:00:00:00:00 0x00000001 > > So I had to change the wireshark version (see below) which is used by hostapd. > (just to document for me what I have forced it to a different version) What. +hostap list. This makes no sense, is that a tshark bug in one of the versions? Maybe we should just use the JSON output, and parse that, but if tshark now has a different idea of what the "wlan.mesh.config.cap" field is, that won't help us at all? Older versions were misparsing the HE element, but that has a length so should only affect the HE element *itself*? So ultimately, what do we do here? Should we take this and sort out the tests? johannes
