Showing posts with label hardware. Show all posts
Showing posts with label hardware. Show all posts

Tuesday, 8 May 2012

Raspberry Pi meets Edimax EW-7811Un wireless adapter

This post contains my notes - what I did to make it work properly, so next time I build the system, I have a step by step guide. In case you lived under the rock for the last months and don't know what Raspberry Pi is, you should visit www.raspberrypi.org now.

Raspberry Pi

I bought Edimax EW-7811Un adapter for my Pi - small factor, b/g/n type, so why not... especially when vendor says it provides Linux drivers (wohoo!). Sadly as it turns out, compiling drivers on x86 or x64 and ARM architectures can be totally different experience - especially with Raspberry Pi being in it's software infancy. In all seriousness - Pi is for those that like to solve problems (at least at the current stage), but the community works hard to catch up very quickly - great stuff!

Wednesday, 24 November 2010

Building cheap console server

This time from the department of almost wasted time...

We all know that serial ports come very handy when you need to (re)configure something like a switch/server/firewall or similar device. In theory you can do that over TCP/IP nowadays with one hint - you need to have connectivity. All would be ok if not the fact that those very switches/firewalls you want to reconfigure actually provide the connectivity you need :-)

The Idea


Now... why spend hundreds of pounds/dollars on off-the shelf kit? Sure, it's cool, properly built and works unless you mess it up, but where's the fun part?! Today I needed a very very quick and cheap solution, so:

  1. SheevaPlug - £114.00
  2. 13-port USB hub - £19.99
  3. USB-serial dongles (pl2303) - £14.99 each
This way I have fully networked console server with 4 ports just under £200 - acceptable, especially when the whole thing is running off DHCP and calls home via OpenVPN - very easy to deploy!

Tricky bits

Generic Sheeva has one USB host port and hub has 13 of them - I want to send it off to remote location and have somebody plug it in and not mess up what's where. Trick is to write appropriate udev rules to detect adapters and give them ttyUSBn names according to physical port on the hub.


All would be fine and easy if it worked as documented - sadly it doesn't. First problem was that ATTRS{devpath} (as returned by udevadm info --attribute-walk -n /dev/ttyUSBn that allows to distinguish usb ports) was used by rule in tests but wasn't propagated properly on none of my Debian or Ubuntu boxes. Then I tried to match KERNELS for parent devices - nope... if you go too far up the tree it doesn't see s**t :-/


The Solution

Finally I got the working rule set - long story short, here it is:

KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.1:1.0",   NAME="ttyUSB0"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.4.1:1.0", NAME="ttyUSB1"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.4.2:1.0", NAME="ttyUSB2"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.4.3:1.0", NAME="ttyUSB3"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.4.4:1.0", NAME="ttyUSB4"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.3.4:1.0", NAME="ttyUSB5"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.3.3:1.0", NAME="ttyUSB6"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.3.2:1.0", NAME="ttyUSB7"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.3.1:1.0", NAME="ttyUSB8"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.2.4:1.0", NAME="ttyUSB9"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.2.3:1.0", NAME="ttyUSB10"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.2.2:1.0", NAME="ttyUSB11"
KERNEL=="ttyUSB*", SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="1-1.2.1:1.0", NAME="ttyUSB12"


I had to use KERNELS match as above to have variables seen by the rule. I still don't know (and at this moment don't care any more) why it didn't work as documented...

The bottom line is that it works, it can be done way cheaper than commercial solutions, literally at the fraction of cost - if you don't mind the spider-ish look of it :-)


Update:
Hat tip to @herkii for pointing out another approach.

Tuesday, 15 December 2009

AirView2 Spectrum Analyzer

Recently I had some serious problems with wi-fi at home - especially one of the laptops was dropping off and couldn't come back. Quick survey using Kismet and other tools to scan what's flying around has proven that my network is in less populated part of the spectrum (at least here) but still, problems are getting worse and worse.

I was fully aware of Wi-Spy by Metageek, seen it in action previously but never had a chance to buy one. Part of the decision was the price back then, maybe now it would be another game, but anyway - I got myself another device, made by well known wi-fi vendor Ubiquiti and it's called AirView2.


What's so special about this one? Why it's better than Wi-Spy?

First of all I didn't say it's better. It's different, woks with Linux, Mac OS X and Windows, has a nice price tag and does pretty much the same as Wi-Spy. Let's have a closer look then, shall we?


It's different

Well, obviously it is... it comes from different vendor... and this post is not a sales pitch - it's just what I've experienced myself. On a bit more serious note, it's smaller than all the Wi-Spy models I've seen so far. Smaller is good, right? Yes - takes up less space, No - easier to loose (looks almost like USB stick).

Works with Linux, Mac and Windows

