Back after a long time and looking for testers

TimoteusR

Member
I have worked as event tech for the last 10 years and I have been lurking on Control Booth especially in the beginning of my career. I have always liked the vibe here.

Last year I worked a lot with networked audio and switches. To me it seemed that most of the tools were made for IT professionals and were hard to use so I set out to make the situation better.

The basic tasks I did on a daily basis were
* Tracing cabling to see which ports devices were connected to
* Changing switchport VLAN's on switches
* Looking for IP addresses for devices on the network
* Looking at wireshark traces to see why devices weren't communicating with each other
* Finding the web interface for a device
* Changing device settings trough a web interface

In the real world things get complicated once you factor in time pressures, undocumented systems that someone built long time ago and many different users making changes to the network.

I have written a desktop software that allows you to see the devices that are communicating on your network. It will also show which switchport the device is connected to. You can name devices and they are tracked when they are moved between switchports.

There are similar products out there that find devices on the network and show information about them. The problem I see with them is that the user interface is made for IT people and they have many features that are not relevant for the daily task of an audio/light/video tech.

My plan is to release a beta version by the end of this year. Right now I'm looking for people who are interested in testing the current prototypes before the actual beta is launched.

If you are interested, you can request early access here
http://eepurl.com/c1x2Hv

I'm also happy to answer questions you have about this software or networking in general.
 
Here's a screenshot of the current alpha version.

The lighter boxes in the top represent plugins that are reporting their status and the lower darker boxes are the devices found on the network.

Right now I'm focusing on the device view and adding plugins. I have noticed that a good workflow for me is to get a set of features working with a rough ui and after that spend a while to make it usable. For example the plugin status was added based on tester feedback and I haven't yet decided which would be the best way to show it.

Right now it has the following plugins:
- IP Finder (passive plugin): Looks for devices communicating on all of the computers network interfaces and find's their ip address
- Pinger (active plugin): Pings the subnets of all the network interfaces.

I think it is important to have a totally passive mode (receive only). This minimizes the risk of devices crashing on the network. Some devices I have run into don't like to receive valid but unexpected network traffic. But sending traffic to the network allows more devices to be found so there needs to be a compromise.

These plugins form a foundation for other plugins. The next one will probably be a mDNS plugin. Many devices advertise their name, model or manufacturer thru that mechanism. It's the first step towards identifying which protocols devices are communicating.
 
In addition to plugins that are based on generic IP networking there are going to be protocol specific plugins. These will be active plugins that use the protocol's device discovery mechanism to detect devices. This will allow me to a) Display which devices use these protocols b) Show protocol specific names for the devices.

I have initial versions for HiQnet and Artnet ready that I just need to test a little bit more and then add to the software.

With RDM it would be possible to not just detect the device but actually show lot's of information about it. Do you have some specific information that you would like to get from devices thru RDM?
 
The reason I asked because there is a fine line with showing information that is not relevant for the person using the software. RDM could be very useful for getting the device model and manufacturer.

I can also see some value in showing some technical information about the device like lamp hours and temperature. But these are features that would probably be relevant when a v2 is released. Right now I'm focusing on building a solid system for finding the devices.
 
Absolutely.

You can do that by listening for ARP-reply packets, which are broadcast and will make it through the switch to you. Probably also DHCP accept packets, though both of these are "build over time" methods; other than that, you can just ping every address on the relevant network -- while that's a little buzzy, I don't know of anything that a standard 56 byte ping will blow up.
 
The IP Finder plugin actually listens to ARP packets already.

IP Finder currently has a small bug related to DHCPDISCOVER and DHCPREQUEST packets. They are sent with a ip address of 0.0.0.0 and currently IP Finder shows the 0.0.0.0 address for the device when in fact it probably should not as it really doesn't provide useful information.

It might be useful to have it analyze the packet further and show that this device is asking for an ip address thru DHCP. It probably could also show which devices are acting as DHCP servers based on DHCPOFFER packets.

To me it seems the hardest part in finding devices is when the device is already powered on, it doesn't send anything to the network and it doesn't respond to pings. I have a cheap Artnet node that does exactly this. The only way to find it is by sending ArtPoll packets to which the node replies.

There is a tradeoff associated with active plugins between finding devices and being sure that nothing breaks.

Two key values I have for this product are
1. Don't cause harm
2. Don't display wrong information

Passive listening should not break anything. Listening to traffic on the switch trunk ports of a big system? Not a problem. It could be even further isolated by disabling sending packets at all. But this will not find all the devices, for example my Artnet node. There is no way to find it passively as it does not send anything or respond to other protocols than Artnet.

This brings us to active plugins that send data to the network to try and find devices.

Pinging should be fine. Sending ArtPoll packets Artnet devices should also be fine. However sending ArtPoll packets to a mixer starts getting into a grey area. As we don't know which protocols devices are using we have to try multiple discovery mechanisms to get a response from them.

For actual protocol data it should not be a problem as the protocols use different ports. But the discovery packets are usually broadcast so devices will receive them. This could be mitigated by trying to guess the device type by mac address manufacturer or previously discovered information. For example if the device did not respond to protocols x and y yesterday, it probably won't respond to them today. This way it would be possible to limit the amount of "wrong protocol" packets sent to devices.

However there are some edge cases that need to be thought out. For example, what if device is a computer. If you install MagicQ it can talk Artnet. If you install HiQnet Manager it will talk HiQnet.

This might not be a big problem in the real world but it is an issue that I'm taking seriously. All it takes is one experience with the software causing troubles at a gig and the users loses confidence with the software.
 
Well, an argument can be made that people who are *serious* about this need to upgrade to at least a semi-smart switch, like the new NetGear Prosafe GSS116E, or equivalent, which allows you to set a monitor port (and that, really, they should be on something like HP ProCurves; the 2626 is *stupid* cheap used and comes with lifetime warranty; buy two, test both, if one breaks you can send it back forever).

As for DHCP, I would think you'd need to see the ACK packets... but those aren't broadcast, are they?
 
You're correct. I had the impression that they were broadcasted but digging into the the specs it seems that they can be either way. The client always broadcasts but the server responses can be sent as unicast or broadcast. The client can request that the server responds as broadcast with the broadcast bit.

"If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK messages to the client's hardware address and 'yiaddr' address. In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff." -https://www.ietf.org/rfc/rfc2131.txt

While digging thru the specs I noticed this part
"The client broadcasts a DHCPREQUEST message that MUST include the 'server identifier' option to indicate which server it has selected, and that MAY include other options specifying desired configuration values."


BTW, here is a great recipe for Cajun chicken. I made some today and it was excellent https://thestayathomechef.com/cajun-stuffed-chicken-breast/
 

Users who are viewing this thread

Back