Today's story comes to you courtesy of my first-ever programming job, from now four years ago. I was a sophomore in college, and had experience at a basic level with pointers and creating linked-lists in C++. I was given a unique opportunity to program a software-defined radio (from here on known as a "SDR", basically, a very expensive WiFi card). Doing so required implementing a Windows NDIS driver, which as you can probably guess meant I was a little over my head, and there was a bit of a learning curve associated with it.
SDR's serve to help reduce the cost of R&D for a new protocol. Developers have a choice: build unique hardware from the ground-up, plug in some code, and hope that everything works easy-peasy, or use one of these things, which have high initial cost, but are purpose-built for allowing any stack of code to run. They handle their own ADC/DAC, and just need a "front-end" (and antenna) to transmit on a given spectrum. For our purposes, I was transmitting a modified 802.11b protocol, so I had to use the 2.4GHz spectrum.
Again: I was a noobie. Readers might be quick to point out "wait, you're still pretty young". Yes, but I have experience now, and have learned from my mistakes. Such as this one.
Seeing as the aforementioned 802.11b protocol was one of our team's own creation (focusing on cooperative networking, in case anyone is curious), this meant a lot of on-the-fly decisions about implementation. Design wasn't really a factor -- I could make linked lists, I tried to separate my code blocks as best I could, but my functions were embarrassingly long. That's neither here nor there, but probably would have helped with debugging (see: previous post).
Onto the subject of mistakes and bugs: when you are running an executable within a command prompt, and it segfaults, it exits "gracefully" -- alerting the user with a printed message to the screen, and killing the process, restoring control of that prompt to the user.
Seeing as this driver was being developed, learned about, and decided upon simultaneously, there were numerous times where I would have a null dereference. For those unaware, that's where you dereference a pointer, attempting to access a member of whatever object that pointer was pointing to, but the pointer was NULL to begin with, therefore accessing memory you shouldn't, and the computer yells at you -- AKA a "segfault".
What do you think a computer does when a null dereference/segfault occurs in kernel-mode code, stuff that is supposed to be super-efficient and super-careful and super-accurate?
 |
| Bad Things happen. |
In the RECEIVE stage, it's an entirely different beast. My (malformed) packet has just taken down every SDR-equipped computer in the lab (aside from the source node). One null dereference, one segfault, and my lab is painted blue.
Honestly, it looked cool as hell.
Segfaults are bad, mkay?
1) Oh, and if you have a really, really bad day, the blue-screen might be a hint that you've just corrupted your Windows install. I had to teach myself how to use Clonezilla to have a backup partition to easily restore from, very shortly after such experiences.
2) When we got these SDRs, we had to have three parts: the SDR, a chip to support the front-end, and the front-end itself. These cost about $4000, total, per SDR setup. As another horror story, the instant we took two of them out of the box they came in, we heard pops and could smell a bit of smoke. A fuse blew, instantaneously. Fortunately, between a $0.10 fuse from Digikey, and someone who was way more adept at PCB reading, voltage-drop measurements, and soldering than I, we salvaged those things.
