Closed GoogleCodeExporter closed 9 years ago
Did this happen after the fix for Issue 15 was pulled down?
Original comment by gconnell@google.com
on 24 Jun 2014 at 3:49
Hello!
Yes, I'm use already fixed version:
140 data = data[:ci.CaptureLength]
Original comment by pavel.odintsov
on 24 Jun 2014 at 6:37
Hey, Pavel,
I'm trying to reproduce this locally and as yet I'm not having any luck.
Can you drop me the version of PF_RING you're currently using? Also, I'm
wondering if maybe the pfring isn't happy about being passed between multiple
threads. Maybe try using runtime.LockOSThread() before your call to Packets()
and see if that makes the issue go away?
Thanks for the patience, and hopefully we can figure this out soon.
Original comment by gsconn...@gmail.com
on 26 Jun 2014 at 5:58
Hello!
I suppose this bug is fixed! I found new bug (not yours!) when PF_RING library
does not match to PF_RING kernel module exactly. I result to unexpected
segfaults like this.
When I upgraded module and library to same up to date version all be fine.
Memory consumption is ok too:
18526 root 20 0 130m 65m 3132 R 104.5 0.2 2:40.94 anomaly_detecto
Thank you for you help and your excellen facility for processing packets! :)
Original comment by pavel.odintsov
on 30 Jun 2014 at 8:46
But my C++ tool (maybe it's interesting for you
https://github.com/FastVPSEestiOu/fastnetmon) with PF_RING works many time
faster then plain gopacket! :)
18526 root 20 0 130m 65m 3132 R 104.5 0.2 5:19.80 anomaly_detecto
13785 root 20 0 108m 4684 2380 S 38.6 0.0 137:09.55 fastnetmon
Good way for opmitiozation :)
Original comment by pavel.odintsov
on 30 Jun 2014 at 8:50
Judging from update #4, I'm going to mark this bug fixed. Thanks again for all
your help :)
Original comment by gsconn...@gmail.com
on 4 Jul 2014 at 1:38
Original issue reported on code.google.com by
pavel.odintsov
on 23 Jun 2014 at 8:49