udp fread issue

I am sending data through ethernet from my pc to a virtex 6 fpga board. I am able to save the data in the fpga perfectly. Now I am having problems reading back data when needed. here is my matlab code:

u = udp('192.168.1.255','localport',9091,'remoteport',7,'timeout',15,'DatagramTerminateMode','off','timeout',15,'inputbuffersize',1200,'outputbuffersize',1200);
fopen(u);
fwrite(u,dataout,'uint8');
read= fread(u);

but read comes back empty and the following error message is seen:

Warning: The specified amount of data was not returned within the
Timeout period.

any help would be great! thanks!

Answer 1

[Walter Roberson]

You turned off datagramterminatemode, so fread() is not going to look for any kind of terminator. Instead it is going to look only for timeout or for the input buffer to be full. You have set that size to 1200, so if you do not receive 1200 bytes of data before the timeout (15 seconds) then you are going to get that warning message.

[Walter Roberson]

I note that you are using udp port 7. That port is, by convention, used for the ECHO service, http://tools.ietf.org/html/rfc862 and the ECHO service would not save the data at the other end (though I guess it isn't prohibited from doing so.) Are you attempting to create an ECHO service, or was it just by chance you used that port number?

ECHO is intended to respond datagram by datagram, and the design is intended for datagram mode such as is discussed at http://msdn.microsoft.com/en-us/library/ms881658.aspx with ends using network library recvfrom() and sendto() . Are you using pre-written software on the fpga side, or do you have access to the source code?

I would also be concerned about whether the fpga knows its own address; see the remarks at http://msdn.microsoft.com/en-us/library/aa450870.aspx

I would recommend that you turn on a network sniffer and watch the packets in detail; remember to set the sniffer to pay attention only to that one network interface.

[matthew martinez]

Here is an updated version of the code:

u = udp('192.168.1.255','localport',9091,'remoteport',9090,'DatagramTerminateMode','off','inputbuffersize',1200,'outputbuffersize',1200); 
f= udp('192.168.1.10','localport',9090,'remoteport',9091,'DatagramTerminateMode','off','inputbuffersize',1200,'outputbuffersize',1200); 
fopen(u); 
fwrite(u,data_out,'uint8'); 
read=fread(f); 
fclose(f); 
fclose(u);

1) I used port 7 because the previous programmer used this port to write data to fpga

so really it is just by chance by my knowledge.

To answer your other question, I am using wireshark, although I am new to the program,

and to network protocol for that matter. wireshark showed an echo protocol of my fwrite() and also

shows an echo with the data from the fpga that I am trying to acces. This means that

the data was sent out from the fpga as an echo but I am not getting it back in matlab.

You were correct, after changing the port away from 7 it no longer says echo in wireshark

as it did previously now the protocol is udp in wireshark. Is there a port you would recomend?

I changed it to 'localport' 9090 and 'remoteport' 9091 so far this hasn't solved the problem though.

2) I dont know if we want to use echo or not, anything that would revieve all the data from the fpga

is fine, but it sounds like echo servers only send back the data you sent out.

I do have acces to the source code and I do believe it is working since the correct data is output

but I can only see it in wireshark nothing is recieved in matlab. It says that the source is 192.168.1.10 and destination is 192.168.1.255.

3) I was also wondering if the fpga knows it's adress and how to find it. The links you sent shows a way to find the adress in CE. Is there a matlab function that would help me find the adress?

[matthew martinez]

slash that last part, I understand what you mean now. I am not sure if the fpga knows its adress and this could be the problem. If this is the case, how should I proceed?

[Walter Roberson]

Destination address 192.168.1.255 is probably not right. It is not _definitely_ wrong, but it is incorrect as a response packet. 192.168.1.255 would be the "broadcast address" for the 192.168.1.x network, and MATLAB would definitely not pick up on such packets as a reply.

It is unlikely that you want to be using 192.168.1.255 as your destination address for "u". You should only need to open one socket (sockets are bidirectional) and that should be like the one you use for "f".

