Actions
Bug #1165
closedaf_packet - one thread consistently not working
Affected Versions:
Effort:
Difficulty:
Label:
Description
Suricata 2.0 is not affected by this issue.
This issue affects only the current git master when running af_packet with workers.
It seems that one thread is never working.
grep kernel stats.log | tail -32 capture.kernel_packets | AFPacketeth31 | 9523057 capture.kernel_drops | AFPacketeth31 | 380976 capture.kernel_packets | AFPacketeth32 | 8901220 capture.kernel_drops | AFPacketeth32 | 238163 capture.kernel_packets | AFPacketeth33 | 9159105 capture.kernel_drops | AFPacketeth33 | 275809 capture.kernel_packets | AFPacketeth34 | 0 capture.kernel_drops | AFPacketeth34 | 0 capture.kernel_packets | AFPacketeth35 | 8664225 capture.kernel_drops | AFPacketeth35 | 264977 capture.kernel_packets | AFPacketeth36 | 9500316 capture.kernel_drops | AFPacketeth36 | 272786 capture.kernel_packets | AFPacketeth37 | 9211077 capture.kernel_drops | AFPacketeth37 | 310315 capture.kernel_packets | AFPacketeth38 | 9222884 capture.kernel_drops | AFPacketeth38 | 285394 capture.kernel_packets | AFPacketeth39 | 9136390 capture.kernel_drops | AFPacketeth39 | 286365 capture.kernel_packets | AFPacketeth310 | 10266882 capture.kernel_drops | AFPacketeth310 | 329302 capture.kernel_packets | AFPacketeth311 | 7989962 capture.kernel_drops | AFPacketeth311 | 234614 capture.kernel_packets | AFPacketeth312 | 8289363 capture.kernel_drops | AFPacketeth312 | 258454 capture.kernel_packets | AFPacketeth313 | 8444730 capture.kernel_drops | AFPacketeth313 | 261794 capture.kernel_packets | AFPacketeth314 | 8903356 capture.kernel_drops | AFPacketeth314 | 331409 capture.kernel_packets | AFPacketeth315 | 8347616 capture.kernel_drops | AFPacketeth315 | 207902 capture.kernel_packets | AFPacketeth316 | 8679327 capture.kernel_drops | AFPacketeth316 | 245890
That is persistent across Suricata restarts, just different thread (usually either thread number 1 or thread number 4).
suricata --build-info This is Suricata version 2.0dev (rev ab50387) Features: PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 PF_RING AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK HAVE_NSS HAVE_LUAJIT HAVE_LIBJANSSON SIMD support: SSE_4_2 SSE_4_1 SSE_3 Atomic intrisics: 1 2 4 8 16 byte(s) 64-bits, Little-endian architecture GCC version 4.6.3, C version 199901 compiled with -fstack-protector compiled with _FORTIFY_SOURCE=2 L1 cache line size (CLS)=64 compiled with LibHTP v0.5.10, linked against LibHTP v0.5.10 Suricata Configuration: AF_PACKET support: yes PF_RING support: yes NFQueue support: no IPFW support: no DAG enabled: no Napatech enabled: no Unix socket enabled: yes Detection enabled: yes libnss support: yes libnspr support: yes libjansson support: yes Prelude support: no PCRE jit: no libluajit: yes libgeoip: yes Non-bundled htp: no Old barnyard2 support: no CUDA enabled: no Suricatasc install: yes Unit tests enabled: no Debug output enabled: no Debug validation enabled: no Profiling enabled: no Profiling locks enabled: no Coccinelle / spatch: yes Generic build parameters: Installation prefix (--prefix): /usr/local Configuration directory (--sysconfdir): /usr/local/etc/suricata/ Log directory (--localstatedir) : /usr/local/var/log/suricata/ Host: x86_64-unknown-linux-gnu GCC binary: gcc GCC Protect enabled: no GCC march native enabled: yes GCC Profile enabled: no
Updated by Victor Julien over 10 years ago
- Status changed from New to Assigned
- Assignee set to Eric Leblond
- Priority changed from High to Normal
Updated by Victor Julien over 10 years ago
This is quite odd. There have been no serious changes to af_packet since 2.0.
Updated by Eric Leblond over 10 years ago
- Status changed from Assigned to Closed
I'm closing it for now. Restarting latest master did not show this problem. It may be linked to the new synchronized start which has been fixed due to another problem.
Actions