All, Just trying to find a suitable collector for NEL from an ASR1k doing CGNAT, so trying nfdump 1.6.10.
My current collector box is a Sun Sparc box running 64 bit Debian 6.0.6 Whenever I started nfcapd ( nfcapd -w -I ar-01_ixn -p 2055 -B200000 -S1 -l /content/netflow/ar-01.ixn -P /content/netflow/ar-01.ixn/nfcapd.pid ), it would die not long after starting with a Bus Error. Running it inside gdb or strace, it wouldn't die, however loading a coredump into gdb showed it dying here: [email protected]:~# gdb /usr/local/bin/nfcapd core GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/bin/nfcapd...done. Reading symbols from /lib/ultra3/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ultra3/libresolv.so.2 Reading symbols from /lib/ultra3/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/ultra3/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Core was generated by `nfcapd -w -I ar-01_ixn -p 2055 -B200000 -S1 -l /content/netflow/ar-01.ixn -P /c'. Program terminated with signal 10, Bus error. #0 Process_v9_data (in_buff=0x6c3f8, in_buff_cnt=<value optimized out>, fs=0x1) at netflow_v9.c:1686 1686 *((uint64_t *)&out[output_offset]) = 0; (gdb) where #0 Process_v9_data (in_buff=0x6c3f8, in_buff_cnt=<value optimized out>, fs=0x1) at netflow_v9.c:1686 #1 Process_v9 (in_buff=0x6c3f8, in_buff_cnt=<value optimized out>, fs=0x1) at netflow_v9.c:2090 #2 0x0006a108 in ?? () #3 0x0006a10c in ?? () I believe this issue is that you're trying to do a 64bit write to something that isn't 64bit aligned. The patch below changes it to a number of 32bit writes instead, and now it's running fine without crashing (doing >600,000 "flows" per 5 minute period). Hope this is helpful, Simon diff -ur nfdump-1.6.10/bin/netflow_v9.c nfdump-master/bin/netflow_v9.c --- nfdump-1.6.10/bin/netflow_v9.c 2013-05-08 16:19:30.000000000 +0100 +++ nfdump-master/bin/netflow_v9.c 2013-06-27 11:42:24.000000000 +0100 @@ -1683,17 +1683,20 @@ *((uint32_t *)&out[output_offset]) = 0; break; case zero64: - *((uint64_t *)&out[output_offset]) = 0; - break; + { *((uint32_t *)&out[output_offset]) = 0; + *((uint32_t *)&out[output_offset+4]) = 0; + } break; case zero96: { *((uint32_t *)&out[output_offset]) = 0; *((uint32_t *)&out[output_offset+4]) = 0; *((uint32_t *)&out[output_offset+8]) = 0; } break; case zero128: - *((uint64_t *)&out[output_offset]) = 0; - *((uint64_t *)&out[output_offset+8]) = 0; - break; + { *((uint32_t *)&out[output_offset]) = 0; + *((uint32_t *)&out[output_offset+4]) = 0; + *((uint32_t *)&out[output_offset+8]) = 0; + *((uint32_t *)&out[output_offset+12]) = 0; + } break; default: syslog(LOG_ERR, "Process_v9: Software bug! Unknown Sequence: %u. at %s line %d", ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Nfdump-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
