When I was in high school in the 1990’s I thought I was some sort of hot sh*t super coder hacker type dude. I was fluent in assembler on my 486, knew MS-DOS inside and out to the point of hot patching and rewriting parts of it, wrote my own TSR multi-tasker, cracked shareware with debug.com, and wrote graphics demos that weren’t in the same ballpark as the real demoscene stuff, but I’d managed to convince myself were pretty good anyway. Hell, I was even the ‘go to’ guy in my peer group when it came to cracking OS/2 software. 486’s running MS-DOS (and occasionally OS/2) were obviously the entire computing world, and I was the best programmer in my small town, and that was all there was to that. Then a family friend who’d and gone off to college came back to visit.

“Do you know any Unix?” he asked me, “Its kind of a big deal”

And while I doubt I would have admitted it at the time, I had never heard of Unix, and it turns out, it is kind of a big deal.

My first experience with a Unix-like OS came in my Junior year of high school. It was the early 1990’s and there was this internet thing I’d heard a lot about, but didn’t quite understand. (What do we need the internet for anyway really, when we have all these cool local BBS systems). A business a couple of towns over had a BBS for some sort of business purpose that I never quite understood, and if you called up the right person at the company and asked nicely, they would give free access to the general public to log in and use the system on nights and weekends.

The draw of this BBS, over any of the myriad of other local BBS’s run by teenage kids out of their bedrooms and basements (including the one by that time running out of my basement), was that it had “The Internet”, whatever that meant. “The Internet” in this case turned out to be an online door program, just like all the games I played at other BBSs’, but in this case, it just dropped you at a command prompt. Thankfully the BBS also had some instructions you could download, to get started. There was a ‘www’ program, which seemed dumb to me, no future in this world wide web thing, certainly, but there was also this thing called ‘ftp’, which was most certainly not dumb.

The BBS’s internet gateway was running Linux, of course, I forget the exact version but I recall it was kernel version 0.99 something or other. I knew just enough to ftp to a site, go to a directory that looked interesting, download the index file, then use ‘!’ to spawn a subshell and open the file in ‘vi’ to read the descriptions of each file and pick the ones I wanted to download, then exit the editor (Esc :q! seemed like the most random way to quit a program to me at the time), exit the subshell, ‘GET’ the files, and then finally quit ftp and the door and back to the BBS. Then another door to copy files from the Linux box to the BBS, and finally a file transfer area to actually download to my computer over the modem (a blazing 28.8k I believe by that time).

At the time, I had zero interest or understanding of what this Linux thing was. To me it was a glorified ftp client. It seemed clunky and had random weird commands and keystrokes for everything. It was nothing but a weird tool I needed to use to get awesome files from all over the world, and I used it to download all sorts of esoteric information and code to teach myself even more about the important world of computing– MS-DOS on a 486 home computer. I downloaded stuff like co-routine libraries for Turbo C, and specifications for accessing DPMI, the important stuff.

It wasn’t until a couple of years later when I went off to college (lugging with my my tri-boot 486- MS-DOS, WindowsNT, and OS/2), that I discovered Linux for real– my room mate was a Linux fanboy and soon had me converted. Our in room dial-up to the school computers provided a terminal into our school computer system (running Ultrix, so my first “real” Unix experience). Rather than the two of us fighting over the room’s only phone line, we soon had SLIP set up on his computer, and a null modem running across the room to mine, which meant we could both be telnet’d into the schools computer at the same time. It was like living in the future! Or perhaps like living in 1972 for those whom MS-DOS wasn’t cutting edge. My computer soon became a quad-boot system, thanks to a Slackware disk, and over the next few years the other OS’s got less and less run time until I was down to just a dual boot Linux/MS-DOS system.

tldr; Ultrix. My first Unix was Ultrix.

One of my goals with installing FreeBSD on my laptop was to be able to use it full-time for work when working from home. For this I needed to be able to accomplish all of my normal daily tasks without sneaking off to boot up a Windows machine or something. Most of what I needed was pretty straight forward, I spend most of my time in a terminal, ssh’d into various machines at work, in Wireshark, or in a Web Browser, all of which work perfectly on FreeBSD.

Of the few programs that were more difficult, Skype ended up being the most difficult by far. There are of course other voice chat programs, but since Skype is what the rest of my team uses, its what I need to use. Modern Skype clients just aren’t available for FreeBSD. It would seem otherwise, looking at Google, but all of the methods people used in the past to get it working are no longer applicable. There was an old skype client in ports that used to work, but that doesn’t support the modern protocols skype uses. In theory you should be able to run the linux skype client using the linux-emulation layer, but people online didn’t seem to be having any luck with it, so I didn’t even try that route. There were some posts on-line from people claiming success using the Skype WebClient under FreeBSD by playing with UserAgent strings, but It didn’t work for me– I could log in to skype, but not successfully make calls.

