date:20090226

Re: NATT patch and FreeBSD's setkey

2009-02-26 Thread VANHULLEBUS Yvan

On Tue, Feb 17, 2009 at 02:41:41PM +, Bjoern A. Zeeb wrote:
[...]
> I am not going to find my posting from a few years back but the
> solution is to keep the kernel and libipsec (and setkey) in base in
> sync and not install libipsec and setkey from the ipsec-tools port.
> Done.

There are two drawbacks with this solution:

- It will take some regular effort to sync those version, unless we do
  have "some automated way to do it" (something like the mechanism
  used for /usr/ports ?).

- if we just have a copy of sources in FreeBSD's tree, someone may
  commit something, then someone else (or a script) may just overwrite
  the changes, as it is supposed to be "just a copy".

But if we can deal with those issues, of course, having the up to date
versions directly shipped with FreeBSD is better !

[]
> We have about 3 months left to get that patch in for 8; ideally 6
> weeks.  Can you update the nat-t patch in a way as discussed here
> before so that the extra address is in etc. and we can move forward?

Done, new version is available here:
http://people.freebsd.org/~vanhu/NAT-T/experimental/patch-FreeBSD-TRUNK-NATT-pfkey-clean-2009-02-26.diff

> I basically do not care if racoon from ipsec-tools is not going to
> work for two weeks of HEAD or four as someone will quickly add a
> conditional patch to the port for a __FreeBSD_version > 8x and
> that can be removed once ipsec-tools properly detect the state of the
> system.

Things will continue working as soon as people compile without NAT-T.
When compiling with NAT-T, we will need to have "old FreeBSD+patch and
old ipsec-tools" or "FreeBSd with new NAT-T code and up to date
(actually even not in HEAD) racoon".

For people who may ask the question, when NAT-T+pfkey cleanup code
will be no more experimental, I'll backport a patchset at least for
FreeBSD 7.x.

Yvan.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FreeBSD Router Problem

2009-02-26 Thread Shawn Everett

Sorry I meant to say FreeBSD 7.0 :)

> Hi Guys,
>
> Here's a weird one...  I set up FreeBSD 5.2 to act as a router.  I used
> the pf.conf script shown at:
> http://www.openbsd.org/faq/pf/pools.html#outgoing
>
> Everything works just fine.  Traffic is appropriately load balanced and
> things work as expected.
>
> Strangely after a few hours something just stops routing traffic.  I can't
> ping the remote gateways either.  Both external interfaces still show the
> correct IP addresses.  Rebooting the BSD box solves the problem.  Nothing
> else gets rebooted.
>
> Any suggestions would be appreciated.
>
> Shawn
>


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

Re: FreeBSD Router Problem

2009-02-26 Thread Adrian Penisoara

Hi,

On Fri, Feb 27, 2009 at 1:06 AM, Shawn Everett  wrote:

> Sorry I meant to say FreeBSD 7.0 :)
>
> > Hi Guys,
> >
> > Here's a weird one...  I set up FreeBSD 5.2 to act as a router.  I used
> > the pf.conf script shown at:
> > http://www.openbsd.org/faq/pf/pools.html#outgoing
> >
> > Everything works just fine.  Traffic is appropriately load balanced and
> > things work as expected.
> >
> > Strangely after a few hours something just stops routing traffic.  I
> can't
> > ping the remote gateways either.  Both external interfaces still show the
> > correct IP addresses.  Rebooting the BSD box solves the problem.  Nothing
> > else gets rebooted.

 Any error messages in dmesg output ?
 Significant changes in "netstat -m" output before and after ?
 The same for "pfctl -s all" output...

>
> >
> > Any suggestions would be appreciated.

Try tcpdump'ing on the router's interfaces an on the source machine and
compare the packet flows -- do the packets reach the router ? Do they
attempt to pass to the outside ?

Regards,
Adrian.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

FreeBSD Router Problem

2009-02-26 Thread Shawn Everett

Hi Guys,

