Aug 302016

A recent conversation I had about real time and embedded systems reminded me of a problem we encountered at my company not too long ago. Namely, cpu throttling and kernel page caching having negative side effects.

With cpu throttling, a daemon called cpuspeed will try to optimize performance and on real time applications this might actually be an inhibitor. Depending on your flavour of Linux, this daemon may or may not be installed and the location of the configuration file might change. For example, on minimal installations of Redhat the daemon is not installed. On desktop installations it is and it’s not configured for optimal performance. On Redhat you can try:

If it’s there, you can either remove it or change it’s governor to performance in /etc/sysctl.conf from, for example “ondemand” to “performance”.

Kernel page caching essentially tries to cache anything that’s read from or written to disk in RAM. If you have an application that needs an abundant amount of memory but the kernel has tied most of it up in caching, it might take too long for the kernel to relinquish that memory. In more recent versions of the Linux kernel, there is a setting that only allows the kernel a certain amount of memory to cache from. For example, to ensure the kernel leaves at least 10gb of memory available. You can can edit/etc/sysctl.conf with the following setting.



Nov 182015

I’ve always been intrigued by computer security but I never had a lot of time to integrate the computer science and mathematics into it like the way I have with digital signal processing. In particular, I think I’d like to do a bit of research into wireless communication security. There’s no better way to learn than by doing, so I decided to experiment with Kali Linux and build my own penetration testing tablet. I was watching a Defcon video recently and someone mentioned something called a “Pwn pad”, a penetration testing tablet by PwnieExpress which comes bundled with Kali Linux Nethunter:

The Kali Linux NetHunter project is the first Open Source Android penetration testing platform for Nexus devices, created as a joint effort between the Kali community member “BinkyBear” and Offensive Security. NetHunter supports Wireless 802.11 frame injection, one-click MANA Evil Access Point setups, HID keyboard (Teensy like attacks), as well asBadUSB MITM attacks – and is built upon the sturdy shoulders of the Kali Linux distribution and toolsets.

Why buy one when you can build one yourself? After scowering the internet for instructions (of which most were outdated or just didn’t work), I managed to create a concise set which worked for me. Of course, use the following instructions at your own discretion.

Team Win Recovery Project twrp-
Kali Linux Nethunter 2.0 for Nexus 10 (Mantaray Kitkat) image

Hardware I use:
TL-WN722N High gain 150mb/s USB wifi adapter
SENA UD100 Industrial Bluetooth USB Adapter


Just a few basic steps to root and flash your Google Nexus 10 to use the Kali Linux Nethunter image.

  1. Transfer the Kali Linux image to the tablet
  2. Reboot your Nexus 10 into the bootloader screen by holding down both the volume buttons and the power button at the same time (3 buttons), hold until the bootscreen shows up. plug it into your computer
  3. From your terminal:
    > sudo apt-get install android-tool-fastboot
    > sudo fastboot oem unlock
  4. Select yes on the device by toggling the volume key and pressing power
    > sudo fastboot flash recovery /path/to/twrp-
  5. Toggle the volume button to Recovery Mode and press power to select it. The TWRP screen will now load.
  6. At this point, I would make a backup through TWRP in case things don’t go as planned.
  7. Do a factory wipe through TWRP. Reboot, it will ask you if you want to install SuperSU, do so.
  8. Finish installing SU after setting up your tablet by opening the SuperSU application. I used TWRP to download and install the application, not Google play. Reboot into recovery mode, select install, and select the Kali Linx image.

These instructions are from memory. I messed around and tried a bunch of things on the internet that didn’t work since they were outdated, this should be the least amount of work to be done to get it running. Voila, here’s a picture of mine:



Post install list:

  • apt-get update
  • apt-get upgrade
  • apt-get dist-upgrade

It comes with very recent versions of Python and g++ which was nice. Good luck and happy testing!

May 032015

I had a problem this weekend where the following snippet would compile within Eclipse, however the IDE would still complain with things like “Symbol ‘array’ could not be resolved”:

