On Mon, Sep 19, 2005 at 08:49:28AM +0200, Peter van Dijk wrote:
> On FreeBSD, we solve this issue by assigning the IPs to lo0. For
> Linux, this approach works equally well and is what the Linux Virtual
> Server documentation recommends.
Oops.. the docs I read were for Linux 2.0. The docs for 2.2
[see long original request below]
Bret, you want a block structured ipfw control language, but
ipfw is an assembly language. You have to live with that.
Your only way out is
A. write a translator from high level to low level language
(many people do use sh scripts to generate ipfw configuration
On Mon, Sep 19, 2005 at 01:37:59PM +0700, Olivier Nicole wrote:
> OK, enabling bridge is useless unless you bridge a pair of interfaces :)
>
> But that ARP thing happens also with interfaces that are not part of
> the bridge! Even if the interfaces are ifconfiged NOARP.
This is not what I observe
On Mon, Sep 19, 2005 at 03:34:10AM +0100, Gary Palmer wrote:
> There is another side effect, which comes into view with certain
> configurations behind load balancers. Foundry has an option (I believe
> called "DSR" for Direct Server Return) which just fiddles with the MAC
> address of the dest
> 'Enabling' bridging is a no-op.. However, when you -configure- a
> couple of interfaces together in a bridge, they share this behaviour;
> but this is correct as bridging is supposed to effectively merge the
> chosen interfaces into one. This does not affect any other interfaces,
> which makes it
On Mon, Sep 19, 2005 at 01:06:19PM +0700, Olivier Nicole wrote:
> To me, it seems that FreeBSD does just that too once bridge is enabled.
'Enabling' bridging is a no-op.. However, when you -configure- a
couple of interfaces together in a bridge, they share this behaviour;
but this is correct as br
> What Motonori Shindo described is actually the default behaviour for
> Linux kernels (at least my 2.6.8-kernel does it by default). It could be
> seen as a sort of proxy-arp, but only for the host itself, not other
> systems. Let me try to describe when it happens. Say you have
> 192.168.42.4
At 09:24 PM 9/18/2005, Dave+Seddon wrote:
skipto
man ipfw -> e.g. ipfw add 10 skipto 4000 all from any to any layer2 out
It's not that simple. Each rule that can send packets into a pipe
has at least two conditions (e.g. IP address, interface name, and
in or out via that interface). Do you p
skipto
man ipfw -> e.g. ipfw add 10 skipto 4000 all from any to any layer2 out
Brett Glass writes:
For years, we've used "Dummynet" in FreeBSD for bandwidth control.
Unfortunately, the semantics of IPFW can, at times, make the use of
Dummynet awkward and inefficient. For example, suppose
For years, we've used "Dummynet" in FreeBSD for bandwidth control.
Unfortunately, the semantics of IPFW can, at times, make the use of
Dummynet awkward and inefficient. For example, suppose you want to
create a set of rules that does bandwidth limiting first
and then blocks certain ports (e.g. T
Pieter de Boer wrote:
Is there any advantage/disadvantage in ARP implementation on FreeBSD
over that of Linux? Thanks.
I was unhappily surprised by this 'feature'. I find it pretty
counter-intuitive. I expect two interfaces to be seperated inside a
kernel, but Linux more or less binds them t
Chuck, Pieter, and Sam,
From: Sam Leffler <[EMAIL PROTECTED]>
Subject: Re: ARP behavior in FreeBSD vs Linux
Date: Sun, 18 Sep 2005 10:51:30 -0700
> Pieter de Boer wrote:
> > Chuck Swiger wrote:
> >
> >>> In contrast, on Linux (by default), it
> >>> responds as long as the target IP address in AR
I can't set 'limit src-nodes' with pfctl on a FreeBSD 5.4-RELEASE
system. This is the error I get:
# echo "set limit src-nodes 1000" | pfctl -f -
pfctl: DIOCSETLIMIT: Invalid argument
I'm able to set 'states' and 'frags' just fine:
# echo "set limit { states 5, frags 2000 }" | pfctl -f -
On Sep 18, 2005, at 1:15 PM, Benjamin Rosenblum wrote:
when i am running a very high network load (streaming video,
dumping ALOT of data across the network, etc) the network card
disconnects (i loose pings and all my transfers drop) and 15-20
seconds later it pops up on the console with
It would also be interesting to know if you've got device polling enabled.
If so, what sysctl settings do you have.
Regards,
Dave Seddon
Mike Tancsa writes:
On Sun, 18 Sep 2005 14:15:51 -0400, in sentex.lists.freebsd.net you
wrote:
Im having an issue with my new linksys eg1032 nic and
Milscvaer wrote:
FreeBSD ought to add per-socket socket options to
allow a programmer to turn on and off the don't
fragment bit for UDP and the UDP checksum, on a per
socket basis.
Sounds like a fine suggestion.
FreeBSD needs to implement this feature. We requested
this same feature years ag
On Sun, 18 Sep 2005 14:15:51 -0400, in sentex.lists.freebsd.net you
wrote:
>Im having an issue with my new linksys eg1032 nic and the onboard intel
>82547EI on my new server. ill go over both problems individually and
>include my dmesg below that.
>
>now the EM problem.
>
>when i am running a
Milscvaer wrote:
>
> FreeBSD ought to add per-socket socket options to
> allow a programmer to turn on and off the don't
> fragment bit for UDP and the UDP checksum, on a per
> socket basis.
>
> FreeBSD needs to implement this feature. We requested
> this same feature years ago and I cannot beli
FreeBSD ought to add per-socket socket options to
allow a programmer to turn on and off the don't
fragment bit for UDP and the UDP checksum, on a per
socket basis.
FreeBSD needs to implement this feature. We requested
this same feature years ago and I cannot believe such
a simple, basic feature i
hello,
I use a 3Com ADSL Modem HomeConnect. 3Com made something really stupid, the
modem do not comply with PPPoE RFC standards in discovery packet.
Under FreeBSD, there is an option to tell the system that we use this modem,
but under OpenBSD, I can't find this feature.
Do you know how I can m
Im having an issue with my new linksys eg1032 nic and the onboard intel
82547EI on my new server. ill go over both problems individually and
include my dmesg below that.
First the SK problem.
Sep 18 13:43:50 Valhalla kernel: skc0:
port 0xc400-0xc4ff mem 0xfeafec00-0xfeafecff irq 21 at devi
Pieter de Boer wrote:
Chuck Swiger wrote:
In contrast, on Linux (by default), it
responds as long as the target IP address in ARP Request matches with
any "local" IP address on the system, which is not necessarily an IP
address assigned to the interface through which the ARP request is
received
Chuck Swiger wrote:
In contrast, on Linux (by default), it
responds as long as the target IP address in ARP Request matches with
any "local" IP address on the system, which is not necessarily an IP
address assigned to the interface through which the ARP request is
received.
This sounds like "pro
Motonori Shindo wrote:
On FreeBSD (and I guess most Operating Systems as well), ARP reply is
sent back only when the target IP address in ARP request matches with
one of the IP addresses assigned to the interface through which the
ARP Request is received.
This is correct behavior. Normally, yo
On FreeBSD (and I guess most Operating Systems as well), ARP reply is
sent back only when the target IP address in ARP request matches with
one of the IP addresses assigned to the interface through which the
ARP Request is received. In contrast, on Linux (by default), it
responds as long as the ta
25 matches
Mail list logo
