OMTech AF2435 (Ruida) LB v1.3.01 won't connect via TCP

LightBurn Hardware Compatibility
1

I’m just replacing an FSL Pro24x36 with a brand new OMTech AF2435. I’ve set up the IP address on the OMTech (Ruida) controller. The Laser and PC are both hardwired to the network. I can ping the Laser but Lightburn refuses to connect with it. It continually says “No Device Detected” or “Waiting for Connection”.

I have been a network engineer since the 80’s (Novell CNE, Microsoft CNE) so I’m confident in my network integrity. The FSL Laser which this unit replaces used the same ethernet cable and PC. Using an RFC1918 Class B Network Address of 172.20.0.0 / 255.255.0.0 and gateway of 172.20.1.1. The PC and the Laser are on the same network so gateway should be irrelevant. The laser’s address is 172.20.8.1. The PC is 172.20.100.4. (Its interesting that there is no subnet mask configuration available on the Ruida controller).

In any case, my PC CAN ping the laser. Its just that Lightburn will not connect to it. (…and I’ve checked my LB device/network config several times…)

Anyone have any ideas?

2

I don’t have your time on a network, but I’d think the mask needs to be 255.255.255.0 ?

Actually I thought the Ruida uses UDP/IP, not TCP/IP. ?

:smile_cat:

3

I’m pretty certain you’re the only person in this forum running a class B network on a 172.16.0.0/12 address block so interesting to see.

Have you checked the trace route from PC to controller?

Also, as Jack indicated, Ruida does not communicate on TCP but uses UDP instead.

Do you possibly have any filtering rules blocking those packets?

4

No… A 172 network, set up as a Class-B (the default) uses 255.255.0.0 (/16)

I’ve been building (and selling) networks for many years…

The Ruida controller doesn’t ask for a subnet configuration in any case which is very unusual!

5

TCP has two protocols UDP and IP. UDP is connectionless and IP is connection oriented. (I’ve also written software which communicates via UDP (connectionless) and IP…) TCP Addressing rules are the same regardless of whether IP or UDP is used.

Regardless, Ping (ICMP) confirms that the Ruida controller sitting at 172.20.8.1 is indeed responding to my PC. …and if I unplug the LAN cable from the laser then the ping fails. (so its not like I have another device on the network with the same Address

1 Like
6

The Ruida is a great controller… for that you trade off it working well elsewhere…

I’ve always considered it stupid when it comes to communications usb or otherwise.

I think it just sits there and waits for a udp packet, when it’s not in run mode.

:smile_cat:

7

No filters. Tried temporarily disabling my AV software just to be sure… No difference…

8

Shouldn’t matter. TCP is TCP. (…and I’m running on 172.20.0.0 not 172.16.0.0)

The 10.0.0.0 (Class A) network is larger than I need (and I have a microwave VPN link to my office which is 10.0.0.0 so I couldn’t use it anyway…) 192.168.0.0 (Class C) is too small as I have lots of devices on my home network. So I needed to use a 172.0.0.0 (Class B) network to have enough room for all my equipment and still have room left for growth).

This is not a network issue… At least not as far as my network at home is concerned. It may very well be a TCP configuration issue with Ruida (who curiously never asks for a subnet mask), or Lightburn trying to find it…

This is going to be a major disappointment as I just unloaded my FSL laser because of an MS XPS update which just broke their proprietary RetinaEngrave software (which they no longer support). The w2hole reason I went to OMTech was because they used Industry standard Ruida controllers and could run non-proprietary software like Lightburn.

Now, right out of the box, Lightburn is refusing to connect with my shiny new Laser…

9

I was referring to the entire block.

I pray for your routing equipment if you approach a million devices. :wink:

A few suggestions:

  1. If you haven’t already tried it. Right-click on Devices button in Laser window to force a reconnect.
  2. Try connecting your computer directly to the Ruida to rule out the possibility of a hardware issue or software configuration issue
  3. Setup a 192.168.0.0 network to see if that addresses the issue. I’m curious if somehow the Ruida assumes a subnet mask. I find this unlikely, though, because I believe its default IP is 10.0.3.3 or somewhere in that range.
  4. Do some packet sniffing to sort out where communication is failing. I’d think if anything packets should be making it out. Maybe failing on the return.
10

I don’t NEED a million devices but I do need more than 256… (A “192” network is simply too small…)

I’ve tried reconnecting multiple times rebooting etc. No luck…

I’ve considered grabbing a wireshark capture but I was REALLY hoping I wouldn’t have to dig that deep… Even the proprietary, now unsupported, FSL laser played on the network just fine…

Unless I’m missing something, this is pretty sad…

11

You’re just not trying hard enough.

192.168.0.0/16 should get you 65,536 if you can squeeze into that.

I’d really suggest starting out with a setup that’s known to work with a direct connection. Then seeing where it breaks down. If you can’t get it working after that then you know there’s a more fundamental problem like ethernet is just broken on the controller.

If that does work, then you can expand the test to see where it breaks down. A possible progression:

  1. direct connection using a 255.255.255.0 mask
  2. direct connection using a 255.255.0.0 mask
  3. on isolated switch with just computer and controller attached with both mask strategies
  4. on LAN
12

Whats your issue? Do you have something against 172 networks?

NO, I’m not going to “squeeze into” anything. There is nothing wrong with my 172 network. It is built properly. I’m not going to re-address my entire network (routers, switches, servers, workstations, access points, microwave antennas, media streamers, door openers, SMS Relays, Messaging Devices, Remote controls, TV’s, FireBoxes, BlueSound Equipment, Raspberry Pi’s, Arduinos, ESP32’s, etc) just for ONE device which doesn’t implement TCP properly. All my OTHER devices are working as they should on my Class-B network! Take a look at RFC1918 if you have any concerns about what specific network addresses are appropriate for private use.

