Jun-ichiro itojun Hagino wrote:
1/ removal of "control" argument from rip6_input and prepend control mbuf
to chain AS IT WAS DESIGNED FOR. This makes rip6_input conform to the proto
type for input. (I have not confirmed that the information in control
is a valid mbuf but it is an mbuf
Robert Watson wrote:
It strikes me that, although some code cleanup may be called for, a week
is too agressive a deadline for many of them to be pushed through,
especially in light of the code maintenance issue on the KAME side.
I sugggest no changes in 4.x
They have had over a year for
Please note that the ip6protosw is ALSO very broken
unfortunately, you are wrong. yes, protosw is supposed to be
protocol-independent. however, due to the nature of IPv6 extension
headers (you can have infinite number of them) you can blow the kernel
stack very
Well what is there now is plainly unacceptable
I think that it was asked for as a VERY SHORT TERM hack.
But it has been there a long time...
I see no reasons so far to not make most of these changes..
well, you are ignoging our design decisions. they are all done
for reasons.
On Mon, 13 Aug 2001, Barry Irwin wrote:
Hi All
Just wondering if anyone else has experiance the following problem:
I have a number of networks running with FreeBSD firewalls providing a
nat service to a number of hosts behind the wall itself. Both outgoing
nat, and port_redirection is
On Tue, 14 Aug 2001, Vladimir Savichev wrote:
heres my howto, should work easy, i applied the frag/signal/telnet patches
after applying the kame/altq patches
http://www.paladincorp.com.au/unix/altq/
couldn't find /altq in FreeBSD/src, Open(6week)/NetBSD(7month) are up
with it ? seems
