Re: m_reclaim and a protocol drain

2001-12-29 Thread Mike Silbersack
On Wed, 26 Dec 2001, Randall Stewart wrote: > This comment facinates me. The reason we made SACK's in SCTP > revokeable is due to the potential DOS attack that someone > can supposedly lauch if you don't allow the stack to revoke. > > I can actually see the reason that Sally made the comments >

Re: dummynet for IPv6?

2001-12-29 Thread Guangrui Fu
hi all, here is another related question, is bridge and ip6_fw supported in FreeBSD? any information on it is highly appreciated! thanks in advance, - Original Message - From: "Guangrui Fu" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 27, 2001

Re: routing sort of

2001-12-29 Thread Nick Rogness
On Sat, 29 Dec 2001, Aleksander Rozman - Andy wrote: > > Hi People! > > I am currently working on implementing new protocol (ax.25) on > FreeBSD. Now my problem is this. For device (SCC Card) there is no > driver on FreebSD yet (I will do that after I finish ax.25)... SO my > question is, would

Panic in radix.c

2001-12-29 Thread Nick Sayer
First, let me start out by saying that I have hacked in Kame's NATPT functionality into this kernel, so it's entirely possible that is causing this, but I thought I'd ask anyway. Here's a stack trace from this panic: (above this is the trap, savecore and reboot) #17 0xc018b973 in rn_match (v_a

routing sort of

2001-12-29 Thread Aleksander Rozman - Andy
Hi People! I am currently working on implementing new protocol (ax.25) on FreeBSD. Now my problem is this. For device (SCC Card) there is no driver on FreebSD yet (I will do that after I finish ax.25)... SO my question is, would it be possible to put this card on another machine (running linu

Re: Why is my ipfw(8) ``fwd'' rule to redirect a service to anothermachine not working?

2001-12-29 Thread Julian Elischer
On Fri, 28 Dec 2001, Crist J . Clark wrote: > On Fri, Dec 28, 2001 at 01:31:07PM -0800, Julian Elischer wrote: > > You need to > > correct the FAQ.. > > > > "The correct way to ensure that this does not happen is to also add > > a 'fwd' rule on the destination rule, forwarding the packet > >