There were lots of people who were able to fix this problem by simply adding the appropriate paths, but since it compiles in my case this wasn’t the solution. Anyway, some genius on Stackoverflow figured it out:

Add the symbol with name “__cplusplus” (which in this case is apparently an override):


with the following value:


Now use “Run C/C++ Code Analysis and the red underlining from the unresolved imports goes away:

There is still that red on the left hand side which is just highlighting of the scope which bothers me. This can be removed by right clicking on the red portion, going to preferences, text editors, and removing the “Show range indicator.” check mark:

Finally something nice looking:

Note that for this example I still needed to ensure I was using the C++11 Language Standard:

Jan 242015

Selenium requires launching a browser on whatever machine is running the tests. Having a display connected to every machine you wish to run Selenium tests on is incredibly cumbersome. To get around this, you can do headless Selenium testing using a program called Xvfb which is a display server implementing the X11 display server protocol. I realize that there is a Xvfb plugin for Jenkins. However, I’ve experimented with it and found it wasn’t completely stable.

First we install Xvfb:

I made a previous post about installing a command line tool as a Linux service, so you could go that route. But if you’d prefer to just use it on the fly then you could do the following:

Add an init.d file to start Xvfb on a particular display variable, in this case 99:

Add the following to the xvfb file:

Then change the permissions on the script and see if it works!

Then in the Manage Jenkins menu, we add an environment variable DISPLAY with it’s value set to :99 in the Jenkins system configurations. I believe by default these variables are inherited by every Jenkins project unless you choose otherwise. If you wish, you can also add ‘/etc/init.d/xvfb start’ to /etc/rc.d/rc.local in order to have it start a server on DISPLAY=:99 every time the machine is rebooted.

Jan 112015

There are scenarios out there where you’d like to run a command as a linux service. Maybe you have a script you would like to run every time Linux is started, who knows. In my case, I had written a Python package which started a web server to listen for HTTP posts and then did something specific with them. It needed to be started every time the machine was restarted. I was using Fedora 16 at the time, not sure how this will hold up on other Linux distros!

Luckily, Linux has a special command, chkconfig,to take some of the pain way. Straight out of the man page:

chkconfig provides a simple command-line tool for maintaining the
/etc/rc[0-6].d directory hierarchy by relieving system administrators
of the task of directly manipulating the numerous symbolic links in
those directories.

There was some debate about what RC actually stands for, , but it seems the consensus is run commands. Here is essentially the script that I ended up using, but of course replacing name_of_service and my_command. The important thing is that my_command is visible to root, i.e., my_command is located somewhere like /usr/bin.  In the script we have:

Provides: name_of_service

I’m not sure if it’s necessary, but I also chose this as the name of the script.

The first thing you need to do is place a script like the one above in /etc/init.d./name_of_service

Since I knew what I chose for “my_command” was unique and would only ever be run once, the way I defined stop() works fine. However I don’t like it and I think I’ll refactor that soon. There should be no guess work into what running “service name_of_my_service stop” will actually end up doing. After a bit of digging, there is a way using the PID generated by the service:

I also knew that there was possibilities of my tool exiting with an error when attempting to start/stop/restart (things like permissions, etc), which is why RETVAL=$? is called after each command. If any of those 3 commands are called and exit with a non-zero status, then the entire call will indicate a fail.

Moving forward, we have Linux manage the service:

Done! You could now run:

But if you wanna learn a bit more about these portions:

Check out the references. Essentially we have what we would like to be loaded by the operating system prior to starting our service, and then define the default run levels of the service.


Jan 112015

Edit Oct 25, 2017: Thank you to Andy for the latest solution in the comments and for n3rdly confirming this works on Jenkins 2.86

As much as I adore the butler it’s always fun to customize things. The simplest way I found to change the logo is to use a theme plugin:

You can write a CSS template, say theme.css:

and then place pumpkin.png and theme.css into userContent folder in the home directory.

Once the plugin is installed, you will have access to some extra configuration settings in “Configure System” under “Manage Jenkins” that you will need to update: