Playing Music Over The Network

**Disclaimer**: Don’t try this at home

Sometimes, the best solution isn’t the prettiest.

Sometimes, your server with a few hundred gigs of music is downstairs tucked away in your amazing wireless closet, but you spend most of your life upstairs on your comfiest of couches. Also, living with 5 others, it would be nice to allow your roommates some degree of control over the music.

Our first semi-serious attempt at solving the music-upstairs problem involved an asus eeepc running xmbc with our music hosted on mediatomb upnp shares but we weren’t happy. We decided for practicality reasons we wanted the music to play on the server downstairs, but have the audio play upstairs. However, we weren’t about to mess with the wiring, so we decided on something else…

Piping audio over ssh to a remote machine

while true; do
	cat /tmp/probedsp
done | ssh dsl@probe sox -t raw -r 48000 -w -s -c 2 - -t ossdsp /dev/dsp

That monstrocity is courtesy of John Hawthorn. We’ve had this running almost a month now, and I’m still not sure if its the greatest thing I’ve ever seen, or the most likely to secure us all a place in software hell.

With great power comes great responsibility. We took that responsibility and piped it over ssh through our wireless network 24/7, sucking up more cpu cycles and bandwith a day than every maching running in 1975.

What that command does (at least as far as I can tell…) is pipe the local audio output over ssh to SoX on the remote machine. We’ve set up mpd to output to our fifo (/tmp/probedsp) which gets sent to probe to be played.

Probe itself is a Fujitsu Stylistic LT C-500 touchscreen I picked up on Used Victoria for $50 and threw Damn Small Linux onto.

When its all said and done, we can control mpd running on our server downstairs, and the audio is played on the tablet upstairs.

Remote Volume Control

To control audio volume, we set up something equally horrifying:

while true
do
	netcat -l -p 1666 | xargs umix
done

That sits netcat on port 1666 looking for arguements to send to probe’s mixing program, umix. We can netcat from a local box or open and write to a socket on port 1666 to control the volume…

The dlink Dir-655 hash changes…

I mentioned in a previous post I needed to programatically log into my Dlink DIR-655 router and grabbed the computed password off of a submit.

Well it turns out the salt changes periodically (maybe every reset?) and just storing the hash wasn’t enough. I ended up writing a bit of ruby to recreate the javascript hashing function

require 'digest/md5'
require 'nokogiri'

router_path = "http://#{router[:ip]}"
x = agent.get(router_path)
salt = x.body.match(/salt = "(.*)"/)[1]

# pad the pasword to length 16
pad_size = (16 - router[:password].length)
padded_password = router[:password] + "\x01" * pad_size

# pad it the rest of the way, length 64 for admin
salted_password = salt + padded_password + ("\x01" * (64 - salt.length - padded_password.length))
login_hash = salt + Digest::MD5.hexdigest(salted_password)

login_path = "#{router_path}/post_login.xml?hash=#{login_hash}"

That code can be found on my github as part of Orbital Command.

Orbital Command Network Visualizer

For a long time I’ve wanted a quick way of spitting out the topology of a network into an easy-to-digest image.

I couldn’t find any Open Source network visualizers I liked, so I sat down with John Hawthorn to write one.

We found Sophsec’s nmap-ruby, a nifty ruby library to call nmap and interpret the response. With the results of an nmap scan on the local network, we’d get a pretty good picture of all the hosts.

I sat down with the task of gathering information about the nodes, and how they relate to each other. What is plugged into what, which host is connected to which wireless router, and whatnot.

Unfortunately, for our home network we have a setup of 2 wireless routers behind a box that acts as our default gateway. This means that all of the traffic internally is done through switching and on layer 2, making tracepath and family unsuitable to map out how the nodes are connected.

As I discussed in my previous post about my dir-655, I ended up programatically logging into my routers to grab their list of connected clients through the admin.

Hawthorn called shotgun on the visualization side of things, and decided on Graphviz for a first-generation renderer.

I had to overcome a few annoying problems (about half way through which Hawth washed his hands at the project :p). I wrote a quick ruby gem to spit out interface information since I needed the localhost’s mac address which nmap did not spit out.

If no default gateway is specified in config, it uses a pretty gross parsing of route’s output to figure it out:

(`route -n`.split("\n").last.match /\s[\d\.]+/)[0].strip

When all is said and done, though, I’m pretty happy with how a graph looks, and I’m storing the results of scans of my network as well as the generated images and plan to do some neat things once I’ve acquired enough data :}.

My Home Scan
A sample scan of my home network with orbital_command