[PATCH 06/44] FT: add IEEE vlan support (including tagged vlans)

[Jouni Malinen]

On Wed, Feb 24, 2016 at 12:53:12PM +0100, michael-dev at fami-braun.de wrote:
> This introduces set_vlan and get_vlan callbacks for wpa_auth
> and uses them to fetch and configure vlan of sta.
> The struct vlan_description is converted into a network encoding
> (struct ft_vlan) for byter order reasons.

struct ft_vlan is used to define a fixed message format in addition to
using it elsewhere in the implementation with all the users having to
know the byte order. This does not look desirable. I'd use a variable
with host byte order elsewhere and convert to the specific byte order
only when building the message. Furthermore, I would prefer not to have
a struct with a struct defined a fixed message format, like the one
here:

>  struct ft_r0kh_r1kh_resp_frame {
>  	u8 frame_type; /* RSN_REMOTE_FRAME_TYPE_FT_RRB */
> @@ -78,13 +88,14 @@ struct ft_r0kh_r1kh_resp_frame {
>  	u8 pmk_r1[PMK_LEN];
>  	u8 pmk_r1_name[WPA_PMK_NAME_LEN];
>  	le16 pairwise;
> +	struct ft_vlan vlan;
>  	u8 pad[FT_R0KH_R1KH_RESP_PAD_LEN]; /* 8-octet boundary for AES block */
>  	u8 key_wrap_extra[8];
>  } STRUCT_PACKED;


This all said, this is the first patch in the series that seems to break
backwards compatibility with earlier hostapd implementation of the
AP-to-AP messages for FT pull/push operations. Taken into account the
issues in extending this fixed message design, I don't think we should
be doing this. If we are willing to declare that there is no backwards
compatibility on this between the version that comes out of this series
and what existed before, we might as well clean this up now and make the
definition extensible, e.g., with a use of TLVs and the receiver
ignoring TLVs that it does not recognize.

In other words, I'm going to drop this patch and all the following
patches that are dependent on changes to these R0KH-R1KH pull/push
messages. I'd like to see a patch to convert the current message format
to an extensible TLV format and these dropped patches rebased on top of
that to confirm that the protocol extensibility in the new design works.

-- 
Jouni Malinen                                            PGP id EFC895FA