[mmann78@xxxxxxxxxxxx]

Did you borrow much of the actual dissection (ie make extern functions) from CIP or was it mostly copy/paste (just curiosity on my part)?  I assume some of the display filters may have shared names.

 

As far as the fragementation goes, I have 2 suggestions:

1. The fragmentation API provided in reassemble.[ch].  You can find a handful of dissectors that use it for examples.

2. The fragmentation done in packet-sctp.c.  I'm still trying to figure out why it needed custom fragmentation, but it appears that at least one reason is that it's API is better at inserting "middle" fragments (at least for the fragment identification scheme used by the protocol).  If you use this as an example, I would recommend using g_ alloced memory for the fragments.  I had recently tried to convert the fragments to use se_ allocated memory (something I'll probably revert), but it ends up using twice the necessary memory for a capture file because the fragments can't be freed once they are reassembled.  CAN frames are significantly smaller than Ethernet frames so memory isn't eaten up as fast in terms of number of frames, but the theory of "wasted" memory still holds.    If you use the SCTP "fragmentation algorithm" for DeviceNet, perhaps that could be an excuse to make it generic enough to put into reassemble.[ch].

 

-----Original Message-----
From: Hans-Jörgen Gunnarss
on <Hag@xxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Aug 24, 2012 4:27 am
Subject: Re: [Wireshark-dev] DeviceNet dissector

Your suggestion makes sense and I have started to build a dissector, borrowing heavily from CIP. One problem is fragmented messages. I don’t really know how to handle them. For now I just state in the info column that they are fragmented and if they are the first, a middle or the last fragment. But perhaps I should add them up to one big single frame. But that leaves an equal amount of fragment confirmatory messages. Any ideas?

 

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of mmann78@xxxxxxxxxxxx
Sent: den 21 augusti 2012 14:48
To: wireshark-dev@xxxxxxxxxxxxx
Subject: Re: [Wireshark-dev] DeviceNet dissector

 

Unfortunately the "CIP" in DeviceNet is drastically different than the CIP that runs over Ethernet/IP.  I think you'd be much better off just writing a pure DeviceNet dissector because I think you'd spend just as much time trying to manipulate packets (if its even possible) to make them look like "Ethernet/IP CIP" packets as you would writing a new dissector. 

 

For starters:

1. DeviceNet doesn't use the same path segmentation (in a single packet) as Ethernet/IP because of packet size contraints

2. The connection architecture is different enough that you couldn't really take advantage of the "CIP connection" conversations.

3. DeviceNet needs a lot more "conversation" data, again because of the packet size constaints.

 

Also if I'm analyzing DeviceNet CAN traffic, I want my dissection to look like a CAN frame and once you start manipulating it, it would be hard to distinguish.  For example, the segment type is determined by a UCMMOpen message/packet and an explicit message then just has class/instance/attribute in that segment size in a separate message.  Would you "add" the segment type to the explicit message packet?  If you did, it would need to show up in Wireshark when that byte doesn't exist in the packet.

 

You probably want to use some of the "value strings" from the CIP dissector and I believe most of the common ones (shared by all of the CIP protocols) are already available in packet-cip.h.  If there are a few more than you need to share, just expose them in packet-cip.h

-----Original Message-----
From: Hans-Jörgen Gunnarss
on <Hag@xxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Tue, Aug 21, 2012 5:28 am
Subject: Re: [Wireshark-dev] DeviceNet dissector

I have now built a program that takes the frames and sends them into Wireshark 

through a pipe. Works really good, thanks for the tip.

In Wireshark the frames go into the SocketCAN dissector which I haveYour  modified 

and added DeviceNet to. Next step is to build the DeviceNet Dissector.

I want to tie the DeviceNet dissector to the existing CIP dissector, but in 

order to use the CIP Dissector I have to modify the packet and insert body type 

information and perhaps modify it so that it fits the CIP-protocol. Is it 

possible to do that? And if possible, is there some information somewhere about 

how to do it? My Google Ninja skill haven't been able to find any information. 

Regards 

Hans-Jörgen

-----Original Message-----

From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] 

On Behalf Of Kurt Knochner

Sent: den 10 augusti 2012 15:40

To: Developer support list for Wireshark

Subject: Re: [Wireshark-dev] DeviceNet dissector

Hans-Jörgen Gunnarsson wrote:

> We are trying to develop a dissector for DeviceNet. We want it to ...

> and partly decodes them. The problem is that it might be better to 

> pick the DeviceNet-messages directly from the dongle into Wireshark.

> Perhaps through SocketCAN or something like that. ...

> We haven't found a good way to do this though. Do you have any ideas 

> or thoughts?

Please take a look at my answer in the following question at ask.wireshark.org.

http://ask.wireshark.org/questions/12102/logging-can-bus-data-to-ws-in-windows

I mentioned a project Wsbridge (link in the answer). They faced a similar 

problem and solved it by using pipes. The code for Wsbridge is available and it 

should give you some ideas.

Regards

Kurt

___________________________________________________________________________

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

______________________________________________________________________

This email has been scanned by the Symantec Email Security.cloud service.

For more information please visit http://www.symanteccloud.com 

______________________________________________________________________

___________________________________________________________________________

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

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

___________________________________________________________________________
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