From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 02:50:23 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id C871916A400;
	Sun, 21 Jan 2007 02:50:23 +0000 (UTC)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp
	[202.249.10.124])
	by mx1.freebsd.org (Postfix) with ESMTP id 957CB13C45B;
	Sun, 21 Jan 2007 02:50:23 +0000 (UTC)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from impact.jinmei.org (shuttle.wide.toshiba.co.jp
	[2001:200:1b1::35])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP
	id 2D88815267; Sun, 21 Jan 2007 11:28:55 +0900 (JST)
Date: Sun, 21 Jan 2007 11:28:52 +0900
Message-ID: <y7vmz4dm7tn.wl%jinmei@isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
In-Reply-To: <20070120214052.U82671@maildrop.int.zabbadoz.net>
References: <20070120192807.GA1326@sandvine.com>
	<yged559v3y8.wl%ume@mahoroba.org>
	<20070120214052.U82671@maildrop.int.zabbadoz.net>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: freebsd-net@freebsd.org, Ed Maste <emaste@phaedrus.sandvine.ca>,
	Hajimu UMEMOTO <ume@freebsd.org>
Subject: Re: inet_pton and oddly-formatted addresses
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 02:50:23 -0000

>>>>> On Sat, 20 Jan 2007 21:42:44 +0000 (UTC), 
>>>>> "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> said:

emaste> I think an address like 1.002.3.4 is bizarre, but is our inet_pton incorrect
emaste> in rejecting it?
>> 
>> The change was taken from BIND9.  The following is from BIND9's
>> CHANGES:
>> 
>> 935.	[bug]		inet_pton failed to reject leading zeros.

> well, maybe they were wrong? How does one get in contact with their
> bugs database these days? Is comp.protocols.dns.bind still a good
> place to discuss these things?

Or bind-users@isc.org.  And yes, I'd ask the question at some
BIND-specific list.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

p.s. 1.002.3.4 is "illegal" according to RFC3986, Section 3.2.2
(although it's specified in the context of a URI), so "what is legal"
is probably a controversial issue.

From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 05:11:04 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 4723016A400
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 05:11:04 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from moutng.kundenserver.de (moutng.kundenserver.de
	[212.227.126.179])
	by mx1.freebsd.org (Postfix) with ESMTP id CCE6613C457
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 05:11:01 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from [88.66.6.102] (helo=amd64.laiers.local)
	by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis),
	id 0ML29c-1H8Uyn3QaM-0006fF; Sun, 21 Jan 2007 06:11:00 +0100
From: Max Laier <max@love2party.net>
Organization: FreeBSD
To: freebsd-net@freebsd.org
Date: Sun, 21 Jan 2007 06:10:39 +0100
User-Agent: KMail/1.9.5
References: <20070120192807.GA1326@sandvine.com>
	<20070120214052.U82671@maildrop.int.zabbadoz.net>
	<y7vmz4dm7tn.wl%jinmei@isl.rdc.toshiba.co.jp>
In-Reply-To: <y7vmz4dm7tn.wl%jinmei@isl.rdc.toshiba.co.jp>
X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGd<hB5S>u+2];
	R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1462050.20htLLDccN";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200701210610.49958.max@love2party.net>
X-Provags-ID: kundenserver.de abuse@kundenserver.de
	login:61c499deaeeba3ba5be80f48ecc83056
Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>,
	Ed Maste <emaste@phaedrus.sandvine.ca>, Hajimu UMEMOTO <ume@freebsd.org>,
	JINMEI Tatuya / =?utf-8?q?=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89?=
	<jinmei@isl.rdc.toshiba.co.jp>
Subject: Re: inet_pton and oddly-formatted addresses
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 05:11:04 -0000

--nextPart1462050.20htLLDccN
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 21 January 2007 03:28, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=
=94=E5=93=89 wrote:
> >>>>> On Sat, 20 Jan 2007 21:42:44 +0000 (UTC),
> >>>>> "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> said:
>
> emaste> I think an address like 1.002.3.4 is bizarre, but is our
> inet_pton incorrect emaste> in rejecting it?
>
> >> The change was taken from BIND9.  The following is from BIND9's
> >> CHANGES:
> >>
> >> 935.	[bug]		inet_pton failed to reject leading zeros.
> >
> > well, maybe they were wrong? How does one get in contact with their
> > bugs database these days? Is comp.protocols.dns.bind still a good
> > place to discuss these things?
>
> Or bind-users@isc.org.  And yes, I'd ask the question at some
> BIND-specific list.
>
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, Toshiba Corp.
> 					jinmei@isl.rdc.toshiba.co.jp
>
> p.s. 1.002.3.4 is "illegal" according to RFC3986, Section 3.2.2
> (although it's specified in the context of a URI), so "what is legal"
> is probably a controversial issue.

Section 7.4 is rather clear about the scope of the definition of "dotted=20
notation" in 3.2.2. - i.e. it is limited to URIs. inet_aton gethostbyname=20
etc. are explicitly allowed to accept platform dependent representations.

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart1462050.20htLLDccN
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQBFsvXZXyyEoT62BG0RAh/2AJ0RqT8TCimmwZ9f1eTjGO0tOmHUggCeNqMb
/HTYhr5Dj7c8NrNC2p2+qLU=
=jGYx
-----END PGP SIGNATURE-----

--nextPart1462050.20htLLDccN--

From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 06:25:24 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id C579616A400
	for <net@freebsd.org>; Sun, 21 Jan 2007 06:25:24 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210])
	by mx1.freebsd.org (Postfix) with ESMTP id 4E2FB13C428
	for <net@freebsd.org>; Sun, 21 Jan 2007 06:25:24 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au
	[61.8.2.162])
	by mailout1.pacific.net.au (Postfix) with ESMTP id 00B145A0657
	for <net@freebsd.org>; Sun, 21 Jan 2007 17:25:22 +1100 (EST)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailproxy1.pacific.net.au (Postfix) with ESMTP id 7F15B8C02
	for <net@freebsd.org>; Sun, 21 Jan 2007 17:25:20 +1100 (EST)
Date: Sun, 21 Jan 2007 17:25:14 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@delplex.bde.org
To: net@freebsd.org
Message-ID: <20070121155510.C23922@delplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: 
Subject: slow writes on nfs with bge devices
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 06:25:24 -0000

nfs writes much less well with bge NICs than with other NICs (sk, fxp, xl,
even rl).  Sometimes writing a 20K source file from vi seems to take about
2 seconds instead of seeming to be instantaneous (this gets faster as the
system warms up).  Iozone shows the problem more reproducibly.  E.g.:

100Mbps fxp server -> 1Gbps bge 5701 client, udp:
%%%
 	IOZONE: Performance Test of Sequential File I/O  --  V1.16 (10/28/92)
 		By Bill Norcott

 	Operating System: FreeBSD -- using fsync()

IOZONE: auto-test mode

 	MB      reclen  bytes/sec written   bytes/sec read
 	1       512     1516885             291918639
 	1       1024    1158783             491354263
 	1       2048    1573651             715694105
 	1       4096    1223692             917431957
 	1       8192    729513              1097929467
 	2       512     1694809             281196631
 	2       1024    1379228             507917189
 	2       2048    1659521             789608264
 	2       4096    4606056             1064567574
 	2       8192    1142288             1318131028
 	4       512     1242214             298269971
 	4       1024    1853545             492110628
 	4       2048    2120136             742888430
 	4       4096    1896792             1121799065
 	4       8192    850210              1441812403
 	8       512     1563847             281422325
 	8       1024    1480844             492749552
 	8       2048    1658649             850165954
 	8       4096    2105283             1211348180
 	8       8192    2098425             1554875506
 	16      512     1508821             296842294
 	16      1024    1966239             527850530
 	16      2048    2036609             842656736
 	16      4096    1666138             1200594889
 	16      8192    2293378             1620824908 
Completed series of tests
%%%

Here bge barely reaches 10Mbps speeds (~1.2 MB/S) for writing.  Reading
is cached well and fast.  100Mbps xl on the same client with the same
server goes at full 100Mbps speed (11.77 MB/S for all file sizes
including larger ones since the disk is not the limit at 100Mbps).
1Gbps sk on a different client with the same server goes at full 100Nbps
speed.

Switching to tcp gives full 100 Mbps speed.  However, when the bge link
speed is reduced to 100Mbps, udp becomes about 10 times slower than the
above and tcp becomes about as slow as the above (maybe a bit faster, but
far below 11.77 MB/S).

bge is also slow at nfs serving:

1Gbps bge 5701 server -> 1Gbps sk client:
%%%

 	IOZONE: Performance Test of Sequential File I/O  --  V1.16 (10/28/92)
 		By Bill Norcott

 	Operating System: FreeBSD -- using fsync()

IOZONE: auto-test mode

 	MB      reclen  bytes/sec written   bytes/sec read
 	1       512     36255350            242114472
 	1       1024    3051699             413319147
 	1       2048    22406458            632021710
 	1       4096    22447700            851162198
 	1       8192    3522493             1047562648
 	2       512     3270779             48125247
 	2       1024    28992179            46693718
 	2       2048    5956380             753318255
 	2       4096    27616650            1053311658
 	2       8192    5573338             48290208
 	4       512     9004770             47435659
 	4       1024    9576276             45601645
 	4       2048    30348874            85116667
 	4       4096    8635673             86150049
 	4       8192    9356773             47100031
 	8       512     9762446             46424146
 	8       1024    10054027            58344604
 	8       2048    9197430             60253061
 	8       4096    15934077            59476759
 	8       8192    8765470             47647937
 	16      512     5670225             46239891
 	16      1024    9425169             45950990
 	16      2048    9833515             46242945
 	16      4096    14812057            51313693
 	16      8192    9203742             47648722 
Completed series of tests
%%%

Now the available bandwidth is 10 times larger and about 9/10 of it is
still not used, with a high variance.  For larger files, the variance is
lower and the average speed is about 10MB/S.  The disk can only do about
40MB/S and the slowest of the 1Gbps NICS (sk) can only sustain 80MB/S
through udp and about 50MB/S through tcp (it is limited by the 33 MHz
32-bit PCI bus and by being less smart than the bge interface). When the
bge NIC was on the system which is now the server with the fxp NIC, bge
and nfs worked unsurprisingly, just slower than I would have liked.  The
write speed was 20-30MB/S for large files and 30-40MB/S for medium-sized
files, with low variance.  This is the only configuration in which nfs/bge
worked as expected.

The problem is very old and not very hardware dependent.  Similar behaviour
happens when some of the following are changed:

OS -> FreeBSD-~5.2 or FreeBSD-6
hardware -> newer amd64 CPU (Turion X2) with 5705 (iozone output for this
             below) instead of old amd64 CPU with 5701.  The newer amd64
 	    normally runs an i386-SMP current kernel while the old amd64
 	    was running an amd64-UP current kernel in the above tests,
 	    but normally runs ~5.2 amd64-UP and behaves similarly with that.
 	    The combination that seemed to work right was an AthlonXP
 	    for the server with the same 5701 and any kernel.  The only
 	    strangeness with that was that current kernels gave a 5-10%
 	    slower nfs server despite giving a 30-90% larger packet rate
 	    for small packets.

 	IOZONE: Performance Test of Sequential File I/O  --  V1.16 (10/28/92)
 		By Bill Norcott

 	Operating System: FreeBSD -- using fsync()

100Mbps fxp server -> 1Gbps bge 5705 client:
%%%
IOZONE: auto-test mode

 	MB      reclen  bytes/sec written   bytes/sec read
 	1       512     2994400             185462027
 	1       1024    3074084             337817536
 	1       2048    2991691             576792985
 	1       4096    3074759             884740798
 	1       8192    3078019             1176892296
 	2       512     4262096             186709962
 	2       1024    2994468             339893080
 	2       2048    5112176             584846610
 	2       4096    4754187             909815165
 	2       8192    5100574             1212919611
 	4       512     5298715             187129017
 	4       1024    5302620             344445041
 	4       2048    4985597             590579630
 	4       4096    3703618             927711124
 	4       8192    5236177             1240896243
 	8       512     5142274             186899396
 	8       1024    6207933             345564808
 	8       2048    6162773             593088329
 	8       4096    6031445             936751120
 	8       8192    6072523             1224102288
 	16      512     5427113             186797193
 	16      1024    5065901             345544445
 	16      2048    5462338             595487384
 	16      4096    5256552             937013065
 	16      8192    5097101             1226320870 
Completed series of tests
%%%

rl on a system with 1/20 as much CPU is faster than this.

The problem doesn't seem to affect much besides writes on nfs.  The
bge 5701 works very well for most things.  It has a much better bus
interface than the 5705 and works even better after moving it to the
old amd64 system (it can now saturate 1Gbps where on the AthlonXP it
only got 3/4 of the way, while the 5705 only gets 1/4 of the way).
I've been working on minimising network latency and maximising packet
rate, and normally have very low network latency (60-80 uS for ping)
and fairly high packet rates.  The changes for this are not the caause
of the bug :-), since the behaviour is not affected by running kernels
without these changes or by sysctl''ing the changes to be null.  However,
the problem looks like ones caused by large latencies combined with
non-streaming protocols.  To write at just 11.77 MB/S, at least 8000
packets/second must be set from the client to the server.  Working
clients sustain this rate, but broken clients the rate is much lower
and not sustained:

Output from netstat -s 1 on server while writing a ~1GB file via 5701/udp:
%%%
             input        (Total)           output
    packets  errs      bytes    packets  errs      bytes colls
        900     0    1513334        142     0      33532     0
       1509     0    2564836        236     0      57368     0
       1647     0    2295802        259     0      51106     0
       1603     0    1502736        252     0      32926     0
       1055     0     637014        163     0      13938     0
        558     0    1542510         86     0      34340     0
        984     0     989854        155     0      21816     0
        864     0    1320786        135     0      38152     0
        883     0    1558060        165     0      34340     0
       1177     0    3780102        203     0      85850     0
       2087     0     954212        331     0      21210     0
       1187     0    1413568        190     0      31310     0
        650     0    3320604        101     0      75346     0
       1565     0    1706542        246     0      37976     0
       2055     0    2360620        329     0      52318     0
       1554     0    2416996        244     0      54226     0
       1402     0    2579894        220     0      58176     0
       1690     0     774488        267     0      16968     0
       1323     0    3690650        209     0      83830     0
        591     0    4519858         92     0     103110     0
%%%

There is no sign of any packet loss or switch problems.  Forcing
1000baseTX full-duplex has no effect.  Forcing 100baseTX full-duplex
makes the problem more obvious.  The mtu is 1500 throughout since
only bge-5701 and sk support jumbo frames and I want to use udp for
nfs.

5705/udp is better:
%%%
             input        (Total)           output
    packets  errs      bytes    packets  errs      bytes colls
       5209     0    6607758        846     0     151702     0
       4763     0    6684546        773     0     153520     0
       4758     0    6618498        769     0     151298     0
       3582     0    7057568        576     0     162498     0
       4935     0    5115068        800     0     116756     0
       4924     0    6622026        798     0     152802     0
       4095     0    6018462        657     0     137450     0
       4647     0    5270442        751     0     120594     0
       4673     0    5451948        758     0     123624     0
       2340     0    6001986        372     0     138168     0
       3750     0    6150610        604     0     140996     0
%%%

sk/udp works right:
%%%
             input        (Total)           output
    packets  errs      bytes    packets  errs      bytes colls
       8638     0   12384676       1440     0     293062     0
       8636     0   12415646       1439     0     293708     0
       8637     0   12415646       1441     0     293708     0
       8637     0   12415646       1439     0     293708     0
       8637     0   12417160       1440     0     293708     0
       8636     0   12413162       1439     0     293506     0
       8637     0   12414132       1439     0     293708     0
       8636     0   12417160       1440     0     293708     0
       8637     0   12415646       1439     0     293708     0
       8636     0   12417160       1440     0     293708     0
       8637     0   12414676       1439     0     293506     0
%%%

sk is under ~5.2 with latency/throughput/efficiency optimizations
that don't have much effect here.

Bruce

From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 07:09:45 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 6365916A401
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 07:09:45 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from moutng.kundenserver.de (moutng.kundenserver.de
	[212.227.126.179])
	by mx1.freebsd.org (Postfix) with ESMTP id D7C9C13C428
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 07:09:44 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from [88.66.6.102] (helo=amd64.laiers.local)
	by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis),
	id 0ML29c-1H8Wpb2P2E-0006eY; Sun, 21 Jan 2007 08:09:39 +0100
From: Max Laier <max@love2party.net>
Organization: FreeBSD
To: freebsd-net@freebsd.org
Date: Sun, 21 Jan 2007 08:09:19 +0100
User-Agent: KMail/1.9.5
References: <20070121155510.C23922@delplex.bde.org>
In-Reply-To: <20070121155510.C23922@delplex.bde.org>
X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGd<hB5S>u+2];
	R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart16990224.mgHh93Ab6g";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200701210809.27770.max@love2party.net>
X-Provags-ID: kundenserver.de abuse@kundenserver.de
	login:61c499deaeeba3ba5be80f48ecc83056
Cc: 
Subject: Re: slow writes on nfs with bge devices
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 07:09:45 -0000

--nextPart16990224.mgHh93Ab6g
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 21 January 2007 07:25, Bruce Evans wrote:
> nfs writes much less well with bge NICs than with other NICs (sk, fxp,

Do you use hardware checksumming on the bge?  There is an XXX in=20
bge_start_locked() that looks a bit suspicious to me.

> xl, even rl).  Sometimes writing a 20K source file from vi seems to
> take about 2 seconds instead of seeming to be instantaneous (this gets
> faster as the system warms up).  Iozone shows the problem more
> reproducibly.  E.g.:
>
> 100Mbps fxp server -> 1Gbps bge 5701 client, udp:
> %%%
>  	IOZONE: Performance Test of Sequential File I/O  --  V1.16 (10/28/92)
>  		By Bill Norcott
>
>  	Operating System: FreeBSD -- using fsync()
>
> IOZONE: auto-test mode
>
>  	MB      reclen  bytes/sec written   bytes/sec read
>  	1       512     1516885             291918639
>  	1       1024    1158783             491354263
>  	1       2048    1573651             715694105
>  	1       4096    1223692             917431957
>  	1       8192    729513              1097929467
>  	2       512     1694809             281196631
>  	2       1024    1379228             507917189
>  	2       2048    1659521             789608264
>  	2       4096    4606056             1064567574
>  	2       8192    1142288             1318131028
>  	4       512     1242214             298269971
>  	4       1024    1853545             492110628
>  	4       2048    2120136             742888430
>  	4       4096    1896792             1121799065
>  	4       8192    850210              1441812403
>  	8       512     1563847             281422325
>  	8       1024    1480844             492749552
>  	8       2048    1658649             850165954
>  	8       4096    2105283             1211348180
>  	8       8192    2098425             1554875506
>  	16      512     1508821             296842294
>  	16      1024    1966239             527850530
>  	16      2048    2036609             842656736
>  	16      4096    1666138             1200594889
>  	16      8192    2293378             1620824908
> Completed series of tests
> %%%
>
> Here bge barely reaches 10Mbps speeds (~1.2 MB/S) for writing.  Reading
> is cached well and fast.  100Mbps xl on the same client with the same
> server goes at full 100Mbps speed (11.77 MB/S for all file sizes
> including larger ones since the disk is not the limit at 100Mbps).
> 1Gbps sk on a different client with the same server goes at full
> 100Nbps speed.
>
> Switching to tcp gives full 100 Mbps speed.  However, when the bge link
> speed is reduced to 100Mbps, udp becomes about 10 times slower than the
> above and tcp becomes about as slow as the above (maybe a bit faster,
> but far below 11.77 MB/S).
>
> bge is also slow at nfs serving:
>
> 1Gbps bge 5701 server -> 1Gbps sk client:
> %%%
>
>  	IOZONE: Performance Test of Sequential File I/O  --  V1.16 (10/28/92)
>  		By Bill Norcott
>
>  	Operating System: FreeBSD -- using fsync()
>
> IOZONE: auto-test mode
>
>  	MB      reclen  bytes/sec written   bytes/sec read
>  	1       512     36255350            242114472
>  	1       1024    3051699             413319147
>  	1       2048    22406458            632021710
>  	1       4096    22447700            851162198
>  	1       8192    3522493             1047562648
>  	2       512     3270779             48125247
>  	2       1024    28992179            46693718
>  	2       2048    5956380             753318255
>  	2       4096    27616650            1053311658
>  	2       8192    5573338             48290208
>  	4       512     9004770             47435659
>  	4       1024    9576276             45601645
>  	4       2048    30348874            85116667
>  	4       4096    8635673             86150049
>  	4       8192    9356773             47100031
>  	8       512     9762446             46424146
>  	8       1024    10054027            58344604
>  	8       2048    9197430             60253061
>  	8       4096    15934077            59476759
>  	8       8192    8765470             47647937
>  	16      512     5670225             46239891
>  	16      1024    9425169             45950990
>  	16      2048    9833515             46242945
>  	16      4096    14812057            51313693
>  	16      8192    9203742             47648722
> Completed series of tests
> %%%
>
> Now the available bandwidth is 10 times larger and about 9/10 of it is
> still not used, with a high variance.  For larger files, the variance
> is lower and the average speed is about 10MB/S.  The disk can only do
> about 40MB/S and the slowest of the 1Gbps NICS (sk) can only sustain
> 80MB/S through udp and about 50MB/S through tcp (it is limited by the
> 33 MHz 32-bit PCI bus and by being less smart than the bge interface).
> When the bge NIC was on the system which is now the server with the fxp
> NIC, bge and nfs worked unsurprisingly, just slower than I would have
> liked.  The write speed was 20-30MB/S for large files and 30-40MB/S for
> medium-sized files, with low variance.  This is the only configuration
> in which nfs/bge worked as expected.
>
> The problem is very old and not very hardware dependent.  Similar
> behaviour happens when some of the following are changed:
>
> OS -> FreeBSD-~5.2 or FreeBSD-6
> hardware -> newer amd64 CPU (Turion X2) with 5705 (iozone output for
> this below) instead of old amd64 CPU with 5701.  The newer amd64
> normally runs an i386-SMP current kernel while the old amd64 was
> running an amd64-UP current kernel in the above tests, but normally
> runs ~5.2 amd64-UP and behaves similarly with that. The combination
> that seemed to work right was an AthlonXP for the server with the same
> 5701 and any kernel.  The only strangeness with that was that current
> kernels gave a 5-10% slower nfs server despite giving a 30-90% larger
> packet rate for small packets.
>
>  	IOZONE: Performance Test of Sequential File I/O  --  V1.16 (10/28/92)
>  		By Bill Norcott
>
>  	Operating System: FreeBSD -- using fsync()
>
> 100Mbps fxp server -> 1Gbps bge 5705 client:
> %%%
> IOZONE: auto-test mode
>
>  	MB      reclen  bytes/sec written   bytes/sec read
>  	1       512     2994400             185462027
>  	1       1024    3074084             337817536
>  	1       2048    2991691             576792985
>  	1       4096    3074759             884740798
>  	1       8192    3078019             1176892296
>  	2       512     4262096             186709962
>  	2       1024    2994468             339893080
>  	2       2048    5112176             584846610
>  	2       4096    4754187             909815165
>  	2       8192    5100574             1212919611
>  	4       512     5298715             187129017
>  	4       1024    5302620             344445041
>  	4       2048    4985597             590579630
>  	4       4096    3703618             927711124
>  	4       8192    5236177             1240896243
>  	8       512     5142274             186899396
>  	8       1024    6207933             345564808
>  	8       2048    6162773             593088329
>  	8       4096    6031445             936751120
>  	8       8192    6072523             1224102288
>  	16      512     5427113             186797193
>  	16      1024    5065901             345544445
>  	16      2048    5462338             595487384
>  	16      4096    5256552             937013065
>  	16      8192    5097101             1226320870
> Completed series of tests
> %%%
>
> rl on a system with 1/20 as much CPU is faster than this.
>
> The problem doesn't seem to affect much besides writes on nfs.  The
> bge 5701 works very well for most things.  It has a much better bus
> interface than the 5705 and works even better after moving it to the
> old amd64 system (it can now saturate 1Gbps where on the AthlonXP it
> only got 3/4 of the way, while the 5705 only gets 1/4 of the way).
> I've been working on minimising network latency and maximising packet
> rate, and normally have very low network latency (60-80 uS for ping)
> and fairly high packet rates.  The changes for this are not the caause
> of the bug :-), since the behaviour is not affected by running kernels
> without these changes or by sysctl''ing the changes to be null.=20
> However, the problem looks like ones caused by large latencies combined
> with non-streaming protocols.  To write at just 11.77 MB/S, at least
> 8000 packets/second must be set from the client to the server.  Working
> clients sustain this rate, but broken clients the rate is much lower
> and not sustained:
>
> Output from netstat -s 1 on server while writing a ~1GB file via
> 5701/udp: %%%
>              input        (Total)           output
>     packets  errs      bytes    packets  errs      bytes colls
>         900     0    1513334        142     0      33532     0
>        1509     0    2564836        236     0      57368     0
>        1647     0    2295802        259     0      51106     0
>        1603     0    1502736        252     0      32926     0
>        1055     0     637014        163     0      13938     0
>         558     0    1542510         86     0      34340     0
>         984     0     989854        155     0      21816     0
>         864     0    1320786        135     0      38152     0
>         883     0    1558060        165     0      34340     0
>        1177     0    3780102        203     0      85850     0
>        2087     0     954212        331     0      21210     0
>        1187     0    1413568        190     0      31310     0
>         650     0    3320604        101     0      75346     0
>        1565     0    1706542        246     0      37976     0
>        2055     0    2360620        329     0      52318     0
>        1554     0    2416996        244     0      54226     0
>        1402     0    2579894        220     0      58176     0
>        1690     0     774488        267     0      16968     0
>        1323     0    3690650        209     0      83830     0
>         591     0    4519858         92     0     103110     0
> %%%
>
> There is no sign of any packet loss or switch problems.  Forcing
> 1000baseTX full-duplex has no effect.  Forcing 100baseTX full-duplex
> makes the problem more obvious.  The mtu is 1500 throughout since
> only bge-5701 and sk support jumbo frames and I want to use udp for
> nfs.
>
> 5705/udp is better:
> %%%
>              input        (Total)           output
>     packets  errs      bytes    packets  errs      bytes colls
>        5209     0    6607758        846     0     151702     0
>        4763     0    6684546        773     0     153520     0
>        4758     0    6618498        769     0     151298     0
>        3582     0    7057568        576     0     162498     0
>        4935     0    5115068        800     0     116756     0
>        4924     0    6622026        798     0     152802     0
>        4095     0    6018462        657     0     137450     0
>        4647     0    5270442        751     0     120594     0
>        4673     0    5451948        758     0     123624     0
>        2340     0    6001986        372     0     138168     0
>        3750     0    6150610        604     0     140996     0
> %%%
>
> sk/udp works right:
> %%%
>              input        (Total)           output
>     packets  errs      bytes    packets  errs      bytes colls
>        8638     0   12384676       1440     0     293062     0
>        8636     0   12415646       1439     0     293708     0
>        8637     0   12415646       1441     0     293708     0
>        8637     0   12415646       1439     0     293708     0
>        8637     0   12417160       1440     0     293708     0
>        8636     0   12413162       1439     0     293506     0
>        8637     0   12414132       1439     0     293708     0
>        8636     0   12417160       1440     0     293708     0
>        8637     0   12415646       1439     0     293708     0
>        8636     0   12417160       1440     0     293708     0
>        8637     0   12414676       1439     0     293506     0
> %%%
>
> sk is under ~5.2 with latency/throughput/efficiency optimizations
> that don't have much effect here.
>
> Bruce
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart16990224.mgHh93Ab6g
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQBFsxGnXyyEoT62BG0RAnb8AJwKV9ZihIC9m3XiHwsJLrAcQBa6CQCdHrbD
T/L2QEOgFi2qQe5Jte2vKbU=
=iMtp
-----END PGP SIGNATURE-----

--nextPart16990224.mgHh93Ab6g--

From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 08:05:34 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id B26B016A400;
	Sun, 21 Jan 2007 08:05:34 +0000 (UTC)
	(envelope-from jhay@meraka.csir.co.za)
Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58])
	by mx1.freebsd.org (Postfix) with ESMTP id 9CD2413C442;
	Sun, 21 Jan 2007 08:05:33 +0000 (UTC)
	(envelope-from jhay@meraka.csir.co.za)
Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973)
	id 8EAE033C94; Sun, 21 Jan 2007 09:32:44 +0200 (SAST)
Date: Sun, 21 Jan 2007 09:32:44 +0200
From: John Hay <jhay@meraka.org.za>
To: "Bruce A. Mah" <bmah@freebsd.org>
Message-ID: <20070121073244.GA80811@zibbi.meraka.csir.co.za>
References: <20070120162936.GA18104@tomcat.kitchenlab.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070120162936.GA18104@tomcat.kitchenlab.org>
User-Agent: Mutt/1.4.2.1i
Cc: freebsd-net@freebsd.org
Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 08:05:34 -0000

On Sat, Jan 20, 2007 at 08:29:36AM -0800, Bruce A. Mah wrote:
> I'm observing a problem with IPv6 over gif(4) tunnels on 6.2-RELEASE
> and recent 6-STABLE, namely that I can't seem to be able to pass
> traffic over them.
> 
> Essentially, when I configure a gif interface like this:
> 
> # ifconfig gif0 inet6 aaaa:bbbb:cccc:dddd::1 aaaa:bbbb:cccc:dddd::2 prefixlen 128
> 
> the interface should add a host route to aaaa:bbbb:cccc:dddd::2
> through gif0.  This is necessary to be able to pass traffic over the
> tunnel, particularly since the source and destination addresses of the
> link don't need to have any relationship to each other.

I only have one IPv6 over IPv4/gif tunnel and ther I use only my side
of the address, something like this:

ifconfig gif0 inet6 2001:4200:ffff:5::2 prefixlen 64

And then bgp on top of this. It seems to work fine on -current built
after my change. 
 
> However, this route doesn't get installed on recent 6-STABLE.
> Therefore there is no way to get an IPv6 packet to the other end of
> the tunnel because there's no route for the destination.  The most
> obvious symptom is that I try to ping the other tunnel endpoint and
> get:
> 
> ping6: UDP connect: No route to host
> 
> I know this worked on RELENG_6 as of June 2006; my home firewall has
> been running this code for months without a hitch.  It doesn't work in
> 6.2-RC2 or 6.2-RELEASE (fresh CD installs on i386, GENERIC kernels),
> or this week's RELENG_6 (nanobsd on i386).
> 
> I somewhat suspect revs. 1.48.2.15 and 1.48.2.14 to
> src/sys/netinet/nd6.c.  If I locally revert these two changes (see
> diff below), IPv6 over gif(4) works again.
> 
> There's another workaround for people stuck in this situation and who
> aren't in a position to try this diff.  That is to manually install
> the host route like this:
> 
> # route add -host -inet6 aaaa:bbbb:cccc:dddd::2 -interface gif0 -nostatic -llinfo
> 
> Comments?

Well it seems that even my stuff does not always work perfectly with that
change (1.48.2.15), so maybe we should revert it and I will search for
yet other ways to make FreeBSD's IPv6 code to actually work for our stuff.

My "stuff" is a wireless IPv6 only network running in adhoc mode with
olsrd as the routing protocol. The problem is that all nodes on a subnet
cannot "see" each other, so olsrd needs to add routes to a node through
another node. Sometimes, just to complicate matters a little more, you
would want to have more than one network card in a host, all with the same
subnet address. (For instance on a high site, with sector antennas.)

The case that I found that still does not work reliably, is if olsrd add
the route and route is not immediately used, then the nd code will time
it out and remove it.

So, I guess if you guys think I should revert my stuff, just say so.

And if you have a solution for my problem, just say so too. :-)

