-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I.e. where we keep past connection state and use that
> as a reference for the initial cwnd. I asked Mark about
> this in the past.. and he said that his paper was
> mis-interpreted and this is incorrect behavior. If you
> have no connections up to a
it was the stock tree
On 7/16/07, Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote:
On Mon, 16 Jul 2007, David Cornejo wrote:
> I eventually reinstalled the OS from a recent snapshot then updated it
> to the latest CURRENT and it works fine now :-(
Hmm I am using CURRENT from today and I culd see the
On Mon, 16 Jul 2007, David Cornejo wrote:
I eventually reinstalled the OS from a recent snapshot then updated it
to the latest CURRENT and it works fine now :-(
Hmm I am using CURRENT from today and I culd see the issue.
I set sysctl net.inet.udp.checksum=0 to get things working temporary.
I
I eventually reinstalled the OS from a recent snapshot then updated it
to the latest CURRENT and it works fine now :-(
dave c
On 7/16/07, Bjoern A. Zeeb <[EMAIL PROTECTED]> wrote:
On Wed, 20 Jun 2007, David Cornejo wrote:
Hi,
> the remote machine sees bad checksums - netstat indicates that
>
On 7/16/07, Sten Daniel Soersdal <[EMAIL PROTECTED]> wrote:
I guess it wouldn't hurt for the operating system to accept larger
frames, as long as only the correctly sized frames are transmitted.
There are alot of people, including myself, that assume a host can't
receive a frame that is larger
On Wed, 20 Jun 2007, David Cornejo wrote:
Hi,
the remote machine sees bad checksums - netstat indicates that
received packets are being discarded because of bad checksums.
-txcsum has no effect, I don't think (at least mine) sis support
offloading checksums - the only if flags seem to be VLAN_
Wes Peters wrote:
On 7/16/07, Sten Daniel Soersdal <[EMAIL PROTECTED]> wrote:
I guess it wouldn't hurt for the operating system to accept larger
frames, as long as only the correctly sized frames are transmitted.
There are alot of people, including myself, that assume a host can't
receive a
Stephen Clark wrote:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Sten Daniel Soersdal wrote:
Stephen Clark wrote:
Hello,
Did something change in 6.2? If my mtu size on rl0 is 1280 it won't
accept a larger incomming packet.
kernel: rl0: discard oversize frame (ether type
The following reply was made to PR kern/112612; it has been noted by GNATS.
From: Cristian KLEIN <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/112612: [lo] Traffic via additional lo(4) interface shows
up on lo0 in bpf(4)
Date: Mon, 16 Jul 2007 17:18:33 +030
Current FreeBSD problem reports
Critical problems
Serious problems
S Tracker Resp. Description
a kern/38554 netchanging interface ipaddress doesn't seem to work
s kern/39937 netipstealth
James Healy wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We've recently been doing some TCP congestion control research, and have
written a small logging module for 6.2 that outputs the cwnd of a tcp
flow to a log file. The logging module is called SIFTR and is available
on our website:
James Healy wrote:
This behaviour seems a little odd to us - can anyone shed some light on
it? Our assumption is that the use of the hostcache is designed to
increase performance where appropriate by seeding the initial cwnd based
on past experience.
For this section of code to return a cwnd th
12 matches
Mail list logo
