Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

UDP sendto() problems

Altera_Forum
Honored Contributor II
1,275 Views

Hi, 

 

I'm having some strange problems with sending udp data using sendto() and was wondering if this is a known issue?  

 

I currently have multiple tasks running network applications, 4 tcp/ip sockets sending and receiving on multiple ethernet interfaces, as well as three UDP sockets using recvfrom() to receive packets. However, I'm unable to send data using sendto(). It's not a software problem as I've tested the very same network code in several linux distros and it works as expected. 

 

One really strange thing I've noticed is, if I create a recvfrom() before the sendto() and send a packet from the application waiting to receive, then the application on the board actually does send to the host over the specified port, but only when this is done.  

 

My platform looks like this, 

 

Cyclone-III Dev board 

Nios II processor 

Iniche network libraries 

uC/OS-ii  

 

Thanks for any help in advance! 

Drew
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
347 Views

Maybe an ARP problem? 

Responding to the ARP request (sent from the remote system before it sends the datagram) may wll add an arp table entry on the fgpa. 

If true, then a ping is also very likely to be enough.
0 Kudos
Altera_Forum
Honored Contributor II
347 Views

Ok, I'll try to ping from the remote and see if I get the same result. I think you may be right and something is going wrong with the ARP request and reply. I'll also try to monitor the network traffic.

0 Kudos
Altera_Forum
Honored Contributor II
347 Views

I should have mentioned previously that I'm communicating with the dev board using a Centos VMware Player appliance. Using Wireshark, I've confirmed that the UDP packets are being read in correctly by the host Windows OS, but they never reach the VM. It seems there is a routing issue between the two.

0 Kudos
Reply