There is a standard that reserves ports in the range 1025 to 32767, but that isn't followed all that much. Anything from 1025 to 65535 as the port number should be okay provided there isn't already something running on the port and provided the two ends agree. The port on the client (the MATLAB program you show above) does not need to be agreed to ahead of time: the server will read the sender's port number out of the packet and reply to it. The port on the server _does_ need to be agreed upon.

I'd say remove (comment out) your "u" and write to "f".

Say, did you notice that you didn't fopen(f) in your code? Can't read from a port that isn't open.

[matthew martinez]

o ya I'm not sure how the fopen didnt get in there but it was in my code. when I use 192.168.1.10 i get back the data that I wrote into the read! at least now I am getting something but I am not getting the correct data back. is there a different adress I should use for getting the data back? By the way, thank you sooo much for your speedy responses. Can't tell you how much I appreciate it..

[matthew martinez]

to be more clear, I am getting the data back that I sent out and not the data from the fpga. This was using 192.168.1.255 which makes sense because it is the broadcast and im just getting back what I sent out. Is there a different adress I should use get the data back. The adress 192.168.1.10 reads nothing and I dont see any wireshark pickup on protocol when this adress is used.

[Walter Roberson]

Could you show your current code? And also indicate what WireShark sees for the addresses and ports for the outgoing packets (and response packets if you are getting any)

You should probably not be using 192.168.1.255 for anything. There are uses for it, but not in this context.

[matthew martinez]

%u = udp('192.168.1.255','localport',9091,'remoteport',9090,'DatagramTerminateMode','off','inputbuffersize',1200,'outputbuffersize',1200,'timeout',50);
f= udp('192.168.1.10','localport',9090,'DatagramTerminateMode','off','inputbuffersize',1200,'outputbuffersize',1200,'timeout',50);
pre=36*ones(8,1); %%%for 16-bit data this is an 8-byte long sequence of "$"
post=126*ones(8,1);
x_out=zeros(64,1);
data_out=[pre;x_out;post];
%fopen(u);
fopen(f);
fwrite(f,data_out,'uint8');%%needs to be uint16 for final
read=fread(f);
 %fclose(u);
 fclose(f);

This has no wireshark output when ran. I used the broadcast server to broadcast the signal and it shows on wireshark. Is there no way to read from the broadcast in matlab? the data that I need it seen in the brodcast...a series of 64 "3e". Here is the wireshark image when 192.168.1.255 is used.

http://i47.tinypic.com/2rzcufo.jpg

[Walter Roberson]

You need the remoteport to be specified in the client (the one initiating the connection.) If it is defaulting to 0 then you would not get any output packets.

Ummm, the 192.168.1.10 in the udp() call needs to be the address of the destination. Your wireshark trace is showing that you are using that as the address of the source -- you have configured that as the IP address of that ethernet adapter. Right-click on the adapter icon (in Windows) and adjust the properties. If the IP stack thinks that the packets are destined for the same machine that sent them, then the packets might not go into the queue to be sharked.

=====

As an enhancement: consider building your data as uint8:

pre = 36*ones(8,1,'uint8'); %%%for 16-bit data this is an 8-byte long sequence of "$"
post = 126*ones(8,1,'uint8');
x_out = zeros(64,1,'uint8');
data_out = [pre; x_out; post];

This will not change the data that goes onto the wire, but it makes it clearer to the reader that you are not planning to do things like send all 64 bits of the floating point zero() array you construct.

[matthew martinez]

thanks I see what you mean, I specified the remoteport as 9091 now. I am confused about the 192.168.1.10 adress. I see it is configured to the network but I am unsure how to change it or what I would change it to. I dont see an option to even change it if I wanted to. And If I do change it, I need to make it the destination not the source and maybe it is the source but wireshark isn't picking up that network.

Thanks for the advice with the data to uint8, I changed them to your suggestion.

Right now, i'm getting nothing back from read.

[matthew martinez]

also, why am I unable to read from the broadcast adress.

[Walter Roberson]

