On Friday, 12 July 2019 11:42:51 CEST Johannes Berg wrote:
> On Fri, 2019-07-12 at 11:36 +0200, Sven Eckelmann wrote:
> >
> > There is already a workaround for that in the hostap testcases:
> >
> > if all_cap_one:
> > # It looks like tshark parser was broken at some point for
> > # wlan.mesh.config.cap which is now (tshark 2.6.3) pointing to incorrect
> > # field (same as wlan.mesh.config.ps_protocol). This used to work with
> > # tshark 2.2.6.
> > #
> > # For now, assume the capability field ends up being the last octet of
> > # the frame.
>
> > But maybe you already spotted the problem - it requires that mesh
> > configuration element is the last element. Which is not the case here -
> > similar to 5GHz tests (where you have most likely a VHT cap/oper element
> > after the meshconf_ie).
> >
> > I hope that this makes more sense now.
>
> Ah, yes, it does. So I guess we need to update/fix that workaround.
I will prepare a patch now for hostap after lunch.
> And
> I guess newer tshark (which you used) is fixed again, if I understand
> correctly?
Yes and no, the master branch is fixed. But unfortunately, there is no
release with this fix.
And the problems is there since commit 3c427376579a ("802.11: Use
proto_tree_add_bitmask") and release v2.4.0rc0. But unfortunately, the
workaround was added with commit 2cbaf0de223b ("tests: Work around tshark bug
in wpas_mesh_max_peering") instead of bringing a fix upstream.
Kind regards,
SvenAttachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
