Ethereal-dev: Re: [ethereal-dev] Re: Adding NetInfo (ONC RPC proto) support to ethereal
On Tue, Jan 04, 2000 at 11:09:23PM -0800, Guy Harris wrote:
> > What is the protocol to follow to get patches incorporated into
> > Ethereal?
>
> Post the diffs and wait for somebody to commit them.
Thanks. There's actually a bug in the patch I posted, so I'll post a new
one. Also, the conversation data that my patch causes to be alloc'ed in
dissect_rpc() is not being freed; I don't know when it ought to be
freed.
The bug in my code lies that I forgot to move the offset past the string
length uint32 that precedes the indirect call's args. Same thing with
the rplies. Ay.
> > ***************
> > *** 836,848 ****
> > conversation = find_conversation(&null_address, &pi.dst,
> > pi.ptype, pi.srcport, pi.destport);
> > if (conversation == NULL) {
> > - conversation = find_conversation(&null_address,
> > - &pi.dst, pi.ptype, 111, pi.destport);
> > /* We haven't seen an RPC call for that conversation,
> > so we can't check for a reply to that call. */
> > ! if (conversation == NULL) {
> > ! return FALSE;
> > ! }
> > }
> >
> > /* The XIDs of the call and reply must match. */
> > --- 836,844 ----
> > conversation = find_conversation(&null_address, &pi.dst,
> > pi.ptype, pi.srcport, pi.destport);
> > if (conversation == NULL) {
> > /* We haven't seen an RPC call for that conversation,
> > so we can't check for a reply to that call. */
> > ! return FALSE;
> > }
> >
> > /* The XIDs of the call and reply must match. */
>
> Yes, port 111 is the well-known port for the portmapper under TCP and
> UDP, but is there a way of doing this without wiring that in? (ONC RPC
> can run atop other transports, although I don't know how often it's run
> over, say, the OSI transport protocols.)
It has to be hardcoded because the Solaris rpcbind sends replies to
indirect calls with a different source port. The Solaris rpcbind has a
socket dedicated to handling indirect calls and does not specify a port
number to the kernel at socket bind time; it uses this socket to: a)
forward indirect calls to the target service, b) receive replies to the
indirect RPC calls and c) to forward the replies back to the client.
I consider this a bug, but it's there and it's Sun's product; Sun, after
all, is responsible for ONC RPC... :/
> > ***************
> > *** 67,322 ****
> >
> > static struct true_false_string yesno = { "Yes", "No" };
> >
> > - /* Stolen from packet-rpc.c:dissect_rpc_uint32() */
> > - int
> > - dissect_rpc_guint32_val(const u_char *pd, int offset, frame_data *fd, proto_tree *tree, char* name, char* type, guint32 * val)
> > - {
> > - guint32 value;
> > -
> > - if (!BYTES_ARE_IN_FRAME(offset,4)) return offset;
> > - value = EXTRACT_UINT(pd, offset+0);
> > -
> > - if (tree && name) {
> > - proto_tree_add_text(tree, offset, 4,
> > - "%s: %u", name, value);
> > - }
> > -
> > - offset += 4;
> > - *val = value;
> > - return offset;
> > - }
> Hmm. It's a bit ugly to have a copy of "dissect_rpc_uint32()" here;
> perhaps "dissect_rpc_guint32_val()" should be moved to "packet-rpc.c",
> and "dissect_rpc_uint32()" made a wrapper around it that throws away the
> value? Uwe?
You are right.
Nico
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