The IP address of the adapter on the MATLAB system needs to be in the same network as the IP address of the fpga, and it must not end in .0 or in .255 (well, those aren't _always_ impossible, but at this level they are.) The address must also not be the same as the IP address of the fpga.

It is the IP address of the fpga that needs to go into the udp() call.

To change your IP address, see http://windows.microsoft.com/en-us/windows-vista/change-tcp-ip-settings and use the fixed IP address variation.

[Walter Roberson]

Servers are not required to pay attention to broadcast packets (though they often do.)

Your fpga might not be on the same IP network as your ethernet interface, so those packets might not be broadcast packets as far as the fpga is concerned.

Sending data to a broadcast address is intended to be a privileged operation. It appears that your system is allowing it anyhow.

You cannot specify the broadcast address as the IP address to listen to because it is not valid for packets to use that IP address as their source address. (I've seen it happen, but it _is_ formally disallowed.)

[matthew martinez]

Thanks this is perfect but is there a way to find the ip adress of the fpga? and I would set it up like

f=udp('fpga ip', 'remoteport', 9090, 'localport', 9091); ...?

[Walter Roberson]

You can only find the IP address of the fpga if it cooperates (or is a little broken.)

There are some circumstances under which you can find its address if you do not know the IP network already (major one: if it implements a DHCP server; other methods pretty much rely on weaknesses in network implementations.)

If you already know the correct IP network, then if it is cooperating, you send an ICMP ECHO packet to the broadcast address, and it might reply. This ICMP ECHO is not the same as the UDP ECHO we were discussing above. And unfortunately it appears to me that the Instrument Control Toolbox does not support ICMP packets, so you might have to start a system() command and parse the output. If, that is, you want to do this automatically; otherwise just

!ping 192.168.1.255

(complete with '!')

See http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ping.mspx

MATLAB does not itself implement any way to discover the address. Your FPGA development kit might use a documented default address, though.

[matthew martinez]

maybe !ping iswindows xp? the command is not recognized in windows 7 cmd

[Walter Roberson]

The ! is only used inside MATLAB.

[matthew martinez]

so I have an update. My boss says that if wireshark can capture the fpga data output then so should I...which makes sense. I continued to struggle with reading from the broadcast adress. Now I used arp -a to find the adress of my fpga and I used arp -s to change the adress from 192.162.1.10 to 192.168.1.18 just to avoid wireshark problems. also changed my ip to 192.168.1.3...now I still get nothing in udp...i only recieve the data back that I sent out with the zeros rather than the 3e. i tried using the ip from the fpga, the broadcast and reading from the ip of the fpga and any other combination just to be safe...and still I get zeros...any advice? I feel that it may be a port problem. wireshark shows that the data is not reaching the destination, but I am confident in the ip of the fpga. here is my code:

clear all
clc
close all
%u = udp('192.168.1.18','localport',9091,'remoteport',9090,'DatagramTerminateMode','off','inputbuffersize',1200,'outputbuffersize',1200);
f= udp('192.168.1.10','localport',9090,'remoteport',9091,'DatagramTerminateMode','off','inputbuffersize',10000,'outputbuffersize',10000);
pre=36*ones(8,1,'uint8'); %%%for 16-bit data this is an 8-byte long sequence of "$"
post=126*ones(8,1,'uint8');
x_out=zeros(64,1,'uint8');
data_out=[pre;x_out;post];
%fopen(u);
fopen(f);
fwrite(f,data_out,'uint8');%%needs to be uint16 for final
read=fread(f);
 %fclose(u);
 fclose(f);

[Walter Roberson]

Remember, u is commented out, so you are still using .10 as your IP address.

What IP address is showing up for the fpga ?

[matthew martinez]

it was coming up as 192.168.1.10 and i tried changing it to 192.168.1.18 i tried using both of these

[matthew martinez]

I saw in another post that the checksum was set to x000000(none) and his problems were solved...would this work for me and how would I achieve this. Where is checksum esatablished?

[Walter Roberson]

Could you post an example of the wireshark capture of the outgoing packet and the capture of the response packet?

[matthew martinez]

http://i46.tinypic.com/2a7v4sj.jpg

[matthew martinez]

doesnt seem to reach the fpga as there is no repose seen

[Walter Roberson]

I'm not sure where the 3e were coming from before; you are constructing 0's for the middle, so it should be 0's.

I do not see anything obviously wrong with the outgoing packet. There doesn't happen to be enough shown for me to have a look at the checksum. If you click on the + beside Ethernet or beside Internet Protocol it might show you additional information.

Is there evidence that the fpga is alive and listening to that particular ethernet port? For example can you go on to the fpga and ask it to ping 192.168.1.3 ?

Is the ethernet port shared with your general network connection? If not then you should go into the network properties and turn off DHCP and Microsoft Networking (NETBUI?), as those are generating unneeded packets. Which the fpga _should_ ignore, but no need to confuse things.

[matthew martinez]

The fpga is set to fill the 0000 with 3e3e3e3e...before, I saw the 3e sent out in wireshark using the broadcast adress...now I see nothing

[matthew martinez]

and it is not shared with the general network

[matthew martinez]

lso checksum says correct in wireshark...I really can't figure this out...driving me nuts...

[Walter Roberson]

Hmmmm... could you try an experiment in which you leave your MATLAB machine set to 192.168.1.3, and leave the fpga set to 192.168.1.18, and in your code change the udp destination to 192.168.1.255 ? Also, for this experiment, please have the localport and destination port different from each other (by setting the local port)

[matthew martinez]

heres picture: http://i48.tinypic.com/30iw8it.png

code:

clc
close all
%u = udp('192.168.1.255','remoteport',9090,'DatagramTerminateMode','off','inputbuffersize',1200,'outputbuffersize',1200);
f= udp('192.168.1.255','DatagramTerminateMode','off','inputbuffersize',10000,'outputbuffersize',10000);
pre=36*ones(8,1,'uint8'); %%%for 16-bit data this is an 8-byte long sequence of "$"
post=126*ones(8,1,'uint8');
x_out=zeros(64,1,'uint8');
data_out=[pre;x_out;post];
%fopen(u);
fopen(f);
all_con = instrfindall;
fwrite(f,data_out,'uint8');%%needs to be uint16 for final
read=fread(f);
 %fclose(u);
 fclose(f);

wireshark picked up the output from the fpga still...I'm starting to think that maybe the fpga is listening on the broadcast adress rather than its ip adress...

[matthew martinez]

and sorry, forgot to run with the reomteport set...I did this with the same results...fread() comes out empty...wireshark picks up on both

[Walter Roberson]

Sorry I need to see the run with the port numbers set explicitly and set to different values (and I need to know the two values)

Please re-check the IP address that is set for the fpga.

The packet you show has some unexpected properties that the ports should help me to resolve.

[matthew martinez]

I rechecked it is 192.168.1.18 I used arp-a.

pics:

http://i49.tinypic.com/vzgcn6.jpg

http://i45.tinypic.com/30m3kox.jpg

and from sending side

http://i47.tinypic.com/30cr9rk.jpg

hope this is what you need...please let me know and ill send you anything else

[Walter Roberson]

Odd....

I need to know which port was set as local on the matlab side, and which was set as remote?

[matthew martinez]

9091

[matthew martinez]

and 9090 as local

[Walter Roberson]

I cannot say that I am certain, but it appears to me that the fpga is badly messing up the packets.

I think when the broadcast packets reach it, it is responding, but instead of putting its own MAC address (ethernet address) into the packet as the source, it is simply exchanging the source and destination MAC addresses, leaving the rest of the header alone (including leaving the IP addresses alone and leaving the ports alone), but it is changing the data to 3E as you expect.

The MATLAB side is probably ignoring the response because (A) the MAC address of the source is invalid; and (B) it knows that its IP address is not 192.168.1.255 and that the packet is not a broadcast packet. Or possibly just (B) alone. Then after that if it _had_ let the packet through it would have tried to deliver it to the wrong port -- but that is something that could be worked around by using the same source and destination port numbers. The fact that you received no response when you were using the same source and destination ports tells me it is likely to be either (A) or (B).

The entire IP stack for the fpga might be messed up. Or, possibly more simply, when the packet comes in, the code that is processing the packet and changing the 00 to 3E is not doing the work of switching the fields. Switching the fields is done automatically in standard network libraries, but since the fpga might not be running a standard network library, possibly the code has to do it explicitly.

The problem with no response except to the broadcast address: I can think of more than one possible reason for that. If we stick to the ID that the source and destination MAC are switched around but the other headers are not being constructed properly, then although the destination MAC ought to be right, with the other headers wrong (e.g., the IP address of the destination would be its own IP address), it could be that the fpga is discarding the packet before it gets out of the network connection. This is a hypothesis, but I don't think it is an especially strong one.

I think my step after that would be to load in nmap from http://nmap.org/download.html

and ask it to scan 192.168.1.18 fairly thoroughly, including a specific scan for udp port 9000 to 9999. I would do this with wireshark running in order to see what (if any) response packets came back even if those response packets were corrupt. (nmap will report on returns that it can understand but that depends on the packet getting back to the right place!)

If nmap says that the host is down, then nmap the entire subnet and see if anything happens.

[matthew martinez]

Yes, looking into the data sheet, the mac addresses are switched on the fpga side although I'm not sure what happens with the ip address. I tried to ping the fpga and it had zero response. also, a weird artifact, when I turn the fpga off, I get two sets of the same data read back into matlab. Again thanks for your help.

[matthew martinez]

I was considering writting something in C and trying to see if I would be able to read in the data that way, what do you think?

[Walter Roberson]

If you do use nmap and the host will not ping, then you may have to use a specific option to force nmap to continue anyhow.

[Walter Roberson]

C will not have any more success if the fpga is simply not responding.

You can see from Wireshark that the packets are going out towards the fpga and appear to be valid. I would think it quite unlikely that the MATLAB level is introducing a bug in the packet, as MATLAB is almost certainly invoking the same standard network libraries that C would call upon.

The nmap people also make ncat which allows you to flexibly build individual packets. See http://nmap.org/ncat/

[matthew martinez]

I was thinking about reading the broadcast adress in C and seeing what I can get and sending the packet from matlab

[Walter Roberson]

Hmmm, messy. You would need to socket() AF_INET SOCK_RAW

http://sock-raw.org/papers/sock_raw has some fairly dense technical details. There must be something around with a better overview.

(My university days predate TCP/IP being finalized...)

[matthew martinez]

just a little update, I decided to make a change in the source code...The destination and source were being swapped on the fpga side so that the source becomes the destination and the destination becomes the source. I decided to hardcode the computer adress into the destination and try to read from that adress without luck...Also tried using the fpga adress for the source so that the comp might accept the message since it recognizes the source. Still no luck but going to try some more changes on the fpga side if you have any advice it would be greatly appreciated.

Answer 2

[matthew martinez]

Thanks, your probably right, but I'm more concerned with reading the data from the fpga. I'm getting nothing from fread after writing I should get dataout back. I checked the fpga side and I am getting the correct output. I just cant recieve it back into matlab.

[Kavya Managundi]

https://www.engr.mun.ca/~oscar/wp-content/uploads/2015/01/tutorial_Data_communication_matlab.pdf

I think this is of some help here.

[YONG LI]

now,I use TCPIP to receive data from the FPGA and the display is empty.display warning:The specified amount of data was not returned within the Timeout period.'tcpip' unable to read any data. For more information on possible reasons, see TCPIP Read Warnings.

[Walter Roberson]

YONG LI please create a new Question for this, and please post your code there, and also please post wireshark traces showing what packets are being exchanged with the FPGA. If possible, please use a separate network interface to talk to the fpga, so that the rest of your network traffic is not mixed in.