I'm in the process of writing a network driver for a fibre channel device.
However, I'm running into the problem that after I hand off a received
packet's sk_buff to the kernel networking code (via netif_rx) it appears to
get dropped on the floor somewhere (I can't tell where). I'm setting the
skb->dev and skb->protocol values before calling netif_rx (which seem to be
the only actions consistently taken on the sk_buff containing the packet by
the other drivers I've looked at). My only explanation is that the
networking code doesn't like what I'm passing on up to it, which would be
the exact same data that my Tx code is handed on the Tx side.
So, my question is: what, exactly does the kernel's networking code expect
to see when it's
given a packet?
Here's the scenario I'm working with: two systems connected to each other
via the FC adapters (HAB's) (well, w/ a FC analyzer in between them now),
the Tx side has an IP of 192.168.0.1 assigned to it's HAB and the Rx has
192.168.0.2 (standard Class C private IP's), after loading the driver
modules and doing `ifup fc0` on both systems, I run `ping 192.168.0.x` from
the Tx system (doesn't matter which one), the Tx system sends an ARP down
the wire and it's received by the HAB on the other system, handed off to
my driver and then my driver hands it off via netif_rx, after which, it's
never seen or heard from again, and ping on the Tx side appropriately
decides that the destination is unreachable.
On the Tx side, I'm given a standard ARP packet preceded by LLC and SNAP
headers (that are, as far as I and one of the other developers here can
tell, exactly what's specified by RFC 2625--IP and ARP Over Fibre Channel)
and the IEEE addresses of dest and send (0xFFFFFFFFFFFF and 0x00a0b804030f
respectively). I grab the dest address (so I can give it to the HAB along
w/ the packet), and then use skb_pull to strip the IEEE's off of the start
of the data buffer (I do this for a couple of reasons: 1. the HAB firmware
generates it's own FC Optional header containing this data and 2. it's not
a complete FC Optional header, as it's missing the NAA bits).
On the receive side, I use skb_put to set len and tail, strip the FC
Optional header off (although I've tried leaving it on) and then hand it
off via netif_rx. I've also tried reconstructing the IEEE dest and send in
the format that I get them on the Tx side, but that didn't work either
(didn't think it would, but I gave it a whirl anyway).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:14 EST