Node dump functionality for metrics (LQI, RSSI, RX and TX stats)

[Stefan-Schmidt]

Get some node metrics information out of the transceiver hardware to be used for userspace for decision in RPL for example. Similar to station dump in wireless.

[zmingshi]

Hi,
If the node dump functionality for metrics is available for use?
Thank you!

[Stefan-Schmidt]

Nobody did any work on it yet. Its still an open issue.

[zmingshi]

Ok, If there is an easy way to access these metrics?

[Stefan-Schmidt]

As long as we have now abstracted way to get them from the kernel subsystem these values are completely driver specific. You would need to get the transceiver datasheet, look up the registers or other ways to get it and extend the driver to provide you the value in some way (sysfs, debugfs, etc). There is definitely coding on the driver level involved. Not sure if you count that as easy.

[alexaring]

Additional these information are useful in combination from which node (indicated by address) was received from. Without this information you can just dump the values from latest received frame.

Depends on your use-case if this is okay for you.

[mcr]

What I really want for metrics is to be able to pull them out of the neighbour cache. So there are really five things to do:

1. collect TX success rates to the neighbour by looking at LL ACKs and number of retries. Essentially, ETX = TX attempts / TX successes, except not using floating point. (i.e. let user space do the division).
2. collect RX signal strength if device can give it to us.
3. store these things into some extension of the neighbour cache. This is most controversial (i.e. requires negotiation with netdev).
4. return extension netlink socket replies for neigh cache enumeration (in some ways, this is the easiest thing, as netlink is designed to be very extensible)
5. provide IP_layer setsockopt() such that signal strength of received packet is provided in auxiliary data. Permit TX power level to be set by userspace. There is work in mac80211 to support this I think.

[zmingshi]

Thank you for your useful answers @Stefan-Schmidt @alexaring , I'll have a try.

[alexaring]

@mcr with neighbour cache you mean L2 cache (own implementation over nl802154) or L3 cache (neighbor discovery over rtnl)?

What we like to have is a L2 cache, maybe in combination with RTNL IPv6 neighbor discovery cache you can do some mapping between L3 address and L2 address.

btw: if we have support also to dump the short address over "ip -6 neigh". Also a short address is unique in combination with pan_id only. So the address need to be some concat with short+pan, I think.

[zmingshi]

Hi,
In my case, I have two openlabs 802.15.4 radio. First, I'd like the two radio could continuously communicate with each other; Then, I'd like to retrieve RSSI, LQI, and some other stats continuously during the communication.

Currently I have some problems for the first issue.
I refer to the at86rf233 datasheet. In Appendix A, it says the chip could offer a Continuous Transmission Test Mode. I think the mode could support my first issue, that could make the two radio communicate continuously. But, I'm not sure how can I enable the mode. If I can enable the mode through modifying the driver code at86rfa33.c?
Hope you could give some suggestions, thank you all!

[alexaring]

Look like wireless dealing with such TESTMODES, then make the same for nl802154, see:
http://lxr.free-electrons.com/source/net/wireless/nl80211.c#L7689

Finally, send-patches.

Thanks

[zmingshi]

Sorry for the request, I'm not familiar with nl80211, nl802154 and some other things about kernel. I don't think I could do the TESTMODES for nl802154 in short time. I need a temporary workaround for my case.

In Appendix A of at86rf233 datasheet, it just requires to make some configurations for registers. Is there any other easy way to realize my case? I just need the two openlabs radio could communicate continuously.
Maybe I also need the two radio could operate in Extended Operating Mode, in which FCS check, ACK frame, Retransmission could support.

Thank you very much for any help!

[Stefan-Schmidt]

@zmingshi, this github issue is about node dump functionality not about any specific at86rf test modes. Please either open a new issue on github to discuss this further or write a mail to the linux-wpan mailing list.

[zmingshi]

Hi,

Currently I have add some codes on at86rf driver, and make it provide rssi and LQI using debugfs. But, I still have some difficulties, hope you could give some suggestions

1. the debugfs refresh the rssi and LQI values every time a new frame is received. Maybe you know that I use seq_printf() to output the values in a file, I wander if it could provide append mode so that the file includes not only current metric values but also older ones
2. I also need retry counter value, I think lp->tx_retry is the frame_retries, but I don't know clearly where I should read the value in the code, I tried several times, but failed, do you have some ideas?
   For the retry counter value, I also tried to define the register 0x19 in code, which I think could record the frame_retries, I make some tests and this way seems work, as I see the changes of frame_retries. Do you think this is a reliable way to get the retry counter?

Thank you all!
Best regards.

[alexaring]

while true
do
echo "date: cat $PATH_TO_FILE" >> $LOGFILE
#or handle in kernel it will be read ready when new values are there
sleep $INTERVALL
done

