Problems moving project from MOD54415 to MOD54417

[mrmtdew2]

Using NBEclipse 2.7.1
The NNDK Platform is NNDK-MOD5441X-KIT; however, we have other NNDKs installed in the development PC.

We have an application that runs on a MOD54415 without any problems. It sends and receives UDP messages to another object using the UDPPacket class.

I loaded the application into a MOD54417. The first UDP message we transmit is lost. The message is never seen by Wireshark. If we wait approximately 10 seconds and transmit another UDP message then that message, and all following transmissions work.
I tried creating a new project from scratch. I added the same source to the project, compiled, and loaded the application into the MOD54417. Same problem.

So I suspect that
1) We need a separate NNDK for the MOD54417 (we did not receive a separate NNDK when we purchased the MOD54417), or
2) I am not "initializing" the MOD54417 correctly.

Can you verify or suggest alternatives?

[dciliske]

Are both interfaces connected to network? Are you running in switched or independent mode?

[mrmtdew2]

Both Ethernet interfaces, the device it communicates with, and the development PC (with Wireshark) are connected to a common Ethernet switch.
I don't know what you mean by "switched or independent mode".
Both Ethernet ports respond to Ping.

Additional testing with different applications have shown that I can transmit and receive just fine if I use different ports to transmit and receive on. However, if I try to transmit and receive on the same port then I have the problem I described earlier. This testing is done with a simple application very similar to the C:\nburn\examples\StandardStack\udp\UDPPacketClass (which transmits and receives on the same port).

Is there something special I need to do to transmit and receive on the same port when using a MOD54417?

[rnixon]

"Both Ethernet interfaces, the device it communicates with, and the development PC (with Wireshark) are connected to a common Ethernet switch. I don't know what you mean by "switched or independent mode"."

By "switch" he means the same thing as "switch" in your first sentence. The two Ethernet ports can act as a network switch, or they can be configured to be two independent Ethernet ports, each with it's own MAC address. Which mode do you need?

[mrmtdew2]

I need independent mode.

[pbreed]

Static or DHCP addresses?
Since both ports are connected to the same network how are you controlling what port the packet goes out of?
What happens if you add a 5 sec delay to your first send to give BOTH interfaces time to do DHCP?
(One of the differences is that you have two ports to finish negotiation not just one, this smells like a timing start up issue to me)

What happens if you ping the destination before sending the UDP packet?
(This diagnoses arp issues)

Given those potential issues, if your protocol can't handle loosing UDP packets
YOUR PROTOCOL IS BROKEN!, deploying it in the real world will be a disaster.

UDP IS BY DEFINITION NOT RELIABLE.

The Netburner may drop UDP packets if arp takes too long.
The Network infrastructure (such as smart switches) WILL randomly drop packets due to set up, path learning or buffer issues.
The PC network stack will drop UDP packets randomly depending on memory state.

TCP does a lot of work to recover from this normal network packet loss, UDP does not.
If you have a protocol that depends on UDP you must add some kind of acknowledgement and re-transmission.


Paul

[mrmtdew2]

FYI, the problem has been resolved. The IP addresses were always static. Now, one Ethernet connection is attached to a LAN and the second directly to another device using a crossover cable. Messages are now transmitted using UDPPacket::SendViaInterface rather than UDPPacket::Send. These two changes removed the Ethernet initialization delays.

SUGGESTION: add sample applications that demonstrate UDPPacket::SendVia, UDPPacket::SendViaInterface, GetFirstInterface, and GetInterfaceBlock. Add and/or improve documentation for those functions as well. IMO, one needs to use these functions to write applications for a 54417.

[dciliske]

We'll take those suggestions under consideration.

As for your solution, it doesn't sound like you have addressed Paul's comments. If your application fails if you lose data, and you have not built into your protocol some sort of retransmit capability, then using UDP will cause your application to fail at some point.

-Dan