Category: Ubuntu

The Dell XPS 13 9343 is the second-generation Sputnik Developer Edition laptop that came pre-loaded with Ubuntu 14.04 LTS (Trusty Tahr). As a former Canonical employee, I was one of the first lucky folks to put that machine into production. And now, over five years on, it’s still one of my favorite ultra-portable workhorse laptops. The only reason it’s no longer my primary Ubuntu machine is due to its paltry (by today’s standards) 8 GB RAM.

So, after picking up a new cyber security contract gig with Alpha Defense, I found myself in need of a dedicated triple-boot Ubuntu, Kali, and Tails sterile-environment machine for penetration testing. And, so I thought, what better way to resurrect the trusty Sputnik after upgrading its BIOS?

Unfortunately, Tails doesn’t support the Broadcom BCM4352 chipset. Per the Tails known-issues page, it is impossible for Tails to use any Wi-Fi card listed on Debian’s wl driver page since it’s proprietary.

But, when doing a fresh install of Ubuntu 20.10 (Groovy Gorilla), Ubuntu also failed to enable the Broadcom BCM4352 chipset, even though I had checked “Install third-party software for graphics and Wi-Fi hardware and additional media formats.”

With the help of the Ubuntu Help BCM43XX page, Wi-Fi was up and running within a few minutes, even with no Internet connection.

After inserting and mounting the Ubuntu 20.10 installation thumb drive:

cd /media/username/"Ubuntu 20.10 amd64"/pool/main/d/dkms
sudo dpkg -i dkms*
cd /media/username/"Ubuntu 20.10 amd64"/pool/main/f/fakeroot
sudo dpkg -i fakeroot*
cd /media/username/"Ubuntu 20.10 amd64"/pool/restricted/b/bcmwl
sudo dpkg -i bcmwl-kernel-source*

If you’re running with Secure Boot enabled, follow the on-screen instructions, and be sure to Enroll MOK when prompted on reboot.

I’m a bit surprised that Ubuntu 20.10 doesn’t support Wi-Fi out of the box on a machine that was certified and pre-installed with Ubuntu 14.04 LTS. But so be it, my favorite laptop is back up and running with a fresh install!

Years ago in 2007, when I first joined Canonical as a staffer, I attended their yearly in-person all-hands meeting during my second week of employment. During the opening plenary, after the icebreaker where all new employees were asked to stand up and explain the history of their IRC pseudonym, the presenter lamented, “We hire bloggers who immediately stop blogging.”

The presenter then went on to talk about how many prospective candidates make it through to the final-round interviews because of their public open source contributions and blog entires. Which makes perfect sense! Ubuntu is open source. Canonical hires expert open source contributors. And what better way is there to promote your open source contributions than to blog about them!

But the comment about how new hires stop blogging really stayed with me. While working at Pepper before Canonical I used to blog daily here on Inert Ramblings and many other now-defunct platforms and forums. I blogged about everything from diet and exercise to tech industry news to photography and journalism.

I Immediately Stopped Blogging

Three months before my team was officially hired by Canonical, Pepper was contracted with Canonical for three months to work on the then-skunk works Ubuntu mobile project.

Everyone at Pepper, including myself, went heads-down with tighter deadlines and more intensive workloads. We found less time to work on our personal open source projects and endeavors. Which in turn led to less things to blog about. Even our after-hours personal time was now dedicated to Canonical projects.

Don’t get me wrong. This wasn’t a bad thing! I’m a geek. I have geek hobbies. Canonical was my dream job and my workload coincidentally paralleled my hobbies. So, for me, it was a win-win!

The only real difference was that I stopped blogging because I was so busy with work. I stopped posting to Inert Ramblings. I stopped posting to photography forums. I stopped posting to coding forums. I stopped posting to the social media platforms that were active at the time. I even stopped rally racing.

It’s not that the previous culture at Canonical dissuaded against blogging. It’s just that there was no incentive to blog anymore. If we were blogging then we weren’t working towards our deadlines. And, although Canonical management made the occasional comments wondering why folks stopped blogging, there was never an official company policy to promote blogging and make it part of our daily workflow.

Start your blogging engines!

Luckily, things changed a few years ago. Canonical holds quarterly product roadmap sprints for key managers and engineers. I organized most of these sprints and, during numerous plenary sessions over the past few years, upper management made it a point to encourage teams to blog about their non-proprietary projects.

Which is great! Canonical’s Ubuntu Blog started seeing more content and traffic. More content started appearing on employee personal blogs. News organizations started picking up stories based on employee blog entries. And, during every roadmap cycle, managers encouraged their employees to blog about what they’re working on.

And the community took notice! More blog content from Canonical and their employees started getting syndicated. My RSS reader is now filled with content from both the official Ubuntu Blog and personal employee blogs!

So, take note. Your company’s marketing team shouldn’t be your only outreach channel. Your employee’s personal blogs can be just as bolstering for your product and service offering!

---

Sean Sosik-Hamor is a former employee of Canonical. Working within Canonical’s IS Team Alpha Squad, Sean’s focus was end-to-end logistics, planning, implementation, and photography for corporate events, summits, conventions, data centers, facilities, equipment transport, and constructing offices and data centers.

He is currently entertaining offers for full-time positions within the photography, event, and data center fields.

