<p dir="ltr">I know of an issue with divert sockets in FreeBSD 9.x amd64 but I have not heard of drastic changes in the network stack to cause issues from 8.x to 9.x.</p>
<p dir="ltr">In fact I believe the netmap api is now a part of both 8 and 9 (something I verified when reading this thread )</p>
<div class="gmail_quote">On Oct 11, 2013 7:40 AM, "C. L. Martinez" <<a href="mailto:carlopmart@gmail.com">carlopmart@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Oct 9, 2013 at 2:52 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
> On Wed, Oct 9, 2013 at 4:41 PM, C. L. Martinez <<a href="mailto:carlopmart@gmail.com">carlopmart@gmail.com</a>> wrote:<br>
>> On Wed, Oct 9, 2013 at 2:33 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
>>> On Wed, Oct 9, 2013 at 4:31 PM, C. L. Martinez <<a href="mailto:carlopmart@gmail.com">carlopmart@gmail.com</a>> wrote:<br>
>>>> On Wed, Oct 9, 2013 at 2:24 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> Yes, and It doesn't drops packets. For example, for udp:<br>
>>>>>><br>
>>>>>> udp:<br>
>>>>>> 6533535 datagrams received<br>
>>>>>> 0 with incomplete header<br>
>>>>>> 0 with bad data length field<br>
>>>>>> 0 with bad checksum<br>
>>>>>> 29 with no checksum<br>
>>>>>> 13 dropped due to no socket<br>
>>>>>> 0 broadcast/multicast datagrams undelivered<br>
>>>>>> 0 dropped due to full socket buffers<br>
>>>>>> 0 not for hashed pcb<br>
>>>>>> 6533522 delivered<br>
>>>>>> 157 datagrams output<br>
>>>>>> 0 times multicast source filter matched<br>
>>>>><br>
>>>>> And what is the same output for the IDS box?<br>
>>>>><br>
>>>><br>
>>>> Nop, it is very different:<br>
>>>><br>
>>>> udp:<br>
>>>> 5431123 datagrams received<br>
>>>> 0 with incomplete header<br>
>>>> 0 with bad data length field<br>
>>>> 8765 with bad checksum<br>
>>>> 453 with no checksum<br>
>>>> 12232 dropped due to no socket<br>
>>>> 0 broadcast/multicast datagrams undelivered<br>
>>>> 0 dropped due to full socket buffers<br>
>>>> ....<br>
>>>><br>
>>>> And here is where I see the problem ... but if problem are not<br>
>>>> interrupts ... I don't know where it is ..<br>
>>><br>
>>> This is UDP ... how about TCP ?<br>
>>><br>
>><br>
>> Here it is:<br>
>><br>
>> tcp:<br>
>> 14996 packets sent<br>
>> 1332 data packets (193400 bytes)<br>
>> 0 data packets (0 bytes) retransmitted<br>
>> 0 data packets unnecessarily retransmitted<br>
>> 0 resends initiated by MTU discovery<br>
>> 20829 ack-only packets (19 delayed)<br>
>> 0 URG only packets<br>
>> 0 window probe packets<br>
>> 31 window update packets<br>
>> 2615 control packets<br>
>> 10104 packets received<br>
>> 1337 acks (for 193421 bytes)<br>
>> 11 duplicate acks<br>
>> 0 acks for unsent data<br>
>> 1109 packets (158370 bytes) received in-sequence<br>
>> 1 completely duplicate packet (0 bytes)<br>
>> 0 old duplicate packets<br>
>> 0 packets with some dup. data (0 bytes duped)<br>
>> 0 out-of-order packets (0 bytes)<br>
>> 0 packets (0 bytes) of data after window<br>
>> 0 window probes<br>
>> 5 window update packets<br>
>> 0 packets received after close<br>
>> 0 discarded for bad checksums<br>
>> 0 discarded for bad header offset fields<br>
>> 0 discarded because packet too short<br>
>> 0 discarded due to memory problems<br>
>> 2602 connection requests<br>
>> 10 connection accepts<br>
>> 0 bad connection attempts<br>
>> 0 listen queue overflows<br>
>> 0 ignored RSTs in the windows<br>
>> 15 connections established (including accepts)<br>
>> 2628 connections closed (including 0 drops)<br>
>> 11 connections updated cached RTT on close<br>
>> 11 connections updated cached RTT variance on close<br>
>> 2 connections updated cached ssthresh on close<br>
>> 2592 embryonic connections dropped<br>
>> 1334 segments updated rtt (of 3774 attempts)<br>
>> 20743 retransmit timeouts<br>
>> 0 connections dropped by rexmit timeout<br>
>> 0 persist timeouts<br>
>> 0 connections dropped by persist timeout<br>
>> 0 Connections (fin_wait_2) dropped because of timeout<br>
>> 2592 keepalive timeouts<br>
>> 0 keepalive probes sent<br>
>> 2592 connections dropped by keepalive<br>
>> 985 correct ACK header predictions<br>
>> 939 correct data packet header predictions<br>
>> 10 syncache entries added<br>
>> 0 retransmitted<br>
>> 0 dupsyn<br>
>> 0 dropped<br>
>> 10 completed<br>
>> 0 bucket overflow<br>
>> 0 cache overflow<br>
>> 0 reset<br>
>> 0 stale<br>
>> 0 aborted<br>
>> 0 badack<br>
>> 0 unreach<br>
>> 0 zone failures<br>
>> 10 cookies sent<br>
>> 0 cookies received<br>
>> 6 hostcache entries added<br>
>> 0 bucket overflow<br>
>> 0 SACK recovery episodes<br>
>> 0 segment rexmits in SACK recovery episodes<br>
>> 0 byte rexmits in SACK recovery episodes<br>
>> 0 SACK options (SACK blocks) received<br>
>> 0 SACK options (SACK blocks) sent<br>
>> 0 SACK scoreboard overflow<br>
>> 0 packets with ECN CE bit set<br>
>> 0 packets with ECN ECT(0) bit set<br>
>> 0 packets with ECN ECT(1) bit set<br>
>> 0 successful ECN handshakes<br>
>> 0 times ECN reduced the congestion window<br>
><br>
> Ok, so it seems there is problem elsewhere than the Suricata<br>
> configuration itself....<br>
> How is the connection between the two machines done? Have you tried on<br>
> a different nic?<br>
><br>
<br>
Hi Peter,<br>
<br>
Yes, I have tried different nics with same result. But I've done<br>
another test. I have reinstalled this host but using FreeBSD 8.4 amd64<br>
and here are the results:<br>
<br>
11/10/2013 -- 11:27:15 - <Info> - stream.reassembly "toclient-chunk-size": 2560<br>
11/10/2013 -- 11:27:15 - <Info> - all 2 packet processing threads, 3<br>
management threads initialized, engine started.<br>
11/10/2013 -- 11:27:15 - <Info> - No packets with invalid checksum,<br>
assuming checksum offloading is NOT used<br>
11/10/2013 -- 11:27:15 - <Info> - No packets with invalid checksum,<br>
assuming checksum offloading is NOT used<br>
11/10/2013 -- 11:36:30 - <Info> - Signal Received. Stopping engine.<br>
11/10/2013 -- 11:36:30 - <Info> - 0 new flows, 0 established flows<br>
were timed out, 0 flows in closed state<br>
11/10/2013 -- 11:36:31 - <Info> - time elapsed 555.799s<br>
11/10/2013 -- 11:36:31 - <Info> - (RxPcapem41) Packets 5845957, bytes 2042472103<br>
11/10/2013 -- 11:36:31 - <Info> - (RxPcapem41) Pcap Total:6747655<br>
Recv:6678123 Drop:69532 (1.0%).<br>
11/10/2013 -- 11:36:31 - <Info> - Stream TCP processed 5632209 TCP packets<br>
11/10/2013 -- 11:36:31 - <Info> - Fast log output wrote 1878 alerts<br>
11/10/2013 -- 11:36:31 - <Info> - TLS logger logged 269 requests<br>
11/10/2013 -- 11:36:31 - <Info> - (RxPcapem42) Packets 5834141, bytes 2037711281<br>
11/10/2013 -- 11:36:31 - <Info> - (RxPcapem42) Pcap Total:6747681<br>
Recv:6666460 Drop:81221 (1.2%).<br>
<br>
Best. Same suricata config and sysctl options ...Uhmmm, I think I need<br>
to do more tuning with FreeBSD 9.2 or maybe I need to change suricata<br>
options for FreeBSD 9.2 ...<br>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" target="_blank">http://suricata-ids.org/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
OISF: <a href="http://www.openinfosecfoundation.org/" target="_blank">http://www.openinfosecfoundation.org/</a><br>
</blockquote></div>