> 
> Bruce.
> 
> Index: nd6.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v
> retrieving revision 1.48.2.16
> diff -u -r1.48.2.16 nd6.c
> --- nd6.c	29 Nov 2006 14:00:29 -0000	1.48.2.16
> +++ nd6.c	20 Jan 2007 16:15:28 -0000
> @@ -1316,7 +1316,7 @@
>  		callout_init(&ln->ln_timer_ch, 0);
>  
>  		/* this is required for "ndp" command. - shin */
> -		if (req == RTM_ADD && (rt->rt_flags & RTF_STATIC)) {
> +		if (req == RTM_ADD) {
>  		        /*
>  			 * gate should have some valid AF_LINK entry,
>  			 * and ln->ln_expire should have some lifetime


John
-- 
John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org

From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 10:53:25 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 9223B16A400
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 10:53:25 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72])
	by mx1.freebsd.org (Postfix) with ESMTP id 664D313C469
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 10:53:25 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-3.cisco.com with ESMTP; 21 Jan 2007 02:53:25 -0800
X-IronPort-AV: i="4.13,217,1167638400"; 
	d="scan'208"; a="458714517:sNHT44923732"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0LArOlG016243; 
	Sun, 21 Jan 2007 02:53:24 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0LArMUw013828;
	Sun, 21 Jan 2007 02:53:22 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 21 Jan 2007 02:53:21 -0800
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 21 Jan 2007 02:53:21 -0800
Message-ID: <45B345FD.7080001@cisco.com>
Date: Sun, 21 Jan 2007 05:52:45 -0500
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Andrew Gallatin <gallatin@cs.duke.edu>
References: <45B0D2E3.9050203@cisco.com>
	<17841.6943.770698.707214@grasshopper.cs.duke.edu>
In-Reply-To: <17841.6943.770698.707214@grasshopper.cs.duke.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jan 2007 10:53:21.0582 (UTC)
	FILETIME=[5DE9B4E0:01C73D4A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=947; t=1169376804;
	x=1170240804; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20kern_mbuf.c=20patch |Sender:=20;
	bh=jK0Xfv0MqZ2fkNObyMBejLj71papNNTcqiK8r1Tc0aE=;
	b=bJMVakYCrCbOLZJTsMglOaDhVoDbPQkDgPBQMHxnS9XGBoWQ3TPUoBLxo0E+mC6WHH2aUZ2/
	3rDilHgQDYxfC3ZySVi0QVykQu0EDcA6vsxh674e6M9pHvx4TnowB1tN;
Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim4002 verified; ); 
Cc: freebsd-net <freebsd-net@freebsd.org>
Subject: Re: kern_mbuf.c patch
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 10:53:25 -0000

Andrew Gallatin wrote:
> Randall Stewart writes:
>  >  	nmbclusters = 1024 + maxusers * 64;
>  > +        nmbjumbop   = 100 + (maxusers * 4);
> 
> The limit on page-size jumbos seems far too small.  Since the socket
> buffer code now uses page-sized jumbos, I'd expect to see its limit be
> the same as nmbclusters.
> 
> 
> Drew
> 
Drew:

Let me re-visit this .. I started real small on purpose.. so
folks would complain ;-)

How about if I calculate the number of pages the
nmbclusters use (I will go look in the UMA structures) and
then make it so the limit is the same number of pages
(scaled like nmbclusters) for each of the larger clusters..

Does that sound about right... (for 4k it would mean you
would have 1/2 as many as 2k... roughly.. depending
on the o/h of the uma system of course.. need to go
look at this).

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 12:25:44 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 522B616A402
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 12:25:44 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226])
	by mx1.freebsd.org (Postfix) with ESMTP id 1C77B13C45A
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 12:25:44 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au
	[61.8.2.162])
	by mailout2.pacific.net.au (Postfix) with ESMTP id 826E66E2BF;
	Sun, 21 Jan 2007 23:25:40 +1100 (EST)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailproxy1.pacific.net.au (Postfix) with ESMTP id 002D58C06;
	Sun, 21 Jan 2007 23:25:41 +1100 (EST)
Date: Sun, 21 Jan 2007 23:25:40 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@delplex.bde.org
To: Max Laier <max@love2party.net>
In-Reply-To: <200701210809.27770.max@love2party.net>
Message-ID: <20070121215054.C24780@delplex.bde.org>
References: <20070121155510.C23922@delplex.bde.org>
	<200701210809.27770.max@love2party.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net@freebsd.org
Subject: Re: slow writes on nfs with bge devices
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 12:25:44 -0000

On Sun, 21 Jan 2007, Max Laier wrote:

> On Sunday 21 January 2007 07:25, Bruce Evans wrote:
>> nfs writes much less well with bge NICs than with other NICs (sk, fxp,
>
> Do you use hardware checksumming on the bge?  There is an XXX in
> bge_start_locked() that looks a bit suspicious to me.

I use the default for that.  Wouldn't checksum problems show up as errors
somwhere?

>>> [excessive quoting deleted]

tcpdump shows a lot of intervals between nfs write requests of almost
exactly 10 mS (even with HZ = 1000, but more obvious with HZ = 100)
for the broken case, so the problem is apparently related to timeouts,
or timeouts are masking a larger problem.  (The average interval between
write requests needs to be about 683 uS to avoid wasting any bandwith.
fxp <-> fxp on the same network averages 708 uS.  fxp <-> bge 5701
averages 3981.)

Bruce

From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 19:33:56 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 2F5DC16A400
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 19:33:56 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from moutng.kundenserver.de (moutng.kundenserver.de
	[212.227.126.177])
	by mx1.freebsd.org (Postfix) with ESMTP id B9B2F13C455
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 19:33:55 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from [88.66.6.102] (helo=amd64.laiers.local)
	by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis),
	id 0ML25U-1H8iRo1z21-0005Fi; Sun, 21 Jan 2007 20:33:54 +0100
From: Max Laier <max@love2party.net>
Organization: FreeBSD
To: Bruce Evans <bde@zeta.org.au>
Date: Sun, 21 Jan 2007 20:32:58 +0100
User-Agent: KMail/1.9.5
References: <20070121155510.C23922@delplex.bde.org>
	<200701210809.27770.max@love2party.net>
	<20070121215054.C24780@delplex.bde.org>
In-Reply-To: <20070121215054.C24780@delplex.bde.org>
X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGd<hB5S>u+2];
	R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1595927.pzSa1nX3oL";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200701212033.34914.max@love2party.net>
X-Provags-ID: kundenserver.de abuse@kundenserver.de
	login:61c499deaeeba3ba5be80f48ecc83056
Cc: freebsd-net@freebsd.org
Subject: Re: slow writes on nfs with bge devices
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 19:33:56 -0000

--nextPart1595927.pzSa1nX3oL
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 21 January 2007 13:25, Bruce Evans wrote:
> On Sun, 21 Jan 2007, Max Laier wrote:
> > On Sunday 21 January 2007 07:25, Bruce Evans wrote:
> >> nfs writes much less well with bge NICs than with other NICs (sk,
> >> fxp,
> >
> > Do you use hardware checksumming on the bge?  There is an XXX in
> > bge_start_locked() that looks a bit suspicious to me.
>
> I use the default for that.  Wouldn't checksum problems show up as
> errors somwhere?

Did you look at the code in question?  It is concerned with fragmented=20
packet chains (which NFS over UDP usually generated) and only commits to=20
sending them, if there are enough descriptors available at once.  This=20
can easily explain burstyness.

Can you just try to disable the delayed checksums via "ifconfig -txcsum"? =
=20
Should be an easy enough test.

> >>> [excessive quoting deleted]
>
> tcpdump shows a lot of intervals between nfs write requests of almost
> exactly 10 mS (even with HZ =3D 1000, but more obvious with HZ =3D 100)
> for the broken case, so the problem is apparently related to timeouts,
> or timeouts are masking a larger problem.  (The average interval
> between write requests needs to be about 683 uS to avoid wasting any
> bandwith. fxp <-> fxp on the same network averages 708 uS.  fxp <-> bge
> 5701 averages 3981.)

See above, I really think that there is something about that if_start loop=
=20
that might be causing this.

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart1595927.pzSa1nX3oL
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQBFs8AOXyyEoT62BG0RAhh5AJ9gf9+sPSC4Eur4cxo3Qnm1xPGmFgCdFZn7
yecaaZcGElSbDiPS6zx3USA=
=4wpX
-----END PGP SIGNATURE-----

--nextPart1595927.pzSa1nX3oL--

From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 20:35:18 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id E7CA516A401;
	Sun, 21 Jan 2007 20:35:18 +0000 (UTC)
	(envelope-from dimitry@andric.com)
Received: from springbank.echomania.com (springbank.echomania.com
	[82.94.255.114])
	by mx1.freebsd.org (Postfix) with ESMTP id A1BDA13C455;
	Sun, 21 Jan 2007 20:35:18 +0000 (UTC)
	(envelope-from dimitry@andric.com)
Received: from localhost (localhost [127.0.0.1])
	by springbank.echomania.com (Postfix) with ESMTP id 5EB69A70C0;
	Sun, 21 Jan 2007 21:17:24 +0100 (CET)
Received: from springbank.echomania.com ([127.0.0.1])
	by localhost (springbank.echomania.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with LMTP id 27582-04-3; Sun, 21 Jan 2007 21:17:23 +0100 (CET)
Received: from [192.168.0.3] (tensor.andric.com [213.154.244.69])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by springbank.echomania.com (Postfix) with ESMTP id 43474A707D;
	Sun, 21 Jan 2007 21:17:23 +0100 (CET)
Message-ID: <45B3CA56.4040106@andric.com>
Date: Sun, 21 Jan 2007 21:17:26 +0100
From: Dimitry Andric <dimitry@andric.com>
User-Agent: Thunderbird 2.0b1 (Windows/20070106)
MIME-Version: 1.0
To: "Bruce A. Mah" <bmah@freebsd.org>
References: <20070120162936.GA18104@tomcat.kitchenlab.org>	<20070121.020741.59649277.hrs@allbsd.org>
	<45B251A5.4000209@freebsd.org>
In-Reply-To: <45B251A5.4000209@freebsd.org>
X-Enigmail-Version: 0.94.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at echomania.com
Cc: freebsd-net@freebsd.org, Hiroki Sato <hrs@freebsd.org>,
	freebsd-stable@freebsd.org, jhay@freebsd.org
Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 20:35:19 -0000

Bruce A. Mah wrote:
>>  I remember Dimitry Andric reported the same problem on -stable on 30
>>  Dec, and after he reverted rev.1.48.2.16 it worked fine again.  Do
>>  you have the symptom even on 6.2-RELEASE?  Since RELENG_6_2_0_RELEASE
>>  did not have the change, I thought there was no problem.
...
> On my 6-STABLE system (which appears to be working fine), I still have
> the change from 1.48.2.16, I only backed out .15 and .14.  I didn't try
> my diff on the 6.2-RC2 and 6.2-RELEASE machines yet.
> 
> Hmmm...I was looking for that bug report before, but I couldn't find it.
>  It's not clear to me how 1.48.2.16 is involved...hmmm...

I originally reported this here:
http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031809.html

and later I found out it was caused by commit 1.48.2.16:
http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html

I'll shoot in a regular PR later tonight...

From owner-freebsd-net@FreeBSD.ORG  Sun Jan 21 22:10:33 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 3E52116A4D1
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 22:10:33 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179])
	by mx1.freebsd.org (Postfix) with ESMTP id D80A213C455
	for <freebsd-net@freebsd.org>; Sun, 21 Jan 2007 22:10:32 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from [213.141.131.138] (helo=localhost)
	by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1H8kzw-0001iY-Vf
	for freebsd-net@freebsd.org; Mon, 22 Jan 2007 01:17:13 +0300
Date: Mon, 22 Jan 2007 01:09:57 +0300
From: Wishmaster <wishmaster@velnet.ru>
X-Mailer: The Bat! (v2.12.00)
X-Priority: 3 (Normal)
Message-ID: <1651695163.20070122010957@velnet.ru>
To: freebsd-net@freebsd.org
In-Reply-To: <45B28F37.7040100@delphij.net>
References: <1458229821.20070120234257@velnet.ru>
	<45B28F37.7040100@delphij.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re[2]: reproducible watchdog timeout in bge
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Wishmaster <wishmaster@velnet.ru>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jan 2007 22:10:33 -0000

Hello LI,

Sunday, January 21, 2007, 12:52:55 AM, you wrote:

LX> Wishmaster wrote:
>> Hi,
>> 
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090

LX> Have you tried this one?

LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62

LX> Cheers,

Yes, i tried, but have no effect.

after reboot interface works, but if i try to ping with packet for
example 1500 bytes and interval 0.01s it looks like

answer
answer
answer
....
..... over 50 or less icmp answers then
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available
ping: sendto: No buffer space available

in dmesg:
bge0: watchdog timeout -- resetting
bge0: link state changed to DOWN
bge0: link state changed to UP

-- 
Best regards,
 Wishmaster                            mailto:wishmaster@velnet.ru



From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 02:26:41 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 21EFF16A400
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 02:26:41 +0000 (UTC)
	(envelope-from bmah@freebsd.org)
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245])
	by mx1.freebsd.org (Postfix) with ESMTP id B648D13C457
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 02:26:40 +0000 (UTC)
	(envelope-from bmah@freebsd.org)
Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109])
	(authenticated bits=0)
	by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id
	l0M2QXhK009144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 21 Jan 2007 18:26:39 -0800
Message-ID: <45B420D5.4040903@freebsd.org>
Date: Sun, 21 Jan 2007 18:26:29 -0800
From: "Bruce A. Mah" <bmah@freebsd.org>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: John Hay <jhay@meraka.org.za>
References: <20070120162936.GA18104@tomcat.kitchenlab.org>
	<20070121073244.GA80811@zibbi.meraka.csir.co.za>
In-Reply-To: <20070121073244.GA80811@zibbi.meraka.csir.co.za>
X-Enigmail-Version: 0.94.0.0
OpenPGP: id=5ba052c3
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigD15351770AADCEA6312F1D02"
Cc: freebsd-net@freebsd.org
Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 02:26:41 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD15351770AADCEA6312F1D02
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If memory serves me right, John Hay wrote:
> On Sat, Jan 20, 2007 at 08:29:36AM -0800, Bruce A. Mah wrote:
>> I'm observing a problem with IPv6 over gif(4) tunnels on 6.2-RELEASE
>> and recent 6-STABLE, namely that I can't seem to be able to pass
>> traffic over them.
>>
>> Essentially, when I configure a gif interface like this:
>>
>> # ifconfig gif0 inet6 aaaa:bbbb:cccc:dddd::1 aaaa:bbbb:cccc:dddd::2 pr=
efixlen 128
>>
>> the interface should add a host route to aaaa:bbbb:cccc:dddd::2
>> through gif0.  This is necessary to be able to pass traffic over the
>> tunnel, particularly since the source and destination addresses of the=

>> link don't need to have any relationship to each other.
>=20
> I only have one IPv6 over IPv4/gif tunnel and ther I use only my side
> of the address, something like this:
>=20
> ifconfig gif0 inet6 2001:4200:ffff:5::2 prefixlen 64
>=20
> And then bgp on top of this. It seems to work fine on -current built
> after my change.=20

I believe the difference between your situation and mine is that your
gif0 interface is setup with a prefixlen < 128, which doesn't
specifically require a host route to the interface of the destination.
This is actually handled specially in several parts of the IPv6 stack.

> Well it seems that even my stuff does not always work perfectly with th=
at
> change (1.48.2.15), so maybe we should revert it and I will search for
> yet other ways to make FreeBSD's IPv6 code to actually work for our stu=
ff.
>
> My "stuff" is a wireless IPv6 only network running in adhoc mode with
> olsrd as the routing protocol. The problem is that all nodes on a subne=
t
> cannot "see" each other, so olsrd needs to add routes to a node through=

> another node. Sometimes, just to complicate matters a little more, you
> would want to have more than one network card in a host, all with the s=
ame
> subnet address. (For instance on a high site, with sector antennas.)
>=20
> The case that I found that still does not work reliably, is if olsrd ad=
d
> the route and route is not immediately used, then the nd code will time=

> it out and remove it.
>=20
> So, I guess if you guys think I should revert my stuff, just say so.
>=20
> And if you have a solution for my problem, just say so too. :-)

This sounds kind of interesting!

I'm concerned that this bug seems (at least in my testing) to be present
in 6.2-RELEASE.  I'm not 100% sure what's the right thing to do at this
point.

Thanks,

Bruce.


--------------enigD15351770AADCEA6312F1D02
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtCDZ2MoxcVugUsMRAg7+AKDv3pIMZjkW2N5A2LHEkmz8rrWN4ACfXKhz
JJ0uwCW8VBWAOoLa8aSKh8E=
=/jYq
-----END PGP SIGNATURE-----

--------------enigD15351770AADCEA6312F1D02--

From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 02:30:48 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 6E68516A400;
	Mon, 22 Jan 2007 02:30:48 +0000 (UTC)
	(envelope-from bmah@freebsd.org)
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5])
	by mx1.freebsd.org (Postfix) with ESMTP id 5377E13C45B;
	Mon, 22 Jan 2007 02:30:48 +0000 (UTC)
	(envelope-from bmah@freebsd.org)
Received: from [64.142.31.109] (phantom.kitchenlab.org [64.142.31.109])
	(authenticated bits=0)
	by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id
	l0M2Ujrf030953
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sun, 21 Jan 2007 18:30:45 -0800
Message-ID: <45B421D4.2050008@freebsd.org>
Date: Sun, 21 Jan 2007 18:30:44 -0800
From: "Bruce A. Mah" <bmah@freebsd.org>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Dimitry Andric <dimitry@andric.com>
References: <20070120162936.GA18104@tomcat.kitchenlab.org>	<20070121.020741.59649277.hrs@allbsd.org>
	<45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com>
In-Reply-To: <45B3CA56.4040106@andric.com>
X-Enigmail-Version: 0.94.0.0
OpenPGP: id=5ba052c3
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigDB6AE63A7FA61973A62DB677"
Cc: freebsd-net@freebsd.org, Hiroki Sato <hrs@freebsd.org>,
	freebsd-stable@freebsd.org, jhay@freebsd.org
Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 02:30:48 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDB6AE63A7FA61973A62DB677
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If memory serves me right, Dimitry Andric wrote:
> Bruce A. Mah wrote:
>>>  I remember Dimitry Andric reported the same problem on -stable on 30=

>>>  Dec, and after he reverted rev.1.48.2.16 it worked fine again.  Do
>>>  you have the symptom even on 6.2-RELEASE?  Since RELENG_6_2_0_RELEAS=
E
>>>  did not have the change, I thought there was no problem.
> ...
>> On my 6-STABLE system (which appears to be working fine), I still have=

>> the change from 1.48.2.16, I only backed out .15 and .14.  I didn't tr=
y
>> my diff on the 6.2-RC2 and 6.2-RELEASE machines yet.
>>
>> Hmmm...I was looking for that bug report before, but I couldn't find i=
t.
>>  It's not clear to me how 1.48.2.16 is involved...hmmm...
>=20
> I originally reported this here:
> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031809.=
html
>=20
> and later I found out it was caused by commit 1.48.2.16:
> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.=
html
>=20
> I'll shoot in a regular PR later tonight...

Hi Dimitry--

This isn't consistent with what I'm finding.  For one thing, rev.
1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there
anyways.  Also, that's not the change I made to my local sources to get
my gif(4) tunnel working.  Are you sure about this?  :-)

Thanks!

Bruce.



--------------enigDB6AE63A7FA61973A62DB677
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtCHU2MoxcVugUsMRAh2BAJ4ko8DJylWIz8Hv5cME5jThGyvbugCgsoIO
o8WDZf7XNeRRO9ibZMwd2IA=
=pPCU
-----END PGP SIGNATURE-----

--------------enigDB6AE63A7FA61973A62DB677--

From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 03:23:30 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 6F11316A400
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 03:23:30 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226])
	by mx1.freebsd.org (Postfix) with ESMTP id 3727E13C442
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 03:23:30 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au
	[61.8.2.163])
	by mailout2.pacific.net.au (Postfix) with ESMTP id 8E5C46E2E9;
	Mon, 22 Jan 2007 14:23:26 +1100 (EST)
Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246])
	by mailproxy2.pacific.net.au (Postfix) with ESMTP id D135227436;
	Mon, 22 Jan 2007 14:23:27 +1100 (EST)
Date: Mon, 22 Jan 2007 14:23:26 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@besplex.bde.org
To: Max Laier <max@love2party.net>
In-Reply-To: <200701212033.34914.max@love2party.net>
Message-ID: <20070122140144.R7272@besplex.bde.org>
References: <20070121155510.C23922@delplex.bde.org>
	<200701210809.27770.max@love2party.net>
	<20070121215054.C24780@delplex.bde.org>
	<200701212033.34914.max@love2party.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net@freebsd.org
Subject: Re: slow writes on nfs with bge devices
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 03:23:30 -0000

On Sun, 21 Jan 2007, Max Laier wrote:

> On Sunday 21 January 2007 13:25, Bruce Evans wrote:
>> On Sun, 21 Jan 2007, Max Laier wrote:
>>> On Sunday 21 January 2007 07:25, Bruce Evans wrote:
>>>> nfs writes much less well with bge NICs than with other NICs (sk,
>>>> fxp,
>>>
>>> Do you use hardware checksumming on the bge?  There is an XXX in
>>> bge_start_locked() that looks a bit suspicious to me.
>>
>> I use the default for that.  Wouldn't checksum problems show up as
>> errors somwhere?
>
> Did you look at the code in question?  It is concerned with fragmented
> packet chains (which NFS over UDP usually generated) and only commits to
> sending them, if there are enough descriptors available at once.  This
> can easily explain burstyness.
>
> Can you just try to disable the delayed checksums via "ifconfig -txcsum"?
> Should be an easy enough test.

I haven't looked closely at the bge checksum code, but tried turning off
checksums (various combinations) yesterday.  THis made no difference.

>> tcpdump shows a lot of intervals between nfs write requests of almost
>> exactly 10 mS (even with HZ = 1000, but more obvious with HZ = 100)
>> for the broken case, so the problem is apparently related to timeouts,
>
> See above, I really think that there is something about that if_start loop
> that might be causing this.

I have some local changes in this area (much larger ifq length and
watermark stuff to reduce tx interrupts).  I think they make no
difference, but will have to test an unchanged driver more carefully.
I assume that the if_start loop always calls the interface if_start
if there is something in the ifq and the interface is not marked as
active.

Bruce

From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 07:44:24 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 81FD816A401
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 07:44:24 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226])
	by mx1.freebsd.org (Postfix) with ESMTP id B6E0313C45A
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 07:44:23 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au
	[61.8.2.162])
	by mailout2.pacific.net.au (Postfix) with ESMTP id 208EE6E160;
	Mon, 22 Jan 2007 18:44:18 +1100 (EST)
Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246])
	by mailproxy1.pacific.net.au (Postfix) with ESMTP id 0C6178C19;
	Mon, 22 Jan 2007 18:44:17 +1100 (EST)
Date: Mon, 22 Jan 2007 18:44:17 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@besplex.bde.org
To: Max Laier <max@love2party.net>
In-Reply-To: <20070122140144.R7272@besplex.bde.org>
Message-ID: <20070122175630.I7870@besplex.bde.org>
References: <20070121155510.C23922@delplex.bde.org>
	<200701210809.27770.max@love2party.net>
	<20070121215054.C24780@delplex.bde.org>
	<200701212033.34914.max@love2party.net>
	<20070122140144.R7272@besplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net@freebsd.org
Subject: Re: slow writes on nfs with bge devices
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 07:44:24 -0000

On Mon, 22 Jan 2007, Bruce Evans wrote:

> On Sun, 21 Jan 2007, Max Laier wrote:
>
>> On Sunday 21 January 2007 13:25, Bruce Evans wrote:

>> Can you just try to disable the delayed checksums via "ifconfig -txcsum"?
>> Should be an easy enough test.
>
> I haven't looked closely at the bge checksum code, but tried turning off
> checksums (various combinations) yesterday.  THis made no difference.

(An old version of) tcpdump -vv reported bad checksums if hardware
checksumming is on, but I assume that is because it can't see the
hardware checksums.

>>> tcpdump shows a lot of intervals between nfs write requests of almost
>>> exactly 10 mS (even with HZ = 1000, but more obvious with HZ = 100)
>>> for the broken case, so the problem is apparently related to timeouts,

Driver-level timestamps make this even more obious.

>> See above, I really think that there is something about that if_start loop
>> that might be causing this.
>
> I have some local changes in this area (much larger ifq length and
> watermark stuff to reduce tx interrupts).  I think they make no
> difference, but will have to test an unchanged driver more carefully.
> I assume that the if_start loop always calls the interface if_start
> if there is something in the ifq and the interface is not marked as
> active.

Tested again with almost pure RELENG_6.  There was little difference.

Here is some tcpdump output in case you can see the pattern better
than me.  Testing dd if=/dev/zero of=zz bs=1m count=100:

% 16:41:12.410346 IP phiplex.bde.org.1735978418 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x0
% 16:41:12.410349 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.410350 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.410350 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.410351 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.410352 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.410379 IP phiplex.bde.org.1735978419 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2000
% 16:41:12.410380 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.410381 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.410381 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.410382 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.410383 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411318 IP besplex.bde.org.nfs > phiplex.bde.org.1735978418: reply ok 160 write [|nfs]

This is normal for writing a 16K fs-block.  Everything completes in < 1 mS.

% 16:41:12.411368 IP phiplex.bde.org.1735978438 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x28000

And the next block is started not more than about 50 uS later.  I don't
know why the next block is out of order.  Possibly related to it being
near the first indirect block.

% 16:41:12.411369 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411369 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411370 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411371 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411372 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411941 IP besplex.bde.org.nfs > phiplex.bde.org.1735978419: reply ok 160 write [|nfs]
% 16:41:12.411965 IP phiplex.bde.org.1735978439 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2a000
% 16:41:12.411966 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411967 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411968 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411969 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.411970 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.412627 IP besplex.bde.org.nfs > phiplex.bde.org.1735978438: reply ok 160 write [|nfs]

% ...

Things go at full speed with sequential blocks to 0x34000 until here.
Then another sequential block:

16:41:12.416820 IP phiplex.bde.org.1735978446 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x38000
% 16:41:12.416821 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.416822 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.416823 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.416823 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.416824 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.417486 IP besplex.bde.org.nfs > phiplex.bde.org.1735978445: reply ok 160 write [|nfs]
% 16:41:12.417506 IP phiplex.bde.org.1735978447 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x3a000
% 16:41:12.417507 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.417508 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.417509 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.417509 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.417510 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.417881 IP phiplex.bde.org.1735978420 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x4000

But before the reply for 0x38000, it got back to sending the second 16K-block.
Still no speed problems.

% 16:41:12.417882 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.417882 IP phiplex.bde.org > besplex.bde.org: udp

% 16:41:12.416820 IP phiplex.bde.org.1735978446 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x38000
% 16:41:12.417883 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.417884 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.417885 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.418187 IP besplex.bde.org.nfs > phiplex.bde.org.1735978446: reply ok 160 write [|nfs]
% 16:41:12.418209 IP phiplex.bde.org.1735978448 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x3c000
% 16:41:12.418210 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.418211 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.418211 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.418212 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.418213 IP phiplex.bde.org > besplex.bde.org: udp

Stalled here.  Stalls seem to be related to out of order delivery.

% 16:41:12.492327 IP besplex.bde.org.822 > phiplex.bde.org.login: . ack 151 win 33304 <nop,nop,timestamp 18270197 1495076486>
% 16:41:12.667862 IP phiplex.bde.org.1735978447 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x3a000

Now it's retrying 0x3a000.

% 16:41:12.667863 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.667864 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.667864 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.667865 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.667866 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.668731 IP besplex.bde.org.nfs > phiplex.bde.org.1735978447: reply ok 160 write [|nfs]
% 16:41:12.668754 IP phiplex.bde.org.1735978449 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x3e000
% 16:41:12.668755 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.668755 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.668756 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.668757 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.668758 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.669650 IP besplex.bde.org.nfs > phiplex.bde.org.1735978449: reply ok 160 write [|nfs]

% ...

Then it got to here with only relatively minor glitches:

% 16:41:12.947085 IP phiplex.bde.org.1735978781 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2d6000
% 16:41:12.947086 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947087 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947088 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947089 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947090 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947861 IP phiplex.bde.org.1735978421 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x6000

It's having problems writing 0x6000.  This is a retry.  Just for unreported
packet loss?  Perhaps my switch or cable is the problem.

% 16:41:12.947862 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947862 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947863 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947864 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947865 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.947956 IP besplex.bde.org.nfs > phiplex.bde.org.1735978781: reply ok 160 write [|nfs]
% 16:41:12.948739 IP besplex.bde.org.nfs > phiplex.bde.org.1735978421: reply ok 160 write [|nfs]

Now it has reached a state in which it ony tries to send 1 packet ever 10 mS.
10 mS is nfsclient's default tick interval.

% 16:41:12.957853 IP phiplex.bde.org.1735978422 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x8000
% 16:41:12.957854 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.957855 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.957856 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.957857 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.957857 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.958723 IP besplex.bde.org.nfs > phiplex.bde.org.1735978422: reply ok 160 write [|nfs]
% 16:41:12.967851 IP phiplex.bde.org.1735978424 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0xc000
% 16:41:12.967852 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.967853 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.967854 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.967854 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.967855 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.968802 IP besplex.bde.org.nfs > phiplex.bde.org.1735978424: reply ok 160 write [|nfs]

In fact, it is (re?)trying most of the old blocks that were out of
order after the first block.  It's not even sending one fs-block per 10 mS,
only one nfs-block = half of an fs-block.

% 16:41:12.977862 IP phiplex.bde.org.1735978425 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0xe000
% 16:41:12.977863 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.977864 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.977864 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.977865 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.977866 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.978714 IP besplex.bde.org.nfs > phiplex.bde.org.1735978425: reply ok 160 write [|nfs]
% 16:41:12.987850 IP phiplex.bde.org.1735978511 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0xba000
% 16:41:12.987851 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.987852 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.987853 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.987854 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.987855 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.988724 IP besplex.bde.org.nfs > phiplex.bde.org.1735978511: reply ok 160 write [|nfs]

This is out of order but still spaced at 10 mS.

% 16:41:12.997848 IP phiplex.bde.org.1735978427 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x12000
% 16:41:12.997849 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.997850 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.997850 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.997851 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.997852 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:12.998715 IP besplex.bde.org.nfs > phiplex.bde.org.1735978427: reply ok 160 write [|nfs]

Back to early blocks.

% 16:41:13.007849 IP phiplex.bde.org.1735978536 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0xec000
% 16:41:13.007850 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.007851 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.007852 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.007853 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.007854 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.008722 IP besplex.bde.org.nfs > phiplex.bde.org.1735978536: reply ok 160 write [|nfs]
% 16:41:13.017847 IP phiplex.bde.org.1735978430 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x18000
% 16:41:13.017848 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.017849 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.017850 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.017851 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.017852 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.018715 IP besplex.bde.org.nfs > phiplex.bde.org.1735978430: reply ok 160 write [|nfs]
% 16:41:13.027846 IP phiplex.bde.org.1735978561 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x11e000
% 16:41:13.027847 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.027848 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.027849 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.027850 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.027850 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.028723 IP besplex.bde.org.nfs > phiplex.bde.org.1735978561: reply ok 160 write [|nfs]
% 16:41:13.037846 IP phiplex.bde.org.1735978594 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x160000
% 16:41:13.037847 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.037848 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.037849 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.037849 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.037850 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.038718 IP besplex.bde.org.nfs > phiplex.bde.org.1735978594: reply ok 160 write [|nfs]
% 16:41:13.047845 IP phiplex.bde.org.1735978432 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x1c000
% 16:41:13.047846 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.047846 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.047847 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.047848 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.047849 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.048717 IP besplex.bde.org.nfs > phiplex.bde.org.1735978432: reply ok 160 write [|nfs]
% 16:41:13.067845 IP phiplex.bde.org.1735978434 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x20000
% 16:41:13.067846 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.067847 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.067848 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.067848 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.067849 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.068712 IP besplex.bde.org.nfs > phiplex.bde.org.1735978434: reply ok 160 write [|nfs]

20 mS interval before above.

% 16:41:13.077847 IP phiplex.bde.org.1735978619 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x192000
% 16:41:13.077849 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.077849 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.077850 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.077851 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.077852 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.078723 IP besplex.bde.org.nfs > phiplex.bde.org.1735978619: reply ok 160 write [|nfs]
% 16:41:13.097842 IP phiplex.bde.org.1735978666 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x1f0000
% 16:41:13.097843 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.097844 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.097844 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.097845 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.097846 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.098713 IP besplex.bde.org.nfs > phiplex.bde.org.1735978666: reply ok 160 write [|nfs]
% 16:41:13.107841 IP phiplex.bde.org.1735978436 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x24000
% 16:41:13.107842 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.107843 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.107844 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.107845 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.107846 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.108712 IP besplex.bde.org.nfs > phiplex.bde.org.1735978436: reply ok 160 write [|nfs]

Even more 20 mS intervals.

% 16:41:13.137840 IP phiplex.bde.org.1735978715 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x252000
% 16:41:13.137841 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.137842 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.137842 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.137843 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.137844 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.138712 IP besplex.bde.org.nfs > phiplex.bde.org.1735978715: reply ok 160 write [|nfs]

30 mS.

% 16:41:13.147839 IP phiplex.bde.org.1735978473 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x6e000
% 16:41:13.147840 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.147841 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.147842 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.147843 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.147843 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.148709 IP besplex.bde.org.nfs > phiplex.bde.org.1735978473: reply ok 160 write [|nfs]

10 mS.

% 16:41:13.177841 IP phiplex.bde.org.1735978763 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2b2000
% 16:41:13.180371 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.180372 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.180372 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.180373 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.180374 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.181243 IP besplex.bde.org.nfs > phiplex.bde.org.1735978763: reply ok 160 write [|nfs]

30 mS.

% 16:41:13.181270 IP phiplex.bde.org.1735978800 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2fc000
% 16:41:13.181271 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.181272 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.181273 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.181274 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.181274 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.182194 IP besplex.bde.org.nfs > phiplex.bde.org.1735978800: reply ok 160 write [|nfs]
% 16:41:13.182216 IP phiplex.bde.org.1735978801 > besplex.bde.org.nfs: 1472 write fh 1028,575312/94220 8192 bytes @ 0x2fe000
% 16:41:13.182217 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.182218 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.182219 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.182220 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.182221 IP phiplex.bde.org > besplex.bde.org: udp
% 16:41:13.183070 IP besplex.bde.org.nfs > phiplex.bde.org.1735978801: reply ok 160 write [|nfs]

Back to normal.

Is this just what happens when nfs/udp loses packets?  nfs/tcp may be better
only because it has better retry algorthms.

Bruce

From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 10:16:51 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 96D2F16A400;
	Mon, 22 Jan 2007 10:16:51 +0000 (UTC)
	(envelope-from dimitry@andric.com)
Received: from springbank.echomania.com (springbank.echomania.com
	[82.94.255.114])
	by mx1.freebsd.org (Postfix) with ESMTP id 524A813C465;
	Mon, 22 Jan 2007 10:16:51 +0000 (UTC)
	(envelope-from dimitry@andric.com)
Received: from localhost (localhost [127.0.0.1])
	by springbank.echomania.com (Postfix) with ESMTP id 97DA7A713D;
	Mon, 22 Jan 2007 11:16:49 +0100 (CET)
Received: from springbank.echomania.com ([127.0.0.1])
	by localhost (springbank.echomania.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with LMTP id 16238-01; Mon, 22 Jan 2007 11:16:45 +0100 (CET)
Received: from [192.168.0.3] (tensor.andric.com [213.154.244.69])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by springbank.echomania.com (Postfix) with ESMTP id 3E8A2A70C0;
	Mon, 22 Jan 2007 11:16:45 +0100 (CET)
Message-ID: <45B48F0C.9090809@andric.com>
Date: Mon, 22 Jan 2007 11:16:44 +0100
From: Dimitry Andric <dimitry@andric.com>
User-Agent: Thunderbird 2.0b1 (Windows/20070106)
MIME-Version: 1.0
To: "Bruce A. Mah" <bmah@freebsd.org>
References: <20070120162936.GA18104@tomcat.kitchenlab.org>	<20070121.020741.59649277.hrs@allbsd.org>
	<45B251A5.4000209@freebsd.org> <45B3CA56.4040106@andric.com>
	<45B421D4.2050008@freebsd.org>
In-Reply-To: <45B421D4.2050008@freebsd.org>
X-Enigmail-Version: 0.94.1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at echomania.com
Cc: freebsd-net@freebsd.org, Hiroki Sato <hrs@freebsd.org>,
	freebsd-stable@freebsd.org, jhay@freebsd.org
Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 10:16:51 -0000

Bruce A. Mah wrote:
>> and later I found out it was caused by commit 1.48.2.16:
>> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html
> 
> This isn't consistent with what I'm finding.  For one thing, rev.
> 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there
> anyways.  Also, that's not the change I made to my local sources to get
> my gif(4) tunnel working.  Are you sure about this?  :-)

I'm following -STABLE, and 1.48.2.16 is in there.  Since it was
committed on 29 Nov, I suspected it would end up in -RELEASE, but
apparently not. :)

I explicitly tried reverting just this one commit, and for me it solved
the problem (i.e. the automagical addition of needed routing entries).

So for you, reverting the combination of 1.48.2.14 and .15 works?  Maybe
there is something else involved too, for example the route command
itself?

I'll have to experiment a bit further, I guess.

From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 10:50:54 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 1E91E16A402
	for <freebsd-net@FreeBSD.org>; Mon, 22 Jan 2007 10:50:54 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210])
	by mx1.freebsd.org (Postfix) with ESMTP id B298413C44B
	for <freebsd-net@FreeBSD.org>; Mon, 22 Jan 2007 10:50:53 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au
	[61.8.2.163])
	by mailout1.pacific.net.au (Postfix) with ESMTP id 62B735A04D4;
	Mon, 22 Jan 2007 21:50:52 +1100 (EST)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailproxy2.pacific.net.au (Postfix) with ESMTP id 256E627403;
	Mon, 22 Jan 2007 21:50:51 +1100 (EST)
Date: Mon, 22 Jan 2007 21:50:49 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@delplex.bde.org
To: Max Laier <max@love2party.net>
In-Reply-To: <20070122175630.I7870@besplex.bde.org>
Message-ID: <20070122211609.M28527@delplex.bde.org>
References: <20070121155510.C23922@delplex.bde.org>
	<200701210809.27770.max@love2party.net>
	<20070121215054.C24780@delplex.bde.org>
	<200701212033.34914.max@love2party.net>
	<20070122140144.R7272@besplex.bde.org>
	<20070122175630.I7870@besplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net@FreeBSD.org
Subject: Re: slow writes on nfs with bge devices
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 10:50:54 -0000

On Mon, 22 Jan 2007, Bruce Evans wrote:

> % ...
>
> Then it got to here with only relatively minor glitches:
>
> % 16:41:12.947085 IP phiplex.bde.org.1735978781 > besplex.bde.org.nfs: 1472 
> write fh 1028,575312/94220 8192 bytes @ 0x2d6000
> % 16:41:12.947086 IP phiplex.bde.org > besplex.bde.org: udp
> % 16:41:12.947087 IP phiplex.bde.org > besplex.bde.org: udp
> % 16:41:12.947088 IP phiplex.bde.org > besplex.bde.org: udp
> % 16:41:12.947089 IP phiplex.bde.org > besplex.bde.org: udp
> % 16:41:12.947090 IP phiplex.bde.org > besplex.bde.org: udp
> % 16:41:12.947861 IP phiplex.bde.org.1735978421 > besplex.bde.org.nfs: 1472 
> write fh 1028,575312/94220 8192 bytes @ 0x6000
>
> It's having problems writing 0x6000.  This is a retry.  Just for unreported
> packet loss?  Perhaps my switch or cable is the problem.

Nevermind / 2.  The switch or cable certain has problems.  The only problem
in FreeBSD or the bge driver, if any, may be that errors are not detected
except as completely lost packets.

Swapping cables gives the following strange behaviours:
- fxp <-> bge (5705) works perfectly (at only 100 MBps of course) with
   a direct link (11.83e6 B/S), but not through the switch (cheap 1Gbps
   switch). 
- fxp <-> bge (5701) works better with a direct link, but imperfectly
   with the same cables that work for the 5705.  nfs write speed increases
   from ~1 MB/S to ~8 MB/S.  The link is autonegotiated correctly as
   100baseTX full-duplex.  With this configuration, errors seem to be
   detected correctly.  nfs writes cause input errors (fxp -> bge at a
   an almost constant rate of almost exactly 1 per 500 packets.  (500
   may be significant since it the bge rx ring sizes is 512.)
- on reconnecting the 5701 through the switch, no errors were detected
   when the link is autonegotited to 1000BaseTX full-duplex, but when it
   is manually configured to 100baseTX full-duplex, some input errors but
   at a highly variable rate not nearly as many as high 1 in 500.  A
   few packet blasting tests on the 5701 didn't cause any input errors
   at 100baseTX.  I haven't figured out the type of the input errors.
   No output errors were reported for any of this.
- when the 5701 was in the server, exhaustive packet blasting tests at
   1000basetX caused a large number of input errors whenever the rx
   interrupt moderation was configured to just a little more aggressively
   than the default, in condtions where the tx is very active.  (The
   rx ring is supposed to have size 512, but had an effective size of
   only 20 under tx load, apparently due to misconfiguration of contention
   with tx resources.)  Packets were just dropped on input.

Bruce

From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 11:08:40 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id B958B16A547
	for <freebsd-net@FreeBSD.org>; Mon, 22 Jan 2007 11:08:40 +0000 (UTC)
	(envelope-from owner-bugmaster@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40])
	by mx1.freebsd.org (Postfix) with ESMTP id A879D13C461
	for <freebsd-net@FreeBSD.org>; Mon, 22 Jan 2007 11:08:40 +0000 (UTC)
	(envelope-from owner-bugmaster@FreeBSD.org)
Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1])
	by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l0MB8eKc037002
	for <freebsd-net@FreeBSD.org>; Mon, 22 Jan 2007 11:08:40 GMT
	(envelope-from owner-bugmaster@FreeBSD.org)
Received: (from linimon@localhost)
	by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l0MB8dIb036998
	for freebsd-net@FreeBSD.org; Mon, 22 Jan 2007 11:08:39 GMT
	(envelope-from owner-bugmaster@FreeBSD.org)
Date: Mon, 22 Jan 2007 11:08:39 GMT
Message-Id: <200701221108.l0MB8dIb036998@freefall.freebsd.org>
X-Authentication-Warning: freefall.freebsd.org: linimon set sender to
	owner-bugmaster@FreeBSD.org using -f
From: FreeBSD bugmaster <bugmaster@FreeBSD.org>
To: freebsd-net@FreeBSD.org
Cc: 
Subject: Current problem reports assigned to you
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 11:08:40 -0000

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
a kern/38554   net        changing interface ipaddress doesn't seem to work
s kern/39937   net        ipstealth issue
o kern/92552   net        A serious bug in most network drivers from 5.X to 6.X 
s kern/95665   net        [if_tun] "ping: sendto: No buffer space available" wit
o kern/106722  net        [net] [patch] ifconfig may not connect an interface to

5 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
s kern/19875   net        A new protocol family, PF_IPOPTION, to handle IP optio
o conf/23063   net        [PATCH] for static ARP tables in rc.network
s bin/41647    net        ifconfig(8) doesn't accept lladdr along with inet addr
o kern/54383   net        [nfs] [patch] NFS root configurations without dynamic 
s kern/60293   net        FreeBSD arp poison patch
o kern/95267   net        packet drops periodically appear
f kern/95277   net        [netinet] IP Encapsulation mask_match() returns wrong 
o kern/102035  net        [plip] plip networking disables parallel port printing
o conf/102502  net        [patch] ifconfig name does't rename netgraph node in n
o kern/106999  net        [netgraph] [patch] ng_ksocket fails to clear multicast

10 problems total.


From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 12:59:42 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id B2C3216A401
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 12:59:42 +0000 (UTC)
	(envelope-from antinvidia@gmail.com)
Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.226])
	by mx1.freebsd.org (Postfix) with ESMTP id 6EADC13C428
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 12:59:42 +0000 (UTC)
	(envelope-from antinvidia@gmail.com)
Received: by nz-out-0506.google.com with SMTP id i11so546940nzh
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 04:59:41 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=ddEXZIXfSXMlvb85jYa2kBeLtI7hgBTLo4hj/qRCCJ4seJByIhNPF691ZWIqC4zEL5T+SvJ+mJ0qf28j5kcZ7figNoshSA5paglJyLufhhNWjjOJcG2snoOxoB/PYjxNz/VRFOn9gMkdSMSbnIKjVKAkkKWq4YPwxqXbA/HDzFE=
Received: by 10.35.93.1 with SMTP id v1mr10412643pyl.1169469113061;
	Mon, 22 Jan 2007 04:31:53 -0800 (PST)
Received: by 10.35.60.19 with HTTP; Mon, 22 Jan 2007 04:31:52 -0800 (PST)
Message-ID: <be0088ce0701220431tf96827et3713885fac8a490a@mail.gmail.com>
Date: Mon, 22 Jan 2007 20:31:52 +0800
From: MQ <antinvidia@gmail.com>
To: Wishmaster <wishmaster@velnet.ru>
In-Reply-To: <1651695163.20070122010957@velnet.ru>
MIME-Version: 1.0
References: <1458229821.20070120234257@velnet.ru>
	<45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: freebsd-net@freebsd.org
Subject: Re: Re[2]: reproducible watchdog timeout in bge
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 12:59:42 -0000

2007/1/22, Wishmaster <wishmaster@velnet.ru>:
>
> Hello LI,
>
> Sunday, January 21, 2007, 12:52:55 AM, you wrote:
>
> LX> Wishmaster wrote:
> >> Hi,
> >>
> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090
>
> LX> Have you tried this one?
>
> LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62
>
> LX> Cheers,
>
> Yes, i tried, but have no effect.
>
> after reboot interface works, but if i try to ping with packet for
> example 1500 bytes and interval 0.01s it looks like
>
> answer
> answer
> answer
> ....
> ..... over 50 or less icmp answers then
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
> ping: sendto: No buffer space available
>
> in dmesg:
> bge0: watchdog timeout -- resetting
> bge0: link state changed to DOWN
> bge0: link state changed to UP
>
> --
> Best regards,
> Wishmaster                            mailto:wishmaster@velnet.ru
>
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to freebsd-net-unsubscribe@freebsd.org
>



What about other NIC chips from Broadcom? And how about the packets other
than icmp under the same load?

From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 13:57:03 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id BA00B16A507
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 13:57:03 +0000 (UTC)
	(envelope-from lists@qwirky.net)
Received: from public.aci.on.ca (aci.on.ca [205.207.148.251])
	by mx1.freebsd.org (Postfix) with ESMTP id 7C26013C428
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 13:57:03 +0000 (UTC)
	(envelope-from lists@qwirky.net)
Received: from (invalid client hostname: host address literal does not match
	remote client address)[127.0.0.1]
	(xtreme-156-171.dyn.aci.on.ca[69.17.156.171] port=1086)
	by public.aci.on.ca([205.207.148.252] port=25)
	via TCP with esmtp (3162 bytes) (sender: <lists@qwirky.net>)
	id <m1H8zOK-003QVIC@public.aci.on.ca> for <freebsd-net@freebsd.org>;
	Mon, 22 Jan 2007 08:39:20 -0500 (EST)
	(Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2006-Feb-21)
Message-ID: <45B4BE90.20602@qwirky.net>
Date: Mon, 22 Jan 2007 08:39:28 -0500
From: Jeff Royle <lists@qwirky.net>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: freebsd-net@freebsd.org
References: <1458229821.20070120234257@velnet.ru>	<45B28F37.7040100@delphij.net>
	<1651695163.20070122010957@velnet.ru>
	<be0088ce0701220431tf96827et3713885fac8a490a@mail.gmail.com>
In-Reply-To: <be0088ce0701220431tf96827et3713885fac8a490a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 0704-1, 22/01/2007), Outbound message
X-Antivirus-Status: Clean
Subject: Re: reproducible watchdog timeout in bge
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: lists@qwirky.net
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 13:57:03 -0000

MQ wrote:
> 2007/1/22, Wishmaster <wishmaster@velnet.ru>:
>>
>> Hello LI,
>>
>> Sunday, January 21, 2007, 12:52:55 AM, you wrote:
>>
>> LX> Wishmaster wrote:
>> >> Hi,
>> >>
>> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090
>>
>> LX> Have you tried this one?
>>
>> LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62
>>
>> LX> Cheers,
>>
>> Yes, i tried, but have no effect.
>>
>> after reboot interface works, but if i try to ping with packet for
>> example 1500 bytes and interval 0.01s it looks like
>>
>> answer
>> answer
>> answer
>> ....
>> ..... over 50 or less icmp answers then
>> ping: sendto: No buffer space available
>> ping: sendto: No buffer space available
>> ping: sendto: No buffer space available
>> ping: sendto: No buffer space available
>> ping: sendto: No buffer space available
>> ping: sendto: No buffer space available
>> ping: sendto: No buffer space available
>>
>> in dmesg:
>> bge0: watchdog timeout -- resetting
>> bge0: link state changed to DOWN
>> bge0: link state changed to UP
>>
>> -- 
>> Best regards,
>> Wishmaster                            mailto:wishmaster@velnet.ru
>>
> 
> What about other NIC chips from Broadcom? And how about the packets other
> than icmp under the same load?
> _______________________________________________

I have been unable to produce time outs with my current setup in 
6.2-Release.

bge0@pci3:0:0:  class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x11 
hdr=0x00
     vendor   = 'Broadcom Corporation'
     device   = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
     class    = network
     subclass = ethernet

Reading the PR, I attempted triggering this through CVSing and through 
the above mentioned ping tests.

So far nothing.

The only issue I have seen using these NICs in 6.2R is if I nail up the 
NIC at 100baseTX full-duplex I sometimes loose connectivity.   Nothing 
in the logs indicate watchdog timeouts or any other issue.   I simply 
brought the NIC back down to auto-neg and all seems fine.   I am 
assuming this is a incompatibility between the BGE and my switch, RS8000.

I have a Asus P5MT-S with dual BGE NIC's

Cheers,

Jeff

From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 14:31:22 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id C9C1616A400
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 14:31:22 +0000 (UTC)
	(envelope-from gallatin@cs.duke.edu)
Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1])
	by mx1.freebsd.org (Postfix) with ESMTP id 6EDB713C448
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 14:31:22 +0000 (UTC)
	(envelope-from gallatin@cs.duke.edu)
Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30])
	by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id l0MEVKc2016612
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Mon, 22 Jan 2007 09:31:20 -0500 (EST)
Received: (from gallatin@localhost)
	by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l0MEVJRg002591; 
	Mon, 22 Jan 2007 09:31:19 -0500 (EST) (envelope-from gallatin)
From: Andrew Gallatin <gallatin@cs.duke.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17844.51894.773943.99076@grasshopper.cs.duke.edu>
Date: Mon, 22 Jan 2007 09:31:18 -0500 (EST)
To: Randall Stewart <rrs@cisco.com>
In-Reply-To: <45B345FD.7080001@cisco.com>
References: <45B0D2E3.9050203@cisco.com>
	<17841.6943.770698.707214@grasshopper.cs.duke.edu>
	<45B345FD.7080001@cisco.com>
X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid
Cc: freebsd-net <freebsd-net@freebsd.org>
Subject: Re: kern_mbuf.c patch
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 14:31:22 -0000


Randall Stewart writes:
 > Andrew Gallatin wrote:
 > > Randall Stewart writes:
 > >  >  	nmbclusters = 1024 + maxusers * 64;
 > >  > +        nmbjumbop   = 100 + (maxusers * 4);
 > > 
 > > The limit on page-size jumbos seems far too small.  Since the socket
 > > buffer code now uses page-sized jumbos, I'd expect to see its limit be
 > > the same as nmbclusters.
 > > 
 > > 
 > > Drew
 > > 
 > Drew:
 > 
 > Let me re-visit this .. I started real small on purpose.. so
 > folks would complain ;-)
 > 
 > How about if I calculate the number of pages the
 > nmbclusters use (I will go look in the UMA structures) and
 > then make it so the limit is the same number of pages
 > (scaled like nmbclusters) for each of the larger clusters..

That sounds reasonable to me, at least for nmbjumbop, but I'm not sure
that the larger 9k and 16k clusters are used outside of drivers, so
the nmbclusters limit may be too large for them.  But I suppose some
limit is better than none :)

Drew


From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 19:25:49 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id EAC7A16A401
	for <net@freebsd.org>; Mon, 22 Jan 2007 19:25:49 +0000 (UTC)
	(envelope-from julian@elischer.org)
Received: from outX.internet-mail-service.net (outX.internet-mail-service.net
	[216.240.47.247])
	by mx1.freebsd.org (Postfix) with ESMTP id CEF1C13C4B7
	for <net@freebsd.org>; Mon, 22 Jan 2007 19:25:49 +0000 (UTC)
	(envelope-from julian@elischer.org)
Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20)
	by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP;
	Mon, 22 Jan 2007 10:51:07 -0800
Received: from [10.251.23.190] (nat.ironport.com [63.251.108.100])
	by idiom.com (Postfix) with ESMTP id 9369D125B5D;
	Mon, 22 Jan 2007 11:11:24 -0800 (PST)
Message-ID: <45B50C5B.2080600@elischer.org>
Date: Mon, 22 Jan 2007 11:11:23 -0800
From: Julian Elischer <julian@elischer.org>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Steve Watt <steve@Watt.COM>
References: <200701221546.l0MFk27m081898@wattres.watt.com>
In-Reply-To: <200701221546.l0MFk27m081898@wattres.watt.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: andre@freebsd.org, Uwe Doering <gemini@geminix.org>, net@freebsd.org
Subject: Re: Interesting TCP issue
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 19:25:50 -0000

Steve Watt wrote:
> On Jan 22,  9:15, Uwe Doering wrote:
> } Subject: Re: Interesting TCP issue
> } Steve Watt wrote:
> } > In <459AD141.5010502@elischer.org>, Julian Elischer wrote:
> } > 
> } > [ Snip discussion of symptoms of window scaling broken when
> } > talking to at least the skype mail servers. ]
> } > 
> } >> we have seen this since 4.x
> } >> I think a fix may be in 7.0 but I'm not sure..
> } >> I thin kthere is a problem when the far end sets the window down to 1 
> } >> but scales it by a factor of 2^{big number}.
> } >>
> } >> Andre, can you check out this problem and MFC the correct fix
> } >> if it is indeed the same problem in 6.2?
> } > 
> } > It is the same problem; I took the (one-line) fix as indicated by
> } > 
> } >> http://cvs.ironport.com/cgi-bin/viewcvs.cgi/freebsd/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85
> } > 
> } > (well, not cvs.ironport.com, which doesn't seem to exist at the moment),
> } > and applied the diff from 1.84 to
> } > 1.85 and to a 6.2-PRERELEASE box updated around 25 Dec 06.
> } > It works like a charm.
> } > 
> } > I would vote to MFC 1.85 now that 6.2 is out.
> } 
> } I wonder whether it is that easy.  As far as I can tell the commit to 
> } HEAD actually comprised changes to three files:
> 
> I wonder as well, but that single diff fixes the problem I was running
> into with the skype mail servers.
> 
> } http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.290&r2=1.291
> } http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85
> } http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.127&r2=1.128
> } 
> } How about the modifications in 'tcp_input.c'?  Are they relevant to the 
> } problem this thread is about?  If so, assessing the correctness of an 
> } MFC might prove to be a little harder.



That's why I asked Andre to look at it but he's not responding..

> 
> Looking at it, yeah, those probably need to be picked up in some form as
> well.  I didn't look closely at the tcpdump after, only observing that
> it worked where it didn't before.
> 
> Hmm.
> 


From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 19:38:13 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 051D216A400
	for <net@freebsd.org>; Mon, 22 Jan 2007 19:38:13 +0000 (UTC)
	(envelope-from julian@elischer.org)
Received: from outN.internet-mail-service.net (outN.internet-mail-service.net
	[216.240.47.237])
	by mx1.freebsd.org (Postfix) with ESMTP id E1F3313C4BD
	for <net@freebsd.org>; Mon, 22 Jan 2007 19:38:12 +0000 (UTC)
	(envelope-from julian@elischer.org)
Received: from shell.idiom.com (HELO idiom.com) (216.240.47.20)
	by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP;
	Mon, 22 Jan 2007 11:17:52 -0800
Received: from [10.251.23.190] (nat.ironport.com [63.251.108.100])
	by idiom.com (Postfix) with ESMTP id 32681125B9C;
	Mon, 22 Jan 2007 11:38:10 -0800 (PST)
Message-ID: <45B512A0.5030502@elischer.org>
Date: Mon, 22 Jan 2007 11:38:08 -0800
From: Julian Elischer <julian@elischer.org>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Andre Oppermann <andre@freebsd.org>
References: <200701221546.l0MFk27m081898@wattres.watt.com>
	<45B50C5B.2080600@elischer.org> <45B50D87.2050208@freebsd.org>
In-Reply-To: <45B50D87.2050208@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Steve Watt <steve@Watt.COM>, Uwe Doering <gemini@geminix.org>,
	net@freebsd.org
Subject: Re: Interesting TCP issue
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 19:38:13 -0000

Andre Oppermann wrote:

>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.290&r2=1.291 
>>>
>>> } 
>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 
>>>
>>> } 
>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.127&r2=1.128 
>>>
>>> } } How about the modifications in 'tcp_input.c'?  Are they relevant 
>>> to the } problem this thread is about?  If so, assessing the 
>>> correctness of an } MFC might prove to be a little harder.
>>
>>
>>
>> That's why I asked Andre to look at it but he's not responding..
> 
> He's about to re-appear @freebsd.
> 

great.. The TCP code is a bit like a house of cards..  Unless one is
up-to-date and has it all 'loaded' into one's mental cache, it is
all to easy to screw up function A by fixing code related to function B.
As I'm not 'loaded' I'm loathe to just MFC the one patch without being 
sure what the other two are..

BTW Andre you might MFC to back to 5 and 4 too if you could..

Julian



From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 19:43:07 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 2493416A409
	for <net@freebsd.org>; Mon, 22 Jan 2007 19:43:07 +0000 (UTC)
	(envelope-from andre@freebsd.org)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2])
	by mx1.freebsd.org (Postfix) with ESMTP id 8A73313C4A5
	for <net@freebsd.org>; Mon, 22 Jan 2007 19:43:06 +0000 (UTC)
	(envelope-from andre@freebsd.org)
Received: (qmail 84175 invoked from network); 22 Jan 2007 18:56:12 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2])
	(envelope-sender <andre@freebsd.org>)
	by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
	for <julian@elischer.org>; 22 Jan 2007 18:56:12 -0000
Message-ID: <45B50D87.2050208@freebsd.org>
Date: Mon, 22 Jan 2007 20:16:23 +0100
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Julian Elischer <julian@elischer.org>
References: <200701221546.l0MFk27m081898@wattres.watt.com>
	<45B50C5B.2080600@elischer.org>
In-Reply-To: <45B50C5B.2080600@elischer.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Steve Watt <steve@Watt.COM>, Uwe Doering <gemini@geminix.org>,
	net@freebsd.org
Subject: Re: Interesting TCP issue
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 19:43:07 -0000

Julian Elischer wrote:
> Steve Watt wrote:
>> On Jan 22,  9:15, Uwe Doering wrote:
>> } Subject: Re: Interesting TCP issue
>> } Steve Watt wrote:
>> } > In <459AD141.5010502@elischer.org>, Julian Elischer wrote:
>> } > } > [ Snip discussion of symptoms of window scaling broken when
>> } > talking to at least the skype mail servers. ]
>> } > } >> we have seen this since 4.x
>> } >> I think a fix may be in 7.0 but I'm not sure..
>> } >> I thin kthere is a problem when the far end sets the window down 
>> to 1 } >> but scales it by a factor of 2^{big number}.
>> } >>
>> } >> Andre, can you check out this problem and MFC the correct fix
>> } >> if it is indeed the same problem in 6.2?
>> } > } > It is the same problem; I took the (one-line) fix as indicated by
>> } > } >> 
>> http://cvs.ironport.com/cgi-bin/viewcvs.cgi/freebsd/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 
>>
>> } > } > (well, not cvs.ironport.com, which doesn't seem to exist at 
>> the moment),
>> } > and applied the diff from 1.84 to
>> } > 1.85 and to a 6.2-PRERELEASE box updated around 25 Dec 06.
>> } > It works like a charm.
>> } > } > I would vote to MFC 1.85 now that 6.2 is out.
>> } } I wonder whether it is that easy.  As far as I can tell the commit 
>> to } HEAD actually comprised changes to three files:
>>
>> I wonder as well, but that single diff fixes the problem I was running
>> into with the skype mail servers.
>>
>> } 
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.290&r2=1.291 
>>
>> } 
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 
>>
>> } 
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.127&r2=1.128 
>>
>> } } How about the modifications in 'tcp_input.c'?  Are they relevant 
>> to the } problem this thread is about?  If so, assessing the 
>> correctness of an } MFC might prove to be a little harder.
> 
> 
> 
> That's why I asked Andre to look at it but he's not responding..

He's about to re-appear @freebsd.

-- 
Andre


From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 19:43:17 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 7E15216A40F
	for <net@freebsd.org>; Mon, 22 Jan 2007 19:43:17 +0000 (UTC)
	(envelope-from andre@freebsd.org)
Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2])
	by mx1.freebsd.org (Postfix) with ESMTP id E737513C4A5
	for <net@freebsd.org>; Mon, 22 Jan 2007 19:43:16 +0000 (UTC)
	(envelope-from andre@freebsd.org)
Received: (qmail 84481 invoked from network); 22 Jan 2007 19:23:03 -0000
Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2])
	(envelope-sender <andre@freebsd.org>)
	by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP
	for <julian@elischer.org>; 22 Jan 2007 19:23:03 -0000
Message-ID: <45B513D2.2060602@freebsd.org>
Date: Mon, 22 Jan 2007 20:43:14 +0100
From: Andre Oppermann <andre@freebsd.org>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Julian Elischer <julian@elischer.org>
References: <200701221546.l0MFk27m081898@wattres.watt.com>
	<45B50C5B.2080600@elischer.org> <45B50D87.2050208@freebsd.org>
	<45B512A0.5030502@elischer.org>
In-Reply-To: <45B512A0.5030502@elischer.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Steve Watt <steve@Watt.COM>, Uwe Doering <gemini@geminix.org>,
	net@freebsd.org
Subject: Re: Interesting TCP issue
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 19:43:17 -0000

Julian Elischer wrote:
> Andre Oppermann wrote:
> 
>>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.290&r2=1.291 
>>>>
>>>> } 
>>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_syncache.c.diff?r1=1.84&r2=1.85 
>>>>
>>>> } 
>>>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.127&r2=1.128 
>>>>
>>>> } } How about the modifications in 'tcp_input.c'?  Are they relevant 
>>>> to the } problem this thread is about?  If so, assessing the 
>>>> correctness of an } MFC might prove to be a little harder.
>>>
>>>
>>>
>>> That's why I asked Andre to look at it but he's not responding..
>>
>> He's about to re-appear @freebsd.
>>
> 
> great.. The TCP code is a bit like a house of cards..  Unless one is
> up-to-date and has it all 'loaded' into one's mental cache, it is
> all to easy to screw up function A by fixing code related to function B.
> As I'm not 'loaded' I'm loathe to just MFC the one patch without being 
> sure what the other two are..

Yes, it's a bit messy and there are many side effects.  I've cleaned up
some parts in my local tree but it's a tedious task because it's so inter-
mingled all over.

> BTW Andre you might MFC to back to 5 and 4 too if you could..

Will look at it.

-- 
Andre


From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 23:06:53 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 129C016A400
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 23:06:53 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
	by mx1.freebsd.org (Postfix) with ESMTP id E32E513C448
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 23:06:52 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 22 Jan 2007 15:06:52 -0800
X-IronPort-AV: i="4.13,221,1167638400"; 
	d="scan'208"; a="104318098:sNHT44223822"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0MN6qNO006785; 
	Mon, 22 Jan 2007 15:06:52 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0MN6nVG029498;
	Mon, 22 Jan 2007 15:06:52 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 22 Jan 2007 15:06:51 -0800
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 22 Jan 2007 15:06:51 -0800
Message-ID: <45B5436B.7090502@cisco.com>
Date: Mon, 22 Jan 2007 18:06:19 -0500
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Andrew Gallatin <gallatin@cs.duke.edu>
References: <45B0D2E3.9050203@cisco.com>	<17841.6943.770698.707214@grasshopper.cs.duke.edu>	<45B345FD.7080001@cisco.com>
	<17844.51894.773943.99076@grasshopper.cs.duke.edu>
In-Reply-To: <17844.51894.773943.99076@grasshopper.cs.duke.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jan 2007 23:06:51.0842 (UTC)
	FILETIME=[007C3220:01C73E7A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1278; t=1169507212;
	x=1170371212; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20kern_mbuf.c=20patch |Sender:=20;
	bh=DVqfuhElcksGwVPhjg64A63i70d40KsBjkMfuUJWl+0=;
	b=sXNodZh4phZBitj0K+u/g3JjLlFX94wjrMt7IZwzeKifFrH6m70PhFamEDvdrtHjIHnnG6iH
	fnq+OWqE6MaQR4q2VURAIDTNPvEUdcC/z+YM6ip4rIdPPJmneWusT6sD;
Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim4002 verified; ); 
Cc: freebsd-net <freebsd-net@freebsd.org>
Subject: Re: kern_mbuf.c patch
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 23:06:53 -0000

Andrew Gallatin wrote:
> Randall Stewart writes:
>  > Andrew Gallatin wrote:
>  > > Randall Stewart writes:
>  > >  >  	nmbclusters = 1024 + maxusers * 64;
>  > >  > +        nmbjumbop   = 100 + (maxusers * 4);
>  > > 
>  > > The limit on page-size jumbos seems far too small.  Since the socket
>  > > buffer code now uses page-sized jumbos, I'd expect to see its limit be
>  > > the same as nmbclusters.
>  > > 
>  > > 
>  > > Drew
>  > > 
>  > Drew:
>  > 
>  > Let me re-visit this .. I started real small on purpose.. so
>  > folks would complain ;-)
>  > 
>  > How about if I calculate the number of pages the
>  > nmbclusters use (I will go look in the UMA structures) and
>  > then make it so the limit is the same number of pages
>  > (scaled like nmbclusters) for each of the larger clusters..
> 
> That sounds reasonable to me, at least for nmbjumbop, but I'm not sure
> that the larger 9k and 16k clusters are used outside of drivers, so
> the nmbclusters limit may be too large for them.  But I suppose some
> limit is better than none :)
> 
> Drew
> 
SCTP uses the best fit size for user data.. thus 16k gets used
for large messages :-)

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 23:16:26 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 1041416A401
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 23:16:26 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179])
	by mx1.freebsd.org (Postfix) with ESMTP id C3C6413C457
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 23:16:25 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from [213.141.131.138] (helo=localhost)
	by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1H98VN-0001Zi-46
	for freebsd-net@freebsd.org; Tue, 23 Jan 2007 02:23:13 +0300
Date: Mon, 22 Jan 2007 15:32:15 +0300
From: Wishmaster <wishmaster@velnet.ru>
X-Mailer: The Bat! (v2.12.00)
X-Priority: 3 (Normal)
Message-ID: <1147284745.20070122153215@velnet.ru>
To: freebsd-net@freebsd.org
In-Reply-To: <45B42FD2.2000403@delphij.net>
References: <1458229821.20070120234257@velnet.ru>
	<45B28F37.7040100@delphij.net> <2910709734.20070121043023@velnet.ru>
	<45B42FD2.2000403@delphij.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re[2]: reproducible watchdog timeout in bge
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Wishmaster <wishmaster@velnet.ru>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 23:16:26 -0000

Hello LI,

Monday, January 22, 2007, 6:30:26 AM, you wrote:

LX> Wishmaster wrote:
>> Hello LI,
>> 
>> Sunday, January 21, 2007, 12:52:55 AM, you wrote:
>> 
>> LX> Wishmaster wrote:
>>>> Hi,
>>>>
>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090
>> 
>> LX> Have you tried this one?
>> 
>> LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62
>> 
>> LX> Cheers,
>> 
>> Yes, i tried, but have no effect.
>> 
>> after reboot interface works, but if i try to ping with packet for
>> example 1500 bytes and interval 0.01s it looks like

LX> I see, so you have a different problem, which could indicate either
LX> there is a different bug in the driver that makes it, or there is some
LX> problem with your hardware :-(

LX> Cheers,

I have three different hardware configurations, and two different
Freebsd releases on them (6.1/amd64 and 6.2/i386) all of them have the
same problem.
There is more detailed description of problem here (lat post by
Wishmaster):
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090

-- 
Best regards,
 Wishmaster                            mailto:wishmaster@velnet.ru



From owner-freebsd-net@FreeBSD.ORG  Mon Jan 22 23:35:31 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 2323316A51C
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 23:35:31 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179])
	by mx1.freebsd.org (Postfix) with ESMTP id D557C13C4B7
	for <freebsd-net@freebsd.org>; Mon, 22 Jan 2007 23:35:30 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from [213.141.131.138] (helo=localhost)
	by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1H98nr-0002eH-2K
	for freebsd-net@freebsd.org; Tue, 23 Jan 2007 02:42:19 +0300
Date: Tue, 23 Jan 2007 02:34:58 +0300
From: Wishmaster <wishmaster@velnet.ru>
X-Mailer: The Bat! (v2.12.00)
X-Priority: 3 (Normal)
Message-ID: <1106181498.20070123023458@velnet.ru>
To: freebsd-net@freebsd.org
In-Reply-To: <45B4BE90.20602@qwirky.net>
References: <1458229821.20070120234257@velnet.ru>
	<45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru>
	<be0088ce0701220431tf96827et3713885fac8a490a@mail.gmail.com>
	<45B4BE90.20602@qwirky.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re[2]: reproducible watchdog timeout in bge
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Wishmaster <wishmaster@velnet.ru>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2007 23:35:31 -0000

Hello Jeff,

Monday, January 22, 2007, 4:39:28 PM, you wrote:

JR> MQ wrote:
>> 2007/1/22, Wishmaster <wishmaster@velnet.ru>:
>>>
>>> Hello LI,
>>>
>>> Sunday, January 21, 2007, 12:52:55 AM, you wrote:
>>>
>>> LX> Wishmaster wrote:
>>> >> Hi,
>>> >>
>>> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92090
>>>
>>> LX> Have you tried this one?
>>>
>>> LX> http://people.freebsd.org/~delphij/misc/patch-bge-releng62
>>>
>>> LX> Cheers,
>>>
>>> Yes, i tried, but have no effect.
>>>
>>> after reboot interface works, but if i try to ping with packet for
>>> example 1500 bytes and interval 0.01s it looks like
>>>
>>> answer
>>> answer
>>> answer
>>> ....
>>> ..... over 50 or less icmp answers then
>>> ping: sendto: No buffer space available
>>> ping: sendto: No buffer space available
>>> ping: sendto: No buffer space available
>>> ping: sendto: No buffer space available
>>> ping: sendto: No buffer space available
>>> ping: sendto: No buffer space available
>>> ping: sendto: No buffer space available
>>>
>>> in dmesg:
>>> bge0: watchdog timeout -- resetting
>>> bge0: link state changed to DOWN
>>> bge0: link state changed to UP
>>>
>>> -- 
>>> Best regards,
>>> Wishmaster                            mailto:wishmaster@velnet.ru
>>>
>> 
>> What about other NIC chips from Broadcom? And how about the packets other
>> than icmp under the same load?
>> _______________________________________________

JR> I have been unable to produce time outs with my current setup in 
JR> 6.2-Release.

JR> bge0@pci3:0:0:  class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x11
JR> hdr=0x00
JR>      vendor   = 'Broadcom Corporation'
JR>      device   = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
JR>      class    = network
JR>      subclass = ethernet

JR> Reading the PR, I attempted triggering this through CVSing and through
JR> the above mentioned ping tests.

JR> So far nothing.

JR> The only issue I have seen using these NICs in 6.2R is if I nail up the
JR> NIC at 100baseTX full-duplex I sometimes loose connectivity.  Nothing
JR> in the logs indicate watchdog timeouts or any other issue.   I simply
JR> brought the NIC back down to auto-neg and all seems fine.   I am 
JR> assuming this is a incompatibility between the BGE and my switch, RS8000.

JR> I have a Asus P5MT-S with dual BGE NIC's

JR> Cheers,

JR> Jeff
JR> _______________________________________________
JR> freebsd-net@freebsd.org mailing list
JR> http://lists.freebsd.org/mailman/listinfo/freebsd-net
JR> To unsubscribe, send any mail to
JR> "freebsd-net-unsubscribe@freebsd.org"


There are different types of broadcom chips on my hardware:

bge0: <Broadcom BCM5721 Gigabit Ethernet, ASIC rev. 0x4101>
mem 0xddef0000-0xddefffff irq 16 at device 0.0 on pci5
miibus0: <MII bus> on bge0
brgphy0: <BCM5750 10/100/1000baseTX PHY> on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto
bge0: Ethernet address: 00:15:f2:cd:21:9a

I don't have any other type of broadcom NIC to test but all other
NICs, for example Intel works correctly.

p.s. MB: ASUSTeK P5M2 /2GBL



-- 
Best regards,
 Wishmaster                            mailto:wishmaster-velnet@yandex.ru



From owner-freebsd-net@FreeBSD.ORG  Tue Jan 23 15:29:47 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 2B53116A409
	for <freebsd-net@freebsd.org>; Tue, 23 Jan 2007 15:29:47 +0000 (UTC)
	(envelope-from undelivery@le20news.com)
Received: from ns34011.ovh.net (ns34011.ovh.net [213.251.169.25])
	by mx1.freebsd.org (Postfix) with SMTP id 96B3713C474
	for <freebsd-net@freebsd.org>; Tue, 23 Jan 2007 15:29:45 +0000 (UTC)
	(envelope-from undelivery@le20news.com)
Received: (qmail 30596 invoked by uid 0); 23 Jan 2007 13:43:22 -0000
Message-ID: <20070123134322.23240.qmail@ns34011.ovh.net>
To: freebsd-net@freebsd.org
Date: Tue, 23 Jan 2007 14:10:12 +0100
From: "Emmanuel" <infos@le20news.com>
X-Mailer-ListID: 45
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Subject: Soldes -60% - Volnay 1er Cru 1992 - LIVRAISON 24H GRATUITE
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: infos@le20news.com
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2007 15:29:47 -0000


   [1][logo_le20_MAJ.gif] [2][chrono_anim_soldes.gif] 

                  Si vous n'arrivez pas à lire ce message, [3]cliquez ici

                     [4]accueil   [5]qui sommes nous ?  [6]nous contacter

   [7][header_soldes_230107.jpg] 
   Nos meilleurs vins (Bourgogne, Vallée du Rhône, Champagne)
   [8]CHOREY-LES-BEAUNE - Pierre de Chabliseau
   prix par bouteille, vendu par 12
   1999
   Rouge
   Bourgogne
   8,50 EUR

                            prix public [DEL: :DEL] [DEL: 14,50 EUR :DEL]
                                                           économisez 42%

   [9]BOURGOGNE Sang d'Anges - Ludovic Belin
   2004
   Rouge
   Bourgogne
   9,50 EUR

                            prix public [DEL: :DEL] [DEL: 12,00 EUR :DEL]

   [10]SANTENAY - Marc BOUTHENET
   prix par bouteille, vendu par 6
   2001
   Rouge
   Bourgogne
   9,80 EUR

                            prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL]
                                                           économisez 43%

   [11]CHABLIS - Jean-Claude FROMONT
   2005
   Blanc
   Bourgogne
   9,95 EUR

                            prix public [DEL: :DEL] [DEL: 13,00 EUR :DEL]

   [12]MARANGES 1er CRU - Pierre de Chabliseau
   prix par bouteille, vendu par 6
   1995
   Rouge
   Bourgogne
   9,90 EUR

                            prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL]
                                                           économisez 42%

   [13]AUXEY-DURESSES - FROMAGEOT-LECHENAULT
   [14]prix par bouteille, vendu par 6
   1999
   Rouge
   Bourgogne
   9,95 EUR

                           prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL] 
                                                économisez 42%[DEL: :DEL]

   [15]MONTAGNY 1er CRU - Jean-Pierre BERTHENET
   prix par bouteille, vendu par 6
   2003
   Blanc
   Bourgogne
   12,40 EUR

                            prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL]

   [16]SAVIGNY-LES-BEAUNE - Manoir de le BRESSANDIERE
   2002
   Rouge
   Bourgogne
   12,90 EUR

                            prix public [DEL: :DEL] [DEL: 15,50 EUR :DEL]

   [17]Muscat Beaumes de Venise - Domaine de La Pigeade
   prix par bouteille, vendu par 2
   2005
   Blanc
   Vallée du Rhône
   12,95 EUR

                            prix public [DEL: :DEL] [DEL: 19,00 EUR :DEL]
                                                           économisez 32%

   [18]SAVIGNY-LES-BEAUNE 1er Cru Aux clous - Louis CHENU
   prix par bouteille, vendu par 6
   2001
   Rouge
   Bourgogne
   12,95 EUR

                            prix public [DEL: :DEL] [DEL: 19,75 EUR :DEL]
                                                           économisez 35%

   [19]MORGON - Pierre de Chabliseau
   2004
   Rouge
   Bourgogne
   13,00 EUR

                            prix public [DEL: :DEL] [DEL: 15,00 EUR :DEL]

   [20]SAVIGNY-LES-BEAUNE 1er CRU - Pierre de Chabliseau
   prix par bouteille, vendu par 6
   2004
   Rouge
   Bourgogne
   13,75 EUR

                            prix public [DEL: :DEL] [DEL: 18,50 EUR :DEL]

   [21]SAVIGNY-LES-BEAUNES - Domaine DELAGRANGE
   1998
   Blanc
   Bourgogne
   14,00 EUR

                            prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL]
                                                           économisez 37%

   [22]BEAUNE Au Renard - Domaine de la Combe
   2004
   Rouge
   Bourgogne
   14,00 EUR

                            prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL]

   [23]MONTAGNY 1er CRU - Jean-Pierre BERTHENET
   2003
   Blanc
   Bourgogne
   14,30 EUR

                            prix public [DEL: :DEL] [DEL: 17,00 EUR :DEL]

   [24]VOLNAY - Nicolas Potel
   prix par bouteille, vendu par 6
   2002
   Rouge
   Bourgogne
   14,60 EUR

                            prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL]
                                                           économisez 42%

   [25]BEAUNE 1er CRU - Pierre de Chabliseau
   prix par bouteille, vendu par 3
   2002
   Rouge
   Bourgogne
   14,70 EUR

                            prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL]
                                                           économisez 42%

   [26]GEVREY-CHAMBERTIN - Jean-Claude FROMONT
   [27]prix par bouteille, vendu par 6
   2001
   Rouge
   Bourgogne
   14,95 EUR

                           prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL] 
                                               économisez 40% [DEL: :DEL]

   [28]BEAUNE Les Frévoles - Delagrange
   1995
   Rouge
   Bourgogne
   15,00 EUR

                            prix public [DEL: :DEL] [DEL: 21,00 EUR :DEL]

   [29]BEAUNE Vieilles Vignes - Domaine de la Combe
   2004
   Rouge
   Bourgogne
   15,00 EUR

                            prix public [DEL: :DEL] [DEL: 18,00 EUR :DEL]

   [30]BEAUNE Les Frévoles - Delagrange
   1996
   Rouge
   Bourgogne
   15,00 EUR

                            prix public [DEL: :DEL] [DEL: 21,00 EUR :DEL]

   [31]SAVIGNY-LES-BEAUNE Vieilles Vignes - Domaine Nicolas Potel
   prix par bouteille, vendu par 6
   2003
   Rouge
   Bourgogne
   15,00 EUR

                            prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL]
                                                           économisez 45%

   [32]GEVREY-CHAMBERTIN - Pierre de Chabliseau
   prix par bouteille, vendu par 6
   2001
   Rouge
   Bourgogne
   15,50 EUR

                            prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL]
                                                           économisez 38%

   [33]SANTENAY Vieilles Vignes - Nicolas Potel
   1999
   Rouge
   Bourgogne
   16,00 EUR

                            prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL]

   [34]MONTHELIE - Alexandre GAUVIN
   prix par bouteille, vendu par 6
   2004
   Blanc
   Bourgogne
   16,00 EUR

                            prix public [DEL: :DEL] [DEL: 20,00 EUR :DEL]

   [35]Côtes du Rhône CAIRANNE - Antique Séminaros
   prix par bouteille, vendu par 6
   1996
   Rouge
   Vallée du Rhône
   16,30 EUR

                            prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL]
                                                           économisez 40%

   [36]VOLNAY-SANTENOTS 1er CRU - Domaine ROUGEOT
   prix par bouteille, vendu par 3
   1991
   Rouge
   Bourgogne
   16,40 EUR

                            prix public [DEL: :DEL] [DEL: 41,00 EUR :DEL]
                                                           économisez 60%

   [37]VOLNAY-SANTENOTS 1er CRU - Domaine ROUGEOT
   prix par bouteille, vendu par 3
   1992
   Rouge
   Bourgogne
   16,40 EUR

                            prix public [DEL: :DEL] [DEL: 41,00 EUR :DEL]
                                                          économisez 60% 

   [38]ALOXE CORTON - CAVE DE NOLAY
   2005
   Rouge
   Bourgogne
   16,60 EUR

                            prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL]

   [39]GEVREY-CHAMBERTIN - Pierre de Chabliseau
   2001
   Rouge
   Bourgogne
   17,00 EUR

                            prix public [DEL: :DEL] [DEL: 25,00 EUR :DEL]
                                                           économisez 33%

   [40]CHABLIS 1ER CRU - Jean-Claude FROMONT
   2005
   Blanc
   Bourgogne
   17,00 EUR

                            prix public [DEL: :DEL] [DEL: 18,00 EUR :DEL]

   [41]SANTENAY 1er Cru - Jean-Claude FROMONT
   prix par bouteille, vendu par 6
   1992
   Rouge
   Bourgogne
   17,00 EUR

                            prix public [DEL: :DEL] [DEL: 21,00 EUR :DEL]

   [42]Châteauneuf-du-Pape - LES GRANDES SERRES
   prix par bouteille, vendu par 6
   2000
   Rouge
   Vallée du Rhône
   17,50 EUR

                            prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL]
                                                           économisez 47%

   [43]BEAUNE 1er CRU LES SIZIES - Alexandre Gauvin
   2004
   Rouge
   Bourgogne
   18,00 EUR

                            prix public [DEL: :DEL] [DEL: 23,00 EUR :DEL]

   [44]VOSNE-ROMANEE - Alexandre GAUVIN
   2002
   Rouge
   Bourgogne
   18,00 EUR

                            prix public [DEL: :DEL] [DEL: 24,00 EUR :DEL]

   [45]CHABLIS 1ER Cru Mont de Milieu - Jean-Claude FROMONT
   2005
   Blanc
   Bourgogne
   18,00 EUR

                            prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL]

   [46]PERNAND-VERGELESSES - Ludovic Belin
   prix par bouteille, vendu par 6
   2003
   Blanc
   Bourgogne
   18,00 EUR

                            prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL]

   [47]MEURSAULT - Eric Boussey
   prix par bouteille, vendu par 6
   1999
   Blanc
   Bourgogne
   19,00 EUR

                            prix public [DEL: :DEL] [DEL: 31,00 EUR :DEL]
                                                           économisez 39%

   [48]CÔTE DE NUITS-VILLAGES Le Vaucrain - Louis Jadot
   1999
   Rouge
   Bourgogne
   19,00 EUR

                            prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL]

   [49]Côtes du Rhône CAIRANNE - Antique Séminaros
   prix par bouteille, vendu par 6
   1998
   Rouge
   Vallée du Rhône
   19,28 EUR

                            prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL]

   [50]VOLNAY 1er CRU - Bernard Delagrange
   2000
   Rouge
   Bourgogne
   20,00 EUR

                            prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL]
                                                           économisez 40%

   [51]PERNAND VERGELESSES - Ludovic Belin
   2003
   Blanc
   Bourgogne
   20,00 EUR

                            prix public [DEL: :DEL] [DEL: 22,00 EUR :DEL]

   [52]MEURSAULT - Jean-Claude FROMONT
   2004
   Blanc
   Bourgogne
   20,00 EUR

                            prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL]

   [53]MEURSAULT - Delagrange
   2002
   Rouge
   Bourgogne
   20,00 EUR

                            prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL]

   [54]PERNAND-VERGELESSES - Ludovic Belin
   2002
   Blanc
   Bourgogne
   20,00 EUR

                            prix public [DEL: :DEL] [DEL: 23,00 EUR :DEL]

   [55]SAVIGNY-LES-BEAUNES - Domaine DELAGRANGE
   1990
   Blanc
   Bourgogne
   22,00 EUR

                            prix public [DEL: :DEL] [DEL: 30,00 EUR :DEL]

   [56]MEURSAULT - Jean-Claude FROMONT
   1996
   Blanc
   Bourgogne
   22,00 EUR

                            prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL]

   [57]MEURSAULT - Pierre de Chabliseau
   2004
   Blanc
   Bourgogne
   22,00 EUR

                            prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL]

   [58]PULIGNY-MONTRACHET - Stéphan Maroslavac
   prix par bouteille, vendu par 6
   1999
   Blanc
   Bourgogne
   22,00 EUR

                            prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL]

   [59]VOLNAY - Adamas
   2003
   Rouge
   Bourgogne
   22,00 EUR

                            prix public [DEL: :DEL] [DEL: 27,00 EUR :DEL]

   [60]MEURSAULT - Jean-Claude FROMONT
   1995
   Blanc
   Bourgogne
   22,00 EUR

                            prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL]

   [61]Châteauneuf-du-Pape - LES GRANDES SERRES
   2004
   Blanc
   Vallée du Rhône
   22,00 EUR

                            prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL]
                                                           économisez 34%

   [62]VOLNAY 1er Cru Vieilles vignes - Comte de Pernand
   2003
   Rouge
   Bourgogne
   23,00 EUR

                            prix public [DEL: :DEL] [DEL: 45,50 EUR :DEL]
                                                           économisez 50%

   [63]POMMARD - Christophe Thilloux
   1996
   Rouge
   Bourgogne
   23,00 EUR

                            prix public [DEL: :DEL] [DEL: 26,00 EUR :DEL]

   [64]Champagne 1er Cru Brut extra Maison Brochet Dolet - Claude BROCHET
   Blanc
   Champagne
   23,90 EUR

                            prix public [DEL: :DEL] [DEL: 35,00 EUR :DEL]
                                                           économisez 32%

   [65]ALOXE CORTON - B. DESCHAMPS-GORDO
   1999
   Rouge
   Bourgogne
   24,00 EUR

                            prix public [DEL: :DEL] [DEL: 34,00 EUR :DEL]
                                                           économisez 30%

   [66]MEURSAULT - Adamas
   2004
   Blanc
   Bourgogne
   24,00 EUR

                            prix public [DEL: :DEL] [DEL: 28,00 EUR :DEL]

   [67]CHAMBOLLE-MUSIGNY - Mallard-Gaulin
   prix par bouteille, vendu par 3
   2001
   Rouge
   Bourgogne
   24,00 EUR

                            prix public [DEL: :DEL] [DEL: 35,00 EUR :DEL]
                                                           économisez 32%

   [68]Châteauneuf-du-Pape - LES GRANDES SERRES
   2003
   Rouge
   Vallée du Rhône
   24,00 EUR

                            prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL]

   [69]PULIGNY-MONTRACHET 1er CRU Champs Gains - Stéphan Maroslavac
   prix par bouteille, vendu par 6
   2001
   Blanc
   Bourgogne
   25,00 EUR

                            prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL]

   [70]Châteauneuf-du-Pape - LES GRANDES SERRES
   2001
   Blanc
   Vallée du Rhône
   25,00 EUR

                            prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL]

   [71]MEURSAULT La Barre - Bernard Delagrange
   prix par bouteille, vendu par 3
   1991
   Blanc
   Bourgogne
   25,00 EUR

                            prix public [DEL: :DEL] [DEL: 45,00 EUR :DEL]
                                                           économisez 45%

   [72]CHAMBOLLE-MUSIGNY - CAVE DE NOLAY
   1996
   Rouge
   Bourgogne
   26,00 EUR

                            prix public [DEL: :DEL] [DEL: 35,00 EUR :DEL]

   [73]POMMARD 1er Cru Fremiers - Christophe Thilloux
   2001
   Rouge
   Bourgogne
   26,50 EUR

                            prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL]

   [74]CORTON GRAND CRU - Jean-Claude FROMONT
   prix par bouteille, vendu par 3
   2004
   Rouge
   Bourgogne
   26,90 EUR

                            prix public [DEL: :DEL] [DEL: 47,00 EUR :DEL]
                                                           économisez 43%

   [75]Châteauneuf-du-Pape - E. GUIGAL
   2000
   Rouge
   Vallée du Rhône
   27,00 EUR

                            prix public [DEL: :DEL] [DEL: 33,00 EUR :DEL]

   [76]VOLNAY 1er Cru Les Mitans - Nicolas Potel
   prix par bouteille, vendu par 3
   2003
   Rouge
   Bourgogne
   28,00 EUR

                            prix public [DEL: :DEL] [DEL: 45,50 EUR :DEL]
                                                           économisez 39%

   [77]Condrieu - Côte Chatillon - François GERARD
   prix par bouteille, vendu par 3
   2004
   Blanc
   Vallée du Rhône
   28,70 EUR

                            prix public [DEL: :DEL] [DEL: 45,00 EUR :DEL]
                                                           économisez 37%

   [78]CORTON GRAND CRU Les Grandes Lolières - Ludovic Belin
   prix par bouteille, vendu par 3
   2004
   Rouge
   Bourgogne
   32,50 EUR

                            prix public [DEL: :DEL] [DEL: 65,00 EUR :DEL]
                                                           économisez 50%

   [79]MEURSAULT 1er Cru Les Charmes - Mallard-Gaulin
   prix par bouteille, vendu par 3
   2002
   Blanc
   Bourgogne
   33,00 EUR

                            prix public [DEL: :DEL] [DEL: 41,00 EUR :DEL]

   [80]CORTON GRAND CRU - Mallard-Gaulin
   prix par bouteille, vendu par 3
   2002
   Rouge
   Bourgogne
   33,00 EUR

                            prix public [DEL: :DEL] [DEL: 49,00 EUR :DEL]
                                                           économisez 33%

   [81]CORTON VERGENNES GRAND CRU - Comte Louis de Vernicourt
   prix par bouteille, vendu par 3
   1994
   Rouge
   Bourgogne
   34,00 EUR

                            prix public [DEL: :DEL] [DEL: 52,00 EUR :DEL]
                                                           économisez 35%

   [82]NUITS SAINT GEORGES 1ER CRU Terres Blanches - Daniel RION et fils
   2004
   Blanc
   Bourgogne
   35,00 EUR

                            prix public [DEL: :DEL] [DEL: 52,00 EUR :DEL]
                                                           économisez 33%

   [83]CÔTE-RÔTIE - Domaine de Rosiers
   prix par bouteille, vendu par 3
   2003
   Rouge
   Vallée du Rhône
   35,00 EUR

                            prix public [DEL: :DEL] [DEL: 48,00 EUR :DEL]

   [84]HERMITAGE - Les Miaux - Ferraton Père & Fils
   prix par bouteille, vendu par 3
   2000
   Rouge
   Vallée du Rhône
   35,00 EUR

                            prix public [DEL: :DEL] [DEL: 45,00 EUR :DEL]

   [85]BEAUNE - Gaston Boisseaux
   1986
   Rouge
   Bourgogne
   36,00 EUR

                            prix public [DEL: :DEL] [DEL: 50,00 EUR :DEL]

   [86]NUITS SAINT GEORGES 1er CRU Aux Argillats - Martin-Dufour
   2003
   Rouge
   Bourgogne
   37,00 EUR

                            prix public [DEL: :DEL] [DEL: 45,00 EUR :DEL]

   [87]BEAUNE - Gaston Boisseaux
   1985
   Rouge
   Bourgogne
   37,00 EUR

                            prix public [DEL: :DEL] [DEL: 50,00 EUR :DEL]

   [88]MAGNUM RULLY - Joseph Drouhin
   2004
   Blanc
   Bourgogne
   38,00 EUR

                            prix public [DEL: :DEL] [DEL: 49,00 EUR :DEL]

   [89]CHARMES-CHAMBERTIN - Jules Belin
   2002
   Rouge
   Bourgogne
   38,00 EUR

                            prix public [DEL: :DEL] [DEL: 76,00 EUR :DEL]
                                                           économisez 50%

   [90]Châteauneuf-du-Pape - Château Cabrières
   1995
   Rouge
   Vallée du Rhône
   38,00 EUR

                            prix public [DEL: :DEL] [DEL: 55,00 EUR :DEL]
                                                           économisez 31%

   [91]CÔTE-RÔTIE Côte Brune - Domaine de Bonserine
   1994
   Rouge
   Vallée du Rhône
   39,00 EUR

                            prix public [DEL: :DEL] [DEL: 48,00 EUR :DEL]

   [92]CÔTE-RÔTIE Côte Brune - Domaine de Bonserine
   1994
   Rouge
   Vallée du Rhône
   39,00 EUR

                            prix public [DEL: :DEL] [DEL: 48,00 EUR :DEL]

   [93]NUITS SAINT GEORGES 1er CRU Aux Argillats - Martin-Dufour
   2001
   Rouge
   Bourgogne
   39,24 EUR

                            prix public [DEL: :DEL] [DEL: 47,00 EUR :DEL]

   [94]PULIGNY-MONTRACHET 1er CRU Les Perrières - Jean-Claude FROMONT
   1988
   Blanc
   Bourgogne
   39,95 EUR

                            prix public [DEL: :DEL] [DEL: 65,00 EUR :DEL]
                                                           économisez 39%

   [95]CORTON-CHARLEMAGNE GRAND CRU - Ludovic Belin
   prix par bouteille, vendu par 2
   2004
   Blanc
   Bourgogne
   44,00 EUR

                            prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL]
                                                           économisez 38%

   [96]CHARMES-CHAMBERTIN Grand Cru - Nicolas Potel
   prix par bouteille, vendu par 3
   2002
   Rouge
   Bourgogne
   46,00 EUR

                            prix public [DEL: :DEL] [DEL: 86,00 EUR :DEL]
                                                           économisez 47%

   [97]Châteauneuf-du-Pape - Château Cabrières
   1990
   Rouge
   Vallée du Rhône
   48,00 EUR

                            prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL]
                                                           économisez 32%

   [98]Châteauneuf-du-Pape - Domaine du Haut des Terres Blanches
   1977
   Rouge
   Vallée du Rhône
   51,00 EUR

                            prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL]

   [99]Châteauneuf-du-Pape - Château Cabrières
   1986
   Rouge
   Vallée du Rhône
   54,00 EUR

                            prix public [DEL: :DEL] [DEL: 90,00 EUR :DEL]
                                                           économisez 41%

   [100]CHAMBOLLE-MUSIGNY - Jaboulet Verchère
   1975
   Rouge
   Bourgogne
   55,00 EUR

                            prix public [DEL: :DEL] [DEL: 72,00 EUR :DEL]

   [101]Châteauneuf-du-Pape - Domaine du Haut des Terres Blanches
   1972
   Rouge
   Vallée du Rhône
   56,00 EUR

                            prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL]

   [102]Châteauneuf-du-Pape - Domaine du Haut des Terres Blanches
   1971
   Rouge
   Vallée du Rhône
   56,00 EUR

                            prix public [DEL: :DEL] [DEL: 70,00 EUR :DEL]

   [103]CHARMES-CHAMBERTIN - Camus Père et fils
   1997
   Rouge
   Bourgogne
   60,00 EUR

                            prix public [DEL: :DEL] [DEL: 96,00 EUR :DEL]
                                                           économisez 38%

   [104]Châteauneuf-du-Pape - Château Cabrières
   1984
   Rouge
   Vallée du Rhône
   62,00 EUR

                            prix public [DEL: :DEL] [DEL: 90,00 EUR :DEL]
                                                           économisez 32%

   [105]CLOS VOUGEOT Grand Cru - Daniel Rion et fils
   2000
   Rouge
   Bourgogne
   73,00 EUR

                           prix public [DEL: :DEL] [DEL: 125,00 EUR :DEL]
                                                           économisez 42%

   [106]Châteauneuf-du-Pape - Château Cabrières
   1981
   Rouge
   Vallée du Rhône
   75,00 EUR

                            prix public [DEL: :DEL] [DEL: 90,00 EUR :DEL]

   [107]Châteauneuf-du-Pape - Château Cabrières
   1979
   Rouge
   Vallée du Rhône
   85,00 EUR

                           prix public [DEL: :DEL] [DEL: 110,00 EUR :DEL]

   [108]CHATEAU DE POMMARD - Jean-Louis Laplanche
   1974
   Rouge
   Bourgogne
   90,00 EUR

                           prix public [DEL: :DEL] [DEL: 110,00 EUR :DEL]

   [109]RICHEBOURG Grand Cru - Domaine Marc ROUGEOT-DUPIN
   1991
   Rouge
   Bourgogne
   98,00 EUR

                           prix public [DEL: :DEL] [DEL: 190,00 EUR :DEL]
                                                           économisez 49%

   [110]ROMANEE SAINT-VIVANT Grand Cru - P. Misserey
   1988
   Rouge
   Bourgogne
   98,00 EUR

                           prix public [DEL: :DEL] [DEL: 170,00 EUR :DEL]
                                                           économisez 43%

   [111]Champagne BOLLINGER R.D. - BOLLINGER
   1981
   Blanc
   Champagne
   195,00 EUR

                             prix public [DEL: :DEL] [DEL: 0,00 EUR :DEL]

   [112]Dom Ruinart Rosé - Ruinart
   1976
   Rosé
   Champagne
   198,00 EUR

                           prix public [DEL: :DEL] [DEL: 245,00 EUR :DEL]

   [113]Moët & Chandon Brut Impérial - Moët & Chandon
   1971
   Rosé
   Champagne
   198,00 EUR

                           prix public [DEL: :DEL] [DEL: 245,00 EUR :DEL]

   Offre valable dans la limite des stocks disponibles
   
   [footer_left_corner.gif]

    [114]Expéditions & retours    [115]Remarques sur la confidentialité
            [116]Conditions d'utilisation    [117]nous contacter

                                                [footer_right_corner.gif]

   "A tout moment, vous disposez d'un droit d'accès, de modification, de
   rectification et de suppression des données qui vous concernent" (art
    34 de la loi Informatique et Libertés du 6 Janvier 1978). Pour vous
             désinscrire de nos mailing lists, [118]cliquez ici

   L'abus d'alcool est dangereux pour la santé, consommez avec
   modération.                                 le20.fr - Copyright © 2005

   le20.fr, 17 rue Berlier, 21000 DIJON - SARL AU CAPITAL DE 15 000 euros
                          - RCS DIJON 480 509 769

   [sendopen.php?MemberID=2857279&SendID=520&Type=Send]

References

   Visible links
   1. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3115
   2. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3115
   3. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3112
   4. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3115
   5. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3005
   6. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3113
   7. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3115
   8. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3061
   9. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3019
  10. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3104
  11. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3100
  12. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3066
  13. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3049
  14. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3066
  15. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3090
  16. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3103
  17. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3012
  18. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3060
  19. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3065
  20. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3064
  21. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3024
  22. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3021
  23. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3094
  24. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3089
  25. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3101
  26. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3075
  27. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3082
  28. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3023
  29. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3020
  30. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3106
  31. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3078
  32. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3062
  33. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3110
  34. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3080
  35. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3084
  36. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3053
  37. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3068
  38. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3044
  39. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3063
  40. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3072
  41. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3054
  42. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3082
  43. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3105
  44. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3099
  45. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3039
  46. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3092
  47. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3077
  48. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3076
  49. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3083
  50. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3007
  51. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3107
  52. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3102
  53. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3109
  54. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3108
  55. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3025
  56. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3013
  57. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3098
  58. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3056
  59. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3086
  60. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3014
  61. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3010
  62. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3016
  63. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3052
  64. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3026
  65. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3069
  66. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3091
  67. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3037
  68. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3079
  69. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3055
  70. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3011
  71. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3070
  72. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3038
  73. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3087
  74. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3096
  75. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3022
  76. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3081
  77. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3046
  78. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3017
  79. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3035
  80. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3036
  81. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3071
  82. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3097
  83. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3015
  84. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3008
  85. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3041
  86. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3034
  87. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3040
  88. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3073
  89. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3085
  90. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3027
  91. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3043
  92. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3074
  93. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3095
  94. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3009
  95. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3018
  96. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3088
  97. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3028
  98. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3047
  99. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3029
 100. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3033
 101. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3048
 102. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3050
 103. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3042
 104. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3030
 105. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3093
 106. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3031
 107. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3032
 108. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3045
 109. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3067
 110. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3051
 111. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3059
 112. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3058
 113. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3057
 114. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3006
 115. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3111
 116. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3114
 117. http://www.le20newsletters.com/users/link.php?UserID=2857279&Newsletter=68&List=45&LinkType=Send&LinkID=3113
 118. http://www.le20newsletters.com/users/unsub.php?Mem=2857279&ConfirmCode=bbdcb47bc8f2dd48a28dd559bff1fcf7

   Hidden links:
 119. mailto:infos@le20.fr
 120. mailto:infos@le20.fr
 121. mailto:infos@le20.fr
 122. mailto:infos@le20.fr

From owner-freebsd-net@FreeBSD.ORG  Tue Jan 23 16:43:06 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 4079C16A405
	for <freebsd-net@freebsd.org>; Tue, 23 Jan 2007 16:43:06 +0000 (UTC)
	(envelope-from jhall@vandaliamo.net)
Received: from trueband.net (trueband.net [216.163.120.10])
	by mx1.freebsd.org (Postfix) with SMTP id C20FB13C4D3
	for <freebsd-net@freebsd.org>; Tue, 23 Jan 2007 16:43:05 +0000 (UTC)
	(envelope-from jhall@vandaliamo.net)
Received: (qmail 16071 invoked by uid 1006); 23 Jan 2007 16:15:04 -0000
Received: from jhall@vandaliamo.net by rs0 by uid 1003 with qmail-scanner-1.16
	(spamassassin: 3.1.4.  Clear:SA:0(1.0/100.0):. 
	Processed in 1.910398 secs); 23 Jan 2007 16:15:04 -0000
X-Spam-Status: No, hits=1.0 required=100.0
X-Spam-Level: *
Received: from unknown (HELO trueband.net) (172.16.0.12)
	by -v with SMTP; 23 Jan 2007 16:15:02 -0000
Received: (qmail 18384 invoked from network); 23 Jan 2007 16:15:02 -0000
Received: from unknown (HELO admintool.trueband.net) (127.0.0.1)
	by -v with SMTP; 23 Jan 2007 16:15:02 -0000
Received: from 65.117.48.154
	(SquirrelMail authenticated user jhall@vandaliamo.net)
	by admintool.trueband.net with HTTP;
	Tue, 23 Jan 2007 16:15:02 -0000 (GMT)
Message-ID: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net>
Date: Tue, 23 Jan 2007 16:15:02 -0000 (GMT)
From: jhall@vandaliamo.net
To: freebsd-net@freebsd.org
User-Agent: SquirrelMail/1.4.4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: VLANs and DHCP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2007 16:43:06 -0000

I currently administer a system which has two DHCP servers on two
different VLANs.  Unfortunately, the two servers are not playing together
well and some comptuers are receiving IP addresses on the wrong network. 
So, with our phone vendor's blessing, I am trying to move all of the DHCP
services to the FreeBSD server.

The computers on the network are supposed to receive an IP address on the
default vlan and the phones are supposed to receive an IP address on their
vlan.

Essentially what happens when a phone is booted, the phone receives an IP
address on the default VLAN, releases that address and then requests an IP
address on the appropriate VLAN.

How do I specify to FreeBSD which VLAN should be the default?  I have read
some information which seems to be conflicting.  One article indicated
vlan0 is the default vlan, and another seemed to indicate vlan1 was the
default vlan.

Or, have I just overcomplicated this?

Thanks for your help.



Jay


From owner-freebsd-net@FreeBSD.ORG  Tue Jan 23 16:48:09 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 9B3CF16A403;
	Tue, 23 Jan 2007 16:48:09 +0000 (UTC)
	(envelope-from bmah@freebsd.org)
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5])
	by mx1.freebsd.org (Postfix) with ESMTP id 7EE4E13C45D;
	Tue, 23 Jan 2007 16:48:09 +0000 (UTC)
	(envelope-from bmah@freebsd.org)
Received: from [192.168.26.75] (64-84-9-2-sf-gw.ncircle.com [64.84.9.2])
	(authenticated bits=0)
	by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id
	l0NGm4XV016006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 23 Jan 2007 08:48:06 -0800
Message-ID: <45B63C3E.9010808@freebsd.org>
Date: Tue, 23 Jan 2007 08:47:58 -0800
From: "Bruce A. Mah" <bmah@freebsd.org>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Dimitry Andric <dimitry@andric.com>
References: <20070120162936.GA18104@tomcat.kitchenlab.org>	<20070121.020741.59649277.hrs@allbsd.org>	<45B251A5.4000209@freebsd.org>
	<45B3CA56.4040106@andric.com>	<45B421D4.2050008@freebsd.org>
	<45B48F0C.9090809@andric.com>
In-Reply-To: <45B48F0C.9090809@andric.com>
X-Enigmail-Version: 0.94.1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig3FD97F734167E6F5E0E2A499"
Cc: freebsd-net@freebsd.org, Hiroki Sato <hrs@freebsd.org>,
	freebsd-stable@freebsd.org, jhay@freebsd.org
Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2007 16:48:09 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3FD97F734167E6F5E0E2A499
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If memory serves me right, Dimitry Andric wrote:
> Bruce A. Mah wrote:
>>> and later I found out it was caused by commit 1.48.2.16:
>>> http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/03185=
3.html
>> This isn't consistent with what I'm finding.  For one thing, rev.
>> 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there
>> anyways.  Also, that's not the change I made to my local sources to ge=
t
>> my gif(4) tunnel working.  Are you sure about this?  :-)
>=20
> I'm following -STABLE, and 1.48.2.16 is in there.  Since it was
> committed on 29 Nov, I suspected it would end up in -RELEASE, but
> apparently not. :)
>=20
> I explicitly tried reverting just this one commit, and for me it solved=

> the problem (i.e. the automagical addition of needed routing entries).

I tried this too and it didn't help.  :-(

Just to confirm, you're dealing with a gif(4) interface with an
explicitly-configured destination address and a 128-bit prefixlen, yes?

> So for you, reverting the combination of 1.48.2.14 and .15 works?

Yep.  BTW these two changes really go together, so it doesn't really
make sense to revert just one of them (the commit logs implied that this
 would be fairly broken in other ways).

> Maybe
> there is something else involved too, for example the route command
> itself?

Not sure what you mean by this exactly...???...

Here's what I've tested so far...in the table below, "work" means that
the host route to the destination got installed correctly and "no work"
means that it didn't.

Base		Local Patch			Result
----		-----------			------
6.2-RELEASE	Unmodified			No work
6.2-RELEASE	Revert nd6.c 1.48.2.{14,15}	Work
6.2-STABLE	Unmodified			No work
6.2-STABLE	Revert nd6.c 1.48.2.{14,15}	Work
6.2-STABLE	Revert nd6.c 1.48.2.16		No work

I'm going to write up an entry for the 6.2-RELEASE errata notes
documenting the existence of a problem and a workaround.  We still need
to figure out exactly what the right fix is.  Testing results from other
users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome.

Bruce.


--------------enig3FD97F734167E6F5E0E2A499
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFtjw+2MoxcVugUsMRAtqCAKDLjhYA+KIyxLDcsWMPUqUPktHy1QCdG2pL
a5DO4JF6QFuYE9xf+z7WNng=
=YYxb
-----END PGP SIGNATURE-----

--------------enig3FD97F734167E6F5E0E2A499--

From owner-freebsd-net@FreeBSD.ORG  Tue Jan 23 17:52:40 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 9906116A402
	for <freebsd-net@freebsd.org>; Tue, 23 Jan 2007 17:52:40 +0000 (UTC)
	(envelope-from dc@dcoder.net)
Received: from mail0.dcoder.net (ns0.dcoder.net [66.92.160.14])
	by mx1.freebsd.org (Postfix) with ESMTP id 6DBAF13C441
	for <freebsd-net@freebsd.org>; Tue, 23 Jan 2007 17:52:40 +0000 (UTC)
	(envelope-from dc@dcoder.net)
Received: by mail0.dcoder.net (Postfix, from userid 1001)
	id 348941700D; Tue, 23 Jan 2007 12:27:12 -0500 (EST)
Date: Tue, 23 Jan 2007 12:27:12 -0500
From: david coder <dc@dcoder.net>
To: freebsd-net@freebsd.org
Message-ID: <20070123172712.GA40770@mail0.dcoder.net>
Mail-Followup-To: freebsd-net@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
User-Agent: Mutt/1.4.2.2i
Subject: Attansic ethernet controller
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2007 17:52:40 -0000

The Asus P5B-E motherboard on-board ethernet controller is the Attansic
L1 PCI-E [copper] Gigabit LAN controller.  I don't need the gigabit but I
would like the 100MB.  As far as I can see, 6.x doesn't support this
controller.  Am I wrong?  Does anybody have a patch?

Thx.

Cheers,

David Coder
Network Engineer Emeritus, Verio/NTT
Telluride, CO & Washington, DC


From owner-freebsd-net@FreeBSD.ORG  Tue Jan 23 21:30:07 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 16E5B16A403;
	Tue, 23 Jan 2007 21:30:07 +0000 (UTC)
	(envelope-from dimitry@andric.com)
Received: from tensor.andric.com (tensor.andric.com [213.154.244.69])
	by mx1.freebsd.org (Postfix) with ESMTP id BA4AA13C459;
	Tue, 23 Jan 2007 21:30:06 +0000 (UTC)
	(envelope-from dimitry@andric.com)
Received: from [192.168.0.3] (kilgore.lan.dim [192.168.0.3])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by tensor.andric.com (Postfix) with ESMTP id BA0A7B80E;
	Tue, 23 Jan 2007 21:57:06 +0100 (CET)
Message-ID: <45B676A2.5090009@andric.com>
Date: Tue, 23 Jan 2007 21:57:06 +0100
From: Dimitry Andric <dimitry@andric.com>
User-Agent: Thunderbird 3.0a1 (Windows/20070122)
MIME-Version: 1.0
To: "Bruce A. Mah" <bmah@freebsd.org>
References: <20070120162936.GA18104@tomcat.kitchenlab.org>	<20070121.020741.59649277.hrs@allbsd.org>	<45B251A5.4000209@freebsd.org>
	<45B3CA56.4040106@andric.com>	<45B421D4.2050008@freebsd.org>
	<45B48F0C.9090809@andric.com> <45B63C3E.9010808@freebsd.org>
In-Reply-To: <45B63C3E.9010808@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org, Hiroki Sato <hrs@freebsd.org>,
	freebsd-stable@freebsd.org, jhay@freebsd.org
Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jan 2007 21:30:07 -0000

Bruce A. Mah wrote:
> Just to confirm, you're dealing with a gif(4) interface with an
> explicitly-configured destination address and a 128-bit prefixlen, yes?

Yes.  The specific line in my rc.conf is:

ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 2001:7b8:2ff:146::1 prefixlen 128"


>> Maybe
>> there is something else involved too, for example the route command
>> itself?
> Not sure what you mean by this exactly...???...

I mean that it may be that between -RELEASE and -STABLE, other things
have changed, e.g. network rc scripts, /sbin/route itself, etc, which
may also influence this behaviour.  I'm sure more than only nd6.c
changed. :)

However, for me, with the whole system at -STABLE (as of Jan 11), I
verified the following results again just now:

nd6.c rev	state
---------	-----
1.48.2.12	works
1.48.2.13	works
1.48.2.14	works
1.48.2.15	works
1.48.2.16	doesn't work


> Here's what I've tested so far...in the table below, "work" means that
> the host route to the destination got installed correctly and "no work"
> means that it didn't.
> 
> Base		Local Patch			Result
> ----		-----------			------
> 6.2-RELEASE	Unmodified			No work
> 6.2-RELEASE	Revert nd6.c 1.48.2.{14,15}	Work
> 6.2-STABLE	Unmodified			No work
> 6.2-STABLE	Revert nd6.c 1.48.2.{14,15}	Work
> 6.2-STABLE	Revert nd6.c 1.48.2.16		No work

So strangely, this is different from my results... I can't install
6.2-RELEASE on the specific box, alas.


> I'm going to write up an entry for the 6.2-RELEASE errata notes
> documenting the existence of a problem and a workaround.  We still need
> to figure out exactly what the right fix is.  Testing results from other
> users (both 6.2-RELEASE and 6.2-STABLE) would be most welcome.

Just FYI, my initial alternative workaround was to use prefixlen 126,
e.g.:

ipv6_ifconfig_gif0="2001:7b8:2ff:146::2 prefixlen 126"

Cheers,
Dimitry

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 00:28:30 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 4E74516A401
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 00:28:30 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from moutng.kundenserver.de (moutng.kundenserver.de
	[212.227.126.186])
	by mx1.freebsd.org (Postfix) with ESMTP id DBD1913C442
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 00:28:29 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from [88.64.177.213] (helo=amd64.laiers.local)
	by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis),
	id 0MKwh2-1H9W020gPN-0004YP; Wed, 24 Jan 2007 01:28:27 +0100
From: Max Laier <max@love2party.net>
Organization: FreeBSD
To: freebsd-net@freebsd.org
Date: Wed, 24 Jan 2007 01:28:19 +0100
User-Agent: KMail/1.9.5
References: <20070123172712.GA40770@mail0.dcoder.net>
In-Reply-To: <20070123172712.GA40770@mail0.dcoder.net>
X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGd<hB5S>u+2];
	R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2112153.pvrDaJQMWI";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200701240128.25363.max@love2party.net>
X-Provags-ID: kundenserver.de abuse@kundenserver.de
	login:61c499deaeeba3ba5be80f48ecc83056
X-Provags-ID2: V01U2FsdGVkX1+PWMojqE1VD3Ftk174F+rYf0QDW4LFFKXYjaBULKKQxcq0pmoNt2Y5aAcATZqZNA5mf19ByMu+N3POSkTzxkgUsk3sbSHymjQuN2EEqxrXZA==
Cc: david coder <dc@dcoder.net>
Subject: Re: Attansic ethernet controller
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 00:28:30 -0000

--nextPart2112153.pvrDaJQMWI
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 23 January 2007 18:27, david coder wrote:
> The Asus P5B-E motherboard on-board ethernet controller is the Attansic
> L1 PCI-E [copper] Gigabit LAN controller.  I don't need the gigabit but
> I would like the 100MB.  As far as I can see, 6.x doesn't support this
> controller.  Am I wrong?  Does anybody have a patch?

Can you provide "pciconf -vl" of that box?

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart2112153.pvrDaJQMWI
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQBFtqgpXyyEoT62BG0RAhoBAJ0QJQp1Eej0yKL9E1xWGTnJqB9bSgCggSgx
6LRqATiRQt66Z0W0pIM3IPM=
=8soT
-----END PGP SIGNATURE-----

--nextPart2112153.pvrDaJQMWI--

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 01:16:24 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 87B0A16A408
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 01:16:24 +0000 (UTC)
	(envelope-from pyunyh@gmail.com)
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225])
	by mx1.freebsd.org (Postfix) with ESMTP id 5808113C4EC
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 01:16:18 +0000 (UTC)
	(envelope-from pyunyh@gmail.com)
Received: by wx-out-0506.google.com with SMTP id s18so27412wxc
	for <freebsd-net@freebsd.org>; Tue, 23 Jan 2007 17:16:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:date:from:to:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent;
	b=Th1haaEORlEQqrX5kYT2QoG4m4UkJ+yXMxNEXHmLtK+4yXCBIKDHPHvWHbvsOuJBoVn8aqyWXH60heJp3zz/6G/FFJ9EJQt/qwmxtbn5xVUqoPG5tGLmWlXxQ2l4lDx8wPe0v284WI06nmAerdcXICYEcV6acXfY0a29ibqGX4c=
Received: by 10.70.87.5 with SMTP id k5mr169594wxb.1169599726344;
	Tue, 23 Jan 2007 16:48:46 -0800 (PST)
Received: from michelle.cdnetworks.co.kr ( [211.53.35.84])
	by mx.google.com with ESMTP id 35sm207956wra.2007.01.23.16.48.44;
	Tue, 23 Jan 2007 16:48:45 -0800 (PST)
Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr
	[127.0.0.1])
	by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id
	l0O0o6Ec037976
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 09:50:06 +0900 (KST)
	(envelope-from pyunyh@gmail.com)
Received: (from yongari@localhost)
	by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l0O0o6R1037975
	for freebsd-net@freebsd.org; Wed, 24 Jan 2007 09:50:06 +0900 (KST)
	(envelope-from pyunyh@gmail.com)
Date: Wed, 24 Jan 2007 09:50:06 +0900
From: Pyun YongHyeon <pyunyh@gmail.com>
To: freebsd-net@freebsd.org
Message-ID: <20070124005006.GA37721@cdnetworks.co.kr>
References: <20070123172712.GA40770@mail0.dcoder.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070123172712.GA40770@mail0.dcoder.net>
User-Agent: Mutt/1.4.2.1i
Subject: Re: Attansic ethernet controller
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: pyunyh@gmail.com
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 01:16:24 -0000

On Tue, Jan 23, 2007 at 12:27:12PM -0500, david coder wrote:
 > The Asus P5B-E motherboard on-board ethernet controller is the Attansic
 > L1 PCI-E [copper] Gigabit LAN controller.  I don't need the gigabit but I
 > would like the 100MB.  As far as I can see, 6.x doesn't support this
 > controller.  Am I wrong?  Does anybody have a patch?
 > 

I think FreeBSD has no driver support for Attansic L1 Gigabit
Ethernet. It seems that the Attansic L1 is used on onboard network
devices(LOM) for Asus M2V, P5B-E and P5L-VM 1394 etc. I don't know
there are publicly available documentations for the hardware but it
seems that Linux already has an experimental driver for the hardware.
I don't have the hardware so writing a driver for the hardware is
not possible to me but other developers that have the hardware can
help you.

-- 
Regards,
Pyun YongHyeon

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 01:47:56 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 9FF9216A400
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 01:47:56 +0000 (UTC)
	(envelope-from dougb@FreeBSD.org)
Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4])
	by mx1.freebsd.org (Postfix) with SMTP id 2447513C4C7
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 01:47:55 +0000 (UTC)
	(envelope-from dougb@FreeBSD.org)
Received: (qmail 10936 invoked by uid 399); 24 Jan 2007 01:21:13 -0000
Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1)
	by localhost with SMTP; 24 Jan 2007 01:21:13 -0000
X-Originating-IP: 127.0.0.1
Message-ID: <45B6B486.6030708@FreeBSD.org>
Date: Tue, 23 Jan 2007 17:21:10 -0800
From: Doug Barton <dougb@FreeBSD.org>
Organization: http://www.FreeBSD.org/
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: jhall@vandaliamo.net
References: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net>
In-Reply-To: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: VLANs and DHCP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 01:47:56 -0000

jhall@vandaliamo.net wrote:
> I currently administer a system which has two DHCP servers on two
> different VLANs.  Unfortunately, the two servers are not playing together
> well and some comptuers are receiving IP addresses on the wrong network. 
> So, with our phone vendor's blessing, I am trying to move all of the DHCP
> services to the FreeBSD server.
> 
> The computers on the network are supposed to receive an IP address on the
> default vlan and the phones are supposed to receive an IP address on their
> vlan.
> 
> Essentially what happens when a phone is booted, the phone receives an IP
> address on the default VLAN, releases that address and then requests an IP
> address on the appropriate VLAN.
> 
> How do I specify to FreeBSD which VLAN should be the default?  I have read
> some information which seems to be conflicting.  One article indicated
> vlan0 is the default vlan, and another seemed to indicate vlan1 was the
> default vlan.
> 
> Or, have I just overcomplicated this?

You have a DHCP configuration problem, not a FreeBSD problem. You'd be
better off posting to a DHCP list.

What you want to investigate between now and then is whether the
phones are sending a client identifier that you could ignore in your
computer dhcp conf file, and/or explicitly listing the MAC addresses
of whichever set of devices has the fewest members, and then giving
every other client an address on the vlan that you configure in dhcp
to be the default.

hth,

Doug

-- 

    This .signature sanitized for your protection

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 02:18:39 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 0062E16A404
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 02:18:38 +0000 (UTC)
	(envelope-from edwin@mavetju.org)
Received: from mail4out.barnet.com.au (mail4.barnet.com.au [202.83.178.125])
	by mx1.freebsd.org (Postfix) with ESMTP id 8F1BB13C44B
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 02:18:38 +0000 (UTC)
	(envelope-from edwin@mavetju.org)
Received: by mail4out.barnet.com.au (Postfix, from userid 1001)
	id 7377E37B92A; Wed, 24 Jan 2007 13:00:28 +1100 (EST)
X-Viruscan-Id: <45B6BDBC0000CA8E3A6A24@BarNet>
Received: from mail4auth.barnet.com.au (mail4.barnet.com.au [202.83.178.125])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mail4.barnet.com.au (Postfix) with ESMTP id 41E5D423B1E;
	Wed, 24 Jan 2007 13:00:28 +1100 (EST)
Received: from k7.mavetju (k7.mavetju.org [10.251.1.18])
	by mail4auth.barnet.com.au (Postfix) with ESMTP id F30AE37B913;
	Wed, 24 Jan 2007 13:00:27 +1100 (EST)
Received: by k7.mavetju (Postfix, from userid 1001)
	id DA095190; Wed, 24 Jan 2007 13:00:27 +1100 (EST)
Date: Wed, 24 Jan 2007 13:00:27 +1100
From: Edwin Groothuis <edwin@mavetju.org>
To: jhall@vandaliamo.net
Message-ID: <20070124020027.GC90167@k7.mavetju>
References: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net>
User-Agent: Mutt/1.4.2.1i
Cc: freebsd-net@freebsd.org
Subject: Re: VLANs and DHCP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 02:18:39 -0000

On Tue, Jan 23, 2007 at 04:15:02PM -0000, jhall@vandaliamo.net wrote:
> I currently administer a system which has two DHCP servers on two
> different VLANs.  Unfortunately, the two servers are not playing together
> well and some comptuers are receiving IP addresses on the wrong network. 
> So, with our phone vendor's blessing, I am trying to move all of the DHCP
> services to the FreeBSD server.
> 
> The computers on the network are supposed to receive an IP address on the
> default vlan and the phones are supposed to receive an IP address on their
> vlan.
> 
> Essentially what happens when a phone is booted, the phone receives an IP
> address on the default VLAN, releases that address and then requests an IP
> address on the appropriate VLAN.

Sounds like you're using Cisco phones and the isc-dhcp server (or
relay-agent)...

Try net/dhcprelay from the ports collection. Let it forward the
DHCP requests to a central server, and all will be fine.

The isc-dhcrelay is euhm... quite noisy.

Edwin

-- 
Edwin Groothuis      |            Personal website: http://www.mavetju.org
edwin@mavetju.org    |          Weblog: http://weblog.barnet.com.au/edwin/

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 03:21:53 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 885B816A400
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 03:21:53 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71])
	by mx1.freebsd.org (Postfix) with ESMTP id 629B113C47E
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 03:21:53 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-2.cisco.com with ESMTP; 23 Jan 2007 19:21:53 -0800
X-IronPort-AV: i="4.13,227,1167638400"; 
	d="2'?scan'208"; a="357541034:sNHT133767124"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0O3LqXS017290
	for <freebsd-net@freebsd.org>; Tue, 23 Jan 2007 19:21:52 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0O3LgGs026543
	for <freebsd-net@freebsd.org>; Tue, 23 Jan 2007 19:21:51 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 Jan 2007 19:21:42 -0800
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 Jan 2007 19:21:42 -0800
Message-ID: <45B679F3.3080407@cisco.com>
Date: Tue, 23 Jan 2007 16:11:15 -0500
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: freebsd-net <freebsd-net@freebsd.org>
Content-Type: multipart/mixed; boundary="------------080208020809070508020709"
X-OriginalArrivalTime: 24 Jan 2007 03:21:42.0052 (UTC)
	FILETIME=[C492D640:01C73F66]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6477; t=1169608912;
	x=1170472912; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20mbuf=20patch=20with=20sysctl=20suggestions=20too
	|Sender:=20; bh=FNcZlcIOvJ98pW41DmLAe1t47gH7+sSrwoobfwh40R8=;
	b=HKhAQo7qUp4iJY/hOJIpqo+Rlw7PpQILdKPAWoFJNSkpj67238wXalOAzFq1NTEy6OsotvJP
	HbHr1yKoIECCyJ/3SjxSjQLxFeoVhTfiN2C7y4bdl7W+jVct67mJ0iv0;
Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim4002 verified; ); 
Subject: mbuf patch with sysctl suggestions too
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 03:21:53 -0000

This is a multi-part message in MIME format.
--------------080208020809070508020709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi all:

Here is iteration 2 of the mbuf patch with limits I
proposed.

Also note the changes for sysctl stuff that Lugi suggested.
Please let me know what you think :-)

R
-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

--------------080208020809070508020709
Content-Type: text/plain;
 name="patch.mbuf.2"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch.mbuf.2"

Index: kern/kern_mbuf.c
===================================================================
RCS file: /usr/FreeBSD/src/sys/kern/kern_mbuf.c,v
retrieving revision 1.27
diff -u -r1.27 kern_mbuf.c
--- kern/kern_mbuf.c	22 Oct 2006 11:52:13 -0000	1.27
+++ kern/kern_mbuf.c	23 Jan 2007 17:55:21 -0000
@@ -106,8 +106,19 @@
 {
 
 	/* This has to be done before VM init. */
-	nmbclusters = 1024 + maxusers * 64;
+	nmbclusters = 1024 + (maxusers * 64);
+        nmbjumbop   = 512  + (maxusers * 32);
+	/* 9k pages take 3 pages, so you get
+	 * 1/3 of the limit of nmbjumbop. 16k
+	 * pages take 4 pages, so you get 
+	 * 1/4 of the limit of nmbjumbop.
+	 */
+        nmbjumbo9   = nmbjumbop/3;
+        nmbjumbo16  = nmbjumbop/4;
 	TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters);
+	TUNABLE_INT_FETCH("kern.ipc.nmbjumbop", &nmbjumbop);
+	TUNABLE_INT_FETCH("kern.ipc.nmbjumbo9", &nmbjumbo9);
+	TUNABLE_INT_FETCH("kern.ipc.nmbjumbo16", &nmbjumbo16);
 }
 SYSINIT(tunable_mbinit, SI_SUB_TUNABLES, SI_ORDER_ANY, tunable_mbinit, NULL);
 
