Tool Time (No Al Borland)

With the live audio business dragged kicking and screaming into the network age it’s required some tools that weren’t necessary in the analog days. IT wonks have been using these or similar tools for decades. Initially there was no need, scale or standard use in pro audio networking for these sorts of tools. As things became more complex than simple point to point networks the need to use more advanced toolsets became common.

If you have a couple of stage boxes and a couple of consoles you likely won’t need most or any of these tools. They’re primarily used to ensure the network is configured and operating properly. They don’t directly measure or monitor audio itself. On a network everything is a packet. The tools know what they are but not necessarily what they do once assembled. It knows it’s a multicast to specific devices but it can’t tell it’s your killer kick drum sound. It knows to shovel data from to and from the desired location in the time required.

Thanks for reading A Barking Dog! Subscribe for free to receive new posts and support my work.

Before we dive into this I want to comment on computing platforms and the suitability for these sorts of tests. For general network tests you can use Windows, Mac or whatever Linux/*nix you wish ( *nix are various Unix like operating systems like Linux or MacOS). The tools for the devices themselves may be platform specific though a good many have Mac clients as well as the standard Windows clients. There are a few that are Mac only though. In other words don’t get locked into platform wars. That said I prefer using a Mac so this toolset focuses on Mac.

The scope of these tools are to troubleshoot, provision or test the integrity of the network and network equipment not so much the audio equipment. Some pro audio equipment uses the same or similar tools but networking is a thing in and of itself. If you learn the basics of how an IP network operates and how to apply basic troubleshooting skills you’ll be 90% of the way there. A great learning resource is John Huntington’s Introduction to Show Networking.

One of the most basic and useful tools is the browser. Most networking hardware has a browser based interface. It’s easy and effective. In some cases you may need a particular browser or at least an up to date browser as the interface may need to run Java or Javascript. You could be limited to plugging directly into a single network you wish to work on but for most uses that’s likely not an issue. Many if not most live sound use cases don’t have more than one network. In a complex environment you’d use a VLAN as a control network so all the switch IP addresses were accessible from any point on the network. It’s likely you’ll only be configuring switches and wireless access points with applications where browser based management is universal. Depending on your use case it may be all you need to manage your equipment. For troubleshooting interconnectivity issues or integrity issues you’ll need additional tools.

There are occasions where you need to see what is on your network. Or more precisely is everything on your net that should be. I use LanScan Pro. It’s Mac only but there are others, for example Angry Ip Scanner, that run on Windows. There is also a command line app called nmap. Nmap has been around since I first started using Unix. A word of caution before scanning a network not under your control. Many sysadmins monitor network scanning to keep out the black hats. If you’re using an existing corporate network they may flag or block you for scanning.

Ping is another app that is universal. It’s usually the first tool to confirm something is on the network and responding. A rule of thumb is if you can’t ping it it’s not available on the current subnet (though some devices don’t respond to pings). It gives you a place to start. If I can’t get a ping next call is to scan the network.

As far as terminal software I like iTerm2. It’s the same command line terminal as the stock MacOS terminal.app with added features and flexibility. Unless you want to geek out on the terminal the stock app is fine. Using command line tools is one area where Windows is different than a *nix type platform like Mac or Linux. Until recently it was more difficult to get these sorts of command line apps on Windows. Thanks to the Windows Power Shell, GCC and various GNU libraries Windows can run most POSIX/*nix style apps from the command line. There are several third party terminal apps for both Mac and Windows but for many tasks the stock terminal on either platform is fine.

There is a learning curve to using the command line but I find it faster and more flexible. If you aren’t experienced (or even if you are) there is nothing wrong with using a tool with a graphic interface. In fact many GUIs are overlays for a *nix tool set. The goal here is not to prove you’re some 1337 h4X0r but to get information that will help you troubleshoot and manage your network. Use the tools with which you feel most comfortable and useful.

Sometimes there is no substitute for a good ol’ fashion serial console. At one point serial access/control of audio gear was normal as well as simply getting online. Those days are long gone to the point where new techs may not be familiar with the protocol. Or the DTMF of your Hayes 300 baud modem negotiating a connection. It’s used these days as a ring tone that says “I’m old”, uber geeky or both. Serial connections to pro level networking equipment have been around for a while. These days it’s migrated down to the small business or semi pro lines of gear. Some equipment still uses DB9 connectors but a great deal of enterprise/data center grade equipment use an RJ45. In either case it’s usually labeled “console”.

While you can use a terminal as a serial console I prefer an app called Serial. It takes fuss and muss out of using a terminal as a serial console in a direct, easy to use package. Using the console I can more easily see the device status as well as create and deploy backups. The downside is learning curve and referencing the console commands for each brand of switch. While similar they use different syntax. Some like a Luminex don’t offer comprehensive command line access.

For any brand device using the browser (or SSH) you need to make sure you’re on the same network as the device. If you change the device IP you then need to change the address on the computer to validate the proper settings. Under the gun it’s time consuming. On a console connection hit enter a couple of times, your credentials and you’re in. Type a couple of commands to load the backup and a few more to ensure the config loaded and has the appropriate IP address and port config. A fair bit faster than starting from scratch with a browser.

If you’ve got deeper issues inside your network you’ll need a protocol analyzer. For this I use Wireshark. It’s a piece of software that captures traffic as it crosses the network. The learning curve to fully use the power of the tool is steep. To fully understand packet structure is another skill. Fortunately there are plenty of resources from which to learn many of them from the Wireshark Foundation.

The use case in the example above was to reverse engineer a control from a legacy media server. Max/MSP is used as a custom interface for the sound effects operator. The issue was the custom Max object used to interface UDP between the server and client no longer worked due to the Max upgrade. At the time the show was built Max didn’t have a native UDP object hence the now unsupported third party plug in. We didn’t know the exact payload that was returned to the sound effects client. Using the tool we were able determine the structure and adapt the native UDP object in Max.

Another use case was to see if there was a DHCP server on a lan. We had some devices with valid addresses from DHCP but others requesting an address didn’t get anything and renewing a lease on an existing device did nothing. You watch the request go out and see what comes back. This was another net that was installed prior to the pandemic and maintained by a crew that’s no longer here. We were then tasked with figuring out what happened. It wasn’t documented. We didn’t know the scope of the network so we starting looking at raw traffic to get an idea of what was happening. Using the tool we were able to determine what services were being provided to the network, which were lacking and the IP address of an unlabeled computer where we couldn’t look at the config. By looking at the traffic we found what services were provided on the network and restored to ability to request addresses. That network has been redesigned and documented.

This is a tool I found out about a few weeks back. It’s called Packet Sender. It came across my feed at Linked In from Dan Nagle. I haven’t used it on a project only to test drive the package. You can send any variety of messages and get the response. It would have been a more appropriate tool for my Max project above. For example to test for the response I built a small max project to send various UDP streams. The data from the program was coded into the legacy object and I didn’t want to change the program. With Packet Sender it’s an all in one solution. Instead of using Max and Wireshark (which needed a fair amount of filtering so I didn’t get bombarded by broadcast traffic) it would have been one and done. Looks to be a handy tool.

Using a browser, ping and a scanner is likely all you’ll ever need. However when you need to dig deeper you’ll know you have the tools and the ability to solve the issue. You can take small steps to learn at first. There is a ton of info on networking on the internet. Chances are you unless your network(s) have complex configurations or large scale won’t need to get past making sure things have an IP address and they’re configured and connected properly.

Thanks for reading A Barking Dog! Subscribe for free to receive new posts and support my work.