Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wireshark Dissector issue #4

Closed
wbw60 opened this issue Aug 13, 2019 · 21 comments
Closed

Wireshark Dissector issue #4

wbw60 opened this issue Aug 13, 2019 · 21 comments

Comments

@wbw60
Copy link

wbw60 commented Aug 13, 2019

Has anyone had luck getting the Wireshark dissector to work? I am able to build it, but I noticed that it appears to conflict with the existing standard Wireshark J1939 dissector which takes precedence when you analyze a packet. Thanks in advance for any help or pointers to information you can give me on this.

@famez
Copy link
Owner

famez commented Aug 20, 2019

Can you check whether the plugin is properly loaded?

In Wireshark, go to Help -> About Wireshark -> Plugins.

@wbw60
Copy link
Author

wbw60 commented Aug 20, 2019

Here's the Plugins list:
image

Error messages when I start wireshark up are:
libEGL warning: DRI2: failed to authenticate
16:17:30.107 Main Warn QIODevice::read (QFile, "/usr/local/share/wireshark/COPYING"): device not open

@wbw60
Copy link
Author

wbw60 commented Aug 20, 2019

This is on Raspian GNU/Linux 9 (stretch). All 30 tests pass when I run execTests (I did make a change to the path to the "test_not_found.json" path in database_test.cpp as I run execTests from the Tests dir).

@famez
Copy link
Owner

famez commented Aug 20, 2019

Normally, it should work by right clicking over one can frame in the .pcap file, then choosing Decode as... and then select J1939 as protocol.

I don´t know if you followed these steps.

@wbw60
Copy link
Author

wbw60 commented Aug 21, 2019

So here's some info from my compiled version:
image
image
image
Looking at the same file (the output of running gear_level.sh) on standard Wireshark on Windows after setting J1939 as the protocol looks like this:

image

Now what I thought I would see on the compiled version was what is in the main README file for the project:

image

Any ideas on what I'm doing wrong that I don't see the message broken up into the SPN components like on your screenshot? Thanks in advance for any info or pointers to info that you think would help!

@wbw60 wbw60 closed this as completed Aug 21, 2019
@wbw60 wbw60 reopened this Aug 21, 2019
@wbw60
Copy link
Author

wbw60 commented Aug 21, 2019

Oops. Didn't mean to close the issue. :-(

@famez
Copy link
Owner

famez commented Aug 21, 2019

Try opening the following pcap file. It contains a Vehicle Identification Number frame. If you are able to see either "Transport Data" or "Transport Connection Management", the problem is that the database (frames.json) is not correctly loaded. In this case, check the path for the database.

vi.zip

@wbw60
Copy link
Author

wbw60 commented Aug 22, 2019

FWIW, I noticed 3 errors in the packet-1939.cpp files that I had fixed in a previous build (I rebuilt everything and had managed to lose my previous changes). The line numbers are off due to including iostream for debug print statements and "<" are my changes, ">" is the original:
++++++++++++++++++
image

+++++++++++++