@@ -118,26 +129,78 @@
 	int error, newnmbclusters;
 
 	newnmbclusters = nmbclusters;
-	error = sysctl_handle_int(oidp, &newnmbclusters, sizeof(int), req); 
+	error = sysctl_int_checked(oidp, &newnmbclusters, nmbclusters, 
+           SYSCTL_NO_LIMIT, req);
+	if (error == 0 && req->newptr) {
+		nmbclusters = newnmbclusters;
+		uma_zone_set_max(zone_clust, nmbclusters);
+		EVENTHANDLER_INVOKE(nmbclusters_change);
+	}
+	return (error);
+}
+
+static int
+sysctl_nmbjclusters(SYSCTL_HANDLER_ARGS)
+{
+	int error, newnmbjclusters;
+
+	newnmbjclusters = nmbjumbop;
+	error = sysctl_int_checked(oidp, &newnmbjclusters, nmbjumbop, 
+           SYSCTL_NO_LIMIT, req);
 	if (error == 0 && req->newptr) {
-		if (newnmbclusters > nmbclusters) {
-			nmbclusters = newnmbclusters;
-			uma_zone_set_max(zone_clust, nmbclusters);
-			EVENTHANDLER_INVOKE(nmbclusters_change);
-		} else
-			error = EINVAL;
+		nmbjumbop = newnmbjclusters;
+		uma_zone_set_max(zone_jumbop, nmbjumbop);
 	}
 	return (error);
 }
