Bhatia, Deepak wrote:
We are sure that HpOpenView uses DCE RPC for communicating between HpOpenView Manager (Client)
and N-Agents (Servers). This is what the customer is asking for.
What our customer is asking us to produce the DCE RPC packets which uses TCP/UDP specific port
number.
What do you mean by "produce", and "uses TCP/UDP specific port number(s)"?
By "produce", do you mean "send packets like the ones DCE RPC sends"?
If so, is the goal of this project to build a program that operates in a
fashion compatible with the way the OpenView modules using DCE RPC
operate? If so, you want either to find documentation for or
reverse-engineer the DCE RPC-based protocols being used, and reimplement
them - which wouldn't require any Ethereal code in the program, but you
might want to add support to Ethereal to dissect that protocol, for use
when testing your program.
Or is the goal to run protocol traces similar to those seen on the wire
agains the OpenView servers, as a way of testing the servers? If so,
*perhaps* the Ethereal code might be useful for decoding traffic you've
captured, but, as I've already noted, it won't help at all in the
process of constructing the traffic to be sent.
And by "uses TCP/UDP specific port number", do you mean "uses particular
hardwired port numbers rather than dynamically-assigned port numbers"?
Hence they ask us to determine the TCP/UDP port number and get the protocol data exchanged
on those port numbers.
Just "get" the protocol data? What do they want to do with that data?
I understand that Client and Server Applications use RPC mechanism in
which they exchage RPC Procedures with there set of parameters. The IDL
is used to generate the RPC Procedures.
So you mean we need to know what RPC Procedures and parameters for these
procedures are used by the protocol on the top of DCE/RPC.
Yes. Unless you know the IDL for the procedures used by OpenView
(whether documented or reverse-engineered), you won't be able to do
anything useful with the DCE RPC-basd protocols used by OpenView.
