[Bro] BRO and CANBUS Protocols

[Clark Gaylord]

I'm curious what you would do with a bro canbus analyzer.

I expect Ludwig probably knows all this, but in the interest of our
discussion, I'll give a short intro to CAN, since I suspect view of us
straddle their respective worlds as I do. Apologies for any errors or if
it's too basic.

>From our IP-centric perspective, CAN can be thought of as a coupling of
ethernet and udp, specifying what we would see analogously as phy, link,
MAC, and udp. (My description is intentionally without referring to the
J1939 terms and should be thought of by analogy.) It is the dominant
communication network in the vast majority of automobiles and trucks,
though it can be thought of more generally an "assembly line" or
instrumentation network. It is very different from, though performs a
somewhat similar function to, modbus, which is a TCP based instrumentation
protocol, and is an abomination.

CAN has a MAC type layer and header that includes a "message type" or
message ID. This id field doubles as a priority, used to arbitrate
collisions (lower message wins), and determines how to decode the payload.
Payload is 0 to 8 bytes. You can think of CAN packets as TLV messages. It
is common to have multiple instruments multiplexed into the payload,
decoded based on the data spec (for example, maybe a GPS message will
encode lat and lon at different bit offsets in the same message). In our
(VTTI) business, where we are interested in the time series of the various
instruments' values, we demultiplex the various instruments; oddly enough,
we call this "demuxing". :-) So, in the example, we pull out lat and lon as
two separate "fields" that we might sniff off the Can and store as distinct
"variables" (yes in the case of lat+lon it would actually be more
convenient to keep them together, but it is more general this way).

There is very little standardization of the data, indeed in the automotive
industry the manufacturers are extremely protective of these data standards
(arguably in part because they would be so mortally embarrassed if anyone
knew how bad these standards were.) J1939 often refers to the more standard
subset of messages used on commercial vehicles; these are required on
trucks and motor coaches and in my experience universally unimplemented on
passenger vehicles. There are a (tiny) handful of CAN messages related to
emissions that are implemented on all vehicles in the US.

Most of my engineer colleagues who live inside CAN use canalyzer or some
other CAN-specific tool (or the C++ code we use in-house for data
acquisition). There is a mythical "libpcan" that can theoretically be used
to create pcap compatible data that can be consumed by tcpdump, Wireshark,
and friends, but when I last tried to build it I could not get it into a
usable state. This would be widely regarded as a valuable contribution to
the community.

So, yes as Johanna notes, bro could potentially be adapted, but I would
suggest chasing it down from the "pcan" perspective. Putting J1939 decodes
on top of that would be a good thing, but I would suggest you build a
modular decode system where you could provide other message decode
capability, so, for example, a given OEM's data (or subset) could be
decoded.

Back to the bigger question, though, I find the notion intriguing but I'm
curious what you're thinking in terms of what you'd like the application to
accomplish, etc.

Regards
Clark

On Sat, Aug 11, 2018, 11:55 Ludwig Goon <lagoon7 at gmail.com> wrote:

> Thanks Johanna,
>
> I do see that the protocol does have some affiliation with the OSI model.
> I will keep researching as well.
>
>
> How difficult is it to create an analyzer? Is it possible to use some of
> the baselevel frameworks?
>
> On Fri, Aug 10, 2018 at 6:33 PM, Johanna Amann <johanna at icir.org> wrote:
>
>> Hi,
>>
>> > Does anyone have any experience with CANBUS protocol specifically using
>> the
>> > J1939 standards? Is this something that BRO can process?
>>
>> from what I can tell, J1939 is not an IP-based protocol - Bro is currently
>> limited to IP communication.
>>
>> Note that this is not really an inherent design problem of Bro - it is
>> just that no one implemented that yet.
>>
>> In case I am wrong and this is somehow layered over IP - we also sadly
>> don't have any analyzers for that.
>>
>> Johanna
>>
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro

-- 

--
Clark Gaylord
cgaylord at vt.edu
... Autocorrect may have improved this message ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180811/33c8ce62/attachment.html