Ethereal-dev: Re: [ethereal-dev] SCTP bakeoff experiences and more ...
On Mon, Jul 03, 2000 at 06:20:56PM +0200, Michael Tuxen wrote:
> 2. The possibility to capture from more than one interface. This would be
> extremely
> helpful for SCTP since SCTP suppports multihoming.
This one is a bit painful to implement on at least some platforms.
libpcap normally does a blocking read from the interface, so you'd have
to do a "select()" or "poll()" to wait for frames from more than one
interface on most platforms.
Unfortunately, at least on FreeBSD (and, I suspect, on most if not all
of the BSDs), the way the underlying mechanism (BPF) works is that
there are two buffers inside the kernel, one into which the BPF
code copies packets and one from which stuff gets copied for
userland to read;
a "select()"/"poll()" doesn't return "there is data to be read"
until there's data in the second of the buffers;
data doesn't get moved from the first buffer to the second until
either
1) the first buffer fills up
or
2) the timer specified in an "ioctl" goes off;
the timer is started when a read done on the BPF device - *NOT*
when a "select()" or "poll()" is done.
The net result is that, unless traffic is coming in at a rate sufficient
to keep filling up the first buffer, the application doesn't see any
traffic unless it breaks out of the "select()" and tries to read it.
I don't know whether the timers implemented in other packet capture
mechanisms (SunOS 4.x and 5.x "bufmod", Digital UNIX's packet filter,
maybe others) have this same problem.
This can probably be worked around with a timer on the
"select()"/"poll()".
> Furthermore I'm currently doing a complete rewrite of the SCTP dissector
> I wrote to
> make use of the tvbuff stuff. I simplifies the dissector a lot and
> depends heavily on it.
> But how can I raise an exception manually?
Well, if you include "exceptions.h", you can do
THROW(<exception>)
However, the only exceptions we use are "the packet runs past the end of
the frame" (i.e., the packet is malformed, and whoever put it on the
wire didn't put all of the stuff there - or the packet takes more than
one frame and we aren't reassembling frames) and "the packet runs past
the end of the captured data in the frame" (i.e., the packet isn't
malformed, but the user didn't specify a capture snapshot length long
enough to capture all of it). Detecting those involves doing a bounds
check; where are you doing bounds checks without using the tvbuff code
to do so? Perhaps we need to add some additional tvbuff functions to do
that.
> The last question I have is dealing with the IP dissector. Is anyone
> adapting it to the tvbuff structure?
It (along with all the other dissectors) will ultimately be converted to
use tvbuffs; I don't know whether Gilbert is currently working on that -
it's currently not at the head of my list of things to do.
> Or should one contribute
> modifictions to it regarding some kind of error handling: for example
> handling of wrong length field or padding at the end of short IP datagrams?
It's probably worth doing that for now; that code (along with other
bounds-checking code already in various dissectors) will probably be
removed when dissectors get converted to use tvbuffs (as it's presumably
redundant).
