[Oisf-users] What does it means??

[Peter Manev]

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?

-- 
Regards,
Peter Manev