netspeed applet will not measure wired

The 'greyed out' Network device combo-box is due to:

gtk_widget_set_sensitive(applet->network_device_combo, !applet->auto_change_device);

The setting is controlled by the "Always monitor a connected device, if possible". Un-ticking this option will enable the Network device combo-box.

From our additional discussion on IRC #ubuntu+1 here's some further information.

When src/netspeed.c::update_applet() is called (controlled by the gconf refresh_time setting) it calls src/backend.c::get_device_info(). This in turn calls:

 glibtop_get_netload(&netload, device);

to obtain the information for "device" (e.g. eth0, wlan0, etc.).

There was a recent (17 Feb 2009) upstream update (bug #330571) to the package:

libgtop2 (2.25.91-0ubuntu1)

This might be the cause.

I've uploaded a test debug package to my PPA for you to gather more information. To capture the debug information you need to use a 'trick' which I'll detail here.

1. Install the package

2. Kill (don't remove) the running version but *don't* press any button the resulting "reload applet" button!

killall netspeed_applet2

3. Start a xterminal and start the applet manually:

/usr/lib/netspeed/netspeed_applet2

This is where the debug output will be seen

4. Now press the "Reload" button so the applet goes into the panel.

The applet will write information to STDERR about the data returned from glibtop_get_netload(). E.g.

/usr/lib/netspeed/netspeed_applet2
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 1, bytes_out 7426924648, bytes_in 300543358
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 1, bytes_out 7426924648, bytes_in 300543358
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 1, bytes_out 7426926470, bytes_in 300545617

To stop the applet use the interrupt (Ctrl+C).

I upgraded, and once i added a new one, it didnt detect my wired connection (the only one I'm using right now).
I force to manually use wired and still it failed to measure traffic

$ /usr/lib/netspeed/netspeed_applet2
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12821953, bytes_in 228127882
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12821953, bytes_in 228127882
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12822085, bytes_in 228128534
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12822085, bytes_in 228128534
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12822843, bytes_in 228128534
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12822843, bytes_in 228128534
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12824147, bytes_in 228129607
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12824147, bytes_in 228129607
** (netspeed_applet2:7724): DEBUG: enter
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
** (netspeed_applet2:7724): DEBUG: updating tooltip
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12824147, bytes_in 228129607
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12824147, bytes_in 228129607
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
** (netspeed_applet2:7724): DEBUG: updating tooltip
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12824592, bytes_in 228129940
get_device_info() calling glibtop_get_netload(&netload, wlan2)
  up 0, running 0, bytes_out 0, bytes_in 0
get_device_info() calling glibtop_get_netload(&netload, eth0)
  up 1, running 0, bytes_out 12824592, bytes_in 228...

On Mon, 2009-03-16 at 10:04 +0000, BUGabundo wrote:
> I upgraded, and once i added a new one, it didnt detect my wired connection (the only one I'm using right now).
> I force to manually use wired and still it failed to measure traffic

I suspect your description may be confusing the issue here, so sorry if
I question it. Let's address the points so I am sure I understand
completely.

1. My interpretation of "...it didn't detect..." means the applet does
not offer the wired connection in the list of devices in the preferences
dialog.

2. However, from the debug trace I can see that the wired connection
*is* reporting data so should I understand you to mean "the applet does
not auto-detect the only currently running interface - which is eth0 -
but when I disable automatic detection I can choose the wired connection
from the 'Device names' combo-box ?

3. In automatic-detection mode which interface does the applet report
information? Does that information include data throughput?

Now we've got that sorted out, lets get to the good news :)

The trace log you've attached is showing that data through-put for eth0
*is* being reported:

> get_device_info() calling glibtop_get_netload(&netload, eth0)
> up 1, running 0, bytes_out 12821953, bytes_in 228127882
> get_device_info() calling glibtop_get_netload(&netload, wlan2)
> up 0, running 0, bytes_out 0, bytes_in 0

However, look at the "running" value. It should be showing "1" for an
in-use interface but for some reason isn't.

The 'running' flag is used internally by the applet to detect the
'active' device. If no device is running then, from what I can recall
from the source-code, it won't try to measure traffic.

So, is there *anything* unusual about the PC's networking configuration?
Things like, is the interface configured manually? Is NetworkManager
managing the interface? If we can discover why all the interfaces are
reporting running = 0 we might solve the issue for netspeed.

This issue may be related to upstream libgtop re-working the struct glibtop_netload

http://bugzilla.gnome.org/show_bug.cgi?id=565096

and netspeed applet not using the latest upstream source (see bug #268727).

On Monday 16 March 2009 16:46:49 TJ wrote:
> So, is there anything unusual about the PC's networking configuration?
> Things like, is the interface configured manually? Is NetworkManager
> managing the interface? If we can discover why all the interfaces are
> reporting running = 0 we might solve the issue for netspeed.

all normal and Auto on the NM side

--
Hi, I'm BUGabundo, and I am Ubuntu (whyubuntu.com)
(``-_-´´) http://LinuxNoDEI.BUGabundo.net && Ubuntu LoCoTeam Portugal http://ubuntu-pt.org
Linux user #443786 GPG key 1024D/A1784EBB

I want to test the flags being returned by the IOCTL call to the socket. I've written a minimal C program to do that. You can either compile the attached source or, if you'd prefer, I can provide a binary. Try it on all your network interfaces.

gcc -o socket-flags socket-flags.c

for dev in /sys/class/net/*; do ./socket-flags ${dev##*/}; done

eth0 SIOCGIFFLAGS 0x1043 ( IFF_UP (0x1) IFF_BROADCAST (0x2) IFF_RUNNING (0x40) IFF_MULTICAST (0x1000))
lo SIOCGIFFLAGS 0x49 ( IFF_UP (0x1) IFF_LOOPBACK (0x8) IFF_RUNNING (0x40))
pan0 SIOCGIFFLAGS 0x1002 ( IFF_BROADCAST (0x2) IFF_MULTICAST (0x1000))
tun0 SIOCGIFFLAGS 0x10d1 ( IFF_UP (0x1) IFF_POINTTOPOINT (0x10) IFF_RUNNING (0x40) IFF_NOARP (0x80) IFF_MULTICAST (0x1000))
wlan0 SIOCGIFFLAGS 0x1043 ( IFF_UP (0x1) IFF_BROADCAST (0x2) IFF_RUNNING (0x40) IFF_MULTICAST (0x1000))
wmaster0 SIOCGIFFLAGS 0x1043 ( IFF_UP (0x1) IFF_BROADCAST (0x2) IFF_RUNNING (0x40) IFF_MULTICAST (0x1000))

What we are looking for is the IFF_RUNNING flag defined in /usr/include/net/if.h:

    IFF_RUNNING = 0x40, /* Resources allocated. */

$ for dev in /sys/class/net/*; do ./socket-flags ${dev##*/}; done
eth0 SIOCGIFFLAGS 0x1003 ( IFF_UP (0x1) IFF_BROADCAST (0x2) IFF_MULTICAST (0x1000))
lo SIOCGIFFLAGS 0x49 ( IFF_UP (0x1) IFF_LOOPBACK (0x8) IFF_RUNNING (0x40))
wlan2 SIOCGIFFLAGS 0x1002 ( IFF_BROADCAST (0x2) IFF_MULTICAST (0x1000))
wmaster0 SIOCGIFFLAGS 0x0 ()

Well there is the evidence that there's something unusual on that system unrelated to netspeed.

You can clearly see that according to the network IOCTL flags, etho isn't running (IFF_RUNNING).

So, what's the PCI [vendor:product] of the network device, which driver is managing it (lspci -vvnn -d ...), and what kernel version is it (uname -a). Also, are there any custom udev or networking settings?

For reference, I've discovered a linux-netdev mailing-list article describing this and an underlying change to the way the IFF_RUNNING flag is used from March 2006.

http://marc.info/?l=linux-netdev&m=122922534630000&w=2

commit b00055aacdb172c05067612278ba27265fcd05ce
Author: Stefan Rompf <email address hidden>
Date: Mon Mar 20 17:09:11 2006 -0800

    [NET] core: add RFC2863 operstate

    this patch adds a dormant flag to network devices, RFC2863 operstate derived
    from these flags and possibility for userspace interaction. It allows drivers
    to signal that a device is unusable for user traffic without disabling
    queueing (and therefore the possibility for protocol establishment traffic to
    flow) and a userspace supplicant (WPA, 802.1X) to mark a device unusable
    without changes to the driver.

    It is the result of our long discussion. However I must admit that it
    represents what Jamal and I agreed on with compromises towards Krzysztof, but
    Thomas and Krzysztof still disagree with some parts. Anyway I think it should
    be applied.

    Signed-off-by: Stefan Rompf <email address hidden>
    Signed-off-by: David S. Miller <email address hidden>

So, on the face of it looks as if no user-space application should rely on IFF_RUNNING.

$ uname -a
Linux blubug 2.6.28-9-generic #31-Ubuntu SMP Wed Mar 11 15:43:49 UTC 2009 x86_64 GNU/Linux

I suspect the solution here would be to get the newer upstream version of netspeed packaged and into the archives.

See bug #268727 "new upstream version of netspeed applet 0.15"