Here's a weird one...  I set up FreeBSD 5.2 to act as a router.  I used
the pf.conf script shown at:
http://www.openbsd.org/faq/pf/pools.html#outgoing

Everything works just fine.  Traffic is appropriately load balanced and
things work as expected.

Strangely after a few hours something just stops routing traffic.  I can't
ping the remote gateways either.  Both external interfaces still show the
correct IP addresses.  Rebooting the BSD box solves the problem.  Nothing
else gets rebooted.

Any suggestions would be appreciated.

Shawn

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

Re: FreeBSD Router Problem

2009-02-26 Thread Chuck Swiger


On Feb 26, 2009, at 3:43 PM, Shawn Everett wrote:

Here's a weird one...  I set up FreeBSD 5.2 to act as a router.

[ ... ]


Any suggestions would be appreciated.


Try upgrading to a supported version of the OS, first, then work on  
debugging any deadlocks if they still reoccur.


Early 5.x versions were a little rocky.  I seem to recall that 5.2  
would experience deadlocks against ATA harddrives that would cause a  
system lockup, and that a errata release (5.2.1) was quickly put out  
to help fix those issues.  6.4 is much more stable by comparison...


Regards,
--
-Chuck

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

Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025)

2009-02-26 Thread Boris Kochergin

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

From: Boris Kochergin 
To: bug-follo...@freebsd.org
Cc:  
Subject: Re: kern/129508: [panic] Kernel panic with EtherIP (may be related
 to SVN commit 178025)
Date: Thu, 26 Feb 2009 23:34:06 -0500

 For anyone who was unenthusiastic about this due to the infrequency of 
 the problem, this has become less of a debugging nightmare. Due to 
 increased network load, the panic occurs about once a day, on average, 
 now with 7.1-RELEASE-p2.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Questions on processing smaller frame size

2009-02-26 Thread Siquijor Philips

Hello Ivan,

>> Try reducing the number of CPUs, it might help by reducing contention.
>
> Ok, I'll try.
>

I have tested reducing the number of CPUs but it was helpless because
it causes my system to hang.

Regards,
Siquijor
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Recommended additions to ipfw command: increment and verbosity limit

2009-02-26 Thread Brett Glass


Everyone:

Reviewing the latest man page for ipfw(8), I see that the only way 
to change the automatic increment for rules is still to set a 
sysctl variable (net.inet.ip.fw.autoinc_step). This was once also 
the case for "one pass" behavior (net.inet.ip.fw.one_pass) as well 
as verbose logging, debugging messages, and the global enable bit 
for the entire firewall. However various "ipfw enable" and "ipfw 
disable" subcommands were added over time to eliminate the need to 
set arcane sysctl variables.


The only two commonly used parameters that are still not settable 
from the ipfw(8) command seem to be autoinc_step and verbose_limit. 
(autoinc_step has to be in the range 1..1000, while verbose_limit 
seems to be able to take any unsigned integer value.)


I'd like to recommend that subcommands be added to set them, not 
only for the sake of consistency but to make it unnecessary to 
circumvent the ipfw command to configure one's firewall. The sysctl 
variables could remain to provide backward compatibility and to 
satisfy the Principle of Least Astonishment. Comments? Should I 
submit code? (Anyone qualified to be a committer should be able to 
make the changes by copying an editing a few lines, but...)


--Brett Glass

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

Re: Questions on processing smaller frame size

2009-02-26 Thread Sepherosa Ziehau

On Wed, Feb 25, 2009 at 6:48 PM, Ivan Voras  wrote:
>
> There is a very experimental patch to the em driver, not endorsed by the
> em driver author (for unknown reasons) that some users claim helps with
> SMP performance. See
> http://lists.freebsd.org/pipermail/freebsd-net/2008-December/020441.html
>

What's the interrupt rate of the above driver if you do:

netperf -H remote-ip -t UDP_STREAM -l 60 -- -m 1472

Anyone has tried it?

Best Regards,
sephe

-- 
Live Free or Die
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: FreeBSD Router Problem

