Student. Cybersecurity & IoT nerd. Little time, little code.
Opinionated in a funky-fresh, nerdy, non edgy kinda way.
Interested in #linux, #c , #embedded , #computerengineering , #cats and the other great things about life.
| GitHub | https://github.com/JoaoNasMonteiro |
| Mood | board |
Been trying to host a blog with github pages and... Welp, I guess I'm just not cut out to be a web dev, even with just a static site generator like Jekyll lol.
All of the vibe coding must have also not helped much.
Stuff just breaks out of nowhere and I just can't be bothered to fix it every time! (Bold coming from a #linux user but oh well)
I will probably move to Medium or some other site like that to host my blog... Sucks but It Is What It Is.
DevLog: Orange Sentry Sprint 2 - MQTT Client Implementation
Introduction
This week's mission was to create a functional MQTT pub/sub client that can grab it's payloads to publish from FIFO pipes (mkfifo) and send them to the broker, as well as to subscribe to a topic and send the messages received through FIFO pipes to other processes to treat.
As you can maybe guess,this week's theme has been plumbing more than anything!
But I also learned more about build systems, why splitting functionality between multiple files is important and why writing utils is so.. useful..
My main blockers were my overall noviceness with the C programming language and trying to learn the Eclipse Paho C MQTT library.
So I dove deep into library docs, man pages and some AI code review to learn about industry best practices, in which the AI was surprisingly good and helpful, especially at providing guidance about best practices.
The Engineering
As a summary, this week provided the mqtt-client implementation, complete with mqtt.h/.c auxiliary files. But also the logging.h util and the fifo-ipc.h/.c library.
The main challenge I faced was to hook everything up in a consistent and well structured manner, while providing adequate levels of abstraction through libraries and utils to avoid calling the vendor library directly from main.
I am planning to use the logging and fifo-ipc libs extensively through the rest of this project, both to keep things consistent and clear.
Speaking of pipes (FIFO is a very funny name btw), I chose to use this technology because I needed some sort of Inter Process Communication (IPC) to let my microservice-inspired architecture's processes talk to one another.
My options were basically Unix Sockets, Signals, Shared Memory, Direct Piping, and FIFO pipes.
Unix sockets looked promising at first, but they were kind of awkward to use (requiring handshakes), so I looked at the other options.
I eliminated signals basically right away, because They can't communicate text in a flexible manner.
Even ignoring the nightmare of memory management with Shared Memory, it was just a security disaster waiting to happen, so I dumped them right away.
Direct Piping just was not repeatable and robust enough.
So I looked at FIFO pipes, and they just fit so goldilockedly perfect. They were challenging but not impossible to implement right (they code basically the same as files), they can be easily debugged from the terminal by echoing to them, and they implement nicely with both C and Python (a technical requirement for this project). So I stuck with them.
They are not perfect, though, and need special treatment for concurrency reasons, and as with any other way of inputting data into a program, they need extensive input sanitization and treatment to avoid security and other kinds of bugs.
I ended up running out of time before I could actually finish implementing the subscribing part of the client, though from the docs it should not be that hard, since I've already done most of the groundwork to handle MQTT connections.
And since I did not have the adequate time to actually test out and debug stuff on ARM and on the board, as well as to clear some TODOS on the code, I will join those tasks into one micro sprint that should last less than a week, a week at most, and try to implement those things there. The plan is to have a really functional and kind of robust (I plan to have at least input sanitization and message formatting/parsing functionalities by the end) client to thoroughly test. If I want to add some more work on top of that I can maybe start to figure out some sort of system to test and benchmark my code on the board.
The Next Steps
The next sprint, a micro one, is also related to MQTT. I plan to implement the subscribing functionality that I could not implement this week, as the complexity of the tasks was too big to handle. I plan to also do some general cleanup across the codebase and dedicate some time to validate and debug the functionality on the ARM board, As I have not been able to even boot up the board for time constraints
Greatest Hits
//snippet of buggy code
int ipc_open_channel(IPC_Channel *channel, const char *path) {
channel->path = path;
if (mkfifo(path, 0666) == -1) {
LOG_ERROR("Failed to create FIFO named pipe");
return -1;
}
channel->fd = open(path, O_RDWR | O_NONBLOCK);
if (channel->fd == -1) {
LOG_ERROR("Failed to open FIFO named pipe");
return -1;
}
return 0;
}
Error:
$ ./bin/x86/mqtt-client
[Error] Failed to create FIFO Named Pipe: File exists
<3>[MQTT_CLIENT] ERROR: Failed to open log FIFO at /tmp/test_fifo
Fixed code:
int ipc_open_channel(IPC_Channel *channel, const char *path) {
channel->path = path;
if (mkfifo(path, 0666) == -1) {
// throw error if there is an actual issue
if (errno != EEXIST) {
LOG_ERROR("Failed to create FIFO named pipe at %s", path);
return -1;
}
// if it gets here then the file already existed, so we just update the
chmod(path, 0666);
}
channel->fd = open(path, O_RDWR | O_NONBLOCK);
if (channel->fd == -1) {
LOG_ERROR("Failed to open FIFO named pipe at %s", path);
return -1;
}
LOG_INFO("Channel opened successfully at %s", path);
return 0;
}
Conclusion
This was a very good and rewarding week for my first big milestone (yeah, I know it's only a sprint) of developing C code beyond just uni courses and quick Udemy projects. Feels nice to build something, and even nicer to ship it.
It may not be perfect, but it's mine and I leaned a lot along the way, and that is what matters.
Moltbook, a week-old social network for AI agents, exposed 6,000+ user emails and over a million API keys through an open database, according to Wiz researchers. The creator boasted about writing "zero code" for the platform. The breach highlights security risks when AI generates software without proper configuration oversight. Vulnerability now patched.
RE: https://mstdn.social/@990000/115993836802443268
I have given this "security" documentation a quick once over and... Welp, I definitely have some opinions that deserve more time than I have available right now to talk about.
Like, it's bad... Real bad.
All of that to say: Please learn to make stuff!
And please don't stop to make stuff that is good!
I don't know where I got this from, but once I've heard something that really stuck with me. It was something along the lines of:
"There are two kinds of people in this world. The people who just like to make stuff seem good, and the people that like to make stuff actually be good"
I think a lot of this AI craze over the last half-decade has been driven by the former people, rather than the latter.
AI could probably write a better paper on astrophysics in a shorter amount of time than I can, but it will never write a better paper than someone that is an actual astrophysicist.
AI is very good at making the stuff that it produces seem good (especially for the non-expert's eye), but it struggles with the deeper reasoning, understanding and experience needed to make stuff that is actually good, be it art or code.
People tend to overestimate the stuff that seems good, but the real impact (and the impact I want to have in the world) is to make things that are actually good.
Maybe some day AI will be capable of producing stuff that is actually good, but as per my very limited understanding on the matter, LLMs won't be the technology that breaks that frontier.
There is this YouTube video series about the #gameboy 's #hardware engineering and it's one of the best introductions to #CPU s and how CPUs process code with registers and stuff and It has been released 9 years ago and they LEFT US HANGING FOR THE REST
I NEED TO KNOW HOW THE GAMEBOY HANDLES RAM
PLEASE!
⚠️ TriggerWarning ⚠️
.. and then #MeidasTouch #BenMeiselas reveals wtf is going on with #melamania & the #EpsteinFiles.
#GifsArtidote: 🤢🤮🤬😡 i am so fucking triggered by these truths that come out, & how they drip-feed us little bits of horrific traumatising stuff.
this is what narcissistic psychopathic behaviour IS: frump is deliberately re-traumatising us so we are physically, mentally & emotionally debilitated to such extend that we can't rise up.
my artidote is: ignore them, set limits & boundaries to how much you listen to & watch this kind of #news, & focus on your #self & your #LocalCommunity.
off course, we need ppl to be on top of this but please ⛔️ & think whether you are resilient enough to take it in.
in my own toxic relationships i learned to first take #responsibility for my #self, & not sacrifice my life for any fucker's delusions of self-importance & privilege.. and believe me, i learned the hard way.
#press #IndependentMedia #news #MentalHealth #survival #CPTSD #BPD #ClusterB #recovery
Marcus Schuler
poison punk