All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <jdb@comx.dk>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: BUG: NIU driver: strange issues with multicast "UDP: short packet"
Date: Wed, 04 Feb 2009 10:32:06 +0100	[thread overview]
Message-ID: <1233739926.20497.78.camel@localhost.localdomain> (raw)
In-Reply-To: <20090204.010029.12969718.davem@davemloft.net>

On Wed, 2009-02-04 at 01:00 -0800, David Miller wrote:
> From: Jesper Dangaard Brouer <jdb@comx.dk>
> Date: Wed, 04 Feb 2009 09:55:04 +0100
> 
> > On Tue, 2009-02-03 at 15:38 -0800, David Miller wrote:
> > > From: Jesper Dangaard Brouer <jdb@comx.dk>
> > > Date: Tue, 03 Feb 2009 14:38:20 +0100
> > > 
> > > >   UDP: short packet: From 81.161.2.106:0 44063/1324 to 233.123.173.7:0
> > > >   UDP: short packet: From 81.161.2.106:0 44063/1324 to 233.123.173.7:0
> > > >   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
> > > >   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
> > > >   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
> > > >   UDP: short packet: From 81.161.2.106:8304 27493/1324 to 233.123.173.7:24931
> > > 
> > > The UDP header length field is garbage in all of these packets.
> > 
> > Yes, but this only happens on the NIU/netpune NIC.  I works with the igb
> > driver, I have both a 82575 and a 82576 NIC.
> 
> Right, and what's unique about NIU is that NIU won't prepull
> the protocol headers into the linear area on receive.

So thats the difference...

> At the point when IPMR is dealing with potentially forwarding
> the frame, the UDP headers aren't yet pulled into the linear
> area.  UDP input will do that with it's pskb_may_pull() call.

Can I get a little code hint, where IPMR is dealing with potentially
forwarding the frame?

> I think this is the critical bit, and some part of the IPMR
> code makes assumptions about all of the protocol headers being
> pulled into the linear SKB area when it executes.
> 
> I really don't have time to track this down, so what I suggest
> you do is add logging to UDP multicast packets at various
> locations looking for the UDP header length in the paged SKB
> area to go illegal.  Move your probe points around to narrow
> down the culprit.

Is there an easy way to test if the packet is corrupted?
Can you recomment a way to test it?


> Good luck.

Thanks I'm going to need it ;-)

Thanks for you quick answer.
-- 
Med venlig hilsen / Best regards
  Jesper Brouer
  ComX Networks A/S
  Linux Network developer
  Cand. Scient Datalog / MSc.
  Author of http://adsl-optimizer.dk
  LinkedIn: http://www.linkedin.com/in/brouer

  reply	other threads:[~2009-02-04  9:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-03 13:38 BUG: NIU driver: strange issues with multicast "UDP: short packet" Jesper Dangaard Brouer
2009-02-03 23:38 ` David Miller
2009-02-04  8:55   ` Jesper Dangaard Brouer
2009-02-04  9:00     ` David Miller
2009-02-04  9:32       ` Jesper Dangaard Brouer [this message]
2009-02-04  9:34         ` David Miller
2009-02-05 12:44       ` Jesper Dangaard Brouer
2009-02-05 12:47         ` [PATCH] Fix UDP short packet false positive Jesper Dangaard Brouer
2009-02-05 23:06           ` David Miller
2009-02-06  9:00             ` [RFC] " Jesper Dangaard Brouer
2009-02-06  9:08               ` David Miller
2009-02-06  9:55                 ` [PATCH] udp: Fix potential wrong ip_hdr(skb) pointers Jesper Dangaard Brouer
2009-02-06  9:59                   ` David Miller
2009-02-06 10:04                   ` Eric Dumazet
2009-02-06 10:49                     ` Jesper Dangaard Brouer
2009-02-06 11:11                       ` David Miller
2009-02-04 11:52   ` BUG: NIU driver: strange issues with multicast "UDP: short packet" Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1233739926.20497.78.camel@localhost.localdomain \
    --to=jdb@comx.dk \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.