IP Bug ? Second IP connection attempt after a reboot will always fail.

Joe Hebert

The code posted below will demonstrate that the second IP connection attempt after a reboot will always fail and you will be locked out from using that port until it times out about 75 seconds later. No error is generated until the timeout occurs. It doesn?t matter what port numbers you are using (aside from port 1 of course which is used by the master) and it doesn?t matter what the port order is when you make the connections.

After you load the code below, open up the debug window and watch nIPOnline. At bootup it will read 0,0,0 indicating all 3 IP connections are offline. Goto emulate a device and push channel 1 to connect all three IP ports and push channel 2 to disconnect all three IP ports.

You will see that the first and third IPs connect and disconnect but the second IP will remain offline. If you wait about 75 seconds you will then see that you can connect and disconnect all three ports without a problem. If you reboot the master, the second port will again fail to connect.

A work around that I?m using for any program that makes 2 or more IP connections is to define a dummy device and use that dummy device to make the second IP connection to wherever, let it time out, and then not use that device/port in code anywhere else.

NOTE: I found this bug while working with an NI-700. I don?t know if this occurs on the rest of the NI series. I?m curious to know if it does.

Joe

(********************************************)
DEFINE_DEVICE

dvTP	= 10001:1:0
dvIP1	= 0:2:0
dvIP2	= 0:3:0
dvIP3	= 0:4:0

(********************************************)
DEFINE_VARIABLE

DEV dvIPs[] = {dvIP1,dvIP2,dvIP3}
INTEGER nIPOnline[] = {0,0,0}

(********************************************)
DEFINE_EVENT

DATA_EVENT[dvIPs] {
   ONLINE:  {nIPOnline[GET_LAST(dvIPs)]=1}
   OFFLINE: {nIPOnline[GET_LAST(dvIPs)]=0}
}

BUTTON_EVENT[dvTP,1] {
   PUSH: {
      IP_CLIENT_OPEN(dvIP1.Port,'amx.com',80,IP_TCP)
      IP_CLIENT_OPEN(dvIP2.Port,'amx.com',80,IP_TCP)
      IP_CLIENT_OPEN(dvIP3.Port,'amx.com',80,IP_TCP)
   }
}

BUTTON_EVENT[dvTP,2] {
   PUSH: {  
      IP_CLIENT_CLOSE(dvIP1.Port)
      IP_CLIENT_CLOSE(dvIP2.Port)
      IP_CLIENT_CLOSE(dvIP3.Port)
   }
}

(******************THE END*******************)

Dries Kaspers

I couldn't recreate your problem with my NI-3000 (latest firmware). all three connections open and close at the button pushes.

Joe Hebert

Thanks for the feedback Dries. I wonder if it's just an NI-700 issue. I've got the latest firmware loaded in it.

If you wouldn't mind (or anyone else) can you try the code I posted at the following thread and see if you can duplicate it with your NI-3000?

NI-700 ? UDP input buffer bug

Cheers,
Joe

Dries Kaspers

I loaded the code from your other thread in my NI-3000 and it behaves the same way you described, so no difference there.

While i was testing i found a strange netlinx studio issue. I had a debug window open and when i rebooted the master controller i saw that debug wasn't closed automatically.

So i went to the debug tab, selected stop debugging (while the NI was rebooting) , which closed my studio application without warning.

Joe Hebert

Thanks again, Dries. So the UDP problem seems to be for the NI series in general but the IP connect issue appears to be only for the NI-700. Does anyone have an NI-700 that can verify what I saw?

I had the same exact experience with Netlinx crashing as you described. Attached are the error messages.

Joe Hebert

Error #2 before Netlinx crashed

Reese Jacobs

NI-700 - IP Bug

Joe,

I have an NI-700 here at home and I will try to re-create your problem scenario on it in the next couple of days and get back to you with the results.

Dries, regarding the problem with Studio crashing after a reboot with debugging still enabled, I have run into the same problem when rebooting while 'Diagnostics' or 'Notifications' are still active. It appears that Studio still thinks the connections to the Master are still open for Debugging, Notifications, or Diagnostics after the reboot and crashes as a result. I have yet to report the problem to AMX since it is more of an annoyance than anything else. Just wanted to let you know it occurs with other items enabled than just Debugging when a reboot occurs.

Reese

Reese Jacobs

NI-700 TCP Connect

Joe,

