Ethereal-dev: Re(2): [ethereal-dev] SCTP bakeoff experiences and more ...
On Mon, 3. Jul 2000, Guy Harris <gharris@xxxxxxxxxxxx> wrote:
>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.
>
I'm thinking on checking variable length parameters in SCTP. For example,
there are IPV4 parameters, which have a type (from which you know what
kind of parameter it is) and a length field. The length field MUST be 8.
So I want to raise an exception when the parameter has the wrong length
field. This corresponds to a malformed chunk, which means a corrupted
SCTP sender (Something that may happen in developping a new protocol).
That is why I want to raise exceptions explicitly.
>> 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).
--
e-mail: Michael.Tuexen@xxxxxxxxxxxxx
