During the linking projects some bugs reared their ugly head. Debugging was done with Wireshark, but it did not understand the protocol so all packets were viewed as UDP packets, which had to be dissected by hand.

Wireshark has a methodology to add a ‘packet dissector’ for a specific purpose. There are six steps required in the dissector code, all of which use internal functions.

  1. Naming the protocol. This convention tells Wireshark what to call the protocol when it recognizes a packet.
  2. Identification of Protocol packets. This tells wire shark how to recognize a packet that conforms to the protocol. It is essentially a programmatic extension of the display filter mechanism, which includes the transport protocol (TCP or UDP), and the port number, or range of ports. For USRP these are between 32000 and 34099.
  3. Display the packet. This is used in the packet history frame to provide some minimal information about the packet. The protocol name, and a type of packet can be displayed.
  4. Finding fields in the packet. Wireshark passes the dissector code a buffer with all the packet data. The first task is to extract the relevant fields from the buffer into variables where they can be stored locally. This also undoes any compression scheme that it may have imposed on the data.
  5. Building a protocol tree. A ‘tree’ is a description of certain parts of the protocol. Starting at the frame level and drilling down through several

There are three methods to implement a dissector, depending on skill level:

  1. Use the universal dissector WSGD. This is a matter of learning how to describe fields in the dissectors own syntax, and writing a script for it. Probably the easiest.
  2. Write a script in LUA. For those who are familiar with this language, it offers an alternative and more flexibility to using a fixed syntax dissector. The next step up.
  3. Write a dissector in C. The most difficult, not only because it requires programming skills but it also requires several background steps to be successfully completed before starting to write any code. The best starting point is to find a ready-coded dissector on GitHub, and compile and install it. The steps are:
    1. Download and install the Wireshark development environment, as well as Cmake and GCC for Linux, or Visual Studio for Windows.
    2. Compile the sample dissector and ensure that you have all the required include files and libraries in place.
    3. Install the dissector and ensure that Wireshark does not crash or requires additional libraries.
    4. Try generating some sample data to ensure that Wireshark recognizes and is calling the dissector.

In this case the C method was chosen, but it turned out to be a bit of an exercise to get the development environment up and running. The example I used was packet-uhd dissector on github. Developing in C can be done on either a Linux or Windows machine. However, on Linux there is very little debug support, so adopting the KISS principle is paramount. On Windows the debugger can be used, so if you are developing for both, it is probably a good idea to get it right on Windows first, then port to Linux. More detailed information about dissectors can be found in Chapter 9 of the Wireshark Developer’s Guide.

However, no good project goes unpunished. I sent a copy of the object code to another amateur, who could not get it to work, following the instructions that worked for me. It turns out that he was using V3.2, which was significantly younger than mine, and still not the latest and greatest. One of the problems with open source software is that everyone seems to have their fingers in it, and when a new fix or update comes out, it is re-released, and there is no guarantee of backward compatibility, which was the case here as well. Since the version I used for development, there have been at least four major releases from 2.4.x to 3.4.x (the appear to go up in x.2’s), not including minor updates which only affect the last digit. I would have to compile at least 6 different versions, then multiply that by 2 for Linux/Windows, and 2 again for 32/64bit, which makes it 24, not including the raspberry Pi. This is a major hornet’s nest that I do not want in the least.

There had to be a better way. I mentioned earlier that there were 3 ways to implement a dissector, the other two were a LUA script or the generic dissector. I do not know LUA and really don’t want to learn another language, so I decided to give the generic dissector a whirl instead. It was relatively simple to learn the syntax, and after one day I had a dissector that was similar to my C code. The advantage of this was that the dissector solves the version issue, and my script stays the same. I tested with quite a few versions with a reasonable degree of success.

The next task was to port that to the raspberry Pi. Unfortunately, the Generic Dissector is not installed with the basic package, so I would have to build it. As usual the stock download would not work, so that becomes yet another arduous exercise.

Looks like LUA is the only universal language for dissectors, and is independent of the Wireshark version. Another language….sigh.

However, there is light at the end of this tunnel, as I am currently building the whole works for the Pi, including Wireshark and the WSGD. There are some lessons learned from this exercise:

  1. Update your APT package manager. Since I set up my Pi there have been new releases of the OS, and it appears that my package manager was trying to access an older download mirror, which no longer existed. Make sure that you have updated the package manager with ‘sudo apt-get update’ first.
  2. Update your OS. The list of updates is endless, a simple ‘sudo apt dist-update’ will do it all.
  3. Download the Source for WSGD. It can be found at wsgd.free.fr. You will need git to download it, clone the repo and you are almost ready to go.
  4. Install required packages. The build is driven by a shell script, ‘build_on_linux.sh’. It attempts to determine the OS type, and ensures that the required packages are installed. Debian is not part of it so no downloads are done. , if you feel ambitious you can add it, or simply download the required packages manually.
  5. Fix broken links. The shell script has the wrong path name for the Wireshark source, change it to the current one, do a search on Github to find the latest.
  6. Compile away. Run the shell script, and if you get past the configuration stage then all is well. If not, you may have to manually download and install missing components. The compile takes a long time, mine was only up to 10% after an hour and a half. Be patient.

The build took over 6.25 hours on my Raspberry Pi, but once completed I had a working copy of the latest and greatest, inclusive of the WSGD dissector. I am now looking at dissected packets on the Pi itself.