> Mhh, I thought also some atheros drivers implement hardware multirate
> retry changes, which maps to this struct. Only one rate per frame
> would introduce a extreme additional communication overhead, which
> will make testing with standard wmediumd impractical. I think we need
> to keep such a
> I agree with that, but there exist also other code in hwsim, which is
>> tightly coupled with the mac80211 API, as e.g., the usage of
>> IEEE80211_TX_MAX_RATES, which already broke older versions of
>> wmediumd or similar implementations. Maybe a review regarding such
>> things would be good to
> I agree with that, but there exist also other code in hwsim, which is
> tightly coupled with the mac80211 API, as e.g., the usage of
> IEEE80211_TX_MAX_RATES, which already broke older versions of
> wmediumd or similar implementations. Maybe a review regarding such
> things would be good to
>> So I would propose to put the whole struct into the netlink messages,
> This is a terrible idea, since internal changes to this struct would
> break the userland API/ABI. hwsim seems perhaps less important than
> most APIs, but there is wmediumd etc. already.
I agree with that, but there exist
> So I would propose to put the whole struct into the netlink messages,
This is a terrible idea, since internal changes to this struct would
break the userland API/ABI. hwsim seems perhaps less important than
most APIs, but there is wmediumd etc. already.
> but I think that will break up the
Hi,
we are working on a sophisticated Wifi simulation framework based on
mac80211_hwsim. This includes the simulation of frame transmissions with
realistic channel access and channel conditions. Therefore we need
several information (e.g. long/short gi, usage of RTS/CTS, ...), which
are available
