[EMAIL PROTECTED] wrote:
my guess is that you have some issue with routing setup.
last time, you had some wacky static routes to help source address
selection (i do not really recommend that). do you still have them?
if so, please show them to us (to mailing
my guess is that you have some issue with routing setup.
last time, you had some wacky static routes to help source address
selection (i do not really recommend that). do you still have them?
if so, please show them to us (to mailing list) with in the script.
Hi all,
As I regularly attend lan parties with plenty of people,
I thought that i'd give ng_bridge a go as opposed to the kernel
bridging.
The test box was a P200 with 64MB of ram,
network cards were:
2x Intel EtherExpress Pro/100B
1x SMC card with a DC21040 chipset
1x SMC card with a DEC/Intel
sorry if you felt offended. i really think it is issue in routing
table, as multiple SPD configuration works just fine here.
still, there's of course a possibility that you have stepped onto
some untested code. KAME SNAP kit is, as documented, very experimental
Gunther Schadow wrote:
I would shut up. But so far I have not seen proof for a complex
VPN setup with KAME that does work.
We use our X-Bone software (http://www.isi.edu/xbone/) to frequently
create and remove complex overlays (tens of nodes in various topologies)
with dynamic routing and
sorry if you felt offended. i really think it is issue in routing
table, as multiple SPD configuration works just fine here.
still, there's of course a possibility that you have stepped onto
some untested code. KAME SNAP kit is, as documented, very experimental
[EMAIL PROTECTED] wrote:
sorry if you felt offended. i really think it is issue in routing
table, as multiple SPD configuration works just fine here.
still, there's of course a possibility that you have stepped onto
some untested code. KAME SNAP kit is, as
Hi,
at the risk of flooding the net with my thoughtbubbles: I (eventually)
need to use ALTQ, IPsec and IPFILTER alltogether on one FreeBSD set-top
box machine (PicoBSD). And I'm afraid of interactions or mutual
exclusions of these packages. I did make IPsec and IPFILTER work
together (that is, I
Gunther Schadow wrote:
However, I am afraid that ALTQ
is not supported on gif pseudo-devices as it seems that ALTQ wants
to deal with things like DMA etc, i.e., real NIC hardware.
ALTQ kicks in at the boundary between network and link layer -
basically, it replaces the send queue of an
Lars Eggert wrote:
The bad news is that all the gif device does is prepend another IP
header, and call ip_output(). Which means that it has no outgoing queue
to which you could apply ALTQ to.
ugh, so that means ALTQ can't be used on the GIF tunnel. The only way
to still use ALTQ is if the
Gunther Schadow wrote:
Another unknown to me is whether the GIF tunnel will copy
the TOS bits into the wrapper, and so, I can't use ALTQ at all.
If it does not currently, this, at least, should be simple to add.
I just hope that in the future we will end up with a *consistent* set
of
Gunther Schadow wrote:
[snip]
... to make things even more complicated, we also have the
berkeley packet filter (BPF) mechanism. Heck! How could
so many things evolve that all do essentially the same
thing? The interesting thing about the BPF mechanism is
that it is very generic. Filter rules
On Tue, May 01, 2001 at 05:42:53PM +, Gunther Schadow wrote:
... However, I am afraid that ALTQ
is not supported on gif pseudo-devices as it seems that ALTQ wants
to deal with things like DMA etc, i.e., real NIC hardware.
IIRC you can put a bandwidth limiter on a virtual interface (this
Rémi Guyomarch wrote:
IIRC you can put a bandwidth limiter on a virtual interface (this is
even the only solution to use ALTQ on tun or ppp devices) and thus
provide a queue which can be managed by ALTQ.
Aha! A Light! How is that done? Can you give more specifics?
Thanks, I appreciate it!
So, I was going to use ALTQ at the remote site to give priority to
outgoing camera control, and audio and to downgrade the outgoing
video to the small bandwidth that remains.
...
I believe that this is a major obstacle right now that will
fail my project. Instead I will have to revert
Gunther Schadow wrote:
Lars, what was your rationale for inventing the ip-tun package?
We wrote it a few years back for FreeBSD-3.X, to support X-Bone when no
KAME was installed (3.X did not have KAME code merged yet.) I hear there
are issues with it under 4.X due to a changed device model, but
In some email I received from Gunther Schadow, sie wrote:
[...]
As an added benefit, the two network interfaces tun0 and fxp0 allow
me to cope with the limited power of IPFILTER's NAT rules (as compared
to IPFW).
What is so limiting about NAT in IPFilter ?
AFAIK, apart from packet matching
In some email I received from Gunther Schadow, sie wrote:
Gunther Schadow wrote:
[snip]
to make things even more complicated, we also have the
berkeley packet filter (BPF) mechanism. Heck! How could
so many things evolve that all do essentially the same
thing? The interesting thing
Darren Reed wrote:
In some email I received from Gunther Schadow, sie wrote:
[...]
As an added benefit, the two network interfaces tun0 and fxp0 allow
me to cope with the limited power of IPFILTER's NAT rules (as compared
to IPFW).
What is so limiting about NAT in IPFilter ?
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
You wrote:
] O.K. I've investigated some more tunneling options based on
] my reading that ALTQ supports the tun0 device. Here is what
] I came up with so far:
]
] 0) KAME IPsec tunnel mode: +STANDARD, +KAME, -ALTQ based on TOS only,
]-doesn't work for me yet, +Cisco interoperable (at least
WAY A: CONTINUE TIGHT KERNEL-COUPLING
- KAME IPsec, ALTQ and IPfilter's rules engine to be combined
into one classifier.
- IPFILTER --- IPSEC --- ALTQ to be placed in this order of
processing (on outgoing packets)
- IPSEC to make sure the packet labels attached by the classifier
are
Yes, this makes your lives very difficult, I understand. However,
I also understand that you kind of prefer working with IPFILTER
because IPFILTER is available for all *BSDs regardless of what
other filtering stuff is also available for those. Therefore, I
have migrated to IPFILTER and I have
If I am
doing things wrong, please advise how to do them right, or refer
me to the documentation that does tell this (of course I read the
KAME newsletter, setkey man page and much other stuff, including
several VPN HOWTO documents that *ALL* use the gif-tunnel hack!)
just make sure, IIRC,
Gunther Schadow wrote:
However, I understand that ALTQ works in the data link layer at
the interface to the NIC. IPsec, however, works above that layer,
even before the IPFILTER rules (on outgoing packets.) So, we have
the following pipe
IPSEC - IPFILTER --- ALTQ
the problem
Rmi Guyomarch wrote:
On Tue, May 01, 2001 at 07:28:42PM +, Gunther Schadow wrote:
Rmi Guyomarch wrote:
IIRC you can put a bandwidth limiter on a virtual interface (this is
even the only solution to use ALTQ on tun or ppp devices) and thus
provide a queue which can be managed
Darren Reed wrote:
In some email I received from Gunther Schadow, sie wrote:
Gunther Schadow wrote:
[snip]
to make things even more complicated, we also have the
berkeley packet filter (BPF) mechanism. Heck! How could
so many things evolve that all do essentially the same
27 matches
Mail list logo
