[Roland Knall <rknall@xxxxxxxxx>]

Hello Evan

Just a little side-note, could you explain what you mean by "records"? With the openSAFETY dissector I voiced the issue some time ago, that openSAFETY in itself is a protocol, where it may end up being multiple nodes sending data in the same ethernet frame. Your solutions seem similar, although I still would face one issue, and that is visual representation.

On a field-bus network (Powerlink, SercosIII, Ethercat, openSAFETY over XXX, ...) there are devices called bus-controllers, which basically gateway data from backplane connected devices onto an ethernet-based bus. Therefore we would have ethernet frames, where we would see up to 500 nodes crammed into one single Ethernet frame (for the openSAFETY dissector it would be around 50). Simply stating where a new record starts is not enough, because there may be data in between (for managing the cramming of the nodes), the data may be multiplexed over multiple frames, and so on.

Also, beside the obvious data representation, the visual representation is lacking big-time. Take a look at any openSAFETY trace I put online, and you'll see what I mean. On a daily basis (at my work) I see Ethernet frames containing 30-50 openSAFETY nodes on smaller networks, which leads to a nearly impossible to decipher picture. I could provide you with such a sample trace, to further demonstrate the issue. My best answer to that problem (and I have been thinking on it for months now), would be some sub-entry representation in the list, similar to a directory structure.

That said, I started a three weeks vacation today, mostly for working on a solution to my problem above, and as well as to getting the extcap interface finally out of gerrit. So if I can be of any help, feel free to ask, I would really appreciate a solution going forward towards 2.0.

regards,

Roland

On Mon, Aug 4, 2014 at 9:56 PM, Evan Huus <eapache@xxxxxxxxx> wrote:

One of the issues that's been popping up a lot recently is how to handle "packets" that contain multiple "records". The reason both those words are in quotes is because there's some broader context and applications:

 - Putting each application-layer PDU into its own "record" regardless of higher-level grouping or reassembly (by e.g. TCP) would theoretically permit filtering for packets where only (fieldA==foo && fieldB==bar) occur together in the same "record", and not just in the same on-the-wire packet.

 - It opens up interesting opportunities for the summary list to be able to, for example, hide everything above the application layer and only display application-layer "records" (again, regardless of TCP-level grouping or fragmentation).

 - It is a necessary component of dissecting record-based file formats with the current plan of reading the entire file as a single "packet".

I've been thinking about this and trying to come up with a way to gracefully (and backwards-compatibly) add this information to our existing data-structures, and I'm currently thinking of just adding it as a flag to the field_info struct (i.e. defining something like FI_STARTS_NEW_RECORD). As far as I've been able to determine, these flag values are accessible everywhere we need them to be (specifically: in the UI and in the display-filter engine), and it makes creating new records backwards-compatible and cheap (just some new macro to set the flag).

My only concern right now is how difficult it will actually be to check this value in the display filter logic - I don't know nearly enough about the dfvm to know if checking for fields in the same "record" is easy or not with the info stored this way.

Thoughts? Suggestions? Better ideas?

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe