<<Another question, what the app locks up, what makes it recover? Reload app, power cycle user, replug eth cable, re ifconfig, restart PC?>>
In my case, I had to press ctrl+C and then restart the code to make it work. Thanks, Nazmul On Tue, Nov 27, 2012 at 1:13 AM, Josh Blum <j...@ettus.com> wrote: > > > 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? > > -josh > > _______________________________________________ > USRP-users mailing list > usrp-us...@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
