Hi Kieran, Thanks for the help. I had not noticed the change in connection number. I had tried various combinations of disconnect/shutdown after each data transfer on the client end (XP). With no disconnect/shutdown, the system seems to work for a few seconds, then a lot of RSTs, an occasional UDP request and then a few good transfers.
This is all when the client is connected to the Microblaze server. I have just reconnected the Netburner server and it runs like clockwork (and much faster) against the same client. Each time the client starts a new transaction a new port number is used but there are no other changes. The Netburner uses a Coldfire 5272, with uCos and an Etherenet stack that I think was written by one of the Netburner founders but I am not sure. I really do hope that I can get some help from Xilinx as I am running out of ideas to try. John Robbins Quoting Kieran Mansley <[EMAIL PROTECTED]>: > On Wed, 2006-09-27 at 13:05 -0300, [EMAIL PROTECTED] wrote: > > > 064131 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: S > 1324574079:1324574079(0) > > win 65535 <mss 1460,nop,nop,sackOK> > > 025123 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: S 74879:74879(0) ack > > 1324574080 win 16384 <mss 1460> > > 000024 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1 win 65535 > > 013976 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: P 1:31(30) ack 1 win > 65535 > > 032930 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16354 > > 027001 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: . ack 31 win 16384 > > 033323 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: P 1:1261(1260) ack 31 > win > > 16384 > > 015320 IP 192.168.0.200.80 > IBM-F3860BD49B6.1678: F 1261:1261(0) ack 31 > win > > 16384 > > 000042 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: . ack 1262 win 64275 > > 000098 IP IBM-F3860BD49B6.1678 > 192.168.0.200.80: F 31:31(0) ack 1262 win > 64275 > > 171178 IP IBM-F3860BD49B6.1671 > 192.168.0.200.80: F > 2601444881:2601444881(0) > > ack 62994 win 64275 > > 018375 IP 192.168.0.200.80 > IBM-F3860BD49B6.1671: R 2:2(0) ack 1 win > 16384 > > 181919 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: F > 2886869572:2886869572(0) > > ack 72265 win 64275 > > 017283 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win > 16384 > > 000060 IP IBM-F3860BD49B6.1676 > 192.168.0.200.80: . ack 1 win 64275 > > 026673 IP 192.168.0.200.80 > IBM-F3860BD49B6.1676: R 2:2(0) ack 1 win > 16384 > > 356558 IP IBM-F3860BD49B6.1662 > 192.168.0.200.80: F > 2269257405:2269257405(0) > > ack 47843 win 64275 > > 016779 IP 192.168.0.200.80 > IBM-F3860BD49B6.1662: R 2:2(0) ack 1 win > 16384 > > > > The server, Microblaze, sends the requested data then the FIN to which the > > > client, IBM, responds with an ack, then two FINs. Should there be an > > acknowledgement of the first FIN by the server? Is the server getting > confused > > and then sending the RST? > > I can't comment on any of the performance issues you have with the > hardware as that's outside my field of expertise but the above TCP trace > I can help with. > > The server is acknowledging the first FIN correctly - that's the packet > #9 in the above trace (line starts 000042). > > The two FINs subsequently sent by the IBM are for two different > connections - one is from port 1678 (which seems to be the connection > you're discussing, and this is normal and in response to the FIN sent by > the server) and one is from port 1671 (which doesn't have any other > traffic in the above trace). The Microblaze doesn't seem to know about > the 1671 port connection either as it sends a RST in response. This is > the most likely reason for the RST anyway - if it receives a packet for > a connection it doesn't know about, a RST is the expected behaviour. > > Hope that helps > > Kieran > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users > _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
