[Hans-Jörgen Gunnarsson <Hag@xxxxxx>]

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
______________________________________________________________________