Wireshark · Ethereal-users: Re: [Ethereal-users] HP RPC Decodes

[peter.makohon@xxxxxxxxxxxxxx]

 HP is willing to work with us if we have the right person from the
Ethereal side call their help desk.  We already have a case open.

Guy,  Is that you?

(I appreciate the quick response)


                                                                                                                             
                    Guy Harris                                                                                               
                    <guy@netapp.c        To:     Peter Makohon/AO/USR/FTU@FTU                                                
                    om>                  cc:     ethereal-users@xxxxxxxxxxxx, Nelson Goodman/AO/USR/FTU@FTU                  
                                         Subject:     Re: [Ethereal-users] HP RPC Decodes                                    
                    01/31/2002                                                                                               
                    04:25 PM                                                                                                 
                                                                                                                             
                                                                                                                             




> Who is in the best position to speak about whether Ethereal can read
> proprietary HP RPCs?

A person who has a specification for the HP RPC in question.  Without a
specification for it, a dissector cannot be written for it in Ethereal
without a lot of reverse-engineering work (and even that isn't
guaranteed to succeed).

>"BERUBE,KELLAH (HP-USA,ex1)" <kellah_berube@xxxxxx> on 01/11/2002
>To:   Nelson Goodman/AO/USR/FTU@FTU
>cc:   Peter Makohon/AO/USR/FTU@FTU
>
>Subject:  RE: RPC information and using Ethereal
>
>
>Nelson:
>I wanted to give you a status.  Our support engineers are looked into your
>questions regarding proprietary RPC calls.  Here is their response:
>
>      "Regarding your question whether or not HP has any proprietary RPC
>code.  The answer is Yes, all of our code for that matter is proprietary
in
>that it is not open source that customers may pull down and modify at
their
>will.  We ported the ONC release from Sun about a couple of years ago, and
>our current code is 1.2 with some functionality from 2.3 built on top.
So,
>basically we have the same ONC software as sun."
>
>      "The library that we use is libnsl for most of the main components
>of rpc and nfs. If the vendor has a working solution already for HP, then
>they should be able to troubleshoot the problem, and/or work with us if
>they do not."
>So, if Guy Harris and the Ethereal folks want to work with our Engineering
>team, we can hook them up on this Case number = 3200534109.   Let me know.

Well, first of all, given that HP was one of the members of the OSF, I
suspect they may have more RPC code than Sun's RPC code - they may also
have DCE RPC code.

They also appear not to have understood the question very well.  What
matters isn't whether they're using proprietary RPC *code* (and, in any
case, Sun *have* given away some versions of their RPC code, including
the 2.3 version, and, in any case, the RPC-layer protocols are published
as RFCs, and Ethereal has dissectors for those), what matters is whether
the particular protocols being run *on top of* RPC are proprietary - the
mere fact that ONC RPC is a published protocol doesn't mean that all
protocols running on top of ONC RPC are published.  The same is true of
DCE RPC - the protocol is published, but, as the Samba folk well know,
not all protocols running on top of DCE RPC are published (well, unless
you count lkcl's book:


http://www.amazon.com/exec/obidos/ASIN/1578701503/qid=1012512238/sr=8-1/ref=sr_8_3_1/104-6478826-5211143


but he found that through reverse-engineering...).

In any case, *I'm* not going to be writing any dissectors for various
random HP-proprietary protcols running atop either ONC RPC *or* DCE RPC,
as I don't have the time; somebody who cares about those protocols will
have to get specifications for them and either write the dissector
themselves or find somebody with the time and inclination to do so.