All,
I'm trying to patch knemo to initialize with the Sys backend (as default) for the package. You have the option to set Nettools or Sys (kernel) providing network information to the monitor. Sys is much more efficient than Nettools, but only works for kernels >= 2.6 (which is everybody now). I wouldn't care or go to the effort is the Nettools backend still worked, but as of the Linux 3.0/3.1 kernels, (as well as later 2.6.X kernels) Nettools doesn't seem to work forcing the user to find and set the obscure setting to Sys before the module will work at all. I propose we make 'Sys' the default backend in TDE.
Hunting and picking through the code, I have found where the default values are set for the backend as well as the colors for the plotter graph. There were a couple of structs and constructors involved depending on how knemo was launched. I have created a patch that does both (1) set the default backend to sys and (2) change the graph colors a bit so it is readable regardless of whether there is a dark/light background shown.
Here is the patch, look it over, engage in discourse and if the yays are greater than the nays --> push it :) (works with gcc47 too :)
All,
I'm trying to patch knemo to initialize with the Sys backend (as default) for the package. You have the option to set Nettools or Sys (kernel) providing network information to the monitor. Sys is much more efficient than Nettools, but only works for kernels >= 2.6 (which is everybody now). I wouldn't care or go to the effort is the Nettools backend still worked, but as of the Linux 3.0/3.1 kernels, (as well as later 2.6.X kernels) Nettools doesn't seem to work forcing the user to find and set the obscure setting to Sys before the module will work at all. I propose we make 'Sys' the default backend in TDE.
Hunting and picking through the code, I have found where the default values are set for the backend as well as the colors for the plotter graph. There were a couple of structs and constructors involved depending on how knemo was launched. I have created a patch that does both (1) set the default backend to sys and (2) change the graph colors a bit so it is readable regardless of whether there is a dark/light background shown.
Here is the patch, look it over, engage in discourse and if the yays are greater than the nays --> push it :) (works with gcc47 too :)
-- David C. Rankin, J.D.,P.E.
Looks reasonable to me. As an aside I am fairly certain that Ubuntu patched sys to be the default backend some time ago, and we should probably just remove the nettools backend code entirely.
Long term it would be interesting to hook knemo into the TDE hardware library (which already monitors statistics via sysfs) to reduce code duplication.
Tim
On 04/18/2012 02:35 AM, Timothy Pearson wrote:
Looks reasonable to me. As an aside I am fairly certain that Ubuntu patched sys to be the default backend some time ago, and we should probably just remove the nettools backend code entirely.
Long term it would be interesting to hook knemo into the TDE hardware library (which already monitors statistics via sysfs) to reduce code duplication.
Tim
Thanks,
What knemo does better than any other application of its size it (1) provides an excellent tooltip with all network stats (available with only a hover over the systray icon), and (2) provides an excellent network graph that is well laid out and fairly configurable.
We may also want to enable the Text -> Top Bar setting as well by default. It adds a nice "(interface) in: out: " readout at the top of the graph. eg:
eth0: in: 539 K/s out: 128 K/s
The knemo code looks like a text-book c++ class based app with readable constructors/destructors, class members, etc.. so the base of knemo is in good shape.
Looks reasonable to me. As an aside I am fairly certain that Ubuntu patched sys to be the default backend some time ago, and we should probably just remove the nettools backend code entirely.
Long term it would be interesting to hook knemo into the TDE hardware library (which already monitors statistics via sysfs) to reduce code duplication.
This type of patch is an example of what I mean by providing usability testing. Patches always look reasonable, but my experience is theory and reality often clash. :)
Patches always work for the person proposing the patch, myself included. Therefore "works for me" is not a usability test plan. :) Not to mention the often subtle differences between distros: works on Debian and fails on Slackware.. :)
Others should be involved to validate functionality remains or improves.
What knemo does better than any other application of its size it (1) provides an excellent tooltip with all network stats (available with only a hover over the systray icon), and (2) provides an excellent network graph that is well laid out and fairly configurable.
We may also want to enable the Text -> Top Bar setting as well by default. It adds a nice "(interface) in: out: " readout at the top of the graph. eg:
eth0: in: 539 K/s out: 128 K/s
The knemo code looks like a text-book c++ class based app with readable constructors/destructors, class members, etc.. so the base of knemo is in good shape.
I never use knemo because of bug report 322, "knemo cannot distinguish between internet and intranet traffic."
I have a network here. I want to distinguish between intranet and internet traffic. My router does provide the internet numbers, so knemo then does not help me with respect to appreciating network traffic. There are many such tools and a simple vnstat/conky setup provides me local network information.
I don't know whether the DD-WRT router firmware can distinguish internet usage among all machines here. knemo would become more useful to me if the app could distinguish the difference. If I had only one machine here then there is no need for a distinction, of course. I'm sure many knemo users fit that description --- perhaps bug report (enhancement request) 322 is beyond the scope of the app.
Darrell
On 04/18/2012 02:24 PM, Darrell Anderson wrote:
I don't know whether the DD-WRT router firmware can distinguish internet usage among all machines here. knemo would become more useful to me if the app could distinguish the difference. If I had only one machine here then there is no need for a distinction, of course. I'm sure many knemo users fit that description --- perhaps bug report (enhancement request) 322 is beyond the scope of the app.
I think it can be easily done and I like the internal verses distinction. However, as your dd-wrt router probably also functions as your gateway, its iptables code can easily check internal/external at the point it sits on the network. For a client machine to do it, it would basically just have to filter packets and say:
if ip = mine; then it's local elif ip = myClassC subnet; then it's internal else it ain't local and it ain't internal, so it must be external.
I'm just not sure how 'authoritative' an app like knemo could be on making that determination - I'm no routing guru.
On 04/18/2012 02:24 PM, Darrell Anderson wrote:
I don't know whether the DD-WRT router firmware can distinguish internet usage among all machines here. knemo would become more useful to me if the app could distinguish the difference. If I had only one machine here then there is no need for a distinction, of course. I'm sure many knemo users fit that description --- perhaps bug report (enhancement request) 322 is beyond the scope of the app.
I think it can be easily done and I like the internal verses distinction. However, as your dd-wrt router probably also functions as your gateway, its iptables code can easily check internal/external at the point it sits on the network. For a client machine to do it, it would basically just have to filter packets and say:
if ip = mine; then it's local elif ip = myClassC subnet; then it's internal else it ain't local and it ain't internal, so it must be external.
I'm just not sure how 'authoritative' an app like knemo could be on making that determination - I'm no routing guru.
The local machine would need to be the gateway router in order to be authoritative on traffic source/destination. This is a corner case that probably should not be handled by TDE, as it is a rather stupid idea to run a GUI on your main gateway/firewall machines for security reasons.
Tim
The local machine would need to be the gateway router in order to be authoritative on traffic source/destination. This is a corner case that probably should not be handled by TDE, as it is a rather stupid idea to run a GUI on your main gateway/firewall machines for security reasons.
I remember years ago when I added my second computer. Good noob years as I started learning more about so many things computer related.
My choice then was to configure my primary machine as my gateway. Simple ip forwarding. I ran iptables on both machines. No set top router entered this picture for a long while thereafter. In that picture, the primary system was a desktop too.
In the past many years a common question I see is how to configure two computers as I described. Lots of people using old hardware and hand-me-downs and can't afford a set top router. Many lack experience and skills to configure a set top router or install improved firmware.
Many ISPs today impose bandwidth caps. Knemo on a gateway desktop can't provide the details users need to monitor those limits.
KNemo could fill those needs.
Corner case? Possibly.
Not demanding. Just talking out loud. :)
Darrell
On 04/18/2012 12:15 AM, David C. Rankin wrote:
Here is the patch, look it over, engage in discourse and if the yays are greater than the nays --> push it :) (works with gcc47 too :)
I've updated the patch to include the plotter 'TopBar' text to be enabled by default:
screenshot:
http://www.3111skyline.com/dl/dt/trinity/ss/knemo-plotter.jpg
(the topbar is the little readout of "eth0 in: out: " at the top)
New patch (attached):
-
Darrell Anderson -
David C. Rankin -
Timothy Pearson