Guy Harris wrote:
For
suitable definition of "near" ("for the next release" probably
wouldn't be suitable from my point of view; "in the next six months"
*might* be possible), that'd be acceptable.
IMHO, I also totally agree not to rush things for the next
release. But would definitely like to see some thought going on in the
direction asap, so as to be able to define the interfaces cleanly and
completely. I would say that a timeline of even six months will be a
challenge and is really appreciable.
I currently have following
requirements which am not sure how well to
integrate in Ethereal:
1. I would like to use Ethereal to be able to read data from a
proprietary interface which by nature is not like Ethernet for ex: lets
say a TDM interface.<>
If by "read" you mean "capture", then
1) Ethereal already supports interfaces that are "not like
Ethernet",
e.g. ISDN, even if it doesn't currently support live capture on all of
them (although it *does* support live capture on ATM, for example).
2) I'd consider that to be something to do, to some degree, in
libpcap
(somebody's already added support for Intel's SS7 cards, and there's
also support for DAG cards). Raw TDM bit streams wouldn't fit well
with
Ethereal at all, but something that supplies frames would work. That'd
also require Ethereal changes to read packets of that type, but the
low-level capture is probably best done in libpcap, so *other*
applications could be written to capture on that interface as well.
Am not sure whether such a support is there. I did go through
the mailing list messages but couldn't find definite answers. DAG SS7
card doesn't support that for sure. I think, the support is there for
DAGs Ethernet based cards. For Intel's Septel card, if somebody has
done that, I would really be interested but I don't see it in Ethereal
distribution?
If only I can get a clear interface to supply frames to Ethereal, my
task is done.
2 .I need to include some proprietary
user information with a well
defined protocol but not part of PDU, which could be parsed and
captured.
What do you mean by "proprietary user information with a
well-defined
protocol but not part of PDU"? In particular, what do you mean by "not
part of PDU"? Is it part of the network traffic in a capture, but not
part of the particular PDU you're dissecting (e.g., some traffic prior
to the PDU you're dissecting governs how to dissect that PDU), or is it
some configuration information not part of the network traffic?
By proprietary information, (and if I may use the example quoted
for SS7 above), I mean the time slot information, the card information,
the port number etc. This information is not carried in the frame, so
this information has to go in a proprietary way and Ethereal dissectors
which are protocol based, will not understand them. There has to be
something in *may be* core to allow such proprietary information to be
stripped of before invoking protocol dissectors and may be invoke a
secondary dissector-like-entity for parsing this proprietary
information.
In addition, another requirement can be to allow user to put filters on
the basis of this proprietary information itself.
3. I would like to be able to get the
captured data online for some real
time correlation?
What do you mean by "some real time correlation"? That
*might* be
something you'd do in a tap.
Lets assume, I would not like to use GUI or a file to get the
captured and filtered data. I would like to *automate* my analysis of
filtered data partly because my requirement is to do the analysis in
real-time.
best regards,
Jeetendra
|