I was looking at some tcpdumps from a FreeBSD box receiving a TCP
stream with someone yesterday and noticed that it seemed to be
generating quite a lot of dupliacte acks. Looking more carefully,
we noticed that the duplicates were actually window updates. The
code for sending window updates can be
Yes, this makes sense. Probably this is a bug since 4.4BSD-Lite.
I had a look to see what Linux does - it only generates pure window
updates in the case that the advertised window would change by a
factor of two. I guess this practically eliminates these updates.
I would guess that changing the
I've got an example extract tcpdump of this at the end of the mail
- here 6 ACKs are sent, 5 of which are pure window updates and
several are 2us apart!
I think the easy option is to delete the code that generates explicit
window updates if the window moves by 2*MSS. We then should be doing
So the apps read buffer is possibly 32 times 2^8 = 8KB ? (32 being the
increment in each of those window updates.)
I don't have the source code to hand, but that certainly sounds
plausable. It is a tcp traffic generation tool, so 8K sounds like
the sort of size it is likely to read in.
There are several problems with the default ntp.conf that we've
committed to -current. First, we have not followed the vendor
recommendations for the pool servers at:
http://www.pool.ntp.org/vendors.html
We are supposed to contact the people running the pool and ask for
a
We are supposed to contact the people running the pool and ask for
a freebsd.pool.ntp.org subdomain.
That's a good idea.
OK - should I contact the pool guys and ask for freebsd.pool.org?
Second, we shouldn't have the local clock configured by default.
Why?
When Redhat did this, it
This is handled by having different local clocks in different strata.
I only use 2 such strata -- 1 for server and another for all clients.
But this is not so easy to set up as a default.
Indeed - I use 14 for the server, in the hope that it would limit
how far the unsynced time would get in
The NTP pool guys have set up our vendor domain. I'd like to commit
the patch below to ntp.conf. It does the following:
1) Uses our vendor domain at the pool.
2) Points people at the pool website and encourages
people to provide a server in the pool (as a
Is 3.freebsd.pool.ntp.org intentionally commented? It does resolve.
Reminder: if you do uncomment it, remember to change the three
servers to four.
The pool set up 4 groups (0, 1, 2, 3) for us, but since we only had
three in the original file (and three is a commonly recommended
number of
I'd tend to suggest stratum 13 so that the inattentive admin
doesn't spread his potentially dodgy clock info too far when
he tries uncommenting the above otherwise I (rather
subjectively) agree with this change :)
I'll change the commented version, as it shouldn't do any harm.
As I said,
I'll change the commented version, as it shouldn't do any harm.
As I said, I usually use 14, which is probably almost too low.
I don't see any real added value having 14 instead of 10. At these levels it
can be only a faked one.
Grand - let's leave it at 10 then.
David.
In light of the chat on bugtraq about using ident services "backwards"
to find out who daemons are running as, I had a look at PR 21998:
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=21998
I've read through and tested the patch, and is seems like a reasonable
idea. Basically, it adds a
I've read through and tested the patch, and is seems like a reasonable
idea. Basically, it adds a flag to sockets which have been created
via an accept() and then adds a new getcred_outgoing sysctl which
works just like getcred but returns EPERM it is not a outgoing
socket.
I think
I'm trying to figure out what #define I should use for the largest
UDP datagram. The header files don't seem to define a constant for
this. The correct size would seem to be 65535 'cos there are two
bytes in the UDP header for the size.
IP_MAXPACKET and IPV6_MAXPACKET are available and have the
So it may be okay to punt on jumbograms for now, and use a 64K static
buffer like the patch in the PR does. Even if you do implement support for
jumbograms, I think keeping the 64K static buffer around as a "fast-path"
for the common case makes sense.
Does it talk about how jumbograms will
On Mon, Aug 20, 2001 at 07:51:17PM +0100, Walter C. Pelissero wrote:
This enforces my belief that there is something broken in some deeper
layer of the network code (see the remote printing issue).
Just out of curiosity, what sort of network card is your Vaio using?
Someone else is seeing
I've just done a further test. I've mounted a directory tree from
Vaio to Vaio using localhost (lo driver) and the test has run
smoothly. So chances would be good the bug is in the ep driver.
Unfortunately...
Andre Albsmeier, who's seeing various network problems, is using
the xe driver
On Tue, Oct 23, 2001 at 02:00:34PM -0500, Alfred Perlstein wrote:
Yes, you're right, I was mistaken in my paranioa, however you're
missing the fact that one may want to allocate an EXT buf and still
have it writeable.
This is the function of M_RDONLY and M_WRITABLE framework which we
put in
On Tue, Oct 23, 2001 at 06:57:59PM -0400, Bosko Milekic wrote:
I believe that the correct way to deal with this issue is to have
M_LEADINGSPACE and M_TRAILINGSPACE simply return the number of bytes
that make up the leading space or trailing space, respectively,
When I looked at this question last year I think I found that there
were few enough places in the kernel which used M_LEADINGSPACE, so
it should be fairly easy to check them. However, I think several
of the uses were in KAME code.
The patch posted first by Luigi is safe because the
When soisdisconnected is called on a socket, the connection is
marked as broken the socket can't recieve or send any more data.
As far as I can tell, any data which is queued for output cannot
be sent, but remains queued in the socket until it is closed.
The patch below makes soisdisconnected
A shutdown guarantees that the data is transferred from the socket
buf to the TCP buf. The real question here is how you get to the
state you claim is happening: the so isdisconnected() should stall
the calling process until the data has drained, if this is the case,
or it should never get
PPS: Ask yourself: how is it that it's *EVER* possible for the function
soisdisconnected() to be called without the socket buffer having been
emptied *FIRST*.
I think it is quite simple. Say that the machine to which you are
talking is powerd down while you are sending data to it. When you
On Fri, May 31, 2002 at 01:25:09PM -0700, Archie Cobbs wrote:
As a temporary saftey measure, I'll add M_WRITABLE(m) into the
M_TRAILINGSPACE() macro. However, I see this as a temporary hack;
the correct fix is to put the burden of writability on the caller.
After all, M_TRAILINGSPACE()
On Fri, Oct 25, 2002 at 06:25:44PM -0400, Don Bowman wrote:
I have a machine running 4.7. I can panic it by sending a reasonably
high load of tcp open/close from/to it. The trace below is from
a socket from localhost to localhost (sendmail). The max number
of open file descriptors I would have
On Tue, Feb 07, 2006 at 12:45:02AM -0500, Kris Kennaway wrote:
Has anyone looked at this? This is on the TODO list for 6.1, so the
sooner it can be resolved the better.
I wonder if a lot of these panics are related to races on the
in6_ifaddr variable? Access to it is unsynchronised currently,
On Fri, Sep 22, 2006 at 11:48:23PM +0100, Robert Watson wrote:
The impact of TSO is clearly dramatic, especially when combined with the
patch, but I'm a bit concerned by the drop in performance in the patched
non-TSO case. For network cards which will always have TSO enabled, this
isn't an
The congestion window is increased based on the ACK's received. TSO
is only done on the send side and only up to the current congestion
window. I have been careful not to get any changes in congestion
control behavior with TSO. (Which does not mean that there may be
other bugs lurking in
On Tue, Nov 14, 2006 at 05:09:20PM +0100, Max Laier wrote:
Any ideas? Any papers that deal with this problem?
Assuming you don't want to use one of the standard cryptographic
ones (which I can imagine being a bit slow for something done
per-packet), then one option might be to use a simpler
On Thu, Nov 16, 2006 at 05:52:32PM +0900, JINMEI Tatuya / [EMAIL
PROTECTED]@C#:H wrote:
If you want something whose behavior is mathematically guaranteed, I'd
recommend universal hashing as already suggested in this thread.
Yep - I agree. I'll try and sort something out for Max - it may
need
On Wed, Mar 10, 2004 at 02:38:40PM -0500, Mark Allman wrote:
I looked for the paper I paraphrased, I'm pretty sure if was one by
Sally Floyd.
I don't have the paper reference handy, but it's Sally's HighSpeed TCP
work. I do happen to have a blurb on it sitting here that I think
captures
I spent a while trying to get PPPoE going through a Netopia smart
modem last night. To cut a long story short, the values for
PTT_RELAY_SID in src/sys/netgraph/ng_pppoe.h are wrong (at least
when compared with tcpdump, linux and the RFC). We have:
#if BYTE_ORDER == BIG_ENDIAN
#define
On Tue, Jun 15, 2004 at 03:57:12PM -0300, Aldrin Leal wrote:
Does the bridging code in FreeBSD 5.2-RELEASE have the hability
to perform mac checking for a given IP?
You could use ipfw2, which can match both on IP address and MAC
address.
David.
On Sun, Jun 20, 2004 at 02:54:34PM +0100, Josef Karthauser wrote:
I should have said that the atheros web site states that the 511T and
the 311T use the same chipset, which is the AR5002G, but that the
I know someone with a 511T, and it works with the ath driver, I
believe. I also have a
It seems to me that RANDOM_IP_ID might be better as a sysctl rather
than a kernel option. Would anyone mind if I changed this?
David.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send
On Tue, Aug 10, 2004 at 05:37:28PM -0300, Marc G. Fournier wrote:
So, is there a bug in the em device driver that doesn't exist on the fxp0
devices?
I have a bundle of machines with em cards that had problems talking
to dumb 10Mbps switches. They work fine with a different 10/100
dumb switch.
did the trick! now can someone remind me what inflight does? and could
someone explain why increasing sendspace alone did not do the trick?
(i had it at 64k, which got things better, but not sufficient).
TCP inflight limiting is supposed to guess the bandwidth-delay
product for a TCP
37 matches
Mail list logo
