Your post seems to make no sense, care to reread and revise?
aRFR networking troubles.....
- Thread starterlightingguy1
- Start date
Your post seems to make no sense, care to reread and revise?
Oh sorry. ...should NOT be able to get on. Typing faster then I was thinking.
Yes, the majority of people, it will basically keep the honest people honest. MAC address spoofing and a wireless sniffer can get around both of these things, I am just thinking very large scale to make sure that he is protected in all instances.
ETC actually recommends it both ways. iRFR: How to Setup Your Wireless Network - Electronic Theatre Controls I know it says an access point, but if the router has no WAN then it is basically just an access point.
Actually that is not correct. That would be correct if your in your routing table you had a catch all statement, which most of these little routers do, but in large networks catch all statements are rarely used, especially when you have more than one "WAN" interface.
One of the reasons I do not like the way ETC explains this is because small SOHO networks this will work, larger networks this becomes more difficult especially when you have a firewall in btwn. I am not saying that it is not going to pass the traffic in most instances, but depending on how strict the policies are it could be an issue. Having the RFU and the Console on the same network would eliminate this issue. The other thing that I do not like is what if someone wanted to use a small SOHO router and also wanted to have internet on the same network.(although I would not recommend it) I am not sure if they have a configuration example for this, but this would be difficult and you would need to add a switch outside the WAN port and if the Console was the default gateway when it assigns an IP to the external interface of the router then it would need to also route the traffic back to the internet.
Yes that's all true
But in this case, it's all COMPLETELY IRRELEVANT.
The OP wants to get his aRFR working.
As best I can tell, that hasn't happened 22 replies later.
How about we gets the OP's problem fixed before we get so bogged down in networking googbledegook that the one answer which fixes the probelm gets lost?
This is NOT enterprise networking, multi WAN is completely irrelevant to this discussion. If it involved corporate networks, then you'd need to get corporate IT involved anyway to get network access, IPs etc etc. So stick to what IS involved, a SOHO router, and let's dump the rest of this irrelevant stuff.
But in this case, it's all COMPLETELY IRRELEVANT.
The OP wants to get his aRFR working.
As best I can tell, that hasn't happened 22 replies later.
How about we gets the OP's problem fixed before we get so bogged down in networking googbledegook that the one answer which fixes the probelm gets lost?
This is NOT enterprise networking, multi WAN is completely irrelevant to this discussion. If it involved corporate networks, then you'd need to get corporate IT involved anyway to get network access, IPs etc etc. So stick to what IS involved, a SOHO router, and let's dump the rest of this irrelevant stuff.
Last edited:
I was just saying that sometimes routing 101 does not always happen and also that ETC does approve of doing it either way, so I was providing justification for the steps that I was having him perform above is all.
But going back to the OP's issue you can do it the way with it being on the outside WAN port, but if you do have issues I would check the SPI firewall if you have exhausted all other options.
No hard feelings here Chris, were all in this together!
Oh yeah btw, I wouldn't be doing it ETC's way, but I do like it because it's nice and simple to explain to someone else...
I'd be using static DHCP but that's another thread entirely
I'm still a fraction lost on where the OP is at...
It works but occasionally gets unhappy?
And what's with the question on subnet masks?
If you are running the WAN route, then leave everything on DHCP and the subnet masks at default so 255.255.255.0 for the router's DHCP pool and I think 255.255.0.0 for the ETC.
If there are still other issues, can you please define them so we can get them sorted?
I'd be using static DHCP but that's another thread entirely
I'm still a fraction lost on where the OP is at...
It works but occasionally gets unhappy?
And what's with the question on subnet masks?
If you are running the WAN route, then leave everything on DHCP and the subnet masks at default so 255.255.255.0 for the router's DHCP pool and I think 255.255.0.0 for the ETC.
If there are still other issues, can you please define them so we can get them sorted?
lightingguy1
Active Member
First of all, before you go and shell out money for a new router, There is somethine else I would try. I would head over to DD-WRT and see if the router you have is supported by their software. Most (but not all) Linksys routers are. The DD-WRT firmware is so much more robust and stable than the default Linksys, and it is free, so it can be like getting a new router for a grand total of $0. Also, personally, I would never by a netgear product, but that is just me.
It sounds to me like most of the issue here is frustration and impatience. Unless you really know networking, it can be a real PITA. Frankly, I don't really understand how HansH's solution can work, but if ETC says it should, then it is certainly worh a try. No need for me to get into my concerns about it. You should however note that with DHCP systems, sometimes they care what order devices are rebooted. Sometimes devices need to be power cycled to to pull down a new IP address or renew their lease. With your Ion acting as a DHCP server to the WAN side of the Router, this could have been your isse when you rebooted, the router lost it's connection and never pulled a new address. Reboothing the routher may have solved your issue.
Of course I also dislike the idea of running the entire system DHCP, with static IPs at least you know where every device is all the time, but again, that is a whole different conversation.
Switching routers, or switching firmwares I do not think is your issues, and I do not think that switching to DDWRT would solve anything especially seeing it is easy to brick a router if you are not careful and also if I am correct in your screenshot in the first post it says you have a wrt120n which is not supported by DDWRT.
Yes this can be a large pain unless you know networking, I will be calling ETC tomorrow to talk about how we could simplify this.
This could be an issue with the router not getting an IP but this theory could be quickly eliminated if you went to the status page and saw if the router did have an IP and if not pressed renew DHCP lease. (this would be in the WAN section of the status page) And this only pertains if you are using the console plugged into the WAN port.
Yes this can be a large pain unless you know networking, I will be calling ETC tomorrow to talk about how we could simplify this.
This could be an issue with the router not getting an IP but this theory could be quickly eliminated if you went to the status page and saw if the router did have an IP and if not pressed renew DHCP lease. (this would be in the WAN section of the status page) And this only pertains if you are using the console plugged into the WAN port.
lightingguy1
Active Member
Why is that...and what would you buy? Ha! You have no idea how long this issue has bugged me!
Hi lightingguy1,
I am sorry to read that you are still having issues connecting your aRFR. There has been a lot of discussion on this topic and I am sure more theory to follow after you have resolved this issue.
Unless you are just unhappy with the specific brand of router, I am not sure that you need to purchase a new one. I know there is some disagreement over which ports you should be connecting to, the use of static vs dynamic IPs and the like, but in an effort to resolve your issue here is what I recommend:
1. Reset your existing router back to the settings that you had in the screen shot you first started with. They were correct for what Hans detailed in his suggestions.
2. The Ion settings you posted originally were mostly correct but need a few tweaks:
As for your Android device, make sure it is set to get its IP address dynamically using DHCP from your router. It will get a 192.168.1.x address, which is fine because the router is doing the translation from that network to the 10.101.x.x network.
The missing "Primary|Master" from the user string usually indicates that the network adapter was offline at the time of the console being launched. For that, usually exiting and returning works to resolve it, but if it persists, make sure you are seeing network activity on the router and on the back of the console.
I am sorry to read that you are still having issues connecting your aRFR. There has been a lot of discussion on this topic and I am sure more theory to follow after you have resolved this issue.
Unless you are just unhappy with the specific brand of router, I am not sure that you need to purchase a new one. I know there is some disagreement over which ports you should be connecting to, the use of static vs dynamic IPs and the like, but in an effort to resolve your issue here is what I recommend:
1. Reset your existing router back to the settings that you had in the screen shot you first started with. They were correct for what Hans detailed in his suggestions.
2. The Ion settings you posted originally were mostly correct but need a few tweaks:
A. Your console should have a gateway in the the local IP settings. We recommend that it either be 10.101.1.1 or the same as the console's IP address. (Yes hardcore networking enthusiasts, we are breaking some guidelines but it works.)
B. Your address service should be checked as it was originally, but the main reason you aren't getting communication is that the subnet mask that you have defined is too restrictive. Your first address is set to 10.101.1.101 (which is not the published recommendation but will work just fine) and your subnet mask is set to 255.255.255.0. That means that any device getting an address from the console (the router in this case) will only be able to talk to those devices with an address of 10.101.1.x, but the console has an address of 10.101.100.101. Instead, you should change your subnet mask there to be 255.255.0.0. That will allow devices getting an IP address from the console to talk to any other device that has an address in the range of 10.101.x.x.
C. For the above to work, you will need to make sure the console is connected to the WAN port.
After you make the changes above and restart the console when prompted, wait until the console has fully booted then power cycle the router. It will ask for a proper IP from the console and you should have communication between the router and your console.As for your Android device, make sure it is set to get its IP address dynamically using DHCP from your router. It will get a 192.168.1.x address, which is fine because the router is doing the translation from that network to the 10.101.x.x network.
The missing "Primary|Master" from the user string usually indicates that the network adapter was offline at the time of the console being launched. For that, usually exiting and returning works to resolve it, but if it persists, make sure you are seeing network activity on the router and on the back of the console.
lightingguy1
Active Member
Last edited:
I am not exactly sure what you mean here. You do want to make sure that the console has an active network connection before launching as primary. To do that, make sure that the lights next to the Ethernet connection of the console are on/blinking. For the router to get a proper IP address from the console, have the console on before power cycling the router. You shouldn't need to do this often however because the addresses given out by the console have a pretty long lease.
If I understand this question correctly, you will want to connect the console to one port of the ETCNet system and the connect the router to a different ETCNet port in the same facility. Remember that the connection from the ETCNet lighting network to the router should still connect on the WAN port. You should also leave on the Address Service (DHCP) on the console to provide addresses not only to your router but also to your ETCNet2/3 Nodes/Gateways.
lightingguy1
Active Member
Whoops! I totally messed up that one....**Facepalm**
Please see edited post....
So in all honesty, the nodes/gateways addresses should be DHCP, NOT static? How would you be able to configure specific ones correctly if they were DHCP? Wouldn't the addresses change day-to-day? If so, How could you "track them down?" Would it be possible to have a mixture of static and DHCP addresses on a network?
The TD at my venue, takes care of the networking, so I don't have to....I'm trying to get my head around this stuff!
Once again, I would like to thank you guys for getting this hot mess into an amazing, usable RFU!
Please see edited post....
So in all honesty, the nodes/gateways addresses should be DHCP, NOT static? How would you be able to configure specific ones correctly if they were DHCP? Wouldn't the addresses change day-to-day? If so, How could you "track them down?" Would it be possible to have a mixture of static and DHCP addresses on a network?
The TD at my venue, takes care of the networking, so I don't have to....I'm trying to get my head around this stuff!
Once again, I would like to thank you guys for getting this hot mess into an amazing, usable RFU!
Last edited:
Let's break these questions out individually:
They can be either. They ship from ETC requesting an IP address to ensure that they will play nicely on the same network.
Using Network Configuration Editor (NCE) for Net2 nodes or Gateway Configuration Editor (GCE) for Net3 Gateways. There is a service that "discovers" the devices on the network and pulls back their current configuration for you to be able to edit. There is not a need to know specifically which IP addresses the devices use, just which devices are located where (which is usually what the Name/Label field is used for).
DHCP uses a system for keeping addresses called leasing. Each address handed out also has a lease period for which it is valid. When the lease expires, the device requests an address again. Usually it renews the same address, but, if by some chance it was already assigned, it may get a new address. ETC issues addresses with 10 year leases. This makes it unlikely that it will actually change IP addresses. However, some devices do not keep a record of their DHCP leases with a power cycle. Your router is one of those devices that will likely forget its address on reboot, which is why you want the DHCP server online when it is looking for an address on power up.
Absolutely! Those devices that are set statically will ignore the DHCP server because they do not need to be assigned an address. In fact, most ETC networked systems are a mix. The nodes/gateways are usually dynamic while the dimming racks and architectural systems are set with static IP addresses. As long as everyone is in the same IP range and subnet, they should play nicely together.
Not at this time.
Similar threads
