VISA TCPIP data packet inquiry

[bgriffin01]

I am trying to use VISA TCPIP calls to communicate to an ONC/RPC application that I have developed for a uP using TCP/IP stack. Ultimately, I am developing a VXI-11 server on my measurements device. I know that VISA can communicate with a VXI-11 device via the viOpen function with TCPIP::170.126.24.59::INSTR as the resource name. The ::INSTR, as I understand it, signals VISA to use the VXI-11 protocol to communicate with the device.

The problem I am having is the data sent from VISA to my device is inconsitant with the RPC protocol as defined by RFC 1831 and 1057 (At least my understanding of these). Here an RPC call is defined to begin with a 32bit XID followed by the message type, etc. The data I see coming into my uP from VISA seemes to be adding a 32bit value before the XID. Here is a data capture to better explain this:

TCPIP data recieved from VISA on port 111 (converted to little-endian from XDR's big-endian):
80000038 00004673 00000000 00000002 000186A0 00000002 00000003 00000000 00000000 00000000 00000000 000670AF 00000001 00000006 00000000

If I ignore the first 32bits, I decode this msg as:
/* RPC HEADER */
XID          = 0x00004673 = RPC message transaction identifier
MSG_TYPE     = 0x00000000 = RPC CALL message
RPCVERS      = 0x00000002 = RFC 1831,1057 RPC version #
PROG         = 0x000186A0 = RFC 1833 PMAP program #
VERS         = 0x00000002 = RFC 1833 PMAP version #
PROC         = 0x00000003 = PMAP_GETPORT
CRED.FLAVOR  = 0x00000000 = AUTH_NULL
CRED.BODY_SZ = 0x00000000 = 0 bytes in body
VERF.FLAVOR  = 0x00000000 = AUTH_NULL
VERF.BODY_SZ = 0x00000000 = 0 bytes in body
/* END OF RPC HEADER */
/* PORTMAPPER MAPPING */
PROG         = 0x000670AF = Server program #
VERS         = 0x00000001 = Server version #
PROT         = 0x00000006 = TCP
PORT         = 0x00000000 = ignored

As you can see the data is a valid RPC (v2) message CALL to a portmapper (v2) ***IF*** the first 32bits are ignored.

My question is what are the first 32bits?

[Shawn B.]

Well, I can't answer your specific question, but I can point you to the information that can answer your question.  First I would take a look at the VXI-11 specification.  Then I would arm myself with a good network protocol analyzer like ethereal/wireshark.

Shawn B.
National Instruments

[bgriffin01]

That is sound advice, thank you. I actually just recently captured some RPC messages with Ethereal and found that the 32-bits I was concerned about are called the fragment header. This header is used as part of RPC Record Marking (RM). Because a data packet (like TCP) can only hold so many bytes, extremely large RPC messages must be seperated into fragments and transmitted in pieces. The first bit(31) of the fragment header is a boolean flag that states whether this fragment is the last in the record. The following 31 bits (0-30) specify the number of bytes in the fragment. See section 10. Record Marking Standard of RFC1831 for "more" details.

I am still unsure what a record of more than one fragment looks like. I have not yet seen this, so I do not know if there is any repeated data within the RPC message between fragments, such as XID, OR if the fragment data simply represents the next fragment[0:30] # of bytes in the RPC message.

But again thank you for your help