udp fragmentation

Max Laier max at love2party.net
Fri Jun 29 12:29:32 UTC 2007


On Friday 29 June 2007, Pyun YongHyeon wrote:
> 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 at 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.

In fact it doesn't seem broken at all, we would just have to do something 
along the lines of ip_input.c::ip_reass() (line 1001 ff):

     for (q = nq; q != NULL; q = nq) {
             nq = q->m_nextpkt;
             q->m_nextpkt = NULL;
             m->m_pkthdr.csum_flags &= q->m_pkthdr.csum_flags;
             m->m_pkthdr.csum_data += q->m_pkthdr.csum_data;
             m_cat(m, q);
     }
     /*
      * In order to do checksumming faster we do 'end-around carry' here
      * (and not in for{} loop), though it implies we are not going to
      * reassemble more than 64k fragments.
      */
     m->m_pkthdr.csum_data =
         (m->m_pkthdr.csum_data & 0xffff) + (m->m_pkthdr.csum_data >> 16);

Have to ponder a bit, if this is easily possible in pf's reassembly.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20070629/76029d8a/attachment.pgp


More information about the freebsd-pf mailing list