nfdump-discuss Mailing List for NFDUMP - Netflow processing tools
netflow collecting and processing tools
Brought to you by:
phaag
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(4) |
Sep
(1) |
Oct
(1) |
Nov
(4) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(20) |
Feb
(14) |
Mar
(12) |
Apr
(4) |
May
(9) |
Jun
(15) |
Jul
(23) |
Aug
(12) |
Sep
(5) |
Oct
(5) |
Nov
(1) |
Dec
(5) |
2007 |
Jan
(7) |
Feb
(9) |
Mar
(6) |
Apr
(9) |
May
(11) |
Jun
(6) |
Jul
(25) |
Aug
(35) |
Sep
(10) |
Oct
(21) |
Nov
(13) |
Dec
(10) |
2008 |
Jan
(3) |
Feb
(5) |
Mar
(9) |
Apr
(5) |
May
(1) |
Jun
(2) |
Jul
(13) |
Aug
(10) |
Sep
(1) |
Oct
(5) |
Nov
(1) |
Dec
|
2009 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(4) |
May
(5) |
Jun
(17) |
Jul
(17) |
Aug
(18) |
Sep
(4) |
Oct
(11) |
Nov
(22) |
Dec
(24) |
2010 |
Jan
(13) |
Feb
(6) |
Mar
(5) |
Apr
(9) |
May
(4) |
Jun
(43) |
Jul
(4) |
Aug
(11) |
Sep
(7) |
Oct
(6) |
Nov
(4) |
Dec
(7) |
2011 |
Jan
(14) |
Feb
(20) |
Mar
(19) |
Apr
(2) |
May
(6) |
Jun
(15) |
Jul
(17) |
Aug
(10) |
Sep
(14) |
Oct
(15) |
Nov
(7) |
Dec
(1) |
2012 |
Jan
(16) |
Feb
(7) |
Mar
(6) |
Apr
(6) |
May
(5) |
Jun
(14) |
Jul
(15) |
Aug
(27) |
Sep
(9) |
Oct
(11) |
Nov
(10) |
Dec
(8) |
2013 |
Jan
(25) |
Feb
(11) |
Mar
(11) |
Apr
(15) |
May
(22) |
Jun
(17) |
Jul
(27) |
Aug
(32) |
Sep
(18) |
Oct
(3) |
Nov
(37) |
Dec
(12) |
2014 |
Jan
(11) |
Feb
(10) |
Mar
(2) |
Apr
(15) |
May
(10) |
Jun
(5) |
Jul
(12) |
Aug
(4) |
Sep
(10) |
Oct
(6) |
Nov
(11) |
Dec
(3) |
2015 |
Jan
(7) |
Feb
(6) |
Mar
(8) |
Apr
(9) |
May
(12) |
Jun
(1) |
Jul
(16) |
Aug
(18) |
Sep
(11) |
Oct
(12) |
Nov
(15) |
Dec
(3) |
2016 |
Jan
(2) |
Feb
(12) |
Mar
(3) |
Apr
(14) |
May
(14) |
Jun
(18) |
Jul
(5) |
Aug
|
Sep
|
Oct
(27) |
Nov
(15) |
Dec
(5) |
2017 |
Jan
(2) |
Feb
|
Mar
(6) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
(8) |
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(2) |
2019 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(11) |
Nov
(2) |
Dec
(1) |
2021 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
From: Sergey <a_...@sa...> - 2022-12-05 07:16:53
|
On Sunday 04 December 2022, Sergey wrote: > Is alignment not possible in 1.7 or is it automatically implied for -t in 1.7? The source code answered this question. In 1.6.23: case 'w': // allow for compatibility - always sync timeslot break; -- Regards, Sergey |
From: Sergey <a_...@sa...> - 2022-12-04 14:05:12
|
Hello. Version 1.6 use -w option for an align time: -w Align file rotation with next n minute ( specified by -t ) interval. Example: If interval is 5 min, sync at 0,5,10... wall clock minutes Default: no alignment. behavour was changed in 1.7: -w flowdir Set the flow directory to store the output files. If a sub hierarchy is specified with -S the final directory is concatenated to flowdir/subdir. Is alignment not possible in 1.7 or is it automatically implied for -t in 1.7? -- Regards, Sergey |
From: waqas a. <waq...@gm...> - 2021-05-27 15:49:36
|
Ok, thank u very much On Mon, 24 May 2021, 17:14 Peter Haag, <ph...@us...> wrote: > > > On 10.05.21 19:33, waqas ahmed wrote: > > Hi, > > I am writing dpdk application that needs to export flow related > information > > using ipfix such as application name, http URL and http user agent > strings. > > Ipfix suggest to use private enterprise numbers for such export. Dpdk > > process craft such ipfix packets and send to collector, now is there any > > filter with Nfdump so that can we use to decode PEN and see given > string?. > > Looking forward to hearing from you > > nfdup needs be be aware of such private enterprise numbers in order to > decode > the data correctly. By default nfdump accepts only well defined elements. > > If you are interessted in implementing such private enterprise fields, just > contact me off list. Please also have a look into nfdump1-.7 beta: > https://github.com/phaag/nfdump/issues/292. It implements NBAR: > > https://www.cisco.com/c/en/us/products/ios-nx-os-software/network-based-application-recognition-nbar/index.html > > Thanks > > - Peter > > > Thanks > > > > > > > > _______________________________________________ > > Nfdump-discuss mailing list > > Nfd...@li... > > https://lists.sourceforge.net/lists/listinfo/nfdump-discuss > > > > > -- > Be nice to your netflow data. Use NfSen and nfdump :) > |
From: Peter H. <ph...@us...> - 2021-05-24 12:31:55
|
On 10.05.21 19:33, waqas ahmed wrote: > Hi, > I am writing dpdk application that needs to export flow related information > using ipfix such as application name, http URL and http user agent strings. > Ipfix suggest to use private enterprise numbers for such export. Dpdk > process craft such ipfix packets and send to collector, now is there any > filter with Nfdump so that can we use to decode PEN and see given string?. > Looking forward to hearing from you nfdup needs be be aware of such private enterprise numbers in order to decode the data correctly. By default nfdump accepts only well defined elements. If you are interessted in implementing such private enterprise fields, just contact me off list. Please also have a look into nfdump1-.7 beta: https://github.com/phaag/nfdump/issues/292. It implements NBAR: https://www.cisco.com/c/en/us/products/ios-nx-os-software/network-based-application-recognition-nbar/index.html Thanks - Peter > Thanks > > > > _______________________________________________ > Nfdump-discuss mailing list > Nfd...@li... > https://lists.sourceforge.net/lists/listinfo/nfdump-discuss > -- Be nice to your netflow data. Use NfSen and nfdump :) |
From: waqas a. <waq...@gm...> - 2021-05-10 17:35:46
|
Hi, I am writing dpdk application that needs to export flow related information using ipfix such as application name, http URL and http user agent strings. Ipfix suggest to use private enterprise numbers for such export. Dpdk process craft such ipfix packets and send to collector, now is there any filter with Nfdump so that can we use to decode PEN and see given string?. Looking forward to hearing from you Thanks |
From: ken a. <ken...@cy...> - 2021-02-09 01:01:48
|
Hi Peter, Using version NSEL-NEL1.6.22, we're seeing element id BYTES_TOTAL (85) along with PKTS (2) in the raw output for (in)bytes and (in)packets respectively, instead of in the expected pairs of IDs 85 and 86 or 1 and 2. I can provide a pcap upon request. -- Ken Adey CyGlass, Inc. is a wholly-owned subsidiary of Nominet UK. Nominet UK is registered in England and Wales No. 3203859 This message is intended exclusively for the individual(s) to whom it is addressed and may contain information that is privileged, or confidential. If you are not the addressee, you must not read, use or disclose the contents of this e-mail. If you receive this e-mail in error, please advise us immediately and delete the e-mail. CyGlass, Inc. has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, Nominet cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment |
From: Peter H. <ph...@us...> - 2021-01-12 19:28:19
|
Hi Ken, It should be possible. I would appreciate, if you could send me a pcap capture of a stream coming from a Vmware exporter. I like to test the implementation. If possible, send it to my email in the AUTHERS file. Many thanks - Peter On 08.01.21 18:42, ken adey wrote: > Hi Peter, > We're seeing elements 32769 and 32770 in template 256 from VeloCloud > (see https://kb.vmware.com/s/article/79184), but they're not being parsed > by nfcapd version 1.6.21 (and nothing in the 1.6.22 ChangeLog indicating > support for these). > > Any plans on adding these? > > Thanks. > > > > _______________________________________________ > Nfdump-discuss mailing list > Nfd...@li... > https://lists.sourceforge.net/lists/listinfo/nfdump-discuss > -- Be nice to your netflow data. Use NfSen and nfdump :) |
From: ken a. <ken...@cy...> - 2021-01-08 18:51:33
|
Hi Peter, We're seeing elements 32769 and 32770 in template 256 from VeloCloud (see https://kb.vmware.com/s/article/79184), but they're not being parsed by nfcapd version 1.6.21 (and nothing in the 1.6.22 ChangeLog indicating support for these). Any plans on adding these? Thanks. -- Ken Adey CyGlass, Inc. is a wholly-owned subsidiary of Nominet UK. Nominet UK is registered in England and Wales No. 3203859 This message is intended exclusively for the individual(s) to whom it is addressed and may contain information that is privileged, or confidential. If you are not the addressee, you must not read, use or disclose the contents of this e-mail. If you receive this e-mail in error, please advise us immediately and delete the e-mail. CyGlass, Inc. has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, Nominet cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment |
From: <st...@ne...> - 2020-12-04 13:48:56
|
This is in reality a followup of a thread from January 2018: https://sourceforge.net/p/nfdump/mailman/message/36174318/ where I had IPFIX export from a Huawei router which was printed with a start time of 1. January 1970 due to missing information in the export from the router. Specifically, quoting from the message above: "To make a long story short: You need to open a ticket at the vendor to fix this at the exporter side. Possible solutions: 1. If they want to stay with the tags #21, #22, they need to send also a tag #160." I now have a fix for this problem from Huawei, where they indeed supply tag #160 (systemInitTimeMilliseconds). I have verified with Wireshark that the template data specifies tag #160, and that the flow data contains sensible values for systemInitTimeMilliseconds. However, nfdump-1.6.22 still prints the records with a start time of 1. January 1970, e.g.: % nfdump -r nfcapd.202012031325 Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows 1970-01-01 01:00:00.000 0.000 UDP 172.20.22.2:37626 -> 172.20.23.2:5201 3749 3.9 M 1 Looking at the nfdump-1.6.22 source I'm wondering if the problem now is simply missing handling of tag #160 (systemInitTimeMilliseconds). In bin/ipfix.h I see #define IPFIX_flowEndDeltaMicroseconds 159 #define IPFIX_postOctetTotalCount 171 i.e. no tag 160 here, and in bin/ipfix.c the ipfix_element_map_s ends at IPFIX_flowEndDeltaMicroseconds. Is it simply the case that tag #160 currently isn't handled by nfdump? If so, is there any possibility of adding such handling? Pcap of the Huawei IPFIX export with the tag #160 information is available at http://www.nethelp.no/ipfix.pcap Steinar Haug, AS 2116 |
From: ken a. <ken...@cy...> - 2020-11-04 19:10:16
|
This is not an nfcapd/nfdump issue, just a general question regarding netflow times. About 9 days ago we started receiving netflow data from a customer's FortiGate firewall. At that time, the date/times in the flows were about 12 days in the past. I have confirmed the "bad" times exist in the incoming raw packets. Over the next 8 days, the date/times were catching up to the current time, and then they started moving into the future, where currently they're about 2 days into the future and getting worse. My question is, has anyone seen behavior like this before? -- Ken Adey CyGlass, Inc. is a wholly-owned subsidiary of Nominet UK. Nominet UK is registered in England and Wales No. 3203859 This message is intended exclusively for the individual(s) to whom it is addressed and may contain information that is privileged, or confidential. If you are not the addressee, you must not read, use or disclose the contents of this e-mail. If you receive this e-mail in error, please advise us immediately and delete the e-mail. CyGlass, Inc. has taken every reasonable precaution to ensure that any attachment to this e-mail has been swept for viruses. However, Nominet cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment |
From: Mostaf F. <mos...@gm...> - 2020-11-01 11:48:52
|
Thanks all I want import pcap files by nfcapd and then run nfdump in verbose mode. To find problem. How I can do this? MyWebSite http://mfaridi.com On Sat, 31 Oct 2020, 15:50 Brian Candler, <b.c...@po...> wrote: > On 31/10/2020 12:18, Mostaf Faridi wrote: > > Can we have find some reference which packet make coredump > > For example > > Packet 1 make coredump > > I want find that packet by tcpdump and tell them do not send that > > packet to nfdump > > 1. If we knew which packet caused nfdump to crash, the bug would have > been fixed already. > > 2. The bug quite possibly *has* been fixed already, in versions newer > that 1.6.16. > > |
From: Brian C. <b.c...@po...> - 2020-10-31 12:21:03
|
On 31/10/2020 12:18, Mostaf Faridi wrote: > Can we have find some reference which packet make coredump > For example > Packet 1 make coredump > I want find that packet by tcpdump and tell them do not send that > packet to nfdump 1. If we knew which packet caused nfdump to crash, the bug would have been fixed already. 2. The bug quite possibly *has* been fixed already, in versions newer that 1.6.16. |
From: Mostaf F. <mos...@gm...> - 2020-10-31 12:19:03
|
Thanks, I'll check it out. Can we have find some reference which packet make coredump For example Packet 1 make coredump I want find that packet by tcpdump and tell them do not send that packet to nfdump MyWebSite http://mfaridi.com On Sat, 31 Oct 2020, 15:45 Brian Candler, <b.c...@po...> wrote: > On 31/10/2020 11:58, Mostaf Faridi wrote: > > Thank you for the clarification. > > How I undrestand which netflow make this error? > > By debugging the C code. > > Of course, the problem may have been fixed already, so before wasting > your time, you should first build nfcapd and nfdump from git HEAD and > see if the problem remains. > > Here are some of the many commits since 1.6.16 which might have fixed > your problem: > > commit c2a976e738fa1bf8d140bdd0cc45685b880dd63d > Author: Peter Haag <pe...@pe...> > Date: Fri Nov 8 07:34:55 2019 +0100 > > Fix corrupt file handling #193 > > commit 7bd6d5b81f68224d23c1df3dff066e35b20fae6c > Author: Peter Haag <pe...@pe...> > Date: Mon Aug 5 09:39:01 2019 +0200 > > Fix off by 1 array. #173 > > commit 9f0fe9563366f62a71d34c92229da3432ec5cf0e > Author: Peter Haag <pe...@pe...> > Date: Sun Apr 1 10:30:25 2018 +0200 > > Fix nfdump crashes, when feeded with garbage input. Issue #104 > > commit b776f8df7028059863b1e89cd8f52f2afaebbdc8 > Author: Peter Haag <peter@Pegasus.local> > Date: Thu Dec 21 17:21:44 2017 +0100 > > Fix wrong offset calculation if unknown options are found > > For the last of those commits, there are more details in issue #77: > https://github.com/phaag/nfdump/issues/77 > > If the problem still exists in current code, then you should find a C > programmer who knows how to drive gdb to help you with the debugging. > > Regards, > > Brian. > > |
From: Brian C. <b.c...@po...> - 2020-10-31 12:15:16
|
On 31/10/2020 11:58, Mostaf Faridi wrote: > Thank you for the clarification. > How I undrestand which netflow make this error? By debugging the C code. Of course, the problem may have been fixed already, so before wasting your time, you should first build nfcapd and nfdump from git HEAD and see if the problem remains. Here are some of the many commits since 1.6.16 which might have fixed your problem: commit c2a976e738fa1bf8d140bdd0cc45685b880dd63d Author: Peter Haag <pe...@pe...> Date: Fri Nov 8 07:34:55 2019 +0100 Fix corrupt file handling #193 commit 7bd6d5b81f68224d23c1df3dff066e35b20fae6c Author: Peter Haag <pe...@pe...> Date: Mon Aug 5 09:39:01 2019 +0200 Fix off by 1 array. #173 commit 9f0fe9563366f62a71d34c92229da3432ec5cf0e Author: Peter Haag <pe...@pe...> Date: Sun Apr 1 10:30:25 2018 +0200 Fix nfdump crashes, when feeded with garbage input. Issue #104 commit b776f8df7028059863b1e89cd8f52f2afaebbdc8 Author: Peter Haag <peter@Pegasus.local> Date: Thu Dec 21 17:21:44 2017 +0100 Fix wrong offset calculation if unknown options are found For the last of those commits, there are more details in issue #77: https://github.com/phaag/nfdump/issues/77 If the problem still exists in current code, then you should find a C programmer who knows how to drive gdb to help you with the debugging. Regards, Brian. |
From: Mostaf F. <mos...@gm...> - 2020-10-31 12:02:18
|
I want undrestand which netflow packages make core dump MyWebSite http://mfaridi.com On Sat, 31 Oct 2020, 15:28 Mostaf Faridi, <mos...@gm...> wrote: > Thank you for the clarification. > How I undrestand which netflow make this error? > > Best Regards > Faridi > > MyWebSite http://mfaridi.com > > On Sat, 31 Oct 2020, 15:24 Brian Candler, <b.c...@po...> wrote: > >> On 31/10/2020 08:43, Mostaf Faridi wrote: >> > I run on server this >> > >> > Tcpdump -i bge0 -w file.pcap >> > >> > For 3 min >> > When I run >> > Nfdump -r file.pcap >> > >> > I see this error >> > >> > Openfile 'file.pcap' : bad magic: 0xC3D4 >> >> Sorry my mistake: pcap files are read by nfcapd, not nfdump. So you'd >> need to do: >> >> nfcapd -f file.pcap .... >> >> nfdump reads nfdump-format data files, which are *written* by nfcapd. >> >> Now, you're saying it's not nfcapd that crashes, but nfdump. This could >> mean one of two things: >> >> 1. The problematic netflow data is causing nfcapd to write out an >> invalid nfdump-format file (which in turn causes nfdump to crash); or >> >> 2. nfcapd is writing out a valid nfdump-format file, but nfdump crashes >> on that specific flow >> >> I'm afraid you'll need to do some C debugging to find out which of these >> cases it is. >> >> Regards, >> >> Brian. >> >> |
From: Mostaf F. <mos...@gm...> - 2020-10-31 11:58:30
|
Thank you for the clarification. How I undrestand which netflow make this error? Best Regards Faridi MyWebSite http://mfaridi.com On Sat, 31 Oct 2020, 15:24 Brian Candler, <b.c...@po...> wrote: > On 31/10/2020 08:43, Mostaf Faridi wrote: > > I run on server this > > > > Tcpdump -i bge0 -w file.pcap > > > > For 3 min > > When I run > > Nfdump -r file.pcap > > > > I see this error > > > > Openfile 'file.pcap' : bad magic: 0xC3D4 > > Sorry my mistake: pcap files are read by nfcapd, not nfdump. So you'd > need to do: > > nfcapd -f file.pcap .... > > nfdump reads nfdump-format data files, which are *written* by nfcapd. > > Now, you're saying it's not nfcapd that crashes, but nfdump. This could > mean one of two things: > > 1. The problematic netflow data is causing nfcapd to write out an > invalid nfdump-format file (which in turn causes nfdump to crash); or > > 2. nfcapd is writing out a valid nfdump-format file, but nfdump crashes > on that specific flow > > I'm afraid you'll need to do some C debugging to find out which of these > cases it is. > > Regards, > > Brian. > > |
From: Brian C. <b.c...@po...> - 2020-10-31 11:54:22
|
On 31/10/2020 08:43, Mostaf Faridi wrote: > I run on server this > > Tcpdump -i bge0 -w file.pcap > > For 3 min > When I run > Nfdump -r file.pcap > > I see this error > > Openfile 'file.pcap' : bad magic: 0xC3D4 Sorry my mistake: pcap files are read by nfcapd, not nfdump. So you'd need to do: nfcapd -f file.pcap .... nfdump reads nfdump-format data files, which are *written* by nfcapd. Now, you're saying it's not nfcapd that crashes, but nfdump. This could mean one of two things: 1. The problematic netflow data is causing nfcapd to write out an invalid nfdump-format file (which in turn causes nfdump to crash); or 2. nfcapd is writing out a valid nfdump-format file, but nfdump crashes on that specific flow I'm afraid you'll need to do some C debugging to find out which of these cases it is. Regards, Brian. |
From: Mostaf F. <mos...@gm...> - 2020-10-31 08:44:02
|
Hi thanks I run on server this Tcpdump -i bge0 -w file.pcap For 3 min When I run Nfdump -r file.pcap I see this error Openfile 'file.pcap' : bad magic: 0xC3D4 Best regards Faridi MyWebSite http://mfaridi.com On Thu, 29 Oct 2020, 19:23 Brian Candler, <b.c...@po...> wrote: > On 29/10/2020 11:35, Mostaf Faridi wrote: > > I use nfdump-1.6.16_1 > > They installed this version of nfdump on many servers. Only on one > > server, I see core dump. > > Nfdump installed on FreeBSD box and traffic comes from centos OS. > > Where I must run nfdump . on FreeBSD box or Centos box? > > You run nfcapd on whatever server the Netflow packets arrive at. It > writes files containing the netflow data, normally one file every 5 > minutes. > > You run nfdump on whatever server is reading the files written by > nfcapd. It might be the same server, or a different one - e.g. if the > files are shared over NFS. > > > I want know which packages can make cordump. For example which package > > like tcp or udp packages make core dump? > > The operating system writes a core dump when a program crashes, e.g. > because it executes an illegal instruction or tries to access > out-of-bounds memory. > > > If I run tcpdump how I understand which packet make core dump? > > > tcpdump is mainly useful for capturing packets, so you can feed them > back into nfcapd or nfdump, and reproduce the problem on demand. > > However with or without tcpdump, you still need to: > > - compile nfdump 1.6.20 from source > - run it until it crashes > - use gdb to read the coredump > - perform a backtrace and inspect variables to work out what caused the > crash > > OR > > - compile nfdump 1.6.20 from source > - run it *under gdb* until it crashes > - perform a backtrace and inspect variables to work out what caused the > crash > > However, this is not the list to explain how to debug C code. I suggest > you find a local system administrator and/or C programmer who can help you. > > |
From: Brian C. <b.c...@po...> - 2020-10-29 15:53:28
|
On 29/10/2020 11:35, Mostaf Faridi wrote: > I use nfdump-1.6.16_1 > They installed this version of nfdump on many servers. Only on one > server, I see core dump. > Nfdump installed on FreeBSD box and traffic comes from centos OS. > Where I must run nfdump . on FreeBSD box or Centos box? You run nfcapd on whatever server the Netflow packets arrive at. It writes files containing the netflow data, normally one file every 5 minutes. You run nfdump on whatever server is reading the files written by nfcapd. It might be the same server, or a different one - e.g. if the files are shared over NFS. > I want know which packages can make cordump. For example which package > like tcp or udp packages make core dump? The operating system writes a core dump when a program crashes, e.g. because it executes an illegal instruction or tries to access out-of-bounds memory. > If I run tcpdump how I understand which packet make core dump? > tcpdump is mainly useful for capturing packets, so you can feed them back into nfcapd or nfdump, and reproduce the problem on demand. However with or without tcpdump, you still need to: - compile nfdump 1.6.20 from source - run it until it crashes - use gdb to read the coredump - perform a backtrace and inspect variables to work out what caused the crash OR - compile nfdump 1.6.20 from source - run it *under gdb* until it crashes - perform a backtrace and inspect variables to work out what caused the crash However, this is not the list to explain how to debug C code. I suggest you find a local system administrator and/or C programmer who can help you. |
From: Mostaf F. <mos...@gm...> - 2020-10-29 11:35:30
|
Cool, thanks! I use nfdump-1.6.16_1 They installed this version of nfdump on many servers. Only on one server, I see core dump. Nfdump installed on FreeBSD box and traffic comes from centos OS. Where I must run nfdump . on FreeBSD box or Centos box? I want know which packages can make cordump. For example which package like tcp or udp packages make core dump? If I run tcpdump how I understand which packet make core dump? Best Regards Faridi MyWebSite http://mfaridi.com On Thu, 29 Oct 2020, 14:29 Brian Candler, <b.c...@po...> wrote: > On 28/10/2020 11:46, Mostaf Faridi wrote: > > Hi, > > I use nfdump 1.6 > > That must be very old then. The current version is 1.6.20. I'd start > by upgrading to that. > > > > Sometimes I see this error > > Kernel:pid 75614 (nfdump),uid 0:exited on signal 11 (core dumped) > > > > Kernel:pid 76732 (nfdump), uid 0:exited on signal 10 (core dumped) > > > > I want know which packet make core dump? > > You can use gdb to read the core dump and tell you exactly what line of > code crashed, and inspect all the variables, which will let you work out > the code path and hence the packet. > > Alternatively, you could capture a load of packets at the same time > (e.g. with tcpdump -w file.pcap ...), and then replay them to nfdump > (nfdump -r file.pcap) until you find the offending packet. > > It might not even be a bad packet. signal 11 (SEGV) can also be caused > by hardware errors, e.g. bad RAM. But if you only see this with nfdump, > and not when doing something else which stresses the CPU (e.g. compiling > a kernel), then it's probably nfdump. > |
From: Brian C. <b.c...@po...> - 2020-10-29 10:59:38
|
On 28/10/2020 11:46, Mostaf Faridi wrote: > Hi, > I use nfdump 1.6 That must be very old then. The current version is 1.6.20. I'd start by upgrading to that. > Sometimes I see this error > Kernel:pid 75614 (nfdump),uid 0:exited on signal 11 (core dumped) > > Kernel:pid 76732 (nfdump), uid 0:exited on signal 10 (core dumped) > > I want know which packet make core dump? You can use gdb to read the core dump and tell you exactly what line of code crashed, and inspect all the variables, which will let you work out the code path and hence the packet. Alternatively, you could capture a load of packets at the same time (e.g. with tcpdump -w file.pcap ...), and then replay them to nfdump (nfdump -r file.pcap) until you find the offending packet. It might not even be a bad packet. signal 11 (SEGV) can also be caused by hardware errors, e.g. bad RAM. But if you only see this with nfdump, and not when doing something else which stresses the CPU (e.g. compiling a kernel), then it's probably nfdump. |
From: Mostaf F. <mos...@gm...> - 2020-10-28 11:55:51
|
Hi, I use nfdump 1.6 Sometimes I see this error Kernel:pid 75614 (nfdump),uid 0:exited on signal 11 (core dumped) Kernel:pid 76732 (nfdump), uid 0:exited on signal 10 (core dumped) I want know which packet make core dump? Best regards, Faridi MyWebSite http://mfaridi.com |
From: Glenn F. F. L. <gl...@co...> - 2020-04-17 16:22:32
|
I cannot find in the nfdump man page any way to display or filter on the "domain observation id" in a particular flowrecord - does such a capability exist? Thanks, -g -- Glenn Forbes Fleming Larratt Cornell University IT Security Office |
From: Brian C. <b.c...@po...> - 2019-10-03 12:29:11
|
On 03/10/2019 13:13, nfd...@li... wrote: > > I have setup from this link > https://blog.alexgittings.com/installing-nfsen-on-ubuntu/. And things > seems to work but I am not sure if it is correct. > > root@NETFLOW:/home/ubuntu# ps -ax | grep nfs > > 5090 ? Ss 0:00 /var/netflow/bin/nfsend-comm > > 5167 ? Ss 0:10 /usr/bin/perl -w /var/netflow/bin/nfsend > > 5168 ? Ss 0:01 /var/netflow/bin/nfsend-comm > > 7316 pts/0 S+ 0:00 grep --color=auto nfs > > root@NETFLOW:/home/ubuntu# ps -ax | grep nfc > > 5163 ? S 0:00 /usr/local/bin/nfcapd -w -D -p 9995 -u > netflow -g www-data -B 200000 -S 1 -P /var/netflow/var/run/p9995.pid > -z -I upstream1 -l /var/netflow/profiles-data/live/upstream1 > > 7318 pts/0 S+ 0:00 grep --color=auto nfc > > This is what I have after the install . The problem is on my Router > its keeps saying zero flow successfully send yet I can ping from my > router to my collector. > Based on your 'ps' output it looks like you have nfsend and nfcapd running happily. You should see files appearing under /var/netflow/profiles-data/live/upstream1 - maybe they are all small and the same size (276 bytes?) which indicates nothing being written. The most important thing to check is whether your router is actually sending any flow data. On your netflow server, listen for netflow data like this: tcpdump -i eth0 -nn udp port 9995 If nothing arrives, then either the router isn't sending any flow data, or some intervening firewall is blocking the packets. How you fix that depends on what sort of router you have, and what sort of firewalling/filtering exists on your network. You might find these docs useful (they include configuration commands for IOS Flexible Netflow): https://nsrc.org/activities/agendas/en/nmm-5-days/netmgmt/en/netflow/exercise1-flow-export.html https://nsrc.org/activities/agendas/en/nmm-5-days/netmgmt/en/netflow/exercise2-install-nfdump-nfsen.html https://nsrc.org/activities/agendas/en/nmm-5-days/netmgmt/en/netflow/exercise3-nfsen-top-talkers.html https://nsrc.org/activities/agendas/en/nmm-5-days/netmgmt/en/netflow/exercise4-using-NfSen.pdf |
From: Maile H. <mai...@tc...> - 2019-10-03 03:10:29
|
I try to install but I could not get everything to works. Please anyone with workable steps ... I understand there is a lot to do to put together everything . since I am new to this I hope someone would share some lights . Thanks in advance. FYI I have setup from this link https://blog.alexgittings.com/installing-nfsen-on-ubuntu/ . And things seems to work but I am not sure if it is correct. root@NETFLOW:/home/ubuntu# ps -ax | grep nfs 5090 ? Ss 0:00 /var/netflow/bin/nfsend-comm 5167 ? Ss 0:10 /usr/bin/perl -w /var/netflow/bin/nfsend 5168 ? Ss 0:01 /var/netflow/bin/nfsend-comm 7316 pts/0 S+ 0:00 grep --color=auto nfs root@NETFLOW:/home/ubuntu# ps -ax | grep nfc 5163 ? S 0:00 /usr/local/bin/nfcapd -w -D -p 9995 -u netflow -g www-data -B 200000 -S 1 -P /var/netflow/var/run/p9995.pid -z -I upstream1 -l /var/netflow/profiles-data/live/upstream1 7318 pts/0 S+ 0:00 grep --color=auto nfc This is what I have after the install . The problem is on my Router its keeps saying zero flow successfully send yet I can ping from my router to my collector. I hope someone would help. Thanks Confidentiality Notice: This email (including any attachment) is intended for internal use only. Any unauthorized use, dissemination or copying of the content is prohibited. If you are not the intended recipient and have received this e-mail in error, please notify the sender by email and delete this email and any attachment. |