| |
| |
| |
|
Comments:
<0> gug
<1> gug
<2> good day people. I try to figure out a mysterious problem with recent matches [to me at least]
<2> LOG tcp -- 195.38.0.0/16 anywhere tcp dpt:smtp flags:SYN,RST,ACK/SYN recent: CHECK seconds: 60 hit_count: 10 name: SPAM side: source LOG level warning prefix `FW_RECENT_DROP_1: '
<2> LOG tcp -- 195.38.0.0/16 anywhere tcp dpt:smtp flags:SYN,RST,ACK/SYN recent: CHECK hit_count: 10 name: SPAM side: source LOG level warning prefix `FW_RECENT_DROP_hit: '
<2> the first matches, the second does not. how come?
<2> (the kernel is 2.6.13)
<2> just a sidenote, if someone feels like answering I am hanging around and wait. if the question is a stupid one I'd appreciate being told. :-) thanks.
<2> for me it looks weird if the recent match is so much broken and nobody's noticed
<3> hello everyone. A quick question, I don't know if you can help me. I want to view the packets that tcpdump doesn't tell me about, the ones dropped by the kernel filter. Also, would these effect bandwidth?
<4> landstalker: tcpdump comes before netfilter
<4> (you will see dropped packet)
<4> s
<3> oh
<3> erm, why don't I then?
<3> 736 packets dropped by kernel that weren't listed in the tcpdump output
<3> do I need to run an extra switch with it or something?
<4> landstalker: man tcpdump ;-)
<4> for explanation on "dropped by kernel"
<3> ok :D
<5> Regit, you use libnetfilter_queue for NuFW right?
<5> do you know if it is already possible to read multiple packets from the kernel per read?
<5> hmm, my internet connection just died, did my messages get trough?
<4> VictorJ: yes
<4> I've seen yuor message
<4> VictorJ: but I don't think this is possible
<5> i remember seeing a post on netfilter-devel in which it was suggested that the lower level lib supports it but the libnetfilter_queue doesn't (yet)
<5> but that was quite a while ago, so i hoped things would have changed
<4> svn is sleeping nowadays
<2> ****
<2> okay, thanks for not helping, but no surprise since it's a kernel bug
<3> no thanks but I appreciate the offer
<5> it seems that nfqueue performs significantly worse than ip_queue
<5> (i am one of the snort_inline devels)
<2> recent match current code is broken
<4> VictorJ: seems to recall you from a past discussion
<4> VictorJ: what do you mean by "significantly worse" ?
<5> i am doing some changes to snort_inline stream re***embly, so i am benchmarking a lot. I am mostly using netpipe-tcp, which uses both very small packets and larger packet.
<2> okay have a nice time and if you use recent match reboot every 22 days or patch the kernel ;)
<5> I keep my results here: http://wiki.vuurmuur.org/~victor/snort_inline_perf.pdf
<5> i decided to test the nfqueue as well and was surprised it performed quite a bit worse on small packets
<5> you should compare the data of 'si260rc1 3000' and 'si260rc1 3000 (nfqueue)
<4> VictorJ: really interesting
<4> VictorJ: have you the stats in term of number of packets ?
<5> testing with snort isn't completely fair though, since it's interface with nfqueue might be a factor as well
<5> hmm no
<5> is it just me or is netfilter.org slow/down
<1> just you
<5> Octavian, it works from here again as well, it just took a few minutes ;-0
<5> okay i added a ipq-test program and the nfqnl_test to the document as well
<5> ipq stays faster at small packets, but the difference is smaller
<5> so there must be something less efficient in snort_inline as well
<6> moin
<6> I hacked a libnetfilter_queue python wrapper (from the ipqueue one)
<4> matth_: funny
<4> VictorJ: ??
<5> Regit, forget the last statements: in the updated graphs from ipq vs. nfq i forgot to add the QUEUE rules
<5> so i measured just unfiltered
<5> with the queue rules the difference is as good as gone
<5> Regit, the doc is updated again
<4> ok
<5> so it seems the slowdown is entirely in snort, sorry for all the fuzz
<4> VictorJ: ok
<5> Regit, thanks for your time :)
<4> VictorJ: no pb
<4> VictorJ: the good thing would be to do better in nfqueue but this may be difficult ;-)
<5> maybe being able to read multiple packets per recv call would improve performance...
<5> and even multiple verdicts in one call
<4> yes, it seems a good idea
<5> but then one have to be carefull not to introduce to much latency
<5> by queueing packets longer than needed
<5> if i read the nfnetlink code correctly this code can already do this
<5> but the netfilter_queue can't
<5> might be mistaken though
<0> gug
<1> gug
<1> Hidden: do you know whether its ok to change matchinfo data as p***ed to the checkentry() match function?
<0> Octavian: I guess it is
<0> Octavian: but I've never tried it
Return to
#netfilter
or
Go to some related
logs:
centos+gnone install
howto kooldock gnome
wiki % escape symbol
#debian
ubuntu acer 8200
gentoo require 'sqlite3-ruby' false
loadxml +lt +gt
php5-cgi cpu load
imagecreatefromtiff
#openzaurus
|
|