What is the can bus:
Normal Mode Message?

Vehicle CAN Buses are networks that connect controllers. These controllers are repsonsible for gathering and sharing information about sensors, vehicle states, information, and calibration. Each vehicle’s network is expressly designed by the vehicle’s manufacturer. The data that goes across the networks is local to the vehicle. It is not meant to be routed or shared beyond the vehicle and its controllers (for the most part). So the data does not need to follow any protocol other than that of the physical layer itself. That’s why when you connect to a vehicles CAN Bus you’ll see a lot of data, but they’ll be little to no indication on what the data means; what the content is in the data bytes. This data is typically proprietary. It is there so controllers can share timely information with each other. This data is normally there (meaning you don’t have to request it, it just shows up). That is why it is called Normal Mode Messages. If the vehicle’s controllers are awake, they will transfer information between themselves. Many vehicles will have multiple CAN Buses and each network will have its own messages and information that needs to be shared between controllers. Some times the information will overlap with other networks, but often it does not.

Receiving Messages:

To receive information we can use open-source tools such as candump or cansniffer.

Let’s take a look at the output of the command candump can0 (can0 is our CAN network interface)
We can see the first column tells us what interface we are on. The second column tells us what Arbitraion ID (ArbID). This ID is to note the format of the data bytes. Lastly we see the data bytes. CAN Frames cannot exceed 8 bytes of data. (Press CNTL+C to escape)

You will start to see that some ArbID’s are the same with the data sometimes changing other times you could have the same ID and different data. Normal Mode messages are the data exchanged normally between controllers.  Each network can have as many as 40 controllers. These messages are proprietary, so we don’t know what they mean… yet! By reverse engineering the data we can understand what the bits and bytes mean.

If you want a more in-depth knowledge of the Can bus take a look at this:

https://en.wikipedia.org/wiki/CAN_bus

Part of the problem you will see with candump is that the messages run very fast, so fast that you don’t have time to see what is going on. The candump command shows messages in a sequence order. Filtering is a simple way to allow you to see only certain frame ArbIDs. To filter with candump try the following:

candump can0,123:7FF

- or -

candump can0,1A5:700

The first command will show only the frame with ArbID == 0x123. That is because we specified a very strict filter mask of 0x7FF (in binary: 0b 111:1111:1111). The combination of the two parameters (0x123 & 0x7FF) resulted in a mask of (0b001:0010:0011 && 0b111:1111:1111 = 0b001:0010:0011 [or 0x123]). While the second command would result in any frame that starts with a 0x1XX to pass the filter mask. For example: 0b001:1010:0101 && 0b111:0000:0000 = 0b001:0000:0000). For more information about filter masks (not the kind you wear) please visit This Wikipedia Article.

With candump, the newest messages show up at the bottom and move data up as time progresses.  Another tool is cansniffer. In stead of displaying data in a sequence, it arranges data by ArbID. Each time a new message arrives, cansniffer overwrites the old message and data with the latest values.

cansniffer can0 -c -t 0

The sniffer command lets us see the change in the data if we use -c then we can have the program display changing data bytes in COLOR! The -t 0 will stop messages from disappearing this can be helpful if messages are messages are showing up slowly or if we want to ran a scan since we will send one message once and look for one message coming back.

What we are seeing in the first column is the time stamp the next is the ArbID then it’s the data the last column is ascii. The most common ascii message you will see is the ascii encoded data such as the VIN.

One of the problems you will see is that cansniffer doesn’t handle a lot of messages very well. You end up getting those messages scrolling by which means you can’t really focus on a message or group of them. Similar to candump, cansniffer allows for filtering. You can see a list of how to filter just by typing in cansniffer. Also you can watch this https://www.youtube.com/watch?v=Ig2Dnh3jF-w   

When send your message faster then the normally displayed message you can make something happen for example sending a frame with an ArbID of 0x300 and Data of FF:FF:FF:FF:FF:FF:FF:FF. With this you might see the lights turn on you know that ID and some of the data in that message corresponds to the lights being on. You can send on that same ID 300 FFFFFFFFFFFFFF00 if the lights no longer turn on then you know its in the last byte is that message to turn on or off the lights.

Send messages

To send a message you will be using cansend.

cansend can0 300#FFFFFFFFFFFFFFFF

We are sending using the can0 interface and sending ID 300 and the data is all F’s

We are working in the terminal we need to have two terminal sessions running. One for sending and the other for receiving. This way when we send a message, we can see that it sent on our receive terminal.

Diagnostics:
Unified Diagnostic Services

Additional info:

ISO 14229:

ISO 14229 Messages (Arb ID#Data): (000#023E010000000000) ... (7FF#023E010000000000) <-- Increment through all IDs to PIN the Controllers.

Each Controller has a Command ID (you will send this in the Arbitration ID of the CAN Frame).
Each Controller has a Response ID (the controller will return this ID in the Arbitration ID of the CAN Frame).
With the Command and Response IDs you can command the controllers using ISO14229 services.

ISO 14229 Uses ISO 15765-2 Transport Protocol.  For more information on this protocol please read this.

You will receive a lot of Negative Responses (03 7F XX YY) where XX is the Service that failed and YY is Negative Response Code.  Please view the NRC List here.

http://opengarages.org/handbook/ebook/

CAN-Utils:

CAN-utils has a lot of parts to it. The basic tools are

• candump: display, filter and log CAN data to files

• canplayer: replay CAN log files

• cansend: send a single frame

• cangen: generate (random) CAN traffic

• cansniffer: display CAN data content differences (just 11bit CAN IDs)

https://github.com/linux-can/can-utils

Sending and Receiving with ISO-TP:

Remember that ISO-TP CAN Transport Protocols offer support for segmented Point-to-Point communication between CAN nodes via two defined CAN Identifiers. This protocol driver implements data transfers according ISO 15765-2.

isotpsend

One tool that makes UDS a lot easier is isotpsend

Just type isotpsend to get help with it but its usage is like cansend just more advanced.  This is going to be sending out our message to a node.

Usage: isotpsend [options] <CAN interface>

Example :

echo “11 22 33 44 55 66 DE AD BE EF” | isotpsend -s 620 -d 520 -p 00 vcan0

Options:
-s <can_id> (source can_id. Use 8 digits for extended IDs)
-d <can_id> (destination can_id. Use 8 digits for extended IDs)
-x <addr> (extended addressing mode. Use 'any' for all addresses)
-p <byte> (set and enable padding byte) -P <mode> (check padding in FC. (l)ength (c)ontent (a)ll)
-t <time ns> (transmit time in nanosecs) CAN IDs and addresses are given and expected in hexadecimal values. The pdu data is expected on STDIN in space separated ASCII hex values.

We need to receive the message back for that we can use candump and can sniffer but again there are more advanced tools within the iso-tp frame work.

isotprecv [options] <CAN interface>
isotpdump [options] <CAN interface>
isotpsniffer [options] <CAN interface>

Check out https://github.com/hartkopp/can-isotp for more information.