[Michael Mann <mmann78@xxxxxxxxxxxx>]

If you pick and unused EtherType and conform to the SocketCAN format, Wireshark is 1 line short of working:

 

dissector_add_for_decode_as("ethertype", can_handle);

in proto_reg_handoff_socketcan()

 

 

 

-----Original Message-----
From: Kumquat KromKiller <kromkillerkumquat@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sun, Nov 8, 2015 6:56 am
Subject: Re: [Wireshark-dev] CAN over Ethernet

When I say plain, maybe I should have said that I'm working at FPGA-level.

Basically, when I receive a CAN message, I put everything between start-of-frame and end-of-frame in the Ethernet payload and since the length of the payload is less than 0x0600, I use the EtherType to store the length.

If I hear you right, the best option for now is to comply with the SocketCAN format, choose an unused EtherType and write a dissector that basically just tell Wireshark that this particular EtherType is in fact SocketCAN ?

That is great because the code for this dissector should be pretty small.

Still, it isn't out-of-the-box. Can you confirm me that this is not possible ? (Again, I'm the one making the CAN over Ethernet bridging device, I can do whatever I want with the payload.)

On Sat, Nov 7, 2015 at 4:19 PM, Michael Mann <mmann78@xxxxxxxxxxxx> wrote:

What is "plain encapsulation of CAN"?  SocketCAN has the format of 4 byte CAN ID. 4 byte length field followed by the CAN data.  This is currently only used in "file formats", not anything on the wire.  Doesn't mean you can't hook up to it, but your wire data will have to match.

 

My suggestion would be to write your own dissector, but it should borrow HEAVILY from SocketCAN, including its dissector table.  I presume your "plain encapsulation of CAN" is slightly different from the 4 byte CAN ID + 4 byte length, so those are the discrepancies you need to address in your own dissector.  Once you have the data length and CAN ID, you can pass that data through the SocketCAN dissector table so it can dissect the next layer (CANopen, DeviceNet, etc)

 

If you make your own dissector (or even modify SocketCAN), because there is no standard ethertype for this, you'll need to use Decode As to dissector and just register your dissector (handle) with the ethertype dissector table. (dissector_add_for_decode_as).

 

 

-----Original Message-----
From: Kumquat KromKiller <kromkillerkumquat@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sat, Nov 7, 2015 9:12 am
Subject: Re: [Wireshark-dev] CAN over Ethernet

I choose how CAN messages will be transported, that is why I said I can add whatever layers I want between Ethernet and CAN.

Right now, it's just plain encapsulation of CAN over Ethernet with a custom EtherType greater than 0x0600.

Ideally, I would like to avoid making my own dissector. It would be great if captured traffic could be dissected with Wireshark out-of-the-box, even if I have to add several unnecessary layers between Ethernet and CAN.

For example, SLL has a non-standard EtherType value for CAN messages but it cannot be encapsulated with Ethernet (there's no standard EtherType value for SLL)

 

Maybe there's a combination of CANopen, SLL, EtherCAT, SocketCAN or whatever that can achieve this ?

On Sat, Nov 7, 2015 at 1:57 PM, Roland Knall <rknall@xxxxxxxxx> wrote:

Hi

It depends how the CAN messages are being transported within Ethernet. Then you could write a dissector for the method, which in turn calls the CAN dissector.

The same thing happens with a lot of other dissectors,the openSAFETY disssector for instance.

regards,

Roland

On Sat, Nov 7, 2015 at 1:33 PM, Kumquat KromKiller <kromkillerkumquat@xxxxxxxxx> wrote:

Hi everyone,

I need to transport CAN messages over Ethernet and I would like to be able to dissect them in Wireshark for debugging purposes.

Considering the fact that I can add whatever layers I want between Ethernet and CAN, what would be the most efficient way to achieve this ?

Thanks.

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