>>> Regardless, why are you trying to do something that is unsupported by
>>> pretty much every vendor/operator/os?
>>
>> Status quo is fine and dandy if it's rational, backed up with a
>> justification and can be understood, but I'm not seeing anything that
>> suggests there's a good reason wh
On 14/11/2012 07:32, Joe Holden wrote:
On 14/11/2012 07:25, Sean Chittenden wrote:
The check to drop ICMP replies to a source of 0.0.0.0/8 was added
in r120958 as part of a fix for link local addresses. It was only
applied to ICMP which is inconsistent as you've found out.
?? Any thoughts as
On 14/11/2012 07:25, Sean Chittenden wrote:
The check to drop ICMP replies to a source of 0.0.0.0/8 was added
in r120958 as part of a fix for link local addresses. It was only
applied to ICMP which is inconsistent as you've found out.
?? Any thoughts as to why? It doesn't appear that the curre
> The check to drop ICMP replies to a source of 0.0.0.0/8 was added
> in r120958 as part of a fix for link local addresses. It was only
> applied to ICMP which is inconsistent as you've found out.
>
>> ?? Any thoughts as to why? It doesn't appear that the current behavior
>>>
On 14/11/2012 07:06, Sean Chittenden wrote:
Hello. I ran in to an interesting situation in what appears to be an exotic
situation. Specifically, after reviewing RFC5735 again and searching for a
datacenter-local or rack-local IP range (i.e trying to provide services that
are guaranteed to be p
On 11/12/2012 02:57 PM, Dustin Wenz wrote:
> I'm trying to determine why the default ephemeral port range appears
> to be 1 through 65535 in at least 8.1 through 9.1RC.
I had produced the patch that extended the ephemeral port range in
FreeBSD. My original patch extended the ephemeral port ran
Hello. I ran in to an interesting situation in what appears to be an
exotic situation. Specifically, after reviewing RFC5735 again and
searching for a datacenter-local or rack-local IP range (i.e trying to
provide services that are guaranteed to be provided in the same rack a
Sean Chittenden wrote:
Hello. I ran in to an interesting situation in what appears to be an exotic
situation. Specifically, after reviewing RFC5735 again and searching for a
datacenter-local or rack-local IP range (i.e trying to provide services that
are guaranteed to be provided in the same r
14.11.2012 04:48, Dustin Wenz пишет:
> Thanks for the information;
>
> It would seem that when I invoke the connect() system call, it picks a client
> port in the portrange.first-last range and not necessarily in
> portrange.hifirst-hilast. Is this expected behavior, or a bug in connect()?
Plea
Thanks for the information;
It would seem that when I invoke the connect() system call, it picks a client
port in the portrange.first-last range and not necessarily in
portrange.hifirst-hilast. Is this expected behavior, or a bug in connect()?
- .Dustin
On Nov 12, 2012, at 12:49 PM, C
To try to completely resolve the race in bpfread(), I have put together these
changes to add a flag to indicate when the hold buffer cannot be modified
because it is in use. Since it's my first time using mtx_sleep() and wakeup(),
I wanted to run these past the list to see if I can get any feedb
On 14.11.2012 00:16, Alfred Perlstein wrote:
Alexander, this is awesome.
On 11/13/12 11:28 AM, Alexander V. Chernikov wrote:
Hello list!
Currently most ipfw operations with dynamic states (keep-state,
check-state, limit) are serialized via IPFW_DYN_LOCK() which is
per-vnet mutex lock.
As a re
Alexander, this is awesome.
On 11/13/12 11:28 AM, Alexander V. Chernikov wrote:
Hello list!
Currently most ipfw operations with dynamic states (keep-state,
check-state, limit) are serialized via IPFW_DYN_LOCK() which is
per-vnet mutex lock.
As a result, performance is limited to the same ~6
Hello list!
Currently most ipfw operations with dynamic states (keep-state,
check-state, limit) are serialized via IPFW_DYN_LOCK() which is per-vnet
mutex lock.
As a result, performance is limited to the same ~650kpps as in routing
(in several cases).
Patch changes the following:
* global lo
>> Hello. I ran in to an interesting situation in what appears to be an exotic
>> situation. Specifically, after reviewing RFC5735 again and searching for a
>> datacenter-local or rack-local IP range (i.e trying to provide services that
>> are guaranteed to be provided in the same rack as the se
On Nov 13, 2012, at 1:43 PM, Andre Oppermann wrote:
> On 13.11.2012 09:41, Alfred Perlstein wrote:
>> On 11/13/12 12:25 AM, Andre Oppermann wrote:
>>> On 13.11.2012 09:18, Alfred Perlstein wrote:
On 11/13/12 12:06 AM, Andre Oppermann wrote:
> On 13.11.2012 07:45, Alfred Perlstein wrote:
On 13.11.2012 09:41, Alfred Perlstein wrote:
On 11/13/12 12:25 AM, Andre Oppermann wrote:
On 13.11.2012 09:18, Alfred Perlstein wrote:
On 11/13/12 12:06 AM, Andre Oppermann wrote:
On 13.11.2012 07:45, Alfred Perlstein wrote:
If you are concerned about the space/time tradeoff I'm pretty happy
That's... So simple that it sounds like a genius idea :)
It works great, thanks! :)
On Nov 13, 2012 10:11 AM, "Özkan KIRIK" wrote:
> you can bridge all interfaces with if_bridge.
> Later, assign the IPv6 addresses to the bridge0 interface.
>
>
>
> On Sun, Nov 11, 2012 at 7:28 PM, Thesaurarius Ro
On Tue, Nov 13, 2012 at 11:21:15AM +0100, Andre Oppermann wrote:
A> On 13.11.2012 10:17, Gleb Smirnoff wrote:
A> > On Mon, Nov 12, 2012 at 06:11:40PM -0800, David O'Brien wrote:
A> > D> On Fri, Sep 14, 2012 at 11:51:51AM +, Gleb Smirnoff wrote:
A> > D> > Log:
A> > D> > o Create directory sys/
On 13.11.2012 10:17, Gleb Smirnoff wrote:
On Mon, Nov 12, 2012 at 06:11:40PM -0800, David O'Brien wrote:
D> On Fri, Sep 14, 2012 at 11:51:51AM +, Gleb Smirnoff wrote:
D> > Log:
D> > o Create directory sys/netpfil, where all packet filters should
D> > reside, and move there ipfw(4) and p
On 11/13/12 12:25 AM, Andre Oppermann wrote:
On 13.11.2012 09:18, Alfred Perlstein wrote:
On 11/13/12 12:06 AM, Andre Oppermann wrote:
On 13.11.2012 07:45, Alfred Perlstein wrote:
If you are concerned about the space/time tradeoff I'm pretty happy
with making it 1/2, 1/4th, 1/8th
the size of
On 13.11.2012 09:18, Alfred Perlstein wrote:
On 11/13/12 12:06 AM, Andre Oppermann wrote:
On 13.11.2012 07:45, Alfred Perlstein wrote:
If you are concerned about the space/time tradeoff I'm pretty happy with making
it 1/2, 1/4th, 1/8th
the size of maxsockets. (smaller?)
Would that work bette
On 13.11.2012 08:42, Sean Chittenden wrote:
Hello. I ran in to an interesting situation in what appears to be an exotic
situation. Specifically, after reviewing RFC5735 again and searching for a
datacenter-local or rack-local IP range (i.e trying to provide services that
are guaranteed to be p
On 11/13/12 12:06 AM, Andre Oppermann wrote:
On 13.11.2012 07:45, Alfred Perlstein wrote:
On 11/12/12 10:23 PM, Peter Wemm wrote:
On Mon, Nov 12, 2012 at 10:11 PM, Alfred Perlstein
wrote:
On 11/12/12 10:04 PM, Alfred Perlstein wrote:
On 11/12/12 10:48 AM, Alfred Perlstein wrote:
On 11/12/12
On 13.11.2012 07:45, Alfred Perlstein wrote:
On 11/12/12 10:23 PM, Peter Wemm wrote:
On Mon, Nov 12, 2012 at 10:11 PM, Alfred Perlstein wrote:
On 11/12/12 10:04 PM, Alfred Perlstein wrote:
On 11/12/12 10:48 AM, Alfred Perlstein wrote:
On 11/12/12 10:01 AM, Andre Oppermann wrote:
I've alrea
25 matches
Mail list logo
