Fedora 18 Compile Moxa Beta Device Driver

Down below is a guide for Ubuntu Linux.  Here is the same thing for Fedora Linux.

The serial interface device drivers on the Moxa web site may not work with the latest Linux kernels.

Send an email message to "support at moxa dot com" and ask for a Beta device driver for Linux for your Moxa device model number.  You should get an answer within a few hours.

First update the system

# yum update

or use yum extender GUI.

The above will typically install about 50 to 100 Megabytes of updates and will take a while.

Install the software development tools

# yum install kernel-headers

# yum groupinstall "Development Tools" "Development Libraries"

Make a directory to work in

$ cd

$ mkdir Moxa-Beta

$ cd Moxa-Beta

Save the tar ball there and untar it:

$ tar -zxvf driv_linux_uport_v1.2.5_build_13040314.tgz

$ cd mxuport

Make the driver

$ make driver_make

...and you should see this scary message:

************************************************************************

Fedora release 18 (Spherical Cow) 3.8.1-201.fc18.x86_64

MOXA UPort 1200/1400/1600 series driver ver 1.2.5

Release Date: 2013/04/03

************************************************************************

**********************************WARNING*******************************

MOXA UPort 1200/1400/1600 series driver may not be compatible with

Linux kernel versions newer than 3.7.10 .

To download the latest driver, please visit Moxa at: http://www.moxa.com

If you have questions, please contact Moxa support at: support at moxa dot com

************************************************************************

Install the driver

If and only if there are no errors above, set user to root and:

# make install

...and you should see this scary message:

************************************************************************

Fedora release 18 (Spherical Cow) 3.8.1-201.fc18.x86_64

MOXA UPort 1200/1400/1600 series driver ver 1.2.5

Release Date: 2013/04/03

************************************************************************

**********************************WARNING*******************************

MOXA UPort 1200/1400/1600 series driver may not be compatible with

Linux kernel versions newer than 3.7.10 .

To download the latest driver, please visit Moxa at: http://www.moxa.com

If you have questions, please contact Moxa support at: support at moxa dot com

************************************************************************

************************************************************************

MOXA UPort 1200/1400/1600 series driver ver 1.2.5 installed successfully.

************************************************************************

Plug it in and set it up

Now, when you plug the Moxa U1250 in, it should show up in /dev as ttyMXUSB0 and ttyMXUSB1.

Configure the device for RS232:

# setserial /dev/ttyMXUSB0 port 0x0

or for RS422:

# setserial /dev/ttyMXUSB0 port 0x2

and for RS485 2-wire:

# setserial /dev/ttyMXUSB0 port 0x1

It is all explained in the readme.txt file and I recommend you use it with Cutecom.

Problems with Low Latency extensions

I compiled the above on a virtual machine and it all went swimmingly.  However, when I tried to compile it on a real machine which has a real serial port, it failed due to a missing 'low-latency' record in 'struct tty_struct' in file mx-uport.c

Eventually, I fixed it by commenting out the offending flag operations in lines 1565, 1567, 2956 and 408.  However, I am not sure whether it works yet.  It now compiles, but I have not had time to test it.

Security Paranoia

The hullabaloo around the world-wide, blanket NSA phone, chat and email logging of the last few weeks has been a boon for computer security, since it made everyone think about it.  OK, not quite everyone, but hopefully every computer geek thought at least a little bit about security!
http://www.guardian.co.uk/world/the-nsa-files

The whole sorry mess is turning into a modern day enactment of Franz Kafka's Der Prozess (The Trial), where a man is tried by a secret court with a secret charge and eventually executed, without him or anybody else being any the wiser about what it was that he supposedly did wrong.

Of course, all serious computer security professionals knew about all the spy-vs-spy stuff all along, but convincing Joe Public, or just a normal middle manager, that you are not a crazy paranoid deluded fool, is very difficult.  The current spate of news articles and government fancy footwork, denials, retractions and debate, now makes it a lot easier to talk about computer security and some people will actually listen too.