+
+
+static int
+sysctl_nmbj9clusters(SYSCTL_HANDLER_ARGS)
+{
+	int error, newnmbj9clusters;
+
+	newnmbj9clusters = nmbjumbo9;
+	error = sysctl_int_checked(oidp, &newnmbj9clusters, nmbjumbo9, 
+           SYSCTL_NO_LIMIT, req); 
+	if (error == 0 && req->newptr) {
+		nmbjumbo9 = newnmbj9clusters;
+		uma_zone_set_max(zone_jumbo9, nmbjumbo9);
+	}
+	return (error);
+}
+
+static int
+sysctl_nmbj16clusters(SYSCTL_HANDLER_ARGS)
+{
+	int error, newnmbj16clusters;
+
+	newnmbj16clusters = nmbjumbo16;
+	error = sysctl_int_checked(oidp, &newnmbj16clusters, nmbjumbo16, 
+           SYSCTL_NO_LIMIT, req);
+	if (error == 0 && req->newptr) {
+		nmbjumbo16 = newnmbj16clusters;
+		uma_zone_set_max(zone_jumbo16, nmbjumbo16);
+	}
+	return (error);
+}
+
 SYSCTL_PROC(_kern_ipc, OID_AUTO, nmbclusters, CTLTYPE_INT|CTLFLAG_RW,
 &nmbclusters, 0, sysctl_nmbclusters, "IU",
     "Maximum number of mbuf clusters allowed");
