Activity for RCDCap
-
Josh posted a comment on ticket #6
@zero_effect I know this is over a year old, but will you make a new version with this fix? 1.0.5 is throwing the make_shared error when trying to compile on CentOS 7, or Amazon Linux 2. When pulling the latest code via hg, the error is gone because of the fix. I prefer to lockdown our RCDCap versions, however the workaround is to pull using hq.
-
Zero effect posted a comment on ticket #6
Alright, try the latest revision and if it works, I will make a new version.
-
CentOS 7 fixes
-
Zdravko Velinov committed [70e874]
switched regex to boost
-
Sorry for the late reply, I am quite busy these days. As far as compiling goes I don't think that I properly support earlier versions of gcc anymore. It can be made to compile, however, the standard c++11 standard library is really buggy in those earlier compilers. I might noodle around a little bit and see whether it can work with boost instead.
-
Eric H created ticket #6
Compile Error CentOS 7
-
Henry Loh created ticket #5
CentOS 8 RPM Spec Includes Conflicting Directories
-
RCDCap released /RCDCap-1.0.5-Source.tar.bz2
-
Zdravko Velinov committed [62b36e]
Bumped version
-
bugtester@bugtester-VirtualBox committed [5a6863]
offset fix
-
bugtester@bugtester-VirtualBox committed [0af056]
added bounds checks - should fix crashes
-
Handling of exception thrown in a worker thread
-
and the test case is fixed, but that implies that an exception is thrown in a worker thread that basically leads to everything crumbling apart
-
reproduction test case for the buffer corruption bug
-
merge
-
Chris Ray posted a comment on ticket #4
gdb -batch -ex "run" -ex "bt" --args rcdcap -i ens192 --erspan --tap-persist --tap-dev ice mon1 2>&1 | grep -v ^"No stack."$ [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". listening on ens192 (EN10MB), capture size 1518 bytes worker threads: 8 on 8 CPUs [New Thread 0x7fffecf79700 (LWP 6642)] [New Thread 0x7fffec778700 (LWP 6643)] [New Thread 0x7fffebf77700 (LWP 6644)] [New Thread 0x7fffeb776700 (LWP 6645)] [New Thread 0x7fffeaf75700...
-
We have succesfully built 1.0.4-r2, installing now to test.
-
Zdravko Velinov committed [758076]
build fix
-
Check 1.0.4-r2. It should now build with pfring enabled.
-
-
Hello, we are unable to build the newest release. Please see the error output below. /usr/local/src/RCDCap-1.0.4-Source/src/pfring-source.cc: In member function 'virtual void RCDCap::PF_RINGDataSource::start()': /usr/local/src/RCDCap-1.0.4-Source/src/pfring-source.cc:84:104: error: no matching function for call to 'RCDCap::PacketInfo::init(int, RCDCap::Time, u_int32_t&, u_int32_t&, size_t&)' packet_info->init(DLT_EN10MB, Time(header.ts), header.caplen, header.len, count); ^ In file included from...
-
Getting segfault with Ubuntu 18.04
-
Ok, I found at least another bug that I was able to reproduce - check the latest release 1.0.4.
-
-
fixed bad packet lost computation
-
Ok, there are some possible corner cases when that functionality can fail. Can you download the latest revision from the repo (hg.code.sf.net/p/rcdcap/code rcdcap-code) and use it instead to validate whether my guess is correct?
-
Fixed initialization on push
-
merge
-
bumped version
-
Here is another one, after loading ip_gre Module into OS kernel and adjusting source interface MTU to 9000 rcdcap: /usr/local/src/RCDCap-1.0.3-Source/src/common-buffer.cc:232: RCDCap::PacketInfo RCDCap::CommonBuffer::next(RCDCap::PacketInfo) const: Assertion `packet_info->m_DebugMagic == 0x1337' failed. Thread 2 "rcdcap" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffecf79700 (LWP 14689)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c:...
-
Good morning, below the the output of GDB while running 1.0.3. Thank you for all your effort put into this project! rcdcap: /usr/local/src/RCDCap-1.0.3-Source/src/common-buffer.cc:232: RCDCap::PacketInfo RCDCap::CommonBuffer::next(RCDCap::PacketInfo) const: Assertion `packet_info->m_DebugMagic == 0x1337' failed. Thread 7 "rcdcap" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffea774700 (LWP 12750)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c:...
-
Yes I can, thank you! Ill report back the results. Do you need any more data from me to assist in troubleshooting?
-
Zdravko Velinov committed [768b17]
bumped version number
-
Ok, it seems to be a new problem with ASIO. Can you try 1.0.3?
-
-
switched from async_write_some to async_write
-
Good morning, unfortunetly rcdcap crashed again. rcdcap: /usr/local/src/RCDCap-1.0.2-Source/src/sink.cc:257: void RCDCap::TAPDeviceSink::writeCompleted(RCDCap::PacketInfo*, size_t, size_t, const boost::system::error_code&, std::size_t): Assertion `bytes_transferred == packet_info->getPCAPHeader().getCapturedLength()' failed. Thread 3 "rcdcap" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffec77b700 (LWP 7922)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c:...
-
Disabling rewind on stop
-
merge
-
Newest version compiled and running, so far so good. Ill report back the results if it should crash or if we stay up all day
-
Ok, can you try the latest version (1.0.2)? It fixes at least one source of memory corruption.
-
Zdravko Velinov committed [89466c]
bumped up the version
-
Ok, can you try the latest version (1.0.2). It fixes at least one source of memory corruption.
-
-
updated documentation
-
Fixed crash in discard sink
-
merge
-
Thread 2 "rcdcap" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffecf7d700 (LWP 32263)] __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:493 493 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory. 0 __memmove_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:493 1 0x00005555556bf5e3 in unsigned char std::__copy_move<false, true,="" std::random_access_iterator_tag="">::__copy_m<unsigned...
-
Can you run from command line with gdb attached and copy the backtrace when it crashes: sudo gdb -batch -ex "run" -ex "bt" --args ./rcdcap -i ens0 --erspan --tap-persist --tap-device mon1 2>&1 | grep -v ^"No stack."$
-
Getting segfault with Ubuntu 18.04
-
Back trace = core dump? Also, I have tried 1.0.1 but the crash still occurs. Thank you!
-
Also, can you test the newer version that I released (1.0.1) that fixes a crash on init?
-
-
Zdravko Velinov committed [abd433]
fixed crash on init
-
one-way traffic only
-
Can you provide a backtrace? Also consider opening an issue in the tickets system.
-
Hello, I am looking for some help diagnosing an issue we are having when running RCDCAP 1.0.0 on Ubunutu 18.04 LTS. Dependencies installed are libpcap0.8, libboost-system1.65.1, libboost-program-options1.65.1, libboost-thread1.65.1. RCDCAP will crash anywhere from immediatly upon issuing the startup command to 15-20 minutes later. We are running it with the following flags: rcdcap -i ens0 --erspan --tap-persist --tap-device mon1
-
-
Zdravko Velinov committed [4380f4]
Clean up
-
added also support for the injection sink
-
bumped the version number
-
tap devices now work on windows
-
updated cxxopts
-
merge
-
Zdravko Velinov committed [cc6063]
Fixed null pointer dereference
-
fixed multiple expressions
-
merge
-
removed dependency on boost program options
-
* Fixed: the text sink should no longer get stuck
-
thanks message
-
Rick McClinton posted a comment on discussion General Discussion
Yes, I agree about the 10G - fortunately the bottleneck on my target segment is currently 1G. I've played with the command line options using --dummy "benchmarks"; I think I am seeing better performance using default worker threads (32) and --buffer-size 1024MB. The typical result is to see slightly fewer packets captured by the application than by the kernel, with zero drops by kernel/driver/buffer. "Better performance" meaning less difference between application and kernel counters. I've also been...
-
Zero effect posted a comment on ticket #2
Are the remote packets in one direction or the local packets?
-
You can increase the internal buffer size, but it won't help you for sustained 10G load. Try running it in dummy mode, this will tell us whether it is bottlenecked by libpcap.
-
I have installed RCDCap 0.9 on SecurityOnion latest. I had to use libboost1.58 to compile, and had to hack the cmake file to update the obsolete dependencies. The hardware has 2x 10G interfaces bonded as a VLAN trunk for both server access and to deliver ERSPAN from two Nexus 9000 switches. RCDCap command line is rcdcap -i bond0.1005 -s 65535 --erspan --tap-persist --tap-device mon1 --worker-threads 8 --expression "proto gre" I am getting lots of drop indicated, e.g. quite soon after a reboot ifconfig...
-
I had to set "no header-format 3" on my Nexus to get ERSPAN-2 packets, which are being decoded properly by RCDCap. Do you still want ERSPAN-3 captures?
-
[FIXED} Custom Header Size to Decapsulate
-
Custom Header Size to Decapsulate
-
-
Jawad Rajput posted a comment on ticket #3
it worked, thanks a lot.
-
yes, you need to recompile
-
Thank you very much. I will try and let you know how it goes, I just want to confirm that I am replacing erspan-processor.cc and then recomplie rpm for CentOS-7, right? Or can I just replace erspan-processor.cc on already installed system?
-
Another user (Walter Shoeber) suggested a patch for Juniper routers. I just commited slightly altered version in the Mercurial repo. Can you test it and say whether it fixes your issue?
-
zeroeffect@zeroeffect-To-be-filled-by-O-E-M committed [243e39]
Type I decap as suggested by Walter Schober
-
Hello RCDCap Team, I have a question about decapsulating headers based on custom size. For Example, in our environment the ERSPAN header size is 38 bytes instead of 50 bytes, I have confirmed that using editcap utility on CentOS-7, when I take off 38 bytes off I can see actual SPAN traffic instead of GRE tunnel traffic. When I use RCDCap to decapsulate it takes some extra bytes of and loose Ether and IP headers. Is there a way to hardcore static length, e.g. 38 bytes, to decapsulate ERSPAN with RCDCap?...
-
Custom Header Size to Decapsulate
-
black88mx6 posted a comment on discussion General Discussion
I am having the same issue on Ubuntu 16.04.4 LTS, sending to briged ethernet/tap seems modify the packets. Any aditional details on why the -I is not working? Permissions?
-
I need binary files with original packets
-
Zdenek Dlouhy posted a comment on discussion General Discussion
06:01:40.969924 IP 10.132.63.1 > localhost.localdomain: GREv0, seq 832271090, length 242: gre-proto-0x22eb 06:01:40.970929 IP 10.132.63.1 > localhost.localdomain: GREv0, seq 898777497, length 242: gre-proto-0x22eb 06:01:40.980932 IP 10.132.63.1 > localhost.localdomain: GREv0, seq 898777498, length 242: gre-proto-0x22eb 06:01:40.982913 IP 10.132.63.1 > localhost.localdomain: GREv0, seq 832271091, length 242: gre-proto-0x22eb 06:01:40.984911 IP 10.132.63.1 > localhost.localdomain: GREv0, seq 898777499,...
-
I meant just an encapsulated stream of packets, so that i can debug it.
-
I meant just a encapsulated stream of packets, so that i can debug it.
-
The problem is, that I'm still getting gre encapsulated dump and I think it's caused by erspan version header type 0x22eb. ERSPAN v1 header type is 0x88be My dump from RCDCap: (tos 0x28, ttl 25, id 64066, offset 0, flags [none], proto GRE (47), length 262) 10.132.63.1 > localhost.localdomain: GREv0, Flags [sequence# present], seq 832122434, length 242 gre-proto-0x22eb rcdcap -i ens33 --erspan --tap-persist --tap-device mon1 --expression "host 10.132.1.241"
-
Can you provide a very simple capture of ping (ICMP) packets?
-
Hi all, is there any way how to change RCDCap configuration for decapsulating erspan version 3 ???? Thanks.
-
Zdravko Velinov committed [4777f2]
Fix for older cmake versions
-
Zdravko Velinov committed [e6cd2f]
merge
-
Julien posted a comment on discussion General Discussion
Hi, cmake version 2.8.12.2 regards,
-
What is your version of cmake? Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Julien nirlya@users.sourceforge.net Date: 3/27/18 15:06 (GMT+01:00) To: "[rcdcap:discussion]" general@discussion.rcdcap.p.re.sourceforge.net Subject: [rcdcap:discussion] Packet truncation Hi, I still have a problem with compilation : [ 85%] Building CXX object src/CMakeFiles/rcdcap.dir/rcdcap-main.cc.o cd /tmp/rcdcap-code/source/build-make/src && /usr/bin/c++ -DLINUX -I/tmp/rcdcap-code/source/build-make/include...
-
Hi, I still have a problem with compilation : [ 85%] Building CXX object src/CMakeFiles/rcdcap.dir/rcdcap-main.cc.o cd /tmp/rcdcap-code/source/build-make/src && /usr/bin/c++ -DLINUX -I/tmp/rcdcap-code/source/build-make/include -I/tmp/rcdcap-code/source/include -pedantic -Wall -Wno-long-long -std=c++0x -mcx16 -msse -msse2 -mssse3 -pthread -o CMakeFiles/rcdcap.dir/rcdcap-main.cc.o -c /tmp/rcdcap-code/source/src/rcdcap-main.cc In file included from /tmp/rcdcap-code/source/include/rcdcap/sink.hh:25:0,...
1 >