Fedora 24

This week I have been updating my machines to run Fedora 24. Two out of 3 updated without any issues and continue to run normally. One machine however has decided to cause me some issues.

My old Toshiba X200 laptop had followed the upgrade instructions to the point where it needed to reboot. So I rebooted the machine and left it to do its work. Returning some time later expecting it to have completed I was disappointed to see it stuck doing nothing. After some investigation it appeared I was getting an error to do with an Invalid PCI ROM Header, the value didn't match what was expected. I couldn't boot the machine without this occurring and left me scratching my head for a bit. There doesn't appear to be an obvious solution online. Others have reported similar issues but apart from seeing the error their machines have fully booted.

I decided to try adding a few flags to my kernel boot parameters. Finally I go one to work. Adding "pci=norom" seems to have done the trick and allowed the machine to continue to update. I won't know until the upgrade is complete if I will need to add this option back in permanently. But hopefully it won't be anything more than that.

The Rodent Battle – It’s not over yet

In my previous post at the end of July I had resorted to calling in the Rat Man to assist me in my struggle. When that failed to show results I detailed my nuclear option of removing all of my loft insulation and denying the rodents access.

The button was pushed. I have spent many hours removing all the insulation. It's not an easy or pleasant task but there is no place left to hide. The entry points were filled with steel wool held in place by more expanding foam. You do get some funny looks bulk buying expanding foam but it all got used.

All has been quiet in the loft for the past few weeks. All that is left to do is have a proper clean up of rodent droppings, repair of eaten network cable and re-insulating before winter.
Everything has been going to plan.

Until today. I was sat at the computer catching up on a few podcasts when I heard the noise. The noise that has kept me awake at night, the noise that caused the pressing of the nuclear button. The sound of the rodent scratching about. The precise location I am uncertain about. I suspect that it is not from the loft, unless it has been enjoying its diet of steel and foam. By my estimation the noise is from the cavity wall above the window. I am guessing that little Ratty not being able to ascend to loft level has decided to compromise by setting up home atop the lintel over the window.

How I proceed at this point is uncertain. I need to insulate the loft for winter provided it is still secure. But it appears that a peaceful nights sleeps is not going to be an option in the short term. A new plan of attack is required.

The Rodent Battle

This month I finally called in the Rat Man to rid me of the menace in the loft. He managed to attend 2 out of the 3 scheduled visits. Having time off work and his no show did not go down well. In any case the traps are being avoided but they do like the additional bait they are being provided with. So after 2 visits and not hearing any movement above me I was a little happier. This evening however, following yesterdays no show, I hear scurrying once again. So in summary I have had 3 afternoons off work for no improvement in the situation whatsoever.

I am getting very close to the nuclear option of stripping out all the loft insulation and permanently denying them access by any means necessary (even if it means taking the roof off). It nibbled though my network cable and I have a zero tolerance approach to network intrusion.


A six pack of rats.

To battle the rodent menace I have 7 traps in my loft. Yesterday I went up to check them; 6 were full. Of the 6, 5 suffered a quick demise through a direct head strike. One unfortunate victim was caught by the tail and eventually passed away from probable starvation/dehydration after a struggle with its surroundings.

In an additional observation one of the head strike victims appeared to have had its hind leg eaten off.

SPI Bus Problem Solved


This image is the result of a week of pulling my hair out. It is a simple read of a register on a device connected to a micro controller over an SPI bus. The protocol was simple, the code driving it was simple, but until today it refused to work. I had checked the connections, the component values, changed some of the hardware but wasn't having much luck.

The time came to get it onto the oscilloscope. I treated myself to a Rigol DS1054Z a few months ago and it has proved its worth already. Having access to a 4 channel scope with protocol decoding has allowed me monitor the bus and find my fault. The scope revealed that the SPI MISO line was signalling the same as the SPI Clock. It turned out I had a tiny solder bridge between some header pins on a break out board, never would have thought to look there. After removing the solder bridge I now have a working SPI bus. Now time to do something with it.

Bash Exploit

Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)

Well I read this article whilst I was at work. Upon getting home I started up my Fedora machine and ran the following check to see if I was vulnerable.

To test if your version of Bash is vulnerable to this issue, run the following command:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If the output of the above command looks as follows:

this is a test

you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

I was vulnerable. But that is what I expected. Knowing that the fix might take a little time I added the suggested workaround to my firewall script.

Workaround: Using IPTables:

A note on using IPTables string matching:

iptables using -m string --hex-string '|28 29 20 7B|'

Is not a good option because the attacker can easily send one or two characters per packet and avoid this signature easily. However, it may provide an overview of automated attempts at exploiting this vulnerability.

In full knowledge that this vulnerability was/is going to get exploited I was monitoring my firewall logs. I had set the rules to log and drop the packets. Note that the work around says it can be bypassed. A couple of hours with the rule in place and nothing unusuall was being logged and I was carrying on as normal. All of a sudden 4-5 packets were caught by the rule. My system was shutdown seconds later. I susspect that this is some opportunistic scanning taking place, however I am not taking any chances until a patch is ready.

On the plus side it has given me the opportunity to boot and update my Windows machine.

Tmux – Solving The Problem Of Window Names

I was lucky enough to get a book on using tmux for Christmas. Following through the examples I noticed that I was not getting the expected behaviour when attempting to set window names.


