[Oisf-users] What does it means??

Shirkdog shirkdog at gmail.com
Fri Oct 11 11:49:14 UTC 2013


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.

In fact I believe the netmap api is now a part of both 8 and 9 (something I
verified when reading this thread )
On Oct 11, 2013 7:40 AM, "C. L. Martinez" <carlopmart at gmail.com> wrote:

> 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 ...
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> OISF: http://www.openinfosecfoundation.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20131011/660276ab/attachment-0002.html>


More information about the Oisf-users mailing list