Reading the RSSI from a Kernel Module

Reading the RSSI from a Kernel Module

[Tim Schneider]

Hi,

I am trying to write a Kernel Module with an implementation of a new  
TCP-Algorithm. Since I need to know the RSSI-Value (Received Signal  
Strength indication) of the sent package, I extended the Pluggable  
Congestion Control Mechanism by a new function which is called right  
after the package is send. At that point, I need to read the RSSI-Value.

I'm now trying to somehow access that value, but I can't figure out  
how. I've come as far, that I found out about the Wirelless  
Extensions, which seem to be very promising. In the header file the  
author states, that this mechanism can be used by both user-space apps  
and kernel modules. Unfortunately nobody seems to ever have used it in  
kernel space, since I can't find any documentations about it. I've  
already asked this question on the netdev mailing list. They told me,  
that there is a new system  with a netlink based cfg80211/nl80211  
interface in development right now , which is supposed to replace the  
wireless extensions in the future. They also told me, that this would  
probably be the correct mailing list for this kind of question.

I would be very glad, if somebody could give me link to a page  
containing informations about this topic, or even just a hint that  
could help me.

Thank you

Tim Schneider

Re: Reading the RSSI from a Kernel Module

[Richard Farina]

Tim Schneider wrote:
> Hi,
>
> I am trying to write a Kernel Module with an implementation of a new 
> TCP-Algorithm. Since I need to know the RSSI-Value (Received Signal 
> Strength indication) of the sent package, I extended the Pluggable 
> Congestion Control Mechanism by a new function which is called right 
> after the package is send. At that point, I need to read the RSSI-Value.
>
> I'm now trying to somehow access that value, but I can't figure out 
> how. I've come as far, that I found out about the Wirelless 
> Extensions, which seem to be very promising. In the header file the 
> author states, that this mechanism can be used by both user-space apps 
> and kernel modules. Unfortunately nobody seems to ever have used it in 
> kernel space, since I can't find any documentations about it. I've 
> already asked this question on the netdev mailing list. They told me, 
> that there is a new system  with a netlink based cfg80211/nl80211 
> interface in development right now , which is supposed to replace the 
> wireless extensions in the future. They also told me, that this would 
> probably be the correct mailing list for this kind of question.
>
I don't mean to make this a flame so please do not take it that way.  
How exactly do you expect to get the RECEIVED Signal Strength indication 
for a packet which you are SENDING? If you send it, you don't receive it...

Just my 0.02

-Rick Farina
> I would be very glad, if somebody could give me link to a page 
> containing informations about this topic, or even just a hint that 
> could help me.
>
> Thank you
>
> Tim Schneider
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Reading the RSSI from a Kernel Module

[Richard Farina]