Yes, it does... better or worse but it does and it's not a matter of hardware or bundled software, but clearly it depends on the host OS and Java. You got it right - Java!
Software is written in Java to be really cross platform, but those that are not Java developers but use it a bit know quite well what a pain in the rear Java can be. Same is here - Ubiquiti warns about compatibility issues, there are long posts on the forums why this particular version of AirView software doesn't work (mostly on Mac OS X) and how to fix it, etc.

Windows - OK, even inside VM with USB passed through to the guest VM (tested VirtualBox, VMWare Workstation and Fusion - all with Windows 7 and latest Java). It was all very slow, loosing connection with the device and re-initializing it all the time, but worked. In native mode with Windows 7 on bare metal box worked like a charm (tested on a netbook PC).

Linux - didn't try, not enough time - sorry.

Mac OS X
- yeah... that sucked! If you have the latest patches installed most likely the software will hang on detecting the device. Of course the reason is Java + OS X (I'm on 10.6.2 as of now with Java 1.6.0_17 in 64-bit mode).

java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib:  no suitable image found.  Did find:  /Library/Java/Extensions/librxtxSerial.jnilib: no matching architecture in universal wrapper thrown while loading gnu.io.RXTXCommDriver

Exception in thread "AirViewer-Initializer" java.lang.UnsatisfiedLinkError: /Library/Java/Extensions/librxtxSerial.jnilib:  no suitable image found.  Did find:  /Library/Java/Extensions/librxtxSerial.jnilib: no matching architecture in universal wrapper
WTF?! File not found... but found? Never mind - luckily the solution is very simple - AirView comes with it's own version of librxtxSerial.jnilib so the one that came with OS X needs to be disabled temporarily and problem will go away. That can be done very easily with one command in the terminal:

mv /Library/Java/Extensions/librxtxSerial.jnilib{,-disabled}
That's it, now it works :-)

Price tag

This argument is obviously quite important. Is it that much cheaper? I'm not so sure... of course you can get the basic Wi-Spy for about £65+VAT so even if AirView2 would be equal to it in hardware terms, it would cost a bit more - £69+VAT... There is one catch to it though - AirView2 comes in several versions. I bought the AirView2-EXT for £64+VAT and this one has MMCX connector for external antenna (because it doesn't have a built-in one) and with clip-on omnidirectional antenna (~3-5dBi I guess) in the package. To buy Wi-Spy with RP-SMA connector you would have to spend at least £120+VAT which is almost double the price of AirView2-EXT.

HINT: Wi-Spy with RP-SMA is 2nd generation - faster with better scan resolution than the first generation of the device. So far I didn't have enough time to grab the full spec for AirView2 and compare them side by side - that would be very interesting (it's already on my TODO list).

Does it do the same stuff?

I would say YES based on what I can see, but as most of those devices are SDRs (Software Defined Radio), they can do all the software allows them to do and I didn't have a chance to compare recent version of Wi-Spy software to the AirView one, so please take my words here with a grain of salt and look for other sources to confirm that.

Conclusions

The device worked for me like a charm - it turned out that the signal from my AP was attenuated by temporary objects that came in the way (books - whole piles of them) and as the amount of networks around at least doubled in the last 12 months, somebody put up some very messy device that is transmitting all the time with a very wide signal, exactly in the area of channel I was on - so here come the interference!
Quick look at the graphs and it was clear, that simple channel change should cut down on the interference and moving books a bit will improve signal strength in a place where this unlucky laptop is used most of the time - it worked very well, no more problems!

Looking at the bottom line, for me that's a money very well spent! I was asking myself a question 'how often I will use this thing' and now I really appreciate the power of seeing something that Kismet and similar tools won't see.

Using spectrum analyzer like AirView or Wi-Spy (doesn't really matter which one - pick one that suits your needs) is like reading between the lines - there is a lot of valuable information out there... if only you can see it!

Monday, 30 June 2008

Soekris net4801 as Nagios powered network monitor

Some time ago (rather long long time ago) we have decided to purchase some small device to turn it into very portable server, that we could send to one of our friends to host. The whole purpose was to get Nagios on it and to monitor our sites from outside of our networks. To some people it may sound crazy, but it makes kind of sense - how many times you have heard from someone "it works on my computer"? Too many times?

The goal is to know when my (and possibly why) visitors/customers can't reach my servers and to be able to diagnose if that is local to some location or network part or it affects wider audience. Up to some point remote sensor answers that question - at least from a perspective of his particular location.

After looking around the net we've decided to get one of those famous Soekris kits.


Was it a good choice as a hardware platform? How will it scale when the amount of monitored systems will reach certain level? Let's see where it got us so far as the system is live for about a year now.