2009-02-26 Thread Shawn Everett

>  Any error messages in dmesg output ?
>  Significant changes in "netstat -m" output before and after ?
>  The same for "pfctl -s all" output...

The box has been up for about 12 hours now.  As a point of discussion here 
is the output from netstat and pfctl in case anything obvious jumps out.

385/905/1290 mbufs in use (current/cache/total)
384/484/868/25600 mbuf clusters in use (current/cache/total/max)
256/384 mbuf+clusters out of packet secondary zone in use (current/cache)
0/44/44/12800 4k (page size) jumbo clusters in use 
(current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
864K/1370K/2234K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/5/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines


# pfctl -s all
No ALTQ support in kernel
ALTQ related functions disabled
TRANSLATION RULES:
nat on ste0 inet from 172.16.3.0/24 to any -> (ste0) round-robin
nat on ste1 inet from 172.16.3.0/24 to any -> (ste1) round-robin

FILTER RULES:
pass out on em0 inet from any to 172.16.3.0/24 flags S/SA keep state
pass in quick on em0 inet from 172.16.3.0/24 to 172.16.3.253 flags S/SA 
keep state
pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } 
round-robin inet proto tcp from 172.16.3.0/24 to any flags S/SA modulate 
state
pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } 
round-robin inet proto udp from 172.16.3.0/24 to any keep state
pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) } 
round-robin inet proto icmp from 172.16.3.0/24 to any keep state
pass out on ste0 proto tcp all flags S/SA modulate state
pass out on ste0 proto udp all keep state
pass out on ste0 proto icmp all keep state
pass out on ste1 proto tcp all flags S/SA modulate state
pass out on ste1 proto udp all keep state
pass out on ste1 proto icmp all keep state
pass out on ste0 route-to (ste1 204.244.159.254) inet from 204.244.159.55 
to any flags S/SA keep state
pass out on ste1 route-to (ste0 204.244.159.254) inet from 204.244.159.68 
to any flags S/SA keep state

STATES:
all udp 172.16.3.255:137 <- 172.16.3.17:137   NO_TRAFFIC:SINGLE
all udp 172.16.3.17:137 -> 204.244.159.68:57827 -> 172.16.3.255:137   
SINGLE:NO_TRAFFIC
all tcp 10.170.54.1:81 <- 172.16.3.71:3064   CLOSED:SYN_SENT
all tcp 172.16.3.71:3064 -> 204.244.159.55:56563 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all tcp 10.170.54.1:81 <- 172.16.3.30:2021   CLOSED:SYN_SENT
all tcp 172.16.3.30:2021 -> 204.244.159.68:54557 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all tcp 10.170.54.1:81 <- 172.16.3.72:1414   CLOSED:SYN_SENT
all tcp 172.16.3.72:1414 -> 204.244.159.55:52567 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all tcp 10.170.54.1:81 <- 172.16.3.31:2865   CLOSED:SYN_SENT
all tcp 172.16.3.31:2865 -> 204.244.159.68:59429 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all tcp 10.170.54.1:81 <- 172.16.3.72:1415   CLOSED:SYN_SENT
all tcp 172.16.3.72:1415 -> 204.244.159.55:61425 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all tcp 10.170.54.1:81 <- 172.16.3.49:1914   CLOSED:SYN_SENT
all tcp 172.16.3.49:1914 -> 204.244.159.68:58532 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all udp 172.16.3.255:138 <- 172.16.3.39:138   NO_TRAFFIC:SINGLE
all udp 172.16.3.39:138 -> 204.244.159.68:62224 -> 172.16.3.255:138   
SINGLE:NO_TRAFFIC
all tcp 64.56.145.72:110 <- 172.16.3.48:1494   FIN_WAIT_2:FIN_WAIT_2
all tcp 172.16.3.48:1494 -> 204.244.159.55:62928 -> 64.56.145.72:110   
FIN_WAIT_2:FIN_WAIT_2
all udp 172.16.3.255:137 <- 172.16.3.49:137   NO_TRAFFIC:SINGLE
all udp 172.16.3.49:137 -> 204.244.159.55:61053 -> 172.16.3.255:137   
SINGLE:NO_TRAFFIC
all tcp 10.170.54.1:81 <- 172.16.3.37:1508   CLOSED:SYN_SENT
all tcp 172.16.3.37:1508 -> 204.244.159.68:54656 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all tcp 10.170.54.1:81 <- 172.16.3.74:3126   CLOSED:SYN_SENT
all tcp 172.16.3.74:3126 -> 204.244.159.55:61282 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all tcp 10.170.54.1:81 <- 172.16.3.18:2446   CLOSED:SYN_SENT
all tcp 172.16.3.18:2446 -> 204.244.159.68:58385 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all tcp 10.170.54.1:81 <- 172.16.3.73:2057   CLOSED:SYN_SENT
all tcp 172.16.3.73:2057 -> 204.244.159.55:61692 -> 10.170.54.1:81   
SYN_SENT:CLOSED
all udp 198.208.22.27:53 <- 172.16.3.74:58071   SINGLE:MULTIPLE
all udp 172.16.3.74:58071 -> 204.244.159.68:54669 -> 198.208.22.27:53   
MULTIPLE:SINGLE
all udp 198.208.22.27:53 <- 172.16.3.74:57503   SINGLE:MULTIPLE
all udp 172.16.3.74:57503 -> 204.244.159.55:64923 -> 198.208.22.27:53   
MULTIPLE:SINGLE
all udp 198.208.22.27:53 <- 172.16.3.74:51153   SINGLE:MULTIPLE
all udp 172.16.3.74:51153 ->

