GNOME Bugzilla – Bug 453070
[PATCH] gnome-netstatus does not correctly list interfaces
Last modified: 2011-07-10 02:44:12 UTC
Please describe the problem: gnome-netstatus doesn't correctly list the interfaces on FreeBSD. This is because the ifreq structure length is not constant. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 91025 [details] [review] Don't rely on structure lengh
Sorry for the noise - we had a patch that reverted this for amd64 :/
Created attachment 91850 [details] [review] Iterate the ifreq structures correctly. OK, the issue is that on Linux/AMD64 the length of the name + sockaddr struct is an incorrect calcuation. Instead the size of the ifreq struct should be used as this is static for Linux. This patch lists the addresses correctly on Linux (amd64, x86) and FreeBSD (x86)
I have the problem that on an x86_64 system, the connection selector only displays lo, a blank, and an unprintable character. However, there are working connections eth0, eth1, and ath0 whose status cannot be monitored by means of the netstatus applet though. I wonder if this issue reported elsewhere, namely at https://bugzilla.redhat.com/show_bug.cgi?id=318411 is identical with the issue reported above. If not, I will open a new bug report. The netstatus applet is still of interest for users who cannot use NM because of its ability to deal with multiple active interfaces. For this reason it is disabled by default on Fedora which I am using myself.
Of course, I meant to say ".. inability to deal with multiple active interfaces .."
The patch from comment #3 restores correct operation of the gnome-netstatus applet on my x86_64 box. Time for a new upstream release?
Comment on attachment 91850 [details] [review] Iterate the ifreq structures correctly. This patch is not quite right and should not be accepted as-is. Notably, the fact that this is all contained inside a check for defined(HAVE_SOCKADDR_SA_LEN) is just plain wrong since you are now using a different struct and member. As this was the only usage in the source tree, not only should the source be updated, but configure.in also needs an update. Is there a need for a check still? Are there implementations of ifreq that do not have ifr_name?
Created attachment 105751 [details] [review] Iterate ifreqs more correctly OK, this patch uses the ifreq struct directly and also works on newer NetBSD's where the ifreq structure could have structs bigger than sockaddr. As it now uses the ifreq structure only (and sa_len where it exists) it should be fine.
Comment on attachment 105751 [details] [review] Iterate ifreqs more correctly You missed the part I said about configure. The code is currently contained inside an #ifdef which is effectively: #if sockaddr does not have sa_len member ... #else ... #endif But nowhere are you ever using sockaddr.sa_len anymore. Since this was the only place HAVE_SOCKADDR_SA_LEN is used, this check and this macro ought to be removed entirely from the source (which is here and in configure.in). However, since there appears to be differing implementations of ifreq are different on different platforms? then a NEW check in configure.in must be added. You could probably just modify the existing configure.in check.
Dan, any input here?
From the patch + ifr->ifr_addr.sa_len); That sure looks like sa_len to me!
Ugh, right. Sorry, I was looking at saddr->sa_len going away and yes of course, ifr_addr is a sockaddr. :-)
Created attachment 115547 [details] [review] Iterate ifreqs more correctly This new patch makes it work on NetBSD -current (4.99.70) (i386, amd64), FreeBSD 6.x,7.x (i386) and Gentoo Linux(i386, amd64) Please consider applying - this bug is getting old!
Version 2.26.0 still doesn't fix this issue. Could somebody be so kind to apply the patch from comment #13? Thanks!
gnome-netstatus development has been stalled [1]. Maintainers don't have future development plan so i am closing the bugs as WONTFIX. [1] http://mail.gnome.org/archives/desktop-devel-list/2011-June/msg00073.html