-SYSCTL_INT(_kern_ipc, OID_AUTO, nmbjumbop, CTLFLAG_RW, &nmbjumbop, 0,
+
+SYSCTL_PROC(_kern_ipc, OID_AUTO, nmbjumbop, CTLTYPE_INT|CTLFLAG_RW, 
+&nmbjumbop, 0, sysctl_nmbjclusters, "IU",
     "Maximum number of mbuf page size jumbo clusters allowed");
-SYSCTL_INT(_kern_ipc, OID_AUTO, nmbjumbo9, CTLFLAG_RW, &nmbjumbo9, 0,
+
+SYSCTL_PROC(_kern_ipc, OID_AUTO, nmbjumbo9, CTLTYPE_INT|CTLFLAG_RW, 
+&nmbjumbo9, 0, sysctl_nmbj9clusters, "IU",
     "Maximum number of mbuf 9k jumbo clusters allowed");
-SYSCTL_INT(_kern_ipc, OID_AUTO, nmbjumbo16, CTLFLAG_RW, &nmbjumbo16, 0,
+
+SYSCTL_PROC(_kern_ipc, OID_AUTO, nmbjumbo16, CTLTYPE_INT|CTLFLAG_RW, 
+&nmbjumbo16, 0, sysctl_nmbj16clusters, "IU",
     "Maximum number of mbuf 16k jumbo clusters allowed");
+
 SYSCTL_STRUCT(_kern_ipc, OID_AUTO, mbstat, CTLFLAG_RD, &mbstat, mbstat,
     "Mbuf general information and statistics");
 
Index: kern/kern_sysctl.c
===================================================================
RCS file: /usr/FreeBSD/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.172
diff -u -r1.172 kern_sysctl.c
--- kern/kern_sysctl.c	6 Nov 2006 13:42:01 -0000	1.172
+++ kern/kern_sysctl.c	23 Jan 2007 17:44:39 -0000
@@ -826,6 +826,43 @@
 }
 
 
+
+/*
+ * Handle an int, unsigned, but limited
+ * between min and max (unsigned)
+ * Two cases:
+ *     a variable:  point arg1 at it.
+ *     a constant:  pass it in arg2.
+ * 
+ */
+
+extern int nmbjumbo9;
+
+int
+sysctl_int_checked(struct sysctl_oid *oidp, void *val, uint32_t min, uint32_t max, struct sysctl_req *req)
+{
+	uint32_t tmpout=0;
+        int error = 0;
+	
+	if(val == NULL)
+		return (EINVAL);
+
+	tmpout = *(int *)val;
+	error = SYSCTL_OUT(req, &tmpout, sizeof(int));
+
+	if (error || !req->newptr) {
+		return (error);
+	}
+	error = SYSCTL_IN(req, (void *)&tmpout, sizeof(uint32_t));
+	if ((tmpout < min) || (tmpout > max)) {
+		error = EINVAL;
+		return(error);
+	}
+	*((uint32_t *)val) = tmpout;
+	return (error);
+}
+
+
 /*
  * Based on on sysctl_handle_int() convert milliseconds into ticks.
  */
Index: sys/sysctl.h
===================================================================
RCS file: /usr/FreeBSD/src/sys/sys/sysctl.h,v
retrieving revision 1.145
diff -u -r1.145 sysctl.h
--- sys/sysctl.h	17 Sep 2006 20:00:35 -0000	1.145
+++ sys/sysctl.h	22 Jan 2007 18:04:42 -0000
@@ -167,6 +167,11 @@
 #define SYSCTL_IN(r, p, l) (r->newfunc)(r, p, l)
 #define SYSCTL_OUT(r, p, l) (r->oldfunc)(r, p, l)
 
+#define SYSCTL_NO_LIMIT 0xffffffff
+int
+sysctl_int_checked(struct sysctl_oid *, void *, uint32_t min, 
+        uint32_t max, struct sysctl_req *);
+
 int sysctl_handle_int(SYSCTL_HANDLER_ARGS);
 int sysctl_msec_to_ticks(SYSCTL_HANDLER_ARGS);
 int sysctl_handle_long(SYSCTL_HANDLER_ARGS);

--------------080208020809070508020709--

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 04:22:08 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 9405916A413
	for <freebsd-net@FreeBSD.org>; Wed, 24 Jan 2007 04:22:08 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210])
	by mx1.freebsd.org (Postfix) with ESMTP id 5CF9B13C47E
	for <freebsd-net@FreeBSD.org>; Wed, 24 Jan 2007 04:22:08 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au
	[61.8.2.163])
	by mailout1.pacific.net.au (Postfix) with ESMTP id 9F6855A7C3A;
	Wed, 24 Jan 2007 15:22:02 +1100 (EST)
Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246])
	by mailproxy2.pacific.net.au (Postfix) with ESMTP id ECB2D27419;
	Wed, 24 Jan 2007 15:22:01 +1100 (EST)
Date: Wed, 24 Jan 2007 15:22:00 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@besplex.bde.org
To: Randall Stewart <rrs@cisco.com>
In-Reply-To: <45B679F3.3080407@cisco.com>
Message-ID: <20070124150524.P16439@besplex.bde.org>
References: <45B679F3.3080407@cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net <freebsd-net@FreeBSD.org>
Subject: Re: mbuf patch with sysctl suggestions too
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 04:22:08 -0000

On Tue, 23 Jan 2007, Randall Stewart wrote:

> Here is iteration 2 of the mbuf patch with limits I
> proposed.
>
> Also note the changes for sysctl stuff that Lugi suggested.
> Please let me know what you think :-)

It has a lot of style bugs (4 per line on so,me lines) (mainly weird
whitespace starting with tab lossage).

Bruce

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 06:10:07 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 95E1616A401
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 06:10:07 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
	by mx1.freebsd.org (Postfix) with ESMTP id 5CE5313C44C
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 06:10:07 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-5.cisco.com with ESMTP; 23 Jan 2007 22:10:07 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0O6A6GQ011011; 
	Tue, 23 Jan 2007 22:10:06 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0O6A6Dk019768;
	Tue, 23 Jan 2007 22:10:06 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 Jan 2007 22:10:06 -0800
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 Jan 2007 22:10:05 -0800
Message-ID: <45B6F81C.6050802@cisco.com>
Date: Wed, 24 Jan 2007 01:09:32 -0500
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Bruce Evans <bde@zeta.org.au>
References: <45B679F3.3080407@cisco.com>
	<20070124150524.P16439@besplex.bde.org>
In-Reply-To: <20070124150524.P16439@besplex.bde.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Jan 2007 06:10:05.0898 (UTC)
	FILETIME=[4AEF62A0:01C73F7E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=792; t=1169619006;
	x=1170483006; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20mbuf=20patch=20with=20sysctl=20suggestions=20too
	|Sender:=20; bh=/LRSHl8f1rd4AvFZtjpcXRErsn+bCQKwZlmi8Sn+S4Q=;
	b=Q++HzgVdq/Oqogfa/++7XmPqg6F3Mh4F0gBzsLUf269E/r68SE66KwcEmFDFCpmKS0fi3rlK
	MqKt+TrZF4KiUqR45iRUWqaKh6D/nkXoqU+jg+otjCiJ7woMgrEFWZ4w;
Authentication-Results: sj-dkim-5; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim5002 verified; ); 
Cc: freebsd-net <freebsd-net@FreeBSD.org>
Subject: Re: mbuf patch with sysctl suggestions too
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 06:10:07 -0000

Bruce Evans wrote:
> On Tue, 23 Jan 2007, Randall Stewart wrote:
> 
>> Here is iteration 2 of the mbuf patch with limits I
>> proposed.
>>
>> Also note the changes for sysctl stuff that Lugi suggested.
>> Please let me know what you think :-)
> 
> It has a lot of style bugs (4 per line on so,me lines) (mainly weird
> whitespace starting with tab lossage).
> 
> Bruce
> 
That has to do with me using emacs I think.. I will be running that
section of code through the style9 (s9indent) stuff that George
gave me...  so that should take care of the space <-> tab issues
and other stuff...

I think Pyun is right though.. in adding the page size
calculation to the init code..

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 06:51:10 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 0C42616A400
	for <freebsd-net@FreeBSD.org>; Wed, 24 Jan 2007 06:51:10 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226])
	by mx1.freebsd.org (Postfix) with ESMTP id C81AA13C471
	for <freebsd-net@FreeBSD.org>; Wed, 24 Jan 2007 06:51:09 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au
	[61.8.2.163])
	by mailout2.pacific.net.au (Postfix) with ESMTP id A863F6E2E3;
	Wed, 24 Jan 2007 17:51:05 +1100 (EST)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailproxy2.pacific.net.au (Postfix) with ESMTP id 1172027417;
	Wed, 24 Jan 2007 17:51:06 +1100 (EST)
Date: Wed, 24 Jan 2007 17:51:05 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@delplex.bde.org
To: Randall Stewart <rrs@cisco.com>
In-Reply-To: <45B6F81C.6050802@cisco.com>
Message-ID: <20070124172119.P36500@delplex.bde.org>
References: <45B679F3.3080407@cisco.com>
	<20070124150524.P16439@besplex.bde.org>
	<45B6F81C.6050802@cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net <freebsd-net@FreeBSD.org>
Subject: Re: mbuf patch with sysctl suggestions too
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 06:51:10 -0000

On Wed, 24 Jan 2007, Randall Stewart wrote:

> Bruce Evans wrote:
>> It has a lot of style bugs (4 per line on so,me lines) (mainly weird
>> whitespace starting with tab lossage).
>> 
> That has to do with me using emacs I think.. I will be running that
> section of code through the style9 (s9indent) stuff that George
> gave me...  so that should take care of the space <-> tab issues
> and other stuff...

I wouldn't trust an editor to get this right.  indent(1) gets closer,
but still gets so much wrong that every change that it wants to make
must be reviewed manually.

> I think Pyun is right though.. in adding the page size
> calculation to the init code..

I forgot to mention the style bugs in the comment related to page
sizes.  IIRC, the comment has many hard-coded magic numbers which are
only correct if the page size is 4K and the allocations start on page
boundaries, but pages can be almost any size and are 8K on some supported
arches, and I think allocations made by UMA are only aligned to a small
power of 2.  I think this allows a 9k buffer to be split across 4
4K-pages (e.g., 128+4096+4096+680) or across 3 8K-pages (128+8192+680).
Hardware might not like this.  Otherwise, non-page-aligned allocations
should make the page size irrelevant.

Bruce

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 12:52:53 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id C700E16A412
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 12:52:53 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
	by mx1.freebsd.org (Postfix) with ESMTP id A12F113C46A
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 12:52:53 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-5.cisco.com with ESMTP; 24 Jan 2007 04:52:53 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0OCqpP6028441; 
	Wed, 24 Jan 2007 04:52:51 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0OCqoUw004494;
	Wed, 24 Jan 2007 04:52:51 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 24 Jan 2007 04:52:50 -0800
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 24 Jan 2007 04:52:50 -0800
Message-ID: <45B75680.9030809@cisco.com>
Date: Wed, 24 Jan 2007 07:52:16 -0500
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Bruce Evans <bde@zeta.org.au>
References: <45B679F3.3080407@cisco.com>
	<20070124150524.P16439@besplex.bde.org>
	<45B6F81C.6050802@cisco.com>
	<20070124172119.P36500@delplex.bde.org>
In-Reply-To: <20070124172119.P36500@delplex.bde.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Jan 2007 12:52:50.0286 (UTC)
	FILETIME=[8E0860E0:01C73FB6]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1887; t=1169643171;
	x=1170507171; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20mbuf=20patch=20with=20sysctl=20suggestions=20too
	|Sender:=20; bh=0+W4qlBZUMkuCblT0GVZIZI+KWN8O+568r7GX63u6MA=;
	b=n4I8azR1za2ftPYxjBXDFyHtN8js5ek79RRKPJ8ApnJbp/kEAypa9JdXWSQ3S/ZnxDVDvpLS
	xeVU7Blasc5BFOR6pf2clDGfpL9QUMwgUyUb/F1kMUf5fGosKXiPcQ7A;
Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim4002 verified; ); 
Cc: freebsd-net <freebsd-net@FreeBSD.org>
Subject: Re: mbuf patch with sysctl suggestions too
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 12:52:53 -0000

Bruce Evans wrote:
> On Wed, 24 Jan 2007, Randall Stewart wrote:
> 
>> Bruce Evans wrote:
>>> It has a lot of style bugs (4 per line on so,me lines) (mainly weird
>>> whitespace starting with tab lossage).
>>>
>> That has to do with me using emacs I think.. I will be running that
>> section of code through the style9 (s9indent) stuff that George
>> gave me...  so that should take care of the space <-> tab issues
>> and other stuff...
> 
> I wouldn't trust an editor to get this right.  indent(1) gets closer,
> but still gets so much wrong that every change that it wants to make
> must be reviewed manually.
> 
>> I think Pyun is right though.. in adding the page size
>> calculation to the init code..
> 
> I forgot to mention the style bugs in the comment related to page
> sizes.  IIRC, the comment has many hard-coded magic numbers which are
> only correct if the page size is 4K and the allocations start on page
> boundaries, but pages can be almost any size and are 8K on some supported
> arches, and I think allocations made by UMA are only aligned to a small
> power of 2.  I think this allows a 9k buffer to be split across 4
> 4K-pages (e.g., 128+4096+4096+680) or across 3 8K-pages (128+8192+680).
> Hardware might not like this.  Otherwise, non-page-aligned allocations
> should make the page size irrelevant.


Hmm.. the one thing I thought of was to use the
uk_ppera to do the calculation (besides what Pyun had
mentioned). But I was concerned about using an internal
Keg variable within another subsystem.... maybe if we
made a access function... but Andre has asked to wait
on this .. he has another idea.. so no hurry... its
been "unlimited" this long... we can wait until Andre
comes up with a better idea :-)

R
> 
> Bruce
> 


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 13:10:51 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 542BB16A402
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 13:10:51 +0000 (UTC)
	(envelope-from rizzo@icir.org)
Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68])
	by mx1.freebsd.org (Postfix) with ESMTP id 41E5413C43E
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 13:10:51 +0000 (UTC)
	(envelope-from rizzo@icir.org)
Received: from xorpc.icir.org (localhost [127.0.0.1])
	by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0ODAo9H056267;
	Wed, 24 Jan 2007 05:10:50 -0800 (PST)
	(envelope-from rizzo@xorpc.icir.org)
Received: (from rizzo@localhost)
	by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0ODAoUg056266;
	Wed, 24 Jan 2007 05:10:50 -0800 (PST) (envelope-from rizzo)
Date: Wed, 24 Jan 2007 05:10:50 -0800
From: Luigi Rizzo <rizzo@icir.org>
To: Randall Stewart <rrs@cisco.com>
Message-ID: <20070124051050.A56064@xorpc.icir.org>
References: <45B679F3.3080407@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <45B679F3.3080407@cisco.com>;
	from rrs@cisco.com on Tue, Jan 23, 2007 at 04:11:15PM -0500
Cc: freebsd-net <freebsd-net@freebsd.org>
Subject: Re: mbuf patch with sysctl suggestions too
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 13:10:51 -0000

On Tue, Jan 23, 2007 at 04:11:15PM -0500, Randall Stewart wrote:
> Hi all:
> 
> Here is iteration 2 of the mbuf patch with limits I
> proposed.
> 
> Also note the changes for sysctl stuff that Lugi suggested.
> Please let me know what you think :-)

...
> +	newnmbjclusters = nmbjumbop;
> +	error = sysctl_int_checked(oidp, &newnmbjclusters, nmbjumbop, 
> +           SYSCTL_NO_LIMIT, req);

A few things here:
- i don't see much of a point in defining SYSCTL_NO_LIMIT;
  UINT32_MAX would do perfectly there, and i think it is easier
  to understand than SYSCTL_NO_LIMIT (which looks like a flag).

- here and in other places you do not allow decresaing the value
  (by putting min = nmbjumbop etc.), and i am not sure why.
  I understand a reasonable lower bound, but i guess the worst
  that can happen, when you reduce the limit to something above
  the current allocation, is that nothing is allocated until
  you go again below the limit, right ?
  
- given that you don't use the new value if error != 0, perhaps
  you can save the assignment newnmbjclusters = nmbjumbop;

And below:

> +/*
> + * Handle an int, unsigned, but limited
> + * between min and max (unsigned)
> + * Two cases:
> + *     a variable:  point arg1 at it.
> + *     a constant:  pass it in arg2.
> + * 
> + */
> +
> +extern int nmbjumbo9;
> +
> +int
> +sysctl_int_checked(struct sysctl_oid *oidp, void *val, uint32_t min, uint32_t max, struct sysctl_req *req)
> +{

the comment refers to something else and should be fixed e.g.

	Handle an unsigned int variable with bound checking.
	Returns 0 (and updates *val) if min <= v <= max;
	returns EINVAL otherwhise (in which case *val is unchanged)

cheers
luigi

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 13:28:28 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id C69AC16A402
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 13:28:28 +0000 (UTC)
	(envelope-from lists@swaggi.com)
Received: from rusty.swaggy.net (rusty.swaggy.net [66.103.13.18])
	by mx1.freebsd.org (Postfix) with ESMTP id 7A3AE13C4D1
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 13:28:28 +0000 (UTC)
	(envelope-from lists@swaggi.com)
Received: from [127.0.0.1] (helo=swaggi.com)
	by rusty.swaggy.net with esmtp (Exim 4.63 (FreeBSD))
	(envelope-from <lists@swaggi.com>) id 1H9hMy-0004Mz-60
	for freebsd-net@freebsd.org; Wed, 24 Jan 2007 07:36:53 -0500
From: "Yuri Lukin" <lists@swaggi.com>
To: freebsd-net@freebsd.org
Date: Wed, 24 Jan 2007 07:36:51 -0500
Message-Id: <20070124122525.M93545@swaggi.com>
In-Reply-To: <20070124020027.GC90167@k7.mavetju>
References: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net>
	<20070124020027.GC90167@k7.mavetju>
X-Mailer: swaggi.com
MIME-Version: 1.0
Content-Type: text/plain;
	charset=iso-8859-1
Subject: Re: VLANs and DHCP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 13:28:28 -0000

On Tue, Jan 23, 2007 at 04:15:02PM -0000, jhall@vandaliamo.net wrote:
> I currently administer a system which has two DHCP servers on two
> different VLANs.  Unfortunately, the two servers are not playing together
> well and some comptuers are receiving IP addresses on the wrong network. 
> So, with our phone vendor's blessing, I am trying to move all of the DHCP
> services to the FreeBSD server.
> 
> The computers on the network are supposed to receive an IP address on the
> default vlan and the phones are supposed to receive an IP address on their
> vlan.
> 
> Essentially what happens when a phone is booted, the phone receives an IP
> address on the default VLAN, releases that address and then requests an IP
> address on the appropriate VLAN.

Just a thought but if your switch properly tags the packets from the voice and
data Vlans, the broadcasts from the IP Phones should not cross over to the
data Vlan. We  have dozens of customers setup this way and they are not having
any problems. Not sure what type of switches you are using but I would check
your switchport configuration (assuming managed switch).  

    Yuri


From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 13:46:40 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 51AAF16A403
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 13:46:40 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
	by mx1.freebsd.org (Postfix) with ESMTP id 2E71113C465
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 13:46:40 +0000 (UTC)
	(envelope-from rrs@cisco.com)
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-5.cisco.com with ESMTP; 24 Jan 2007 05:46:39 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0ODkc61014932; 
	Wed, 24 Jan 2007 05:46:38 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0ODkaGk024347;
	Wed, 24 Jan 2007 05:46:36 -0800 (PST)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 24 Jan 2007 05:46:36 -0800
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 24 Jan 2007 05:46:36 -0800
Message-ID: <45B7631A.3070001@cisco.com>
Date: Wed, 24 Jan 2007 08:46:02 -0500
From: Randall Stewart <rrs@cisco.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.8.0.8) Gecko/20061029 FreeBSD/i386 SeaMonkey/1.0.6
MIME-Version: 1.0
To: Luigi Rizzo <rizzo@icir.org>
References: <45B679F3.3080407@cisco.com> <20070124051050.A56064@xorpc.icir.org>
In-Reply-To: <20070124051050.A56064@xorpc.icir.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Jan 2007 13:46:36.0302 (UTC)
	FILETIME=[10E35AE0:01C73FBE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2187; t=1169646398;
	x=1170510398; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rrs@cisco.com;
	z=From:=20Randall=20Stewart=20<rrs@cisco.com>
	|Subject:=20Re=3A=20mbuf=20patch=20with=20sysctl=20suggestions=20too
	|Sender:=20; bh=JmglI4vnlLBiSC8bBUrCbGhFcjG3/jRYvA6w2BLMY4M=;
	b=WbMAIWPKujbtVHEk7az6r83ujNtIvnYVx8GlIDdKkk9yk+ybMbFfJrr7SxnzxBpBYSorO47F
	fCJTO/WA7F6Lxw/12TmDkfzf5FD4zJSDgknMtRTZP0MwaT/fHxZsPcY8;
Authentication-Results: sj-dkim-4; header.From=rrs@cisco.com; dkim=pass (sig
	from cisco.com/sjdkim4002 verified; ); 
Cc: freebsd-net <freebsd-net@freebsd.org>
Subject: Re: mbuf patch with sysctl suggestions too
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 13:46:40 -0000

Luigi Rizzo wrote:
> On Tue, Jan 23, 2007 at 04:11:15PM -0500, Randall Stewart wrote:
>> Hi all:
>>
>> Here is iteration 2 of the mbuf patch with limits I
>> proposed.
>>
>> Also note the changes for sysctl stuff that Lugi suggested.
>> Please let me know what you think :-)
> 
> ...
>> +	newnmbjclusters = nmbjumbop;
>> +	error = sysctl_int_checked(oidp, &newnmbjclusters, nmbjumbop, 
>> +           SYSCTL_NO_LIMIT, req);
> 
> A few things here:
> - i don't see much of a point in defining SYSCTL_NO_LIMIT;
>   UINT32_MAX would do perfectly there, and i think it is easier
>   to understand than SYSCTL_NO_LIMIT (which looks like a flag).
> 

ok
> - here and in other places you do not allow decresaing the value
>   (by putting min = nmbjumbop etc.), and i am not sure why.
>   I understand a reasonable lower bound, but i guess the worst
>   that can happen, when you reduce the limit to something above
>   the current allocation, is that nothing is allocated until
>   you go again below the limit, right ?

Well.. no I believe someone (was in Lin) mentioned that
you can get a live-lock if you allow a reduction.. and
thus the mbuf clusters were NOT allowed to be reduced..



>   
> - given that you don't use the new value if error != 0, perhaps
>   you can save the assignment newnmbjclusters = nmbjumbop;
> 

ok


> And below:
> 
>> +/*
>> + * Handle an int, unsigned, but limited
>> + * between min and max (unsigned)
>> + * Two cases:
>> + *     a variable:  point arg1 at it.
>> + *     a constant:  pass it in arg2.
>> + * 
>> + */
>> +
>> +extern int nmbjumbo9;
>> +
>> +int
>> +sysctl_int_checked(struct sysctl_oid *oidp, void *val, uint32_t min, uint32_t max, struct sysctl_req *req)
>> +{
> 
> the comment refers to something else and should be fixed e.g.
> 
> 	Handle an unsigned int variable with bound checking.
> 	Returns 0 (and updates *val) if min <= v <= max;
> 	returns EINVAL otherwhise (in which case *val is unchanged)
> 

Cool.. but as I said, Andre wants me to wait on this.. so
I will :-)

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