Now, after a "make; sudo make install" from the wireshark source directory and a "cmake --build ../wiresharkSourceDir" in the wireshark build directory, I reran and was able to see that the DB loaded (I put an error message in the entry into proto_reg_handoff_j1939() and in the check to see if the DB was parsed) - here's that code snippet:
\\\\\\\\\\\\\\\
void proto_reg_handoff_j1939(void) {

        std::cerr << "In Handoff" << std::endl;

    j1939_handle = create_dissector_handle( dissect_J1939, proto_j1939 );

    //Load database
    J1939DataBase ddbb;
    if(!ddbb.parseJsonFile(DATABASE_PATH)) {                //Something went wrong
        std::cerr << "Error loading Database" << std::endl;
            return;
    }

\\\\\\\\\\\\\\\\\\\\\

When I did a "sudo ./wireshark" from the run directory in the wireshark build tree, the "In Handoff" message showed up. I opened the file you sent, selected a packet, did the Decode As:
image
chose J1939, opened up the SAE J1939 info and got this:

image

Do you see anything incorrect with what I did? Are there any other tests I should try? Thanks in advance for your help and advice on this.

@wbw60
Copy link
Author

wbw60 commented Aug 22, 2019

A few more items that might be of use. Here's the "about" dialog showing what the build consists of:

image

Here's the plugin tab:
image

If I disable SAE J1939 in the Enable Protocols list:
image

I no longer have a J1939 option in the "Decode As" dialog:
image

For comparison's sake, here's a shot of the "Decode As" from my non-customized Windows version:

image

And here's the enabled protocols for the standard Windows Wireshark:

image

Let me know what other info could help. Thanks again for your help!

@famez
Copy link
Owner

famez commented Aug 22, 2019

Could you tell me which version of the J1939-Framework you installed? Thanks.

@wbw60
Copy link
Author

wbw60 commented Aug 26, 2019

Sorry for the delay, I was away from the office and couldn't check. In the CMakeLists.txt file in the top level I found "set(J1939Framework_VERSION 1.0.0)". Was that where you wanted me to look, or are there other version numbers that would be helpful? Thanks.

@wbw60
Copy link
Author

wbw60 commented Aug 26, 2019

More info:
TRCToCap, config.h has version 2.6.1 (not sure if that's the plugin version or not).
TRCWriter.cpp has "FILEVERSION" set to 1.1.
Wireshark source version is 3.0.3.

@famez
Copy link
Owner

famez commented Aug 26, 2019

Hi,

About the fix you have done

FWIW, I noticed 3 errors in the packet-1939.cpp files that I had fixed in a previous build (I rebuilt everything and had managed to lose my previous changes). The line numbers are off due to including iostream for debug print statements and "<" are my changes, ">" is the original:
++++++++++++++++++
image

+++++++++++++

It is correct. I did not tests about the wireshark dissector for a while, but I made some modifications over the J1939 library code that broke the code for the dissector.

You can open a pull request the modifications or otherwise, I will fix that later.

Nevertheless, the problem seems to be that with this version of wireshark (3.0.3) a new layer has been added (Linux Cooked Capture). This layer was not present before and the following lines in the code (packet-1939.cpp) :


//Get the buffer from the upper layer so that we can obtain the ID for the Can Frame
tvbuff_t *canIdTvb = tvb_get_ds_tvb(tvb);

//Obtain the length of the concerning frame
guint32 data_length = tvb_reported_length(tvb);

//Allocate a buffer where to store the DLC (payload of the can frame)
guint8* content = (guint8*)wmem_alloc(pinfo->pool, data_length);

//Obtain the can id
guint32 canId = tvb_get_ntohl(canIdTvb, 0);

canId is supposed to contain the identifier for the frame, instead, it contains the first 4 octets of the Linux Cooked Capture layer (00040118 or 00010118).

These lines must be fixed.

Sadly, I do not have the time to fix the code now, so I think it will be ready in two weeks :(

@wbw60
Copy link
Author

wbw60 commented Aug 26, 2019

OK, let me know when you post the changes and I'll test them out. Thanks for all your help on this.

@famez
Copy link
Owner

famez commented Aug 26, 2019

As a quick fix you can test with the following modification:

Original code:


 //Obtain the can id
    guint32 canId = tvb_get_ntohl(canIdTvb, 0);

Modified code:


 //Obtain the can id
    guint32 leCanId = tvb_get_ntohl(canIdTvb, 0x10);
guint32 canId = (leCanId >> 24) | ((leCanId >> 8)&0xFF00) | ((leCanId << 8)&0xFF0000) | ((leCanId << 24) &0xFF000000);

canId &= 0x1FFFFFFF;

For me it worked.

@wbw60
Copy link
Author

wbw60 commented Aug 27, 2019

I'm going on a trip for a few days but I'll give it a go when I get back. Thanks much!

@wbw60
Copy link
Author

wbw60 commented Sep 2, 2019

I got back from my trip and my office was closed due to the hurricane coming. Hopefully later this week after it passes I will be able to try your fix. :-(

@famez
Copy link
Owner

famez commented Sep 3, 2019

Ok, no problem.

@famez
Copy link
Owner

famez commented Sep 4, 2019

Please, pull the latest commit to test the dissector.

@wbw60
Copy link
Author

wbw60 commented Sep 9, 2019

At long last, I was able to rebuild wireshark with your latest commit (hint to those doing this on RPI3+ machines - use "cmake -G Ninja ../wireshark_source_dir" and then "ninja -j1" in your wireshark build directory) and it worked as expected.

image

Thanks much for your help in tracking this down. We can close this issue.

@famez
Copy link
Owner

famez commented Sep 9, 2019

I am glad that it worked. Closing...

@famez famez closed this as completed Sep 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants