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