From owner-freebsd-net@FreeBSD.ORG  Wed Jan 24 13:49:34 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 5902D16A402
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 13:49:34 +0000 (UTC)
	(envelope-from rizzo@icir.org)
Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68])
	by mx1.freebsd.org (Postfix) with ESMTP id 4657013C4D1
	for <freebsd-net@freebsd.org>; Wed, 24 Jan 2007 13:49:34 +0000 (UTC)
	(envelope-from rizzo@icir.org)
Received: from xorpc.icir.org (localhost [127.0.0.1])
	by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0ODnVAe056621;
	Wed, 24 Jan 2007 05:49:31 -0800 (PST)
	(envelope-from rizzo@xorpc.icir.org)
Received: (from rizzo@localhost)
	by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0ODnV2Q056620;
	Wed, 24 Jan 2007 05:49:31 -0800 (PST) (envelope-from rizzo)
Date: Wed, 24 Jan 2007 05:49:31 -0800
From: Luigi Rizzo <rizzo@icir.org>
To: Randall Stewart <rrs@cisco.com>
Message-ID: <20070124054931.B56550@xorpc.icir.org>
References: <45B679F3.3080407@cisco.com> <20070124051050.A56064@xorpc.icir.org>
	<45B7631A.3070001@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <45B7631A.3070001@cisco.com>;
	from rrs@cisco.com on Wed, Jan 24, 2007 at 08:46:02AM -0500
Cc: freebsd-net <freebsd-net@freebsd.org>
Subject: Re: mbuf patch with sysctl suggestions too
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2007 13:49:34 -0000

On Wed, Jan 24, 2007 at 08:46:02AM -0500, Randall Stewart wrote:
> Luigi Rizzo wrote:
> > On Tue, Jan 23, 2007 at 04:11:15PM -0500, Randall Stewart wrote:
> >> Hi all:
> >>
> >> Here is iteration 2 of the mbuf patch with limits I
> >> proposed.
> >>
> >> Also note the changes for sysctl stuff that Lugi suggested.
> >> Please let me know what you think :-)
> > 
> > ...
> >> +	newnmbjclusters = nmbjumbop;
> >> +	error = sysctl_int_checked(oidp, &newnmbjclusters, nmbjumbop, 
> >> +           SYSCTL_NO_LIMIT, req);
> > 
> > A few things here:
> > - i don't see much of a point in defining SYSCTL_NO_LIMIT;
> >   UINT32_MAX would do perfectly there, and i think it is easier
> >   to understand than SYSCTL_NO_LIMIT (which looks like a flag).
> > 
> 
> ok
> > - here and in other places you do not allow decresaing the value
> >   (by putting min = nmbjumbop etc.), and i am not sure why.
> >   I understand a reasonable lower bound, but i guess the worst
> >   that can happen, when you reduce the limit to something above
> >   the current allocation, is that nothing is allocated until
> >   you go again below the limit, right ?
> 
> Well.. no I believe someone (was in Lin) mentioned that
> you can get a live-lock if you allow a reduction.. and
> thus the mbuf clusters were NOT allowed to be reduced..

maybe... but then this is definitely worth putting a note
explaining why.

	cheers
	luigi

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 01:18:42 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 88C3216A404
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 01:18:42 +0000 (UTC)
	(envelope-from kbyanc@posi.net)
Received: from nlpi012.sbcis.sbc.com (nlpi012.sbcis.sbc.com [207.115.36.41])
	by mx1.freebsd.org (Postfix) with ESMTP id 555E213C442
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 01:18:42 +0000 (UTC)
	(envelope-from kbyanc@posi.net)
X-ORBL: [71.141.251.198]
Received: from gateway.posi.net (adsl-71-141-251-198.dsl.snfc21.pacbell.net
	[71.141.251.198])
	by nlpi012.sbcis.sbc.com (8.13.8 out.dk.spool/8.13.8) with ESMTP id
	l0P12fv8031249; Wed, 24 Jan 2007 19:02:42 -0600
Received: from localhost (localhost [127.0.0.1])
	by gateway.posi.net (Postfix) with ESMTP id 4715275E002;
	Wed, 24 Jan 2007 17:02:36 -0800 (PST)
Date: Wed, 24 Jan 2007 17:02:35 -0800 (PST)
From: Kelly Yancey <kbyanc@posi.net>
To: Max Laier <max@love2party.net>
In-Reply-To: <200701212033.34914.max@love2party.net>
Message-ID: <20070124164949.P16327@gateway.posi.net>
References: <20070121155510.C23922@delplex.bde.org>
	<200701210809.27770.max@love2party.net>
	<20070121215054.C24780@delplex.bde.org>
	<200701212033.34914.max@love2party.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: freebsd-net@freebsd.org
Subject: Re: slow writes on nfs with bge devices
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 01:18:42 -0000

On Sun, 21 Jan 2007, Max Laier wrote:

> On Sunday 21 January 2007 13:25, Bruce Evans wrote:
> > On Sun, 21 Jan 2007, Max Laier wrote:
> > > On Sunday 21 January 2007 07:25, Bruce Evans wrote:
> > >> nfs writes much less well with bge NICs than with other NICs (sk,
> > >> fxp,
> > >
> > > Do you use hardware checksumming on the bge?  There is an XXX in
> > > bge_start_locked() that looks a bit suspicious to me.
> >
> > I use the default for that.  Wouldn't checksum problems show up as
> > errors somwhere?
>
> Did you look at the code in question?  It is concerned with fragmented
> packet chains (which NFS over UDP usually generated) and only commits to
> sending them, if there are enough descriptors available at once.  This
> can easily explain burstyness.
>
> Can you just try to disable the delayed checksums via "ifconfig -txcsum"?
> Should be an easy enough test.
>

  I realize that Bruce has already identified the problem as being with
the cabling, however I wanted to add a warning that disabling hardware
checksums for bge cards is not a good idea.  You can find my analysis of
data corruption bugs caused by using bge cards without checksum
offloading in the archives:
http://lists.freebsd.org/pipermail/freebsd-net/2004-January/002530.html

  Kelly

-- 
Kelly Yancey  -  kbyanc@posi.net | kelly@nttmcl.com

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 13:27:38 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id CD64116A406
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 13:27:38 +0000 (UTC)
	(envelope-from frank@pinky.sax.de)
Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24])
	by mx1.freebsd.org (Postfix) with ESMTP id 2970413C465
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 13:27:37 +0000 (UTC)
	(envelope-from frank@pinky.sax.de)
Received: from [192.168.20.32] (sun.behrens [192.168.20.32])
	by pinky.frank-behrens.de (8.13.8/8.13.8) with ESMTP id l0PD9S5W071724
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 14:09:28 +0100 (CET)
	(envelope-from frank@pinky.sax.de)
Message-Id: <200701251309.l0PD9S5W071724@pinky.frank-behrens.de>
From: "Frank Behrens" <frank@pinky.sax.de>
To: freebsd-net@freebsd.org
Date: Thu, 25 Jan 2007 14:09:28 +0100
MIME-Version: 1.0
Priority: normal
X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Subject: When IPv6 temporary addresses are regenerated?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 13:27:38 -0000

I have an IPv6 setup with temporary addresses (RFC3041). To switch this on I used "sysctl 
net.inet6.ip6.use_tempaddr=1". The temporary address is generated and meanwhile expired. 

Does anybody know, when this address is expected to be regenerated?

My current interface configuration is
vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet xxx.xxx.xx.xx netmask 0xffffff00 broadcast xxx.xxx.xxx.xxx
        inet6 fe80::211:xxxx:xxxx:xxxx%vlan0 prefixlen 64 scopeid 0x5
        inet6 2xxx:xxxx:xxxx:: prefixlen 64 anycast
        inet6 2xxx:xxxx:xxxx:0:211:2fff:xxxx:xxxx prefixlen 64
        inet6 2xxx:xxxx:xxxx:0:54b:5960:xxxx:xxxx prefixlen 64 deprecated autoconf temporary pltime 0 vltime 509995
I use FreeBSD 6.2-PRERELEASE-200611090613.

Regards,
   Frank
-- 
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.


From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 16:34:56 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 180EA16A401;
	Thu, 25 Jan 2007 16:34:56 +0000 (UTC)
	(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (cell.sick.ru [217.72.144.68])
	by mx1.freebsd.org (Postfix) with ESMTP id 9611D13C459;
	Thu, 25 Jan 2007 16:34:55 +0000 (UTC)
	(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (glebius@localhost [127.0.0.1])
	by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l0PGOMFZ009041
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Jan 2007 19:24:22 +0300 (MSK)
	(envelope-from glebius@FreeBSD.org)
Received: (from glebius@localhost)
	by cell.sick.ru (8.13.4/8.13.1/Submit) id l0PGOMY8009040;
	Thu, 25 Jan 2007 19:24:22 +0300 (MSK)
	(envelope-from glebius@FreeBSD.org)
X-Authentication-Warning: cell.sick.ru: glebius set sender to
	glebius@FreeBSD.org using -f
Date: Thu, 25 Jan 2007 19:24:22 +0300
From: Gleb Smirnoff <glebius@FreeBSD.org>
To: bms@FreeBSD.org, rwatson@FreeBSD.org
Message-ID: <20070125162422.GA7922@bestcom.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
Cc: net@FreeBSD.org
Subject: rev. 1.94 of netinet/in.c broke CARP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 16:34:56 -0000

  Hello, colleagues!

  I've just discovered, that revision 1.94 of in.c has broke CARP. This
change adds a code to in_ifdetach() that goes through the global list
of all multicast instances and deletes all the instances, that are
belonging to a particular interface. This is intended to avoid leaking
multicast instances.

  Before this change, most of the subsystems, that allocated multicast
membership instances had freed is theirselves. I don't know about others,
but at least CARP is broken now. It attempts to free a memory, that
already has been freed.

 The scenario is:

 ifconfig vlan0 create
 ifconfig vlan0 vlandev em0 vlan 1 10.0.0.1/24
 ifconfig carp0 create
 ifconfig carp0 vhid 1 10.0.0.2/24
 ifconfig vlan0 destroy

 The codepath is:

 if_detach(vlan0)
 event_handler_invoke()
 carp_ifdetach(vlan0)
 carpdetach(carp0)
 carp_multicast_cleanup(carp0)
 in_delmulti(a freed inm)

That inm has been freed earlier in if_detach() before event handler has
called its hooks.

  Bruce and Robert,

  I suppose you can tell me the correct way to deal with multicast
memberships now, when there is a generic GC function for them. Should I
just stop referencing the inms from CARP softc, and don't care about them?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 16:35:12 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 57C2C16A404
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 16:35:12 +0000 (UTC)
	(envelope-from r.gruyters@yirdis.nl)
Received: from mail.yirdis.nl (82-148-208-109.fiber.unet.nl [82.148.208.109])
	by mx1.freebsd.org (Postfix) with ESMTP id C61BA13C448
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 16:35:11 +0000 (UTC)
	(envelope-from r.gruyters@yirdis.nl)
Received: from server.yirdis.net (localhost [127.0.0.1])
	by mail.yirdis.nl (8.13.6/8.13.6) with ESMTP id l0PG5WSI036294
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 17:05:32 +0100 (CET)
	(envelope-from r.gruyters@yirdis.nl)
Received: (from www@localhost)
	by server.yirdis.net (8.13.6/8.13.6/Submit) id l0PG5WiZ036293
	for freebsd-net@freebsd.org; Thu, 25 Jan 2007 17:05:32 +0100 (CET)
	(envelope-from r.gruyters@yirdis.nl)
X-Authentication-Warning: server.yirdis.net: www set sender to
	r.gruyters@yirdis.nl using -f
Received: from hp-xw4100-01.yirdis.nl (hp-xw4100-01.yirdis.nl [10.8.0.27])
	by server.yirdis.net (Horde MIME library) with HTTP; Thu, 25 Jan 2007
	17:05:32 +0100
Message-ID: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net>
Date: Thu, 25 Jan 2007 17:05:32 +0100
From: Robin Gruyters <r.gruyters@yirdis.nl>
To: freebsd-net@freebsd.org
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) / FreeBSD-5.4
X-Virus-Scanned: OK
Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R]
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 16:35:12 -0000

On 13-Jan-2007 Oleg Bulyzhin wrote:
>
> > Could you please test attached patch? It should fix ierrs issue =20
> and should not
> > break link events (would be fine to test it: unplug/plug cable, =20
> try to change
> > media with ifconfig, change media on other end of wire).
> >
Hi ya,

Just wondering will this patch/update be available for RELENG_6? I =20
have the same problems here with 3 of our servers.

Here is dmesg from our development server:

[...]
Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
         The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 6.2-RELEASE #1: Mon Jan 15 15:34:19 CET 2007
     root@server.yirdis.net:/data/obj/data/src_6_2/sys/YIRDIS
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.12-MHz 686-class CPU)
   Origin =3D "GenuineIntel"  Id =3D 0xf41  Stepping =3D 1
   =20
Features=3D0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,M=
CA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
   Features2=3D0x641d<SSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,<b14>>
   AMD Features=3D0x20000000<LM>
   Logical CPUs per core: 2
real memory  =3D 2147430400 (2047 MB)
avail memory =3D 2100547584 (2003 MB)
ACPI APIC Table: <HP     00000083>
Security auditing service present
BSM auditing present
ioapic1: Changing APIC ID to 9
ioapic0 <Version 2.0> irqs 0-23 on motherboard
ioapic1 <Version 2.0> irqs 24-47 on motherboard
ioapic2 <Version 2.0> irqs 48-71 on motherboard
ioapic3 <Version 2.0> irqs 72-95 on motherboard
acpi0: <HP P52> on motherboard
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0
cpu0: <ACPI CPU> on acpi0
pcib0: <ACPI Host-PCI bridge> on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 2.0 on pci0
pci13: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> at device 4.0 on pci0
pci6: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> at device 0.0 on pci6
pci7: <ACPI PCI bus> on pcib3
pcib4: <ACPI PCI-PCI bridge> at device 0.2 on pci6
pci10: <ACPI PCI bus> on pcib4
pcib5: <PCI-PCI bridge> at device 1.0 on pci10
pci11: <PCI bus> on pcib5
ste0: <D-Link DL10050 10/100BaseTX> port 0x5000-0x507f irq 72 at =20
device 4.0 on pci11
miibus0: <MII bus> on ste0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ste0: Ethernet address: 00:0d:88:fc:c8:cc
ste1: <D-Link DL10050 10/100BaseTX> port 0x5080-0x50ff irq 73 at =20
device 5.0 on pci11
miibus1: <MII bus> on ste1
ukphy1: <Generic IEEE 802.3u media interface> on miibus1
ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ste1: Ethernet address: 00:0d:88:fc:c8:cd
ste2: <D-Link DL10050 10/100BaseTX> port 0x5400-0x547f irq 74 at =20
device 6.0 on pci11
miibus2: <MII bus> on ste2
ukphy2: <Generic IEEE 802.3u media interface> on miibus2
ukphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ste2: Ethernet address: 00:0d:88:fc:c8:ce
ste3: <D-Link DL10050 10/100BaseTX> port 0x5480-0x54ff irq 75 at =20
device 7.0 on pci11
miibus3: <MII bus> on ste3
ukphy3: <Generic IEEE 802.3u media interface> on miibus3
ukphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ste3: Ethernet address: 00:0d:88:fc:c8:cf
pcib6: <ACPI PCI-PCI bridge> at device 6.0 on pci0
pci3: <ACPI PCI bus> on pcib6
pcib7: <ACPI PCI-PCI bridge> at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib7
ciss0: <HP Smart Array 6i> port 0x4000-0x40ff mem =20
0xfdff0000-0xfdff1fff,0xfdf80000-0xfdfbffff irq 24 at device 1.0 on pci2
ciss0: [GIANT-LOCKED]
bge0: <Broadcom BCM5704 B0, ASIC rev. 0x2100> mem =20
0xfdf70000-0xfdf7ffff irq 25 at device 2.0 on pci2
miibus4: <MII bus> on bge0
brgphy0: <BCM5704 10/100/1000baseTX PHY> on miibus4
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, =20
1000baseTX-FDX, auto
bge0: Ethernet address: 00:12:79:94:ed:12
bge1: <Broadcom BCM5704 B0, ASIC rev. 0x2100> mem =20
0xfdf60000-0xfdf6ffff irq 26 at device 2.1 on pci2
miibus5: <MII bus> on bge1
brgphy1: <BCM5704 10/100/1000baseTX PHY> on miibus5
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, =20
1000baseTX-FDX, auto
bge1: Ethernet address: 00:12:79:94:ed:11
pci0: <serial bus, USB> at device 29.0 (no driver attached)
pci0: <serial bus, USB> at device 29.1 (no driver attached)
pci0: <base peripheral> at device 29.4 (no driver attached)
pci0: <base peripheral, interrupt controller> at device 29.5 (no =20
driver attached)
pci0: <serial bus, USB> at device 29.7 (no driver attached)
pcib8: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci1: <ACPI PCI bus> on pcib8
pci1: <display, VGA> at device 3.0 (no driver attached)
pci1: <base peripheral> at device 4.0 (no driver attached)
pci1: <base peripheral> at device 4.2 (no driver attached)
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel 6300ESB UDMA100 controller> port =20
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f irq 18 at device 31.1 =20
on pci0
ata0: <ATA channel 0> on atapci0
ata1: <ATA channel 1> on atapci0
acpi_tz0: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: model IntelliMouse Explorer, device ID 4
sio0: <Standard PC COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
fdc0: <floppy drive controller (FDE)> port 0x3f2-0x3f5 irq 6 drq 2 on acpi0
fdc0: [FAST]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
pmtimer0 on isa0
orm0: <ISA Option ROMs> at iomem =20
0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=3D0x300>
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounter "TSC" frequency 3000124702 Hz quality 800
Timecounters tick every 1.000 msec
acd0: CDROM <COMPAQ CD-ROM SN-124/N104> at ata0-master PIO4
da0 at ciss0 bus 0 target 0 lun 0
da0: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-0 device
da0: 135.168MB/s transfers
da0: 69459MB (142253280 512 byte sectors: 255H 32S/T 17433C)
Trying to mount root from ufs:/dev/da0s1a
Accounting enabled
[...]

And here the netstat interface statistics:
[...]
Name    Mtu Network       Address              Ipkts Ierrs    Opkts =20
Oerrs  Coll
ste0*  1500 <Link#1>      00:0d:88:fc:c8:cc        0     0        0    =20
  0     0
ste1*  1500 <Link#2>      00:0d:88:fc:c8:cd        0     0        0    =20
  0     0
ste2*  1500 <Link#3>      00:0d:88:fc:c8:ce        0     0        0    =20
  0     0
ste3*  1500 <Link#4>      00:0d:88:fc:c8:cf        0     0        0    =20
  0     0
bge0   1500 <Link#5>      00:12:79:94:ed:12 11343768 2114510 20564242  =20
    0     0
bge1*  1500 <Link#6>      00:12:79:94:ed:11        0     0        0    =20
  0     0
pflog 33208 <Link#7>                               0     0        0    =20
  0     0
lo0   16384 <Link#8>                        60221421     0 60221421    =20
  0     0
[...]

If you have a patch for FreeBSD 6.2, i'm quite happily to test it on =20
our development server.

Regards,

Robin Gruyters





From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 18:13:13 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id B531416A404
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 18:13:13 +0000 (UTC)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp
	[202.249.10.124])
	by mx1.freebsd.org (Postfix) with ESMTP id 7D28413C441
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 18:13:13 +0000 (UTC)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from impact.jinmei.org (shuttle.wide.toshiba.co.jp
	[IPv6:2001:200:1b1::35])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 096E273018;
	Fri, 26 Jan 2007 03:13:12 +0900 (JST)
Date: Fri, 26 Jan 2007 03:13:07 +0900
Message-ID: <y7vmz47x9e4.wl%jinmei@isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: John Hay <jhay@meraka.org.za>
In-Reply-To: <20070121073244.GA80811@zibbi.meraka.csir.co.za>
References: <20070120162936.GA18104@tomcat.kitchenlab.org>
	<20070121073244.GA80811@zibbi.meraka.csir.co.za>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: "Bruce A. Mah" <bmah@freebsd.org>, freebsd-net@freebsd.org
Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 18:13:13 -0000

>>>>> On Sun, 21 Jan 2007 09:32:44 +0200, 
>>>>> John Hay <jhay@meraka.org.za> said:

>> There's another workaround for people stuck in this situation and who
>> aren't in a position to try this diff.  That is to manually install
>> the host route like this:
>> 
>> # route add -host -inet6 aaaa:bbbb:cccc:dddd::2 -interface gif0 -nostatic -llinfo
>> 
>> Comments?

> Well it seems that even my stuff does not always work perfectly with that
> change (1.48.2.15), so maybe we should revert it and I will search for
> yet other ways to make FreeBSD's IPv6 code to actually work for our stuff.

> My "stuff" is a wireless IPv6 only network running in adhoc mode with
> olsrd as the routing protocol. The problem is that all nodes on a subnet
> cannot "see" each other, so olsrd needs to add routes to a node through
> another node. Sometimes, just to complicate matters a little more, you
> would want to have more than one network card in a host, all with the same
> subnet address. (For instance on a high site, with sector antennas.)

> The case that I found that still does not work reliably, is if olsrd add
> the route and route is not immediately used, then the nd code will time
> it out and remove it.

I think I'm responsible for the troubles.  I've been thinking about
how to meet all the requests, and concluded that it's more complicated
than I originally thought.

I've come across an idea that may solve the problems, but I'll need
more time to implement and test it.

At the moment, I suggest reverting the 1.48.2.16 change for those who
simply wanted a gif to work.

Regarding the OLSRD stuff, I'd like to know more specific features
that are sought.  For example,

- what should happen if link-layer address resolution fails?  Should
  then entry be removed?  Probably not according to your description
  above, but what would you expect the entry to become in this case?

- once the link-layer address is resolved for the entry, should it be
  regarded as "permanent" without any ND state changes?  For example,
  should NUD be performed on the cache?  If yes, what should happen if
  NUD detects the neighbor is unreachable?  Should the entry be
  removed?  Again, probably not, but then what should it become?
  Keeping it with the same link-layer address?  Keeping it with an
  empty link-layer address?  Others?  What if the neighbor is acting
  as a router (setting the router flag in NAs)?  Should destination
  caches using the now-unreachable router be removed as described in
  the protocol spec?  Or should the destination caches be intact?

I have my own speculation on these points, but I'd like to know what
the actual user(s) of these features want before taking any action
based on the speculation.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 18:24:36 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 8DB7016A400;
	Thu, 25 Jan 2007 18:24:36 +0000 (UTC) (envelope-from bms@FreeBSD.org)
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
	[66.111.4.28])
	by mx1.freebsd.org (Postfix) with ESMTP id 4F5B213C468;
	Thu, 25 Jan 2007 18:24:36 +0000 (UTC) (envelope-from bms@FreeBSD.org)
Received: from out1.internal (unknown [10.202.2.149])
	by out1.messagingengine.com (Postfix) with ESMTP id BEC0E9763D;
	Thu, 25 Jan 2007 12:38:45 -0500 (EST)
Received: from heartbeat2.messagingengine.com ([10.202.2.161])
	by out1.internal (MEProxy); Thu, 25 Jan 2007 12:38:45 -0500
X-Sasl-enc: j2+PKSGr0AEGO+mGlFuxncAxg1X3jNFh7D5V17V/zUxU 1169746725
Received: from [192.168.123.18]
	(82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254])
	by mail.messagingengine.com (Postfix) with ESMTP id 300F3151A0;
	Thu, 25 Jan 2007 12:38:44 -0500 (EST)
Message-ID: <45B8EB23.705@FreeBSD.org>
Date: Thu, 25 Jan 2007 17:38:43 +0000
From: "Bruce M. Simpson" <bms@FreeBSD.org>
User-Agent: Thunderbird 1.5.0.9 (X11/20070125)
MIME-Version: 1.0
To: Gleb Smirnoff <glebius@FreeBSD.org>
References: <20070125162422.GA7922@bestcom.ru>
In-Reply-To: <20070125162422.GA7922@bestcom.ru>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rwatson@FreeBSD.org, net@FreeBSD.org
Subject: Re: rev. 1.94 of netinet/in.c broke CARP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 18:24:36 -0000

Gleb,

Good catch, thanks for tracking this down.

Gleb Smirnoff wrote:
>   I've just discovered, that revision 1.94 of in.c has broke CARP. This
> change adds a code to in_ifdetach() that goes through the global list
> of all multicast instances and deletes all the instances, that are
> belonging to a particular interface. This is intended to avoid leaking
> multicast instances.
>   
The irony of this of course is that I was working on two separate fixes; 
one to prevent the MROUTING code panicking when an interface was 
suddenly removed, and the other to prevent the netinet ifp detach path 
from panicking in the same circumstances.

These are resource leaks which have been in BSD for years and years. I 
neglected to test them *together* however; carp(4) was being used in the 
test cases for both bugs.

>   Before this change, most of the subsystems, that allocated multicast
> membership instances had freed is theirselves. I don't know about others,
> but at least CARP is broken now. It attempts to free a memory, that
> already has been freed.
>   
I would suggest that the correct fix, for now, would be for carp(4) to 
now *not* perform its own cleanup for the IPv4 groups it joins on member 
interfaces.

The symptom here is that carp(4) needs to join a multicast group on its 
member interface. When the interface goes away, the group membership is 
now destroyed, at the netinet global level, by the netinet detach path 
first.

However, carp(4) is keeping its own imo_membership vector of the 
addresses it joined on its member interfaces (rather than using the one 
which netinet assigns to it in its attach path), and later tries to free 
these memberships.

netinet6 does not have the same problem because in6 memberships are 
reference counted.

The root problem is that we should be using consistent semantics for 
both the IPv4 and IPv6 paths, and the kernel APIs where soft-ifnets 
(such as carp(4)) and routing code (such as MROUTING) need to manipulate 
multicast group memberships.

Regards,
BMS

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 18:37:23 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 88EA016A402;
	Thu, 25 Jan 2007 18:37:23 +0000 (UTC)
	(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (cell.sick.ru [217.72.144.68])
	by mx1.freebsd.org (Postfix) with ESMTP id 06A6913C44C;
	Thu, 25 Jan 2007 18:37:22 +0000 (UTC)
	(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (glebius@localhost [127.0.0.1])
	by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l0PIbK7r010265
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 25 Jan 2007 21:37:20 +0300 (MSK)
	(envelope-from glebius@FreeBSD.org)
Received: (from glebius@localhost)
	by cell.sick.ru (8.13.4/8.13.1/Submit) id l0PIbK6Z010264;
	Thu, 25 Jan 2007 21:37:20 +0300 (MSK)
	(envelope-from glebius@FreeBSD.org)
X-Authentication-Warning: cell.sick.ru: glebius set sender to
	glebius@FreeBSD.org using -f
Date: Thu, 25 Jan 2007 21:37:20 +0300
From: Gleb Smirnoff <glebius@FreeBSD.org>
To: "Bruce M. Simpson" <bms@FreeBSD.org>
Message-ID: <20070125183720.GB7922@cell.sick.ru>
References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <45B8EB23.705@FreeBSD.org>
User-Agent: Mutt/1.5.6i
Cc: rwatson@FreeBSD.org, net@FreeBSD.org
Subject: Re: rev. 1.94 of netinet/in.c broke CARP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 18:37:23 -0000

  Bruce,

On Thu, Jan 25, 2007 at 05:38:43PM +0000, Bruce M. Simpson wrote:
B> Gleb Smirnoff wrote:
B> >  I've just discovered, that revision 1.94 of in.c has broke CARP. This
B> >change adds a code to in_ifdetach() that goes through the global list
B> >of all multicast instances and deletes all the instances, that are
B> >belonging to a particular interface. This is intended to avoid leaking
B> >multicast instances.
B> >  
B> The irony of this of course is that I was working on two separate fixes; 
B> one to prevent the MROUTING code panicking when an interface was 
B> suddenly removed, and the other to prevent the netinet ifp detach path 
B> from panicking in the same circumstances.
B> 
B> These are resource leaks which have been in BSD for years and years. I 
B> neglected to test them *together* however; carp(4) was being used in the 
B> test cases for both bugs.

Yes, I knew that we were leaking memory allocated for multicast purposes
on interface detach. I was trying to fix this with Oleg and Yar, but failed.

B> >  Before this change, most of the subsystems, that allocated multicast
B> >membership instances had freed is theirselves. I don't know about others,
B> >but at least CARP is broken now. It attempts to free a memory, that
B> >already has been freed.
B> >  
B> I would suggest that the correct fix, for now, would be for carp(4) to 
B> now *not* perform its own cleanup for the IPv4 groups it joins on member 
B> interfaces.

Unfortunately, this won't be a correct fix. In a scenario when the parent
interface stays on its place, but you are creating, attaching and
destroying a CARP interface, the multicast membership would not be
left and memory won't be freed. So, after the following sequence

ifconfig fxp0 10.0.0.1/24
ifconfig carp0 create
ifconfig carp0 vhid 1 10.0.0.2/24
ifconfig carp0 destroy

, we would still have a multicast membership on fxp0.

B> The symptom here is that carp(4) needs to join a multicast group on its 
B> member interface. When the interface goes away, the group membership is 
B> now destroyed, at the netinet global level, by the netinet detach path 
B> first.
B> 
B> However, carp(4) is keeping its own imo_membership vector of the 
B> addresses it joined on its member interfaces (rather than using the one 
B> which netinet assigns to it in its attach path), and later tries to free 
B> these memberships.
B> 
B> netinet6 does not have the same problem because in6 memberships are 
B> reference counted.
B> 
B> The root problem is that we should be using consistent semantics for 
B> both the IPv4 and IPv6 paths, and the kernel APIs where soft-ifnets 
B> (such as carp(4)) and routing code (such as MROUTING) need to manipulate 
B> multicast group memberships.

Looks like we need refcounting in IPv4, too.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 21:06:04 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 0AD0B16A404;
	Thu, 25 Jan 2007 21:06:04 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 9CFB013C44C;
	Thu, 25 Jan 2007 21:06:03 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from fledge.watson.org (fledge.watson.org [209.31.154.41])
	by cyrus.watson.org (Postfix) with ESMTP id 624134B89D;
	Thu, 25 Jan 2007 15:40:52 -0500 (EST)
Date: Thu, 25 Jan 2007 20:40:52 +0000 (GMT)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Gleb Smirnoff <glebius@FreeBSD.org>
In-Reply-To: <20070125183720.GB7922@cell.sick.ru>
Message-ID: <20070125203807.S13293@fledge.watson.org>
References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org>
	<20070125183720.GB7922@cell.sick.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "Bruce M. Simpson" <bms@FreeBSD.org>, net@FreeBSD.org
Subject: Re: rev. 1.94 of netinet/in.c broke CARP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 21:06:04 -0000

On Thu, 25 Jan 2007, Gleb Smirnoff wrote:

> B> >  Before this change, most of the subsystems, that allocated multicast
> B> >membership instances had freed is theirselves. I don't know about others,
> B> >but at least CARP is broken now. It attempts to free a memory, that
> B> >already has been freed.
> B> >
> B> I would suggest that the correct fix, for now, would be for carp(4) to
> B> now *not* perform its own cleanup for the IPv4 groups it joins on member
> B> interfaces.
>
> Unfortunately, this won't be a correct fix. In a scenario when the parent 
> interface stays on its place, but you are creating, attaching and destroying 
> a CARP interface, the multicast membership would not be left and memory 
> won't be freed. So, after the following sequence
>
> ifconfig fxp0 10.0.0.1/24
> ifconfig carp0 create
> ifconfig carp0 vhid 1 10.0.0.2/24
> ifconfig carp0 destroy
>
> , we would still have a multicast membership on fxp0.
>
> B> The symptom here is that carp(4) needs to join a multicast group on its 
> B> member interface. When the interface goes away, the group membership is 
> B> now destroyed, at the netinet global level, by the netinet detach path B> 
> first. B> B> However, carp(4) is keeping its own imo_membership vector of 
> the B> addresses it joined on its member interfaces (rather than using the 
> one B> which netinet assigns to it in its attach path), and later tries to 
> free B> these memberships. B> B> netinet6 does not have the same problem 
> because in6 memberships are B> reference counted. B> B> The root problem is 
> that we should be using consistent semantics for B> both the IPv4 and IPv6 
> paths, and the kernel APIs where soft-ifnets B> (such as carp(4)) and 
> routing code (such as MROUTING) need to manipulate B> multicast group 
> memberships.

Architecturally, the right fix is that CARP needs to have a handler for ifnet 
destruction that always runs before the multicast address garbage collection. 
I'm pretty preoccupied for the next few days due to an impending paper 
deadline, so can't investigate further currently, but one way or the other 
that ordering dependency needs to be expressed.  If done properly, CARP will 
always have released its multicast address before they are forceably removed. 
Having the reference count is good too, but what I describe should be 
sufficient regardless of the refcount.

Robert N M Watson
Computer Laboratory
University of Cambridge

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 21:23:13 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id C441816A402;
	Thu, 25 Jan 2007 21:23:13 +0000 (UTC)
	(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (cell.sick.ru [217.72.144.68])
	by mx1.freebsd.org (Postfix) with ESMTP id 49ECB13C44B;
	Thu, 25 Jan 2007 21:23:13 +0000 (UTC)
	(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (glebius@localhost [127.0.0.1])
	by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l0PLNAA6011307
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Jan 2007 00:23:11 +0300 (MSK)
	(envelope-from glebius@FreeBSD.org)
Received: (from glebius@localhost)
	by cell.sick.ru (8.13.4/8.13.1/Submit) id l0PLNALV011306;
	Fri, 26 Jan 2007 00:23:10 +0300 (MSK)
	(envelope-from glebius@FreeBSD.org)
X-Authentication-Warning: cell.sick.ru: glebius set sender to
	glebius@FreeBSD.org using -f
Date: Fri, 26 Jan 2007 00:23:10 +0300
From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Robert Watson <rwatson@FreeBSD.org>
Message-ID: <20070125212310.GG7922@cell.sick.ru>
References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org>
	<20070125183720.GB7922@cell.sick.ru>
	<20070125203807.S13293@fledge.watson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <20070125203807.S13293@fledge.watson.org>
User-Agent: Mutt/1.5.6i
Cc: "Bruce M. Simpson" <bms@FreeBSD.org>, net@FreeBSD.org
Subject: Re: rev. 1.94 of netinet/in.c broke CARP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 21:23:13 -0000

On Thu, Jan 25, 2007 at 08:40:52PM +0000, Robert Watson wrote:
R> Architecturally, the right fix is that CARP needs to have a handler for 
R> ifnet destruction that always runs before the multicast address garbage 
R> collection. I'm pretty preoccupied for the next few days due to an 
R> impending paper deadline, so can't investigate further currently, but one 
R> way or the other that ordering dependency needs to be expressed.  If done 
R> properly, CARP will always have released its multicast address before they 
R> are forceably removed. Having the reference count is good too, but what I 
R> describe should be sufficient regardless of the refcount.

This means removing usage of EVENTHANDLER(9) and going back to
exporting carp_ifdetach() and calling it directly from if_detach().
This is back out revision 1.255 of net/if.c. Not sure what is a right
way...

I am worried about that CARP is not the only subsystem in kernel
that can join a multicast group on an ifnet, and keep a pointer
to the multicast instance.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 21:33:32 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 25EAF16A406;
	Thu, 25 Jan 2007 21:33:32 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from moutng.kundenserver.de (moutng.kundenserver.de
	[212.227.126.183])
	by mx1.freebsd.org (Postfix) with ESMTP id A41B213C44B;
	Thu, 25 Jan 2007 21:33:31 +0000 (UTC)
	(envelope-from max@love2party.net)
Received: from [88.66.51.18] (helo=amd64.laiers.local)
	by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis),
	id 0MKwpI-1HACDm3Rcc-0006zQ; Thu, 25 Jan 2007 22:33:31 +0100
From: Max Laier <max@love2party.net>
Organization: FreeBSD
To: freebsd-net@freebsd.org
Date: Thu, 25 Jan 2007 22:33:10 +0100
User-Agent: KMail/1.9.5
References: <20070125162422.GA7922@bestcom.ru>
	<20070125203807.S13293@fledge.watson.org>
	<20070125212310.GG7922@cell.sick.ru>
In-Reply-To: <20070125212310.GG7922@cell.sick.ru>
X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGd<hB5S>u+2];
	R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1765310.oDHRGgHRZ9";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200701252233.17309.max@love2party.net>
X-Provags-ID: kundenserver.de abuse@kundenserver.de
	login:61c499deaeeba3ba5be80f48ecc83056
X-Provags-ID2: V01U2FsdGVkX19I08y7gk0V+ds24FUKxqS/FXgHHeSRgKlWJq21KERtIigRUE4Z0sTcQWjuDm3vgad7lUuPNnXz2O/LEImzMSwMpQ8I8jiQPNXZjXpMdH1Jdg==
Cc: "Bruce M. Simpson" <bms@freebsd.org>, Robert Watson <rwatson@freebsd.org>
Subject: Re: rev. 1.94 of netinet/in.c broke CARP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 21:33:32 -0000

--nextPart1765310.oDHRGgHRZ9
Content-Type: text/plain;
  charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 25 January 2007 22:23, Gleb Smirnoff wrote:
> On Thu, Jan 25, 2007 at 08:40:52PM +0000, Robert Watson wrote:
> R> Architecturally, the right fix is that CARP needs to have a handler
> for R> ifnet destruction that always runs before the multicast address
> garbage R> collection. I'm pretty preoccupied for the next few days due
> to an R> impending paper deadline, so can't investigate further
> currently, but one R> way or the other that ordering dependency needs
> to be expressed.  If done R> properly, CARP will always have released
> its multicast address before they R> are forceably removed. Having the
> reference count is good too, but what I R> describe should be
> sufficient regardless of the refcount.
>
> This means removing usage of EVENTHANDLER(9) and going back to
> exporting carp_ifdetach() and calling it directly from if_detach().
> This is back out revision 1.255 of net/if.c. Not sure what is a right
> way...
>
> I am worried about that CARP is not the only subsystem in kernel
> that can join a multicast group on an ifnet, and keep a pointer
> to the multicast instance.

pfsync might, but from a quick glance at this thread and code it seems=20
non-related.  I'll look more closely later.

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart1765310.oDHRGgHRZ9
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQBFuSIdXyyEoT62BG0RAvYZAJ4sxF8FIAc8ujb9g/DQjaNTA39DWgCbBzR+
WiIpdnP9NU2kGp0noOIQ0mA=
=ZF/B
-----END PGP SIGNATURE-----

--nextPart1765310.oDHRGgHRZ9--

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 22:00:10 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 9634216A402;
	Thu, 25 Jan 2007 22:00:10 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 03FFA13C455;
	Thu, 25 Jan 2007 22:00:09 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from fledge.watson.org (fledge.watson.org [209.31.154.41])
	by cyrus.watson.org (Postfix) with ESMTP id 691B049839;
	Thu, 25 Jan 2007 17:00:08 -0500 (EST)
Date: Thu, 25 Jan 2007 22:00:08 +0000 (GMT)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: Gleb Smirnoff <glebius@FreeBSD.org>
In-Reply-To: <20070125212310.GG7922@cell.sick.ru>
Message-ID: <20070125214956.J13293@fledge.watson.org>
References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org>
	<20070125183720.GB7922@cell.sick.ru>
	<20070125203807.S13293@fledge.watson.org>
	<20070125212310.GG7922@cell.sick.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "Bruce M. Simpson" <bms@FreeBSD.org>, net@FreeBSD.org
Subject: Re: rev. 1.94 of netinet/in.c broke CARP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 22:00:11 -0000


On Fri, 26 Jan 2007, Gleb Smirnoff wrote:

> On Thu, Jan 25, 2007 at 08:40:52PM +0000, Robert Watson wrote:
> R> Architecturally, the right fix is that CARP needs to have a handler for
> R> ifnet destruction that always runs before the multicast address garbage
> R> collection. I'm pretty preoccupied for the next few days due to an
> R> impending paper deadline, so can't investigate further currently, but one
> R> way or the other that ordering dependency needs to be expressed.  If done
> R> properly, CARP will always have released its multicast address before they
> R> are forceably removed. Having the reference count is good too, but what I
> R> describe should be sufficient regardless of the refcount.
>
> This means removing usage of EVENTHANDLER(9) and going back to exporting 
> carp_ifdetach() and calling it directly from if_detach(). This is back out 
> revision 1.255 of net/if.c. Not sure what is a right way...
>
> I am worried about that CARP is not the only subsystem in kernel that can 
> join a multicast group on an ifnet, and keep a pointer to the multicast 
> instance.

Alternatively, we move to having two event handlers: one for general stack 
consumers to use, and a second one to do low level address and protocol 
cleanup.  CARP would use the former, multicast address stuff the latter...

Robert N M Watson
Computer Laboratory
University of Cambridge

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 22:46:01 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id CE76E16A415
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 22:46:01 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179])
	by mx1.freebsd.org (Postfix) with ESMTP id 884F513C441
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 22:46:01 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from [213.141.131.138] (helo=localhost)
	by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1HADRa-000IpY-4C
	for freebsd-net@freebsd.org; Fri, 26 Jan 2007 01:51:46 +0300
