> I have now played with the wireshark.
>
> I do not get what you suggest "ICMP destination unreachable packet"
> or something similar. The only "ICMP" protocol related is when I
> connect the device and setting up the ip address, but no "unreachable
> packets" or similar during the uhd run. When running there are only
> UDP frames/protocol.
>
> Instead, however, I discovered some really suspect behavior with the
> ports changing wildly back and forth on both the device and host, and
> UDP packet/frame size then change much too. This happens both in the
> beginning of the streaming (see attached packets 241--287), then
> after a while it settles to the requested (constant) packet size
> (3050 bytes, close to the requested 3008 bytes) and the ports becomes
> fixed (see packets 1271-1277) .
>
> But then in the end, when it all fails, the ports on the device and
> host suddenly change again and the packets becomes very small, like
> 58 or 60 bytes only (see packets 211078 --). The little actual data
> in those failing packets seem quite odd too.
>
The packets in the dump all look quite normal. If it helps, here is the
mapping for the ports from fw_common.h
#define USRP2_UDP_CTRL_PORT 49152
//#define USRP2_UDP_UPDATE_PORT 49154
#define USRP2_UDP_RX_DSP0_PORT 49156
#define USRP2_UDP_TX_DSP0_PORT 49157
#define USRP2_UDP_RX_DSP1_PORT 49158
#define USRP2_UDP_FIFO_CRTL_PORT 49159
#define USRP2_UDP_UART_BASE_PORT 49170
#define USRP2_UDP_UART_GPS_PORT 49172
> Please find the transcript of the mentioned and seemingly crucial
> packages from the beginning and the end when the UHD communication
> fails. Note the selected packets' numbering. The wireshark captured
> the command: uhd_fft -a "addr=192.168.10.2, recv_frame_size=3008" -s
> 25e6
>
Is the behavior any different when the recv_frame_size is
unspecified/aka left default MTU?
Another question, what the app locks up, what makes it recover? Reload
app, power cycle user, replug eth cable, re ifconfig, restart PC?