With all native solutions off the table, I figured a Virtual Machine running Linux and a Skype client would be a good alternative and should be pretty easy to set up. It ended up being much more difficult than I expected. Creating a Debian Linux VM and installing skype for Linux in it wasn’t too hard. Getting Skype to show up on my X desktop under FreeBSD by ssh’ing into the VM and forwarding X wasn’t too hard either. But thats where my luck ended, getting audio working smoothly almost killed me.

I started out with bhyve, but quickly found that bhyve supports audio applications in theory, and thats about it. I moved over to VirtualBox to discover audio didn’t work reliably for me there either. Audio would work for a few minutes, and then stop playing until I restarted the VM. I tried all of the audio options available, I even tried installing VirtualBox from source so I could enable the PulseAudio back-end, but still with no luck.

What finally worked for me was to install PulseAudio on my FreeBSD host and set it up to listen to network audio on a TCP port. Then in the VM I set the PULSE_SERVER environment variable to tell Skype itself to send audio over the network to my host. This doesn’t use PulseAudio for VirtualBox, in fact VirtualBox doesn’t need any sound support at all. The Skype Application just sends whatever audio it wants to output over the network instead. At first the audio was very choppy, but I was able to resolve this by increasing the buffering on PulseAudio on the host.

Finally Skype audio calls and I can join all my Skype meetings for work while running FreeBSD on my laptop (and cheating by running Linux in a VM, but that’s life). I can also see co-worker’s screens that they share and see their video feeds if they enable one (though frame rate is poor due to using X forwarding). However I’ve not yet found a way to share my own screen with this setup which is kind of a bummer, and I can’t send a video feed of myself (which I don’t care about at all). Presumably I would be able to use a USB webcam if I could pass it through to VirtualBox, but VirtualBox on FreeBSD only supports USB 1.1 and my webcam is USB 2

When setting up networking on a computer, configuring multiple default gateways tells the system “To send traffic to an IP that doesn’t match any of the configured subnets, any of these gateways will work, pick one”. That’s rarely what the user configuring the system means to express. Commonly they have multiple networks and for each network, traffic matching the netmask should be transmitted to the configured directly to the IP on that network, and traffic that doesn’t match the netmask but “belongs” on that network should be sent to that network’s gateway; but nothing about “default gateway” has told the device what traffic “belongs on each network”. Of course the right way to configure this would be to modify the routing table to tell the computer what network traffic to send to which gateway.

At $WORK we develop and support a Linux based device which has a web based configuration interface we’ve developed. One common support issue we run into is a complaint about the device not responding to certain network requests, and when we troubleshoot, we discover the user has configured multiple default gateways on different Ethernet devices. When the device needs to send to an IP that’s not on one of its local subnets, it sends the traffic to one of the default gateways, which then has no idea what to do with that traffic, since it should have gone to the other default gateway.

The right way to configure this setup would be to set a static route for each gateway on each network interface, routing only the traffic that that gateway will be able to route to that gateway, and our web interface makes this possible by allowing the configuration of arbitary static routes. However many customer’s use this feature untouched and instead just populate a gateway per network interface, and leave it at that, never telling the device what traffic should go to each network– just an IP, netmask, and a gateway. The netmask defines the local subnet of course, but says nothing about the full extent of the network reachable through the gateway.

Its easy to see why this happens, “Network Settings” generally consists of an IP, netmask, broadcast address, and a gateway. Whoever is installing the device gets the network settings from their network administrator– adds them in the GUI and calls it a day. If they have a second network to add (possibly with a seconds network administrator) they get an IP, broadcast, netmask, and gateway for that one and add it in the GUI and call it another day. e. The post-it note they are given by the network administrator with the network settings for the device, doesn’t mention anything about configuring a static route, just the IP, netmask, broadcast address, and gateway for the network. This information isn’t wrong, its just that network administrators tend to consider their network the entire world, so these settings won’t play nice with multiple networks.

Many years ago during a revamp of our product, I proposed adding a ‘routemask’ field to each network in the GUI – the subnet mask telling what IPs could be reached directly on the network and the routemask telling what IPs could be reached via the gateway configured for the network. With this information, we could insert the correct routing statements on the back end and everything would work as expected. This was shot down though, because no one would understand the terminology, and if a user asked their network administrator for the ‘routemask’ of their network, they’d probably get little more than a funny look. Its too bad since in 90% of the cases, if there was a routemask field in the GUI for the network interface, and the network administrators considered ‘routemask’ something they scribbled down on the post-it when handing out network settings, it would be enough in 90% of our installs; with only a few requiring more complex setup then this.

I think the root cause of this is that for the average user, network settings are something they are used to, and understand, but routing tables are not, so they aren’t likely to even think of routing tables when setting up their network. Its not part of the all important post-it.