Re: FreeBSD Router Problem

2009-02-26 Thread Adrian Penisoara

Hi,

On Fri, Feb 27, 2009 at 8:41 AM, Shawn Everett  wrote:

> >  Any error messages in dmesg output ?
> >  Significant changes in "netstat -m" output before and after ?
> >  The same for "pfctl -s all" output...
>
> The box has been up for about 12 hours now.  As a point of discussion here
> is the output from netstat and pfctl in case anything obvious jumps out.
>
> 385/905/1290 mbufs in use (current/cache/total)
> 384/484/868/25600 mbuf clusters in use (current/cache/total/max)
> 256/384 mbuf+clusters out of packet secondary zone in use (current/cache)
> 0/44/44/12800 4k (page size) jumbo clusters in use
> (current/cache/total/max)
> 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
> 864K/1370K/2234K bytes allocated to network (current/cache/total)
> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
> 0/0/0 requests for jumbo clusters denied (4k/9k/16k)
> 0/5/6656 sfbufs in use (current/peak/max)
> 0 requests for sfbufs denied
> 0 requests for sfbufs delayed
> 0 requests for I/O initiated by sendfile
> 0 calls to protocol drain routines
>

This looks OK to me...


>
>
> # pfctl -s all
> No ALTQ support in kernel
> ALTQ related functions disabled
> TRANSLATION RULES:
> nat on ste0 inet from 172.16.3.0/24 to any -> (ste0) round-robin
> nat on ste1 inet from 172.16.3.0/24 to any -> (ste1) round-robin
>
> FILTER RULES:
> pass out on em0 inet from any to 172.16.3.0/24 flags S/SA keep state
> pass in quick on em0 inet from 172.16.3.0/24 to 172.16.3.253 flags S/SA
> keep state
> pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) }
> round-robin inet proto tcp from 172.16.3.0/24 to any flags S/SA modulate
> state
> pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) }
> round-robin inet proto udp from 172.16.3.0/24 to any keep state
> pass in on em0 route-to { (ste0 204.244.159.254), (ste1 204.244.159.254) }
> round-robin inet proto icmp from 172.16.3.0/24 to any keep state
> pass out on ste0 proto tcp all flags S/SA modulate state
> pass out on ste0 proto udp all keep state
> pass out on ste0 proto icmp all keep state
> pass out on ste1 proto tcp all flags S/SA modulate state
> pass out on ste1 proto udp all keep state
> pass out on ste1 proto icmp all keep state
> pass out on ste0 route-to (ste1 204.244.159.254) inet from 204.244.159.55
> to any flags S/SA keep state
> pass out on ste1 route-to (ste0 204.244.159.254) inet from 204.244.159.68
> to any flags S/SA keep state
>

