'Impossible'? Watch Me—My Unorthodox Internship Adventure With R, Python, and MikroTik
As a fresh young graduate stepping straight from college into my first internship, my top priority was figuring out how things worked at the telecoms company that took me in. Honestly, it wasn't even a paid position—but I didn't mind; I simply wanted to give my best and show what I was capable of. I think this is probably the feeling any excited young engineer has when first entering their industry.
Impossible?
The year was 2015. At that time, our company was providing free/open WiFi access to an entire neighborhood through a set of MikroTik and (Ubiquiti) Unifi-based wireless stations. Historically, this neighborhood had been quite neglected when it came to quality Internet. I knew firsthand how poor the Internet connection there was, because I had friends living in the area. Especially during holiday seasons—since it's a popular touristic spot—the home Internet service was notoriously awful 😓.
Our open WiFi service was therefore appealing, especially to tourists visiting the area. It allowed them to get online easily at the beach or from their accommodations without signing up for a full home Internet service. Sure, the quality wasn't great—but it was affordable and convenient if you only needed to check emails and browse lightly for a week or two (no Netflix binges, sadly 🍿😉). Moreover, for the company, this WiFi service was quite cheap to offer since we just reused most of the existing base-station infrastructure (the company used airMAX with Ubiquiti radios back then to service home Internet clients).
However, there was a major problem: we had no visibility whatsoever on user connections. Clients would constantly call, complaining about poor Internet quality, and we didn’t even have a basic way to identify which WiFi station or antenna they were connected to. The system felt incredibly messy, and as far as everyone there was concerned, there wasn’t an easy or straightforward solution. I'll never forget what the CTO said one day, loud and clear:
🔥 "It's impossible to find out where a client is connected—or to debug their connection issues." 🔥
To me, that sounded like a direct invitation for challenge and innovation. It was as if someone had just planted a giant "Impossible" sign right in front of me, daring me to knock it down 💥. So naturally, I couldn't resist. I began investigating potential solutions. At the time, the network was routed, having evolved from a previously VLAN-segmented setup. Out of curiosity, I checked Unifi & MikroTik's documentation to see if they offered any APIs—and thankfully, they did (although still in its infancy). It was officially time to roll up my sleeves and build some custom software!
Challenge accepted! ✅
Clearly, it was possible. But there was a catch: back then, the only programming languages I really knew were Batch scripting, Java, and R. And frankly, I couldn't stand Java. I still remember having to memorize entire Java encryption functions just to write them down by hand for software engineering exams. I still can’t quite believe I pulled that off—how in the world did I memorize all those encryption algorithms?! Even today, thinking back to it baffles me. Java never "clicked" with me. Honestly, I wish they'd taught us Python 🐍 instead—but I understand that universities need to cater to broader curriculum requirements for future Telecommunications Systems Engineers.
So, R it was. Wait… the R programming language? Isn’t that just for data science, statistics and charts?! Yep, it definitely is. But at that point, I figured probably nobody in the entire world was writing network management tooling using R—so why not start myself? By the way, some R-related questions I asked back then on StackOverflow, AskUbuntu and superuser are still useful to others today.
Now that I look back, this probably wasn't the wisest choice. What I actually needed was proper mentorship. But at that moment I was alone, so I just dove straight in, and naturally ended up doing something a bit unusual (or outright crazy 🙃).
Building the Solution 🛠️
As I continued developing my solution, I was faced with even more decisions. How exactly should I architect the software? Should I regularly pull and cache the data into a database, or should queries be run on-demand across all Unifi Controllers and MikroTik hotspots each time someone searched for a client location? Ultimately, I decided to gather and store all of the data in MongoDB—simply because, at the time, there was an existing connector available for R, and to be 100% honest, I was excited 🤩 to explore NoSQL databases.
However, over time I found myself increasingly relying on Python scripts. It was my first experience developing in Python—primarily because many tasks just couldn't run in R (despite my very stubborn attempts to avoid Python at first!). At least I'd given R a solid chance.
To give a nutshell version of what the script did:
- First, it would connect to the main MikroTik core router and extract MAC addresses and user IDs from the wireless registration table (users connected at that moment).
- Then, the script would connect to another MikroTik core router—where all hotspots connected via EoIP tunnels—and retrieve the IP addresses of each MikroTik hotspot.
- Once it had these IP addresses, the script would individually connect to every hotspot, pulling each connected client's MAC address and signal-strength data. Honestly, this was quite tedious—at the time, the entire script took upwards of six minutes to execute. In fact, it was so slow that by the time it finished running, some users had already disconnected from their original locations detected in the first step.
- Next, the script would connect to all the company's Unifi Controllers and similarly fetch MACs and RSSI values. Thankfully, this aspect was somewhat simpler.
- Finally, it consolidated this data and mapped it neatly, assigning timestamped values to each user ID.
If you're curious, the script itself can be found here, and the complete project, including various other services I built around it, can be found here.
Looking back
When I finally presented the end result, the CTO was astonished. Even better, I had earned the respect and recognition of the engineering team. Was it an impossible task? Well, not exactly—but was it a thrilling and rewarding way to push an intern to his absolute limits? Absolutely, 100%.
Admittedly, the paths I took during this experience weren't always carefully measured or guided by an experienced mentor, but I still felt very satisfied with the outcome. Of course, when my own professor at the university later found out the kind of high-quality work I'd done for free, he got mad at the company💥—likely wishing they'd given me something more aligned to the academic standards. Still, for me at that age, it was a great experience overall.
Looking back, I now realize just how important good mentorship is for a young engineer. Effective mentorship can really shape the trajectory of your career. Sure, nowadays AI can partially fill some mentorship roles, but nothing beats having a real human connection —someone experienced 👨🏫 who can guide you personally and directly. If I’d had a mentor back then, I think I could have made even better career decisions.
Today, at my current job, I frequently help new colleagues get onboarded 🧑💻; however, I always try to go beyond just training—I strive to mentor them, spending time to really help them grow and encouraging them to think outside the box. Honestly, I wish I'd had someone like that guiding me back then....