Date: Fri, 26 Jan 2007 01:47:28 +0300
From: Wishmaster <wishmaster@velnet.ru>
X-Mailer: The Bat! (v2.12.00)
X-Priority: 3 (Normal)
Message-ID: <1582899958.20070126014728@velnet.ru>
To: freebsd-net@freebsd.org
In-Reply-To: <45B4BE90.20602@qwirky.net>
References: <1458229821.20070120234257@velnet.ru>
	<45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru>
	<be0088ce0701220431tf96827et3713885fac8a490a@mail.gmail.com>
	<45B4BE90.20602@qwirky.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re[2]: reproducible watchdog timeout in bge
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Wishmaster <wishmaster@velnet.ru>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 22:46:01 -0000

Hello Jeff,

Monday, January 22, 2007, 4:39:28 PM, you wrote:


JR> I have been unable to produce time outs with my current setup in 
JR> 6.2-Release.

JR> bge0@pci3:0:0:  class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x11
JR> hdr=0x00
JR>      vendor   = 'Broadcom Corporation'
JR>      device   = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
JR>      class    = network
JR>      subclass = ethernet

JR> Reading the PR, I attempted triggering this through CVSing and through
JR> the above mentioned ping tests.

JR> So far nothing.

JR> The only issue I have seen using these NICs in 6.2R is if I nail up the
JR> NIC at 100baseTX full-duplex I sometimes loose connectivity.  Nothing
JR> in the logs indicate watchdog timeouts or any other issue.   I simply
JR> brought the NIC back down to auto-neg and all seems fine.   I am 
JR> assuming this is a incompatibility between the BGE and my switch, RS8000.

JR> I have a Asus P5MT-S with dual BGE NIC's

JR> Cheers,

JR> Jeff
JR> _______________________________________________
JR> freebsd-net@freebsd.org mailing list
JR> http://lists.freebsd.org/mailman/listinfo/freebsd-net
JR> To unsubscribe, send any mail to
JR> "freebsd-net-unsubscribe@freebsd.org"


pciconf says:
bge0@pci3:0:0:  class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x21 hdr=0x00
    vendor   = 'Broadcom Corporation'
    device   = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
    class    = network
    subclass = ethernet
bge1@pci4:0:0:  class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x21 hdr=0x00
    vendor   = 'Broadcom Corporation'
    device   = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
    class    = network
    subclass = ethernet

So, if you have no troubles can you tell do you have smp kernel with
apic and what distribution you are using?

On my configuration I have dual core intel xeon 30xx series  with
SMP and APIC kernel (i386 distribution). This issue appears just after system boots up.

If you have non-smp kernel can you try to recompile it with smp and
apic support?

p.s. motherboard asus p5m2/2gbl

-- 
Best regards,
 Wishmaster                            mailto:wishmaster-velnet@yandex.ru



From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 22:50:42 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 7488616A401
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 22:50:42 +0000 (UTC)
	(envelope-from edwin@mavetju.org)
Received: from mail4out.barnet.com.au (mail4.barnet.com.au [202.83.178.125])
	by mx1.freebsd.org (Postfix) with ESMTP id 38E9813C461
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 22:50:42 +0000 (UTC)
	(envelope-from edwin@mavetju.org)
Received: by mail4out.barnet.com.au (Postfix, from userid 1001)
	id 997B137BB47; Fri, 26 Jan 2007 09:50:41 +1100 (EST)
X-Viruscan-Id: <45B93441000148209CDE5C@BarNet>
Received: from mail4auth.barnet.com.au (mail4.barnet.com.au [202.83.178.125])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by mail4.barnet.com.au (Postfix) with ESMTP id 6C23B424A6D;
	Fri, 26 Jan 2007 09:50:41 +1100 (EST)
Received: from k7.mavetju (k7.mavetju.org [10.251.1.18])
	by mail4auth.barnet.com.au (Postfix) with ESMTP id 263AF37BB58;
	Fri, 26 Jan 2007 09:50:41 +1100 (EST)
Received: by k7.mavetju (Postfix, from userid 1001)
	id EFB961A0; Fri, 26 Jan 2007 09:50:40 +1100 (EST)
Date: Fri, 26 Jan 2007 09:50:40 +1100
From: Edwin Groothuis <edwin@mavetju.org>
To: Yuri Lukin <lists@swaggi.com>
Message-ID: <20070125225040.GD90167@k7.mavetju>
References: <1729.65.117.48.154.1169568902.squirrel@admintool.trueband.net>
	<20070124020027.GC90167@k7.mavetju>
	<20070124122525.M93545@swaggi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070124122525.M93545@swaggi.com>
User-Agent: Mutt/1.4.2.1i
Cc: freebsd-net@freebsd.org
Subject: Re: VLANs and DHCP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 22:50:42 -0000

On Wed, Jan 24, 2007 at 07:36:51AM -0500, Yuri Lukin wrote:
> On Tue, Jan 23, 2007 at 04:15:02PM -0000, jhall@vandaliamo.net wrote:
> > I currently administer a system which has two DHCP servers on two
> > different VLANs.  Unfortunately, the two servers are not playing together
> > well and some comptuers are receiving IP addresses on the wrong network. 
> > So, with our phone vendor's blessing, I am trying to move all of the DHCP
> > services to the FreeBSD server.
> > 
> > The computers on the network are supposed to receive an IP address on the
> > default vlan and the phones are supposed to receive an IP address on their
> > vlan.
> > 
> > Essentially what happens when a phone is booted, the phone receives an IP
> > address on the default VLAN, releases that address and then requests an IP
> > address on the appropriate VLAN.
> 
> Just a thought but if your switch properly tags the packets from the voice and
> data Vlans, the broadcasts from the IP Phones should not cross over to the
> data Vlan. We  have dozens of customers setup this way and they are not having
> any problems. Not sure what type of switches you are using but I would check
> your switchport configuration (assuming managed switch).  

Look at the behaviour of the ISC-dhcrelay. It's euhm... very
interesting if you have multiple ethernet cards in the server.

Edwin

-- 
Edwin Groothuis      |            Personal website: http://www.mavetju.org
edwin@mavetju.org    |          Weblog: http://weblog.barnet.com.au/edwin/

From owner-freebsd-net@FreeBSD.ORG  Thu Jan 25 23:36:16 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 2427C16A402
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 23:36:16 +0000 (UTC)
	(envelope-from ticso@cicely12.cicely.de)
Received: from raven.bwct.de (raven.bwct.de [85.159.14.73])
	by mx1.freebsd.org (Postfix) with ESMTP id AC7F613C46A
	for <freebsd-net@freebsd.org>; Thu, 25 Jan 2007 23:36:15 +0000 (UTC)
	(envelope-from ticso@cicely12.cicely.de)
Received: from cicely5.cicely.de ([10.1.1.7])
	by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l0PNB6ks083115;
	Fri, 26 Jan 2007 00:11:06 +0100 (CET)
	(envelope-from ticso@cicely12.cicely.de)
Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14])
	by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l0PNAqlL053940
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Jan 2007 00:10:53 +0100 (CET)
	(envelope-from ticso@cicely12.cicely.de)
Received: from cicely12.cicely.de (localhost [127.0.0.1])
	by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l0PNAqUL044939;
	Fri, 26 Jan 2007 00:10:52 +0100 (CET)
	(envelope-from ticso@cicely12.cicely.de)
Received: (from ticso@localhost)
	by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l0PNAqBV044938;
	Fri, 26 Jan 2007 00:10:52 +0100 (CET) (envelope-from ticso)
Date: Fri, 26 Jan 2007 00:10:52 +0100
From: Bernd Walter <ticso@cicely12.cicely.de>
To: freebsd-usb@freebsd.org, freebsd-net@freebsd.org
Message-ID: <20070125231051.GE44259@cicely12.cicely.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha
User-Agent: Mutt/1.5.9i
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8,
	BAYES_00=-2.599 autolearn=ham version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de
Cc: Bernd Walter <ticso@cicely12.cicely.de>
Subject: Anyone working on RTL8187 USB WLAN support?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ticso@cicely.de
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2007 23:36:16 -0000

Just as the subject says.
Devices are a bit cheaper to get than ralink based.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd@bwct.de           info@bwct.de            support@fizon.de

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 03:18:09 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 1116B16A703
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 03:18:05 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailout2.pacific.net.au (mailout2-3.pacific.net.au [61.8.2.226])
	by mx1.freebsd.org (Postfix) with ESMTP id CE09713C483
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 03:18:04 +0000 (UTC)
	(envelope-from bde@zeta.org.au)
Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au
	[61.8.2.162])
	by mailout2.pacific.net.au (Postfix) with ESMTP id 21AE26E2BA;
	Fri, 26 Jan 2007 14:18:01 +1100 (EST)
Received: from besplex.bde.org (katana.zip.com.au [61.8.7.246])
	by mailproxy1.pacific.net.au (Postfix) with ESMTP id B84F08C07;
	Fri, 26 Jan 2007 14:18:02 +1100 (EST)
Date: Fri, 26 Jan 2007 14:18:01 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@besplex.bde.org
To: Robin Gruyters <r.gruyters@yirdis.nl>
In-Reply-To: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net>
Message-ID: <20070126141754.X7697@besplex.bde.org>
References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net@freebsd.org
Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R]
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 03:18:09 -0000

On Thu, 25 Jan 2007, Robin Gruyters wrote:

> On 13-Jan-2007 Oleg Bulyzhin wrote:
>> 
>> > Could you please test attached patch? It should fix ierrs issue and 
>> should not
>> > break link events (would be fine to test it: unplug/plug cable, try to 
>> change
>> > media with ifconfig, change media on other end of wire).
>
> Just wondering will this patch/update be available for RELENG_6? I have the 
> same problems here with 3 of our servers.
> ...
> And here the netstat interface statistics:
> [...]
> Name    Mtu Network       Address              Ipkts Ierrs    Opkts Oerrs 
> Coll
> ...
> bge0   1500 <Link#5>      00:12:79:94:ed:12 11343768 2114510 20564242     0 
> 0
> bge1*  1500 <Link#6>      00:12:79:94:ed:11        0     0        0     0 
> 0

I think the bug fixed by the patch couldn't cause so many errors (unless
Ipkts has overflowed and the uptime more than a week).

Bruce

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 06:47:16 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id CD21616A402
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 06:47:16 +0000 (UTC)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp
	[202.249.10.124])
	by mx1.freebsd.org (Postfix) with ESMTP id D2FC313C4B5
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 06:47:15 +0000 (UTC)
	(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from impact.jinmei.org (unknown
	[IPv6:2001:200:1b1:1010:805d:f488:329:8dc5])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 9903B73019;
	Fri, 26 Jan 2007 15:47:13 +0900 (JST)
Date: Fri, 26 Jan 2007 15:47:08 +0900
Message-ID: <y7v3b5yxp1v.wl%jinmei@isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	<jinmei@isl.rdc.toshiba.co.jp>
To: "Frank Behrens" <frank@pinky.sax.de>
In-Reply-To: <200701251309.l0PD9S5W071724@pinky.frank-behrens.de>
References: <200701251309.l0PD9S5W071724@pinky.frank-behrens.de>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: freebsd-net@freebsd.org
Subject: Re: When IPv6 temporary addresses are regenerated?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 06:47:16 -0000

>>>>> On Thu, 25 Jan 2007 14:09:28 +0100, 
>>>>> "Frank Behrens" <frank@pinky.sax.de> said:

> I have an IPv6 setup with temporary addresses (RFC3041). To switch this on I used "sysctl 
> net.inet6.ip6.use_tempaddr=1". The temporary address is generated and meanwhile expired. 

> Does anybody know, when this address is expected to be regenerated?

As described in RFC3041 (and in its successor draft),

   When a temporary address becomes deprecated, a new one should be
   generated.

(from section 3.4 of RFC3041).  FreeBSD should behave that way (on my
laptop running 6.2-PRERELEASE, I have two temporary addresses; one is
preferred and the other is deprecated).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

p.s. if you want to get a useful answer, it's generally advisable not
to hide details as in xxx.xxx.xx.xx, especially when you are not
certain about some aspect of the matter - because such details are
often a key to the answer.  If you do not want to disclose your
internal information but want to get an answer, I'd recommend you to
reproduce the situation using prefixes for documentations/examples
like 192.0.2.0/24 and 2001:db8::/32 and show every detail.

> My current interface configuration is
> vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet xxx.xxx.xx.xx netmask 0xffffff00 broadcast xxx.xxx.xxx.xxx
>         inet6 fe80::211:xxxx:xxxx:xxxx%vlan0 prefixlen 64 scopeid 0x5
>         inet6 2xxx:xxxx:xxxx:: prefixlen 64 anycast
>         inet6 2xxx:xxxx:xxxx:0:211:2fff:xxxx:xxxx prefixlen 64
>         inet6 2xxx:xxxx:xxxx:0:54b:5960:xxxx:xxxx prefixlen 64 deprecated autoconf temporary pltime 0 vltime 509995

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 07:59:22 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id DEC3116A401
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 07:59:22 +0000 (UTC)
	(envelope-from r.gruyters@yirdis.nl)
Received: from mail.yirdis.nl (82-148-208-109.fiber.unet.nl [82.148.208.109])
	by mx1.freebsd.org (Postfix) with ESMTP id 75D9C13C483
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 07:59:21 +0000 (UTC)
	(envelope-from r.gruyters@yirdis.nl)
Received: from server.yirdis.net (localhost [127.0.0.1])
	by mail.yirdis.nl (8.13.6/8.13.6) with ESMTP id l0Q7xJZC028161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Jan 2007 08:59:19 +0100 (CET)
	(envelope-from r.gruyters@yirdis.nl)
Received: (from www@localhost)
	by server.yirdis.net (8.13.6/8.13.6/Submit) id l0Q7xI12028160;
	Fri, 26 Jan 2007 08:59:18 +0100 (CET)
	(envelope-from r.gruyters@yirdis.nl)
X-Authentication-Warning: server.yirdis.net: www set sender to
	r.gruyters@yirdis.nl using -f
Received: from hp-xw4100-01.yirdis.nl (hp-xw4100-01.yirdis.nl [10.8.0.27])
	by webmail.yirdis.nl (Horde MIME library) with HTTP; Fri, 26 Jan 2007
	08:59:18 +0100
Message-ID: <20070126085918.710xjsopz48kso4w@webmail.yirdis.nl>
Date: Fri, 26 Jan 2007 08:59:18 +0100
From: Robin Gruyters <r.gruyters@yirdis.nl>
To: Bruce Evans <bde@zeta.org.au>
References: <20070125170532.c9c2374hkwk4oc4k@server.yirdis.net>
	<20070126141754.X7697@besplex.bde.org>
In-Reply-To: <20070126141754.X7697@besplex.bde.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) / FreeBSD-5.4
X-Virus-Scanned: OK
Cc: freebsd-net@freebsd.org
Subject: Re: [Fwd: Re: bge Ierr rate increase from 5.3R -> 6.1R]
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 07:59:22 -0000

Quoting Bruce Evans <bde@zeta.org.au>:

> On Thu, 25 Jan 2007, Robin Gruyters wrote:
>
>> On 13-Jan-2007 Oleg Bulyzhin wrote:
>>>
>>>> Could you please test attached patch? It should fix ierrs issue and
>>> should not
>>>> break link events (would be fine to test it: unplug/plug cable, try
>>> to change
>>>> media with ifconfig, change media on other end of wire).
>>
>> Just wondering will this patch/update be available for RELENG_6? I  =20
>> have the same problems here with 3 of our servers.
>> ...
>> And here the netstat interface statistics:
>> [...]
>> Name    Mtu Network       Address              Ipkts Ierrs    Opkts =20
>>  Oerrs Coll
>> ...
>> bge0   1500 <Link#5>      00:12:79:94:ed:12 11343768 2114510  =20
>> 20564242     0 0
>> bge1*  1500 <Link#6>      00:12:79:94:ed:11        0     0        0     0=
 0
>
> I think the bug fixed by the patch couldn't cause so many errors (unless
> Ipkts has overflowed and the uptime more than a week).
>
The server was up almost for 11 days.

[...]
  8:56AM  up 10 days, 17:13, 1 user, load averages: 0.03, 0.04, 0.02
[...]

- Robin

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 11:39:58 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 1EB0516A501
	for <net@freebsd.org>; Fri, 26 Jan 2007 11:39:58 +0000 (UTC)
	(envelope-from eugen@grosbein.pp.ru)
Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.166])
	by mx1.freebsd.org (Postfix) with ESMTP id 8514E13C483
	for <net@freebsd.org>; Fri, 26 Jan 2007 11:39:56 +0000 (UTC)
	(envelope-from eugen@grosbein.pp.ru)
Received: from grosbein.pp.ru (localhost [127.0.0.1])
	by grosbein.pp.ru (8.13.8/8.13.8) with ESMTP id l0PIfkax060528
	for <net@freebsd.org>; Fri, 26 Jan 2007 01:41:46 +0700 (KRAT)
	(envelope-from eugen@grosbein.pp.ru)
Received: (from eugen@localhost)
	by grosbein.pp.ru (8.13.8/8.13.8/Submit) id l0PIfknl060527
	for net@freebsd.org; Fri, 26 Jan 2007 01:41:46 +0700 (KRAT)
	(envelope-from eugen)
Date: Fri, 26 Jan 2007 01:41:46 +0700
From: Eugene Grosbein <eugen@kuzbass.ru>
To: net@freebsd.org
Message-ID: <20070125184146.GA60481@grosbein.pp.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.2i
Cc: 
Subject: interface metric & quagga
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 11:39:58 -0000

Hi!

'route -n monitor' shows me that 'ifconfig up' command
produces RTM_NEWADDR, RTM_ADD and RTM_IFINFO message.

RTM_NEWADDR contains 'metric 0' regardless of interface metric
value set with ifconfig before. quagga, since version 0.99.3,
takes metric value from RTM_NEWADDR message and this value overrides
right interface metric learned by quagga a milisecond before.
Then it passes zero interface metric to ripd that uses interface
metric as hop count increment for RIP-learned routes.
This effectively breaks RIPv2 for FreeBSD (quagga-0.99.2 and older
versions do not use metric from RTM_NEWADDR and work), perhaps RIPv1 too.

Verified with RELENG_4 and RELENG_6.
Is it kernel bug or quagga bug?

I also suggest to include next patch to the Ports tree
if no objections. It restores RIP support.

--- zebra/kernel_socket.c.orig	Fri Jan 26 01:10:06 2007
+++ zebra/kernel_socket.c	Fri Jan 26 01:10:17 2007
@@ -585,8 +585,6 @@
   if (ifnlen && strncmp (ifp->name, ifname, INTERFACE_NAMSIZ))
     isalias = 1;
   
-  ifp->metric = ifam->ifam_metric;
-  
   /* Add connected address. */
   switch (sockunion_family (&addr))
     {


Eugene Grosbein

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 11:44:52 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 3BADD16A405;
	Fri, 26 Jan 2007 11:44:52 +0000 (UTC)
	(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (cell.sick.ru [217.72.144.68])
	by mx1.freebsd.org (Postfix) with ESMTP id 9F55913C481;
	Fri, 26 Jan 2007 11:44:51 +0000 (UTC)
	(envelope-from glebius@FreeBSD.org)
Received: from cell.sick.ru (glebius@localhost [127.0.0.1])
	by cell.sick.ru (8.13.4/8.13.3) with ESMTP id l0QBinUL016534
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Jan 2007 14:44:49 +0300 (MSK)
	(envelope-from glebius@FreeBSD.org)
Received: (from glebius@localhost)
	by cell.sick.ru (8.13.4/8.13.1/Submit) id l0QBini4016533;
	Fri, 26 Jan 2007 14:44:49 +0300 (MSK)
	(envelope-from glebius@FreeBSD.org)
X-Authentication-Warning: cell.sick.ru: glebius set sender to
	glebius@FreeBSD.org using -f
Date: Fri, 26 Jan 2007 14:44:49 +0300
From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Robert Watson <rwatson@FreeBSD.org>
Message-ID: <20070126114449.GM7922@cell.sick.ru>
References: <20070125162422.GA7922@bestcom.ru> <45B8EB23.705@FreeBSD.org>
	<20070125183720.GB7922@cell.sick.ru>
	<20070125203807.S13293@fledge.watson.org>
	<20070125212310.GG7922@cell.sick.ru>
	<20070125214956.J13293@fledge.watson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
In-Reply-To: <20070125214956.J13293@fledge.watson.org>
User-Agent: Mutt/1.5.6i
Cc: "Bruce M. Simpson" <bms@FreeBSD.org>, net@FreeBSD.org
Subject: Re: rev. 1.94 of netinet/in.c broke CARP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 11:44:52 -0000

On Thu, Jan 25, 2007 at 10:00:08PM +0000, Robert Watson wrote:
R> >On Thu, Jan 25, 2007 at 08:40:52PM +0000, Robert Watson wrote:
R> >R> Architecturally, the right fix is that CARP needs to have a handler for
R> >R> ifnet destruction that always runs before the multicast address garbage
R> >R> collection. I'm pretty preoccupied for the next few days due to an
R> >R> impending paper deadline, so can't investigate further currently, but 
R> >one
R> >R> way or the other that ordering dependency needs to be expressed.  If 
R> >done
R> >R> properly, CARP will always have released its multicast address before 
R> >they
R> >R> are forceably removed. Having the reference count is good too, but what 
R> >I
R> >R> describe should be sufficient regardless of the refcount.
R> >
R> >This means removing usage of EVENTHANDLER(9) and going back to exporting 
R> >carp_ifdetach() and calling it directly from if_detach(). This is back out 
R> >revision 1.255 of net/if.c. Not sure what is a right way...
R> >
R> >I am worried about that CARP is not the only subsystem in kernel that can 
R> >join a multicast group on an ifnet, and keep a pointer to the multicast 
R> >instance.
R> 
R> Alternatively, we move to having two event handlers: one for general stack 
R> consumers to use, and a second one to do low level address and protocol 
R> cleanup.  CARP would use the former, multicast address stuff the latter...

Well, I am just not sure that the new coding strategy, chosen by Bruce is
correct. We used to have every subsystem to join multicast membership itself,
and leave it itself. Due to bugs in the Ethernet layer (?) on interface
detach some multicast memberships were not left and thus memory was leaking.

Is adding a generic GC function a correct way or was it better to just fix
the buggy layer, that forgot about its multicast memberships?

ATM, I can fix the CARP in the following way:

1) Call multicast cleanup, if we are destroying carp interface itself.
2) Don't call multicast cleanup, if we are called through EVENTHANDLER(9)
   since parent is detaching.

Would this fix be ok?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 15:38:18 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 394D216A404
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 15:38:18 +0000 (UTC)
	(envelope-from frank@pinky.sax.de)
Received: from pinky.frank-behrens.de (pinky.frank-behrens.de [82.139.199.24])
	by mx1.freebsd.org (Postfix) with ESMTP id 983D213C46E
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 15:38:15 +0000 (UTC)
	(envelope-from frank@pinky.sax.de)
Received: from [192.168.20.32] (sun.behrens [192.168.20.32])
	by pinky.frank-behrens.de (8.13.8/8.13.8) with ESMTP id l0QFcDNa002222
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 16:38:13 +0100 (CET)
	(envelope-from frank@pinky.sax.de)
Message-Id: <200701261538.l0QFcDNa002222@pinky.frank-behrens.de>
From: "Frank Behrens" <frank@pinky.sax.de>
To: freebsd-net@freebsd.org
Date: Fri, 26 Jan 2007 16:38:14 +0100
MIME-Version: 1.0
Priority: normal
In-reply-to: <200701251309.l0PD9S5W071724@pinky.frank-behrens.de>
X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1)
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: 8BIT
Content-description: Mail message body
Subject: Re: When IPv6 temporary addresses are regenerated?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 15:38:18 -0000

As nobody made a reply I will reply myself. ;-)

Frank Behrens <frank@pinky.sax.de> wrote on 25 Jan 2007 14:09:
> I have an IPv6 setup with temporary addresses (RFC3041). To switch this on I used "sysctl 
> net.inet6.ip6.use_tempaddr=1". The temporary address is generated and meanwhile expired. 
> 
> Does anybody know, when this address is expected to be regenerated?

Short answer after digging in the sources:
A new temporary address is regenerated, when there is another address configured with flag 
"autoconf" (and temporary address is deprecated).

The specification says, the temporary addresses should be generated for interfaces setup 
with stateless address autoconfiguration. What for a setup do I have? My FreeBSD router is 
connected via PPP, so I inserted the assigned _prefix_ in rc.conf. Now I have a half 
autoconfiguration, the prefix is assigned statically combined with IEEE identifiers.
You see that in my current config:
>         inet6 2xxx:xxxx:xxxx:0:211:2fff:xxxx:xxxx prefixlen 64
>         inet6 2xxx:xxxx:xxxx:0:54b:5960:xxxx:xxxx prefixlen 64 deprecated autoconf temporary pltime 0 vltime 509995

But we can change the autoconf interface attribute with the undocumented ifconfig(8) flag 
with same name. In that case all works as expected.

To achieve this as simple as possible I changed my rc.conf from
ipv6_prefix_vlan0="2xxx:xxx:xxxx:x"
to
ipv6_ifconfig_vlan0="2xxx:xxx:xxxx:x:: prefixlen 64 eui64 autoconf"

The site effect is, that there is now no automatic assigment of a 64 bit anycast address for 
this interface, but that does not matter in my setup.

So my problem is solved, maybe someone can document the behaviour.

Gruß,
   Frank
-- 
Frank Behrens, Osterwieck, Germany
PGP-key 0x5B7C47ED on public servers available.


From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 17:30:19 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id F1B2816A408
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 17:30:18 +0000 (UTC)
	(envelope-from ericx@vineyard.net)
Received: from smtp1.vineyard.net (a1.vineyard.net [204.17.195.95])
	by mx1.freebsd.org (Postfix) with ESMTP id 9ED7313C4AD
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 17:30:18 +0000 (UTC)
	(envelope-from ericx@vineyard.net)