I am sad to report that my NI-700 worked just fine with your 3 IP connection test program. Each of the three connections was established successfully each time. I did several iterations using button presses 1 and 2 to cycle through the connection group and each time all three successfully connected and then disconnected.

Firmware is 2.95.214.


Reese

Joe Hebert

Hi Reese,

I wonder what is different with my setup from yours. I?ve got the same firmware as you have as you?ll be able to see from the Netlinx system log file that I've attached. I notated the log file regarding when I pushed the connect and disconnect TP buttons. I can reproduce this anomaly at will with the NI-700.

Just to repeat ? this only occurs after a reboot and the very first time you attempt to make the second IP connection and during the 75 second timeout period for the second IP connection attempt. After that I can connect and disconnect at will.

Do you (or anyone) have any idea why I?m seeing what I?m seeing? The log file is attached as an image and the notes (and file) are to be read from bottom to top.

Thanks in advance,
Joe

Reese Jacobs

IP Bug - NI-700

Hey Joe,

I knew you would be disappointed in my results. However, I will try again this afternoon to ensure I was within your timing windows. I am confident I did the test just after reboot and it succeeded but I will try again to be sure.

If in fact mine does continue to work and your NI-700 does not (as appears the case), I am at a loss to explain the reason. I can tell you that 75 seconds is an interesting number since that happens to be the default TCP Keepalive time interval at which Keepalive probes are sent out. Typically though the TCP Keepalive capability requires 10 failed probes at 75 seconds before declaring the counterpart of the connection to be dead but these values are configurable. Having been looking at TCP connections and Netlinx recently including how Keepalive might be useful in the Netlinx environment because of shutdown issues and open TCP connections, I encountered the magical 75 second default time. Not sure if this means anything in your environment or not but I thought I would put it out there for thought.

I will post results for you later today on the re-test.

Reese

Reese Jacobs

NI-700 IP Bug - Confirmation of Test Results

Joe,

I re-ran the test several times on the NI-700. Immediately following reboot, I emulated button press 1 and watched all 3 connections come online. I then disconnected them using button 2 and repeated the entire process of connecting and disconnecting probably a total of 5 times within 2 minutes of booting the Master. Each time, all 3 connections were successful.

Don't know what else to tell you except that my NI-700 seems to be behaving as you would expect. Let me know if there is anything else I can try for you.

Reese

Joe Hebert

Hey Reese,

Just to clarify, it doesn?t matter when you perform the test after a reboot. It can be 10 seconds later, 10 minutes later, or 10 hours later for all I know. All I do know is that the very first time I push TP 1 (whenever that first time happens to be and it doesn?t matter if it?s via emulate a device or with a real TP), the first and third connections are always successful and the second connection always fails.

I sure am curious as to why I see different results with my NI-700 than you see with yours since we both have the same firmware. The Netlinx system log that I posted verifies that I?m not hallucinating and I can recreate the problem at will. I assume your Netlinx system log shows none of the errors that mine does. I believe my NI-700 is from one of the first shipments because I ordered mine well before they were available. I don?t know if that should have anything to do with it. I do find it hard to believe that I?m the only one but stranger things have happened.

I think I should rename this thread to: Joe?s NI-700 IP Connect Bug ? Who Cares?

One last stab at it: We have confirmed our Masters have the same firmware. What do you see on the online tree for the NI-700 itself. Mine reports as v1.01.124. I looked in the firmware section on the web and I don?t see a listing for the NI-700 itself so I don?t know if it?s upgradeable or if it?s a totally integrated system.

Thanks for the feedback.

Later,
Joe

Reese Jacobs

IP Bug - NI-700

Joe,

Don't know what to tell you - I woudn't say no one cares but I don't have a lot of suggestions for you.

I left the master booted and ran the tests at different times with success every time.

Here are the details:

- Master f/w: 2.95.214
- NI f/w: 1.01.124
- Serial #: 210503P3540344

I know with other NI controllers there is a firmware download for the Master and for the Integrated Controller. However, like you, I have only seen a Master firmware upgrade for the NI-700 and nothing for the Integrated Controller. It looks like both of our controllers/masters are consistent in terms of the lastest firmware downloads.

Mine came from an early batch also since I pre-ordered long before they were shipping. Let me know if I can check anything else for you.

Reese

Joe Hebert

Thanks Reese. That should do it. I can?t think of any more angles of attack. I have a work around for it so it will just have to be left as an unsolved mystery.

Joe