On Jan 25, 2013, at 2:13, Anton Yuzhaninov wrote:
> ABrH> After upgrading to 9.1 it seems like carp doesn't pay attention to
> advskew anymore. I have two boxes each setup with carp0 and carp1; the
> intention is that in regular operation proxy1 is master for carp0 and proxy2
> for carp1. Ho
On 01.02.2013 23:54, Kevin Day wrote:
On Feb 1, 2013, at 4:39 PM, Andre Oppermann wrote:
This is not true. FreeBSD uses bits in the timestamp to encode all recognized
TCP options
including window scaling.
Sorry, you are correct here. Reading through a half dozen TCP implementations
in t
On Feb 1, 2013, at 4:39 PM, Andre Oppermann wrote:
>
> This is not true. FreeBSD uses bits in the timestamp to encode all
> recognized TCP options including window scaling.
>
Sorry, you are correct here. Reading through a half dozen TCP implementations
in the last day trying to figure out wh
On 01.02.2013 22:21, Kevin Day wrote:
We've got a large cluster of HTTP servers, each server handling >10,000req/sec.
Occasionally, and
during periods of heavy load, we'd get complaints from some users that
downloads were working but
going EXTREMELY slowly. After a whole lot of debugging, we na
On Feb 1, 2013, at 4:05 PM, Ed Maste wrote:
> On 1 February 2013 16:21, Kevin Day wrote:
>> We've got a large cluster of HTTP servers, each server handling
>> >10,000req/sec. Occasionally, and during periods of heavy load, we'd get
>> complaints from some users that downloads were working but
On 1 February 2013 16:21, Kevin Day wrote:
> We've got a large cluster of HTTP servers, each server handling
> >10,000req/sec. Occasionally, and during periods of heavy load, we'd get
> complaints from some users that downloads were working but going EXTREMELY
> slowly. After a whole lot of deb
We've got a large cluster of HTTP servers, each server handling >10,000req/sec.
Occasionally, and during periods of heavy load, we'd get complaints from some
users that downloads were working but going EXTREMELY slowly. After a whole lot
of debugging, we narrowed it down to being only Windows 8
The following reply was made to PR kern/175734; it has been noted by GNATS.
From: Marius Strobl
To: bug-follo...@freebsd.org, m.sp...@meta-srl.com
Cc:
Subject: Re: kern/175734: no ethernet detected on system with EG20T PCH
chipset ATOM E6xx series
Date: Fri, 1 Feb 2013 18:21:34 +0100
FreeBSD
On 01/02/2013 9:53 AM, Karim Fodil-Lemelin wrote:
Hi -net,
Sorry for the lengthy email.
TLDR: If the IP header is not aligned on an even address then the
amd64 version of in_cksum_hdr() will not work while the i386 version
of it will.
I came across this problem while working on custom softw
Hi -net,
Sorry for the lengthy email.
TLDR: If the IP header is not aligned on an even address then the amd64
version of in_cksum_hdr() will not work while the i386 version of it will.
I came across this problem while working on custom software using the
FreeBSD bridge. Our code sometimes de
On 01.02.2013 14:15, Gleb Smirnoff wrote:
On Fri, Feb 01, 2013 at 02:04:38PM +0100, Andre Oppermann wrote:
A> >The m_get2() function allocates a single mbuf with enough space
A> > to hold specified amount of data. It can return either a single mbuf,
A> > an mbuf with a standard cluster, page
On Fri, Feb 01, 2013 at 02:04:38PM +0100, Andre Oppermann wrote:
A> >The m_get2() function allocates a single mbuf with enough space
A> > to hold specified amount of data. It can return either a single mbuf,
A> > an mbuf with a standard cluster, page size cluster, or jumbo cluster.
A>
A> While
On 01.02.2013 13:04, Gleb Smirnoff wrote:
Hi!
The m_get2() function allocates a single mbuf with enough space
to hold specified amount of data. It can return either a single mbuf,
an mbuf with a standard cluster, page size cluster, or jumbo cluster.
While m_get2() is a good function, I'm
On 2/1/13 7:04 AM, Gleb Smirnoff wrote:
Hi!
The m_get2() function allocates a single mbuf with enough space
to hold specified amount of data. It can return either a single mbuf,
an mbuf with a standard cluster, page size cluster, or jumbo cluster.
It is alredy utilized in pfsync, bpf,
On 01.02.2013 10:09, Vijay Singh wrote:
> I see that BPFIF_LOCK() in bpf_mtap() is getting invoked, even
> though I am not tracing the interface. Is this expected?
This should not happen, since BPF_MTAP macro checks if BFP consumers
are present (via bpf_peers_present()) before calling bpf_mtap.
Bt
Hi!
The m_get2() function allocates a single mbuf with enough space
to hold specified amount of data. It can return either a single mbuf,
an mbuf with a standard cluster, page size cluster, or jumbo cluster.
It is alredy utilized in pfsync, bpf, libalias and soon to be utilized
in ieee80211
Hi everyone!
I am trying to tunnel IPv4 traffic over an IPv6 VPN. So far it is unsuccessful.
Both machines are running FreeBSD 9.1-RELEASE. They are acting as
gateways and they both have assigned /64 IPv6 subnets. The purpose is
to encapsulate the non routable IPv4 traffic behind those gateways
i
Hi everyone!
I am trying to tunnel IPv4 traffic over an IPv6 VPN. So far it is unsuccessful.
Both machines are running FreeBSD 9.1-RELEASE. They are acting as
gateways and they both have assigned /64 IPv6 subnets. The purpose is
to encapsulate the non routable IPv4 traffic behind those gateways
i
18 matches
Mail list logo
