All of lore.kernel.org
 help / color / mirror / Atom feed
From: bjorn@mork.no (Bjørn Mork)
To: kernelnewbies@lists.kernelnewbies.org
Subject: USB device debugging
Date: Tue, 24 May 2016 19:00:23 +0200	[thread overview]
Message-ID: <87posbqtlk.fsf@nemi.mork.no> (raw)
In-Reply-To: <20160524144629.GE28161@kroah.com> (Greg KH's message of "Tue, 24 May 2016 07:46:29 -0700")

Greg KH <greg@kroah.com> writes:
> On Tue, May 24, 2016 at 01:48:16PM +0530, Narasimha M wrote:
>> Thanks for the information. But i want to know the flow of receive
>> packet from usb driver to linux stack. I am facing an issue that
>> corrupted data is coming to usbnet_bh function. So i want to know
>> about the place where we generate the data in usb driver and sent it
>> to usbnet. Could you please help in finding out this. I am using
>> Gobinet driver as usb driver.
>
> Look in the usbnet driver itself, it is the one that receives the data
> from the USB core.
>
> If you suspect the USB core isn't getting the data properly, use usbmon
> to look at the "raw" USB data for the device, instructions for how to
> use that is in the kernel documentation directory.

I would have started with usbmon in this case. Some Gobi firmwares are
known to corrupt ethernet headers in various ways, if that is the
problem.  There are numerous workarounds for these issues in the
qmi_wwan driver, and AFAIK also in the GobiNet driver.  But the worst
mess is unfixable, where the header is overwritten by arbitrary data and
you don't even know if there is a header there or not.  The only
possible workaround for those devices is using "raw-ip" mode, where you
can be certain that there is no ethernet header (and therefore no mess)

Nothing can be ruled out of course, but I say that there is little
chance of any data corruption in the usbnet code.  It doesn't really
touch the packet buffers between USB controller and network stack.  The
corruption is most likely to happen in firmware, or possibly in GobiNet
although I haven't yet seen any proof of that.


Bj?rn

  reply	other threads:[~2016-05-24 17:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-24  7:39 USB device debugging Narasimha M
2016-05-24  7:59 ` Carlo Caione
2016-05-24  8:18   ` Narasimha M
2016-05-24 14:46     ` Greg KH
2016-05-24 17:00       ` Bjørn Mork [this message]
2016-05-25  9:00         ` Narasimha M
2016-05-25 10:11           ` Bjørn Mork
2016-05-25 10:51             ` Narasimha M
2016-05-25 11:06               ` Bjørn Mork
2016-05-25 11:29                 ` Narasimha M
2016-05-25 12:01                   ` Bjørn Mork
2016-05-25 12:37                     ` Narasimha M
2016-05-25 12:56                       ` Bjørn Mork
2016-05-25 15:24                         ` Narasimha M
2016-05-25 15:42                           ` Narasimha M
2016-05-25 18:20                             ` Greg KH
2016-05-26  5:31                               ` Narasimha M
2016-05-26  5:51                                 ` Greg KH
2016-05-26  6:23             ` Narasimha M

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=87posbqtlk.fsf@nemi.mork.no \
    --to=bjorn@mork.no \
    --cc=kernelnewbies@lists.kernelnewbies.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.