What about if you did it as a threaded program and spawned new threads to match the new sessions. This would likely require some cleverness to get decent performance (thread pre-spawning, maybe some sort of session grouping so that if N sessions arrive in close sucession you could bundle them into one thread). A simular alternative would be to hack go into a big select loop on N bpf's (which really end up being just filehandles) and pre-opening new ones as nessecary (do non blocking opens, so you always have a spare bpf or two floating around...). Ugly - yes, complicated - probably.
On Thu, Feb 06, 2003 at 05:48:16PM -0800, Guy Harris wrote: > On Thu, Feb 06, 2003 at 04:41:31PM -0800, Cuzens, Jarrod wrote: > > What I would like to be able to do is track this session by > > essentially adding a pcap filter (to a new instance of pcap) to monitor > > srcIP:srcPort and dstIP:dstPort for this new session (disregarding sequence > > numbers (I just need the naive case :) ) ) on the fly. This way pcap would > > now pass me up anything related to this session. Extending this idea a > > little further the original pcap instance would still detect new sessions > > and I would continue to add new rules to the session filter and remove them > > when either the session stales or I get a FIN. > > > > Basically, what I am trying to get at is that I would like to be > > able to dynamically add a remove rules from a filter on the fly. I have read > > a few documents about BPF+ that seem to indicate that this is the direction > > for BPF+ (although I have also read documents that state the contrary). > > I didn't see anything obvious about that in the BPF+ paper. > > > Is there any functionality like this in libpcap? > > Well, one could, in theory, generate a new filter and install that new > filter. > > However: > > 1) on platforms where filtering is done in user mode, and where > more than one packet is delivered on a read/receive/whatever > from the underlying kernel mechanism, the loop that processes > packets in a buffer gets a pointer to the filter program into > a local variable and uses that pointer, so that if the filter > is changed in the middle of the loop by a callback routine, > the loop will continue to use the old filter for all packets > in the buffer (which means that it could be using a filter > program that's in freed memory, which is Not Good); > > 2) on packets where filtering is done in the kernel, setting a > filter expression causes any packets buffered in the kernel > to be flushed, so that if there are packets that would pass > the old filter but not the new one, you don't see them. > > 1) is easy to fix. > > 2), however, would require kernel changes on BSD. It wouldn't require > kernel changes on Linux, it would just require *removing* the change > that causes the buffered packets to be flushed - however, that change > was put in because people didn't want to see packets that wouldn't have > passed the new filter, so, for many people, removing that change would > reintroduce a bug that they wanted fixed. > > Furthermore, although you can prevent packets that would have passed the > old filter but wouldn't have passed the new filter from being seen by > flushing the buffer, you can't retroactively un-filter-out packets that > would *not* have passed the old filter but *would* have passed the new > filter - but that's what you'd want, as your new filter would pass > *more* packets up, rather than passing *fewer* packets up. > > There would need to be some way of specifying, on systems that do packet > filtering in the kernel, that, somehow, if a packet that matches a given > filter - or perhaps a given rule in a filter - is seen, the kernel > packet filtering code should, perhaps, temporarily buffer *all* packets > but not deliver *any* of them until a new filter is set, at which point > it should run all the buffered packets through the filter and deliver > the ones that pass. > > That would, however, cause you to run the risk of overrunning the > buffer, as it would put *all* packets into the buffer. > > It would, in theory, be possible to do that on most of the OSes running > on PC hardware, namely Windows (as the mechanism isn't built into > Windows, but is supplied by the open-source WinPcap add on), Linux (as > it's open-source), and the free-software BSDs (as they're open-source); > it'd also be possible, presumably, on MacOS X, as the part of Darwin > that includes BPF is open-source. > > The other OSes on which libpcap currently supports in-kernel packet > filter, however, are closed-source (Digital UNIX, AIX when BPF is being > used), so you'd be out of luck on them. > - > This is the TCPDUMP workers list. It is archived at > http://www.tcpdump.org/lists/workers/index.html > To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe -- >-=-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-=-< Ryan Mooney [EMAIL PROTECTED] <-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=-> - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
