On Wed, Dec 14, 2011 at 03:22:06PM -0800, YongHyeon PYUN wrote: > On Wed, Dec 14, 2011 at 01:32:42PM -0800, YongHyeon PYUN wrote: > > On Wed, Dec 14, 2011 at 10:17:41PM +0100, Andrea Venturoli wrote: > > > On 12/14/11 20:59, YongHyeon PYUN wrote: > > > > > > >AFAIK the firmware of controller has no known TSO issue so it > > > >indicates a bug in driver. > > > >What makes me wonder is ICMP ECHO packet should not be affected by > > > >TSO and I have no clue at this moment. > > > > > > I wasn't talking about ICMP ECHO. > > > > > > What happened was: > > > a) the client connected to my server, advertising a TCP MSS of X; > > > b) my server started sending with packets larger than X (possibly it > > > misinterpreted MSS size???); > > > c) an ICMP packet arrived, asking my server to send packets no larger > > > than Y (I guess it was ignored); > > > d) my server kept resending the same (too big) packets; > > > e) it eventually reduced packet size, but it was still larger than Y; > > > ... > > > > > > Wireshark showed some wrong checksums (I believe on the ICMP packet, but > > > I might remember wrong). > > > > You can check whether you received bad checksummed frames with > > netstat(1). > > > > > Of course this made a bell ring and removing TSO solved everything. > > > > > > > > > > > > >(Here, I assume you've > > > >captured packets on receiver side since bpf sees packets before > > > >hardware computes checksum.) > > > > > > Yes, although I don't have them anymore. > > > > > > > > > > > > >If you have a reliable way that reproduces the issue, let me know. > > > > > > I can turn TSO on again, save the packets and send them to you. > > > I just hope nothing changes on the Internet in between the server and > > > the client. > > > Let me know if you need/want this and I'll arrange in the next few days. > > > > > > > Let me know MSS of both client and server. > > Is simple downloading from client to server is enough to trigger > > the issue? Packet capture that shows the problem would be great to > > know what's going on here. > > > > Would you try attached patch and let me know it goes?
Sorry, it seems extra pull up for TCP payload may not be required here. Try this instead.
Index: sys/dev/fxp/if_fxp.c =================================================================== --- sys/dev/fxp/if_fxp.c (revision 228504) +++ sys/dev/fxp/if_fxp.c (working copy) @@ -1454,7 +1454,7 @@ return (ENOBUFS); } tcp = (struct tcphdr *)(mtod(m, char *) + poff); - m = m_pullup(m, poff + sizeof(struct tcphdr) + tcp->th_off); + m = m_pullup(m, poff + (tcp->th_off << 2)); if (m == NULL) { *m_head = NULL; return (ENOBUFS);
_______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"