$ tmux new-window -n console

What this should do is create a new tmux window and within it a window called "console". What I was getting was a tmux window containing a window named after my command prompt e.g. 'bob@computer ~'. This was bothering me so I set about researching the problem, unluckily for me its not one that is that common. By chance I located a post linking to a RedHat bug report https://bugzilla.redhat.com/show_bug.cgi?id=969429. The report outlines a problem regarding a change in terminal escape codes and highlighted an identical problem with screen as I am having with tmux. I checked the escape codes in my .bashrc file, nothing wrong there. Next stop was /etc/bashrc.


  if [ -z "$PROMPT_COMMAND" ]; then
    case $TERM in
      if [ -e /etc/sysconfig/bash-prompt-xterm ]; then
      elif [ "${VTE_VERSION:-0}" -ge 3405 ]; then
          PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      if [ -e /etc/sysconfig/bash-prompt-screen ]; then
          PROMPT_COMMAND='printf "\033k%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/~}"'
      [ -e /etc/sysconfig/bash-prompt-default ] && PROMPT_COMMAND=/etc/sysconfig/bash-prompt-default

/etc/bashrc contained the above code section. It comprises two different sections for different terminals, each has its own prompt with different escape codes. The but report highlighted that the problem lay with the 033k escape code where as 033]0 worked. I should only be using the problematic escape code if I am using a screen terminal. So which am I using?


$ echo $TERM

The result from running the above command in my gnome-terminal was "xterm-256color". This was expected and what I assumed I was using. Running it from inside a tmux session I got "screen-256color". Tmux using a screen terminal is pointing back to the problematic escape code. Time to go back to the .tmux.conf and check my settings.


# Use 256 term colours
set -g default-terminal "screen-256color"

There is my problem line, I have set it to use the screen terminal, oops.

.tmux.conf - Correct

# Use 256 term colours
set -g default-terminal "xterm-256color"

By using the xterm-256color terminal I correct the problem with the escape code. Rerunning my initial tmux command tmux opens with a window named 'console'. Problem solved.

Return of the Rat

The sound of something reminding me of a cat scratching could be heard in the loft. I don't have a cat in the loft, only insulation and a trap.

Ascending into the roof space it was clear that all was not well. An aroma tainted the air. The trap had seen action, some time ago by the state of its occupant (sorry no pics this time). This means I have a live one still to get. The trap has been reset. Fingers crossed for another victim in a day or so.

Bang!, Jug Time

I awoke this morning not looking forward to the busy day that was waiting for me at work. Imagine how I felt when upon pushing the button to start the electric shower I was greeted with a Bang rather than the cascade of hot water. I was less than impressed at the lack of water, especially as I was already behind schedule. I grabbed the measuring jug from the kitchen and scooped water out of the sink and dumped it over my head whilst standing in the bath. I reached work less than ready to start the day.

Researching showers it became apparent that I might just be lucky on replacement options. So after stocking up on advice from my colleagues I ventured to a DIY store to part with some money. Trying to fit a shower in a small bathroom at the end of the hard day can hardly be called fun. I was driven on by the desire for a shower to ease my aches and pains. Two hours of drilling, cutting, wiring, sealing, compressing later I had a box on the wall with water and power going in and a hose coming out. The moment of truth, I flipped the breaker, it  stayed on. I pulled the isolation switch cord, it lit and so did the power indicator on the box. I turned the box to cold, cold water began to spring forth from the shower head. Turning the box to hot, a few seconds wait, warm water began to emerge. Success, my first plumbing job and it has worked. No leaks, no power tripping or electrocution.

It may have been a long day but just the knowledge that a hot shower awaits me in the morning means I can relax and have a restful nights sleep.

Keeping My Hat On

In my previous post I outlined my thinking about moving from Fedora to OpenSuse. I installed OpenSuse 12.3 onto mylaptop and had a play about. The installer was clean and easy to use and everything was setup with the minimum of effort.

Two issues with Fedora prompting a move were the control over the firewall and the Arduino software not being up to date. I was disappointed to that the installation of the Arduino software didn't come with a desktop icon setup but the latest version was there to use. Now onto the firewall; things were not good.

OpenSuse has completely removed the iptables scripts for managing the firewall. It seems you will use their firewall daemon and associated setup program. So basically the future looks like I will be being forced into using a wrapper of some sort around the iptables rules for my firewall. What's more, after doing some reading it would appear that more applications will rely on this dynamic functionality in the future. So what do I do? I can, on Fedora at least, use my existing script in the short term but need to migrate it. Alternatively I can change distro, waiting a little longer for the inevitable push towards dynamic firewalls.

Where does this leave me now then? I'm thinking of staying with Fedora at the moment. Fedora 19 will be due out in around 3-4 months time. At this point I think a clean installation of my main machine will probably be in order. In the mean time I can work on migrating my current firewall script over to the Firewalld system. It will mean I have to manually install the latest Arduino software but that is at least a manageable task.

OpenSuse was removed from the laptop and Fedora 18 reinstalled. A clean installation does appear to have changed a few things. A series of upgrades over the years had left a few legacy options it seems. The Fedora installer was not as user friendly as the OpenSuse installer, especially when it came to creating the dual boot with Windows on a separate hard disk. That said it did install and I'm sure it will improve in the future.