Project help

Good evening everyone. I am a computer engineering student at the University of Florence and I was assigned a project for my thesis.
Basically I have 2 devices, udoo board and OpenMote, which must communicate with each other. OpenMote is my sensor network and udoo is my base station. So when OpenMote detects something odd in the network sends a signal to the base station. My problem is that OpenMote is a small device with low memory and little RAM which requires flash to load programs written in C exclusively. So as you understand I cannot install completely Bro but I have to work through the Broccoli library and I don’t know how to write the program that does what I wrote above. Do you have any idea?


How are the Udoo system and OpenMode system communicating? I would guess you are using Wifi for the connectivity?

If you were going to install Bro on one of those two devices, it probably should be the Udoo. More practically, since the Udoo has an ethernet port, sniff the ethernet traffic from an inexpensive port mirroring switch, such as any Mikrotik switch, or a Dualcomm “tap” which is actually also a port mirroring switch, with dedicated ports. You would then install Bro on a 3rd system and monitor from there.


If I had to do this as described, I think I’d build some custom code on the OpenMote sensor that would take the events it detected, pack them into a custom protocol, and shoot those events to an ingest process running on the Udoo via an appropriate link. If Bro is desired, then one can build the ingest process on the Udoo as a Bro plugin. This plugin would listen for the special incoming event packets that came from the sensor, read them, and use those event packets to generate / log / etc. custom bro events on the Udoo.

The principle would be similar to broccoli, but the idea would be to keep unnecessary overhead on the OpenMote to a minimum. My guess is that the sensor is probably going to need to devote the vast majority of its resources to both classifying “weird” traffic and running the stack necessary to communicate over whatever protocol it might use (802.15.4 / Zigbee?) in the first place. I really doubt the sensor is going to be able to do much classification, either …

For any kind of more significant analysis, I’d either use a passive receiver or, if one of those weren’t available and / or the sensor were doing something weird, something like a RTL-SDR or HackRF to capture raw I/Q and demodulate / decode into relevant packets that could be passed along to a bro worker running on a more powerful host. That approach, though, would indeed most likely involve writing custom code to parse Zigbee / 802.15.4 / whatever.

Just a few thoughts,

Gilbert Clark