What ports does X32 Edit need?

StradivariusBone

Custom Title
Premium Member
Fight Leukemia
Trying to access an M32 through a router. We have a central broadcast room that links two venues, both with M32s. Both venues have M32s which are networked directly to consumer routers to allow for the musicians to operate the mixing apps for their IEMs on their mobiles.

I'd like to be able to use the X32 Edit app to work on the boards remotely when in the broadcast room but I can't seem to get the routers to allow the traffic. Wireshark indicates that the Edit app sends out UDP on port 10023 exclusively, but opening that port up still returns an error of an unreachable port. Also tried putting the board in the DMZ with the same results.

It doesn't looks like X32 Edit is sending anything else out for discovery (like multicast traffic) it looks like it just sends out a message on the broadcast address with the same port and then waits for a reply. Anyone gone down this rabbit hole? I'd say it's the router brand, but we actually have two different ones and the same issue.
 
Paging @TimMc , he might have some ideas.
 
I would probably employ the use of a hub or sniffing switch to see what sort of handshake occurs after discovery. This won’t show up in wireshark.
 
Paging @TimMc , he might have some ideas.
Ya know, I've never even thought to look. One of those things that 'just works' so long as all devices are on the same network. Can be DHCP or automatic local address (169...).

It's def a firewall issue on your routers. I'm not privy to how it was done, but we had a mixerperson in Manila mixing a pandemic streaming show in Belfast. All I know is the changes in the router for the each user was similar to what one would do for gaming.
 
Static IPs or DHCP?
It staiic, the router is the gateway adresss, then the IP of the board you want to edit.

Personally, on small dedicated networks, I prefer static IPs. Router is usually 192.168.1.1 with subnet 255.255.255.0, then PC 1 192.168.1.10, then board 2 -.20, board 3 -.30 and so on.

The network settings under setup will tell you the configuration. If DHCP and dealing with VPN, it's a bit more complicated and over my paygrade.
 
One of those things that 'just works' so long as all devices are on the same network.

It might just be that simple. We do have the wireless networks on a different subnet than the main production network. The idea there was to keep meddling musicians out of the production side of things where they'd have access to mess with any of the 2 consoles that aren't in the FOH.

What's odd is that the error that's coming up is from the host console we're trying to hit. So the traffic is getting through (we can ping it at the very least), it's just rejected on the other side which makes me wonder if the console itself is defaulted to reject connections from outside its own subnet. It just doesn't make sense that they would give you an option to do a manual IP (assuming discovery failed) and then configure the consoles to reject stuff outside their own subnets.

We do have a bunch of devices that are static since everything has a control interface webpage these days, but we have an edge router setup to run DHCP for the production network stuff that doesn't need a static and then each of those routers does its own DHCP as well.
 
It might just be that simple. We do have the wireless networks on a different subnet than the main production network. The idea there was to keep meddling musicians out of the production side of things where they'd have access to mess with any of the 2 consoles that aren't in the FOH.

What's odd is that the error that's coming up is from the host console we're trying to hit. So the traffic is getting through (we can ping it at the very least), it's just rejected on the other side which makes me wonder if the console itself is defaulted to reject connections from outside its own subnet. It just doesn't make sense that they would give you an option to do a manual IP (assuming discovery failed) and then configure the consoles to reject stuff outside their own subnets.

We do have a bunch of devices that are static since everything has a control interface webpage these days, but we have an edge router setup to run DHCP for the production network stuff that doesn't need a static and then each of those routers does its own DHCP as well.
if you can ping the console then its not subnet, If they weren't on the same subnet they wouldn't be able to communicate at all. Do you have everything set as static IP's for console and control?
 
They aren't on the same subnet. The console is behind a router port. I've tried opening the 10023 port and put the console in the routers DMZ, which will allow the pings to happen but shows a blocked port when the X32 Edit app tries to hit it. Console and the computer are both static IPs.
 
It might just be that simple. We do have the wireless networks on a different subnet than the main production network. The idea there was to keep meddling musicians out of the production side of things where they'd have access to mess with any of the 2 consoles that aren't in the FOH.

What's odd is that the error that's coming up is from the host console we're trying to hit. So the traffic is getting through (we can ping it at the very least), it's just rejected on the other side which makes me wonder if the console itself is defaulted to reject connections from outside its own subnet. It just doesn't make sense that they would give you an option to do a manual IP (assuming discovery failed) and then configure the consoles to reject stuff outside their own subnets.

