USB device debugging

[Narasimha M]

Thanks for explanation. Here data is getting corrupted before it comes
to the usbnet itself, so after it reaches to usbnet and go through
network stack, it is failing in tcp checksum and packet is getting
dropped. Same driver is working with linux-3.10.20 but not working
with linux-2.6.32.Not able to find the exact function in driver which
sends receive packet to usbnet, not able to proceed further. Please
suggest some pointers to proceed further.

On Tue, May 24, 2016 at 10:30 PM, Bjørn Mork <bjorn at mork.no> wrote:
> Greg KH <greg at 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



-- 
Narasimha