VRT_49.0 Protocol Spec

GNU Radio
1

On 04/26/2010 06:09 PM, Matt E. wrote:

I’ll send you a copy when I get the latest one. Attached is the draft
I have.

Matt

Thanks. I’ve started reading it.

To re-use a phrase I’ve heard on fark.com rather too many times: “I
threw up in my mouth a little”.

Optional fields, optional packing formats. Rather a nightmare. Doing a
Wireshark parser is going to
be just so much fun :slight_smile:

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

2

On Mon, Apr 26, 2010 at 15:19, Marcus D. Leech [email protected]
wrote:

Optional fields, optional packing formats. Rather a nightmare. Doing a
Wireshark parser is going to
be just so much fun :slight_smile:

Optional parsing? :slight_smile:

Johnathan

3

On Mon, Apr 26, 2010 at 03:26:46PM -0700, Matt E. wrote:

On 04/26/2010 03:19 PM, Marcus D. Leech wrote:

Optional fields, optional packing formats. Rather a nightmare. Doing a
Wireshark parser is going to
be just so much fun :slight_smile:

We use a very well defined subset of VRT which makes parsing a lot
easier. We don’t use class fields, for example.

Matt

FWIW, the code that’s already written handles all of the cases
consistently. It wasn’t a big deal. There’s a finite set of stuff
and there’s some machine generated code that handles all the optionally
there/not-there cases.

Eric

4

On 04/26/2010 03:19 PM, Marcus D. Leech wrote:

Optional fields, optional packing formats. Rather a nightmare. Doing a
Wireshark parser is going to
be just so much fun :slight_smile:

We use a very well defined subset of VRT which makes parsing a lot
easier. We don’t use class fields, for example.

Matt

5

On 04/26/2010 07:01 PM, Eric B. wrote:

easier. We don’t use class fields, for example.

Well, perhaps I should look at that code as a dissector core for
Wireshark, then.

Does it handle the lovely “optimized for wire-format-density vs
optimized-for-machine-processing” wire-format
variabilities?

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

6

On 04/26/2010 07:01 PM, Eric B. wrote:

FWIW, the code that’s already written handles all of the cases
consistently. It wasn’t a big deal. There’s a finite set of stuff
and there’s some machine generated code that handles all the optionally
there/not-there cases.

Eric

Just looked at the code. Unfortunately, Wireshark is written in C, and
expects that its dissectors will
also be written in C. Sigh.

Also, am I to understand that the VRT code only handles the Rx path, and
not the Tx path? Also, given
that VRT will be used in UHD, what will the licensing implications be,
since the VRT code is GPL only.
[Not intending to stir up any controversy, just want to know what the
broader picture is].

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

7

Also, am I to understand that the VRT code only handles the Rx path, and
not the Tx path? Also, given
that VRT will be used in UHD, what will the licensing implications be,
since the VRT code is GPL only.
[Not intending to stir up any controversy, just want to know what the
broader picture is].

The UHD has its own custom VRT implementation specific to the uhd
metadata and usage. The python code generates pack and unpack routines
for tx and rx respectively.

http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/lib/transport/gen_vrt.py

-Josh

8

On 04/26/2010 04:30 PM, Marcus D. Leech wrote:

Just looked at the code. Unfortunately, Wireshark is written in C, and
expects that its dissectors will
also be written in C. Sigh.

Also, am I to understand that the VRT code only handles the Rx path, and
not the Tx path? Also, given
that VRT will be used in UHD, what will the licensing implications be,
since the VRT code is GPL only.
[Not intending to stir up any controversy, just want to know what the
broader picture is].

We are writing our own VRT code in UHD and not using any of the stuff in
GNU Radio.

Matt

9

On Mon, Apr 26, 2010 at 07:11:26PM -0400, Marcus D. Leech wrote:

We use a very well defined subset of VRT which makes parsing a lot

Well, perhaps I should look at that code as a dissector core for
Wireshark, then.

Does it handle the lovely “optimized for wire-format-density vs
optimized-for-machine-processing” wire-format
variabilities?

Currently only handles the “optimized for machine processing” case.

Eric

10

On 04/26/2010 08:00 PM, Matt E. wrote:

We are writing our own VRT code in UHD and not using any of the stuff
in GNU Radio.

Thanks Matt, Josh already cleared that up a few minutes ago.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium