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
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 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 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 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 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, 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 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 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 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 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 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 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 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 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 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:
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:
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 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 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 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, 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 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 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 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 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 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, 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 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, 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 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 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, 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 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
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 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
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 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 Sat, 3 Mar 2007, Peter Jeremy wrote:
Disabling net.inet.ip.portrange.randomized appears to work around this
but is undesirable for other reasons.
I should add that in the short term, that does seem to be the only
solution.
Fernando Gont has some ideas on how to make port reuse happen le
On Sat, 3 Mar 2007, Peter Jeremy wrote:
First problem: FreeBSD appears to be re-using source ports too
rapidly. My understanding is that a TCP socket ({src IP, src port,
dst IP, dst port} tuple) should not be re-used for 120 seconds after
teardown. Sample tcpdumps and IPfilter whinges below
On Wed, 17 Jan 2007, Ricardo Nabinger Sanchez wrote:
Hello,
Accidentally I got into this PDF:
http://www.dcs.qmul.ac.uk/~awm/slides/masterclass2006/monitor-hardware.pdf
Quite interesting results, and nice future work. Has anybody seen it
already?
I believe that there is a FreeBSD develope
On Wed, 24 Jan 2007, Randall Stewart wrote:
Well.. no I believe someone (was in Lin) mentioned that
you can get a live-lock if you allow a reduction.. and
thus the mbuf clusters were NOT allowed to be reduced..
I messed around with this a bit when changing the limit on
net.inet.tcp.maxtcptw.
On Fri, 29 Sep 2006, Randall Stewart wrote:
> Hmm.. I would think 512b and 1K will not show any
> improvement.. since they would probably end up either
> in an mbuf chain.. or a single 2k (or maybe 4k) cluster..
I know, I just want to make sure that it doesn't somehow cause performance
loss for
On Fri, 29 Sep 2006, Andre Oppermann wrote:
> over it an copies the data into the mbufs by using uiomove(). sosend_dgram()
> and sosend_generic() are change to use m_uiotombuf() instead of
> sosend_copyin().
Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to
see if perfo
Although it sounds silly, could you try recompiling 6.1 and 7.0 with a
non-SMP kernel and see how they perform? That would at least tell us if
it's a general performance problem in 6.x and 7.x, or if SMP is somehow
hurting performance in this case.
Mike "Silby" Silbersack
_
On Mon, 14 Aug 2006, Simon Walton wrote:
Thanks. I did not go with ipfw2 partly because of concerns about
whether it was stable enough (this is on 4.10) and also because
it requires rebuilding part of userland. Perhaps this would
be the way to go after all.
The only way you'll know is to try
On Fri, 18 Aug 2006, Chris wrote:
whats the point of keeping a connection alive (hung) to a dead network
for 2 hours tho? That I dont understand either.
Chris
I used to wonder that myself. From the perspective of minimizing the
number of open sockets, it makes sense to kill connections to
On Fri, 11 Aug 2006, Simon Walton wrote:
Is there any reason why the default initial timeout for keep alive
packets needs to be as long as two hours? This period causes the dynamic
rules in my firewall filter to timeout.
Is there a major objection to reducing the default idle time to
say 3
On Tue, 23 May 2006, Ratan Dey wrote:
Hi,
I have a motherboard ASUS NCL-DE/SCSI. This motherboard has a built in NIC
card of BROADCOM 5700. I am using FreeBSD 5.4 and i am not able to use my NIC
card.
So how can i utilized this BROADCOM 5700 NIC in freebsd 5.4
Regards-
Rata
The bge d
It's been nearly four years, I was wondering if anyone has had a thought
on this change yet. :)
Mike "Silby" Silbersack
-- Forwarded message --
Date: Tue, 30 Jul 2002 15:15:55 -0500 (CDT)
From: Mike Silbersack <[EMAIL PROTECTED]>
To: freebsd-net@fre
On Tue, 7 Mar 2006, Julian H. Stacey wrote:
Looks to me like skyr decided to close the connection, and it closed as
expected. I think the problem is probably above the TCP layer - have you
tried an older version of rlogin to see if that makes a difference?
Hmm. Thanks Mike,
Until you wrote t
On Tue, 28 Feb 2006, Julian H. Stacey wrote:
---
& the only things I typed into that box were
rlogin skyr
ls
I had previously started in another xterm
tcpdump -v -i rl0 -l | grep skyr
& got this:
---
20:49:03.103230 IP (tos 0x0, ttl 15, id 240, offset 0, flags
> Thanks Mike,
> Well I fixed a local problem of parity on my FreeBSD end, by changing to
> XTerm*eightBitInput:False
> XTerm*eightBitOutput: False
> xrdb -merge ~/.Xdefaults
> But rlogins & telnets to the 4.2BSD Symmetric still die af
On Mon, 27 Feb 2006, Julian Stacey wrote:
Anyone know if modern FreeBSD still supports TCP_COMPAT_42 ?
TCP_COMPAT_42 just tweaked how we generated TCP initial sequence numbers.
The lack of it should not be impacting your ability to connect to machines
of any vintage.
Mike "Silby" Silbersa
On Wed, 1 Feb 2006, Greg 'groggy' Lehey wrote:
Last week, at the Linux.conf.au in Dunedin, Van Jacobson presented
some slides about work he has been doing rearchitecting the Linux
network stack. He claims to have reduced the CPU usage by 80% and
doubled network throughput (he expects more, but
On Mon, 2 Jan 2006, Attila Nagy wrote:
I use pf on all machines, if that counts...
... yes, that counts. Without pf it works OK, but when I load a simple pass
only ruleset, it breaks.
Someone else reported this problem a few weeks ago, he said that it occurs
when hz is set > 1000. Do you h
> Ed Maste wrote this message on Wed, Dec 14, 2005 at 13:07 -0500:
>> It seemed this behaviour appeared in v 1.130 of uipc_mbuf.c. The
>> patch below restores the behaviour of putting MCLBYTES into the
>> initial mbuf cluster.
>>
>> Comments?
>
> Looks correct to me... I assume you've tested this?
On Sat, 26 Nov 2005, Julian Elischer wrote:
In this world of P2P apps it would be neat to have a way that two P2P apps
could attach to each other even though each is through a firewall. Most
firewalls only allow
"outgoing" connections.
Go research Microsoft's uPnP firewall support.
Mike "S
On Sat, 12 Nov 2005, Mike Silbersack wrote:
Does anyone have a Cisco router running an up to date version of IOS that
they would be willing to run some tests on for me? I'm running tests vs the
TCP stacks of various operating systems for my eurobsdcon presentation, and
IOS is the one
Does anyone have a Cisco router running an up to date version of IOS that
they would be willing to run some tests on for me? I'm running tests vs
the TCP stacks of various operating systems for my eurobsdcon
presentation, and IOS is the one OS I can't seem to download and install
inside VMWa
On Tue, 8 Nov 2005, Lars Eggert wrote:
Also note that other attacks against long-lived TCP connections are still
possible, e.g., through spoofed ICMP packets.
I don't think we've been vulnerable to the ICMP-based reset attack for a
few years, actually. Using SYN packets is the best method,
On Tue, 8 Nov 2005, Lars Eggert wrote:
Thus, I'd like to suggest that the default for net.inet.tcp.insecure_rst be
zero for now. AFAIK, any other TCP mod came disabled be default in the past,
too.
Lars
I'm open to discussing the change. I plan to revisit that and the SYN
causing a connec
On Tue, 18 Oct 2005, Anton Bester wrote:
Hi All,
I do not know if this is the correct forum for this questions, if not please
point me in the right direction.
My secondary DNS server all of a sudden started to chop up about 100% of
my server's cpu, I'm running a FreeBSD 5.1-RELEASE server w
Sorry for the delay, you took me out of the To: listing, so the message
just went into my lists box, which I didn't get to until today.
On Fri, 14 Oct 2005, Nicolas KOWALSKI wrote:
Assuming that port reuse is the problem, there is no quick fix for
this, just resetting connections when a SYN
On Sun, 9 Oct 2005, Jan Mikael Melen wrote:
Hi,
I have the D-Link DWL-G520 which has the atheros 5212 chip. When rebooting the
FreeBSD 6.0-BETA5 after the final sync kernel panics. If the if_ath module has
not been loaded in to the memory all works fine. Does anyone have any good
idea how to g
On Fri, 14 Oct 2005, [EMAIL PROTECTED] wrote:
Nicolas KOWALSKI wrote:
Our FreeBSD 4.10 NFS server has some problems serving files by NFS on
TCP (no problem with UDP) when the Linux (2.6) or Solaris (5.9)
clients shut down in an unclean manner (power failure). When the clients
try to mount the
On Tue, 11 Oct 2005, Olivier Nicole wrote:
I am facing the following problem: I have a web server with an
application that calls a MySQL server.
For class and test run, I may have 100 users accessing the same web
page to login to the same database.
Well, it seems that was due to a bad instal
On Mon, 10 Oct 2005, Olivier Nicole wrote:
FreeBSD has no SYN rate limit, but you could be running into TIME_WAIT
recycling issues.
I already set tcp.msl to 5000 to release the TIME WAIT quickly.
I should really remove that sysctl...
It's tangential to the problem, that would only help if
On Mon, 10 Oct 2005, Olivier Nicole wrote:
For some reason, it seems that the MySQL server only accepts 50
connections to the same resource comming from the same client at one
given time. 50 other connections are in SYN_SENT state.
Any reason why this limit?
FreeBSD has no SYN rate limit, bu
On Thu, 8 Sep 2005, Olivier Nicole wrote:
Hi Mike,
First of all, the redirection you speak of - is that occuring on the local
machine itself, or a physically seperate machine?
Yes same machine.
Then my guess is that something is wrong with your redirection setup.
Unfortunately, tcpdump s
On Thu, 8 Sep 2005, Olivier Nicole wrote:
When I try to connect via a redirection through the firewall, I got a
RST after the SYN, SYN/ACK, ACK.
OK here is a step further, the rest occures because of syncache_expand
that return 0 on line 722 of tcp_input.
Any reason why the syncache is empty
On Wed, 3 Aug 2005, Dave+Seddon wrote:
For some reason, the 'current' can be WAAAY higher than the 'max' which
seems very odd. I've tried putting the 'max' right up to 5 billion, however
it only goes to 2.1 billion.
Argh, kris beat me to mentioning the statistics problem.
Well, I'd add anot
On Wed, 15 Jun 2005, Jeremie Le Hen wrote:
Hi Mike,
5.x has some features so that it does not allow too many TIME_WAIT sockets
to build up beyond a certain threshold, but if you're using 4.x we can
still tweak some sysctl values to achieve the effect you want.
Would you mind being a little
On Wed, 15 Jun 2005, PSI, Mike Smith wrote:
The buildup of the TIME_WAIT sockets is on the SERVER side. And I am using
FreeBSD 4.7 (with an incredible amount of kernel mods for ISO, QOS,
Air/Ground communications support, etc.) Mods don't affect this problem but
is why I am stuck with FreeBSD 4
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
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 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 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 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 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, 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 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 [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:
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, 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 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 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 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 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
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 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.
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, 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 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 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 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 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, 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 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
1 - 100 of 382 matches
Mail list logo
