From dfilter at FreeBSD.ORG  Wed Jul  1 08:10:03 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Wed Jul  1 08:10:08 2009
Subject: kern/134557: commit references a PR
Message-ID: <200907010810.n618A24m007017@freefall.freebsd.org>

The following reply was made to PR kern/134557; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/134557: commit references a PR
Date: Wed,  1 Jul 2009 08:09:10 +0000 (UTC)

 Author: mav
 Date: Wed Jul  1 08:08:56 2009
 New Revision: 195231
 URL: http://svn.freebsd.org/changeset/base/195231
 
 Log:
   Fix infinite loop in ng_iface, that happens when packet passes out via
   two different ng interfaces sequentially due to tunnelling.
   
   PR:		kern/134557
   Submitted by:	Mikolaj Golub
   Approved by:	re (kensmith)
   MFC after:	3 days
 
 Modified:
   head/sys/netgraph/ng_iface.c
 
 Modified: head/sys/netgraph/ng_iface.c
 ==============================================================================
 --- head/sys/netgraph/ng_iface.c	Wed Jul  1 07:37:21 2009	(r195230)
 +++ head/sys/netgraph/ng_iface.c	Wed Jul  1 08:08:56 2009	(r195231)
 @@ -382,7 +382,8 @@ ng_iface_output(struct ifnet *ifp, struc
  	}
  
  	/* Protect from deadly infinite recursion. */
 -	while ((mtag = m_tag_locate(m, MTAG_NGIF, MTAG_NGIF_CALLED, NULL))) {
 +	mtag = NULL;
 +	while ((mtag = m_tag_locate(m, MTAG_NGIF, MTAG_NGIF_CALLED, mtag))) {
  		if (*(struct ifnet **)(mtag + 1) == ifp) {
  			log(LOG_NOTICE, "Loop detected on %s\n", ifp->if_xname);
  			m_freem(m);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From dudu at dudu.ro  Wed Jul  1 09:35:36 2009
From: dudu at dudu.ro (Vlad Galu)
Date: Wed Jul  1 09:35:43 2009
Subject: Is there a chance to declare the prototype for setfib() somewhere
	in a system header?
Message-ID: <ad79ad6b0907010206x4c7833b7r508fb725fccc35b8@mail.gmail.com>

Right now, to be able to compile with g++ (not gcc), I have to declare
it in a "extern <<C>>" scope.
From pluknet at gmail.com  Wed Jul  1 09:57:56 2009
From: pluknet at gmail.com (pluknet)
Date: Wed Jul  1 09:58:06 2009
Subject: Is there a chance to declare the prototype for setfib()
	somewhere in a system header?
In-Reply-To: <ad79ad6b0907010206x4c7833b7r508fb725fccc35b8@mail.gmail.com>
References: <ad79ad6b0907010206x4c7833b7r508fb725fccc35b8@mail.gmail.com>
Message-ID: <a31046fc0907010257v5a1f5161pa027eb70d1d6a839@mail.gmail.com>

2009/7/1 Vlad Galu <dudu@dudu.ro>:
> Right now, to be able to compile with g++ (not gcc), I have to declare
> it in a "extern <<C>>" scope.


setfib() is declared in -current only in sys/socket.h (r1.102).

Can some please correct setfib(2) manpage?

--- lib/libc/sys/setfib.2.orig  2009-07-01 13:50:07.000000000 +0400
+++ lib/libc/sys/setfib.2       2009-07-01 13:50:22.000000000 +0400
@@ -33,6 +33,7 @@
 .Sh LIBRARY
 .Lb libc
 .Sh SYNOPSIS
+.In sys/socket.h
 .Ft int
 .Fn setfib "int fib"
 .Sh DESCRIPTION

-- 
wbr,
pluknet
From dudu at dudu.ro  Wed Jul  1 10:04:45 2009
From: dudu at dudu.ro (Vlad Galu)
Date: Wed Jul  1 10:04:52 2009
Subject: Is there a chance to declare the prototype for setfib()
	somewhere in a system header?
In-Reply-To: <a31046fc0907010257v5a1f5161pa027eb70d1d6a839@mail.gmail.com>
References: <ad79ad6b0907010206x4c7833b7r508fb725fccc35b8@mail.gmail.com> 
	<a31046fc0907010257v5a1f5161pa027eb70d1d6a839@mail.gmail.com>
Message-ID: <ad79ad6b0907010304y7de4d8dax399af87c7436a0fd@mail.gmail.com>

On Wed, Jul 1, 2009 at 12:57 PM, pluknet<pluknet@gmail.com> wrote:
> 2009/7/1 Vlad Galu <dudu@dudu.ro>:
>> Right now, to be able to compile with g++ (not gcc), I have to declare
>> it in a "extern <<C>>" scope.
>
>
> setfib() is declared in -current only in sys/socket.h (r1.102).
>
> Can some please correct setfib(2) manpage?
>
> --- lib/libc/sys/setfib.2.orig ?2009-07-01 13:50:07.000000000 +0400
> +++ lib/libc/sys/setfib.2 ? ? ? 2009-07-01 13:50:22.000000000 +0400
> @@ -33,6 +33,7 @@
> ?.Sh LIBRARY
> ?.Lb libc
> ?.Sh SYNOPSIS
> +.In sys/socket.h
> ?.Ft int
> ?.Fn setfib "int fib"
> ?.Sh DESCRIPTION
>
> --
> wbr,
> pluknet
>

It would be great if the change to socket.h could be MFCed :) Thanks!
From dudu at dudu.ro  Wed Jul  1 12:33:16 2009
From: dudu at dudu.ro (Vlad Galu)
Date: Wed Jul  1 12:33:29 2009
Subject: Is there a chance to declare the prototype for setfib()
	somewhere in a system header?
In-Reply-To: <ad79ad6b0907010304y7de4d8dax399af87c7436a0fd@mail.gmail.com>
References: <ad79ad6b0907010206x4c7833b7r508fb725fccc35b8@mail.gmail.com> 
	<a31046fc0907010257v5a1f5161pa027eb70d1d6a839@mail.gmail.com> 
	<ad79ad6b0907010304y7de4d8dax399af87c7436a0fd@mail.gmail.com>
Message-ID: <ad79ad6b0907010532g78032f18yeb0823f9ef9db26f@mail.gmail.com>

On Wed, Jul 1, 2009 at 1:04 PM, Vlad Galu<dudu@dudu.ro> wrote:
> On Wed, Jul 1, 2009 at 12:57 PM, pluknet<pluknet@gmail.com> wrote:
>> 2009/7/1 Vlad Galu <dudu@dudu.ro>:
>>> Right now, to be able to compile with g++ (not gcc), I have to declare
>>> it in a "extern <<C>>" scope.
>>
>>
>> setfib() is declared in -current only in sys/socket.h (r1.102).
>>
>> Can some please correct setfib(2) manpage?
>>
>> --- lib/libc/sys/setfib.2.orig ?2009-07-01 13:50:07.000000000 +0400
>> +++ lib/libc/sys/setfib.2 ? ? ? 2009-07-01 13:50:22.000000000 +0400
>> @@ -33,6 +33,7 @@
>> ?.Sh LIBRARY
>> ?.Lb libc
>> ?.Sh SYNOPSIS
>> +.In sys/socket.h
>> ?.Ft int
>> ?.Fn setfib "int fib"
>> ?.Sh DESCRIPTION
>>
>> --
>> wbr,
>> pluknet
>>
>
> It would be great if the change to socket.h could be MFCed :) Thanks!
>

I've submitted a PR, filed as misc/136216.
From ddeineka at gmail.com  Wed Jul  1 13:20:05 2009
From: ddeineka at gmail.com (Dmitry A.Deineka)
Date: Wed Jul  1 13:20:11 2009
Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) --
 recovering
Message-ID: <200907011320.n61DK4rs056957@freefall.freebsd.org>

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: "Dmitry A.Deineka" <ddeineka@gmail.com>
To: bug-followup@freebsd.org
Cc: Pyun YongHyeon <pyunyh@gmail.com>
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) --
 recovering
Date: Wed, 01 Jul 2009 15:59:22 +0300

 Hi,
 
 have same problem, motherboard Asus P5K-VM with marvell yukon onboard:
 mskc0: <Marvell Yukon 88E8056 Gigabit Ethernet> port 0xd800-0xd8ff mem 
 0xfeafc000-0xfeafffff irq 17 at device 0.0 on pci1
 msk0: <Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x03> on 
 mskc0
 msk0: Ethernet address: 00:1e:8c:5e:f8:92
 
 
 Problem confirmed with FreeBSD 7.x, now installed 8.0-CURRENT-200906 
 with the same problem (and the same msk driver, as I see in source).
 
 Patch from Pyun YongHyeon in this PR applied, but it not fix problem. 
 Downloading large file by ftp from another server causes following:
 
 Jul  1 15:43:58 msktest kernel: msk0: watchdog timeout
 Jul  1 15:43:58 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:44:00 msktest kernel: msk0: link state changed to UP
 Jul  1 15:44:38 msktest kernel: msk0: watchdog timeout
 Jul  1 15:44:38 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:44:40 msktest kernel: msk0: link state changed to UP
 Jul  1 15:45:03 msktest kernel: msk0: watchdog timeout
 Jul  1 15:45:03 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:45:05 msktest kernel: msk0: link state changed to UP
 Jul  1 15:45:28 msktest kernel: msk0: watchdog timeout
 Jul  1 15:45:28 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:45:30 msktest kernel: msk0: link state changed to UP
 Jul  1 15:46:07 msktest kernel: msk0: watchdog timeout
 Jul  1 15:46:07 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:46:09 msktest kernel: msk0: link state changed to UP
 Jul  1 15:46:24 msktest kernel: msk0: watchdog timeout
 Jul  1 15:46:24 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:46:26 msktest kernel: msk0: link state changed to UP
 Jul  1 15:47:07 msktest kernel: msk0: watchdog timeout
 Jul  1 15:47:07 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:47:09 msktest kernel: msk0: link state changed to UP
 Jul  1 15:48:33 msktest kernel: msk0: watchdog timeout
 Jul  1 15:48:33 msktest kernel: msk0: link state changed to DOWN
 Jul  1 15:48:35 msktest kernel: msk0: link state changed to UP
 
 
 Hope this helps.
 
 With best regards,
    Dmitry
From bohdan200 at gmail.com  Thu Jul  2 07:22:21 2009
From: bohdan200 at gmail.com (Bohdan Tymkiv)
Date: Thu Jul  2 07:22:53 2009
Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - 
	ng_pptp problem
In-Reply-To: <200906301940.n5UJe2l3096572@freefall.freebsd.org>
References: <200906301940.n5UJe2l3096572@freefall.freebsd.org>
Message-ID: <9ce5b0ed0907020022n14af930du1127acb35bc14cc0@mail.gmail.com>

Hello Mikolaj,

I confirm that this patch fixes the issue.
Thank you very much! Now pptp through pppoe works fine!

Bohdan Tymkiv

On Tue, Jun 30, 2009 at 10:40 PM, Mikolaj Golub<to.my.trociny@gmail.com> wrote:
> The following reply was made to PR kern/134557; it has been noted by GNATS.
>
> From: Mikolaj Golub <to.my.trociny@gmail.com>
> To: bug-followup@FreeBSD.org
> Cc: freebsd-net@FreeBSD.org, Sergei Cherveni <sergei.cherveni@gmail.com>, Alexander Motin <mav@FreeBSD.org>
> Subject: Re: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem
> Date: Tue, 30 Jun 2009 22:33:12 +0300
>
> ?--=-=-=
>
> ?Unfortunately, the problem was introduced by this commit :-)
>
> ?----------
>
> ?Author: ? ? ? ?mav
> ?Date: ?Sat Jan 31 12:48:09 2009 UTC (4 months, 4 weeks ago)
> ?Log Message:
>
> ?MFC rev. 187495
>
> ?Check for infinite recursion possible on some broken PPTP/L2TP/... VPN setups.
> ?Mark packets with mbuf_tag on first interface passage and drop on second.
>
> ?PR: ? ? ? ? ? ?ports/129625, ports/125303
>
> ?----------
>
> ?If a packet goes through two or more ng interfaces, "while" loop in the tag
> ?checking code can run infinitely. The attached patch should fix this.
>
> ?--
> ?Mikolaj Golub
>
>
> ?--=-=-=
> ?Content-Type: text/x-diff
> ?Content-Disposition: attachment; filename=ng_iface.c.patch
>
> ?--- netgraph/ng_iface.c.orig ? 2009-06-30 21:47:54.000000000 +0300
> ?+++ netgraph/ng_iface.c ? ? ? ?2009-06-30 21:49:29.000000000 +0300
> ?@@ -365,7 +365,8 @@
> ? ? ? ?}
>
> ? ? ? ?/* Protect from deadly infinite recursion. */
> ?- ? ? ?while ((mtag = m_tag_locate(m, MTAG_NGIF, MTAG_NGIF_CALLED, NULL))) {
> ?+ ? ? ?mtag = NULL;
> ?+ ? ? ?while ((mtag = m_tag_locate(m, MTAG_NGIF, MTAG_NGIF_CALLED, mtag))) {
> ? ? ? ? ? ? ? ?if (*(struct ifnet **)(mtag + 1) == ifp) {
> ? ? ? ? ? ? ? ? ? ? ? ?log(LOG_NOTICE, "Loop detected on %s\n", ifp->if_xname);
> ? ? ? ? ? ? ? ? ? ? ? ?m_freem(m);
>
> ?--=-=-=--
> _______________________________________________
> 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"
>
From dwmalone at maths.tcd.ie  Thu Jul  2 08:28:06 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Thu Jul  2 08:28:12 2009
Subject: NTP - default /etc/ntp.conf
In-Reply-To: <20090605124428.GA85576@mavetju.org>
References: <20090605124428.GA85576@mavetju.org>
Message-ID: <20090702082800.GA72556@walton.maths.tcd.ie>

There are several problems with the default ntp.conf that we've
committed to -current. First, we have not followed the vendor
recommendations for the pool servers at:

	http://www.pool.ntp.org/vendors.html

We are supposed to contact the people running the pool and ask for
a freebsd.pool.ntp.org subdomain.

Second, we shouldn't have the local clock configured by default.
The local clock should only be configured on a single server in a
NTP domain that might be disconnected from the rest of the tree.
Since the default config is a client config, it doesn't make sense
to have the local clock configured. Even if it was a server config,
it still wouldn't make sense, because it is only useful if a single
server has it configured.

I'd like to suggest that we get a vendor subdomain from the pool
guys and use that, and that we comment out the local clock. We
should get this fixed before 8.0 is releasted, so that we don't end
up shipping lots misconfigured FreeBSD boxes and upset the ntp guys!

	David.
From roberto at keltia.freenix.fr  Thu Jul  2 08:46:17 2009
From: roberto at keltia.freenix.fr (Ollivier Robert)
Date: Thu Jul  2 08:46:23 2009
Subject: NTP - default /etc/ntp.conf
In-Reply-To: <20090702082800.GA72556@walton.maths.tcd.ie>
References: <20090605124428.GA85576@mavetju.org>
	<20090702082800.GA72556@walton.maths.tcd.ie>
Message-ID: <20090702084608.GA59311@roberto-al.eurocontrol.fr>

According to David Malone:
> We are supposed to contact the people running the pool and ask for
> a freebsd.pool.ntp.org subdomain.

That's a good idea.
 
> Second, we shouldn't have the local clock configured by default.

Why?

> The local clock should only be configured on a single server in a
> NTP domain that might be disconnected from the rest of the tree.
> Since the default config is a client config, it doesn't make sense
> to have the local clock configured. Even if it was a server config,
> it still wouldn't make sense, because it is only useful if a single
> server has it configured.

I do not see the point in removing it, it helps to keep the ntpd daemon
running if for some reason it loses the "real" ntp servers.

-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr
In memoriam to Ondine : http://ondine.keltia.net/

From dwmalone at maths.tcd.ie  Thu Jul  2 08:55:52 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Thu Jul  2 08:55:59 2009
Subject: NTP - default /etc/ntp.conf 
In-Reply-To: Your message of "Thu, 02 Jul 2009 10:46:08 +0200."
	<20090702084608.GA59311@roberto-al.eurocontrol.fr> 
Message-ID: <200907020955.aa73037@walton.maths.tcd.ie>

> > We are supposed to contact the people running the pool and ask for
> > a freebsd.pool.ntp.org subdomain.

> That's a good idea.

OK - should I contact the pool guys and ask for freebsd.pool.org?

> > Second, we shouldn't have the local clock configured by default.

> Why?

When Redhat did this, it caused a variety of niggles and compaints
in the ntp community. The recent thread in comp.protocols.time.ntp
gives one example where the local clock came under suspicion for
causing various problems. It also interfers with people using real
local clocks, where the system clock is controled by something other
than NTP, and you just want NTP to distribute the time.

> > The local clock should only be configured on a single server in a
> > NTP domain that might be disconnected from the rest of the tree.
> > Since the default config is a client config, it doesn't make sense
> > to have the local clock configured. Even if it was a server config,
> > it still wouldn't make sense, because it is only useful if a single
> > server has it configured.

> I do not see the point in removing it, it helps to keep the ntpd daemon
> running if for some reason it loses the "real" ntp servers.

It's definitely a misconfiguration to ship it by default. If you
have many clients all with a local clock configured, then, when
disconnected, they all just follow themselves rather than following
the clock on a server. If you have it configured on several servers
you end up with some clients following each of the servers, but
they won't all stay together unless you're lucky. For this use of
the local clock, you only want one local clock per island that might
become disconnected.

(Also, we probably really want people to run in orphan mode rather
than local clock mode, but we can wait a little longer until orphan
mode is more commonly deployed, IMHO...)

	David.
From jhay at meraka.org.za  Thu Jul  2 09:29:28 2009
From: jhay at meraka.org.za (John Hay)
Date: Thu Jul  2 09:29:35 2009
Subject: NTP - default /etc/ntp.conf
In-Reply-To: <200907020955.aa73037@walton.maths.tcd.ie>
References: <20090702084608.GA59311@roberto-al.eurocontrol.fr>
	<200907020955.aa73037@walton.maths.tcd.ie>
Message-ID: <20090702092924.GA52735@zibbi.meraka.csir.co.za>

On Thu, Jul 02, 2009 at 09:55:44AM +0100, David Malone wrote:
> > > We are supposed to contact the people running the pool and ask for
> > > a freebsd.pool.ntp.org subdomain.
> 
> > That's a good idea.
> 
> OK - should I contact the pool guys and ask for freebsd.pool.org?
> 
> > > Second, we shouldn't have the local clock configured by default.
> 
> > Why?
> 
> When Redhat did this, it caused a variety of niggles and compaints
> in the ntp community. The recent thread in comp.protocols.time.ntp
> gives one example where the local clock came under suspicion for
> causing various problems. It also interfers with people using real
> local clocks, where the system clock is controled by something other
> than NTP, and you just want NTP to distribute the time.
> 
> > > The local clock should only be configured on a single server in a
> > > NTP domain that might be disconnected from the rest of the tree.
> > > Since the default config is a client config, it doesn't make sense
> > > to have the local clock configured. Even if it was a server config,
> > > it still wouldn't make sense, because it is only useful if a single
> > > server has it configured.
> 
> > I do not see the point in removing it, it helps to keep the ntpd daemon
> > running if for some reason it loses the "real" ntp servers.
> 
> It's definitely a misconfiguration to ship it by default. If you
> have many clients all with a local clock configured, then, when
> disconnected, they all just follow themselves rather than following
> the clock on a server. If you have it configured on several servers
> you end up with some clients following each of the servers, but
> they won't all stay together unless you're lucky. For this use of
> the local clock, you only want one local clock per island that might
> become disconnected.
> 
> (Also, we probably really want people to run in orphan mode rather
> than local clock mode, but we can wait a little longer until orphan
> mode is more commonly deployed, IMHO...)
> 

I agree with what David said. Maybe just in addition, a client machine
(one that do not supply time to anyone), is not really worse off if its
ntpd daemon is not synchronised because it could not get to valid ntp
servers, so here you do not gain anything by adding a fake local clock.
You might just cause confusion because it will look like it is
synchronised where it is actually not. In the ntp server case you want
to be really carefull with using the fake local clock. It can cause a
lot of problems.

My feeling is that the fake local clock should not even be commented
out in the default ntp.conf file. It should totally removed.

John
-- 
John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org
From jiabwang at redhat.com  Thu Jul  2 09:34:36 2009
From: jiabwang at redhat.com (wang_jiabo)
Date: Thu Jul  2 09:34:42 2009
Subject: dhcpv6 client configuration
In-Reply-To: <20090702092924.GA52735@zibbi.meraka.csir.co.za>
References: <20090702084608.GA59311@roberto-al.eurocontrol.fr>	<200907020955.aa73037@walton.maths.tcd.ie>
	<20090702092924.GA52735@zibbi.meraka.csir.co.za>
Message-ID: <4A4C7F29.3080209@redhat.com>

Hi, All:
   I setup a DHCPv6 server  and dhcpv6 client  on  redhat,
but who could  tell me how to setup a dhcpv6 client on freebsd7.1 or 7.0
thanks
jiabo
From dennis.melentyev at gmail.com  Thu Jul  2 10:40:02 2009
From: dennis.melentyev at gmail.com (Dennis Melentyev)
Date: Thu Jul  2 10:40:09 2009
Subject: kern/133572: [ppp] [hang] incoming PPTP connection hangs the 
	system
Message-ID: <200907021040.n62Ae2ma082605@freefall.freebsd.org>

The following reply was made to PR kern/133572; it has been noted by GNATS.

From: Dennis Melentyev <dennis.melentyev@gmail.com>
To: Mikolaj Golub <to.my.trociny@gmail.com>
Cc: bug-followup@freebsd.org, freebsd-net@freebsd.org
Subject: Re: kern/133572: [ppp] [hang] incoming PPTP connection hangs the 
	system
Date: Thu, 2 Jul 2009 13:30:33 +0300

 Hi Mikolaj,
 
 2009/6/30 Mikolaj Golub <to.my.trociny@gmail.com>:
 >
 > Could you try the patch from kern/134557?
 
 Unfortunately, no. I haven't that setup anymore.
 
 -- 
 Dennis Melentyev
From dennis.melentyev at gmail.com  Thu Jul  2 10:59:21 2009
From: dennis.melentyev at gmail.com (Dennis Melentyev)
Date: Thu Jul  2 10:59:28 2009
Subject: kern/133572: [ppp] [hang] incoming PPTP connection hangs the 
	system
In-Reply-To: <86fxdhze4f.fsf@kopusha.onet>
References: <200906090620.n596K6Uu039348@freefall.freebsd.org>
	<86fxdhze4f.fsf@kopusha.onet>
Message-ID: <b84edfa10907020330p4268f3e4s9df50d5afc9b3918@mail.gmail.com>

Hi Mikolaj,

2009/6/30 Mikolaj Golub <to.my.trociny@gmail.com>:
>
> Could you try the patch from kern/134557?

Unfortunately, no. I haven't that setup anymore.

-- 
Dennis Melentyev
From bms at incunabulum.net  Thu Jul  2 12:34:07 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu Jul  2 12:34:14 2009
Subject: Netconf / Yang model support?
Message-ID: <4A4CA93C.6000204@incunabulum.net>

Is anyone in the FreeBSD community working on NETCONF support?

information here:
    http://en.wikipedia.org/wiki/Netconf

Interesting that SSH is a mandatory transport.

Note: This does NOT appear to be the same as Debian's netconf effort, 
but I could be wrong:
    http://netconf.alioth.debian.org/

thanks,
BMS
From lab at gta.com  Thu Jul  2 14:21:57 2009
From: lab at gta.com (Larry Baird)
Date: Thu Jul  2 14:22:03 2009
Subject: Polling and kern.polling.idle_poll
In-Reply-To: <4A4C9FCC.6020304@prt.org>
References: <20090630180029.GA8847@gta.com> <4A4C9FCC.6020304@prt.org>
Message-ID: <20090702142155.GA71817@gta.com>

Paul,

> Larry Baird wrote:
> >The man page for polling states:
> >    kern.polling.idle_poll
> >	 Controls if polling is enabled in the idle loop.  There are no
> >	 reasons (other than power saving or bugs in the scheduler's han-
> >	 dling of idle priority kernel threads) to disable this.
> >
> >So why is it now disabled by default?  Looking back through cvs the
> >change was made by Luigi way back in August of 2002.  
> >
> >  
> Did you ever get a reply for this question on the -net list?  I may have 
> missed it, but I don't think you did.
> I'm very interested in why this was changed too.
I got some off list mail from Luigi.  In 4.x, the idle_poll() was called
from idle.  Now it is its own thread.  CPU statistics will now show high 100%
utilization if your set kern.polling.idle_poll.  He also has some concerns
about if locking was in place for SMP.  Looking at the code locking appears
to be in place.

The performance improvment is too great for me to ignore, so I made a few
mods to my kernels.  I modified kern_poll to set P_NOLOAD for the idle_poll
thread. I then modified CPU statistics to view all processes with P_NOLOAD
as the idle process.  So far working great for me.  Patches below.

*** /sys/kern/kern_poll.c       2006-06-16 18:11:55.000000000 -0400
--- kern_poll.c 2009-07-02 10:03:07.000000000 -0400
***************
*** 577,583 ****
--- 577,587 ----
  {
        struct thread *td = curthread;
        struct rtprio rtp;
+       struct proc *p = td->td_proc;
  
+       PROC_LOCK(p);
+       p->p_flag |= P_NOLOAD;
+       PROC_UNLOCK(p);
        rtp.prio = RTP_PRIO_MAX;        /* lowest priority */
        rtp.type = RTP_PRIO_IDLE;
        mtx_lock_spin(&sched_lock);

*** /sys/kern/kern_clock.c      2008-06-04 06:31:41.000000000 -0400
--- kern_clock.c        2009-07-02 10:05:01.000000000 -0400
***************
*** 516,522 ****
                                thread_statclock(0);
                        td->td_sticks++;
                        p->p_rux.rux_sticks++;
!                       if (td != PCPU_GET(idlethread)) {
                                cp_time[CP_SYS]++;
                                pcp_time[CP_SYS]++;
                        } else {
--- 516,522 ----
                                thread_statclock(0);
                        td->td_sticks++;
                        p->p_rux.rux_sticks++;
!                       if ( ! (p->p_flag & P_NOLOAD) ) {
                                cp_time[CP_SYS]++;
                                pcp_time[CP_SYS]++;
                        } else {



-- 
------------------------------------------------------------------------
Larry Baird                        | http://www.gta.com
Global Technology Associates, Inc. | Orlando, FL
Email: lab@gta.com                 | TEL 407-380-0220, FAX 407-380-6080
From barney_cordoba at yahoo.com  Thu Jul  2 15:17:53 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Thu Jul  2 15:17:59 2009
Subject: Polling and kern.polling.idle_poll
Message-ID: <806553.16497.qm@web63903.mail.re1.yahoo.com>




--- On Thu, 7/2/09, Larry Baird <lab@gta.com> wrote:

> From: Larry Baird <lab@gta.com>
> Subject: Re: Polling and kern.polling.idle_poll
> To: "Paul Thornton" <prt@prt.org>
> Cc: freebsd-net@freebsd.org
> Date: Thursday, July 2, 2009, 10:21 AM
> Paul,
> 
> > Larry Baird wrote:
> > >The man page for polling states:
> > >? ? kern.polling.idle_poll
> > >?????Controls if polling
> is enabled in the idle loop.? There are no
> > >?????reasons (other than
> power saving or bugs in the scheduler's han-
> > >?????dling of idle
> priority kernel threads) to disable this.
> > >
> > >So why is it now disabled by default??
> Looking back through cvs the
> > >change was made by Luigi way back in August of
> 2002.? 
> > >
> > >? 
> > Did you ever get a reply for this question on the -net
> list?? I may have 
> > missed it, but I don't think you did.
> > I'm very interested in why this was changed too.
> I got some off list mail from Luigi.? In 4.x, the
> idle_poll() was called
> from idle.? Now it is its own thread.? CPU
> statistics will now show high 100%
> utilization if your set kern.polling.idle_poll.? He
> also has some concerns
> about if locking was in place for SMP.? Looking at the
> code locking appears
> to be in place.
> 
> The performance improvment is too great for me to ignore,
> so I made a few
> mods to my kernels.? I modified kern_poll to set
> P_NOLOAD for the idle_poll
> thread. I then modified CPU statistics to view all
> processes with P_NOLOAD
> as the idle process.? So far working great for
> me.? Patches below.
> 
> *** /sys/kern/kern_poll.c? ?
> ???2006-06-16 18:11:55.000000000 -0400
> --- kern_poll.c 2009-07-02 10:03:07.000000000 -0400
> ***************
> *** 577,583 ****
> --- 577,587 ----
> ? {
> ? ? ? ? struct thread *td = curthread;
> ? ? ? ? struct rtprio rtp;
> +? ? ???struct proc *p =
> td->td_proc;
> ? 
> +? ? ???PROC_LOCK(p);
> +? ? ???p->p_flag |= P_NOLOAD;
> +? ? ???PROC_UNLOCK(p);
> ? ? ? ? rtp.prio = RTP_PRIO_MAX;?
> ? ? ? /* lowest priority */
> ? ? ? ? rtp.type = RTP_PRIO_IDLE;
> ? ? ? ?
> mtx_lock_spin(&sched_lock);
> 
> *** /sys/kern/kern_clock.c? ? ? 2008-06-04
> 06:31:41.000000000 -0400
> --- kern_clock.c? ? ? ? 2009-07-02
> 10:05:01.000000000 -0400
> ***************
> *** 516,522 ****
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> thread_statclock(0);
> ? ? ? ? ? ? ? ?
> ? ? ? ? td->td_sticks++;
> ? ? ? ? ? ? ? ?
> ? ? ? ? p->p_rux.rux_sticks++;
> !? ? ? ? ? ? ? ?
> ? ? ???if (td !=
> PCPU_GET(idlethread)) {
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> cp_time[CP_SYS]++;
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> pcp_time[CP_SYS]++;
> ? ? ? ? ? ? ? ?
> ? ? ? ? } else {
> --- 516,522 ----
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> thread_statclock(0);
> ? ? ? ? ? ? ? ?
> ? ? ? ? td->td_sticks++;
> ? ? ? ? ? ? ? ?
> ? ? ? ? p->p_rux.rux_sticks++;
> !? ? ? ? ? ? ? ?
> ? ? ???if ( ! (p->p_flag &
> P_NOLOAD) ) {
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> cp_time[CP_SYS]++;
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> pcp_time[CP_SYS]++;
> ? ? ? ? ? ? ? ?
> ? ? ? ? } else {
> 

Curious as to why you don't simply lay out the $40 for a modern ethernet card that doesn't need polling to work well?

Barney


      
From rizzo at iet.unipi.it  Thu Jul  2 15:20:08 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Thu Jul  2 15:20:17 2009
Subject: Polling and kern.polling.idle_poll
In-Reply-To: <20090702142155.GA71817@gta.com>
References: <20090630180029.GA8847@gta.com> <4A4C9FCC.6020304@prt.org>
	<20090702142155.GA71817@gta.com>
Message-ID: <20090702150917.GA52464@onelab2.iet.unipi.it>

On Thu, Jul 02, 2009 at 10:21:55AM -0400, Larry Baird wrote:
> Paul,
> 
> > Larry Baird wrote:
> > >The man page for polling states:
> > >    kern.polling.idle_poll
> > >	 Controls if polling is enabled in the idle loop.  There are no
> > >	 reasons (other than power saving or bugs in the scheduler's han-
> > >	 dling of idle priority kernel threads) to disable this.
> > >
> > >So why is it now disabled by default?  Looking back through cvs the
> > >change was made by Luigi way back in August of 2002.  
> > >
> > >  
> > Did you ever get a reply for this question on the -net list?  I may have 
> > missed it, but I don't think you did.
> > I'm very interested in why this was changed too.
> I got some off list mail from Luigi.  In 4.x, the idle_poll() was called
> from idle.  Now it is its own thread.  CPU statistics will now show high 100%
> utilization if your set kern.polling.idle_poll.  He also has some concerns
> about if locking was in place for SMP.  Looking at the code locking appears
> to be in place.
> 
> The performance improvment is too great for me to ignore, so I made a few
> mods to my kernels.  I modified kern_poll to set P_NOLOAD for the idle_poll
> thread. I then modified CPU statistics to view all processes with P_NOLOAD
> as the idle process.  So far working great for me.  Patches below.

just to understand -- the patch below is just cosmetics to avoid
seeing the polling thread appear as "SYS" time, right ?

cheers
luigi

> *** /sys/kern/kern_poll.c       2006-06-16 18:11:55.000000000 -0400
> --- kern_poll.c 2009-07-02 10:03:07.000000000 -0400
> ***************
> *** 577,583 ****
> --- 577,587 ----
>   {
>         struct thread *td = curthread;
>         struct rtprio rtp;
> +       struct proc *p = td->td_proc;
>   
> +       PROC_LOCK(p);
> +       p->p_flag |= P_NOLOAD;
> +       PROC_UNLOCK(p);
>         rtp.prio = RTP_PRIO_MAX;        /* lowest priority */
>         rtp.type = RTP_PRIO_IDLE;
>         mtx_lock_spin(&sched_lock);
> 
> *** /sys/kern/kern_clock.c      2008-06-04 06:31:41.000000000 -0400
> --- kern_clock.c        2009-07-02 10:05:01.000000000 -0400
> ***************
> *** 516,522 ****
>                                 thread_statclock(0);
>                         td->td_sticks++;
>                         p->p_rux.rux_sticks++;
> !                       if (td != PCPU_GET(idlethread)) {
>                                 cp_time[CP_SYS]++;
>                                 pcp_time[CP_SYS]++;
>                         } else {
> --- 516,522 ----
>                                 thread_statclock(0);
>                         td->td_sticks++;
>                         p->p_rux.rux_sticks++;
> !                       if ( ! (p->p_flag & P_NOLOAD) ) {
>                                 cp_time[CP_SYS]++;
>                                 pcp_time[CP_SYS]++;
>                         } else {
> 
> 
> 
> -- 
> ------------------------------------------------------------------------
> Larry Baird                        | http://www.gta.com
> Global Technology Associates, Inc. | Orlando, FL
> Email: lab@gta.com                 | TEL 407-380-0220, FAX 407-380-6080
> _______________________________________________
> 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"
From lab at gta.com  Thu Jul  2 15:25:31 2009
From: lab at gta.com (Larry Baird)
Date: Thu Jul  2 15:25:38 2009
Subject: Polling and kern.polling.idle_poll
In-Reply-To: <20090702150917.GA52464@onelab2.iet.unipi.it>
References: <20090630180029.GA8847@gta.com> <4A4C9FCC.6020304@prt.org>
	<20090702142155.GA71817@gta.com>
	<20090702150917.GA52464@onelab2.iet.unipi.it>
Message-ID: <20090702152530.GA93332@gta.com>

> just to understand -- the patch below is just cosmetics to avoid
> seeing the polling thread appear as "SYS" time, right ?
Yes.  Another fix would be to have the idle thread call poll_idle() like
it did in 4.x.  The comment for P_NOLOAD says
	/* Ignore during load avg calculations. */
Looking at the threads that set P_NOLOAD, all of them are appear to
do minimal work.  Both idle_poll() and vm_page_zero_idle() used
to be called by the idle process.  Mapping them back to the idle
process seems reasonable to me.

Larry


-- 
------------------------------------------------------------------------
Larry Baird                        | http://www.gta.com
Global Technology Associates, Inc. | Orlando, FL
Email: lab@gta.com                 | TEL 407-380-0220, FAX 407-380-6080
From lab at gta.com  Thu Jul  2 15:31:53 2009
From: lab at gta.com (Larry Baird)
Date: Thu Jul  2 15:32:00 2009
Subject: Polling and kern.polling.idle_poll
In-Reply-To: <806553.16497.qm@web63903.mail.re1.yahoo.com>
References: <806553.16497.qm@web63903.mail.re1.yahoo.com>
Message-ID: <20090702153151.GB93332@gta.com>

> Curious as to why you don't simply lay out the $40 for a modern ethernet card that doesn't need polling to work well?
These are low end embedded boxs.  No way to upgrade.  But in actuallity
they have modern (fxp) NICS.  From our testing, live lock is a real issue
for gateways receiving lots of network traffic.  Polling prevents live
lock.

Larry

-- 
------------------------------------------------------------------------
Larry Baird                        | http://www.gta.com
Global Technology Associates, Inc. | Orlando, FL
Email: lab@gta.com                 | TEL 407-380-0220, FAX 407-380-6080
From rob.gallagher at gmail.com  Thu Jul  2 16:20:01 2009
From: rob.gallagher at gmail.com (Rob Gallagher)
Date: Thu Jul  2 16:20:07 2009
Subject: IPv6 routing
Message-ID: <1d7a7b9d0907020855s469dc3f1x34e7515f1ea6edaf@mail.gmail.com>

Hi,

I previously had a freebsd 7.0 box set up as an IPv6 router for my
home network, behind a sixxs tunnel. It was running rtadvd to hand out
IPv6 addresses from my sixxs block to the network.

However, after migrating this configuration over to a newly installed
FreeBSD 7.2 box it appears that the machine will no longer route IPv6.
All the correct settings seem to be enabled as described here:
http://www.freebsd.org/doc/en/books/handbook/network-ipv6.html, and
the configurations are identical to the 7.0 box.

The only odd thing I can see is that the machine is not getting an
IPv6 address on the lan-facing interface, which would explain why it
can't route anything. There are no issues with the sixxs tunnel itself
or IPv6 connectivity from the machine; it is also handing out IPv6
addresses to hosts on the network via RAs.

Could there be something I'm missing?

rg

-- 
rob.gallagher (at) gmail.com || www.spoofedpacket.net || PK: 0x1DD13A78
From hrs at FreeBSD.org  Thu Jul  2 16:48:34 2009
From: hrs at FreeBSD.org (Hiroki Sato)
Date: Thu Jul  2 16:48:41 2009
Subject: IPv6 routing
In-Reply-To: <1d7a7b9d0907020855s469dc3f1x34e7515f1ea6edaf@mail.gmail.com>
References: <1d7a7b9d0907020855s469dc3f1x34e7515f1ea6edaf@mail.gmail.com>
Message-ID: <20090703.014741.106072119.hrs@allbsd.org>

Rob Gallagher <rob.gallagher@gmail.com> wrote
  in <1d7a7b9d0907020855s469dc3f1x34e7515f1ea6edaf@mail.gmail.com>:

ro> The only odd thing I can see is that the machine is not getting an
ro> IPv6 address on the lan-facing interface, which would explain why it
ro> can't route anything. There are no issues with the sixxs tunnel itself
ro> or IPv6 connectivity from the machine; it is also handing out IPv6
ro> addresses to hosts on the network via RAs.
ro>
ro> Could there be something I'm missing?

 How did you configure the interfaces?  If you use gif(4) between sixx
 and your router, and then rtadvd(8) to send RAs on your LAN,
 typically all of the interfaces need manual configuration.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090702/dd4c9175/attachment.pgp
From brde at optusnet.com.au  Thu Jul  2 18:21:13 2009
From: brde at optusnet.com.au (Bruce Evans)
Date: Thu Jul  2 18:21:21 2009
Subject: NTP - default /etc/ntp.conf 
In-Reply-To: <200907020955.aa73037@walton.maths.tcd.ie>
References: <200907020955.aa73037@walton.maths.tcd.ie>
Message-ID: <20090703035833.E40558@delplex.bde.org>

On Thu, 2 Jul 2009, David Malone wrote:

>>> The local clock should only be configured on a single server in a
>>> NTP domain that might be disconnected from the rest of the tree.
>>> Since the default config is a client config, it doesn't make sense
>>> to have the local clock configured. Even if it was a server config,
>>> it still wouldn't make sense, because it is only useful if a single
>>> server has it configured.
>
>> I do not see the point in removing it, it helps to keep the ntpd daemon
>> running if for some reason it loses the "real" ntp servers.
>
> It's definitely a misconfiguration to ship it by default. If you
> have many clients all with a local clock configured, then, when
> disconnected, they all just follow themselves rather than following
> the clock on a server. If you have it configured on several servers
> you end up with some clients following each of the servers, but
> they won't all stay together unless you're lucky. For this use of
> the local clock, you only want one local clock per island that might
> become disconnected.

This is handled by having different local clocks in different strata.
I only use 2 such strata -- 1 for server and another for all clients.
But this is not so easy to set up as a default.

ref8 FreeBSD cluster machines have the new ntp.conf, so they have the
local clock with the same stratum and this misconfiguration is getting
some official testing :-).  It is probably actually unofficial, due
mergemaster blowing away the old primitive ntp.conf which is still
used on other FreeBSD cluster machines.  This seems to break the
server config generally -- ntptrace on ref8* hangs after localhost
while ntptrace on ref7-amd64 hangs after hub.

Bruce
From dwmalone at maths.tcd.ie  Thu Jul  2 18:34:18 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Thu Jul  2 18:34:25 2009
Subject: NTP - default /etc/ntp.conf 
In-Reply-To: Your message of "Fri, 03 Jul 2009 04:21:02 +1000."
	<20090703035833.E40558@delplex.bde.org> 
Message-ID: <200907021934.aa77192@walton.maths.tcd.ie>

> This is handled by having different local clocks in different strata.
> I only use 2 such strata -- 1 for server and another for all clients.
> But this is not so easy to set up as a default.

Indeed - I use 14 for the server, in the hope that it would limit
how far the unsynced time would get in the event of something
unexpected happening. If we're disconnected, I don't expect the
time to need to go more than two hops, so 14 should be OK. Introducing
some machines at stratum 10 into my network will result in something
else that I didn't expect.

> ref8 FreeBSD cluster machines have the new ntp.conf, so they have the
> local clock with the same stratum and this misconfiguration is getting
> some official testing :-).

I think this configuration has been pretty well tested, unbeknownst to
many ;-)

> It is probably actually unofficial, due
> mergemaster blowing away the old primitive ntp.conf which is still
> used on other FreeBSD cluster machines.  This seems to break the
> server config generally -- ntptrace on ref8* hangs after localhost
> while ntptrace on ref7-amd64 hangs after hub.

Interesting!

	David.
From pyunyh at gmail.com  Fri Jul  3 00:49:45 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri Jul  3 00:49:51 2009
Subject: Polling and kern.polling.idle_poll
In-Reply-To: <20090702153151.GB93332@gta.com>
References: <806553.16497.qm@web63903.mail.re1.yahoo.com>
	<20090702153151.GB93332@gta.com>
Message-ID: <20090703004750.GH13137@michelle.cdnetworks.co.kr>

On Thu, Jul 02, 2009 at 11:31:51AM -0400, Larry Baird wrote:
> > Curious as to why you don't simply lay out the $40 for a modern ethernet card that doesn't need polling to work well?
> These are low end embedded boxs.  No way to upgrade.  But in actuallity
> they have modern (fxp) NICS.  From our testing, live lock is a real issue

Lack of intelligent interrupt mitigation is a weak point of fxp(4)
hardwares. You may not need poling(4) any more on recent PCIe
based fast ethernet controllers.

> for gateways receiving lots of network traffic.  Polling prevents live
> lock.
> 
And it may also add additional latencies.

> Larry
From realliukai at gmail.com  Fri Jul  3 01:33:45 2009
From: realliukai at gmail.com (=?GB2312?B?wfW/rQ==?=)
Date: Fri Jul  3 03:57:30 2009
Subject: WDS support?
Message-ID: <7237120a0907021833r20e8a45bg243e4e3d881778b2@mail.gmail.com>

Hi all:
   I am looking for information about WDS in freebsd.I wonder whether the
WDS is supported and how to config it.
thank you
**
**
**
Michael Kevin
From realliukai at gmail.com  Fri Jul  3 01:53:56 2009
From: realliukai at gmail.com (=?GB2312?B?wfW/rQ==?=)
Date: Fri Jul  3 04:32:24 2009
Subject: 11n-aware rate control algorithm?
Message-ID: <7237120a0907021853oa614403iedb966d77bb9f451@mail.gmail.com>

Hi all

I am working on someting about 802.11n recently, but 11n transmit requires
an 11n-aware rate control algorithm. Does anybody have write the algorithm?
Could someone give me some advice and some example to help me.

thank you


Micheal Kevin
From sam at freebsd.org  Fri Jul  3 04:47:05 2009
From: sam at freebsd.org (Sam Leffler)
Date: Fri Jul  3 04:47:11 2009
Subject: WDS support?
In-Reply-To: <7237120a0907021833r20e8a45bg243e4e3d881778b2@mail.gmail.com>
References: <7237120a0907021833r20e8a45bg243e4e3d881778b2@mail.gmail.com>
Message-ID: <4A4D8D47.9040201@freebsd.org>

???? wrote:
> Hi all:
>    I am looking for information about WDS in freebsd.I wonder whether the
> WDS is supported and how to config it.
> thank you

In HEAD look at tools/tools/net80211/scripts.  I don't think the
handbook has anything.

	Sam
From barney_cordoba at yahoo.com  Fri Jul  3 11:31:45 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Fri Jul  3 11:31:52 2009
Subject: Polling and kern.polling.idle_poll
Message-ID: <117993.46390.qm@web63907.mail.re1.yahoo.com>




--- On Thu, 7/2/09, Larry Baird <lab@gta.com> wrote:

> From: Larry Baird <lab@gta.com>
> Subject: Re: Polling and kern.polling.idle_poll
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: freebsd-net@freebsd.org, "Paul Thornton" <prt@prt.org>
> Date: Thursday, July 2, 2009, 11:31 AM
> > Curious as to why you don't
> simply lay out the $40 for a modern ethernet card that
> doesn't need polling to work well?
> These are low end embedded boxs.? No way to
> upgrade.? But in actuallity
> they have modern (fxp) NICS.? From our testing, live
> lock is a real issue
> for gateways receiving lots of network traffic.?
> Polling prevents live
> lock.

There are few applications where dropping buckets of packets is preferable to losing the keyboard. If "livelock is a problem", then your systems are too slow for the task.

Livelock can easity be tuned with the "work" parameter. fxp drivers are hard coded to (I think) 6000 ints per second, so its not rocket science to set your tuning parameters to whatever the system can handle before entering a livelock scenario. In reality, interrupt moderation is the equivalent of polling 6000 times per second, in the case of fxp. You wouldn't want to set hz to 6000 as you substantially increase system overhead. Moderation is a much more efficient way of managing your ethernet loads, because the "polls" are only directed at the driver, and if you dont have traffic then you don't  need to get polled.

Barney


      
From lstewart at freebsd.org  Fri Jul  3 12:28:23 2009
From: lstewart at freebsd.org (Lawrence Stewart)
Date: Fri Jul  3 12:28:29 2009
Subject: Slow local TCP transfers on -CURRENT
In-Reply-To: <20090505160145.8C8F18FC15@mx1.freebsd.org>
References: <20090505160145.8C8F18FC15@mx1.freebsd.org>
Message-ID: <4A4DF0BC.6090207@freebsd.org>

Hi Qing,

Qing Li wrote:
>> Qing (added to CC) is aware of the problem. Not sure how far 
>> off the fix is.
>>
> 
> I am resuming the work on it, hoping to get it verified and
> finalized in a day or so. Sorry about the delay.

Did this ever get fixed? I don't think I saw a follow up to this thread 
so just thought I'd check.

Cheers,
Lawrence
From nvass9573 at gmx.com  Fri Jul  3 15:49:38 2009
From: nvass9573 at gmx.com (Nikos Vassiliadis)
Date: Fri Jul  3 15:49:46 2009
Subject: ndis and USB wirelless ethernet
In-Reply-To: <4A4880EF.5010206@gmx.com>
References: <4A43386D.80500@gmx.com>	<20090625103420.GD31161@weongyo.cdnetworks.kr>	<4A436A8A.1000405@gmx.com>	<20090626041246.GE31161@weongyo.cdnetworks.kr>	<4A461AF9.7040900@gmx.com>	<20090629032520.GA1138@weongyo.cdnetworks.kr>
	<4A4880EF.5010206@gmx.com>
Message-ID: <4A4E2873.3010501@gmx.com>

Hello Weongyo & net,

I did some tests with an AP. The bad news is that I am
getting random crashes. At least I cannot relate them
to something... It just stops responding, I cannot break
to the debugger. Would I try another driver? there are
3 versions if I recall correctly on the vendor's site.

Something strange I've noticed, is that if I set the ssid
before setting the interface to "up" state, it does not
associate with the AP.

ifconfig wlan0 down
ifconfig wlan0 ssid barba
ifconfig wlan0 up

 > Setting BSSID to 00:1b:2f:be:78:aa
 > ndis_newstate: INIT -> SCAN
 > ndis0: link state changed to DOWN
 > ndis0: link state changed to UP
 > ndis_scan_results: 4 results
 > scan: bssid 00:1c:a2:b2:4e:e5 chan 2412MHz (1/1152) rssi 25
 > scan: bssid 00:13:33:07:90:90 chan 2442MHz (7/1152) rssi 75
 > scan: bssid 00:05:59:0a:b7:c1 chan 2437MHz (6/1152) rssi 60
 > scan: bssid 00:1a:4f:20:dc:4a chan 2437MHz (6/1152) rssi 6
 > wlan0: ieee80211_new_state_locked: pending SCAN -> RUN transition lost
 > ndis_newstate: SCAN -> AUTH
 > Setting BSSID to 00:1b:2f:be:78:aa
 > Setting BSSID to ff:ff:ff:ff:ff:ff
 > Setting ESSID to "barba"
 > ndis_newstate: AUTH -> ASSOC

If if delete the ssid, and "up" the interface, it
associates:

 > Setting BSSID to 00:1b:2f:be:78:aa
 > ndis_newstate: INIT -> SCAN
 > ndis0: link state changed to DOWN
 > ndis_scan_results: 4 results
 > scan: bssid 00:13:33:07:90:90 chan 2442MHz (7/1152) rssi 73
 > scan: bssid 00:1c:a2:b2:4e:e5 chan 2412MHz (1/1152) rssi 15
 > scan: bssid 00:1a:4f:20:dc:4a chan 2437MHz (6/1152) rssi 7
 > scan: bssid 00:05:59:0a:b7:c1 chan 2437MHz (6/1152) rssi 54
 > ndis_newstate: SCAN -> AUTH
 > Setting BSSID to 00:1b:2f:be:78:aa
 > Setting BSSID to ff:ff:ff:ff:ff:ff
 > Setting ESSID to "barba"
 > ndis_newstate: AUTH -> ASSOC
 > ndis_newstate: ASSOC -> RUN
 > ndis0: link state changed to UP

If you have some idea, I would be happy to test it.

Thanks, Nikos
From wangfangcs at gmail.com  Fri Jul  3 19:47:20 2009
From: wangfangcs at gmail.com (Fang Wang)
Date: Fri Jul  3 19:47:26 2009
Subject: tcputo(RFC 5482) can work now
Message-ID: <abd04180907031224r2f1fa787v7727aeb86f7becb7@mail.gmail.com>

Hi,

    The tcp UTO option described in RFC 5482 now is accomplished. The
branch is //depot/projects/soc2009/tcputo/.

Regards,
Fang Wang
From rpaulo at freebsd.org  Fri Jul  3 22:07:30 2009
From: rpaulo at freebsd.org (Rui Paulo)
Date: Fri Jul  3 22:07:37 2009
Subject: CFR: 802.11s implementation (mesh11s project)
Message-ID: <53F44E76-CB3A-45F5-A269-7B034350BA60@freebsd.org>

Hi,
If you would like to review the mesh11s code, you can find a diff  
against HEAD here:
	http://people.freebsd.org/~rpaulo/mesh_195323.diff

This is the most recent diff, but expect changes. We will present the  
re@ team with a patch so we can discuss the inclusion of this in the  
8.0 release.

Thanks,
--
Rui Paulo

From mav at FreeBSD.org  Sat Jul  4 06:02:03 2009
From: mav at FreeBSD.org (mav@FreeBSD.org)
Date: Sat Jul  4 06:02:10 2009
Subject: kern/134557: [netgraph] [hang] 7.2 with mpd5.3 hanging up -
	ng_pptp problem
Message-ID: <200907040602.n64623KG016795@freefall.freebsd.org>

Synopsis: [netgraph] [hang] 7.2 with mpd5.3 hanging up - ng_pptp problem

State-Changed-From-To: open->closed
State-Changed-By: mav
State-Changed-When: Sat Jul 4 06:01:31 UTC 2009
State-Changed-Why: 
Patch committed and merged to 7-SATBLE.

http://www.freebsd.org/cgi/query-pr.cgi?pr=134557
From dfilter at FreeBSD.ORG  Sat Jul  4 06:10:04 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Sat Jul  4 06:10:10 2009
Subject: kern/134557: commit references a PR
Message-ID: <200907040610.n646A41V016953@freefall.freebsd.org>

The following reply was made to PR kern/134557; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/134557: commit references a PR
Date: Sat,  4 Jul 2009 06:01:15 +0000 (UTC)

 Author: mav
 Date: Sat Jul  4 06:00:57 2009
 New Revision: 195336
 URL: http://svn.freebsd.org/changeset/base/195336
 
 Log:
   MFC rev.195335:
   Fix infinite loop in ng_iface, that happens when packet passes out via
   two different ng interfaces sequentially due to tunnelling.
   
   PR:		kern/134557
   Submitted by:	Mikolaj Golub
 
 Modified:
   stable/7/sys/   (props changed)
   stable/7/sys/contrib/pf/   (props changed)
   stable/7/sys/netgraph/ng_iface.c
 
 Modified: stable/7/sys/netgraph/ng_iface.c
 ==============================================================================
 --- stable/7/sys/netgraph/ng_iface.c	Sat Jul  4 05:07:52 2009	(r195335)
 +++ stable/7/sys/netgraph/ng_iface.c	Sat Jul  4 06:00:57 2009	(r195336)
 @@ -365,7 +365,8 @@ ng_iface_output(struct ifnet *ifp, struc
  	}
  
  	/* Protect from deadly infinite recursion. */
 -	while ((mtag = m_tag_locate(m, MTAG_NGIF, MTAG_NGIF_CALLED, NULL))) {
 +	mtag = NULL;
 +	while ((mtag = m_tag_locate(m, MTAG_NGIF, MTAG_NGIF_CALLED, mtag))) {
  		if (*(struct ifnet **)(mtag + 1) == ifp) {
  			log(LOG_NOTICE, "Loop detected on %s\n", ifp->if_xname);
  			m_freem(m);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From nork at FreeBSD.org  Sun Jul  5 05:53:28 2009
From: nork at FreeBSD.org (Norikatsu Shigemura)
Date: Sun Jul  5 05:53:41 2009
Subject: pcap(bpf) packet injection not-acceptable on FreeBSD host.
Message-ID: <20090705145320.fdd081ef.nork@FreeBSD.org>

Hi.

	I have a trouble that an application packet-injecting by pcap(bpf)'s
	pcap_sendpacket function doesn't communicate to FreeBSD host, but
	can communicate to other machine.  So I researched, and I noticed
	that sys/net/if_ethersubr.c has a structured issue(?)(I didn't know).
	Do you have any idea?


	I made a test program (attached file, fake-arp-reply.c).  Do 'gcc
	fake-arp-reply -lpcap'.  I tested 2 case (8-current self,
	8-current -> 7-stable):

test platform (I tested on 8-current, 7.2-stable)
on 8-current:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ ifconfig rl0
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8<VLAN_MTU>
        ether 00:0b:97:33:1c:30
        inet 192.168.36.6 netmask 0xffffff00 broadcast 192.168.36.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
$ arp -an
? (192.168.36.6) at 00:0b:97:33:1c:30 on rl0 permanent [ethernet]
? (192.168.36.1) at 00:1b:78:37:f1:cf on rl0 [ethernet]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

on 7-stable:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ ifconfig bge0
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=98<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:1b:78:37:f1:cf
        inet 192.168.36.1 netmask 0xffffff00 broadcast 192.168.36.255
        inet6 fe80::21b:78ff:fe37:f1cf%bge0 prefixlen 64 scopeid 0x1 
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active
$ arp -an
? (192.168.36.1) at 00:1b:78:37:f1:cf on bge0 permanent [ethernet]
? (192.168.36.6) at 00:0b:97:33:1c:30 on bge0 [ethernet]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

TEST 1: 8-current self (same 7-stable self, too)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# ./a.out -d rl0 -i 192.168.36.64 -m 10-20-30-40-50-60
rl0, 192.168.36.64 10:20:30:40:50:60
(on other console, ping 192.168.36.64)
arp request catched, arp replyed and done.
# arp -an
? (192.168.36.6) at 00:0b:97:33:1c:30 on rl0 permanent [ethernet]
? (192.168.36.1) at 00:1b:78:37:f1:cf on rl0 [ethernet]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

TEST 2: 8-current -> 7-stable(same 8-current -> 7-stable, too)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
# ./a.out -d rl0 -i 192.168.36.64 -m 10-20-30-40-50-60
rl0, 192.168.36.64 10:20:30:40:50:60
 (on other machine's console, ping 192.168.36.64...)
arp request catched, arp replyed and done.

On other machine:
$ ping 192.168.36.64
PING 192.168.36.64 (192.168.36.64): 56 data bytes
^C
--- 192.168.36.64 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
$ arp -an
? (192.168.36.1) at 00:1b:78:37:f1:cf on bge0 permanent [ethernet]
? (192.168.36.6) at 00:0b:97:33:1c:30 on bge0 [ethernet]
? (192.168.36.64) at 10:20:30:40:50:60 on bge0 [ethernet]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-------------- next part --------------
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <pcap.h>

struct sendpkt {
	u_char	dmac[6];
	u_char	smac[6];
	u_char	etype[2];
	u_char	htype[2];
	u_char	ptype[2];
	u_char	hlen[1];
	u_char	plen[1];
	u_char	op[2];
	u_char	src_mac[6];
	u_char	src_ipv4[4];
	u_char	dst_mac[6];
	u_char	dst_ipv4[4];
	u_char	trailer[18];
} __packed;

struct sendpkt sendpkt = {
	{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, }, /* overwrite live packet */
	{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, }, /* overwrite argument */
	{ 0x08, 0x06, },			 /* constant */
	{ 0x00, 0x01, },			 /* constant */
	{ 0x08, 0x00, },			 /* constant */
	{ 0x06, },				 /* constant */
	{ 0x04, },				 /* constant */
	{ 0x00, 0x02, },			 /* constant */
	{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, }, /* overwrite live packet */
	{ 0x00, 0x00, 0x00, 0x00, },		 /* overwrite live packet */
	{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, }, /* overwrite argument */
	{ 0xff, 0xff, 0xff, 0xff, },		 /* overwrite argument */
	{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,	 /* constant */
	  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
	  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, },
};

int
main(int argc, char *argv[])
{
	int	ch;
	u_char	dev[30] = "lo0",
		mac[6]  = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, },
		ipv4[4] = { 0, 0, 0, 0, };
	pcap_t	*p;
	static char errbuf[PCAP_ERRBUF_SIZE];

	while(  (ch = getopt(argc, argv, "d:i:m:")) != -1  )  {
		switch (ch)  {
		case 'd':
			strlcpy(dev, optarg, sizeof(dev));
			break;
		case 'i':
			sscanf(optarg, "%hhd%*[.]%hhd%*[.]%hhd%*[.]%hhd",
				&ipv4[0], &ipv4[1], &ipv4[2], &ipv4[3]);
			break;
		case 'm':
			sscanf(optarg, "%hhx%*[:.-]%hhx%*[:.-]%hhx%*[:.-]%hhx%*[:.-]%hhx%*[:.-]%hhx",
				&mac[0], &mac[1], &mac[2], &mac[3], &mac[4], &mac[5]);
			break;
		default:
			fprintf(stderr, "-d Device Name -i IPv4 Address -m MAC Addresss\n");
			exit(0);
			/* NOT REACHABLE */
		}
	}

	printf("%s, %d.%d.%d.%d %02x:%02x:%02x:%02x:%02x:%02x\n",
		dev,
		ipv4[0], ipv4[1], ipv4[2], ipv4[3],
		mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);

	memcpy(&sendpkt.smac,     mac,  sizeof(sendpkt.smac));
	memcpy(&sendpkt.src_mac,  mac,  sizeof(sendpkt.src_mac));
	memcpy(&sendpkt.src_ipv4, ipv4, sizeof(sendpkt.src_ipv4));

	if(  (p = pcap_open_live(dev, 1500/*bytes*/, 1/*TRUE*/, 10/*msec*/, errbuf))  )  {
		int in_loop = 1;
		while(  in_loop  )  {
			struct pcap_pkthdr pkt_info;
			u_char *recvpkt;
			if(  (recvpkt = (u_char *)pcap_next(p, &pkt_info))  )  {
				if(  recvpkt[12] == 0x08    && recvpkt[13] == 0x06
				&&   recvpkt[20] == 0x00    && recvpkt[21] == 0x01
				&&   recvpkt[38] == ipv4[0] && recvpkt[39] == ipv4[1]
				&&   recvpkt[40] == ipv4[2] && recvpkt[41] == ipv4[3]  )  {
					memcpy(sendpkt.dmac,     &recvpkt[6],  sizeof(sendpkt.dmac));
					memcpy(sendpkt.dst_mac,  &recvpkt[22], sizeof(sendpkt.dst_mac));
					memcpy(sendpkt.dst_ipv4, &recvpkt[28], sizeof(sendpkt.dst_ipv4));
					pcap_sendpacket(p, (u_char *)&sendpkt, sizeof(sendpkt));
					printf("arp request catched, arp replyed and done.\n");
					in_loop = 0;
				}  else  {
					printf("len=%d           \r", pkt_info.caplen);
					if(  recvpkt[12] == 0x08    && recvpkt[13] == 0x06
					&&   recvpkt[20] == 0x00    && recvpkt[21] == 0x01  )  {
						printf("arp? recv=%d.%d.%d.%d / argv=%d.%d.%d.%d\n",
							recvpkt[38], recvpkt[39], recvpkt[40], recvpkt[41],
							ipv4[0], ipv4[1], ipv4[2], ipv4[3]);
					}
					fflush(stdout);
				}
			}
			usleep(100);
		}

		pcap_close(p);
	}  else  {
		fprintf(stderr, "pcap_open_live: error '%s'\n", errbuf);
	}

	return 0;
}
From weongyo.jeong at gmail.com  Mon Jul  6 04:37:52 2009
From: weongyo.jeong at gmail.com (Weongyo Jeong)
Date: Mon Jul  6 04:37:59 2009
Subject: ndis and USB wirelless ethernet
In-Reply-To: <4A4E2873.3010501@gmx.com>
References: <4A43386D.80500@gmx.com>
	<20090625103420.GD31161@weongyo.cdnetworks.kr>
	<4A436A8A.1000405@gmx.com>
	<20090626041246.GE31161@weongyo.cdnetworks.kr>
	<4A461AF9.7040900@gmx.com>
	<20090629032520.GA1138@weongyo.cdnetworks.kr>
	<4A4880EF.5010206@gmx.com> <4A4E2873.3010501@gmx.com>
Message-ID: <20090706043747.GD1138@weongyo.cdnetworks.kr>

On Fri, Jul 03, 2009 at 06:49:07PM +0300, Nikos Vassiliadis wrote:
> Hello Weongyo & net,
> 
> I did some tests with an AP. The bad news is that I am
> getting random crashes. At least I cannot relate them
> to something... It just stops responding, I cannot break
> to the debugger. Would I try another driver? there are
> 3 versions if I recall correctly on the vendor's site.

I'm happy to see your device is successfully associated with AP.
However it seems it's a bad news that you sometimes meet crashes.  Does
a random crash mean a OS hang (e.g. could not type any keys) or no more
work of network operations?

Frankly speaking, for both cases it looks I could not provide any
solutions without backtraces unless I encountered same problems on my
environment.  It'd better if we can reproduce its problem easily.

One thing to hang as far as I know is that try to execute `ifconfig down
&& ifconfig up' multiple times.  In NDIS USB support it's recommended
that `ifconfig up' is executed once.

I think you can try another drivers.

> Something strange I've noticed, is that if I set the ssid
> before setting the interface to "up" state, it does not
> associate with the AP.
> 
> ifconfig wlan0 down
> ifconfig wlan0 ssid barba
> ifconfig wlan0 up
> 
> > Setting BSSID to 00:1b:2f:be:78:aa
> > ndis_newstate: INIT -> SCAN
> > ndis0: link state changed to DOWN
> > ndis0: link state changed to UP
> > ndis_scan_results: 4 results
> > scan: bssid 00:1c:a2:b2:4e:e5 chan 2412MHz (1/1152) rssi 25
> > scan: bssid 00:13:33:07:90:90 chan 2442MHz (7/1152) rssi 75
> > scan: bssid 00:05:59:0a:b7:c1 chan 2437MHz (6/1152) rssi 60
> > scan: bssid 00:1a:4f:20:dc:4a chan 2437MHz (6/1152) rssi 6
> > wlan0: ieee80211_new_state_locked: pending SCAN -> RUN transition lost
> > ndis_newstate: SCAN -> AUTH
> > Setting BSSID to 00:1b:2f:be:78:aa
> > Setting BSSID to ff:ff:ff:ff:ff:ff
> > Setting ESSID to "barba"
> > ndis_newstate: AUTH -> ASSOC
> 
> If if delete the ssid, and "up" the interface, it
> associates:
> 
> > Setting BSSID to 00:1b:2f:be:78:aa
> > ndis_newstate: INIT -> SCAN
> > ndis0: link state changed to DOWN
> > ndis_scan_results: 4 results
> > scan: bssid 00:13:33:07:90:90 chan 2442MHz (7/1152) rssi 73
> > scan: bssid 00:1c:a2:b2:4e:e5 chan 2412MHz (1/1152) rssi 15
> > scan: bssid 00:1a:4f:20:dc:4a chan 2437MHz (6/1152) rssi 7
> > scan: bssid 00:05:59:0a:b7:c1 chan 2437MHz (6/1152) rssi 54
> > ndis_newstate: SCAN -> AUTH
> > Setting BSSID to 00:1b:2f:be:78:aa
> > Setting BSSID to ff:ff:ff:ff:ff:ff
> > Setting ESSID to "barba"
> > ndis_newstate: AUTH -> ASSOC
> > ndis_newstate: ASSOC -> RUN
> > ndis0: link state changed to UP
> 
> If you have some idea, I would be happy to test it.

AFAIK this behavior (ASSOC -> RUN) depends on the routine of the link
status change on NDIS driver that in private experience, some drivers
doesn't call the link status handler even if it's ready to use or call
the handler too early which is one of the abnormal.

So don't know what's going on in NDIS driver currently.

regards,
Weongyo Jeong
From andriko.b at gmail.com  Mon Jul  6 11:00:10 2009
From: andriko.b at gmail.com (Andrew Bliznak)
Date: Mon Jul  6 11:00:17 2009
Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
	recovering
Message-ID: <200907061100.n66B09AP002935@freefall.freebsd.org>

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: Andrew Bliznak <andriko.b@gmail.com>
To: bug-followup@FreeBSD.org, skylord@linkline.ru
Cc:  
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
	recovering
Date: Mon, 6 Jul 2009 13:20:12 +0300

 Same problem with Asus P5BV-C/4L in production.
 
 I found desktop with Asus P5LD2 MB and use it for experimental setup.
 Three host is same gig switch, msk0 configured with vlans and
 ipforwarding
 For tests I run iperf -c 192.168.4.21 -t 60000 -w 128k -P 4 between
 hosts on different vlans.
 7.2-RELEASE kernel with if_msk* from head +patch. Need to specify
 ifconfig -vlanhwtag  to run without input errors,
 after 30 minutes card locked,  down/up interface not help, need to reboot.
 Next I connect disk witch Ubuntu 9.04, setup vlans, test run ok,
 little lover forwarding rate.
 After, boot again freebsd, run test. Hmm, test run ok...
 Reboot with stock 7.2-REL GENERIC kernel. Box running well over weekend...
From bugmaster at FreeBSD.org  Mon Jul  6 11:07:04 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jul  6 11:09:03 2009
Subject: Current problem reports assigned to freebsd-net@FreeBSD.org
Message-ID: <200907061107.n66B73Cu010867@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/136168  net        [em] em driver initialization fails on Intel 5000PSL m
o kern/135836  net        [bce] bce BCM5709 Watchdog after warm boot - ok after 
o kern/135502  net        [periodic] Warning message raised by rtfree function i
o kern/135222  net        [igb] low speed routing between two igb interfaces
o kern/135067  net        [patch] [fib] Incorrect KASSERTs in sys/net/route.c
o kern/134931  net        [route] [fib] Route messages sent to all socket listen
o kern/134658  net        [bce] bce driver fails on PowerEdge m610 blade.
o kern/134583  net        [hang] Machine with jail freezes after random amount o
o kern/134531  net        [route] [panic] kernel crash related to routes/zebra
o kern/134401  net        [msk] [panic] Kernel Fatal trap 12: page fault while i
o kern/134369  net        [route] [ip6] IPV6 in Head broken for routing table up
o kern/134168  net        [ral] ral driver problem on RT2525 2.4GHz transceiver 
o kern/134157  net        [dummynet] dummynet loads cpu for 100% and make a syst
o kern/134079  net        [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8
o kern/133969  net        [dummynet] [panic] Fatal trap 12: page fault while in 
o kern/133968  net        [dummynet] [panic] dummynet kernel panic
o kern/133902  net        [tun] Killing tun0 iface ssh tunnel causes Panic Strin
o kern/133736  net        [udp] ip_id not protected ...
o kern/133613  net        [wpi] [panic] kernel panic in wpi(4)
o kern/133595  net        [panic] Kernel Panic at pcpu.h:195
o kern/133572  net        [ppp] [hang] incoming PPTP connection hangs the system
o kern/133490  net        [bpf] [panic] 'kmem_map too small' panic on Dell r900 
o kern/133328  net        [bge] [panic] Kernel panics with Windows7 client
o kern/133235  net        [netinet] [patch] Process SIOCDLIFADDR command incorre
o kern/133218  net        [carp] [hang] use of carp(4) causes system to freeze
o kern/133204  net        [msk] msk driver timeouts
o kern/133060  net        [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs
o kern/132991  net        [bge] if_bge low performance problem
o kern/132984  net        [netgraph] swi1: net 100% cpu usage
f bin/132911   net        ip6fw(8): argument type of fill_icmptypes is wrong and
o kern/132889  net        [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d
o kern/132885  net        [wlan] 802.1x broken after SVN rev 189592
o conf/132851  net        [fib] [patch] allow to setup fib for service running f
o kern/132832  net        [netinet] [patch] tcp_output() might generate invalid 
o bin/132798   net        [patch] ggatec(8): ggated/ggatec connection slowdown p
o kern/132734  net        [ifmib] [panic] panic in net/if_mib.c
o kern/132722  net        [ath] Wifi ath0 associates fine with AP, but DHCP or I
o kern/132715  net        [lagg] [panic] Panic when creating vlan's on lagg inte
o kern/132705  net        [libwrap] [patch] libwrap - infinite loop if hosts.all
o kern/132672  net        [ndis] [panic] ndis with rt2860.sys causes kernel pani
o kern/132669  net        [xl] 3c905-TX send DUP! in reply on ping (sometime)
o kern/132625  net        [iwn] iwn drivers don't support setting country
o kern/132554  net        [ipl] There is no ippool start script/ipfilter magic t
o kern/132354  net        [nat] Getting some packages to ipnat(8) causes crash
o kern/132285  net        [carp] alias gives incorrect hash in dmesg
o kern/132277  net        [crypto] [ipsec] poor performance using cryptodevice f
o conf/132179  net        [patch] /etc/network.subr: ipv6 rtsol on incorrect wla
o kern/132107  net        [carp] carp(4) advskew setting ignored when carp IP us
o kern/131781  net        [ndis] ndis keeps dropping the link
o kern/131776  net        [wi] driver fails to init
o kern/131753  net        [altq] [panic] kernel panic in hfsc_dequeue
o bin/131567   net        [socket] [patch] Update for regression/sockets/unix_cm
o kern/131549  net        ifconfig(8) can't clear 'monitor' mode on the wireless
o kern/131536  net        [netinet] [patch] kernel does allow manipulation of su
o bin/131365   net        route(8): route add changes interpretation of network 
o kern/131162  net        [ath] Atheros driver bugginess and kernel crashes
o kern/131153  net        [iwi] iwi doesn't see a wireless network
f kern/131087  net        [ipw] [panic] ipw / iwi - no sent/received packets; iw
f kern/130820  net        [ndis] wpa_supplicant(8) returns 'no space on device'
o kern/130628  net        [nfs] NFS / rpc.lockd deadlock on 7.1-R
o conf/130555  net        [rc.d] [patch] No good way to set ipfilter variables a
o kern/130525  net        [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau
o kern/130311  net        [wlan_xauth] [panic] hostapd restart causing kernel pa
o kern/130109  net        [ipfw] Can not set fib for packets originated from loc
f kern/130059  net        [panic] Leaking 50k mbufs/hour
o kern/129750  net        [ath] Atheros AR5006 exits on "cannot map register spa
f kern/129719  net        [nfs] [panic] Panic during shutdown, tcp_ctloutput: in
o kern/129580  net        [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo
o kern/129517  net        [ipsec] [panic] double fault / stack overflow
o kern/129508  net        [carp] [panic] Kernel panic with EtherIP (may be relat
o kern/129352  net        [xl] [patch] xl0 watchdog timeout
o kern/129219  net        [ppp] Kernel panic when using kernel mode ppp
o kern/129197  net        [panic] 7.0 IP stack related panic
o kern/129135  net        [vge] vge driver on a VIA mini-ITX not working
o bin/128954   net        ifconfig(8) deletes valid routes
o kern/128917  net        [wpi] [panic] if_wpi and wpa+tkip causing kernel panic
o kern/128884  net        [msk] if_msk page fault while in kernel mode
o kern/128840  net        [igb] page fault under load with igb/LRO
o bin/128602   net        [an] wpa_supplicant(8) crashes with an(4)
o kern/128598  net        [bluetooth] WARNING: attempt to net_add_domain(bluetoo
o kern/128448  net        [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res
o conf/128334  net        [request] use wpa_cli in the "WPA DHCP" situation
o bin/128295   net        [patch] ifconfig(8) does not print TOE4 or TOE6 capabi
o bin/128001   net        wpa_supplicant(8), wlan(4), and wi(4) issues
o kern/127928  net        [tcp] [patch] TCP bandwidth gets squeezed every time t
o kern/127834  net        [ixgbe] [patch] wrong error counting
o kern/127826  net        [iwi] iwi0 driver has reduced performance and connecti
o kern/127815  net        [gif] [patch] if_gif does not set vlan attributes from
o kern/127724  net        [rtalloc] rtfree: 0xc5a8f870 has 1 refs
f bin/127719   net        [arp] arp: Segmentation fault (core dumped)
s kern/127587  net        [bge] [request] if_bge(4) doesn't support BCM576X fami
f kern/127528  net        [icmp]: icmp socket receives icmp replies not owned by
o bin/127192   net        routed(8) removes the secondary alias IP of interface 
f kern/127145  net        [wi]: prism (wi) driver crash at bigger traffic
o kern/127102  net        [wpi] Intel 3945ABG low throughput
o kern/127057  net        [udp] Unable to send UDP packet via IPv6 socket to IPv
o kern/127050  net        [carp] ipv6 does not work on carp interfaces [regressi
o kern/126945  net        [carp] CARP interface destruction with ifconfig destro
o kern/126924  net        [an] [patch] printf -> device_printf and simplify prob
o kern/126895  net        [patch] [ral] Add antenna selection (marked as TBD)
o kern/126874  net        [vlan]: Zebra problem if ifconfig vlanX destroy
o bin/126822   net        wpa_supplicant(8): WPA PSK does not work in adhoc mode
o kern/126714  net        [carp] CARP interface renaming makes system no longer 
o kern/126695  net        rtfree messages and network disruption upon use of if_
o kern/126688  net        [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and 
o kern/126475  net        [ath] [panic] ath pcmcia card inevitably panics under 
o kern/126339  net        [ipw] ipw driver drops the connection
o kern/126214  net        [ath] txpower problem with Atheros wifi card
o kern/126075  net        [inet] [patch] internet control accesses beyond end of
o bin/125922   net        [patch] Deadlock in arp(8)
o kern/125920  net        [arp] Kernel Routing Table loses Ethernet Link status 
o kern/125845  net        [netinet] [patch] tcp_lro_rx() should make use of hard
o kern/125816  net        [carp] [if_bridge] carp stuck in init when using bridg
f kern/125502  net        [ral] ifconfig ral0 scan produces no output unless in 
o kern/125258  net        [socket] socket's SO_REUSEADDR option does not work
o kern/125239  net        [gre] kernel crash when using gre
o kern/124767  net        [iwi] Wireless connection using iwi0 driver (Intel 220
o kern/124753  net        [ieee80211] net80211 discards power-save queue packets
o kern/124341  net        [ral] promiscuous mode for wireless device ral0 looses
o kern/124160  net        [libc] connect(2) function loops indefinitely
o kern/124127  net        [msk] watchdog timeout (missed Tx interrupts) -- recov
o kern/124021  net        [ip6] [panic] page fault in nd6_output()
o kern/123968  net        [rum] [panic] rum driver causes kernel panic with WPA.
p kern/123961  net        [vr] [patch] Allow vr interface to handle vlans
o kern/123892  net        [tap] [patch] No buffer space available
o kern/123890  net        [ppp] [panic] crash & reboot on work with PPP low-spee
o kern/123858  net        [stf] [patch] stf not usable behind a NAT
o kern/123796  net        [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not
o bin/123633   net        ifconfig(8) doesn't set inet and ether address in one 
f kern/123617  net        [tcp] breaking connection when client downloading file
o kern/123603  net        [tcp] tcp_do_segment and Received duplicate SYN
o kern/123559  net        [iwi] iwi periodically disassociates/associates [regre
o bin/123465   net        [ip6] route(8): route add -inet6 <ipv6_addr> -interfac
o kern/123463  net        [ipsec] [panic] repeatable crash related to ipsec-tool
o kern/123429  net        [nfe] [hang] "ifconfig nfe up" causes a hard system lo
o kern/123347  net        [bge] bge1: watchdog timeout -- linkstate changed to D
o conf/123330  net        [nsswitch.conf] Enabling samba wins in nsswitch.conf c
o kern/123256  net        [wpi] panic: blockable sleep lock with wpi(4)
f kern/123172  net        [bce] Watchdog timeout problems with if_bce
o kern/123160  net        [ip] Panic and reboot at sysctl kern.polling.enable=0
o kern/122989  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/122954  net        [lagg] IPv6 EUI64 incorrectly chosen for lagg devices
o kern/122928  net        [em] interface watchdog timeouts and stops receiving p
f kern/122839  net        [multicast] FreeBSD 7 multicast routing problem
p kern/122794  net        [lagg] Kernel panic after brings lagg(8) up if NICs ar
o kern/122780  net        [lagg] tcpdump on lagg interface during high pps wedge
o kern/122772  net        [em] em0 taskq panic, tcp reassembly bug causes radix 
o kern/122743  net        [mbuf] [panic] vm_page_unwire: invalid wire count: 0
o kern/122697  net        [ath] Atheros card is not well supported
o kern/122685  net        It is not visible passing packets in tcpdump(1)
o kern/122551  net        [bge] Broadcom 5715S no carrier on HP BL460c blade usi
o kern/122319  net        [wi] imposible to enable ad-hoc demo mode with Orinoco
o kern/122290  net        [netgraph] [panic] Netgraph related "kmem_map too smal
f kern/122252  net        [ipmi] [bge] IPMI problem with BCM5704 (does not work 
o kern/122195  net        [ed] Alignment problems in if_ed
o kern/122058  net        [em] [panic] Panic on em1: taskq
o kern/122033  net        [ral] [lor] Lock order reversal in ral0 at bootup [reg
o bin/121895   net        [patch] rtsol(8)/rtsold(8) doesn't handle managed netw
o kern/121872  net        [wpi] driver fails to attach on a fujitsu-siemens s711
s kern/121774  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/121706  net        [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit
o kern/121624  net        [em] [regression] Intel em WOL fails after upgrade to 
o kern/121555  net        [panic] Fatal trap 12: current process = 12 (swi1: net
o kern/121443  net        [gif] [lor] icmp6_input/nd6_lookup
o kern/121437  net        [vlan] Routing to layer-2 address does not work on VLA
o bin/121359   net        [patch] ppp(8): fix local stack overflow in ppp
o kern/121298  net        [em] [panic] Fatal trap 12: page fault while in kernel
o kern/121257  net        [tcp] TSO + natd  -> slow outgoing tcp traffic
o kern/121181  net        [panic] Fatal trap 3: breakpoint instruction fault whi
o kern/121080  net        [bge] IPv6 NUD problem on multi address config on bge0
o kern/120966  net        [rum] kernel panic with if_rum and WPA encryption
p docs/120945  net        [patch] ip6(4) man page lacks documentation for TCLASS
o kern/120566  net        [request]: ifconfig(8) make order of arguments more fr
o kern/120304  net        [netgraph] [patch] netgraph source assumes 32-bit time
o kern/120266  net        [udp] [panic] gnugk causes kernel panic when closing U
o kern/120232  net        [nfe] [patch] Bring in nfe(4) to RELENG_6
o kern/120130  net        [carp] [panic] carp causes kernel panics in any conste
o bin/120060   net        routed(8) deletes link-level routes in the presence of
o kern/119945  net        [rum] [panic] rum device in hostap mode, cause kernel 
o kern/119791  net        [nfs] UDP NFS mount of aliased IP addresses from a Sol
o kern/119617  net        [nfs] nfs error on wpa network when reseting/shutdown
f kern/119516  net        [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi
o kern/119432  net        [arp] route add -host <host> -iface <nic> causes arp e
o kern/119225  net        [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr
a bin/118987   net        ifconfig(8): ifconfig -l (address_family) does not wor
o sparc/118932 net        [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output
a kern/118879  net        [bge] [patch] bge has checksum problems on the 5703 ch
o kern/118727  net        [netgraph] [patch] [request] add new ng_pf module
a kern/118238  net        [bce] [patch] bce driver shows "no carrier" on Intel S
s kern/117717  net        [panic] Kernel panic with Bittorrent client.
o kern/117448  net        [carp] 6.2 kernel crash [regression]
o kern/117423  net        [vlan] Duplicate IP on different interfaces
o bin/117339   net        [patch] route(8): loading routing management commands 
o kern/117271  net        [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap
o kern/117043  net        [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM
o kern/116837  net        [tun] [panic] [patch] ifconfig tunX destroy: panic
o kern/116747  net        [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 
o bin/116643   net        [patch] [request] fstat(1): add INET/INET6 socket deta
o kern/116328  net        [bge]: Solid hang with bge interface
o kern/116185  net        [iwi] if_iwi driver leads system to reboot
o kern/115239  net        [ipnat] panic with 'kmem_map too small' using ipnat
o kern/115019  net        [netgraph] ng_ether upper hook packet flow stops on ad
o kern/115002  net        [wi] if_wi timeout. failed allocation (busy bit). ifco
o kern/114915  net        [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f
o kern/113895  net        [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R
o kern/112722  net        [ipsec] [udp] IP v4 udp fragmented packet reject
o kern/112686  net        [patm] patm driver freezes System (FreeBSD 6.2-p4) i38
o kern/112570  net        [bge] packet loss with bge driver on BCM5704 chipset
o bin/112557   net        [patch] ppp(8) lock file should not use symlink name
o kern/112528  net        [nfs] NFS over TCP under load hangs with "impossible p
o kern/111457  net        [ral] ral(4) freeze
o kern/110140  net        [ipw] ipw fails under load
o kern/109733  net        [bge] bge link state issues [regression]
o kern/109470  net        [wi] Orinoco Classic Gold PC Card Can't Channel Hop
o kern/109308  net        [pppd] [panic] Multiple panics kernel ppp suspected [r
o kern/109251  net        [re] [patch] if_re cardbus card won't attach
o bin/108895   net        pppd(8): PPPoE dead connections on 6.2 [regression]
o kern/108542  net        [bce] Huge network latencies with 6.2-RELEASE / STABLE
o kern/107944  net        [wi] [patch] Forget to unlock mutex-locks
o kern/107850  net        [bce] bce driver link negotiation is faulty
o conf/107035  net        [patch] bridge(8): bridge interface given in rc.conf n
o kern/106438  net        [ipf] ipfilter: keep state does not seem to allow repl
o kern/106316  net        [dummynet] dummynet with multipass ipfw drops packets 
o kern/106243  net        [nve] double fault panic in if_nve.c on high loads
o kern/105945  net        Address can disappear from network interface
s kern/105943  net        Network stack may modify read-only mbuf chain copies
o bin/105925   net        problems with ifconfig(8) and vlan(4) [regression]
o kern/105348  net        [ath] ath device stopps TX
o kern/104851  net        [inet6] [patch] On link routes not configured when usi
o kern/104751  net        [netgraph] kernel panic, when getting info about my tr
o kern/104485  net        [bge] Broadcom BCM5704C: Intermittent on newer chip ve
o kern/103191  net        Unpredictable reboot
o kern/103135  net        [ipsec] ipsec with ipfw divert (not NAT) encodes a pac
o conf/102502  net        [netgraph] [patch] ifconfig name does't rename netgrap
o kern/102035  net        [plip] plip networking disables parallel port printing
o kern/101948  net        [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau
o kern/100709  net        [libc] getaddrinfo(3) should return TTL info
o kern/100519  net        [netisr] suggestion to fix suboptimal network polling
o kern/98978   net        [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel
o kern/98597   net        [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu
o bin/98218    net        wpa_supplicant(8) blacklist not working
f bin/97392    net        ppp(8) hangs instead terminating
o kern/97306   net        [netgraph] NG_L2TP locks after connection with failed 
f kern/96268   net        [socket] TCP socket performance drops by 3000% if pack
o kern/96030   net        [bfe] [patch] Install hangs with Broadcomm 440x NIC in
o kern/95519   net        [ral] ral0 could not map mbuf
o kern/95288   net        [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr
o kern/95277   net        [netinet] [patch] IP Encapsulation mask_match() return
o kern/95267   net        packet drops periodically appear
s kern/94863   net        [bge] [patch] hack to get bge(4) working on IBM e326m
o kern/94162   net        [bge] 6.x kenel stale with bge(4)
o kern/93886   net        [ath] Atheros/D-Link DWL-G650 long delay to associate 
f kern/93378   net        [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo
o kern/93019   net        [ppp] ppp and tunX problems: no traffic after restarti
o kern/92880   net        [libc] [patch] almost rewritten inet_network(3) functi
f kern/92552   net        A serious bug in most network drivers from 5.X to 6.X 
s kern/92279   net        [dc] Core faults everytime I reboot, possible NIC issu
o kern/92090   net        [bge] bge0: watchdog timeout -- resetting
o kern/91859   net        [ndis] if_ndis does not work with Asus WL-138
s kern/91777   net        [ipf] [patch] wrong behaviour with skip rule inside an
o kern/91594   net        [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10
o kern/91364   net        [ral] [wep] WF-511 RT2500 Card PCI and WEP
o kern/91311   net        [aue] aue interface hanging
o kern/90890   net        [vr] Problems with network: vr0: tx shutdown timeout
s kern/90086   net        [hang] 5.4p8 on supermicro P8SCT hangs during boot if 
f kern/88082   net        [ath] [panic] cts protection for ath0 causes panic
o kern/87521   net        [ipf] [panic] using ipfilter "auth" keyword leads to k
o kern/87506   net        [vr] [patch] Fix alias support on vr interfaces
s kern/86920   net        [ndis] ifconfig: SIOCS80211: Invalid argument [regress
o kern/86103   net        [ipf] Illegal NAT Traversal in IPFilter
o kern/85780   net        'panic: bogus refcnt 0' in routing/ipv6
o bin/85445    net        ifconfig(8): deprecated keyword to ifconfig inoperativ
o kern/85266   net        [xe] [patch] xe(4) driver does not recognise Xircom XE
o kern/84202   net        [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre
o bin/82975    net        route change does not parse classfull network as given
o kern/82497   net        [vge] vge(4) on AMD64 only works when loaded late, not
f kern/81644   net        [vge] vge(4) does not work properly when loaded as a K
s kern/81147   net        [net] [patch] em0 reinitialization while adding aliase
o kern/80853   net        [ed] [patch] add support for Compex RL2000/ISA in PnP 
o kern/79895   net        [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 
f kern/79262   net        [dc] Adaptec ANA-6922 not fully supported
o bin/79228    net        [patch] extend arp(8) to be able to create blackhole r
o kern/78090   net        [ipf] ipf filtering on bridged packets doesn't work if
p kern/77913   net        [wi] [patch] Add the APDL-325 WLAN pccard to wi(4)
o kern/77341   net        [ip6] problems with IPV6 implementation
o kern/77273   net        [ipf] ipfilter breaks ipv6 statefull filtering on 5.3
s kern/77195   net        [ipf] [patch] ipfilter ioctl SIOCGNATL does not match 
o kern/75873   net        Usability problem with non-RFC-compliant IP spoof prot
s kern/75407   net        [an] an(4): no carrier after short time
f kern/73538   net        [bge] problem with the Broadcom BCM5788 Gigabit Ethern
o kern/71469   net        default route to internet magically disappears with mu
o kern/70904   net        [ipf] ipfilter ipnat problem with h323 proxy support
o kern/64556   net        [sis] if_sis short cable fix problems with NetGear FA3
s kern/60293   net        [patch] FreeBSD arp poison patch
o kern/54383   net        [nfs] [patch] NFS root configurations without dynamic 
f i386/45773   net        [bge] Softboot causes autoconf failure on Broadcom 570
s bin/41647    net        ifconfig(8) doesn't accept lladdr along with inet addr
s kern/39937   net        ipstealth issue
a kern/38554   net        [patch] changing interface ipaddress doesn't seem to w
o kern/35442   net        [sis] [patch] Problem transmitting runts in if_sis dri
o kern/34665   net        [ipf] [hang] ipfilter rcmd proxy "hangs".
o kern/31647   net        [libc] socket calls can return undocumented EINVAL
o kern/30186   net        [libc] getaddrinfo(3) does not handle incorrect servna
o kern/27474   net        [ipf] [ppp] Interactive use of user PPP and ipfilter c
o conf/23063   net        [arp] [patch] for static ARP tables in rc.network

305 problems total.

From naddy at mips.inka.de  Mon Jul  6 15:01:19 2009
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Mon Jul  6 15:01:27 2009
Subject: NTP - default /etc/ntp.conf
References: <20090702084608.GA59311@roberto-al.eurocontrol.fr>
	<200907020955.aa73037@walton.maths.tcd.ie>
Message-ID: <h2t1pr$28me$1@lorvorc.mips.inka.de>

David Malone <dwmalone@maths.tcd.ie> wrote:

> (Also, we probably really want people to run in orphan mode rather
> than local clock mode, but we can wait a little longer until orphan
> mode is more commonly deployed, IMHO...)

I didn't know about orphan mode, so I had to try it right away.

$ cat /etc/ntp.conf
server 127.127.8.0 mode 14
fudge 127.127.8.0 time1 0.236
tos orphan 5
$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GENERIC(0)      .DCFa.           0 l  27h   64    0    0.000   -1.255   0.793

Shouldn't ntpd have figured out by now that the clock is gone (I
unplugged it yesterday) and have switched into orphan mode?

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

From louie at transsys.com  Mon Jul  6 23:37:02 2009
From: louie at transsys.com (Louis Mamakos)
Date: Mon Jul  6 23:37:10 2009
Subject: NTP - default /etc/ntp.conf
In-Reply-To: <h2t1pr$28me$1@lorvorc.mips.inka.de>
References: <20090702084608.GA59311@roberto-al.eurocontrol.fr>
	<200907020955.aa73037@walton.maths.tcd.ie>
	<h2t1pr$28me$1@lorvorc.mips.inka.de>
Message-ID: <20090706233701.GA30824@ringworld.transsys.com>

On Mon, Jul 06, 2009 at 02:30:19PM +0000, Christian Weisgerber wrote:
> David Malone <dwmalone@maths.tcd.ie> wrote:
> 
> > (Also, we probably really want people to run in orphan mode rather
> > than local clock mode, but we can wait a little longer until orphan
> > mode is more commonly deployed, IMHO...)
> 
> I didn't know about orphan mode, so I had to try it right away.
> 
> $ cat /etc/ntp.conf
> server 127.127.8.0 mode 14
> fudge 127.127.8.0 time1 0.236
> tos orphan 5
> $ ntpq -p
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *GENERIC(0)      .DCFa.           0 l  27h   64    0    0.000   -1.255   0.793
> 
> Shouldn't ntpd have figured out by now that the clock is gone (I
> unplugged it yesterday) and have switched into orphan mode?
> 
> -- 
> Christian "naddy" Weisgerber                          naddy@mips.inka.de

It seems like orphan mode is something that you'd run on an ensemble
of local machines to ensure that they continue to be synchronized with
each other because that's deemed important for some application need.
I don't understand why you'd go to all this trouble on a single host
to simulate NTP clock synchronization when in fact the local clock
isn't synchronized to anything?

If you're concerned about keeping the local clock synchronized to UTC
in the event that your NTP process is partitioned from it's external
NTP peers, then you don't need to do anything.  Once NTP has
determined what you're clock's intrinsic frequency error is, the local
clock model will contnue to apply this frequency correction even in
the absence of external peers providing offset/delay samples.  (This
is the magic number squirreled away in /var/db/ntp.drift, or wherever
it gets put these days.)

louie

From aragon at phat.za.net  Tue Jul  7 03:46:18 2009
From: aragon at phat.za.net (Aragon Gouveia)
Date: Tue Jul  7 03:46:24 2009
Subject: iwn(4) doesn't like hardware RF switches
Message-ID: <4A52C132.5080106@phat.za.net>

Hi,

Is it just me, or does the iwn driver in -CURRENT not play well with 
hardware RF switches on notebooks?  For me the only resemblence of an 
event I see is when I switch off RF - the kernel sends a log to syslog. 
  wpa_supplicant doesn't pick it up, and neither does devd.  The result 
is that I can't keep wpa_supplicant running and let it reassociate when 
I turn off/on, and neither can I start/stop wpa_supplicant from devd 
when I turn on/off.

I guess I could leave the RF switch on and just bind a key shortcut in 
Xorg to start/stop wpa_supplicant, but a standard approach would be 
nice... :)


Thanks,
Aragon


From nvass9573 at gmx.com  Tue Jul  7 09:51:29 2009
From: nvass9573 at gmx.com (Nikos Vassiliadis)
Date: Tue Jul  7 09:51:36 2009
Subject: ndis and USB wirelless ethernet
In-Reply-To: <20090706043747.GD1138@weongyo.cdnetworks.kr>
References: <4A43386D.80500@gmx.com>	<20090625103420.GD31161@weongyo.cdnetworks.kr>	<4A436A8A.1000405@gmx.com>	<20090626041246.GE31161@weongyo.cdnetworks.kr>	<4A461AF9.7040900@gmx.com>	<20090629032520.GA1138@weongyo.cdnetworks.kr>	<4A4880EF.5010206@gmx.com>
	<4A4E2873.3010501@gmx.com>
	<20090706043747.GD1138@weongyo.cdnetworks.kr>
Message-ID: <4A531A94.40701@gmx.com>

Weongyo Jeong wrote:
> I'm happy to see your device is successfully associated with AP.
> However it seems it's a bad news that you sometimes meet crashes.  Does
> a random crash mean a OS hang (e.g. could not type any keys) or no more
> work of network operations?

It hangs, I cannot use the keyboard and I have to power-cycle it.
It can happen after some time downloading and uploading. It hangs
after 5 to 30 minutes of heavy traffic. By heavy traffic, I mean
the maximum I can get from this device, which is 50KBytes/sec.

I am not sure what will happen if I let it idle for, let's say
one day, but I haven't had a single crash during times with
low activity, such as ssh traffic.

> Frankly speaking, for both cases it looks I could not provide any
> solutions without backtraces unless I encountered same problems on my
> environment.  It'd better if we can reproduce its problem easily.

Unfortunately, I have no solid facts to show you. The only strange
thing I've seen and is consistent, is this:

speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; 
sleep 1 ; vmstat -m | grep USBdev
        USBdev    53     4K       -   267579  16,32,128,1024
        USBdev    53     4K       -   267612  16,32,128,1024
        USBdev    53     4K       -   267642  16,32,128,1024
speed#
speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; 
sleep 1 ; vmstat -m | grep USBdev
        USBdev    53     4K       -   268071  16,32,128,1024
        USBdev    53     4K       -   268101  16,32,128,1024
        USBdev    53     4K       -   268140  16,32,128,1024

And then with some traffic:
speed# ping -i 0.01 192.168.1.1 > /dev/null &
[1] 1777
speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; 
sleep 1 ; vmstat -m | grep USBdev
        USBdev    53     4K       -   270249  16,32,128,1024
        USBdev    58     4K       -   271095  16,32,128,1024
        USBdev    56     4K       -   272008  16,32,128,1024
speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; 
sleep 1 ; vmstat -m | grep USBdev
        USBdev    54     4K       -   279649  16,32,128,1024
        USBdev    57     4K       -   280544  16,32,128,1024
        USBdev    54     4K       -   281423  16,32,128,1024

I don't know how relevant is the above, but it seemed strange,
so I am posting it...

> One thing to hang as far as I know is that try to execute `ifconfig down
> && ifconfig up' multiple times.  In NDIS USB support it's recommended
> that `ifconfig up' is executed once.

OK, noted and avoided.

> I think you can try another drivers.

Will do.

> AFAIK this behavior (ASSOC -> RUN) depends on the routine of the link
> status change on NDIS driver that in private experience, some drivers
> doesn't call the link status handler even if it's ready to use or call
> the handler too early which is one of the abnormal.
> 
> So don't know what's going on in NDIS driver currently.

I see.

Thanks again Weongyo for your help, I'll report again
when I'll find some more useful bits about the problem.

Regards, Nikos
From freebsdusb at bindone.de  Tue Jul  7 10:09:01 2009
From: freebsdusb at bindone.de (Michael Gmelin)
Date: Tue Jul  7 10:09:08 2009
Subject: iwn(4) doesn't like hardware RF switches
In-Reply-To: <4A52C132.5080106@phat.za.net>
References: <4A52C132.5080106@phat.za.net>
Message-ID: <4A531E96.4060005@bindone.de>

Aragon Gouveia wrote:
> Hi,
> 
> Is it just me, or does the iwn driver in -CURRENT not play well with
> hardware RF switches on notebooks?  For me the only resemblence of an
> event I see is when I switch off RF - the kernel sends a log to syslog.
>  wpa_supplicant doesn't pick it up, and neither does devd.  The result
> is that I can't keep wpa_supplicant running and let it reassociate when
> I turn off/on, and neither can I start/stop wpa_supplicant from devd
> when I turn on/off.
> 
> I guess I could leave the RF switch on and just bind a key shortcut in
> Xorg to start/stop wpa_supplicant, but a standard approach would be
> nice... :)
> 
> 
> Thanks,
> Aragon
> 
> 
> _______________________________________________
> 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 can confirm this behaviour (+ sometimes iwn gets totally confused by
that). What laptop are you using?


From aragon at phat.za.net  Tue Jul  7 12:42:35 2009
From: aragon at phat.za.net (Aragon Gouveia)
Date: Tue Jul  7 12:42:42 2009
Subject: iwn(4) doesn't like hardware RF switches
In-Reply-To: <3a142e750907070115x737bb9edl7eb1d53708b845d0@mail.gmail.com>
References: <4A52C132.5080106@phat.za.net>
	<3a142e750907070115x737bb9edl7eb1d53708b845d0@mail.gmail.com>
Message-ID: <4A5342B4.5080704@phat.za.net>

Paul B. Mahol wrote:
> The only way to handle hardware RF switch is via devd(8).
> ACPI notify devd(8) about state change and devd than can react on that change.
> iwn(8) can do nothing about this.
> What notebook do you have?

Dell XPS M1330


Thanks,
Aragon
From naddy at mips.inka.de  Tue Jul  7 15:54:07 2009
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Tue Jul  7 15:54:16 2009
Subject: NTP - default /etc/ntp.conf
References: <20090702084608.GA59311@roberto-al.eurocontrol.fr>
	<200907020955.aa73037@walton.maths.tcd.ie>
	<h2t1pr$28me$1@lorvorc.mips.inka.de>
	<20090706233701.GA30824@ringworld.transsys.com>
Message-ID: <h2vr2s$2bf6$1@lorvorc.mips.inka.de>

Louis Mamakos <louie@transsys.com> wrote:

> > Shouldn't ntpd have figured out by now that the clock is gone (I
> > unplugged it yesterday) and have switched into orphan mode?
> 
> It seems like orphan mode is something that you'd run on an ensemble
> of local machines to ensure that they continue to be synchronized with
> each other because that's deemed important for some application need.
> I don't understand why you'd go to all this trouble on a single host
> to simulate NTP clock synchronization when in fact the local clock
> isn't synchronized to anything?

This particular setup is a single server with a bunch of clients.
Even if the server loses its reference clock, the clients should
all continue to have the same time.  If the server reports that it
is unsynchronized, the clients will ignore it and drift apart.

Now, in my test case the server keeps thinking that it is synchronized
to a dead refclock, which is fine for the clients.  But I still
wonder why it didn't switch into orphan mode.

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de

From qing.li at bluecoat.com  Tue Jul  7 16:34:55 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Tue Jul  7 16:35:02 2009
Subject: Slow local TCP transfers on -CURRENT
In-Reply-To: <4A4DF0BC.6090207@freebsd.org>
References: <20090505160145.8C8F18FC15@mx1.freebsd.org>
	<4A4DF0BC.6090207@freebsd.org>
Message-ID: <B583FBF374231F4A89607B4D08578A4304A0AE0F@bcs-mail03.internal.cacheflow.com>

Yes, this was fixed a couple of months ago.

-- Qing

> -----Original Message-----
> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-
> net@freebsd.org] On Behalf Of Lawrence Stewart
> Sent: Friday, July 03, 2009 4:51 AM
> To: Qing Li
> Cc: freebsd-net@freebsd.org; qingli@freebsd.org
> Subject: Re: Slow local TCP transfers on -CURRENT
> 
> Hi Qing,
> 
> Qing Li wrote:
> >> Qing (added to CC) is aware of the problem. Not sure how far
> >> off the fix is.
> >>
> >
> > I am resuming the work on it, hoping to get it verified and
> > finalized in a day or so. Sorry about the delay.
> 
> Did this ever get fixed? I don't think I saw a follow up to this
thread
> so just thought I'd check.
> 
> Cheers,
> Lawrence
> _______________________________________________
> 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"
From jfvogel at gmail.com  Wed Jul  8 00:22:46 2009
From: jfvogel at gmail.com (Jack Vogel)
Date: Wed Jul  8 00:22:54 2009
Subject: Regression: em driver in -CURRENT, "Invalid MAC address"
In-Reply-To: <2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com>
References: <gthe3t$822$1@ger.gmane.org>
	<2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com>
	<h234fa$cob$1@ger.gmane.org>
	<2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com>
	<688430.20427.qm@web37906.mail.mud.yahoo.com>
	<2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com>
Message-ID: <2a41acea0907071722p7992bea0s281399cb0baecd90@mail.gmail.com>

In case you hadn't seen it, the code that fixes this is now checked into
the tip, so the latest em driver should work for you.

Jack


On Sun, Jun 28, 2009 at 9:52 AM, Jack Vogel <jfvogel@gmail.com> wrote:

> Sigh.. both windows and linux have frozen drivers for this old hardware,
> therefore they never see the regressions they cause in the current code :(
>
> I will make a patch for you to test on Monday Mark, it will do the same
> thing
> that I did in the e1000_82540.c, basically change the read_mac function
> back
> to the older way of doing it.
>
> Regards,
>
> Jack
>
>
>
>
> On Sat, Jun 27, 2009 at 10:36 PM, Mark Atkinson <atkin901@yahoo.com>wrote:
>
>>
>>
>> ________________________________
>> >From: Jack Vogel <jfvogel@gmail.com>
>> >Oh, hmmm, so this card is completely broken with the new driver then?
>>
>> Completely, unfortunately (they don't show up in ifconfig, only in
>> dmesg/pciconf).
>>
>> >What was the last working version you used?
>>
>> I was running a kernel from -current May 27th, 2009.   I don't recall
>> any significant em updates between then and when the new driver went
>> in.
>>
>> On Fri, Jun 26, 2009 at 11:36 AM, Mark Atkinson <atkin901@yahoo.com>
>> wrote:
>> Jack Vogel wrote:
>> > I'm willing to bet that its in fact the same problem that VMWare is
>> > having. Our method of getting the mac address changed, and the
>> emulations
>> > seem to be unprepared for it.
>> >
>> > This was done for a real customer requirement to allow support of
>> > alternate mac addressing in firmware. What happens now is a warm reset
>> of
>> > the hardware is done, followed by reading the RAR[0] register. In a real
>> > Intel NIC the mac
>> > address will be valid in that register, but in VMWare, and I'm willing
>> to
>> > bet in
>> > VirtualBox as well, its 0.
>> >
>> > VMWare also has 3 choices of device (wow, amazing coincidence :), can
>> > you tell me when you pick e1000 what real adapter it claims to emulate?
>> >
>> > I am considering options for this problem. The one I lean toward right
>> now
>> > is to make a "legacy" em driver, it will have support for ONLY pre-PCI
>> > Express
>> > hardware, it will be frozen as it were, the idea is that with no new
>> work
>> > on it
>> > it will not suffer from any regression type failures. If I do this,
>> there
>> > are some
>> > strategy issues, and its those I'm thinking about.
>> >
>> > In any case, I intend to have this problem resolved for 8's release.
>> Stay
>> > tuned.
>>
>> Just FYI.  this is a real machine with real cards.  Older fiber cards.
>>
>> em0: <Intel(R) PRO/1000 Network Connection 6.9.14> mem
>> 0xdb000000-0xdb01ffff
>> irq 28 at device 4.0 on pci19
>> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb000000
>>
>> em0: Invalid MAC address
>> device_attach: em0 attach returned 5
>> em1: <Intel(R) PRO/1000 Network Connection 6.9.14> mem
>> 0xdb020000-0xdb03ffff
>> irq 29 at device 9.0 on pci19
>> em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb020000
>>
>> em1: Invalid MAC address
>> device_attach: em1 attach returned 5
>>
>>
>> $ pciconf -v -l |grep -A4 -e "^em"
>> em0@pci0:19:4:0:        class=0x020000 card=0x10008086 chip=0x10008086
>> rev=0x03 hdr=0x00
>>   vendor     = 'Intel Corporation'
>>   device     = '82542 Gigabit Ethernet Controller'
>>   class      = network
>>   subclass   = ethernet
>> em1@pci0:19:9:0:        class=0x020000 card=0x10008086 chip=0x10008086
>> rev=0x03 hdr=0x00
>>   vendor     = 'Intel Corporation'
>>   device     = '82542 Gigabit Ethernet Controller'
>>   class      = network
>>   subclass   = ethernet
>>
>>
>>
>> --
>> Mark Atkinson
>> atkin901@yahoo.com
>> (!wired)?(coffee++):(wired);
>>
>>
>>
>> _______________________________________________
>> 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"
>>
>>
>>
>>
>
From pyunyh at gmail.com  Wed Jul  8 05:00:15 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Jul  8 05:00:22 2009
Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) --
	recovering
Message-ID: <200907080500.n6850FAp036717@freefall.freebsd.org>

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: Pyun YongHyeon <pyunyh@gmail.com>
To: "Dmitry A.Deineka" <ddeineka@gmail.com>
Cc: bug-followup@freebsd.org
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Wed, 8 Jul 2009 13:58:02 +0900

 On Wed, Jul 01, 2009 at 03:59:22PM +0300, Dmitry A.Deineka wrote:
 > Hi,
 > 
 > have same problem, motherboard Asus P5K-VM with marvell yukon onboard:
 > mskc0: <Marvell Yukon 88E8056 Gigabit Ethernet> port 0xd800-0xd8ff mem 
 > 0xfeafc000-0xfeafffff irq 17 at device 0.0 on pci1
 > msk0: <Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x03> on 
 > mskc0
 > msk0: Ethernet address: 00:1e:8c:5e:f8:92
 > 
 > 
 > Problem confirmed with FreeBSD 7.x, now installed 8.0-CURRENT-200906 
 > with the same problem (and the same msk driver, as I see in source).
 > 
 > Patch from Pyun YongHyeon in this PR applied, but it not fix problem. 
 > Downloading large file by ftp from another server causes following:
 > 
 > Jul  1 15:43:58 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:43:58 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:44:00 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:44:38 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:44:38 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:44:40 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:45:03 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:45:03 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:45:05 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:45:28 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:45:28 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:45:30 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:46:07 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:46:07 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:46:09 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:46:24 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:46:24 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:46:26 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:47:07 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:47:07 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:47:09 msktest kernel: msk0: link state changed to UP
 > Jul  1 15:48:33 msktest kernel: msk0: watchdog timeout
 > Jul  1 15:48:33 msktest kernel: msk0: link state changed to DOWN
 > Jul  1 15:48:35 msktest kernel: msk0: link state changed to UP
 > 
 > 
 > Hope this helps.
 > 
 
 I guess you're suffering from difference issues. Support for Yukon
 Ultra was known to be unstable. I had tried hard to address the
 issue but lack of the hardware was major bottle-neck.
 
 Original submitter' hardware is not Yukon Ultra and looks like some
 timing issues related with interrupt level timer, Tx threshold. It
 would be great if original submitter can test previous patch.
 
 > With best regards,
 >   Dmitry
From pyunyh at gmail.com  Wed Jul  8 05:10:06 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Wed Jul  8 05:10:12 2009
Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) --
	recovering
Message-ID: <200907080510.n685A5o7048654@freefall.freebsd.org>

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Andrew Bliznak <andriko.b@gmail.com>
Cc: bug-followup@FreeBSD.org, skylord@linkline.ru
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- recovering
Date: Wed, 8 Jul 2009 14:03:58 +0900

 On Mon, Jul 06, 2009 at 11:00:09AM +0000, Andrew Bliznak wrote:
 > The following reply was made to PR kern/124127; it has been noted by GNATS.
 > 
 > From: Andrew Bliznak <andriko.b@gmail.com>
 > To: bug-followup@FreeBSD.org, skylord@linkline.ru
 > Cc:  
 > Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
 > 	recovering
 > Date: Mon, 6 Jul 2009 13:20:12 +0300
 > 
 >  Same problem with Asus P5BV-C/4L in production.
 >  
 
 Show me dmesg output (msk(4) and e1000phy(4) part) to see what
 controller you have. Due to the diverse Yukon controllers and their
 silicon bugs for each revision it's really hard to tell you're
 seeing the same issue of this PR. Please show me more information.
 
 >  I found desktop with Asus P5LD2 MB and use it for experimental setup.
 >  Three host is same gig switch, msk0 configured with vlans and
 >  ipforwarding
 >  For tests I run iperf -c 192.168.4.21 -t 60000 -w 128k -P 4 between
 >  hosts on different vlans.
 >  7.2-RELEASE kernel with if_msk* from head +patch. Need to specify
 >  ifconfig -vlanhwtag  to run without input errors,
 >  after 30 minutes card locked,  down/up interface not help, need to reboot.
 
 Need to know which controller you have.
 
 >  Next I connect disk witch Ubuntu 9.04, setup vlans, test run ok,
 >  little lover forwarding rate.
 >  After, boot again freebsd, run test. Hmm, test run ok...
 >  Reboot with stock 7.2-REL GENERIC kernel. Box running well over weekend...
 
 This confuse me. So you don't see issues any more?
From sthaug at nethelp.no  Wed Jul  8 12:43:12 2009
From: sthaug at nethelp.no (sthaug@nethelp.no)
Date: Wed Jul  8 12:43:19 2009
Subject: Missing MFC of Silbersack/Klein IP id generation?
Message-ID: <20090708.141630.78743642.sthaug@nethelp.no>

According to the comments for rev. 1.10 of netinet/ip_id.c, from

    http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_id.c

this is to be MFCed after 2 weeks (i.e. 2 weeks after 6. February 2008).

And yet here we are in July 2009, and 7-STABLE shows no sign of this
version of the IP id generation code but instead has the version that
Amit Klein showed had problems,

http://www.trusteer.com/docs/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf

Is this a deliberate choice?

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
From linimon at FreeBSD.org  Wed Jul  8 20:50:52 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Jul  8 20:51:03 2009
Subject: kern/136482: [age] Attansic L1 Gigabit Ethernet recieves
	multicasts only in promisc mode
Message-ID: <200907082050.n68KopEm090538@freefall.freebsd.org>

Synopsis: [age] Attansic L1 Gigabit Ethernet recieves multicasts only in promisc mode

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Jul 8 20:50:44 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136482
From weongyo.jeong at gmail.com  Thu Jul  9 03:47:09 2009
From: weongyo.jeong at gmail.com (Weongyo Jeong)
Date: Thu Jul  9 03:47:16 2009
Subject: ndis and USB wirelless ethernet
In-Reply-To: <4A531A94.40701@gmx.com>
References: <4A43386D.80500@gmx.com>
	<20090625103420.GD31161@weongyo.cdnetworks.kr>
	<4A436A8A.1000405@gmx.com>
	<20090626041246.GE31161@weongyo.cdnetworks.kr>
	<4A461AF9.7040900@gmx.com>
	<20090629032520.GA1138@weongyo.cdnetworks.kr>
	<4A4880EF.5010206@gmx.com> <4A4E2873.3010501@gmx.com>
	<20090706043747.GD1138@weongyo.cdnetworks.kr>
	<4A531A94.40701@gmx.com>
Message-ID: <20090709023651.GA1553@weongyo.cdnetworks.kr>

On Tue, Jul 07, 2009 at 12:51:16PM +0300, Nikos Vassiliadis wrote:
> Weongyo Jeong wrote:
> >I'm happy to see your device is successfully associated with AP.
> >However it seems it's a bad news that you sometimes meet crashes.  Does
> >a random crash mean a OS hang (e.g. could not type any keys) or no more
> >work of network operations?
> 
> It hangs, I cannot use the keyboard and I have to power-cycle it.
> It can happen after some time downloading and uploading. It hangs
> after 5 to 30 minutes of heavy traffic. By heavy traffic, I mean
> the maximum I can get from this device, which is 50KBytes/sec.
> 
> I am not sure what will happen if I let it idle for, let's say
> one day, but I haven't had a single crash during times with
> low activity, such as ssh traffic.
> 
> >Frankly speaking, for both cases it looks I could not provide any
> >solutions without backtraces unless I encountered same problems on my
> >environment.  It'd better if we can reproduce its problem easily.
> 
> Unfortunately, I have no solid facts to show you. The only strange
> thing I've seen and is consistent, is this:
> 
> speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; 
> sleep 1 ; vmstat -m | grep USBdev
>        USBdev    53     4K       -   267579  16,32,128,1024
>        USBdev    53     4K       -   267612  16,32,128,1024
>        USBdev    53     4K       -   267642  16,32,128,1024
> speed#
> speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; 
> sleep 1 ; vmstat -m | grep USBdev
>        USBdev    53     4K       -   268071  16,32,128,1024
>        USBdev    53     4K       -   268101  16,32,128,1024
>        USBdev    53     4K       -   268140  16,32,128,1024
> 
> And then with some traffic:
> speed# ping -i 0.01 192.168.1.1 > /dev/null &
> [1] 1777
> speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; 
> sleep 1 ; vmstat -m | grep USBdev
>        USBdev    53     4K       -   270249  16,32,128,1024
>        USBdev    58     4K       -   271095  16,32,128,1024
>        USBdev    56     4K       -   272008  16,32,128,1024
> speed# vmstat -m | grep USBdev ; sleep 1 ; vmstat -m | grep USBdev ; 
> sleep 1 ; vmstat -m | grep USBdev
>        USBdev    54     4K       -   279649  16,32,128,1024
>        USBdev    57     4K       -   280544  16,32,128,1024
>        USBdev    54     4K       -   281423  16,32,128,1024
> 
> I don't know how relevant is the above, but it seemed strange,
> so I am posting it...

It's a normal case that in implementation it allocates a memory buffer
for transactions.  So if it increases without any reduction it'd be a
problem.

regards,
Weongyo Jeong

From jhein at timing.com  Thu Jul  9 04:27:51 2009
From: jhein at timing.com (John Hein)
Date: Thu Jul  9 04:28:08 2009
Subject: network lock manager (lockd) deadlocked in 'rpcrecv'
In-Reply-To: <19029.5367.534192.928426@gromit.timing.com>
References: <19029.4145.296260.915327@gromit.timing.com>
	<19029.5367.534192.928426@gromit.timing.com>
Message-ID: <19029.9551.628427.146587@gromit.timing.com>

John Hein wrote at 15:51 -0600 on Jul  8, 2009:
 > John Hein wrote at 15:31 -0600 on Jul  8, 2009:
 >  > I have a home directory on FreeBSD 7.2-stable (20090705), amd64.
 >  > It is serving up the directory over nfs (v3, tcp), and now
 >  > I'm seeing lots of 'lockd not responding' on Fedora 10 & 11 systems.
  .
  .
 > Also in dmesg:
 > 
 > NLM: failed to contact remote rpcbind, stat = 5, port = 28416
  .
  .

Here's some good information.  This seems to happen when there are 2
or more Fedora systems trying to access locks via lockd.

Rebooting the Fedora box that has 'lockd not responding' frees
up the deadlocked freebsd lockd.

But _also_ disabling the firewall on the Fedora boxes helps, too.

This doesn't necessarily completely implicate or exonerate
lockd.  But what should lockd do when the remote box asks
for a lock, but doesn't complete the RPC dialog?  Is there
a way we can deal with this problem and not have lockd
deadlock?
From jhein at timing.com  Thu Jul  9 04:27:53 2009
From: jhein at timing.com (John Hein)
Date: Thu Jul  9 04:28:09 2009
Subject: network lock manager (lockd) deadlocked in 'rpcrecv'
Message-ID: <19029.4145.296260.915327@gromit.timing.com>

I have a home directory on FreeBSD 7.2-stable (20090705), amd64.
It is serving up the directory over nfs (v3, tcp), and now
I'm seeing lots of 'lockd not responding' on Fedora 10 & 11 systems.

USER    PID  PPID   SID NI %CPU %MEM   VSZ   RSS  TT  WCHAN  STAT STARTED      TIME COMMAND
root    791     1   791  0  0.0  0.0  6748  1500  ??  rpcrec Ds    2:45PM   0:05.80 /usr/sbin/rpc.lockd

Once lockd gets in this state, doing a test lock on a file
from a FreeBSD box locks with 'lockd not responding', too
(and ctrl-c and kill -9 does nothing).

USER         PID  PPID   SID NI %CPU %MEM   VSZ   RSS  TT  WCHAN  STAT STARTED      TIME COMMAND
jhein       6297  3491  3491  0  0.0  0.0  1412   604  p5  nlmrcv T+    3:18PM   0:00.00 /h/jhein/nfslocktest /nfs/locktest


I see this on an i386 6.4-stable, too.
From jhein at timing.com  Thu Jul  9 04:27:54 2009
From: jhein at timing.com (John Hein)
Date: Thu Jul  9 04:28:10 2009
Subject: network lock manager (lockd) deadlocked in 'rpcrecv'
In-Reply-To: <19029.4145.296260.915327@gromit.timing.com>
References: <19029.4145.296260.915327@gromit.timing.com>
Message-ID: <19029.5367.534192.928426@gromit.timing.com>

John Hein wrote at 15:31 -0600 on Jul  8, 2009:
 > I have a home directory on FreeBSD 7.2-stable (20090705), amd64.
 > It is serving up the directory over nfs (v3, tcp), and now
 > I'm seeing lots of 'lockd not responding' on Fedora 10 & 11 systems.
 > 
 > USER    PID  PPID   SID NI %CPU %MEM   VSZ   RSS  TT  WCHAN  STAT STARTED      TIME COMMAND
 > root    791     1   791  0  0.0  0.0  6748  1500  ??  rpcrec Ds    2:45PM   0:05.80 /usr/sbin/rpc.lockd
 > 
 > Once lockd gets in this state, doing a test lock on a file
 > from a FreeBSD box locks with 'lockd not responding', too
 > (and ctrl-c and kill -9 does nothing).
 > 
 > USER         PID  PPID   SID NI %CPU %MEM   VSZ   RSS  TT  WCHAN  STAT STARTED      TIME COMMAND
 > jhein       6297  3491  3491  0  0.0  0.0  1412   604  p5  nlmrcv T+    3:18PM   0:00.00 /h/jhein/nfslocktest /nfs/locktest
 > 
 > 
 > I see this on an i386 6.4-stable, too.

Also in dmesg:

NLM: failed to contact remote rpcbind, stat = 5, port = 28416


And from ddb...

Tracing command rpc.lockd pid 791 tid 100176 td 0xffffff00069dd720
sched_switch() at 0xffffffff8037df95 = sched_switch+0x1d5
mi_switch() at 0xffffffff803656fb = mi_switch+0x18b
sleepq_timedwait() at 0xffffffff80390aeb = sleepq_timedwait+0x3b
_sleep() at 0xffffffff80365cd4 = _sleep+0x324
clnt_dg_call() at 0xffffffff80504a0b = clnt_dg_call+0x4fb
nlm_get_rpc() at 0xffffffff804f3ef7 = nlm_get_rpc+0x147
nlm_host_get_rpc() at 0xffffffff804f430e = nlm_host_get_rpc+0x10e
nlm_do_lock() at 0xffffffff804f58be = nlm_do_lock+0x1ce
nlm4_lock_4_svc() at 0xffffffff804f6c91 = nlm4_lock_4_svc+0x11
nlm_prog_4() at 0xffffffff804f8098 = nlm_prog_4+0x308
svc_run() at 0xffffffff8050c1f3 = svc_run+0x293
nlm_syscall() at 0xffffffff804f675c = nlm_syscall+0x79c
syscall() at 0xffffffff805818f4 = syscall+0x1b4
Xfast_syscall() at 0xffffffff8056d35b = Xfast_syscall+0xab
--- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x8008a91ec, rsp = 0x7fffffffed08, rbp = 0x7fffffffe
e20 ---

From dwmalone at maths.tcd.ie  Thu Jul  9 09:20:41 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Thu Jul  9 09:20:49 2009
Subject: NTP - default /etc/ntp.conf 
In-Reply-To: Your message of "Thu, 02 Jul 2009 10:46:08 +0200."
	<20090702084608.GA59311@roberto-al.eurocontrol.fr> 
Message-ID: <200907091020.aa42546@walton.maths.tcd.ie>

The NTP pool guys have set up our vendor domain. I'd like to commit
the patch below to ntp.conf. It does the following:

	1) Uses our vendor domain at the pool.
	2) Points people at the pool website and encourages
	   people to provide a server in the pool (as a
	   courtesy to the pool guys).
	3) Fixes a spelling.
	4) Comments out the local clock and includes a link
	   to documentation for use of the local clock on
	   the ntp.org site.

If there are no objections, I'll ask re@ for permission to commit
this.

	David.

Index: ntp.conf
===================================================================
--- ntp.conf    (revision 195484)
+++ ntp.conf    (working copy)
@@ -13,19 +13,22 @@
 #
 # The following three servers will give you a random set of three
 # NTP servers geographically close to you.
-# See http://en.wikipedia.org/wiki/NTP_pool for details.
+# See http://www.pool.ntp.org/ for details. Note, the pool encourages
+# users with a static IP and good upstream NTP servers to add a server
+# to the pool. See http://www.pool.ntp.org/join.html if you are interested.
 #
 # The option `iburst' is used for faster initial synchronisation.
 # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD.
 #
-server 0.pool.ntp.org iburst maxpoll 9
-server 1.pool.ntp.org iburst maxpoll 9
-server 2.pool.ntp.org iburst maxpoll 9
+server 0.freebsd.pool.ntp.org iburst maxpoll 9
+server 1.freebsd.pool.ntp.org iburst maxpoll 9
+server 2.freebsd.pool.ntp.org iburst maxpoll 9
+#server 3.freebsd.pool.ntp.org iburst maxpoll 9
 
 #
 # If you want to pick yourself which country's public NTP server
 # you want sync against, comment out the above servers, uncomment
-# the next ones and replace CC with the country's abbrevation.
+# the next ones and replace CC with the country's abbreviation.
 # Make sure that the hostnames resolve to a proper IP address!
 #
 # server 0.CC.pool.ntp.org iburst maxpoll 9
@@ -50,10 +53,12 @@
 #restrict 127.127.1.0
 
 #
-# If we lose sync against all configured servers, the NTP clients
-# syncing against this server will lose sync too. To overcome this,
-# we will act as a stratum 10 server with our own internal clock
-# so that everybody at least will have the same time as we have.
+# If a server loses sync with all upstream servers, NTP clients
+# no longer follow that server. The local clock can be configured
+# to provide a time source when this happens, but it should usually
+# be configured on just one server on a network. For more details see
+# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock
+# The use of Orphan Mode may be preferable.
 #
-server 127.127.1.0
-fudge 127.127.1.0 stratum 10
+#server 127.127.1.0
+#fudge 127.127.1.0 stratum 10

From roberto at keltia.freenix.fr  Thu Jul  9 09:27:09 2009
From: roberto at keltia.freenix.fr (Ollivier Robert)
Date: Thu Jul  9 09:27:17 2009
Subject: NTP - default /etc/ntp.conf
In-Reply-To: <200907091020.aa42546@walton.maths.tcd.ie>
References: <20090702084608.GA59311@roberto-al.eurocontrol.fr>
	<200907091020.aa42546@walton.maths.tcd.ie>
Message-ID: <20090709092700.GA64721@roberto-al.eurocontrol.fr>

According to David Malone:
> The NTP pool guys have set up our vendor domain. I'd like to commit
> the patch below to ntp.conf. It does the following:

Approval from me, thanks.

-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr
In memoriam to Ondine : http://ondine.keltia.net/

From andriko.b at gmail.com  Thu Jul  9 11:50:03 2009
From: andriko.b at gmail.com (Andrew Bliznak)
Date: Thu Jul  9 11:50:20 2009
Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
	recovering
Message-ID: <200907091150.n69Bo385069459@freefall.freebsd.org>

The following reply was made to PR kern/124127; it has been noted by GNATS.

From: Andrew Bliznak <andriko.b@gmail.com>
To: pyunyh@gmail.com
Cc: bug-followup@freebsd.org
Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) -- 
	recovering
Date: Thu, 9 Jul 2009 14:48:12 +0300

 2009/7/8 Pyun YongHyeon <pyunyh@gmail.com>:
 > On Mon, Jul 06, 2009 at 11:00:09AM +0000, Andrew Bliznak wrote:
 >> The following reply was made to PR kern/124127; it has been noted by GNA=
 TS.
 >>
 >> From: Andrew Bliznak <andriko.b@gmail.com>
 >> To: bug-followup@FreeBSD.org, skylord@linkline.ru
 >> Cc:
 >> Subject: Re: kern/124127: [msk] watchdog timeout (missed Tx interrupts) =
 --
 >> =A0 =A0 =A0 recovering
 >> Date: Mon, 6 Jul 2009 13:20:12 +0300
 >>
 >> =A0Same problem with Asus P5BV-C/4L in production.
 >>
 >
 > Show me dmesg output (msk(4) and e1000phy(4) part) to see what
 > controller you have. Due to the diverse Yukon controllers and their
 > silicon bugs for each revision it's really hard to tell you're
 > seeing the same issue of this PR. Please show me more information.
 >
 
 mskc0: <Marvell Yukon 88E8056 Gigabit Ethernet> port 0xd800-0xd8ff mem
 0xfbefc000-0xfbefffff irq 18 at device 0.0 on pci5
 msk0: <Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x03> on ms=
 kc0
 msk0: Ethernet address: 00:22:15:ef:02:06
 miibus0: <MII bus> on msk0
 e1000phy0: <Marvell 88E1149 Gigabit PHY> PHY 0 on miibus0
 e1000phy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX,=
  auto
 mskc0: [FILTER]
 
 Huh, yes, it's different problem, which bug number for this?
 
 >> =A0I found desktop with Asus P5LD2 MB and use it for experimental setup.
 >> =A0Three host is same gig switch, msk0 configured with vlans and
 >> =A0ipforwarding
 >> =A0For tests I run iperf -c 192.168.4.21 -t 60000 -w 128k -P 4 between
 >> =A0hosts on different vlans.
 >> =A07.2-RELEASE kernel with if_msk* from head +patch. Need to specify
 >> =A0ifconfig -vlanhwtag =A0to run without input errors,
 >> =A0after 30 minutes card locked, =A0down/up interface not help, need to =
 reboot.
 >
 > Need to know which controller you have.
 >
 
 mskc0: <Marvell Yukon 88E8053 Gigabit Ethernet> port 0xc800-0xc8ff mem
 0xcbffc000-0xcbffffff irq 19 at device 0.0 on pci2
 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xcbffc000
 mskc0: MSI count : 2
 mskc0: attempting to allocate 2 MSI vectors (2 supported)
 mskc0: using IRQs 256-257 for MSI
 mskc0: RAM buffer size : 48KB
 mskc0: Port 0 : Rx Queue 32KB(0x00000000:0x00007fff)
 mskc0: Port 0 : Tx Queue 16KB(0x00008000:0x0000bfff)
 msk0: <Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02> on mskc0
 msk0: bpf attached
 msk0: Ethernet address: 00:17:31:bd:1a:64
 miibus0: <MII bus> on msk0
 mskc0: [MPSAFE]
 mskc0: [FILTER]
 mskc0: Uncorrectable PCI Express error
 msk0: link state changed to UP
 
 
 >> =A0Next I connect disk witch Ubuntu 9.04, setup vlans, test run ok,
 >> =A0little lover forwarding rate.
 >> =A0After, boot again freebsd, run test. Hmm, test run ok...
 >> =A0Reboot with stock 7.2-REL GENERIC kernel. Box running well over weeke=
 nd...
 >
 > This confuse me. So you don't see issues any more?
 >
 
 Yes.
 
 I instaled 8.0-BETA1-amd64 on this box, rerun tests, all ok.
 Also try clear CMOS from BIOS - no change. Next, I reflash BIOS from disket=
 te
 and problem returns.
 Build new kernel with patch-2.diff, now test run ok.
 Rebuild kernel without patch, and this time msk works.
 Look like very strange HW, but patch obviously helped.
From nvass9573 at gmx.com  Thu Jul  9 12:09:34 2009
From: nvass9573 at gmx.com (Nikos Vassiliadis)
Date: Thu Jul  9 12:09:41 2009
Subject: localhost routes are not displayed when using multiple routing
	tables
Message-ID: <4A55DDE8.9090808@gmx.com>

Hello,

I noticed this:
> speed# netstat -rnfinet
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags    Refs      Use  Netif Expire
> 127.0.0.1          link#4             UH          0        0    lo0
> 192.168.1.0/24     link#6             U           1      193  wlan0
> 192.168.1.6        link#4             UHS         0        0    lo0

> speed# setfib 1 netstat -rnfinet
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags    Refs      Use  Netif Expire
> 127.0.0.1          link#4             UH          0        0    lo0
> 192.168.1.0/24     link#6             U           0        0  wlan0
> speed#

The routing entry for 192.168.1.6 is missing from the second
routing table. 192.168.1.6 is actually routed through lo0 on
every FIB. But, for formality reasons, shouldn't it be there,
appearing when one examines the routing table?

Nikos
From lconrad at Go2France.com  Thu Jul  9 14:19:12 2009
From: lconrad at Go2France.com (Len Conrad)
Date: Thu Jul  9 14:19:19 2009
Subject: (no subject)
Message-ID: <200907091540.AA316473920@mail.Go2France.com>

uname -a

FreeBSD xxx 7.1-RELEASE FreeBSD 7.1-RELEASE #0

kldstat

Id Refs Address    Size     Name
 1    5 0xc0400000 97f830   kernel
 2    1 0xc0d80000 ff18     iscsi_initiator.ko
 3    1 0xc0d90000 6a2c4    acpi.ko


iscontrol doesn't have -V version and strings doesn't find anything that looks like a version.


iscontrol -d -v -t 192.168.78.5 
                    port = 3260
                    tags = 0
                 maxluns = 0
                     iqn = iqn.2005-01.il.ac.huji.cs:
          maxConnections = 1
maxRecvDataSegmentLength = 65536
maxXmitDataSegmentLength = 65536
          maxBurstLength = 131072
        firstBurstLength = 65536
        defaultTime2Wait = 0
      defaultTime2Retain = 0
       maxOutstandingR2T = 1
      errorRecoveryLevel = 0
    targetPortalGroupTag = 0
            headerDigest = None,CRC32C
              dataDigest = None,CRC32C
              initialR2T = 1
           immediateData = 1
          dataPDUInOrder = 1
     dataSequenceInOrder = 1
             sessionType = Normal
           targetAddress = (null)
             targetAlias = (null)
              targetName = (null)
           initiatorName = (null)
          initiatorAlias = (null)
              authMethod = None
              chapSecret = (null)
               chapIName = (null)
             tgtChapName = (null)
           tgtChapSecret = (null)
      tgttgtChallengeLen = 0
I-: cmd=0x3 len=301
        SessionType=Discovery
        InitiatorName=iqn.2005-01.il.ac.huji.cs::mr1.xxxx.net
        MaxBurstLength=131072
        HeaderDigest=None,CRC32C
        DataDigest=None,CRC32C
        MaxRecvDataSegmentLength=65536
        ErrorRecoveryLevel=0
        DefaultTime2Wait=0
        DefaultTime2Retain=0
        DataPDUInOrder=Yes
        DataSequenceInOrder=Yes
        MaxOutstandingR2T=1
T-: cmd=0x23 len=281
        TargetPortalGroupTag=0
        TargetAlias=1576.b3
        HeaderDigest=None
        DataDigest=None
        MaxRecvDataSegmentLength=65536
        MaxBurstLength=Irrelevant
        DefaultTime2Wait=0
        DefaultTime2Retain=0
        MaxOutstandingR2T=Irrelevant
        DataPDUInOrder=Irrelevant
        DataSequenceInOrder=Irrelevant
        ErrorRecoveryLevel=0

I-: cmd=0x4 len=16
        SendTargets=All
recvpdu: Socket is not connected
recvpdu failed

I-: cmd=0x6 len=0
recvpdu: Socket is not connected
recvpdu failed

==========

initatator does work into a FreeBSD/iscsi-target:


# iscontrol -c /etc/iscsi.conf -n target0

iscontrol[817]: running
iscontrol[817]: (pass3:iscsi0:0:0:0):  tagged openings now 0
iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:1
iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:2
iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:3
iscontrol: supervise starting main loop

#ll /dev/is*
crw-------  1 root  wheel    0,  27 Jul  8 13:29 /dev/iscsi
crw-------  1 root  wheel    0, 103 Jul  8 13:29 /dev/iscsi0

#ll /dev/da*
crw-r-----  1 root  operator    0,  90 Jul  8 13:29 /dev/da0
crw-r-----  1 root  operator    0,  91 Jul  8 13:29 /dev/da0s1
crw-r-----  1 root  operator    0,  92 Jul  8 08:30 /dev/da0s1a
crw-r-----  1 root  operator    0,  93 Jul  8 13:30 /dev/da0s1b
crw-r-----  1 root  operator    0,  94 Jul  8 13:29 /dev/da0s1c
crw-r-----  1 root  operator    0,  95 Jul  8 08:29 /dev/da0s1d
crw-r-----  1 root  operator    0,  96 Jul  8 08:29 /dev/da0s1e
crw-r-----  1 root  operator    0, 105 Jul  8 13:29 /dev/da1
crw-r-----  1 root  operator    0, 106 Jul  8 13:29 /dev/da1s1
crw-r-----  1 root  operator    0, 107 Jul  8 13:29 /dev/da1s1c
crw-r-----  1 root  operator    0, 108 Jul  8 13:29 /dev/da1s1d

#mount /dev/da1s1 /iscsitest/

#df
Filesystem  1K-blocks    Used    Avail Capacity  Mounted on
/dev/da0s1a  10154158  141662  9200164     2%    /
devfs               1       1        0   100%    /dev
/dev/da0s1d  20308398 1393604 17290124     7%    /usr
/dev/da0s1e  40622090  292054 37080270     1%    /var
/dev/da1s1    9907690 2990276  6124800    33%    /iscsitest

=========

Red Hat Enterprise iscsi initiator connects to EMC SAN target reliably.

If we can't get the FreeBSD iniatator working, we'll have to convert several machines from FreeBSD to Linux.

Len


From sam at FreeBSD.org  Thu Jul  9 15:23:13 2009
From: sam at FreeBSD.org (sam@FreeBSD.org)
Date: Thu Jul  9 15:23:20 2009
Subject: kern/132715: [lagg] [panic] Panic when creating vlan's on lagg
	interface
Message-ID: <200907091523.n69FNDf6038283@freefall.freebsd.org>

Synopsis: [lagg] [panic] Panic when creating vlan's on lagg interface

Responsible-Changed-From-To: freebsd-net->jfv
Responsible-Changed-By: sam
Responsible-Changed-When: Thu Jul 9 15:22:48 UTC 2009
Responsible-Changed-Why: 
this is really a driver issue

http://www.freebsd.org/cgi/query-pr.cgi?pr=132715
From silby at silby.com  Thu Jul  9 16:38:15 2009
From: silby at silby.com (Mike Silbersack)
Date: Thu Jul  9 16:38:28 2009
Subject: Missing MFC of Silbersack/Klein IP id generation?
In-Reply-To: <20090708.141630.78743642.sthaug@nethelp.no>
References: <20090708.141630.78743642.sthaug@nethelp.no>
Message-ID: <alpine.BSF.1.00.0907091208320.26293@niwun.pair.com>



On Wed, 8 Jul 2009, sthaug@nethelp.no wrote:

> According to the comments for rev. 1.10 of netinet/ip_id.c, from
>
>    http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_id.c
>
> this is to be MFCed after 2 weeks (i.e. 2 weeks after 6. February 2008).
>
> And yet here we are in July 2009, and 7-STABLE shows no sign of this
> version of the IP id generation code but instead has the version that
> Amit Klein showed had problems,
>
> http://www.trusteer.com/docs/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf
>
> Is this a deliberate choice?
>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no

This is a case of me losing track of time and not getting around to the 
merge.  As far as I know the code in question works properly.  I will try 
to merge it soon.  If another committer would like to handle the merge for 
me to get it done sooner, please speak up. :)

Sorry for the delay,

Mike "Silby" Silbersack
From mailing at gaturkey.com  Thu Jul  9 16:38:42 2009
From: mailing at gaturkey.com (Global Access Travel)
Date: Thu Jul  9 16:38:49 2009
Subject: Fam Trip to TURKEY for $999 (Refundable)
Message-ID: <4160ebbac2875aa5a278057632084b8f@localhost.localdomain>

[http://www.turkeycallingus.com/]

Exclusive Boutique Enterprise

Turkey FAM
ISTANBUL - CAPPADOCIA - KONYA - ANTALYA - PAMUKKALE - KUSADASI
9 Nights / 11 Days  $999

? 5 Continents ? 150 Countries Worldwide ? 100.000 Hotels ?
Instant Confirmation

[http://www.turkeycallingus.com]

[http://www.turkeycallingus.com/turkey-fam/TurkeyFam.htm]
[http://www.turkeycallingus.com/turkey-fam/TurkeyFamItinerary.htm]
[http://www.turkeycallingus.com/turkey-fam/TurkeyFamRates.htm]
[http://www.turkeycallingus.com/turkey-fam/TurkeyFamServices.htm]
[http://www.turkeycallingus.com/turkey-fam/TurkeyFamHotels.htm]

Global Access proudly presents the biggest FAM Trip of the year, teaming
with Turkish Airlines and Turkish Ministry of Tourism and Culture.

As the host of ASTA IDE 2010 and European Capital of Culture 2010, Turkey
is likely to be the one of the most popular destinations in 2010. Those who
act early and get to know this beautiful country better will be able to
give a better insight to their clients and secure more bookings.

Our specially selected travel agents will stay in best hotels in each
town, be escorted by professional, top tour guides, taste exceptionally
good examples of Turkish Cuisine, and get to know Turkey in elegant way.

Join us for a luxury FAM adventure and be our special guest in our
beautiful country!

COMBINE WITH World Travel Market!

One of the biggest travel shows of Europe and the world, WTM, will be
held in London between 9-12 November 2009. Combine your London trip with
Turkey and benefit from great agent rates to see one of the most popular
tourist destinations from USA and Canada.
WE WILL REFUND YOUR MONEY BACK !

Upon booking your 20th passenger on a Global Access Travel Service, we
will refund you the whole tour price that you?ve paid for the FAM Trip.

If you book 20 or more people on a Global Access Travel Service before
the FAM Trip starts, then you will travel for free!

About Us Global Access Travel (GA) was founded in Turkey by a group of
tourism professionals and marketing experts who recognized the needs to
offer online services for accommodations, car rentals, and other travel
related services to travel agencies.
Through its sophisticated online reservation services, GA offers more
than 100,000 hotels, motels, resorts, clubs and apartments all around the
world.
Other services of GA include car rentals, transfers, special tours,
luxury services, city breaks, flight tickets and other services such as
tailor made tour packages, exhibition organizations, incentives and other
travel related services around the globe at competitive rates.

[http://www.TurkeyCallingus.com] www.TurkeyCalling.us
[http://www.turkeycallingus.com/turkey-calling-contact-us.htm]

Global Access Travel
Tel: +90 212 258 58 29 Fax: +90 212 258 34 47
E-mail : [mailto:incoming@gaturkey.com] incoming@gaturkey.com   Website:
[http://www.turkeycallingus.com/] www.TurkeyCalling.Us
This message was sent by: FamTrit turkey, N?zhetiye Cad., istanbul, besiktas 34357, Turkey

To be removed click here:
http://app.icontact.com/icp/mmail-mprofile.pl?r=47129461&l=82243&s=V4MA&m=578549&c=305227

Forward to a friend: 
http://app.icontact.com/icp/sub/forward?m=578549&s=47129461&c=V4MA&cid=305227


From mailing at gaturkey.com  Thu Jul  9 16:49:18 2009
From: mailing at gaturkey.com (Global Access Travel)
Date: Thu Jul  9 16:49:24 2009
Subject: Fam Trip to TURKEY for $999 (Refundable)
Message-ID: <d1a2f20799dfb653ac0a9bf767609a1c@localhost.localdomain>

[http://www.turkeycallingus.com/]

Exclusive Boutique Enterprise

Turkey FAM
ISTANBUL - CAPPADOCIA - KONYA - ANTALYA - PAMUKKALE - KUSADASI
9 Nights / 11 Days  $999

? 5 Continents ? 150 Countries Worldwide ? 100.000 Hotels ?
Instant Confirmation

[http://www.turkeycallingus.com]

[http://www.turkeycallingus.com/turkey-fam/TurkeyFam.htm]
[http://www.turkeycallingus.com/turkey-fam/TurkeyFamItinerary.htm]
[http://www.turkeycallingus.com/turkey-fam/TurkeyFamRates.htm]
[http://www.turkeycallingus.com/turkey-fam/TurkeyFamServices.htm]
[http://www.turkeycallingus.com/turkey-fam/TurkeyFamHotels.htm]

Global Access proudly presents the biggest FAM Trip of the year, teaming
with Turkish Airlines and Turkish Ministry of Tourism and Culture.

As the host of ASTA IDE 2010 and European Capital of Culture 2010, Turkey
is likely to be the one of the most popular destinations in 2010. Those who
act early and get to know this beautiful country better will be able to
give a better insight to their clients and secure more bookings.

Our specially selected travel agents will stay in best hotels in each
town, be escorted by professional, top tour guides, taste exceptionally
good examples of Turkish Cuisine, and get to know Turkey in elegant way.

Join us for a luxury FAM adventure and be our special guest in our
beautiful country!

COMBINE WITH World Travel Market!

One of the biggest travel shows of Europe and the world, WTM, will be
held in London between 9-12 November 2009. Combine your London trip with
Turkey and benefit from great agent rates to see one of the most popular
tourist destinations from USA and Canada.
WE WILL REFUND YOUR MONEY BACK !

Upon booking your 20th passenger on a Global Access Travel Service, we
will refund you the whole tour price that you?ve paid for the FAM Trip.

If you book 20 or more people on a Global Access Travel Service before
the FAM Trip starts, then you will travel for free!

About Us Global Access Travel (GA) was founded in Turkey by a group of
tourism professionals and marketing experts who recognized the needs to
offer online services for accommodations, car rentals, and other travel
related services to travel agencies.
Through its sophisticated online reservation services, GA offers more
than 100,000 hotels, motels, resorts, clubs and apartments all around the
world.
Other services of GA include car rentals, transfers, special tours,
luxury services, city breaks, flight tickets and other services such as
tailor made tour packages, exhibition organizations, incentives and other
travel related services around the globe at competitive rates.

[http://www.TurkeyCallingus.com] www.TurkeyCalling.us
[http://www.turkeycallingus.com/turkey-calling-contact-us.htm]

Global Access Travel
Tel: +90 212 258 58 29 Fax: +90 212 258 34 47
E-mail : [mailto:incoming@gaturkey.com] incoming@gaturkey.com   Website:
[http://www.turkeycallingus.com/] www.TurkeyCalling.Us
This message was sent by: FamTrit turkey, N?zhetiye Cad., istanbul, besiktas 34357, Turkey

To be removed click here:
http://app.icontact.com/icp/mmail-mprofile.pl?r=47130731&l=82243&s=F9IT&m=578549&c=305227

Forward to a friend: 
http://app.icontact.com/icp/sub/forward?m=578549&s=47130731&c=F9IT&cid=305227


From linimon at FreeBSD.org  Thu Jul  9 18:27:01 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Thu Jul  9 18:27:07 2009
Subject: kern/136618: [pf][stf] panic on cloning interface without unit
	number, e.g. `stf'
Message-ID: <200907091827.n69IR0Sl084730@freefall.freebsd.org>

Synopsis: [pf][stf] panic on cloning interface without unit number, e.g. `stf'

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Jul 9 18:26:44 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136618
From brian at Awfulhak.org  Thu Jul  9 18:33:21 2009
From: brian at Awfulhak.org (Brian Somers)
Date: Thu Jul  9 18:33:27 2009
Subject: NTP - default /etc/ntp.conf
In-Reply-To: <200907091020.aa42546@walton.maths.tcd.ie>
References: <20090702084608.GA59311@roberto-al.eurocontrol.fr>
	<200907091020.aa42546@walton.maths.tcd.ie>
Message-ID: <20090709110323.6106a0f3@Awfulhak.org>

On Thu, 09 Jul 2009 10:20:29 +0100, David Malone <dwmalone@maths.tcd.ie> wrote:
> The NTP pool guys have set up our vendor domain. I'd like to commit
> the patch below to ntp.conf. It does the following:
> 
> 	1) Uses our vendor domain at the pool.
> 	2) Points people at the pool website and encourages
> 	   people to provide a server in the pool (as a
> 	   courtesy to the pool guys).
> 	3) Fixes a spelling.
> 	4) Comments out the local clock and includes a link
> 	   to documentation for use of the local clock on
> 	   the ntp.org site.
> 
> If there are no objections, I'll ask re@ for permission to commit
> this.
> 
> 	David.
> 
> Index: ntp.conf
> ===================================================================
> --- ntp.conf    (revision 195484)
> +++ ntp.conf    (working copy)
> @@ -13,19 +13,22 @@
>  #
>  # The following three servers will give you a random set of three
>  # NTP servers geographically close to you.
> -# See http://en.wikipedia.org/wiki/NTP_pool for details.
> +# See http://www.pool.ntp.org/ for details. Note, the pool encourages
> +# users with a static IP and good upstream NTP servers to add a server
> +# to the pool. See http://www.pool.ntp.org/join.html if you are interested.
>  #
>  # The option `iburst' is used for faster initial synchronisation.
>  # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD.
>  #
> -server 0.pool.ntp.org iburst maxpoll 9
> -server 1.pool.ntp.org iburst maxpoll 9
> -server 2.pool.ntp.org iburst maxpoll 9
> +server 0.freebsd.pool.ntp.org iburst maxpoll 9
> +server 1.freebsd.pool.ntp.org iburst maxpoll 9
> +server 2.freebsd.pool.ntp.org iburst maxpoll 9
> +#server 3.freebsd.pool.ntp.org iburst maxpoll 9
>  
>  #
>  # If you want to pick yourself which country's public NTP server
>  # you want sync against, comment out the above servers, uncomment
> -# the next ones and replace CC with the country's abbrevation.
> +# the next ones and replace CC with the country's abbreviation.
>  # Make sure that the hostnames resolve to a proper IP address!
>  #
>  # server 0.CC.pool.ntp.org iburst maxpoll 9
> @@ -50,10 +53,12 @@
>  #restrict 127.127.1.0
>  
>  #
> -# If we lose sync against all configured servers, the NTP clients
> -# syncing against this server will lose sync too. To overcome this,
> -# we will act as a stratum 10 server with our own internal clock
> -# so that everybody at least will have the same time as we have.
> +# If a server loses sync with all upstream servers, NTP clients
> +# no longer follow that server. The local clock can be configured
> +# to provide a time source when this happens, but it should usually
> +# be configured on just one server on a network. For more details see
> +# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock
> +# The use of Orphan Mode may be preferable.
>  #
> -server 127.127.1.0
> -fudge 127.127.1.0 stratum 10
> +#server 127.127.1.0
> +#fudge 127.127.1.0 stratum 10

I'd tend to suggest stratum 13 so that the inattentive admin
doesn't spread his potentially dodgy clock info too far when
he tries uncommenting the above....  otherwise I (rather
subjectively) agree with this change :)

-- 
Brian Somers                                       <brian@Awfulhak.org>
Don't _EVER_ lose your sense of humour !            <brian@FreeBSD.org>
From scf at FreeBSD.org  Thu Jul  9 20:15:06 2009
From: scf at FreeBSD.org (Sean C. Farley)
Date: Thu Jul  9 20:15:29 2009
Subject: NTP - default /etc/ntp.conf 
In-Reply-To: <200907091020.aa42546@walton.maths.tcd.ie>
References: <200907091020.aa42546@walton.maths.tcd.ie>
Message-ID: <alpine.BSF.2.00.0907091512150.75393@thor.farley.org>

On Thu, 9 Jul 2009, David Malone wrote:

> The NTP pool guys have set up our vendor domain. I'd like to commit
> the patch below to ntp.conf. It does the following:
>
> 	1) Uses our vendor domain at the pool.
> 	2) Points people at the pool website and encourages
> 	   people to provide a server in the pool (as a
> 	   courtesy to the pool guys).
> 	3) Fixes a spelling.
> 	4) Comments out the local clock and includes a link
> 	   to documentation for use of the local clock on
> 	   the ntp.org site.
>
> If there are no objections, I'll ask re@ for permission to commit
> this.

Is 3.freebsd.pool.ntp.org intentionally commented?  It does resolve. 
Reminder:  if you do uncomment it, remember to change the "three 
servers" to four.

Otherwise, it looks good to me.

> 	David.
>
> Index: ntp.conf
> ===================================================================
> --- ntp.conf    (revision 195484)
> +++ ntp.conf    (working copy)
> @@ -13,19 +13,22 @@
> #
> # The following three servers will give you a random set of three
> # NTP servers geographically close to you.
> -# See http://en.wikipedia.org/wiki/NTP_pool for details.
> +# See http://www.pool.ntp.org/ for details. Note, the pool encourages
> +# users with a static IP and good upstream NTP servers to add a server
> +# to the pool. See http://www.pool.ntp.org/join.html if you are interested.
> #
> # The option `iburst' is used for faster initial synchronisation.
> # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD.
> #
> -server 0.pool.ntp.org iburst maxpoll 9
> -server 1.pool.ntp.org iburst maxpoll 9
> -server 2.pool.ntp.org iburst maxpoll 9
> +server 0.freebsd.pool.ntp.org iburst maxpoll 9
> +server 1.freebsd.pool.ntp.org iburst maxpoll 9
> +server 2.freebsd.pool.ntp.org iburst maxpoll 9
> +#server 3.freebsd.pool.ntp.org iburst maxpoll 9
>
> #
> # If you want to pick yourself which country's public NTP server
> # you want sync against, comment out the above servers, uncomment
> -# the next ones and replace CC with the country's abbrevation.
> +# the next ones and replace CC with the country's abbreviation.
> # Make sure that the hostnames resolve to a proper IP address!
> #
> # server 0.CC.pool.ntp.org iburst maxpoll 9
> @@ -50,10 +53,12 @@
> #restrict 127.127.1.0
>
> #
> -# If we lose sync against all configured servers, the NTP clients
> -# syncing against this server will lose sync too. To overcome this,
> -# we will act as a stratum 10 server with our own internal clock
> -# so that everybody at least will have the same time as we have.
> +# If a server loses sync with all upstream servers, NTP clients
> +# no longer follow that server. The local clock can be configured
> +# to provide a time source when this happens, but it should usually
> +# be configured on just one server on a network. For more details see
> +# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock
> +# The use of Orphan Mode may be preferable.
> #
> -server 127.127.1.0
> -fudge 127.127.1.0 stratum 10
> +#server 127.127.1.0
> +#fudge 127.127.1.0 stratum 10
>
> _______________________________________________
> 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"
>


Sean
-- 
scf@FreeBSD.org
From rea-fbsd at codelabs.ru  Thu Jul  9 22:30:39 2009
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Thu Jul  9 22:30:46 2009
Subject: kern/136618: [pf][stf] panic on cloning interface without unit
	number, e.g. `stf'
In-Reply-To: <200907091827.n69IR0Sl084730@freefall.freebsd.org>
References: <200907091827.n69IR0Sl084730@freefall.freebsd.org>
Message-ID: <hCsIYFcvX6asZcp4d+hhi1QeoOA@sMocRdeSobDWD5aEcWfflbBNqYM>

// Sorry for a long letter ;))

In fact, stf(4) problem will be healed with the attached patch: it works
for me and should provide absolutely sane pf rules, because stf(4) is
essentially a singleton interface, so there won't be ambiguities: 'stf'
as the interface name will have the same effect as the 'stf' being
treated as the interface group name.

In fact, the problem is rather simple: when cloned interface is created,
interface group with the interface family name (e.g. "vlan" or "carp")
is created prior to the interface creation.  So, when we create (with
pure creation or rename) the interface with the name of the "family",
pf will pick up the kif (via pfi_attach_ifnet) that already exists and
correspond to the interface group name and thus the loop will be
created: one of interface's groups will be its "family" group and this
group's ifg_pf_kif will be equal to the kif.  Recursive functions
like pfi_kif_update() won't be happy with this.

With my patch it shouldn't be a problem for any interface type --
infinite recursion will be avoided.  But another problem exists for
non-singleton interfaces: when we have, for example, interfaces carp1,
carp2 and carp3 and some of them (say, carp2) is renamed to just "carp",
then the rules for "carp" will really correspond to the whole family of
carp interfaces and not just to the former "carp2".  Of course, this is
a kind of shooting yourself to your feet, but this can be left unnoticed
and will produce a big headache; moreover, interface groups are hardly
well-documented now, so a person should learn from the experience or
from sources.

There is kern/127042 (rather old one, but it essentially the same as the
current PR) that addresses this aspect of the problem: it

 - refuses to add new group whose name coincides with the name of
   existing interface (first hunk);

 - additionally, it refuses to rename interface to the name that
   coincides with one of existing group names (second and third hunks of
   the patch in the said PR, by the way, last hunk misses '{' after 'if'
   and has 'groupname' instead of 'new_name').

The first part makes singletons to be real singletons and there will be
no groups of their name (in contrast with the current behaviour) as long
as these interfaces aren't renamed.  I mean that for the 'stf' case,
there will be no group named 'stf'.  But if I'll rename 'stf' -> 'foo',
then I'll be able to create the 'stf' group: 'ifconfig lo0 group stf'
will work happily.  This is the weird example, but it shows that the
behaviour here isn't very consistent with the notion of singletons.
Perhaps, interfaces such as 'stf' shouldn't be allowed to be renamed
at all -- this will close this issue.

Thus, this second patch (slightly reworked one from kern/127042) should
eliminate the foot-shooting problem: there will be no iface renames and
group creation that will result in the described foot-shooting.  And
since interface cloning when the "family" name is used (e.g. 'ifconfig
tun create') will create tunX with X being the first available digit, we
should be safe with this as long as all cloned interfaces (but singleton
ones) will refuse to create interface with the "family" name.

If there will be general consensus that singleton interfaces shouldn't
be allowed to be renamed, then I can try to implement such
functionality.  Going the other way and allowing creation of the 'stf'
group shouldn't also be hard -- just an additional test inside
if_addgroup() and a new interface flag that will be tested inside
if_addgroup().  And may be a special function for allocation of
singleton interface units -- just for simplicity and to avoid code
duplication.

Any views on this?  Perhaps I am missing something important here?
It is already deep night here, so I can produce some bad ideas :((

Thanks for your patience!

--- pf_if.c-avoid-infinite-recursion.diff begins here ---
begin 600 pf_if.c-avoid-infinite-recursion.diff
M+2TM('-Y<R]C;VYT<FEB+W!F+VYE="]P9E]I9BYC+F]R:6<),C`P.2TP-RTQ
M,"`P,#HQ.3HT-"XP,#`P,#`P,#`@*S`T,#`**RLK('-Y<R]C;VYT<FEB+W!F
M+VYE="]P9E]I9BYC"3(P,#DM,#<M,3`@,#$Z,#`Z,38N,#`P,#`P,#`P("LP
M-#`P"D!`("TU,S`L,3`@*S4S,"PR-B!`0`H@"0EP9FE?9'EN861D<E]U<&1A
M=&4H<"D["B`*(`DO*B!A9V%I;B!F;W(@86QL(&=R;W5P<R!K:68@:7,@;65M
M8F5R(&]F("HO"BT):68@*&MI9BT^<&9I:U]I9G`@(3T@3E5,3"D*+0D)5$%)
M3%%?1D]214%#2"AI9F=L+"`F:VEF+3YP9FEK7VEF<"T^:69?9W)O=7!S+"!I
M9F=L7VYE>'0I"BT)"0EP9FE?:VEF7W5P9&%T92@H<W1R=6-T('!F:5]K:68@
M*BD*+0D)"2`@("!I9F=L+3YI9F=L7V=R;W5P+3YI9F=?<&9?:VEF*3L**PEI
M9B`H:VEF+3YP9FEK7VEF<"`A/2!.54Q,*2!["BL)"7-T<G5C="!P9FE?:VEF
M("IG<E]K:68["BL)"51!24Q17T9/4D5!0T@H:69G;"P@)FMI9BT^<&9I:U]I
M9G`M/FEF7V=R;W5P<RP@:69G;%]N97AT*2!["BL)"0EG<E]K:68@/0HK"0D)
M("`@("AS=')U8W0@<&9I7VMI9B`J*6EF9VPM/FEF9VQ?9W)O=7`M/FEF9U]P
M9E]K:68["BL)"0DO*@HK"0D)("H@079O:60@:6YF:6YI=&4@<F5C=7)S:6]N
M.B!I9B!I;G1E<F9A8V4@;F%M92!I<PHK"0D)("H@=&AE('-A;64@87,@=&AE
M(&EN=&5R9F%C92!G<F]U<"!N86UE("AF;W(@97AA;7!L92P**PD)"2`J('-T
M9B@T*2!H87,@;VYL>2!O;F4@:6YS=&%N8V4@86YD(&ET<R!K:68@=VEL;"!B
M90HK"0D)("H@;F%M960@(G-T9B(L(&%S('1H92!G<F]U<"=S(")K:68B+B`@
M06YO=&AE<B!C87-E"BL)"0D@*B!I<R!T:&4@:6YT97)F86-E(')E;F%M960@
M=&\@:70G<R!F86UI;'D@;F%M90HK"0D)("H@*&4N9RXL(")V;&%N6"(@+3X@
M(G9L86XB*2X@($EN(&9A8W0L('1H92!L871T97(**PD)"2`J(&-A<V4@;75S
M="!B92!P<F]H:6)I=&5D+"!S:6YC92!I="!M86ME<R!P9@HK"0D)("H@<G5L
M97,@=&\@8F5H879E(&YO;BUI;G1U:71I=F5L>3H@:6YT97)F86-E)W,**PD)
M"2`J(')U;&5S('=I;&P@87!P;'D@=&\@=&AE('=H;VQE(&=R;W5P+@HK"0D)
M("HO"BL)"0EI9B`H:VEF("$](&=R7VMI9BD**PD)"0EP9FE?:VEF7W5P9&%T
?92AG<E]K:68I.PHK"0E]"BL)?0H@?0H@"B!V;VED"@``
`
end
--- pf_if.c-avoid-infinite-recursion.diff ends here ---

--- if.c-avoid-group-and-iface-name-clashes.diff begins here ---
begin 600 if.c-avoid-group-and-iface-name-clashes.diff
M+2TM('-Y<R]N970O:68N8RYO<FEG"3(P,#DM,#<M,3`@,#$Z-3DZ,3`N,#`P
M,#`P,#`P("LP-#`P"BLK*R!S>7,O;F5T+VEF+F,),C`P.2TP-RTQ,"`P,CHP
M,#HQ,RXP,#`P,#`P,#`@*S`T,#`*0$`@+3DV-2PV("LY-C4L.2!`0`H@"2`@
M("!G<F]U<&YA;65;<W1R;&5N*&=R;W5P;F%M92D@+2`Q72`\/2`G.2<I"B`)
M"7)E='5R;B`H14E.5D%,*3L*(`HK"6EF("AI9G5N:70H9W)O=7!N86UE*2`A
M/2!.54Q,*0HK"0ER971U<FX@*$5%6$E35"D["BL*(`E)1DY%5%]73$]#2R@I
M.PH@"51!24Q17T9/4D5!0T@H:69G;"P@)FEF<"T^:69?9W)O=7!S+"!I9F=L
M7VYE>'0I"B`)"6EF("@A<W1R8VUP*&EF9VPM/FEF9VQ?9W)O=7`M/FEF9U]G
M<F]U<"P@9W)O=7!N86UE*2D@>PI`0"`M,3DP-RPV("LQ.3$P+#<@0$`*(`EC
M:&%R(&YE=U]N86UE6TE&3D%-4TE:73L*(`ES=')U8W0@:69A9&1R("II9F$[
M"B`)<W1R=6-T('-O8VMA9&1R7V1L("IS9&P["BL)<W1R=6-T(&EF9U]G<F]U
M<"`J:69G(#T@3E5,3#L*(`H@"6EF<B`]("AS=')U8W0@:69R97$@*BED871A
M.PH@"7-W:71C:"`H8VUD*2!["D!`("TR,#$T+#<@*S(P,3@L,34@0$`*(`D)
M"7)E='5R;B`H14E.5D%,*3L*(`D):68@*&EF=6YI="AN97=?;F%M92D@(3T@
M3E5,3"D*(`D)"7)E='5R;B`H145825-4*3L*+0D)"BL**PD)249.151?4DQ/
M0TLH*3L**PD)5$%)3%%?1D]214%#2"AI9F<L("967VEF9U]H96%D+"!I9F=?
M;F5X="D**PD)"6EF("@A<W1R8VUP*&EF9RT^:69G7V=R;W5P+"!N97=?;F%M
M92DI('L**PD)"0E)1DY%5%]254Y,3T-+*"D["BL)"0D)<F5T=7)N("A%15A)
M4U0I.PHK"0D)?0HK"0E)1DY%5%]254Y,3T-+*"D["BL*(`D)+RH@06YN;W5N
M8V4@=&AE(&1E<&%R='5R92!O9B!T:&4@:6YT97)F86-E+B`J+PH@"0ER=%]I
M9F%N;F]U;F-E;7-G*&EF<"P@249!3E]$15!!4E154D4I.PH@"0E%5D5.5$A!
J3D1,15)?24Y63TM%*&EF;F5T7V1E<&%R='5R95]E=F5N="P@:69P*3L*
`
end
--- if.c-avoid-group-and-iface-name-clashes.diff ends here ---
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook
    {_.-``-'         {_/            #
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pf_if.c-avoid-infinite-recursion.diff
Type: text/x-diff
Size: 1156 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090709/cbe67be0/pf_if.c-avoid-infinite-recursion.bin
From rea-fbsd at codelabs.ru  Thu Jul  9 22:40:04 2009
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Thu Jul  9 22:40:10 2009
Subject: kern/136618: [pf][stf] panic on cloning interface without unit
	number, e.g. `stf'
Message-ID: <200907092240.n69Me3fg082980@freefall.freebsd.org>

The following reply was made to PR kern/136618; it has been noted by GNATS.

From: Eygene Ryabinkin <rea-fbsd@codelabs.ru>
To: linimon@FreeBSD.org
Cc: bug-followup@FreeBSD.org, freebsd-net@FreeBSD.org, mlaier@freebsd.org,
	artis.caune@gmail.com
Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit
	number, e.g. `stf'
Date: Fri, 10 Jul 2009 02:30:34 +0400

 --W/nzBZO5zC0uMSeA
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 // Sorry for a long letter ;))
 
 In fact, stf(4) problem will be healed with the attached patch: it works
 for me and should provide absolutely sane pf rules, because stf(4) is
 essentially a singleton interface, so there won't be ambiguities: 'stf'
 as the interface name will have the same effect as the 'stf' being
 treated as the interface group name.
 
 In fact, the problem is rather simple: when cloned interface is created,
 interface group with the interface family name (e.g. "vlan" or "carp")
 is created prior to the interface creation.  So, when we create (with
 pure creation or rename) the interface with the name of the "family",
 pf will pick up the kif (via pfi_attach_ifnet) that already exists and
 correspond to the interface group name and thus the loop will be
 created: one of interface's groups will be its "family" group and this
 group's ifg_pf_kif will be equal to the kif.  Recursive functions
 like pfi_kif_update() won't be happy with this.
 
 With my patch it shouldn't be a problem for any interface type --
 infinite recursion will be avoided.  But another problem exists for
 non-singleton interfaces: when we have, for example, interfaces carp1,
 carp2 and carp3 and some of them (say, carp2) is renamed to just "carp",
 then the rules for "carp" will really correspond to the whole family of
 carp interfaces and not just to the former "carp2".  Of course, this is
 a kind of shooting yourself to your feet, but this can be left unnoticed
 and will produce a big headache; moreover, interface groups are hardly
 well-documented now, so a person should learn from the experience or
 =66rom sources.
 
 There is kern/127042 (rather old one, but it essentially the same as the
 current PR) that addresses this aspect of the problem: it
 
  - refuses to add new group whose name coincides with the name of
    existing interface (first hunk);
 
  - additionally, it refuses to rename interface to the name that
    coincides with one of existing group names (second and third hunks of
    the patch in the said PR, by the way, last hunk misses '{' after 'if'
    and has 'groupname' instead of 'new_name').
 
 The first part makes singletons to be real singletons and there will be
 no groups of their name (in contrast with the current behaviour) as long
 as these interfaces aren't renamed.  I mean that for the 'stf' case,
 there will be no group named 'stf'.  But if I'll rename 'stf' -> 'foo',
 then I'll be able to create the 'stf' group: 'ifconfig lo0 group stf'
 will work happily.  This is the weird example, but it shows that the
 behaviour here isn't very consistent with the notion of singletons.
 Perhaps, interfaces such as 'stf' shouldn't be allowed to be renamed
 at all -- this will close this issue.
 
 Thus, this second patch (slightly reworked one from kern/127042) should
 eliminate the foot-shooting problem: there will be no iface renames and
 group creation that will result in the described foot-shooting.  And
 since interface cloning when the "family" name is used (e.g. 'ifconfig
 tun create') will create tunX with X being the first available digit, we
 should be safe with this as long as all cloned interfaces (but singleton
 ones) will refuse to create interface with the "family" name.
 
 If there will be general consensus that singleton interfaces shouldn't
 be allowed to be renamed, then I can try to implement such
 functionality.  Going the other way and allowing creation of the 'stf'
 group shouldn't also be hard -- just an additional test inside
 if_addgroup() and a new interface flag that will be tested inside
 if_addgroup().  And may be a special function for allocation of
 singleton interface units -- just for simplicity and to avoid code
 duplication.
 
 Any views on this?  Perhaps I am missing something important here?
 It is already deep night here, so I can produce some bad ideas :((
 
 Thanks for your patience!
 
 --- pf_if.c-avoid-infinite-recursion.diff begins here ---
 begin 600 pf_if.c-avoid-infinite-recursion.diff
 M+2TM('-Y<R]C;VYT<FEB+W!F+VYE=3D"]P9E]I9BYC+F]R:6<),C`P.2TP-RTQ
 M,"`P,#HQ.3HT-"XP,#`P,#`P,#`@*S`T,#`**RLK('-Y<R]C;VYT<FEB+W!F
 M+VYE=3D"]P9E]I9BYC"3(P,#DM,#<M,3`@,#$Z,#`Z,38N,#`P,#`P,#`P("LP
 M-#`P"D!`("TU,S`L,3`@*S4S,"PR-B!`0`H@"0EP9FE?9'EN861D<E]U<&1A
 M=3D&4H<"D["B`*(`DO*B!A9V%I;B!F;W(@86QL(&=3DR;W5P<R!K:68@:7,@;65M
 M8F5R(&]F("HO"BT):68@*&MI9BT^<&9I:U]I9G`@(3T@3E5,3"D*+0D)5$%)
 M3%%?1D]214%#2"AI9F=3DL+"`F:VEF+3YP9FEK7VEF<"T^:69?9W)O=3D7!S+"!I
 M9F=3DL7VYE>'0I"BT)"0EP9FE?:VEF7W5P9&%T92@H<W1R=3D6-T('!F:5]K:68@
 M*BD*+0D)"2`@("!I9F=3DL+3YI9F=3DL7V=3DR;W5P+3YI9F=3D?<&9?:VEF*3L**PEI
 M9B`H:VEF+3YP9FEK7VEF<"`A/2!.54Q,*2!["BL)"7-T<G5C=3D"!P9FE?:VEF
 M("IG<E]K:68["BL)"51!24Q17T9/4D5!0T@H:69G;"P@)FMI9BT^<&9I:U]I
 M9G`M/FEF7V=3DR;W5P<RP@:69G;%]N97AT*2!["BL)"0EG<E]K:68@/0HK"0D)
 M("`@("AS=3D')U8W0@<&9I7VMI9B`J*6EF9VPM/FEF9VQ?9W)O=3D7`M/FEF9U]P
 M9E]K:68["BL)"0DO*@HK"0D)("H@079O:60@:6YF:6YI=3D&4@<F5C=3D7)S:6]N
 M.B!I9B!I;G1E<F9A8V4@;F%M92!I<PHK"0D)("H@=3D&AE('-A;64@87,@=3D&AE
 M(&EN=3D&5R9F%C92!G<F]U<"!N86UE("AF;W(@97AA;7!L92P**PD)"2`J('-T
 M9B@T*2!H87,@;VYL>2!O;F4@:6YS=3D&%N8V4@86YD(&ET<R!K:68@=3DVEL;"!B
 M90HK"0D)("H@;F%M960@(G-T9B(L(&%S('1H92!G<F]U<"=3DS(")K:68B+B`@
 M06YO=3D&AE<B!C87-E"BL)"0D@*B!I<R!T:&4@:6YT97)F86-E(')E;F%M960@
 M=3D&\@:70G<R!F86UI;'D@;F%M90HK"0D)("H@*&4N9RXL(")V;&%N6"(@+3X@
 M(G9L86XB*2X@($EN(&9A8W0L('1H92!L871T97(**PD)"2`J(&-A<V4@;75S
 M=3D"!B92!P<F]H:6)I=3D&5D+"!S:6YC92!I=3D"!M86ME<R!P9@HK"0D)("H@<G5L
 M97,@=3D&\@8F5H879E(&YO;BUI;G1U:71I=3DF5L>3H@:6YT97)F86-E)W,**PD)
 M"2`J(')U;&5S('=3DI;&P@87!P;'D@=3D&\@=3D&AE('=3DH;VQE(&=3DR;W5P+@HK"0D)
 M("HO"BL)"0EI9B`H:VEF("$](&=3DR7VMI9BD**PD)"0EP9FE?:VEF7W5P9&%T
 ?92AG<E]K:68I.PHK"0E]"BL)?0H@?0H@"B!V;VED"@``
 `
 end
 --- pf_if.c-avoid-infinite-recursion.diff ends here ---
 
 --- if.c-avoid-group-and-iface-name-clashes.diff begins here ---
 begin 600 if.c-avoid-group-and-iface-name-clashes.diff
 M+2TM('-Y<R]N970O:68N8RYO<FEG"3(P,#DM,#<M,3`@,#$Z-3DZ,3`N,#`P
 M,#`P,#`P("LP-#`P"BLK*R!S>7,O;F5T+VEF+F,),C`P.2TP-RTQ,"`P,CHP
 M,#HQ,RXP,#`P,#`P,#`@*S`T,#`*0$`@+3DV-2PV("LY-C4L.2!`0`H@"2`@
 M("!G<F]U<&YA;65;<W1R;&5N*&=3DR;W5P;F%M92D@+2`Q72`\/2`G.2<I"B`)
 M"7)E=3D'5R;B`H14E.5D%,*3L*(`HK"6EF("AI9G5N:70H9W)O=3D7!N86UE*2`A
 M/2!.54Q,*0HK"0ER971U<FX@*$5%6$E35"D["BL*(`E)1DY%5%]73$]#2R@I
 M.PH@"51!24Q17T9/4D5!0T@H:69G;"P@)FEF<"T^:69?9W)O=3D7!S+"!I9F=3DL
 M7VYE>'0I"B`)"6EF("@A<W1R8VUP*&EF9VPM/FEF9VQ?9W)O=3D7`M/FEF9U]G
 M<F]U<"P@9W)O=3D7!N86UE*2D@>PI`0"`M,3DP-RPV("LQ.3$P+#<@0$`*(`EC
 M:&%R(&YE=3DU]N86UE6TE&3D%-4TE:73L*(`ES=3D')U8W0@:69A9&1R("II9F$[
 M"B`)<W1R=3D6-T('-O8VMA9&1R7V1L("IS9&P["BL)<W1R=3D6-T(&EF9U]G<F]U
 M<"`J:69G(#T@3E5,3#L*(`H@"6EF<B`]("AS=3D')U8W0@:69R97$@*BED871A
 M.PH@"7-W:71C:"`H8VUD*2!["D!`("TR,#$T+#<@*S(P,3@L,34@0$`*(`D)
 M"7)E=3D'5R;B`H14E.5D%,*3L*(`D):68@*&EF=3D6YI=3D"AN97=3D?;F%M92D@(3T@
 M3E5,3"D*(`D)"7)E=3D'5R;B`H145825-4*3L*+0D)"BL**PD)249.151?4DQ/
 M0TLH*3L**PD)5$%)3%%?1D]214%#2"AI9F<L("967VEF9U]H96%D+"!I9F=3D?
 M;F5X=3D"D**PD)"6EF("@A<W1R8VUP*&EF9RT^:69G7V=3DR;W5P+"!N97=3D?;F%M
 M92DI('L**PD)"0E)1DY%5%]254Y,3T-+*"D["BL)"0D)<F5T=3D7)N("A%15A)
 M4U0I.PHK"0D)?0HK"0E)1DY%5%]254Y,3T-+*"D["BL*(`D)+RH@06YN;W5N
 M8V4@=3D&AE(&1E<&%R=3D'5R92!O9B!T:&4@:6YT97)F86-E+B`J+PH@"0ER=3D%]I
 M9F%N;F]U;F-E;7-G*&EF<"P@249!3E]$15!!4E154D4I.PH@"0E%5D5.5$A!
 J3D1,15)?24Y63TM%*&EF;F5T7V1E<&%R=3D'5R95]E=3DF5N=3D"P@:69P*3L*
 `
 end
 --- if.c-avoid-group-and-iface-name-clashes.diff ends here ---
 --=20
 Eygene
  _                ___       _.--.   #
  \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
  /  ' `         ,       __.--'      #  to read the on-line manual
  )/' _/     \   `-_,   /            #  while single-stepping the kernel.
  `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
      _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook
     {_.-``-'         {_/            #
 
 --W/nzBZO5zC0uMSeA
 Content-Type: text/x-diff; charset=us-ascii
 Content-Disposition: attachment; filename="pf_if.c-avoid-infinite-recursion.diff"
 
 --- sys/contrib/pf/net/pf_if.c.orig	2009-07-10 00:19:44.000000000 +0400
 +++ sys/contrib/pf/net/pf_if.c	2009-07-10 01:00:16.000000000 +0400
 @@ -530,10 +530,26 @@
  		pfi_dynaddr_update(p);
  
  	/* again for all groups kif is member of */
 -	if (kif->pfik_ifp != NULL)
 -		TAILQ_FOREACH(ifgl, &kif->pfik_ifp->if_groups, ifgl_next)
 -			pfi_kif_update((struct pfi_kif *)
 -			    ifgl->ifgl_group->ifg_pf_kif);
 +	if (kif->pfik_ifp != NULL) {
 +		struct pfi_kif *gr_kif;
 +		TAILQ_FOREACH(ifgl, &kif->pfik_ifp->if_groups, ifgl_next) {
 +			gr_kif =
 +			    (struct pfi_kif *)ifgl->ifgl_group->ifg_pf_kif;
 +			/*
 +			 * Avoid infinite recursion: if interface name is
 +			 * the same as the interface group name (for example,
 +			 * stf(4) has only one instance and its kif will be
 +			 * named "stf", as the group's "kif".  Another case
 +			 * is the interface renamed to it's family name
 +			 * (e.g., "vlanX" -> "vlan").  In fact, the latter
 +			 * case must be prohibited, since it makes pf
 +			 * rules to behave non-intuitively: interface's
 +			 * rules will apply to the whole group.
 +			 */
 +			if (kif != gr_kif)
 +				pfi_kif_update(gr_kif);
 +		}
 +	}
  }
  
  void
 
 --W/nzBZO5zC0uMSeA--
From jhay at meraka.org.za  Fri Jul 10 05:40:18 2009
From: jhay at meraka.org.za (John Hay)
Date: Fri Jul 10 05:40:26 2009
Subject: NTP - default /etc/ntp.conf
In-Reply-To: <200907091020.aa42546@walton.maths.tcd.ie>
References: <20090702084608.GA59311@roberto-al.eurocontrol.fr>
	<200907091020.aa42546@walton.maths.tcd.ie>
Message-ID: <20090710054014.GA57163@zibbi.meraka.csir.co.za>

Hi David,

On Thu, Jul 09, 2009 at 10:20:29AM +0100, David Malone wrote:
> The NTP pool guys have set up our vendor domain. I'd like to commit
> the patch below to ntp.conf. It does the following:
> 
> 	1) Uses our vendor domain at the pool.
> 	2) Points people at the pool website and encourages
> 	   people to provide a server in the pool (as a
> 	   courtesy to the pool guys).
> 	3) Fixes a spelling.
> 	4) Comments out the local clock and includes a link
> 	   to documentation for use of the local clock on
> 	   the ntp.org site.
> 
> If there are no objections, I'll ask re@ for permission to commit
> this.

This looks fine to me.

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

> 
> 	David.
> 
> Index: ntp.conf
> ===================================================================
> --- ntp.conf    (revision 195484)
> +++ ntp.conf    (working copy)
> @@ -13,19 +13,22 @@
>  #
>  # The following three servers will give you a random set of three
>  # NTP servers geographically close to you.
> -# See http://en.wikipedia.org/wiki/NTP_pool for details.
> +# See http://www.pool.ntp.org/ for details. Note, the pool encourages
> +# users with a static IP and good upstream NTP servers to add a server
> +# to the pool. See http://www.pool.ntp.org/join.html if you are interested.
>  #
>  # The option `iburst' is used for faster initial synchronisation.
>  # The option `maxpoll 9' is used to prevent PLL/FLL flipping on FreeBSD.
>  #
> -server 0.pool.ntp.org iburst maxpoll 9
> -server 1.pool.ntp.org iburst maxpoll 9
> -server 2.pool.ntp.org iburst maxpoll 9
> +server 0.freebsd.pool.ntp.org iburst maxpoll 9
> +server 1.freebsd.pool.ntp.org iburst maxpoll 9
> +server 2.freebsd.pool.ntp.org iburst maxpoll 9
> +#server 3.freebsd.pool.ntp.org iburst maxpoll 9
>  
>  #
>  # If you want to pick yourself which country's public NTP server
>  # you want sync against, comment out the above servers, uncomment
> -# the next ones and replace CC with the country's abbrevation.
> +# the next ones and replace CC with the country's abbreviation.
>  # Make sure that the hostnames resolve to a proper IP address!
>  #
>  # server 0.CC.pool.ntp.org iburst maxpoll 9
> @@ -50,10 +53,12 @@
>  #restrict 127.127.1.0
>  
>  #
> -# If we lose sync against all configured servers, the NTP clients
> -# syncing against this server will lose sync too. To overcome this,
> -# we will act as a stratum 10 server with our own internal clock
> -# so that everybody at least will have the same time as we have.
> +# If a server loses sync with all upstream servers, NTP clients
> +# no longer follow that server. The local clock can be configured
> +# to provide a time source when this happens, but it should usually
> +# be configured on just one server on a network. For more details see
> +# http://support.ntp.org/bin/view/Support/UndisciplinedLocalClock
> +# The use of Orphan Mode may be preferable.
>  #
> -server 127.127.1.0
> -fudge 127.127.1.0 stratum 10
> +#server 127.127.1.0
> +#fudge 127.127.1.0 stratum 10

From dwmalone at maths.tcd.ie  Fri Jul 10 05:53:59 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Fri Jul 10 05:54:06 2009
Subject: NTP - default /etc/ntp.conf 
In-Reply-To: Your message of "Thu, 09 Jul 2009 15:15:03 CDT."
	<alpine.BSF.2.00.0907091512150.75393@thor.farley.org> 
Message-ID: <200907100653.aa52216@walton.maths.tcd.ie>

> Is 3.freebsd.pool.ntp.org intentionally commented?  It does resolve. 
> Reminder:  if you do uncomment it, remember to change the "three 
> servers" to four.

The pool set up 4 groups (0, 1, 2, 3) for us, but since we only had
three in the original file (and three is a commonly recommended
number of servers), I thought I'd only three of the four. I did
think that we might rotate which subset of the 4 we use over time.

I've no problem commenting in all 4 if people think that's a better
config.

	David.
From dwmalone at maths.tcd.ie  Fri Jul 10 05:56:11 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Fri Jul 10 05:56:17 2009
Subject: NTP - default /etc/ntp.conf 
In-Reply-To: Your message of "Thu, 09 Jul 2009 11:03:23 PDT."
	<20090709110323.6106a0f3@Awfulhak.org> 
Message-ID: <200907100656.aa52257@walton.maths.tcd.ie>

> I'd tend to suggest stratum 13 so that the inattentive admin
> doesn't spread his potentially dodgy clock info too far when
> he tries uncommenting the above....  otherwise I (rather
> subjectively) agree with this change :)

I'll change the commented version, as it shouldn't do any harm.
As I said, I usually use 14, which is probably almost too low.

	David.
From artis.caune at gmail.com  Fri Jul 10 06:14:15 2009
From: artis.caune at gmail.com (Artis Caune)
Date: Fri Jul 10 06:14:21 2009
Subject: kern/136618: [pf][stf] panic on cloning interface without unit 
	number, e.g. `stf'
In-Reply-To: <hCsIYFcvX6asZcp4d+hhi1QeoOA@sMocRdeSobDWD5aEcWfflbBNqYM>
References: <200907091827.n69IR0Sl084730@freefall.freebsd.org>
	<hCsIYFcvX6asZcp4d+hhi1QeoOA@sMocRdeSobDWD5aEcWfflbBNqYM>
Message-ID: <9e20d71e0907092253m69346b0nde7095f7de9bc36f@mail.gmail.com>

2009/7/10 Eygene Ryabinkin <rea-fbsd@codelabs.ru>:
> There is kern/127042 (rather old one, but it essentially the same as the
> current PR) that addresses this aspect of the problem: it
>
> ?- additionally, it refuses to rename interface to the name that
> ? coincides with one of existing group names (second and third hunks of
> ? the patch in the said PR, by the way, last hunk misses '{' after 'if'
> ? and has 'groupname' instead of 'new_name').

sorry for bad patch, my bad s/copy/coffee/

thanks for working on this.




-- 
Artis Caune

    Everything should be made as simple as possible, but not simpler.
From artis.caune at gmail.com  Fri Jul 10 06:20:03 2009
From: artis.caune at gmail.com (Artis Caune)
Date: Fri Jul 10 06:20:09 2009
Subject: kern/136618: [pf][stf] panic on cloning interface without unit 
	number, e.g. `stf'
Message-ID: <200907100620.n6A6K3nO040550@freefall.freebsd.org>

The following reply was made to PR kern/136618; it has been noted by GNATS.

From: Artis Caune <artis.caune@gmail.com>
To: rea-fbsd@codelabs.ru
Cc: linimon@freebsd.org, bug-followup@freebsd.org, freebsd-net@freebsd.org, 
	mlaier@freebsd.org
Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit 
	number, e.g. `stf'
Date: Fri, 10 Jul 2009 08:53:07 +0300

 2009/7/10 Eygene Ryabinkin <rea-fbsd@codelabs.ru>:
 > There is kern/127042 (rather old one, but it essentially the same as the
 > current PR) that addresses this aspect of the problem: it
 >
 > =C2=A0- additionally, it refuses to rename interface to the name that
 > =C2=A0 coincides with one of existing group names (second and third hunks=
  of
 > =C2=A0 the patch in the said PR, by the way, last hunk misses '{' after '=
 if'
 > =C2=A0 and has 'groupname' instead of 'new_name').
 
 sorry for bad patch, my bad s/copy/coffee/
 
 thanks for working on this.
 
 
 
 
 --=20
 Artis Caune
 
     Everything should be made as simple as possible, but not simpler.
From roberto at keltia.freenix.fr  Fri Jul 10 07:43:54 2009
From: roberto at keltia.freenix.fr (Ollivier Robert)
Date: Fri Jul 10 07:44:01 2009
Subject: NTP - default /etc/ntp.conf
In-Reply-To: <200907100656.aa52257@walton.maths.tcd.ie>
References: <20090709110323.6106a0f3@Awfulhak.org>
	<200907100656.aa52257@walton.maths.tcd.ie>
Message-ID: <20090710074346.GA67742@roberto-al.eurocontrol.fr>

According to David Malone:
> I'll change the commented version, as it shouldn't do any harm.
> As I said, I usually use 14, which is probably almost too low.

I don't see any real added value having 14 instead of 10. At these levels it
can be only a "faked" one.

-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr
In memoriam to Ondine : http://ondine.keltia.net/

From rea-fbsd at codelabs.ru  Fri Jul 10 10:27:14 2009
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Fri Jul 10 10:27:21 2009
Subject: kern/136618: [pf][stf] panic on cloning interface without unit
 number, e.g. `stf'
In-Reply-To: <9e20d71e0907092253m69346b0nde7095f7de9bc36f@mail.gmail.com>
References: <200907091827.n69IR0Sl084730@freefall.freebsd.org>
	<hCsIYFcvX6asZcp4d+hhi1QeoOA@sMocRdeSobDWD5aEcWfflbBNqYM>
	<9e20d71e0907092253m69346b0nde7095f7de9bc36f@mail.gmail.com>
Message-ID: <oFQ01mX9yU9mR7VUVKhz5SuDnPk@jmKTY7juey8QgiyMw1P6k9Lb4sg>

Artis, good day.

Fri, Jul 10, 2009 at 08:53:07AM +0300, Artis Caune wrote:
> 2009/7/10 Eygene Ryabinkin <rea-fbsd@codelabs.ru>:
> > There is kern/127042 (rather old one, but it essentially the same as the
> > current PR) that addresses this aspect of the problem: it
> >
> > ?- additionally, it refuses to rename interface to the name that
> > ? coincides with one of existing group names (second and third hunks of
> > ? the patch in the said PR, by the way, last hunk misses '{' after 'if'
> > ? and has 'groupname' instead of 'new_name').
> 
> sorry for bad patch, my bad s/copy/coffee/

No problems.  Care to test both patches?  If yes, please, report back
any findings of any type.

> thanks for working on this.

You're welcome ;))
-- 
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook
    {_.-``-'         {_/            #
From rea-fbsd at codelabs.ru  Fri Jul 10 10:30:04 2009
From: rea-fbsd at codelabs.ru (Eygene Ryabinkin)
Date: Fri Jul 10 10:30:11 2009
Subject: kern/136618: [pf][stf] panic on cloning interface without unit
 number, e.g. `stf'
Message-ID: <200907101030.n6AAU3Ar050676@freefall.freebsd.org>

The following reply was made to PR kern/136618; it has been noted by GNATS.

From: Eygene Ryabinkin <rea-fbsd@codelabs.ru>
To: Artis Caune <artis.caune@gmail.com>
Cc: linimon@freebsd.org, bug-followup@freebsd.org, freebsd-net@freebsd.org,
	mlaier@freebsd.org
Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit
 number, e.g. `stf'
Date: Fri, 10 Jul 2009 14:26:57 +0400

 Artis, good day.
 
 Fri, Jul 10, 2009 at 08:53:07AM +0300, Artis Caune wrote:
 > 2009/7/10 Eygene Ryabinkin <rea-fbsd@codelabs.ru>:
 > > There is kern/127042 (rather old one, but it essentially the same as the
 > > current PR) that addresses this aspect of the problem: it
 > >
 > > š- additionally, it refuses to rename interface to the name that
 > > š coincides with one of existing group names (second and third hunks of
 > > š the patch in the said PR, by the way, last hunk misses '{' after 'if'
 > > š and has 'groupname' instead of 'new_name').
 > 
 > sorry for bad patch, my bad s/copy/coffee/
 
 No problems.  Care to test both patches?  If yes, please, report back
 any findings of any type.
 
 > thanks for working on this.
 
 You're welcome ;))
 -- 
 Eygene
  _                ___       _.--.   #
  \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
  /  ' `         ,       __.--'      #  to read the on-line manual
  )/' _/     \   `-_,   /            #  while single-stepping the kernel.
  `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
      _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook
     {_.-``-'         {_/            #
From dwmalone at maths.tcd.ie  Fri Jul 10 11:10:18 2009
From: dwmalone at maths.tcd.ie (David Malone)
Date: Fri Jul 10 11:10:24 2009
Subject: NTP - default /etc/ntp.conf 
In-Reply-To: Your message of "Fri, 10 Jul 2009 09:43:46 +0200."
	<20090710074346.GA67742@roberto-al.eurocontrol.fr> 
Message-ID: <200907101210.aa53747@walton.maths.tcd.ie>

> > I'll change the commented version, as it shouldn't do any harm.
> > As I said, I usually use 14, which is probably almost too low.

> I don't see any real added value having 14 instead of 10. At these levels it
> can be only a "faked" one.

Grand - let's leave it at 10 then.

	David.
From LConrad at Go2France.com  Fri Jul 10 11:30:15 2009
From: LConrad at Go2France.com (Len Conrad)
Date: Fri Jul 10 11:30:28 2009
Subject: FreeBSD/iSCSI initiator into EMC Clarion target
Message-ID: <200907101311781.SM01728@W500.Go2France.com>


uname -a

FreeBSD xxx 7.1-RELEASE FreeBSD 7.1-RELEASE #0

kldstat

Id Refs Address    Size     Name
 1    5 0xc0400000 97f830   kernel
 2    1 0xc0d80000 ff18     iscsi_initiator.ko
 3    1 0xc0d90000 6a2c4    acpi.ko


iscontrol doesn't have -V version and strings doesn't find anything that looks like a version.


iscontrol -d -v -t 192.168.78.5 
                    port = 3260
                    tags = 0
                 maxluns = 0
                     iqn = iqn.2005-01.il.ac.huji.cs:
          maxConnections = 1
maxRecvDataSegmentLength = 65536
maxXmitDataSegmentLength = 65536
          maxBurstLength = 131072
        firstBurstLength = 65536
        defaultTime2Wait = 0
      defaultTime2Retain = 0
       maxOutstandingR2T = 1
      errorRecoveryLevel = 0
    targetPortalGroupTag = 0
            headerDigest = None,CRC32C
              dataDigest = None,CRC32C
              initialR2T = 1
           immediateData = 1
          dataPDUInOrder = 1
     dataSequenceInOrder = 1
             sessionType = Normal
           targetAddress = (null)
             targetAlias = (null)
              targetName = (null)
           initiatorName = (null)
          initiatorAlias = (null)
              authMethod = None
              chapSecret = (null)
               chapIName = (null)
             tgtChapName = (null)
           tgtChapSecret = (null)
      tgttgtChallengeLen = 0
I-: cmd=0x3 len=301
        SessionType=Discovery
        InitiatorName=iqn.2005-01.il.ac.huji.cs::mr1.xxxx.net
        MaxBurstLength=131072
        HeaderDigest=None,CRC32C
        DataDigest=None,CRC32C
        MaxRecvDataSegmentLength=65536
        ErrorRecoveryLevel=0
        DefaultTime2Wait=0
        DefaultTime2Retain=0
        DataPDUInOrder=Yes
        DataSequenceInOrder=Yes
        MaxOutstandingR2T=1
T-: cmd=0x23 len=281
        TargetPortalGroupTag=0
        TargetAlias=1576.b3
        HeaderDigest=None
        DataDigest=None
        MaxRecvDataSegmentLength=65536
        MaxBurstLength=Irrelevant
        DefaultTime2Wait=0
        DefaultTime2Retain=0
        MaxOutstandingR2T=Irrelevant
        DataPDUInOrder=Irrelevant
        DataSequenceInOrder=Irrelevant
        ErrorRecoveryLevel=0

I-: cmd=0x4 len=16
        SendTargets=All
recvpdu: Socket is not connected
recvpdu failed

I-: cmd=0x6 len=0
recvpdu: Socket is not connected
recvpdu failed

==========

initatator does work into a FreeBSD/iscsi-target:


# iscontrol -c /etc/iscsi.conf -n target0

iscontrol[817]: running
iscontrol[817]: (pass3:iscsi0:0:0:0):  tagged openings now 0
iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:1
iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:2
iscontrol[817]: cam_open_btl: no passthrough device found at 2:0:3
iscontrol: supervise starting main loop

#ll /dev/is*
crw-------  1 root  wheel    0,  27 Jul  8 13:29 /dev/iscsi
crw-------  1 root  wheel    0, 103 Jul  8 13:29 /dev/iscsi0

#ll /dev/da*
crw-r-----  1 root  operator    0,  90 Jul  8 13:29 /dev/da0
crw-r-----  1 root  operator    0,  91 Jul  8 13:29 /dev/da0s1
crw-r-----  1 root  operator    0,  92 Jul  8 08:30 /dev/da0s1a
crw-r-----  1 root  operator    0,  93 Jul  8 13:30 /dev/da0s1b
crw-r-----  1 root  operator    0,  94 Jul  8 13:29 /dev/da0s1c
crw-r-----  1 root  operator    0,  95 Jul  8 08:29 /dev/da0s1d
crw-r-----  1 root  operator    0,  96 Jul  8 08:29 /dev/da0s1e
crw-r-----  1 root  operator    0, 105 Jul  8 13:29 /dev/da1
crw-r-----  1 root  operator    0, 106 Jul  8 13:29 /dev/da1s1
crw-r-----  1 root  operator    0, 107 Jul  8 13:29 /dev/da1s1c
crw-r-----  1 root  operator    0, 108 Jul  8 13:29 /dev/da1s1d

#mount /dev/da1s1 /iscsitest/

#df
Filesystem  1K-blocks    Used    Avail Capacity  Mounted on
/dev/da0s1a  10154158  141662  9200164     2%    /
devfs               1       1        0   100%    /dev
/dev/da0s1d  20308398 1393604 17290124     7%    /usr
/dev/da0s1e  40622090  292054 37080270     1%    /var
/dev/da1s1    9907690 2990276  6124800    33%    /iscsitest

=========

Red Hat Enterprise iscsi initiator connects to EMC SAN target reliably.

If we can't get the FreeBSD iniatator working, we'll have to convert several machines from FreeBSD to Linux.

Len

From realliukai at gmail.com  Fri Jul 10 03:43:43 2009
From: realliukai at gmail.com (=?GB2312?B?wfW/rQ==?=)
Date: Fri Jul 10 12:00:08 2009
Subject: system panic when i use ath without swap,some advice?
Message-ID: <7237120a0907092043ld8a3325mcf1458ef4aab3bf8@mail.gmail.com>

Hi all

    My system is atom n270 1G RAM, freebsd 7.2 release .without swap.
    When my ath is associated with an AP, and the traffic is high, the
system will panic and reboot. this happened many times.
    Can you give me some advice please.
thanks

Micheal Kevin
From hlh at restart.be  Fri Jul 10 12:35:34 2009
From: hlh at restart.be (Henri Hennebert)
Date: Fri Jul 10 12:35:46 2009
Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and
 IPv6 for 'local' connections
Message-ID: <4A573591.1000506@restart.be>

Hello,

After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when
connecting with firefox to a local apache server using the global
unicast IPv6 address of the local machine. pf.conf must be updated!

My configuration:

[root@avoriaz ~]# ifconfig em0

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
	ether 00:1d:60:ad:2a:ce
	inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255
	inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1
	inet6 2001:41d0:2:2d29:1:1:: prefixlen 80
	media: Ethernet 100baseTX (100baseTX <half-duplex>)
	status: active

[root@avoriaz ~]# host www.restart.bel
www.restart.bel is an alias for avoriaz.restart.bel.
avoriaz.restart.bel has address 192.168.24.1
avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1::

pf.conf:

int_if="em0"
block in  log all
block out log all
set skip on lo0
antispoof quick for $int_if inet
# Allow trafic with physical internal network
pass in quick on $int_if from ($int_if:network) to ($int_if) keep state
pass out quick on $int_if from ($int_if) to ($int_if:network) keep state

The problem:

[root@avoriaz ~]# telnet -4 www.restart.bel 80
Trying 192.168.24.1...
Connected to avoriaz.restart.bel.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
[root@avoriaz ~]# telnet -6 www.restart.bel 80
Trying 2001:41d0:2:2d29:1:1::...
--->Never connect and get a timeout!

tcpdump and logging in pf show me that

For a IPv4 connection:
the packet from telnet to apache pass 2 times on lo0 (out and in)
the answer packet from apache to telnet pass 2 times on lo0 (out and in)

So no problem, there is `set skip on lo0'

For a IPv6 connection:
The first packet from telnet to apache pass 2 times on lo0 (out and in)
The answer packet from apache to telnet path on em0  and is rejected
due to the default flags S/SA.

So I have to change pf.conf and replace the last line:
pass out quick on $int_if from ($int_if) to ($int_if:network) \
keep state flags any

Then all is OK

By the way, on 7.2

netstat -rn display

192.168.24.1        00:1d:60:ad:2a:ce
....
2001:41d0:2:2d29:1:1::            00:1d:60:ad:2a:ce


On 8.0-BETA1 there is an assymetry:

netstat -rn display

192.168.24.1       link#3
....
no entry for 2001:41d0:2:2d29:1:1::

Hope it may help someone

Henri


From pluknet at gmail.com  Fri Jul 10 16:13:24 2009
From: pluknet at gmail.com (pluknet)
Date: Fri Jul 10 16:13:31 2009
Subject: aliases on lo0: SIOCDIFADDR gives EADDRNOTAVAIL
Message-ID: <a31046fc0907100913j7c3edf1ft7173c135a83cc846@mail.gmail.com>

Hi.

I have the next string in rc.conf:
ifconfig_lo0_alias0="inet 192.168.193.193/32"

/etc/rc.d/netif restart lo0 prints an error:

Stopping network:ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
 lo0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        inet 192.168.193.193 netmask 0xffffffff

Can someone comment on this?

Thanks.

-- 
wbr,
pluknet
From pluknet at gmail.com  Fri Jul 10 16:24:29 2009
From: pluknet at gmail.com (pluknet)
Date: Fri Jul 10 16:24:35 2009
Subject: aliases on lo0: SIOCDIFADDR gives EADDRNOTAVAIL
In-Reply-To: <a31046fc0907100913j7c3edf1ft7173c135a83cc846@mail.gmail.com>
References: <a31046fc0907100913j7c3edf1ft7173c135a83cc846@mail.gmail.com>
Message-ID: <a31046fc0907100924r21e772far20a33d9eff49072d@mail.gmail.com>

2009/7/10 pluknet <pluknet@gmail.com>:
> Hi.
>
> I have the next string in rc.conf:
> ifconfig_lo0_alias0="inet 192.168.193.193/32"
>
> /etc/rc.d/netif restart lo0 prints an error:
>
> Stopping network:ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
> ?lo0.
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
> ? ? ? ?inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
> ? ? ? ?inet6 ::1 prefixlen 128
> ? ? ? ?inet 127.0.0.1 netmask 0xff000000
> ? ? ? ?inet 192.168.193.193 netmask 0xffffffff
>
> Can someone comment on this?
>

P.S. AFAICS from sh -x this equvalents to:
ifconfig lo0 inet 192.168.193.193/32 -alias
ifconfig lo0 inet 192.168.193.193 delete

$ sudo ifconfig lo0 inet 192.168.193.193/32 -alias
$ ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
$ sudo ifconfig lo0 inet 192.168.193.193 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

-- 
wbr,
pluknet
From onemda at gmail.com  Fri Jul 10 20:25:43 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Fri Jul 10 20:25:49 2009
Subject: system panic when i use ath without swap,some advice?
In-Reply-To: <7237120a0907092043ld8a3325mcf1458ef4aab3bf8@mail.gmail.com>
References: <7237120a0907092043ld8a3325mcf1458ef4aab3bf8@mail.gmail.com>
Message-ID: <3a142e750907101325l318a8854q6c75dd7b94dfcc3a@mail.gmail.com>

On 7/10/09, ****** <realliukai@gmail.com> wrote:
> Hi all
>
>     My system is atom n270 1G RAM, freebsd 7.2 release .without swap.
>     When my ath is associated with an AP, and the traffic is high, the
> system will panic and reboot. this happened many times.
>     Can you give me some advice please.
> thanks
>
> Micheal Kevin
> _______________________________________________
> 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"
>

Provide backtrace from crash, and "vmstat -m" output.

-- 
Paul
From kbrint at rufus.net  Sat Jul 11 04:13:52 2009
From: kbrint at rufus.net (kevin brintnall)
Date: Sat Jul 11 04:14:15 2009
Subject: panic on ip_input, ip_len byte ordering problem?
Message-ID: <20090711035435.GA18298@rufus.net>

Hi,

Here is my system:

	FreeBSD fw.rufus.net 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #1: Wed Jun 10 11:32:28 CDT 2009     root@hamachi.rufus.net:/usr/obj/usr/src/sys/SOEKRIS  i386

I am seeing occasional panics in ip_input when forwarding IP traffic at
low rates (<100pkt/sec).

	Fatal trap 12: page fault while in kernel mode
	cpuid = 0; apic id = 00
	fault virtual address	= 0xc
	fault code		= supervisor read, page not present
	instruction pointer	= 0x20:0xc0872228
	stack pointer	        = 0x28:0xc17f2b20
	frame pointer	        = 0x28:0xc17f2b3c
	code segment		= base 0x0, limit 0xfffff, type 0x1b
				= DPL 0, pres 1, def32 1, gran 1
	processor eflags	= interrupt enabled, resume, IOPL = 0
	current process		= 20 (irq10: sis0 sis1+)
	trap number		= 12
	panic: page fault
	cpuid = 0
	Uptime: 12d10h48m45s
	Physical memory: 115 MB
	Dumping 49 MB: 34 18 2
	Dump complete

The stack trace is as follows:

	#5  0xc0b502cc in trap (frame=0xc17f2ae0) at /usr/src/sys/i386/i386/trap.c:530
	#6  0xc0b342bb in calltrap () at /usr/src/sys/i386/i386/exception.s:159
	#7  0xc0872228 in m_copydata (m=0x0, off=0, len=88, 
	    cp=0xc1aeb6a8 "some garbage") at /usr/src/sys/kern/uipc_mbuf.c:815
	#8  0xc090a728 in ip_forward (m=0xc19f0700, srcrt=0)
	    at /usr/src/sys/netinet/ip_input.c:1307
	#9  0xc090bf0c in ip_input (m=0xc19f0700)
	    at /usr/src/sys/netinet/ip_input.c:609
	#10 0xc08c9fa5 in netisr_dispatch (num=2, m=0xc19f0700)
	    at /usr/src/sys/net/netisr.c:185

m_copydata is walking off the end of the mbuf chain..  It turns out that
the IP header length is incorrect.

Here is the code from frame 8:

	1304	if (mcopy != NULL) {
	1305		mcopy->m_len = min(ip->ip_len, M_TRAILINGSPACE(mcopy));
	1306		mcopy->m_pkthdr.len = mcopy->m_len;
	1307		m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t));
	1308	}

The packet is 116 bytes, which is correctly reflected in the mbuf header.
However, the IP packet length appears to be in network byte order rather
than host byte order.  Note that 29696=ntohs(116).

	(kgdb) p m->m_hdr->mh_len
	$55 = 116
	(kgdb) p mcopy->m_hdr->mh_len
	$56 = 204
	(kgdb) p ip->ip_len
	$57 = 29696		<<-- should be 116!

The rest of the IP header looks correct:

$58 = {ip_hl = 5, ip_v = 4, ip_tos = 16 '\020', ip_len = 29696, ip_id = 38700, 
  ip_off = 64, ip_ttl = 58 ':', ip_p = 6 '\006', ip_sum = 5172, ip_src = {
    s_addr = X}, ip_dst = {s_addr = 1139586513}}

When ip_input is initially called, I think the ip_len must be right..
Otherwise, the "tooshort" block around ip_input.c:383 would stop
processing.

		if (m->m_pkthdr.len < ip->ip_len) {
	tooshort:
			ipstat.ips_tooshort++;
			goto bad;
		}

Any ideas?  My best guess is that there exists a code path in PF somewhere
that is doing an uneven number of ntohs() and htons().

Thanks in advance!

--
 kevin brintnall =~ /kbrint@rufus.net/
From iprebeg at freebsd.org  Sat Jul 11 07:59:21 2009
From: iprebeg at freebsd.org (iprebeg@freebsd.org)
Date: Sat Jul 11 07:59:28 2009
Subject: em driver doesn't set multicast ethernet address
Message-ID: <20090711073647.GA1824@valeria.zesoi.fer.hr>

While testing -CURRENT in VMWare environment, I discovered that em
driver doesn't properly set destination address in Ethernet header. In
the other words, when I start listening multicast session with mcastread
(mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is
224.0.0.22, but its destionation Ethernet address doesn't look like
01:00:5e:... Other machines that I run in same environment (like
FreeBSD-7) behave in good manner.
From bms at incunabulum.net  Sat Jul 11 08:17:11 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Sat Jul 11 08:17:18 2009
Subject: em driver doesn't set multicast ethernet address
In-Reply-To: <20090711073647.GA1824@valeria.zesoi.fer.hr>
References: <20090711073647.GA1824@valeria.zesoi.fer.hr>
Message-ID: <4A5849E5.90909@incunabulum.net>

iprebeg@freebsd.org wrote:
> While testing -CURRENT in VMWare environment, I discovered that em
> driver doesn't properly set destination address in Ethernet header. In
> the other words, when I start listening multicast session with mcastread
> (mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is
> 224.0.0.22, but its destionation Ethernet address doesn't look like
> 01:00:5e:... Other machines that I run in same environment (like
> FreeBSD-7) behave in good manner.
>   

It seems that the introduction of IGMPv3 may have exposed some 
driver/hardware issues, where certain network interfaces are not able to 
transmit on groups which haven't been joined for receive. This is a bug, 
and would likely break production use of IPv6, which makes heavier use 
of link-scope groups than IPv4 does.

Can you provide the following information please, so that someone can 
better help you:
 1) the date of the -CURRENT code you are using;
 2) tcpdump or wireshark capture output, containing the actual output 
generated by em(4).

Does this issue occur if you use the 'mtest' tool to join 224.0.0.22 
inside the guest? The kernel will *not* listen to 224.0.0.22, unless 
you're running a multicast routing daemon -- as it doesn't have to; that 
link-scope group is for reports only.

This issue doesn't appear with IGMPv2, because it only ever transmits 
its reports on the group thus joined. This has the disadvantage that 
multicast routers have to have functioning promiscuous multicast 
receive, just to proxy or forward traffic.

Can you force the use of IGMPv2 using the sysctls as defined in the 
igmp(4) man page as a workaround?

thanks,
BMS
From iprebeg at freebsd.org  Sat Jul 11 09:33:02 2009
From: iprebeg at freebsd.org (iprebeg@freebsd.org)
Date: Sat Jul 11 09:33:09 2009
Subject: em driver doesn't set multicast ethernet address
In-Reply-To: <4A5849E5.90909@incunabulum.net>
References: <20090711073647.GA1824@valeria.zesoi.fer.hr>
	<4A5849E5.90909@incunabulum.net>
Message-ID: <20090711092753.GA9630@valeria.zesoi.fer.hr>

On Sat, Jul 11, 2009 at 09:14:29AM +0100, Bruce Simpson wrote:
> iprebeg@freebsd.org wrote:
>> While testing -CURRENT in VMWare environment, I discovered that em
>> driver doesn't properly set destination address in Ethernet header. In
>> the other words, when I start listening multicast session with mcastread
>> (mcast-tools), kernel triggers IGMPv3 packet. Its destionation IP is
>> 224.0.0.22, but its destionation Ethernet address doesn't look like
>> 01:00:5e:... Other machines that I run in same environment (like
>> FreeBSD-7) behave in good manner.
>>   
>
> It seems that the introduction of IGMPv3 may have exposed some 
> driver/hardware issues, where certain network interfaces are not able to 
> transmit on groups which haven't been joined for receive. This is a bug, 
> and would likely break production use of IPv6, which makes heavier use of 
> link-scope groups than IPv4 does.
>
> Can you provide the following information please, so that someone can 
> better help you:
> 1) the date of the -CURRENT code you are using;
> 2) tcpdump or wireshark capture output, containing the actual output 
> generated by em(4).

1) Problem emerged after I upgraded to BETA1 and stayed there after I
upgraded to p4 version dated 10th of July. Before that I used few months
old snapshot (can't exactly tell the date).
2) dump file generated by wireshark is attached

>
> Does this issue occur if you use the 'mtest' tool to join 224.0.0.22 inside 
> the guest? The kernel will *not* listen to 224.0.0.22, unless you're 
> running a multicast routing daemon -- as it doesn't have to; that 
> link-scope group is for reports only.

There is no difference, ethernet destination is still usual unicast
address.

>
> This issue doesn't appear with IGMPv2, because it only ever transmits its 
> reports on the group thus joined. This has the disadvantage that multicast 
> routers have to have functioning promiscuous multicast receive, just to 
> proxy or forward traffic.
>
> Can you force the use of IGMPv2 using the sysctls as defined in the igmp(4) 
> man page as a workaround?

Well, now, something really interesting happened. I changed default IGMP
version via sysctl

# sysctl net.inet.igmp.default_version=2

but, then I tested it with mtest and generated packets were still IGMPv3
Membership reports, but first two of them had proper mcast ethernet
address. They generated sent by mtest.

>
> thanks,
> BMS
> _______________________________________________
> 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"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: igmp.dump
Type: application/octet-stream
Size: 6618 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090711/7148a56a/igmp.obj
From hlh at restart.be  Sat Jul 11 10:09:50 2009
From: hlh at restart.be (Henri Hennebert)
Date: Sat Jul 11 10:10:03 2009
Subject: 8.0-BETA1 - for the record - different paths followed by IPv4
 and IPv6 for 'local' connections
In-Reply-To: <B583FBF374231F4A89607B4D08578A4304673660@bcs-mail03.internal.cacheflow.com>
References: <4A5734C3.3000806@restart.be>
	<B583FBF374231F4A89607B4D08578A4304673660@bcs-mail03.internal.cacheflow.com>
Message-ID: <4A5864DC.1070106@restart.be>

Li, Qing wrote:
> Hi,
> 
> Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/
> and let me know how it works out for you. I thought I had committed the patch 
> but turned out I didn't.

I apply the patch, reset my pf.conf to its previous content and all is 
running smoothly. By the way, I discover after my post that my 
"solution" was not working for long (many bytes) connections and this is 
solved too.

Many thank for your time

Henri

PS please commit as soon as possible

> 
>> On 8.0-BETA1 there is an assymetry:
>>
>> netstat -rn display
>>
>> 192.168.24.1       link#3
>> ....
>> no entry for 2001:41d0:2:2d29:1:1::
>>
> 
> This is by design as part of the new architecture in 8.0, which maintains 
> the L2 ARP/ND6 and L3 routing tables separately.
> 
> -- Qing
> 
> 
> 
> -----Original Message-----
> From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert
> Sent: Fri 7/10/2009 5:32 AM
> To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org
> Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
>  
> Hello,
> 
> After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when 
> connecting with firefox to a local apache server using the global 
> unicast IPv6 address of the local machine. pf.conf must be updated!
> 
> My configuration:
> 
> [root@avoriaz ~]# ifconfig em0
> 
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> 	options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
> 	ether 00:1d:60:ad:2a:ce
> 	inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255
> 	inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1
> 	inet6 2001:41d0:2:2d29:1:1:: prefixlen 80
> 	media: Ethernet 100baseTX (100baseTX <half-duplex>)
> 	status: active
> 
> [root@avoriaz ~]# host www.restart.bel
> www.restart.bel is an alias for avoriaz.restart.bel.
> avoriaz.restart.bel has address 192.168.24.1
> avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1::
> 
> pf.conf:
> 
> int_if="em0"
> block in  log all
> block out log all
> set skip on lo0
> antispoof quick for $int_if inet
> # Allow trafic with physical internal network
> pass in quick on $int_if from ($int_if:network) to ($int_if) keep state
> pass out quick on $int_if from ($int_if) to ($int_if:network) keep state
> 
> The problem:
> 
> [root@avoriaz ~]# telnet -4 www.restart.bel 80
> Trying 192.168.24.1...
> Connected to avoriaz.restart.bel.
> Escape character is '^]'.
> ^]
> telnet> quit
> Connection closed.
> [root@avoriaz ~]# telnet -6 www.restart.bel 80
> Trying 2001:41d0:2:2d29:1:1::...
> --->Never connect and get a timeout!
> 
> tcpdump and logging in pf show me that
> 
> For a IPv4 connection:
> the packet from telnet to apache pass 2 times on lo0 (out and in)
> the answer packet from apache to telnet pass 2 times on lo0 (out and in)
> 
> So no problem, there is `set skip on lo0'
> 
> For a IPv6 connection:
> The first packet from telnet to apache pass 2 times on lo0 (out and in)
> The answer packet from apache to telnet path on em0  and is rejected
> due to the default flags S/SA.
> 
> So I have to change pf.conf and replace the last line:
> pass out quick on $int_if from ($int_if) to ($int_if:network) \
> keep state flags any
> 
> Then all is OK
> 
> By the way, on 7.2
> 
> netstat -rn display
> 
> 192.168.24.1        00:1d:60:ad:2a:ce
> ....
> 2001:41d0:2:2d29:1:1::            00:1d:60:ad:2a:ce
> 
> 
> On 8.0-BETA1 there is an assymetry:
> 
> netstat -rn display
> 
> 192.168.24.1       link#3
> ....
> no entry for 2001:41d0:2:2d29:1:1::
> 
> Hope it may help someone
> 
> Henri
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 

From A.Hongens at netmatch.nl  Sat Jul 11 10:10:09 2009
From: A.Hongens at netmatch.nl (=?ISO-8859-1?Q?Angelo_H=F6ngens?=)
Date: Sat Jul 11 10:10:15 2009
Subject: kern/127050: [carp] ipv6 does not work on carp interfaces
	[regression]
Message-ID: <200907111010.n6BAA6C3077941@freefall.freebsd.org>

The following reply was made to PR kern/127050; it has been noted by GNATS.

From: =?ISO-8859-1?Q?Angelo_H=F6ngens?= <A.Hongens@netmatch.nl>
To: bug-followup@FreeBSD.org, maddog2k@maddog2k.net
Cc:  
Subject: Re: kern/127050: [carp] ipv6 does not work on carp interfaces [regression]
Date: Sat, 11 Jul 2009 12:06:30 +0200

 A few months ago I could not ping any virtual ipv6 addresses. However,
 I'm running 7.2 now, and decided to pick up this issue. Something seems
 to have changed, and I can ping at least the first ipv6 address of a
 carp interface (just not the others)
 
 
 Some more info: I have four reverse cache machines (simple Dell R300's),
 running Squid. The four machines are balanced by round robin DNS. The
 DNS publishes 4 virtual carp addresses, and each node has 4 carp
 interfaces, but is always the master over its own one. This way, up to
 three nodes can fail, and the other takes over.
 
 Works like a charm, but of course I want to enable ipv6 over the same
 infrastructure.
 
 I've configured ipv6 aliases on all interfaces, and rebooted all nodes.
 
 Now the funny thing is, I can ping all ipv4 ip's (it's been running in
 production for months), I can ping6 the the dedicated ip's of all nodes
 (2001:81:82::206:113 for the node below), and I can ping to all the
 FIRST ipv6 addresses of the carp interfaces.
 
 Could very well be something I'm doing wrong, but I think it's a bug in
 carp. (Of course I could work around it by creating 16 carp interfaces
 on each machine, but I don't know what's the best solution.)
 
 So:
 
 I can ping6 to 2001:81:82::206:81
 I can ping6 to 2001:81:82::206:82
 I can ping6 to 2001:81:82::206:83
 I can ping6 to 2001:81:82::206:84
 I can NOT ping6 to 2001:81:82::206:85
 I can NOT ping6 to 2001:81:82::206:86
 I can NOT ping6 to 2001:81:82::206:87
 I can NOT ping6 to 2001:81:82::206:88
 I can NOT ping6 to 2001:81:82::206:121
 I can NOT ping6 to 2001:81:82::206:122
 I can NOT ping6 to 2001:81:82::206:123
 I can NOT ping6 to 2001:81:82::206:124
 
 
 Here you see pings on the cluster node. Pings to :81 get answered, but
 the node does not answer of neighbor solicitaions to :85:
 
 $ sudo tcpdump -ni nic0 icmp6
 listening on nic0, link-type EN10MB (Ethernet), capture size 96 bytes
 11:54:09.846489 IP6 2001:610:6a8:0:223:6cff:fe8d:6775 >
 2001:81:82::206:81: ICMP6, echo request, seq 0, length 16
 11:54:09.846524 IP6 2001:81:82::206:81 >
 2001:610:6a8:0:223:6cff:fe8d:6775: ICMP6, echo reply, seq 0, length 16
 11:54:10.845796 IP6 2001:610:6a8:0:223:6cff:fe8d:6775 >
 2001:81:82::206:81: ICMP6, echo request, seq 1, length 16
 11:54:10.845829 IP6 2001:81:82::206:81 >
 2001:610:6a8:0:223:6cff:fe8d:6775: ICMP6, echo reply, seq 1, length 16
 11:54:11.848522 IP6 2001:610:6a8:0:223:6cff:fe8d:6775 >
 2001:81:82::206:81: ICMP6, echo request, seq 2, length 16
 11:54:11.848539 IP6 2001:81:82::206:81 >
 2001:610:6a8:0:223:6cff:fe8d:6775: ICMP6, echo reply, seq 2, length 16
 11:54:13.949889 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6,
 neighbor solicitation, who has 2001:81:82::206:85, length 32
 11:54:14.846703 IP6 2001:81:82::206:113 > 2001:81:82::1: ICMP6, neighbor
 solicitation, who has 2001:81:82::1, length 32
 11:54:14.847034 IP6 2001:81:82::1 > 2001:81:82::206:113: ICMP6, neighbor
 advertisement, tgt is 2001:81:82::1, length 24
 11:54:14.948194 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6,
 neighbor solicitation, who has 2001:81:82::206:85, length 32
 11:54:15.948203 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6,
 neighbor solicitation, who has 2001:81:82::206:85, length 32
 11:54:16.954932 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6,
 neighbor solicitation, who has 2001:81:82::206:85, length 32
 11:54:17.952257 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6,
 neighbor solicitation, who has 2001:81:82::206:85, length 32
 11:54:18.952558 IP6 fe80::203:feff:fea0:b000 > ff02::1:ff06:85: ICMP6,
 neighbor solicitation, who has 2001:81:82::206:85, length 32
 
 I am running:
 $ uname -a
 FreeBSD balancer3.domain.local 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Tue
 Jun 16 12:08:00 CEST 2009
 root@balancer3.domain.local:/usr/obj/usr/src/sys/GENERIC-CARP  amd64
 
 
 IP's below are scrambled and are not the real addresses:
 
 
 -- /etc/rc.conf -------------------------
 ifconfig_bge0_name="nic0"
 ifconfig_bge1_name="nic1"
 ipv6_enable="YES"
 
 ifconfig_nic0="inet 81.82.206.113 netmask 255.255.255.192"
 ifconfig_nic0_alias0="inet6 2001:81:82::206:113 prefixlen 48"
 ifconfig_nic1="inet 10.82.20.113 netmask 255.255.255.0"
 defaultrouter="81.82.206.65"
 ipv6_defaultrouter="2001:81:82::1"
 
 cloned_interfaces="carp0 carp1 carp2 carp3"
 
 ifconfig_carp0="vhid 103 pass blabla 81.82.206.81/26 advskew 0"
 ifconfig_carp0_alias0="inet6 2001:81:82::206:81 prefixlen 48"
 ifconfig_carp0_alias1="inet 81.82.206.85 netmask 255.255.255.192"
 ifconfig_carp0_alias2="inet6 2001:81:82::206:85 prefixlen 48"
 ifconfig_carp0_alias3="inet 81.82.206.121 netmask 255.255.255.192"
 ifconfig_carp0_alias4="inet6 2001:81:82::206:121 prefixlen 48"
 
 ifconfig_carp1="vhid 104 pass blabla 81.82.206.82/26 advskew 100"
 ifconfig_carp1_alias0="inet6 2001:81:82::206:82 prefixlen 48"
 ifconfig_carp1_alias1="inet 81.82.206.86 netmask 255.255.255.192"
 ifconfig_carp1_alias2="inet6 2001:81:82::206:86 prefixlen 48"
 ifconfig_carp1_alias3="inet 81.82.206.122 netmask 255.255.255.192"
 ifconfig_carp1_alias4="inet6 2001:81:82::206:122 prefixlen 48"
 
 fconfig_carp2="vhid 105 pass blabla 81.82.206.83/26 advskew 100"
 ifconfig_carp2_alias0="inet6 2001:81:82::206:83 prefixlen 48"
 ifconfig_carp2_alias1="inet 81.82.206.87 netmask 255.255.255.192"
 ifconfig_carp2_alias2="inet6 2001:81:82::206:87 prefixlen 48"
 ifconfig_carp2_alias3="inet 81.82.206.123 netmask 255.255.255.192"
 ifconfig_carp2_alias4="inet6 2001:81:82::206:123 prefixlen 48"
 
 ifconfig_carp3="vhid 106 pass blabla 81.82.206.84/26 advskew 100"
 ifconfig_carp3_alias0="inet6 2001:81:82::206:84 prefixlen 48"
 ifconfig_carp3_alias1="inet 81.82.206.88 netmask 255.255.255.192"
 ifconfig_carp3_alias2="inet6 2001:81:82::206:88 prefixlen 48"
 ifconfig_carp3_alias3="inet 81.82.206.124 netmask 255.255.255.192"
 ifconfig_carp3_alias4="inet6 2001:81:82::206:124 prefixlen 48"
 -----------------------------------------
 
 -- ifconfig output ----------------------
 
 nic0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric
 0 mtu 1500
         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
         ether 00:22:19:cd:5c:e0
         inet6 fe80::222:19ff:fecd:5ce0%nic0 prefixlen 64 scopeid 0x1
         inet 81.82.206.113 netmask 0xffffffc0 broadcast 81.82.206.127
         inet6 2001:81:82::206:113 prefixlen 48
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
 nic1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
         ether 00:22:19:cd:5c:e1
         inet6 fe80::222:19ff:fecd:5ce1%nic1 prefixlen 64 scopeid 0x2
         inet 10.82.20.113 netmask 0xffffff00 broadcast 10.82.20.255
         media: Ethernet autoselect (1000baseTX <full-duplex>)
         status: active
 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
         inet6 ::1 prefixlen 128
         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
         inet 127.0.0.1 netmask 0xff000000
 carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
         inet 81.82.206.81 netmask 0xffffffc0
         inet6 2001:81:82::206:81 prefixlen 48
         inet 81.82.206.85 netmask 0xffffffc0
         inet6 2001:81:82::206:85 prefixlen 48
         inet 81.82.206.121 netmask 0xffffffc0
         inet6 2001:81:82::206:121 prefixlen 48
         carp: MASTER vhid 103 advbase 1 advskew 0
 carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
         inet 81.82.206.82 netmask 0xffffffc0
         inet6 2001:81:82::206:82 prefixlen 48
         inet 81.82.206.86 netmask 0xffffffc0
         inet6 2001:81:82::206:86 prefixlen 48
         inet 81.82.206.122 netmask 0xffffffc0
         inet6 2001:81:82::206:122 prefixlen 48
         carp: BACKUP vhid 104 advbase 1 advskew 100
 carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
         inet 81.82.206.83 netmask 0xffffffc0
         inet6 2001:81:82::206:83 prefixlen 48
         inet 81.82.206.87 netmask 0xffffffc0
         inet6 2001:81:82::206:87 prefixlen 48
         inet 81.82.206.123 netmask 0xffffffc0
         inet6 2001:81:82::206:123 prefixlen 48
         carp: BACKUP vhid 105 advbase 1 advskew 100
 carp3: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
         inet 81.82.206.84 netmask 0xffffffc0
         inet6 2001:81:82::206:84 prefixlen 48
         inet 81.82.206.88 netmask 0xffffffc0
         inet6 2001:81:82::206:88 prefixlen 48
         inet 81.82.206.124 netmask 0xffffffc0
         inet6 2001:81:82::206:124 prefixlen 48
         carp: BACKUP vhid 106 advbase 1 advskew 100
 
 
 -- 
 
 
 With kind regards,
 
 
 Angelo Höngens
 
 Systems Administrator
 
 ------------------------------------------
 NetMatch
 tourism internet software solutions
 
 Ringbaan Oost 2b
 5013 CA Tilburg
 T: +31 (0)13 5811088
 F: +31 (0)13 5821239
 
 mailto:A.Hongens@netmatch.nl
 http://www.netmatch.nl
 ------------------------------------------
From bms at incunabulum.net  Sat Jul 11 13:01:14 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Sat Jul 11 13:01:20 2009
Subject: em driver doesn't set multicast ethernet address
In-Reply-To: <20090711092753.GA9630@valeria.zesoi.fer.hr>
References: <20090711073647.GA1824@valeria.zesoi.fer.hr>
	<4A5849E5.90909@incunabulum.net>
	<20090711092753.GA9630@valeria.zesoi.fer.hr>
Message-ID: <4A588C4D.4060805@incunabulum.net>

Hi,

Thanks for the feedback.

iprebeg@freebsd.org wrote:
> Well, now, something really interesting happened. I changed default IGMP
> version via sysctl
>
> # sysctl net.inet.igmp.default_version=2
>
> but, then I tested it with mtest and generated packets were still IGMPv3
> Membership reports, but first two of them had proper mcast ethernet
> address. They generated sent by mtest.
>   

Sorry, forgot to mention -- this sysctl won't take effect immediately.
It needs to be set before the interface's driver is loaded and IPv4 is 
attached to the interface.

Do you have any unusual ARP table entries or routing setup? That would 
be where to look next.

There haven't been any other reports of this issue as far as I know. The 
IGMP code does not fill out the Ethernet address field -- it leaves it 
up to ip_output() to do that.

Do you see this with other multicast traffic, or just IGMP reports?

thanks,
BMS

From iprebeg at freebsd.org  Sat Jul 11 13:44:34 2009
From: iprebeg at freebsd.org (iprebeg@freebsd.org)
Date: Sat Jul 11 13:44:40 2009
Subject: em driver doesn't set multicast ethernet address
In-Reply-To: <4A588C4D.4060805@incunabulum.net>
References: <20090711073647.GA1824@valeria.zesoi.fer.hr>
	<4A5849E5.90909@incunabulum.net>
	<20090711092753.GA9630@valeria.zesoi.fer.hr>
	<4A588C4D.4060805@incunabulum.net>
Message-ID: <20090711133917.GA10001@valeria.zesoi.fer.hr>

On Sat, Jul 11, 2009 at 01:57:49PM +0100, Bruce Simpson wrote:
> Hi,
>
> Thanks for the feedback.
>
> iprebeg@freebsd.org wrote:
>> Well, now, something really interesting happened. I changed default IGMP
>> version via sysctl
>>
>> # sysctl net.inet.igmp.default_version=2
>>
>> but, then I tested it with mtest and generated packets were still IGMPv3
>> Membership reports, but first two of them had proper mcast ethernet
>> address. They generated sent by mtest.
>>   
>
> Sorry, forgot to mention -- this sysctl won't take effect immediately.
> It needs to be set before the interface's driver is loaded and IPv4 is 
> attached to the interface.
>

I placed config in sysctl.conf and rebooted but mcastread still generates IGMPv3
membership report. Am I missing something?

> Do you have any unusual ARP table entries or routing setup? That would be 
> where to look next.
>

Nope. 

> There haven't been any other reports of this issue as far as I know. The 
> IGMP code does not fill out the Ethernet address field -- it leaves it up 
> to ip_output() to do that.
>
> Do you see this with other multicast traffic, or just IGMP reports?
>

I generated multicast traffic with nc and examined packets still have
wrong ether dest address.

So, it seems that no IGMP code is wrong. Can someone please try to
reproduce this with different hardware? I have no other configuration 
but this in VMWare environment.

> thanks,
> BMS
>
From bms at incunabulum.net  Sat Jul 11 13:59:15 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Sat Jul 11 13:59:22 2009
Subject: em driver doesn't set multicast ethernet address
In-Reply-To: <20090711133917.GA10001@valeria.zesoi.fer.hr>
References: <20090711073647.GA1824@valeria.zesoi.fer.hr>
	<4A5849E5.90909@incunabulum.net>
	<20090711092753.GA9630@valeria.zesoi.fer.hr>
	<4A588C4D.4060805@incunabulum.net>
	<20090711133917.GA10001@valeria.zesoi.fer.hr>
Message-ID: <4A5899DC.7080804@incunabulum.net>

iprebeg@freebsd.org wrote:
> I placed config in sysctl.conf and rebooted but mcastread still generates IGMPv3
> membership report. Am I missing something?
>   

Only other thing I can think of right now:
Are any multicast queriers/routers present on the virtual subnet?

I'm tied up, so probably can't look at the sysctl in detail, until in 
the week.

cheers,
BMS
From iprebeg at freebsd.org  Sat Jul 11 14:18:23 2009
From: iprebeg at freebsd.org (iprebeg@freebsd.org)
Date: Sat Jul 11 14:18:29 2009
Subject: em driver doesn't set multicast ethernet address
In-Reply-To: <4A5899DC.7080804@incunabulum.net>
References: <20090711073647.GA1824@valeria.zesoi.fer.hr>
	<4A5849E5.90909@incunabulum.net>
	<20090711092753.GA9630@valeria.zesoi.fer.hr>
	<4A588C4D.4060805@incunabulum.net>
	<20090711133917.GA10001@valeria.zesoi.fer.hr>
	<4A5899DC.7080804@incunabulum.net>
Message-ID: <20090711141305.GA26848@valeria.zesoi.fer.hr>

On Sat, Jul 11, 2009 at 02:55:40PM +0100, Bruce Simpson wrote:
> iprebeg@freebsd.org wrote:
>> I placed config in sysctl.conf and rebooted but mcastread still generates 
>> IGMPv3
>> membership report. Am I missing something?
>>   
>
> Only other thing I can think of right now:
> Are any multicast queriers/routers present on the virtual subnet?
>
> I'm tied up, so probably can't look at the sysctl in detail, until in the 
> week.
>

There is no such. I'm implementing IGMP snooping extensions in ng_bridge
and luckily, they are based on IPv4 addresses, so I can probably
temporarly disable preliminary {multi/other}cast discrimination based on
ethernet address and stick to IPv4 until bug is fixed. In a meantime,
I'll try to figure out some different hardware configuration to make
sure this is not "feature" of VMWare, even everything worked fine until
now.

> cheers,
> BMS
From ricky.packetlogic at gmail.com  Sat Jul 11 15:07:14 2009
From: ricky.packetlogic at gmail.com (ricky.packetlogic@gmail.com)
Date: Sat Jul 11 15:07:21 2009
Subject: kern/135222: [igb] low speed routing between two igb
 interfaces
In-Reply-To: <4A399C7F.4000203@modulus.org>
Message-ID: <16045747.41247323614497.JavaMail.root@wombat>

>>Intel 82575EB (and friends)  are *the* premier ethernet controllers to 
>>use with FreeBSD in a server.  igb should be the most stable and 
>>supported driver in the whole kernel.  I can't think of any other driver 
>>and series of controllers I would rather use in a server like this.

Well, the good NIC is no good at all without good driver, sadly, it's the case with stock igb driver shipped with FB.

I hate to say this, but igb driver sucks, there're many obvious issue in the code like wrong DMA allocation etc. You just have to re-write completely to get igb work, i.e., to support msi-x with multiqueue.

>>If the drivers for these chips are now "bad", this is a very sad day for 
>>people who wanted to use FreeBSD in their dual socket servers.
Either stick to em or re-write the igb driver.

It's just funny that everybody keeps quite on this, is it too difficulty to let people know it's the known issue with igb driver?

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

--
This message was sent on behalf of ricky.packetlogic@gmail.com at openSubscriber.com
http://www.opensubscriber.com/message/freebsd-net@freebsd.org/12445915.html
From barney_cordoba at yahoo.com  Sat Jul 11 16:51:23 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sat Jul 11 16:51:30 2009
Subject: kern/135222: [igb] low speed routing between two igb
	interfaces
Message-ID: <370660.51527.qm@web63906.mail.re1.yahoo.com>




--- On Sat, 7/11/09, ricky.packetlogic@gmail.com <ricky.packetlogic@gmail.com> wrote:

> From: ricky.packetlogic@gmail.com <ricky.packetlogic@gmail.com>
> Subject: Re: Re: kern/135222: [igb] low speed routing between two igb interfaces
> To: freebsd-net@freebsd.org
> Date: Saturday, July 11, 2009, 10:46 AM
> >>Intel 82575EB (and
> friends)? are *the* premier ethernet controllers to 
> >>use with FreeBSD in a server.? igb should be
> the most stable and 
> >>supported driver in the whole kernel.? I can't
> think of any other driver 
> >>and series of controllers I would rather use in a
> server like this.
> 
> Well, the good NIC is no good at all without good driver,
> sadly, it's the case with stock igb driver shipped with FB.
> 
> I hate to say this, but igb driver sucks, there're many
> obvious issue in the code like wrong DMA allocation etc. You
> just have to re-write completely to get igb work, i.e., to
> support msi-x with multiqueue.
> 
> >>If the drivers for these chips are now "bad", this
> is a very sad day for 
> >>people who wanted to use FreeBSD in their dual
> socket servers.
> Either stick to em or re-write the igb driver.
> 
> It's just funny that everybody keeps quite on this, is it
> too difficulty to let people know it's the known issue with
> igb driver?
> 
> Ricky

I thought packetlogic ran on Linux, have you finally abandoned that pig?

Barney


      
From stuartb at 4gh.net  Sat Jul 11 22:23:45 2009
From: stuartb at 4gh.net (Stuart Barkley)
Date: Sat Jul 11 22:23:52 2009
Subject: NTP - default /etc/ntp.conf 
In-Reply-To: <200907100653.aa52216@walton.maths.tcd.ie>
References: <200907100653.aa52216@walton.maths.tcd.ie>
Message-ID: <alpine.BSF.2.00.0907111752300.3561@freeman.4gh.net>

On Fri, 10 Jul 2009 at 01:53 -0000, David Malone wrote:

> > Is 3.freebsd.pool.ntp.org intentionally commented?  It does
> > resolve. Reminder:  if you do uncomment it, remember to change the
> > "three servers" to four.
>
> I've no problem commenting in all 4 if people think that's a better
> config.

4 ntp servers are usually recommended.  If one is down and one is
wacky the remaining two can out vote the wacky one.  Kinda like using
raid-5 with a hot spare.

Stuart
-- 
I've never been lost; I was once bewildered for three days, but never lost!
                                        --  Daniel Boone
From rpaulo at freebsd.org  Sun Jul 12 13:23:09 2009
From: rpaulo at freebsd.org (Rui Paulo)
Date: Sun Jul 12 13:23:16 2009
Subject: HEADS UP: projects/mesh11s committed to HEAD
Message-ID: <D2CA8D0A-AF0A-4C05-BA0E-DD714A7BCB9C@freebsd.org>

Hi,
Just a heads up to note that 802.11s D3.0 support has been committed  
to HEAD. If you notice any wireless related problems, please inform me  
ASAP.

Thanks,
--
Rui Paulo

From LConrad at Go2France.com  Sun Jul 12 19:00:52 2009
From: LConrad at Go2France.com (Len Conrad)
Date: Sun Jul 12 19:01:03 2009
Subject: dump hangs on 7.1
In-Reply-To: <200907120914.50095.mel.flynn+fbsd.questions@mailing.thruhe
	re.net>
References: <200907101829.AA227541664@mail.Go2France.com>
	<200907120914.50095.mel.flynn+fbsd.questions@mailing.thruhere.net>
Message-ID: <200907122042515.SM01728@W500.Go2France.com>


>On Friday 10 July 2009 08:29:01 Len Conrad wrote:
>> FreeBSD 7.1-RELEASE #0: Thu Jan  1 14:37:25 UTC 2009    
>> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>>
>> CPU: Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz (2496.26-MHz 686-class
>> CPU) Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10
>>   AMD Features=0x20100000<NX,LM>
>>   AMD Features2=0x1<LAHF>
>>   Cores per package: 4
>> real memory  = 3484745728 (3323 MB)
>> avail memory = 3405537280 (3247 MB)
>> ACPI APIC Table: <DELL   PE_SC3  >
>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>>  cpu0 (BSP): APIC ID:  0
>>  cpu1 (AP): APIC ID:  1
>>  cpu2 (AP): APIC ID:  2
>>  cpu3 (AP): APIC ID:  3
>>
>>
>> /sbin/dump -0uanL -f - / | ssh dump_images@xxx.net dd
>> of=/var/ftp/dump_images/mx1-root-test
>>
>> dump has completed only once. Several other dumps have all gotten under
>> way, target file is created and increases until the hang.
>>
>> CTRL-C gets back to shell,eg:
>>
>>   DUMP: Date of this level 0 dump: Fri Jul 10 10:25:33 2009
>>   DUMP: Date of last level 0 dump: the epoch
>>   DUMP: Dumping snapshot of /dev/da0s1d (/usr) to standard output
>>   DUMP: mapping (Pass I) [regular files]
>>   DUMP: mapping (Pass II) [directories]
>>   DUMP: estimated 1713942 tape blocks.
>>   DUMP: dumping (Pass III) [directories]
>>   DUMP: dumping (Pass IV) [regular files]
>> ^C  DUMP: Interrupt received.
>>   DUMP: Do you want to abort dump?: ("yes" or "no") Killed by signal 2.
>>   DUMP: Broken pipe
>>   DUMP: The ENTIRE dump is aborted.
>>
>> Hangs always in Pass IV
>
>What's the output ps -auwwx|grep dump at the time of the dump.

when the dump hangs:

ps auxww | grep dump

root    61360  0.0  0.0  3128  1168  p0  I+    1:47PM   0:00.06 /sbin/dump -0uanL -f - / (dump)

root    61361  0.0  0.1  5560  2768  p0  I+    1:47PM   0:03.65 ssh xxx@xxx.net dd of=/var/ftp/dump_images/mx1-root-test

root    61364  0.0  0.0  3128  1528  p0  I+    1:47PM   0:00.36 dump: /dev/da0s1a: pass 4: 92.66% done, finished in 0:00 at Sun Jul 12 13:47:52 2009 (dump)

root    61365  0.0  0.0  3128  1184  p0  I+    1:47PM   0:00.29 /sbin/dump -0uanL -f - / (dump)

root    61366  0.0  0.0  3128  1184  p0  I+    1:47PM   0:00.29 /sbin/dump -0uanL -f - / (dump)

root    61367  0.0  0.0  3128  1184  p0  I+    1:47PM   0:00.29 /sbin/dump -0uanL -f - / (dump)

root    61382  0.0  0.0  1660   900  p1  R+    1:48PM   0:00.00 grep dump

========

btw, with dump and dar failing, I tried rdiff-backup which succeeded.

Thanks
Len


From qing.li at bluecoat.com  Sun Jul 12 19:28:30 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Sun Jul 12 19:28:47 2009
Subject: 8.0-BETA1 - for the record - different paths followed by IPv4
	and IPv6 for 'local' connections
References: <4A5734C3.3000806@restart.be>
	<B583FBF374231F4A89607B4D08578A4304673660@bcs-mail03.internal.cacheflow.com>
	<4A5864DC.1070106@restart.be>
Message-ID: <B583FBF374231F4A89607B4D08578A4304673665@bcs-mail03.internal.cacheflow.com>


The patch has been committed, svn revision 195643.

Thanks,

-- Qing


-----Original Message-----
From: Henri Hennebert [mailto:hlh@restart.be]
Sent: Sat 7/11/2009 3:09 AM
To: Li, Qing
Cc: freebsd-stable@freebsd.org; freebsd-net@freebsd.org
Subject: Re: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
 
Li, Qing wrote:
> Hi,
> 
> Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/
> and let me know how it works out for you. I thought I had committed the patch 
> but turned out I didn't.

I apply the patch, reset my pf.conf to its previous content and all is 
running smoothly. By the way, I discover after my post that my 
"solution" was not working for long (many bytes) connections and this is 
solved too.

Many thank for your time

Henri

PS please commit as soon as possible

> 
>> On 8.0-BETA1 there is an assymetry:
>>
>> netstat -rn display
>>
>> 192.168.24.1       link#3
>> ....
>> no entry for 2001:41d0:2:2d29:1:1::
>>
> 
> This is by design as part of the new architecture in 8.0, which maintains 
> the L2 ARP/ND6 and L3 routing tables separately.
> 
> -- Qing
> 
> 
> 
> -----Original Message-----
> From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert
> Sent: Fri 7/10/2009 5:32 AM
> To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org
> Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
>  
> Hello,
> 
> After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when 
> connecting with firefox to a local apache server using the global 
> unicast IPv6 address of the local machine. pf.conf must be updated!
> 
> My configuration:
> 
> [root@avoriaz ~]# ifconfig em0
> 
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> 	options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
> 	ether 00:1d:60:ad:2a:ce
> 	inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255
> 	inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1
> 	inet6 2001:41d0:2:2d29:1:1:: prefixlen 80
> 	media: Ethernet 100baseTX (100baseTX <half-duplex>)
> 	status: active
> 
> [root@avoriaz ~]# host www.restart.bel
> www.restart.bel is an alias for avoriaz.restart.bel.
> avoriaz.restart.bel has address 192.168.24.1
> avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1::
> 
> pf.conf:
> 
> int_if="em0"
> block in  log all
> block out log all
> set skip on lo0
> antispoof quick for $int_if inet
> # Allow trafic with physical internal network
> pass in quick on $int_if from ($int_if:network) to ($int_if) keep state
> pass out quick on $int_if from ($int_if) to ($int_if:network) keep state
> 
> The problem:
> 
> [root@avoriaz ~]# telnet -4 www.restart.bel 80
> Trying 192.168.24.1...
> Connected to avoriaz.restart.bel.
> Escape character is '^]'.
> ^]
> telnet> quit
> Connection closed.
> [root@avoriaz ~]# telnet -6 www.restart.bel 80
> Trying 2001:41d0:2:2d29:1:1::...
> --->Never connect and get a timeout!
> 
> tcpdump and logging in pf show me that
> 
> For a IPv4 connection:
> the packet from telnet to apache pass 2 times on lo0 (out and in)
> the answer packet from apache to telnet pass 2 times on lo0 (out and in)
> 
> So no problem, there is `set skip on lo0'
> 
> For a IPv6 connection:
> The first packet from telnet to apache pass 2 times on lo0 (out and in)
> The answer packet from apache to telnet path on em0  and is rejected
> due to the default flags S/SA.
> 
> So I have to change pf.conf and replace the last line:
> pass out quick on $int_if from ($int_if) to ($int_if:network) \
> keep state flags any
> 
> Then all is OK
> 
> By the way, on 7.2
> 
> netstat -rn display
> 
> 192.168.24.1        00:1d:60:ad:2a:ce
> ....
> 2001:41d0:2:2d29:1:1::            00:1d:60:ad:2a:ce
> 
> 
> On 8.0-BETA1 there is an assymetry:
> 
> netstat -rn display
> 
> 192.168.24.1       link#3
> ....
> no entry for 2001:41d0:2:2d29:1:1::
> 
> Hope it may help someone
> 
> Henri
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
> 


From repcsike at gmail.com  Mon Jul 13 07:13:38 2009
From: repcsike at gmail.com (=?ISO-8859-1?B?QmFs4XpzIE3hdOlmZnk=?=)
Date: Mon Jul 13 07:13:44 2009
Subject: Fwd: dump hangs on 7.1
In-Reply-To: <c4b701070907122341q7bef82bbwb0943c5fe3d1ff1d@mail.gmail.com>
References: <200907101829.AA227541664@mail.Go2France.com>
	<200907120914.50095.mel.flynn+fbsd.questions@mailing.thruhere.net>
	<200907122042515.SM01728@W500.Go2France.com>
	<c4b701070907122341q7bef82bbwb0943c5fe3d1ff1d@mail.gmail.com>
Message-ID: <c4b701070907122341g2295f285uab250d23d6bb7f1f@mail.gmail.com>

Hi,

I had a similar error with 7.0, and found reference that there was
problem(as far as I can remember there was an issue with large disk I/O and
creating snapshots on the partition).
Dump was creating the files, and it hanged, sometimes it finishes like once
in ten for small partitions. Every time hangs at pass 4, but for me
sometimes it was unable to get back to the shell with ctrl + c, I had to
close my ssh session, but I could fine the dump session in ps -ax.

I had the generic kernel, and I user freebsd-update to update to 7.2, now
it's working like a charm!

Because you don't have dump, please backup your system with another utility
before even thinking about the update, or you can still wait for the others
to tell you something useful.

Maybe some vmstat / gstat detail could be helpful to look up the resource
usage when dump hangs?

Best Regards,

Bal?zs.



2009/7/12 Len Conrad <LConrad@go2france.com>


> >On Friday 10 July 2009 08:29:01 Len Conrad wrote:
> >> FreeBSD 7.1-RELEASE #0: Thu Jan  1 14:37:25 UTC 2009
> >> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
> >>
> >> CPU: Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz (2496.26-MHz
> 686-class
> >> CPU) Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10
> >>   AMD Features=0x20100000<NX,LM>
> >>   AMD Features2=0x1<LAHF>
> >>   Cores per package: 4
> >> real memory  = 3484745728 (3323 MB)
> >> avail memory = 3405537280 (3247 MB)
> >> ACPI APIC Table: <DELL   PE_SC3  >
> >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> >>  cpu0 (BSP): APIC ID:  0
> >>  cpu1 (AP): APIC ID:  1
> >>  cpu2 (AP): APIC ID:  2
> >>  cpu3 (AP): APIC ID:  3
> >>
> >>
> >> /sbin/dump -0uanL -f - / | ssh dump_images@xxx.net dd
> >> of=/var/ftp/dump_images/mx1-root-test
> >>
> >> dump has completed only once. Several other dumps have all gotten under
> >> way, target file is created and increases until the hang.
> >>
> >> CTRL-C gets back to shell,eg:
> >>
> >>   DUMP: Date of this level 0 dump: Fri Jul 10 10:25:33 2009
> >>   DUMP: Date of last level 0 dump: the epoch
> >>   DUMP: Dumping snapshot of /dev/da0s1d (/usr) to standard output
> >>   DUMP: mapping (Pass I) [regular files]
> >>   DUMP: mapping (Pass II) [directories]
> >>   DUMP: estimated 1713942 tape blocks.
> >>   DUMP: dumping (Pass III) [directories]
> >>   DUMP: dumping (Pass IV) [regular files]
> >> ^C  DUMP: Interrupt received.
> >>   DUMP: Do you want to abort dump?: ("yes" or "no") Killed by signal 2.
> >>   DUMP: Broken pipe
> >>   DUMP: The ENTIRE dump is aborted.
> >>
> >> Hangs always in Pass IV
> >
> >What's the output ps -auwwx|grep dump at the time of the dump.
>
> when the dump hangs:
>
> ps auxww | grep dump
>
> root    61360  0.0  0.0  3128  1168  p0  I+    1:47PM   0:00.06 /sbin/dump
> -0uanL -f - / (dump)
>
> root    61361  0.0  0.1  5560  2768  p0  I+    1:47PM   0:03.65 ssh
> xxx@xxx.net dd of=/var/ftp/dump_images/mx1-root-test
>
> root    61364  0.0  0.0  3128  1528  p0  I+    1:47PM   0:00.36 dump:
> /dev/da0s1a: pass 4: 92.66% done, finished in 0:00 at Sun Jul 12 13:47:52
> 2009 (dump)
>
> root    61365  0.0  0.0  3128  1184  p0  I+    1:47PM   0:00.29 /sbin/dump
> -0uanL -f - / (dump)
>
> root    61366  0.0  0.0  3128  1184  p0  I+    1:47PM   0:00.29 /sbin/dump
> -0uanL -f - / (dump)
>
> root    61367  0.0  0.0  3128  1184  p0  I+    1:47PM   0:00.29 /sbin/dump
> -0uanL -f - / (dump)
>
> root    61382  0.0  0.0  1660   900  p1  R+    1:48PM   0:00.00 grep dump
>
> ========
>
> btw, with dump and dar failing, I tried rdiff-backup which succeeded.
>
> Thanks
> Len
>
>
> _______________________________________________
> 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"
>
From freebsdusb at bindone.de  Mon Jul 13 07:17:29 2009
From: freebsdusb at bindone.de (Michael Gmelin)
Date: Mon Jul 13 07:17:38 2009
Subject: Fwd: dump hangs on 7.1
In-Reply-To: <c4b701070907122341g2295f285uab250d23d6bb7f1f@mail.gmail.com>
References: <200907101829.AA227541664@mail.Go2France.com>	<200907120914.50095.mel.flynn+fbsd.questions@mailing.thruhere.net>	<200907122042515.SM01728@W500.Go2France.com>	<c4b701070907122341q7bef82bbwb0943c5fe3d1ff1d@mail.gmail.com>
	<c4b701070907122341g2295f285uab250d23d6bb7f1f@mail.gmail.com>
Message-ID: <4A5ADF84.7040506@bindone.de>

The problem you're referring to was fixed in 7.1 (we had the same issues
in 7.0 i386), so I don't think this is the problem Len is facing.

Bal?zs M?t?ffy wrote:
> Hi,
> 
> I had a similar error with 7.0, and found reference that there was
> problem(as far as I can remember there was an issue with large disk I/O and
> creating snapshots on the partition).
> Dump was creating the files, and it hanged, sometimes it finishes like once
> in ten for small partitions. Every time hangs at pass 4, but for me
> sometimes it was unable to get back to the shell with ctrl + c, I had to
> close my ssh session, but I could fine the dump session in ps -ax.
> 
> I had the generic kernel, and I user freebsd-update to update to 7.2, now
> it's working like a charm!
> 
> Because you don't have dump, please backup your system with another utility
> before even thinking about the update, or you can still wait for the others
> to tell you something useful.
> 
> Maybe some vmstat / gstat detail could be helpful to look up the resource
> usage when dump hangs?
> 
> Best Regards,
> 
> Bal?zs.
> 
> 
> 
> 2009/7/12 Len Conrad <LConrad@go2france.com>
> 
> 
>>> On Friday 10 July 2009 08:29:01 Len Conrad wrote:
>>>> FreeBSD 7.1-RELEASE #0: Thu Jan  1 14:37:25 UTC 2009
>>>> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>>>>
>>>> CPU: Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz (2496.26-MHz
>> 686-class
>>>> CPU) Origin = "GenuineIntel"  Id = 0x1067a  Stepping = 10
>>>>   AMD Features=0x20100000<NX,LM>
>>>>   AMD Features2=0x1<LAHF>
>>>>   Cores per package: 4
>>>> real memory  = 3484745728 (3323 MB)
>>>> avail memory = 3405537280 (3247 MB)
>>>> ACPI APIC Table: <DELL   PE_SC3  >
>>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>>>>  cpu0 (BSP): APIC ID:  0
>>>>  cpu1 (AP): APIC ID:  1
>>>>  cpu2 (AP): APIC ID:  2
>>>>  cpu3 (AP): APIC ID:  3
>>>>
>>>>
>>>> /sbin/dump -0uanL -f - / | ssh dump_images@xxx.net dd
>>>> of=/var/ftp/dump_images/mx1-root-test
>>>>
>>>> dump has completed only once. Several other dumps have all gotten under
>>>> way, target file is created and increases until the hang.
>>>>
>>>> CTRL-C gets back to shell,eg:
>>>>
>>>>   DUMP: Date of this level 0 dump: Fri Jul 10 10:25:33 2009
>>>>   DUMP: Date of last level 0 dump: the epoch
>>>>   DUMP: Dumping snapshot of /dev/da0s1d (/usr) to standard output
>>>>   DUMP: mapping (Pass I) [regular files]
>>>>   DUMP: mapping (Pass II) [directories]
>>>>   DUMP: estimated 1713942 tape blocks.
>>>>   DUMP: dumping (Pass III) [directories]
>>>>   DUMP: dumping (Pass IV) [regular files]
>>>> ^C  DUMP: Interrupt received.
>>>>   DUMP: Do you want to abort dump?: ("yes" or "no") Killed by signal 2.
>>>>   DUMP: Broken pipe
>>>>   DUMP: The ENTIRE dump is aborted.
>>>>
>>>> Hangs always in Pass IV
>>> What's the output ps -auwwx|grep dump at the time of the dump.
>> when the dump hangs:
>>
>> ps auxww | grep dump
>>
>> root    61360  0.0  0.0  3128  1168  p0  I+    1:47PM   0:00.06 /sbin/dump
>> -0uanL -f - / (dump)
>>
>> root    61361  0.0  0.1  5560  2768  p0  I+    1:47PM   0:03.65 ssh
>> xxx@xxx.net dd of=/var/ftp/dump_images/mx1-root-test
>>
>> root    61364  0.0  0.0  3128  1528  p0  I+    1:47PM   0:00.36 dump:
>> /dev/da0s1a: pass 4: 92.66% done, finished in 0:00 at Sun Jul 12 13:47:52
>> 2009 (dump)
>>
>> root    61365  0.0  0.0  3128  1184  p0  I+    1:47PM   0:00.29 /sbin/dump
>> -0uanL -f - / (dump)
>>
>> root    61366  0.0  0.0  3128  1184  p0  I+    1:47PM   0:00.29 /sbin/dump
>> -0uanL -f - / (dump)
>>
>> root    61367  0.0  0.0  3128  1184  p0  I+    1:47PM   0:00.29 /sbin/dump
>> -0uanL -f - / (dump)
>>
>> root    61382  0.0  0.0  1660   900  p1  R+    1:48PM   0:00.00 grep dump
>>
>> ========
>>
>> btw, with dump and dar failing, I tried rdiff-backup which succeeded.
>>
>> Thanks
>> Len
>>
>>
>> _______________________________________________
>> 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"
>>
> _______________________________________________
> 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"

From bugmaster at FreeBSD.org  Mon Jul 13 11:07:02 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jul 13 11:09:09 2009
Subject: Current problem reports assigned to freebsd-net@FreeBSD.org
Message-ID: <200907131107.n6DB70vh040701@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/136618  net        [pf][stf] panic on cloning interface without unit numb
o kern/136482  net        [age] Attansic L1 Gigabit Ethernet recieves multicasts
o kern/136168  net        [em] em driver initialization fails on Intel 5000PSL m
o kern/135836  net        [bce] bce BCM5709 Watchdog after warm boot - ok after 
o kern/135502  net        [periodic] Warning message raised by rtfree function i
o kern/135222  net        [igb] low speed routing between two igb interfaces
o kern/135067  net        [patch] [fib] Incorrect KASSERTs in sys/net/route.c
o kern/134931  net        [route] [fib] Route messages sent to all socket listen
o kern/134658  net        [bce] bce driver fails on PowerEdge m610 blade.
o kern/134583  net        [hang] Machine with jail freezes after random amount o
o kern/134531  net        [route] [panic] kernel crash related to routes/zebra
o kern/134401  net        [msk] [panic] Kernel Fatal trap 12: page fault while i
o kern/134369  net        [route] [ip6] IPV6 in Head broken for routing table up
o kern/134168  net        [ral] ral driver problem on RT2525 2.4GHz transceiver 
o kern/134157  net        [dummynet] dummynet loads cpu for 100% and make a syst
o kern/134079  net        [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8
o kern/133969  net        [dummynet] [panic] Fatal trap 12: page fault while in 
o kern/133968  net        [dummynet] [panic] dummynet kernel panic
o kern/133902  net        [tun] Killing tun0 iface ssh tunnel causes Panic Strin
o kern/133736  net        [udp] ip_id not protected ...
o kern/133613  net        [wpi] [panic] kernel panic in wpi(4)
o kern/133595  net        [panic] Kernel Panic at pcpu.h:195
o kern/133572  net        [ppp] [hang] incoming PPTP connection hangs the system
o kern/133490  net        [bpf] [panic] 'kmem_map too small' panic on Dell r900 
o kern/133328  net        [bge] [panic] Kernel panics with Windows7 client
o kern/133235  net        [netinet] [patch] Process SIOCDLIFADDR command incorre
o kern/133218  net        [carp] [hang] use of carp(4) causes system to freeze
o kern/133204  net        [msk] msk driver timeouts
o kern/133060  net        [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs
o kern/132991  net        [bge] if_bge low performance problem
o kern/132984  net        [netgraph] swi1: net 100% cpu usage
f bin/132911   net        ip6fw(8): argument type of fill_icmptypes is wrong and
o kern/132889  net        [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d
o kern/132885  net        [wlan] 802.1x broken after SVN rev 189592
o conf/132851  net        [fib] [patch] allow to setup fib for service running f
o kern/132832  net        [netinet] [patch] tcp_output() might generate invalid 
o bin/132798   net        [patch] ggatec(8): ggated/ggatec connection slowdown p
o kern/132734  net        [ifmib] [panic] panic in net/if_mib.c
o kern/132722  net        [ath] Wifi ath0 associates fine with AP, but DHCP or I
o kern/132705  net        [libwrap] [patch] libwrap - infinite loop if hosts.all
o kern/132672  net        [ndis] [panic] ndis with rt2860.sys causes kernel pani
o kern/132669  net        [xl] 3c905-TX send DUP! in reply on ping (sometime)
o kern/132625  net        [iwn] iwn drivers don't support setting country
o kern/132554  net        [ipl] There is no ippool start script/ipfilter magic t
o kern/132354  net        [nat] Getting some packages to ipnat(8) causes crash
o kern/132285  net        [carp] alias gives incorrect hash in dmesg
o kern/132277  net        [crypto] [ipsec] poor performance using cryptodevice f
o conf/132179  net        [patch] /etc/network.subr: ipv6 rtsol on incorrect wla
o kern/132107  net        [carp] carp(4) advskew setting ignored when carp IP us
o kern/131781  net        [ndis] ndis keeps dropping the link
o kern/131776  net        [wi] driver fails to init
o kern/131753  net        [altq] [panic] kernel panic in hfsc_dequeue
o bin/131567   net        [socket] [patch] Update for regression/sockets/unix_cm
o kern/131549  net        ifconfig(8) can't clear 'monitor' mode on the wireless
o kern/131536  net        [netinet] [patch] kernel does allow manipulation of su
o bin/131365   net        route(8): route add changes interpretation of network 
o kern/131162  net        [ath] Atheros driver bugginess and kernel crashes
o kern/131153  net        [iwi] iwi doesn't see a wireless network
f kern/131087  net        [ipw] [panic] ipw / iwi - no sent/received packets; iw
f kern/130820  net        [ndis] wpa_supplicant(8) returns 'no space on device'
o kern/130628  net        [nfs] NFS / rpc.lockd deadlock on 7.1-R
o conf/130555  net        [rc.d] [patch] No good way to set ipfilter variables a
o kern/130525  net        [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau
o kern/130311  net        [wlan_xauth] [panic] hostapd restart causing kernel pa
o kern/130109  net        [ipfw] Can not set fib for packets originated from loc
f kern/130059  net        [panic] Leaking 50k mbufs/hour
o kern/129750  net        [ath] Atheros AR5006 exits on "cannot map register spa
f kern/129719  net        [nfs] [panic] Panic during shutdown, tcp_ctloutput: in
o kern/129580  net        [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo
o kern/129517  net        [ipsec] [panic] double fault / stack overflow
o kern/129508  net        [carp] [panic] Kernel panic with EtherIP (may be relat
o kern/129352  net        [xl] [patch] xl0 watchdog timeout
o kern/129219  net        [ppp] Kernel panic when using kernel mode ppp
o kern/129197  net        [panic] 7.0 IP stack related panic
o kern/129135  net        [vge] vge driver on a VIA mini-ITX not working
o bin/128954   net        ifconfig(8) deletes valid routes
o kern/128917  net        [wpi] [panic] if_wpi and wpa+tkip causing kernel panic
o kern/128884  net        [msk] if_msk page fault while in kernel mode
o kern/128840  net        [igb] page fault under load with igb/LRO
o bin/128602   net        [an] wpa_supplicant(8) crashes with an(4)
o kern/128598  net        [bluetooth] WARNING: attempt to net_add_domain(bluetoo
o kern/128448  net        [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res
o conf/128334  net        [request] use wpa_cli in the "WPA DHCP" situation
o bin/128295   net        [patch] ifconfig(8) does not print TOE4 or TOE6 capabi
o bin/128001   net        wpa_supplicant(8), wlan(4), and wi(4) issues
o kern/127928  net        [tcp] [patch] TCP bandwidth gets squeezed every time t
o kern/127834  net        [ixgbe] [patch] wrong error counting
o kern/127826  net        [iwi] iwi0 driver has reduced performance and connecti
o kern/127815  net        [gif] [patch] if_gif does not set vlan attributes from
o kern/127724  net        [rtalloc] rtfree: 0xc5a8f870 has 1 refs
f bin/127719   net        [arp] arp: Segmentation fault (core dumped)
s kern/127587  net        [bge] [request] if_bge(4) doesn't support BCM576X fami
f kern/127528  net        [icmp]: icmp socket receives icmp replies not owned by
o bin/127192   net        routed(8) removes the secondary alias IP of interface 
f kern/127145  net        [wi]: prism (wi) driver crash at bigger traffic
o kern/127102  net        [wpi] Intel 3945ABG low throughput
o kern/127057  net        [udp] Unable to send UDP packet via IPv6 socket to IPv
o kern/127050  net        [carp] ipv6 does not work on carp interfaces [regressi
o kern/126945  net        [carp] CARP interface destruction with ifconfig destro
o kern/126924  net        [an] [patch] printf -> device_printf and simplify prob
o kern/126895  net        [patch] [ral] Add antenna selection (marked as TBD)
o kern/126874  net        [vlan]: Zebra problem if ifconfig vlanX destroy
o bin/126822   net        wpa_supplicant(8): WPA PSK does not work in adhoc mode
o kern/126714  net        [carp] CARP interface renaming makes system no longer 
o kern/126695  net        rtfree messages and network disruption upon use of if_
o kern/126688  net        [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and 
o kern/126475  net        [ath] [panic] ath pcmcia card inevitably panics under 
o kern/126339  net        [ipw] ipw driver drops the connection
o kern/126214  net        [ath] txpower problem with Atheros wifi card
o kern/126075  net        [inet] [patch] internet control accesses beyond end of
o bin/125922   net        [patch] Deadlock in arp(8)
o kern/125920  net        [arp] Kernel Routing Table loses Ethernet Link status 
o kern/125845  net        [netinet] [patch] tcp_lro_rx() should make use of hard
o kern/125816  net        [carp] [if_bridge] carp stuck in init when using bridg
f kern/125502  net        [ral] ifconfig ral0 scan produces no output unless in 
o kern/125258  net        [socket] socket's SO_REUSEADDR option does not work
o kern/125239  net        [gre] kernel crash when using gre
o kern/124767  net        [iwi] Wireless connection using iwi0 driver (Intel 220
o kern/124753  net        [ieee80211] net80211 discards power-save queue packets
o kern/124341  net        [ral] promiscuous mode for wireless device ral0 looses
o kern/124160  net        [libc] connect(2) function loops indefinitely
o kern/124127  net        [msk] watchdog timeout (missed Tx interrupts) -- recov
o kern/124021  net        [ip6] [panic] page fault in nd6_output()
o kern/123968  net        [rum] [panic] rum driver causes kernel panic with WPA.
p kern/123961  net        [vr] [patch] Allow vr interface to handle vlans
o kern/123892  net        [tap] [patch] No buffer space available
o kern/123890  net        [ppp] [panic] crash & reboot on work with PPP low-spee
o kern/123858  net        [stf] [patch] stf not usable behind a NAT
o kern/123796  net        [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not
o bin/123633   net        ifconfig(8) doesn't set inet and ether address in one 
f kern/123617  net        [tcp] breaking connection when client downloading file
o kern/123603  net        [tcp] tcp_do_segment and Received duplicate SYN
o kern/123559  net        [iwi] iwi periodically disassociates/associates [regre
o bin/123465   net        [ip6] route(8): route add -inet6 <ipv6_addr> -interfac
o kern/123463  net        [ipsec] [panic] repeatable crash related to ipsec-tool
o kern/123429  net        [nfe] [hang] "ifconfig nfe up" causes a hard system lo
o kern/123347  net        [bge] bge1: watchdog timeout -- linkstate changed to D
o conf/123330  net        [nsswitch.conf] Enabling samba wins in nsswitch.conf c
o kern/123256  net        [wpi] panic: blockable sleep lock with wpi(4)
f kern/123172  net        [bce] Watchdog timeout problems with if_bce
o kern/123160  net        [ip] Panic and reboot at sysctl kern.polling.enable=0
o kern/122989  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/122954  net        [lagg] IPv6 EUI64 incorrectly chosen for lagg devices
o kern/122928  net        [em] interface watchdog timeouts and stops receiving p
f kern/122839  net        [multicast] FreeBSD 7 multicast routing problem
p kern/122794  net        [lagg] Kernel panic after brings lagg(8) up if NICs ar
o kern/122780  net        [lagg] tcpdump on lagg interface during high pps wedge
o kern/122772  net        [em] em0 taskq panic, tcp reassembly bug causes radix 
o kern/122743  net        [mbuf] [panic] vm_page_unwire: invalid wire count: 0
o kern/122697  net        [ath] Atheros card is not well supported
o kern/122685  net        It is not visible passing packets in tcpdump(1)
o kern/122551  net        [bge] Broadcom 5715S no carrier on HP BL460c blade usi
o kern/122319  net        [wi] imposible to enable ad-hoc demo mode with Orinoco
o kern/122290  net        [netgraph] [panic] Netgraph related "kmem_map too smal
f kern/122252  net        [ipmi] [bge] IPMI problem with BCM5704 (does not work 
o kern/122195  net        [ed] Alignment problems in if_ed
o kern/122058  net        [em] [panic] Panic on em1: taskq
o kern/122033  net        [ral] [lor] Lock order reversal in ral0 at bootup [reg
o bin/121895   net        [patch] rtsol(8)/rtsold(8) doesn't handle managed netw
o kern/121872  net        [wpi] driver fails to attach on a fujitsu-siemens s711
s kern/121774  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/121706  net        [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit
o kern/121624  net        [em] [regression] Intel em WOL fails after upgrade to 
o kern/121555  net        [panic] Fatal trap 12: current process = 12 (swi1: net
o kern/121443  net        [gif] [lor] icmp6_input/nd6_lookup
o kern/121437  net        [vlan] Routing to layer-2 address does not work on VLA
o bin/121359   net        [patch] ppp(8): fix local stack overflow in ppp
o kern/121298  net        [em] [panic] Fatal trap 12: page fault while in kernel
o kern/121257  net        [tcp] TSO + natd  -> slow outgoing tcp traffic
o kern/121181  net        [panic] Fatal trap 3: breakpoint instruction fault whi
o kern/121080  net        [bge] IPv6 NUD problem on multi address config on bge0
o kern/120966  net        [rum] kernel panic with if_rum and WPA encryption
p docs/120945  net        [patch] ip6(4) man page lacks documentation for TCLASS
o kern/120566  net        [request]: ifconfig(8) make order of arguments more fr
o kern/120304  net        [netgraph] [patch] netgraph source assumes 32-bit time
o kern/120266  net        [udp] [panic] gnugk causes kernel panic when closing U
o kern/120232  net        [nfe] [patch] Bring in nfe(4) to RELENG_6
o kern/120130  net        [carp] [panic] carp causes kernel panics in any conste
o bin/120060   net        routed(8) deletes link-level routes in the presence of
o kern/119945  net        [rum] [panic] rum device in hostap mode, cause kernel 
o kern/119791  net        [nfs] UDP NFS mount of aliased IP addresses from a Sol
o kern/119617  net        [nfs] nfs error on wpa network when reseting/shutdown
f kern/119516  net        [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi
o kern/119432  net        [arp] route add -host <host> -iface <nic> causes arp e
o kern/119225  net        [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr
a bin/118987   net        ifconfig(8): ifconfig -l (address_family) does not wor
o sparc/118932 net        [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output
a kern/118879  net        [bge] [patch] bge has checksum problems on the 5703 ch
o kern/118727  net        [netgraph] [patch] [request] add new ng_pf module
a kern/118238  net        [bce] [patch] bce driver shows "no carrier" on Intel S
s kern/117717  net        [panic] Kernel panic with Bittorrent client.
o kern/117448  net        [carp] 6.2 kernel crash [regression]
o kern/117423  net        [vlan] Duplicate IP on different interfaces
o bin/117339   net        [patch] route(8): loading routing management commands 
o kern/117271  net        [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap
o kern/117043  net        [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM
o kern/116837  net        [tun] [panic] [patch] ifconfig tunX destroy: panic
o kern/116747  net        [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 
o bin/116643   net        [patch] [request] fstat(1): add INET/INET6 socket deta
o kern/116328  net        [bge]: Solid hang with bge interface
o kern/116185  net        [iwi] if_iwi driver leads system to reboot
o kern/115239  net        [ipnat] panic with 'kmem_map too small' using ipnat
o kern/115019  net        [netgraph] ng_ether upper hook packet flow stops on ad
o kern/115002  net        [wi] if_wi timeout. failed allocation (busy bit). ifco
o kern/114915  net        [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f
o kern/113895  net        [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R
o kern/112722  net        [ipsec] [udp] IP v4 udp fragmented packet reject
o kern/112686  net        [patm] patm driver freezes System (FreeBSD 6.2-p4) i38
o kern/112570  net        [bge] packet loss with bge driver on BCM5704 chipset
o bin/112557   net        [patch] ppp(8) lock file should not use symlink name
o kern/112528  net        [nfs] NFS over TCP under load hangs with "impossible p
o kern/111457  net        [ral] ral(4) freeze
o kern/110140  net        [ipw] ipw fails under load
o kern/109733  net        [bge] bge link state issues [regression]
o kern/109470  net        [wi] Orinoco Classic Gold PC Card Can't Channel Hop
o kern/109308  net        [pppd] [panic] Multiple panics kernel ppp suspected [r
o kern/109251  net        [re] [patch] if_re cardbus card won't attach
o bin/108895   net        pppd(8): PPPoE dead connections on 6.2 [regression]
o kern/108542  net        [bce] Huge network latencies with 6.2-RELEASE / STABLE
o kern/107944  net        [wi] [patch] Forget to unlock mutex-locks
o kern/107850  net        [bce] bce driver link negotiation is faulty
o conf/107035  net        [patch] bridge(8): bridge interface given in rc.conf n
o kern/106438  net        [ipf] ipfilter: keep state does not seem to allow repl
o kern/106316  net        [dummynet] dummynet with multipass ipfw drops packets 
o kern/106243  net        [nve] double fault panic in if_nve.c on high loads
o kern/105945  net        Address can disappear from network interface
s kern/105943  net        Network stack may modify read-only mbuf chain copies
o bin/105925   net        problems with ifconfig(8) and vlan(4) [regression]
o kern/105348  net        [ath] ath device stopps TX
o kern/104851  net        [inet6] [patch] On link routes not configured when usi
o kern/104751  net        [netgraph] kernel panic, when getting info about my tr
o kern/104485  net        [bge] Broadcom BCM5704C: Intermittent on newer chip ve
o kern/103191  net        Unpredictable reboot
o kern/103135  net        [ipsec] ipsec with ipfw divert (not NAT) encodes a pac
o conf/102502  net        [netgraph] [patch] ifconfig name does't rename netgrap
o kern/102035  net        [plip] plip networking disables parallel port printing
o kern/101948  net        [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau
o kern/100709  net        [libc] getaddrinfo(3) should return TTL info
o kern/100519  net        [netisr] suggestion to fix suboptimal network polling
o kern/98978   net        [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel
o kern/98597   net        [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu
o bin/98218    net        wpa_supplicant(8) blacklist not working
f bin/97392    net        ppp(8) hangs instead terminating
o kern/97306   net        [netgraph] NG_L2TP locks after connection with failed 
f kern/96268   net        [socket] TCP socket performance drops by 3000% if pack
o kern/96030   net        [bfe] [patch] Install hangs with Broadcomm 440x NIC in
o kern/95519   net        [ral] ral0 could not map mbuf
o kern/95288   net        [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr
o kern/95277   net        [netinet] [patch] IP Encapsulation mask_match() return
o kern/95267   net        packet drops periodically appear
s kern/94863   net        [bge] [patch] hack to get bge(4) working on IBM e326m
o kern/94162   net        [bge] 6.x kenel stale with bge(4)
o kern/93886   net        [ath] Atheros/D-Link DWL-G650 long delay to associate 
f kern/93378   net        [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo
o kern/93019   net        [ppp] ppp and tunX problems: no traffic after restarti
o kern/92880   net        [libc] [patch] almost rewritten inet_network(3) functi
f kern/92552   net        A serious bug in most network drivers from 5.X to 6.X 
s kern/92279   net        [dc] Core faults everytime I reboot, possible NIC issu
o kern/92090   net        [bge] bge0: watchdog timeout -- resetting
o kern/91859   net        [ndis] if_ndis does not work with Asus WL-138
s kern/91777   net        [ipf] [patch] wrong behaviour with skip rule inside an
o kern/91594   net        [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10
o kern/91364   net        [ral] [wep] WF-511 RT2500 Card PCI and WEP
o kern/91311   net        [aue] aue interface hanging
o kern/90890   net        [vr] Problems with network: vr0: tx shutdown timeout
s kern/90086   net        [hang] 5.4p8 on supermicro P8SCT hangs during boot if 
f kern/88082   net        [ath] [panic] cts protection for ath0 causes panic
o kern/87521   net        [ipf] [panic] using ipfilter "auth" keyword leads to k
o kern/87506   net        [vr] [patch] Fix alias support on vr interfaces
s kern/86920   net        [ndis] ifconfig: SIOCS80211: Invalid argument [regress
o kern/86103   net        [ipf] Illegal NAT Traversal in IPFilter
o kern/85780   net        'panic: bogus refcnt 0' in routing/ipv6
o bin/85445    net        ifconfig(8): deprecated keyword to ifconfig inoperativ
o kern/85266   net        [xe] [patch] xe(4) driver does not recognise Xircom XE
o kern/84202   net        [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre
o bin/82975    net        route change does not parse classfull network as given
o kern/82497   net        [vge] vge(4) on AMD64 only works when loaded late, not
f kern/81644   net        [vge] vge(4) does not work properly when loaded as a K
s kern/81147   net        [net] [patch] em0 reinitialization while adding aliase
o kern/80853   net        [ed] [patch] add support for Compex RL2000/ISA in PnP 
o kern/79895   net        [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 
f kern/79262   net        [dc] Adaptec ANA-6922 not fully supported
o bin/79228    net        [patch] extend arp(8) to be able to create blackhole r
o kern/78090   net        [ipf] ipf filtering on bridged packets doesn't work if
p kern/77913   net        [wi] [patch] Add the APDL-325 WLAN pccard to wi(4)
o kern/77341   net        [ip6] problems with IPV6 implementation
o kern/77273   net        [ipf] ipfilter breaks ipv6 statefull filtering on 5.3
s kern/77195   net        [ipf] [patch] ipfilter ioctl SIOCGNATL does not match 
o kern/75873   net        Usability problem with non-RFC-compliant IP spoof prot
s kern/75407   net        [an] an(4): no carrier after short time
f kern/73538   net        [bge] problem with the Broadcom BCM5788 Gigabit Ethern
o kern/71469   net        default route to internet magically disappears with mu
o kern/70904   net        [ipf] ipfilter ipnat problem with h323 proxy support
o kern/64556   net        [sis] if_sis short cable fix problems with NetGear FA3
s kern/60293   net        [patch] FreeBSD arp poison patch
o kern/54383   net        [nfs] [patch] NFS root configurations without dynamic 
f i386/45773   net        [bge] Softboot causes autoconf failure on Broadcom 570
s bin/41647    net        ifconfig(8) doesn't accept lladdr along with inet addr
s kern/39937   net        ipstealth issue
a kern/38554   net        [patch] changing interface ipaddress doesn't seem to w
o kern/35442   net        [sis] [patch] Problem transmitting runts in if_sis dri
o kern/34665   net        [ipf] [hang] ipfilter rcmd proxy "hangs".
o kern/31647   net        [libc] socket calls can return undocumented EINVAL
o kern/30186   net        [libc] getaddrinfo(3) does not handle incorrect servna
o kern/27474   net        [ipf] [ppp] Interactive use of user PPP and ipfilter c
o conf/23063   net        [arp] [patch] for static ARP tables in rc.network

306 problems total.

From linimon at FreeBSD.org  Mon Jul 13 15:14:03 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Mon Jul 13 15:14:15 2009
Subject: kern/136695: [ip] [patch] fwd reached after skipto in dynamic
	rules does not work in every case
Message-ID: <200907131514.n6DFE2Wg043111@freefall.freebsd.org>

Old Synopsis: fwd reached after skipto in dynamic rules does not work in every case [PATCH]
New Synopsis: [ip] [patch] fwd reached after skipto in dynamic rules does not work in every case

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jul 13 15:13:10 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136695
From rascal1981 at gmail.com  Mon Jul 13 15:30:00 2009
From: rascal1981 at gmail.com (rascal)
Date: Mon Jul 13 15:30:06 2009
Subject: question regarding IPSEC Setup
Message-ID: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>

So I have a couple of questions regarding a scenario that has recently been
brought to me.  I have two sites, one with a cisco device and one with a
server running freebsd 7.2.  The client wants to connect the two sites using
these devices and I am told that the best way would be to establish an IPSEC
tunnel between the cisco device and the freebsd server.  The cisco is a
concentrator 3000 and the server is just a dell poweredge 860 with 4 nics in
the back running 7.2 freebsd.  I guess my two questions are:

1.  Has anyone done this before and what are their results?
2.  Is setting up an IPSEC tunnel the best route for this or is there
something else I should be looking at?
3.  Any tips/tricks/good sites to check on for setting up IPSEC on freebsd
(I am currently reading
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html which
is pretty darn good)?

Thanks in advance for any help!!

---
Matthew
From atkin901 at yahoo.com  Mon Jul 13 17:25:50 2009
From: atkin901 at yahoo.com (Mark Atkinson)
Date: Mon Jul 13 17:25:56 2009
Subject: Regression: em driver in -CURRENT, "Invalid MAC address"
References: <gthe3t$822$1@ger.gmane.org>
	<2a41acea0905020803s63b69b1awb39538f000f5bd5a@mail.gmail.com>
	<h234fa$cob$1@ger.gmane.org>
	<2a41acea0906261725x57e6903br9f3f42b55f3a3d30@mail.gmail.com>
	<688430.20427.qm@web37906.mail.mud.yahoo.com>
	<2a41acea0906280952s23d6553ep42fcfd4671561c3a@mail.gmail.com>
	<2a41acea0907071722p7992bea0s281399cb0baecd90@mail.gmail.com>
Message-ID: <h3fqmb$ja2$1@ger.gmane.org>

Jack Vogel wrote:
> In case you hadn't seen it, the code that fixes this is now checked into
> the tip, so the latest em driver should work for you.

I upgraded the machine in question this morning and it appears to be 
working, thanks!

>>> em0: <Intel(R) PRO/1000 Network Connection 6.9.14> mem
>>> 0xdb000000-0xdb01ffff
>>> irq 28 at device 4.0 on pci19
>>> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb000000
>>>
>>> em0: Invalid MAC address
>>> device_attach: em0 attach returned 5
>>> em1: <Intel(R) PRO/1000 Network Connection 6.9.14> mem
>>> 0xdb020000-0xdb03ffff
>>> irq 29 at device 9.0 on pci19
>>> em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdb020000
>>>
>>> em1: Invalid MAC address
>>> device_attach: em1 attach returned 5

-- 
Mark Atkinson
atkin901@yahoo.com
(!wired)?(coffee++):(wired);


From josh at jtechcommunications.com  Mon Jul 13 20:30:04 2009
From: josh at jtechcommunications.com (Joshua Reynolds)
Date: Mon Jul 13 20:30:11 2009
Subject: kern/135222: [igb] low speed routing between two igb interfaces
Message-ID: <200907132030.n6DKU3J7083309@freefall.freebsd.org>

The following reply was made to PR kern/135222; it has been noted by GNATS.

From: Joshua Reynolds <josh@jtechcommunications.com>
To: bug-followup@FreeBSD.org,
 1@hnt.ru
Cc:  
Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces
Date: Mon, 13 Jul 2009 13:57:20 -0600

 --Apple-Mail-35-772384282
 Content-Type: text/plain;
 	charset=US-ASCII;
 	format=flowed;
 	delsp=yes
 Content-Transfer-Encoding: 7bit
 
 We had this same problem with our SuperMicro box and have been stumped  
 since switching our interface to igb.  Thanks Michael for the work  
 around... I hope they put this in the errata, it certainly would have  
 helped us a great deal.
 
 
 
 Best regards,
 
 Joshua Reynolds
 President
 J-Tech Communications
 
 jtechcommunications.com
 
 406-586-7100 (ph)
 406-586-1584 (fx)
 888-586-3000 (tf)
 
 
 --Apple-Mail-35-772384282
 Content-Type: text/html;
 	charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 
 <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
 -webkit-line-break: after-white-space; ">We had this same problem with =
 our SuperMicro box and have been stumped since switching our interface =
 to igb. &nbsp;Thanks&nbsp;Michael for the work around... I hope they put =
 this in the errata, it certainly would have helped us a great =
 deal.<br><div> <span class=3D"Apple-style-span" style=3D"border-collapse: =
 separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
 font-style: normal; font-variant: normal; font-weight: normal; =
 letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
 auto; text-indent: 0px; text-transform: none; white-space: normal; =
 widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
 -webkit-border-vertical-spacing: 0px; =
 -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
 auto; -webkit-text-stroke-width: 0px; "><div><div><div =
 style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
 margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
 Roman', serif; "><font class=3D"Apple-style-span" face=3D"Helvetica" =
 size=3D"3"><span class=3D"Apple-style-span" style=3D"font-size: 12px; =
 "><br class=3D"Apple-interchange-newline"><br =
 class=3D"Apple-interchange-newline"><br =
 class=3D"webkit-block-placeholder"></span></font></div><div =
 style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
 margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
 Roman', serif; "><span style=3D"font-size: 9pt; font-family: Helvetica, =
 sans-serif; color: black; ">Best regards,</span><span style=3D"color: =
 black; "><o:p></o:p></span></div></div></div><div><div><div =
 style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
 margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
 Roman', serif; "><span style=3D"font-size: 9pt; font-family: Helvetica, =
 sans-serif; color: black; ">&nbsp;</span><span style=3D"color: black; =
 "><o:p></o:p></span></div></div></div><div><div><div style=3D"margin-top: =
 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
 font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
 style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
 black; ">Joshua Reynolds</span><span style=3D"color: black; =
 "><o:p></o:p></span></div></div></div><div><div><div style=3D"margin-top: =
 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
 font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
 style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
 black; ">President</span><span style=3D"color: black; =
 "><o:p></o:p></span></div></div></div><div><div><div style=3D"margin-top: =
 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
 font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
 style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
 black; ">J-Tech Communications</span><span style=3D"color: black; =
 "><o:p></o:p></span></div></div></div><div><div><div style=3D"margin-top: =
 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
 font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
 style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
 black; ">&nbsp;</span><span style=3D"color: black; =
 "><o:p></o:p></span></div></div></div><div><div><div style=3D"margin-top: =
 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
 font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
 style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
 black; ">jtechcommunications.com</span><span style=3D"color: black; =
 "><o:p></o:p></span></div></div></div><div><div><div style=3D"margin-top: =
 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
 font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
 style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
 black; ">&nbsp;</span><span style=3D"color: black; =
 "><o:p></o:p></span></div></div></div><div><div><div style=3D"margin-top: =
 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
 font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
 style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
 black; ">406-586-7100 (ph)</span><span style=3D"color: black; =
 "><o:p></o:p></span></div></div></div><div><div><div style=3D"margin-top: =
 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
 font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
 style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
 black; ">406-586-1584 (fx)</span><span style=3D"color: black; =
 "><o:p></o:p></span></div></div></div><div><div><div style=3D"margin-top: =
 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
 font-size: 12pt; font-family: 'Times New Roman', serif; "><span =
 style=3D"font-size: 9pt; font-family: Helvetica, sans-serif; color: =
 black; ">888-586-3000 (tf)</span></div></div></div></span> =
 </div><br></body></html>=
 
 --Apple-Mail-35-772384282--
From rahmati at sepehrs.com  Mon Jul 13 22:35:10 2009
From: rahmati at sepehrs.com (Nasser Rahmati)
Date: Mon Jul 13 22:35:17 2009
Subject: test
Message-ID: <4A5AED6D.5090500@sepehrs.com>

Hello

-- 
With the best ragards

Nasser Rahmati
Sepehr S. T. Co. Ltd.
Tel:     +9821 88975701
Fax:     +9821 88983352
E-mail:  rahmati@sepehrs.com
Web:     http://www.sepehrs.com

From delphij at delphij.net  Tue Jul 14 00:42:17 2009
From: delphij at delphij.net (Xin LI)
Date: Tue Jul 14 00:42:50 2009
Subject: [LOR] carp vs bridge
Message-ID: <4A5BD40E.9080108@delphij.net>

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

Hi,

This LOR is observed in an environment with both CARP and bridge set up.
 Is this an known one?

lock order reversal:

 1st 0xffffff00033253e0 carp_if (carp_if) @
/usr/src/sys/netinet/ip_carp.c:1326
 2nd 0xffffff00031d1218 if_bridge (if_bridge) @
/usr/src/sys/net/if_bridge.c:1850
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_mtx_lock_flags() at _mtx_lock_flags+0x78
bridge_output() at bridge_output+0x67
ether_output() at ether_output+0x3d7
ip_output() at ip_output+0xd12
carp_send_ad_locked() at carp_send_ad_locked+0x54b
carp_master_down_locked() at carp_master_down_locked+0x79
carp_master_down() at carp_master_down+0x33
softclock() at softclock+0x291
intr_event_execute_handlers() at intr_event_execute_handlers+0x68
ithread_loop() at ithread_loop+0xb2
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
- --- trap 0, rip = 0, rsp = 0xffffff8000042d30, rbp = 0 ---

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iEYEARECAAYFAkpb0zcACgkQi+vbBBjt66Ci6wCfT/sMbpkSqbKacc2vHRK5fOpY
RugAn1w8iVoWFmz8xGYeJzuYS9yUWwy2
=bTB3
-----END PGP SIGNATURE-----
From glen.j.barber at gmail.com  Tue Jul 14 01:09:42 2009
From: glen.j.barber at gmail.com (Glen Barber)
Date: Tue Jul 14 01:09:49 2009
Subject: [LOR] carp vs bridge
In-Reply-To: <4A5BD40E.9080108@delphij.net>
References: <4A5BD40E.9080108@delphij.net>
Message-ID: <4ad871310907131747g6798c0b9j96a8ce5540f42289@mail.gmail.com>

On Mon, Jul 13, 2009 at 8:40 PM, Xin LI<delphij@delphij.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> This LOR is observed in an environment with both CARP and bridge set up.
> ?Is this an known one?
>
> lock order reversal:
>
> ?1st 0xffffff00033253e0 carp_if (carp_if) @
> /usr/src/sys/netinet/ip_carp.c:1326
> ?2nd 0xffffff00031d1218 if_bridge (if_bridge) @
> /usr/src/sys/net/if_bridge.c:1850
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x2e
> witness_checkorder() at witness_checkorder+0x81e
> _mtx_lock_flags() at _mtx_lock_flags+0x78
> bridge_output() at bridge_output+0x67
> ether_output() at ether_output+0x3d7
> ip_output() at ip_output+0xd12
> carp_send_ad_locked() at carp_send_ad_locked+0x54b
> carp_master_down_locked() at carp_master_down_locked+0x79
> carp_master_down() at carp_master_down+0x33
> softclock() at softclock+0x291
> intr_event_execute_handlers() at intr_event_execute_handlers+0x68
> ithread_loop() at ithread_loop+0xb2
> fork_exit() at fork_exit+0x12a
> fork_trampoline() at fork_trampoline+0xe
> - --- trap 0, rip = 0, rsp = 0xffffff8000042d30, rbp = 0 ---
>

I didn't see that particular LOR listed with the others:
http://sources.zabbadoz.net/freebsd/lor.html

Regards,

-- 
Glen Barber
From mav at FreeBSD.org  Tue Jul 14 07:25:17 2009
From: mav at FreeBSD.org (mav@FreeBSD.org)
Date: Tue Jul 14 07:25:24 2009
Subject: kern/132984: [netgraph] swi1: net 100% cpu usage
Message-ID: <200907140725.n6E7PGLa010984@freefall.freebsd.org>

Synopsis: [netgraph] swi1: net 100% cpu usage

State-Changed-From-To: open->closed
State-Changed-By: mav
State-Changed-When: Tue Jul 14 07:23:12 UTC 2009
State-Changed-Why: 
This is probably duplicate of solved kern/134557. Fix committed
to 8-CURRENT and merged to 7-STABLE on 2009-07-04.

http://www.freebsd.org/cgi/query-pr.cgi?pr=132984
From perryh at pluto.rain.com  Tue Jul 14 07:40:45 2009
From: perryh at pluto.rain.com (perryh@pluto.rain.com)
Date: Tue Jul 14 07:40:54 2009
Subject: question regarding IPSEC Setup
In-Reply-To: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
References: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
Message-ID: <4a5c340f.kgJItzxBrh6/yWqR%perryh@pluto.rain.com>

rascal <rascal1981@gmail.com> wrote:
> ... I have two sites, one with a cisco device and one with a
> server running freebsd 7.2.  The client wants to connect the two
> sites using these devices and I am told that the best way would
> be to establish an IPSEC tunnel between the cisco device and the
> freebsd server.  The cisco is a concentrator 3000 and the server
> is just a dell poweredge 860 with 4 nics in the back running 7.2
> freebsd.  I guess my two questions are:
>
> 1.  Has anyone done this before and what are their results?
> 2.  Is setting up an IPSEC tunnel the best route for
> this or is there something else I should be looking at?
> 3.  Any tips/tricks/good sites to check on for
> setting up IPSEC on freebsd (I am currently reading
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html
> which is pretty darn good)?

I am no expert, just a user:  my employer uses Cisco VPN for remote
access.  Last I knew Cisco had VPN clients available for Windows and
for (some version of) Linux.  There's no official FreeBSD client
AFAIK, but ports/security/vpnc seems to work well for the purpose.

I have no idea how the Cisco end is set up, but have gotten the
impression that it may involve some sort of Cisco proprietary
extensions to IPSEC.
From bz at FreeBSD.org  Tue Jul 14 08:12:47 2009
From: bz at FreeBSD.org (bz@FreeBSD.org)
Date: Tue Jul 14 08:12:58 2009
Subject: kern/136695: [ipfw] [patch] fwd reached after skipto in dynamic
	rules does not work in every case
Message-ID: <200907140812.n6E8CkPX076050@freefall.freebsd.org>

Old Synopsis: [ip] [patch] fwd reached after skipto in dynamic rules does not work in every case
New Synopsis: [ipfw] [patch] fwd reached after skipto in dynamic rules does not work in every case

Responsible-Changed-From-To: freebsd-net->freebsd-ipfw
Responsible-Changed-By: bz
Responsible-Changed-When: Tue Jul 14 08:12:22 UTC 2009
Responsible-Changed-Why: 
Re-assign to the right list.

http://www.freebsd.org/cgi/query-pr.cgi?pr=136695
From john at dnepro.net  Tue Jul 14 13:56:04 2009
From: john at dnepro.net (Eugene Perevyazko)
Date: Tue Jul 14 13:56:11 2009
Subject: question regarding IPSEC Setup
In-Reply-To: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
References: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
Message-ID: <20090714134131.GA23925@traktor.dnepro.net>

On Mon, Jul 13, 2009 at 11:09:11AM -0400, rascal wrote:
> So I have a couple of questions regarding a scenario that has recently been
> brought to me.  I have two sites, one with a cisco device and one with a
> server running freebsd 7.2.  The client wants to connect the two sites using
> these devices and I am told that the best way would be to establish an IPSEC
> tunnel between the cisco device and the freebsd server.  The cisco is a
> concentrator 3000 and the server is just a dell poweredge 860 with 4 nics in
> the back running 7.2 freebsd.  I guess my two questions are:
> 
> 1.  Has anyone done this before and what are their results?

I'm using several IPSec tunnels between cisco 851's  and freebsd routers.
It "just works". 

> 2.  Is setting up an IPSEC tunnel the best route for this or is there
> something else I should be looking at?
IPSec is the standard for tunnels over internet. Cisco VPN requires their proprietary client, OpenVPN is not for ciscos.

> 3.  Any tips/tricks/good sites to check on for setting up IPSEC on freebsd
> (I am currently reading
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html which
> is pretty darn good)?
I use IPSec tunnels without gif interface on freebsd, don't know if it will work with it. I declare policy in /etc/ipsec.conf, and use racoon (ports/security/ipsec-tools) to do all the rest. It's pretty simple on cisco side too. Just say if you need an example.

-- 
Eugene Perevyazko
From kfl at xiplink.com  Tue Jul 14 14:14:10 2009
From: kfl at xiplink.com (Karim Fodil-Lemelin)
Date: Tue Jul 14 14:14:16 2009
Subject: kern/124127: [msk] watchdog timeout (missed Tx interrupts) --
 recovering
In-Reply-To: <200907080510.n685A5o7048654@freefall.freebsd.org>
References: <200907080510.n685A5o7048654@freefall.freebsd.org>
Message-ID: <4A5C8F17.8030008@xiplink.com>

Hello,

We have seen the problem reappear on msk driver (after the applying the 
latest patch in gnats). The patch did improve things tremendously but 
now the watchdog will timeout after 7 or 8 hours of flawless activity 
(before the patch it would happen right away on the first transfer).

Using the legacy interrupt sysctl (on top of the patched kernel atm) is 
giving us better result, haven't seen a failure in days now.

Regards,

Karim.
From rascal1981 at gmail.com  Tue Jul 14 16:18:21 2009
From: rascal1981 at gmail.com (rascal)
Date: Tue Jul 14 16:18:27 2009
Subject: question regarding IPSEC Setup
In-Reply-To: <20090714134131.GA23925@traktor.dnepro.net>
References: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
	<20090714134131.GA23925@traktor.dnepro.net>
Message-ID: <3228ef7c0907140918i5d90dc44q995a4210f2767f9a@mail.gmail.com>

Thanks for the input on this everyone!  Eugene, I'll take you up on your
offer of examples!  I have a good idea of how to do this, I just want to
make sure I get it right and if I have some examples to compare to that
would be great!  Thanks much!

On Tue, Jul 14, 2009 at 9:41 AM, Eugene Perevyazko <john@dnepro.net> wrote:

> On Mon, Jul 13, 2009 at 11:09:11AM -0400, rascal wrote:
> > So I have a couple of questions regarding a scenario that has recently
> been
> > brought to me.  I have two sites, one with a cisco device and one with a
> > server running freebsd 7.2.  The client wants to connect the two sites
> using
> > these devices and I am told that the best way would be to establish an
> IPSEC
> > tunnel between the cisco device and the freebsd server.  The cisco is a
> > concentrator 3000 and the server is just a dell poweredge 860 with 4 nics
> in
> > the back running 7.2 freebsd.  I guess my two questions are:
> >
> > 1.  Has anyone done this before and what are their results?
>
> I'm using several IPSec tunnels between cisco 851's  and freebsd routers.
> It "just works".
>
> > 2.  Is setting up an IPSEC tunnel the best route for this or is there
> > something else I should be looking at?
> IPSec is the standard for tunnels over internet. Cisco VPN requires their
> proprietary client, OpenVPN is not for ciscos.
>
> > 3.  Any tips/tricks/good sites to check on for setting up IPSEC on
> freebsd
> > (I am currently reading
> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.htmlwhich
> > is pretty darn good)?
> I use IPSec tunnels without gif interface on freebsd, don't know if it will
> work with it. I declare policy in /etc/ipsec.conf, and use racoon
> (ports/security/ipsec-tools) to do all the rest. It's pretty simple on cisco
> side too. Just say if you need an example.
>
> --
> Eugene Perevyazko
> _______________________________________________
> 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"
>
From ivoras at freebsd.org  Tue Jul 14 17:20:06 2009
From: ivoras at freebsd.org (Ivan Voras)
Date: Tue Jul 14 17:20:12 2009
Subject: HEADS UP: projects/mesh11s committed to HEAD
In-Reply-To: <D2CA8D0A-AF0A-4C05-BA0E-DD714A7BCB9C@freebsd.org>
References: <D2CA8D0A-AF0A-4C05-BA0E-DD714A7BCB9C@freebsd.org>
Message-ID: <h3ieih$kpu$2@ger.gmane.org>

Rui Paulo wrote:
> Hi,
> Just a heads up to note that 802.11s D3.0 support has been committed to
> HEAD. If you notice any wireless related problems, please inform me ASAP.

Hi,

Any short tutorials on how to use it? For example with a couple of laptops?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090714/0ee8e34a/signature.pgp
From fox at verio.net  Wed Jul 15 00:39:50 2009
From: fox at verio.net (David DeSimone)
Date: Wed Jul 15 00:40:00 2009
Subject: question regarding IPSEC Setup
In-Reply-To: <3228ef7c0907140918i5d90dc44q995a4210f2767f9a@mail.gmail.com>
References: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
	<20090714134131.GA23925@traktor.dnepro.net>
	<3228ef7c0907140918i5d90dc44q995a4210f2767f9a@mail.gmail.com>
Message-ID: <20090715001514.GU6896@verio.net>

rascal <rascal1981@gmail.com> wrote:
>
> Thanks for the input on this everyone!  Eugene, I'll take you up on
> your offer of examples!  I have a good idea of how to do this, I
> just want to make sure I get it right and if I have some examples to
> compare to that would be great!  Thanks much!

Here is an example IPSEC config that we use, that interoperates with
Cisco, Checkpoint, and probably other standard IPSEC implementations.

We're using PF for firewalling.

Example config:

    Here:  11.22.33.44	(FreeBSD machine)

	Networks behind:
	    10.10.30.40/24
	    10.10.30.50/24

    There:  55.66.77.88  (Some other IPSEC)

	Networks behind:
	    10.20.50.60/24
	    10.20.50.70/24

    Parameters:
	IKE:
	    Phase 1:
		Pre-shared Secret
		AES + SHA1
		DH Group 2
		Lifetime 24 hours
	    Phase 2:
		One SPI per subnet pair
		No PFS
		Lifetime 1 hour
	ESP:
	    AES + SHA1

Kernel build options:

    options  IPSEC
    options  IPSEC_ESP
    options  IPSEC_DEBUG

/etc/rc.conf:

    gateway_enable="YES"

    pf_enable="YES"
    pf_rules="/usr/local/etc/pf.conf"

    racoon_enable="YES"
    ipsec_enable="YES"
    ipsec_file="/usr/local/etc/ipsec.conf"

Partial /usr/local/etc/pf.conf:

    EXT="dc0"                       # Interface for external traffic
    EXTIP="(dc0)"                   # External virtual IP

    table <IPSEC_PEERS> file "/usr/local/etc/ipsec.peers"

    pass in log quick on $EXT proto udp from <IPSEC_PEERS> to $EXTIP port 500 keep state
    pass in     quick on $EXT proto esp from <IPSEC_PEERS> to $EXTIP          keep state

/usr/local/etc/ipsec.peers:

    55.66.77.88

/usr/local/etc/ipsec.conf:

    spdflush;

    spdadd 10.20.50.60/24  10.10.30.40/24  any \
	-P in  ipsec esp/tunnel/55.66.77.88-11.22.33.44/unique;
    spdadd 10.10.30.40/24  10.20.50.60/24  any \
	-P out ipsec esp/tunnel/11.22.33.44-55.66.77.88/unique;

    spdadd 10.20.50.60/24  10.10.30.50/24  any \
	-P in  ipsec esp/tunnel/55.66.77.88-11.22.33.44/unique;
    spdadd 10.10.30.50/24  10.20.50.60/24  any \
	-P out ipsec esp/tunnel/11.22.33.44-55.66.77.88/unique;

    spdadd 10.20.50.70/24  10.10.30.40/24  any \
	-P in  ipsec esp/tunnel/55.66.77.88-11.22.33.44/unique;
    spdadd 10.10.30.40/24  10.20.50.70/24  any \
	-P out ipsec esp/tunnel/11.22.33.44-55.66.77.88/unique;

    spdadd 10.20.50.70/24  10.10.30.50/24  any \
	-P in  ipsec esp/tunnel/55.66.77.88-11.22.33.44/unique;
    spdadd 10.10.30.50/24  10.20.50.70/24  any \
	-P out ipsec esp/tunnel/11.22.33.44-55.66.77.88/unique;

/usr/local/etc/racoon/racoon.conf:

    log  debug;             # notify(*), debug, debug2

    path  pre_shared_key  "/usr/local/etc/ipsec.keys";
    path  pidfile         "/var/run/racoon.pid";

    listen
    {
	isakmp  11.22.33.44;
	strict_address;             # Needed?
    }

    remote  55.66.77.88
    {
	exchange_mode  aggressive,main,base;

	my_identifier     address  11.22.33.44;
	peers_identifier  address  55.66.77.88;

	verify_identifier  off;

	proposal_check  claim;      # obey, strict, claim(*), exact(*)

	proposal
	{
	    encryption_algorithm    aes;
	    hash_algorithm          sha1;
	    authentication_method   pre_shared_key;
	    dh_group                2;
	    lifetime        time    24 hours;
	}
    }


    sainfo  address  10.20.50.60/24 any   address  10.10.30.40/24 any
    {
	lifetime            time    1 hour;

	encryption_algorithm        aes;
	authentication_algorithm    hmac_sha1;
	compression_algorithm       deflate;
    }

    sainfo  address  10.10.30.40/24 any   address  10.20.50.60/24 any
    {
	lifetime            time    1 hour;

	encryption_algorithm        aes;
	authentication_algorithm    hmac_sha1;
	compression_algorithm       deflate;
    }

    sainfo  address  10.20.50.60/24 any   address  10.10.30.50/24 any
    {
	lifetime            time    1 hour;

	encryption_algorithm        aes;
	authentication_algorithm    hmac_sha1;
	compression_algorithm       deflate;
    }

    sainfo  address  10.10.30.50/24 any   address  10.20.50.60/24 any
    {
	lifetime            time    1 hour;

	encryption_algorithm        aes;
	authentication_algorithm    hmac_sha1;
	compression_algorithm       deflate;
    }

    sainfo  address  10.20.50.70/24 any   address  10.10.30.40/24 any
    {
	lifetime            time    1 hour;

	encryption_algorithm        aes;
	authentication_algorithm    hmac_sha1;
	compression_algorithm       deflate;
    }

    sainfo  address  10.10.30.40/24 any   address  10.20.50.70/24 any
    {
	lifetime            time    1 hour;

	encryption_algorithm        aes;
	authentication_algorithm    hmac_sha1;
	compression_algorithm       deflate;
    }

    sainfo  address  10.20.50.70/24 any   address  10.10.30.50/24 any
    {
	lifetime            time    1 hour;

	encryption_algorithm        aes;
	authentication_algorithm    hmac_sha1;
	compression_algorithm       deflate;
    }

    sainfo  address  10.10.30.50/24 any   address  10.20.50.70/24 any
    {
	lifetime            time    1 hour;

	encryption_algorithm        aes;
	authentication_algorithm    hmac_sha1;
	compression_algorithm       deflate;
    }

/usr/local/etc/ipsec.keys:   (chmod 600!)

    # Keys for IPSEC
    # Remote IP, shared key

    55.66.77.88    SecretKey!!


The main difficulty is making sure you've got every different direction
of source and destination subnet cross-referenced in your SPD config and
the exact same entries configured in your racoon config.

In our setup, we auto-generate these files from a master config file,
but regretably I cannot release the code for this...


Anyway, I hope this gives you some idea how to setup IPSEC.  Debugging
is of course the next step.  Never assume that your peer has configured
everything right.  :)

Make sure your ipsec.keys file is not readable by anyone but root, or
raccoon will silently ignore it.

-- 
David DeSimone == Network Admin == fox@verio.net
  "I don't like spinach, and I'm glad I don't, because if I
   liked it I'd eat it, and I just hate it." -- Clarence Darrow


This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free.  Thank you.
From rascal1981 at gmail.com  Wed Jul 15 01:43:59 2009
From: rascal1981 at gmail.com (rascal)
Date: Wed Jul 15 01:44:07 2009
Subject: question regarding IPSEC Setup
In-Reply-To: <20090715001514.GU6896@verio.net>
References: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
	<20090714134131.GA23925@traktor.dnepro.net>
	<3228ef7c0907140918i5d90dc44q995a4210f2767f9a@mail.gmail.com>
	<20090715001514.GU6896@verio.net>
Message-ID: <3228ef7c0907141843s30df148eu2c6c64acd7748029@mail.gmail.com>

Thanks very much David, I really appreciate it!

I have the racoon2 package; does this make a big difference or do these
configs work close to the same?

On Tue, Jul 14, 2009 at 8:15 PM, David DeSimone <fox@verio.net> wrote:

> rascal <rascal1981@gmail.com> wrote:
> >
> > Thanks for the input on this everyone!  Eugene, I'll take you up on
> > your offer of examples!  I have a good idea of how to do this, I
> > just want to make sure I get it right and if I have some examples to
> > compare to that would be great!  Thanks much!
>
> Here is an example IPSEC config that we use, that interoperates with
> Cisco, Checkpoint, and probably other standard IPSEC implementations.
>
> We're using PF for firewalling.
>
> Example config:
>
>    Here:  11.22.33.44  (FreeBSD machine)
>
>        Networks behind:
>            10.10.30.40/24
>            10.10.30.50/24
>
>    There:  55.66.77.88  (Some other IPSEC)
>
>        Networks behind:
>            10.20.50.60/24
>            10.20.50.70/24
>
>    Parameters:
>        IKE:
>            Phase 1:
>                Pre-shared Secret
>                AES + SHA1
>                DH Group 2
>                Lifetime 24 hours
>            Phase 2:
>                One SPI per subnet pair
>                No PFS
>                Lifetime 1 hour
>        ESP:
>            AES + SHA1
>
> Kernel build options:
>
>    options  IPSEC
>    options  IPSEC_ESP
>    options  IPSEC_DEBUG
>
> /etc/rc.conf:
>
>    gateway_enable="YES"
>
>    pf_enable="YES"
>    pf_rules="/usr/local/etc/pf.conf"
>
>    racoon_enable="YES"
>    ipsec_enable="YES"
>    ipsec_file="/usr/local/etc/ipsec.conf"
>
> Partial /usr/local/etc/pf.conf:
>
>    EXT="dc0"                       # Interface for external traffic
>    EXTIP="(dc0)"                   # External virtual IP
>
>    table <IPSEC_PEERS> file "/usr/local/etc/ipsec.peers"
>
>    pass in log quick on $EXT proto udp from <IPSEC_PEERS> to $EXTIP port
> 500 keep state
>    pass in     quick on $EXT proto esp from <IPSEC_PEERS> to $EXTIP
>  keep state
>
> /usr/local/etc/ipsec.peers:
>
>    55.66.77.88
>
> /usr/local/etc/ipsec.conf:
>
>    spdflush;
>
>    spdadd 10.20.50.60/24  10.10.30.40/24  any \
>        -P in  ipsec esp/tunnel/55.66.77.88-11.22.33.44/unique;
>    spdadd 10.10.30.40/24  10.20.50.60/24  any \
>        -P out ipsec esp/tunnel/11.22.33.44-55.66.77.88/unique;
>
>    spdadd 10.20.50.60/24  10.10.30.50/24  any \
>        -P in  ipsec esp/tunnel/55.66.77.88-11.22.33.44/unique;
>    spdadd 10.10.30.50/24  10.20.50.60/24  any \
>        -P out ipsec esp/tunnel/11.22.33.44-55.66.77.88/unique;
>
>    spdadd 10.20.50.70/24  10.10.30.40/24  any \
>        -P in  ipsec esp/tunnel/55.66.77.88-11.22.33.44/unique;
>    spdadd 10.10.30.40/24  10.20.50.70/24  any \
>        -P out ipsec esp/tunnel/11.22.33.44-55.66.77.88/unique;
>
>    spdadd 10.20.50.70/24  10.10.30.50/24  any \
>        -P in  ipsec esp/tunnel/55.66.77.88-11.22.33.44/unique;
>    spdadd 10.10.30.50/24  10.20.50.70/24  any \
>        -P out ipsec esp/tunnel/11.22.33.44-55.66.77.88/unique;
>
> /usr/local/etc/racoon/racoon.conf:
>
>    log  debug;             # notify(*), debug, debug2
>
>    path  pre_shared_key  "/usr/local/etc/ipsec.keys";
>    path  pidfile         "/var/run/racoon.pid";
>
>    listen
>    {
>        isakmp  11.22.33.44;
>        strict_address;             # Needed?
>    }
>
>    remote  55.66.77.88
>    {
>        exchange_mode  aggressive,main,base;
>
>        my_identifier     address  11.22.33.44;
>        peers_identifier  address  55.66.77.88;
>
>        verify_identifier  off;
>
>        proposal_check  claim;      # obey, strict, claim(*), exact(*)
>
>        proposal
>        {
>            encryption_algorithm    aes;
>            hash_algorithm          sha1;
>            authentication_method   pre_shared_key;
>            dh_group                2;
>            lifetime        time    24 hours;
>        }
>    }
>
>
>    sainfo  address  10.20.50.60/24 any   address  10.10.30.40/24 any
>    {
>        lifetime            time    1 hour;
>
>        encryption_algorithm        aes;
>        authentication_algorithm    hmac_sha1;
>        compression_algorithm       deflate;
>    }
>
>    sainfo  address  10.10.30.40/24 any   address  10.20.50.60/24 any
>    {
>        lifetime            time    1 hour;
>
>        encryption_algorithm        aes;
>        authentication_algorithm    hmac_sha1;
>        compression_algorithm       deflate;
>    }
>
>    sainfo  address  10.20.50.60/24 any   address  10.10.30.50/24 any
>    {
>        lifetime            time    1 hour;
>
>        encryption_algorithm        aes;
>        authentication_algorithm    hmac_sha1;
>        compression_algorithm       deflate;
>    }
>
>    sainfo  address  10.10.30.50/24 any   address  10.20.50.60/24 any
>    {
>        lifetime            time    1 hour;
>
>        encryption_algorithm        aes;
>        authentication_algorithm    hmac_sha1;
>        compression_algorithm       deflate;
>    }
>
>    sainfo  address  10.20.50.70/24 any   address  10.10.30.40/24 any
>    {
>        lifetime            time    1 hour;
>
>        encryption_algorithm        aes;
>        authentication_algorithm    hmac_sha1;
>        compression_algorithm       deflate;
>    }
>
>    sainfo  address  10.10.30.40/24 any   address  10.20.50.70/24 any
>    {
>        lifetime            time    1 hour;
>
>        encryption_algorithm        aes;
>        authentication_algorithm    hmac_sha1;
>        compression_algorithm       deflate;
>    }
>
>    sainfo  address  10.20.50.70/24 any   address  10.10.30.50/24 any
>    {
>        lifetime            time    1 hour;
>
>        encryption_algorithm        aes;
>        authentication_algorithm    hmac_sha1;
>        compression_algorithm       deflate;
>    }
>
>    sainfo  address  10.10.30.50/24 any   address  10.20.50.70/24 any
>    {
>        lifetime            time    1 hour;
>
>        encryption_algorithm        aes;
>        authentication_algorithm    hmac_sha1;
>        compression_algorithm       deflate;
>    }
>
> /usr/local/etc/ipsec.keys:   (chmod 600!)
>
>    # Keys for IPSEC
>    # Remote IP, shared key
>
>    55.66.77.88    SecretKey!!
>
>
> The main difficulty is making sure you've got every different direction
> of source and destination subnet cross-referenced in your SPD config and
> the exact same entries configured in your racoon config.
>
> In our setup, we auto-generate these files from a master config file,
> but regretably I cannot release the code for this...
>
>
> Anyway, I hope this gives you some idea how to setup IPSEC.  Debugging
> is of course the next step.  Never assume that your peer has configured
> everything right.  :)
>
> Make sure your ipsec.keys file is not readable by anyone but root, or
> raccoon will silently ignore it.
>
> --
> David DeSimone == Network Admin == fox@verio.net
>  "I don't like spinach, and I'm glad I don't, because if I
>   liked it I'd eat it, and I just hate it." -- Clarence Darrow
>
>
> This email message is intended for the use of the person to whom it has
> been sent, and may contain information that is confidential or legally
> protected. If you are not the intended recipient or have received this
> message in error, you are not authorized to copy, distribute, or otherwise
> use this message or its attachments. Please notify the sender immediately by
> return e-mail and permanently delete this message and any attachments.
> Verio, Inc. makes no warranty that this email is error or virus free.  Thank
> you.
>
From fox at verio.net  Wed Jul 15 02:12:55 2009
From: fox at verio.net (David DeSimone)
Date: Wed Jul 15 02:13:02 2009
Subject: question regarding IPSEC Setup
In-Reply-To: <3228ef7c0907141843s30df148eu2c6c64acd7748029@mail.gmail.com>
References: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
	<20090714134131.GA23925@traktor.dnepro.net>
	<3228ef7c0907140918i5d90dc44q995a4210f2767f9a@mail.gmail.com>
	<20090715001514.GU6896@verio.net>
	<3228ef7c0907141843s30df148eu2c6c64acd7748029@mail.gmail.com>
Message-ID: <20090715021251.GV6896@verio.net>

rascal <rascal1981@gmail.com> wrote:
>
> I have the racoon2 package; does this make a big difference or do
> these configs work close to the same?

I did not have any luck using racoon2 because apparently it does not
interoperate well with older IPSEC implementations.  At least, it did
not a couple of years ago when I set up my IPSEC.

What you probably want is the security/ipsec-tools port, which contains
the original racoon IKE daemon.

-- 
David DeSimone == Network Admin == fox@verio.net
  "I don't like spinach, and I'm glad I don't, because if I
   liked it I'd eat it, and I just hate it." -- Clarence Darrow


This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free.  Thank you.
From rascal1981 at gmail.com  Wed Jul 15 03:01:58 2009
From: rascal1981 at gmail.com (rascal)
Date: Wed Jul 15 03:02:06 2009
Subject: question regarding IPSEC Setup
In-Reply-To: <20090715021251.GV6896@verio.net>
References: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
	<20090714134131.GA23925@traktor.dnepro.net>
	<3228ef7c0907140918i5d90dc44q995a4210f2767f9a@mail.gmail.com>
	<20090715001514.GU6896@verio.net>
	<3228ef7c0907141843s30df148eu2c6c64acd7748029@mail.gmail.com>
	<20090715021251.GV6896@verio.net>
Message-ID: <3228ef7c0907142001y650892b3w696576647086ba38@mail.gmail.com>

very good then, I'll have to uninstall racoon2/install the ipsectools.  I
must have missed when I installed ipsectools but no worries.  If I could ask
one more favor; what does your cisco config look like that would match one
of these?  I have got mine configed based on someone else's tunnel specs and
while I am sure they are comparable I wanted to make sure I wasn't missing
anything.  I was trying to go off of this:
http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2002-09/11533.html
But it's a little outdated and wanted to make sure I was doing it
correctly.  It sounds like I am on the right path for this, just a few more
pieces to go!  Thanks very much again for the help!

On Tue, Jul 14, 2009 at 10:12 PM, David DeSimone <fox@verio.net> wrote:

> rascal <rascal1981@gmail.com> wrote:
> >
> > I have the racoon2 package; does this make a big difference or do
> > these configs work close to the same?
>
> I did not have any luck using racoon2 because apparently it does not
> interoperate well with older IPSEC implementations.  At least, it did
> not a couple of years ago when I set up my IPSEC.
>
> What you probably want is the security/ipsec-tools port, which contains
> the original racoon IKE daemon.
>
> --
> David DeSimone == Network Admin == fox@verio.net
>  "I don't like spinach, and I'm glad I don't, because if I
>   liked it I'd eat it, and I just hate it." -- Clarence Darrow
>
>
> This email message is intended for the use of the person to whom it has
> been sent, and may contain information that is confidential or legally
> protected. If you are not the intended recipient or have received this
> message in error, you are not authorized to copy, distribute, or otherwise
> use this message or its attachments. Please notify the sender immediately by
> return e-mail and permanently delete this message and any attachments.
> Verio, Inc. makes no warranty that this email is error or virus free.  Thank
> you.
>
From onemda at gmail.com  Wed Jul 15 07:59:25 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Wed Jul 15 07:59:32 2009
Subject: ndis lor: hal preemption lock
In-Reply-To: <3a142e750907040333o3938c06y6369af6fa6976812@mail.gmail.com>
References: <3a142e750906080809i381c4e6amd93da8a135ab9bd3@mail.gmail.com>
	<4A2D2EB1.3040702@errno.com> <1244477453.7794.2.camel@localhost>
	<3a142e750906081006v6369051dw75c5077e6032101f@mail.gmail.com>
	<1244656248.1701.53.camel@localhost>
	<3a142e750906101108v588e33dfsb0cb81f024c65cfb@mail.gmail.com>
	<1244658479.1701.56.camel@localhost>
	<3a142e750906101805re85136cif71eeeda2c641451@mail.gmail.com>
	<1245323702.1754.0.camel@localhost>
	<3a142e750907040333o3938c06y6369af6fa6976812@mail.gmail.com>
Message-ID: <3a142e750907150027t106edef5m767dd0319f83bd63@mail.gmail.com>

On 7/4/09, Paul B. Mahol <onemda@gmail.com> wrote:
> On 6/18/09, Coleman Kane <cokane@freebsd.org> wrote:
>> I've committed this one as r194432.
>
> Ah, that one introduced regression.
> Switching ndisX up before creating vap will cause panic.
> Here is fix:
>
> --- /sys/dev/if_ndis/if_ndis.c  2009-06-28 09:15:54.000000000 +0000
> +++ if_ndis.c   2009-07-04 10:23:41.000000000 +0000
> @@ -2292,6 +2292,8 @@
>         ifp = sc->ifp;
>         ic = ifp->if_l2com;
>         vap = TAILQ_FIRST(&ic->ic_vaps);
> +       if (vap == NULL)
> +               return;
>
>         if (!NDIS_INITIALIZED(sc)) {
>                 DPRINTF(("%s: NDIS not initialized\n", __func__));

Bump!

Please commit.

-- 
Paul
From delphij at delphij.net  Wed Jul 15 08:07:29 2009
From: delphij at delphij.net (Xin LI)
Date: Wed Jul 15 08:07:36 2009
Subject: [LOR] carp vs bridge
In-Reply-To: <4ad871310907131747g6798c0b9j96a8ce5540f42289@mail.gmail.com>
References: <4A5BD40E.9080108@delphij.net>
	<4ad871310907131747g6798c0b9j96a8ce5540f42289@mail.gmail.com>
Message-ID: <4A5D8DF0.4010708@delphij.net>

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

Here is a brute-force workaround for the issue, basically this would
convert the hard deadlock into another problem (no multicast/broadcast
being done on bridge, if CARP is enabled).  It's good enough for my
usage but is of course far from ideal.

As I am not sure how much I could step further on a real fix due to
$REALJOB, I'd like to share some further analysis for the problem.
Basically, it was caused by CARP's use of locking and bridge's locking,
the former would acquire CARP interface's mutex, while holding the
mutex, it tries to indirectly call ether_output which, in turn, calls
bridge_output if the CARP enabled interface is also part of a bridge.
Since the bridge_output wants to acquire lock for the bridge's member
interface, which is potentially parent for CARP interface, the order
constraint is violated and thus a deadlock could happen.

I think there is no obvious clean solution to break the dependency
without weakening the realtimeness of sending the required multicast at
this point.  Will think again about it when I got some spare time.

Cheers,
- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iEYEARECAAYFAkpdjfAACgkQi+vbBBjt66BxsACgggT8vhXo62V7Sh+2uAA0re2c
dmEAnix+ax16obT2+neW7Iw0/P12cBVp
=IM/r
-----END PGP SIGNATURE-----
-------------- next part --------------
Index: if_ethersubr.c
===================================================================
--- if_ethersubr.c	(revision 195705)
+++ if_ethersubr.c	(working copy)
@@ -394,8 +394,18 @@
 	* Bridges require special output handling.
 	*/
 	if (ifp->if_bridge) {
+#if defined(INET) || defined(INET6)
+#ifdef DEV_CARP
+		if ((m->m_flags & ~(M_MCAST | M_BCAST)) == m->m_flags) {
+#endif
+#endif
 		BRIDGE_OUTPUT(ifp, m, error);
 		return (error);
+#if defined(INET) || defined(INET6)
+#ifdef DEV_CARP
+		}
+#endif
+#endif
 	}
 
 #if defined(INET) || defined(INET6)
From phoemix at harmless.hu  Wed Jul 15 16:29:58 2009
From: phoemix at harmless.hu (Gergely CZUCZY)
Date: Wed Jul 15 16:30:08 2009
Subject: IPsec tunnel help
Message-ID: <20090715181703.00006c68@unknown>

Hello,

I'd like to ask for a bit of a help.

I'd like to set up an IPSec VPN between two hosts, and I'm facing an
issue I can't solve myself.

The setup is the following:
It's a site-to-host VPN, from A to B.
At A side there's the fbsd gateway, it's a 7.2 box, everything is built
into the kernel, and ipsec-tools is up and running. I've got a /24
range here.

Site B is a Zywall 2 Plus device.

A: pub: 217.150.138.138, local: 192.168.0.0/24
B: pub: 217.150.130.163, local box: 192.168.1.64/32
C: 192.168.0.248

Phase 1 and 2 are completed. I'm trying to ping a box from the B site
behind the fbsd box, let's call it C. The icmp-echo-request reaches C,
reply is generated. The icmp-echo-reply appears on the local interface
of the fbsd box, but at that point it's lost I can't find a trace of
it. It's not on the gif0 IF and neither there are any outgoing ESP
packets on the public interface.

Configs:
--- rc.conf --
# IPSec VPN
ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"
ipsec_program="/usr/local/sbin/setkey"
racoon_enable="YES"
racoon_flags="-d -l /var/log/racoon.log"

--- rc.conf ---
(i've put up the gif0 by hand)

gif0:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet 217.150.138.138 --> 217.150.130.163
        inet 192.168.0.0 --> 192.168.1.64 netmask 0xffffffff
(I've also tried with 192.168.0.251->192.168.1.64/32, no luck, same
results)

--- ipsec.conf ---
spdflush;
spdadd 192.168.1.64/32 192.168.0.0/24 any -P in ipsec
  esp/tunnel/217.150.130.163-217.150.138.138/unique;
spdadd 192.168.0.0/24 192.168.1.64/32 any -P in ipsec
  esp/tunnel/217.150.138.138-217.150.130.163/unique;
--- ipsec.conf ---

--- racoon.conf ---
log debug;

path pre_shared_key "/usr/local/etc/ipsec.keys";
path pidfile        "/var/run/racoon.pid";

listen {
       isakmp   217.150.138.138;
       adminsock        "/var/db/racoon/racoon.sock";
}

remote 217.150.130.163 {
       exchange_mode main;

       my_identifier    address 217.150.138.138;
       peers_identifier address 217.150.130.163;
       verify_identifier        on;

#       lifetime                time    40000 sec;

       proposal_check   claim;

       proposal
       {
        encryption_algorithm    3des;
        hash_algorithm          sha1;
        authentication_method   pre_shared_key;
        dh_group                2;
        lifetime time           40000 seconds;
       }
}

sainfo address 192.168.1.64/32 any address 192.168.0.0/24 any {
       lifetime time          40000 seconds;
       encryption_algorithm   3des;
       authentication_algorithm hmac_sha1;
       compression_algorithm    deflate;
}

sainfo address 192.168.0.0/24 any address 192.168.1.64/32 any {
       lifetime time          40000 seconds;
       encryption_algorithm   3des;
       authentication_algorithm hmac_sha1;
       compression_algorithm    deflate;
}
--- racoon.conf ---

I've got the tunnel up:
# racoonctl show-sa isakmp
Destination            Cookies                           Created
217.150.130.163.500    60566fd9f22997f0:368679084fb0bf3e 2009-07-15
17:47:00
# racoonctl show-sa esp
217.150.138.138 217.150.130.163
...
217.150.130.163 217.150.138.138
...
(if i should show anything out of it tell me)

I'm pinging the C box, on the local if i see the traffic:
IP 192.168.1.64 > 192.168.0.248: ICMP echo request, id 1547, seq 3777,
length 64 IP 192.168.0.248 > 192.168.1.64: ICMP echo reply, id 1547,
seq 3777, length 64


on the gif0 i only see:
IP 192.168.1.64 > 192.168.0.248: ICMP echo request, id 1547, seq 3802,
length 64


and on the public IF i see the following traffic:
IP 217.150.130.163 > 217.150.138.138: ESP(spi=0x022aff56,seq=0x627),
length 116


No ESP packets from the fbsd box to the zyxel (A->B). Practically
traffic comes in, reaches the box on the local net, but any traffic
going outside is being lost somewhere.

In the pf.conf I allow the traffic to go through:
--- pf.conf snippet ---
pass in quick on $if_inetfw proto udp from any to ($if_inetfw:0) port
  500 keep state
pass in quick on $if_inetfw proto {esp,ah,ipencap} from any to
  ($if_inetfw:0) keep state
pass out quick on $if_inetfw proto {esp,ah,ipencap} from any to any
  keep state
--- pf.conf snippet ---

So the question is, what is wrong, why do I don't have any traffic
going to the B host out of the fbsd box? And how can this be fixed?

Thanks in advance

-- 
Sincerely,
Gergely CZUCZY

+36-30-9702963
From sol4nki at gmail.com  Thu Jul 16 01:21:59 2009
From: sol4nki at gmail.com (Jigar SOLANKI)
Date: Thu Jul 16 01:22:05 2009
Subject: IPsec tunnel help
In-Reply-To: <20090715181703.00006c68@unknown>
References: <20090715181703.00006c68@unknown>
Message-ID: <52bc9f190907151757w313175acxa40d4eae656a8345@mail.gmail.com>

Hi,

I think that you can't see any outgoing traffic because there is no spd rule
that matches any outgoing traffic ( from site A, ie you freebsd box) : this
just comes from your second spd rule where "in" should be "out" :

Try to replace the second rule:

spdadd 192.168.0.0/24 192.168.1.64/32 any -P in ipsec
 esp/tunnel/217.150.138.138-217.150.130.163/unique;


By :


spdadd 192.168.0.0/24 192.168.1.64/32 any -P out ipsec
 esp/tunnel/217.150.138.138-217.150.130.163/unique;


Hope this helps. :-)

Regards,

--
SOLANKI Jigar
---
From gergely.czuczy at harmless.hu  Thu Jul 16 06:14:58 2009
From: gergely.czuczy at harmless.hu (Gergely CZUCZY)
Date: Thu Jul 16 06:15:10 2009
Subject: IPsec tunnel help
In-Reply-To: <52bc9f190907151757w313175acxa40d4eae656a8345@mail.gmail.com>
References: <20090715181703.00006c68@unknown>
	<52bc9f190907151757w313175acxa40d4eae656a8345@mail.gmail.com>
Message-ID: <20090716081452.0000693d@unknown>

Thanks, this solved the problem. I think i was too tired and was
producing layer8 issues :)

Another question, what does the AES mean for racoon, is it AES256 or
AES128? I've seen both at some ipsec devices, and I haven't seen the
cipher size specified here.

On Thu, 16 Jul 2009 02:57:43 +0200
Jigar SOLANKI <sol4nki@gmail.com> wrote:

> Hi,
> 
> I think that you can't see any outgoing traffic because there is no
> spd rule that matches any outgoing traffic ( from site A, ie you
> freebsd box) : this just comes from your second spd rule where "in"
> should be "out" :
> 
> Try to replace the second rule:
> 
> spdadd 192.168.0.0/24 192.168.1.64/32 any -P in ipsec
>  esp/tunnel/217.150.138.138-217.150.130.163/unique;
> 
> 
> By :
> 
> 
> spdadd 192.168.0.0/24 192.168.1.64/32 any -P out ipsec
>  esp/tunnel/217.150.138.138-217.150.130.163/unique;
> 
> 
> Hope this helps. :-)
> 
> Regards,
> 
> --
> SOLANKI Jigar
> ---
> 


-- 
Sincerely,
Gergely CZUCZY
Harmless Digital Bt

+36-30-9702963
From phoemix at harmless.hu  Thu Jul 16 12:32:51 2009
From: phoemix at harmless.hu (Gergely CZUCZY)
Date: Thu Jul 16 12:32:59 2009
Subject: FreeBSD 7.2 racoon and NAT-T
Message-ID: <20090716143248.0000184e@unknown>

Hello,

I'd like to ask for the state of that NAT-T support in 7.2. I've seen a
note in ipsec-tools's OPTIONS for a required kernel patch for 6.x in
order to have NAT-T working. Is this also required for 7.2?
If a kernel patch is needed, is a recent patch available for 7.2?
Does racoon needs to be patched with anything not in the port?

Thanks in advance

-- 
Sincerely,
Gergely CZUCZY

+36-30-9702963
From vanhu at FreeBSD.org  Thu Jul 16 12:38:38 2009
From: vanhu at FreeBSD.org (VANHULLEBUS Yvan)
Date: Thu Jul 16 12:38:45 2009
Subject: FreeBSD 7.2 racoon and NAT-T
In-Reply-To: <20090716143248.0000184e@unknown>
References: <20090716143248.0000184e@unknown>
Message-ID: <20090716123836.GA85624@zeninc.net>

On Thu, Jul 16, 2009 at 02:32:48PM +0200, Gergely CZUCZY wrote:
> Hello,

Hi.


> I'd like to ask for the state of that NAT-T support in 7.2. I've seen a
> note in ipsec-tools's OPTIONS for a required kernel patch for 6.x in
> order to have NAT-T working. Is this also required for 7.2?
> If a kernel patch is needed, is a recent patch available for 7.2?
> Does racoon needs to be patched with anything not in the port?

http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
and ipsec-tools 0.7.x will work together (NOT tried with very recent
versions of stable/7, please report any problem).


A new FreeBSD patch will be needed to be able to run with upcoming
0.8.x (and with recent HEAD snapshots), and will be put in the same
location.


Yvan.
From phoemix at harmless.hu  Thu Jul 16 12:58:02 2009
From: phoemix at harmless.hu (Gergely CZUCZY)
Date: Thu Jul 16 12:59:07 2009
Subject: FreeBSD 7.2 racoon and NAT-T
In-Reply-To: <20090716123836.GA85624@zeninc.net>
References: <20090716143248.0000184e@unknown>
	<20090716123836.GA85624@zeninc.net>
Message-ID: <20090716145759.000074c9@unknown>

On Thu, 16 Jul 2009 14:38:36 +0200
VANHULLEBUS Yvan <vanhu@FreeBSD.org> wrote:

> On Thu, Jul 16, 2009 at 02:32:48PM +0200, Gergely CZUCZY wrote:
> > Hello,
> 
> Hi.
> 
> 
> > I'd like to ask for the state of that NAT-T support in 7.2. I've
> > seen a note in ipsec-tools's OPTIONS for a required kernel patch
> > for 6.x in order to have NAT-T working. Is this also required for
> > 7.2? If a kernel patch is needed, is a recent patch available for
> > 7.2? Does racoon needs to be patched with anything not in the port?
> 
> http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
> and ipsec-tools 0.7.x will work together (NOT tried with very recent
> versions of stable/7, please report any problem).
> 
> 
> A new FreeBSD patch will be needed to be able to run with upcoming
> 0.8.x (and with recent HEAD snapshots), and will be put in the same
> location.

Thank you very much.

Would it be possible that this could be integrated?
Might be with racoon, that would also be very nice. So far this is the
only thing I've found in FreeBSD that needs a feature in the base
install needs a 3rdparty utility in order to work at all.

Would be very nice to have everything in base available to have IPSec
working all around.

> 
> 
> Yvan.



-- 
Sincerely,
Gergely CZUCZY
Harmless Digital Bt

+36-30-9702963
From vanhu at FreeBSD.org  Thu Jul 16 13:21:19 2009
From: vanhu at FreeBSD.org (VANHULLEBUS Yvan)
Date: Thu Jul 16 13:21:26 2009
Subject: FreeBSD 7.2 racoon and NAT-T
In-Reply-To: <20090716145759.000074c9@unknown>
References: <20090716143248.0000184e@unknown>
	<20090716123836.GA85624@zeninc.net>
	<20090716145759.000074c9@unknown>
Message-ID: <20090716132117.GA98916@zeninc.net>

On Thu, Jul 16, 2009 at 02:57:59PM +0200, Gergely CZUCZY wrote:
[...]
> Thank you very much.
> 
> Would it be possible that this could be integrated?
> Might be with racoon, that would also be very nice. So far this is the
> only thing I've found in FreeBSD that needs a feature in the base
> install needs a 3rdparty utility in order to work at all.
> 
> Would be very nice to have everything in base available to have IPSec
> working all around.

kernel part of NAT-T stuff has been commited for upcoming FreeBSD 8.0,
and userland part needed to run with this kernel code has been
commited in ipsec-tools's HEAD, so will be in 0.8.0 (no, sync between
versions numbers 8.0 and 0.8 is really just a chance :-).

Backport to FreeBSD 7.x has not been planned for now for various
reasons.


Yvan.
From julian at elischer.org  Thu Jul 16 16:34:53 2009
From: julian at elischer.org (Julian Elischer)
Date: Thu Jul 16 16:35:04 2009
Subject: FreeBSD 7.2 racoon and NAT-T
In-Reply-To: <20090716145759.000074c9@unknown>
References: <20090716143248.0000184e@unknown>	<20090716123836.GA85624@zeninc.net>
	<20090716145759.000074c9@unknown>
Message-ID: <4A5F56AC.1000603@elischer.org>

Gergely CZUCZY wrote:
> On Thu, 16 Jul 2009 14:38:36 +0200
> VANHULLEBUS Yvan <vanhu@FreeBSD.org> wrote:
> 
>> On Thu, Jul 16, 2009 at 02:32:48PM +0200, Gergely CZUCZY wrote:
>>> Hello,
>> Hi.
>>
>>
>>> I'd like to ask for the state of that NAT-T support in 7.2. I've
>>> seen a note in ipsec-tools's OPTIONS for a required kernel patch
>>> for 6.x in order to have NAT-T working. Is this also required for
>>> 7.2? If a kernel patch is needed, is a recent patch available for
>>> 7.2? Does racoon needs to be patched with anything not in the port?
>> http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
>> and ipsec-tools 0.7.x will work together (NOT tried with very recent
>> versions of stable/7, please report any problem).
>>
>>
>> A new FreeBSD patch will be needed to be able to run with upcoming
>> 0.8.x (and with recent HEAD snapshots), and will be put in the same
>> location.
> 

????  Does that mean that I was dreaming and the NAT-T stuff wasn't 
committed?  I was certain I had seen it being committted to current?


> Thank you very much.
> 
> Would it be possible that this could be integrated?
> Might be with racoon, that would also be very nice. So far this is the
> only thing I've found in FreeBSD that needs a feature in the base
> install needs a 3rdparty utility in order to work at all.
> 
> Would be very nice to have everything in base available to have IPSec
> working all around.
> 
>>
>> Yvan.
> 
> 
> 

From Brian.Jacobs at lodgenet.com  Thu Jul 16 16:37:01 2009
From: Brian.Jacobs at lodgenet.com (Jacobs, Brian)
Date: Thu Jul 16 16:37:07 2009
Subject: GRE tunnel limitations
Message-ID: <126E45722B459248997856ECB72DEB7701285DC0@host.lodgenet.com>

Does anyone have some realistic data on the number of GRE/ipip tunnels
FreeBSD 7.x can reasonably terminate?  Assume no IPsec, just standard
encapsulation.  I have an ad-hoc need to terminate about 1,4000 static
GRE tunnels (as Cisco 7206's are backordered until September).  J

 

Thanks in advance!

 

/bmj

From julian at elischer.org  Thu Jul 16 16:45:29 2009
From: julian at elischer.org (Julian Elischer)
Date: Thu Jul 16 16:45:35 2009
Subject: GRE tunnel limitations
In-Reply-To: <126E45722B459248997856ECB72DEB7701285DC0@host.lodgenet.com>
References: <126E45722B459248997856ECB72DEB7701285DC0@host.lodgenet.com>
Message-ID: <4A5F5927.3080904@elischer.org>

Jacobs, Brian wrote:
> Does anyone have some realistic data on the number of GRE/ipip tunnels
> FreeBSD 7.x can reasonably terminate?  Assume no IPsec, just standard
> encapsulation.  I have an ad-hoc need to terminate about 1,4000 static
> GRE tunnels (as Cisco 7206's are backordered until September).  J
> 
>  
> 
> Thanks in advance!
> 
>  
> 
> /bmj
> 
> _______________________________________________
> 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"



The limitation would be that there is an interface for reach one and 
the interface 'interface' uses a linked list.  it might work but there 
would probably be scaling issues.

I've often thought that what we need is a way to do "bulk encapsulatin 
interfaces" where there is not an "interface" assigned to each 
destination. (at least not one that shows up in 'ifconfig').

How will you want to decide which gre interface to use for a given 
packet? is it just a standard routing decision based on the remote 
address?



From Brian.Jacobs at lodgenet.com  Thu Jul 16 16:50:03 2009
From: Brian.Jacobs at lodgenet.com (Jacobs, Brian)
Date: Thu Jul 16 16:50:10 2009
Subject: GRE tunnel limitations
In-Reply-To: <4A5F5927.3080904@elischer.org>
References: <126E45722B459248997856ECB72DEB7701285DC0@host.lodgenet.com>
	<4A5F5927.3080904@elischer.org>
Message-ID: <126E45722B459248997856ECB72DEB7701285DC2@host.lodgenet.com>

IP unnumbered between the two boxen.  I've built some scripts to
automatically generate config files, and then other scripts to
automagically create the GRE interfaces and inject appropriate routes.

GRE numbers are assigned sequentially based on config file lines (and
are of no consequence):

gre45: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu
1476
 tunnel inet 10.3.100.39 --> 207.230.84.130
 inet 10.3.100.39 --> 10.11.146.129 netmask 0xffffffff 
gre46: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu
1476
 tunnel inet 10.3.100.39 --> 12.35.57.131
 inet 10.3.100.39 --> 10.10.201.1 netmask 0xffffffff

10.3.100.39 is the primary Ethernet interface address of the local box
(terminator).  10.10.201.1 is the inside Ethernet of the remote box.

Routing statement for 10.0.0.0/8 live on the remote box, and individual
routes live on the concentrator:

root@yttrium /root# netstat -nr | grep 10.10.201
10.10.201.0/26     10.10.201.1        UGS         0     2042  gre46
10.10.201.1        10.3.100.39        UH          1    49263  gre46

/bmj


-----Original Message-----
From: Julian Elischer [mailto:julian@elischer.org] 
Sent: Thursday, July 16, 2009 12:45 PM
To: Jacobs, Brian
Cc: freebsd-net@freebsd.org
Subject: Re: GRE tunnel limitations

Jacobs, Brian wrote:
> Does anyone have some realistic data on the number of GRE/ipip tunnels
> FreeBSD 7.x can reasonably terminate?  Assume no IPsec, just standard
> encapsulation.  I have an ad-hoc need to terminate about 1,4000 static
> GRE tunnels (as Cisco 7206's are backordered until September).  J
> 
>  
> 
> Thanks in advance!
> 
>  
> 
> /bmj
> 
> _______________________________________________
> 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"



The limitation would be that there is an interface for reach one and 
the interface 'interface' uses a linked list.  it might work but there 
would probably be scaling issues.

I've often thought that what we need is a way to do "bulk encapsulatin 
interfaces" where there is not an "interface" assigned to each 
destination. (at least not one that shows up in 'ifconfig').

How will you want to decide which gre interface to use for a given 
packet? is it just a standard routing decision based on the remote 
address?



From linimon at FreeBSD.org  Fri Jul 17 04:09:35 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Fri Jul 17 04:09:47 2009
Subject: kern/136836: [ath] atheros card stops functioning after about
	12 hours uptime
Message-ID: <200907170409.n6H49YLg084325@freefall.freebsd.org>

Old Synopsis: atheros card stops functioning after about 12 hours uptime
New Synopsis: [ath] atheros card stops functioning after about 12 hours uptime

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jul 17 04:09:22 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136836
From linimon at FreeBSD.org  Fri Jul 17 04:15:52 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Fri Jul 17 04:15:59 2009
Subject: kern/136803: [sctp] [panic] Kernel panic and hanging on using
	SCTP
Message-ID: <200907170415.n6H4Fp9R092614@freefall.freebsd.org>

Old Synopsis: Kernel panic and hanging on using SCTP
New Synopsis: [sctp] [panic] Kernel panic and hanging on using SCTP

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jul 17 04:15:38 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136803
From fox at verio.net  Fri Jul 17 06:22:23 2009
From: fox at verio.net (David DeSimone)
Date: Fri Jul 17 06:22:29 2009
Subject: question regarding IPSEC Setup
In-Reply-To: <3228ef7c0907142001y650892b3w696576647086ba38@mail.gmail.com>
References: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
	<20090714134131.GA23925@traktor.dnepro.net>
	<3228ef7c0907140918i5d90dc44q995a4210f2767f9a@mail.gmail.com>
	<20090715001514.GU6896@verio.net>
	<3228ef7c0907141843s30df148eu2c6c64acd7748029@mail.gmail.com>
	<20090715021251.GV6896@verio.net>
	<3228ef7c0907142001y650892b3w696576647086ba38@mail.gmail.com>
Message-ID: <20090717062218.GL6896@verio.net>

rascal <rascal1981@gmail.com> wrote:
>
> If I could ask one more favor; what does your cisco config look like
> that would match one of these?  I have got mine configed based on
> someone else's tunnel specs and while I am sure they are comparable I
> wanted to make sure I wasn't missing anything.

Here's an example config that I sanitized from one of our Cisco routers;
I think it should work, but it's only an example.  At some point you
have to adapt these configs to your own situation.  :)

    crypto isakmp policy 1
     encr aes 
     authentication pre-share
     group 2  

    crypto isakmp key SecretKey!! address 11.22.33.44

    crypto ipsec transform-set AES-SHA1 esp-aes esp-sha-hmac

    crypto map IPSEC local-address GigabitEthernet0/1

    crypto map IPSEC 1 ipsec-isakmp 
     set peer 11.22.33.44
     set transform-set AES-SHA1
     match address remote-site

    interface GigabitEthernet0/1
     ip address 55.66.77.88 255.255.255.224
     crypto map IPSEC

    ip access-list extended remote-site
     permit ip 10.20.50.60 0.0.0.255 10.10.30.40 0.0.0.255
     permit ip 10.20.50.60 0.0.0.255 10.10.30.50 0.0.0.255
     permit ip 10.20.50.70 0.0.0.255 10.10.30.40 0.0.0.255
     permit ip 10.20.50.70 0.0.0.255 10.10.30.50 0.0.0.255

-- 
David DeSimone == Network Admin == fox@verio.net
  "I don't like spinach, and I'm glad I don't, because if I
   liked it I'd eat it, and I just hate it." -- Clarence Darrow


This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free.  Thank you.
From vanhu at FreeBSD.org  Fri Jul 17 07:21:27 2009
From: vanhu at FreeBSD.org (VANHULLEBUS Yvan)
Date: Fri Jul 17 07:22:54 2009
Subject: FreeBSD 7.2 racoon and NAT-T
In-Reply-To: <4A5F56AC.1000603@elischer.org>
References: <20090716143248.0000184e@unknown>
	<20090716123836.GA85624@zeninc.net>
	<20090716145759.000074c9@unknown> <4A5F56AC.1000603@elischer.org>
Message-ID: <20090717072124.GA4883@zeninc.net>

On Thu, Jul 16, 2009 at 09:34:52AM -0700, Julian Elischer wrote:
> Gergely CZUCZY wrote:
[...]
> >>>I'd like to ask for the state of that NAT-T support in 7.2. I've
> >>>seen a note in ipsec-tools's OPTIONS for a required kernel patch
> >>>for 6.x in order to have NAT-T working. Is this also required for
> >>>7.2? If a kernel patch is needed, is a recent patch available for
> >>>7.2? Does racoon needs to be patched with anything not in the port?
> >>http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
> >>and ipsec-tools 0.7.x will work together (NOT tried with very recent
> >>versions of stable/7, please report any problem).
> >>
> >>
> >>A new FreeBSD patch will be needed to be able to run with upcoming
> >>0.8.x (and with recent HEAD snapshots), and will be put in the same
> >>location.
> 
> ????  Does that mean that I was dreaming and the NAT-T stuff wasn't 
> committed?  I was certain I had seen it being committted to current?

I was talking about FreeBSD 7.2 here.


Yvan.
From artis.caune at gmail.com  Fri Jul 17 08:15:30 2009
From: artis.caune at gmail.com (Artis Caune)
Date: Fri Jul 17 08:15:37 2009
Subject: kern/136618: [pf][stf] panic on cloning interface without unit 
	number, e.g. `stf'
In-Reply-To: <200907101030.n6AAU3Ar050676@freefall.freebsd.org>
References: <200907101030.n6AAU3Ar050676@freefall.freebsd.org>
Message-ID: <9e20d71e0907170115w3bb17f75tf31d6362a1311fd3@mail.gmail.com>

2009/7/10 Eygene Ryabinkin <rea-fbsd@codelabs.ru>

>  No problems.  Care to test both patches?  If yes, please, report back
>  any findings of any type.
>


Hi, patch works good on amd64, 8.0-BETA2, r195712


root@FreeBSD ~# ifconfig carp0 name carp
ifconfig: ioctl (set name): File exists





-- 
Artis Caune

   Everything should be made as simple as possible, but not simpler.
From artis.caune at gmail.com  Fri Jul 17 08:20:05 2009
From: artis.caune at gmail.com (Artis Caune)
Date: Fri Jul 17 08:20:13 2009
Subject: kern/136618: [pf][stf] panic on cloning interface without unit 
	number, e.g. `stf'
Message-ID: <200907170820.n6H8K5Z9024579@freefall.freebsd.org>

The following reply was made to PR kern/136618; it has been noted by GNATS.

From: Artis Caune <artis.caune@gmail.com>
To: Eygene Ryabinkin <rea-fbsd@codelabs.ru>
Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org
Subject: Re: kern/136618: [pf][stf] panic on cloning interface without unit 
	number, e.g. `stf'
Date: Fri, 17 Jul 2009 11:15:27 +0300

 --0016369205b11155ce046ee26452
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 7bit
 
 2009/7/10 Eygene Ryabinkin <rea-fbsd@codelabs.ru>
 
 >  No problems.  Care to test both patches?  If yes, please, report back
 >  any findings of any type.
 >
 
 
 Hi, patch works good on amd64, 8.0-BETA2, r195712
 
 
 root@FreeBSD ~# ifconfig carp0 name carp
 ifconfig: ioctl (set name): File exists
 
 
 
 
 
 -- 
 Artis Caune
 
    Everything should be made as simple as possible, but not simpler.
 
 --0016369205b11155ce046ee26452
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 <div class=3D"gmail_quote">2009/7/10 Eygene Ryabinkin <span dir=3D"ltr">&lt=
 ;<a href=3D"mailto:rea-fbsd@codelabs.ru">rea-fbsd@codelabs.ru</a>&gt;</span=
 ><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(=
 204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 <div class=3D"im">=C2=A0No problems. =C2=A0Care to test both patches? =C2=
 =A0If yes, please, report back<br>
 =C2=A0any findings of any type.<br></div></blockquote></div><br><br>Hi, pat=
 ch works good on amd64, 8.0-BETA2, r195712<br><br><br>root@FreeBSD ~# ifcon=
 fig carp0 name carp<br>ifconfig: ioctl (set name): File exists<br><br><br><=
 br>
 <br clear=3D"all"><br>-- <br>Artis Caune<br><br> =C2=A0 =C2=A0Everything sh=
 ould be made as simple as possible, but not simpler.<br>
 
 --0016369205b11155ce046ee26452--
From morganw at chemikals.org  Fri Jul 17 18:00:08 2009
From: morganw at chemikals.org (Wes Morgan)
Date: Fri Jul 17 18:00:20 2009
Subject: kern/136836: atheros card stops functioning after about 12 hours
 uptime  
Message-ID: <200907171800.n6HI08HP057638@freefall.freebsd.org>

The following reply was made to PR kern/136836; it has been noted by GNATS.

From: Wes Morgan <morganw@chemikals.org>
To: FreeBSD-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/136836: atheros card stops functioning after about 12 hours
 uptime  
Date: Fri, 17 Jul 2009 12:55:05 -0500 (CDT)

 These messages show up in syslog indicating that the card has stopped 
 working:
 
 
 Jul 17 06:35:57 catalyst wpa_supplicant[491]: CTRL-EVENT-EAP-STARTED EAP authentication started
 Jul 17 06:35:57 catalyst wpa_supplicant[491]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
 Jul 17 06:35:57 catalyst wpa_supplicant[491]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
 Jul 17 06:35:58 catalyst wpa_supplicant[491]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
 Jul 17 06:35:58 catalyst wpa_supplicant[491]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
 Jul 17 06:35:59 catalyst wpa_supplicant[491]: WPA: Failed to set PTK to the driver.
 Jul 17 06:35:59 catalyst wpa_supplicant[491]: WPA: Key negotiation completed with 00:40:10:10:00:03 [PTK=CCMP GTK=CCMP]
 Jul 17 06:37:16 catalyst kernel: nfs server 192.168.0.1:/usr/home/media: not responding
 Jul 17 06:39:44 catalyst wpa_supplicant[491]: CTRL-EVENT-SCAN-RESULTS 
 Jul 17 06:41:14 catalyst wpa_supplicant[491]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
 Jul 17 06:41:14 catalyst kernel: wlan0: link state changed to DOWN
 Jul 17 06:41:15 catalyst kernel: wlan0: link state changed to UP
 
 
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: CTRL-EVENT-EAP-STARTED EAP authentication started
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
 Jul 16 08:00:27 catalyst wpa_supplicant[31662]: WPA: Failed to set PTK to the driver.
 Jul 16 08:00:27 catalyst wpa_supplicant[31662]: WPA: Key negotiation completed with 00:40:10:10:00:03 [PTK=CCMP GTK=CCMP]
 Jul 16 08:01:45 catalyst kernel: nfs server 192.168.0.1:/usr/home/media: not responding
 
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: CTRL-EVENT-EAP-STARTED EAP authentication started
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
 Jul 15 06:25:32 catalyst wpa_supplicant[495]: WPA: Failed to set PTK to the driver.
 Jul 15 06:25:32 catalyst wpa_supplicant[495]: WPA: Key negotiation completed with 00:40:10:10:00:03 [PTK=CCMP GTK=CCMP]
 Jul 15 06:26:50 catalyst kernel: nfs server 192.168.0.1:/usr/home/media: not responding
From morganw at chemikals.org  Fri Jul 17 18:00:10 2009
From: morganw at chemikals.org (Wes Morgan)
Date: Fri Jul 17 18:00:21 2009
Subject: kern/136836: atheros card stops functioning after about 12 hours
 uptime
Message-ID: <200907171800.n6HI0Avw057666@freefall.freebsd.org>

The following reply was made to PR kern/136836; it has been noted by GNATS.

From: Wes Morgan <morganw@chemikals.org>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/136836: atheros card stops functioning after about 12 hours
 uptime
Date: Fri, 17 Jul 2009 12:58:33 -0500 (CDT)

 These messages show up in syslog indicating that the card has stopped working:
 
 Jul 17 06:35:57 catalyst wpa_supplicant[491]: CTRL-EVENT-EAP-STARTED EAP authentication started
 Jul 17 06:35:57 catalyst wpa_supplicant[491]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
 Jul 17 06:35:57 catalyst wpa_supplicant[491]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
 Jul 17 06:35:58 catalyst wpa_supplicant[491]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
 Jul 17 06:35:58 catalyst wpa_supplicant[491]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
 Jul 17 06:35:59 catalyst wpa_supplicant[491]: WPA: Failed to set PTK to the driver.
 Jul 17 06:35:59 catalyst wpa_supplicant[491]: WPA: Key negotiation completed with 00:40:10:10:00:03 [PTK=CCMP GTK=CCMP]
 Jul 17 06:37:16 catalyst kernel: nfs server 192.168.0.1:/usr/home/media: not responding
 Jul 17 06:39:44 catalyst wpa_supplicant[491]: CTRL-EVENT-SCAN-RESULTS 
 Jul 17 06:41:14 catalyst wpa_supplicant[491]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
 Jul 17 06:41:14 catalyst kernel: wlan0: link state changed to DOWN
 Jul 17 06:41:15 catalyst kernel: wlan0: link state changed to UP
 
 
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: CTRL-EVENT-EAP-STARTED EAP authentication started
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
 Jul 16 08:00:26 catalyst wpa_supplicant[31662]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
 Jul 16 08:00:27 catalyst wpa_supplicant[31662]: WPA: Failed to set PTK to the driver.
 Jul 16 08:00:27 catalyst wpa_supplicant[31662]: WPA: Key negotiation completed with 00:40:10:10:00:03 [PTK=CCMP GTK=CCMP]
 Jul 16 08:01:45 catalyst kernel: nfs server 192.168.0.1:/usr/home/media: not responding
 
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: CTRL-EVENT-EAP-STARTED EAP authentication started
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
 Jul 15 06:25:31 catalyst wpa_supplicant[495]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
 Jul 15 06:25:32 catalyst wpa_supplicant[495]: WPA: Failed to set PTK to the driver.
 Jul 15 06:25:32 catalyst wpa_supplicant[495]: WPA: Key negotiation completed with 00:40:10:10:00:03 [PTK=CCMP GTK=CCMP]
 Jul 15 06:26:50 catalyst kernel: nfs server 192.168.0.1:/usr/home/media: not responding
From sam at errno.com  Fri Jul 17 19:17:56 2009
From: sam at errno.com (Sam Leffler)
Date: Fri Jul 17 19:18:02 2009
Subject: kern/136836: atheros card stops functioning after about 12 hours
 uptime
In-Reply-To: <200907171800.n6HI0Avw057666@freefall.freebsd.org>
References: <200907171800.n6HI0Avw057666@freefall.freebsd.org>
Message-ID: <4A60C551.1070208@errno.com>

Wes Morgan wrote:
> The following reply was made to PR kern/136836; it has been noted by GNATS.
> 
> From: Wes Morgan <morganw@chemikals.org>
> To: bug-followup@freebsd.org
> Cc:  
> Subject: Re: kern/136836: atheros card stops functioning after about 12 hours
>  uptime
> Date: Fri, 17 Jul 2009 12:58:33 -0500 (CDT)
> 
>  These messages show up in syslog indicating that the card has stopped working:
>  
>  Jul 17 06:35:57 catalyst wpa_supplicant[491]: CTRL-EVENT-EAP-STARTED EAP authentication started
>  Jul 17 06:35:57 catalyst wpa_supplicant[491]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
>  Jul 17 06:35:57 catalyst wpa_supplicant[491]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
>  Jul 17 06:35:58 catalyst wpa_supplicant[491]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
>  Jul 17 06:35:58 catalyst wpa_supplicant[491]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
>  Jul 17 06:35:59 catalyst wpa_supplicant[491]: WPA: Failed to set PTK to the driver.
>  Jul 17 06:35:59 catalyst wpa_supplicant[491]: WPA: Key negotiation completed with 00:40:10:10:00:03 [PTK=CCMP GTK=CCMP]
>  Jul 17 06:37:16 catalyst kernel: nfs server 192.168.0.1:/usr/home/media: not responding
>  Jul 17 06:39:44 catalyst wpa_supplicant[491]: CTRL-EVENT-SCAN-RESULTS 
>  Jul 17 06:41:14 catalyst wpa_supplicant[491]: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>  Jul 17 06:41:14 catalyst kernel: wlan0: link state changed to DOWN
>  Jul 17 06:41:15 catalyst kernel: wlan0: link state changed to UP
>  
>  
>  Jul 16 08:00:26 catalyst wpa_supplicant[31662]: CTRL-EVENT-EAP-STARTED EAP authentication started
>  Jul 16 08:00:26 catalyst wpa_supplicant[31662]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
>  Jul 16 08:00:26 catalyst wpa_supplicant[31662]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
>  Jul 16 08:00:26 catalyst wpa_supplicant[31662]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
>  Jul 16 08:00:26 catalyst wpa_supplicant[31662]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
>  Jul 16 08:00:27 catalyst wpa_supplicant[31662]: WPA: Failed to set PTK to the driver.
>  Jul 16 08:00:27 catalyst wpa_supplicant[31662]: WPA: Key negotiation completed with 00:40:10:10:00:03 [PTK=CCMP GTK=CCMP]
>  Jul 16 08:01:45 catalyst kernel: nfs server 192.168.0.1:/usr/home/media: not responding
>  
>  Jul 15 06:25:31 catalyst wpa_supplicant[495]: CTRL-EVENT-EAP-STARTED EAP authentication started
>  Jul 15 06:25:31 catalyst wpa_supplicant[495]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
>  Jul 15 06:25:31 catalyst wpa_supplicant[495]: OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
>  Jul 15 06:25:31 catalyst wpa_supplicant[495]: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
>  Jul 15 06:25:31 catalyst wpa_supplicant[495]: WPA: EAPOL-Key Replay Counter did not increase - dropping packet
>  Jul 15 06:25:32 catalyst wpa_supplicant[495]: WPA: Failed to set PTK to the driver.
>  Jul 15 06:25:32 catalyst wpa_supplicant[495]: WPA: Key negotiation completed with 00:40:10:10:00:03 [PTK=CCMP GTK=CCMP]
>  Jul 15 06:26:50 catalyst kernel: nfs server 192.168.0.1:/usr/home/media: not responding

This looks like another problem I'm working on.  If you do

wlandebug +crypto

to get debug msgs you should see a complaint about not being able to 
plumb the PTK and the key index is > 0.

	Sam
From seklecki at noc.cfi.pgh.pa.us  Fri Jul 17 23:01:05 2009
From: seklecki at noc.cfi.pgh.pa.us (Brian A. Seklecki)
Date: Fri Jul 17 23:01:12 2009
Subject: Dropped/Duplicate SYN, Cisco PIX/ASA, and and random ISN w/
 net.inet.ip.random_id=1
Message-ID: <1247870762.10382.14770.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com>

All:

  We recently worked closely with some FreeBSD developers to track down
an illusive bug in the stack.

In a high performance environment, we observed dropped (or extreme
delayed) SYN packets, but were unable to easily reproduce the problem
using test case scenarios.

Our environment: 
 - FreeBSD 7.x Servers
 - FreeBSD 6.x clients
 - PIX/ASA 7.2.x stateful firewalls
 - pf(4) on the server with lots of jails
 - PHP clients and server with SOAP framework, so lots and lots 
   of sockets, often thousands between any given client->server,
   in various TCP states.

Getting to the heart of the matter, see:

  http://fxr.watson.org/fxr/source/netinet/tcp_timewait.c#L385

Here we drop SYN's from [client:source_ephemeral_socket] if:

 1) We already have that exact combination in CLOSE_WAIT
 2) The ISN of the new incoming SYN is lower than that of
    the existing socket in CLOSE_WAIT

Those conditions are _highly_ unlikely, until you start hedging your
bets.  

net.inet.ip.random_id=1 in sysctl.conf(5) is one way to exacerbate the
problem.  So are the magic scrubbing bubbles in pf.conf(5): scrub all
random-id.  Also, the PIX/ASA code randomizes IDs by default as well(*).

net.inet.ip.portrange.randomized is another; since truly randomized
numbers can involved duplicates.

Additionally, the default random port ephemeral source port range is way
too small for these HPC environments, leading to more likely collisions,
so that can be increased:

 net.inet.ip.random_id=0 
 net.inet.ip.portrange.randomized=1
 net.inet.ip.portrange.first=2048

Anyway, this discussion strictly for the benefit of the mailing list
archives, in case, further down the road, someone else finds them self
tcpdump(8)'ing duplicate SYNs and starting at netstat(8) -s output and
beginning to doubt their own existence.

 ~Brian A. Seklecki


(*) To disable port randomization on the Cisco PIX:

tcp-map verify-chksum
 check-retransmission
 checksum-verification
 exceed-mss drop
 syn-data drop
 tcp-options selective-ack allow 
 urgent-flag clear
 no ttl-evasion-protection
!
icmp unreachable rate-limit 1 burst-size 1
timeout xlate 3:00:00
timeout conn 12:00:00 half-closed 0:10:00 udp 0:01:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 
!
policy-map global_policy
 class my_inspection_tcp
  set connection embryonic-conn-max 2048 per-client-max 1024\  
    per-client-embryonic-max 1024 random-sequence-number disable
  set connection timeout embryonic 0:02:00 tcp 1:30:00 dcd 24:00:00 5 
  set connection advanced-options verify-chksum
!
service-policy global_policy interface [WhateverIF]



From linimon at FreeBSD.org  Sat Jul 18 04:26:59 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Jul 18 04:27:06 2009
Subject: kern/136876: [bge] bge will not resume properly after suspend
Message-ID: <200907180426.n6I4QxnY042841@freefall.freebsd.org>

Old Synopsis: bge will not resume properly after suspend
New Synopsis: [bge] bge will not resume properly after suspend

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Jul 18 04:26:34 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136876
From volker at vwsoft.com  Sat Jul 18 19:28:58 2009
From: volker at vwsoft.com (volker@vwsoft.com)
Date: Sat Jul 18 19:29:05 2009
Subject: system panic when i use ath without swap,some advice?
In-Reply-To: <7237120a0907092043ld8a3325mcf1458ef4aab3bf8@mail.gmail.com>
References: <7237120a0907092043ld8a3325mcf1458ef4aab3bf8@mail.gmail.com>
Message-ID: <4A621C86.1060002@vwsoft.com>

On 07/10/09 05:43, ???? wrote:
> Hi all
> 
>     My system is atom n270 1G RAM, freebsd 7.2 release .without swap.
>     When my ath is associated with an AP, and the traffic is high, the
> system will panic and reboot. this happened many times.
>     Can you give me some advice please.
> thanks
> 
> Micheal Kevin

Micheal,

sure, if you can give us the actual panic message, and preferable a
backtrace, I'm pretty sure we can.

If you can easily produce the panic, you can also grab the coredump w/o
swap space, if you have a spare USB thumb drive handy (see savecore).
BTW by instructing the kernel to save it's coredump onto a (dedicated)
USB thumb drive, I'm fetching core dumps from embedded units which is
otherwise impossible. You can than later analyze and debug your kernel
crash on a workstation machine.

HTH

Volker
From fazaeli at sepehrs.com  Sat Jul 18 22:35:04 2009
From: fazaeli at sepehrs.com (H.Fazaeli)
Date: Sat Jul 18 22:35:11 2009
Subject: broadcom 57710 support
Message-ID: <4A5C3EE6.7010704@sepehrs.com>


Is there any near plan to develop drivers for
network cards based on broadcom NetXtereme II 57710
10 GbE controller?

-- 


Best regards.

Hooman Fazaeli <hf@sepehrs.com>
Sepehr S. T. Co. Ltd.

Web: http://www.sepehrs.com
Tel: (9821)88975701-2
Fax: (9821)88983352





From bjsptyltdstore at sify.com  Sun Jul 19 02:39:50 2009
From: bjsptyltdstore at sify.com (Bryan James)
Date: Sun Jul 19 02:40:04 2009
Subject: Order To New Zealand
Message-ID: <200907182120.n6ILKreL023762@n22.sivit.org>

<<< No Message Collected >>>
From linimon at FreeBSD.org  Sun Jul 19 03:50:33 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sun Jul 19 03:50:39 2009
Subject: kern/136893: ppp(8) crashing with port 65535 in "nat port"
Message-ID: <200907190350.n6J3oWqd058402@freefall.freebsd.org>

Synopsis: ppp(8) crashing with port 65535 in "nat port"

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jul 19 03:50:16 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136893
From espartano.mail at gmail.com  Sun Jul 19 05:51:09 2009
From: espartano.mail at gmail.com (Espartano)
Date: Sun Jul 19 05:51:16 2009
Subject: OT: where to buy Atheros mini pci-exress?
Message-ID: <d353bd50907182220q7c674f6am65cf459c15301a7@mail.gmail.com>

Hi folk, someone know where can I buy an Atheros mini pci-express card ?

I want to get one of this card (Atheros mini pci-express card) for my
laptop to use with freebsd of course but I can't to find out where or
in what web page I could buy one.


I will be glad getting any clue.

Thanks in advanced.

-- 
Un saludo y muchisimas gracias.

Atte: Ing. Jorge S?nchez Escobedo.
Sent from Orizaba, Ver, Mexico
From brian at FreeBSD.org  Sun Jul 19 07:16:17 2009
From: brian at FreeBSD.org (brian@FreeBSD.org)
Date: Sun Jul 19 07:16:23 2009
Subject: kern/136893: ppp(8) crashing with port 65535 in "nat port"
Message-ID: <200907190716.n6J7GH4M026981@freefall.freebsd.org>

Synopsis: ppp(8) crashing with port 65535 in "nat port"

Responsible-Changed-From-To: freebsd-net->brian
Responsible-Changed-By: brian
Responsible-Changed-When: Sun Jul 19 07:15:48 UTC 2009
Responsible-Changed-Why: 
I'll take a look at this.

http://www.freebsd.org/cgi/query-pr.cgi?pr=136893
From ebastan10 at yahoo.com  Sun Jul 19 09:34:57 2009
From: ebastan10 at yahoo.com (Hooman Fazaeli)
Date: Sun Jul 19 15:08:55 2009
Subject: broadcom 57710 support
Message-ID: <220163.23742.qm@web33504.mail.mud.yahoo.com>


Any one knows if there is any near plan to develop drivers for

network cards based on broadcom NetXtereme II 57710

10 GbE controller?

-----------------------
best regards
Hooman Fazaeli



      
From barney_cordoba at yahoo.com  Sun Jul 19 16:06:41 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sun Jul 19 16:06:47 2009
Subject: broadcom 57710 support
Message-ID: <50667.57004.qm@web63901.mail.re1.yahoo.com>




--- On Sun, 7/19/09, Hooman Fazaeli <ebastan10@yahoo.com> wrote:

> From: Hooman Fazaeli <ebastan10@yahoo.com>
> Subject: broadcom 57710 support
> To: freebsd-net@freebsd.org
> Date: Sunday, July 19, 2009, 5:08 AM
> 
> Any one knows if there is any near plan to develop drivers
> for
> 
> network cards based on broadcom NetXtereme II 57710
> 
> 10 GbE controller?
> 
> -----------------------
> best regards
> Hooman Fazaeli

Ok, I'll bite. What is so special about this particular part that you 
simply must use it in your 10GbE server?

Barney


      
From onemda at gmail.com  Sun Jul 19 17:28:13 2009
From: onemda at gmail.com (Paul B. Mahol)
Date: Sun Jul 19 17:28:28 2009
Subject: ndis lor: hal preemption lock
In-Reply-To: <3a142e750907150027t106edef5m767dd0319f83bd63@mail.gmail.com>
References: <3a142e750906080809i381c4e6amd93da8a135ab9bd3@mail.gmail.com>
	<1244477453.7794.2.camel@localhost>
	<3a142e750906081006v6369051dw75c5077e6032101f@mail.gmail.com>
	<1244656248.1701.53.camel@localhost>
	<3a142e750906101108v588e33dfsb0cb81f024c65cfb@mail.gmail.com>
	<1244658479.1701.56.camel@localhost>
	<3a142e750906101805re85136cif71eeeda2c641451@mail.gmail.com>
	<1245323702.1754.0.camel@localhost>
	<3a142e750907040333o3938c06y6369af6fa6976812@mail.gmail.com>
	<3a142e750907150027t106edef5m767dd0319f83bd63@mail.gmail.com>
Message-ID: <3a142e750907191028u15dfd769o26270d48d15ae664@mail.gmail.com>

On 7/15/09, Paul B. Mahol <onemda@gmail.com> wrote:
> On 7/4/09, Paul B. Mahol <onemda@gmail.com> wrote:
>> On 6/18/09, Coleman Kane <cokane@freebsd.org> wrote:
>>> I've committed this one as r194432.
>>
>> Ah, that one introduced regression.
>> Switching ndisX up before creating vap will cause panic.
>> Here is fix:
>>
>> --- /sys/dev/if_ndis/if_ndis.c  2009-06-28 09:15:54.000000000 +0000
>> +++ if_ndis.c   2009-07-04 10:23:41.000000000 +0000
>> @@ -2292,6 +2292,8 @@
>>         ifp = sc->ifp;
>>         ic = ifp->if_l2com;
>>         vap = TAILQ_FIRST(&ic->ic_vaps);
>> +       if (vap == NULL)
>> +               return;
>>
>>         if (!NDIS_INITIALIZED(sc)) {
>>                 DPRINTF(("%s: NDIS not initialized\n", __func__));
>
> Bump!
>
> Please commit.

Beep!

kern/136895

-- 
Paul
From rpaulo at gmail.com  Sun Jul 19 17:57:41 2009
From: rpaulo at gmail.com (Rui Paulo)
Date: Sun Jul 19 17:57:48 2009
Subject: OT: where to buy Atheros mini pci-exress?
In-Reply-To: <d353bd50907182220q7c674f6am65cf459c15301a7@mail.gmail.com>
References: <d353bd50907182220q7c674f6am65cf459c15301a7@mail.gmail.com>
Message-ID: <158A6BB0-3670-4D55-8247-5682B73390B3@gmail.com>


On 19 Jul 2009, at 06:20, Espartano wrote:

> Hi folk, someone know where can I buy an Atheros mini pci-express  
> card ?
>
> I want to get one of this card (Atheros mini pci-express card) for my
> laptop to use with freebsd of course but I can't to find out where or
> in what web page I could buy one.

www.netgate.com
www.minipci.biz (great for EU people).

Regards,
--
Rui Paulo

From linimon at FreeBSD.org  Sun Jul 19 20:38:02 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sun Jul 19 20:38:14 2009
Subject: kern/136911: [netgraph] [panic] system panic on kldload
	ng_bpf.ko then options NETGRAPH_BPF is built in
Message-ID: <200907192038.n6JKc18w084902@freefall.freebsd.org>

Old Synopsis: sytem panic on kldload ng_bpf.ko then options NETGRAPH_BPF is built in
New Synopsis: [netgraph] [panic] system panic on kldload ng_bpf.ko then options NETGRAPH_BPF is built in

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jul 19 20:37:08 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136911
From mgrooms at shrew.net  Sun Jul 19 21:45:58 2009
From: mgrooms at shrew.net (Matthew Grooms)
Date: Sun Jul 19 21:46:05 2009
Subject: FreeBSD + carp on VMWare ESX
Message-ID: <4A638E76.2060706@shrew.net>

Hi all,

I was having problems running carp on VMWare ESX 4 and did a little 
investigative work to determine the cause of the problem. There are 
several posts on the VMWare forums of other users having the same 
difficulty, so I know its not just me :)

In any case, for carp to have a chance of working on ESX you have to 
enable promiscuous mode on the vSwitch the port group its associated 
with. But after doing this, carp interfaces immediately go into BACKUP 
state. If the the net.inet.carp.allow is set to 0, then they immediately 
move into a MASTER state. Of course this isn't useful if you actually 
want carp to work. tcpdump output showed multiple copies of the carp 
packets being bounced back to the host that emitted them. This made me 
suspect that the host was seeing its own advertisement, evaluating it as 
being sent by another host and placing its own carp interface into a 
BACKUP state as a result.

To solve this, my first inclination was to add a pf rule to block all 
inbound carp traffic from itself for a given interface. Unfortunately, 
that didn't seem to work for some reason. I ended up writing a small 
kernel patch that basically does the same thing ( IPv4 only ) which does 
work without any problem that I can see. Unfortunately I don't have much 
experience with the FreeBSD kernel so I assume that its not safe to walk 
the interface address list without holding the appropriate lock.

Would someone please have a look at this? I really need this to work in 
a production system. Others would likely be very happy to have this work 
as well, even if they have to apply a patch.

Thanks in advance,

-Matthew
-------------- next part --------------
Index: ip_carp.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_carp.c,v
retrieving revision 1.52.2.3
diff -u -r1.52.2.3 ip_carp.c
--- ip_carp.c	9 May 2009 00:35:38 -0000	1.52.2.3
+++ ip_carp.c	19 Jul 2009 20:12:49 -0000
@@ -533,7 +533,9 @@
 {
 	struct ip *ip = mtod(m, struct ip *);
 	struct carp_header *ch;
-	int iplen, len;
+	struct ifnet *ifp = m->m_pkthdr.rcvif;
+	struct ifaddr *ifa;
+	int len, iplen;
 
 	carpstats.carps_ipackets++;
 
@@ -543,21 +545,39 @@
 	}
 
 	/* check if received on a valid carp interface */
-	if (m->m_pkthdr.rcvif->if_carp == NULL) {
+	if (ifp->if_carp == NULL) {
 		carpstats.carps_badif++;
 		CARP_LOG("carp_input: packet received on non-carp "
 		    "interface: %s\n",
-		    m->m_pkthdr.rcvif->if_xname);
+		    ifp->if_xname);
 		m_freem(m);
 		return;
 	}
 
+	/*
+	 * verify that the source address is not valid
+	 * for the interface it was received on. this
+	 * tends to happen with VMWare ESX vSwitches.
+	 */
+	TAILQ_FOREACH(ifa, &ifp->if_addrlist, ifa_list) {
+		struct in_addr in;
+		in.s_addr = ifatoia(ifa)->ia_addr.sin_addr.s_addr;
+		if (ifa->ifa_addr->sa_family == AF_INET &&
+		    in.s_addr == ip->ip_src.s_addr ) {
+			m_freem(m);
+			return;
+		}
+	}
+
 	/* verify that the IP TTL is 255.  */
 	if (ip->ip_ttl != CARP_DFLTTL) {
 		carpstats.carps_badttl++;
 		CARP_LOG("carp_input: received ttl %d != 255i on %s\n",
 		    ip->ip_ttl,
-		    m->m_pkthdr.rcvif->if_xname);
+		    ifp->if_xname);
 		m_freem(m);
 		return;
 	}
@@ -592,7 +612,7 @@
 		carpstats.carps_badlen++;
 		CARP_LOG("carp_input: packet too short %d on %s\n",
 		    m->m_pkthdr.len,
-		    m->m_pkthdr.rcvif->if_xname);
+		    ifp->if_xname);
 		m_freem(m);
 		return;
 	}
@@ -609,7 +629,7 @@
 	if (carp_cksum(m, len - iplen)) {
 		carpstats.carps_badsum++;
 		CARP_LOG("carp_input: checksum failed on %s\n",
-		    m->m_pkthdr.rcvif->if_xname);
+		    ifp->if_xname);
 		m_freem(m);
 		return;
 	}
From fazaeli at sepehrs.com  Sun Jul 19 22:35:22 2009
From: fazaeli at sepehrs.com (H.Fazaeli)
Date: Sun Jul 19 22:35:33 2009
Subject: broadcom 57710 support
Message-ID: <4A62D7DD.3040701@sepehrs.com>


Is there any near plan to develop drivers for
network cards based on broadcom NetXtereme II 57710
10 GbE controller?

-- 


Best regards.

Hooman Fazaeli <hf@sepehrs.com>
Sepehr S. T. Co. Ltd.

Web: http://www.sepehrs.com
Tel: (9821)88975701-2
Fax: (9821)88983352






From andrew at modulus.org  Sun Jul 19 22:57:09 2009
From: andrew at modulus.org (Andrew Snow)
Date: Sun Jul 19 22:57:17 2009
Subject: FreeBSD + carp on VMWare ESX
In-Reply-To: <4A638E76.2060706@shrew.net>
References: <4A638E76.2060706@shrew.net>
Message-ID: <4A63A4B3.6090500@modulus.org>

Matthew Grooms wrote:
> I was having problems running carp on VMWare ESX 4 and did a little 
> investigative work to determine the cause of the problem. 

If have tested CARP on ESX 3.5u4 successfully with a 32-bit FreeBSD 
guest with e1000 vNICs.

As well as turning on promiscuous mode on the vSwitch, you have to 
enable "MAC Address changes" and "Forged transmits" as CARP requires 
these to work properly.

Unless this is a vSphere-specific problem I must suspect your 
configuration as the problem.  Do you want to post your CARP config?


- Andrew
From mgrooms at shrew.net  Sun Jul 19 23:25:27 2009
From: mgrooms at shrew.net (Matthew Grooms)
Date: Sun Jul 19 23:25:36 2009
Subject: FreeBSD + carp on VMWare ESX
In-Reply-To: <4A63A4B3.6090500@modulus.org>
References: <4A638E76.2060706@shrew.net> <4A63A4B3.6090500@modulus.org>
Message-ID: <3D3254E2-4E45-4C67-84D2-DB05660D768F@shrew.net>

The other options you mention are enabled by default. This problem  
also effects pre vSphere versions but only under certain  
circumstances. Others claim this is only an issue when NIC teaming is  
in use. However, I disabled this feature and still experience the  
problem without the patch applied.

I'll be happy to post the config when I'm back in front of the  
computer. It's not a configuration problem. I'm not new to FreeBSD or  
carp and have quite a bit of time invested trying to get this to work.

Have a look at the vmware forums. A lot of folks have reported the  
problem in great detail and, as far as I can tell, have yet to get  
this working.

-Matthew

On Jul 19, 2009, at 5:56 PM, Andrew Snow <andrew@modulus.org> wrote:

> Matthew Grooms wrote:
>> I was having problems running carp on VMWare ESX 4 and did a little  
>> investigative work to determine the cause of the problem.
>
> If have tested CARP on ESX 3.5u4 successfully with a 32-bit FreeBSD  
> guest with e1000 vNICs.
>
> As well as turning on promiscuous mode on the vSwitch, you have to  
> enable "MAC Address changes" and "Forged transmits" as CARP requires  
> these to work properly.
>
> Unless this is a vSphere-specific problem I must suspect your  
> configuration as the problem.  Do you want to post your CARP config?
>
>
> - Andrew
From Brian.Jacobs at lodgenet.com  Mon Jul 20 09:30:20 2009
From: Brian.Jacobs at lodgenet.com (Jacobs, Brian)
Date: Mon Jul 20 09:30:27 2009
Subject: GRE tunnel limitations
In-Reply-To: <126E45722B459248997856ECB72DEB7701285DC2@host.lodgenet.com>
References: <126E45722B459248997856ECB72DEB7701285DC0@host.lodgenet.com><4A5F5927.3080904@elischer.org>
	<126E45722B459248997856ECB72DEB7701285DC2@host.lodgenet.com>
Message-ID: <126E45722B459248997856ECB72DEB7701285DED@host.lodgenet.com>

For all interested, I've been doing some implementation work over the
weekend.  Tonight I did a cutover of 766 GRE tunnels to a RELENG_7 box:

[root@yttrium /lso/dev/real]# uname -a
FreeBSD yttrium.colo.XXXXXXXXXX.net 7.1-RELEASE FreeBSD 7.1-RELEASE #1:
Mon Apr 13 11:37:56 EDT 2009     bjacobs@yttrium.colo.
XXXXXXXXXX.net:/usr/obj/usr/src/sys/YTTRIUM  i386
[root@yttrium /lso/dev/real]# ifconfig |grep gre |wc -l
     766
[root@yttrium /lso/dev/real]# netstat -nr |wc -l 
    1494
[root@yttrium /lso/dev/real]# uptime
 5:32AM  up 74 days, 11:01, 5 users, load averages: 0.00, 0.26, 0.59

Load average is nothing (hovers between 0 and .20), although there isn't
much traversing the tunnels (yet), nor have we implemented IPsec (yet --
next step, have crypto card if needed).  Another project commencing
shortly will push/pull about 10mb/s aggregate (estimate) across the
collective tunnels.

Please advise if the group (or any individuals) want performance data
from real world usage.

/bmj


-----Original Message-----
From: owner-freebsd-net@freebsd.org
[mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jacobs, Brian
Sent: Thursday, July 16, 2009 12:50 PM
To: Julian Elischer
Cc: freebsd-net@freebsd.org
Subject: RE: GRE tunnel limitations

IP unnumbered between the two boxen.  I've built some scripts to
automatically generate config files, and then other scripts to
automagically create the GRE interfaces and inject appropriate routes.

GRE numbers are assigned sequentially based on config file lines (and
are of no consequence):

gre45: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu
1476
 tunnel inet 10.3.100.39 --> 207.230.84.130
 inet 10.3.100.39 --> 10.11.146.129 netmask 0xffffffff 
gre46: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu
1476
 tunnel inet 10.3.100.39 --> 12.35.57.131
 inet 10.3.100.39 --> 10.10.201.1 netmask 0xffffffff

10.3.100.39 is the primary Ethernet interface address of the local box
(terminator).  10.10.201.1 is the inside Ethernet of the remote box.

Routing statement for 10.0.0.0/8 live on the remote box, and individual
routes live on the concentrator:

root@yttrium /root# netstat -nr | grep 10.10.201
10.10.201.0/26     10.10.201.1        UGS         0     2042  gre46
10.10.201.1        10.3.100.39        UH          1    49263  gre46

/bmj


-----Original Message-----
From: Julian Elischer [mailto:julian@elischer.org] 
Sent: Thursday, July 16, 2009 12:45 PM
To: Jacobs, Brian
Cc: freebsd-net@freebsd.org
Subject: Re: GRE tunnel limitations

Jacobs, Brian wrote:
> Does anyone have some realistic data on the number of GRE/ipip tunnels
> FreeBSD 7.x can reasonably terminate?  Assume no IPsec, just standard
> encapsulation.  I have an ad-hoc need to terminate about 1,4000 static
> GRE tunnels (as Cisco 7206's are backordered until September).  J
> 
>  
> 
> Thanks in advance!
> 
>  
> 
> /bmj
> 
> _______________________________________________
> 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"



The limitation would be that there is an interface for reach one and 
the interface 'interface' uses a linked list.  it might work but there 
would probably be scaling issues.

I've often thought that what we need is a way to do "bulk encapsulatin 
interfaces" where there is not an "interface" assigned to each 
destination. (at least not one that shows up in 'ifconfig').

How will you want to decide which gre interface to use for a given 
packet? is it just a standard routing decision based on the remote 
address?



_______________________________________________
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"
From bugmaster at FreeBSD.org  Mon Jul 20 11:07:01 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jul 20 11:09:07 2009
Subject: Current problem reports assigned to freebsd-net@FreeBSD.org
Message-ID: <200907201107.n6KB70Se002375@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/136911  net        [netgraph] [panic] system panic on kldload ng_bpf.ko t
o kern/136876  net        [bge] bge will not resume properly after suspend
o kern/136836  net        [ath] atheros card stops functioning after about 12 ho
o kern/136803  net        [sctp] [panic] Kernel panic and hanging on using SCTP
o kern/136618  net        [pf][stf] panic on cloning interface without unit numb
o kern/136482  net        [age] Attansic L1 Gigabit Ethernet recieves multicasts
o kern/136168  net        [em] em driver initialization fails on Intel 5000PSL m
o kern/135836  net        [bce] bce BCM5709 Watchdog after warm boot - ok after 
o kern/135502  net        [periodic] Warning message raised by rtfree function i
o kern/135222  net        [igb] low speed routing between two igb interfaces
o kern/135067  net        [patch] [fib] Incorrect KASSERTs in sys/net/route.c
o kern/134931  net        [route] [fib] Route messages sent to all socket listen
o kern/134658  net        [bce] bce driver fails on PowerEdge m610 blade.
o kern/134583  net        [hang] Machine with jail freezes after random amount o
o kern/134531  net        [route] [panic] kernel crash related to routes/zebra
o kern/134401  net        [msk] [panic] Kernel Fatal trap 12: page fault while i
o kern/134369  net        [route] [ip6] IPV6 in Head broken for routing table up
o kern/134168  net        [ral] ral driver problem on RT2525 2.4GHz transceiver 
o kern/134157  net        [dummynet] dummynet loads cpu for 100% and make a syst
o kern/134079  net        [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8
o kern/133969  net        [dummynet] [panic] Fatal trap 12: page fault while in 
o kern/133968  net        [dummynet] [panic] dummynet kernel panic
o kern/133902  net        [tun] Killing tun0 iface ssh tunnel causes Panic Strin
o kern/133736  net        [udp] ip_id not protected ...
o kern/133613  net        [wpi] [panic] kernel panic in wpi(4)
o kern/133595  net        [panic] Kernel Panic at pcpu.h:195
o kern/133572  net        [ppp] [hang] incoming PPTP connection hangs the system
o kern/133490  net        [bpf] [panic] 'kmem_map too small' panic on Dell r900 
o kern/133328  net        [bge] [panic] Kernel panics with Windows7 client
o kern/133235  net        [netinet] [patch] Process SIOCDLIFADDR command incorre
o kern/133218  net        [carp] [hang] use of carp(4) causes system to freeze
o kern/133204  net        [msk] msk driver timeouts
o kern/133060  net        [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs
o kern/132991  net        [bge] if_bge low performance problem
f bin/132911   net        ip6fw(8): argument type of fill_icmptypes is wrong and
o kern/132889  net        [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d
o kern/132885  net        [wlan] 802.1x broken after SVN rev 189592
o conf/132851  net        [fib] [patch] allow to setup fib for service running f
o kern/132832  net        [netinet] [patch] tcp_output() might generate invalid 
o bin/132798   net        [patch] ggatec(8): ggated/ggatec connection slowdown p
o kern/132734  net        [ifmib] [panic] panic in net/if_mib.c
o kern/132722  net        [ath] Wifi ath0 associates fine with AP, but DHCP or I
o kern/132705  net        [libwrap] [patch] libwrap - infinite loop if hosts.all
o kern/132672  net        [ndis] [panic] ndis with rt2860.sys causes kernel pani
o kern/132669  net        [xl] 3c905-TX send DUP! in reply on ping (sometime)
o kern/132625  net        [iwn] iwn drivers don't support setting country
o kern/132554  net        [ipl] There is no ippool start script/ipfilter magic t
o kern/132354  net        [nat] Getting some packages to ipnat(8) causes crash
o kern/132285  net        [carp] alias gives incorrect hash in dmesg
o kern/132277  net        [crypto] [ipsec] poor performance using cryptodevice f
o conf/132179  net        [patch] /etc/network.subr: ipv6 rtsol on incorrect wla
o kern/132107  net        [carp] carp(4) advskew setting ignored when carp IP us
o kern/131781  net        [ndis] ndis keeps dropping the link
o kern/131776  net        [wi] driver fails to init
o kern/131753  net        [altq] [panic] kernel panic in hfsc_dequeue
o bin/131567   net        [socket] [patch] Update for regression/sockets/unix_cm
o kern/131549  net        ifconfig(8) can't clear 'monitor' mode on the wireless
o kern/131536  net        [netinet] [patch] kernel does allow manipulation of su
o bin/131365   net        route(8): route add changes interpretation of network 
o kern/131162  net        [ath] Atheros driver bugginess and kernel crashes
o kern/131153  net        [iwi] iwi doesn't see a wireless network
f kern/131087  net        [ipw] [panic] ipw / iwi - no sent/received packets; iw
f kern/130820  net        [ndis] wpa_supplicant(8) returns 'no space on device'
o kern/130628  net        [nfs] NFS / rpc.lockd deadlock on 7.1-R
o conf/130555  net        [rc.d] [patch] No good way to set ipfilter variables a
o kern/130525  net        [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau
o kern/130311  net        [wlan_xauth] [panic] hostapd restart causing kernel pa
o kern/130109  net        [ipfw] Can not set fib for packets originated from loc
f kern/130059  net        [panic] Leaking 50k mbufs/hour
o kern/129750  net        [ath] Atheros AR5006 exits on "cannot map register spa
f kern/129719  net        [nfs] [panic] Panic during shutdown, tcp_ctloutput: in
o kern/129580  net        [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo
o kern/129517  net        [ipsec] [panic] double fault / stack overflow
o kern/129508  net        [carp] [panic] Kernel panic with EtherIP (may be relat
o kern/129352  net        [xl] [patch] xl0 watchdog timeout
o kern/129219  net        [ppp] Kernel panic when using kernel mode ppp
o kern/129197  net        [panic] 7.0 IP stack related panic
o kern/129135  net        [vge] vge driver on a VIA mini-ITX not working
o bin/128954   net        ifconfig(8) deletes valid routes
o kern/128917  net        [wpi] [panic] if_wpi and wpa+tkip causing kernel panic
o kern/128884  net        [msk] if_msk page fault while in kernel mode
o kern/128840  net        [igb] page fault under load with igb/LRO
o bin/128602   net        [an] wpa_supplicant(8) crashes with an(4)
o kern/128598  net        [bluetooth] WARNING: attempt to net_add_domain(bluetoo
o kern/128448  net        [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res
o conf/128334  net        [request] use wpa_cli in the "WPA DHCP" situation
o bin/128295   net        [patch] ifconfig(8) does not print TOE4 or TOE6 capabi
o bin/128001   net        wpa_supplicant(8), wlan(4), and wi(4) issues
o kern/127928  net        [tcp] [patch] TCP bandwidth gets squeezed every time t
o kern/127834  net        [ixgbe] [patch] wrong error counting
o kern/127826  net        [iwi] iwi0 driver has reduced performance and connecti
o kern/127815  net        [gif] [patch] if_gif does not set vlan attributes from
o kern/127724  net        [rtalloc] rtfree: 0xc5a8f870 has 1 refs
f bin/127719   net        [arp] arp: Segmentation fault (core dumped)
s kern/127587  net        [bge] [request] if_bge(4) doesn't support BCM576X fami
f kern/127528  net        [icmp]: icmp socket receives icmp replies not owned by
o bin/127192   net        routed(8) removes the secondary alias IP of interface 
f kern/127145  net        [wi]: prism (wi) driver crash at bigger traffic
o kern/127102  net        [wpi] Intel 3945ABG low throughput
o kern/127057  net        [udp] Unable to send UDP packet via IPv6 socket to IPv
o kern/127050  net        [carp] ipv6 does not work on carp interfaces [regressi
o kern/126945  net        [carp] CARP interface destruction with ifconfig destro
o kern/126924  net        [an] [patch] printf -> device_printf and simplify prob
o kern/126895  net        [patch] [ral] Add antenna selection (marked as TBD)
o kern/126874  net        [vlan]: Zebra problem if ifconfig vlanX destroy
o bin/126822   net        wpa_supplicant(8): WPA PSK does not work in adhoc mode
o kern/126714  net        [carp] CARP interface renaming makes system no longer 
o kern/126695  net        rtfree messages and network disruption upon use of if_
o kern/126688  net        [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and 
o kern/126475  net        [ath] [panic] ath pcmcia card inevitably panics under 
o kern/126339  net        [ipw] ipw driver drops the connection
o kern/126214  net        [ath] txpower problem with Atheros wifi card
o kern/126075  net        [inet] [patch] internet control accesses beyond end of
o bin/125922   net        [patch] Deadlock in arp(8)
o kern/125920  net        [arp] Kernel Routing Table loses Ethernet Link status 
o kern/125845  net        [netinet] [patch] tcp_lro_rx() should make use of hard
o kern/125816  net        [carp] [if_bridge] carp stuck in init when using bridg
f kern/125502  net        [ral] ifconfig ral0 scan produces no output unless in 
o kern/125258  net        [socket] socket's SO_REUSEADDR option does not work
o kern/125239  net        [gre] kernel crash when using gre
o kern/124767  net        [iwi] Wireless connection using iwi0 driver (Intel 220
o kern/124753  net        [ieee80211] net80211 discards power-save queue packets
o kern/124341  net        [ral] promiscuous mode for wireless device ral0 looses
o kern/124160  net        [libc] connect(2) function loops indefinitely
o kern/124127  net        [msk] watchdog timeout (missed Tx interrupts) -- recov
o kern/124021  net        [ip6] [panic] page fault in nd6_output()
o kern/123968  net        [rum] [panic] rum driver causes kernel panic with WPA.
p kern/123961  net        [vr] [patch] Allow vr interface to handle vlans
o kern/123892  net        [tap] [patch] No buffer space available
o kern/123890  net        [ppp] [panic] crash & reboot on work with PPP low-spee
o kern/123858  net        [stf] [patch] stf not usable behind a NAT
o kern/123796  net        [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not
o bin/123633   net        ifconfig(8) doesn't set inet and ether address in one 
f kern/123617  net        [tcp] breaking connection when client downloading file
o kern/123603  net        [tcp] tcp_do_segment and Received duplicate SYN
o kern/123559  net        [iwi] iwi periodically disassociates/associates [regre
o bin/123465   net        [ip6] route(8): route add -inet6 <ipv6_addr> -interfac
o kern/123463  net        [ipsec] [panic] repeatable crash related to ipsec-tool
o kern/123429  net        [nfe] [hang] "ifconfig nfe up" causes a hard system lo
o kern/123347  net        [bge] bge1: watchdog timeout -- linkstate changed to D
o conf/123330  net        [nsswitch.conf] Enabling samba wins in nsswitch.conf c
o kern/123256  net        [wpi] panic: blockable sleep lock with wpi(4)
f kern/123172  net        [bce] Watchdog timeout problems with if_bce
o kern/123160  net        [ip] Panic and reboot at sysctl kern.polling.enable=0
o kern/122989  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/122954  net        [lagg] IPv6 EUI64 incorrectly chosen for lagg devices
o kern/122928  net        [em] interface watchdog timeouts and stops receiving p
f kern/122839  net        [multicast] FreeBSD 7 multicast routing problem
p kern/122794  net        [lagg] Kernel panic after brings lagg(8) up if NICs ar
o kern/122780  net        [lagg] tcpdump on lagg interface during high pps wedge
o kern/122772  net        [em] em0 taskq panic, tcp reassembly bug causes radix 
o kern/122743  net        [mbuf] [panic] vm_page_unwire: invalid wire count: 0
o kern/122697  net        [ath] Atheros card is not well supported
o kern/122685  net        It is not visible passing packets in tcpdump(1)
o kern/122551  net        [bge] Broadcom 5715S no carrier on HP BL460c blade usi
o kern/122319  net        [wi] imposible to enable ad-hoc demo mode with Orinoco
o kern/122290  net        [netgraph] [panic] Netgraph related "kmem_map too smal
f kern/122252  net        [ipmi] [bge] IPMI problem with BCM5704 (does not work 
o kern/122195  net        [ed] Alignment problems in if_ed
o kern/122058  net        [em] [panic] Panic on em1: taskq
o kern/122033  net        [ral] [lor] Lock order reversal in ral0 at bootup [reg
o bin/121895   net        [patch] rtsol(8)/rtsold(8) doesn't handle managed netw
o kern/121872  net        [wpi] driver fails to attach on a fujitsu-siemens s711
s kern/121774  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/121706  net        [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit
o kern/121624  net        [em] [regression] Intel em WOL fails after upgrade to 
o kern/121555  net        [panic] Fatal trap 12: current process = 12 (swi1: net
o kern/121443  net        [gif] [lor] icmp6_input/nd6_lookup
o kern/121437  net        [vlan] Routing to layer-2 address does not work on VLA
o bin/121359   net        [patch] ppp(8): fix local stack overflow in ppp
o kern/121298  net        [em] [panic] Fatal trap 12: page fault while in kernel
o kern/121257  net        [tcp] TSO + natd  -> slow outgoing tcp traffic
o kern/121181  net        [panic] Fatal trap 3: breakpoint instruction fault whi
o kern/121080  net        [bge] IPv6 NUD problem on multi address config on bge0
o kern/120966  net        [rum] kernel panic with if_rum and WPA encryption
p docs/120945  net        [patch] ip6(4) man page lacks documentation for TCLASS
o kern/120566  net        [request]: ifconfig(8) make order of arguments more fr
o kern/120304  net        [netgraph] [patch] netgraph source assumes 32-bit time
o kern/120266  net        [udp] [panic] gnugk causes kernel panic when closing U
o kern/120232  net        [nfe] [patch] Bring in nfe(4) to RELENG_6
o kern/120130  net        [carp] [panic] carp causes kernel panics in any conste
o bin/120060   net        routed(8) deletes link-level routes in the presence of
o kern/119945  net        [rum] [panic] rum device in hostap mode, cause kernel 
o kern/119791  net        [nfs] UDP NFS mount of aliased IP addresses from a Sol
o kern/119617  net        [nfs] nfs error on wpa network when reseting/shutdown
f kern/119516  net        [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi
o kern/119432  net        [arp] route add -host <host> -iface <nic> causes arp e
o kern/119225  net        [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr
a bin/118987   net        ifconfig(8): ifconfig -l (address_family) does not wor
o sparc/118932 net        [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output
a kern/118879  net        [bge] [patch] bge has checksum problems on the 5703 ch
o kern/118727  net        [netgraph] [patch] [request] add new ng_pf module
a kern/118238  net        [bce] [patch] bce driver shows "no carrier" on Intel S
s kern/117717  net        [panic] Kernel panic with Bittorrent client.
o kern/117448  net        [carp] 6.2 kernel crash [regression]
o kern/117423  net        [vlan] Duplicate IP on different interfaces
o bin/117339   net        [patch] route(8): loading routing management commands 
o kern/117271  net        [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap
o kern/117043  net        [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM
o kern/116837  net        [tun] [panic] [patch] ifconfig tunX destroy: panic
o kern/116747  net        [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 
o bin/116643   net        [patch] [request] fstat(1): add INET/INET6 socket deta
o kern/116328  net        [bge]: Solid hang with bge interface
o kern/116185  net        [iwi] if_iwi driver leads system to reboot
o kern/115239  net        [ipnat] panic with 'kmem_map too small' using ipnat
o kern/115019  net        [netgraph] ng_ether upper hook packet flow stops on ad
o kern/115002  net        [wi] if_wi timeout. failed allocation (busy bit). ifco
o kern/114915  net        [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f
o kern/113895  net        [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R
o kern/112722  net        [ipsec] [udp] IP v4 udp fragmented packet reject
o kern/112686  net        [patm] patm driver freezes System (FreeBSD 6.2-p4) i38
o kern/112570  net        [bge] packet loss with bge driver on BCM5704 chipset
o bin/112557   net        [patch] ppp(8) lock file should not use symlink name
o kern/112528  net        [nfs] NFS over TCP under load hangs with "impossible p
o kern/111457  net        [ral] ral(4) freeze
o kern/110140  net        [ipw] ipw fails under load
o kern/109733  net        [bge] bge link state issues [regression]
o kern/109470  net        [wi] Orinoco Classic Gold PC Card Can't Channel Hop
o kern/109308  net        [pppd] [panic] Multiple panics kernel ppp suspected [r
o kern/109251  net        [re] [patch] if_re cardbus card won't attach
o bin/108895   net        pppd(8): PPPoE dead connections on 6.2 [regression]
o kern/108542  net        [bce] Huge network latencies with 6.2-RELEASE / STABLE
o kern/107944  net        [wi] [patch] Forget to unlock mutex-locks
o kern/107850  net        [bce] bce driver link negotiation is faulty
o conf/107035  net        [patch] bridge(8): bridge interface given in rc.conf n
o kern/106438  net        [ipf] ipfilter: keep state does not seem to allow repl
o kern/106316  net        [dummynet] dummynet with multipass ipfw drops packets 
o kern/106243  net        [nve] double fault panic in if_nve.c on high loads
o kern/105945  net        Address can disappear from network interface
s kern/105943  net        Network stack may modify read-only mbuf chain copies
o bin/105925   net        problems with ifconfig(8) and vlan(4) [regression]
o kern/105348  net        [ath] ath device stopps TX
o kern/104851  net        [inet6] [patch] On link routes not configured when usi
o kern/104751  net        [netgraph] kernel panic, when getting info about my tr
o kern/104485  net        [bge] Broadcom BCM5704C: Intermittent on newer chip ve
o kern/103191  net        Unpredictable reboot
o kern/103135  net        [ipsec] ipsec with ipfw divert (not NAT) encodes a pac
o conf/102502  net        [netgraph] [patch] ifconfig name does't rename netgrap
o kern/102035  net        [plip] plip networking disables parallel port printing
o kern/101948  net        [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau
o kern/100709  net        [libc] getaddrinfo(3) should return TTL info
o kern/100519  net        [netisr] suggestion to fix suboptimal network polling
o kern/98978   net        [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel
o kern/98597   net        [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu
o bin/98218    net        wpa_supplicant(8) blacklist not working
f bin/97392    net        ppp(8) hangs instead terminating
o kern/97306   net        [netgraph] NG_L2TP locks after connection with failed 
f kern/96268   net        [socket] TCP socket performance drops by 3000% if pack
o kern/96030   net        [bfe] [patch] Install hangs with Broadcomm 440x NIC in
o kern/95519   net        [ral] ral0 could not map mbuf
o kern/95288   net        [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr
o kern/95277   net        [netinet] [patch] IP Encapsulation mask_match() return
o kern/95267   net        packet drops periodically appear
s kern/94863   net        [bge] [patch] hack to get bge(4) working on IBM e326m
o kern/94162   net        [bge] 6.x kenel stale with bge(4)
o kern/93886   net        [ath] Atheros/D-Link DWL-G650 long delay to associate 
f kern/93378   net        [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo
o kern/93019   net        [ppp] ppp and tunX problems: no traffic after restarti
o kern/92880   net        [libc] [patch] almost rewritten inet_network(3) functi
f kern/92552   net        A serious bug in most network drivers from 5.X to 6.X 
s kern/92279   net        [dc] Core faults everytime I reboot, possible NIC issu
o kern/92090   net        [bge] bge0: watchdog timeout -- resetting
o kern/91859   net        [ndis] if_ndis does not work with Asus WL-138
s kern/91777   net        [ipf] [patch] wrong behaviour with skip rule inside an
o kern/91594   net        [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10
o kern/91364   net        [ral] [wep] WF-511 RT2500 Card PCI and WEP
o kern/91311   net        [aue] aue interface hanging
o kern/90890   net        [vr] Problems with network: vr0: tx shutdown timeout
s kern/90086   net        [hang] 5.4p8 on supermicro P8SCT hangs during boot if 
f kern/88082   net        [ath] [panic] cts protection for ath0 causes panic
o kern/87521   net        [ipf] [panic] using ipfilter "auth" keyword leads to k
o kern/87506   net        [vr] [patch] Fix alias support on vr interfaces
s kern/86920   net        [ndis] ifconfig: SIOCS80211: Invalid argument [regress
o kern/86103   net        [ipf] Illegal NAT Traversal in IPFilter
o kern/85780   net        'panic: bogus refcnt 0' in routing/ipv6
o bin/85445    net        ifconfig(8): deprecated keyword to ifconfig inoperativ
o kern/85266   net        [xe] [patch] xe(4) driver does not recognise Xircom XE
o kern/84202   net        [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre
o bin/82975    net        route change does not parse classfull network as given
o kern/82497   net        [vge] vge(4) on AMD64 only works when loaded late, not
f kern/81644   net        [vge] vge(4) does not work properly when loaded as a K
s kern/81147   net        [net] [patch] em0 reinitialization while adding aliase
o kern/80853   net        [ed] [patch] add support for Compex RL2000/ISA in PnP 
o kern/79895   net        [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 
f kern/79262   net        [dc] Adaptec ANA-6922 not fully supported
o bin/79228    net        [patch] extend arp(8) to be able to create blackhole r
o kern/78090   net        [ipf] ipf filtering on bridged packets doesn't work if
p kern/77913   net        [wi] [patch] Add the APDL-325 WLAN pccard to wi(4)
o kern/77341   net        [ip6] problems with IPV6 implementation
o kern/77273   net        [ipf] ipfilter breaks ipv6 statefull filtering on 5.3
s kern/77195   net        [ipf] [patch] ipfilter ioctl SIOCGNATL does not match 
o kern/75873   net        Usability problem with non-RFC-compliant IP spoof prot
s kern/75407   net        [an] an(4): no carrier after short time
f kern/73538   net        [bge] problem with the Broadcom BCM5788 Gigabit Ethern
o kern/71469   net        default route to internet magically disappears with mu
o kern/70904   net        [ipf] ipfilter ipnat problem with h323 proxy support
o kern/64556   net        [sis] if_sis short cable fix problems with NetGear FA3
s kern/60293   net        [patch] FreeBSD arp poison patch
o kern/54383   net        [nfs] [patch] NFS root configurations without dynamic 
f i386/45773   net        [bge] Softboot causes autoconf failure on Broadcom 570
s bin/41647    net        ifconfig(8) doesn't accept lladdr along with inet addr
s kern/39937   net        ipstealth issue
a kern/38554   net        [patch] changing interface ipaddress doesn't seem to w
o kern/35442   net        [sis] [patch] Problem transmitting runts in if_sis dri
o kern/34665   net        [ipf] [hang] ipfilter rcmd proxy "hangs".
o kern/31647   net        [libc] socket calls can return undocumented EINVAL
o kern/30186   net        [libc] getaddrinfo(3) does not handle incorrect servna
o kern/27474   net        [ipf] [ppp] Interactive use of user PPP and ipfilter c
o conf/23063   net        [arp] [patch] for static ARP tables in rc.network

309 problems total.

From max at love2party.net  Mon Jul 20 11:30:46 2009
From: max at love2party.net (Max Laier)
Date: Mon Jul 20 11:30:53 2009
Subject: FreeBSD + carp on VMWare ESX
In-Reply-To: <3D3254E2-4E45-4C67-84D2-DB05660D768F@shrew.net>
References: <4A638E76.2060706@shrew.net> <4A63A4B3.6090500@modulus.org>
	<3D3254E2-4E45-4C67-84D2-DB05660D768F@shrew.net>
Message-ID: <200907201318.08122.max@love2party.net>

On Monday 20 July 2009 01:25:03 Matthew Grooms wrote:
> The other options you mention are enabled by default. This problem
> also effects pre vSphere versions but only under certain
> circumstances. Others claim this is only an issue when NIC teaming is
> in use. However, I disabled this feature and still experience the
> problem without the patch applied.
>
> I'll be happy to post the config when I'm back in front of the
> computer. It's not a configuration problem. I'm not new to FreeBSD or
> carp and have quite a bit of time invested trying to get this to work.
>
> Have a look at the vmware forums. A lot of folks have reported the
> problem in great detail and, as far as I can tell, have yet to get
> this working.

There is clearly something very wrong with how the vswitch works and it's not 
really FreeBSD's job to work around these issues.  The patch you posted is 
rather intrusive and certainly not something we want in the tree.  You should 
talk to VMWare's support to fix the obvious short-comings in the vswitch 
design.

As for your patch - you want "IF_ADDR_[UN]LOCK(ifp);" around walking the 
address list.  Don't forget to unlock before the return.

> -Matthew
>
> On Jul 19, 2009, at 5:56 PM, Andrew Snow <andrew@modulus.org> wrote:
> > Matthew Grooms wrote:
> >> I was having problems running carp on VMWare ESX 4 and did a little
> >> investigative work to determine the cause of the problem.
> >
> > If have tested CARP on ESX 3.5u4 successfully with a 32-bit FreeBSD
> > guest with e1000 vNICs.
> >
> > As well as turning on promiscuous mode on the vSwitch, you have to
> > enable "MAC Address changes" and "Forged transmits" as CARP requires
> > these to work properly.
> >
> > Unless this is a vSphere-specific problem I must suspect your
> > configuration as the problem.  Do you want to post your CARP config?
> >
> >
> > - Andrew
>
> _______________________________________________
> 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"
>
>
> !DSPAM:4a63ab81519501271912576!

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

From hlh at restart.be  Mon Jul 20 12:57:56 2009
From: hlh at restart.be (Henri Hennebert)
Date: Mon Jul 20 12:58:10 2009
Subject: 8.0-BETA1 - for the record - different paths followed by IPv4
 and IPv6 for 'local' connections
In-Reply-To: <B583FBF374231F4A89607B4D08578A4304673665@bcs-mail03.internal.cacheflow.com>
References: <4A5734C3.3000806@restart.be>	<B583FBF374231F4A89607B4D08578A4304673660@bcs-mail03.internal.cacheflow.com>	<4A5864DC.1070106@restart.be>
	<B583FBF374231F4A89607B4D08578A4304673665@bcs-mail03.internal.cacheflow.com>
Message-ID: <4A6469CE.4060907@restart.be>

Li, Qing wrote:
> The patch has been committed, svn revision 195643.
> 
> Thanks,
> 
> -- Qing
> 
Just another case where the route must be created:

[root@avoriaz ~]# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
	tunnel inet 212.239.166.57 --> 94.23.44.41
	inet6 fe80::21d:60ff:fead:2ace%gif0 prefixlen 64 scopeid 0x4
	inet6 2001:41d0:2:2d29:1:ffff:: --> 2001:41d0:2:2d29:0:ffff:: prefixlen 
128
	options=1<ACCEPT_REV_ETHIP_VER>

[root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff::
PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: --> 
2001:41d0:2:2d29:1:ffff::
^C
--- 2001:41d0:2:2d29:1:ffff:: ping6 statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

[root@avoriaz ~]# route add -inet6 2001:41d0:2:2d29:1:ffff:: -interface lo0
add host 2001:41d0:2:2d29:1:ffff::: gateway lo0

[root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff::
PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: --> 
2001:41d0:2:2d29:1:ffff::
16 bytes from ::1, icmp_seq=0 hlim=64 time=0.531 ms
16 bytes from ::1, icmp_seq=1 hlim=64 time=0.884 ms
16 bytes from ::1, icmp_seq=2 hlim=64 time=0.748 ms
^C
--- 2001:41d0:2:2d29:1:ffff:: ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.531/0.721/0.884/0.145 ms

Thanks

Henri
> 
> -----Original Message-----
> From: Henri Hennebert [mailto:hlh@restart.be]
> Sent: Sat 7/11/2009 3:09 AM
> To: Li, Qing
> Cc: freebsd-stable@freebsd.org; freebsd-net@freebsd.org
> Subject: Re: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
>  
> Li, Qing wrote:
>> Hi,
>>
>> Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/
>> and let me know how it works out for you. I thought I had committed the patch 
>> but turned out I didn't.
> 
> I apply the patch, reset my pf.conf to its previous content and all is 
> running smoothly. By the way, I discover after my post that my 
> "solution" was not working for long (many bytes) connections and this is 
> solved too.
> 
> Many thank for your time
> 
> Henri
> 
> PS please commit as soon as possible
> 
>>> On 8.0-BETA1 there is an assymetry:
>>>
>>> netstat -rn display
>>>
>>> 192.168.24.1       link#3
>>> ....
>>> no entry for 2001:41d0:2:2d29:1:1::
>>>
>> This is by design as part of the new architecture in 8.0, which maintains 
>> the L2 ARP/ND6 and L3 routing tables separately.
>>
>> -- Qing
>>
>>
>>
>> -----Original Message-----
>> From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert
>> Sent: Fri 7/10/2009 5:32 AM
>> To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org
>> Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
>>  
>> Hello,
>>
>> After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when 
>> connecting with firefox to a local apache server using the global 
>> unicast IPv6 address of the local machine. pf.conf must be updated!
>>
>> My configuration:
>>
>> [root@avoriaz ~]# ifconfig em0
>>
>> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>> 	options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
>> 	ether 00:1d:60:ad:2a:ce
>> 	inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255
>> 	inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1
>> 	inet6 2001:41d0:2:2d29:1:1:: prefixlen 80
>> 	media: Ethernet 100baseTX (100baseTX <half-duplex>)
>> 	status: active
>>
>> [root@avoriaz ~]# host www.restart.bel
>> www.restart.bel is an alias for avoriaz.restart.bel.
>> avoriaz.restart.bel has address 192.168.24.1
>> avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1::
>>
>> pf.conf:
>>
>> int_if="em0"
>> block in  log all
>> block out log all
>> set skip on lo0
>> antispoof quick for $int_if inet
>> # Allow trafic with physical internal network
>> pass in quick on $int_if from ($int_if:network) to ($int_if) keep state
>> pass out quick on $int_if from ($int_if) to ($int_if:network) keep state
>>
>> The problem:
>>
>> [root@avoriaz ~]# telnet -4 www.restart.bel 80
>> Trying 192.168.24.1...
>> Connected to avoriaz.restart.bel.
>> Escape character is '^]'.
>> ^]
>> telnet> quit
>> Connection closed.
>> [root@avoriaz ~]# telnet -6 www.restart.bel 80
>> Trying 2001:41d0:2:2d29:1:1::...
>> --->Never connect and get a timeout!
>>
>> tcpdump and logging in pf show me that
>>
>> For a IPv4 connection:
>> the packet from telnet to apache pass 2 times on lo0 (out and in)
>> the answer packet from apache to telnet pass 2 times on lo0 (out and in)
>>
>> So no problem, there is `set skip on lo0'
>>
>> For a IPv6 connection:
>> The first packet from telnet to apache pass 2 times on lo0 (out and in)
>> The answer packet from apache to telnet path on em0  and is rejected
>> due to the default flags S/SA.
>>
>> So I have to change pf.conf and replace the last line:
>> pass out quick on $int_if from ($int_if) to ($int_if:network) \
>> keep state flags any
>>
>> Then all is OK
>>
>> By the way, on 7.2
>>
>> netstat -rn display
>>
>> 192.168.24.1        00:1d:60:ad:2a:ce
>> ....
>> 2001:41d0:2:2d29:1:1::            00:1d:60:ad:2a:ce
>>
>>
>> On 8.0-BETA1 there is an assymetry:
>>
>> netstat -rn display
>>
>> 192.168.24.1       link#3
>> ....
>> no entry for 2001:41d0:2:2d29:1:1::
>>
>> Hope it may help someone
>>
>> Henri
>>
>> _______________________________________________
>> freebsd-stable@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
>>
> 
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

From julian at elischer.org  Mon Jul 20 15:14:08 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jul 20 15:14:18 2009
Subject: GRE tunnel limitations
In-Reply-To: <126E45722B459248997856ECB72DEB7701285DED@host.lodgenet.com>
References: <126E45722B459248997856ECB72DEB7701285DC0@host.lodgenet.com><4A5F5927.3080904@elischer.org>
	<126E45722B459248997856ECB72DEB7701285DC2@host.lodgenet.com>
	<126E45722B459248997856ECB72DEB7701285DED@host.lodgenet.com>
Message-ID: <4A6489BF.50207@elischer.org>

Jacobs, Brian wrote:
> For all interested, I've been doing some implementation work over the
> weekend.  Tonight I did a cutover of 766 GRE tunnels to a RELENG_7 box:

good to know, though load with traffic is more important.

talk to Philip Paeps about crypto support.. some crypto offload
cards slow down the system.. you need to have a PCI-E one or PCI-X
at slowest for it to be worth while on a fast machine.

(CC'd)




> 
> [root@yttrium /lso/dev/real]# uname -a
> FreeBSD yttrium.colo.XXXXXXXXXX.net 7.1-RELEASE FreeBSD 7.1-RELEASE #1:
> Mon Apr 13 11:37:56 EDT 2009     bjacobs@yttrium.colo.
> XXXXXXXXXX.net:/usr/obj/usr/src/sys/YTTRIUM  i386
> [root@yttrium /lso/dev/real]# ifconfig |grep gre |wc -l
>      766
> [root@yttrium /lso/dev/real]# netstat -nr |wc -l 
>     1494
> [root@yttrium /lso/dev/real]# uptime
>  5:32AM  up 74 days, 11:01, 5 users, load averages: 0.00, 0.26, 0.59
> 
> Load average is nothing (hovers between 0 and .20), although there isn't
> much traversing the tunnels (yet), nor have we implemented IPsec (yet --
> next step, have crypto card if needed).  Another project commencing
> shortly will push/pull about 10mb/s aggregate (estimate) across the
> collective tunnels.
> 
> Please advise if the group (or any individuals) want performance data
> from real world usage.
> 
> /bmj
> 
> 
> -----Original Message-----
> From: owner-freebsd-net@freebsd.org
> [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jacobs, Brian
> Sent: Thursday, July 16, 2009 12:50 PM
> To: Julian Elischer
> Cc: freebsd-net@freebsd.org
> Subject: RE: GRE tunnel limitations
> 
> IP unnumbered between the two boxen.  I've built some scripts to
> automatically generate config files, and then other scripts to
> automagically create the GRE interfaces and inject appropriate routes.
> 
> GRE numbers are assigned sequentially based on config file lines (and
> are of no consequence):
> 
> gre45: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu
> 1476
>  tunnel inet 10.3.100.39 --> 207.230.84.130
>  inet 10.3.100.39 --> 10.11.146.129 netmask 0xffffffff 
> gre46: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> metric 0 mtu
> 1476
>  tunnel inet 10.3.100.39 --> 12.35.57.131
>  inet 10.3.100.39 --> 10.10.201.1 netmask 0xffffffff
> 
> 10.3.100.39 is the primary Ethernet interface address of the local box
> (terminator).  10.10.201.1 is the inside Ethernet of the remote box.
> 
> Routing statement for 10.0.0.0/8 live on the remote box, and individual
> routes live on the concentrator:
> 
> root@yttrium /root# netstat -nr | grep 10.10.201
> 10.10.201.0/26     10.10.201.1        UGS         0     2042  gre46
> 10.10.201.1        10.3.100.39        UH          1    49263  gre46
> 
> /bmj
> 
> 
> -----Original Message-----
> From: Julian Elischer [mailto:julian@elischer.org] 
> Sent: Thursday, July 16, 2009 12:45 PM
> To: Jacobs, Brian
> Cc: freebsd-net@freebsd.org
> Subject: Re: GRE tunnel limitations
> 
> Jacobs, Brian wrote:
>> Does anyone have some realistic data on the number of GRE/ipip tunnels
>> FreeBSD 7.x can reasonably terminate?  Assume no IPsec, just standard
>> encapsulation.  I have an ad-hoc need to terminate about 1,4000 static
>> GRE tunnels (as Cisco 7206's are backordered until September).  J
>>
>>  
>>
>> Thanks in advance!
>>
>>  
>>
>> /bmj
>>
>> _______________________________________________
>> 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"
> 
> 
> 
> The limitation would be that there is an interface for reach one and 
> the interface 'interface' uses a linked list.  it might work but there 
> would probably be scaling issues.
> 
> I've often thought that what we need is a way to do "bulk encapsulatin 
> interfaces" where there is not an "interface" assigned to each 
> destination. (at least not one that shows up in 'ifconfig').
> 
> How will you want to decide which gre interface to use for a given 
> packet? is it just a standard routing decision based on the remote 
> address?
> 
> 
> 
> _______________________________________________
> 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"

From eri at freebsd.org  Mon Jul 20 18:25:31 2009
From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=)
Date: Mon Jul 20 18:25:37 2009
Subject: FreeBSD + carp on VMWare ESX
In-Reply-To: <200907201318.08122.max@love2party.net>
References: <4A638E76.2060706@shrew.net> <4A63A4B3.6090500@modulus.org> 
	<3D3254E2-4E45-4C67-84D2-DB05660D768F@shrew.net>
	<200907201318.08122.max@love2party.net>
Message-ID: <9a542da30907201100l236eff1cyaf04f7ca6b8c1c8e@mail.gmail.com>

On Mon, Jul 20, 2009 at 1:18 PM, Max Laier<max@love2party.net> wrote:
> On Monday 20 July 2009 01:25:03 Matthew Grooms wrote:
>> The other options you mention are enabled by default. This problem
>> also effects pre vSphere versions but only under certain
>> circumstances. Others claim this is only an issue when NIC teaming is
>> in use. However, I disabled this feature and still experience the
>> problem without the patch applied.
>>
>> I'll be happy to post the config when I'm back in front of the
>> computer. It's not a configuration problem. I'm not new to FreeBSD or
>> carp and have quite a bit of time invested trying to get this to work.
>>
>> Have a look at the vmware forums. A lot of folks have reported the
>> problem in great detail and, as far as I can tell, have yet to get
>> this working.
>
> There is clearly something very wrong with how the vswitch works and it's not
> really FreeBSD's job to work around these issues. ?The patch you posted is
> rather intrusive and certainly not something we want in the tree. ?You should
> talk to VMWare's support to fix the obvious short-comings in the vswitch
> design.

I think this is a problem that has been there since carp merge.
By looking at in_arpinput() in if_ether.c around this comment
        /*
	 * For a bridge, we want to check the address irrespective
	 * of the receive interface. (This will change slightly
	 * when we have clusters of interfaces).
	 * If the interface does not match, but the recieving interface
	 * is part of carp, we call carp_iamatch to see if this is a
	 * request for the virtual host ip.
	 * XXX: This is really ugly!
         */
Following the code the check for the bridge case is done for the
destination ip(protocol) address and for the source one while for the
carp this is done only for the destination ip(protocol) address. Which
seems wrong since the same check should apply for carp.
This would eliminate a looping back packet.
This is prevented as it is now for  target ip address but not by
source ip address since the check is missing.
The following patch against head should fix this IMO. It is untested
but seems the right solution for this.

Technically this would make code around the 'match' label discard the packet.


Index: if_ether.c
===================================================================
--- if_ether.c	(revision 195741)
+++ if_ether.c	(working copy)
@@ -522,7 +522,7 @@
 		}
 #endif
 	}
-	LIST_FOREACH(ia, INADDR_HASH(isaddr.s_addr), ia_hash)
+	LIST_FOREACH(ia, INADDR_HASH(isaddr.s_addr), ia_hash) {
 		if (((bridged && ia->ia_ifp->if_bridge != NULL) ||
 		    ia->ia_ifp == ifp) &&
 		    isaddr.s_addr == ia->ia_addr.sin_addr.s_addr) {
@@ -530,6 +530,17 @@
 			IN_IFADDR_RUNLOCK();
 			goto match;
 		}
+#ifdef DEV_CARP
+                if (ifp->if_carp != NULL &&
+                    carp_iamatch(ifp->if_carp, ia, &isaddr, &enaddr) &&
+                    isaddr.s_addr == ia->ia_addr.sin_addr.s_addr) {
+                        carp_match = 1;
+                        ifa_ref(&ia->ia_ifa);
+                        IN_IFADDR_RUNLOCK();
+                        goto match;
+                }
+#endif
+	}

 #define BDG_MEMBER_MATCHES_ARP(addr, ifp, ia)				\
   (ia->ia_ifp->if_bridge == ifp->if_softc &&				\


>
> As for your patch - you want "IF_ADDR_[UN]LOCK(ifp);" around walking the
> address list. ?Don't forget to unlock before the return.
>
>> -Matthew
>>
>> On Jul 19, 2009, at 5:56 PM, Andrew Snow <andrew@modulus.org> wrote:
>> > Matthew Grooms wrote:
>> >> I was having problems running carp on VMWare ESX 4 and did a little
>> >> investigative work to determine the cause of the problem.
>> >
>> > If have tested CARP on ESX 3.5u4 successfully with a 32-bit FreeBSD
>> > guest with e1000 vNICs.
>> >
>> > As well as turning on promiscuous mode on the vSwitch, you have to
>> > enable "MAC Address changes" and "Forged transmits" as CARP requires
>> > these to work properly.
>> >
>> > Unless this is a vSphere-specific problem I must suspect your
>> > configuration as the problem. ?Do you want to post your CARP config?
>> >
>> >
>> > - Andrew
>>
>> _______________________________________________
>> 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"
>>
>>
>> !DSPAM:4a63ab81519501271912576!
>
> --
> /"\ ?Best regards, ? ? ? ? ? ? ? ? ? ? ?| mlaier@freebsd.org
> \ / ?Max Laier ? ? ? ? ? ? ? ? ? ? ? ? ?| ICQ #67774661
> ?X ? http://pf4freebsd.love2party.net/ ?| mlaier@EFnet
> / \ ?ASCII Ribbon Campaign ? ? ? ? ? ? ?| Against HTML Mail and News
>
> _______________________________________________
> 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"
>



-- 
Ermal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_ether.c.diff
Type: application/octet-stream
Size: 1015 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090720/77011907/if_ether.c.obj
From gnemmi at gmail.com  Mon Jul 20 21:50:05 2009
From: gnemmi at gmail.com (Gonzalo Nemmi)
Date: Mon Jul 20 21:50:12 2009
Subject: kern/136876: [bge] bge will not resume properly after suspend
Message-ID: <200907202150.n6KLo5ib004305@freefall.freebsd.org>

The following reply was made to PR kern/136876; it has been noted by GNATS.

From: Gonzalo Nemmi <gnemmi@gmail.com>
To: bug-followup@freebsd.org,
 adamk@voicenet.com
Cc:  
Subject: Re: kern/136876: [bge] bge will not resume properly after suspend
Date: Mon, 20 Jul 2009 18:22:37 -0300

 I can confirm experiencing the same behaviour on my Dell 1318 running 
 FreeBSD 8.0-BETA2 for i386 using the stock kernel and 
 kern.smp.disabled="1" on my device.hints.
 
 Hw: Dell 1318, Intel(R) Celeron(R) CPU 560@2.13GHz.
 
 bge0@pci0:9:0:0:        class=0x020000 card=0x02861028 chip=0x171314e4 
 rev=0x02 
 hdr=0x00
 vendor     = 'Broadcom Corporation'
 device     = 'Broadcom NetLink (TM) Fast Ethernet (BCM5906m)'
 class      = network
 subclass   = ethernet
 bar   [10] = type Memory, range 64, base 0xf69f0000, size 65536, enabled
 cap 01[48] = powerspec 3  supports D0 D3  current D0
 cap 03[50] = VPD
 cap 09[58] = vendor (length 120)
 cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message
 cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1)
 
 kldstat
 
 Id Refs Address    Size     Name
  1   28 0xc0400000 cf6c70   kernel
  2    1 0xc10f7000 11bc0    if_bge.ko
  3    1 0xc1109000 1ac4c    snd_hda.ko
  4    2 0xc1124000 61f78    sound.ko
  5    1 0xc1186000 2af4     coretemp.ko
  6    1 0xc1189000 a6d8     i915.ko
  7    2 0xc1194000 177d4    drm.ko
 
 
 kldunload if_bge snd_hda
 
 Jul 20 17:50:49 gargoyle login: ROOT LOGIN (root) ON ttyv0
 Jul 20 17:51:06 gargoyle kernel: brgphy0: detached
 Jul 20 17:51:06 gargoyle kernel: lock order reversal:
 Jul 20 17:51:06 gargoyle kernel: 1st 0xc0dba45c kernel linker (kernel 
 linker) @ /usr/src/sys/kern/kern_linker.c:1079
 Jul 20 17:51:06 gargoyle kernel: 2nd 0xc0dbbc64 sysctl lock (sysctl 
 lock) @ /usr/src/sys/kern/kern_sysctl.c:257
 Jul 20 17:51:06 gargoyle kernel: KDB: stack backtrace:
 Jul 20 17:51:06 gargoyle kernel: 
 db_trace_self_wrapper(c0c6baf4,e6daba34,c08bc995,c08ad6db,c0c6e989,...) 
 at db_trace_self_wrapper+0x26
 Jul 20 17:51:06 gargoyle kernel: 
 kdb_backtrace(c08ad6db,c0c6e989,c452bc88,c4529e10,e6daba90,...) at 
 kdb_backtrace+0x29
 Jul 20 17:51:06 gargoyle kernel: 
 _witness_debugger(c0c6e989,c0dbbc64,c0c69667,c4529e10,c0c6956e,...) at 
 _witness_debugger+0x25
 Jul 20 17:51:06 gargoyle kernel: 
 witness_checkorder(c0dbbc64,9,c0c6956e,101,0,...) at 
 witness_checkorder+0x839
 Jul 20 17:51:06 gargoyle kernel: 
 _sx_xlock(c0dbbc64,0,c0c6956e,101,c4722c00,...) at _sx_xlock+0x85
 Jul 20 17:51:06 gargoyle kernel: 
 sysctl_ctx_free(c4722c4c,c4722c00,e6dabb18,c08a3c85,c4722c00,...) at 
 sysctl_ctx_free+0x30
 Jul 20 17:51:06 gargoyle kernel: 
 device_sysctl_fini(c4722c00,0,c0d4c848,c472a810,c4ab3400,...) at 
 device_sysctl_fini+0x1a
 Jul 20 17:51:06 gargoyle kernel: 
 device_detach(c4722c00,c4722b80,e6dabb38,c06bc622,c4722b80,...) at 
 device_detach+0x1f5
 Jul 20 17:51:06 gargoyle kernel: 
 bus_generic_detach(c4722b80,c4722b80,e6dabb64,c08a3b1c,c4722b80,...) at 
 bus_generic_detach+0x29
 Jul 20 17:51:06 gargoyle kernel: 
 miibus_detach(c4722b80,c45d6060,c0d4ca68,a3c,c0c76f47,...) at 
 miibus_detach+0x12
 Jul 20 17:51:06 gargoyle kernel: 
 device_detach(c4722b80,c472b008,e6dabb98,c10ff7ff,c4722300,...) at 
 device_detach+0x8c
 Jul 20 17:51:06 gargoyle kernel: 
 bus_generic_detach(c4722300,1,c1104b66,aec,c4722300,...) at 
 bus_generic_detach+0x29
 Jul 20 17:51:06 gargoyle kernel: 
 bge_detach(c4722300,c4677060,c0d4ca68,a3c,c4526300,...) at 
 bge_detach+0xbf
 Jul 20 17:51:06 gargoyle kernel: 
 device_detach(c4722300,c086c843,c0dbb570,c1106c20,c456fb80,...) at 
 device_detach+0x8c
 Jul 20 17:51:06 gargoyle kernel: 
 driver_module_handler(c4526300,1,c1106c20,109,0,...) at 
 driver_module_handler+0x29c
 Jul 20 17:51:06 gargoyle kernel: 
 module_unload(c4526300,c0c652ef,273,270,c08604b6,...) at 
 module_unload+0x43
 Jul 20 17:51:06 gargoyle kernel: 
 linker_file_unload(c4544200,0,c0c652ef,437,c10f7000,...) at 
 linker_file_unload+0x15e
 Jul 20 17:51:06 gargoyle kernel: 
 kern_kldunload(c4b346c0,2,0,e6dabd2c,c0ba8dd3,...) at 
 kern_kldunload+0xd5
 Jul 20 17:51:06 gargoyle kernel: 
 kldunloadf(c4b346c0,e6dabcf8,8,c0c6fa4b,c0d50450,...) at 
 kldunloadf+0x2b
 Jul 20 17:51:06 gargoyle kernel: syscall(e6dabd38) at syscall+0x2a3
 Jul 20 17:51:06 gargoyle kernel: Xint0x80_syscall() at 
 Xint0x80_syscall+0x20
 Jul 20 17:51:06 gargoyle kernel: --- syscall (444, FreeBSD ELF32, 
 kldunloadf), eip = 0x280d516b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 ---
 Jul 20 17:51:06 gargoyle kernel: miibus0: detached
 Jul 20 17:51:06 gargoyle kernel: bge0: detached
 Jul 20 17:51:06 gargoyle kernel: sysctl_unregister_oid: failed to 
 unregister sysctl
 Jul 20 17:51:06 gargoyle kernel: pcm0: detached
 Jul 20 17:51:06 gargoyle kernel: hdac0: detached
 
 
 kldoad snd_hda
 
 Jul 20 17:52:16 gargoyle kernel: hdac0: <Intel 82801H High Definition 
 Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at device 27.0 on 
 pci0
 Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Driver Revision: 
 20090624_0136
 Jul 20 17:52:16 gargoyle kernel: hdac0: [ITHREAD]
 Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel STAC9228X
 Jul 20 17:52:16 gargoyle kernel: bge0: <Broadcom BCM5906 A2, ASIC rev. 
 0xc002> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on pci9
 Jul 20 17:52:16 gargoyle kernel: miibus0: <MII bus> on bge0
 Jul 20 17:52:16 gargoyle kernel: brgphy0: <BCM5906 10/100baseTX PHY> PHY 
 1 on miibus0
 Jul 20 17:52:16 gargoyle kernel: brgphy0:  10baseT, 10baseT-FDX, 
 100baseTX, 100baseTX-FDX, auto
 Jul 20 17:52:16 gargoyle kernel: bge0: Ethernet address: 
 00:23:ae:04:ba:ca
 Jul 20 17:52:16 gargoyle kernel: bge0: [ITHREAD]
 Jul 20 17:52:16 gargoyle kernel: pcm0: <HDA Sigmatel STAC9228X PCM #0 
 Analog> at cad 0 nid 1 on hdac0
 Jul 20 17:52:16 gargoyle kernel: bge0: link state changed to DOWN
 Jul 20 17:52:18 gargoyle kernel: bge0: link state changed to UP
 
 
 acpiconf -s 3
 
 Jul 20 17:53:51 gargoyle acpi: suspend at 20090720 17:53:51
 Jul 20 17:53:56 gargoyle kernel: fwohci0: fwohci_pci_suspend
 Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 
 0, val 32768)
 Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, 
 val 0xffffffff)
 Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 
 24, val 0xffffffff)
 Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 
 16, val 0xffffffff)
 Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 
 16, val 0)
 Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 
 16, val 0xffffffff)
 Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 
 16, val 0)
 Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 
 23, val 18)
 Jul 20 17:54:25 gargoyle kernel: bge0: flow-through queue init failed
 Jul 20 17:54:25 gargoyle kernel: bge0: initialization failure
 Jul 20 17:54:25 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 
 ports.
 Jul 20 17:54:25 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes.
 Jul 20 17:54:25 gargoyle kernel: fwohci0: Initiate bus reset
 Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset
 Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: 
 node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode
 Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable 
 IRM irm(0)  (me) 
 Jul 20 17:54:25 gargoyle kernel: firewire0: bus manager 0 
 Jul 20 17:54:25 gargoyle kernel: fwohci0: unrecoverable error
 Jul 20 17:54:25 gargoyle kernel: wakeup from sleeping state (slept 
 00:00:29)
 Jul 20 17:54:25 gargoyle acpi: resumed at 20090720 17:54:25
 
 
 more info:
 http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009023.html
 http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009385.html
 
 This problem also affects FreeBSD 7.2-RELEASE:
 http://forums.freebsd.org/showthread.php?t=3886
From linimon at FreeBSD.org  Tue Jul 21 01:04:05 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Tue Jul 21 01:04:12 2009
Subject: kern/136946: [fwohci] fwohci throws an"unrecoverable error"
	upon resume from suspend
Message-ID: <200907210104.n6L144km058809@freefall.freebsd.org>

Synopsis: [fwohci] fwohci throws an"unrecoverable error" upon resume from suspend

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Jul 21 01:03:56 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136946
From linimon at FreeBSD.org  Tue Jul 21 04:51:32 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Tue Jul 21 04:51:45 2009
Subject: kern/136946: [fwohci] fwohci throws an"unrecoverable error"
	upon resume from suspend
Message-ID: <200907210451.n6L4pW1W036981@freefall.freebsd.org>

Synopsis: [fwohci] fwohci throws an"unrecoverable error" upon resume from suspend

Responsible-Changed-From-To: freebsd-net->freebsd-firewire
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Jul 21 04:51:09 UTC 2009
Responsible-Changed-Why: 
fix assignment.

http://www.freebsd.org/cgi/query-pr.cgi?pr=136946
From learner.study at gmail.com  Tue Jul 21 09:37:56 2009
From: learner.study at gmail.com (Learner Study)
Date: Tue Jul 21 09:38:03 2009
Subject: TCP SACK
Message-ID: <7efa8a7d0907210207m327a1252nee4a04f5e4ea7a@mail.gmail.com>

Hello experts:

Is there is reason why freebsd TCP implementation limits the number of SACK
blocks on receiver side to MAX_SACK_BLOCKS whereas the sender side SACK
holes are implemented as a linked list?

Any issues if someone decides to use receiver side linked list as well
(instead of fixed sized array)?

Thanks in advance for your suggestions.
From bra at fsn.hu  Tue Jul 21 13:08:26 2009
From: bra at fsn.hu (Attila Nagy)
Date: Tue Jul 21 13:08:33 2009
Subject: broadcom 57710 support
In-Reply-To: <50667.57004.qm@web63901.mail.re1.yahoo.com>
References: <50667.57004.qm@web63901.mail.re1.yahoo.com>
Message-ID: <4A65B9E1.80208@fsn.hu>

Barney Cordoba wrote:
>> Any one knows if there is any near plan to develop drivers
>> for
>>
>> network cards based on broadcom NetXtereme II 57710
>>
>> 10 GbE controller?
>>
>> -----------------------
>> best regards
>> Hooman Fazaeli
>>     
>
> Ok, I'll bite. What is so special about this particular part that you 
> simply must use it in your 10GbE server?
>
>   
A possible cause -at least for me- is that HP switched from the Gigabit 
Broadcoms for these 10GE versions. So newer machines (for example the HP 
BL460c G6) come with Broadcom 57711 instead of the 57xx ones (supported 
by bge and bce).

FreeBSD ran very well on HP machines, it would be good if this could 
continue.
From barney_cordoba at yahoo.com  Tue Jul 21 14:49:09 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Tue Jul 21 14:49:15 2009
Subject: broadcom 57710 support
Message-ID: <634188.92246.qm@web63905.mail.re1.yahoo.com>




--- On Tue, 7/21/09, Attila Nagy <bra@fsn.hu> wrote:

> From: Attila Nagy <bra@fsn.hu>
> Subject: Re: broadcom 57710 support
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: freebsd-net@freebsd.org, "Hooman Fazaeli" <ebastan10@yahoo.com>
> Date: Tuesday, July 21, 2009, 8:51 AM
> Barney Cordoba wrote:
> >> Any one knows if there is any near plan to develop
> drivers
> >> for
> >> 
> >> network cards based on broadcom NetXtereme II
> 57710
> >> 
> >> 10 GbE controller?
> >> 
> >> -----------------------
> >> best regards
> >> Hooman Fazaeli
> >>? ???
> > 
> > Ok, I'll bite. What is so special about this
> particular part that you simply must use it in your 10GbE
> server?
> > 
> >???
> A possible cause -at least for me- is that HP switched from
> the Gigabit Broadcoms for these 10GE versions. So newer
> machines (for example the HP BL460c G6) come with Broadcom
> 57711 instead of the 57xx ones (supported by bge and bce).
> 

I wouldn't use a "new" server that doesn't support Nehelam. You're better
off getting a 1U server that has exactly what you want in it, rather than
having to hope that whoever happens to write a driver for this new part
does a good job. Even then you're stuck with last year's CPU model, 
guaranteeing 20% less performance. 

Barney


      
From davidch at broadcom.com  Tue Jul 21 16:41:45 2009
From: davidch at broadcom.com (David Christensen)
Date: Tue Jul 21 16:41:53 2009
Subject: broadcom 57710 support
In-Reply-To: <4A5C3EE6.7010704@sepehrs.com>
References: <4A5C3EE6.7010704@sepehrs.com>
Message-ID: <5D267A3F22FD854F8F48B3D2B523819339EC15C6D5@IRVEXCHCCR01.corp.ad.broadcom.com>

> Is there any near plan to develop drivers for network cards 
> based on broadcom NetXtereme II 57710 10 GbE controller?

I have written a driver to support the 57710/57711/57711E
parts, bxe(9), but I haven't released it as I haven't been
able to get much testing mileage on it.  The biggest
challenge is the wide array of PHYs used in the 10GbE space
which makes testing a complex issue (I think we have 7 or 8
PHYs today which various customers use).  

If there are some developers who are interested in getting a
version of the driver and helping work out some of the bugs
please contact me directly.  Ideally I'd like to have this
driver ready for 8.1.

Dave
From qingli at FreeBSD.org  Tue Jul 21 19:06:39 2009
From: qingli at FreeBSD.org (Qing Li)
Date: Tue Jul 21 19:06:45 2009
Subject: useloopback sysctl vars
Message-ID: <200907211906.n6LJ6dvu035927@freefall.freebsd.org>


Hi,

Does anyone set either of the following systl variables to 0?
    net.link.ether.inet.useloopback
    net.inet6.icmp6.nd6_useloopback
If so, would you mind letting me know your reasons?

Thanks,

-- Qing

From bra at fsn.hu  Tue Jul 21 19:47:14 2009
From: bra at fsn.hu (Attila Nagy)
Date: Tue Jul 21 19:47:21 2009
Subject: broadcom 57710 support
In-Reply-To: <634188.92246.qm@web63905.mail.re1.yahoo.com>
References: <634188.92246.qm@web63905.mail.re1.yahoo.com>
Message-ID: <4A661B3E.1060007@fsn.hu>

Barney Cordoba wrote:
>> A possible cause -at least for me- is that HP switched from
>> the Gigabit Broadcoms for these 10GE versions. So newer
>> machines (for example the HP BL460c G6) come with Broadcom
>> 57711 instead of the 57xx ones (supported by bge and bce).
>>
>>     
>
> I wouldn't use a "new" server that doesn't support Nehelam. You're better
> off getting a 1U server that has exactly what you want in it, rather than
> having to hope that whoever happens to write a driver for this new part
> does a good job. Even then you're stuck with last year's CPU model, 
> guaranteeing 20% less performance. 
>   
The BL460c G6 supports Nehalem (Intel 55xx), and 1U server instead of a 
blade is all what I want.


From rascal1981 at gmail.com  Wed Jul 22 03:42:40 2009
From: rascal1981 at gmail.com (rascal)
Date: Wed Jul 22 03:42:47 2009
Subject: question regarding IPSEC Setup
In-Reply-To: <20090717062218.GL6896@verio.net>
References: <3228ef7c0907130809n29566514xb2c1f522e1da8a3f@mail.gmail.com>
	<20090714134131.GA23925@traktor.dnepro.net>
	<3228ef7c0907140918i5d90dc44q995a4210f2767f9a@mail.gmail.com>
	<20090715001514.GU6896@verio.net>
	<3228ef7c0907141843s30df148eu2c6c64acd7748029@mail.gmail.com>
	<20090715021251.GV6896@verio.net>
	<3228ef7c0907142001y650892b3w696576647086ba38@mail.gmail.com>
	<20090717062218.GL6896@verio.net>
Message-ID: <3228ef7c0907212042vcc77f7cx1e73fc48ae9e8628@mail.gmail.com>

Sorry for the delay on replying to this but I have been horribly swamped
with a handful of other fires.  I am coming back to this tomorrow and with a
fresh cisco device!  So I am hoping to have an update for you all tomorrow
or the next day.  Thanks again David for the fresh cisco example; I can
already see at least to points of issue that I have made!  I'll get back to
you all soon and thanks again!

On Fri, Jul 17, 2009 at 2:22 AM, David DeSimone <fox@verio.net> wrote:

> rascal <rascal1981@gmail.com> wrote:
> >
> > If I could ask one more favor; what does your cisco config look like
> > that would match one of these?  I have got mine configed based on
> > someone else's tunnel specs and while I am sure they are comparable I
> > wanted to make sure I wasn't missing anything.
>
> Here's an example config that I sanitized from one of our Cisco routers;
> I think it should work, but it's only an example.  At some point you
> have to adapt these configs to your own situation.  :)
>
>    crypto isakmp policy 1
>     encr aes
>     authentication pre-share
>     group 2
>
>    crypto isakmp key SecretKey!! address 11.22.33.44
>
>    crypto ipsec transform-set AES-SHA1 esp-aes esp-sha-hmac
>
>    crypto map IPSEC local-address GigabitEthernet0/1
>
>    crypto map IPSEC 1 ipsec-isakmp
>     set peer 11.22.33.44
>     set transform-set AES-SHA1
>     match address remote-site
>
>    interface GigabitEthernet0/1
>     ip address 55.66.77.88 255.255.255.224
>     crypto map IPSEC
>
>    ip access-list extended remote-site
>     permit ip 10.20.50.60 0.0.0.255 10.10.30.40 0.0.0.255
>     permit ip 10.20.50.60 0.0.0.255 10.10.30.50 0.0.0.255
>     permit ip 10.20.50.70 0.0.0.255 10.10.30.40 0.0.0.255
>     permit ip 10.20.50.70 0.0.0.255 10.10.30.50 0.0.0.255
>
> --
> David DeSimone == Network Admin == fox@verio.net
>  "I don't like spinach, and I'm glad I don't, because if I
>   liked it I'd eat it, and I just hate it." -- Clarence Darrow
>
>
> This email message is intended for the use of the person to whom it has
> been sent, and may contain information that is confidential or legally
> protected. If you are not the intended recipient or have received this
> message in error, you are not authorized to copy, distribute, or otherwise
> use this message or its attachments. Please notify the sender immediately by
> return e-mail and permanently delete this message and any attachments.
> Verio, Inc. makes no warranty that this email is error or virus free.  Thank
> you.
>
From delphij at delphij.net  Wed Jul 22 06:32:30 2009
From: delphij at delphij.net (Xin LI)
Date: Wed Jul 22 06:32:39 2009
Subject: LOR: PFil hook read/write mutex vs if_bridge
Message-ID: <4A66B227.6010706@delphij.net>

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

Looks like a new one, anybody care about it?

(maybe harmless though.  I haven't get a chance to exercise it further)

lock order reversal:
 1st 0xffffffff809ee9c8 PFil hook read/write mutex (PFil hook read/write
mutex) @ /usr/src/sys/net/pfil.c:74
 2nd 0xffffff0003326418 if_bridge (if_bridge) @
/usr/src/sys/net/if_bridge.c:1848
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_mtx_lock_flags() at _mtx_lock_flags+0x78
bridge_output() at bridge_output+0x67
ether_output() at ether_output+0x558
pf_route() at pf_route+0x5ec
pf_test() at pf_test+0x7c4
pf_check_in() at pf_check_in+0x39
pfil_run_hooks() at pfil_run_hooks+0xcf
ip_input() at ip_input+0x2eb
netisr_dispatch_src() at netisr_dispatch_src+0xb8
ether_demux() at ether_demux+0x17d
ether_input() at ether_input+0x18e
em_rxeof() at em_rxeof+0x254
em_handle_rxtx() at em_handle_rxtx+0x4b
taskqueue_run() at taskqueue_run+0x96
taskqueue_thread_loop() at taskqueue_thread_loop+0x3f
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
- --- trap 0, rip = 0, rsp = 0xffffff80000a6d30, rbp = 0 ---


- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iEYEARECAAYFAkpmsicACgkQi+vbBBjt66DkhwCgojNp7zSLd/TNGrNg0rzVMpQ4
/XgAmwdOggz33OT8kBNjClVjz8R56Uy8
=7PU5
-----END PGP SIGNATURE-----
From wjw at digiware.nl  Wed Jul 22 08:18:53 2009
From: wjw at digiware.nl (Willem Jan Withagen)
Date: Wed Jul 22 08:19:00 2009
Subject: IPv6 and ipfw
Message-ID: <4A66CBE2.6050606@digiware.nl>

Hi,

Running 7.2 I tried to insert this into my IPFW rules

# ipfw add allow udp from any to 2001:xxx:3::113,2001:xxxx:3::116 \
	dst-port 10001-10100 keep-state
ipfw: bad netmask ``xxxx:3::113''

also:
# ipfw add allow udp from any to trixbox.ip6 dst-port 10001-10100 keep-state
ipfw: hostname ``trixbox.ip6'' unknown
Exit 68
# host trixbox.ip6
trixbox.ip6.digiware.nl has IPv6 address 2001:4cb8:3::116

So it looks like what is in the manual is overly optimistic:
----
      addr6-list: ip6-addr[,addr6-list]

      ip6-addr:
              A host or subnet specified one of the following ways:

              numeric-ip | hostname
                      Matches a single IPv6 address as allowed by inet_pton(3)
                      or a hostname.  Hostnames are resolved at the time the
                      rule is added to the firewall list.

              addr/masklen
                      Matches all IPv6 addresses with base addr (specified as
                      allowed by inet_pton or a hostname) and mask width of
                      masklen bits.

              No support for sets of IPv6 addresses is provided because IPv6
              addresses are typically random past the initial prefix.
----

Anybody else ran into this?
Or should I file this as a PR.

--WjW
From lstewart at freebsd.org  Wed Jul 22 09:11:26 2009
From: lstewart at freebsd.org (Lawrence Stewart)
Date: Wed Jul 22 09:11:59 2009
Subject: TCP SACK
In-Reply-To: <7efa8a7d0907210207m327a1252nee4a04f5e4ea7a@mail.gmail.com>
References: <7efa8a7d0907210207m327a1252nee4a04f5e4ea7a@mail.gmail.com>
Message-ID: <4A66D799.5050307@freebsd.org>

Learner Study wrote:
> Hello experts:
> 
> Is there is reason why freebsd TCP implementation limits the number of SACK
> blocks on receiver side to MAX_SACK_BLOCKS whereas the sender side SACK
> holes are implemented as a linked list?
> 
> Any issues if someone decides to use receiver side linked list as well
> (instead of fixed sized array)?

I'm not intimately familiar with the SACK code, so with that disclaimer 
in hand...

For starters, there is a limit imposed by the TCP option space on the 
number of SACK blocks you can squeeze into a single TCP header (max 4, 
typically fewer when other common options are in use). MAX_SACK_BLKS is 
defined as 6, so we actually are able to store an extra 2 blocks 
receiver side than we can send in any given ACK.

Given that constraint, I see no reason to store more blocks at the 
receiver. As holes get filled, we recompute the sack blocks anyway so I 
don't think (conceptually at least) we're losing any important 
information. I am aware though that the implementation is sub-optimal in 
other areas (a few of which I'm trying to fix).

That said, I see no issues with switching to a linked list. You'd need 
to do some replumbing around the place and you will increase memory 
consumption for I suspect will be no real gain.

If you decide to proceed and can measure improvements as a result of 
your changes, I'd be interested to look at your patch(es). I just 
suspect it will be a relatively fruitless endeavor.

Cheers,
Lawrence
From raffaele.delorenzo at libero.it  Wed Jul 22 10:00:32 2009
From: raffaele.delorenzo at libero.it (raffaele.delorenzo@libero.it)
Date: Wed Jul 22 10:00:45 2009
Subject: R: IPv6 and ipfw
Message-ID: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost>

Hi all,
You has found a parser bug.
When the protocol is "ipv6" and you are a 
comma separated ipv6 addresses, the parser work fine because the "add_srcip6" 
function is called and recognize all addresses.
When the protocol is "!=ipv6" 
(like TCP,UDP,ICMP6)  the "add_src" fuction is called and it cause troubles 
because the "inet_pton()" fails and erroneously is called the "add_srcip" 
function (see the code below).

(from "ipfw2.c")
 add_src(ipfw_insn *cmd, char 
*av, u_char proto)
{
	struct in6_addr a;
	char *host, *ch;
	ipfw_insn *ret = 
NULL;

	if ((host = strdup(av)) == NULL)
		return NULL;
	if ((ch = strrchr
(host, '/')) != NULL)
		*ch = '\0';

	if (proto == IPPROTO_IPV6  || strcmp(av, 
"me6") == 0 ||
	    inet_pton(AF_INET6, host, &a))
		ret = add_srcip6(cmd, av);

	/* XXX: should check for IPv4, not !IPv6 */
	if (ret == NULL && (proto == 
IPPROTO_IP || strcmp(av, "me") == 0 ||
	    !inet_pton(AF_INET6, host, &a)))
		
ret = add_srcip(cmd, av);
	if (ret == NULL && strcmp(av, "any") != 0)
		ret = 
cmd;

	free(host);
	return ret;
}

I think that possibles solutions are the 
follows:

1) Create a new protocols types UPD6,TCP6 only for IPv6 rules to 
avoid parser confusions, and check about this protocol inside the "add_src" 
fuction (easy to implement).
2) Check the comma separated ip/ipv6 addresses 
inside the "add_src" function (a little too hard to implement).

I appreciate 
suggestions from the community experts about this problem.

Ciao

Raffaele


>----Messaggio originale----
>Da: wjw@digiware.nl
>Data: 22/07/2009 10.20
>A: 
<net@freebsd.org>
>Ogg: IPv6 and ipfw
>
>Hi,
>
>Running 7.2 I tried to insert 
this into my IPFW rules
>
># ipfw add allow udp from any to 2001:xxx:3::
113,2001:xxxx:3::116 \
>	dst-port 10001-10100 keep-state
>ipfw: bad netmask 
``xxxx:3::113''
>
>also:
># ipfw add allow udp from any to trixbox.ip6 dst-port 
10001-10100 keep-state
>ipfw: hostname ``trixbox.ip6'' unknown
>Exit 68
># host 
trixbox.ip6
>trixbox.ip6.digiware.nl has IPv6 address 2001:4cb8:3::116
>
>So it 
looks like what is in the manual is overly optimistic:
>----
>      addr6-list: 
ip6-addr[,addr6-list]
>
>      ip6-addr:
>              A host or subnet 
specified one of the following ways:
>
>              numeric-ip | hostname

>                      Matches a single IPv6 address as allowed by inet_pton(3)

>                      or a hostname.  Hostnames are resolved at the time the

>                      rule is added to the firewall list.
>
>              
addr/masklen
>                      Matches all IPv6 addresses with base addr 
(specified as
>                      allowed by inet_pton or a hostname) and 
mask width of
>                      masklen bits.
>
>              No support 
for sets of IPv6 addresses is provided because IPv6
>              addresses 
are typically random past the initial prefix.
>----
>
>Anybody else ran into 
this?
>Or should I file this as a PR.
>
>--WjW

>_______________________________________________
>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"
>


From auryn at zirakzigil.org  Wed Jul 22 10:17:20 2009
From: auryn at zirakzigil.org (Giulio Ferro)
Date: Wed Jul 22 10:17:28 2009
Subject: multicast and multiple nics
Message-ID: <4A66E39A.8000201@zirakzigil.org>

This is something that's really been puzzling me lately...

Freebsd 8 beta amd64 recently updated

The box has 2 nics:
(internet inteface)
em0 : 192.168.1.1, netmask 255.255.255.0

(lan interface)
re0 : 192.168.2.1 netmask 255.255.255.0 (lan interface)
        192.168.2.2 netmask 255.255.255.255 (alias 0)
        192.168.2.3 netmask 255.255.255.255 (alias 1)

I want to run ushare (/usr/ports/ushare). This program sends
multicast packets to multicast address 239.255.255.250

The packets should go to the lan, so I add the route:
route add 224/4 -iface re0

In order to do the test I switch off the firewall (/etc/rc.d/pf stop)

I start the service, but no packets can be seen leaving the interface re0
with tcpdump.

Even If I ping a multicast address directly I can see no packets at all:

ping -I 192.168.2.1 239.255.255.250

I can't really understand why this doesn't work. I've also tried to enable
multicast routing (mrouted), just defining the interfaces I want to use
in /etc/mrouted.conf, but no luck. I'm not even sure if mrouted should be
needed in this setup, anyway...

Can someone point me what I'm doing wrong?

Thanks.

From iprebeg at freebsd.org  Wed Jul 22 10:47:48 2009
From: iprebeg at freebsd.org (iprebeg@freebsd.org)
Date: Wed Jul 22 10:47:54 2009
Subject: multicast and multiple nics
In-Reply-To: <4A66E39A.8000201@zirakzigil.org>
References: <4A66E39A.8000201@zirakzigil.org>
Message-ID: <20090722104059.GA682@valeria.zesoi.fer.hr>

On Wed, Jul 22, 2009 at 12:02:02PM +0200, Giulio Ferro wrote:
> This is something that's really been puzzling me lately...
>
> Freebsd 8 beta amd64 recently updated
>
> The box has 2 nics:
> (internet inteface)
> em0 : 192.168.1.1, netmask 255.255.255.0
>
> (lan interface)
> re0 : 192.168.2.1 netmask 255.255.255.0 (lan interface)
>        192.168.2.2 netmask 255.255.255.255 (alias 0)
>        192.168.2.3 netmask 255.255.255.255 (alias 1)
>
> I want to run ushare (/usr/ports/ushare). This program sends
> multicast packets to multicast address 239.255.255.250
>
> The packets should go to the lan, so I add the route:
> route add 224/4 -iface re0
>
> In order to do the test I switch off the firewall (/etc/rc.d/pf stop)
>
> I start the service, but no packets can be seen leaving the interface re0
> with tcpdump.

Can you try to sniff with other machine in that lan?

>
> Even If I ping a multicast address directly I can see no packets at all:
>
> ping -I 192.168.2.1 239.255.255.250

Please, try to use mcastread like this

mcastread -v4 -s 192.168.2.1 re0 239.255.255.250 1337

or mcastsend like this

mcastsend -i re0 239.255.255.250 1337

to check is there any mcast traffic. ( IGMP packets generated by
mcastread are mcasted to 224.0.0.22 ). 

There is also quite a bug already mentioned here. Something is
preventing proper setting of destionation MAC. It is seen as DMAC stays
unicast-like.

>
> I can't really understand why this doesn't work. I've also tried to enable
> multicast routing (mrouted), just defining the interfaces I want to use
> in /etc/mrouted.conf, but no luck. I'm not even sure if mrouted should be
> needed in this setup, anyway...

You don't need mrouted, AFAIK. It is needed only when you want deploy
mcast session in WAN.

>
> Can someone point me what I'm doing wrong?
>
> Thanks.
>
> _______________________________________________
> 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"
From fb-net at psconsult.nl  Wed Jul 22 12:03:12 2009
From: fb-net at psconsult.nl (Paul Schenkeveld)
Date: Wed Jul 22 12:03:25 2009
Subject: Bridging wlan to gif?
Message-ID: <20090722113956.GA1870@psconsult.nl>

Hi,

I'm trying to bridge a wlan interface to a gif tunnel on 8.0-BETA2.
Running tcpdump on wlan0 I see DHCP packets coming in as IP packets,
on gif0 however tcpdump shows ethernet headers prepended.  Needless
to say things do not work as expected.

What I try to accomplish is the following:

  +------+      +--------------+     +-------+
  |      | .... |ath0      bge0|-----|Router |     Gateway
  |      |      |wlan0     gif0|     +-------+    +----------+
  |      |      | \       /    |         |        |  gif0    |
  |      |      |  bridge0     |      Internet    |    \     |
  |      |      |              |         |        |  bridge0 |
  +------+      +--------------+     +-------+    |       \  |
    Wifi          Access point       |Router |----|fxp0  fxp1|---- LAN X
   client          8.0-BETA2         +-------+    +----------+

 - The Wifi client must be part of LAN X and receive a DHCP address from
   a DHCP server (not shown) on LAN X
 - On the access point wlan0 and gif0 are bridged together
 - On the gateway fxp1 and gif0 are bridged together
 - Gif0 on the access point and gif0 on the gateway communicate correctly
   when given IP addresses

Regards,

Paul Schenkeveld
From wjw at digiware.nl  Wed Jul 22 15:11:00 2009
From: wjw at digiware.nl (Willem Jan Withagen)
Date: Wed Jul 22 15:11:07 2009
Subject: R: IPv6 and ipfw
In-Reply-To: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost>
References: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost>
Message-ID: <4A672C79.3000006@digiware.nl>

Reply below, and an also reorganised the yours...
raffaele.delorenzo@libero.it wrote:
>> Hi,
>>
>> Running 7.2 I tried to insert 
> this into my IPFW rules
>> # ipfw add allow udp from any to 2001:xxx:3::
> 113,2001:xxxx:3::116 \
>> 	dst-port 10001-10100 keep-state
>> ipfw: bad netmask 
> ``xxxx:3::113''
>> also:
>> # ipfw add allow udp from any to trixbox.ip6 dst-port 
> 10001-10100 keep-state
>> ipfw: hostname ``trixbox.ip6'' unknown
>> Exit 68
>> # host 
> trixbox.ip6
>> trixbox.ip6.digiware.nl has IPv6 address 2001:4cb8:3::116
>>
>> So it 
> looks like what is in the manual is overly optimistic:
>> ----
>>      addr6-list: 
> ip6-addr[,addr6-list]
>>      ip6-addr:
>>              A host or subnet 
> specified one of the following ways:
>>              numeric-ip | hostname
> 
>>                      Matches a single IPv6 address as allowed by inet_pton(3)
> 
>>                      or a hostname.  Hostnames are resolved at the time the
> 
>>                      rule is added to the firewall list.
>>
>>              
> addr/masklen
>>                      Matches all IPv6 addresses with base addr 
> (specified as
>>                      allowed by inet_pton or a hostname) and 
> mask width of
>>                      masklen bits.
>>
>>              No support 
> for sets of IPv6 addresses is provided because IPv6
>>              addresses 
> are typically random past the initial prefix.
>> ----
>>
>> Anybody else ran into 
> this?
>> Or should I file this as a PR.

 > Hi all,
 > You has found a parser bug.
 > When the protocol is "ipv6" and you are a
 > comma separated ipv6 addresses, the parser work fine because the 
"add_srcip6"
 > function is called and recognize all addresses.
 > When the protocol is "!=ipv6"
 > (like TCP,UDP,ICMP6)  the "add_src" fuction is called and it cause troubles
 > because the "inet_pton()" fails and erroneously is called the "add_srcip"
 > function (see the code below).
 >
 > (from "ipfw2.c")
 >  add_src(ipfw_insn *cmd, char
 > *av, u_char proto)
 > {
 > 	struct in6_addr a;
 > 	char *host, *ch;
 > 	ipfw_insn *ret =
 > NULL;
 >
 > 	if ((host = strdup(av)) == NULL)
 > 		return NULL;
 > 	if ((ch = strrchr
 > (host, '/')) != NULL)
 > 		*ch = '\0';
 >
 > 	if (proto == IPPROTO_IPV6  || strcmp(av,
 > "me6") == 0 ||
 > 	    inet_pton(AF_INET6, host, &a))
 > 		ret = add_srcip6(cmd, av);
 >
 > 	/* XXX: should check for IPv4, not !IPv6 */
 > 	if (ret == NULL && (proto ==
 > IPPROTO_IP || strcmp(av, "me") == 0 ||
 > 	    !inet_pton(AF_INET6, host, &a)))
 > 		
 > ret = add_srcip(cmd, av);
 > 	if (ret == NULL && strcmp(av, "any") != 0)
 > 		ret =
 > cmd;
 >
 > 	free(host);
 > 	return ret;
 > }
 >
 > I think that possibles solutions are the
 > follows:
 >
 > 1) Create a new protocols types UPD6,TCP6 only for IPv6 rules to
 > avoid parser confusions, and check about this protocol inside the "add_src"
 > fuction (easy to implement).
 > 2) Check the comma separated ip/ipv6 addresses
 > inside the "add_src" function (a little too hard to implement).
 >
 > I appreciate
 > suggestions from the community experts about this problem.

I would prefer not to make seperate tcp6 and udp6 items, since what i would 
like to do is things like:

hostlist="a.b.c.d,A:B:C:D::F"

and then in the firewall something like
	ipfw add allow tcp from any to ${hostlist} dst-port 80 setup

and if tcp now goes into tcp and tcp6 I need to double my rules etc.

Which raises one other point:
	using a FQDN with more A and AAAA records also just inserts the
	first reply in the list.
	Now I don't use FQDN since most of the time in the Firewall DNS
	is not quite up yet.

--WjW
From julian at elischer.org  Wed Jul 22 16:33:57 2009
From: julian at elischer.org (Julian Elischer)
Date: Wed Jul 22 16:34:03 2009
Subject: Bridging wlan to gif?
In-Reply-To: <20090722113956.GA1870@psconsult.nl>
References: <20090722113956.GA1870@psconsult.nl>
Message-ID: <4A673F75.8070003@elischer.org>

Paul Schenkeveld wrote:
> Hi,
> 
> I'm trying to bridge a wlan interface to a gif tunnel on 8.0-BETA2.
> Running tcpdump on wlan0 I see DHCP packets coming in as IP packets,
> on gif0 however tcpdump shows ethernet headers prepended.  Needless
> to say things do not work as expected.
> 
> What I try to accomplish is the following:
> 
>   +------+      +--------------+     +-------+
>   |      | .... |ath0      bge0|-----|Router |     Gateway
>   |      |      |wlan0     gif0|     +-------+    +----------+
>   |      |      | \       /    |         |        |  gif0    |
>   |      |      |  bridge0     |      Internet    |    \     |
>   |      |      |              |         |        |  bridge0 |
>   +------+      +--------------+     +-------+    |       \  |
>     Wifi          Access point       |Router |----|fxp0  fxp1|---- LAN X
>    client          8.0-BETA2         +-------+    +----------+
> 

nice diagram....

you can't bridge gif as it doesn't have a MAC header
if yo want to bridge the wifi net and LAN X then tha tis another 
matter and you can probably do that., but you are goin gto have to use 
a different way to do it..


Might I suggest a netgraph bridge, where the tunnel is implemented as 
a tcp or UDP socket layer (optionally with ipsec).

use a netgraph bridge node on each side, and connect them
using ksocket nodes which are linked to each other.

you might also find that you can use mpd as a good link between them.

I've done this in the past but do not have working examples in
front of me.





>  - The Wifi client must be part of LAN X and receive a DHCP address from
>    a DHCP server (not shown) on LAN X
>  - On the access point wlan0 and gif0 are bridged together
>  - On the gateway fxp1 and gif0 are bridged together
>  - Gif0 on the access point and gif0 on the gateway communicate correctly
>    when given IP addresses
> 
> Regards,
> 
> Paul Schenkeveld
> _______________________________________________
> 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"

From gavin at FreeBSD.org  Wed Jul 22 18:47:57 2009
From: gavin at FreeBSD.org (gavin@FreeBSD.org)
Date: Wed Jul 22 18:48:04 2009
Subject: bin/136994: [patch] ifconfig(8) print carp mac address
Message-ID: <200907221847.n6MIlut9027728@freefall.freebsd.org>

Old Synopsis: [patch] ifconfig: print carp mac address
New Synopsis: [patch] ifconfig(8) print carp mac address

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Wed Jul 22 18:45:25 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s)

http://www.freebsd.org/cgi/query-pr.cgi?pr=136994
From fazaeli at sepehrs.com  Wed Jul 22 22:35:02 2009
From: fazaeli at sepehrs.com (H.Fazaeli)
Date: Wed Jul 22 22:35:16 2009
Subject: broadcom 57710 support
In-Reply-To: <20090720050153.GP1166@FreeBSD.org>
References: <4A62D7DD.3040701@sepehrs.com> <20090720050153.GP1166@FreeBSD.org>
Message-ID: <4A656239.2090803@sepehrs.com>


Wojciech A. Koszek wrote:
> On Sun, Jul 19, 2009 at 12:52:53PM +0430, H.Fazaeli wrote:
>   
>> Is there any near plan to develop drivers for
>> network cards based on broadcom NetXtereme II 57710
>> 10 GbE controller?
>>     
>
> Do you plan to help somehow with driver development?
>
>   
No. I just plan to use them on IBM blade servers.
> In order to develop this driver someone would probably have an
> easy access to those cards. Are they packaged in PCIe format as
> well, or they only have the blade version?
>
> Thanks,
>   
Both blade and usual PC form factors are available.
See http://www.redbooks.ibm.com/technotes/tips0688.pdf
and
http://www.broadcom.com/products/Enterprise-Networking/10-Gigabit-Ethernet-Controllers/BCM57710


-- 

Best regards.
Hooman Fazaeli




From fazaeli at sepehrs.com  Wed Jul 22 22:35:04 2009
From: fazaeli at sepehrs.com (H.Fazaeli)
Date: Wed Jul 22 22:35:16 2009
Subject: broadcom 57710 support
In-Reply-To: <50667.57004.qm@web63901.mail.re1.yahoo.com>
References: <50667.57004.qm@web63901.mail.re1.yahoo.com>
Message-ID: <4A6560BE.9090608@sepehrs.com>


Nothing actually special. They are one of few 10GbE expansion cards 
supported on IBM blade servers.
See http://www.redbooks.ibm.com/technotes/tips0688.pdf


Barney Cordoba wrote:
>
> --- On Sun, 7/19/09, Hooman Fazaeli <ebastan10@yahoo.com> wrote:
>
>   
>> From: Hooman Fazaeli <ebastan10@yahoo.com>
>> Subject: broadcom 57710 support
>> To: freebsd-net@freebsd.org
>> Date: Sunday, July 19, 2009, 5:08 AM
>>
>> Any one knows if there is any near plan to develop drivers
>> for
>>
>> network cards based on broadcom NetXtereme II 57710
>>
>> 10 GbE controller?
>>
>> -----------------------
>> best regards
>> Hooman Fazaeli
>>     
>
> Ok, I'll bite. What is so special about this particular part that you 
> simply must use it in your 10GbE server?
>
> Barney
>
>
>       
> _______________________________________________
> 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"
>
>   

-- 

Best regards.
Hooman Fazaeli




From qing.li at bluecoat.com  Thu Jul 23 01:03:18 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Thu Jul 23 01:03:31 2009
Subject: 8.0-BETA1 - for the record - different paths followed by IPv4
	and IPv6 for 'local' connections
In-Reply-To: <4A6469CE.4060907@restart.be>
References: <4A5734C3.3000806@restart.be>	<B583FBF374231F4A89607B4D08578A4304673660@bcs-mail03.internal.cacheflow.com>	<4A5864DC.1070106@restart.be>
	<B583FBF374231F4A89607B4D08578A4304673665@bcs-mail03.internal.cacheflow.com>
	<4A6469CE.4060907@restart.be>
Message-ID: <B583FBF374231F4A89607B4D08578A4304CDAAEC@bcs-mail03.internal.cacheflow.com>


> >
> Just another case where the route must be created:
> 

That's probably because I explicitly disabled such
route installation for PPP link type.

Please apply patch http://people.freebsd.org/~qingli/patch and
let me know if that solves your problem.

Thanks,

-- Qing



> [root@avoriaz ~]# ifconfig gif0
> gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
> 	tunnel inet 212.239.166.57 --> 94.23.44.41
> 	inet6 fe80::21d:60ff:fead:2ace%gif0 prefixlen 64 scopeid 0x4
> 	inet6 2001:41d0:2:2d29:1:ffff:: --> 2001:41d0:2:2d29:0:ffff::
> prefixlen
> 128
> 	options=1<ACCEPT_REV_ETHIP_VER>
> 
> [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff::
> PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: -->
> 2001:41d0:2:2d29:1:ffff::
> ^C
> --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics ---
> 4 packets transmitted, 0 packets received, 100.0% packet loss
> 
> [root@avoriaz ~]# route add -inet6 2001:41d0:2:2d29:1:ffff::
-interface
> lo0
> add host 2001:41d0:2:2d29:1:ffff::: gateway lo0
> 
> [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff::
> PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: -->
> 2001:41d0:2:2d29:1:ffff::
> 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.531 ms
> 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.884 ms
> 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.748 ms
> ^C
> --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 0.531/0.721/0.884/0.145 ms
> 
> Thanks
> 
> Henri
> >
> > -----Original Message-----
> > From: Henri Hennebert [mailto:hlh@restart.be]
> > Sent: Sat 7/11/2009 3:09 AM
> > To: Li, Qing
> > Cc: freebsd-stable@freebsd.org; freebsd-net@freebsd.org
> > Subject: Re: 8.0-BETA1 - for the record - different paths followed
by
> IPv4 and IPv6 for 'local' connections
> >
> > Li, Qing wrote:
> >> Hi,
> >>
> >> Please try patch-7-10 in my home directory
> http://people.freebsd.org/~qingli/
> >> and let me know how it works out for you. I thought I had committed
> the patch
> >> but turned out I didn't.
> >
> > I apply the patch, reset my pf.conf to its previous content and all
> is
> > running smoothly. By the way, I discover after my post that my
> > "solution" was not working for long (many bytes) connections and
this
> is
> > solved too.
> >
> > Many thank for your time
> >
> > Henri
> >
> > PS please commit as soon as possible
> >
> >>> On 8.0-BETA1 there is an assymetry:
> >>>
> >>> netstat -rn display
> >>>
> >>> 192.168.24.1       link#3
> >>> ....
> >>> no entry for 2001:41d0:2:2d29:1:1::
> >>>
> >> This is by design as part of the new architecture in 8.0, which
> maintains
> >> the L2 ARP/ND6 and L3 routing tables separately.
> >>
> >> -- Qing
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert
> >> Sent: Fri 7/10/2009 5:32 AM
> >> To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org
> >> Subject: 8.0-BETA1 - for the record - different paths followed by
> IPv4 and IPv6 for 'local' connections
> >>
> >> Hello,
> >>
> >> After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem
> when
> >> connecting with firefox to a local apache server using the global
> >> unicast IPv6 address of the local machine. pf.conf must be updated!
> >>
> >> My configuration:
> >>
> >> [root@avoriaz ~]# ifconfig em0
> >>
> >> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
mtu
> 1500
> >>
>
options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO
> 4>
> >> 	ether 00:1d:60:ad:2a:ce
> >> 	inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255
> >> 	inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1
> >> 	inet6 2001:41d0:2:2d29:1:1:: prefixlen 80
> >> 	media: Ethernet 100baseTX (100baseTX <half-duplex>)
> >> 	status: active
> >>
> >> [root@avoriaz ~]# host www.restart.bel
> >> www.restart.bel is an alias for avoriaz.restart.bel.
> >> avoriaz.restart.bel has address 192.168.24.1
> >> avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1::
> >>
> >> pf.conf:
> >>
> >> int_if="em0"
> >> block in  log all
> >> block out log all
> >> set skip on lo0
> >> antispoof quick for $int_if inet
> >> # Allow trafic with physical internal network
> >> pass in quick on $int_if from ($int_if:network) to ($int_if) keep
> state
> >> pass out quick on $int_if from ($int_if) to ($int_if:network) keep
> state
> >>
> >> The problem:
> >>
> >> [root@avoriaz ~]# telnet -4 www.restart.bel 80
> >> Trying 192.168.24.1...
> >> Connected to avoriaz.restart.bel.
> >> Escape character is '^]'.
> >> ^]
> >> telnet> quit
> >> Connection closed.
> >> [root@avoriaz ~]# telnet -6 www.restart.bel 80
> >> Trying 2001:41d0:2:2d29:1:1::...
> >> --->Never connect and get a timeout!
> >>
> >> tcpdump and logging in pf show me that
> >>
> >> For a IPv4 connection:
> >> the packet from telnet to apache pass 2 times on lo0 (out and in)
> >> the answer packet from apache to telnet pass 2 times on lo0 (out
and
> in)
> >>
> >> So no problem, there is `set skip on lo0'
> >>
> >> For a IPv6 connection:
> >> The first packet from telnet to apache pass 2 times on lo0 (out and
> in)
> >> The answer packet from apache to telnet path on em0  and is
rejected
> >> due to the default flags S/SA.
> >>
> >> So I have to change pf.conf and replace the last line:
> >> pass out quick on $int_if from ($int_if) to ($int_if:network) \
> >> keep state flags any
> >>
> >> Then all is OK
> >>
> >> By the way, on 7.2
> >>
> >> netstat -rn display
> >>
> >> 192.168.24.1        00:1d:60:ad:2a:ce
> >> ....
> >> 2001:41d0:2:2d29:1:1::            00:1d:60:ad:2a:ce
> >>
> >>
> >> On 8.0-BETA1 there is an assymetry:
> >>
> >> netstat -rn display
> >>
> >> 192.168.24.1       link#3
> >> ....
> >> no entry for 2001:41d0:2:2d29:1:1::
> >>
> >> Hope it may help someone
> >>
> >> Henri
> >>
> >> _______________________________________________
> >> freebsd-stable@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to "freebsd-stable-
> unsubscribe@freebsd.org"
> >>
> >
> >
> > _______________________________________________
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-
> unsubscribe@freebsd.org"

From hlh at restart.be  Thu Jul 23 10:01:17 2009
From: hlh at restart.be (Henri Hennebert)
Date: Thu Jul 23 10:01:35 2009
Subject: [SOLVED] 8.0-BETA1 - for the record - different paths followed by
 IPv4 and IPv6 for 'local' connections
In-Reply-To: <B583FBF374231F4A89607B4D08578A4304CDAAEC@bcs-mail03.internal.cacheflow.com>
References: <4A5734C3.3000806@restart.be>	<B583FBF374231F4A89607B4D08578A4304673660@bcs-mail03.internal.cacheflow.com>	<4A5864DC.1070106@restart.be>
	<B583FBF374231F4A89607B4D08578A4304673665@bcs-mail03.internal.cacheflow.com>
	<4A6469CE.4060907@restart.be>
	<B583FBF374231F4A89607B4D08578A4304CDAAEC@bcs-mail03.internal.cacheflow.com>
Message-ID: <4A6834E7.60704@restart.be>

Li, Qing wrote:
>> Just another case where the route must be created:
>>
> 
> That's probably because I explicitly disabled such
> route installation for PPP link type.
> 
> Please apply patch http://people.freebsd.org/~qingli/patch and
> let me know if that solves your problem.

The problem is solved.

Thanks a lot.

Henri

PS. the ipv4 ping was working fine before (and after) your patch, so
I don't see why you have to patch in.c
> 
> Thanks,
> 
> -- Qing
> 
> 
> 
>> [root@avoriaz ~]# ifconfig gif0
>> gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
>> 	tunnel inet 212.239.166.57 --> 94.23.44.41
>> 	inet6 fe80::21d:60ff:fead:2ace%gif0 prefixlen 64 scopeid 0x4
>> 	inet6 2001:41d0:2:2d29:1:ffff:: --> 2001:41d0:2:2d29:0:ffff::
>> prefixlen
>> 128
>> 	options=1<ACCEPT_REV_ETHIP_VER>
>>
>> [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff::
>> PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: -->
>> 2001:41d0:2:2d29:1:ffff::
>> ^C
>> --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics ---
>> 4 packets transmitted, 0 packets received, 100.0% packet loss
>>
>> [root@avoriaz ~]# route add -inet6 2001:41d0:2:2d29:1:ffff::
> -interface
>> lo0
>> add host 2001:41d0:2:2d29:1:ffff::: gateway lo0
>>
>> [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff::
>> PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: -->
>> 2001:41d0:2:2d29:1:ffff::
>> 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.531 ms
>> 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.884 ms
>> 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.748 ms
>> ^C
>> --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 0.531/0.721/0.884/0.145 ms
>>
>> Thanks
>>
>> Henri
>>> -----Original Message-----
>>> From: Henri Hennebert [mailto:hlh@restart.be]
>>> Sent: Sat 7/11/2009 3:09 AM
>>> To: Li, Qing
>>> Cc: freebsd-stable@freebsd.org; freebsd-net@freebsd.org
>>> Subject: Re: 8.0-BETA1 - for the record - different paths followed
> by
>> IPv4 and IPv6 for 'local' connections
>>> Li, Qing wrote:
>>>> Hi,
>>>>
>>>> Please try patch-7-10 in my home directory
>> http://people.freebsd.org/~qingli/
>>>> and let me know how it works out for you. I thought I had committed
>> the patch
>>>> but turned out I didn't.
>>> I apply the patch, reset my pf.conf to its previous content and all
>> is
>>> running smoothly. By the way, I discover after my post that my
>>> "solution" was not working for long (many bytes) connections and
> this
>> is
>>> solved too.
>>>
>>> Many thank for your time
>>>
>>> Henri
>>>
>>> PS please commit as soon as possible
>>>
>>>>> On 8.0-BETA1 there is an assymetry:
>>>>>
>>>>> netstat -rn display
>>>>>
>>>>> 192.168.24.1       link#3
>>>>> ....
>>>>> no entry for 2001:41d0:2:2d29:1:1::
>>>>>
>>>> This is by design as part of the new architecture in 8.0, which
>> maintains
>>>> the L2 ARP/ND6 and L3 routing tables separately.
>>>>
>>>> -- Qing
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert
>>>> Sent: Fri 7/10/2009 5:32 AM
>>>> To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org
>>>> Subject: 8.0-BETA1 - for the record - different paths followed by
>> IPv4 and IPv6 for 'local' connections
>>>> Hello,
>>>>
>>>> After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem
>> when
>>>> connecting with firefox to a local apache server using the global
>>>> unicast IPv6 address of the local machine. pf.conf must be updated!
>>>>
>>>> My configuration:
>>>>
>>>> [root@avoriaz ~]# ifconfig em0
>>>>
>>>> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
> mtu
>> 1500
> options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO
>> 4>
>>>> 	ether 00:1d:60:ad:2a:ce
>>>> 	inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255
>>>> 	inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1
>>>> 	inet6 2001:41d0:2:2d29:1:1:: prefixlen 80
>>>> 	media: Ethernet 100baseTX (100baseTX <half-duplex>)
>>>> 	status: active
>>>>
>>>> [root@avoriaz ~]# host www.restart.bel
>>>> www.restart.bel is an alias for avoriaz.restart.bel.
>>>> avoriaz.restart.bel has address 192.168.24.1
>>>> avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1::
>>>>
>>>> pf.conf:
>>>>
>>>> int_if="em0"
>>>> block in  log all
>>>> block out log all
>>>> set skip on lo0
>>>> antispoof quick for $int_if inet
>>>> # Allow trafic with physical internal network
>>>> pass in quick on $int_if from ($int_if:network) to ($int_if) keep
>> state
>>>> pass out quick on $int_if from ($int_if) to ($int_if:network) keep
>> state
>>>> The problem:
>>>>
>>>> [root@avoriaz ~]# telnet -4 www.restart.bel 80
>>>> Trying 192.168.24.1...
>>>> Connected to avoriaz.restart.bel.
>>>> Escape character is '^]'.
>>>> ^]
>>>> telnet> quit
>>>> Connection closed.
>>>> [root@avoriaz ~]# telnet -6 www.restart.bel 80
>>>> Trying 2001:41d0:2:2d29:1:1::...
>>>> --->Never connect and get a timeout!
>>>>
>>>> tcpdump and logging in pf show me that
>>>>
>>>> For a IPv4 connection:
>>>> the packet from telnet to apache pass 2 times on lo0 (out and in)
>>>> the answer packet from apache to telnet pass 2 times on lo0 (out
> and
>> in)
>>>> So no problem, there is `set skip on lo0'
>>>>
>>>> For a IPv6 connection:
>>>> The first packet from telnet to apache pass 2 times on lo0 (out and
>> in)
>>>> The answer packet from apache to telnet path on em0  and is
> rejected
>>>> due to the default flags S/SA.
>>>>
>>>> So I have to change pf.conf and replace the last line:
>>>> pass out quick on $int_if from ($int_if) to ($int_if:network) \
>>>> keep state flags any
>>>>
>>>> Then all is OK
>>>>
>>>> By the way, on 7.2
>>>>
>>>> netstat -rn display
>>>>
>>>> 192.168.24.1        00:1d:60:ad:2a:ce
>>>> ....
>>>> 2001:41d0:2:2d29:1:1::            00:1d:60:ad:2a:ce
>>>>
>>>>
>>>> On 8.0-BETA1 there is an assymetry:
>>>>
>>>> netstat -rn display
>>>>
>>>> 192.168.24.1       link#3
>>>> ....
>>>> no entry for 2001:41d0:2:2d29:1:1::
>>>>
>>>> Hope it may help someone
>>>>
>>>> Henri
>>>>
>>>> _______________________________________________
>>>> freebsd-stable@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>>> To unsubscribe, send any mail to "freebsd-stable-
>> unsubscribe@freebsd.org"
>>>
>>> _______________________________________________
>>> freebsd-stable@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to "freebsd-stable-
>> unsubscribe@freebsd.org"
> 

From auryn at zirakzigil.org  Thu Jul 23 10:47:13 2009
From: auryn at zirakzigil.org (Giulio Ferro)
Date: Thu Jul 23 10:47:20 2009
Subject: multicast and multiple nics
In-Reply-To: <20090722104059.GA682@valeria.zesoi.fer.hr>
References: <4A66E39A.8000201@zirakzigil.org>
	<20090722104059.GA682@valeria.zesoi.fer.hr>
Message-ID: <4A683FA5.3000406@zirakzigil.org>

Thanks for the reply.

iprebeg@freebsd.org wrote:
>> I want to run ushare (/usr/ports/ushare). This program sends
>> multicast packets to multicast address 239.255.255.250
>>
>> The packets should go to the lan, so I add the route:
>> route add 224/4 -iface re0
>>
>> In order to do the test I switch off the firewall (/etc/rc.d/pf stop)
>>
>> I start the service, but no packets can be seen leaving the interface re0
>> with tcpdump.
>>     
>
> Can you try to sniff with other machine in that lan?
>   

Yes. Other machines can multicast without problem but nothing
multicast shows originating from the freebsd box.
>   
>> Even If I ping a multicast address directly I can see no packets at all:
>>
>> ping -I 192.168.2.1 239.255.255.250
>>     
I forgot mentioning that I can run this command from my linux box
and tcpdump from the same machine show the packets going to and fro.

>
> Please, try to use mcastread like this
>
> mcastread -v4 -s 192.168.2.1 re0 239.255.255.250 1337
>   
mcastread -v4 -s 192.168.2.1 re0 239.255.255.250 1337
mcastread: trying 239.255.255.250
mcastread: using (S,G)=(192.168.2.1,239.255.255.250)

And stays there..

> or mcastsend like this
>
> mcastsend -i re0 239.255.255.250 1337
>   
This results in an error:
mcastsend: setsockopt(IP_MULTICAST_IF): Can't assign requested address


Is there something else I can try?

Thanks again...

From iprebeg at freebsd.org  Thu Jul 23 13:07:41 2009
From: iprebeg at freebsd.org (iprebeg@freebsd.org)
Date: Thu Jul 23 13:07:47 2009
Subject: multicast and multiple nics
In-Reply-To: <4A683FA5.3000406@zirakzigil.org>
References: <4A66E39A.8000201@zirakzigil.org>
	<20090722104059.GA682@valeria.zesoi.fer.hr>
	<4A683FA5.3000406@zirakzigil.org>
Message-ID: <20090723130103.GA2938@valeria.zesoi.fer.hr>

On Thu, Jul 23, 2009 at 12:47:01PM +0200, Giulio Ferro wrote:
> Thanks for the reply.
>
> iprebeg@freebsd.org wrote:
>>> I want to run ushare (/usr/ports/ushare). This program sends
>>> multicast packets to multicast address 239.255.255.250
>>>
>>> The packets should go to the lan, so I add the route:
>>> route add 224/4 -iface re0
>>>
>>> In order to do the test I switch off the firewall (/etc/rc.d/pf stop)
>>>
>>> I start the service, but no packets can be seen leaving the interface re0
>>> with tcpdump.
>>>     
>>
>> Can you try to sniff with other machine in that lan?
>>   
>
> Yes. Other machines can multicast without problem but nothing
> multicast shows originating from the freebsd box.
>>   
>>> Even If I ping a multicast address directly I can see no packets at all:
>>>
>>> ping -I 192.168.2.1 239.255.255.250
>>>     
> I forgot mentioning that I can run this command from my linux box
> and tcpdump from the same machine show the packets going to and fro.
>
>>
>> Please, try to use mcastread like this
>>
>> mcastread -v4 -s 192.168.2.1 re0 239.255.255.250 1337
>>   
> mcastread -v4 -s 192.168.2.1 re0 239.255.255.250 1337
> mcastread: trying 239.255.255.250
> mcastread: using (S,G)=(192.168.2.1,239.255.255.250)
>
> And stays there..

It is ok for mcastread to stay like this, but in normal situation, 
you should see two IGMPv3 reports leaving re0. Maybe it is related 
to re driver. Can you try the same on adapter that uses different
driver?

>
>> or mcastsend like this
>>
>> mcastsend -i re0 239.255.255.250 1337
>>   
> This results in an error:
> mcastsend: setsockopt(IP_MULTICAST_IF): Can't assign requested address
>
>

You can use it without "-i re0" part and maybe experiment with and
without routes.

> Is there something else I can try?
>
> Thanks again...

You're most welcome.

>
> _______________________________________________
> 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"
From lucian at lastdot.org  Thu Jul 23 15:27:51 2009
From: lucian at lastdot.org (Lucian@lastdot.org)
Date: Thu Jul 23 15:27:58 2009
Subject: How to change default source address?
Message-ID: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>

Hi guys,

I need to change the default source address on a freebsd server.
My situation is somehow similar to this
(http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
In linux i can easily do it like:

ip ro replace default via 10.10.10.1 src a.b.c.d (where a.b.c.d is em0 alias).

Any ideas?
From julian at elischer.org  Thu Jul 23 16:04:14 2009
From: julian at elischer.org (Julian Elischer)
Date: Thu Jul 23 16:04:21 2009
Subject: How to change default source address?
In-Reply-To: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>
References: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>
Message-ID: <4A6889FF.2020703@elischer.org>

Lucian@lastdot.org wrote:
> Hi guys,
> 
> I need to change the default source address on a freebsd server.
> My situation is somehow similar to this
> (http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
> In linux i can easily do it like:
> 
> ip ro replace default via 10.10.10.1 src a.b.c.d (where a.b.c.d is em0 alias).
> 
> Any ideas?
> _______________________________________________
> 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"


The source address used in most cases is the address of the
interface through which the packet will be exiting the system.

you MAY be able to do something with natd but anything you do there 
would have limitations.


A diagram of your problem would help.. I had trouble visualizing
what is happening now and what you want to happen.



From psteele at webmail.maxiscale.com  Thu Jul 23 16:27:20 2009
From: psteele at webmail.maxiscale.com (Peter Steele)
Date: Thu Jul 23 16:27:27 2009
Subject: nfe taskq performance issues
Message-ID: <B8A480488C0C6849826655761349EA431F6E00@owa.webmail.maxiscale.com>

We've been hitting serious nfe taskq performance issues during stress
tests and in doing some research on the problem we came across this old
email:

 

From: Ivan Voras <ivoras@freebsd.org>
Date: April 28, 2009 3:53:14 AM PDT
To: freebsd-threads@freebsd.org
Cc: freebsd-net@freebsd.org, freebsd-performance@freebsd.org
Subject: Re: FreeBSD 7.1 taskq em performance
>
> I have been hitting some barrier with FreeBSD 7.1 network performance.
I
> have written an application which contains two kernel threads that
takes
> mbufs directly from a network interface and forwards to another
network
> interface. This idea is to simulate different network environment.
>
> I have been using FreeBSD 6.4 amd64 and tested with an Ixia box
> (specialised hardware firing very high packet rate). The PC was a
Core2 2.6
> GHz with dual ports Intel PCIE Gigabit network card. It can manage up
to 1.2
> million pps.
>
> I have a higher spec PC with FreeBSD 7.1 amd64 and Quadcore 2.3 GHz
and
> PCIE Gigabit network card. The performance can only achieve up to 600k
pps.
> I notice the 'taskq em0' and 'taskq em1' is solid 100% CPU but it is
not in
> FreeBSD 6.4. 

 

In our case we are running FreeBSD 7.0, but we are seeing our boxes
experience serious thread starvation issues as the nfe0 cpu percentage
climbs steadily while cpu idle time drops at times to 0 percent. This
email thread mentioned a patch for the em driver here:

 

http://people.yandex-team.ru/~wawa/ 
<http://people.yandex-team.ru/%7Ewawa/> 

 

Does anyone know if this patch will work with the nfe driver?

 

From bms at incunabulum.net  Thu Jul 23 18:54:13 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu Jul 23 18:54:19 2009
Subject: How to change default source address?
In-Reply-To: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>
References: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>
Message-ID: <4A68B1D2.5080201@incunabulum.net>

Lucian@lastdot.org wrote:
> Hi guys,
>
> I need to change the default source address on a freebsd server.
> My situation is somehow similar to this
> (http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
> In linux i can easily do it like:
>
> ip ro replace default via 10.10.10.1 src a.b.c.d (where a.b.c.d is em0 alias).
>   

There is preliminary source address policy/selection support in the 
network stack, from KAME, however it is not currently fully implemented 
for IPv4.

Most users just bind their daemons to different interface addresses. As 
Julian points out, you could use a packet filter (e.g. PF, IPFW) to 
change the source address for your traffic, but I suspect you want a 
socket-layer solution.

If your applications can't be told to use different interface addresses, 
then this is the quickest way to achieve what you want. However, 
volunteers to finish the source address selection support, are more than 
welcome.

thanks,
BMS


From if at xip.at  Thu Jul 23 20:42:13 2009
From: if at xip.at (Ingo Flaschberger)
Date: Thu Jul 23 20:42:20 2009
Subject: natt (again) in 7.2 stable and a forticlient
Message-ID: <alpine.LFD.1.10.0907232208260.25323@filebunker.xip.at>

Dear Yvan,

I have tried to get natt at freebsd 7.2 stable with your patch
http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
and ipsec-tools 0.7.2 and 0.8-alpha20090525+natt running,
but have no success.

negotiation works, but traffic from forticlient gives
esp_input_cb: authentication hash mismatch for packet in SA x.x.x.x/009320d9
error.

Also there is no traffic seen incoming at the forticlient, but leaves the 
freebsd-box.

I have tried to figure out changes at freebsd 8.0 and the patchset
http://people.freebsd.org/~bz/20090523-04-natt.diff, but that is at some
places new code.

Do you have any idea what breaks?
Will it work at 8.0? and does it make sense to go with 8.0?
(have seen some other ipsec patches from you that address stability)

Kind regards,
 	Ingo Flaschberger
From bob at veznat.com  Fri Jul 24 01:17:53 2009
From: bob at veznat.com (Bob Van Zant)
Date: Fri Jul 24 01:18:00 2009
Subject: IPv6 traffic between two hosts not flowing
Message-ID: <C68E5309.36C3E%bob@veznat.com>

I have 2 FreeBSD machines each with 3 ethernet interfaces each with an IPv6
address.

Here's a table showing how the two machines are connected. To try to blame
the switch or its configuration I have tried directly connecting the
machines. The results were the same.

6.3                    4948             6.2
---                    ----             ---
fxp0                                  em2
fc00:dada::47                         fc00:dada::2

bge0                                  em0
fc00:dada:1::47                       fc00:dada:1::2

bge1                                  em1
fc00:dada:2::47                       fc00:dada:2::2

Traffic from fxp0 to em2 works fine.
bge0 to em0 and bge1 to em1 doesn't work as I'll explain below and is the
reason I'm writing to the list.


This host is able to communicate with it's IPv6 neighbor over the fxp0
interface, however, neither of the bge interfaces are able to communicate
with their peers.

ndp(8) output on the 6.3 machine (with bge interfaces) seems to highlight
something weird. In addition to the errors occurring, the Netif column for
fc00:dada:1::47 shows fxp0. ifconfig shows that address on bge0. The same is
true for fc00:dada:2::47; in ndp it shows up on fxp0 but ifconfig thinks
it's on bge1 (it should be). The linklayer address being "(incomplete)" also
seems weird given that this is a normal ethernet interface on the local
machine.


$ ndp -an
Neighbor                             Linklayer Address  Netif Expire    S
Flags
fc00:dada::2                         0:e:c:b4:13:8f      fxp0 22h38m10s S R
fc00:dada::47                        0:2:b3:e7:4a:56     fxp0 permanent R
ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument
ndp: failed to get neighbor information
fc00:dada:1::47                      (incomplete)        fxp0
ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument
ndp: failed to get neighbor information
fc00:dada:2::47                      (incomplete)        fxp0
fe80::20d:56ff:fe70:a9ae%bge0        0:d:56:70:a9:ae     bge0 permanent R
fe80::20d:56ff:fe70:a9af%bge1        0:d:56:70:a9:af     bge1 permanent R
fe80::202:b3ff:fee7:4a56%fxp0        0:2:b3:e7:4a:56     fxp0 permanent R


Output from ifmcstat looks correct to me (mostly the same as fxp0 but with
the appropriate addresses different).

I did find this message in the logfile at least once:

    nd6_storelladdr: sdl_alen == 0


If I do a ping6 in between the two hosts and then run tcpdump on either of
the bge interfaces I can see neighbor discovery traffic going back and
forth.

If the ping is from the bge interface to the corresponding em interface then
all I ever see is the NDP traffic.

If the ping is from the em interface to the corresponding bge interface then
I see a normal solicitation and advertisement followed by ICMP echo requests
(there are never any replies). The 6.2 machine's ndp cache looks correct.
The 6.3 machine's ndp cache is the one pasted above.


I feel like I'm just rambling here and not necessarily putting together a
sane question. If this is making sense to anyone and it isn't immediately
obvious what's going on please ask me some follow up questions.

In addition to all of this, after what appears to be about an hour of
sending ping packets that go nowhere and pulling interfaces in and out of
promiscuous mode (tcpdump) the system appears to deadlock. I don't have any
proof that it's deadlock other than a completely unresponsive box that needs
to have the power cable removed. It's happened twice so far this afternoon.

Thanks for reading this far,

Bob


From julian at elischer.org  Fri Jul 24 04:32:26 2009
From: julian at elischer.org (Julian Elischer)
Date: Fri Jul 24 04:32:33 2009
Subject: IPv6 traffic between two hosts not flowing
In-Reply-To: <C68E5309.36C3E%bob@veznat.com>
References: <C68E5309.36C3E%bob@veznat.com>
Message-ID: <4A69395B.4020604@elischer.org>

Bob Van Zant wrote:
> I have 2 FreeBSD machines each with 3 ethernet interfaces each with an IPv6
> address.
> 
> Here's a table showing how the two machines are connected. To try to blame
> the switch or its configuration I have tried directly connecting the
> machines. The results were the same.
> 
> 6.3                    4948             6.2
> ---                    ----             ---
> fxp0                                  em2
> fc00:dada::47                         fc00:dada::2
> 
> bge0                                  em0
> fc00:dada:1::47                       fc00:dada:1::2
> 
> bge1                                  em1
> fc00:dada:2::47                       fc00:dada:2::2
> 
> Traffic from fxp0 to em2 works fine.
> bge0 to em0 and bge1 to em1 doesn't work as I'll explain below and is the
> reason I'm writing to the list.
> 
> 
> This host is able to communicate with it's IPv6 neighbor over the fxp0
> interface, however, neither of the bge interfaces are able to communicate
> with their peers.
> 
> ndp(8) output on the 6.3 machine (with bge interfaces) seems to highlight
> something weird. In addition to the errors occurring, the Netif column for
> fc00:dada:1::47 shows fxp0. ifconfig shows that address on bge0. The same is
> true for fc00:dada:2::47; in ndp it shows up on fxp0 but ifconfig thinks
> it's on bge1 (it should be). The linklayer address being "(incomplete)" also
> seems weird given that this is a normal ethernet interface on the local
> machine.

I'm going to guess that if the other connections were disconnected, 
the 2nd and 3rd pairs would work.

I'm also guessing that if you closely look at the data between the 2nd 
and 3rd pairs you will somewhere see the addresses of the first pair
in there. FreeBSD has often suffered when trying to run connections in 
parallel, even in IPV4.

I believe this has been fixed in 8.x to some extent..



> 
> 
> $ ndp -an
> Neighbor                             Linklayer Address  Netif Expire    S
> Flags
> fc00:dada::2                         0:e:c:b4:13:8f      fxp0 22h38m10s S R
> fc00:dada::47                        0:2:b3:e7:4a:56     fxp0 permanent R
> ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument
> ndp: failed to get neighbor information
> fc00:dada:1::47                      (incomplete)        fxp0
> ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument
> ndp: failed to get neighbor information
> fc00:dada:2::47                      (incomplete)        fxp0
> fe80::20d:56ff:fe70:a9ae%bge0        0:d:56:70:a9:ae     bge0 permanent R
> fe80::20d:56ff:fe70:a9af%bge1        0:d:56:70:a9:af     bge1 permanent R
> fe80::202:b3ff:fee7:4a56%fxp0        0:2:b3:e7:4a:56     fxp0 permanent R
> 
> 
> Output from ifmcstat looks correct to me (mostly the same as fxp0 but with
> the appropriate addresses different).
> 
> I did find this message in the logfile at least once:
> 
>     nd6_storelladdr: sdl_alen == 0
> 
> 
> If I do a ping6 in between the two hosts and then run tcpdump on either of
> the bge interfaces I can see neighbor discovery traffic going back and
> forth.

but not correct probably or it would be stored in the Link Level tables.

> 
> If the ping is from the bge interface to the corresponding em interface then
> all I ever see is the NDP traffic.
> 
> If the ping is from the em interface to the corresponding bge interface then
> I see a normal solicitation and advertisement followed by ICMP echo requests
> (there are never any replies). The 6.2 machine's ndp cache looks correct.
> The 6.3 machine's ndp cache is the one pasted above.
> 
> 
> I feel like I'm just rambling here and not necessarily putting together a
> sane question. If this is making sense to anyone and it isn't immediately
> obvious what's going on please ask me some follow up questions.
> 
> In addition to all of this, after what appears to be about an hour of
> sending ping packets that go nowhere and pulling interfaces in and out of
> promiscuous mode (tcpdump) the system appears to deadlock. I don't have any
> proof that it's deadlock other than a completely unresponsive box that needs
> to have the power cable removed. It's happened twice so far this afternoon.
> 
> Thanks for reading this far,

if you had an 8.x image, you might try it there..
and a 6.2<->6.2 and 6.3<->6.3 boot as well
probably the person you want to actually speak with is Qing Li

> 
> Bob
> 
> 
> _______________________________________________
> 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"

From jamie.ostrowski at gmail.com  Fri Jul 24 04:42:07 2009
From: jamie.ostrowski at gmail.com (Jamie Ostrowski)
Date: Fri Jul 24 04:42:13 2009
Subject: How to change default source address?
In-Reply-To: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>
References: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>
Message-ID: <29ae62fc0907232114r2afb9dc8y966a22db6d3236bc@mail.gmail.com>

On Thu, Jul 23, 2009 at 9:57 AM, Lucian@lastdot.org <lucian@lastdot.org>wrote:

> Hi guys,
>
> I need to change the default source address on a freebsd server.
> My situation is somehow similar to this
> (http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
> In linux i can easily do it like:
>
> ip ro replace default via 10.10.10.1 src a.b.c.d (where a.b.c.d is em0
> alias).
>
> Any ideas?
>


  There may technically be a way to do this. If you set your default route
to the gateway of your secondary network assigned to your card, it will
actually change the source ip of your packets to be coming from the machine.


  For example, let's say I've got my nic configured like this:

   fxp1: 172.16.1.5 netmask 255.255.255.0
   fxp1_alias0: 192.168.0.2 255.255.255.0

  If I do:

   route delete default
   route add default 192.168.0.1

  The machine will send all the packets bound for any default address out
the interface 192.168.0.2 to 192.168.0.1, and it will show up on the other
end of the connection coming from that address, rather than 172.16.1.5.

  Of course, that will only work if, in your case, your secondary ip address
you want to use is on a different subnet than your primary on the machine.
Since you didn't specify, I'm making that assumption.

  Depending on your application, your mileage will vary.


    - Jamie











> _______________________________________________
> 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"
>
From julian at elischer.org  Fri Jul 24 04:51:45 2009
From: julian at elischer.org (Julian Elischer)
Date: Fri Jul 24 04:51:52 2009
Subject: How to change default source address?
In-Reply-To: <29ae62fc0907232114r2afb9dc8y966a22db6d3236bc@mail.gmail.com>
References: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>
	<29ae62fc0907232114r2afb9dc8y966a22db6d3236bc@mail.gmail.com>
Message-ID: <4A693DE2.3050905@elischer.org>

Jamie Ostrowski wrote:
> On Thu, Jul 23, 2009 at 9:57 AM, Lucian@lastdot.org <lucian@lastdot.org>wrote:
> 
>> Hi guys,
>>
>> I need to change the default source address on a freebsd server.
>> My situation is somehow similar to this
>> (http://marc.info/?l=freebsd-questions&m=122535960804508&w=2).
>> In linux i can easily do it like:
>>
>> ip ro replace default via 10.10.10.1 src a.b.c.d (where a.b.c.d is em0
>> alias).
>>
>> Any ideas?
>>
> 
> 
>   There may technically be a way to do this. If you set your default route
> to the gateway of your secondary network assigned to your card, it will
> actually change the source ip of your packets to be coming from the machine.
> 
> 
>   For example, let's say I've got my nic configured like this:
> 
>    fxp1: 172.16.1.5 netmask 255.255.255.0
>    fxp1_alias0: 192.168.0.2 255.255.255.0
> 
>   If I do:
> 
>    route delete default
>    route add default 192.168.0.1
> 
>   The machine will send all the packets bound for any default address out
> the interface 192.168.0.2 to 192.168.0.1, and it will show up on the other
> end of the connection coming from that address, rather than 172.16.1.5.
> 
>   Of course, that will only work if, in your case, your secondary ip address
> you want to use is on a different subnet than your primary on the machine.
> Since you didn't specify, I'm making that assumption.
> 
>   Depending on your application, your mileage will vary.

you could set up 2 routing tables and assign different apps to use 
different tables.

> 
> 
>     - Jamie
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> _______________________________________________
>> 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"
>>
> _______________________________________________
> 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"

From vanhu at FreeBSD.org  Fri Jul 24 08:29:18 2009
From: vanhu at FreeBSD.org (VANHULLEBUS Yvan)
Date: Fri Jul 24 08:29:25 2009
Subject: natt (again) in 7.2 stable and a forticlient
In-Reply-To: <alpine.LFD.1.10.0907232208260.25323@filebunker.xip.at>
References: <alpine.LFD.1.10.0907232208260.25323@filebunker.xip.at>
Message-ID: <20090724082915.GA93467@zeninc.net>

On Thu, Jul 23, 2009 at 10:15:25PM +0200, Ingo Flaschberger wrote:
> Dear Yvan,

Hi.


> I have tried to get natt at freebsd 7.2 stable with your patch
> http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
> and ipsec-tools 0.7.2 and 0.8-alpha20090525+natt running,
> but have no success.

http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
will work with ipsec-tools 0.7.2 but NOT with 0.8-alpha20090525+natt.


> negotiation works, but traffic from forticlient gives
> esp_input_cb: authentication hash mismatch for packet in SA x.x.x.x/009320d9
> error.

Strange.... does this work with the same forticlient but without NAT-T ?


> Also there is no traffic seen incoming at the forticlient, but leaves the 
> freebsd-box.

Are you sure you don't have "something strange" on your network ?
For example an old an ugly "IKE proxy" which would tries to "fix"
traffic coming through UDP 500 ?

Can you check what version of NAT-T is used by your forticlient ?

By default, ipsec-tools will announce support for RFC and drafts 00/01
(we'll have to change that to only announce RFC by default).

If forticlient announces/choices drafts 00/01, and if there is some
kind of IKE proxy on the way, it will probably just won't work (and
may explain authentication hashs mismatches....).


> I have tried to figure out changes at freebsd 8.0 and the patchset
> http://people.freebsd.org/~bz/20090523-04-natt.diff, but that is at some
> places new code.

Thare are some changes, but basically, the code does the same thing
(but it does it in a cleaner way :-) ).


> Do you have any idea what breaks?
> Will it work at 8.0? and does it make sense to go with 8.0?
> (have seen some other ipsec patches from you that address stability)

You can also try 8.0 with a recent ipsec-tools HEAD, but I guess
you'll have the same result.



Yvan.
From lapo at lapo.it  Fri Jul 24 09:02:56 2009
From: lapo at lapo.it (Lapo Luchini)
Date: Fri Jul 24 09:03:03 2009
Subject: error creating stf1 [Was: using 6to4 on two different IPv4
	addresses]
In-Reply-To: <gojqmq$ms$1@ger.gmane.org>
References: <gojqmq$ms$1@ger.gmane.org>
Message-ID: <4A69727E.2010206@lapo.it>

Lapo Luchini wrote:
> % sudo ifconfig stf1 create
> ifconfig: SIOCIFCREATE: Invalid argument
> 
> I guess the kernel is hardwired to support only one stf interface?
> 
> "man stf" states:
>   Each stf interface is created at runtime using interface cloning.
>   This is most easily done with the ifconfig(8) create command or
>   using the cloned_interfaces variable in rc.conf(5).

I think this is either a bug or a documentation bug: if it's supposed to
be able to create only one interface, then
"Each stf interface is created"
should probably be changed to something like
"The one and only stf interface is created"
... else "ifconfig create" should work as stated.

Mhh, Eygene Ryabinkin in message
http://lists.freebsd.org/pipermail/freebsd-net/2009-July/022456.html
states that "stf(4) is essentially a singleton interface", in that case
I guess it's the man that should be patched (to remove that "each") and
maybe support for aliases should be added.

-- 
Lapo Luchini - http://lapo.it/
From vova at fbsd.ru  Fri Jul 24 11:37:18 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Fri Jul 24 11:37:25 2009
Subject: How to change default source address?
In-Reply-To: <4A693DE2.3050905@elischer.org>
References: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>
	<29ae62fc0907232114r2afb9dc8y966a22db6d3236bc@mail.gmail.com>
	<4A693DE2.3050905@elischer.org>
Message-ID: <1248433706.1678.13.camel@localhost>

Hi 

 
> you could set up 2 routing tables and assign different apps to use 
> different tables

Is it possible to select routing table by ipfw setfib X ?

someting like:

ipfw add setfib 1 ip from a.b.c.d to any out xmit em0
setfib 1 route add default 10.10.10.1 


PS:
you may need to compile kernel with 
options ROUTETABLES=2

PPS:
why there is not sysctl way to specify number of routing tables ? 

-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From if at xip.at  Fri Jul 24 12:06:20 2009
From: if at xip.at (Ingo Flaschberger)
Date: Fri Jul 24 12:06:27 2009
Subject: natt (again) in 7.2 stable and a forticlient
In-Reply-To: <20090724082915.GA93467@zeninc.net>
References: <alpine.LFD.1.10.0907232208260.25323@filebunker.xip.at>
	<20090724082915.GA93467@zeninc.net>
Message-ID: <alpine.LFD.1.10.0907241400520.1395@filebunker.xip.at>

Dear Yvan,

>> I have tried to get natt at freebsd 7.2 stable with your patch
>> http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
>> and ipsec-tools 0.7.2 and 0.8-alpha20090525+natt running,
>> but have no success.
>
> http://people.freebsd.org/~vanhu/NAT-T/patch-natt-7.2-2009-05-12.diff
> will work with ipsec-tools 0.7.2 but NOT with 0.8-alpha20090525+natt.

seems to work with both versions.

>> negotiation works, but traffic from forticlient gives
>> esp_input_cb: authentication hash mismatch for packet in SA x.x.x.x/009320d9
>> error.
>
> Strange.... does this work with the same forticlient but without NAT-T ?

yes.

>> Also there is no traffic seen incoming at the forticlient, but leaves the
>> freebsd-box.
>
> Are you sure you don't have "something strange" on your network ?
> For example an old an ugly "IKE proxy" which would tries to "fix"
> traffic coming through UDP 500 ?
>
> Can you check what version of NAT-T is used by your forticlient ?

"draft"
If I use rfc-version of http://shrew.net/ ipsec-client (2.1.5-rc-2)
nat-t works.

> By default, ipsec-tools will announce support for RFC and drafts 00/01
> (we'll have to change that to only announce RFC by default).

I will try that.

> If forticlient announces/choices drafts 00/01, and if there is some
> kind of IKE proxy on the way, it will probably just won't work (and
> may explain authentication hashs mismatches....).

I have tried that behind 2 different nat-gw (freebsd and linux) and there
was definitley no ike proxy.

..

If i use draft-version with http://shrew.net/ ipsec-client, I see 
valid incomming packets (icmp-pings), but ipsec-client tells that the
icmp-ping return packets have a unknown phase1 sa.


Kind regards,
 	Ingo Flaschberger

From julian at elischer.org  Fri Jul 24 13:23:28 2009
From: julian at elischer.org (Julian Elischer)
Date: Fri Jul 24 13:23:35 2009
Subject: How to change default source address?
In-Reply-To: <1248433706.1678.13.camel@localhost>
References: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>	
	<29ae62fc0907232114r2afb9dc8y966a22db6d3236bc@mail.gmail.com>	
	<4A693DE2.3050905@elischer.org>
	<1248433706.1678.13.camel@localhost>
Message-ID: <4A69B5D1.3070807@elischer.org>

Vladimir Grebenschikov wrote:
> Hi 
> 
>  
>> you could set up 2 routing tables and assign different apps to use 
>> different tables
> 
> Is it possible to select routing table by ipfw setfib X ?
> 
> someting like:
> 
> ipfw add setfib 1 ip from a.b.c.d to any out xmit em0
> setfib 1 route add default 10.10.10.1 
> 
> 
> PS:
> you may need to compile kernel with 
> options ROUTETABLES=2

yes

> 
> PPS:
> why there is not sysctl way to specify number of routing tables ? 

There is, kind of.
originally there had to be a compiled in table and you had to specif 
the maximum you would allow (up to 16),
and the sysctl would reduce that maximum. (that may have changed as I 
see it's read-only now for me)
That may change in the future but the hours in the day are still <= 24

> 

From julian at elischer.org  Fri Jul 24 13:27:50 2009
From: julian at elischer.org (Julian Elischer)
Date: Fri Jul 24 13:27:57 2009
Subject: How to change default source address?
In-Reply-To: <1248433706.1678.13.camel@localhost>
References: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>	
	<29ae62fc0907232114r2afb9dc8y966a22db6d3236bc@mail.gmail.com>	
	<4A693DE2.3050905@elischer.org>
	<1248433706.1678.13.camel@localhost>
Message-ID: <4A69B6D7.3080501@elischer.org>

Vladimir Grebenschikov wrote:
> Hi 
> 
>  
>> you could set up 2 routing tables and assign different apps to use 
>> different tables
> 
> Is it possible to select routing table by ipfw setfib X ?
> 
> someting like:
> 
> ipfw add setfib 1 ip from a.b.c.d to any out xmit em0
> setfib 1 route add default 10.10.10.1 

no that wouldn't work for 2 reasons.
1/ for local sockets, the routing decision is made already before it 
gets to the firewall
2/ for non-ocal packets (from another machine that you are routing)
the packet needs to b etested on the recv (in) side of things
but by then the sending machine has aready decided on a local address too.
The only way to do this would be to do: setfib -1 my_aplication
so that the sockets were created looking at fib 1
or:
setfib -1 /bin/sh
so that all children used fib 1


> 
> 
> PS:
> you may need to compile kernel with 
> options ROUTETABLES=2
> 
> PPS:
> why there is not sysctl way to specify number of routing tables ? 
> 

From Brian.Jacobs at lodgenet.com  Fri Jul 24 13:28:30 2009
From: Brian.Jacobs at lodgenet.com (Jacobs, Brian)
Date: Fri Jul 24 13:28:37 2009
Subject: L2TPv3 ?
Message-ID: <126E45722B459248997856ECB72DEB7701285E3A@host.lodgenet.com>

Anyone know of plans or status for implementation of L2TPv3 in FreeBSD?
Support for it would solve a lot of interoperability heartache with
Cisco devices...

 

Thanks!

 

/bmj

From vova at fbsd.ru  Fri Jul 24 13:40:51 2009
From: vova at fbsd.ru (Vladimir Grebenschikov)
Date: Fri Jul 24 13:40:58 2009
Subject: How to change default source address?
In-Reply-To: <4A69B6D7.3080501@elischer.org>
References: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com>
	<29ae62fc0907232114r2afb9dc8y966a22db6d3236bc@mail.gmail.com>
	<4A693DE2.3050905@elischer.org> <1248433706.1678.13.camel@localhost>
	<4A69B6D7.3080501@elischer.org>
Message-ID: <1248442843.1678.36.camel@localhost>


> >> you could set up 2 routing tables and assign different apps to use 
> >> different tables
> > 
> > Is it possible to select routing table by ipfw setfib X ?
> > 
> > someting like:
> > 
> > ipfw add setfib 1 ip from a.b.c.d to any out xmit em0
> > setfib 1 route add default 10.10.10.1 
> 
> no that wouldn't work for 2 reasons.
> 1/ for local sockets, the routing decision is made already before it 
> gets to the firewall
> 2/ for non-ocal packets (from another machine that you are routing)
> the packet needs to be tested on the recv (in) side of things
> but by then the sending machine has aready decided on a local address too.

Not nice. I have a dream, that fbsd now capable to do real multi-fib routing :(

What about ipfw fwd ? That was working years ago for me, but of course, requires to put all custom routing entries into ipfw rules.

What about binding of FIBs to local addresses or/and interfaces ?
Such way that kernel will decide what fib to use examining local IP address  of package ?

-- 
Vladimir B. Grebenschikov
vova@fbsd.ru
From if at xip.at  Fri Jul 24 14:10:44 2009
From: if at xip.at (Ingo Flaschberger)
Date: Fri Jul 24 14:10:50 2009
Subject: natt (again) in 7.2 stable and a forticlient
In-Reply-To: <20090724082915.GA93467@zeninc.net>
References: <alpine.LFD.1.10.0907232208260.25323@filebunker.xip.at>
	<20090724082915.GA93467@zeninc.net>
Message-ID: <alpine.LFD.1.10.0907241609180.1395@filebunker.xip.at>

Hi,

attached a patch for ports-security-ipsec-tools Makefile
to disable to offer NATT-IKE-ENCAP.

Kind regardsm
 	Ingo Flaschberger
-------------- next part --------------
--- Makefile_org        2009-07-24 15:01:11.000000000 +0200
+++ Makefile    2009-07-24 16:07:32.000000000 +0200
@@ -41,6 +41,7 @@
                DPD             "enable Dead Peer Detection" on \
                NATT            "enable NAT-Traversal (kernel-patch required)" on \
                NATTF           "require NAT-Traversal (fail without kernel-patch)" off \
+               NATNONIKE       "offer NAT-Traversal UDP encapsulation only" off \
                FRAG            "enable IKE fragmentation payload support" on \
                HYBRID          "enable Hybrid, Xauth and Mode-cfg support" on \
                PAM             "enable PAM authentication (Xauth server)" off \
@@ -99,6 +100,10 @@
 CONFIGURE_ARGS+=       --disable-natt
 .endif
 
+.ifdef(NATNONIKE)
+CONFIGURE_ARGS+=       --enable-natt-versions=2,3,4,5,6,5,7,8,RFC
+.endif
+
 .ifdef(WITH_FRAG)
 CONFIGURE_ARGS+=       --enable-frag
 .else
From if at xip.at  Fri Jul 24 16:10:46 2009
From: if at xip.at (Ingo Flaschberger)
Date: Fri Jul 24 16:10:54 2009
Subject: natt (again) in 7.2 stable and a forticlient
In-Reply-To: <alpine.LFD.1.10.0907241609180.1395@filebunker.xip.at>
References: <alpine.LFD.1.10.0907232208260.25323@filebunker.xip.at>
	<20090724082915.GA93467@zeninc.net>
	<alpine.LFD.1.10.0907241609180.1395@filebunker.xip.at>
Message-ID: <alpine.LFD.1.10.0907241752070.1395@filebunker.xip.at>

Hi,

> attached a patch for ports-security-ipsec-tools Makefile
> to disable to offer NATT-IKE-ENCAP.

aii.. bug in the batch, sorry.

attached new patch.

Kind regards,
 	Ingo Flaschberger
-------------- next part --------------
--- Makefile_org        2009-07-24 15:01:11.000000000 +0200
+++ Makefile    2009-07-24 17:47:26.000000000 +0200
@@ -41,6 +41,7 @@
                DPD             "enable Dead Peer Detection" on \
                NATT            "enable NAT-Traversal (kernel-patch required)" on \
                NATTF           "require NAT-Traversal (fail without kernel-patch)" off \
+               NATNONIKE       "offer NAT-Traversal UDP encapsulation only" off \
                FRAG            "enable IKE fragmentation payload support" on \
                HYBRID          "enable Hybrid, Xauth and Mode-cfg support" on \
                PAM             "enable PAM authentication (Xauth server)" off \
@@ -99,6 +100,10 @@
 CONFIGURE_ARGS+=       --disable-natt
 .endif
 
+.ifdef(WITH_NATNONIKE)
+CONFIGURE_ARGS+=       --enable-natt-versions=2,3,4,5,6,5,7,8,RFC
+.endif
+
 .ifdef(WITH_FRAG)
 CONFIGURE_ARGS+=       --enable-frag
 .else
From barney_cordoba at yahoo.com  Fri Jul 24 21:10:57 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Fri Jul 24 21:11:04 2009
Subject: nfe taskq performance issues
Message-ID: <624694.56110.qm@web63902.mail.re1.yahoo.com>




--- On Thu, 7/23/09, Peter Steele <psteele@webmail.maxiscale.com> wrote:

> From: Peter Steele <psteele@webmail.maxiscale.com>
> Subject: nfe taskq performance issues
> To: freebsd-net@FreeBSD.org
> Date: Thursday, July 23, 2009, 11:58 AM
> We've been hitting serious nfe taskq
> performance issues during stress
> tests and in doing some research on the problem we came
> across this old
> email:
> 
>  
> 
> From: Ivan Voras <ivoras@freebsd.org>
> Date: April 28, 2009 3:53:14 AM PDT
> To: freebsd-threads@freebsd.org
> Cc: freebsd-net@freebsd.org,
> freebsd-performance@freebsd.org
> Subject: Re: FreeBSD 7.1 taskq em performance
> >
> > I have been hitting some barrier with FreeBSD 7.1
> network performance.
> I
> > have written an application which contains two kernel
> threads that
> takes
> > mbufs directly from a network interface and forwards
> to another
> network
> > interface. This idea is to simulate different network
> environment.
> >
> > I have been using FreeBSD 6.4 amd64 and tested with an
> Ixia box
> > (specialised hardware firing very high packet rate).
> The PC was a
> Core2 2.6
> > GHz with dual ports Intel PCIE Gigabit network card.
> It can manage up
> to 1.2
> > million pps.
> >
> > I have a higher spec PC with FreeBSD 7.1 amd64 and
> Quadcore 2.3 GHz
> and
> > PCIE Gigabit network card. The performance can only
> achieve up to 600k
> pps.
> > I notice the 'taskq em0' and 'taskq em1' is solid 100%
> CPU but it is
> not in
> > FreeBSD 6.4. 
> 
>  
> 
> In our case we are running FreeBSD 7.0, but we are seeing
> our boxes
> experience serious thread starvation issues as the nfe0 cpu
> percentage
> climbs steadily while cpu idle time drops at times to 0
> percent. This
> email thread mentioned a patch for the em driver here:
> 
>  
> 
> http://people.yandex-team.ru/~wawa/ 
> <http://people.yandex-team.ru/%7Ewawa/>

It means you're using your CPU up processing packets. There are any number
of reasons for it; lock contention, poor general design, network stack
contention. I'm not sure why you'd want to use a 64 bit build for a 
network application, but you'll have to track down the source by profiling
or running focused tests to isolate your bottlenecks.

Barney


      
From linimon at FreeBSD.org  Sat Jul 25 01:08:50 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Jul 25 01:09:02 2009
Subject: kern/137089: [lagg] lagg falsely triggers IPv6 duplicate
	address detection
Message-ID: <200907250108.n6P18nfB018813@freefall.freebsd.org>

Old Synopsis: lagg falsely triggers IPv6 duplicate address detection
New Synopsis: [lagg] lagg falsely triggers IPv6 duplicate address detection

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Jul 25 01:08:36 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=137089
From linimon at FreeBSD.org  Sat Jul 25 01:28:00 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Jul 25 01:28:07 2009
Subject: kern/136943: [wpi] [lor] wpi0_com_lock / wpi0
Message-ID: <200907250127.n6P1RxUo034082@freefall.freebsd.org>

Old Synopsis: [lor] wpi0_com_lock / wpi0
New Synopsis: [wpi] [lor] wpi0_com_lock / wpi0

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Jul 25 01:27:46 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=136943
From linimon at FreeBSD.org  Sat Jul 25 01:31:12 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Jul 25 01:31:20 2009
Subject: kern/137036: [ipsec] fastforwarding breaks ipsec
Message-ID: <200907250131.n6P1V6OX042347@freefall.freebsd.org>

Old Synopsis: fastforwarding breaks ipsec
New Synopsis: [ipsec] fastforwarding breaks ipsec

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Jul 25 01:30:44 UTC 2009
Responsible-Changed-Why: 
Apparently this is documented behavior.

http://www.freebsd.org/cgi/query-pr.cgi?pr=137036
From iprebeg at freebsd.org  Sat Jul 25 13:10:52 2009
From: iprebeg at freebsd.org (iprebeg@freebsd.org)
Date: Sat Jul 25 13:10:59 2009
Subject: Wrong multicast destination IP
Message-ID: <20090725130424.GA24589@valeria.zesoi.fer.hr>


In recent current kernel, it appears that IGMPv2 reports (not IGMPv3)
are sent to wrong multicast address. I'm trying to setup mcast routing
in this way:

.--.                     .--.                     .--.
|c1|-10.0.1.2---10.0.1.1-|mr|-10.0.2.1---10.0.2.2-|c2|
'--' em0             em0 '--' em2             em0 '--'

(em1 is used for SSH access)

mrouted is started on mr with configuration containing only one line:

>phyint em1 disable

and route is created:

>route add 224/24 -iface em0

Machine c1 issues command

>mcastread -v4 -s 10.0.2.2 em0 235.0.0.1 1337

and machine c2 has route

>route add 224/24 -iface em0

and issuse command

>mcastsend 235.0.0.1 1337

mr uses p4 kernel dating 24th of June and cX's use BETA2.

So, I have two problems. 

1) No packets are forwarded. I hope that reason is problem stated in 2).
   Anyway, I'd be happy if someone can confirm that I'm doing everything
   right. It would be also cool if someone could post XORP configuration
   that I can use for this configuration. I can see UDP packets reach em2 
   iface on mr.

2) Even all machines support IGMPv3, after I start mrouted, network
   converges to IGMPv2. What I see in tcpdump is that DIP of IGMPv2
   packets isn't in IGMP-CONTROL range (224.0.0.X), but it is set to IP
   of group that it tries to join ( 235.0.0.1 in this case ). This is
   not cast with IGMP leave or IGMPv3 reports which are generated by
   same commands after I kill mrouted and network again converges to
   IGMPv3.

TIA

iprebeg
From vanhu at FreeBSD.org  Sat Jul 25 13:30:56 2009
From: vanhu at FreeBSD.org (VANHULLEBUS Yvan)
Date: Sat Jul 25 13:31:02 2009
Subject: natt (again) in 7.2 stable and a forticlient
In-Reply-To: <alpine.LFD.1.10.0907241752070.1395@filebunker.xip.at>
References: <alpine.LFD.1.10.0907232208260.25323@filebunker.xip.at>
	<20090724082915.GA93467@zeninc.net>
	<alpine.LFD.1.10.0907241609180.1395@filebunker.xip.at>
	<alpine.LFD.1.10.0907241752070.1395@filebunker.xip.at>
Message-ID: <20090725133053.GA3042@zeninc.net>

On Fri, Jul 24, 2009 at 06:10:42PM +0200, Ingo Flaschberger wrote:
> Hi,
>
>> attached a patch for ports-security-ipsec-tools Makefile
>> to disable to offer NATT-IKE-ENCAP.
>
> aii.. bug in the batch, sorry.
>
> attached new patch.

Drafts 05+ should NOT be used, as they use IANA numbers which have
been assigned to other RFCs.

The cleaner change will probably be to enable only RFC support by
default directly in ipsec-tools (for 0.8.0 release), and perhaps to
add some optiond to enable a specific list of drafts to support in
FreeBSD's patch.



Yvan.
From iprebeg at freebsd.org  Sat Jul 25 14:18:09 2009
From: iprebeg at freebsd.org (iprebeg@freebsd.org)
Date: Sat Jul 25 14:18:16 2009
Subject: Wrong multicast destination IP
In-Reply-To: <20090725130424.GA24589@valeria.zesoi.fer.hr>
References: <20090725130424.GA24589@valeria.zesoi.fer.hr>
Message-ID: <20090725141138.GA3370@valeria.zesoi.fer.hr>

On Sat, Jul 25, 2009 at 03:04:24PM +0200, iprebeg@freebsd.org wrote:
> 
> In recent current kernel, it appears that IGMPv2 reports (not IGMPv3)
> are sent to wrong multicast address. I'm trying to setup mcast routing
> in this way:
> 
> .--.                     .--.                     .--.
> |c1|-10.0.1.2---10.0.1.1-|mr|-10.0.2.1---10.0.2.2-|c2|
> '--' em0             em0 '--' em2             em0 '--'
> 
> (em1 is used for SSH access)
> 
> mrouted is started on mr with configuration containing only one line:
> 
> >phyint em1 disable
> 
> and route is created:
> 
> >route add 224/24 -iface em0
> 
> Machine c1 issues command
> 
> >mcastread -v4 -s 10.0.2.2 em0 235.0.0.1 1337
> 
> and machine c2 has route
> 
> >route add 224/24 -iface em0
> 
> and issuse command
> 
> >mcastsend 235.0.0.1 1337
> 
> mr uses p4 kernel dating 24th of June and cX's use BETA2.
> 
> So, I have two problems. 
> 
> 1) No packets are forwarded. I hope that reason is problem stated in 2).
>    Anyway, I'd be happy if someone can confirm that I'm doing everything
>    right. It would be also cool if someone could post XORP configuration
>    that I can use for this configuration. I can see UDP packets reach em2 
>    iface on mr.
> 
> 2) Even all machines support IGMPv3, after I start mrouted, network
>    converges to IGMPv2. What I see in tcpdump is that DIP of IGMPv2
>    packets isn't in IGMP-CONTROL range (224.0.0.X), but it is set to IP
>    of group that it tries to join ( 235.0.0.1 in this case ). This is
>    not cast with IGMP leave or IGMPv3 reports which are generated by
>    same commands after I kill mrouted and network again converges to
>    IGMPv3

Please, IGNORE part about improper dest addr, I realized difference with
IGMPv3 and IGMPv{1,2} reports destionation IP. I still need some help
with setting up mcast routing...

> 
> TIA
> 
> iprebeg
> _______________________________________________
> 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"
From lists.br at gmail.com  Sat Jul 25 15:31:33 2009
From: lists.br at gmail.com (Luiz Otavio O Souza)
Date: Sat Jul 25 15:31:40 2009
Subject: How to change default source address?
References: <5a3c8f450907230757j21191a11n6cae4699ec8a76e1@mail.gmail.com><29ae62fc0907232114r2afb9dc8y966a22db6d3236bc@mail.gmail.com><4A693DE2.3050905@elischer.org>
	<1248433706.1678.13.camel@localhost><4A69B6D7.3080501@elischer.org>
	<1248442843.1678.36.camel@localhost>
Message-ID: <8222942B09F94943A7B9314F1D7833E4@adnote989>

>
>> >> you could set up 2 routing tables and assign different apps to use
>> >> different tables
>> >
>> > Is it possible to select routing table by ipfw setfib X ?
>> >
>> > someting like:
>> >
>> > ipfw add setfib 1 ip from a.b.c.d to any out xmit em0
>> > setfib 1 route add default 10.10.10.1
>>
>> no that wouldn't work for 2 reasons.
>> 1/ for local sockets, the routing decision is made already before it
>> gets to the firewall
>> 2/ for non-ocal packets (from another machine that you are routing)
>> the packet needs to be tested on the recv (in) side of things
>> but by then the sending machine has aready decided on a local address 
>> too.
>
> Not nice. I have a dream, that fbsd now capable to do real multi-fib 
> routing :(
>
> What about ipfw fwd ? That was working years ago for me, but of course, 
> requires to put all custom routing entries into ipfw rules.
>
> What about binding of FIBs to local addresses or/and interfaces ?
> Such way that kernel will decide what fib to use examining local IP 
> address  of package ?
>
> -- 
> Vladimir B. Grebenschikov
> vova@fbsd.ru

The actual routing code doesn't receive any information about the source 
address (the route is found using exclusively the destination address), so 
right now the kernel cannot select the fib by looking at the source address 
(local address).

There is an kernel option called RADIX_MPATH wich changes the routing code 
substancially (and looks like - from an untrained eye - it uses the 
local/source address to select the correct route). Unfornately my test 
hardware dies and i cannot look at this (right now) to tell you how this 
will work in the "real world", but if you can, you should try it.

Luiz

From bz at FreeBSD.org  Sat Jul 25 19:42:10 2009
From: bz at FreeBSD.org (bz@FreeBSD.org)
Date: Sat Jul 25 19:42:17 2009
Subject: kern/137036: [ipsec] fastforwarding breaks ipsec
Message-ID: <200907251942.n6PJg8Qq031679@freefall.freebsd.org>

Synopsis: [ipsec] fastforwarding breaks ipsec

State-Changed-From-To: open->closed
State-Changed-By: bz
State-Changed-When: Sat Jul 25 19:41:06 UTC 2009
State-Changed-Why: 
Works as expected.  I admit that inet(4) is probably not the
best place to look for the description butat least it's there.


Responsible-Changed-From-To: freebsd-net->bz
Responsible-Changed-By: bz
Responsible-Changed-When: Sat Jul 25 19:41:06 UTC 2009
Responsible-Changed-Why: 
Take in case of follow-ups.

http://www.freebsd.org/cgi/query-pr.cgi?pr=137036
From mgrooms at shrew.net  Sun Jul 26 23:25:15 2009
From: mgrooms at shrew.net (Matthew Grooms)
Date: Sun Jul 26 23:25:23 2009
Subject: FreeBSD + carp on VMWare ESX
In-Reply-To: <200907201318.08122.max@love2party.net>
References: <4A638E76.2060706@shrew.net> <4A63A4B3.6090500@modulus.org>
	<3D3254E2-4E45-4C67-84D2-DB05660D768F@shrew.net>
	<200907201318.08122.max@love2party.net>
Message-ID: <4A6CE5D6.3020709@shrew.net>

Max Laier wrote:
> 
> There is clearly something very wrong with how the vswitch works and it's not 
> really FreeBSD's job to work around these issues.  The patch you posted is 
> rather intrusive and certainly not something we want in the tree.  You should 
> talk to VMWare's support to fix the obvious short-comings in the vswitch 
> design.
> 

I agree completely. We have a support contract with VMWare and I intend 
to open a ticket. However I think the likelihood of them providing a fix 
for this just about zero. Who knows, maybe they will surprise me.

> As for your patch - you want "IF_ADDR_[UN]LOCK(ifp);" around walking the 
> address list.  Don't forget to unlock before the return.
> 

Thanks for the help. Here is an updated patch against 7.2 if anyone else 
has a VMWare + FreeBSD + CARP problem child and needs a fix today ...

http://www.shrew.net/static/patches/esx-carp.diff

The IPv6 code path is untested. Also, the changes were placed under a 
sysctl conditional so the following is required in /etc/sysctl.conf to 
enable it at boot time ...

net.inet.carp.drop_echoed=1

Thanks again,

-Matthew
-------------- next part --------------
Index: ip_carp.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_carp.c,v
retrieving revision 1.52.2.3
diff -u -r1.52.2.3 ip_carp.c
--- ip_carp.c	9 May 2009 00:35:38 -0000	1.52.2.3
+++ ip_carp.c	26 Jul 2009 22:46:19 -0000
@@ -143,6 +143,8 @@
     &carp_opts[CARPCTL_LOG], 0, "log bad carp packets");
 SYSCTL_INT(_net_inet_carp, CARPCTL_ARPBALANCE, arpbalance, CTLFLAG_RW,
     &carp_opts[CARPCTL_ARPBALANCE], 0, "balance arp responses");
+SYSCTL_INT(_net_inet_carp, CARPCTL_DROPECHOED, drop_echoed, CTLFLAG_RW,
+    &carp_opts[CARPCTL_DROPECHOED], 0, "drop packets echoed to sender");
 SYSCTL_INT(_net_inet_carp, OID_AUTO, suppress_preempt, CTLFLAG_RD,
     &carp_suppress_preempt, 0, "Preemption is suppressed");
 
@@ -552,6 +554,28 @@
 		return;
 	}
 
+	/*
+	 * verify that the source address is not valid
+	 * for the interface it was received on. this
+	 * tends to happen with VMWare ESX vSwitches.
+	 */
+	if (carp_opts[CARPCTL_DROPECHOED]) {
+		struct ifnet *ifp = m->m_pkthdr.rcvif;
+		struct ifaddr *ifa;
+		IF_ADDR_LOCK(ifp);
+		TAILQ_FOREACH(ifa, &ifp->if_addrlist, ifa_list) {
+			struct in_addr in4;
+			in4 = ifatoia(ifa)->ia_addr.sin_addr;
+			if (ifa->ifa_addr->sa_family == AF_INET &&
+			    in4.s_addr == ip->ip_src.s_addr) {
+				IF_ADDR_UNLOCK(ifp);
+				m_freem(m);
+				return;
+			}
+		}
+		IF_ADDR_UNLOCK(ifp);
+	}
+
 	/* verify that the IP TTL is 255.  */
 	if (ip->ip_ttl != CARP_DFLTTL) {
 		carpstats.carps_badttl++;
@@ -644,6 +668,28 @@
 		return (IPPROTO_DONE);
 	}
 
+	/*
+	 * verify that the source address is not valid
+	 * for the interface it was received on. this
+	 * tends to happen with VMWare ESX vSwitches.
+	 */
+	if (carp_opts[CARPCTL_DROPECHOED]) {
+		struct ifnet *ifp = m->m_pkthdr.rcvif;
+		struct ifaddr *ifa;
+		IF_ADDR_LOCK(ifp);
+		TAILQ_FOREACH(ifa, &ifp->if_addrlist, ifa_list) {
+			struct in6_addr in6;
+			in6 = ifatoia6(ifa)->ia_addr.sin6_addr;
+			if (ifa->ifa_addr->sa_family == AF_INET6 &&
+			    memcmp(&in6, &ip6->ip6_src, sizeof(in6)) == 0) {
+				IF_ADDR_UNLOCK(ifp);
+				m_freem(m);
+				return (IPPROTO_DONE);
+			}
+		}
+		IF_ADDR_UNLOCK(ifp);
+	}
+
 	/* verify that the IP TTL is 255 */
 	if (ip6->ip6_hlim != CARP_DFLTTL) {
 		carpstats.carps_badttl++;
Index: ip_carp.h
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_carp.h,v
retrieving revision 1.3
diff -u -r1.3 ip_carp.h
--- ip_carp.h	1 Dec 2006 18:37:41 -0000	1.3
+++ ip_carp.h	26 Jul 2009 22:46:19 -0000
@@ -140,7 +140,8 @@
 #define	CARPCTL_LOG		3	/* log bad packets */
 #define	CARPCTL_STATS		4	/* statistics (read-only) */
 #define	CARPCTL_ARPBALANCE	5	/* balance arp responses */
-#define	CARPCTL_MAXID		6
+#define	CARPCTL_DROPECHOED	6	/* drop packets echoed to the sender */
+#define	CARPCTL_MAXID		7
 
 #define	CARPCTL_NAMES { \
 	{ 0, 0 }, \
From bms at incunabulum.net  Sun Jul 26 23:29:46 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Sun Jul 26 23:29:54 2009
Subject: Wrong multicast destination IP
In-Reply-To: <20090725130424.GA24589@valeria.zesoi.fer.hr>
References: <20090725130424.GA24589@valeria.zesoi.fer.hr>
Message-ID: <4A6CE6E4.3010106@incunabulum.net>

Hi,

It sounds as though you are in fact running into a regression in the ARP 
cache code.

Please see recent threads on current@, this is a known issue. 
Unfortunately I can't assist other than providing advice, I am very busy 
at the moment.

iprebeg@freebsd.org wrote:
> In recent current kernel, it appears that IGMPv2 reports (not IGMPv3)
> are sent to wrong multicast address. I'm trying to setup mcast routing
> in this way:
> ...
> mrouted is started on mr with configuration containing only one line:
>   

I wouldn't rely on mrouted for anything, DVMRP is quite obsolete. 
mrouted does not support IGMPv3 to the best of my knowledge. It embeds 
its own IGMPv2 router control, and will act as a querier. This is why 
your boxes are reverting to IGMPv2 when mrouted is running.

I would recommend ports/net/mcast-tools for exercising the multicast 
forwarding plane. There is a tool in there called 'mfc' which will let 
you temporarily install entries in the Multicast Forwarding Cache. 
Please don't use 'mfc' in a production environment -- there is no loop 
detection.

The last time I fully tested multicast forwarding on the -CURRENT track 
was in March, right after the IGMPv3 drop went in, and right after 
MROUTING was cleaned up.

I'm not aware of any regressions on that track, apart from the ARP cache 
regression which Xin Li was looking into. One chap on current@ reported 
that one of Xin Li's interim patches fixed his multicast issues, I 
believe I Cc'd you on that thread. Unfortunately Xin Li himself is also 
tied up at the moment.

> ...
> 1) No packets are forwarded. I hope that reason is problem stated in 2).
>    Anyway, I'd be happy if someone can confirm that I'm doing everything
>    right. It would be also cool if someone could post XORP configuration
>    that I can use for this configuration. I can see UDP packets reach em2 
>    iface on mr.
>   

    There is a config in XORP's tree called multicast4.boot, which is a 
basic example of PIM config.


> 2) Even all machines support IGMPv3, after I start mrouted, network
>    converges to IGMPv2. What I see in tcpdump is that DIP of IGMPv2
>    packets isn't in IGMP-CONTROL range (224.0.0.X), but it is set to IP
>    of group that it tries to join ( 235.0.0.1 in this case ). This is
>    not cast with IGMP leave or IGMPv3 reports which are generated by
>    same commands after I kill mrouted and network again converges to
>    IGMPv3.
>   

These are not regressions at all -- you are seeing entirely standards 
conformant behaviour.

    The behaviour you report is entirely correct for IGMPv2 control 
traffic. Joins are always sent to the group itself. Leaves are sent to 
the fast-leave group 224.0.0.2. To the best of my knowledge, this 
behaviour has not regressed (at least at layer 3) in the network stack.

    I did have a set of automated QEMU and PCS based regression tests 
for IGMP. Unfortunately, due to broken serial behaviour, this does not 
work with FreeBSD 8-CURRENT, however it has worked with prior versions 
of FreeBSD.

    I'm sorry, I am very tied up with $DAYJOB at the moment and can't 
really be of further help. I can try to answer technical questions in 
email about the code, but I can't set aside any free time at the moment 
to test or debug.

    A good reference for multicast deployment is the book 'Interdomain 
Multicast Routing', I found it very helpful. Hopefully this is enough 
information to get you started on the right track.

thanks,
BMS
From bugmaster at FreeBSD.org  Mon Jul 27 11:06:59 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Jul 27 11:09:11 2009
Subject: Current problem reports assigned to freebsd-net@FreeBSD.org
Message-ID: <200907271106.n6RB6w4k019035@freefall.freebsd.org>

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/137089  net        [lagg] lagg falsely triggers IPv6 duplicate address de
o bin/136994   net        [patch] ifconfig(8) print carp mac address
o kern/136943  net        [wpi] [lor] wpi0_com_lock / wpi0
o kern/136911  net        [netgraph] [panic] system panic on kldload ng_bpf.ko t
o kern/136876  net        [bge] bge will not resume properly after suspend
o kern/136836  net        [ath] atheros card stops functioning after about 12 ho
o kern/136803  net        [sctp] [panic] Kernel panic and hanging on using SCTP
o kern/136618  net        [pf][stf] panic on cloning interface without unit numb
o kern/136482  net        [age] Attansic L1 Gigabit Ethernet recieves multicasts
o kern/136168  net        [em] em driver initialization fails on Intel 5000PSL m
o kern/135836  net        [bce] bce BCM5709 Watchdog after warm boot - ok after 
o kern/135502  net        [periodic] Warning message raised by rtfree function i
o kern/135222  net        [igb] low speed routing between two igb interfaces
o kern/135067  net        [patch] [fib] Incorrect KASSERTs in sys/net/route.c
o kern/134931  net        [route] [fib] Route messages sent to all socket listen
o kern/134658  net        [bce] bce driver fails on PowerEdge m610 blade.
o kern/134583  net        [hang] Machine with jail freezes after random amount o
o kern/134531  net        [route] [panic] kernel crash related to routes/zebra
o kern/134401  net        [msk] [panic] Kernel Fatal trap 12: page fault while i
o kern/134369  net        [route] [ip6] IPV6 in Head broken for routing table up
o kern/134168  net        [ral] ral driver problem on RT2525 2.4GHz transceiver 
o kern/134157  net        [dummynet] dummynet loads cpu for 100% and make a syst
o kern/134079  net        [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8
o kern/133969  net        [dummynet] [panic] Fatal trap 12: page fault while in 
o kern/133968  net        [dummynet] [panic] dummynet kernel panic
o kern/133902  net        [tun] Killing tun0 iface ssh tunnel causes Panic Strin
o kern/133736  net        [udp] ip_id not protected ...
o kern/133613  net        [wpi] [panic] kernel panic in wpi(4)
o kern/133595  net        [panic] Kernel Panic at pcpu.h:195
o kern/133572  net        [ppp] [hang] incoming PPTP connection hangs the system
o kern/133490  net        [bpf] [panic] 'kmem_map too small' panic on Dell r900 
o kern/133328  net        [bge] [panic] Kernel panics with Windows7 client
o kern/133235  net        [netinet] [patch] Process SIOCDLIFADDR command incorre
o kern/133218  net        [carp] [hang] use of carp(4) causes system to freeze
o kern/133204  net        [msk] msk driver timeouts
o kern/133060  net        [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs
o kern/132991  net        [bge] if_bge low performance problem
f bin/132911   net        ip6fw(8): argument type of fill_icmptypes is wrong and
o kern/132889  net        [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d
o kern/132885  net        [wlan] 802.1x broken after SVN rev 189592
o conf/132851  net        [fib] [patch] allow to setup fib for service running f
o kern/132832  net        [netinet] [patch] tcp_output() might generate invalid 
o bin/132798   net        [patch] ggatec(8): ggated/ggatec connection slowdown p
o kern/132734  net        [ifmib] [panic] panic in net/if_mib.c
o kern/132722  net        [ath] Wifi ath0 associates fine with AP, but DHCP or I
o kern/132705  net        [libwrap] [patch] libwrap - infinite loop if hosts.all
o kern/132672  net        [ndis] [panic] ndis with rt2860.sys causes kernel pani
o kern/132669  net        [xl] 3c905-TX send DUP! in reply on ping (sometime)
o kern/132625  net        [iwn] iwn drivers don't support setting country
o kern/132554  net        [ipl] There is no ippool start script/ipfilter magic t
o kern/132354  net        [nat] Getting some packages to ipnat(8) causes crash
o kern/132285  net        [carp] alias gives incorrect hash in dmesg
o kern/132277  net        [crypto] [ipsec] poor performance using cryptodevice f
o conf/132179  net        [patch] /etc/network.subr: ipv6 rtsol on incorrect wla
o kern/132107  net        [carp] carp(4) advskew setting ignored when carp IP us
o kern/131781  net        [ndis] ndis keeps dropping the link
o kern/131776  net        [wi] driver fails to init
o kern/131753  net        [altq] [panic] kernel panic in hfsc_dequeue
o bin/131567   net        [socket] [patch] Update for regression/sockets/unix_cm
o kern/131549  net        ifconfig(8) can't clear 'monitor' mode on the wireless
o kern/131536  net        [netinet] [patch] kernel does allow manipulation of su
o bin/131365   net        route(8): route add changes interpretation of network 
o kern/131162  net        [ath] Atheros driver bugginess and kernel crashes
o kern/131153  net        [iwi] iwi doesn't see a wireless network
f kern/131087  net        [ipw] [panic] ipw / iwi - no sent/received packets; iw
f kern/130820  net        [ndis] wpa_supplicant(8) returns 'no space on device'
o kern/130628  net        [nfs] NFS / rpc.lockd deadlock on 7.1-R
o conf/130555  net        [rc.d] [patch] No good way to set ipfilter variables a
o kern/130525  net        [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau
o kern/130311  net        [wlan_xauth] [panic] hostapd restart causing kernel pa
o kern/130109  net        [ipfw] Can not set fib for packets originated from loc
f kern/130059  net        [panic] Leaking 50k mbufs/hour
o kern/129750  net        [ath] Atheros AR5006 exits on "cannot map register spa
f kern/129719  net        [nfs] [panic] Panic during shutdown, tcp_ctloutput: in
o kern/129580  net        [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo
o kern/129517  net        [ipsec] [panic] double fault / stack overflow
o kern/129508  net        [carp] [panic] Kernel panic with EtherIP (may be relat
o kern/129352  net        [xl] [patch] xl0 watchdog timeout
o kern/129219  net        [ppp] Kernel panic when using kernel mode ppp
o kern/129197  net        [panic] 7.0 IP stack related panic
o kern/129135  net        [vge] vge driver on a VIA mini-ITX not working
o bin/128954   net        ifconfig(8) deletes valid routes
o kern/128917  net        [wpi] [panic] if_wpi and wpa+tkip causing kernel panic
o kern/128884  net        [msk] if_msk page fault while in kernel mode
o kern/128840  net        [igb] page fault under load with igb/LRO
o bin/128602   net        [an] wpa_supplicant(8) crashes with an(4)
o kern/128598  net        [bluetooth] WARNING: attempt to net_add_domain(bluetoo
o kern/128448  net        [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res
o conf/128334  net        [request] use wpa_cli in the "WPA DHCP" situation
o bin/128295   net        [patch] ifconfig(8) does not print TOE4 or TOE6 capabi
o bin/128001   net        wpa_supplicant(8), wlan(4), and wi(4) issues
o kern/127928  net        [tcp] [patch] TCP bandwidth gets squeezed every time t
o kern/127834  net        [ixgbe] [patch] wrong error counting
o kern/127826  net        [iwi] iwi0 driver has reduced performance and connecti
o kern/127815  net        [gif] [patch] if_gif does not set vlan attributes from
o kern/127724  net        [rtalloc] rtfree: 0xc5a8f870 has 1 refs
f bin/127719   net        [arp] arp: Segmentation fault (core dumped)
s kern/127587  net        [bge] [request] if_bge(4) doesn't support BCM576X fami
f kern/127528  net        [icmp]: icmp socket receives icmp replies not owned by
o bin/127192   net        routed(8) removes the secondary alias IP of interface 
f kern/127145  net        [wi]: prism (wi) driver crash at bigger traffic
o kern/127102  net        [wpi] Intel 3945ABG low throughput
o kern/127057  net        [udp] Unable to send UDP packet via IPv6 socket to IPv
o kern/127050  net        [carp] ipv6 does not work on carp interfaces [regressi
o kern/126945  net        [carp] CARP interface destruction with ifconfig destro
o kern/126924  net        [an] [patch] printf -> device_printf and simplify prob
o kern/126895  net        [patch] [ral] Add antenna selection (marked as TBD)
o kern/126874  net        [vlan]: Zebra problem if ifconfig vlanX destroy
o bin/126822   net        wpa_supplicant(8): WPA PSK does not work in adhoc mode
o kern/126714  net        [carp] CARP interface renaming makes system no longer 
o kern/126695  net        rtfree messages and network disruption upon use of if_
o kern/126688  net        [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and 
o kern/126475  net        [ath] [panic] ath pcmcia card inevitably panics under 
o kern/126339  net        [ipw] ipw driver drops the connection
o kern/126214  net        [ath] txpower problem with Atheros wifi card
o kern/126075  net        [inet] [patch] internet control accesses beyond end of
o bin/125922   net        [patch] Deadlock in arp(8)
o kern/125920  net        [arp] Kernel Routing Table loses Ethernet Link status 
o kern/125845  net        [netinet] [patch] tcp_lro_rx() should make use of hard
o kern/125816  net        [carp] [if_bridge] carp stuck in init when using bridg
f kern/125502  net        [ral] ifconfig ral0 scan produces no output unless in 
o kern/125258  net        [socket] socket's SO_REUSEADDR option does not work
o kern/125239  net        [gre] kernel crash when using gre
o kern/124767  net        [iwi] Wireless connection using iwi0 driver (Intel 220
o kern/124753  net        [ieee80211] net80211 discards power-save queue packets
o kern/124341  net        [ral] promiscuous mode for wireless device ral0 looses
o kern/124160  net        [libc] connect(2) function loops indefinitely
o kern/124127  net        [msk] watchdog timeout (missed Tx interrupts) -- recov
o kern/124021  net        [ip6] [panic] page fault in nd6_output()
o kern/123968  net        [rum] [panic] rum driver causes kernel panic with WPA.
p kern/123961  net        [vr] [patch] Allow vr interface to handle vlans
o kern/123892  net        [tap] [patch] No buffer space available
o kern/123890  net        [ppp] [panic] crash & reboot on work with PPP low-spee
o kern/123858  net        [stf] [patch] stf not usable behind a NAT
o kern/123796  net        [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not
o bin/123633   net        ifconfig(8) doesn't set inet and ether address in one 
f kern/123617  net        [tcp] breaking connection when client downloading file
o kern/123603  net        [tcp] tcp_do_segment and Received duplicate SYN
o kern/123559  net        [iwi] iwi periodically disassociates/associates [regre
o bin/123465   net        [ip6] route(8): route add -inet6 <ipv6_addr> -interfac
o kern/123463  net        [ipsec] [panic] repeatable crash related to ipsec-tool
o kern/123429  net        [nfe] [hang] "ifconfig nfe up" causes a hard system lo
o kern/123347  net        [bge] bge1: watchdog timeout -- linkstate changed to D
o conf/123330  net        [nsswitch.conf] Enabling samba wins in nsswitch.conf c
o kern/123256  net        [wpi] panic: blockable sleep lock with wpi(4)
f kern/123172  net        [bce] Watchdog timeout problems with if_bce
o kern/123160  net        [ip] Panic and reboot at sysctl kern.polling.enable=0
o kern/122989  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/122954  net        [lagg] IPv6 EUI64 incorrectly chosen for lagg devices
o kern/122928  net        [em] interface watchdog timeouts and stops receiving p
f kern/122839  net        [multicast] FreeBSD 7 multicast routing problem
p kern/122794  net        [lagg] Kernel panic after brings lagg(8) up if NICs ar
o kern/122780  net        [lagg] tcpdump on lagg interface during high pps wedge
o kern/122772  net        [em] em0 taskq panic, tcp reassembly bug causes radix 
o kern/122743  net        [mbuf] [panic] vm_page_unwire: invalid wire count: 0
o kern/122697  net        [ath] Atheros card is not well supported
o kern/122685  net        It is not visible passing packets in tcpdump(1)
o kern/122551  net        [bge] Broadcom 5715S no carrier on HP BL460c blade usi
o kern/122319  net        [wi] imposible to enable ad-hoc demo mode with Orinoco
o kern/122290  net        [netgraph] [panic] Netgraph related "kmem_map too smal
f kern/122252  net        [ipmi] [bge] IPMI problem with BCM5704 (does not work 
o kern/122195  net        [ed] Alignment problems in if_ed
o kern/122058  net        [em] [panic] Panic on em1: taskq
o kern/122033  net        [ral] [lor] Lock order reversal in ral0 at bootup [reg
o bin/121895   net        [patch] rtsol(8)/rtsold(8) doesn't handle managed netw
o kern/121872  net        [wpi] driver fails to attach on a fujitsu-siemens s711
s kern/121774  net        [swi] [panic] 6.3 kernel panic in swi1: net
o kern/121706  net        [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit
o kern/121624  net        [em] [regression] Intel em WOL fails after upgrade to 
o kern/121555  net        [panic] Fatal trap 12: current process = 12 (swi1: net
o kern/121443  net        [gif] [lor] icmp6_input/nd6_lookup
o kern/121437  net        [vlan] Routing to layer-2 address does not work on VLA
o bin/121359   net        [patch] ppp(8): fix local stack overflow in ppp
o kern/121298  net        [em] [panic] Fatal trap 12: page fault while in kernel
o kern/121257  net        [tcp] TSO + natd  -> slow outgoing tcp traffic
o kern/121181  net        [panic] Fatal trap 3: breakpoint instruction fault whi
o kern/121080  net        [bge] IPv6 NUD problem on multi address config on bge0
o kern/120966  net        [rum] kernel panic with if_rum and WPA encryption
p docs/120945  net        [patch] ip6(4) man page lacks documentation for TCLASS
o kern/120566  net        [request]: ifconfig(8) make order of arguments more fr
o kern/120304  net        [netgraph] [patch] netgraph source assumes 32-bit time
o kern/120266  net        [udp] [panic] gnugk causes kernel panic when closing U
o kern/120232  net        [nfe] [patch] Bring in nfe(4) to RELENG_6
o kern/120130  net        [carp] [panic] carp causes kernel panics in any conste
o bin/120060   net        routed(8) deletes link-level routes in the presence of
o kern/119945  net        [rum] [panic] rum device in hostap mode, cause kernel 
o kern/119791  net        [nfs] UDP NFS mount of aliased IP addresses from a Sol
o kern/119617  net        [nfs] nfs error on wpa network when reseting/shutdown
f kern/119516  net        [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi
o kern/119432  net        [arp] route add -host <host> -iface <nic> causes arp e
o kern/119225  net        [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr
a bin/118987   net        ifconfig(8): ifconfig -l (address_family) does not wor
o sparc/118932 net        [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output
a kern/118879  net        [bge] [patch] bge has checksum problems on the 5703 ch
o kern/118727  net        [netgraph] [patch] [request] add new ng_pf module
a kern/118238  net        [bce] [patch] bce driver shows "no carrier" on Intel S
s kern/117717  net        [panic] Kernel panic with Bittorrent client.
o kern/117448  net        [carp] 6.2 kernel crash [regression]
o kern/117423  net        [vlan] Duplicate IP on different interfaces
o bin/117339   net        [patch] route(8): loading routing management commands 
o kern/117271  net        [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap
o kern/117043  net        [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM
o kern/116837  net        [tun] [panic] [patch] ifconfig tunX destroy: panic
o kern/116747  net        [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 
o bin/116643   net        [patch] [request] fstat(1): add INET/INET6 socket deta
o kern/116328  net        [bge]: Solid hang with bge interface
o kern/116185  net        [iwi] if_iwi driver leads system to reboot
o kern/115239  net        [ipnat] panic with 'kmem_map too small' using ipnat
o kern/115019  net        [netgraph] ng_ether upper hook packet flow stops on ad
o kern/115002  net        [wi] if_wi timeout. failed allocation (busy bit). ifco
o kern/114915  net        [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f
o kern/113895  net        [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R
o kern/112722  net        [ipsec] [udp] IP v4 udp fragmented packet reject
o kern/112686  net        [patm] patm driver freezes System (FreeBSD 6.2-p4) i38
o kern/112570  net        [bge] packet loss with bge driver on BCM5704 chipset
o bin/112557   net        [patch] ppp(8) lock file should not use symlink name
o kern/112528  net        [nfs] NFS over TCP under load hangs with "impossible p
o kern/111457  net        [ral] ral(4) freeze
o kern/110140  net        [ipw] ipw fails under load
o kern/109733  net        [bge] bge link state issues [regression]
o kern/109470  net        [wi] Orinoco Classic Gold PC Card Can't Channel Hop
o kern/109308  net        [pppd] [panic] Multiple panics kernel ppp suspected [r
o kern/109251  net        [re] [patch] if_re cardbus card won't attach
o bin/108895   net        pppd(8): PPPoE dead connections on 6.2 [regression]
o kern/108542  net        [bce] Huge network latencies with 6.2-RELEASE / STABLE
o kern/107944  net        [wi] [patch] Forget to unlock mutex-locks
o kern/107850  net        [bce] bce driver link negotiation is faulty
o conf/107035  net        [patch] bridge(8): bridge interface given in rc.conf n
o kern/106438  net        [ipf] ipfilter: keep state does not seem to allow repl
o kern/106316  net        [dummynet] dummynet with multipass ipfw drops packets 
o kern/106243  net        [nve] double fault panic in if_nve.c on high loads
o kern/105945  net        Address can disappear from network interface
s kern/105943  net        Network stack may modify read-only mbuf chain copies
o bin/105925   net        problems with ifconfig(8) and vlan(4) [regression]
o kern/105348  net        [ath] ath device stopps TX
o kern/104851  net        [inet6] [patch] On link routes not configured when usi
o kern/104751  net        [netgraph] kernel panic, when getting info about my tr
o kern/104485  net        [bge] Broadcom BCM5704C: Intermittent on newer chip ve
o kern/103191  net        Unpredictable reboot
o kern/103135  net        [ipsec] ipsec with ipfw divert (not NAT) encodes a pac
o conf/102502  net        [netgraph] [patch] ifconfig name does't rename netgrap
o kern/102035  net        [plip] plip networking disables parallel port printing
o kern/101948  net        [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau
o kern/100709  net        [libc] getaddrinfo(3) should return TTL info
o kern/100519  net        [netisr] suggestion to fix suboptimal network polling
o kern/98978   net        [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel
o kern/98597   net        [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu
o bin/98218    net        wpa_supplicant(8) blacklist not working
f bin/97392    net        ppp(8) hangs instead terminating
o kern/97306   net        [netgraph] NG_L2TP locks after connection with failed 
f kern/96268   net        [socket] TCP socket performance drops by 3000% if pack
o kern/96030   net        [bfe] [patch] Install hangs with Broadcomm 440x NIC in
o kern/95519   net        [ral] ral0 could not map mbuf
o kern/95288   net        [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr
o kern/95277   net        [netinet] [patch] IP Encapsulation mask_match() return
o kern/95267   net        packet drops periodically appear
s kern/94863   net        [bge] [patch] hack to get bge(4) working on IBM e326m
o kern/94162   net        [bge] 6.x kenel stale with bge(4)
o kern/93886   net        [ath] Atheros/D-Link DWL-G650 long delay to associate 
f kern/93378   net        [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo
o kern/93019   net        [ppp] ppp and tunX problems: no traffic after restarti
o kern/92880   net        [libc] [patch] almost rewritten inet_network(3) functi
f kern/92552   net        A serious bug in most network drivers from 5.X to 6.X 
s kern/92279   net        [dc] Core faults everytime I reboot, possible NIC issu
o kern/92090   net        [bge] bge0: watchdog timeout -- resetting
o kern/91859   net        [ndis] if_ndis does not work with Asus WL-138
s kern/91777   net        [ipf] [patch] wrong behaviour with skip rule inside an
o kern/91594   net        [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10
o kern/91364   net        [ral] [wep] WF-511 RT2500 Card PCI and WEP
o kern/91311   net        [aue] aue interface hanging
o kern/90890   net        [vr] Problems with network: vr0: tx shutdown timeout
s kern/90086   net        [hang] 5.4p8 on supermicro P8SCT hangs during boot if 
f kern/88082   net        [ath] [panic] cts protection for ath0 causes panic
o kern/87521   net        [ipf] [panic] using ipfilter "auth" keyword leads to k
o kern/87506   net        [vr] [patch] Fix alias support on vr interfaces
s kern/86920   net        [ndis] ifconfig: SIOCS80211: Invalid argument [regress
o kern/86103   net        [ipf] Illegal NAT Traversal in IPFilter
o kern/85780   net        'panic: bogus refcnt 0' in routing/ipv6
o bin/85445    net        ifconfig(8): deprecated keyword to ifconfig inoperativ
o kern/85266   net        [xe] [patch] xe(4) driver does not recognise Xircom XE
o kern/84202   net        [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre
o bin/82975    net        route change does not parse classfull network as given
o kern/82497   net        [vge] vge(4) on AMD64 only works when loaded late, not
f kern/81644   net        [vge] vge(4) does not work properly when loaded as a K
s kern/81147   net        [net] [patch] em0 reinitialization while adding aliase
o kern/80853   net        [ed] [patch] add support for Compex RL2000/ISA in PnP 
o kern/79895   net        [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 
f kern/79262   net        [dc] Adaptec ANA-6922 not fully supported
o bin/79228    net        [patch] extend arp(8) to be able to create blackhole r
o kern/78090   net        [ipf] ipf filtering on bridged packets doesn't work if
p kern/77913   net        [wi] [patch] Add the APDL-325 WLAN pccard to wi(4)
o kern/77341   net        [ip6] problems with IPV6 implementation
o kern/77273   net        [ipf] ipfilter breaks ipv6 statefull filtering on 5.3
s kern/77195   net        [ipf] [patch] ipfilter ioctl SIOCGNATL does not match 
o kern/75873   net        Usability problem with non-RFC-compliant IP spoof prot
s kern/75407   net        [an] an(4): no carrier after short time
f kern/73538   net        [bge] problem with the Broadcom BCM5788 Gigabit Ethern
o kern/71469   net        default route to internet magically disappears with mu
o kern/70904   net        [ipf] ipfilter ipnat problem with h323 proxy support
o kern/64556   net        [sis] if_sis short cable fix problems with NetGear FA3
s kern/60293   net        [patch] FreeBSD arp poison patch
o kern/54383   net        [nfs] [patch] NFS root configurations without dynamic 
f i386/45773   net        [bge] Softboot causes autoconf failure on Broadcom 570
s bin/41647    net        ifconfig(8) doesn't accept lladdr along with inet addr
s kern/39937   net        ipstealth issue
a kern/38554   net        [patch] changing interface ipaddress doesn't seem to w
o kern/35442   net        [sis] [patch] Problem transmitting runts in if_sis dri
o kern/34665   net        [ipf] [hang] ipfilter rcmd proxy "hangs".
o kern/31647   net        [libc] socket calls can return undocumented EINVAL
o kern/30186   net        [libc] getaddrinfo(3) does not handle incorrect servna
o kern/27474   net        [ipf] [ppp] Interactive use of user PPP and ipfilter c
o conf/23063   net        [arp] [patch] for static ARP tables in rc.network

312 problems total.

From os at sfedu.ru  Mon Jul 27 14:34:50 2009
From: os at sfedu.ru (Oleg Sharoyko)
Date: Mon Jul 27 14:34:59 2009
Subject: Wrong outgoing interface with multiple routing tables
Message-ID: <1248704237.96833.127.camel@brain.cc.rsu.ru>

Hello!

I'm having a trouble with multiple routing tables (FreeBSD 7.2 release).
Either I'm missing something in my setup or packets for daemons started
with setfib are being sent out via the wrong interface.

What I'd like to implement:

em0 - internal management network with ip address 10.2.5.2/24 and
default route 10.2.5.1

em1 - public interface to be used in jail with ip address
195.208.245.229/27 and default route 195.208.245.225

Here are my routing tables:

r61net-fbsdhost-1, / # setfib -0 netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            10.2.5.1           UGS         0      350    em0
10.2.5.0/24        link#1             UC          0        0    em0
10.2.5.1           00:1e:4a:b4:ea:c0  UHLW        2        0    em0   1182
127.0.0.1          127.0.0.1          UH          0       30    lo0

r61net-fbsdhost-1, / # setfib -1 netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            195.208.245.225    UGS         0        0    em1
195.208.245.224/27 link#2             UC          0        0    em1
195.208.245.225    link#2             UHLW        2        0    em1

Firewall:

r61net-fbsdhost-1, / # ipfw show
00001  0    0 setfib 1 ip from any to any in recv em1
00010  0    0 count ip from any to any dst-port 2222 fib 0
00011  0    0 count ip from any 2222 to any fib 0
00012  0    0 count ip from any to any dst-port 2222 fib 1
00013  0    0 count ip from any 2222 to any fib 1
00100  0    0 allow ip from any to any via lo0
00200  0    0 deny ip from any to 127.0.0.0/8
00300  0    0 deny ip from 127.0.0.0/8 to any
65000 30 2648 allow ip from any to any
65535  0    0 deny ip from any to any


With this setup almost everything works as I expect. For example ICMP
echo requests and responses are being received and sent via em1. Both
when ping runs on this host as "setfib 1 ping other_host" and when other
host pings ip address of em1. Connection attempts (setfib 1 telnet
other_host) are also being sent out of the right interface. But when it
comes to the daemons I run into troubles. 

I use sshd for tests (have also tried other daemons with no luck):

r61net-fbsdhost-1, / # setfib 1 /usr/sbin/sshd -o 'ListenAddress 195.208.245.229:2222' -D

sshd is bound only to ip address of em1:

r61net-fbsdhost-1, / # sockstat | grep 2222
root     sshd       839   3  tcp4   195.208.245.229:2222  *:*

While doing telnet 195.208.249.229 2222 from another host I got following packet traces:

r61net-fbsdhost-1, / # tcpdump -i em0 port 2222
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
17:39:34.872475 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: S 2590499299:2590499299(0) ack 3939022576 win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 3248254533 147282318>
17:39:34.902622 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: P 1:41(40) ack 1 win 8326 <nop,nop,timestamp 3248254533 147282318>
17:39:37.572271 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: P 41:60(19) ack 7 win 8326 <nop,nop,timestamp 3248254593 147282585>
17:39:37.572293 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: F 60:60(0) ack 7 win 8326 <nop,nop,timestamp 3248254593 147282585>
17:39:37.572986 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: . ack 8 win 8325 <nop,nop,timestamp 3248254593 147282585>

r61net-fbsdhost-1, / # tcpdump -i em1 port 2222
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes
17:39:34.872370 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: S 3939022575:3939022575(0) win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 147282318 0>
17:39:34.872803 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: . ack 2590499300 win 8326 <nop,nop,timestamp 147282318 3248254533>
17:39:35.002882 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: . ack 41 win 8326 <nop,nop,timestamp 147282331 3248254533>
17:39:37.571659 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: P 0:6(6) ack 41 win 8326 <nop,nop,timestamp 147282585 3248254533>
17:39:37.572923 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: . ack 61 win 8323 <nop,nop,timestamp 147282585 3248254593>
17:39:37.572945 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: F 6:6(0) ack 61 win 8326 <nop,nop,timestamp 147282585 3248254593>

And firewall counters:

r61net-fbsdhost-1, / # ipfw show
00001  6  326 setfib 1 ip from any to any in recv em1
00010  0    0 count ip from any to any dst-port 2222 fib 0
00011  5  327 count ip from any 2222 to any fib 0
00012  6  326 count ip from any to any dst-port 2222 fib 1
00013  0    0 count ip from any 2222 to any fib 1
00100  0    0 allow ip from any to any via lo0
00200  0    0 deny ip from any to 127.0.0.0/8
00300  0    0 deny ip from 127.0.0.0/8 to any
65000 60 5057 allow ip from any to any
65535  0    0 deny ip from any to any

So the packets, generated by sshd are being sent out via em0 instead of
em1.

With

ipfw add 2 setfib 1 ip from 195.208.245.229 to any

outgoing packets are being tagged with correct fib, but still sent via
em0.

With

ipfw add 60003 fwd 195.208.245.225 src-ip me src-ip 195.208.245.224/27 not dst-ip 195.208.245.224/27

first SYN packet from 195.208.245.229 is being sent correctly via em1,
but I cannot see any further packets at all:

r61net-fbsdhost-1, / # tcpdump -i em1 port 2222
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes
18:01:56.665341 IP brain.cc.rsu.ru.50435 > stat.r61.net.2222: S 2484180116:2484180116(0) win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 147415433 0>
18:01:56.665463 IP stat.r61.net.2222 > brain.cc.rsu.ru.50435: S 3905497961:3905497961(0) ack 2484180117 win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 3376909218 147415433>
18:01:56.665798 IP brain.cc.rsu.ru.50435 > stat.r61.net.2222: . ack 1 win 8326 <nop,nop,timestamp 147415433 3376909218>

and no packets at em0. TCP connection establishes but no data packets
come from daemon which is rather weird.

I would appreciate any help with this issue.

-- 
Oleg Sharoyko.
Software and Network Engineer
Computer Center of Rostov State University.

From raffaele.delorenzo at libero.it  Mon Jul 27 17:02:13 2009
From: raffaele.delorenzo at libero.it (Raffaele De Lorenzo)
Date: Mon Jul 27 17:02:26 2009
Subject: R: IPv6 and ipfw
In-Reply-To: <4A672C79.3000006@digiware.nl>
References: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost>
	<4A672C79.3000006@digiware.nl>
Message-ID: <11956F97-0C87-456F-A769-70BEDBA351BE@libero.it>

Hi all,
I attached a patch that solve this problem. I will send a PR as soon  
as possible.

Instructions:

Patch the follow files:

/usr/src/sbin/ipfw/ipfw2.c (patch is ipfw2.c.diff)
/usr/src/sbin/ipfw/ipfw2.h (patch is ipfw2.h.diff)
/usr/src/sbin/ipfw/ipv6.c (patch is ipv6.c.diff)

This patch was tested on FreeBSD 8 Beta 2 AMD64 and official FreeBSD 8  
BETA 2 Sources.

Let me know any suggestion or problem.

Regards
Raffaele

On Jul 22, 2009, at 5:12 PM, Willem Jan Withagen wrote:

> Reply below, and an also reorganised the yours...
> raffaele.delorenzo@libero.it wrote:
>>> Hi,
>>>
>>> Running 7.2 I tried to insert
>> this into my IPFW rules
>>> # ipfw add allow udp from any to 2001:xxx:3::
-------------- next part --------------
>> 113,2001:xxxx:3::116 \
>>> 	dst-port 10001-10100 keep-state
>>> ipfw: bad netmask
>> ``xxxx:3::113''
>>> also:
>>> # ipfw add allow udp from any to trixbox.ip6 dst-port
>> 10001-10100 keep-state
>>> ipfw: hostname ``trixbox.ip6'' unknown
>>> Exit 68
>>> # host
>> trixbox.ip6
>>> trixbox.ip6.digiware.nl has IPv6 address 2001:4cb8:3::116
>>>
>>> So it
>> looks like what is in the manual is overly optimistic:
>>> ----
>>>     addr6-list:
>> ip6-addr[,addr6-list]
>>>     ip6-addr:
>>>             A host or subnet
>> specified one of the following ways:
>>>             numeric-ip | hostname
>>>                     Matches a single IPv6 address as allowed by  
>>> inet_pton(3)
>>>                     or a hostname.  Hostnames are resolved at the  
>>> time the
>>>                     rule is added to the firewall list.
>>>
>>>
>> addr/masklen
>>>                     Matches all IPv6 addresses with base addr
>> (specified as
>>>                     allowed by inet_pton or a hostname) and
>> mask width of
>>>                     masklen bits.
>>>
>>>             No support
>> for sets of IPv6 addresses is provided because IPv6
>>>             addresses
>> are typically random past the initial prefix.
>>> ----
>>>
>>> Anybody else ran into
>> this?
>>> Or should I file this as a PR.
>
> > Hi all,
> > You has found a parser bug.
> > When the protocol is "ipv6" and you are a
> > comma separated ipv6 addresses, the parser work fine because the  
> "add_srcip6"
> > function is called and recognize all addresses.
> > When the protocol is "!=ipv6"
> > (like TCP,UDP,ICMP6)  the "add_src" fuction is called and it cause  
> troubles
> > because the "inet_pton()" fails and erroneously is called the  
> "add_srcip"
> > function (see the code below).
> >
> > (from "ipfw2.c")
> >  add_src(ipfw_insn *cmd, char
> > *av, u_char proto)
> > {
> > 	struct in6_addr a;
> > 	char *host, *ch;
> > 	ipfw_insn *ret =
> > NULL;
> >
> > 	if ((host = strdup(av)) == NULL)
> > 		return NULL;
> > 	if ((ch = strrchr
> > (host, '/')) != NULL)
> > 		*ch = '\0';
> >
> > 	if (proto == IPPROTO_IPV6  || strcmp(av,
> > "me6") == 0 ||
> > 	    inet_pton(AF_INET6, host, &a))
> > 		ret = add_srcip6(cmd, av);
> >
> > 	/* XXX: should check for IPv4, not !IPv6 */
> > 	if (ret == NULL && (proto ==
> > IPPROTO_IP || strcmp(av, "me") == 0 ||
> > 	    !inet_pton(AF_INET6, host, &a)))
> > 		
> > ret = add_srcip(cmd, av);
> > 	if (ret == NULL && strcmp(av, "any") != 0)
> > 		ret =
> > cmd;
> >
> > 	free(host);
> > 	return ret;
> > }
> >
> > I think that possibles solutions are the
> > follows:
> >
> > 1) Create a new protocols types UPD6,TCP6 only for IPv6 rules to
> > avoid parser confusions, and check about this protocol inside the  
> "add_src"
> > fuction (easy to implement).
> > 2) Check the comma separated ip/ipv6 addresses
> > inside the "add_src" function (a little too hard to implement).
> >
> > I appreciate
> > suggestions from the community experts about this problem.
>
> I would prefer not to make seperate tcp6 and udp6 items, since what  
> i would like to do is things like:
>
> hostlist="a.b.c.d,A:B:C:D::F"
>
> and then in the firewall something like
> 	ipfw add allow tcp from any to ${hostlist} dst-port 80 setup
>
> and if tcp now goes into tcp and tcp6 I need to double my rules etc.
>
> Which raises one other point:
> 	using a FQDN with more A and AAAA records also just inserts the
> 	first reply in the list.
> 	Now I don't use FQDN since most of the time in the Firewall DNS
> 	is not quite up yet.
>
> --WjW
> _______________________________________________
> freebsd-ipfw@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw- 
> unsubscribe@freebsd.org"

From julian at elischer.org  Mon Jul 27 17:26:48 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jul 27 17:26:55 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <1248704237.96833.127.camel@brain.cc.rsu.ru>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>
Message-ID: <4A6DE356.6040006@elischer.org>

Oleg Sharoyko wrote:
> Hello!
> 
> I'm having a trouble with multiple routing tables (FreeBSD 7.2 release).
> Either I'm missing something in my setup or packets for daemons started
> with setfib are being sent out via the wrong interface.
> 
> What I'd like to implement:
> 
> em0 - internal management network with ip address 10.2.5.2/24 and
> default route 10.2.5.1
> 
> em1 - public interface to be used in jail with ip address
> 195.208.245.229/27 and default route 195.208.245.225
> 
> Here are my routing tables:
> 
> r61net-fbsdhost-1, / # setfib -0 netstat -rn
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags    Refs      Use  Netif Expire
> default            10.2.5.1           UGS         0      350    em0
> 10.2.5.0/24        link#1             UC          0        0    em0
> 10.2.5.1           00:1e:4a:b4:ea:c0  UHLW        2        0    em0   1182
> 127.0.0.1          127.0.0.1          UH          0       30    lo0
> 
> r61net-fbsdhost-1, / # setfib -1 netstat -rn
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags    Refs      Use  Netif Expire
> default            195.208.245.225    UGS         0        0    em1
> 195.208.245.224/27 link#2             UC          0        0    em1
> 195.208.245.225    link#2             UHLW        2        0    em1


so far, all looks correct.

> 
> Firewall:
> 
> r61net-fbsdhost-1, / # ipfw show
> 00001  0    0 setfib 1 ip from any to any in recv em1

good

> 00010  0    0 count ip from any to any dst-port 2222 fib 0
> 00011  0    0 count ip from any 2222 to any fib 0
> 00012  0    0 count ip from any to any dst-port 2222 fib 1
> 00013  0    0 count ip from any 2222 to any fib 1
> 00100  0    0 allow ip from any to any via lo0
> 00200  0    0 deny ip from any to 127.0.0.0/8
> 00300  0    0 deny ip from 127.0.0.0/8 to any
> 65000 30 2648 allow ip from any to any
> 65535  0    0 deny ip from any to any
> 
> 
> With this setup almost everything works as I expect. For example ICMP
> echo requests and responses are being received and sent via em1. Both
> when ping runs on this host as "setfib 1 ping other_host" and when other
> host pings ip address of em1. Connection attempts (setfib 1 telnet
> other_host) are also being sent out of the right interface. But when it
> comes to the daemons I run into troubles. 
> 
> I use sshd for tests (have also tried other daemons with no luck):
> 
> r61net-fbsdhost-1, / # setfib 1 /usr/sbin/sshd -o 'ListenAddress 195.208.245.229:2222' -D

Are you running this from inetd?. (doesnt look like it)

btw is it 1 or -1? or -F 1?
I can't remember if I supported just '1'.

> 
> sshd is bound only to ip address of em1:
> 
> r61net-fbsdhost-1, / # sockstat | grep 2222
> root     sshd       839   3  tcp4   195.208.245.229:2222  *:*
> 
> While doing telnet 195.208.249.229 2222 from another host I got following packet traces:
> 
> r61net-fbsdhost-1, / # tcpdump -i em0 port 2222
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
> 17:39:34.872475 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: S 2590499299:2590499299(0) ack 3939022576 win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 3248254533 147282318>
> 17:39:34.902622 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: P 1:41(40) ack 1 win 8326 <nop,nop,timestamp 3248254533 147282318>
> 17:39:37.572271 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: P 41:60(19) ack 7 win 8326 <nop,nop,timestamp 3248254593 147282585>
> 17:39:37.572293 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: F 60:60(0) ack 7 win 8326 <nop,nop,timestamp 3248254593 147282585>
> 17:39:37.572986 IP stat.r61.net.2222 > brain.cc.rsu.ru.49293: . ack 8 win 8325 <nop,nop,timestamp 3248254593 147282585>
> 
> r61net-fbsdhost-1, / # tcpdump -i em1 port 2222
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes
> 17:39:34.872370 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: S 3939022575:3939022575(0) win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 147282318 0>
> 17:39:34.872803 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: . ack 2590499300 win 8326 <nop,nop,timestamp 147282318 3248254533>
> 17:39:35.002882 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: . ack 41 win 8326 <nop,nop,timestamp 147282331 3248254533>
> 17:39:37.571659 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: P 0:6(6) ack 41 win 8326 <nop,nop,timestamp 147282585 3248254533>
> 17:39:37.572923 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: . ack 61 win 8323 <nop,nop,timestamp 147282585 3248254593>
> 17:39:37.572945 IP brain.cc.rsu.ru.49293 > stat.r61.net.2222: F 6:6(0) ack 61 win 8326 <nop,nop,timestamp 147282585 3248254593>
> 
> And firewall counters:
> 
> r61net-fbsdhost-1, / # ipfw show
> 00001  6  326 setfib 1 ip from any to any in recv em1
> 00010  0    0 count ip from any to any dst-port 2222 fib 0
> 00011  5  327 count ip from any 2222 to any fib 0
> 00012  6  326 count ip from any to any dst-port 2222 fib 1
> 00013  0    0 count ip from any 2222 to any fib 1
> 00100  0    0 allow ip from any to any via lo0
> 00200  0    0 deny ip from any to 127.0.0.0/8
> 00300  0    0 deny ip from 127.0.0.0/8 to any
> 65000 60 5057 allow ip from any to any
> 65535  0    0 deny ip from any to any
> 
> So the packets, generated by sshd are being sent out via em0 instead of
> em1.
> 
> With
> 
> ipfw add 2 setfib 1 ip from 195.208.245.229 to any
> 
> outgoing packets are being tagged with correct fib, but still sent via
> em0.


yes becasue on outgoing packets the firewall is too late to influence 
that.

> 
> With
> 
> ipfw add 60003 fwd 195.208.245.225 src-ip me src-ip 195.208.245.224/27 not dst-ip 195.208.245.224/27
> 
> first SYN packet from 195.208.245.229 is being sent correctly via em1,
> but I cannot see any further packets at all:
> 
> r61net-fbsdhost-1, / # tcpdump -i em1 port 2222
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes
> 18:01:56.665341 IP brain.cc.rsu.ru.50435 > stat.r61.net.2222: S 2484180116:2484180116(0) win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 147415433 0>
> 18:01:56.665463 IP stat.r61.net.2222 > brain.cc.rsu.ru.50435: S 3905497961:3905497961(0) ack 2484180117 win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 3376909218 147415433>
> 18:01:56.665798 IP brain.cc.rsu.ru.50435 > stat.r61.net.2222: . ack 1 win 8326 <nop,nop,timestamp 147415433 3376909218>
> 
> and no packets at em0. TCP connection establishes but no data packets
> come from daemon which is rather weird.
> 
> I would appreciate any help with this issue.

try adding a '-' on the command
and get back to me.

> 

From os at sfedu.ru  Mon Jul 27 18:13:18 2009
From: os at sfedu.ru (Oleg Sharoyko)
Date: Mon Jul 27 18:13:25 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6DE356.6040006@elischer.org>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>
	<4A6DE356.6040006@elischer.org>
Message-ID: <4A6DEE30.6000108@sfedu.ru>


Julian Elischer wrote:

>> r61net-fbsdhost-1, / # setfib 1 /usr/sbin/sshd -o 'ListenAddress 
>> 195.208.245.229:2222' -D
> 
> Are you running this from inetd?. (doesnt look like it)

No, I run this from shell merely for test purposes. First I tried to 
start sshd in a usual way in a jail, but came to this simple test example.

> btw is it 1 or -1? or -F 1?
> I can't remember if I supported just '1'.

According to manual page it works either way and it does indeed.

> try adding a '-' on the command
> and get back to me.

The same results.

--
Oleg
From julian at elischer.org  Mon Jul 27 19:27:26 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jul 27 19:27:33 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6DEE30.6000108@sfedu.ru>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>
Message-ID: <4A6DFFA1.1010709@elischer.org>

Oleg Sharoyko wrote:
> 
> Julian Elischer wrote:
> 
>>> r61net-fbsdhost-1, / # setfib 1 /usr/sbin/sshd -o 'ListenAddress 
>>> 195.208.245.229:2222' -D
>>
>> Are you running this from inetd?. (doesnt look like it)
> 
> No, I run this from shell merely for test purposes. First I tried to 
> start sshd in a usual way in a jail, but came to this simple test example.
> 
>> btw is it 1 or -1? or -F 1?
>> I can't remember if I supported just '1'.
> 
> According to manual page it works either way and it does indeed.
> 
>> try adding a '-' on the command
>> and get back to me.
> 
> The same results.


just thought I'd check the easy thing before I looked at the hard ones :-)


(the syntax changed so I wasn't sure whether it was changed in 7 and 
how much).

does it still fail if you run it in foreground mode (no daemonizing)?

> 
> -- 
> Oleg

From os at sfedu.ru  Mon Jul 27 19:34:04 2009
From: os at sfedu.ru (Oleg Sharoyko)
Date: Mon Jul 27 19:34:11 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6DFFA1.1010709@elischer.org>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>
	<4A6DFFA1.1010709@elischer.org>
Message-ID: <4A6E0121.2020004@sfedu.ru>


Julian Elischer wrote:

> does it still fail if you run it in foreground mode (no daemonizing)?

Yes. I actually test sshd in foreground mode (-D tells sshd to not go 
into background). I have also checked a very simple client/server where 
server called setsockopt(SO_SETFIB, 1) and got the same results.

--
Oleg
From julian at elischer.org  Mon Jul 27 19:52:39 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jul 27 19:52:46 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6DFFA1.1010709@elischer.org>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>	<4A6DE356.6040006@elischer.org>
	<4A6DEE30.6000108@sfedu.ru> <4A6DFFA1.1010709@elischer.org>
Message-ID: <4A6E058A.6060004@elischer.org>

So there are two possible ways a daemon might assign a fib to a socket 
that it is accepting:

1/  the accept socket could take the FIB of the process.
2/  the accept socket could take the fib of the incoming SYN packet.

I chose #1, but it is possible something in changes between 6
and 7 broke the "chain of custody" for the fib.
This code is in production in 6.x based systems but was only 
introduced to FreeBSD in 7.x.

The process makes a socket which inherits the fib from it.
The socket includes an INET PCB (Protocol Control Block)
which gets a copy too..
when "listen() is called and a syn comes in, a new entry is made in 
the syncache code and this includes a new connection block which is 
supposed to inherrit the fib number from the originating listen socket.

Eventually a new socket is created and it is supposed to inherit teh
fibnum from the syncache entry, and to copy it to the inpcb attached 
to it.

It's possible that somewhere this has been broken by changes.
but I don't see it right at the moment.


From julian at elischer.org  Mon Jul 27 19:54:23 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jul 27 19:54:30 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6E0121.2020004@sfedu.ru>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>
Message-ID: <4A6E05EC.8050401@elischer.org>

Oleg Sharoyko wrote:
> 
> Julian Elischer wrote:
> 
>> does it still fail if you run it in foreground mode (no daemonizing)?
> 
> Yes. I actually test sshd in foreground mode (-D tells sshd to not go 
> into background). I have also checked a very simple client/server where 
> server called setsockopt(SO_SETFIB, 1) and got the same results.
> 
> -- 
> Oleg


great.. in your simple server, can you do the sockopt on the socket 
AFTER you did the listen()?
(just as a test).
From os at sfedu.ru  Mon Jul 27 20:14:13 2009
From: os at sfedu.ru (Oleg Sharoyko)
Date: Mon Jul 27 20:14:20 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6E05EC.8050401@elischer.org>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>
	<4A6E05EC.8050401@elischer.org>
Message-ID: <4A6E0A8B.5000103@sfedu.ru>


Julian Elischer wrote:

> great.. in your simple server, can you do the sockopt on the socket 
> AFTER you did the listen()?
> (just as a test).

Doesn't help. I have also tried to add setsockopt() after accept() (for 
a new socket) and in this case the only packet that is being sent out 
via wrong interface is the SYN+ACK from server.

I'll try to look into the kernel code tomorrow and will report any findings.

--
Oleg
From julian at elischer.org  Mon Jul 27 20:32:36 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jul 27 20:32:43 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6E058A.6060004@elischer.org>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>	<4A6DE356.6040006@elischer.org>	<4A6DEE30.6000108@sfedu.ru>
	<4A6DFFA1.1010709@elischer.org> <4A6E058A.6060004@elischer.org>
Message-ID: <4A6E0EE7.2070103@elischer.org>

Julian Elischer wrote:
> So there are two possible ways a daemon might assign a fib to a socket 
> that it is accepting:
> 
> 1/  the accept socket could take the FIB of the process.
> 2/  the accept socket could take the fib of the incoming SYN packet.
> 
> I chose #1, but it is possible something in changes between 6
> and 7 broke the "chain of custody" for the fib.
> This code is in production in 6.x based systems but was only introduced 
> to FreeBSD in 7.x.
> 
> The process makes a socket which inherits the fib from it.
> The socket includes an INET PCB (Protocol Control Block)
> which gets a copy too..
> when "listen() is called and a syn comes in, a new entry is made in the 
> syncache code and this includes a new connection block which is supposed 
> to inherrit the fib number from the originating listen socket.
> 
> Eventually a new socket is created and it is supposed to inherit teh
> fibnum from the syncache entry, and to copy it to the inpcb attached to it.
> 
> It's possible that somewhere this has been broken by changes.
> but I don't see it right at the moment.
found one place in kern/ipc_socket.c

in sonewconn()
------
         so->so_linger = head->so_linger;
         so->so_state = head->so_state | SS_NOFDREF;
         so->so_proto = head->so_proto;
         so->so_fibnum = head->so_fibnum;  <------  Add this
         so->so_cred = crhold(head->so_cred);
#ifdef MAC
         SOCK_LOCK(head);
         mac_create_socket_from_socket(head, so);
         SOCK_UNLOCK(head);
#endif
--------
and in netinet/tcp_syncache.c
in syncache_socket()

change the following:
------
         inp = sotoinpcb(so);
         inp->inp_inc.inc_fibnum = so->so_fibnum;
         INP_WLOCK(inp);

         /* Insert new socket into PCB hash list. */
------

and see if this helps
(it may not, there may be another code path I'm missing).

> 
> 
> _______________________________________________
> 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"

From julian at elischer.org  Mon Jul 27 20:34:21 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jul 27 20:34:28 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6E0A8B.5000103@sfedu.ru>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>
	<4A6E05EC.8050401@elischer.org> <4A6E0A8B.5000103@sfedu.ru>
Message-ID: <4A6E0F50.1010504@elischer.org>

Oleg Sharoyko wrote:
> 
> Julian Elischer wrote:
> 
>> great.. in your simple server, can you do the sockopt on the socket 
>> AFTER you did the listen()?
>> (just as a test).
> 
> Doesn't help. I have also tried to add setsockopt() after accept() (for 
> a new socket) and in this case the only packet that is being sent out 
> via wrong interface is the SYN+ACK from server.


this is very important. it means I'm not setting the fibnum in the 
syncache code correctly.

> 
> I'll try to look into the kernel code tomorrow and will report any 
> findings.
> 
> -- 
> Oleg

From julian at elischer.org  Mon Jul 27 22:12:51 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jul 27 22:12:57 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6E0A8B.5000103@sfedu.ru>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>
	<4A6E05EC.8050401@elischer.org> <4A6E0A8B.5000103@sfedu.ru>
Message-ID: <4A6E2666.2040906@elischer.org>

Oleg Sharoyko wrote:
> 
> Julian Elischer wrote:
> 
>> great.. in your simple server, can you do the sockopt on the socket 
>> AFTER you did the listen()?
>> (just as a test).
> 
> Doesn't help. I have also tried to add setsockopt() after accept() (for 
> a new socket) and in this case the only packet that is being sent out 
> via wrong interface is the SYN+ACK from server.
> 
> I'll try to look into the kernel code tomorrow and will report any 
> findings.
> 
> -- 
> Oleg


in addition to the patches already sent you might like to add the 
following line to netinet/tcp_input.c

                 }
                 inc.inc_fport = th->th_sport;
                 inc.inc_lport = th->th_dport;
                 inc.inc_fibnum = so->so_fibnum; <-------------
                 /*
                  * Check for an existing connection attempt in 
syncache if
                  * the flag is only ACK.  A successful lookup creates 
a new
                  * socket appended to the listen queue in 
SYN_RECEIVED state.
                  */
From julian at elischer.org  Mon Jul 27 23:24:48 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Jul 27 23:24:55 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6E2666.2040906@elischer.org>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>	<4A6DE356.6040006@elischer.org>
	<4A6DEE30.6000108@sfedu.ru>	<4A6DFFA1.1010709@elischer.org>
	<4A6E0121.2020004@sfedu.ru>	<4A6E05EC.8050401@elischer.org>
	<4A6E0A8B.5000103@sfedu.ru> <4A6E2666.2040906@elischer.org>
Message-ID: <4A6E3743.7050708@elischer.org>

Julian Elischer wrote:
> Oleg Sharoyko wrote:
>>
>> Julian Elischer wrote:
>>
>>> great.. in your simple server, can you do the sockopt on the socket 
>>> AFTER you did the listen()?
>>> (just as a test).
>>
>> Doesn't help. I have also tried to add setsockopt() after accept() 
>> (for a new socket) and in this case the only packet that is being sent 
>> out via wrong interface is the SYN+ACK from server.
>>
>> I'll try to look into the kernel code tomorrow and will report any 
>> findings.
>>
>> -- 
>> Oleg
> 
> 
> in addition to the patches already sent you might like to add the 
> following line to netinet/tcp_input.c
> 
>                 }
>                 inc.inc_fport = th->th_sport;
>                 inc.inc_lport = th->th_dport;
>                 inc.inc_fibnum = so->so_fibnum; <-------------
>                 /*
>                  * Check for an existing connection attempt in syncache if
>                  * the flag is only ACK.  A successful lookup creates a new
>                  * socket appended to the listen queue in SYN_RECEIVED 
> state.
>                  */

in fact you might try just this on its own

> _______________________________________________
> 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"

From os at sfedu.ru  Tue Jul 28 13:38:19 2009
From: os at sfedu.ru (Oleg Sharoyko)
Date: Tue Jul 28 13:38:26 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6E3743.7050708@elischer.org>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>
	<4A6E05EC.8050401@elischer.org> <4A6E0A8B.5000103@sfedu.ru>
	<4A6E2666.2040906@elischer.org>  <4A6E3743.7050708@elischer.org>
Message-ID: <1248788292.71222.10.camel@brain.cc.rsu.ru>


On Mon, 2009-07-27 at 16:24 -0700, Julian Elischer wrote:

> > in addition to the patches already sent you might like to add the 
> > following line to netinet/tcp_input.c
> > 
> >                 }
> >                 inc.inc_fport = th->th_sport;
> >                 inc.inc_lport = th->th_dport;
> >                 inc.inc_fibnum = so->so_fibnum; <-------------
> >                 /*
> >                  * Check for an existing connection attempt in syncache if
> >                  * the flag is only ACK.  A successful lookup creates a new
> >                  * socket appended to the listen queue in SYN_RECEIVED 
> > state.
> >                  */
> 
> in fact you might try just this on its own

With this patch alone all the packets but SYN+ACK are being sent out
correctly. SYN+ACK still uses wrong interface.

ip_output() uses struct inpcb *inp argument to set fib. But when
syncache_respond() sends SYN+ACK, ip_output() is being called without
inp (from netinet/tcp_syncache.c, syncache_respond()):

 error = ip_output(m, sc->sc_ipopts, NULL, 0, NULL, NULL);

It I add
 M_SETFIB(m, sc->sc_inc.inc_fibnum);

before the call to ip_output(), then SYN+ACK goes the right way.

-- 
Oleg Sharoyko.
Software and Network Engineer
Computer Center of Rostov State University.

From julian at elischer.org  Tue Jul 28 15:47:00 2009
From: julian at elischer.org (Julian Elischer)
Date: Tue Jul 28 15:47:07 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <1248788292.71222.10.camel@brain.cc.rsu.ru>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>	
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>	
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>	
	<4A6E05EC.8050401@elischer.org> <4A6E0A8B.5000103@sfedu.ru>	
	<4A6E2666.2040906@elischer.org> <4A6E3743.7050708@elischer.org>
	<1248788292.71222.10.camel@brain.cc.rsu.ru>
Message-ID: <4A6F1D76.7040806@elischer.org>

Oleg Sharoyko wrote:
> On Mon, 2009-07-27 at 16:24 -0700, Julian Elischer wrote:
> 
>>> in addition to the patches already sent you might like to add the 
>>> following line to netinet/tcp_input.c
>>>
>>>                 }
>>>                 inc.inc_fport = th->th_sport;
>>>                 inc.inc_lport = th->th_dport;
>>>                 inc.inc_fibnum = so->so_fibnum; <-------------
>>>                 /*
>>>                  * Check for an existing connection attempt in syncache if
>>>                  * the flag is only ACK.  A successful lookup creates a new
>>>                  * socket appended to the listen queue in SYN_RECEIVED 
>>> state.
>>>                  */
>> in fact you might try just this on its own
> 
> With this patch alone all the packets but SYN+ACK are being sent out
> correctly. SYN+ACK still uses wrong interface.
> 
> ip_output() uses struct inpcb *inp argument to set fib. But when
> syncache_respond() sends SYN+ACK, ip_output() is being called without
> inp (from netinet/tcp_syncache.c, syncache_respond()):
> 
>  error = ip_output(m, sc->sc_ipopts, NULL, 0, NULL, NULL);
> 
> It I add
>  M_SETFIB(m, sc->sc_inc.inc_fibnum);


excellent!

I'll get that checked in!

> 
> before the call to ip_output(), then SYN+ACK goes the right way.
> 

From julian at elischer.org  Tue Jul 28 16:15:13 2009
From: julian at elischer.org (Julian Elischer)
Date: Tue Jul 28 16:15:20 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <1248788292.71222.10.camel@brain.cc.rsu.ru>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>	
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>	
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>	
	<4A6E05EC.8050401@elischer.org> <4A6E0A8B.5000103@sfedu.ru>	
	<4A6E2666.2040906@elischer.org> <4A6E3743.7050708@elischer.org>
	<1248788292.71222.10.camel@brain.cc.rsu.ru>
Message-ID: <4A6F2414.2080203@elischer.org>

Oleg Sharoyko wrote:
> On Mon, 2009-07-27 at 16:24 -0700, Julian Elischer wrote:
> 
>>> in addition to the patches already sent you might like to add the 
>>> following line to netinet/tcp_input.c
>>>
>>>                 }
>>>                 inc.inc_fport = th->th_sport;
>>>                 inc.inc_lport = th->th_dport;
>>>                 inc.inc_fibnum = so->so_fibnum; <-------------
>>>                 /*
>>>                  * Check for an existing connection attempt in syncache if
>>>                  * the flag is only ACK.  A successful lookup creates a new
>>>                  * socket appended to the listen queue in SYN_RECEIVED 
>>> state.
>>>                  */
>> in fact you might try just this on its own
> 
> With this patch alone all the packets but SYN+ACK are being sent out
> correctly. SYN+ACK still uses wrong interface.
> 
> ip_output() uses struct inpcb *inp argument to set fib. But when
> syncache_respond() sends SYN+ACK, ip_output() is being called without
> inp (from netinet/tcp_syncache.c, syncache_respond()):
> 
>  error = ip_output(m, sc->sc_ipopts, NULL, 0, NULL, NULL);
> 
> It I add
>  M_SETFIB(m, sc->sc_inc.inc_fibnum);
> 
> before the call to ip_output(), then SYN+ACK goes the right way.
> 

ok so here's my final patch.
This is taken against -current. so it may not patch exactly cleanly.

it's not quite minimal as I'm cleaning up something too, but
could you check it works?

if you have ipv6 it might be nice to check that ipv6 doesn't crash
with this patch too (ipv6 doesn't support Multiple routing tables
yet).

-------------- next part --------------
Index: sys/kern/uipc_socket.c
===================================================================
--- sys/kern/uipc_socket.c	(revision 195859)
+++ sys/kern/uipc_socket.c	(working copy)
@@ -438,6 +438,7 @@
 	so->so_options = head->so_options &~ SO_ACCEPTCONN;
 	so->so_linger = head->so_linger;
 	so->so_state = head->so_state | SS_NOFDREF;
+	so->so_fibnum = head->so_fibnum;
 	so->so_proto = head->so_proto;
 	so->so_cred = crhold(head->so_cred);
 #ifdef MAC
Index: sys/netinet/tcp_input.c
===================================================================
--- sys/netinet/tcp_input.c	(revision 195859)
+++ sys/netinet/tcp_input.c	(working copy)
@@ -758,6 +758,7 @@
 		}
 		inc.inc_fport = th->th_sport;
 		inc.inc_lport = th->th_dport;
+		inc.inc_fibnum = so->so_fibnum;
 
 		/*
 		 * Check for an existing connection attempt in syncache if
Index: sys/netinet/tcp_syncache.c
===================================================================
--- sys/netinet/tcp_syncache.c	(revision 195859)
+++ sys/netinet/tcp_syncache.c	(working copy)
@@ -642,8 +642,7 @@
 #endif
 
 	inp = sotoinpcb(so);
-	inp->inp_inc.inc_fibnum = sc->sc_inc.inc_fibnum;
-	so->so_fibnum = sc->sc_inc.inc_fibnum;
+	inp->inp_inc.inc_fibnum = so->so_fibnum;
 	INP_WLOCK(inp);
 
 	/* Insert new socket into PCB hash list. */
@@ -1128,8 +1127,6 @@
 	sc->sc_cred = cred;
 	cred = NULL;
 	sc->sc_ipopts = ipopts;
-	/* XXX-BZ this fib assignment is just useless. */
-	sc->sc_inc.inc_fibnum = inp->inp_inc.inc_fibnum;
 	bcopy(inc, &sc->sc_inc, sizeof(struct in_conninfo));
 #ifdef INET6
 	if (!(inc->inc_flags & INC_ISIPV6))
@@ -1403,6 +1400,7 @@
 	} else
 		optlen = 0;
 
+	M_SETFIB(m, sc->sc_inc.inc_fibnum);
 #ifdef INET6
 	if (sc->sc_inc.inc_flags & INC_ISIPV6) {
 		th->th_sum = 0;
From os at sfedu.ru  Tue Jul 28 16:18:15 2009
From: os at sfedu.ru (Oleg Sharoyko)
Date: Tue Jul 28 16:18:22 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6F1D76.7040806@elischer.org>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>	
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>	
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>	
	<4A6E05EC.8050401@elischer.org> <4A6E0A8B.5000103@sfedu.ru>	
	<4A6E2666.2040906@elischer.org> <4A6E3743.7050708@elischer.org>
	<1248788292.71222.10.camel@brain.cc.rsu.ru>
	<4A6F1D76.7040806@elischer.org>
Message-ID: <4A6F24BB.7050907@sfedu.ru>

Julian Elischer wrote:

> I'll get that checked in!

Please, also take a look at

_syncache_add() in tcp_syncache.c

There is some code which looks strange, at least at first sight. Won't 
bcopy() overwrite assigned value of sc->sc_inc.inc_fibnum ?

         /* XXX-BZ this fib assignment is just useless. */
         sc->sc_inc.inc_fibnum = inp->inp_inc.inc_fibnum;
         bcopy(inc, &sc->sc_inc, sizeof(struct in_conninfo));

--
Oleg
From julian at elischer.org  Tue Jul 28 16:20:00 2009
From: julian at elischer.org (Julian Elischer)
Date: Tue Jul 28 16:20:07 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6F24BB.7050907@sfedu.ru>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>	
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>	
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>	
	<4A6E05EC.8050401@elischer.org> <4A6E0A8B.5000103@sfedu.ru>	
	<4A6E2666.2040906@elischer.org> <4A6E3743.7050708@elischer.org>
	<1248788292.71222.10.camel@brain.cc.rsu.ru>
	<4A6F1D76.7040806@elischer.org> <4A6F24BB.7050907@sfedu.ru>
Message-ID: <4A6F2533.4050007@elischer.org>

Oleg Sharoyko wrote:
> Julian Elischer wrote:
> 
>> I'll get that checked in!
> 
> Please, also take a look at
> 
> _syncache_add() in tcp_syncache.c
> 
> There is some code which looks strange, at least at first sight. Won't 
> bcopy() overwrite assigned value of sc->sc_inc.inc_fibnum ?
> 
>         /* XXX-BZ this fib assignment is just useless. */
>         sc->sc_inc.inc_fibnum = inp->inp_inc.inc_fibnum;
>         bcopy(inc, &sc->sc_inc, sizeof(struct in_conninfo));

the bcopy just writes teh same vlue in again

I've removed this in the patch.

> 
> -- 
> Oleg

From qing.li at bluecoat.com  Tue Jul 28 17:24:53 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Tue Jul 28 17:25:05 2009
Subject: multicast transmission (was: CARP broken on -CURRENT?)
In-Reply-To: <4A61544E.2050208@delphij.net>
References: <4A5F8010.7050504@delphij.net><4A5F7540.7070201@delphij.net>	<4A5EF889.6040604@delphij.net><E1MRNt8-0004so-2J@clue.co.za>	<E1MRWFf-0005Xt-P8@clue.co.za><E1MRYA8-0005df-D6@clue.co.za>
	<4A61544E.2050208@delphij.net>
Message-ID: <B583FBF374231F4A89607B4D08578A4304D42FEE@bcs-mail03.internal.cacheflow.com>

The problem appears to be contained in ether_output().
A slightly modified version of Xin's patch has been committed.
Please sync to r195921.

Please let us know if the patch resolves your issues and report
new problems if any.

Thanks,

-- Qing


> -----Original Message-----
> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-
> current@freebsd.org] On Behalf Of Xin LI
> Sent: Friday, July 17, 2009 9:49 PM
> To: Ian FREISLICH
> Cc: FreeBSD Current; d@delphij.net
> Subject: Re: CARP broken on -CURRENT?
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I got it.  It was the cached llentry that preventing ether_output() to
> choose the right broadcast/multicast address and use the default
> gateway's L2 address.  Here is a proposed patch.
> 
> Cheers,
> - --
> Xin LI <delphij@delphij.net>	http://www.delphij.net/
> FreeBSD - The Power to Serve!
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.12 (FreeBSD)
> 
> iEYEARECAAYFAkphVE0ACgkQi+vbBBjt66CghgCeOeqa4vLb+oW1qiZCKAggSdKM
> O7wAoIF/JL1DNQ/EcuOi8TkNPofJyGLN
> =hP2w
> -----END PGP SIGNATURE-----
From os at sfedu.ru  Tue Jul 28 20:15:10 2009
From: os at sfedu.ru (Oleg Sharoyko)
Date: Tue Jul 28 20:15:17 2009
Subject: Wrong outgoing interface with multiple routing tables
In-Reply-To: <4A6F2414.2080203@elischer.org>
References: <1248704237.96833.127.camel@brain.cc.rsu.ru>	
	<4A6DE356.6040006@elischer.org> <4A6DEE30.6000108@sfedu.ru>	
	<4A6DFFA1.1010709@elischer.org> <4A6E0121.2020004@sfedu.ru>	
	<4A6E05EC.8050401@elischer.org> <4A6E0A8B.5000103@sfedu.ru>	
	<4A6E2666.2040906@elischer.org> <4A6E3743.7050708@elischer.org>
	<1248788292.71222.10.camel@brain.cc.rsu.ru>
	<4A6F2414.2080203@elischer.org>
Message-ID: <4A6F5C41.3050009@sfedu.ru>


Julian Elischer wrote:

> ok so here's my final patch.
> This is taken against -current. so it may not patch exactly cleanly.
> 
> it's not quite minimal as I'm cleaning up something too, but
> could you check it works?

Works with 7.2. Thanks!

> if you have ipv6 it might be nice to check that ipv6 doesn't crash
> with this patch too (ipv6 doesn't support Multiple routing tables
> yet).

It took me some time to setup a test IPv6 network and it also works, no 
crashes with v6 here.

--
Oleg

From bob at veznat.com  Tue Jul 28 21:52:56 2009
From: bob at veznat.com (Bob Van Zant)
Date: Tue Jul 28 21:53:03 2009
Subject: IPv6 traffic between two hosts not flowing
In-Reply-To: <4A69395B.4020604@elischer.org>
Message-ID: <C694C144.37036%bob@veznat.com>

The problem ended up being a semi-broken em (yes, em, bge wasn't the problem
like I originally thought) driver in 6.2. The driver wasn't bringing in
ethernet multicast frames (required for ndp to work) and without ndp things
weren't working. If the interface was put into promiscuous mode for a few
seconds ndp could take place and everything worked fine.

Upgrading the kernel to 6.3 made the problem go away.

Just in case it's useful to anyone, these are the 3 em devices I had on this
machine (a Dell 2850):

em0@pci6:7:0:    class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05
hdr=0x00
em1@pci7:8:0:    class=0x020000 card=0x016d1028 chip=0x10768086 rev=0x05
hdr=0x00
em2@pci9:4:0:    class=0x020000 card=0x10028086 chip=0x10268086 rev=0x04
hdr=0x00

em2 was the only device functioning properly on 6.2.

-Bob





On 7/23/09 9:32 PM, "Julian Elischer" <julian@elischer.org> wrote:

> Bob Van Zant wrote:
>> I have 2 FreeBSD machines each with 3 ethernet interfaces each with an IPv6
>> address.
>> 
>> Here's a table showing how the two machines are connected. To try to blame
>> the switch or its configuration I have tried directly connecting the
>> machines. The results were the same.
>> 
>> 6.3                    4948             6.2
>> ---                    ----             ---
>> fxp0                                  em2
>> fc00:dada::47                         fc00:dada::2
>> 
>> bge0                                  em0
>> fc00:dada:1::47                       fc00:dada:1::2
>> 
>> bge1                                  em1
>> fc00:dada:2::47                       fc00:dada:2::2
>> 
>> Traffic from fxp0 to em2 works fine.
>> bge0 to em0 and bge1 to em1 doesn't work as I'll explain below and is the
>> reason I'm writing to the list.
>> 
>> 
>> This host is able to communicate with it's IPv6 neighbor over the fxp0
>> interface, however, neither of the bge interfaces are able to communicate
>> with their peers.
>> 
>> ndp(8) output on the 6.3 machine (with bge interfaces) seems to highlight
>> something weird. In addition to the errors occurring, the Netif column for
>> fc00:dada:1::47 shows fxp0. ifconfig shows that address on bge0. The same is
>> true for fc00:dada:2::47; in ndp it shows up on fxp0 but ifconfig thinks
>> it's on bge1 (it should be). The linklayer address being "(incomplete)" also
>> seems weird given that this is a normal ethernet interface on the local
>> machine.
> 
> I'm going to guess that if the other connections were disconnected,
> the 2nd and 3rd pairs would work.
> 
> I'm also guessing that if you closely look at the data between the 2nd
> and 3rd pairs you will somewhere see the addresses of the first pair
> in there. FreeBSD has often suffered when trying to run connections in
> parallel, even in IPV4.
> 
> I believe this has been fixed in 8.x to some extent..
> 
> 
> 
>> 
>> 
>> $ ndp -an
>> Neighbor                             Linklayer Address  Netif Expire    S
>> Flags
>> fc00:dada::2                         0:e:c:b4:13:8f      fxp0 22h38m10s S R
>> fc00:dada::47                        0:2:b3:e7:4a:56     fxp0 permanent R
>> ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument
>> ndp: failed to get neighbor information
>> fc00:dada:1::47                      (incomplete)        fxp0
>> ndp: ioctl(SIOCGNBRINFO_IN6): Invalid argument
>> ndp: failed to get neighbor information
>> fc00:dada:2::47                      (incomplete)        fxp0
>> fe80::20d:56ff:fe70:a9ae%bge0        0:d:56:70:a9:ae     bge0 permanent R
>> fe80::20d:56ff:fe70:a9af%bge1        0:d:56:70:a9:af     bge1 permanent R
>> fe80::202:b3ff:fee7:4a56%fxp0        0:2:b3:e7:4a:56     fxp0 permanent R
>> 
>> 
>> Output from ifmcstat looks correct to me (mostly the same as fxp0 but with
>> the appropriate addresses different).
>> 
>> I did find this message in the logfile at least once:
>> 
>>     nd6_storelladdr: sdl_alen == 0
>> 
>> 
>> If I do a ping6 in between the two hosts and then run tcpdump on either of
>> the bge interfaces I can see neighbor discovery traffic going back and
>> forth.
> 
> but not correct probably or it would be stored in the Link Level tables.
> 
>> 
>> If the ping is from the bge interface to the corresponding em interface then
>> all I ever see is the NDP traffic.
>> 
>> If the ping is from the em interface to the corresponding bge interface then
>> I see a normal solicitation and advertisement followed by ICMP echo requests
>> (there are never any replies). The 6.2 machine's ndp cache looks correct.
>> The 6.3 machine's ndp cache is the one pasted above.
>> 
>> 
>> I feel like I'm just rambling here and not necessarily putting together a
>> sane question. If this is making sense to anyone and it isn't immediately
>> obvious what's going on please ask me some follow up questions.
>> 
>> In addition to all of this, after what appears to be about an hour of
>> sending ping packets that go nowhere and pulling interfaces in and out of
>> promiscuous mode (tcpdump) the system appears to deadlock. I don't have any
>> proof that it's deadlock other than a completely unresponsive box that needs
>> to have the power cable removed. It's happened twice so far this afternoon.
>> 
>> Thanks for reading this far,
> 
> if you had an 8.x image, you might try it there..
> and a 6.2<->6.2 and 6.3<->6.3 boot as well
> probably the person you want to actually speak with is Qing Li
> 
>> 
>> Bob
>> 
>> 
>> _______________________________________________
>> 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"
> 
> _______________________________________________
> 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"


From linimon at FreeBSD.org  Wed Jul 29 01:55:47 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Jul 29 01:55:59 2009
Subject: kern/137170: [ath] atheros AR9285 not recognised
Message-ID: <200907290155.n6T1tlwp053305@freefall.freebsd.org>

Old Synopsis: atheros AR9285 not recognised
New Synopsis: [ath] atheros AR9285 not recognised

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Jul 29 01:55:24 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=137170
From ap00 at mail.ru  Wed Jul 29 10:29:28 2009
From: ap00 at mail.ru (Anthony Pankov)
Date: Wed Jul 29 10:29:35 2009
Subject: TCP initial window size
Message-ID: <98265976953.20090729141708@mail.ru>


Can anybody explain me about initial TCP window sent to the client (in syn/ack packet),
please.

Is it unmanageable and always set to net.inet.tcp.recvspace?

(Due to use of syncache and syncache code is (tcp_syncache.c):
        /* Initial receive window: clip sbspace to [0 .. TCP_MAXWIN] */
        win = sbspace(&so->so_rcv);
        win = imax(win, 0);
        win = imin(win, TCP_MAXWIN);
        sc->sc_wnd = win;
)

If it is, then what bad things will happen if i replace code above by
code like this:

if (tcp_do_rfc3390)
  sc->sc_wnd = min(4*(sc->sc_peer_mss ? sc->sc_peer_mss:tcp_mssdflt ),
                   max(2 * (sc->sc_peer_mss ? sc->sc_peer_mss:tcp_mssdflt), 4380));
else
  sc->sc_wnd = (sc->sc_peer_mss ? sc->sc_peer_mss:tcp_mssdflt) * ss_fltsz;


Also, does local connection use syncache?


System: FreeBSD 6.2-RELEASE-p9

-- 
Best regards,
 Anthony                          mailto:ap00@mail.ru


From wjw at digiware.nl  Wed Jul 29 10:44:33 2009
From: wjw at digiware.nl (Willem Jan Withagen)
Date: Wed Jul 29 10:44:40 2009
Subject: R: IPv6 and ipfw
In-Reply-To: <11956F97-0C87-456F-A769-70BEDBA351BE@libero.it>
References: <3164304.442981248256119643.JavaMail.defaultUser@defaultHost>
	<4A672C79.3000006@digiware.nl>
	<11956F97-0C87-456F-A769-70BEDBA351BE@libero.it>
Message-ID: <4A702885.5080803@digiware.nl>

Raffaele De Lorenzo wrote:
> Hi all,
> I attached a patch that solve this problem. I will send a PR as soon as 
> possible.
> 
> Instructions:
> 
> Patch the follow files:
> 
> /usr/src/sbin/ipfw/ipfw2.c (patch is ipfw2.c.diff)
> /usr/src/sbin/ipfw/ipfw2.h (patch is ipfw2.h.diff)
> /usr/src/sbin/ipfw/ipv6.c (patch is ipv6.c.diff)
> 
> This patch was tested on FreeBSD 8 Beta 2 AMD64 and official FreeBSD 8 
> BETA 2 Sources.
> 
> Let me know any suggestion or problem.

Patch worked fine on 7.2-stable as well.
Multiple ipv6 addresses are now accepted in one go.

But it still does not really works as well as I would like ;):

ipfw add 11101 allow udp from any to 192.168.10.67,2001:dddd:c::67 dst-port 
45457 keep-state
ipfw: bad netmask ``dddd:c::67''

Which from your comment seems correct:
+ * Pre-Check multi address rules to avoid parser confusion about IPv4/IPv6 
addresses.
+ * XXX I assume the first know address is the reference address (You cannot 
use both IPv4/IPv6 addresses inside
+ * a multi-addresses rule).

But looking at the code, why not fist parse chunks seperated by ',' and then 
test them for all possible variants, because as far as I understand there 
are no ',''s allowed in the adresspec.

Thanx for the work thusfar,

--WjW
From tuexen at freebsd.org  Wed Jul 29 16:26:16 2009
From: tuexen at freebsd.org (Michael Tuexen)
Date: Wed Jul 29 16:27:06 2009
Subject: mld_mtx lock order reversal
Message-ID: <30F5F8DF-111B-4931-8AA3-DDD18B3A5AB9@freebsd.org>

Dear all,

when doing a
ifconfig gif0 down
ifconfig gif0 -tunnel
ifconfig gif0 destroy
I got a the following message on the last command.
Is this a false positive?

Best regards
Michael

--- syscall (304, FreeBSD ELF64, kldload), rip = 0x8006923ac, rsp =  
0x7fffffffed38, rbp = 0 ---
lock order reversal:
  1st 0xffffff0002995bc8 if_afdata (if_afdata) @ net/if.c:830
  2nd 0xffffffff80de59c0 mld_mtx (mld_mtx) @ netinet6/mld6.c:570
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_mtx_lock_flags() at _mtx_lock_flags+0x78
mld_domifdetach() at mld_domifdetach+0x24
in6_domifdetach() at in6_domifdetach+0x11
if_detach() at if_detach+0x6ed
gif_clone_destroy() at gif_clone_destroy+0xda
ifc_simple_destroy() at ifc_simple_destroy+0x2a
if_clone_destroyif() at if_clone_destroyif+0xc0
ifioctl() at ifioctl+0x6f5
kern_ioctl() at kern_ioctl+0xc5
ioctl() at ioctl+0xfd
syscall() at syscall+0x1af
Xfast_syscall() at Xfast_syscall+0xe1

From merketing.e at email.it  Wed Jul 29 19:46:42 2009
From: merketing.e at email.it (M. Lorona)
Date: Wed Jul 29 19:46:59 2009
Subject: Richiesta
Message-ID: <20090729192219.6374310A355@davidovitch.com>

<html>
<TABLE>
<TR>
<TD>
<b>SOFTWARE PER L' EMAIL-MARKETING</b>
</TD>
</TR>
<tr><td><hr></td></tr>
<TR><TD>
<LI>Software che estrapola dati dalle Pagine Gialle e Bianche.<br>
<LI>Software per creare le email info@ da ricerche on line su motori
<li>Software Gestionale per inviare newsletter
<li>800 server smtp per inviare le tue newsletter (10.000 per ora)<br>
ps: il servizio smtp non ? soggetto a sospensioni del servizio per segnalazione di terzi.<br>
Creare appuntamenti inbound in poco tempo si pu?, cosa aspetti, noi ti diamo gli strumenti.
</td>
</tr>
<tr><td><hr></td></tr>
<tr>
<td>
se sei interessato all'acquisto clicca il link sottostante.
</TD></TR>
<tr>
<td bgcolor=green height=1></td></tr>
<tr>
<td align=center><a href="mailto:email.marketing.spa@gmail.com?subject=Richiesta info&Body=Indichi:%0ARagione%20Sociale%0ANome%0ACogome%0ATelefono%0Aquanti%20venditori%20lavorano%20per%20voi"><b>Clicca per ulteriori chiarimenti</b></a></td></tr>
<td bgcolor=green height=1></td></tr>
<tr><td>Se non riesci ad aprire il link scrivi una e-mail email.marketing.spa@gmail.com</td></tr>
From bms at incunabulum.net  Thu Jul 30 01:26:16 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu Jul 30 01:26:23 2009
Subject: mld_mtx lock order reversal
In-Reply-To: <30F5F8DF-111B-4931-8AA3-DDD18B3A5AB9@freebsd.org>
References: <30F5F8DF-111B-4931-8AA3-DDD18B3A5AB9@freebsd.org>
Message-ID: <4A70F65D.1040201@incunabulum.net>

Michael Tuexen wrote:
> Dear all,
>
> when doing a
> ifconfig gif0 down
> ifconfig gif0 -tunnel
> ifconfig gif0 destroy
> I got a the following message on the last command.
> Is this a false positive?

See comments in mld6.c.

Some LOR warnings are unavoidable at the moment because of INET6 
locking; the worst culprit is the SCOPE6 lock.

Unfortunately I can't do anything about this right now. The LORs 
themselves should be pretty benign.

From killing at multiplay.co.uk  Thu Jul 30 20:15:05 2009
From: killing at multiplay.co.uk (Steven Hartland)
Date: Thu Jul 30 20:15:25 2009
Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
References: <200906011450.n51Eo3Wp095320@freefall.freebsd.org>
Message-ID: <5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk>

Anyone point me in the right direction on how to add the phy to support
these machine?

Seems like its just a matter of adding the PHY details to miidevs but how
do I find out the specifics of that?

    Regards
    Steve

----- Original Message ----- 
From: "DutchDaemon" <freebsd@bengrimm.net>


> The following reply was made to PR kern/134658; it has been noted by GNATS.
> 
> From: DutchDaemon <freebsd@bengrimm.net>
> To: bug-followup@FreeBSD.org, harald_jensas@dell.com
> Cc:  
> Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
> Date: Mon, 01 Jun 2009 16:21:59 +0200
> 
> http://forums.freebsd.org/showthread.php?t=3804


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From delphij at delphij.net  Thu Jul 30 21:42:52 2009
From: delphij at delphij.net (Xin LI)
Date: Thu Jul 30 21:42:59 2009
Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
In-Reply-To: <5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk>
References: <200906011450.n51Eo3Wp095320@freefall.freebsd.org>
	<5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk>
Message-ID: <4A721381.2060602@delphij.net>

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

Hi, Steven,

Try this patch:

	http://people.freebsd.org/~delphij/misc/bce-5709phy.diff

(You need to rebuild the whole kernel)

Another thing that may need attention:
	http://www.mavetju.org/mail/view_message.php?list=freebsd-drivers&id=2977317

Steven Hartland wrote:
> Anyone point me in the right direction on how to add the phy to support
> these machine?
> 
> Seems like its just a matter of adding the PHY details to miidevs but how
> do I find out the specifics of that?
> 
>    Regards
>    Steve
> 
> ----- Original Message ----- From: "DutchDaemon" <freebsd@bengrimm.net>
> 
> 
>> The following reply was made to PR kern/134658; it has been noted by
>> GNATS.
>>
>> From: DutchDaemon <freebsd@bengrimm.net>
>> To: bug-followup@FreeBSD.org, harald_jensas@dell.com
>> Cc:  Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge
>> m610 blade.
>> Date: Mon, 01 Jun 2009 16:21:59 +0200
>>
>> http://forums.freebsd.org/showthread.php?t=3804
> 
> 
> ================================================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and
> the person or entity to whom it is addressed. In the event of
> misdirection, the recipient is prohibited from using, copying, printing
> or otherwise disseminating it or any information contained in it.
> In the event of misdirection, illegible or incomplete transmission
> please telephone +44 845 868 1337
> or return the E.mail to postmaster@multiplay.co.uk.
> 
> _______________________________________________
> 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"


- --
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)

iEYEARECAAYFAkpyE4EACgkQi+vbBBjt66CVzACfUvBEXu06kGoJfnUwYDnOYU9q
/U8Anj8tPvqDniFUtr8SZEpS188jDyDv
=I5zq
-----END PGP SIGNATURE-----
From linimon at FreeBSD.org  Fri Jul 31 04:45:09 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Fri Jul 31 04:45:21 2009
Subject: kern/137279: [bge] [panic] Page fault (fatal trap 12) NFS
	server w/Broadcom BCM5704
Message-ID: <200907310445.n6V4j8eS088559@freefall.freebsd.org>

Old Synopsis: Page fault (fatal trap 12) NFS server w/Broadcom BCM5704
New Synopsis: [bge] [panic] Page fault (fatal trap 12) NFS server w/Broadcom BCM5704

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jul 31 04:44:05 UTC 2009
Responsible-Changed-Why: 
seems to be in the bge_intr routine.

http://www.freebsd.org/cgi/query-pr.cgi?pr=137279
From killing at multiplay.co.uk  Fri Jul 31 08:47:09 2009
From: killing at multiplay.co.uk (Steven Hartland)
Date: Fri Jul 31 08:47:16 2009
Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
References: <200906011450.n51Eo3Wp095320@freefall.freebsd.org>
	<5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk>
	<4A721381.2060602@delphij.net>
Message-ID: <7F616135EE574E40A8F88E643FA744A3@multiplay.co.uk>

This already appears to be in the 8.0 BETA2 source that we are running,
no go :(

    Regards
    Steve

----- Original Message ----- 
From: "Xin LI" <delphij@delphij.net>
To: "Steven Hartland" <killing@multiplay.co.uk>
Cc: "DutchDaemon" <freebsd@bengrimm.net>; <freebsd-net@FreeBSD.org>
Sent: Thursday, July 30, 2009 10:41 PM
Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, Steven,
> 
> Try this patch:
> 
> http://people.freebsd.org/~delphij/misc/bce-5709phy.diff
> 
> (You need to rebuild the whole kernel)
> 
> Another thing that may need attention:
> http://www.mavetju.org/mail/view_message.php?list=freebsd-drivers&id=2977317


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.

From Hartmut.Brandt at dlr.de  Fri Jul 31 14:09:34 2009
From: Hartmut.Brandt at dlr.de (Hartmut.Brandt@dlr.de)
Date: Fri Jul 31 14:09:41 2009
Subject: TCP RST question
Message-ID: <E086A96846579E4F932C168218DB1E550243BA@exbe5.intra.dlr.de>

Hi all,

I'm looking at our TCP stack and found a change that was introduced with
the syncache. The original BSD code did send an RST segment when the
connection timed out in SYN-RECEIVED. The TCP would retransmit the
SYN+ACK several times and then give up and RST the peer.

With syncache, however, our TCP doesn't send the RST anymore. It just
silently discards local state.

So the question is whether TCP is supposed to RST or not. Looking at
RFC793 I found nothing useful. It talks about sending RSTs as response
to incoming segments and it looks like TCP is never supposed to give up
retransmitting. The state diagram has no line from SYN-RECEIVED to
CLOSED. Stevens, on the other hand, has this line and it is labeled
'send: RST'.

So the questions are:

 - is TCP supposed to send an RST when it times out in SYN-RECEIVED?
 - why was this changed (I suppose it is just one of the regressions
introduced with the syn-cache).

harti

NB: does anybody know a good mailing list where this kind of questions
can be discussed?
From linimon at FreeBSD.org  Fri Jul 31 16:09:05 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Fri Jul 31 16:09:23 2009
Subject: kern/137309: [ipsec] sequence number in a SADB_X_SPDGET
	response is set to zero
Message-ID: <200907311609.n6VG95MU036316@freefall.freebsd.org>

Synopsis: [ipsec] sequence number in a SADB_X_SPDGET response is set to zero

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jul 31 16:08:55 UTC 2009
Responsible-Changed-Why: 

Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=137309
From julian at elischer.org  Fri Jul 31 16:41:38 2009
From: julian at elischer.org (Julian Elischer)
Date: Fri Jul 31 16:41:45 2009
Subject: TCP RST question
In-Reply-To: <E086A96846579E4F932C168218DB1E550243BA@exbe5.intra.dlr.de>
References: <E086A96846579E4F932C168218DB1E550243BA@exbe5.intra.dlr.de>
Message-ID: <4A731B5F.6060301@elischer.org>

Hartmut.Brandt@dlr.de wrote:
> Hi all,
> 
> I'm looking at our TCP stack and found a change that was introduced with
> the syncache. The original BSD code did send an RST segment when the
> connection timed out in SYN-RECEIVED. The TCP would retransmit the
> SYN+ACK several times and then give up and RST the peer.
> 
> With syncache, however, our TCP doesn't send the RST anymore. It just
> silently discards local state.
> 
> So the question is whether TCP is supposed to RST or not. Looking at
> RFC793 I found nothing useful. It talks about sending RSTs as response
> to incoming segments and it looks like TCP is never supposed to give up
> retransmitting. The state diagram has no line from SYN-RECEIVED to
> CLOSED. Stevens, on the other hand, has this line and it is labeled
> 'send: RST'.
> 
> So the questions are:
> 
>  - is TCP supposed to send an RST when it times out in SYN-RECEIVED?
>  - why was this changed (I suppose it is just one of the regressions
> introduced with the syn-cache).

maybe something to do with avoiding DOS or something?

> harti
> 
> NB: does anybody know a good mailing list where this kind of questions
> can be discussed?
> _______________________________________________
> 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"

From Michael.Tuexen at lurchi.franken.de  Fri Jul 31 21:41:45 2009
From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=)
Date: Fri Jul 31 21:41:53 2009
Subject: TCP RST question
In-Reply-To: <E086A96846579E4F932C168218DB1E550243BA@exbe5.intra.dlr.de>
References: <E086A96846579E4F932C168218DB1E550243BA@exbe5.intra.dlr.de>
Message-ID: <FBF62984-6610-43E9-A3A9-6B57A1CFE341@lurchi.franken.de>

On Jul 31, 2009, at 3:57 PM, <Hartmut.Brandt@dlr.de> <Hartmut.Brandt@dlr.de 
 > wrote:

> Hi all,
>
> I'm looking at our TCP stack and found a change that was introduced  
> with
> the syncache. The original BSD code did send an RST segment when the
> connection timed out in SYN-RECEIVED. The TCP would retransmit the
> SYN+ACK several times and then give up and RST the peer.
>
> With syncache, however, our TCP doesn't send the RST anymore. It just
> silently discards local state.
>
> So the question is whether TCP is supposed to RST or not. Looking at
> RFC793 I found nothing useful. It talks about sending RSTs as response
> to incoming segments and it looks like TCP is never supposed to give  
> up
> retransmitting. The state diagram has no line from SYN-RECEIVED to
> CLOSED. Stevens, on the other hand, has this line and it is labeled
> 'send: RST'.
>
> So the questions are:
>
> - is TCP supposed to send an RST when it times out in SYN-RECEIVED?
> - why was this changed (I suppose it is just one of the regressions
> introduced with the syn-cache).
>
> harti
>
> NB: does anybody know a good mailing list where this kind of questions
> can be discussed?
tsvwg@ietf.org
tcpm@ietf.org

Best reagrds
Michael
> _______________________________________________
> 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"
>

From linimon at FreeBSD.org  Fri Jul 31 23:52:16 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Fri Jul 31 23:52:28 2009
Subject: kern/137317: [tcp] logs full of syncache problems
Message-ID: <200907312352.n6VNqEge015819@freefall.freebsd.org>

Old Synopsis: logs full of syncache problems
New Synopsis: [tcp] logs full of syncache problems

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jul 31 23:51:52 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=137317