Hi everyone,
I wanted to extend LED color based on bandwidth usage for LAN0-5 on my Turris Omnia with TurrisOS 5.1.9 . Unfortunately, this did not work. (It actually does work, but let me continue …)
The code for LED color based on bandwidth usage accesses /proc/net/dev and compares bytes/packets transfered to a previous value in a loop.
For testing purposes I transferred multiple gigabytes from my server (connected to LAN0) to my laptop (connected to LAN3) and vice versa.
However, the byte/packet count printed by # cat /proc/net/dev | grep lan3 did not significantly change in the range of multiple gigabytes.
Also I observed, that during the transfer of multiple gigabytes the Realtime Graph (LuCI -> Status -> Realtime Graphs -> Traffic -> lan3) does not indicate the traffic.
When I perform a speed test (against one of those speed test sites on the internet) the traffic is indicated in the Realtime Graph and also # cat /proc/net/dev | grep lan3. The LED color also changes (if configured accordingly) (therefore: LED color based on bandwidth usage works! 
).
Looking at Turris Documentation -> Hardware -> Omnia -> About -> Network interfaces I suppose, that
- traffic “crossing” the switch chip (e.g. WAN -> eth2 -> eth0 -> Port5 -> Port3 -> LAN3) is counted
- traffic “routed” within the switch chip is not counted (e.g. LAN0 -> Port0 -> Port3 -> LAN3)
Questions:
- Is my assumption correct?
- Is this behavior documented somewhere? If so, where?
- Is there a solution to the issue illustrated above? How can I monitor the activity on a specific LAN port?
If this has been discussed/solved, I am happy about a link to the topic/site (as my search was not successful).
Thanks you in advance.
Somewhere around Turris OS 5.1, they switched to using the Distributed Switch Architecture - https://www.kernel.org/doc/html/latest/networking/dsa/dsa.html
The Omnia uses the MV88E6085 chipset
This means you can now see traffic per port when that traffic has to pass through the Omnia’s CPU. However, as you’ve found, when traffic is direct between switch ports, it does not pass through the CPU and does not get included in the counters in /proc/net/dev.
Looking at the output of ethtool -S lan2, I believe the stats you are looking for are in the in_good_octets and out_octets columns. The tx_bytes and rx_bytes stats match the bytes transferred in /proc/net/dev
Thank you very much!
Oh no, it’s DSA again. 
I installed ethtool (opkg update , opkg install ethtool) and tried your suggestion.
I can confirm that in_good_octets and out_octets contain the desired values.
Within the next days I will try to adapt the script from LED color based on bandwidth usage to use ethtool instead of /proc/net/dev.
I was wondering - maybe you (or someone else) know - how TurrisOS or OpenWrt address this issue (if at all). As far as I know, the Realtime Graphs are a default feature in OpenWrt. Apparently (I did not research in this) those access /proc/net/dev, too, as they do not indicate traffic between switch ports.
1 Like
@dpdrown Thanks again for the suggestion to use ´ethtool´ . The adapted Lua script now works. See LED color based on bandwidth usage for details.
Side note: ethtool -S creates different outputs depending on the interface. E.g. in_good_octets and out_octets do not exist for eth2. For eth2 those are called good_octets_received and good_octets_sent.
Any idea on the Realtime Graphs?
I have an example realtime graph extension here: https://github.com/ddrown/omnia-wifibusy-realtime
It should be possible to take that and convert it to polling ethtool for the interface counters