Hi Dan,
Do you plan to MFC the icmplim_output sysctl work you did in ip_icmp.c
mid-2000? Seems quite useful for firewall-class systems running
4.5-STABLE.
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Dear all,
I am trying to figure out how to let roaming users
access internal resource via freebsd as IPsec gateway.
Because they have dynamic IPs. How can I write
security policy to deal with this? Is there any IPsec
client for windows platform available? Is it ok to let
ESP packet coming in and
On Wed, 13 Mar 2002, Dmitry Koltsov wrote:
> Hello,
>
> I'm running on 4.4-stable.
>
> Seems like my problem is (connection refused) caused by listen queue.
>
> I have 1-10 requsts in apache listen queue (port 80), queue len is 511
> connections and have counter "listen queue overflows" growing
Would anyone be upset if I got rid of maxsockets and consequently the
limits on the *pcb zones? This was previously used so that the zone
allocator could allocate items at interrupt time. Now you can just supply
M_NOWAIT/WAITOK and get the desired effect without a hard limit.
Jeff
To Unsubscr
* Jeff Roberson <[EMAIL PROTECTED]> [020320 11:36] wrote:
> Would anyone be upset if I got rid of maxsockets and consequently the
> limits on the *pcb zones? This was previously used so that the zone
> allocator could allocate items at interrupt time. Now you can just supply
> M_NOWAIT/WAITOK an
Dunno if this belongs to net or security but...
I've established a tunnel between my home FreeBSD host and a corporate
OpenBSD firewall. This works just fine. Well, works, but not good enough.
Specs:
home:
FreeBSD 4.5
IPF
pub-ip: 130.236.218.63
priv-net: 192.168.2.0/24
office:
OpenBSD 3.0-stabl
On Wed, 20 Mar 2002, Jeff Roberson wrote:
> Would anyone be upset if I got rid of maxsockets and consequently the
> limits on the *pcb zones? This was previously used so that the zone
> allocator could allocate items at interrupt time. Now you can just supply
> M_NOWAIT/WAITOK and get the desi
Rickard Borgmäster wrote:
> I've established a tunnel between my home FreeBSD host and a corporate
> OpenBSD firewall.
IPsec tunnel I assume?
> I can see this at OpenBSD box:
> # netstat -rn
> [...]
> Port DestinationPort Proto SA(Address/Proto/Type/Direction)
> 192.168.2/24
< said:
> We still need to cap the number of sockets somehow, as it would be bad for
> sockets to consume all memory.
There's already a cap: maxfiles.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Wed, 20 Mar 2002, Alfred Perlstein wrote:
>
> That depends on what this implies. :)
>
> Does it mean that when giving M_NOWAIT there's a chance it may fail
> more often than the old zone allocator? Meaning does M_NOWAIT mean
> "only allocate from cache" or do you do close to the same thing
On Wed, 20 Mar 2002, Mike Silbersack wrote:
>
> We still need to cap the number of sockets somehow, as it would be bad for
> sockets to consume all memory. If you want to move the socket limit to
> someplace where it can be modified via a sysctl, that'd be great. As
> you're going through and
On Wed, 20 Mar 2002, Garrett Wollman wrote:
> < said:
>
> > We still need to cap the number of sockets somehow, as it would be bad for
> > sockets to consume all memory.
>
> There's already a cap: maxfiles.
>
> -GAWollman
That would end up being a reduction below the current value; right now
so
* Jeff Roberson <[EMAIL PROTECTED]> [020320 12:29] wrote:
>
>
> On Wed, 20 Mar 2002, Alfred Perlstein wrote:
>
> >
> > That depends on what this implies. :)
> >
> > Does it mean that when giving M_NOWAIT there's a chance it may fail
> > more often than the old zone allocator? Meaning does M_NO
On Wed, 20 Mar 2002, Jeff Roberson wrote:
> I have kept the current limits in place, but I think that it's somewhat
> ugly to have this policy enforced in the allocator where it is hard to
> adjust with a sysctl. Perhaps maxsockets could stay but become run time
> adjustable.
>
> Is there any c
On Wed, 20 Mar 2002, Alfred Perlstein wrote:
> >
> > Currently it means, if I can't get KVA or a page to back it, return NULL.
> > It just stops operations that would REALLY block. The old code reserved
> > the KVA up front and just found a page at interrupt time.
>
> Bottom line, will the sem
On Wed, 20 Mar 2002 12:21:07 -0800
Lars Eggert <[EMAIL PROTECTED]> hit the keyboard and punched:
> > I can see this at OpenBSD box:
> > # netstat -rn
> > [...]
> > Port DestinationPort Proto SA(Address/Proto/Type/Direction)
> > 192.168.2/24 0 10.0.0/24 0 0
>
< said:
> That would end up being a reduction below the current value; right now
> sockets > maxfiles with large maxuser values. Whether or not this is a
> necessary differential, I'm not sure. (With TIME_WAIT and FIN_WAIT_2
> sockets, I believe that maxsockets should exceed maxfiles.)
My poin
Rickard Borgmäster wrote:
>>It looks like the OpenBSD IPsec implementation integrates IPsec tunnel
>>mode SAs with the routing table (good!) FreeBSD's KAME doesn't (yet;
>>more recent KAME SNAPs have "device sec" which looks promising).
>
>
> KAME? Is KAME something I need? The only thing I've
On Wed, 20 Mar 2002 14:44:06 -0800
Lars Eggert <[EMAIL PROTECTED]> hit the keyboard and punched:
> No, there is an (older) KAME included in FreeBSD; however that one
> doesn't yet represent SAs in the routing table as interfaces.
I still do not understand wether I need KAME or not? What would i
Hi,
Can someone help me point the source code where "the TCP/IP stack knows
that the NIC is going to insert the checksums"?
Is there anyway to disable checksum in the hardware so that
the checksum will be done in software or
to force the TCP/IP stack do the checksumming?
My current project is
20 matches
Mail list logo
