On Fri, 27 Jun 2008, Chuck Swiger wrote:
> On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote:
> [ ... ]
> >> If net.inet.ip.fw.one_pass is true, then you definitely want to
> >> apply your
> >> deny rules first, as once something matches a pipe rule, it's going
> >> to be
> >> passed. The
On Thu, 26 Jun 2008, Eygene Ryabinkin wrote:
I had already tried to debug this situation and Mike Silbersack
helped me with patching the kernel. At that days his patches (that
went into 7.x) helped, but with higher request rate to the Apache,
they seem to be back again. I can try to setup the
On Sun, 15 Jun 2008 11:16:17 +0100, in sentex.lists.freebsd.net you
wrote:
>Paul wrote:
>> Get these with GRE tunnel on
>> FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #5: Sun May 11 19:00:57 EDT
>> 2008 :/usr/obj/usr/src/sys/ROUTER amd64
>> But do not get them with 7.0-RELEASE
>>
>> Any ideas what
Firstly, tried turning off polling? Some of us have found it to be
detrimental to performance on the more modern systems. Its use was more
practical on older systems were servicing interrupts took alot of CPU
power, but the "em" driver supports delaying interrupts until more
packets have ar
On Jun 27, 2008, at 3:01 PM, Freddie Cash wrote:
[ ... ]
If net.inet.ip.fw.one_pass is true, then you definitely want to
apply your
deny rules first, as once something matches a pipe rule, it's going
to be
passed. The tradeoff is that the accounting/fairness of traffic is
less
accurate but
On Fri, 27 Jun 2008 11:06:19 -0400, "George V. Neville-Neil"
<[EMAIL PROTECTED]> wrote:
> At Thu, 26 Jun 2008 12:56:41 -0700,
> julian wrote:
>>
>> I'm planning on committing it unless someone can provide a reason not
>> to, as I've seen it working, needed it, and have not seen any bad
>> byproduc
On 2008-Jun-27 22:59:56 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote:
>Peter Jeremy wrote:
>> The kernel should send out gratuitous ARP requests whenever you assign
>> an address to an interface. You could confirm that this is happening
>> by tcpdumping the interface whilst you add aliases.
>>
On Fri, Jun 27, 2008 at 2:37 PM, Chuck Swiger <[EMAIL PROTECTED]> wrote:
> On Jun 27, 2008, at 1:01 PM, Freddie Cash wrote:
>> Mainly, I'm wondering where to put the "ipfw queue" rules (the ones
>> that send the packets to dummynet), in relation to the packet
>> filtering rules, or if it even matte
On Jun 27, 2008, at 1:01 PM, Freddie Cash wrote:
Mainly, I'm wondering where to put the "ipfw queue" rules (the ones
that send the packets to dummynet), in relation to the packet
filtering rules, or if it even matters.
For instance, do the queue rules apply to all the rules in the set, or
only t
George V. Neville-Neil wrote:
At Thu, 26 Jun 2008 12:56:41 -0700,
julian wrote:
I'm planning on committing it unless someone can provide a reason not
to, as I've seen it working, needed it, and have not seen any bad
byproducts.
I'd be interested to know how you tested it. NAT-T and IPsec a
Peter Jeremy wrote:
On 2008-Jun-26 22:06:11 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote:
I guess what I could do was to "poison" their arp cache for each
address with a "is-at" message. Is there a way to force the sending
of these messages for all the addresses of an interface?
The k
I'm trying to figure out how traffic shaping using dummynet fits into
an ipfw ruleset.
Mainly, I'm wondering where to put the "ipfw queue" rules (the ones
that send the packets to dummynet), in relation to the packet
filtering rules, or if it even matters.
For instance, do the queue rules apply t
On Fri, 27 Jun 2008, Paul wrote:
I have the same 'problem' if that helps any.. Sockets stuck for over a month
in CLOSED and they have a * for the port on the source IP. tcp4 0 0
67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6:
Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn'
>
> NO! It is just wrong! There is no relation between vlan queues on the
> same physical interface and thus you can't guarantee anything! Can we
> please stop with this nonsense and not bring up the patch every other
> month.
Understood !!
___
fre
I'm watching top -S -I -s1 -H
This is just more of an observation.. I'm not having a problem with it,
just wondering why it's doing it.. It's almost like most of the system
processes in 'top' are a 3-5 minute average instead of an instant
percentage. If this is intended behavior I simply wanted
On Fri, 27 Jun 2008, Eygene Ryabinkin wrote:
Paul, good day.
Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote:
I have the same 'problem' if that helps any.. Sockets stuck for over a
month in CLOSED and they have a * for the port on the source IP. tcp4 0 0
67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-
Hi Eygene.. It happens with telnet :) A lot of my closed entries are
from telnet so I can't really put a finger on any specific application :/
Eygene Ryabinkin wrote:
Paul, good day.
Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote:
I have the same 'problem' if that helps any.. Sockets s
> > kernel: nd6_lookup: failed to add route for a
> > neighbor(2001:0470:0007:0028::0001), errno=17
> >
> > Client IPv6 address:2001:470:7:28::2/64
> >
> > The script they suggest, and I used, is :
> >
> > ifconfig gif0 create
> > ifconfig gif0 tunnel MYIP 216.66.22.2
> > ifconfig gif0
On Friday 27 June 2008 18:57:59 Alexandre Biancalana wrote:
> On 6/27/08, Max Laier <[EMAIL PROTECTED]> wrote:
> > You don't need a patch at all. What you do is: Queue on the
> > physical interface, classify on the vlan interface. It is broken to
> > allow ALTQ on a virtual interface if you can
On 6/27/08, Max Laier <[EMAIL PROTECTED]> wrote:
>
>
> You don't need a patch at all. What you do is: Queue on the physical
> interface, classify on the vlan interface. It is broken to allow ALTQ on
> a virtual interface if you can do it otherwise.
>
> in pf.conf speak:
>
> If you have "ifco
The following reply was made to PR kern/121257; it has been noted by GNATS.
From: Alex Samorukov <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/121257: [tcp] TSO + natd -> slow outgoing tcp traffic
Date: Fri, 27 Jun 2008 16:48:15 +0200
I can approve the pro
At Thu, 26 Jun 2008 23:25:18 -0400,
Paul wrote:
>
> I have a FreeBSD router set up with Full BGP routes and I'm doing some
> tests on using it for routing.
>
> 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008
> amd64
>
> oddness..:
>
> Use a packet generator to generat
At Thu, 26 Jun 2008 12:56:41 -0700,
julian wrote:
>
> I'm planning on committing it unless someone can provide a reason not
> to, as I've seen it working, needed it, and have not seen any bad
> byproducts.
>
I'd be interested to know how you tested it. NAT-T and IPsec are
non-trivial protocol
Paul, good day.
Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote:
> I have the same 'problem' if that helps any.. Sockets stuck for over a
> month in CLOSED and they have a * for the port on the source IP.
> tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED
> 7.0-RELEASE-p1 Free
I have the same 'problem' if that helps any.. Sockets stuck for over a
month in CLOSED and they have a * for the port on the source IP.
tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED
7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008
amd64
Doesn't seem
Peter Jeremy wrote:
On 2008-Jun-26 22:06:11 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote:
I guess what I could do was to "poison" their arp cache for each
address with a "is-at" message. Is there a way to force the sending
of these messages for all the addresses of an interface?
The kernel sh
Ali, good day.
Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote:
> > Just a quick "me too" message: I also used to see this on my 7.x
> > machines. This was with Apache servers in the proxy setup: one
>
> I'm wondering: where these 32 bit, or 64 bit machines?
amd64.
> > I had already tr
Tuc at T-B-O-H.NET wrote:
Hi,
Running 5.5 (And no "upgrade" messages please, I'm forced to, its
out of my hands) and trying to bring up HE's IPV6.
I've got it running on a 4.10 system (Ok, feel free to tell me
to upgrade, this one is more a lazy issue.. But I am making progress.
On Thursday 26 June 2008 22:21:54 Giulio Ferro wrote:
> I've tried to set altq bandwidth control on a vlan interface, but this
> feature
> doesn't seem to be supported by the vlan driver.
>
> I've googled around and I've found that there should be a trivial patch
> to enable this feature:
> http://
Pyun YongHyeon wrote:
I've updated patch again. There was a bug that disabled
multicasting filter. Back out previous patch and try again.
The URL is the same as before.
> Regards,
> Eugene
rtsol still doesn't work with vr0 being in non-promiscuous mode.
However, apparently vr0 picked up ro
On Thu, 26 Jun 2008, Robert Watson wrote:
I think the first logical step is to wait for the application to get into
that state again, and then run procstat or fstat to dump the file descriptor
away for the process. Presumably in the normal steady state, you expect to
see a few IPC sockets (sy
On Fri, Jun 27, 2008 at 12:44:55AM -0700, Eugene M. Kim wrote:
> FWIW, I stumbled upon this while browsing through old -net archives...
> Apparently re(4) had a similar (same?) problem.
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034336.html
> http://lists.freebsd.org/pip
Giulio Ferro wrote:
http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch
Nope, this patch doesn't apply cleanly to freebsd 7...
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send an
On Fri, Jun 27, 2008 at 12:32:06AM -0700, Eugene M. Kim wrote:
> [EMAIL PROTECTED] wrote:
> > Would you try patch at the following URL?
> > http://people.freebsd.org/~yongari/vr/vr.cam.patch
>
> Nope, didn't fix it (symptom's still the same)... ;_;
>
I've updated patch again. There was a
FWIW, I stumbled upon this while browsing through old -net archives...
Apparently re(4) had a similar (same?) problem.
http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034336.html
http://lists.freebsd.org/pipermail/freebsd-stable/2007-April/034339.html
Cheers,
Eugene
_
[EMAIL PROTECTED] wrote:
> Would you try patch at the following URL?
> http://people.freebsd.org/~yongari/vr/vr.cam.patch
Nope, didn't fix it (symptom's still the same)... ;_;
Regards,
Eugene
___
freebsd-net@freebsd.org mailing list
http://lists.freebs
On 2008-Jun-26 22:06:11 +0200, Giulio Ferro <[EMAIL PROTECTED]> wrote:
> I guess what I could do was to "poison" their arp cache for each
>address with a "is-at" message. Is there a way to force the sending
>of these messages for all the addresses of an interface?
The kernel should send out gratui
37 matches
Mail list logo
