I'm working on my code base and I was surprised by the fact, that the
type of the received signal strength for frames received via Netlink is
u32, but the actual struct ieee80211_rx_status.signal uses an s8 for signal.
I actually refer to this line:
https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/net/wireless/mac80211_hwsim.c#L3250
As we use the signal measurement in dBm (see
https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/net/wireless/mac80211_hwsim.c#L2764),
negative dBm values are totally reasonable as received signal strength.
Moreover, I don't really know, whether mac80211 or respectively minstrel
can do reasonable work with positive values.
Was this done intentionally ?
On the other hand this line
https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/net/wireless/mac80211_hwsim.c#L1276
inconsistently uses a negative value in the case of not using
netlink/wmediumd, which is a decent value.
I think it is not possible to easily switch to another type (e.g. s32 or
even s8) for the netlink attribute without breaking things, but somebody
might correct me.
We could do the hack and always negate the value of signal, since
positive signal strength values in dBm are practically impossible over
the air. Or I could simply use the corresponding u32 value, which will
map silently to the "right" negative s8 value, but it doesn't feel right :-)
Any suggestions?
kind regards
Benjamin Beichler
--
M.Sc. Benjamin Beichler
Universität Rostock, Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
University of Rostock, Department of CS and EE
Institute of Applied Microelectronics and CE
Richard-Wagner-Straße 31
18119 Rostock
Deutschland/Germany
phone: +49 (0) 381 498 - 7278
email: [email protected]
www: http://www.imd.uni-rostock.de/
On Mon, 2018-11-26 at 17:07 +0100, Benjamin Beichler wrote:
> I'm working on my code base and I was surprised by the fact, that the
> type of the received signal strength for frames received via Netlink is
> u32, but the actual struct ieee80211_rx_status.signal uses an s8 for signal.
>
> I actually refer to this line:
> https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/net/wireless/mac80211_hwsim.c#L3250
I guess this should use nla_get_s32 now, but I think that didn't exist
before and it also doesn't really matter since if you have a negative
value in a u32 it still works just fine as long as userspace and
kernelspace agree on the 2's complement representation :-)
> As we use the signal measurement in dBm (see
> https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/net/wireless/mac80211_hwsim.c#L2764),
> negative dBm values are totally reasonable as received signal strength.
> Moreover, I don't really know, whether mac80211 or respectively minstrel
> can do reasonable work with positive values.
Indeed. Make it negative.
> On the other hand this line
> https://elixir.bootlin.com/linux/v4.20-rc4/source/drivers/net/wireless/mac80211_hwsim.c#L1276
> inconsistently uses a negative value in the case of not using
> netlink/wmediumd, which is a decent value.
Sure, it should be negative.
> I think it is not possible to easily switch to another type (e.g. s32 or
> even s8) for the netlink attribute without breaking things, but somebody
> might correct me.
Well, u32 and s32 are really identical in netlink anyway, they're just 4
bytes long integers. So there's no "switching" if we now write
"nla_get_s32" in the code.
What we might want to do is use a policy now that says it must be a
sensible value like -200 to -10 or something, but it doesn't really
matter.
> Any suggestions?
Just put a negative integer there in your userspace.
(u32)-50 == 0xffffffce
signal = nla_get_u32(...) = 0xffffffce
-> signal will end up with -50
Nothing to see here, move along ;-)
johannes