Re: vmmap replacement -- please test

2012-01-13 Thread Ariane van der Steldt
On Sat, Jan 07, 2012 at 11:47:32PM +0100, Juan Francisco Cantero Hurtado wrote: > On Fri, 06 Jan 2012 23:51:28 +0100, Ariane van der Steldt > wrote: > > I found and fixed the i386 bug. Please test this, to confirm that it > > fixes the problem (and doesn't introduce anything else, ofcourse). > >

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Theo de Raadt
> > From remote I could build a bot-net of machines that send you > > illegal fragments and, if you create a state of the bad mappings, you'd > > run your state table out. When the state table gets full, it will > > eject other stuff which is more important. Like ssh sessions and such. > > > > We

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Kenneth Gober
On Fri, Jan 13, 2012 at 1:44 PM, Theo de Raadt wrote: > From remote I could build a bot-net of machines that send you > illegal fragments and, if you create a state of the bad mappings, you'd > run your state table out. When the state table gets full, it will > eject other stuff which is more imp

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Alexander Bluhm
On Fri, Jan 13, 2012 at 11:44:20AM -0700, Theo de Raadt wrote: > > I have to drop them all, "including those not yet received". > > That last bit is crazy. You cannot maintain state until the potential > packets fall out of the fragment cache. This is also true for the reassembly implementation

Add OPENBSD-CARP-MIB to snmpd(8)

2012-01-13 Thread Joel Knight
Hi, This diff integrates my existing snmp MIB for carp(4) into the base snmpd. I brought the MIB straight across with no changes. The only limitation I'm aware of is that it doesn't support the multiple carpnodes style loadbalancing; it only reports status on the main carpnode. http://www.packetm

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Alexander Bluhm
On Fri, Jan 13, 2012 at 11:44:20AM -0700, Theo de Raadt wrote: > > I have to drop them all, "including those not yet received". > > That last bit is crazy. You cannot maintain state until the potential > packets fall out of the fragment cache. After discussion with deraadt@ it came clear that dr

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Theo de Raadt
> On Fri, Jan 13, 2012 at 02:13:09PM -0300, Fernando Gont wrote: > > If there was a fragment overlap, there was malicious activity, and > > you're certainly not going to get any legitimate fragment reassembled. > > Therefore, IMO, it doesn't make sense to tie resources (i.e., keep > > state) for th

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Alexander Bluhm
On Fri, Jan 13, 2012 at 02:13:09PM -0300, Fernando Gont wrote: > If there was a fragment overlap, there was malicious activity, and > you're certainly not going to get any legitimate fragment reassembled. > Therefore, IMO, it doesn't make sense to tie resources (i.e., keep > state) for that. > > I

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Simon Perreault
On 2012-01-13 12:13, Fernando Gont wrote: If you do not keep state, then. 1) If you don't get any further fragments, you saved memory and other resources, or, 2) If you do get other fragments, they'll be queued, and since other fragments were dropped, there won't be any reassembled datagram, and

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Fernando Gont
On 01/13/2012 12:11 PM, Alexander Bluhm wrote: > On Fri, Jan 13, 2012 at 11:01:43AM -0300, Fernando Gont wrote: >> On 01/12/2012 04:04 PM, Alexander Bluhm wrote: >>> I have reconsidered it and drop the fragments immediately. The >>> packet to be reassembled will be dropped after timeout. >> >> S

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Alexander Bluhm
On Fri, Jan 13, 2012 at 11:01:43AM -0300, Fernando Gont wrote: > On 01/12/2012 04:04 PM, Alexander Bluhm wrote: > > I have reconsidered it and drop the fragments immediately. The > > packet to be reassembled will be dropped after timeout. > > Sorry: immediately, or after a timeout? We have a l

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Fernando Gont
On 01/12/2012 02:45 PM, Kenneth Gober wrote: > I'd argue that you should drop all the "constituent fragments" as soon > as you receive them. > > Since there's no legitimate reason of overlapping fragments, get rid of > them asap. And if there were more fragments (for the same packe

libXi: SIGBUS in ParseClassInfo on sparc64

2012-01-13 Thread David Coppa
Hi! I've noticed that on sparc64 we got the same SIGBUS described here: http://comments.gmane.org/gmane.comp.freedesktop.xorg/44722 This happens frequently and it's annoying as it renders GTK2 applications unusable on sparc64, since our gtk+2 is being built using "--with-xinput". ---8<--- GNU

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Fernando Gont
Hi, Alexander, On 01/12/2012 04:04 PM, Alexander Bluhm wrote: > I have reconsidered it and drop the fragments immediately. The > packet to be reassembled will be dropped after timeout. Sorry: immediately, or after a timeout? Now pf > works like our IPv6 stack. > > - Sort pf_fragment fields