We’ve gotten through a lot of topics in our dive into networking information you need to be most successful with your interactive and immersive installations. In part 1 we covered IPs and then we dove into ports, firewalls, and TCP vs UDP in part 2. In part 3, we’re going to take a look at firewall rules and how to approach troubleshooting with this new knowledge.
If you’re just starting this series, make sure to start with parts 1 and 2 below.
ALSO IF YOU DISABLED YOUR FIREWALL AT THE END OF PART MAKE SURE YOU RE-ENABLED IT (friendly reminder)
Firewall rules
As I mentioned at the end of part 2, the firewall can be a common blocker of communication messages between different systems. As more and more operating systems seem to prioritize security, it will become even more of a common issue. A great way to quickly debug and determine if the firewall is the reason you aren’t able to communicate is to completely disable it in your operating system, restart your application/system, and then try again. If you find that communication is now flowing as expected, we need to re-enable your firewall and make a firewall rule.
A firewall rule is exactly what it sounds like. It’s an exception you manually add to your firewall telling it what additional data you’d like to be allowed to flow in or out of your system. This is important to remember that firewalls filter both incoming and outgoing traffic. This means you could have a system that can receive all the data from the external world but have 0 ability to respond. You could also have a server that has no way of getting info from the outside world but it might be able to broadcast some messages out of it. Both of these are things the firewall can do. In most cases, your operating system will be setup to have a mix of common incoming and outgoing rules setup so you can do things like use the internet, speak to other systems on the network with shared folders, talk to printers, etc.
How to setup a firewall rule
The first step to setting up a firewall rule is to know all the appropriate information required for the rule. This includes:
- Port you’d like to open
- Whether the rule is for incoming traffic or outgoing traffic
- Which protocol is being used (TCP or UDP)
Depending on what firewall you’re using (as there are lots of different ones) and what OS you’re on, you might find setting up app-based rules are easier than the more specific port-based rules. I still recommend using port-based rules whenever possible, especially with complex applications like TouchDesigner that also include a lot of other SDKs and frameworks, I prefer to be explicit and just allow the whole system to talk on whatever port I need. That way if TouchDesigner triggers another process for the communication and it appears to the OS as a different app, you don’t have to hope the firewall is smart enough to make the connection and allow that subprocess to communicate.
In terms of adding the firewall rules, here are two quick guides for how to do this on Windows and macOS, although if you use a different version of Windows or macOS you could search for your specific OS version.
Windows 10:
On Windows 10, the firewall control panel settings are great in that they allow you to do either app-based rules or port based rules.
https://resources.infosecinstitute.com/topic/how-to-configure-windows-10-firewall/
macOS:
macOS is a bit different in that the UI version of the firewall controls focus on app-based rules as opposed to port-based rules. If you would like to do port-based rules, you’ll have to use the command line to set more specific rules, but the app-based rules should work enough for getting started:
How to troubleshoot
You might be up to your ears in somewhat boring network terminology and information, but it’s all useful! Even with just the few things we’ve learned, we can engage in some pretty deep troubleshooting. So what are my first two troubleshooting steps? Let’s take a look:
IP Address
The first thing to do is confirm the IP addresses. Like we saw in part 1, making sure that you understand your IP address correctly (especially making sure you’re using the private address and not the public address) and that the IP addresses are entered correctly. I can’t tell you how many times a simple typo was why a system wasn’t working.
Once the IP addresses are confirmed, we want to make sure that we’re actually on the same network and able to communicate in general. This is where the useful ping tool comes into play. This tool ships with Windows, macOS, and Linux systems by default. The ping tool communicates over TCP protocol between two systems to confirm if they can communicate. That’s really it! It sends a small message from one system to another, waits for the other system to confirm it received it and sends the acknowledgement back, and then it times the whole trip. This is great for both ensuring that you can communicate properly but also that your communication timings are tight (under 30ms otherwise something weird is happening on the local network).
Pro-tip: This works on most networks except those with very strict security policies (like giant corporate networks) where they disable ping messages on the network. In those cases, you can ask IT for help to confirm if the two computers are on the same network and subnet and can communicate, but otherwise ping should work just fine.
Get Our 7 Core TouchDesigner Templates, FREE
We’re making our 7 core project file templates available – for free.
These templates shed light into the most useful and sometimes obtuse features of TouchDesigner.
They’re designed to be immediately applicable for the complete TouchDesigner beginner, while also providing inspiration for the advanced user.
Using ping
ping is a simple tool to use. We access it via command line, but it’s usage is easy enough even if you’re not comfortable with command line. If you’re on Windows, we’ll want to open up a command prompt window, you can do this by click on the start menu and searching for cmd:
On macOS you’ll want to open up Terminal app. Once we have our terminal open we’ll be ready to type in our command. The syntax for ping is:
ping <enter IP address or domain>
That’s it! So an example could be:
ping 192.168.0.247
This would send ping packets to 192.168.0.247 from my system. On my network I could do something like this and see the messages returning successfully:
What we see here is:
- I tell my system to ping 192.168.0.247
- My system sends 4 messages which all receive a reply in less than 1ms
- The final report from my system is that 4 packets were sent and 4 were received
So this is what a successful ping looks like. I targeted a system, sent it some messages, got them back quickly with no lost packets. Perfect. What does it look like if I was to mis-type the IP and try to communicate with a system that doesn’t exist (or a system that isn’t accepting ping messages)?
We’ll see something that looks like this. Instead of getting successful responses with the response times, I either get timed out requests or destination host unreachable.
What does that mean???
What this means is that in about 30 seconds I can hop into the command line and confirm if our IP addresses are even able to communicate on the network. Not only can I check if I typed it correctly (because if I try the IP address and get no answers, I can go double check if it’s correct) but I can also check if the machines are even on the same network or if there is some network-level system blocking my communication. This is huge because if you aren’t able to check things like this quickly, you could spend hours or days trying firewall rules or this and that other troubleshooting options only to realize your systems aren’t on the same network or someone has disabled UDP communication on the router. So doing a test like this is literally the first thing I do on a gig if network communication isn’t working. Do the ping test. If it passes go to the next step below. If it fails, figure out why immediately. Start asking questions about the network and why a ping might fail. This will often lead you to why the communication isn’t working in the first place.
Firewall again?
This is where the firewall troubleshooting we mentioned in part 2 and the firewall rules from this post come into play. If I can confirm that the two system can talk and they are in fact on the same network, my mind immediately goes to firewalls next. The nice thing is we already know what to do here. First, I’d try to fully disable my firewall and see if communication starts flowing. If that works then I’d go on to the next steps we mentioned about creating a custom firewall rule to allow that pipeline to work with my firewall enabled. If disabling my firewall and restarting the application don’t end up working, then I can immediately start raising flags that something might be happening with the network overall. The nice thing here is that when I raise the flag and start asking around about the network, I have a rich amount of information I can use. I can tell the IT folks that I’ve tried a ping test and it worked, I’ve tried opening up firewall ports, I have these IP addresses and ports that I’m using, and I have these protocols that I’m using. Giving an IT person all that information will make their face light up because it sounds like you’re actually trying to make their job easier.
Wrap up
I know it really feels like at the end of the day I keep coming back to IP address, ports, and firewalls, but I guarantee you that the large majority of the day-to-day problems you’ll have with networked installations will be focused on these things. In the next post we’ll wrap up by looking at a few network-level things that you should be aware of, but honestly if you know just what we’ve talked about so far, you will likely be able to fix most problems you have yourself or at least be able to communicate with the right person exactly what’s going on and what you’re experiencing. Happy troubleshooting!
