I bought a UniFi wireless access point. Expensive but supposed to be about the nicest you can get for the money. I have high hopes.
Anyway, I was a little worried about getting it set up using their software as so much of the talk was Windows centered. I didn’t need to worry.
This article gave me the commands I needed to install the software and run it on Ubuntu natively.
First add this repository:
deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti
Then run these commands in sequence (make sure you are up to date before you begin).
# First get the key for the repository you just added
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50
# Update your repository lists and install unifi
sudo apt-get update
sudo apt-get install unifi
# Check to see unifi is running
sudo service unifi status
You are supposed to be able to visit https://:8443/ but I had to add localhost to the URL, so you may want to try this instead:
When you first visit the controller, it will walk you through a basic set up process. That’s pretty much it.
A user here at work borked one of their Windows 7 virtual machines after installing a VPN client and making some DNS/hosts changes. There uninstalled the VPN client (something from SonicWALL) but the issues persisted.
IPconfig had some interesting clues, but some external sites were also having intermittent issues: sometimes gmail or google or amazon would or would not work. This seemed DNS related.
Nonetheless, I wanted to eliminate the possibility that the VPN hadn’t left something altered. I thought perhaps there was something related to the NIC so I removed and re-install the NIC drivers. This did nothing.
My co-workers insisted I remove the virtual NIC and add another in its place. I insisted killing the driver was a sufficient test, but since they kept going on about it I killed the virtual NIC just to silence them. This did not work: it neither fixed the issue nor did it silence my helpful audience.
My admittedly brilliant network-guru boss even kicked me out from my terminal to hack away at it for a bit. I wasn’t able to wrestle my desk back until the user in question asked for his machine back and I insisted I had to leave for the day. I resolved to fix it first thing in the morning. Sometimes a fresh perspective is all you need.
That and some gardening, I suppose.
Anyway, the next morning I went to work on one of the suggestions of my co-workers by trying to find some sort of removal tool for the already-removed VPN client. In doing so, I noticed two things that started working in the back of my mind. First, DNS resposes sometimes included an incorrect fully-qualified suffix. Second, I was seeing the IP address of 127.0.53.53 for this VM.
I found this article on the IP address 127.0.53.53 and discovered that this was in fact a sort of error message. In short it’s your network complaining that there is some degree of name collision happening. This strengthened my position that it was a DNS issue.
I abandoned the whole un-installer nonsense and started poking around the network preferences.
If you open your network connections, you can find at least one connection to follow along.
Here you can see both your IPv4 and IPv6 entries. You may want to check both of them (future proof?). Anyway, pick one and click the Properties button.
Nothing much to see here. Just head directly to that Advanced button.
Here is the meat. This is where you control your DNS suffixes. This is default.
Funny thing, Windows has two radio button choices for how to deal with DNS suffixes. The first reads “Append primary and connection specific DNS suffixes”.
The second reads thus “Append these DNS suffixes (in order):”.
The interesting thing to note is the total lack of reference to the primary suffix if you choose the list. You must include the primary (and any connection specific) if you use the second option. His list did not include them.
Long rabbit hole with a simple solution. I added the (in our case one) primary suffix at the top of the list and corrected the local access issue.
I have been upgrading certain machines here at work and testing various items along the way. First one item of concern.
There is a great package out there for Windows domain integration called likewise-open. We had a 13.10 machine running and connected to our Windows domain using this package. It’s a great package and it really streamlines the domain membership problem.
Unfortunately there is currently no 14.04 package available in the repositories. The machine we upgraded is currently not able to log in using domain credentials. Since it’s Friday at 16:09, I created the user a local administrative level account and we’ll look to doing more as is necessary (but surely next week).
I imagine this package will appear in the repositories before long. We shall see. Just be forewarned if you are planning to upgrade any Windows domain connected Ubuntu machines any time soon.
But there is a nice delight to offset this. The old vmware-view-client package which was broken due to a misplaced dependency and which has finally been removed from earlier-version repositories has been replaced in the 14.04 repositories with a working version. Now you can use vmware-view-client to attach to your View sessions and you can do so using the VMWare native PCoIP protocol.
I won’t pretend to understand why the makers of dd-wrt would make all the installation tools Windows executables, but they have. I mean, it’s a Linux based firmware. Silliness.
Fortunately I didn’t need Windows to use their tools. I was able to download their files and run them all under Wine in Ubuntu 10.04 for my Linksys WRT54g without any troubles—until I arrived at Step 20. Their tftp.exe wouldn’t run under Wine. Turns out, though, I didn’t need to use their tftp.exe at all.
In case you are not already using Wine, you can find it in Synaptic easily enough. You should not need to perform any special configurations.
You will want to replace Step 20 with a manual ftp installation of some kind. I used TFTP. You can install TFTP through Synaptic or by entering sudo apt-get install tftp at the command line followed by your password when prompted for it.
Either way you’ll want to have a terminal open for the next bit.
Once TFTP was installed I went to my terminal and changed into the directory where my dd-wrt file (mine was called dd-wrt.v24-12548_NEWD_micro.bin) was located on my local machine: cd /path/to/dd-wrt/location
Then I merely ran the following TFTP commands. Once I entered the first command below I was taken to an FTP prompt (that’s the > pictured in the commands below). You won’t need to type that; it’s just here to separate the FTP commands from the terminal commands. You can leave FTP and return to your terminal by typing q or quit at the FTP prompt (and hitting Enter, duh).
When it worked my terminal returned the message “Sent 1703936 bytes in 2.6 seconds”.
(You needn’t worry much about Step 21 or Step 22 either.)
Also, I was twice prompted by dd-wrt on the router to set a password. Once when I installed it and once again after I hard-reset it (Step 24). That’s normal. Just go with it and pick a nice complex secure password.
You can find the instructions for installing dd-wrt on a WRT54g v5here. Just remember to refer to the above when you get to Step 20 (if you are using Linux). Their site has a strong catalog of routers which can run dd-wrt. Hopefully yours will be among them.
They also sell certain routers with dd-wrt already installed in case that’s a better starting point for you. Check out their home page.