From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 07:21:07 2004 Return-Path: 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 B449916A4CE for ; Mon, 18 Oct 2004 07:21:07 +0000 (GMT) Received: from orion.erdves.lt (ns2.lrtc.net [217.9.240.98]) by mx1.FreeBSD.org (Postfix) with SMTP id 640F543D55 for ; Mon, 18 Oct 2004 07:21:06 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 70727 invoked from network); 18 Oct 2004 07:21:04 -0000 Received: from p2p-241-242-ird.vln0.lrtc.net (HELO donatas) (217.9.241.242) by orion.erdves.lt with SMTP; 18 Oct 2004 07:21:04 -0000 Message-ID: <00b001c4b4eb$4ef3eee0$9f90a8c0@donatas> From: "donatas" To: Date: Mon, 18 Oct 2004 11:20:20 +0300 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: TOS and IPFW-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: donatas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 07:21:07 -0000 Hello, is there any possibility to use TOS on IPFW-1 machines? Wee need to prioritize VOIP (MGCP) packets for high throughput. FreeBSD 4.10. than you in advance From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 07:39:00 2004 Return-Path: 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 B160116A4CE for ; Mon, 18 Oct 2004 07:39:00 +0000 (GMT) Received: from therion.astral-on.net (therion.astral-on.net [193.41.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDE4043D46 for ; Mon, 18 Oct 2004 07:38:58 +0000 (GMT) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (odin.astral-on.net [193.41.4.6]) i9I7csol079393 for ; Mon, 18 Oct 2004 10:38:55 +0300 (EEST) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (localhost.astral-on.net [127.0.0.1]) by odin.astral-on.net (8.12.8p2/8.12.8) with ESMTP id i9I7cswk058987 for ; Mon, 18 Oct 2004 10:38:54 +0300 (EEST) (envelope-from ad@odin.astral-on.net) Received: (from ad@localhost) by odin.astral-on.net (8.12.8p2/8.12.8/Submit) id i9I7crbQ058986 for freebsd-net@freebsd.org; Mon, 18 Oct 2004 10:38:53 +0300 (EEST) Date: Mon, 18 Oct 2004 10:38:53 +0300 From: Andrew Degtiariov To: freebsd-net@freebsd.org Message-ID: <20041018073853.GA53824@astral-on.net> Mail-Followup-To: freebsd-net@freebsd.org References: <00b001c4b4eb$4ef3eee0$9f90a8c0@donatas> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <00b001c4b4eb$4ef3eee0$9f90a8c0@donatas> User-Agent: Mutt/1.5.6i Subject: Re: TOS and IPFW-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-net@astral-on.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 07:39:00 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 18, 2004 at 11:20:20AM +0300, donatas wrote: > Hello, > is there any possibility to use TOS on IPFW-1 machines? > Wee need to prioritize VOIP (MGCP) packets for high throughput. > FreeBSD 4.10. > > than you in advance No, TOS field matching implement only in IPFW2 (limited to well known TOS types like a lowdelay, throughput... you can't specify TOS as number). But *prioritization* with dummynet it is a bad idea. ALTQ provides more right way to do *prioritization* (but not so good which you can get with Cisco). So, i have some patches to IPFW2 which provides maching any TOS (both numbers and names). It's for FreeBSD 4.8 but which no problems applies (handmade required of course) to any systems what ipfw2 support. -- Andrew Degtiariov DA-RIPE --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ip_fw2.c.patch" --- sys/netinet/ip_fw2.c.orig Wed Sep 17 14:11:18 2003 +++ sys/netinet/ip_fw2.c Wed Sep 17 14:16:54 2003 @@ -1699,8 +1699,16 @@ break; case O_IPTOS: - match = (hlen > 0 && - flags_match(cmd, ip->ip_tos)); + if (hlen > 0) { + u_int16_t *p = + ((ipfw_insn_u16 *)cmd)->ports; + int i; + + for (i = cmdlen - 1; !match && i>0; + i--, p += 2) + match = (ip->ip_tos>=p[0] && + ip->ip_tos<=p[1]); + } break; case O_TCPFLAGS: @@ -2309,7 +2317,6 @@ case O_IPOPT: case O_IPLEN: case O_IPID: - case O_IPTOS: case O_IPPRECEDENCE: case O_IPTTL: case O_IPVER: @@ -2375,6 +2382,7 @@ goto bad_size; break; + case O_IPTOS: case O_MAC_TYPE: case O_IP_SRCPORT: case O_IP_DSTPORT: /* XXX artificial limit, 30 port pairs */ --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipfw2.c.patch" --- sbin/ipfw/ipfw2.c.orig Wed Sep 17 14:17:44 2003 +++ sbin/ipfw/ipfw2.c Wed Sep 17 14:28:53 2003 @@ -143,6 +143,12 @@ * This is only used in this code. */ #define IPPROTO_ETHERTYPE 0x1000 + +/* + * faked protocol for TOS + */ +#define IPPROTO_IPTOS 0x2000 + static struct _s_x ether_types[] = { /* * Note, we cannot use "-:&/" in the names because they are field @@ -377,13 +383,16 @@ print_port(int proto, u_int16_t port) { - if (proto == IPPROTO_ETHERTYPE) { + if (proto == IPPROTO_ETHERTYPE || proto == IPPROTO_IPTOS) { char *s; - if (do_resolv && (s = match_value(ether_types, port)) ) - printf("%s", s); - else - printf("0x%04x", port); + if (do_resolv && + (s = match_value(proto == IPPROTO_ETHERTYPE ? ether_types : + f_iptos, port)) ) + printf("%s", s); + else + printf(proto == IPPROTO_ETHERTYPE ? "0x%04x": "0x%02x", + port); } else { struct servent *se = NULL; if (do_resolv) { @@ -413,7 +422,8 @@ printf(" not"); if (opcode != 0) printf ("%s", opcode == O_MAC_TYPE ? " mac-type" : - (opcode == O_IP_DSTPORT ? " dst-port" : " src-port")); + (opcode == O_IPTOS ? " iptos" : + (opcode == O_IP_DSTPORT ? " dst-port" : " src-port")) ); for (i = F_LEN((ipfw_insn *)cmd) - 1; i > 0; i--, p += 2) { printf(sep); print_port(proto, p[0]); @@ -445,8 +455,16 @@ if ( *s == '\0') return 0; /* not found */ - if (isdigit(*s)) - return strtol(s, end, base); + if (isdigit(*s)) { + i = strtol(s, end, base); + + if (proto == IPPROTO_IPTOS && (i < 0 || i > 255)) { + *end = s; + return 0; + } else + return i; + } + /* * find separator. '\\' escapes the next char. @@ -467,8 +485,9 @@ buf[i++] = *p; buf[i++] = '\0'; - if (proto == IPPROTO_ETHERTYPE) { - i = match_token(ether_types, buf); + if (proto == IPPROTO_ETHERTYPE || proto == IPPROTO_IPTOS) { + i = match_token(proto == IPPROTO_ETHERTYPE ? ether_types : + f_iptos, buf); free(buf); if (i != -1) { /* found */ *end = s1; @@ -1109,7 +1128,8 @@ break; case O_IPTOS: - print_flags("iptos", cmd, f_iptos); + print_newports((ipfw_insn_u16 *)cmd, + IPPROTO_IPTOS, cmd->opcode); break; case O_ICMPTYPE: @@ -2954,7 +2974,13 @@ case TOK_IPTOS: NEED1("missing argument for iptos"); - fill_flags(cmd, O_IPTOS, f_iptos, *av); + if (!fill_newports ((ipfw_insn_u16 *)cmd, *av, + IPPROTO_IPTOS)) + { + errx(EX_DATAERR, "invalid TOS value \"%s\"", *av); + + } + cmd->opcode = O_IPTOS; ac--; av++; break; --jRHKVT23PllUwdXP-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 11:02:05 2004 Return-Path: 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 7294E16A525 for ; Mon, 18 Oct 2004 11:02:05 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6407743D2F for ; Mon, 18 Oct 2004 11:02:05 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i9IB25Um048114 for ; Mon, 18 Oct 2004 11:02:05 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i9IB24Ua048108 for freebsd-net@freebsd.org; Mon, 18 Oct 2004 11:02:04 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 18 Oct 2004 11:02:04 GMT Message-Id: <200410181102.i9IB24Ua048108@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 11:02:05 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 2 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 11:37:29 2004 Return-Path: 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 20DC916A4CF for ; Mon, 18 Oct 2004 11:37:29 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3B1443D46 for ; Mon, 18 Oct 2004 11:37:27 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i9IBbLPV072235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Oct 2004 15:37:21 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i9IBbKFj072234; Mon, 18 Oct 2004 15:37:20 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 18 Oct 2004 15:37:19 +0400 From: Gleb Smirnoff To: marks@ripe.net, Julian Elischer Message-ID: <20041018113719.GA72194@cell.sick.ru> References: <20041011103028.GA18981@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20041011103028.GA18981@cell.sick.ru> X-NCC-RegId: ru.bestcom User-Agent: Mutt/1.5.6i cc: net@freebsd.org Subject: Re: new ng_device X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 11:37:29 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=koi8-r Content-Disposition: inline A slightly updated version: use m_uiotombuf() instead of homegrown implementation. On Mon, Oct 11, 2004 at 02:30:28PM +0400, Gleb Smirnoff wrote: T> Here is a major rewrite of ng_device. The main T> differencies with current one are: T> T> - one dev per node T> - locking T> - read queue implemented using struct ifqueue, thus T> reducing number of reads/writes to temporary buffers. T> T> A more detailed list of differencies is attached. A test program T> also attached. T> T> P.S. Yet another crazy netgraph idea: ng_iface + ng_device is T> a substitute for tun(4). I should write a patch for ppp(8) T> to work with ng_iface. :) T> T> -- T> Totus tuus, Glebius. T> GLEBIUS-RIPN GLEB-RIPE T> _______________________________________________ T> freebsd-net@freebsd.org mailing list T> http://lists.freebsd.org/mailman/listinfo/freebsd-net T> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_device.c" /* * Copyright (c) 2002 Mark Santcroos * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * Netgraph "device" node * * This node presents a /dev/ngd%d device that interfaces to an other * netgraph node. * * $FreeBSD: src/sys/netgraph/ng_device.c,v 1.11 2004/07/20 13:16:17 glebius Exp $ * */ #if 0 #define AAA printf("ng_device: %s\n", __func__ ); #else #define AAA #endif #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define ERROUT(x) do { error = (x); goto done; } while (0) /* Netgraph methods */ static ng_constructor_t ng_device_constructor; static ng_rcvmsg_t ng_device_rcvmsg; static ng_shutdown_t ng_device_shutdown; static ng_newhook_t ng_device_newhook; static ng_rcvdata_t ng_device_rcvdata; static ng_disconnect_t ng_device_disconnect; /* Netgraph type */ static struct ng_type ngd_typestruct = { .version = NG_ABI_VERSION, .name = NG_DEVICE_NODE_TYPE, .constructor = ng_device_constructor, .rcvmsg = ng_device_rcvmsg, .shutdown = ng_device_shutdown, .newhook = ng_device_newhook, .rcvdata = ng_device_rcvdata, .disconnect = ng_device_disconnect, }; NETGRAPH_INIT(device, &ngd_typestruct); /* per node data */ struct ngd_private { struct ifqueue readq; SLIST_ENTRY(ngd_private) links; struct ng_node *node; struct ng_hook *hook; struct cdev *ngddev; struct mtx ngd_mtx; int unit; uint16_t flags; #define NGDF_OPEN 0x0001 #define NGDF_RWAIT 0x0002 }; typedef struct ngd_private *priv_p; /* List of all active nodes and mutex to protect it */ static SLIST_HEAD(, ngd_private) ngd_nodes = SLIST_HEAD_INITIALIZER(ngd_nodes); static struct mtx ng_device_mtx; MTX_SYSINIT(ng_device, &ng_device_mtx, "ng_device", MTX_DEF); /* Maximum number of NGD devices */ #define MAX_NGD 25 /* should be more than enough for now */ static d_close_t ngdclose; static d_open_t ngdopen; static d_read_t ngdread; static d_write_t ngdwrite; #if 0 static d_ioctl_t ngdioctl; #endif static d_poll_t ngdpoll; static struct cdevsw ngd_cdevsw = { .d_version = D_VERSION, .d_open = ngdopen, .d_close = ngdclose, .d_read = ngdread, .d_write = ngdwrite, #if 0 .d_ioctl = ngdioctl, #endif .d_poll = ngdpoll, .d_name = NG_DEVICE_DEVNAME, }; /* Helper functions */ static int get_free_unit(void); /****************************************************************************** * Netgraph methods ******************************************************************************/ /* * create new node */ static int ng_device_constructor(node_p node) { priv_p priv; AAA MALLOC(priv, priv_p, sizeof(*priv), M_NETGRAPH, M_NOWAIT | M_ZERO); if (priv == NULL) return (ENOMEM); mtx_init(&priv->ngd_mtx, "ng_device", NULL, MTX_DEF); mtx_lock(&priv->ngd_mtx); mtx_lock(&ng_device_mtx); priv->unit = get_free_unit(); if(priv->unit < 0) { printf("%s: No free unit found by get_free_unit(), " "increase MAX_NGD\n",__func__); mtx_unlock(&ng_device_mtx); mtx_destroy(&priv->ngd_mtx); FREE(priv, M_NETGRAPH); return(EINVAL); } priv->ngddev = make_dev(&ngd_cdevsw, unit2minor(priv->unit), UID_ROOT, GID_WHEEL, 0600, NG_DEVICE_DEVNAME "%d", priv->unit); if(priv->ngddev == NULL) { printf("%s(): make_dev() failed\n",__func__); mtx_unlock(&ng_device_mtx); mtx_destroy(&priv->ngd_mtx); FREE(priv, M_NETGRAPH); return(EINVAL); } SLIST_INSERT_HEAD(&ngd_nodes, priv, links); mtx_unlock(&ng_device_mtx); mtx_init(&priv->readq.ifq_mtx, "ng_device queue", NULL, MTX_DEF); IFQ_SET_MAXLEN(&priv->readq, ifqmaxlen); /* Link everything together */ NG_NODE_SET_PRIVATE(node, priv); priv->node = node; priv->ngddev->si_drv1 = priv; mtx_unlock(&priv->ngd_mtx); return(0); } /* * Process control message. */ static int ng_device_rcvmsg(node_p node, item_p item, hook_p lasthook) { const priv_p priv = NG_NODE_PRIVATE(node); struct ng_mesg *msg; struct ng_mesg *resp = NULL; int error = 0; NGI_GET_MSG(item, msg); if (msg->header.typecookie == NGM_DEVICE_COOKIE) { switch (msg->header.cmd) { case NGM_DEVICE_GET_DEVNAME: /* XXX: Fix when NGD_MAX us bigger */ NG_MKRESPONSE(resp, msg, strlen(NG_DEVICE_DEVNAME) + 3, M_NOWAIT); if (resp == NULL) ERROUT(ENOMEM); strlcpy((char *)resp->data, priv->ngddev->si_name, strlen(priv->ngddev->si_name) + 1); break; default: error = EINVAL; break; } } else error = EINVAL; done: NG_RESPOND_MSG(error, node, item, resp); NG_FREE_MSG(msg); return (error); } /* * Accept incoming hook. We support only one hook per node. */ static int ng_device_newhook(node_p node, hook_p hook, const char *name) { priv_p priv = NG_NODE_PRIVATE(node); AAA /* We have only one hook per node */ if (priv->hook != NULL) return (EISCONN); priv->hook = hook; return(0); } /* * Receive data from hook, write it to device. */ static int ng_device_rcvdata(hook_p hook, item_p item) { priv_p priv = NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); struct mbuf *m; AAA NGI_GET_M(item, m); NG_FREE_ITEM(item); IF_LOCK(&priv->readq); if (_IF_QFULL(&priv->readq)) { _IF_DROP(&priv->readq); IF_UNLOCK(&priv->readq); NG_FREE_M(m); return (ENOBUFS); } _IF_ENQUEUE(&priv->readq, m); IF_UNLOCK(&priv->readq); mtx_lock(&priv->ngd_mtx); if (priv->flags & NGDF_RWAIT) { priv->flags &= ~NGDF_RWAIT; wakeup(priv); } mtx_unlock(&priv->ngd_mtx); return(0); } /* * Removal of the hook destroys the node. */ static int ng_device_disconnect(hook_p hook) { priv_p priv = NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); AAA destroy_dev(priv->ngddev); mtx_destroy(&priv->ngd_mtx); mtx_lock(&ng_device_mtx); SLIST_REMOVE(&ngd_nodes, priv, ngd_private, links); mtx_unlock(&ng_device_mtx); IF_DRAIN(&priv->readq); mtx_destroy(&(priv)->readq.ifq_mtx); FREE(priv, M_NETGRAPH); ng_rmnode_self(NG_HOOK_NODE(hook)); return(0); } /* * Node shutdown. Everything is already done in disconnect method. */ static int ng_device_shutdown(node_p node) { NG_NODE_UNREF(node); return (0); } /****************************************************************************** * Device methods ******************************************************************************/ /* * the device is opened */ static int ngdopen(struct cdev *dev, int flag, int mode, struct thread *td) { priv_p priv = (priv_p )dev->si_drv1; AAA mtx_lock(&priv->ngd_mtx); priv->flags |= NGDF_OPEN; mtx_unlock(&priv->ngd_mtx); return(0); } /* * the device is closed */ static int ngdclose(struct cdev *dev, int flag, int mode, struct thread *td) { priv_p priv = (priv_p )dev->si_drv1; AAA mtx_lock(&priv->ngd_mtx); priv->flags &= ~NGDF_OPEN; mtx_unlock(&priv->ngd_mtx); return(0); } #if 0 /* * The ioctl is transformed into netgraph control message. * We do not process them, yet. */ /* * process ioctl * * they are translated into netgraph messages and passed on * */ static int ngdioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flag, struct thread *td) { struct ngd_softc *sc = &ngd_softc; struct ngd_connection * connection = NULL; struct ngd_connection * tmp; int error = 0; struct ng_mesg *msg; struct ngd_param_s * datap; AAA SLIST_FOREACH(tmp,&sc->head,links) { if(tmp->ngddev == dev) { connection = tmp; } } if(connection == NULL) { printf("%s(): connection is still NULL, no dev found\n",__func__); return(-1); } NG_MKMESSAGE(msg, NGM_DEVICE_COOKIE, cmd, sizeof(struct ngd_param_s), M_NOWAIT); if (msg == NULL) { printf("%s(): msg == NULL\n",__func__); goto nomsg; } /* pass the ioctl data into the ->data area */ datap = (struct ngd_param_s *)msg->data; datap->p = addr; NG_SEND_MSG_HOOK(error, sc->node, msg, connection->active_hook, 0); if(error) printf("%s(): NG_SEND_MSG_HOOK error: %d\n",__func__,error); nomsg: return(0); } #endif /* if 0 */ /* * This function is called when a read(2) is done to our device. * We process one mbuf from queue. */ static int ngdread(struct cdev *dev, struct uio *uio, int flag) { priv_p priv = (priv_p )dev->si_drv1; struct mbuf *m; int len, error = 0; AAA /* get an mbuf */ do { IF_DEQUEUE(&priv->readq, m); if (m == NULL) { if (flag & IO_NDELAY) return (EWOULDBLOCK); mtx_lock(&priv->ngd_mtx); priv->flags |= NGDF_RWAIT; mtx_unlock(&priv->ngd_mtx); if ((error = tsleep(priv, PCATCH | (PZERO + 1), "ngdread", 0)) != 0) return (error); } } while (m == NULL); while (m && uio->uio_resid > 0 && error == 0) { len = MIN(uio->uio_resid, m->m_len); if (len != 0) error = uiomove(mtod(m, void *), len, uio); m = m_free(m); } if (m) m_freem(m); return (error); } /* * This function is called when our device is written to. * We read the data from userland into mbuf chain and pass it to the remote hook. * */ static int ngdwrite(struct cdev *dev, struct uio *uio, int flag) { priv_p priv = (priv_p )dev->si_drv1; struct mbuf *m; int error = 0; AAA if (uio->uio_resid == 0) return (0); if (uio->uio_resid < 0 || uio->uio_resid > IP_MAXPACKET) return (EIO); if ((m = m_uiotombuf(uio, M_DONTWAIT, 0)) == NULL) return (ENOBUFS); NG_SEND_DATA_ONLY(error, priv->hook, m); return (error); } /* * we are being polled/selected * check if there is data available for read */ static int ngdpoll(struct cdev *dev, int events, struct thread *td) { priv_p priv = (priv_p )dev->si_drv1; int revents = 0; if (events & (POLLIN | POLLRDNORM) && !IFQ_IS_EMPTY(&priv->readq)) revents |= events & (POLLIN | POLLRDNORM); return (revents); } /****************************************************************************** * Helper subroutines ******************************************************************************/ static int get_free_unit() { struct ngd_private *priv = NULL; int n = 0; int unit = -1; AAA mtx_assert(&ng_device_mtx, MA_OWNED); /* When there is no list yet, the first device unit is always 0. */ if SLIST_EMPTY(&ngd_nodes) return(0); /* Just do a brute force loop to find the first free unit that is * smaller than MAX_NGD. * Set MAX_NGD to a large value, doesn't impact performance. */ for(n = 0; nunit == n) { unit = -1; break; } unit = n; } } return (unit); } --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_device.h" /* * Copyright (c) 2002 Mark Santcroos * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * * $FreeBSD: src/sys/netgraph/ng_device.h,v 1.3 2004/06/29 15:46:12 marks Exp $ * */ #ifndef _NETGRAPH_NG_DEVICE_H_ #define _NETGRAPH_NG_DEVICE_H_ /* Node type name and magic cookie */ #define NG_DEVICE_NODE_TYPE "device" #define NGM_DEVICE_COOKIE 1091129178 #define NG_DEVICE_DEVNAME "ngd" /* Netgraph control messages */ enum { NGM_DEVICE_GET_DEVNAME, }; #if 0 /* passing ioctl params */ struct ngd_param_s { void * p; }; #endif #endif /* _NETGRAPH_NG_DEVICE_H_ */ --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_device.log" List of functional changes: - Make a single device per single node with a single hook. This gives us parrallelizm, which can't be achieved on a single node with many devices/hooks. This also gives us flexibility - we can play with a particular device node, not affecting others. - Remove read queue as it is. Use struct ifqueue instead. This change removes a lot of extra memcpy()ing, m_devget()ting and m_copymem()ming. In ng_device_receivedata() we take enqueue an mbuf and wake readers. In ngdread() we take one mbuf from qeueue and uiomove() it to userspace. If no mbuf is present we optionally block. [1] - In ngdwrite() we create an mbuf from uio using m_uiotombuf(). This is faster then uiomove() into buffer, and then m_copydata(), and this is much better than huge m_pullup(). - Perform locking of device - Perform locking of connection list. - Clear out _rcvmsg method, since it does nothing good yet. - Implement NGM_DEVICE_GET_DEVNAME message. - #if 0 ioctl method, while nothing is done here yet. - Return immediately from ngdwrite() if uio_resid == 0. List of tidyness changes: - Introduce device2priv(), to remove cut'n'paste. - Use MALLOC/FREE, instead of malloc/free. - Use unit2minor(). - Use UID_ROOT/GID_WHEEL instead of 0/0. - Define NGD_DEVICE_DEVNAME, use it. - Use more nice macros for debugging. [2] - Return Exxx, not -1. style(9): - No "#endif" after short block. - Break long lines. - Remove extra spaces, add needed spaces. [1] Obtained from: if_tun.c [2] Obtained from: ng_pppoe.c --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_device_test.c" #include #include #include #include #include #include #include #define BUFSIZ 16384 uint32_t count = 0; void status() { /* XXX: unsafe */ printf("Written %u bytes\n", count); }; void status_term() { status(); exit(0); }; int o_writedev = 1; int o_writesock = 1; int main(int argc, char *argv[]) { struct ngm_mkpeer mkp; char msgbuf[sizeof(struct ng_mesg) + 6]; struct ng_mesg *rep = (struct ng_mesg *)msgbuf; struct sigaction sa; fd_set rfds; int ch, cs, ds, f, d, maxfd, n, nread, bytes; unsigned char buf[BUFSIZ], buf1[BUFSIZ]; char *fname = NULL; char dname[10]; while ((ch = getopt(argc, argv, "dsf:")) != -1) switch (ch) { case 'd': o_writedev = 0; break; case 's': o_writesock = 0; break; case 'f': fname = optarg; break; default: err(1, "No such option"); } (void )sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sa.sa_handler = status; (void )sigaction(SIGINFO, &sa, (struct sigaction *)0); sa.sa_handler = status_term; (void )sigaction(SIGTERM, &sa, (struct sigaction *)0); (void )sigaction(SIGINT, &sa, (struct sigaction *)0); /* Create a socket node */ if (NgMkSockNode(NULL, &cs, &ds) == -1) err(1, "Cannot create netgraph socket node"); snprintf(mkp.type, sizeof(mkp.type), "%s", NG_DEVICE_NODE_TYPE); snprintf(mkp.ourhook, sizeof(mkp.ourhook), "%s", "device"); snprintf(mkp.peerhook, sizeof(mkp.peerhook), "%s", "socket"); if (NgSendMsg(cs, ".:", NGM_GENERIC_COOKIE, NGM_MKPEER, &mkp, sizeof(mkp)) == -1) err(1, "Cannot create netgraph device node"); if (NgSendMsg(cs, ".:device", NGM_DEVICE_COOKIE, NGM_DEVICE_GET_DEVNAME, NULL, 0) == -1) err(1, "Cannot send NGM_DEVICE_GET_DEVNAME message"); if (NgRecvMsg(cs, rep, sizeof(msgbuf), NULL) == -1) err(1, "Cannon receive device name reply"); snprintf(dname, sizeof(dname), "/dev/%s", (char *)rep->data); printf("Device name is %s\n", dname); if (fname != NULL) { if ((f = open(fname, O_RDONLY)) == -1) err(1, "failed to open %s", fname); } else f = STDIN_FILENO; if ((d = open(dname, O_RDWR)) == -1) err(1, "failed to open %s", dname); maxfd = (((d)>(ds))?(d):(ds)); maxfd++; /* XXX: we do not check for writability */ for (;;) { FD_ZERO(&rfds); FD_SET(f, &rfds); FD_SET(d, &rfds); FD_SET(ds, &rfds); if ((n = select(maxfd, &rfds, NULL, NULL, NULL)) == -1) err(1, "select()"); if (FD_ISSET(d, &rfds)) { if ((nread = read(d, (void *)buf1, BUFSIZ)) == -1) err(1, "read from device"); if (nread == 0) exit (0); buf[nread] = '\0'; if (fname == NULL) printf("Read from device: %s\n", buf1); if (bcmp((void *)buf, (void *)buf1, nread) != 0) printf("Read from device is not identical\n"); } if (FD_ISSET(ds, &rfds)) { if ((nread = read(ds, (void *)buf1, BUFSIZ)) == -1) err(1, "read from socket"); buf[nread+1] = '\0'; if (fname == NULL) printf("Read from socket: %s\n", buf1); if (bcmp((void *)buf, (void *)buf1, nread) != 0) printf("Read from socket is not identical\n"); } if (FD_ISSET(f, &rfds)) { if ((nread = read(f, (void *)buf, BUFSIZ)) == -1) err(1, "read() from input"); if (nread == 0) { status(); return (0); } buf[nread] = '\0'; if (fname == NULL) printf("Read from input: %s\n", buf); if (o_writedev) { if ((bytes = write(d, (void *)buf, nread)) == -1) err(1, "write() to device"); if (bytes != nread) warn("Written %d out of %d to device\n", bytes, nread); } if (o_writesock) { if ((bytes = write(ds, (void *)buf, nread)) == -1) err(1, "write() to socket"); if (bytes != nread) warn("Written %d out of %d to socket\n", bytes, nread); } count += nread; } } } --GvXjxJ+pjyke8COw-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 11:56:33 2004 Return-Path: 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 C1DED16A4CF for ; Mon, 18 Oct 2004 11:56:33 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D740243D31 for ; Mon, 18 Oct 2004 11:56:32 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i9IBuVRJ072407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Oct 2004 15:56:31 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i9IBuUgq072406 for net@freebsd.org; Mon, 18 Oct 2004 15:56:30 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 18 Oct 2004 15:56:30 +0400 From: Gleb Smirnoff To: net@freebsd.org Message-ID: <20041018115630.GA72342@cell.sick.ru> References: <20041010142942.GA13032@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20041010142942.GA13032@cell.sick.ru> User-Agent: Mutt/1.5.6i Subject: Re: [REVIEW/TEST] netgraph node to wrap interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 11:56:34 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=koi8-r Content-Disposition: inline A more simple version for review, which can be built on latest CURRENT, where m_tag_free_default() function is defined in sys/mbuf.h. On Sun, Oct 10, 2004 at 06:29:42PM +0400, Gleb Smirnoff wrote: T> This node is just a proof of concept. At this moment a small T> number of interfaces is supported. Supported interfaces are those, T> who have if_input method defined (all have if_output method defined, T> AFAIK). T> T> Hook semantics are very similar to ng_ether. You have "upper" and T> "lower" hooks. In most setups mbufs coming from upper should T> later be sent on lower, and vice versa. However, you can modify T> them or just read in a netgraph chain. T> T> Sample usage is: T> T> /usr/sbin/ngctl -f- <<-SEQ T> mkpeer ifwrap qq upper T> name .:qq wrap_fxp0 T> disconnect .:qq T> msg wrap_fxp0: attach "fxp0" T> SEQ T> # race? T> sleep 1 T> /usr/sbin/ngctl -f- <<-SEQ T> mkpeer wrap_fxp0: tee upper right T> connect wrap_fxp0: wrap_fxp0:upper lower left T> SEQ -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --zhXaljGHf11kAtnf Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_ifwrap.c" /*- * Copyright (c) 2004 Gleb Smirnoff * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD$ */ #if 0 #define DFUNC(msg) printf("ifwrap: %s: %s\n", __func__, msg); #define DLINE(msg) printf("ifwrap: -%d-: %s", __LINE__, msg ); #else #define DFUNC(msg) #define DLINE(msg) #endif #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define ERROUT(x) do { error = (x); goto done; } while (0) /* Netgraph methods */ static ng_constructor_t ng_ifwrap_constructor; static ng_rcvmsg_t ng_ifwrap_rcvmsg; static ng_shutdown_t ng_ifwrap_shutdown; static ng_newhook_t ng_ifwrap_newhook; static ng_rcvdata_t ng_ifwrap_rcvdata; static ng_disconnect_t ng_ifwrap_disconnect; /* New routines for interface */ static int ng_ifwrap_output(struct ifnet *, struct mbuf *, struct sockaddr *, struct rtentry *); static void ng_ifwrap_input(struct ifnet *, struct mbuf *); /* * Our internal tag to store next hop and rtentry. It is declared * here, since noone except of this node should take care of it. */ struct ifwrap_tag { struct m_tag mt; struct rtentry *rt; struct sockaddr sa; }; #define TAGSIZ (sizeof(struct ifwrap_tag) - sizeof(struct m_tag)) /* Free method for our tags */ static void ifwrap_tag_free(struct m_tag *); /* List of commands and how to convert arguments to/from ASCII */ static const struct ng_cmdlist ng_ifwrap_cmdlist[] = { { NGM_IFWRAP_COOKIE, NGM_IFWRAP_ATTACH, "attach", &ng_parse_string_type, NULL }, { 0 } }; /* Netgraph node type descriptor */ static struct ng_type ng_ifwrap_typestruct = { .version = NG_ABI_VERSION, .name = NG_IFWRAP_NODE_TYPE, .constructor = ng_ifwrap_constructor, .rcvmsg = ng_ifwrap_rcvmsg, .shutdown = ng_ifwrap_shutdown, .newhook = ng_ifwrap_newhook, .rcvdata = ng_ifwrap_rcvdata, .disconnect = ng_ifwrap_disconnect, .cmdlist = ng_ifwrap_cmdlist, }; NETGRAPH_INIT(ifwrap, &ng_ifwrap_typestruct); /* Information we store for each node */ struct ng_ifwrap_priv { struct ifnet *ifp; /* pointer to our ifnet */ node_p node; /* back pointer to node */ hook_p upper; /* hook for input */ hook_p lower; /* hook for output */ /* Pointers to original routines */ int (*if_output) (struct ifnet *, struct mbuf *, struct sockaddr *, struct rtentry *); void (*if_input) (struct ifnet *, struct mbuf *); }; typedef struct ng_ifwrap_priv *priv_p; /* This is where we store pointer from iface to node private date. This * makes us incompatible with ng_fec(4). */ #define IFP2NG(ifp) (priv_p )(ifp->if_afdata[AF_NETGRAPH]) #define IFP2NG_SET(ifp, val) ifp->if_afdata[AF_NETGRAPH] = (val); /****************************************************************************** * Netgraph methods ******************************************************************************/ static int ng_ifwrap_constructor(node_p node) { priv_p priv; MALLOC(priv, priv_p, sizeof(*priv), M_NETGRAPH, M_NOWAIT | M_ZERO); if (priv == NULL) return (ENOMEM); NG_NODE_SET_PRIVATE(node, priv); priv->node = node; return (0); } /* * Hooks are almost the same as ng_ether's, and so is this callback. */ static int ng_ifwrap_newhook(node_p node, hook_p hook, const char *name) { const priv_p priv = NG_NODE_PRIVATE(node); hook_p *hookptr; if (strcmp(name, NG_IFWRAP_HOOK_UPPER) == 0) hookptr = &priv->upper; else if (strcmp(name, NG_IFWRAP_HOOK_LOWER) == 0) hookptr = &priv->lower; else return (EINVAL); /* Check if already connected */ if (*hookptr != NULL) return (EISCONN); *hookptr = hook; return (0); } static int ng_ifwrap_rcvmsg(node_p node, item_p item, hook_p lasthook) { const priv_p priv = NG_NODE_PRIVATE(node); struct ng_mesg *msg, *resp = NULL; int error = 0; NGI_GET_MSG(item, msg); switch (msg->header.typecookie) { case NGM_IFWRAP_COOKIE: switch (msg->header.cmd) { case NGM_IFWRAP_ATTACH: /* Check if we are already initialized */ if (priv->ifp != NULL) ERROUT(EISCONN); if (msg->header.arglen == 0) ERROUT(EINVAL); if ((priv->ifp = ifunit((char *)msg->data)) == NULL) ERROUT(ENOENT); /* * Not all interfaces have both input and output * method. Those are not supported. */ if (priv->ifp->if_input == NULL || priv->ifp->if_output == NULL) ERROUT(ENOTSUP); /* * XXX: There is no mutex to lock struct ifnet yet, * so we will hold afdata_mtx for the whole surgery * procedure. This will not stop races, since other * struct-ifnet-surgeons does not do it same way. */ IF_AFDATA_LOCK(priv->ifp); /* Check if someone already have grabbed AF_NETGRAPH */ if(IFP2NG(priv->ifp) != NULL) { IF_AFDATA_UNLOCK(priv->ifp); priv->ifp = NULL; ERROUT(EISCONN); } IFP2NG_SET(priv->ifp, priv); priv->if_input = priv->ifp->if_input; priv->ifp->if_input = ng_ifwrap_input; priv->if_output = priv->ifp->if_output; priv->ifp->if_output = ng_ifwrap_output; IF_AFDATA_UNLOCK(priv->ifp); break; default: error = EINVAL; break; } break; default: error = EINVAL; break; } done: NG_RESPOND_MSG(error, node, item, resp); NG_FREE_MSG(msg); return(error); } static int ng_ifwrap_rcvdata(hook_p hook, item_p item ) { const priv_p priv = NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); struct mbuf *m; int error = 0; NGI_GET_M(item, m); NG_FREE_ITEM(item); /* Check if we have attached interface */ if (priv->ifp == NULL) { NG_FREE_M(m); return (ENOTCONN); } if (hook == priv->upper) { (priv->if_input)(priv->ifp, m); return (0); } else if (hook == priv->lower) { struct ifwrap_tag *tag; struct sockaddr *dst; tag = (struct ifwrap_tag *)m_tag_locate(m, NGM_IFWRAP_COOKIE, NG_IFWRAP_TAG_OUTPUT, NULL); if (tag == NULL) { DFUNC("no tag in input packet"); NG_FREE_M(m); return (EDESTADDRREQ); } dst = &tag->sa; error = (priv->if_output)(priv->ifp, m, dst, tag->rt); return (error); } else panic("ng_ifwrap: unknown hook"); /* not reach */ return (0); } static int ng_ifwrap_shutdown(node_p node) { const priv_p priv = NG_NODE_PRIVATE(node); if (priv->ifp != NULL) { IF_AFDATA_LOCK(priv->ifp); IFP2NG_SET(priv->ifp, NULL); /* Restore old methods */ priv->ifp->if_input = priv->if_input; priv->ifp->if_output = priv->if_output; IF_AFDATA_UNLOCK(priv->ifp); } NG_NODE_UNREF(node); FREE(priv, M_NETGRAPH); return (0); } static int ng_ifwrap_disconnect(hook_p hook) { const priv_p priv = NG_NODE_PRIVATE(NG_HOOK_NODE(hook)); if (hook == priv->lower) priv->lower = NULL; if (hook == priv->upper) priv->upper = NULL; return (0); } static int ng_ifwrap_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, struct rtentry *rt) { const priv_p priv = IFP2NG(ifp); struct ifwrap_tag *tag; int error = 0; DFUNC("in"); if (priv->upper == NULL) return (priv->if_output)(ifp, m, dst, rt); /* Save rt and dst in mbuf tag */ if ((tag = (struct ifwrap_tag *)m_tag_alloc(NGM_IFWRAP_COOKIE, NG_IFWRAP_TAG_OUTPUT, TAGSIZ, M_DONTWAIT)) == NULL) { m_freem(m); return (ENOMEM); } tag->mt.m_tag_free = &ifwrap_tag_free; bcopy(dst, &tag->sa, dst->sa_len); /* do not allow ip_output() to free our rt */ if (rt != NULL) { RT_LOCK(rt); RT_ADDREF(rt); RT_UNLOCK(rt); tag->rt = rt; } else tag->rt = NULL; m_tag_prepend(m, &tag->mt); NG_SEND_DATA_ONLY(error, priv->upper, m); return (error); } static void ng_ifwrap_input(struct ifnet *ifp, struct mbuf *m) { const priv_p priv = IFP2NG(ifp); int error; DFUNC("in"); if (priv->lower == NULL) return (priv->if_input)(ifp, m); NG_SEND_DATA_ONLY(error, priv->lower, m); return; } /****************************************************************************** * Helper functions ******************************************************************************/ static void ifwrap_tag_free(struct m_tag *mt) { struct ifwrap_tag *tag = (struct ifwrap_tag *)mt; DFUNC("in"); if (tag->rt != NULL) RTFREE(tag->rt); m_tag_free_default(mt); } --zhXaljGHf11kAtnf Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_ifwrap.h" /*- * Copyright (c) 2004 Gleb Smirnoff * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHIFWRAP IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD$ */ #ifndef _NETGRAPH_NG_IFWRAP_H_ #define _NETGRAPH_NG_IFWRAP_H_ #define NG_IFWRAP_NODE_TYPE "ifwrap" #define NGM_IFWRAP_COOKIE 1094849975 /* Hook names, just like in ng_ether */ #define NG_IFWRAP_HOOK_LOWER "lower" /* -> input */ #define NG_IFWRAP_HOOK_UPPER "upper" /* -> output */ /* Tags */ enum { NG_IFWRAP_TAG_OUTPUT, /* stores parameters of if_output() */ }; /* Netgraph commands */ enum { NGM_IFWRAP_ATTACH, /* attach to interface */ }; #endif /* _NETGRAPH_NG_IFWRAP_H_ */ --zhXaljGHf11kAtnf-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 14:05:35 2004 Return-Path: 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 B3E4416A4CF for ; Mon, 18 Oct 2004 14:05:35 +0000 (GMT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7B9943D31 for ; Mon, 18 Oct 2004 14:05:32 +0000 (GMT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.11/8.12.11) with ESMTP id i9IE5Spg000539 for ; Mon, 18 Oct 2004 22:05:28 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i9IE5RdQ000538 for net@freebsd.org; Mon, 18 Oct 2004 22:05:27 +0800 (KRAST) (envelope-from eugen) Date: Mon, 18 Oct 2004 22:05:27 +0800 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20041018140527.GA441@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: asymmetric NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 14:05:35 -0000 Hi! Let's consider a simple scheme with two NAT boxes where packet flow is asymmetric: A----+ | | S ---+ T | | B----+ Here S is a host in the local network and its IP is 192.168.1.1, A and B are both border routers and both do NAT, T is a target server in a public Internet having IP address 1.1.1.1. All links drawn above are WAN and multihop links. Outgoing traffic from S to T flows through A, incoming traffic flows through B. A has 2.2.2.2 for its outer interface, B has 3.3.3.3 for its. A and B both do "static NAT" for S, they translate 192.168.1.1 to 4.4.4.4 (and vise versa). One can try redirect_address 192.168.1.1 4.4.4.4 for natd(8) configuration (and corresponding ipfw rules) to achieve this. AFAIK, libalias and ipnat do not support this configuration currently. I'm trying to patch libalias to support this and have some progress but still cannot make work active mode FTP transfers when S is a client and T is a server. Should this schema work in a theory at least? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 17:30:09 2004 Return-Path: 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 C553F16A4CF for ; Mon, 18 Oct 2004 17:30:09 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D572843D53 for ; Mon, 18 Oct 2004 17:30:08 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id E7FF11FF903; Mon, 18 Oct 2004 19:30:06 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 2042C1FF9A8; Mon, 18 Oct 2004 19:30:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id D6AE4156BA; Mon, 18 Oct 2004 17:28:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id CBE23154FC; Mon, 18 Oct 2004 17:28:02 +0000 (UTC) Date: Mon, 18 Oct 2004 17:28:02 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Eugene Grosbein In-Reply-To: <20041018140527.GA441@grosbein.pp.ru> Message-ID: References: <20041018140527.GA441@grosbein.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: net@freebsd.org Subject: Re: asymmetric NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 17:30:09 -0000 On Mon, 18 Oct 2004, Eugene Grosbein wrote: > Hi! > > Let's consider a simple scheme with two NAT boxes > where packet flow is asymmetric: > > A----+ > | | > S ---+ T > | | > B----+ ... > A has 2.2.2.2 for its outer interface, B has 3.3.3.3 for its. > A and B both do "static NAT" for S, they translate > 192.168.1.1 to 4.4.4.4 (and vise versa). One can try ... > AFAIK, libalias and ipnat do not support this configuration currently. > I'm trying to patch libalias to support this and have some progress > but still cannot make work active mode FTP transfers when S is a client > and T is a server. > > Should this schema work in a theory at least? the only thing I can think of is to have some kind of protocoll beteween A and B that a) in almost realtime syncs states or b) queries the other for a known state about the connection in question and updates it's internal "tables". both are problematic and normally addressed in HA software. For you scenario an unidirectional syncing would be enough but if you want to dtrt do it bidirectional because you might not be able to garantee 100% that all traffic leaves through A and responses always come in via B. just my 2cs -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 18:02:30 2004 Return-Path: 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 5891416A4CE for ; Mon, 18 Oct 2004 18:02:30 +0000 (GMT) Received: from dauntless.milewski.org (dauntless.milewski.org [64.142.38.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39F6143D3F for ; Mon, 18 Oct 2004 18:02:30 +0000 (GMT) (envelope-from zandr@asperasoft.com) Received: by dauntless.milewski.org (Postfix, from userid 8) id EB967604D1; Mon, 18 Oct 2004 11:01:40 -0700 (PDT) X-Scanned-By: AMaViS at dauntless.milewski.org. Received: from [192.168.1.191] (adsl-64-142-38-164.sonic.net [64.142.38.164]) by dauntless.milewski.org (Postfix) with ESMTP id E7C035FAEE for ; Mon, 18 Oct 2004 11:01:37 -0700 (PDT) Message-ID: <41740500.7010404@asperasoft.com> Date: Mon, 18 Oct 2004 11:01:36 -0700 From: Aleksandr Milewski User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: PCI-E Marvell Yukon? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 18:02:30 -0000 Apologies if this is in a FAQ (or worse, I'm posting to the wrong list). *BSD is somewhat new to me as most of my *nix experience is with that Finnish OS. :) Having reached my wits end with NISTnet/netem, I'm trying to build a fast (~1Gb/s) Dummynet machine, and the machines I have available are Asus P5GDC-V boards and SysKonnect SK-9E21D NICs. Both of these are Marvell Yukon chips on PCI-Express. FreeBSD (I last tried 5.3Beta6) doesn't see these at all, but happily detects the cheap and nasty rtk I tossed in as a management interface. Is there any way to get these NICs running under FreeBSD? This is a lab machine, so I'm quite happy to be on the bleeding edge if necessary. Any wisdom would be appreciated, I'd rather not have to replace these machines to get sk's on conventional PCI (which I know I can make work). Thanks in advance, Zandr From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 19:01:15 2004 Return-Path: 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 DC8A216A4CE; Mon, 18 Oct 2004 19:01:15 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE95A43D39; Mon, 18 Oct 2004 19:01:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 99E417A41E; Mon, 18 Oct 2004 12:01:15 -0700 (PDT) Message-ID: <417412FB.3040906@elischer.org> Date: Mon, 18 Oct 2004 12:01:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20041011103028.GA18981@cell.sick.ru> <20041018113719.GA72194@cell.sick.ru> In-Reply-To: <20041018113719.GA72194@cell.sick.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: new ng_device X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 19:01:16 -0000 Gleb Smirnoff wrote: >A slightly updated version: use m_uiotombuf() instead >of homegrown implementation. > >On Mon, Oct 11, 2004 at 02:30:28PM +0400, Gleb Smirnoff wrote: >T> Here is a major rewrite of ng_device. The main >T> differencies with current one are: > > looks good to me From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 21:03:17 2004 Return-Path: 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 40B8D16A4CE for ; Mon, 18 Oct 2004 21:03:17 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9471743D49 for ; Mon, 18 Oct 2004 21:03:16 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id C157F54C9 for ; Sun, 17 Oct 2004 13:19:45 -0700 (PDT) To: freebsd-net@freebsd.org Date: Sun, 17 Oct 2004 13:19:45 -0700 Message-ID: <49035.1098044385@monkeys.com> From: "Ronald F. Guilmette" Subject: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 21:03:17 -0000 [[This question is related vaguely to the other question that I posted to this list a few minutes ago.]] I'm sitting here looking at that man pages for aio_read and aio_write, and the question occurs to me: ``Home come there is no such thing as an aio_connect function?'' There are clearly cases in which one would like to perform reads asynchronously, but likewise, there are cases where one might like to also perform socket connects asynchronously. So how come no aio_connect? From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 21:03:17 2004 Return-Path: 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 504A216A4CF for ; Mon, 18 Oct 2004 21:03:17 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 956E243D4C for ; Mon, 18 Oct 2004 21:03:16 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id AFF5554A7 for ; Sun, 17 Oct 2004 13:07:49 -0700 (PDT) To: freebsd-net@freebsd.org Date: Sun, 17 Oct 2004 13:07:49 -0700 Message-ID: <48850.1098043669@monkeys.com> From: "Ronald F. Guilmette" Subject: Question about controlling socket connect retries X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 21:03:17 -0000 Greetings folks, It is my understanding that when one makes a call to connect(2) in order to, for example, make an IPv4 TCP connection to some server, a SYN packet is sent out, and then, if neither a corresponding SYN+ACK nor any other kind of (NACK) response is received within some specific (short) period of time, the connection attempt is retried by sending out another SYN packet. My understanding... which may be wrong... is also that there may in fact be more than one SYN retry made, during an attempt to make a TCP socket connection, as necessary. (But I may have misunderstood the mechanics of such things, in which case I would be grateful for any corrections to my understanding.) Anyway, assuming that the above is accurate, then I am inclined to wonder whether or not anything in FreeBSD provides me with a way to inspect and/or modify any of the parameters relevant to TCP connect retries. In particular I would like to be able to programatically inspect and/or diddle the following relevant parameters: 1) The time period between SYN retries. 2) The total number unanswered SYN retries that will be attempted before a failure of the connect(2) call will be returned back to the userland program. My (admittedly uneducated) guess is that there are probably some sysctl parameters that might be used to modify the above low-level protocol parameters, however after a cursory search for such, I have been unable to locate any such. Thus, I would be very grateful if someone could point me at the relevant sysctl parameters. Thanks. P.S. I should say that I _do_ understand that the relevant RFCs may perhaps specify some very specific requirements on the two parameters I have mentioned above, and that deviation from the RFCs with respect to either parameter may perhaps render one non-RFC-conformant, however for my purposes, that would be perfectly OK. From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 21:11:43 2004 Return-Path: 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 7029C16A4CE for ; Mon, 18 Oct 2004 21:11:43 +0000 (GMT) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F94143D3F for ; Mon, 18 Oct 2004 21:11:42 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: (qmail 15310 invoked by uid 207); 18 Oct 2004 21:11:41 -0000 Received: from keramida@freebsd.org by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.65):. Processed in 2.504229 secs); 18 Oct 2004 21:11:41 -0000 Received: from dialup65.ach.sch.gr (HELO gothmog.gr) ([81.186.70.65]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Oct 2004 21:11:38 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i9IKY38a004472; Mon, 18 Oct 2004 23:34:03 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i9IKY3t1004471; Mon, 18 Oct 2004 23:34:03 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 18 Oct 2004 23:34:03 +0300 From: Giorgos Keramidas To: Aleksandr Milewski Message-ID: <20041018203403.GA3992@gothmog.gr> References: <41740500.7010404@asperasoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41740500.7010404@asperasoft.com> cc: freebsd-net@freebsd.org Subject: Re: PCI-E Marvell Yukon? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 21:11:43 -0000 On 2004-10-18 11:01, Aleksandr Milewski wrote: > Apologies if this is in a FAQ (or worse, I'm posting to the wrong list). > *BSD is somewhat new to me as most of my *nix experience is with that > Finnish OS. :) > > Having reached my wits end with NISTnet/netem, I'm trying to build a > fast (~1Gb/s) Dummynet machine, and the machines I have available are > Asus P5GDC-V boards and SysKonnect SK-9E21D NICs. The SysKonnect adapters are supported by the sk driver on FreeBSD, which has "issues" in 5.X or later. I gave up after a month of fiddling with the settings of the interface and installed a Netgear adapter (sis driver). From owner-freebsd-net@FreeBSD.ORG Mon Oct 18 21:38:59 2004 Return-Path: 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 AD14A16A4CE for ; Mon, 18 Oct 2004 21:38:59 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50D2A43D4C for ; Mon, 18 Oct 2004 21:38:59 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i9ILcvqw095285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Mon, 18 Oct 2004 17:38:58 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i9ILcvmG095282; Mon, 18 Oct 2004 17:38:57 -0400 (EDT) (envelope-from wollman) Date: Mon, 18 Oct 2004 17:38:57 -0400 (EDT) From: Garrett Wollman Message-Id: <200410182138.i9ILcvmG095282@khavrinen.lcs.mit.edu> To: "Ronald F. Guilmette" In-Reply-To: <49035.1098044385@monkeys.com> References: <49035.1098044385@monkeys.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@FreeBSD.ORG Subject: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2004 21:38:59 -0000 < said: > I'm sitting here looking at that man pages for aio_read and aio_write, > and the question occurs to me: ``Home come there is no such thing as > an aio_connect function?'' Mostly because there is no need, since connect() doesn't transfer any data; it just establishes a connection. If the socket is put in non-blocking mode, connect() will take place in the background. -GAWollman From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 03:33:35 2004 Return-Path: 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 C584216A4CE for ; Tue, 19 Oct 2004 03:33:35 +0000 (GMT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFFEE43D45 for ; Tue, 19 Oct 2004 03:33:33 +0000 (GMT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i9J3XVGk092564; Tue, 19 Oct 2004 11:33:31 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <41748A86.B377F2BC@kuzbass.ru> Date: Tue, 19 Oct 2004 11:31:18 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20041018140527.GA441@grosbein.pp.ru> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: asymmetric NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 03:33:35 -0000 "Bjoern A. Zeeb" wrote: > > Let's consider a simple scheme with two NAT boxes > > where packet flow is asymmetric: > > > > A----+ > > | | > > S ---+ T > > | | > > B----+ > ... > > A has 2.2.2.2 for its outer interface, B has 3.3.3.3 for its. > > A and B both do "static NAT" for S, they translate > > 192.168.1.1 to 4.4.4.4 (and vise versa). One can try > ... > > AFAIK, libalias and ipnat do not support this configuration currently. > > I'm trying to patch libalias to support this and have some progress > > but still cannot make work active mode FTP transfers when S is a client > > and T is a server. > > > > Should this schema work in a theory at least? > > the only thing I can think of is to have some kind of protocoll > beteween A and B that > > a) in almost realtime syncs states > or > b) queries the other for a known state about the connection in > question and updates it's internal "tables". > > both are problematic and normally addressed in HA software. > > For you scenario an unidirectional syncing would be enough but > if you want to dtrt do it bidirectional because you might not be able > to garantee 100% that all traffic leaves through A and responses > always come in via B. You are right, packet flow can change. But why may I need to sync states of NAT boxes in case of static NAT? Eugene From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 06:23:45 2004 Return-Path: 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 D08E516A4CE for ; Tue, 19 Oct 2004 06:23:45 +0000 (GMT) Received: from ns1.interbgc.com (mail.interbgc.com [217.9.224.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 73B3443D3F for ; Tue, 19 Oct 2004 06:23:44 +0000 (GMT) (envelope-from misho@interbgc.com) Received: (qmail 88136 invoked from network); 19 Oct 2004 06:23:17 -0000 Received: from misho@interbgc.com by keeper.interbgc.com by uid 1002 with qmail-scanner-1.14 (uvscan: v4.2.40/v4374. spamassassin: 2.63. Clear:SA:0(-4.9/8.0):. Processed in 0.606268 secs); 19 Oct 2004 06:23:17 -0000 X-Spam-Status: No, hits=-4.9 required=8.0 Received: from topilapi.ddns.cablebg.net (HELO misho) (213.240.200.136) by mail.interbgc.com with SMTP; 19 Oct 2004 06:23:16 -0000 Message-ID: <002f01c4b5a4$1e481140$88c8f0d5@misho> From: "Mihail Balikov" To: References: <20041011103028.GA18981@cell.sick.ru><20041018113719.GA72194@cell.sick.ru> <417412FB.3040906@elischer.org> Date: Tue, 19 Oct 2004 09:23:15 +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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Re: new ng_device X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Mihail Balikov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 06:23:45 -0000 Hello, is it possible to connect ng_pppoe node to ng_device and to use pppd ? regards, Mihail Balikov ----- Original Message ----- From: "Julian Elischer" To: "Gleb Smirnoff" Cc: Sent: Monday, October 18, 2004 10:01 PM Subject: Re: new ng_device > > > Gleb Smirnoff wrote: > > >A slightly updated version: use m_uiotombuf() instead > >of homegrown implementation. > > > >On Mon, Oct 11, 2004 at 02:30:28PM +0400, Gleb Smirnoff wrote: > >T> Here is a major rewrite of ng_device. The main > >T> differencies with current one are: > > > > > > looks good to me > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 06:30:30 2004 Return-Path: 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 5261216A4CF for ; Tue, 19 Oct 2004 06:30:30 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DA7443D31 for ; Tue, 19 Oct 2004 06:30:30 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id 7FE3A54A7; Mon, 18 Oct 2004 23:30:28 -0700 (PDT) To: Garrett Wollman In-reply-to: Your message of Mon, 18 Oct 2004 17:38:57 -0400. <200410182138.i9ILcvmG095282@khavrinen.lcs.mit.edu> Date: Mon, 18 Oct 2004 23:30:28 -0700 Message-ID: <67378.1098167428@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@FreeBSD.ORG Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 06:30:30 -0000 In message <200410182138.i9ILcvmG095282@khavrinen.lcs.mit.edu>, you wrote: >< said: > >> I'm sitting here looking at that man pages for aio_read and aio_write, >> and the question occurs to me: ``Home come there is no such thing as >> an aio_connect function?'' > >Mostly because there is no need, since connect() doesn't transfer any >data; it just establishes a connection. If the socket is put in >non-blocking mode, connect() will take place in the background. That is a very interesting point, and one which I am now pondering. I myself _have_ in fact done what you are talking about before, i.e. starting up a non-blocking connect and then coming back later on with, say, either select() or poll() to see if it has finished. So I _do_ know how to do what you are describing. But thinking about it now, I'd just like to say that it seems to me that that approach may have some significantly different semantics than the hypothetical aio_connect() function that I had suggested. (But then again, maybe not. I'll have to give it some more thought.) Anyway, upon further reflection (and further RTFM'ing) I am now inclined towards a distinct dislike for the entire aio_*() family of functions because, as I just now realized, they provide the programmer with a synchronous way (i.e. the aio_error function) of checking for inherently _asynchronous_ events, i.e. I/O completions. All things considered, I think that I personally would prefer to receive such notifications (of asynchronous I/O completions) via interrupts... er... I mean via signals. (I suppose that there is some way of doing that, but I confess that I per- sonally have never come across it, so if anybody wants to educate me, then by all means please do so.) P.S. And before anybody lambasts me about the head and neck for even suggesting the use of signals to indicate I/O completions, allow me to just say that yes, I _do_ undertstand that this would be quite costly, but for some applications, the cost would be acceptable. From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 07:29:33 2004 Return-Path: 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 993EC16A4CE for ; Tue, 19 Oct 2004 07:29:33 +0000 (GMT) Received: from therion.astral-on.net (therion.astral-on.net [193.41.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAF8743D41 for ; Tue, 19 Oct 2004 07:29:31 +0000 (GMT) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (odin.astral-on.net [193.41.4.6]) i9J7TRol039959 for ; Tue, 19 Oct 2004 10:29:27 +0300 (EEST) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (localhost.astral-on.net [127.0.0.1]) by odin.astral-on.net (8.12.8p2/8.12.8) with ESMTP id i9J7TRwk009071 for ; Tue, 19 Oct 2004 10:29:27 +0300 (EEST) (envelope-from ad@odin.astral-on.net) Received: (from ad@localhost) by odin.astral-on.net (8.12.8p2/8.12.8/Submit) id i9J7TQ3l009070 for freebsd-net@freebsd.org; Tue, 19 Oct 2004 10:29:26 +0300 (EEST) Date: Tue, 19 Oct 2004 10:29:26 +0300 From: Andrew Degtiariov To: freebsd-net@freebsd.org Message-ID: <20041019072926.GB6079@astral-on.net> 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.6i Subject: ALTQ CDNR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-net@astral-on.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 07:29:33 -0000 Hello people! Whether works or not ALTQ CDNR in FreeBSD 5.3? -- Andrew Degtiariov DA-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 07:33:48 2004 Return-Path: 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 F1E5D16A4CE for ; Tue, 19 Oct 2004 07:33:48 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95FAD43D53 for ; Tue, 19 Oct 2004 07:33:48 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by mproxy.gmail.com with SMTP id 74so296681rnk for ; Tue, 19 Oct 2004 00:33:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hyxpq82usKxpz65JWp9ne1mQtssmnJ4Bl6MdZ730lTXy43VvL+I0emIN6oY2PSCKZB5g3v3oGFQi/xVaumachk0Shk3zzsNZt/lybU4HlfNy8mFdl69iFITtm4RpPQ90Cumw0RBapkscWg6x2XU94XC4K3VfW56Gfs3in8VAabo Received: by 10.38.9.24 with SMTP id 24mr1841925rni; Tue, 19 Oct 2004 00:33:47 -0700 (PDT) Received: by 10.38.149.19 with HTTP; Tue, 19 Oct 2004 00:33:47 -0700 (PDT) Message-ID: <79722fad0410190033147e8601@mail.gmail.com> Date: Tue, 19 Oct 2004 10:33:47 +0300 From: Vlad GALU To: freebsd-net@astral-on.net, freebsd-net@freebsd.org In-Reply-To: <20041019072926.GB6079@astral-on.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041019072926.GB6079@astral-on.net> Subject: Re: ALTQ CDNR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vlad GALU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 07:33:49 -0000 On Tue, 19 Oct 2004 10:29:26 +0300, Andrew Degtiariov wrote: > Hello people! > Whether works or not ALTQ CDNR in FreeBSD 5.3? > You don't need that anymore. You can mark packets directly from pf. > -- > Andrew Degtiariov > DA-RIPE > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 07:43:37 2004 Return-Path: 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 2E88116A4CE for ; Tue, 19 Oct 2004 07:43:37 +0000 (GMT) Received: from therion.astral-on.net (therion.astral-on.net [193.41.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A6AE43D48 for ; Tue, 19 Oct 2004 07:43:35 +0000 (GMT) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (odin.astral-on.net [193.41.4.6]) i9J7hPol043420; Tue, 19 Oct 2004 10:43:26 +0300 (EEST) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (localhost.astral-on.net [127.0.0.1]) by odin.astral-on.net (8.12.8p2/8.12.8) with ESMTP id i9J7hPwk009567; Tue, 19 Oct 2004 10:43:25 +0300 (EEST) (envelope-from ad@odin.astral-on.net) Received: (from ad@localhost) by odin.astral-on.net (8.12.8p2/8.12.8/Submit) id i9J7hOJ4009566; Tue, 19 Oct 2004 10:43:24 +0300 (EEST) Date: Tue, 19 Oct 2004 10:43:24 +0300 From: Andrew Degtiariov To: Vlad GALU Message-ID: <20041019074324.GC6079@astral-on.net> Mail-Followup-To: Vlad GALU , freebsd-net@astral-on.net, freebsd-net@freebsd.org References: <20041019072926.GB6079@astral-on.net> <79722fad0410190033147e8601@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79722fad0410190033147e8601@mail.gmail.com> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org cc: freebsd-net@astral-on.net Subject: Re: ALTQ CDNR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-net@astral-on.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 07:43:37 -0000 On Tue, Oct 19, 2004 at 10:33:47AM +0300, Vlad GALU wrote: > On Tue, 19 Oct 2004 10:29:26 +0300, Andrew Degtiariov > wrote: > > Hello people! > > Whether works or not ALTQ CDNR in FreeBSD 5.3? > > > You don't need that anymore. You can mark packets directly from pf. I can change TOS field in pf? ALTQ CDNR does it. -- Andrew Degtiariov DA-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 07:57:44 2004 Return-Path: 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 6808D16A4CE for ; Tue, 19 Oct 2004 07:57:44 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5C8243D49 for ; Tue, 19 Oct 2004 07:57:43 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by mproxy.gmail.com with SMTP id 73so298131rnk for ; Tue, 19 Oct 2004 00:57:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=PIea+dw0gZKPTI9vhb3jmYbmcM1KkT7jRJRsD4mGS4W2Sty2JFr1qS3B1s5uI/3eBiPCztG3/k5mTgqdXKDVCuzCGB7xzZxeGg3wIsGNY9H+0r4bVvfpIFvSJk3VieoBoU0HeqxtWv2nzDWklJ5QmYpCswpLTuSIP19Cm27Havs Received: by 10.38.152.39 with SMTP id z39mr1847840rnd; Tue, 19 Oct 2004 00:57:41 -0700 (PDT) Received: by 10.38.149.19 with HTTP; Tue, 19 Oct 2004 00:57:41 -0700 (PDT) Message-ID: <79722fad0410190057417778be@mail.gmail.com> Date: Tue, 19 Oct 2004 10:57:41 +0300 From: Vlad GALU To: freebsd-net@freebsd.org In-Reply-To: <20041019074324.GC6079@astral-on.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20041019072926.GB6079@astral-on.net> <79722fad0410190033147e8601@mail.gmail.com> <20041019074324.GC6079@astral-on.net> Subject: Re: ALTQ CDNR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Vlad GALU List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 07:57:44 -0000 On Tue, 19 Oct 2004 10:43:24 +0300, Andrew Degtiariov wrote: > On Tue, Oct 19, 2004 at 10:33:47AM +0300, Vlad GALU wrote: > > On Tue, 19 Oct 2004 10:29:26 +0300, Andrew Degtiariov > > wrote: > > > Hello people! > > > Whether works or not ALTQ CDNR in FreeBSD 5.3? > > > > > You don't need that anymore. You can mark packets directly from pf. > I can change TOS field in pf? ALTQ CDNR does it. > I'm not sure, but it can tag packets and you can match them afterwards, when assigning them to a specific queue. > -- > Andrew Degtiariov > DA-RIPE > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 08:06:56 2004 Return-Path: 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 A4E5E16A4CE for ; Tue, 19 Oct 2004 08:06:56 +0000 (GMT) Received: from therion.astral-on.net (therion.astral-on.net [193.41.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0966343D53 for ; Tue, 19 Oct 2004 08:06:55 +0000 (GMT) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (odin.astral-on.net [193.41.4.6]) i9J86qol049974 for ; Tue, 19 Oct 2004 11:06:52 +0300 (EEST) (envelope-from ad@astral-on.net) Received: from odin.astral-on.net (localhost.astral-on.net [127.0.0.1]) by odin.astral-on.net (8.12.8p2/8.12.8) with ESMTP id i9J86qwk010353 for ; Tue, 19 Oct 2004 11:06:52 +0300 (EEST) (envelope-from ad@odin.astral-on.net) Received: (from ad@localhost) by odin.astral-on.net (8.12.8p2/8.12.8/Submit) id i9J86pr8010352 for freebsd-net@freebsd.org; Tue, 19 Oct 2004 11:06:51 +0300 (EEST) Date: Tue, 19 Oct 2004 11:06:51 +0300 From: Andrew Degtiariov To: freebsd-net@freebsd.org Message-ID: <20041019080651.GD6079@astral-on.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20041019072926.GB6079@astral-on.net> <79722fad0410190033147e8601@mail.gmail.com> <20041019074324.GC6079@astral-on.net> <79722fad0410190057417778be@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79722fad0410190057417778be@mail.gmail.com> User-Agent: Mutt/1.5.6i Subject: Re: ALTQ CDNR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-net@astral-on.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 08:06:56 -0000 On Tue, Oct 19, 2004 at 10:57:41AM +0300, Vlad GALU wrote: > > > On Tue, 19 Oct 2004 10:29:26 +0300, Andrew Degtiariov > > > wrote: > > > > Hello people! > > > > Whether works or not ALTQ CDNR in FreeBSD 5.3? > > > > > > > You don't need that anymore. You can mark packets directly from pf. > > I can change TOS field in pf? ALTQ CDNR does it. > > > I'm not sure, but it can tag packets and you can match them > afterwards, when assigning them to a specific queue. I can't match tagget by router 1 packets on router 2. ALTQ CDNR was a suitable tool for this and sadly see that support of ones was dropped. -- Andrew Degtiariov DA-RIPE From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 10:41:09 2004 Return-Path: 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 27F7516A4CE for ; Tue, 19 Oct 2004 10:41:09 +0000 (GMT) Received: from web54604.mail.yahoo.com (web54604.mail.yahoo.com [68.142.225.188]) by mx1.FreeBSD.org (Postfix) with SMTP id C98F043D31 for ; Tue, 19 Oct 2004 10:41:08 +0000 (GMT) (envelope-from ceyong@yahoo.com) Message-ID: <20041019104108.41717.qmail@web54604.mail.yahoo.com> Received: from [202.184.38.16] by web54604.mail.yahoo.com via HTTP; Tue, 19 Oct 2004 03:41:08 PDT Date: Tue, 19 Oct 2004 03:41:08 -0700 (PDT) From: "Yong Chu Eu (Ñî×ÓÓÓ)" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: multicast problem in vls on freebsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 10:41:09 -0000 When i install freeBSD 4.10 without kame code, my multicast function on router fail. i try to stream multicast video(vls) from router to vlc player at client? ===== Ô¸ÄúÓÀÔ¶ĞÒ¸££¬¿ìÀֺͰ²Ïê Happy & Healthy Always ! ^_^ ! ¸öÈËÍøÒ³ Homepage:http://planet.time.net.my/sunwaycity/ceyong ¸öÈË·ğѧÍøÒ³ Buddhist Page: http://planet.time.net.my/SunwayCity/ceyong/artikel.htm ICQ:16994867/ Yahoo Messenger ID:ceyong /MSN Messenger:ceyong at hotmail.com _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 11:33:27 2004 Return-Path: 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 C52D916A4CE for ; Tue, 19 Oct 2004 11:33:27 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1F0B43D5C for ; Tue, 19 Oct 2004 11:33:26 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 57685 invoked from network); 19 Oct 2004 11:32:26 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Oct 2004 11:32:26 -0000 Message-ID: <4174FB8C.F63D278A@freebsd.org> Date: Tue, 19 Oct 2004 13:33:32 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Ronald F. Guilmette" References: <67378.1098167428@monkeys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.ORG cc: Garrett Wollman Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 11:33:27 -0000 "Ronald F. Guilmette" wrote: > > In message <200410182138.i9ILcvmG095282@khavrinen.lcs.mit.edu>, you wrote: > > >< said: > > > >> I'm sitting here looking at that man pages for aio_read and aio_write, > >> and the question occurs to me: ``Home come there is no such thing as > >> an aio_connect function?'' > > > >Mostly because there is no need, since connect() doesn't transfer any > >data; it just establishes a connection. If the socket is put in > >non-blocking mode, connect() will take place in the background. > > That is a very interesting point, and one which I am now pondering. > > I myself _have_ in fact done what you are talking about before, i.e. > starting up a non-blocking connect and then coming back later on with, > say, either select() or poll() to see if it has finished. So I _do_ > know how to do what you are describing. But thinking about it now, > I'd just like to say that it seems to me that that approach may have > some significantly different semantics than the hypothetical aio_connect() > function that I had suggested. (But then again, maybe not. I'll have > to give it some more thought.) > > Anyway, upon further reflection (and further RTFM'ing) I am now inclined > towards a distinct dislike for the entire aio_*() family of functions > because, as I just now realized, they provide the programmer with a > synchronous way (i.e. the aio_error function) of checking for inherently > _asynchronous_ events, i.e. I/O completions. All things considered, I > think that I personally would prefer to receive such notifications (of > asynchronous I/O completions) via interrupts... er... I mean via signals. > > (I suppose that there is some way of doing that, but I confess that I per- > sonally have never come across it, so if anybody wants to educate me, then > by all means please do so.) man kqueue. And have a look at libevent by Niels Provos. Saves the day. > P.S. And before anybody lambasts me about the head and neck for even > suggesting the use of signals to indicate I/O completions, allow me to > just say that yes, I _do_ undertstand that this would be quite costly, > but for some applications, the cost would be acceptable. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 13:56:14 2004 Return-Path: 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 B5B0216A4CE; Tue, 19 Oct 2004 13:56:14 +0000 (GMT) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 349C143D1F; Tue, 19 Oct 2004 13:56:14 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 360822C3D0; Tue, 19 Oct 2004 15:56:13 +0200 (CEST) Date: Tue, 19 Oct 2004 15:56:13 +0200 From: Thomas Quinot To: freebsd-net@freebsd.org Message-ID: <20041019135612.GA27971@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.6i cc: wpaul@freebsd.org Subject: yppush going into an endless loop X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 13:56:14 -0000 On a 5.2.1-REL NIS server where NIS maps are updated every hour from a crontab, I often see yppush going into an endless loop: 0x281220dc in __vfprintf () from /lib/libc.so.5 (gdb) bt #0 0x281220dc in __vfprintf () from /lib/libc.so.5 #1 0x28121b3f in strchr () from /lib/libc.so.5 #2 0x28122173 in __vfprintf () from /lib/libc.so.5 #3 0x281220a6 in vfprintf () from /lib/libc.so.5 #4 0x2810ed6d in fprintf () from /lib/libc.so.5 #5 0x08049bf2 in __verr ( fmt=0x804c2c0 "warning: exiting with transfer to %s (transid = %lu) still pending", ap=0x2813d120 "\\`\f") at /usr/src/RELENG_5_2/usr.sbin/ypserv/yp_error.c:58 #6 0x08049c58 in yp_error (fmt=0xbbc004d0 "Ğ") at /usr/src/RELENG_5_2/usr.sbin/ypserv/yp_error.c:71 #7 0x0804a39f in yppush_exit (now=672387024) at /usr/src/RELENG_5_2/usr.sbin/yppush/yppush_main.c:195 #8 0x0804a406 in handler (sig=6) at /usr/src/RELENG_5_2/usr.sbin/yppush/yppush_main.c:213 #9 #10 0x280c1dcf in kill () from /lib/libc.so.5 #11 0x2812ef82 in abort () from /lib/libc.so.5 #12 0x2812d6fe in tcflow () from /lib/libc.so.5 #13 0x2812d72b in tcflow () from /lib/libc.so.5 #14 0x2812e459 in free () from /lib/libc.so.5 #15 0x281090e3 in _nsdbtput () from /lib/libc.so.5 #16 0x2810909b in _nsdbtput () from /lib/libc.so.5 ---Type to continue, or q to quit--- #17 0x28108c98 in endhostent () from /lib/libc.so.5 #18 0x2810944f in _nsdbtput () from /lib/libc.so.5 #19 0x2812f384 in exit () from /lib/libc.so.5 #20 0x0804a3c6 in yppush_exit () at /usr/src/RELENG_5_2/usr.sbin/yppush/yppush_main.c:201 #21 0x0804a406 in handler (sig=6) at /usr/src/RELENG_5_2/usr.sbin/yppush/yppush_main.c:213 #22 #23 0x280c1dcf in kill () from /lib/libc.so.5 Script done on Tue Oct 19 15:19:12 2004 Two questions: 1. has anyone already observed similar behaviour; 2. from code-reading, it looks like we attempt to prevent yppush_exit from wrecking havoc when we call it from a signal handler by zeroing out yppush_jobs. Shouldn't that be yppush_joblist? As far as 2 is concerned, the following change should work around the problem (but then I'd still have to find out why yppush is exiting on a signal in the first place). Index: yppush_main.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/yppush/yppush_main.c,v retrieving revision 1.18 diff -u -r1.18 yppush_main.c --- yppush_main.c 3 May 2003 21:06:41 -0000 1.18 +++ yppush_main.c 19 Oct 2004 13:37:22 -0000 @@ -209,7 +209,7 @@ handler(int sig) { if (sig == SIGTERM || sig == SIGINT || sig == SIGABRT) { - yppush_jobs = 0; + yppush_joblist = NULL; yppush_exit(1); } -- Thomas.Quinot@Cuivre.FR.EU.ORG From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 15:00:50 2004 Return-Path: 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 1FE5C16A4CF for ; Tue, 19 Oct 2004 15:00:50 +0000 (GMT) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85E4943D48 for ; Tue, 19 Oct 2004 15:00:49 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: by blah.sun-fish.com (Postfix, from userid 599) id B72C134196; Tue, 19 Oct 2004 17:00:47 +0200 (CEST) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id ABA2A34176 for ; Tue, 19 Oct 2004 17:00:47 +0200 (CEST) Received: by sun-fish.com (Postfix, from userid 1008) id 6D5D1D4C899; Tue, 19 Oct 2004 17:00:47 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id 8A89AD4C887 for ; Tue, 19 Oct 2004 17:00:42 +0200 (CEST) Date: Tue, 19 Oct 2004 18:00:42 +0300 From: Vladimir Terziev To: freebsd-net@freebsd.org Message-Id: <20041019180042.553c1af0@daemon.cmotd.com> Organization: SunFish Ltd. X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-unknown-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Quagga & ripd difficulty X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 15:00:50 -0000 Hi All, i try to set up quagga to route my VPNs. I use RIP (served by quagga's ripd) as routing protocol. All works fine, but i have difficulties with equal-cost routes. Now the problem ... One of my VPN peer servers has two VPN connections to every one of the other VPN peers. For quagga these are 2 equal-cost routes. When both of the VPN connections are established, quagga randomly preffers one of them and routes all VPN traffic via it. When one of the connections is not present (not connected) the VPN traffic is routed via the connected one. All this is fine, but i have the desire one of the routes to be prefferable when both of them are present. I mean the following ... if i have Net-1 <-> VPN-Peer-1 <----- A -----> VPN-Peer-2 <-> Net-2 Net-1 <-> VPN-Peer-1 <----- B -----> VPN-Peer-2 <-> Net-2 quagga to create a route between Net-1 and Net-2 always via connection A if both of the connections are present. Any ideas are welcome! Thanks in advance! Vladimir From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 16:31:37 2004 Return-Path: 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 B2B2C16A4CE for ; Tue, 19 Oct 2004 16:31:37 +0000 (GMT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ACB943D1D for ; Tue, 19 Oct 2004 16:31:32 +0000 (GMT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.11/8.12.11) with ESMTP id i9JGVTBm001269; Wed, 20 Oct 2004 00:31:29 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i9JGVSek001268; Wed, 20 Oct 2004 00:31:28 +0800 (KRAST) (envelope-from eugen) Date: Wed, 20 Oct 2004 00:31:28 +0800 From: Eugene Grosbein To: Vladimir Terziev Message-ID: <20041019163128.GA1201@grosbein.pp.ru> References: <20041019180042.553c1af0@daemon.cmotd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041019180042.553c1af0@daemon.cmotd.com> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: Quagga & ripd difficulty X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 16:31:37 -0000 > One of my VPN peer servers has two VPN connections to every one of the other VPN peers. For quagga these are 2 equal-cost routes. When both of the VPN connections are established, quagga randomly preffers one of them and routes all VPN traffic via it. When one of the connections is not present (not connected) the VPN traffic is routed via the connected one. All this is fine, but i have the desire one of the routes to be prefferable when both of them are present. I mean the following ... if i have > > Net-1 <-> VPN-Peer-1 <----- A -----> VPN-Peer-2 <-> Net-2 > Net-1 <-> VPN-Peer-1 <----- B -----> VPN-Peer-2 <-> Net-2 > > quagga to create a route between Net-1 and Net-2 always via connection A if both of the connections are present. > Any ideas are welcome! For RIP, there is a metric manipulation technique: router can artifically increase metrics of some of received routes when these routes come from a distinct neighbour or via distinct inteface. For RIP there is offset-list command but it is not implemented yet AFAIK. Eugene From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 18:21:34 2004 Return-Path: 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 9241716A4CE for ; Tue, 19 Oct 2004 18:21:34 +0000 (GMT) Received: from istanbul.enderunix.org (freefall.marmara.edu.tr [193.140.143.23]) by mx1.FreeBSD.org (Postfix) with SMTP id 3B89C43D62 for ; Tue, 19 Oct 2004 18:21:31 +0000 (GMT) (envelope-from ofsen@enderunix.org) Received: (qmail 47258 invoked by uid 89); 19 Oct 2004 18:21:50 -0000 Message-ID: <20041019182150.47247.qmail@istanbul.enderunix.org> From: Omer Faruk Sen To: freebsd-net@freebsd.org Date: Tue, 19 Oct 2004 21:21:49 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-9" Content-Transfer-Encoding: 7bit Subject: ipfw bw limiting question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 18:21:34 -0000 Hi, I am having troubles with understanding ipfw mask option (which related with bw limiting). For example I want to limit traffic on port 80 from my server to any IP adress. But all of the connecting IPs should have the same bw which is configured via mask src-ip am I right? For example: ipfw add pipe 1 tcp from x.x.x.x./32 80 to any out xmit em0 ipfw pipe 1 config bw 100Kbits/s mask src-ip 0xffffffff These commands are supposed to do that: x.x.x.x:80 ---> IP1:xxx (100Kbits/s bw limit) x.x.x.x:80 ---> IP2:xxx (100 kbits/s bw limit) What I didn't understand is why I am stating src-ip 0xfffffff as the mask. I mean in my bw limiting rules destionation ips (IP1, IP2 ...) should be the one that create dynamic pipes whose bw is 100kbits/s for each pipe. But I give src-ip 0xfffffff. Shouldn't the right way for that is to use dst-ip 0xffffff here? I have searched internet and as far as I read I am wrong. I am missing some point here. Can anyone help me? ----------------------- Omer Faruk Sen http://www.EnderUNIX.ORG Software Development Team @ Turkey http://www.Faruk.NET For Public key: http://www.enderunix.org/ofsen/ofsen.asc ******************************************************** First Turkish FreeBSD book is out! Go check it. Duydunuz mu! Turkiye'nin ilk FreeBSD kitabi cikti. http://www.acikkod.com/freebsd.php From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 19:26:13 2004 Return-Path: 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 13F1616A4CE; Tue, 19 Oct 2004 19:26:13 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8603143D5A; Tue, 19 Oct 2004 19:26:12 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id 0D81C54AA; Tue, 19 Oct 2004 12:26:12 -0700 (PDT) To: Andre Oppermann In-reply-to: Your message of Tue, 19 Oct 2004 13:33:32 +0200. <4174FB8C.F63D278A@freebsd.org> Date: Tue, 19 Oct 2004 12:26:12 -0700 Message-ID: <72574.1098213972@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@FreeBSD.ORG cc: Garrett Wollman Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 19:26:13 -0000 In message <4174FB8C.F63D278A@freebsd.org>, you wrote: >> Anyway, upon further reflection (and further RTFM'ing) I am now inclined >> towards a distinct dislike for the entire aio_*() family of functions >> because, as I just now realized, they provide the programmer with a >> synchronous way (i.e. the aio_error function) of checking for inherently >> _asynchronous_ events, i.e. I/O completions. All things considered, I >> think that I personally would prefer to receive such notifications (of >> asynchronous I/O completions) via interrupts... er... I mean via signals. >> >> (I suppose that there is some way of doing that, but I confess that I per- >> sonally have never come across it, so if anybody wants to educate me, then >> by all means please do so.) > >man kqueue. I am familiar with kqueue, and I wrote an early example program to illustrate its use: http://www.monkeys.com/freeware/kqueue-echo.c But that facility (kqueue/kevent) does not provide the kind of asynchronous I/O completion interrupts that I was asking about. Rather, it is just a different (and significantly more efficient) way of doing essentially the same things as you can do with either select() or poll(). >And have a look at libevent by Niels Provos. Saves the day. Hummm... I did a google search on that and started to read this page: http://www.monkey.org/~provos/libevent/ (As a monkey myself, I supposed that I should have already known about this, but I didn't. :-) Anyway, reading that page was rather enlightening, and it gave me some other clues that I tracked down. Those caused me to realize that the aio_*() family of functions is _not_ hopeless after all, and that they _can_ trigger exactly the kinds of asynchronous I/O completion signals that I was asking for... although that fact is very poorly (un-)documented in the relevant FreeBSD man pages (on 4.10-RELEASE) for the aio_*() functions. (Those man pages need a LOT of work.) Anyway, as I have just learned, the async I/O control blocks used by, for example, aio_read() and aio_write() contain a field named `aio_sigevent' that allows the user to request, in advance, that some specific signal be delivered when the requested I/O operation completes. This is _exactly_ the kind of thing that I earlier said would be a Good Thing To Have. So anyway, I am pleased to see that, after all, it _is_ possible to pro- gramatically ask to be interrupted (via a signal) when a given async I/O operation completes. That's the good news. The bad news is that... just as I noted in the posting that began this thread... there is no such thing, at present, as an aio_connect() function. :-( Bummer! Anyway, I'd like to now repeat the ``request for enhancement'' that I put forward in the posting I made that started this thread. The reasons why the functionality of such a (hypothetical) new function would _not_ be redundant with the functionality provided by other kernel calls (e.g. connect() on a NOWAIT descriptor, followed by select()/poll()) are now quite clear and evident. A call to connect() followed by a call to select() or poll() to detect completion of the asynchronous connect() is a funda- mentally _synchronous_ (manual polling) approach to the problem of detecting the completion of an asynchronous connect() attempt. But if there existed an aio_connect() function, then via the `aio_sigevent' field of the async I/O control block (struct aiocb) passed to such a function the caller could request _asynchronous_ notification (via a signal) of the subsequent completion of the asynchronous aio_connect() call. (And let me say that I dearly wish that I had _exactly_ this functionality RIGHT NOW. It would help a lot for one project I am working on.) In short, many of the reasons for having an aio_read() function are, in my opinion, equally applicable to a (hypothetical) aio_connect() function. In an ideal Universe... or even in just an ideal kernel... both should exist, as they both would/could provide an asynchronous (signal-based) notifications of completion events... a kind of functionality that clearly cannot be duplicated with any other existing kernel calls, or even with any combinations thereof. Unless someone comes up with a compelling counter-argument, I will shortly be submitting a ``request for enhancement'' PR that asks specifically for the addition of a new aio_connect() kernel call. From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 19:41:39 2004 Return-Path: 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 E594016A4CE for ; Tue, 19 Oct 2004 19:41:39 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7487143D39 for ; Tue, 19 Oct 2004 19:41:39 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CJzrW-00005N-00; Tue, 19 Oct 2004 21:41:38 +0200 Received: from [217.227.158.113] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CJzrW-00042U-00; Tue, 19 Oct 2004 21:41:38 +0200 From: Max Laier To: freebsd-net@freebsd.org, freebsd-net@astral-on.net Date: Tue, 19 Oct 2004 21:41:04 +0200 User-Agent: KMail/1.7 References: <20041019072926.GB6079@astral-on.net> In-Reply-To: <20041019072926.GB6079@astral-on.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1106660.qCL3ng3Zf7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410192141.13468.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: ALTQ CDNR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 19:41:40 -0000 --nextPart1106660.qCL3ng3Zf7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 19 October 2004 09:29, Andrew Degtiariov wrote: > Hello people! > Whether works or not ALTQ CDNR in FreeBSD 5.3? The "options ALTQ_CDNR" is a dummy at the moment. It introduces a function= =20 pointer in ip_input() that can be used as conditioner hook, but it is not=20 used at the moment. There are plans to resurrect the conditioner, but it is= =20 not yet clear how and where. It might be a function of pf in the future. To answer the question. No, the conditioner will not work in FreeBSD 5.3 =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1106660.qCL3ng3Zf7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBdW3ZXyyEoT62BG0RAq5oAJ4nGmyLbiB7r0gsN6ZgvGZ2Mo5FFwCdFVjd uODfL3SPZGw85SHbItBS7YE= =rjXD -----END PGP SIGNATURE----- --nextPart1106660.qCL3ng3Zf7-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 20:56:15 2004 Return-Path: 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 A9C8016A4CE for ; Tue, 19 Oct 2004 20:56:15 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D96E743D49 for ; Tue, 19 Oct 2004 20:56:14 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 61790 invoked from network); 19 Oct 2004 20:55:10 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Oct 2004 20:55:10 -0000 Message-ID: <41757F72.A36AD263@freebsd.org> Date: Tue, 19 Oct 2004 22:56:18 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Ronald F. Guilmette" References: <72574.1098213972@monkeys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.ORG cc: gurney_j@resnet.uoregon.edu cc: Garrett Wollman Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 20:56:15 -0000 "Ronald F. Guilmette" wrote: > > In message <4174FB8C.F63D278A@freebsd.org>, you wrote: > > >> Anyway, upon further reflection (and further RTFM'ing) I am now inclined > >> towards a distinct dislike for the entire aio_*() family of functions > >> because, as I just now realized, they provide the programmer with a > >> synchronous way (i.e. the aio_error function) of checking for inherently > >> _asynchronous_ events, i.e. I/O completions. All things considered, I > >> think that I personally would prefer to receive such notifications (of > >> asynchronous I/O completions) via interrupts... er... I mean via signals. > >> > >> (I suppose that there is some way of doing that, but I confess that I per- > >> sonally have never come across it, so if anybody wants to educate me, then > >> by all means please do so.) > > > >man kqueue. > > I am familiar with kqueue, and I wrote an early example program to illustrate > its use: > > http://www.monkeys.com/freeware/kqueue-echo.c > > But that facility (kqueue/kevent) does not provide the kind of asynchronous > I/O completion interrupts that I was asking about. Rather, it is just a > different (and significantly more efficient) way of doing essentially the > same things as you can do with either select() or poll(). What other events than aio_connect() you are interested in? > >And have a look at libevent by Niels Provos. Saves the day. > > Hummm... I did a google search on that and started to read this page: > > http://www.monkey.org/~provos/libevent/ > > (As a monkey myself, I supposed that I should have already known about this, > but I didn't. :-) > > Anyway, reading that page was rather enlightening, and it gave me some other > clues that I tracked down. Those caused me to realize that the aio_*() > family of functions is _not_ hopeless after all, and that they _can_ trigger > exactly the kinds of asynchronous I/O completion signals that I was asking > for... although that fact is very poorly (un-)documented in the relevant > FreeBSD man pages (on 4.10-RELEASE) for the aio_*() functions. (Those man > pages need a LOT of work.) Feel free to submit updates for the man pages. AFAIK there are certain problems with AIO in FreeBSD and you not only the man pages need some work but the implementation too. > Anyway, as I have just learned, the async I/O control blocks used by, for > example, aio_read() and aio_write() contain a field named `aio_sigevent' > that allows the user to request, in advance, that some specific signal be > delivered when the requested I/O operation completes. This is _exactly_ > the kind of thing that I earlier said would be a Good Thing To Have. I still don't understand what exactly you are trying to achieve (The Big PictureTM). > So anyway, I am pleased to see that, after all, it _is_ possible to pro- > gramatically ask to be interrupted (via a signal) when a given async I/O > operation completes. That's the good news. The bad news is that... just > as I noted in the posting that began this thread... there is no such thing, > at present, as an aio_connect() function. :-( Bummer! Ah, you want to be interrupt driven instead of being poll-event driven as with poll/select and kqueue? What about extending kqueue with a async signaling mechanism? Would that make your stuff work? I think doing this would be easier and more powerful than fixing all the aio stuff. The kqueue will queue all events and then signal them via SIGwhatever so you can do one poll on the kqueue and dequeue all pending events. Plus you can schedule all new works which then will be reported to you via the same mechanism again. I've added Jean-Mark Gurney to the CC list. He has done some more involved work on kqueue recently. He probably has the best overview if/how to make this work with kqueue. > Anyway, I'd like to now repeat the ``request for enhancement'' that I put > forward in the posting I made that started this thread. The reasons why > the functionality of such a (hypothetical) new function would _not_ be > redundant with the functionality provided by other kernel calls (e.g. > connect() on a NOWAIT descriptor, followed by select()/poll()) are now > quite clear and evident. A call to connect() followed by a call to select() > or poll() to detect completion of the asynchronous connect() is a funda- > mentally _synchronous_ (manual polling) approach to the problem of detecting > the completion of an asynchronous connect() attempt. But if there existed > an aio_connect() function, then via the `aio_sigevent' field of the > async I/O control block (struct aiocb) passed to such a function the > caller could request _asynchronous_ notification (via a signal) of the > subsequent completion of the asynchronous aio_connect() call. (And let > me say that I dearly wish that I had _exactly_ this functionality RIGHT > NOW. It would help a lot for one project I am working on.) > > In short, many of the reasons for having an aio_read() function are, in > my opinion, equally applicable to a (hypothetical) aio_connect() function. > In an ideal Universe... or even in just an ideal kernel... both should > exist, as they both would/could provide an asynchronous (signal-based) > notifications of completion events... a kind of functionality that clearly > cannot be duplicated with any other existing kernel calls, or even with > any combinations thereof. > > Unless someone comes up with a compelling counter-argument, I will shortly > be submitting a ``request for enhancement'' PR that asks specifically for > the addition of a new aio_connect() kernel call. You can submit as many requests for enhancements as you whish as long as you attach the patch to implement it. Otherwise they will sit in GNATS for a long time. AIO has been very much neglected and there is no active maintainer for it. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 23:21:27 2004 Return-Path: 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 83DDA16A4CE; Tue, 19 Oct 2004 23:21:27 +0000 (GMT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B5F343D39; Tue, 19 Oct 2004 23:21:27 +0000 (GMT) (envelope-from tony.ackerman@intel.com) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9JNPFQt026722; Tue, 19 Oct 2004 23:25:15 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9JNOnF7013350; Tue, 19 Oct 2004 23:25:01 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) M2004101916212509941 ; Tue, 19 Oct 2004 16:21:25 -0700 Received: from orsmsx403.amr.corp.intel.com ([192.168.65.209]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 16:21:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Oct 2004 16:21:23 -0700 Message-ID: <2726872B7A674F489DDEFB72CE1F670D016EFB22@orsmsx403.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] Make em(4) use device sysctl tree Thread-Index: AcSzBWYeIJvt38IvSR6QTw8NnP+c5gDLHzEA From: "Ackerman, Tony" To: "Bruce M Simpson" , X-OriginalArrivalTime: 19 Oct 2004 23:21:25.0055 (UTC) FILETIME=[5A2A2CF0:01C4B632] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) cc: freebsdnic@mailbox.cps.intel.com cc: mux@FreeBSD.org cc: tackerman@FreeBSD.org Subject: RE: [PATCH] Make em(4) use device sysctl tree X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 23:21:27 -0000 Bruce, Aren't the calls to sysctl_ctx_free() still required? Tony =20 -----Original Message----- From: Bruce M Simpson [mailto:bms@spc.org]=20 Sent: Friday, October 15, 2004 3:21 PM To: freebsd-net@FreeBSD.org Cc: tackerman@FreeBSD.org; freebsdnic@mailbox.cps.intel.com; mux@FreeBSD.org Subject: [PATCH] Make em(4) use device sysctl tree Here is a non-critical patch to bring em(4) into line with other drivers, by using the sysctl tree created for each device by the bus framework. Please review; Thanks. BMS From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 23:41:05 2004 Return-Path: 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 834C316A4CE for ; Tue, 19 Oct 2004 23:41:05 +0000 (GMT) Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA0EE43D53 for ; Tue, 19 Oct 2004 23:41:04 +0000 (GMT) (envelope-from ernie@spooky.eis.net.au) Received: (from ernie@localhost) by spooky.eis.net.au (8.12.11/8.12.11) id i9JNf3Ak040311 for freebsd-net@freebsd.org; Wed, 20 Oct 2004 09:41:03 +1000 (EST) (envelope-from ernie) From: User Ernie Message-Id: <200410192341.i9JNf3Ak040311@spooky.eis.net.au> To: freebsd-net@freebsd.org Date: Wed, 20 Oct 2004 09:41:03 +1000 (EST) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Whitelist for dnsbl recipients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 23:41:05 -0000 I am using the sendmail FEATURE(`dnsbl', on my mail gateway server which feeds several other mail server, to do lookups from an aggregated black list t1.dnsbl.net.au It works too well! Because t1.dnsbl.net.au a comprehensive, aggregated black list, a lot of mail from poorly configured senders gets rejected. Every now and then I have a request from a user to turn of the black list feature for their mail box. I thought I could do it with a rule in the /etc/mail/access file, using a syntax like: To:user@some.domain.name.com OK That didn't seem to work, I still got lots of reject messages in the mail log. Can anyone suggest a way of solving the problem? I have no problem white listing source addresses, but there are too many source addresses to solve this problem, it really needs to be an exempted recipient address. - Ernie. From owner-freebsd-net@FreeBSD.ORG Tue Oct 19 23:50:06 2004 Return-Path: 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 369E116A4CE; Tue, 19 Oct 2004 23:50:06 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19D3243D2F; Tue, 19 Oct 2004 23:50:06 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 103B35C848; Tue, 19 Oct 2004 16:50:06 -0700 (PDT) Date: Wed, 20 Oct 2004 01:50:06 +0200 From: Maxime Henrion To: "Ackerman, Tony" Message-ID: <20041019235005.GB41649@elvis.mu.org> References: <2726872B7A674F489DDEFB72CE1F670D016EFB22@orsmsx403.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2726872B7A674F489DDEFB72CE1F670D016EFB22@orsmsx403.amr.corp.intel.com> User-Agent: Mutt/1.4.2.1i cc: freebsdnic@mailbox.cps.intel.com cc: tackerman@FreeBSD.org cc: freebsd-net@FreeBSD.org Subject: Re: [PATCH] Make em(4) use device sysctl tree X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 23:50:06 -0000 Ackerman, Tony wrote: > Bruce, > Aren't the calls to sysctl_ctx_free() still required? They aren't required because the sysctl tree and the sysctl context are both created by the newbus framework, and also destroyed by the said framework if a device detaches. However, your comment made me notice that Bruce forgot to remove the sysctl_ctx and sysctl_tree fields of the softc in his patch. :-) Cheers, Maxime > -----Original Message----- > From: Bruce M Simpson [mailto:bms@spc.org] > Sent: Friday, October 15, 2004 3:21 PM > To: freebsd-net@FreeBSD.org > Cc: tackerman@FreeBSD.org; freebsdnic@mailbox.cps.intel.com; > mux@FreeBSD.org > Subject: [PATCH] Make em(4) use device sysctl tree > > Here is a non-critical patch to bring em(4) into line with other > drivers, by using the sysctl tree created for each device by the > bus framework. > > Please review; Thanks. > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 00:19:05 2004 Return-Path: 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 3146016A4CE; Wed, 20 Oct 2004 00:19:05 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 900F143D58; Wed, 20 Oct 2004 00:19:04 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id B491E54A7; Tue, 19 Oct 2004 17:19:03 -0700 (PDT) To: Andre Oppermann In-reply-to: Your message of Tue, 19 Oct 2004 22:56:18 +0200. <41757F72.A36AD263@freebsd.org> Date: Tue, 19 Oct 2004 17:19:03 -0700 Message-ID: <74506.1098231543@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@FreeBSD.ORG cc: gurney_j@resnet.uoregon.edu cc: Garrett Wollman Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 00:19:05 -0000 In message <41757F72.A36AD263@freebsd.org>, you wrote: >What other events than aio_connect() you are interested in? Well, I'm glad that you asked, because after my last message in this thread I realized that (just for the sake of symmetry, if for no other reason) it would also be swell to have a kernel function called aio_accept(). That's it for now... just aio_connect() and aio_accept(). If I think of something else, I'll let you know. >Feel free to submit updates for the man pages. I shall, as time permits. Thanks. >AFAIK there are certain problems with AIO in FreeBSD Could you be a little bit more specific please? I'd like to know about any such problems. >I still don't understand what exactly you are trying to achieve (The Big >PictureTM). I would just like to be able to write network clients and/or network servers using the kind of radically different programming style that the aio_* functions (with their signal-generating asynchronous interrupt capability) would seem to permit one to use. Basically, I have a mental model of how asynchronous events (in particular, various kinds of I/O completion events) really _should_ be handled. And the mental model I have has nothing at all to do with any kind of synchronous polling (which I view as inherently ugly and typically inefficient, both from the point of view of machine cycles, and also, perhaps more importantly, from the point of view of code clarity and straightforwardness, or lack thereof). Note that select(), poll(), and even kqueue()/kevent() are really all just different ways of doing _polling_ for a set of events. The kqueue/kevent stuff is definitely more efficient and more flexible than either select() or poll(), but at base, it is still just a different interface to a kernel- implemented polling mechanism. And as I have said, I simply do not like polling. Never have, and never will. (I could perhaps illustrate the basis for my fear and loathing of polling, in general, by relating a story from my own ancient past. Long long ago, in a valley not far away, I worked as a compiler software engineer for one of the many goofy little SillyCone Valley companies that, back 20 years ago or more, made money by selling their own special proprietary-design computers with CPUs constructed out of entire circuit boards, larger than your head. I don't even remember the name of the company anymore... I'm sure that they have long since gone out of business... but anyway, shortly after I started work there, the lead developer explained one of the fundamental aspects of the compiler for the one and only higher-level langauge... Enhanced BASIC... that was supported on the company's proprietary hardware. In a nutshell, whoever had designed the company's CPU boards had apparently tried... and failed... to actually implement hardware interrupts on/for the company's proprietary CPU. The dolt just couldn't get hardware interrupts to work. DUH! But the company _had_ to ship _something_ so they shipped what they had, which was systems with CPUs that simply could not field interrupts, e.g. for I/O device completions. The result was the most incredible kludge I have even heard about, either before or since. Unbelievable as it may sound today, the burden imposed by the lack of functioning hardware inter- rupts was foisted off onto the software. The BASIC compiler was implemented in such a way that in generated a call to an I/O completion polling routine just prior to each and every backwards jump in the code, e.g. at the ends of loops, etc. Thus, as long as the customer(s) never programmed in anything other than the company-approved BASIC langauage... using the company's own proprietary BASIC compiler... all was well, and the system(s) mostly functioned acceptably well, albeit as a rather remarkably low level of performance, relative to what they could have done, if they had only had working hardware interrupts, rather than this idiotic compiler-dependent polling kludge. And of course, the machines would often and frequently lock up, for no obvious or apparent reason, and would thence have to be power-cycled in order to get them back online... a fact which I personally assumed was due to the fact that large amounts of support code... libraries, kernel, etc... had been implemented by the company itself in _assembly_, rather than in BASIC, implying that these hunks of code were probably littered with lots of backwards jumps, i.e. loops, in which no manual polling for I/O com- pletions occured. Anyway, I count my brief stint at this particular com- pany as one of high points of my early practical education in the field of software. It certainly taught me the clear advantages of being interrupted when something happens, as opposed to always having to check, over and over again, to see if something has happened.) Getting back to the topic at hand, as I have said, I think that the aio_* functions, together with their signal-generating capabilities, could support a rather dramatically different style of programming (e.g. for clients and servers) when compared to the polling primitives select(), poll(), and kevent(). Instead of starting up a whole bunch of (otherwise unrelated) I/O operations and then having to come back to a central ``event loop'' to constantly check to see which ones of them have completed, aio_*() operations (with signals for completions) could allow more of a ``set it and forget it'' sytle of programming where we just start each operation and then go off to do other things, knowing that we will get asynchronously forced into some signal handling function when/if there is an I/O completion. That signal handler could then perhaps start up the next operation that needed to be done, e.g. for that specific socket or file handle, and then just return. Meanwhile, the ``mainline'' code that we were executing before the signal arrived would be picked up right where it left off, and that code would be none the wiser than anything at all had ever even happened. I personally like this more ``distributed'' (code-wise) model of handling I/O completions a lot more than the traditional select()/poll()/kevent() centralized ``event loop'' model wherein, for the purposes of polling, we have to effectively stick a whole bunch of otherwise totally unrelated and independent things (e.g. file handles) together into a single combined vector argument just for the sake of select()/poll()/kevent(). Also, I guess you could say that my personal tastes are influenced by my early career experiences, and one in particular that I have described above. Last but not least, it seems to me that quite a lot of the evolution of various *NIX kernels and standards over the past many years have been oriented towards providing more ``kernel like'' functionality in the userland level. Certainly, the aio_*() with their signaling capability are a fine example of this. Using aio_*() with completion signaling gives almost the same look and feel to userland programs as the kernel has when _it_ fields asynchronous I/O interrupts. And I like that. It just ``feels'' like a more natural programming style to me. >Ah, you want to be interrupt driven instead of being poll-event driven as >with poll/select and kqueue? Yes. Please. >What about extending kqueue with a async signaling mechanism? What about it? I'm sorry, but to be frank I have to say that that just sounds like a kludge to me. As I have said, select()/poll()/kevent() are all just different ways of doing polling. Any one of them could be hacked to make it generate signals instead, but why bother when there is already a standardized and well-defined (and mostly implemented) non-polling approach to detecting I/O completions, i.e. aio*() with signals. (The expression that comes immediately to mind is ``Putting lipstick on a pig.'' Certainly, select() or poll() or kevent() could be enhanced with ``interrupt'' capabilities, but they were all designed and intended to provide non-interrupt ``polling'' functionality. So why change them? I mean it's kinda like asking a qualified electrician to fix your broken plumbing. Yea, _maybe_ he could do it, but why not just hire a plumber instead?) >Would that make your stuff work? I think doing this >would be easier and more powerful than fixing all the aio stuff. I ask again, What's wrong with the aio*() stuff? Are you saying that you stylistically don't like the programming model they give you, or are you referring again to broken bits in the FreeBSD implementation? >The kqueue >will queue all events and then signal them via SIGwhatever so you can do >one poll on the kqueue and dequeue all pending events. It will do that?? I didn't know that. Anyway, I would still like to be able to attach _different_ signal handler functions to each different event completion that I am waiting for. It seems to me that the aio_*() functions would support this, whereas as I have noted above, kevent() makes to mash everything that you are waiting for together, even if they are otherwise unrelated. (It would be kinda nice, I think, to be able, for example, to put all of the code for handling one kind of socket connection into one single source file, and then put 100% of the code for dealing with some different kinds of socket into its onw provate source file also. It seems to me that if I had a complete (and fully working) familiy of aio_*() functions, then I could do this exact sort of thing, whereas with select()/poll()/kevent(), you also have to push or ``leak'' some knowledge of _all_ sockts/events throughout the entire program back into your centralized non-distributed single central event loop. >I've added Jean-Mark Gurney to the CC list. He has done some more involved >work on kqueue recently. He probably has the best overview if/how to make >this work with kqueue. That's fine, but see above with regards to my opinion of the wisdom of even attempting that. Lest anybody misundertstand me. allow me to say that kqueue()/kevent() stuff is _very_ impressive, and when I first learned about it I was in rapture over it for some time. This is great stuff, and certainly is a dramatic step forward with regards to _efficient_ kernel support for handling large numbers of events/sockets. But efficiency for my machines is not equivalent to efficiency for me, and the two are sometimes in conflict. As a software engineer, I may often prefer a programming style that will allow my code to be more modular, even if that makes it rather less efficient. >You can submit as many requests for enhancements as you whish as long as >you attach the patch to implement it. :-) Yes, the GNU ethic... you can have whatever you want, as long as YOU implement it. :-) I am well and truly familiar with that. It kinda reminds of what Colin Powell said to President Bush about Iraq... ``You break it, you own it.'' >Otherwise they will sit in GNATS >for a long time. AIO has been very much neglected and there is no active >maintainer for it. Sadness. :-( From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 01:21:50 2004 Return-Path: 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 416E716A4CE for ; Wed, 20 Oct 2004 01:21:50 +0000 (GMT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 138E043D2D for ; Wed, 20 Oct 2004 01:21:48 +0000 (GMT) (envelope-from jinmei@isl.rdc.toshiba.co.jp) Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id DFE9A1535E; Wed, 20 Oct 2004 10:21:44 +0900 (JST) Date: Wed, 20 Oct 2004 10:21:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: snap-users@kame.net In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: MUT of stf (Re: (KAME-snap 8815) Re: Weird memory exhaustion with FreeBSD 4.10-STABLE) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 01:21:50 -0000 Forgot to respond to this point: >>>>> On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), >>>>> Pekka Savola said: > Speaking of 6to4, if_stf.c does not support setting the MTU, because > there's no ioctl handler for it. It wouldn't IMHO hurt to be able to > raise it from the glued-in default of 1280.. According to itojun (the principal author of the stf driver), it's on purpose. He said the reason for the restriction is because stf normally had multiple (anonymous) destinations and we couldn't pre-negotiate the size of the receiving buffer at the other ends. (No further questions on this to me, please:-) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 03:19:37 2004 Return-Path: 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 3116F16A4CE for ; Wed, 20 Oct 2004 03:19:37 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEB8E43D39 for ; Wed, 20 Oct 2004 03:19:36 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 2529 invoked from network); 20 Oct 2004 03:19:34 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Oct 2004 03:19:34 -0000 Received: from hydrogen.funkthat.com (abufwd@localhost.funkthat.com [127.0.0.1])i9K3JWlb081786; Tue, 19 Oct 2004 20:19:34 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i9K3JVFk081785; Tue, 19 Oct 2004 20:19:31 -0700 (PDT) Date: Tue, 19 Oct 2004 20:19:31 -0700 From: John-Mark Gurney To: "Ronald F. Guilmette" Message-ID: <20041020031931.GP22681@funkthat.com> References: <41757F72.A36AD263@freebsd.org> <74506.1098231543@monkeys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74506.1098231543@monkeys.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-net@freebsd.org cc: Andre Oppermann Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 03:19:37 -0000 Ronald F. Guilmette wrote this message on Tue, Oct 19, 2004 at 17:19 -0700: > I would just like to be able to write network clients and/or network servers > using the kind of radically different programming style that the aio_* > functions (with their signal-generating asynchronous interrupt capability) > would seem to permit one to use. > > Basically, I have a mental model of how asynchronous events (in particular, > various kinds of I/O completion events) really _should_ be handled. And > the mental model I have has nothing at all to do with any kind of synchronous > polling (which I view as inherently ugly and typically inefficient, both > from the point of view of machine cycles, and also, perhaps more importantly, > from the point of view of code clarity and straightforwardness, or lack > thereof). > > Note that select(), poll(), and even kqueue()/kevent() are really all just > different ways of doing _polling_ for a set of events. The kqueue/kevent > stuff is definitely more efficient and more flexible than either select() > or poll(), but at base, it is still just a different interface to a kernel- > implemented polling mechanism. And as I have said, I simply do not like > polling. Never have, and never will. Sorry, but there is nothing in FreeBSD that will let you program in the method you would like to do... I do agree with you that there are many improvements that can be made. Also, going aio_ as implemented in FreeBSD will be guaranteed to perform worse than kqueue/kevent.. This is because aio_ requires a kernel thread to wait for you instead of your process context.. Currently we are limited to only executing 4 aio_ events at once.. This can be increased, but will incure a stack for each additional thread you want to run... FreeBSD's kernel is inherently syncronous... This will prevent you from impelmenting what you want.. There is no way to have out standing io for multiple file descriptors... The reason kqueue/kevent works with sockets is that the sockets buffer data, making it work... if this wasn't the case, it'd be much less efficent.. To handle what you want to do, we would need to completely rearchitect the FreeBSD kernel to make more things asyncronous.. Some subsystems are getting better at this (like geom), but Unix has historicly been a syncronous system... So there is a lot of legacy code that will make this more difficult... Going async can improve things, and with it, makes implementing a sync interface easy on top of it... So the short of it is, no, FreeBSD at a low level does not support it... Now, I know this isn't what you want, but I usually make my kevent use appear as if it's async... I use the udata pointer point to a struct which starts with a function pointer... Then when I get events back from kevent, I just have code that loops over the events, and calls the associated function pointer.. simulating a signal... Now that kqueue has been locked, it shouldn't be too hard to use threads to create another thread and run the function in a thread, or using cv's or something similar to wake up other threads... To prevent multiple threads from executing, you can mark the events ONESHOT which means that they'll be removed once returned to kevent... It also means you could have multiple threads asking for events from the kqueue w/o getting duplicates... Hope this helps... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 04:42:04 2004 Return-Path: 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 D9FD616A4CE for ; Wed, 20 Oct 2004 04:42:04 +0000 (GMT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEF9E43D2F for ; Wed, 20 Oct 2004 04:42:03 +0000 (GMT) (envelope-from pekkas@netcore.fi) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9K4fkx02007; Wed, 20 Oct 2004 07:41:46 +0300 Date: Wed, 20 Oct 2004 07:41:46 +0300 (EEST) From: Pekka Savola To: snap-users@kame.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 cc: freebsd-net@freebsd.org Subject: Re: (KAME-snap 8847) MUT of stf (Re: Weird memory exhaustion with FreeBSD 4.10-STABLE) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 04:42:05 -0000 On Wed, 20 Oct 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > Forgot to respond to this point: > > >>>>> On Wed, 29 Sep 2004 10:59:32 +0300 (EEST), > >>>>> Pekka Savola said: > > > Speaking of 6to4, if_stf.c does not support setting the MTU, because > > there's no ioctl handler for it. It wouldn't IMHO hurt to be able to > > raise it from the glued-in default of 1280.. > > According to itojun (the principal author of the stf driver), it's on > purpose. He said the reason for the restriction is because stf > normally had multiple (anonymous) destinations and we couldn't > pre-negotiate the size of the receiving buffer at the other ends. I'm not sure if I see the argument. Are you assuming that some destinations might not have a 1500-byte receive buffer? That would seem to be .. a rather cautious assumption. I recall IPv6 specs already require being able to receive a packet of 1500 bytes.. (Due to this, e.g., draft-ietf-v6ops-mech-v2 now also requires at least 1500 byte reasm/receive buffer.) AFAIK, A bigger potential issue comes from how the implementation plays with PMTUD, e.g., does it set the DF-bit on the IPv4 header of the tunnelened packets or not. If it does, the code would need to reflect back v4 ICMP packet too big errors as ICMPv6 errors, and I believe KAME doesn't do that. I fully agree that setting MTU of the stf interface to a high value would be bad, but especially on relays, something higher than 1280 (e.g., 1480) would probably make a lot of sense. > (No further questions on this to me, please:-) Hey, we're on public mailing lists, so itojun can respond if he feels like it :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 13:40:12 2004 Return-Path: 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 BF3F016A4CE for ; Wed, 20 Oct 2004 13:40:12 +0000 (GMT) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC41A43D31 for ; Wed, 20 Oct 2004 13:40:09 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: by blah.sun-fish.com (Postfix, from userid 599) id D4FF434341; Wed, 20 Oct 2004 15:40:05 +0200 (CEST) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id C5F0F34330; Wed, 20 Oct 2004 15:40:05 +0200 (CEST) Received: by sun-fish.com (Postfix, from userid 1008) id BEC85D4C88D; Wed, 20 Oct 2004 15:40:04 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id 68B70D4C888; Wed, 20 Oct 2004 15:40:04 +0200 (CEST) Date: Wed, 20 Oct 2004 16:40:04 +0300 From: Vladimir Terziev To: Eugene Grosbein Message-Id: <20041020164004.6e0c3414@daemon.cmotd.com> In-Reply-To: <20041019163128.GA1201@grosbein.pp.ru> References: <20041019180042.553c1af0@daemon.cmotd.com> <20041019163128.GA1201@grosbein.pp.ru> Organization: SunFish Ltd. X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-unknown-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Quagga & ripd difficulty X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 13:40:12 -0000 In fact i can't even predict the name of the interface via which the traffic will be routed, because my VPN is based on VTUN servers. They choose the next free tun device, respectively interface, when the VPN connection is established beteen 2 peers. I read the Quagga documentation a lot of times, but i couldn't find any clue how to manipulated metrics when the traffic comes from distinct neighbour. Could you help me with this, please ? Vladimir On Wed, 20 Oct 2004 00:31:28 +0800 Eugene Grosbein wrote: > > One of my VPN peer servers has two VPN connections to every one of the other VPN peers. For quagga these are 2 equal-cost routes. When both of the VPN connections are established, quagga randomly preffers one of them and routes all VPN traffic via it. When one of the connections is not present (not connected) the VPN traffic is routed via the connected one. All this is fine, but i have the desire one of the routes to be prefferable when both of them are present. I mean the following ... if i have > > > > Net-1 <-> VPN-Peer-1 <----- A -----> VPN-Peer-2 <-> Net-2 > > Net-1 <-> VPN-Peer-1 <----- B -----> VPN-Peer-2 <-> Net-2 > > > > quagga to create a route between Net-1 and Net-2 always via connection A if both of the connections are present. > > Any ideas are welcome! > > For RIP, there is a metric manipulation technique: > router can artifically increase metrics of some of received routes > when these routes come from a distinct neighbour or via distinct inteface. > For RIP there is offset-list command but it is not implemented yet AFAIK. > > Eugene > From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 13:49:29 2004 Return-Path: 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 D8EEE16A4CE for ; Wed, 20 Oct 2004 13:49:29 +0000 (GMT) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id E54A243D66 for ; Wed, 20 Oct 2004 13:49:24 +0000 (GMT) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.11/8.12.11) with ESMTP id i9KDnMB3003092; Wed, 20 Oct 2004 21:49:22 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.11/8.12.11/Submit) id i9KDnMfV003091; Wed, 20 Oct 2004 21:49:22 +0800 (KRAST) (envelope-from eugen) Date: Wed, 20 Oct 2004 21:49:22 +0800 From: Eugene Grosbein To: Vladimir Terziev Message-ID: <20041020134922.GA1585@grosbein.pp.ru> References: <20041019180042.553c1af0@daemon.cmotd.com> <20041019163128.GA1201@grosbein.pp.ru> <20041020164004.6e0c3414@daemon.cmotd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041020164004.6e0c3414@daemon.cmotd.com> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org Subject: Re: Quagga & ripd difficulty X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 13:49:30 -0000 > I read the Quagga documentation a lot of times, but i couldn't find any clue how to manipulated metrics when the traffic comes from distinct neighbour. Could you help me with this, please ? offset-list command is mentioned in ripd documentation. But it seems for me, it is not implemented. From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 14:03:01 2004 Return-Path: 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 CC4D816A4CE for ; Wed, 20 Oct 2004 14:03:01 +0000 (GMT) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 679E443D1F for ; Wed, 20 Oct 2004 14:03:01 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id i9KE2xVu054853; Wed, 20 Oct 2004 09:02:59 -0500 (CDT) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id i9KE2xSG054852; Wed, 20 Oct 2004 09:02:59 -0500 (CDT) (envelope-from tinguely) Date: Wed, 20 Oct 2004 09:02:59 -0500 (CDT) From: Mark Tinguely Message-Id: <200410201402.i9KE2xSG054852@casselton.net> To: ceyong@yahoo.com, freebsd-net@freebsd.org In-Reply-To: <20041019104108.41717.qmail@web54604.mail.yahoo.com> X-Spam-Status: No, hits=0.9 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on ccn.casselton.net Subject: Re: multicast problem in vls on freebsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 14:03:01 -0000 on Tue, 19 Oct 2004 03:41:08 -0700 (PDT), Yong Chu Eu asked: > When i install freeBSD 4.10 without kame code, my multicast function on > router fail. i try to stream multicast video(vls) from router to vlc > player at client? You may need to provide more information: How is your network configured? Is there a router or switch between the FreeBSD machine and the client? multicast packets are not passed by routers. some smart switches require enabling of multicast/IGMP on the ports. What Ethernet card are you using? Have you used tcpdump on the FreeBSD machine and/or a Windows Ethernet snooper to verify multicast/IGMP traffic? --Mark Tinguely tinguely@casselton.net From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 14:53:29 2004 Return-Path: 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 5BF2A16A4CE for ; Wed, 20 Oct 2004 14:53:29 +0000 (GMT) Received: from web54608.mail.yahoo.com (web54608.mail.yahoo.com [68.142.225.192]) by mx1.FreeBSD.org (Postfix) with SMTP id C885F43D41 for ; Wed, 20 Oct 2004 14:53:28 +0000 (GMT) (envelope-from ceyong@yahoo.com) Message-ID: <20041020145328.64288.qmail@web54608.mail.yahoo.com> Received: from [202.184.41.61] by web54608.mail.yahoo.com via HTTP; Wed, 20 Oct 2004 07:53:28 PDT Date: Wed, 20 Oct 2004 07:53:28 -0700 (PDT) From: "Yong Chu Eu (Ñî×ÓÓÓ)" To: Mark Tinguely , freebsd-net@freebsd.org In-Reply-To: <200410201402.i9KE2xSG054852@casselton.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: multicast problem in vls on freebsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 14:53:29 -0000 i am try to stream from freeBSD multicast router(without kame but with pim6sd,route6d)to MN throught Access Point which are redhat. There is a bridge between eth0 and wlan0 at software Access Point. There problem is i cannot even start streaming from vls, the error message i paste as below . I can do streaming on IPV4/IPv6 unicast. | 192.168.1.1 3ffe:80f0:ff03:1::1 fxp0 FreeBSD 4.10 Router(Vls Server 0.5.6) vr0 rl0 192.168.2.1 192.168.3.1 3ffe:80f0:ff03:2::1 3ffe:80f0:ff03:3::1 | | | | | | eth0 eth0 3ffe:80f0:ff03:2::2 3ffe:80f0:ff03:3::2 192.168.2.2 192.168.3.2 Linux PC Access Point Linux PC Access Point (HOSTAP 0.13) (HOSTAP 0.13) | | | | br0 br0 192.168.2.3 192.168.3.3 3ffe:80f0:ff03:2::3 3ffe:80f0:ff03:3::3 | | | | wlan0 wlan0 192.168.2.4 192.168.3.4 essid:mipv6a essid:mipv6b ---- | MN | ---- Roaming notebook (VLC player 0.7.2) Linux Kernel 2.4.22 with MIPL 1.0 (Dlink Wireless Card with acx100 driver) 192.168.4.1(Home address 3ffe:80d0:ff03:4::1) mipv6 at vls> start matrix multicast local1 --loop Provider: Manager Error: -1 Provider: local1 Error: -1 Info: Unable to start program matrix Info: Error: unable to start streaming of program matrix Error: Unable to create thread Error: Unable to init streamer Error: Net6Output initialisation failed Error: Unable to change value for option 12: Can't assign requested address mipv6 at vls> Connection closed by foreign host. 2004-10-05 19:48:10 [ERROR/local1] Unable to start program matrix 2004-10-05 19:48:10 [ERROR/local1] Error: unable to start streaming of program matrix Error: Unable to create thread Error: Unable to init streamer Error: Net6Output initialisation failed Error: Unable to change value for option 12: Can't assign requested address pure virtual method called Abort (core dumped) # Application wide settings BEGIN "Vls" LogFile = "vls.log" # log file ScreenLog = "enable" # log to the console SystemLog = "disable" # log to the systemlog END # Security informations : # # The section "Groups" describes which group is allowed to use which command. # Each user who belongs to the 'master" group has all the power on the server. # Each one who belongs to the "monitor" group is a "read-only" user. BEGIN "Groups" # --- Format: # groupname = "cmd1|cmd2|..." # --- Example: monitor = "help|browse|logout" master = "help|browse|start|resume|suspend|stop|shutdown|logout|config|program|input|channel|show" END # The section "Users" describes each user # Use "mkpasswd" to generate the encrypted password. BEGIN "Users" # --- Format: # username = "encryptedpassword:group" # --- Example: ceyong = "3BcKWoiQn0vi6:monitor" # password is 'monitor' mipv6 = "JKg2TpPerilnw:master" # password is 'bozo' END # Telnet Administration BEGIN "Telnet" # Domain = "Inet6" # Inet4 or Inet6 LocalPort = "9999" # Port to use for that purpose Use = "true" END # Streams sources declaration BEGIN "Inputs" # --- Format: # InputName = "Type" # --- Example: local1 = "local" # Local input example # kfir = "video" # Video input example (mpeg encoder) # dvb = "dvb" # Video input example (DVB card) END #BEGIN "local1" # ConfigPath = "/usr/local/etc/videolan/vls" #END # --- Format: # BEGIN "program_number" # Name = "program_name" # Type = "type" # can be Mpeg1-PS, Mpeg2-PS, Mpeg2-TS, or Dvd # FileName = "path" # use this variable if Type is not "Dvd" # Device = "device" # use this variable with type "Dvd" # END # --- Example: #BEGIN "1" # DVD # Name = "film" # Device = "/dev/cdrom" # Type = "dvd" # DvdTitle = "2" # Start title # DvdChapter = "1" # Start chapter #END BEGIN "Input" FilesPath = "/usr/src" ProgramCount = "1" END BEGIN "1" # DVD stored on a hard disk Name = "matrix" FileName = "/usr/src/true.mpeg" Type = "Mpeg1-PS" # DvdTitle = "1" # Start title # DvdChapter = "1" # Start chapter END # Video input configuration BEGIN "kfir" # --- Example: # Device = "/dev/video" # Video4linux device (default is /dev/video) # Type = "Mpeg2-PS" # Stream type (default is "Mpeg2-PS") END # Video input (DVB) configuration BEGIN "dvb" # --- Example: # DeviceNumber = "0" # /dev/dvb/adapter # SendMethod = "0" # 0 - Send All Pids # 1 - Send only MPEG2 datas END # Channel (outputs) declaration BEGIN "Channels" # --- Format: # ChannelName = "Type" # --- Example: localhost = "network" client1 = "network" unicast = "network" multicast = "network" # localfile = "file" END # Channels configuration BEGIN "localhost" # The client is on the same host as the server DstHost = "127.0.0.1" DstPort = "1234" END BEGIN "client1" # unicast example DstHost = "192.168.3.4" # destination host DstPort = "1234" # destination port END #BEGIN "client2" # unicast with IPv6 example # Domain = "inet6" # DstHost = "3ffe:ffff::2:12:42" # destination host # DstPort = "1234" # destination port #END BEGIN "unicast" # unicast with IPv6 example Domain = "inet6" DstHost = "3ffe:80d0:ff03:4::1" # destination host DstPort = "1234" # destination port END BEGIN "multicast" Domain ="inet6" # multicast example Type = "multicast" TTL = "128" # Time To Live DstHost = "ff6e:1:1:1::2222" # multicast address DstPort = "1234" # destination port END #BEGIN "localfile" # file output example # FileName = "stream.ts" # Append = "no" # rewrite the file if it exists #END # Commands automatically lanched on Startup # Commands shall be like they would be typed in a telnet console. BEGIN "LaunchOnStartUp" # command1 = "start dolby localhost local1 --loop" # command2 = "start 28009 client1 dvb" END --- Mark Tinguely wrote: > > on Tue, 19 Oct 2004 03:41:08 -0700 (PDT), Yong Chu Eu > asked: > > > When i install freeBSD 4.10 without kame code, my multicast function > on > > router fail. i try to stream multicast video(vls) from router to vlc > > player at client? > > You may need to provide more information: > > How is your network configured? > Is there a router or switch between the FreeBSD machine and the > client? > multicast packets are not passed by routers. > some smart switches require enabling of multicast/IGMP on the ports. > > What Ethernet card are you using? > > Have you used tcpdump on the FreeBSD machine and/or a Windows Ethernet > snooper to verify multicast/IGMP traffic? > > --Mark Tinguely tinguely@casselton.net > ===== Ô¸ÄúÓÀÔ¶ĞÒ¸££¬¿ìÀֺͰ²Ïê Happy & Healthy Always ! ^_^ ! ¸öÈËÍøÒ³ Homepage:http://planet.time.net.my/sunwaycity/ceyong ¸öÈË·ğѧÍøÒ³ Buddhist Page: http://planet.time.net.my/SunwayCity/ceyong/artikel.htm ICQ:16994867/ Yahoo Messenger ID:ceyong /MSN Messenger:ceyong at hotmail.com __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 15:53:49 2004 Return-Path: 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 732BA16A4CE for ; Wed, 20 Oct 2004 15:53:49 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2DB043D1D for ; Wed, 20 Oct 2004 15:53:48 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost.ipv6.lcs.mit.edu [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i9KFrlqw014555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Wed, 20 Oct 2004 11:53:47 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i9KFreme014552; Wed, 20 Oct 2004 11:53:40 -0400 (EDT) (envelope-from wollman) Date: Wed, 20 Oct 2004 11:53:40 -0400 (EDT) From: Garrett Wollman Message-Id: <200410201553.i9KFreme014552@khavrinen.lcs.mit.edu> To: "Ronald F. Guilmette" In-Reply-To: <74506.1098231543@monkeys.com> References: <41757F72.A36AD263@freebsd.org> <74506.1098231543@monkeys.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 15:53:49 -0000 < said: > That's it for now... just aio_connect() and aio_accept(). If I think of > something else, I'll let you know. [lots of Big Picture(R) stuff elided] This is certainly an interesting model of program design. However, some caution is advised. Here are the most significant issues: - FreeBSD doesn't really support POSIX real-time signals, and I don't know whether the AIO code implements the signal mechanism at all. (I believe it's conditional in the specification on AIO && RTS.) - There's very little you can safely do in a signal handler other than post a "complete" flag (of type volatile sig_atomic_t) somewhere, or call a small number of POSIX-specified functions. - Even worse, the POSIX committee just discovered that the behavior of asynchronous signals is (thanks to changes in C99) now almost completely undefined. It is unlikely that this will be fixed any time soon. You are, on the whole, much safer (with respect to POSIX's ability to define the semantics of the operations you want) implementing your asynchronous operations using threads. FreeBSD does not support the RTS "start a new thread for signal delivery" mechanism, but with KSE it should be fairly easy to dispatch a message to the UTS telling it to do so. -GAWollman From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 16:02:06 2004 Return-Path: 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 21FBA16A4CE for ; Wed, 20 Oct 2004 16:02:06 +0000 (GMT) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0C7843D2D for ; Wed, 20 Oct 2004 16:02:05 +0000 (GMT) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.12.11/8.12.11) with ESMTP id i9KG24Ps072866; Wed, 20 Oct 2004 11:02:04 -0500 (CDT) (envelope-from tinguely@casselton.net) Received: (from tinguely@localhost) by casselton.net (8.12.11/8.12.11/Submit) id i9KG2455072865; Wed, 20 Oct 2004 11:02:04 -0500 (CDT) (envelope-from tinguely) Date: Wed, 20 Oct 2004 11:02:04 -0500 (CDT) From: Mark Tinguely Message-Id: <200410201602.i9KG2455072865@casselton.net> To: ceyong@yahoo.com, freebsd-net@freebsd.org In-Reply-To: <20041020145328.64288.qmail@web54608.mail.yahoo.com> X-Spam-Status: No, hits=0.9 required=5.0 tests=REPLY_TO_EMPTY autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on ccn.casselton.net Subject: Re: multicast problem in vls on freebsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 16:02:06 -0000 on Wed, 20 Oct 2004 07:53:28 -0700, Yong Chu Eu said: > > i am try to stream from freeBSD multicast router(without kame but with > pim6sd,route6d)to MN throught Access Point which are redhat. There is a > bridge between eth0 and wlan0 at software Access Point. There problem is i > cannot even start streaming from vls, the error message i paste as below . > I can do streaming on IPV4/IPv6 unicast. I have not used vls, so I defer to anyone that can offer better suggestions. I don't see anything in the on-line documentations about known IPv6 multicast problems or how to interpret the Net6Output error message. Have you tried to IPv4 multicast? From the vls documentation is configured: BEGIN "multicast1" # multicast streaming Type = "multicast" DstHost = "239.2.12.42" DstPort = "1234" TTL = "64" END I am assuming the Linux PC Access Point is a bridge mode, not routing, so a IPv4 mrouted (DVMRP) or pimd (PIM) is not needed; though FreeBSD will only send the multicast packets out one of the interfaces without a IPv6 multicast router. The other suggestion is to turn on the verbose debugging, it may shed light on the multicast problem. --Mark Tinguely From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 16:20:10 2004 Return-Path: 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 4166F16A4CF for ; Wed, 20 Oct 2004 16:20:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FBA843D1D for ; Wed, 20 Oct 2004 16:20:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 78F441FF9A8; Wed, 20 Oct 2004 18:20:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id A7AC31FF931; Wed, 20 Oct 2004 18:20:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 372BA156BA; Wed, 20 Oct 2004 16:16:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 2B3D6154FC; Wed, 20 Oct 2004 16:16:50 +0000 (UTC) Date: Wed, 20 Oct 2004 16:16:50 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Vladimir Terziev In-Reply-To: <20041020164004.6e0c3414@daemon.cmotd.com> Message-ID: References: <20041019180042.553c1af0@daemon.cmotd.com> <20041019163128.GA1201@grosbein.pp.ru> <20041020164004.6e0c3414@daemon.cmotd.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org Subject: Re: Quagga & ripd difficulty X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 16:20:10 -0000 On Wed, 20 Oct 2004, Vladimir Terziev wrote: > In fact i can't even predict the name of the interface via which the traffic will be routed, because my VPN is based on VTUN servers. They choose the next free tun device, respectively interface, when the VPN connection is established beteen 2 peers. use sth like device tun1; in your vtun config. PS: vtun is not secure ! -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 19:51:39 2004 Return-Path: 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 BC80716A4CE for ; Wed, 20 Oct 2004 19:51:39 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D6DF43D60 for ; Wed, 20 Oct 2004 19:51:38 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9KJpais056528; Wed, 20 Oct 2004 23:51:36 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Wed, 20 Oct 2004 23:51:36 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: "Ronald F. Guilmette" In-Reply-To: <49035.1098044385@monkeys.com> Message-ID: <20041020233952.V17688@is.park.rambler.ru> References: <49035.1098044385@monkeys.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 19:51:39 -0000 On Sun, 17 Oct 2004, Ronald F. Guilmette wrote: > I'm sitting here looking at that man pages for aio_read and aio_write, > and the question occurs to me: ``Home come there is no such thing as > an aio_connect function?'' > > There are clearly cases in which one would like to perform reads > asynchronously, but likewise, there are cases where one might like > to also perform socket connects asynchronously. So how come no > aio_connect? In FreeBSD you can do connect() on the non-blocking socket, then set the socket to a blocking mode, and post aio_read() or aio_write() operations on the socket. FreeBSD allows to post AIO operaitons on non-connected socket. NT (and W2K, I believe) do not. This is why ConnectEx() appeared in XP. I do not know about other OSes, but I belive only FreeBSD and NT have the kernel level AIO sockets implementation without the threads emulation in the user level (Solaris) or without the quietly falling to synchronous behaviour (Linux). While the developing my server nginx, I found the POSIX aio_* operations uncomfortable. I do not mean a different programming style, I mean the aio_read() and aio_write() drawbacks - they have no scatter-gather capabilities (aio_readv/aio_writev) and they require too many syscalls. E.g, the reading requires *) 3 syscalls for ready data: aio_read(), aio_error(), aio_return() *) 5 syscalls for non-ready data: aio_read(), aio_error(), waiting for notification, then aio_error(), aio_return(), or if timeout occuired - aio_cancel(), aio_error(). I think aio_* may be usefull for the zero-copy sockets, however, FreeBSD's aio_write() does not wait when the data would be acknowledged by peer and notifies the completion just after it pass the data to the network layer. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 20:04:29 2004 Return-Path: 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 2FCB216A4CE for ; Wed, 20 Oct 2004 20:04:29 +0000 (GMT) Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9CB143D2D for ; Wed, 20 Oct 2004 20:04:28 +0000 (GMT) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (excluster2.maxwell.syr.edu [128.230.129.231]) by maxwell.syr.edu (8.12.10/8.9.1) with ESMTP id i9KK4QBf026789; Wed, 20 Oct 2004 16:04:26 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2004 16:04:27 -0400 Message-ID: <32A8B2CB12BFC84D8D11D872C787AA9A058EE90F@EXCHANGE.forest.maxwell.syr.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: aio_connect ? Thread-Index: AcS23mDylHHulLbjStybFNXDu4AmLAAAZkQw From: "Christopher M. Sedore" To: "Igor Sysoev" , "Ronald F. Guilmette" cc: freebsd-net@freebsd.org Subject: RE: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 20:04:29 -0000 =20 > From: owner-freebsd-net@freebsd.org=20 > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Igor Sysoev > Subject: Re: aio_connect ? >=20 [...] > While the developing my server nginx, I found the POSIX aio_*=20 > operations > uncomfortable. I do not mean a different programming style, I mean > the aio_read() and aio_write() drawbacks - they have no scatter-gather > capabilities (aio_readv/aio_writev) and they require too many=20 > syscalls. > E.g, the reading requires > *) 3 syscalls for ready data: aio_read(), aio_error(), aio_return() > *) 5 syscalls for non-ready data: aio_read(), aio_error(), > waiting for notification, then aio_error(), aio_return(), > or if timeout occuired - aio_cancel(), aio_error(). >=20 This is why I added aio_waitcomplete(). It reduces both cases to two syscalls. -Chris=20 From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 20:11:07 2004 Return-Path: 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 8597A16A4CE for ; Wed, 20 Oct 2004 20:11:07 +0000 (GMT) Received: from pmout02.st1.spray.net (pmout02.st1.spray.net [212.78.207.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCCDF43D5A for ; Wed, 20 Oct 2004 20:11:06 +0000 (GMT) (envelope-from omikjam@spray.se) Received: from pmcodec01.st1.spray.net (pmcodec01.st1.spray.net [212.78.207.206]) by pmout02.st1.spray.net (Postfix) with SMTP id 1171286EF for ; Wed, 20 Oct 2004 20:11:05 +0000 (GMT) From: "Erik Mossberg" To: freebsd-net@freebsd.org Message-ID: <1098303064020497@lycos-europe.com> X-Mailer: LycosMail X-Originating-IP: [213.67.20.137] Mime-Version: 1.0 Date: Wed, 20 Oct 2004 20:11:04 GMT Content-Type: multipart/mixed; boundary="=_NextPart_Lycos_0204971098303064_ID" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: GRE tunnel problem om FreeBSD 5.2.1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 20:11:07 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --=_NextPart_Lycos_0204971098303064_ID Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hello, I have a weird problem with a GRE tunnel, the setup is as follows; gre0: flags=b051 mtu 1476 tunnel inet 213.67.20.137 --> 194.145.248.113 inet 194.145.248.138 --> 194.145.248.137 netmask 0xfffffffc And I've tried both w/ and w/o the link1 option mentioned in the man page for gre. and netstat -rn -f inet: Destination Gateway Flags Refs Use Netif Expire default 213.67.20.1 UGS 17 19250541 rl1 127.0.0.1 127.0.0.1 UH 1 1802 lo0 192.168.0 link#1 UC 0 0 rl0 192.168.0.54 00:04:75:c8:18:d8 UHLW 2 5683090 rl0 608 192.168.0.55 link#1 UHLW 2 140 rl0 192.168.0.91 00:0d:54:9a:d2:d1 UHLW 0 13538 rl0 1039 192.168.0.95 00:0d:88:81:fd:98 UHLW 0 766395 rl0 5 192.168.5.2 192.168.5.1 UH 0 12 gif2 194.145.248.137 194.145.248.138 UH 0 1177 gre0 213.67.20 link#2 UC 0 0 rl1 213.67.20.1 00:10:67:00:c4:39 UHLW 1 0 rl1 234 213.67.20.108 00:10:67:00:c4:39 UHLW 0 12 rl1 822 213.67.20.137 127.0.0.1 UGHS 0 136 lo0 when I try to ping 194.195.248.137 I have a 95% packet loss, but when pinging from remote to 194.145.248.138 works just fine with no packet loss. tcpdump -eni rl1 shows this: 22:05:55.148354 0:10:a7:13:bf:58 0:10:67:0:c4:39 0800 122: 213.67.20.137 > 194.145.248.113: gre (frag 49403:88@752+) 22:05:56.158351 0:10:a7:13:bf:58 0:10:67:0:c4:39 0800 122: 213.67.20.137 > 194.145.248.113: gre (frag 49410:88@51176) Sometimes the packet 1 or 2 packets goes through and gets a reply though. I use: FreeBSD 5.2.1-RELEASE-p5 #3: Sun Apr 18 22:25:17 CEST 2004 omicron@fisken:/usr/obj/usr/src/sys/merltock i386 When google-ing for this problem I found this: http://lists.freebsd.org/pipermail/freebsd-current/2004-February/02039 4.html Which seems to be the same problem, can the bug have been brought back afterwards? I hope I didn't miss any info.. Regards, Erik --=_NextPart_Lycos_0204971098303064_ID-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 20:22:35 2004 Return-Path: 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 456A016A4CE; Wed, 20 Oct 2004 20:22:35 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0178343D68; Wed, 20 Oct 2004 20:22:35 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id C45DB54A7; Wed, 20 Oct 2004 13:22:34 -0700 (PDT) To: John-Mark Gurney In-reply-to: Your message of Tue, 19 Oct 2004 20:19:31 -0700. <20041020031931.GP22681@funkthat.com> Date: Wed, 20 Oct 2004 13:22:34 -0700 Message-ID: <78978.1098303754@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org cc: Andre Oppermann Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 20:22:35 -0000 In message <20041020031931.GP22681@funkthat.com>, you wrote: >Sorry, but there is nothing in FreeBSD that will let you program in the >method you would like to do... Well, _if_ there were a full and complet family of aio_*() functions implemented in the FreeBSD kernel, _then_ I could indeed program in the style I've described. >Also, going aio_ as implemented in FreeBSD will be guaranteed to perform >worse than kqueue/kevent.. I understand that, and I don't care. As I noted earlier, for some applications, performance of these particular operations is a non- issue. >This is because aio_ requires a kernel thread >to wait for you instead of your process context.. Currently we are limited >to only executing 4 aio_ events at once.. This can be increased, but will >incure a stack for each additional thread you want to run... That's OK. I don't mind. At least I don't think that I mind. (How big must the separate event handler stacks be? If they are only, say, 2kB apiece, then that's no big deal. Heck, my lowly desktop machine has a zillion times that much main memory now!) >FreeBSD's kernel is inherently syncronous... Well, surely not entirely. I mean it fields interrupts, right? >To handle what you want to do, we would need to completely rearchitect >the FreeBSD kernel to make more things asyncronous.. I was under the impression that a lot of work had already gone in that general direction in order to support SMP. No? >Going async can improve things, and with it, makes implementing a sync >interface easy on top of it... Yes. (I realized myself last night that in theory, read(2) and write(2) could be implemented, entirely in userland, on top of aio_read() and aio_write() respectively.) >So the short of it is, no, FreeBSD at a low level does not support >it... Oh well. It didn't hurt to ask. >Now, I know this isn't what you want, but I usually make my kevent >use appear as if it's async... I use the udata pointer point to a >struct which starts with a function pointer... Then when I get events >back from kevent, I just have code that loops over the events, and calls >the associated function pointer.. simulating a signal... I understand. Your event loop is really an event/dispatch loop. >Hope this helps... Well, you have certainly helped to clarify for me the various reasons why it might be less than a good idea to use aio_*() function calls, in abundance, on the current FreeBSD kernel. For that I do thank you. From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 20:27:54 2004 Return-Path: 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 770BA16A4CE for ; Wed, 20 Oct 2004 20:27:54 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA3B443D1D for ; Wed, 20 Oct 2004 20:27:53 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9KKRqis058928; Thu, 21 Oct 2004 00:27:52 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Thu, 21 Oct 2004 00:27:52 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: "Christopher M. Sedore" In-Reply-To: <32A8B2CB12BFC84D8D11D872C787AA9A058EE90F@EXCHANGE.forest.maxwell.syr.edu> Message-ID: <20041021001251.G17688@is.park.rambler.ru> References: <32A8B2CB12BFC84D8D11D872C787AA9A058EE90F@EXCHANGE.forest.maxwell.syr.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: "Ronald F. Guilmette" Subject: RE: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 20:27:54 -0000 On Wed, 20 Oct 2004, Christopher M. Sedore wrote: > > While the developing my server nginx, I found the POSIX aio_* > > operations > > uncomfortable. I do not mean a different programming style, I mean > > the aio_read() and aio_write() drawbacks - they have no scatter-gather > > capabilities (aio_readv/aio_writev) and they require too many > > syscalls. > > E.g, the reading requires > > *) 3 syscalls for ready data: aio_read(), aio_error(), aio_return() > > *) 5 syscalls for non-ready data: aio_read(), aio_error(), > > waiting for notification, then aio_error(), aio_return(), > > or if timeout occuired - aio_cancel(), aio_error(). > > This is why I added aio_waitcomplete(). It reduces both cases to two > syscalls. As I understand aio_waitcomplete() returns aiocb of any complete AIO operation but I need to know the state of the exact AIO, namely the last aio_read(). I use kqueue to get AIO notifications. If AIO operation would fail at the start, will kqueue return notificaiton about this operation ? Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 20:52:03 2004 Return-Path: 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 CBD3E16A4CE for ; Wed, 20 Oct 2004 20:52:03 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98B0943D31 for ; Wed, 20 Oct 2004 20:52:03 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id 77B0554A7; Wed, 20 Oct 2004 13:52:03 -0700 (PDT) To: Garrett Wollman In-reply-to: Your message of Wed, 20 Oct 2004 11:53:40 -0400. <200410201553.i9KFreme014552@khavrinen.lcs.mit.edu> Date: Wed, 20 Oct 2004 13:52:03 -0700 Message-ID: <79155.1098305523@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 20:52:04 -0000 In message <200410201553.i9KFreme014552@khavrinen.lcs.mit.edu>, you wrote: >< said: > >> That's it for now... just aio_connect() and aio_accept(). If I think of >> something else, I'll let you know. > >[lots of Big Picture(R) stuff elided] > >This is certainly an interesting model of program design. It is very gentlemanly of you to say so. Thank you. >However, >some caution is advised. Here are the most significant issues: > >- FreeBSD doesn't really support POSIX real-time signals, I think that is entirely orthogonal to the issue we were discussing, which was just async I/O. There is no clear or obvious dependence of aio_*() on anything which could be called ``real time'', in the traditional sense. I certainly _do not_ expect that if I made use of aio_*() functions (with signaling) that I and/or my userland program would then receive notifications of I/O completions within any given small interval after the I/O completions actually occured. There might be big time lags before _I_ actually receive the completion notifications, e.g. if other higher priority processes get scheduled before mine. That's OK. Even if the aio_*() functions don't give me any sort of ``real time'' capabilities, I still do like the ``interrupt me when you are done'' model of I/O _and_ especially what it might allow me to do in the way of better modularizaion of the programs I have which need to do different things on different sockets concurrently. >and I >don't know whether the AIO code implements the signal mechanism at >all. (I believe it's conditional in the specification on AIO && RTS.) Well, I don't actually _have_ copies of the more recent POSIX standards... I actually have nothing fresher than about 1992... so I can't easily check that. (I wish that I did, but those documents tend to be EXPEN$IVE.) In any case, it makes no difference. The bottom line is that aio_*() with signaling capabilities (for completions) would be a Nice Thing To Have, regardless of which standard(s) such capabilities are or are not required in. >- There's very little you can safely do in a signal handler other than >post a "complete" flag (of type volatile sig_atomic_t) somewhere, or >call a small number of POSIX-specified functions. Yes, yes. I know. (I was on the ANSI C language standard comittee for awhile, long long ago, so I am well familiar with sig_atomic_t and also all of the arcane _theoretical_ limitations regarding what can and can't be done, standard-conformantly, in a signal handlers. But of course we both know that in addition to just writing sig_atomic_t thingies, in practice it is possible to do lots lots more without actually breaking anything. And if one uses ``thread safe'' libraries, then you can get away with doing even more in/from a signal handler.) >- Even worse, the POSIX committee just discovered that the behavior of >asynchronous signals is (thanks to changes in C99) now almost >completely undefined. Umm... Could you elaborate on that please? Where could I find more infor- mation about what you just said. I _relly_ want to read about this. From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 21:04:30 2004 Return-Path: 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 8DA8116A4CE for ; Wed, 20 Oct 2004 21:04:30 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7517843D1D for ; Wed, 20 Oct 2004 21:04:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 5EA2C7A41E; Wed, 20 Oct 2004 14:04:30 -0700 (PDT) Message-ID: <4176D2DE.1020308@elischer.org> Date: Wed, 20 Oct 2004 14:04:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Garrett Wollman References: <41757F72.A36AD263@freebsd.org> <74506.1098231543@monkeys.com> <200410201553.i9KFreme014552@khavrinen.lcs.mit.edu> In-Reply-To: <200410201553.i9KFreme014552@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: "Ronald F. Guilmette" Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:04:30 -0000 Garrett Wollman wrote: >< said: > > > >>That's it for now... just aio_connect() and aio_accept(). If I think of >>something else, I'll let you know. >> >> > >[lots of Big Picture(R) stuff elided] > >This is certainly an interesting model of program design. However, >some caution is advised. Here are the most significant issues: > >- FreeBSD doesn't really support POSIX real-time signals, and I >don't know whether the AIO code implements the signal mechanism at >all. (I believe it's conditional in the specification on AIO && RTS.) > >- There's very little you can safely do in a signal handler other than >post a "complete" flag (of type volatile sig_atomic_t) somewhere, or >call a small number of POSIX-specified functions. > >- Even worse, the POSIX committee just discovered that the behavior of >asynchronous signals is (thanks to changes in C99) now almost >completely undefined. It is unlikely that this will be fixed any time >soon. > >You are, on the whole, much safer (with respect to POSIX's ability to >define the semantics of the operations you want) implementing your >asynchronous operations using threads. FreeBSD does not support the >RTS "start a new thread for signal delivery" mechanism, but with KSE >it should be fairly easy to dispatch a message to the UTS telling it >to do so. > KSE threading does this by default.. If you make N threads, you will see N +1 threads. one of which will be in ksesig state. > >-GAWollman > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 21:05:18 2004 Return-Path: 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 9B48216A4CE for ; Wed, 20 Oct 2004 21:05:18 +0000 (GMT) Received: from maxwell.syr.edu (maxwell.syr.edu [128.230.129.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D11043D46 for ; Wed, 20 Oct 2004 21:05:18 +0000 (GMT) (envelope-from cmsedore@maxwell.syr.edu) Received: from exchange.maxwell.syr.edu (excluster2.maxwell.syr.edu [128.230.129.231]) by maxwell.syr.edu (8.12.10/8.9.1) with ESMTP id i9KL5FBf031304; Wed, 20 Oct 2004 17:05:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2004 17:05:17 -0400 Message-ID: <32A8B2CB12BFC84D8D11D872C787AA9A058EE914@EXCHANGE.forest.maxwell.syr.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: aio_connect ? Thread-Index: AcS242d2QiwOIewWTamIn1cEu7/kXQAA+woQ From: "Christopher M. Sedore" To: "Igor Sysoev" cc: freebsd-net@freebsd.org cc: "Ronald F. Guilmette" Subject: RE: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:05:18 -0000 =20 > From: Igor Sysoev [mailto:is@rambler-co.ru]=20 > Subject: RE: aio_connect ? >=20 > On Wed, 20 Oct 2004, Christopher M. Sedore wrote: >=20 > > > While the developing my server nginx, I found the POSIX aio_* > > > operations > > > uncomfortable. I do not mean a different programming style, I mean > > > the aio_read() and aio_write() drawbacks - they have no=20 > scatter-gather > > > capabilities (aio_readv/aio_writev) and they require too many > > > syscalls. > > > E.g, the reading requires > > > *) 3 syscalls for ready data: aio_read(), aio_error(),=20 > aio_return() > > > *) 5 syscalls for non-ready data: aio_read(), aio_error(), > > > waiting for notification, then aio_error(), aio_return(), > > > or if timeout occuired - aio_cancel(), aio_error(). > > > > This is why I added aio_waitcomplete(). It reduces both=20 > cases to two > > syscalls. >=20 > As I understand aio_waitcomplete() returns aiocb of any complete AIO > operation but I need to know the state of the exact AIO,=20 > namely the last > aio_read(). Correct, it won't poll, but what state can you get from calling aio_error() that you don't already know from aio_waitcomplete(). The operation has either completed (successfully or unsuccessfully) or it hasn't. If it hasn't you haven't "gotten it back" via aio_waitcomplete, and if it has, you did. I may be missing something, but how does aio_error() tell you something that you don't already know? > I use kqueue to get AIO notifications. If AIO operation would fail > at the start, will kqueue return notificaiton about this operation ? I don't think so--IIRC, if you have a parameter problem or the operation can't be queued, you'll get an error return from aio_read and no kqueue result. If it is queued, you'll get a kqueue notification. -Chris From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 21:11:36 2004 Return-Path: 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 CD7C916A4F0 for ; Wed, 20 Oct 2004 21:11:36 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B2BF43D2D for ; Wed, 20 Oct 2004 21:11:36 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id 7B5A654A7; Wed, 20 Oct 2004 14:11:36 -0700 (PDT) To: Igor Sysoev In-reply-to: Your message of Wed, 20 Oct 2004 23:51:36 +0400. <20041020233952.V17688@is.park.rambler.ru> Date: Wed, 20 Oct 2004 14:11:36 -0700 Message-ID: <79296.1098306696@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:11:37 -0000 In message <20041020233952.V17688@is.park.rambler.ru>, you wrote: >> There are clearly cases in which one would like to perform reads >> asynchronously, but likewise, there are cases where one might like >> to also perform socket connects asynchronously. So how come no >> aio_connect? > >In FreeBSD you can do connect() on the non-blocking socket, then set >the socket to a blocking mode, and post aio_read() or aio_write() >operations on the socket. As I earlier noted, in this thread, that approach _does not_ provide quite the same semantics as aio_*() with signaling upon completion. >While the developing my server nginx, I found the POSIX aio_* operations >uncomfortable. I do not mean a different programming style, I mean >the aio_read() and aio_write() drawbacks - they have no scatter-gather >capabilities (aio_readv/aio_writev) You could add those. They would just be your personal extensions... at least until you propose them and get them accepted by the POSIX people for the next revision of the standard. > and they require too many syscalls. >E.g, the reading requires >*) 3 syscalls for ready data: aio_read(), aio_error(), aio_return() >*) 5 syscalls for non-ready data: aio_read(), aio_error(), > waiting for notification, then aio_error(), aio_return(), > or if timeout occuired - aio_cancel(), aio_error(). This assumes that one is _not_ using the signaling capabilities of the aio_*() functions in order to allow the kernel to dynamically signal the userland program upon completion of a previously scheduled async I/O operation. If however a programmer were to use _that_ approache to de- tecting I/O completions, then the number of syscals would be reduced accordingly. However this all misses the point. As I noted earlier in this thread, efficience _for the machines_ is not always one's highest engineering design goal. If I have a choice between building a more maintainable, more adaptable, more modularized program, or instead building a more machine-efficient program, I personally will almost always choose to build the clearly, more modularized program as opposed to trying to squeeze every last machine cycle out of the thing. In fact, that is why I program almost exclusively in higher level languages, even though I could almost certainly write assembly code that would almost always be faster. Machine time is worth something, but my time is worth more. >I think aio_* may be usefull for the zero-copy sockets, however, >FreeBSD's aio_write() does not wait when the data would be acknowledged >by peer and notifies the completion just after it pass the data to >the network layer. Yea. I thought about that issue also. It's an interesting one. Ideally, for aio_write() on a (TCP?) socket, it might perhaps be the case that ``completions'' should not be signaled until a corresponding ACK comes back from the host you sent the packet to. Then again, _some_ applications would almost certainly prefer _not_ to wait for the ACK. So I suppose that the best thing, from a flexibility standpoint, would be to allow either behavior as an option which would be selected by some new setsockopt/getsockopt option. I wonder what POSIX has to say about the aio_*() functions and what constitutes ``completion''. Is a disk write complete when it is scheduled, or only when the data actually goes out to the disk drive? The same questions arise when the device one intends to write to is a network card. From owner-freebsd-net@FreeBSD.ORG Wed Oct 20 21:37:57 2004 Return-Path: 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 F17EA16A4CE for ; Wed, 20 Oct 2004 21:37:57 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D705043D31 for ; Wed, 20 Oct 2004 21:37:57 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id BE6507A424; Wed, 20 Oct 2004 14:37:57 -0700 (PDT) Message-ID: <4176DAB5.5020302@elischer.org> Date: Wed, 20 Oct 2004 14:37:57 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Igor Sysoev References: <49035.1098044385@monkeys.com> <20041020233952.V17688@is.park.rambler.ru> In-Reply-To: <20041020233952.V17688@is.park.rambler.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: "Ronald F. Guilmette" Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 21:37:58 -0000 Igor Sysoev wrote: >On Sun, 17 Oct 2004, Ronald F. Guilmette wrote: > > > >>I'm sitting here looking at that man pages for aio_read and aio_write, >>and the question occurs to me: ``Home come there is no such thing as >>an aio_connect function?'' >> >>There are clearly cases in which one would like to perform reads >>asynchronously, but likewise, there are cases where one might like >>to also perform socket connects asynchronously. So how come no >>aio_connect? >> >> > >In FreeBSD you can do connect() on the non-blocking socket, then set >the socket to a blocking mode, and post aio_read() or aio_write() >operations on the socket. > >FreeBSD allows to post AIO operaitons on non-connected socket. >NT (and W2K, I believe) do not. This is why ConnectEx() appeared in XP. >I do not know about other OSes, but I belive only FreeBSD and NT have >the kernel level AIO sockets implementation without the threads emulation >in the user level (Solaris) or without the quietly falling to synchronous >behaviour (Linux). > >While the developing my server nginx, I found the POSIX aio_* operations >uncomfortable. I do not mean a different programming style, I mean >the aio_read() and aio_write() drawbacks - they have no scatter-gather >capabilities (aio_readv/aio_writev) and they require too many syscalls. >E.g, the reading requires >*) 3 syscalls for ready data: aio_read(), aio_error(), aio_return() >*) 5 syscalls for non-ready data: aio_read(), aio_error(), > waiting for notification, then aio_error(), aio_return(), > or if timeout occuired - aio_cancel(), aio_error(). > >I think aio_* may be usefull for the zero-copy sockets, however, >FreeBSD's aio_write() does not wait when the data would be acknowledged >by peer and notifies the completion just after it pass the data to >the network layer. > Now that we have real threads, it shuld be possible to write an aio library that is implemented by having a bunch of underlying threads.. > > >Igor Sysoev >http://sysoev.ru/en/ >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 01:24:15 2004 Return-Path: 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 DCF6D16A4CE for ; Thu, 21 Oct 2004 01:24:15 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CD0743D45 for ; Thu, 21 Oct 2004 01:24:15 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id BE77D653B5; Thu, 21 Oct 2004 02:24:14 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 58057-02-4; Thu, 21 Oct 2004 02:24:14 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-121-95-134.dsl.snfc21.pacbell.net [67.121.95.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 8DE93653AE; Thu, 21 Oct 2004 02:24:12 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id DA97C61FE; Wed, 20 Oct 2004 18:24:04 -0700 (PDT) Date: Wed, 20 Oct 2004 18:24:04 -0700 From: Bruce M Simpson To: Yong Chu Eu =?iso-8859-1?B?KNHu19PT0yk=?= Message-ID: <20041021012404.GF10871@empiric.icir.org> Mail-Followup-To: Yong Chu Eu =?iso-8859-1?B?KNHu19PT0yk=?= , Mark Tinguely , freebsd-net@freebsd.org References: <200410201402.i9KE2xSG054852@casselton.net> <20041020145328.64288.qmail@web54608.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041020145328.64288.qmail@web54608.mail.yahoo.com> cc: freebsd-net@freebsd.org cc: Mark Tinguely Subject: Re: multicast problem in vls on freebsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 01:24:16 -0000 On Wed, Oct 20, 2004 at 07:53:28AM -0700, Yong Chu Eu (Ñî×ÓÓÓ) wrote: > i am try to stream from freeBSD multicast router(without kame but with > pim6sd,route6d)to MN throught Access Point which are redhat. There is a > bridge between eth0 and wlan0 at software Access Point. There problem is i > cannot even start streaming from vls, the error message i paste as below . > I can do streaming on IPV4/IPv6 unicast. There are several issues here that I see above and beyond the problems you are having with vls. Many pieces of 802.11 hardware simply don't support multicast receive in an efficient way. The last time I looked at the acx100 driver code, it did not support multicast receive, period - the necessary ioctls were not there. So if you wanted to receive multicast frames, you would need to put the card into promiscuous mode. You might consider contacting the author, Darron Broad, about this. I don't know about the behaviour of the Linux bridging code with respect to bridging multicast frames; the behaviour for most low-end hardware switch implementations is to propagate them on all other ports as if they were broadcasts. BMS From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 05:04:32 2004 Return-Path: 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 DB23316A4CE for ; Thu, 21 Oct 2004 05:04:32 +0000 (GMT) Received: from pacha.mail.bishopston.net (pacha.mail.bishopston.net [66.221.209.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C5A543D46 for ; Thu, 21 Oct 2004 05:04:32 +0000 (GMT) (envelope-from jamie@bishopston.net) X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-net@freebsd.org Received: from catflap.bishopston.net (jamie@localhost [127.0.0.1]) by catflap.bishopston.net (8.13.1/8.13.1) with ESMTP id i9L54T9T020928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2004 06:04:29 +0100 (BST) (envelope-from jamie@catflap.bishopston.net) Received: (from jamie@localhost) by catflap.bishopston.net (8.13.1/8.12.9/Submit) id i9L54RhY020926; Thu, 21 Oct 2004 06:04:27 +0100 (BST) Date: Thu, 21 Oct 2004 06:04:27 +0100 (BST) From: Jamie Jones Message-Id: <200410210504.i9L54RhY020926@catflap.bishopston.net> To: ofsen@enderunix.org X-Scanned-By: milter-sender/0.58.805 (localhost [127.0.0.1]); Thu, 21 Oct 2004 06:04:29 +0100 cc: freebsd-net@freebsd.org Subject: Re: ipfw bw limiting question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 05:04:33 -0000 > What I didn't understand is why I am stating src-ip 0xfffffff as the mask. I > mean in my bw limiting rules destionation ips (IP1, IP2 ...) should be the > one that create dynamic pipes whose bw is 100kbits/s for each pipe. But I > give src-ip 0xfffffff. Shouldn't the right way for that is to use dst-ip > 0xffffff here? To me, dst-ip seems logical - I assume you are saying it doesn't work ? Weird... Anyway, try replacing "src-ip 0xffffffff" with simply the word "all". Does that do the trick? cheers, Jamie From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 05:37:11 2004 Return-Path: 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 2534A16A4CE for ; Thu, 21 Oct 2004 05:37:11 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id BACF443D31 for ; Thu, 21 Oct 2004 05:37:09 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9L5b7is090711; Thu, 21 Oct 2004 09:37:07 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Thu, 21 Oct 2004 09:37:07 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: "Ronald F. Guilmette" In-Reply-To: <79296.1098306696@monkeys.com> Message-ID: <20041021091935.K17688@is.park.rambler.ru> References: <79296.1098306696@monkeys.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 05:37:11 -0000 On Wed, 20 Oct 2004, Ronald F. Guilmette wrote: > > and they require too many syscalls. > >E.g, the reading requires > >*) 3 syscalls for ready data: aio_read(), aio_error(), aio_return() > >*) 5 syscalls for non-ready data: aio_read(), aio_error(), > > waiting for notification, then aio_error(), aio_return(), > > or if timeout occuired - aio_cancel(), aio_error(). > > This assumes that one is _not_ using the signaling capabilities of the > aio_*() functions in order to allow the kernel to dynamically signal the > userland program upon completion of a previously scheduled async I/O > operation. If however a programmer were to use _that_ approache to de- > tecting I/O completions, then the number of syscals would be reduced > accordingly. Yes, nginx does not use the AIO signaling capabilities. With signals you do not call the syscall that waits the completion. But the call of the signal handler requires 3 context switches instead of 2 switches in the case of syscall. > However this all misses the point. As I noted earlier in this thread, > efficience _for the machines_ is not always one's highest engineering > design goal. If I have a choice between building a more maintainable, > more adaptable, more modularized program, or instead building a more > machine-efficient program, I personally will almost always choose to > build the clearly, more modularized program as opposed to trying to > squeeze every last machine cycle out of the thing. In fact, that is > why I program almost exclusively in higher level languages, even though > I could almost certainly write assembly code that would almost always be > faster. Machine time is worth something, but my time is worth more. I believe if you want to build a more maintainable, more adaptable, more modularized program then you should avoid two things - the threads and the signals. If you like to use a callback behaviour of the signals you could easy implement it without any signal. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 05:52:47 2004 Return-Path: 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 79FFD16A4CE for ; Thu, 21 Oct 2004 05:52:47 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB61943D4C for ; Thu, 21 Oct 2004 05:52:46 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9L5qjis091634; Thu, 21 Oct 2004 09:52:45 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Thu, 21 Oct 2004 09:52:45 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: "Christopher M. Sedore" In-Reply-To: <32A8B2CB12BFC84D8D11D872C787AA9A058EE914@EXCHANGE.forest.maxwell.syr.edu> Message-ID: <20041021093817.J17688@is.park.rambler.ru> References: <32A8B2CB12BFC84D8D11D872C787AA9A058EE914@EXCHANGE.forest.maxwell.syr.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: "Ronald F. Guilmette" Subject: RE: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 05:52:47 -0000 On Wed, 20 Oct 2004, Christopher M. Sedore wrote: > > > > While the developing my server nginx, I found the POSIX aio_* > > > > operations > > > > uncomfortable. I do not mean a different programming style, I mean > > > > the aio_read() and aio_write() drawbacks - they have no > > scatter-gather > > > > capabilities (aio_readv/aio_writev) and they require too many > > > > syscalls. > > > > E.g, the reading requires > > > > *) 3 syscalls for ready data: aio_read(), aio_error(), > > aio_return() > > > > *) 5 syscalls for non-ready data: aio_read(), aio_error(), > > > > waiting for notification, then aio_error(), aio_return(), > > > > or if timeout occuired - aio_cancel(), aio_error(). > > > > > > This is why I added aio_waitcomplete(). It reduces both > > cases to two > > > syscalls. Yes, aio_waitcomplete() can be used as the single waiting point. But then I can not accept() connetions. How could I learn about the new connections ? > > As I understand aio_waitcomplete() returns aiocb of any complete AIO > > operation but I need to know the state of the exact AIO, > > namely the last > > aio_read(). > > Correct, it won't poll, but what state can you get from calling > aio_error() that you don't already know from aio_waitcomplete(). The > operation has either completed (successfully or unsuccessfully) or it > hasn't. If it hasn't you haven't "gotten it back" via aio_waitcomplete, > and if it has, you did. I may be missing something, but how does > aio_error() tell you something that you don't already know? With aio_error() I may (and even have to) pass aiocb of the wanted operation. aio_waitcomplete() returns aiocb of any operation. If I have several operations there may be the race condition. > > I use kqueue to get AIO notifications. If AIO operation would fail > > at the start, will kqueue return notificaiton about this operation ? > > I don't think so--IIRC, if you have a parameter problem or the operation > can't be queued, you'll get an error return from aio_read and no kqueue > result. If it is queued, you'll get a kqueue notification. Well, so I may not call aio_error() just after aio_read()/aio_write(). However, I can not use aio_waitcomplete() instead of aio_error()/aio_return() pair after kevent() reports the completetion. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 05:59:03 2004 Return-Path: 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 E70C116A4CE for ; Thu, 21 Oct 2004 05:59:03 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2421B43D64 for ; Thu, 21 Oct 2004 05:59:03 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9L5wvis091926; Thu, 21 Oct 2004 09:58:57 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Thu, 21 Oct 2004 09:58:57 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: Julian Elischer In-Reply-To: <4176DAB5.5020302@elischer.org> Message-ID: <20041021095322.Y17688@is.park.rambler.ru> References: <49035.1098044385@monkeys.com> <20041020233952.V17688@is.park.rambler.ru> <4176DAB5.5020302@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: "Ronald F. Guilmette" Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 05:59:04 -0000 On Wed, 20 Oct 2004, Julian Elischer wrote: > Now that we have real threads, it shuld be possible to write an aio > library that is > implemented by having a bunch of underlying threads.. Do you mean the kernel only threads when the single threaded user process has several threads in kernel ? As I understand FreeBSD 4.x already has similar AIO implementation. Or do you mean the implementaion by user-level threads like in Solaris ? Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 07:06:39 2004 Return-Path: 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 B3A8516A4CE for ; Thu, 21 Oct 2004 07:06:39 +0000 (GMT) Received: from web54606.mail.yahoo.com (web54606.mail.yahoo.com [68.142.225.190]) by mx1.FreeBSD.org (Postfix) with SMTP id 2D2F743D2D for ; Thu, 21 Oct 2004 07:06:39 +0000 (GMT) (envelope-from ceyong@yahoo.com) Message-ID: <20041021070638.30131.qmail@web54606.mail.yahoo.com> Received: from [202.184.38.16] by web54606.mail.yahoo.com via HTTP; Thu, 21 Oct 2004 00:06:38 PDT Date: Thu, 21 Oct 2004 00:06:38 -0700 (PDT) From: "Yong Chu Eu (Ñî×ÓÓÓ)" To: Bruce M Simpson In-Reply-To: <20041021012404.GF10871@empiric.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-net@freebsd.org cc: Mark Tinguely Subject: Re: multicast problem in vls on freebsd 4.10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 07:06:39 -0000 i see, but its seem i cannot even start streaming from vls server(i think maybe sender side problem but i don't what is the problem,all the configuration well in manner) but i did get IPv6 and IPv4 unicast up. i confirm that my network card did support multicast. As for bridge,u are right. some bridge are not supporting multicast will do broadcast. even in broadcast i still can recv traffic. --- Bruce M Simpson wrote: > On Wed, Oct 20, 2004 at 07:53:28AM -0700, Yong Chu Eu (Ñî×ÓÓÓ) wrote: > > i am try to stream from freeBSD multicast router(without kame but with > > pim6sd,route6d)to MN throught Access Point which are redhat. There is > a > > bridge between eth0 and wlan0 at software Access Point. There problem > is i > > cannot even start streaming from vls, the error message i paste as > below . > > I can do streaming on IPV4/IPv6 unicast. > > There are several issues here that I see above and beyond the problems > you are having with vls. Many pieces of 802.11 hardware simply don't > support multicast receive in an efficient way. > > The last time I looked at the acx100 driver code, it did not support > multicast receive, period - the necessary ioctls were not there. So if > you wanted to receive multicast frames, you would need to put the card > into promiscuous mode. You might consider contacting the author, Darron > Broad, about this. > > I don't know about the behaviour of the Linux bridging code with respect > to bridging multicast frames; the behaviour for most low-end hardware > switch implementations is to propagate them on all other ports as if > they were broadcasts. > > BMS > ===== Ô¸ÄúÓÀÔ¶ĞÒ¸££¬¿ìÀֺͰ²Ïê Happy & Healthy Always ! ^_^ ! ¸öÈËÍøÒ³ Homepage:http://planet.time.net.my/sunwaycity/ceyong ¸öÈË·ğѧÍøÒ³ Buddhist Page: http://planet.time.net.my/SunwayCity/ceyong/artikel.htm ICQ:16994867/ Yahoo Messenger ID:ceyong /MSN Messenger:ceyong at hotmail.com _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 07:08:49 2004 Return-Path: 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 DA45F16A4D5 for ; Thu, 21 Oct 2004 07:08:49 +0000 (GMT) Received: from blah.sun-fish.com (blah.sun-fish.com [62.176.125.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9CD543D41 for ; Thu, 21 Oct 2004 07:08:47 +0000 (GMT) (envelope-from vladimir.terziev@sun-fish.com) Received: by blah.sun-fish.com (Postfix, from userid 599) id E5C783423B; Thu, 21 Oct 2004 09:08:45 +0200 (CEST) Received: from sun-fish.com (fs.cmotd.com [192.168.3.253]) by blah.sun-fish.com (Postfix) with ESMTP id D6BC334234; Thu, 21 Oct 2004 09:08:45 +0200 (CEST) Received: by sun-fish.com (Postfix, from userid 1008) id 7C559D4C88A; Thu, 21 Oct 2004 09:08:45 +0200 (CEST) Received: from daemon.cmotd.com (daemon.cmotd.com [192.168.3.104]) by sun-fish.com (Postfix) with SMTP id 0252AD4C887; Thu, 21 Oct 2004 09:08:45 +0200 (CEST) Date: Thu, 21 Oct 2004 10:08:45 +0300 From: Vladimir Terziev To: "Bjoern A. Zeeb" Message-Id: <20041021100845.4ae38f61@daemon.cmotd.com> In-Reply-To: References: <20041019180042.553c1af0@daemon.cmotd.com> <20041019163128.GA1201@grosbein.pp.ru> <20041020164004.6e0c3414@daemon.cmotd.com> Organization: SunFish Ltd. X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-unknown-freebsd4.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Quagga & ripd difficulty X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 07:08:50 -0000 Why do you think vtun is not secure ? On Wed, 20 Oct 2004 16:16:50 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Wed, 20 Oct 2004, Vladimir Terziev wrote: > > > In fact i can't even predict the name of the interface via which the traffic will be routed, because my VPN is based on VTUN servers. They choose the next free tun device, respectively interface, when the VPN connection is established beteen 2 peers. > > use sth like > device tun1; > in your vtun config. > > PS: vtun is not secure ! > > -- > Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT > From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 07:23:21 2004 Return-Path: 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 B311A16A4CE for ; Thu, 21 Oct 2004 07:23:21 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FFB843D1F for ; Thu, 21 Oct 2004 07:23:21 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 2E9B4653B5; Thu, 21 Oct 2004 08:23:19 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 61745-09-2; Thu, 21 Oct 2004 08:23:18 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-121-95-134.dsl.snfc21.pacbell.net [67.121.95.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 9C35465218; Thu, 21 Oct 2004 08:23:16 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 77968631E; Thu, 21 Oct 2004 00:23:05 -0700 (PDT) Date: Thu, 21 Oct 2004 00:23:05 -0700 From: Bruce M Simpson To: Vladimir Terziev Message-ID: <20041021072305.GA13756@empiric.icir.org> Mail-Followup-To: Vladimir Terziev , "Bjoern A. Zeeb" , freebsd-net@freebsd.org References: <20041019180042.553c1af0@daemon.cmotd.com> <20041019163128.GA1201@grosbein.pp.ru> <20041020164004.6e0c3414@daemon.cmotd.com> <20041021100845.4ae38f61@daemon.cmotd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041021100845.4ae38f61@daemon.cmotd.com> cc: "Bjoern A. Zeeb" cc: freebsd-net@freebsd.org Subject: Re: Quagga & ripd difficulty X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 07:23:21 -0000 On Thu, Oct 21, 2004 at 10:08:45AM +0300, Vladimir Terziev wrote: > Why do you think vtun is not secure ? This is fact, not opinion: http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt BMS From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 07:26:23 2004 Return-Path: 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 42E6B16A4CE for ; Thu, 21 Oct 2004 07:26:23 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8302443D58 for ; Thu, 21 Oct 2004 07:26:22 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 547291FF9AC; Thu, 21 Oct 2004 09:26:20 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 7D7781FF9AB; Thu, 21 Oct 2004 09:26:18 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 14F03156C2; Thu, 21 Oct 2004 07:26:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 124BE15682; Thu, 21 Oct 2004 07:26:03 +0000 (UTC) Date: Thu, 21 Oct 2004 07:26:02 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Vladimir Terziev In-Reply-To: <20041021100845.4ae38f61@daemon.cmotd.com> Message-ID: References: <20041019180042.553c1af0@daemon.cmotd.com> <20041019163128.GA1201@grosbein.pp.ru> <20041021100845.4ae38f61@daemon.cmotd.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org Subject: Re: Quagga & ripd difficulty X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 07:26:23 -0000 On Thu, 21 Oct 2004, Vladimir Terziev wrote: > On Wed, 20 Oct 2004 16:16:50 +0000 (UTC) > "Bjoern A. Zeeb" wrote: > > > use sth like > > device tun1; > > in your vtun config. > > > > PS: vtun is not secure ! > > Why do you think vtun is not secure ? Peter Gutman wrote a nice article about vtun (and others) for a german magazin about that [1]. I am unsure if the linux_vpn.txt is the same as the article but it may at least give a good overview/introduction. The english version of the article seems to be online[2] btw. [1] see http://www.cs.auckland.ac.nz/~pgut001/ /Analysis of some problems in Linux VPN implementations.*/ [2] http://www.linux-magazine.com/issue/39/VPN_Insecurity.pdf -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 08:03:45 2004 Return-Path: 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 9D6DC16A4CE for ; Thu, 21 Oct 2004 08:03:45 +0000 (GMT) Received: from server.frh.utn.edu.ar (server.frh.utn.edu.ar [170.210.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1892343D2D for ; Thu, 21 Oct 2004 08:03:44 +0000 (GMT) (envelope-from fernando@gont.com.ar) Received: (qmail 24766 invoked from network); 21 Oct 2004 08:02:36 -0000 Received: from customer123-155-32.iplannetworks.net (HELO fernando.gont.com.ar) (gont-fernando@200.123.155.32) by server.frh.utn.edu.ar with SMTP; 21 Oct 2004 08:02:36 -0000 Message-Id: <4.3.2.7.2.20041021044818.00d5a560@server.frh.utn.edu.ar> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Oct 2004 05:13:55 -0300 To: freebsd-net@freebsd.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: tcp_notify() and the connection establishment timer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 08:03:45 -0000 Folks, I was trying to figure out what the BSD policy for aborting connection-establishment attempts was. According to Stevens' TCPv2, when TCP sends the first SYN for establishing a connection, a 75-seconds timer is initialized. If the connection cannot be established before that 75-second period is over, the conenction will be aborted. However, looking at the tcp_notify() function, I see the following code: static struct inpcb * tcp_notify(inp, error) struct inpcb *inp; int error; { struct tcpcb *tp = (struct tcpcb *)inp->inp_ppcb; /* * Ignore some errors if we are hooked up. * If connection hasn't completed, has retransmitted several times, * and receives a second error, give up now. This is better * than waiting a long time to establish a connection that * can never complete. */ if (tp->t_state == TCPS_ESTABLISHED && (error == EHOSTUNREACH || error == ENETUNREACH || error == EHOSTDOWN)) { return inp; } else if (tp->t_state < TCPS_ESTABLISHED && tp->t_rxtshift > 3 && tp->t_softerror) { tcp_drop(tp, error); return (struct inpcb *)0; } else { tp->t_softerror = error; return inp; } #if 0 wakeup( &so->so_timeo); sorwakeup(so); sowwakeup(so); #endif } Maybe I'm missing something, but I get the impression that, considering the value (six seconds) to which the RTO is initialized, that part that says } else if (tp->t_state < TCPS_ESTABLISHED && tp->t_rxtshift > 3 && tp->t_softerror) { tcp_drop(tp, error); return (struct inpcb *)0; will never be executed, as the connection-establishment timer will always timeout before the evaluated condition becomes true. Am I missing something? Or is it that this code is there just in case the initial RTO is reduced to such a value that, in that case, this code would kick in before the 75-seconds tconnection-establishment timer? Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 10:33:32 2004 Return-Path: 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 94E4A16A505 for ; Thu, 21 Oct 2004 10:33:31 +0000 (GMT) Received: from risky.niblet.co.uk (risky.niblet.co.uk [80.177.236.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0D7443D45 for ; Thu, 21 Oct 2004 10:33:30 +0000 (GMT) (envelope-from matt@genesi.co.uk) Received: from sakura.niblet.co.uk ([80.177.236.68] helo=sakura) by risky.niblet.co.uk with smtp (Exim 4.42 (FreeBSD)) id 1CKaGO-0005N8-Ao for freebsd-net@freebsd.org; Thu, 21 Oct 2004 11:33:44 +0100 From: "Matt Sealey" To: Date: Thu, 21 Oct 2004 11:33:32 +0100 Message-ID: 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.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Subject: xl0: discard oversize frame (ether type 800 flags 3 len 1492 > max 1472) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 10:33:32 -0000 xl0: discard oversize frame (ether type 800 flags 3 len 1492 > max 1472) Does anyone know what causes this kernel message? I was getting it on wi0 for a long time (bridged connection between xl0, rl0 and wi0) but just ignored it. Eventually after about 20 of those messages over an extended period of time (week or so), the wireless network slows down to treacle. I haven't noticed anything on the 100Mbit network yet but I assume it's going to do the same thing. No matter what the MTU is, there is always this 20 byte discrepency. I've checked the bug list summary and it's on there but I can't find a reasonable explanation on what it is and why it happens, if it's a configuration thing I can fix, I want to fix it even if it means disabling features. -- Matt Sealey Genesi, Manager, Developer Relations From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 12:51:06 2004 Return-Path: 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 E544316A4CE; Thu, 21 Oct 2004 12:51:06 +0000 (GMT) Received: from melusine.cuivre.fr.eu.org (melusine.cuivre.fr.eu.org [82.225.155.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6241C43D48; Thu, 21 Oct 2004 12:51:06 +0000 (GMT) (envelope-from thomas@FreeBSD.ORG) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 9F28F2C3D0; Thu, 21 Oct 2004 14:51:04 +0200 (CEST) Date: Thu, 21 Oct 2004 14:51:04 +0200 From: Thomas Quinot To: freebsd-net@freebsd.org, wpaul@freebsd.org Message-ID: <20041021125104.GA14176@melusine.cuivre.fr.eu.org> References: <20041019135612.GA27971@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041019135612.GA27971@melusine.cuivre.fr.eu.org> X-message-flag: WARNING! Using Outlook can damage your computer. User-Agent: Mutt/1.5.6i Subject: Re: yppush going into an endless loop X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 12:51:07 -0000 * Thomas Quinot, 2004-10-19 : > On a 5.2.1-REL NIS server where NIS maps are updated every hour from a > crontab, I often see yppush going into an endless loop: Here is more information. I was able to capture the output of yppush on one of these occurrences: yppush: transfer of map netid.byname to server failed yppush: status returned by ypxfr: Master's version not newer yppush in malloc(): error: recursive call yppush: warning: exiting with transfer to (transid = 1098286624) still pending yppush in free(): error: recursive call yppush: warning: exiting with transfer to (transid = 1098286624) still pending yppush in free(): error: recursive call yppush: warning: exiting with transfer to (transid = 1098286624) still pending yppush in free(): error: recursive call yppush: warning: exiting with transfer to (transid = 1098286624) still pending [...] Something fishy is happening here, maybe the SIGIO handler is called at an unfortunate time. I'll patch around yppush to get a core dump at that point. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 13:40:19 2004 Return-Path: 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 59A8216A4CE for ; Thu, 21 Oct 2004 13:40:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E2FF43D53 for ; Thu, 21 Oct 2004 13:40:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 76981 invoked from network); 21 Oct 2004 13:38:56 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 13:38:56 -0000 Message-ID: <4177BC49.73B6D910@freebsd.org> Date: Thu, 21 Oct 2004 15:40:25 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fernando Gont References: <4.3.2.7.2.20041021044818.00d5a560@server.frh.utn.edu.ar> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: tcp_notify() and the connection establishment timer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 13:40:19 -0000 Fernando Gont wrote: > > Folks, > > I was trying to figure out what the BSD policy for aborting > connection-establishment attempts was. > > According to Stevens' TCPv2, when TCP sends the first SYN for establishing > a connection, a 75-seconds timer is initialized. If the connection cannot > be established before that 75-second period is over, the conenction will be > aborted. > > However, looking at the tcp_notify() function, I see the following code: > > static struct inpcb * > tcp_notify(inp, error) > struct inpcb *inp; > int error; > { > struct tcpcb *tp = (struct tcpcb *)inp->inp_ppcb; > > /* > * Ignore some errors if we are hooked up. > * If connection hasn't completed, has retransmitted several times, > * and receives a second error, give up now. This is better > * than waiting a long time to establish a connection that > * can never complete. > */ > if (tp->t_state == TCPS_ESTABLISHED && > (error == EHOSTUNREACH || error == ENETUNREACH || > error == EHOSTDOWN)) { > return inp; > } else if (tp->t_state < TCPS_ESTABLISHED && tp->t_rxtshift > 3 && > tp->t_softerror) { > tcp_drop(tp, error); > return (struct inpcb *)0; > } else { > tp->t_softerror = error; > return inp; > } > #if 0 > wakeup( &so->so_timeo); > sorwakeup(so); > sowwakeup(so); > #endif > } > > Maybe I'm missing something, but I get the impression that, considering the > value (six seconds) to which the RTO is initialized, that part that says > > } else if (tp->t_state < TCPS_ESTABLISHED && tp->t_rxtshift > 3 && > tp->t_softerror) { > tcp_drop(tp, error); > return (struct inpcb *)0; > > will never be executed, as the connection-establishment timer will always > timeout before the evaluated condition becomes true. > > Am I missing something? Or is it that this code is there just in case the > initial RTO is reduced to such a value that, in that case, this code would > kick in before the 75-seconds tconnection-establishment timer? Yes, tcp_notify() gets called from icmp_input() when ICMP unreachable or related error messages from the network are received. In those cases you don't want to wait the full 75 seconds because the network tells you that a connection cannot be established to that destination. It doesn't do that the first time the network tells us that to avoid too fast reaction on spurious network problems, outages or re-routings. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 14:33:22 2004 Return-Path: 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 454CC16A4CF for ; Thu, 21 Oct 2004 14:33:22 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63FB743D48 for ; Thu, 21 Oct 2004 14:33:21 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 77418 invoked from network); 21 Oct 2004 14:31:58 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 14:31:58 -0000 Message-ID: <4177C8AD.6060706@freebsd.org> Date: Thu, 21 Oct 2004 16:33:17 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:33:22 -0000 I want to bring this up for discussion prior to start working on it. I intend to remove T/TCP (transactional TCP) support from our TCP implementation for the following reasons: o T/TCP is very intrusive to the TCP code and has special cases and dependencies in many places. This makes it a lot harder to maintain the TCP code and is prone to break when other changes are made. In fact I don't know whether still works on 6-current. o T/TCP only available on FreeBSD. No other Operating System or TCP/IP stack implements it to my knowledge. Certainly no OS that is common. o T/TCP is more or less broken by design. It's security model is very weak and it strongly recommended to disable it if your host is exposed to the Internet. o T/TCP is disabled by default on FreeBSD. o T/TCP requires different API calls than TCP to use it (UDP like). o T/TCP is not supported by any common network application. o T/TCP is unmaintained and other major OS have refused to consider including it based on it's weak security model (DDoS heaven). However something like T/TCP is certainly useful and I know of one special purpose application using it (Web Proxy Server/Client for high-delay Satellite connections). Thus after the removal of T/TCP for the reasons above I want to provide a work-alike replacement for T/TCP's functionality: o Using a cookie mechanism instead of the clumsy TAO connection counting like SYN cookies in syncache. o The client has to enable the option in the TCP SYN request to the server. If the server accepts it, then it returns a unique cookie generated from the IP address of the client and some random seed. On subsequent connections the client will include the cookie in the TCP SYN request and it will send the first chunk of payload in the SYN packet. If the cookie matches on the server side, the TCP connection will be direcly propagated into ESTABLISHED state and process plus present the payload to accept socket. The SYN/ACK will be returned together with the answer payload from the socket (or it will SYN/ACK directly as we do now, doesn't matter that much). With this we get the same short-cutting of the 3WSH but with way less intrusive code and much more secure than T/TCP. o Using the same standard TCP API but with an deferred connect() until the first write() is made. o To be enabled with a simple socket option on the client and server side. o All infrastructure is in place to easily implement this (syncache and tcphostcache). This different implementation will be disabled by default and clearly marked EXPERIMENTAL in a protocol sense. It will allow the only known user of T/TCP to keep the same functionality with a very small change to his application. It allows interesting new uses primarily in Intranet environment where many short connections are openend in rapid succession (LDAP servers, SQL servers, etc.). The modifications to those programs to use the new option is minimal and requires only the setting of the socket option, one setsockopt() call. A nice description of T/TCP is here: http://linuxgazette.net/issue47/stacey.html FUD Notice: If you haven't read and/or unstood the link above or TCP/IP Illustrated Volume 3 then please refrain from participating in this discussion! -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 14:42:08 2004 Return-Path: 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 6CA0116A4CE; Thu, 21 Oct 2004 14:42:08 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99BA243D49; Thu, 21 Oct 2004 14:42:07 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i9LEg5th028436; Thu, 21 Oct 2004 16:42:05 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 21 Oct 2004 16:33:17 +0200." <4177C8AD.6060706@freebsd.org> Date: Thu, 21 Oct 2004 16:42:05 +0200 Message-ID: <28435.1098369725@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:42:08 -0000 In message <4177C8AD.6060706@freebsd.org>, Andre Oppermann writes: >I want to bring this up for discussion prior to start working on it. > >I intend to remove T/TCP (transactional TCP) support from our TCP >implementation for the following reasons: Yeah, go for it! >However something like T/TCP is certainly useful and I know of one special >purpose application using it (Web Proxy Server/Client for high-delay Satellite >connections). Wouldn't that be inferior to what accept-filters gives us ? -- 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. From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 14:47:19 2004 Return-Path: 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 2E95416A4CF for ; Thu, 21 Oct 2004 14:47:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64BBE43D46 for ; Thu, 21 Oct 2004 14:47:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 77641 invoked from network); 21 Oct 2004 14:45:55 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 14:45:55 -0000 Message-ID: <4177CBFC.AEA69F47@freebsd.org> Date: Thu, 21 Oct 2004 16:47:24 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp References: <28435.1098369725@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:47:19 -0000 Poul-Henning Kamp wrote: > > In message <4177C8AD.6060706@freebsd.org>, Andre Oppermann writes: > >I want to bring this up for discussion prior to start working on it. > > > >I intend to remove T/TCP (transactional TCP) support from our TCP > >implementation for the following reasons: > > Yeah, go for it! > > >However something like T/TCP is certainly useful and I know of one special > >purpose application using it (Web Proxy Server/Client for high-delay Satellite > >connections). > > Wouldn't that be inferior to what accept-filters gives us ? No, not at all. In fact they are complementary and work beautifully together. T/TCP and the replacement are about cutting the extra round-trip times for the three-way handshake of TCP. accept_filter is sort of a buffer that defers readablility to userland until a full request has been received (a HTTP/1.1 request for example). -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 14:56:56 2004 Return-Path: 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 9FF3216A4CE for ; Thu, 21 Oct 2004 14:56:56 +0000 (GMT) Received: from mailhost.nmt.edu (mailhost.nmt.edu [129.138.4.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A79F43D31 for ; Thu, 21 Oct 2004 14:56:56 +0000 (GMT) (envelope-from wcolburn@nmt.edu) Received: from icewing.nmt.edu (icewing.nmt.edu [129.138.4.102]) by mailhost.nmt.edu (8.13.0/8.13.0) with ESMTP id i9LEusfj020837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Oct 2004 08:56:55 -0600 Received: from icewing.nmt.edu (localhost [127.0.0.1]) by icewing.nmt.edu (8.12.8/8.12.8) with ESMTP id i9LEusMG019688 for ; Thu, 21 Oct 2004 08:56:54 -0600 Received: (from wcolburn@localhost) by icewing.nmt.edu (8.12.8/8.12.8/Submit) id i9LEusnH019686 for freebsd-net@freebsd.org; Thu, 21 Oct 2004 08:56:54 -0600 Date: Thu, 21 Oct 2004 08:56:54 -0600 From: "William D. Colburn (aka Schlake)" To: freebsd-net@freebsd.org Message-ID: <20041021145654.GA19657@nmt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: 9 second ping lag unless I run tcpdump on RELENG_5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:56:56 -0000 I have a RELENG_5 box on my desk. Unless I run the tcpdump program, it responds progressively slower on the network. This seemed like the most appropriate list to post this question too. This morning, for instance, it had a 9 second ping response time from a machine on the same network segment as it when I came into work. As soon as I typed 'tcpdump' on the freebsd box the ping time dropped to nearly instantaneous. I killed tcpdump and let it run for a while. About a thousand seconds later it suddenly jumped to 1 second, then to 2 seconds. As soon as I ran tcpdump again it dropped back to normal. The uname ids it as 5.3-STABLE #14: Wed Oct 20 10:23:11 UTC 2004, with a GENERIC kernel. I did a new cvsup (along with a tcpdump because otherwise cvsup fails) this morning and nothing new came across. -- William Colburn, "Sysprog" Computer Center, New Mexico Institute of Mining and Technology http://www.nmt.edu/tcc/ http://www.nmt.edu/~wcolburn From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 14:59:26 2004 Return-Path: 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 9DC3916A4CE; Thu, 21 Oct 2004 14:59:26 +0000 (GMT) Received: from starburst.demon.co.uk (starburst.demon.co.uk [80.176.229.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4616943D55; Thu, 21 Oct 2004 14:59:25 +0000 (GMT) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.11.6/8.11.6) id i9LExNX13313; Thu, 21 Oct 2004 15:59:23 +0100 From: Richard Wendland Message-Id: <200410211459.i9LExNX13313@starburst.demon.co.uk> To: andre@freebsd.org (Andre Oppermann) Date: Thu, 21 Oct 2004 15:59:22 +0100 (BST) In-Reply-To: <4177C8AD.6060706@freebsd.org> from "Andre Oppermann" at Oct 21, 2004 04:33:17 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richard@codeburst.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 14:59:26 -0000 > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: Good reasons & decision Andre. Another reason is that T/TCP (RFC1644) is listed as "deprecated" in the "Roadmap for TCP Specification Documents" I-D, almost certainly to become a RFC soon: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-00.txt Richard -- Richard Wendland richard@codeburst.co.uk From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 15:24:11 2004 Return-Path: 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 4C46B16A4CE for ; Thu, 21 Oct 2004 15:24:11 +0000 (GMT) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.FreeBSD.org (Postfix) with SMTP id C277943D5A for ; Thu, 21 Oct 2004 15:24:10 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 67547 invoked from network); 21 Oct 2004 15:24:09 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay01.pair.com with SMTP; 21 Oct 2004 15:24:09 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 21 Oct 2004 10:24:08 -0500 (CDT) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <4177C8AD.6060706@freebsd.org> Message-ID: <20041021101010.V7681@odysseus.silby.com> References: <4177C8AD.6060706@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 15:24:11 -0000 On Thu, 21 Oct 2004, Andre Oppermann wrote: > I want to bring this up for discussion prior to start working on it. > > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: That sounds good. > o The client has to enable the option in the TCP SYN request to the server. > If the server accepts it, then it returns a unique cookie generated from > the IP address of the client and some random seed. On subsequent > connections > the client will include the cookie in the TCP SYN request and it will > send the first chunk of payload in the SYN packet. If the cookie matches I think that it would have to be slightly more complex than that for it to be secure. Instead of using syncookie/RFC1948-like generation, just randomly generate the cookie and store it in the tcp host cache. Then steal the concept of NQNFS leases, giving the cookie a limited lifetime, after which it must be reissued. I think you'll need to track two cookies on the server side, to gracefully handle the cookie transition period... Well, I'm sure there are many ways to do it, but I agree that it's certainly doable; we have plenty of time to talk about the exact implementation. My reason for avoiding the use of syncookies/RFC1948 in the implementation is that relying on those pieces of code makes a FreeBSD implementation easy, but would make an implementation in other OSes potentially difficult. > FUD Notice: > > If you haven't read and/or unstood the link above or TCP/IP Illustrated > Volume 3 then please refrain from participating in this discussion! Hey, I just looked in section 24.7 in Vol. 1, and it says nothing but good things about T/TCP - you must be the one misunderstanding things here! :) Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 15:35:21 2004 Return-Path: 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 17DC516A4E0 for ; Thu, 21 Oct 2004 15:35:21 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E15E43D1D for ; Thu, 21 Oct 2004 15:35:20 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 78076 invoked from network); 21 Oct 2004 15:33:57 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 15:33:57 -0000 Message-ID: <4177D73E.C0531896@freebsd.org> Date: Thu, 21 Oct 2004 17:35:26 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack References: <4177C8AD.6060706@freebsd.org> <20041021101010.V7681@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 15:35:21 -0000 Mike Silbersack wrote: > > On Thu, 21 Oct 2004, Andre Oppermann wrote: > > o The client has to enable the option in the TCP SYN request to the server. > > If the server accepts it, then it returns a unique cookie generated from > > the IP address of the client and some random seed. On subsequent > > connections > > the client will include the cookie in the TCP SYN request and it will > > send the first chunk of payload in the SYN packet. If the cookie matches > > I think that it would have to be slightly more complex than that for it to > be secure. Instead of using syncookie/RFC1948-like generation, just > randomly generate the cookie and store it in the tcp host cache. Then > steal the concept of NQNFS leases, giving the cookie a limited lifetime, > after which it must be reissued. I think you'll need to track two cookies > on the server side, to gracefully handle the cookie transition period... It wasn't meant to use the exact syncookies code, but the general mechanism like your description of it. We can't use syncookies and that code as is anyway because it puts far more information into the cookie. > Well, I'm sure there are many ways to do it, but I agree that it's > certainly doable; we have plenty of time to talk about the exact > implementation. My reason for avoiding the use of syncookies/RFC1948 in > the implementation is that relying on those pieces of code makes a FreeBSD > implementation easy, but would make an implementation in other OSes > potentially difficult. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 15:39:44 2004 Return-Path: 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 9314516A4CE; Thu, 21 Oct 2004 15:39:44 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0273243D1F; Thu, 21 Oct 2004 15:39:44 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 4C00265213; Thu, 21 Oct 2004 16:39:42 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 68561-01-14; Thu, 21 Oct 2004 16:39:41 +0100 (BST) Received: from empiric.dek.spc.org (adsl-67-121-95-134.dsl.snfc21.pacbell.net [67.121.95.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 61E43651F4; Thu, 21 Oct 2004 16:39:41 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 7EA0965F6; Thu, 21 Oct 2004 08:39:33 -0700 (PDT) Date: Thu, 21 Oct 2004 08:39:33 -0700 From: Bruce M Simpson To: Andre Oppermann Message-ID: <20041021153933.GK13756@empiric.icir.org> Mail-Followup-To: Andre Oppermann , freebsd-arch@freebsd.org, freebsd-net@freebsd.org References: <4177C8AD.6060706@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4177C8AD.6060706@freebsd.org> cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 15:39:44 -0000 On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: Go ahead and kill the old thing, it's time. I agree. > Thus after the removal of T/TCP for the reasons above I want to provide > a work-alike replacement for T/TCP's functionality: I disagree. I think the time spent here would be better spent on working on an import of SCTP into the kernel, perhaps the KAME code base would be a good starting point. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 16:22:48 2004 Return-Path: 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 D632A16A4CF for ; Thu, 21 Oct 2004 16:22:48 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3774043D41 for ; Thu, 21 Oct 2004 16:22:48 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 78473 invoked from network); 21 Oct 2004 16:21:24 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 16:21:24 -0000 Message-ID: <4177E25E.804639E@freebsd.org> Date: Thu, 21 Oct 2004 18:22:54 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce M Simpson References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 16:22:49 -0000 Bruce M Simpson wrote: > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > I disagree. I think the time spent here would be better spent on working > on an import of SCTP into the kernel, perhaps the KAME code base would > be a good starting point. Is the SCTP in KAME complete and stable? Are there any other (open source) implementations of it? It's my time and I'll do the T/TCP replacement in any case because I think it is useful. :) -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 16:27:59 2004 Return-Path: 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 5DCDB16A4CE; Thu, 21 Oct 2004 16:27:59 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFB7443D67; Thu, 21 Oct 2004 16:27:58 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i9LGRvqw026450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Thu, 21 Oct 2004 12:27:57 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i9LGRvsj026447; Thu, 21 Oct 2004 12:27:57 -0400 (EDT) (envelope-from wollman) Date: Thu, 21 Oct 2004 12:27:57 -0400 (EDT) From: Garrett Wollman Message-Id: <200410211627.i9LGRvsj026447@khavrinen.lcs.mit.edu> To: Mike Silbersack In-Reply-To: <20041021101010.V7681@odysseus.silby.com> References: <4177C8AD.6060706@freebsd.org> <20041021101010.V7681@odysseus.silby.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@FreeBSD.ORG cc: freebsd-arch@FreeBSD.ORG Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 16:27:59 -0000 < said: > I think that it would have to be slightly more complex than that for it to > be secure. Instead of using syncookie/RFC1948-like generation, > [...] HIP! HIP! HIP!!! -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 16:36:07 2004 Return-Path: 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 878B916A4CE for ; Thu, 21 Oct 2004 16:36:07 +0000 (GMT) Received: from mail.netroad.ru (mail.netroad.ru [213.24.172.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB78E43D41 for ; Thu, 21 Oct 2004 16:36:06 +0000 (GMT) (envelope-from devel@proxy.netroad.ru) Received: from mail.netroad.ru (localhost [127.0.0.1]) by mail.netroad.ru (Postfix) with ESMTP id 263E514860B; Thu, 21 Oct 2004 20:34:40 +0400 (MSD) Received: from proxy.netroad.ru (proxy.netroad.ru [213.24.172.2]) by mail.netroad.ru (Postfix) with ESMTP id 051371485FF; Thu, 21 Oct 2004 20:34:40 +0400 (MSD) Received: by proxy.netroad.ru (Postfix, from userid 999) id C78CB256214; Thu, 21 Oct 2004 20:36:01 +0400 (MSD) Date: Thu, 21 Oct 2004 20:36:01 +0400 From: "Lenar D. Tukhvatullin" To: "William D. Colburn (aka Schlake)" Message-ID: <20041021163601.GA88117@proxy.netroad.ru> Mail-Followup-To: "William D. Colburn (aka Schlake)" , freebsd-net@freebsd.org References: <20041021145654.GA19657@nmt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041021145654.GA19657@nmt.edu> User-Agent: Mutt/1.5.5.1i X-AntiVirus: ClamAV at mail.netroad.ru cc: freebsd-net@freebsd.org Subject: Re: 9 second ping lag unless I run tcpdump on RELENG_5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 16:36:07 -0000 On Thu, Oct 21, 2004 at 08:56:54AM -0600, William D. Colburn (aka Schlake) wrote: > I have a RELENG_5 box on my desk. Unless I run the tcpdump program, it > responds progressively slower on the network. This seemed like the most > appropriate list to post this question too. > > This morning, for instance, it had a 9 second ping response time from a > machine on the same network segment as it when I came into work. As > soon as I typed 'tcpdump' on the freebsd box the ping time dropped to > nearly instantaneous. I killed tcpdump and let it run for a while. > About a thousand seconds later it suddenly jumped to 1 second, then to 2 > seconds. As soon as I ran tcpdump again it dropped back to normal. > > The uname ids it as 5.3-STABLE #14: Wed Oct 20 10:23:11 UTC 2004, > with a GENERIC kernel. I did a new cvsup (along with a tcpdump because > otherwise cvsup fails) this morning and nothing new came across. tcpdump (by default) puts interface into promiscuous mode. (or you can set this mode by hand: ifconfig promisc) Maybe your ethernet card broken? Try to replace it. -- Lenar D. Tukhvatullin From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 16:45:50 2004 Return-Path: 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 8C3A116A4CE for ; Thu, 21 Oct 2004 16:45:50 +0000 (GMT) Received: from mailhost.nmt.edu (mailhost.nmt.edu [129.138.4.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FF5643D1D for ; Thu, 21 Oct 2004 16:45:50 +0000 (GMT) (envelope-from wcolburn@nmt.edu) Received: from icewing.nmt.edu (icewing.nmt.edu [129.138.4.102]) by mailhost.nmt.edu (8.13.0/8.13.0) with ESMTP id i9LGjmvt030175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Oct 2004 10:45:49 -0600 Received: from icewing.nmt.edu (localhost [127.0.0.1]) by icewing.nmt.edu (8.12.8/8.12.8) with ESMTP id i9LGjmMG020471 for ; Thu, 21 Oct 2004 10:45:48 -0600 Received: (from wcolburn@localhost) by icewing.nmt.edu (8.12.8/8.12.8/Submit) id i9LGjmOf020469 for freebsd-net@freebsd.org; Thu, 21 Oct 2004 10:45:48 -0600 Date: Thu, 21 Oct 2004 10:45:48 -0600 From: "William D. Colburn (aka Schlake)" To: freebsd-net@freebsd.org Message-ID: <20041021164548.GA20454@nmt.edu> References: <20041021145654.GA19657@nmt.edu> <20041021163601.GA88117@proxy.netroad.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041021163601.GA88117@proxy.netroad.ru> User-Agent: Mutt/1.4.2.1i Subject: Re: 9 second ping lag unless I run tcpdump on RELENG_5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 16:45:50 -0000 I've been running 5.3 for over a month now. I only noticed this after 5.3-RELEASE came out. It could be the card, I'll try to swap it and see what happens. On Thu, Oct 21, 2004 at 08:36:01PM +0400, Lenar D. Tukhvatullin wrote: >Date: Thu, 21 Oct 2004 20:36:01 +0400 >From: "Lenar D. Tukhvatullin" >To: "William D. Colburn (aka Schlake)" >Cc: freebsd-net@freebsd.org >Subject: Re: 9 second ping lag unless I run tcpdump on RELENG_5 > >On Thu, Oct 21, 2004 at 08:56:54AM -0600, William D. Colburn (aka Schlake) wrote: >> I have a RELENG_5 box on my desk. Unless I run the tcpdump program, it >> responds progressively slower on the network. This seemed like the most >> appropriate list to post this question too. >> >> This morning, for instance, it had a 9 second ping response time from a >> machine on the same network segment as it when I came into work. As >> soon as I typed 'tcpdump' on the freebsd box the ping time dropped to >> nearly instantaneous. I killed tcpdump and let it run for a while. >> About a thousand seconds later it suddenly jumped to 1 second, then to 2 >> seconds. As soon as I ran tcpdump again it dropped back to normal. >> >> The uname ids it as 5.3-STABLE #14: Wed Oct 20 10:23:11 UTC 2004, >> with a GENERIC kernel. I did a new cvsup (along with a tcpdump because >> otherwise cvsup fails) this morning and nothing new came across. > >tcpdump (by default) puts interface into promiscuous mode. >(or you can set this mode by hand: ifconfig promisc) > >Maybe your ethernet card broken? Try to replace it. > >-- >Lenar D. Tukhvatullin >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- William Colburn, "Sysprog" Computer Center, New Mexico Institute of Mining and Technology http://www.nmt.edu/tcc/ http://www.nmt.edu/~wcolburn From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 17:31:47 2004 Return-Path: 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 265DE16A4CF; Thu, 21 Oct 2004 17:31:47 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id B254D43D49; Thu, 21 Oct 2004 17:31:46 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i9LHVkag092966; Thu, 21 Oct 2004 10:31:46 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 1AE6477A9D0; Thu, 21 Oct 2004 13:31:45 -0400 (EDT) To: Andre Oppermann From: Mark Allman In-Reply-To: <4177C8AD.6060706@freebsd.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lights MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Oct 2004 13:31:45 -0400 Sender: mallman@icir.org Message-Id: <20041021173145.1AE6477A9D0@guns.icir.org> cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 17:31:47 -0000 --=-=-= Content-Type: text/plain > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: Yeah, I think that makes a bunch of sense. > Thus after the removal of T/TCP for the reasons above I want to provide > a work-alike replacement for T/TCP's functionality: I haven't fully digested this yet. But, I'll voice my distaste for implementing things that just seem to "Make Sense". That's a model that has been used and is used by other operating systems and those of us who watch packets can attest that things that "Make Sense" often don't and likely would have benefitted by a bit more thought and a bit more vetting. I would be happier if something like this were vetted out a bit more (written up, digested by folks, etc.) before it went into anything but someone's experimental kernel. Just my two cents. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBd/KBWyrrWs4yIs4RAg2gAJ9xlUCP//uGpoOA7LI2d7DINHVz3gCfR1bP jaMNH+4vOnCC06DHV7tU930= =UPzK -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 17:57:04 2004 Return-Path: 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 82E9F16A4CF for ; Thu, 21 Oct 2004 17:57:04 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94C1243D53 for ; Thu, 21 Oct 2004 17:57:03 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79111 invoked from network); 21 Oct 2004 17:55:39 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 17:55:39 -0000 Message-ID: <4177F875.2822A51E@freebsd.org> Date: Thu, 21 Oct 2004 19:57:09 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mallman@icir.org References: <20041021173145.1AE6477A9D0@guns.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 17:57:04 -0000 Mark Allman wrote: > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > I haven't fully digested this yet. But, I'll voice my distaste for > implementing things that just seem to "Make Sense". That's a model that > has been used and is used by other operating systems and those of us who > watch packets can attest that things that "Make Sense" often don't and > likely would have benefitted by a bit more thought and a bit more > vetting. I would be happier if something like this were vetted out a > bit more (written up, digested by folks, etc.) before it went into > anything but someone's experimental kernel. Just my two cents. Sure. To make you sleep better it will be disabled by default (like T/TCP) and possibly even not compliled in by default (#ifdef'd). If enabled and compiled in it does not automatically enable itself for all and everything. The application has to enable it on the socket as well. A writeup will follow once I get there. I made this request before I start working on it to prevent to waste my time on it if people wanted to religiously stick to T/TCP. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 18:08:08 2004 Return-Path: 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 57B9916A4CE for ; Thu, 21 Oct 2004 18:08:08 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28FDD43D2D for ; Thu, 21 Oct 2004 18:08:08 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id B219754A7; Thu, 21 Oct 2004 11:08:07 -0700 (PDT) To: Julian Elischer In-reply-to: Your message of Wed, 20 Oct 2004 14:37:57 -0700. <4176DAB5.5020302@elischer.org> Date: Thu, 21 Oct 2004 11:08:07 -0700 Message-ID: <92904.1098382087@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org cc: Igor Sysoev Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:08:08 -0000 In message <4176DAB5.5020302@elischer.org>, you wrote: >Now that we have real threads, it shuld be possible to write an aio >library that is > implemented by having a bunch of underlying threads.. That's a very interesting idea. Whan you say ``Now that we have real threads...'' I assume that you are talking about the 5.x releases, correct? From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 18:19:12 2004 Return-Path: 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 9283216A4CE for ; Thu, 21 Oct 2004 18:19:12 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1287743D58 for ; Thu, 21 Oct 2004 18:19:08 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id CEAA57A403; Thu, 21 Oct 2004 11:19:07 -0700 (PDT) Message-ID: <4177FD9B.8010805@elischer.org> Date: Thu, 21 Oct 2004 11:19:07 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Igor Sysoev References: <49035.1098044385@monkeys.com> <20041020233952.V17688@is.park.rambler.ru> <4176DAB5.5020302@elischer.org> <20041021095322.Y17688@is.park.rambler.ru> In-Reply-To: <20041021095322.Y17688@is.park.rambler.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: "Ronald F. Guilmette" Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:19:12 -0000 I meant under 5.3, we could implement aio as a part of the library and have it create per process kernel threads to go do all the work.. (hiding this from the user) Igor Sysoev wrote: >On Wed, 20 Oct 2004, Julian Elischer wrote: > > > >>Now that we have real threads, it shuld be possible to write an aio >>library that is >> implemented by having a bunch of underlying threads.. >> >> > >Do you mean the kernel only threads when the single threaded user process >has several threads in kernel ? As I understand FreeBSD 4.x already >has similar AIO implementation. > >Or do you mean the implementaion by user-level threads like in Solaris ? > > >Igor Sysoev >http://sysoev.ru/en/ > > From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 18:31:42 2004 Return-Path: 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 6A7B716A4CE; Thu, 21 Oct 2004 18:31:42 +0000 (GMT) Received: from skippyii.compar.com (test.compar.com [216.208.38.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE09143D2F; Thu, 21 Oct 2004 18:31:41 +0000 (GMT) (envelope-from matt@gsicomp.on.ca) Received: from hermes (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185])i9LIc4cW051189; Thu, 21 Oct 2004 14:38:05 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <00e901c4b79b$d13e6e40$1200a8c0@gsicomp.on.ca> From: "Matt Emmerton" To: "Andre Oppermann" , "Bruce M Simpson" References: <4177C8AD.6060706@freebsd.org><20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> Date: Thu, 21 Oct 2004 14:28:50 -0400 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:31:42 -0000 > Bruce M Simpson wrote: > > > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > > Thus after the removal of T/TCP for the reasons above I want to provide > > > a work-alike replacement for T/TCP's functionality: > > > > I disagree. I think the time spent here would be better spent on working > > on an import of SCTP into the kernel, perhaps the KAME code base would > > be a good starting point. > > Is the SCTP in KAME complete and stable? Are there any other (open source) > implementations of it? The SCTP home page (www.sctp.org) has a list of implementations. Note that I had to use Google's cache of the site -- I believe there was a Slashdot article on SCTP this morning which may have taken down the site. AIX, Solaris, HP and Cisco all support SCTP in their latest OS versions. There are aslo a few different (non-free) implementations for Windows, and at least one open-source implementation for Linux (http://www.openss7.org) -- Matt Emmerton From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 18:32:40 2004 Return-Path: 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 849FA16A4CE; Thu, 21 Oct 2004 18:32:40 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69B3743D4C; Thu, 21 Oct 2004 18:32:40 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i9LIWdag093598; Thu, 21 Oct 2004 11:32:39 -0700 (PDT) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 00E8977A9D0; Thu, 21 Oct 2004 14:32:38 -0400 (EDT) To: Andre Oppermann From: Mark Allman In-Reply-To: <4177F875.2822A51E@freebsd.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Lights MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Oct 2004 14:32:37 -0400 Sender: mallman@icir.org Message-Id: <20041021183238.00E8977A9D0@guns.icir.org> cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:32:40 -0000 --=-=-= Content-Type: text/plain > Sure. To make you sleep better it will be disabled by default (like > T/TCP) and possibly even not compliled in by default (#ifdef'd). Part of your argument against T/TCP. :-) > A writeup will follow once I get there. I made this request before I > start working on it to prevent to waste my time on it if people wanted > to religiously stick to T/TCP. I think moving on from T/TCP is fine, don't get me wrong. And, I am all for seeing new schemes that buy us some of the things T/TCP was designed for. I am just not enthusiastic about dumping things into the kernel without some review and thought (by more than one person; and, that is not a knock on you --- if I had a nickel for every half-baked thing I'd implemented somewhere .... basically, it's good to get different perspectives). Doing this in a systematic way may have benefits beyond FreeBSD, as well, of course. allman --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFBeADFWyrrWs4yIs4RAuRpAJ97dKby5KS6sJKaDupU8s4OU7/1rQCfURgQ qF+ji12qxOfWn09/Xu92sxg= =MK6u -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 18:51:39 2004 Return-Path: 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 1104716A4CE; Thu, 21 Oct 2004 18:51:39 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF6AF43D41; Thu, 21 Oct 2004 18:51:38 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id i9LIpcVc037579; Thu, 21 Oct 2004 11:51:38 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i9LIpcpO037578; Thu, 21 Oct 2004 11:51:38 -0700 (PDT) (envelope-from obrien) Date: Thu, 21 Oct 2004 11:51:37 -0700 From: "David O'Brien" To: Andre Oppermann Message-ID: <20041021185137.GA37500@dragon.nuxi.com> References: <4177C8AD.6060706@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4177C8AD.6060706@freebsd.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:51:39 -0000 On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > I intend to remove T/TCP (transactional TCP) support from our TCP > implementation for the following reasons: .. Fine. > Thus after the removal of T/TCP for the reasons above I want to provide > a work-alike replacement for T/TCP's functionality: .. > This different implementation will be disabled by default and clearly > marked EXPERIMENTAL in a protocol sense. It will allow the only known > user of T/TCP to keep the same functionality with a very small change > to his application. It allows interesting new uses primarily in > Intranet environment where many short connections are openend in rapid > succession (LDAP servers, SQL servers, etc.). The modifications to > those programs to use the new option is minimal and requires only the > setting of the socket option, one setsockopt() call. I'm not so happy with a FreeBSD-only "proprietary" thing. Is there any proposed RFC work that provides the qualities you want? The advantage with T/TCP is that there was a published standard. -- -- David (obrien@FreeBSD.org) From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 18:58:59 2004 Return-Path: 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 47AD716A4CE; Thu, 21 Oct 2004 18:58:59 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F26343D39; Thu, 21 Oct 2004 18:58:59 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 126667A424; Thu, 21 Oct 2004 11:58:59 -0700 (PDT) Message-ID: <417806F2.50607@elischer.org> Date: Thu, 21 Oct 2004 11:58:58 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Andre Oppermann References: <20041021173145.1AE6477A9D0@guns.icir.org> <4177F875.2822A51E@freebsd.org> In-Reply-To: <4177F875.2822A51E@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org cc: mallman@icir.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 18:58:59 -0000 Andre Oppermann wrote: >Mark Allman wrote: > > >>>Thus after the removal of T/TCP for the reasons above I want to provide >>>a work-alike replacement for T/TCP's functionality: >>> >>> >>I haven't fully digested this yet. But, I'll voice my distaste for >>implementing things that just seem to "Make Sense". That's a model that >>has been used and is used by other operating systems and those of us who >>watch packets can attest that things that "Make Sense" often don't and >>likely would have benefitted by a bit more thought and a bit more >>vetting. I would be happier if something like this were vetted out a >>bit more (written up, digested by folks, etc.) before it went into >>anything but someone's experimental kernel. Just my two cents. >> >> > >Sure. To make you sleep better it will be disabled by default (like >T/TCP) and possibly even not compliled in by default (#ifdef'd). If >enabled and compiled in it does not automatically enable itself for all >and everything. The application has to enable it on the socket as well. > >A writeup will follow once I get there. I made this request before I >start working on it to prevent to waste my time on it if people wanted >to religiously stick to T/TCP. > > couldn't you do it with a spoofing interface? i.e. tcp sessions going through get turned into something that loks like ttcp on the wire and converted back at teh other end? From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 19:01:59 2004 Return-Path: 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 1091B16A4CE; Thu, 21 Oct 2004 19:01:59 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAA6443D53; Thu, 21 Oct 2004 19:01:58 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i9LJ1vqw028422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Thu, 21 Oct 2004 15:01:57 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i9LJ1u28028419; Thu, 21 Oct 2004 15:01:56 -0400 (EDT) (envelope-from wollman) Date: Thu, 21 Oct 2004 15:01:56 -0400 (EDT) From: Garrett Wollman Message-Id: <200410211901.i9LJ1u28028419@khavrinen.lcs.mit.edu> To: freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <20041021185137.GA37500@dragon.nuxi.com> References: <4177C8AD.6060706@freebsd.org> <20041021185137.GA37500@dragon.nuxi.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:01:59 -0000 < said: > I'm not so happy with a FreeBSD-only "proprietary" thing. Is there any > proposed RFC work that provides the qualities you want? The advantage > with T/TCP is that there was a published standard. T/TCP was a published *non*standard, loudly blazoned "EXPERIMENTAL". I don't see how Andre's proposed replacement can be any worse. -GAWollman From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 19:03:12 2004 Return-Path: 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 A4F0816A4CE for ; Thu, 21 Oct 2004 19:03:12 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D724543D69 for ; Thu, 21 Oct 2004 19:03:11 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79741 invoked from network); 21 Oct 2004 19:01:47 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 19:01:47 -0000 Message-ID: <417807F5.AE550647@freebsd.org> Date: Thu, 21 Oct 2004 21:03:17 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org References: <4177C8AD.6060706@freebsd.org> <20041021185137.GA37500@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:03:12 -0000 David O'Brien wrote: > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > .. > > This different implementation will be disabled by default and clearly > > marked EXPERIMENTAL in a protocol sense. It will allow the only known > > user of T/TCP to keep the same functionality with a very small change > > to his application. It allows interesting new uses primarily in > > Intranet environment where many short connections are openend in rapid > > succession (LDAP servers, SQL servers, etc.). The modifications to > > those programs to use the new option is minimal and requires only the > > setting of the socket option, one setsockopt() call. > > I'm not so happy with a FreeBSD-only "proprietary" thing. Is there any > proposed RFC work that provides the qualities you want? The advantage > with T/TCP is that there was a published standard. Not for TCP. There are plenty of proposed or approved replacements for TCP though. Implementing or importing them is a lot harder and applications wanting to use it have to be extensively modified. The nice thing of my proposed replacement is its simplicity. Submitting an RFC draft for that is not hard and I'm going to do it based on the feedback I've got so far. I think we can enough drive behind this to make it an actual published RFC standard. Don't worry. I don't want to remove one intrusive piece of code just to replace it with another one. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 19:04:56 2004 Return-Path: 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 E0BD316A4CF for ; Thu, 21 Oct 2004 19:04:56 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19AE043D6A for ; Thu, 21 Oct 2004 19:04:56 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79777 invoked from network); 21 Oct 2004 19:03:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 19:03:31 -0000 Message-ID: <4178085D.898E981D@freebsd.org> Date: Thu, 21 Oct 2004 21:05:01 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: <20041021173145.1AE6477A9D0@guns.icir.org> <4177F875.2822A51E@freebsd.org> <417806F2.50607@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org cc: mallman@icir.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:04:57 -0000 Julian Elischer wrote: > > Andre Oppermann wrote: > > >Mark Allman wrote: > > > > > >>>Thus after the removal of T/TCP for the reasons above I want to provide > >>>a work-alike replacement for T/TCP's functionality: > >>> > >>> > >>I haven't fully digested this yet. But, I'll voice my distaste for > >>implementing things that just seem to "Make Sense". That's a model that > >>has been used and is used by other operating systems and those of us who > >>watch packets can attest that things that "Make Sense" often don't and > >>likely would have benefitted by a bit more thought and a bit more > >>vetting. I would be happier if something like this were vetted out a > >>bit more (written up, digested by folks, etc.) before it went into > >>anything but someone's experimental kernel. Just my two cents. > >> > >> > > > >Sure. To make you sleep better it will be disabled by default (like > >T/TCP) and possibly even not compliled in by default (#ifdef'd). If > >enabled and compiled in it does not automatically enable itself for all > >and everything. The application has to enable it on the socket as well. > > > >A writeup will follow once I get there. I made this request before I > >start working on it to prevent to waste my time on it if people wanted > >to religiously stick to T/TCP. > > > > > > couldn't you do it with a spoofing interface? > i.e. tcp sessions going through get turned into something that loks like > ttcp > on the wire and converted back at teh other end? You failed the FUD test at the bottom of my email. -- Andre From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 19:13:24 2004 Return-Path: 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 E5D2B16A4CF for ; Thu, 21 Oct 2004 19:13:24 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id B301643D55 for ; Thu, 21 Oct 2004 19:13:24 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id EC6A654AC; Thu, 21 Oct 2004 12:13:23 -0700 (PDT) To: Igor Sysoev In-reply-to: Your message of Thu, 21 Oct 2004 09:37:07 +0400. <20041021091935.K17688@is.park.rambler.ru> Date: Thu, 21 Oct 2004 12:13:23 -0700 Message-ID: <93418.1098386003@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:13:25 -0000 In message <20041021091935.K17688@is.park.rambler.ru>, you wrote: >I believe if you want to build a more maintainable, more adaptable, >more modularized program then you should avoid two things - the threads and >the signals. If you like to use a callback behaviour of the signals you could >easy implement it without any signal. OK. I'll bite. How? From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 19:34:23 2004 Return-Path: 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 D5E9316A4CE; Thu, 21 Oct 2004 19:34:23 +0000 (GMT) Received: from www.citello.it (host170-131.pool80117.interbusiness.it [80.117.131.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1793443D2D; Thu, 21 Oct 2004 19:34:21 +0000 (GMT) (envelope-from molter@tin.it) Received: from gattaccio.codalunga (ANice-205-1-12-243.w81-248.abo.wanadoo.fr [81.248.122.243]) by www.citello.it (Postfix) with ESMTP id 6CD091559; Thu, 21 Oct 2004 21:34:27 +0200 (CEST) Received: by gattaccio.codalunga (Postfix, from userid 1001) id 140EDC117; Thu, 21 Oct 2004 21:32:49 +0200 (CEST) Date: Thu, 21 Oct 2004 21:32:48 +0200 From: Marco Molteni To: Andre Oppermann Message-Id: <20041021213248.223cab2c.molter@tin.it> In-Reply-To: <4177E25E.804639E@freebsd.org> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 19:34:24 -0000 On Thu, 21 Oct 2004 Andre Oppermann wrote: > Bruce M Simpson wrote: > > > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > > Thus after the removal of T/TCP for the reasons above I want to > > > provide a work-alike replacement for T/TCP's functionality: > > > > I disagree. I think the time spent here would be better spent on > > working on an import of SCTP into the kernel, perhaps the KAME code > > base would be a good starting point. > > Is the SCTP in KAME complete and stable? Are there any other (open > source) implementations of it? SCTP in KAME is complete, stable and fully supported. It is mainly developed by the SCTP RFC author, Randall Stewart. A T/TCP alternative as you are describing sounds very similar to PR-SCTP (Partial Reliability SCTP). (Don't let the name fool you, please read the internet draft). There is at least another kernel-level open source implementation, for Linux, plus other user-level implementations. marco -- panic("The moon has moved again."); From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 21:36:51 2004 Return-Path: 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 6626D16A4CF; Thu, 21 Oct 2004 21:36:51 +0000 (GMT) Received: from smtp1.jazztel.es (smtp1.jazztel.es [62.14.3.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9629143D46; Thu, 21 Oct 2004 21:36:50 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from antivirus by smtp1.jazztel.es with antivirus id 1CKkcL-00015x-00 Thu, 21 Oct 2004 23:37:05 +0200 Received: from [212.106.236.249] (helo=rguez.homeunix.net) by smtp1.jazztel.es with esmtp id 1CKkcL-000155-00 Thu, 21 Oct 2004 23:37:05 +0200 Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) by rguez.homeunix.net (8.13.1/8.13.1) with ESMTP id i9LLal6i056546; Thu, 21 Oct 2004 23:36:47 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.1/8.13.1/Submit) id i9LLamqO001012; Thu, 21 Oct 2004 23:36:48 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) X-Authentication-Warning: orion.redesjm.local: freebsd set sender to josemi@freebsd.jazztel.es using -f From: Jose M Rodriguez To: current@freebsd.org Date: Thu, 21 Oct 2004 23:36:47 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410212336.47914.josemi@freebsd.jazztel.es> X-AntiVirus: checked by AntiVir Milter 1.1-beta; AVE 6.28.0.7; VDF 6.28.0.24 (host: antares.redesjm.local) X-Virus-Scanned: by antivirus cc: net@freebsd.org Subject: still problems closing TCP(ftp) streams X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 21:36:51 -0000 Hi, This is latest RELENG_5_3 I still have problems closing tcp (mainly ftp) streams, but can't see any special. This is at home. adsl router (pppoa, mtu/mru 1500), doing NAPT. local net working great. Linux and Windows working well. no time/stream pattern observed. Can anyone see something strange in this tcpdump output? It is hang at ftp stream closing. thanks, -- josemi 23:18:34.615860 IP (tos 0x0, ttl 64, id 53638, offset 0, flags [DF], length: 58) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: P [tcp sum ok] 336:342(6)ack 3473 win 33304 23:18:34.664133 IP (tos 0x0, ttl 53, id 64936, offset 0, flags [DF], length: 100) zeppo.rediris.es.ftp > antares.redesjm.local.53853: P 3473:3521(48) ack 342 win 24616 23:18:34.664483 IP (tos 0x0, ttl 64, id 60305, offset 0, flags [DF], length: 64) antares.redesjm.local.57291 > zeppo.rediris.es.48994: S [tcp sum ok] 3275417208:3275417208(0) win 65535 23:18:34.712948 IP (tos 0x0, ttl 57, id 64937, offset 0, flags [DF], length: 64) zeppo.rediris.es.48994 > antares.redesjm.local.57291: S [tcp sum ok] 3492715774:3492715774(0) ack 3275417209 win 24616 23:18:34.713048 IP (tos 0x0, ttl 64, id 25778, offset 0, flags [DF], length: 52) antares.redesjm.local.57291 > zeppo.rediris.es.48994: . [tcp sum ok] 1:1(0) ack 1 win 33304 23:18:34.713206 IP (tos 0x0, ttl 64, id 54756, offset 0, flags [DF], length: 58) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: P [tcp sum ok] 342:348(6)ack 3521 win 33304 23:18:34.765188 IP (tos 0x0, ttl 53, id 64938, offset 0, flags [DF], length: 82) zeppo.rediris.es.ftp > antares.redesjm.local.53853: P [tcp sum ok] 3521:3551(30) ack 348 win 24616 23:18:34.769997 IP (tos 0x8, ttl 57, id 64939, offset 0, flags [DF], length: 427) zeppo.rediris.es.48994 > antares.redesjm.local.57291: P 1:376(375) ack 1 win24616 23:18:34.770505 IP (tos 0x8, ttl 57, id 64940, offset 0, flags [DF], length: 52) zeppo.rediris.es.48994 > antares.redesjm.local.57291: F [tcp sum ok] 376:376(0) ack 1 win 24616 23:18:34.770606 IP (tos 0x0, ttl 64, id 26519, offset 0, flags [DF], length: 52) antares.redesjm.local.57291 > zeppo.rediris.es.48994: . [tcp sum ok] 1:1(0) ack 377 win 33304 23:18:34.771493 IP (tos 0x0, ttl 64, id 38399, offset 0, flags [DF], length: 52 ) antares.redesjm.local.57291 > zeppo.rediris.es.48994: F [tcp sum ok] 1:1(0) ack 377 win 33304 23:18:34.823060 IP (tos 0x8, ttl 57, id 64941, offset 0, flags [DF], length: 52) zeppo.rediris.es.48994 > antares.redesjm.local.57291: . [tcp sum ok] 377:377(0) ack 2 win 24616 23:18:34.856005 IP (tos 0x0, ttl 64, id 13732, offset 0, flags [DF], length: 52) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: . [tcp sum ok] 348:348(0)ack 3551 win 33304 23:18:34.902684 IP (tos 0x0, ttl 53, id 64942, offset 0, flags [DF], length: 105) zeppo.rediris.es.ftp > antares.redesjm.local.53853: P 3551:3604(53) ack 348 win 24616 23:18:34.904000 IP (tos 0x0, ttl 64, id 40099, offset 0, flags [DF], length: 58) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: P [tcp sum ok] 348:354(6)ack 3604 win 33304 23:18:34.954132 IP (tos 0x0, ttl 53, id 64943, offset 0, flags [DF], length: 101) zeppo.rediris.es.ftp > antares.redesjm.local.53853: P 3604:3653(49) ack 354 win 24616 23:18:34.954477 IP (tos 0x0, ttl 64, id 54766, offset 0, flags [DF], length: 64) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 23:18:35.045985 IP (tos 0x0, ttl 64, id 54734, offset 0, flags [DF], length: 52) antares.redesjm.local.53853 > zeppo.rediris.es.ftp: . [tcp sum ok] 354:354(0)ack 3653 win 33304 23:18:37.946156 IP (tos 0x0, ttl 64, id 51670, offset 0, flags [DF], length: 64) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 23:18:41.146258 IP (tos 0x0, ttl 64, id 17586, offset 0, flags [DF], length: 64) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 23:18:44.346350 IP (tos 0x0, ttl 64, id 35811, offset 0, flags [DF], length: 48) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 23:18:47.546497 IP (tos 0x0, ttl 64, id 30435, offset 0, flags [DF], length: 48) antares.redesjm.local.61346 > zeppo.rediris.es.35835: S [tcp sum ok] 3860012610:3860012610(0) win 65535 From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 21:43:18 2004 Return-Path: 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 26FD216A4D9; Thu, 21 Oct 2004 21:43:18 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C20B043D41; Thu, 21 Oct 2004 21:43:17 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i9LLh2vT033772; Thu, 21 Oct 2004 17:43:02 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i9LLh2hM033769; Thu, 21 Oct 2004 17:43:02 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 21 Oct 2004 17:43:01 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: gnn@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Locking fixes to IPv6 scope6.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 21:43:18 -0000 On Sat, 16 Oct 2004 gnn@freebsd.org wrote: > @@ -71,12 +71,14 @@ > scope6_ifattach(ifp) > struct ifnet *ifp; > { > - int s = splnet(); > + > struct scope6_id *sid; > > sid = (struct scope6_id *)malloc(sizeof(*sid), M_IFADDR, M_WAITOK); > bzero(sid, sizeof(*sid)); > > + IFNET_WLOCK(); > + > /* > * XXX: IPV6_ADDR_SCOPE_xxx macros are not standard. > * Should we rather hardcode here? I notice that the comments indicate that you acquire the ifnet list lock to prevent the ifnet from going away; however, the caller passes in an ifnet pointer. Shouldn't it be the responsibility of the caller to make sure the ifnet doesn't go away, or it could go away before you could aquire the lock? I.e., either by virtue of the ifnet life cycle, or by virtue of the caller locking the list and these functions asserting it? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 23:18:03 2004 Return-Path: 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 2082F16A4CE for ; Thu, 21 Oct 2004 23:18:03 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 745B543D55 for ; Thu, 21 Oct 2004 23:18:02 +0000 (GMT) (envelope-from juan.fco.rodriguez@gmail.com) Received: by rproxy.gmail.com with SMTP id 74so88972rnk for ; Thu, 21 Oct 2004 16:18:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=QHz+T70M8pu90sFWH8DSWvWyXrACEq6Gtt4QjIAFzCpk8aGe353i2SS+K18BtNVKiev9NLeGxb44x7A0fdkOu+eDR/CuRTHs2SFc0dxPdzYxXSOW3+EIvsUhkG4VcOGx2dnYZ7XjrxXDfJliCWFXLLIAhERoh6SUMy3xQjfle6g= Received: by 10.38.151.68 with SMTP id y68mr3366551rnd; Thu, 21 Oct 2004 16:17:35 -0700 (PDT) Received: by 10.38.102.43 with HTTP; Thu, 21 Oct 2004 16:17:29 -0700 (PDT) Message-ID: <96b30c400410211617466e7ea9@mail.gmail.com> Date: Fri, 22 Oct 2004 00:17:29 +0100 From: Juan Rodriguez To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: if_ed.c "NIC memory corrupt - invalid packet length" error X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Juan Rodriguez List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 23:18:03 -0000 Hello, I'm getting this error now and then, so I've tried to look at the file "if_ed.c" where the message is printed to sort it out... I'd be glad if somebody could tell me what's the reason of this line inside "ed_rint()" function: /* * because buffers are aligned on 256-byte boundary, * the length computed above is off by 256 in almost * all cases. Fix it... */ if (len & 0xff) len -= 256 ; I wonder what can happen here if we've got a length value that is less than 256. We could end up with a negative value... could it be this the source that causes the problem ? PS: I'm kinda newbie so I might be saying stupid things! :) Thanks From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 23:23:26 2004 Return-Path: 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 2B60916A4D7 for ; Thu, 21 Oct 2004 23:23:26 +0000 (GMT) Received: from server.frh.utn.edu.ar (server.frh.utn.edu.ar [170.210.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64D7343D48 for ; Thu, 21 Oct 2004 23:23:23 +0000 (GMT) (envelope-from fernando@gont.com.ar) Received: (qmail 9112 invoked from network); 21 Oct 2004 23:22:14 -0000 Received: from customer68-118-58.iplannetworks.net (HELO fernando.gont.com.ar) (gont-fernando@200.68.118.58) by server.frh.utn.edu.ar with SMTP; 21 Oct 2004 23:22:14 -0000 Message-Id: <4.3.2.7.2.20041021195220.00d5a9b0@pop.gmx.net> X-Sender: gont-fernando@server.frh.utn.edu.ar X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Oct 2004 20:32:17 -0300 To: Andre Oppermann From: Fernando Gont In-Reply-To: <4177BC49.73B6D910@freebsd.org> References: <4.3.2.7.2.20041021044818.00d5a560@server.frh.utn.edu.ar> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: freebsd-net@freebsd.org Subject: Re: tcp_notify() and the connection establishment timer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 23:23:26 -0000 At 15:40 21/10/2004 +0200, Andre Oppermann wrote: > > Maybe I'm missing something, but I get the impression that, considering the > > value (six seconds) to which the RTO is initialized, that part that says > > > > } else if (tp->t_state < TCPS_ESTABLISHED && tp->t_rxtshift > 3 && > > tp->t_softerror) { > > tcp_drop(tp, error); > > return (struct inpcb *)0; > > > > will never be executed, as the connection-establishment timer will always > > timeout before the evaluated condition becomes true. > > > > Am I missing something? Or is it that this code is there just in case the > > initial RTO is reduced to such a value that, in that case, this code would > > kick in before the 75-seconds tconnection-establishment timer? > >Yes, tcp_notify() gets called from icmp_input() when ICMP unreachable or >related error messages from the network are received. In those cases >you don't want to wait the full 75 seconds because the network tells >you that a connection cannot be established to that destination. It >doesn't do that the first time the network tells us that to avoid too >fast reaction on spurious network problems, outages or re-routings. I'd agree with this idea. However, my point is that, given the initial RTO of 6 seconds, the 75-second timer will always expire before the connection is aborted due to the received ICMP error messages. That is, either the connection-establishment timer should be set to a larger value, or else fewer retransmissions and fewer ICMP errors should be required to abort a connection. If you have a copy of Stevens' TCPv2 at hand, there's a diagram on page 828 that shows this. The 75-second timer will expire *before* tx->t_rxtshift > 3. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 23:27:48 2004 Return-Path: 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 3875416A4CE for ; Thu, 21 Oct 2004 23:27:48 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2189243D2D for ; Thu, 21 Oct 2004 23:27:48 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id i9LNRlBQ058455; Thu, 21 Oct 2004 16:27:47 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id i9LNRl9V058454; Thu, 21 Oct 2004 16:27:47 -0700 (PDT) (envelope-from rizzo) Date: Thu, 21 Oct 2004 16:27:47 -0700 From: Luigi Rizzo To: Juan Rodriguez Message-ID: <20041021162747.A58326@xorpc.icir.org> References: <96b30c400410211617466e7ea9@mail.gmail.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: <96b30c400410211617466e7ea9@mail.gmail.com>; from juan.fco.rodriguez@gmail.com on Fri, Oct 22, 2004 at 12:17:29AM +0100 cc: freebsd-net@freebsd.org Subject: Re: if_ed.c "NIC memory corrupt - invalid packet length" error X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 23:27:48 -0000 On Fri, Oct 22, 2004 at 12:17:29AM +0100, Juan Rodriguez wrote: > Hello, > > I'm getting this error now and then, so I've tried to look at the > file "if_ed.c" where the message is printed to sort it out... most of the time the message is because of a runt packet, or a residue of some collision, or the like. I'd probably just comment out the printf() if it bothers you. > I'd be glad if somebody could tell me what's the reason of this line > inside "ed_rint()" function: > > /* > * because buffers are aligned on 256-byte boundary, > * the length computed above is off by 256 in almost > * all cases. Fix it... > */ > if (len & 0xff) > len -= 256 ; > > I wonder what can happen here if we've got a length value well because the comment refers to the code above, you should supply that as well or there is nothing we can comment about. Apart from that, i vaguely remember having touched this part of the code and it was taking care of bugs in the NIC which at times would compute a wrong length. In any case it is mostly unrelated to the above which has an easier explaination cheers luigi > that is less than 256. We could end up with a negative value... > could it be this the source that causes the problem ? > > PS: I'm kinda newbie so I might be saying stupid things! :) > Thanks > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Oct 21 23:38:51 2004 Return-Path: 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 6A24D16A506 for ; Thu, 21 Oct 2004 23:38:48 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5BB943D2F for ; Thu, 21 Oct 2004 23:38:47 +0000 (GMT) (envelope-from juan.fco.rodriguez@gmail.com) Received: by rproxy.gmail.com with SMTP id 73so109266rnk for ; Thu, 21 Oct 2004 16:38:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hr1qgSwcp8Gk+s8YGnXtYfLptCgqQK4L227ZG4c3T+a0HgZ+9Kiw1d0PtnaMy/YFLRyesbztsJdM4VPcguO2+SYc55Aguy40dwguyUbDGpwafyOnEdnnklS3uz/kVfi5LHj9KhhmXlPRyN55bdZ0gXUjfrO9BvSfSgAniG2Fwxc= Received: by 10.38.152.39 with SMTP id z39mr3387523rnd; Thu, 21 Oct 2004 16:38:47 -0700 (PDT) Received: by 10.38.102.43 with HTTP; Thu, 21 Oct 2004 16:38:47 -0700 (PDT) Message-ID: <96b30c40041021163876b809d4@mail.gmail.com> Date: Fri, 22 Oct 2004 00:38:47 +0100 From: Juan Rodriguez To: freebsd-net@freebsd.org In-Reply-To: <20041021162747.A58326@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <96b30c400410211617466e7ea9@mail.gmail.com> <20041021162747.A58326@xorpc.icir.org> Subject: Re: if_ed.c "NIC memory corrupt - invalid packet length" error X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Juan Rodriguez List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 23:38:51 -0000 On Thu, 21 Oct 2004 16:27:47 -0700, Luigi Rizzo wrote: > On Fri, Oct 22, 2004 at 12:17:29AM +0100, Juan Rodriguez wrote: > > Hello, > > > > I'm getting this error now and then, so I've tried to look at the > > file "if_ed.c" where the message is printed to sort it out... > > most of the time the message is because of a runt packet, or > a residue of some collision, or the like. I'd probably just > comment out the printf() if it bothers you. > > > I'd be glad if somebody could tell me what's the reason of this line > > inside "ed_rint()" function: > > > > /* > > * because buffers are aligned on 256-byte boundary, > > * the length computed above is off by 256 in almost > > * all cases. Fix it... > > */ > > if (len & 0xff) > > len -= 256 ; > > > > I wonder what can happen here if we've got a length value > > well because the comment refers to the code above, you should > supply that as well or there is nothing we can comment about. > Apart from that, i vaguely remember having touched this part > of the code and it was taking care of bugs in the NIC which > at times would compute a wrong length. In any case it is mostly > unrelated to the above which has an easier explaination > > cheers > luigi > Ok, I was expecting that you all would look at the source file, it's a pain for me to copy/paste souce code here: if (len > (ETHER_MAX_LEN - ETHER_CRC_LEN + sizeof(struct ed_ring)) || len < (ETHER_MIN_LEN - ETHER_CRC_LEN + sizeof(struct ed_ring))) { /* * Length is a wild value. There's a good chance that * this was caused by the NIC being old and buggy. * The bug is that the length low byte is duplicated in * the high byte. Try to recalculate the length based on * the pointer to the next packet. */ /* * NOTE: sc->next_packet is pointing at the current packet. */ len &= ED_PAGE_SIZE - 1; /* preserve offset into page */ if (packet_hdr.next_packet >= sc->next_packet) { len += (packet_hdr.next_packet - sc->next_packet) * ED_PAGE_SIZE; } else { len += ((packet_hdr.next_packet - sc->rec_page_start) + (sc->rec_page_stop - sc->next_packet)) * ED_PAGE_SIZE; } /* * because buffers are aligned on 256-byte boundary, * the length computed above is off by 256 in almost * all cases. Fix it... */ if (len & 0xff) len -= 256 ; I hope it's clearer now, but Im still got the doubt about what would happen if we've got, e.g., len = 120 and we do len -= 256, isn't this a possible bug ? Thanks From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 01:47:01 2004 Return-Path: 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 A308816A4CE; Fri, 22 Oct 2004 01:47:01 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 745D043D2D; Fri, 22 Oct 2004 01:47:01 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (rwcrmhc12) with ESMTP id <20041022014700014004od4ue>; Fri, 22 Oct 2004 01:47:00 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) i9M1l8Qx045714; Thu, 21 Oct 2004 21:47:12 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)i9M1l7Tu045713; Thu, 21 Oct 2004 21:47:07 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 21 Oct 2004 21:47:07 -0400 From: Craig Rodrigues To: Marco Molteni Message-ID: <20041022014707.GA45582@crodrigues.org> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041021213248.223cab2c.molter@tin.it> User-Agent: Mutt/1.4.1i cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 01:47:01 -0000 On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote: > SCTP in KAME is complete, stable and fully supported. > It is mainly developed by the SCTP RFC author, Randall Stewart. Randall has been maintaining his SCTP stack on FreeBSD 4.x, OpenBSD, and NetBSD. It has recently been ported to Darwin. > > A T/TCP alternative as you are describing sounds very > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > name fool you, please read the internet draft). Interesting stuff: http://www.portaroo.net/ietf/idref/draft-ietf-tsvwg-prsctp/ > > There is at least another kernel-level open source implementation, > for Linux, plus other user-level implementations. There is one kernel implementation of SCTP in the Linux 2.6 series of kernels ( http://lksctp.sourceforge.net ), and another kernel level implementation available separately ( http://www.openss7.org/sctp.html ). SCTP is an IETF standard, and a lot of people are getting interested in it. It would be nice to have it in FreeBSD, especially since it is showing up in the Linux distributions. The only issue with Randall's implementation is that it is only for 4.x.....I looked a while back at porting it to 5.x/CURRENT.... there is some work that needs to be done, i.e. using the new zone(9) API for allocating memory, and probably also getting the locking right. I don't know how much overlap there is with what Andre is going to implement, but I thought I would throw the information out there for those who may be interested. :) -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 02:02:31 2004 Return-Path: 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 12F7816A4CE; Fri, 22 Oct 2004 02:02:30 +0000 (GMT) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F76843D5A; Fri, 22 Oct 2004 02:02:29 +0000 (GMT) (envelope-from rcarter@pinyon.org) Received: by quine.pinyon.org (Postfix, from userid 1005) id 15AE961C8; Thu, 21 Oct 2004 19:02:29 -0700 (MST) Received: from feyerabend.hq.pinyon.org (feyerabend.hq.Pinyon.ORG [10.0.9.6]) by quine.pinyon.org (Postfix) with ESMTP id B233161C0; Thu, 21 Oct 2004 19:02:26 -0700 (MST) Received: from feyerabend.hq.pinyon.org (localhost [127.0.0.1]) by feyerabend.hq.pinyon.org (Postfix) with ESMTP id A8D34103A028; Thu, 21 Oct 2004 19:02:26 -0700 (MST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Craig Rodrigues In-Reply-To: Message from Craig Rodrigues <20041022014707.GA45582@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Oct 2004 19:02:26 -0700 From: "Russell L. Carter" Message-Id: <20041022020226.A8D34103A028@feyerabend.hq.pinyon.org> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on quine.pinyon.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Level: cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 02:02:31 -0000 Greetings, It is not easy to get kame up and running, and I know this because I have. It is beyond all ordinary production installations. And as Craig notes it's not possible[1] in the 5* line yet. Maybe Randall would like to chip in on whether BSD SCTP is ready for prime time in FreeBSD. But do not underestimate the gains this protocol provides for fault tolerant server applications. Russell [1] It's been two months since I tried. : : On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote: : > SCTP in KAME is complete, stable and fully supported. : > It is mainly developed by the SCTP RFC author, Randall Stewart. : : Randall has been maintaining his SCTP stack on FreeBSD 4.x, : OpenBSD, and NetBSD. It has recently been ported to Darwin. : : : > : > A T/TCP alternative as you are describing sounds very : > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the : > name fool you, please read the internet draft). : : Interesting stuff: : http://www.portaroo.net/ietf/idref/draft-ietf-tsvwg-prsctp/ : : > : > There is at least another kernel-level open source implementation, : > for Linux, plus other user-level implementations. : : There is one kernel implementation of SCTP in : the Linux 2.6 series of kernels ( http://lksctp.sourceforge.net ), : and another kernel level implementation available separately : ( http://www.openss7.org/sctp.html ). : : SCTP is an IETF standard, and a lot of people are getting interested : in it. It would be nice to have it in FreeBSD, especially since : it is showing up in the Linux distributions. : : The only issue with Randall's implementation is that : it is only for 4.x.....I looked a while back at porting it to 5.x/CURRENT.... : there is some work that needs to be done, i.e. using : the new zone(9) API for allocating memory, and probably also : getting the locking right. : : I don't know how much overlap there is with what Andre is going to : implement, but I thought I would throw the information out there : for those who may be interested. :) : : -- : Craig Rodrigues : http://crodrigues.org : rodrigc@crodrigues.org : _______________________________________________ : freebsd-net@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-net : To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 03:25:01 2004 Return-Path: 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 90BF216A4CE; Fri, 22 Oct 2004 03:25:01 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 280AB43D45; Fri, 22 Oct 2004 03:25:01 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-68-123-122-146.dsl.snfc21.pacbell.net [68.123.122.146])i9M3OwxQ296002; Thu, 21 Oct 2004 23:24:58 -0400 Message-ID: <41787D89.3060906@elischer.org> Date: Thu, 21 Oct 2004 20:24:57 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Craig Rodrigues References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <20041022014707.GA45582@crodrigues.org> In-Reply-To: <20041022014707.GA45582@crodrigues.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org cc: Andre Oppermann cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 03:25:01 -0000 Craig Rodrigues wrote: > On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote: >>A T/TCP alternative as you are describing sounds very >>similar to PR-SCTP (Partial Reliability SCTP). (Don't let the >>name fool you, please read the internet draft). > > > Interesting stuff: > http://www.portaroo.net/ietf/idref/draft-ietf-tsvwg-prsctp/ that's potaroo > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 07:48:01 2004 Return-Path: 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 7830D16A4CE; Fri, 22 Oct 2004 07:48:01 +0000 (GMT) Received: from v6.hitachi.co.jp (galilei.v6.hitachi.co.jp [133.145.167.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C2D743D46; Fri, 22 Oct 2004 07:48:00 +0000 (GMT) (envelope-from suz@crl.hitachi.co.jp) Received: from flora210w.uki-uki.net (localhost [IPv6:::1]) by v6.hitachi.co.jp (8.12.11/8.12.11) with ESMTP id i9M6gRRt061248; Fri, 22 Oct 2004 15:42:29 +0900 (JST) (envelope-from suz@crl.hitachi.co.jp) Date: Fri, 22 Oct 2004 15:42:18 +0900 Message-ID: From: SUZUKI Shinsuke To: molter@tin.it X-cite: xcite 1.33 In-Reply-To: <20041021213248.223cab2c.molter@tin.it> References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> User-Agent: Wanderlust/2.11.32 (Wonderwall) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Network Systems Research Dept., Central Research Laboratory, Hitachi, Ltd, Japan MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: SCTP in KAME / Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 07:48:01 -0000 >>>>> On Thu, 21 Oct 2004 21:32:48 +0200 >>>>> molter@tin.it(Marco Molteni) said: > SCTP in KAME is complete, stable and fully supported. > It is mainly developed by the SCTP RFC author, Randall Stewart. KAME Project haven't received SCTP-related bug report so much, and I think it's due to a lack of testers, SCTP-API standard, and SCTP-ready applications. #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP #application fails in compilation due to a change by SCTP. So it's #difficult to conclude that SCTP is already stable... So I'm not still sure if SCTP in KAME is complete and stable enough to merge into -current. (If someone can contribute to this kind of evaluation, it's quite appreciated, of course!) Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 11:58:26 2004 Return-Path: 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 2E4BB16A4D0; Fri, 22 Oct 2004 11:58:26 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 861E743D41; Fri, 22 Oct 2004 11:58:25 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 384EB5311; Fri, 22 Oct 2004 13:58:24 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id EEB745310; Fri, 22 Oct 2004 13:58:16 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 77F7AB861; Fri, 22 Oct 2004 13:58:16 +0200 (CEST) To: Andre Oppermann References: <4177C8AD.6060706@freebsd.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 22 Oct 2004 13:58:16 +0200 In-Reply-To: <4177C8AD.6060706@freebsd.org> (Andre Oppermann's message of "Thu, 21 Oct 2004 16:33:17 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 11:58:26 -0000 Andre Oppermann writes: > o T/TCP only available on FreeBSD. No other Operating System or TCP/IP > stack implements it to my knowledge. Certainly no OS that is common. AFAIK, both Linux and Windows support it, at least on the server side (i.e. they can receive T/TCP connections even if they can't initiate them). > o T/TCP requires different API calls than TCP to use it (UDP like). Only on the client side, I believe. > o T/TCP is not supported by any common network application. Prior to libfetch, fetch(1) used it by default. > Thus after the removal of T/TCP for the reasons above I want to provide > a work-alike replacement for T/TCP's functionality: Unlike your proposal, T/TCP is described in Internet RFCs (1379 and 1644) and well-known by the Internet community. > If you haven't read and/or unstood the link above or TCP/IP Illustrated > Volume 3 then please refrain from participating in this discussion! Nice. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 12:47:38 2004 Return-Path: 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 767CF16A4CE; Fri, 22 Oct 2004 12:47:38 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 394DF43D1F; Fri, 22 Oct 2004 12:47:38 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 2F6385311; Fri, 22 Oct 2004 14:47:37 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 8EC5C5310; Fri, 22 Oct 2004 14:47:30 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 3E816B861; Fri, 22 Oct 2004 14:47:30 +0200 (CEST) To: Andre Oppermann References: <4177C8AD.6060706@freebsd.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 22 Oct 2004 14:47:30 +0200 In-Reply-To: (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav's?= message of "Fri, 22 Oct 2004 13:58:16 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 12:47:38 -0000 des@des.no (Dag-Erling Sm=F8rgrav) writes: > [...] I should add: I'm not against removing T/TCP support (especially if it helps simplify our network stack), but I don't see the point in replacing it with some homebrew protocol that noone else supports. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 15:15:01 2004 Return-Path: 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 A75CE16A4CF for ; Fri, 22 Oct 2004 15:15:01 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3C2D43D41 for ; Fri, 22 Oct 2004 15:15:00 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 87301 invoked from network); 22 Oct 2004 15:13:27 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 15:13:27 -0000 Message-ID: <417923F3.898EDBC8@freebsd.org> Date: Fri, 22 Oct 2004 17:14:59 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Marco Molteni References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <20041021213248.223cab2c.molter@tin.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 15:15:01 -0000 Marco Molteni wrote: > > On Thu, 21 Oct 2004 Andre Oppermann wrote: > > > Bruce M Simpson wrote: > > > > > > On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: > > > > Thus after the removal of T/TCP for the reasons above I want to > > > > provide a work-alike replacement for T/TCP's functionality: > > > > > > I disagree. I think the time spent here would be better spent on > > > working on an import of SCTP into the kernel, perhaps the KAME code > > > base would be a good starting point. > > > > Is the SCTP in KAME complete and stable? Are there any other (open > > source) implementations of it? > > SCTP in KAME is complete, stable and fully supported. > It is mainly developed by the SCTP RFC author, Randall Stewart. > > A T/TCP alternative as you are describing sounds very > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > name fool you, please read the internet draft). Yes, but it depends on SCTP and we don't have SCTP in the kernel any time soon. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 15:23:06 2004 Return-Path: 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 89F9E16A4D2 for ; Fri, 22 Oct 2004 15:23:06 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9FA243D49 for ; Fri, 22 Oct 2004 15:23:05 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 87400 invoked from network); 22 Oct 2004 15:21:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 15:21:31 -0000 Message-ID: <417925D8.C426261E@freebsd.org> Date: Fri, 22 Oct 2004 17:23:04 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= References: <4177C8AD.6060706@freebsd.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 15:23:06 -0000 Dag-Erling Smørgrav wrote: > > Andre Oppermann writes: > > o T/TCP only available on FreeBSD. No other Operating System or TCP/IP > > stack implements it to my knowledge. Certainly no OS that is common. > > AFAIK, both Linux and Windows support it, at least on the server side > (i.e. they can receive T/TCP connections even if they can't initiate > them). Any fully TCP compliant stack should be able to accept T/TCP connection attempts. However if it didn't implement T/TCP itself it would simply do the standard 3WSH. So yes, you can use T/TCP from the client side towards any TCP server but you don't get any benefit from it. Neither Windows or Linux implement it. Windows during the NT4 days had a bug in the TCP stack that allowed something like T/TCP but it wasn't T/TCP and didn't work with T/TCP compliant clients. > > o T/TCP requires different API calls than TCP to use it (UDP like). > > Only on the client side, I believe. Yes, on the client side. sendto() instead of connect()+write(). > > o T/TCP is not supported by any common network application. > > Prior to libfetch, fetch(1) used it by default. Only if T/TCP was enabled on the machine (net.inet.tcp.rfc1644). > > Thus after the removal of T/TCP for the reasons above I want to provide > > a work-alike replacement for T/TCP's functionality: > > Unlike your proposal, T/TCP is described in Internet RFCs (1379 and > 1644) and well-known by the Internet community. Well known for its gaping security holes and left unimplemented on any other OS except FreeBSD. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 17:28:01 2004 Return-Path: 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 68ED016A4D0 for ; Fri, 22 Oct 2004 17:28:01 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FA1543D53 for ; Fri, 22 Oct 2004 17:28:01 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 18150 invoked from network); 22 Oct 2004 17:28:00 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 17:28:00 -0000 Received: from hydrogen.funkthat.com (liforg@localhost.funkthat.com [127.0.0.1])i9MHRxlb069336; Fri, 22 Oct 2004 10:28:00 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i9MHRxA0069335; Fri, 22 Oct 2004 10:27:59 -0700 (PDT) Date: Fri, 22 Oct 2004 10:27:59 -0700 From: John-Mark Gurney To: "Ronald F. Guilmette" Message-ID: <20041022172759.GX22681@funkthat.com> References: <20041020031931.GP22681@funkthat.com> <78978.1098303754@monkeys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78978.1098303754@monkeys.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-net@freebsd.org cc: Andre Oppermann Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 17:28:01 -0000 Ronald F. Guilmette wrote this message on Wed, Oct 20, 2004 at 13:22 -0700: > >This is because aio_ requires a kernel thread > >to wait for you instead of your process context.. Currently we are limited > >to only executing 4 aio_ events at once.. This can be increased, but will > >incure a stack for each additional thread you want to run... > > That's OK. I don't mind. At least I don't think that I mind. (How big > must the separate event handler stacks be? If they are only, say, 2kB > apiece, then that's no big deal. Heck, my lowly desktop machine has a > zillion times that much main memory now!) The stacks are at least 8KB.. (but I think 12KB), plus any associated struct proc and other associated data... there is a tunable to increase the four, but of course, you'll take up more memory.. > >FreeBSD's kernel is inherently syncronous... > > Well, surely not entirely. I mean it fields interrupts, right? I'm talking about how it appears from userland.. This entire discussion has been about userland/kernel interface and nothing more.. bringing up a kernel/kernel interface is completely different... > >To handle what you want to do, we would need to completely rearchitect > >the FreeBSD kernel to make more things asyncronous.. > > I was under the impression that a lot of work had already gone in that > general direction in order to support SMP. No? For a lot of the kernel to kernel stuff, but many paths like ioctl's, read, write, etc. All those kernel interfaces will block in the kernel path till the resulting device returns... (is woken up).. There is no async interface as it hasn't been the Unix way(tm)... > >Going async can improve things, and with it, makes implementing a sync > >interface easy on top of it... > > Yes. (I realized myself last night that in theory, read(2) and write(2) > could be implemented, entirely in userland, on top of aio_read() and > aio_write() respectively.) > > >So the short of it is, no, FreeBSD at a low level does not support > >it... > > Oh well. It didn't hurt to ask. > > >Now, I know this isn't what you want, but I usually make my kevent > >use appear as if it's async... I use the udata pointer point to a > >struct which starts with a function pointer... Then when I get events > >back from kevent, I just have code that loops over the events, and calls > >the associated function pointer.. simulating a signal... > > I understand. Your event loop is really an event/dispatch loop. > > >Hope this helps... > > Well, you have certainly helped to clarify for me the various reasons > why it might be less than a good idea to use aio_*() function calls, > in abundance, on the current FreeBSD kernel. For that I do thank you. Even though aio_ needs help, it appears that some other people are working on improving it right now... Doug Ambrisko posted a message to -current about some patches to make aio_ work with kqueue. Brian Feldman did start work on making kqueue's send signals when an event became available, but it was put on the back burner because of a problem w/ locking since, that signel could also wake up the kqueue that delivered the signal.. Though now that kqueue has been locked down we can revisit this.. Oh, another thing is that there isn't yet a verbose signal delivery mechanism.. There are only two signals that are for user's use, and that isn't enough for what you want.. since even if you did get a signal, it'd degenerate into an event/dispatch loop at you stated above.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 17:40:17 2004 Return-Path: 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 C54C916A4D8 for ; Fri, 22 Oct 2004 17:40:17 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D36543D55 for ; Fri, 22 Oct 2004 17:40:17 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 25155 invoked from network); 22 Oct 2004 17:40:17 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Oct 2004 17:40:17 -0000 Received: from hydrogen.funkthat.com (mdazwt@localhost.funkthat.com [127.0.0.1])i9MHeGlb069756; Fri, 22 Oct 2004 10:40:16 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i9MHeGbt069755; Fri, 22 Oct 2004 10:40:16 -0700 (PDT) Date: Fri, 22 Oct 2004 10:40:16 -0700 From: John-Mark Gurney To: "Ronald F. Guilmette" Message-ID: <20041022174016.GZ22681@funkthat.com> References: <20041020031931.GP22681@funkthat.com> <78978.1098303754@monkeys.com> <20041022172759.GX22681@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041022172759.GX22681@funkthat.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 17:40:17 -0000 John-Mark Gurney wrote this message on Fri, Oct 22, 2004 at 10:27 -0700: > Brian Feldman did start work on making kqueue's send signals when an > event became available, but it was put on the back burner because of a > problem w/ locking since, that signel could also wake up the kqueue > that delivered the signal.. Though now that kqueue has been locked > down we can revisit this.. I misspoke, it was Alfred Perlstein who did this work. see v1.71 and v1.72 of src/sys/kern/kern_event.c.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 18:01:31 2004 Return-Path: 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 A3E1516A4FE; Fri, 22 Oct 2004 18:01:31 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B6EA43D2F; Fri, 22 Oct 2004 18:01:31 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id F244854AB; Fri, 22 Oct 2004 11:01:30 -0700 (PDT) To: John-Mark Gurney In-reply-to: Your message of Fri, 22 Oct 2004 10:27:59 -0700. <20041022172759.GX22681@funkthat.com> Date: Fri, 22 Oct 2004 11:01:30 -0700 Message-ID: <2171.1098468090@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org cc: Andre Oppermann Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 18:01:32 -0000 In message <20041022172759.GX22681@funkthat.com>, you wrote: >Oh, another thing is that there isn't yet a verbose signal delivery >mechanism.. There are only two signals that are for user's use... ^defined in relevant standards Signal numbers are typically represented as ints. Is there anything in the kernel that prevents me from, say, calling kill(2) with a second argument of, say, 0xdeadbeef, in other words any old random int value that I might care to use? If not, then there are effectively 4 billion+ different signal numbers that could be used by a programmer. Such usage might not be fully standard-conformant, but it might work OK, nontheless. (In fact, one might even be able to use _most_ typical pointer values as if they were signal numbers, simply by casting them to ints before use.) From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 18:07:50 2004 Return-Path: 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 F333316A4CE for ; Fri, 22 Oct 2004 18:07:49 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9707B43D4C for ; Fri, 22 Oct 2004 18:07:49 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i9MI7mqw039924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Fri, 22 Oct 2004 14:07:48 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i9MI7m0O039921; Fri, 22 Oct 2004 14:07:48 -0400 (EDT) (envelope-from wollman) Date: Fri, 22 Oct 2004 14:07:48 -0400 (EDT) From: Garrett Wollman Message-Id: <200410221807.i9MI7m0O039921@khavrinen.lcs.mit.edu> To: "Ronald F. Guilmette" In-Reply-To: <2171.1098468090@monkeys.com> References: <20041022172759.GX22681@funkthat.com> <2171.1098468090@monkeys.com> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@FreeBSD.ORG Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 18:07:50 -0000 < said: > Signal numbers are typically represented as ints. Is there anything in > the kernel that prevents me from, say, calling kill(2) with a second > argument of, say, 0xdeadbeef, in other words any old random int value > that I might care to use? Yes. Signals are represented, in the kernel and in the API, as bits in fixed-size bitmaps. POSIX real-time signals, if we implemented them, would at least give you the opportunity to queue signals, with unique ancillary data attached to each instance. We have all the mechanism to do this in the user-kernel interface; it's just not implemented in the kernel. -GAWollman From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 18:24:32 2004 Return-Path: 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 F2E7316A4CE; Fri, 22 Oct 2004 18:24:31 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 887B443D2F; Fri, 22 Oct 2004 18:24:31 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i9MIOUag009286; Fri, 22 Oct 2004 11:24:31 -0700 (PDT) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [68.76.113.50]) by guns.icir.org (Postfix) with ESMTP id A613777AF4A; Fri, 22 Oct 2004 14:24:30 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 31A2B1EF3BF; Fri, 22 Oct 2004 14:24:30 -0400 (EDT) To: Marco Molteni From: Mark Allman In-Reply-To: <20041021213248.223cab2c.molter@tin.it> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Glycerine MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 22 Oct 2004 14:24:30 -0400 Sender: mallman@icir.org Message-Id: <20041022182430.31A2B1EF3BF@lawyers.icir.org> cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 18:24:32 -0000 --=-=-= Content-Type: text/plain > A T/TCP alternative as you are describing sounds very > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > name fool you, please read the internet draft). Can you sketch this in a bit more detail? I do not follow. PR-SCTP is about being allowed to "abandon" data --- i.e., send it and then decide that you don't really care if it gets across the network (say, because it got lost and has taken too long to retransmit and so the data is out of date). Without a Big Hack, I cannot envision TCP doing something like this. What am I missing? Thanks, allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFBeVBeWyrrWs4yIs4RApwcAJ9VDoEaO7SpKK/ty0NUlZi+qM3vawCeNhJB lbLVyoW0++t6W8U7lRavcH4= =yp18 -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 19:46:07 2004 Return-Path: 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 50BB116A4CE; Fri, 22 Oct 2004 19:46:07 +0000 (GMT) Received: from hotmail.com (bay24-f25.bay24.hotmail.com [64.4.18.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 103AD43D5C; Fri, 22 Oct 2004 19:46:07 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Oct 2004 12:46:04 -0700 Received: from 198.53.131.3 by by24fd.bay24.hotmail.msn.com with HTTP; Fri, 22 Oct 2004 19:45:59 GMT X-Originating-IP: [198.53.131.3] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com From: "Stephane Raimbault" To: gnn@FreeBSD.org Date: Fri, 22 Oct 2004 13:45:59 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Oct 2004 19:46:04.0516 (UTC) FILETIME=[C429A240:01C4B86F] cc: net@FreeBSD.org Subject: Re: Error 49, socket problem? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 19:46:07 -0000 The servers are busier today and error 49 is comming up frequently now. Here are some results of what you asked for. # netstat -m 305/5152/26624 mbufs in use (current/peak/max): 305 mbufs allocated to data 292/3592/6656 mbuf clusters in use (current/peak/max) 8472 Kbytes allocated to network (42% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines # ifconfig -a em0: flags=8843 mtu 1500 options=3 inet 10.0.12.15 netmask 0xffffffe0 broadcast 10.0.12.31 inet6 fe80::230:48ff:fe29:7f48%em0 prefixlen 64 scopeid 0x1 ether 00:30:48:29:7f:48 media: Ethernet 100baseTX status: active em1: flags=8802 mtu 1500 options=3 ether 00:30:48:29:7f:49 media: Ethernet autoselect status: no carrier lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 faith0: flags=8002 mtu 1500 # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.12.1 UGSc 588 1292 em0 10.0.12/27 link#1 UC 13 0 em0 10.0.12.1 00:00:5e:00:01:05 UHLW 588 0 em0 1177 10.0.12.8 00:0c:f1:77:a5:d8 UHLW 97 7723205 em0 229 10.0.12.10 00:30:48:29:7f:34 UHLW 0 22 em0 552 10.0.12.11 00:30:48:29:80:38 UHLW 0 1165712 em0 987 10.0.12.12 00:30:48:29:80:d4 UHLW 0 172 em0 1018 10.0.12.13 00:30:48:27:75:61 UHLW 215 35228169 em0 1193 10.0.12.14 00:30:48:29:80:84 UHLW 1 27992157 em0 959 10.0.12.15 00:30:48:29:7f:48 UHLW 1 12597865 lo0 10.0.12.22 00:30:48:23:bb:f0 UHLW 2125 303510829 em0 1034 10.0.12.23 00:e0:81:21:1b:78 UHLW 0 242 em0 697 10.0.12.26 00:0d:61:03:80:98 UHLW 0 8736 em0 975 10.0.12.30 00:c0:4f:9e:b9:c7 UHLW 0 848 em0 1003 10.0.12.31 ff:ff:ff:ff:ff:ff UHLWb 0 2347026 em0 127.0.0.1 127.0.0.1 UH 1022 153926288 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%em0/64 link#1 UC em0 fe80::230:48ff:fe29:7f48%em0 00:30:48:29:7f:48 UHL lo0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 fe80::1%lo0 link#3 UHL lo0 ff01::/32 ::1 U lo0 ff02::%em0/32 link#1 UC em0 ff02::%lo0/32 ::1 UC lo0 # uptime 1:39PM up 31 days, 3:02, 3 users, load averages: 1.34, 1.27, 1.07 # sysctl -a | grep socket kern.ipc.maxsockets: 12328 socket: 192, 12328, 5320, 1080, 124222928 jail.socket_unixiproute_only: 1 # tail -f /wwwlogs/httpd-error.log [Fri Oct 22 13:39:18 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:20 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:20 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:21 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:24 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:39 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:39 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:40 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:43 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed [Fri Oct 22 13:39:43 2004] [error] (49)Can't assign requested address: proxy: HTTP: attempt to connect to 127.0.0.1:81 (127.0.0.1) failed what else can I check for here... it's quite mysterious as several network based apps on the server fail, yet nothing in /var/log/messages indicating a problem. >From: gnn@FreeBSD.org >To: "Stephane Raimbault" >CC: net@FreeBSD.org >Subject: Re: Error 49, socket problem? >Date: Thu, 14 Oct 2004 10:46:58 +0900 > >At Wed, 13 Oct 2004 09:36:03 -0600, >Stephane Raimbault wrote: > > > > I doubt it's a DoS attack, however it could very well be. > > > >Well, probably not, given what you told us below. > > > In this particular setup, apache runs on port 80 and 81. A slimed down > > version of apache handles basic http requests on port 80 and on port 81, >we > > have a beefier version of apache with php running applications. We >proxy > > the request from port 80 to port 81 so the client only ever sees >connections > > to port 80. > > > > What I find strange is other applications on the server freak out when >this > > is happening in the same manner. such as php not able to make mysql > > connections with a similar error. The errors aren't limited to >127.0.0.1 > > either, it seems to be an overall problem with the box, not specifically >the > > loopback or apache. > > > > PHP Warning: mysql_connect(): Can't connect to MySQL server on > > 'dbm.xxx.xxx.com' (49) in /www/index.php on line 4060 > > > > In this case the above dbm.xxx.xxx.com resolves to 10.0.12.22 which is >one > > of the MySQL server's in the cluster. > > > > I've ruled out that it's a problem with the MySQL server in this case, > > because I have 4 other web servers (running apache) able to connect to >that > > MySQL server during the same time. All web servers in this cluster seem >to > > exhibit the error randomly at diffrent times. Not only during high peak > > traffic times as previously thought. > > > > Are there buffers I could be running out of? What should I be checking? > > Perhaps something in sysctl... If I know what I should probably be >looking > > at, I can probably monitor and have certain variables logged / graphed >for a > > better idea of what is going on. > > > >What version of FreeBSD are you running? > >I would check the interfaces (ifconfig -a), routing table (netstat >-rn), and then the rest of the network statistics (man netstat) when >this happens. Does it happen reliably or intermittently? > >Later, >George _________________________________________________________________ MSN® Calendar keeps you organized and takes the effort out of scheduling get-togethers. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 20:22:38 2004 Return-Path: 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 D9DBC16A4CE; Fri, 22 Oct 2004 20:22:38 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6548843D41; Fri, 22 Oct 2004 20:22:37 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9MKMZis040348; Sat, 23 Oct 2004 00:22:35 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Sat, 23 Oct 2004 00:22:35 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: Stephane Raimbault In-Reply-To: Message-ID: <20041023001755.F91215@is.park.rambler.ru> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: gnn@freebsd.org cc: net@freebsd.org Subject: Re: Error 49, socket problem? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 20:22:39 -0000 On Fri, 22 Oct 2004, Stephane Raimbault wrote: > The servers are busier today and error 49 is comming up frequently now. What does "netstat -n | grep 127.0.0.1 | wc -l" show ? You should probably try sysctl -w net.inet.ip.portrange.first=49152 sysctl -w net.inet.ip.portrange.last=65535 or even sysctl -w net.inet.ip.portrange.first=1024 sysctl -w net.inet.ip.portrange.last=65535 And after you upgrade to 4.10 do not forget to set sysctl -w net.inet.ip.portrange.randomized=0 Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Oct 22 20:25:37 2004 Return-Path: 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 C054716A4CE for ; Fri, 22 Oct 2004 20:25:37 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1168943D3F for ; Fri, 22 Oct 2004 20:25:37 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9MKPUis040528; Sat, 23 Oct 2004 00:25:30 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Sat, 23 Oct 2004 00:25:30 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: "Ronald F. Guilmette" In-Reply-To: <93418.1098386003@monkeys.com> Message-ID: <20041023002300.I91215@is.park.rambler.ru> References: <93418.1098386003@monkeys.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2004 20:25:37 -0000 On Thu, 21 Oct 2004, Ronald F. Guilmette wrote: > >I believe if you want to build a more maintainable, more adaptable, > >more modularized program then you should avoid two things - the threads and > >the signals. If you like to use a callback behaviour of the signals you could > >easy implement it without any signal. > > OK. I'll bite. How? I'm sure you know it. Sorry, English is not my native language so I may tell you only shortly. You can use two notification models. First is the socket readiness for operations, second is the operation completeness. In the first model you use usual read()/write() operations and learn readiness using select()/poll()/kevent(). In the second model you use aio_read()/aio_write() operations and learn about their completeness using aio_suspend()/aio_waitcomplete()/kevent(). After you have got the notifications you would call your callback handlers as well as the kernel would call your signal handlers. The difference between your code and kernel is that your code always calls handlers in the well known places that allows to avoid the various race conditions. The kernel may call the signal handler any time if the signal is not blocked. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 00:59:39 2004 Return-Path: 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 2106C16A4CE; Sat, 23 Oct 2004 00:59:39 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86D1943D4C; Sat, 23 Oct 2004 00:59:38 +0000 (GMT) (envelope-from peter.lei@ieee.org) Received: from [10.10.0.75] (c-24-13-174-21.client.comcast.net[24.13.174.21]) by comcast.net (sccrmhc13) with ESMTP id <20041023005905016001r5jje> (Authid: peterlei); Sat, 23 Oct 2004 00:59:29 +0000 Message-ID: <4179ACB8.4020108@ieee.org> Date: Fri, 22 Oct 2004 19:58:32 -0500 From: Peter Lei User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: SUZUKI Shinsuke References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> In-Reply-To: X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010006070805020405040504" cc: freebsd-net@freebsd.org cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 00:59:39 -0000 This is a cryptographically signed message in MIME format. --------------ms010006070805020405040504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think this is because any bugs that are found are usually communicated directly to us. I think Randy has a better handle on how many people are using this stack. I'm quite sure it is stable enough to go in to -current. While the SCTP API hasn't gone through last call, it's fairly stable and we have both "converted" many applications from TCP to SCTP using the sockets API, as well as had portability between the KAME SCTP stack and the linux stack for some test applications used at the last interop event (except for the standard sockets issues that one runs into even for TCP like no sin_length field in the sockaddr struct). The same stack has also been ported to Mac OSX as a native kernel build as well as an loadable/unloadble NKE w/a minor kernel change. I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. The major changes to our SCTP code when it gets committed into KAME has been that of code format/style. What is the existing criteria for a measure of "stability"? regards, --peter SUZUKI Shinsuke wrote: >>>>>>On Thu, 21 Oct 2004 21:32:48 +0200 >>>>>>molter@tin.it(Marco Molteni) said: > > >>SCTP in KAME is complete, stable and fully supported. >>It is mainly developed by the SCTP RFC author, Randall Stewart. > > > KAME Project haven't received SCTP-related bug report so much, and I > think it's due to a lack of testers, SCTP-API standard, and SCTP-ready > applications. > #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP > #application fails in compilation due to a change by SCTP. So it's > #difficult to conclude that SCTP is already stable... > > So I'm not still sure if SCTP in KAME is complete and stable enough to > merge into -current. (If someone can contribute to this kind of > evaluation, it's quite appreciated, of course!) > > Thanks, > ---- > SUZUKI, Shinsuke @ KAME Project > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --------------ms010006070805020405040504 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII7TCC AtEwggI6oAMCAQICAwvwrTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwMzE3MjE1NjMzWhcNMDUwMzE3MjE1NjMz WjBEMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJw ZXRlci5sZWlAaWVlZS5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDX4PR3 QP+rgEBZtv1Q4YhKjRXUZQSk+9xNzesbK7pyirmUxKnm209ZGibDUAb/yC0ghvl3GbvNv/72 cyfC7JVjiABrDxY19L9mRGLKzjlK/bgBPY8SIu4blM/RtyabN4CdYk24LoGPHuLLkJIvvvQR LG0IJIfP8zvoHy0UGzyXOM/S4msxF1zDpBu7lYMe4Dpu5O9uaE2j1G/jswVmO2KMyQmffOGx 0Mw18tiGNMWkjMAwSJnXO2VSHzvh+I3OM71ReFo9ET2TtiXzqdDM5z0/LTsIyy1vP4Ib3Co9 xZNTe6JqVk2BsH7EZKPxi+oD7f/HctNWTZk0sesgba7D97jLAgMBAAGjLzAtMB0GA1UdEQQW MBSBEnBldGVyLmxlaUBpZWVlLm9yZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AB86WuVOs/pHjC4SPdbKb+obiQZVqR813FD3JcW+stkaZQHTPHoln/SYRd3TZcZIXageyme6 f5Gl3lOsamSUrtkov5u6B0vvtuDuMQH7deh1ARTQfC+R3hv29vVQ+uSPlLo/AGWaPcW030NW Bp96xBIESmHBMWGuYWkxMDHII/R+MIIC0TCCAjqgAwIBAgIDC/CtMA0GCSqGSIb3DQEBBAUA MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNDAz MTcyMTU2MzNaFw0wNTAzMTcyMTU2MzNaMEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBN ZW1iZXIxITAfBgkqhkiG9w0BCQEWEnBldGVyLmxlaUBpZWVlLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBANfg9HdA/6uAQFm2/VDhiEqNFdRlBKT73E3N6xsrunKKuZTE qebbT1kaJsNQBv/ILSCG+XcZu82//vZzJ8LslWOIAGsPFjX0v2ZEYsrOOUr9uAE9jxIi7huU z9G3Jps3gJ1iTbgugY8e4suQki++9BEsbQgkh8/zO+gfLRQbPJc4z9LiazEXXMOkG7uVgx7g Om7k725oTaPUb+OzBWY7YozJCZ984bHQzDXy2IY0xaSMwDBImdc7ZVIfO+H4jc4zvVF4Wj0R PZO2JfOp0MznPT8tOwjLLW8/ghvcKj3Fk1N7ompWTYGwfsRko/GL6gPt/8dy01ZNmTSx6yBt rsP3uMsCAwEAAaMvMC0wHQYDVR0RBBYwFIEScGV0ZXIubGVpQGllZWUub3JnMAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAHzpa5U6z+keMLhI91spv6huJBlWpHzXcUPclxb6y 2RplAdM8eiWf9JhF3dNlxkhdqB7KZ7p/kaXeU6xqZJSu2Si/m7oHS++24O4xAft16HUBFNB8 L5HeG/b29VD65I+Uuj8AZZo9xbTfQ1YGn3rEEgRKYcExYa5haTEwMcgj9H4wggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEwMjMwMDU4MzJaMCMGCSqGSIb3DQEJ BDEWBBRrk39gpoOpWqYdY1tVvISJ5jw1uzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDB4BgkrBgEEAYI3EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg SXNzdWluZyBDQQIDC/CtMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwvwrTANBgkqhkiG9w0BAQEFAASCAQA3fGlS sskhvbOgczo64RIPkpGP/te8inW9boQ3wlQf6O7hRV/6ooAfpRxdfBEo4TR4/SnMuY9ExN3N 3MpC6TBk0PPs+KEhVY81I8AYRgxcRbswHvZKrgnTWwuw2jArld+sY/mwdiWQUcfn5ALkR5Wl i/TqEN5J0bvK4tlBUxhWjf3OD+oG90qlJ73VCdPI4r3AbAQC82ECQCy48LsdRs+SZVpwbn0k JeGivu8inV76Rvbq6yAHOFm+ADzEpogpDV1QFKlWmafRhdIpKxrqn1mRAREdwKGo4D2RizyI zpNpY6glpC86jck8MGp2b021TV9Je/VT4UyaPmWaTf/sM0pRAAAAAAAA --------------ms010006070805020405040504-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 06:07:01 2004 Return-Path: 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 B6DEA16A4CE for ; Sat, 23 Oct 2004 06:07:01 +0000 (GMT) Received: from hotmail.com (bay24-f14.bay24.hotmail.com [64.4.18.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id A124943D46 for ; Sat, 23 Oct 2004 06:07:01 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Oct 2004 23:07:01 -0700 Received: from 66.244.239.179 by by24fd.bay24.hotmail.msn.com with HTTP; Sat, 23 Oct 2004 06:06:01 GMT X-Originating-IP: [66.244.239.179] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com From: "Stephane Raimbault" To: is@rambler-co.ru Date: Sat, 23 Oct 2004 00:06:01 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Oct 2004 06:07:01.0152 (UTC) FILETIME=[82D92200:01C4B8C6] cc: net@FreeBSD.org Subject: Re: Error 49, socket problem? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 06:07:01 -0000 Thanks Igor, I was running out of ports in the 1024-5000 range and setting my last port to 65535 via sysctl did solve my problem. In 4.10 what will sysctl -w net.inet.ip.portrange.randomized=0 do for me? Is there any danger of me setting the port range from 1024 - 65535 ? Thanks, Stephane. Igor Sysoev wrote: >On Fri, 22 Oct 2004, Stephane Raimbault wrote: > > >>The servers are busier today and error 49 is comming up frequently now. > > >What does "netstat -n | grep 127.0.0.1 | wc -l" show ? > >You should probably try > >sysctl -w net.inet.ip.portrange.first=49152 >sysctl -w net.inet.ip.portrange.last=65535 > >or even > >sysctl -w net.inet.ip.portrange.first=1024 >sysctl -w net.inet.ip.portrange.last=65535 > >And after you upgrade to 4.10 do not forget to set > >sysctl -w net.inet.ip.portrange.randomized=0 > > >Igor Sysoev >http://sysoev.ru/en/ >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 06:13:01 2004 Return-Path: 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 C3D7416A4CE for ; Sat, 23 Oct 2004 06:13:01 +0000 (GMT) Received: from hotmail.com (bay24-f38.bay24.hotmail.com [64.4.18.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE3A143D39 for ; Sat, 23 Oct 2004 06:13:01 +0000 (GMT) (envelope-from segr@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Oct 2004 23:13:00 -0700 Received: from 66.244.239.179 by by24fd.bay24.hotmail.msn.com with HTTP; Sat, 23 Oct 2004 06:12:01 GMT X-Originating-IP: [66.244.239.179] X-Originating-Email: [segr@hotmail.com] X-Sender: segr@hotmail.com From: "Stephane Raimbault" To: net@freebsd.org Date: Sat, 23 Oct 2004 00:12:01 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Oct 2004 06:13:00.0978 (UTC) FILETIME=[59523920:01C4B8C7] Subject: using natd to load balance port 80 to multiple servers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 06:13:01 -0000 Hi All, I'm currently using a freebsd box running natd to forward port 80 to several (5) web servers on private IP's. I have discovered that natd doesn't handle many requests/second all that well (seem to choke at about 200 req/second (educated guess)) There are other packet filtering options on FreeBSD and I wonder if I can use them to do what I'm trying to do with natd. Would someone be able to point me to documentation or help me have either ipf/ipfw/pf forward port 80 traffic to private space IP's? Is there a better way of split port 80 traffic across multiple webservers that has elduded me? Other then a comercial content switch that is :) I've worked with the loadd port and ran into some problems, so I resulted in simply using some natd syntax to forward port 80 traffic to multiple servers... Now that seems to have run to it's limitation and I'm wondering if I can do the same thing with ipf/ipfw/pf as I believe that might be a bit more efficient. Any feedback would be appreciated... Thanks, Stephane. _________________________________________________________________ Designer Mail isn't just fun to send, it's fun to receive. Use special stationery, fonts and colors. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 12:56:20 2004 Return-Path: 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 C515D16A4CE for ; Sat, 23 Oct 2004 12:56:20 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6923B43D2D for ; Sat, 23 Oct 2004 12:56:19 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9NCuGis006523; Sat, 23 Oct 2004 16:56:17 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Sat, 23 Oct 2004 16:56:16 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: Stephane Raimbault In-Reply-To: Message-ID: <20041023164550.J6546@is.park.rambler.ru> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@FreeBSD.org Subject: Re: Error 49, socket problem? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 12:56:20 -0000 On Sat, 23 Oct 2004, Stephane Raimbault wrote: > I was running out of ports in the 1024-5000 range and setting my last port > to 65535 via sysctl did solve my problem. > > In 4.10 what will sysctl -w net.inet.ip.portrange.randomized=0 do for me? If you have too many quick connections between proxy (4.10) and backend, or between the http server (4.10) and the SQL server then you may see in the logs the accidental errors "Connection refused". This is because 4.10 gets port number randomly and there is the chance that other side has the connection with the same port in TIME_WAIT state. See, i.e., http://freebsd.rambler.ru/bsdmail/freebsd-stable_2004/msg02310.html > Is there any danger of me setting the port range from 1024 - 65535 ? I believe it is safe. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 13:07:34 2004 Return-Path: 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 D6B5B16A4CE; Sat, 23 Oct 2004 13:07:34 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CA1543D5D; Sat, 23 Oct 2004 13:07:32 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9ND71tr031391; Sat, 23 Oct 2004 09:07:04 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A572A.9080306@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:05:46 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Lei References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> In-Reply-To: <4179ACB8.4020108@ieee.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: SUZUKI Shinsuke cc: andre@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing it withsomething simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:07:35 -0000 Peter: Yes, I do get all the bugs reported to me (usually) directly.. And I try to turn them around within a week (if possible)... I have a couple on my plate right now from Chiba Hirotsugu ... in fact the last batch of bugs was also from Chiba... I know of at least 4 sites actively using the code and reporting bugs and issues Marko, Chiba, The U-D guys (there are about 4 different projects at U-D and a LOT of folks in the PEL lab so I won't try to name them all), Alessio (performance tests I think), Jian Wang (doing some cwnd type testing)... and there are others that have reported bugs... in fact some have even pulled it into their products (QNX I think).. they of course are behind us (just like KAME is too).. I have put on my web site patch-24 (which I have, as yet, not sent to KAME and probably will-not). Patch 25 will come out as soon as I finish fixing Chiba-san's issues... resolving all known bugs :-D I have not heard of any compile issues with SCTP and KAME.. if there are it is probably due to changes in KAME that need changes in the SCTP side too... We always cvs update and compile to validate BEFORE we send in the patch to Itojun. There have been SOME issues with the formatting.. in some cases code as accidentally disappeared.. but this will happen on a project like ours as we send patches in and try to integrate it :-D Anyway.. I do think it is stable enough for inclusion in stable BSD... if you have another 4.x round.. BUT we have not went in and fully got things working on 5.x... I know one of our team members (Kozuka-san) has made an effort to make it compile.. but it as yet does not function :-0 I also, before patch 25, would like to finish a third round of performance optimization. I finally have a second machine with a Gig-E interface and 2.XMhz .. so I think I can try to squeak it up a bit more... ah.. plans for next week if I can find the cycles :-o Anyway.. after patch-25 I intend on taking my new machine to the 5.3 strain and trying to figure out what I need to do to make it work :-0 (maybe patch26 :-D) R Peter Lei wrote: > I think this is because any bugs that are found are usually > communicated directly to us. > > I think Randy has a better handle on how many people are using > this stack. I'm quite sure it is stable enough to go in to > -current. > > While the SCTP API hasn't gone through last call, it's fairly > stable and we have both "converted" many applications from TCP > to SCTP using the sockets API, as well as had portability between > the KAME SCTP stack and the linux stack for some test applications > used at the last interop event (except for the standard sockets > issues that one runs into even for TCP like no sin_length field > in the sockaddr struct). > > The same stack has also been ported to Mac OSX as a native kernel > build as well as an loadable/unloadble NKE w/a minor kernel change. > > I'm not aware of any KAME SNAP compilation failures w/and w/o SCTP. > The major changes to our SCTP code when it gets committed into KAME > has been that of code format/style. > > What is the existing criteria for a measure of "stability"? > > regards, > --peter > > SUZUKI Shinsuke wrote: > >>>>>>> On Thu, 21 Oct 2004 21:32:48 +0200 >>>>>>> molter@tin.it(Marco Molteni) said: >> >> >> >>> SCTP in KAME is complete, stable and fully supported. >>> It is mainly developed by the SCTP RFC author, Randall Stewart. >> >> >> >> KAME Project haven't received SCTP-related bug report so much, and I >> think it's due to a lack of testers, SCTP-API standard, and SCTP-ready >> applications. >> #Sometimes KAME SNAP compilation fails in SCTP and non-SCTP >> #application fails in compilation due to a change by SCTP. So it's >> #difficult to conclude that SCTP is already stable... >> >> So I'm not still sure if SCTP in KAME is complete and stable enough to >> merge into -current. (If someone can contribute to this kind of >> evaluation, it's quite appreciated, of course!) >> >> Thanks, >> ---- >> SUZUKI, Shinsuke @ KAME Project >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 13:14:34 2004 Return-Path: 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 B299616A4CE for ; Sat, 23 Oct 2004 13:14:34 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3B8043D58 for ; Sat, 23 Oct 2004 13:14:33 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i9NDEWis007605; Sat, 23 Oct 2004 17:14:32 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Sat, 23 Oct 2004 17:14:32 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: Stephane Raimbault In-Reply-To: Message-ID: <20041023165912.J6546@is.park.rambler.ru> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: using natd to load balance port 80 to multiple servers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:14:34 -0000 On Sat, 23 Oct 2004, Stephane Raimbault wrote: > I'm currently using a freebsd box running natd to forward port 80 to several > (5) web servers on private IP's. > > I have discovered that natd doesn't handle many requests/second all that > well (seem to choke at about 200 req/second (educated guess)) > > There are other packet filtering options on FreeBSD and I wonder if I can > use them to do what I'm trying to do with natd. > > Would someone be able to point me to documentation or help me have either > ipf/ipfw/pf forward port 80 traffic to private space IP's? > > Is there a better way of split port 80 traffic across multiple webservers > that has elduded me? Other then a comercial content switch that is :) > > I've worked with the loadd port and ran into some problems, so I resulted in > simply using some natd syntax to forward port 80 traffic to multiple > servers... Now that seems to have run to it's limitation and I'm wondering > if I can do the same thing with ipf/ipfw/pf as I believe that might be a bit > more efficient. > > Any feedback would be appreciated... You could look at PF. Also you could use http reverse-proxy like nginx, look the example of the configuration (the page is in Russian, but the configuration is in English :) http://sysoev.ru/nginx/docs/example.html Currenty, to proxy the several servers you need to set up their IPs under one name in DNS. nginx would connect to them in round robin. If some server does not response then nginx would try the next. You could set several reasons to try the next server: proxy_next_upstream error timeout invalid_header http_500; or even proxy_next_upstream error timeout invalid_header http_500 http_404; nginx was tested on several busy sites under FreeBSD (serving the static files and the proxing, using kqueue/select/poll), Linux (static and proxy, using epoll, rt signals) and Solaris (static only, using /dev/poll). Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 13:16:40 2004 Return-Path: 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 8580416A4CE; Sat, 23 Oct 2004 13:16:40 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D4E143D58; Sat, 23 Oct 2004 13:16:38 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9NDGRtr031497; Sat, 23 Oct 2004 09:16:33 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A5960.3000708@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:15:12 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matt Emmerton References: <4177C8AD.6060706@freebsd.org><20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <00e901c4b79b$d13e6e40$1200a8c0@gsicomp.on.ca> In-Reply-To: <00e901c4b79b$d13e6e40$1200a8c0@gsicomp.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org cc: Andre Oppermann cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:16:40 -0000 Matt Emmerton wrote: > > > The SCTP home page (www.sctp.org) has a list of implementations. Note that > I had to use Google's cache of the site -- I believe there was a Slashdot > article on SCTP this morning which may have taken down the site. Sigh... It is also over satellite... which is medium speed internet at best.. my provider may also have limits on how many connection attempts I get ... I buy a professional package.. but you can BET I will dump sat has soon as DSL shows up (in the next year or soo I hope)... > > AIX, Solaris, HP and Cisco all support SCTP in their latest OS versions. > There are aslo a few different (non-free) implementations for Windows, and > at least one open-source implementation for Linux (http://www.openss7.org) > Linux has SCTP built into the kernle with the lk-sctp project.. I would not touch the openss7 version.. it is not very compatible with any other SCTP (it does not follow the standard).. At the last interop some of the issues were finally fixed (its really the first time they showed up and tested)... but I don't know if those patches are available or per fee. The lk-sctp project in the kernel is far stabler and they are working to performance tune it (here it needs a lot of work) and AFAIK lk-sctp will ship with all 2.6.6 and greater kernels... turned on by default if I remember right.. R > -- > Matt Emmerton > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 13:17:24 2004 Return-Path: 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 D0BDB16A4CE; Sat, 23 Oct 2004 13:17:24 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D68943D53; Sat, 23 Oct 2004 13:17:22 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9NDHJtr031503; Sat, 23 Oct 2004 09:17:20 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A5994.7020306@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:16:04 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Molteni References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> In-Reply-To: <20041021213248.223cab2c.molter@tin.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:17:25 -0000 Marco Molteni wrote: > On Thu, 21 Oct 2004 Andre Oppermann wrote: > > >>Bruce M Simpson wrote: >> >>>On Thu, Oct 21, 2004 at 04:33:17PM +0200, Andre Oppermann wrote: >>> >>>>Thus after the removal of T/TCP for the reasons above I want to >>>>provide a work-alike replacement for T/TCP's functionality: >>> >>>I disagree. I think the time spent here would be better spent on >>>working on an import of SCTP into the kernel, perhaps the KAME code >>>base would be a good starting point. >> >>Is the SCTP in KAME complete and stable? Are there any other (open >>source) implementations of it? > > > SCTP in KAME is complete, stable and fully supported. > It is mainly developed by the SCTP RFC author, Randall Stewart. > > A T/TCP alternative as you are describing sounds very > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > name fool you, please read the internet draft). RFC3758 (its a proposed standard now.. not a draft.) :-> R > There is at least another kernel-level open source implementation, > for Linux, plus other user-level implementations. > > marco -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 13:20:46 2004 Return-Path: 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 0586E16A4CE; Sat, 23 Oct 2004 13:20:46 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id A037E43D1F; Sat, 23 Oct 2004 13:20:43 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9NDKNtr031514; Sat, 23 Oct 2004 09:20:25 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A5A4C.1080706@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:19:08 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Russell L. Carter" References: <20041022020226.A8D34103A028@feyerabend.hq.pinyon.org> In-Reply-To: <20041022020226.A8D34103A028@feyerabend.hq.pinyon.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Craig Rodrigues cc: freebsd-arch@freebsd.org cc: Andre Oppermann cc: freebsd-net@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:20:46 -0000 Russell L. Carter wrote: > Greetings, > > It is not easy to get kame up and running, and I know this because > I have. It is beyond all ordinary production installations. Wow.. I have never had a problem installing it.. but of course I have worked in U**X for 20+ years... so maybe I don't notice and am not a good example :-9 > > And as Craig notes it's not possible[1] in the 5* line > yet. Maybe Randall would like to chip in on whether BSD SCTP > is ready for prime time in FreeBSD. But do not underestimate > the gains this protocol provides for fault tolerant > server applications. The 5* port is on my radar... as I just posted in my cross post). The 4* is ready for prime time IMO, I do have a few bugs that need addressing (I will get to them next week I hope ...sigh) R > > Russell > > [1] It's been two months since I tried. > > : > : On Thu, Oct 21, 2004 at 09:32:48PM +0200, Marco Molteni wrote: > : > SCTP in KAME is complete, stable and fully supported. > : > It is mainly developed by the SCTP RFC author, Randall Stewart. > : > : Randall has been maintaining his SCTP stack on FreeBSD 4.x, > : OpenBSD, and NetBSD. It has recently been ported to Darwin. > : > : > : > > : > A T/TCP alternative as you are describing sounds very > : > similar to PR-SCTP (Partial Reliability SCTP). (Don't let the > : > name fool you, please read the internet draft). > : > : Interesting stuff: > : http://www.portaroo.net/ietf/idref/draft-ietf-tsvwg-prsctp/ > : > : > > : > There is at least another kernel-level open source implementation, > : > for Linux, plus other user-level implementations. > : > : There is one kernel implementation of SCTP in > : the Linux 2.6 series of kernels ( http://lksctp.sourceforge.net ), > : and another kernel level implementation available separately > : ( http://www.openss7.org/sctp.html ). > : > : SCTP is an IETF standard, and a lot of people are getting interested > : in it. It would be nice to have it in FreeBSD, especially since > : it is showing up in the Linux distributions. > : > : The only issue with Randall's implementation is that > : it is only for 4.x.....I looked a while back at porting it to 5.x/CURRENT.... > : there is some work that needs to be done, i.e. using > : the new zone(9) API for allocating memory, and probably also > : getting the locking right. > : > : I don't know how much overlap there is with what Andre is going to > : implement, but I thought I would throw the information out there > : for those who may be interested. :) > : > : -- > : Craig Rodrigues > : http://crodrigues.org > : rodrigc@crodrigues.org > : _______________________________________________ > : freebsd-net@freebsd.org mailing list > : http://lists.freebsd.org/mailman/listinfo/freebsd-net > : To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 13:24:12 2004 Return-Path: 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 17B8316A4CE; Sat, 23 Oct 2004 13:24:12 +0000 (GMT) Received: from stewart.chicago.il.us (dpc674425142.direcpc.com [67.44.25.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A73843D69; Sat, 23 Oct 2004 13:24:09 +0000 (GMT) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (localhost [127.0.0.1]) i9NDO3tr031523; Sat, 23 Oct 2004 09:24:06 -0400 (EDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <417A5B28.9080308@stewart.chicago.il.us> Date: Sat, 23 Oct 2004 09:22:48 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org References: <20041021183238.00E8977A9D0@guns.icir.org> In-Reply-To: <20041021183238.00E8977A9D0@guns.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: Removing T/TCP and replacing it with something simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 13:24:12 -0000 Mark Allman wrote: >>Sure. To make you sleep better it will be disabled by default (like >>T/TCP) and possibly even not compliled in by default (#ifdef'd). > > > Part of your argument against T/TCP. :-) > > >>A writeup will follow once I get there. I made this request before I >>start working on it to prevent to waste my time on it if people wanted >>to religiously stick to T/TCP. > > > I think moving on from T/TCP is fine, don't get me wrong. And, I am all > for seeing new schemes that buy us some of the things T/TCP was designed > for. I am just not enthusiastic about dumping things into the kernel > without some review and thought (by more than one person; and, that is > not a knock on you --- if I had a nickel for every half-baked thing I'd > implemented somewhere .... basically, it's good to get different > perspectives). > > Doing this in a systematic way may have benefits beyond FreeBSD, as > well, of course. I would rather have Andre work with me to get any other rinkles out of SCTP that he deems are there... and get the KAME-SCTP stack ported directly in to FreeBSD.. this IMO ... would make more sense... Get something that is pretty well baked (IMO at least) and work to get it "productionized" (even though I don't feel it needs much work in this vein)... R > > allman > > > -- Randall Stewart 803-345-0369 815-342-5222(cell) From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 14:16:46 2004 Return-Path: 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 B8B2516A4CE for ; Sat, 23 Oct 2004 14:16:46 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF71943D3F for ; Sat, 23 Oct 2004 14:16:45 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 96072 invoked from network); 23 Oct 2004 14:15:01 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Oct 2004 14:15:01 -0000 Message-ID: <417A67CC.90E11C98@freebsd.org> Date: Sat, 23 Oct 2004 16:16:44 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randall Stewart References: <4177C8AD.6060706@freebsd.org> <20041021153933.GK13756@empiric.icir.org> <4177E25E.804639E@freebsd.org> <20041021213248.223cab2c.molter@tin.it> <4179ACB8.4020108@ieee.org> <417A572A.9080306@stewart.chicago.il.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org cc: SUZUKI Shinsuke cc: freebsd-net@freebsd.org Subject: SCTP in FreeBSD 5.x/current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 14:16:46 -0000 Randall Stewart wrote: > Anyway.. I do think it is stable enough for inclusion in > stable BSD... if you have another 4.x round.. BUT we have > not went in and fully got things working on 5.x... I know > one of our team members (Kozuka-san) has made an effort > to make it compile.. but it as yet does not function :-0 > > I also, before patch 25, would like to finish a third round > of performance optimization. I finally have a second machine > with a Gig-E interface and 2.XMhz .. so I think I can > try to squeak it up a bit more... ah.. plans for next > week if I can find the cycles :-o > > Anyway.. after patch-25 I intend on taking my new machine > to the 5.3 strain and trying to figure out what I need > to do to make it work :-0 (maybe patch26 :-D) Randall, I'm willing to work with you to get SCTP into FreeBSD-CURRENT. All new stuff has to go into -current first before it is allowed to be backported to 5.x and 4.x. -current and 5.x are not much different so a port by you to 5.x will usually work with -current as well. What I can't do is extensive porting/testing of SCTP. But I can "hold your hand" and support you from the FreeBSD team side. The largest difference between 4.x and 5.x is proper SMP locking. The socket layer is fine-grained SMP locked and the underlying transport protocols have to be aware of that to get decent performance. But we can work that out based on the experience we have with locking down the TCP code. Don't be afraid, that way it's less hard than it seems on the first glance. But nontheless having a simple and more secure replacement for T/TCP is a worthwile goal and I will do it, even if just for fun. Keeps me sharp on the TCP code. ;-) -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 16:01:18 2004 Return-Path: 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 248D716A4D0; Sat, 23 Oct 2004 16:01:18 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 821C843D46; Sat, 23 Oct 2004 16:01:17 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1CLOKS-000IJt-RJ; Sat, 23 Oct 2004 09:01:16 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16762.32844.243298.206348@ran.psg.com> Date: Sat, 23 Oct 2004 09:01:16 -0700 To: Peter Lei References: <4177C8AD.6060706@freebsd.org> <4177E25E.804639E@freebsd.org> <4179ACB8.4020108@ieee.org> cc: freebsd-net@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: SCTP in KAME / Re: Removing T/TCP and replacing itwithsomething simpler X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 16:01:18 -0000 dunno if i am the randy you meant to invoke, but sctp is far more usable and used than t/tcp. but it is not widely used yet. it very well may be. i think it would be good to support it, and i have zero qualms about dumping t/tcp. randy From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 16:12:22 2004 Return-Path: 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 7A4A616A535 for ; Sat, 23 Oct 2004 16:12:22 +0000 (GMT) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id F154043D1D for ; Sat, 23 Oct 2004 16:12:21 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] (pool-68-160-246-51.ny325.east.verizon.net [68.160.246.51]) by pi.codefab.com (8.12.11/8.12.11) with ESMTP id i9NGBqva064562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Oct 2004 12:12:16 -0400 (EDT) Message-ID: <417A82BD.1090100@mac.com> Date: Sat, 23 Oct 2004 12:11:41 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane Raimbault References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.5 tests=none autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pi.codefab.com cc: net@freebsd.org Subject: Re: using natd to load balance port 80 to multiple servers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 16:12:22 -0000 Stephane Raimbault wrote: > I'm currently using a freebsd box running natd to forward port 80 to > several (5) web servers on private IP's. OK. > I have discovered that natd doesn't handle many requests/second all that > well (seem to choke at about 200 req/second (educated guess)) Let's take that number as being right, although the first consideration when doing performance tuning is that you need to measure things accurately enough that you can see whether a change makes a meaningful difference. There are plenty of tools available in the ports tree, although you could start with "ab" from apache. Next, you ought to read "man tuning" and look into adjusting HZ, NMBCLUSTERS in your kernel config, using any hardware support for your NICs (-link0 option) or try using device polling. You should probably investigate the net.inet sysctls, particularly those controlling retransmit time intervals net.inet.tcp.rexmit_min and the keepalive and net.inet.ip.fw.dyn*lifetime tunables. > There are other packet filtering options on FreeBSD and I wonder if I > can use them to do what I'm trying to do with natd. It's true that natd runs in userspace, which creates more overhead, so using PF instead might be worth doing, sure. > Would someone be able to point me to documentation or help me have > either ipf/ipfw/pf forward port 80 traffic to private space IP's? Consider http://www.openbsd.org/faq/pf/index.html > Is there a better way of split port 80 traffic across multiple > webservers that has elduded me? Other then a comercial content switch > that is :) Oh, sure. The most obvious solution to the problem is to give all of the servers real IPs and use some other form of balancing (DNS round-robin, or splitting the content somehow [static vs dynamicly generated?]), and avoid dealing with NAT altogether. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 16:52:19 2004 Return-Path: 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 0D42F16A4CE for ; Sat, 23 Oct 2004 16:52:19 +0000 (GMT) Received: from segfault-outgoing-helo.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBBD743D1D for ; Sat, 23 Oct 2004 16:52:18 +0000 (GMT) (envelope-from rfg@monkeys.com) Received: from segfault-nmh-helo.monkeys.com (localhost [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id 7A38E54A7; Sat, 23 Oct 2004 09:52:18 -0700 (PDT) To: Igor Sysoev In-reply-to: Your message of Sat, 23 Oct 2004 00:25:30 +0400. <20041023002300.I91215@is.park.rambler.ru> Date: Sat, 23 Oct 2004 09:52:18 -0700 Message-ID: <7208.1098550338@monkeys.com> From: "Ronald F. Guilmette" cc: freebsd-net@freebsd.org Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 16:52:19 -0000 In message <20041023002300.I91215@is.park.rambler.ru>, you wrote: >On Thu, 21 Oct 2004, Ronald F. Guilmette wrote: > >> >I believe if you want to build a more maintainable, more adaptable, >> >more modularized program then you should avoid two things - the threads and >> >the signals. If you like to use a callback behaviour of the signals you could >> >easy implement it without any signal. >> >> OK. I'll bite. How? > >I'm sure you know it. Don't be too sure. The number of things that I _don't_ know is enormous! >Sorry, English is not my native language so I may >tell you only shortly. Your English seems perfect to me. >You can use two notification models. First is the socket readiness >for operations, second is the operation completeness. >In the first model you use usual read()/write() operations and learn >readiness using select()/poll()/kevent(). Correct, but that requires either (a) waiting or else (b) constantly re- checking the status without waiting, over and overt again. The efficiency of (b) is obviously very low, so most people, myself in- cluded, never want to use that approach. In the case if (a), as I have noted, if you have a program that is per- foprming operations of, say, _several_ different independent socket connections, then if you also have a "modular" program in which each module only uses select()/poll()/kevent() to wait for completion on the specific socket that it is handling, then the (bad) effect is that completions of various operations on _other_ sockets (that are being handled) by other/different modules) may not be serviced in a timely fashion, which can be very bad. or at least very inefficient. >In the second model you use aio_read()/aio_write() operations and learn >about their completeness using aio_suspend()/aio_waitcomplete()/kevent(). These are, I believe, just other ways of doing "polling" for completion, and they thus suffer all of the same problems as polling via select(), or poll(), or kevent(). >After you have got the notifications you would call your callback handlers >as well as the kernel would call your signal handlers. Yes, I do see what you mean here. However I can only say again that using aio_*() functions with their signaling capabilities provides the programmer with a totally asynchronous notification of the completion of _individual_ I/O operations, and that this is fundamentally different, semantically, from the kind of synchronous polling for completion of any one of a _set_ of pending I/O operations that may be performed via select(), or poll(), or kevent(), or aio_suspend(). Thus, I still do believe that the judicious use of the aio_*() functions with signaling could support a dramatically different programming style, especially for complex network clients and/or servers that must monitor and respond to events on various kinds of socket connections, all in the same single program. From owner-freebsd-net@FreeBSD.ORG Sat Oct 23 22:06:20 2004 Return-Path: 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 583A516A4CE for ; Sat, 23 Oct 2004 22:06:20 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08C8C43D45 for ; Sat, 23 Oct 2004 22:06:20 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id EA7EB654C2; Sat, 23 Oct 2004 23:06:18 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09923-02-4; Sat, 23 Oct 2004 23:06:18 +0100 (BST) Received: from empiric.dek.spc.org (dhcp120.icir.org [192.150.187.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id D145E65476; Sat, 23 Oct 2004 23:06:13 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 694D561CB; Sat, 23 Oct 2004 15:06:05 -0700 (PDT) Date: Sat, 23 Oct 2004 15:06:05 -0700 From: Bruce M Simpson To: "Ronald F. Guilmette" Message-ID: <20041023220605.GA810@empiric.icir.org> Mail-Followup-To: "Ronald F. Guilmette" , Igor Sysoev , freebsd-net@freebsd.org References: <20041023002300.I91215@is.park.rambler.ru> <7208.1098550338@monkeys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7208.1098550338@monkeys.com> cc: freebsd-net@freebsd.org cc: Igor Sysoev Subject: Re: aio_connect ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Oct 2004 22:06:20 -0000 On Sat, Oct 23, 2004 at 09:52:18AM -0700, Ronald F. Guilmette wrote: > or kevent(), or aio_suspend(). Thus, I still do believe that the judicious > use of the aio_*() functions with signaling could support a dramatically > different programming style, especially for complex network clients and/or > servers that must monitor and respond to events on various kinds of socket > connections, all in the same single program. As was pointed out earlier, it requires POSIX realtime signal support to become useful in this way. I have programmed in this way under Solaris, for what it's worth; I implemented an httpd server using aio calls and real-time signals a few years ago, and the performance as compared to a select()/poll() based server turned out to be far worse, at least in terms of the number of requests per second it was able to handle. I don't recall specific figures. So I would regard it as largely a red herring; the kqueue/kevent mechanism will yield somewhat finer granularity in terms of polling for an i/o completion event from userland on FreeBSD, which seems to be what you're trying to achieve. aio and realtime signals is something we don't really do at the moment. Regards, BMS