Can you please submit your patch to the group for review?
On Tue, Aug 21, 2007 at 01:50:55PM -0700, Alfred Perlstein wrote:
> Hello all,
>
> I would like to reserve about 64 entries for VENDOR specific address
> families in sys/socket.h.
>
> I think this will allow vendors to comfortably use the
On Wednesday 22 August 2007, Alfred Perlstein wrote:
> I trimmed the sender of this because I got it in private mail, that
> said I thought it was a good bunch of questions so I am replying
> to it.
>
> > 64? are you intending to bump AF_MAX or allocate them sequentially
> > such that adding anoth
I trimmed the sender of this because I got it in private mail, that
said I thought it was a good bunch of questions so I am replying
to it.
> 64? are you intending to bump AF_MAX or allocate them sequentially such
> that adding another AF will require AF_MAX to grow a lot?
>
> In general this s
Hello all,
I would like to reserve about 64 entries for VENDOR specific address
families in sys/socket.h.
I think this will allow vendors to comfortably use the array of
address families without worrying about overlap with FreeBSD
protocols.
If no one objects I plan to commit this in the next fe
On 8/20/07, George V. Neville-Neil <[EMAIL PROTECTED]> wrote:
>
> Your raccoon config, if you could send it to me, would be helpful.
Not a problem. Look for an email from "Seth" in your inbox in the
next day or so (he is in europe on a different time schedule).
Thanks again for your help, Georg
Hi,
I was wondering why racoon doesnt support negotiation for per-socket
policies? Is it because racoon maintains its database based on src and dst
addresses and a port based one doesnt always has one?
Is this support is planned for any future ipsec-tools release? It is just
mentioned
at http://ww
On Tue, Aug 21, 2007 at 06:17:48PM +0200, Jacek Zapala wrote:
> I have applied the patch and it looks like it has helped.
Great, thank you!
> But I'm not sure if I understood well - you suspect that only 8 bytes of
> tcp header are copied from the original tcp packet to the icmp message
> by the
On Tue, 2007-08-21 at 16:50 +0200, Daniel Hartmeier wrote:
> Could you possibly try the patch below, and see if it fixes the
> problem
> (with rfc1323 enabled again)?
>
> We're accessing th_flags from the TCP header embedded in the ICMPv6
> packet, even though we only pulled up the first 8 bytes o
Could you possibly try the patch below, and see if it fixes the problem
(with rfc1323 enabled again)?
We're accessing th_flags from the TCP header embedded in the ICMPv6
packet, even though we only pulled up the first 8 bytes of the mbuf,
because the sender doesn't have to provide more of the head
On Tue, 2007-08-21 at 16:31 +0200, Daniel Hartmeier wrote:
> Is the following a correct view of your setup:
>
> src $int_if pf $ext_if router dst
>
> Where client src connects to server dst, and you create the state
> entry
> when the initial TCP SYN goes out $ext_if on the firew
On Tue, Aug 21, 2007 at 04:16:51PM +0200, Jacek Zapala wrote:
> I have disabled this on sending side (FreeBSD) and it started to work!
Ah, so it's related to window scaling. Headaches again ;)
Is the following a correct view of your setup:
src $int_if pf $ext_if router dst
Whe
On Tue, 2007-08-21 at 15:50 +0200, Daniel Hartmeier wrote:
> Since you're using TCP window scaling, could you try disabling that
> (sysctl net.inet.tcp.rfc1323=0 on either peer), and see if it affects
> things? Just to make sure that's not a part of the problem.
Good guess!
I have disabled this o
On Tue, Aug 21, 2007 at 03:37:52PM +0200, Jacek Zapala wrote:
> Attached.
Thanks, I'll study them.
Since you're using TCP window scaling, could you try disabling that
(sysctl net.inet.tcp.rfc1323=0 on either peer), and see if it affects
things? Just to make sure that's not a part of the problem.
On Tue, 2007-08-21 at 14:11 +0200, Daniel Hartmeier wrote:
> But th_seq of the TCP packet quoted by the ICMPv6 error is 2463010534,
> which is outside dst's window. Strangely, it is within src's window.
>
> I don't understand why some_router would do this. It looks like it's
> either quoting the w
When filtering statefully, there is no need for a specific rule allowing
ICMPv6 errors like ICMP6_PACKET_TOO_BIG. These ICMPv6 messages contain, as
payload, the header of the original packet that triggered the error. pf
extracts that inner header and searches for a matching state entry. If a
matchi
The following reply was made to PR kern/115413; it has been noted by GNATS.
From: Jacek Zapala <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/115413: [ipv6] ipv6 pmtu not working
Date: Tue, 21 Aug 2007 12:05:18 +0200
Further debugging:
scp from src_addr to dst_addr which pf
On Monday 20 August 2007, Kevin Oberman wrote:
> I am trying to tune a FreeBSD system for ~100 ms. RTT at 10 Gbps. (I
> posted another message about this back on 8/17). I am running current
> of late July 31.
>
> I am using iperf and I have confirmed (with gdb) that it is passing
> setsockopt a siz
17 matches
Mail list logo