The problem appears to be that THE RUIDA CONTROLLER doesn’t know (or at least ASK) anything about subnet masks. It could pick a default subnet mask based on the first octet of the network range (which would be pretty sloppy), but it doesn’t even appear to be doing that. I’ve never had any non-DHCP TCP device NOT ask for a subnet during configuration…

My testing appears to confirm that the Ruida Controller (RDC644XG) is not properly supporting TCP. The fact that it doesn’t ask for a subnet mask was the giveaway. It appears to be applying a 255.255.255.0 (/24) mask to my Class B Network! If I give the Controller an IP address which shares the same first three octets as my PC, I can connect with it! I don’t expect this is a Lightburn issue as the network stack management is done by the O/S. So, it would appear that Ruida is making some assumptions that it shouldn’t! I think its ALWAYS applying a 255.255.255.0 subnet mask…

I’m curious if anyone is running on a “10.” network and can communicate with a Ruida controller that DOESN’T share the same first three octets? Maybe the Ruida controll is “smart” enough to look at the first octet and make accomodations for “10.” but not “172.” It actually shouldn’t be making ANY assumptions in ANY case. Why not just ask us?

IOW:
Network: 172.20.0.0
Subnet Mask: 255.255.0.0
My PC: 172.20.100.4
Ruida Controller: 172.20.8.1

This doesn’t work…

But if I change the Ruida Address to 172.20.100.100 Lightburn on my PC can communicate with it…

This should NOT be necessary and only the hosts in my 172.20.100.0 block will be able to talk with it. (I use the third octet for organizational grouping and 100 is only for my personal workstations. None of my servers, or workstations of other family members, will be able to see it)

All because Ruida is not properly implementing a subnet mask…

13

Sorry. I was speaking lightheartedly but apparently you took it a criticism. And I wasn’t suggesting you change everything to accommodate the Ruida. I was offering a method of troubleshooting.

Anyway, I’ll step away.

14

OK, my apologies…

I was going to simply run a single ethernet cable between the PC and the Ruida to test a 168 network but it occurred to me it might be worth testing a simple IP reassignment on the Ruida first. I figured they might just always using the same subnet mask (since they didn’t ask). All I had to do was change the IP on the Ruida. …and it proved worthwhile. At least now we know where/what the problem is!

So, the Rudia TCP implementation is effectively broken. Even a novice network engineer would know that a subnet mask needs to be set appropriately. The good news is they are likely using someone elses TCP library anyway (as no sane person tries to write their own TCP stack when lots already exist). I would expect all they need to do is ask for a subnet mask on the UI and then actually apply it (in place of the 255.255.255.0 they are apparently using).

I’m going to run this up the flagpole at OMTech (as they certainly have more clout with one of their biz partners than a single user). I’ll also see if I can find a way to open a ticket at Ruida directly.

15

Since you know the problem, shouldn’t you be complaining to OMTech?
OMTech does state in the large print “Ethernet to PC”, not Ethernet to obscure networks.
Post a pic of your in house server farm, love to see it.

16

I’m sorry… I thought knowledgeable folks here might already have a solution to this problem…

There is no such thing as an “obscure” network. “172” (Class-B) should work as well as “192” (Class-C) or “10” (Class-A) networks. TCP is TCP as long as its properly implemented. Other folks seem to be using 10 and 192 networks without an issue.

In fact, if you actually read the thread, you will see that I DID NOT know what the issue was AT THE START of this. (I had hoped someone might have already diagnosed the issue)

So, I ultimately DID work through the issue and find out what the problem appears to be. You can see this if you read the thread.

And, I did post what I found here in the even some other user may find it to help them as well. (You can thank me later…)

And I did just finish posting the details to OMTech so they can take the ball to Ruida about this…

But thanks for your helpful suggestions!

17

Based on past experience, keep your coffee in a really good insulated mug while you wait for the response … :frowning_face:

18

I plug my Ruida directly into my PC with no issues other than having to assign my pc an address…

Maybe you can clarify… I always thought TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network.

But UDP doesn’t does none of the above except use the IP network in an attempt to deliver the packet and it doesn’t know/care if it made it there or not. Seems like a long way from TCP/IP.

Have I go this wrong?

:smile_cat:

19

Thanks, I wouldn’t expect any less…

Its a pretty dumb firmware error and I wouldn’t expect it to be very hard to fix. No one writes their own TCP stacks anymore so all I would expect they should have to do is ask for a subnet mask and then use it instead of the one they are ALWAYS using (255.255.255.0)… The library/API they are using for TCP services undoubtedly already has a parameter available for this.

20

TCP/UDP is connectionless and data delivery is not guaranteed. TCP/IP is connection oriented and provides guaranteed delivery at the transport layer.

All TCP packets (IP and UDP) have checksums in their payload to provide the ability to detect corrupted data. However, only IP ensures delivery and in a specific order.

UDP is more like shouting in a crowd. No one is guaranteed to get your packet, and no re-transmits will automatically be performed. When using UDP, the applications at either end need to have some sort of agreed upon hand shake (at the application layer) so they can determine if packets are delivered, in what order, or if re-transmits are necessary. IP does all this automatically at the transport layer…

UDP is generally used for lightweight, non-critical, data transports. IP is more robust. Not sure why they chose UDP here, but as long as the services running on either end can agree on a hand shake process, then there is no reason why it can’t work.

The addressing scheme is the same never-the-less…