Does anyone want to review this patch before I check it in? The change
has been reviewed and tested by coworkers, but not yet reviewed by any
other FreeBSD committers.
http://www.silby.com/patches/if_bxe.c-safestop.patch
This resolves an issue we saw at work where IPMI would report bus errors
On 9/5/12 3:56 PM, YongHyeon PYUN wrote:
On Tue, Sep 04, 2012 at 11:35:13PM -0500, Mike Silbersack wrote:
Does anyone want to review this patch before I check it in? The change
has been reviewed and tested by coworkers, but not yet reviewed by any
other FreeBSD committers.
http
On Thu, 26 Jun 2008, Eygene Ryabinkin wrote:
I had already tried to debug this situation and Mike Silbersack
helped me with patching the kernel. At that days his patches (that
went into 7.x) helped, but with higher request rate to the Apache,
they seem to be back again. I can try to setup
On Fri, 18 Jul 2008, Bernd Walter wrote:
443 is a self written server, but it also happens with port 80 and
sslproxy.
The client is a telnet, which disconnects directly after connecting,
so the disconnect is initiated from the client, which seems to be
important for this problem to trigger.
Y
On Wed, 8 Jul 2009, sth...@nethelp.no wrote:
According to the comments for rev. 1.10 of netinet/ip_id.c, from
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_id.c
this is to be MFCed after 2 weeks (i.e. 2 weeks after 6. February 2008).
And yet here we are in July 2009, and 7-STA
On Thu, 12 Apr 2007, LI Xin wrote:
Hi,
I found this by accident on our wiki:
Re-roll and bring in the Eifel detection originally submitted by Jeffrey
Hsu.
No. That is not going into FreeBSD if I can help it.
http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL
On top of that, we don't need yet an
On Thu, 12 Apr 2007, LI Xin wrote:
That's disappointing, but better safe than sorry.
BTW. Is there any legal alternative, e.g. make this as an option like
WANT_IDEA?
That sounds like an option... but is it worth it? Can you give us access
to your testbench that shows eifel to be an importa
On Fri, 27 Apr 2007, Preethi Natarajan wrote:
> From tcpdump at client side:
> Time: 38s.695ms: S->C data (282b)
> Time: 38s.707ms: S->C data (1448b)
> Time: 38s.707ms: C->S ack
> Time: 38s.719ms: S->C data (1448b)
> Time: 38s.719ms: C->S ack
> Time: 38s.731ms: S->C data (1448b)
> Time: 38s.741m
I've found one of the causes of the network instability of FreeBSD 7; the
tcp syncache fails to retransmit SYN-ACK packets. This causes interesting
problems when packet loss is experienced during connection setup. The
symptoms that I have witnessed are twofold:
1. If the third part of the
On Tue, 10 Jul 2007, Eygene Ryabinkin wrote:
Can't say that I am pushing much traffic through my box, but after
applying your patch and rebuilding the kernel I am still seeing the
messages like
-
TCP: [209.132.176.NNN]:NNN to [144.206.NNN.NNN]:NNN tcpflags
0x19; syncache_expand: Segment fa
On Fri, 20 Jul 2007, Peter Wemm wrote:
TCP: [127.0.0.1]:52446 to [127.0.0.1]:1128 tcpflags 0x10;
syncache_expand: Segment failed SYNCOOKIE authentication, segment
rejected (probably spoofed)
[...]
How on earth can localhost be spoofing itself? This is getting quite
absurd. :-(
Any extra ACK
On Thu, 16 Aug 2007, Igor Sysoev wrote:
I have looked sources and found that in early versions the sent counter
was simply not incremented at all. The patch attached.
The patch looks ready to commit to me. Do you want me to commit or, or do
you have another committer lined up?
After the
On Fri, 19 Oct 2007, Garrett Cooper wrote:
Hi,
In an effort to connect my 2 machines up -- the FreeBSD 8-CURRENT and
the Windows box, for filesharing via SMB I've installed samba3 and done that
song and dance to get things to work. The really weird thing is that my 2
machines will talk via
On Fri, 19 Oct 2007, Garrett Cooper wrote:
Just to clarify, how are the two hooked together? Is it over gigabit
switch, a 10mbps hub, or directly cabled together?
-Mike
Sure. They're both connected over a gigabit switch, but the Windows
driver's kind of sketchy because it keeps on switc
On Thu, 25 Oct 2007, Anton Yuzhaninov wrote:
As silby@ already pointed out to me, try changing TCP_MAX_WINSHIFT in
src/sys/netinet/tcp.h to 4.
With TCP_MAX_WINSHIFT 4 it works.
I have a fix for this already in HEAD, I'll merge it to releng_7 tonight.
But from other host with RELENG_7 tcp
On Fri, 26 Oct 2007, Anton Yuzhaninov wrote:
Yes problem was in firewall, not Solaris/FreeBSD tcp stacks.
On Solaris was used ipfilter 3.4.18, and after 3.4.18 was fixed several bugs,
which can cause such problems.
Probably this:
4.1.17 - Released 20 January 2007
fix tracking TCP windo
On Fri, 9 Nov 2007, Matt Reimer wrote:
On a eight core machine running RELENG_7 I'm seeing TCP stalls,
sometimes lasting up to 60 seconds or so. While trying to track this
down I noticed that net.inet.tcp.syncache.count is negative. Should it
be possible for the count to go negative? Perhaps it
On Fri, 9 Nov 2007, Matt Reimer wrote:
Ok, I've run netperf in both directions. The box I've been targeting
is 66.230.193.105 aka wordpress1.
Ok, at least that looks good.
The machine is a Dell 1950 with 8 x 1.6GHz Xeon 5310s, 8G RAM, and this NIC:
Nice.
I first noticed this problem run
On Sat, 10 Nov 2007, Mike Silbersack wrote:
FWIW, my crazy theory of the moment is this: We have some bug that happens
when the listen queues overflow in 7.0, and your test is strenuous enough to
hit the listen queue overflow condition, leading to total collapse. I'll
have to c
On Sat, 10 Nov 2007, Matt Reimer wrote:
I ran "netstat -Lan" every second while running this test and the
output never changed from the following, whether before or after the
stall:
I forgot to mention, check netstat -s for listen queue overflows.
During the stall the sockets are all in TIM
On Mon, 26 Nov 2007, James Healy wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
While monitoring a data transfer between two 7-beta3 hosts with tcpdump
and SIFTR[1] last week, we noticed that SACK was not being negotiated as
expected.
James Healy and Lawrence Stewart
Good detective
On Wed, 12 Dec 2007, Julian Elischer wrote:
So, I'm playing with some multiple routing table support..
the first version is a minimal impact version with very limited
functionality.
It's done that way so I can put it in RELENG_6/7 without breaking ABIs (I
hope).
Later there will be a more fl
On Sun, 20 Jan 2008, s3raphi wrote:
I am running web polygraph against a FreeBSD7.0-RC1 squid server and
experiencing problems. I have run the same test against the same hardware on
FreeBSD 6.1 without issue. This seems to be specific to FreeBSD 7.
The problem is related to the number of client
On Wed, 23 Jan 2008, Andre Oppermann wrote:
OTOH the enforcement of this rule wasn't really there before and it
may be argued that we've got a POLA violation here. A careful reading
That's exactly the point. We were not enforcing timestamps since...
whenever the RFC1323 code went in. Then
On Sat, 26 Jan 2008, Andre Oppermann wrote:
Maxim Konovalov wrote:
http://maxim.int.ru/stuff/adsl.dmp.gz
192.168.1.1 -- adsl box
192.168.1.250 -- FreeBSD
The trace looks perfectly fine with regard to timestamps. They are sent
and properly reflected by the adsl box. Everything else looks f
On Sat, 1 Mar 2008, Fernando Gont wrote:
Folks,
This patch changes the default ephemeral port range from 49152-65535 to
1024-65535. This makes it harder for an attacker to guess the ephemeral ports
(as the port number space is larger). Also, it makes the chances of port
number collisions s
On Mon, 3 Mar 2008, Fernando Gont wrote:
Folks,
Here's the same patch, but with the first ephemeral port changed from 1024 to
1.
Now that I've actually gone to try to apply the patch (so I can view the
two codepaths side by side, rather than in diff form), I'm finding that I
can't app
On Sat, 1 Mar 2008, Fernando Gont wrote:
I will also start working on the double-hash ephemeral port selection
algorithm described in the draft (this is, IMHO, the right approach to
ephemeral port randomization)
Kind regards,
--
Fernando Gont
Earlier in the week, I had commented (via priv
On Mon, 3 Mar 2008, Fernando Gont wrote:
(Shame on me... somehow you mail got stuck in my queue, and I didn't respond
to it).
No sweat, I've taken far longer to reply to your e-mails!
While I haven't look match at the scheme proposed by Amit, I think there's a
"flaw" with the algorithm: IP
On Mon, 3 Mar 2008, Fernando Gont wrote:
At 04:11 a.m. 03/03/2008, Mike Silbersack wrote:
Here's the same patch, but with the first ephemeral port changed from 1024
to 1.
Now that I've actually gone to try to apply the patch (so I can view the
two codepaths side by side, r
On Fri, 7 Mar 2008, Jake Rizzo wrote:
Hi,
I had two 6.3-STABLE boxen which have been happily running away for months
on end now without any problems. Last week I upgraded (via buildworld) both
boxes to 7.0-STABLE. Since then I've had reports of some clients being
unable to connect via tcp.
On Sun, 9 Mar 2008, Jake Rizzo wrote:
The patch didn't work, but doing this:
sysctl net.inet.tcp.tso=0
sysctl net.inet.tcp.sack.enable=0
Allows the client to connect again. Since my ifconfig doesn't show that my
nic supports TSO then I presume it's the sack sysctl that's making it work.
The
On Tue, 11 Mar 2008, d.s. al coda wrote:
Hi,
We recently upgraded one of our webservers to FreeBSD 7, and we started
receiving complaints from some users not able to connect to that server
anymore. On top of that, users were saying that the problem only occurred on
Windows (at least, the ones w
On Tue, 11 Mar 2008, d.s. al coda wrote:
- FreeBSD 7 has (there is of course an aligning nop
after the eol, which tcpdump skips)
Jake Rizzo sent me some updated tcpdumps comparing 6.3 vs 7.0, and that
aligning NOP that tcpdump (and wireshark) omit seems to be the only
difference.
Here's
On Wed, 12 Mar 2008, Mike Silbersack wrote:
I think we will need to fix tcpdump before trying to finish diagnosing this
problem. We were missing key information before.
-Mike
Hm, that was far easier than expected. Patch attached.
Here's what the two tcpdumps show now:
6.3:
IP A &g
On Wed, 12 Mar 2008, Bjoern A. Zeeb wrote:
On Tue, 11 Mar 2008, d.s. al coda wrote:
- FreeBSD 7 has (there is of course an aligning nop
after the eol, which tcpdump skips)
Which is a bug (the nop after the EOL) that I recently fixed in HEAD.
I am still curious to know if it's only ordering
On Thu, 13 Mar 2008, Bjoern A. Zeeb wrote:
It should give you output like this:
19549200,sackOK,eol,0x01[bad padding]>
I like the [bad padding].
But I think the "good" case should look like it did before, per POLA.
-Mike
___
freebsd-net@freeb
On Fri, 14 Mar 2008, Bjoern A. Zeeb wrote:
But I think the "good" case should look like it did before, per POLA.
Ok, I am only printing it in case bad padding happens or one gave -v.
The new patch is here:
http://sources.zabbadoz.net/freebsd/patchset/20080314-01-tcpdump-print-tcp-option-pad
On Mon, 28 Apr 2008, Julian Elischer wrote:
profiling diff attached..
slightly imporved version that allows you to clear the stats without
rebooting
I see an indentation glitch and a spelling error or two, but the general
concept looks great! If you want to wait a few days, maybe I cou
On Fri, 28 May 2004, Larry Rosenman wrote:
> I have a LinkSys WPC54GS PCCARD Wireless card, and am using the NDISulator
> to use the windows driver.
>
> I get the following when transferring large files:
>
> lerlaptop# tail /var/log/messages
> May 28 08:37:47 lerlaptop kernel: NDIS: buggy driver
On Fri, 28 May 2004, Larry Rosenman wrote:
> > Second, have you tried various versions of the windows drivers for the
> > card? Maybe different versions of the driver have different bugs. :)
> There is only one version for this card, it's relatively new.
I think that since it supports 98/me/2K/
On Fri, 28 May 2004, Larry Rosenman wrote:
> I E-mailed you (Silby) the driver. You should also be able to use
> ports/archivers/cabextract to pull stuff from the cab's.
>
> LER
Neat, I didn't know we had that util in ports. I tried it on the cabs,
and it told me to use "unshield", which was a
On Tue, 1 Jun 2004, Dmitry Pryanishnikov wrote:
> The main question is: how to prevent this situation? Of course, as a
> workaround I can set net.inet.ip.portrange.randomized to zero, but what's
> the real solution? Is it FTP-client or FTP-server that should take care of
> the previous DATA port
On Tue, 1 Jun 2004, Kris Kennaway wrote:
> On Tue, Jun 01, 2004 at 12:05:35PM -0500, Mike Silbersack wrote:
> > Sounds like something that should be dealt with on the server's end. Some
> > of the changes we've made in 5.x might fix the problem, but I don't think
&
On Tue, 1 Jun 2004, Andre Oppermann wrote:
> A port should not be reused this fast. Maybe the randomness isn't
> so random after all and choses the same port over again and again?
We use arc4random, so I don't think that's likely, but it is possible.
> > A simpler solution might be to use pass
On Wed, 2 Jun 2004, Andre Oppermann wrote:
> The random generator indeed works badly. If it was truely random it
> should generate a collision only every (1/range) on average. Maybe
> the arc4random function reuses the same or small number of initial vectors
> all over again leading to the same
On Wed, 2 Jun 2004, Don Lewis wrote:
> Randomizing DNS query IDs without repeating any particular ID too
> quickly is a similar problem. I contributed some code to for this to
> BIND version 8 a number of years ago. See the nsid stuff in
> /usr/src/contrib/bind/bin/named/ns_main.c. There are s
On Fri, 18 Jun 2004, Igor Sysoev wrote:
Hi,
I read objections in cvs-all@ about netstat's output after MFC
of sendfile(2) statistics.
How about "netstat -ms" ?
Right now this switch combination is treated as simple "-m" in both -STABLE
and -CURRENT.
Igor Sysoev
http://sysoev.ru/en/
I would prefer t
On Thu, 17 Jun 2004, Alfred Perlstein wrote:
I was going to suggest vmstat now that sfbufs are used for so many
other things than just "sendfile bufs".
--
- Alfred Perlstein
How about if we do this:
5.x: List sfbufs both in vmstat _and_ in netstat -m, as their status is
relevant to both network a
On Tue, 29 Jun 2004, David Malone wrote:
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.
I'd rather see a sysctl that switched between incremental frag IDs and
arc4random() based IDs, followed by the removal of
On Sun, 11 Jul 2004 [EMAIL PROTECTED] wrote:
I have been told on other lists that the problem is with the firmware
version on the cards. I flashed them some time back with firmware v.1.7.4.
I have been told that only v. 1.5.6 and earler work with FreeBSD. That
sounded rather strange since the sam
On Tue, 24 Aug 2004, Bob Ababurko wrote:
Hello-
I have just done a portscan on my FreeBSD box running 5.2.1 and got :
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
111/tcp open rpcbind
1023/tcp open netvenuechat
now, i made a faux pas when i configured this m
On Mon, 11 Oct 2004, Eli Dart wrote:
In reply to Omer Faruk Sen <[EMAIL PROTECTED]> :
According to the very old article stated
http://www.totse.com/en/technology/computer_technology/162444.html there is
no way to tune time_wait timeout in FreeBSD. But since it is very old
article my question is thi
On Thu, 30 Sep 2004, Andrew Wenlang Zhu wrote:
Does any one know how to use Dummynet to fragment packet? Or any other open
source software can achieve this?
Thanks,
Andrew
I don't think that dummynet can fragment packets.
The program you're looking for is fragrouter, I think it's in ports.
Mike "Si
On Thu, 21 Oct 2004, Andre Oppermann wrote:
I want to bring this up for discussion prior to start working on it.
I intend to remove T/TCP (transactional TCP) support from our TCP
implementation for the following reasons:
That sounds good.
o The client has to enable the option in the TCP SYN request
On Fri, 29 Oct 2004, Ollie Cook wrote:
Good afternoon,
I am currently writing a potentially high bandwidth (think fileserver)
application which will proxy data from one PF_INET socket to another (no reason
it has to be PF_INET, but that's how the application stands).
In actual fact, I know in adva
On Mon, 15 Nov 2004, James wrote:
Folks,
Attached is initial code for ip6_fastforward() that I'm proposing for FreeBSD
5.x. This code was written for an internally modified FreeBSD 4.9, however in
I think that Andre Oppermann will have a lot of interest in this, but he's
on vacation at the moment,
On Fri, 19 Nov 2004, Tilman Linneweh wrote:
Synopsis: [patch] TCP should honour incoming RSTs even if the receive window is
closed
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: arved
Responsible-Changed-When: Fri Nov 19 12:02:29 GMT 2004
Responsible-Changed-Why:
ov
Synopsis: [patch] TCP should honour incoming RSTs even if the receive window is
closed
Responsible-Changed-From-To: freebsd-net->silby
Responsible-Changed-By: silby
Responsible-Changed-When: Fri Nov 26 08:09:32 GMT 2004
Responsible-Changed-Why:
Patch committed, hook into the regression test fram
On Sun, 28 Nov 2004, Heinz Knocke wrote:
Hi everybody!
While reading quite old but important RFC 1323 in chapter on RTT
measurement based on timestamps I found an opinion that:
" A solution to these problems (rough RTT estimation) which actually
simplifies the sender substantially, is as follows
There have been a few reports by users of front end web proxies and other
systems under FreeBSD that port randomization causes them problems under
load. This seems to be due to a combination of port randomization and
rapid connections to the same host causing ports to be recycled before the
IS
On Sat, 18 Dec 2004, Mike Silbersack wrote:
There have been a few reports by users of front end web proxies and other
systems under FreeBSD that port randomization causes them problems under
load. This seems to be due to a combination of port randomization and rapid
connections to the same
On Wed, 29 Dec 2004, Maxim Konovalov wrote:
On Wed, 29 Dec 2004, 03:02-0600, Mike Silbersack wrote:
This appears to work for Igor, and it seems safe enough to commit before
4.11-RC2. But, if possible, I'd like a few more sets of eyes to doublecheck
the concept and code; please take a look
With re's permission, I'm going to commit FreeBSD's fix for the RST part
of the slipping in the window attack to 4.11 in the next few days. That's
not a big deal, we seem to have an acceptable solution there. (See
tcp_input.c rev 1.235 for more info.)
The SYN side of the equation, however, is
On Mon, 3 Jan 2005, Charles Swiger wrote:
Are you relying on the IPID or the connection tuple of
srcIP+srcPort+destIP+destPort to identify the SYN packet as being associated
with an already established connection?
Connection tuple.
This means that SYN packets left of the window will no longer rec
On Mon, 3 Jan 2005, Don Lewis wrote:
For the life of me, I can't figure out why SYN packets (other than delayed
retransmissions of the original SYN) would ever show up once a connection
is in the ESTABLISHED state.
It can happen if one side of the connection crashes and tries to
reconnect using the
On Mon, 3 Jan 2005, Don Lewis wrote:
That's pretty much what previous versions of the draft suggested. The
earlier versions made some suggestions about how to deal with the corner
case by adjusting the sequence number in ACK, but these schemes added a
bunch of complexity and had some fatal flaws.
I
On Wed, 5 Jan 2005, Mark Allman wrote:
I ran this idea by Randall Stewart who has done a bunch of thinking on
this topic (and, helped produce one of the current internet-drafts on
the topic). He swayed me that my initial hit (above) might not be quite
right. Below is Randall's response to my forw
Ok, here's an updated patch for the SYN case. I've included the patch
relative to 6.x, and some text from a tcpdump showing it in action.
It responds to each SYN with an ACK like the latest tcpsecure document
states, but it uses a global counter to rate limit the number of ACKs of
this type th
On Mon, 10 Jan 2005, Don Lewis wrote:
Now that I've looked at the above case, it looks to me like your
suggested patch might affect the response to a legitimate duplicate SYN.
It will definitely follow a different code path.
You're right, I neglected to handle the duplicate SYN case.
Couldn't we ce
On Mon, 10 Jan 2005, Mike Silbersack wrote:
We could do something there like
if (th->th_seq != tp->irs) {
goto dropafterack; /* Or however we handle these bad syns */
} else {
thflags &= ~TH_SYN;
th->th_seq++;
if (th->th_urp > 1)
th->th_urp--;
else
On Tue, 11 Jan 2005, Lars Erik Gullerud wrote:
You didn't mention what MTA you are using, so I don't know if this is a
similar (application-level) issue, or if it's FreeBSD 4.10 that causes some
additional delay before initiating a TCP CLOSE, but either way, this might be
the behaviour you are o
I'd like to apologize to everyone for dropping the ball on this. I came
down with a cold on Monday evening, and was pretty out of it until
Thursday. By the time I had caught back up on everything I needed to, we
had already missed the window for 4.11. I'll get back into this in a few
days.
On Sun, 20 Feb 2005, Julian Elischer wrote:
I'm looking at implementing a kernel module that implelemnts an ABI that
allows a particular tcp session to be followed.
I'm not terribly intereted in the data sent/received bas in the actual
session
behaviour itself..
p.s. would this be generally usef
On Sun, 20 Feb 2005, Kris Kennaway wrote:
On Sun, Feb 20, 2005 at 07:40:35PM -0600, Mike Silbersack wrote:
Yes, I think that'd be very useful; when a user has a repeatable network
problem, we could have them turn this on and create a detailed log file
for us. In cases of reset connections
On Fri, 11 Mar 2005 [EMAIL PROTECTED] wrote:
As to how vulnerable FreeBSD is to this I do not know nor do I know if
we should bother to do anything about it. What, in particular are you
worried about here? Also, if you consider this a security issue you
should probably also include the security t
On Fri, 11 Mar 2005, Anthony Atkielski wrote:
How vulnerable is FreeBSD to the recently announced technique for
individually identifying computers by the clock slew apparent in TCP
packets? If it is vulnerable to this, will there be any plans to
address the vulnerability?
--
Anthony
I finally read
On Thu, 17 Mar 2005, John-Mark Gurney wrote:
Ok, since you wanted to look at it more... I have a working copy of
making packets alignment safe for ip in p4 at as change 73150:
http://perforce.freebsd.org/changeView.cgi?CH=73150&ignore=GO%21
This currently is only for arm and I plan to now remove th
On Fri, 18 Mar 2005, John-Mark Gurney wrote:
I'm confused - don't sparc64 and alpha have similar alignment
requirements? Why does arm require code changes?
yes, the alignment constraints for arm are the same.. the reason I
said the above is only for arm is the epe driver (which is only on
an ARM c
On Fri, 18 Mar 2005, John-Mark Gurney wrote:
Moving the alignment out of the drivers and into a common place seems like
a good idea, but I wonder if it should be done in the ethernet code
instead of in the ip code; won't other protocols have unaligned access
problems if the change is made exactly a
On Sat, 19 Mar 2005, Sten Spans wrote:
em with jumboframes is borken atm.
It seems some drivers don't handle the jumboframes -
chained mbufs case quite correctly.
--
Sten Spans
Totally broken, or broken when used on non-i386 architectures?
Mike "Silby" Silbersack
___
On Tue, 22 Mar 2005, Robert Gogolok wrote:
http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2003-May/000204.html is
the same problem or similar problem.
Forgot to mention thge important fact I use ipfw, bad bad...
With
# sysctl net.inet.ip.fw.dyn_keepalive=0
the FIN_WAIT_2 connections cleaned
On Thu, 28 Apr 2005, Bruce M Simpson wrote:
jmg's suggestion of bringing in the NetBSD patches to allow the entire
network stack to be compiled with unaligned accesses (for those platforms
which support it) is interesting because it can simplify or eliminate
some of the acrobatics needed in network
On Tue, 3 May 2005, Sten Spans wrote:
For the if_tap case fixing the driver ( or rather changing m_uiotombuf )
is definately the correct solution. No sensible person would say otherwise.
Once the if_tap change is properly tested and signed off it should
make it into the tree.
Yes, that makes sense.
I'll take a look at it while I'm at BSDCan next week. From your website's
description of the attack, I don't see why FreeBSD would be affected so
greatly... we must be wasting a lot of time traversing linked lists / etc.
Mike "Silby" Silbersack
On Mon, 2 May 2005 [EMAIL PROTECTED] wrote:
Greeti
On Sun, 8 May 2005, Suleiman Souhlal wrote:
The patch at http://people.freebsd.org/~ssouhlal/testing/
ip_reass-20050507.diff does just this.
Could you kindly test it?
Bye,
--
Suleiman Souhlal | [EMAIL PROTECTED]
The concept sounds ok, as long as it doesn't change how fragment
reassembly work
On Sun, 8 May 2005, Suleiman Souhlal wrote:
The patch at http://people.freebsd.org/~ssouhlal/testing/
ip_reass-20050507.diff does just this.
Could you kindly test it?
Bye,
--
Suleiman Souhlal | [EMAIL PROTECTED]
Your patch looks like it would defeat newdawn4, but it's not general
enough to o
On Thu, 12 May 2005, Matt Ruzicka wrote:
A couple days after we patched our systems, we started to receive a number
of reports of mysql connection errors when our patched FreeBSD 4.9 web
servers were trying to connect to our mysql server, which lives on a
separate FreeBSD machine.
Although you just
On Thu, 12 May 2005, Gandalf The White wrote:
# patch ip_reass-20050507.diff
Recompile kernel
I ran:
# top
I ran the test again and CPU utilization was at close to 98% to 99% in the
interrupt column.
Ken
Brooks Davis and myself ran some tests tonight while sitting around at
BSDCan and came to the
On Fri, 13 May 2005, Maxim Konovalov wrote:
[...]
So, test out my attached patch with varying settings of
maxfragspersecond and see if it makes any difference for you.
Am I right the above delta is a letfover from Suleiman's work and it's
not needed at all?
--
Maxim Konovalov
Correct, good catch!
M
On Fri, 13 May 2005, Matt Ruzicka wrote:
Hmm.. doesn't seem to have helped.
net.inet.ip.portrange.randomized: 0
net.inet.ip.portrange.randomcps: 10
net.inet.ip.portrange.randomtime: 45
Results of outbound port check:
pasiphae01.frii.com Fri May 13 09:44:26 2005 failed
Did I miss something?
Matth
On Fri, 13 May 2005 [EMAIL PROTECTED] wrote:
I attempted to apply the patch, but I think the date on my in_pcb.c is incorrect. What do I do to correct?:
I have revision 1.163 from 6-current.
Mike "Silby" Silbersack
___
freebsd-net@freebsd.org mailing lis
On Fri, 13 May 2005, Matt Ruzicka wrote:
Thank you both very much for all the help.
Incidentally those systems are now running 4.11 (patched today for htt).
Does the problem happen now that the system is upgraded to 4.11?
Mike "Silby" Silbersack
___
freeb
On Fri, 13 May 2005, Matt Ruzicka wrote:
Yes, it still does. And actually the script Maxim attached to his last
email (using our IP's) has an interesting side effect of causing the
connections to fail.
It doesn't fail right away, but within a few moments.
Are you perhaps exhausting all ports? Try
On Sat, 14 May 2005, Mike Jakubik wrote:
Im sorry, i mean to say receiving, not sending. I did try adjusting this,
but it made no difference. Just to recap:
Try changing net.inet.tcp.delayed_ack=0 and see if that changes anything.
Mike "Silby" Silbersack
On Fri, 20 May 2005, Jeremie Le Hen wrote:
Hi,
I tried to use my integrated wireless network card. I get the
iwicontrol(8) utility on Damien Bergamini's website [1], as well as
the firmware tarball. I use CURRENT's iwi(4) driver, I guess it's
the lastest revision as the driver of the website last
On Tue, 24 May 2005, Josef Karthauser wrote:
I tried that:
genius# ifconfig iwi0 up
genius# ifconfig iwi0
iwi0: flags=8802 mtu 1500
I've seen the same problem - with certain access points (or a certain
ordering of commands to bring the interface up?) the driver wouldn't
associate.
On Wed, 1 Jun 2005 [EMAIL PROTECTED] wrote:
We use SPECweb99 to experiment 300, 600 and 1000 simultaneous
connections on four testing platforms including the [EMAIL PROTECTED] on
FreeBSD v5.3, Apache v1.3.3 on FreeBSD v5.3, Apache v1.3.3 on Redhat
Enterprise Linux v3.0, and TUX 3.2.14 on Red
On Wed, 1 Jun 2005, jun lu wrote:
our project write a web server in freebsd kernel. we can receive and
send data directly in kernel.Now i have some idea, i think i can creat a
mbuf with cluster buffer before i send some data,because the data i want
to send are all in kernel,so i can take th
On Tue, 14 Jun 2005, PSI, Mike Smith wrote:
Idiot test requested by client - Same as above but see how fast 10,000
can be sent (will never come close to happening in the real world).
Problem: Because among other things I am using let's say minimal and
ancient computer power, I hit a DOS stat
1 - 100 of 382 matches
Mail list logo
