Re: Help on a network driver ...

[Rabeeh Khoury <rabeeh@xxxxxxxxxxxxx>]

Hi,

I had a problem like this -

If you have a socket buffer that you are going to handle to the upper 
layers, usually you write -

netif_rx(skb);

just add the following line -

skb->pkt_type = PACKET_HOST;

before the 'netif_rx(skb);' line.

The reason for that is that the TCP layer doesn't accept any packet that 
the pkt_type is not a PACKET_HOST. This feature was added to TCP layer 
in order to distnguish between packets that are for the host and packets 
which are not, which is usually noticed when the port works in 
promiscuous mode !

Regards,
Rabeeh


David Brownell wrote:

> Hi,
>
> I've hit a sticking point with a network driver, and am wondering if
> anyone here can provide some helpful suggestions.  Seems like maybe
> I'm doing something the network layer doesn't like, but it's not been
> very helpful about helping figure out just what!  So it's a good time
> to ask for help from folk who know the network stack better.
>
>
> DRIVER:  "drivers/usb/usbnet.c" (2.4.1-ac2), earlier kernels have
> an earlier version with the same problem ("drivers/usb/net1080.c")
> which handled fewer device types.
>
> Basically, USB is used as a network, following the same model used
> by Win32 drivers for these devices:  Ethernet-ish devices, with
> bridging so that end-users can use simple configurations (don't need
> to enable IP routing etc).  Win32 appears to have something less
> powerful than the "bridge" driver built into its networking stack (no
> loops allowed).  "Laplink" style usb-to-usb cables work this way, and
> smart-enough USB devices (iPaq, Yopy ... ;-) have been known to
> do the same thing.  I've seen throughput up to about 700 KByte/sec
> with USB 1.1 ("12 Mbit/s").  I hope to see USB 2.0 ("480 Mbit/s")
> devices doing this sometime later this year!
>
>
> PROBLEM:  TCP connections won't establish -- sometimes.
> The same driver executable may work one day, fail the next.
>
> If I watch things with "tcpdump" what I'll see is TCP setup packets
> (say for FTP, SSH, rpcinfo) arriving ... but no acks getting sent
> back.  Meanwhile, "ping" traffic flies (both directions) without any
> problems at all.  A while back I computed checksums of packets
> on both sides (tx/rx) and they were the same ... suggesting that if
> the data got corrupted, it happened after netif_rx().  The network
> service in question is "live" enough to access by loopback (on
> the server) or through a regular Ethernet connection, though I've
> sometimes seen strange messages from the networking code about
> not being able to find a route to an interface hosted by this driver.
>
>
> So what I'd like is suggestions that can help me figure out why TCP
> seems to be ignoring these packets ... though I'd not turn down a
> patch if one were offered!
>
> - Dave