On Mon, Sep 08, 2008 at 08:43:23PM -0700, David Miller wrote:

quoted text
> If we're talking about the netlink emission of WEXT blobs, then such
> bits cannot be fixed unfortunately, because via netlink we don't know
> in the message generating context what kind of process will receive
> the message.

OK. Interesting point here is that the old code was using IWEVCUSTOM
which is defined as having header_type IW_HEADER_TYPE_POINT and so are
the new IWEVASSOCREQIE and IWEVASSOCRESPIE. The only difference is in
max_tokens specifying different maximum length for the data. Maybe the
old code was also broken, but wpa_supplicant handled the bogus data
without causing problems (text parsing failing instead of some
parameters being set based on bogus binary data).

quoted text
> In fact, when broadcasting a netlink message, applications of different
> dispositions can want to receive the message.
> 
> So in essence netlink cases cannot be fixed for COMPAT handling,
> rather, netlink protocols must be designed to be COMPAT agnostic from
> the beginning, and use fixed sized types only.  WEXT was not.

I haven't looked how IW_HEADER_TYPE_POINT headers get encoded with
wireless_send_event(), but it sounds likely something there gets
different field size. It sounds like there is not really a good
solution for this with the current iw event types and should we want to
get the original issue fixed, something new would need to be
specified.. Would people be fine with extending wireless_send_event()
with new event types that use fixed sized fields or is someone going to
be interesting in providing a better replacement for this functionality?

-- 
Jouni Malinen                                            PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html