04-03-2012 05:04 PM
Well, Ruby was running first, so I can't imagine it would report an error. However, I think LabVIEW only had a timeout error and not a connection error.
Although, now you have me doubting myself. I'll rerun and check the error tomorrow.
04-04-2012 09:10 AM
Windows 7 32 bit
Intel Core i7
Gigabit (10/100/1000 Mbits/sec) Dual LAN subsystem using the Intel 82567L and Intel 82574L Gigabit Ethernet Controllers
(a handful of other cards, but nothing of consequence)
Right now, we're communicating with our unit which is an FPGA using one of the motherboard ports.
04-04-2012 09:46 AM
Is it possible to get the unit to calculate the UDP checksums? Usually this is offloaded to the NIC, but your hardware may be different. UDP checksum of 0x0000 *should* indicate disabled, but maybe that's not being acknowledged.
04-04-2012 10:02 AM
Correct, the hardware does have an offload option. I have tried both enabled/disabled. Although I had previously thought this was for sending only. Does it have an option for verifying received checksums?
Everything the unit sends has the IP checksums, but no UDP checksums. Wireshark doens't seem to see a problem with this.
04-05-2012 11:39 AM
Unfortunately, I need the net address to specify the card I'm using. This computer has 6 ports. 4 will be used for GigE Vision, and 1 is this custom interface.
According to the LabVIEW Help for UDP Open Function:
net address specifies on which network address to listen. Specifying an address is useful if you have more than one network card, such as two Ethernet cards, and want to listen only on the card with the specified address. If you do not specify a network address, LabVIEW listens on all network addresses. This function broadcasts only on the default network address.
If you are attempting to broadcast on a specific adapter, you must make that adapter the default in your system. Specifying the net address does not specify which card to broadcast on, only on which card to listen.
In your case, it seems you should leave net address unwired. If you do so, do you still receive a timeout error?
04-05-2012 12:48 PM
Same result with no address wired.
The "only on default network address" disturbs me a bit. Later in this project, I hoped to be transmitting simultaneously out of all ports. Does that mean that it will just send out of the port the destination is registered (arp tables) on?
Back to my problem and what I've tried:
1) A seperate laptop running XP and a Ruby program was sending UDP packets to my program. All packets were received
2) LabVIEW program running on windows XP talking to the unit. Nothing was received.
3) We used an ethernet tap to monitor the activity... I'm analyzing now
Really, I'm starting to think that something in the packet is causing it to get dumped by the card/windows/LabVIEW drivers (yet somehow still get to wireshark). Nothing has seen the packets coming from the unit (except wireshark).
04-05-2012 01:43 PM
Yes, transmit will always be according to the routing tables.
I don't know a lot about wireshark, but I assume it's hooking into the network stack at some much lower level and reading raw packets before the operating system has a chance to do anything with them. Your LabVIEW and Ruby programs are both relying on the operating system to pass packets to them, so if the operating system sees the packets as invalid and drops them, you'll never get them regardless of programming language.
04-05-2012 02:04 PM
Good to know. So if I have multiple ethernet ports and windows doens't know where a destination is, it will poll each until it finds the destination?
Ok, that was my assumption but I'm REALLY new to networking. Thanks.
Since it's probably in the windows layer, should I take this question somewhere else, or does someone have an idea of where to look?
04-05-2012 04:42 PM
Some LabVIEW specific questions, if the UDP Checksum (not the IPv4, or ethernet) is invalid. Will LabVIEW report it with a read?
If the checksum is 0x0000, will LabVIEW follow UDP protocol and ignore the checksum?