In order to ensure computer security, you should be somewhat paranoid.  You got to assume that every data byte you send out on the internet is recorded by at least five different three letter agencies (and criminal syndicates) the world over.  You should think of every angle and you should not make any assumptions about security, but rather attempt to verify and test everything.
 
The practical problem is how - how can one person, or a small team, possibly test and verify everything in a computer net?

Co-operation With Security Agencies

It is in the interest of all technology companies to work closely with their local security agencies.  That is the right thing to do.

Years ago, I worked at a small phone company that manufactured VoIP equipment and one day we received a visit from a friendly man in black, who asked us to add a backdoor to our equipment and of course we did.  We did exactly what was asked.  It was the right thing to do.

The problem is what you as a small company IT Geek should do to ensure security in your organization, given that your equipment is sourced from all over the world and therefore full of back doors leading to various security agencies and others that are not loyal to your country?

NSA Keys

The open co-operation between Microsoft and the NSA goes back to Windows 1995 and very likely long before:
http://www.heise.de/tp/artikel/5/5263/1.html
http://edition.cnn.com/TECH/computing/9909/03/windows.nsa.02/

The NSA key could potentially be used to subvert the security of any Windows 95 and Windows NT user.

It appears that nowadays the NSA is a little more subtle.

NSA Stuxnet

The Stuxnet worm released in 2010, was aimed at the Iranian uranium enrichment program and used long term security flaws in MS Windows to damage uranium hexafluoride centrifuges:
http://spectrum.ieee.org/telecom/security/the-real-story-of-stuxnet
https://www.symantec.com/security_response/writeup.jsp?docid=2010-071400-3123-99

The current thinking is that Microsoft deliberately delayed certain security fixes in order to assist with the Stuxnet deployment.  Microsoft is an American company and obviously it was in their interest to do so and one could argue that it was in the interest of pretty much everybody on the planet.

Microsoft is infamous for its slow reaction to security flaws:
http://news.bbc.co.uk/2/hi/technology/4907588.stm
http://www.zdnet.com/google-security-flaws-not-fixed-in-a-week-should-be-made-public-7000016124/

The problem with a delayed response to security issues, is that as soon as someone was exploited, he may investigate and then use that exploit against others.  It would be very naive to assume that only the 'good guys' will know about these flaws.

Microsoft Internet Explorer is also famous for being the only web browser program repeatedly warned against by multiple government agencies:
https://www.kb.cert.org/vuls/id/713878
http://www.softwaretop100.org/german-and-french-governments-advise-against-using-ie

Of course, Microsoft is not the only evildoer in this game.  Sony is unique in that it raised the ire of every government on the planet in 2005 with their well meaning, but totally misguided and easily exploited root-kit fiasco:
https://www.eff.org/press/archives/2005/11/09
http://www.pcworld.com/article/125838/article.html

Cross Purposes

There is an ancient proverb attributed to both Sun Tsu and Arabian philosophers: "The enemy of my enemy is my friend".

Free and Open software including Linux and BSD are used by military organizations the world over.  Many of these organizations have virtually unlimited funding and are serious contributors to the Linux kernel development and they would be at constant logger heads with each other, if each would try to subvert the system for their own exclusive good.

In contrast, Microsoft is said to favour the NSA with early bug reports:
https://www.techdirt.com/articles/20130614/02110223467/microsoft-said-to-give-zero-day-exploits-to-us-government-before-it-patches-them.shtml

The Linux and BSD development processes are wide open, and bug report databases are available to everybody, not just to a select few, which levels the playing field:
https://bugzilla.redhat.com/index.cgi
http://www.debian.org/Bugs/

Essentially, the various contributors to Linux and BSD have to play ball, or go home and it is this openness of the development cycle, more than anything else, that ensures a high level of trust in Free and Open software.

Get Started on the Right path

So this is the answer: Employ Linux and BSD systems wherever possible in your organization, especially at key choke points in the network and benefit from the multitude of security audits performed by government users the world over.