Tim Schneider wrote:
>
> Am 13.07.2009 um 08:59 schrieb Richard Farina:
>> I don't mean to make this a flame so please do not take it that way.  
>> How exactly do you expect to get the RECEIVED Signal Strength 
>> indication for a packet which you are SENDING? If you send it, you 
>> don't receive it...
>>
>> Just my 0.02
>>
>> -Rick Farina
>
> Hi Rick,
>
> as far, as I understood, the RSSI-Mechanism also displays the signal 
> strength of the just sent package. I figured there was some way the 
> MAC-Layer transported that information, but you're right, I could be 
> mistaken. Anyways, since I'm trying to implement a TCP Algorithm, i 
> definitely have a  two-way connection. Assuming, that the route back 
> is going to be the same as it was on the way there (which basically 
> should be true, based on the Routing algorithms we're using in our 
> wireless mesh network), I could just use the RSSI Value of the 
> received ACK.
>
Any RSSI on a sent packet will be a calculated number not an observed 
number and as such it will be completely pointless for any kind of rate 
control algorithm.  Assuming that the card could actually receive the 
packets it is sending (which it can't) then you would be observing a 
24dBm signal (for instance) with 0 patch loss and your RSSI would be at 
or above max.  Realistically you can assume that every packet you sent 
has a max RSSI on your end because you are the one transmitting it.  
Now, if you want to know what the RSSI on the receiver side is that is a 
completely different question, one which you cannot answer at all. When 
you send a packet you do not have the good fortune to know what RSSI the 
receiver got.  You can roughly assume based on your RSSI when you get an 
ACK, but honestly that isn't even close to correct because every packet 
has a very unique experience in the air and you cannot assume things 
like the same tx power and rx sensitivity will be the same on both 
ends.  There is some 802.11 protocol (the letter eludes me at present) 
which is in draft form which adds information to packets so that both 
ends know each other's RSSI, but I have never seen it implemented 
anywhere yet.

I advise you keep the discussion on list as I am by no means an expert 
and many people much better at this than I may respond.

-Rick Farina
> Regards,
>
> Tim Schneider
>
>

Re: Reading the RSSI from a Kernel Module

[Tim Schneider]

I did some research on the subject, and it seems that you are right.  
The RSSI Value can only be read at the receiving end. This does make a  
lot of sense, but I read a paper about the Algorithm I am trying to  
implement, and the Author stated it would be possible to read the RSSI- 
Value at the senders end. Since the author is a professor at a German  
university, I figured he knew what he was talking about. I reworked my  
way through the Paper and realized, that there is another thing that  
you can't just read at the senders end. He uses the hopcount of the  
connection for his calculations. That's an Information that is  
actually impossible to get without the support of the routing-layer.  
Since I need to modify the routing-layer anyways now, I'll just modify  
it in a way, so that I can read the RSSI-Information of the first hop  
too.

Thank you for your help.

Tim Schneider

Am 13.07.2009 um 13:57 schrieb Richard Farina:

> Tim Schneider wrote:
>>
>> Am 13.07.2009 um 08:59 schrieb Richard Farina:
>>> I don't mean to make this a flame so please do not take it that  
>>> way.  How exactly do you expect to get the RECEIVED Signal  
>>> Strength indication for a packet which you are SENDING? If you  
>>> send it, you don't receive it...
>>>
>>> Just my 0.02
>>>
>>> -Rick Farina
>>
>> Hi Rick,
>>
>> as far, as I understood, the RSSI-Mechanism also displays the  
>> signal strength of the just sent package. I figured there was some  
>> way the MAC-Layer transported that information, but you're right, I  
>> could be mistaken. Anyways, since I'm trying to implement a TCP  
>> Algorithm, i definitely have a  two-way connection. Assuming, that  
>> the route back is going to be the same as it was on the way there  
>> (which basically should be true, based on the Routing algorithms  
>> we're using in our wireless mesh network), I could just use the  
>> RSSI Value of the received ACK.
>>
> Any RSSI on a sent packet will be a calculated number not an  
> observed number and as such it will be completely pointless for any  
> kind of rate control algorithm.  Assuming that the card could  
> actually receive the packets it is sending (which it can't) then you  
> would be observing a 24dBm signal (for instance) with 0 patch loss  
> and your RSSI would be at or above max.  Realistically you can  
> assume that every packet you sent has a max RSSI on your end because  
> you are the one transmitting it.  Now, if you want to know what the  
> RSSI on the receiver side is that is a completely different  
> question, one which you cannot answer at all. When you send a packet  
> you do not have the good fortune to know what RSSI the receiver  
> got.  You can roughly assume based on your RSSI when you get an ACK,  
> but honestly that isn't even close to correct because every packet  
> has a very unique experience in the air and you cannot assume things  
> like the same tx power and rx sensitivity will be the same on both  
> ends.  There is some 802.11 protocol (the letter eludes me at  
> present) which is in draft form which adds information to packets so  
> that both ends know each other's RSSI, but I have never seen it  
> implemented anywhere yet.
>
> I advise you keep the discussion on list as I am by no means an  
> expert and many people much better at this than I may respond.
>
> -Rick Farina
>> Regards,
>>
>> Tim Schneider
>>
>>
>