Description of problem: I have a setup where fprobe-ulog reads log entries, and forwards to a flow-capture process. The purpose is to get some reports from the flow tools to understand how much traffic is going to and from different sites. After upgrading to kernel 3.17, the ULOG entry I had in my iptables configuration wasn't supported any more. After googling a little, I changed it to NFLOG. But now my fprobe-ulog won't work any more. When strace:ing I see it fails to do a call of "socket(PF_NETLINK, SOCK_RAW, 5)". I'm not very familiar with this functionality. I'm guessing this is an obsolete socket call now, but I can't find any obvious flag to fprobe-ulog to make it try something else. Version-Release number of selected component (if applicable): fprobe-ulog-1.1-14.fc21.x86_64 kernel-3.17.3-300.fc21.x86_64 How reproducible: Every time Steps to Reproduce: 1. /usr/bin/fprobe-ulog -Xp25p1:100 localhost:8818 Actual results: libipulog initialization error: Unable to create netlink socket Expected results: A running daemon. Additional info: As far as I know, this might not have a solution. Maybe fprobe-ulog is an old tool that won't work any more with the current kernel that only supports NFLOG. But if that is so, is there any reason to keep the package in the distribution? As I said, I'm not very familiar with the kernel logging features, so I might miss something obvious.
Hm. fprobe-ulog is old and unmaintained. However, I've just found a fork of it that works with NFLOG. I will try to build it now.
Scratch that, the changes in that fork have nothing to do with NFLOG; in fact, fprobe-ulog you're looking at should do NFLOG just fine. I'll need some time to investigate.
Are you saying fprobe-ulog works on other F21 systems, and something is wrong with mine, that needs to be understood? A specific problem in my setup, that is. Or are you saying that that fprobe-ulog isn't working for you either, but ought to have worked (for both of us)? That is, it is general problem. No hurry, of course! Let me know if I should look for some peculiarities on my side. If possible, with a pointer what to look for! :-)
I don't see how the current fprobe-ulog can work with NFLOG. I think it needs to get ported to use libnetfilter_log.
libnetfilter_log appears to perhaps ship a libipulog compatibility interface.
It appears to be fairly straightforward to port to the new libnetfilter_log libipulog interface. However, I'm as of yet not having success running it. Getting: libipulog initialization error: Unable to create netlink handle
Okay, think I have things mostly sorted. I've put up a new release here: https://github.com/opoplawski/fprobe-ulog/releases One remaining issue is that the -B open no longer works, it generates: setsockopt(): Bad file descriptor although the program still runs. You need a BR on libnetfilter_log-devel now. Paul, I can update the Fedora package if you'd like.
Orion, thanks so much for fixing this. Feel free to update the package, and thanks again.
fprobe-ulog-1.2-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/fprobe-ulog-1.2-1.fc21
Package fprobe-ulog-1.2-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fprobe-ulog-1.2-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-17597/fprobe-ulog-1.2-1.fc21 then log in and leave karma (feedback).
With the new version, the fprobe-ulog daemon starts running. But still no data from flow-capture shows up in /var/flow-tools. Maybe it's something I'm doing wrong? Do I need a different setup from what I did before? Previously I had a rule in iptables: ULOG all -- any any anywhere anywhere ulog-cprange 48 ulog-qthreshold 50 Now the corresponding rule looks like this: NFLOG all -- any any anywhere anywhere nflog-range 48 nflog-threshold 50 The packet count for the rule in iptables keep increasing, so it's still matched like before. strace:ing fprobe-ulog I see that one thread is hanging in a recvfrm() call on fd 4, which is a netlink socket: fprobe-ul 12652 root 4u netlink 0t0 98309689 NETFILTER It seems to hang there indefinitely. Another thread is doing select() with a 5 second timeout. When it times out there are a few futex() calls, and a new sleep is started. From what I can see, no "real" work is done. Is it me who don't understand what more I need to update? Is there some problem with the update? Or some third kind of problem. I don't remember how I figured out the "-Xp25p1:100" option to fprobe-ulog, so I also tried without it, but it didn't make any difference.
The issue may be NF log group. It looks like fprobe-ulog defaults to group 1, which perhaps the ULOG target defaulted to as well. The NFLOG target seems to default to group 0. Try using the "-U 0" option to fprobe-ulog. That worked for me.
Thanks! Yes, that made a difference. An when double checking the man page for "iptables-extensions" the NFLOG group range goes from 0 to 16535, while the range for ULOG is 1 to 32. It's somewhat confusing that the manual page for -U says it is a BIT MASK, Which lead me to assume 0 meant no groups, 1 group 1, 2 group 2, 3 group 1 and 2, and so on. (Or starting from 0, if I had noticed the difference in group numbers between ULOG and NFLOG.) But with "-U 0" I do get data in my flow logs again. (And at a quick glance, the data looks correct.) Thanks again!
fprobe-ulog-1.2-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.