From owner-netdev@oss.sgi.com Mon Nov  1 11:47:38 1999
Received:  by oss.sgi.com id <S305155AbPKATrT>;
	Mon, 1 Nov 1999 11:47:19 -0800
Received: from animaniacs.conectiva.com.br ([200.250.58.146]:6391 "HELO
        frajuto.conectiva") by oss.sgi.com with SMTP id <S305154AbPKATrB>;
	Mon, 1 Nov 1999 11:47:01 -0800
Received: (qmail 8192 invoked from network); 1 Nov 1999 18:57:29 -0000
Received: from frajuto.conectiva (acme@192.168.255.201)
  by frajuto.conectiva with SMTP; 1 Nov 1999 18:57:29 -0000
Date:   Mon, 1 Nov 1999 16:57:29 -0200 (EDT)
From:   Arnaldo Carvalho de Melo <acme@conectiva.com.br>
X-Sender: acme@frajuto.conectiva
To:     Henner Eisen <eis@baty.hanse.de>
cc:     cyclom2x device driver devel list 
        <cycsyn-devel@bazar.conectiva.com.br>, linux-x25@vger.rutgers.edu,
        netdev@oss.sgi.com
Subject: Re: ETH_P_X25 type (was Re: [PATCH] cyclom2x driver update)
In-Reply-To: <ouiu3mumem.fsf@baty.hanse.de>
Message-ID: <Pine.LNX.4.20.9911011628080.15054-100000@frajuto.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On 1 Nov 1999, Henner Eisen wrote:

> >>>>> "Arnaldo" == Arnaldo Carvalho de Melo <acme@conectiva.com.br> writes:
> 
>     Arnaldo> point for such protocol, I've just added ARPHRD_HWX25 to
>     Arnaldo> make my driver compile while such protocol proves to work
> 
> I think we should also define a new protocol type (ETH_P_???) for
> packets passing to/from intelligent X.25 devicec which implement
> all three X.25 layers in firmware. IMHO, the current situation
> is not clean. ETH_P_X25 (which is even an offically registered

agreed

> ethertype) should be reserved for skb's containing X.25 PLP packets,
> where skb->data points to the head of the X.25 header when
> passing netif_rx(). Currently, that is
> not always the case: ETH_P_X25 packets received by a ARPHRD_X25 device
> have skb->data pointing to the link-layer control byte
> (Documenatiation/networking/x25-iface.txt) while ETH_P_X25 packets
> received via 802.2 LLC have skb->data pointing to the X.25 PLP header.
> Thus, current X.25 NL must analyse skb->dev->type for received
> frames and behave differently for ARP_HRDRD_X25 type as opposed to
> other HW type which I'd consider a layer violation.
> I think a clean solution should provide a distinct type, e.g.
> ETH_P_X25IFACE for packet with lapb control header. Then, we should
> also have a similar distict type (e.g. ETH_P_X25HWX25) for packets
> passed to/from intelligent X.25 devices.
>  
> I also realized that if_ether.h contains a dummy type ETH_P_CONTROL.
> Does anybody know what it's intended for?
> 
> No code (neither in net nor drivers/net) uses it.
> 
> Maybe an alternative to the above would be to always use
> ETH_P_X25 for X.25 packets (ommiting the x25-ifaxe.txt
> 0x00 control byte) and using ETH_P_CONTROL for controling the lapb link
> state?

seems fine to me, this way we save a byte for data packets (common
case) and make the "prepare for future retransmition" (when we have to do
a skb_push(skb, 1) just to put the control byte back when the driver was
unable to send the packet to the driver right away) code a little simpler,
also with ETH_P_X25HWX25 we don't need to test skb->dev->type on packets
reception in af_x25.c.

> Henner 

cool, I was trying just to hack the X.25 packet layer to make it work
without that much changes, but seems like we'll get a cleaner hack... ;)

         - Arnaldo


From owner-netdev@oss.sgi.com Mon Nov  1 11:51:39 1999
Received:  by oss.sgi.com id <S305178AbPKATv2>;
	Mon, 1 Nov 1999 11:51:28 -0800
Received: from animaniacs.conectiva.com.br ([200.250.58.146]:18679 "HELO
        frajuto.conectiva") by oss.sgi.com with SMTP id <S305173AbPKATvO>;
	Mon, 1 Nov 1999 11:51:14 -0800
Received: (qmail 8355 invoked from network); 1 Nov 1999 19:01:55 -0000
Received: from frajuto.conectiva (acme@192.168.255.201)
  by frajuto.conectiva with SMTP; 1 Nov 1999 19:01:55 -0000
Date:   Mon, 1 Nov 1999 17:01:54 -0200 (EDT)
From:   Arnaldo Carvalho de Melo <acme@conectiva.com.br>
X-Sender: acme@frajuto.conectiva
To:     Henner Eisen <eis@baty.hanse.de>
cc:     cyclom2x device driver devel list 
        <cycsyn-devel@bazar.conectiva.com.br>, linux-x25@vger.rutgers.edu,
        netdev@oss.sgi.com
Subject: Re: ETH_P_X25 type (was Re: [PATCH] cyclom2x driver update)
In-Reply-To: <Pine.LNX.4.20.9911011628080.15054-100000@frajuto.conectiva>
Message-ID: <Pine.LNX.4.20.9911011701020.15054-100000@frajuto.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, 1 Nov 1999, Arnaldo Carvalho de Melo wrote:

> On 1 Nov 1999, Henner Eisen wrote:
> 
> > >>>>> "Arnaldo" == Arnaldo Carvalho de Melo <acme@conectiva.com.br> writes:
> > 
> >     Arnaldo> point for such protocol, I've just added ARPHRD_HWX25 to
> >     Arnaldo> make my driver compile while such protocol proves to work
> > 
> > I think we should also define a new protocol type (ETH_P_???) for
> > packets passing to/from intelligent X.25 devicec which implement
> > all three X.25 layers in firmware. IMHO, the current situation
> > is not clean. ETH_P_X25 (which is even an offically registered
> 
> agreed
> 
> > ethertype) should be reserved for skb's containing X.25 PLP packets,
> > where skb->data points to the head of the X.25 header when
> > passing netif_rx(). Currently, that is
> > not always the case: ETH_P_X25 packets received by a ARPHRD_X25 device
> > have skb->data pointing to the link-layer control byte
> > (Documenatiation/networking/x25-iface.txt) while ETH_P_X25 packets
> > received via 802.2 LLC have skb->data pointing to the X.25 PLP header.
> > Thus, current X.25 NL must analyse skb->dev->type for received
> > frames and behave differently for ARP_HRDRD_X25 type as opposed to
> > other HW type which I'd consider a layer violation.
> > I think a clean solution should provide a distinct type, e.g.
> > ETH_P_X25IFACE for packet with lapb control header. Then, we should
> > also have a similar distict type (e.g. ETH_P_X25HWX25) for packets
> > passed to/from intelligent X.25 devices.
> >  
> > I also realized that if_ether.h contains a dummy type ETH_P_CONTROL.
> > Does anybody know what it's intended for?
> > 
> > No code (neither in net nor drivers/net) uses it.
> > 
> > Maybe an alternative to the above would be to always use
> > ETH_P_X25 for X.25 packets (ommiting the x25-ifaxe.txt
> > 0x00 control byte) and using ETH_P_CONTROL for controling the lapb link
> > state?
> 
> seems fine to me, this way we save a byte for data packets (common
> case) and make the "prepare for future retransmition" (when we have to do
> a skb_push(skb, 1) just to put the control byte back when the driver was
> unable to send the packet to the driver right away) code a little simpler,
                                   ^^^^^^
                                   hardware

> also with ETH_P_X25HWX25 we don't need to test skb->dev->type on packets
> reception in af_x25.c.
> 
> > Henner 
> 
> cool, I was trying just to hack the X.25 packet layer to make it work
> without that much changes, but seems like we'll get a cleaner hack... ;)
> 
>          - Arnaldo
> 


From owner-netdev@oss.sgi.com Mon Nov  1 12:53:50 1999
Received:  by oss.sgi.com id <S305157AbPKAUxb>;
	Mon, 1 Nov 1999 12:53:31 -0800
Received: from kogge.hanse.de ([192.76.134.17]:10759 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S305156AbPKAUxI>;
	Mon, 1 Nov 1999 12:53:08 -0800
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id VAA52523;
	Mon, 1 Nov 1999 21:57:35 +0100 (CET)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id VAA22726;
	Mon, 1 Nov 1999 21:51:31 +0100
To:     Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Cc:     cyclom2x device driver devel list 
        <cycsyn-devel@bazar.conectiva.com.br>, linux-x25@vger.rutgers.edu,
        netdev@oss.sgi.com
Subject: Re: ETH_P_X25 type (was Re: [PATCH] cyclom2x driver update)
References: <Pine.LNX.4.20.9911011628080.15054-100000@frajuto.conectiva>
From:   Henner Eisen <eis@baty.hanse.de>
Date:   01 Nov 1999 21:51:31 +0100
In-Reply-To: Arnaldo Carvalho de Melo's message of "Mon, 1 Nov 1999 16:57:29 -0200 (EDT)"
Message-ID: <ouaeoyx7e4.fsf@baty.hanse.de>
Lines:  21
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "Arnaldo" == Arnaldo Carvalho de Melo <acme@conectiva.com.br> writes:

    Arnaldo> cool, I was trying just to hack the X.25 packet layer to
    Arnaldo> make it work without that much changes, but seems like
    Arnaldo> we'll get a cleaner hack... ;)

Well, lets wait for comments from others, in particular I'd like to
know, what the ETH_P_CONTROL was originally intended for.

The other question is whether changes like this are appropriate at
the currrent (feature freeze) state of the kernel.

Another question to other network developers:

I think it would be nice to have reserved a dummy ETH_P_EXP in if_ether.h
and a dummy ARPHRD_EXP in if_arp.h that can be be safely used (without
risking to clash with future official extensions) by experimential
protocol/device_type implementations until they get an officially
assigned ID. Should I prepare a patch?

Henner 

From owner-netdev@oss.sgi.com Mon Nov  1 14:02:51 1999
Received:  by oss.sgi.com id <S305156AbPKAWCl>;
	Mon, 1 Nov 1999 14:02:41 -0800
Received: from lightning.swansea.uk.linux.org ([194.168.151.1]:36670 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S305154AbPKAWC1>;
	Mon, 1 Nov 1999 14:02:27 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 11iPWS-0003EQ-00; Mon, 1 Nov 1999 22:01:52 +0000
Subject: Re: ETH_P_X25 type (was Re: [PATCH] cyclom2x driver update)
To:     eis@baty.hanse.de (Henner Eisen)
Date:   Mon, 1 Nov 1999 22:01:50 +0000 (GMT)
Cc:     acme@conectiva.com.br, cycsyn-devel@bazar.conectiva.com.br,
        linux-x25@vger.rutgers.edu, netdev@oss.sgi.com
In-Reply-To: <ouaeoyx7e4.fsf@baty.hanse.de> from "Henner Eisen" at Nov 1, 99 09:51:31 pm
Content-Type: text
Content-Length: 444       
Message-Id: <E11iPWS-0003EQ-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> Well, lets wait for comments from others, in particular I'd like to
> know, what the ETH_P_CONTROL was originally intended for.

Its for sending raw messages to hardware firmware. Its an otherwise undefined
board specific packet type for any kind of magic

> risking to clash with future official extensions) by experimential
> protocol/device_type implementations until they get an officially
> assigned ID. Should I prepare a patch?

Sure


From owner-netdev@oss.sgi.com Mon Nov  1 15:15:31 1999
Received:  by oss.sgi.com id <S305158AbPKAXPV>;
	Mon, 1 Nov 1999 15:15:21 -0800
Received: from mailhost.uni-koblenz.de ([141.26.64.1]:54678 "EHLO
        mailhost.uni-koblenz.de") by oss.sgi.com with ESMTP
	id <S305154AbPKAXOy>; Mon, 1 Nov 1999 15:14:54 -0800
Received: from cacc-10.uni-koblenz.de (cacc-10.uni-koblenz.de [141.26.131.10])
	by mailhost.uni-koblenz.de (8.9.1/8.9.1) with ESMTP id AAA29499
	for <netdev@oss.sgi.com>; Tue, 2 Nov 1999 00:19:17 +0100 (MET)
Received:  by lappi.waldorf-gmbh.de id <S407621AbPKAXSG>;
	Tue, 2 Nov 1999 00:18:06 +0100
Date:   Tue, 2 Nov 1999 00:18:06 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     netdev@oss.sgi.com
Subject: ADMIN: Netdev move
Message-ID: <19991102001806.A21338@uni-koblenz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
X-Accept-Language: de,en,fr
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Since netdev has basically become completly unusable I've offered Miguel
to host the mailing list as netdev@oss.sgi.com which he has accepted.
Right now netdev is the only major mailing list hosted on oss, which has
plenty of resources, so email latencies should now be sane again.  I've
also installed anti-spam meassures, so I hope the spam problem to be
eleminated to the degree that this is possible at all.

The subscription list of netdev@nuclecu.unam.mx has been copied to the
new netdev mailing list, so re-subscribing is not necessary.  The list
had a three digit number of undeliverable addresses which I all have
deleted.  Apologies to those which I've deleted even though the problems
were only temporary but for the initial cleanup that seemed to be necessary.

Netdev archives will be available on oss.sgi.com.  At this time we don't
have digests available; if there is demand I however can set them up.

Please report problems with this list to netdev-owner@oss.sgi.com or me.

Happy hacking,

  Ralf

From owner-netdev@oss.sgi.com Wed Nov  3 21:57:11 1999
Received:  by oss.sgi.com id <S305164AbPKDF5B>;
	Wed, 3 Nov 1999 21:57:01 -0800
Received: from cr1008912-a.yec1.on.wave.home.com ([24.114.46.136]:11526 "EHLO
        cr1008912-a.yec1.on.wave.home.com") by oss.sgi.com with ESMTP
	id <S305162AbPKDF4k>; Wed, 3 Nov 1999 21:56:40 -0800
Received: (from localhost user: 'blah', uid#63042) by kanga.kvack.org
	with SMTP id <S40AbPKDGAJ>; Thu, 4 Nov 1999 01:00:09 -0500
Date:   Thu, 4 Nov 1999 01:00:09 -0500 (EST)
From:   "Benjamin C.R. LaHaise" <blah@kvack.org>
To:     Andi Kleen <ak@muc.de>
cc:     netdev@oss.sgi.com
Subject: Re: 2.2.13pre17: tcp sockets stuck in CLOSE_WAIT
In-Reply-To: <19991101093355.D2343@hera.cs.kun.nl>
Message-ID: <Pine.LNX.3.96.991104005822.31560D-100000@kanga.kvack.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1357
Lines: 30

On Mon, 1 Nov 1999, Erik Verbruggen wrote:

> On Fri, Oct 29, 1999 at 02:18:04AM +0200, Andi Kleen wrote:
> > On Thu, Oct 28, 1999 at 09:42:11PM +0200, Benjamin C.R. LaHaise wrote:
> > > Hello,
> > > 
> > > I've just noticed a bunch of sockets stuck in CLOSE_WAIT without a timer
> > > have been sitting around for at least a day now.  They appear to be
> > > triggered by incoming auth requests when my system is delivering mail.  I
> > > remember seeing the same thing under 2.3.12 once before as well.
> > 
> > CLOSE_WAIT means it is waiting for the process to call close().
> > Fix: kill the process.
> 
> No, only a reboot cures them. This behaviour results in quite a lot
> sockets in this state on larger servers. Having like 448 sockets in
> CLOSE_WAIT this way is quite "normal" for an irc server, for example.

To reiterate, they're still here another week later...  (zmailer's been
restarted a few times, and I have verified that all of its processes were
killed =)

		-ben

tcp       10      0 cr1008912-a.yec1.o:auth radium.scl.zaz.com:4673	CLOSE_WAIT  off (0.00/0)
tcp       10      0 cr1008912-a.yec1.o:auth bettina.informati:65057	CLOSE_WAIT  off (0.00/0)
tcp       12      0 cr1008912-a.yec1.o:auth mea.tmt.tele.fi:4182	CLOSE_WAIT  off (0.00/0)
tcp       10      0 cr1008912-a.yec1.o:auth COYOTE.RES.CMU.EDU:2046	CLOSE_WAIT  off (0.00/0)



From owner-netdev@oss.sgi.com Thu Nov  4 18:25:36 1999
Received:  by oss.sgi.com id <S305156AbPKECZ1>;
	Thu, 4 Nov 1999 18:25:27 -0800
Received: from mcn.xidian.edu.cn ([202.117.114.10]:17739 "EHLO
        mcn.xidian.edu.cn") by oss.sgi.com with ESMTP id <S305155AbPKECZD>;
	Thu, 4 Nov 1999 18:25:03 -0800
Received: from mcn.xidian.edu.cn (xhmeng [192.168.1.7])
	by mcn.xidian.edu.cn (8.8.7/8.8.7) with ESMTP id KAA05128
	for <netdev@oss.sgi.com>; Fri, 5 Nov 1999 10:14:32 +0800
Message-ID: <3822417F.216D22E2@mcn.xidian.edu.cn>
Date:   Fri, 05 Nov 1999 10:31:28 +0800
From:   Meng Xiaohu <xhmeng@mcn.xidian.edu.cn>
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux <netdev@oss.sgi.com>
Subject: a "make" problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 642
Lines: 25

Hi,

When I was compiling kernel 2.1.59 on Redhat 5.1( glibc-2.0.7), it
occured errors below. How can I figure it out?

/tmp/cca06163.s: Assembler messages:
/tmp/cca06163.s:65: Error: operands given don't match any known 386
instruction
/tmp/cca06163.s:68: Error: operands given don't match any known 386
instruction
make[2]: *** [locks.o] Error 1
make[1]: *** [first_rule] Error 2
make: *** [linuxsubdirs] Error 2


Thanks!
--
Meng Xiaohu
State Key Laboratory on Integrated Service Networks
P.O.Box 297, Xidian University
Xi'an, Shaanxi, 710071, P.R.China
Tel:029-8201005 (Office),  029-8207423 (Dormitory)
E-mail:xhmeng@mcn.xidian.edu.cn



From owner-netdev@oss.sgi.com Thu Nov  4 21:31:33 1999
Received:  by oss.sgi.com id <S305157AbPKEFbN>;
	Thu, 4 Nov 1999 21:31:13 -0800
Received: from [216.88.157.131] ([216.88.157.131]:15372 "HELO
        smtp.linuxcare.com") by oss.sgi.com with SMTP id <S305155AbPKEFa4>;
	Thu, 4 Nov 1999 21:30:56 -0800
Received: (qmail 10429 invoked from network); 5 Nov 1999 05:42:15 -0000
Received: from view.linuxcare.com (HELO localhost) (@216.88.157.130)
  by smtp.linuxcare.com with SMTP; 5 Nov 1999 05:42:15 -0000
Received: from rustcorp.com.au (really [127.0.0.1]) by rustcorp.com.au
	via in.smtpd with esmtp (ident rusty using rfc1413)
	id <m11jbyI-000CI5C@localhost> (Debian Smail3.2.0.102)
	for <netdev@oss.sgi.com>; Fri, 5 Nov 1999 16:31:34 +1100 (EST) 
Message-Id: <m11jbyI-000CI5C@localhost>
From:   Paul Rusty Russell <Paul.Russell@rustcorp.com.au>
To:     netdev@oss.sgi.com
Subject: [PATCH] 2.3 netfilter-debug
Date:   Fri, 05 Nov 1999 16:31:18 +1100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1856
Lines: 59

Hi all,

	I'll be transmitting a patch to remove CONFIG_NETFILTER_DEBUG
as a config option before 2.4, but meanwhile it *has* caught some
bugs, so I'd like to keep it for a while longer.

	This sets the expected debug info on fragments, so we don't
get bogus warnings with fragmentation.  It also takes out the
(overzealous) debugging messages.

--- linux-2.3/net/ipv4/ip_output.c.~1~	Fri Nov  5 12:36:42 1999
+++ linux-2.3/net/ipv4/ip_output.c	Fri Nov  5 16:26:40 1999
@@ -841,6 +841,9 @@
 		skb_put(skb2, len + hlen);
 		skb2->nh.raw = skb2->data;
 		skb2->h.raw = skb2->data + hlen;
+#ifdef CONFIG_NETFILTER_DEBUG
+		skb2->nf_debug = skb->nf_debug;
+#endif 
 
 		/*
 		 *	Charge the memory for the fragment to any owner
--- linux-2.3/net/core/netfilter.c.~1~	Fri Nov  5 12:35:33 1999
+++ linux-2.3/net/core/netfilter.c	Fri Nov  5 16:29:56 1999
@@ -359,15 +359,12 @@
 		struct nf_hook_ops *elem = (struct nf_hook_ops *)*i;
 		switch (elem->hook(hook, skb, indev, outdev)) {
 		case NF_QUEUE:
-			NFDEBUG("nf_iterate: NF_QUEUE for %p.\n", *skb);
 			return NF_QUEUE;
 
 		case NF_STOLEN:
-			NFDEBUG("nf_iterate: NF_STOLEN for %p.\n", *skb);
 			return NF_STOLEN;
 
 		case NF_DROP:
-			NFDEBUG("nf_iterate: NF_DROP for %p.\n", *skb);
 			return NF_DROP;
 
 #ifdef CONFIG_NETFILTER_DEBUG
@@ -427,8 +424,6 @@
 			}
 			/* Hand it to userspace for collection */
 			skb_queue_tail(&recip->wake->skbq, skb);
-			NFDEBUG("Waking up pf=%i hook=%u mark=%lu reason=%u\n",
-				pf, hook, skb->nfmark, skb->nfreason);
 			wake_up_interruptible(&recip->wake->sleep);
 
 			return;
@@ -473,7 +468,6 @@
 	verdict = nf_iterate(&nf_hooks[pf][hook], &skb, hook, indev,
 			     outdev, &elem);
 	if (verdict == NF_QUEUE) {
-		NFDEBUG("nf_hook: Verdict = QUEUE.\n");
 		nf_queue(skb, elem, pf, hook, indev, outdev, okfn);
 	}
 	read_unlock_bh(&nf_lock);
--
Hacking time.

From owner-netdev@oss.sgi.com Fri Nov  5 13:12:59 1999
Received:  by oss.sgi.com id <S305158AbPKEVMk>;
	Fri, 5 Nov 1999 13:12:40 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:15390 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305155AbPKEVM3>; Fri, 5 Nov 1999 13:12:29 -0800
Received: from hotmail.com (f52.law3.hotmail.com [209.185.241.52])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with SMTP id PAA22555
	for <netdev@roxanne.nuclecu.unam.mx>; Fri, 5 Nov 1999 15:17:04 -0600
Received: (qmail 99358 invoked by uid 0); 5 Nov 1999 21:16:31 -0000
Message-ID: <19991105211631.99357.qmail@hotmail.com>
Received: from 132.248.170.133 by www.hotmail.com with HTTP;
	Fri, 05 Nov 1999 13:16:31 PST
X-Originating-IP: [132.248.170.133]
Reply-To: maurik@servidor.unam.mx
From:   "Mauricio Hernandez" <mauhernandez@hotmail.com>
To:     ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com,
        linux-ipv6@inner.net, ipv6@uni-muenster.de, ipv6imp@munnari.oz.au,
        netdev@roxanne.nuclecu.unam.mx, sun-ipv6-users@sunroof.eng.sun.com,
        users@ipv6.org, linux-ayuda@nuclecu.unam.mx
Subject: IPv6
Date:   Fri, 05 Nov 1999 15:16:31 CST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 395
Lines: 15

Hi!

I was trayng to configure my Linux system with Red Hat 6.0 and 2.2.13 kernel 
to work with IPv6, but I have problems with ftp and telnet, I lose it when I 
was instaling inet6-apps and telnet.

Thanks for any help.
(en ingles o espanol)


Mauricio Hernandez Garcia
UNAM, Mexico.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From owner-netdev@oss.sgi.com Sun Nov  7 14:20:32 1999
Received:  by oss.sgi.com id <S305155AbPKGWUX>;
	Sun, 7 Nov 1999 14:20:23 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:52800 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPKGWUM>; Sun, 7 Nov 1999 14:20:12 -0800
Received: from duff.kuicr.kyoto-u.ac.jp (root@duff.kuicr.kyoto-u.ac.jp [133.103.101.254])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id QAA22029
	for <netdev@nuclecu.unam.mx>; Sun, 7 Nov 1999 16:25:04 -0600
Received: from localhost (okuji@izzy.kuicr.kyoto-u.ac.jp [133.103.101.171])
	by duff.kuicr.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id HAA32301
	for <netdev@nuclecu.unam.mx>; Mon, 8 Nov 1999 07:24:50 +0900
To:     netdev@nuclecu.unam.mx
Subject: ANSI C++ problem in include/linux/socket.h
From:   OKUJI Yoshinori <okuji@kuicr.kyoto-u.ac.jp>
X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991108072259J.okuji@kuicr.kyoto-u.ac.jp>
Date:   Mon, 08 Nov 1999 07:22:59 +0900
X-Dispatcher: imput version 990905(IM130)
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1218
Lines: 34

  Hello,

  When compiling lftp with gcc-2.95.2 on linux-2.2.13, I got this
error:

gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include    -O2 -Wall -Wwrite-strings -Woverloaded-virtual -fno-exceptions -fno-rtti -c -o ftpclass.o ftpclass.cc
In file included from /usr/include/sys/socket.h:6,
                 from ftpclass.cc:26:
/usr/include/linux/socket.h: In function `struct cmsghdr * __cmsg_nxthdr(void *, unsigned int, cmsghdr *)':
/usr/include/linux/socket.h:109: ANSI C++ forbids implicit conversion from `void *' in return


This incompatibility could be fixed just by this patch below. The
change should be trivial.


--- linux/include/linux/socket.h	Tue Aug 10 04:05:13 1999
+++ /usr/src/linux/include/linux/socket.h	Mon Nov  8 07:07:24 1999
@@ -106,7 +106,7 @@
 
 	__ptr = (struct cmsghdr*)(((unsigned char *) __cmsg) +  CMSG_ALIGN(__cmsg->cmsg_len));
 	if ((unsigned long)((char*)(__ptr+1) - (char *) __ctl) > __size)
-		return NULL;
+		return (struct cmsghdr *) NULL;
 
 	return __ptr;
 }


Best wishes,
okuji
----------------------------------------------------------------------
OKUJI Yoshinori  <okuji@kuicr.kyoto-u.ac.jp>           ^o-o^
http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English)     m /

From owner-netdev@oss.sgi.com Tue Nov  9 13:45:09 1999
Received:  by oss.sgi.com id <S305157AbPKIVo7>;
	Tue, 9 Nov 1999 13:44:59 -0800
Received: from [216.88.157.131] ([216.88.157.131]:28932 "HELO
        smtp.linuxcare.com") by oss.sgi.com with SMTP id <S305154AbPKIVof>;
	Tue, 9 Nov 1999 13:44:35 -0800
Received: (qmail 31978 invoked from network); 9 Nov 1999 21:56:46 -0000
Received: from view.linuxcare.com (HELO localhost) (@216.88.157.130)
  by smtp.linuxcare.com with SMTP; 9 Nov 1999 21:56:46 -0000
Received: from rustcorp.com.au (really [127.0.0.1]) by rustcorp.com.au
	via in.smtpd with esmtp (ident rusty using rfc1413)
	id <m11lJ4V-000CIVC@localhost> (Debian Smail3.2.0.102)
	for <netdev@oss.sgi.com>; Wed, 10 Nov 1999 08:44:59 +1100 (EST) 
Message-Id: <m11lJ4V-000CIVC@localhost>
From:   Paul Rusty Russell <Paul.Russell@rustcorp.com.au>
To:     kuznet@ms2.inr.ac.ru
cc:     netdev@oss.sgi.com
Subject: [PATCH] Suppressing ICMP redirects for mangled packets?
Date:   Wed, 10 Nov 1999 08:44:57 +1100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 966
Lines: 32

Alexey,

	Is it reasonable to suppress ICMP redirects in this case?
There are cases where we want to route through a box for special
effects: most common is the where we're NATing 1.2.3.1 onto
192.168.1.1, and a box on 192.168.1.* connects to 1.2.3.1.

Rusty.
PS.  Thanks for bouncing me the crash report from l-k; I'm looking
     into it.

--- linux-2.3/net/ipv4/ip_forward.c.~1~	Fri Nov  5 12:33:21 1999
+++ linux-2.3/net/ipv4/ip_forward.c	Wed Nov 10 07:43:57 1999
@@ -113,8 +113,15 @@
 	/*
 	 *	We now generate an ICMP HOST REDIRECT giving the route
 	 *	we calculated.
+	 *
+	 *	Don't do this if we mangled the packet: bouncing
+	 *	through us probably intentional. 10-Nov-1999 --RR
 	 */
-	if (rt->rt_flags&RTCF_DOREDIRECT && !opt->srr)
+	if (rt->rt_flags&RTCF_DOREDIRECT
+#ifdef CONFIG_NETFILTER
+	    && !(skb->nfcache & NFC_ALTERED)
+#endif
+	    && !opt->srr)
 		ip_rt_send_redirect(skb);
 
 	/* We are about to mangle packet. Copy it! */
--
Hacking time.

From owner-netdev@oss.sgi.com Tue Nov  9 23:15:38 1999
Received:  by oss.sgi.com id <S305158AbPKJHPS>;
	Tue, 9 Nov 1999 23:15:18 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:8719 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPKJHOw>; Tue, 9 Nov 1999 23:14:52 -0800
Received: from cr1008912-a.yec1.on.wave.home.com (root@cr1008912-a.yec1.on.wave.home.com [24.114.46.136])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id BAA04354
	for <netdev@nuclecu.unam.mx>; Wed, 10 Nov 1999 01:19:55 -0600
Received: (from localhost user: 'blah', uid#63042) by kanga.kvack.org
	with SMTP id <S40AbPKJHSW>; Wed, 10 Nov 1999 02:18:22 -0500
Date:   Wed, 10 Nov 1999 02:18:22 -0500 (EST)
From:   "Benjamin C.R. LaHaise" <blah@kvack.org>
To:     OKUJI Yoshinori <okuji@kuicr.kyoto-u.ac.jp>
cc:     netdev@nuclecu.unam.mx
Subject: Re: ANSI C++ problem in include/linux/socket.h
In-Reply-To: <19991108072259J.okuji@kuicr.kyoto-u.ac.jp>
Message-ID: <Pine.LNX.3.96.991110021557.21637C-100000@kanga.kvack.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 354
Lines: 13

On Mon, 8 Nov 1999, OKUJI Yoshinori wrote:

>   Hello,
> 
>   When compiling lftp with gcc-2.95.2 on linux-2.2.13, I got this
> error:

Wrong fix.  The include files in 2.2.12+ are careful to define NULL as 0
when compiling C++ code, so something else you are #include'ing is
redefining NULL as ((void *)0) instead of the 0 it's supposed to be.

		-ben


From owner-netdev@oss.sgi.com Wed Nov 10 00:40:40 1999
Received:  by oss.sgi.com id <S305159AbPKJIk3>;
	Wed, 10 Nov 1999 00:40:29 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:19001 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPKJIkO>; Wed, 10 Nov 1999 00:40:14 -0800
Received: from duff.kuicr.kyoto-u.ac.jp (root@duff.kuicr.kyoto-u.ac.jp [133.103.101.254])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id CAA05283
	for <netdev@nuclecu.unam.mx>; Wed, 10 Nov 1999 02:45:19 -0600
Received: from localhost (okuji@izzy.kuicr.kyoto-u.ac.jp [133.103.101.171])
	by duff.kuicr.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id RAA02657;
	Wed, 10 Nov 1999 17:44:56 +0900
To:     "Benjamin C.R. LaHaise" <blah@kvack.org>, torvalds@transmeta.com
Cc:     netdev@nuclecu.unam.mx
Subject: Re: ANSI C++ problem in include/linux/socket.h
From:   OKUJI Yoshinori <okuji@kuicr.kyoto-u.ac.jp>
In-Reply-To: <Pine.LNX.3.96.991110021557.21637C-100000@kanga.kvack.org>
References: <19991108072259J.okuji@kuicr.kyoto-u.ac.jp>
	<Pine.LNX.3.96.991110021557.21637C-100000@kanga.kvack.org>
X-Mailer: Mew version 1.94.1 on Emacs 20.4 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991110174256O.okuji@kuicr.kyoto-u.ac.jp>
Date:   Wed, 10 Nov 1999 17:42:56 +0900
X-Dispatcher: imput version 990905(IM130)
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1161
Lines: 33

From: "Benjamin C.R. LaHaise" <blah@kvack.org>
Subject: Re: ANSI C++ problem in include/linux/socket.h
Date: Wed, 10 Nov 1999 02:18:22 -0500 (EST)

> Wrong fix.  The include files in 2.2.12+ are careful to define NULL as 0
> when compiling C++ code, so something else you are #include'ing is
> redefining NULL as ((void *)0) instead of the 0 it's supposed to be.

  Thanks for pointing out that. I read and tested all the NULL
definitions, and then found that "include/linux/posix_types.h" was the
cause. The header unconditionally defines NULL as "(void *)0". So this
is a revised patch (I don't know where to send it, so I add Linus into
the addresses):

--- linux/include/linux/posix_types.h	Mon Dec 28 15:18:28 1998
+++ /usr/src/linux/include/linux/posix_types.h	Wed Nov 10 17:30:19 1999
@@ -8,7 +8,11 @@
  */
 
 #ifndef NULL
-# define NULL		((void *) 0)
+# if !defined __cplusplus
+#  define NULL		((void *) 0)
+# else
+#  define NULL		(0)
+# endif
 #endif
 
 /*

----------------------------------------------------------------------
OKUJI Yoshinori  <okuji@kuicr.kyoto-u.ac.jp>           ^o-o^
http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English)     m /

From owner-netdev@oss.sgi.com Wed Nov 10 05:47:27 1999
Received:  by oss.sgi.com id <S305161AbPKJNrR>;
	Wed, 10 Nov 1999 05:47:17 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:32568 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305160AbPKJNq4>; Wed, 10 Nov 1999 05:46:56 -0800
Received: from gw.simegen.com (gw.simegen.com [203.2.135.4])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id HAA09645
	for <netdev@nuclecu.unam.mx>; Wed, 10 Nov 1999 07:52:01 -0600
From:   dancer@zeor.simegen.com
Received: from anaconda.simegen.com [203.28.9.32] (mail)
	by gw.simegen.com with esmtp (Exim 3.03 #1 (Debian))
	id 11lY9Z-00059H-00; Wed, 10 Nov 1999 23:51:13 +1000
Received: from localhost
	([127.0.0.1] helo=zeor.simegen.com ident=dancer)
	by anaconda.simegen.com with esmtp (Exim 3.03 #1 (Debian))
	id 11lY9W-00007w-00; Thu, 11 Nov 1999 00:51:10 +1100
Message-ID: <3829784D.38D1C53C@zeor.simegen.com>
Date:   Wed, 10 Nov 1999 13:51:09 +0000
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Benjamin C.R. LaHaise" <blah@kvack.org>
CC:     OKUJI Yoshinori <okuji@kuicr.kyoto-u.ac.jp>, netdev@nuclecu.unam.mx
Subject: Re: ANSI C++ problem in include/linux/socket.h
References: <Pine.LNX.3.96.991110021557.21637C-100000@kanga.kvack.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 527
Lines: 20

"Benjamin C.R. LaHaise" wrote:

> On Mon, 8 Nov 1999, OKUJI Yoshinori wrote:
>
> >   Hello,
> >
> >   When compiling lftp with gcc-2.95.2 on linux-2.2.13, I got this
> > error:
>
> Wrong fix.  The include files in 2.2.12+ are careful to define NULL as 0
> when compiling C++ code, so something else you are #include'ing is
> redefining NULL as ((void *)0) instead of the 0 it's supposed to be.
>
>                 -ben

Run the compiler with -E and capture the output. You should be able to hunt
down the rogue definition.

D


From owner-netdev@oss.sgi.com Wed Nov 10 08:00:20 1999
Received:  by oss.sgi.com id <S305162AbPKJQAB>;
	Wed, 10 Nov 1999 08:00:01 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:24077 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S305160AbPKJP7q>;
	Wed, 10 Nov 1999 07:59:46 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA01172; Wed, 10 Nov 1999 19:01:57 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <199911101601.TAA01172@ms2.inr.ac.ru>
Subject: Re: [PATCH] Suppressing ICMP redirects for mangled packets?
To:     Paul.Russell@rustcorp.com.au (Paul Rusty Russell)
Date:   Wed, 10 Nov 1999 19:01:57 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <m11lJ4V-000CIVC@localhost> from "Paul Rusty Russell" at Nov 10, 99 08:44:57 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 487
Lines: 14

Hello!

> 	Is it reasonable to suppress ICMP redirects in this case?
> There are cases where we want to route through a box for special
> effects: most common is the where we're NATing 1.2.3.1 onto
> 192.168.1.1, and a box on 192.168.1.* connects to 1.2.3.1.

The solution is hack in the purest form. 8)

Why not to make it cleanly in spirit of ip_masquearade_icmp?
netfilter has to rewrite ICMP consistently in any case and
parsing redirects does not add anything new, does it?

Alexey

From owner-netdev@oss.sgi.com Mon Nov 15 17:17:41 1999
Received:  by oss.sgi.com id <S305155AbPKPBRV>;
	Mon, 15 Nov 1999 17:17:21 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:43314 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPKPBQ7>; Mon, 15 Nov 1999 17:16:59 -0800
Received: from mails.conexion.com.py ([209.117.123.2])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id TAA06101
	for <netdev@nuclecu.unam.mx>; Mon, 15 Nov 1999 19:22:21 -0600
Received: from pc (conexionppp230.conexion.com.py [209.117.143.230])
	by mails.conexion.com.py (8.9.3/8.9.3) with SMTP id VAA10234
	for <netdev@nuclecu.unam.mx>; Mon, 15 Nov 1999 21:26:47 -0300
Message-ID: <000001bf2fda$0b666860$e68f75d1@pc.conexion.com.py>
From:   "Andres Benitez" <dorego@conexion.com.py>
To:     <netdev@nuclecu.unam.mx>
Subject: dqpsk
Date:   Mon, 15 Nov 1999 20:00:22 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0004_01BF2FA4.0D0C11A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 995
Lines: 33

This is a multi-part message in MIME format.

------=_NextPart_000_0004_01BF2FA4.0D0C11A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

We are students of electronic Engeniering, and we need information and =
aplications of dqpsk modulation, could you send us something at this =
mail-adress pleace!

------=_NextPart_000_0004_01BF2FA4.0D0C11A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>We are students of electronic =
Engeniering, and=20
we need information and aplications of dqpsk modulation, could you send =
us=20
something at this mail-adress pleace!</FONT></DIV></BODY></HTML>

------=_NextPart_000_0004_01BF2FA4.0D0C11A0--


From owner-netdev@oss.sgi.com Tue Nov 16 08:45:35 1999
Received:  by oss.sgi.com id <S305159AbPKPQpP>;
	Tue, 16 Nov 1999 08:45:15 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:42029 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPKPQpA>; Tue, 16 Nov 1999 08:45:00 -0800
Received: from maxcow.borg.com (MaxCow.borg.com [205.217.206.188])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id KAA17879
	for <netdev@nuclecu.unam.mx>; Tue, 16 Nov 1999 10:47:42 -0600
Received: from mail.borg.com (mail.borg.com [205.217.206.192]) by maxcow.borg.com (8.9.0/8.8.8) with ESMTP id LAA02033 for <netdev@nuclecu.unam.mx>; Tue, 16 Nov 1999 11:47:40 -0500 (EST)
Received: from swc (cti-fw2.borg.com [205.217.206.199]) by mail.borg.com (8.8.7/8.7.3) with SMTP id LAA28628; Tue, 16 Nov 1999 11:44:38 -0500 (EST)
Message-Id: <3.0.6.32.19991116113710.0079cc00@mail.borg.com>
X-Sender: stu@mail.borg.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date:   Tue, 16 Nov 1999 11:37:10 -0500
To:     "Andres Benitez" <dorego@conexion.com.py>
From:   Stu Card <stu@critical.com>
Subject: Re: dqpsk
Cc:     netdev@nuclecu.unam.mx
In-Reply-To: <000001bf2fda$0b666860$e68f75d1@pc.conexion.com.py>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1483
Lines: 26

At 08:00 PM 1999-11-15 -0400, you
("Andres Benitez" <dorego@conexion.com.py>) wrote:

>    We are students of electronic Engeniering, and  we need information and
>aplications of dqpsk modulation, could you send us  something at this
>mail-adress pleace!

I'm afraid you will find that most of the members of this list know nothing
of DQPSK, as it has nothing to do with the subject of the list, which is
Linux network software development.  DQPSK is Differential Quadrature Phase
Shift Keying.  It is a variant of QPSK which does not require fully coherent
demodulation.  QPSK is a phase-only modulation, commonly used in satellite
communications and other situations where either the signal to noise ratio
is very low, or it is necessary to use very power-efficient amplifiers
(which operate Class C, are therefore nonlinear and thus cannot amplify
signals with any amplitude component to their modulation).  QPSK provides
2 bits per symbol.  A more sophisticated variation on this theme is
trellis-coded 8-PSK, which provides the same information rate in the
same bandwidth, with a slightly better error rate, at the expense of
substantially more complexity in the demodulator/decoder.

------------------------------------------------------------------------
Stuart W. Card, Chief Scientist & Vice-Pres., Critical Technologies Inc.
Suite 400 Technology Center, 4th Floor 1001 Broad Street, Utica NY 13501
315-793-0248   FAX -9710    <stu@critical.com>   http://www.critical.com


From owner-netdev@oss.sgi.com Thu Nov 18 00:12:30 1999
Received:  by oss.sgi.com id <S305160AbPKRIML>;
	Thu, 18 Nov 1999 00:12:11 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:60457 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPKRILt>; Thu, 18 Nov 1999 00:11:49 -0800
Received: from mta3.263.net ([202.96.44.45])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id CAA28770
	for <netdev@nuclecu.unam.mx>; Thu, 18 Nov 1999 02:17:00 -0600
From:   zam_ustc@263.net
Received: from 263.net (unknown [202.96.44.9])
	by mta3.263.net (Postfix) with SMTP id 6DBAC1C45EE63
	for <netdev@nuclecu.unam.mx>; Thu, 18 Nov 1999 16:16:27 +0800 (CST)
Received: (fmail 3386 invoked by uid 1004); 18 Nov 1999 08:23:09 -0000
Date:   18 Nov 1999 08:23:09 -0000
Message-ID: <19991118082309.3385.fmail@263.net>
Reply-To: zam_ustc@263.net
To:     netdev@nuclecu.unam.mx
Subject: What's the problem? Help me!
Content-Transfer-Encoding: 8bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 2038
Lines: 82

hi,everybody!
I want to use raw socket to send my ipv6 packets.I want to fill the
ipv6 header myself. But I cannot succeed. My programme goes as follows:

#include<signal.h>
#include<sys/socket.h>
#include<netinet/ip6.h>
#include<netinet/icmp6.h>
#include<stdio.h>
#include<netdb.h>
#include<netinet/in.h>

void sigalrm(int );
void SendEchoRequest(void);

#define MAX_BUFF_LEN 1000

void *buff;
struct sockaddr *sendaddr;
int sendlen,sockfd;
int seq=0;
struct addrinfo hints,*res;

main()
{int on=1;
 buff=malloc(MAX_BUFF_LEN);
 hints.ai_flags=AI_CANONNAME;
 hints.ai_family=0;
 hints.ai_socktype=0;
 getaddrinfo("3ffe:3216:2101:601:101::6",NULL,&hints,&res);
 sendaddr=res->ai_addr;
 sendlen=res->ai_addrlen;
 signal(SIGALRM,sigalrm);
 if((sockfd=socket(sendaddr->sa_family,SOCK_RAW,1))<0)
    perror("socket");
 if(setsockopt(sockfd,IPPROTO_IPV6,IP_HDRINCL,&on,sizeof(on))<0)
     perror("setsockopt");
 sigalrm(SIGALRM);
 while(1);
}

void sigalrm(int signo)
{SendEchoRequest();
 seq++;
 alarm(3);
 return;
void SendEchoRequest(void)
{struct ip6_hdr *ip6;
 struct icmp6_hdr *icmp6;
 int len=0;
 ip6=(struct ip6_hdr*)buff;
 ip6->ip6_vfc=6<<4;
 ip6->ip6_vfc|=1;
 ip6->ip6_flow=ip6->ip6_vfc;
 ip6->ip6_flow<<=24;
 ip6->ip6_flow|=1;
 ip6->ip6_nxt=58;
 ip6->ip6_hlim=2;
 len+=sizeof(struct ip6_hdr);
 icmp6=(struct icmp6_hdr *)(buff+sizeof(struct ip6_hdr));
 icmp6->icmp6_type=ICMP6_ECHO_REQUEST;
 icmp6->icmp6_code=0;
 icmp6->icmp6_id=0x8888;
 icmp6->icmp6_seq=seq%1000;
 len+=sizeof(struct icmp6_hdr);
 icmp6->icmp6_seq=seq%1000;
 len+=sizeof(struct icmp6_hdr);
 len+=8;
 if(sendto(sockfd,buff,len,0,sendaddr,sendlen)!=len)
         perror("sendto");
}

  This is just a  programme to test the setsockopt() using IP_HDRINCL.
 The packets I receive is not what I want to send. Why?
 Thanks for any help.

_____________________________________________
首都在线--先进中国人的网上家园 http://www.263.net
免费邮箱 邮件杂志 签名邮件 邮件加密 邮件追身呼
搜索引擎 个人站点 在线游戏 网上聊天 网上挂号
金融王国 在线杀毒 跳蚤市场 软件下载 休闲娱乐


From owner-netdev@oss.sgi.com Sun Nov 21 11:46:35 1999
Received:  by oss.sgi.com id <S305156AbPKUTqZ>;
	Sun, 21 Nov 1999 11:46:25 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:49468 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPKUTp6>; Sun, 21 Nov 1999 11:45:58 -0800
Received: from sabre-wulf.nvg.ntnu.no (root@sabre-wulf.nvg.ntnu.no [129.241.210.67])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id NAA14141
	for <netdev@nuclecu.unam.mx>; Sun, 21 Nov 1999 13:51:56 -0600
Received: from tyrell.nvg.ntnu.no ([IPv6:::ffff:129.241.210.70]:43278 "EHLO tyrell.nvg.ntnu.no" ident: "root") by sabre-wulf.nvg.ntnu.no with ESMTP id <49512-10099>; Sun, 21 Nov 1999 20:51:38 +0100
Received: (from venaas@localhost)
          by tyrell.nvg.ntnu.no (8.8.7/8.8.4)
	  id UAA10298; Sun, 21 Nov 1999 20:51:25 +0100
From:   <venaas@nvg.ntnu.no>
Date: 	Sun, 21 Nov 1999 20:51:25 +0100
To:     zam_ustc@263.net
Cc:     netdev@nuclecu.unam.mx
Subject: Re: What's the problem? Help me!
Message-ID: <19991121205125.A10139@nvg.ntnu.no>
References: <19991118082309.3385.fmail@263.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <19991118082309.3385.fmail@263.net>; from zam_ustc@263.net on Thu, Nov 18, 1999 at 08:23:09AM -0000
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 753
Lines: 21

On Thu, Nov 18, 1999 at 08:23:09AM -0000, zam_ustc@263.net wrote:
> hi,everybody!
> I want to use raw socket to send my ipv6 packets.I want to fill the
> ipv6 header myself. But I cannot succeed. My programme goes as follows:

[...stuff deleted...]

>   This is just a  programme to test the setsockopt() using IP_HDRINCL.
>  The packets I receive is not what I want to send. Why?
>  Thanks for any help.

You're not supposed to use IP_HDRINCL with IPv6, see RFC 2292. It
might help to look at some source code, see for instance the ping
code in the inet6-apps package at http://www.inner.net/pub/ipv6/

Stig

-- 
Duct tape is like the force.  It has a light side, and a dark side, and
it holds the universe together ...
                -- Carl Zwanzig

From owner-netdev@oss.sgi.com Mon Nov 22 15:29:12 1999
Received:  by oss.sgi.com id <S305167AbPKVX3D>;
	Mon, 22 Nov 1999 15:29:03 -0800
Received: from [24.218.56.16] ([24.218.56.16]:5382 "EHLO
        dibbler.ne.mediaone.net") by oss.sgi.com with ESMTP
	id <S305164AbPKVX2r>; Mon, 22 Nov 1999 15:28:47 -0800
Received: (from rodrigc@localhost)
	by dibbler.ne.mediaone.net (8.9.3/8.9.3) id SAA01116
	for netdev@oss.sgi.com; Mon, 22 Nov 1999 18:39:30 -0500
Date:   Mon, 22 Nov 1999 18:39:30 -0500
From:   Craig Rodrigues <rodrigc@mediaone.net>
To:     netdev@oss.sgi.com
Subject: Documentation for netfilter as a school project?
Message-ID: <19991122183930.A1107@mediaone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 906
Lines: 28

Hi,

I am taking a course in Network Protocols at Harvard this
semester (http://lab.dce.harvard.edu/extension/cscie131b/),
and was thinking of writing about Netfilter for my term
project.

Since this is Harvard, and not MIT, the term project
cannot involve anything too technical, like coding. :)
Instead I need to write about a contemporary networking
topic, and I'm thinking netfilter is a good one.

I have a lot of experience in different areas of software
development, but I am a not as experienced in Unix systems
programming and I have no experience writing kernel level
Unix or Linux code.

Can someone give me some pointers as to what kinds of things
I should write about?  After my course is over (in Jan.) I wouldn't
mind contributing anything I write to the netfilter project
as documentation.

Thanks.

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

From owner-netdev@oss.sgi.com Tue Nov 23 20:37:25 1999
Received:  by oss.sgi.com id <S305155AbPKXEhO>;
	Tue, 23 Nov 1999 20:37:14 -0800
Received: from linuxcare.canberra.net.au ([203.29.91.49]:33297 "EHLO
        front.linuxcare.com.au") by oss.sgi.com with ESMTP
	id <S305154AbPKXEgx>; Tue, 23 Nov 1999 20:36:53 -0800
Received: from gargle.linuxcare.com.au (stick.linuxcare.com.au [10.61.2.17])
	by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) with ESMTP id PAA02813;
	Wed, 24 Nov 1999 15:42:09 +1100
Received: from rustcorp.com.au (really [127.0.0.1]) by rustcorp.com.au
	via in.smtpd with esmtp
	id <m11qUGh-000DsuC@gargle.linuxcare.com.au> (Debian Smail3.2.0.102)
	for <rodrigc@mediaone.net>; Wed, 24 Nov 1999 15:42:59 +1100 (EST) 
Message-Id: <m11qUGh-000DsuC@gargle.linuxcare.com.au>
From:   Paul Rusty Russell <Paul.Russell@linuxcare.com.au>
To:     Craig Rodrigues <rodrigc@mediaone.net>
Cc:     netdev@oss.sgi.com
Subject: Re: Documentation for netfilter as a school project? 
In-reply-to: Your message of "Mon, 22 Nov 1999 18:39:30 CDT."
             <19991122183930.A1107@mediaone.net> 
Date:   Wed, 24 Nov 1999 15:42:59 +1100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 425
Lines: 16

In message <19991122183930.A1107@mediaone.net> you write:
> Hi,
> 
> I am taking a course in Network Protocols at Harvard this
> semester (http://lab.dce.harvard.edu/extension/cscie131b/),
> and was thinking of writing about Netfilter for my term
> project.

See all the netfilter HOWTOs; figure out what's missing in your
opinion, and write about it.

I'd really like an ip and tc man page, though.

Rusty.
--
Hacking time.

From owner-netdev@oss.sgi.com Thu Nov 25 21:12:46 1999
Received:  by oss.sgi.com id <S305156AbPKZFMg>;
	Thu, 25 Nov 1999 21:12:36 -0800
Received: from colin.muc.de ([193.149.48.1]:1549 "HELO colin.muc.de")
	by oss.sgi.com with SMTP id <S305154AbPKZFMM>;
	Thu, 25 Nov 1999 21:12:12 -0800
Received: by colin.muc.de id <140552-2>; Fri, 26 Nov 1999 06:18:23 +0100
Message-ID: <19991126061821.64483@colin.muc.de>
Date:   Fri, 26 Nov 1999 06:18:21 +0100
From:   Andi Kleen <ak@muc.de>
To:     becker@CESDIS.gsfc.nasa.gov
Cc:     netdev@oss.sgi.com
Subject: Bug in recent net driver skeleton ?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 612
Lines: 22

Hallo Donald,

The recent ethernet drivers of yours (3c59x 0.99L, tulip 0.91g2,
eepro100 etc.) have this line:

#if (LINUX_VERSION_CODE >= 0x20100)
char kernel_version[] = UTS_RELEASE;
#endif

Now this breaks when I try to compile multiple of these drivers statically
into a kernel. The linker rightfully complains about multiple definitions
of kernel_version. I think the right fix is to change it into:

#if defined(MODULE) && (LINUX_VERSION_CODE >= 0x20100)
char kernel_version[] = UTS_RELEASE;
#endif

kernel_version makes no sense without a module anyways. Or is there some
deep reason I'm missing?

-Andi


From owner-netdev@oss.sgi.com Thu Nov 25 21:38:36 1999
Received:  by oss.sgi.com id <S305157AbPKZFi0>;
	Thu, 25 Nov 1999 21:38:26 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:7940 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S305154AbPKZFiJ>;
	Thu, 25 Nov 1999 21:38:09 -0800
Received: (qmail 727 invoked by uid 502); 26 Nov 1999 05:44:25 -0000
Message-ID: <19991126054425.723.qmail@mail.ocs.com.au>
Received: (qmail 708 invoked from network); 26 Nov 1999 05:44:19 -0000
Received: from ocs4.ocs-net (192.168.255.4)
  by mail.ocs.com.au with SMTP; 26 Nov 1999 05:44:19 -0000
X-Mailer: exmh version 2.0.2
From:   Keith Owens <kaos@ocs.com.au>
To:     Andi Kleen <ak@muc.de>
cc:     becker@CESDIS.gsfc.nasa.gov, netdev@oss.sgi.com
Subject: Re: Bug in recent net driver skeleton ? 
In-reply-to: Your message of "Fri, 26 Nov 1999 06:18:21 BST."
             <19991126061821.64483@colin.muc.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Fri, 26 Nov 1999 16:44:16 +1100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1241
Lines: 31

On Fri, 26 Nov 1999 06:18:21 +0100, 
Andi Kleen <ak@muc.de> wrote:
>The recent ethernet drivers of yours (3c59x 0.99L, tulip 0.91g2,
>eepro100 etc.) have this line:
>
>#if (LINUX_VERSION_CODE >= 0x20100)
>char kernel_version[] = UTS_RELEASE;
>#endif
>
>Now this breaks when I try to compile multiple of these drivers statically
>into a kernel. The linker rightfully complains about multiple definitions
>of kernel_version. I think the right fix is to change it into:
>
>#if defined(MODULE) && (LINUX_VERSION_CODE >= 0x20100)
>char kernel_version[] = UTS_RELEASE;
>#endif
>
>kernel_version makes no sense without a module anyways. Or is there some
>deep reason I'm missing?

It may be redundant anyway.  #include <modules.h> defines
kernel_version[] in 2.0 kernels and __module_kernel_version[] for 2.1
(starting around 2.1.90 I think).  Any module should include modules.h
which will insert the correct definition.

You only get a problem if you need to link two or more objects into a
single module and more than one of the the inputs includes <module.h>,
it results in duplicate definitions of kernel_version.  In this case,
all but one of the inputs should either not include modules.h or should
#define __NO_VERSION__ before modules.h.


From owner-netdev@oss.sgi.com Sat Nov 27 01:26:15 1999
Received:  by oss.sgi.com id <S305155AbPK0J0F>;
	Sat, 27 Nov 1999 01:26:05 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:53063 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPK0JZr>; Sat, 27 Nov 1999 01:25:47 -0800
Received: from wiget.t17.ds.pwr.wroc.pl (postfix@wiget.t17.ds.pwr.wroc.pl [156.17.210.110])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id DAA13782
	for <netdev@nuclecu.unam.mx>; Sat, 27 Nov 1999 03:32:06 -0600
Received: by wiget.t17.ds.pwr.wroc.pl (Postfix, from userid 500)
	id 4ACFE5F086; Sat, 27 Nov 1999 10:30:27 +0100 (CET)
Date:   Sat, 27 Nov 1999 10:30:26 +0100
From:   Artur Frysiak <wiget@t17.ds.pwr.wroc.pl>
To:     Netdev list <netdev@nuclecu.unam.mx>
Cc:     Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>, Andi Kleen <ak@muc.de>,
        "David S . Miller" <davem@redhat.com>,
        Pedro Roque <roque@di.fc.ul.pt>,
        Linux Kernel List <linux-kernel@vger.rutgers.edu>
Subject: Oops - bug in IPv6 code
Message-ID: <19991127103026.A6725@wiget>
Mail-Followup-To: Netdev list <netdev@nuclecu.unam.mx>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>, Andi Kleen <ak@muc.de>,
	"David S . Miller" <davem@redhat.com>,
	Pedro Roque <roque@di.fc.ul.pt>,
	Linux Kernel List <linux-kernel@vger.rutgers.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
X-Operating-System: Linux wiget 2.2.13 
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 4524
Lines: 111

Hi.
I cacht some oops. Every oops in IPv6 code. I make oops meassge save by hand
and decode it.

ksymoops 0.7c on i686 2.2.13.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.2.13/ (default)
     -m /boot/System.map (specified)

current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c4823e83>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0010286
eax: c35b6c60 ebx: c275e960 ecx: c35b6c60 edx: 00000004
esi: 00000000 edi: c275ea10 ebp: c275e960 esp: c01d9dc2
ds: 0018 es: 0018 ss: 0018
Stack: 00000006 c12a4850 04061900 c12a0406 00000003 c275ea70 c12a4868 c12a4858
       c1378da0 000000c8 c34b6c60 c1378ea0 fffffff4 c12a4858 c482ad5c c01d9d84
       47915763 c1378eb0 c482ad5c c35b6cd4 00000006 c275ea30 c275ea10 c35b6c60
Call Trace: [<c482ad5c>] [<c482ad5c>] [<c482137d>] [<c4820109>] [<c4821ba6>] [<c482b480>] [<c482ad5c>]
        [<c4816c4c>] [<c014952d>] [<c482b058>] [<c481ba62>] [<c01463f2>] [<c4826058>] [<c0117cb1>] [<c010a359>]
        [<c01133f9>] [<c01077b1>] [<c0108f94>] [<c0107ee1>] [<c01077da>] [<c01133f9>] [<c0108fe4>] [<c0108f94>]
        [<c0106000>] [<c0100018>] [<c0106088>] [<c0106000>] [<c010175>]
Code: 86 46 34 c0 74 0a f7 d8 89 83 54 02 00 00 eb 22 46 20

>>EIP; c4823e83 <[ipv6]tcp_v6_err+2db/4b0>   <=====
Trace; c482ad5c <[ipv6]ip6_routing_table+0/1c>
Trace; c482ad5c <[ipv6]ip6_routing_table+0/1c>
Trace; c482137d <[ipv6]icmpv6_notify+99/fc>
Trace; c4820109 <[ipv6]raw_v6_lookup+21/dc>
Trace; c4821ba6 <[ipv6]ipv6_dev_mc_inc+c6/130>
Trace; c482b480 <[ipv6]icmpv6_protocol+0/18>
Trace; c482ad5c <[ipv6]ip6_routing_table+0/1c>
Trace; c4816c4c <[ipv6]ip6_input+c8/128>
Trace; c014952d <__kfree_skb+ad/b8>
Trace; c482b058 <[ipv6]ipv6_packet_type+0/14>
Trace; c481ba62 <[ipv6]rt6_info_route+ee/14c>
Trace; c01463f2 <devpts_root_lookup+a2/ac>
Trace; c4826058 <[ipv6]ipv6_parse_exthdrs+14/54>
Trace; c0117cb1 <do_bottom_half+51/6c>
Trace; c010a359 <do_IRQ+41/48>
Trace; c01133f9 <printk+121/168>
Trace; c01077b1 <cpu_idle+59/68>
Trace; c0108f94 <system_call+34/40>
Trace; c0107ee1 <sys_clone+21/28>
Trace; c01077da <sys_idle+1a/30>
Trace; c01133f9 <printk+121/168>
Trace; c0108fe4 <signal_return+14/20>
Trace; c0108f94 <system_call+34/40>
Trace; c0106000 <get_options+0/7c>
Trace; c0100018 <startup_32+18/11d>
Trace; c0106088 <cpu_idle+c/1c>
Trace; c0106000 <get_options+0/7c>
Trace; 0c010175 Before first symbol
Code;  c4823e83 <[ipv6]tcp_v6_err+2db/4b0>
00000000 <_EIP>:
Code;  c4823e83 <[ipv6]tcp_v6_err+2db/4b0>   <=====
   0:   86 46 34                  xchg   %al,0x34(%esi)   <=====
Code;  c4823e86 <[ipv6]tcp_v6_err+2de/4b0>
   3:   c0                        (bad)  
Code;  c4823e87 <[ipv6]tcp_v6_err+2df/4b0>
   4:   74 0a                     je     10 <_EIP+0x10> c4823e93 <[ipv6]tcp_v6_err+2eb/4b0>
Code;  c4823e89 <[ipv6]tcp_v6_err+2e1/4b0>
   6:   f7 d8                     neg    %eax
Code;  c4823e8b <[ipv6]tcp_v6_err+2e3/4b0>
   8:   89 83 54 02 00 00         mov    %eax,0x254(%ebx)
Code;  c4823e91 <[ipv6]tcp_v6_err+2e9/4b0>
   e:   eb 22                     jmp    32 <_EIP+0x32> c4823eb5 <[ipv6]tcp_v6_err+30d/4b0>
Code;  c4823e93 <[ipv6]tcp_v6_err+2eb/4b0>
  10:   46                        inc    %esi
Code;  c4823e94 <[ipv6]tcp_v6_err+2ec/4b0>
  11:   20 00                     and    %al,(%eax)

Linux wiget 2.2.13 #3 Wed Nov 10 07:02:10 CET 1999 i686 pld
Kernel modules         2.3.3
Gnu C                  2.95.2
Binutils               2.9.5.0.19
Linux C Library        2.1.2
Dynamic linker         ldd (GNU libc) 2.1.2
Linux C++ Library      2.10.0
Procps                 2.0.6
Mount                  2.10b
Net-tools              1.53
Console-tools          0.3.3
Sh-utils               2.0
Sh-utils               Parker.
Sh-utils
Sh-utils               Inc.
Sh-utils               NO
Sh-utils               PURPOSE.
Modules Loaded         snd-card-gusclassic snd-gus snd-pcm1 snd-timer
snd-midi snd-seq-device snd-mixer snd-pcm snd soundcore autofs softdog
ne2k-pci 8390 ipv6

Host is connected to IPv6 network by LAN (without sit/gre tunnels).

Wiget
-- 
  __    __ _            _
 / / /\ \ (_) __ _  ___| |_  @__mail:  Artur Frysiak
 \ \/  \/ / |/ _` |/ _ \ __|            Rudlice 10
  \  /\  /| | (_| |  __/ |_           98-311 Ostrowek
   \/  \/ |_|\__, |\___|\__|
             |___/           email:   Wiget@t17.ds.pwr.wroc.pl
PGP key: http://www.t17.ds.pwr.wroc.pl/~wiget/pgp.key
1024D/12FE7FAE ACB5 5834 C2F7 F86E 4F21  6D88 06B8 2CFE 12FE 7FAE

From owner-netdev@oss.sgi.com Sat Nov 27 02:10:55 1999
Received:  by oss.sgi.com id <S305158AbPK0KKf>;
	Sat, 27 Nov 1999 02:10:35 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:10060 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPK0KKO>; Sat, 27 Nov 1999 02:10:14 -0800
Received: from sabre-wulf.nvg.ntnu.no (root@sabre-wulf.nvg.ntnu.no [129.241.210.67])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id EAA15089
	for <netdev@nuclecu.unam.mx>; Sat, 27 Nov 1999 04:16:44 -0600
Received: from tyrell.nvg.ntnu.no ([IPv6:::ffff:129.241.210.70]:28936 "EHLO tyrell.nvg.ntnu.no" ident: "root") by sabre-wulf.nvg.ntnu.no with ESMTP id <49160-19020>; Sat, 27 Nov 1999 11:16:34 +0100
Received: (from venaas@localhost)
          by tyrell.nvg.ntnu.no (8.8.7/8.8.4)
	  id LAA18713; Sat, 27 Nov 1999 11:16:32 +0100
From:   <venaas@nvg.ntnu.no>
Date: 	Sat, 27 Nov 1999 11:16:32 +0100
To:     Netdev list <netdev@nuclecu.unam.mx>,
        Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
        Andi Kleen <ak@muc.de>, "David S . Miller" <davem@redhat.com>,
        Pedro Roque <roque@di.fc.ul.pt>,
        Linux Kernel List <linux-kernel@vger.rutgers.edu>
Subject: Re: Oops - bug in IPv6 code
Message-ID: <19991127111632.A18674@nvg.ntnu.no>
References: <19991127103026.A6725@wiget>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <19991127103026.A6725@wiget>; from Artur Frysiak on Sat, Nov 27, 1999 at 10:30:26AM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1620
Lines: 41

On Sat, Nov 27, 1999 at 10:30:26AM +0100, Artur Frysiak wrote:
> Code;  c4823e83 <[ipv6]tcp_v6_err+2db/4b0>
> 00000000 <_EIP>:
> Code;  c4823e83 <[ipv6]tcp_v6_err+2db/4b0>   <=====
>    0:   86 46 34                  xchg   %al,0x34(%esi)   <=====
> Code;  c4823e86 <[ipv6]tcp_v6_err+2de/4b0>
>    3:   c0                        (bad)  
> Code;  c4823e87 <[ipv6]tcp_v6_err+2df/4b0>
>    4:   74 0a                     je     10 <_EIP+0x10> c4823e93 <[ipv6]tcp_v6_err+2eb/4b0>
> Code;  c4823e89 <[ipv6]tcp_v6_err+2e1/4b0>
>    6:   f7 d8                     neg    %eax
> Code;  c4823e8b <[ipv6]tcp_v6_err+2e3/4b0>
>    8:   89 83 54 02 00 00         mov    %eax,0x254(%ebx)
> Code;  c4823e91 <[ipv6]tcp_v6_err+2e9/4b0>
>    e:   eb 22                     jmp    32 <_EIP+0x32> c4823eb5 <[ipv6]tcp_v6_err+30d/4b0>
> Code;  c4823e93 <[ipv6]tcp_v6_err+2eb/4b0>
>   10:   46                        inc    %esi
> Code;  c4823e94 <[ipv6]tcp_v6_err+2ec/4b0>
>   11:   20 00                     and    %al,(%eax)

I think the following patch might fix it:

--- tcp_ipv6.c.orig     Thu Aug 26 02:29:53 1999
+++ tcp_ipv6.c  Sun Oct 31 00:59:31 1999
@@ -632,7 +632,6 @@
 
                if (dst == NULL) {
                        struct flowi fl;
-                       struct dst_entry *dst;
 
                        /* BUGGG_FUTURE: Again, it is not clear how
                           to handle rthdr case. Ignore this complexity

This will be fixed in the next 2.2 I hope.

Stig

-- 
Duct tape is like the force.  It has a light side, and a dark side, and
it holds the universe together ...
                -- Carl Zwanzig

From owner-netdev@oss.sgi.com Sat Nov 27 04:05:43 1999
Received:  by oss.sgi.com id <S305159AbPK0MFY>;
	Sat, 27 Nov 1999 04:05:24 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:43348 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPK0MFE>; Sat, 27 Nov 1999 04:05:04 -0800
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id GAA15692
	for <netdev@nuclecu.unam.mx>; Sat, 27 Nov 1999 06:11:30 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch1.nortel.com; Sat, 27 Nov 1999 06:10:54 -0600
Received: from zctwb003.asiapac.nortel.com ([47.152.32.111]) 
          by zrchb213.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id WXA29W01; Sat, 27 Nov 1999 06:10:44 -0600
Received: from pwold011.asiapac.nortel.com ([47.181.193.45]) 
          by zctwb003.asiapac.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) 
          id WSTGCDPH; Sat, 27 Nov 1999 23:10:42 +1100
Received: from asiapacificm01.nt.com (awolr002 [47.181.193.11]) 
          by pwold011.asiapac.nortel.com (8.9.3/8.9.3) with ESMTP id XAA31791;
          Sat, 27 Nov 1999 23:06:23 +1100
Message-ID: <383FC97A.A5074285@asiapacificm01.nt.com>
Date:   Sat, 27 Nov 1999 12:07:22 +0000
From:   "Andrew Morton" <morton@nortelnetworks.com>
Organization: Nortel Networks, Wollongong Australia
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13-7mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     venaas <venaas@nvg.ntnu.no>
CC:     Netdev list <netdev@nuclecu.unam.mx>,
        Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
        Andi Kleen <ak@muc.de>, "David S . Miller" <davem@redhat.com>,
        Pedro Roque <roque@di.fc.ul.pt>,
        Linux Kernel List <linux-kernel@vger.rutgers.edu>
Subject: Re: Oops - bug in IPv6 code
References: <19991127103026.A6725@wiget> <19991127111632.A18674@nvg.ntnu.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 228
Lines: 8

venaas wrote:
>                 if (dst == NULL) {
>                         struct flowi fl;
> -                       struct dst_entry *dst;

Compilation with -Wshadow would have caught this.

Any reason why this is not done?

From owner-netdev@oss.sgi.com Sat Nov 27 04:47:14 1999
Received:  by oss.sgi.com id <S305160AbPK0Mqy>;
	Sat, 27 Nov 1999 04:46:54 -0800
Received: from athena.nuclecu.unam.mx ([132.248.29.9]:45400 "EHLO
        athena.nuclecu.unam.mx") by oss.sgi.com with ESMTP
	id <S305154AbPK0Mqd>; Sat, 27 Nov 1999 04:46:33 -0800
Received: from wiget.t17.ds.pwr.wroc.pl (postfix@wiget.t17.ds.pwr.wroc.pl [156.17.210.110])
	by athena.nuclecu.unam.mx (8.8.7/8.8.7) with ESMTP id GAA15923
	for <netdev@nuclecu.unam.mx>; Sat, 27 Nov 1999 06:53:02 -0600
Received: by wiget.t17.ds.pwr.wroc.pl (Postfix, from userid 500)
	id 499AF5F021; Sat, 27 Nov 1999 13:51:21 +0100 (CET)
Date:   Sat, 27 Nov 1999 13:51:21 +0100
From:   Artur Frysiak <wiget@t17.ds.pwr.wroc.pl>
To:     Andrew Morton <morton@nortelnetworks.com>
Cc:     venaas <venaas@nvg.ntnu.no>, Netdev list <netdev@nuclecu.unam.mx>,
        Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
        Andi Kleen <ak@muc.de>, "David S . Miller" <davem@redhat.com>,
        Pedro Roque <roque@di.fc.ul.pt>,
        Linux Kernel List <linux-kernel@vger.rutgers.edu>
Subject: Re: Oops - bug in IPv6 code
Message-ID: <19991127135121.C2579@wiget>
Reply-To: Artur Frysiak <wiget@ipv6.t17.dhs.org>
Mail-Followup-To: Andrew Morton <morton@nortelnetworks.com>,
	venaas <venaas@nvg.ntnu.no>, Netdev list <netdev@nuclecu.unam.mx>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>, Andi Kleen <ak@muc.de>,
	"David S . Miller" <davem@redhat.com>,
	Pedro Roque <roque@di.fc.ul.pt>,
	Linux Kernel List <linux-kernel@vger.rutgers.edu>
References: <19991127103026.A6725@wiget> <19991127111632.A18674@nvg.ntnu.no> <383FC97A.A5074285@asiapacificm01.nt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <383FC97A.A5074285@asiapacificm01.nt.com>; from morton@nortelnetworks.com on Sat, Nov 27, 1999 at 12:07:22PM +0000
X-Operating-System: Linux wiget 2.2.13 
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 794
Lines: 24

On Sat, 27 Nov 1999, Andrew Morton wrote:

> venaas wrote:
> >                 if (dst == NULL) {
> >                         struct flowi fl;
> > -                       struct dst_entry *dst;
> 
> Compilation with -Wshadow would have caught this.
> 
> Any reason why this is not done?

I apply this patch and kernel work fine. If I get any other oops I mail info
about this to netdev.

Wiget
-- 
  __    __ _            _
 / / /\ \ (_) __ _  ___| |_  @__mail:  Artur Frysiak
 \ \/  \/ / |/ _` |/ _ \ __|            Rudlice 10
  \  /\  /| | (_| |  __/ |_           98-311 Ostrowek
   \/  \/ |_|\__, |\___|\__|
             |___/           email:   Wiget@t17.ds.pwr.wroc.pl
PGP key: http://www.t17.ds.pwr.wroc.pl/~wiget/pgp.key
1024D/12FE7FAE ACB5 5834 C2F7 F86E 4F21  6D88 06B8 2CFE 12FE 7FAE

From owner-netdev@oss.sgi.com Sat Nov 27 10:50:29 1999
Received:  by oss.sgi.com id <S305161AbPK0SuT>;
	Sat, 27 Nov 1999 10:50:19 -0800
Received: from dibbler.ne.mediaone.net ([24.218.57.252]:13583 "EHLO
        dibbler.ne.mediaone.net") by oss.sgi.com with ESMTP
	id <S305154AbPK0SuE>; Sat, 27 Nov 1999 10:50:04 -0800
Received: (from rodrigc@localhost)
	by dibbler.ne.mediaone.net (8.9.3/8.9.3) id NAA17666;
	Sat, 27 Nov 1999 13:49:42 -0500
Date:   Sat, 27 Nov 1999 13:49:37 -0500
From:   Craig Rodrigues <rodrigc@mediaone.net>
To:     Andrew Morton <morton@nortelnetworks.com>
Cc:     netdev@oss.sgi.com
Subject: Re: Oops - bug in IPv6 code
Message-ID: <19991127134937.A17658@mediaone.net>
References: <19991127103026.A6725@wiget> <19991127111632.A18674@nvg.ntnu.no> <383FC97A.A5074285@asiapacificm01.nt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <383FC97A.A5074285@asiapacificm01.nt.com>; from morton@nortelnetworks.com on Sat, Nov 27, 1999 at 12:07:22PM +0000
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 1489
Lines: 32

On Sat, Nov 27, 1999 at 12:07:22PM +0000, Andrew Morton wrote:
> venaas wrote:
> >                 if (dst == NULL) {
> >                         struct flowi fl;
> > -                       struct dst_entry *dst;
> 
> Compilation with -Wshadow would have caught this.
> 
> Any reason why this is not done?

Compiling with -Wshadow spews lots of warnings:
cc -c -Wshadow -I/usr/src/linux/include -D__KERNEL__ -I. -o tcp_ipv6.o tcp_ipv6.c 

In file included from /usr/src/linux/include/net/checksum.h:33,
                 from /usr/src/linux/include/net/tcp.h:24,
                 from tcp_ipv6.c:37:
/usr/src/linux/include/asm/checksum.h: In function `csum_and_copy_to_user':
/usr/src/linux/include/asm/checksum.h:206: warning: declaration of `sum' shadows a parameter
In file included from tcp_ipv6.c:41:
/usr/src/linux/include/net/addrconf.h: At top level:
/usr/src/linux/include/net/addrconf.h:47: warning: declaration of `event' shadows global declaration
In file included from /usr/src/linux/include/net/ip6_route.h:13,
                 from tcp_ipv6.c:42:
/usr/src/linux/include/net/ip6_fib.h:170: warning: declaration of `event' shadows global declaration
tcp_ipv6.c: In function `tcp_v6_connect':
tcp_ipv6.c:438: warning: declaration of `sin' shadows global declaration
tcp_ipv6.c: In function `tcp_v6_err':
tcp_ipv6.c:635: warning: declaration of `dst' shadows previous local              
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

From owner-netdev@oss.sgi.com Mon Nov 29 23:46:36 1999
Received:  by oss.sgi.com id <S305157AbPK3HqQ>;
	Mon, 29 Nov 1999 23:46:16 -0800
Received: from linuxcare.canberra.net.au ([203.29.91.49]:43013 "EHLO
        front.linuxcare.com.au") by oss.sgi.com with ESMTP
	id <S305156AbPK3Hp4>; Mon, 29 Nov 1999 23:45:56 -0800
Received: from gargle.linuxcare.com.au (stick.linuxcare.com.au [10.61.2.17])
	by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA27354;
	Tue, 30 Nov 1999 18:52:37 +1100
Received: from rustcorp.com.au (really [127.0.0.1]) by rustcorp.com.au
	via in.smtpd with esmtp
	id <m11siAY-000DsYC@gargle.linuxcare.com.au> (Debian Smail3.2.0.102)
	for <netdev@oss.sgi.com>; Tue, 30 Nov 1999 18:57:50 +1100 (EST) 
Message-Id: <m11siAY-000DsYC@gargle.linuxcare.com.au>
From:   Paul Rusty Russell <Paul.Russell@linuxcare.com.au>
To:     netdev@oss.sgi.com
cc:     linux-kernel@vger.rutgers.edu
Subject: [PATCH] CONFIG_NETFILTER_DEBUG removal
Date:   Tue, 30 Nov 1999 18:57:49 +1100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 15617
Lines: 498

The netfilter debug flags (marking where an skb had been) were a great
idea for security, but fragmentation, tunnelling and other
complexities kept giving false alarms.  No genuine failures have been
seen.

Hence, the debug option should be removed.

diff -urN linux-2.3-official/Documentation/Configure.help linux-2.3-mangled/Documentation/Configure.help
--- linux-2.3-official/Documentation/Configure.help	Tue Nov 30 17:58:57 1999
+++ linux-2.3-mangled/Documentation/Configure.help	Tue Nov 30 18:49:07 1999
@@ -1477,10 +1477,6 @@
   Chances are that you should say Y here if you compile a kernel which
   will run as a router and N for regular hosts. If unsure, say N.
  
-Network packet filtering debugging
-CONFIG_NETFILTER_DEBUG
-  Say Y to make sure packets aren't leaking.
-
 SYN flood protection
 CONFIG_SYN_COOKIES
   Normal TCP/IP networking is open to an attack known as "SYN
diff -urN linux-2.3-official/arch/ppc/pmac_defconfig linux-2.3-mangled/arch/ppc/pmac_defconfig
--- linux-2.3-official/arch/ppc/pmac_defconfig	Tue Nov 30 17:58:32 1999
+++ linux-2.3-mangled/arch/ppc/pmac_defconfig	Tue Nov 30 18:49:07 1999
@@ -134,7 +134,6 @@
 # CONFIG_RTNETLINK is not set
 # CONFIG_NETLINK_DEV is not set
 CONFIG_NETFILTER=y
-# CONFIG_NETFILTER_DEBUG is not set
 # CONFIG_FILTER is not set
 CONFIG_UNIX=y
 CONFIG_INET=y
diff -urN linux-2.3-official/include/linux/netfilter.h linux-2.3-mangled/include/linux/netfilter.h
--- linux-2.3-official/include/linux/netfilter.h	Tue Nov 30 17:58:19 1999
+++ linux-2.3-mangled/include/linux/netfilter.h	Tue Nov 30 18:49:07 1999
@@ -103,14 +103,10 @@
 
 /* This is gross, but inline doesn't cut it for avoiding the function
    call in fast path: gcc doesn't inline (needs value tracking?). --RR */
-#ifdef CONFIG_NETFILTER_DEBUG
-#define NF_HOOK nf_hook_slow
-#else
 #define NF_HOOK(pf, hook, skb, indev, outdev, okfn)			\
 (list_empty(&nf_hooks[(pf)][(hook)])					\
  ? (okfn)(skb)								\
  : nf_hook_slow((pf), (hook), (skb), (indev), (outdev), (okfn)))
-#endif
 
 int nf_hook_slow(int pf, unsigned int hook, struct sk_buff *skb,
 		 struct net_device *indev, struct net_device *outdev,
@@ -158,10 +154,6 @@
 extern void nf_reinject(struct sk_buff *skb,
 			unsigned long mark,
 			unsigned int verdict);
-
-#ifdef CONFIG_NETFILTER_DEBUG
-extern void nf_dump_skb(int pf, struct sk_buff *skb);
-#endif
 
 /* FIXME: Before cache is ever used, this must be implemented for real. */
 extern void nf_invalidate_cache(int pf);
diff -urN linux-2.3-official/include/linux/netfilter_ipv4.h linux-2.3-mangled/include/linux/netfilter_ipv4.h
--- linux-2.3-official/include/linux/netfilter_ipv4.h	Tue Nov 30 17:58:19 1999
+++ linux-2.3-mangled/include/linux/netfilter_ipv4.h	Tue Nov 30 18:49:07 1999
@@ -49,15 +49,6 @@
 #define NF_IP_POST_ROUTING	4
 #define NF_IP_NUMHOOKS		5
 
-#ifdef CONFIG_NETFILTER_DEBUG
-#ifdef __KERNEL__
-void debug_print_hooks_ip(unsigned int nf_debug);
-void nf_debug_ip_local_deliver(struct sk_buff *skb);
-void nf_debug_ip_loopback_xmit(struct sk_buff *newskb);
-void nf_debug_ip_finish_output2(struct sk_buff *skb);
-#endif /*__KERNEL__*/
-#endif /*CONFIG_NETFILTER_DEBUG*/
-
 /* Arguments for setsockopt SOL_IP: */
 /* 2.0 firewalling went from 64 through 71 (and +256, +512, etc). */
 /* 2.2 firewalling (+ masq) went from 64 through 76 */
diff -urN linux-2.3-official/include/linux/skbuff.h linux-2.3-mangled/include/linux/skbuff.h
--- linux-2.3-official/include/linux/skbuff.h	Tue Nov 30 17:58:11 1999
+++ linux-2.3-mangled/include/linux/skbuff.h	Tue Nov 30 18:49:07 1999
@@ -116,9 +116,6 @@
 	__u32		nfreason;
 	/* Cache info */
 	__u32		nfcache;
-#ifdef CONFIG_NETFILTER_DEBUG
-        unsigned int nf_debug;
-#endif
 #endif /*CONFIG_NETFILTER*/
 #if defined(CONFIG_SHAPER) || defined(CONFIG_SHAPER_MODULE)
 	__u32		shapelatency;		/* Latency on frame */
diff -urN linux-2.3-official/net/Config.in linux-2.3-mangled/net/Config.in
--- linux-2.3-official/net/Config.in	Tue Nov 30 17:58:33 1999
+++ linux-2.3-mangled/net/Config.in	Tue Nov 30 18:49:07 1999
@@ -13,9 +13,6 @@
    tristate '  Netlink device emulation' CONFIG_NETLINK_DEV
 fi
 bool 'Network packet filtering (replaces ipchains)' CONFIG_NETFILTER
-if [ "$CONFIG_NETFILTER" = "y" ]; then
-   bool '  Network packet filtering debugging' CONFIG_NETFILTER_DEBUG
-fi
 bool 'Socket Filtering'  CONFIG_FILTER
 tristate 'Unix domain sockets' CONFIG_UNIX
 bool 'TCP/IP networking' CONFIG_INET
diff -urN linux-2.3-official/net/core/netfilter.c linux-2.3-mangled/net/core/netfilter.c
--- linux-2.3-official/net/core/netfilter.c	Tue Nov 30 17:58:19 1999
+++ linux-2.3-mangled/net/core/netfilter.c	Tue Nov 30 18:49:07 1999
@@ -26,7 +26,7 @@
  * of skbuffs queued for userspace, and not deregister a hook unless
  * this is zero, but that sucks.  Now, we simply check when the
  * packets come back: if the hook is gone, the packet is discarded. */
-#ifdef CONFIG_NETFILTER_DEBUG
+#if 0
 #define NFDEBUG(format, args...)  printk(format , ## args)
 #else
 #define NFDEBUG(format, args...)
@@ -57,13 +57,6 @@
 {
 	struct list_head *i;
 
-#ifdef CONFIG_NETFILTER_DEBUG
-	if (reg->pf<0 || reg->pf>=NPROTO || reg->hooknum >= NF_MAX_HOOKS) {
-		NFDEBUG("nf_register_hook: bad vals: pf=%i, hooknum=%u.\n",
-			reg->pf, reg->hooknum);
-		return -EINVAL;
-	}
-#endif
 	NFDEBUG("nf_register_hook: pf=%i hook=%u.\n", reg->pf, reg->hooknum);
 	
 	write_lock_bh(&nf_lock);
@@ -80,13 +73,6 @@
 
 void nf_unregister_hook(struct nf_hook_ops *reg)
 {
-#ifdef CONFIG_NETFILTER_DEBUG
-	if (reg->pf<0 || reg->pf>=NPROTO || reg->hooknum >= NF_MAX_HOOKS) {
-		NFDEBUG("nf_unregister_hook: bad vals: pf=%i, hooknum=%u.\n",
-			reg->pf, reg->hooknum);
-		return;
-	}
-#endif
 	write_lock_bh(&nf_lock);
 	list_del(&reg->list);
 	write_unlock_bh(&nf_lock);
@@ -105,22 +91,6 @@
 	struct list_head *i;
 	int ret = 0;
 
-#ifdef CONFIG_NETFILTER_DEBUG
-	if (reg->pf<0 || reg->pf>=NPROTO) {
-		NFDEBUG("nf_register_sockopt: bad val: pf=%i.\n", reg->pf);
-		return -EINVAL;
-	}
-	if (reg->set_optmin > reg->set_optmax) {
-		NFDEBUG("nf_register_sockopt: bad set val: min=%i max=%i.\n", 
-			reg->set_optmin, reg->set_optmax);
-		return -EINVAL;
-	}
-	if (reg->get_optmin > reg->get_optmax) {
-		NFDEBUG("nf_register_sockopt: bad get val: min=%i max=%i.\n", 
-			reg->get_optmin, reg->get_optmax);
-		return -EINVAL;
-	}
-#endif
 	if (down_interruptible(&nf_sockopt_mutex) != 0)
 		return -EINTR;
 
@@ -149,141 +119,12 @@
 
 void nf_unregister_sockopt(struct nf_sockopt_ops *reg)
 {
-#ifdef CONFIG_NETFILTER_DEBUG
-	if (reg->pf<0 || reg->pf>=NPROTO) {
-		NFDEBUG("nf_register_sockopt: bad val: pf=%i.\n", reg->pf);
-		return;
-	}
-#endif
 	/* No point being interruptible: we're probably in cleanup_module() */
 	down(&nf_sockopt_mutex);
 	list_del(&reg->list);
 	up(&nf_sockopt_mutex);
 }
 
-#ifdef CONFIG_NETFILTER_DEBUG
-#include <net/ip.h>
-#include <net/route.h>
-#include <net/tcp.h>
-#include <linux/netfilter_ipv4.h>
-
-void nf_dump_skb(int pf, struct sk_buff *skb)
-{
-	printk("skb: pf=%i %s dev=%s len=%u\n", 
-	       pf,
-	       skb->sk ? "(owned)" : "(unowned)",
-	       skb->dev ? skb->dev->name : "(no dev)",
-	       skb->len);
-	switch (pf) {
-	case PF_INET: {
-		const struct iphdr *ip = skb->nh.iph;
-		__u32 *opt = (__u32 *) (ip + 1);
-		int opti;
-		__u16 src_port = 0, dst_port = 0;
-
-		if (ip->protocol == IPPROTO_TCP
-		    || ip->protocol == IPPROTO_UDP) {
-			struct tcphdr *tcp=(struct tcphdr *)((__u32 *)ip+ip->ihl);
-			src_port = ntohs(tcp->source);
-			dst_port = ntohs(tcp->dest);
-		}
-	
-		printk("PROTO=%d %ld.%ld.%ld.%ld:%hu %ld.%ld.%ld.%ld:%hu"
-		       " L=%hu S=0x%2.2hX I=%hu F=0x%4.4hX T=%hu",
-		       ip->protocol,
-		       (ntohl(ip->saddr)>>24)&0xFF,
-		       (ntohl(ip->saddr)>>16)&0xFF,
-		       (ntohl(ip->saddr)>>8)&0xFF,
-		       (ntohl(ip->saddr))&0xFF,
-		       src_port,
-		       (ntohl(ip->daddr)>>24)&0xFF,
-		       (ntohl(ip->daddr)>>16)&0xFF,
-		       (ntohl(ip->daddr)>>8)&0xFF,
-		       (ntohl(ip->daddr))&0xFF,
-		       dst_port,
-		       ntohs(ip->tot_len), ip->tos, ntohs(ip->id),
-		       ntohs(ip->frag_off), ip->ttl);
-
-		for (opti = 0; opti < (ip->ihl - sizeof(struct iphdr) / 4); opti++)
-			printk(" O=0x%8.8X", *opt++);
-		printk("\n");
-	}
-	}
-}
-
-void nf_debug_ip_local_deliver(struct sk_buff *skb)
-{
-	/* If it's a loopback packet, it must have come through
-	 * NF_IP_LOCAL_OUT, NF_IP_RAW_INPUT, NF_IP_PRE_ROUTING and
-	 * NF_IP_LOCAL_IN.  Otherwise, must have gone through
-	 * NF_IP_RAW_INPUT and NF_IP_PRE_ROUTING.  */
-	if (!skb->dev) {
-		printk("ip_local_deliver: skb->dev is NULL.\n");
-	}
-	else if (strcmp(skb->dev->name, "lo") == 0) {
-		if (skb->nf_debug != ((1 << NF_IP_LOCAL_OUT)
-				      | (1 << NF_IP_POST_ROUTING)
-				      | (1 << NF_IP_PRE_ROUTING)
-				      | (1 << NF_IP_LOCAL_IN))) {
-			printk("ip_local_deliver: bad loopback skb: ");
-			debug_print_hooks_ip(skb->nf_debug);
-			nf_dump_skb(PF_INET, skb);
-		}
-	}
-	else {
-		if (skb->nf_debug != ((1<<NF_IP_PRE_ROUTING)
-				      | (1<<NF_IP_LOCAL_IN))) {
-			printk("ip_local_deliver: bad non-lo skb: ");
-			debug_print_hooks_ip(skb->nf_debug);
-			nf_dump_skb(PF_INET, skb);
-		}
-	}
-}
-
-void nf_debug_ip_loopback_xmit(struct sk_buff *newskb)
-{
-	if (newskb->nf_debug != ((1 << NF_IP_LOCAL_OUT)
-				 | (1 << NF_IP_POST_ROUTING))) {
-		printk("ip_dev_loopback_xmit: bad owned skb = %p: ", 
-		       newskb);
-		debug_print_hooks_ip(newskb->nf_debug);
-		nf_dump_skb(PF_INET, newskb);
-	}
-	/* Clear to avoid confusing input check */
-	newskb->nf_debug = 0;
-}
-
-void nf_debug_ip_finish_output2(struct sk_buff *skb)
-{
-	/* If it's owned, it must have gone through the
-	 * NF_IP_LOCAL_OUT and NF_IP_POST_ROUTING.
-	 * Otherwise, must have gone through NF_IP_RAW_INPUT,
-	 * NF_IP_PRE_ROUTING, NF_IP_FORWARD and NF_IP_POST_ROUTING.
-	 */
-	if (skb->sk) {
-		if (skb->nf_debug != ((1 << NF_IP_LOCAL_OUT)
-				      | (1 << NF_IP_POST_ROUTING))) {
-			printk("ip_finish_output: bad owned skb = %p: ", skb);
-			debug_print_hooks_ip(skb->nf_debug);
-			nf_dump_skb(PF_INET, skb);
-		}
-	} else {
-		if (skb->nf_debug != ((1 << NF_IP_PRE_ROUTING)
-#ifdef CONFIG_IP_NETFILTER_RAW_INPUT
-				      | (1 << NF_IP_RAW_INPUT)
-#endif
-				      | (1 << NF_IP_FORWARD)
-				      | (1 << NF_IP_POST_ROUTING))) {
-			printk("ip_finish_output: bad unowned skb = %p: ",skb);
-			debug_print_hooks_ip(skb->nf_debug);
-			nf_dump_skb(PF_INET, skb);
-		}
-	}
-}
-
-
-#endif /*CONFIG_NETFILTER_DEBUG*/
-
 void nf_cacheflush(int pf, unsigned int hook, const void *packet,
 		   const struct net_device *indev, const struct net_device *outdev,
 		   __u32 packetcount, __u32 bytecount)
@@ -359,25 +200,13 @@
 		struct nf_hook_ops *elem = (struct nf_hook_ops *)*i;
 		switch (elem->hook(hook, skb, indev, outdev)) {
 		case NF_QUEUE:
-			NFDEBUG("nf_iterate: NF_QUEUE for %p.\n", *skb);
 			return NF_QUEUE;
 
 		case NF_STOLEN:
-			NFDEBUG("nf_iterate: NF_STOLEN for %p.\n", *skb);
 			return NF_STOLEN;
 
 		case NF_DROP:
-			NFDEBUG("nf_iterate: NF_DROP for %p.\n", *skb);
 			return NF_DROP;
-
-#ifdef CONFIG_NETFILTER_DEBUG
-		case NF_ACCEPT:
-			break;
-
-		default:
-			NFDEBUG("Evil return from %p(%u).\n", 
-				elem->hook, hook);
-#endif
 		}
 	}
 	return NF_ACCEPT;
@@ -427,8 +256,6 @@
 			}
 			/* Hand it to userspace for collection */
 			skb_queue_tail(&recip->wake->skbq, skb);
-			NFDEBUG("Waking up pf=%i hook=%u mark=%lu reason=%u\n",
-				pf, hook, skb->nfmark, skb->nfreason);
 			wake_up_interruptible(&recip->wake->sleep);
 
 			return;
@@ -454,26 +281,11 @@
 	unsigned int verdict;
 	int ret = 0;
 
-#ifdef CONFIG_NETFILTER_DEBUG
-	if (pf < 0 || pf >= NPROTO || hook >= NF_MAX_HOOKS) {
-		NFDEBUG("nf_hook: bad vals: pf=%i, hook=%u.\n",
-			pf, hook);
-		kfree_skb(skb);
-		return -EINVAL; /* -ECODERFUCKEDUP ?*/
-	}
-
-	if (skb->nf_debug & (1 << hook)) {
-		NFDEBUG("nf_hook: hook %i already set.\n", hook);
-		nf_dump_skb(pf, skb);
-	}
-	skb->nf_debug |= (1 << hook);
-#endif
 	read_lock_bh(&nf_lock);
 	elem = &nf_hooks[pf][hook];
 	verdict = nf_iterate(&nf_hooks[pf][hook], &skb, hook, indev,
 			     outdev, &elem);
 	if (verdict == NF_QUEUE) {
-		NFDEBUG("nf_hook: Verdict = QUEUE.\n");
 		nf_queue(skb, elem, pf, hook, indev, outdev, okfn);
 	}
 	read_unlock_bh(&nf_lock);
@@ -586,36 +398,6 @@
 void nf_invalidate_cache(int pf)
 {
 }
-
-#ifdef CONFIG_NETFILTER_DEBUG
-
-void debug_print_hooks_ip(unsigned int nf_debug)
-{
-	if (nf_debug & (1 << NF_IP_PRE_ROUTING)) {
-		printk("PRE_ROUTING ");
-		nf_debug ^= (1 << NF_IP_PRE_ROUTING);
-	}
-	if (nf_debug & (1 << NF_IP_LOCAL_IN)) {
-		printk("LOCAL_IN ");
-		nf_debug ^= (1 << NF_IP_LOCAL_IN);
-	}
-	if (nf_debug & (1 << NF_IP_FORWARD)) {
-		printk("FORWARD ");
-		nf_debug ^= (1 << NF_IP_FORWARD);
-	}
-	if (nf_debug & (1 << NF_IP_LOCAL_OUT)) {
-		printk("LOCAL_OUT ");
-		nf_debug ^= (1 << NF_IP_LOCAL_OUT);
-	}
-	if (nf_debug & (1 << NF_IP_POST_ROUTING)) {
-		printk("POST_ROUTING ");
-		nf_debug ^= (1 << NF_IP_POST_ROUTING);
-	}
-	if (nf_debug)
-		printk("Crap bits: 0x%04X", nf_debug);
-	printk("\n");
-}
-#endif /* CONFIG_NETFILTER_DEBUG */
 
 void __init netfilter_init(void)
 {
diff -urN linux-2.3-official/net/core/skbuff.c linux-2.3-mangled/net/core/skbuff.c
--- linux-2.3-official/net/core/skbuff.c	Tue Nov 30 17:58:36 1999
+++ linux-2.3-mangled/net/core/skbuff.c	Tue Nov 30 18:51:39 1999
@@ -202,9 +202,6 @@
 	skb->rx_dev = NULL;
 #ifdef CONFIG_NETFILTER
 	skb->nfmark = skb->nfreason = skb->nfcache = 0;
-#ifdef CONFIG_NETFILTER_DEBUG
-	skb->nf_debug = 0;
-#endif
 #endif
 	memset(skb->cb, 0, sizeof(skb->cb));
 	skb->priority = 0;
@@ -327,9 +324,6 @@
 	n->nfmark=skb->nfmark;
 	n->nfreason=skb->nfreason;
 	n->nfcache=skb->nfcache;
-#ifdef CONFIG_NETFILTER_DEBUG
-	n->nf_debug=skb->nf_debug;
-#endif
 #endif
 	return n;
 }
@@ -381,9 +375,6 @@
 	n->nfmark=skb->nfmark;
 	n->nfreason=skb->nfreason;
 	n->nfcache=skb->nfcache;
-#ifdef CONFIG_NETFILTER_DEBUG
-	n->nf_debug=skb->nf_debug;
-#endif
 #endif
 	return n;
 }
diff -urN linux-2.3-official/net/ipv4/ip_fragment.c linux-2.3-mangled/net/ipv4/ip_fragment.c
--- linux-2.3-official/net/ipv4/ip_fragment.c	Tue Nov 30 17:57:53 1999
+++ linux-2.3-mangled/net/ipv4/ip_fragment.c	Tue Nov 30 18:49:07 1999
@@ -387,10 +387,6 @@
 	*/
 	skb->security = qp->fragments->skb->security;
 
-#ifdef CONFIG_NETFILTER_DEBUG
-	skb->nf_debug = qp->fragments->skb->nf_debug;
-#endif
-
 	/* Done with all fragments. Fixup the new IP header. */
 	iph = skb->nh.iph;
 	iph->frag_off = 0;
diff -urN linux-2.3-official/net/ipv4/ip_input.c linux-2.3-mangled/net/ipv4/ip_input.c
--- linux-2.3-official/net/ipv4/ip_input.c	Tue Nov 30 17:57:44 1999
+++ linux-2.3-mangled/net/ipv4/ip_input.c	Tue Nov 30 18:49:07 1999
@@ -215,10 +215,6 @@
 {
 	struct iphdr *iph = skb->nh.iph;
 
-#ifdef CONFIG_NETFILTER_DEBUG
-	nf_debug_ip_local_deliver(skb);
-#endif /*CONFIG_NETFILTER_DEBUG*/
-
 	/* Free rx_dev before enqueueing to sockets */
 	if (skb->rx_dev) {
 		dev_put(skb->rx_dev);
diff -urN linux-2.3-official/net/ipv4/ip_output.c linux-2.3-mangled/net/ipv4/ip_output.c
--- linux-2.3-official/net/ipv4/ip_output.c	Tue Nov 30 17:58:59 1999
+++ linux-2.3-mangled/net/ipv4/ip_output.c	Tue Nov 30 18:49:07 1999
@@ -100,9 +100,6 @@
 	newskb->ip_summed = CHECKSUM_UNNECESSARY;
 	BUG_TRAP(newskb->dst);
 
-#ifdef CONFIG_NETFILTER_DEBUG
-	nf_debug_ip_loopback_xmit(newskb);
-#endif
 	netif_rx(newskb);
 	return 0;
 }
@@ -190,10 +187,6 @@
 {
 	struct dst_entry *dst = skb->dst;
 	struct hh_cache *hh = dst->hh;
-
-#ifdef CONFIG_NETFILTER_DEBUG
-	nf_debug_ip_finish_output2(skb);
-#endif /*CONFIG_NETFILTER_DEBUG*/
 
 	if (hh) {
 		read_lock_bh(&hh->hh_lock);

--
Hacking time.

From owner-netdev@oss.sgi.com Tue Nov 30 02:50:26 1999
Received:  by oss.sgi.com id <S305165AbPK3Krq>;
	Tue, 30 Nov 1999 02:47:46 -0800
Received: from linuxcare.canberra.net.au ([203.29.91.49]:52742 "EHLO
        front.linuxcare.com.au") by oss.sgi.com with ESMTP
	id <S305156AbPK3KrW>; Tue, 30 Nov 1999 02:47:22 -0800
Received: from gargle.linuxcare.com.au (stick.linuxcare.com.au [10.61.2.17])
	by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) with ESMTP id VAA27947
	for <netdev@oss.sgi.com>; Tue, 30 Nov 1999 21:54:02 +1100
Received: from rustcorp.com.au (really [127.0.0.1]) by rustcorp.com.au
	via in.smtpd with esmtp
	id <m11sl07-000DsYC@gargle.linuxcare.com.au> (Debian Smail3.2.0.102)
	for <netdev@oss.sgi.com>; Tue, 30 Nov 1999 21:59:15 +1100 (EST) 
Message-Id: <m11sl07-000DsYC@gargle.linuxcare.com.au>
From:   Paul Rusty Russell <Paul.Russell@linuxcare.com.au>
To:     netdev@oss.sgi.com
Subject: [PATCH] packet fragmentation after POST_ROUTING netfilter hook
Date:   Tue, 30 Nov 1999 21:59:15 +1100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 4112
Lines: 139

At the moment, a fragment comes in, must be defragmented for
connection tracking.  It is then forwarded, fragmented, then must be
defragemented AGAIN for NAT in POST_ROUTING hook.  Ick.

This patch defers fragmentation to past the hook, by effectively
reversing ip_send and ip_finish_output (renaming ip_finish_output
because it's EXPORTed), and making everyone use ip_send (it's harmless
to set skb->dev and skb->protocol AFAICT).

I think this also means that the fragment: part in ip_queue_xmit2 can
be reduced, since skb->dst->output() will now do fragmenting.

This is a patch mainly to how much Alexey hates it. 8-)

Rusty.
PS.  Alexey; I saw your photograph in Linux Magazine: very
     disappointed!  I hope, at least, that *your* head? 8-)

diff -ur linux-2.3-official/include/net/ip.h linux-2.3-mangled/include/net/ip.h
--- linux-2.3-official/include/net/ip.h	Tue Nov 30 19:08:08 1999
+++ linux-2.3-mangled/include/net/ip.h	Tue Nov 30 21:43:10 1999
@@ -29,6 +29,7 @@
 #include <linux/netdevice.h>
 #include <linux/inetdevice.h>
 #include <linux/in_route.h>
+#include <linux/netfilter_ipv4.h>
 #include <net/route.h>
 #include <net/arp.h>
 
@@ -138,7 +139,7 @@
 void ip_send_reply(struct sock *sk, struct sk_buff *skb, struct ip_reply_arg *arg,
 		   unsigned int len); 
 
-extern __inline__ int ip_finish_output(struct sk_buff *skb);
+extern int ip_finish_output_and_frag(struct sk_buff *skb);
 
 struct ipv4_config
 {
@@ -156,10 +157,13 @@
 #ifdef CONFIG_INET
 extern __inline__ int ip_send(struct sk_buff *skb)
 {
-	if (skb->len > skb->dst->pmtu)
-		return ip_fragment(skb, ip_finish_output);
-	else
-		return ip_finish_output(skb);
+	struct net_device *dev = skb->dst->dev;
+
+	skb->dev = dev;
+	skb->protocol = __constant_htons(ETH_P_IP);
+
+	return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev,
+		       ip_finish_output_and_frag);
 }
 
 extern __inline__
diff -ur linux-2.3-official/net/ipv4/ip_output.c linux-2.3-mangled/net/ipv4/ip_output.c
--- linux-2.3-official/net/ipv4/ip_output.c	Tue Nov 30 17:58:59 1999
+++ linux-2.3-mangled/net/ipv4/ip_output.c	Tue Nov 30 21:45:38 1999
@@ -209,22 +209,18 @@
 	return -EINVAL;
 }
 
-__inline__ int ip_finish_output(struct sk_buff *skb)
+int ip_finish_output_and_frag(struct sk_buff *skb)
 {
-	struct net_device *dev = skb->dst->dev;
-
-	skb->dev = dev;
-	skb->protocol = __constant_htons(ETH_P_IP);
-
-	return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev,
-		       ip_finish_output2);
+	if (skb->len > skb->dst->pmtu)
+		return ip_fragment(skb, ip_finish_output2);
+	else
+		return ip_finish_output2(skb);
 }
 
 int ip_mc_output(struct sk_buff *skb)
 {
 	struct sock *sk = skb->sk;
 	struct rtable *rt = (struct rtable*)skb->dst;
-	struct net_device *dev = rt->u.dst.dev;
 
 	/*
 	 *	If the indicated interface is up and running, send the packet.
@@ -235,9 +231,6 @@
 		ip_do_nat(skb);
 #endif
 
-	skb->dev = dev;
-	skb->protocol = __constant_htons(ETH_P_IP);
-
 	/*
 	 *	Multicasts are looped back for other local users
 	 */
@@ -277,7 +270,7 @@
 				newskb->dev, ip_dev_loopback_xmit);
 	}
 
-	return ip_finish_output(skb);
+	return ip_send(skb);
 }
 
 int ip_output(struct sk_buff *skb)
@@ -293,7 +286,7 @@
 		ip_do_nat(skb);
 #endif
 
-	return ip_finish_output(skb);
+	return ip_send(skb);
 }
 
 /* Queues a packet to be sent, and starts the transmitter if necessary.  
@@ -837,6 +830,8 @@
 
 		skb2->pkt_type = skb->pkt_type;
 		skb2->priority = skb->priority;
+		skb2->dev = skb->dev;
+		skb2->protocol = skb->protocol;
 		skb_reserve(skb2, (dev->hard_header_len+15)&~15);
 		skb_put(skb2, len + hlen);
 		skb2->nh.raw = skb2->data;
diff -ur linux-2.3-official/net/netsyms.c linux-2.3-mangled/net/netsyms.c
--- linux-2.3-official/net/netsyms.c	Tue Nov 30 17:58:59 1999
+++ linux-2.3-mangled/net/netsyms.c	Tue Nov 30 21:36:48 1999
@@ -239,7 +239,7 @@
 EXPORT_SYMBOL(in_aton);
 EXPORT_SYMBOL(ip_mc_inc_group);
 EXPORT_SYMBOL(ip_mc_dec_group);
-EXPORT_SYMBOL(ip_finish_output);
+EXPORT_SYMBOL(ip_finish_output_and_frag);
 EXPORT_SYMBOL(inet_dgram_ops);
 EXPORT_SYMBOL(ip_cmsg_recv);
 EXPORT_SYMBOL(inet_addr_type); 

--
Hacking time.