On Wed, May 25, 2016 at 3:41 PM, Bj?rn Mork [off-list ref] wrote:

Narasimha M [off-list ref] writes:

quoted

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.

This is no surprise.  There is no "send receive packet to usbnet".

usbnet allocates a receive buffer and hands it to the USB host
controller. This happens in rx_submit().

Understood this.

The host controller calls the
rx_complete() callback when it gets data from the device.

Here i want the help that where will be this host controller ? and how
to it calls the rx_complete () callback ? Whet is the function in host
controller does this. ? Ehat is the exact meaning of when device gets
the data ? These things i am not able to understand. BTW iam using
some 4g dongle as usb and usb driver is gobinet to support this and i
am checking this on one router which has 2.6.32 kernel. I tried to use
usbmon also, i got the raw data. I am trying to process it. Meanwhile
i am not clear about the above explanation. Please try to explain me
if you are not irritated.


 >This callback

will trigger further handling in the usbnet_bh() tasklet, calling
rx_process().  This again calls the minidriver specific rx_fixup()
callback if there is any, which is GobiNet's only chance of inspecting
and possibly modifying the buffer.  But normally it will not touch the
buffer, since there is no fixup necessary for Gobi devices in 802.3 mode
(they transmit plain ethernet packets). rx_process() ends up calling
usbnet_skb_return() which hands the buffer over the the networking stack
using netif_rx().

Understood

So, if we ignore the possible firmware bug workarounds in rx_fixup(),
then nothing ever touches the receive buffer in usbnet. It's just a
handle being passed around.

Understood.

Note that I don't remember, or care, what 2.6.32 might have done. It's too
outdated to be relevant.  But the usbnet design is much older and
haven't changed drastically, so I assume most of the above is valid
there too.


Bj?rn

-- 
Narasimha