Jeetendra Singh wrote:
It seems, I am misunderstood in the first place. I never meant to expose
the interfaces in the form of APIs as they exist today. They are
certainly not *well-defined* to be frozen. But I cannot see the reason
to put the fix (if i may call them) on the back burner. We are anyways
tied to use the APIs as they exist today and also the fact if they are
changed, they have to be propagated to all the legs/applications which
are currently using them (not recommended when we know for certain that
there are problems with those APIs and they will certainly get
modified). So why not work on them to fix them in *near* future.
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.
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.
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?
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.