From owner-freebsd-net Sun Oct 13 6:24:26 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D8F1A37B401
for <freebsd-net@freebsd.org>; Sun, 13 Oct 2002 06:24:21 -0700 (PDT)
Received: from dibbler.ne.client2.attbi.com (dibbler.ne.client2.attbi.com [24.61.41.247])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4840543E75
for <freebsd-net@freebsd.org>; Sun, 13 Oct 2002 06:24:21 -0700 (PDT)
(envelope-from rodrigc@attbi.com)
Received: from dibbler.ne.client2.attbi.com (localhost.ne.attbi.com [127.0.0.1])
by dibbler.ne.client2.attbi.com (8.12.6/8.12.5) with ESMTP id g9DDP1CK035991
for <freebsd-net@freebsd.org>; Sun, 13 Oct 2002 09:25:01 -0400 (EDT)
(envelope-from rodrigc@dibbler.ne.client2.attbi.com)
Received: (from rodrigc@localhost)
by dibbler.ne.client2.attbi.com (8.12.6/8.12.6/Submit) id g9DDP1d3035987
for freebsd-net@freebsd.org; Sun, 13 Oct 2002 09:25:01 -0400 (EDT)
Date: Sun, 13 Oct 2002 09:25:00 -0400
From: Craig Rodrigues <rodrigc@attbi.com>
To: freebsd-net@freebsd.org
Subject: How to add bpf support to if_atmsubr.c?
Message-ID: <20021013092500.A35284@attbi.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X"
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi,
I am on a -current system, using patches from Harti Brandt's
Netgraph ATM work:
http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/
I am trying to add bpf support to /src/sys/net/if_atmsubr.c so that
I can use tcpdump when sending traffic over my ATM card.
I've got things mostly working, but I think I'm using the
wrong arguments in the bpfattach() call (I'm not familiar with
bpf and just guessed, based on looking at files in the same directory).
Here is the line I used:
bpfattach(ifp, DLT_ATM_RFC1483, sizeof(u_int));
What should I really be using?
I am attaching the patch I am using, which incorporates
patches from Harti Brandt, and bpf fixes from me.
Thanks.
--
Craig Rodrigues
http://www.gis.net/~craigr
rodrigc@attbi.com
--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="patch-if_atmsubr.c"
--- if_atmsubr.c.orig Fri Jun 15 03:32:25 2001
+++ if_atmsubr.c Sun Oct 13 04:05:16 2002
@@ -57,6 +57,7 @@
#include <net/if_atm.h>
#include <netinet/in.h>
+#include <net/bpf.h>
#include <netinet/if_atm.h>
#include <netinet/if_ether.h> /* XXX: for ETHERTYPE_* */
#if defined(INET) || defined(INET6)
@@ -66,6 +67,15 @@
#include <netnatm/natm.h>
#endif
+void (*ng_atm_attach_p)(struct ifnet *);
+void (*ng_atm_detach_p)(struct ifnet *);
+int (*ng_atm_output_p)(struct ifnet *, struct mbuf **);
+void (*ng_atm_input_p)(struct ifnet *, struct mbuf **,
+ struct atm_pseudohdr *, void *);
+void (*ng_atm_input_orphan_p)(struct ifnet *, struct mbuf *,
+ struct atm_pseudohdr *, void *);
+void (*ng_atm_message_p)(struct ifnet *, u_int32_t, u_int32_t);
+
#ifndef ETHERTYPE_IPV6
#define ETHERTYPE_IPV6 0x86dd
#endif
@@ -199,6 +209,16 @@
}
}
+ if (ng_atm_output_p != NULL) {
+ if ((error = (*ng_atm_output_p)(ifp, &m)) != 0) {
+ if (m != NULL)
+ m_freem(m);
+ return (error);
+ }
+ if (m == NULL)
+ return (0);
+ }
+
/*
* Queue message on interface, and start output if interface
* not yet active.
@@ -234,6 +254,16 @@
}
ifp->if_ibytes += m->m_pkthdr.len;
+ if (ifp->if_bpf != NULL) {
+ bpf_mtap(ifp, m);
+ }
+
+ if (ng_atm_input_p != NULL) {
+ (*ng_atm_input_p)(ifp, &m, ah, rxhand);
+ if (m == NULL)
+ return;
+ }
+
if (rxhand) {
#ifdef NATM
struct natmpcb *npcb = rxhand;
@@ -244,9 +274,10 @@
inq = &natmintrq;
m->m_pkthdr.rcvif = rxhand; /* XXX: overload */
#else
+/*
printf("atm_input: NATM detected but not configured in kernel\n");
- m_freem(m);
- return;
+*/
+ goto dropit;
#endif
} else {
/*
@@ -287,7 +318,13 @@
break;
#endif
default:
- m_freem(m);
+#ifndef NATM
+ dropit:
+#endif
+ if (ng_atm_input_orphan_p != NULL)
+ (*ng_atm_input_orphan_p)(ifp, m, ah, rxhand);
+ else
+ m_freem(m);
return;
}
}
@@ -330,4 +367,36 @@
break;
}
+}
+
+void
+atm_ifdetach(ifp)
+ register struct ifnet *ifp;
+{
+
+}
+
+void
+atm_ifattach1(struct ifnet *ifp)
+{
+ atm_ifattach(ifp);
+ bpfattach(ifp, DLT_ATM_RFC1483, sizeof(u_int));
+ if(ng_atm_attach_p)
+ (*ng_atm_attach_p)(ifp);
+}
+
+void
+atm_ifdetach1(struct ifnet *ifp)
+{
+ if(ng_atm_detach_p)
+ (*ng_atm_detach_p)(ifp);
+ bpfdetach(ifp);
+ atm_ifdetach(ifp);
+}
+
+void
+atm_message(struct ifnet *ifp, u_int32_t msg, u_int32_t arg)
+{
+ if(ng_atm_message_p)
+ (*ng_atm_message_p)(ifp, msg, arg);
}
--LZvS9be/3tNcYl/X--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sun Oct 13 11: 7:44 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id F3C7737B401
for <freebsd-net@FreeBSD.ORG>; Sun, 13 Oct 2002 11:07:42 -0700 (PDT)
Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30])
by mx1.FreeBSD.org (Postfix) with SMTP id 6D0B343E6E
for <freebsd-net@FreeBSD.ORG>; Sun, 13 Oct 2002 11:07:41 -0700 (PDT)
(envelope-from keramida@ceid.upatras.gr)
Received: (qmail 15704 invoked from network); 13 Oct 2002 18:00:40 -0000
Received: from upnet-dialinpool-85.upnet.gr (HELO hades.hell.gr) (@150.140.128.169)
by nic.upatras.gr with SMTP; 13 Oct 2002 18:00:40 -0000
Received: from hades.hell.gr (hades [127.0.0.1])
by hades.hell.gr (8.12.6/8.12.6) with ESMTP id g9DI7jaW011684;
Sun, 13 Oct 2002 21:07:45 +0300 (EEST)
(envelope-from keramida@ceid.upatras.gr)
Received: (from keramida@localhost)
by hades.hell.gr (8.12.6/8.12.6/Submit) id g9DHh97i011279;
Sun, 13 Oct 2002 20:43:09 +0300 (EEST)
(envelope-from keramida@ceid.upatras.gr)
Date: Sun, 13 Oct 2002 20:43:08 +0300
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: soheil hassas yeganeh <soheil_h_y@hotmail.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: IP bad cksum (0!)
Message-ID: <20021013174308.GD10829@hades.hell.gr>
References: <F83YiMCIqtQvAauNjVu0000036e@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F83YiMCIqtQvAauNjVu0000036e@hotmail.com>
X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On 2002-10-11 14:57, soheil hassas yeganeh <soheil_h_y@hotmail.com> wrote:
> To recompute the checksum of the ip packets i wrote this lines in
> the ip_input.c files :
>
> ip->ip_sum =0 ;
> if(hlen == sizeof(struct ip))
> ip->ip_sum = in_cksum_hdr(ip);
> else
> ip->ip_sum = in_cksum(m,hlen);
>
> When i make a dump it says that it has bad cksum 0!
>
> 12:25:11.858759 62.217.112.165 > 66.201.71.98: icmp: echo reply (ttl 42, id 17879, len 84, bad cksum 0!)
>
> I don't know why this doesn't work ??????
Use diff(1) to show us exactly where those changes were made. Apart
from a few stylistic bogons that the above fragment of source has,
it's really impossible to understand why it fails without seeing
exactly where the change was made.
--
keramida@FreeBSD.org FreeBSD: The Power to Serve
FreeBSD 5.0-CURRENT #12: Thu Oct 10 21:08:38 EEST 2002
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sun Oct 13 13:30:14 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D6DDD37B401
for <net@FreeBSD.ORG>; Sun, 13 Oct 2002 13:30:13 -0700 (PDT)
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4C16943E4A
for <net@FreeBSD.ORG>; Sun, 13 Oct 2002 13:30:13 -0700 (PDT)
(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA12265;
Sun, 13 Oct 2002 13:24:35 -0700 (PDT)
Received: from arch20m.dellroad.org (localhost [127.0.0.1])
by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9DKNFON074921;
Sun, 13 Oct 2002 13:23:15 -0700 (PDT)
(envelope-from archie@arch20m.dellroad.org)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9DKNF4C074920;
Sun, 13 Oct 2002 13:23:15 -0700 (PDT)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200210132023.g9DKNF4C074920@arch20m.dellroad.org>
Subject: Re: Comments Please
In-Reply-To: <20021012.171809.93306957.imp@bsdimp.com> "from M. Warner Losh at
Oct 12, 2002 05:18:09 pm"
To: "M. Warner Losh" <imp@bsdimp.com>
Date: Sun, 13 Oct 2002 13:23:15 -0700 (PDT)
Cc: net@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
M. Warner Losh writes:
>
> static int ether_resolvemulti(struct ifnet *, struct sockaddr **,
> struct sockaddr *);
> -u_char etherbroadcastaddr[6] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
> +u_char etherbroadcastaddr[ETHER_ADDR_LEN] =
> + { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
'etherbroadcastaddr' should really have type 'const u_char []'
rather than 'u_char []'.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sun Oct 13 22: 0:38 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 76A1637B401; Sun, 13 Oct 2002 22:00:36 -0700 (PDT)
Received: from samwise.jobeus.net (samwise.jobeus.net [205.206.125.238])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 954C843EB2; Sun, 13 Oct 2002 22:00:35 -0700 (PDT)
(envelope-from freebsd@jobeus.net)
Received: (from root@localhost)
by samwise.jobeus.net (8.12.6/8.12.3) id g9E50RwI095512;
Sun, 13 Oct 2002 23:00:27 -0600 (MDT)
(envelope-from freebsd@jobeus.net)
Received: from localhost (freebsd@localhost [127.0.0.1])
by samwise.jobeus.net (8.12.6/8.12.3av) with ESMTP id g9E50QDo095504;
Sun, 13 Oct 2002 23:00:26 -0600 (MDT)
(envelope-from freebsd@jobeus.net)
Date: Sun, 13 Oct 2002 23:00:26 -0600 (MDT)
From: Scott Carmichael <freebsd@jobeus.net>
To: freebsd-net@freebsd.org, <freebsd-hackers@freebsd.org>
Subject: IP resolving
Message-ID: <20021013225806.M95476-100000@samwise.jobeus.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS perl-11
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Can someone help me here? Is there a code change I can make somewhere?
Please CC me on any replies, as I am not subscribed to -net or -hackers.
Thanks,
Scott
---------- Forwarded message ----------
Date: Fri, 11 Oct 2002 14:14:08 -0600 (MDT)
From: Scott Carmichael <freebsd@jobeus.net>
To: freebsd-questions@FreeBSD.ORG
Subject: IP resolving
I would like to know two things... Why FreeBSD acts in the following way
while OpenBSD does not, and if it's possible to fix this?
It seems that if anyone connects to my FreeBSD server wish a hostname that
does not match their IP, I get a console message about the mismatch, and
then if they connect via rlogin or ssh, 'who', 'w', 'last', etc. all
report that they are connected _from_ MY box, which they aren't.
This is annoying for a few reasons... A. I don't know where people are
connecting from, B. When I get a console message for every time a user
connects to pop3 to check their email and they check it every 5 minutes,
24 hours a day, I miss good important messages, and C. It used to resolve
to IPs instead of hostnames when this occurred when I ran OpenBSD last
year.
An example of what I mean about the 'unresolving IPs' is the following:
At school, the Computer Science department runs a DNS server with two
views, inside and outside. If you're off-campus, you can't resolve, say
"zone34wb.cpsc.ucalgary.ca", but if you're on campus, this will resolve
properly.
When I connect to my computer at home from this computer, 'w' will instead
report:
2:11PM up 1 day, 2:28, 1 user, load averages: 1.15, 1.06, 1.01
USER TTY FROM LOGIN@ IDLE WHAT
jobe p0 samwise 1:53PM - w
Where 'samwise' is the name of my computer.
Temporarily, this is solvable by editing my /etc/hosts file to include all
the Computers I know in the Computer Science department, but alas, it
happens with other users as well that are on various ISPs around the
country.
Can I fix this? At least so that 'who' or 'w' will report the IP addresses
instead of just giving up? And can I get rid of the console messages?
Thanks a ton,
Scott Carmichael
http://jobeus.net/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 0:10:24 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 914DC37B401
for <net@FreeBSD.ORG>; Mon, 14 Oct 2002 00:10:23 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7791643E9E
for <net@FreeBSD.ORG>; Mon, 14 Oct 2002 00:10:22 -0700 (PDT)
(envelope-from brandt@fokus.gmd.de)
Received: from beagle (beagle [193.175.132.100])
by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g9E7A4e25099;
Mon, 14 Oct 2002 09:10:04 +0200 (MEST)
Date: Mon, 14 Oct 2002 09:10:04 +0200 (CEST)
From: Harti Brandt <brandt@fokus.gmd.de>
To: Luigi Rizzo <rizzo@icir.org>
Cc: "M. Warner Losh" <imp@bsdimp.com>, <net@FreeBSD.ORG>
Subject: Re: Comments Please
In-Reply-To: <20021012191709.B93684@carp.icir.org>
Message-ID: <20021014090528.V19145-100000@beagle.fokus.gmd.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Sat, 12 Oct 2002, Luigi Rizzo wrote:
LR>On Sat, Oct 12, 2002 at 08:07:47PM -0600, M. Warner Losh wrote:
LR>...
LR>> : reveals the use of an explicit constant (6) in net/if_arp.h and
LR>> : netinet/if_ether.c; there is more of the same in net/bridge.c
LR>> : (my fault), net/if_atmsubr.c, netinet/if_ether.c, netncp/ncp_subr.c
LR>>
LR>> atmsubr? Doesn't ATM have its own constants?
LR>
LR>eh, that's the problem with explicit constants, you can never tell
LR>whether "6" is english, german or italian... in any case the
LR>relevant piece of code is:
LR>
LR> net/if_atmsubr.c: if (bcmp(alc, ATMLLC_HDR, 6)) {
LR>
LR>I have no idea if it has any relation with ethernet header sizes.
No, this is the length of an LLC/SNAP header minus the type field.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
brandt@fokus.gmd.de, brandt@fokus.fhg.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 0:26:35 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 7F4D837B401
for <freebsd-net@FreeBSD.ORG>; Mon, 14 Oct 2002 00:26:34 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
by mx1.FreeBSD.org (Postfix) with ESMTP id 89C3043EAC
for <freebsd-net@FreeBSD.ORG>; Mon, 14 Oct 2002 00:26:33 -0700 (PDT)
(envelope-from brandt@fokus.gmd.de)
Received: from beagle (beagle [193.175.132.100])
by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g9E7QRe26753;
Mon, 14 Oct 2002 09:26:27 +0200 (MEST)
Date: Mon, 14 Oct 2002 09:26:27 +0200 (CEST)
From: Harti Brandt <brandt@fokus.gmd.de>
To: Craig Rodrigues <rodrigc@attbi.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: How to add bpf support to if_atmsubr.c?
In-Reply-To: <20021013092500.A35284@attbi.com>
Message-ID: <20021014092010.S19145-100000@beagle.fokus.gmd.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <20021014092010.B19145@beagle.fokus.gmd.de>
Content-Disposition: INLINE
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Sun, 13 Oct 2002, Craig Rodrigues wrote:
CR>Hi,
CR>
CR>I am on a -current system, using patches from Harti Brandt's
CR>Netgraph ATM work:
CR>http://www.fokus.fhg.de/research/cc/cats/employees/hartmut.brandt/ngatm/
CR>
CR>I am trying to add bpf support to /src/sys/net/if_atmsubr.c so that
CR>I can use tcpdump when sending traffic over my ATM card.
CR>
CR>I've got things mostly working, but I think I'm using the
CR>wrong arguments in the bpfattach() call (I'm not familiar with
CR>bpf and just guessed, based on looking at files in the same directory).
CR>
CR>Here is the line I used:
CR>bpfattach(ifp, DLT_ATM_RFC1483, sizeof(u_int));
CR>
CR>What should I really be using?
CR>
CR>I am attaching the patch I am using, which incorporates
CR>patches from Harti Brandt, and bpf fixes from me.
You my look at dev/en. In revision 1.7 of if_atmsub.c bpf support was
moved from the generic file to the ENI driver ('as it should be'????).
Maybe its time to move it back. The problem is, that at attach time you
don't know what link-level encapsulation is used, because this can be
select when you establish the VCC (via the parameter 'z' (see en(4))).
So BPF_DLC_RFC1483 will not work without LLC/SNAP encapsulation.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
brandt@fokus.gmd.de, brandt@fokus.fhg.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 2: 0:21 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id CB44337B401
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 02:00:08 -0700 (PDT)
Received: from chung.yikes.com (dsl-65-184-72-125.telocity.com [65.184.72.125])
by mx1.FreeBSD.org (Postfix) with ESMTP id 631E743EB2
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 02:00:07 -0700 (PDT)
(envelope-from leonardc@cs.berkeley.edu)
Received: from feather (12-232-222-255.client.attbi.com [12.232.222.255])
by chung.yikes.com (8.12.3/8.11.6) with SMTP id g9E900ds028615
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 02:00:02 -0700 (PDT)
(envelope-from leonardc@cs.berkeley.edu)
From: "Leonard Chung" <leonardc@cs.berkeley.edu>
To: <freebsd-net@freebsd.org>
Subject: MPD PPTP tunneling intermittantly fails
Date: Mon, 14 Oct 2002 01:59:58 -0700
Message-ID: <AEEMJFAIHDPJNCAKCHHBIEHDCHAA.leonardc@cs.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20021012182849.X24791-100000@chung.yikes.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
I'm trying to get MPD working reliably, but I've been having strange
problems with it. I've gone through the mailing list archives, Google, and
even copied Julian's MPD config files that he posted on the mailing list a
while back with no success.
The problem that I'm having is that MPD starts properly and I can
successfully connect to the service using Windows clients. However, when I
ping internal hosts, the first five or so work fine, and then beyond that
packets start getting lost, with a loss rate of around 50%. These tests are
run over a local network with two subnets, so packet loss shouldn't be a
problem. So although I can currently connect and create a tunnel, it isn't
very useful as beyond any initial DNS queries, file transfers, etc. fail
completely.
Also, is there any way to get DHCP to work with MPD rather than hard wire
IPs directly into MPD's config files?
I'm guessing this is probably just something easy that I'm missing. My
config files and an MPD trace are below.
Thanks,
Leonard
multipptp:
load client1
load client2
load client3
load client4
client1:
new -i ng0 pptp1 pptp1
set ipcp ranges 10.0.0.1/32 10.0.2.1/24
load client_standard
client2:
new -i ng1 pptp2 pptp2
set ipcp ranges 10.0.0.1/32 10.0.2.2/24
load client_standard
client3:
new -i ng2 pptp3 pptp3
set ipcp ranges 10.0.0.1/32 10.0.2.3/24
load client_standard
client4:
new -i ng3 pptp4 pptp4
set ipcp ranges 10.0.0.1/32 10.0.2.4/24
load client_standard
client_standard:
set iface disable on-demand
set iface enable proxy-arp
set iface idle 0
#set iface idle 1800
set bundle enable multilink
set link yes acfcomp protocomp
set link no pap chap
set link enable chap
set link mtu 1460
set link keep-alive 10 60
set ipcp yes vjcomp
set ipcp dns 10.0.0.1
set ipcp nbns 10.0.0.1
#set ipcp dns 192.168.1.3
#set ipcp nbns 192.168.1.4
set bundle enable compression
set bundle yes crypt-reqd
set ccp yes mppc
#set ccp yes mpp-e40
set ccp no mpp-e40
set ccp yes mpp-e128
set ccp yes mpp-stateless
set pptp enable always-ack
#
# For our PPTP server
#
pptp1:
set link type pptp
#set pptp self 65.184.72.125
set pptp self 192.168.0.1
#set pptp self 1.2.3.4
set pptp enable incoming
set pptp disable originate
pptp2:
set link type pptp
#set pptp self 65.184.72.125
set pptp self 192.168.0.1
#set pptp self 1.2.3.4
set pptp enable incoming
set pptp disable originate
pptp3:
set link type pptp
#set pptp self 65.184.72.125
set pptp self 192.168.0.1
#set pptp self 1.2.3.4
set pptp enable incoming
set pptp disable originate
pptp4:
set link type pptp
#set pptp self 65.184.72.125
set pptp self 192.168.0.1
#set pptp self 1.2.3.4
set pptp enable incoming
set pptp disable originate
test1 "<PW>" 10.0.2.1
feather "<PW>" 10.0.2.2
sylvia "<PW>" 10.0.2.3
chung# ifconfig
fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255
inet6 fe80::2a0:c9ff:fe03:b454%fxp0 prefixlen 64 scopeid 0x1
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:a0:c9:03:b4:54
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 65.184.72.125 netmask 0xfffffffc broadcast 65.184.72.127
inet6 fe80::280:adff:fe73:ebfe%ed0 prefixlen 64 scopeid 0x3
ether 00:80:ad:73:eb:fe
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500
chung# mpd
Multi-link PPP for FreeBSD, by Archie L. Cobbs.
Based on iij-ppp, by Toshiharu OHNO.
mpd: pid 24745, version 3.9 (root@chung.yikes.com 20:13 11-Oct-2002)
[pptp1] ppp node is "mpd24745-pptp1"
mpd: local IP address for PPTP is 192.168.0.1
[pptp1] using interface ng0
[pptp2] ppp node is "mpd24745-pptp2"
[pptp2] using interface ng1
[pptp3] ppp node is "mpd24745-pptp3"
[pptp3] using interface ng2
[pptp4] ppp node is "mpd24745-pptp4"
[pptp4] using interface ng3
[pptp4:pptp4] mpd: PPTP connection from 192.168.0.2:3068
pptp0: attached to connection with 192.168.0.2:3068
[pptp1] IFACE: Open event
[pptp1] IPCP: Open event
[pptp1] IPCP: state change Initial --> Starting
[pptp1] IPCP: LayerStart
[pptp1] IPCP: Open event
[pptp1] bundle: OPEN event in state CLOSED
[pptp1] opening link "pptp1"...
[pptp1] link: OPEN event
[pptp1] LCP: Open event
[pptp1] LCP: state change Initial --> Starting
[pptp1] LCP: LayerStart
[pptp1] device: OPEN event in state DOWN
[pptp1] attaching to peer's outgoing call
[pptp1] device is now in state OPENING
[pptp1] device: UP event in state OPENING
[pptp1] device is now in state UP
[pptp1] link: UP event
[pptp1] link: origination is remote
[pptp1] LCP: Up event
[pptp1] LCP: state change Starting --> Req-Sent
[pptp1] LCP: phase shift DEAD --> ESTABLISH
[pptp1] LCP: SendConfigReq #1
ACFCOMP
PROTOCOMP
MRU 1500
MAGICNUM 2f3117ec
AUTHPROTO CHAP MSOFTv2
MP MRRU 1600
MP SHORTSEQ
ENDPOINTDISC [802.1] 00 a0 c9 03 b4 54
pptp0-0: ignoring SetLinkInfo
[pptp1] LCP: rec'd Configure Request #0 link 0 (Req-Sent)
MRU 1400
MAGICNUM 5aaa4632
PROTOCOMP
ACFCOMP
CALLBACK
Not supported
[pptp1] LCP: SendConfigRej #0
CALLBACK
[pptp1] rec'd unknown ctrl message, cookie=942710669 cmd=4
[pptp1] LCP: rec'd Configure Request #1 link 0 (Req-Sent)
MRU 1400
MAGICNUM 5aaa4632
PROTOCOMP
ACFCOMP
[pptp1] LCP: SendConfigAck #1
MRU 1400
MAGICNUM 5aaa4632
PROTOCOMP
ACFCOMP
[pptp1] LCP: state change Req-Sent --> Ack-Sent
[pptp1] LCP: SendConfigReq #2
ACFCOMP
PROTOCOMP
MRU 1500
MAGICNUM 2f3117ec
AUTHPROTO CHAP MSOFTv2
MP MRRU 1600
MP SHORTSEQ
ENDPOINTDISC [802.1] 00 a0 c9 03 b4 54
[pptp1] LCP: rec'd Configure Reject #2 link 0 (Ack-Sent)
MP MRRU 1600
MP SHORTSEQ
ENDPOINTDISC [802.1] 00 a0 c9 03 b4 54
[pptp1] LCP: SendConfigReq #3
ACFCOMP
PROTOCOMP
MRU 1500
MAGICNUM 2f3117ec
AUTHPROTO CHAP MSOFTv2
[pptp1] LCP: rec'd Configure Ack #3 link 0 (Ack-Sent)
ACFCOMP
PROTOCOMP
MRU 1500
MAGICNUM 2f3117ec
AUTHPROTO CHAP MSOFTv2
[pptp1] LCP: state change Ack-Sent --> Opened
[pptp1] LCP: phase shift ESTABLISH --> AUTHENTICATE
[pptp1] LCP: auth: peer wants nothing, I want CHAP
[pptp1] CHAP: sending CHALLENGE
[pptp1] LCP: LayerUp
[pptp1] LCP: rec'd Ident #2 link 0 (Opened)
MESG: MSRASV5.10
pptp0-0: ignoring SetLinkInfo
[pptp1] LCP: rec'd Ident #3 link 0 (Opened)
MESG: MSRAS-1-FEATHER
[pptp1] CHAP: rec'd RESPONSE #1
Name: "feather"
Peer name: "feather"
Response is valid
[pptp1] CHAP: sending SUCCESS
[pptp1] LCP: authorization successful
[pptp1] LCP: phase shift AUTHENTICATE --> NETWORK
mpd: ioctl(SIOCSIFMTU): Invalid argument
[pptp1] up: 1 link, total bandwidth 64000 bps
[pptp1] IPCP: Up event
[pptp1] IPCP: state change Starting --> Req-Sent
[pptp1] IPCP: SendConfigReq #1
IPADDR 10.0.0.1
COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
[pptp1] CCP: Open event
[pptp1] CCP: state change Initial --> Starting
[pptp1] CCP: LayerStart
[pptp1] CCP: Up event
[pptp1] CCP: state change Starting --> Req-Sent
[pptp1] CCP: SendConfigReq #1
MPPC
0x01000040: MPPE, 128 bit, stateless
[pptp1] CCP: rec'd Configure Request #4 link 0 (Req-Sent)
MPPC
0x010000e1: MPPC MPPE, 40 bit, 56 bit, 128 bit, stateless
[pptp1] CCP: SendConfigNak #4
MPPC
0x01000040: MPPE, 128 bit, stateless
[pptp1] IPCP: rec'd Configure Request #5 link 0 (Req-Sent)
IPADDR 0.0.0.0
NAKing with 10.0.2.2
PRIDNS 0.0.0.0
NAKing with 10.0.0.1
PRINBNS 0.0.0.0
NAKing with 10.0.0.1
SECDNS 0.0.0.0
SECNBNS 0.0.0.0
[pptp1] IPCP: SendConfigRej #5
SECDNS 0.0.0.0
SECNBNS 0.0.0.0
[pptp1] IPCP: rec'd Configure Reject #1 link 0 (Req-Sent)
COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
[pptp1] IPCP: SendConfigReq #2
IPADDR 10.0.0.1
[pptp1] CCP: rec'd Configure Ack #1 link 0 (Req-Sent)
MPPC
0x01000040: MPPE, 128 bit, stateless
[pptp1] CCP: state change Req-Sent --> Ack-Rcvd
[pptp1] CCP: rec'd Configure Request #6 link 0 (Ack-Rcvd)
MPPC
0x01000040: MPPE, 128 bit, stateless
[pptp1] CCP: SendConfigAck #6
MPPC
0x01000040: MPPE, 128 bit, stateless
[pptp1] CCP: state change Ack-Rcvd --> Opened
[pptp1] CCP: LayerUp
Compress using: MPPE, 128 bit, stateless
Decompress using: MPPE, 128 bit, stateless
mpd: ioctl(SIOCSIFMTU): Invalid argument
[pptp1] IPCP: rec'd Configure Request #7 link 0 (Req-Sent)
IPADDR 0.0.0.0
NAKing with 10.0.2.2
PRIDNS 0.0.0.0
NAKing with 10.0.0.1
PRINBNS 0.0.0.0
NAKing with 10.0.0.1
[pptp1] IPCP: SendConfigNak #7
IPADDR 10.0.2.2
PRIDNS 10.0.0.1
PRINBNS 10.0.0.1
[pptp1] IPCP: rec'd Configure Ack #2 link 0 (Req-Sent)
IPADDR 10.0.0.1
[pptp1] IPCP: state change Req-Sent --> Ack-Rcvd
[pptp1] IPCP: rec'd Configure Request #8 link 0 (Ack-Rcvd)
IPADDR 10.0.2.2
10.0.2.2 is OK
PRIDNS 10.0.0.1
PRINBNS 10.0.0.1
[pptp1] IPCP: SendConfigAck #8
IPADDR 10.0.2.2
PRIDNS 10.0.0.1
PRINBNS 10.0.0.1
[pptp1] IPCP: state change Ack-Rcvd --> Opened
[pptp1] IPCP: LayerUp
10.0.0.1 -> 10.0.2.2
[pptp1] IFACE: Up event
[pptp1] exec: /sbin/ifconfig ng0 10.0.0.1 10.0.2.2 netmask 0xffffffff
-link0
[pptp1] exec: /usr/sbin/arp -s 10.0.2.2 0:a0:c9:3:b4:54 pub
[pptp1] IFACE: Up event
^Cmpd: caught fatal signal int
mpd: fatal error, exiting
[pptp1] IPCP: Down event
[pptp1] IPCP: state change Opened --> Starting
[pptp1] IPCP: LayerDown
[pptp1] IFACE: Down event
[pptp1] exec: /usr/sbin/arp -d 10.0.2.2
[pptp1] exec: /sbin/ifconfig ng0 down delete -link0
[pptp1] IFACE: Close event
[pptp1] IPCP: Close event
[pptp1] IPCP: state change Starting --> Initial
[pptp1] IPCP: LayerFinish
[pptp2] IPCP: Down event
[pptp2] IFACE: Close event
[pptp3] IPCP: Down event
[pptp3] IFACE: Close event
[pptp4] IPCP: Down event
[pptp4] IFACE: Close event
mpd: process 24745 terminated
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 3:25:25 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 9DB0137B401
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 03:25:24 -0700 (PDT)
Received: from office.LF.net (office.LF.net [212.9.190.165])
by mx1.FreeBSD.org (Postfix) with ESMTP id 34F1943E8A
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 03:25:24 -0700 (PDT)
(envelope-from krion@voodoo.oberon.net)
Received: from voodoo.oberon.net ([212.118.165.100])
by office.LF.net with esmtp (Exim 4.04)
id 1812PY-0006Xd-00
for freebsd-net@freebsd.org; Mon, 14 Oct 2002 12:25:20 +0200
Received: from krion by voodoo.oberon.net with local (Exim 4.10)
id 1812Oy-000Dfq-00
for freebsd-net@freebsd.org; ÐÎ, 14 ÏËÔ 2002 12:24:44 +0200
Date: Mon, 14 Oct 2002 12:24:44 +0200
From: Kirill Ponomarew <ponomarew@oberon.net>
To: freebsd-net@freebsd.org
Subject: delayed ACK
Message-ID: <20021014102444.GA52491@krion>
Mail-Followup-To: Kirill Ponomarew <ponomarew@oberon.net>,
freebsd-net@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi,
is it recommended to use net.inet.tcp.delayed_ack=0 on the machines with
heavy network traffic ?
--
MfG
Kirill
Nothing is ever so bad it can't be made worse by
firing the coach.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 8:41:44 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 68B0737B401
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 08:41:43 -0700 (PDT)
Received: from csmail.commserv.ucsb.edu (cspdc.commserv.ucsb.edu [128.111.251.12])
by mx1.FreeBSD.org (Postfix) with ESMTP id 0A1D843EB2
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 08:41:43 -0700 (PDT)
(envelope-from steve@expertcity.com)
Received: from expertcity.com ([68.6.35.15]) by csmail.commserv.ucsb.edu
(Netscape Messaging Server 3.62) with ESMTP id 417;
Mon, 14 Oct 2002 08:41:40 -0700
Message-ID: <3DAAE60E.3010708@expertcity.com>
Date: Mon, 14 Oct 2002 08:43:10 -0700
From: Steve Francis <steve@expertcity.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kirill Ponomarew <ponomarew@oberon.net>
Cc: freebsd-net@freebsd.org
Subject: Re: delayed ACK
References: <20021014102444.GA52491@krion>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Kirill Ponomarew wrote:
> Hi,
>
> is it recommended to use net.inet.tcp.delayed_ack=0 on the machines with
> heavy network traffic ?
>
If you want to increase your network traffic for no particular reason,
and increase load on your server, then yes.
Otherwise no.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 11: 0:49 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5918537B401
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 11:00:47 -0700 (PDT)
Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70])
by mx1.FreeBSD.org (Postfix) with SMTP id 294E543EAF
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 11:00:45 -0700 (PDT)
(envelope-from oppermann@pipeline.ch)
Received: (qmail 41005 invoked from network); 14 Oct 2002 17:57:42 -0000
Received: from unknown (HELO pipeline.ch) ([62.48.0.53]) (envelope-sender <oppermann@pipeline.ch>)
by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP
for <freebsd-net@freebsd.org>; 14 Oct 2002 17:57:42 -0000
Message-ID: <3DAB0604.7E780B3B@pipeline.ch>
Date: Mon, 14 Oct 2002 19:59:32 +0200
From: Andre Oppermann <oppermann@pipeline.ch>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: freebsd-net@freebsd.org, freebsd-isp@freebsd.org
Subject: Statistical Email Message Size Distribution
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
The first numbers of the Swiss Internet Analysis performed by Olivier
Mueller and Daniel Graf are available. The whole study will be available
in November 2002.
Here is the statistical message size distribution of email messages
observed in the analysis. These numbers are very important to find
the right parameters for the filesystem the message store resides on.
For example you have to tune the block size, fragment size and inode
to block ratio to hold so many small files.
We see that in total 49.3% of all messages are 4KB or smaller and that
80% are smaller than 16KB. 11% are between 17 and 64KB big. Almost 97%
are smaller than 512KB.
up to 2KB 23.53%
up to 4KB 25.64%
up to 8KB 18.43%
up to 16KB 11.98%
up to 32KB 5.78%
up to 64KB 5.11%
up to 128KB 2.83%
up to 256KB 2.44%
up to 512KB 1.50%
up to 1MB 1.25%
up to 10MB 1.47%
more 10MB 0.0054%
For these numbers 13.97 million messages flowing through the five
largest Swiss ISPs in the first week of September 2002 have been
analysed. So these numbers clearly apply to an ISP environment.
--
Andre Oppermann
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 11:35:46 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 2F4A737B401
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 11:35:45 -0700 (PDT)
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
by mx1.FreeBSD.org (Postfix) with SMTP id F2C1343EAF
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 11:35:43 -0700 (PDT)
(envelope-from iedowse@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
id <aa83883@salmon>; 14 Oct 2002 19:35:42 +0100 (BST)
To: freebsd-net@freebsd.org
Subject: IP_SENDSRCADDR implementation
Date: Mon, 14 Oct 2002 19:35:42 +0100
From: Ian Dowse <iedowse@maths.tcd.ie>
Message-ID: <200210141935.aa83883@salmon.maths.tcd.ie>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
It was discussed here some time ago that we should have an
IP_SENDSRCADDR ancillary data type to match the IP_RECVDSTADDR
socket option. This permits a server process binding to a wildcard
UDP socket to select the IP address from which outgoing packets are
sent on a per-datagram basis. When combined with IP_RECVDSTADDR,
such server processes can guarantee to reply to a request using the
same source IP address as the destination IP address of the request,
without having to open one socket per server IP address. Thomas
Moestl did an initial implementation of this feature, and the patch
presented here is based on his work and some discussions that
followed.
One approach would be to add to mess in udp_output() where we
temporarily block input and connect the wildcard-bound socket to
the destination address while sending, and do something similar
with binding the source address.
The approach taken here was to instead separate each of in_pcbbind()
and in_pcbconnect() into a *_setup() version of the function that
only performs the port allocation (but does not change the PCB),
and an outer wrapper with the original name that calls the *_setup()
version and then commits the changes to the PCB. Now udp_output()
can use the *_setup() versions to perform the port and address
allocation, so it does not need the temporary connect() hack any
more.
The IP_SENDSRCADDR change consists of adding a control-message
reading loop to udp_output(), and doing an in_pcbbind_setup()
to determine what source address to use for the datagram.
The patch is at:
http://www.maths.tcd.ie/~iedowse/FreeBSD/sendsrcaddr.diff
Unfortunately it is relatively extensive. I've been running it for
about 4 months now, but that does not rule out the possibility of
bugs and unintended side-effects. Any comments, reviews or suggestions
welcome. Is this something that is useful enough to commit now, or
should it be deferred until after 5.0?
Ian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 12:28:44 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id C830137B401
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 12:28:43 -0700 (PDT)
Received: from niwun.pair.com (niwun.pair.com [209.68.2.70])
by mx1.FreeBSD.org (Postfix) with SMTP id 21C2043EBE
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 12:28:43 -0700 (PDT)
(envelope-from silby@silby.com)
Received: (qmail 84168 invoked by uid 3193); 14 Oct 2002 19:28:37 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 14 Oct 2002 19:28:37 -0000
Date: Mon, 14 Oct 2002 15:28:37 -0400 (EDT)
From: Mike Silbersack <silby@silby.com>
X-X-Sender: silby@niwun.pair.com
To: Ian Dowse <iedowse@maths.tcd.ie>
Cc: freebsd-net@freebsd.org
Subject: Re: IP_SENDSRCADDR implementation
In-Reply-To: <200210141935.aa83883@salmon.maths.tcd.ie>
Message-ID: <Pine.BSF.4.44.0210141527210.83670-100000@niwun.pair.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Mon, 14 Oct 2002, Ian Dowse wrote:
> Unfortunately it is relatively extensive. I've been running it for
> about 4 months now, but that does not rule out the possibility of
> bugs and unintended side-effects. Any comments, reviews or suggestions
> welcome. Is this something that is useful enough to commit now, or
> should it be deferred until after 5.0?
>
> Ian
I haven't looked at the implementation, but I think that it would be wise
to include the patch before 5.0-release so that there's a clear cutoff
where the feature became available. Have any patches been made to allow
bind to use this feature yet?
Mike "Silby" Silbersack
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 12:33:14 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 0B89E37B433; Mon, 14 Oct 2002 12:33:08 -0700 (PDT)
Received: from maktoobchat.net (bareed3.maktoob.net [195.172.126.104])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 69BF243EB7; Mon, 14 Oct 2002 12:33:05 -0700 (PDT)
(envelope-from dmusa@maktoob.com)
Received: from [195.172.126.106] (HELO maktoobchat.net)
by maktoobchat.net (CommuniGate Pro SMTP 3.5.8)
with ESMTP id 2201993; Mon, 14 Oct 2002 19:33:39 +0000
Received: from [195.172.126.113] (HELO webmail)
by maktoobchat.net (CommuniGate Pro SMTP 3.4.7)
with SMTP id 5081075; Mon, 14 Oct 2002 19:28:08 +0000
From: dmusa@maktoob.com (Dr.Dan Musa)
To: dmusa@maktoob.com
Subject: Business Proposal
Comment: Maktoob By BOC
X-Mailer: Maktoob 1.0 [Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt; YComp 5.0.2.5)]
X-Originating-IP: [216.139.168.229]
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1256
Content-Transfer-Encoding: 7bit
Date: Mon, 14 Oct 2002 19:28:08 +0000
Message-ID: <auto-000005081075@maktoobchat.net>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
_________________________________________________________
Looking to be employed? We have an ocean of employers and employees waiting to be matched. Go to Maktoob Jobs NOW.
http://www.maktoob.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 13:15:37 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id A300737B401
for <net@FreeBSD.org>; Mon, 14 Oct 2002 13:15:36 -0700 (PDT)
Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4276043EB2
for <net@FreeBSD.org>; Mon, 14 Oct 2002 13:15:36 -0700 (PDT)
(envelope-from jhb@FreeBSD.org)
Received: (qmail 4088 invoked from network); 14 Oct 2002 20:15:29 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63])
(envelope-sender <jhb@FreeBSD.org>)
by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
for <net@FreeBSD.org>; 14 Oct 2002 20:15:29 -0000
Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1])
by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id g9EKFBn5032068
for <net@FreeBSD.org>; Mon, 14 Oct 2002 16:15:14 -0400 (EDT)
(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20021014161512.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Mon, 14 Oct 2002 16:15:12 -0400 (EDT)
From: John Baldwin <jhb@FreeBSD.org>
To: net@FreeBSD.org
Subject: Rename of MSIZE kernel option..
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Would people be open to renaming the 'MSIZE' kernel option to something
more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can
break other places in the kernel. For example, ISA device ivars have
an ivar for the size of a memory resource called 'MSIZE' and the kernel
option causes breakage in src/sys/isa/isavar.h:
ISA_ACCESSOR(msize, MSIZE, int)
when ISA_ACCESSOR is properly defined via __BUS_ACCESSOR() rather than
homerolling a private copy of __BUS_ACCESSOR(). For now I've fixed it
to rename the ISA ivar to ISA_IVAR_MEMSIZE but MSIZE seems to be too
generic a name for a kernel option and it would be nice to avoid this
problem in the future.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 13:20:13 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 6D9C537B404; Mon, 14 Oct 2002 13:20:11 -0700 (PDT)
Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 9948743E9C; Mon, 14 Oct 2002 13:20:09 -0700 (PDT)
(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org ([12.232.206.8])
by sccrmhc03.attbi.com
(InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
id <20021014202008.XZKJ24958.sccrmhc03.attbi.com@InterJet.elischer.org>;
Mon, 14 Oct 2002 20:20:08 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA75356;
Mon, 14 Oct 2002 13:18:31 -0700 (PDT)
Date: Mon, 14 Oct 2002 13:18:30 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: John Baldwin <jhb@FreeBSD.org>
Cc: net@FreeBSD.org
Subject: Re: Rename of MSIZE kernel option..
In-Reply-To: <XFMail.20021014161512.jhb@FreeBSD.org>
Message-ID: <Pine.BSF.4.21.0210141318240.63899-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
go for it..
On Mon, 14 Oct 2002, John Baldwin wrote:
> Would people be open to renaming the 'MSIZE' kernel option to something
> more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can
> break other places in the kernel. For example, ISA device ivars have
> an ivar for the size of a memory resource called 'MSIZE' and the kernel
> option causes breakage in src/sys/isa/isavar.h:
>
> ISA_ACCESSOR(msize, MSIZE, int)
>
> when ISA_ACCESSOR is properly defined via __BUS_ACCESSOR() rather than
> homerolling a private copy of __BUS_ACCESSOR(). For now I've fixed it
> to rename the ISA ivar to ISA_IVAR_MEMSIZE but MSIZE seems to be too
> generic a name for a kernel option and it would be nice to avoid this
> problem in the future.
>
> --
>
> John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 13:59:12 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id CA46D37B401
for <net@freebsd.org>; Mon, 14 Oct 2002 13:59:11 -0700 (PDT)
Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130])
by mx1.FreeBSD.org (Postfix) with ESMTP id EB1C843EA3
for <net@freebsd.org>; Mon, 14 Oct 2002 13:59:10 -0700 (PDT)
(envelope-from jdp@polstra.com)
Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13])
by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g9EKx3x08301;
Mon, 14 Oct 2002 13:59:04 -0700 (PDT)
(envelope-from jdp@vashon.polstra.com)
Received: (from jdp@localhost)
by vashon.polstra.com (8.12.5/8.12.5/Submit) id g9EKx0sY022550;
Mon, 14 Oct 2002 13:59:00 -0700 (PDT)
(envelope-from jdp)
Date: Mon, 14 Oct 2002 13:59:00 -0700 (PDT)
Message-Id: <200210142059.g9EKx0sY022550@vashon.polstra.com>
To: net@freebsd.org
From: John Polstra <jdp@polstra.com>
Cc: hykim@cs.rice.edu
Subject: Re: Tigon 3 bad checksums on TCP packets
In-Reply-To: <Pine.GSO.4.33.0210111723110.9821-100000@frosty.cs.rice.edu>
References: <Pine.GSO.4.33.0210111723110.9821-100000@frosty.cs.rice.edu>
Organization: Polstra & Co., Seattle, WA
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
In article <Pine.GSO.4.33.0210111723110.9821-100000@frosty.cs.rice.edu>,
Hyong-Youb Kim <hykim@cs.rice.edu> wrote:
>
> Thanks. I resolved the issue by forcing BGE_PCI_WRITE_BNDRY_16BYTES
> in BGE_PCI_DMA_RW_CTL register. The linux driver apparently has a DMA test
> code and sets this value depending on the test results. I have no clue as
> to why this configuration messes up TCP receive packets and not UDP
> packets.
I notice that everybody who's reported this problem has an Athlon. I
guess there must be a bad interaction with the Athlon chipsets. I
don't know why you're seeing the problem only on TCP packets.
John
--
John Polstra
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 14: 0:51 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id BF9B637B401
for <net@freebsd.org>; Mon, 14 Oct 2002 14:00:50 -0700 (PDT)
Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130])
by mx1.FreeBSD.org (Postfix) with ESMTP id 061AA43EA3
for <net@freebsd.org>; Mon, 14 Oct 2002 14:00:50 -0700 (PDT)
(envelope-from jdp@polstra.com)
Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13])
by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g9EL0mx08322;
Mon, 14 Oct 2002 14:00:48 -0700 (PDT)
(envelope-from jdp@vashon.polstra.com)
Received: (from jdp@localhost)
by vashon.polstra.com (8.12.5/8.12.5/Submit) id g9EL0lnn022565;
Mon, 14 Oct 2002 14:00:47 -0700 (PDT)
(envelope-from jdp)
Date: Mon, 14 Oct 2002 14:00:47 -0700 (PDT)
Message-Id: <200210142100.g9EL0lnn022565@vashon.polstra.com>
To: net@freebsd.org
From: John Polstra <jdp@polstra.com>
Cc: hykim@cs.rice.edu
Subject: Re: Tigon 3 bad checksums on TCP packets
In-Reply-To: <Pine.GSO.4.33.0210120045320.12482-100000@frosty.cs.rice.edu>
References: <Pine.GSO.4.33.0210120045320.12482-100000@frosty.cs.rice.edu>
Organization: Polstra & Co., Seattle, WA
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
In article <Pine.GSO.4.33.0210120045320.12482-100000@frosty.cs.rice.edu>,
Hyong-Youb Kim <hykim@cs.rice.edu> wrote:
>
> BTW, setting BGE_PCI_WRITE_BNDRY_16BYTES limits receive throughput to
> 540Mb/s. So it is not a solution.
> I really like to find out what this config does.
It works around a bug in the BCM570x chip, apparently. I noticed
that the Linux driver only applies this workaround for 5700 and 5701
chips. If you want better performance you may have to wait until
you can buy cards with the newer 5703 chips on them. Or, switch to
a non-Athlon system.
John
--
John Polstra
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 14:23:11 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id BEA2637B401; Mon, 14 Oct 2002 14:23:09 -0700 (PDT)
Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 11D6643EAA; Mon, 14 Oct 2002 14:23:09 -0700 (PDT)
(envelope-from gallatin@cs.duke.edu)
Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30])
by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id RAA06015;
Mon, 14 Oct 2002 17:23:08 -0400 (EDT)
Received: (from gallatin@localhost)
by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g9ELMcc54226;
Mon, 14 Oct 2002 17:22:38 -0400 (EDT)
(envelope-from gallatin@cs.duke.edu)
From: Andrew Gallatin <gallatin@cs.duke.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15787.13726.246550.526201@grasshopper.cs.duke.edu>
Date: Mon, 14 Oct 2002 17:22:38 -0400 (EDT)
To: John Baldwin <jhb@FreeBSD.org>
Cc: net@FreeBSD.org
Subject: Re: Rename of MSIZE kernel option..
In-Reply-To: <XFMail.20021014161512.jhb@FreeBSD.org>
References: <XFMail.20021014161512.jhb@FreeBSD.org>
X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
John Baldwin writes:
> Would people be open to renaming the 'MSIZE' kernel option to something
> more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can
No.
MSIZE is a traditional BSDism. Everybody else still uses it.
Even AIX and MacOS. I really don't like the idea of changing this.
> break other places in the kernel. For example, ISA device ivars have
> an ivar for the size of a memory resource called 'MSIZE' and the kernel
> option causes breakage in src/sys/isa/isavar.h:
>
> ISA_ACCESSOR(msize, MSIZE, int)
>
> when ISA_ACCESSOR is properly defined via __BUS_ACCESSOR() rather than
> homerolling a private copy of __BUS_ACCESSOR(). For now I've fixed it
> to rename the ISA ivar to ISA_IVAR_MEMSIZE but MSIZE seems to be too
> generic a name for a kernel option and it would be nice to avoid this
> problem in the future.
Renaming MSIZE to ISA_IVAR_MEMSIZE seems right to me.
Drew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 15: 0:18 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 0FAED37B404
for <freebsd-net@FreeBSD.ORG>; Mon, 14 Oct 2002 15:00:16 -0700 (PDT)
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by mx1.FreeBSD.org (Postfix) with ESMTP id 2F95343EB2
for <freebsd-net@FreeBSD.ORG>; Mon, 14 Oct 2002 15:00:15 -0700 (PDT)
(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id OAA28294;
Mon, 14 Oct 2002 14:45:26 -0700 (PDT)
Received: from arch20m.dellroad.org (localhost [127.0.0.1])
by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9ELi3ON084596;
Mon, 14 Oct 2002 14:44:03 -0700 (PDT)
(envelope-from archie@arch20m.dellroad.org)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9ELi3AT084595;
Mon, 14 Oct 2002 14:44:03 -0700 (PDT)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200210142144.g9ELi3AT084595@arch20m.dellroad.org>
Subject: Re: MPD PPTP tunneling intermittantly fails
In-Reply-To: <AEEMJFAIHDPJNCAKCHHBIEHDCHAA.leonardc@cs.berkeley.edu>
"from Leonard Chung at Oct 14, 2002 01:59:58 am"
To: Leonard Chung <leonardc@cs.berkeley.edu>
Date: Mon, 14 Oct 2002 14:44:03 -0700 (PDT)
Cc: freebsd-net@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Leonard Chung writes:
> The problem that I'm having is that MPD starts properly and I can
> successfully connect to the service using Windows clients. However, when I
> ping internal hosts, the first five or so work fine, and then beyond that
> packets start getting lost, with a loss rate of around 50%. These tests are
> run over a local network with two subnets, so packet loss shouldn't be a
> problem. So although I can currently connect and create a tunnel, it isn't
> very useful as beyond any initial DNS queries, file transfers, etc. fail
> completely.
Are you using Mac OS X clients? If so, you may need the
latest patch to ng_pptpgre(4) to work around a problem:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_pptpgre.c.diff?r1=1.25&r2=1.26
Otherwise, I haven't heard of anyone else having that particular problem..
See if you have errors reported by 'ngctl msg ng0:inet.ppp.link0 getstats'
(replace 'ng0' with the appropriate inteface name).
> Also, is there any way to get DHCP to work with MPD rather than hard wire
> IPs directly into MPD's config files?
Unfortunately not.
> I'm guessing this is probably just something easy that I'm missing. My
> config files and an MPD trace are below.
These look reasonable.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 17:46:36 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 42E5537B401
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 17:46:35 -0700 (PDT)
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
by mx1.FreeBSD.org (Postfix) with SMTP id 1EAA543EAC
for <freebsd-net@freebsd.org>; Mon, 14 Oct 2002 17:46:34 -0700 (PDT)
(envelope-from iedowse@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
id <aa39010@salmon>; 15 Oct 2002 01:46:33 +0100 (BST)
To: Mike Silbersack <silby@silby.com>
Cc: freebsd-net@freebsd.org
Subject: Re: IP_SENDSRCADDR implementation
In-Reply-To: Your message of "Mon, 14 Oct 2002 15:28:37 EDT."
<Pine.BSF.4.44.0210141527210.83670-100000@niwun.pair.com>
Date: Tue, 15 Oct 2002 01:46:31 +0100
From: Ian Dowse <iedowse@maths.tcd.ie>
Message-ID: <200210150146.aa39010@salmon.maths.tcd.ie>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
In message <Pine.BSF.4.44.0210141527210.83670-100000@niwun.pair.com>, Mike Silb
ersack writes:
>
>I haven't looked at the implementation, but I think that it would be wise
>to include the patch before 5.0-release so that there's a clear cutoff
>where the feature became available.
Ok - I'll see what the reaction here is first and then check with
re@ before considering committing it.
>Have any patches been made to allow
>bind to use this feature yet?
Bind as in named? No, I haven't looked into this, but it would be
a very good candidate, as I think it would remove the issue of
having to bind to new IP addresses while running as an unpriviledged
user.
The other thing that could be done here for improved compatibility
is to implement the Linux IP_PKTINFO socket option and control
message. Doing this should be fairly trivial once the IP_SENDSRCADDR
code is in place.
Ian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 20:53:44 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 997B537B401; Mon, 14 Oct 2002 20:53:43 -0700 (PDT)
Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24])
by mx1.FreeBSD.org (Postfix) with ESMTP
id C868443ECF; Mon, 14 Oct 2002 20:53:42 -0700 (PDT)
(envelope-from bmilekic@unixdaemons.com)
Received: (from bmilekic@localhost)
by tesla.distributel.net (8.11.6/8.11.6) id g9F3uAI60012;
Mon, 14 Oct 2002 23:56:10 -0400 (EDT)
(envelope-from bmilekic@unixdaemons.com)
Date: Mon, 14 Oct 2002 23:56:10 -0400
From: Bosko Milekic <bmilekic@unixdaemons.com>
To: John Baldwin <jhb@FreeBSD.org>
Cc: net@FreeBSD.org
Subject: Re: Rename of MSIZE kernel option..
Message-ID: <20021014235610.A59973@unixdaemons.com>
References: <XFMail.20021014161512.jhb@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <XFMail.20021014161512.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Mon, Oct 14, 2002 at 04:15:12PM -0400
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Not that my opinion really holds much weight with you guys but for what
it's worth, I think the change would be gratuitist.
1. MSIZE has been around forever.
2. The argument that sys/sys/mbuf.h should have MSIZE removed/changed
because some other code may use it is fallacious. The "other code"
should be careful not to use a constant that has been so named for the
longest time I can recall.
On Mon, Oct 14, 2002 at 04:15:12PM -0400, John Baldwin wrote:
> Would people be open to renaming the 'MSIZE' kernel option to something
> more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can
> break other places in the kernel. For example, ISA device ivars have
> an ivar for the size of a memory resource called 'MSIZE' and the kernel
> option causes breakage in src/sys/isa/isavar.h:
>
> ISA_ACCESSOR(msize, MSIZE, int)
>
> when ISA_ACCESSOR is properly defined via __BUS_ACCESSOR() rather than
> homerolling a private copy of __BUS_ACCESSOR(). For now I've fixed it
> to rename the ISA ivar to ISA_IVAR_MEMSIZE but MSIZE seems to be too
> generic a name for a kernel option and it would be nice to avoid this
> problem in the future.
>
> --
>
> John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
--
Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 21:12:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 021A837B404
for <net@FreeBSD.ORG>; Mon, 14 Oct 2002 21:12:58 -0700 (PDT)
Received: from ares.cs.Virginia.EDU (ares.cs.Virginia.EDU [128.143.137.19])
by mx1.FreeBSD.org (Postfix) with ESMTP id 01EE243E9E
for <net@FreeBSD.ORG>; Mon, 14 Oct 2002 21:12:57 -0700 (PDT)
(envelope-from nicolas@cs.virginia.edu)
Received: from arachnion.cs.Virginia.EDU (arachnion.cs.Virginia.EDU [128.143.136.20])
by ares.cs.Virginia.EDU (8.9.3+Sun/8.9.2/UVACS-2000040300) with ESMTP id AAA22191
for <net@FreeBSD.ORG>; Tue, 15 Oct 2002 00:12:56 -0400 (EDT)
Received: from localhost (nc2y@localhost)
by arachnion.cs.Virginia.EDU (8.9.2/8.9.2) with ESMTP id AAA13140
for <net@FreeBSD.ORG>; Tue, 15 Oct 2002 00:12:55 -0400 (EDT)
X-Authentication-Warning: arachnion.cs.Virginia.EDU: nc2y owned process doing -bs
Date: Tue, 15 Oct 2002 00:12:55 -0400 (EDT)
From: Nicolas Christin <nicolas@cs.virginia.edu>
X-X-Sender: nc2y@arachnion.cs.Virginia.EDU
To: net@FreeBSD.ORG
Subject: Re: Rename of MSIZE kernel option..
In-Reply-To: <15787.13726.246550.526201@grasshopper.cs.duke.edu>
Message-ID: <Pine.GSO.4.44.0210150002310.13090-100000@arachnion.cs.Virginia.EDU>
Organization: University of Virginia - CS Dept.
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Note: I'm just a lurker here, but thought I'd give my 2 cents on this
discussion as well.
On Mon, 14 Oct 2002, Andrew Gallatin wrote:
> > Would people be open to renaming the 'MSIZE' kernel option to something
> > more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can
>
> No.
>
> MSIZE is a traditional BSDism. Everybody else still uses it.
> Even AIX and MacOS. I really don't like the idea of changing this.
True, but John is right, it's too generic a name. The argument "it's
been forever so we can't change it" seems a bit fallacious to me:
that's with that line of thinking that one ends up with breakages no one
can figure out years down the road. You end up having to keep pieces of
code no one really knows what they're doing anymore, but if you take
them out, the whole thing crashes and burns. Not that I'm saying it
would be the case for something as obvious as MSIZE, but still...
> Renaming MSIZE to ISA_IVAR_MEMSIZE seems right to me.
I agree. Don't use something like MSIZE at all. The name is not explicit
enough.
For a transition period, one could define both an MSIZE and an MBUF_SIZE
equivalent to MSIZE for a couple of versions (say the whole 5.x series),
clearly stating MSIZE is deprecated and shouldn't be used anymore, and
then it could be completely removed in 6.x.
--
Nicolas Christin
Ph.D. Candidate, University of Virginia, Computer Science
http://www.cs.virginia.edu/~nicolas
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon Oct 14 23:13: 9 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 70F1B37B401
for <freebsd-net@FreeBSD.ORG>; Mon, 14 Oct 2002 23:13:08 -0700 (PDT)
Received: from a.smtp-out.sonic.net (a.smtp-out.sonic.net [208.201.224.38])
by mx1.FreeBSD.org (Postfix) with SMTP id E1AB343EAA
for <freebsd-net@FreeBSD.ORG>; Mon, 14 Oct 2002 23:13:07 -0700 (PDT)
(envelope-from gharris@sonic.net)
Received: (qmail 15087 invoked from network); 15 Oct 2002 06:13:06 -0000
Received: from ultra.sonic.net (208.201.224.22)
by a.smtp-out.sonic.net with SMTP; 15 Oct 2002 06:13:06 -0000
Received: from quadrajet.sonic.net (adsl-209-204-185-65.sonic.net [209.204.185.65])
by ultra.sonic.net (8.11.6/8.8.5) with ESMTP id g9F6D6r10999;
Mon, 14 Oct 2002 23:13:06 -0700
X-envelope-info: <gharris@sonic.net>
Received: (from guy@localhost)
by quadrajet.sonic.net (8.9.3/8.9.3) id XAA88478;
Mon, 14 Oct 2002 23:13:05 -0700 (PDT)
(envelope-from gharris)
Date: Mon, 14 Oct 2002 23:13:05 -0700
From: Guy Harris <gharris@sonic.net>
To: Harti Brandt <brandt@fokus.gmd.de>
Cc: Craig Rodrigues <rodrigc@attbi.com>, freebsd-net@FreeBSD.ORG
Subject: Re: How to add bpf support to if_atmsubr.c?
Message-ID: <20021014231305.H332@quadrajet.sonic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> The problem is, that at attach time you
> don't know what link-level encapsulation is used, because this can be
> select when you establish the VCC (via the parameter 'z' (see en(4))).
> So BPF_DLC_RFC1483 will not work without LLC/SNAP encapsulation.
The current CVS versions of libpcap and tcpdump, and the current
released version of Ethereal, support a DLT_SUNATM DLT_ type. SunATM's
DLPI interface supplies packets with a 4-byte pseudo-header, consisting of:
a 1-byte flag byte;
a 1-byte VPI value;
a 2-byte (big-endian) VCI value;
where the flag byte contains a one-bit "direction" flag (indicating
whether the packet was sent or received) and a 4-bit packet type. After
that comes the raw reassembled PDU.
The packet type can be one of
"raw" - meaning "other"?
LANE
LLC-multiplexed
MARS
IFMP
ILMI
Q.2931
A similar thing could perhaps be done here; that'd allow the driver to
supply signalling traffic to BPF, for example. That way, the
encapsulation type - DLT_BPFATM, or something such as that - wouldn't
depend on the circuit type; it'd be supplied to the application as part
of the packet pseudo-header.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 1:47:23 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 3B72437B401
for <net@FreeBSD.ORG>; Tue, 15 Oct 2002 01:47:22 -0700 (PDT)
Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30])
by mx1.FreeBSD.org (Postfix) with SMTP id 76BE143EB1
for <net@FreeBSD.ORG>; Tue, 15 Oct 2002 01:47:20 -0700 (PDT)
(envelope-from keramida@ceid.upatras.gr)
Received: (qmail 27036 invoked from network); 15 Oct 2002 08:40:16 -0000
Received: from upnet-dialinpool-83.upnet.gr (HELO hades.hell.gr) (@150.140.128.171)
by nic.upatras.gr with SMTP; 15 Oct 2002 08:40:16 -0000
Received: by hades.hell.gr (Postfix, from userid 1001)
id 7F597B60D; Tue, 15 Oct 2002 08:01:03 +0300 (EEST)
Date: Tue, 15 Oct 2002 08:01:03 +0300
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: Nicolas Christin <nicolas@cs.virginia.edu>
Cc: net@FreeBSD.ORG
Subject: Re: Rename of MSIZE kernel option..
Message-ID: <20021015050103.GD14604@hades.hell.gr>
References: <15787.13726.246550.526201@grasshopper.cs.duke.edu> <Pine.GSO.4.44.0210150002310.13090-100000@arachnion.cs.Virginia.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.44.0210150002310.13090-100000@arachnion.cs.Virginia.EDU>
X-PGP-Fingerprint: C1EB 0653 DB8B A557 3829 00F9 D60F 941A 3186 03B6
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On 2002-10-15 00:12, Nicolas Christin <nicolas@cs.virginia.edu> wrote:
> On Mon, 14 Oct 2002, Andrew Gallatin wrote:
> > > Would people be open to renaming the 'MSIZE' kernel option to something
> > > more specific such as 'MBUF_SIZE' or 'MBUFSIZE'? Using 'MSIZE' can
> >
> > No.
> >
> > MSIZE is a traditional BSDism. Everybody else still uses it.
> > Even AIX and MacOS. I really don't like the idea of changing this.
>
> True, but John is right, it's too generic a name. The argument "it's
> been forever so we can't change it" seems a bit fallacious to me:
True. But that sort of reasoning might lead us one day to rename
macros and functions like m_get() to mbuf_get() or similar. That
doesn't seem like a good idea :-/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 4: 1:12 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6B60B37B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 04:01:11 -0700 (PDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
by mx1.FreeBSD.org (Postfix) with ESMTP id 551C643E7B
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 04:01:10 -0700 (PDT)
(envelope-from brandt@fokus.gmd.de)
Received: from beagle (beagle [193.175.132.100])
by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g9FB15e14694;
Tue, 15 Oct 2002 13:01:05 +0200 (MEST)
Date: Tue, 15 Oct 2002 13:01:05 +0200 (CEST)
From: Harti Brandt <brandt@fokus.gmd.de>
To: Bruce M Simpson <bms@spc.org>
Cc: Guy Harris <gharris@sonic.net>,
Craig Rodrigues <rodrigc@attbi.com>, <freebsd-net@FreeBSD.ORG>
Subject: Re: How to add bpf support to if_atmsubr.c?
In-Reply-To: <20021015105452.GH6089@spc.org>
Message-ID: <20021015125732.K54193-100000@beagle.fokus.gmd.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, 15 Oct 2002, Bruce M Simpson wrote:
BMS>On Mon, Oct 14, 2002 at 11:13:05PM -0700, Guy Harris wrote:
BMS>> The current CVS versions of libpcap and tcpdump, and the current
BMS>> released version of Ethereal, support a DLT_SUNATM DLT_ type. SunATM's
BMS>> DLPI interface supplies packets with a 4-byte pseudo-header, consisting of:
BMS>[snip]
BMS>
BMS>Just FYI...
BMS>
BMS>This sounds very similar to the promiscuous cell receive option on ENI's
BMS>SpeedStream 5861 router. I found the raw hex cell output was essentially
BMS>a 4 byte ATM UNI header omitting the CRC byte, and the 48 bytes of the raw
BMS>AAL5 cell payload.
The marconi HE cards have the same format although they have no promiscous
mode (although it would be easy to configure all unused connections to
receveive to a free receive group, the question is whether you want this
(350000/packets per second for OC3)). My driver allows you to receive
cells (i.e. AAL0) on any of the supported connections.
BMS>Is there any open source support for the SunATM PCI cards? I see a few of
BMS>them cropping up on eBay from time to time. It might be worth finding out
BMS>which ASICs they use, I doubt Sun would engineer their own.
Does Sun still make ATM cards? As far as I remember I saw the last SBUS
cards a couple of years ago.
harti
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
brandt@fokus.gmd.de, brandt@fokus.fhg.de
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 5:16: 3 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 02D6337B401
for <net@freebsd.org>; Tue, 15 Oct 2002 05:16:03 -0700 (PDT)
Received: from mail.dada.it (mail4.dada.it [195.110.100.4])
by mx1.FreeBSD.org (Postfix) with SMTP id 29DF743EAA
for <net@freebsd.org>; Tue, 15 Oct 2002 05:15:58 -0700 (PDT)
(envelope-from ale@unixmania.net)
Received: (qmail 3039 invoked from network); 15 Oct 2002 12:15:49 -0000
Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252)
by mail.dada.it with SMTP; 15 Oct 2002 12:15:49 -0000
Received: by libero.sunshine.ale (Postfix, from userid 1001)
id D6CF2602F; Tue, 15 Oct 2002 14:15:50 +0200 (CEST)
Date: Tue, 15 Oct 2002 14:15:50 +0200
From: Alessandro de Manzano <adm@unixmania.net>
To: net@freebsd.org
Subject: which L2TP server ?
Message-ID: <20021015141550.A24823@libero.sunshine.ale>
Reply-To: Alessandro de Manzano <adm@unixmania.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-Operating-System: FreeBSD 4.7-STABLE
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hello!
I'm looking for a good L2TP server for FreeBSD, someone knows it ?
If I'm right MPD does not (yet?) support L2TP.
Thanks in advance!
--
bye!
Ale
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 5:41:16 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id BE69937B401
for <net@freebsd.org>; Tue, 15 Oct 2002 05:41:07 -0700 (PDT)
Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10])
by mx1.FreeBSD.org (Postfix) with ESMTP id 805F843E9C
for <net@freebsd.org>; Tue, 15 Oct 2002 05:41:06 -0700 (PDT)
(envelope-from maxim@macomnet.ru)
Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14])
by relay1.macomnet.ru (8.11.6/8.11.6) with ESMTP id g9FCf4Z1183732
for <net@freebsd.org>; Tue, 15 Oct 2002 16:41:05 +0400 (MSD)
Date: Tue, 15 Oct 2002 16:41:04 +0400 (MSD)
From: Maxim Konovalov <maxim@macomnet.ru>
X-X-Sender: Maxim Konovalov <maxim@macomnet.ru>
To: net@freebsd.org
Subject: RFR: ping(8) patches: do not fragment, TOS, maximum payload
Message-ID: <20021015162242.J54875-100000@news1.macomnet.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hello,
I have made a patch set for ping(8). I'll appreciate your comments.
I did not include patches #3 and #4, they are stylistic mostly (based
on BDE's style patch).
A cumulative patch is there:
http://people.freebsd.org/~maxim/p.cumulative
#1, Print strict source routing option. Requested by David Wang
<dsw@juniper.net>.
Index: ping.c
===================================================================
RCS file: /home/maxim/cvs/ping/ping.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ping.c 15 Oct 2002 11:56:58 -0000 1.1
+++ ping.c 15 Oct 2002 11:57:53 -0000 1.2
@@ -953,7 +953,9 @@
hlen = 0;
break;
case IPOPT_LSRR:
- (void)printf("\nLSRR: ");
+ case IPOPT_SSRR:
+ (void)printf(*cp == IPOPT_LSRR ?
+ "\nLSRR: " : "\nSSRR: ");
j = cp[IPOPT_OLEN] - IPOPT_MINOFF + 1;
hlen -= 2;
cp += 2;
%%%
#2, Implement -D (do not fragment) and -z (TOS) options. Obtained from
OpenBSD, bin/35843.
Index: ping.c
===================================================================
RCS file: /home/maxim/cvs/ping/ping.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ping.c 15 Oct 2002 11:57:53 -0000 1.2
+++ ping.c 15 Oct 2002 12:04:10 -0000 1.3
@@ -67,6 +67,7 @@
*/
#include <sys/param.h> /* NB: we rely on this for <sys/types.h> */
+#include <sys/sysctl.h>
#include <ctype.h>
#include <err.h>
@@ -107,6 +108,7 @@
#define MAXPAYLOAD (IP_MAXPACKET - MAXIPLEN - MINICMPLEN)
#define MAXWAIT 10 /* max seconds to wait for response */
#define MAXALARM (60 * 60) /* max seconds for alarm timeout */
+#define MAXTOS 255
#define A(bit) rcvd_tbl[(bit)>>3] /* identify byte in array */
#define B(bit) (1 << ((bit) & 0x07)) /* identify bit in byte */
@@ -138,6 +140,7 @@
#define F_TTL 0x8000
#define F_MISSED 0x10000
#define F_ONCE 0x20000
+#define F_HDRINCL 0x40000
/*
* MAX_DUP_CHK is the number of bits in received table, i.e. the maximum
@@ -151,7 +154,7 @@
struct sockaddr_in whereto; /* who to ping */
int datalen = DEFDATALEN;
int s; /* socket file descriptor */
-u_char outpack[MINICMPLEN + MAXPAYLOAD];
+u_char outpackhdr[IP_MAXPACKET], *outpack;
char BSPACE = '\b'; /* characters written for flood */
char BBELL = '\a'; /* characters written for MISSED and AUDIBLE */
char DOT = '.';
@@ -201,6 +204,7 @@
{
struct in_addr ifaddr;
struct iovec iov;
+ struct ip *ip;
struct msghdr msg;
struct sigaction si_sa;
struct sockaddr_in from, sin;
@@ -209,13 +213,15 @@
struct hostent *hp;
struct sockaddr_in *to;
double t;
+ size_t sz;
u_char *datap, packet[IP_MAXPACKET];
char *ep, *source, *target;
#ifdef IPSEC_POLICY_IPSEC
char *policy_in, *policy_out;
#endif
u_long alarmtimeout, ultmp;
- int ch, hold, i, packlen, preload, sockerrno, almost_done = 0, ttl;
+ int ch, df, hold, i, mib[4], packlen, preload, sockerrno,
+ almost_done = 0, tos, ttl;
char ctrl[CMSG_SPACE(sizeof(struct timeval))];
char hnamebuf[MAXHOSTNAMELEN], snamebuf[MAXHOSTNAMELEN];
#ifdef IP_OPTIONS
@@ -239,11 +245,12 @@
setuid(getuid());
uid = getuid();
- alarmtimeout = preload = 0;
+ alarmtimeout = df = preload = tos = 0;
+ outpack = outpackhdr + sizeof(struct ip);
datap = &outpack[MINICMPLEN + PHDR_LEN];
while ((ch = getopt(argc, argv,
- "AI:LQRS:T:c:adfi:l:m:nop:qrs:t:v"
+ "ADI:LQRS:T:c:adfi:l:m:nop:qrs:t:vz:"
#ifdef IPSEC
#ifdef IPSEC_POLICY_IPSEC
"P:"
@@ -266,6 +273,10 @@
optarg);
npackets = ultmp;
break;
+ case 'D':
+ options |= F_HDRINCL;
+ df = 1;
+ break;
case 'd':
options |= F_SO_DEBUG;
break;
@@ -390,6 +401,13 @@
else
errx(1, "invalid security policy");
break;
+ case 'z':
+ options |= F_HDRINCL;
+ ultmp = strtoul(optarg, &ep, 0);
+ if (*ep || ep == optarg || ultmp > MAXTOS)
+ errx(EX_USAGE, "invalid TOS: `%s'", optarg);
+ tos = ultmp;
+ break;
#endif /*IPSEC_POLICY_IPSEC*/
#endif /*IPSEC*/
default:
@@ -509,6 +527,28 @@
#endif /*IPSEC_POLICY_IPSEC*/
#endif /*IPSEC*/
+ if (options & F_HDRINCL) {
+ ip = (struct ip*)outpackhdr;
+ if (!(options & (F_TTL | F_MTTL))) {
+ mib[0] = CTL_NET;
+ mib[1] = PF_INET;
+ mib[2] = IPPROTO_IP;
+ mib[3] = IPCTL_DEFTTL;
+ sz = sizeof(ttl);
+ if (sysctl(mib, 4, &ttl, &sz, NULL, 0) == -1)
+ err(1, "sysctl(net.inet.ip.ttl)");
+ }
+ setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hold, sizeof(hold));
+ ip->ip_v = IPVERSION;
+ ip->ip_hl = sizeof(struct ip) >> 2;
+ ip->ip_tos = tos;
+ ip->ip_id = 0;
+ ip->ip_off = df ? IP_DF : 0;
+ ip->ip_ttl = ttl;
+ ip->ip_p = IPPROTO_ICMP;
+ ip->ip_src.s_addr = source ? sin.sin_addr.s_addr : INADDR_ANY;
+ ip->ip_dst = to->sin_addr;
+ }
/* record route option */
if (options & F_RROUTE) {
#ifdef IP_OPTIONS
@@ -758,9 +798,12 @@
static void
pinger(void)
{
+ struct ip *ip;
struct icmp *icp;
int cc, i;
+ u_char *packet;
+ packet = outpack;
icp = (struct icmp *)outpack;
icp->icmp_type = ICMP_ECHO;
icp->icmp_code = 0;
@@ -779,7 +822,14 @@
/* compute ICMP checksum here */
icp->icmp_cksum = in_cksum((u_short *)icp, cc);
- i = sendto(s, (char *)outpack, cc, 0, (struct sockaddr *)&whereto,
+ if (options & F_HDRINCL) {
+ cc += sizeof(struct ip);
+ ip = (struct ip *)outpackhdr;
+ ip->ip_len = cc;
+ ip->ip_sum = in_cksum((u_short *)outpackhdr, cc);
+ packet = outpackhdr;
+ }
+ i = sendto(s, (char *)packet, cc, 0, (struct sockaddr *)&whereto,
sizeof(whereto));
if (i < 0 || i != cc) {
@@ -1448,7 +1498,7 @@
usage()
{
(void)fprintf(stderr, "%s\n%s\n%s\n",
-"usage: ping [-AQRadfnoqrv] [-c count] [-i wait] [-l preload] [-m ttl]",
+"usage: ping [-ADQRadfnoqrv] [-c count] [-i wait] [-l preload] [-m ttl]",
" [-p pattern] "
#ifdef IPSEC
#ifdef IPSEC_POLICY_IPSEC
@@ -1456,6 +1506,6 @@
#endif
#endif
"[-s packetsize] [-S src_addr] [-t timeout]",
-" [host | [-L] [-I iface] [-T ttl] mcast-group]");
+" [-z tos ] [host | [-L] [-I iface] [-T ttl] mcast-group]");
exit(EX_USAGE);
}
Index: ping.8
===================================================================
RCS file: /home/maxim/cvs/ping/ping.8,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ping.8 15 Oct 2002 11:56:58 -0000 1.1
+++ ping.8 15 Oct 2002 12:04:10 -0000 1.2
@@ -42,7 +42,7 @@
packets to network hosts
.Sh SYNOPSIS
.Nm
-.Op Fl AQRadfnoqrv
+.Op Fl ADQRadfnoqrv
.Op Fl c Ar count
.Op Fl i Ar wait
.Op Fl l Ar preload
@@ -52,6 +52,7 @@
.Op Fl s Ar packetsize
.Op Fl S Ar src_addr
.Op Fl t Ar timeout
+.Op Fl z Ar tos
.Bo
.Ar host |
.Op Fl L
@@ -111,6 +112,8 @@
Set the
.Dv SO_DEBUG
option on the socket being used.
+.It Fl D
+Set the Don't Fragment bit.
.It Fl f
Flood ping.
Outputs packets as fast as they come back or one hundred times per second,
@@ -252,6 +255,8 @@
packets other than
.Tn ECHO_RESPONSE
that are received are listed.
+.It Fl z Ar tos
+Use the specified type of service.
.El
.Pp
When using
%%%
#5 Do not constantify maximum payload size. It is 65467 with -R
(record route), and 65507 without it.
Index: ping.c
===================================================================
RCS file: /home/maxim/cvs/ping/ping.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ping.c 15 Oct 2002 12:04:40 -0000 1.5
+++ ping.c 15 Oct 2002 12:04:59 -0000 1.6
@@ -104,7 +104,6 @@
#define MAXIPLEN (sizeof(struct ip) + MAX_IPOPTLEN)
#define MAXICMPLEN (ICMP_ADVLENMIN + MAX_IPOPTLEN)
#define MINICMPLEN ICMP_MINLEN
-#define MAXPAYLOAD (IP_MAXPACKET - MAXIPLEN - MINICMPLEN)
#define MAXWAIT 10 /* max seconds to wait for response */
#define MAXALARM (60 * 60) /* max seconds for alarm timeout */
#define MAXTOS 255
@@ -151,6 +150,7 @@
char rcvd_tbl[MAX_DUP_CHK / 8];
struct sockaddr_in whereto; /* who to ping */
+long maxpayload;
int datalen = DEFDATALEN;
int s; /* socket file descriptor */
u_char outpackhdr[IP_MAXPACKET], *outpack;
@@ -351,18 +351,16 @@
options |= F_SO_DONTROUTE;
break;
case 's': /* size of packet to send */
- if (uid) {
- errno = EPERM;
- err(EX_NOPERM, "-s flag");
- }
ultmp = strtoul(optarg, &ep, 0);
- if (ultmp > MAXPAYLOAD)
- errx(EX_USAGE,
- "packet size too large: %lu > %u",
- ultmp, MAXPAYLOAD);
if (*ep || ep == optarg)
errx(EX_USAGE, "invalid packet size: `%s'",
optarg);
+ if (uid != 0 && ultmp > DEFDATALEN) {
+ errno = EPERM;
+ err(EX_NOPERM,
+ "packet size too large: %lu > %u",
+ ultmp, DEFDATALEN);
+ }
datalen = ultmp;
break;
case 'S':
@@ -418,6 +416,12 @@
usage();
target = argv[optind];
+ maxpayload = IP_MAXPACKET - sizeof(struct ip) - MINICMPLEN;
+ if (options & F_RROUTE)
+ maxpayload -= MAX_IPOPTLEN;
+ if (datalen > maxpayload)
+ errx(EX_USAGE, "packet size too large: %lu > %u", datalen,
+ maxpayload);
if (source) {
bzero((char *)&sin, sizeof(sin));
sin.sin_family = AF_INET;
@@ -1476,7 +1480,7 @@
&pat[13], &pat[14], &pat[15]);
if (ii > 0)
- for (kk = 0; kk <= MAXPAYLOAD - (PHDR_LEN + ii); kk += ii)
+ for (kk = 0; kk <= maxpayload - (PHDR_LEN + ii); kk += ii)
for (jj = 0; jj < ii; ++jj)
bp[jj + kk] = pat[jj];
if (!(options & F_QUIET)) {
Index: ping.8
===================================================================
RCS file: /home/maxim/cvs/ping/ping.8,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ping.8 15 Oct 2002 12:04:10 -0000 1.2
+++ ping.8 15 Oct 2002 12:04:59 -0000 1.3
@@ -235,7 +235,7 @@
with the 8 bytes of
.Tn ICMP
header data.
-Only the super-user may use this option.
+Only the super-user may specify values more then default.
.It Fl S Ar src_addr
Use the following IP address as the source address in outgoing packets.
On hosts with more than one IP address, this option can be used to
%%%
Thank you very much.
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:maxim@macomnet.ru
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 7:10:32 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B6DCB37B401
for <net@freebsd.org>; Tue, 15 Oct 2002 07:10:31 -0700 (PDT)
Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18])
by mx1.FreeBSD.org (Postfix) with SMTP id 4D56343E9E
for <net@freebsd.org>; Tue, 15 Oct 2002 07:10:31 -0700 (PDT)
(envelope-from kudzu@tenebras.com)
Received: (qmail 27395 invoked from network); 15 Oct 2002 14:10:29 -0000
Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241)
by 0 with SMTP; 15 Oct 2002 14:10:29 -0000
Message-ID: <3DAC21D5.1080006@tenebras.com>
Date: Tue, 15 Oct 2002 07:10:29 -0700
From: Michael Sierchio <kudzu@tenebras.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en, fr-fr, ru
MIME-Version: 1.0
To: Alessandro de Manzano <adm@unixmania.net>
Cc: net@freebsd.org
Subject: Re: which L2TP server ?
References: <20021015141550.A24823@libero.sunshine.ale>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Alessandro de Manzano wrote:
> Hello!
>
> I'm looking for a good L2TP server for FreeBSD, someone knows it ?
>
> If I'm right MPD does not (yet?) support L2TP.
>
>
> Thanks in advance!
>
>
man ng_l2tp
DESCRIPTION
The ng_l2tp node type implements the encapsulation layer of the L2TP pro-
tocol as described in RFC 2661. This includes adding the L2TP packet
header for outgoing packets and verifying and removing it for incoming
packets. The node maintains the L2TP sequence number state and handles
control session packet acknowledgment and retransmission.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 7:17: 6 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 98E9A37B401
for <net@freebsd.org>; Tue, 15 Oct 2002 07:17:05 -0700 (PDT)
Received: from mail.dada.it (mail3.dada.it [195.110.100.3])
by mx1.FreeBSD.org (Postfix) with SMTP id 517DE43EAA
for <net@freebsd.org>; Tue, 15 Oct 2002 07:17:03 -0700 (PDT)
(envelope-from ale@unixmania.net)
Received: (qmail 10065 invoked from network); 15 Oct 2002 14:17:00 -0000
Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252)
by mail.dada.it with SMTP; 15 Oct 2002 14:17:00 -0000
Received: by libero.sunshine.ale (Postfix, from userid 1001)
id 5E393602F; Tue, 15 Oct 2002 16:17:00 +0200 (CEST)
Date: Tue, 15 Oct 2002 16:17:00 +0200
From: Alessandro de Manzano <adm@unixmania.net>
To: Michael Sierchio <kudzu@tenebras.com>
Cc: net@freebsd.org
Subject: Re: which L2TP server ?
Message-ID: <20021015161700.A25444@libero.sunshine.ale>
Reply-To: Alessandro de Manzano <adm@unixmania.net>
References: <20021015141550.A24823@libero.sunshine.ale> <3DAC21D5.1080006@tenebras.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3DAC21D5.1080006@tenebras.com>; from kudzu@tenebras.com on Tue, Oct 15, 2002 at 07:10:29AM -0700
X-Operating-System: FreeBSD 4.7-STABLE
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, Oct 15, 2002 at 07:10:29AM -0700, Michael Sierchio wrote:
> man ng_l2tp
>
> DESCRIPTION
> The ng_l2tp node type implements the encapsulation layer of the L2TP pro-
> tocol as described in RFC 2661. This includes adding the L2TP packet
thanks, but I'm looking for something at higher level, also easier to
setup.
As MPD (actually it use ng_ppp and others), for example.
tnx!
--
bye!
Ale
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 7:32:54 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id E008D37B401
for <freebsd-net@FreeBSD.org>; Tue, 15 Oct 2002 07:32:52 -0700 (PDT)
Received: from 21322530218.direct.eti.at (21322530218.direct.eti.at [213.225.30.218])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8AEA643E91
for <freebsd-net@FreeBSD.org>; Tue, 15 Oct 2002 07:32:46 -0700 (PDT)
(envelope-from tilman@arved.de)
Received: from huckfinn.arved.de (localhost [127.0.0.1])
by 21322530218.direct.eti.at (8.12.5/8.12.5) with ESMTP id g9FEg4UF056609;
Tue, 15 Oct 2002 16:42:04 +0200 (CEST)
(envelope-from tilman@arved.de)
Received: (from tilman@localhost)
by huckfinn.arved.de (8.12.5/8.12.5/Submit) id g9FEg3JT056608;
Tue, 15 Oct 2002 16:42:03 +0200 (CEST)
X-Authentication-Warning: huckfinn.arved.de: tilman set sender to tilman@arved.de using -f
Date: Tue, 15 Oct 2002 16:42:03 +0200
From: Tilman Linneweh <tilman@arved.de>
To: Alessandro de Manzano <adm@unixmania.net>
Cc: freebsd-net@FreeBSD.org
Subject: Re: which L2TP server ?
Message-ID: <20021015144203.GA56390@huckfinn.arved.de>
Reply-To: e0025974@student.tuwien.ac.at
References: <20021015141550.A24823@libero.sunshine.ale> <3DAC21D5.1080006@tenebras.com> <20021015161700.A25444@libero.sunshine.ale>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="1yeeQ81UyVL57Vl7"
Content-Disposition: inline
In-Reply-To: <20021015161700.A25444@libero.sunshine.ale>
User-Agent: Mutt/1.4i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
--1yeeQ81UyVL57Vl7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In arved.freebsd.net, you wrote:
> On Tue, Oct 15, 2002 at 07:10:29AM -0700, Michael Sierchio wrote:
>=20
>> man ng_l2tp
>>=20
>> DESCRIPTION
>> The ng_l2tp node type implements the encapsulation layer of the L2=
TP pro-
>> tocol as described in RFC 2661. This includes adding the L2TP pac=
ket
>=20
> thanks, but I'm looking for something at higher level, also easier to
> setup.
>=20
> As MPD (actually it use ng_ppp and others), for example.
I once compiled the Linux one from www.l2tpd.org (port at
http://stud3.tuwien.ac.at/~e0025974/bsdsrc/l2tpd.shar), but never
tested, if it really worked on FreeBSD.
regards
arved
--1yeeQ81UyVL57Vl7
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)
iD8DBQE9rCk5fCLDn4B6xToRAvK2AJ9uTmJqmL4ILXlrzjdNYwpFgRwnHACfVQGG
7PG2dAf5rGcnCHw9wa0jme4=
=1s6r
-----END PGP SIGNATURE-----
--1yeeQ81UyVL57Vl7--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 9:58:37 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6FAF837B404
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 09:58:36 -0700 (PDT)
Received: from b.smtp-out.sonic.net (b.smtp-out.sonic.net [208.201.224.39])
by mx1.FreeBSD.org (Postfix) with SMTP id 83AC343EAF
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 09:58:34 -0700 (PDT)
(envelope-from gharris@sonic.net)
Received: (qmail 26644 invoked from network); 15 Oct 2002 16:58:34 -0000
Received: from turbo.sonic.net (208.201.224.26)
by b.smtp-out.sonic.net with SMTP; 15 Oct 2002 16:58:34 -0000
Received: from quadrajet.sonic.net (adsl-209-204-185-65.sonic.net [209.204.185.65])
by turbo.sonic.net (8.11.6/8.8.5) with ESMTP id g9FGwXR08989;
Tue, 15 Oct 2002 09:58:33 -0700
X-envelope-info: <gharris@sonic.net>
Received: (from guy@localhost)
by quadrajet.sonic.net (8.9.3/8.9.3) id JAA00393;
Tue, 15 Oct 2002 09:58:32 -0700 (PDT)
(envelope-from gharris)
Date: Tue, 15 Oct 2002 09:58:32 -0700
From: Guy Harris <gharris@sonic.net>
To: Bruce M Simpson <bms@spc.org>,
Harti Brandt <brandt@fokus.gmd.de>,
Craig Rodrigues <rodrigc@attbi.com>, freebsd-net@FreeBSD.ORG
Subject: Re: How to add bpf support to if_atmsubr.c?
Message-ID: <20021015095832.B332@quadrajet.sonic.net>
References: <20021014231305.H332@quadrajet.sonic.net> <20021015105452.GH6089@spc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <20021015105452.GH6089@spc.org>; from bms@spc.org on Tue, Oct 15, 2002 at 11:54:52AM +0100
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, Oct 15, 2002 at 11:54:52AM +0100, Bruce M Simpson wrote:
> This sounds very similar to the promiscuous cell receive option on ENI's
> SpeedStream 5861 router. I found the raw hex cell output was essentially
> a 4 byte ATM UNI header omitting the CRC byte, and the 48 bytes of the raw
> AAL5 cell payload.
Similar, but not the same; I doubt there's any hardware significance to
the VPI/VCI part of the header, and the type field is probably put there
by the driver. (Also, the DLPI interface supplies reassembled AAL5
PDUs, not raw cells; I don't know what it does for other AALs, except
for the signalling AAL where it again supplies reassembled packets.)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 10: 0:13 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 249F437B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 10:00:12 -0700 (PDT)
Received: from a.smtp-out.sonic.net (a.smtp-out.sonic.net [208.201.224.38])
by mx1.FreeBSD.org (Postfix) with SMTP id 72AFD43E75
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 10:00:11 -0700 (PDT)
(envelope-from gharris@sonic.net)
Received: (qmail 31564 invoked from network); 15 Oct 2002 17:00:11 -0000
Received: from turbo.sonic.net (208.201.224.26)
by a.smtp-out.sonic.net with SMTP; 15 Oct 2002 17:00:11 -0000
Received: from quadrajet.sonic.net (adsl-209-204-185-65.sonic.net [209.204.185.65])
by turbo.sonic.net (8.11.6/8.8.5) with ESMTP id g9FH0AR10697;
Tue, 15 Oct 2002 10:00:11 -0700
X-envelope-info: <gharris@sonic.net>
Received: (from guy@localhost)
by quadrajet.sonic.net (8.9.3/8.9.3) id KAA00405;
Tue, 15 Oct 2002 10:00:09 -0700 (PDT)
(envelope-from gharris)
Date: Tue, 15 Oct 2002 10:00:09 -0700
From: Guy Harris <gharris@sonic.net>
To: Harti Brandt <brandt@fokus.gmd.de>
Cc: Bruce M Simpson <bms@spc.org>,
Craig Rodrigues <rodrigc@attbi.com>, freebsd-net@FreeBSD.ORG
Subject: Re: How to add bpf support to if_atmsubr.c?
Message-ID: <20021015100009.C332@quadrajet.sonic.net>
References: <20021015105452.GH6089@spc.org> <20021015125732.K54193-100000@beagle.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <20021015125732.K54193-100000@beagle.fokus.gmd.de>; from brandt@fokus.gmd.de on Tue, Oct 15, 2002 at 01:01:05PM +0200
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, Oct 15, 2002 at 01:01:05PM +0200, Harti Brandt wrote:
> Does Sun still make ATM cards? As far as I remember I saw the last SBUS
> cards a couple of years ago.
They still have a Web page for SunATM:
http://www.sun.com/products-n-solutions/hw/networking/connectivity/sunatm/index.html
and say that they've introduced a 4.0 version of SunATM (which runs in
64-bit mode on Solaris 7) and also list PCI adapters in addition to the
SBus adapters.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 10:10:31 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 85D9437B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 10:10:29 -0700 (PDT)
Received: from isilon.com (isilon.com [65.101.129.58])
by mx1.FreeBSD.org (Postfix) with ESMTP id 14B2243E88
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 10:10:29 -0700 (PDT)
(envelope-from bbaumann@isilon.com)
Received: from localhost (localhost [127.0.0.1])
by isilon.com (8.12.2/8.11.1) with ESMTP id g9FHAR3C077453;
Tue, 15 Oct 2002 10:10:27 -0700 (PDT)
(envelope-from bbaumann@isilon.com)
Date: Tue, 15 Oct 2002 10:10:27 -0700 (PDT)
From: Bill Baumann <bbaumann@isilon.com>
To: e0025974@student.tuwien.ac.at
Cc: Alessandro de Manzano <adm@unixmania.net>,
freebsd-net@FreeBSD.ORG
Subject: Re: which L2TP server ?
In-Reply-To: <20021015144203.GA56390@huckfinn.arved.de>
Message-ID: <Pine.BSF.4.21.0210150959440.75976-100000@isilon.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
A year & a half ago, the l2tpd interface and code was still in its
infancy. If all you seek is to create tunnels/sessions, and don't care
about security or other more complex l2tp issues, it should work ok.
I developed my own L2TP stack for Linux with much higher level of
functionality. It would take some porting effort. Only a small effort
was made on usability, so that could be an issue too.
http://sourceforge.net/projects/l2tp/
I would also suggest going to http://sourceforge.net and search for l2tp.
There are a few other projects out there besides these two.
Regards,
Bill Baumann
On Tue, 15 Oct 2002, Tilman Linneweh wrote:
> In arved.freebsd.net, you wrote:
> > On Tue, Oct 15, 2002 at 07:10:29AM -0700, Michael Sierchio wrote:
> >
> >> man ng_l2tp
> >>
> >> DESCRIPTION
> >> The ng_l2tp node type implements the encapsulation layer of the L2TP pro-
> >> tocol as described in RFC 2661. This includes adding the L2TP packet
> >
> > thanks, but I'm looking for something at higher level, also easier to
> > setup.
> >
> > As MPD (actually it use ng_ppp and others), for example.
>
> I once compiled the Linux one from www.l2tpd.org (port at
> http://stud3.tuwien.ac.at/~e0025974/bsdsrc/l2tpd.shar), but never
> tested, if it really worked on FreeBSD.
>
> regards
> arved
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 12:18:30 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 9235537B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 12:18:29 -0700 (PDT)
Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132])
by mx1.FreeBSD.org (Postfix) with ESMTP id BCC6843EAC
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 12:18:28 -0700 (PDT)
(envelope-from pherman@frenchfries.net)
Received: from mammoth.eat.frenchfries.net (da001d0461.lax-ca.osd.concentric.net [64.0.145.206])
by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g9FIvac07389
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 11:57:38 -0700
Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000)
id 314184A22; Tue, 15 Oct 2002 12:16:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mammoth.eat.frenchfries.net (Postfix) with ESMTP
id 2A8794A20; Tue, 15 Oct 2002 12:16:31 -0700 (PDT)
Date: Tue, 15 Oct 2002 12:16:31 -0700 (PDT)
From: Paul Herman <pherman@frenchfries.net>
X-X-Sender: pherman@mammoth.eat.frenchfries.net
To: Steve Francis <steve@expertcity.com>
Cc: Kirill Ponomarew <ponomarew@oberon.net>,
<freebsd-net@FreeBSD.ORG>
Subject: Re: delayed ACK
In-Reply-To: <3DAAE60E.3010708@expertcity.com>
Message-ID: <20021015115315.U7412-100000@mammoth.eat.frenchfries.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Mon, 14 Oct 2002, Steve Francis wrote:
> Kirill Ponomarew wrote:
> >
> > is it recommended to use net.inet.tcp.delayed_ack=0 on the machines with
> > heavy network traffic ?
> >
> If you want to increase your network traffic for no particular reason,
> and increase load on your server, then yes.
>
> Otherwise no.
Not true. Although some bugs have been fixed in 4.3, FreeBSD's
delayed ACKs will still degrade your performance dramatically in
some cases.
For now, the best advice I could give is to benchmark your client
machine with and without delayed ACKs and see which works best for
your environment.
-Paul.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 12:28:55 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D34EA37B401
for <net@freebsd.org>; Tue, 15 Oct 2002 12:28:54 -0700 (PDT)
Received: from venus.vincentjardin.net (AVelizy-102-1-3-234.abo.wanadoo.fr [217.128.244.234])
by mx1.FreeBSD.org (Postfix) with ESMTP id 39CF643EA3
for <net@freebsd.org>; Tue, 15 Oct 2002 12:28:54 -0700 (PDT)
(envelope-from jardin@venus.vincentjardin.net)
Received: by venus.vincentjardin.net (Postfix, from userid 501)
id A5AF51503A0; Tue, 15 Oct 2002 21:44:44 +0200 (CEST)
Content-Type: text/plain;
charset="iso-8859-1"
From: Vincent Jardin <vjardin@wanadoo.fr>
To: Alessandro de Manzano <adm@unixmania.net>, net@freebsd.org
Subject: Re: which L2TP server ?
Date: Tue, 15 Oct 2002 21:44:44 +0200
X-Mailer: KMail [version 1.3.1]
References: <20021015141550.A24823@libero.sunshine.ale>
In-Reply-To: <20021015141550.A24823@libero.sunshine.ale>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20021015194444.A5AF51503A0@venus.vincentjardin.net>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
There is a new L2TP project from Roaring Penguin. It supports both LAC and
LNS features:
http://sourceforge.net/projects/rp-l2tp
It requires pppd. It has been written for Linux, however it should support
FreeBSD easily.
Vincent
Le Mardi 15 Octobre 2002 14:15, Alessandro de Manzano a écrit :
> Hello!
>
> I'm looking for a good L2TP server for FreeBSD, someone knows it ?
>
> If I'm right MPD does not (yet?) support L2TP.
>
>
> Thanks in advance!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 13: 5:51 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 3EA3637B401
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 13:05:50 -0700 (PDT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
by mx1.FreeBSD.org (Postfix) with ESMTP id AEA0543EB3
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 13:05:49 -0700 (PDT)
(envelope-from don@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19)
id <42S946S8>; Tue, 15 Oct 2002 16:05:44 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022C75@mail.sandvine.com>
From: Don Bowman <don@sandvine.com>
To: "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org>
Subject: dynamic load of em/fxp/bge
Date: Tue, 15 Oct 2002 16:05:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
I am trying to load the if_em, if_fxp, if_bge drivers
via /boot/loader.conf.
I've added
if_fxp_load="YES"
if_bge_load="YES"
if_em_load="YES"
The problem is that the bge driver doesn't load. It will
if I manually load it after startup with kldload. The issue
seems to be a dependency on miibus, both fxp and bge want
to load it, bge gets an error that its already loaded.
I tried putting 'miibus_load="YES"' in loader.conf, but the
same affect is seen.
I've tried from the boot prompt doing an explicit load of these
manually in each order, but to no avail.
As a work-around, I've placed an kldload if_bge in rc.network
before the 'ifconfig -l'.
Any suggestions on why the fxp/bge don't play nice when loaded
automatically, but will work if run manually? Is there a timing
thing that the fxp hasn't initialised its miibus yet?
I have:
fxp0
fxp1
bge0
in this particular machine. The bge will get miibus2 (eventually),
leaving fxp0 to have miibus0, fxp1 to have miibus1 I think.
Suggestions?
--don
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 14: 1: 3 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 320AA37B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 14:01:00 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by mx1.FreeBSD.org (Postfix) with ESMTP id 9FF4543EAC
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 14:00:59 -0700 (PDT)
(envelope-from larse@ISI.EDU)
Received: from isi.edu (nik.isi.edu [128.9.168.58])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9FL0sC05962;
Tue, 15 Oct 2002 14:00:54 -0700 (PDT)
Message-ID: <3DAC8206.1080604@isi.edu>
Date: Tue, 15 Oct 2002 14:00:54 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Paul Herman <pherman@frenchfries.net>
Cc: Steve Francis <steve@expertcity.com>,
Kirill Ponomarew <ponomarew@oberon.net>, freebsd-net@FreeBSD.ORG
Subject: Re: delayed ACK
References: <20021015115315.U7412-100000@mammoth.eat.frenchfries.net>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060106040804030107080102"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a cryptographically signed message in MIME format.
--------------ms060106040804030107080102
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Paul Herman wrote:
>
> Not true. Although some bugs have been fixed in 4.3, FreeBSD's
> delayed ACKs will still degrade your performance dramatically in
> some cases.
I'm sorry, but such statements without a packet trace that exhibits the
problem are just not useful.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms060106040804030107080102
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX
DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD
VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE
aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m
xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac
yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl
oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9
VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO
VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh
DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR
1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw
DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN
MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh
cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK
zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa
SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/
r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK
OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy
CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB
ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM
jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV
s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF
MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTAxNTIxMDA1NFowIwYJKoZIhvcNAQkEMRYEFC1rn5aoAj1/wSqRItGM
x/+ycHV9MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB
naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ
KoZIhvcNAQEBBQAEggEAbPlZAlegWsdWbgki5wmbzpESWHUjADkSxLtxYBY9LwkT0RUeNwvE
fBZ4ChQJMqRhaMOKVpORKuSGpkY1inSqfTVpDhqntsw6qxa6IBh+4gnG+f51csdejHUBHHSN
V9RC7y1CNujmZzxVSlNTbCcIiunYiSg99937UQIciPe2x1cEQsC+WLHK6giSIKGXSm5mSv9G
zzZER0DlJxTo3H+GzBU11Lp+u+yBYvRXiQjxvDraW3rgoBTIpxdXbj6O9/tI7NlF9CfAv8cm
S2nz6i4PvEH4COVHH+xMOrqcsinkOLt97r3KTV0KGMaPT1a/vnrW+983PNYDqizBbywRkiGS
dAAAAAAAAA==
--------------ms060106040804030107080102--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 14:53:22 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 9C46A37B401
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 14:53:21 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7783943E4A
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 14:53:20 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9FLrGYj053179
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 00:53:19 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <065901c27495$56a94c40$8c2a40c1@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: <freebsd-net@freebsd.org>
Subject: ENOBUFS
Date: Wed, 16 Oct 2002 00:53:46 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
My processes writing to SOCK_DGRAM sockets are getting ENOBUFS
while netstat -s counter under the heading of "ip" is incrementing:
7565828 output packets dropped due to no bufs, etc.
but netstat -m shows:
> netstat -m
579/1440/131072 mbufs in use (current/peak/max):
578 mbufs allocated to data
1 mbufs allocated to packet headers
576/970/32768 mbuf clusters in use (current/peak/max)
2300 Kbytes allocated to network (2% of mb_map in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
Where should I start looking? The interface is em
Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 14:59:16 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id C92C237B401
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 14:59:13 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5B6D943E75
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 14:59:13 -0700 (PDT)
(envelope-from larse@ISI.EDU)
Received: from isi.edu (nik.isi.edu [128.9.168.58])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9FLx9C23893;
Tue, 15 Oct 2002 14:59:09 -0700 (PDT)
Message-ID: <3DAC8FAD.30601@isi.edu>
Date: Tue, 15 Oct 2002 14:59:09 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Petri Helenius <pete@he.iki.fi>
Cc: freebsd-net@freebsd.org
Subject: Re: ENOBUFS
References: <065901c27495$56a94c40$8c2a40c1@PHE>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020907070109000802030402"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a cryptographically signed message in MIME format.
--------------ms020907070109000802030402
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Petri Helenius wrote:
> My processes writing to SOCK_DGRAM sockets are getting ENOBUFS
> while netstat -s counter under the heading of "ip" is incrementing:
> 7565828 output packets dropped due to no bufs, etc.
What rate are you sending these packets at? A standard interface queue
length is 50 packets, you get ENOBUFS when it's full.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms020907070109000802030402
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX
DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD
VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE
aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m
xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac
yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl
oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9
VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO
VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh
DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR
1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw
DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN
MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh
cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK
zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa
SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/
r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK
OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy
CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB
ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM
jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV
s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF
MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTAxNTIxNTkwOVowIwYJKoZIhvcNAQkEMRYEFL4QAOq8SEF2HTsTHYE1
qr9bC3D/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB
naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ
KoZIhvcNAQEBBQAEggEAm6hZaSEb6/o7UJav5hj23gTrWFEIjZz48xCHnhcVzTHyTGq+FpHu
+/aHYRJxDWhpCcyp1yZ1xMxQkm+mDuZmFGBBregElXPag6uz2H7+bdcEOZKLMVbK2gbdSuG/
fSqjBFnxRoXBGx8RbwXjeDITyrlaYqNU74laeMHWukuiEI0LWhYUI1e1NUvnh8WR3euNfdkt
aw6xLWTLATvOZ3cJbYEjH/C3iZSUXjVwZNyp53REKdhootraKKNHNS71flLBoocdEmGTkk1p
O2qs2TS//LQiGY7KBmzLSG36D+vwjI2gvEnwznxP/KyuiTwFWapku714ATyOHhtrpurzlYyT
XAAAAAAAAA==
--------------ms020907070109000802030402--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 15:17:30 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id E27BC37B401; Tue, 15 Oct 2002 15:17:18 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
by mx1.FreeBSD.org (Postfix) with ESMTP
id BF67643E6A; Tue, 15 Oct 2002 15:17:17 -0700 (PDT)
(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9FMHDIw060638;
Wed, 16 Oct 2002 00:17:13 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: net@freebsd.org, arch@freebsd.org
Subject: RFC: eliminating the _IP_VHL hack.
From: Poul-Henning Kamp <phk@freebsd.org>
Date: Wed, 16 Oct 2002 00:17:13 +0200
Message-ID: <60637.1034720233@critter.freebsd.dk>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
almost 7 years ago, this commit introduced the _IP_VHL hack in our
IP-stack:
] revision 1.7
] date: 1995/12/21 21:20:27; author: wollman; state: Exp; lines: +5 -1
] If _IP_VHL is defined, declare a single ip_vhl member in struct ip rather
] than separate ip_v and ip_hl members. Should have no effect on current code,
] but I'd eventually like to get rid of those obnoxious bitfields completely.
We can argue a lot about how long time we should wait for "eventually",
but I would say that 7 years is far too long, considering the status:
In the meantime absolutely no code has picked up on this idea, and source
files using the _IP_VHL hack in in the minority in our tree.
The side effect of having some source-files using the _IP_VHL hack and
some not is that sizeof(struct ip) varies from file to file, which at
best is confusing an at worst the source of some really evil bugs.
I would therefore propose to eliminate the _IP_VHL hack from the kernel
to end this state of (potential) confusion, and invite comments to the
following patch:
Index: ip.h
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip.h,v
retrieving revision 1.19
diff -u -r1.19 ip.h
--- ip.h 14 Dec 2001 19:37:32 -0000 1.19
+++ ip.h 15 Oct 2002 22:02:26 -0000
@@ -47,9 +47,6 @@
* Structure of an internet header, naked of options.
*/
struct ip {
-#ifdef _IP_VHL
- u_char ip_vhl; /* version << 4 | header length >> 2 */
-#else
#if BYTE_ORDER == LITTLE_ENDIAN
u_int ip_hl:4, /* header length */
ip_v:4; /* version */
@@ -58,7 +55,6 @@
u_int ip_v:4, /* version */
ip_hl:4; /* header length */
#endif
-#endif /* not _IP_VHL */
u_char ip_tos; /* type of service */
u_short ip_len; /* total length */
u_short ip_id; /* identification */
@@ -72,13 +68,6 @@
u_short ip_sum; /* checksum */
struct in_addr ip_src,ip_dst; /* source and dest address */
};
-
-#ifdef _IP_VHL
-#define IP_MAKE_VHL(v, hl) ((v) << 4 | (hl))
-#define IP_VHL_HL(vhl) ((vhl) & 0x0f)
-#define IP_VHL_V(vhl) ((vhl) >> 4)
-#define IP_VHL_BORING 0x45
-#endif
#define IP_MAXPACKET 65535 /* maximum packet size */
Index: ip_icmp.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v
retrieving revision 1.70
diff -u -r1.70 ip_icmp.c
--- ip_icmp.c 1 Aug 2002 03:53:04 -0000 1.70
+++ ip_icmp.c 15 Oct 2002 22:05:23 -0000
@@ -51,7 +51,6 @@
#include <net/if_types.h>
#include <net/route.h>
-#define _IP_VHL
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/in_var.h>
@@ -128,7 +127,7 @@
struct ifnet *destifp;
{
register struct ip *oip = mtod(n, struct ip *), *nip;
- register unsigned oiplen = IP_VHL_HL(oip->ip_vhl) << 2;
+ register unsigned oiplen = oip->ip_hl << 2;
register struct icmp *icp;
register struct mbuf *m;
unsigned icmplen;
@@ -214,7 +213,8 @@
nip = mtod(m, struct ip *);
bcopy((caddr_t)oip, (caddr_t)nip, sizeof(struct ip));
nip->ip_len = m->m_len;
- nip->ip_vhl = IP_VHL_BORING;
+ nip->ip_v = IPVERSION;
+ nip->ip_hl = 5;
nip->ip_p = IPPROTO_ICMP;
nip->ip_tos = 0;
icmp_reflect(m);
@@ -364,7 +364,7 @@
* Problem with datagram; advise higher level routines.
*/
if (icmplen < ICMP_ADVLENMIN || icmplen < ICMP_ADVLEN(icp) ||
- IP_VHL_HL(icp->icmp_ip.ip_vhl) < (sizeof(struct ip) >> 2)) {
+ icp->icmp_ip.ip_hl < (sizeof(struct ip) >> 2)) {
icmpstat.icps_badlen++;
goto freeit;
}
@@ -526,7 +526,7 @@
if (code > 3)
goto badcode;
if (icmplen < ICMP_ADVLENMIN || icmplen < ICMP_ADVLEN(icp) ||
- IP_VHL_HL(icp->icmp_ip.ip_vhl) < (sizeof(struct ip) >> 2)) {
+ icp->icmp_ip.ip_hl < (sizeof(struct ip) >> 2)) {
icmpstat.icps_badlen++;
break;
}
@@ -593,7 +593,7 @@
struct in_ifaddr *ia;
struct in_addr t;
struct mbuf *opts = 0;
- int optlen = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof(struct ip);
+ int optlen = (ip->ip_hl << 2) - sizeof(struct ip);
struct route *ro = NULL, rt;
if (!in_canforward(ip->ip_src) &&
@@ -703,7 +703,8 @@
* mbuf's data back, and adjust the IP length.
*/
ip->ip_len -= optlen;
- ip->ip_vhl = IP_VHL_BORING;
+ ip->ip_v = IPVERSION;
+ ip->ip_hl = 5;
m->m_len -= optlen;
if (m->m_flags & M_PKTHDR)
m->m_pkthdr.len -= optlen;
@@ -734,7 +735,7 @@
register int hlen;
register struct icmp *icp;
- hlen = IP_VHL_HL(ip->ip_vhl) << 2;
+ hlen = ip->ip_hl << 2;
m->m_data += hlen;
m->m_len -= hlen;
icp = mtod(m, struct icmp *);
Index: ip_icmp.h
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_icmp.h,v
retrieving revision 1.18
diff -u -r1.18 ip_icmp.h
--- ip_icmp.h 19 Mar 2002 21:25:46 -0000 1.18
+++ ip_icmp.h 15 Oct 2002 22:02:52 -0000
@@ -123,13 +123,8 @@
#define ICMP_TSLEN (8 + 3 * sizeof (n_time)) /* timestamp */
#define ICMP_MASKLEN 12 /* address mask */
#define ICMP_ADVLENMIN (8 + sizeof (struct ip) + 8) /* min */
-#ifndef _IP_VHL
#define ICMP_ADVLEN(p) (8 + ((p)->icmp_ip.ip_hl << 2) + 8)
/* N.B.: must separately check that ip_hl >= 5 */
-#else
-#define ICMP_ADVLEN(p) (8 + (IP_VHL_HL((p)->icmp_ip.ip_vhl) << 2) + 8)
- /* N.B.: must separately check that header length >= 5 */
-#endif
/*
* Definition of type and code field values.
Index: ip_input.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.211
diff -u -r1.211 ip_input.c
--- ip_input.c 10 Oct 2002 12:03:36 -0000 1.211
+++ ip_input.c 15 Oct 2002 22:02:57 -0000
@@ -34,8 +34,6 @@
* $FreeBSD: src/sys/netinet/ip_input.c,v 1.211 2002/10/10 12:03:36 maxim Exp $
*/
-#define _IP_VHL
-
#include "opt_bootp.h"
#include "opt_ipfw.h"
#include "opt_ipdn.h"
@@ -324,7 +322,7 @@
if (args.rule) { /* dummynet already filtered us */
ip = mtod(m, struct ip *);
- hlen = IP_VHL_HL(ip->ip_vhl) << 2;
+ hlen = ip->ip_hl << 2;
goto iphack ;
}
@@ -340,12 +338,12 @@
}
ip = mtod(m, struct ip *);
- if (IP_VHL_V(ip->ip_vhl) != IPVERSION) {
+ if (ip->ip_v != IPVERSION) {
ipstat.ips_badvers++;
goto bad;
}
- hlen = IP_VHL_HL(ip->ip_vhl) << 2;
+ hlen = ip->ip_hl << 2;
if (hlen < sizeof(struct ip)) { /* minimum header length */
ipstat.ips_badhlen++;
goto bad;
@@ -755,7 +753,7 @@
ipstat.ips_reassembled++;
ip = mtod(m, struct ip *);
/* Get the header length of the reassembled packet */
- hlen = IP_VHL_HL(ip->ip_vhl) << 2;
+ hlen = ip->ip_hl << 2;
#ifdef IPDIVERT
/* Restore original checksum before diverting packet */
if (divert_info != 0) {
@@ -882,7 +880,7 @@
struct ip *ip = mtod(m, struct ip *);
register struct mbuf *p, *q, *nq;
struct mbuf *t;
- int hlen = IP_VHL_HL(ip->ip_vhl) << 2;
+ int hlen = ip->ip_hl << 2;
int i, next;
/*
@@ -1020,7 +1018,7 @@
*/
q = fp->ipq_frags;
ip = GETIP(q);
- if (next + (IP_VHL_HL(ip->ip_vhl) << 2) > IP_MAXPACKET) {
+ if (next + (ip->ip_hl << 2) > IP_MAXPACKET) {
ipstat.ips_toolong++;
ip_freef(head, fp);
return (0);
@@ -1068,8 +1066,8 @@
nipq--;
(void) m_free(dtom(fp));
ip_nfragpackets--;
- m->m_len += (IP_VHL_HL(ip->ip_vhl) << 2);
- m->m_data -= (IP_VHL_HL(ip->ip_vhl) << 2);
+ m->m_len += (ip->ip_hl << 2);
+ m->m_data -= (ip->ip_hl << 2);
/* some debugging cruft by sklower, below, will go away soon */
if (m->m_flags & M_PKTHDR) /* XXX this should be done elsewhere */
m_fixhdr(m);
@@ -1193,7 +1191,7 @@
dst = ip->ip_dst;
cp = (u_char *)(ip + 1);
- cnt = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof (struct ip);
+ cnt = (ip->ip_hl << 2) - sizeof (struct ip);
for (; cnt > 0; cnt -= optlen, cp += optlen) {
opt = cp[IPOPT_OPTVAL];
if (opt == IPOPT_EOL)
@@ -1582,14 +1580,15 @@
register caddr_t opts;
int olen;
- olen = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof (struct ip);
+ olen = (ip->ip_hl << 2) - sizeof (struct ip);
opts = (caddr_t)(ip + 1);
i = m->m_len - (sizeof (struct ip) + olen);
bcopy(opts + olen, opts, (unsigned)i);
m->m_len -= olen;
if (m->m_flags & M_PKTHDR)
m->m_pkthdr.len -= olen;
- ip->ip_vhl = IP_MAKE_VHL(IPVERSION, sizeof(struct ip) >> 2);
+ ip->ip_v = IPVERSION;
+ ip->ip_hl = sizeof(struct ip) >> 2;
}
u_char inetctlerrmap[PRC_NCMDS] = {
@@ -1686,7 +1685,7 @@
MGET(mcopy, M_DONTWAIT, m->m_type);
if (mcopy != NULL) {
M_COPY_PKTHDR(mcopy, m);
- mcopy->m_len = imin((IP_VHL_HL(ip->ip_vhl) << 2) + 8,
+ mcopy->m_len = imin((ip->ip_hl << 2) + 8,
(int)ip->ip_len);
m_copydata(m, 0, mcopy->m_len, mtod(mcopy, caddr_t));
#ifdef MAC
Index: ip_output.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.165
diff -u -r1.165 ip_output.c
--- ip_output.c 23 Sep 2002 08:56:24 -0000 1.165
+++ ip_output.c 15 Oct 2002 22:03:41 -0000
@@ -34,8 +34,6 @@
* $FreeBSD: src/sys/netinet/ip_output.c,v 1.165 2002/09/23 08:56:24 maxim Exp $
*/
-#define _IP_VHL
-
#include "opt_ipfw.h"
#include "opt_ipdn.h"
#include "opt_ipdivert.h"
@@ -191,7 +189,7 @@
#endif
if (args.rule != NULL) { /* dummynet already saw us */
ip = mtod(m, struct ip *);
- hlen = IP_VHL_HL(ip->ip_vhl) << 2 ;
+ hlen = ip->ip_hl << 2 ;
if (ro->ro_rt)
ia = ifatoia(ro->ro_rt->rt_ifa);
goto sendit;
@@ -210,7 +208,8 @@
* Fill in IP header.
*/
if ((flags & (IP_FORWARDING|IP_RAWOUTPUT)) == 0) {
- ip->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2);
+ ip->ip_v = IPVERSION;
+ ip->ip_hl = hlen >> 2;
ip->ip_off &= IP_DF;
#ifdef RANDOM_IP_ID
ip->ip_id = ip_randomid();
@@ -219,7 +218,7 @@
#endif
ipstat.ips_localout++;
} else {
- hlen = IP_VHL_HL(ip->ip_vhl) << 2;
+ hlen = ip->ip_hl << 2;
}
dst = (struct sockaddr_in *)&ro->ro_dst;
@@ -553,11 +552,7 @@
/* be sure to update variables that are affected by ipsec4_output() */
ip = mtod(m, struct ip *);
-#ifdef _IP_VHL
- hlen = IP_VHL_HL(ip->ip_vhl) << 2;
-#else
hlen = ip->ip_hl << 2;
-#endif
if (ro->ro_rt == NULL) {
if ((flags & IP_ROUTETOIF) == 0) {
printf("ip_output: "
@@ -862,13 +857,8 @@
ip->ip_len = htons(ip->ip_len);
ip->ip_off = htons(ip->ip_off);
ip->ip_sum = 0;
- if (sw_csum & CSUM_DELAY_IP) {
- if (ip->ip_vhl == IP_VHL_BORING) {
- ip->ip_sum = in_cksum_hdr(ip);
- } else {
- ip->ip_sum = in_cksum(m, hlen);
- }
- }
+ if (sw_csum & CSUM_DELAY_IP)
+ ip->ip_sum = in_cksum(m, hlen);
/* Record statistics for this interface address. */
if (!(flags & IP_FORWARDING) && ia) {
@@ -988,7 +978,8 @@
*mhip = *ip;
if (hlen > sizeof (struct ip)) {
mhlen = ip_optcopy(ip, mhip) + sizeof (struct ip);
- mhip->ip_vhl = IP_MAKE_VHL(IPVERSION, mhlen >> 2);
+ mhip->ip_v = IPVERSION;
+ mhip->ip_hl = mhlen >> 2;
}
m->m_len = mhlen;
mhip->ip_off = ((off - hlen) >> 3) + ip->ip_off;
@@ -1012,13 +1003,8 @@
m->m_pkthdr.csum_flags = m0->m_pkthdr.csum_flags;
mhip->ip_off = htons(mhip->ip_off);
mhip->ip_sum = 0;
- if (sw_csum & CSUM_DELAY_IP) {
- if (mhip->ip_vhl == IP_VHL_BORING) {
- mhip->ip_sum = in_cksum_hdr(mhip);
- } else {
- mhip->ip_sum = in_cksum(m, mhlen);
- }
- }
+ if (sw_csum & CSUM_DELAY_IP)
+ mhip->ip_sum = in_cksum(m, mhlen);
*mnext = m;
mnext = &m->m_nextpkt;
nfrags++;
@@ -1041,13 +1027,8 @@
ip->ip_off |= IP_MF;
ip->ip_off = htons(ip->ip_off);
ip->ip_sum = 0;
- if (sw_csum & CSUM_DELAY_IP) {
- if (ip->ip_vhl == IP_VHL_BORING) {
- ip->ip_sum = in_cksum_hdr(ip);
- } else {
- ip->ip_sum = in_cksum(m, hlen);
- }
- }
+ if (sw_csum & CSUM_DELAY_IP)
+ ip->ip_sum = in_cksum(m, hlen);
sendorfree:
for (m = m0; m; m = m0) {
m0 = m->m_nextpkt;
@@ -1097,7 +1078,7 @@
u_short csum, offset;
ip = mtod(m, struct ip *);
- offset = IP_VHL_HL(ip->ip_vhl) << 2 ;
+ offset = ip->ip_hl << 2 ;
csum = in_cksum_skip(m, ip->ip_len, offset);
if (m->m_pkthdr.csum_flags & CSUM_UDP && csum == 0)
csum = 0xffff;
@@ -1169,7 +1150,8 @@
ip = mtod(m, struct ip *);
bcopy(p->ipopt_list, ip + 1, optlen);
*phlen = sizeof(struct ip) + optlen;
- ip->ip_vhl = IP_MAKE_VHL(IPVERSION, *phlen >> 2);
+ ip->ip_v = IPVERSION;
+ ip->ip_hl = *phlen >> 2;
ip->ip_len += optlen;
return (m);
}
@@ -1187,7 +1169,7 @@
cp = (u_char *)(ip + 1);
dp = (u_char *)(jp + 1);
- cnt = (IP_VHL_HL(ip->ip_vhl) << 2) - sizeof (struct ip);
+ cnt = (ip->ip_hl << 2) - sizeof (struct ip);
for (; cnt > 0; cnt -= optlen, cp += optlen) {
opt = cp[0];
if (opt == IPOPT_EOL)
@@ -2025,11 +2007,7 @@
ip->ip_len = htons(ip->ip_len);
ip->ip_off = htons(ip->ip_off);
ip->ip_sum = 0;
- if (ip->ip_vhl == IP_VHL_BORING) {
- ip->ip_sum = in_cksum_hdr(ip);
- } else {
- ip->ip_sum = in_cksum(copym, hlen);
- }
+ ip->ip_sum = in_cksum(copym, hlen);
/*
* NB:
* It's not clear whether there are any lingering
Index: raw_ip.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.100
diff -u -r1.100 raw_ip.c
--- raw_ip.c 15 Aug 2002 18:51:26 -0000 1.100
+++ raw_ip.c 15 Oct 2002 22:06:09 -0000
@@ -59,7 +59,6 @@
#include <net/if.h>
#include <net/route.h>
-#define _IP_VHL
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/in_pcb.h>
@@ -263,10 +262,10 @@
ip = mtod(m, struct ip *);
/* don't allow both user specified and setsockopt options,
and don't allow packet length sizes that will crash */
- if (((IP_VHL_HL(ip->ip_vhl) != (sizeof (*ip) >> 2))
+ if (((ip->ip_hl != (sizeof (*ip) >> 2))
&& inp->inp_options)
|| (ip->ip_len > m->m_pkthdr.len)
- || (ip->ip_len < (IP_VHL_HL(ip->ip_vhl) << 2))) {
+ || (ip->ip_len < (ip->ip_hl << 2))) {
m_freem(m);
return EINVAL;
}
Index: tcp_subr.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/tcp_subr.c,v
retrieving revision 1.143
diff -u -r1.143 tcp_subr.c
--- tcp_subr.c 10 Oct 2002 21:41:30 -0000 1.143
+++ tcp_subr.c 15 Oct 2002 22:06:27 -0000
@@ -62,7 +62,6 @@
#include <net/route.h>
#include <net/if.h>
-#define _IP_VHL
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
@@ -284,7 +283,8 @@
{
struct ip *ip = (struct ip *) ip_ptr;
- ip->ip_vhl = IP_VHL_BORING;
+ ip->ip_v = IPVERSION;
+ ip->ip_hl = 5;
ip->ip_tos = 0;
ip->ip_len = 0;
ip->ip_id = 0;
@@ -371,7 +371,7 @@
KASSERT(tp != NULL || m != NULL, ("tcp_respond: tp and m both NULL"));
#ifdef INET6
- isipv6 = IP_VHL_V(((struct ip *)ipgen)->ip_vhl) == 6;
+ isipv6 = ((struct ip *)ipgen)->ip_v == 6;
ip6 = ipgen;
#endif /* INET6 */
ip = ipgen;
@@ -1102,7 +1102,7 @@
if (ip) {
s = splnet();
th = (struct tcphdr *)((caddr_t)ip
- + (IP_VHL_HL(ip->ip_vhl) << 2));
+ + (ip->ip_hl << 2));
INP_INFO_WLOCK(&tcbinfo);
inp = in_pcblookup_hash(&tcbinfo, faddr, th->th_dport,
ip->ip_src, th->th_sport, 0, NULL);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 15:20:12 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id E992337B401
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 15:20:10 -0700 (PDT)
Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63])
by mx1.FreeBSD.org (Postfix) with ESMTP id 688F343E6E
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 15:20:10 -0700 (PDT)
(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org ([12.232.206.8])
by sccrmhc03.attbi.com
(InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
id <20021015222009.PLAG24958.sccrmhc03.attbi.com@InterJet.elischer.org>;
Tue, 15 Oct 2002 22:20:09 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA81728;
Tue, 15 Oct 2002 15:18:03 -0700 (PDT)
Date: Tue, 15 Oct 2002 15:18:02 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: Petri Helenius <pete@he.iki.fi>
Cc: freebsd-net@freebsd.org
Subject: Re: ENOBUFS
In-Reply-To: <065901c27495$56a94c40$8c2a40c1@PHE>
Message-ID: <Pine.BSF.4.21.0210151517010.81042-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, 16 Oct 2002, Petri Helenius wrote:
>
> My processes writing to SOCK_DGRAM sockets are getting ENOBUFS
> while netstat -s counter under the heading of "ip" is incrementing:
> 7565828 output packets dropped due to no bufs, etc.
> but netstat -m shows:
my guess is that the interface has no more room in it's output queue..
when you get the error, back off a bit..
> > netstat -m
> 579/1440/131072 mbufs in use (current/peak/max):
> 578 mbufs allocated to data
> 1 mbufs allocated to packet headers
> 576/970/32768 mbuf clusters in use (current/peak/max)
> 2300 Kbytes allocated to network (2% of mb_map in use)
> 0 requests for memory denied
> 0 requests for memory delayed
> 0 calls to protocol drain routines
>
> Where should I start looking? The interface is em
>
> Pete
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 15:26:25 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id BB40237B401; Tue, 15 Oct 2002 15:26:24 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 59F4D43E6A; Tue, 15 Oct 2002 15:26:24 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9FMQOpJ027014;
Tue, 15 Oct 2002 15:26:24 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9FMQOAH027013;
Tue, 15 Oct 2002 15:26:24 -0700 (PDT)
(envelope-from rizzo)
Date: Tue, 15 Oct 2002 15:26:24 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Poul-Henning Kamp <phk@FreeBSD.ORG>
Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG
Subject: Re: RFC: eliminating the _IP_VHL hack.
Message-ID: <20021015152624.A26977@carp.icir.org>
References: <60637.1034720233@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <60637.1034720233@critter.freebsd.dk>; from phk@FreeBSD.ORG on Wed, Oct 16, 2002 at 12:17:13AM +0200
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, Oct 16, 2002 at 12:17:13AM +0200, Poul-Henning Kamp wrote:
...
> I would therefore propose to eliminate the _IP_VHL hack from the kernel
yes, go for it.
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 15:46:40 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id F3DC237B401; Tue, 15 Oct 2002 15:46:38 -0700 (PDT)
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 1CB8D43E65; Tue, 15 Oct 2002 15:46:38 -0700 (PDT)
(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1])
by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g9FMkagQ007724
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK);
Tue, 15 Oct 2002 18:46:37 -0400 (EDT)
(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id g9FMka0o007721;
Tue, 15 Oct 2002 18:46:36 -0400 (EDT)
(envelope-from wollman)
Date: Tue, 15 Oct 2002 18:46:36 -0400 (EDT)
From: Garrett Wollman <wollman@lcs.mit.edu>
Message-Id: <200210152246.g9FMka0o007721@khavrinen.lcs.mit.edu>
To: Poul-Henning Kamp <phk@FreeBSD.ORG>
Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG
Subject: RFC: eliminating the _IP_VHL hack.
In-Reply-To: <60637.1034720233@critter.freebsd.dk>
References: <60637.1034720233@critter.freebsd.dk>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
<<On Wed, 16 Oct 2002 00:17:13 +0200, Poul-Henning Kamp <phk@FreeBSD.ORG> said:
> In the meantime absolutely no code has picked up on this idea,
It was copied in spirit from OSF/1.
> The side effect of having some source-files using the _IP_VHL hack and
> some not is that sizeof(struct ip) varies from file to file,
Not so. Any compiler which allocates different amounts of storage to
one eight-bit member versus two four-bit bitfield members is seriously
broken (and would defeat the whole purpose).
> I would therefore propose to eliminate the _IP_VHL hack from the kernel
> to end this state of (potential) confusion, and invite comments to the
> following patch:
Much better to delete the bogus BYTE_ORDER kluge from ip.h. (Note
that the definition of the bitfields in question has nothing
whatsoever to do with the actual byte order in use; it simply relies
on the historical behavior of compilers which allocated space for
bitfields in BYTE_ORDER order.)
-GAWollman
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 15:47:48 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 8B11437B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 15:47:47 -0700 (PDT)
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
by mx1.FreeBSD.org (Postfix) with ESMTP id DEAB943E4A
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 15:47:46 -0700 (PDT)
(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1])
by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g9FMlkgQ007751
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK);
Tue, 15 Oct 2002 18:47:46 -0400 (EDT)
(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id g9FMlkH7007748;
Tue, 15 Oct 2002 18:47:46 -0400 (EDT)
(envelope-from wollman)
Date: Tue, 15 Oct 2002 18:47:46 -0400 (EDT)
From: Garrett Wollman <wollman@lcs.mit.edu>
Message-Id: <200210152247.g9FMlkH7007748@khavrinen.lcs.mit.edu>
To: "Petri Helenius" <pete@he.iki.fi>
Cc: <freebsd-net@FreeBSD.ORG>
Subject: ENOBUFS
In-Reply-To: <065901c27495$56a94c40$8c2a40c1@PHE>
References: <065901c27495$56a94c40$8c2a40c1@PHE>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
<<On Wed, 16 Oct 2002 00:53:46 +0300, "Petri Helenius" <pete@he.iki.fi> said:
> My processes writing to SOCK_DGRAM sockets are getting ENOBUFS
Probably means that your outgoing interface queue is filling up.
ENOBUFS is the only way the kernel has to tell you ``slow down!''.
-GAWollman
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 15:56:57 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6725337B401
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 15:56:56 -0700 (PDT)
Received: from 66-162-33-178.gen.twtelecom.net (66-162-33-178.gen.twtelecom.net [66.162.33.178])
by mx1.FreeBSD.org (Postfix) with ESMTP id 1E21243E4A
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 15:56:56 -0700 (PDT)
(envelope-from steve@expertcity.com)
Received: from [10.4.2.41] (helo=expertcity.com)
by 66-162-33-178.gen.twtelecom.net with esmtp (Exim 3.22 #4)
id 181acR-0005fG-00; Tue, 15 Oct 2002 15:56:55 -0700
Message-ID: <3DAC9D37.7060701@expertcity.com>
Date: Tue, 15 Oct 2002 15:56:55 -0700
From: Steve Francis <steve@expertcity.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Lars Eggert <larse@ISI.EDU>
Cc: Paul Herman <pherman@frenchfries.net>,
Kirill Ponomarew <ponomarew@oberon.net>, freebsd-net@FreeBSD.ORG
Subject: Re: delayed ACK
References: <3DAC8206.1080604@isi.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Lars Eggert wrote:
>Paul Herman wrote:
>
>
>>Not true. Although some bugs have been fixed in 4.3, FreeBSD's
>>delayed ACKs will still degrade your performance dramatically in
>>some cases.
>>
>>
>
>I'm sorry, but such statements without a packet trace that exhibits the
>problem are just not useful.
>
>Lars
>
>
He's probably referring to poorly behaved windows clients, on certain
applications, if you leave net.inet.tcp.slowstart_flightsize at default.
Incidentally, why are not the defaults on
net.inet.tcp.slowstart_flightsize higher?
RFC2414 seems to indicate it should be higher. Solaris in version 8 and
later default to 4 for this value.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 16: 0:27 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id AB84837B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 16:00:24 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by mx1.FreeBSD.org (Postfix) with ESMTP id 35F5E43E6E
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 16:00:24 -0700 (PDT)
(envelope-from larse@ISI.EDU)
Received: from isi.edu (nik.isi.edu [128.9.168.58])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9FN0JC03935;
Tue, 15 Oct 2002 16:00:19 -0700 (PDT)
Message-ID: <3DAC9E03.5070402@isi.edu>
Date: Tue, 15 Oct 2002 16:00:19 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Steve Francis <steve@expertcity.com>
Cc: Paul Herman <pherman@frenchfries.net>,
Kirill Ponomarew <ponomarew@oberon.net>, freebsd-net@FreeBSD.ORG
Subject: Re: delayed ACK
References: <3DAC8206.1080604@isi.edu> <3DAC9D37.7060701@expertcity.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060205080205030005080508"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a cryptographically signed message in MIME format.
--------------ms060205080205030005080508
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Steve Francis wrote:
>>
> He's probably referring to poorly behaved windows clients, on certain
> applications, if you leave net.inet.tcp.slowstart_flightsize at default.
Ah. Well, that's a Windows problem :-)
> Incidentally, why are not the defaults on
> net.inet.tcp.slowstart_flightsize higher?
> RFC2414 seems to indicate it should be higher. Solaris in version 8 and
> later default to 4 for this value.
I've been running with 4 for years w/o problems. so i'm all for the change.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms060205080205030005080508
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX
DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD
VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE
aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m
xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac
yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl
oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9
VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO
VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh
DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR
1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw
DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN
MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh
cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK
zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa
SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/
r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK
OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy
CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB
ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM
jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV
s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF
MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTAxNTIzMDAxOVowIwYJKoZIhvcNAQkEMRYEFCX1IPVur/V/WozpDM2v
RpK+gexmMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB
naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ
KoZIhvcNAQEBBQAEggEAJObheHHNLZYLyEJrOobZDVVvzMVReQHZ5yx1gFyLnsYq73SBNwmt
nftn5/RjDo2D6NfwH5PUQ0jALOTxWN3jeE9S40aKDn65ALNKpaJPG1wpNFZgu3jf+GdiGpEU
JE3EPbSJbRYRgk0TRADrhATsQWLHSivyVyf6Xa3q4KkWLGX2E4tHGMr/3x1niEo7d28BPfl4
7+TPvHea/SSybEfh7E6tkNQar12vC7s+r2PbEmdj93u0EXVoaHr95VR7CZozvMJMjA72Z3Nj
PLL6F3pA7xaAusxFeoNPA3ycu/E8bMFvwtufIiwhLszIDm7vvXMOQRIUP/7R7VIE//8phB9F
ggAAAAAAAA==
--------------ms060205080205030005080508--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 16: 3:58 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id EBB9F37B401
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 16:03:56 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id 15C8243E65
for <freebsd-net@freebsd.org>; Tue, 15 Oct 2002 16:03:56 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9FN3pYj053715;
Wed, 16 Oct 2002 02:03:55 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <068b01c2749f$32e7cf70$8c2a40c1@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Lars Eggert" <larse@ISI.EDU>
Cc: <freebsd-net@freebsd.org>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu>
Subject: Re: ENOBUFS
Date: Wed, 16 Oct 2002 02:04:11 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>
> What rate are you sending these packets at? A standard interface queue
> length is 50 packets, you get ENOBUFS when it's full.
>
This might explain the phenomenan. (packets are going out bursty, with average
hovering at ~500Mbps:ish) I recomplied kernel with IFQ_MAXLEN of 5000
but there seems to be no change in the behaviour. How do I make sure that
em-interface is running 66/64 and is there a way to see interface queue depth?
em0: <Intel(R) PRO/1000 Network Connection, Version - 1.3.14> port 0x3040-0x307f
mem 0xfc220000-0xfc23ffff irq 17 at device 3.0 on pci2
em0: Speed:1000 Mbps Duplex:Full
pcib2: <PCI to PCI bridge (vendor=8086 device=1460)> at device 29.0 on pci1
IOAPIC #2 intpin 0 -> irq 16
IOAPIC #2 intpin 6 -> irq 17
IOAPIC #2 intpin 7 -> irq 18
pci2: <PCI bus> on pcib2
The OS is 4.7-RELEASE.
Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 16: 8:16 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 418F837B404
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 16:08:15 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4B72043E4A
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 16:08:14 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9FN8CYj053735;
Wed, 16 Oct 2002 02:08:13 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <06bb01c2749f$ce73e8c0$8c2a40c1@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Garrett Wollman" <wollman@lcs.mit.edu>
Cc: <freebsd-net@FreeBSD.ORG>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <200210152247.g9FMlkH7007748@khavrinen.lcs.mit.edu>
Subject: Re: ENOBUFS
Date: Wed, 16 Oct 2002 02:08:42 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>
> Probably means that your outgoing interface queue is filling up.
> ENOBUFS is the only way the kernel has to tell you ``slow down!''.
>
How much should I be able to send to two em interfaces on one
66/64 PCI ?
Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 16:10:57 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 80F0437B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 16:10:56 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id 2A48443E7B
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 16:10:56 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9FNAupJ027482;
Tue, 15 Oct 2002 16:10:56 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9FNAtmQ027481;
Tue, 15 Oct 2002 16:10:55 -0700 (PDT)
(envelope-from rizzo)
Date: Tue, 15 Oct 2002 16:10:55 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Petri Helenius <pete@he.iki.fi>
Cc: Lars Eggert <larse@ISI.EDU>, freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021015161055.A27443@carp.icir.org>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <068b01c2749f$32e7cf70$8c2a40c1@PHE>; from pete@he.iki.fi on Wed, Oct 16, 2002 at 02:04:11AM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, Oct 16, 2002 at 02:04:11AM +0300, Petri Helenius wrote:
> >
> > What rate are you sending these packets at? A standard interface queue
> > length is 50 packets, you get ENOBUFS when it's full.
> >
> This might explain the phenomenan. (packets are going out bursty, with average
> hovering at ~500Mbps:ish) I recomplied kernel with IFQ_MAXLEN of 5000
> but there seems to be no change in the behaviour. How do I make sure that
how large are the packets and how fast is the box ?
on a fast box you should be able to generate packets faster than wire
speed for sizes around 500bytes, meaning that you are going to saturate
the queue no matter how large it is.
cheers
luigi
> em-interface is running 66/64 and is there a way to see interface queue depth?
> em0: <Intel(R) PRO/1000 Network Connection, Version - 1.3.14> port 0x3040-0x307f
> mem 0xfc220000-0xfc23ffff irq 17 at device 3.0 on pci2
> em0: Speed:1000 Mbps Duplex:Full
> pcib2: <PCI to PCI bridge (vendor=8086 device=1460)> at device 29.0 on pci1
> IOAPIC #2 intpin 0 -> irq 16
> IOAPIC #2 intpin 6 -> irq 17
> IOAPIC #2 intpin 7 -> irq 18
> pci2: <PCI bus> on pcib2
>
> The OS is 4.7-RELEASE.
>
> Pete
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 16:15:31 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5DCA637B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 16:15:28 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by mx1.FreeBSD.org (Postfix) with ESMTP id DCC9843E6E
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 16:15:27 -0700 (PDT)
(envelope-from larse@ISI.EDU)
Received: from isi.edu (nik.isi.edu [128.9.168.58])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9FNFMC13950;
Tue, 15 Oct 2002 16:15:22 -0700 (PDT)
Message-ID: <3DACA189.4030107@isi.edu>
Date: Tue, 15 Oct 2002 16:15:21 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Petri Helenius <pete@he.iki.fi>
Cc: Garrett Wollman <wollman@lcs.mit.edu>, freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
References: <065901c27495$56a94c40$8c2a40c1@PHE> <200210152247.g9FMlkH7007748@khavrinen.lcs.mit.edu> <06bb01c2749f$ce73e8c0$8c2a40c1@PHE>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050706080208040209060404"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a cryptographically signed message in MIME format.
--------------ms050706080208040209060404
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Petri Helenius wrote:
>>Probably means that your outgoing interface queue is filling up.
>>ENOBUFS is the only way the kernel has to tell you ``slow down!''.
>>
>
> How much should I be able to send to two em interfaces on one
> 66/64 PCI ?
I've seen netperf UDP throughputs of ~950Mpbs with a fiber em card and
4K datagrams on a 2.4Ghz P4.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms050706080208040209060404
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX
DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD
VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE
aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m
xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac
yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl
oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9
VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO
VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh
DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR
1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw
DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN
MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh
cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK
zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa
SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/
r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK
OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy
CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB
ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM
jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV
s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF
MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTAxNTIzMTUyMVowIwYJKoZIhvcNAQkEMRYEFO8H3vbRhFb8XK+SenMv
KNDD8JTWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB
naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ
KoZIhvcNAQEBBQAEggEAPbwyR/9sFFgnzT0709cBnyKrOsxHYwDYP6lcpzxV7kHEd0Q4Z+EO
Flws+DkDvPtXRyvxW3dc8LfH5otaALNlo2iKr+ExwjLeKTnZfFhvhmfWHZ1PYY9I/qwKNaYk
2+fNEYhlHNjcqsdftnMlw54XLM5O9mF4Jk9ObJYxCG+v3t4mzXmDp9uzfYLwUJ4MMbnDdCrF
x4L02z7MjTR+HNZ0Qfn/JslirHLHcfQtlGt4J483UEEV+NQOafWGLmJiyzTZccs4CtUhMXKD
dmOr1nqJxdxSpn+YDBdP08W1FKWYz7t8g1iXYOBFy3VQAtpgVt3TA/A2uOXRxGwNptAvobmb
gwAAAAAAAA==
--------------ms050706080208040209060404--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 16:22:57 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D28B637B404
for <net@freebsd.org>; Tue, 15 Oct 2002 16:22:55 -0700 (PDT)
Received: from rootlabs.com (root.org [67.118.192.226])
by mx1.FreeBSD.org (Postfix) with SMTP id 00DA143E6A
for <net@freebsd.org>; Tue, 15 Oct 2002 16:22:55 -0700 (PDT)
(envelope-from nate@rootlabs.com)
Received: (qmail 37692 invoked by uid 1000); 15 Oct 2002 23:22:56 -0000
Date: Tue, 15 Oct 2002 16:22:56 -0700 (PDT)
From: Nate Lawson <nate@root.org>
To: Poul-Henning Kamp <phk@freebsd.org>
Cc: net@freebsd.org, arch@freebsd.org
Subject: Re: RFC: eliminating the _IP_VHL hack.
In-Reply-To: <60637.1034720233@critter.freebsd.dk>
Message-ID: <Pine.BSF.4.21.0210151614240.37181-100000@root.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, 16 Oct 2002, Poul-Henning Kamp wrote:
> almost 7 years ago, this commit introduced the _IP_VHL hack in our
> IP-stack:
>
> ] revision 1.7
> ] date: 1995/12/21 21:20:27; author: wollman; state: Exp; lines: +5 -1
> ] If _IP_VHL is defined, declare a single ip_vhl member in struct ip rather
> ] than separate ip_v and ip_hl members. Should have no effect on current code,
> ] but I'd eventually like to get rid of those obnoxious bitfields completely.
>
> We can argue a lot about how long time we should wait for "eventually",
> but I would say that 7 years is far too long, considering the status:
Fine by me.
> RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v
> retrieving revision 1.70
> diff -u -r1.70 ip_icmp.c
> --- ip_icmp.c 1 Aug 2002 03:53:04 -0000 1.70
> +++ ip_icmp.c 15 Oct 2002 22:05:23 -0000
> @@ -51,7 +51,6 @@
> #include <net/if_types.h>
> #include <net/route.h>
>
> -#define _IP_VHL
> #include <netinet/in.h>
> #include <netinet/in_systm.h>
> #include <netinet/in_var.h>
> @@ -128,7 +127,7 @@
> struct ifnet *destifp;
> {
> register struct ip *oip = mtod(n, struct ip *), *nip;
> - register unsigned oiplen = IP_VHL_HL(oip->ip_vhl) << 2;
> + register unsigned oiplen = oip->ip_hl << 2;
> register struct icmp *icp;
> register struct mbuf *m;
> unsigned icmplen;
> @@ -214,7 +213,8 @@
> nip = mtod(m, struct ip *);
> bcopy((caddr_t)oip, (caddr_t)nip, sizeof(struct ip));
> nip->ip_len = m->m_len;
> - nip->ip_vhl = IP_VHL_BORING;
> + nip->ip_v = IPVERSION;
> + nip->ip_hl = 5;
I think there is a manifest constant for the default ipv4 header size but
can't remember it right now.
-Nate
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 18:17:58 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6A06C37B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 18:17:57 -0700 (PDT)
Received: from mail.deltanet.com (mail.deltanet.com [216.237.144.132])
by mx1.FreeBSD.org (Postfix) with ESMTP id F284543E77
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 18:17:56 -0700 (PDT)
(envelope-from pherman@frenchfries.net)
Received: from mammoth.eat.frenchfries.net (da001d0174.lax-ca.osd.concentric.net [64.0.144.175])
by mail.deltanet.com (8.11.6/8.11.6) with ESMTP id g9G065c04297
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 17:06:06 -0700
Received: by mammoth.eat.frenchfries.net (Postfix, from userid 1000)
id E22644A22; Tue, 15 Oct 2002 17:25:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mammoth.eat.frenchfries.net (Postfix) with ESMTP
id DE3764A20; Tue, 15 Oct 2002 17:25:42 -0700 (PDT)
Date: Tue, 15 Oct 2002 17:25:42 -0700 (PDT)
From: Paul Herman <pherman@frenchfries.net>
X-X-Sender: pherman@mammoth.eat.frenchfries.net
To: Lars Eggert <larse@ISI.EDU>
Cc: Steve Francis <steve@expertcity.com>,
Kirill Ponomarew <ponomarew@oberon.net>, <freebsd-net@FreeBSD.ORG>
Subject: Re: delayed ACK
In-Reply-To: <3DAC8206.1080604@isi.edu>
Message-ID: <20021015162359.B8363-100000@mammoth.eat.frenchfries.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, 15 Oct 2002, Lars Eggert wrote:
> Paul Herman wrote:
> >
> > Not true. Although some bugs have been fixed in 4.3, FreeBSD's
> > delayed ACKs will still degrade your performance dramatically in
> > some cases.
>
> I'm sorry, but such statements without a packet trace that exhibits the
> problem are just not useful.
</me reels line back in>
Aha! Another victim who is willing to take a look at this! :-)
It's an issue that was left unresolved in kern/24645. Bruce Evans
brought this to my attention back during the unrelated "I have
delayed ACK problems" thread on -net in January of 2001 and I then
passed it on to jlemon. If you need a packet trace, let me know,
but you should be able to reproduce it yourself. Even today on my
4.7-PRERELEASE I still get:
mammoth# sysctl net.inet.tcp.delayed_ack=0
net.inet.tcp.delayed_ack: 1 -> 0
mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel
0.000u 0.041s 0:00.33 12.1% 350+300k 0+0io 0pf+0w
mammoth# sysctl net.inet.tcp.delayed_ack=1
net.inet.tcp.delayed_ack: 0 -> 1
mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel
0.014u 0.033s 0:45.90 0.0% 700+600k 0+0io 0pf+0w
^^^^^^^
It seems that lowering lo0 mtu to 1500 makes this particular
problem go away. The magic mtu size is 2100. This makes me think
that this is a big problem across GigE using 8K jumbo frames, not
sure. Also, taring over the IPv6 lo0 interface seems to work OK.
No idea what causes this.
-Paul.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 18:22:56 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id C635437B401; Tue, 15 Oct 2002 18:22:54 -0700 (PDT)
Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 819B643E7B; Tue, 15 Oct 2002 18:22:54 -0700 (PDT)
(envelope-from hsu@FreeBSD.org)
Received: from FreeBSD.org ([63.193.112.125])
by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001))
with ESMTP id <0H41001UMVU5KX@mta5.snfc21.pbi.net>; Tue,
15 Oct 2002 18:22:54 -0700 (PDT)
Date: Tue, 15 Oct 2002 18:23:22 -0700
From: Jeffrey Hsu <hsu@FreeBSD.org>
Subject: Re: RFC: eliminating the _IP_VHL hack.
In-reply-to: Message from Poul-Henning Kamp <phk@freebsd.org>
"of Wed, 16 Oct 2002 00:17:13 +0200." <60637.1034720233@critter.freebsd.dk>
To: Poul-Henning Kamp <phk@freebsd.org>
Cc: net@freebsd.org, arch@freebsd.org
Message-id: <0H41001UNVU5KX@mta5.snfc21.pbi.net>
MIME-version: 1.0
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> The side effect of having some source-files using the _IP_VHL hack and
> some not is that sizeof(struct ip) varies from file to file, which at
> best is confusing an at worst the source of some really evil bugs.
> I would therefore propose to eliminate the _IP_VHL hack from the kernel
> to end this state of (potential) confusion
This problem could be solved more easily by changing the u_int back
to an u_char, as it used to be before rev 1.15:
Index: ip.h
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip.h,v
retrieving revision 1.19
diff -u -r1.19 ip.h
--- ip.h 14 Dec 2001 19:37:32 -0000 1.19
+++ ip.h 16 Oct 2002 01:15:48 -0000
@@ -51,11 +51,11 @@
u_char ip_vhl; /* version << 4 | header length >> 2 */
#else
#if BYTE_ORDER == LITTLE_ENDIAN
- u_int ip_hl:4, /* header length */
+ u_char ip_hl:4, /* header length */
ip_v:4; /* version */
#endif
#if BYTE_ORDER == BIG_ENDIAN
- u_int ip_v:4, /* version */
+ u_char ip_v:4, /* version */
ip_hl:4; /* header length */
#endif
#endif /* not _IP_VHL */
But, if we were to pick one or the other to discard, I would keep the
IP_VHL because that field really is a byte in the IP header
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 18:30:48 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id ABB1F37B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 18:30:46 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4F0E343E7B
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 18:30:46 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9G1UipJ029135;
Tue, 15 Oct 2002 18:30:44 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9G1Ui2C029134;
Tue, 15 Oct 2002 18:30:44 -0700 (PDT)
(envelope-from rizzo)
Date: Tue, 15 Oct 2002 18:30:44 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Paul Herman <pherman@frenchfries.net>
Cc: Lars Eggert <larse@ISI.EDU>,
Steve Francis <steve@expertcity.com>,
Kirill Ponomarew <ponomarew@oberon.net>, freebsd-net@FreeBSD.ORG
Subject: Re: delayed ACK
Message-ID: <20021015183044.A29061@carp.icir.org>
References: <3DAC8206.1080604@isi.edu> <20021015162359.B8363-100000@mammoth.eat.frenchfries.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021015162359.B8363-100000@mammoth.eat.frenchfries.net>; from pherman@frenchfries.net on Tue, Oct 15, 2002 at 05:25:42PM -0700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
this smells a lot as a bad interaction between default window
size and mtu -- loopback has 16k default, maybe tar uses a
smallish window (32k is default now for net.inet.tcp.sendspace,
but used to be 16k at the time), which means only 1 or 2 packets in
flight at once, meaning that many times you get the 200ms delay
and your throughput goes way down.
cheers
luigi
On Tue, Oct 15, 2002 at 05:25:42PM -0700, Paul Herman wrote:
...
> Aha! Another victim who is willing to take a look at this! :-)
>
> It's an issue that was left unresolved in kern/24645. Bruce Evans
> brought this to my attention back during the unrelated "I have
> delayed ACK problems" thread on -net in January of 2001 and I then
> passed it on to jlemon. If you need a packet trace, let me know,
> but you should be able to reproduce it yourself. Even today on my
> 4.7-PRERELEASE I still get:
>
> mammoth# sysctl net.inet.tcp.delayed_ack=0
> net.inet.tcp.delayed_ack: 1 -> 0
> mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel
> 0.000u 0.041s 0:00.33 12.1% 350+300k 0+0io 0pf+0w
>
> mammoth# sysctl net.inet.tcp.delayed_ack=1
> net.inet.tcp.delayed_ack: 0 -> 1
> mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel
> 0.014u 0.033s 0:45.90 0.0% 700+600k 0+0io 0pf+0w
> ^^^^^^^
>
> It seems that lowering lo0 mtu to 1500 makes this particular
> problem go away. The magic mtu size is 2100. This makes me think
> that this is a big problem across GigE using 8K jumbo frames, not
> sure. Also, taring over the IPv6 lo0 interface seems to work OK.
>
> No idea what causes this.
>
> -Paul.
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 18:48:28 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id C84AC37B404
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 18:48:23 -0700 (PDT)
Received: from out1.mx.nwbl.wi.voyager.net (out1.mx.nwbl.wi.voyager.net [169.207.3.119])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5F5AD43E88
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 18:48:23 -0700 (PDT)
(envelope-from silby@silby.com)
Received: from [10.1.1.6] (d163.as28.nwbl0.wi.voyager.net [169.207.71.229])
by out1.mx.nwbl.wi.voyager.net (Postfix) with ESMTP
id BEE25E3FC2; Tue, 15 Oct 2002 20:48:02 -0500 (CDT)
Date: Tue, 15 Oct 2002 20:52:49 -0500 (CDT)
From: Mike Silbersack <silby@silby.com>
To: Luigi Rizzo <rizzo@icir.org>
Cc: Paul Herman <pherman@frenchfries.net>,
Lars Eggert <larse@ISI.EDU>, Steve Francis <steve@expertcity.com>,
Kirill Ponomarew <ponomarew@oberon.net>, <freebsd-net@FreeBSD.ORG>
Subject: Re: delayed ACK
In-Reply-To: <20021015183044.A29061@carp.icir.org>
Message-ID: <20021015204614.L21041-100000@patrocles.silby.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, 15 Oct 2002, Luigi Rizzo wrote:
> this smells a lot as a bad interaction between default window
> size and mtu -- loopback has 16k default, maybe tar uses a
> smallish window (32k is default now for net.inet.tcp.sendspace,
> but used to be 16k at the time), which means only 1 or 2 packets in
> flight at once, meaning that many times you get the 200ms delay
> and your throughput goes way down.
>
> cheers
> luigi
NetBSD introduced a "fix" for this recently, it seems sorta hackish, but
maybe we need to do something similar.
The diff reminds me why FreeBSD has a policy of seperating style and
functional commits, fwiw. :)
http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/netinet/tcp_output.c.diff?r1=1.84&r2=1.85
Revision 1.85 / (download) - annotate - [select for diffs], Tue Aug 20
16:29:42 2002 UTC (8 weeks ago) by thorpej
Branch: MAIN
CVS Tags: gehenna-devsw-base
Changes since 1.84: +18 -4 lines
Diff to previous 1.84 (colored)
Never send more than half a socket buffer of data. This insures that
we can always keep 2 packets on the wire, no matter what SO_SNDBUF is,
and therefore ACKs will never be delayed unless we run out of data to
transmit. The problem is quite easy to tickle when the MTU of the
outgoing interface is larger than the socket buffer size (e.g. loopback).
Fix from Charles Hannum.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 18:53:44 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 14D9B37B408
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 18:53:43 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id E4EF043E9E
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 18:53:39 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9G1rcpJ029422;
Tue, 15 Oct 2002 18:53:38 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9G1rcj6029421;
Tue, 15 Oct 2002 18:53:38 -0700 (PDT)
(envelope-from rizzo)
Date: Tue, 15 Oct 2002 18:53:38 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Mike Silbersack <silby@silby.com>
Cc: Paul Herman <pherman@frenchfries.net>,
Lars Eggert <larse@ISI.EDU>, Steve Francis <steve@expertcity.com>,
Kirill Ponomarew <ponomarew@oberon.net>, freebsd-net@FreeBSD.ORG
Subject: Re: delayed ACK
Message-ID: <20021015185338.A29388@carp.icir.org>
References: <20021015183044.A29061@carp.icir.org> <20021015204614.L21041-100000@patrocles.silby.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021015204614.L21041-100000@patrocles.silby.com>; from silby@silby.com on Tue, Oct 15, 2002 at 08:52:49PM -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, Oct 15, 2002 at 08:52:49PM -0500, Mike Silbersack wrote:
...
> NetBSD introduced a "fix" for this recently, it seems sorta hackish, but
> maybe we need to do something similar.
this helps you if the other side has delayed acks, but halves the
throughput if you are being window limited and the other side does not
use delayed acks (can you force immediate acks by setting the PUSH flag
in the tcp header ?)
cheers
luigi
>
> http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/netinet/tcp_output.c.diff?r1=1.84&r2=1.85
>
> Revision 1.85 / (download) - annotate - [select for diffs], Tue Aug 20
> 16:29:42 2002 UTC (8 weeks ago) by thorpej
> Branch: MAIN
> CVS Tags: gehenna-devsw-base
> Changes since 1.84: +18 -4 lines
> Diff to previous 1.84 (colored)
>
> Never send more than half a socket buffer of data. This insures that
> we can always keep 2 packets on the wire, no matter what SO_SNDBUF is,
> and therefore ACKs will never be delayed unless we run out of data to
> transmit. The problem is quite easy to tickle when the MTU of the
> outgoing interface is larger than the socket buffer size (e.g. loopback).
>
> Fix from Charles Hannum.
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 20:31:49 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id AF3DA37B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 20:31:47 -0700 (PDT)
Received: from out5.mx.nwbl.wi.voyager.net (out5.mx.nwbl.wi.voyager.net [169.207.3.123])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4370043E91
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 20:31:47 -0700 (PDT)
(envelope-from silby@silby.com)
Received: from [10.1.1.6] (d163.as28.nwbl0.wi.voyager.net [169.207.71.229])
by out5.mx.nwbl.wi.voyager.net (Postfix) with ESMTP
id E596DC6D1A; Tue, 15 Oct 2002 22:31:44 -0500 (CDT)
Date: Tue, 15 Oct 2002 22:36:32 -0500 (CDT)
From: Mike Silbersack <silby@silby.com>
To: Luigi Rizzo <rizzo@icir.org>
Cc: Paul Herman <pherman@frenchfries.net>,
Lars Eggert <larse@ISI.EDU>, Steve Francis <steve@expertcity.com>,
Kirill Ponomarew <ponomarew@oberon.net>, <freebsd-net@FreeBSD.ORG>
Subject: Re: delayed ACK
In-Reply-To: <20021015185338.A29388@carp.icir.org>
Message-ID: <20021015222156.F21041-100000@patrocles.silby.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, 15 Oct 2002, Luigi Rizzo wrote:
> On Tue, Oct 15, 2002 at 08:52:49PM -0500, Mike Silbersack wrote:
> ...
> > NetBSD introduced a "fix" for this recently, it seems sorta hackish, but
> > maybe we need to do something similar.
>
> this helps you if the other side has delayed acks, but halves the
> throughput if you are being window limited and the other side does not
> use delayed acks (can you force immediate acks by setting the PUSH flag
> in the tcp header ?)
>
> cheers
> luigi
I think the comment is slightly misleading, and that it won't actually
cause any performance problems as you suggest.
From what I recall, immediate acking of PUSH packets varies... Linux
appears to have changed back and forth on whether it does so or not. I
also seem to recall Windows making a change too. Either way, we probably
shouldn't rely on that behavior alone.
> > Never send more than half a socket buffer of data. This insures that
> > we can always keep 2 packets on the wire, no matter what SO_SNDBUF is,
> > and therefore ACKs will never be delayed unless we run out of data to
> > transmit. The problem is quite easy to tickle when the MTU of the
> > outgoing interface is larger than the socket buffer size (e.g. loopback).
If I'm reading the implementation correctly, what this means is that if
you have a single packet > .5*socketbuffer, you reduce the maximum
*segment* size, causing two smaller packets to be sent instead of one
large packet. (Smaller still being 8K in size.)
While such a change might help with localhost, I have this sneaky
suspicion that it falls apart when applied to jumbo frames and 32K send
buffers. Someone well motivated should be able to come up with a more
general heuristic.
Mike "Silby" Silbersack
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 22:56:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5F0A837B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 22:56:57 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id 08F2843E77
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 22:56:56 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9G5unYj056127;
Wed, 16 Oct 2002 08:56:54 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <06c901c274d8$e5280b80$8c2a40c1@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Luigi Rizzo" <rizzo@icir.org>
Cc: "Lars Eggert" <larse@ISI.EDU>, <freebsd-net@FreeBSD.ORG>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org>
Subject: Re: ENOBUFS
Date: Wed, 16 Oct 2002 08:57:19 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>
> how large are the packets and how fast is the box ?
Packets go out at an average size of 1024 bytes. The box is dual
P4 Xeon 2400/400 so I think it should qualify as "fast" ? I disabled
hyperthreading to figure out if it was causing problems. I seem to
be able to send packets at a rate in the 900Mbps when just sending
them out with a process. If I do similar sending on two interfaces at
same time, it tops out at 600Mbps.
The information I´m looking for is how to instrument where the
bottleneck is to either tune the parameters or report a bug in PCI or
em code. (or just simply swap the GE hardware to something that
works better)
Pete
> on a fast box you should be able to generate packets faster than wire
> speed for sizes around 500bytes, meaning that you are going to saturate
> the queue no matter how large it is.
>
> cheers
> luigi
>
> > em-interface is running 66/64 and is there a way to see interface queue
depth?
> > em0: <Intel(R) PRO/1000 Network Connection, Version - 1.3.14> port
0x3040-0x307f
> > mem 0xfc220000-0xfc23ffff irq 17 at device 3.0 on pci2
> > em0: Speed:1000 Mbps Duplex:Full
> > pcib2: <PCI to PCI bridge (vendor=8086 device=1460)> at device 29.0 on pci1
> > IOAPIC #2 intpin 0 -> irq 16
> > IOAPIC #2 intpin 6 -> irq 17
> > IOAPIC #2 intpin 7 -> irq 18
> > pci2: <PCI bus> on pcib2
> >
> > The OS is 4.7-RELEASE.
> >
> > Pete
> >
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 23: 5:36 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id DACB337B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 23:05:33 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5C45543E75
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 23:05:33 -0700 (PDT)
(envelope-from larse@ISI.EDU)
Received: from isi.edu (c-24-130-112-157.we.client2.attbi.com [24.130.112.157])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9G65UC18513;
Tue, 15 Oct 2002 23:05:30 -0700 (PDT)
Message-ID: <3DAD01A7.3020807@isi.edu>
Date: Tue, 15 Oct 2002 23:05:27 -0700
From: Lars Eggert <larse@ISI.EDU>
Organization: USC Information Sciences Institute
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Petri Helenius <pete@he.iki.fi>
Cc: Luigi Rizzo <rizzo@icir.org>, freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040303050100000105070307"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a cryptographically signed message in MIME format.
--------------ms040303050100000105070307
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Petri Helenius wrote:
>>how large are the packets and how fast is the box ?
>
>
> Packets go out at an average size of 1024 bytes. The box is dual
> P4 Xeon 2400/400 so I think it should qualify as "fast" ? I disabled
> hyperthreading to figure out if it was causing problems. I seem to
> be able to send packets at a rate in the 900Mbps when just sending
> them out with a process. If I do similar sending on two interfaces at
> same time, it tops out at 600Mbps.
The 900Mbps are similar to what I see here on similar hardware.
For your two-interface setup, are the 600Mbps aggregate send rate on
both interfaces, or do you see 600Mbps per interface? In the latter
case, is your CPU maxed out? Only one can be in the kernel under
-stable, so the second one won't help much. With small packets like
that, you may be interrupt-bound. (Until Luigi releases polling for em
interfaces... :-)
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms040303050100000105070307
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX
DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD
VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE
aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m
xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac
yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl
oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9
VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO
VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh
DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR
1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw
DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN
MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh
cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK
zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa
SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/
r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK
OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy
CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB
ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM
jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV
s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF
MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTAxNjA2MDUyN1owIwYJKoZIhvcNAQkEMRYEFO6Ne28+iM5256TSEwNx
DpvH8TxvMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB
naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ
KoZIhvcNAQEBBQAEggEACFCOwDT/U6KEjz/8B0lcL2e6ps4RpfjK+Hl0NrDpnh5yAsMexPNE
O5N54Z4f24OoBFvahERHiOxFkZoqrZURZMjVISgvBnymc9njzrXQDCyRS1lXUI7+iPJs8PlH
8xgUU4Fr1WVS9P8m6IvU9oh1GcMyFzsbqrwyG4Abw4ZQXzU/dCPculzyh+VOvkIEP0gNtTgM
pDow5QkttKYs7+pRVaP9lQIMqk8tjcuJLF/Zoao+G6roMgVw7B11QsyKodx6s4+XyThJt1WW
uDtE+AjLaDQ7BUsAlSXskhix3kdyJ+tRdelzDyb/KgYsp2v6WqteXO2GAiH3zu24ZsoppaTs
DwAAAAAAAA==
--------------ms040303050100000105070307--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 23:13:10 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6D05237B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 23:13:08 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7E9C543E75
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 23:13:07 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9G6CpYj056250;
Wed, 16 Oct 2002 09:13:06 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <071501c274db$222c3ea0$8c2a40c1@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Lars Eggert" <larse@ISI.EDU>
Cc: "Luigi Rizzo" <rizzo@icir.org>, <freebsd-net@FreeBSD.ORG>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu>
Subject: Re: ENOBUFS
Date: Wed, 16 Oct 2002 09:13:20 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> The 900Mbps are similar to what I see here on similar hardware.
What kind of receive performance do you observe? I haven´t got that
far yet.
>
> For your two-interface setup, are the 600Mbps aggregate send rate on
> both interfaces, or do you see 600Mbps per interface? In the latter
600Mbps per interface. I´m going to try this out also on -CURRENT
to see if it changes anything. Interrupts do not seem to pose a big
problem because I´m seeing only a few thousand em interrupts
a second but since every packet involves a write call there are >100k
syscalls a second.
> case, is your CPU maxed out? Only one can be in the kernel under
> -stable, so the second one won't help much. With small packets like
> that, you may be interrupt-bound. (Until Luigi releases polling for em
> interfaces... :-)
>
I´ll try changing the packet sizes to figure out optimum.
Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 23:27: 5 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5242F37B401
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 23:27:02 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by mx1.FreeBSD.org (Postfix) with ESMTP id C392A43E7B
for <freebsd-net@FreeBSD.ORG>; Tue, 15 Oct 2002 23:27:01 -0700 (PDT)
(envelope-from larse@ISI.EDU)
Received: from isi.edu (c-24-130-112-157.we.client2.attbi.com [24.130.112.157])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9G6QwC27173;
Tue, 15 Oct 2002 23:26:58 -0700 (PDT)
Message-ID: <3DAD06AF.7060701@isi.edu>
Date: Tue, 15 Oct 2002 23:26:55 -0700
From: Lars Eggert <larse@ISI.EDU>
Organization: USC Information Sciences Institute
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Petri Helenius <pete@he.iki.fi>
Cc: Luigi Rizzo <rizzo@icir.org>, freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030403000307050700010406"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a cryptographically signed message in MIME format.
--------------ms030403000307050700010406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Petri Helenius wrote:
>>The 900Mbps are similar to what I see here on similar hardware.
>
> What kind of receive performance do you observe? I haven´t got that
> far yet.
Less :-) Let me tell you tomorrow, don't have the numbers here right now.
> 600Mbps per interface. I´m going to try this out also on -CURRENT
> to see if it changes anything. Interrupts do not seem to pose a big
> problem because I´m seeing only a few thousand em interrupts
> a second but since every packet involves a write call there are >100k
> syscalls a second.
So maybe syscalls/second are the bottleneck. On -current, try enabling
zero copy sockets, it seems to help somewhat. Other than that, I've not
found -current to be much different in terms of performance.
If you're just interested in maxing throughput, try sending over TCP
with large write sizes. In that case, syscall overhead is less, since
you amortize it over multiple packets. (But there are different issues
that can limit TCP throughput.)
> I´ll try changing the packet sizes to figure out optimum.
I think I remember that 4K packets were fastest with the em hardware in
our case.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms030403000307050700010406
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX
DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD
VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE
aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m
xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac
yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl
oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9
VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO
VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh
DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR
1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw
DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN
MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh
cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK
zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa
SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/
r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK
OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy
CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB
ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM
jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV
s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF
MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTAxNjA2MjY1NlowIwYJKoZIhvcNAQkEMRYEFD36vhZZkvEWWBaPtx6C
bYmG5FwGMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB
naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ
KoZIhvcNAQEBBQAEggEAgb7brqshaM0ANtPz5lLGDYZfzjnHLv+UyQGn5mnFpmQnL9YDMfiL
xJnhfFT+nzIo9s5r+pE/c/InovmCyVvlPxNeQw8kGi98e4KAGMcvaEfdOrcS8R3+7Tjgeqoj
TPXWtEe/fjXVdQj/GfYh7/sNEc5QZLhjuYV5KBymAeqAWNSLTaVjrI5T4YinqmMC3JpyqUf0
AqR0Kq3BK6QAZ62pUZs3AqIGcTXCIyxvT0C7aYDHWMBrd05G6L5J5qdp1u24dctNZRjA/VNp
+zk29jttkZ1p+7M8/BouAnL2C9e9lq55lanlear9HRpMyvcLR4oX/zPjfnV3U3r5vaPL6MNs
IQAAAAAAAA==
--------------ms030403000307050700010406--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue Oct 15 23:39:49 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 04E3137B401; Tue, 15 Oct 2002 23:39:48 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 278AC43E6E; Tue, 15 Oct 2002 23:39:47 -0700 (PDT)
(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9G6deIw051939;
Wed, 16 Oct 2002 08:39:41 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: Garrett Wollman <wollman@lcs.mit.edu>
Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG
Subject: Re: RFC: eliminating the _IP_VHL hack.
In-Reply-To: Your message of "Tue, 15 Oct 2002 18:46:36 EDT."
<200210152246.g9FMka0o007721@khavrinen.lcs.mit.edu>
Date: Wed, 16 Oct 2002 08:39:40 +0200
Message-ID: <51938.1034750380@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
In message <200210152246.g9FMka0o007721@khavrinen.lcs.mit.edu>, Garrett Wollman
writes:
>Much better to delete the bogus BYTE_ORDER kluge from ip.h. (Note
>that the definition of the bitfields in question has nothing
>whatsoever to do with the actual byte order in use; it simply relies
>on the historical behavior of compilers which allocated space for
>bitfields in BYTE_ORDER order.)
Do you intend to complete the task you originally started ?
What is your plan for 3rd party software ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 0:52:55 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 03A5437B401; Wed, 16 Oct 2002 00:52:53 -0700 (PDT)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 6747B43EAF; Wed, 16 Oct 2002 00:52:51 -0700 (PDT)
(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA05653;
Wed, 16 Oct 2002 17:52:48 +1000
Date: Wed, 16 Oct 2002 18:03:24 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Jeffrey Hsu <hsu@FreeBSD.ORG>
Cc: Poul-Henning Kamp <phk@FreeBSD.ORG>, <net@FreeBSD.ORG>,
<arch@FreeBSD.ORG>
Subject: Re: RFC: eliminating the _IP_VHL hack.
In-Reply-To: <0H41001UNVU5KX@mta5.snfc21.pbi.net>
Message-ID: <20021016172019.W4358-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Tue, 15 Oct 2002, Jeffrey Hsu wrote:
> > The side effect of having some source-files using the _IP_VHL hack and
> > some not is that sizeof(struct ip) varies from file to file, which at
> > best is confusing an at worst the source of some really evil bugs.
There is no such effect, or ip would not work. Bitfields are inherently
unportable, but here everything is carefully packed so that there is a
good chance that both versions give the same struct layout for all
non-broken compilers (the layout needs to be compiler-independent too).
> > I would therefore propose to eliminate the _IP_VHL hack from the kernel
> > to end this state of (potential) confusion
This would remove the least unportable version.
> This problem could be solved more easily by changing the u_int back
> to an u_char, as it used to be before rev 1.15:
>
> Index: ip.h
> ===================================================================
> RCS file: /home/ncvs/src/sys/netinet/ip.h,v
> retrieving revision 1.19
> diff -u -r1.19 ip.h
> --- ip.h 14 Dec 2001 19:37:32 -0000 1.19
> +++ ip.h 16 Oct 2002 01:15:48 -0000
> @@ -51,11 +51,11 @@
> u_char ip_vhl; /* version << 4 | header length >> 2 */
> #else
> #if BYTE_ORDER == LITTLE_ENDIAN
> - u_int ip_hl:4, /* header length */
> + u_char ip_hl:4, /* header length */
> ip_v:4; /* version */
> #endif
> #if BYTE_ORDER == BIG_ENDIAN
> - u_int ip_v:4, /* version */
> + u_char ip_v:4, /* version */
> ip_hl:4; /* header length */
> #endif
> #endif /* not _IP_VHL */
>
> But, if we were to pick one or the other to discard, I would keep the
> IP_VHL because that field really is a byte in the IP header
This would just guarantee unportable behaviour by untranslating from C.
C compilers reject bit-fields that are declared to have u_char, since
u_char is not a permitted type for a bit-field. E.g., from the C99
draft n869.txt:
6.7.2.1 Language 6.7.2.1
WG14/N869 Committee Draft -- January 18, 1999 115
[#8] A bit-field shall have a type that is a qualified or
unqualified version of _Bool, signed int, or unsigned int.
...
Little is lost by restricting the type of a bitfield in this way, since
the width of a bitfield can be determined without lokking at its type.
Bit-fields that are declared to have types other than the standard
types for them are a poorly documented gcc extension. The type of a
bit-field has little or no affect on packing of bits near the bitfield,
at least if everything is packed manually. However, the types of
bit-fields within a struct affects padding at the end of a struct in
a (usually) less than useful way: if a standard standard type is used,
then structs get padded if necessary to give alignment of that type.
E.g., on i386's the following structs have size 4 although you probably
want them to have size 1:
struct foo1 { int bar: 1; };
struct foo2 { int bar: 8; };
TenDRA is bug-for-bug compatible with gcc here.
This can be worked around if the compiler is gcc by declaring the
struct as __packed (__aligned(1) doesn't seem to work), or by declaring
the bit-field type as char, or on some systems by using -mno-bit-align.
These workarounds are even more unportable than bit-fields. However,
there is no problem with struct ip yet, because everything is manually
packed to work with "all" C compilers on "all" systems. This will
break on systems with 64-bit ints, since sizeof(struct ip) == 20 is
not a multiple of 8.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 1:16:55 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 4FA1737B401; Wed, 16 Oct 2002 01:16:54 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 81E3C43E77; Wed, 16 Oct 2002 01:16:53 -0700 (PDT)
(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9G8GeIw069414;
Wed, 16 Oct 2002 10:16:47 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: Bruce Evans <bde@zeta.org.au>
Cc: Jeffrey Hsu <hsu@FreeBSD.ORG>, net@FreeBSD.ORG, arch@FreeBSD.ORG
Subject: Re: RFC: eliminating the _IP_VHL hack.
In-Reply-To: Your message of "Wed, 16 Oct 2002 18:03:24 +1000."
<20021016172019.W4358-100000@gamplex.bde.org>
Date: Wed, 16 Oct 2002 10:16:40 +0200
Message-ID: <69413.1034756200@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
In message <20021016172019.W4358-100000@gamplex.bde.org>, Bruce Evans writes:
>On Tue, 15 Oct 2002, Jeffrey Hsu wrote:
>
>> > The side effect of having some source-files using the _IP_VHL hack and
>> > some not is that sizeof(struct ip) varies from file to file, which at
>> > best is confusing an at worst the source of some really evil bugs.
>
>There is no such effect, or ip would not work.
s/,/ with our current compilers and architectures,/
>> > I would therefore propose to eliminate the _IP_VHL hack from the kernel
>> > to end this state of (potential) confusion
>
>This would remove the least unportable version.
Could be, but there is no point in us having two different versions,
neither of which is guaranteed to be portable, in particular when
one of the two is private to FreeBSD and not even consistently used
there.
For reference:
NetBSD hasn't got the _IP_VHL but has a __packed__ on the
structure.
OpenBSD hasn't got the _IP_VHL either, but hasn't adopted
the __packed__ from NetBSD.
Linux also uses bitfields and endianess #ifdefs.
>These workarounds are even more unportable than bit-fields. However,
>there is no problem with struct ip yet, because everything is manually
>packed to work with "all" C compilers on "all" systems. This will
>break on systems with 64-bit ints, since sizeof(struct ip) == 20 is
>not a multiple of 8.
Good point.
I'll ammend my proposal to include a __packed__ and a CTASSERT on
the size of struct ip == 20.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 2:31: 0 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6A8D937B401
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 02:30:57 -0700 (PDT)
Received: from chung.yikes.com (dsl-65-184-72-125.telocity.com [65.184.72.125])
by mx1.FreeBSD.org (Postfix) with ESMTP id ABDCE43EAC
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 02:30:56 -0700 (PDT)
(envelope-from leonardc@cs.berkeley.edu)
Received: from feather ([10.0.1.250])
by chung.yikes.com (8.12.3/8.11.6) with SMTP id g9G9Uods035690;
Wed, 16 Oct 2002 02:30:51 -0700 (PDT)
(envelope-from leonardc@cs.berkeley.edu)
From: "Leonard Chung" <leonardc@cs.berkeley.edu>
To: "Archie Cobbs" <archie@dellroad.org>
Cc: <freebsd-net@FreeBSD.ORG>
Subject: RE: MPD PPTP tunneling intermittantly fails
Date: Wed, 16 Oct 2002 02:30:50 -0700
Message-ID: <AEEMJFAIHDPJNCAKCHHBIEJBCHAA.leonardc@cs.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <200210142144.g9ELi3AT084595@arch20m.dellroad.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
I'm just using Windows clients, so there are no OS X clients.
Here's the ngctl output:
chung# ngctl msg ng0:inet.ppp.link0 getstats
Rec'd response "getstats" (3) from "ng0:inet.ppp.link0":
Args: { xmitPackets=1967 xmitOctets=209321 xmitLoneAcks=395 xmitDrops=345
recvPackets=1590 recvOctets=248518 recvAckTimeouts=55 }
As you can tell, the connection hasn't transmitted much data before it's
already become problematic. The drop count to packet count on transmits and
timeouts on recv's seems awfully high given everything is just on a local
area network. Here's my physical topology:
Inside 10.0.0.0/8 <--------> {10.0.0.1 - MPD Machine - 192.168.0.1}
<-------> 192.168.0.0/24 Protected clients
|
| Outside Internet
IP
->
Each net address on the MPD machine has its own Ethernet card. In addition,
pinging the MPD machine from either side results in no packet loss and <1ms
latency.
Here's some more information if that helps:
chung# kldstat
Id Refs Address Size Name
1 10 0xc0100000 2bce78 kernel
2 9 0xc0b71000 9000 netgraph.ko
3 1 0xc0b7a000 3000 ng_socket.ko
4 1 0xc0b7d000 3000 ng_iface.ko
5 1 0xc0b80000 6000 ng_ppp.ko
6 1 0xc0b86000 4000 ng_bpf.ko
7 1 0xc0b8a000 4000 ng_vjc.ko
8 1 0xc0b8e000 4000 ng_pptpgre.ko
9 1 0xc0b93000 4000 ng_ksocket.ko
10 1 0xc0b98000 3000 ng_mppc.ko
chung# uname -a
FreeBSD chung.yikes.com 4.6.2-RELEASE FreeBSD 4.6.2-RELEASE #0: Wed Aug 28
00:07:12 PDT 2002
leonard@chung.yikes.com:/usr/obj/usr/src/sys/CHUNG_KERN_FW i386
Thanks for your help,
Leonard
-----Original Message-----
From: Archie Cobbs [mailto:archie@dellroad.org]
Sent: Monday, October 14, 2002 2:44 PM
To: Leonard Chung
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: MPD PPTP tunneling intermittantly fails
Leonard Chung writes:
> The problem that I'm having is that MPD starts properly and I can
> successfully connect to the service using Windows clients. However, when I
> ping internal hosts, the first five or so work fine, and then beyond that
> packets start getting lost, with a loss rate of around 50%. These tests
are
> run over a local network with two subnets, so packet loss shouldn't be a
> problem. So although I can currently connect and create a tunnel, it isn't
> very useful as beyond any initial DNS queries, file transfers, etc. fail
> completely.
Are you using Mac OS X clients? If so, you may need the
latest patch to ng_pptpgre(4) to work around a problem:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_pptpgre.c.diff?r1=
1.25&r2=1.26
Otherwise, I haven't heard of anyone else having that particular problem..
See if you have errors reported by 'ngctl msg ng0:inet.ppp.link0 getstats'
(replace 'ng0' with the appropriate inteface name).
> Also, is there any way to get DHCP to work with MPD rather than hard wire
> IPs directly into MPD's config files?
Unfortunately not.
> I'm guessing this is probably just something easy that I'm missing. My
> config files and an MPD trace are below.
These look reasonable.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 3: 3:30 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 8D06B37B404; Wed, 16 Oct 2002 03:03:27 -0700 (PDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 2437F43EAA; Wed, 16 Oct 2002 03:03:26 -0700 (PDT)
(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from localhost ([3ffe:501:4819:2000:14e:a4d1:f898:6ed5])
by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9GA2mt66864;
Wed, 16 Oct 2002 19:02:48 +0900 (JST)
Date: Wed, 16 Oct 2002 19:03:33 +0900
Message-ID: <y7vbs5u4s5m.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: "Sam Leffler" <sam@errno.com>
Cc: "Julian Elischer" <julian@elischer.org>,
<freebsd-arch@FreeBSD.ORG>, <freebsd-net@FreeBSD.ORG>
Subject: Re: CFR: m_tag patch
In-Reply-To: <080101c27151$b2e92a30$52557f42@errno.com>
References: <Pine.BSF.4.21.0210071613260.34884-100000@InterJet.elischer.org>
<18d301c26e5e$8b5c7a30$52557f42@errno.com>
<y7vd6qhg0vj.wl@ocean.jinmei.org>
<080101c27151$b2e92a30$52557f42@errno.com>
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 20000228(IM140)
Lines: 59
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Fri, 11 Oct 2002 11:12:02 -0700,
>>>>> "Sam Leffler" <sam@errno.com> said:
>> > struct m_tag {
>> > SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags
> */
>> > u_int16_t m_tag_id; /* Tag ID */
>> > u_int16_t m_tag_len; /* Length of data */
>> > u_int32_t m_tag_cookie; /* Module/ABI */
>> > };
(snip)
>> Sorry for interrupting, but please let me make it sure. Do you intend
>> to hide the additional member from other modules than the m_tag
>> internal? I'm afraid a story that (e.g.) some code fragments in the
>> network layer directly refers to m_tag_cookie, which will break source
>> level compatibility with other BSDs (when the code fragments are
>> shared with others). As suz said before, we (KAME) are very much
>> afraid of this kind of story.
> The changes I'm proposing for KAME code make no references to m_tag_cookie.
> Things should be clear when you have a patch to look at.
I know that, but what I'm worrying about is a story that *.c under
netinet[6] will have a direct reference to m_tag_cookie *in the
future". Then we'll need to separate the code fragments like this:
#if defined(__FreeBSD__) && && __FreeBSD__ >= 5
if (mtag->m_tag_cookie != PACKET_TAG_IPSEC_OUT_DONE &&
mtag->m_tag_cookie !=
PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED)
continue;
#else
if (mtag->m_tag_id != PACKET_TAG_IPSEC_OUT_DONE &&
mtag->m_tag_id !=
PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED)
continue;
#endif
(derived from the current KAME's ip6_output.c)
We've experienced a lot of headaches due to this type of
incompatibility. I fully understand that once some changes are
incorporated to a particular BSD, the BSD developers are free to
modify the code based on their local policy, even if the result
introduces the incompatibility with other BSDs. Of course, there
should be a reason for the modification, and the change may provide a
better behavior. So, I can only ask, "please understand our position
(that needs to handle all *BSDs) and consider a compromise."
> I'm working on
> getting that to you.
Yes, I noticed that, thanks. I'll take a closer look at it later.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 3:19:56 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 9F65C37B401
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 03:19:55 -0700 (PDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
by mx1.FreeBSD.org (Postfix) with ESMTP id D696F43E88
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 03:19:54 -0700 (PDT)
(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from localhost ([3ffe:501:4819:2000:14e:a4d1:f898:6ed5])
by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9GAJnt67022;
Wed, 16 Oct 2002 19:19:50 +0900 (JST)
Date: Wed, 16 Oct 2002 19:20:34 +0900
Message-ID: <y7v8z0y4rd9.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: drogoh <drogoh@necessary-evil.org>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: IPv6 tunnel with PPPoE
In-Reply-To: <20021012010103.649ada4a.drogoh@necessary-evil.org>
References: <20021012010103.649ada4a.drogoh@necessary-evil.org>
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 20000228(IM140)
Lines: 14
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Sat, 12 Oct 2002 01:01:03 -0500,
>>>>> drogoh <drogoh@necessary-evil.org> said:
> I am wondering if anyone has used an IPv6 tunnel with something like freenet6 using PPPoE with userland PPP. I've tried to use one myself, but my problem APPEARS to be with PPP, because in the ppp.log I see lines like this: IPV6CP: deflink: State change Closed --> Req-Sent and Phase: deflink: IPV6CP protocol reject closes IPV6CP !
> However, if this is not the reason for not being able to get a route with PPPoE, I'd appreciate any help to get it working.
If you're trying to establish the tunnel as your external link to the
IPv6 Internet, you don't need ipv6cp. Just disable it:
disable ipv6cp
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 5:29:37 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 4324137B401; Wed, 16 Oct 2002 05:29:35 -0700 (PDT)
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 2661843EB1; Wed, 16 Oct 2002 05:29:33 -0700 (PDT)
(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9GCTMIw014911;
Wed, 16 Oct 2002 14:29:24 +0200 (CEST)
(envelope-from phk@critter.freebsd.dk)
To: Bruce Evans <bde@zeta.org.au>
Cc: net@freebsd.org, arch@freebsd.org
Subject: Re: cvs commit: src/sys/dev/kbd atkbdcreg.h
In-Reply-To: Your message of "Wed, 16 Oct 2002 22:23:18 +1000."
<20021016221657.I5365-100000@gamplex.bde.org>
Date: Wed, 16 Oct 2002 14:29:22 +0200
Message-ID: <14910.1034771362@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
In message <20021016221657.I5365-100000@gamplex.bde.org>, Bruce Evans writes:
>> This kind of bug is a _really_ horribly thing as we end up with one bit
>> of code thinking a particular structure is 136 bytes and another that it
>> is only 112 bytes.
>>
>> Ideally all places would remember to #include the right "opt_foo.h" file,
>> but I think in practice file containing the variable sized struct should
>> #include it explicitly as a precaution.
>
>Ideally, header files wouldn't have any "variable sized structs" or
>anything else that depends on options. Core headers have to be much
>more careful about this because including an options header nested
>would break most modules and everything outside of the kernel (apart
>from the bug that modules and things outside of the kernel have no
>way to determine the correct value for the option).
I agree.
Suggestions for the best way of fixing "struct ipq" in ip_var.h
hereby solicited.
I can see that MAC just unceremonously put their own field in there,
and I guess that is the most sensible thing to do, despite the
RAM this may cost during a DoS attack.
Objections to this patch:
Index: ip_var.h
===================================================================
RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v
retrieving revision 1.66
diff -u -r1.66 ip_var.h
--- ip_var.h 16 Oct 2002 01:54:44 -0000 1.66
+++ ip_var.h 16 Oct 2002 07:35:44 -0000
@@ -68,10 +68,8 @@
u_short ipq_id; /* sequence id for reassembly */
struct mbuf *ipq_frags; /* to ip headers of fragments */
struct in_addr ipq_src,ipq_dst;
-#ifdef IPDIVERT
u_int32_t ipq_div_info; /* ipfw divert port & flags */
u_int16_t ipq_div_cookie; /* ipfw divert cookie */
-#endif
struct label ipq_label; /* MAC label */
};
#endif /* _KERNEL */
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 6:45:10 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 7F1E937B401
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 06:45:08 -0700 (PDT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
by mx1.FreeBSD.org (Postfix) with ESMTP id F3A9443EA3
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 06:45:07 -0700 (PDT)
(envelope-from don@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19)
id <42S947QM>; Wed, 16 Oct 2002 09:45:07 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022C8D@mail.sandvine.com>
From: Don Bowman <don@sandvine.com>
To: "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org>
Subject: dynamic load of em/fxp/bge
Date: Wed, 16 Oct 2002 09:45:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
I am trying to load the if_em, if_fxp, if_bge drivers
via /boot/loader.conf.
I've added
if_fxp_load="YES"
if_bge_load="YES"
if_em_load="YES"
The problem is that the bge driver doesn't load. It will
if I manually load it after startup with kldload. The issue
seems to be a dependency on miibus, both fxp and bge want
to load it, bge gets an error that its already loaded.
I tried putting 'miibus_load="YES"' in loader.conf, but the
same affect is seen.
I've tried from the boot prompt doing an explicit load of these
manually in each order, but to no avail.
As a work-around, I've placed an kldload if_bge in rc.network
before the 'ifconfig -l'.
Any suggestions on why the fxp/bge don't play nice when loaded
automatically, but will work if run manually? Is there a timing
thing that the fxp hasn't initialised its miibus yet?
I have:
fxp0
fxp1
bge0
in this particular machine. The bge will get miibus2 (eventually),
leaving fxp0 to have miibus0, fxp1 to have miibus1 I think.
Suggestions?
--don
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 7:39:19 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 69B5C37B401
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 07:39:17 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id E699F43E6A
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 07:39:16 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9GEdGpJ034796;
Wed, 16 Oct 2002 07:39:16 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9GEdGCo034795;
Wed, 16 Oct 2002 07:39:16 -0700 (PDT)
(envelope-from rizzo)
Date: Wed, 16 Oct 2002 07:39:16 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Petri Helenius <pete@he.iki.fi>
Cc: Lars Eggert <larse@ISI.EDU>, freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021016073916.A34626@carp.icir.org>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <06c901c274d8$e5280b80$8c2a40c1@PHE>; from pete@he.iki.fi on Wed, Oct 16, 2002 at 08:57:19AM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, Oct 16, 2002 at 08:57:19AM +0300, Petri Helenius wrote:
> >
> > how large are the packets and how fast is the box ?
>
> Packets go out at an average size of 1024 bytes. The box is dual
> P4 Xeon 2400/400 so I think it should qualify as "fast" ? I disabled
yes, it qualifies as fast. With this kind of box, a trivial
program can send short (18 byte payload, 64 byte total)
UDP frames at 5-600kpps, with quite a bit of time i suspect is
being spent in the userland-kernel transition (with some tricks
to skip that i went up to ~680kpps).
> The information I´m looking for is how to instrument where the
hard to tell -- see if short packets you get the same performance
i mention above, then maybe try some tricks such as sending
short bursts (5-10 pkts at a time) on each of the interfaces.
Maybe using a UP kernel as opposed to an SMP one might give you
slightly better performance, i am not sure though.
There might be some minor optimizations here and there which could
possibly help (e.g. make th em driver use m_getcl(), remove IPSEC
from the kernel if you have it) but you are essentially close to
the speed you can get with that box (within a factor of 2, probably).
cheers
luigi
> > on a fast box you should be able to generate packets faster than wire
> > speed for sizes around 500bytes, meaning that you are going to saturate
> > the queue no matter how large it is.
> >
> > cheers
> > luigi
> >
> > > em-interface is running 66/64 and is there a way to see interface queue
> depth?
> > > em0: <Intel(R) PRO/1000 Network Connection, Version - 1.3.14> port
> 0x3040-0x307f
> > > mem 0xfc220000-0xfc23ffff irq 17 at device 3.0 on pci2
> > > em0: Speed:1000 Mbps Duplex:Full
> > > pcib2: <PCI to PCI bridge (vendor=8086 device=1460)> at device 29.0 on pci1
> > > IOAPIC #2 intpin 0 -> irq 16
> > > IOAPIC #2 intpin 6 -> irq 17
> > > IOAPIC #2 intpin 7 -> irq 18
> > > pci2: <PCI bus> on pcib2
> > >
> > > The OS is 4.7-RELEASE.
> > >
> > > Pete
> > >
> > >
> > >
> > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > with "unsubscribe freebsd-net" in the body of the message
> >
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 7:46:18 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 88ECB37B401; Wed, 16 Oct 2002 07:46:15 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 1F26543E8A; Wed, 16 Oct 2002 07:46:15 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9GEkBpJ034883;
Wed, 16 Oct 2002 07:46:11 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9GEkAG2034882;
Wed, 16 Oct 2002 07:46:10 -0700 (PDT)
(envelope-from rizzo)
Date: Wed, 16 Oct 2002 07:46:10 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" <jinmei@isl.rdc.toshiba.co.jp>
Cc: Sam Leffler <sam@errno.com>,
Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.ORG,
freebsd-net@FreeBSD.ORG
Subject: Re: CFR: m_tag patch
Message-ID: <20021016074610.C34626@carp.icir.org>
References: <Pine.BSF.4.21.0210071613260.34884-100000@InterJet.elischer.org> <18d301c26e5e$8b5c7a30$52557f42@errno.com> <y7vd6qhg0vj.wl@ocean.jinmei.org> <080101c27151$b2e92a30$52557f42@errno.com> <y7vbs5u4s5m.wl@ocean.jinmei.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <y7vbs5u4s5m.wl@ocean.jinmei.org>; from jinmei@isl.rdc.toshiba.co.jp on Wed, Oct 16, 2002 at 07:03:33PM +0900
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Actually from what i have read on previous postings on this thread,
the only additional check that you might/will need is to make sure
that m_tag_cookie corresponds to the GENERIC ABI.
Also note that in your example the code should be conditional
on __FreeBSD_version and not on __FreeBSD__
cheers
luigi
On Wed, Oct 16, 2002 at 07:03:33PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
...
> >>>>> "Sam Leffler" <sam@errno.com> said:
>
> >> > struct m_tag {
> >> > SLIST_ENTRY(m_tag) m_tag_link; /* List of packet tags
> > */
> >> > u_int16_t m_tag_id; /* Tag ID */
> >> > u_int16_t m_tag_len; /* Length of data */
> >> > u_int32_t m_tag_cookie; /* Module/ABI */
> >> > };
>
> (snip)
>
> >> Sorry for interrupting, but please let me make it sure. Do you intend
> >> to hide the additional member from other modules than the m_tag
> >> internal? I'm afraid a story that (e.g.) some code fragments in the
> >> network layer directly refers to m_tag_cookie, which will break source
> >> level compatibility with other BSDs (when the code fragments are
> >> shared with others). As suz said before, we (KAME) are very much
> >> afraid of this kind of story.
>
> > The changes I'm proposing for KAME code make no references to m_tag_cookie.
> > Things should be clear when you have a patch to look at.
>
> I know that, but what I'm worrying about is a story that *.c under
> netinet[6] will have a direct reference to m_tag_cookie *in the
> future". Then we'll need to separate the code fragments like this:
>
> #if defined(__FreeBSD__) && && __FreeBSD__ >= 5
> if (mtag->m_tag_cookie != PACKET_TAG_IPSEC_OUT_DONE &&
> mtag->m_tag_cookie !=
> PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED)
> continue;
> #else
> if (mtag->m_tag_id != PACKET_TAG_IPSEC_OUT_DONE &&
> mtag->m_tag_id !=
> PACKET_TAG_IPSEC_OUT_CRYPTO_NEEDED)
> continue;
> #endif
> (derived from the current KAME's ip6_output.c)
>
> We've experienced a lot of headaches due to this type of
> incompatibility. I fully understand that once some changes are
> incorporated to a particular BSD, the BSD developers are free to
> modify the code based on their local policy, even if the result
> introduces the incompatibility with other BSDs. Of course, there
> should be a reason for the modification, and the change may provide a
> better behavior. So, I can only ask, "please understand our position
> (that needs to handle all *BSDs) and consider a compromise."
>
> > I'm working on
> > getting that to you.
>
> Yes, I noticed that, thanks. I'll take a closer look at it later.
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> jinmei@isl.rdc.toshiba.co.jp
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 7:52:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 7494537B401; Wed, 16 Oct 2002 07:52:57 -0700 (PDT)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 3712543EAA; Wed, 16 Oct 2002 07:52:56 -0700 (PDT)
(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA13232;
Thu, 17 Oct 2002 00:52:43 +1000
Date: Thu, 17 Oct 2002 01:03:20 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Jeffrey Hsu <hsu@FreeBSD.ORG>, <net@FreeBSD.ORG>,
<arch@FreeBSD.ORG>
Subject: Re: RFC: eliminating the _IP_VHL hack.
In-Reply-To: <69413.1034756200@critter.freebsd.dk>
Message-ID: <20021017004627.O5865-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, 16 Oct 2002, Poul-Henning Kamp wrote:
> In message <20021016172019.W4358-100000@gamplex.bde.org>, Bruce Evans writes:
> >On Tue, 15 Oct 2002, Jeffrey Hsu wrote:
> >
> >> > The side effect of having some source-files using the _IP_VHL hack and
> >> > some not is that sizeof(struct ip) varies from file to file, which at
> >> > best is confusing an at worst the source of some really evil bugs.
> >
> >There is no such effect, or ip would not work.
>
> s/,/ with our current compilers and architectures,/
It is the non-_IP_VHL case that will break. The _IP_VHL case requires
little more than the existence of uint8_t, which is now required by POSIX.
> >> > I would therefore propose to eliminate the _IP_VHL hack from the kernel
> >> > to end this state of (potential) confusion
> >
> >This would remove the least unportable version.
>
> Could be, but there is no point in us having two different versions,
> neither of which is guaranteed to be portable, in particular when
> one of the two is private to FreeBSD and not even consistently used
> there.
I agree that source oce portability is a problem and wasn't helped by
not completing this change.
> For reference:
>
> NetBSD hasn't got the _IP_VHL but has a __packed__ on the
> structure.
As you may know, I don't like gccisms like __packed__. NetBSD actually
uses __attribute__(__packed__) like we used to in other places. Our
__packed doesn't exactly help portability, since it is a syntax error
on systems that don't #define it.
> OpenBSD hasn't got the _IP_VHL either, but hasn't adopted
> the __packed__ from NetBSD.
>
> Linux also uses bitfields and endianess #ifdefs.
There are also an amazing number of unportable bit-fields in <sys/ata.h>
<sys/cdio.h>, <sys/cdrio.h> and <sys/dvdio.h>. The declarations of these
don't even use endianness #ifdefs or __packed in most cases. Some
unportabilities are avoided using the gcc extension of small bit-field
types.
> I'll ammend my proposal to include a __packed__ and a CTASSERT on
> the size of struct ip == 20.
I prefer just the CTASSERT until __packed is found to be necessary.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 9: 9:47 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 02EDD37B401
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 09:09:46 -0700 (PDT)
Received: from ebb.errno.com (ebb.errno.com [66.127.85.87])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5C88343E9C
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 09:09:45 -0700 (PDT)
(envelope-from sam@errno.com)
Received: from melange (melange.errno.com [66.127.85.82])
(authenticated bits=0)
by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g9GG9f1H004556
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
Wed, 16 Oct 2002 09:09:45 -0700 (PDT)?g
(envelope-from sam@errno.com)œ
X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange
Message-ID: <22e001c2752e$7179d370$52557f42@errno.com>
From: "Sam Leffler" <sam@errno.com>
To: "Petri Helenius" <pete@he.iki.fi>, "Lars Eggert" <larse@ISI.EDU>
Cc: "Luigi Rizzo" <rizzo@icir.org>, <freebsd-net@FreeBSD.ORG>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE>
Subject: Re: ENOBUFS
Date: Wed, 16 Oct 2002 09:09:41 -0700
Organization: Errno Consulting
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> > The 900Mbps are similar to what I see here on similar hardware.
>
> What kind of receive performance do you observe? I haven´t got that
> far yet.
> >
> > For your two-interface setup, are the 600Mbps aggregate send rate on
> > both interfaces, or do you see 600Mbps per interface? In the latter
>
> 600Mbps per interface. I´m going to try this out also on -CURRENT
> to see if it changes anything. Interrupts do not seem to pose a big
> problem because I´m seeing only a few thousand em interrupts
> a second but since every packet involves a write call there are >100k
> syscalls a second.
>
> > case, is your CPU maxed out? Only one can be in the kernel under
> > -stable, so the second one won't help much. With small packets like
> > that, you may be interrupt-bound. (Until Luigi releases polling for em
> > interfaces... :-)
> >
> I´ll try changing the packet sizes to figure out optimum.
>
Try my port of the netbsd kttcp kernel module. You can find it at
http://www.freebsd.org/~sam
It will eliminate the system calls. Don't recall if you said your system is
a dual-processor; I never tried it on SMP hardware.
Sam
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 10: 5: 0 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 44F7337B401; Wed, 16 Oct 2002 10:04:59 -0700 (PDT)
Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
by mx1.FreeBSD.org (Postfix) with ESMTP
id D887C43E8A; Wed, 16 Oct 2002 10:04:58 -0700 (PDT)
(envelope-from tlambert2@mindspring.com)
Received: from pool0308.cvx40-bradley.dialup.earthlink.net ([216.244.43.53] helo=mindspring.com)
by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
id 181rbC-00027m-00; Wed, 16 Oct 2002 10:04:46 -0700
Message-ID: <3DAD9BE6.530F8466@mindspring.com>
Date: Wed, 16 Oct 2002 10:03:34 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Bruce Evans <bde@zeta.org.au>, net@freebsd.org, arch@freebsd.org
Subject: Re: cvs commit: src/sys/dev/kbd atkbdcreg.h
References: <14910.1034771362@critter.freebsd.dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Poul-Henning Kamp wrote:
> In message <20021016221657.I5365-100000@gamplex.bde.org>, Bruce Evans writes:
> >Ideally, header files wouldn't have any "variable sized structs" or
> >anything else that depends on options. Core headers have to be much
> >more careful about this because including an options header nested
> >would break most modules and everything outside of the kernel (apart
> >from the bug that modules and things outside of the kernel have no
> >way to determine the correct value for the option).
>
> I agree.
>
> Suggestions for the best way of fixing "struct ipq" in ip_var.h
> hereby solicited.
Please use a union; things like diversion information result in
other information not being used. It makes no sense to uniformly
bloat all memory allocations for minority features, merely for
the sake of uniformity.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 10:29:30 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B7F5237B404
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 10:29:29 -0700 (PDT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
by mx1.FreeBSD.org (Postfix) with ESMTP id 917BE43EBE
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 10:29:28 -0700 (PDT)
(envelope-from don@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19)
id <42S9479X>; Wed, 16 Oct 2002 13:29:27 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022C96@mail.sandvine.com>
From: Don Bowman <don@sandvine.com>
To: 'Sam Leffler' <sam@errno.com>, freebsd-net@FreeBSD.ORG
Subject: RE: ENOBUFS
Date: Wed, 16 Oct 2002 13:29:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Sam Leffler wrote:
> Try my port of the netbsd kttcp kernel module. You can find it at
>
> http://www.freebsd.org/~sam
this seems to use some things from netbsd like
so_rcv.sb_lastrecord and SBLASTRECORDCHK/SBLASTMBUFCHK.
Is there something else I need to apply to build it on
freebsd -STABLE?
--don (don@sandvine.com www.sandvine.com)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 10:33:26 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id C3F8E37B401
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 10:33:25 -0700 (PDT)
Received: from ebb.errno.com (ebb.errno.com [66.127.85.87])
by mx1.FreeBSD.org (Postfix) with ESMTP id C37D443ECD
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 10:33:22 -0700 (PDT)
(envelope-from sam@errno.com)
Received: from melange (melange.errno.com [66.127.85.82])
(authenticated bits=0)
by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g9GHXL1H005244
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
Wed, 16 Oct 2002 10:33:22 -0700 (PDT)?g
(envelope-from sam@errno.com)œ
X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange
Message-ID: <243a01c2753a$1ff8b0a0$52557f42@errno.com>
From: "Sam Leffler" <sam@errno.com>
To: "Don Bowman" <don@sandvine.com>, <freebsd-net@FreeBSD.ORG>
References: <FE045D4D9F7AED4CBFF1B3B813C8533701022C96@mail.sandvine.com>
Subject: Re: ENOBUFS
Date: Wed, 16 Oct 2002 10:33:21 -0700
Organization: Errno Consulting
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> Sam Leffler wrote:
> > Try my port of the netbsd kttcp kernel module. You can find it at
> >
> > http://www.freebsd.org/~sam
>
> this seems to use some things from netbsd like
> so_rcv.sb_lastrecord and SBLASTRECORDCHK/SBLASTMBUFCHK.
> Is there something else I need to apply to build it on
> freebsd -STABLE?
>
Sorry, I ported Jason's tail pointer stuff to -stable before kttcp so it
assumes that's installed. If you don't want to redo kttcp you might try
applying thorpe-stable.patch from the same directory. FWIW I've been
running with that patch in my production systems for many months w/o
incident. I never committed it because I didn't see noticeable performance
improvements.
Sam
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 10:49:41 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 4F8E837B401
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 10:49:40 -0700 (PDT)
Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4070043EBE
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 10:49:35 -0700 (PDT)
(envelope-from mbretter@inode.at)
Received: from line-c-227.adsl-dynamic.inode.at ([62.99.151.227]:1027 helo=inode.at)
by smtp.inode.at with esmtp (Exim 4.05)
id 181sEK-0003xM-00
for freebsd-net@freebsd.org; Wed, 16 Oct 2002 19:45:12 +0200
Message-ID: <3DADA600.7090707@inode.at>
Date: Wed, 16 Oct 2002 19:46:40 +0200
From: Michael Bretterklieber <mbretter@inode.at>
Organization: JAWA Management Software GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: mpd - Radius
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi,
I'm now evaluating if its difficult to extend mpd with radius
authentication (with libradius).
I have some questions:
1. Will be in auth.c the function AuthGetData() the right place to put
Radius stuff?
2. What was the intention behind the function CustomAuthData()?
3. How should radius configured in the mpd.conf, is something like: set
bundle radius /etc/radius.conf ok?
bye,
--
--
--------------------------------------
E-mail: Michael.Bretterklieber@jawa.at
----------------------------
JAWA Management Software GmbH
Liebenauer Hauptstr. 200
A-8041 GRAZ
Tel: ++43-(0)316-403274-12
Fax: ++43-(0)316-403274-10
GSM: ++43-(0)676-93 96 698
homepage: http://www.jawa.at
--------- privat -----------
E-mail: mbretter@inode.at
homepage: http://www.inode.at/mbretter
--------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 11: 7:41 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id A1FFA37B401; Wed, 16 Oct 2002 11:07:39 -0700 (PDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 34E5843EB2; Wed, 16 Oct 2002 11:07:37 -0700 (PDT)
(envelope-from jinmei@isl.rdc.toshiba.co.jp)
Received: from localhost ([3ffe:501:100f:f::6])
by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g9GI7Ht70328;
Thu, 17 Oct 2002 03:07:18 +0900 (JST)
Date: Thu, 17 Oct 2002 03:07:07 +0900
Message-ID: <y7vadle2r78.wl@ocean.jinmei.org>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
To: Luigi Rizzo <rizzo@icir.org>
Cc: Sam Leffler <sam@errno.com>,
Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.ORG,
freebsd-net@FreeBSD.ORG
Subject: Re: CFR: m_tag patch
In-Reply-To: <20021016074610.C34626@carp.icir.org>
References: <Pine.BSF.4.21.0210071613260.34884-100000@InterJet.elischer.org>
<18d301c26e5e$8b5c7a30$52557f42@errno.com>
<y7vd6qhg0vj.wl@ocean.jinmei.org>
<080101c27151$b2e92a30$52557f42@errno.com>
<y7vbs5u4s5m.wl@ocean.jinmei.org>
<20021016074610.C34626@carp.icir.org>
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 20000228(IM140)
Lines: 33
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>>>>> On Wed, 16 Oct 2002 07:46:10 -0700,
>>>>> Luigi Rizzo <rizzo@icir.org> said:
> Actually from what i have read on previous postings on this thread,
> the only additional check that you might/will need is to make sure
> that m_tag_cookie corresponds to the GENERIC ABI.
(I re-read the thread) perhaps the example in my previous message
wasn't good (and it was at least incorrect). According to the
discussion on the thread, we'll probably keep m_tag_cookie being 0 and
use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this
convention is kept (and will be kept) at least under netinet6.
It would be good to make more explicit comments on the intended usage,
not just a single comment for the m_tag_cookie member:
u_int32_t m_tag_cookie; /* Module/ABI */
> Also note that in your example the code should be conditional
> on __FreeBSD_version and not on __FreeBSD__
We (KAME) actually need __FreeBSD__, because we want to keep a single
code base for all *BSDs (again, I know this is our local issue). But,
whether or not we need __FreeBSD__ (in addition to __FreeBSD_version)
is a minor point. From our point view, we do want to avoid any ifdef
for separating different *BSDs.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
jinmei@isl.rdc.toshiba.co.jp
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 11:19: 6 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id BB0E137B401; Wed, 16 Oct 2002 11:19:04 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP
id CD80343E8A; Wed, 16 Oct 2002 11:19:03 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9GIIvpJ038254;
Wed, 16 Oct 2002 11:18:57 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9GIIvl8038253;
Wed, 16 Oct 2002 11:18:57 -0700 (PDT)
(envelope-from rizzo)
Date: Wed, 16 Oct 2002 11:18:57 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" <jinmei@isl.rdc.toshiba.co.jp>
Cc: Sam Leffler <sam@errno.com>,
Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.ORG,
freebsd-net@FreeBSD.ORG
Subject: Re: CFR: m_tag patch
Message-ID: <20021016111857.A38181@carp.icir.org>
References: <Pine.BSF.4.21.0210071613260.34884-100000@InterJet.elischer.org> <18d301c26e5e$8b5c7a30$52557f42@errno.com> <y7vd6qhg0vj.wl@ocean.jinmei.org> <080101c27151$b2e92a30$52557f42@errno.com> <y7vbs5u4s5m.wl@ocean.jinmei.org> <20021016074610.C34626@carp.icir.org> <y7vadle2r78.wl@ocean.jinmei.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <y7vadle2r78.wl@ocean.jinmei.org>; from jinmei@isl.rdc.toshiba.co.jp on Thu, Oct 17, 2002 at 03:07:07AM +0900
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Thu, Oct 17, 2002 at 03:07:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
...
> (I re-read the thread) perhaps the example in my previous message
> wasn't good (and it was at least incorrect). According to the
> discussion on the thread, we'll probably keep m_tag_cookie being 0 and
> use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this
> convention is kept (and will be kept) at least under netinet6.
unfortunately this will not prevent code from having to check that
the m_tag_cookie actually corresponds to the value you want, to
make sure that your code does not misinterpret as own tags
generated/destined to other clients.
Am I correct, Sam ?
> > Also note that in your example the code should be conditional
> > on __FreeBSD_version and not on __FreeBSD__
>
> We (KAME) actually need __FreeBSD__, because we want to keep a single
> code base for all *BSDs (again, I know this is our local issue). But,
i know it is a minor point, but we had this discussion before
(and hit related bugs during cross builds).
__FreeBSD__ refers to the build environment, whereas __FreeBSD_version
matches the source tree you are building, and it is #defined
on all versions of FreeBSD that you care about.
So, should you have FreeBSD-specific code (hopefully as little as
possible), you should *never* use __FreeBSD__ but instead use only
__FreeBSD_version.
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 11:29:55 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id E9E5337B404; Wed, 16 Oct 2002 11:29:53 -0700 (PDT)
Received: from ebb.errno.com (ebb.errno.com [66.127.85.87])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 500B943EE8; Wed, 16 Oct 2002 11:29:29 -0700 (PDT)
(envelope-from sam@errno.com)
Received: from melange (melange.errno.com [66.127.85.82])
(authenticated bits=0)
by ebb.errno.com (8.12.5/8.12.1) with ESMTP id g9GITP1H005622
(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
Wed, 16 Oct 2002 11:29:26 -0700 (PDT)?g
(envelope-from sam@errno.com)œ
X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange
Message-ID: <24db01c27541$f529da40$52557f42@errno.com>
From: "Sam Leffler" <sam@errno.com>
To: "JINMEI Tatuya" <jinmei@isl.rdc.toshiba.co.jp>,
"Luigi Rizzo" <rizzo@icir.org>
Cc: <freebsd-net@FreeBSD.ORG>, <freebsd-arch@FreeBSD.ORG>,
"Julian Elischer" <julian@elischer.org>
References: <Pine.BSF.4.21.0210071613260.34884-100000@InterJet.elischer.org> <18d301c26e5e$8b5c7a30$52557f42@errno.com> <y7vd6qhg0vj.wl@ocean.jinmei.org> <080101c27151$b2e92a30$52557f42@errno.com> <y7vbs5u4s5m.wl@ocean.jinmei.org> <20021016074610.C34626@carp.icir.org> <y7vadle2r78.wl@ocean.jinmei.org> <20021016111857.A38181@carp.icir.org>
Subject: Re: CFR: m_tag patch
Date: Wed, 16 Oct 2002 11:29:25 -0700
Organization: Errno Consulting
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> On Thu, Oct 17, 2002 at 03:07:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B
wrote:
> ...
> > (I re-read the thread) perhaps the example in my previous message
> > wasn't good (and it was at least incorrect). According to the
> > discussion on the thread, we'll probably keep m_tag_cookie being 0 and
> > use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this
> > convention is kept (and will be kept) at least under netinet6.
>
> unfortunately this will not prevent code from having to check that
> the m_tag_cookie actually corresponds to the value you want, to
> make sure that your code does not misinterpret as own tags
> generated/destined to other clients.
>
> Am I correct, Sam ?
>
Correct. If you explicitly look inside the m_tag structure instead of using
one of the m_tag_* routines to search then you will need to validate
m_tag_cookie to avoid interpreting tags created by other modules. The
comments I wrote in mbuf.h for this stuff describe this and say that when
writing code that is to be compatible with other systems one should always
use MTAG_ABI_COMPAT and the openbsd-compatible m_tag_get and m_tag_find
routines.
m_tag_cookie was mainly added so that netgraph could piggyback on top of the
facility and remove it's private code. At some point it may be worthwhile
to talk with the openbsd+netbsd folks about adopting this new m_tag
facility.
Sam
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 11:41:17 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 7044037B404
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 11:41:15 -0700 (PDT)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88])
by mx1.FreeBSD.org (Postfix) with ESMTP id 16D0943E88
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 11:41:15 -0700 (PDT)
(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org ([12.232.206.8])
by rwcrmhc52.attbi.com
(InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
id <20021016184018.ZPRG11063.rwcrmhc52.attbi.com@InterJet.elischer.org>;
Wed, 16 Oct 2002 18:40:18 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA86830;
Wed, 16 Oct 2002 11:21:32 -0700 (PDT)
Date: Wed, 16 Oct 2002 11:21:31 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: Michael Bretterklieber <mbretter@inode.at>
Cc: freebsd-net@freebsd.org
Subject: Re: mpd - Radius
In-Reply-To: <3DADA600.7090707@inode.at>
Message-ID: <Pine.BSF.4.21.0210161120010.82978-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, 16 Oct 2002, Michael Bretterklieber wrote:
> Hi,
>
> I'm now evaluating if its difficult to extend mpd with radius
> authentication (with libradius).
> I have some questions:
>
> 1. Will be in auth.c the function AuthGetData() the right place to put
> Radius stuff?
> 2. What was the intention behind the function CustomAuthData()?
mpd was written for use in the InterJet, which had
a separate database controlling "everything".
you could hook in to that database using that (from memory)
Archie wil answer I'm sure and give more info..
also check how 'ppp' does it's radius stuff.
> 3. How should radius configured in the mpd.conf, is something like: set
> bundle radius /etc/radius.conf ok?
>
> bye,
>
> --
> --
> --------------------------------------
> E-mail: Michael.Bretterklieber@jawa.at
> ----------------------------
> JAWA Management Software GmbH
> Liebenauer Hauptstr. 200
> A-8041 GRAZ
> Tel: ++43-(0)316-403274-12
> Fax: ++43-(0)316-403274-10
> GSM: ++43-(0)676-93 96 698
> homepage: http://www.jawa.at
> --------- privat -----------
> E-mail: mbretter@inode.at
> homepage: http://www.inode.at/mbretter
> --------------------------------------
>
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 11:41:22 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id D4B9737B401; Wed, 16 Oct 2002 11:41:20 -0700 (PDT)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 72E3A43E9C; Wed, 16 Oct 2002 11:41:20 -0700 (PDT)
(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org ([12.232.206.8])
by rwcrmhc52.attbi.com
(InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
id <20021016184028.ZPUO11063.rwcrmhc52.attbi.com@InterJet.elischer.org>;
Wed, 16 Oct 2002 18:40:28 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA86833;
Wed, 16 Oct 2002 11:24:35 -0700 (PDT)
Date: Wed, 16 Oct 2002 11:24:34 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: Luigi Rizzo <rizzo@icir.org>
Cc: "JINMEI Tatuya / ?$B?@L@C#:H?(B" <jinmei@isl.rdc.toshiba.co.jp>,
Sam Leffler <sam@errno.com>, freebsd-arch@FreeBSD.ORG,
freebsd-net@FreeBSD.ORG
Subject: Re: CFR: m_tag patch
In-Reply-To: <20021016111857.A38181@carp.icir.org>
Message-ID: <Pine.BSF.4.21.0210161122540.82978-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, 16 Oct 2002, Luigi Rizzo wrote:
> On Thu, Oct 17, 2002 at 03:07:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> ...
> > (I re-read the thread) perhaps the example in my previous message
> > wasn't good (and it was at least incorrect). According to the
> > discussion on the thread, we'll probably keep m_tag_cookie being 0 and
> > use m_tag_id in (e.g.) ip6_output.c. So, we'll be happy if this
> > convention is kept (and will be kept) at least under netinet6.
>
> unfortunately this will not prevent code from having to check that
> the m_tag_cookie actually corresponds to the value you want, to
> make sure that your code does not misinterpret as own tags
> generated/destined to other clients.
>
> Am I correct, Sam ?
yes but this is always done with macros, and the OpenBSD
compatible macros also check for the correct cookie value.
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 13:18:33 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id AFF8D37B401
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 13:18:30 -0700 (PDT)
Received: from smtp.inode.at (smtp-01.inode.at [62.99.194.3])
by mx1.FreeBSD.org (Postfix) with ESMTP id D478343EAA
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 13:18:29 -0700 (PDT)
(envelope-from mbretter@inode.at)
Received: from line-c-227.adsl-dynamic.inode.at ([62.99.151.227]:1190 helo=inode.at)
by smtp.inode.at with esmtp (Exim 4.05)
id 181ucd-0000ql-00
for freebsd-net@freebsd.org; Wed, 16 Oct 2002 22:18:28 +0200
Message-ID: <3DADC8EB.4000603@inode.at>
Date: Wed, 16 Oct 2002 22:15:39 +0200
From: Michael Bretterklieber <mbretter@inode.at>
Organization: JAWA Management Software GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: Re: mpd - Radius
References: <Pine.BSF.4.21.0210161120010.82978-100000@InterJet.elischer.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi,
Julian Elischer wrote:
>On Wed, 16 Oct 2002, Michael Bretterklieber wrote:
>
>
>
>>Hi,
>>
>>I'm now evaluating if its difficult to extend mpd with radius
>>authentication (with libradius).
>>I have some questions:
>>
>>1. Will be in auth.c the function AuthGetData() the right place to put
>>Radius stuff?
>>
No. I wrote a small program wich is able to make radius-auth. Now I'm
integrating it into mpd and auth.c is the wrong place. The right place
will be pap.c or chap.c or ...
>>2. What was the intention behind the function CustomAuthData()?
>>
>>
>
>mpd was written for use in the InterJet, which had
>a separate database controlling "everything".
>you could hook in to that database using that (from memory)
>Archie wil answer I'm sure and give more info..
>also check how 'ppp' does it's radius stuff.
>
yes, I took many things from ppp.
No I'm trying for the first shot only to make pap-auth with radius.
>
>
>
>
>
>>3. How should radius configured in the mpd.conf, is something like: set
>>bundle radius /etc/radius.conf ok?
>>
>>bye,
>>
>>--
>>--
>>--------------------------------------
>>E-mail: Michael.Bretterklieber@jawa.at
>>----------------------------
>>JAWA Management Software GmbH
>>Liebenauer Hauptstr. 200
>>A-8041 GRAZ
>>Tel: ++43-(0)316-403274-12
>>Fax: ++43-(0)316-403274-10
>>GSM: ++43-(0)676-93 96 698
>>homepage: http://www.jawa.at
>>--------- privat -----------
>>E-mail: mbretter@inode.at
>>homepage: http://www.inode.at/mbretter
>>--------------------------------------
>>
>>
>>
>>
>>To Unsubscribe: send mail to majordomo@FreeBSD.org
>>with "unsubscribe freebsd-net" in the body of the message
>>
>>
>>
>
>
>
>
>
--
--
--------------------------------------
E-mail: Michael.Bretterklieber@jawa.at
----------------------------
JAWA Management Software GmbH
Liebenauer Hauptstr. 200
A-8041 GRAZ
Tel: ++43-(0)316-403274-12
Fax: ++43-(0)316-403274-10
GSM: ++43-(0)676-93 96 698
homepage: http://www.jawa.at
--------- privat -----------
E-mail: mbretter@inode.at
homepage: http://www.inode.at/mbretter
--------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 13:54:30 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D30BF37B401
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 13:54:27 -0700 (PDT)
Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5DF7B43E9E
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 13:54:27 -0700 (PDT)
(envelope-from mbretter@inode.at)
Received: from line-c-227.adsl-dynamic.inode.at ([62.99.151.227]:1201 helo=inode.at)
by smtp.inode.at with esmtp (Exim 4.05)
id 181v7G-0003G8-00; Wed, 16 Oct 2002 22:50:06 +0200
Message-ID: <3DADD157.5060709@inode.at>
Date: Wed, 16 Oct 2002 22:51:35 +0200
From: Michael Bretterklieber <mbretter@inode.at>
Organization: JAWA Management Software GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Cc: Archie Cobbs <archie@dellroad.org>
Subject: Re: mpd - Radius
References: <Pine.BSF.4.21.0210161120010.82978-100000@InterJet.elischer.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi,
Now I got pap-radius-auth with mpd to work :-)
I made it now with a static define. The next step will be to add the
appropriate config-param for mpd.conf.
Are there any hints, a small howto would be great?
Something like:
- naming conventions of param
- where to add param
- how to access param
bye,
Julian Elischer wrote:
>On Wed, 16 Oct 2002, Michael Bretterklieber wrote:
>
>
>
>>Hi,
>>
>>I'm now evaluating if its difficult to extend mpd with radius
>>authentication (with libradius).
>>I have some questions:
>>
>>1. Will be in auth.c the function AuthGetData() the right place to put
>>Radius stuff?
>>2. What was the intention behind the function CustomAuthData()?
>>
>>
>
>mpd was written for use in the InterJet, which had
>a separate database controlling "everything".
>you could hook in to that database using that (from memory)
>Archie wil answer I'm sure and give more info..
>also check how 'ppp' does it's radius stuff.
>
>
>
>
>
>>3. How should radius configured in the mpd.conf, is something like: set
>>bundle radius /etc/radius.conf ok?
>>
>>bye,
>>
>>--
>>--
>>--------------------------------------
>>E-mail: Michael.Bretterklieber@jawa.at
>>----------------------------
>>JAWA Management Software GmbH
>>Liebenauer Hauptstr. 200
>>A-8041 GRAZ
>>Tel: ++43-(0)316-403274-12
>>Fax: ++43-(0)316-403274-10
>>GSM: ++43-(0)676-93 96 698
>>homepage: http://www.jawa.at
>>--------- privat -----------
>>E-mail: mbretter@inode.at
>>homepage: http://www.inode.at/mbretter
>>--------------------------------------
>>
>>
>>
>>
>>To Unsubscribe: send mail to majordomo@FreeBSD.org
>>with "unsubscribe freebsd-net" in the body of the message
>>
>>
>>
>
>
>
>
>
--
--
--------------------------------------
E-mail: Michael.Bretterklieber@jawa.at
----------------------------
JAWA Management Software GmbH
Liebenauer Hauptstr. 200
A-8041 GRAZ
Tel: ++43-(0)316-403274-12
Fax: ++43-(0)316-403274-10
GSM: ++43-(0)676-93 96 698
homepage: http://www.jawa.at
--------- privat -----------
E-mail: mbretter@inode.at
homepage: http://www.inode.at/mbretter
--------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 14:21:38 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 3E11C37B401; Wed, 16 Oct 2002 14:21:37 -0700 (PDT)
Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16])
by mx1.FreeBSD.org (Postfix) with ESMTP
id A14BC43E6A; Wed, 16 Oct 2002 14:21:35 -0700 (PDT)
(envelope-from zec@tel.fer.hr)
Received: from tel.fer.hr (zg04-123.dialin.iskon.hr [213.191.137.124])
by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g9GLL2x02073;
Wed, 16 Oct 2002 23:21:03 +0200 (MEST)
Message-ID: <3DADD864.15757E4E@tel.fer.hr>
Date: Wed, 16 Oct 2002 23:21:40 +0200
From: Marko Zec <zec@tel.fer.hr>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org
Subject: RFC: BSD network stack virtualization
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi all,
on http://www.tel.fer.hr/zec/BSD/vimage/ you can find the patches
against 4.7-RELEASE kernel sources, which provide the functionality of
maintaining multiple independent network stack images within a single
operating system kernel. No userland patches are necessary, except an
additional virtual image management utility.
Within a patched kernel, every process and network interface belongs to
an unique virtual image, which provides the independent:
- set of network interfaces and userland processes;
- interface addresses and routing tables;
- TCP, UDP, raw protocol control blocks;
- network traffic counters / statistics;
- set of net.inet tunable sysctl variables;
- ipfw and dummynet instance;
- system load and CPU usage accounting and scheduling
From the userland perspective, all the virtualization modifications
within the kernel have been designed to preserve the complete API/ABI
compatibility, so absolutely all existing userland binaries should be
able to run unmodified on the virtualized kernel.
There are many possible applications of having multiple independent
instances of the network stack within a single kernel, just to mention
VPN provisioning, virtual hosting, and network simulation...
I'd be glad to hear your comments on the code and suggestions for the
further development.
Have fun!
Marko
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 14:31:52 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id E1D3237B401
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 14:31:51 -0700 (PDT)
Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252])
by mx1.FreeBSD.org (Postfix) with SMTP id 5A3AE43E6A
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 14:31:51 -0700 (PDT)
(envelope-from darcy@wavefire.com)
Received: (qmail 21948 invoked from network); 16 Oct 2002 21:53:02 -0000
Received: from dbitech.wavefire.com (HELO dbitech) (darcy@64.141.15.253)
by radius.wavefire.com with SMTP; 16 Oct 2002 21:53:02 -0000
Content-Type: text/plain;
charset="us-ascii"
From: Darcy Buskermolen <darcy@wavefire.com>
Organization: Wavefire Technologies Corp.
To: freebsd-net@freebsd.org
Subject: xl driver and POLLING
Date: Wed, 16 Oct 2002 14:31:44 -0700
User-Agent: KMail/1.4.3
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200210161431.44288.darcy@wavefire.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Has there been any work done on adding POLLING support to the xl driver?
--=20
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 14:42: 6 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id AD9A337B401
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 14:42:05 -0700 (PDT)
Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3])
by mx1.FreeBSD.org (Postfix) with SMTP id 7F47443E77
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 14:42:02 -0700 (PDT)
(envelope-from misho@interbgc.com)
Received: (qmail 74707 invoked by uid 1005); 16 Oct 2002 21:41:52 -0000
Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14
(uvscan: v4.1.60/v4228. Clear:.
Processed in 0.48539 secs); 16 Oct 2002 21:41:52 -0000
Received: from unknown (HELO misho) (217.9.231.229)
by mail.interbgc.com with SMTP; 16 Oct 2002 21:41:52 -0000
Message-ID: <000d01c2755c$d6d01f80$e5e709d9@interbgc.com>
Reply-To: "Mihail Balikov" <misho@interbgc.com>
From: "Mihail Balikov" <misho@interbgc.com>
To: "Darcy Buskermolen" <darcy@wavefire.com>
Cc: <freebsd-net@freebsd.org>
References: <200210161431.44288.darcy@wavefire.com>
Subject: Re: xl driver and POLLING
Date: Thu, 17 Oct 2002 00:41:50 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
http://gosho.interbgc.com/if_xl.c.diff
----- Original Message -----
From: "Darcy Buskermolen" <darcy@wavefire.com>
To: <freebsd-net@freebsd.org>
Sent: Thursday, October 17, 2002 12:31 AM
Subject: xl driver and POLLING
Has there been any work done on adding POLLING support to the xl driver?
--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 14:45:28 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B307637B401
for <net@freebsd.org>; Wed, 16 Oct 2002 14:45:26 -0700 (PDT)
Received: from bricore.com (adsl-66-124-255-252.dsl.snfc21.pacbell.net [66.124.255.252])
by mx1.FreeBSD.org (Postfix) with ESMTP id E023043E3B
for <net@freebsd.org>; Wed, 16 Oct 2002 14:45:25 -0700 (PDT)
(envelope-from lchen@briontech.com)
Received: from luoqi (luoqi.bricore.com [192.168.1.63])
by bricore.com (8.11.6/8.11.6) with SMTP id g9GLjPP19215
for <net@freebsd.org>; Wed, 16 Oct 2002 14:45:25 -0700 (PDT)
(envelope-from lchen@briontech.com)
From: "Luoqi Chen" <lchen@briontech.com>
To: <net@freebsd.org>
Subject: possible routed bug
Date: Wed, 16 Oct 2002 14:46:24 -0700
Message-ID: <AHEKICEOIHLOGINAFIINIEEJCAAA.lchen@briontech.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi,
I've encountered a possible bug in routed code that's interfering
with path mtu discovery mechanism. Routed deletes any cloned route
as soon as it sees one (with exception of arp routes in the local
ethernet), including protocol cloned routes served as holders for
path mtu information. Could anyone confirm this is not an intended
behavior?
This symptom of this bug is the breakdown of the pmtu discovery
process. It is easily reproduced with a machine behind a PPPoE
router (or any router limits MTU to below 1500) and running routed.
With this seutp, send an email larger than 1500 to your friend at
stanford or mit, you will find the email couldn't be delivered.
Start tcpdump and watch your email and icmp traffic, you will see
an icmp response ICMP_NEEDFRAG for the first 1500-byte tcp packet,
but *NO* immediate retransmission with reduced packet size in
response to the icmp message, the next retransmission will occur
10ms later when the retransmit timer expires and with the same 1500
byte packet.
Following is my proposed fix. Basically treat the protocol cloned
routes the same way as we treat arp routes (in fact also cloned),
that is, ignore them.
Index: table.c
===================================================================
RCS file: /home/ncvs/src/sbin/routed/table.c,v
retrieving revision 1.16
diff -u -r1.16 table.c
--- table.c 18 Feb 2002 20:35:19 -0000 1.16
+++ table.c 16 Oct 2002 18:33:53 -0000
@@ -1111,9 +1111,9 @@
continue;
/* ignore ARP table entries on systems with a merged route
- * and ARP table.
+ * and ARP table, or any other cloned routes
*/
- if (rtm->rtm_flags & RTF_LLINFO)
+ if (rtm->rtm_flags & (RTF_LLINFO | RTF_WASCLONED))
continue;
/* ignore multicast addresses
@@ -1259,6 +1259,11 @@
if (m.r.rtm.rtm_flags & RTF_LLINFO) {
trace_act("ignore ARP %s", str);
+ continue;
+ }
+
+ if (m.r.rtm.rtm_flags & RTF_WASCLONED) {
+ trace_act("ignore clone %s", str);
continue;
}
Thanks
-lq
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 15:17:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id CE9E137B401
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 15:17:54 -0700 (PDT)
Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4])
by mx1.FreeBSD.org (Postfix) with ESMTP id 69C2343E6E
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 15:17:52 -0700 (PDT)
(envelope-from mbretter@inode.at)
Received: from line-c-227.adsl-dynamic.inode.at ([62.99.151.227]:1231 helo=inode.at)
by smtp.inode.at with esmtp (Exim 4.05)
id 181wPs-00022W-00; Thu, 17 Oct 2002 00:13:24 +0200
Message-ID: <3DADE4DE.1080205@inode.at>
Date: Thu, 17 Oct 2002 00:14:54 +0200
From: Michael Bretterklieber <mbretter@inode.at>
Organization: JAWA Management Software GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org, Archie Cobbs <archie@dellroad.org>
Cc: Michael Bretterklieber <mbretter@inode.at>
Subject: Re: mpd - Radius
References: <Pine.BSF.4.21.0210161120010.82978-100000@InterJet.elischer.org> <3DADD157.5060709@inode.at>
Content-Type: multipart/mixed;
boundary="------------080308070009060802010907"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a multi-part message in MIME format.
--------------080308070009060802010907
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
mpd - basic radius (pap only) support now finished, see attachements.
two new files:
radius.h
radius.c
four modified files:
Makefile
bund.h
bund.c
pap.c
(I hope I got all changes files)
You can activate radius by adding this config-param:
set bundle radius /etc/radius.conf
you have to remove the comment in the Makefile from RADIUS_AUTH=yes.
bye,
Michael Bretterklieber wrote:
> Hi,
>
> Now I got pap-radius-auth with mpd to work :-)
>
> I made it now with a static define. The next step will be to add the
> appropriate config-param for mpd.conf.
>
> Are there any hints, a small howto would be great?
> Something like:
> - naming conventions of param
> - where to add param
> - how to access param
>
> bye,
>
> Julian Elischer wrote:
>
>> On Wed, 16 Oct 2002, Michael Bretterklieber wrote:
>>
>>
>>
>>> Hi,
>>>
>>> I'm now evaluating if its difficult to extend mpd with radius
>>> authentication (with libradius).
>>> I have some questions:
>>>
>>> 1. Will be in auth.c the function AuthGetData() the right place to
>>> put Radius stuff?
>>> 2. What was the intention behind the function CustomAuthData()?
>>>
>>
>>
>> mpd was written for use in the InterJet, which had
>> a separate database controlling "everything".
>> you could hook in to that database using that (from memory)
>> Archie wil answer I'm sure and give more info..
>> also check how 'ppp' does it's radius stuff.
>>
>>
>>
>>
>>
>>> 3. How should radius configured in the mpd.conf, is something like:
>>> set bundle radius /etc/radius.conf ok?
>>>
>>> bye,
>>>
>>> --
>>> --
>>> -------------------------------------- E-mail:
>>> Michael.Bretterklieber@jawa.at ---------------------------- JAWA
>>> Management Software GmbH
>>> Liebenauer Hauptstr. 200 A-8041 GRAZ Tel: ++43-(0)316-403274-12 Fax:
>>> ++43-(0)316-403274-10 GSM: ++43-(0)676-93 96 698 homepage:
>>> http://www.jawa.at --------- privat -----------
>>> E-mail: mbretter@inode.at
>>> homepage: http://www.inode.at/mbretter
>>> --------------------------------------
>>>
>>>
>>>
>>>
>>> To Unsubscribe: send mail to majordomo@FreeBSD.org
>>> with "unsubscribe freebsd-net" in the body of the message
>>>
>>>
>>
>>
>>
>>
>>
>>
>
--
--
--------------------------------------
E-mail: Michael.Bretterklieber@jawa.at
----------------------------
JAWA Management Software GmbH
Liebenauer Hauptstr. 200
A-8041 GRAZ
Tel: ++43-(0)316-403274-12
Fax: ++43-(0)316-403274-10
GSM: ++43-(0)676-93 96 698
homepage: http://www.jawa.at
--------- privat -----------
E-mail: mbretter@inode.at
homepage: http://www.inode.at/mbretter
--------------------------------------
--------------080308070009060802010907
Content-Type: application/gzip;
name="mpd_radius.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="mpd_radius.tar.gz"
H4sIAFXkrT0AA+0aa3PaSDJf4Vf0kt0EYoF5+BHjdS4yCFu3vE4SSVzZFCtLg9FFSDpJxOdL
8t+ve0YC2cGxvbvJXl2pU8Fi1O/p7ukZJjCDmlWzndns0TeDeqNe39vZeVQXcPNva29v91F9
f3e31dpr7O/vIX5jd2/vEdS/nUprWEaxGQI8Cn0//hre5Zwx93so9H2hWq3CdrwItheBXW3V
Draj0NoOKCgKxnwJOgsAdqHeajd32rstaNbrzeLW1hYIlNfMhpEVQ2MPmi18324lKC9fQrWx
J+3BFn426vDyZREeO57lLm0GJXMZz2vzUnbIu5gtPYsPFrceOzObzUCTu+pEn8oT45TGUtTQ
tJ1lRKhbj5mHoVvcKsL2syLAM+gqPXWoGupoqNP3baFIsyntoybNPfxDmgA4XlwoFFzmHdI3
GfXBr5bvRTGYcARPXO999YVrBTVSleOMzUD1Zn6KhfYTnll9gU+HxWpxq0BY289ANz0nvgJr
zqz3pAFJm0F5xTGYmxGDH45gfCrrCrdOGRpqRzYUePIEbsMbKsbrkfZLBT4SR4C+f1Hun3By
Ccqltz9F72Asj9sQMuupDVEcmleopfWexSVJcPXMBatUDoVPnh9IzQY65aAltfa4V4pQQPVP
GLoAjQbbjE2Y+SHEcyeC6CqK2YLbU7ghGsaMhUDM2/Br6afo1xIKTGVVC2Q8ORgZd5Flmd5I
6DkckqCBT5fzq57puBX4GepkXrXwhXXQMb2nMVygblbIbObFjulGXLsNEgEu/NiHc9PW2L+W
LIpp8DMaWCUDuz5HhSfonSi69EMbFmZszf9Gxgl10XnWIijzMKUPoTIXAJ8+QfZ1ykPi3Cq3
6a96H0zXsXFyogDjh5VSTRPjMZYId9qT1f5UHb6S+2p32h+dqENEWxvS5jQzJBiw6IKIUAei
H0QX5bE2MkZTjAEJ6lLKOBGD0TtaxsEyLuP76VD+BfWdBzUH9U65SWQXZkQ5Hajg9CTkXIzj
OdG8zNUcK4o2RWG60u9J0JP7uiLBcNLvJ/jnITPfH25O5NTDJOp86dnVF5hRs5rIau7ALUTi
WD+IwSl5eop5lsQOeRq1df7D/FlZuJ2TYQrf9LuQ3OYGcEuZzV1PuPdwPaF9EUs4+Jnr+BmY
iyn6cV2HCg+P9k1aPyDav67hnfGeaPzHAn6TCRsD/t5ez0Y8ET0w4onkD0Q8kT8k4gk/jXju
+Q1hD3xchElSadFljgemZbEgxnV0Y2nVEvcBlmDuUO7HP3H9pwz81g3gHf1fY6++n/Z/zXpj
h/q//UYz7/++B2zs/0RQfL0BTHCud4Ct/Xa9ue4Ad1rUAeJn2nYB6IoxHajDaVfVO6PhUOkY
0voFhf1QHiiZobGs69j3dCVKLRoQSZXB0BRDO8sy6XSUcZZrVxnie9Ln4Dnpc3AgPef6FI7R
Bp3FHX+xMD1b5DOm3QcfC9ezyjWV4HPC8SOUVnWUHkoSZn+JygXVacuMHd9bVdqSdD8pqZUk
Be38mDa5IP4IGZoYipZB4IfY1CHmPVgLf2XVD1kcXkHEcNm1E9Y9fQBiOHYWzF/G91WcOz/L
XJQzeOvjR61We0f8S7IYxDF0TknMRaO+L/YH9f2DdIcguFjU92a90hbjAJEXhNi5z7J9w3o9
ShqCDe+wruO6iavmM/MD1WvBLS3Z5PGVzKRhSHE2SRRzskle0sNclwbXpN20kTuw/WdW9IcB
T+P5X1r/8V19Xf+bzbz+f0e4vf7P71H/5zfqf/N5u/58Xf+x0op6u67/YuO9CMPlYYG3pyru
lrG9hYE2oQ5nyZI9M+bI3AwLhbQdfcvbsIH8ZlWS3x1m8dJcX+Ol5eMdb8sElsjQt83d3XeH
tFl/8+YNLDA145iFbTB8bJY/OCZg9+Z4a02iORZcJKYKOU0q5CHX3hBfeG9Orx0WraiW04Tu
fDHVE2uPsZBeOjZuRhYXC2zv6SzB9OLNRKfOn9rqbYSB+R5tddm3rAB35f9+q7k+/9vBXrDR
bO7X8/z/HrAx/9Og+HoFWGHdOAXcwTZwXQN261QD8PN5ssTrZzru83Dj11H7qnF2VKBvXVkZ
jIZ09pfZNB0VrlhEh3uPAXuQAEWFuIt1He89Psxc8yIifv2u3O1uHRUKVXdhc5H7vM17Xpca
jUTmY5BtGyJ/GVqYoJiDgjw53mJYeELHx94qmF9F2MO54JpXKCO+ChjJ2KrhJlnUBBvK2X0d
VIpbutbRSX5yLmkVtzIqicHiVmc0NjhWtXvtNKSWbAmvSxifnunG2ViZDkZdZYBCIBWy8G22
qFlU9GIUBRm+14nuWTnSw9RvGWOZ/G/s735RB1qtnfX5f7Oxy/O/tfOd8z9dBW7D+z/N/+1n
RfyH+RVchc7FHJP44GCnStkLvZCxY70r4RJt1UB2XeAYEZ3psPADs2ucVGO2E+HKd77kWx9K
riUdWHhJvvGRc8czcXeB+bbAzvnSwQUQU4/+0uqJQe3Mkr2ThCzNkEHAwoUT08FIEPofHBsf
Yox5nq4z33X9S8e7oAXUdogs4kQLFre5UgCN2g3NIvBnqUoWZhEscOpp0TZRVeJqnvsf6FXq
Cc/H/RyTODcEfgzuIkPik5Xr2TeUQqmWa2JnENY4cfNLVVBkxiWpKmipvUT1vpE2kBhq+9Zy
gbtVsVdNOSLlNs6JjxghnRCykJ86rrzPJ42TZywRIWCcqjroo57xWtYUwOexNnqldpUuHJ/h
SwV6mqJgKNH433HLD7/9JuuI9/QpyMMu/j8D5c1YU3QdRhryUwfjvorUyE6Th4aq6BiEw05/
0lWHJxIcTwwYjgzoqwPVQDRjJHEpX5LBqIfsBorWOcUB+ZivOFxmTzWGJK830kCGsawZamfS
lzUYT7TxSFeALKFDir6sDpRuDeWjTFBeKUMDWeqncr+/0TTk1xkNDU1FLUeaDscK6ikf9xUh
Ck3tqhodeyDH5IksHnbQX6gibrD1sdJR6UF5o6BFsnYmJVx15R8T+q1I7kNXHsgnaGD5S78g
u6xnULHORFMGSIjuAH1yrBuqMTEUOBmNuuRx3Ihqr9SOoh9Cf0Rz0IMJHW92ZUOWxIwgE/QY
IiD28URXue/UoaFo2mRMP7dV4HT0Gr2DespI3OVOHg25weimkXYm5oJ8wWdBgtenCr7RyLPc
YzI5RUfPdYwsGkpERxoZS2GonPTVE2XYUZAjvh8Rn9eqrlRw2lSdUFQh+rWMcifccJos1Ew8
ZuJV4pMKKmknd1+ppHyCjoGgq0nQcNd1ThPHJ3FPrYPDLkXaYRZa7jLiaYjPVFcwbZKci/xZ
fEklijCvJyCNYh2MGHLEZObJj5sePxRscT+wdG3KfzinsoqJGWDVQtZmxGsGVmMvpkz3Z1hE
aS8V+C4+sIgiizk8odm/CTFCKsxxZxG4DrOlVFxS6WEc+v9k2MghyrXiz439MRn6sYh7leLq
59ifsYNwnfPa/EWxiMpB9icbWlpj+nFhafEX0zka5OK+6hlUDq9hW5a/9DaiSnx/l/1LdDfI
09+HbkH9qxfZ/2FIm9ZvKeOO/m+/udta9X8Nfv8D+7/9vP/7HpD3f3n/l/d/ef+X9395//e7
+r9SEAR0F2/T/bwHNIThnG6SFAv4AEf8FSfwA+aVsYPjt1T4uyNx6wKRb7/tw8ktK+bkbeA/
xtEYCmZh6IfEqUIXKfiZ/jL0oI7Pn1H8bRxxWtHBnNGGO0uJfiSCxp0LErAJk67z1e/WXTC5
Q3HCczFq+NgGU5KvjcPi5+I9e21SWrTOuIKH4hKQ+C6uXBGXIj32mcet4C8xdGP+Cw3/VQVd
QbJYdFjMeCVkuKBMQ3Gnp0xy0F7+U72uTzUqa7pxb+9cY7bJS7fNbqpOsIwJGad0pQpWBm3K
7x5AarvQBz59SrxNVGjbiiSpmlM6cxUjPQ0ZdO+iE1hTfnmpM+qLwfF4vLb/Dges1f+9xptx
HF43fXXPIrldt5rl+81JyvShCl2wOA2fcvqw+mU9HajcR4sspwqpAdUka13fMl16h4oVV1rh
p+cnitH9tuAqo0BpTVNJtN3eBqyz9iraqfoOZb2q8vt5M4eFX40vRJ3yFV7tqYomrdg8xMEP
mnNq6UQZiJKCSupnUnBVtQjhCKqNu5XIcnigGhG2j9achAkx/AJEpgaIWzvt4lfucH6BXRLC
MpVufRFvgwhNoQbtviIE9g0R9TtEdKgtVIYnyn2lrAgwWmmFTy73JLdUbxGM8VgoZt7cLPDX
T0NuL+XZSr5xNdhYzG8s5k9o5T7iMZzRdRV12RWHcmGtzfU6QzSrFY0H58pCIf5zfoqTQw45
5JBDDjnkkEMOOeSQQw455JBDDjnkkEMOOeSQQw455PA1+C+0l6YVAFAAAA==
--------------080308070009060802010907--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 16:45:18 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 24B5337B401
for <freebsd-net@FreeBSD.org>; Wed, 16 Oct 2002 16:45:17 -0700 (PDT)
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5E61543E42
for <freebsd-net@FreeBSD.org>; Wed, 16 Oct 2002 16:45:16 -0700 (PDT)
(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA64434;
Wed, 16 Oct 2002 16:43:25 -0700 (PDT)
Received: from arch20m.dellroad.org (localhost [127.0.0.1])
by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9GNhPON008141;
Wed, 16 Oct 2002 16:43:25 -0700 (PDT)
(envelope-from archie@arch20m.dellroad.org)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9GNhNQY008140;
Wed, 16 Oct 2002 16:43:23 -0700 (PDT)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200210162343.g9GNhNQY008140@arch20m.dellroad.org>
Subject: Re: mpd - Radius
In-Reply-To: <3DADD157.5060709@inode.at> "from Michael Bretterklieber at Oct
16, 2002 10:51:35 pm"
To: Michael Bretterklieber <mbretter@inode.at>
Date: Wed, 16 Oct 2002 16:43:23 -0700 (PDT)
Cc: freebsd-net@FreeBSD.org
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Michael Bretterklieber writes:
> Now I got pap-radius-auth with mpd to work :-)
Cool!
You may want to contact Brendan Bank <brendan@gnarst.net> because he's
also working on mpd+RADIUS.
It would be nice if you two could coordinate and maybe review
each other's code...
> I made it now with a static define. The next step will be to add the
> appropriate config-param for mpd.conf.
>
> Are there any hints, a small howto would be great?
> Something like:
> - naming conventions of param
> - where to add param
> - how to access param
Probably these should be bundle-level commands, right? You can
use the examples that already exist as a starting point.
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 17:15:12 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id A34CA37B401
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 17:15:11 -0700 (PDT)
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by mx1.FreeBSD.org (Postfix) with ESMTP id 0C8C943E88
for <freebsd-net@FreeBSD.ORG>; Wed, 16 Oct 2002 17:15:11 -0700 (PDT)
(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA64737;
Wed, 16 Oct 2002 17:02:00 -0700 (PDT)
Received: from arch20m.dellroad.org (localhost [127.0.0.1])
by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9H01xON008366;
Wed, 16 Oct 2002 17:01:59 -0700 (PDT)
(envelope-from archie@arch20m.dellroad.org)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9H01xOU008365;
Wed, 16 Oct 2002 17:01:59 -0700 (PDT)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200210170001.g9H01xOU008365@arch20m.dellroad.org>
Subject: Re: MPD PPTP tunneling intermittantly fails
In-Reply-To: <AEEMJFAIHDPJNCAKCHHBIEJBCHAA.leonardc@cs.berkeley.edu>
"from Leonard Chung at Oct 16, 2002 02:30:50 am"
To: Leonard Chung <leonardc@cs.berkeley.edu>
Date: Wed, 16 Oct 2002 17:01:59 -0700 (PDT)
Cc: freebsd-net@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Leonard Chung writes:
> I'm just using Windows clients, so there are no OS X clients.
>
> Here's the ngctl output:
>
> chung# ngctl msg ng0:inet.ppp.link0 getstats
> Rec'd response "getstats" (3) from "ng0:inet.ppp.link0":
> Args: { xmitPackets=1967 xmitOctets=209321 xmitLoneAcks=395 xmitDrops=345
> recvPackets=1590 recvOctets=248518 recvAckTimeouts=55 }
That doesn't look so good. But it doesn't look "crazy" from the
netgraph side, just like a lot of packets are being dropped.
There must be something specific about your setup that causes this.
You're using 4.6.2? Try applying all of the patches in sys/netgraph
that are in 4.7-REL that you don't have in 4.6.2... ?
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 17:54: 2 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B947E37B401
for <net@freebsd.org>; Wed, 16 Oct 2002 17:53:59 -0700 (PDT)
Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5C6CA43E6A
for <net@freebsd.org>; Wed, 16 Oct 2002 17:53:59 -0700 (PDT)
(envelope-from kelly@alicia.nttmcl.com)
Received: from alicia.nttmcl.com (localhost [127.0.0.1])
by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id g9H0s9vm012618
for <net@freebsd.org>; Wed, 16 Oct 2002 17:54:09 -0700 (PDT)
(envelope-from kelly@alicia.nttmcl.com)
Received: from localhost (kelly@localhost)
by alicia.nttmcl.com (8.12.5/8.12.5/Submit) with ESMTP id g9H0s99m012615
for <net@freebsd.org>; Wed, 16 Oct 2002 17:54:09 -0700 (PDT)
Date: Wed, 16 Oct 2002 17:54:09 -0700 (PDT)
From: Kelly Yancey <kelly@nttmcl.com>
To: net@freebsd.org
Subject: Patch for review: only report protocol data via EVFILT_READ filter
Message-ID: <20021016172902.E11940-200000@alicia.nttmcl.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-756964737-1034816049=:11940"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--0-756964737-1034816049=:11940
Content-Type: TEXT/PLAIN; charset=US-ASCII
Currently, the value returned in a kevent's data member by the
EVFILT_READ filter is "number of bytes in the socket buffer" which
includes control and out-of-band data. However, this isn't particularly
useful as any read(), readv(), or readmsg() for the amount of data
reported may block if there is any non-protocol data in the buffer. And
being that there is no way for userland applications to determine if, and
if so how much, non-protocol data is in the buffer, the reported value
cannot be trusted for anything useful.
PR 30634 touches on this issue; UDP sockets are particularly visible
examples since they always include 16 bytes of address information in
addition to the datagram received. However, from reading the code it
would appear that OOB data can cause a similar problem for TCP sockets.
It seems that the overriding issue is that the read* API takes the
number of bytes of protocol data to read whereas kevent() reports the
total number of bytes available (protocol or administrative). The
attached patch, which I would appreciate your comments on, modifies
kevent() to report just the number of bytes of protocol data.
As an aside, it appears that the FIONREAD ioctl (sys_socket.c:soo_ioctl)
and stat(2) on a socket (sys_socket.c:soo_stat) also return the total
number of bytes (protocol data other otherwise) in the socket buffer.
For similar reasons as described above, I suspect that these should be
also modified to return just the number of bytes of actual data. Unless
someone knows of an explicit example otherwise, I don't think changing the
value reported via these interfaces would break any existing applications
as they are probably expecting the new behaviour anyway.
Thanks,
Kelly
(P.S. I've already sent a version of this patch, made against -stable,
to Jonathan, but I haven't heard anything from him in almost a week)
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
--0-756964737-1034816049=:11940
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="fix-pr30634.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <20021016175409.M11940@alicia.nttmcl.com>
Content-Description:
Content-Disposition: attachment; filename="fix-pr30634.diff"
SW5kZXg6IHN5cy9zb2NrZXR2YXIuaA0KPT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9zeXMvc29ja2V0dmFy
Lmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjk0DQpkaWZmIC11IC1wIC1y
MS45NCBzb2NrZXR2YXIuaA0KLS0tIHN5cy9zb2NrZXR2YXIuaAkxNyBBdWcg
MjAwMiAwMjozNjoxNiAtMDAwMAkxLjk0DQorKysgc3lzL3NvY2tldHZhci5o
CTE2IE9jdCAyMDAyIDIxOjM0OjEzIC0wMDAwDQpAQCAtMTA1LDYgKzEwNSw3
IEBAIHN0cnVjdCBzb2NrZXQgew0KIAkJdV9pbnQJc2JfaGl3YXQ7CS8qIG1h
eCBhY3R1YWwgY2hhciBjb3VudCAqLw0KIAkJdV9pbnQJc2JfbWJjbnQ7CS8q
IGNoYXJzIG9mIG1idWZzIHVzZWQgKi8NCiAJCXVfaW50CXNiX21ibWF4Owkv
KiBtYXggY2hhcnMgb2YgbWJ1ZnMgdG8gdXNlICovDQorCQl1X2ludAlzYl9j
dGw7CQkvKiBub24tZGF0YSBjaGFycyBpbiBidWZmZXIgKi8NCiAJCWludAlz
Yl9sb3dhdDsJLyogbG93IHdhdGVyIG1hcmsgKi8NCiAJCWludAlzYl90aW1l
bzsJLyogdGltZW91dCBmb3IgcmVhZC93cml0ZSAqLw0KIAkJc2hvcnQJc2Jf
ZmxhZ3M7CS8qIGZsYWdzLCBzZWUgYmVsb3cgKi8NCkBAIC0yMjcsNiArMjI4
LDggQEAgc3RydWN0IHhzb2NrZXQgew0KIC8qIGFkanVzdCBjb3VudGVycyBp
biBzYiByZWZsZWN0aW5nIGFsbG9jYXRpb24gb2YgbSAqLw0KICNkZWZpbmUJ
c2JhbGxvYyhzYiwgbSkgeyBcDQogCShzYiktPnNiX2NjICs9IChtKS0+bV9s
ZW47IFwNCisJaWYgKChtKS0+bV90eXBlICE9IE1UX0RBVEEpIFwNCisJCShz
YiktPnNiX2N0bCArPSAobSktPm1fbGVuOyBcDQogCShzYiktPnNiX21iY250
ICs9IE1TSVpFOyBcDQogCWlmICgobSktPm1fZmxhZ3MgJiBNX0VYVCkgXA0K
IAkJKHNiKS0+c2JfbWJjbnQgKz0gKG0pLT5tX2V4dC5leHRfc2l6ZTsgXA0K
QEAgLTIzNSw2ICsyMzgsOCBAQCBzdHJ1Y3QgeHNvY2tldCB7DQogLyogYWRq
dXN0IGNvdW50ZXJzIGluIHNiIHJlZmxlY3RpbmcgZnJlZWluZyBvZiBtICov
DQogI2RlZmluZQlzYmZyZWUoc2IsIG0pIHsgXA0KIAkoc2IpLT5zYl9jYyAt
PSAobSktPm1fbGVuOyBcDQorCWlmICgobSktPm1fdHlwZSAhPSBNVF9EQVRB
KSBcDQorCQkoc2IpLT5zYl9jdGwgLT0gKG0pLT5tX2xlbjsgXA0KIAkoc2Ip
LT5zYl9tYmNudCAtPSBNU0laRTsgXA0KIAlpZiAoKG0pLT5tX2ZsYWdzICYg
TV9FWFQpIFwNCiAJCShzYiktPnNiX21iY250IC09IChtKS0+bV9leHQuZXh0
X3NpemU7IFwNCkluZGV4OiBrZXJuL3VpcGNfc29ja2V0LmMNCj09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMv
a2Vybi91aXBjX3NvY2tldC5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4x
MzINCmRpZmYgLXUgLXAgLXIxLjEzMiB1aXBjX3NvY2tldC5jDQotLS0ga2Vy
bi91aXBjX3NvY2tldC5jCTUgT2N0IDIwMDIgMjE6MjM6NDYgLTAwMDAJMS4x
MzINCisrKyBrZXJuL3VpcGNfc29ja2V0LmMJMTYgT2N0IDIwMDIgMjE6MzI6
MDEgLTAwMDANCkBAIC0xNzg1LDYgKzE3ODUsNyBAQCBmaWx0X3NvcmVhZChz
dHJ1Y3Qga25vdGUgKmtuLCBsb25nIGhpbnQpDQogCXN0cnVjdCBzb2NrZXQg
KnNvID0gKHN0cnVjdCBzb2NrZXQgKilrbi0+a25fZnAtPmZfZGF0YTsNCiAN
CiAJa24tPmtuX2RhdGEgPSBzby0+c29fcmN2LnNiX2NjOw0KKwlrbi0+a25f
ZGF0YSAtPSBzby0+c29fcmN2LnNiX2N0bDsNCiAJaWYgKHNvLT5zb19zdGF0
ZSAmIFNTX0NBTlRSQ1ZNT1JFKSB7DQogCQlrbi0+a25fZmxhZ3MgfD0gRVZf
RU9GOw0KIAkJa24tPmtuX2ZmbGFncyA9IHNvLT5zb19lcnJvcjsNCg==
--0-756964737-1034816049=:11940--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 19:18:56 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 828FE37B401
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 19:18:55 -0700 (PDT)
Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101])
by mx1.FreeBSD.org (Postfix) with ESMTP id 86D2543E6E
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 19:18:54 -0700 (PDT)
(envelope-from bsd#nms@otdel-1.org)
Received: by otdel-1.org (CommuniGate Pro PIPE 4.0b9)
with PIPE id 2170121; Thu, 17 Oct 2002 06:18:53 +0400
Date: Thu, 17 Oct 2002 06:18:49 +0400
From: Nikolai Saoukh <bsd#nms@otdel-1.org>
To: freebsd-net@FreeBSD.ORG
Subject: Re: MPD PPTP tunneling intermittantly fails
Message-ID: <20021017021849.GA1354@otdel1.org>
Mail-Followup-To: freebsd-net@FreeBSD.ORG
References: <AEEMJFAIHDPJNCAKCHHBIEJBCHAA.leonardc@cs.berkeley.edu> <200210170001.g9H01xOU008365@arch20m.dellroad.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200210170001.g9H01xOU008365@arch20m.dellroad.org>
User-Agent: Mutt/1.5.1i
X-Mailer: CommuniGate Pro CLI mailer
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, Oct 16, 2002 at 05:01:59PM -0700, Archie Cobbs wrote:
| That doesn't look so good. But it doesn't look "crazy" from the
| netgraph side, just like a lot of packets are being dropped.
| There must be something specific about your setup that causes this.
Specific is MPPE. I have the same problem here.
I am digging the problem at slow pace. So far
I discoverd that mpd set mtu on interface too early,
thus without MPPE header size. But the real problem,
is the huge amount of CCP Reset Requests from win client.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 19:51:45 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id AAB4237B401
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 19:51:44 -0700 (PDT)
Received: from dominion.1my.net (dominion.1my.net [202.56.152.11])
by mx1.FreeBSD.org (Postfix) with ESMTP id 90F5743E65
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 19:51:43 -0700 (PDT)
(envelope-from mikechoo@opensos.net)
Received: from lifebook ([219.93.215.151])
(authenticated bits=0)
by dominion.1my.net (8.12.5/8.12.5) with ESMTP id g9GFLpGK066727
for <freebsd-net@freebsd.org>; Wed, 16 Oct 2002 23:21:55 +0800 (MYT)
(envelope-from mikechoo@opensos.net)
Date: Wed, 16 Oct 2002 23:21:40 +0800
From: Michael Choo <mikechoo@opensos.net>
X-Mailer: The Bat! (v1.60) Personal
Reply-To: Michael Choo <mikechoo@opensos.net>
Organization: OpenSOS Sdn Bhd
X-Priority: 3 (Normal)
Message-ID: <1319077331.20021016232140@opensos.net>
To: freebsd-net@freebsd.org
Subject: Realtek 8150 support
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi,
Are there any development on a Realtek 8150 USB NIC driver?
Been searching all over and all I can find are Linux drivers.
--
Best regards,
Michael mailto:mikechoo@opensos.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 23:14:35 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id DAF2B37B401
for <freebsd-net@FreeBSD.org>; Wed, 16 Oct 2002 23:14:32 -0700 (PDT)
Received: from smtp.inode.at (smtp-02.inode.at [62.99.194.4])
by mx1.FreeBSD.org (Postfix) with ESMTP id 6CE6943E4A
for <freebsd-net@FreeBSD.org>; Wed, 16 Oct 2002 23:14:27 -0700 (PDT)
(envelope-from mbretter@inode.at)
Received: from line-c-62.adsl-dynamic.inode.at ([62.99.151.62]:1037 helo=inode.at)
by smtp.inode.at with esmtp (Exim 4.05)
id 1823r8-00076d-00; Thu, 17 Oct 2002 08:10:02 +0200
Message-ID: <3DAE5495.1040409@inode.at>
Date: Thu, 17 Oct 2002 08:11:33 +0200
From: Michael Bretterklieber <mbretter@inode.at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.1) Gecko/20020826
X-Accept-Language: de-at, de-de, de, en, en-us
MIME-Version: 1.0
To: Archie Cobbs <archie@dellroad.org>
Cc: freebsd-net@FreeBSD.org, brendan@gnarst.net
Subject: Re: mpd - Radius
References: <200210162343.g9GNhNQY008140@arch20m.dellroad.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi,
Archie Cobbs schrieb:
> Michael Bretterklieber writes:
>
>>Now I got pap-radius-auth with mpd to work :-)
>
>
> Cool!
>
> You may want to contact Brendan Bank <brendan@gnarst.net> because he's
> also working on mpd+RADIUS.
>
> It would be nice if you two could coordinate and maybe review
> each other's code...
>
>
>>I made it now with a static define. The next step will be to add the
>>appropriate config-param for mpd.conf.
>>
>>Are there any hints, a small howto would be great?
>>Something like:
>>- naming conventions of param
>>- where to add param
>>- how to access param
>
>
> Probably these should be bundle-level commands, right? You can
> use the examples that already exist as a starting point.
yes. I implemented it at bundle level.
But I think it will better to have something like this in the mpd.conf:
- gobal switch to enable radius support.
- switches for the different layers (link, bundle) where radius can be
used (because Radius can more the Authentication)
bye,
>
> Cheers,
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * Packet Design * http://www.packetdesign.com
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
>
--
--
--------------------------------------
E-mail: Michael.Bretterklieber@jawa.at
----------------------------
JAWA Management Software GmbH
Liebenauer Hauptstr. 200
A-8041 GRAZ
Tel: ++43-(0)316-403274-12
Fax: ++43-(0)316-403274-10
GSM: ++43-(0)676-93 96 698
homepage: http://www.jawa.at
--------- privat -----------
E-mail: mbretter@inode.at
homepage: http://www.inode.at/mbretter
--------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed Oct 16 23:59:11 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id BAE1537B401; Wed, 16 Oct 2002 23:59:09 -0700 (PDT)
Received: from erg.verweg.com (erg.verweg.com [217.77.141.129])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 7CC4D43E65; Wed, 16 Oct 2002 23:59:08 -0700 (PDT)
(envelope-from ruben@erg.verweg.com)
Received: from erg.verweg.com (erg.verweg.com [217.77.141.129])
by erg.verweg.com (8.12.5/8.12.5) with ESMTP id g9H6x5iV016429
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
Thu, 17 Oct 2002 08:59:05 +0200 (CEST)
(envelope-from ruben@erg.verweg.com)
Received: (from ruben@localhost)
by erg.verweg.com (8.12.5/8.12.5/Submit) id g9H6x4mR016428;
Thu, 17 Oct 2002 08:59:04 +0200 (CEST)
(envelope-from ruben)
Date: Thu, 17 Oct 2002 08:59:04 +0200
From: Ruben van Staveren <ruben@verweg.com>
To: Marko Zec <zec@tel.fer.hr>
Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org
Subject: Re: RFC: BSD network stack virtualization
Message-ID: <20021017065904.GA16310@erg.verweg.com>
References: <3DADD864.15757E4E@tel.fer.hr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DADD864.15757E4E@tel.fer.hr>
X-LeerQuoten: http://leerquoten.verweg.com
Organisation: Verweg Dot Com
X-message: Zeker Outlook ?
User-Agent: Mutt/1.5.1i
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Spam-Status: No, hits=-9.9 required=5.0
tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,
USER_AGENT_MUTT
version=2.41
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Isn't this something that can overcome the current shortcomings of jail(2) ?
(the no other stacks/no raw sockets problem)
- Ruben
--
,-_ .----------------------------------------------------------------.
/() ) | Ruben van Staveren http://ruben.is.verweg.com/ |_o
(__ ( |Men are from Mars. Women are from Venus. Computers are from hell| #>
=/ () `----------------------------------------------------------------' 4
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 1: 8:36 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id C167D37B401
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 01:08:34 -0700 (PDT)
Received: from web10412.mail.yahoo.com (web10412.mail.yahoo.com [216.136.128.126])
by mx1.FreeBSD.org (Postfix) with SMTP id 4C3C343E88
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 01:08:34 -0700 (PDT)
(envelope-from opolyakov@yahoo.com)
Message-ID: <20021017080834.24087.qmail@web10412.mail.yahoo.com>
Received: from [12.236.91.184] by web10412.mail.yahoo.com via HTTP; Thu, 17 Oct 2002 01:08:34 PDT
Date: Thu, 17 Oct 2002 01:08:34 -0700 (PDT)
From: Oleg Polyakov <opolyakov@yahoo.com>
Subject: Re: delayed ACK
To: freebsd-net@FreeBSD.ORG
In-Reply-To: <3DAC9D37.7060701@expertcity.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
--- Steve Francis <steve@expertcity.com> wrote:
> Lars Eggert wrote:
>
> >Paul Herman wrote:
> >
> >
> >>Not true. Although some bugs have been fixed in 4.3, FreeBSD's
> >>delayed ACKs will still degrade your performance dramatically in
> >>some cases.
> >>
> >>
> >
> >I'm sorry, but such statements without a packet trace that exhibits the
> >problem are just not useful.
> >
> >Lars
> >
> >
> He's probably referring to poorly behaved windows clients, on certain
> applications, if you leave net.inet.tcp.slowstart_flightsize at default.
>
> Incidentally, why are not the defaults on
> net.inet.tcp.slowstart_flightsize higher?
> RFC2414 seems to indicate it should be higher. Solaris in version 8 and
> later default to 4 for this value.
As you may know there is RFC draft which will replace RFC2414
(draft-ietf-tsvwg-initwin-04).
It also require to decrease cwnd in case we decreasing MSS because of
PMTU Discovery to prevent small packet bursts.
I've got patches, they are pretty trvial - somebody with commit bit has
to take a look and put them in a tree.
----
Oleg
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 1:56:22 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D8DA937B401
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 01:56:21 -0700 (PDT)
Received: from helios.earthmagic.org (helios.earthmagic.org [198.78.66.220])
by mx1.FreeBSD.org (Postfix) with ESMTP id 1BE6C43E7B
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 01:56:21 -0700 (PDT)
(envelope-from lonewolf-freebsd@earthmagic.org)
Received: (qmail 65902 invoked from network); 17 Oct 2002 08:56:16 -0000
Received: from ppp751.vic.padsl.internode.on.net (HELO Lara.earthmagic.org) (eo-lonewolf@150.101.210.238)
by helios.earthmagic.org with DES-CBC3-SHA encrypted SMTP; 17 Oct 2002 08:56:16 -0000
Message-Id: <5.1.0.14.2.20021017184945.02958380@helios.earthmagic.org>
X-Sender: eo-lonewolf@helios.earthmagic.org (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 17 Oct 2002 18:55:26 +1000
To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org
From: "J. 'LoneWolf' Mattsson" <lonewolf-freebsd@earthmagic.org>
Subject: Re: RFC: BSD network stack virtualization
In-Reply-To: <20021017065904.GA16310@erg.verweg.com>
References: <3DADD864.15757E4E@tel.fer.hr>
<3DADD864.15757E4E@tel.fer.hr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
At 08:59 17/10/2002 +0200, Ruben van Staveren wrote:
>Isn't this something that can overcome the current shortcomings of jail(2) ?
>(the no other stacks/no raw sockets problem)
I've been tempted at looking into jail-ifying raw sockets as well, but time
has precluded me from doing so (and from tracking -stable regularly). I
must say that this virtualization sounds very promising in making the jail
even more useful! And of course all the other avenues that are made
possible with this. I guess the main/traditional question to ask first
would be:
This change adds abstraction, therefore it probably reduces performance -
by how much?
Thanks for the initiative Marko, I hope this will be seriously considered
for inclusion (barring any negative side-effects of it). And I hope I'll
have a chance to give it a test-drive soon! :)
Cheers,
/Johny
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 3:20: 8 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 2D89537B401
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 03:20:07 -0700 (PDT)
Received: from firmlai.bal.ru (firmlai.bal.ru [195.42.138.2])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8ED1943E6A
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 03:20:00 -0700 (PDT)
(envelope-from oleg@firmlai.bal.ru)
Received: from oleg.bal.ru (oleg.bal.ru [195.42.138.3])
by firmlai.bal.ru (8.10.0.Beta6/oleg@bal.ru) with ESMTP id g9HAJl661870
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 14:19:49 +0400 (MSD)
Date: Thu, 17 Oct 2002 14:20:04 +0400
From: Oleg Borowkov <oleg@firmlai.bal.ru>
X-Mailer: The Bat! (v1.61)
Reply-To: Oleg Borowkov <oleg@firmlai.bal.ru>
Organization: LAI Firm
X-Priority: 3 (Normal)
Message-ID: <1317582544.20021017142004@firmlai.bal.ru>
Disposition-Notification-To: oleg@firmlai.bal.ru
To: freebsd-net@FreeBSD.ORG
Subject: trouble with wireless link
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi freebsd-net!
Help me fix trouble with wireless link:
/sbin/ifconfig wi0 inet 192.168.1.1/24 channel 7 nwkey secret ssid mynet
/var/log/messages:
Oct 17 16:57:28 dom1 /kernel: pccard: card inserted, slot 0
Oct 17 16:57:28 dom1 pccardd[41]: Card "Lucent Technologies"("WaveLAN/IEEE") [Ve
rsion 01.01] [] matched "Lucent Technologies" ("WaveLAN/IEEE") [(null)] [(null)]
Oct 17 16:57:33 dom1 /kernel: wi0 at port 0x240-0x27f irq 3 slot 0 on pccard0
Oct 17 16:57:33 dom1 /kernel: wi0: 802.11 address: 00:02:2d:3a:d3:97
Oct 17 16:57:33 dom1 /kernel: wi0: using Lucent Technologies, WaveLAN/IEEE
Oct 17 16:57:33 dom1 /kernel: wi0: Lucent Firmware: Station 8.10.01
Oct 17 16:57:33 dom1 pccardd[41]: wi0: Lucent Technologies (WaveLAN/IEEE) inserted.
link ~30km long:
# ping -c3 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=128 time=7.465 ms
64 bytes from 192.168.1.2: icmp_seq=0 ttl=128 time=18.968 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=0 ttl=128 time=28.423 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=0 ttl=128 time=30.504 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=1 ttl=128 time=10.231 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=128 time=32.439 ms (DUP!)
64 bytes from 192.168.1.2: icmp_seq=2 ttl=128 time=9.234 ms
--- 192.168.1.2 ping statistics ---
3 packets transmitted, 3 packets received, +4 duplicates, 0% packet loss
round-trip min/avg/max/stddev = 7.465/19.609/32.439/10.032 ms
AP - freebsd 4.6 + linksys wmp11
Client - freebsd 4.6 + orinoco silver
all work fine, but duplicated paket's degrade speed... help me fix
this...
Big thnk
--
Oleg
oleg@firmlai.bal.ru
icq:34687903
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 4: 2:20 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 9894437B401; Thu, 17 Oct 2002 04:02:18 -0700 (PDT)
Received: from premijer.tel.fer.hr (premijer.tel.fer.hr [161.53.19.221])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 3D55D43E97; Thu, 17 Oct 2002 04:02:13 -0700 (PDT)
(envelope-from zec@tel.fer.hr)
Received: from tel.fer.hr (zec-laptop.tel.fer.hr [161.53.19.8])
by premijer.tel.fer.hr (Postfix) with ESMTP
id F1F681380; Thu, 17 Oct 2002 13:01:44 +0200 (MET DST)
Message-ID: <3DAE98B4.4058023A@tel.fer.hr>
Date: Thu, 17 Oct 2002 13:02:13 +0200
From: Marko Zec <zec@tel.fer.hr>
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "J. 'LoneWolf' Mattsson" <lonewolf-freebsd@earthmagic.org>
Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org
Subject: Re: RFC: BSD network stack virtualization
References: <3DADD864.15757E4E@tel.fer.hr>
<3DADD864.15757E4E@tel.fer.hr> <5.1.0.14.2.20021017184945.02958380@helios.earthmagic.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
"J. 'LoneWolf' Mattsson" wrote:
> At 08:59 17/10/2002 +0200, Ruben van Staveren wrote:
> >Isn't this something that can overcome the current shortcomings of jail(2) ?
> >(the no other stacks/no raw sockets problem)
It should be possible even to run multiple jails within each virtual image, if
one wishes to do so :)
Actually, my code reuses the jail framework for providing separation (hiding)
between the user processes, therefore the behavior in that area will be very
similar. Everything else done on the networking layer is free of "jail" legacy,
as my concept is completely different: providing multiple truly independent
network stacks, instead of hiding parts of the monolithic one, which was the
approach taken by jail implementation.
An additional goodie is the introduction of soft limit option on average CPU
usage per each virtual image. This can be very useful in virtual hosting
applications, to prevent starving of CPU resources from runaway or malicious
processes running in a single virtual image.
> I've been tempted at looking into jail-ifying raw sockets as well, but time
> has precluded me from doing so (and from tracking -stable regularly). I
> must say that this virtualization sounds very promising in making the jail
> even more useful! And of course all the other avenues that are made
> possible with this. I guess the main/traditional question to ask first
> would be:
> This change adds abstraction, therefore it probably reduces performance -
> by how much?
In most parts of the code the virtualization is achieved via introduction of a
single additional level of indirection for all virtualized symbols/variables,
which are now contained in the new struct vimage, unique for each virtual image.
Therefore the calls to most of the networking functions within the kernel had to
be extended with an additional argument, which passes the pointer to the current
vimage struct.
This additional overhead shouldn't present a to significant problem, particularly
not for the current 1+ GHz CPUs with fast memory. Some preliminary tests (netperf
on TCP flows) show that the performance penalty is generally minimal, somewhere
around 1-2%, compared to normal maximum throughputs (not limited by the media
speed). As I perform more systematic and accurate measurements, I'll post them on
my web page.
Best regards,
Marko
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 5: 7:34 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D522337B401
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 05:07:33 -0700 (PDT)
Received: from mail1.ugr.es (mail1.ugr.es [150.214.20.24])
by mx1.FreeBSD.org (Postfix) with ESMTP id 9D1C843E77
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 05:07:25 -0700 (PDT)
(envelope-from fran@ugr.es)
Received: from mail1.ugr.es (localhost [127.0.0.1])
by mail1.ugr.es (8.9.3/8.9.3) with ESMTP id OAA09651
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 14:07:19 +0200 (MEST)
Received: from goliat.ugr.es (goliat.ugr.es [150.214.20.3])
by mail1.ugr.es (8.9.3/8.9.3) with ESMTP id OAA09642
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 14:07:18 +0200 (MEST)
Received: from pcb2bis (pcb2bis.ugr.es [150.214.35.65])
by goliat.ugr.es (8.9.3/8.9.1) with SMTP id OAA17450
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 14:07:16 +0200 (MEST)
Message-ID: <002901c275d5$fe4e8dc0$4123d696@ugr.es>
Reply-To: "Francisco J. Medina Jimenez" <fran@ugr.es>
From: "Francisco J. Medina Jimenez" <fran@ugr.es>
To: <freebsd-net@freebsd.org>
Subject: performance of pptp with mpd
Date: Thu, 17 Oct 2002 14:09:05 +0200
Organization: Servicios de Informatica y Redes de Comunicaciones. Universidad de Granada
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi.
I'm testing mpd 3.9 with FreeBSD 4.6.2. The performance of transfers
using W2k clients is much better than using XP or Win9x (in same
conditions). Are there any parameters to adjust or it's problem of pptp
client implementation?
Thanks in advance.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 5:14:27 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B46CA37B401
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 05:14:25 -0700 (PDT)
Received: from jawa.at (inforum.at [213.229.17.146])
by mx1.FreeBSD.org (Postfix) with ESMTP id C183D43E65
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 05:14:08 -0700 (PDT)
(envelope-from mbretter@inode.at)
Received: (from root@localhost)
by jawa.at (8.11.6/8.11.6) id g9HCDl584238
for freebsd-net@freebsd.org; Thu, 17 Oct 2002 14:13:47 +0200 (CEST)
(envelope-from mbretter@inode.at)
Received: from inode.at (dings.jawa.at [192.168.200.60])
by jawa.at (8.11.6/8.11.6av) with ESMTP id g9HCDj284230
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 14:13:45 +0200 (CEST)
(envelope-from mbretter@inode.at)
Message-ID: <3DAEA97A.4050907@inode.at>
Date: Thu, 17 Oct 2002 14:13:46 +0200
From: Michael Bretterklieber <mbretter@inode.at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.1) Gecko/20020826
X-Accept-Language: de-at, de, en, en-us
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: Re: performance of pptp with mpd
References: <002901c275d5$fe4e8dc0$4123d696@ugr.es>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi,
you can try:
set ccp yes mpp-stateless
or you can try to comment out this line. I had similar problems some
weeks ago with this option.
bye,
Francisco J. Medina Jimenez schrieb:
> Hi.
>
> I'm testing mpd 3.9 with FreeBSD 4.6.2. The performance of transfers
> using W2k clients is much better than using XP or Win9x (in same
> conditions). Are there any parameters to adjust or it's problem of pptp
> client implementation?
>
> Thanks in advance.
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
>
--
------------------------------- ----------------------------------
Michael Bretterklieber - Michael.Bretterklieber@jawa.at
JAWA Management Software GmbH - http://www.jawa.at
Liebenauer Hauptstr. 200 -------------- privat ------------
A-8041 GRAZ GSM: ++43-(0)676-93 96 698
Tel: ++43-(0)316-403274-12 E-mail: mbretter@inode.at
Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter
------------------------------- ----------------------------------
"...the number of UNIX installations has grown to 10, with more expected..."
- Dennis Ritchie and Ken Thompson, June 1972
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 8: 4:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 14F0837B401; Thu, 17 Oct 2002 08:04:59 -0700 (PDT)
Received: from cisco.com (sword.cisco.com [161.44.208.100])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 14D6143E42; Thu, 17 Oct 2002 08:04:58 -0700 (PDT)
(envelope-from sjt@cisco.com)
Received: from sjt-u10.cisco.com (sjt-u10.cisco.com [10.85.30.63])
by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id LAA26633;
Thu, 17 Oct 2002 11:04:56 -0400 (EDT)
Received: (sjt@localhost) by sjt-u10.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id LAA15828; Thu, 17 Oct 2002 11:04:56 -0400 (EDT)
Date: Thu, 17 Oct 2002 11:04:56 -0400
From: Steve Tremblett <sjt@cisco.com>
To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org
Subject: Netgraph TCP/IP
Message-ID: <20021017110456.G15035@sjt-u10.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
A while back someone was fishing for a project to take on and someone
suggested a complete TCP/IP implementation in netgraph. I found the
idea interesting and am considering taking a shot at it. My main goal
in all this is to learn as much as possible and at this point I'm just
reading.
While this is a personal educational project, I figure I should propose
it here and solicit comments/thoughts/suggestions on such a venture so
that maybe the results might be usable by someone else.
Thanks
--
Steve Tremblett
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 12: 0:32 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id EBCAA37B401; Thu, 17 Oct 2002 12:00:31 -0700 (PDT)
Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22])
by mx1.FreeBSD.org (Postfix) with ESMTP
id A2F7143E6A; Thu, 17 Oct 2002 12:00:31 -0700 (PDT)
(envelope-from tlambert2@mindspring.com)
Received: from pool0289.cvx22-bradley.dialup.earthlink.net ([209.179.199.34] helo=mindspring.com)
by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
id 182FsZ-0004f7-00; Thu, 17 Oct 2002 12:00:20 -0700
Message-ID: <3DAF087C.7B148341@mindspring.com>
Date: Thu, 17 Oct 2002 11:59:08 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Tremblett <sjt@cisco.com>
Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org
Subject: Re: Netgraph TCP/IP
References: <20021017110456.G15035@sjt-u10.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Steve Tremblett wrote:
> A while back someone was fishing for a project to take on and someone
> suggested a complete TCP/IP implementation in netgraph. I found the
> idea interesting and am considering taking a shot at it. My main goal
> in all this is to learn as much as possible and at this point I'm just
> reading.
>
> While this is a personal educational project, I figure I should propose
> it here and solicit comments/thoughts/suggestions on such a venture so
> that maybe the results might be usable by someone else.
Start with just a TCP implementation, after exposing a raw IP
interface as a netgraph node. This will make your life much
easier. There is a lot of promiscuous knowledge in the code,
both for packets on the way in, and packets on the way out.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 13: 9:16 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id E989537B401; Thu, 17 Oct 2002 13:09:14 -0700 (PDT)
Received: from venus.vincentjardin.net (AVelizy-102-1-4-2.abo.wanadoo.fr [80.11.204.2])
by mx1.FreeBSD.org (Postfix) with ESMTP
id E362C43E42; Thu, 17 Oct 2002 13:09:13 -0700 (PDT)
(envelope-from jardin@venus.vincentjardin.net)
Received: by venus.vincentjardin.net (Postfix, from userid 501)
id E98171503A0; Thu, 17 Oct 2002 22:01:11 +0200 (CEST)
Content-Type: text/plain;
charset="iso-8859-1"
From: Vincent Jardin <vjardin@wanadoo.fr>
To: Terry Lambert <tlambert2@mindspring.com>
Subject: Re: Netgraph TCP/IP
Date: Thu, 17 Oct 2002 22:01:11 +0200
X-Mailer: KMail [version 1.3.1]
References: <20021017110456.G15035@sjt-u10.cisco.com> <3DAF087C.7B148341@mindspring.com>
In-Reply-To: <3DAF087C.7B148341@mindspring.com>
Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20021017200111.E98171503A0@venus.vincentjardin.net>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
I do not think that you need a raw IP netgraph node. Something similar
already exists. Why not use the ng_ksocket in order to open a raw IP socket
under your TCP node ?
Vincent
Le Jeudi 17 Octobre 2002 20:59, vous avez écrit :
> Steve Tremblett wrote:
> > A while back someone was fishing for a project to take on and someone
> > suggested a complete TCP/IP implementation in netgraph. I found the
> > idea interesting and am considering taking a shot at it. My main goal
> > in all this is to learn as much as possible and at this point I'm just
> > reading.
> >
> > While this is a personal educational project, I figure I should propose
> > it here and solicit comments/thoughts/suggestions on such a venture so
> > that maybe the results might be usable by someone else.
>
> Start with just a TCP implementation, after exposing a raw IP
> interface as a netgraph node. This will make your life much
> easier. There is a lot of promiscuous knowledge in the code,
> both for packets on the way in, and packets on the way out.
>
> -- Terry
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 13:11:21 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id A174A37B404
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 13:11:20 -0700 (PDT)
Received: from chimie.u-strasbg.fr (chimie.u-strasbg.fr [130.79.34.77])
by mx1.FreeBSD.org (Postfix) with ESMTP id E86C443E88
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 13:11:19 -0700 (PDT)
(envelope-from guybrand@chimie.u-strasbg.fr)
Received: from localhost (localhost.u-strasbg.fr [127.0.0.1])
by chimie.u-strasbg.fr (Postfix) with ESMTP
id ECE69FB84F; Thu, 17 Oct 2002 22:11:10 +0200 (CEST)
Received: from mathilda.u-strasbg.fr (chimie.u-strasbg.fr [130.79.34.77])
by chimie.u-strasbg.fr (Postfix) with ESMTP id 4B750FB849
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 22:11:10 +0200 (CEST)
Received: by mathilda.u-strasbg.fr (Postfix, from userid 1001)
id 8B1F634501; Thu, 17 Oct 2002 22:11:09 +0200 (CEST)
Date: Thu, 17 Oct 2002 22:11:09 +0200
From: Guy Brand <guybrand@chimie.u-strasbg.fr>
To: freebsd-net@FreeBSD.ORG
Subject: No bridge with Ifs and Vlans
Message-ID: <20021017201109.GQ43318@chimie.u-strasbg.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Organization: ISIS ULP, Strasbourg, France
X-Virus-Scanned: by AMaViS snapshot-20010714
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi all,
I'm setting up a 3 NICs bridge using Intel cards under FreeBSD 4.7. The
trunk has traffic with three different VLAN tags (111,222,800). I have
802.1q aware switches behind my two internal interfaces and they should
only get some tagged frames (ipfw use planned to get rid of unwanted
VLAN traffic) :
___ fxp1 --- switch1 of VLAN 111,222,800
/
/
VLANs 111,222,800 ===== em0
\
\___ fxp2 --- switch2 of VLAN 111
After bridging the three interfaces (sysctl), a dump at em0 shows all tagged
frames coming from the trunk but a dump at fxp1 or fxp2 show nothing (dump
with "tcpdump -nle -i..."), bridge dysfunction ? Setting up VLAN interfaces
for VLAN ID 111 :
ifconfig vlan0 vlan 111 vlandev em0
ifconfig vlan1 vlan 111 vlandev fxp1
ifconfig vlan2 vlan 111 vlandev fxp2
and bridging them (vlanX) together doesn't change anything.
What have I missed ?
--
bug
sleepless
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 13:48:25 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 617DB37B401; Thu, 17 Oct 2002 13:48:23 -0700 (PDT)
Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62])
by mx1.FreeBSD.org (Postfix) with ESMTP
id E4D9743E8A; Thu, 17 Oct 2002 13:48:22 -0700 (PDT)
(envelope-from tlambert2@mindspring.com)
Received: from pool0289.cvx22-bradley.dialup.earthlink.net ([209.179.199.34] helo=mindspring.com)
by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
id 182HZ5-0002TA-00; Thu, 17 Oct 2002 13:48:19 -0700
Message-ID: <3DAF21CA.60031059@mindspring.com>
Date: Thu, 17 Oct 2002 13:47:06 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Vincent Jardin <vjardin@wanadoo.fr>
Cc: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org
Subject: Re: Netgraph TCP/IP
References: <20021017110456.G15035@sjt-u10.cisco.com> <3DAF087C.7B148341@mindspring.com> <20021017200111.E98171503A0@venus.vincentjardin.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Vincent Jardin wrote:
> I do not think that you need a raw IP netgraph node. Something similar
> already exists. Why not use the ng_ksocket in order to open a raw IP socket
> under your TCP node ?
Because the packet will never get to your protocol processing, unless
you turn of standard TCP altogether, and even then, the pr_input will
not do the right thing for chaining the data up to a Netgraph node.
ip_input.c:
...
if (args.next_hop && ip->ip_p == IPPROTO_TCP) {
/* TCP needs IPFORWARD info if available */
struct m_hdr tag;
tag.mh_type = MT_TAG;
tag.mh_flags = PACKET_TAG_IPFORWARD;
tag.mh_data = (caddr_t)args.next_hop;
tag.mh_next = m;
(*inetsw[ip_protox[ip->ip_p]].pr_input)(
(struct mbuf *)&tag, hlen);
} else
(*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen);
...
For this to work, you have to have a pr_input that glues into a
Netgraph entry point, so that IP packets of a specific protocol
type captured by the Netgraph node get passed to it.
There is also the m_pullup() issue of the TCP protocol that is
being passed IP datagrams which may be frags of TCP packets, in
order to get the full TCP header, with options.
Minimally, the approach has to be a seperate TCP stack, which is
given a different protocol number for the purposes of experiment,
so that you can have a duplicate TCP stack on both sides using
the normal mechanism, and replace it on one side with the Netgraph
version equivalen.
See the LRP implementation from Rice University, or the updated
port by Duke University. They both use this approach to run a
stack, and other primitives, in paralell on the system. That is
also why the code, as it sits in their source bases, would take
some work to integrate fully into FreeBSD (license issues aside)
as the default protocol processing path. Actually, it would take
much longer now that the SYN cache and the polling code has
obfuscated things.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 13:55: 9 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id ECD8437B401
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 13:55:08 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id AA95343E97
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 13:55:04 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9HKsuYj077213;
Thu, 17 Oct 2002 23:55:02 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <0be401c2761f$855af670$8c2a40c1@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Lars Eggert" <larse@ISI.EDU>
Cc: "Luigi Rizzo" <rizzo@icir.org>, <freebsd-net@FreeBSD.ORG>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu>
Subject: Re: ENOBUFS
Date: Thu, 17 Oct 2002 23:55:24 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>
> Less :-) Let me tell you tomorrow, don't have the numbers here right now.
I seem to get about 5-6 packets on an interrupt. Is this tunable? At
50kpps the card generates 10k interrupts a second. Sending generates
way less. This is about 300Mbps so with the average packet size of
750 there should be room for more packets on the interface queue
before needing to service an interrupt?
What´s the way to access kernel adapter-structure? Is there an utility
that can view the values there?
>
Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 16:20:13 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 07A5837B401; Thu, 17 Oct 2002 16:20:10 -0700 (PDT)
Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 6534C43E75; Thu, 17 Oct 2002 16:20:09 -0700 (PDT)
(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org ([12.232.206.8])
by sccrmhc02.attbi.com
(InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
id <20021017232008.HORB26432.sccrmhc02.attbi.com@InterJet.elischer.org>;
Thu, 17 Oct 2002 23:20:08 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA03531;
Thu, 17 Oct 2002 16:03:13 -0700 (PDT)
Date: Thu, 17 Oct 2002 16:03:12 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Vincent Jardin <vjardin@wanadoo.fr>, freebsd-net@freebsd.org,
freebsd-hackers@freebsd.org
Subject: Re: Netgraph TCP/IP
In-Reply-To: <3DAF21CA.60031059@mindspring.com>
Message-ID: <Pine.BSF.4.21.0210171450440.2971-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Thu, 17 Oct 2002, Terry Lambert wrote:
> Vincent Jardin wrote:
> > I do not think that you need a raw IP netgraph node. Something similar
> > already exists. Why not use the ng_ksocket in order to open a raw IP socket
> > under your TCP node ?
>
> Because the packet will never get to your protocol processing, unless
> you turn of standard TCP altogether, and even then, the pr_input will
> not do the right thing for chaining the data up to a Netgraph node.
>
> ip_input.c:
> ...
> if (args.next_hop && ip->ip_p == IPPROTO_TCP) {
> /* TCP needs IPFORWARD info if available */
> struct m_hdr tag;
>
> tag.mh_type = MT_TAG;
> tag.mh_flags = PACKET_TAG_IPFORWARD;
> tag.mh_data = (caddr_t)args.next_hop;
> tag.mh_next = m;
>
> (*inetsw[ip_protox[ip->ip_p]].pr_input)(
> (struct mbuf *)&tag, hlen);
> } else
> (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen);
>
> ...
This has been changed with the addition of the new OOB tag metadata
methods committed by sam Leffler a few days ago. This were specifically
designed to co-operate with the netgraph OOB data requirements. I will
be modifying netgraph over the next few weeks (I hope) to use the new
scheme. This will allow seamless flow of metadata between netgaph and
other networking components. (e.g. the 'fwd' info above)
>
> For this to work, you have to have a pr_input that glues into a
> Netgraph entry point, so that IP packets of a specific protocol
> type captured by the Netgraph node get passed to it.
it will all "fall into place" with the new scheme, once I
have converted netgraph to use it.
>
> There is also the m_pullup() issue of the TCP protocol that is
> being passed IP datagrams which may be frags of TCP packets, in
> order to get the full TCP header, with options.
The tcp code should handle this anyway.
>
> Minimally, the approach has to be a seperate TCP stack, which is
> given a different protocol number for the purposes of experiment,
> so that you can have a duplicate TCP stack on both sides using
> the normal mechanism, and replace it on one side with the Netgraph
> version equivalen.
Not necessarily.. if each stack can 'reject' a packet.. ("not mine").
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 16:22:46 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 1273F37B401
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 16:22:45 -0700 (PDT)
Received: from sigbus.com (c-24-126-10-97.we.client2.attbi.com [24.126.10.97])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4E1CC43E6A
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 16:22:44 -0700 (PDT)
(envelope-from henrich@sigbus.com)
Received: (from henrich@localhost)
by sigbus.com (8.11.1/8.11.1) id g9HNMhq90134
for freebsd-net@freebsd.org; Thu, 17 Oct 2002 16:22:43 -0700 (PDT)
(envelope-from henrich)
Date: Thu, 17 Oct 2002 16:22:43 -0700
From: Charles Henrich <henrich@sigbus.com>
To: freebsd-net@freebsd.org
Subject: IPSEC/NAT issues
Message-ID: <20021017162243.B89519@sigbus.com>
Mail-Followup-To: freebsd-net@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Operating-System: FreeBSD 4.2-RELEASE
X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F
X-GPG-Fingerprint: EA4C AB9B 0C38 17C0 AB3F 11DE 41F6 5883 41E7 4F49
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
I apologize for not CC'ing originally!
I have a network/firewall where I want to nat an entire network. However, I
also want nat traffic to one remote host in particular out on the internet to
be IPsec'd as well.
[A] (10.x) [B] (Nat) [C] (Real IP)
I've setup IPsec on both machines, and from either machine (B,C) I can ssh to
the other, with ipsec packets all happening happy as a clam. However if try a
connection from behind the nat box to the remote host (A,C) the key exchange
works fine (between B&C), but then no data flows back and forth. Anyone have
any suggestions on this? Thanks!
-Crh
Charles Henrich henrich@msu.edu
http://www.sigbus.com/~henrich
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 17: 6:57 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 021B237B401
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 17:06:55 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8AAAF43E77
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 17:06:54 -0700 (PDT)
(envelope-from larse@ISI.EDU)
Received: from isi.edu (nik.isi.edu [128.9.168.58])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9I06qC11308;
Thu, 17 Oct 2002 17:06:52 -0700 (PDT)
Message-ID: <3DAF509C.6030002@isi.edu>
Date: Thu, 17 Oct 2002 17:06:52 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Charles Henrich <henrich@sigbus.com>
Cc: freebsd-net@freebsd.org
Subject: Re: IPSEC/NAT issues
References: <20021017162243.B89519@sigbus.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060803050607000600040702"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a cryptographically signed message in MIME format.
--------------ms060803050607000600040702
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Charles Henrich wrote:
>
> I have a network/firewall where I want to nat an entire network. However, I
> also want nat traffic to one remote host in particular out on the internet to
> be IPsec'd as well.
>
> [A] (10.x) [B] (Nat) [C] (Real IP)
There was a thread on -hackers named "VPN Routing through gif (4)
tunnel" a few weeks ago that dealt with a very similar issue.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms060803050607000600040702
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX
DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD
VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE
aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m
xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac
yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl
oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9
VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO
VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh
DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR
1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw
DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN
MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh
cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK
zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa
SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/
r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK
OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy
CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB
ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM
jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV
s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF
MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTAxODAwMDY1MlowIwYJKoZIhvcNAQkEMRYEFL7xv454gZRvFs6NOi2P
QSBap729MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB
naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ
KoZIhvcNAQEBBQAEggEADojR5Y8gGgJI35SXZuR9mG8h0SN1zn0DbvV61DByXUzhDkkDbkPw
/Uw4OKTKQWBib1k2r0XBze+JeW8OSJ6beN9mohsKQbX7IfMtufQKVrozVERa/te9YyLZGb/l
6dM9L6emCJ6edWOBffmpsax2DfTSYwVPJLpeyIn6mVyCWVegc57W6A70rMB0gVQm9Doe3Rnl
hLtkRqkvZ73RUS7xIxug6ClXQObHL7x99w2pF0S01bJE+9vdTTDWPgTMq11X6f3K8uUxuUDA
oeUOEX6UNgk7NN6mjTe0nk1nUm4JCbFANesVutyGeE3slKlXQSvxoBqxC2d446IrFORQXKSr
SwAAAAAAAA==
--------------ms060803050607000600040702--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 17:29:10 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id C3BBD37B401
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 17:29:08 -0700 (PDT)
Received: from sigbus.com (c-24-126-10-97.we.client2.attbi.com [24.126.10.97])
by mx1.FreeBSD.org (Postfix) with ESMTP id ECB6943EA9
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 17:29:07 -0700 (PDT)
(envelope-from henrich@sigbus.com)
Received: (from henrich@localhost)
by sigbus.com (8.11.1/8.11.1) id g9I0T5j92007;
Thu, 17 Oct 2002 17:29:05 -0700 (PDT)
(envelope-from henrich)
Date: Thu, 17 Oct 2002 17:29:05 -0700
From: Charles Henrich <henrich@sigbus.com>
To: Lars Eggert <larse@ISI.EDU>
Cc: freebsd-net@freebsd.org
Subject: Re: IPSEC/NAT issues
Message-ID: <20021017172905.A91625@sigbus.com>
Mail-Followup-To: Lars Eggert <larse@ISI.EDU>,
freebsd-net@freebsd.org
References: <20021017162243.B89519@sigbus.com> <3DAF509C.6030002@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3DAF509C.6030002@isi.edu>; from larse@ISI.EDU on Thu, Oct 17, 2002 at 05:06:52PM -0700
X-Operating-System: FreeBSD 4.2-RELEASE
X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F
X-GPG-Fingerprint: EA4C AB9B 0C38 17C0 AB3F 11DE 41F6 5883 41E7 4F49
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> > I have a network/firewall where I want to nat an entire network. However,
> > I also want nat traffic to one remote host in particular out on the
> > internet to be IPsec'd as well.
> >
> > [A] (10.x) [B] (Nat) [C] (Real IP)
>
> There was a thread on -hackers named "VPN Routing through gif (4) tunnel" a
> few weeks ago that dealt with a very similar issue.
I've looked through those, and it doesnt quite seem to apply? What im doing
is transport mode ESP between my nat gateway and the remote host. this works
properly. in my firewall rules I have
allow esp packets to and from remote host
divert to nat
Now from host A, if I try a connection to IP C, then on the gateway I see
racoon fire up and establish a working IPSEC path between B&C. Further it
looks like it properly encapsulates the packets and forwards them on to host
C, which appears to properly respond to them. On host B, they are unencrypted
and for some reason they do not make a path into natd for un-natting.
The nat daemon does not log any rejections of the packet, however in my kernel
log, I see a
Oct 17 17:23:51 dmz /kernel: Connection attempt to TCP B:3283 from C:22
Is the esp mucking with the in/out interface perhaps?
If Im logged into host B, I can connect to Host C succesfully using the
transport mode connection no problem. Its just this last little bit of natd
not processing the packets. Im thinking im doing something silly. but I cant
see what.
-Crh
Charles Henrich henrich@msu.edu
http://www.sigbus.com/~henrich
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 17:48: 2 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 8193837B401; Thu, 17 Oct 2002 17:47:59 -0700 (PDT)
Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 9F84343E6A; Thu, 17 Oct 2002 17:47:55 -0700 (PDT)
(envelope-from tlambert2@mindspring.com)
Received: from pool0180.cvx40-bradley.dialup.earthlink.net ([216.244.42.180] helo=mindspring.com)
by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
id 182LIr-0000tA-00; Thu, 17 Oct 2002 17:47:49 -0700
Message-ID: <3DAF59ED.D14BD089@mindspring.com>
Date: Thu, 17 Oct 2002 17:46:37 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Julian Elischer <julian@elischer.org>
Cc: Vincent Jardin <vjardin@wanadoo.fr>, freebsd-net@freebsd.org,
freebsd-hackers@freebsd.org
Subject: Re: Netgraph TCP/IP
References: <Pine.BSF.4.21.0210171450440.2971-100000@InterJet.elischer.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Julian Elischer wrote:
> > There is also the m_pullup() issue of the TCP protocol that is
> > being passed IP datagrams which may be frags of TCP packets, in
> > order to get the full TCP header, with options.
>
> The tcp code should handle this anyway.
It should, but it won't. The issue is when you need to make a
decision based on TCP packet contents, but you don't have a
complete packet. The expected behaviour is to call m_pullup.
For a Netgraph version of this, you will either need a context
(there isn't one at that point -- it runs at NETISR), or you
will need to be able to restart tcp_input(). The problem with
that is that it's expensive. Effectively, you almost need to
seperate out the frag code before, and assemble whole packets
before going into the traditional tcp_input(). Lemon has some
good idea in this area; so do I. I've got code here, where I've
moved around some of the operations to delay computations until
fill data is available (which would avoid recomputation).
> > Minimally, the approach has to be a seperate TCP stack, which is
> > given a different protocol number for the purposes of experiment,
> > so that you can have a duplicate TCP stack on both sides using
> > the normal mechanism, and replace it on one side with the Netgraph
> > version equivalen.
>
> Not necessarily.. if each stack can 'reject' a packet.. ("not mine").
The problem with this one is that the packet in this case is TCP.
Ideally, what you would like for the developement case is to be able
to tag particular flows as going to one TCP stack vs. the other; then
by examining the flow tag, youy would be able to decide where to handle
the packet (this also implies moving the frag reassembly to a seperate
"layer"). Then you could flag a flow, and have it dealt with that way.
In FreeBSD's lower level code, though, IP flows aren't really treated
as flows; this is partly an artifact of the routing code, itself, and
partly an artifact if inpcbhash(), which is actually broken. The hash
on iput for a flow vs. output on a flow allocation is also broken;
consider, that you can make a connection on an outbound socket which
is not bound, from a specific source IP address, with no specific
source port, and the source port contention is handled globally, rather
than locally -- thus limiting you to 65535 maximum outbound connections
on a single machine (the number of ports in a single globally contended
IP address space, despite the fact that your source IP was specified).
What this adss up to is that if you want to run stacks in parallel,
they can't share protocol numbers, because the code does not really
distinguish them at the proper layer, but instead, distinguishes them
off-by-one.
This actually makes processing slower overall, as well; consider that
the fast forwarding code does a lookup, which, on a miss, is then
passed up to the TCP to do another lookup, rather than passing the
lookup result as part of the context.
What this basically means is that the hash entries for the values are
not shared, with a single hit-per-flow, and the more "fast forwarding"
you do, the slower normal processing goes. The same happens for the
SYN cache context lookup. It basically really slows down the code, to
not do the hash lower down, and then make the decision on the basis of
the result of identifying the flow.
In a general sense, what you would need to do to do what you suggest is
to pass all packets through all possible stacks, until you hit the
"default" one -- the standard TCP -- and rely on all the other stacks
to not eat the packet.
In practice, this means that every IP protocol, except TCP, ends up
getting rewritten for Netgraph use, until TCP gets rewritten, and
then your lookup is O(N*MAX(1,flow_count/hash_size)), where N is the
number of IP protocols (TCP, UDP, RTP, etc.).
Also, in practice, this still doubles the overhead for things that need
to be pre-decided (flow identification for IP fast forwarding, DSR,
splicing, etc.), and that none of these things can really be safely
implemented as Netgraph modules.
Yeah, it can be made to function correctly that way, but it won't
function quickly.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 17:56: 6 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id EBD2137B401
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 17:56:03 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7B5F143E88
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 17:56:03 -0700 (PDT)
(envelope-from larse@ISI.EDU)
Received: from isi.edu (nik.isi.edu [128.9.168.58])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9I0u2C21626;
Thu, 17 Oct 2002 17:56:02 -0700 (PDT)
Message-ID: <3DAF5C21.6000108@isi.edu>
Date: Thu, 17 Oct 2002 17:56:01 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Charles Henrich <henrich@sigbus.com>
Cc: freebsd-net@freebsd.org
Subject: Re: IPSEC/NAT issues
References: <20021017162243.B89519@sigbus.com> <3DAF509C.6030002@isi.edu> <20021017172905.A91625@sigbus.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090601060501040507040902"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a cryptographically signed message in MIME format.
--------------ms090601060501040507040902
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Charles Henrich wrote:
> The nat daemon does not log any rejections of the packet, however in my kernel
> log, I see a
>
> Oct 17 17:23:51 dmz /kernel: Connection attempt to TCP B:3283 from C:22
Your packets don't seem to reach natd after IPsec inbound processing.
Looks like ipfw processing happens before IPsec (so natd sees the
IPsec'ed packets, but doesn't know anything about them), and gets thems
them after IPsec inbound processing. What you want is a way to do IPsec
first, and then ipfw processing, but I don't know if that can be done.
Try configuring an IPIP tunnel between B and C, and transport-mode IPsec
that. That way, your NAT packets get tunneled, and the tunneled packets
secured. On inbound, security processing comes first, then
decapsulation, then ipfw.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms090601060501040507040902
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX
DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD
VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE
aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m
xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac
yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl
oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9
VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO
VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh
DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR
1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw
DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN
MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh
cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK
zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa
SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/
r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK
OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy
CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB
ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM
jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV
s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF
MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTAxODAwNTYwMlowIwYJKoZIhvcNAQkEMRYEFO35qziQ1Yg/0LZyppEx
Rvrz2Mv4MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB
naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ
KoZIhvcNAQEBBQAEggEAjpeBPwrbYeytluGzq7basyM8Mi2AjApNvDr8n1wAqjjjFpf6AeWr
leatF4j4m3f7bAGSlpnDfuNOSsUMh5/iLtGl6So2z0ntcV4AkyX9UjZIicoH2dSI3l/RLIz7
Rj/nHCLQzm1fOer4HdcjpIgOF+FhGkzPKw3Ca19GUp1ehZqkoFNNCfLkxQXgLr6dorV5iIV1
qGiwIWK1MWHD+yG3uwsOdBpZB9oD2wWR2b3fr+tDhdvL9s7aOkJoOJeCboSaizvBKuvPL95k
KvnDn+3VSMTTEPrMdjmgAZnGWZc5nkpnUZc0SN0/d76cnDVkD5ghr36vri9tSArfamFDWgfH
ewAAAAAAAA==
--------------ms090601060501040507040902--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 20:12: 1 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id EDFDE37B401
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 20:11:59 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id 933C843E6E
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 20:11:59 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9I3BxpJ075516;
Thu, 17 Oct 2002 20:11:59 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9I3BwUm075515;
Thu, 17 Oct 2002 20:11:58 -0700 (PDT)
(envelope-from rizzo)
Date: Thu, 17 Oct 2002 20:11:58 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Petri Helenius <pete@he.iki.fi>
Cc: Lars Eggert <larse@ISI.EDU>, freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021017201158.A75351@carp.icir.org>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu> <0be401c2761f$855af670$8c2a40c1@PHE>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <0be401c2761f$855af670$8c2a40c1@PHE>; from pete@he.iki.fi on Thu, Oct 17, 2002 at 11:55:24PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
...
> I seem to get about 5-6 packets on an interrupt. Is this tunable? At
just reading the source code, yes, it appears that the card has
support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
and usage in sys/dev/em/* . I don't know in what units are the values
(28 and 128, respectively), but it does appear that tx interrupts are
delayed a bit more than rx interrupts.
They are not user-configurable at the moment though, you need to rebuild
the kernel.
cheers
luigi
> 50kpps the card generates 10k interrupts a second. Sending generates
> way less. This is about 300Mbps so with the average packet size of
> 750 there should be room for more packets on the interface queue
> before needing to service an interrupt?
>
> What´s the way to access kernel adapter-structure? Is there an utility
> that can view the values there?
> >
> Pete
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 21:15:38 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 466D637B401
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 21:15:37 -0700 (PDT)
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by mx1.FreeBSD.org (Postfix) with ESMTP id 3793D43E77
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 21:15:36 -0700 (PDT)
(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA85147;
Thu, 17 Oct 2002 21:10:56 -0700 (PDT)
Received: from arch20m.dellroad.org (localhost [127.0.0.1])
by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9I4AuON020821;
Thu, 17 Oct 2002 21:10:56 -0700 (PDT)
(envelope-from archie@arch20m.dellroad.org)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9I4AsvJ020820;
Thu, 17 Oct 2002 21:10:54 -0700 (PDT)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200210180410.g9I4AsvJ020820@arch20m.dellroad.org>
Subject: Re: MPD PPTP tunneling intermittantly fails
In-Reply-To: <20021017021849.GA1354@otdel1.org> "from Nikolai Saoukh at Oct 17,
2002 06:18:49 am"
To: Nikolai Saoukh <bsd#nms@otdel-1.org>
Date: Thu, 17 Oct 2002 21:10:54 -0700 (PDT)
Cc: freebsd-net@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Nikolai Saoukh writes:
> | That doesn't look so good. But it doesn't look "crazy" from the
> | netgraph side, just like a lot of packets are being dropped.
> | There must be something specific about your setup that causes this.
>
> Specific is MPPE. I have the same problem here.
> I am digging the problem at slow pace. So far
> I discoverd that mpd set mtu on interface too early,
> thus without MPPE header size. But the real problem,
> is the huge amount of CCP Reset Requests from win client.
Hmm, try enabling the mpp-stateless option.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 21:30:13 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 0068337B401
for <freebsd-net@FreeBSD.org>; Thu, 17 Oct 2002 21:30:12 -0700 (PDT)
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by mx1.FreeBSD.org (Postfix) with ESMTP id 6F4F543E75
for <freebsd-net@FreeBSD.org>; Thu, 17 Oct 2002 21:30:11 -0700 (PDT)
(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA85347;
Thu, 17 Oct 2002 21:26:16 -0700 (PDT)
Received: from arch20m.dellroad.org (localhost [127.0.0.1])
by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9I4QGON021047;
Thu, 17 Oct 2002 21:26:16 -0700 (PDT)
(envelope-from archie@arch20m.dellroad.org)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9I4QFxo021046;
Thu, 17 Oct 2002 21:26:15 -0700 (PDT)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200210180426.g9I4QFxo021046@arch20m.dellroad.org>
Subject: Re: performance of pptp with mpd
In-Reply-To: <002901c275d5$fe4e8dc0$4123d696@ugr.es> "from Francisco J. Medina
Jimenez at Oct 17, 2002 02:09:05 pm"
To: "Francisco J. Medina Jimenez" <fran@ugr.es>
Date: Thu, 17 Oct 2002 21:26:15 -0700 (PDT)
Cc: freebsd-net@FreeBSD.org
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Francisco J. Medina Jimenez writes:
> I'm testing mpd 3.9 with FreeBSD 4.6.2. The performance of transfers
> using W2k clients is much better than using XP or Win9x (in same
> conditions). Are there any parameters to adjust or it's problem of pptp
> client implementation?
The different Windowses have different PPP characteristics.
For Win9x, make sure you have the latest MS updates.
Try playing with 'set link mtu ...', mpp-stateless, and enabling
multilink.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 21:30:19 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 1C61937B401; Thu, 17 Oct 2002 21:30:18 -0700 (PDT)
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 043E843E91; Thu, 17 Oct 2002 21:30:16 -0700 (PDT)
(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA85269;
Thu, 17 Oct 2002 21:16:53 -0700 (PDT)
Received: from arch20m.dellroad.org (localhost [127.0.0.1])
by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9I4GrON020889;
Thu, 17 Oct 2002 21:16:53 -0700 (PDT)
(envelope-from archie@arch20m.dellroad.org)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9I4GrmL020888;
Thu, 17 Oct 2002 21:16:53 -0700 (PDT)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200210180416.g9I4GrmL020888@arch20m.dellroad.org>
Subject: Re: Netgraph TCP/IP
In-Reply-To: <20021017110456.G15035@sjt-u10.cisco.com> "from Steve Tremblett
at Oct 17, 2002 11:04:56 am"
To: Steve Tremblett <sjt@cisco.com>
Date: Thu, 17 Oct 2002 21:16:53 -0700 (PDT)
Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Steve Tremblett writes:
> A while back someone was fishing for a project to take on and someone
> suggested a complete TCP/IP implementation in netgraph. I found the
> idea interesting and am considering taking a shot at it. My main goal
> in all this is to learn as much as possible and at this point I'm just
> reading.
>
> While this is a personal educational project, I figure I should propose
> it here and solicit comments/thoughts/suggestions on such a venture so
> that maybe the results might be usable by someone else.
Are you intending to have this hook into the normal FreeBSD TCP/IP
stack or be truly standalone? I read your question as the latter but
others seem to read it as the former.
If the latter, I'd suggest splitting it up into several netgraph
nodes, eg.:
| | | | | |
ng_udp ng_tcp
\ /
\ /
ng_ip
|
|
ng_arp
| |
| |
ng_ether
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 21:30:23 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id CC1BB37B408
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 21:30:20 -0700 (PDT)
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by mx1.FreeBSD.org (Postfix) with ESMTP id DFB3F43E65
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 21:30:19 -0700 (PDT)
(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA85332;
Thu, 17 Oct 2002 21:24:30 -0700 (PDT)
Received: from arch20m.dellroad.org (localhost [127.0.0.1])
by arch20m.dellroad.org (8.12.6/8.12.6) with ESMTP id g9I4OTON021011;
Thu, 17 Oct 2002 21:24:30 -0700 (PDT)
(envelope-from archie@arch20m.dellroad.org)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.12.6/8.12.6/Submit) id g9I4OTrO021010;
Thu, 17 Oct 2002 21:24:29 -0700 (PDT)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200210180424.g9I4OTrO021010@arch20m.dellroad.org>
Subject: Re: mpd - Radius
In-Reply-To: <3DAE5495.1040409@inode.at> "from Michael Bretterklieber at Oct
17, 2002 08:11:33 am"
To: Michael Bretterklieber <mbretter@inode.at>
Date: Thu, 17 Oct 2002 21:24:28 -0700 (PDT)
Cc: Archie Cobbs <archie@dellroad.org>, freebsd-net@FreeBSD.ORG,
brendan@gnarst.net
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Michael Bretterklieber writes:
> But I think it will better to have something like this in the mpd.conf:
> - gobal switch to enable radius support.
> - switches for the different layers (link, bundle) where radius can be
> used (because Radius can more the Authentication)
That makes sense :-)
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 21:48:42 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 8F59C37B401
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 21:48:40 -0700 (PDT)
Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173])
by mx1.FreeBSD.org (Postfix) with ESMTP id DBC1543E6A
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 21:48:39 -0700 (PDT)
(envelope-from jimmcgra@bellatlantic.net)
Received: from Default ([141.154.237.113]) by pop016.verizon.net
(InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP
id <20021018044839.LNKQ1630.pop016.verizon.net@Default>;
Thu, 17 Oct 2002 23:48:39 -0500
From: "Jim McGrath" <jimmcgra@bellatlantic.net>
To: "Luigi Rizzo" <rizzo@icir.org>, "Petri Helenius" <pete@he.iki.fi>
Cc: "Lars Eggert" <larse@ISI.EDU>, <freebsd-net@FreeBSD.ORG>
Subject: RE: ENOBUFS
Date: Fri, 18 Oct 2002 00:49:04 -0400
Message-ID: <NDBBKKEELKBCJJBEGDECCEHHCGAA.jimmcgra@bellatlantic.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <20021017201158.A75351@carp.icir.org>
Importance: Normal
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop016.verizon.net from [141.154.237.113] at Thu, 17 Oct 2002 23:48:38 -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Careful here. Read the errata sheet!! I do not believe the em driver uses
these parameters, and possibly for a good reason.
Jim
> -----Original Message-----
> From: owner-freebsd-net@FreeBSD.ORG
> [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo
> Sent: Thursday, October 17, 2002 11:12 PM
> To: Petri Helenius
> Cc: Lars Eggert; freebsd-net@FreeBSD.ORG
> Subject: Re: ENOBUFS
>
>
> On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
> ...
> > I seem to get about 5-6 packets on an interrupt. Is this tunable? At
>
> just reading the source code, yes, it appears that the card has
> support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> and usage in sys/dev/em/* . I don't know in what units are the values
> (28 and 128, respectively), but it does appear that tx interrupts are
> delayed a bit more than rx interrupts.
>
> They are not user-configurable at the moment though, you need to rebuild
> the kernel.
>
> cheers
> luigi
>
> > 50kpps the card generates 10k interrupts a second. Sending generates
> > way less. This is about 300Mbps so with the average packet size of
> > 750 there should be room for more packets on the interface queue
> > before needing to service an interrupt?
> >
> > What´s the way to access kernel adapter-structure? Is there an utility
> > that can view the values there?
> > >
> > Pete
> >
> >
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 21:55:47 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 56B8737B401
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 21:55:46 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id 99F1143E9E
for <freebsd-net@FreeBSD.ORG>; Thu, 17 Oct 2002 21:55:45 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9I4thpJ076389;
Thu, 17 Oct 2002 21:55:43 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9I4thFp076388;
Thu, 17 Oct 2002 21:55:43 -0700 (PDT)
(envelope-from rizzo)
Date: Thu, 17 Oct 2002 21:55:43 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Jim McGrath <jimmcgra@bellatlantic.net>
Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>,
freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021017215543.B76232@carp.icir.org>
References: <20021017201158.A75351@carp.icir.org> <NDBBKKEELKBCJJBEGDECCEHHCGAA.jimmcgra@bellatlantic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <NDBBKKEELKBCJJBEGDECCEHHCGAA.jimmcgra@bellatlantic.net>; from jimmcgra@bellatlantic.net on Fri, Oct 18, 2002 at 12:49:04AM -0400
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, Oct 18, 2002 at 12:49:04AM -0400, Jim McGrath wrote:
> Careful here. Read the errata sheet!! I do not believe the em driver uses
> these parameters, and possibly for a good reason.
as if i had access to the data sheets :)
cheers
luigi
> Jim
>
> > -----Original Message-----
> > From: owner-freebsd-net@FreeBSD.ORG
> > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo
> > Sent: Thursday, October 17, 2002 11:12 PM
> > To: Petri Helenius
> > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG
> > Subject: Re: ENOBUFS
> >
> >
> > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
> > ...
> > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At
> >
> > just reading the source code, yes, it appears that the card has
> > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> > and usage in sys/dev/em/* . I don't know in what units are the values
> > (28 and 128, respectively), but it does appear that tx interrupts are
> > delayed a bit more than rx interrupts.
> >
> > They are not user-configurable at the moment though, you need to rebuild
> > the kernel.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu Oct 17 21:58:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6BA9137B401
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 21:58:58 -0700 (PDT)
Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101])
by mx1.FreeBSD.org (Postfix) with ESMTP id 860DF43E7B
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 21:58:57 -0700 (PDT)
(envelope-from bsd#nms@otdel-1.org)
Received: by otdel-1.org (CommuniGate Pro PIPE 4.0b9)
with PIPE id 2200010; Fri, 18 Oct 2002 08:58:56 +0400
Date: Fri, 18 Oct 2002 08:58:53 +0400
From: Nikolai Saoukh <bsd#nms@otdel-1.org>
To: freebsd-net@FreeBSD.ORG
Subject: Re: MPD PPTP tunneling intermittantly fails
Message-ID: <20021018045853.GA329@otdel1.org>
Mail-Followup-To: freebsd-net@FreeBSD.ORG
References: <20021017021849.GA1354@otdel1.org> <200210180410.g9I4AsvJ020820@arch20m.dellroad.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200210180410.g9I4AsvJ020820@arch20m.dellroad.org>
User-Agent: Mutt/1.5.1i
X-Mailer: CommuniGate Pro CLI mailer
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Thu, Oct 17, 2002 at 09:10:54PM -0700, Archie Cobbs wrote:
| > is the huge amount of CCP Reset Requests from win client.
|
| Hmm, try enabling the mpp-stateless option.
When on direct modem link the win client refuses mpp-stateless.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 0:39:52 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 4870437B401
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 00:39:51 -0700 (PDT)
Received: from mail.allcaps.org (h-66-166-142-198.SNDACAGL.covad.net [66.166.142.198])
by mx1.FreeBSD.org (Postfix) with ESMTP id 9C6A243E7B
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 00:39:50 -0700 (PDT)
(envelope-from bsder@mail.allcaps.org)
Received: by mail.allcaps.org (Postfix, from userid 501)
id 4D1051550C; Fri, 18 Oct 2002 00:39:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mail.allcaps.org (Postfix) with ESMTP
id 423FB1550B; Fri, 18 Oct 2002 00:39:49 -0700 (PDT)
Date: Fri, 18 Oct 2002 00:39:49 -0700 (PDT)
From: "Andrew P. Lentvorski" <bsder@mail.allcaps.org>
To: Charles Henrich <henrich@sigbus.com>
Cc: freebsd-net@freebsd.org
Subject: Re: IPSEC/NAT issues
In-Reply-To: <20021017162243.B89519@sigbus.com>
Message-ID: <20021018002729.T66900-100000@mail.allcaps.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
packet will get rejected when it reaches the other IPSEC node.
You can create forwarding rules which NAT packets destined for other hosts
and leave the IPSEC packets alone. You'll have to create an ipfw ruleset.
You also probably need to understand the difference between tunnel mode
and transport mode in IPSEC. Transport mode is host-to-host. Tunnel mode
is network-to-network. (I may have those two backwards) You are trying
to do a hybrid; I don't think that is allowed in IPSEC.
One of the hardest things for me to get used to in IPSEC was the fact that
two machines could actually not talk to one another normally, but could
create an IPSEC tunnel. Also, two machines that could actually talk to
one another was not sufficient to guarantee that they could set up a
tunnel.
Good luck,
-a
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 1:18:27 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id E25C337B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 01:18:25 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id 95A1143EAF
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 01:18:24 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9I8IEYj081941;
Fri, 18 Oct 2002 11:18:17 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <0cf301c2767e$fb192080$8c2a40c1@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Jim McGrath" <jimmcgra@bellatlantic.net>,
"Luigi Rizzo" <rizzo@icir.org>
Cc: "Lars Eggert" <larse@ISI.EDU>, <freebsd-net@FreeBSD.ORG>
References: <NDBBKKEELKBCJJBEGDECCEHHCGAA.jimmcgra@bellatlantic.net>
Subject: Re: ENOBUFS
Date: Fri, 18 Oct 2002 11:18:45 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Where could I get the errata sheet?
Could the numbers be packet thresholds? 28 and 128 packets respectively?
Anything else that can be done? Does PCI width/speed affect the amount of
time spent in the kernel interrupt or are the PCI transfers asynchronous?
Pete
----- Original Message -----
From: "Jim McGrath" <jimmcgra@bellatlantic.net>
To: "Luigi Rizzo" <rizzo@icir.org>; "Petri Helenius" <pete@he.iki.fi>
Cc: "Lars Eggert" <larse@ISI.EDU>; <freebsd-net@FreeBSD.ORG>
Sent: Friday, October 18, 2002 7:49 AM
Subject: RE: ENOBUFS
> Careful here. Read the errata sheet!! I do not believe the em driver uses
> these parameters, and possibly for a good reason.
>
> Jim
>
> > -----Original Message-----
> > From: owner-freebsd-net@FreeBSD.ORG
> > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo
> > Sent: Thursday, October 17, 2002 11:12 PM
> > To: Petri Helenius
> > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG
> > Subject: Re: ENOBUFS
> >
> >
> > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
> > ...
> > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At
> >
> > just reading the source code, yes, it appears that the card has
> > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> > and usage in sys/dev/em/* . I don't know in what units are the values
> > (28 and 128, respectively), but it does appear that tx interrupts are
> > delayed a bit more than rx interrupts.
> >
> > They are not user-configurable at the moment though, you need to rebuild
> > the kernel.
> >
> > cheers
> > luigi
> >
> > > 50kpps the card generates 10k interrupts a second. Sending generates
> > > way less. This is about 300Mbps so with the average packet size of
> > > 750 there should be room for more packets on the interface queue
> > > before needing to service an interrupt?
> > >
> > > What´s the way to access kernel adapter-structure? Is there an utility
> > > that can view the values there?
> > > >
> > > Pete
> > >
> > >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-net" in the body of the message
> >
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 1:30:42 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6679737B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 01:30:41 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id 3BD3543EAF
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 01:30:40 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9I8UbYj082020;
Fri, 18 Oct 2002 11:30:39 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <0d0b01c27680$b553ba90$8c2a40c1@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Luigi Rizzo" <rizzo@icir.org>
Cc: "Lars Eggert" <larse@ISI.EDU>, <freebsd-net@FreeBSD.ORG>
References: <065901c27495$56a94c40$8c2a40c1@PHE> <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu> <0be401c2761f$855af670$8c2a40c1@PHE> <20021017201158.A75351@carp.icir.org>
Subject: Re: ENOBUFS
Date: Fri, 18 Oct 2002 11:31:08 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
>
> just reading the source code, yes, it appears that the card has
> support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> and usage in sys/dev/em/* . I don't know in what units are the values
> (28 and 128, respectively), but it does appear that tx interrupts are
> delayed a bit more than rx interrupts.
>
The thing what is looking suspect is also the "small packet interrupt" feature
which does not seem to get modified in the em driver but is on the defines.
If that would be on by default, we´d probably see interrupts "too often"
because it tries to optimize interrupts for good throughput on small number
of TCP streams.
Should these questions be posted to the authors of the driver?
Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 1:36:31 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id EF80937B401
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 01:36:30 -0700 (PDT)
Received: from consult-scs.com (vpn.consult-scs.com [209.172.126.178])
by mx1.FreeBSD.org (Postfix) with ESMTP id 9C64043E42
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 01:36:30 -0700 (PDT)
(envelope-from vulture@consult-scs.com)
Received: from consult-scs.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60])
(authenticated bits=0)
by consult-scs.com (8.12.6/8.12.6) with ESMTP id g9I2dOIB064440
for <freebsd-net@freebsd.org>; Thu, 17 Oct 2002 19:39:25 -0700 (PDT)
Message-ID: <3DAF7470.8040103@consult-scs.com>
Date: Thu, 17 Oct 2002 19:39:44 -0700
From: Jonathan Feally <vulture@consult-scs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: RE: IPSEC/NAT issues
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On a side note:
For whoever tackles this project - a sysctl variable would be nice to
turn the second ipsec processing(pre ipfw/ipf) on or off.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 1:36:33 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6D8B737B404
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 01:36:31 -0700 (PDT)
Received: from consult-scs.com (vpn.consult-scs.com [209.172.126.178])
by mx1.FreeBSD.org (Postfix) with ESMTP id 0005F43EA9
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 01:36:30 -0700 (PDT)
(envelope-from vulture@consult-scs.com)
Received: from consult-scs.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60])
(authenticated bits=0)
by consult-scs.com (8.12.6/8.12.6) with ESMTP id g9I2axIB060983;
Thu, 17 Oct 2002 19:37:03 -0700 (PDT)
Message-ID: <3DAF73DE.1080307@consult-scs.com>
Date: Thu, 17 Oct 2002 19:37:18 -0700
From: Jonathan Feally <vulture@consult-scs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charles Henrich <henrich@sigbus.com>
Cc: freebsd-net@freebsd.org
Subject: Re: IPsec/NAT FreeBSD
References: <20021017161013.A89519@sigbus.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
I was just looking at the latest postings from the net list and was
reading yours when I found this e-mail you sent directly to me.
I've had some success with IPSEC/IPFW and NATD.
The problem lies in the kernel, ipsec and ipfw ordering of where the
packets flow.
What you are trying to do - makes perfect sense. But the kerenl is
screwing you up.
I took and duplicated your problem using a 4.6.2-R Machine with a Lan
behind it and a 4.4-R machine.
So here lies the problem:
The outgoing packets from the lan get nat-ed and then ipsec-ed.
The incoming packets are ipsec-ed but don't pass to natd as a regular
packet. because ipsec takes place after ipfw.
I think a solution to the problem would be to have ipsec processing take
place both before and after ipfw(or ipf).
Somebody else though will have to figure out how to make a custom kernel
to do double ipsec processing because I'm not a C programmer.
Hope somebody can make it happen, for both of us.
- Jonathan
Charles Henrich wrote:
>I've run across your postings in the FreeBSD mailing lists, and it looks like
>your trying to do what I am trying to do. I was wondering if you had solved
>it? That is, I have a nat'd network, and I want packets from any host on the
>inside of the network to be ESP encapsilated after nat translation to one
>particular host outside the network. It looks like it works, kinda. Packets
>hit the gateway, are nat'd, are ESP encapsilated, and sent on their merry way.
>Racoon even does a proper key exchange. On the return path however, the
>packed is unencapsilated, but nat seems to refuse to reverse the natting?
>Were you able to solve this problem?
>
>Thanks for any advice!
>
>-Crh
>
> Charles Henrich Eon Entertainment henrich@msu.edu
>
> http://www.sigbus.com/~henrich
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 3:48: 1 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id BDC1B37B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 03:47:59 -0700 (PDT)
Received: from femme.sapphite.org (pcp02268182pcs.longhl01.md.comcast.net [68.50.99.190])
by mx1.FreeBSD.org (Postfix) with ESMTP id 3215A43E9E
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 03:47:50 -0700 (PDT)
(envelope-from trish@bsdunix.net)
Received: from localhost (trish@localhost [127.0.0.1])
by femme.sapphite.org (8.12.6/8.12.5) with ESMTP id g9IAm1hG002453;
Fri, 18 Oct 2002 06:48:06 -0400 (EDT)
(envelope-from trish@bsdunix.net)
Date: Fri, 18 Oct 2002 06:48:01 -0400 (EDT)
From: Trish Lynch <trish@bsdunix.net>
X-X-Sender: <trish@femme.sapphite.org>
To: Jonathan Feally <vulture@consult-scs.com>
Cc: Charles Henrich <henrich@sigbus.com>, <freebsd-net@FreeBSD.ORG>
Subject: Re: IPsec/NAT FreeBSD
In-Reply-To: <3DAF73DE.1080307@consult-scs.com>
Message-ID: <20021018064542.X491-100000@femme.sapphite.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Thu, 17 Oct 2002, Jonathan Feally wrote:
>
> I think a solution to the problem would be to have ipsec processing take
> place both before and after ipfw(or ipf).
> Somebody else though will have to figure out how to make a custom kernel
> to do double ipsec processing because I'm not a C programmer.
>
> Hope somebody can make it happen, for both of us.
> - Jonathan
>
> Charles Henrich wrote:
>
> >I've run across your postings in the FreeBSD mailing lists, and it looks like
> >your trying to do what I am trying to do. I was wondering if you had solved
> >it? That is, I have a nat'd network, and I want packets from any host on the
> >inside of the network to be ESP encapsilated after nat translation to one
> >particular host outside the network. It looks like it works, kinda. Packets
> >hit the gateway, are nat'd, are ESP encapsilated, and sent on their merry way.
> >Racoon even does a proper key exchange. On the return path however, the
> >packed is unencapsilated, but nat seems to refuse to reverse the natting?
> >Were you able to solve this problem?
> >
> >Thanks for any advice!
> >
I don't let IPSEC packets be processed by natd through the divert socket,
in fact I use ipfw skipto rules:
00100 skipto 65535 ip from 66.80.117.2 to 64.14.48.150
00200 skipto 65535 ip from 64.14.48.150 to 66.80.117.2
00300 skipto 65535 ip from 10.80.116.0/23 to 10.0.0.0/24
00400 skipto 65535 ip from 10.0.0.0/24 to 10.80.116.0/23
00500 divert 8668 ip from any to any via fxp0
65535 allow ip from any to any
It works well.
-Trish
--
Trish Lynch trish@bsdunix.net
Ecartis Core Team trish@listmistress.org
EFNet IRC Oper @ efnet.dkom.at AilleCat@EFNet
UNIXNet IRC Admin @ femme.ipv6.sapphite.org AilleCat@UNIXNet
Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 5:53:17 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 43A3137B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 05:53:15 -0700 (PDT)
Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5011C43EB2
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 05:53:14 -0700 (PDT)
(envelope-from jimmcgra@bellatlantic.net)
Received: from Default ([141.154.237.113]) by out001.verizon.net
(InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP
id <20021018125313.ZIWQ3265.out001.verizon.net@Default>;
Fri, 18 Oct 2002 07:53:13 -0500
From: "Jim McGrath" <jimmcgra@bellatlantic.net>
To: "Luigi Rizzo" <rizzo@icir.org>
Cc: "Petri Helenius" <pete@he.iki.fi>, "Lars Eggert" <larse@ISI.EDU>,
<freebsd-net@FreeBSD.ORG>
Subject: RE: ENOBUFS
Date: Fri, 18 Oct 2002 08:53:36 -0400
Message-ID: <NDBBKKEELKBCJJBEGDECCEHJCGAA.jimmcgra@bellatlantic.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <20021017215543.B76232@carp.icir.org>
Importance: Normal
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at out001.verizon.net from [141.154.237.113] at Fri, 18 Oct 2002 07:53:13 -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
I have to tread carefully here because I was under NDA at my previous
company. My work was with the wx driver, but hardware problems are hardware
problems. There are a lot of performance enhancing features in the 82544.
You will notice that the em driver does not use them. This may be for a
reason :-( Our implementation ran with transmit interrupts disabled, so I
can't comment on TIDV and am not allowed to comment on RIDV.
The Receive Descriptor Threshold interrupt showed promise under high load
(Rx interrupts disabled) but you would need to add a timeout function, 1
msec. or faster, to process receive descriptors under low load.
Jim
> -----Original Message-----
> From: owner-freebsd-net@FreeBSD.ORG
> [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo
> Sent: Friday, October 18, 2002 12:56 AM
> To: Jim McGrath
> Cc: Petri Helenius; Lars Eggert; freebsd-net@FreeBSD.ORG
> Subject: Re: ENOBUFS
>
>
> On Fri, Oct 18, 2002 at 12:49:04AM -0400, Jim McGrath wrote:
> > Careful here. Read the errata sheet!! I do not believe the em
> driver uses
> > these parameters, and possibly for a good reason.
>
> as if i had access to the data sheets :)
>
> cheers
> luigi
> > Jim
> >
> > > -----Original Message-----
> > > From: owner-freebsd-net@FreeBSD.ORG
> > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo
> > > Sent: Thursday, October 17, 2002 11:12 PM
> > > To: Petri Helenius
> > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG
> > > Subject: Re: ENOBUFS
> > >
> > >
> > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
> > > ...
> > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At
> > >
> > > just reading the source code, yes, it appears that the card has
> > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> > > and usage in sys/dev/em/* . I don't know in what units are the values
> > > (28 and 128, respectively), but it does appear that tx interrupts are
> > > delayed a bit more than rx interrupts.
> > >
> > > They are not user-configurable at the moment though, you need
> to rebuild
> > > the kernel.
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 6:16:43 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id E41F537B401; Fri, 18 Oct 2002 06:16:41 -0700 (PDT)
Received: from cisco.com (sword.cisco.com [161.44.208.100])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 0F78D43E91; Fri, 18 Oct 2002 06:16:41 -0700 (PDT)
(envelope-from sjt@cisco.com)
Received: from sjt-u10.cisco.com (sjt-u10.cisco.com [10.85.30.63])
by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id JAA23856;
Fri, 18 Oct 2002 09:16:40 -0400 (EDT)
Received: (sjt@localhost) by sjt-u10.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id JAA20857; Fri, 18 Oct 2002 09:16:39 -0400 (EDT)
Date: Fri, 18 Oct 2002 09:16:39 -0400
From: Steve Tremblett <sjt@cisco.com>
To: Archie Cobbs <archie@dellroad.org>
Cc: freebsd-net@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject: Re: Netgraph TCP/IP
Message-ID: <20021018091639.W15035@sjt-u10.cisco.com>
References: <20021017110456.G15035@sjt-u10.cisco.com> <200210180416.g9I4GrmL020888@arch20m.dellroad.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200210180416.g9I4GrmL020888@arch20m.dellroad.org>; from archie@dellroad.org on Thu, Oct 17, 2002 at 09:16:53PM -0700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
+---- Archie Cobbs wrote:
| Are you intending to have this hook into the normal FreeBSD TCP/IP
| stack or be truly standalone? I read your question as the latter but
| others seem to read it as the former.
I am very much a babe in the woods at this point. I have no plan aside
from reading as much as possible. My original idea was for it to be
completely separate, so individual nodes could be replaced easily to
try new algorithms. The subsequent discussion has been valuable
nonetheless, and my plans certainly aren't written in stone.
| If the latter, I'd suggest splitting it up into several netgraph
| nodes, eg.:
|
| | | | | | |
| ng_udp ng_tcp
| \ /
| \ /
| ng_ip
| |
| |
| ng_arp
| | |
| | |
| ng_ether
That was how I pictured it as well (well before your diagram got munged
by my editor that is) - thanks :)
--
Steve Tremblett
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 6:21:18 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B6C6137B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 06:21:15 -0700 (PDT)
Received: from pop017.verizon.net (pop017pub.verizon.net [206.46.170.210])
by mx1.FreeBSD.org (Postfix) with ESMTP id F307843E42
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 06:21:14 -0700 (PDT)
(envelope-from jimmcgra@bellatlantic.net)
Received: from Default ([141.154.237.113]) by pop017.verizon.net
(InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP
id <20021018132114.MLNH1423.pop017.verizon.net@Default>;
Fri, 18 Oct 2002 08:21:14 -0500
From: "Jim McGrath" <jimmcgra@bellatlantic.net>
To: "Petri Helenius" <pete@he.iki.fi>, "Luigi Rizzo" <rizzo@icir.org>
Cc: "Lars Eggert" <larse@ISI.EDU>, <freebsd-net@FreeBSD.ORG>
Subject: RE: ENOBUFS
Date: Fri, 18 Oct 2002 09:21:37 -0400
Message-ID: <NDBBKKEELKBCJJBEGDECOEHJCGAA.jimmcgra@bellatlantic.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <0cf301c2767e$fb192080$8c2a40c1@PHE>
Importance: Normal
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop017.verizon.net from [141.154.237.113] at Fri, 18 Oct 2002 08:21:13 -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> Where could I get the errata sheet?
Product Specification Updates i.e. errata, and the Product Specification
itself are available from Intel under a Non Disclosure Agreement. Unless
you work for a company that is doing business with Intel, they are probably
not obtainable.
>
> Could the numbers be packet thresholds? 28 and 128 packets respectively?
>
I can't answer that directly because of NDA. Let us apply some logic here.
If they were packet counts, under very low load conditions e.g. a single
telnet session, the telnet link would be unusable. This leads us to the
conclusion that they must be time values.
Jim
> Anything else that can be done? Does PCI width/speed affect the amount of
> time spent in the kernel interrupt or are the PCI transfers asynchronous?
>
> Pete
>
> ----- Original Message -----
> From: "Jim McGrath" <jimmcgra@bellatlantic.net>
> To: "Luigi Rizzo" <rizzo@icir.org>; "Petri Helenius" <pete@he.iki.fi>
> Cc: "Lars Eggert" <larse@ISI.EDU>; <freebsd-net@FreeBSD.ORG>
> Sent: Friday, October 18, 2002 7:49 AM
> Subject: RE: ENOBUFS
>
>
> > Careful here. Read the errata sheet!! I do not believe the em
> driver uses
> > these parameters, and possibly for a good reason.
> >
> > Jim
> >
> > > -----Original Message-----
> > > From: owner-freebsd-net@FreeBSD.ORG
> > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo
> > > Sent: Thursday, October 17, 2002 11:12 PM
> > > To: Petri Helenius
> > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG
> > > Subject: Re: ENOBUFS
> > >
> > >
> > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
> > > ...
> > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At
> > >
> > > just reading the source code, yes, it appears that the card has
> > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> > > and usage in sys/dev/em/* . I don't know in what units are the values
> > > (28 and 128, respectively), but it does appear that tx interrupts are
> > > delayed a bit more than rx interrupts.
> > >
> > > They are not user-configurable at the moment though, you need
> to rebuild
> > > the kernel.
> > >
> > > cheers
> > > luigi
> > >
> > > > 50kpps the card generates 10k interrupts a second. Sending generates
> > > > way less. This is about 300Mbps so with the average packet size of
> > > > 750 there should be room for more packets on the interface queue
> > > > before needing to service an interrupt?
> > > >
> > > > What´s the way to access kernel adapter-structure? Is there
> an utility
> > > > that can view the values there?
> > > > >
> > > > Pete
> > > >
> > > >
> > >
> > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > with "unsubscribe freebsd-net" in the body of the message
> > >
> >
> >
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 6:27:55 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D2C4037B401
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 06:27:53 -0700 (PDT)
Received: from otdel-1.org (draculina.otdel-1.org [195.230.89.101])
by mx1.FreeBSD.org (Postfix) with ESMTP id 6B15E43E7B
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 06:27:51 -0700 (PDT)
(envelope-from bsd#nms@otdel-1.org)
Received: by otdel-1.org (CommuniGate Pro PIPE 4.0b9)
with PIPE id 2220061; Fri, 18 Oct 2002 17:27:47 +0400
Date: Fri, 18 Oct 2002 17:27:32 +0400
From: Nikolai Saoukh <bsd#nms@otdel-1.org>
To: freebsd-net@FreeBSD.ORG
Subject: For those who had problems with MPD server and win clients
Message-ID: <20021018132732.GA27692@otdel1.org>
Mail-Followup-To: freebsd-net@FreeBSD.ORG
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.1i
X-Mailer: CommuniGate Pro CLI mailer
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
IMHO, there is a combination of two bugs.
1) MPD (3.9, at least) calculates and sets mtu (bund.c/BundUpdateParams())
at wrong time -- when one of MIN() args is still zero. ioctl with bizzare mtu
value rejected, thus leaving the default (1500), which in turn is above
MRU requested from win client (1400 for multilink).
[at the same time on other end of connection]
2) MS clients has setting 'Negotiate multi-link for single link connections'.
Even when this option is negotiated, ms client does not understand partial MP
(RFC1990) fragments. When both (begin, end) flags set, then everything is fine,
as long as everything fits MRU.
Would anyone review and test this patches?
(bund.c patches a kind of nitpicking -- enabled is not negotiated :-))
--- bund.c.orig Tue Oct 8 13:40:15 2002
+++ bund.c Fri Oct 18 17:17:23 2002
@@ -548,22 +548,20 @@
mtu = NG_IFACE_MTU_DEFAULT; /* Reset to default settings */
break;
case 1:
- if (!Enabled(&bund->conf.options, BUND_CONF_MULTILINK)) {
- mtu = MIN(bund->links[the_link]->lcp.peer_mru,
- bund->links[the_link]->phys->type->mtu);
- break;
- }
- /* FALLTHROUGH */
+ mtu = bund->links[the_link]->lcp.peer_mru;
+ break;
default: /* We fragment everything, use bundle MRRU */
mtu = bund->mp.peer_mrru;
break;
}
- /* Subtract to make room for various frame-bloating protocols */
- if (Enabled(&bund->conf.options, BUND_CONF_COMPRESSION))
- mtu = CcpSubtractBloat(mtu);
- if (Enabled(&bund->conf.options, BUND_CONF_ENCRYPTION))
- mtu = EcpSubtractBloat(mtu);
+ if (bm->n_up > 0) {
+ /* Subtract to make room for various frame-bloating protocols */
+ if (bund->ccp.xmit != NULL)
+ mtu = CcpSubtractBloat(mtu);
+ if (bund->ecp.xmit != NULL)
+ mtu = EcpSubtractBloat(mtu);
+ }
/* Update interface MTU */
if (mtu > BUND_MAX_MTU)
--- iface.c.orig Tue Oct 8 14:28:09 2002
+++ iface.c Sat Oct 12 11:54:36 2002
@@ -346,6 +346,8 @@
/* Sanity */
assert(!iface->ip_up);
+ BundUpdateParams();
+
/* Set addresses and bring interface up */
snprintf(hisaddr, sizeof(hisaddr), "%s", inet_ntoa(iface->peer_addr));
ExecCmd(LG_IFACE, "%s %s %s %s netmask 0xffffffff %slink0",
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 6:41:26 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id B419C37B406
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 06:41:25 -0700 (PDT)
Received: from hottub.hottub.org (hottub.org [66.60.164.74])
by mx1.FreeBSD.org (Postfix) with ESMTP id 5023F43E8A
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 06:41:25 -0700 (PDT)
(envelope-from matt@hottub.org)
Received: by hottub.hottub.org (Postfix, from userid 1100)
id BE1EC213BF; Fri, 18 Oct 2002 06:39:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by hottub.hottub.org (Postfix) with ESMTP id B7A97213BB
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 06:39:51 -0700 (PDT)
Date: Fri, 18 Oct 2002 06:39:51 -0700 (PDT)
From: Matthew Zahorik <matt@hottub.org>
X-X-Sender: matt@hottub
To: freebsd-net@freebsd.org
Subject: Re: IPSEC/NAT issues
In-Reply-To: <20021018002729.T66900-100000@mail.allcaps.org>
Message-ID: <Pine.GSO.4.40.0210180628271.5762-100000@hottub>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> packet will get rejected when it reaches the other IPSEC node.
Not exactly true. I use a Windows Nortel Contivity client behind NAT just
fine.
If you're using an AH association (header authentication) that will not
pass through NAT. I'm sure someone on this list may come up with a fancy
trick for FreeBSD, but generally the statement is true. AH detects the
NAT changes as header corruption.
But if you're only using ESP (encryption of payload) that will work fine.
Most turn on both AH and ESP by default, but that isn't always the case as
in the Nortel boxes.
On another note, I'd *love* to use my FreeBSD NAT box as a VPN tunnel
endpoint rather than my windows boxes. It's a dynamic IP, so it's
catch-22 right now. I can't create a tunnel or SPD policy entry before I
know the IP addresses, and IKE/racoon can't start without those things.
So, if someone happens to be ripping the IPsec processing apart, something
to eliminate this catch-22 would be nice (: (spd entries pointing to an
unconfigured or dummy tunnel, for example)
Thanks!
- Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 7:12:23 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 7678437B401; Fri, 18 Oct 2002 07:12:22 -0700 (PDT)
Received: from dominion.1my.net (dominion.1my.net [202.56.152.11])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 44B9943E97; Fri, 18 Oct 2002 07:12:21 -0700 (PDT)
(envelope-from mikechoo@opensos.net)
Received: from lifebook ([219.93.84.169])
(authenticated bits=0)
by dominion.1my.net (8.12.5/8.12.5) with ESMTP id g9IECCGK070737;
Fri, 18 Oct 2002 22:12:17 +0800 (MYT)
(envelope-from mikechoo@opensos.net)
Date: Fri, 18 Oct 2002 22:11:55 +0800
From: Michael Choo <mikechoo@opensos.net>
X-Mailer: The Bat! (v1.60) Personal
Reply-To: Michael Choo <mikechoo@opensos.net>
Organization: OpenSOS Sdn Bhd
X-Priority: 3 (Normal)
Message-ID: <4510281043.20021018221155@opensos.net>
To: owner-freebsd-net@FreeBSD.ORG, Matthew Zahorik <matt@hottub.org>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re[2]: IPSEC/NAT issues
In-Reply-To: <Pine.GSO.4.40.0210180628271.5762-100000@hottub>
References: <Pine.GSO.4.40.0210180628271.5762-100000@hottub>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hello Matthew,
Friday, October 18, 2002, 9:39:51 PM, you wrote:
MZ> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
>> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
>> packet will get rejected when it reaches the other IPSEC node.
MZ> Not exactly true. I use a Windows Nortel Contivity client behind NAT just
MZ> fine.
Yup, I use a Windows Nortel Contivity client behind a FreeBSD userland
PPP NAT just fine too.
--
Best regards,
Michael mailto:mikechoo@opensos.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 7:29:25 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id BA16437B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 07:29:23 -0700 (PDT)
Received: from zelax.ru (rosa.zelax.ru [212.188.91.12])
by mx1.FreeBSD.org (Postfix) with ESMTP id 52DE543E9E
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 07:29:22 -0700 (PDT)
(envelope-from wr@zelax.ru)
Received: (from root@localhost)
by zelax.ru (8.9.3/8.9.3) id SAA37542
for freebsd-net@FreeBSD.ORG.KAV; Fri, 18 Oct 2002 18:29:19 +0400 (MSD)
(envelope-from wr@zelax.ru)
Received: from zelax.ru (slava.local [192.168.11.152])
by zelax.ru (8.9.3/8.9.3) with ESMTP id SAA37534
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 18:29:19 +0400 (MSD)
(envelope-from wr@zelax.ru)
Message-ID: <3DB07D78.4080306@zelax.ru>
Date: Fri, 18 Oct 2002 17:30:32 -0400
From: "Vyacheslav V. Burdjanadze" <wr@zelax.ru>
Organization: ZELAX
User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98;
X-Accept-Language: ru, en
MIME-Version: 1.0
To: freebsd-net@FreeBSD.ORG
Subject: pppd rechallenge bug?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi. Sorry for off-topic, but maybe authors of pppd reads this mail-list..
When porting latest pppd (2.4.1) to RTEMS OS I noticed that
auth_withpeer_success() does not check current operation phase thus if
we enable CHAP rechallenge , each
rechallenge will bring us to network phase (by calling
auth_withpeer_success()). Is this intent?
--
- " Why do you call this software 'beta' ? "
- " Cuz it beta than nothin' ! "
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 7:36:36 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 197B537B401
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 07:36:34 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by mx1.FreeBSD.org (Postfix) with ESMTP id 864C643E7B
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 07:36:33 -0700 (PDT)
(envelope-from larse@ISI.EDU)
Received: from isi.edu (c-24-130-112-157.we.client2.attbi.com [24.130.112.157])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g9IEaVC15122;
Fri, 18 Oct 2002 07:36:31 -0700 (PDT)
Message-ID: <3DB01C6E.7030308@isi.edu>
Date: Fri, 18 Oct 2002 07:36:30 -0700
From: Lars Eggert <larse@ISI.EDU>
Organization: USC Information Sciences Institute
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Matthew Zahorik <matt@hottub.org>
Cc: freebsd-net@freebsd.org
Subject: Re: IPSEC/NAT issues
References: <Pine.GSO.4.40.0210180628271.5762-100000@hottub>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010407010507060506030101"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This is a cryptographically signed message in MIME format.
--------------ms010407010507060506030101
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Matthew Zahorik wrote:
> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
>
>>You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
>>packet will get rejected when it reaches the other IPSEC node.
>
> Not exactly true. I use a Windows Nortel Contivity client behind NAT just
> fine.
Reading his first post, the original poster wants to IPsec NAT'ed
packets, not vice versa.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms010407010507060506030101
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC
AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV
BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG
A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj
ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG
CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw
MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy
dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw
LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ
gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd
knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp
AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS
BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH
XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M
G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp
h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwglQTANBgkqhkiG9w0BAQQFADCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgyNDE4NTMzOVoX
DTAzMDgyNDE4NTMzOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD
VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANI2Rrt4ggaQ/IrOsDeOm2H4/R5FRIL6JjDY3StE
aogp1r23WKniQ1Vj98Nu5WxlaZ3Iam3Jen5T66H8u7rtMNpK4qAeAGoBsVeyVr1+CTFeuv+m
xCh7BvBJwhLdm0zDaoDT05YKYZaqtsT+F286FWJQg31Xtf+vTKLVVrHcsafnteyal2NEt7Ac
yZZfjsVLwxp2Lq3cwYfRQRoo7/yCVzS7HsgM6jmbO4taEMo4yC2rpnUbWEUCDTaCYgpAXzAl
oiNk7GDh0wz2s5ZSnHRvNSBMAjCmpNtSYHfXFI1ANwrrrHIJ7Ei83+XN32PWY4OPzO3iown9
VR+vM+8lNx9OX28CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO
VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ
KoZIhvcNAQEEBQADgYEAXcrIlKmPLM/r8r3oz2ZLPLaT1AyMjYTZY2qq/R7SUtFa9BNlTIFh
DG78QKfJ9lo2LMzTPQqMZgNLmj95GbNPI8P8OIq2K6MeCZWz08ROackqTFP6xWbIFIfXcBVR
1dZnDDyDKBBh05KkvyTPawSQyOBUeNBfQUyO4TE+3o58U8UwggM5MIICoqADAgECAgMIJUEw
DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MDAeFw0wMjA4MjQxODUzMzlaFw0wMzA4MjQxODUzMzlaMFQxDzANBgNVBAQTBkVnZ2VydDEN
MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh
cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDSNka7eIIGkPyK
zrA3jpth+P0eRUSC+iYw2N0rRGqIKda9t1ip4kNVY/fDbuVsZWmdyGptyXp+U+uh/Lu67TDa
SuKgHgBqAbFXsla9fgkxXrr/psQoewbwScIS3ZtMw2qA09OWCmGWqrbE/hdvOhViUIN9V7X/
r0yi1Vax3LGn57XsmpdjRLewHMmWX47FS8Madi6t3MGH0UEaKO/8glc0ux7IDOo5mzuLWhDK
OMgtq6Z1G1hFAg02gmIKQF8wJaIjZOxg4dMM9rOWUpx0bzUgTAIwpqTbUmB31xSNQDcK66xy
CexIvN/lzd9j1mODj8zt4qMJ/VUfrzPvJTcfTl9vAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB
ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk
dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAF3KyJSpjyzP6/K96M9mSzy2k9QM
jI2E2WNqqv0e0lLRWvQTZUyBYQxu/ECnyfZaNizM0z0KjGYDS5o/eRmzTyPD/DiKtiujHgmV
s9PETmnJKkxT+sVmyBSH13AVUdXWZww8gygQYdOSpL8kz2sEkMjgVHjQX0FMjuExPt6OfFPF
MYIDJzCCAyMCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx
EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp
Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z
MAIDCCVBMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTAyMTAxODE0MzYzMVowIwYJKoZIhvcNAQkEMRYEFAe5eS5bDgNlhvt9NIE4
dqMh8dLbMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G
CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGB
naCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMIJUEwDQYJ
KoZIhvcNAQEBBQAEggEAqZim2udsakGyFMe/KstPLzuwgQSDOUS7kywODWf2V7cRnqwNIsGL
JbLgyGSO/XPDfWxXoe1CV7R6gFeVB24WdLNevcBwOKNyhbZi8NsREnuxNgMf3UcWPfzn0MpH
gEfBBj8u3JUAN2DGzEJplqMm5oKb7D6NLuKSMYI/qaG6ZkVpiVkkHxfHpJhwkIHPdGN5Jfpn
C6z200VAtCllAc9D2p1/3TUx2tnjWPESy7Mz6m3t0fOuqtdausepoZ7IrLO1225FonyjoiJJ
QvMQxUa7651Xrk63SHshGQdm+swZvZziF5sLmr6eFBtSHRmh4nvywZfu9Vejni8XV/beB5VJ
igAAAAAAAA==
--------------ms010407010507060506030101--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 8:21:46 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 8143437B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 08:21:43 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id 3127843E65
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 08:21:42 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9IFL8Yj085103;
Fri, 18 Oct 2002 18:21:25 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <00b001c276ba$1533dbf0$3500080a@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Jim McGrath" <jimmcgra@bellatlantic.net>,
"Luigi Rizzo" <rizzo@icir.org>
Cc: "Lars Eggert" <larse@ISI.EDU>, <freebsd-net@FreeBSD.ORG>,
<freebsdnic@mailbox.cps.intel.com>
References: <NDBBKKEELKBCJJBEGDECCEHJCGAA.jimmcgra@bellatlantic.net>
Subject: Re: ENOBUFS
Date: Fri, 18 Oct 2002 18:21:37 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
(I´ll throw in the address found in the README of the driver, maybe somebody
there has access to appropriate documentation / is willing to work on
documenting
tunables and optimizing the performance)
> I have to tread carefully here because I was under NDA at my previous
> company. My work was with the wx driver, but hardware problems are hardware
> problems. There are a lot of performance enhancing features in the 82544.
The chips I have are 82546. Is your recommendation to steer away from Intel
Gigabit Ethernet chips? What would be more optimal alternative?
> You will notice that the em driver does not use them. This may be for a
> reason :-( Our implementation ran with transmit interrupts disabled, so I
> can't comment on TIDV and am not allowed to comment on RIDV.
>
Maybe I´ll play with the value and see what happens. Any comments on
the question how to access the adapter structure from userland?
> The Receive Descriptor Threshold interrupt showed promise under high load
> (Rx interrupts disabled) but you would need to add a timeout function, 1
> msec. or faster, to process receive descriptors under low load.
>
Luigi´s polling work would be useful here. That would lead to incorrect
timestamps
on the packets, though?
Pete
>
> > -----Original Message-----
> > From: owner-freebsd-net@FreeBSD.ORG
> > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo
> > Sent: Friday, October 18, 2002 12:56 AM
> > To: Jim McGrath
> > Cc: Petri Helenius; Lars Eggert; freebsd-net@FreeBSD.ORG
> > Subject: Re: ENOBUFS
> >
> >
> > On Fri, Oct 18, 2002 at 12:49:04AM -0400, Jim McGrath wrote:
> > > Careful here. Read the errata sheet!! I do not believe the em
> > driver uses
> > > these parameters, and possibly for a good reason.
> >
> > as if i had access to the data sheets :)
> >
> > cheers
> > luigi
> > > Jim
> > >
> > > > -----Original Message-----
> > > > From: owner-freebsd-net@FreeBSD.ORG
> > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo
> > > > Sent: Thursday, October 17, 2002 11:12 PM
> > > > To: Petri Helenius
> > > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG
> > > > Subject: Re: ENOBUFS
> > > >
> > > >
> > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
> > > > ...
> > > > > I seem to get about 5-6 packets on an interrupt. Is this tunable? At
> > > >
> > > > just reading the source code, yes, it appears that the card has
> > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> > > > and usage in sys/dev/em/* . I don't know in what units are the values
> > > > (28 and 128, respectively), but it does appear that tx interrupts are
> > > > delayed a bit more than rx interrupts.
> > > >
> > > > They are not user-configurable at the moment though, you need
> > to rebuild
> > > > the kernel.
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-net" in the body of the message
> >
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 9:19: 1 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D7CC537B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 09:19:00 -0700 (PDT)
Received: from pop017.verizon.net (pop017pub.verizon.net [206.46.170.210])
by mx1.FreeBSD.org (Postfix) with ESMTP id 1617F43EEC
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 09:19:00 -0700 (PDT)
(envelope-from jimmcgra@bellatlantic.net)
Received: from Default ([141.154.237.113]) by pop017.verizon.net
(InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP
id <20021018161859.NYOR1423.pop017.verizon.net@Default>;
Fri, 18 Oct 2002 11:18:59 -0500
From: "Jim McGrath" <jimmcgra@bellatlantic.net>
To: "Petri Helenius" <pete@he.iki.fi>, "Luigi Rizzo" <rizzo@icir.org>
Cc: "Lars Eggert" <larse@ISI.EDU>, <freebsd-net@FreeBSD.ORG>,
<freebsdnic@mailbox.cps.intel.com>
Subject: RE: ENOBUFS
Date: Fri, 18 Oct 2002 12:19:21 -0400
Message-ID: <NDBBKKEELKBCJJBEGDECEEHMCGAA.jimmcgra@bellatlantic.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <00b001c276ba$1533dbf0$3500080a@PHE>
Importance: Normal
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at pop017.verizon.net from [141.154.237.113] at Fri, 18 Oct 2002 11:18:58 -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> The chips I have are 82546. Is your recommendation to steer away
> from Intel
> Gigabit Ethernet chips? What would be more optimal alternative?
>
The 82543/82544 chips worked well in vanilla configurations. I never played
with an 82546. The em driver is supported by Intel, so any chip features it
uses should be safe. When testing with a SmartBits, 64 byte packets and
high line utilization, I ran into problems when RIDV was enabled. This may
be fixed with the 82546, but I have no way of verifying this.
> Maybe I´ll play with the value and see what happens. Any comments on
> the question how to access the adapter structure from userland?
>
We added sysctls to the wx driver to allow tuning/testing of various
parameters. The same could be done to the em driver. You will likely need
to do more than just modify fields in the adapter structure. The control
register you are targeting will need to be rewritten by the sysctl.
Jim
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 9:53:34 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 25ED137B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 09:53:30 -0700 (PDT)
Received: from mx2.nersc.gov (mx2.nersc.gov [128.55.6.22])
by mx1.FreeBSD.org (Postfix) with ESMTP id DD06143E88
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 09:53:28 -0700 (PDT)
(envelope-from dart@nersc.gov)
Received: from mx2.nersc.gov (localhost [127.0.0.1])
by localhost.nersc.gov (Postfix) with ESMTP
id 1EA61593E; Fri, 18 Oct 2002 09:53:28 -0700 (PDT)
Received: from gemini.nersc.gov (gemini.nersc.gov [128.55.16.111])
by mx2.nersc.gov (Postfix) with ESMTP
id 9F4D6593C; Fri, 18 Oct 2002 09:53:27 -0700 (PDT)
Received: from gemini.nersc.gov (localhost [127.0.0.1])
by gemini.nersc.gov (Postfix) with ESMTP
id 559193B1AE; Fri, 18 Oct 2002 09:53:27 -0700 (PDT)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: "Jim McGrath" <jimmcgra@bellatlantic.net>
Cc: "Petri Helenius" <pete@he.iki.fi>,
"Luigi Rizzo" <rizzo@icir.org>, "Lars Eggert" <larse@ISI.EDU>,
freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
In-Reply-To: Message from "Jim McGrath" <jimmcgra@bellatlantic.net>
of "Fri, 18 Oct 2002 09:21:37 EDT." <NDBBKKEELKBCJJBEGDECOEHJCGAA.jimmcgra@bellatlantic.net>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_128925830P";
micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 18 Oct 2002 09:53:27 -0700
From: Eli Dart <dart@nersc.gov>
Message-Id: <20021018165327.559193B1AE@gemini.nersc.gov>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
--==_Exmh_128925830P
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
In reply to "Jim McGrath" <jimmcgra@bellatlantic.net> :
> =
> > Where could I get the errata sheet?
> =
> Product Specification Updates i.e. errata, and the Product Specificatio=
n
> itself are available from Intel under a Non Disclosure Agreement. Unle=
ss
> you work for a company that is doing business with Intel, they are prob=
ably
> not obtainable.
> >
> > Could the numbers be packet thresholds? 28 and 128 packets respective=
ly?
> >
> I can't answer that directly because of NDA. Let us apply some logic h=
ere.
> If they were packet counts, under very low load conditions e.g. a singl=
e
> telnet session, the telnet link would be unusable. This leads us to th=
e
> conclusion that they must be time values.
Based on the source code for the sk driver (look for "interrupt =
moderation" in if_sk.c) I would suspect that those values represent =
time in microseconds. My guess (based on no privileged information =
whatsoever) is that if we've not interrupted in <timeout> =
microseconds and we have something to send (or we've received =
something) go ahead and raise an interrupt.....
Just a guess. I'm perfectly willing to be wrong about this....
--eli
> =
> Jim
> > Anything else that can be done? Does PCI width/speed affect the amoun=
t of
> > time spent in the kernel interrupt or are the PCI transfers asynchron=
ous?
> >
> > Pete
> >
> > ----- Original Message -----
> > From: "Jim McGrath" <jimmcgra@bellatlantic.net>
> > To: "Luigi Rizzo" <rizzo@icir.org>; "Petri Helenius" <pete@he.iki.fi>=
> > Cc: "Lars Eggert" <larse@ISI.EDU>; <freebsd-net@FreeBSD.ORG>
> > Sent: Friday, October 18, 2002 7:49 AM
> > Subject: RE: ENOBUFS
> >
> >
> > > Careful here. Read the errata sheet!! I do not believe the em
> > driver uses
> > > these parameters, and possibly for a good reason.
> > >
> > > Jim
> > >
> > > > -----Original Message-----
> > > > From: owner-freebsd-net@FreeBSD.ORG
> > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Luigi Rizzo
> > > > Sent: Thursday, October 17, 2002 11:12 PM
> > > > To: Petri Helenius
> > > > Cc: Lars Eggert; freebsd-net@FreeBSD.ORG
> > > > Subject: Re: ENOBUFS
> > > >
> > > >
> > > > On Thu, Oct 17, 2002 at 11:55:24PM +0300, Petri Helenius wrote:
> > > > ...
> > > > > I seem to get about 5-6 packets on an interrupt. Is this tunabl=
e? At
> > > >
> > > > just reading the source code, yes, it appears that the card has
> > > > support for delayed rx/tx interrupts -- see RIDV and TIDV definit=
ions
> > > > and usage in sys/dev/em/* . I don't know in what units are the va=
lues
> > > > (28 and 128, respectively), but it does appear that tx interrupts=
are
> > > > delayed a bit more than rx interrupts.
> > > >
> > > > They are not user-configurable at the moment though, you need
> > to rebuild
> > > > the kernel.
> > > >
> > > > cheers
> > > > luigi
> > > >
> > > > > 50kpps the card generates 10k interrupts a second. Sending gene=
rates
> > > > > way less. This is about 300Mbps so with the average packet size=
of
> > > > > 750 there should be room for more packets on the interface queu=
e
> > > > > before needing to service an interrupt?
> > > > >
> > > > > What=B4s the way to access kernel adapter-structure? Is there
> > an utility
> > > > > that can view the values there?
> > > > > >
> > > > > Pete
> > > > >
> > > > >
> > > >
> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > > with "unsubscribe freebsd-net" in the body of the message
> > > >
> > >
> > >
> >
> >
> =
> =
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
--==_Exmh_128925830P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: This is a comment.
iD8DBQE9sDyHLTFEeF+CsrMRAj3SAKDnmZM7GH1u8JAajyz6boZB7oeLEQCgiQJJ
5jP8QSLOwQE2OcI/xd9xbuo=
=PgrR
-----END PGP SIGNATURE-----
--==_Exmh_128925830P--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10: 5:52 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 5BFA337B401; Fri, 18 Oct 2002 10:05:50 -0700 (PDT)
Received: from search.sparks.net (d-207-5-180-136.gwi.net [207.5.180.136])
by mx1.FreeBSD.org (Postfix) with ESMTP
id EE45843E9C; Fri, 18 Oct 2002 10:05:49 -0700 (PDT)
(envelope-from dmiller@search.sparks.net)
Received: by search.sparks.net (Postfix, from userid 100)
id D7197D999; Fri, 18 Oct 2002 12:59:27 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
by search.sparks.net (Postfix) with ESMTP
id D1CADD98C; Fri, 18 Oct 2002 12:59:27 -0400 (EDT)
Date: Fri, 18 Oct 2002 12:59:27 -0400 (EDT)
From: David Miller <dmiller@search.sparks.net>
To: Attila Nagy <bra@fsn.hu>
Cc: "Kenneth D. Merry" <ken@kdm.org>,
Christopher Smith <csmith@its.uq.edu.au>, hardware@FreeBSD.ORG,
net@FreeBSD.ORG
Subject: Re: High interrupt load on firewalls
In-Reply-To: <Pine.LNX.4.44.0210091011560.3631-100000@scribble.fsn.hu>
Message-ID: <Pine.BSF.4.21.0210181257350.90681-100000@search.sparks.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Wed, 9 Oct 2002, Attila Nagy wrote:
With a dc ethernet card and ~45K packets per second, an XP1700 system went
from > 50% interrupt to < 1%. I was astounded at the change!
If all it takes to get Gb interfaces polling is to send Luigi a card then
he needs to send me his shipping address:)
--- David
> Hello,
>
> > You might want to try out some of the Intel gigabit boards. At least
> > we've got an engineer from Intel who maintains the driver.
> I'm far from being a FreeBSD expert, but Luigi Rizzo's polling patch
> helped me a lot in similar cases to get better performance.
>
> >From POLLING(4):
> DESCRIPTION
> "Device polling" (polling for brevity) refers to a technique to handle
> devices that does not rely on the latter to generate interrupts when they
> need attention, but rather lets the CPU poll devices to service their
> needs. This might seem inefficient and counterintuitive, but when done
> properly, polling gives more control to the operating system on when and
> how to handle devices, with a number of advantages in terms of system
> responsivity and performance.
>
> AFAIK there are only two problems about that:
> SUPPORTED DEVICES
> Polling requires explicit modifications to the device drivers. As of
> this writing, the dc, fxp, rl and sis devices are supported, with other
> in the works.
>
> (no Gigabit cards)
>
> and
> sys/kern/kern_poll.c:
> [...]
> #ifdef SMP
> #include "opt_lint.h"
> #ifndef COMPILING_LINT
> #error DEVICE_POLLING is not compatible with SMP
> #endif
> #endif
> [...]
>
> (no SMP support)
>
> As stated above, I'm not an expert, but my opinion is that polling would
> be the best on the Gigabit cards (due to their capacity) and not the Fast
> Ethernet ones.
>
> Maybe we could start sending GE hardware to Luigi :)
>
> ----------[ Free Software ISOs - http://www.fsn.hu/?f=download ]----------
> Attila Nagy e-mail: Attila.Nagy@fsn.hu
> Free Software Network (FSN.HU) phone @work: +361 210 1415 (194)
> cell.: +3630 306 6758
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hardware" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10:11: 2 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 788EE37B401
for <net@freebsd.org>; Fri, 18 Oct 2002 10:10:59 -0700 (PDT)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38])
by mx1.FreeBSD.org (Postfix) with ESMTP id C4B6043EAF
for <net@freebsd.org>; Fri, 18 Oct 2002 10:10:58 -0700 (PDT)
(envelope-from crist.clark@attbi.com)
Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com
(InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
id <20021018171057.DCL18217.rwcrmhc51.attbi.com@blossom.cjclark.org>
for <net@freebsd.org>; Fri, 18 Oct 2002 17:10:57 +0000
Received: from blossom.cjclark.org (localhost. [127.0.0.1])
by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g9IHAvWn045491
for <net@freebsd.org>; Fri, 18 Oct 2002 10:10:57 -0700 (PDT)
(envelope-from crist.clark@attbi.com)
Received: (from cjc@localhost)
by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g9IHAuB5045490
for net@freebsd.org; Fri, 18 Oct 2002 10:10:56 -0700 (PDT)
X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f
Date: Fri, 18 Oct 2002 10:10:55 -0700
From: "Crist J. Clark" <crist.clark@attbi.com>
To: net@freebsd.org
Subject: Strange FTP TCP Window Problem
Message-ID: <20021018171055.GA45449@blossom.cjclark.org>
Reply-To: cjclark@alum.mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
X-URL: http://people.freebsd.org/~cjc/
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This has got me stumped. I must be missing something obvious. I am
trying to download some files via FTP. There are four files. Three
download just fine, one just won't go. Since the three work fine, I
assume it's not PORT vs. PASV, NAT, or other firewall issues, that is,
the usual suspects have been eliminated. But what is really strange is
that it looks like _my client_ is the one causing the headaches.
Here is a tcpdump(8) of the data connection. Keep an eye on the window
values my client is sending back,
09:15:11.097800 a.b.c.136.29826 > d.e.f.17.18747: S [tcp sum ok] 2410623756:2410623756(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 6027020 0> (ttl 64, id 50031, len 64)
09:15:11.118335 d.e.f.17.18747 > a.b.c.136.29826: S [tcp sum ok] 2932757104:2932757104(0) ack 2410623757 win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 1679619 6027020> (ttl 56, id 24108, len 60)
09:15:11.118443 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1 win 16500 <nop,nop,timestamp 6027020 1679619> (ttl 64, id 43640, len 52)
09:15:11.156424 d.e.f.17.18747 > a.b.c.136.29826: . 1:501(500) ack 1 win 16384 <nop,nop,timestamp 1679619 6027020> [tos 0x8] (ttl 56, id 24111, len 552)
09:15:11.159468 d.e.f.17.18747 > a.b.c.136.29826: . 501:1001(500) ack 1 win 16384 <nop,nop,timestamp 1679619 6027020> [tos 0x8] (ttl 56, id 24112, len 552)
09:15:11.227371 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1001 win 15500 <nop,nop,timestamp 6027020 1679619> [tos 0x8] (ttl 64, id 61006, len 52)
09:15:11.258205 d.e.f.17.18747 > a.b.c.136.29826: . 1001:1501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24113, len 552)
09:15:11.261225 d.e.f.17.18747 > a.b.c.136.29826: . 1501:2001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24114, len 552)
09:15:11.279923 d.e.f.17.18747 > a.b.c.136.29826: . 2001:2501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24115, len 552)
09:15:11.427395 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 2501 win 14000 <nop,nop,timestamp 6027021 1679620> [tos 0x8] (ttl 64, id 40196, len 52)
09:15:11.457865 d.e.f.17.18747 > a.b.c.136.29826: . 2501:3001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24116, len 552)
09:15:11.461105 d.e.f.17.18747 > a.b.c.136.29826: . 3001:3501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24117, len 552)
09:15:11.480485 d.e.f.17.18747 > a.b.c.136.29826: . 3501:4001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24118, len 552)
09:15:11.483702 d.e.f.17.18747 > a.b.c.136.29826: . 4001:4501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24119, len 552)
09:15:11.627707 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 4501 win 12000 <nop,nop,timestamp 6027021 1679620> [tos 0x8] (ttl 64, id 44302, len 52)
09:15:11.648692 d.e.f.17.18747 > a.b.c.136.29826: . 4501:5001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24120, len 552)
09:15:11.659731 d.e.f.17.18747 > a.b.c.136.29826: . 5001:5501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24121, len 552)
09:15:11.670448 d.e.f.17.18747 > a.b.c.136.29826: . 5501:6001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24122, len 552)
09:15:11.673581 d.e.f.17.18747 > a.b.c.136.29826: . 6001:6501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24123, len 552)
09:15:11.692780 d.e.f.17.18747 > a.b.c.136.29826: . 6501:7001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24124, len 552)
09:15:11.827393 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 7001 win 9500 <nop,nop,timestamp 6027021 1679620> [tos 0x8] (ttl 64, id 38068, len 52)
09:15:11.855900 d.e.f.17.18747 > a.b.c.136.29826: . 7001:7501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24125, len 552)
09:15:11.860077 d.e.f.17.18747 > a.b.c.136.29826: . 7501:8001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24126, len 552)
09:15:11.878834 d.e.f.17.18747 > a.b.c.136.29826: . 8001:8501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24127, len 552)
09:15:11.881856 d.e.f.17.18747 > a.b.c.136.29826: . 8501:9001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24128, len 552)
09:15:11.892382 d.e.f.17.18747 > a.b.c.136.29826: . 9001:9501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24129, len 552)
09:15:11.903415 d.e.f.17.18747 > a.b.c.136.29826: . 9501:10001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24130, len 552)
09:15:12.027385 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 10001 win 6500 <nop,nop,timestamp 6027022 1679621> [tos 0x8] (ttl 64, id 60342, len 52)
09:15:12.052757 d.e.f.17.18747 > a.b.c.136.29826: . 10001:10501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24131, len 552)
09:15:12.063589 d.e.f.17.18747 > a.b.c.136.29826: . 10501:11001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24132, len 552)
09:15:12.074515 d.e.f.17.18747 > a.b.c.136.29826: . 11001:11501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24133, len 552)
09:15:12.078151 d.e.f.17.18747 > a.b.c.136.29826: . 11501:12001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24134, len 552)
09:15:12.096930 d.e.f.17.18747 > a.b.c.136.29826: . 12001:12501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24135, len 552)
09:15:12.099980 d.e.f.17.18747 > a.b.c.136.29826: . 12501:13001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24136, len 552)
09:15:12.110647 d.e.f.17.18747 > a.b.c.136.29826: . 13001:13501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24137, len 552)
09:15:12.227383 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 13501 win 3000 <nop,nop,timestamp 6027022 1679621> [tos 0x8] (ttl 64, id 51576, len 52)
09:15:12.264837 d.e.f.17.18747 > a.b.c.136.29826: . 13501:14001(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24138, len 552)
09:15:12.268095 d.e.f.17.18747 > a.b.c.136.29826: . 14001:14501(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24139, len 552)
09:15:12.278653 d.e.f.17.18747 > a.b.c.136.29826: . 14501:15001(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24140, len 552)
09:15:12.289849 d.e.f.17.18747 > a.b.c.136.29826: . 15001:15501(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24141, len 552)
09:15:12.293592 d.e.f.17.18747 > a.b.c.136.29826: . 15501:16001(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24142, len 552)
09:15:12.427402 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16001 win 500 <nop,nop,timestamp 6027023 1679622> [tos 0x8] (ttl 64, id 41001, len 52)
09:15:17.202100 d.e.f.17.18747 > a.b.c.136.29826: . 16001:16501(500) ack 1 win 16384 <nop,nop,timestamp 1679631 6027020> [tos 0x8] (ttl 56, id 24157, len 552)
09:15:17.227476 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027032 1679631> [tos 0x8] (ttl 64, id 59052, len 52)
09:15:22.186435 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679641 6027020> [tos 0x8] (ttl 56, id 24183, len 53)
09:15:22.186625 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027042 1679641> [tos 0x8] (ttl 64, id 55942, len 52)
09:15:30.194393 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679657 6027020> [tos 0x8] (ttl 56, id 24221, len 53)
09:15:30.195913 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027058 1679657> [tos 0x8] (ttl 64, id 14020, len 52)
09:15:46.198335 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679689 6027020> [tos 0x8] (ttl 56, id 24333, len 53)
09:15:46.198583 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027090 1679689> [tos 0x8] (ttl 64, id 16087, len 52)
09:16:18.201164 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679753 6027020> [tos 0x8] (ttl 56, id 24500, len 53)
09:16:18.201409 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027154 1679753> [tos 0x8] (ttl 64, id 30338, len 52)
09:17:18.194176 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679873 6027020> [tos 0x8] (ttl 56, id 25061, len 53)
09:17:18.194430 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027274 1679873> [tos 0x8] (ttl 64, id 20615, len 52)
09:18:18.193763 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679993 6027020> [tos 0x8] (ttl 56, id 25447, len 53)
09:18:18.194005 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027394 1679993> [tos 0x8] (ttl 64, id 12107, len 52)
09:19:18.186418 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1680113 6027020> [tos 0x8] (ttl 56, id 25862, len 53)
09:19:18.187970 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027514 1680113> [tos 0x8] (ttl 64, id 51084, len 52)
And this just hangs here forever.
I can't see why the client is refusing to accept more data. Like I
said, I'll bet I'm not seeing something obvious, but all of the SEQ
and ACK numbers look good to me. I should note that this isn't just an
issue with the FreeBSD ftp client. I get the same result with Windows,
Solaris, Cygwin, and OpenBSD too.
Why is it happening and how do I get around this?
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10:18: 4 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 4806737B401; Fri, 18 Oct 2002 10:18:03 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP
id DFEC943EAC; Fri, 18 Oct 2002 10:18:02 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IHI2pJ082828;
Fri, 18 Oct 2002 10:18:02 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9IHI2tO082827;
Fri, 18 Oct 2002 10:18:02 -0700 (PDT)
(envelope-from rizzo)
Date: Fri, 18 Oct 2002 10:18:02 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: David Miller <dmiller@search.sparks.net>
Cc: Attila Nagy <bra@fsn.hu>, "Kenneth D. Merry" <ken@kdm.org>,
Christopher Smith <csmith@its.uq.edu.au>, hardware@FreeBSD.ORG,
net@FreeBSD.ORG
Subject: Re: High interrupt load on firewalls
Message-ID: <20021018101802.A82792@carp.icir.org>
References: <Pine.LNX.4.44.0210091011560.3631-100000@scribble.fsn.hu> <Pine.BSF.4.21.0210181257350.90681-100000@search.sparks.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.BSF.4.21.0210181257350.90681-100000@search.sparks.net>; from dmiller@search.sparks.net on Fri, Oct 18, 2002 at 12:59:27PM -0400
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, Oct 18, 2002 at 12:59:27PM -0400, David Miller wrote:
> On Wed, 9 Oct 2002, Attila Nagy wrote:
>
> With a dc ethernet card and ~45K packets per second, an XP1700 system went
> from > 50% interrupt to < 1%. I was astounded at the change!
that is partly cheating, because with polling, some of the work which
was done in an interrupt context is done elsewere. Still you might
have some significant load reduction, i admit :)
> If all it takes to get Gb interfaces polling is to send Luigi a card then
> he needs to send me his shipping address:)
all it takes is to look at the source code in some of the supported
cards -- the changes are clearly marked by #ifdef DEVICE_POLLING/#endif
blocks and are rather trivial in most cases (not all of them, 'fxp' was
particularly tricky to get right!).
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10:22: 4 2002
Delivered-To: freebsd-net@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 916)
id C553937B401; Fri, 18 Oct 2002 10:22:03 -0700 (PDT)
Date: Fri, 18 Oct 2002 10:22:03 -0700
From: Prafulla Deuskar <pdeuskar@freebsd.org>
To: Petri Helenius <pete@he.iki.fi>
Cc: Luigi Rizzo <rizzo@icir.org>, Lars Eggert <larse@ISI.EDU>,
freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021018102203.A86452@hub.freebsd.org>
References: <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu> <0be401c2761f$855af670$8c2a40c1@PHE> <20021017201158.A75351@carp.icir.org> <0d0b01c27680$b553ba90$8c2a40c1@PHE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <0d0b01c27680$b553ba90$8c2a40c1@PHE>; from pete@he.iki.fi on Fri, Oct 18, 2002 at 11:31:08AM +0300
X-Operating-System: FreeBSD 4.7-RC on an i386
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Transmit/Receive Interrupt Delay values are in units of 1.024 microseconds.
The em driver currently uses these to enable interrupt coalescing on the cards.
Thanks,
Prafulla
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10:27:29 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id EDB5337B401
for <freebsd-net@FreeBSD.org>; Fri, 18 Oct 2002 10:27:27 -0700 (PDT)
Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77])
by mx1.FreeBSD.org (Postfix) with ESMTP id 422C543E9C
for <freebsd-net@FreeBSD.org>; Fri, 18 Oct 2002 10:27:27 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224])
by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IHR5LE362954;
Fri, 18 Oct 2002 13:27:05 -0400
Received: from localhost (localhost [127.0.0.1])
by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IHR4OQ001632;
Fri, 18 Oct 2002 10:27:04 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Date: Fri, 18 Oct 2002 10:27:04 -0700 (PDT)
From: Kelly Yancey <kbyanc@posi.net>
To: Petri Helenius <pete@he.iki.fi>
Cc: Luigi Rizzo <rizzo@icir.org>, Lars Eggert <larse@ISI.EDU>,
<freebsd-net@FreeBSD.org>
Subject: Re: ENOBUFS
In-Reply-To: <0d0b01c27680$b553ba90$8c2a40c1@PHE>
Message-ID: <20021018102515.V1611-100000@gateway.posi.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Petri Helenius wrote:
> >
> > just reading the source code, yes, it appears that the card has
> > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> > and usage in sys/dev/em/* . I don't know in what units are the values
> > (28 and 128, respectively), but it does appear that tx interrupts are
> > delayed a bit more than rx interrupts.
> >
> The thing what is looking suspect is also the "small packet interrupt" fe=
ature
> which does not seem to get modified in the em driver but is on the define=
s.
>
> If that would be on by default, we=B4d probably see interrupts "too often=
"
> because it tries to optimize interrupts for good throughput on small numb=
er
> of TCP streams.
>
Hmm. Might that explain the abysmal performance of the em driver with
packets smaller than 333 bytes?
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
FreeBSD, The Power To Serve: http://www.freebsd.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10:33:21 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 711DB37B404
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 10:33:20 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id D5CF343E88
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 10:33:19 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IHXJpJ082999;
Fri, 18 Oct 2002 10:33:19 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9IHXJ46082998;
Fri, 18 Oct 2002 10:33:19 -0700 (PDT)
(envelope-from rizzo)
Date: Fri, 18 Oct 2002 10:33:19 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Kelly Yancey <kbyanc@posi.net>
Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>,
freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021018103319.A82982@carp.icir.org>
References: <0d0b01c27680$b553ba90$8c2a40c1@PHE> <20021018102515.V1611-100000@gateway.posi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021018102515.V1611-100000@gateway.posi.net>; from kbyanc@posi.net on Fri, Oct 18, 2002 at 10:27:04AM -0700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
...
> Hmm. Might that explain the abysmal performance of the em driver with
> packets smaller than 333 bytes?
what do you mean ? it works great for me. even on -current i
can push out over 400kpps (64byte frames) on a 2.4GHz box.
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10:36:41 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 7F5A837B401; Fri, 18 Oct 2002 10:36:40 -0700 (PDT)
Received: from search.sparks.net (d-207-5-180-136.gwi.net [207.5.180.136])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 2662D43E9E; Fri, 18 Oct 2002 10:36:40 -0700 (PDT)
(envelope-from dmiller@search.sparks.net)
Received: by search.sparks.net (Postfix, from userid 100)
id 4CE53D999; Fri, 18 Oct 2002 13:30:18 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
by search.sparks.net (Postfix) with ESMTP
id 3D224D98C; Fri, 18 Oct 2002 13:30:18 -0400 (EDT)
Date: Fri, 18 Oct 2002 13:30:18 -0400 (EDT)
From: David Miller <dmiller@search.sparks.net>
To: Luigi Rizzo <rizzo@icir.org>
Cc: Attila Nagy <bra@fsn.hu>, "Kenneth D. Merry" <ken@kdm.org>,
Christopher Smith <csmith@its.uq.edu.au>, hardware@FreeBSD.ORG,
net@FreeBSD.ORG
Subject: Re: High interrupt load on firewalls
In-Reply-To: <20021018101802.A82792@carp.icir.org>
Message-ID: <Pine.BSF.4.21.0210181328230.90681-100000@search.sparks.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> On Fri, Oct 18, 2002 at 12:59:27PM -0400, David Miller wrote:
> > On Wed, 9 Oct 2002, Attila Nagy wrote:
> >
> > With a dc ethernet card and ~45K packets per second, an XP1700 system went
> > from > 50% interrupt to < 1%. I was astounded at the change!
>
> that is partly cheating, because with polling, some of the work which
> was done in an interrupt context is done elsewere. Still you might
> have some significant load reduction, i admit :)
Very significant. The system went from maxed out at 30K pps to 35% idle
at > 40K pps.
I suspect it's an extreme case with the dc card. I've observed less with
the fxp.
Thanks for all the work Luigi:)
--- David
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10:38:28 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 2B5CA37B412
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 10:38:27 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id C6BAD43E9E
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 10:38:26 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IHcPpJ083056;
Fri, 18 Oct 2002 10:38:25 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9IHcP8T083055;
Fri, 18 Oct 2002 10:38:25 -0700 (PDT)
(envelope-from rizzo)
Date: Fri, 18 Oct 2002 10:38:25 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Petri Helenius <pete@he.iki.fi>
Cc: Jim McGrath <jimmcgra@bellatlantic.net>,
Lars Eggert <larse@ISI.EDU>, freebsd-net@FreeBSD.ORG,
freebsdnic@mailbox.cps.intel.com
Subject: Re: ENOBUFS
Message-ID: <20021018103825.B82982@carp.icir.org>
References: <NDBBKKEELKBCJJBEGDECCEHJCGAA.jimmcgra@bellatlantic.net> <00b001c276ba$1533dbf0$3500080a@PHE>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <00b001c276ba$1533dbf0$3500080a@PHE>; from pete@he.iki.fi on Fri, Oct 18, 2002 at 06:21:37PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, Oct 18, 2002 at 06:21:37PM +0300, Petri Helenius wrote:
...
> Luigi´s polling work would be useful here. That would lead to incorrect
> timestamps
> on the packets, though?
polling introduce an extra uncertainty which might be as large as
an entire clock tick, yes.
But even with interrupts, you cannot trust the time when the interrupt
driver is run -- there are cases where an ISR is delayed by 10ms or more.
And even when it runs, it might take quite a bit of time (up to a
few 100's of microseconds) to drain the receive queue from packets
received earlier.
in normal cases, timestamps are reasonably accurate in both cases.
In special cases, the error induced by having interrupts blocked
causes errors which are much larger than polling alone.
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10:45:20 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 4E3E137B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 10:45:19 -0700 (PDT)
Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101])
by mx1.FreeBSD.org (Postfix) with ESMTP id 503C243EB2
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 10:45:18 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224])
by pimout2-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IHjEcK036722;
Fri, 18 Oct 2002 13:45:15 -0400
Received: from localhost (localhost [127.0.0.1])
by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IHjDOQ001677;
Fri, 18 Oct 2002 10:45:13 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Date: Fri, 18 Oct 2002 10:45:13 -0700 (PDT)
From: Kelly Yancey <kbyanc@posi.net>
To: Luigi Rizzo <rizzo@icir.org>
Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>,
<freebsd-net@FreeBSD.ORG>
Subject: Re: ENOBUFS
In-Reply-To: <20021018103319.A82982@carp.icir.org>
Message-ID: <20021018103653.V1611-100000@gateway.posi.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> ...
> > Hmm. Might that explain the abysmal performance of the em driver with
> > packets smaller than 333 bytes?
>
> what do you mean ? it works great for me. even on -current i
> can push out over 400kpps (64byte frames) on a 2.4GHz box.
>
> luigi
>
Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
plugged into PCI-X bus:
FrameSize TxFrames RxFrames LostFrames Lost (%)
330 249984 129518 120466 48.19
331 249144 127726 121418 48.73
332 248472 140817 107655 43.33
333 247800 247800 0 0
It has no trouble handling frames 333 bytes or larger. But for any frame
332 bytes or smaller we consistently see ~50% packet loss. This same machine
easily pushes ~100Mps with the very same frame sizes using a bge card rather
than em.
I've gotten the same results with both em driver version 1.3.14 and 1.3.15
on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
FreeBSD, The Power To Serve: http://www.freebsd.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 10:59:24 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 10E1C37B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 10:59:23 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id AB78043EA3
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 10:59:22 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IHxMpJ083285;
Fri, 18 Oct 2002 10:59:22 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9IHxMFR083284;
Fri, 18 Oct 2002 10:59:22 -0700 (PDT)
(envelope-from rizzo)
Date: Fri, 18 Oct 2002 10:59:22 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Kelly Yancey <kbyanc@posi.net>
Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>,
freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021018105922.E82982@carp.icir.org>
References: <20021018103319.A82982@carp.icir.org> <20021018103653.V1611-100000@gateway.posi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021018103653.V1611-100000@gateway.posi.net>; from kbyanc@posi.net on Fri, Oct 18, 2002 at 10:45:13AM -0700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
How is the measurement done, does the box under test act as a router
with the smartbit pushing traffic in and expecting it back ?
The numbers are strange, anyways.
A frame of N bytes takes (N*8+160) nanoseconds on the wire, which
for 330-byte frames should amount to 1000000/(330*8+160) ~= 357kpps,
not the 249 or so you are seeing. Looks as if the times were 40% off.
cheers
luigi
On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote:
...
> > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> >
> > luigi
> >
>
> Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> plugged into PCI-X bus:
>
> FrameSize TxFrames RxFrames LostFrames Lost (%)
> 330 249984 129518 120466 48.19
> 331 249144 127726 121418 48.73
> 332 248472 140817 107655 43.33
> 333 247800 247800 0 0
>
> It has no trouble handling frames 333 bytes or larger. But for any frame
> 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> easily pushes ~100Mps with the very same frame sizes using a bge card rather
> than em.
>
> I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
>
> Kelly
>
> --
> Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> FreeBSD, The Power To Serve: http://www.freebsd.org/
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 11:11:49 2002
Delivered-To: freebsd-net@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 916)
id 0B7C837B401; Fri, 18 Oct 2002 11:11:48 -0700 (PDT)
Date: Fri, 18 Oct 2002 11:11:48 -0700
From: Prafulla Deuskar <pdeuskar@freebsd.org>
To: Kelly Yancey <kbyanc@posi.net>
Cc: Luigi Rizzo <rizzo@icir.org>, Petri Helenius <pete@he.iki.fi>,
Lars Eggert <larse@ISI.EDU>, freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021018111147.A91108@hub.freebsd.org>
References: <20021018103319.A82982@carp.icir.org> <20021018103653.V1611-100000@gateway.posi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021018103653.V1611-100000@gateway.posi.net>; from kbyanc@posi.net on Fri, Oct 18, 2002 at 10:45:13AM -0700
X-Operating-System: FreeBSD 4.7-RC on an i386
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
FYI. 82543 doesn't support PCI-X protocol.
For PCI-X support use 82544, 82545 or 82546 based cards.
-Prafulla
Kelly Yancey [kbyanc@posi.net] wrote:
> On Fri, 18 Oct 2002, Luigi Rizzo wrote:
>
> > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> > ...
> > > Hmm. Might that explain the abysmal performance of the em driver with
> > > packets smaller than 333 bytes?
> >
> > what do you mean ? it works great for me. even on -current i
> > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> >
> > luigi
> >
>
> Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> plugged into PCI-X bus:
>
> FrameSize TxFrames RxFrames LostFrames Lost (%)
> 330 249984 129518 120466 48.19
> 331 249144 127726 121418 48.73
> 332 248472 140817 107655 43.33
> 333 247800 247800 0 0
>
> It has no trouble handling frames 333 bytes or larger. But for any frame
> 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> easily pushes ~100Mps with the very same frame sizes using a bge card rather
> than em.
>
> I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
>
> Kelly
>
> --
> Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> FreeBSD, The Power To Serve: http://www.freebsd.org/
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 11:14: 2 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5EA8E37B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 11:14:00 -0700 (PDT)
Received: from pimout4-ext.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8BE6143E7B
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 11:13:59 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224])
by pimout4-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IIDtoi270898;
Fri, 18 Oct 2002 14:13:56 -0400
Received: from localhost (localhost [127.0.0.1])
by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IIDtOQ001720;
Fri, 18 Oct 2002 11:13:55 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Date: Fri, 18 Oct 2002 11:13:54 -0700 (PDT)
From: Kelly Yancey <kbyanc@posi.net>
To: Luigi Rizzo <rizzo@icir.org>
Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>,
<freebsd-net@FreeBSD.ORG>
Subject: Re: ENOBUFS
In-Reply-To: <20021018105922.E82982@carp.icir.org>
Message-ID: <20021018110238.T1611-100000@gateway.posi.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> How is the measurement done, does the box under test act as a router
> with the smartbit pushing traffic in and expecting it back ?
>
The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is
configured with 7 VLANs. THe SmartBit produces X byte UDP datagrams that go
through a Foundry ServerIron switch for VLAN tagging and then to the GigE
interface (where they are untagged). The box is acting as a router and all
traffic is directed out the fxp interface where it returns to the SmartBit.
> The numbers are strange, anyways.
>
> A frame of N bytes takes (N*8+160) nanoseconds on the wire, which
> for 330-byte frames should amount to 1000000/(330*8+160) ~= 357kpps,
> not the 249 or so you are seeing. Looks as if the times were 40% off.
>
Yeah, I've never made to much sense of the actual numbers myself. Our
resident SmartBit expert runs the tests and provides me with the results. I
use them more for getting an idea of the relative performance of one
configuration over another and not as absolute numbers themselves. I'll check
with our resident expert and see if he can explain how it calculates those
numbers. The point being, though, that there is an undeniable drop-off with
332 byte or smaller packets. We have never seen any such drop-off using the
bge driver.
Thanks,
Kelly
> cheers
> luigi
>
> On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote:
> ...
> > > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> > >
> > > luigi
> > >
> >
> > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> > plugged into PCI-X bus:
> >
> > FrameSize TxFrames RxFrames LostFrames Lost (%)
> > 330 249984 129518 120466 48.19
> > 331 249144 127726 121418 48.73
> > 332 248472 140817 107655 43.33
> > 333 247800 247800 0 0
> >
> > It has no trouble handling frames 333 bytes or larger. But for any frame
> > 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> > easily pushes ~100Mps with the very same frame sizes using a bge card rather
> > than em.
> >
> > I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
> >
> > Kelly
> >
> > --
> > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> > FreeBSD, The Power To Serve: http://www.freebsd.org/
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-net" in the body of the message
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 11:25:29 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 6084A37B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 11:25:27 -0700 (PDT)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88])
by mx1.FreeBSD.org (Postfix) with ESMTP id E37A843E77
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 11:25:26 -0700 (PDT)
(envelope-from crist.clark@attbi.com)
Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com
(InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
id <20021018182526.CAJZ11892.rwcrmhc52.attbi.com@blossom.cjclark.org>;
Fri, 18 Oct 2002 18:25:26 +0000
Received: from blossom.cjclark.org (localhost. [127.0.0.1])
by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g9IIPNWn045992;
Fri, 18 Oct 2002 11:25:23 -0700 (PDT)
(envelope-from crist.clark@attbi.com)
Received: (from cjc@localhost)
by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g9IIPM4w045991;
Fri, 18 Oct 2002 11:25:22 -0700 (PDT)
X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f
Date: Fri, 18 Oct 2002 11:25:22 -0700
From: "Crist J. Clark" <crist.clark@attbi.com>
To: Matthew Zahorik <matt@hottub.org>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: IPSEC/NAT issues
Message-ID: <20021018182522.GC45449@blossom.cjclark.org>
Reply-To: "Crist J. Clark" <cjc@FreeBSD.ORG>
References: <20021018002729.T66900-100000@mail.allcaps.org> <Pine.GSO.4.40.0210180628271.5762-100000@hottub>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.40.0210180628271.5762-100000@hottub>
User-Agent: Mutt/1.4i
X-URL: http://people.freebsd.org/~cjc/
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, Oct 18, 2002 at 06:39:51AM -0700, Matthew Zahorik wrote:
> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
>
> > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> > packet will get rejected when it reaches the other IPSEC node.
>
> Not exactly true. I use a Windows Nortel Contivity client behind NAT just
> fine.
>
> If you're using an AH association (header authentication) that will not
> pass through NAT. I'm sure someone on this list may come up with a fancy
> trick for FreeBSD, but generally the statement is true. AH detects the
> NAT changes as header corruption.
>
> But if you're only using ESP (encryption of payload) that will work fine.
>
> Most turn on both AH and ESP by default, but that isn't always the case as
> in the Nortel boxes.
Not exactly true. The current ESP standard has its own header
authentification mechanism. To verify end-to-end header integrity, you
need only use ESP with this option turned on (excuse me if I don't go
to the RFC to remind myself of the formal name of the option).
And as another data point, the Cisco VPN Concentrator (formerly
Altiga) run just fine through NAT by default. They do ESP without
header integrity checks and UDP encapsulation of the ESP to make it
easier to run it through NAT (although that isn't "real" IPsec
anymore).
> On another note, I'd *love* to use my FreeBSD NAT box as a VPN tunnel
> endpoint rather than my windows boxes. It's a dynamic IP, so it's
> catch-22 right now. I can't create a tunnel or SPD policy entry before I
> know the IP addresses, and IKE/racoon can't start without those things.
>
> So, if someone happens to be ripping the IPsec processing apart, something
> to eliminate this catch-22 would be nice (: (spd entries pointing to an
> unconfigured or dummy tunnel, for example)
What's the problem with just having the script that builds the SPD
discover the IP address on its own?
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 11:26:55 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 0110537B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 11:26:53 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8CFAF43EAC
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 11:26:52 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IIQqpJ083507;
Fri, 18 Oct 2002 11:26:52 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9IIQqLh083506;
Fri, 18 Oct 2002 11:26:52 -0700 (PDT)
(envelope-from rizzo)
Date: Fri, 18 Oct 2002 11:26:52 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Kelly Yancey <kbyanc@posi.net>
Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>,
freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021018112652.A83405@carp.icir.org>
References: <20021018105922.E82982@carp.icir.org> <20021018110238.T1611-100000@gateway.posi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20021018110238.T1611-100000@gateway.posi.net>; from kbyanc@posi.net on Fri, Oct 18, 2002 at 11:13:54AM -0700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Oh, I *thought* the numbers you reported were pps but now i see that
nowhere you mentioned that.
But if things are as you say, i am seriously puzzled on what you
are trying to measure -- the output interface (fxp) is a 100Mbit/s
card which cannot possibly support the load you are trying to offer
to saturate the input link.
You should definitely clarify how fast the smartbits unit is pushing
out traffic, and whether its speed depends on the measured RTT.
It might well be that what you are
seeing is saturation of ipintrq, which happens because of some
strange timing issue -- nothing to do with the board.
In any case, at least in my experience, a 1GHz box with two em
cards can easily forward between 350 and 400kpps (64-byte frames) with a
4.6-ish kernel, and a 2.4GHz box goes above 650kpps.
cheers
luigi
On Fri, Oct 18, 2002 at 11:13:54AM -0700, Kelly Yancey wrote:
> On Fri, 18 Oct 2002, Luigi Rizzo wrote:
>
> > How is the measurement done, does the box under test act as a router
> > with the smartbit pushing traffic in and expecting it back ?
> >
> The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is
> configured with 7 VLANs. THe SmartBit produces X byte UDP datagrams that go
> through a Foundry ServerIron switch for VLAN tagging and then to the GigE
> interface (where they are untagged). The box is acting as a router and all
> traffic is directed out the fxp interface where it returns to the SmartBit.
>
> > The numbers are strange, anyways.
> >
> > A frame of N bytes takes (N*8+160) nanoseconds on the wire, which
> > for 330-byte frames should amount to 1000000/(330*8+160) ~= 357kpps,
> > not the 249 or so you are seeing. Looks as if the times were 40% off.
> >
>
> Yeah, I've never made to much sense of the actual numbers myself. Our
> resident SmartBit expert runs the tests and provides me with the results. I
> use them more for getting an idea of the relative performance of one
> configuration over another and not as absolute numbers themselves. I'll check
> with our resident expert and see if he can explain how it calculates those
> numbers. The point being, though, that there is an undeniable drop-off with
> 332 byte or smaller packets. We have never seen any such drop-off using the
> bge driver.
>
> Thanks,
>
> Kelly
>
> > cheers
> > luigi
> >
> > On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote:
> > ...
> > > > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> > > >
> > > > luigi
> > > >
> > >
> > > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> > > plugged into PCI-X bus:
> > >
> > > FrameSize TxFrames RxFrames LostFrames Lost (%)
> > > 330 249984 129518 120466 48.19
> > > 331 249144 127726 121418 48.73
> > > 332 248472 140817 107655 43.33
> > > 333 247800 247800 0 0
> > >
> > > It has no trouble handling frames 333 bytes or larger. But for any frame
> > > 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> > > easily pushes ~100Mps with the very same frame sizes using a bge card rather
> > > than em.
> > >
> > > I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> > > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
> > >
> > > Kelly
> > >
> > > --
> > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> > > FreeBSD, The Power To Serve: http://www.freebsd.org/
> > >
> > >
> > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > with "unsubscribe freebsd-net" in the body of the message
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-net" in the body of the message
> >
>
> --
> Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 11:46:33 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id C2E4A37B413
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 11:46:31 -0700 (PDT)
Received: from consult-scs.com (vpn.consult-scs.com [209.172.126.178])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7333343E9E
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 11:46:31 -0700 (PDT)
(envelope-from vulture@consult-scs.com)
Received: from consult-scs.com (adsl-63-197-17-60.dsl.snfc21.pacbell.net [63.197.17.60])
(authenticated bits=0)
by consult-scs.com (8.12.6/8.12.6) with ESMTP id g9IIkQIB032135;
Fri, 18 Oct 2002 11:46:26 -0700 (PDT)
Message-ID: <3DB05716.8080806@consult-scs.com>
Date: Fri, 18 Oct 2002 11:46:46 -0700
From: Jonathan Feally <vulture@consult-scs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charles Henrich <henrich@sigbus.com>, freebsd-net@freebsd.org
Subject: Re: IPSEC/NAT issues
References: <20021017162243.B89519@sigbus.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
As I think about it, it isn't IPSEC that needs to process twice once
before and once after ipfw. Its the other way around.
IPFW should first allow the ESP packets into the machine, then IPSEC
extracted the secured packet, and then IPFW will process the normal
packet again, thus allowing the divert to natd to acutally recieve the
non-ipsec version of the packet.
I did some poking around with the kernel code last night, but can't seem
to figure out where to cause a packet that was recieved as IPSEC to go
back though ipfw. I'll keep trying.
The files I've been looking though are sys/netinet/ip_input.c and
sys/netinet/ip_outpuit.c
Charles Henrich wrote:
>I apologize for not CC'ing originally!
>
>I have a network/firewall where I want to nat an entire network. However, I
>also want nat traffic to one remote host in particular out on the internet to
>be IPsec'd as well.
>
>[A] (10.x) [B] (Nat) [C] (Real IP)
>
>I've setup IPsec on both machines, and from either machine (B,C) I can ssh to
>the other, with ipsec packets all happening happy as a clam. However if try a
>connection from behind the nat box to the remote host (A,C) the key exchange
>works fine (between B&C), but then no data flows back and forth. Anyone have
>any suggestions on this? Thanks!
>
>-Crh
>
> Charles Henrich henrich@msu.edu
>
> http://www.sigbus.com/~henrich
>
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with "unsubscribe freebsd-net" in the body of the message
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 11:48:16 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id CDEB837B401; Fri, 18 Oct 2002 11:48:14 -0700 (PDT)
Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 2072E43EA3; Fri, 18 Oct 2002 11:48:14 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224])
by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IImCLE599274;
Fri, 18 Oct 2002 14:48:13 -0400
Received: from localhost (localhost [127.0.0.1])
by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IImBOQ001782;
Fri, 18 Oct 2002 11:48:11 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Date: Fri, 18 Oct 2002 11:48:11 -0700 (PDT)
From: Kelly Yancey <kbyanc@posi.net>
To: Prafulla Deuskar <pdeuskar@FreeBSD.ORG>
Cc: Luigi Rizzo <rizzo@icir.org>, Petri Helenius <pete@he.iki.fi>,
Lars Eggert <larse@ISI.EDU>, <freebsd-net@FreeBSD.ORG>
Subject: Re: ENOBUFS
In-Reply-To: <20021018111147.A91108@hub.freebsd.org>
Message-ID: <20021018113427.Y1611-100000@gateway.posi.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Prafulla Deuskar wrote:
> FYI. 82543 doesn't support PCI-X protocol.
> For PCI-X support use 82544, 82545 or 82546 based cards.
>
> -Prafulla
>
That is alright, we aren't expecting PCI-X speeds. It is just that our only
PCI slot on the motherboard (1U rack-mount system) is a PCI-X slot. Shouldn't
the 82543 still function normally but only as at PCI speeds?
Thanks,
Kelly
>
> Kelly Yancey [kbyanc@posi.net] wrote:
> > On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> >
> > > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> > > ...
> > > > Hmm. Might that explain the abysmal performance of the em driver with
> > > > packets smaller than 333 bytes?
> > >
> > > what do you mean ? it works great for me. even on -current i
> > > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> > >
> > > luigi
> > >
> >
> > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> > plugged into PCI-X bus:
> >
> > FrameSize TxFrames RxFrames LostFrames Lost (%)
> > 330 249984 129518 120466 48.19
> > 331 249144 127726 121418 48.73
> > 332 248472 140817 107655 43.33
> > 333 247800 247800 0 0
> >
> > It has no trouble handling frames 333 bytes or larger. But for any frame
> > 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> > easily pushes ~100Mps with the very same frame sizes using a bge card rather
> > than em.
> >
> > I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
> >
> > Kelly
> >
> > --
> > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> > FreeBSD, The Power To Serve: http://www.freebsd.org/
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-net" in the body of the message
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
"No nation is permitted to live in ignorance with impunity."
-- Thomas Jefferson, 1821.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 12:17:48 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 612CF37B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 12:17:44 -0700 (PDT)
Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77])
by mx1.FreeBSD.org (Postfix) with ESMTP id 2B43F43E6A
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 12:17:43 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224])
by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IJHcLE322542;
Fri, 18 Oct 2002 15:17:39 -0400
Received: from localhost (localhost [127.0.0.1])
by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IJHXOQ001827;
Fri, 18 Oct 2002 12:17:38 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Date: Fri, 18 Oct 2002 12:17:33 -0700 (PDT)
From: Kelly Yancey <kbyanc@posi.net>
To: Luigi Rizzo <rizzo@icir.org>
Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>,
<freebsd-net@FreeBSD.ORG>
Subject: Re: ENOBUFS
In-Reply-To: <20021018112652.A83405@carp.icir.org>
Message-ID: <20021018114829.Y1611-100000@gateway.posi.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> Oh, I *thought* the numbers you reported were pps but now i see that
> nowhere you mentioned that.
>
Sorry. I just checked with our tester. Those are the total number of
packets sent during the test. Each test lasted 10 seconds, so divde by 10 to
get pps.
> But if things are as you say, i am seriously puzzled on what you
> are trying to measure -- the output interface (fxp) is a 100Mbit/s
> card which cannot possibly support the load you are trying to offer
> to saturate the input link.
>
We don't want to saturate the input link, only saturate the outbound link
(100Mps). Oddly enough, the em card cannot do this with any packets less than
333 bytes and drops ~50% of the packets. But clearly this isn't a bottlenext
issue because the drop-off isn't smooth. 332 byte backs cause ~50% packet
loss; 333 byte packets cause 0% packet loss.
> You should definitely clarify how fast the smartbits unit is pushing
> out traffic, and whether its speed depends on the measured RTT.
>
It doesn't sound like the box is that smart. As it was explained to me, the
test setup includes a desired 'load' to put on the wire: it is measured as a
percentage of the wire speed. Since our SmartBit unit only supports
100base-T and doesn't understand vlans, we have to use 7 separate outbound
ports, each configured for 14.25% load. To the GigE interface, this should
appear as 99.75 megabits of data (including all headers/framing).
> It might well be that what you are
> seeing is saturation of ipintrq, which happens because of some
> strange timing issue -- nothing to do with the board.
>
I don't understand why it would only happen with the em card and not with
the bge under the exact same traffic (or even more demanding traffic, i.e.
64byte frames). Also, wouldn't packet gradually subside as we approached the
333 byte magic limit rather than the sudden drop-off we are seeing?
> In any case, at least in my experience, a 1GHz box with two em
> cards can easily forward between 350 and 400kpps (64-byte frames) with a
> 4.6-ish kernel, and a 2.4GHz box goes above 650kpps.
>
We expect our kernel to be slower than that (we typically see ~120kpps for
64-byte frames using the bge driver and a 5701-based card) because we are
using an fxp card for outbound traffic and have added additional code to the
ip_input() processing. The point isn't absolute numbers, though, but trying
to figure out why when using the em driver (and only with the em driver!) we
see ~50% packet loss with packets smaller than 333 bytes (no matter what size,
just that it is smaller). That is, 64 byte frames: ~50% packet loss; 332 byte
frames: ~50% packet loss; 333 byte frames: 0% packet loss. That sort of
sudden drop doesn't look like a bottleneck to me.
We've mostly written the em driver off because of this. The bge driver
works just fine performance wise; it was the sporadic watchdog timeouts
that led us to investigate the Intel cards to begin with. I only mentioned it
on-list because earlier Jim McGrath alluded to similar performance issues with
the Intel GigE cards and small frames.
Actually, at this point, I'm hoping that your polling patches for the em
driver workaround whatever problem is causing the packet loss and am eagerly
awaiting them to be committed. :)
Thanks,
Kelly
>
> On Fri, Oct 18, 2002 at 11:13:54AM -0700, Kelly Yancey wrote:
> > On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> >
> > > How is the measurement done, does the box under test act as a router
> > > with the smartbit pushing traffic in and expecting it back ?
> > >
> > The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is
> > configured with 7 VLANs. THe SmartBit produces X byte UDP datagrams that go
> > through a Foundry ServerIron switch for VLAN tagging and then to the GigE
> > interface (where they are untagged). The box is acting as a router and all
> > traffic is directed out the fxp interface where it returns to the SmartBit.
> >
> > > The numbers are strange, anyways.
> > >
> > > A frame of N bytes takes (N*8+160) nanoseconds on the wire, which
> > > for 330-byte frames should amount to 1000000/(330*8+160) ~= 357kpps,
> > > not the 249 or so you are seeing. Looks as if the times were 40% off.
> > >
> >
> > Yeah, I've never made to much sense of the actual numbers myself. Our
> > resident SmartBit expert runs the tests and provides me with the results. I
> > use them more for getting an idea of the relative performance of one
> > configuration over another and not as absolute numbers themselves. I'll check
> > with our resident expert and see if he can explain how it calculates those
> > numbers. The point being, though, that there is an undeniable drop-off with
> > 332 byte or smaller packets. We have never seen any such drop-off using the
> > bge driver.
> >
> > Thanks,
> >
> > Kelly
> >
> > > cheers
> > > luigi
> > >
> > > On Fri, Oct 18, 2002 at 10:45:13AM -0700, Kelly Yancey wrote:
> > > ...
> > > > > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> > > > >
> > > > > luigi
> > > > >
> > > >
> > > > Using a SmartBit to push traffic across a 1.8Ghz P4; 82543 chipset card
> > > > plugged into PCI-X bus:
> > > >
> > > > FrameSize TxFrames RxFrames LostFrames Lost (%)
> > > > 330 249984 129518 120466 48.19
> > > > 331 249144 127726 121418 48.73
> > > > 332 248472 140817 107655 43.33
> > > > 333 247800 247800 0 0
> > > >
> > > > It has no trouble handling frames 333 bytes or larger. But for any frame
> > > > 332 bytes or smaller we consistently see ~50% packet loss. This same machine
> > > > easily pushes ~100Mps with the very same frame sizes using a bge card rather
> > > > than em.
> > > >
> > > > I've gotten the same results with both em driver version 1.3.14 and 1.3.15
> > > > on both FreeBSD 4.5 and 4.7 (all 4 combinations, that is).
> > > >
> > > > Kelly
> > > >
> > > > --
> > > > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> > > > FreeBSD, The Power To Serve: http://www.freebsd.org/
> > > >
> > > >
> > > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > > with "unsubscribe freebsd-net" in the body of the message
> > >
> > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > with "unsubscribe freebsd-net" in the body of the message
> > >
> >
> > --
> > Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
> > Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-net" in the body of the message
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 12:26:31 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 21E5B37B401
for <freebsd-net@FreeBSD.org>; Fri, 18 Oct 2002 12:26:30 -0700 (PDT)
Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102])
by mx1.FreeBSD.org (Postfix) with ESMTP id 8496743EAC
for <freebsd-net@FreeBSD.org>; Fri, 18 Oct 2002 12:26:29 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224])
by pimout3-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9IJQOne512386;
Fri, 18 Oct 2002 15:26:25 -0400
Received: from localhost (localhost [127.0.0.1])
by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9IJQJOQ001849;
Fri, 18 Oct 2002 12:26:20 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Date: Fri, 18 Oct 2002 12:26:19 -0700 (PDT)
From: Kelly Yancey <kbyanc@posi.net>
To: Luigi Rizzo <rizzo@icir.org>
Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>,
<freebsd-net@FreeBSD.org>
Subject: Re: ENOBUFS
In-Reply-To: <20021018114829.Y1611-100000@gateway.posi.net>
Message-ID: <20021018122321.G1611-100000@gateway.posi.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Kelly Yancey wrote:
> > You should definitely clarify how fast the smartbits unit is pushing
> > out traffic, and whether its speed depends on the measured RTT.
> >
>
> It doesn't sound like the box is that smart. As it was explained to me, the
> test setup includes a desired 'load' to put on the wire: it is measured as a
> percentage of the wire speed. Since our SmartBit unit only supports
> 100base-T and doesn't understand vlans, we have to use 7 separate outbound
> ports, each configured for 14.25% load. To the GigE interface, this should
> appear as 99.75 megabits of data (including all headers/framing).
>
Oops. That was actually the explanation of the SmartBits 'desired ILoad'
which I didn't quote in the posted numbers. The actual number of packets
transmitted is based on RTT. Sorry for the confusion,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
"No nation is permitted to live in ignorance with impunity."
-- Thomas Jefferson, 1821.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 13:16:32 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 04E2537B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 13:16:31 -0700 (PDT)
Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18])
by mx1.FreeBSD.org (Postfix) with SMTP id 0E96D43EA9
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 13:16:30 -0700 (PDT)
(envelope-from kudzu@tenebras.com)
Received: (qmail 42728 invoked from network); 18 Oct 2002 20:16:28 -0000
Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241)
by 0 with SMTP; 18 Oct 2002 20:16:28 -0000
Message-ID: <3DB06C1C.8070502@tenebras.com>
Date: Fri, 18 Oct 2002 13:16:28 -0700
From: Michael Sierchio <kudzu@tenebras.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en, fr-fr, ru
MIME-Version: 1.0
To: "Crist J. Clark" <cjc@FreeBSD.ORG>
Cc: Matthew Zahorik <matt@hottub.org>, freebsd-net@FreeBSD.ORG
Subject: Re: IPSEC/NAT issues
References: <20021018002729.T66900-100000@mail.allcaps.org> <Pine.GSO.4.40.0210180628271.5762-100000@hottub> <20021018182522.GC45449@blossom.cjclark.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Crist J. Clark wrote:
> ...The current ESP standard has its own header
> authentification mechanism. To verify end-to-end header integrity, you
> need only use ESP with this option turned on (excuse me if I don't go
> to the RFC to remind myself of the formal name of the option).
I just happened to be looking at it, so...
RFC 2406 IP Encapsulating Security Payload (ESP)
ESP is used to provide confidentiality, data origin authentication,
connectionless integrity, an anti-replay service (a form of partial
sequence integrity), and limited traffic flow confidentiality.
2.7 Authentication Data
The Authentication Data is a variable-length field containing an
Integrity Check Value (ICV) computed over the ESP packet minus the
Authentication Data. The length of the field is specified by the
authentication function selected. The Authentication Data field is
optional, and is included only if the authentication service has been
selected for the SA in question. The authentication algorithm
specification MUST specify the length of the ICV and the comparison
rules and processing steps for validation.
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 13:41:49 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 1A00737B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 13:41:48 -0700 (PDT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
by mx1.FreeBSD.org (Postfix) with ESMTP id 79C6143E91
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 13:41:47 -0700 (PDT)
(envelope-from don@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19)
id <42S9VAXG>; Fri, 18 Oct 2002 15:53:43 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022CCA@mail.sandvine.com>
From: Don Bowman <don@sandvine.com>
To: 'Luigi Rizzo' <rizzo@icir.org>, Kelly Yancey <kbyanc@posi.net>
Cc: Petri Helenius <pete@he.iki.fi>, Lars Eggert <larse@ISI.EDU>,
freebsd-net@FreeBSD.ORG
Subject: RE: ENOBUFS
Date: Fri, 18 Oct 2002 15:53:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> From: Luigi Rizzo [mailto:rizzo@icir.org]
> On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> ...
> > Hmm. Might that explain the abysmal performance of the
> em driver with
> > packets smaller than 333 bytes?
>
> what do you mean ? it works great for me. even on -current i
> can push out over 400kpps (64byte frames) on a 2.4GHz box.
400kpps seems like very poor performance.
Unless I do the math wrong, this is only ~200Mbps,
the nic should be able to allow ~2-3Mpps (GE bidirectional).
The performance tests I've been doing have also shown
that the broadcom chip (with the bge driver) outperforms the
intel chip (with the em driver) for small packets. This could
be due to tuning in the driver (there are different
tunables in both cases) or due to erroneous/over-aggressive
workarounds. For example, in the broadcom GE chip, the
driver blindly turns off hardware acceleration for checksums,
when it really only needs to do this for certain early rev
silicon. This had a negligible performance improvement @ any
rate owing to the high speed of the processor :) The linux
driver (avail from broadcom) provides some hints here.
The most pressing limit I ran into was the user->kernel
up/down stack interface. Using 'iperf' with UDP, the transmitter
runs out of gas just going up and down the stack, in and
out of kernel, over the sysctl, etc long before the nic
runs out of speed (for small packets).
Seems like there's some interest in a bakeoff :) I'm willing
to post some results when I have them avail.
My $0.02 is that there is likely some outdated 'war stories'
on all silicon that tends to end up implemented as work-arounds
in the driver long after they are fixed in silicon. The
(insert negative opinion) strategy of the silicon vendors
of hiding their errata and datasheets makes for much poorer
utilisation of their product. At least intel has had the good
sense to release their driver.
--don
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 13:48:58 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 5A5C437B401
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 13:48:58 -0700 (PDT)
Received: from wheeljack.redlamb.net (wheeljack.redlamb.net [65.240.12.162])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7B9FD43EAC
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 13:48:57 -0700 (PDT)
(envelope-from redlamb@redlamb.net)
Received: from mirage.redlamb.net (optimusprime.redlamb.net [208.210.151.74])
by wheeljack.redlamb.net (Postfix) with ESMTP id 354F73FEB2
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 11:17:48 -0500 (CDT)
Received: by mirage.redlamb.net (Postfix, from userid 1000)
id 6CE0D248; Fri, 18 Oct 2002 11:17:48 -0500 (CDT)
Date: Fri, 18 Oct 2002 11:17:48 -0500
From: Peter Erickson <redlamb@redlamb.net>
To: FreeBSD-Net List <freebsd-net@freebsd.org>
Subject: Ethernet bonding with netgraph
Message-ID: <20021018161748.GA16899@redlamb.net>
Mail-Followup-To: FreeBSD-Net List <freebsd-net@freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.1i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Could someone please explain to me how to setup a channel-bond between two ethernet cards? I am VERY new to the whole idea of netgraph and I am not too sure how to go about setting one up. After searching on google, I found something about using ng_fec, but I am still unsure about which node types I need to connect and how to connect them. I'm also unsure of what kernel options that I need to add. If it matters, I am running FBSD 4.6 and I am trying to setup Snort to listen to two ethernet cards that are connected to a Finisar UTP/1L network tap. Please help. Thanks in advance for any help.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 13:52:39 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 77BF437B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 13:52:38 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP id 773DE43E8A
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 13:52:37 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9IKqTYj087581;
Fri, 18 Oct 2002 23:52:31 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <017201c276e8$58e4b8f0$3500080a@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Luigi Rizzo" <rizzo@icir.org>
Cc: "Jim McGrath" <jimmcgra@bellatlantic.net>,
"Lars Eggert" <larse@ISI.EDU>, <freebsd-net@FreeBSD.ORG>
References: <NDBBKKEELKBCJJBEGDECCEHJCGAA.jimmcgra@bellatlantic.net> <00b001c276ba$1533dbf0$3500080a@PHE> <20021018103825.B82982@carp.icir.org>
Subject: Re: ENOBUFS
Date: Fri, 18 Oct 2002 23:53:00 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> In special cases, the error induced by having interrupts blocked
> causes errors which are much larger than polling alone.
Which conditions block interrupts for longer than, say, a millisecond?
Disk errors / wakeups? Anything occurring in "normal" conditions?
Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 13:53:24 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id BFB5637B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 13:53:23 -0700 (PDT)
Received: from out002.verizon.net (out002pub.verizon.net [206.46.170.141])
by mx1.FreeBSD.org (Postfix) with ESMTP id F1A9C43E9E
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 13:53:22 -0700 (PDT)
(envelope-from jimmcgra@bellatlantic.net)
Received: from Default ([141.154.237.113]) by out002.verizon.net
(InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP
id <20021018205322.XXVC2867.out002.verizon.net@Default>;
Fri, 18 Oct 2002 15:53:22 -0500
From: "Jim McGrath" <jimmcgra@bellatlantic.net>
To: "Kelly Yancey" <kbyanc@posi.net>, "Luigi Rizzo" <rizzo@icir.org>
Cc: "Petri Helenius" <pete@he.iki.fi>, "Lars Eggert" <larse@ISI.EDU>,
<freebsd-net@FreeBSD.ORG>
Subject: RE: ENOBUFS
Date: Fri, 18 Oct 2002 16:53:41 -0400
Message-ID: <NDBBKKEELKBCJJBEGDECOEIACGAA.jimmcgra@bellatlantic.net>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <20021018114829.Y1611-100000@gateway.posi.net>
Importance: Normal
X-Authentication-Info: Submitted using SMTP AUTH LOGIN at out002.verizon.net from [141.154.237.113] at Fri, 18 Oct 2002 15:53:21 -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
I was testing the wx driver with an 82544 based NIC. Small packets were
used to allow very high packet rates. I was experimenting with various
values of RIDV. The problem I experienced was 82544 chip lockup when RIDV
was nonzero and packet rate was high. Small packets were never a problem by
themselves.
Jim
> We've mostly written the em driver off because of this. The bge driver
> works just fine performance wise; it was the sporadic watchdog timeouts
> that led us to investigate the Intel cards to begin with. I only
> mentioned it
> on-list because earlier Jim McGrath alluded to similar
> performance issues with
> the Intel GigE cards and small frames.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 13:57:39 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 60C9D37B401; Fri, 18 Oct 2002 13:57:37 -0700 (PDT)
Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 6A9FB43E97; Fri, 18 Oct 2002 13:57:35 -0700 (PDT)
(envelope-from pete@he.iki.fi)
Received: from PHE (silver.he.iki.fi [193.64.42.241])
by silver.he.iki.fi (8.12.6/8.11.4) with SMTP id g9IKvXYj087664;
Fri, 18 Oct 2002 23:57:34 +0300 (EEST)
(envelope-from pete@he.iki.fi)
Message-ID: <018001c276e9$0d6a4100$3500080a@PHE>
From: "Petri Helenius" <pete@he.iki.fi>
To: "Prafulla Deuskar" <pdeuskar@FreeBSD.ORG>
Cc: "Luigi Rizzo" <rizzo@icir.org>, "Lars Eggert" <larse@ISI.EDU>,
<freebsd-net@FreeBSD.ORG>
References: <3DAC8FAD.30601@isi.edu> <068b01c2749f$32e7cf70$8c2a40c1@PHE> <20021015161055.A27443@carp.icir.org> <06c901c274d8$e5280b80$8c2a40c1@PHE> <3DAD01A7.3020807@isi.edu> <071501c274db$222c3ea0$8c2a40c1@PHE> <3DAD06AF.7060701@isi.edu> <0be401c2761f$855af670$8c2a40c1@PHE> <20021017201158.A75351@carp.icir.org> <0d0b01c27680$b553ba90$8c2a40c1@PHE> <20021018102203.A86452@hub.freebsd.org>
Subject: Re: ENOBUFS
Date: Fri, 18 Oct 2002 23:58:03 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
> Transmit/Receive Interrupt Delay values are in units of 1.024 microseconds.
> The em driver currently uses these to enable interrupt coalescing on the
cards.
>
Is this one and 24 one thousandth of microseconds or 1024 microseconds which
equals to about one millisecond and sounds quite a lot?
With former, em would "top out" at about 35000 interrupts a second.
(times two for two interfaces) With 256 receive descriptors available this would
translate to about 9Mpps :-)
Pete
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 14: 4:48 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 1CA6C37B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 14:04:47 -0700 (PDT)
Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242])
by mx1.FreeBSD.org (Postfix) with ESMTP id 6A9C743E8A
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 14:04:45 -0700 (PDT)
(envelope-from Kevin_Stevens@pursued-with.net)
Received: from babelfish (babelfish [192.168.168.42])
by pursued-with.net (8.12.6/8.12.5) with ESMTP id g9IL4iFv040054;
Fri, 18 Oct 2002 14:04:44 -0700 (PDT)
(envelope-from Kevin_Stevens@pursued-with.net)
Date: Fri, 18 Oct 2002 14:04:44 -0700 (PDT)
From: Kevin Stevens <Kevin_Stevens@pursued-with.net>
Reply-To: Kevin_Stevens@pursued-with.net
To: Don Bowman <don@sandvine.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: RE: ENOBUFS
In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C8533701022CCA@mail.sandvine.com>
Message-ID: <20021018135434.Y40012-100000@babelfish.pursued-with.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Don Bowman wrote:
> > what do you mean ? it works great for me. even on -current i
> > can push out over 400kpps (64byte frames) on a 2.4GHz box.
>
> 400kpps seems like very poor performance.
> Unless I do the math wrong, this is only ~200Mbps,
> the nic should be able to allow ~2-3Mpps (GE bidirectional).
First, you're only pushing packets, so you are only talking a potential
1GB, not two.
Second, sending minimum-size packets, while a best-case metric for pps, is
a worst-case metric for throughput. I don't think that you can conclude
that 20% theoretical bandwidth utilization at minimum packet size is poor
performance; in fact it seems pretty good to me. Extrapolating from those
numbers, if the packets were five times larger (320b), you'd hit
theoretical maximum throughput. Obviously that won't happen, your pps
numbers will go down as the packet size goes up, but it does indicate you
have some headroom, even without going to jumbo frames if the card pushed
five times fewer pps at 1500 byte frames you'd max out the throughput.
You can't tell very much from a single data point like that, but what you
can infer doesn't seem to me to be bad at all.
KeS
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 14: 5:37 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 61BDE37B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 14:05:36 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id C7AB443EA9
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 14:05:35 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9IL5YpJ084818;
Fri, 18 Oct 2002 14:05:34 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9IL5YSo084817;
Fri, 18 Oct 2002 14:05:34 -0700 (PDT)
(envelope-from rizzo)
Date: Fri, 18 Oct 2002 14:05:34 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: Petri Helenius <pete@he.iki.fi>
Cc: Jim McGrath <jimmcgra@bellatlantic.net>,
Lars Eggert <larse@ISI.EDU>, freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021018140534.A84731@carp.icir.org>
References: <NDBBKKEELKBCJJBEGDECCEHJCGAA.jimmcgra@bellatlantic.net> <00b001c276ba$1533dbf0$3500080a@PHE> <20021018103825.B82982@carp.icir.org> <017201c276e8$58e4b8f0$3500080a@PHE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <017201c276e8$58e4b8f0$3500080a@PHE>; from pete@he.iki.fi on Fri, Oct 18, 2002 at 11:53:00PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, Oct 18, 2002 at 11:53:00PM +0300, Petri Helenius wrote:
> > In special cases, the error induced by having interrupts blocked
> > causes errors which are much larger than polling alone.
>
> Which conditions block interrupts for longer than, say, a millisecond?
changes in link status in several ethernet drivers will cause
their interrupt service routine (ISR) to loop polling for some event.
A similar thing used to happen in the xl driver when fetching
statistics, once per second (hopefully fixed now).
Even in "normal" condition, the ISR for a network card has to
loop around the status bit until no interrupts are pending,
and because (typically) the receive ring is replenished while
you process it, and packets come in without explicitly requesting them,
there is no upper bound on how long you will loop.
I wouldn't be surprised if there were other drivers doing busy-wait
cycles in the interrupt service routine, because sometimes the driver
detects an error condition and calls some generic routine to
reinitialize the hardware, but that routine has been written
for use at attach time, not at runtime.
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 14:20:24 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 060B937B401
for <net@freebsd.org>; Fri, 18 Oct 2002 14:20:18 -0700 (PDT)
Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11])
by mx1.FreeBSD.org (Postfix) with ESMTP id 107A043E6A
for <net@freebsd.org>; Fri, 18 Oct 2002 14:20:17 -0700 (PDT)
(envelope-from stephenm@windriver.com)
Received: from brisbane (brisbane [147.11.38.9])
by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA25087;
Fri, 18 Oct 2002 14:19:16 -0700 (PDT)
Message-Id: <200210182119.OAA25087@mail.wrs.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: cjclark@alum.mit.edu
Cc: net@freebsd.org, stephenm@mail.wrs.com
Subject: Re: Strange FTP TCP Window Problem
In-reply-to: Your message of "Fri, 18 Oct 2002 10:10:55 PDT."
<20021018171055.GA45449@blossom.cjclark.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 Oct 2002 14:20:07 -0700
From: Stephen Macmanus <stephenm@windriver.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
This type of behavior typically indicates a problem with the
application itself, above the socket layer, not TCP or the
other protocols. The window size continually decreases as
data arrives since TCP is storing the incoming data in the
receive buffer, but the target application is not reading it.
I have seen cases where this behavior occurs due to subtle
failures like CPU starvation due to scheduling priorities
or incorrect mutual exclusion.
I have also encountered simpler causes, such as creating a
socket for the purpose of sending data that uses a port which
also matches incoming data. In that case, the application simply
never read the unexpected data from the socket. Setting the
receive buffer to zero allowed TCP to discard the data and avoid
the problem. This possibility may not apply in your case, since the
client successfully handles other file transfers, but in my experience
the application is the most likely cause of the problem.
Stephen
--
------------------
Stephen Macmanus #include <std_disclaimer.h>
Technical Staff
Wind River Networks stephenm@wrs.com
> This has got me stumped. I must be missing something obvious. I am
> trying to download some files via FTP. There are four files. Three
> download just fine, one just won't go. Since the three work fine, I
> assume it's not PORT vs. PASV, NAT, or other firewall issues, that is,
> the usual suspects have been eliminated. But what is really strange is
> that it looks like _my client_ is the one causing the headaches.
>
> Here is a tcpdump(8) of the data connection. Keep an eye on the window
> values my client is sending back,
>
> 09:15:11.097800 a.b.c.136.29826 > d.e.f.17.18747: S [tcp sum ok] 2410623756:2410623756(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 6027020 0> (ttl 64, id 50031, len 64)
> 09:15:11.118335 d.e.f.17.18747 > a.b.c.136.29826: S [tcp sum ok] 2932757104:2932757104(0) ack 2410623757 win 16384 <mss 512,nop,wscale 0,nop,nop,timestamp 1679619 6027020> (ttl 56, id 24108, len 60)
> 09:15:11.118443 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1 win 16500 <nop,nop,timestamp 6027020 1679619> (ttl 64, id 43640, len 52)
> 09:15:11.156424 d.e.f.17.18747 > a.b.c.136.29826: . 1:501(500) ack 1 win 16384 <nop,nop,timestamp 1679619 6027020> [tos 0x8] (ttl 56, id 24111, len 552)
> 09:15:11.159468 d.e.f.17.18747 > a.b.c.136.29826: . 501:1001(500) ack 1 win 16384 <nop,nop,timestamp 1679619 6027020> [tos 0x8] (ttl 56, id 24112, len 552)
> 09:15:11.227371 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 1001 win 15500 <nop,nop,timestamp 6027020 1679619> [tos 0x8] (ttl 64, id 61006, len 52)
> 09:15:11.258205 d.e.f.17.18747 > a.b.c.136.29826: . 1001:1501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24113, len 552)
> 09:15:11.261225 d.e.f.17.18747 > a.b.c.136.29826: . 1501:2001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24114, len 552)
> 09:15:11.279923 d.e.f.17.18747 > a.b.c.136.29826: . 2001:2501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24115, len 552)
> 09:15:11.427395 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 2501 win 14000 <nop,nop,timestamp 6027021 1679620> [tos 0x8] (ttl 64, id 40196, len 52)
> 09:15:11.457865 d.e.f.17.18747 > a.b.c.136.29826: . 2501:3001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24116, len 552)
> 09:15:11.461105 d.e.f.17.18747 > a.b.c.136.29826: . 3001:3501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24117, len 552)
> 09:15:11.480485 d.e.f.17.18747 > a.b.c.136.29826: . 3501:4001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24118, len 552)
> 09:15:11.483702 d.e.f.17.18747 > a.b.c.136.29826: . 4001:4501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24119, len 552)
> 09:15:11.627707 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 4501 win 12000 <nop,nop,timestamp 6027021 1679620> [tos 0x8] (ttl 64, id 44302, len 52)
> 09:15:11.648692 d.e.f.17.18747 > a.b.c.136.29826: . 4501:5001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24120, len 552)
> 09:15:11.659731 d.e.f.17.18747 > a.b.c.136.29826: . 5001:5501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24121, len 552)
> 09:15:11.670448 d.e.f.17.18747 > a.b.c.136.29826: . 5501:6001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24122, len 552)
> 09:15:11.673581 d.e.f.17.18747 > a.b.c.136.29826: . 6001:6501(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24123, len 552)
> 09:15:11.692780 d.e.f.17.18747 > a.b.c.136.29826: . 6501:7001(500) ack 1 win 16384 <nop,nop,timestamp 1679620 6027020> [tos 0x8] (ttl 56, id 24124, len 552)
> 09:15:11.827393 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 7001 win 9500 <nop,nop,timestamp 6027021 1679620> [tos 0x8] (ttl 64, id 38068, len 52)
> 09:15:11.855900 d.e.f.17.18747 > a.b.c.136.29826: . 7001:7501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24125, len 552)
> 09:15:11.860077 d.e.f.17.18747 > a.b.c.136.29826: . 7501:8001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24126, len 552)
> 09:15:11.878834 d.e.f.17.18747 > a.b.c.136.29826: . 8001:8501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24127, len 552)
> 09:15:11.881856 d.e.f.17.18747 > a.b.c.136.29826: . 8501:9001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24128, len 552)
> 09:15:11.892382 d.e.f.17.18747 > a.b.c.136.29826: . 9001:9501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24129, len 552)
> 09:15:11.903415 d.e.f.17.18747 > a.b.c.136.29826: . 9501:10001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24130, len 552)
> 09:15:12.027385 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 10001 win 6500 <nop,nop,timestamp 6027022 1679621> [tos 0x8] (ttl 64, id 60342, len 52)
> 09:15:12.052757 d.e.f.17.18747 > a.b.c.136.29826: . 10001:10501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24131, len 552)
> 09:15:12.063589 d.e.f.17.18747 > a.b.c.136.29826: . 10501:11001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24132, len 552)
> 09:15:12.074515 d.e.f.17.18747 > a.b.c.136.29826: . 11001:11501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24133, len 552)
> 09:15:12.078151 d.e.f.17.18747 > a.b.c.136.29826: . 11501:12001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24134, len 552)
> 09:15:12.096930 d.e.f.17.18747 > a.b.c.136.29826: . 12001:12501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24135, len 552)
> 09:15:12.099980 d.e.f.17.18747 > a.b.c.136.29826: . 12501:13001(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24136, len 552)
> 09:15:12.110647 d.e.f.17.18747 > a.b.c.136.29826: . 13001:13501(500) ack 1 win 16384 <nop,nop,timestamp 1679621 6027020> [tos 0x8] (ttl 56, id 24137, len 552)
> 09:15:12.227383 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 13501 win 3000 <nop,nop,timestamp 6027022 1679621> [tos 0x8] (ttl 64, id 51576, len 52)
> 09:15:12.264837 d.e.f.17.18747 > a.b.c.136.29826: . 13501:14001(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24138, len 552)
> 09:15:12.268095 d.e.f.17.18747 > a.b.c.136.29826: . 14001:14501(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24139, len 552)
> 09:15:12.278653 d.e.f.17.18747 > a.b.c.136.29826: . 14501:15001(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24140, len 552)
> 09:15:12.289849 d.e.f.17.18747 > a.b.c.136.29826: . 15001:15501(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24141, len 552)
> 09:15:12.293592 d.e.f.17.18747 > a.b.c.136.29826: . 15501:16001(500) ack 1 win 16384 <nop,nop,timestamp 1679622 6027020> [tos 0x8] (ttl 56, id 24142, len 552)
> 09:15:12.427402 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16001 win 500 <nop,nop,timestamp 6027023 1679622> [tos 0x8] (ttl 64, id 41001, len 52)
> 09:15:17.202100 d.e.f.17.18747 > a.b.c.136.29826: . 16001:16501(500) ack 1 win 16384 <nop,nop,timestamp 1679631 6027020> [tos 0x8] (ttl 56, id 24157, len 552)
> 09:15:17.227476 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027032 1679631> [tos 0x8] (ttl 64, id 59052, len 52)
> 09:15:22.186435 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679641 6027020> [tos 0x8] (ttl 56, id 24183, len 53)
> 09:15:22.186625 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027042 1679641> [tos 0x8] (ttl 64, id 55942, len 52)
> 09:15:30.194393 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679657 6027020> [tos 0x8] (ttl 56, id 24221, len 53)
> 09:15:30.195913 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027058 1679657> [tos 0x8] (ttl 64, id 14020, len 52)
> 09:15:46.198335 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679689 6027020> [tos 0x8] (ttl 56, id 24333, len 53)
> 09:15:46.198583 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027090 1679689> [tos 0x8] (ttl 64, id 16087, len 52)
> 09:16:18.201164 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679753 6027020> [tos 0x8] (ttl 56, id 24500, len 53)
> 09:16:18.201409 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027154 1679753> [tos 0x8] (ttl 64, id 30338, len 52)
> 09:17:18.194176 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679873 6027020> [tos 0x8] (ttl 56, id 25061, len 53)
> 09:17:18.194430 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027274 1679873> [tos 0x8] (ttl 64, id 20615, len 52)
> 09:18:18.193763 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1679993 6027020> [tos 0x8] (ttl 56, id 25447, len 53)
> 09:18:18.194005 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027394 1679993> [tos 0x8] (ttl 64, id 12107, len 52)
> 09:19:18.186418 d.e.f.17.18747 > a.b.c.136.29826: . [tcp sum ok] 16501:16502(1) ack 1 win 16384 <nop,nop,timestamp 1680113 6027020> [tos 0x8] (ttl 56, id 25862, len 53)
> 09:19:18.187970 a.b.c.136.29826 > d.e.f.17.18747: . [tcp sum ok] 1:1(0) ack 16501 win 0 <nop,nop,timestamp 6027514 1680113> [tos 0x8] (ttl 64, id 51084, len 52)
>
> And this just hangs here forever.
>
> I can't see why the client is refusing to accept more data. Like I
> said, I'll bet I'm not seeing something obvious, but all of the SEQ
> and ACK numbers look good to me. I should note that this isn't just an
> issue with the FreeBSD ftp client. I get the same result with Windows,
> Solaris, Cygwin, and OpenBSD too.
>
> Why is it happening and how do I get around this?
> --
> Crist J. Clark | cjclark@alum.mit.edu
> | cjclark@jhu.edu
> http://people.freebsd.org/~cjc/ | cjc@freebsd.org
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
--
------------------
Stephen Macmanus #include <std_disclaimer.h>
Technical Staff
Wind River Networks stephenm@wrs.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 14:32: 2 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 837C837B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 14:32:01 -0700 (PDT)
Received: from overlord.e-gerbil.net (e-gerbil.net [64.186.142.66])
by mx1.FreeBSD.org (Postfix) with ESMTP id 2635443E88
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 14:32:01 -0700 (PDT)
(envelope-from ras@e-gerbil.net)
Received: by overlord.e-gerbil.net (Postfix, from userid 1000)
id 961FA15E4B; Fri, 18 Oct 2002 17:31:54 -0400 (EDT)
Date: Fri, 18 Oct 2002 17:31:54 -0400
From: Richard A Steenbergen <ras@e-gerbil.net>
To: Kevin Stevens <Kevin_Stevens@pursued-with.net>
Cc: Don Bowman <don@sandvine.com>, freebsd-net@FreeBSD.ORG
Subject: Re: ENOBUFS
Message-ID: <20021018213154.GO26000@overlord.e-gerbil.net>
References: <FE045D4D9F7AED4CBFF1B3B813C8533701022CCA@mail.sandvine.com> <20021018135434.Y40012-100000@babelfish.pursued-with.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20021018135434.Y40012-100000@babelfish.pursued-with.net>
User-Agent: Mutt/1.3.27i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, Oct 18, 2002 at 02:04:44PM -0700, Kevin Stevens wrote:
>
> First, you're only pushing packets, so you are only talking a potential
> 1GB, not two.
>
> Second, sending minimum-size packets, while a best-case metric for pps, is
> a worst-case metric for throughput. I don't think that you can conclude
> that 20% theoretical bandwidth utilization at minimum packet size is poor
> performance; in fact it seems pretty good to me. Extrapolating from those
> numbers, if the packets were five times larger (320b), you'd hit
> theoretical maximum throughput. Obviously that won't happen, your pps
> numbers will go down as the packet size goes up, but it does indicate you
> have some headroom, even without going to jumbo frames if the card pushed
> five times fewer pps at 1500 byte frames you'd max out the throughput.
>
> You can't tell very much from a single data point like that, but what you
> can infer doesn't seem to me to be bad at all.
Counting overhead for the preamble, SFD, the ethernet headers, the
checksum, the interframe gap, and the padding required to produce a
minimum sized ethernet frame, the equivalent of no less than 84 bytes is
transmitted for any frame. That makes the maximum unidirectional
packets/sec on GigE 1.488Mpps.
400kpps is a little under 27% of this. In "normal" use that's probably
good enough, but it's hardly what I'd call line rate. :)
--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 14:41: 8 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 082B937B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 14:41:07 -0700 (PDT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
by mx1.FreeBSD.org (Postfix) with ESMTP id 7511D43EA9
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 14:41:06 -0700 (PDT)
(envelope-from don@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19)
id <42S9VA79>; Fri, 18 Oct 2002 17:41:05 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701022CD2@mail.sandvine.com>
From: Don Bowman <don@sandvine.com>
To: "'Kevin_Stevens@pursued-with.net'" <Kevin_Stevens@pursued-with.net>,
Don Bowman <don@sandvine.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: RE: ENOBUFS
Date: Fri, 18 Oct 2002 17:40:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
From: Kevin Stevens [mailto:Kevin_Stevens@pursued-with.net]
> On Fri, 18 Oct 2002, Don Bowman wrote:
>
> > > what do you mean ? it works great for me. even on -current i
> > > can push out over 400kpps (64byte frames) on a 2.4GHz box.
> >
> > 400kpps seems like very poor performance.
> > Unless I do the math wrong, this is only ~200Mbps,
> > the nic should be able to allow ~2-3Mpps (GE bidirectional).
>
> First, you're only pushing packets, so you are only talking a
> potential 1GB, not two.
>
> Second, sending minimum-size packets, while a best-case
> metric for pps, is a worst-case metric for throughput.
> I don't think that you can conclude that 20% theoretical
> bandwidth utilization at minimum packet size is poor
> performance; in fact it seems pretty good to me.
Problem is, I'm making a bridge application which operates in a network
similar to a router, not an endpoint server which receives TCP packets.
There's a huge number of small packets on the internet due to
TCP ACK's etc.
I need to be able to do ~1.5Mpps x 2 for a single interface (both
directions), which becomes ~1.5Mpps x 4 for an 'in' and an 'out'
interface.
Clearly you are correct that for most client/server applications
64-byte pps are not the interesting stat.
Clearly I will have some tuning ahead, and likely I will not succeed,
but for sure my 1U XEON with 6 gigabit nics will work very hard
for its living :)
--don (don@sandvine.com www.sandvine.com)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 15:41:28 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 0B1F237B401
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 15:41:27 -0700 (PDT)
Received: from nyvw02.kddia.com (ny.kdd.com [209.137.139.35])
by mx1.FreeBSD.org (Postfix) with SMTP id C85A343E65
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 15:41:25 -0700 (PDT)
(envelope-from fengli@kddia.com)
Received: from 192.168.11.1 by nyvw02.kddia.com (InterScan E-Mail VirusWall NT); Fri, 18 Oct 2002 18:41:55 -0400
Received: from nypc147 (375pc131.ny.kdd.com [192.168.18.131])
by ny.kdd.com (8.9.3/3.7W-0.1) with ESMTP id SAA45608
for <freebsd-net@freebsd.org>; Fri, 18 Oct 2002 18:41:18 -0400 (EDT)
Date: Fri, 18 Oct 2002 18:40:13 -0400
From: Feng Li <fengli@kddia.com>
To: freebsd-net@freebsd.org
Subject: Is anyone can help this ?
Message-Id: <20021018183544.581C.FENGLI@kddia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.11
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi, Friends
Could anyone advise me how to configure the Ethernet
Card on my PC with speed=100Mbps, duplex=Full parameters ?
My PC is running FreeBSD 3.1-Relase, the interface name
is fxp0.
The config example will be appreciated greatly !
Thanks a lot in advnace !
Feng
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 16:25: 1 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 67F9937B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 16:25:00 -0700 (PDT)
Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102])
by mx1.FreeBSD.org (Postfix) with ESMTP id 4FCF243ECD
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 16:24:59 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Received: from gateway.posi.net (adsl-63-201-92-224.dsl.snfc21.pacbell.net [63.201.92.224])
by pimout3-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id g9INOvne654452;
Fri, 18 Oct 2002 19:24:58 -0400
Received: from localhost (localhost [127.0.0.1])
by gateway.posi.net (8.12.6/8.12.5) with ESMTP id g9INOuOQ002264;
Fri, 18 Oct 2002 16:24:56 -0700 (PDT)
(envelope-from kbyanc@posi.net)
Date: Fri, 18 Oct 2002 16:24:56 -0700 (PDT)
From: Kelly Yancey <kbyanc@posi.net>
To: Feng Li <fengli@kddia.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: Is anyone can help this ?
In-Reply-To: <20021018183544.581C.FENGLI@kddia.com>
Message-ID: <20021018162040.K1874-100000@gateway.posi.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Feng Li wrote:
>
> Hi, Friends
>
> Could anyone advise me how to configure the Ethernet
> Card on my PC with speed=100Mbps, duplex=Full parameters ?
>
> My PC is running FreeBSD 3.1-Relase, the interface name
> is fxp0.
>
> The config example will be appreciated greatly !
>
> Thanks a lot in advnace !
>
I don't remember if it is the same in 3.1, but per `man ifconfig` and `man
fxp`:
ifconfig fxp0 media 100baseTX mediaopt full-duplex
ifconfig fxp0 media 100BaseT mediaopt full-duplex
By the way, this sort of question belongs on -questions. Thanks,
Kelly
--
Kelly Yancey -- kbyanc@{posi.net,FreeBSD.org}
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 18:45:23 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id D189437B401
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 18:45:22 -0700 (PDT)
Received: from web21408.mail.yahoo.com (web21408.mail.yahoo.com [216.136.232.78])
by mx1.FreeBSD.org (Postfix) with SMTP id 6D11043E7B
for <freebsd-net@FreeBSD.ORG>; Fri, 18 Oct 2002 18:45:22 -0700 (PDT)
(envelope-from zopewiz@yahoo.com)
Message-ID: <20021019014522.4446.qmail@web21408.mail.yahoo.com>
Received: from [63.170.174.190] by web21408.mail.yahoo.com via HTTP; Fri, 18 Oct 2002 18:45:22 PDT
Date: Fri, 18 Oct 2002 18:45:22 -0700 (PDT)
From: Carlos Carnero <zopewiz@yahoo.com>
Subject: mpd PPTP server; client gateway
To: freebsd-net@FreeBSD.ORG
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
Hi,
I've succesfully configured mpd as PPTP server for
VPNs. But I have one stumbling block: when I connect
to the server from a Windows XP client, the new
connection gets assigned the same IP address as the
default gateway. For instance:
Client IP address: 192.168.250.240
Client netmask: 255.255.255.0
Client gateway: 192.168.250.240
the latter _should_ be 192.168.250.1.
I can't ping to any other IP addresses inside the VPN.
Has any one been there?
Best regards,
Carlos.
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri Oct 18 22:58:27 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP
id 591F737B401; Fri, 18 Oct 2002 22:58:26 -0700 (PDT)
Received: from mail.allcaps.org (h-66-166-142-198.SNDACAGL.covad.net [66.166.142.198])
by mx1.FreeBSD.org (Postfix) with ESMTP
id 4DD1B43E7B; Fri, 18 Oct 2002 22:58:25 -0700 (PDT)
(envelope-from bsder@mail.allcaps.org)
Received: by mail.allcaps.org (Postfix, from userid 501)
id 785751550C; Fri, 18 Oct 2002 22:58:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mail.allcaps.org (Postfix) with ESMTP
id 6C8DA1550B; Fri, 18 Oct 2002 22:58:22 -0700 (PDT)
Date: Fri, 18 Oct 2002 22:58:22 -0700 (PDT)
From: "Andrew P. Lentvorski" <bsder@mail.allcaps.org>
To: "Crist J. Clark" <cjc@FreeBSD.ORG>
Cc: Matthew Zahorik <matt@hottub.org>, <freebsd-net@FreeBSD.ORG>
Subject: Re: IPSEC/NAT issues
In-Reply-To: <20021018182522.GC45449@blossom.cjclark.org>
Message-ID: <20021018222132.P68535-100000@mail.allcaps.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
On Fri, 18 Oct 2002, Me, Myself, and I blathered:
> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> packet will get rejected when it reaches the other IPSEC node.
I still stand by my original statement. However, it won't be true for
much longer. There is now a draft document (as of August 18, 2002) for
dealing with NAT traversal.
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-reqts-02.txt
<quote>
a) Incompatibility between IPsec AH [RFC2402] and NAT. Since the AH header
incorporates the IP source and destination addresses in the
keyed message integrity check, NAT or reverse NAT devices making changes
to address fields will invalidate the message integrity check.
Since IPsec ESP [4] does not incorporate the IP source and
destination addresses in its keyed message integrity check,
this issue does not arise for ESP.
b) Incompatibility between checksums and NAT. TCP/UDP/SCTP
checksums have a dependency on the IP source and destination
addresses through inclusion of the "pseudo-header" in the
calculation. As a result, where checksums are calculated and
checked on receipt, they will be invalidated by passage through
a NAT or reverse NAT device.
As a result, IPsec ESP will only pass unimpeded through a NAT if
TCP/UDP/SCTP protocols are not involved (as in IPsec tunnel
mode or IPsec/GRE), or checksums are not calculated (as is
possible with IPv4 UDP)
</quote>
-a
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat Oct 19 16:28:47 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
by hub.freebsd.org (Postfix) with ESMTP id 4034F37B401
for <net@freebsd.org>; Sat, 19 Oct 2002 16:28:46 -0700 (PDT)
Received: from carp.icir.org (carp.icir.org [192.150.187.71])
by mx1.FreeBSD.org (Postfix) with ESMTP id A7CE343E6A
for <net@freebsd.org>; Sat, 19 Oct 2002 16:28:45 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: from carp.icir.org (localhost [127.0.0.1])
by carp.icir.org (8.12.3/8.12.3) with ESMTP id g9JNSjpJ099097;
Sat, 19 Oct 2002 16:28:45 -0700 (PDT)
(envelope-from rizzo@carp.icir.org)
Received: (from rizzo@localhost)
by carp.icir.org (8.12.3/8.12.3/Submit) id g9JNSjG4099096;
Sat, 19 Oct 2002 16:28:45 -0700 (PDT)
(envelope-from rizzo)
Date: Sat, 19 Oct 2002 16:28:45 -0700
From: Luigi Rizzo <rizzo@icir.org>
To: net@freebsd.org
Subject: supported USB-wireless adapters ?
Message-ID: <20021019162845.A99077@carp.icir.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org
as the subject syas, can anyone suggest wireless (802.11b)
usb-adapters which are supported by FreeBSD ?
thanks
luigi
----------------------------------+-----------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone: (510) 666 2988
----------------------------------+-----------------------------------------
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message