Note: Community TFTP documentation is on the Ubuntu Wiki but this short guide adds extra steps to help secure and safeguard your TFTP server.

Every Data Centre Engineer should have a TFTP server somewhere on their network whether it be running on a production host or running on their own notebook for disaster recovery. And since TFTP is lightweight without any user authentication care should be taken to prevent access to or overwriting of critical files.

The following example is similar to the configuration I run on my personal Ubuntu notebook and home Ubuntu servers. This allows me to do switch firmware upgrades and backup configuration files regardless of environment since my notebook is always with me.

Step 1: Install TFTP and TFTP server

$ sudo apt update; sudo apt install tftp-hpa tftpd-hpa

Step 2: Configure TFTP server

The default configuration below allows switches and other devices to download files but, if you have predictable filenames, then anyone can download those files if you configure TFTP Server on your notebook. This can lead to dissemination of copyrighted firmware images or config files that may contain passwords and other sensitive information.

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure"

Instead of keeping any files directly in the /var/lib/tftpboot base directory I’ll use mktemp to create incoming and outgoing directories with hard-to-guess names. This prevents guessing common filenames.

First create an outgoing directory owned by root mode 755. Files in this directory should be owned by root to prevent unauthorized or accidental overwriting. You wouldn’t want your expensive Cisco IOS firmware image accidentally or maliciously overwritten.

$ cd /var/lib/tftpboot
$ sudo chmod 755 $(sudo mktemp -d XXXXXXXXXX --suffix=-outgoing)

Next create incoming directory owned by tftp mode 700 . This allows tftpd-hpa to create files in this directory if configured to do so.

$ sudo chown tftp:tftp $(sudo mktemp -d XXXXXXXXXX --suffix=-incoming)
$ ls -1
ocSZiwPCkH-outgoing
UHiI443eTG-incoming

Configure tftpd-hpa to allow creation of new files. Simply add –create to TFTP_OPTIONS in /etc/default/tftpd-hpa.

# /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS=":69"
TFTP_OPTIONS="--secure --create"

And lastly restart tftpd-hpa.

$ sudo /etc/init.d/tftpd-hpa restart
[ ok ] Restarting tftpd-hpa (via systemctl): tftpd-hpa.service.

Step 3: Firewall rules

If you have a software firewall enabled you’ll need to allow access to port 69/udp. Either add this rule to your firewall scripts if you manually configure iptables or run the following UFW command:

$ sudo ufw allow tftp

Step 4: Transfer files

Before doing a firmware upgrade or other possibly destructive maintenance I always backup my switch config and firmware.

cisco-switch#copy running-config tftp://192.168.0.1/UHiI443eTG-incoming/config-cisco-switch
Address or name of remote host [192.168.0.1]? 
Destination filename [UHiI443eTG-incoming/config-cisco-switch]? 
 
 !!
3554 bytes copied in 0.388 secs (9160 bytes/sec)

cisco-switch#copy flash:?
flash:c1900-universalk9-mz.SPA.156-3.M2.bin flash:ccpexp flash:cpconfig-19xx.cfg flash:home.shtml
flash:vlan.dat

cisco-switch#copy flash:c1900-universalk9-mz.SPA.156-3.M2.bin tftp://192.168.0.1/UHiI443eTG-incoming/c1900-universalk9-mz.SPA.156-3.M2.bin 
Address or name of remote host [192.168.0.1]? 
Destination filename [UHiI443eTG-incoming/c1900-universalk9-mz.SPA.156-3.M2.bin]? 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
85258084 bytes copied in 172.692 secs (493700 bytes/sec)

Files in incoming will be owned by tftp mode 666 (world writable) by default. Remember to move those files to your outgoing directory and change ownership to root mode 644 for safe keeping.

Once you’re sure your switch config and firmware is safely backed up it’s safe to copy new firmware to flash or do any other required destructive maintenance.

Step 5: Prevent TFTP access

It’s good practice on a notebook to deny services when not actively in-use. Assuming you have a software firewall be sure to deny access to your TFTP server when on the road or when connected to hostile networks.

$ sudo ufw deny tftp
Rule updated
Rule updated (v6)

$ sudo ufw status
Status: active

To Action From
-- ------ ----
CUPS ALLOW Anywhere 
OpenSSH DENY Anywhere 
69/udp DENY Anywhere 
CUPS (v6) ALLOW Anywhere (v6) 
OpenSSH (v6) DENY Anywhere (v6) 
69/udp (v6) DENY Anywhere (v6)

Managing multiple facilities across multiple continents can be a pain especially when Wi-Fi is involved. Different regions use different frequencies depending on regulatory domain. And, depending on your hardware vendor, compliant hardware could be backordered.

In my case, the Cisco Aironet 1140 Series Access Point (AIR-AP1142N-T-K9 802.11a/g/n Standalone AP; Int Ant; Taiwan C) is backordered by 4-6 weeks. I guess our Taipei 101 office is out of luck for a while unless I can find a different piece of compliant hardware.

Here are some miscellaneous regulatory notes for when I need to revisit this in the future:

• Cisco Aironet 1140 Series Access Point Ordering Guide [PDF]
• Wireless LAN Compliance Status
• List of WLAN channels
• Channel Deployment Issues for 2.4-GHz 802.11 WLANs