Ruida firmware has always assumed a TCP/IP network mask of 255.255.255.0. This effectively required everyone to artificially limit the available IP address of their laser to an address which matches the first three octets of the laptop/PC using the laser. This works fine for folks who have their equipment on a Class C network, but for folks (like me) with a Class B (or Class A) only a small subset of machines on the network will be able to talk with the laser.
All Ruida has to do is simply ASK for the subnet mask to be entered when configuring the controller (instead of always assuming 255.255.255.0). I have never seen any other network devices make this lazy (and absolutely incorrect) assumption.
Anyway, about a year or so ago, it was said Ruida understood the issue and would be fixing it. Anyone know if they finally did something about it?
Opinion: Even if somebody said they understood the issue, the probability of a fix rolling out to any existing controllers is exactly zero.
Not only would an update require new firmware for each controller model, every seller must then merge that firmware with the setup configuration for each distinct machine type they sell (or sold) with that controller and verify each combination works as intended or at least doesn’t brick the controller.
Given that the number of folks (like you) with anything other than a Class C network rounds off to zero, nobody in that chain has any motivation to solve your problem.
They did, however, get you to Go Away for a year, which definitely counts as a win in their customer service criteria.
I don’t know where you found this, but it’s like complaining about the sunrise/sunset times. We’ve seen attempt to fix things before. These fixed items were simple items, not anything like re-writing the IP section.
As @ednisley was attempting to say they simply don’t care.
I’ve always stated that the communication abilities of the Ruida are some of the worst I’ve ever seen.
I believe it uses UDP/IP. I think many times UDP is referred to as an unreliable and connectionless protocol because it is.
UDP doesn’t need a connection and does not guarantee delivery, order, or error checking, making it a lightweight, efficient option and much more easily programed generating less code.
It could also be that there is limited memory within the Ruida for firmware, but I’m just guessing.
The only other option is a non Chinese controller or a bridge.
The Lightburn bridge has a Lightburn created software layer to help with these UDP issues.
I’ve been writing software professionally since the 1980’s. I’ve written software that was licensed by both Microsoft and HP for their internal use. Much of the code I’ve written is also used specifically for network communications. I know a little bit about what can and can’t be done, what is required to implement those changes, and how deep those changes must go into a product line.
The"entire IP stack" does not need to be re-written in any way shape or form. All they need to do is ASK for the user to supply a subnet mask instead of assuming it will always be 255.255.255.0. Its actually the configuration interface which needs the extra work so they can simply ask for the info.
The entire product line does NOT need to be re-written. They could choose to roll this out as iother updates are being applied to their controllers.
Most of the networks I have worked on are NOT class C networks. I reject the assumption that this “rounds to zero”. Many established CNC shops have networks which are larger than the very limited 255 hosts which can be supported on a class C network. The very fact that folks have to suggest that the first three octets must match that of any PC/Laptop which wishes to communicate with the controller is proof of this. If everyone was running just class C networks then this issue would never be encountered.
Whether Ruida controllers use UDP or TCP is not actually relevant to solving this issue. (I’ve heard they use UDP). For the purposes of addressing, both TCP and UDP use IP for transport and have the same subnet masking and addressing requirements.
Again, this has nothing to do with re-writing the protocol stack. All they need to do is ask for a subnet mask to be input instead of simply assuming it is always 255.255.255.0. I’ve literally never seen any other device on a network make this assumption. I guess we are lucky they just didn’t give us a fixed IP address as well…
Tbh, if you are running a class B network, you should also have the ability and equipment available to stick it on a separate class C VLAN and route to it. Not that hardwiring the subnet mask isn’t a ridiculous design decision, it looks like it would be extra work to get to that point!
The fact of the matter is many consumer routers with a built in DHCP service automatically create a 10.0.0.0 address for the private network so that is what many folks end up using anyway. …and that is a Class A network by default. Lots of folks have more than 255 hosts on their home networks given all the “intelligent” crap we buy so more and more routers are now just issuing 10 dot addresses. Less and less people are running Class C networks anymore…
Yes, I know lots of ways around this (like sticking a $50 router onto the side of the laser to create a private class C network under my primary network just for it alone). But the proper solution is for Ruida to fix their code to allow us to specify the mask we want to use. That is the way it should have been done in the first place and it should be a fairly simple fix.
…and yes, I have programmed FPGA hardware, using both Verilog and VHDL.
Anyway, despite all the axes everyone seems to have to grind, it appears Ruida has not updated their firmware so I’ll take my leave at this point.
Rather than waiting for Ruida to fix their IP Stack, I purchased a tiny $70 Router to sit between the machine and my network. It works great. This effectively puts the Ruida controller on its own isolated Class-C network (192.168.2.0/24) underneath my own Class-B network (172.20.0.0/16).
I was going to try this with a Raspberry Pi, but Pi’s only have a single ethernet port and this device is smaller and cheaper anyway. It appears to be the perfect solution for what I wanted to do. (Its actually a Pi under the covers anyway…)
The router has an IP in my network (172.20.8.1) and it processes/accepts traffic from any host as it should. It then passes it into the private “Ruida” Network (192.168.2.0/24) where there is only one host (the Ruida Controller) at 192.168.2.2.
It only took a few minutes to load the latest router firmware (FriendlyWrt which is a port of OpenWrt). It then only required two additional firewall rules from the default config:
Port forwarding of all UDP traffic on port 50200 from the outside IP of the router (172.20.8.1) directly to the Ruida controller inside (192.168.2.2)
masquerading (NAT) all traffic back in to the “real” network so it all appears to come directly from the router.
As far as my network is concerned, the address of the Ruida is simply the address of the Router (172.20.8.1) and the IP traffic is properly handled regardless of the size of the network. (Ruida traffic can even flow through an upstream Internet Router). No more messing around with artificial addressing rules (or network size limitations) imposed by a broken Ruida network stack.
Lightburn appears quite happy with the arrangement!
I’m still using UDP (which I’m OK with) and entirely on a wired network (which I prefer). This router will accept a WiFi module and similar models already have it built in WiFi (which I wasn’t interested in).
If you have a larger network and would like ALL the machines on your network (even outside you network) to be able to talk to your Ruida controller, this is a pretty simple solution I think.
