From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.4) Gecko/20060614 Fedora/1.5.0.4-1.2.fc5 Firefox/1.5.0.4 pango-text Description of problem: On running /usr/sbin/driftnet, it opens a window that is 0x0 in dimension. The only thing viewable is a tiny fraction of the window titlebar (metacity). An attempt at stretching that window to a usable size already causes a spike in the CPU usage levels. With driftnet running (with the resized window), and CPU levels back down to normal, once a page with images is opened, none of the images are captured and the CPU usage levels shoot to 100%. At this point driftnet has probably hung since closing the window does not kill the program. It will also not respond to ^C. Version-Release number of selected component (if applicable): driftnet-0.1.6-9.fc5.3 How reproducible: Always Steps to Reproduce: 1. Start with fully updated official FC5 system 2. Install driftnet & run '/usr/sbin/driftnet' 3. Open a webpage with some jpeg pictures Actual Results: driftnet hangs, no images captures, CPU load is at 100% (driftnet). Expected Results: driftnet should open a window with non-zero dimensions and display the images captured from the network. Additional info: Tried the binary from the Dries RPM repository as well. It opens a proper sized display window, but also hangs when a page with JPEGs is loaded. The Dries binary works fine on a i386 FC4 machine. There are no FC4 i386 versions of driftnet in extras so I couldn't try that.
I have just upgraded the FC4 machine to FC5 and driftnet still does not work. When I start it as 'driftnet -v' I can see that it is picking up the new network connections but nothing is displayed on the screen. The program itself does not hang however -- maybe that is a x86_64 only issue?
I think it's an x86-64 only issue. Could you please try the patch attached?
Created attachment 134667 [details] driftnet-64bit-spin.patch
Okay, the patch definitely solves the software hang on x86_64. Closing the window also kills the process as expected. However, driftnet still does not display any captured images. The capture process itself seems to be working since the command driftnet -v -a -d /tmp does save copies of the captured images in /tmp which can then be viewed using an external viewer. So, the bottom line is that the built-in display of driftnet does not seem to work on FC5 (i386/x86_64).
(In reply to comment #4) > Okay, the patch definitely solves the software hang on x86_64. Closing the > window also kills the process as expected. However, driftnet still does not > display any captured images. The capture process itself seems to be working > since the command > > driftnet -v -a -d /tmp > > does save copies of the captured images in /tmp which can then be viewed using > an external viewer. So, the bottom line is that the built-in display of driftnet > does not seem to work on FC5 (i386/x86_64). Cool, it's most likely due to the gtk2 port code. I'll look into it soon.
I just send of a build request for driftnet-0.1.6-13.20040426cvs that should fix all the problems. It works for me on my FC-7 x86_64. I don't understand why, but it looks like the g_free(template) call causes the tmpdir variable to get emptied. Since the template variable is no longer used, I'm not sure why that happens at all. But commenting out that line made things work for me. This only happens when not specifying -d, when creating a tmpdir out of the template dirname using mkdtemp().
hmm, seems the endianness code fails on ppc64, so the build failed. I'll pick it up tomorrow.
Please try driftnet-0.1.6-15.20040426cvs. It just finished building. It fixes all problems for me (1 pixel window, hanging driftnet's, not capturing anything at all).
Where do I find the rpm? Thanks.
You should be able to find it in the current rawhide/development tree, but I've alo put one up for you at ftp://ftp.xelerance.com/driftnet-0.1.6-15.20040426cvs.x86_64.rpm
I guess it just hadn't propagated through the mirrors yet. I'll try it out using the rpm from your ftp.
Hi Paul, I grabbed the rpm from your ftp and tried installing it but it seems to require a version of libpcap (Missing Dependency: libpcap.so.0.9.4()(64bit)) that is not available through _any_ of the repositories (I enabled them all using --enablerepo=*). Since you mentioned that I should be able to get driftnet through the development repo anyway, I waited for the last 5 days. As of today, the only version available in rawhide is 0.1.6-12. Could you please double-check whether the packages (driftnet/libpcap/...?) have indeed been published through rawhide? Thank you.
Hi Paul, I finally managed to get the new driftnet via rawhide. After some testing, the old issues seem to have been resolved. However, I did note a few more glitches: 1. When launched without an explicit interface specification, no images are captured. According to the documentation, it should be listening on all interfaces. 2. Clicking on an image is supposed to save it. This does not seem to work (I could not find any saved images under $HOME or /tmp). Thanks for your efforts in fixing the package.
With the package I just pushed out, I can launch driftnet without any arguments, and it captures from my eth0. Clicking on an image to save, apparently only works when you specify -d somedir. This error could be improved (or somedir could be set to . if it was not set I suppose.
driftnet-0.1.6-18.20040426cvs.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
driftnet-0.1.6-19.20040426cvs.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
It is present in the others too. I have a fix that's in devel, that needs to be pushed to the other releases..... please don't close this bug.
Paul, in which Fedora releases is this bug still present?
Actually, I just checked with the fedora 8.92 package, and it works now. And that version is in F8 and F7 (it's the versions based on 20040426cvs). So i guess we can really close this bug.