In November of 2015 (two months after my last post to this site), I opted to leave the Internet Service Provider world and attempt something new – the world of Enterprise Networking.
Moving away from a Linux based world was an interesting prospect, but one I often looked down upon. Seriously, the network tools available to a Linux user are more powerful than anything I’ve seen in Windows. My last ten years were spent helping to build a Pennsylvania ISP full of Linux systems that I engineered, virtualized, built, improve upon, rebuilt and troubleshot. I had my hands in everything: Services from email, ftp, radius, numerous webservices, etc, etc. It was a great learning environment and I had the opportunity to work and learn from some impressive people. So while I was hesitant to move on to the world dominated by Microsoft, in time I eventually I grew a strong appreciation for the companies products.
In the 3 years since I’ve moved on I’ve certainly kept busy. I now have access to more advanced Cisco, Fortinet, and Citrix equipment, a fascinating VSAT network at my fingertips, and a network more focuesd on high-availability. The first couple of years were a fun series of regular network events to keep myself busy most hours of the day. At one point I started thinking I would have some form of PTSD if I that pace changed. I pride myself in being able to make solid troubleshooting decisions at 2am with no sleep.
I’ve been so busy, I’ve not posted to Braindeadprojects.com in that entire time.
I created this site as a way to contribute back to a community of online websites, blogs, IRC channels, and mailing lists that helped me learn along the way. A Saturday morning dream about building my own blog and naming it in homage to David Letterman’s “Stupid Pet Tricks” became a weekend project and thus “BraindeadProjects.com”.
I only had time to document a handul of my projects, but I’m happy to share the ones that I have.
The site’s been offline for a couple of months while I handle other items, but I’ve got new articles in the works, more information to share, and I finally moved the site to my personal KVM cluster.
As you can see, the VGA controller has a kernel module loaded and associated with it (radeon), however the Startech (Tehuti Networks) controller does not. With the device ID number in hand (0x4024), we can now look for it in the kernel source. If you don’t already have a copy of the Linux source, make sure to grab one via git:
edge:~# mkdir ~/git
edge:~# cd ~/git
edge: git# git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
edge: git# cd ~/git/linux
edge:~# grep 0x4024 include/linux/pci_ids.h
Hmm…not a single hit. Let’s search for anything Tehuti related:
So there’s device ID’s 0x3009, 0x3010, and 0x3014… but no 0x4024. So it doesn’t appear to be present in the source tree. But a quick search on the vendor website and the drivers are readily available for download – great news, but the running kernel (3.16.0-4-amd64) isn’t supported:
(From the Tehuti_TN4010.zip Readme file)
“- Supported kernels: 2.6.24 – 3.14.x”
edge:~# uname -r
And when trying to compile it, it fails:
/var/tmp/Linux/tn40.c: In function ‘bdx_ethtool_ops’: /var/tmp/Linux/tn40.c:4021:5: error: implicit declaration of function ‘SET_ETHTOOL_OPS’ [-Werror=implicit-function-declaration] SET_ETHTOOL_OPS(netdev, &bdx_ethtool_ops);
cc1: some warnings being treated as errors /usr/src/linux-headers-3.16.0-4-common/scripts/Makefile.build:262: recipe for target ‘/var/tmp/Linux/tn40.o’ failed
So, let’s dig around and see if we can find the SET_ETHTOOL_OPS macro in the changelogs:
edge: git# cd ~/git/linux
edge:git# git log -S “#define SET_ETHTOOL_OPS”
Author: Wilfried Klaebe <email@example.com>
Date: Sun May 11 00:12:32 2014 +0000
net: get rid of SET_ETHTOOL_OPS
net: get rid of SET_ETHTOOL_OPS
Dave Miller mentioned he’d like to see SET_ETHTOOL_OPS gone. This does that.
Compile tested only, but I’d seriously wonder if this broke anything.
Suggested-by: Dave Miller <firstname.lastname@example.org>
Signed-off-by: Wilfried Klaebe <email@example.com>
Acked-by: Felipe Balbi <firstname.lastname@example.org>
Signed-off-by: David S. Miller <email@example.com>
Well, there’s the reason it won’t compile – the macro was recently removed. So how do we get the module to compile? Simple – just update the source to perform the same action that the macro used to do. Or to make things easy (although it’s overkill for a patch file), just apply a truly braindead patch:
edge: tmp## ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 10000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: No
Advertised link modes: 10000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Link detected: no
I’ve passed along the information to Startech. It’s a pretty simple fix, so I’d expect to see it in their distributed source code soon. But in the meantime, if you’re working with this card and unable to get the kernel module to build, see if this solution will work for you.
A couple of months ago, I started to notice a few issues when watching YouTube videos at my home. It seemed that the videos were taking longer to buffer, and a quick check of my Ubiquiti NanoBridge M5 (NMB5-25) revealed my signal had deteriorated from it’s usual -64dBm signal to around -75dBm. The Airmax Quality had also significantly tanked, now reading around 40%. An Airview scan didn’t seem to indicate any new interference:
Throughput tests to two on-network Speedtest.net Mini sites still showed decent rates, but it became obvious that TCP retransmissions were starting to significantly impact surfing the web. Unfortunately, I didn’t think to grab a tcpdump to support that theory.
I had been holding off installing the new NanoBeam M5 (NBE-M5-400) since I wanted to ensure they were stable. While I’ve not been burned by the problems with ToughCable or chain burnout problems on the Rocket Titanium M5’s, I’ve heard my fair share of grumbling from people that have. On the Ubiquiti forum people have mostly raved about the new units so I figured I’d see how well it performs.
On the roof of my home, I have a non-penetrating mount atop two anti-fatigue mats purchased from the Home Depot. The mats aren’t UV rated, something I didn’t consider until later. After a yearlong installation, the mats are in surprisingly good shape. I don’t anticipate having to replace them in the next two years based on their current wear.
The NanoBridge M5 dish itself was still tightly connected to it’s mast, and the 3 concrete ballasts holding the mount in place seem to prevent any possible shifting. Initially when my signal deteriorated, I thought a bird may have slammed into the dish or mount and somehow moved it, but I don’t believe this is the case. The more likely culprit is a tree.
I knew when I installed the link that it was very likely clipping the tree on the right. Our tower is slightly to the right of the valley. Not particularly liking heights and trying to limit visibility from the street, I opted not to move the mount closer to the front of my home. I may revisit that decision in the future. Before I removed the NanoBridge I did try to correct it’s position but was only able to receive around an average of -70dBm at best.
Losing sunlight, I upgraded the dish to the NanoBeam M5. The only thing about the dish I dislike is that it has one U-bolt instead of two. I’m sure it’s ample but the NanoBridge’s 2 U-bolt configuration really seemed to hold it to the pole so that it couldn’t possibly be knocked out of alignment. My roof is mostly flat with a slight angle, so I wasn’t able to fully straighten the dish.
Installing the NanoBeam was quick and easy. The first thing that was obvious was the noise floor had gone from -93dBm to -103dBm. The signal was significantly improved, now running in the -63dBm range, and overall stats were a remarkable improvement over the NanoBridge.
The week before I performed the upgrade, I finally added the Ubiquiti radio to my home Cacti installation. Forgive the ugly colors of the graphs (I plan of making them more visually appealing one day), but as Adam Savage says “The only difference between screwing around and science is writing it down“. These graphs display a pretty clean-cut before and after of the upgrade, which took place at about 20:00.
I incorrectly saved the Airmax graph after the upgrade and only noticed the next day (that’s why this graph is hours after the others).
I’m extremely pleased with the upgrade. My initial problems with YouTube buffering have gone away and three days later things are still going strong. In the end I had a chance to see a pretty cool sunset on Lambs Gap.
About a year ago, we were doing some wireless throughput/interference testing at the office to acclamate ourselves to the wireless world. Most importantly, we were trying to answer the question “Why can’t I just lease a 10 foot section on a tower and install a zillion radios there?”
Despite having a handful of BCP design documents at hand, as well as input from established and respected members of the wireless community, the question kept seeming to pop up. So how does one present a worthwhile answer?
My solution was to build a small section of a tower leg on our back lot using a non-penetrating roof mount, 2 Ubiquiti Rocket M5 90 5G-20-90 degree sectors (mounted 90 degrees from each other, without shielding), 2 Nanostion M5 CPE’s, 4 laptops, and a couple of inverters and car batteries to power 2 of the laptops (the other 2 were run off extension cables). The two laptops connected at the Access Point side ran as Iperf servers, each laptop ran as a client.
The thought was to grab Iperf and AirOS datapoints at every couple of seconds and see “what happens when I do this?” “THIS” generally entailed doing something BCPs warned against doing.
To gather the Iperf data and AirOS statistics, I put together a quick script i called “Ubiquiperf“. Basically it polls an iperf test every second, pulls the stats off the radio (Capacity, Quality, RSSI, etc) , generates a CSV file of all the data, and finally creates a graph using the jpgraph PHP libraries.
Due to weather conditions our testing was cut short and our initial results had a simple problem: we needed to turn the transmit power down on all the radios.
For a baseline, we performed a quick throughput test one at a time, where each Access Point operating on the same frequency could perform at about 85Mbps:
So what happens if I perform the same throughput test on both units but at the exact same time, over a longer duration?
Well, it obviously cut off about 20Mbps from the first access point. Of course, the power on the radios really needs to be turned down so this test is unfortunately not worth much. We’ll be doing additional testing in the near future, and hope to have meaningful results that include mounts with and without RF Armor, Titanium model equipment, etc. I’ll publish our results when I can.