The following reply was made to PR kern/125003; it has been noted by GNATS.
From: Shunsuke SHINOMIYA [EMAIL PROTECTED]
To: Hiroki Sato [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re[2]: kern/125003: incorrect EtherIP header format.
Date: Fri, 27 Jun 2008 15:00:45 +0900
Hi Eygene,
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?
I had already tried to debug this situation and Mike Silbersack
helped me with patching the
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 gratuitous ARP
[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
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
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 bug
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
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
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
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
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:
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.
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 tried to
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 should
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
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 FreeBSD
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
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 generate random
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 -gt; slow outgoing tcp traffic
Date: Fri, 27 Jun 2008 16:48:15 +0200
I can approve the
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 ifconfig vlanX
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 do it
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 inet6
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
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
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
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 !!
___
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
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 to
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
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
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 to
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 matters.
For
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.
I have
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
byproducts.
I'd
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
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
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 changed? :)
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
38 matches
Mail list logo
