Search This Blog

Wednesday 27 February 2013

Ubuntu, Minicom & Cisco

Install Minicom

Find the name of your serial port
Next, you need to find out is which device your serial (including the USB adapter) ports are mapped to. The easiest way to do this is to connect the console cable to a running Cisco device. Now open up a Terminal using "Applications > Accessories > Terminal" and type this command:

dmesg | grep tty

The output will look something like one of these:

[    0.788856] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    0.789144] 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[94023.461242] usb 2-1: pl2303 converter now attached to ttyUSB0
[107561.131086] type=1503 audit(1260922689.994:33): operation="open" pid=27195 parent=27185 profile="/usr/sbin/cupsd" requested_mask="w::" denied_mask="w::" fsuid=0 ouid=0 name="/dev/ttyUSB0

Look in this output for words that contain "tty". In this case, it is "ttyS0". That means the name of the device that corresponds to your serial port is "ttyS0". The name of your device that corresponds to your USB port has a definition of name="/dev/ttyUSB0" (make sure it's plugged in). Now we are ready to configure Minicom to use this information.

Configure Minicom

Open a terminal using "Applications > Accessories > Terminal". Now type this command to enter the configuration menu of Minicom:

sudo minicom -s

Use the keyboard arrow keys to select the menu item labeled "Serial Port Setup" and then hit "Enter". Here is what I had to change:

Change the line speed (press E) & change to "9600"

Change the hardware flow control (press F) & change to "No"

Change the serial device (press A) & change to "/dev/ttyS0"

Or to use your USB port, change the serial device to "/dev/ttyUSB0"

Be sure to use the device name that you learned with the grep output.
Once your screen looks like mine, you can hit "Escape" to go back to the main menu. Next, you need to select "Save setup as dfl" and hit "Enter" to save these settings to the default profile. Then select "Exit Minicom" to exit Minicom...

To find out if you have configured Minicom correctly, type this command in the terminal:

sudo minicom

After entering your sudo user password, you should be connected to your Cisco device.

Once inside, press Ctrl+A, to access minicom commands. Press 'Ctrl+A', then 'Z' to access help. Ctrl-A, then another letter, like 'X' & you will eXit. Help will show a list of available commands.

JIRA Jelly script - Transition to Closed

Over the past year or so I've become a big fan of Atlassians JIRA. I've managed to frig around and get a pretty neat ticket/request solution in place for my company but in doing so I've also become the defacto goto person.

A new project needed to just receive emails, create an issue and then close it. Steps 1 & 2 are simple with IMAP & Mail listeners. But I wasn't aware of a way to carry out 3.

Enter stage left Jelly Scripts. Scripting language supported within JIRA. Turned out to be rather simple and a couple of hours work turned out :

<!-- This script will parse all tickets matching "${filterNum}" and transition them to Closed state. -->
<!-- Paul Regan 27/2/2013 (Thats a UK Date people !) -->
<JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.enterprise.JiraTagLib" xmlns:core="jelly:core" xmlns:log="jelly:log">
<!-- Login as automation user  -->
      <jira:Login username="<jira-user>" password="<password>">

<!-- Set Some variables  -->
      <!-- 2 = Close Issue Transition (NB//TRANSITION NOT STATUS).  Can be seen on the transition URL -->
      <core:set var="workflowStep" value="2" />
      <core:set var="workflowUser" value="<jira-user>" />
      <core:set var="comment" value="This topic has been closed by jelly script automation" />
      <!-- Run the SearchRequestFilter Against a filer.  15231 = All Tickets -1 Day or 15232 = All Open Tickets-->
      <!--The numeric comes from the filters URL -->
      <core:set var="filterNum" value="15232" />
      
<!--Run the search using filter defined above -->
<jira:RunSearchRequest filterid="${filterNum}" var="issues" />

<!-- Build array of issues matching filter & run through it -->
      <core:forEach var="issue" items="${issues}">
      <!-- Log updates are written to /opt/atlassian/jira/data/log/atlassian-jira.log. -->
                <log:warn>Closing issue ${issue.key}</log:warn>
                <jira:TransitionWorkflow key="${issue.key}" user="${workflowUser}" workflowAction="${workflowStep}" comment="${comment}"/>
                
                <!-- Useful debugging aid.  Remark the actions and just use this to write a comment in results -->
                <!-- <jira:AddComment comment="This would be closed" issue-key="${issue.key}"/> -->
                <!-- Useful debugging aid.  Remark the actions and just use this to display results -->
                <!-- ${issue.key} -->

      </core:forEach>
      </jira:Login>
</JiraJelly>



Sunday 24 February 2013

Raspberry PI & OpenVPN


The majority of these instructions come from : blog.remibergsma.com and have been reproduced with kind permission.

Like most things with Linux my working solution was actually a culmination of information from various places.

sudo apt-get install openvpn

After the install finishes, you need to generate keys for the server and the client(s). OpenVPN ships with the ‘easy-rsa’ tool. It’s easiest to copy the example folder and work from there.

sudo cp -R /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn
cd /etc/openvpn
sudo chown -R pi:pi *
cd /etc/openvpn/easy-rsa/2.0

The ‘easy-rsa’-tool has a file called ‘vars’ that you can edit to set some defaults. That will save you time later on but it’s not required to do so.

Load the vars like this (note the two dots):

. ./vars
(dot space dot/vars)

Generate the keys:

./clean-all
./build-ca
./build-key-server <server>
./build-key <client-name>
./build-dh

The first line makes sure we start from scratch. The second generates a key for the Certificate Authority. The key for the server itself is generated on the third line. Repeat the forth line for each client that needs to connect. Finally, we need the Diffie Hellman key as well, which is generated on the fifth line and will take a few mins to complete.

Copy the keys to the OpenVPN folder.

sudo cp ca.crt ca.key dh1024.pem <server>.crt <server>.key /etc/openvpn

Last step is to configure the server. You can copy the example config and make sure it points to the certs you just created.

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn
sudo gunzip /etc/openvpn/server.conf.gz
sudo nano /etc/openvpn/server.conf


Change any settings (dchp scope, OpenVPN port etc) that are particular to your install in server.conf

When you’re done, start OpenVPN like this:

sudo /etc/init.d/openvpn start

The first time I started OpenVPN it failed with :


/etc/var/log/syslog
<snip>
raspberrypi ovpn-server[22119]: OpenVPN 2.2.1 arm-linux-gnueabihf [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Apr 28 2012
raspberrypi ovpn-server[22119]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
raspberrypi ovpn-server[22119]: Diffie-Hellman initialized with 1024 bit key
raspberrypi ovpn-server[22119]: TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
raspberrypi ovpn-server[22119]: Socket Buffers: R=[163840->131072] S=[163840->131072]
raspberrypi ovpn-server[22119]: ROUTE default_gateway=192.168.99.1
raspberrypi ovpn-server[22119]: Note: Cannot open TUN/TAP dev /dev/net/tun: No such device (errno=19)
raspberrypi ovpn-server[22119]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
raspberrypi ovpn-server[22119]: /sbin/ifconfig 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
raspberrypi ovpn-server[22119]: Linux ifconfig failed: external program exited with error status: 1
raspberrypi ovpn-server[22119]: Exiting
</snip>

Another VPN app I have which also uses /dev/net/tun failed with the same error.  Reboot fixed this and so far its not come back.

Check the state of the TUN0 interface

ifconfig tun0

All being well you’ll see:

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
 inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
 RX packets:49 errors:0 dropped:0 overruns:0 frame:0
 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:100
 RX bytes:3772 (3.6 KiB) TX bytes:1212 (1.1 KiB)

You should now be able to connect to the OpenVPN server with a client. Which ever client you choose you will need the client.crt, client.key and ca.crt files plus the ip-address of your Raspberry Pi.

I chose TunnelBlick which after a rather convoluted profile setup seems to work well on OSX 10.8.2 (ML)

Have a look at ‘/var/log/syslog’ to access the logfiles. You’d be able to see which client connects:


Jan 5 22:07:56 raspberrypi ovpn-server[14459]: 1.2.3.4:64805 [client-name] Peer Connection Initiated with [AF_INET]1.2.3.4:64805

From the VPN client check that you can ping the LAN IP address of your RPi, assuming that works then you just need to push some routes around and you should be set.

VPN Client----VPN Subnet---RPI---LAN Subnet

To enable traffic from the VPN network to your local subnet you will need routes on each end to tell devices how and where to send traffic. To enable this on the VPN site :

sudo nano /etc/openvpn/server.conf

Find the push routes section and add a 'push route' statement which reflects your local network address.

You will also need to add a route back to the VPN Subnet, probably by adding a static route to your internet edge device.

Finally, enable routing on the Rasperry Pi:

There are a couple of ways suggested for this but what worked for me :

sudo nano /etc/sysctl.conf
uncomment : net.ipv4.ip_formward=1

Reboot your device.  You should now be able to connect to the VPN and ping other devices on your local network and vice-a-versa to VPN clients.

Saturday 23 February 2013

Foscam F19821W & Apache Reverse Proxy

Finding myself with a few redundant Foscam F19821W cameras in my possession I thought I'd set them up around the house.

Getting them working with the browser plugin was relatively painless and gave live view and everything you'd expect from the manufactures app.

The next logical step was to access to them from anywhere.  The cameras come with UPnP and a DDNS setup.  No, don't want that, I want control of what comes in and out.

The installed firmware only allowed H.264 streams. An update to 1.1.1.10 and running :

http://<camera_ip>:<port>/cgi-bin/CGIProxy.fcgi?usr=<user>&pwd=<password>&cmd=setSubStreamFormat&format=1

Which enables a MJPEG stream which you can consume using a browser or something like VLC:

http://<camera_ip>:<port>/cgi-bin/CGIStream.cgi?cmd=GetMJStream&usr=<user>&pwd=<password>

I now have a couple of options to make these available outside.
  1. Port forwarding each Foscam port on my internet router. << Easy
  2. Reverse proxy. << Not so easy
Of course I wanted the not so easy and a single place to control and distribute access.  I don't like the idea of exposing the cameras directly.

Reverse proxy consisted of using my goto device Raspberry Pi and Apache.  Took a while to get the config nailed.

I'm not going to go into the entire Apache setup but I chose to create a virtual host :


 <VirtualHost *:80>
 ServerAdmin 
 ServerName <host>.<domain>
 ProxyRequests Off
 ProxyVia Off
 RewriteEngine On
 
 <Proxy *>
  Order deny,allow
  Allow from all
 </Proxy>
 # Used for iFrames
 ProxyPass /foscam1/ http://<camera_ip>:<port>/
 ProxyPassReverse /foscam1/ http://<camera_ip>:<port>/

 DocumentRoot /var/www/foscam
 <Directory /var/www/foscam>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 #Rules to rewrite camera urls
 RewriteEngine On
 RewriteRule ^cgi-bin/(.*)$ /camera1/cgi-bin/$1 [L]
 RewriteRule ^css/(.*)$ /camera1/css/$1 [L]
 RewriteRule ^images/(.*)$ /camera1/images/$1 [L]
 RewriteRule ^lg/(.*)$ /camera1/lg/$1 [L]
 </Directory>

# ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
# <Directory "/usr/lib/cgi-bin">
#  AllowOverride None
#  Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
#  Order allow,deny
#  Allow from all
# </Directory>
  
 ErrorLog ${APACHE_LOG_DIR}/home-error.log
 CustomLog ${APACHE_LOG_DIR}/home-access.log combined
</VirtualHost>

Hit your public IP with the /foscam1/ URI and it will redirect to your camera.  You can consume the MJPEG stream and get to the management app, but no live view due to the way Foscams plugin works with the cameras media port.

Alternatively build a simple html page with iFrames that Apache will serve each camera stream, which is what I did.  Its also a good idea to wrap some Apache authentication around this and if you have the option use DDNS to clean up the URL if your on a DHCP internet link.

I don't yet know if I'll leave it this way.  I doubt Foscam have a particularly robust security ethos and after this weeks amazing amount of hacks its only a matter of time before a vuln is found.  OpenVPN is next on the agenda so I may put all this behind that.

Friday 8 February 2013

Raspberry PI Wireless WPA-Enterprise

From my previous post the hardware was working fine and I'd already had the RPI connecting to my home WPA2 networks.

Finding a working WPA2-Enterprise config was painful exercise in trial and error.
Using :

sudo wpa_supplicant -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf -Dwext -dd -s

-dd = Double debug
-s = Will send the output to /var/log/syslog

Final WPA-Enterprise WPA Supplicant configuration

cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
ctrl_interface_group=root
update_config=1
ap_scan=1

network={
 ssid="<ssid>"
 scan_ssid=1
 key_mgmt=WPA-EAP
 pairwise=CCMP TKIP
 group=CCMP TKIP
 eap=PEAP
 identity="<uid>"
 password="<password>"
 phase1="peapver=1"
 phase2="MSCHAPV2"
 pac_file="/etc/wpa_supplicant/pac"
}

Hint : If you have both ETH0 and WLAN0 enabled and cabled then ETH0 will connect first so the routing table will reflect its default gateway.  If each interface is on a different subnet then you will have issues with connectivity if you unplug ETH0 - the default route goes away.

Raspberry PI Wireless WLAN0 won't work without ETH0

There are plenty of other sites documenting how to initially configure wireless so I'm not going to repeat them.  This is specifically about a weird issue I had configuring the card for home.

No hardware issues, the latest Raspian build found the Edimax USB card with no issues.  My problem was the wlan0 interface would not work without eth0 also being active.

Further investigation led me to find the MAC address both the wlan0 & eth0 IP responded from was in fact the eth0 address.

Now this goes against everything I understand but in my case with the RPI ethernet cable plugged in:

Take note of the HWaddr on each card.


$ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:b0:0c:39  
          inet addr:192.168.99.75  Bcast:192.168.99.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1


wlan0     Link encap:Ethernet  HWaddr 80:1f:02:82:33:24  
          inet addr:192.168.99.78  Bcast:192.168.99.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1


Then from another workstation, in this case I'm using NMAP:

$ sudo nmap -sn 192.168.99.75  **<< - ETH0**

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-03 10:19 GMT
Nmap scan report for 192.168.99.75
Host is up (0.020s latency).
MAC Address: B8:27:EB:B0:0C:39 (Raspberry Pi Foundation)
Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
Paul@lo-mbp-preg / $ sudo nmap -sn 192.168.99.78

$ sudo nmap -sn 192.168.99.78  **<< - WLAN0**

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-03 10:19 GMT
Nmap scan report for 192.168.99.78
Host is up (0.0044s latency).
MAC Address: B8:27:EB:B0:0C:39 (Raspberry Pi Foundation)
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds


You can see that the MAC Address/HWAddr for both ETH0 and WLAN0 is the same, and matches the ETH0 HWAddr from ifconfig.  So in my case the Wireless was not working and all traffic was passing via ETH0

I never actually found 'the reason' for this.  In the process of debugging it started working reliably.  Which I hate.  But this config is now working :

**/etc/network/interfaces**

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

**/etc/wpa_supplicant/wpa_supplicant.conf**

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
ctrl_interface_group=root
update_config=1
ap_scan=1

network={
 ssid="<ssid>"
 psk=<key>
}
network={
 ssid="<ssid>"
 scan_ssid=1
 key_mgmt=WPA-EAP
 pairwise=CCMP TKIP
 group=CCMP TKIP
 eap=PEAP
 identity="<uid>"
 password="<password>"
 #ca_cert="/etc/cert/ca.pem"
 phase1="peapver=1"
 #phase1="fast_provisioning=1"
 phase2="MSCHAPV2"
 pac_file="/etc/wpa_supplicant/pac"
}

Raspberry PI, Video & Audio Streaming

Requirements :
Using my PI seemed a logical solution = small.  Attach a PowerGen external pack = Portable.  I'm already making progress!

Streaming has been tougher, 4-5 days of tough.  Seemed to settle immediately on VLC and started by using the Windows GUI to build out the command line options.  I ended up with a network stream that VLC client could open.
vlc --qt-start-minimized dshow:// :dshow-vdev="QuickCam Orbit/Sphere AF" :dshow-adev="Microphone (2- Orbit/Sphere AF)" :dshow-size="640x480" :live-caching="300" --sout="#transcode{vcodec=h264,vb=0,scale=0,acodec=mp4a,ab=128,channels=2,samplerate=44100}:http{mux=ffmpeg{mux=flv},dst=:8888/}"
Figured the next step was to reproduce this on Ubuntu before trying the Wheezy in case there was anything odd about the distro.  Ubuntu build resulted in :
cvlc "v4l2://" --v4l2-width=420 --v4l2-height=320 --input-slave=alsa:// --sout '#transcode{vcodec=WMV2,vb=256,acodec=wma2}:standard{access=http,dst=8080/,mux=asf}'
Adding the Mediabuntu repository allowed me to use h264 but the video was awful.

Getting this working involved a great deal of trial and error to find video and audio codecs that worked.

RaspberryPI

Expected to be able to use the same Ubuntu command.  #fail

Again, a lot of trial and error resulted in.
cvlc 'v4l2:///dev/video0:chroma=mjpg' --v4l2-width=420 --v4l2-height=320 --input-slave=alsa://hw:1,0 --alsa-audio-channels=1 --volume=1024 --sout '#standard{access=http,mux=ogg,dst=:8888/stream.ogv}' --sout-http-mime=video/ogg
Big difference here is I stopped transcoding and switched to using the M-JPEG stream from the camera.  as the CPU just wasn't up to transcoding, >90% CPU.

Initially the audio stream volume was very low.  --volume=1024 helped but the actual fix was to use alsamix.

 ./alsamixer
- Change to Cam
- F4 change to capture
- Was set to 0 .. raised to 50

Getting this working in a browser is still a WIP.  The camera outputs:

Video : MJPG
Audio : PCM S16 LE (ARAW)

From what I can tell theres no way to view a MJPG stream in a browser.  Tried various things, including wrapping it all in a HTML5 <video></video> tag with some Apache proxy statements.  Setting mime type (which I left on the working command above).

I have some h264 cameras coming so will see how that works out.

Some useful links that got me this far :
http://www.phillips321.co.uk/2012/11/05/raspberrypi-webcam-mjpg-stream-cctv/
https://www.adafruit.com/blog/2012/11/02/pieye-streaming-webcam-piday-raspberrypi-raspberry_pi/
https://forum.videolan.org/viewtopic.php?f=13&t=74077&start=0
http://stackoverflow.com/questions/7917905/how-to-use-vlc-live-streams-with-html5-video