From owner-netdev@oss.sgi.com Sat Jul  1 07:52:46 2000
Received:  by oss.sgi.com id <S42226AbQGAOwg>;
	Sat, 1 Jul 2000 07:52:36 -0700
Received: from smtprch2.nortelnetworks.com ([192.135.215.15]:20356 "EHLO
        smtprch2.nortel.com") by oss.sgi.com with ESMTP id <S42200AbQGAOwP>;
	Sat, 1 Jul 2000 07:52:15 -0700
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Sat, 1 Jul 2000 09:48:11 -0500
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.2650.21) 
          id NQCK3909; Sat, 1 Jul 2000 09:51:17 -0500
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.2650.21) 
          id NCLF849C; Sun, 2 Jul 2000 00:51:25 +1000
Received: from uow.edu.au (IDENT:akpm@[47.181.194.49]) 
          by pwold011.asiapac.nortel.com (8.9.3/8.9.3) with ESMTP id AAA17524 
          for <netdev@oss.sgi.com>; Sun, 2 Jul 2000 00:51:24 +1000
Message-ID: <395E0686.BC319D33@uow.edu.au>
Date:   Sun, 02 Jul 2000 00:56:06 +1000
X-Sybari-Space: 00000000 00000000 00000000
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdk i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: 802.3x flow control
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <andrewm@uow.edu.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

What's the story on MAC-level flow control?

The only Linux drivers I can find which do this are Donald's latest
eepro100 and 3com's 3c90x.  starfire seems to have infrastructure but
never turns it on.

Is this considered a useful thing to have?

This abstract:
http://www.computer.org/proceedings/lcn/0309/03090160abs.htm makes it
sound bad.

This article: http://www.nwfusion.com/netresources/0913flow.html and the
vendor opinions at http://www.nwfusion.com/netresources/0913flow2.html
show mixed opinions.

I would have thought that if a switch is doing 10<->100 conversion then
it would be a good thing to have for non-TCP protocols (eg, streaming
media across the LAN, NFS).


I've altered one of Donald's tools so it produces 802.3x PAUSE frames
and I've got it all working in 3c59x (as a module option).    Should I
have bothered?

From owner-netdev@oss.sgi.com Sat Jul  1 09:34:07 2000
Received:  by oss.sgi.com id <S42227AbQGAQdq>;
	Sat, 1 Jul 2000 09:33:46 -0700
Received: from adsl-151-196-251-33.bellatlantic.net ([151.196.251.33]:14575
        "EHLO vaio.greennet") by oss.sgi.com with ESMTP id <S42200AbQGAQd1>;
	Sat, 1 Jul 2000 09:33:27 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id MAA17348;
	Sat, 1 Jul 2000 12:37:30 -0400
Date:   Sat, 1 Jul 2000 12:37:30 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Andrew Morton <andrewm@uow.edu.au>
cc:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: 802.3x flow control
In-Reply-To: <395E0686.BC319D33@uow.edu.au>
Message-ID: <Pine.LNX.4.10.10007011133120.6225-100000@vaio.greennet>
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 Sun, 2 Jul 2000, Andrew Morton wrote:

> What's the story on MAC-level flow control?
> 
> The only Linux drivers I can find which do this are Donald's latest
> eepro100 and 3com's 3c90x.  starfire seems to have infrastructure but
> never turns it on.

Some updated chips that have added flow control and have on-chip
transceivers look at the negotiation results and turn on flow control
without driver intervention.  So you don't see explicit driver support.
This is good for me because it's not always clear which chip revision had
flow control added.

Surprisingly, flow control has had a major impact on driver Rx structure.
Most designs automatically trigger flow control when the chip is about to
run out of Rx buffers.  My drivers used to be structured to never run out of
Rx buffers to avoid this case -- they recycled Rx buffers rather than
passing them to the software queue layer when they were running short.

So I changed the drivers to run out of Rx buffers(!) when the system
(usually the slow skbuff allocation routine) couldn't keep up with traffic.
Note the discussion last week on the netdev mailing list about changing this
back.  People don't understand that was the behavior the drivers used to
have, and it was explicitly changed for this reason.  You have to understand
the Big Picture.

Note that you cannot fake flow control with driver software.  The Rx pause
frames must be put at the very front of the transmit queue, and you have to
handle Tx resume frames even if you have no Rx buffers lest you end up
deadlocked.

> Is this considered a useful thing to have?
> This abstract:
> http://www.computer.org/proceedings/lcn/0309/03090160abs.htm makes it
> sound bad.

When reading papers list this you should be aware of an "ATM bias".  There
are people that claim "if it doesn't have the functionality that ATM
promised, it's not worth doing".

When ATM was introduced, it claimed end-to-end flow control and reserved
bandwidth.  It took many years of additional development and dramatically
more hardware and software than was initially claimed before this could even
be demoed.  Even today a multi-vendor ATM network might not fulfill a
bandwidth reservation.

Ethernet flow control is a good feature to have in a typical LAN with
bursty traffic and a mix of device speeds.  It doesn't help, and likely
hurts, when you have saturating  (e.g. streaming multimedia) traffic.

Ethernet flow control certainly shouldn't be used to do end-to-end traffic
flow control.  Think of it like electrical power wiring.  It's much less
complicated to install thicker wiring than to have a complicated system that
switches off the neighbor's water heater when you turn on your microwave.
Ethernet flow control is like a circuit breaker that trips when you plug too
many lamps into the same outlet, 

> This article: http://www.nwfusion.com/netresources/0913flow.html and the
> vendor opinions at http://www.nwfusion.com/netresources/0913flow2.html
> show mixed opinions.

That's good coverage of the issues, biased by some vendor justification for
their approach.

> I would have thought that if a switch is doing 10<->100 conversion then
> it would be a good thing to have for non-TCP protocols (eg, streaming
> media across the LAN, NFS).

Simple streaming is where flow control can fall down.  If you have bursty
traffic on top of 50% or less streaming traffic, then flow control can work
great.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf Clusters / Linux Installations
Annapolis MD 21403



From owner-netdev@oss.sgi.com Mon Jul  3 23:36:53 2000
Received:  by oss.sgi.com id <S42233AbQGDGgc>;
	Mon, 3 Jul 2000 23:36:32 -0700
Received: from saw.sw.com.sg ([203.120.9.98]:63113 "HELO saw.sw.com.sg")
	by oss.sgi.com with SMTP id <S42203AbQGDGgD>;
	Mon, 3 Jul 2000 23:36:03 -0700
Received: (qmail 3907 invoked by uid 577); 4 Jul 2000 06:36:05 -0000
Message-ID: <20000704143605.A3892@saw.sw.com.sg>
Date:   Tue, 4 Jul 2000 14:36:05 +0800
From:   Andrey Savochkin <saw@saw.sw.com.sg>
To:     Donald Becker <becker@scyld.com>,
        Andrew Morton <andrewm@uow.edu.au>
Cc:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: 802.3x flow control
References: <395E0686.BC319D33@uow.edu.au> <Pine.LNX.4.10.10007011133120.6225-100000@vaio.greennet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2i
In-Reply-To: <Pine.LNX.4.10.10007011133120.6225-100000@vaio.greennet>; from "Donald Becker" on Sat, Jul 01, 2000 at 12:37:30PM
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello,

On Sat, Jul 01, 2000 at 12:37:30PM -0400, Donald Becker wrote:
> So I changed the drivers to run out of Rx buffers(!) when the system
> (usually the slow skbuff allocation routine) couldn't keep up with traffic.
> Note the discussion last week on the netdev mailing list about changing this
> back.  People don't understand that was the behavior the drivers used to

Thanks for the comments.
However, I need to mention that you handle the out-of-buffers condition not
very well, at least in eepro100.
The first obvious point is that you shouldn't restart RU under such
conditions in receiver-not-ready path of speedo_interrupt().  Otherwise the
card immediately and completely hangs.

As an additional note to the recent netdev discussion, I should admit that I
was too quick with my comments.
The current eepro100 drivers in 2.2.16 and 2.4.0 do allow the card to reach
to end of RX buffer ring and stop operations.  However, they delay and do
not pass to the upper layers the last buffer from the ring, for a completely
different reason.  Certainly, as Andrew's mentioned, this part of code is a
bit messy, and I hope to clean it up later.

> have, and it was explicitly changed for this reason.  You have to understand
> the Big Picture.

I wish we heard about code author's intentions more frequently...

Best regards
		Andrey

From owner-netdev@oss.sgi.com Tue Jul  4 02:11:33 2000
Received:  by oss.sgi.com id <S42234AbQGDJLO>;
	Tue, 4 Jul 2000 02:11:14 -0700
Received: from porsta.cs.Helsinki.FI ([128.214.48.124]:10836 "EHLO
        porsta.cs.Helsinki.FI") by oss.sgi.com with ESMTP id <S42203AbQGDJLH>;
	Tue, 4 Jul 2000 02:11:07 -0700
Received: from cs.helsinki.fi (sarolaht@kiviletto.cs.Helsinki.FI [128.214.9.223]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with ESMTP id MAA05580 for <netdev@oss.sgi.com>; Tue, 4 Jul 2000 12:11:14 +0300
Message-ID: <3961AA34.92CD9E98@cs.helsinki.fi>
Date:   Tue, 04 Jul 2000 12:11:16 +0300
From:   Pasi Sarolahti <sarolaht@cs.Helsinki.FI>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
Subject: Problems with parsing tcp options on linux 2.2 and 2.4-pre
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

Hi,

I'm testing the effects of different TCP modifications on
the communication performance on slow links, generating some packet
losses on the way. I have had problems with SACK option. Everything is
fine when I have both tcp_sack and tcp_timestamps set on, but if I try
sack without timestamps it seems like the sender doesn't care about the
sack blocks at all and performs as if it was used without the sack
option. This behaviour occurs at
least in 2.2.12 and 2.3.99-pre9 kernels. Receiving end seems to generate
the sack blocks correctly. The data I used was unidirectional bulk data
generated by ttcp.

After a couple of printk - enhanced rounds I did a simple test
commenting out the following in tcp_fast_parse_options():

/* If we didn't send out any options ignore them all. */
        if (tp->tcp_header_len == sizeof(struct tcphdr))
                return 0;

After this SACK started working nicely. Are we facing a bug or do I have
some kind of misunderstanding here?

- Pasi

From owner-netdev@oss.sgi.com Tue Jul  4 06:34:13 2000
Received:  by oss.sgi.com id <S42239AbQGDNeD>;
	Tue, 4 Jul 2000 06:34:03 -0700
Received: from mail0.u-aizu.ac.jp ([163.143.1.43]:18082 "EHLO
        mail0.u-aizu.ac.jp") by oss.sgi.com with ESMTP id <S42236AbQGDNdj>;
	Tue, 4 Jul 2000 06:33:39 -0700
Received: from ccultra2.u-aizu.ac.jp (ccultra2 [163.143.99.104]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP
	id WAA19961 for <netdev@oss.sgi.com>; Tue, 4 Jul 2000 22:33:31 +0900 (JST)
Received: from ccultra2.u-aizu.ac.jp (vssct42.u-aizu.ac.jp [163.143.180.156])
	by ccultra2.u-aizu.ac.jp (8.9.3+Sun/8.8.8) with ESMTP id WAA26611
	for <netdev@oss.sgi.com>; Tue, 4 Jul 2000 22:29:19 +0900 (JST)
Message-ID: <3961E7F0.878CB46D@ccultra2.u-aizu.ac.jp>
Date:   Tue, 04 Jul 2000 22:34:40 +0900
From:   Behcet Sarikaya <sarikaya@ccultra2.u-aizu.ac.jp>
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To:     netdev@oss.sgi.com
Subject: Linux Wavelan Driver wvlan does not support IPv6?
References: <BGEJIPLJJPEEOEACMGEIOEJDCAAA.coronach@succubus.dhis.org>
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello,
  Does someone has a fix to the problem:
Linux Wavelan PCMCIA card driver at:
http://www.fasta.fh-dortmund.de/users/andy/wvlan/

does not  work on IPv6?

It seems that with that driver the source addresses are set to 0. If
someone were able hack it, let me know.

Behcet Sarikaya
University of Aizu


From owner-netdev@oss.sgi.com Tue Jul  4 10:43:15 2000
Received:  by oss.sgi.com id <S42247AbQGDRnF>;
	Tue, 4 Jul 2000 10:43:05 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:9471 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42246AbQGDRm6>; Tue, 4 Jul 2000 10:42:58 -0700
Received: from fred.muc.de (none@ns1195.munich.netsurf.de [195.180.235.195])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id TAA27001;
	Tue, 4 Jul 2000 19:42:45 +0200 (MET DST)
Received: from andi by fred.muc.de with local (Exim 2.05 #1)
	id 139STy-0000Jp-00; Tue, 4 Jul 2000 15:11:22 +0200
Date:   Tue, 4 Jul 2000 15:11:22 +0200
From:   Andi Kleen <ak@muc.de>
To:     Pasi Sarolahti <sarolaht@cs.helsinki.fi>
Cc:     netdev@oss.sgi.com
Subject: Re: Problems with parsing tcp options on linux 2.2 and 2.4-pre
Message-ID: <20000704151122.A1221@fred.muc.de>
References: <3961AA34.92CD9E98@cs.helsinki.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <3961AA34.92CD9E98@cs.helsinki.fi>; from Pasi Sarolahti on Tue, Jul 04, 2000 at 11:12:39AM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Jul 04, 2000 at 11:12:39AM +0200, Pasi Sarolahti wrote:
> 
> After a couple of printk - enhanced rounds I did a simple test
> commenting out the following in tcp_fast_parse_options():
> 
> /* If we didn't send out any options ignore them all. */
>         if (tp->tcp_header_len == sizeof(struct tcphdr))
>                 return 0;
> 
> After this SACK started working nicely. Are we facing a bug or do I have
> some kind of misunderstanding here?

Yes, it is a long standing bug that is fixed in 2.2.17pre9


-Andi

-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Tue Jul  4 10:54:45 2000
Received:  by oss.sgi.com id <S42245AbQGDRyZ>;
	Tue, 4 Jul 2000 10:54:25 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:21771 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42242AbQGDRyQ>;
	Tue, 4 Jul 2000 10:54:16 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA25694; Tue, 4 Jul 2000 21:40:55 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200007041740.VAA25694@ms2.inr.ac.ru>
Subject: Re: Problems with parsing tcp options on linux 2.2 and 2.4-pre
To:     sarolaht@cs.Helsinki.FI (Pasi Sarolahti)
Date:   Tue, 4 Jul 2000 21:40:55 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <3961AA34.92CD9E98@cs.helsinki.fi> from "Pasi Sarolahti" at Jul 4, 0 02:13:14 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 171       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> After this SACK started working nicely. Are we facing a bug

Yes, of course. It has been fixed in the latest 2.2 and will be
fixed in 2.4 soon or later.

Alexey

From owner-netdev@oss.sgi.com Tue Jul  4 16:11:46 2000
Received:  by oss.sgi.com id <S42249AbQGDXLh>;
	Tue, 4 Jul 2000 16:11:37 -0700
Received: from sith.mimuw.edu.pl ([193.0.97.1]:47364 "HELO sith.mimuw.edu.pl")
	by oss.sgi.com with SMTP id <S42246AbQGDXLI>;
	Tue, 4 Jul 2000 16:11:08 -0700
Received: (qmail 3466 invoked by uid 601); 4 Jul 2000 23:11:42 -0000
Date:   Wed, 5 Jul 2000 01:11:42 +0200
From:   Jan Rekorajski <baggins@sith.mimuw.edu.pl>
To:     netfilter@samba.org, netdev@oss.sgi.com
Subject: iptable_nat seriously b0rken
Message-ID: <20000705011142.A2931@sith.mimuw.edu.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0pre1i
X-Operating-System: Linux 2.4.0-test2-ac2 i586
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Please CC answers to me as I'm not subscribed to the lists.

The problem is simple, iptable_nat kills sit tunnels, see this:

7: sit1@lec0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1480 qdisc noqueue 
    link/sit 193.0.97.15 peer 193.219.28.246
    inet6 fe80::c100:610f/128 scope link 
    inet6 3ffe:8010:70::2/126 scope global 

Normal, configured tunnel, local IPv6 is 3ffe:8010:70::2, remote
is 3ffe:8010:70::1

spider /root~# ping6 3ffe:8010:70::1
PING 3ffe:8010:70::1(6bone-gw.icm.edu.pl) 56 data bytes
64 bytes from 6bone-gw.icm.edu.pl: icmp_seq=0 hops=64 time=7.0 ms
64 bytes from 6bone-gw.icm.edu.pl: icmp_seq=1 hops=64 time=6.5 ms
64 bytes from 6bone-gw.icm.edu.pl: icmp_seq=2 hops=64 time=5.1 ms

--- 3ffe:8010:70::1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 5.1/6.2/7.0 ms

A you can see it works...

spider /root~# modprobe ip_tables

spider /root~# ping6 3ffe:8010:70::1
PING 3ffe:8010:70::1(6bone-gw.icm.edu.pl) 56 data bytes
64 bytes from 6bone-gw.icm.edu.pl: icmp_seq=0 hops=64 time=6.8 ms
64 bytes from 6bone-gw.icm.edu.pl: icmp_seq=1 hops=64 time=7.2 ms

--- 3ffe:8010:70::1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 6.8/7.0/7.2 ms

...it still works...

spider /root~# modprobe iptable_nat

spider /root~# ping6 3ffe:8010:70::1
PING 3ffe:8010:70::1(6bone-gw.icm.edu.pl) 56 data bytes

--- 3ffe:8010:70::1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

...and now my tunnel has been converted into /dev/null, _what_ does
iptable_nat do that simple insmod kills the tunnel?

Kernels tested from 2.3.99-pre6 to 2.4.0-test1,
then 2.4.0-test3-pre2/ac2/pre1, 2.4.0-test2-ac19/ac7,
with, or without patches from netfilter CVS.

Jan
-- 
Jan Rękorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, type MANIAC         |                   -- TROOPS by Kevin Rubio

From owner-netdev@oss.sgi.com Tue Jul  4 18:35:47 2000
Received:  by oss.sgi.com id <S42256AbQGEBfh>;
	Tue, 4 Jul 2000 18:35:37 -0700
Received: from [129.254.164.217] ([129.254.164.217]:35743 "EHLO pec.etri.re.kr")
	by oss.sgi.com with ESMTP id <S42250AbQGEBfb>;
	Tue, 4 Jul 2000 18:35:31 -0700
Received: from qkim (qkim.etri.re.kr [129.254.164.96])
	by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id e651W6E00597
	for <netdev@oss.sgi.com>; Wed, 5 Jul 2000 10:32:07 +0900 (KST)
Message-ID: <002b01bfe621$3e60be20$60a4fe81@etri.re.kr>
From:   "Kim, Yong-Woon" <qkim@pec.etri.re.kr>
To:     <netdev@oss.sgi.com>
Subject: [Q] IPv6-native Linux
Date:   Wed, 5 Jul 2000 10:35:02 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="euc-kr"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4029.2901
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi!

I'm considering a development of an IPv6-native Linux which means that 
the IPv4 block is removed and only the IPv6 block is used for 
the Linux networking.

Is it a big job? 
or are minor modifications enough?

If possible, please give me some guideline for the modifications.
I mean where I have to work for the modifications.

Best regards,
Kim, Yong-Woon




From owner-netdev@oss.sgi.com Tue Jul  4 19:20:58 2000
Received:  by oss.sgi.com id <S42259AbQGECUr>;
	Tue, 4 Jul 2000 19:20:47 -0700
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:26889 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S42258AbQGECUq>; Tue, 4 Jul 2000 19:20:46 -0700
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id LAA30214;
	Wed, 5 Jul 2000 11:20:30 +0900
To:     qkim@pec.etri.re.kr
Cc:     netdev@oss.sgi.com, usagi@v6.linux.or.jp
Subject: Re: [Q] IPv6-native Linux
From:   Hideaki YOSHIFUJI <yoshfuji@v6.linux.or.jp>
In-Reply-To: <002b01bfe621$3e60be20$60a4fe81@etri.re.kr>
References: <002b01bfe621$3e60be20$60a4fe81@etri.re.kr>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000705112029H.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date:   Wed, 05 Jul 2000 11:20:29 +0900
X-Dispatcher: imput version 990905(IM130)
Lines:  24
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

In article <002b01bfe621$3e60be20$60a4fe81@etri.re.kr> (at Wed, 5 Jul 2000 10:35:02 +0900), "Kim, Yong-Woon" <qkim@pec.etri.re.kr> says:

> I'm considering a development of an IPv6-native Linux which means that 
> the IPv4 block is removed and only the IPv6 block is used for 
> the Linux networking.
> 
> Is it a big job? 
> or are minor modifications enough?

For kernel, you shuold re-construct codes.
remove codes from ipv4 referenced from ipv6 and put it a new "ip" layer
so that we can remove either (not both) ipv4 or ipv6.

For userland, DNS, NTP, NFS, NIS and other services don't speak 
IPv6 (on Linux) AFAIK.

We (new project mainly from Linux IPv6 Users JP) are planing to do these.

-- 
Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Thu Jul  6 18:09:32 2000
Received:  by oss.sgi.com id <S42219AbQGGBJX>;
	Thu, 6 Jul 2000 18:09:23 -0700
Received: from [203.17.0.30] ([203.17.0.30]:58862 "HELO halfway")
	by oss.sgi.com with SMTP id <S42203AbQGGBJD>;
	Thu, 6 Jul 2000 18:09:03 -0700
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway (Postfix) with ESMTP
	id C97BB8195; Thu,  6 Jul 2000 14:09:44 +1000 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     baggins@sith.mimuw.edu.pl
Cc:     Multiple recipients of list NETFILTER <netfilter@samba.org>,
        netdev@oss.sgi.com
Subject: Re: iptable_nat seriously b0rken 
In-reply-to: Your message of "Wed, 05 Jul 2000 09:12:18 +1000."
             <20000705011142.A2931@sith.mimuw.edu.pl> 
Date:   Thu, 06 Jul 2000 14:09:44 +1000
Message-Id: <20000706040944.C97BB8195@halfway>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In message <20000705011142.A2931@sith.mimuw.edu.pl> you write:
> Please CC answers to me as I'm not subscribed to the lists.
> 
> The problem is simple, iptable_nat kills sit tunnels, see this:

Dave, please merge.  Having tunnels pass the entunnelled packets
through the LOCAL_OUT hook is nicer anyway (from a filtering and
least-surprise perspective), and allows my connection tracking code to
do its magic...

Since ip_gre and ipip are basically identical, fixed them too.

Rusty.

diff -urN -X /tmp/filenPQH5d --minimal linux-2.4.0-test3-2/net/ipv4/ip_gre.c working-2.4.0-test3-2/net/ipv4/ip_gre.c
--- linux-2.4.0-test3-2/net/ipv4/ip_gre.c	Thu May 25 12:41:52 2000
+++ working-2.4.0-test3-2/net/ipv4/ip_gre.c	Thu Jul  6 14:03:16 2000
@@ -27,6 +27,7 @@
 #include <linux/in6.h>
 #include <linux/inetdevice.h>
 #include <linux/igmp.h>
+#include <linux/netfilter_ipv4.h>
 
 #include <net/sock.h>
 #include <net/ip.h>
@@ -616,6 +617,12 @@
 	return(0);
 }
 
+/* Need this wrapper because NF_HOOK takes the function address */
+static inline int do_ip_send(struct sk_buff *skb)
+{
+	return ip_send(skb);
+}
+
 static int ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct ip_tunnel *tunnel = (struct ip_tunnel*)dev->priv;
@@ -829,7 +836,8 @@
 
 	stats->tx_bytes += skb->len;
 	stats->tx_packets++;
-	ip_send(skb);
+	NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev,
+		do_ip_send);
 	tunnel->recursion--;
 	return 0;
 
diff -urN -X /tmp/filenPQH5d --minimal linux-2.4.0-test3-2/net/ipv4/ipip.c working-2.4.0-test3-2/net/ipv4/ipip.c
--- linux-2.4.0-test3-2/net/ipv4/ipip.c	Thu May 25 12:41:52 2000
+++ working-2.4.0-test3-2/net/ipv4/ipip.c	Thu Jul  6 14:01:41 2000
@@ -107,6 +107,7 @@
 #include <linux/if_arp.h>
 #include <linux/mroute.h>
 #include <linux/init.h>
+#include <linux/netfilter_ipv4.h>
 
 #include <net/sock.h>
 #include <net/ip.h>
@@ -499,6 +500,12 @@
 	return 0;
 }
 
+/* Need this wrapper because NF_HOOK takes the function address */
+static inline int do_ip_send(struct sk_buff *skb)
+{
+	return ip_send(skb);
+}
+
 /*
  *	This function assumes it is being called from dev_queue_xmit()
  *	and that skb is filled properly by that function.
@@ -631,7 +638,8 @@
 
 	stats->tx_bytes += skb->len;
 	stats->tx_packets++;
-	ip_send(skb);
+	NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev,
+		do_ip_send);
 	tunnel->recursion--;
 	return 0;
 
diff -urN -X /tmp/filenPQH5d --minimal linux-2.4.0-test3-2/net/ipv6/sit.c working-2.4.0-test3-2/net/ipv6/sit.c
--- linux-2.4.0-test3-2/net/ipv6/sit.c	Fri May 12 13:22:39 2000
+++ working-2.4.0-test3-2/net/ipv6/sit.c	Thu Jul  6 14:03:23 2000
@@ -29,6 +29,7 @@
 #include <linux/icmp.h>
 #include <asm/uaccess.h>
 #include <linux/init.h>
+#include <linux/netfilter_ipv4.h>
 
 #include <net/sock.h>
 #include <net/snmp.h>
@@ -404,6 +405,12 @@
 	return 0;
 }
 
+/* Need this wrapper because NF_HOOK takes the function address */
+static inline int do_ip_send(struct sk_buff *skb)
+{
+	return ip_send(skb);
+}
+
 /*
  *	This function assumes it is being called from dev_queue_xmit()
  *	and that skb is filled properly by that function.
@@ -559,7 +566,8 @@
 
 	stats->tx_bytes += skb->len;
 	stats->tx_packets++;
-	ip_send(skb);
+	NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev,
+		do_ip_send);
 
 	tunnel->recursion--;
 	return 0;
--
Hacking time.

From owner-netdev@oss.sgi.com Thu Jul  6 18:55:03 2000
Received:  by oss.sgi.com id <S42222AbQGGByx>;
	Thu, 6 Jul 2000 18:54:53 -0700
Received: from pizda.ninka.net ([216.101.162.242]:22915 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42203AbQGGByb>;
	Thu, 6 Jul 2000 18:54:31 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id SAA04231;
	Thu, 6 Jul 2000 18:44:51 -0700
Date:   Thu, 6 Jul 2000 18:44:51 -0700
Message-Id: <200007070144.SAA04231@pizda.ninka.net>
X-Authentication-Warning: pizda.ninka.net: davem set sender to davem@redhat.com using -f
From:   "David S. Miller" <davem@redhat.com>
To:     rusty@linuxcare.com.au
CC:     baggins@sith.mimuw.edu.pl, netfilter@samba.org, netdev@oss.sgi.com
In-reply-to: <20000706040944.C97BB8195@halfway> (message from Rusty Russell on
	Thu, 06 Jul 2000 14:09:44 +1000)
Subject: Re: iptable_nat seriously b0rken
References:  <20000706040944.C97BB8195@halfway>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   From: Rusty Russell <rusty@linuxcare.com.au>
   Date:   Thu, 06 Jul 2000 14:09:44 +1000

   Since ip_gre and ipip are basically identical, fixed them too.

Patch applied, thanks.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Thu Jul  6 21:18:18 2000
Received:  by oss.sgi.com id <S42224AbQGGESI>;
	Thu, 6 Jul 2000 21:18:08 -0700
Received: from [203.17.0.30] ([203.17.0.30]:15345 "HELO halfway")
	by oss.sgi.com with SMTP id <S42223AbQGGERp>;
	Thu, 6 Jul 2000 21:17:45 -0700
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway (Postfix) with ESMTP
	id B23C08154; Fri,  7 Jul 2000 14:17:48 +1000 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     torvalds@transmeta.com
Cc:     netdev@oss.sgi.com
Subject: [PATCH] misc netfilter fixes against test3-2
Date:   Fri, 07 Jul 2000 14:17:48 +1000
Message-Id: <20000707041748.B23C08154@halfway>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 12802
Lines: 350

Linus, please apply.

For the curious:

Bugs fixed: (most to least important)
	conntrack: ip_defrag crash fix			Andi Kleen
	conntrack: local ICMPs on NAT'ed conns fix	Rusty
	MASQUERADE: reset on address change (diald)	Rusty
	ip_queue: Pass mark field			James Morris
	ftp nat: don't overallocate space		Marc Boucher/Rusty
	MIRROR: must not track mirrored packets		Rusty

Enhancements:
	NAT: Set NFC_ALTERED bit only when skb altered	Rusty
	compat: Always set NFC_ALTERED: no rules	Rusty
	ftp conntrack: Always print partial matches	Rusty
	mac: matching in FORWARD chain			Rusty

Cheers!
Rusty.

diff -urN -X /tmp/fileJ6etyF --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ip_fw_compat.c tmp-cleanpatch/net/ipv4/netfilter/ip_fw_compat.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ip_fw_compat.c	Thu Jun 29 01:26:09 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ip_fw_compat.c	Fri Jul  7 13:08:37 2000
@@ -86,7 +86,8 @@
 	int ret = FW_BLOCK;
 	u_int16_t redirpt;
 
-	(*pskb)->nfcache |= NFC_UNKNOWN;
+	/* Assume worse case: any hook could change packet */
+	(*pskb)->nfcache |= NFC_UNKNOWN | NFC_ALTERED;
 	(*pskb)->ip_summed = CHECKSUM_NONE;
 
 	switch (hooknum) {
diff -urN -X /tmp/fileJ6etyF --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ip_nat_core.c tmp-cleanpatch/net/ipv4/netfilter/ip_nat_core.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ip_nat_core.c	Thu Jun 29 01:26:09 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ip_nat_core.c	Fri Jul  7 13:08:37 2000
@@ -663,8 +663,10 @@
 static void
 manip_pkt(u_int16_t proto, struct iphdr *iph, size_t len,
 	  const struct ip_conntrack_manip *manip,
-	  enum ip_nat_manip_type maniptype)
+	  enum ip_nat_manip_type maniptype,
+	  __u32 *nfcache)
 {
+	*nfcache |= NFC_ALTERED;
 	find_nat_proto(proto)->manip_pkt(iph, len, manip, maniptype);
 
 	if (maniptype == IP_NAT_MANIP_SRC) {
@@ -718,7 +720,8 @@
 				  (*pskb)->nh.iph,
 				  (*pskb)->len,
 				  &info->manips[i].manip,
-				  info->manips[i].maniptype);
+				  info->manips[i].maniptype,
+				  &(*pskb)->nfcache);
 		}
 	}
 	helper = info->helper;
@@ -782,7 +785,8 @@
 			manip_pkt(inner->protocol, inner,
 				  skb->len - ((void *)inner - (void *)iph),
 				  &info->manips[i].manip,
-				  !info->manips[i].maniptype);
+				  !info->manips[i].maniptype,
+				  &skb->nfcache);
 		/* Outer packet needs to have IP header NATed like
                    it's a reply. */
 		} else if (info->manips[i].direction == dir
@@ -795,7 +799,8 @@
 			       IP_PARTS(info->manips[i].manip.ip));
 			manip_pkt(0, iph, skb->len,
 				  &info->manips[i].manip,
-				  info->manips[i].maniptype);
+				  info->manips[i].maniptype,
+				  &skb->nfcache);
 		}
 	}
 	READ_UNLOCK(&ip_nat_lock);
diff -urN -X /tmp/fileJ6etyF --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ip_nat_standalone.c tmp-cleanpatch/net/ipv4/netfilter/ip_nat_standalone.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ip_nat_standalone.c	Thu Jun 29 01:26:09 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ip_nat_standalone.c	Fri Jul  7 13:08:37 2000
@@ -60,8 +60,7 @@
 	IP_NF_ASSERT(!((*pskb)->nh.iph->frag_off
 		       & __constant_htons(IP_MF|IP_OFFSET)));
 
-	/* FIXME: One day, fill in properly. --RR */
-	(*pskb)->nfcache |= NFC_UNKNOWN | NFC_ALTERED;
+	(*pskb)->nfcache |= NFC_UNKNOWN;
 
 	/* If we had a hardware checksum before, it's now invalid */
 	if ((*pskb)->pkt_type != PACKET_LOOPBACK)
diff -urN -X /tmp/fileEbRxnx --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ip_queue.c tmp-cleanpatch/net/ipv4/netfilter/ip_queue.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ip_queue.c	Thu Jun 29 01:26:09 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ip_queue.c	Fri Jul  7 13:08:45 2000
@@ -6,6 +6,8 @@
  *
  * 2000-03-27: Simplified code (thanks to Andi Kleen for clues). (JM)
  * 2000-05-20: Fixed notifier problems (following Miguel Freitas' report). (JM)
+ * 2000-06-19: Fixed so nfmark is copied to metadata (reported by Sebastian 
+ *             Zander). (JM)
  *
  */
 #include <linux/module.h>
@@ -391,6 +393,7 @@
 	pm->data_len = data_len;
 	pm->timestamp_sec = e->skb->stamp.tv_sec;
 	pm->timestamp_usec = e->skb->stamp.tv_usec;
+	pm->mark = e->skb->nfmark;
 	pm->hook = e->info->hook;
 	if (e->info->indev) strcpy(pm->indev_name, e->info->indev->name);
 	else pm->indev_name[0] = '\0';
diff -urN -X /tmp/filenRRBei --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ip_conntrack_ftp.c tmp-cleanpatch/net/ipv4/netfilter/ip_conntrack_ftp.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ip_conntrack_ftp.c	Thu Jun 29 01:26:09 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ip_conntrack_ftp.c	Fri Jul  7 13:08:51 2000
@@ -181,8 +181,9 @@
 		   connection tracking, not packet filtering.
 		   However, it is neccessary for accurate tracking in
 		   this case. */
-		DEBUGP("conntrack_ftp: partial `%.*s'\n",
-		       (int)datalen, data);
+		if (net_ratelimit())
+			printk("conntrack_ftp: partial %u+%u\n",
+			       ntohl(tcph->seq), datalen);
 		return NF_DROP;
 
 	case 0: /* no match */
diff -urN -X /tmp/fileLO7Uag --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ip_conntrack_core.c tmp-cleanpatch/net/ipv4/netfilter/ip_conntrack_core.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ip_conntrack_core.c	Thu Jun 29 01:26:09 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ip_conntrack_core.c	Fri Jul  7 13:09:03 2000
@@ -816,7 +816,9 @@
 	unsigned int olddebug = skb->nf_debug;
 #endif
 	if (sk) sock_hold(sk);
+	local_bh_disable(); 
 	skb = ip_defrag(skb);
+	local_bh_enable(); 
 	if (!skb) {
 		if (sk) sock_put(sk);
 		return skb;
diff -urN -X /tmp/filen7QCuR --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ipt_mac.c tmp-cleanpatch/net/ipv4/netfilter/ipt_mac.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ipt_mac.c	Fri May 12 13:22:38 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ipt_mac.c	Fri Jul  7 13:09:10 2000
@@ -33,9 +33,11 @@
 		   unsigned int matchsize,
 		   unsigned int hook_mask)
 {
+	/* FORWARD isn't always valid, but it's nice to be able to do --RR */
 	if (hook_mask
-	    & ~((1 << NF_IP_PRE_ROUTING) | (1 << NF_IP_LOCAL_IN))) {
-		printk("ipt_mac: only valid for PRE_ROUTING or LOCAL_IN.\n");
+	    & ~((1 << NF_IP_PRE_ROUTING) | (1 << NF_IP_LOCAL_IN)
+		| (1 << NF_IP_FORWARD))) {
+		printk("ipt_mac: only valid for PRE_ROUTING, LOCAL_IN or FORWARD.\n");
 		return 0;
 	}
 
diff -urN -X /tmp/fileEFGdiT --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ipt_MASQUERADE.c tmp-cleanpatch/net/ipv4/netfilter/ipt_MASQUERADE.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ipt_MASQUERADE.c	Thu Jun 29 01:26:09 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ipt_MASQUERADE.c	Fri Jul  7 13:09:16 2000
@@ -127,8 +127,8 @@
 {
 	struct net_device *dev = ptr;
 
-	if (event == NETDEV_DOWN) {
-		/* Device was downed.  Search entire table for
+	if (event == NETDEV_DOWN || event == NETDEV_CHANGEADDR) {
+		/* Device was downed/changed (diald)  Search entire table for
 		   conntracks which were associated with that device,
 		   and forget them. */
 		IP_NF_ASSERT(dev->ifindex != 0);
diff -urN -X /tmp/filevIBgPs --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ip_conntrack_core.c tmp-cleanpatch/net/ipv4/netfilter/ip_conntrack_core.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ip_conntrack_core.c	Thu Jun 29 01:26:09 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ip_conntrack_core.c	Fri Jul  7 13:09:22 2000
@@ -303,6 +303,7 @@
 	struct ip_conntrack_tuple_hash *h;
 
 	IP_NF_ASSERT(iph->protocol == IPPROTO_ICMP);
+	IP_NF_ASSERT(skb->nfct == NULL);
 
 	iph = skb->nh.iph;
 	hdr = (struct icmphdr *)((u_int32_t *)iph + iph->ihl);
@@ -350,10 +351,27 @@
 		DEBUGP("icmp_error_track: Can't invert tuple\n");
 		return NULL;
 	}
+
+	*ctinfo = IP_CT_RELATED;
+
 	h = ip_conntrack_find_get(&innertuple, NULL);
 	if (!h) {
-		DEBUGP("icmp_error_track: no match\n");
-		return NULL;
+		/* Locally generated ICMPs will match inverted if they
+		   haven't been SNAT'ed yet */
+		/* FIXME: NAT code has to handle half-done double NAT --RR */
+		if (hooknum == NF_IP_LOCAL_OUT)
+			h = ip_conntrack_find_get(&origtuple, NULL);
+
+		if (!h) {
+			DEBUGP("icmp_error_track: no match\n");
+			return NULL;
+		}
+		/* Reverse direction from that found */
+		if (DIRECTION(h) != IP_CT_DIR_REPLY)
+			*ctinfo += IP_CT_IS_REPLY;
+	} else {
+		if (DIRECTION(h) == IP_CT_DIR_REPLY)
+			*ctinfo += IP_CT_IS_REPLY;
 	}
 
 	/* REJECT target does this commonly, so allow locally
@@ -364,10 +382,6 @@
 		ip_conntrack_put(h->ctrack);
 		return NULL;
 	}
-
-	*ctinfo = IP_CT_RELATED;
-	if (DIRECTION(h) == IP_CT_DIR_REPLY)
-		*ctinfo += IP_CT_IS_REPLY;
 
 	/* Update skb to refer to this connection */
 	skb->nfct = &h->ctrack->infos[*ctinfo];
diff -urN -X /tmp/filevIBgPs --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ip_nat_core.c tmp-cleanpatch/net/ipv4/netfilter/ip_nat_core.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ip_nat_core.c	Thu Jun 29 01:26:09 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ip_nat_core.c	Fri Jul  7 13:09:22 2000
@@ -467,7 +467,7 @@
 static unsigned int opposite_hook[NF_IP_NUMHOOKS]
 = { [NF_IP_PRE_ROUTING] = NF_IP_POST_ROUTING,
     [NF_IP_POST_ROUTING] = NF_IP_PRE_ROUTING,
-    [NF_IP_LOCAL_OUT] = NF_IP_PRE_ROUTING
+    [NF_IP_LOCAL_OUT] = NF_IP_POST_ROUTING
 };
 
 unsigned int
@@ -754,7 +754,7 @@
 	   (even though a "host unreachable" coming from the host
 	   itself is a bit wierd).
 
-	   More explanation: some people use NAT for anonomizing.
+	   More explanation: some people use NAT for anonymizing.
 	   Also, CERT recommends dropping all packets from private IP
 	   addresses (although ICMP errors from internal links with
 	   such addresses are not too uncommon, as Alan Cox points
@@ -785,8 +785,7 @@
 				  !info->manips[i].maniptype);
 		/* Outer packet needs to have IP header NATed like
                    it's a reply. */
-		} else if (info->manips[i].direction == dir
-			 && info->manips[i].hooknum == hooknum) {
+		} else if (info->manips[i].hooknum == hooknum) {
 			/* Use mapping to map outer packet: 0 give no
                            per-proto mapping */
 			DEBUGP("icmp_reply: outer %s -> %u.%u.%u.%u\n",
diff -urN -X /tmp/fileciI17V --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ip_nat_ftp.c tmp-cleanpatch/net/ipv4/netfilter/ip_nat_ftp.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ip_nat_ftp.c	Wed Apr 12 17:43:07 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ip_nat_ftp.c	Fri Jul  7 13:09:28 2000
@@ -123,7 +123,8 @@
 
 	if (newlen > (*pskb)->len + skb_tailroom(*pskb)) {
 		struct sk_buff *newskb;
-		newskb = skb_copy_expand(*pskb, skb_headroom(*pskb), newlen,
+		newskb = skb_copy_expand(*pskb, skb_headroom(*pskb),
+					 newlen - (*pskb)->len,
 					 GFP_ATOMIC);
 		if (!newskb) {
 			DEBUGP("ftp: oom\n");
diff -urN -X /tmp/filev1eVOB --minimal linux-2.4.0-test3-4/net/ipv4/netfilter/ipt_MIRROR.c tmp-cleanpatch/net/ipv4/netfilter/ipt_MIRROR.c
--- linux-2.4.0-test3-4/net/ipv4/netfilter/ipt_MIRROR.c	Fri May 12 13:22:38 2000
+++ tmp-cleanpatch/net/ipv4/netfilter/ipt_MIRROR.c	Fri Jul  7 13:09:42 2000
@@ -41,23 +41,25 @@
         struct iphdr *iph = skb->nh.iph;
 	struct rtable *rt;
 
-	if (ip_route_output(&rt, iph->daddr, iph->saddr,
+	/* Backwards */
+	if (ip_route_output(&rt, iph->saddr, iph->daddr,
 			    RT_TOS(iph->tos) | RTO_CONN,
 			    0)) {
-		return -EINVAL;
+		return 0;
 	}
-	/* check if the interface we are living by is the same as the one we arrived on */
 
+	/* check if the interface we are leaving by is the same as the
+           one we arrived on */
 	if (skb->rx_dev == rt->u.dst.dev) {
 		/* Drop old route. */
 		dst_release(skb->dst);
 		skb->dst = &rt->u.dst;
-		return 0;
+		return 1;
 	}
-	else  return -EINVAL;
+	return 0;
 }
 
-static int
+static void
 ip_rewrite(struct sk_buff *skb)
 {
 	struct iphdr *iph = skb->nh.iph;
@@ -69,10 +71,27 @@
 	/* Rewrite IP header */
 	iph->daddr = odaddr;
 	iph->saddr = osaddr;
-
-	return 0;
 }
 
+/* Stolen from ip_finish_output2 */
+static void ip_direct_send(struct sk_buff *skb)
+{
+	struct dst_entry *dst = skb->dst;
+	struct hh_cache *hh = dst->hh;
+
+	if (hh) {
+		read_lock_bh(&hh->hh_lock);
+  		memcpy(skb->data - 16, hh->hh_data, 16);
+		read_unlock_bh(&hh->hh_lock);
+	        skb_push(skb, hh->hh_len);
+		hh->hh_output(skb);
+	} else if (dst->neighbour)
+		dst->neighbour->output(skb);
+	else {
+		printk(KERN_DEBUG "khm in MIRROR\n");
+		kfree(skb);
+	}
+}
 
 static unsigned int ipt_mirror_target(struct sk_buff **pskb,
 				      unsigned int hooknum,
@@ -82,8 +101,12 @@
 				      void *userinfo)
 {
 	if ((*pskb)->dst != NULL) {
-		if (!ip_rewrite(*pskb) && !route_mirror(*pskb)) {
-			ip_send(*pskb);
+		if (route_mirror(*pskb)) {
+			ip_rewrite(*pskb);
+			/* Don't let conntrack code see this packet:
+                           it will think we are starting a new
+                           connection! --RR */
+			ip_direct_send(*pskb);
 			return NF_STOLEN;
 		}
 	}

--
Hacking time.

From owner-netdev@oss.sgi.com Thu Jul  6 23:02:09 2000
Received:  by oss.sgi.com id <S42225AbQGGGB7>;
	Thu, 6 Jul 2000 23:01:59 -0700
Received: from [203.115.28.196] ([203.115.28.196]:33970 "EHLO
        postoffice.millenniumit.com") by oss.sgi.com with ESMTP
	id <S42223AbQGGGBk>; Thu, 6 Jul 2000 23:01:40 -0700
Received: from millenniumit.com (sql.millenniumit.com [172.25.62.85])
	by postoffice.millenniumit.com (8.9.3+Sun/8.9.1) with ESMTP id NAA06558;
	Fri, 7 Jul 2000 13:00:48 -0400 (EDT)
Message-ID: <3965702D.6019CF6E@millenniumit.com>
Date:   Fri, 07 Jul 2000 11:52:45 +0600
From:   Chanaka Mendis <chanakam@millenniumit.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com, netdevx@nuclecu.unam.mx,
        netdevx@nuclecu.unam.mx.com
Subject: tcpdump on Solaris 2.6
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: 2090
Lines: 58





Hi,
Could you help me in this problem
I tried to install tcp dump on SOLARIS 2.6.Already installed libcab 5.0.

When I execute ./configure its fine. But It giving the following error
when I
tried to "make".
RED section is the error.

gcc -O2 -DHAVE_CONFIG_H -I.  -I./missing -c ./smbutil.c
gcc -O2 -DHAVE_CONFIG_H -I.  -I./missing -c ./print-ascii.c
gcc -O2 -DHAVE_CONFIG_H -I.  -I./missing -c ./print-telnet.c
sed -e 's/.*/char version[] = "&";/' ./VERSION > version.c
gcc -O2 -DHAVE_CONFIG_H -I.  -I./missing -c version.c
gcc -O2 -DHAVE_CONFIG_H -I.  -I./missing -o inet_ntop.o -c
./missing/inet_ntop.c
gcc -O2 -DHAVE_CONFIG_H -I.  -I./missing -o inet_pton.o -c
./missing/inet_pton.c
gcc -O2 -DHAVE_CONFIG_H -I.  -I./missing -o inet_aton.o -c
./missing/inet_aton.c
gcc -O2 -DHAVE_CONFIG_H -I.  -I./missing  -o tcpdump tcpdump.o
print-arp.o
print-atalk.o print-atm.o print-bootp.o  print-decnet.o print-domain.o
print-dvmrp.o print-egp.o  print-ether.o print-fddi.o print-gre.o
print-icmp.o  print-igrp.o print-ip.o print-ipx.o print-isoclns.o
print-krb.o
print-llc.o print-nfs.o print-ntp.o print-null.o print-ospf.o
print-pim.o
print-ppp.o print-raw.o print-rip.o print-sl.o  print-snmp.o
print-sunrpc.o
print-tcp.o print-tftp.o print-udp.o  print-wb.o addrtoname.o bpf_dump.o

gmt2local.o machdep.o  parsenfsfh.o util.o savestr.o setsignal.o
print-esp.o
print-ah.o print-vjc.o print-isakmp.o print-chdlc.o  print-ipcomp.o
print-mobile.o print-l2tp.o print-bgp.o print-rx.o  print-lane.o
print-cip.o
print-pppoe.o print-lcp.o  print-smb.o smbutil.o print-ascii.o
print-telnet.o
version.o   inet_ntop.o inet_pton.o inet_aton.o -lpcap -lsocket -lnsl
-lz
Undefined                       first referenced
 symbol                             in file
yylex                               /usr/local/lib/libpcap.a(grammar.o)
lex_init                            /usr/local/lib/libpcap.a(gencode.o)
ld: fatal: Symbol referencing errors. No output written to tcpdump
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `tcpdump'

Thanks

Gayantha


From owner-netdev@oss.sgi.com Fri Jul  7 05:42:40 2000
Received:  by oss.sgi.com id <S42186AbQGGMmb>;
	Fri, 7 Jul 2000 05:42:31 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:5385 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42185AbQGGMmI>;
	Fri, 7 Jul 2000 05:42:08 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id QAA02612; Fri, 7 Jul 2000 16:35:29 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200007071235.QAA02612@ms2.inr.ac.ru>
Subject: Re: iptable_nat seriously b0rken
To:     rusty@linuxcare.COM.AU (Rusty Russell)
Date:   Fri, 7 Jul 2000 16:35:29 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20000706040944.C97BB8195@halfway> from "Rusty Russell" at Jul 7, 0 05:14:11 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: 400
Lines: 12

Hello!

> Dave, please merge.  Having tunnels pass the entunnelled packets
> through the LOCAL_OUT hook is nicer anyway (from a filtering and
> least-surprise perspective), and allows my connection tracking code to
> do its magic...

Well, Paul, but could you drop a note, _why_ it failed to work
without this? Seems, something is more fundamentally wrong yet.
It is not a minor surprise. 8)

Alexey

From owner-netdev@oss.sgi.com Fri Jul  7 10:21:32 2000
Received:  by oss.sgi.com id <S42205AbQGGRVM>;
	Fri, 7 Jul 2000 10:21:12 -0700
Received: from waste.org ([209.173.204.2]:62839 "EHLO waste.org")
	by oss.sgi.com with ESMTP id <S42185AbQGGRUo>;
	Fri, 7 Jul 2000 10:20:44 -0700
Received: from localhost (oxymoron@localhost)
	by waste.org (8.9.3/8.9.3) with ESMTP id MAA26280;
	Fri, 7 Jul 2000 12:20:47 -0500
Date:   Fri, 7 Jul 2000 12:20:46 -0500 (CDT)
From:   Oliver Xymoron <oxymoron@waste.org>
To:     Willy Tarreau <willy@novworld.Novecom.Fr>
cc:     linux-kernel <linux-kernel@vger.rutgers.edu>, netdev@oss.sgi.com
Subject: [PATCH] Re: [RFC] solution for the inet_ntoa problem, buffer allocator
In-Reply-To: <Pine.LNX.4.10.10007071038310.1903-100000@waste.org>
Message-ID: <Pine.LNX.4.10.10007071202180.1903-200000@waste.org>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1378811188-1461769515-962989416=:1903"
Content-ID: <Pine.LNX.4.10.10007071203430.1903@waste.org>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 19030
Lines: 326

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1378811188-1461769515-962989416=:1903
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.10007071203431.1903@waste.org>

On Fri, 7 Jul 2000, Oliver Xymoron wrote:

> On Fri, 7 Jul 2000, Willy Tarreau wrote:
> 
> > > Not threadsafe.
> > 
> > Hmmm, I forgot that aspect :-/
> 
> I'm gonna post a cleanup patch that kills in_ntoa entirely. The right way
> to do it is in_ntoa2 which and local buffers ala sprintf.

Ok, here's a completely untested but very straightforward patch that
removes in_ntoa and replaces all uses with in_ntoa2. In_ntoa wasn't
threadsafe so every use was a potential race and it was being called
multiple times for printk args.  Alternatives discussed included hacking
printk to print IP addresses (doesn't fix all uses and compiler complains)
and adding some sort of allocator to in_ntoa (ugly, still not threadsafe).

I'd like to kill NIPQUAD (and definitely HIPQUAD) in favor of in_ntoa2 as
it looks like one argument in an argument list but is magically four. It
also doesn't have an obvious analog for IPv6, which is doing rather ugly
things currently.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

---1378811188-1461769515-962989416=:1903
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ntoa-purge.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.10007071203360.1903@waste.org>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME="ntoa-purge.patch"

ZGlmZiAtdXIgbGludXgvZHJpdmVycy9uZXQvd2FuL3NkbGFfY2hkbGMuYyBs
aW51eC13b3JrL2RyaXZlcnMvbmV0L3dhbi9zZGxhX2NoZGxjLmMNCi0tLSBs
aW51eC9kcml2ZXJzL25ldC93YW4vc2RsYV9jaGRsYy5jCVRodSBNYXkgIDQg
MTM6MzE6MjEgMjAwMA0KKysrIGxpbnV4LXdvcmsvZHJpdmVycy9uZXQvd2Fu
L3NkbGFfY2hkbGMuYwlGcmkgSnVsICA3IDExOjQwOjQwIDIwMDANCkBAIC0y
MDA0LDE3ICsyMDA0LDE5IEBADQogDQogCWlmKChjaGRsY19wcml2X2FyZWEt
PnJvdXRlX3N0YXR1cyA9PSBBRERfUk9VVEUpICYmDQogCQkoKGNoZGxjX3By
aXZfYXJlYS0+SVBfYWRkcmVzcyAmIDB4MDAwMDAwRkYpID4gMikpIHsNCisJ
CWNoYXIgYVsxNl07DQorCQkNCiAJCXByaW50ayhLRVJOX0lORk8gIiVzOiBE
eW5hbWljIHJvdXRlIGZhaWx1cmUuXG4iLGNhcmQtPmRldm5hbWUpOw0KICAg
ICAgICAgICAgICAgICBpZihjYXJkLT51LmMuc2xhcnBfdGltZXIpIHsNCiAJ
CQlwcmludGsoS0VSTl9JTkZPICIlczogQmFkIElQIGFkZHJlc3MgJXMgcmVj
ZWl2ZWRcbiIsDQogCQkJCWNhcmQtPmRldm5hbWUsDQotCQkJCWluX250b2Eo
bnRvaGwoY2hkbGNfcHJpdl9hcmVhLT5JUF9hZGRyZXNzKSkpOw0KKwkJCQlp
bl9udG9hMihudG9obChjaGRsY19wcml2X2FyZWEtPklQX2FkZHJlc3MpLCBh
KSk7DQogICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnRrKEtFUk5fSU5G
TyAiJXM6IGZyb20gcmVtb3RlIHN0YXRpb24uXG4iLA0KIAkJCQljYXJkLT5k
ZXZuYW1lKTsNCiAgICAgICAgICAgICAgICAgfWVsc2V7IA0KICAgICAgICAg
ICAgICAgICAgICAgICAgIHByaW50ayhLRVJOX0lORk8gIiVzOiBCYWQgSVAg
YWRkcmVzcyAlcyBpc3N1ZWRcbiIsDQogCQkJCWNhcmQtPmRldm5hbWUsDQot
CQkJCWluX250b2EobnRvaGwoY2hkbGNfcHJpdl9hcmVhLT5JUF9hZGRyZXNz
KSkpOw0KKwkJCQlpbl9udG9hMihudG9obChjaGRsY19wcml2X2FyZWEtPklQ
X2FkZHJlc3MpLCBhKSk7DQogICAgICAgICAgICAgICAgICAgICAgICAgcHJp
bnRrKEtFUk5fSU5GTyAiJXM6IHRvIHJlbW90ZSBzdGF0aW9uLiBMb2NhbFxu
IiwNCiAJCQkJY2FyZC0+ZGV2bmFtZSk7DQogCQkJcHJpbnRrKEtFUk5fSU5G
TyAiJXM6IElQIGFkZHJlc3MgbXVzdCBiZSBBLkIuQy4xXG4iLA0KQEAgLTIx
MjQsMTYgKzIxMjYsMjAgQEANCiAJCX0NCiANCiAgICAgICAgICAgICAgICBp
ZihlcnIpIHsNCi0JCQlwcmludGsoS0VSTl9JTkZPICIlczogQWRkIHJvdXRl
ICVzIGZhaWxlZCAoJWQpXG4iLCANCi0JCQkJY2FyZC0+ZGV2bmFtZSwgaW5f
bnRvYShyZW1vdGVfSVBfYWRkciksIGVycik7DQorCQkgICAgICAgY2hhciBh
WzE2XTsNCisJCSAgICAgICBwcmludGsoS0VSTl9JTkZPICIlczogQWRkIHJv
dXRlICVzIGZhaWxlZCAoJWQpXG4iLCANCisJCQkJY2FyZC0+ZGV2bmFtZSwg
DQorCQkJCWluX250b2EyKHJlbW90ZV9JUF9hZGRyLCBhKSwgZXJyKTsNCiAJ
CX0gZWxzZSB7DQorCQkJY2hhciBhWzE2XTsNCisNCiAJCQkoKGNoZGxjX3By
aXZhdGVfYXJlYV90ICopZGV2LT5wcml2KS0+cm91dGVfc3RhdHVzID0gUk9V
VEVfQURERUQ7DQogCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IER5bmFtaWMg
cm91dGUgYWRkZWQuXG4iLA0KIAkJCQljYXJkLT5kZXZuYW1lKTsNCiAJCQlw
cmludGsoS0VSTl9JTkZPICIlczogICAgTG9jYWwgSVAgYWRkciA6ICVzXG4i
LA0KLQkJCQljYXJkLT5kZXZuYW1lLCBpbl9udG9hKGxvY2FsX0lQX2FkZHIp
KTsNCisJCQkJY2FyZC0+ZGV2bmFtZSwgaW5fbnRvYTIobG9jYWxfSVBfYWRk
ciwgYSkpOw0KIAkJCXByaW50ayhLRVJOX0lORk8gIiVzOiAgICBSZW1vdGUg
SVAgYWRkcjogJXNcbiIsDQotCQkJCWNhcmQtPmRldm5hbWUsIGluX250b2Eo
cmVtb3RlX0lQX2FkZHIpKTsNCisJCQkJY2FyZC0+ZGV2bmFtZSwgaW5fbnRv
YTIocmVtb3RlX0lQX2FkZHIsIGEpKTsNCiAJCQljaGRsY19wcml2X2FyZWEt
PnJvdXRlX3JlbW92ZWQgPSAwOw0KIAkJfQ0KIAkJYnJlYWs7DQpAQCAtMjE2
MywxNSArMjE2OSwxOCBAQA0KIAkJZXJyID0gaXBfcnRfa2lsbCgmcm91dGUp
Ow0KICNlbmRpZg0KIAkJaWYoZXJyKSB7DQorCQkJY2hhciBhWzE2XTsNCiAJ
CQlwcmludGsoS0VSTl9JTkZPDQogCQkJCSIlczogUmVtb3ZlIHJvdXRlICVz
IGZhaWxlZCwgKGVyciAlZClcbiIsDQotCQkJCQljYXJkLT5kZXZuYW1lLCBp
bl9udG9hKHJlbW90ZV9JUF9hZGRyKSwNCi0JCQkJCWVycik7DQorCQkJCWNh
cmQtPmRldm5hbWUsIA0KKwkJCQlpbl9udG9hMihyZW1vdGVfSVBfYWRkciwg
YSksIGVycik7DQogCQl9IGVsc2Ugew0KKwkJCWNoYXIgYVsxNl07DQogCQkJ
KChjaGRsY19wcml2YXRlX2FyZWFfdCAqKWRldi0+cHJpdiktPnJvdXRlX3N0
YXR1cyA9DQogCQkJCU5PX1JPVVRFOw0KICAgICAgICAgICAgICAgICAgICAg
ICAgIHByaW50ayhLRVJOX0lORk8gIiVzOiBEeW5hbWljIHJvdXRlIHJlbW92
ZWQ6ICVzXG4iLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBjYXJkLT5kZXZuYW1lLCBpbl9udG9hKGxvY2FsX0lQX2FkZHIp
KTsgDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGNhcmQtPmRldm5hbWUsIA0KKwkJCQkJaW5fbnRvYTIobG9jYWxfSVBfYWRk
ciwgYSkpOyANCiAJCQljaGRsY19wcml2X2FyZWEtPnJvdXRlX3JlbW92ZWQg
PSAxOw0KIAkJfQ0KIAkJYnJlYWs7DQpkaWZmIC11ciBsaW51eC9kcml2ZXJz
L25ldC93YW4vc2RsYV9mci5jIGxpbnV4LXdvcmsvZHJpdmVycy9uZXQvd2Fu
L3NkbGFfZnIuYw0KLS0tIGxpbnV4L2RyaXZlcnMvbmV0L3dhbi9zZGxhX2Zy
LmMJVGh1IE1heSAgNCAxMzozMToyMSAyMDAwDQorKysgbGludXgtd29yay9k
cml2ZXJzL25ldC93YW4vc2RsYV9mci5jCUZyaSBKdWwgIDcgMTE6NDA6NDEg
MjAwMA0KQEAgLTEyMiw3ICsxMjIsNyBAQA0KICNpbmNsdWRlIDxhc20vaW8u
aD4JCS8qIGZvciBpbmIoKSwgb3V0YigpLCBldGMuICovDQogI2luY2x1ZGUg
PGxpbnV4L3RpbWUuaD4JIAkvKiBmb3IgZG9fZ2V0dGltZW9mZGF5ICovCQ0K
ICNpbmNsdWRlIDxsaW51eC9pbi5oPgkJLyogc29ja2FkZHJfaW4gKi8NCi0j
aW5jbHVkZSA8bGludXgvaW5ldC5oPgkJLyogaW5fbnRvYSgpLCBldGMuLi4g
Ki8NCisjaW5jbHVkZSA8bGludXgvaW5ldC5oPgkJLyogaW5fbnRvYTIoKSwg
ZXRjLi4uICovDQogI2luY2x1ZGUgPGFzbS91YWNjZXNzLmg+DQogI2luY2x1
ZGUgPGxpbnV4L2luZXRkZXZpY2UuaD4NCiAjaW5jbHVkZSA8bGludXgvaXAu
aD4NCkBAIC0yMTc2LDEwICsyMTc2LDExIEBADQogCQkJCQlzZXRfZnMoZnMp
OwkgICAgICAvKiByZXN0b3JlIG9sZCBibG9jayAqLw0KIA0KIAkJCQkJaWYg
KGVycikgew0KKwkJCQkJCWNoYXIgYVsxNl07DQogCQkJCQkJcHJpbnRrKEtF
Uk5fSU5GTyAiJXM6IEFkZGluZyBvZiByb3V0ZSBmYWlsZWQuICBFcnJvcjog
JWRcbiIsIGNhcmQtPmRldm5hbWUsZXJyKTsNCiAJCQkJCQlwcmludGsoS0VS
Tl9JTkZPICIlczogQWRkcmVzczogJXNcbiIsDQogCQkJCQkJICAgICAgIGNo
YW4tPm5hbWUsDQotCQkJCQkJICAgICAgIGluX250b2EoaW5fZGV2LT5pZmFf
bGlzdC0+aWZhX2FkZHJlc3MpICk7DQorCQkJCQkJICAgICAgIGluX250b2Ey
KGluX2Rldi0+aWZhX2xpc3QtPmlmYV9hZGRyZXNzKSwgYSk7DQogCQkJCQl9
IGVsc2Ugew0KIAkJCQkJCWNoYW4tPnJvdXRlX2ZsYWcgPSBST1VURV9BRERF
RDsNCiAJCQkJCX0NCkBAIC0yMTkxLDkgKzIxOTIsMTAgQEANCiAJCQkJCXNl
dF9mcyhmcyk7CSAgICAgIC8qIHJlc3RvcmUgb2xkIGJsb2NrICovDQogDQog
CQkJCQlpZiAoZXJyKSB7DQorCQkJCQkJY2hhciBhWzE2XTsNCiAJCQkJCQlw
cmludGsoS0VSTl9JTkZPICIlczogRGVsZXRpbmcgb2Ygcm91dGUgZmFpbGVk
LiAgRXJyb3I6ICVkXG4iLCBjYXJkLT5kZXZuYW1lLGVycik7DQogCQkJCQkJ
cHJpbnRrKEtFUk5fSU5GTyAiJXM6IEFkZHJlc3M6ICVzXG4iLA0KLQkJCQkJ
CSAgICAgICBkZXYtPm5hbWUsaW5fbnRvYShpbl9kZXYtPmlmYV9saXN0LT5p
ZmFfYWRkcmVzcykgKTsNCisJCQkJCQkgICAgICAgZGV2LT5uYW1lLGluX250
b2EyKGluX2Rldi0+aWZhX2xpc3QtPmlmYV9hZGRyZXNzKSwgYSk7DQogCQkJ
CQl9IGVsc2Ugew0KIAkJCQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiBSZW1v
dmVkIHJvdXRlLlxuIiwNCiAJCQkJCQkgICAgICAgY2hhbi0+bmFtZSk7DQpA
QCAtMzQzNiwxNCArMzQzOCwyMCBAQA0KIA0KIAlpbl9kZXYgPSBkZXYtPmlw
X3B0cjsNCiAJaWYoIGluX2RldiAhPSBOVUxMICYmIGluX2Rldi0+aWZhX2xp
c3QgIT0gTlVMTCkgew0KKwkJY2hhciBhWzE2XTsNCisNCiAJCXN3aXRjaCAo
bnRvaHMoYXJwaGRyLT5hcl9vcCkpIHsNCiANCiAJCWNhc2UgMHgwODogIC8v
IEludmVyc2UgQVJQIHJlcXVlc3QgIC0tIFNlbmQgUmVwbHksIGFkZCByb3V0
ZS4NCiAJCQkNCiAJCQkvKiBDaGVjayBmb3IgdmFsaWQgQWRkcmVzcyAqLw0K
LQkJCXByaW50ayhLRVJOX0lORk8gIiVzOiBSZWN2ZCBQdFAgYWRkciAlcyAt
SW5BcnAgUmVxXG4iLCAoKGZyX2NoYW5uZWxfdCAqKWRldi0+cHJpdiktPm5h
bWUsIGluX250b2EoYXJwaGRyLT5hcl9zaXApKTsNCi0NCi0JCQlpZiAoKGlu
X2Rldi0+aWZhX2xpc3QtPmlmYV9tYXNrICYgYXJwaGRyLT5hcl9zaXApICE9
IChpbl9kZXYtPmlmYV9saXN0LT5pZmFfbWFzayAmIGluX2Rldi0+aWZhX2xp
c3QtPmlmYV9sb2NhbCkpIHsNCisJCQlwcmludGsoS0VSTl9JTkZPICIlczog
UmVjdmQgUHRQIGFkZHIgJXMgLUluQXJwIFJlcVxuIiwNCisJCQkJKChmcl9j
aGFubmVsX3QgKilkZXYtPnByaXYpLT5uYW1lLCANCisJCQkJaW5fbnRvYTIo
YXJwaGRyLT5hcl9zaXAsIGEpKTsNCisNCisJCQlpZiAoKGluX2Rldi0+aWZh
X2xpc3QtPmlmYV9tYXNrICYgYXJwaGRyLT5hcl9zaXApICE9IA0KKwkJCQko
aW5fZGV2LT5pZmFfbGlzdC0+aWZhX21hc2sgJiANCisJCQkJIGluX2Rldi0+
aWZhX2xpc3QtPmlmYV9sb2NhbCkpIHsNCiAJCQkJcHJpbnRrKEtFUk5fSU5G
TyAiJXM6IEludmFsaWQgUHRQIGFkZHJlc3MuICBJbkFSUCBpZ25vcmVkLlxu
IiwgY2FyZC0+ZGV2bmFtZSk7DQogCQkJCXByaW50ayhLRVJOX0lORk8gIm1h
c2sgJVhcbiIsIGluX2Rldi0+aWZhX2xpc3QtPmlmYV9tYXNrKTsNCiAJCQkJ
cHJpbnRrKEtFUk5fSU5GTyAibG9jYWwgJVhcbiIsIGluX2Rldi0+aWZhX2xp
c3QtPmlmYV9sb2NhbCk7DQpAQCAtMzQ5Niw3ICszNTA0LDcgQEANCiAJCWNh
c2UgMHgwOTogIC8vIEludmVyc2UgQVJQIHJlcGx5DQogDQogCQkJLyogQ2hl
Y2sgZm9yIHZhbGlkIEFkZHJlc3MgKi8NCi0JCQlwcmludGsoS0VSTl9JTkZP
ICIlczogUmVjdmQgUHRQIGFkZHIgJXMgLUluQXJwIFJlcGx5XG4iLCAoKGZy
X2NoYW5uZWxfdCAqKWRldi0+cHJpdiktPm5hbWUsIGluX250b2EoYXJwaGRy
LT5hcl9zaXApKTsNCisJCQlwcmludGsoS0VSTl9JTkZPICIlczogUmVjdmQg
UHRQIGFkZHIgJXMgLUluQXJwIFJlcGx5XG4iLCAoKGZyX2NoYW5uZWxfdCAq
KWRldi0+cHJpdiktPm5hbWUsIGluX250b2EyKGFycGhkci0+YXJfc2lwLCBh
KSk7DQogDQogCQkJaWYgKChpbl9kZXYtPmlmYV9saXN0LT5pZmFfbWFzayAm
IGFycGhkci0+YXJfc2lwKSAhPSAoaW5fZGV2LT5pZmFfbGlzdC0+aWZhX21h
c2sgJiBpbl9kZXYtPmlmYV9saXN0LT5pZmFfbG9jYWwpKSB7DQogCQkJCXBy
aW50ayhLRVJOX0lORk8gIiVzOiBJbnZhbGlkIFB0UCBhZGRyZXNzLiAgSW5B
UlAgaWdub3JlZC5cbiIsIGNhcmQtPmRldm5hbWUpOw0KZGlmZiAtdXIgbGlu
dXgvZHJpdmVycy9uZXQvd2FuL3NkbGFfcHBwLmMgbGludXgtd29yay9kcml2
ZXJzL25ldC93YW4vc2RsYV9wcHAuYw0KLS0tIGxpbnV4L2RyaXZlcnMvbmV0
L3dhbi9zZGxhX3BwcC5jCVRodSBNYXkgIDQgMTM6MzE6MjEgMjAwMA0KKysr
IGxpbnV4LXdvcmsvZHJpdmVycy9uZXQvd2FuL3NkbGFfcHBwLmMJRnJpIEp1
bCAgNyAxMTozNjozOCAyMDAwDQpAQCAtODYsNyArODYsNyBAQA0KICNpbmNs
dWRlIDxsaW51eC9pZl9hcnAuaD4JLyogQVJQSFJEXyogZGVmaW5lcyAqLw0K
ICNpbmNsdWRlIDxhc20vYnl0ZW9yZGVyLmg+CS8qIGh0b25zKCksIGV0Yy4g
Ki8NCiAjaW5jbHVkZSA8bGludXgvaW4uaD4JCS8qIHNvY2thZGRyX2luICov
DQotI2luY2x1ZGUgPGxpbnV4L2luZXQuaD4JCS8qIGluX2F0b24oKSwgaW5f
bnRvYSgpIHByb3RvdHlwZXMgKi8NCisjaW5jbHVkZSA8bGludXgvaW5ldC5o
PgkJLyogaW5fYXRvbigpLCBpbl9udG9hMigpIHByb3RvdHlwZXMgKi8NCiAN
CiAjaW5jbHVkZSA8bGludXgvaW5ldGRldmljZS5oPg0KICNpbmNsdWRlIDxh
c20vdWFjY2Vzcy5oPg0KQEAgLTE5ODUsMTEgKzE5ODUsMTQgQEANCiAJCQkJ
CSIlczogQW4gZXJyb3Igb2NjdXJyZWQgaW4gSVAgYXNzaWdubWVudC5cbiIs
IA0KIAkJCQkJY2FyZC0+ZGV2bmFtZSk7DQogCQkJfSBlbHNlIHsNCisJCQkJ
Y2hhciBhWzE2XTsNCiAJCQkJc3RydWN0IGluX2lmYWRkciAqaWZhID0gaW5f
ZGV2LT5pZmFfbGlzdDsNCiAJCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IEFz
c2lnbmVkIExjbC4gQWRkcjogJXNcbiIsIA0KLQkJCQkJCWNhcmQtPmRldm5h
bWUsIGluX250b2EoaWZhLT5pZmFfbG9jYWwpKTsNCisJCQkJCWNhcmQtPmRl
dm5hbWUsIA0KKwkJCQkJaW5fbnRvYTIoaWZhLT5pZmFfbG9jYWwsIGEpKTsN
CiAJCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IEFzc2lnbmVkIFJtdC4gQWRk
cjogJXNcbiIsIA0KLQkJCQkJCWNhcmQtPmRldm5hbWUsIGluX250b2EoaWZh
LT5pZmFfYWRkcmVzcykpOw0KKwkJCQkJY2FyZC0+ZGV2bmFtZSwNCisJCQkJ
CWluX250b2EyKGlmYS0+aWZhX2FkZHJlc3MsIGEpKTsNCiAJCQl9DQogCQkJ
UmVhZF9jb25uZWN0aW9uX2luZm8gPSAwOw0KIAkJfQ0KQEAgLTIwMzIsNyAr
MjAzNSw4IEBADQogCXBwcDUwOF9jb25mX3QgY2ZnOw0KIAlzdHJ1Y3QgbmV0
X2RldmljZSAqZGV2ID0gY2FyZC0+d2FuZGV2LmRldjsNCiAJc3RydWN0IGlu
X2RldmljZSAqaW5fZGV2ID0gZGV2LT5pcF9wdHI7DQotCQ0KKwljaGFyIGEx
WzE2XSwgYTJbMTZdOw0KKw0KIAkvKiBQcmVwYXJlIFBQUCBjb25maWd1cmF0
aW9uIHN0cnVjdHVyZSAqLw0KIAltZW1zZXQoJmNmZywgMCwgc2l6ZW9mKHBw
cDUwOF9jb25mX3QpKTsNCiANCkBAIC0yMDkyLDggKzIwOTYsOCBAQA0KIAkJ
CWNmZy5pcF9sb2NhbAkJPSBpbl9kZXYtPmlmYV9saXN0LT5pZmFfbG9jYWw7
DQogCQkJY2ZnLmlwX3JlbW90ZQkJPSBpbl9kZXYtPmlmYV9saXN0LT5pZmFf
YWRkcmVzczsNCiAgICAgICAgICAgICAgICAgICAgICAgICBORVhfUFJJTlRL
KEtFUk5fSU5GTyAiTG9jYWwgJXMgUmVtb3RlICVzIE5hbWUgJXNcbiIsDQot
CQkJCQlpbl9udG9hKGNmZy5pcF9sb2NhbCksIA0KLQkJCQkJaW5fbnRvYShj
ZmcuaXBfcmVtb3RlKSwgDQorCQkJCQlpbl9udG9hMihjZmcuaXBfbG9jYWws
IGExKSwgDQorCQkJCQlpbl9udG9hMihjZmcuaXBfcmVtb3RlLCBhMiksIA0K
IAkJCQkJZGV2LT5uYW1lKTsNCiAJCQlicmVhazsNCiAJDQpAQCAtMjY5Nywx
MiArMjcwMSwxMyBAQA0KIA0KIA0KIAlpZiAoZXJyKSB7DQorCQljaGFyIGFb
MTZdOw0KIAkJcHJpbnRrIChLRVJOX0lORk8gIiVzOiBBZGRpbmcgb2Ygcm91
dGUgZmFpbGVkOlxuIiwNCiAJCQljYXJkLT5kZXZuYW1lKTsNCiAJCXByaW50
ayAoS0VSTl9JTkZPICIlczoJTG9jYWwgOiAlc1xuIiwNCi0JCQljYXJkLT5k
ZXZuYW1lLGluX250b2EocHBwX3ByaXZfYXJlYS0+aXBfbG9jYWwpKTsNCisJ
CQljYXJkLT5kZXZuYW1lLGluX250b2EyKHBwcF9wcml2X2FyZWEtPmlwX2xv
Y2FsLCBhKSk7DQogCQlwcmludGsgKEtFUk5fSU5GTyAiJXM6CVJlbW90ZTog
JXNcbiIsDQotCQkJY2FyZC0+ZGV2bmFtZSxpbl9udG9hKHBwcF9wcml2X2Fy
ZWEtPmlwX3JlbW90ZSkpOw0KKwkJCWNhcmQtPmRldm5hbWUsaW5fbnRvYTIo
cHBwX3ByaXZfYXJlYS0+aXBfcmVtb3RlLCBhKSk7DQogCX0NCiAJcmV0dXJu
IGVycjsNCiB9DQpAQCAtMjc1MiwxMCArMjc1NywxMSBAQA0KIAkJcHJpbnRr
IChLRVJOX0lORk8gIiVzOiBEZWxldGluZyBkeW5hbWljIHJvdXRlIGZhaWxl
ZCAlZCFcbiIsDQogCQkJIGNhcmQtPmRldm5hbWUsIGVycik7DQogCQlyZXR1
cm4gZXJyOw0KLQl9ZWxzZQ0KKwl9IGVsc2Ugew0KKwkJY2hhciBhWzE2XTsN
CiAJCXByaW50ayAoS0VSTl9JTkZPICIlczogUFBQIERlbGV0aW5nIGR5bmFt
aWMgcm91dGUgJXMgc3VjY2Vzc2Z1bHlcbiIsDQotCQkJY2FyZC0+ZGV2bmFt
ZSwgaW5fbnRvYShpcF9hZGRyKSk7DQotDQorCQkJY2FyZC0+ZGV2bmFtZSwg
aW5fbnRvYTIoaXBfYWRkciwgYSkpOw0KKwl9DQogCQ0KIAlyZXR1cm4gMDsN
CiB9DQpkaWZmIC11ciBsaW51eC9mcy9uZnMvbW91bnRfY2xudC5jIGxpbnV4
LXdvcmsvZnMvbmZzL21vdW50X2NsbnQuYw0KLS0tIGxpbnV4L2ZzL25mcy9t
b3VudF9jbG50LmMJVGh1IEFwciAxMyAwOTo1NDoxOSAyMDAwDQorKysgbGlu
dXgtd29yay9mcy9uZnMvbW91bnRfY2xudC5jCUZyaSBKdWwgIDcgMTE6Mjc6
MjQgMjAwMA0KQEAgLTY3LDcgKzY3LDcgQEANCiAJZHByaW50aygiTkZTOiAg
ICAgIG5mc19tb3VudCglMDh4OiVzKVxuIiwNCiAJCQkodW5zaWduZWQpbnRv
aGwoYWRkci0+c2luX2FkZHIuc19hZGRyKSwgcGF0aCk7DQogDQotCXN0cmNw
eShob3N0bmFtZSwgaW5fbnRvYShhZGRyLT5zaW5fYWRkci5zX2FkZHIpKTsN
CisJaW5fbnRvYTIoYWRkci0+c2luX2FkZHIuc19hZGRyLCBob3N0bmFtZSk7
DQogCWlmICghKG1udF9jbG50ID0gbW50X2NyZWF0ZShob3N0bmFtZSwgYWRk
ciwgdmVyc2lvbikpKQ0KIAkJcmV0dXJuIC1FQUNDRVM7DQogDQpkaWZmIC11
ciBsaW51eC9mcy9uZnMvbmZzcm9vdC5jIGxpbnV4LXdvcmsvZnMvbmZzL25m
c3Jvb3QuYw0KLS0tIGxpbnV4L2ZzL25mcy9uZnNyb290LmMJRnJpIEFwciAy
MSAxNTozNjo0MCAyMDAwDQorKysgbGludXgtd29yay9mcy9uZnMvbmZzcm9v
dC5jCUZyaSBKdWwgIDcgMTE6NDA6MzggMjAwMA0KQEAgLTI4MCw3ICsyODAs
OCBAQA0KIAkJcmV0dXJuIC0xOw0KIAl9DQogDQotCXN0cm5jcHkobmZzX2Rh
dGEuaG9zdG5hbWUsIGluX250b2Eoc2VydmFkZHIpLCBzaXplb2YobmZzX2Rh
dGEuaG9zdG5hbWUpLTEpOw0KKwlpbl9udG9hMihzZXJ2YWRkciwgbmZzX2Rh
dGEuaG9zdG5hbWUpOw0KKw0KIAlyZXR1cm4gMDsNCiB9DQogDQpAQCAtMzcy
LDkgKzM3MywxMCBAQA0KIHN0YXRpYyBpbnQgX19pbml0IHJvb3RfbmZzX2dl
dHBvcnQoaW50IHByb2dyYW0sIGludCB2ZXJzaW9uLCBpbnQgcHJvdG8pDQog
ew0KIAlzdHJ1Y3Qgc29ja2FkZHJfaW4gc2luOw0KKwljaGFyIGFbMTZdOw0K
IA0KIAlwcmludGsoS0VSTl9OT1RJQ0UgIkxvb2tpbmcgdXAgcG9ydCBvZiBS
UEMgJWQvJWQgb24gJXNcbiIsDQotCQlwcm9ncmFtLCB2ZXJzaW9uLCBpbl9u
dG9hKHNlcnZhZGRyKSk7DQorCQlwcm9ncmFtLCB2ZXJzaW9uLCBpbl9udG9h
MihzZXJ2YWRkciwgYSkpOw0KIAlzZXRfc29ja2FkZHIoJnNpbiwgc2VydmFk
ZHIsIDApOw0KIAlyZXR1cm4gcnBjX2dldHBvcnRfZXh0ZXJuYWwoJnNpbiwg
cHJvZ3JhbSwgdmVyc2lvbiwgcHJvdG8pOw0KIH0NCmRpZmYgLXVyIGxpbnV4
L2luY2x1ZGUvbGludXgvaW5ldC5oIGxpbnV4LXdvcmsvaW5jbHVkZS9saW51
eC9pbmV0LmgNCi0tLSBsaW51eC9pbmNsdWRlL2xpbnV4L2luZXQuaAlXZWQg
SnVuICA5IDE2OjQ1OjM2IDE5OTkNCisrKyBsaW51eC13b3JrL2luY2x1ZGUv
bGludXgvaW5ldC5oCUZyaSBKdWwgIDcgMTE6Mjc6MjcgMjAwMA0KQEAgLTQ1
LDcgKzQ1LDYgQEANCiAjaWZkZWYgX19LRVJORUxfXw0KIA0KIGV4dGVybiB2
b2lkCQlpbmV0X3Byb3RvX2luaXQoc3RydWN0IG5ldF9wcm90byAqcHJvKTsN
Ci1leHRlcm4gY2hhcgkJKmluX250b2EoX191MzIgaW4pOw0KIGV4dGVybiBj
aGFyCQkqaW5fbnRvYTIoX191MzIgaW4sIGNoYXIgKmJ1Zik7DQogZXh0ZXJu
IF9fdTMyCQlpbl9hdG9uKGNvbnN0IGNoYXIgKnN0cik7DQogDQpkaWZmIC11
ciBsaW51eC9pbmNsdWRlL2xpbnV4L3dhbnJvdXRlci5oIGxpbnV4LXdvcmsv
aW5jbHVkZS9saW51eC93YW5yb3V0ZXIuaA0KLS0tIGxpbnV4L2luY2x1ZGUv
bGludXgvd2Fucm91dGVyLmgJRnJpIEp1biAyMyAyMzozMzo0MCAyMDAwDQor
KysgbGludXgtd29yay9pbmNsdWRlL2xpbnV4L3dhbnJvdXRlci5oCUZyaSBK
dWwgIDcgMTE6Mjc6MjUgMjAwMA0KQEAgLTQwMiw3ICs0MDIsNyBAQA0KIA0K
ICNpbmNsdWRlIDxsaW51eC9mcy5oPgkJLyogc3VwcG9ydCBmb3IgZGV2aWNl
IGRyaXZlcnMgKi8NCiAjaW5jbHVkZSA8bGludXgvcHJvY19mcy5oPgkvKiBw
cm9jIGZpbGVzeXN0ZW0gcHJhZ21hdGljcyAqLw0KLSNpbmNsdWRlIDxsaW51
eC9pbmV0Lmg+CQkvKiBpbl9hdG9uKCksIGluX250b2EoKSBwcm90b3R5cGVz
ICovDQorI2luY2x1ZGUgPGxpbnV4L2luZXQuaD4JCS8qIGluX2F0b24oKSwg
aW5fbnRvYTIoKSBwcm90b3R5cGVzICovDQogI2luY2x1ZGUgPGxpbnV4L25l
dGRldmljZS5oPgkvKiBzdXBwb3J0IGZvciBuZXR3b3JrIGRyaXZlcnMgKi8N
CiAvKi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgKiBXQU4g
ZGV2aWNlIGRhdGEgc3BhY2UuDQpkaWZmIC11ciBsaW51eC9uZXQvaXB2NC9p
cGNvbmZpZy5jIGxpbnV4LXdvcmsvbmV0L2lwdjQvaXBjb25maWcuYw0KLS0t
IGxpbnV4L25ldC9pcHY0L2lwY29uZmlnLmMJVGh1IEp1biAyMiAwOToyMzoy
NiAyMDAwDQorKysgbGludXgtd29yay9uZXQvaXB2NC9pcGNvbmZpZy5jCUZy
aSBKdWwgIDcgMTE6Mjc6MjMgMjAwMA0KQEAgLTI4Miw3ICsyODIsNyBAQA0K
IAkgKi8NCiAJIA0KIAlpZiAoIWljX2hvc3RfbmFtZV9zZXQpDQotCQlzdHJj
cHkoc3lzdGVtX3V0c25hbWUubm9kZW5hbWUsIGluX250b2EoaWNfbXlhZGRy
KSk7DQorCQlpbl9udG9hMihpY19teWFkZHIsIHN5c3RlbV91dHNuYW1lLm5v
ZGVuYW1lKTsNCiANCiAJaWYgKHJvb3Rfc2VydmVyX2FkZHIgPT0gSU5BRERS
X05PTkUpDQogCQlyb290X3NlcnZlcl9hZGRyID0gaWNfc2VydmFkZHI7DQpk
aWZmIC11ciBsaW51eC9uZXQvaXB2NC91dGlscy5jIGxpbnV4LXdvcmsvbmV0
L2lwdjQvdXRpbHMuYw0KLS0tIGxpbnV4L25ldC9pcHY0L3V0aWxzLmMJV2Vk
IEp1biAgOSAxNjo0NTozNyAxOTk5DQorKysgbGludXgtd29yay9uZXQvaXB2
NC91dGlscy5jCUZyaSBKdWwgIDcgMTE6Mjc6MjMgMjAwMA0KQEAgLTQ2LDE3
ICs0Niw2IEBADQogICoJRGlzcGxheSBhbiBJUCBhZGRyZXNzIGluIHJlYWRh
YmxlIGZvcm1hdC4gDQogICovDQogIA0KLWNoYXIgKmluX250b2EoX191MzIg
aW4pDQotew0KLQlzdGF0aWMgY2hhciBidWZmWzE4XTsNCi0JY2hhciAqcDsN
Ci0NCi0JcCA9IChjaGFyICopICZpbjsNCi0Jc3ByaW50ZihidWZmLCAiJWQu
JWQuJWQuJWQiLA0KLQkJKHBbMF0gJiAyNTUpLCAocFsxXSAmIDI1NSksIChw
WzJdICYgMjU1KSwgKHBbM10gJiAyNTUpKTsNCi0JcmV0dXJuKGJ1ZmYpOw0K
LX0NCi0NCiBjaGFyICppbl9udG9hMihfX3UzMiBpbiwgY2hhciAqYnVmZikN
CiB7DQogCXNwcmludGYoYnVmZiwgIiVkLiVkLiVkLiVkIiwgTklQUVVBRChp
bikpOw0KZGlmZiAtdXIgbGludXgvbmV0L25ldHN5bXMuYyBsaW51eC13b3Jr
L25ldC9uZXRzeW1zLmMNCi0tLSBsaW51eC9uZXQvbmV0c3ltcy5jCUZyaSBK
dWwgIDcgMTE6NTQ6NDYgMjAwMA0KKysrIGxpbnV4LXdvcmsvbmV0L25ldHN5
bXMuYwlGcmkgSnVsICA3IDExOjI3OjIzIDIwMDANCkBAIC00MjcsNyArNDI3
LDcgQEANCiBFWFBPUlRfU1lNQk9MKGRldl9vcGVuKTsNCiANCiAvKiBVc2Vk
IGJ5IG90aGVyIG1vZHVsZXMgKi8NCi1FWFBPUlRfU1lNQk9MKGluX250b2Ep
Ow0KK0VYUE9SVF9TWU1CT0woaW5fbnRvYTIpOw0KIA0KIEVYUE9SVF9TWU1C
T0woaXBfcmN2KTsNCiBFWFBPUlRfU1lNQk9MKGFycF9yY3YpOw0KZGlmZiAt
dXIgbGludXgvbmV0L3N1bnJwYy9wbWFwX2NsbnQuYyBsaW51eC13b3JrL25l
dC9zdW5ycGMvcG1hcF9jbG50LmMNCi0tLSBsaW51eC9uZXQvc3VucnBjL3Bt
YXBfY2xudC5jCVdlZCBKdW4gMjEgMTQ6NDM6MzcgMjAwMA0KKysrIGxpbnV4
LXdvcmsvbmV0L3N1bnJwYy9wbWFwX2NsbnQuYwlGcmkgSnVsICA3IDExOjI3
OjIyIDIwMDANCkBAIC04Nyw3ICs4Nyw3IEBADQogfQ0KIA0KICNpZmRlZiBD
T05GSUdfUk9PVF9ORlMNCi1jaGFyICppbl9udG9hKF9fdTMyIGluKTsNCitj
aGFyICppbl9udG9hMihfX3UzMiBpbiwgY2hhciAqYnVmZik7DQogDQogaW50
DQogcnBjX2dldHBvcnRfZXh0ZXJuYWwoc3RydWN0IHNvY2thZGRyX2luICpz
aW4sIF9fdTMyIHByb2csIF9fdTMyIHZlcnMsIGludCBwcm90KQ0KQEAgLTEw
MCw3ICsxMDAsNyBAQA0KIAlkcHJpbnRrKCJSUEM6ICAgICAgcnBjX2dldHBv
cnRfZXh0ZXJuYWwoJXUuJXUuJXUuJXUsICVkLCAlZCwgJWQpXG4iLA0KIAkJ
CU5JUFFVQUQoc2luLT5zaW5fYWRkci5zX2FkZHIpLCBwcm9nLCB2ZXJzLCBw
cm90KTsNCiANCi0Jc3RyY3B5KGhvc3RuYW1lLCBpbl9udG9hKHNpbi0+c2lu
X2FkZHIuc19hZGRyKSk7DQorCWluX250b2EyKHNpbi0+c2luX2FkZHIuc19h
ZGRyLCBob3N0bmFtZSk7DQogCWlmICghKHBtYXBfY2xudCA9IHBtYXBfY3Jl
YXRlKGhvc3RuYW1lLCBzaW4sIHByb3QpKSkNCiAJCXJldHVybiAtRUFDQ0VT
Ow0KIA0KT25seSBpbiBsaW51eDogbnRvYS1wdXJnZS5wYXRjaA0K
---1378811188-1461769515-962989416=:1903--

From owner-netdev@oss.sgi.com Sun Jul  9 11:47:00 2000
Received:  by oss.sgi.com id <S42220AbQGISqk>;
	Sun, 9 Jul 2000 11:46:40 -0700
Received: from cuk.user.link.si ([212.30.95.68]:1519 "HELO linux.cuk.nu")
	by oss.sgi.com with SMTP id <S42185AbQGISqL>;
	Sun, 9 Jul 2000 11:46:11 -0700
Received: from cuk.nu (win.cuk.nu [192.168.3.11])
	by linux.cuk.nu (Postfix) with ESMTP id 2A4F85D813
	for <netdev@oss.sgi.com>; Sun,  9 Jul 2000 20:46:13 +0200 (CEST)
Message-ID: <3968C828.A873C524@cuk.nu>
Date:   Sun, 09 Jul 2000 20:44:56 +0200
From:   Marko Cuk <cuk@cuk.nu>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
Subject: (no subject)
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

 

From owner-netdev@oss.sgi.com Sun Jul  9 12:02:01 2000
Received:  by oss.sgi.com id <S42226AbQGITBv>;
	Sun, 9 Jul 2000 12:01:51 -0700
Received: from cuk.user.link.si ([212.30.95.68]:1775 "HELO linux.cuk.nu")
	by oss.sgi.com with SMTP id <S42185AbQGITBe>;
	Sun, 9 Jul 2000 12:01:34 -0700
Received: from cuk.nu (win.cuk.nu [192.168.3.11])
	by linux.cuk.nu (Postfix) with ESMTP id 393125D813
	for <netdev@oss.sgi.com>; Sun,  9 Jul 2000 21:01:32 +0200 (CEST)
Message-ID: <3968CBBF.6928D91C@cuk.nu>
Date:   Sun, 09 Jul 2000 21:00:15 +0200
From:   Marko Cuk <cuk@cuk.nu>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
Subject: list
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

list

From owner-netdev@oss.sgi.com Mon Jul 10 08:40:30 2000
Received:  by oss.sgi.com id <S42231AbQGJPkU>;
	Mon, 10 Jul 2000 08:40:20 -0700
Received: from tcm.hut.fi ([130.233.44.1]:35085 "EHLO tcm-gw.tcm.hut.fi")
	by oss.sgi.com with ESMTP id <S42185AbQGJPkD>;
	Mon, 10 Jul 2000 08:40:03 -0700
Received: (from smap@localhost)
	by tcm-gw.tcm.hut.fi (8.8.7/8.8.7) id SAA20004
	for <netdev@oss.sgi.com>; Mon, 10 Jul 2000 18:40:10 +0300
Received: from caffeine.tcm.hut.fi(130.233.45.27) by tcm-gw.tcm.hut.fi via smap (V2.0)
	id xma020002; Mon, 10 Jul 00 18:40:02 +0300
Received: from morphine.tcm.hut.fi (morphine.tcm.hut.fi [130.233.45.7])
	by caffeine.tcm.hut.fi (8.9.3+Sun/8.9.2) with ESMTP id SAA18050
	for <netdev@oss.sgi.com>; Mon, 10 Jul 2000 18:40:11 +0300 (EET DST)
Received: from localhost (lpetande@localhost) by morphine.tcm.hut.fi (8.9.2/8.7.1) with ESMTP id SAA12989 for <netdev@oss.sgi.com>; Mon, 10 Jul 2000 18:39:47 +0300 (EET DST)
X-Authentication-Warning: morphine.tcm.hut.fi: lpetande owned process doing -bs
Date:   Mon, 10 Jul 2000 18:39:47 +0300 (EET DST)
From:   Lars Henrik Petander <lpetande@tcm.hut.fi>
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Adding of destination options in IPv6
In-Reply-To: <200007071235.QAA02612@ms2.inr.ac.ru>
Message-ID: <Pine.SOL.4.10.10007101628230.10709-100000@morphine.tcm.hut.fi>
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

Hello!

The current advanced sockets interface makes it possible to add
destination options to packets sent via that socket, but currently there
does not seem to be any generic mechanism for adding options to arbitrary
packets sent to certain destinations. Correct me if I have missed some
mechanism for this purpose.

I think that there is a need for such a mechanism. At least Mobile IPv6
and probably also IPSec need to add destination options to all packets
sent to certain addresses independently of the sockets. We have added
hooks to our Mobile IPv6 module into ip6_output.c's ip6_xmit and
ip6_build_xmit to add the options before fragmentation is done. It seemed
to be the right place to add them.

However, the pmtu calculation does not work with tcp if options are added.
We solved this rather kludgily by reserving space in tcp_ipv6.c for the
maximum number of options that MIPv6 could add. 

Are there any plans for a generic routine for adding extension headers? It
would make the addition of extension headers easier, if the for example
the sk_buff structure had a pointer to a ipv6_txoptions structure and the
headers would be copied to the sk_buff just before doing the pmtu checks
and fragmentation. Also a netfilter hook just before the copying of the
extension headers to the skb would be great.

Any comments on these ideas? BTW, is there any documentation
besides the source code of the operation of the IPv6 routing table and
destination cache in the 2.3 kernel series?

TIA,
Henrik.

--
Henrik Petander
MIPL Mobile IPv6,
<http://www.mipl.mediapoli.com>




From owner-netdev@oss.sgi.com Mon Jul 10 08:49:49 2000
Received:  by oss.sgi.com id <S42232AbQGJPt3>;
	Mon, 10 Jul 2000 08:49:29 -0700
Received: from colin.muc.de ([193.149.48.1]:60172 "HELO colin.muc.de")
	by oss.sgi.com with SMTP id <S42185AbQGJPt0>;
	Mon, 10 Jul 2000 08:49:26 -0700
Received: by colin.muc.de id <140559-3>; Mon, 10 Jul 2000 17:49:25 +0200
Message-ID: <20000710174922.57526@colin.muc.de>
From:   Andi Kleen <ak@muc.de>
To:     Lars Henrik Petander <lpetande@tcm.hut.fi>
Cc:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: Adding of destination options in IPv6
References: <200007071235.QAA02612@ms2.inr.ac.ru> <Pine.SOL.4.10.10007101628230.10709-100000@morphine.tcm.hut.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
In-Reply-To: <Pine.SOL.4.10.10007101628230.10709-100000@morphine.tcm.hut.fi>; from Lars Henrik Petander on Mon, Jul 10, 2000 at 05:41:42PM +0200
Date:   Mon, 10 Jul 2000 17:49:23 +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Jul 10, 2000 at 05:41:42PM +0200, Lars Henrik Petander wrote:
> I think that there is a need for such a mechanism. At least Mobile IPv6
> and probably also IPSec need to add destination options to all packets
> sent to certain addresses independently of the sockets. We have added
> hooks to our Mobile IPv6 module into ip6_output.c's ip6_xmit and
> ip6_build_xmit to add the options before fragmentation is done. It seemed
> to be the right place to add them.

2.4 has netfilterv6, so the right place for it is probably a netfilter
module.


-Andi

From owner-netdev@oss.sgi.com Mon Jul 10 09:28:19 2000
Received:  by oss.sgi.com id <S42190AbQGJQ2A>;
	Mon, 10 Jul 2000 09:28:00 -0700
Received: from liman-3.rutgers.edu ([128.6.110.76]:59603 "EHLO
        liman.rutgers.edu") by oss.sgi.com with ESMTP id <S42185AbQGJQ1x>;
	Mon, 10 Jul 2000 09:27:53 -0700
Received: from pcs.rutgers.edu (hongbol@pcs [128.6.110.64])
	by liman.rutgers.edu (8.9.1/8.9.1) with ESMTP id MAA05925;
	Mon, 10 Jul 2000 12:27:26 -0400 (EDT)
From:   Hongbo Liu <hongbol@winlab.rutgers.edu>
Received: (from hongbol@localhost)
	by pcs.rutgers.edu (8.9.1/8.9.1) id MAA27925;
	Mon, 10 Jul 2000 12:27:50 -0400 (EDT)
Date:   Mon, 10 Jul 2000 12:27:50 -0400 (EDT)
Message-Id: <200007101627.MAA27925@pcs.rutgers.edu>
To:     netdev@oss.sgi.com
Cc:     ato2@home.com
Subject: out of order tcpdump timestamp on Linux
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I'm doing experiment about the LAN traffic flow by using tcpdump. I observed
the following out of order tcpdump timestamp problem:
 
962032606.281506 *.230.77.87.1611 > *.230.77.82.8901: . ack 83985 win 30408 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281622 *.230.77.82.8901 > *.230.77.87.1611: . 112641:114089(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281512 *.230.77.87.1611 > *.230.77.82.8901: . ack 86881 win 28960 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281654 *.230.77.82.8901 > *.230.77.87.1611: P 114089:115537(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281516 *.230.77.87.1611 > *.230.77.82.8901: . ack 89777 win 27512 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281692 *.230.77.82.8901 > *.230.77.87.1611: P 115537:116985(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281521 *.230.77.87.1611 > *.230.77.82.8901: . ack 92673 win 26064 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281719 *.230.77.82.8901 > *.230.77.87.1611: . 116985:118433(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281527 *.230.77.87.1611 > *.230.77.82.8901: . ack 95569 win 24616 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281745 *.230.77.82.8901 > *.230.77.87.1611: P 118433:119881(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281533 *.230.77.87.1611 > *.230.77.82.8901: . ack 98465 win 23168 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281771 *.230.77.82.8901 > *.230.77.87.1611: P 119881:121329(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281538 *.230.77.87.1611 > *.230.77.82.8901: . ack 101361 win 21720 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281796 *.230.77.82.8901 > *.230.77.87.1611: . 121329:122777(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281544 *.230.77.87.1611 > *.230.77.82.8901: . ack 104257 win 20272 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281821 *.230.77.82.8901 > *.230.77.87.1611: P 122777:124225(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281549 *.230.77.87.1611 > *.230.77.82.8901: . ack 107153 win 18824 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281846 *.230.77.82.8901 > *.230.77.87.1611: P 124225:125673(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281555 *.230.77.87.1611 > *.230.77.82.8901: . ack 110049 win 17376 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281873 *.230.77.82.8901 > *.230.77.87.1611: P 125673:127121(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281559 *.230.77.87.1611 > *.230.77.82.8901: . ack 112641 win 30408 <nop,nop,timestamp 39071924 32468033> (DF)
962032606.281896 *.230.77.82.8901 > *.230.77.87.1611: . 127121:128569(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281907 *.230.77.82.8901 > *.230.77.87.1611: P 128569:130017(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281918 *.230.77.82.8901 > *.230.77.87.1611: P 130017:131465(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281928 *.230.77.82.8901 > *.230.77.87.1611: . 131465:132913(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281938 *.230.77.82.8901 > *.230.77.87.1611: P 132913:134361(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281948 *.230.77.82.8901 > *.230.77.87.1611: P 134361:135809(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)
962032606.281960 *.230.77.82.8901 > *.230.77.87.1611: P 135809:137257(1448) ack 1000010 win 31856 <nop,nop,timestamp 32468034 39071924> (DF)

The two hosts are in the same LAN (Ethernet 100Mbps). Both are linux box. 
The tcpdump is version 3.4 with libpcap-0.4. I had thought of two possible 
reasons, but both are problematic. 
One is local clock adjustment. But this reason is not so persuasive. 
Since if the decreasing of timestamp is because local clock is faster than 
the global clock. This kind of adjustment should not be so frequently with 
the minimal interval of 0.004 ms!
Another possible reason is there are two different threads responsible for
getting timestamp of tcpdump and they are not synchronized. But as I use
top, I found only one thread for tcpdump.

Does anyone have any idea on what happened with Linux and tcpdump and
how to fix it?

-Hongbo
 


From owner-netdev@oss.sgi.com Mon Jul 10 13:53:01 2000
Received:  by oss.sgi.com id <S42209AbQGJUwv>;
	Mon, 10 Jul 2000 13:52:51 -0700
Received: from mail.informatik.uni-ulm.de ([134.60.68.63]:21851 "EHLO
        mail.informatik.uni-ulm.de") by oss.sgi.com with ESMTP
	id <S42188AbQGJUwb>; Mon, 10 Jul 2000 13:52:31 -0700
Received: from [134.60.8.165] (helo=ferret.extern.uni-ulm.de ident=user94646)
	by mail.informatik.uni-ulm.de with esmtp (Exim 3.00 #1)
	id 13BkXr-0004Sg-00
	for netdev@oss.sgi.com; Mon, 10 Jul 2000 22:52:52 +0200
Received: from blackbird.extern.uni-ulm.de ([172.16.1.10] ident=root)
	by ferret.extern.uni-ulm.de with esmtp (Exim 3.02 #2)
	id 13BkUm-0000D2-00
	for netdev@oss.sgi.com; Mon, 10 Jul 2000 22:49:40 +0200
Received: (from stefan@localhost)
	by blackbird.extern.uni-ulm.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id WAA01120
	for netdev@oss.sgi.com; Mon, 10 Jul 2000 22:50:47 +0200
Date:   Mon, 10 Jul 2000 22:50:47 +0200
From:   Stefan Schlott <stefan.schlott@student.uni-ulm.de>
To:     netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
Message-ID: <20000710225047.A838@blackbird.extern.uni-ulm.de>
References: <200007071235.QAA02612@ms2.inr.ac.ru> <Pine.SOL.4.10.10007101628230.10709-100000@morphine.tcm.hut.fi> <20000710174922.57526@colin.muc.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20000710174922.57526@colin.muc.de>; from ak@muc.de on Mon, Jul 10, 2000 at 05:49:23PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello,

> > I think that there is a need for such a mechanism. At least Mobile IPv6
> > and probably also IPSec need to add destination options to all packets
> > sent to certain addresses independently of the sockets. We have added
> > hooks to our Mobile IPv6 module into ip6_output.c's ip6_xmit and
> > ip6_build_xmit to add the options before fragmentation is done.
> 2.4 has netfilterv6, so the right place for it is probably a netfilter
> module.
Please tell me that I am wrong, but afaik the netfilter hooks only return
fragmented packets (nf6 hooks are called after fragmentation when sending,
and before defragmentation when receiving a packet).

Stefan.

-- 
*--- please cut here... -------------------------------------- thanks! ---*
|-> E-Mail: stefan.schlott@student.uni-ulm.de    DH-PGP-Key: 0x2F36F4FE <-|
| An unrecoverable error occured and windows will shut down. If the       |
| problem persists please contact http://www.linux.org/                   |
|   -- Seen on Slashdot (08.02.2000)                                      |
*-------------------------------------------------------------------------*

From owner-netdev@oss.sgi.com Mon Jul 10 14:07:31 2000
Received:  by oss.sgi.com id <S42218AbQGJVHW>;
	Mon, 10 Jul 2000 14:07:22 -0700
Received: from gst.gst.com ([208.219.159.150]:51209 "EHLO gst.gst.com")
	by oss.sgi.com with ESMTP id <S42188AbQGJVHB>;
	Mon, 10 Jul 2000 14:07:01 -0700
Received: from x0.org ([208.219.159.214])
	by  gst.gst.com (8.8.8/8.8.8) with ESMTP id RAA24335
	for <netdev@oss.sgi.com>; Mon, 10 Jul 2000 17:18:26 -0400 (EDT)
Message-ID: <396A3AF9.68A8C278@x0.org>
Date:   Mon, 10 Jul 2000 17:07:05 -0400
From:   Andy <andy@x0.org>
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test3-scps i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: tcp_poll? What is that?
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

Hello!

I am working on a new transport layer protocol and am using TCP as an
example.
Here is my problem. I found function tcp_poll (Linux 2.4 - pre3 test3:
net/ipv4/tcp.c:554).

The description says:

547 /*
548  *      Wait for a TCP event.
549  *
550  *      Note that we don't need to lock the socket, as the upper
poll layers
551  *      take care of normal races (between the test and the event)
and we don't
552  *      go look at any of the socket buffers directly.
553  */

Can anybody explain if this is used and what is the condition when this
is used?

			Andy

From owner-netdev@oss.sgi.com Mon Jul 10 14:12:51 2000
Received:  by oss.sgi.com id <S42217AbQGJVMc>;
	Mon, 10 Jul 2000 14:12:32 -0700
Received: from pizda.ninka.net ([216.101.162.242]:25479 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S42188AbQGJVMU>;
	Mon, 10 Jul 2000 14:12:20 -0700
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id OAA08230;
	Mon, 10 Jul 2000 14:01:42 -0700
Date:   Mon, 10 Jul 2000 14:01:42 -0700
Message-Id: <200007102101.OAA08230@pizda.ninka.net>
X-Authentication-Warning: pizda.ninka.net: davem set sender to davem@redhat.com using -f
From:   "David S. Miller" <davem@redhat.com>
To:     andy@x0.org
CC:     netdev@oss.sgi.com
In-reply-to: <396A3AF9.68A8C278@x0.org> (message from Andy on Mon, 10 Jul 2000
	17:07:05 -0400)
Subject: Re: tcp_poll? What is that?
References:  <396A3AF9.68A8C278@x0.org>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date:   Mon, 10 Jul 2000 17:07:05 -0400
   From: Andy <andy@x0.org>

   Can anybody explain if this is used and what is the condition when
   this is used?

select() on a TCP_LISTEN state socket, look at the caller.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Tue Jul 11 00:11:24 2000
Received:  by oss.sgi.com id <S42205AbQGKHLF>;
	Tue, 11 Jul 2000 00:11:05 -0700
Received: from eidolon.muppetlabs.com ([216.231.41.85]:3860 "EHLO
        eidolon.muppetlabs.com") by oss.sgi.com with ESMTP
	id <S42188AbQGKHK4>; Tue, 11 Jul 2000 00:10:56 -0700
Received: from localhost (bench@localhost)
	by eidolon.muppetlabs.com (8.9.3/8.9.3) with ESMTP id SAA03835
	for <netdev@oss.sgi.com>; Mon, 10 Jul 2000 18:06:53 -0700
Date:   Mon, 10 Jul 2000 18:06:53 -0700 (PDT)
From:   Ben <bench@muppetlabs.com>
To:     netdev@oss.sgi.com
Subject: listen queues for AF_UNIX sockets
Message-ID: <Pine.LNX.4.10.10007101758280.7471-100000@eidolon.muppetlabs.com>
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

A long time ago there was a thread on this list where it was pointed out
that listen queues are not built for AF_UNIX sockets. I never saw any
follow-up about this being fixed, and it's not clear from the comments in
af_unix.c for recent versions of the 2.2 kernel that the problem has been
delt with... was it? Does listen() now do what you would expect it to for
unix domain sockets?

I ask because the symptoms I'm having in my program indicate that unix
domain sockets still might not have queues.


From owner-netdev@oss.sgi.com Tue Jul 11 03:41:46 2000
Received:  by oss.sgi.com id <S42222AbQGKKlg>;
	Tue, 11 Jul 2000 03:41:36 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:18819 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42220AbQGKKlM>; Tue, 11 Jul 2000 03:41:12 -0700
Received: from fred.muc.de (none@ns1099.munich.netsurf.de [195.180.235.99])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id MAA26917;
	Tue, 11 Jul 2000 12:41:13 +0200 (MET DST)
Received: from andi by fred.muc.de with local (Exim 2.05 #1)
	id 13BxUo-0000FQ-00; Tue, 11 Jul 2000 12:42:34 +0200
Date:   Tue, 11 Jul 2000 12:42:34 +0200
From:   Andi Kleen <ak@muc.de>
To:     Stefan Schlott <stefan.schlott@student.uni-ulm.de>
Cc:     netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
Message-ID: <20000711124233.A924@fred.muc.de>
References: <200007071235.QAA02612@ms2.inr.ac.ru> <Pine.SOL.4.10.10007101628230.10709-100000@morphine.tcm.hut.fi> <20000710174922.57526@colin.muc.de> <20000710225047.A838@blackbird.extern.uni-ulm.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <20000710225047.A838@blackbird.extern.uni-ulm.de>; from Stefan Schlott on Mon, Jul 10, 2000 at 10:53:46PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Jul 10, 2000 at 10:53:46PM +0200, Stefan Schlott wrote:
> Hello,
> 
> > > I think that there is a need for such a mechanism. At least Mobile IPv6
> > > and probably also IPSec need to add destination options to all packets
> > > sent to certain addresses independently of the sockets. We have added
> > > hooks to our Mobile IPv6 module into ip6_output.c's ip6_xmit and
> > > ip6_build_xmit to add the options before fragmentation is done.
> > 2.4 has netfilterv6, so the right place for it is probably a netfilter
> > module.
> Please tell me that I am wrong, but afaik the netfilter hooks only return
> fragmented packets (nf6 hooks are called after fragmentation when sending,
> and before defragmentation when receiving a packet).

Correct, it occurs after fragmentation. 


-Andi


From owner-netdev@oss.sgi.com Tue Jul 11 04:11:46 2000
Received:  by oss.sgi.com id <S42224AbQGKLLc>;
	Tue, 11 Jul 2000 04:11:32 -0700
Received: from sirius-ether.rz.uni-ulm.de ([134.60.1.36]:62205 "EHLO
        mail.rz.uni-ulm.de") by oss.sgi.com with ESMTP id <S42220AbQGKLLD>;
	Tue, 11 Jul 2000 04:11:03 -0700
Received: from student.uni-ulm.de (votimand.informatik.uni-ulm.de [134.60.77.186])
	by mail.rz.uni-ulm.de (8.9.3/8.9.3) with ESMTP id NAA28039;
	Tue, 11 Jul 2000 13:05:27 +0200 (MEST)
Message-ID: <396AFFA9.A64FEDCB@student.uni-ulm.de>
Date:   Tue, 11 Jul 2000 13:06:17 +0200
From:   Stefan Schlott <stefan.schlott@student.uni-ulm.de>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
References: <200007071235.QAA02612@ms2.inr.ac.ru> <Pine.SOL.4.10.10007101628230.10709-100000@morphine.tcm.hut.fi> <20000710174922.57526@colin.muc.de> <20000710225047.A838@blackbird.extern.uni-ulm.de> <20000711124233.A924@fred.muc.de>
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

Andi Kleen wrote:

> > Please tell me that I am wrong, but afaik the netfilter hooks only return
> > fragmented packets (nf6 hooks are called after fragmentation when sending,
> > and before defragmentation when receiving a packet).
> Correct, it occurs after fragmentation.
*sigh* which is why Lars (and me, too) had to modify the ipv6 module.
Passing unfragmented packets to nf6 would be really hard to implement
(as far as I understand the code)... but it would be really nice
to have an interface which can modify whole packets when sending
and receiving; the same thing for forwarding would result in an "always
defragment" option, which would be somewhat "un-ip6-ish" :-)

Stefan.

From owner-netdev@oss.sgi.com Tue Jul 11 04:29:18 2000
Received:  by oss.sgi.com id <S42225AbQGKL26>;
	Tue, 11 Jul 2000 04:28:58 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:64936 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42220AbQGKL2k>;
	Tue, 11 Jul 2000 04:28:40 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id HAA02752;
	Tue, 11 Jul 2000 07:28:49 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id HAA03360;
	Tue, 11 Jul 2000 07:28:48 -0400 (EDT)
Date:   Tue, 11 Jul 2000 07:28:48 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     Stefan Schlott <stefan.schlott@student.uni-ulm.de>
cc:     netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
In-Reply-To: <396AFFA9.A64FEDCB@student.uni-ulm.de>
Message-ID: <Pine.GSO.4.20.0007110721180.3334-100000@shell.cyberus.ca>
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 Tue, 11 Jul 2000, Stefan Schlott wrote:

> *sigh* which is why Lars (and me, too) had to modify the ipv6 module.
> Passing unfragmented packets to nf6 would be really hard to implement
> (as far as I understand the code)... but it would be really nice
> to have an interface which can modify whole packets when sending
> and receiving; the same thing for forwarding would result in an "always
> defragment" option, which would be somewhat "un-ip6-ish" :-)

I might be missing something:

If you dont want to deal with fragmentation then on input use
NF_IP6_LOCAL_IN and output NF_IP6_POST_ROUTING

cheers,
jamal






From owner-netdev@oss.sgi.com Tue Jul 11 15:47:34 2000
Received:  by oss.sgi.com id <S42217AbQGKWrO>;
	Tue, 11 Jul 2000 15:47:14 -0700
Received: from mail.informatik.uni-ulm.de ([134.60.68.63]:52862 "EHLO
        mail.informatik.uni-ulm.de") by oss.sgi.com with ESMTP
	id <S42209AbQGKWrL>; Tue, 11 Jul 2000 15:47:11 -0700
Received: from [134.60.8.94] (helo=ferret.extern.uni-ulm.de ident=user87003)
	by mail.informatik.uni-ulm.de with esmtp (Exim 3.00 #1)
	id 13C6Vq-0002kp-00; Tue, 11 Jul 2000 22:20:14 +0200
Received: from blackbird.extern.uni-ulm.de ([172.16.1.10] ident=root)
	by ferret.extern.uni-ulm.de with esmtp (Exim 3.02 #2)
	id 13C6Ob-0000Ju-00; Tue, 11 Jul 2000 22:12:45 +0200
Received: (from stefan@localhost)
	by blackbird.extern.uni-ulm.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id WAA01718;
	Tue, 11 Jul 2000 22:13:16 +0200
Date:   Tue, 11 Jul 2000 22:13:16 +0200
From:   Stefan Schlott <stefan.schlott@student.uni-ulm.de>
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
Message-ID: <20000711221316.A1386@blackbird.extern.uni-ulm.de>
References: <396AFFA9.A64FEDCB@student.uni-ulm.de> <200007111512.TAA16460@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <200007111512.TAA16460@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Jul 11, 2000 at 07:12:38PM +0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello,

> > and receiving; the same thing for forwarding would result in an "always
> > defragment" option, which would be somewhat "un-ip6-ish" :-)
> It is anti-ip4-ish with the same success. 8)
:-)

> My personal opinion is that current mobile IPv6 is one big piece
> of shit yet. 8)8) Piggibacking such options to data packets
> introduces no advantages, but lots of troubles.
It's even worse... I am working on IPsec ;-)
The solution you described seems to be the only possibility for the moment.
I am trying to calculate the size of the new headers, thus determining the
new ext_header_len. As a second step, I do my modifications in ip6_xmit/
ip6_build_xmit.
A general interface for this work would be ugly, but at least there would
be an interface ;-)
Any comments?

Stefan.

-- 
*--- please cut here... -------------------------------------- thanks! ---*
|-> E-Mail: stefan.schlott@student.uni-ulm.de    DH-PGP-Key: 0x2F36F4FE <-|
| HAL 9000 [nervous] : "Dave, put down those Windows disks !!!"           |
*-------------------------------------------------------------------------*

From owner-netdev@oss.sgi.com Tue Jul 11 15:49:23 2000
Received:  by oss.sgi.com id <S42209AbQGKWtE>;
	Tue, 11 Jul 2000 15:49:04 -0700
Received: from gst.gst.com ([208.219.159.150]:20243 "EHLO gst.gst.com")
	by oss.sgi.com with ESMTP id <S42190AbQGKWsq>;
	Tue, 11 Jul 2000 15:48:46 -0700
Received: from x0.org ([208.219.159.214])
	by  gst.gst.com (8.8.8/8.8.8) with ESMTP id MAA25328
	for <netdev@oss.sgi.com>; Tue, 11 Jul 2000 12:32:02 -0400 (EDT)
Message-ID: <396B495A.F0B2BD93@x0.org>
Date:   Tue, 11 Jul 2000 12:20:42 -0400
From:   Andy <andy@x0.org>
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test3-scps i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: TCP - Kernel module. Success!!
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

Hello!

I managed to convert TCP into kernel module. It works and it seems
pretty
stabile. The only thing that does not work is the 'Used by'. Currently
it
is considered unused all the time, which can result in machine crash
when
you try to unload the module. There are some minor uglynesses concerning
some casting. I hope I will be able to find a better solution than to 
create a function inside TCP module that takes void* as an argument and
performs casting inside.


By making TCP a kernel module, I proved that it is possible and I
modified 
some of the  algorithms in the IP code, so that it is more universal.
For example now you can actually add a new stream type transport layer 
protocol with almost no kernel modification.
This is great for inclusion of new transport protocols that might/will
come
in the future.
It also makes the inclusion of IPSEC much easier.

The kernel used was 2.4 - test3 pre3. The size of kernel module is 95k, 
which is significant difference for embeded systems.

I am in the process of creating a patch.

Please comment!

				Andy

From owner-netdev@oss.sgi.com Tue Jul 11 21:05:36 2000
Received:  by oss.sgi.com id <S42224AbQGLEFQ>;
	Tue, 11 Jul 2000 21:05:16 -0700
Received: from cpu2747.adsl.bellglobal.com ([207.236.55.216]:39929 "EHLO
        grendel.conscoop.ottawa.on.ca") by oss.sgi.com with ESMTP
	id <S42217AbQGLEEz>; Tue, 11 Jul 2000 21:04:55 -0700
Received: (from rgb@localhost)
	by grendel.conscoop.ottawa.on.ca (8.9.0/8.9.0) id AAA23306;
	Wed, 12 Jul 2000 00:04:54 -0400
Date:   Wed, 12 Jul 2000 00:04:53 -0400
From:   Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>
To:     Stefan Schlott <stefan.schlott@student.uni-ulm.de>
Cc:     netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
Message-ID: <20000712000453.A23228@grendel.conscoop.ottawa.on.ca>
References: <396AFFA9.A64FEDCB@student.uni-ulm.de> <200007111512.TAA16460@ms2.inr.ac.ru> <20000711221316.A1386@blackbird.extern.uni-ulm.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S"
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20000711221316.A1386@blackbird.extern.uni-ulm.de>; from stefan.schlott@student.uni-ulm.de on Tue, Jul 11, 2000 at 10:13:16PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 11, 2000 at 10:13:16PM +0200, Stefan Schlott wrote:
> Hello,
>=20
> > > and receiving; the same thing for forwarding would result in an "alwa=
ys
> > > defragment" option, which would be somewhat "un-ip6-ish" :-)
> > It is anti-ip4-ish with the same success. 8)
> :-)
>=20
> > My personal opinion is that current mobile IPv6 is one big piece
> > of shit yet. 8)8) Piggibacking such options to data packets
> > introduces no advantages, but lots of troubles.

> It's even worse... I am working on IPsec ;-)

On which implementation are you working?  What platform/OS?  Is it
GPL?

Are you coming to OLS?

> Stefan.

	slainte mhath, RGB
--=20
Richard Guy Briggs -- PGP key available            Auto-Free Ottawa! Canada
<www.conscoop.ottawa.on.ca/rgb/>                       <www.flora.org/afo/>
Prevent Internet Wiretapping!        --        FreeS/WAN:<www.freeswan.org>
Thanks for voting Green! -- <green.ca>      Marillion:<www.marillion.co.uk>

--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i

iQCVAwUBOWvuY9+sBuIhFagtAQG1rAP/YUIc1UljA815C9gGgcrMOy4fAdTdoh2Q
Dn63IuOSOouDwUTbUBXstH73e8wMzQ2TL+zC0y/VT7QDTYiv61oDt9jK+AkVMLw4
edtBZAapjUqWEjgybVzjqNtfWSOK7xp7XNtH1kkl3Bqlw6Ixumt7jBvnANryWL8w
XR0fMNd210k=
=F9pW
-----END PGP SIGNATURE-----

--AhhlLboLdkugWU4S--

From owner-netdev@oss.sgi.com Wed Jul 12 00:03:47 2000
Received:  by oss.sgi.com id <S42225AbQGLHDh>;
	Wed, 12 Jul 2000 00:03:37 -0700
Received: from asbestos.linuxcare.com.au ([203.17.0.30]:13300 "HELO halfway")
	by oss.sgi.com with SMTP id <S42217AbQGLHDM>;
	Wed, 12 Jul 2000 00:03:12 -0700
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway (Postfix) with ESMTP
	id 313AB8172; Wed, 12 Jul 2000 16:56:28 +1000 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     netdev@oss.sgi.com
Cc:     davem@vger.rutgers.edu
Subject: [PATCH] Bogus extra bytes in ICMP errors in 2.3.0-test3-7
Date:   Wed, 12 Jul 2000 16:56:28 +1000
Message-Id: <20000712065629.313AB8172@halfway>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Finally tracked down why we send 20 extra `crap' bytes in ICMP
responses: someone changed 2.2's `skb_in->len' to
`(skb_in->tail-(u8*)iph)'.

Rusty.
--- working-2.4.0-test3-7/net/ipv4/icmp.c.~1~	Thu Jun 29 01:26:09 2000
+++ working-2.4.0-test3-7/net/ipv4/icmp.c	Wed Jul 12 16:46:37 2000
@@ -669,7 +669,7 @@
 	room -= sizeof(struct iphdr) + icmp_param.replyopts.optlen;
 	room -= sizeof(struct icmphdr);
 
-	icmp_param.data_len=(iph->ihl<<2)+(skb_in->tail-(u8*)iph);
+	icmp_param.data_len = skb_in->tail - (u8*)iph;
 	if (icmp_param.data_len > room)
 		icmp_param.data_len = room;
 	

--
Hacking time.

From owner-netdev@oss.sgi.com Wed Jul 12 01:57:37 2000
Received:  by oss.sgi.com id <S42226AbQGLI5R>;
	Wed, 12 Jul 2000 01:57:17 -0700
Received: from tcm.hut.fi ([130.233.44.1]:12294 "EHLO tcm-gw.tcm.hut.fi")
	by oss.sgi.com with ESMTP id <S42217AbQGLI5B>;
	Wed, 12 Jul 2000 01:57:01 -0700
Received: (from smap@localhost)
	by tcm-gw.tcm.hut.fi (8.8.7/8.8.7) id LAA28247
	for <netdev@oss.sgi.com>; Wed, 12 Jul 2000 11:57:09 +0300
Received: from caffeine.tcm.hut.fi(130.233.45.27) by tcm-gw.tcm.hut.fi via smap (V2.0)
	id xma028239; Wed, 12 Jul 00 11:56:55 +0300
Received: from morphine.tcm.hut.fi (morphine.tcm.hut.fi [130.233.45.7])
	by caffeine.tcm.hut.fi (8.9.3+Sun/8.9.2) with ESMTP id LAA18581;
	Wed, 12 Jul 2000 11:57:04 +0300 (EET DST)
Received: from localhost (lpetande@localhost) by morphine.tcm.hut.fi (8.9.2/8.7.1) with ESMTP id LAA16262; Wed, 12 Jul 2000 11:56:39 +0300 (EET DST)
X-Authentication-Warning: morphine.tcm.hut.fi: lpetande owned process doing -bs
Date:   Wed, 12 Jul 2000 11:56:39 +0300 (EET DST)
From:   Lars Henrik Petander <lpetande@tcm.hut.fi>
To:     Stefan Schlott <stefan.schlott@student.uni-ulm.de>
cc:     kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
In-Reply-To: <20000711221316.A1386@blackbird.extern.uni-ulm.de>
Message-ID: <Pine.SOL.4.10.10007121149150.15093-100000@morphine.tcm.hut.fi>
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 Tue, 11 Jul 2000, Stefan Schlott wrote:

> Hello,
> 
> > > and receiving; the same thing for forwarding would result in an "always
> > > defragment" option, which would be somewhat "un-ip6-ish" :-)
> > It is anti-ip4-ish with the same success. 8)
> :-)
> 
> > My personal opinion is that current mobile IPv6 is one big piece
> > of shit yet. 8)8) Piggibacking such options to data packets
> > introduces no advantages, but lots of troubles.

Mobile IPv6 has its problems, but it is is an improvement to Mobile IPv4.
Also the better mobility support in IPv6 can be lead to earlier adoption
of IPv6. Piggybacking signaling information might not provide any
benefits to operating system designers, but it does provide benefits to
network operators by decreasing the load on their network.

Henrik

> 
> Stefan.
> 
> -- 
> *--- please cut here... -------------------------------------- thanks! ---*
> |-> E-Mail: stefan.schlott@student.uni-ulm.de    DH-PGP-Key: 0x2F36F4FE <-|
> | HAL 9000 [nervous] : "Dave, put down those Windows disks !!!"           |
> *-------------------------------------------------------------------------*
> 


From owner-netdev@oss.sgi.com Wed Jul 12 04:44:18 2000
Received:  by oss.sgi.com id <S42217AbQGLLoI>;
	Wed, 12 Jul 2000 04:44:08 -0700
Received: from [192.203.80.144] ([192.203.80.144]:59664 "HELO kaiser.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42209AbQGLLns>;
	Wed, 12 Jul 2000 04:43:48 -0700
Received: from ms2.inr.ac.ru (minus.inr.ac.ru [3ffe:2400::280:c8ff:fe59:5bcc]) by kaiser.inr.ac.ru (8.6.13/ANK+IPv6) with ESMTP id TAA32283 for <netdev@oss.sgi.com>; Tue, 11 Jul 2000 19:12:53 +0400
From:   kuznet@ms2.inr.ac.ru
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA16460; Tue, 11 Jul 2000 19:12:38 +0400
Message-Id: <200007111512.TAA16460@ms2.inr.ac.ru>
Subject: Re: Adding of destination options in IPv6
To:     stefan.schlott@student.uni-ulm.DE (Stefan Schlott)
Date:   Tue, 11 Jul 2000 19:12:38 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <396AFFA9.A64FEDCB@student.uni-ulm.de> from "Stefan Schlott" at Jul 11, 0 04:13:06 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 1130      
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> and receiving; the same thing for forwarding would result in an "always
> defragment" option, which would be somewhat "un-ip6-ish" :-)

It is anti-ip4-ish with the same success. 8)

Well, I am glad to hear that someone, who is interested in mobile IPv6
understood main obstacle on the way. It is crucial progress. 8)


Honestly, I do not know any answer. Adding variable options to TCP
(and UDP etc) packets is solvable task and current pmtu discovery
can be modified to handle this. But I would prefer not to see this
inside stack though.

What's about UDP, you have to defrag on output, if you are in hurry.
In 2.5 netfilter will receive full frames, I hope, and problem will disappear.

What's about TCP, add maximal size of mobile options to ext_header_len,
when it can be mobile _potentially_. Doing MSS varying in flight is
possible (we do this with SACKs on bidirectional connections),
but I do not see much of sense to make this.

My personal opinion is that current mobile IPv6 is one big piece
of shit yet. 8)8) Piggibacking such options to data packets
introduces no advantages, but lots of troubles.

Alexey

From owner-netdev@oss.sgi.com Wed Jul 12 06:18:27 2000
Received:  by oss.sgi.com id <S42224AbQGLNSS>;
	Wed, 12 Jul 2000 06:18:18 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:64701 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42209AbQGLNSD>; Wed, 12 Jul 2000 06:18:03 -0700
Received: from fred.muc.de (none@ns1051.munich.netsurf.de [195.180.235.51])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id PAA14712;
	Wed, 12 Jul 2000 15:18:07 +0200 (MET DST)
Received: from andi by fred.muc.de with local (Exim 2.05 #1)
	id 13C2sD-0000kF-00; Tue, 11 Jul 2000 18:27:05 +0200
Date:   Tue, 11 Jul 2000 18:27:05 +0200
From:   Andi Kleen <ak@muc.de>
To:     Stefan Schlott <stefan.schlott@student.uni-ulm.de>
Cc:     netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
Message-ID: <20000711182705.A2855@fred.muc.de>
References: <200007071235.QAA02612@ms2.inr.ac.ru> <Pine.SOL.4.10.10007101628230.10709-100000@morphine.tcm.hut.fi> <20000710174922.57526@colin.muc.de> <20000710225047.A838@blackbird.extern.uni-ulm.de> <20000711124233.A924@fred.muc.de> <396AFFA9.A64FEDCB@student.uni-ulm.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <396AFFA9.A64FEDCB@student.uni-ulm.de>; from Stefan Schlott on Tue, Jul 11, 2000 at 01:12:42PM +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Jul 11, 2000 at 01:12:42PM +0200, Stefan Schlott wrote:
> Andi Kleen wrote:
> 
> > > Please tell me that I am wrong, but afaik the netfilter hooks only return
> > > fragmented packets (nf6 hooks are called after fragmentation when sending,
> > > and before defragmentation when receiving a packet).
> > Correct, it occurs after fragmentation.
> *sigh* which is why Lars (and me, too) had to modify the ipv6 module.
> Passing unfragmented packets to nf6 would be really hard to implement
> (as far as I understand the code)... but it would be really nice
> to have an interface which can modify whole packets when sending
> and receiving; the same thing for forwarding would result in an "always
> defragment" option, which would be somewhat "un-ip6-ish" :-)

The problem is that the unfragmented packet does not exist for locally
originated packets. The fragments are directly created from the user space
buffer. About the only way to get an unfragmented packet is to reassemble
it (like the v4 code does). For forwarded packets you would have to do that
anyways (although IPv6 stricly discourages it) 


-Andi


From owner-netdev@oss.sgi.com Wed Jul 12 09:13:38 2000
Received:  by oss.sgi.com id <S42225AbQGLQN1>;
	Wed, 12 Jul 2000 09:13:27 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:7951 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42209AbQGLQNR>;
	Wed, 12 Jul 2000 09:13:17 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA29362; Wed, 12 Jul 2000 20:13:12 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200007121613.UAA29362@ms2.inr.ac.ru>
Subject: Re: Adding of destination options in IPv6
To:     stefan.schlott@student.uni-ulm.de (Stefan Schlott)
Date:   Wed, 12 Jul 2000 20:13:12 +0400 (MSK DST)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20000711221316.A1386@blackbird.extern.uni-ulm.de> from "Stefan Schlott" at Jul 11, 0 10:13:16 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 805       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> new ext_header_len. As a second step, I do my modifications in ip6_xmit/
> ip6_build_xmit.
> A general interface for this work would be ugly, but at least there would
> be an interface ;-)
> Any comments?

Comment is that it is right direction.

Only it is not so straightforward. Such adjustments violate existing
locking hierarchy, so that you have to design thing, which does not exist
now. Namely, message queue for relaible feedback from lower layers
to upper ones. It is for mobile IPv6.

And it still will not work with IPsec, because you cannot send anything
not-encrypted, while the information trips back to sender. So, direct
surgery inside TCP is required in any case.

Reserving space is much simpler and seems not to hurt anyone.
Surgeons wait, while terapeutics helps. 8)

Alexey

From owner-netdev@oss.sgi.com Wed Jul 12 09:37:58 2000
Received:  by oss.sgi.com id <S42211AbQGLQhr>;
	Wed, 12 Jul 2000 09:37:47 -0700
Received: from minus.inr.ac.ru ([193.233.7.97]:21007 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S42209AbQGLQhd>;
	Wed, 12 Jul 2000 09:37:33 -0700
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA29581; Wed, 12 Jul 2000 20:36:41 +0400
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200007121636.UAA29581@ms2.inr.ac.ru>
Subject: Re: Adding of destination options in IPv6
To:     lpetande@tcm.hut.fi (Lars Henrik Petander)
Date:   Wed, 12 Jul 2000 20:36:41 +0400 (MSK DST)
Cc:     stefan.schlott@student.uni-ulm.de, netdev@oss.sgi.com
In-Reply-To: <Pine.SOL.4.10.10007121149150.15093-100000@morphine.tcm.hut.fi> from "Lars Henrik Petander" at Jul 12, 0 11:56:39 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 358       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

>				but it does provide benefits to
> network operators by decreasing the load on their network.

Sorry. Introducing perturbations to data stream never resulted
in saving something and never will.

Piggybacking works when it does not harm data stream.
If it does, it is made with control protocols. It is ABC of
networking, programming etc.

Alexey

From owner-netdev@oss.sgi.com Thu Jul 13 05:35:56 2000
Received:  by oss.sgi.com id <S42238AbQGMMfg>;
	Thu, 13 Jul 2000 05:35:36 -0700
Received: from laurin.munich.netsurf.de ([194.64.166.1]:13490 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S42211AbQGMMfH>; Thu, 13 Jul 2000 05:35:07 -0700
Received: from fred.muc.de (none@ns1183.munich.netsurf.de [195.180.235.183])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id OAA13053;
	Thu, 13 Jul 2000 14:34:30 +0200 (MET DST)
Received: from andi by fred.muc.de with local (Exim 2.05 #1)
	id 13CiDe-0000ES-00; Thu, 13 Jul 2000 14:35:58 +0200
Date:   Thu, 13 Jul 2000 14:35:58 +0200
From:   Andi Kleen <ak@muc.de>
To:     davem@redhat.com
Cc:     "A.N.Kuznetsov" <kuznet@ms2.inr.ac.ru>, netdev@oss.sgi.com
Subject: [PATCH] Turn off tw_recycle
Message-ID: <20000713143558.A888@fred.muc.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hallo David,

It unfortunately turns out that the clever TW recycle trick does not work.
It assumes that an IP address has a shared timestamp clock, but that is 
not true with masquerading and NAT. The problem is that it arbitarily denies
service to masqueraded hosts when they're outside of the saved timestamp
window. Me and Alexey found no suitable way to fix that problem (there
is no way to detect NAT/masquerading), so I propose the following patch 
to turn it off.


-Andi


Index: net/ipv4/tcp_input.c
===================================================================
RCS file: /cvs/linux/net/ipv4/tcp_input.c,v
retrieving revision 1.193
diff -u -u -r1.193 tcp_input.c
--- net/ipv4/tcp_input.c	2000/04/20 14:41:16	1.193
+++ net/ipv4/tcp_input.c	2000/07/13 12:42:24
@@ -80,7 +80,7 @@
 int sysctl_tcp_syncookies = SYNC_INIT; 
 int sysctl_tcp_stdurg;
 int sysctl_tcp_rfc1337;
-int sysctl_tcp_tw_recycle = 1;
+int sysctl_tcp_tw_recycle = 0;
 int sysctl_tcp_abort_on_overflow = 0;
 int sysctl_tcp_max_orphans = NR_FILE;
 int sysctl_tcp_max_tw_buckets = NR_FILE*2;

-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Thu Jul 13 08:32:47 2000
Received:  by oss.sgi.com id <S42212AbQGMPch>;
	Thu, 13 Jul 2000 08:32:37 -0700
Received: from gst.gst.com ([208.219.159.150]:53263 "EHLO gst.gst.com")
	by oss.sgi.com with ESMTP id <S42211AbQGMPcT>;
	Thu, 13 Jul 2000 08:32:19 -0700
Received: from x0.org ([208.219.159.214])
	by  gst.gst.com (8.8.8/8.8.8) with ESMTP id LAA26141
	for <netdev@oss.sgi.com>; Thu, 13 Jul 2000 11:43:46 -0400 (EDT)
Message-ID: <396DE108.F301C5E1@x0.org>
Date:   Thu, 13 Jul 2000 11:32:24 -0400
From:   Andy <andy@x0.org>
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test3-scps i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: RARP and kernel
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

Hello!

Is there any special reason why rarp is not in linux kernel any more?
What is alternative solution?

			Andy

From owner-netdev@oss.sgi.com Thu Jul 13 08:49:17 2000
Received:  by oss.sgi.com id <S42205AbQGMPtH>;
	Thu, 13 Jul 2000 08:49:07 -0700
Received: from aarnima1-pc2.tmt.tele.fi ([194.252.70.162]:20484 "EHLO
        aarnima1-pc2.tmt.tele.fi") by oss.sgi.com with ESMTP
	id <S42185AbQGMPsv>; Thu, 13 Jul 2000 08:48:51 -0700
Received: (from localhost user: 'mea' uid#500 fake: STDIN
	(mea@aarnima1-pc2.tmt.tele.fi)) by mail.zmailer.org
	id <S378354AbQGMPsh>; Thu, 13 Jul 2000 18:48:37 +0300
Date:	Thu, 13 Jul 2000 18:48:37 +0300
From:	Matti Aarnio <matti.aarnio@sonera.fi>
To:	Andy <andy@x0.org>
Cc:	"netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: RARP and kernel
Message-ID: <20000713184837.D10825@mea-ext.zmailer.org>
References: <396DE108.F301C5E1@x0.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <396DE108.F301C5E1@x0.org>; from andy@x0.org on Thu, Jul 13, 2000 at 11:32:24AM -0400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Thu, Jul 13, 2000 at 11:32:24AM -0400, Andy wrote:
> Hello!
> 
> Is there any special reason why rarp is not in linux kernel any more?
> What is alternative solution?

	Because it is equally easily served in user-space.
	Look for  rarpd.
 
> 			Andy

From owner-netdev@oss.sgi.com Thu Jul 13 09:44:07 2000
Received:  by oss.sgi.com id <S42208AbQGMQn5>;
	Thu, 13 Jul 2000 09:43:57 -0700
Received: from gst.gst.com ([208.219.159.150]:35088 "EHLO gst.gst.com")
	by oss.sgi.com with ESMTP id <S42185AbQGMQnq>;
	Thu, 13 Jul 2000 09:43:46 -0700
Received: from x0.org ([208.219.159.214])
	by  gst.gst.com (8.8.8/8.8.8) with ESMTP id MAA04457;
	Thu, 13 Jul 2000 12:55:04 -0400 (EDT)
Message-ID: <396DF1BF.E4D4BD5A@x0.org>
Date:   Thu, 13 Jul 2000 12:43:43 -0400
From:   Andy <andy@x0.org>
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test3-scps i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     petrescu@acm.org, "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: TCP - Kernel module. Success!!
References: <396B495A.F0B2BD93@x0.org> <t4ya36m2cb.fsf@xiii.crm.mot.com>
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

> Does your tcp kernel modules work with an ipv6 kernel module ?
> I mean, what happens if I insmod ipv6 but not tcp ?
>         what happens if insmod tcp and then insmod ipv6, do I get an
>         ipv4, ipv6 stack ?


I did not do any kind of testing/developing on IPV6. Sorry.

			Andy

From owner-netdev@oss.sgi.com Thu Jul 13 14:14:38 2000
Received:  by oss.sgi.com id <S42220AbQGMVO2>;
	Thu, 13 Jul 2000 14:14:28 -0700
Received: from [200.29.52.202] ([200.29.52.202]:17318 "EHLO fwzofri.zofri.cl")
	by oss.sgi.com with ESMTP id <S42207AbQGMVOI>;
	Thu, 13 Jul 2000 14:14:08 -0700
Received: (from aaguirre@localhost)
	by fwzofri.zofri.cl (8.9.3/8.9.3) id RAA06017
	for netdev@oss.sgi.com; Thu, 13 Jul 2000 17:10:54 -0400 (CST)
From:   Armando Aguirre Schlick <aaguirre@zofri.cl>
Message-Id: <200007132110.RAA06017@fwzofri.zofri.cl>
Subject: getipnodebyname??
To:     netdev@oss.sgi.com
Date:   Thu, 13 Jul 2000 17:10:54 -0400 (CST)
In-Reply-To: <20000713213055.A4337@bacchus.dhis.org> from "Ralf Baechle" at Jul 13, 2000 09:30:55 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
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

 
 	Hi everybody..
 	Here's my question... is there some standard function like
 getipnodebyname in glibc?
 	I need to reach all of the address of a host, including IPv4-mapped
 IPv6 address...
 	Thanks in advance..


From owner-netdev@oss.sgi.com Thu Jul 13 14:22:38 2000
Received:  by oss.sgi.com id <S42207AbQGMVWS>;
	Thu, 13 Jul 2000 14:22:18 -0700
Received: from m203-1-p29.warwick.net ([208.242.203.34]:49156 "EHLO
        circuit.moureaux.com") by oss.sgi.com with ESMTP id <S42205AbQGMVWR>;
	Thu, 13 Jul 2000 14:22:17 -0700
Received: from circuit.moureaux.com (IDENT:statux@localhost [127.0.0.1])
	by circuit.moureaux.com (8.9.3/8.9.3) with SMTP id RAA01372;
	Thu, 13 Jul 2000 17:21:23 -0400
Date:   Thu, 13 Jul 2000 17:21:23 -0400 (EDT)
From:   Statux <statux@bigfoot.com>
X-Sender: statux@circuit.moureaux.com
To:     Armando Aguirre Schlick <aaguirre@zofri.cl>
cc:     netdev@oss.sgi.com
Subject: Re: getipnodebyname??
In-Reply-To: <200007132110.RAA06017@fwzofri.zofri.cl>
Message-ID: <Pine.LNX.3.96.1000713171949.1364A-100000@circuit.moureaux.com>
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

gethostbyname or gethostbyname2, perhaps?

On Thu, 13 Jul 2000, Armando Aguirre Schlick wrote:

>  
>  	Hi everybody..
>  	Here's my question... is there some standard function like
>  getipnodebyname in glibc?
>  	I need to reach all of the address of a host, including IPv4-mapped
>  IPv6 address...
>  	Thanks in advance..
> 


From owner-netdev@oss.sgi.com Thu Jul 13 14:33:08 2000
Received:  by oss.sgi.com id <S42222AbQGMVct>;
	Thu, 13 Jul 2000 14:32:49 -0700
Received: from [200.29.52.202] ([200.29.52.202]:19878 "EHLO fwzofri.zofri.cl")
	by oss.sgi.com with ESMTP id <S42205AbQGMVcV>;
	Thu, 13 Jul 2000 14:32:21 -0700
Received: (from aaguirre@localhost)
	by fwzofri.zofri.cl (8.9.3/8.9.3) id RAA06309
	for netdev@oss.sgi.com; Thu, 13 Jul 2000 17:29:26 -0400 (CST)
From:   Armando Aguirre Schlick <aaguirre@zofri.cl>
Message-Id: <200007132129.RAA06309@fwzofri.zofri.cl>
Subject: Re: getipnodebyname??
To:     netdev@oss.sgi.com
Date:   Thu, 13 Jul 2000 17:29:25 -0400 (CST)
In-Reply-To: <Pine.LNX.3.96.1000713171949.1364A-100000@circuit.moureaux.com> from "Statux" at Jul 13, 2000 05:21:23 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
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


> gethostbyname or gethostbyname2, perhaps?

	gethostbyname return everything, not including IPv4-mapped IPv6, and
gethostbyname depends on the second arg (AF_INET or AF_INET6), but twice
don't return what I'd want ( I know it).
	Does exists some _new_ RFC about it??

> On Thu, 13 Jul 2000, Armando Aguirre Schlick wrote:
> 
> >  
> >  	Hi everybody..
> >  	Here's my question... is there some standard function like
> >  getipnodebyname in glibc?
> >  	I need to reach all of the address of a host, including IPv4-mapped
> >  IPv6 address...
> >  	Thanks in advance..
> > 
> 
> 


From owner-netdev@oss.sgi.com Thu Jul 13 14:52:58 2000
Received:  by oss.sgi.com id <S42223AbQGMVws>;
	Thu, 13 Jul 2000 14:52:48 -0700
Received: from m203-1-p29.warwick.net ([208.242.203.34]:55812 "EHLO
        circuit.moureaux.com") by oss.sgi.com with ESMTP id <S42205AbQGMVwY>;
	Thu, 13 Jul 2000 14:52:24 -0700
Received: from circuit.moureaux.com (IDENT:statux@localhost [127.0.0.1])
	by circuit.moureaux.com (8.9.3/8.9.3) with SMTP id RAA06400;
	Thu, 13 Jul 2000 17:52:08 -0400
Date:   Thu, 13 Jul 2000 17:52:08 -0400 (EDT)
From:   Statux <statux@bigfoot.com>
X-Sender: statux@circuit.moureaux.com
To:     Armando Aguirre Schlick <aaguirre@zofri.cl>
cc:     netdev@oss.sgi.com
Subject: Re: getipnodebyname??
In-Reply-To: <200007132129.RAA06309@fwzofri.zofri.cl>
Message-ID: <Pine.LNX.3.96.1000713174424.4278A-100000@circuit.moureaux.com>
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

my understanding (from my Richard Stevens book) is that gethostbyname will
return ipv4 mapped ipv6 addresses by setting h_addrtype in hostent to
AF_INET6. gethostbyname doesn't have a second argument; gethostbyname2
does. if you want all the addresses of a host and you want them to be ipv4
mapped to ipv6, then you use gethostbyname.

what exact info are you looking for, though? one of those two functions
should give you all you need.

On Thu, 13 Jul 2000, Armando Aguirre Schlick wrote:

> 
> > gethostbyname or gethostbyname2, perhaps?
> 
> 	gethostbyname return everything, not including IPv4-mapped IPv6, and
> gethostbyname depends on the second arg (AF_INET or AF_INET6), but twice
> don't return what I'd want ( I know it).
> 	Does exists some _new_ RFC about it??
> 
> > On Thu, 13 Jul 2000, Armando Aguirre Schlick wrote:
> > 
> > >  
> > >  	Hi everybody..
> > >  	Here's my question... is there some standard function like
> > >  getipnodebyname in glibc?
> > >  	I need to reach all of the address of a host, including IPv4-mapped
> > >  IPv6 address...
> > >  	Thanks in advance..
> > > 
> > 
> > 
> 


From owner-netdev@oss.sgi.com Thu Jul 13 15:28:28 2000
Received:  by oss.sgi.com id <S42228AbQGMW2S>;
	Thu, 13 Jul 2000 15:28:18 -0700
Received: from [200.29.52.202] ([200.29.52.202]:28070 "EHLO fwzofri.zofri.cl")
	by oss.sgi.com with ESMTP id <S42205AbQGMW2F>;
	Thu, 13 Jul 2000 15:28:05 -0700
Received: (from aaguirre@localhost)
	by fwzofri.zofri.cl (8.9.3/8.9.3) id SAA07204
	for netdev@oss.sgi.com; Thu, 13 Jul 2000 18:25:11 -0400 (CST)
From:   Armando Aguirre Schlick <aaguirre@zofri.cl>
Message-Id: <200007132225.SAA07204@fwzofri.zofri.cl>
Subject: Re: getipnodebyname??
To:     netdev@oss.sgi.com
Date:   Thu, 13 Jul 2000 18:25:10 -0400 (CST)
In-Reply-To: <Pine.LNX.3.96.1000713174424.4278A-100000@circuit.moureaux.com> from "Statux" at Jul 13, 2000 05:52:08 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
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

> 
> my understanding (from my Richard Stevens book) is that gethostbyname will
> return ipv4 mapped ipv6 addresses by setting h_addrtype in hostent to
> AF_INET6.

	What is that book?? gethostbyname(name) don't have an arg of type
hostent. I guess that I' have to set h_addrtype at the struct returned or
I'm wrong??
	Where can I find the specifications of the function gethostbyname
(the last one). The glibc documentation isn't uptodate (glibc-2.1.x).

> gethostbyname doesn't have a second argument; gethostbyname2
> does.

	Sorry, gethostbyname2(name,af). I wrote it fast..

> if you want all the addresses of a host and you want them to be ipv4
> mapped to ipv6, then you use gethostbyname.
> 
> what exact info are you looking for, though? one of those two functions
> should give you all you need.

	Thanks so much.

From owner-netdev@oss.sgi.com Thu Jul 13 15:35:48 2000
Received:  by oss.sgi.com id <S42229AbQGMWf2>;
	Thu, 13 Jul 2000 15:35:28 -0700
Received: from m203-1-p29.warwick.net ([208.242.203.34]:62724 "EHLO
        circuit.moureaux.com") by oss.sgi.com with ESMTP id <S42205AbQGMWfL>;
	Thu, 13 Jul 2000 15:35:11 -0700
Received: from circuit.moureaux.com (IDENT:statux@localhost [127.0.0.1])
	by circuit.moureaux.com (8.9.3/8.9.3) with SMTP id SAA32058;
	Thu, 13 Jul 2000 18:34:45 -0400
Date:   Thu, 13 Jul 2000 18:34:44 -0400 (EDT)
From:   Statux <statux@bigfoot.com>
X-Sender: statux@circuit.moureaux.com
To:     Armando Aguirre Schlick <aaguirre@zofri.cl>
cc:     netdev@oss.sgi.com
Subject: Re: getipnodebyname??
In-Reply-To: <200007132225.SAA07204@fwzofri.zofri.cl>
Message-ID: <Pine.LNX.3.96.1000713183220.32052A-100000@circuit.moureaux.com>
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

err.. yeah... slight mental slip.. gethostbyname takes a char* which is
the hosname (ip or dns) and it returns a hostent. gethostbyname defaults
to ipv4, and gethostbyname2 allows you to pick. gethostbyname2 takes a
char* and an AF_INET or AF_INET6 argument... if you want ipv4 mapped to
ipv6, then use gethostbyname2 with AF_INET6.

On Thu, 13 Jul 2000, Armando Aguirre Schlick wrote:

> > 
> > my understanding (from my Richard Stevens book) is that gethostbyname will
> > return ipv4 mapped ipv6 addresses by setting h_addrtype in hostent to
> > AF_INET6.
> 
> 	What is that book?? gethostbyname(name) don't have an arg of type
> hostent. I guess that I' have to set h_addrtype at the struct returned or
> I'm wrong??
> 	Where can I find the specifications of the function gethostbyname
> (the last one). The glibc documentation isn't uptodate (glibc-2.1.x).
> 
> > gethostbyname doesn't have a second argument; gethostbyname2
> > does.
> 
> 	Sorry, gethostbyname2(name,af). I wrote it fast..
> 
> > if you want all the addresses of a host and you want them to be ipv4
> > mapped to ipv6, then you use gethostbyname.
> > 
> > what exact info are you looking for, though? one of those two functions
> > should give you all you need.
> 
> 	Thanks so much.
> 


From owner-netdev@oss.sgi.com Thu Jul 13 16:43:19 2000
Received:  by oss.sgi.com id <S42238AbQGMXm7>;
	Thu, 13 Jul 2000 16:42:59 -0700
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:17938 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S42205AbQGMXmi>; Thu, 13 Jul 2000 16:42:38 -0700
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id IAA28979;
	Fri, 14 Jul 2000 08:41:40 +0900
To:     aaguirre@zofri.cl
Cc:     netdev@oss.sgi.com
Subject: Re: getipnodebyname??
From:   Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <200007132110.RAA06017@fwzofri.zofri.cl>
References: <20000713213055.A4337@bacchus.dhis.org>
	<200007132110.RAA06017@fwzofri.zofri.cl>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000714084140G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date:   Fri, 14 Jul 2000 08:41:40 +0900
X-Dispatcher: imput version 990905(IM130)
Lines:  19
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <200007132110.RAA06017@fwzofri.zofri.cl> (at Thu, 13 Jul 2000 17:10:54 -0400 (CST)), Armando Aguirre Schlick <aaguirre@zofri.cl> says:

>  	Here's my question... is there some standard function like
>  getipnodebyname in glibc?
>  	I need to reach all of the address of a host, including IPv4-mapped
>  IPv6 address...

gethostbyname2() (or gethostbyname2_r(); maybe glibc specific).

Pelease note getipnoby{name,addr} and gethostbyname2{,_r}() are now 
deprecated; please read draft-ietf-ipng-rfc2553bis-00.txt.
According to this draft, we will be able to pass AI_V4MAPPED, AI_ALL, 
AI_ADDRCONFIG flags through getaddrinfo(). 
(I'm not sure, but maybe) I will implement this.

-- 
Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Fri Jul 14 00:21:09 2000
Received:  by oss.sgi.com id <S42217AbQGNHUu>;
	Fri, 14 Jul 2000 00:20:50 -0700
Received: from asbestos.linuxcare.com.au ([203.17.0.30]:56302 "HELO halfway")
	by oss.sgi.com with SMTP id <S42205AbQGNHUb>;
	Fri, 14 Jul 2000 00:20:31 -0700
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway (Postfix) with ESMTP
	id 13BAB8172; Fri, 14 Jul 2000 17:20:22 +1000 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     torvalds@transmeta.com
Cc:     netdev@oss.sgi.com, netfilter@lists.samba.org
Subject: [PATCH] netfilter bugfixes.
Date:   Fri, 14 Jul 2000 17:20:22 +1000
Message-Id: <20000714072023.13BAB8172@halfway>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Linus, please apply.

This patch:

	Compatibility layer ping corruption bug		(Rusty)
	Sparc alignment bugfix				(Rusty)
	REJECT fix + TCP RST re-enable			(Rusty)
	ICMP REDIRECT suppression fix			(Rusty)
	ipqueue -W bugfixes				(James Morris,
							 Andrew Morton)

This breaks source compatibility for x86 (but not binary
compatibility), and both source and binary compatibility for platforms
where it didn't work before anyway 8).

Rusty.
--- working-2.4.0-test4-3/Documentation/Changes.~1~	Wed Jul 12 17:51:59 2000
+++ working-2.4.0-test4-3/Documentation/Changes	Fri Jul 14 16:38:57 2000
@@ -317,12 +317,12 @@
 
 Netfilter
 ---------
-o  http://netfilter.filewatcher.org/iptables-1.1.0.tar.bz2
-     <http://netfilter.filewatcher.org/iptables-1.1.0.tar.bz2>
-o  http://www.samba.org/netfilter/iptables-1.1.0.tar.bz2
-     <http://www.samba.org/netfilter/iptables-1.1.0.tar.bz2>
-o  http://netfilter.kernelnotes.org/iptables-1.1.0.tar.bz2
-     <http://netfilter.kernelnotes.org/iptables-1.1.0.tar.bz2>
+o  http://netfilter.filewatcher.org/iptables-1.1.1.tar.bz2
+     <http://netfilter.filewatcher.org/iptables-1.1.1.tar.bz2>
+o  http://www.samba.org/netfilter/iptables-1.1.1.tar.bz2
+     <http://www.samba.org/netfilter/iptables-1.1.1.tar.bz2>
+o  http://netfilter.kernelnotes.org/iptables-1.1.1.tar.bz2
+     <http://netfilter.kernelnotes.org/iptables-1.1.1.tar.bz2>
 
 Ip-route2
 ---------
diff -urN -X /tmp/fileOJlBE7 --minimal linux-2.4.0-test3-2/net/ipv4/netfilter/ip_fw_compat_masq.c working-2.4.0-test3-2/net/ipv4/netfilter/ip_fw_compat_masq.c
--- linux-2.4.0-test3-2/net/ipv4/netfilter/ip_fw_compat_masq.c	Thu Jun 29 01:26:09 2000
+++ working-2.4.0-test3-2/net/ipv4/netfilter/ip_fw_compat_masq.c	Tue Jul  4 17:29:24 2000
@@ -105,7 +105,7 @@
 	/* Wouldn't be here if not tracked already => masq'ed ICMP
            ping or error related to masq'd connection */
 	IP_NF_ASSERT(ct);
-	if (CTINFO2DIR(ctinfo) == IP_CT_DIR_ORIGINAL) {
+	if (ctinfo == IP_CT_RELATED) {
 		icmp_reply_translation(skb, ct, NF_IP_PRE_ROUTING,
 				       CTINFO2DIR(ctinfo));
 		icmp_reply_translation(skb, ct, NF_IP_POST_ROUTING,
diff -urN -X /tmp/file5l4Euc --minimal linux-2.4.0-test3-2/include/linux/netfilter_ipv4/ip_tables.h working-2.4.0-test3-2/include/linux/netfilter_ipv4/ip_tables.h
--- linux-2.4.0-test3-2/include/linux/netfilter_ipv4/ip_tables.h	Thu Jul  6 13:26:32 2000
+++ working-2.4.0-test3-2/include/linux/netfilter_ipv4/ip_tables.h	Fri Jul  7 18:42:41 2000
@@ -280,7 +280,7 @@
 	unsigned int size;
 
 	/* The entries. */
-	unsigned char entries[0];
+	struct ipt_entry entrytable[0];
 };
 
 /* Standard return verdict, or do jump. */
diff -urN -X /tmp/file5l4Euc --minimal linux-2.4.0-test3-2/include/linux/netfilter_ipv6/ip6_tables.h working-2.4.0-test3-2/include/linux/netfilter_ipv6/ip6_tables.h
--- linux-2.4.0-test3-2/include/linux/netfilter_ipv6/ip6_tables.h	Thu May 25 12:41:49 2000
+++ working-2.4.0-test3-2/include/linux/netfilter_ipv6/ip6_tables.h	Fri Jul  7 19:08:16 2000
@@ -286,7 +286,7 @@
 	unsigned int size;
 
 	/* The entries. */
-	unsigned char entries[0];
+	struct ip6t_entry entrytable[0];
 };
 
 /* Standard return verdict, or do jump. */
diff -urN -X /tmp/file5l4Euc --minimal linux-2.4.0-test3-2/net/ipv4/netfilter/ip_tables.c working-2.4.0-test3-2/net/ipv4/netfilter/ip_tables.c
--- linux-2.4.0-test3-2/net/ipv4/netfilter/ip_tables.c	Thu Jun 29 01:26:09 2000
+++ working-2.4.0-test3-2/net/ipv4/netfilter/ip_tables.c	Fri Jul  7 18:43:40 2000
@@ -1029,7 +1029,7 @@
 			 t->private->number);
 		if (entries->size == t->private->size)
 			ret = copy_entries_to_user(t->private->size,
-						   t, uptr->entries);
+						   t, uptr->entrytable);
 		else {
 			duprintf("get_entries: I've got %u not %u!\n",
 				 t->private->size,
diff -urN -X /tmp/file5l4Euc --minimal linux-2.4.0-test3-2/net/ipv6/netfilter/ip6_tables.c working-2.4.0-test3-2/net/ipv6/netfilter/ip6_tables.c
--- linux-2.4.0-test3-2/net/ipv6/netfilter/ip6_tables.c	Thu Jun 29 01:26:11 2000
+++ working-2.4.0-test3-2/net/ipv6/netfilter/ip6_tables.c	Fri Jul  7 19:15:15 2000
@@ -1075,7 +1075,7 @@
 			 t->private->number);
 		if (entries->size == t->private->size)
 			ret = copy_entries_to_user(t->private->size,
-						   t, uptr->entries);
+						   t, uptr->entrytable);
 		else {
 			duprintf("get_entries: I've got %u not %u!\n",
 				 t->private->size,
diff -urN -X /tmp/fileVB9oIz --minimal tmp/include/linux/netfilter_ipv4/ipt_REJECT.h working-2.4.0-test3-9/include/linux/netfilter_ipv4/ipt_REJECT.h
--- tmp/include/linux/netfilter_ipv4/ipt_REJECT.h	Tue Mar 28 04:35:56 2000
+++ working-2.4.0-test3-9/include/linux/netfilter_ipv4/ipt_REJECT.h	Tue Jul 11 17:36:54 2000
@@ -6,7 +6,10 @@
 	IPT_ICMP_HOST_UNREACHABLE,
 	IPT_ICMP_PROT_UNREACHABLE,
 	IPT_ICMP_PORT_UNREACHABLE,
-	IPT_ICMP_ECHOREPLY
+	IPT_ICMP_ECHOREPLY,
+	IPT_ICMP_NET_PROHIBITED,
+	IPT_ICMP_HOST_PROHIBITED,
+	IPT_TCP_RESET
 };
 
 struct ipt_reject_info {
diff -urN -X /tmp/fileVB9oIz --minimal tmp/net/core/netfilter.c working-2.4.0-test3-9/net/core/netfilter.c
--- tmp/net/core/netfilter.c	Fri Apr 14 10:19:57 2000
+++ working-2.4.0-test3-9/net/core/netfilter.c	Wed Jul 12 12:18:42 2000
@@ -261,11 +261,11 @@
 		if (skb->nf_debug != ((1 << NF_IP_PRE_ROUTING)
 				      | (1 << NF_IP_FORWARD)
 				      | (1 << NF_IP_POST_ROUTING))) {
-			/* Fragments will have no owners, but still
-                           may be local */
-			if (!(skb->nh.iph->frag_off & htons(IP_MF|IP_OFFSET))
-			    || skb->nf_debug != ((1 << NF_IP_LOCAL_OUT)
-						 | (1 << NF_IP_POST_ROUTING))){
+			/* Fragments, entunnelled packets, TCP RSTs
+                           generated by ipt_REJECT will have no
+                           owners, but still may be local */
+			if (skb->nf_debug != ((1 << NF_IP_LOCAL_OUT)
+					      | (1 << NF_IP_POST_ROUTING))){
 				printk("ip_finish_output:"
 				       " bad unowned skb = %p: ",skb);
 				debug_print_hooks_ip(skb->nf_debug);
diff -urN -X /tmp/fileVB9oIz --minimal tmp/net/ipv4/netfilter/ip_conntrack_core.c working-2.4.0-test3-9/net/ipv4/netfilter/ip_conntrack_core.c
--- tmp/net/ipv4/netfilter/ip_conntrack_core.c	Tue Jul 11 12:08:17 2000
+++ working-2.4.0-test3-9/net/ipv4/netfilter/ip_conntrack_core.c	Tue Jul 11 17:12:08 2000
@@ -551,6 +551,7 @@
 resolve_normal_ct(struct sk_buff *skb,
 		  struct ip_conntrack_protocol *proto,
 		  int *set_reply,
+		  unsigned int hooknum,
 		  enum ip_conntrack_info *ctinfo)
 {
 	struct ip_conntrack_tuple tuple;
@@ -573,6 +574,21 @@
 	if (DIRECTION(h) == IP_CT_DIR_REPLY) {
 		/* Reply on unconfirmed connection => unclassifiable */
 		if (!(h->ctrack->status & IPS_CONFIRMED)) {
+			/* Exception: local TCP RSTs (generated by
+                           REJECT target). */
+			if (hooknum == NF_IP_LOCAL_OUT
+			    && h->tuple.dst.protonum == IPPROTO_TCP) {
+				const struct tcphdr *tcph
+					= (const struct tcphdr *)
+					((u_int32_t *)skb->nh.iph
+					 + skb->nh.iph->ihl);
+				if (tcph->rst) {
+					*ctinfo	= IP_CT_ESTABLISHED
+						+ IP_CT_IS_REPLY;
+					*set_reply = 0;
+					goto set_skb;
+				}
+			}
 			DEBUGP("Reply on unconfirmed connection\n");
 			ip_conntrack_put(h->ctrack);
 			return NULL;
@@ -598,6 +614,7 @@
 		}
 		*set_reply = 0;
 	}
+ set_skb:
 	skb->nfct = &h->ctrack->infos[*ctinfo];
 	return h->ctrack;
 }
@@ -669,7 +686,7 @@
 	    && icmp_error_track(*pskb, &ctinfo, hooknum))
 		return NF_ACCEPT;
 
-	if (!(ct = resolve_normal_ct(*pskb, proto, &set_reply, &ctinfo)))
+	if (!(ct = resolve_normal_ct(*pskb, proto,&set_reply,hooknum,&ctinfo)))
 		/* Not valid part of a connection */
 		return NF_ACCEPT;
 
diff -urN -X /tmp/fileVB9oIz --minimal tmp/net/ipv4/netfilter/ip_conntrack_standalone.c working-2.4.0-test3-9/net/ipv4/netfilter/ip_conntrack_standalone.c
--- tmp/net/ipv4/netfilter/ip_conntrack_standalone.c	Fri Apr 28 08:43:15 2000
+++ working-2.4.0-test3-9/net/ipv4/netfilter/ip_conntrack_standalone.c	Tue Jul 11 17:12:08 2000
@@ -169,11 +169,15 @@
 			       const struct net_device *out,
 			       int (*okfn)(struct sk_buff *))
 {
-	/* We've seen it coming out the other side: confirm */
+	/* We've seen it coming out the other side: confirm (only if
+           new packet: REJECT can generate TCP RESET response, or ICMP
+           errors) */
 	if ((*pskb)->nfct) {
 		struct ip_conntrack *ct
 			= (struct ip_conntrack *)(*pskb)->nfct->master;
-		if (!(ct->status & IPS_CONFIRMED))
+		/* ctinfo is the index of the nfct inside the conntrack */
+		if ((*pskb)->nfct - ct->infos == IP_CT_NEW
+		    && !(ct->status & IPS_CONFIRMED))
 			ip_conntrack_confirm(ct);
 	}
 	return NF_ACCEPT;
@@ -191,7 +195,8 @@
 	if ((*pskb)->nfct) {
 		struct ip_conntrack *ct
 			= (struct ip_conntrack *)(*pskb)->nfct->master;
-		if (!(ct->status & IPS_CONFIRMED))
+		if ((*pskb)->nfct - ct->infos == IP_CT_NEW
+		    && !(ct->status & IPS_CONFIRMED))
 			ip_conntrack_confirm(ct);
 	}
 
diff -urN -X /tmp/fileVB9oIz --minimal tmp/net/ipv4/netfilter/ip_fw_compat.c working-2.4.0-test3-9/net/ipv4/netfilter/ip_fw_compat.c
--- tmp/net/ipv4/netfilter/ip_fw_compat.c	Tue Jul 11 12:08:17 2000
+++ working-2.4.0-test3-9/net/ipv4/netfilter/ip_fw_compat.c	Tue Jul 11 17:12:08 2000
@@ -71,7 +71,8 @@
 		struct ip_conntrack *ct
 			= (struct ip_conntrack *)skb->nfct->master;
 
-		if (!(ct->status & IPS_CONFIRMED))
+		if (skb->nfct - ct->infos == IP_CT_NEW
+		    && !(ct->status & IPS_CONFIRMED))
 			ip_conntrack_confirm(ct);
 	}
 }
diff -urN -X /tmp/fileVB9oIz --minimal tmp/net/ipv4/netfilter/ipt_REJECT.c working-2.4.0-test3-9/net/ipv4/netfilter/ipt_REJECT.c
--- tmp/net/ipv4/netfilter/ipt_REJECT.c	Tue Jun 27 14:52:47 2000
+++ working-2.4.0-test3-9/net/ipv4/netfilter/ipt_REJECT.c	Wed Jul 12 17:46:26 2000
@@ -7,6 +7,7 @@
 #include <linux/ip.h>
 #include <net/icmp.h>
 #include <net/ip.h>
+#include <net/tcp.h>
 struct in_device;
 #include <net/route.h>
 #include <linux/netfilter_ipv4/ip_tables.h>
@@ -18,6 +19,113 @@
 #define DEBUGP(format, args...)
 #endif
 
+/* Send RST reply */
+static void send_reset(struct sk_buff *oldskb)
+{
+	struct sk_buff *nskb;
+	struct tcphdr *tcph;
+	struct rtable *rt;
+	unsigned int tcplen;
+	int needs_ack;
+
+	/* Clone skb (skb is about to be dropped, so we don't care) */
+	nskb = skb_clone(oldskb, GFP_ATOMIC);
+	if (!nskb)
+		return;
+
+	/* This packet will not be the same as the other: clear nf fields */
+	nf_conntrack_put(nskb->nfct);
+	nskb->nfct = NULL;
+	nskb->nfcache = 0;
+#ifdef CONFIG_NETFILTER_DEBUG
+	nskb->nf_debug = 0;
+#endif
+
+	/* IP header checks: fragment, too short. */
+	if (nskb->nh.iph->frag_off & htons(IP_OFFSET)
+	    || nskb->len < (nskb->nh.iph->ihl<<2) + sizeof(struct tcphdr))
+		goto free_nskb;
+
+	tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
+	tcplen = nskb->len - nskb->nh.iph->ihl*4;
+
+	/* Check checksum. */
+	if (tcp_v4_check(tcph, tcplen, nskb->nh.iph->saddr,
+			 nskb->nh.iph->daddr,
+			 csum_partial((char *)tcph, tcplen, 0)) != 0)
+		goto free_nskb;
+
+	/* No RST for RST. */
+	if (tcph->rst)
+		goto free_nskb;
+
+	nskb->nh.iph->daddr = xchg(&nskb->nh.iph->saddr, nskb->nh.iph->daddr);
+	tcph->source = xchg(&tcph->dest, tcph->source);
+
+	/* Truncate to length (no data) */
+	tcph->doff = sizeof(struct tcphdr)/4;
+	skb_trim(nskb, nskb->nh.iph->ihl*4 + sizeof(struct tcphdr));
+
+	if (tcph->ack) {
+		needs_ack = 0;
+		tcph->seq = tcph->ack_seq;
+		tcph->ack_seq = 0;
+	} else {
+		needs_ack = 1;
+		tcph->seq = 0;
+		tcph->ack_seq = htonl(ntohl(tcph->seq) + tcph->syn + tcph->fin
+				      + tcplen - (tcph->doff<<2));
+	}
+
+	/* Reset flags */
+	((u_int8_t *)tcph)[13] = 0;
+	tcph->rst = 1;
+	if (needs_ack)
+		tcph->ack = 1;
+
+	tcph->window = 0;
+	tcph->urg_ptr = 0;
+
+	/* Adjust TCP checksum */
+	tcph->check = 0;
+	tcph->check = tcp_v4_check(tcph, sizeof(struct tcphdr),
+				   nskb->nh.iph->saddr,
+				   nskb->nh.iph->daddr,
+				   csum_partial((char *)tcph,
+						sizeof(struct tcphdr), 0));
+
+	/* Adjust IP TTL, DF */
+	nskb->nh.iph->ttl = MAXTTL;
+	/* Set DF, id = 0 */
+	nskb->nh.iph->frag_off = htons(IP_DF);
+	nskb->nh.iph->id = 0;
+
+	/* Adjust IP checksum */
+	nskb->nh.iph->check = 0;
+	nskb->nh.iph->check = ip_fast_csum((unsigned char *)nskb->nh.iph, 
+					   nskb->nh.iph->ihl);
+
+	/* Routing */
+	if (ip_route_output(&rt, nskb->nh.iph->daddr, nskb->nh.iph->saddr,
+			    RT_TOS(nskb->nh.iph->tos) | RTO_CONN,
+			    0) != 0)
+		goto free_nskb;
+
+	dst_release(nskb->dst);
+	nskb->dst = &rt->u.dst;
+
+	/* "Never happens" */
+	if (nskb->len > nskb->dst->pmtu)
+		goto free_nskb;
+
+	NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, nskb, NULL, nskb->dst->dev,
+		ip_finish_output);
+	return;
+
+ free_nskb:
+	kfree_skb(nskb);
+}
+
 static unsigned int reject(struct sk_buff **pskb,
 			   unsigned int hooknum,
 			   const struct net_device *in,
@@ -43,6 +151,12 @@
     	case IPT_ICMP_PORT_UNREACHABLE:
     		icmp_send(*pskb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
     		break;
+    	case IPT_ICMP_NET_PROHIBITED:
+    		icmp_send(*pskb, ICMP_DEST_UNREACH, ICMP_NET_ANO, 0);
+    		break;
+	case IPT_ICMP_HOST_PROHIBITED:
+    		icmp_send(*pskb, ICMP_DEST_UNREACH, ICMP_HOST_ANO, 0);
+    		break;
     	case IPT_ICMP_ECHOREPLY: {
 		struct icmphdr *icmph  = (struct icmphdr *)
 			((u_int32_t *)(*pskb)->nh.iph + (*pskb)->nh.iph->ihl);
@@ -64,6 +178,9 @@
 		}
 	}
 	break;
+	case IPT_TCP_RESET:
+		send_reset(*pskb);
+		break;
 	}
 
 	return NF_DROP;
@@ -96,7 +213,7 @@
 
 	/* Only allow these for packet filtering. */
 	if (strcmp(tablename, "filter") != 0) {
-		DEBUGP("REJECT: bad table `%s'.\n", table);
+		DEBUGP("REJECT: bad table `%s'.\n", tablename);
 		return 0;
 	}
 	if ((hook_mask & ~((1 << NF_IP_LOCAL_IN)
@@ -116,6 +233,18 @@
 		/* Must contain ICMP match. */
 		if (IPT_MATCH_ITERATE(e, find_ping_match) == 0) {
 			DEBUGP("REJECT: ECHOREPLY illegal for non-ping\n");
+			return 0;
+		}
+	} else if (rejinfo->with == IPT_TCP_RESET) {
+		/* Must specify that it's a TCP packet */
+		if (e->ip.proto != IPPROTO_TCP
+		    || (e->ip.invflags & IPT_INV_PROTO)) {
+			DEBUGP("REJECT: TCP_RESET illegal for non-tcp\n");
+			return 0;
+		}
+		/* Only for local input.  Rest is too dangerous. */
+		if ((hook_mask & ~(1 << NF_IP_LOCAL_IN)) != 0) {
+			DEBUGP("REJECT: TCP_RESET only from INPUT\n");
 			return 0;
 		}
 	}
diff -urN -X /tmp/fileCRGgIa --minimal tmp/include/linux/netfilter_ipv4/ip_nat_core.h working-2.4.0-test4/include/linux/netfilter_ipv4/ip_nat_core.h
--- tmp/include/linux/netfilter_ipv4/ip_nat_core.h	Sat Apr 15 03:05:39 2000
+++ working-2.4.0-test4/include/linux/netfilter_ipv4/ip_nat_core.h	Fri Jul 14 15:12:09 2000
@@ -16,10 +16,10 @@
 
 extern struct list_head protos;
 
-extern void icmp_reply_translation(struct sk_buff *skb,
-				   struct ip_conntrack *conntrack,
-				   unsigned int hooknum,
-				   int dir);
+extern unsigned int icmp_reply_translation(struct sk_buff *skb,
+					   struct ip_conntrack *conntrack,
+					   unsigned int hooknum,
+					   int dir);
 
 extern void replace_in_hashes(struct ip_conntrack *conntrack,
 			      struct ip_nat_info *info);
diff -urN -X /tmp/fileCRGgIa --minimal tmp/net/ipv4/netfilter/ip_nat_core.c working-2.4.0-test4/net/ipv4/netfilter/ip_nat_core.c
--- tmp/net/ipv4/netfilter/ip_nat_core.c	Tue Jul 11 12:08:17 2000
+++ working-2.4.0-test4/net/ipv4/netfilter/ip_nat_core.c	Fri Jul 14 17:14:13 2000
@@ -735,7 +735,7 @@
 	} else return NF_ACCEPT;
 }
 
-void
+unsigned int
 icmp_reply_translation(struct sk_buff *skb,
 		       struct ip_conntrack *conntrack,
 		       unsigned int hooknum,
@@ -749,6 +749,22 @@
 	struct ip_nat_info *info = &conntrack->nat.info;
 
 	IP_NF_ASSERT(skb->len >= iph->ihl*4 + sizeof(struct icmphdr));
+	/* Must be RELATED */
+	IP_NF_ASSERT(skb->nfct - (struct ip_conntrack *)skb->nfct->master
+		     == IP_CT_RELATED
+		     || skb->nfct - (struct ip_conntrack *)skb->nfct->master
+		     == IP_CT_RELATED+IP_CT_IS_REPLY);
+
+	/* Redirects on non-null nats must be dropped, else they'll
+           start talking to each other without our translation, and be
+           confused... --RR */
+	if (hdr->type == ICMP_REDIRECT) {
+		/* Don't care about races here. */
+		if (info->initialized
+		    != ((1 << IP_NAT_MANIP_SRC) | (1 << IP_NAT_MANIP_DST))
+		    || info->num_manips != 0)
+			return NF_DROP;
+	}
 
 	DEBUGP("icmp_reply_translation: translating error %p hook %u dir %s\n",
 	       skb, hooknum, dir == IP_CT_DIR_ORIGINAL ? "ORIG" : "REPLY");
@@ -810,6 +826,8 @@
 	hdr->checksum = 0;
 	hdr->checksum = ip_compute_csum((unsigned char *)hdr,
 					sizeof(*hdr) + datalen);
+
+	return NF_ACCEPT;
 }
 
 int ip_nat_helper_register(struct ip_nat_helper *me)
diff -urN -X /tmp/fileCRGgIa --minimal tmp/net/ipv4/netfilter/ip_nat_standalone.c working-2.4.0-test4/net/ipv4/netfilter/ip_nat_standalone.c
--- tmp/net/ipv4/netfilter/ip_nat_standalone.c	Tue Jul 11 12:08:17 2000
+++ working-2.4.0-test4/net/ipv4/netfilter/ip_nat_standalone.c	Fri Jul 14 15:05:45 2000
@@ -84,9 +84,8 @@
 	case IP_CT_RELATED:
 	case IP_CT_RELATED+IP_CT_IS_REPLY:
 		if ((*pskb)->nh.iph->protocol == IPPROTO_ICMP) {
-			icmp_reply_translation(*pskb, ct, hooknum,
-					       CTINFO2DIR(ctinfo));
-			return NF_ACCEPT;
+			return icmp_reply_translation(*pskb, ct, hooknum,
+						      CTINFO2DIR(ctinfo));
 		}
 		/* Fall thru... (Only ICMPs can be IP_CT_IS_REPLY) */
 	case IP_CT_NEW:
diff -urN linux-2.4.0-test4-pre6/net/ipv4/netfilter/ip_queue.c linux/net/ipv4/netfilter/ip_queue.c
--- linux-2.4.0-test4-pre6/net/ipv4/netfilter/ip_queue.c	Thu Jul 13 23:31:22 2000
+++ linux/net/ipv4/netfilter/ip_queue.c	Thu Jul 13 23:35:38 2000
@@ -244,7 +244,7 @@
 {
 	ipq_queue_element_t *e;
 
-	if (v->value < 0 || v->value > NF_MAX_VERDICT)
+	if (v->value > NF_MAX_VERDICT)
 		return -EINVAL;
 	e = ipq_dequeue(q, id_cmp, v->id);
 	if (e == NULL)
@@ -309,10 +309,9 @@
 		if (e->info->indev->ifindex == ifindex)
 			return 1;
 	if (e->info->outdev)
-		if (e->info->outdev->ifindex == ifindex);
+		if (e->info->outdev->ifindex == ifindex)
 			return 1;
 	return 0;
-	
 }
 
 /* Drop any queued packets associated with device ifindex */

--
Hacking time.

From owner-netdev@oss.sgi.com Fri Jul 14 09:43:52 2000
Received:  by oss.sgi.com id <S42218AbQGNQnm>;
	Fri, 14 Jul 2000 09:43:42 -0700
Received: from [200.29.52.202] ([200.29.52.202]:46247 "EHLO fwzofri.zofri.cl")
	by oss.sgi.com with ESMTP id <S42205AbQGNQnZ>;
	Fri, 14 Jul 2000 09:43:25 -0700
Received: (from aaguirre@localhost)
	by fwzofri.zofri.cl (8.9.3/8.9.3) id MAA14594
	for netdev@oss.sgi.com; Fri, 14 Jul 2000 12:40:29 -0400 (CST)
From:   Armando Aguirre Schlick <aaguirre@zofri.cl>
Message-Id: <200007141640.MAA14594@fwzofri.zofri.cl>
Subject: inet_ntop...
To:     netdev@oss.sgi.com
Date:   Fri, 14 Jul 2000 12:40:28 -0400 (CST)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
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


   Hi, I have some trouble...
   When i want to use inet_ntop i have a dump...
   The arg is "in", an "struct in6_addr *".
   And i test it in this way:
	
	for (uint i=0; i<4; i++)
	printf("Direccion original %x.\n",in->s6_addr32[i]);
	
   The output is:
	Direccion original 0.
	Direccion original 0.
	Direccion original 0.
	Direccion original 1000000.
	
   This one is "::1", but when i execute the next line i have a 
 "segmentation fault" error...

     printf("%d.- %s (direccion almacenada).\n",i+1,
             inet_ntop(AF_INET6, in, hbuf2,
	     INET6_ADDRSTRLEN));
	     
    I defined hbuf2 as "char *" and "i" is ok.
    
    What's wrong??
    Thanks.

From owner-netdev@oss.sgi.com Fri Jul 14 10:57:42 2000
Received:  by oss.sgi.com id <S42219AbQGNR5d>;
	Fri, 14 Jul 2000 10:57:33 -0700
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:59922 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S42205AbQGNR5S>; Fri, 14 Jul 2000 10:57:18 -0700
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id CAA00363;
	Sat, 15 Jul 2000 02:56:45 +0900
To:     aaguirre@zofri.cl
Cc:     netdev@oss.sgi.com
Subject: Re: inet_ntop...
From:   Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) 
        <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <200007141640.MAA14594@fwzofri.zofri.cl>
References: <200007141640.MAA14594@fwzofri.zofri.cl>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000715025645I.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date:   Sat, 15 Jul 2000 02:56:45 +0900
X-Dispatcher: imput version 990905(IM130)
Lines:  13
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <200007141640.MAA14594@fwzofri.zofri.cl> (at Fri, 14 Jul 2000 12:40:28 -0400 (CST)), Armando Aguirre Schlick <aaguirre@zofri.cl> says:

>     I defined hbuf2 as "char *" and "i" is ok.
>     
>     What's wrong??

"OK"?  Why did you think so?
Show the definitions/declarations in AS-IS format as possible.

-- 
Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Fri Jul 14 11:40:32 2000
Received:  by oss.sgi.com id <S42224AbQGNSkW>;
	Fri, 14 Jul 2000 11:40:22 -0700
Received: from gst.gst.com ([208.219.159.150]:34825 "EHLO gst.gst.com")
	by oss.sgi.com with ESMTP id <S42205AbQGNSj7>;
	Fri, 14 Jul 2000 11:39:59 -0700
Received: from x0.org ([208.219.159.214])
	by  gst.gst.com (8.8.8/8.8.8) with ESMTP id OAA20558
	for <netdev@oss.sgi.com>; Fri, 14 Jul 2000 14:51:28 -0400 (EDT)
Message-ID: <396F5E86.6C6F1176@x0.org>
Date:   Fri, 14 Jul 2000 14:40:06 -0400
From:   Andy <andy@x0.org>
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test3-scps i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: TCP - Kernel module. Success!!
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

> I managed to convert TCP into kernel module. It works and it seems
> pretty
> stabile. The only thing that does not work is the 'Used by'. Currently
> it
> is considered unused all the time, which can result in machine crash
> when
> you try to unload the module. There are some minor uglynesses concerning
> some casting. I hope I will be able to find a better solution than to
> create a function inside TCP module that takes void* as an argument and
> performs casting inside.
> I am in the process of creating a patch.

I have a patch, but it is pretty big. 
I can send it to anyone.

		Andy

From owner-netdev@oss.sgi.com Sat Jul 15 01:49:30 2000
Received:  by oss.sgi.com id <S42244AbQGOItK>;
	Sat, 15 Jul 2000 01:49:10 -0700
Received: from tcm.hut.fi ([130.233.44.1]:23044 "EHLO tcm-gw.tcm.hut.fi")
	by oss.sgi.com with ESMTP id <S42205AbQGOIsg>;
	Sat, 15 Jul 2000 01:48:36 -0700
Received: (from smap@localhost)
	by tcm-gw.tcm.hut.fi (8.8.7/8.8.7) id QAA25093
	for <netdev@oss.sgi.com>; Tue, 11 Jul 2000 16:56:16 +0300
Received: from caffeine.tcm.hut.fi(130.233.45.27) by tcm-gw.tcm.hut.fi via smap (V2.0)
	id xma025087; Tue, 11 Jul 00 16:55:50 +0300
Received: from morphine.tcm.hut.fi (morphine.tcm.hut.fi [130.233.45.7])
	by caffeine.tcm.hut.fi (8.9.3+Sun/8.9.2) with ESMTP id QAA19097;
	Tue, 11 Jul 2000 16:55:58 +0300 (EET DST)
Received: from localhost (lpetande@localhost) by morphine.tcm.hut.fi (8.9.2/8.7.1) with ESMTP id QAA15260; Tue, 11 Jul 2000 16:55:34 +0300 (EET DST)
X-Authentication-Warning: morphine.tcm.hut.fi: lpetande owned process doing -bs
Date:   Tue, 11 Jul 2000 16:55:33 +0300 (EET DST)
From:   Lars Henrik Petander <lpetande@tcm.hut.fi>
To:     jamal <hadi@cyberus.ca>
cc:     Stefan Schlott <stefan.schlott@student.uni-ulm.de>,
        netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
In-Reply-To: <Pine.GSO.4.20.0007110721180.3334-100000@shell.cyberus.ca>
Message-ID: <Pine.SOL.4.10.10007111604480.14382-100000@morphine.tcm.hut.fi>
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 Tue, 11 Jul 2000, jamal wrote:

> 
> 
> On Tue, 11 Jul 2000, Stefan Schlott wrote:
> 
> > *sigh* which is why Lars (and me, too) had to modify the ipv6 module.
> > Passing unfragmented packets to nf6 would be really hard to implement
> > (as far as I understand the code)... but it would be really nice
> > to have an interface which can modify whole packets when sending
> > and receiving; the same thing for forwarding would result in an "always
> > defragment" option, which would be somewhat "un-ip6-ish" :-)
> 
> I might be missing something:
> 
> If you dont want to deal with fragmentation then on input use
> NF_IP6_LOCAL_IN and output NF_IP6_POST_ROUTING

NF_IP6_POST_ROUTING would not necessarily work if the packet already
contained options added by sockets and fragmentation is also done before
it. In order to add the extension headers in the correct order they need
to be inserted into the ip6_txoptions structure before the
ipv6_push_frag_opts or ipv6_push_nfrag_opts functions are called. These
functions add the options into the beginning of the skb in the correct
order.

The incoming options we handled by defining the mobile IPv6 options to 
include/linux/in6.h and adding hooks into net/ipv6/exthdr.c to handle the
options. 

Henrik

> 
> cheers,
> jamal
> 
> 
> 
> 
> 


From owner-netdev@oss.sgi.com Sat Jul 15 01:49:59 2000
Received:  by oss.sgi.com id <S42245AbQGOItk>;
	Sat, 15 Jul 2000 01:49:40 -0700
Received: from tcm.hut.fi ([130.233.44.1]:25092 "EHLO tcm-gw.tcm.hut.fi")
	by oss.sgi.com with ESMTP id <S42205AbQGOItR>;
	Sat, 15 Jul 2000 01:49:17 -0700
Received: (from smap@localhost)
	by tcm-gw.tcm.hut.fi (8.8.7/8.8.7) id JAA23175
	for <netdev@oss.sgi.com>; Tue, 11 Jul 2000 09:57:14 +0300
Received: from caffeine.tcm.hut.fi(130.233.45.27) by tcm-gw.tcm.hut.fi via smap (V2.0)
	id xma023167; Tue, 11 Jul 00 09:56:46 +0300
Received: from morphine.tcm.hut.fi (morphine.tcm.hut.fi [130.233.45.7])
	by caffeine.tcm.hut.fi (8.9.3+Sun/8.9.2) with ESMTP id JAA17115;
	Tue, 11 Jul 2000 09:56:55 +0300 (EET DST)
Received: from localhost (lpetande@localhost) by morphine.tcm.hut.fi (8.9.2/8.7.1) with ESMTP id JAA12923; Tue, 11 Jul 2000 09:56:31 +0300 (EET DST)
X-Authentication-Warning: morphine.tcm.hut.fi: lpetande owned process doing -bs
Date:   Tue, 11 Jul 2000 09:56:31 +0300 (EET DST)
From:   Lars Henrik Petander <lpetande@tcm.hut.fi>
To:     Stefan Schlott <stefan.schlott@student.uni-ulm.de>
cc:     netdev@oss.sgi.com
Subject: Re: Adding of destination options in IPv6
In-Reply-To: <20000710225047.A838@blackbird.extern.uni-ulm.de>
Message-ID: <Pine.SOL.4.10.10007110949040.12817-100000@morphine.tcm.hut.fi>
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, 10 Jul 2000, Stefan Schlott wrote:

> Hello,
> 
> > > I think that there is a need for such a mechanism. At least Mobile IPv6
> > > and probably also IPSec need to add destination options to all packets
> > > sent to certain addresses independently of the sockets. We have added
> > > hooks to our Mobile IPv6 module into ip6_output.c's ip6_xmit and
> > > ip6_build_xmit to add the options before fragmentation is done.
> > 2.4 has netfilterv6, so the right place for it is probably a netfilter
> > module.
> Please tell me that I am wrong, but afaik the netfilter hooks only return
> fragmented packets (nf6 hooks are called after fragmentation when sending,
> and before defragmentation when receiving a packet).

Yes, that's why we added our own hooks. It was easier than using the nf
hook after fragmentation and redoing the fragmentation in our own code.
For the same reason a new nf hook or some other way of adding
destination options would be nice before the fragmentation
in ip6_xmit and ip6_build_xmit.

Henrik

> 
> Stefan.
> 
> -- 
> *--- please cut here... -------------------------------------- thanks! ---*
> |-> E-Mail: stefan.schlott@student.uni-ulm.de    DH-PGP-Key: 0x2F36F4FE <-|
> | An unrecoverable error occured and windows will shut down. If the       |
> | problem persists please contact http://www.linux.org/                   |
> |   -- Seen on Slashdot (08.02.2000)                                      |
> *-------------------------------------------------------------------------*
> 


From owner-netdev@oss.sgi.com Sat Jul 15 02:52:39 2000
Received:  by oss.sgi.com id <S42247AbQGOJwU>;
	Sat, 15 Jul 2000 02:52:20 -0700
Received: from hermes.domdv.de ([193.102.202.1]:4621 "HELO zeus.domdv.de")
	by oss.sgi.com with SMTP id <S42205AbQGOJvr>;
	Sat, 15 Jul 2000 02:51:47 -0700
Received: from ast@pcast2.domdv.de by zeus.domdv.de  with smtp
	(Smail3.2.0.111 #1) id m13DOZL-006QWFC; Sat, 15 Jul 2000 11:49:11 +0200 (MEST)
Content-Length: 5157
Message-ID: <XFMail.20000715114824.ast@domdv.de>
X-Mailer: XFMail 1.4.4 on Linux
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="_=XFMail.1.4.4.Linux:20000715114602:10075=_"
Date:   Sat, 15 Jul 2000 11:48:24 +0200 (MEST)
Organization: D.O.M. Datenverarbeitung GmbH
From:   Andreas Steinmetz <ast@domdv.de>
To:     tadavis@lbl.gov, netdev@oss.sgi.com, ak@muc.de, davem@redhat.com
Subject: bonding driver + slave device (net/core) fix
Cc:     linux-net@vger.rutgers.edu, linux-kernel@vger.rutgers.edu
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This message is in MIME format
--_=XFMail.1.4.4.Linux:20000715114602:10075=_
Content-Type: text/plain; charset=us-ascii

Hi,
the following problems exist with the bonding driver (drivers/net/bonding.c) in
2.2.16 and 2.2.17-pre:

1. Missing entry in drivers/net/Space.c makes the driver inaccessible when not
   compiled as module.

2. Bug in netif_rx() in net/core/dev.c causes received packets to be lost when
   there is a backlog, this is valid not only for the bonding driver but for
   all drivers using IFF_SLAVE (the master device usually has no queue, only
   the slaves have them, due to the bug the received packed would be appended
   to the nonexisting master device queue).
   This problem will fully show up when bonding 100MBit devices, causing the
   bonded data rate to drop to 60-70Kbytes/s.

The fixes for the above problems are attached as bonding-fix.diff and are fully
tested.

3. The bonding driver will loop when packets are to be transmitted and no
   slaves are attached causing the system to freeze. This is especially bad as
   the bonding device has to be up to attach slaves, so this has a certain
   probability to occur.
   The driver has bugs in bond_close() that may hang the system (not fully
   releasing slaves, possible interrupt race problems).
   It might hang the system in bond_open().

The fixes for the bonding driver are attached as bonding-changes.diff. Please
note that they are not yet tested (not urgent for me, my servers tend to be up
all the time).

All patches are against 2.2.16.

A final word for all who want to test 100MBit channel bonding: use fast
systems! The maximum throughput with 2 bonded cards @ 100% cpu load is about
18Mbytes/s between two PIII-500 Systems (rough measurement with ftp get and
top).


--_=XFMail.1.4.4.Linux:20000715114602:10075=_
Content-Disposition: attachment; filename="bonding-changes.diff"
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
 charset=us-ascii; name=bonding-changes.diff; SizeOnDisk=1449

--- linux/drivers/net/bonding.c	Sat Jul 15 10:24:35 2000
+++ linux-custom/drivers/net/bonding.c	Sat Jul 15 10:43:44 2000
@@ -71,8 +71,12 @@
 	bonding_t *private = (struct bonding *) master->priv;
 	slave_queue_t *queue = (struct slave_queue *) private->queue;
 	slave_t *slave, *next;
+	int flags;
+
+	save_flags(flags);
+	cli();
 
-	for( slave=queue->head; slave != NULL; slave=next) {
+	for( slave=queue->head; slave != NULL; ) {
 #ifdef BONDING_DEBUG
 		printk("freeing = %s\n", slave->dev->name);
 #endif
@@ -80,9 +84,12 @@
 		slave->dev->slave = NULL;
 		next = slave->next;
 		kfree(slave);
-		queue->num_slaves++;
+		slave=next;
+		queue->num_slaves--;
 	}
 
+	restore_flags(flags);
+
 	MOD_DEC_USE_COUNT;
 	return 0;
 }
@@ -121,14 +128,15 @@
 		return -EBUSY;
 	}
 		   
-	slave->slave = master;     /* save the master in slave->slave */
-	slave->flags |= IFF_SLAVE;
-
 	if ((new_slave = kmalloc(sizeof(slave_t), GFP_KERNEL)) == NULL) {
+		restore_flags(flags);
 		return -ENOMEM;
 	}
 	memset(new_slave, 0, sizeof(slave_t));
 
+	slave->slave = master;     /* save the master in slave->slave */
+	slave->flags |= IFF_SLAVE;
+
 	new_slave->dev = slave;
 
 	if (queue->head == NULL) {
@@ -240,6 +248,11 @@
 	struct slave_queue *queue = bond->queue;
 	int good = 0;
 	
+	if(!queue->num_slaves) {
+		dev_kfree_skb(skb);
+		return 0;
+	}
+
 	while (good == 0) {
 		slave = queue->current_slave->dev;
 		if (slave->flags & (IFF_UP|IFF_RUNNING)) {

--_=XFMail.1.4.4.Linux:20000715114602:10075=_
Content-Disposition: attachment; filename="bonding-fix.diff"
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
 charset=us-ascii; name=bonding-fix.diff; SizeOnDisk=1412

diff -rNu linux/drivers/net/Space.c linux-custom/drivers/net/Space.c
--- linux/drivers/net/Space.c	Wed Jun  7 23:26:43 2000
+++ linux-custom/drivers/net/Space.c	Sat Jul 15 11:19:45 2000
@@ -106,6 +106,7 @@
 extern int ncr885e_probe(struct device *);
 extern int cs89x0_probe(struct device *dev);
 extern int ethertap_probe(struct device *dev);
+extern int bond_init(struct device *dev);
 extern int ether1_probe (struct device *dev);
 extern int ether3_probe (struct device *dev);
 extern int etherh_probe (struct device *dev);
@@ -631,6 +632,12 @@
     static struct device tap0_dev = { "tap0", 0, 0, 0, 0, NETLINK_TAPBASE, 0, 0
, 0, 0, NEXT_DEV, ethertap_probe, };
 #   undef NEXT_DEV
 #   define NEXT_DEV	(&tap0_dev)
+#endif
+
+#ifdef CONFIG_BONDING
+static struct device bonding_dev = { "bond0", 0, 0, 0, 0, 0, 0, 0, 0, 0, NEXT_D
EV, bond_init, };
+#    undef NEXT_DEV
+#    define NEXT_DEV    (&bonding_dev)
 #endif
 
 #ifdef CONFIG_LANMEDIA
diff -rNu linux/net/core/dev.c linux-custom/net/core/dev.c
--- linux/net/core/dev.c	Wed Jun  7 23:26:44 2000
+++ linux-custom/net/core/dev.c	Sat Jul 15 11:18:37 2000
@@ -773,6 +773,10 @@
 	if (backlog.qlen <= netdev_max_backlog) {
 		if (backlog.qlen) {
 			if (netdev_dropping == 0) {
+				if (skb->dev->flags & IFF_SLAVE  && 
+				    skb->dev->slave) {
+					skb->dev = skb->dev->slave;
+				}
 				skb_queue_tail(&backlog,skb);
 				mark_bh(NET_BH);
 				return;

--_=XFMail.1.4.4.Linux:20000715114602:10075=_--
End of MIME message

From owner-netdev@oss.sgi.com Mon Jul 17 12:20:12 2000
Received:  by oss.sgi.com id <S42211AbQGQTTw>;
	Mon, 17 Jul 2000 12:19:52 -0700
Received: from picard.mcnc.org ([152.45.4.100]:54277 "EHLO picard.mcnc.org")
	by oss.sgi.com with ESMTP id <S42208AbQGQTTX>;
	Mon, 17 Jul 2000 12:19:23 -0700
Received: from anr.mcnc.org (lore.mcnc.org [152.45.4.102])
	by picard.mcnc.org (8.9.3/8.9.3) with ESMTP id PAA17018
	for <netdev@oss.sgi.com>; Mon, 17 Jul 2000 15:18:50 -0400
Message-ID: <39735C1A.1DAA80EE@anr.mcnc.org>
Date:   Mon, 17 Jul 2000 15:18:50 -0400
From:   Ilia Baldine <ibaldin@anr.mcnc.org>
Organization: MCNC ANR
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
Subject: Seeing double
Content-Type: multipart/alternative;
 boundary="------------B66E50C261C6B617AEAF8545"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


--------------B66E50C261C6B617AEAF8545
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
This might sound as a silly question, but why if I ping the
local interface and use tcpdump, I see two requests
and two replies for each reported ping packet sent?
I'm running 2.2.14 patched by RedHat.
-ilia

--
-------------------------------------+----------------------
Ilia Baldine                         | ibaldin@anr.mcnc.org
Network Research Engineer,           | ph#:(919)248-1847
Advanced Networking Research, MCNC   | FAX:(919)248-1455
-------------------------------------+----------------------
"I used to think the brain was the most important part
of the body, but then I realized who was telling me that."
                        -Emo Philips
------------------------------------------------------------



--------------B66E50C261C6B617AEAF8545
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<br>This might sound as a silly question, but why if I ping the
<br>local interface and use tcpdump, I see two requests
<br>and two replies for each reported ping packet sent?
<br>I'm running 2.2.14 patched by RedHat.
<br>-ilia
<pre>--&nbsp;
-------------------------------------+----------------------
Ilia Baldine&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | ibaldin@anr.mcnc.org
Network Research Engineer,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | ph#:(919)248-1847
Advanced Networking Research, MCNC&nbsp;&nbsp; | FAX:(919)248-1455
-------------------------------------+----------------------
"I used to think the brain was the most important part&nbsp;
of the body, but then I realized who was telling me that."
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -Emo Philips
------------------------------------------------------------</pre>
&nbsp;</html>

--------------B66E50C261C6B617AEAF8545--


From owner-netdev@oss.sgi.com Tue Jul 18 02:40:16 2000
Received:  by oss.sgi.com id <S42250AbQGRJj4>;
	Tue, 18 Jul 2000 02:39:56 -0700
Received: from gate.uai.etel.ru ([195.38.57.243]:43528 "EHLO gate.uai.etel.ru")
	by oss.sgi.com with ESMTP id <S42235AbQGRJj2>;
	Tue, 18 Jul 2000 02:39:28 -0700
Received:  by sendmail (8.8.8/8.8.8) of gate.uai.etel.ru  id PAA03965
	for <netdev@oss.sgi.com>; Tue, 18 Jul 2000 15:29:13 +0600
Received: from <Zimovets@uai.etel.ru> by gate.uai.etel.ru via smap (V2.1)
	id xma003929; Tue, 18 Jul 00 15:19:02 +0600
Received:  by sendmail (8.10.1/8.10.1) with ESMTP id e6I9RP401546
	for <netdev@oss.sgi.com>; Tue, 18 Jul 2000 15:27:26 +0600
Message-ID: <39742302.583420D5@uai.etel.ru>
Date:   Tue, 18 Jul 2000 15:27:30 +0600
From:   "Maxim E. Zimovets" <Zimovets@uai.etel.ru>
Organization: UralAvaiInform
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.14-15mdk i686)
X-Accept-Language: ru, en
MIME-Version: 1.0
To:     Netdev <netdev@oss.sgi.com>
Subject: Policy based routing with fwmark clause?
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

Hi all

I've tried to make policy based routing with ip and ipchains. My config
is as follow:
Slackware Linux 7.0 with kernel v 2.2.15,
iproute2-2.2.4-now-ss000225,
ipchains v 1.3.9
Memory 64MB
NIC - rtl8139

When I try to route with following config everything is fine:
ip route add 0/0 via 1.1.1.1 table 5
ip rule add from 2.2.2.2 table 5 pref 100

ip rule show gives as expected:
0:           from all lookup local
100:      from 2.2.2.2 lookup 5
32766: from all lookup main
32737: from all lookup default
It's Ok and works fine.

When I try to setup more granular routing with ipchains:
ipchains -A input -i eth2 -p tcp -s 2.2.2.2/32 45000 -d 0/0 -m 2
ip route add 0/0 via 1.1.1.1 table 5
ip rule add fwmark 2 table 5 pref 100

I got this output  from ip rule show:
0:           from all lookup local
100:      from all lookup 5
                      ^^^^
                         ??
32766: from all lookup main
32737: from all lookup default
and Linux tried to route all the packets it got via table 5 despite of
ipchains at all.

What is wrong? Or may be what do I do wrong?
Any suggestions are welcome
Maxim
--
This mail reflects the personal opinion of the author. It can differ
from the opinion of his employer.

Maxim Zimovets
Network Administrator
Zimovets@uai.etel.ru



From owner-netdev@oss.sgi.com Tue Jul 18 03:26:26 2000
Received:  by oss.sgi.com id <S42252AbQGRK0Q>;
	Tue, 18 Jul 2000 03:26:16 -0700
Received: from mail.cyberus.ca ([209.195.95.1]:54988 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S42235AbQGRKZk>;
	Tue, 18 Jul 2000 03:25:40 -0700
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id GAA13535;
	Tue, 18 Jul 2000 06:25:17 -0400 (EDT)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id GAA17375;
	Tue, 18 Jul 2000 06:25:17 -0400 (EDT)
Date:   Tue, 18 Jul 2000 06:25:17 -0400 (EDT)
From:   jamal <hadi@cyberus.ca>
To:     "Maxim E. Zimovets" <Zimovets@uai.etel.ru>
cc:     Netdev <netdev@oss.sgi.com>
Subject: Re: Policy based routing with fwmark clause?
In-Reply-To: <39742302.583420D5@uai.etel.ru>
Message-ID: <Pine.GSO.4.20.0007180624090.17366-100000@shell.cyberus.ca>
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



Do you have "route by fwmark" compiled?

cheers,
jamal

On Tue, 18 Jul 2000, Maxim E. Zimovets wrote:

> Hi all
> 
> I've tried to make policy based routing with ip and ipchains. My config
> is as follow:
> Slackware Linux 7.0 with kernel v 2.2.15,
> iproute2-2.2.4-now-ss000225,
> ipchains v 1.3.9
> Memory 64MB
> NIC - rtl8139
> 
> When I try to route with following config everything is fine:
> ip route add 0/0 via 1.1.1.1 table 5
> ip rule add from 2.2.2.2 table 5 pref 100
> 
> ip rule show gives as expected:
> 0:           from all lookup local
> 100:      from 2.2.2.2 lookup 5
> 32766: from all lookup main
> 32737: from all lookup default
> It's Ok and works fine.
> 
> When I try to setup more granular routing with ipchains:
> ipchains -A input -i eth2 -p tcp -s 2.2.2.2/32 45000 -d 0/0 -m 2
> ip route add 0/0 via 1.1.1.1 table 5
> ip rule add fwmark 2 table 5 pref 100
> 
> I got this output  from ip rule show:
> 0:           from all lookup local
> 100:      from all lookup 5
>                       ^^^^
>                          ??
> 32766: from all lookup main
> 32737: from all lookup default
> and Linux tried to route all the packets it got via table 5 despite of
> ipchains at all.
> 
> What is wrong? Or may be what do I do wrong?
> Any suggestions are welcome
> Maxim
> --
> This mail reflects the personal opinion of the author. It can differ
> from the opinion of his employer.
> 
> Maxim Zimovets
> Network Administrator
> Zimovets@uai.etel.ru
> 
> 


From owner-netdev@oss.sgi.com Wed Jul 19 08:58:53 2000
Received:  by oss.sgi.com id <S42268AbQGSP6d>;
	Wed, 19 Jul 2000 08:58:33 -0700
Received: from smtp2.libero.it ([193.70.192.52]:7040 "EHLO smtp2.libero.it")
	by oss.sgi.com with ESMTP id <S42257AbQGSP6D>;
	Wed, 19 Jul 2000 08:58:03 -0700
Received: from trantor.ferrara.linux.it (151.20.149.100) by smtp2.libero.it; 19 Jul 2000 17:57:25 +0200
Received: by trantor.ferrara.linux.it (Postfix, from userid 501)
	id EEC514BF3D; Wed, 19 Jul 2000 17:56:09 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by trantor.ferrara.linux.it (Postfix) with ESMTP
	id E907A4BF3A; Wed, 19 Jul 2000 17:56:09 +0200 (CEST)
Date:   Wed, 19 Jul 2000 17:56:09 +0200 (CEST)
From:   Mauro Tortonesi <mauro@trantor.ferrara.linux.it>
To:     netdev@oss.sgi.com, freesoftware@itojun.org,
        chmouel@mandrakesoft.com, linux-ipv6@inner.net,
        ivano.guardini@cselt.it, consiglio@ferrara.linux.it,
        netbug@ftp.uk.linux.org, patches@tcpdump.org,
        andrea@ferrara.linux.it, pb@bieringer.de, ipv6rpm@jindai.net,
        Casper.Dik@Holland.Sun.COM, gmazzini@ing.unife.it,
        webmaster@ipv6.org, wim@bofh.st, david.madore@ens.fr,
        cmetz@inner.net
Subject: new ipv6 website
Message-ID: <Pine.LNX.4.21.0007191232360.956-100000@trantor.ferrara.linux.it>
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


i am sending this mail to you to announce the birth of Project6, a new
website which focuses on ipv6 technology from the linux point of view. 
the URL is:

http://project6.ferrara.linux.it

the main purpose of our work is to encourage and support the porting of
existing ipv4 applications to ipv6, but it is also our interest to help
the end user to become familiar with ipv6 technology. 

although our site is still in phase of development, it has already many
interesting contents. 

first of all, we provide patches that add ipv6 support to some popular
networking applications like bsd-finger, netkit-base and tcpdump (tcpdump 
already supports ipv6, but glibc lacks of some headers, so if you want
ipv6 support for linux you have to apply our patch - this problem, as the
announce of tcpdump 3.5 on freshmeat states, has already been notified to
tcpdump.org). 

moreover, in our effort to fasten the development of a fully ipv6-enabled
linux distribution, we have begun to distribute the RPMS of the basic
networking applications (netkit-base, bsd-finger, tcpdump, libpcap,
net-tools, etc..), expressly built for the linux mandrake 7.1 distribution.

you can get download patches and RPMS from our ftp site:

ftp://ftp.ferrara.linux.it/pub/project6

please, understand that we don't want to become rivals of the Linux
IPv6 RPM project (http://v6rpm.jindai.net - they're doing a great
work) or of any other ipv6-related organization, but we are interested in
developing RPMS for our own use and so we have resolved to distribute them
in the hope that they may be useful to someone else.

here we come to the most interesting part. we are still a small team and
we are looking for contributors (testers, article writers and developers). 
if you are interested in helping us, please send me a mail or visit our
website. you will find informations on how to contact us.

thank you for your patience, i hope not to have bothered you too much ;-)

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			mauro@ferrara.linux.it
Ferrara Linux User Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it





From owner-netdev@oss.sgi.com Wed Jul 19 12:24:43 2000
Received:  by oss.sgi.com id <S42274AbQGSTYd>;
	Wed, 19 Jul 2000 12:24:33 -0700
Received: from fep4-orange.clear.net.nz ([203.97.32.4]:64761 "EHLO
        fep4-orange.clear.net.nz") by oss.sgi.com with ESMTP
	id <S42257AbQGSTX6>; Wed, 19 Jul 2000 12:23:58 -0700
Received: from metastasis.f00f.org (a203-167-249-89.reverse.clear.net.nz [203.167.249.89]) by fep4-orange.clear.net.nz (1.5/1.7) with ESMTP id HAA17951; Thu, 20 Jul 2000 07:23:31 +1200 (NZST)
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id 8A8539E1F; Thu, 20 Jul 2000 07:23:28 +1200 (NZST)
Date:   Thu, 20 Jul 2000 07:23:28 +1200
From:   Chris Wedgwood <cw@f00f.org>
To:     Ilia Baldine <ibaldin@picard.mcnc.org>
Cc:     netdev@oss.sgi.com
Subject: Re: Seeing double
Message-ID: <20000720072328.C846@metastasis.f00f.org>
References: <39735C1A.1DAA80EE@anr.mcnc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <39735C1A.1DAA80EE@anr.mcnc.org>; from ibaldin@picard.mcnc.org on Mon, Jul 17, 2000 at 03:18:50PM -0400
X-No-Archive: Yes
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

    This might sound as a silly question, but why if I ping the
    local interface and use tcpdump, I see two requests
    and two replies for each reported ping packet sent?

One sent to the device, the other received by the device.


   --cw

From owner-netdev@oss.sgi.com Fri Jul 21 15:26:34 2000
Received:  by oss.sgi.com id <S42233AbQGUW0Y>;
	Fri, 21 Jul 2000 15:26:24 -0700
Received: from Altitude.CAM.ORG ([198.168.100.1]:52214 "EHLO Altitude.CAM.ORG")
	by oss.sgi.com with ESMTP id <S42229AbQGUWZt>;
	Fri, 21 Jul 2000 15:25:49 -0700
Received: (from uucp@localhost)
	by Altitude.CAM.ORG (8.9.3/8.9.3) with UUCP id SAA28899
	for netdev@oss.sgi.com; Fri, 21 Jul 2000 18:30:52 -0400 (EDT)
Received: (from hendrik@localhost)
	by topoi.cam.org (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id RAA11115;
	Fri, 21 Jul 2000 17:45:13 -0400
From:   Hendrik Boom <hendrik@topoi.cam.org>
Message-Id: <200007212145.RAA11115@topoi.cam.org>
Subject: Linux heartbeat
To:     netdev@oss.sgi.com
Date:   Fri, 21 Jul 2000 17:45:13 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
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

A friend of mine is having a problem with a high-data-rate
application which appears to involve developing some new protocols.
He's preparing a letter with the details.  He tells me the Linux
scheduler uses a 100-Hz clock, and that isn't fast enough for him.
By the time the scheduler gets around to the next tick and reconsiders
whether to execute his process, his 15-meg rotating buffer has overflowed.

He believes that the proper fix would be for the Linux timer code to be
rewritten to operate at higher resolution.  He is facing the prospect
of switching to another OS.

As I said, he's preparing a letter with the details.  Is this an appropriate
forum to present it? Or should I send it elsewhere (if so, where?).

-- hendrik@topoi.cam.org

From owner-netdev@oss.sgi.com Fri Jul 21 16:41:36 2000
Received:  by oss.sgi.com id <S42234AbQGUXl0>;
	Fri, 21 Jul 2000 16:41:26 -0700
Received: from [203.126.247.144] ([203.126.247.144]:14004 "EHLO zsngs001")
	by oss.sgi.com with ESMTP id <S42229AbQGUXk4>;
	Fri, 21 Jul 2000 16:40:56 -0700
Received: from zsngd101.asiapac.nortel.com (actually znsgd101) by zsngs001;
          Sat, 22 Jul 2000 07:36:53 +0800
Received: from zctwb003.asiapac.nortel.com ([47.152.32.111]) 
          by zsngd101.asiapac.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id 3KQPQQ1C; Sat, 22 Jul 2000 07:37:05 +0800
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.2652.39) 
          id PJ5SCTTK; Sat, 22 Jul 2000 09:37:08 +1000
Received: from uow.edu.au ([47.221.35.254]) 
          by pwold011.asiapac.nortel.com (8.9.3/8.9.3) with ESMTP id JAA32617;
          Sat, 22 Jul 2000 09:37:24 +1000
Message-ID: <3978DDD5.C55DD07D@uow.edu.au>
Date:   Sat, 22 Jul 2000 09:33:41 +1000
X-Sybari-Space: 00000000 00000000 00000000
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To:     Hendrik Boom <hendrik@topoi.cam.org>
CC:     netdev@oss.sgi.com
Subject: Re: Linux heartbeat
References: <200007212145.RAA11115@topoi.cam.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <andrewm@uow.edu.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Run that by me again?  15 megs in 10 millisecs is 1.5 gigabytes per
second.

What is his actual data rate?  It must be enormous.

I suspect that what he is encountering is scheduling stalls which are
much greater than 10 millisecs.  If a process does something like a huge
read() or /bin/sync then all other processes don't get scheduled for up
to 150 millisecs in my experience.

Before your colleague does anything else he should read the linux-kernel
archives for the past 4 weeks.  Search for 'low latency'.  Once he has
absorbed that little bunfight he will be better armed.

He has a requirement for hard realtime.  He has several options:

1: Use a realtime OS

2: Use RTLinux (A realtime OS)

3: Use kernel 2.2 with Ingo Molnar's low-latency patches.  This will
give him approx 2 millisec max latency.

4: Use kernel 2.4 with my low-latency patch.  This is a much simpler
patch and is probably not as reliable as Ingo's.

5: Do it in the kernel and do the realtime stuff at interrupt time.

If he goes with a low-latency Linux patch then his process will need to
give itself SCHED_FIFO scheduling policy, it should use mlockall() to
prevent itself getting paged out and it will require some cooperation
from a device driver which will cause the process to become runnable
promptly.

Whichever way, I believe it would be useful for him to send a
description of his requirements to linux-kernel@vger.rutgers.edu.  But
make sure that he has read the archives beforehand.



Hendrik Boom wrote:
> 
> A friend of mine is having a problem with a high-data-rate
> application which appears to involve developing some new protocols.
> He's preparing a letter with the details.  He tells me the Linux
> scheduler uses a 100-Hz clock, and that isn't fast enough for him.
> By the time the scheduler gets around to the next tick and reconsiders
> whether to execute his process, his 15-meg rotating buffer has overflowed.
> 
> He believes that the proper fix would be for the Linux timer code to be
> rewritten to operate at higher resolution.  He is facing the prospect
> of switching to another OS.
> 
> As I said, he's preparing a letter with the details.  Is this an appropriate
> forum to present it? Or should I send it elsewhere (if so, where?).
> 
> -- hendrik@topoi.cam.org

From owner-netdev@oss.sgi.com Sat Jul 22 05:12:03 2000
Received:  by oss.sgi.com id <S42210AbQGVMLn>;
	Sat, 22 Jul 2000 05:11:43 -0700
Received: from Altitude.CAM.ORG ([198.168.100.1]:31741 "EHLO Altitude.CAM.ORG")
	by oss.sgi.com with ESMTP id <S42207AbQGVMLK>;
	Sat, 22 Jul 2000 05:11:10 -0700
Received: (from uucp@localhost)
	by Altitude.CAM.ORG (8.9.3/8.9.3) with UUCP id IAA03351;
	Sat, 22 Jul 2000 08:15:58 -0400 (EDT)
Received: (from hendrik@localhost)
	by topoi.cam.org (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id XAA11784;
	Fri, 21 Jul 2000 23:43:34 -0400
From:   Hendrik Boom <hendrik@topoi.cam.org>
Message-Id: <200007220343.XAA11784@topoi.cam.org>
Subject: Re: Linux heartbeat
In-Reply-To: <3978DDD5.C55DD07D@uow.edu.au> from Andrew Morton at "Jul 22, 2000
 09:33:41 am"
To:     Andrew Morton <andrewm@uow.edu.au>
Date:   Fri, 21 Jul 2000 23:43:22 -0400 (EDT)
CC:     netdev@oss.sgi.com
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
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

> Run that by me again?  15 megs in 10 millisecs is 1.5 gigabytes per
> second.
> 
> What is his actual data rate?  It must be enormous.

Sorry. My mistake. Out by two orders of magnitude.

The actual data rate will be about 15 megabytes per second.

> 
> I suspect that what he is encountering is scheduling stalls which are
> much greater than 10 millisecs.  If a process does something like a huge
> read() or /bin/sync then all other processes don't get scheduled for up
> to 150 millisecs in my experience.
> 
> Before your colleague does anything else he should read the linux-kernel
> archives for the past 4 weeks.  Search for 'low latency'.  Once he has
> absorbed that little bunfight he will be better armed.
> 

This does explain some of the problems he has been having.  I've forwarded
your message;  he will look into things further.

-- hendrik.

> He has a requirement for hard realtime.  He has several options:
> 
> 1: Use a realtime OS
> 
> 2: Use RTLinux (A realtime OS)
> 
> 3: Use kernel 2.2 with Ingo Molnar's low-latency patches.  This will
> give him approx 2 millisec max latency.
> 
> 4: Use kernel 2.4 with my low-latency patch.  This is a much simpler
> patch and is probably not as reliable as Ingo's.
> 
> 5: Do it in the kernel and do the realtime stuff at interrupt time.
> 
> If he goes with a low-latency Linux patch then his process will need to
> give itself SCHED_FIFO scheduling policy, it should use mlockall() to
> prevent itself getting paged out and it will require some cooperation
> from a device driver which will cause the process to become runnable
> promptly.
> 
> Whichever way, I believe it would be useful for him to send a
> description of his requirements to linux-kernel@vger.rutgers.edu.  But
> make sure that he has read the archives beforehand.
> 
> 
> 
> Hendrik Boom wrote:
> > 
> > A friend of mine is having a problem with a high-data-rate
> > application which appears to involve developing some new protocols.
> > He's preparing a letter with the details.  He tells me the Linux
> > scheduler uses a 100-Hz clock, and that isn't fast enough for him.
> > By the time the scheduler gets around to the next tick and reconsiders
> > whether to execute his process, his 15-meg rotating buffer has overflowed.
> > 
> > He believes that the proper fix would be for the Linux timer code to be
> > rewritten to operate at higher resolution.  He is facing the prospect
> > of switching to another OS.
> > 
> > As I said, he's preparing a letter with the details.  Is this an appropriate
> > forum to present it? Or should I send it elsewhere (if so, where?).
> > 
> > -- hendrik@topoi.cam.org
> 


From owner-netdev@oss.sgi.com Sat Jul 22 11:42:55 2000
Received:  by oss.sgi.com id <S42217AbQGVSmf>;
	Sat, 22 Jul 2000 11:42:35 -0700
Received: from colin.muc.de ([193.149.48.1]:49675 "HELO colin.muc.de")
	by oss.sgi.com with SMTP id <S42207AbQGVSmL>;
	Sat, 22 Jul 2000 11:42:11 -0700
Received: by colin.muc.de id <140596-3>; Sat, 22 Jul 2000 20:41:30 +0200
Message-ID: <20000722204128.33863@colin.muc.de>
From:   Andi Kleen <ak@muc.de>
To:     Hendrik Boom <hendrik@topoi.cam.org>
Cc:     netdev@oss.sgi.com
Subject: Re: Linux heartbeat
References: <200007212145.RAA11115@topoi.cam.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.88e
In-Reply-To: <200007212145.RAA11115@topoi.cam.org>; from Hendrik Boom on Sat, Jul 22, 2000 at 12:30:12AM +0200
Date:   Sat, 22 Jul 2000 20:41:29 +0200
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sat, Jul 22, 2000 at 12:30:12AM +0200, Hendrik Boom wrote:
> He believes that the proper fix would be for the Linux timer code to be
> rewritten to operate at higher resolution.  He is facing the prospect
> of switching to another OS.
> 
It doesn't need to be rewriten, just be recompiled with a higher HZ constant.

> As I said, he's preparing a letter with the details.  Is this an appropriate
> forum to present it? Or should I send it elsewhere (if so, where?).

netdev is about networking, not scheduling. Better send it to link-kernel


-Andi

From owner-netdev@oss.sgi.com Sat Jul 22 14:28:55 2000
Received:  by oss.sgi.com id <S42218AbQGVV2f>;
	Sat, 22 Jul 2000 14:28:35 -0700
Received: from fep4-orange.clear.net.nz ([203.97.32.4]:5367 "EHLO
        fep4-orange.clear.net.nz") by oss.sgi.com with ESMTP
	id <S42207AbQGVV2E>; Sat, 22 Jul 2000 14:28:04 -0700
Received: from metastasis.f00f.org (a203-167-249-89.reverse.clear.net.nz [203.167.249.89]) by fep4-orange.clear.net.nz (1.5/1.7) with ESMTP id JAA01771; Sun, 23 Jul 2000 09:27:34 +1200 (NZST)
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id 9B8979E2D; Sun, 23 Jul 2000 09:27:31 +1200 (NZST)
Date:   Sun, 23 Jul 2000 09:27:31 +1200
From:   Chris Wedgwood <cw@f00f.org>
To:     Andy <andy@x0.org>
Cc:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
Subject: Re: TCP - Kernel module. Success!!
Message-ID: <20000723092731.A27374@metastasis.f00f.org>
References: <396F5E86.6C6F1176@x0.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <396F5E86.6C6F1176@x0.org>; from andy@x0.org on Fri, Jul 14, 2000 at 02:40:06PM -0400
X-No-Archive: Yes
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

    I have a patch, but it is pretty big. 

If it's only 20k or so then I don't see why netdev will mind.
 
    I can send it to anyone.

I'm interested. I made ipv4 patches for 2.1.x and also 2.3.x, but
when the module unloaded, if that had been any ipv4 tcp streams
previously active (usage counters prevented removal when streams were
active or in time-wait), things would oops horribly.

I never did find out why.


  --cw


From owner-netdev@oss.sgi.com Mon Jul 24 07:41:49 2000
Received:  by oss.sgi.com id <S42243AbQGXOl3>;
	Mon, 24 Jul 2000 07:41:29 -0700
Received: from d12lmsgate-3.de.ibm.com ([195.212.91.201]:12012 "EHLO
        d12lmsgate-3.de.ibm.com") by oss.sgi.com with ESMTP
	id <S42229AbQGXOkw>; Mon, 24 Jul 2000 07:40:52 -0700
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id QAA161916
	for <netdev@oss.sgi.com>; Mon, 24 Jul 2000 16:40:20 +0200
From:   DJBARROW@de.ibm.com
Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1])
	by d12relay02.de.ibm.com (8.8.8m3/NCO v4.92) with SMTP id QAA257774
	for <netdev@oss.sgi.com>; Mon, 24 Jul 2000 16:40:14 +0200
Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id C1256926.004E9F34 ; Mon, 24 Jul 2000 16:18:45 +0200
X-Lotus-FromDomain: IBMDE
To:     netdev@oss.sgi.com
cc:     utz.bacher@de.ibm.com, schwidefsky@de.ibm.com
Message-ID: <C1256926.004E9D24.00@d12mta09.de.ibm.com>
Date:   Mon, 24 Jul 2000 16:18:37 +0200
Subject: zero copy skbuff.c enhancments
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=ourZSmsmTWZkD5Y6mbH1UZxqGrv7GCc25R9FwQEjm1C19YLKinxWknUb"
Content-Disposition: inline
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

--0__=ourZSmsmTWZkD5Y6mbH1UZxqGrv7GCc25R9FwQEjm1C19YLKinxWknUb
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable




Hi,

I've written a patch for skbuff.c & skbuff.h which allows zero-copying =
of
incoming network frames
from network device drivers by using these new apis.


void init_zero_copy_buffer(zero_copy_header *header,zerocopy_freefunc
freefunc,int order)

init_zero_copy_skb should be called prior to calling make_zero_copy_skb=

 it's purpose is to initialise the refcnt, the header has to be
 at the start of the buffer.
 The freefunc is typically kfree & is used to free the buffer up.

struct sk_buff *make_zero_copy_skb(unsigned int size,int gfp_mask,
                        unsigned char *data,zero_copy_header *zc_header=
)
make_zero_copy_skb was added so network device drivers could take do
 give the network layer data received without memcpying it,
 zero_copy_header is used so that drivers can point the refcnt (
skb_datarefp ) to
 the head of our allocated buffer rather than the end of the data as us=
ed
by alloc_skb
 ( this would have upset the possibility of being able to use zero copy=
 as
we would
  be corrupting the incoming data).
 It is the intention that a single refcnt could be used for multiple
zero_copied skbs
 which may come from a single larger driver buffer.
 The typical usage scenario for this function is as follows
 1) receive packet
 2) kmalloc new io buffer for io program to replace buffer that just ca=
me
in
 if this succeeds  init_zero_copy_buffer the new buffer & make_zero_cop=
y
skb
 the newly received buffer.
 3) call netif_rx with the new buffer.
 We cant use a static list of circular list of buffers for the io progr=
am
 & a destructor type concept to free give the buffer back to the driver=
 for
2 reasons.
 1) if someone suspends an ftp transfer or similar with ctrl-z
 the received buffer will stay in the network stack & not be given
 back to the driver until the ftp transfer is unsuspended & thus lockin=
g
 the driver during this time.
 2) if skb->destructor is called when driver is unloaded we would crash=

 as the function no longer exists, the quantity of code required
 to work around this would be 300 or 400 lines as we would have to
 pull all the drivers skbuffs from the stack when unregistering the
 driver & some of the network code could understandably get upset if we=
 did
 this.
For this reason we have kfree_skb_buffer freeing a user specified buffe=
r.


Alan Cox has expressed some intrest in the patches ( in the concept any=
way
) & recommended that I post them to you,
 I've been using them for a while in  my own driver in 2.2.16 & 2.3.99 =
they
 seem relatively stable
under these circumstances anyway. The only case I can think of where th=
ey
may not work
is drivers depending on the 16 byte skb_reserve kludge in dev_alloc_skb=
.

Also a colleague of mine Utz Bacher is coding his gigabit ethernet driv=
er
against these API's.

The patch is against 2.4.0test4 which I have tested & it does run on in=
tel.

Try out the API's if you can find an eligible driver to do so & let me
know.

Hopefully the patch will apply cleanly for you.


Thanks
(See attached file: zero_copy_skb220700.patch)
D.J. Barrow Linux for S/390 kernel developer
eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Sch=F6naicherstr. 220, 71032 B=F6blingen
=

--0__=ourZSmsmTWZkD5Y6mbH1UZxqGrv7GCc25R9FwQEjm1C19YLKinxWknUb
Content-type: application/octet-stream; 
	name="zero_copy_skb220700.patch"
Content-Disposition: attachment; filename="zero_copy_skb220700.patch"
Content-transfer-encoding: base64

ZGlmZiAtdSAtciBsaW51eC5vcmlnL2luY2x1ZGUvbGludXgvc2tidWZmLmggbGludXgubmV3L2lu
Y2x1ZGUvbGludXgvc2tidWZmLmgKLS0tIGxpbnV4Lm9yaWcvaW5jbHVkZS9saW51eC9za2J1ZmYu
aAlUaHUgSnVsIDEzIDA3OjAyOjAyIDIwMDAKKysrIGxpbnV4Lm5ldy9pbmNsdWRlL2xpbnV4L3Nr
YnVmZi5oCU1vbiBKdWwgMjQgMjE6Mjg6MzggMjAwMApAQCAtNDgsNiArNDgsMTcgQEAKIH07CiAj
ZW5kaWYKIAorCisjZGVmaW5lIFpFUk9DT1BZX01BR0lDIDB4MzQ1Njk4NzYKK3R5cGVkZWYgdm9p
ZCAoKnplcm9jb3B5X2ZyZWVmdW5jKShjb25zdCB2b2lkICopOwordHlwZWRlZiBzdHJ1Y3Qgewor
CV9fdTMyICAgICAgICAgICAgIG1hZ2ljOworCWF0b21pY190ICAgICAgICAgIHJlZmNudDsKKwl6
ZXJvY29weV9mcmVlZnVuYyBmcmVlZnVuYzsKKwlpbnQgICAgICAgICAgICAgICBvcmRlcjsgLyog
dXNlZCBmb3IgZnJlZV9wYWdlcyAqLworfSB6ZXJvX2NvcHlfaGVhZGVyOworCisKIHN0cnVjdCBz
a19idWZmX2hlYWQgewogCS8qIFRoZXNlIHR3byBtZW1iZXJzIG11c3QgYmUgZmlyc3QuICovCiAJ
c3RydWN0IHNrX2J1ZmYJKiBuZXh0OwpAQCAtMTI0LDYgKzEzNSw3IEBACiAJdW5zaWduZWQgY2hh
cgkqZGF0YTsJCQkvKiBEYXRhIGhlYWQgcG9pbnRlcgkJCQkqLwogCXVuc2lnbmVkIGNoYXIJKnRh
aWw7CQkJLyogVGFpbCBwb2ludGVyCQkJCQkqLwogCXVuc2lnbmVkIGNoYXIgCSplbmQ7CQkJLyog
RW5kIHBvaW50ZXIJCQkJCSovCisJYXRvbWljX3QgICAgICAgICpyZWZjbnRfcHRyOyAgICAgICAg
ICAgIC8qIFBvaW50ZXIgdG8gcmVmY250IGFyZWEgICAgICAgICAgICAgICAgICAgICAgICovCiAJ
dm9pZCAJCSgqZGVzdHJ1Y3Rvcikoc3RydWN0IHNrX2J1ZmYgKik7CS8qIERlc3RydWN0IGZ1bmN0
aW9uCQkqLwogI2lmZGVmIENPTkZJR19ORVRGSUxURVIKIAkvKiBDYW4gYmUgdXNlZCBmb3IgY29t
bXVuaWNhdGlvbiBiZXR3ZWVuIGhvb2tzLiAqLwpAQCAtMTYxLDYgKzE3MywxMiBAQAogCiBleHRl
cm4gdm9pZAkJCV9fa2ZyZWVfc2tiKHN0cnVjdCBza19idWZmICpza2IpOwogZXh0ZXJuIHN0cnVj
dCBza19idWZmICoJCXNrYl9wZWVrX2NvcHkoc3RydWN0IHNrX2J1ZmZfaGVhZCAqbGlzdCk7Citl
eHRlcm4gdm9pZCAgICAgICAgICAgICAgICAgICAgIHNrYl9mcmVlX3BhZ2VzKHVuc2lnbmVkIGxv
bmcgcGFnZSwgdW5zaWduZWQgbG9uZyBvcmRlcik7Cit2b2lkICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGluaXRfemVyb19jb3B5X2J1ZmZlcih6ZXJvX2NvcHlfaGVhZGVyICpoZWFkZXIsCisJ
CQkJCQkgICAgICB6ZXJvY29weV9mcmVlZnVuYyBmcmVlZnVuYyxpbnQgb3JkZXIpOworc3RydWN0
IHNrX2J1ZmYgICAgICAgICAgICAgICAgICAqbWFrZV96ZXJvX2NvcHlfc2tiKHVuc2lnbmVkIGlu
dCBzaXplLGludCBnZnBfbWFzaywKKwkJCQl1bnNpZ25lZCBjaGFyICpkYXRhLHplcm9fY29weV9o
ZWFkZXIgKmhlYWRlcik7CitleHRlcm4gdm9pZCAgICAgICAgICAgICAgICAgICAgIGtmcmVlX3Nr
Yl9idWZmZXIoc3RydWN0IHNrX2J1ZmYgKnNrYik7CiBleHRlcm4gc3RydWN0IHNrX2J1ZmYgKgkJ
YWxsb2Nfc2tiKHVuc2lnbmVkIGludCBzaXplLCBpbnQgcHJpb3JpdHkpOwogZXh0ZXJuIHZvaWQJ
CQlrZnJlZV9za2JtZW0oc3RydWN0IHNrX2J1ZmYgKnNrYik7CiBleHRlcm4gc3RydWN0IHNrX2J1
ZmYgKgkJc2tiX2Nsb25lKHN0cnVjdCBza19idWZmICpza2IsIGludCBwcmlvcml0eSk7CkBAIC0x
NzksNyArMTk3LDcgQEAKIC8qIEludGVybmFsICovCiBzdGF0aWMgaW5saW5lIGF0b21pY190ICpz
a2JfZGF0YXJlZnAoc3RydWN0IHNrX2J1ZmYgKnNrYikKIHsKLQlyZXR1cm4gKGF0b21pY190ICop
KHNrYi0+ZW5kKTsKKwlyZXR1cm4gc2tiLT5yZWZjbnRfcHRyOwogfQogCiAvKioKZGlmZiAtdSAt
ciBsaW51eC5vcmlnL25ldC9jb3JlL3NrYnVmZi5jIGxpbnV4Lm5ldy9uZXQvY29yZS9za2J1ZmYu
YwotLS0gbGludXgub3JpZy9uZXQvY29yZS9za2J1ZmYuYwlNb24gTWF5IDIyIDE4OjUwOjU1IDIw
MDAKKysrIGxpbnV4Lm5ldy9uZXQvY29yZS9za2J1ZmYuYwlNb24gSnVsIDI0IDIxOjI5OjI3IDIw
MDAKQEAgLTE5LDYgKzE5LDggQEAKICAqCQlSYXkgVmFuVGFzc2xlCToJRml4ZWQgLS1za2ItPmxv
Y2sgaW4gZnJlZQogICoJCUFsYW4gQ294CToJc2tiX2NvcHkgY29weSBhcnAgZmllbGQKICAqCQlB
bmRpIEtsZWVuCToJc2xhYmlmaWVkIGl0LgorICogICAgICAgICAgICAgIEQuSi4gQmFycm93ICAg
ICA6ICAgICAgIEFkZGVkIG1ha2VfemVyb19jb3B5X3NrYiBhcyAKKyAqICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBwcm9wb3NlZCBieSBVdHogQmFjaGVyLgogICoKICAqCU5P
VEU6CiAgKgkJVGhlIF9fc2tiXyByb3V0aW5lcyBzaG91bGQgYmUgY2FsbGVkIHdpdGggaW50ZXJy
dXB0cyAKQEAgLTYzLDYgKzY1LDcgQEAKICNpbmNsdWRlIDxhc20vc3lzdGVtLmg+CiAKIGludCBz
eXNjdGxfaG90X2xpc3RfbGVuID0gMTI4Oworc3RhdGljIGF0b21pY190IG5ldF96ZXJvY29weV9i
dWZmZXJzICA9IEFUT01JQ19JTklUKDApOwogCiBzdGF0aWMga21lbV9jYWNoZV90ICpza2J1ZmZf
aGVhZF9jYWNoZTsKIApAQCAtMTQyLDYgKzE0NSwxMDEgQEAKIAlrbWVtX2NhY2hlX2ZyZWUoc2ti
dWZmX2hlYWRfY2FjaGUsIHNrYik7CiB9CiAKKy8qCisgKiBpbml0X3plcm9fY29weV9idWZmZXIg
c2hvdWxkIGJlIGNhbGxlZCBwcmlvciB0byBjYWxsaW5nIG1ha2VfemVyb19jb3B5X3NrYgorICog
aXQncyBwdXJwb3NlIGlzIHRvIGluaXRpYWxpc2UgdGhlIHJlZmNudCwgdGhlIGhlYWRlciBoYXMg
dG8gYmUKKyAqIGF0IHRoZSBzdGFydCBvZiB0aGUgYnVmZmVyLgorICogVGhlIGZyZWVmdW5jIGlz
IHR5cGljYWxseSBrZnJlZSAmIGlzIHVzZWQgdG8gZnJlZSB0aGUgYnVmZmVyIHVwLgorICovCit2
b2lkIGluaXRfemVyb19jb3B5X2J1ZmZlcih6ZXJvX2NvcHlfaGVhZGVyICpoZWFkZXIsemVyb2Nv
cHlfZnJlZWZ1bmMgZnJlZWZ1bmMsaW50IG9yZGVyKQoreworCXN0YXRpYyBpbnQgbWVzc2FnZV9w
cmludGVkPTA7CisJaW50ICAgIGJ1ZmZjbnQ7CisJaGVhZGVyLT5tYWdpYz1aRVJPQ09QWV9NQUdJ
QzsKKwlhdG9taWNfc2V0KCZoZWFkZXItPnJlZmNudCwwKTsKKwloZWFkZXItPmZyZWVmdW5jPWZy
ZWVmdW5jOworCWhlYWRlci0+b3JkZXI9b3JkZXI7CisJYXRvbWljX2luYygmbmV0X3plcm9jb3B5
X2J1ZmZlcnMpOworCWJ1ZmZjbnQ9YXRvbWljX3JlYWQoJm5ldF96ZXJvY29weV9idWZmZXJzKTsK
KwlpZigoYnVmZmNudD4xMDAwfHxidWZmY250PDApJiYhbWVzc2FnZV9wcmludGVkKQorCXsKKwkJ
cHJpbnRrKCJidWZmZXIgbWFuYWdtZW50IHByb2JsZW0gaW5pdF96ZXJvX2NvcHlfYnVmZmVyIGNv
dW50cyAlZCB6ZXJvIGNvcHkgYnVmZmVyc1xuIixidWZmY250KTsKKwkJbWVzc2FnZV9wcmludGVk
PTE7CisJfQorCQkKK30KKy8qCisgKiBtYWtlX3plcm9fY29weV9za2Igd2FzIGFkZGVkIHNvIG5l
dHdvcmsgZGV2aWNlIGRyaXZlcnMgY291bGQgdGFrZSBkbworICogZ2l2ZSB0aGUgbmV0d29yayBs
YXllciBkYXRhIHJlY2VpdmVkIHdpdGhvdXQgbWVtY3B5aW5nIGl0LAorICogemVyb19jb3B5X2hl
YWRlciBpcyB1c2VkIHNvIHRoYXQgZHJpdmVycyBjYW4gcG9pbnQgdGhlIHJlZmNudCAoIHNrYl9k
YXRhcmVmcCApIHRvIAorICogdGhlIGhlYWQgb2Ygb3VyIGFsbG9jYXRlZCBidWZmZXIgcmF0aGVy
IHRoYW4gdGhlIGVuZCBvZiB0aGUgZGF0YSBhcyB1c2VkIGJ5IGFsbG9jX3NrYgorICogKCB0aGlz
IHdvdWxkIGhhdmUgdXBzZXQgdGhlIHBvc3NpYmlsaXR5IG9mIGJlaW5nIGFibGUgdG8gdXNlIHpl
cm8gY29weSBhcyB3ZSB3b3VsZAorICogIGJlIGNvcnJ1cHRpbmcgdGhlIGluY29taW5nIGRhdGEp
LiAKKyAqIEl0IGlzIHRoZSBpbnRlbnRpb24gdGhhdCBhIHNpbmdsZSByZWZjbnQgY291bGQgYmUg
dXNlZCBmb3IgbXVsdGlwbGUgemVyb19jb3BpZWQgc2ticworICogd2hpY2ggbWF5IGNvbWUgZnJv
bSBhIHNpbmdsZSBsYXJnZXIgZHJpdmVyIGJ1ZmZlci4KKyAqIFRoZSB0eXBpY2FsIHVzYWdlIHNj
ZW5hcmlvIGZvciB0aGlzIGZ1bmN0aW9uIGlzIGFzIGZvbGxvd3MKKyAqIDEpIHJlY2VpdmUgcGFj
a2V0CisgKiAyKSBrbWFsbG9jIG5ldyBpbyBidWZmZXIgZm9yIGlvIHByb2dyYW0gdG8gcmVwbGFj
ZSBidWZmZXIgdGhhdCBqdXN0IGNhbWUgaW4KKyAqIGlmIHRoaXMgc3VjY2VlZHMgIGluaXRfemVy
b19jb3B5X2J1ZmZlciB0aGUgbmV3IGJ1ZmZlciAmIG1ha2VfemVyb19jb3B5IHNrYiAKKyAqIHRo
ZSBuZXdseSByZWNlaXZlZCBidWZmZXIuCisgKiAzKSBjYWxsIG5ldGlmX3J4IHdpdGggdGhlIG5l
dyBidWZmZXIuCisgKiBXZSBjYW50IHVzZSBhIHN0YXRpYyBsaXN0IG9mIGNpcmN1bGFyIGxpc3Qg
b2YgYnVmZmVycyBmb3IgdGhlIGlvIHByb2dyYW0gCisgKiAmIGEgZGVzdHJ1Y3RvciB0eXBlIGNv
bmNlcHQgdG8gZnJlZSBnaXZlIHRoZSBidWZmZXIgYmFjayB0byB0aGUgZHJpdmVyIGZvciAyIHJl
YXNvbnMuCisgKiAxKSBpZiBzb21lb25lIHN1c3BlbmRzIGFuIGZ0cCB0cmFuc2ZlciBvciBzaW1p
bGFyIHdpdGggY3RybC16CisgKiB0aGUgcmVjZWl2ZWQgYnVmZmVyIHdpbGwgc3RheSBpbiB0aGUg
bmV0d29yayBzdGFjayAmIG5vdCBiZSBnaXZlbgorICogYmFjayB0byB0aGUgZHJpdmVyIHVudGls
IHRoZSBmdHAgdHJhbnNmZXIgaXMgdW5zdXNwZW5kZWQgJiB0aHVzIGxvY2tpbmcKKyAqIHRoZSBk
cml2ZXIgZHVyaW5nIHRoaXMgdGltZS4KKyAqIDIpIGlmIHNrYi0+ZGVzdHJ1Y3RvciBpcyBjYWxs
ZWQgd2hlbiBkcml2ZXIgaXMgdW5sb2FkZWQgd2Ugd291bGQgY3Jhc2gKKyAqIGFzIHRoZSBmdW5j
dGlvbiBubyBsb25nZXIgZXhpc3RzLCB0aGUgcXVhbnRpdHkgb2YgY29kZSByZXF1aXJlZAorICog
dG8gd29yayBhcm91bmQgdGhpcyB3b3VsZCBiZSAzMDAgb3IgNDAwIGxpbmVzIGFzIHdlIHdvdWxk
IGhhdmUgdG8KKyAqIHB1bGwgYWxsIHRoZSBkcml2ZXJzIHNrYnVmZnMgZnJvbSB0aGUgc3RhY2sg
d2hlbiB1bnJlZ2lzdGVyaW5nIHRoZQorICogZHJpdmVyICYgc29tZSBvZiB0aGUgbmV0d29yayBj
b2RlIGNvdWxkIHVuZGVyc3RhbmRhYmx5IGdldCB1cHNldCBpZiB3ZSBkaWQgdGhpcy4KKyAqIEZv
ciB0aGlzIHJlYXNvbiB3ZSBoYXZlIGtmcmVlX3NrYl9idWZmZXIgZnJlZWluZyBhIHVzZXIgc3Bl
Y2lmaWVkIGJ1ZmZlci4KKyAqLworc3RydWN0IHNrX2J1ZmYgKm1ha2VfemVyb19jb3B5X3NrYih1
bnNpZ25lZCBpbnQgc2l6ZSxpbnQgZ2ZwX21hc2ssCisJCQkJICAgIHVuc2lnbmVkIGNoYXIgKmRh
dGEsemVyb19jb3B5X2hlYWRlciAqemNfaGVhZGVyKQoreworCQorCXN0cnVjdCBza19idWZmICpz
a2I7CisKKwlpZiAoaW5faW50ZXJydXB0KCkgJiYgKGdmcF9tYXNrICYgX19HRlBfV0FJVCkpIHsK
KwkJc3RhdGljIGludCBjb3VudCA9IDA7CisJCWlmICgrK2NvdW50IDwgNSkgeworCQkJcHJpbnRr
KEtFUk5fRVJSICJtYWtlX3plcm9fY29weV9za2IgY2FsbGVkIG5vbmF0b21pY2FsbHkgIgorCQkJ
ICAgICAgICJmcm9tIGludGVycnVwdCAlcFxuIiwgTkVUX0NBTExFUihzaXplKSk7CisgCQkJKihp
bnQqKTAgPSAwOworCQl9CisJCWdmcF9tYXNrICY9IH5fX0dGUF9XQUlUOworCX0KKworCS8qIEdl
dCB0aGUgSEVBRCAqLworCXNrYj0gc2tiX2hlYWRfZnJvbV9wb29sKCk7CisJaWYgKHNrYiA9PSBO
VUxMKSB7CisJCXNrYiA9IGttZW1fY2FjaGVfYWxsb2Moc2tidWZmX2hlYWRfY2FjaGUsIGdmcF9t
YXNrKTsKKwkJaWYgKHNrYiA9PSBOVUxMKQorCQkJZ290byBub2hlYWQ7CisJfQorCS8qIFhYWDog
ZG9lcyBub3QgaW5jbHVkZSBzbGFiIG92ZXJoZWFkICovIAorCXNrYi0+dHJ1ZXNpemUgPSAgc2l6
ZSArIHNpemVvZihzdHJ1Y3Qgc2tfYnVmZik7CisKKworCS8qIExvYWQgdGhlIGRhdGEgcG9pbnRl
cnMuICovCisJc2tiLT5oZWFkID0gZGF0YTsKKwlza2ItPmRhdGEgPSBkYXRhOworCXNrYi0+dGFp
bCA9IGRhdGE7CisJc2tiLT5lbmQgPSBkYXRhICsgc2l6ZTsKKworCS8qIFNldCB1cCBvdGhlciBz
dGF0ZSAqLworCXNrYi0+bGVuID0gMDsKKwlza2ItPmlzX2Nsb25lID0gMDsKKwlza2ItPmNsb25l
ZCA9IDA7CisJYXRvbWljX3NldCgmc2tiLT51c2VycywxKTsKKwlza2ItPnJlZmNudF9wdHI9Jnpj
X2hlYWRlci0+cmVmY250OworCWF0b21pY19pbmMoc2tiLT5yZWZjbnRfcHRyKTsKKwlyZXR1cm4g
c2tiOworbm9oZWFkOgorCXJldHVybiBOVUxMOworfQogCiAvKiAJQWxsb2NhdGUgYSBuZXcgc2ti
dWZmLiBXZSBkbyB0aGlzIG91cnNlbHZlcyBzbyB3ZSBjYW4gZmlsbCBpbiBhIGZldwogICoJJ3By
aXZhdGUnIGZpZWxkcyBhbmQgYWxzbyBkbyBtZW1vcnkgc3RhdGlzdGljcyB0byBmaW5kIGFsbCB0
aGUKQEAgLTIwNSw3ICszMDMsOCBAQAogCXNrYi0+aXNfY2xvbmUgPSAwOwogCXNrYi0+Y2xvbmVk
ID0gMDsKIAotCWF0b21pY19zZXQoJnNrYi0+dXNlcnMsIDEpOyAKKwlhdG9taWNfc2V0KCZza2It
PnVzZXJzLCAxKTsKKwlza2ItPnJlZmNudF9wdHI9KGF0b21pY190ICopc2tiLT5lbmQ7CiAJYXRv
bWljX3NldChza2JfZGF0YXJlZnAoc2tiKSwgMSk7CiAJcmV0dXJuIHNrYjsKIApAQCAtMjI1LDYg
KzMyNCw3IEBACiAJc3RydWN0IHNrX2J1ZmYgKnNrYiA9IHA7CiAKIAlza2ItPmRlc3RydWN0b3Ig
PSBOVUxMOworCXNrYi0+cmVmY250X3B0cj1OVUxMOwogCXNrYi0+cGt0X3R5cGUgPSBQQUNLRVRf
SE9TVDsJLyogRGVmYXVsdCB0eXBlICovCiAJc2tiLT5wcmV2ID0gc2tiLT5uZXh0ID0gTlVMTDsK
IAlza2ItPmxpc3QgPSBOVUxMOwpAQCAtMjQ4LDE0ICszNDgsNDUgQEAKIAlza2ItPnByaW9yaXR5
ID0gMDsKIH0KIAorLyogV2UgY2FuJ3QgdXNlIGEgcHJvY2VkdXJlIHBvaW50ZXIgYXMgZnJlZV9w
YWdlcyBpcyBpbmxpbmUgKi8KK3ZvaWQgc2tiX2ZyZWVfcGFnZXModW5zaWduZWQgbG9uZyBwYWdl
LCB1bnNpZ25lZCBsb25nIG9yZGVyKQoreworCWZyZWVfcGFnZXMocGFnZSxvcmRlcik7Cit9CisK
K3ZvaWQga2ZyZWVfc2tiX2J1ZmZlcihzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQoreworCXplcm9fY29w
eV9oZWFkZXIgKnpjX2hlYWRlcjsKKwlpZiAoYXRvbWljX2RlY19hbmRfdGVzdChza2JfZGF0YXJl
ZnAoc2tiKSkpIHsKKwkJaWYoKHVuc2lnbmVkIGNoYXIgKilza2JfZGF0YXJlZnAoc2tiKT09c2ti
LT5lbmQpCisJCQlrZnJlZShza2ItPmhlYWQpOworCQllbHNlIHsKKwkJCXpjX2hlYWRlcj0oemVy
b19jb3B5X2hlYWRlciAqKSgoc2l6ZV90KXNrYl9kYXRhcmVmcChza2IpLQorCQkJCW9mZnNldG9m
KHplcm9fY29weV9oZWFkZXIscmVmY250KSk7CisJCQlpZih6Y19oZWFkZXItPm1hZ2ljPT1aRVJP
Q09QWV9NQUdJQykKKwkJCXsKKwkJCQlpZih6Y19oZWFkZXItPmZyZWVmdW5jPT0oemVyb2NvcHlf
ZnJlZWZ1bmMpc2tiX2ZyZWVfcGFnZXMpCisJCQkJCXNrYl9mcmVlX3BhZ2VzKCh1bnNpZ25lZCBs
b25nKXpjX2hlYWRlciwKKwkJCQkJCSAgIHpjX2hlYWRlci0+b3JkZXIpOworCQkJCWVsc2UKKwkJ
CQkJemNfaGVhZGVyLT5mcmVlZnVuYyh6Y19oZWFkZXIpOworCQkJCWF0b21pY19kZWMoJm5ldF96
ZXJvY29weV9idWZmZXJzKTsKKwkJCX0KKwkJCWVsc2UKKwkJCQlwcmludGsoImtmcmVlX3NrYl9i
dWZmZXIgYmFkIFpFUk9DT1BZX01BR0lDIHpjX2hlYWRlcj0lcCIsemNfaGVhZGVyKTsKKwkJfQor
CQkJCisJCSAgCisJfQorfQorCisKIC8qCiAgKglGcmVlIGFuIHNrYnVmZiBieSBtZW1vcnkgd2l0
aG91dCBjbGVhbmluZyB0aGUgc3RhdGUuIAogICovCiB2b2lkIGtmcmVlX3NrYm1lbShzdHJ1Y3Qg
c2tfYnVmZiAqc2tiKQogewotCWlmICghc2tiLT5jbG9uZWQgfHwgYXRvbWljX2RlY19hbmRfdGVz
dChza2JfZGF0YXJlZnAoc2tiKSkpICAKLQkJa2ZyZWUoc2tiLT5oZWFkKTsKLQorCWtmcmVlX3Nr
Yl9idWZmZXIoc2tiKTsKIAlza2JfaGVhZF90b19wb29sKHNrYik7CiB9CiAKQEAgLTI2Niw2ICsz
OTcsMTIgQEAKICAqCUZyZWUgYW4gc2tfYnVmZi4gUmVsZWFzZSBhbnl0aGluZyBhdHRhY2hlZCB0
byB0aGUgYnVmZmVyLiAKICAqCUNsZWFuIHRoZSBzdGF0ZS4gVGhpcyBpcyBhbiBpbnRlcm5hbCBo
ZWxwZXIgZnVuY3Rpb24uIFVzZXJzIHNob3VsZAogICoJYWx3YXlzIGNhbGwga2ZyZWVfc2tiCisg
KgorICogICAgICBrZnJlZV9za2JtZW0gaGFkIHRvIGJlIHNwbGl0IGludG8gdHdvIGZ1bmN0aW9u
cyBiZWNhdXNlCisgKiAgICAgIHNrYl9oZWFkZXJpbml0IGhhZCB0byBiZSBkb25lIGFmdGVyIHRo
ZSB6ZXJvIGNvcHkgYnVmZmVyCisgKiAgICAgIGZyZWUgJiBwdXR0aW5nIHNrYl9oZWFkZXJpbml0
IGFmdGVyIGtmcmVlX3NrYm1lbSB3YXMKKyAqICAgICAgY2F1c2luZyByYWNlIGNvbmRpdGlvbnMg
YXMgdGhlIG5ld2x5IGZyZWVkIHVwIHNrX2J1ZmYKKyAqICAgICAgZGlkbid0IGhhdmUgaXRzIGhl
YWQgJiB0YWlsIHBvaW50ZXIgaW5pdGlhbGlzZWQgREpCLgogICovCiAKIHZvaWQgX19rZnJlZV9z
a2Ioc3RydWN0IHNrX2J1ZmYgKnNrYikKQEAgLTI5MCw5ICs0MjcsMTAgQEAKICNpZmRlZiBDT05G
SUdfTkVUCQkKIAlpZihza2ItPnJ4X2RldikKIAkJZGV2X3B1dChza2ItPnJ4X2Rldik7Ci0jZW5k
aWYJCQorI2VuZGlmCisJa2ZyZWVfc2tiX2J1ZmZlcihza2IpOwogCXNrYl9oZWFkZXJpbml0KHNr
YiwgTlVMTCwgMCk7ICAvKiBjbGVhbiBzdGF0ZSAqLwotCWtmcmVlX3NrYm1lbShza2IpOworCXNr
Yl9oZWFkX3RvX3Bvb2woc2tiKTsKIH0KIAogLyoqCg==

--0__=ourZSmsmTWZkD5Y6mbH1UZxqGrv7GCc25R9FwQEjm1C19YLKinxWknUb--


From owner-netdev@oss.sgi.com Tue Jul 25 06:53:07 2000
Received:  by oss.sgi.com id <S42211AbQGYNwr>;
	Tue, 25 Jul 2000 06:52:47 -0700
Received: from sabre-wulf.nvg.ntnu.no ([129.241.210.67]:15376 "EHLO
        sabre-wulf.nvg.ntnu.no") by oss.sgi.com with ESMTP
	id <S42210AbQGYNwM>; Tue, 25 Jul 2000 06:52:12 -0700
Received: from tyrell.nvg.ntnu.no ([IPv6:::ffff:129.241.210.70]:51727 "EHLO
        tyrell.nvg.ntnu.no" ident: "TIMEDOUT2" whoson: "rufsen")
	by sabre-wulf.nvg.ntnu.no with ESMTP id <S49451AbQGYNvU>;
	Tue, 25 Jul 2000 15:51:20 +0200
Received: (from venaas@localhost)
          by tyrell.nvg.ntnu.no (8.9.3/8.8.4)
	  id PAA05560; Tue, 25 Jul 2000 15:51:09 +0200
From:   <venaas@nvg.ntnu.no>
Date:   Tue, 25 Jul 2000 15:51:09 +0200
To:     Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Cc:     aaguirre@zofri.cl, netdev@oss.sgi.com
Subject: Re: getipnodebyname??
Message-ID: <20000725155109.A5439@nvg.ntnu.no>
References: <20000713213055.A4337@bacchus.dhis.org> <200007132110.RAA06017@fwzofri.zofri.cl> <20000714084140G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000714084140G.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>; from yoshfuji@ecei.tohoku.ac.jp on Fri, Jul 14, 2000 at 08:41:40AM +0900
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Jul 14, 2000 at 08:41:40AM +0900, Hideaki YOSHIFUJI wrote:
> In article <200007132110.RAA06017@fwzofri.zofri.cl> (at Thu, 13 Jul 2000 17:10:54 -0400 (CST)), Armando Aguirre Schlick <aaguirre@zofri.cl> says:
> 
> >  	Here's my question... is there some standard function like
> >  getipnodebyname in glibc?
> >  	I need to reach all of the address of a host, including IPv4-mapped
> >  IPv6 address...
> 
> gethostbyname2() (or gethostbyname2_r(); maybe glibc specific).
> 
> Pelease note getipnoby{name,addr} and gethostbyname2{,_r}() are now 
> deprecated; please read draft-ietf-ipng-rfc2553bis-00.txt.
> According to this draft, we will be able to pass AI_V4MAPPED, AI_ALL, 
> AI_ADDRCONFIG flags through getaddrinfo(). 
> (I'm not sure, but maybe) I will implement this.

I still think that getipnoby{name,addr} need to be implemented in order
to be compliant with the rfc2553bis-00 draft. Or have I missed something?

I think it's important that the new glibc 2.2 is fully compliant, since
there will be quite some time (a few years) until next opportunity. There
are other things that need to be added/changed too. Of course there are
other standards too....

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 Tue Jul 25 06:59:17 2000
Received:  by oss.sgi.com id <S42218AbQGYN7H>;
	Tue, 25 Jul 2000 06:59:07 -0700
Received: from tazenda.demon.co.uk ([158.152.220.239]:10509 "EHLO
        tazenda.demon.co.uk") by oss.sgi.com with ESMTP id <S42217AbQGYN6t>;
	Tue, 25 Jul 2000 06:58:49 -0700
Received: from kings-cross.london.uk.eu.org [::ffff:192.168.2.83] 
	by tazenda.demon.co.uk with esmtp (Exim 3.11 #1 (Debian))
	id 13H54l-0000OA-00; Tue, 25 Jul 2000 14:48:51 +0100
Received: from localhost
	([::ffff:127.0.0.1] helo=tazenda.demon.co.uk ident=pb)
	by kings-cross.london.uk.eu.org with esmtp (Exim 3.12 #1 (Debian))
	id 13H52o-0001n8-00; Tue, 25 Jul 2000 14:46:50 +0100
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To:     Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) 
        <yoshfuji@ecei.tohoku.ac.jp>
cc:     netdev@oss.sgi.com
Subject: Re: SIOCGLIFCONF? 
In-Reply-To: Message from Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) <yoshfuji@ecei.tohoku.ac.jp> 
   of "Mon, 01 May 2000 00:16:40 +0900." <20000501001640H.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> 
References: <yoshfuji@ecei.tohoku.ac.jp> <E12lvCJ-0000Du-00@kings-cross.london.uk.eu.org> <20000501000837W.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>  <20000501001640H.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 25 Jul 2000 14:46:50 +0100
From:   Philip Blundell <pb@tazenda.demon.co.uk>
Message-Id: <E13H52o-0001n8-00@kings-cross.london.uk.eu.org>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>> >.. Do you have a copyright assignment on file already?
>> 
>> ifaddrs.h and ifaddrs.3 are based on BSDI's ones; "BSDI Lisence".
>> ifaddrs.c is my work; GPL2.
>
>I mean, yes.

(Sorry for the delay)

I can't find this in the electronic list of assignments at gnu.org.  Did you 
get the signed paperwork back from the FSF to confirm your assignment had been 
added?

p.



From owner-netdev@oss.sgi.com Tue Jul 25 07:40:27 2000
Received:  by oss.sgi.com id <S42219AbQGYOkI>;
	Tue, 25 Jul 2000 07:40:08 -0700
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:32266 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S42210AbQGYOjq>; Tue, 25 Jul 2000 07:39:46 -0700
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id XAA14123;
	Tue, 25 Jul 2000 23:38:52 +0900
To:     pb@tazenda.demon.co.uk
Cc:     netdev@oss.sgi.com
Subject: Re: SIOCGLIFCONF? 
From:   Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <E13H52o-0001n8-00@kings-cross.london.uk.eu.org>
References: <20000501000837W.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
	<20000501001640H.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
	<E13H52o-0001n8-00@kings-cross.london.uk.eu.org>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000725233852K.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date:   Tue, 25 Jul 2000 23:38:52 +0900
X-Dispatcher: imput version 990905(IM130)
Lines:  22
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <E13H52o-0001n8-00@kings-cross.london.uk.eu.org> (at Tue, 25 Jul 2000 14:46:50 +0100), Philip Blundell <pb@tazenda.demon.co.uk> says:

> >> >.. Do you have a copyright assignment on file already?
> >> 
> >> ifaddrs.h and ifaddrs.3 are based on BSDI's ones; "BSDI Lisence".
> >> ifaddrs.c is my work; GPL2.
> >
> >I mean, yes.

> I can't find this in the electronic list of assignments at gnu.org.  Did you 
> get the signed paperwork back from the FSF to confirm your assignment had been 
> added?

Could you explain in in datail?

Bug report once I submitted is
<http://www-gnats.gnu.org:8080/cgi-bin/wwwgnats.pl/full/1642>.

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@v6.linux.or.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Tue Jul 25 10:22:57 2000
Received:  by oss.sgi.com id <S42228AbQGYRWs>;
	Tue, 25 Jul 2000 10:22:48 -0700
Received: from panic.ohr.gatech.edu ([130.207.47.194]:2576 "EHLO havoc.gtf.org")
	by oss.sgi.com with ESMTP id <S42210AbQGYRW1>;
	Tue, 25 Jul 2000 10:22:27 -0700
Received: from mandrakesoft.com (adsl-77-228-135.atl.bellsouth.net [216.77.228.135])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id NAA29811
	for <netdev@oss.sgi.com>; Tue, 25 Jul 2000 13:21:51 -0400
Message-ID: <397DCCB0.EF0DC4DA@mandrakesoft.com>
Date:   Tue, 25 Jul 2000 13:21:52 -0400
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com
Subject: quick packet xmit q
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

Do others think it would be helpful for dev->hard_start_xmit() to know
if the packet being Tx'd is the last in a sequence?

I was thinking that the net driver might be able to make some
optimizations if it knew that other packet were (or were not) to follow,
after the current one being processed.

In general processing items in a series usually lends to a certain
amount of optimization.  When Tulip chips are using the ring (not linked
list) style of descriptors, you have two not one buffers for each
descriptor.  Processing things in a series also may allow one to make
better use of various interrupt mitigation strategies.

	Jeff



-- 
Jeff Garzik              |
Building 1024            | Yossarian lives.
MandrakeSoft, Inc.       |

From owner-netdev@oss.sgi.com Tue Jul 25 10:26:48 2000
Received:  by oss.sgi.com id <S42233AbQGYR0i>;
	Tue, 25 Jul 2000 10:26:38 -0700
Received: from d12lmsgate-3.de.ibm.com ([195.212.91.201]:52884 "EHLO
        d12lmsgate-3.de.ibm.com") by oss.sgi.com with ESMTP
	id <S42229AbQGYR0O>; Tue, 25 Jul 2000 10:26:14 -0700
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA225042
	for <netdev@oss.sgi.com>; Tue, 25 Jul 2000 19:25:40 +0200
From:   DJBARROW@de.ibm.com
Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1])
	by d12relay01.de.ibm.com (8.8.8m3/NCO v4.92) with SMTP id TAA226150
	for <netdev@oss.sgi.com>; Tue, 25 Jul 2000 19:25:39 +0200
Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id C1256927.005FBAB9 ; Tue, 25 Jul 2000 19:25:37 +0200
X-Lotus-FromDomain: IBMDE
To:     netdev@oss.sgi.com
Message-ID: <C1256927.005FBA38.00@d12mta09.de.ibm.com>
Date:   Tue, 25 Jul 2000 19:25:32 +0200
Subject: zero copy skb enhancments.
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=HyYIJHhx6KIxINiNzhmNT2HdVN2xJrTxEQhDBJcAiTrUWRcrZfYvmPzZ"
Content-Disposition: inline
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

--0__=HyYIJHhx6KIxINiNzhmNT2HdVN2xJrTxEQhDBJcAiTrUWRcrZfYvmPzZ
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable




Did you receive the stuff yesterday ?,

Here is a minor fix to the patches I posted yesterday, I forgot to add =
my
new functions to kernel/ksyms.c in
the last patch.

(See attached file: zero_copy_skb250700.patch)

D.J. Barrow Linux for S/390 kernel developer
eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Sch=F6naicherstr. 220, 71032 B=F6blingen
=

--0__=HyYIJHhx6KIxINiNzhmNT2HdVN2xJrTxEQhDBJcAiTrUWRcrZfYvmPzZ
Content-type: application/octet-stream; 
	name="zero_copy_skb250700.patch"
Content-Disposition: attachment; filename="zero_copy_skb250700.patch"
Content-transfer-encoding: base64

ZGlmZiAtdSAtciBsaW51eC5vcmlnL2luY2x1ZGUvbGludXgvc2tidWZmLmggbGludXgubmV3L2lu
Y2x1ZGUvbGludXgvc2tidWZmLmgKLS0tIGxpbnV4Lm9yaWcvaW5jbHVkZS9saW51eC9za2J1ZmYu
aAlUaHUgSnVsIDEzIDA3OjAyOjAyIDIwMDAKKysrIGxpbnV4Lm5ldy9pbmNsdWRlL2xpbnV4L3Nr
YnVmZi5oCU1vbiBKdWwgMjQgMjE6Mjg6MzggMjAwMApAQCAtNDgsNiArNDgsMTcgQEAKIH07CiAj
ZW5kaWYKIAorCisjZGVmaW5lIFpFUk9DT1BZX01BR0lDIDB4MzQ1Njk4NzYKK3R5cGVkZWYgdm9p
ZCAoKnplcm9jb3B5X2ZyZWVmdW5jKShjb25zdCB2b2lkICopOwordHlwZWRlZiBzdHJ1Y3Qgewor
CV9fdTMyICAgICAgICAgICAgIG1hZ2ljOworCWF0b21pY190ICAgICAgICAgIHJlZmNudDsKKwl6
ZXJvY29weV9mcmVlZnVuYyBmcmVlZnVuYzsKKwlpbnQgICAgICAgICAgICAgICBvcmRlcjsgLyog
dXNlZCBmb3IgZnJlZV9wYWdlcyAqLworfSB6ZXJvX2NvcHlfaGVhZGVyOworCisKIHN0cnVjdCBz
a19idWZmX2hlYWQgewogCS8qIFRoZXNlIHR3byBtZW1iZXJzIG11c3QgYmUgZmlyc3QuICovCiAJ
c3RydWN0IHNrX2J1ZmYJKiBuZXh0OwpAQCAtMTI0LDYgKzEzNSw3IEBACiAJdW5zaWduZWQgY2hh
cgkqZGF0YTsJCQkvKiBEYXRhIGhlYWQgcG9pbnRlcgkJCQkqLwogCXVuc2lnbmVkIGNoYXIJKnRh
aWw7CQkJLyogVGFpbCBwb2ludGVyCQkJCQkqLwogCXVuc2lnbmVkIGNoYXIgCSplbmQ7CQkJLyog
RW5kIHBvaW50ZXIJCQkJCSovCisJYXRvbWljX3QgICAgICAgICpyZWZjbnRfcHRyOyAgICAgICAg
ICAgIC8qIFBvaW50ZXIgdG8gcmVmY250IGFyZWEgICAgICAgICAgICAgICAgICAgICAgICovCiAJ
dm9pZCAJCSgqZGVzdHJ1Y3Rvcikoc3RydWN0IHNrX2J1ZmYgKik7CS8qIERlc3RydWN0IGZ1bmN0
aW9uCQkqLwogI2lmZGVmIENPTkZJR19ORVRGSUxURVIKIAkvKiBDYW4gYmUgdXNlZCBmb3IgY29t
bXVuaWNhdGlvbiBiZXR3ZWVuIGhvb2tzLiAqLwpAQCAtMTYxLDYgKzE3MywxMiBAQAogCiBleHRl
cm4gdm9pZAkJCV9fa2ZyZWVfc2tiKHN0cnVjdCBza19idWZmICpza2IpOwogZXh0ZXJuIHN0cnVj
dCBza19idWZmICoJCXNrYl9wZWVrX2NvcHkoc3RydWN0IHNrX2J1ZmZfaGVhZCAqbGlzdCk7Citl
eHRlcm4gdm9pZCAgICAgICAgICAgICAgICAgICAgIHNrYl9mcmVlX3BhZ2VzKHVuc2lnbmVkIGxv
bmcgcGFnZSwgdW5zaWduZWQgbG9uZyBvcmRlcik7Cit2b2lkICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGluaXRfemVyb19jb3B5X2J1ZmZlcih6ZXJvX2NvcHlfaGVhZGVyICpoZWFkZXIsCisJ
CQkJCQkgICAgICB6ZXJvY29weV9mcmVlZnVuYyBmcmVlZnVuYyxpbnQgb3JkZXIpOworc3RydWN0
IHNrX2J1ZmYgICAgICAgICAgICAgICAgICAqbWFrZV96ZXJvX2NvcHlfc2tiKHVuc2lnbmVkIGlu
dCBzaXplLGludCBnZnBfbWFzaywKKwkJCQl1bnNpZ25lZCBjaGFyICpkYXRhLHplcm9fY29weV9o
ZWFkZXIgKmhlYWRlcik7CitleHRlcm4gdm9pZCAgICAgICAgICAgICAgICAgICAgIGtmcmVlX3Nr
Yl9idWZmZXIoc3RydWN0IHNrX2J1ZmYgKnNrYik7CiBleHRlcm4gc3RydWN0IHNrX2J1ZmYgKgkJ
YWxsb2Nfc2tiKHVuc2lnbmVkIGludCBzaXplLCBpbnQgcHJpb3JpdHkpOwogZXh0ZXJuIHZvaWQJ
CQlrZnJlZV9za2JtZW0oc3RydWN0IHNrX2J1ZmYgKnNrYik7CiBleHRlcm4gc3RydWN0IHNrX2J1
ZmYgKgkJc2tiX2Nsb25lKHN0cnVjdCBza19idWZmICpza2IsIGludCBwcmlvcml0eSk7CkBAIC0x
NzksNyArMTk3LDcgQEAKIC8qIEludGVybmFsICovCiBzdGF0aWMgaW5saW5lIGF0b21pY190ICpz
a2JfZGF0YXJlZnAoc3RydWN0IHNrX2J1ZmYgKnNrYikKIHsKLQlyZXR1cm4gKGF0b21pY190ICop
KHNrYi0+ZW5kKTsKKwlyZXR1cm4gc2tiLT5yZWZjbnRfcHRyOwogfQogCiAvKioKZGlmZiAtdSAt
ciBsaW51eC5vcmlnL2tlcm5lbC9rc3ltcy5jIGxpbnV4Lm5ldy9rZXJuZWwva3N5bXMuYwotLS0g
bGludXgub3JpZy9rZXJuZWwva3N5bXMuYwlXZWQgSnVsIDEyIDE5OjA2OjE3IDIwMDAKKysrIGxp
bnV4Lm5ldy9rZXJuZWwva3N5bXMuYwlXZWQgSnVsIDI2IDAwOjQ0OjUyIDIwMDAKQEAgLTUzMCwz
ICs1MzAsOCBAQAogCiBFWFBPUlRfU1lNQk9MKHRhc2tsaXN0X2xvY2spOwogRVhQT1JUX1NZTUJP
TChwaWRoYXNoKTsKKworLyogRm9yIHplcm8gY29weWluZyByZWNlaXZlZCBuZXR3b3JrIHBhY2tl
dHMgKi8KK0VYUE9SVF9TWU1CT0wobWFrZV96ZXJvX2NvcHlfc2tiKTsKK0VYUE9SVF9TWU1CT0wo
aW5pdF96ZXJvX2NvcHlfYnVmZmVyKTsKK0VYUE9SVF9TWU1CT0woc2tiX2ZyZWVfcGFnZXMpOwpk
aWZmIC11IC1yIGxpbnV4Lm9yaWcvbmV0L2NvcmUvc2tidWZmLmMgbGludXgubmV3L25ldC9jb3Jl
L3NrYnVmZi5jCi0tLSBsaW51eC5vcmlnL25ldC9jb3JlL3NrYnVmZi5jCU1vbiBNYXkgMjIgMTg6
NTA6NTUgMjAwMAorKysgbGludXgubmV3L25ldC9jb3JlL3NrYnVmZi5jCU1vbiBKdWwgMjQgMjE6
Mjk6MjcgMjAwMApAQCAtMTksNiArMTksOCBAQAogICoJCVJheSBWYW5UYXNzbGUJOglGaXhlZCAt
LXNrYi0+bG9jayBpbiBmcmVlCiAgKgkJQWxhbiBDb3gJOglza2JfY29weSBjb3B5IGFycCBmaWVs
ZAogICoJCUFuZGkgS2xlZW4JOglzbGFiaWZpZWQgaXQuCisgKiAgICAgICAgICAgICAgRC5KLiBC
YXJyb3cgICAgIDogICAgICAgQWRkZWQgbWFrZV96ZXJvX2NvcHlfc2tiIGFzIAorICogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3Bvc2VkIGJ5IFV0eiBCYWNoZXIuCiAg
KgogICoJTk9URToKICAqCQlUaGUgX19za2JfIHJvdXRpbmVzIHNob3VsZCBiZSBjYWxsZWQgd2l0
aCBpbnRlcnJ1cHRzIApAQCAtNjMsNiArNjUsNyBAQAogI2luY2x1ZGUgPGFzbS9zeXN0ZW0uaD4K
IAogaW50IHN5c2N0bF9ob3RfbGlzdF9sZW4gPSAxMjg7CitzdGF0aWMgYXRvbWljX3QgbmV0X3pl
cm9jb3B5X2J1ZmZlcnMgID0gQVRPTUlDX0lOSVQoMCk7CiAKIHN0YXRpYyBrbWVtX2NhY2hlX3Qg
KnNrYnVmZl9oZWFkX2NhY2hlOwogCkBAIC0xNDIsNiArMTQ1LDEwMSBAQAogCWttZW1fY2FjaGVf
ZnJlZShza2J1ZmZfaGVhZF9jYWNoZSwgc2tiKTsKIH0KIAorLyoKKyAqIGluaXRfemVyb19jb3B5
X2J1ZmZlciBzaG91bGQgYmUgY2FsbGVkIHByaW9yIHRvIGNhbGxpbmcgbWFrZV96ZXJvX2NvcHlf
c2tiCisgKiBpdCdzIHB1cnBvc2UgaXMgdG8gaW5pdGlhbGlzZSB0aGUgcmVmY250LCB0aGUgaGVh
ZGVyIGhhcyB0byBiZQorICogYXQgdGhlIHN0YXJ0IG9mIHRoZSBidWZmZXIuCisgKiBUaGUgZnJl
ZWZ1bmMgaXMgdHlwaWNhbGx5IGtmcmVlICYgaXMgdXNlZCB0byBmcmVlIHRoZSBidWZmZXIgdXAu
CisgKi8KK3ZvaWQgaW5pdF96ZXJvX2NvcHlfYnVmZmVyKHplcm9fY29weV9oZWFkZXIgKmhlYWRl
cix6ZXJvY29weV9mcmVlZnVuYyBmcmVlZnVuYyxpbnQgb3JkZXIpCit7CisJc3RhdGljIGludCBt
ZXNzYWdlX3ByaW50ZWQ9MDsKKwlpbnQgICAgYnVmZmNudDsKKwloZWFkZXItPm1hZ2ljPVpFUk9D
T1BZX01BR0lDOworCWF0b21pY19zZXQoJmhlYWRlci0+cmVmY250LDApOworCWhlYWRlci0+ZnJl
ZWZ1bmM9ZnJlZWZ1bmM7CisJaGVhZGVyLT5vcmRlcj1vcmRlcjsKKwlhdG9taWNfaW5jKCZuZXRf
emVyb2NvcHlfYnVmZmVycyk7CisJYnVmZmNudD1hdG9taWNfcmVhZCgmbmV0X3plcm9jb3B5X2J1
ZmZlcnMpOworCWlmKChidWZmY250PjEwMDB8fGJ1ZmZjbnQ8MCkmJiFtZXNzYWdlX3ByaW50ZWQp
CisJeworCQlwcmludGsoImJ1ZmZlciBtYW5hZ21lbnQgcHJvYmxlbSBpbml0X3plcm9fY29weV9i
dWZmZXIgY291bnRzICVkIHplcm8gY29weSBidWZmZXJzXG4iLGJ1ZmZjbnQpOworCQltZXNzYWdl
X3ByaW50ZWQ9MTsKKwl9CisJCQorfQorLyoKKyAqIG1ha2VfemVyb19jb3B5X3NrYiB3YXMgYWRk
ZWQgc28gbmV0d29yayBkZXZpY2UgZHJpdmVycyBjb3VsZCB0YWtlIGRvCisgKiBnaXZlIHRoZSBu
ZXR3b3JrIGxheWVyIGRhdGEgcmVjZWl2ZWQgd2l0aG91dCBtZW1jcHlpbmcgaXQsCisgKiB6ZXJv
X2NvcHlfaGVhZGVyIGlzIHVzZWQgc28gdGhhdCBkcml2ZXJzIGNhbiBwb2ludCB0aGUgcmVmY250
ICggc2tiX2RhdGFyZWZwICkgdG8gCisgKiB0aGUgaGVhZCBvZiBvdXIgYWxsb2NhdGVkIGJ1ZmZl
ciByYXRoZXIgdGhhbiB0aGUgZW5kIG9mIHRoZSBkYXRhIGFzIHVzZWQgYnkgYWxsb2Nfc2tiCisg
KiAoIHRoaXMgd291bGQgaGF2ZSB1cHNldCB0aGUgcG9zc2liaWxpdHkgb2YgYmVpbmcgYWJsZSB0
byB1c2UgemVybyBjb3B5IGFzIHdlIHdvdWxkCisgKiAgYmUgY29ycnVwdGluZyB0aGUgaW5jb21p
bmcgZGF0YSkuIAorICogSXQgaXMgdGhlIGludGVudGlvbiB0aGF0IGEgc2luZ2xlIHJlZmNudCBj
b3VsZCBiZSB1c2VkIGZvciBtdWx0aXBsZSB6ZXJvX2NvcGllZCBza2JzCisgKiB3aGljaCBtYXkg
Y29tZSBmcm9tIGEgc2luZ2xlIGxhcmdlciBkcml2ZXIgYnVmZmVyLgorICogVGhlIHR5cGljYWwg
dXNhZ2Ugc2NlbmFyaW8gZm9yIHRoaXMgZnVuY3Rpb24gaXMgYXMgZm9sbG93cworICogMSkgcmVj
ZWl2ZSBwYWNrZXQKKyAqIDIpIGttYWxsb2MgbmV3IGlvIGJ1ZmZlciBmb3IgaW8gcHJvZ3JhbSB0
byByZXBsYWNlIGJ1ZmZlciB0aGF0IGp1c3QgY2FtZSBpbgorICogaWYgdGhpcyBzdWNjZWVkcyAg
aW5pdF96ZXJvX2NvcHlfYnVmZmVyIHRoZSBuZXcgYnVmZmVyICYgbWFrZV96ZXJvX2NvcHkgc2ti
IAorICogdGhlIG5ld2x5IHJlY2VpdmVkIGJ1ZmZlci4KKyAqIDMpIGNhbGwgbmV0aWZfcnggd2l0
aCB0aGUgbmV3IGJ1ZmZlci4KKyAqIFdlIGNhbnQgdXNlIGEgc3RhdGljIGxpc3Qgb2YgY2lyY3Vs
YXIgbGlzdCBvZiBidWZmZXJzIGZvciB0aGUgaW8gcHJvZ3JhbSAKKyAqICYgYSBkZXN0cnVjdG9y
IHR5cGUgY29uY2VwdCB0byBmcmVlIGdpdmUgdGhlIGJ1ZmZlciBiYWNrIHRvIHRoZSBkcml2ZXIg
Zm9yIDIgcmVhc29ucy4KKyAqIDEpIGlmIHNvbWVvbmUgc3VzcGVuZHMgYW4gZnRwIHRyYW5zZmVy
IG9yIHNpbWlsYXIgd2l0aCBjdHJsLXoKKyAqIHRoZSByZWNlaXZlZCBidWZmZXIgd2lsbCBzdGF5
IGluIHRoZSBuZXR3b3JrIHN0YWNrICYgbm90IGJlIGdpdmVuCisgKiBiYWNrIHRvIHRoZSBkcml2
ZXIgdW50aWwgdGhlIGZ0cCB0cmFuc2ZlciBpcyB1bnN1c3BlbmRlZCAmIHRodXMgbG9ja2luZwor
ICogdGhlIGRyaXZlciBkdXJpbmcgdGhpcyB0aW1lLgorICogMikgaWYgc2tiLT5kZXN0cnVjdG9y
IGlzIGNhbGxlZCB3aGVuIGRyaXZlciBpcyB1bmxvYWRlZCB3ZSB3b3VsZCBjcmFzaAorICogYXMg
dGhlIGZ1bmN0aW9uIG5vIGxvbmdlciBleGlzdHMsIHRoZSBxdWFudGl0eSBvZiBjb2RlIHJlcXVp
cmVkCisgKiB0byB3b3JrIGFyb3VuZCB0aGlzIHdvdWxkIGJlIDMwMCBvciA0MDAgbGluZXMgYXMg
d2Ugd291bGQgaGF2ZSB0bworICogcHVsbCBhbGwgdGhlIGRyaXZlcnMgc2tidWZmcyBmcm9tIHRo
ZSBzdGFjayB3aGVuIHVucmVnaXN0ZXJpbmcgdGhlCisgKiBkcml2ZXIgJiBzb21lIG9mIHRoZSBu
ZXR3b3JrIGNvZGUgY291bGQgdW5kZXJzdGFuZGFibHkgZ2V0IHVwc2V0IGlmIHdlIGRpZCB0aGlz
LgorICogRm9yIHRoaXMgcmVhc29uIHdlIGhhdmUga2ZyZWVfc2tiX2J1ZmZlciBmcmVlaW5nIGEg
dXNlciBzcGVjaWZpZWQgYnVmZmVyLgorICovCitzdHJ1Y3Qgc2tfYnVmZiAqbWFrZV96ZXJvX2Nv
cHlfc2tiKHVuc2lnbmVkIGludCBzaXplLGludCBnZnBfbWFzaywKKwkJCQkgICAgdW5zaWduZWQg
Y2hhciAqZGF0YSx6ZXJvX2NvcHlfaGVhZGVyICp6Y19oZWFkZXIpCit7CisJCisJc3RydWN0IHNr
X2J1ZmYgKnNrYjsKKworCWlmIChpbl9pbnRlcnJ1cHQoKSAmJiAoZ2ZwX21hc2sgJiBfX0dGUF9X
QUlUKSkgeworCQlzdGF0aWMgaW50IGNvdW50ID0gMDsKKwkJaWYgKCsrY291bnQgPCA1KSB7CisJ
CQlwcmludGsoS0VSTl9FUlIgIm1ha2VfemVyb19jb3B5X3NrYiBjYWxsZWQgbm9uYXRvbWljYWxs
eSAiCisJCQkgICAgICAgImZyb20gaW50ZXJydXB0ICVwXG4iLCBORVRfQ0FMTEVSKHNpemUpKTsK
KyAJCQkqKGludCopMCA9IDA7CisJCX0KKwkJZ2ZwX21hc2sgJj0gfl9fR0ZQX1dBSVQ7CisJfQor
CisJLyogR2V0IHRoZSBIRUFEICovCisJc2tiPSBza2JfaGVhZF9mcm9tX3Bvb2woKTsKKwlpZiAo
c2tiID09IE5VTEwpIHsKKwkJc2tiID0ga21lbV9jYWNoZV9hbGxvYyhza2J1ZmZfaGVhZF9jYWNo
ZSwgZ2ZwX21hc2spOworCQlpZiAoc2tiID09IE5VTEwpCisJCQlnb3RvIG5vaGVhZDsKKwl9CisJ
LyogWFhYOiBkb2VzIG5vdCBpbmNsdWRlIHNsYWIgb3ZlcmhlYWQgKi8gCisJc2tiLT50cnVlc2l6
ZSA9ICBzaXplICsgc2l6ZW9mKHN0cnVjdCBza19idWZmKTsKKworCisJLyogTG9hZCB0aGUgZGF0
YSBwb2ludGVycy4gKi8KKwlza2ItPmhlYWQgPSBkYXRhOworCXNrYi0+ZGF0YSA9IGRhdGE7CisJ
c2tiLT50YWlsID0gZGF0YTsKKwlza2ItPmVuZCA9IGRhdGEgKyBzaXplOworCisJLyogU2V0IHVw
IG90aGVyIHN0YXRlICovCisJc2tiLT5sZW4gPSAwOworCXNrYi0+aXNfY2xvbmUgPSAwOworCXNr
Yi0+Y2xvbmVkID0gMDsKKwlhdG9taWNfc2V0KCZza2ItPnVzZXJzLDEpOworCXNrYi0+cmVmY250
X3B0cj0memNfaGVhZGVyLT5yZWZjbnQ7CisJYXRvbWljX2luYyhza2ItPnJlZmNudF9wdHIpOwor
CXJldHVybiBza2I7Citub2hlYWQ6CisJcmV0dXJuIE5VTEw7Cit9CiAKIC8qIAlBbGxvY2F0ZSBh
IG5ldyBza2J1ZmYuIFdlIGRvIHRoaXMgb3Vyc2VsdmVzIHNvIHdlIGNhbiBmaWxsIGluIGEgZmV3
CiAgKgkncHJpdmF0ZScgZmllbGRzIGFuZCBhbHNvIGRvIG1lbW9yeSBzdGF0aXN0aWNzIHRvIGZp
bmQgYWxsIHRoZQpAQCAtMjA1LDcgKzMwMyw4IEBACiAJc2tiLT5pc19jbG9uZSA9IDA7CiAJc2ti
LT5jbG9uZWQgPSAwOwogCi0JYXRvbWljX3NldCgmc2tiLT51c2VycywgMSk7IAorCWF0b21pY19z
ZXQoJnNrYi0+dXNlcnMsIDEpOworCXNrYi0+cmVmY250X3B0cj0oYXRvbWljX3QgKilza2ItPmVu
ZDsKIAlhdG9taWNfc2V0KHNrYl9kYXRhcmVmcChza2IpLCAxKTsKIAlyZXR1cm4gc2tiOwogCkBA
IC0yMjUsNiArMzI0LDcgQEAKIAlzdHJ1Y3Qgc2tfYnVmZiAqc2tiID0gcDsKIAogCXNrYi0+ZGVz
dHJ1Y3RvciA9IE5VTEw7CisJc2tiLT5yZWZjbnRfcHRyPU5VTEw7CiAJc2tiLT5wa3RfdHlwZSA9
IFBBQ0tFVF9IT1NUOwkvKiBEZWZhdWx0IHR5cGUgKi8KIAlza2ItPnByZXYgPSBza2ItPm5leHQg
PSBOVUxMOwogCXNrYi0+bGlzdCA9IE5VTEw7CkBAIC0yNDgsMTQgKzM0OCw0NSBAQAogCXNrYi0+
cHJpb3JpdHkgPSAwOwogfQogCisvKiBXZSBjYW4ndCB1c2UgYSBwcm9jZWR1cmUgcG9pbnRlciBh
cyBmcmVlX3BhZ2VzIGlzIGlubGluZSAqLwordm9pZCBza2JfZnJlZV9wYWdlcyh1bnNpZ25lZCBs
b25nIHBhZ2UsIHVuc2lnbmVkIGxvbmcgb3JkZXIpCit7CisJZnJlZV9wYWdlcyhwYWdlLG9yZGVy
KTsKK30KKwordm9pZCBrZnJlZV9za2JfYnVmZmVyKHN0cnVjdCBza19idWZmICpza2IpCit7CisJ
emVyb19jb3B5X2hlYWRlciAqemNfaGVhZGVyOworCWlmIChhdG9taWNfZGVjX2FuZF90ZXN0KHNr
Yl9kYXRhcmVmcChza2IpKSkgeworCQlpZigodW5zaWduZWQgY2hhciAqKXNrYl9kYXRhcmVmcChz
a2IpPT1za2ItPmVuZCkKKwkJCWtmcmVlKHNrYi0+aGVhZCk7CisJCWVsc2UgeworCQkJemNfaGVh
ZGVyPSh6ZXJvX2NvcHlfaGVhZGVyICopKChzaXplX3Qpc2tiX2RhdGFyZWZwKHNrYiktCisJCQkJ
b2Zmc2V0b2YoemVyb19jb3B5X2hlYWRlcixyZWZjbnQpKTsKKwkJCWlmKHpjX2hlYWRlci0+bWFn
aWM9PVpFUk9DT1BZX01BR0lDKQorCQkJeworCQkJCWlmKHpjX2hlYWRlci0+ZnJlZWZ1bmM9PSh6
ZXJvY29weV9mcmVlZnVuYylza2JfZnJlZV9wYWdlcykKKwkJCQkJc2tiX2ZyZWVfcGFnZXMoKHVu
c2lnbmVkIGxvbmcpemNfaGVhZGVyLAorCQkJCQkJICAgemNfaGVhZGVyLT5vcmRlcik7CisJCQkJ
ZWxzZQorCQkJCQl6Y19oZWFkZXItPmZyZWVmdW5jKHpjX2hlYWRlcik7CisJCQkJYXRvbWljX2Rl
YygmbmV0X3plcm9jb3B5X2J1ZmZlcnMpOworCQkJfQorCQkJZWxzZQorCQkJCXByaW50aygia2Zy
ZWVfc2tiX2J1ZmZlciBiYWQgWkVST0NPUFlfTUFHSUMgemNfaGVhZGVyPSVwIix6Y19oZWFkZXIp
OworCQl9CisJCQkKKwkJICAKKwl9Cit9CisKKwogLyoKICAqCUZyZWUgYW4gc2tidWZmIGJ5IG1l
bW9yeSB3aXRob3V0IGNsZWFuaW5nIHRoZSBzdGF0ZS4gCiAgKi8KIHZvaWQga2ZyZWVfc2tibWVt
KHN0cnVjdCBza19idWZmICpza2IpCiB7Ci0JaWYgKCFza2ItPmNsb25lZCB8fCBhdG9taWNfZGVj
X2FuZF90ZXN0KHNrYl9kYXRhcmVmcChza2IpKSkgIAotCQlrZnJlZShza2ItPmhlYWQpOwotCisJ
a2ZyZWVfc2tiX2J1ZmZlcihza2IpOwogCXNrYl9oZWFkX3RvX3Bvb2woc2tiKTsKIH0KIApAQCAt
MjY2LDYgKzM5NywxMiBAQAogICoJRnJlZSBhbiBza19idWZmLiBSZWxlYXNlIGFueXRoaW5nIGF0
dGFjaGVkIHRvIHRoZSBidWZmZXIuIAogICoJQ2xlYW4gdGhlIHN0YXRlLiBUaGlzIGlzIGFuIGlu
dGVybmFsIGhlbHBlciBmdW5jdGlvbi4gVXNlcnMgc2hvdWxkCiAgKglhbHdheXMgY2FsbCBrZnJl
ZV9za2IKKyAqCisgKiAgICAgIGtmcmVlX3NrYm1lbSBoYWQgdG8gYmUgc3BsaXQgaW50byB0d28g
ZnVuY3Rpb25zIGJlY2F1c2UKKyAqICAgICAgc2tiX2hlYWRlcmluaXQgaGFkIHRvIGJlIGRvbmUg
YWZ0ZXIgdGhlIHplcm8gY29weSBidWZmZXIKKyAqICAgICAgZnJlZSAmIHB1dHRpbmcgc2tiX2hl
YWRlcmluaXQgYWZ0ZXIga2ZyZWVfc2tibWVtIHdhcworICogICAgICBjYXVzaW5nIHJhY2UgY29u
ZGl0aW9ucyBhcyB0aGUgbmV3bHkgZnJlZWQgdXAgc2tfYnVmZgorICogICAgICBkaWRuJ3QgaGF2
ZSBpdHMgaGVhZCAmIHRhaWwgcG9pbnRlciBpbml0aWFsaXNlZCBESkIuCiAgKi8KIAogdm9pZCBf
X2tmcmVlX3NrYihzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQpAQCAtMjkwLDkgKzQyNywxMCBAQAogI2lm
ZGVmIENPTkZJR19ORVQJCQogCWlmKHNrYi0+cnhfZGV2KQogCQlkZXZfcHV0KHNrYi0+cnhfZGV2
KTsKLSNlbmRpZgkJCisjZW5kaWYKKwlrZnJlZV9za2JfYnVmZmVyKHNrYik7CiAJc2tiX2hlYWRl
cmluaXQoc2tiLCBOVUxMLCAwKTsgIC8qIGNsZWFuIHN0YXRlICovCi0Ja2ZyZWVfc2tibWVtKHNr
Yik7CisJc2tiX2hlYWRfdG9fcG9vbChza2IpOwogfQogCiAvKioKT25seSBpbiBsaW51eC5uZXcv
OiB6ZXJvX2NvcHlfc2tiMjUwNzAwLnBhdGNoCg==

--0__=HyYIJHhx6KIxINiNzhmNT2HdVN2xJrTxEQhDBJcAiTrUWRcrZfYvmPzZ--


From owner-netdev@oss.sgi.com Tue Jul 25 10:30:08 2000
Received:  by oss.sgi.com id <S42236AbQGYR36>;
	Tue, 25 Jul 2000 10:29:58 -0700
Received: from tazenda.demon.co.uk ([158.152.220.239]:49933 "EHLO
        tazenda.demon.co.uk") by oss.sgi.com with ESMTP id <S42210AbQGYR3f>;
	Tue, 25 Jul 2000 10:29:35 -0700
Received: from kings-cross.london.uk.eu.org [::ffff:192.168.2.83] 
	by tazenda.demon.co.uk with esmtp (Exim 3.11 #1 (Debian))
	id 13H7Wf-0000dq-00; Tue, 25 Jul 2000 17:25:49 +0100
Received: from localhost
	([::ffff:127.0.0.1] helo=tazenda.demon.co.uk ident=pb)
	by kings-cross.london.uk.eu.org with esmtp (Exim 3.12 #1 (Debian))
	id 13H7Ug-0002C0-00; Tue, 25 Jul 2000 17:23:46 +0100
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
To:     Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
cc:     netdev@oss.sgi.com
Subject: Re: SIOCGLIFCONF? 
In-Reply-To: Message from Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp> 
   of "Tue, 25 Jul 2000 23:38:52 +0900." <20000725233852K.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> 
References: <20000501000837W.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <20000501001640H.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <E13H52o-0001n8-00@kings-cross.london.uk.eu.org>  <20000725233852K.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 25 Jul 2000 17:23:45 +0100
From:   Philip Blundell <pb@tazenda.demon.co.uk>
Message-Id: <E13H7Ug-0002C0-00@kings-cross.london.uk.eu.org>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>Could you explain in in datail?

Before we can use your code you need to assign copyright to the FSF.  Please 
take a look at <http://gcc.gnu.org/contribute.html>; it explains how to do 
this, and most of the information there applies to glibc as well as to gcc.

I'm not familiar with the BSDI licence.  Someone will need to check that it is 
compatible with the GPL.

The code could also use some tidying up before it is incorporated into glibc.  
You should get rid of `config.h' and the ifdefs that go with it.  There is no 
need to test for glibc >= 2.1 since this code will go into 2.2.  Also, please 
reformat the C code according to the GNU coding standard.

Thanks

p.



From owner-netdev@oss.sgi.com Tue Jul 25 11:40:17 2000
Received:  by oss.sgi.com id <S42234AbQGYSkI>;
	Tue, 25 Jul 2000 11:40:08 -0700
Received: from smtp1.cern.ch ([137.138.128.38]:53005 "EHLO smtp1.cern.ch")
	by oss.sgi.com with ESMTP id <S42210AbQGYSjv>;
	Tue, 25 Jul 2000 11:39:51 -0700
Received: from lxplus015.cern.ch (IDENT:root@lxplus015.cern.ch [137.138.161.112])
	by smtp1.cern.ch (8.9.3/8.9.3) with ESMTP id UAA05834;
	Tue, 25 Jul 2000 20:39:26 +0200 (MET DST)
Received: (from jes@localhost)
	by lxplus015.cern.ch (8.9.3/8.9.3) id UAA19371;
	Tue, 25 Jul 2000 20:39:24 +0200
To:     DJBARROW@de.ibm.com
Cc:     netdev@oss.sgi.com
Subject: Re: zero copy skb enhancments.
References: <C1256927.005FBA38.00@d12mta09.de.ibm.com>
From:   Jes Sorensen <jes@linuxcare.com>
Date:   25 Jul 2000 20:39:24 +0200
In-Reply-To: DJBARROW@de.ibm.com's message of "Tue, 25 Jul 2000 19:25:32 +0200"
Message-ID: <d3d7k2836r.fsf@lxplus015.cern.ch>
Lines:  18
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.4
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

>>>>> ">" == DJBARROW  <DJBARROW@de.ibm.com> writes:

>> Did you receive the stuff yesterday ?,

>> Here is a minor fix to the patches I posted yesterday, I forgot to
>> add my new functions to kernel/ksyms.c in the last patch.

Your posting came through just fine.

I just setup a new mailing list for issues regarding kiobuf based I/O
after we had a lot of discussions on this topic at the Ottawa Linux
Symposium. A major issue will be zero copy networking using Stephen's
kiobuf design.

Mail linux-fastio-subscribe@sunsite.auc.dk to subscribe.

Jes


From owner-netdev@oss.sgi.com Tue Jul 25 13:29:59 2000
Received:  by oss.sgi.com id <S42244AbQGYU3j>;
	Tue, 25 Jul 2000 13:29:39 -0700
Received: from georgia-2.dsl.speakeasy.net ([216.254.93.178]:28147 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S42210AbQGYU3H>;
	Tue, 25 Jul 2000 13:29:07 -0700
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id QAA11003;
	Tue, 25 Jul 2000 16:30:41 -0400
Date:   Tue, 25 Jul 2000 16:30:41 -0400 (EDT)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     DJBARROW@de.ibm.com
cc:     netdev@oss.sgi.com
Subject: Re: zero copy skbuff.c enhancments
In-Reply-To: <C1256926.004E9D24.00@d12mta09.de.ibm.com>
Message-ID: <Pine.LNX.4.10.10007251514550.10034-100000@vaio.greennet>
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, 24 Jul 2000 DJBARROW@de.ibm.com wrote:

> I've written a patch for skbuff.c & skbuff.h which allows zero-copying of
> incoming network frames
> from network device drivers by using these new apis.

Everyone has a different idea of what zero copy copy is.
The rule seems to be "My code is zero copy", no matter how many copies it
takes.

Despite the rule, your scheme doesn't qualify as zero-copy.

> make_zero_copy_skb was added so network device drivers could take do
>  give the network layer data received without memcpying it,

This is pointless with most modern network cards, which almost always use
descriptor-based architecture.  The Linux drivers use this to receive
packets directly into preallocated, full-sized skbuffs.

You scheme has the driver receiving into a generic buffer, and then stuffing
the pointer into the skbuff.  This approach just adds overhead.

The only place this scheme would be useful at all is with the RTL8139.  The
RTL8139 receives directly into a linear receive ring, with packets written
one after another.  But
   - no one buys the rtl8139 for performance, just for the low cost
   - leaving packets on the small 32KB or 64KB receive ring will result in
     quickly running out of recieve space.
   - we already copy-and-checksum out of the receive ring to amortize the
     copy cost.

> under these circumstances anyway. The only case I can think of where they
> may not work
> is drivers depending on the 16 byte skb_reserve kludge in dev_alloc_skb.

I'm uncertain of which skb_reserve() you are referring to, but skb_reserve()
is often used for performance reasons.  For instance, the drivers use
skb_reserve(skb, 2) to longword- and cache-align the IP header. In some cases
the skbuff data section is offset to allow the chip to linearly write the Rx
status before the packet data in one PCI transaction.  With careful driver
construction each receive packet can be transferred in a single PCI burst
instead of four or more transactions that would otherwise be needed.


Doing true zero-copy receive would require the adapter to
  - verify the IP and TCP payload checksums
  - interpret the IP header and options
  - look up the proper socket
  - verify that this data segment is next in order
  - look up the destination region.
    If the application hasn't done a socket read, you lose.
  - look up the physical page in the page table, doing proper lockin
    If the application has done a read, but the page doesn't exist, you lose.
  - lock the socket.
  - wire down the destination pages
  - copy the data to the user application pages
  - unwire the pages, update the socket info, unlock the socket

I've missed a few steps here, but this is the general idea.  Some of the
steps could be simplifed with the adapter handling the protocol stack, but
handling initialization and exceptions must still be done by the main
processor.  So many of these operations are on likely-cached data structures
that having an adapter do zero-copy on receive is just a loss.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf Clusters / Linux Installations
Annapolis MD 21403


From owner-netdev@oss.sgi.com Wed Jul 26 10:04:55 2000
Received:  by oss.sgi.com id <S42223AbQGZREq>;
	Wed, 26 Jul 2000 10:04:46 -0700
Received: from mailgate.rz.uni-karlsruhe.de ([129.13.64.97]:8964 "EHLO
        mailgate.rz.uni-karlsruhe.de") by oss.sgi.com with ESMTP
	id <S42210AbQGZREI>; Wed, 26 Jul 2000 10:04:08 -0700
Received: from workstation1a (isdn216-52.rz.uni-karlsruhe.de [129.13.216.52])
	by mailgate.rz.uni-karlsruhe.de with smtp (Exim 3.02 #2)
	id 13HUas-0006RG-00; Wed, 26 Jul 2000 19:03:42 +0200
From:   "Frank Dinies" <unom@rz.uni-karlsruhe.de>
To:     <netdev@oss.sgi.com>
Subject: TCP Implementation
Date:   Wed, 26 Jul 2000 19:03:52 +0200
Message-ID: <NDBBJEEJCLHFLGJHDHFMKEEGCAAA.unom@rz.uni-karlsruhe.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello,

my name is Frank Dinies and I study computer science in Karlsruhe.
At the moment I´m involved in a seminar dealing with the network
implementation
under Linux 2.4.0.
I would be very happy if there is some documentation available about the TCP
implementation.
I searched a lot in the web, but found nothing in more detail.

Thanks

Frank Dinies


From owner-netdev@oss.sgi.com Wed Jul 26 11:53:16 2000
Received:  by oss.sgi.com id <S42223AbQGZSxG>;
	Wed, 26 Jul 2000 11:53:06 -0700
Received: from brutus.conectiva.com.br ([200.250.58.146]:9976 "HELO
        thor.distro.conectiva") by oss.sgi.com with SMTP id <S42210AbQGZSwm>;
	Wed, 26 Jul 2000 11:52:42 -0700
Received: by thor.distro.conectiva (Postfix, from userid 573)
	id 94D37EC40C; Wed, 26 Jul 2000 15:52:16 -0300 (BRST)
Date:   Wed, 26 Jul 2000 15:52:16 -0300
From:   Fabio Olive Leite <olive@conectiva.com.br>
To:     netdev@oss.sgi.com
Subject: [patch] in.tftpd and aliased interfaces
Message-ID: <20000726155216.M18562@conectiva.com.br>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="opJtzjQTFsWo+cga"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hi there,

I'm new to the list, but I think this might be the best place to send a
small patch to in.tftpd. It makes the server work over aliased interfaces,
which is usually necessary for high availability servers.

For example, when using two machines to serve tftp, controlled by
heartbeat, you have a "service" IP that heartbeat configures as an alias to
the real interface. So here I have the machine ha1, eth0 is 10.0.17.27, and
eth0:0 is 10.0.17.26, which is the "service" ip. The hostname ha translates
to the service IP.

What happens is that a client tries to download a kernel image from ha, but
since tftpd binds to inaddr_any, it ends up replying as 10.0.17.27, which
is not what the client expects. tcpdump shows requests going to 10.0.17.26,
and answers coming from 10.0.17.27. Obviously it does not work, since the
server keeps sending the same block, and the client keeps acking the block
it received. They don't really see each other...

If the server binds to 10.0.17.26, everything works ok. Since tftp uses
udp, we can't obtain (AFAIK, pleased to be proved wrong on this) the IP
that the client used to reach us and bind to that, so that things would
work fine without any odd changes. What I did to solve this is a small
patch that adds a "-b <ip>" option to in.tftpd, so that you can specify the
IP it should bind to. Marginal error handling is done and logged.

With this patch, setting up a highly available tftp server needs only a
small addition to the inetd line with the "-b <ip>" option. Whenever the
primary server goes down, heartbeat restarts the service (in this case
inetd) on the backup, which assumes the service IP. in.tftpd now binds to
that address when run, so clients don't see any change.

Anybody has comments or critics? I'm eager to hear them...

Regards
Fábio
-- 
( Fábio Olivé Leite -- Conectiva HA Team -- olive@conectiva.com.br )
(     PPGC/UFRGS MSc candidate  --  Advisor: Taisy Silva Weber     )
( Linux - Distributed Systems - Fault Tolerance - Security - Pizza )

--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tftp_ha.patch"

diff -ruN netkit-tftp-0.15.orig/tftpd/tftpd.c netkit-tftp-0.15/tftpd/tftpd.c
--- netkit-tftp-0.15.orig/tftpd/tftpd.c	Sun Aug  1 22:11:33 1999
+++ netkit-tftp-0.15/tftpd/tftpd.c	Wed Jul 26 14:48:16 2000
@@ -101,12 +101,24 @@
 	register struct tftphdr *tp;
 	register int n = 0;
 	int on = 1;
+	int bound = 0;
 
+	/* open the log earlier, to log supplied address errors */
+	openlog("tftpd", LOG_PID, LOG_DAEMON);
 	ac--; av++;
+	/* "-b ip.addr.ess" handling */
+	if (ac > 0 && !strncmp(av[0], "-b", 2)) {
+		if (inet_aton(av[1], &s_in.sin_addr) < 0) {
+			syslog(LOG_ERR, "inet_aton: %m\n");
+			exit(1);
+		}
+		ac-=2;
+		av+=2;
+		bound = 1;
+	}
 	if (ac==0) dirs[0] = "/tftpboot";  /* default directory */
 	while (ac-- > 0 && n < MAXARG)
 		dirs[n++] = *av++;
-	openlog("tftpd", LOG_PID, LOG_DAEMON);
 	if (ioctl(0, FIONBIO, &on) < 0) {
 		syslog(LOG_ERR, "ioctl(FIONBIO): %m\n");
 		exit(1);
@@ -191,6 +203,8 @@
 		syslog(LOG_ERR, "socket: %m\n");
 		exit(1);
 	}
+	if (bound)
+		syslog(LOG_NOTICE, "binding to address %s\n", inet_ntoa(s_in.sin_addr));
 	if (bind(peer, (struct sockaddr *)&s_in, sizeof (s_in)) < 0) {
 		syslog(LOG_ERR, "bind: %m\n");
 		exit(1);

--opJtzjQTFsWo+cga--

From owner-netdev@oss.sgi.com Wed Jul 26 20:21:17 2000
Received:  by oss.sgi.com id <S42234AbQG0DU5>;
	Wed, 26 Jul 2000 20:20:57 -0700
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:52235 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S42210AbQG0DU1>; Wed, 26 Jul 2000 20:20:27 -0700
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id MAA24001;
	Thu, 27 Jul 2000 12:19:14 +0900
To:     olive@conectiva.com.br
Cc:     netdev@oss.sgi.com
Subject: Re: [patch] in.tftpd and aliased interfaces
From:   Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) 
        <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <20000726155216.M18562@conectiva.com.br>
References: <20000726155216.M18562@conectiva.com.br>
X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000727121913T.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date:   Thu, 27 Jul 2000 12:19:13 +0900
X-Dispatcher: imput version 990905(IM130)
Lines:  13
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <20000726155216.M18562@conectiva.com.br> (at Wed, 26 Jul 2000 15:52:16 -0300), Fabio Olive Leite <olive@conectiva.com.br> says:

> If the server binds to 10.0.17.26, everything works ok. Since tftp uses
> udp, we can't obtain (AFAIK, pleased to be proved wrong on this) the IP
> that the client used to reach us and bind to that, so that things would
> work fine without any odd changes. What I did to solve this is a small

IP_PKTINFO for IPv4 / IPV6_PKTINFO for IPv6 ?

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@v6.linux.or.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Wed Jul 26 22:25:57 2000
Received:  by oss.sgi.com id <S42243AbQG0FZh>;
	Wed, 26 Jul 2000 22:25:37 -0700
Received: from magnus.cordef.net.pl ([212.160.102.222]:45319 "HELO
        kepler.agaran.6bone.pl") by oss.sgi.com with SMTP id <S42223AbQG0FZS>;
	Wed, 26 Jul 2000 22:25:18 -0700
Received: by kepler.agaran.6bone.pl (Postfix+IPv6, from userid 500)
	id 4D729BF43; Thu, 27 Jul 2000 07:24:28 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by kepler.agaran.6bone.pl (Postfix+IPv6) with ESMTP id 1F3FABF42
	for <netdev@oss.sgi.com>; Thu, 27 Jul 2000 07:24:27 +0200 (CEST)
Date:   Thu, 27 Jul 2000 07:24:26 +0200 (CEST)
From:   Maciej 'Agaran' Pijanka <agaran@agaran.6bone.pl>
To:     NetDevel List <netdev@oss.sgi.com>
Subject: Ipv6 problem..
Message-ID: <Pine.LNX.4.21.0007270712030.10259-100000@kepler.agaran.6bone.pl>
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

Hello

i have nice 486 as testing machine, no ipv4 on interfaces (exept lo)
and after some time it dont see another machine - gw, at that moment rest
of machines (exept that one) is normally visible..and any other machine
may ping that which is not visible from test. Kernel recompile take loot
of time on that box..maybe any have idea what can help...
ifconfig down
and up + reassign adresses fixes problem
but it may happen 10 minutes later again..
could anyone point me what is wrong?


system is (if that is important):
ti486DX4/100 12Mram, 
EtherCard: DE205-AB (ewrk3.o as module)
Video Display: MDA
Kernel: 2.2.17pre13
Settings: ipv6.o as module
netlink support.

output of `ip -6 ro' dont change when problem happen
what more info should i supply

Best Regards

-- 
Maciej 'Agaran' Pijanka <agaran@agaran.6bone.pl>
i386, Linux 2.2, Pine, Slrn, Vi(m), IPv6, Gdb, 
I do not fear computers.  I fear the lack of them.
                -- Isaac Asimov


From owner-netdev@oss.sgi.com Thu Jul 27 05:42:19 2000
Received:  by oss.sgi.com id <S42222AbQG0MmJ>;
	Thu, 27 Jul 2000 05:42:09 -0700
Received: from d12lmsgate-3.de.ibm.com ([195.212.91.201]:31405 "EHLO convert rfc822-to-8bit
        d12lmsgate-3.de.ibm.com") by oss.sgi.com with ESMTP
	id <S42211AbQG0Mlg>; Thu, 27 Jul 2000 05:41:36 -0700
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id OAA15304;
	Thu, 27 Jul 2000 14:40:28 +0200
From:   DJBARROW@de.ibm.com
Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1])
	by d12relay01.de.ibm.com (8.8.8m3/NCO v4.92) with SMTP id OAA127052;
	Thu, 27 Jul 2000 14:40:26 +0200
Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id C1256929.00458C24 ; Thu, 27 Jul 2000 14:39:38 +0200
X-Lotus-FromDomain: IBMDE
To:     netdev@oss.sgi.com, Donald Becker <becker@scyld.com>
cc:     ADLUNG@de.ibm.com, utz.bacher@de.ibm.com
Message-ID: <C1256929.00458ADA.00@d12mta09.de.ibm.com>
Date:   Thu, 27 Jul 2000 14:39:33 +0200
Subject: Zero copy suggestion
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: 8BIT
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



Hi Donald,

Owing to your previous responses & arguments
I accept my patches are a little S/390 specific unfortunately.

Would it aid their acceptance if I #ifdeffed the stuff
CONFIG_ZERO_COPY_READS.
This way I would be preventing the stack becoming bloatware.


D.J. Barrow Linux for S/390 kernel developer
eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen



From owner-netdev@oss.sgi.com Thu Jul 27 09:46:30 2000
Received:  by oss.sgi.com id <S42248AbQG0QqK>;
	Thu, 27 Jul 2000 09:46:10 -0700
Received: from d12lmsgate.de.ibm.com ([195.212.91.199]:64134 "EHLO convert rfc822-to-8bit
        d12lmsgate.de.ibm.com") by oss.sgi.com with ESMTP id <S42246AbQG0Qp4>;
	Thu, 27 Jul 2000 09:45:56 -0700
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA127814;
	Thu, 27 Jul 2000 18:45:25 +0200
From:   DJBARROW@de.ibm.com
Received: from d12mta09.de.ibm.com (d12mta09_cs0 [9.165.223.1])
	by d12relay01.de.ibm.com (8.8.8m3/NCO v4.92) with SMTP id SAA195042;
	Thu, 27 Jul 2000 18:45:18 +0200
Received: by d12mta09.de.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id C1256929.005C07CF ; Thu, 27 Jul 2000 18:45:13 +0200
X-Lotus-FromDomain: IBMDE
To:     Donald Becker <becker@scyld.com>, netdev@oss.sgi.com
cc:     utz.bacher@de.ibm.com
Message-ID: <C1256929.005C070C.00@d12mta09.de.ibm.com>
Date:   Thu, 27 Jul 2000 18:45:07 +0200
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: 8BIT
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



Hi hopefully this will clarify a few open questions,

>>under these circumstances anyway. The only case I can think of where they
>>may not work
>is drivers depending on the 16 byte skb_reserve kludge in dev_alloc_skb.

>I'm uncertain of which skb_reserve() you are referring to, but
skb_reserve()
>is often used for performance reasons.  For instance, the drivers use
>skb_reserve(skb, 2) to longword- and cache-align the IP header. In some
cases
>the skbuff data section is offset to allow the chip to linearly write the
Rx
>status before the packet data in one PCI transaction.  With careful driver
>construction each receive packet can be transferred in a single PCI burst
>instead of four or more transactions that would otherwise be needed.

Wrt the skb_reserve kludge this is what I was referring to.

static inline struct sk_buff *dev_alloc_skb(unsigned int length)
{    struct sk_buff *skb;
     skb = alloc_skb(length+16, GFP_ATOMIC);  /* Kludge inserted here :-)
*/
     if (skb)
          skb_reserve(skb,16);
     return skb;
}

I'm getting tons of recommendations to join a linux-fastio mailing list, I
think I'm on enough of the things.

I'll call the functions one_less_copy_skb if it makes people happier.

The fact remains that because we S/390 network interfaces give us multiple
network frames in one read buffer
 We don't even know how many network frames we will receive until we get
the buffer from the cards.
We can't allocate our single skb beforehand & point the card at the buffer.

In short whatever wonderful things are being done with kiobuffs for 2.5 we
have to continue our memcpying
into post allocated skb's unless we have a mechanism of converting a single
large buffer into multiple skbs
in an arbitrary fashion & giving it to the upper network layers as done in
the code I posted.



D.J. Barrow Linux for S/390 kernel developer
eMail: djbarrow@de.ibm.com,barrow_dj@yahoo.com
Phone: +49-(0)7031-16-2583
IBM Germany Lab, Schönaicherstr. 220, 71032 Böblingen



From owner-netdev@oss.sgi.com Thu Jul 27 10:03:00 2000
Received:  by oss.sgi.com id <S42250AbQG0RCu>;
	Thu, 27 Jul 2000 10:02:50 -0700
Received: from ausmtp02.au.ibm.COM ([202.135.136.105]:54279 "EHLO
        ausmtp02.au.ibm.com") by oss.sgi.com with ESMTP id <S42236AbQG0RCZ>;
	Thu, 27 Jul 2000 10:02:25 -0700
Received: from f03n07e.au.ibm.com 
	by ausmtp02.au.ibm.com (IBM AP 1.0) with ESMTP id CAA213440
	for <netdev@oss.sgi.com>; Fri, 28 Jul 2000 02:55:49 +1000
From:   rsharada@in.ibm.com
Received: from d73mta05.au.ibm.com (f06n05s [9.185.166.67])
	by f03n07e.au.ibm.com (8.8.8m3/NCO v4.92) with SMTP id DAA25902
	for <netdev@oss.sgi.com>; Fri, 28 Jul 2000 03:01:42 +1000
Received: by d73mta05.au.ibm.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id CA256929.005D8763 ; Fri, 28 Jul 2000 03:01:35 +1000
X-Lotus-FromDomain: IBMIN@IBMAU
To:     netdev@oss.sgi.com
Message-ID: <CA256929.005D7AAC.00@d73mta05.au.ibm.com>
Date:   Thu, 27 Jul 2000 19:12:21 +0530
Subject: ipv6 query
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello,
     I am pretty much new to this mailing list as well to linux as a
whole...but can somebody enlighten me on the progress that has been done
with respect to multicast routing and dhcpv6 implementation on linux for
ipv6? I tried to look out in a couple of sites, but did not get anything
substantial....any pointers or leads that anybody can provide would be
truly appreciated...
Thanks and Regards,
   R  Sharada
   IBM Global Services India Pvt. Ltd.
   Golden Enclave, Bangalore
   rsharada@in.ibm.com
   Ph: 526 7117 Extn:2554



From owner-netdev@oss.sgi.com Thu Jul 27 10:20:10 2000
Received:  by oss.sgi.com id <S42249AbQG0RUA>;
	Thu, 27 Jul 2000 10:20:00 -0700
Received: from csa.iisc.ernet.in ([144.16.67.8]:29459 "EHLO csa.iisc.ernet.in")
	by oss.sgi.com with ESMTP id <S42236AbQG0RTq>;
	Thu, 27 Jul 2000 10:19:46 -0700
Received: from venus.csa.iisc.ernet.in (IDENT:asarun@venus.csa.iisc.ernet.in [144.16.67.44])
	by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id WAA23190
	for <netdev@oss.sgi.com>; Thu, 27 Jul 2000 22:49:27 +0530
Received: from localhost (asarun@localhost)
	by venus.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id WAA00414
	for <netdev@oss.sgi.com>; Thu, 27 Jul 2000 22:49:05 +0530
X-Authentication-Warning: venus.csa.iisc.ernet.in: asarun owned process doing -bs
Date:   Thu, 27 Jul 2000 22:49:04 +0530 (IST)
From:   A S Arun <asarun@csa.iisc.ernet.in>
To:     netdev@oss.sgi.com
Message-ID: <Pine.LNX.3.96.1000727224837.367A-100000@venus.csa.iisc.ernet.in>
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


	I am trying to change the forwarding algorithm in the linux
kernel. i am using kernel version 2.2.12. i could find the place where the
route cache is searched, but i am unable to find where the search in the
fib table is taking place. can you please help me out. 

Also, is there any book on ip in linux kernel?

*******************************************************************************
				A.S.ARUN		

3rd Sem M.E.					Room No. D-3
Computer Science & Engineering			IISc Hostels 
Dept. of Computer Science & Automation			

			Indian Institute of Science			
			    Bangalore - 560012		
				   INDIA
*******************************************************************************



From owner-netdev@oss.sgi.com Thu Jul 27 10:42:09 2000
Received:  by oss.sgi.com id <S42246AbQG0Rl7>;
	Thu, 27 Jul 2000 10:41:59 -0700
Received: from nero.doit.wisc.edu ([128.104.17.130]:51720 "EHLO
        nero.doit.wisc.edu") by oss.sgi.com with ESMTP id <S42236AbQG0Rl3>;
	Thu, 27 Jul 2000 10:41:29 -0700
Received: (from jleu@localhost)
	by nero.doit.wisc.edu (8.8.7/8.8.7) id MAA12168;
	Thu, 27 Jul 2000 12:40:48 -0500
Message-ID: <20000727124048.D12108@doit.wisc.edu>
Date:   Thu, 27 Jul 2000 12:40:48 -0500
From:   "James R. Leu" <jleu@mindspring.com>
To:     A S Arun <asarun@csa.iisc.ernet.in>, netdev@oss.sgi.com
Subject: Re: your mail
Reply-To: jleu@mindspring.com
References: <Pine.LNX.3.96.1000727224837.367A-100000@venus.csa.iisc.ernet.in>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <Pine.LNX.3.96.1000727224837.367A-100000@venus.csa.iisc.ernet.in>; from A S Arun on Thu, Jul 27, 2000 at 10:49:04PM +0530
Organization: none
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Thu, Jul 27, 2000 at 10:49:04PM +0530, A S Arun wrote:
> 
> 	I am trying to change the forwarding algorithm in the linux
> kernel. i am using kernel version 2.2.12. i could find the place where the
> route cache is searched, but i am unable to find where the search in the
> fib table is taking place. can you please help me out. 

If you look in ip_route_input_slow() (packet bing routed from one interface to
another) or ip_route_output_slow() (packets originating at this box)
you will see a fib_lookup() which tries to match this packet's info to a
entry in the FIB.  Once an entry is found, a route cache entry is created
and stored in to the route cache (rt_intern_hash()).  All future
ip_route_input() or ip_route_output() will try to use the info from the
route cache for packets with similar characteristics.

Laters,
Jim
-- 
James R. Leu

From owner-netdev@oss.sgi.com Thu Jul 27 16:54:11 2000
Received:  by oss.sgi.com id <S42261AbQG0XyC>;
	Thu, 27 Jul 2000 16:54:02 -0700
Received: from storm.ca ([209.87.239.69]:32133 "EHLO mail.storm.ca")
	by oss.sgi.com with ESMTP id <S42222AbQG0Xxx>;
	Thu, 27 Jul 2000 16:53:53 -0700
Received: from storm.ca (ppp005.ottawa.storm.ca [209.87.238.5])
	by mail.storm.ca (8.9.3+Sun/8.9.3) with ESMTP id TAA04558;
	Thu, 27 Jul 2000 19:53:05 -0400 (EDT)
Message-ID: <3980CB8B.82C629BC@storm.ca>
Date:   Thu, 27 Jul 2000 19:53:47 -0400
From:   Sandy Harris <sandy@storm.ca>
Organization: Global Village Idiots
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To:     A S Arun <asarun@csa.iisc.ernet.in>
CC:     netdev@oss.sgi.com
Subject: Re: 
References: <Pine.LNX.3.96.1000727224837.367A-100000@venus.csa.iisc.ernet.in>
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

A S Arun wrote:

> Also, is there any book on ip in linux kernel?

"Linux IP Stacks Commentary" for 2.0.34 kernel
ISBN 1-57610-470-2
Publisher's site: www.coriolis.com

From owner-netdev@oss.sgi.com Thu Jul 27 17:20:01 2000
Received:  by oss.sgi.com id <S42267AbQG1ATv>;
	Thu, 27 Jul 2000 17:19:51 -0700
Received: from m202-1-p13.warwick.net ([208.242.202.18]:12805 "EHLO
        circuit.moureaux.com") by oss.sgi.com with ESMTP id <S42222AbQG1ATn>;
	Thu, 27 Jul 2000 17:19:43 -0700
Received: from circuit.moureaux.com (IDENT:statux@localhost [127.0.0.1])
	by circuit.moureaux.com (8.9.3/8.9.3) with SMTP id UAA01659;
	Thu, 27 Jul 2000 20:19:16 -0400
Date:   Thu, 27 Jul 2000 20:19:16 -0400 (EDT)
From:   Statux <statux@bigfoot.com>
X-Sender: statux@circuit.moureaux.com
To:     Sandy Harris <sandy@storm.ca>
cc:     A S Arun <asarun@csa.iisc.ernet.in>, netdev@oss.sgi.com
Subject: Re: 
In-Reply-To: <3980CB8B.82C629BC@storm.ca>
Message-ID: <Pine.LNX.3.96.1000727201911.1654A-100000@circuit.moureaux.com>
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

old kernel :/

On Thu, 27 Jul 2000, Sandy Harris wrote:

> A S Arun wrote:
> 
> > Also, is there any book on ip in linux kernel?
> 
> "Linux IP Stacks Commentary" for 2.0.34 kernel
> ISBN 1-57610-470-2
> Publisher's site: www.coriolis.com
> 


From owner-netdev@oss.sgi.com Fri Jul 28 03:05:25 2000
Received:  by oss.sgi.com id <S42222AbQG1KFF>;
	Fri, 28 Jul 2000 03:05:05 -0700
Received: from csa.iisc.ernet.in ([144.16.67.8]:31240 "EHLO csa.iisc.ernet.in")
	by oss.sgi.com with ESMTP id <S42218AbQG1KEn>;
	Fri, 28 Jul 2000 03:04:43 -0700
Received: from venus.csa.iisc.ernet.in (IDENT:asarun@venus.csa.iisc.ernet.in [144.16.67.44])
	by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA30259;
	Fri, 28 Jul 2000 15:34:51 +0530
Received: from localhost (asarun@localhost)
	by venus.csa.iisc.ernet.in (8.9.3/8.9.3) with SMTP id PAA14608;
	Fri, 28 Jul 2000 15:34:30 +0530
X-Authentication-Warning: venus.csa.iisc.ernet.in: asarun owned process doing -bs
Date:   Fri, 28 Jul 2000 15:34:30 +0530 (IST)
From:   A S Arun <asarun@csa.iisc.ernet.in>
To:     "James R. Leu" <jleu@mindspring.com>
cc:     netdev@oss.sgi.com
Subject: Re: your mail
In-Reply-To: <20000727124048.D12108@doit.wisc.edu>
Message-ID: <Pine.LNX.3.96.1000728151839.14440A-100000@venus.csa.iisc.ernet.in>
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

Sir,
	Thank you very much for your reply. I have some more doubts.
(1)
unsigned char tb_data[0]; 
	last line of struct fib_table in ip_fib.h

and then, 
  struct fn_zone *fz;  
  struct fn_hash *t = (struct fn_hash*)tb->tb_data; 
  for (fz = t->fn_zone_list; fz; fz = fz->fz_next)............. 
  
	in fn_hash_lookup in fib_hash.c

tb->tb_data is assigned value in only one place 
 memset(tb->tb_data, 0, sizeof(struct fn_hash));
	
	in fib_hash_init at the end of fib_hash.c

i am not able to understand how does t->fn_zone_list contain any valid
data?

(2) in route.c, there is a structure and also a inline function by name
fn_hash. 

(3) there are 2 functions fib_lookup, one in fib_rules.c and another in
ip_fib.h.




From owner-netdev@oss.sgi.com Fri Jul 28 07:58:47 2000
Received:  by oss.sgi.com id <S42233AbQG1O6h>;
	Fri, 28 Jul 2000 07:58:37 -0700
Received: from mail.inconnect.com ([209.140.64.7]:40433 "HELO
        mail.inconnect.com") by oss.sgi.com with SMTP id <S42218AbQG1O6R>;
	Fri, 28 Jul 2000 07:58:17 -0700
Received: (qmail 26291 invoked from network); 28 Jul 2000 14:58:17 -0000
Received: from ultra1.inconnect.com (209.140.64.2)
  by mail with SMTP; 28 Jul 2000 14:58:17 -0000
Date:   Fri, 28 Jul 2000 08:58:17 -0600 (MDT)
From:   Keyshaun <thekernel@subdimension.com>
X-Sender: kruger@ultra1.inconnect.com
To:     Linux Netdev <netdev@oss.sgi.com>
Subject: Net interfeces.
Message-ID: <Pine.SOL.4.21.0007280852260.10802-100000@ultra1.inconnect.com>
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

I am in the early design phase of some high speed fiber products.  I know
that I can get a 155Mbit connection to work, but how realistic is it to
run a 2.5Gbit connection with an embedded linux system doing
routing?  Should I write my won embedded OS that only does routing and use
an embedded 486 off to the side to controll it?  Any comments on how to
take 2.5Gbit and handel it real time with frame switching and routing
would be appreciated.  

Shaun Kruger
thekernel@subdimension.com


From owner-netdev@oss.sgi.com Mon Jul 31 00:05:03 2000
Received:  by oss.sgi.com id <S42286AbQGaHEx>;
	Mon, 31 Jul 2000 00:04:53 -0700
Received: from titan.bieringer.de ([195.226.187.62]:56331 "HELO
        titan.bieringer.de") by oss.sgi.com with SMTP id <S42270AbQGaHE3>;
	Mon, 31 Jul 2000 00:04:29 -0700
Received: (qmail 24067 invoked by uid 89); 31 Jul 2000 07:04:16 -0000
Received: from p3e9ecb26.dip.t-dialin.net (62.158.203.38)
  by mail.bieringer.de with POP3 XMIT; 31 Jul 2000 07:04:16 -0000
Message-Id: <3.0.6.32.20000731090543.0083b670@mail2.bieringer.de>
X-URL:  http://www.bieringer.de/pb/
X-Sender: peter@mail2.bieringer.de
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date:   Mon, 31 Jul 2000 09:05:43 +0200
To:     netdev@oss.sgi.com
From:   Peter Bieringer <pb@bieringer.de>
Subject: Q: When will "ip_forward per interface" flag in /proc used?
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

Hi,

surly a dump question, but a look into the source code gave me no answer.

There exists in newer kernel 2.1.9x+(?) an IP forwarding switch
(all/default/per device)

My question is now, when will the information "per interface" used:

( ) decide forwarding packets coming *from* this interface
( ) decide forwarding packets sending *to* this interface
( ) in both cases

TIA,
	Peter



From owner-netdev@oss.sgi.com Mon Jul 31 01:22:54 2000
Received:  by oss.sgi.com id <S42270AbQGaIWo>;
	Mon, 31 Jul 2000 01:22:44 -0700
Received: from luna.tlmat.unican.es ([193.144.186.2]:23301 "EHLO
        luna.tlmat.unican.es") by oss.sgi.com with ESMTP id <S42233AbQGaIW3>;
	Mon, 31 Jul 2000 01:22:29 -0700
Received: from centauro (lira.tlmat.unican.es [193.144.186.27]) by luna.tlmat.unican.es with SMTP (8.7.6/8.7.1) id KAA03087 for <netdev@oss.sgi.com>; Mon, 31 Jul 2000 10:38:23 +0200 (METDST)
Message-ID: <010b01bffac8$a20fa240$1bba90c1@tlmat.unican.es>
From:   =?iso-8859-1?B?UmFt824gQWf8ZXJv?= <ramon@tlmat.unican.es>
To:     <netdev@oss.sgi.com>
Subject: TCP/IP implementation
Date:   Mon, 31 Jul 2000 10:23:40 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0108_01BFFAD9.6533BD00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0108_01BFFAD9.6533BD00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

    Hi,

        Alan Cox has given me your address, so I will reply the question =
that I asked him...

    I am working within ip implementation in 2.2.14 kernel, and I would =
like to ask you some questions...

    First of all, I have analized the source code for almost all the ip =
implementation, and I'm able to see every function definition, but I =
can't find where these functions are called (if they really are). As an =
example, I have my Linux box configured with uip_forwarding, and I have =
analized the ip`_forward.c  code. It seems that the function which =
really performs the forwarding is ip_forward. What I haven=B4t been able =
to discover is where this function is called from..

    I would be really grateful if you gave me some piece of advice.

    May you recommend me some source of information (book, web =
resources,...) in which I could find what I need?

    Thank you so much in advance...


------=_NextPart_000_0108_01BFFAD9.6533BD00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Alan Cox has =
given me=20
your address, so I will reply the question that I asked =
him...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>&nbsp;<FONT color=3D#0000ff><EM>&nbsp;&nbsp; I am =
working within=20
ip implementation in 2.2.14 kernel, and I would like to ask you some=20
questions...</EM></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><EM><FONT color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp; First of all, =
I have=20
analized the source code for almost all the ip implementation, and I'm =
able to=20
see every function definition, but I can't find where these functions =
are called=20
(if they really are). As an example, I have my Linux box configured with =

uip_forwarding, and I have analized the ip`_forward.c&nbsp; code. It =
seems that=20
the function which really performs the forwarding is ip_forward. What I =
haven=B4t=20
been able to discover is where this function is called =
from..</FONT></EM></DIV>
<DIV>&nbsp;</DIV>
<DIV><EM><FONT color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp; I would be =
really=20
grateful if you gave me some piece of advice.</FONT></EM></DIV>
<DIV>&nbsp;</DIV>
<DIV><EM><FONT color=3D#0000ff size=3D2>&nbsp;&nbsp;&nbsp; May you =
recommend me some=20
source of information (book, web resources,...) in which I could find =
what I=20
need?</FONT></EM></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff size=3D2><EM>&nbsp;&nbsp;&nbsp; Thank you so =
much in=20
advance...</EM></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0108_01BFFAD9.6533BD00--


From owner-netdev@oss.sgi.com Mon Jul 31 03:50:15 2000
Received:  by oss.sgi.com id <S42290AbQGaKuF>;
	Mon, 31 Jul 2000 03:50:05 -0700
Received: from garm.bart.nl ([194.158.170.13]:38415 "EHLO garm.bart.nl")
	by oss.sgi.com with ESMTP id <S42233AbQGaKtr>;
	Mon, 31 Jul 2000 03:49:47 -0700
Received: from daemon.ninth-circle.org (daemon.ninth-circle.org [195.38.210.81])
	by garm.bart.nl (8.10.1/8.10.1) with ESMTP id e6VAn1E33917;
	Mon, 31 Jul 2000 12:49:09 +0200 (CEST)
Received: (from asmodai@localhost)
	by daemon.ninth-circle.org (8.9.3/8.9.3) id MAA34844;
	Mon, 31 Jul 2000 12:48:31 +0200 (CEST)
	(envelope-from asmodai)
Date:   Mon, 31 Jul 2000 12:48:30 +0200
From:   Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
To:     =?iso-8859-1?Q?Ram=F3n_Ag=FCero?= <ramon@tlmat.unican.es>
Cc:     netdev@oss.sgi.com
Subject: Re: TCP/IP implementation
Message-ID: <20000731124830.D32129@daemon.ninth-circle.org>
References: <010b01bffac8$a20fa240$1bba90c1@tlmat.unican.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i
In-Reply-To: <010b01bffac8$a20fa240$1bba90c1@tlmat.unican.es>; from ramon@tlmat.unican.es on Mon, Jul 31, 2000 at 10:23:40AM +0200
Organisation: Ninth-Circle Enterprises
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

[mailwrapping recovered by gratatious use of gq]

-On [20000731 10:47], Ramón Agüero (ramon@tlmat.unican.es) wrote:
>    First of all, I have analized the source code for almost all the ip
>implementation, and I'm able to see every function definition, but I
>can't find where these functions are called (if they really are).  As
>an example, I have my Linux box configured with uip_forwarding, and I
>have analized the ip`_forward.c  code. It seems that the function which
>really performs the forwarding is ip_forward. What I haven´t been able
>to discover is where this function is called from..

You could try indexing your source with glimpse, which should be readily
available as a rpm or deb or whatever package format you use.

HTH, HAND,

-- 
Jeroen Ruigrok vd Werven/Asmodai    asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Abandon hope, all ye who enter here...

From owner-netdev@oss.sgi.com Mon Jul 31 07:41:36 2000
Received:  by oss.sgi.com id <S42293AbQGaOlZ>;
	Mon, 31 Jul 2000 07:41:25 -0700
Received: from brutus.conectiva.com.br ([200.250.58.146]:60403 "HELO
        thor.distro.conectiva") by oss.sgi.com with SMTP id <S42233AbQGaOlG>;
	Mon, 31 Jul 2000 07:41:06 -0700
Received: by thor.distro.conectiva (Postfix, from userid 573)
	id 425BFEC40D; Mon, 31 Jul 2000 10:33:08 -0300 (BRST)
Date:   Mon, 31 Jul 2000 10:33:08 -0300
From:   Fabio Olive Leite <olive@conectiva.com.br>
To:     Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Cc:     netdev@oss.sgi.com
Subject: Re: [patch] in.tftpd and aliased interfaces
Message-ID: <20000731103308.E1677@conectiva.com.br>
References: <20000726155216.M18562@conectiva.com.br> <20000727121913T.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.2i
In-Reply-To: <20000727121913T.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>; from yoshfuji@ecei.tohoku.ac.jp on Thu, Jul 27, 2000 at 12:19:13PM +0900
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi there,

On Thu, Jul 27, 2000 at 12:19:13PM +0900, Hideaki YOSHIFUJI wrote:
) In article <20000726155216.M18562@conectiva.com.br> (at Wed, 26 Jul 2000 15:52:16 -0300), Fabio Olive Leite <olive@conectiva.com.br> says:
) 
) > If the server binds to 10.0.17.26, everything works ok. Since tftp uses
) > udp, we can't obtain (AFAIK, pleased to be proved wrong on this) the IP
) > that the client used to reach us and bind to that, so that things would
) > work fine without any odd changes. What I did to solve this is a small
) 
) IP_PKTINFO for IPv4 / IPV6_PKTINFO for IPv6 ?

Sorry, I don't get it. Are those sockoptions or ioctls I should use?

-- 
( Fábio Olivé Leite -- Conectiva HA Team -- olive@conectiva.com.br )
(     PPGC/UFRGS MSc candidate  --  Advisor: Taisy Silva Weber     )
( Linux - Distributed Systems - Fault Tolerance - Security - Pizza )

From owner-netdev@oss.sgi.com Mon Jul 31 07:54:35 2000
Received:  by oss.sgi.com id <S42295AbQGaOy0>;
	Mon, 31 Jul 2000 07:54:26 -0700
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:58630 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S42294AbQGaOyQ>; Mon, 31 Jul 2000 07:54:16 -0700
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id XAA08977;
	Mon, 31 Jul 2000 23:50:40 +0900
To:     olive@conectiva.com.br
Cc:     netdev@oss.sgi.com
Subject: Re: [patch] in.tftpd and aliased interfaces
From:   Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <20000731103308.E1677@conectiva.com.br>
References: <20000726155216.M18562@conectiva.com.br>
	<20000727121913T.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
	<20000731103308.E1677@conectiva.com.br>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000731235040C.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date:   Mon, 31 Jul 2000 23:50:40 +0900
X-Dispatcher: imput version 990905(IM130)
Lines:  13
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <20000731103308.E1677@conectiva.com.br> (at Mon, 31 Jul 2000 10:33:08 -0300), Fabio Olive Leite <olive@conectiva.com.br> says:

> ) IP_PKTINFO for IPv4 / IPV6_PKTINFO for IPv6 ?
> 
> Sorry, I don't get it. Are those sockoptions or ioctls I should use?

setsockopt(2).  Then, use recvmsg(2) and you can get the 
destination address through control messages (ancillary data).

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@v6.linux.or.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Mon Jul 31 13:01:31 2000
Received:  by oss.sgi.com id <S42286AbQGaUBL>;
	Mon, 31 Jul 2000 13:01:11 -0700
Received: from titan.bieringer.de ([195.226.187.62]:46353 "HELO
        titan.bieringer.de") by oss.sgi.com with SMTP id <S42245AbQGaUAu>;
	Mon, 31 Jul 2000 13:00:50 -0700
Received: (qmail 27230 invoked by uid 89); 31 Jul 2000 20:00:47 -0000
Received: from p3e9ec809.dip.t-dialin.net (62.158.200.9)
  by mail.bieringer.de with POP3 XMIT; 31 Jul 2000 20:00:47 -0000
Message-Id: <3.0.6.32.20000731220215.0081bc00@mail2.bieringer.de>
X-URL:  http://www.bieringer.de/pb/
X-Sender: peter@mail2.bieringer.de
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date:   Mon, 31 Jul 2000 22:02:15 +0200
To:     netdev@oss.sgi.com
From:   Peter Bieringer <pb@bieringer.de>
Subject: Bug? Kernel panic if a special IPv6 address is assigned to an
  interface
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

Hi,

Konstantin Agouros <Konstantin.Agouros@netage.de> sends me a hint and I
have reproduced this similar.

The szenario is stupid, but can be happen:

An IPv6 ready 2.2.16 kernel boots up without no additional IPv6 configuration

[root@gate internet]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:BF:06:AE:08
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::250:bfff:fe06:ae08/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:340638 errors:0 dropped:0 overruns:0 frame:0
          TX packets:494933 errors:0 dropped:0 overruns:0 carrier:0
          collisions:4288 txqueuelen:100
          Interrupt:9 Base address:0xf800


Konstantin has now assigned a second IPv6 address, and because of
mistyping/misthinking he used

ifconfig eth0 add fe90::250:bfff:fe06:ae08/10
                    ^
after a while, kernel crashes

I reproduced this in similar way, I've added an fe90::EUI address and
delete it few seconds after. Starting reboot, kernel crashes after changing
the runlevel to 6.

On another host on the link I've looked for IPv6 multicasts with tcpdump,
they are received in correct manner.

Can anyone also reproduce this? Does the output of kernel panic help?

Any hints?

TIA,
	Peter