On Thu, 9 Sep 2010, Vlad Galu wrote:
> 2010/9/9 Marat N.Afanasyev :
> > I wonder, are these dynamic rules really necessary? let's see, a client
> > connects to your web-server and you immediately should create a new dynamic
> > rule, therefore you participate in this DoS attack as well as attac
On Thursday, September 09, 2010 3:04:27 pm Jack Vogel wrote:
> On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote:
>
> > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote:
> > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote:
> > >
> > > > Hi!
> > > >
> > > > > > Is this within a
On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote:
> On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote:
>
> > Hi!
> >
> > > > Is this within a jail or something else along those lines? I can't
> > > > reproduce the problem otherwise. Frustrating! Someone else on the
> > list
> > > >
Hi,
I recently tried enabling MCA (ie w.mca.enabled=1 in loader.conf) on an
8.0-STABLE system and found that it would cause the system to hang after a few
minutes of uptime.
The screen would go black and the monitor would turn off (regardless of wether
it was in X or not) and only a hard reset
On Thu, 9 Sep 2010, Kevin Oberman wrote:
Hey,
I think I should try to summarize parts of the ISDN topic, which I
have been disconnected from for more than 2 years now, to make this
tail of a thread more helpful maybe.
I agree that later release notes could have mentioned it but neither
did the
2010/9/9 Marat N.Afanasyev :
> I wonder, are these dynamic rules really necessary? let's see, a client
> connects to your web-server and you immediately should create a new dynamic
> rule, therefore you participate in this DoS attack as well as attacker. ;)
With a stateless firewall, you help the
> Date: Thu, 09 Sep 2010 22:03:10 +0400
> From: "Marat N.Afanasyev"
> Sender: owner-freebsd-sta...@freebsd.org
>
> Gareth de Vaux wrote:
> > Hi again, I use some keep-state rules in ipfw, but get the following
> > kernel message:
> >
> > kernel: ipfw: install_state: Too many dynamic rules
> >
> >
Gareth's email bouncing for anybody else or is it just me?
Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at boot
btw.
Tell me more exactly the make/model of the hardware so I might try to get
my hands on one?
Jack
On Thu, Sep 9, 2010 at 1:20 PM, John Baldwin wrote:
> On T
On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote:
> On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote:
> > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote:
> >
> > > Hi!
> > >
> > > > > Is this within a jail or something else along those lines? I can't
> > > > > reproduce the pr
Gareth de Vaux wrote:
Hi again, I use some keep-state rules in ipfw, but get the following
kernel message:
kernel: ipfw: install_state: Too many dynamic rules
when presumably my state table reaches its limit (and I effectively
get DoS'd).
netstat shows tons of connections in FIN_WAIT_2 state,
> Date: Thu, 09 Sep 2010 12:33:57 +0300
> From: Andriy Gapon
> Sender: owner-freebsd-sta...@freebsd.org
>
> on 09/09/2010 11:22 per...@pluto.rain.com said the following:
> > Good, perhaps even "necessary", but is it "sufficient"? Those
> > following a -STABLE branch are expected to read stable@,
On Thu, 9 Sep 2010, Gareth de Vaux wrote:
> Hi again, I use some keep-state rules in ipfw, but get the following
> kernel message:
>
> kernel: ipfw: install_state: Too many dynamic rules
>
> when presumably my state table reaches its limit (and I effectively
> get DoS'd).
>
> netstat sh
On 09/08/2010 06:44, Vadim Goncharov wrote:
> Hi Mark Linimon!
>
> On Wed, 8 Sep 2010 07:30:19 +; Mark Linimon wrote about 'Re: HEADS UP:
> FreeBSD 6.4 and 8.0 EoLs coming soon':
>
The reason is performance for overall network stack, not ideology.
>
>>> For a practical reasons, "it wo
Hi!
> > Basically, when the securelevel is positive, the kernel restricts
> > certain tasks; not even the superuser (i.e., root) is allowed to
> > do them.
> OH YUCK, another root isn't really root, so is it also possibly
> the reason for the MSIX failure?? Is this pile, er feature, on by default
On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote:
> Hi!
>
> > > Is this within a jail or something else along those lines? I can't
> > > reproduce the problem otherwise. Frustrating! Someone else on the
> list
> > > might have ideas as to what could cause this.
> >
> > Nope, this's a normal h
On Thu 09 Sep 2010 at 08:35:29 -0700, Jeremy Chadwick wrote:
> Regardless, when it comes to building world and kernel, you should
> follow the instructions in /usr/src/Makefile (there's 11 steps). Do not
> skip steps, and do not avoid steps (such as doing installkernel then
> skipping the boot-int
On Thu, Sep 09, 2010 at 05:39:02PM +0200, Gareth de Vaux wrote:
> Hi again, I use some keep-state rules in ipfw, but get the following
> kernel message:
>
> kernel: ipfw: install_state: Too many dynamic rules
>
> when presumably my state table reaches its limit (and I effectively
> get DoS'd).
>
Hi again, I use some keep-state rules in ipfw, but get the following
kernel message:
kernel: ipfw: install_state: Too many dynamic rules
when presumably my state table reaches its limit (and I effectively
get DoS'd).
netstat shows tons of connections in FIN_WAIT_2 state, mostly to
my webserver.
On Thu, Sep 09, 2010 at 05:24:00PM +0200, Olaf Seibert wrote:
> Thomas Ronner wrote:
>
> > I don't know about the old-fashioned way, but the new way is:
> >
> > # cd /usr/src
> > # make buildkernel KERNCONF=GENERIC
> > # make installkernel KERNCONF=GENERIC
>
> Thank you, that worked.
>
> I wond
Thomas Ronner wrote:
> I don't know about the old-fashioned way, but the new way is:
>
> # cd /usr/src
> # make buildkernel KERNCONF=GENERIC
> # make installkernel KERNCONF=GENERIC
Thank you, that worked.
I wonder what the underlying difference is; probably something fairly
subtle. The same hac
On Thu 2010-09-09 (16:54), Kurt Jaeger wrote:
> -c asks for pci device capabilities, which are read in
>
> /usr/src/usr.sbin/pciconf/pciconf.c:177 with O_RDWR
Ah. I'll have to schedule a reboot then ..
___
freebsd-stable@freebsd.org mailing list
http://
Jeremy Chadwick wrote:
On Thu, Sep 09, 2010 at 04:22:26PM +0200, Gareth de Vaux wrote:
On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote:
You need to be root to use the -c flag. Despite your prompt, I don't
think you're root. Reproduction:
That was as root,
# id
uid=0(root) gi
Hi!
> > > Is this within a jail or something else along those lines? I can't
> > > reproduce the problem otherwise. Frustrating! Someone else on the list
> > > might have ideas as to what could cause this.
> >
> > Nope, this's a normal host. I've got securelevel on 1, but doubt that
> > would
On Thu, Sep 9, 2010 at 4:22 PM, Gareth de Vaux wrote:
> On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote:
> > You need to be root to use the -c flag. Despite your prompt, I don't
> > think you're root. Reproduction:
>
> That was as root,
>
> # id
> uid=0(root) gid=0(wheel) groups=0(wheel),5(ope
On 7 September 2010 18:50, Jeremie Le Hen wrote:
> Hi list,
>
> => Please Cc: me when replying, as I am not subscribed. <=
>
> I tried to install FreeBSD (201008 -CURRENT snapshot, but I don't think
> it's important here) in a KVM-backed virtual machine on a headless Linux
> host, following sectio
on 09/09/2010 17:07 Vadim Goncharov said the following:
>
> Because this thread is not about this feature but about policy which will
> slowly bring FreeBSD project to troubles if nothing will be changed.
Your opinion is noted.
--
Andriy Gapon
___
fre
Hi!
> > Is this within a jail or something else along those lines? I can't
> > reproduce the problem otherwise. Frustrating! Someone else on the list
> > might have ideas as to what could cause this.
>
> Nope, this's a normal host. I've got securelevel on 1, but doubt that
> would affect this?
On Thu 2010-09-09 (07:24), Jeremy Chadwick wrote:
> Is this within a jail or something else along those lines? I can't
> reproduce the problem otherwise. Frustrating! Someone else on the list
> might have ideas as to what could cause this.
Nope, this's a normal host. I've got securelevel on 1,
On Thu, Sep 09, 2010 at 04:22:26PM +0200, Gareth de Vaux wrote:
> On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote:
> > You need to be root to use the -c flag. Despite your prompt, I don't
> > think you're root. Reproduction:
>
> That was as root,
>
> # id
> uid=0(root) gid=0(wheel) groups=0(wh
On Thu 2010-09-09 (07:02), Jeremy Chadwick wrote:
> You need to be root to use the -c flag. Despite your prompt, I don't
> think you're root. Reproduction:
That was as root,
# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
# pciconf -lc
pciconf: /dev/pci: Operation not permitted
__
Hi Olaf,
On 09/09/2010 16:17, Olaf Seibert wrote:
I'm trying to build a custom kernel, and I got an error. So I tried
GENERIC, in the perhaps old-fashioned way of
# config GENERIC
# cd ../compile/GENERIC
# make depend
# make
I don't know about the old-fashioned way, but t
I'm trying to build a custom kernel, and I got an error. So I tried
GENERIC, in the perhaps old-fashioned way of
# config GENERIC
# cd ../compile/GENERIC
# make depend
# make
and I get a complaint about a file named ``hack.So''. Here is what
happens if I remove it again to get it
Hi Andriy Gapon!
On Thu, 09 Sep 2010 12:33:57 +0300; Andriy Gapon wrote about 'Re: Policy for
removing working code':
>> Good, perhaps even "necessary", but is it "sufficient"? Those
>> following a -STABLE branch are expected to read stable@, but
>> what about those who are following a securit
On Thu, Sep 09, 2010 at 03:10:17PM +0200, Olaf Seibert wrote:
> I just upgraded a box from 8.0 to 8.1, and already when rebooting with
> the new kernel (i.e. before installing new userland), I got the
> following problem.
>
> Of course many of the messages scrolled off screen, but some were
> pres
Hi Scot Hetzel!
On Thu, 9 Sep 2010 04:18:52 -0500; Scot Hetzel wrote about 'Re: Policy for
removing working code':
>>> We can't e-mail announce@ every time something is going to
>>> be removed. That would be way too much spam for that list.
>>
>> That may depend on how often something substant
On Thu, Sep 09, 2010 at 03:25:19PM +0200, Gareth de Vaux wrote:
> On Thu 2010-09-09 (06:13), Jeremy Chadwick wrote:
> > Can you add the "-c" flag to your pciconf command? Thanks.
>
> Forbidden?
>
> # pciconf -lvc
> pciconf: /dev/pci: Operation not permitted
> # pciconf -lc
> pciconf: /dev/pci:
Hi John Baldwin!
On Wed, 8 Sep 2010 10:21:47 -0400; John Baldwin wrote about 'Re: Policy for
removing working code':
>>> No, that would require maintaining two network stacks, not just one. The
>>> shims to allow unlocked code to run were not trivial. The choices were
>>> this:
>>
>>> 1) Mo
Hi Andriy Gapon!
On Wed, 08 Sep 2010 17:13:29 +0300; Andriy Gapon wrote about 'Re: Policy for
removing working code':
>> network stack, it is deeper. It is the policy or may be style of thought,
>> discourse. Something like:
>>progress dictates we need fix/maintainership to feature X
>> &
I just upgraded a box from 8.0 to 8.1, and already when rebooting with
the new kernel (i.e. before installing new userland), I got the
following problem.
Of course many of the messages scrolled off screen, but some were
preserved in the syslog.
Sep 9 14:26:51 fourquid mountd[839]: can't get addr
On Thu 2010-09-09 (06:13), Jeremy Chadwick wrote:
> Can you add the "-c" flag to your pciconf command? Thanks.
Forbidden?
# pciconf -lvc
pciconf: /dev/pci: Operation not permitted
# pciconf -lc
pciconf: /dev/pci: Operation not permitted
# ls -l /dev/pci
crw-r--r-- 1 root wheel0, 9 Sep
On Thu, Sep 09, 2010 at 02:54:01PM +0200, Gareth de Vaux wrote:
> On Wed 2010-09-08 (09:41), Jack Vogel wrote:
> > This is what'd I'd expect, the onboard is PCH chipset, support was not in
> > 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it
> > should
> > work.
>
> I've ju
On Wed 2010-09-08 (09:41), Jack Vogel wrote:
> This is what'd I'd expect, the onboard is PCH chipset, support was not in
> 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should
> work.
I've just paid the machine a visit and yes, MSIX fails on the onboard but
the device sti
2010/9/9 Andriy Gapon :
> on 09/09/2010 12:33 Andriy Gapon said the following:
>> People, who care, are expected to read current@ and stable@ even if they use
>> only releases and security branches. At the very least, to see what's
>> cooking
>> up for them and what to expect.
>
> Not to mention
on 09/09/2010 14:19 nickolas...@gmail.com said the following:
> 2010/9/9 Andriy Gapon :
>> on 09/09/2010 12:33 Andriy Gapon said the following:
>>> People, who care, are expected to read current@ and stable@ even if they use
>>> only releases and security branches. At the very least, to see what's
on 09/09/2010 11:22 per...@pluto.rain.com said the following:
> Good, perhaps even "necessary", but is it "sufficient"? Those
> following a -STABLE branch are expected to read stable@, but
> what about those who are following a security branch?
People, who care, are expected to read current@ and
on 09/09/2010 12:33 Andriy Gapon said the following:
> People, who care, are expected to read current@ and stable@ even if they use
> only releases and security branches. At the very least, to see what's cooking
> up for them and what to expect.
Not to mention isdn@ for this particular case.
BTW,
On Thu, Sep 9, 2010 at 3:22 AM, wrote:
> John Baldwin wrote:
>
>> We can't e-mail announce@ every time something is going to
>> be removed. That would be way too much spam for that list.
>
> That may depend on how often something substantial is removed :)
>
>> I do think stable@ is a good place
On Thu, Sep 09, 2010 at 01:22:22AM -0700, per...@pluto.rain.com wrote:
> John Baldwin wrote:
>
> > We can't e-mail announce@ every time something is going to
> > be removed. That would be way too much spam for that list.
>
> That may depend on how often something substantial is removed :)
If m
John Baldwin wrote:
> We can't e-mail announce@ every time something is going to
> be removed. That would be way too much spam for that list.
That may depend on how often something substantial is removed :)
> I do think stable@ is a good place to e-mail ...
Good, perhaps even "necessary", but
49 matches
Mail list logo