We do have a bunch of devices that are static since everything has a control interface webpage these days, but we have an edge router setup to run DHCP for the production network stuff that doesn't need a static and then each of those routers does its own DHCP as well.
@StradivariusBone Does your edge router do bull nose?
Toodleoo!
Ron Hebbard
 
It might just be that simple. We do have the wireless networks on a different subnet than the main production network. The idea there was to keep meddling musicians out of the production side of things where they'd have access to mess with any of the 2 consoles that aren't in the FOH.

What's odd is that the error that's coming up is from the host console we're trying to hit. So the traffic is getting through (we can ping it at the very least), it's just rejected on the other side which makes me wonder if the console itself is defaulted to reject connections from outside its own subnet. It just doesn't make sense that they would give you an option to do a manual IP (assuming discovery failed) and then configure the consoles to reject stuff outside their own subnets.

We do have a bunch of devices that are static since everything has a control interface webpage these days, but we have an edge router setup to run DHCP for the production network stuff that doesn't need a static and then each of those routers does its own DHCP as well.

If you're trying to get an X32 on 1918 net B to respond to machines on 1918 net A, then either the router on net B is going to have to give the X32 a way to get packets back there, or the X32 itself will have to know how to deal with that, and I'm pretty sure its network stack isn't that smart.

These routers are in different places? On different public IPs? How are the packets moving from A to B?
 
in addition to yuor sketch, plz run AngryIP Scanner or similar on each LAN and post the results as CSV file
 
"Wireshark indicates that the Edit app sends out UDP on port 10023 exclusively, but opening that port up still returns an error of an unreachable port."


Scroll down to "comparison of UDP and TCP"... for what you're looking to do, you need a TCP connection - bidirectional - on the control app. x32 Edit can't be real time if it only deals in UDP. you need the mix app
 
1663362420381.png


It's not much of a map. I'm wondering if it is something in the router that's blocking the return path like Jay said, so I was planning to setup wireshark to run inside the Venue 2 subnet to see if it would grab anything different. Oddly enough it was able to establish a connection using one computer in that booth (a different one than I had been working with) but one that is on the 192..2. subnet. I didn't have much time to troubleshoot last night, but I'm chalking it up to the router being flaky for now, but there's also an issue of our potentially overzealous MSP installing their monitoring software on parts of the production network when they were asked not to. I'll try again from the broadcast room, but I'm assuming if I can hit it in one spot, I ought to be able to hit it in another on the same subnet. There's only a small managed switch between the two.

1663362853010.png


From everything I've seen from the X32 App, it's just UDP. It's just streaming packets updating the board status once it's connected, which makes sense. There's not a huge need for error-correction, but a definite benefit to lower latency. There might be some kind of TCP handshake happening in the beginning that I haven't seen, but past that it's just streaming data between the two hosts post-connection. In any event, it seems like it's "happy", just will do some more troubleshooting to see if I can nail down what changed to allow it to work.
 
Yeah, I put in static routes on both wifi routers to point to each other. The LightFactory PC's in both spaces have web servers and those are able to hit from any of the subnets. It was just this particular app that wouldn't for whatever reason. Like I said, it worked last night, but now I'd like to learn why it decided to all of a sudden.
 
The problem is likely that the nodes on either network connect to a router that may not have a route to the other network, since there's a third network in the middle.

To really make this work right, you're going to need a bunch of static routes on the various routers.
yeah, network topology (and terminology - we're increasingly networking pros too, lately) has something to do with it as well no doubt...the two Venue "routers" are set up as Access Points to/for subnets rather than routers.
The whole facility should be IPv6 (but that's a discussion/rant for another place/time - the gear just isnt up to speed on this in most cases yet - so in the meantime go here and add this to your credentials/resume ) because it makes this so much easier and the day is coming...
 
I can only barely justify IPv6 for the greater Internet, really; there's no justification for running it on local networks that I can see unless you're Ford or GE or Chase.
 
I can only barely justify IPv6 for the greater Internet, really; there's no justification for running it on local networks that I can see unless you're Ford or GE or Chase.
My house network has 3 vLANs... one for IoT, one for security, and one for WAN access. No registered domain name, just a local network.
 

Users who are viewing this thread

Back