ipt-netflow-users Mailing List for NetFlow/IPFIX iptables module
NetFlow iptables module for Linux kernel
Brought to you by:
aabc
Menu
▾
▴
ipt-netflow-users — Combined mail list
You can subscribe to this list here.
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Karel <li...@vc...> - 2018-08-03 09:16:31
|
> On 2018-07-26 14:21, Axel Beckert wrote:
>
> A few months ago, I packaged ipt-netflow for Debian.
I am glad to see this project (and mailing list) is not dead after all.
I would very much like to use ipt-netflow, but I am unable to compile it
into kernel statically.
Compiling as module works, but I am using custom kernel without modules
(for simplicity and security)
I have managed to copy ipt-netflow inside the kernel tree and compile
it. But when I boot, my kernel panics
Can somebody make sense of the bootlog below ?
[ 1.495239] md: raid10 personality registered for level 10
[ 1.497164] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input1
[ 1.500114] md: raid6 personality registered for level 6
[ 1.501716] md: raid5 personality registered for level 5
[ 1.503336] md: raid4 personality registered for level 4
[ 1.504960] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK
2.5+ PQ: 0 ANSI: 5
[ 1.507438] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised:
dm-...@re...
[ 1.509768] ipt_NETFLOW version 2.2-24-g0565def, srcversion srcversion
[ 1.511583] ipt_NETFLOW: hashsize 376979 (2945K)
[ 1.515558] netflow: registering: /proc/net/stat/ipt_netflow
[ 1.517290] netflow: registered: /proc/net/stat/ipt_netflow
[ 1.518904] netflow: registering: /proc/net/stat/ipt_netflow_snmp
[ 1.520603] netflow: registered: /proc/net/stat/ipt_netflow_snmp
[ 1.522283] netflow: registering: /proc/net/stat/ipt_netflow_flows
[ 1.524073] netflow: registered: /proc/net/stat/ipt_netflow_flows
[ 1.525865] netflow: registered: sysctl net.netflow
[ 1.527371] ipt_NETFLOW: error connecting UDP socket 101, don't worry,
will try reconnect later.
[ 1.530020] ipt_NETFLOW: added destination 127.0.0.1:2055 (unconnected)
[ 1.531897] ipt_NETFLOW protocol version 5 (NetFlow) enabled.
[ 1.533697] BUG: unable to handle kernel NULL pointer dereference at
0000000000000090
[ 1.536295] IP: [<ffffffff813b7654>] 0xffffffff813b7654
[ 1.537923] PGD 0
[ 1.538771] Oops: 0002 [#1] SMP
[ 1.539990] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.111-min-1 #4
[ 1.541857] task: ffff88013c178000 ti: ffff88013c180000 task.ti:
ffff88013c180000
[ 1.544114] RIP: 0010:[<ffffffff813b7654>] [<ffffffff813b7654>]
0xffffffff813b7654
[ 1.546478] RSP: 0000:ffff88013c183e50 EFLAGS: 00010206
[ 1.548036] RAX: 0000000000000002 RBX: 0000000000000090 RCX:
00000000fffedc28
[ 1.550074] RDX: 0000000000000000 RSI: 0000000000000002 RDI:
0000000000000090
[ 1.551968] RBP: ffffffff81655ce0 R08: 00000000ffffffff R09:
ffff88013fc0ef00
[ 1.553962] R10: ffffffff8177b000 R11: ffffffffffffffff R12:
0000000000000002
[ 1.555946] R13: ffffffff81655ce0 R14: 0000000000000000 R15:
0000000000000000
[ 1.557954] FS: 0000000000000000(0000) GS:ffff88013fc00000(0000)
knlGS:0000000000000000
[ 1.560277] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1.561886] CR2: 0000000000000090 CR3: 0000000001608000 CR4:
0000000000000630
[ 1.563800] Stack:
[ 1.564559] 0000000000000090 ffffffff81352494 0000000000000000
ffffffff81655ce0
[ 1.567159] ffffffff8135254f ffffffff816940ea ffffffff816940ea
0000000000000000
[ 1.569810] ffffffff816f8388 ffffffff816736b5 ffffffff81694390
ffffffff816940ea
[ 1.572426] Call Trace:
[ 1.573272] [<ffffffff81352494>] ? 0xffffffff81352494
[ 1.574678] [<ffffffff8135254f>] ? 0xffffffff8135254f
[ 1.576083] [<ffffffff816940ea>] ? 0xffffffff816940ea
[ 1.577589] [<ffffffff816940ea>] ? 0xffffffff816940ea
[ 1.579105] [<ffffffff816736b5>] ? 0xffffffff816736b5
[ 1.580560] [<ffffffff81694390>] ? 0xffffffff81694390
[ 1.582115] [<ffffffff816940ea>] ? 0xffffffff816940ea
[ 1.583589] [<ffffffff81673d9e>] ? 0xffffffff81673d9e
[ 1.585171] [<ffffffff8106f700>] ? 0xffffffff8106f700
[ 1.586663] [<ffffffff816736b5>] ? 0xffffffff816736b5
[ 1.588207] [<ffffffff81673f49>] ? 0xffffffff81673f49
[ 1.589734] [<ffffffff813b3d70>] ? 0xffffffff813b3d70
[ 1.591198] [<ffffffff813b3d75>] ? 0xffffffff813b3d75
[ 1.592663] [<ffffffff813b963f>] ? 0xffffffff813b963f
[ 1.594144] [<ffffffff813b3d70>] ? 0xffffffff813b3d70
[ 1.595611] Code: 5c 41 5d 41 5e 41 5f 5d c3 31 c0 87 03 83 f8 01 0f 85
55 ff ff ff eb cb 0f 1f 44 00 00
66 2e 0f 1f 84 00 00 00 00 00 53 48 89 fb <3e> ff 0f 79 05 e8 e2 fe ff
ff 65 48 8b 04 25 80 d4 00 00 48 89
[ 1.607156] RIP [<ffffffff813b7654>] 0xffffffff813b7654
[ 1.608765] RSP <ffff88013c183e50>
[ 1.609727] CR2: 0000000000000090
[ 1.610773] ---[ end trace 440d8207a6b63214 ]---
[ 1.612207] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
[ 1.612207]
[ 1.615299] Kernel Offset: disabled
[ 1.616388] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
|
|
From: Axel B. <ab...@de...> - 2018-07-26 12:37:07
|
Hi, A few months ago, I packaged ipt-netflow for Debian. So far it's available in Debian Unstable and Testing. Locally I also use backported packages on Debian Stretch/Stable. But since that's not much more than a pure recompilation of the package, I haven't bothered adding it to the official backports archive. (I might do so, if there's a some demand for it.) I named the package iptables-netflow instead of just ipt-netflow to be consistent with other iptables plugins packaged for Debian. For information about the source package, see https://packages.qa.debian.org/iptables-netflow And for the binary packages see https://packages.debian.org/iptables-netflow-dkms and https://packages.debian.org/irqtop I build irqtop from the same source package but into a separate binary package since on the one hand it's useful on its own and on the other hand, I don't want iptables-netflow-dkms to pull in ruby as dependency. This is also visible in the installation statistics, since irqtop has about 10 times of installations than iptables-netflow-dkms itself: https://qa.debian.org/popcon.php?package=iptables-netflow (Disclaimer: At least four of the reported iptables-netflow-dkms installations are my own. But this also means that there seem to be some other users out there besides myself. :-) Should be available in Debian Stable with Debian's next major release nicknamed "Buster" (aka Debian 10). P.S.: I uploaded a bug fix package yesterday as there were cases where the kernel module would not have been built for the correct kernel. (DKMS packaging woes. :-) Should be available in Debian Testing in a few days, too. Regards, Axel -- ,''`. | Axel Beckert <ab...@de...>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE |
|
From: Karel <li...@vc...> - 2018-01-25 07:01:27
|
> On 2018-01-09 12:06, Karel wrote:
>
> How difficult would it be to compile ipt-netflow statically, instead of
> as a module ?
>
> Ideally, I would like to "patch" the kernel source, and then simply
> select ipt-netflow option in menuconfig.
Hello again,
I have still not given up on the idea of compiling ipt-netflow
statically into kernel.
I think I have made some progress on my own, but now I am stuck and need
help.
I have managed to copy ipt-netflow inside the kernel tree and
successfully compile it. But when I boot, my kernel panics (please see
boot log below)
I am not a kernel hacker. Could somebody please help me understand what
is causing the panic ?
thanks,
Karel
[ 1.495239] md: raid10 personality registered for level 10
[ 1.497164] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input1
[ 1.500114] md: raid6 personality registered for level 6
[ 1.501716] md: raid5 personality registered for level 5
[ 1.503336] md: raid4 personality registered for level 4
[ 1.504960] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK
2.5+ PQ: 0 ANSI: 5
[ 1.507438] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised:
dm-...@re...
[ 1.509768] ipt_NETFLOW version 2.2-24-g0565def, srcversion srcversion
[ 1.511583] ipt_NETFLOW: hashsize 376979 (2945K)
[ 1.515558] netflow: registering: /proc/net/stat/ipt_netflow
[ 1.517290] netflow: registered: /proc/net/stat/ipt_netflow
[ 1.518904] netflow: registering: /proc/net/stat/ipt_netflow_snmp
[ 1.520603] netflow: registered: /proc/net/stat/ipt_netflow_snmp
[ 1.522283] netflow: registering: /proc/net/stat/ipt_netflow_flows
[ 1.524073] netflow: registered: /proc/net/stat/ipt_netflow_flows
[ 1.525865] netflow: registered: sysctl net.netflow
[ 1.527371] ipt_NETFLOW: error connecting UDP socket 101, don't worry,
will try reconnect later.
[ 1.530020] ipt_NETFLOW: added destination 127.0.0.1:2055 (unconnected)
[ 1.531897] ipt_NETFLOW protocol version 5 (NetFlow) enabled.
[ 1.533697] BUG: unable to handle kernel NULL pointer dereference at
0000000000000090
[ 1.536295] IP: [<ffffffff813b7654>] 0xffffffff813b7654
[ 1.537923] PGD 0
[ 1.538771] Oops: 0002 [#1] SMP
[ 1.539990] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.111-min-1 #4
[ 1.541857] task: ffff88013c178000 ti: ffff88013c180000 task.ti:
ffff88013c180000
[ 1.544114] RIP: 0010:[<ffffffff813b7654>] [<ffffffff813b7654>]
0xffffffff813b7654
[ 1.546478] RSP: 0000:ffff88013c183e50 EFLAGS: 00010206
[ 1.548036] RAX: 0000000000000002 RBX: 0000000000000090 RCX:
00000000fffedc28
[ 1.550074] RDX: 0000000000000000 RSI: 0000000000000002 RDI:
0000000000000090
[ 1.551968] RBP: ffffffff81655ce0 R08: 00000000ffffffff R09:
ffff88013fc0ef00
[ 1.553962] R10: ffffffff8177b000 R11: ffffffffffffffff R12:
0000000000000002
[ 1.555946] R13: ffffffff81655ce0 R14: 0000000000000000 R15:
0000000000000000
[ 1.557954] FS: 0000000000000000(0000) GS:ffff88013fc00000(0000)
knlGS:0000000000000000
[ 1.560277] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1.561886] CR2: 0000000000000090 CR3: 0000000001608000 CR4:
0000000000000630
[ 1.563800] Stack:
[ 1.564559] 0000000000000090 ffffffff81352494 0000000000000000
ffffffff81655ce0
[ 1.567159] ffffffff8135254f ffffffff816940ea ffffffff816940ea
0000000000000000
[ 1.569810] ffffffff816f8388 ffffffff816736b5 ffffffff81694390
ffffffff816940ea
[ 1.572426] Call Trace:
[ 1.573272] [<ffffffff81352494>] ? 0xffffffff81352494
[ 1.574678] [<ffffffff8135254f>] ? 0xffffffff8135254f
[ 1.576083] [<ffffffff816940ea>] ? 0xffffffff816940ea
[ 1.577589] [<ffffffff816940ea>] ? 0xffffffff816940ea
[ 1.579105] [<ffffffff816736b5>] ? 0xffffffff816736b5
[ 1.580560] [<ffffffff81694390>] ? 0xffffffff81694390
[ 1.582115] [<ffffffff816940ea>] ? 0xffffffff816940ea
[ 1.583589] [<ffffffff81673d9e>] ? 0xffffffff81673d9e
[ 1.585171] [<ffffffff8106f700>] ? 0xffffffff8106f700
[ 1.586663] [<ffffffff816736b5>] ? 0xffffffff816736b5
[ 1.588207] [<ffffffff81673f49>] ? 0xffffffff81673f49
[ 1.589734] [<ffffffff813b3d70>] ? 0xffffffff813b3d70
[ 1.591198] [<ffffffff813b3d75>] ? 0xffffffff813b3d75
[ 1.592663] [<ffffffff813b963f>] ? 0xffffffff813b963f
[ 1.594144] [<ffffffff813b3d70>] ? 0xffffffff813b3d70
[ 1.595611] Code: 5c 41 5d 41 5e 41 5f 5d c3 31 c0 87 03 83 f8 01 0f 85
55 ff ff ff eb cb 0f 1f 44 00 00
66 2e 0f 1f 84 00 00 00 00 00 53 48 89 fb <3e> ff 0f 79 05 e8 e2 fe ff
ff 65 48 8b 04 25 80 d4 00 00 48 89
[ 1.607156] RIP [<ffffffff813b7654>] 0xffffffff813b7654
[ 1.608765] RSP <ffff88013c183e50>
[ 1.609727] CR2: 0000000000000090
[ 1.610773] ---[ end trace 440d8207a6b63214 ]---
[ 1.612207] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
[ 1.612207]
[ 1.615299] Kernel Offset: disabled
[ 1.616388] ---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x00000009
|
|
From: Karel <li...@vc...> - 2018-01-09 11:06:59
|
Hello, I am using custom compiled kernel without modules (mostly for security reasons, but also fro simplicity). How difficult would it be to compile ipt-netflow statically, instead of as a module ? Ideally, I would like to "patch" the kernel source, and then simply select ipt-netflow option in menuconfig. Any suggestions would be appreciated. (For the record, compiling as module works OK on kernel 4.4.) thanks, Karel |
|
From: Bruce F. <bfe...@ba...> - 2017-08-22 14:18:41
|
Goodman I would suggest you report this on the issue tracker for the project on git hub: https://github.com/aabc/ipt-netflow/issues See what the developers have to say On 08/16/2017 07:21 PM, Goodman Leung wrote: > do you have any other solution ? > > 在 2017/8/15 16:39, Goodman Leung 写道: >> i got the same error using the git version you provided . >> >> i installed gcc-4.6 and gcc-4.4 , all of they can not build. >> >> 在 2017/8/15 16:20, Bruce Ferrell 写道: >>> Gordon, >>> >>> I just finished compiling against a check out from the git repository at: >>> >>> ttps://github.com/aabc/ipt-netflow >>> >>> It builds and works >>> >>> I'd suggest pulling that and attempting a build. >>> >>> If that Fails, use the link I sent previously to update your compiler and set it up correctly. The steps are all at that link. >>> >>> >>> >>> On 08/15/2017 01:10 AM, Goodman Leung wrote: >>>> hi >>>> >>>> my gcc version as follow: >>>> >>>> gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 >>>> Copyright (C) 2013 Free Software Foundation, Inc. >>>> This is free software; see the source for copying conditions. There is NO >>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE >>>> >>>> 在 2017/8/15 15:22, Bruce Ferrell 写道: >>>>> >>>>> And to followup on my own reply, mine is fixed in the git repository. >>>>> >>>>> >>>>> On 08/15/2017 12:16 AM, Bruce Ferrell wrote: >>>>>> Gordon, >>>>>> >>>>>> Your error is different from the one I get on Scientific Linux 6.9 with Kernel 4.12.7 >>>>>> >>>>>> My error seems to be a kernel internal structure change: >>>>>> >>>>>> error: request for member ‘tv64’ in something not a structure or union >>>>>> >>>>>> Your error is a gcc version problem; please send the output of: >>>>>> >>>>>> gcc --version >>>>>> >>>>>> and try the solution found below; Even if you're not on a Ubuntu release the fix should be similar: >>>>>> >>>>>> |https://askubuntu.com/questions/26498/choose-gcc-and-g-version | >>>>>> >>>>>> On 08/14/2017 11:12 PM, Goodman Leung wrote: >>>>>>> thks for reply >>>>>>> >>>>>>> here is the error output : >>>>>>> >>>>>>> grep: input file `version.h' is also the output >>>>>>> Compiling for kernel 4.9.20-040920-generic >>>>>>> make -C /lib/modules/4.9.20-040920-generic/build M=/root/tools/ipt-netflow/ipt-netflow-2.2 modules CONFIG_DEBUG_INFO=y >>>>>>> make[1]: Entering directory `/usr/src/linux-headers-4.9.20-040920-generic' >>>>>>> CC [M] /root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o >>>>>>> gcc: error: unrecognized command line option ‘-fstack-protector-strong’ >>>>>>> make[2]: *** [/root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o] Error 1 >>>>>>> make[1]: *** [_module_/root/tools/ipt-netflow/ipt-netflow-2.2] Error 2 >>>>>>> make[1]: Leaving directory `/usr/src/linux-headers-4.9.20-040920-generic' >>>>>>> make: *** [ipt_NETFLOW.ko] Error 2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 在 2017/8/15 11:09, Bruce Ferrell 写道: >>>>>>>> Gordon, >>>>>>>> >>>>>>>> What error are you having? What distro? >>>>>>>> >>>>>>>> >>>>>>>> On 08/14/2017 07:18 PM, Goodman Leung wrote: >>>>>>>>> hi list >>>>>>>>> >>>>>>>>> any update ? >>>>>>>>> >>>>>>>>> >>>>>>>>> 在 2017/8/14 18:20, Goodman Leung 写道: >>>>>>>>>> hi list >>>>>>>>>> >>>>>>>>>> does any one know , is there a plan to support kernel 4.9 + ? >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Check out the vibrant tech community on one of the world's most >>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>>> _______________________________________________ >>>>>> ipt-netflow-users mailing list >>>>>> ipt...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> ipt-netflow-users mailing list >>>>> ipt...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> >>>> >>>> _______________________________________________ >>>> ipt-netflow-users mailing list >>>> ipt...@li... >>>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> ipt-netflow-users mailing list >>> ipt...@li... >>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >> > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users |
|
From: Goodman L. <gbc...@gm...> - 2017-08-17 02:21:39
|
do you have any other solution ? 在 2017/8/15 16:39, Goodman Leung 写道: > i got the same error using the git version you provided . > > i installed gcc-4.6 and gcc-4.4 , all of they can not build. > > 在 2017/8/15 16:20, Bruce Ferrell 写道: >> Gordon, >> >> I just finished compiling against a check out from the git repository >> at: >> >> ttps://github.com/aabc/ipt-netflow >> >> It builds and works >> >> I'd suggest pulling that and attempting a build. >> >> If that Fails, use the link I sent previously to update your compiler >> and set it up correctly. The steps are all at that link. >> >> >> >> On 08/15/2017 01:10 AM, Goodman Leung wrote: >>> hi >>> >>> my gcc version as follow: >>> >>> gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 >>> Copyright (C) 2013 Free Software Foundation, Inc. >>> This is free software; see the source for copying conditions. There >>> is NO >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >>> PURPOSE >>> >>> 在 2017/8/15 15:22, Bruce Ferrell 写道: >>>> >>>> And to followup on my own reply, mine is fixed in the git repository. >>>> >>>> >>>> On 08/15/2017 12:16 AM, Bruce Ferrell wrote: >>>>> Gordon, >>>>> >>>>> Your error is different from the one I get on Scientific Linux 6.9 >>>>> with Kernel 4.12.7 >>>>> >>>>> My error seems to be a kernel internal structure change: >>>>> >>>>> error: request for member ‘tv64’ in something not a structure or >>>>> union >>>>> >>>>> Your error is a gcc version problem; please send the output of: >>>>> >>>>> gcc --version >>>>> >>>>> and try the solution found below; Even if you're not on a Ubuntu >>>>> release the fix should be similar: >>>>> >>>>> |https://askubuntu.com/questions/26498/choose-gcc-and-g-version | >>>>> >>>>> On 08/14/2017 11:12 PM, Goodman Leung wrote: >>>>>> thks for reply >>>>>> >>>>>> here is the error output : >>>>>> >>>>>> grep: input file `version.h' is also the output >>>>>> Compiling for kernel 4.9.20-040920-generic >>>>>> make -C /lib/modules/4.9.20-040920-generic/build >>>>>> M=/root/tools/ipt-netflow/ipt-netflow-2.2 modules >>>>>> CONFIG_DEBUG_INFO=y >>>>>> make[1]: Entering directory >>>>>> `/usr/src/linux-headers-4.9.20-040920-generic' >>>>>> CC [M] /root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o >>>>>> gcc: error: unrecognized command line option >>>>>> ‘-fstack-protector-strong’ >>>>>> make[2]: *** >>>>>> [/root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o] Error 1 >>>>>> make[1]: *** [_module_/root/tools/ipt-netflow/ipt-netflow-2.2] >>>>>> Error 2 >>>>>> make[1]: Leaving directory >>>>>> `/usr/src/linux-headers-4.9.20-040920-generic' >>>>>> make: *** [ipt_NETFLOW.ko] Error 2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 在 2017/8/15 11:09, Bruce Ferrell 写道: >>>>>>> Gordon, >>>>>>> >>>>>>> What error are you having? What distro? >>>>>>> >>>>>>> >>>>>>> On 08/14/2017 07:18 PM, Goodman Leung wrote: >>>>>>>> hi list >>>>>>>> >>>>>>>> any update ? >>>>>>>> >>>>>>>> >>>>>>>> 在 2017/8/14 18:20, Goodman Leung 写道: >>>>>>>>> hi list >>>>>>>>> >>>>>>>>> does any one know , is there a plan to support kernel 4.9 + ? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> ipt-netflow-users mailing list >>>>> ipt...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> ipt-netflow-users mailing list >>>> ipt...@li... >>>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> >>> >>> _______________________________________________ >>> ipt-netflow-users mailing list >>> ipt...@li... >>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >> >> >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> ipt-netflow-users mailing list >> ipt...@li... >> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users > |
|
From: Goodman L. <gbc...@gm...> - 2017-08-15 08:39:48
|
i got the same error using the git version you provided . i installed gcc-4.6 and gcc-4.4 , all of they can not build. 在 2017/8/15 16:20, Bruce Ferrell 写道: > Gordon, > > I just finished compiling against a check out from the git repository at: > > ttps://github.com/aabc/ipt-netflow > > It builds and works > > I'd suggest pulling that and attempting a build. > > If that Fails, use the link I sent previously to update your compiler > and set it up correctly. The steps are all at that link. > > > > On 08/15/2017 01:10 AM, Goodman Leung wrote: >> hi >> >> my gcc version as follow: >> >> gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 >> Copyright (C) 2013 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There >> is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE >> >> 在 2017/8/15 15:22, Bruce Ferrell 写道: >>> >>> And to followup on my own reply, mine is fixed in the git repository. >>> >>> >>> On 08/15/2017 12:16 AM, Bruce Ferrell wrote: >>>> Gordon, >>>> >>>> Your error is different from the one I get on Scientific Linux 6.9 >>>> with Kernel 4.12.7 >>>> >>>> My error seems to be a kernel internal structure change: >>>> >>>> error: request for member ‘tv64’ in something not a structure or >>>> union >>>> >>>> Your error is a gcc version problem; please send the output of: >>>> >>>> gcc --version >>>> >>>> and try the solution found below; Even if you're not on a Ubuntu >>>> release the fix should be similar: >>>> >>>> |https://askubuntu.com/questions/26498/choose-gcc-and-g-version | >>>> >>>> On 08/14/2017 11:12 PM, Goodman Leung wrote: >>>>> thks for reply >>>>> >>>>> here is the error output : >>>>> >>>>> grep: input file `version.h' is also the output >>>>> Compiling for kernel 4.9.20-040920-generic >>>>> make -C /lib/modules/4.9.20-040920-generic/build >>>>> M=/root/tools/ipt-netflow/ipt-netflow-2.2 modules CONFIG_DEBUG_INFO=y >>>>> make[1]: Entering directory >>>>> `/usr/src/linux-headers-4.9.20-040920-generic' >>>>> CC [M] /root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o >>>>> gcc: error: unrecognized command line option >>>>> ‘-fstack-protector-strong’ >>>>> make[2]: *** >>>>> [/root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o] Error 1 >>>>> make[1]: *** [_module_/root/tools/ipt-netflow/ipt-netflow-2.2] >>>>> Error 2 >>>>> make[1]: Leaving directory >>>>> `/usr/src/linux-headers-4.9.20-040920-generic' >>>>> make: *** [ipt_NETFLOW.ko] Error 2 >>>>> >>>>> >>>>> >>>>> >>>>> 在 2017/8/15 11:09, Bruce Ferrell 写道: >>>>>> Gordon, >>>>>> >>>>>> What error are you having? What distro? >>>>>> >>>>>> >>>>>> On 08/14/2017 07:18 PM, Goodman Leung wrote: >>>>>>> hi list >>>>>>> >>>>>>> any update ? >>>>>>> >>>>>>> >>>>>>> 在 2017/8/14 18:20, Goodman Leung 写道: >>>>>>>> hi list >>>>>>>> >>>>>>>> does any one know , is there a plan to support kernel 4.9 + ? >>>>>>>> >>>>>>> >>>>>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> ipt-netflow-users mailing list >>>> ipt...@li... >>>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> ipt-netflow-users mailing list >>> ipt...@li... >>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >> >> >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> _______________________________________________ >> ipt-netflow-users mailing list >> ipt...@li... >> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users |
|
From: Bruce F. <bfe...@ba...> - 2017-08-15 08:20:56
|
Gordon, I just finished compiling against a check out from the git repository at: ttps://github.com/aabc/ipt-netflow It builds and works I'd suggest pulling that and attempting a build. If that Fails, use the link I sent previously to update your compiler and set it up correctly. The steps are all at that link. On 08/15/2017 01:10 AM, Goodman Leung wrote: > hi > > my gcc version as follow: > > gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 > Copyright (C) 2013 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE > > 在 2017/8/15 15:22, Bruce Ferrell 写道: >> >> And to followup on my own reply, mine is fixed in the git repository. >> >> >> On 08/15/2017 12:16 AM, Bruce Ferrell wrote: >>> Gordon, >>> >>> Your error is different from the one I get on Scientific Linux 6.9 with Kernel 4.12.7 >>> >>> My error seems to be a kernel internal structure change: >>> >>> error: request for member ‘tv64’ in something not a structure or union >>> >>> Your error is a gcc version problem; please send the output of: >>> >>> gcc --version >>> >>> and try the solution found below; Even if you're not on a Ubuntu release the fix should be similar: >>> >>> |https://askubuntu.com/questions/26498/choose-gcc-and-g-version | >>> >>> On 08/14/2017 11:12 PM, Goodman Leung wrote: >>>> thks for reply >>>> >>>> here is the error output : >>>> >>>> grep: input file `version.h' is also the output >>>> Compiling for kernel 4.9.20-040920-generic >>>> make -C /lib/modules/4.9.20-040920-generic/build M=/root/tools/ipt-netflow/ipt-netflow-2.2 modules CONFIG_DEBUG_INFO=y >>>> make[1]: Entering directory `/usr/src/linux-headers-4.9.20-040920-generic' >>>> CC [M] /root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o >>>> gcc: error: unrecognized command line option ‘-fstack-protector-strong’ >>>> make[2]: *** [/root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o] Error 1 >>>> make[1]: *** [_module_/root/tools/ipt-netflow/ipt-netflow-2.2] Error 2 >>>> make[1]: Leaving directory `/usr/src/linux-headers-4.9.20-040920-generic' >>>> make: *** [ipt_NETFLOW.ko] Error 2 >>>> >>>> >>>> >>>> >>>> 在 2017/8/15 11:09, Bruce Ferrell 写道: >>>>> Gordon, >>>>> >>>>> What error are you having? What distro? >>>>> >>>>> >>>>> On 08/14/2017 07:18 PM, Goodman Leung wrote: >>>>>> hi list >>>>>> >>>>>> any update ? >>>>>> >>>>>> >>>>>> 在 2017/8/14 18:20, Goodman Leung 写道: >>>>>>> hi list >>>>>>> >>>>>>> does any one know , is there a plan to support kernel 4.9 + ? >>>>>>> >>>>>> >>>>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> ipt-netflow-users mailing list >>> ipt...@li... >>> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >>> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> ipt-netflow-users mailing list >> ipt...@li... >> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users |
|
From: Goodman L. <gbc...@gm...> - 2017-08-15 08:11:08
|
hi my gcc version as follow: gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE 在 2017/8/15 15:22, Bruce Ferrell 写道: > > And to followup on my own reply, mine is fixed in the git repository. > > > On 08/15/2017 12:16 AM, Bruce Ferrell wrote: >> Gordon, >> >> Your error is different from the one I get on Scientific Linux 6.9 >> with Kernel 4.12.7 >> >> My error seems to be a kernel internal structure change: >> >> error: request for member ‘tv64’ in something not a structure or union >> >> Your error is a gcc version problem; please send the output of: >> >> gcc --version >> >> and try the solution found below; Even if you're not on a Ubuntu >> release the fix should be similar: >> >> |https://askubuntu.com/questions/26498/choose-gcc-and-g-version | >> >> On 08/14/2017 11:12 PM, Goodman Leung wrote: >>> thks for reply >>> >>> here is the error output : >>> >>> grep: input file `version.h' is also the output >>> Compiling for kernel 4.9.20-040920-generic >>> make -C /lib/modules/4.9.20-040920-generic/build >>> M=/root/tools/ipt-netflow/ipt-netflow-2.2 modules CONFIG_DEBUG_INFO=y >>> make[1]: Entering directory >>> `/usr/src/linux-headers-4.9.20-040920-generic' >>> CC [M] /root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o >>> gcc: error: unrecognized command line option ‘-fstack-protector-strong’ >>> make[2]: *** [/root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o] >>> Error 1 >>> make[1]: *** [_module_/root/tools/ipt-netflow/ipt-netflow-2.2] Error 2 >>> make[1]: Leaving directory >>> `/usr/src/linux-headers-4.9.20-040920-generic' >>> make: *** [ipt_NETFLOW.ko] Error 2 >>> >>> >>> >>> >>> 在 2017/8/15 11:09, Bruce Ferrell 写道: >>>> Gordon, >>>> >>>> What error are you having? What distro? >>>> >>>> >>>> On 08/14/2017 07:18 PM, Goodman Leung wrote: >>>>> hi list >>>>> >>>>> any update ? >>>>> >>>>> >>>>> 在 2017/8/14 18:20, Goodman Leung 写道: >>>>>> hi list >>>>>> >>>>>> does any one know , is there a plan to support kernel 4.9 + ? >>>>>> >>>>> >>>>> >> >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> ipt-netflow-users mailing list >> ipt...@li... >> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >> > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users |
|
From: Bruce F. <bfe...@ba...> - 2017-08-15 07:22:13
|
And to followup on my own reply, mine is fixed in the git repository. On 08/15/2017 12:16 AM, Bruce Ferrell wrote: > Gordon, > > Your error is different from the one I get on Scientific Linux 6.9 with Kernel 4.12.7 > > My error seems to be a kernel internal structure change: > > error: request for member ‘tv64’ in something not a structure or union > > Your error is a gcc version problem; please send the output of: > > gcc --version > > and try the solution found below; Even if you're not on a Ubuntu release the fix should be similar: > > |https://askubuntu.com/questions/26498/choose-gcc-and-g-version | > > On 08/14/2017 11:12 PM, Goodman Leung wrote: >> thks for reply >> >> here is the error output : >> >> grep: input file `version.h' is also the output >> Compiling for kernel 4.9.20-040920-generic >> make -C /lib/modules/4.9.20-040920-generic/build M=/root/tools/ipt-netflow/ipt-netflow-2.2 modules CONFIG_DEBUG_INFO=y >> make[1]: Entering directory `/usr/src/linux-headers-4.9.20-040920-generic' >> CC [M] /root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o >> gcc: error: unrecognized command line option ‘-fstack-protector-strong’ >> make[2]: *** [/root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o] Error 1 >> make[1]: *** [_module_/root/tools/ipt-netflow/ipt-netflow-2.2] Error 2 >> make[1]: Leaving directory `/usr/src/linux-headers-4.9.20-040920-generic' >> make: *** [ipt_NETFLOW.ko] Error 2 >> >> >> >> >> 在 2017/8/15 11:09, Bruce Ferrell 写道: >>> Gordon, >>> >>> What error are you having? What distro? >>> >>> >>> On 08/14/2017 07:18 PM, Goodman Leung wrote: >>>> hi list >>>> >>>> any update ? >>>> >>>> >>>> 在 2017/8/14 18:20, Goodman Leung 写道: >>>>> hi list >>>>> >>>>> does any one know , is there a plan to support kernel 4.9 + ? >>>>> >>>> >>>> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users > |
|
From: Bruce F. <bfe...@ba...> - 2017-08-15 07:16:33
|
Gordon, Your error is different from the one I get on Scientific Linux 6.9 with Kernel 4.12.7 My error seems to be a kernel internal structure change: error: request for member ‘tv64’ in something not a structure or union Your error is a gcc version problem; please send the output of: gcc --version and try the solution found below; Even if you're not on a Ubuntu release the fix should be similar: |https://askubuntu.com/questions/26498/choose-gcc-and-g-version | On 08/14/2017 11:12 PM, Goodman Leung wrote: > thks for reply > > here is the error output : > > grep: input file `version.h' is also the output > Compiling for kernel 4.9.20-040920-generic > make -C /lib/modules/4.9.20-040920-generic/build M=/root/tools/ipt-netflow/ipt-netflow-2.2 modules CONFIG_DEBUG_INFO=y > make[1]: Entering directory `/usr/src/linux-headers-4.9.20-040920-generic' > CC [M] /root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o > gcc: error: unrecognized command line option ‘-fstack-protector-strong’ > make[2]: *** [/root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o] Error 1 > make[1]: *** [_module_/root/tools/ipt-netflow/ipt-netflow-2.2] Error 2 > make[1]: Leaving directory `/usr/src/linux-headers-4.9.20-040920-generic' > make: *** [ipt_NETFLOW.ko] Error 2 > > > > > 在 2017/8/15 11:09, Bruce Ferrell 写道: >> Gordon, >> >> What error are you having? What distro? >> >> >> On 08/14/2017 07:18 PM, Goodman Leung wrote: >>> hi list >>> >>> any update ? >>> >>> >>> 在 2017/8/14 18:20, Goodman Leung 写道: >>>> hi list >>>> >>>> does any one know , is there a plan to support kernel 4.9 + ? >>>> >>> >>> |
|
From: Goodman L. <gbc...@gm...> - 2017-08-15 06:12:27
|
thks for reply here is the error output : grep: input file `version.h' is also the output Compiling for kernel 4.9.20-040920-generic make -C /lib/modules/4.9.20-040920-generic/build M=/root/tools/ipt-netflow/ipt-netflow-2.2 modules CONFIG_DEBUG_INFO=y make[1]: Entering directory `/usr/src/linux-headers-4.9.20-040920-generic' CC [M] /root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o gcc: error: unrecognized command line option ‘-fstack-protector-strong’ make[2]: *** [/root/tools/ipt-netflow/ipt-netflow-2.2/ipt_NETFLOW.o] Error 1 make[1]: *** [_module_/root/tools/ipt-netflow/ipt-netflow-2.2] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-4.9.20-040920-generic' make: *** [ipt_NETFLOW.ko] Error 2 在 2017/8/15 11:09, Bruce Ferrell 写道: > Gordon, > > What error are you having? What distro? > > > On 08/14/2017 07:18 PM, Goodman Leung wrote: >> hi list >> >> any update ? >> >> >> 在 2017/8/14 18:20, Goodman Leung 写道: >>> hi list >>> >>> does any one know , is there a plan to support kernel 4.9 + ? >>> >> >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> ipt-netflow-users mailing list >> ipt...@li... >> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users >> > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users |
|
From: Bruce F. <bfe...@ba...> - 2017-08-15 04:02:48
|
Gordon, What error are you having? What distro? On 08/14/2017 07:18 PM, Goodman Leung wrote: > hi list > > any update ? > > > 在 2017/8/14 18:20, Goodman Leung 写道: >> hi list >> >> does any one know , is there a plan to support kernel 4.9 + ? >> > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users > |
|
From: Goodman L. <gbc...@gm...> - 2017-08-15 02:18:19
|
hi list any update ? 在 2017/8/14 18:20, Goodman Leung 写道: > hi list > > does any one know , is there a plan to support kernel 4.9 + ? > |
|
From: Goodman L. <gbc...@gm...> - 2017-08-14 10:21:09
|
hi list does any one know , is there a plan to support kernel 4.9 + ? |
|
From: Gabriel Z. <gab...@do...> - 2016-07-15 14:09:54
|
Hello! I’m using ipt_NETFLOW exporter with WANGuard Collector and still getting this error: Received flow from 318 seconds ago on interface "eth5". Adjusting flow delay from 294 to 318. What can I do to make the delay lower? Wanguard’s support told me to "age and export in under 5 minutes.” Best regards, Gabriel |
|
From: Michael K. <mic...@pl...> - 2015-08-15 14:28:39
|
If you are looking for UDP as well, it becomes a bit harder because there is nothing that can guarantee the flow is new. If you query the data from a database and group by IPs, ports and protocols then select the minimum start time stamp for the flows, you should get a relatively accurate count of flows. You can use a modulus to normalize the timestamps into 1 minute buckets as a second step. Pseudo-sql Select srcIP,dstIP,srcPort,dstPort,protocol,min(flowstart) from database.flowsTable Group by srcIP,dstIP,srcPort,dstPort,protocol This will give you the unique TCP,UDP(and ICMP sort of) conversations and their start times. Adding a modulo function to the flow start timestamp will allow you to convert it to 1 minute resolution. Once you have done that, you will be able to count the flows in each bucket. You may have to do some work to figure out the "real" minutes of the flow because they generally are milliseconds since the system started, not absolute. -Mike Krygeris > On Aug 15, 2015, at 6:45 AM, ABC <ab...@te...> wrote: > > Phillip, > >> On Fri, Aug 14, 2015 at 09:07:48PM +0000, Phillip Rzewski wrote: >> Before I get into my question, what I'm ultimately trying to do is >> find the best way to count new flows started per minute. [...] But I'm >> open to other suggestions. > > If you are interested only in TCP flows, you can analyse TCP_FLAGS(6) > Element for presence of SYN flag. As you should know, first packet of > TCP stream is marked with SYN bit. So you need only change your approach > to counting only flows that is SYN marked. > > -abc > > ------------------------------------------------------------------------------ > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users |
|
From: ABC <ab...@te...> - 2015-08-15 10:45:43
|
Phillip, On Fri, Aug 14, 2015 at 09:07:48PM +0000, Phillip Rzewski wrote: > Before I get into my question, what I'm ultimately trying to do is > find the best way to count new flows started per minute. [...] But I'm > open to other suggestions. If you are interested only in TCP flows, you can analyse TCP_FLAGS(6) Element for presence of SYN flag. As you should know, first packet of TCP stream is marked with SYN bit. So you need only change your approach to counting only flows that is SYN marked. -abc |
|
From: Michael K. <mic...@pl...> - 2015-08-14 23:35:00
|
I can confirm that Cisco does time stamp based on active timeouts in all cases. The flow tuple should be used to stitch long lived flows together during longer periods of time. As a general rule the flow cache "forgets" everything that was observed when it is exported. Times and flags are all reset among other things that might be considered "stateful". If you query across a large data set, group on the 7-tuple and use the minimum start interval for start time and the max end interval for the end. This will always give you the flow duration for the period specified. -Mike Krygeris Sent from my iPhone > On Aug 14, 2015, at 6:40 PM, ABC <ab...@te...> wrote: > > Hello Phillip, > > That's interesting interpretation of FIRST_SWITCHED. The behavior ipt-netflow > you described is intentional, and there is my arguments: > > 1. Currently, exported flow is interpreted same as Expired Flow (historically, > it was expiring from CEF cache), so measurement is restarted for new packets. > IF, instead of reporting timestamp of first packet of when measurement is > (re)started, probe will report some other time in the past, then many > statistical properties of the flow data will be lost or become hard(er) to > calculate. > > For example, it will not be possible (or become much harder) to correctly > measure data rate of the flow, because some arbitrary time will be added to > it's duration. (Yes, it will be possible reconstruct correct rate if we collect > all intermediate active flow exports for this flow and subtract them from last > measurement, but this could be thousands and thousands flow records for many > hours or even days worth data. For example, for some always active persistent > connection.) > > > 2. RFC 3954 states: > > 3.2. Flow Expiration > [...] > 3. For long-lasting Flows, the Exporter SHOULD export the Flow > Records on a regular basis. This timeout SHOULD be > configurable at the Exporter. > > This is implicitly confirms that Exported and Expired flow is synonymous for > Cisco. > > > 3. RFC 5102 5.11.3 states: > > The Flow was terminated for reporting purposes while it was > still active, for example, after the maximum lifetime of > unreported Flows was reached. > > While this is about IPFIX, there is draft-claise-ipfix-eval-netflow-04 > stating important differences between IPFIX and NetFlow v9, which does not say > there is any differenrcte on expiring/terminating flow for v9 and IPFIX. > > If flow is (semantically) "terminated", then what will be next is "new" flow, > and not some continuation of older flow. > > > -abc > >> On Fri, Aug 14, 2015 at 09:07:48PM +0000, Phillip Rzewski wrote: >> Before I get into my question, what I'm ultimately trying to do is find the best way to count new flows started per minute. The question below is regarding a snag I hit when trying to solve this using what I thought was the most direct approach. But I'm open to other suggestions. >> General Netflow docs all describe how each flow can be uniquely identified by the tuple of IP source/dest address+IP source/dest port+etc. It's also advised how the default 30-minute timeout for exporting data about active flows may be sub-optimal since it means a giant burst of traffic will be exported at the conclusion of a long-lived flow, with the collector oblivious up until that point of the long-lived flow's existence. Therefore, I've lowered the active timeout in my environment to 1-minute. >> With these 1-minute updates now coming in for long-lived flows, I was hoping to have a way in my collector to group the records that make up the same long-lived flow, so that way I'd not be counting each flow received at the start of a new minute as a "new flow". I noticed the "FIRST_SWITCHED" field, and this showed great potential since I'd have hoped it would be set to the single timestamp when the flow was first observed in the router, then even in subsequent updates in later minutes that timestamp would be the same. >> Unfortunately, with the ipt-netflow, I'm not finding this to be the case: For my long-lived flow, the FIRST_SWITCHED timestamp is being updated to the beginning of each new 1-minute interval. Is this really desired behavior? I unfortunately don't have a Cisco router at my disposal to see if it does the same thing, but I'd be interested to hear if anyone else can confirm if this behavior is universal. >> --Phil > >> ------------------------------------------------------------------------------ > >> _______________________________________________ >> ipt-netflow-users mailing list >> ipt...@li... >> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users > > > ------------------------------------------------------------------------------ > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users |
|
From: ABC <ab...@te...> - 2015-08-14 22:40:35
|
Hello Phillip,
That's interesting interpretation of FIRST_SWITCHED. The behavior ipt-netflow
you described is intentional, and there is my arguments:
1. Currently, exported flow is interpreted same as Expired Flow (historically,
it was expiring from CEF cache), so measurement is restarted for new packets.
IF, instead of reporting timestamp of first packet of when measurement is
(re)started, probe will report some other time in the past, then many
statistical properties of the flow data will be lost or become hard(er) to
calculate.
For example, it will not be possible (or become much harder) to correctly
measure data rate of the flow, because some arbitrary time will be added to
it's duration. (Yes, it will be possible reconstruct correct rate if we collect
all intermediate active flow exports for this flow and subtract them from last
measurement, but this could be thousands and thousands flow records for many
hours or even days worth data. For example, for some always active persistent
connection.)
2. RFC 3954 states:
3.2. Flow Expiration
[...]
3. For long-lasting Flows, the Exporter SHOULD export the Flow
Records on a regular basis. This timeout SHOULD be
configurable at the Exporter.
This is implicitly confirms that Exported and Expired flow is synonymous for
Cisco.
3. RFC 5102 5.11.3 states:
The Flow was terminated for reporting purposes while it was
still active, for example, after the maximum lifetime of
unreported Flows was reached.
While this is about IPFIX, there is draft-claise-ipfix-eval-netflow-04
stating important differences between IPFIX and NetFlow v9, which does not say
there is any differenrcte on expiring/terminating flow for v9 and IPFIX.
If flow is (semantically) "terminated", then what will be next is "new" flow,
and not some continuation of older flow.
-abc
On Fri, Aug 14, 2015 at 09:07:48PM +0000, Phillip Rzewski wrote:
> Before I get into my question, what I'm ultimately trying to do is find the best way to count new flows started per minute. The question below is regarding a snag I hit when trying to solve this using what I thought was the most direct approach. But I'm open to other suggestions.
> General Netflow docs all describe how each flow can be uniquely identified by the tuple of IP source/dest address+IP source/dest port+etc. It's also advised how the default 30-minute timeout for exporting data about active flows may be sub-optimal since it means a giant burst of traffic will be exported at the conclusion of a long-lived flow, with the collector oblivious up until that point of the long-lived flow's existence. Therefore, I've lowered the active timeout in my environment to 1-minute.
> With these 1-minute updates now coming in for long-lived flows, I was hoping to have a way in my collector to group the records that make up the same long-lived flow, so that way I'd not be counting each flow received at the start of a new minute as a "new flow". I noticed the "FIRST_SWITCHED" field, and this showed great potential since I'd have hoped it would be set to the single timestamp when the flow was first observed in the router, then even in subsequent updates in later minutes that timestamp would be the same.
> Unfortunately, with the ipt-netflow, I'm not finding this to be the case: For my long-lived flow, the FIRST_SWITCHED timestamp is being updated to the beginning of each new 1-minute interval. Is this really desired behavior? I unfortunately don't have a Cisco router at my disposal to see if it does the same thing, but I'd be interested to hear if anyone else can confirm if this behavior is universal.
> --Phil
> ------------------------------------------------------------------------------
> _______________________________________________
> ipt-netflow-users mailing list
> ipt...@li...
> https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users
|
|
From: Phillip R. <ph...@ya...> - 2015-08-14 21:10:55
|
Before I get into my question, what I'm ultimately trying to do is find the best way to count new flows started per minute. The question below is regarding a snag I hit when trying to solve this using what I thought was the most direct approach. But I'm open to other suggestions. General Netflow docs all describe how each flow can be uniquely identified by the tuple of IP source/dest address+IP source/dest port+etc. It's also advised how the default 30-minute timeout for exporting data about active flows may be sub-optimal since it means a giant burst of traffic will be exported at the conclusion of a long-lived flow, with the collector oblivious up until that point of the long-lived flow's existence. Therefore, I've lowered the active timeout in my environment to 1-minute. With these 1-minute updates now coming in for long-lived flows, I was hoping to have a way in my collector to group the records that make up the same long-lived flow, so that way I'd not be counting each flow received at the start of a new minute as a "new flow". I noticed the "FIRST_SWITCHED" field, and this showed great potential since I'd have hoped it would be set to the single timestamp when the flow was first observed in the router, then even in subsequent updates in later minutes that timestamp would be the same. Unfortunately, with the ipt-netflow, I'm not finding this to be the case: For my long-lived flow, the FIRST_SWITCHED timestamp is being updated to the beginning of each new 1-minute interval. Is this really desired behavior? I unfortunately don't have a Cisco router at my disposal to see if it does the same thing, but I'd be interested to hear if anyone else can confirm if this behavior is universal. --Phil |
|
From: ABC <ab...@te...> - 2014-10-06 11:00:57
|
Hello Michal, First of all try to use latest git version or 2.0.1 release. You should configure with ./configure --enable-macaddress, note that "mac" is lowercase. After you loaded module, check first line of /proc/net/stat/ipt_netflow it should contain word "mac". After that macaddresses will be available if interface support them and packets have them (for example, if you are testing on lo there will be no mac addresses.) To verify that flows are sent with mac address records use wireshark. Then if all is correct report problem to flowd developers. You may also report your succes to me/to this list. -abc On Mon, Oct 06, 2014 at 10:57:01AM +0200, Micha?? Zubryk wrote: > Hello, > > I have a question about log using the ipt-netflow mac addresses. > > Or outside running, version 9 netflow and parameter --enable-MACAddress > it is necessary to include something else? > > > I have > ipt_NETFLOW v2.0-32-gbbf2ee7-dirty, srcversion 3D0A68824BC6038EB2B0996; > Aggr mac > ipt_NETFLOW protocol version 9 (NetFlow) enabled. > > A collection of data to use https://code.google.com/p/flowd > > Collect data using a linux router and iptables > $IPTABLES -I FORWARD -j NETFLOW > > > All data are collect exceptMAC addresses ;( > > > Regards. > > -- > Michal Zubryk > > > > ------------------------------------------------------------------------------ > Slashdot TV. Videos for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > _______________________________________________ > ipt-netflow-users mailing list > ipt...@li... > https://lists.sourceforge.net/lists/listinfo/ipt-netflow-users |
|
From: Michał Z. <mi...@zs...> - 2014-10-06 09:12:45
|
Hello, I have a question about log using the ipt-netflow mac addresses. Or outside running, version 9 netflow and parameter --enable-MACAddress it is necessary to include something else? I have ipt_NETFLOW v2.0-32-gbbf2ee7-dirty, srcversion 3D0A68824BC6038EB2B0996; Aggr mac ipt_NETFLOW protocol version 9 (NetFlow) enabled. A collection of data to use https://code.google.com/p/flowd Collect data using a linux router and iptables $IPTABLES -I FORWARD -j NETFLOW All data are collect exceptMAC addresses ;( Regards. -- Michal Zubryk |
|
From: ABC <ab...@te...> - 2014-08-07 05:37:47
|
ipt-netflow is high performance NetFlow exporting module for Linux kernel (up to 3.16). Designed for Linux router with heavy network load. This is netfilter/iptables module adding support for -j NETFLOW target. Designed to work efficiently w/o conntrack. ipt-netflow version 2.0 has been released. This is major release with a lot of new features and improvements, such as: Support of NetFlow protocols v9 and IPFIX. Accounting for IPv6 traffic, NAT translation events (NEL). Additional options is SNMP-index translation rules, Ethernet Type, VLAN, and MAC addresses exporting. Performance improvements (tested to work well on 10Gbit load). Stability improvements and bug fixes. SourceForge.net Project Page: http://sourceforge.net/projects/ipt-netflow/ GutHub Project Page: https://github.com/aabc/ipt-netflow |
|
From: Kevin M. <ke...@fi...> - 2013-12-10 20:48:57
|
I will grab it and test it right away. ~KEM Sent from my iPad > On Dec 10, 2013, at 2:38 PM, ABC <ab...@te...> wrote: > > Hello Kevin, > > Ipt-netflow release v1.8 does not have v9/ipfix. It is implemented in > latest Git version, which is not released as new version yet. It should > be pretty stable though, but I will wait more testing before release. > > Try > git clone http://github.com/aabc/ipt-netflow.git > > -abc > >> On Tue, Dec 10, 2013 at 01:23:02PM -0500, Kevin Mason wrote: >> Just started testing ipt_netflow v1.8, how is the flow export specified? I would like to send either v9 or IPFIX, but that information seems to be missing from the docs. >> >> Thank >> ~KEM |