lp->tx_retry is not the max_frame_retries. This is the retry value to going into TX_ARET mode WITHOUT doing a force change. We have some retries there, if currently a receiving is in progress then it will not be aborted. A force state change will do that.

The max_frame_retries are setable via wpan-tools "max_frame_retries", be sure that ack request bit will be set otherwise this setting have no sense.

[zmingshi]

Thank you for the reply.

1. I also thought the cat command, but the $INTERVALL is hard to decide, as the fixed interval value could not ensure that all the updated values could be read. I have tried, it will miss some value.
   What do you mean by the saying "#or handle in kernel it will be read ready when new values are there"? How can I handle it in kernel? I think it may work if it could be done in the kernel.
2. I'm not mean the max_frame_retries, I know it could be set via wpan-tools. What I mean is the actual retry value for a frame being successfully received. Of course, when a frame is tried to transmit for max_frame_retries times, and still not being received, the retry value should be max_frame_retries.
   I think it is recorded in register 0x19, in which ARET_FRAME_RETRIES should be the retry value, is it? I also think the lp->tx_retry should be the same to ARET_FRAME_RETRIES just before a new frame is about to be sent and lp->tx_retry is not be reset to 0.

Also, the ack request bit can not be set, when I tried the command iwpan dev wpan0 set ackreq_default 1, error occurs: command failed: Operation not supported (-95). So, the command is not supported now?

[alexaring]

The kernel can report when the file is readable, until that read(2) will block. So you can run a cat on a file and if there is a new value you can save it... at least you will also lost some values because you don't queue them inside the kernelspace.

I don't want to tell you workarounds anymore for a non-mainline solution. I already told you the mainline solution would be what wireless do with a netlink interface to dump the neighbours.

This handling "how much retries was necessary to got an ACK" is part of transceiver side. You can't get this values, what you can get is the TRAC_STATUS, if it reaches ABOVE max_frame_retires or CSMA-CA retries.

According the -EOPNOTSUPP - update your kernel.

[zmingshi]

Sorry to answer your reply so late ! @alexaring
What's the meaning by saying "According the -EOPNOTSUPP"? I really want to update my kernel, its version is 4.1 now.
I tried to configure tx_power by iwpan, but it failed. If it is as my kernel is not updated?
Thank you!

[alexaring]

Yes, as you can see it here:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/net/ieee802154/nl802154.c?id=refs/tags/v4.1.21

no tx power functionality. You can backport it or update the kernel.

• Alex

[zmingshi]

My kernel is v4.1.15. That means my kernel should be updated. I still have no idea about how to update the kernel (v4.1.15 ->v4.1.21)? As I'm a beginner for Linux kernel, would you mind to tell me how to update it in more detail? Thank you very much!

Is there any way to change the tx_power value? I tried to find where to initialize the tx_power in kernel, but I couldn't find it.

[alexaring]

(v4.1.15 ->v4.1.21)? -> should contain only fixes, no new features... it's a stable release.

Change tx value -> yes hack it into hw_init of at86rf230 driver.

Update kernel -> I can't help you, google it.

[zmingshi]

Hi, how can I join the linux-wpan mailing list? I have tried to email to [email protected], but the email was refused.
I'd like to join the list to learn more about linux-wpan.
Thank you all!

[alexaring]

http://vger.kernel.org/majordomo-info.html

[darkfader]

Hi all. I too want to have some metrics. I currently use netlink to get neighbour state, but that doesn't give me much to work with when trying to do RPL routing. (usermode, route-over for now)

I did add some debug output (in mrf24j40.c) that shows LQI and RSSI for received packets. (hmm.. should go into NL802154_NODE_INFO_ATTR_* or something?)
Eventually I also want to check for MRF24J40_TX_ERR_MAXRETRY error to get some ETX value out of it, but I'd need to create an extra SPI transfer I think. (I'm not so good with drivers yet)

I could use sysfs for now and dump some of the latest seen neighbours; I already tried creating a sysfs file to enable/disable debug toggle. But if I can't get a decent output that uses the additional neighbour info, that wouldn't make me happy.

[titobrasolin-ke]

It's been a long time since the last comment on October 24, 2017, so I thought it might be helpful to mention that the LQI has been available to userspace applications since 2018: torvalds/linux@811e299

[alexaring]

Hi,

thanks for your comment. Yes you can use that cmsg field to track some LQI values, that requires an all-time user space daemon and you getting all frames and parse them to kind of create a database for each node you want to track the LQI values. Also track the short/extended address mapping.

The idea is to move something like such nodes stats in the kernel that you can dump periodically with hopefully newer recent LQI values and you can do some heuristic in userspace to make some sense out of this weird value with maybe combine it with more other values that this nodes stats have e.g. ack errored frames, etc. :-)