I'm forwarding Ethan's announcement here. Ethan, you'll get better reception to your ideas if you post them to the correct place. Most networking hackers do not read linux-kernel due to the sheer vol
The concept could be improved in my opinion. _All_ filters could use the regex (finally cnews regex in the kernel, yiiha). So what we need is this to be an extension to _all_ filters. i.e define u32
... BTW, i am not sure how efficient the stuff that Henry spencer wrote is in comparison to newer research on variants of boyer-moore for regex searches. comment? I picked Spencer's mainly because it
Take a look at snorts implementation. I think snort is GPL so you may just be able to borrow it. Your problem seesm to be the regexp scheme used. You dont need a static buffer i think. You should be
Jamal Hadi wrote: On Tue, 20 May 2003, Ethan Sommer wrote: Yep. We haven't spent a lot of time on optimizations. Obviously that example can be fixed pretty quickly... except I'm not sure we can avoid
Ok, i see your dilema. How does snort do it? I dont think copying the packet is the right way to do it. Could the null NOT be considered as something speacial unless explicitly stated? This would be
Maybe make it take a length parameter and if it's zero treat null's like all other algorithms do and it's non-zero use the length instead. Then you can hide it in a wrapper function for the "normal"
Jamal Hadi wrote: On Tue, 20 May 2003, Ethan Sommer wrote: Nope. I need to strip out all the nulls from the packet, or any posix regex parser will think the string ends at the first null. (so protoco
Actually, the library that you pointed to seems to have callbacks associated with every match - so it could be used on string matches. The author is on the cc. Didnt see anything kernel related in my
Jamal Hadi wrote: I think you should do some measurements - "it doesnt slow 100Mbps" and "lets worry about it when we get to 1 or 10Gbps" are handwaving at best. Infact i would strongly recommend loo
Philippe Biondi wrote: regexp support was planned but not done yet. (if someone know where I can download more free time !). The implementation should not be that hard, once you have the compiler to
If P and Q are regexps, P|Q is a regexp, so you do can. So detection is clearly not a problem. But to fit in the libqsearch model, you have to know which of the parterns matched. This is theorically
Philippe Biondi wrote: On Wed, 21 May 2003, Ethan Sommer wrote: Philippe Biondi wrote: regexp support was planned but not done yet. (if someone know where I can download more free time !). The implem
Strange way of reasoning... what if pattern1 is "(subpat1|subpat2)" ? regexp is a regular language so it is equivalent to a DFA. For every NDFA, there exist a DFA that recognize the same language. S
Philippe Biondi wrote: I take it back, it is regular (kinda) but you can't to it with a deterministic finite atomaton. If there is a cycle in pattern1, off of which pattern2 has a branch, then you wo
You mean things like a*b -> 1 ac -> 2 ? You can still express this with a DFA, i.e. a(c|a*b) Of course, if you have patterns that match the same string, you need to decide at some point whether you w
Well, that's too easy. The DFA should also test bits only in the order in which they appear in the packet. Constructing a DFA that jumps back and forth and tests the same bit over and over again woul
"exists a DFA" doesn't mean that there is only one :-) Typically, there are a lot of DFAs for each NFA, usually an infinite number of them. And among them are also those that don't combine states you
I'm forwarding Ethan's announcement here. Ethan, you'll get better reception to your ideas if you post them to the correct place. Most networking hackers do not read linux-kernel due to the sheer vol
Hi, The concept could be improved in my opinion. _All_ filters could use the regex (finally cnews regex in the kernel, yiiha). So what we need is this to be an extension to _all_ filters. i.e define