No it hasn't changed in 4.3-BETA ...
I have added
options NETGRAPH_FRAME_RELAY
options NETGRAPH_LMI
options NETGRAPH_SOCKET
options NETGRAPH_RFC1490
options NETGRAPH_IFACE
to my config and all is silent ...
cheers
mjt
> -Original Message-
> From: Udo Erdelhoff [SMTP:[EMAIL PROTECTED]]
Nick Rogness wrote:
>
> On Sat, 17 Mar 2001, Julian Elischer wrote:
>
> > Alex Pilosov wrote:
> > >
> > > On Sat, 17 Mar 2001, Nick Rogness wrote:
> > >
> > > > There is no way to tell your packet to go back out to ISP #2. That is the
> > > > point I'm trying to get across. Unless your running
Nick Rogness wrote:
>
>
> >
> > The final step is to select to which divert rule the packets eventually get
> > sent.
> > Each divert rule goes to a different natd, each of which is attached to a
> > different outgoing interface.
>
> I am going to look at what you suggested this afterno
On Sat, 17 Mar 2001, Wes Peters wrote:
> > >
> > >
> > > Packet 1 comes in through ISP #2 network. It comes into your
> > > internal network to machine 1. Machine 1 replies to the
> > > packet...but where does it go? It will exit through interface
> > > to ISP #1 becaus
Alex Pilosov wrote:
>
> On Sat, 17 Mar 2001, Garrett Wollman wrote:
>
> > That's the way Internet routing is supposed to work. If your routing
> > table says a packet supposed to go one way, and it really needs to go
> > another way, that's *user error* -- if you misconfigure your routing,
> >
Nick Rogness wrote:
>
> On Sat, 17 Mar 2001, Nick Rogness wrote:
>
> More clarification.
>
> >
> > > I completely fail to see that you have actually stated a problem yet.
> > >
> > > What exactly is the problem you think you're trying to solve here?
> > >
> >
> > Consider the following.
Alex Pilosov wrote:
>
> On Sat, 17 Mar 2001, Nick Rogness wrote:
>
> > There is no way to tell your packet to go back out to ISP #2. That is the
> > point I'm trying to get across. Unless your running a routing
> > daemon. But is that really practical with cable modems, dsl, etc?...I
> > don'
Nick Rogness wrote:
>
> On Sat, 17 Mar 2001, Wes Peters wrote:
>
> [Wes, if you get this, for some reason I can't send to your
> domain.]
>
> You are not understanding what I am trying to say. Once again I'll try to
> clarify.
>
> > > For dual-homed hos
On Sat, 17 Mar 2001, Garrett Wollman wrote:
> That's the way Internet routing is supposed to work. If your routing
> table says a packet supposed to go one way, and it really needs to go
> another way, that's *user error* -- if you misconfigure your routing,
> FreeBSD will do what you ask it to;
On Sat, 17 Mar 2001, Julian Elischer wrote:
> Alex Pilosov wrote:
> >
> > On Sat, 17 Mar 2001, Nick Rogness wrote:
> >
> > > There is no way to tell your packet to go back out to ISP #2. That is the
> > > point I'm trying to get across. Unless your running a routing
> > > daemon. But is that
On Sat, 17 Mar 2001, Garrett Wollman wrote:
> < said:
>
> > Packet 1 comes in through ISP #2 network. It comes into your
> > internal network to machine 1. Machine 1 replies to the
> > packet...but where does it go? It will exit through interface
> > to ISP #1 because of the
< said:
> Packet 1 comes in through ISP #2 network. It comes into your
> internal network to machine 1. Machine 1 replies to the
> packet...but where does it go? It will exit through interface
> to ISP #1 because of the default gateway. It came in ISP #2 and
> l
On Sat, 17 Mar 2001, Alex Pilosov wrote:
> On Sat, 17 Mar 2001, Nick Rogness wrote:
>
> > > b) route-cache means fast lookup of destination gateway. Lookup of
> > > destination gateway may be slow (see d), and it makes sense to keep track
> > > of a TCP connection and 'fast-switch' (cisco lingo)
On Sat, 17 Mar 2001, Julian Elischer wrote:
> this will do what you want for OUTGOING packets.
> incoming packets will probably all come in on one network.
And to fix this, you play tricks with your DNS server :)
A setup that I have at home:
Domain with two listed nameservers (same machine, diff
Alex Pilosov wrote:
> You don't need to know the interface. You must route based on the source
> IP. I.E:
>
> ISP A ISP B
> \ /
> ra rb
> \ /
> your router
> |
> |
> |
> (local)
>
> (ra
Alex Pilosov wrote:
>
> On Sat, 17 Mar 2001, Nick Rogness wrote:
>
> > There is no way to tell your packet to go back out to ISP #2. That is the
> > point I'm trying to get across. Unless your running a routing
> > daemon. But is that really practical with cable modems, dsl, etc?...I
> > don'
Nick Rogness wrote:
>
> On Sat, 17 Mar 2001, Nick Rogness wrote:
>
> There is no way to tell your packet to go back out to ISP #2. That is the
> point I'm trying to get across. Unless your running a routing
> daemon. But is that really practical with cable modems, dsl, etc?...I
> don't think
On Sat, 17 Mar 2001, Nick Rogness wrote:
> > b) route-cache means fast lookup of destination gateway. Lookup of
> > destination gateway may be slow (see d), and it makes sense to keep track
> > of a TCP connection and 'fast-switch' (cisco lingo) the following packets,
> > caching the following da
> On Sat, 17 Mar 2001 23:37:58 +0900 (JST)
> Hajimu UMEMOTO <[EMAIL PROTECTED]> said:
ume> I wish to support IPv6 for skeyaccess(3). With this patch, you can
ume> specify IPv6 address using `internet' keyword into /etc/skey.access.
ume> Please review it.
Oops, previous patch touched the
On Sat, 17 Mar 2001, Alex Pilosov wrote:
> On Sat, 17 Mar 2001, Nick Rogness wrote:
>
> > There is no way to tell your packet to go back out to ISP #2. That is the
> > point I'm trying to get across. Unless your running a routing
> > daemon. But is that really practical with cable modems, dsl
On Sat, 17 Mar 2001, Nick Rogness wrote:
> There is no way to tell your packet to go back out to ISP #2. That is the
> point I'm trying to get across. Unless your running a routing
> daemon. But is that really practical with cable modems, dsl, etc?...I
> don't think so.
Is the clue really gon
On Sat, 17 Mar 2001, Nick Rogness wrote:
More clarification.
>
> > I completely fail to see that you have actually stated a problem yet.
> >
> > What exactly is the problem you think you're trying to solve here?
> >
>
> Consider the following. I have to restate this every damn couple
On Sat, 17 Mar 2001, Wes Peters wrote:
[Wes, if you get this, for some reason I can't send to your
domain.]
You are not understanding what I am trying to say. Once again I'll try to
clarify.
> > For dual-homed hosts, this is a problem because your pa
Hi!
I try to install FreeBSD 4.1
when the proces of copying begin, (near 20% of /bin copied)
I receive such error
panic: general protection fault
syncing disks .. 99.. 99 99 99
automatic reboot in 15 seconds, press any key to abort.
Thank you very much for any help.
To Unsubscribe: sen
Nick Rogness wrote:
>
> On Fri, 16 Mar 2001, Jeroen Ruigrok/Asmodai wrote:
>
> > -On [20010310 04:00], Nick Rogness ([EMAIL PROTECTED]) wrote:
> > >
> > >Is anyone working on route caching functionality within FreeBSD? This
> > >would eliminate a lot of problems with using FreeBSD as a router..
Hi,
I wish to support IPv6 for skeyaccess(3). With this patch, you can
specify IPv6 address using `internet' keyword into /etc/skey.access.
Please review it.
Index: lib/libskey/skeyaccess.c
diff -u lib/libskey/skeyaccess.c.orig lib/libskey/skeyaccess.c
--- lib/libskey/skeyaccess.c.orig Mo
Dear All:
This message is to notify you of a new SCTP reference
implementation available at:
http://www.sctp.chicago.il.us
Version 4.0.3 is now the current version... now for
the list of features new to this implementation:
***IPv6 support.
***Support for FreeBSD kernel.
There has been MAJOR
On Fri, 16 Mar 2001, Jeroen Ruigrok/Asmodai wrote:
> am I correct in my assumption that all fixes needed for tcpdump can be
> handled in our own sources? Or do we need to send these to
> tcpdump.org?
I'm fairly sure we'll need to submit them to tcpdump.org.
I need to verify that I've got the IP
28 matches
Mail list logo