On Thu, Feb 13, 2003 at 10:38:20AM +0000, John Leach wrote:
> The reason I ask is I'm writing wiretap support for the Firestorm NIDS
> (http://www.scaramanga.co.uk/firestorm) alert log which dumps out the
> sll layer too. I have an "Alert" dissector first, so I need to call the
> sll dissector rather than just set the encap whilst reading.
>
> Firestorm uses an mmapped packet socket for capture, so the sll
> structure is different too (tpacket_hdr + alignment + sockaddr_ll +
> alignment). Bit of a pain really as I've had to mod packet-sll to
> detect this and act accordingly.
Well, if the structure is different, it's not really the same as
DLT_LINUX_SLL, so it really should have its own dissector, even if that
dissector shares code with the DLT_LINUX_SLL dissector and might even
be in the same *file* as that dissector.
Given that, there's no reason to export the DLT_LINUX_SLL dissector
directly; you could export your dissector directly, however.
> Unless somebody thinks mmapped packet socket
> sll support would be useful? (I'm not sure where else this would crop
> up) It might be nice to be able to capture using this method... has
> anybody thought about this before?
Yes.
The way to do *that* is to support it in libpcap. The only problem
there is that, allegedly, there are applications that depend on being
able to open a capture device and then fork and be able to use the
capture device in the child process, or something such as that, and the
claim is that you can't do that with a mmapped capture device.
Equally unfortunately, there's currently no way for an application to
specify that it doesn't *care* whether you can fork.
Phil Wood at the US Los Alamos National Laboratory has some code to
support it in libpcap, using an environment variable to specify whether
it's OK to use memory-mapped captures; it's a hack, but if the claims
are true that using memory-mapped captures will break some libpcap
applications, there's not much you can do. I've been looking at merging
some of his changes into the standard libpcap, although there's a bunch
of other changes that I *don't* want to include.
In the long term, for that *and* other reasons, I want there to be a new
API for opening capture devices in libpcap; one change is that, instead
of just being able to specify promiscuous vs. non-promiscuous mode, I
want a bunch of options to be able to be specified at open time, such as
"open for capture" vs. "open for capture and sending". One such option
would be an indication of whether the pcap_t needs to work across a fork
or not; the default would be "not", so that most applications, if
converted to use the new API, could use the memory-mapped device.