NetBurner Community Forum

We are using NetBurner SB70LC modules to provide ethernet connectivity to our products. The products communicate via the EtherNet/IP industrial protocol, as well as Modbus/TCP, telnet, and http. So far, the NetBurner has been working like a champ. However, we recently experienced a new problem. It doesn’t appear to be a unit problem, because it persists, even when the module is swapped out for a new one.

The NetBurner module simply stops responding to ethernet communication at its fixed IP address. Inspecting the network with WireShark, we find that the module is suddenly sending ARP requests on the 169.254 “AutoIP” subnet. Funny thing is, we have enabled neither AutoIP nor DHCP in our NetBurner firmware.

Having discovered the NetBurner’s new 169.254 address, we are able to communicate with it, and inspect the IP settings. Interestingly, the static IP setting is still set to its original address. Rebooting the module sometimes restores communication on the original static IP address, and sometimes not.

Has this problem been reported before, and if so, are there any known solutions to it? If not, does anyone have any ideas on what could precipitate this behavior?

How are you verifying that the device still has the static IP? If you are using IPSetup and looking at what value it sends you for the settings, this is not necessarily accurate. IPSetup shows you what's in the ConfigRecord for the interface, not what's in the interface's actual settings.

AutoIP is automagically launched in builds after circa 2.6.5 (I think). It was added to simplify the situation of communicating in standalone installations with a direct connection to the device. It can be disabled by removing/commenting out the AUTOIP macro in predef.h.

As for what's going on: I would assume that someone is stomping on the primary interface's IP address somewhere, somehow, and since the primary interface is no longer routable, the system falls back to using the AutoIP address.

-Dan

Indeed, we are verifying that the static IP has not changed in the ConfigRecord. To your point, it is the interface’s actual settings that have changed (to 169.254.*). It sure looks like the AutoIP feature is kicking in.

I had been under the impression that AutoIP would not kick in, as long as a static IP was assigned, and DHCP was not enabled. That seems to have held true for all of our product installations to date, until this one. Apparently (as you suggest), something on the network must be stomping on the static IP address.

I am trying to imagine what mechanism could possibly stomp on the interface’s “live” IP address.

My first thought is a tool like IPSetup, but testing confirms that IPSetup reprograms the static IP address in the ConfigRecord, then reboots the module. The IP address in our problem installation is clearly not being reprogrammed.

I did confirm that our predef.h file contains #define AUTOIP, so the AutoIP function is likely enabled in our NetBurner library build. I am prepared to turn it off and rebuild it, but I suspect that will only make things worse. Once the “live” IP address is stomped on, the module will become incommunicado.

I am told a Schneider MDrive device is resident on the subnet, and that it may contain a NetBurner (but I am not certain of this). That could suggest that NetBurner IP config tools may be active on the network. Thoughts?

We bought near one hundred SB70LC in the past years and have a similar problem on one third. The units are working well for a while and stop communicating suddenly. Sometime a RESET is enough.
On my bench I have 2 units connected on the same Cisco router and I never experienced a single communication failure. Their addresses have been reserved in the router DHCP table. Of course, all "defective units" are installed in client facilities.

All units are programmed with the same software version: SB70LC-SshFactoryApp_APP.s19
Is it possible that making a DHCP reservation solve that problem?

Are you 100% sure that no other device on tha tLAN has the same address?

I had a customer problem where the DHCP server gave out week long IP leases,
but the store manager power cycled the router every morning....

So when everythign powerd up in the morning it gave out new addresses....

The NetBurner was not power cycled so it though it still had the 7 day IP lease it was given the day before...
Yet the router assigend that address to other devices....


Best solution to this is to use DHCP, and detect when you can't connect ... and reset the world automagically....


Paul

Yes I am sure that there is no other device with the same address.
Again this morning a SB70LC stop working. The IP Setup tool didn't see it, so I RESET the device and it came back on the Setup list showing the same IP address as before. Note that a RESET doesn't work all the time. This device worked for several weeks and always succeed to reconnect till this morning.

I asked NetBurner what can cause it..... I receive that it has to be debugg as answer.....

The problem is that I have 30 installed SB70LC programmed with NetBurner software having the same problem: disappearing from the LAN. My customers are not happy and I must stop selling the product.

NetBurner send me a new software version, it is on test, I will post results.

I tried several things to reproduce the problem without success.

Any idea will help. Thanks

Until you can reproduce the problem its going to be hard...

If ipsetup can't find it, then the number of possiblities is limited, IPSETUP is pretty low int he IP stack....


Step one monitor the count given by:
#include <buffers.h>

WORD GetFreeCount();

Is that number shrinking over time.... the world will die when it gets to zero...
If this is decreasing do you have ANY user written code doing things with UDP?


You might also monitor the value from
#include <bsp.h>
DWORD spaceleft();



Can you tell me exactly what your code is doing....