NI Home > Community > NI Discussion Forums
Reply
Active Participant
Texas_Diaz
Posts: 261
0 Kudos

Re: Problematic fallback to link local - how to avoid?

The System Configuration API cannot dynamically reconfigure network settings - the network settings are not actually applied to the target until its next reboot (I should have been more clear, almost ALL possible network configuration is done at boot time, with the one exception of lease renewal).  What the System Config APIs do is set the proper values in the INI files, so that on the next reboot everything works as expected.  Therefore, when you set the IP settings they are not applied immediately, they are applied on the next reboot - if you find that DHCP doesn't work, you cannot then set the IP address and expect it to work immediately.

 

RT must have an IP address before it allows any application to run.

 

-Danny

Active Participant
Texas_Diaz
Posts: 261
0 Kudos

Re: Problematic fallback to link local - how to avoid?


Mads wrote:
I definitely want to request such a feature...but what is the proper channel?

There are two paths.  One is the idea exchange, which is where we get a lot of great user suggestions and turn them into features.  You can get to the Idea Exchange via http://www.ni.com/ideas and post your suggestion.  There is no guarantee that your idea will be implemented as a feature, it depends on how "popular" the feature is.  I will tell you that more investigation will need to be done before doing anything with your suggestion, as I can see a lot of problems with the initial idea - it needs to be fleshed out a lot more.

 

The second path is a Custom Engineering request, we can guarantee that your feature gets R&D face-time, but it's not free.  If you decide to do that, you must contact your sales rep for the area you're in, and they can help you with a custom engineering request.

 

-Danny

Active Participant
Mads
Posts: 1,318
0 Kudos

Re: Problematic fallback to link local - how to avoid?

Sure, the settings via the sysconf do not get applied immediately, but our app applies it then restarts..and voila, the controller has managed to "keep" the IP even though DHCP is down...But if it never launches the app this override never gets to kick in. We have this working, it just got stuck at one customer due to proxy Sep and the link local fallback.
MTO
Active Participant
Texas_Diaz
Posts: 261
0 Kudos

Re: Problematic fallback to link local - how to avoid?

Mads,

 

I was able to set aside some time and test this behavior, and I have it working.  The only difference is that you don't check the "Halt on TCP/IP Error" box.  If you set the ni-rt.ini token:

 

[IP_Settings]

no_LinkLocal=true

 

What happens in this case is if DHCP fails, you will get the message:

 

Initializing network...
Unable to configure the primary network device.

 

The primary network device will not be configured, but the System Config API can still see the network devices in the system (I didn't think it would be able to).  You can then use the System Config API to configure the network devices like you have been doing and it works the same.

 

Enjoy!

-Danny

Active Participant
Mads
Posts: 1,318
0 Kudos

Re: Problematic fallback to link local - how to avoid?

[ Edited ]

This sounds perfect, Ill test it tomorrow when I have the gear. But this possibility will be lost in 2012 you say?

MTO
Active Participant
Texas_Diaz
Posts: 261

Re: Problematic fallback to link local - how to avoid?

Yes, we added the "feature" in RT 2009 when we officially moved to supporting AutoIP (DHCP with LinkLocal fallback) and it's been 3 years since doing so with you being the first one who is documented as needing the mechanism to disable LinkLocal.  We are also doing a LOT of maintenance to the network infrastructure components for RT 2012, and this feature was "removed" from VxWorks and "not reimplemented" for PharLap - it doesn't make much sense to complicate our code base to keep in "what if" tokens and behavior that will not be used.

 

It is too late to re-add this behavior to RT 2012, but I have filed CAR 344502 to have this behavior re-added for RT 2012SP1.  You can watch the readme and release notes for RT 2012SP1 to see if the CAR makes it into RT 2012SP1, or reply back to this thread in November to keep it on our minds for RT 2012SP1.  

 

-Danny

Active Participant
Mads
Posts: 1,318
0 Kudos

Re: Problematic fallback to link local - how to avoid?

[ Edited ]

It took some more time before I could test it, but now I have done so and the results were not good;

 

I added the section:

 

[IP_Settings]
no_LinkLocal=true

 

to ni-rt.ini.

 

The result is that the RT Application never gets launched when DHCP is offline. Yes, it does not fall back to link local, but the end result is the same as when it did - status LED starts to flash 4 times indicating a crash and no app is launched (with APIPA it just crashed the same way, but then due to the proxy ARP conflict).

 

What I expected and hoped for was that it would launch the application. We would then get up and running, and access on the secondary NIC (we would for this particular app also get NIC 1 up and running because the application would automatically reconfigure it to use static IPs...but that's the longer story).

 

You mentioned that you had tested it, but perhaps you just checked that you could manually reconfigure it after such a bootup, not that it started the application, which could then reconfigure the NIC settings using the System Config API?

 

Or are there other keys that will have to be set? Is there e.g. andything in the TCP_STACK_CONFIG section that must must be changed or added, except for the Halt_On_Error which is set to False?

MTO
Active Participant
Texas_Diaz
Posts: 261
0 Kudos

Re: Problematic fallback to link local - how to avoid?

[ Edited ]

My test setup was as follows:

 

cRIO-9014

LabVIEW Real-Time 2011SP1

 

My test process was as follows:

 

  1. I built a startup application that queried the System Config API for the number of NICs present in the system and the MAC Addresses of those NICs, and printed the information to the console via the RT Debug String VI.  I built and deployed the application as a startup app. 
  2. I verified that the application ran successfully on our internal network (with DHCP present) when the target was rebooted.  
  3. I then added the token to the ni-rt.ini file using the Web Services silverlight client, rebooted, and verified that the application still ran successfully (no changes to the network).  
  4. I then unplugged the network cable from the controller, and rebooted the controller.  This simulates no DHCP present (the network drivers do not know the difference between a cable being unplugged and a perfectly quiet network).  I verified that the controller indeed booted, gave the error message I expected, and loaded the application correctly and gave me the correct information.

I did not attempt to use the System Config API to reconfigure the network settings, but if the startup app loaded and the System Config API can detect the network devices in the system then I considered it an exercise to the reader to complete the steps.

 

Does this not work for you the same way?

 

-Danny

Active Participant
Mads
Posts: 1,318
0 Kudos

Re: Problematic fallback to link local - how to avoid?

Different story here I'm afraid:

 

cFP-2220.

Fieldpoint 6.0.9 - Aug 2011 (LabVIEW Real-Time 11.0).

 

1. Installed a simple application that outputs data on the serial port - and used this to check if the application is started.

2. Added the nolinklocal key and verified that the Halt on TCP checkbox was unchecked.

3. Restarted the controller with NIC 1 set to DHCP and NIC2 set to static (the latetr not connected). - application started OK (data on serial port)

4. Disconnected the controller from the LAN and connected it to a laptop instead.

5. Restarted ->   No application started (no traffic on serial port), and status LED indicates that it has entered Safe Mode.

 

6. Reconnected to the LAN (with DHCP server) - boot up fine.

7. Disconnected again (no laptop) ----->>  Crash and safe mode again, no application launched.

 

The nolink key is definitely registered as it would otherwise go to link local, but it never launches the application so nothing is gained.:smileysad: Any ideas?

 

 

 

MTO
Active Participant
Texas_Diaz
Posts: 261
0 Kudos

Re: Problematic fallback to link local - how to avoid?

Can you post the output from the serial console?  I'd like to see if the system says anything "odd" when it cannot perform DHCP.

 

-Danny