Realtime desktop unreachable

[Paolo_Squillari]

Hi,

After I read this articles:

- http://www.ni.com/white-paper/2733/en

- http://www.ni.com/white-paper/8239/en
- https://decibel.ni.com/content/docs/DOC-10692

I verified the compatibility of my desktop according to: http://digital.ni.com/public.nsf/allkb/9209361E17708D548625744A007FF353 using a USB Drive. My hardware configuration has been validated; so I installed the "safe mode" according to step 2 of http://www.ni.com/white-paper/2733/en.

I connected a network cable from my desktop PC, using Device 1 - MAC adrr: 00:03:1D:0A:15:72, to a DHCP and the I rebooted (without USB drive); see image: Pict1.1.jpg.

The issues are:
1. Why does the system start in a "DHCP or Link local" like with the address: 169.254.50.127 instead of an ip in my subnet (192.168.1.100 - 192.168.1.255) (NI MAX doesn't find this host)?
2. Why, even if I use a cross over cable to connect my laptop (laptop ip: 169.254.50.126, subnet mask: 255.255.0.0) to the RT desktop, doesn't NI MAX find the RT desktop?

Note For this test I used NI LabVIEW 2012, NI MAX 5.4.

[Texas_Diaz]

The USB Flash Drive is only a shallow verification of whether or not LV RT will work on your hardware.  It's the 90% confidence factor, not a 100%.  The USB Flash Drive's evaluation mechanism attempts to load drivers for each core device and talk to each core device, but does not test to see if everything works together cohesively (it doesn't actually boot the OS for use).

Looks like you know that 169.254.x.y addresses are Link-Local, and you also know that the computer must have a Link Local IP in order to correctly talk, so thanks for that (so I don't have to repeat my usual speech).  Here's what is going through my mind:

1. Clearly the hardware is of the correct type, or else the network devices wouldn't have been discovered.
2. If you have a DHCP server on your network, the device/network-stack would have attempted to contact the DHCP server for an address.
• If the DHCP server isn't responding to DHCP requests, or the device is unable to talk on the network, the system uses a Link Local address mechanism.
3. Everything else seems to be working (at least on the surface).

So what it seems to me is that your device may be having a hard time communicating on the network.  There are a number of reasons this could be, so let's go down the list of usual candidates (let me know if any of these apply):

1. You're using a relatively new SandyBridge or newer Intel board with Intel 82577 or 82579 ethernet chipsets.
2. You have an off-brand Intel OEM network adapter (off-brand adapters sometimes use mostly-compatible PHY hardware with an Intel MAC).
3. The device is not plugged in (link/activity lights are not active).

Have you tried pinging the device from Windows?  

This could be a number of things, it's difficult to tell just from your description.  You're also using a 2012 USB key, and I don't remember if we fixed a number of bugs with newer hardware (issue #1 above) in that version of the key.  Try to use the 2013 USB Key (don't worry, it'll still work with older versions of LV)  - just download he ZIP, extract the whole thing to a directory on your hard disk, and run USBCreate.exe to put an image onto a USB key.  See if this works.

-Danny

[Paolo_Squillari]

Thank you for very fast reply!

My Motherboard is a commell MS-C72 (http://www.commell.com.tw/Product/SBC/MS-C72.HTM).
This motherboard has two LAN interfaces: Intel® 82574L integrated on the motherboard.

I don't know if the off-brand adapters use mostly-compatible PHY hardware with an Intel MAC.

The device has the link/activity led blinking.

I also tried the 2013 USB key and I got a new message using the Evaluate system option:
"Initialazing network...
               Unable to configure the primary network device."

I tried to ping the system (version 2012 and 2013), but in both case the host was unreachable.

[Texas_Diaz]

Very very interesting.  

The problem with 3rd-party hardware is that you never know what you're getting until you try to use it.  I'll be the first to admit we don't spend gobs of money testing every known hardware configuration, because it's just not cost-effective.  But I do have some starter tips for helping to debug what's going on.

The first thing I always do when I run into issues like this is set up WireShark to see how the device is attempting DHCP.  

1. The MOST THOROUGH way to do this is to have 2 ethernet NICs in your Host PC and enable a DHCP server on your secondary NIC.  Then, plug a crossover cable from the RT Target to the secondary NIC.  You can then use WireShark to sniff the communications between the Windows PC and the RT Target as it's doing DHCP; we can see if the target sends DHCP packets and we can see how the DHCP server is responding.  
2. If you don't have a second NIC in your PC, you can have a HUB (yes a HUB (which is not a switch or a router), or a MIRRORED SWITCH/ROUTER (this is a SWITCH or ROUTER with the port the RT target is on mirrored to the port the Windows PC is on).  If you don't use the correct hardware, you're only going to be able to listen to half the conversation.  If you don't know that there's a huge difference between a HUB, a SWITCH, and a ROUTER, and know what the differences are in their behavior to packets coming into the device, then save everyone the time and get yourself a second NIC card and go through the first option above.  Anyway, run WireShark in this configuration and you can get both the transmit and the receive side of the equation the entire conversation through.

Basically I'm wanting to determine if the driver seems to have a problem transmitting and/or receiving packets.  I expect to see the device attempt 3 times to transmit a DHCP DISCOVER packet before giving up and going to AutoIP, and then I expect there to be an ARP packet with the AutoIP address the target wants to use.  If the DHCP server is listening, I expect the DHCP server to send a DHCP OFFER message in response to the DHCP DISCOVER, and the target should hear the offer and send back a DHCP REPLY.  If the device is having a problem receiving packets, the device will continue to send DHCP DISCOVER until it gives up and drops to AutoIP.  

Can you try this and post the Wireshark log (.pcap) showing the communication?  Please do not filter the results.

-Danny