Re: DeviceNet dissector

[mmann78 () netscape net]

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 () hms se>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
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 () wireshark org [mailto:wireshark-dev-bounces () wireshark org]On Behalf Of mmann78 () 
netscape net
Sent: den 21 augusti 2012 14:48
To: wireshark-dev () wireshark org
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 () hms se>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
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 () wireshark org [mailto:wireshark-dev-bounces () wireshark org] 
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 () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?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 () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?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 () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

 
 

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