I did finally implement a pop-up if the user tries to save a network configuration with multiple default gateways informing the user that ‘this probably isn’t what you want’ and telling them how to configure static routes. Hopefully this helps.

I often need to copy text from my terminal and paste it into an email, but xterm, by default, when you highlight text, only places the text in the PRIMARY buffer, making it ready for pasting with the middle mouse button. The secure email client that I’m forced to use for work only allows pasting with Ctrl-V, which uses the CLIPBOARD buffer, making it hard to get the data I want to paste into an email there, so I need some way of synchronizing the two clipboards.

The first option would be to configure xterm to use the CLIPBOARD buffer instead of PRIMARY. This can be accomplished by editing $HOME/.Xresources to add:

XTerm*selectToClipboard: true

I didn’t want to go this route, since I didn’t want every bit of highlighted text to make it to my clipboard. I wanted to keep my clipboards separate but be able to choose what to paste. There are some Clipboard management programs like parcellite which live in your toolbar and let you synchronize, but rather than another GUI to click around in, the solution I decided to go with was xclip.

I ended up with the following script, which I saved in ~/scripts/paste_selection.sh:

#!/bin/sh
TMP=`xclip -o -selection clipboard`
xclip -o -selection primary | xclip -i -selection clipboard
xdotool keyup shift
xdotool keyup v
xdotool key ctrl+v
echo "$TMP" | xclip -i -selection clipboard

This command backs up the current text in the CLIPBOARD buffer, copies the PRIMARY text into it, then it fakes a Ctrl+V keypress, The two Keyup events are necessary because I run this script from a hotkey assigned to Ctrl-Shift-V, and without this those keys would still be pressed down when the fake ctrl+v occurs. Finally I restore the CLIPBOARD to its original values.

I put this in a script in my scripts directory and set up a hotkey to call it using xbindkeys by adding the following to my $HOME/.xbindkeys file:

"~/scripts/paste_selection.sh"
  Shift + Control + v

With this functionality I can now at any point use Ctrl-V to paste my CLIPBOARD buffer into an application, or use Ctrl-Shift-V to paste the PRIMARY selection buffer without affecting the current clipboard contents, and can finally paste from xterm into my email app which does not support pasting the PRIMARY buffer with middle click.

After I started working occasionally from my Thinkpad running FreeBSD, I suddenly wanted that environment all the time, but hunching over a laptop to work isn’t the best ergonomics for me. Luckily they had a bunch of old unused Thinkpad docking stations at work (model A402) , and IT let me check one out to try out.

I was able to work from home using my Thinkpad docked on my desk with an external monitor, keyboard and mouse, for a few months, but I eventually got myself a desktop for that use (Currently running GhostBSD), and relegated the Thinkpad back to a portable system.

My experience was basically that I could use the computer as a portable workstation around the house and around town, or I could dock it and use it as a Desktop, but couldn’t do both without being annoyed. Docking and Undocking just didn’t work seamlessly enough under FreeBSD. The dream was to carry my computer around with me, plug it in, keep working on the external monitor, then unplug it and take it with me without missing a beat. I even wrote scripts for dock and undock which would move my windows around between desktops and resize them to how I like them to be when working on the laptop and when working on the desktop (When on the desktop I have two screens, the laptop and external, where I only have the one laptop screen when working portably so I move some stuff to additional workspaces)

Docking Status and Issues

• Ethernet works fine on the Dock– no issues

• USB Mostly works fine, but sometimes if I leave the Thinkpad docked for a few days, I lose the USB devices on the dock and have to physically undock and redock to get them back

• External monitors (DVI and VGA) work as well as the VGA port on the laptop itself, but Monitor Hotplug doesn’t work without restarting X for me on this laptop.

• If I put the laptop to sleep while docked, I can’t wake it up reliably

• The Audio jack on the dock doesn’t automatically mirror the built in audio jack. It might be possible to configure the audio to output there instead of the laptop jack,but I haven’t tried because the laptop jack is more convenient for my setup.

The USB issue wasn’t too much of a problem when I had the system docked all the time, I just plugged my mouse and keyboard into the laptop directly rather than through the dock and all was well, and sleeping while docked wasn’t too important, but the monitor issues caused me to seek other solutions.

The issue isn’t even related to the dock at all- I have the same issue on FreeBSD on this laptop even using the built in VGA Port. Basically if I plug in a monitor while X is running, it won’t be recognized or available in xrandr unless I reboot or restart X. I even opened a thread on the FreeBSD Forum for this but haven’t been able to resolve it.

In the end I ended up using the Thinkpad as a portable FreeBSD station and a separate desktop as my main BSD workstation, which worked much better for me than trying to force the one device into both roles.