I once again experienced the same issue with the next webi controler.
Lost connection with it was only abled to establish it by putting it in PRG mode and using router for DHCP. This happens 2 times and the third time I am no longer able at all to access it, I then once again got the 403 error in the page.
This time I bought 2 WebI modules, they have lasted about 1,5-2 years each earlier, so that we would not risk being without the switch when it happens again.
But this time it only lasted for 1 week, then the problem came back, was able to fix it only by restart, 2 days later same thing I then changed to the other Webi module, that lasted also 2 days. And today it was not possible to restart to fix the problem so I have had to put it in DHCP fearing that it is not long until also this Webi gives up completely.
Since the cost of shipping from Sweden I have not returned any of the modules, I am now up to 5 Webi modules showing the same symptom and being corrupt.
Feels like there has to be another explanation to this?
I am assuming you are assigning a Static IP address to the board. Can you confirm that?
If you are assigning a Static IP address to the board is the IP address you are assigning the board outside the DHCP range of the network router? My guess is that there is an IP address conflict issue with another device on the network.
Sometimes it is better to reserve a DHCP address for a board on the network router than to assign a static IP address to the board. This ensures that the router does not lease that IP address out to another device on the network under any circumstances. Of course assigning the board a Static IP outside the DHCP range will accomplish essentially the same thing.
The Webi is assigned to a static public IP so a router should not be a problem. And that I think would not explain that it goes corrupt and that I am no longer able to access it at all?
What is the static IP address you are assigning to the board and what is the DHCP range of the router? If the IP address you are assigning the board is inside the router’s DHCP range then this can absolutely cause an IP conflict.
I think you are focusing on the wrong thing, no matter the Router your Webi module should never leave static IP mode by itself, no products I know of are designed to act that way no matter of the network condition. If there is an IP conflict the problem is in the network not in the module. And it does not explain why I finally with so many modules get the 403 permission denied problem.
I guess what I am saying is it sounds like the module is trying to use the static IP address assigned to it but another device took that IP address so when you go to access the board over that IP address it isn’t the board responding to your request but rather the other device on the network that took over that IP address. Does that make sense? It’s not the Web-i giving you a 403 error its some other device.
But when I move to under another router using DHCP the problem is still there.
And it is right now using DHCP despite that it is set to fixed IP and it is not in PRG mode.
And when I get the 403 error there is the NCD logo on the tab of the browser.
Would you mind taking a look at Joakim’s description and see if you can determine what would be causing this? Joakim, Jacob and Xu are the developers here who created the Web-i module so perhaps they can provide some insight into this. I have not previously seen this problem.
403 is a forbidden error code. So something is either disabling the web server, resetting file permissions, or just generally corrupting on-board memory.
What are you switching with the relays? Its possible that inductive spikes are somehow getting fed into the Web-i and degrading the on-board memory over time. This is the most likely culprit that comes to mind.
Could you reset the module to DHCP and put it on a to a simple network and see if it works? If the page does comes from the module, the module should have a corrupt memory. However, put a module on a simple network and DHCP mode can check if the module still working.
Shirui_Xu_Software_D:
That’s exactly what i tested, i used wireshark and connected directly to the module and saw that it was making a DHCP discovery, I then connected it to free standing router to see if it got an IP, and it did, I then connected to that IP and was able to access it, the module I have now has not reached the 403 error yet but it is showing the same first signs already. But on the last modules that finally got to the 403 error I went through the same procedure.
Jacob
I am using all the relays to control small Tratec Coaxial relays on 12V that draws very small mA. It is used to switch our upstreams CCTV inputs to our Instruments.
I think I have tried your suggestion on other html with the earlier Webi modules but i can try with the old one again on Monday when i am back at work.
It has been supplied with a 12V 2A power supply.
I now tried changing it to 12V 5A just to test and when i started up i got the 403 error.
But as you suggested one page works, but not just inputing the IP.
Yes it looks like your etc files have been corrupted somehow. Theres a section in the guide that might fix the issue. It states:
If Web-i Interface pages do not display all content:
Enter the following sequence into the address bar of your web browser: http://deviceIPAddress/cgi-bin/resetEtc.sh This will reset the configuration files for the device. The device will then have to be reconfigured.
I’ve not seen this happen often, but it could be the issue.
When i try that I get a empty page with “Reset Etc folder” in the upper left corner, but there is nothing i can click or do.
Still the question, 5 modules doing this on the same relay board, either there has to something exterior that causes this or the modules are of very poor quality, the 2 I have now are only few weeks old and are behaving like this.
I forgot to mention that just going to this page should factory reset your config files.
As for why its happening is difficult to say. If those config files are changed a lot or a bot is crawling the .sh files then it may trigger this issue. This is purely theory as this is the first I’ve come across this issue.
No, it did not reset the module, the same problem as before.
I managed to get the other module to work but only with DHCP. I had to to try to get it to work again since we use it at a daily basis when we are working in the field.
I now have 2 modules, one is among the 2 i ordered a few weeks ago that is constantly showing the 403 access forbidden error and the one thats active right now.
Can i send you those 2 modules to analyze?