netstats_l2: cc2538 (and at86rf2xx fixes)

[smlng]

add layer2 netstats to cc2538 and minor correction in at86rf2xx.

[PeterKietzmann]

@smlng would you mind splitting the at86rf2xx part into a separate commit? ACK for the changes in general. @cgundogan would you give it a quick try? Maybe at the Hack'n'ACK?!

[smlng]

@PeterKietzmann the at86rf2xx corrections are in a seperate commit, just not in a new PR - but I don't think thats needed here.

[alignan]

👍

[PeterKietzmann]

ACK and go

[OlegHahm]

Hm, I disagree with the at86rf2xx "fix".

1. Data that was received on L2 should go into statistics, whether it can be processed or not.
2. A preprocessor line must always start with a #, i.e. no preceding white spaces are allowed.

[smlng]

@OlegHahm

1. I understand your concerns, but contrary to Linux' ip -s -s link we currently have no (distinct) RX errors - and this definitely is a receive error not a success.
2. my editor tricked me into this, for cc2538 cc2538: Minor indentation fix #5995 corrects this - should be done here, too. But only if we don't revert this anyways

[OlegHahm]

I understand your concerns, but contrary to Linux' ip -s -s link we currently have no (distinct) RX errors - and this definitely is a receive error not a success.

From the L2 perspective I would argue that it is a success - otherwise the packet would not be passed to the driver.

[smlng]

In general I would agree; but I would argue that from the RIOT perspective I would say L2 ends when the packet passes out of grnrc_netdev2_ieee802154.c, or not? That way, netstat could (should) be captured in netdev2?

[PeterKietzmann]

Hi! Sorry for merging this too fast. About the leading white spaces in the preprocessor lines, I have completely overlooked them. About the position of the rx byte counter I do understand both of your argumentations. When I reviewed this I was thinking about what I would assume as a user of these statistics and that was actually "how many bytes have successfully been received by the driver". That's why I gave my ACK. On the other hand I see Olegs concerns which might allow for easier troubleshooting. If we go with the change in this PR I agree that it might be reasonable to think about moving to grnrc_netdev2_ieee802154.c

[OlegHahm]

The best solution would be probably to properly specify and document what these statistics mean.

[PeterKietzmann]

@OlegHahm this seems reasonable. But I think we should first agree on what we want them to mean: (i) complete number bytes received, including later removed ones from malformed frames or (ii) number of successfully received bytes by the driver. IIRC you wrote the initial support for L2 statistics so I'd like to leave the decision up to you :-)!

[smlng]

I'd like to point out here that for Linux/Unix experienced user or developer these stats might be more intuitive (to understand) if they mean (and capture) the same as on Linux, i.e., ip -s -s link as already referenced above.

[OlegHahm]

@smlng, agreed. Can you (i) provide documentation of the meanings of the statistics for iproute2 and (ii) provide a PR with the missing netstats?

[OlegHahm]

@PeterKietzmann, okay, let's have a discussion on the mailing list.