Quite an evolved route forwarding setup ;)...


>
> STATES:
> all udp 172.16.3.255:137 <- 172.16.3.17:137   NO_TRAFFIC:SINGLE
> all udp 172.16.3.17:137 -> 204.244.159.68:57827 -> 172.16.3.255:137
> SINGLE:NO_TRAFFIC
> all tcp 10.170.54.1:81 <- 172.16.3.71:3064   CLOSED:SYN_SENT
> all tcp 172.16.3.71:3064 -> 204.244.159.55:56563 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.30:2021   CLOSED:SYN_SENT
> all tcp 172.16.3.30:2021 -> 204.244.159.68:54557 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.72:1414   CLOSED:SYN_SENT
> all tcp 172.16.3.72:1414 -> 204.244.159.55:52567 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.31:2865   CLOSED:SYN_SENT
> all tcp 172.16.3.31:2865 -> 204.244.159.68:59429 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.72:1415   CLOSED:SYN_SENT
> all tcp 172.16.3.72:1415 -> 204.244.159.55:61425 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.49:1914   CLOSED:SYN_SENT
> all tcp 172.16.3.49:1914 -> 204.244.159.68:58532 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all udp 172.16.3.255:138 <- 172.16.3.39:138   NO_TRAFFIC:SINGLE
> all udp 172.16.3.39:138 -> 204.244.159.68:62224 -> 172.16.3.255:138
> SINGLE:NO_TRAFFIC
> all tcp 64.56.145.72:110 <- 172.16.3.48:1494   FIN_WAIT_2:FIN_WAIT_2
> all tcp 172.16.3.48:1494 -> 204.244.159.55:62928 -> 64.56.145.72:110
> FIN_WAIT_2:FIN_WAIT_2
> all udp 172.16.3.255:137 <- 172.16.3.49:137   NO_TRAFFIC:SINGLE
> all udp 172.16.3.49:137 -> 204.244.159.55:61053 -> 172.16.3.255:137
> SINGLE:NO_TRAFFIC
> all tcp 10.170.54.1:81 <- 172.16.3.37:1508   CLOSED:SYN_SENT
> all tcp 172.16.3.37:1508 -> 204.244.159.68:54656 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.74:3126   CLOSED:SYN_SENT
> all tcp 172.16.3.74:3126 -> 204.244.159.55:61282 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.18:2446   CLOSED:SYN_SENT
> all tcp 172.16.3.18:2446 -> 204.244.159.68:58385 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all tcp 10.170.54.1:81 <- 172.16.3.73:2057   CLOSED:SYN_SENT
> all tcp 172.16.3.73:2057 -> 204.244.159.55:61692 -> 10.170.54.1:81
> SYN_SENT:CLOSED
> all udp 198.208.22.27:53 <- 172.16.3.74:58071   SINGLE:MULTIPLE
> all udp 172.16.3.74:58071 -> 204.244.159.68:54669 -> 198.208.22.27:53
> MULTIPLE:SINGLE
> all udp 198.208.22.27:53 <- 172.16.3.7

Re: NATT patch and FreeBSD's setkey

Re: FreeBSD Router Problem

Re: FreeBSD Router Problem

FreeBSD Router Problem

Re: FreeBSD Router Problem

Re: kern/129508: [panic] Kernel panic with EtherIP (may be related to SVN commit 178025)

Re: Questions on processing smaller frame size

Recommended additions to ipfw command: increment and verbosity limit

Re: Questions on processing smaller frame size

Re: FreeBSD Router Problem

Re: FreeBSD Router Problem

11 matches

Site Navigation

Mail list logo

Footer information