Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Jun 2007 09:06:30 +0900
From:      Pyun YongHyeon <pyunyh@gmail.com>
To:        Max Laier <max@love2party.net>
Cc:        Hugo Koji Kobayashi <koji@registro.br>, freebsd-pf@freebsd.org
Subject:   Re: udp fragmentation
Message-ID:  <20070629000630.GA52912@cdnetworks.co.kr>
In-Reply-To: <200706282256.10397.max@love2party.net>
References:  <20070528224225.GC40678@registro.br> <200706282134.26140.max@love2party.net> <009f01c7b9bc$b7a3bd20$c40a0a0a@chepkov.lan> <200706282256.10397.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Jun 28, 2007 at 10:56:01PM +0200, Max Laier wrote:
 > [ Please don't top post, fixed ]
 > 
 > On Thursday 28 June 2007, Vadym Chepkov wrote:
 > > From: "Max Laier" <max@love2party.net>, Thursday, June 28, 2007 3:34 PM
 > > > On Thursday 28 June 2007, Hugo Koji Kobayashi wrote:
 > > > > On Thu, Jun 28, 2007 at 07:19:25PM +0200, Max Laier wrote:
 > > > > > Just to confirm I'm testing the right
 > > > > > cases, my setup looks like:
 > > > > >
 > > > > > Host1       Host2      Host3
 > > > > >
 > > > > > netsend -> pf scrub -> pf scrub -> netreceive
 > > > >
 > > > > I'm not sure I understood your setup. Why there are 3 hosts?
 > > >
 > > > In order to test scrub on forward and receiver at the same time (but
 > > > taking Host2 out of the stream doesn't change the result).
 > > >
 > > > > I think a query should be sth like this:
 > > > >
 > > > >    Client[netsend->pf scrub] -> Internet -> DNS server
 > > > >
 > > > > And the response should be:
 > > > >
 > > > >    DNS server -> Internet -> Client[pf scrub->netreceive]
 > > > >
 > > > > > Everthing works as expected with various UDP payloads > MTU.
 > > > >
 > > > > Are you saying that you're able to receive responses to the
 > > > > following dig command when it's run from a client machine running
 > > > > pf scrub?
 > > > >
 > > > >   dig @a.ns.se se dnskey +dnssec +bufsize=4500
 > > > >
 > > > > This query is supposed to receive a DNS answer of more than 4KB.
 > > >
 > > > See the attached script I did just now.
 > > >
 > > > The only thing common about your setup seems to be the bge(4) NIC. 
 > > > Can you try disabling hardware checksumming (ifconfig -txcsum
 > > > -rxcsum)?  My test is over a hardware checksumming fxp(4) card,
 > > > though.
 > >
 > > Yes, this eliminated the issue. Bug in bge driver?
 > 
 > Kind of - the driver claims to have done UDP checksum testing on the 
 > fragment (which is impossible).  The attached patch should fix the issue 
 > for bge(4) and any other similar NIC.
 > 

I guess bge(4) has Rx checksum offload bug on fragmented UDP
datagrams. Since other hardwares with checksum offload capability
does not show this issue, it could be related with UDP pseudo header
calculation. How about disabling UDP pseudo header calculation?

I don't have bge(4) hardwares so the patch is just guess work.
-- 
Regards,
Pyun YongHyeon

--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="bge.patch"

Index: if_bge.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.197
diff -u -r1.197 if_bge.c
--- if_bge.c	4 Jun 2007 18:25:03 -0000	1.197
+++ if_bge.c	29 Jun 2007 00:06:13 -0000
@@ -1254,7 +1254,7 @@
 	 */
 	CSR_WRITE_4(sc, BGE_MODE_CTL, BGE_DMA_SWAP_OPTIONS |
 	    BGE_MODECTL_MAC_ATTN_INTR | BGE_MODECTL_HOST_SEND_BDS |
-	    BGE_MODECTL_TX_NO_PHDR_CSUM);
+	    BGE_MODECTL_TX_NO_PHDR_CSUM | BGE_MODECTL_RX_NO_PHDR_CSUM);
 
 	/*
 	 * Tell the firmware the driver is running
@@ -2988,8 +2988,7 @@
 			    m->m_pkthdr.len >= ETHER_MIN_NOPAD) {
 				m->m_pkthdr.csum_data =
 				    cur_rx->bge_tcp_udp_csum;
-				m->m_pkthdr.csum_flags |=
-				    CSUM_DATA_VALID | CSUM_PSEUDO_HDR;
+				m->m_pkthdr.csum_flags |= CSUM_DATA_VALID;
 			}
 		}
 

--PEIAKu/WMn1b1Hv9--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070629000630.GA52912>