Julian Elischer wrote:
>
> setfib 3 /bin/sh
>
> now by default everythign you do uses table 3.
> or even
>
> setfib 3 jail {blah}
>
> and all the procs in the jail use table 3. You also need to do
> setfib 3 jexec xxx
> for extra processes you add to the jail afterwards.
Is it possible to de
Dear all,
Last month, Kip Macy committed support for TCP offload to the FreeBSD CVS
repository for the Chelsio 10gbps device driver. We've had interest from
other vendors in supporting TOE on FreeBSD, although it remains unclear as yet
which will end up supporting it. This e-mail is about h
Vadim Goncharov wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops only.
In multicast, next-hops are normally just inte
Julian Elischer wrote:
OK, but we should think about it in the future. In theory, routing
socket's messages are easily extendable with FIB number in uint16_t,
as message keeps it's length...
I will do that with the advice of people who know that protocol better
than I do.
I'm afraid Linux
The following reply was made to PR kern/116837; it has been noted by GNATS.
From: Bob Van Zant <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: kern/116837: ifconfig tunX destroy: panic
Date: Sun, 6 Jan 2008 22:46:09 +0530
My FreeBSD 7.0-PRERELEASE box has been running into this prob
Mykola Dzham wrote:
Julian Elischer wrote:
setfib 3 /bin/sh
now by default everythign you do uses table 3.
or even
setfib 3 jail {blah}
and all the procs in the jail use table 3. You also need to do
setfib 3 jexec xxx
for extra processes you add to the jail afterwards.
Is it possible to d
Robert Watson wrote:
There's also the opportunity to think about whether it's possible to
harden things in such a ways as to not give up our flexibility to keep
maintaining and improving TCP (and other related subsystems), yet
improving the quality of life for a third party TOE driver maint
Bruce M. Simpson wrote:
Vadim Goncharov wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops only.
In multicast, next-ho
On Sun, 6 Jan 2008, Julian Elischer wrote:
There's also the opportunity to think about whether it's possible to harden
things in such a ways as to not give up our flexibility to keep maintaining
and improving TCP (and other related subsystems), yet improving the quality
of life for a third pa
Hey All,
I piped up a couple of weeks before Christmas regarding a need to control or at
least reliably predict which packets a system would drop if too many packets
where being received by the kernel destined for a BPF program. My particular
example here is a copy of Snort monitoring a mirror of
07.01.08 @ 00:10 Julian Elischer wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops
only. In multicast, next-hops ar
On Jan 6, 2008 5:47 AM, Robert Watson <[EMAIL PROTECTED]> wrote:
...
> My proposal, and this is really a proposal to drive discussion as much as a
> proposal for a policy, is that the internal TCP data structures exported via
> the TOE interfaces and accessed by TOE device drivers *not* be conside
07.01.08 @ 02:00 Peter Wood wrote:
Hey All,
I piped up a couple of weeks before Christmas regarding a need to
control or at
least reliably predict which packets a system would drop if too many
packets
where being received by the kernel destined for a BPF program. My
particular
example her
Vadim Goncharov wrote:
07.01.08 @ 00:10 Julian Elischer wrote:
Is multicast and multipath routing the same?
No. They are currently orthogonal.
However it makes sense to merge the multicast and unicast forwarding
code as currently MROUTING is limited to a fan-out of 32 next-hops
only. In m
Evening,
I don't think that modifying bpf.c is good solution, as userland is not
the only consumer of BPF, think, for example, about ng_bpf. Moreover,
what is the purpose of sampling, after all? BPF was never intended to be
reliable every-packet solution.
Certainly other things do use BPF,
Hi,
I am looking for user-space PPP source code, but couldn't find it. Could
you please let me know the path from where I can download it?
Thanks and regards
Krishnan
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/list
16 matches
Mail list logo
