Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g2LIvfF07905 for netdev-outgoing; Thu, 21 Mar 2002 10:57:41 -0800 Received: from mail.gmx.net (sproxy.gmx.net [213.165.64.20]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g2LIvaq07899 for ; Thu, 21 Mar 2002 10:57:36 -0800 Received: (qmail 6671 invoked by uid 0); 21 Mar 2002 17:57:27 -0000 Received: from a1as19-p21.stg.tli.de (HELO havana.yon.net) (195.252.194.21) by mail.gmx.net (mp008-rz3) with SMTP; 21 Mar 2002 17:57:27 -0000 Received: from localhost (localhost [127.0.0.1]) by havana.yon.net (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g2LHuA024648 for ; Thu, 21 Mar 2002 18:56:10 +0100 Date: Thu, 21 Mar 2002 18:56:10 +0100 (CET) From: Yon Uriarte Reply-To: To: Subject: sock_queue_rcv_skb skb->dev = NULL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Content-Length: 1283 Lines: 32 Hi, I'm developing support for UDP encapsulated ESP packets for freeswan, for an easier NAT traversal. Check the drafts at ietf.org. I've changed sock->data_ready() on the 'interesting' sockets to avoid touching my code on most cases. Then I check the skb, dequeueing it and adjusting it to pass it on to freeswan as a normal ESP packet. But then ipsec_rcv needs skb->dev, to find the incoming device and the matching ipsecXXX interface. If it doesnt find a skb->dev it still passes it on, which seems to heavily kill my uml 'machine' (gdb is running, but the kernel just dies with some trap) upon calling netif_rx on the dev'less skb (so the decrypted skb seems to be received on the ipsecXXX interfaces and you can account it, etc.). I commented out the skb->dev = NULL; line and it seems to work but I'm not comfortable at all with this. First because I dont know what if anything I've just broken and because it means a kernel recompile and reboot is needed, which is against one of my goals, support for compiling modular freeswan with just the kernel sources, no need to reboot. Can someone enlighten me on the need to NULL'ify skb->dev upon sock queueing? And can the kernel run with that line commented out? It does now, but that means nothing. TIA, HAND yon