You have to run your own computer network penetration and information leakage tests too, but you got to start with a Free and Open system that is designed to be secure, otherwise you would put yourself at a terrible and unnecessary disadvantage.

Also, do use a password manager, such as KeepassX, to enable you to use different passwords for everything. If you are paranoid about password managers, see this: http://www.ssi.gouv.fr/fr/produits-et-prestataires/produits-certifies-cspn/certificat_cspn_2010_07.html

IT Security Guidance

Any organization has limited resources and the key to avoid squandering those resources on the wrong solutions, is the Threat Risk Assessment:
http://www.cse-cst.gc.ca/its-sti/publications/tra-emr/

Once you have done the above groundwork, then you can start to think of a plan to secure your system, but not before.

More valuable guidance is available here:
http://www.cse-cst.gc.ca/its-sti/publications/index-eng.html

Now go and fix your computer network!

4WD Rover

Flying a model plane in the desert is difficult.  There is sand laden wind during the day, so one can only fly at night and then one cannot see the plane properly.  So I decided to make a little runabout.

A runabout robot uses much the same parts as a plane.  An aircraft RC system is used for backup and test and the autopilot is the same, just with a different ArduRover software load. Details here http://rover.ardupilot.com/

Where to get the parts

Pololu.com sells a range of motor speed controllers with various control inputs.  The Easy series has linear, digital and RC control inputs.  It can also blend two RC channels for differential control.  This way, one can make a 4WD robot chassis, using the Throttle channel for speed control and the Rudder channel for direction.  The blending will add or subtract the two channels such that the left/right will speed up or slow down the one side slightly, to make the model turn.

I picked the 18V 15A speed controller http://www.pololu.com/catalog/product/1376

Pololu also has geared motors and wheels to match http://www.pololu.com/catalog/category/51

So, I picked up a wood bread board at Carrefour, epoxy glued four geared motors with 50 by 120mm wheels to it and la voila, a 4WD Rover!

The advantage of using a wood bread board as the base, is that one can easily screw and glue things to it.  A metal chassis is much more difficult to work with and costs a whole lot more.

Here is the Schematic of the RC motor control - to test and configure the speed controllers before the autopilot is added to the mix.

Ultimately, I want to add a short range proximity sensor on each corner to protect the wheels and avoid banging into things, as well as a camera and range finder on a pan/tilt swivel for distant obstacle/object detection.  Jameco.com sells a range of pan/tilt swivels and robot grippers, that will be handy for this project http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_2144518_-1

Video

To process video/stills, one would need OpenCV, which is beyond the capability of an Arduino auto pilot.  A Texas Instruments Beaglebone Black running at 1 GHz (or an old netbook computer) may be a better platform for that, so ultimately I can see the Arduino going out the window http://beagleboard.org/Products/BeagleBone%20Black

Motor Control

The Pololu motor controller user guide is here http://www.pololu.com/docs/pdf/0J44/simple_motor_controllers.pdf

In the guide on pages 15 and 16 it explains where to get the software required to configure the motor controllers.  The default configuration is for analogue inputs, which means that the speed controllers won't work by default - you have to configure them.

The software is available from here http://www.pololu.com/file/download/smc-windows-121204.zip

I tried the Linux version first, but it requires some non-existent libraries, so then I tried Windows on Virtualbox on my Mac and then found that I cannot yield control of the USB port to Windows since something in the Mac grabs control of it.  Therefore, I dug out my old Linux netbook and installed the Windows software all over again on XP.  This time it worked.

Clicking around a bit, I found the RC settings and configured the one controller as Mix Left and the other as Mix Right.  I also disabled the 'motor safe start' since I am not sure how it will work in practise and I don't want to ever run this program again just to reset the controllers.

When testing motors, put the machine on a couple of Sparkfun component boxes, to keep it from running away.

Test run

Once I got the controllers configured for RC, I gave things a try and the magic smoke didn't escape, but the controls were 90 degrees out, so I had to swap channels 3 and 4 around.

Overall, this seems to be a good rover platform that can zoom around at a decent walking speed.