Received: from localhost (loopback [127.0.0.1])
	by smtp1.vineyard.net (Postfix) with ESMTP id BD8711581A7B
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 12:06:37 -0500 (EST)
Received: from smtp1.vineyard.net ([127.0.0.1])
	by localhost (ace1.vineyard.net [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 10571-01-5 for <freebsd-net@freebsd.org>;
	Fri, 26 Jan 2007 12:06:32 -0500 (EST)
Received: from [204.17.195.104] (fortiva.vineyard.net [204.17.195.104])
	by smtp1.vineyard.net (Postfix) with ESMTP id 114D415818EA
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 11:47:20 -0500 (EST)
Message-ID: <45BA3083.7020006@vineyard.net>
Date: Fri, 26 Jan 2007 11:46:59 -0500
From: "Eric W. Bates" <ericx@vineyard.net>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: freebsd-net@freebsd.org
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS-ace1 at Vineyard.NET
Subject: About NAT Traversal
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 17:30:19 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Can someone please refer me to some documentation describing how to
implement NAT Traversal?

- --
Eric W. Bates
ericx@vineyard.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFujCDD1roJTQ4LlERAsKOAKCQMNTdzlR/tW130s0hWKqb2j3wkgCgk4Sy
7+/Hv8jHZHj4dOcgNbbM+lE=
=OpF/
-----END PGP SIGNATURE-----

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 18:39:01 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 8B49C16A403
	for <net@freebsd.org>; Fri, 26 Jan 2007 18:39:01 +0000 (UTC)
	(envelope-from bms@FreeBSD.org)
Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com
	[66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6488C13C494
	for <net@freebsd.org>; Fri, 26 Jan 2007 18:38:59 +0000 (UTC)
	(envelope-from bms@FreeBSD.org)
Received: from out1.internal (unknown [10.202.2.149])
	by out1.messagingengine.com (Postfix) with ESMTP id 0413E96850;
	Fri, 26 Jan 2007 13:38:58 -0500 (EST)
Received: from heartbeat2.messagingengine.com ([10.202.2.161])
	by out1.internal (MEProxy); Fri, 26 Jan 2007 13:38:58 -0500
X-Sasl-enc: SOOqJi9tnDeX0j5QYuuUmH92w9/9nlEVVMvLt0zQ16kW 1169836737
Received: from [192.168.123.18]
	(82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254])
	by mail.messagingengine.com (Postfix) with ESMTP id 22485165F0;
	Fri, 26 Jan 2007 13:38:56 -0500 (EST)
Message-ID: <45BA4ABD.5040402@FreeBSD.org>
Date: Fri, 26 Jan 2007 18:38:53 +0000
From: "Bruce M. Simpson" <bms@FreeBSD.org>
User-Agent: Thunderbird 1.5.0.9 (X11/20070125)
MIME-Version: 1.0
To: Eugene Grosbein <eugen@kuzbass.ru>
References: <20070125184146.GA60481@grosbein.pp.ru>
In-Reply-To: <20070125184146.GA60481@grosbein.pp.ru>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: net@freebsd.org
Subject: Re: interface metric & quagga
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 18:39:01 -0000

Eugene Grosbein wrote:
> RTM_NEWADDR contains 'metric 0' regardless of interface metric
> value set with ifconfig before. quagga, since version 0.99.3,
> takes metric value from RTM_NEWADDR message and this value overrides
> right interface metric learned by quagga a milisecond before.
> Then it passes zero interface metric to ripd that uses interface
> metric as hop count increment for RIP-learned routes.
> This effectively breaks RIPv2 for FreeBSD (quagga-0.99.2 and older
> versions do not use metric from RTM_NEWADDR and work), perhaps RIPv1 too.
>   
It's a mixed issue.

FreeBSD does not use the interface metric, so routing daemons shouldn't 
use that field.

However, many routing implementations use a metric or distance of 0 to 
indicate a directly-connected route or interface route, so it has 
special meaning.

We could deal with this situation better by explicitly setting the 
metric to an invalid value.
If/when we implemented equal-cost multipath, or source address selection 
policies, then we should use this field.
> Verified with RELENG_4 and RELENG_6.
> Is it kernel bug or quagga bug?
>
> I also suggest to include next patch to the Ports tree
> if no objections. It restores RIP support.
>   
I'd rewrite the patch to wrap the assignment in #ifndef __FreeBSD__ so 
that it can be taken upstream more easily. If/when we do equal-cost 
multipath or source policy we can bump __FreeBSD_version.

Regards,
BMS

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 18:56:42 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 75D1E16A406
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 18:56:42 +0000 (UTC)
	(envelope-from phi@evilphi.com)
Received: from mail.twinthornes.com (mail.twinthornes.com [65.75.198.147])
	by mx1.freebsd.org (Postfix) with ESMTP id 582DF13C4A3
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 18:56:42 +0000 (UTC)
	(envelope-from phi@evilphi.com)
Received: from [10.9.70.4] (c-24-20-142-99.hsd1.or.comcast.net [24.20.142.99])
	by mail.twinthornes.com (Postfix) with ESMTP id 0810249;
	Fri, 26 Jan 2007 10:34:08 -0800 (PST)
Message-ID: <45BA499D.2060609@evilphi.com>
Date: Fri, 26 Jan 2007 10:34:05 -0800
From: Darren Pilgrim <phi@evilphi.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Eric W. Bates" <ericx@vineyard.net>
References: <45BA3083.7020006@vineyard.net>
In-Reply-To: <45BA3083.7020006@vineyard.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org
Subject: Re: About NAT Traversal
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 18:56:42 -0000

Eric W. Bates wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Can someone please refer me to some documentation describing how to
> implement NAT Traversal?

In what context?  The methods required to traverse a NAT are highly 
protocol-specific.

-- 
Darren Pilgrim

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 19:16:26 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 9E87B16A400
	for <net@freebsd.org>; Fri, 26 Jan 2007 19:16:26 +0000 (UTC)
	(envelope-from nvass@teledomenet.gr)
Received: from arwen.teledomenet.gr (arwen.teledomenet.gr [213.142.128.58])
	by mx1.freebsd.org (Postfix) with ESMTP id C732213C49D
	for <net@freebsd.org>; Fri, 26 Jan 2007 19:16:25 +0000 (UTC)
	(envelope-from nvass@teledomenet.gr)
Received: from iris ([192.168.1.71])
	by arwen.teledomenet.gr (8.12.10/8.12.10) with ESMTP id l0QBwlm1024405
	for <net@freebsd.org>; Fri, 26 Jan 2007 13:58:47 +0200
From: Nikos Vassiliadis <nvass@teledomenet.gr>
Date: Fri, 26 Jan 2007 14:01:09 +0200
User-Agent: KMail/1.9.1
MIME-Version: 1.0
Content-Disposition: inline
To: net@freebsd.org
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200701261401.09832.nvass@teledomenet.gr>
Cc: 
Subject: ng_pptpgre problems: tcp connections reset unexpectedly
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 19:16:26 -0000

Hello everybody,

 It seems that tcp connections over pptp reset unexpectedly. I have
tried several things such as connecting from a FBSD-4 to a FBSD-6,
connecting from a FBSD-[46] to a Cisco router(*). There are times which
the client box gets from the other peer an echo-request msg, which is
not supposed to happen while downloading. Perhaps it's relevant to
this:
11:31:40.887739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20702393:20703805(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.887859 IP 134.76.12.3.56123 > 213.142.137.253.64016: P 20703805:20705217(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.888005 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20705217:20706629(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.888217 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20706629:20708041(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.888352 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20708041:20709453(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.888660 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20709453:20710865(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225915>
11:31:40.888966 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20710865:20712277(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225916>

(*) the result is always the same.

What i have not tried, is a newer mpd, Alexander Motin seems to
maintain mpd very actively, he sends a patch every 5 minutes or so:)
I am using at the moment 6.2-PRE, just a  few days before RELEASE,
and mpd-3.18_4.

Could you please help? any workarounds, tunables, suggestions?
It's my connection to the internet and from time to time I need
to download something bigger than a few megs...

Thanks in advance, Nikos

root:2:~/tst1# fetch ftp://ftp2.de.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-disc1.iso; date 
6.2-RELEASE-i386-disc1.iso                      3% of  573 MB  185 kBps 50m56s
fetch: transfer timed out
fetch: 6.2-RELEASE-i386-disc1.iso appears to be truncated: 20702208/601229312 bytes
Fri Jan 26 11:31:40 EET 2007

netstat -m:
11:31:38
139/521/660 mbufs in use (current/cache/total)
65/291/356/17088 mbuf clusters in use (current/cache/total/max)
65/204 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
164K/712K/877K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/7/4528 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
2016 calls to protocol drain routines
11:31:39
141/519/660 mbufs in use (current/cache/total)
65/291/356/17088 mbuf clusters in use (current/cache/total/max)
65/204 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
165K/711K/877K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/7/4528 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
2016 calls to protocol drain routines
11:31:40
179/481/660 mbufs in use (current/cache/total)
65/291/356/17088 mbuf clusters in use (current/cache/total/max)
65/204 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
174K/702K/877K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/7/4528 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
2016 calls to protocol drain routines
11:31:41
70/590/660 mbufs in use (current/cache/total)
66/290/356/17088 mbuf clusters in use (current/cache/total/max)
66/203 mbuf+clusters out of packet secondary zone in use (current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
149K/727K/877K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/7/4528 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
2016 calls to protocol drain routines

tcpdump.ng0:
11:31:40.797285 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20695333:20696745(1412) ack 1 win 5792 <nop,nop,timestamp 50979088 694225824>
11:31:40.797294 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20696745 win 32476 <nop,nop,timestamp 694225916 50979088>
11:31:40.797697 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20696745:20698157(1412) ack 1 win 5792 <nop,nop,timestamp 50979088 694225824>
11:31:40.797780 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20698157 win 33182 <nop,nop,timestamp 694225916 50979088>
11:31:40.798589 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20698157:20699569(1412) ack 1 win 5792 <nop,nop,timestamp 50979089 694225826>
11:31:40.798739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20699569:20700981(1412) ack 1 win 5792 <nop,nop,timestamp 50979089 694225826>
11:31:40.798748 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20700981 win 32476 <nop,nop,timestamp 694225917 50979089>
11:31:40.798877 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20700981:20702393(1412) ack 1 win 5792 <nop,nop,timestamp 50979089 694225826>
11:31:40.798924 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20702393 win 33182 <nop,nop,timestamp 694225917 50979089>
11:31:40.859025 IP 213.142.137.253.64016 > 134.76.12.3.56123: R 1:1(0) ack 20702393 win 33182
11:31:40.887739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20702393:20703805(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.887859 IP 134.76.12.3.56123 > 213.142.137.253.64016: P 20703805:20705217(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.888005 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20705217:20706629(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.888217 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20706629:20708041(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.888352 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20708041:20709453(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
11:31:40.888660 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20709453:20710865(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225915>
11:31:40.888966 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20710865:20712277(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225916>
11:31:40.889120 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20712277:20713689(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225916>
11:31:40.889424 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20713689:20715101(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225916>
11:31:40.890062 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20715101:20716513(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225917>
11:31:40.890204 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20716513:20717925(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225917>
11:31:40.890488 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20717925:20719337(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225917>
11:31:40.890616 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20719337:20720749(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225917>
11:31:40.948622 IP 134.76.12.3.21 > 213.142.137.253.63090: P 3351:3387(36) ack 241 win 5792 <nop,nop,timestamp 50979104 694117118>
11:31:40.948922 IP 213.142.137.253.63090 > 134.76.12.3.21: F 241:241(0) ack 3387 win 33182 <nop,nop,timestamp 694226067 50979104>
11:31:41.038701 IP 134.76.12.3.21 > 213.142.137.253.63090: P 3387:3424(37) ack 242 win 5792 <nop,nop,timestamp 50979113 694226067>
11:31:41.038728 IP 213.142.137.253.63090 > 134.76.12.3.21: R 1015843767:1015843767(0) win 0
11:31:41.039995 IP 134.76.12.3.21 > 213.142.137.253.63090: F 3424:3424(0) ack 242 win 5792 <nop,nop,timestamp 50979113 694226067>

tcpdump.fxp0:
11:31:40.794914 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37741, ack 25863, length 24: IP [|ip]
11:31:40.795396 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.795399 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37742, ack 25863, length 24: IP [|ip]
11:31:40.795486 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25864, ack 37741, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20688273 win 32476 <nop,nop,[|tcp]>
11:31:40.795684 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.795688 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37743, ack 25863, length 24: IP [|ip]
11:31:40.795782 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25865, ack 37742, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20689685 win 33182 <nop,nop,[|tcp]>
11:31:40.795826 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.795830 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37744, ack 25863, length 24: IP [|ip]
11:31:40.795972 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.796003 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25866, ack 37744, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20692509 win 32476 <nop,nop,[|tcp]>
11:31:40.796109 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37745, ack 25863, length 24: IP [|ip]
11:31:40.796604 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.796607 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37746, ack 25865, length 24: IP [|ip]
11:31:40.796757 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25867, ack 37745, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20693921 win 33182 <nop,nop,[|tcp]>
11:31:40.796995 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.796999 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37747, ack 25865, length 24: IP [|ip]
11:31:40.797269 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.797272 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37748, ack 25866, length 24: IP [|ip]
11:31:40.797303 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25868, ack 37747, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20696745 win 32476 <nop,nop,[|tcp]>
11:31:40.797679 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.797793 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25869, ack 37748, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20698157 win 33182 <nop,nop,[|tcp]>
11:31:40.798073 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37749, ack 25868, length 24: IP [|ip]
11:31:40.798565 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.798568 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37750, ack 25868, length 24: IP [|ip]
11:31:40.798722 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.798726 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37751, ack 25868, length 24: IP [|ip]
11:31:40.798759 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25870, ack 37750, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20700981 win 32476 <nop,nop,[|tcp]>
11:31:40.798864 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.798935 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25871, ack 37751, length 72: IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20702393 win 33182 <nop,nop,[|tcp]>
11:31:40.859053 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25872, length 56: IP 213.142.137.253.64016 > 134.76.12.3.56123: R 1:1(0) ack 20702393 win 33182
11:31:40.887217 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37752, ack 25872, length 24: IP [|ip]
11:31:40.887703 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.887706 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37753, ack 25872, length 24: IP [|ip]
11:31:40.887844 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.887846 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37754, ack 25872, length 24: IP [|ip]
11:31:40.887990 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.887993 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37755, ack 25872, length 24: IP [|ip]
11:31:40.888201 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.888204 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37756, ack 25872, length 24: IP [|ip]
11:31:40.888336 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.888340 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37757, ack 25872, length 24: IP [|ip]
11:31:40.888645 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.888647 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37758, ack 25872, length 24: IP [|ip]
11:31:40.888950 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.888954 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37759, ack 25872, length 24: IP [|ip]
11:31:40.889104 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.889108 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37760, ack 25872, length 24: IP [|ip]
11:31:40.889412 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.889554 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37761, ack 25872, length 24: IP [|ip]
11:31:40.890047 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.890050 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37762, ack 25872, length 24: IP [|ip]
11:31:40.890188 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.890191 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37763, ack 25872, length 24: IP [|ip]
11:31:40.890473 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.890476 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37764, ack 25872, length 24: IP [|ip]
11:31:40.890605 IP 10.1.1.233 > 192.168.1.71: gre
11:31:40.892035 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, ack 37764, no-payload, length 12
11:31:40.948594 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37765, ack 25872, length 108: IP 134.76.12.3.21 > 213.142.137.253.63090: P 3351:3387(36) ack 241 win 5792 <nop,nop,[|tcp]>
11:31:40.948945 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25873, ack 37765, length 72: IP 213.142.137.253.63090 > 134.76.12.3.21: F 241:241(0) ack 3387 win 33182 <nop,nop,[|tcp]>
11:31:40.966187 IP6 fe80::200:b4ff:fe93:32c1 > ff02::1:ff00:193: ICMP6, neighbor solicitation, who has 2001:610:240:0:53::193, length 32
11:31:41.038668 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37766, ack 25873, length 109: IP 134.76.12.3.21 > 213.142.137.253.63090: P 3387:3424(37) ack 242 win 5792 <nop,nop,[|tcp]>
11:31:41.038747 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, seq 25874, ack 37766, length 60: IP 213.142.137.253.63090 > 134.76.12.3.21: R 1015843767:1015843767(0) win 0
11:31:41.039984 IP 10.1.1.233 > 192.168.1.71: GREv1, call 24108, seq 37767, ack 25874, length 72: IP 134.76.12.3.21 > 213.142.137.253.63090: F 3424:3424(0) ack 242 win 5792 <nop,nop,[|tcp]>
11:31:41.045027 IP 192.168.1.71 > 10.1.1.233: GREv1, call 58, ack 37767, no-payload, length 12
11:31:41.222816 802.1d config 8000.00:05:1a:b3:80:80.8018 root 8000.00:05:1a:b3:80:80 pathcost 0 age 0 max 20 hello 2 fdelay 15 

From owner-freebsd-net@FreeBSD.ORG  Fri Jan 26 23:30:51 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id CD91516A401
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 23:30:51 +0000 (UTC)
	(envelope-from bmah@freebsd.org)
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245])
	by mx1.freebsd.org (Postfix) with ESMTP id B2CD913C483
	for <freebsd-net@freebsd.org>; Fri, 26 Jan 2007 23:30:51 +0000 (UTC)
	(envelope-from bmah@freebsd.org)
Received: from [192.168.2.119] (hornet.kitchenlab.org [64.142.31.105])
	(authenticated bits=0)
	by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id
	l0QNUnNe020687
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 26 Jan 2007 15:30:50 -0800
Message-ID: <45BA8F19.70807@freebsd.org>
Date: Fri, 26 Jan 2007 15:30:33 -0800
From: "Bruce A. Mah" <bmah@freebsd.org>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?=
	<jinmei@isl.rdc.toshiba.co.jp>
References: <20070120162936.GA18104@tomcat.kitchenlab.org>	<20070121073244.GA80811@zibbi.meraka.csir.co.za>
	<y7vmz47x9e4.wl%jinmei@isl.rdc.toshiba.co.jp>
In-Reply-To: <y7vmz47x9e4.wl%jinmei@isl.rdc.toshiba.co.jp>
X-Enigmail-Version: 0.94.1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig3DB7C2120A0DC897F9361150"
Cc: freebsd-net@freebsd.org
Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2007 23:30:51 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3DB7C2120A0DC897F9361150
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If memory serves me right, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=
=93=89 wrote:
>>>>>> On Sun, 21 Jan 2007 09:32:44 +0200,=20
>>>>>> John Hay <jhay@meraka.org.za> said:
>=20
>>> There's another workaround for people stuck in this situation and who=

>>> aren't in a position to try this diff.  That is to manually install
>>> the host route like this:
>>>
>>> # route add -host -inet6 aaaa:bbbb:cccc:dddd::2 -interface gif0 -nost=
atic -llinfo
>>>
>>> Comments?
>=20
>> Well it seems that even my stuff does not always work perfectly with t=
hat
>> change (1.48.2.15), so maybe we should revert it and I will search for=

>> yet other ways to make FreeBSD's IPv6 code to actually work for our st=
uff.
>=20
>> My "stuff" is a wireless IPv6 only network running in adhoc mode with
>> olsrd as the routing protocol. The problem is that all nodes on a subn=
et
>> cannot "see" each other, so olsrd needs to add routes to a node throug=
h
>> another node. Sometimes, just to complicate matters a little more, you=

>> would want to have more than one network card in a host, all with the =
same
>> subnet address. (For instance on a high site, with sector antennas.)
>=20
>> The case that I found that still does not work reliably, is if olsrd a=
dd
>> the route and route is not immediately used, then the nd code will tim=
e
>> it out and remove it.
>=20
> I think I'm responsible for the troubles.  I've been thinking about
> how to meet all the requests, and concluded that it's more complicated
> than I originally thought.
>=20
> I've come across an idea that may solve the problems, but I'll need
> more time to implement and test it.
>=20
> At the moment, I suggest reverting the 1.48.2.16 change for those who
> simply wanted a gif to work.

Based on these comments above, I've reverted rev. 1.67, 1.68, 1.69, and
1.70 of nd.c on HEAD.  After a bunch more testing I've convinced myself
that I think this will solve the problems that we have been seeing, and
possibly why some other people's testing yielded counter-intitive
results.  I'll MFC to STABLE in 3 days.

Commit message below...

Bruce

-----

bmah        2007-01-26 23:22:58 UTC

  FreeBSD src repository

  Modified files:
    sys/netinet6         nd6.c
  Log:
  Revert nd6.c revs. 1.67, 1.68, 1.69, 1.70 in an attempt to unbreak
  IPv6 over point-to-point gif(4) tunnels.

  These revisions caused a host route to the destination of a
  point-to-point gif(4) interface to not get installed when the interface=

  and destination addresses were assigned.  This caused
  "no route to host" errors when trying to send traffic over the
  interface.  The first packet arriving inbound over the tunnel,
  however, would cause the correct route to get installed, allowing
  subsequent outbound traffic to be routed correctly.

  gif(4) interfaces with prefix lengths of less than 128 bits
  (i.e. no explicit destination address assigned) were not affected
  by this bug.

  This bug fix is a possible candidate for a 6.2-RELEASE errata note.

  Approved by:    jhay (original committer)
  Discussed with: jhay, JINMEI Tatuya
  MFC after:      3 days

  Revision  Changes    Path
  1.74      +1 -1      src/sys/netinet6/nd6.c



--------------enig3DB7C2120A0DC897F9361150
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFuo8f2MoxcVugUsMRAs0oAJ9zFL6y0GM0cv4pspAM2evTl0lzJACfXpR0
BieEAS33m9kJadCEd048LsQ=
=eLoT
-----END PGP SIGNATURE-----

--------------enig3DB7C2120A0DC897F9361150--

From owner-freebsd-net@FreeBSD.ORG  Sat Jan 27 03:50:18 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@freebsd.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 3E71816A4A6
	for <net@freebsd.org>; Sat, 27 Jan 2007 03:50:18 +0000 (UTC)
	(envelope-from mav@alkar.net)
Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121])
	by mx1.freebsd.org (Postfix) with ESMTP id 0C99E13C48D
	for <net@freebsd.org>; Sat, 27 Jan 2007 03:50:16 +0000 (UTC)
	(envelope-from mav@alkar.net)
Received: from [195.248.178.122] (account mav@alkar.net HELO [192.168.3.2])
	by cmail.optima.ua (CommuniGate Pro SMTP 5.0.11)
	with ESMTPA id 20211520; Sat, 27 Jan 2007 04:50:15 +0200
Message-ID: <45BABDE2.4010503@alkar.net>
Date: Sat, 27 Jan 2007 04:50:10 +0200
From: Alexander Motin <mav@alkar.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.13) Gecko/20060414
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nikos Vassiliadis <nvass@teledomenet.gr>
References: <1169850194.00677461.1169839202@10.7.7.3>
In-Reply-To: <1169850194.00677461.1169839202@10.7.7.3>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: net@freebsd.org
Subject: Re: ng_pptpgre problems: tcp connections reset unexpectedly
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jan 2007 03:50:18 -0000

Hi.

Nikos Vassiliadis wrote:
>  It seems that tcp connections over pptp reset unexpectedly. I have
> tried several things such as connecting from a FBSD-4 to a FBSD-6,
> connecting from a FBSD-[46] to a Cisco router(*). There are times which
> the client box gets from the other peer an echo-request msg, which is
> not supposed to happen while downloading. Perhaps it's relevant to
> this:
> 
> (*) the result is always the same.
> 
> What i have not tried, is a newer mpd, Alexander Motin seems to
> maintain mpd very actively, he sends a patch every 5 minutes or so:)
> I am using at the moment 6.2-PRE, just a  few days before RELEASE,
> and mpd-3.18_4.

Actually I have spent so much time working on mpd4 that I dont like to 
even hear about some problems in ancient mpd3. :) There so much work was 
done in mpd4 that it is mostly pointless to debug something in mpd3.

> Could you please help? any workarounds, tunables, suggestions?
> It's my connection to the internet and from time to time I need
> to download something bigger than a few megs...

I do not use pptp actively, to say for sure, but you can try to play 
with such pptp options like delayed-ack, always-ack and windowing.

> Thanks in advance, Nikos
> 
> root:2:~/tst1# fetch ftp://ftp2.de.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-disc1.iso; date 
> 6.2-RELEASE-i386-disc1.iso                      3% of  573 MB  185 kBps 50m56s
> fetch: transfer timed out
> fetch: 6.2-RELEASE-i386-disc1.iso appears to be truncated: 20702208/601229312 bytes
> Fri Jan 26 11:31:40 EET 2007

> tcpdump.ng0:
> 11:31:40.797285 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20695333:20696745(1412) ack 1 win 5792 <nop,nop,timestamp 50979088 694225824>
> 11:31:40.797294 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20696745 win 32476 <nop,nop,timestamp 694225916 50979088>
> 11:31:40.797697 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20696745:20698157(1412) ack 1 win 5792 <nop,nop,timestamp 50979088 694225824>
> 11:31:40.797780 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20698157 win 33182 <nop,nop,timestamp 694225916 50979088>
> 11:31:40.798589 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20698157:20699569(1412) ack 1 win 5792 <nop,nop,timestamp 50979089 694225826>
> 11:31:40.798739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20699569:20700981(1412) ack 1 win 5792 <nop,nop,timestamp 50979089 694225826>
> 11:31:40.798748 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20700981 win 32476 <nop,nop,timestamp 694225917 50979089>
> 11:31:40.798877 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20700981:20702393(1412) ack 1 win 5792 <nop,nop,timestamp 50979089 694225826>
> 11:31:40.798924 IP 213.142.137.253.64016 > 134.76.12.3.56123: . ack 20702393 win 33182 <nop,nop,timestamp 694225917 50979089>
> 11:31:40.859025 IP 213.142.137.253.64016 > 134.76.12.3.56123: R 1:1(0) ack 20702393 win 33182
> 11:31:40.887739 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20702393:20703805(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
> 11:31:40.887859 IP 134.76.12.3.56123 > 213.142.137.253.64016: P 20703805:20705217(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>
> 11:31:40.888005 IP 134.76.12.3.56123 > 213.142.137.253.64016: . 20705217:20706629(1412) ack 1 win 5792 <nop,nop,timestamp 50979098 694225914>

Looking here I can see that it is your local machine (213.142.137.253) 
sent "R" - Reset request just after normal acknowledge packet. I don't 
see the reason for such it's behaviour. Is it the same machine where 
fetch and tcpdump running? Wasn't there some kind of time 
synchronization or NAT restart or some other external event?

-- 
Alexander Motin mav@alkar.net
Optima Telecom

From owner-freebsd-net@FreeBSD.ORG  Sat Jan 27 05:09:02 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id EE2F416A402
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 05:09:02 +0000 (UTC)
	(envelope-from ashoke@rocketmail.com)
Received: from web51907.mail.yahoo.com (web51907.mail.yahoo.com
	[206.190.48.70])
	by mx1.freebsd.org (Postfix) with SMTP id 8A34B13C484
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 05:09:00 +0000 (UTC)
	(envelope-from ashoke@rocketmail.com)
Received: (qmail 28519 invoked by uid 60001); 27 Jan 2007 05:08:59 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com;
	h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
	b=M71J1waxAS5L99kL2PabkmHDinYxKICsieH8YxqOUUkaS3AEsgoqTiZ7fAxlW3cTcvtR8G4v23FxkG/TnFWYAT7MnAqHx070ahN6R1BStZ5DhMxpFlauqafBqkyt1d0KcOWXKU5GQr88BbFMb+rx9biLAjGRuDoRLqP0heiHAeU=;
X-YMail-OSG: JYPcR7IVM1lPxS7vxxG7g3vddAsktfwAxeQ3SKw9Cdv1N4xwN_3ny8e3oIIWGM6tXQ--
Received: from [61.2.178.73] by web51907.mail.yahoo.com via HTTP;
	Fri, 26 Jan 2007 21:08:59 PST
Date: Fri, 26 Jan 2007 21:08:59 -0800 (PST)
From: ashoke saha <ashoke@rocketmail.com>
To: Darren Pilgrim <phi@evilphi.com>, "Eric W. Bates" <ericx@vineyard.net>
In-Reply-To: <45BA499D.2060609@evilphi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <816104.21070.qm@web51907.mail.yahoo.com>
Cc: freebsd-net@freebsd.org
Subject: Re: About NAT Traversal
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jan 2007 05:09:03 -0000

basic kame (racoon) as NAT_T for IKE. It did not have
kernel support till 6.0. you can take the patch from
there. 
also NAT_T has moved from draft to RFC and do google
for NAT_T  to get get the RFC's and also read the code
in the kernel patch and racoon.

assuming you are talking about ipsec NAT_T.

ashoke.

--- Darren Pilgrim <phi@evilphi.com> wrote:

> Eric W. Bates wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Can someone please refer me to some documentation
> describing how to
> > implement NAT Traversal?
> 
> In what context?  The methods required to traverse a
> NAT are highly 
> protocol-specific.
> 
> -- 
> Darren Pilgrim
> _______________________________________________
> freebsd-net@freebsd.org mailing list
>
http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to
> "freebsd-net-unsubscribe@freebsd.org"
> 



 
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121

From owner-freebsd-net@FreeBSD.ORG  Sat Jan 27 10:08:06 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: net@FreeBSD.org
Delivered-To: freebsd-net@FreeBSD.ORG
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 0F09D16A400;
	Sat, 27 Jan 2007 10:08:06 +0000 (UTC)
	(envelope-from eugen@www.svzserv.kemerovo.su)
Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su
	[213.184.65.80])
	by mx1.freebsd.org (Postfix) with ESMTP id 7294413C46C;
	Sat, 27 Jan 2007 10:08:05 +0000 (UTC)
	(envelope-from eugen@www.svzserv.kemerovo.su)
Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1])
	by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l0R9mTck020817;
	Sat, 27 Jan 2007 16:48:29 +0700 (KRAT)
	(envelope-from eugen@www.svzserv.kemerovo.su)
Received: (from eugen@localhost)
	by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l0R9mTPp020814;
	Sat, 27 Jan 2007 16:48:29 +0700 (KRAT) (envelope-from eugen)
Date: Sat, 27 Jan 2007 16:48:29 +0700
From: Eugene Grosbein <eugen@www.svzserv.kemerovo.su>
To: "Bruce M. Simpson" <bms@FreeBSD.org>
Message-ID: <20070127094829.GA20381@svzserv.kemerovo.su>
References: <20070125184146.GA60481@grosbein.pp.ru>
	<45BA4ABD.5040402@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45BA4ABD.5040402@FreeBSD.org>
User-Agent: Mutt/1.4.2.1i
Cc: net@FreeBSD.org
Subject: Re: interface metric & quagga
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jan 2007 10:08:06 -0000

On Fri, Jan 26, 2007 at 06:38:53PM +0000, Bruce M. Simpson wrote:

> >RTM_NEWADDR contains 'metric 0' regardless of interface metric
> >value set with ifconfig before. quagga, since version 0.99.3,
> >takes metric value from RTM_NEWADDR message and this value overrides
> >right interface metric learned by quagga a milisecond before.
> >Then it passes zero interface metric to ripd that uses interface
> >metric as hop count increment for RIP-learned routes.
> >This effectively breaks RIPv2 for FreeBSD (quagga-0.99.2 and older
> >versions do not use metric from RTM_NEWADDR and work), perhaps RIPv1 too.

> It's a mixed issue.
> 
> FreeBSD does not use the interface metric, so routing daemons shouldn't 
> use that field.
> 
> However, many routing implementations use a metric or distance of 0 to 
> indicate a directly-connected route or interface route, so it has 
> special meaning.
> 
> We could deal with this situation better by explicitly setting the 
> metric to an invalid value.

Quagga checks if metric is zero and changes zero to one for itself
in first place. Sadly, it does not perform such sanity check
in second place, when it processes RTM_NEWADDR.

> If/when we implemented equal-cost multipath, or source address selection 
> policies, then we should use this field.
> >Verified with RELENG_4 and RELENG_6.
> >Is it kernel bug or quagga bug?
> >
> >I also suggest to include next patch to the Ports tree
> >if no objections. It restores RIP support.
> >  
> I'd rewrite the patch to wrap the assignment in #ifndef __FreeBSD__ so 
> that it can be taken upstream more easily. If/when we do equal-cost 
> multipath or source policy we can bump __FreeBSD_version.

Here is version that does not need #ifndef __FreeBSD__
Now (ifam->ifam_metric) is always zero for all FreeBSD versions.

--- zebra/kernel_socket.c.orig	Fri Jan 26 10:55:03 2007
+++ zebra/kernel_socket.c	Fri Jan 26 10:55:35 2007
@@ -585,6 +585,7 @@
   if (ifnlen && strncmp (ifp->name, ifname, INTERFACE_NAMSIZ))
     isalias = 1;
   
+  if (ifam->ifam_metric)
   ifp->metric = ifam->ifam_metric;
   
   /* Add connected address. */

I currently run this patch in production for relatively large RIPv2 network
of FreeBSD routers (versions 4.11 and 6.x).

Eugene Grosbein

From owner-freebsd-net@FreeBSD.ORG  Sat Jan 27 14:31:50 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 41C7416A403
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 14:31:50 +0000 (UTC)
	(envelope-from antinvidia@gmail.com)
Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179])
	by mx1.freebsd.org (Postfix) with ESMTP id 023F013C481
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 14:31:49 +0000 (UTC)
	(envelope-from antinvidia@gmail.com)
Received: by py-out-1112.google.com with SMTP id f47so505537pye
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 06:31:49 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=Zm1miee6Y8rDKZcyOWud5cmfQyryMyVm/u4WBxgGrxjenlrJwhfaMkMRnRZ1L72nbzxu4LrBPVgD01Ob+VEJFOmXeg4q+JG3SqC19hrZnJcU/aatH/WKIx/kMNhALS2dv9mp9mIkMOVClCNodIocnzJmvS9vLlJmbQAQQiLJ2Zs=
Received: by 10.35.80.20 with SMTP id h20mr8344393pyl.1169908309285;
	Sat, 27 Jan 2007 06:31:49 -0800 (PST)
Received: by 10.35.60.19 with HTTP; Sat, 27 Jan 2007 06:31:49 -0800 (PST)
Message-ID: <be0088ce0701270631j4b5b0a09u3ca2da75563ad0b2@mail.gmail.com>
Date: Sat, 27 Jan 2007 14:31:49 +0000
From: MQ <antinvidia@gmail.com>
To: Wishmaster <wishmaster@velnet.ru>
In-Reply-To: <1582899958.20070126014728@velnet.ru>
MIME-Version: 1.0
References: <1458229821.20070120234257@velnet.ru>
	<45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru>
	<be0088ce0701220431tf96827et3713885fac8a490a@mail.gmail.com>
	<45B4BE90.20602@qwirky.net> <1582899958.20070126014728@velnet.ru>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: freebsd-net@freebsd.org
Subject: Re: Re[2]: reproducible watchdog timeout in bge
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jan 2007 14:31:50 -0000

2007/1/25, Wishmaster <wishmaster@velnet.ru>:
>
> Hello Jeff,
>
> Monday, January 22, 2007, 4:39:28 PM, you wrote:
>
>
> JR> I have been unable to produce time outs with my current setup in
> JR> 6.2-Release.
>
> JR> bge0@pci3:0:0:  class=0x020000 card=0x81491043 chip=0x165914e4
> rev=0x11
> JR> hdr=0x00
> JR>      vendor   = 'Broadcom Corporation'
> JR>      device   = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
> JR>      class    = network
> JR>      subclass = ethernet
>
> JR> Reading the PR, I attempted triggering this through CVSing and through
> JR> the above mentioned ping tests.
>
> JR> So far nothing.
>
> JR> The only issue I have seen using these NICs in 6.2R is if I nail up
> the
> JR> NIC at 100baseTX full-duplex I sometimes loose connectivity.  Nothing
> JR> in the logs indicate watchdog timeouts or any other issue.   I simply
> JR> brought the NIC back down to auto-neg and all seems fine.   I am
> JR> assuming this is a incompatibility between the BGE and my switch,
> RS8000.
>
> JR> I have a Asus P5MT-S with dual BGE NIC's
>
> JR> Cheers,
>
> JR> Jeff
> JR> _______________________________________________
> JR> freebsd-net@freebsd.org mailing list
> JR> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> JR> To unsubscribe, send any mail to
> JR> "freebsd-net-unsubscribe@freebsd.org"
>
>
> pciconf says:
> bge0@pci3:0:0:  class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x21
> hdr=0x00
>     vendor   = 'Broadcom Corporation'
>     device   = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
>     class    = network
>     subclass = ethernet
> bge1@pci4:0:0:  class=0x020000 card=0x81491043 chip=0x165914e4 rev=0x21
> hdr=0x00
>     vendor   = 'Broadcom Corporation'
>     device   = 'BCM5750A1 NetXtreme Gigabit Ethernet PCI Express'
>     class    = network
>     subclass = ethernet
>
> So, if you have no troubles can you tell do you have smp kernel with
> apic and what distribution you are using?
>
> On my configuration I have dual core intel xeon 30xx series  with
> SMP and APIC kernel (i386 distribution). This issue appears just after
> system boots up.
>
> If you have non-smp kernel can you try to recompile it with smp and
> apic support?
>
> p.s. motherboard asus p5m2/2gbl
>
> --
> Best regards,
> Wishmaster                            mailto:wishmaster-velnet@yandex.ru
>
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>


I have two boxes with onboard bge, one using 5780, the other 5701. Neither
of them has your problem. I think there may be some problems with your
software or hardware configuration.

From owner-freebsd-net@FreeBSD.ORG  Sat Jan 27 14:50:27 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id E264916A402
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 14:50:27 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from mail.velnet.ru (mail.velnet.ru [88.210.53.179])
	by mx1.freebsd.org (Postfix) with ESMTP id 9E1C213C48C
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 14:50:27 +0000 (UTC)
	(envelope-from wishmaster@velnet.ru)
Received: from [213.141.131.138] (helo=localhost)
	by mail.velnet.ru with esmtp (Exim 4.30; FreeBSD) id 1HAoyQ-000E4q-Qo
	for freebsd-net@freebsd.org; Sat, 27 Jan 2007 17:56:10 +0300
Date: Sat, 27 Jan 2007 17:51:57 +0300
From: Wishmaster <wishmaster@velnet.ru>
X-Mailer: The Bat! (v2.12.00)
X-Priority: 3 (Normal)
Message-ID: <194684269.20070127175157@velnet.ru>
To: freebsd-net@freebsd.org
In-Reply-To: <be0088ce0701270631j4b5b0a09u3ca2da75563ad0b2@mail.gmail.com>
References: <1458229821.20070120234257@velnet.ru>
	<45B28F37.7040100@delphij.net> <1651695163.20070122010957@velnet.ru>
	<be0088ce0701220431tf96827et3713885fac8a490a@mail.gmail.com>
	<45B4BE90.20602@qwirky.net> <1582899958.20070126014728@velnet.ru>
	<be0088ce0701270631j4b5b0a09u3ca2da75563ad0b2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re[4]: reproducible watchdog timeout in bge
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Wishmaster <wishmaster@velnet.ru>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jan 2007 14:50:28 -0000

Hello MQ,

Saturday, January 27, 2007, 5:31:49 PM, you wrote:

M> I have two boxes with onboard bge, one using 5780, the other
M> 5701. Neither of them has your problem. I think there may be some
M> problems with your software or hardware configuration.


I don't think so. I have two different motherboards and two
different freebsd distributions on them (6.1/amd64 and 6.2/i386). On both motherboards there
are bcm5721 onboard network chips and both configurations have the
same issue.

Can you tell me do you have smp kernel?

p.s.  On both machines I have clear installation of freebsd. i.e.
there is nothing except SMP in my kernel.
-- 
Best regards,
 Wishmaster                            mailto:wishmaster@velnet.ru



From owner-freebsd-net@FreeBSD.ORG  Sat Jan 27 16:40:04 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 1028D16A401
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 16:40:04 +0000 (UTC)
	(envelope-from antonio.tommasi@unile.it)
Received: from cabis.unile.it (cabis.unile.it [212.189.128.35])
	by mx1.freebsd.org (Postfix) with ESMTP id B6D6313C4A3
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 16:40:03 +0000 (UTC)
	(envelope-from antonio.tommasi@unile.it)
Received: from localhost (cabis [127.0.0.1])
	by cabis.unile.it (Postfix) with ESMTP id 4E32C22AF0C
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 17:20:49 +0100 (CET)
X-Virus-Scanned: virus/spam checker at unile.it
Received: from cabis.unile.it ([127.0.0.1])
	by localhost (cabis.unile.it [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vxKW7c1zbCfk for <freebsd-net@freebsd.org>;
	Sat, 27 Jan 2007 17:20:49 +0100 (CET)
Received: from webmail.ilenic.unile.it (webmail.ilenic.unile.it
	[212.189.128.42])
	by cabis.unile.it (Postfix) with ESMTP id F3B0622AED8
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 17:20:48 +0100 (CET)
Received: from 151.50.247.45 (SquirrelMail authenticated user atommasi)
	by webmail.ilenic.unile.it with HTTP;
	Sat, 27 Jan 2007 17:20:49 +0100 (CET)
Message-ID: <10239.151.50.247.45.1169914849.squirrel@webmail.ilenic.unile.it>
Date: Sat, 27 Jan 2007 17:20:49 +0100 (CET)
From: antonio.tommasi@unile.it
To: freebsd-net@freebsd.org
User-Agent: SquirrelMail/1.4.6 [CVS]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: Filtering Bridge Traffic on layer IP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jan 2007 16:40:04 -0000

Hi to all,
i've configured a freebsd box bridge. This machine have 2 ethernet card
and i configure them with one ip address. I also configure firewalling
with ipfw on this box.
Is there a possibility to filter bridged traffic with ipfw on layer IP?
I need to allow some machine with some ip to access to internet and the
other not.
I cannot implemet nat-firewalling because i need to not change actual ip
configuration on my lan.
Have you any suggestion?
Thanks in advance
Antonio


From owner-freebsd-net@FreeBSD.ORG  Sat Jan 27 16:52:02 2007
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
X-Original-To: freebsd-net@freebsd.org
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 3DAEC16A400
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 16:52:02 +0000 (UTC)
	(envelope-from rizzo@icir.org)
Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68])
	by mx1.freebsd.org (Postfix) with ESMTP id 2AB3613C46C
	for <freebsd-net@freebsd.org>; Sat, 27 Jan 2007 16:52:02 +0000 (UTC)
	(envelope-from rizzo@icir.org)
Received: from xorpc.icir.org (localhost [127.0.0.1])
	by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l0RGq1rH001881;
	Sat, 27 Jan 2007 08:52:01 -0800 (PST)
	(envelope-from rizzo@xorpc.icir.org)
Received: (from rizzo@localhost)
	by xorpc.icir.org (8.12.11/8.12.3/Submit) id l0RGq11H001880;
	Sat, 27 Jan 2007 08:52:01 -0800 (PST) (envelope-from rizzo)
Date: Sat, 27 Jan 2007 08:52:01 -0800
From: Luigi Rizzo <rizzo@icir.org>
To: antonio.tommasi@unile.it
Message-ID: <20070127085201.A1868@xorpc.icir.org>
References: <10239.151.50.247.45.1169914849.squirrel@webmail.ilenic.unile.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <10239.151.50.247.45.1169914849.squirrel@webmail.ilenic.unile.it>;
	from antonio.tommasi@unile.it on Sat, Jan 27, 2007 at 05:20:49PM +0100
Cc: freebsd-net@freebsd.org
Subject: Re: Filtering Bridge Traffic on layer IP
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jan 2007 16:52:02 -0000

On Sat, Jan 27, 2007 at 05:20:49PM +0100, antonio.tommasi@unile.it wrote:
> Hi to all,
> i've configured a freebsd box bridge. This machine have 2 ethernet card
> and i configure them with one ip address. I also configure firewalling
> with ipfw on this box.
> Is there a possibility to filter bridged traffic with ipfw on layer IP?

guarda http://info.iet.unipi.it/~luigi/ip_dummynet/

ciao
luigi

> I need to allow some machine with some ip to access to internet and the
> other not.
> I cannot implemet nat-firewalling because i need to not change actual ip
> configuration on my lan.
> Have you any suggestion?
> Thanks in advance
> Antonio
> 
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"