Steve’s Software Trek

I wrote an article about Analyzing BACnet with Wireshark for ASHRAE Journal special supplement BACnet Today.  ASHRAE is very particular about endorsing specific company products, and removed some references I had to information about how BACnet MS/TP can be supported on Wireshark by adding an external interface which sends Ethernet SNAP protocol packets.  The external interface was originally a Cimetrics U+4 device which connects BACnet MS/TP via USB to a computer, and uses a special driver to appear as a network interface to Wireshark.

In April, 2008, I was informed that the Cimetrics U+4 packets showed up in Wireshark, but were not decoded correctly.  I asked for a sample of the capture, and reverse engineered the header.  I then created the BACnet MS/TP decoding in Wireshark in order to display the MS/TP data, and passed the BACnet Network Layer and Application Layer information along to the existing dissectors.

The beauty of the BACnet protocol is that it is layered.  The NPDU (network layer) and APDU (application layer) encodings are the same regardless of the datalink layer used.  The NDPU layer is decoded by packet-bacnet.c, which passes the APDU layer to packet-bacapp.c.  The BACnet MS/TP datalink layer is decoded by packet-mstp.c which I created, and passes the NPDU, if it exists, to packet-bacnet.c, for decoding.  The ARCNET, Ethernet, and BACnet/IP (packet-bvlc.c) all pass a relevant packet to packet-bacnet.c for BACnet decoding.  I created packet-cimetrics.c for the Cimetrics header which passes the BACnet MS/TP datalink layer to packet-mstp.c.

The BACnet MS/TP patches were accepted into the Wireshark repository on May 13, 2008, checked in as SVN 25291.  The SVN 25881 was a fix to the Length decoding.  The BACnet MS/TP decoding eventually made it into the Wireshark 1.1 development release, but is not present in the Wireshark 1.0 stable release.

Wireshark now sees packets with the Cimetrics U+4 signature encapsulated in the SNAP protocol as MS/TP packets, and it is able to open a file that has been saved in PCAP format using the MS/TP WTAP signature.  But I didn’t have a Cimetrics U+4 device.  So I used a standard RS485 converter, my open source BACnet stack, and wrote a simple application to packetize the MS/TP frames and saves them to PCAP format.  I could now capture MS/TP packets and view them!

In August, 2008, I received an email from John in New Zealand.  His intention was “to use an existing simple VB application that captures MS/TP traffic from a low cost USB to RS-485 converter, to send the MS/TP packets using Winsock/UDP to Wireshark for final dissection and display.”  I figured that we could do this by making use of the existing SNAP protocol dissector that I created for the Cimetrics packets.

I reused the code that I had written to save in PCAP format, and wrote a simple application to packetize the MS/TP frames and resend them on Ethernet as the Cimetrics U+4 signature encapsulated in the SNAP protocol.  I got it to work under Linux, but would probably need to use WinPcap to get it to work under Windows.

Sending those SNAP protocol packets on Ethernet allows the display of BACnet MS/TP packets in realtime alongside BACnet/IP and BACnet Ethernet.  This makes it very easy to relate traffic going to and from workstations and routers with what is happening on the BACnet MS/TP network.

There are some sample captures (see cimetrics_mstp.pcap and mstp_wtap.cap) that demostrate some of the abilities of Wireshark.

I use a USB to RS-485 converter from SerialGear USB-COMi-SI-M, and am told that the B&B Electronics USOPTL4 works very well.  I am also told that the USB to RS-485 adapters that use the FTDI chipset are great for this as they allow the use of 76800 baud which is usually the stumbling block for native MS/TP interfacing with a standard PC serial port.

I drove to the BACnet meetings in nearby Atlanta and Bill photographed my license plate.  We need lofty goals, don’t we?

Our fun BACnet committee and working groups met in Germantown at the end of April for a week. The weather was perfect, and the Montgomery College Germantown Campus was beautiful and lively.

We had our traditional Tuesday night BACnet dinner at Dogfish Head Brewery.

Most of the working groups met.

Our highly intelligent BACnet committee met in New York City. The discussion centered around Interpretation Requests, Public Review Addendum responses, and revised Public Review Addendum. The Lighting Output object, part of SSPC 135-2004 Addendum i, was approved for its second Public Review.

Many working groups also met on Thursday, Friday, and Sunday. The Lighting Applications working group met on Sunday morning, and we worked on the Color Output object. The Wireless Networking working group met and discussed ways to reduce broadcast packets. The Objects and Services working group met and reviewed addendum comments.

After the Sunday working group meetings, I attended mass at St. Patrick’s Cathedral. It was an awesome church and included a magnificent pipe organ and a number of alcoves.

It was my first visit to New York City. I took a ferry to see the Statue of Liberty Enlightening the World, the full name for the Statue of Liberty. I took a lot of photos, and also sent a photo from my cell phone to my family.

I also toured Ellis Island. It was very touching as I toured the building, rooms, and steps where many families walked through to live in America between 1892 and 1924. A set of steps leading down from the Registration Hall was divided into 3, and was dubbed the “Stairs of Separation.” The steps marked the parting of the way for many family and friends with different destinations. The middle steps led to the islands hospital or detention rooms, while the outer steps were destinations of New York or New Jersey by way of ferry.

I attended the BACnet Interoperability Workshop again this year. The Plugfest was held in Milwaukee. I tested another BACnet Stack at SourceForge enabled device. This time it was an Atmel AVR ATmega168 using the GCC WinAVR compiler. It was utilizing the BACnet MS/TP datalink layer, and had a Device object and 9 Analog Input objects inside. It supported the ReadProperty service, and WhoIs and I-Am services for binding. It had a Maximum APDU size of 128 bytes.
AVR Memory Usage
—————-
Device: atmega168

Program: 16350 bytes (99.8% Full)
(.text + .data + .bootloader)

Data: 630 bytes (61.5% Full)
(.data + .bss + .noinit)

Here is the key that helped me fit the code. I found a GCC compiler and linker directive that allowed all the unused functions and dead code to be removed. I found the directive initially on the GCC M68HC11 FAQ. It saved me from having to split out all the functions into separate files and put them into a single library.

I also met some great folks, some of whom were using the BACnet Stack at SourceForge in their products. I also saw a lot of folks using Wireshark for BACnet protocol analysis. I also got to see a lot of friends that I have made over the years.

Edit: I compiled the project with IAR AVR version 4 compiler and here are the memory usage statistics:

IAR AVR:
10 055 bytes of CODE memory (+ 36 range fill )
553 bytes of DATA memory (+ 24 absolute )

I used to analyze BACnet MS/TP RS-485 traffic using an HP54645D 100MHz 2+16 channel mixed signal oscilloscope because it had a deep buffer and MegaZoom which allowed me to see the data and timing of the frames. However, I have a new tool.

Howard introduced me to Digiview. The Digiview tool is a USB based logic analyzer. It permits you to view and decode signals. I set one of the signals to Async Decode, and gave the tool the baud rate, stop bits, parity of the signal. The software shows the logic signal and displays the decoded the data above the signal. The software also has time marker tools and allows you to set multiple time markers.

Using the DigiView tool and software, I am able to analyze BACnet MS/TP timing and frames with ease. I can see exactly how fast each node is responding and how long each node allows for the various BACnet MS/TP frames. I can also see exactly the content of each frame without having to decode the waveforms.

There are other mini logic analyzers on the market such as BitScope, USBee, PicoScope, and the Ant8 Logic Analyzer. Jack Ganssle wrote a review of some of them.