Bug 187979 - 'System Monitor - Network Settings' does not show any network interfaces after upgrade to kernel 2.6.29. Works OK with 2.6.28.
Summary: 'System Monitor - Network Settings' does not show any network interfaces afte...
Status: RESOLVED FIXED
Alias: None
Product: ksysguard
Classification: Unmaintained
Component: Plasmoid / Applet (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-24 09:45 UTC by rgadsdon
Modified: 2009-06-11 06:17 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Patch for bug 187979 (8.14 KB, patch)
2009-06-10 17:00 UTC, Sebastien Martel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rgadsdon 2009-03-24 09:45:40 UTC
Version:            (using KDE 4.2.1)
Compiler:          gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) 
OS:                Linux
Installed from:    Fedora RPMs

'System Monitor - Network Settings' does not show any network interfaces after upgrade to kernel 2.6.29.  Displays 'globe' icon instead of traffic monitor window, on panel.  Works correctly with previous 2.6.28.x kernels.
Other network monitor (KNemo) shows interface and traffic info correctly.
Comment 1 rgadsdon 2009-04-21 13:19:19 UTC
Problem still occurs with KDE 4.2.2 (compiled from source) and kernel 2.6.29.1
Comment 2 irv 2009-05-01 19:25:11 UTC
this has happened to me, 2.6.29.2, kde 4.2.2 (from debian).

it wouldn't detect my CPU up to and including KDE 4.2.1 (how bizarre), now it does (yay), but no network interface :(
Comment 3 Dennis Schridde 2009-05-20 23:48:24 UTC
Also notable: http://forum.kde.org/kde-does-not-see-eth0-t-39534.html#pid57543
Comment 4 rgadsdon 2009-05-21 10:44:10 UTC
Thanks for the link.

I have checked the corresponding output from '#hal-device' and '#solid-hardware details ..........' running kernel 2.6.28 (2.6.28.10) and 2.6.29 (2.6.29.4), and the results are identical.   The problem still occurs with kernel 2.6.29.4..
Comment 5 irv 2009-05-21 15:12:35 UTC
the link is indeed correct regarding netdev.c, in initNetDev:

if ( updateNetDev() < 0 )
    return;

I'm at work and not had the time to look at the interface, but looks like a classic case of using the same return code to indicate multiple errors; and judging by the comments, neither of them are fatal. In UpdateNetDev:

if ( ( fd = open( "/proc/net/dev", O_RDONLY ) ) < 0 ) {
    /* /proc/net/dev may not exist on some machines. */
    NetDevOk = -1;
    return 0;
  }

whereas...

  if ( ( fd = open( "/proc/net/wireless", O_RDONLY ) ) < 0 ) {
    /* /proc/net/wireless may not exist on some machines. */
    NetDevWifiBuf[0]='\0';
    return -1;
  }

Again, only skimming it but I don't think it should set NetDevOK to -1 either, as that's going to prevent further updates in the same vein:
if ( NetDevOk < 0 )
    return 0;

So, the way I see it, this can be changed from unconfirmed to either confirmed (which it is) and then fix it, or wontfix because you can stipulate you have to have wireless support on linux, which is indeed the workaround.

Cheers,

Andy
Comment 6 John Tapsell 2009-05-21 15:48:15 UTC
> So, the way I see it, this can be changed from unconfirmed to either confirmed
> (which it is) and then fix it, or wontfix because you can stipulate you have to
> have wireless support on linux, which is indeed the workaround.

The way I see it is that you guys seem to understand the problem and have a solution.  I just need to wait for you to go the last mile and test if your solution works.  If it works, then commit the change :-)
Comment 7 Dennis Schridde 2009-05-21 16:28:35 UTC
(In reply to comment #5)
> So, the way I see it, this can be changed from unconfirmed to either
> confirmed (which it is) and then fix it, or wontfix because you can stipulate
> you have to have wireless support on linux, which is indeed the workaround.
Err... Why do I have to have wireless support? I do not even have a wireless card, nor an access point. Thus I do not think there is anything enforcing me to enable wireless support. ;)
Comment 8 irv 2009-05-21 18:23:48 UTC
(In reply to comment #7)
> (In reply to comment #5)
> > So, the way I see it, this can be changed from unconfirmed to either
> > confirmed (which it is) and then fix it, or wontfix because you can stipulate
> > you have to have wireless support on linux, which is indeed the workaround.
> Err... Why do I have to have wireless support? I do not even have a wireless
> card, nor an access point. Thus I do not think there is anything enforcing me
> to enable wireless support. ;)

indeed! which is why I hope they fix it :)
Comment 9 John Tapsell 2009-06-01 19:29:58 UTC
irv, any chance of a patch for this?
Comment 10 Sebastien Martel 2009-06-10 17:00:51 UTC
Created attachment 34407 [details]
Patch for bug 187979

This fixes the problem that ksysguardd did not report any network interfaces when wifi was not present, it should also fix the reverse case where there is only wifi present
Comment 11 John Tapsell 2009-06-11 06:17:00 UTC
SVN commit 980071 by johnflux:

This fixes the problem that ksysguardd did not report any network interfaces
when wifi was not present, it should also fix the reverse case where there is
only wifi present

Written by:  mlconsultant@hotmail.com
Reviewed and with minor whitespace cleanup

BUG:187979


 M  +97 -107   netdev.c   [POSSIBLY UNSAFE: scanf]


WebSVN link: http://websvn.kde.org/?view=rev&revision=980071