From owner-freebsd-net Sun May 6 1:44:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from lu.pine.nl (lu.pine.nl [213.156.0.240]) by hub.freebsd.org (Postfix) with ESMTP id E1FFD37B424 for ; Sun, 6 May 2001 01:44:34 -0700 (PDT) (envelope-from mark@pine.nl) Received: by lu.pine.nl (Postfix, from userid 96) id EB10122B3F; Sun, 6 May 2001 10:42:55 +0200 (MET DST) Received: from atro.pine.nl (atro.pine.nl [213.156.0.2]) by lu.pine.nl (Postfix) with ESMTP id B7B9E1E134; Sun, 6 May 2001 10:42:51 +0200 (MET DST) Date: Sun, 6 May 2001 10:44:29 +0200 (MET DST) From: Mark Lastdrager To: Christopher Leigh Cc: Subject: Re: i can get linux to do ab -c 150 -n 2000 http://127.0.0.1 no sweat; what In-Reply-To: <20010506021058.7518.qmail@lubbockcomputer.com> Message-ID: X-NCC-RegID: nl.pine MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 6 May 2001, owner-freebsd-net@FreeBSD.ORG wrote: >~# /www/bin/ab -c 150 -n 2000 http://127.0.0.1/ >This is ApacheBench, Version 1.3c <$Revision: 1.44 $> apache-1.3 >Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, >http://www.zeustech.net/ >Copyright (c) 1998-2000 The Apache Group, http://www.apache.org/ > >Server Software: Apache/1.3.19 >Server Hostname: 127.0.0.1 >Server Port: 80 > >Document Path: / >Document Length: 1310 bytes > >Concurrency Level: 150 >Time taken for tests: 284.256 seconds >Complete requests: 2000 >Failed requests: 0 >Total transferred: 3536325 bytes >HTML transferred: 2639650 bytes >Requests per second: 7.04 >Transfer rate: 12.44 kb/s received > >Connnection Times (ms) > min avg max >Connect: 7 10667 53372 >Processing: 1247 10154 32805 >Total: 1254 20821 86177 >~# > >it usually takes about 20 seconds for linux to do it. > >how do i configure freebsd to be able to do it? I think there's something wrong with your setup. This is my 4.3-STABLE output on a PII-350 (I even didn't change anything with sysctl): (mark@a /~) /usr/local/apache/bin/ab -c 150 -n 2000 http://127.0.0.1 This is ApacheBench, Version 1.3c <$Revision: 1.41 $> apache-1.3 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/ Server Software: Apache/1.3.14 Server Hostname: 127.0.0.1 Server Port: 80 Document Path: / Document Length: 1358 bytes Concurrency Level: 150 Time taken for tests: 25.983 seconds Complete requests: 2000 Failed requests: 0 Total transferred: 3687532 bytes HTML transferred: 2825998 bytes Requests per second: 76.97 Transfer rate: 141.92 kb/s received Connnection Times (ms) min avg max Connect: 0 530 1369 Processing: 148 1321 2329 Total: 148 1851 3698 Mark Lastdrager -- Pine Internet BV :: tel. +31-70-3111010 :: fax. +31-70-3111011 PGP 92BB81D1 fingerprint 0059 7D7B C02B 38D2 A853 2785 8C87 3AF1 Today's excuse: Backbone adjustment To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 6 1:57:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from rose.niw.com.au (app3022-2.gw.connect.com.au [203.63.119.4]) by hub.freebsd.org (Postfix) with ESMTP id C6EA737B424 for ; Sun, 6 May 2001 01:57:32 -0700 (PDT) (envelope-from ian@niw.com.au) Received: from localhost (localhost [127.0.0.1]) by rose.niw.com.au (Postfix) with ESMTP id 69E2D111319 for ; Sun, 6 May 2001 18:27:30 +0930 (CST) Received: by rose.niw.com.au (Postfix, from userid 1000) id 0A08B111318; Sun, 6 May 2001 18:27:28 +0930 (CST) Date: Sun, 6 May 2001 18:27:28 +0930 From: Ian West To: freebsd-net@freebsd.org Subject: Netgraph/fxp/pppoe causing system panic in 4.3 stable. Message-ID: <20010506182728.L1899@rose.niw.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a reproducible kernel panic in 4.3 stable caused (sort of) by netgraph, or maybe by fxp0 in conjunction with pppoe. It is caused by setting up and attempting to open a pppoe connection over an fxp interface, due to fxp_start being called before fxp device has been opened. (This only occurs if the fxp interface has not been configured in any way since since boot.) Maybe if ethernet if has not been opened, and is down, it should be brought up by opening it for pppoe similar to ifconfig bringing it up when an ip address is assigned ? Causing the fault is as simple as running user land ppp, configuring 'set line pppoe:fxp0' and then trying to open the link. Backtrace is as follows. #0 0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083 #1 0xc01e4de4 in ether_output_frame (ifp=0xc0cbea00, m=0xc09d3d00) at ../../net/if_ethersubr.c:399 #2 0xc01fac2c in ng_ether_rcv_lower (node=0xc0cd3100, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_ether.c:629 #3 0xc01fab55 in ng_ether_rcvdata (hook=0xc0e0bf40, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_ether.c:595 #4 0xc01f8401 in ng_send_data (hook=0xc0e0bfc0, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_base.c:1648 #5 0xc01fc6e9 in sendpacket (sp=0xc0e0f840) at ../../netgraph/ng_pppoe.c:1451 #6 0xc01fb99e in pppoe_start (sp=0xc0e0f840) at ../../netgraph/ng_pppoe.c:754 #7 0xc01fb824 in ng_pppoe_rcvmsg (node=0xc0da8ac0, msg=0xc0e0f800, retaddr=0xc0e0bf00 "[7]:", rptr=0xc643fe28) at ../../netgraph/ng_pppoe.c:660 #8 0xc01f7925 in ng_send_msg (here=0xc0d607c0, msg=0xc0e0f800, address=0xc0cd4650 ".:tun0", rptr=0xc643fe28) at ../../netgraph/ng_base.c:1180 #9 0xc01fc954 in ngc_send (so=0xc5d5dc00, flags=0, m=0xc09e1f00, addr=0xc0cd4620, control=0x0, p=0xc5f44700) at ../../netgraph/ng_socket.c:242 #10 0xc01bffcb in sosend (so=0xc5d5dc00, addr=0xc0cd4620, uio=0xc643fed0, top=0xc09e1f00, control=0x0, flags=0, p=0xc5f44700) at ../../kern/uipc_socket.c:611 #11 0xc01c377f in sendit (p=0xc5f44700, s=2, mp=0xc643ff10, flags=0) at ../../kern/uipc_syscalls.c:583 #12 0xc01c3882 in sendto (p=0xc5f44700, uap=0xc643ff80) at ../../kern/uipc_syscalls.c:636 #13 0xc03340ad in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077941491, tf_esi = -1077941498, tf_ebp = -1077940984, tf_isp = -968622124, tf_ebx = 672834760, tf_edx = -1077941500, tf_ecx = -1077941500, tf_eax = 133, tf_trapno = 7, tf_err = 2, tf_eip = 673075808, tf_cs = 31, tf_eflags = 518, tf_esp = -1077941588, tf_ss = 47}) at ../../i386/i386/trap.c:1150 Program received signal SIGSEGV, Segmentation fault. 0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083 1083 txp = sc->cbl_last->next; (kgdb) print sc $1 = (struct fxp_softc *) 0xc0cbea00 (kgdb) print sc->cbl_last $2 = (struct fxp_cb_tx *) 0x0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 6 4:41:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 2987D37B422 for ; Sun, 6 May 2001 04:40:59 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f46BeVq25548; Sun, 6 May 2001 12:40:35 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f46BeuB54870; Sun, 6 May 2001 12:40:56 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105061140.f46BeuB54870@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Ian West Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Netgraph/fxp/pppoe causing system panic in 4.3 stable. In-Reply-To: Message from Ian West of "Sun, 06 May 2001 18:27:28 +0930." <20010506182728.L1899@rose.niw.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 May 2001 12:40:56 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org PPPoE now brings the interface IFF_UP before using it, but this isn't the right solution (someone could manually down it again). fxp should just drop data if it's not up. > I have a reproducible kernel panic in 4.3 stable caused (sort of) by > netgraph, or maybe by fxp0 in conjunction with pppoe. It is caused by > setting up and attempting to open a pppoe connection over an fxp > interface, due to fxp_start being called before fxp device has been > opened. (This only occurs if the fxp interface has not been configured > in any way since since boot.) > > Maybe if ethernet if has not been opened, and is down, it should be brought up > by opening it for pppoe similar to ifconfig bringing it up when an ip > address is assigned ? > > Causing the fault is as simple as running user land ppp, configuring 'set line > pppoe:fxp0' and then trying to open the link. > > Backtrace is as follows. > #0 0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083 > #1 0xc01e4de4 in ether_output_frame (ifp=0xc0cbea00, m=0xc09d3d00) at ../../net/if_ethersubr.c:399 > #2 0xc01fac2c in ng_ether_rcv_lower (node=0xc0cd3100, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_ether.c:629 > #3 0xc01fab55 in ng_ether_rcvdata (hook=0xc0e0bf40, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_ether.c:595 > #4 0xc01f8401 in ng_send_data (hook=0xc0e0bfc0, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_base.c:1648 > #5 0xc01fc6e9 in sendpacket (sp=0xc0e0f840) at ../../netgraph/ng_pppoe.c:1451 > #6 0xc01fb99e in pppoe_start (sp=0xc0e0f840) at ../../netgraph/ng_pppoe.c:754 > #7 0xc01fb824 in ng_pppoe_rcvmsg (node=0xc0da8ac0, msg=0xc0e0f800, retaddr=0xc0e0bf00 "[7]:", rptr=0xc643fe28) > at ../../netgraph/ng_pppoe.c:660 > #8 0xc01f7925 in ng_send_msg (here=0xc0d607c0, msg=0xc0e0f800, address=0xc0cd4650 ".:tun0", rptr=0xc643fe28) > at ../../netgraph/ng_base.c:1180 > #9 0xc01fc954 in ngc_send (so=0xc5d5dc00, flags=0, m=0xc09e1f00, addr=0xc0cd4620, control=0x0, p=0xc5f44700) > at ../../netgraph/ng_socket.c:242 > #10 0xc01bffcb in sosend (so=0xc5d5dc00, addr=0xc0cd4620, uio=0xc643fed0, top=0xc09e1f00, control=0x0, flags=0, p=0xc5f44700) > at ../../kern/uipc_socket.c:611 > #11 0xc01c377f in sendit (p=0xc5f44700, s=2, mp=0xc643ff10, flags=0) at ../../kern/uipc_syscalls.c:583 > #12 0xc01c3882 in sendto (p=0xc5f44700, uap=0xc643ff80) at ../../kern/uipc_syscalls.c:636 > #13 0xc03340ad in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077941491, tf_esi = -1077941498, tf_ebp = -1077940984, > tf_isp = -968622124, tf_ebx = 672834760, tf_edx = -1077941500, tf_ecx = -1077941500, tf_eax = 133, tf_trapno = 7, tf_err = 2, > tf_eip = 673075808, tf_cs = 31, tf_eflags = 518, tf_esp = -1077941588, tf_ss = 47}) at ../../i386/i386/trap.c:1150 > > Program received signal SIGSEGV, Segmentation fault. > 0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083 > 1083 txp = sc->cbl_last->next; > > (kgdb) print sc > $1 = (struct fxp_softc *) 0xc0cbea00 > (kgdb) print sc->cbl_last > $2 = (struct fxp_cb_tx *) 0x0 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 6 6:38:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id 18FEC37B422 for ; Sun, 6 May 2001 06:38:06 -0700 (PDT) (envelope-from matt@gsicomp.on.ca) Received: from xena.gsicomp.on.ca ([64.228.153.241]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010506133805.CGXS25498.tomts13-srv.bellnexxia.net@xena.gsicomp.on.ca>; Sun, 6 May 2001 09:38:05 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id f46DZTN33443; Sun, 6 May 2001 09:35:29 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <002301c0d631$02440e50$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Brian Somers" Cc: , References: <200105061140.f46BeuB54870@hak.lan.Awfulhak.org> Subject: Re: Netgraph/fxp/pppoe causing system panic in 4.3 stable. Date: Sun, 6 May 2001 09:32:33 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm not sure if it's just fxp0 -- a few weeks ago a few people reported this very same problem with PPPoE for cards other than fxp0. Adding an ifconfig_xxx="up" to /etc/rc.conf (as suggested by an article on daemonnews or freebsddiary) "fixed" the problems for the people that I heard about -- but you're right that it isn't the best solution. The problem is this: if a card is down, it's because a) it's never been configured or b) it was downed manually. In the former case, we want PPPoE to initialize and start using the card (since you'd never have to initialize the NIC being used for PPPoE.) However, in case b), the driver should just ignore the data. How can we differentiate between case a) and case b)? I could see some admins getting pretty peeved if they 'ifconfig down fxp0' and then a few seconds later, PPPoE brings the interface back up to send data. (Of course, it would be better to kill the PPPoE daemon first before doing that, but...) > PPPoE now brings the interface IFF_UP before using it, but this isn't > the right solution (someone could manually down it again). > > fxp should just drop data if it's not up. > > > I have a reproducible kernel panic in 4.3 stable caused (sort of) by > > netgraph, or maybe by fxp0 in conjunction with pppoe. It is caused by > > setting up and attempting to open a pppoe connection over an fxp > > interface, due to fxp_start being called before fxp device has been > > opened. (This only occurs if the fxp interface has not been configured > > in any way since since boot.) > > > > Maybe if ethernet if has not been opened, and is down, it should be brought up > > by opening it for pppoe similar to ifconfig bringing it up when an ip > > address is assigned ? > > > > Causing the fault is as simple as running user land ppp, configuring 'set line > > pppoe:fxp0' and then trying to open the link. > > > > Backtrace is as follows. > > #0 0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083 > > #1 0xc01e4de4 in ether_output_frame (ifp=0xc0cbea00, m=0xc09d3d00) at ../../net/if_ethersubr.c:399 > > #2 0xc01fac2c in ng_ether_rcv_lower (node=0xc0cd3100, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_ether.c:629 > > #3 0xc01fab55 in ng_ether_rcvdata (hook=0xc0e0bf40, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_ether.c:595 > > #4 0xc01f8401 in ng_send_data (hook=0xc0e0bfc0, m=0xc09d3d00, meta=0x0) at ../../netgraph/ng_base.c:1648 > > #5 0xc01fc6e9 in sendpacket (sp=0xc0e0f840) at ../../netgraph/ng_pppoe.c:1451 > > #6 0xc01fb99e in pppoe_start (sp=0xc0e0f840) at ../../netgraph/ng_pppoe.c:754 > > #7 0xc01fb824 in ng_pppoe_rcvmsg (node=0xc0da8ac0, msg=0xc0e0f800, retaddr=0xc0e0bf00 "[7]:", rptr=0xc643fe28) > > at ../../netgraph/ng_pppoe.c:660 > > #8 0xc01f7925 in ng_send_msg (here=0xc0d607c0, msg=0xc0e0f800, address=0xc0cd4650 ".:tun0", rptr=0xc643fe28) > > at ../../netgraph/ng_base.c:1180 > > #9 0xc01fc954 in ngc_send (so=0xc5d5dc00, flags=0, m=0xc09e1f00, addr=0xc0cd4620, control=0x0, p=0xc5f44700) > > at ../../netgraph/ng_socket.c:242 > > #10 0xc01bffcb in sosend (so=0xc5d5dc00, addr=0xc0cd4620, uio=0xc643fed0, top=0xc09e1f00, control=0x0, flags=0, p=0xc5f44700) > > at ../../kern/uipc_socket.c:611 > > #11 0xc01c377f in sendit (p=0xc5f44700, s=2, mp=0xc643ff10, flags=0) at ../../kern/uipc_syscalls.c:583 > > #12 0xc01c3882 in sendto (p=0xc5f44700, uap=0xc643ff80) at ../../kern/uipc_syscalls.c:636 > > #13 0xc03340ad in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077941491, tf_esi = -1077941498, tf_ebp = -1077940984, > > tf_isp = -968622124, tf_ebx = 672834760, tf_edx = -1077941500, tf_ecx = -1077941500, tf_eax = 133, tf_trapno = 7, tf_err = 2, > > tf_eip = 673075808, tf_cs = 31, tf_eflags = 518, tf_esp = -1077941588, tf_ss = 47}) at ../../i386/i386/trap.c:1150 > > > > Program received signal SIGSEGV, Segmentation fault. > > 0xc0289b06 in fxp_start (ifp=0xc0cbea00) at ../../pci/if_fxp.c:1083 > > 1083 txp = sc->cbl_last->next; > > > > (kgdb) print sc > > $1 = (struct fxp_softc *) 0xc0cbea00 > > (kgdb) print sc->cbl_last > > $2 = (struct fxp_cb_tx *) 0x0 > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 6 7:25:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 32A3537B424 for ; Sun, 6 May 2001 07:25:12 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f46EOwq26018; Sun, 6 May 2001 15:24:58 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f46EPMB56450; Sun, 6 May 2001 15:25:22 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105061425.f46EPMB56450@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Matthew Emmerton" Cc: "Brian Somers" , freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Netgraph/fxp/pppoe causing system panic in 4.3 stable. In-Reply-To: Message from "Matthew Emmerton" of "Sun, 06 May 2001 09:32:33 EDT." <002301c0d631$02440e50$1200a8c0@gsicomp.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 May 2001 15:25:22 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I guess the key question is whether PPPoE should use the interface if it's not IFF_UP. If it shouldn't, the interface should drop the data on the floor. If it should, the interface should just deal with it. I'd suggest that we should fix the guilty interfaces and automatically ``ifconfig iface up'' from the rc script. ppp shouldn't be bringing the interface up itself. > I'm not sure if it's just fxp0 -- a few weeks ago a few people reported this > very same problem with PPPoE for cards other than fxp0. > Adding an ifconfig_xxx="up" to /etc/rc.conf (as suggested by an article on > daemonnews or freebsddiary) "fixed" the problems for the people that I heard > about -- but you're right that it isn't the best solution. > > The problem is this: if a card is down, it's because a) it's never been > configured or b) it was downed manually. In the former case, we want PPPoE > to initialize and start using the card (since you'd never have to initialize > the NIC being used for PPPoE.) However, in case b), the driver should just > ignore the data. > > How can we differentiate between case a) and case b)? I could see some > admins getting pretty peeved if they 'ifconfig down fxp0' and then a few > seconds later, PPPoE brings the interface back up to send data. (Of course, > it would be better to kill the PPPoE daemon first before doing that, but...) > > > PPPoE now brings the interface IFF_UP before using it, but this isn't > > the right solution (someone could manually down it again). > > > > fxp should just drop data if it's not up. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 6 8: 8:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id A45BF37B422 for ; Sun, 6 May 2001 08:08:24 -0700 (PDT) (envelope-from matt@gsicomp.on.ca) Received: from xena.gsicomp.on.ca ([64.228.153.241]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010506150823.DCEA25498.tomts13-srv.bellnexxia.net@xena.gsicomp.on.ca>; Sun, 6 May 2001 11:08:23 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id f46F5mN33588; Sun, 6 May 2001 11:05:48 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <007b01c0d63d$a0adaea0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Brian Somers" Cc: References: <200105061425.f46EPMB56450@hak.lan.Awfulhak.org> Subject: Re: Netgraph/fxp/pppoe causing system panic in 4.3 stable. Date: Sun, 6 May 2001 11:02:53 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org However, in 3.4, netgraph + pppoe didn't require "ifconfig iface up" in rc.conf in order to use PPPoE, but that requirement has been in 4.x from the beginning. The big question is, why did this behaviour change? (Insert POLA argument here.) I can't really see why we shoudl be forcing users to "ifconfig iface up" their ethernet NIC in rc.conf, when it's really abstracted away by PPPoE -- netgraph should look after bringing the interface up, and perhaps complain loudly if someone should down it while it's being used. (I'm thinking that the control of the interface should lie under netgraph and it's tools, not standard userland tools like ifconfig, for "abstracted" cases like this.) > I guess the key question is whether PPPoE should use the interface if > it's not IFF_UP. > > If it shouldn't, the interface should drop the data on the floor. > > If it should, the interface should just deal with it. > > I'd suggest that we should fix the guilty interfaces and > automatically ``ifconfig iface up'' from the rc script. ppp > shouldn't be bringing the interface up itself. > > > I'm not sure if it's just fxp0 -- a few weeks ago a few people reported this > > very same problem with PPPoE for cards other than fxp0. > > Adding an ifconfig_xxx="up" to /etc/rc.conf (as suggested by an article on > > daemonnews or freebsddiary) "fixed" the problems for the people that I heard > > about -- but you're right that it isn't the best solution. > > > > The problem is this: if a card is down, it's because a) it's never been > > configured or b) it was downed manually. In the former case, we want PPPoE > > to initialize and start using the card (since you'd never have to initialize > > the NIC being used for PPPoE.) However, in case b), the driver should just > > ignore the data. > > > > How can we differentiate between case a) and case b)? I could see some > > admins getting pretty peeved if they 'ifconfig down fxp0' and then a few > > seconds later, PPPoE brings the interface back up to send data. (Of course, > > it would be better to kill the PPPoE daemon first before doing that, but...) > > > > > PPPoE now brings the interface IFF_UP before using it, but this isn't > > > the right solution (someone could manually down it again). > > > > > > fxp should just drop data if it's not up. > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 6 17:36:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from thor.oit.pdx.edu (thor.oit.pdx.edu [131.252.120.40]) by hub.freebsd.org (Postfix) with ESMTP id C977837B424; Sun, 6 May 2001 17:36:11 -0700 (PDT) (envelope-from singh@pdx.edu) Received: from gere.odin.pdx.edu (gere.odin.pdx.edu [131.252.120.42]) by thor.oit.pdx.edu (8.11.1/8.11.1) with ESMTP id f470aAl01840; Sun, 6 May 2001 17:36:11 -0700 (PDT) Received: from localhost (singh@localhost) by gere.odin.pdx.edu (8.11.1/8.11.1) with ESMTP id f470aAl24073; Sun, 6 May 2001 17:36:10 -0700 (PDT) X-Authentication-Warning: gere.odin.pdx.edu: singh owned process doing -bs Date: Sun, 6 May 2001 17:36:10 -0700 (PDT) From: Harkirat Singh X-X-Sender: To: Cc: Subject: TCP timers - callout In-Reply-To: <20010420113920.31958.qmail@web12903.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! I am doing a project and wanted to copy the value of tcp timers for my own use, in the earlier versions (2.2.7 & 3.4) it was simple to copy the value of all the tcp timers as there was #define TCPT_NTIMERS and then one can simply copy these timers as tp->myt_rxtcur = tp->t_rxtcur; so own for all the four timers. I am working on Release-4.2 and found that it uses various callout() macros which register thse timers with the kernel and then kernel will check after cartian fix time about the status of the timers. I want to know is there any documentation about functionality of callout macros as Stevens Volume II does'nt have much of the details about it. Thanks, Harkirat Singh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun May 6 18:32:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 0486737B424 for ; Sun, 6 May 2001 18:32:32 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f471Vo650242; Sun, 6 May 2001 20:31:50 -0500 (CDT) (envelope-from jlemon) Date: Sun, 6 May 2001 20:31:50 -0500 (CDT) From: Jonathan Lemon Message-Id: <200105070131.f471Vo650242@prism.flugsvamp.com> To: singh@pdx.edu, net@freebsd.org Subject: Re: TCP timers - callout X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you write: >I want to know is there any documentation about functionality of >callout macros as Stevens Volume II does'nt have much of the details about >it. man 9 timeout -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 1:59:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from web5302.mail.yahoo.com (web5302.mail.yahoo.com [216.115.106.111]) by hub.freebsd.org (Postfix) with SMTP id 3BAD637B422 for ; Mon, 7 May 2001 01:59:42 -0700 (PDT) (envelope-from vishubp@yahoo.com) Message-ID: <20010507085942.25657.qmail@web5302.mail.yahoo.com> Received: from [203.200.20.3] by web5302.mail.yahoo.com; Mon, 07 May 2001 09:59:41 BST Date: Mon, 7 May 2001 09:59:41 +0100 (BST) From: =?iso-8859-1?q?vishwanath=20pargaonkar?= Subject: ping6/telnet To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i have freebsd 4.2 stable release. i have set up a ipv6 network. i dun know y ping6 is not working ie ping6 with linklocaladdress. ping6 -I interfacename linklocaladdress works fine. and telnet y is not working.ie telnet linklocaladdress will it not work? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 2:10:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from molly.straylight.com (molly.straylight.com [204.69.232.69]) by hub.freebsd.org (Postfix) with ESMTP id 9015537B422 for ; Mon, 7 May 2001 02:10:07 -0700 (PDT) (envelope-from jonathan@graehl.org) Received: from case (root@localhost [127.0.0.1]) by molly.straylight.com (8.11.0/8.10.0) with ESMTP id f4799hL11812 for ; Mon, 7 May 2001 02:09:43 -0700 From: "Jonathan Graehl" To: Subject: Do I need to close after shutdown if I don't want to leak descriptors? (making sure TCP retransmits all my data) Date: Mon, 7 May 2001 02:10:14 -0700 Message-ID: <000001c0d6d5$87607e80$6dfeac40@straylight.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2605 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Scenario: I accept a (TCP) connection, write some data, close the connection. Problem: close() does not perform an orderly shutdown, does not resend unacknowledged data - responds with RST to data/acks sent to me Non-solution: SO_LINGER, makes close into a blocking call in order to get orderly shutdown Incomplete solution: shutdown(SHUT_RDWR), but then what? Will the OS close the fd for me once the other end acknowledges, or better yet, closes its end as well, or do I need to close the fd? If so, how can I be notified when the other end acknowledges up to FIN (or timeout) in order to do so? (selecting for readable is not a solution; if they have sent me data I am uninterested in reading, I will select readable) Obviously, if shutdown fails (it shouldn't, I die on failure), you would need to close to avoid descriptor leakage. But do I need to babysit the descriptor after I have no more interest in it? Is there a ps-like tool with which I can easily inspect descriptor usage? This seems to be a very difficult question; I have found contradictory (and many obviously wrong) opinions so far, and Stevens' UNP doesn't address it at all (he seems unaware of the possibility, or else silently reliant on process termination freeing all descriptors). -- Jonathan Graehl http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 2:27:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2F47637B422 for ; Mon, 7 May 2001 02:27:27 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f479RQb22383; Mon, 7 May 2001 02:27:26 -0700 (PDT) Date: Mon, 7 May 2001 02:27:26 -0700 From: Alfred Perlstein To: Jonathan Graehl Cc: freebsd-net@FreeBSD.ORG Subject: Re: Do I need to close after shutdown if I don't want to leak descriptors? (making sure TCP retransmits all my data) Message-ID: <20010507022726.P18676@fw.wintelcom.net> References: <000001c0d6d5$87607e80$6dfeac40@straylight.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000001c0d6d5$87607e80$6dfeac40@straylight.com>; from jonathan@graehl.org on Mon, May 07, 2001 at 02:10:14AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Jonathan Graehl [010507 02:10] wrote: > Scenario: I accept a (TCP) connection, write some data, close the > connection. > > Problem: close() does not perform an orderly shutdown, does not resend > unacknowledged data - responds with RST to data/acks sent to me > > Non-solution: SO_LINGER, makes close into a blocking call in order to > get orderly shutdown Here's a trick that may work. use setsockopt to set SO_SNDLOWAT == SO_SNDBUF, when you get a writeable event back you know the socket is clear. this is good because you should be able to go back to using poll/kevent to monitor them. -- -Alfred Perlstein - [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 4:14:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 73A3D37B422 for ; Mon, 7 May 2001 04:14:47 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 83CC54B0B; Mon, 7 May 2001 20:14:45 +0900 (JST) To: =?iso-8859-1?q?vishwanath=20pargaonkar?= Cc: freebsd-net@freebsd.org In-reply-to: vishubp's message of Mon, 07 May 2001 09:59:41 +0100. <20010507085942.25657.qmail@web5302.mail.yahoo.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ping6/telnet From: itojun@iijlab.net Date: Mon, 07 May 2001 20:14:45 +0900 Message-ID: <7216.989234085@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >i have freebsd 4.2 stable release. >i have set up a ipv6 network. > i dun know y ping6 is not working ie ping6 with >linklocaladdress. > ping6 -I interfacename linklocaladdress > works fine. you MUST either: 1. specify the outgoing interface like "ping6 -I if0 linklocal" 2. specify the outgoing scope identifier, like "ping6 linklocal%if0" (KAME assumes that scope identifiers are interface name/index, for linklocal address > and telnet y is not working.ie >telnet linklocaladdress will it not work? similarly to 2, you MUST specify the outgoing scope identifier, like "telnet linklocal%if0". itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 7: 7:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.rinet.ru (relay.rinet.ru [195.54.192.35]) by hub.freebsd.org (Postfix) with ESMTP id 0E80737B424 for ; Mon, 7 May 2001 07:07:42 -0700 (PDT) (envelope-from yar@snark.rinet.ru) Received: from snark.rinet.ru (root@snark.rinet.ru [195.54.192.73]) by relay.rinet.ru (8.9.3/8.9.3) with ESMTP id SAA02643 for ; Mon, 7 May 2001 18:07:29 +0400 (MSD) X-Envelope-To: Received: (from yar@localhost) by snark.rinet.ru (8.11.3/8.11.3) id f47E7TW34764 for freebsd-net@freebsd.org; Mon, 7 May 2001 18:07:29 +0400 (MSD) (envelope-from yar) Date: Mon, 7 May 2001 18:07:29 +0400 From: Yar Tikhiy To: freebsd-net@freebsd.org Subject: ipfw & ifconfig in rc.network Message-ID: <20010507180729.A34655@snark.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, Is there any serious reason to load ipfw rules after configuring network interfaces? IMHO the right way is doing that in the reverse order. Incidentally, IPFilter rules are loaded before starting the interfaces, which leads to inconsistency as well. -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 10:56:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id 574AF37B422 for ; Mon, 7 May 2001 10:56:39 -0700 (PDT) (envelope-from gshapiro@gshapiro.net) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.0.Beta7/8.12.0.Beta7) id f47HuMQA024907; Mon, 7 May 2001 10:56:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15094.57798.682855.84630@horsey.gshapiro.net> Date: Mon, 7 May 2001 10:56:22 -0700 From: Gregory Neil Shapiro To: Sean Farley Cc: , Subject: Re: Solution: Sendmail outgoing bind() fails only PPP In-Reply-To: <20010427142517.K747-200000@thor.farley.org> References: <20010427142517.K747-200000@thor.farley.org> X-Mailer: VM 6.92 under 21.5 (beta0) "alfalfa" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sean-freebsd> I found the bug. The socket was IPv6, but the bind used an sean-freebsd> IPv4 sockaddr struct. Patch attached. sean-freebsd> - s = socket(addr.sa.sa_family, SOCK_STREAM, 0); sean-freebsd> + s = socket(clt_addr.sa.sa_family, SOCK_STREAM, 0); Thanks for the fix. It will be part of 8.11.4. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 11: 3:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id C02D537B422 for ; Mon, 7 May 2001 11:03:17 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA82332; Mon, 7 May 2001 11:38:32 -0700 (PDT) Message-ID: <3AF6D25B.A3DF88B@elischer.org> Date: Mon, 07 May 2001 09:50:35 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Shaun Dwyer Cc: freebsd-net@freebsd.org Subject: Re: bridging and link bonding with netgraph References: <3AEEE8A0.EE9B2651@bigpond.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Shaun Dwyer wrote: > > For configuring netgraph for bridging, i used the example script in > /usr/share/examples/netgraph/ether.bridge . > > Is this to be expected when using netgraph for bridging? or is it > because of some piece of hardware i was using, or something else? > I dont think pocessor power was an issue, because it only peaked at > 20% (from systat -vmstat). We've heard many rumours of this 'variation' in netgraph throughput but never been able to pin it down to anything particular. Theoretically there shouldn't be any problem but in theory and practice only agree in threory.. In practice theory and practice tend to differ.. :-) between what values dod the varioations in ping time vary? julian > -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 11:23: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id C622737B422 for ; Mon, 7 May 2001 11:23:00 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA82392; Mon, 7 May 2001 11:42:48 -0700 (PDT) Message-ID: <3AF6E39A.A7447268@elischer.org> Date: Mon, 07 May 2001 11:04:10 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Vladimir B. Grebenschikov" Cc: freebsd-net@freebsd.org Subject: Re: netgraph interface names References: <15092.6166.422647.927779@vbook.express.ru> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was thinking of doing this.. but slightly differnt.... renaming the node would change the interface name too. but what you have would work as well. "Vladimir B. Grebenschikov" wrote: > > Tring to use netgraph system for some pruposes > (frame-relay/tunneling/sync) I found that it is too complicated to > follow naming schemes for different clients, and build firewall > tables And not very clean witch ngX for what. > > There two patches: > > first allow name netgraph network interface. > > # ngctl msg ng0: setifname \"sync0\" > > will name interace ng0 as sync0 > > second patch allows rename already named netgraph node (I don't understand why > netgraph designers don't allow this) > > # ngctl name ng0: sync0 > > so small script will easy create interface: > > mkif() { > name="$1" > ngname=`( echo "mkpeer iface dummy inet"; echo "msg .:dummy getifname" ) \ > | ngctl -f - | perl -n -e '/Args:\s+\"(ng\d+)\"/ && print "$1\n";'` > if [ "$name" != "" ]; then > ngctl msg $ngname: setifname \"$name\" > ngctl name $ngname: $name > ngname=$name > fi > } > > # SYNC interfaces > mkif sync0 > # some other netgraph stuff > > mkif sync1 > ... > mkif sync2 > ... > > # framerelay > mkif frm0 > ... > mkif frm1 > ... > > -------------------------------------------------------------------------------- > Name: iface-setname.patch > iface-setname.patch Type: unspecified type (application/octet-stream) > Encoding: base64 > > Name: node-rename.patch > node-rename.patch Type: unspecified type (application/octet-stream) > Encoding: base64 > > -------------------------------------------------------------------------------- > > -- > TSB Russian Express, Moscow > Vladimir B. Grebenschikov, vova@express.ru -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 11:46:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from comm.uni-svishtov.bg (ns.uni-svishtov.bg [193.68.172.1]) by hub.freebsd.org (Postfix) with ESMTP id AEF6837B424 for ; Mon, 7 May 2001 11:46:00 -0700 (PDT) (envelope-from rvasilev@uni-svishtov.bg) Received: from grinch.uni-svishtov.bg (root@grinch.uni-svishtov.bg [193.68.172.9]) by comm.uni-svishtov.bg (8.9.3/8.9.3) with ESMTP id VAA24258; Mon, 7 May 2001 21:45:41 +0300 (EEST) Received: from deckland (deckland.uni-svishtov.bg [193.68.173.82]) by grinch.uni-svishtov.bg (8.9.3/8.9.1) with SMTP id VAA04341; Mon, 7 May 2001 21:45:40 +0300 (EEST) Message-ID: <004a01c0d70c$c668a4e0$52ad44c1@unisvishtov.bg> From: "Radoslav Vasilev" To: Cc: "Radoslav Vasilev" Subject: broadcast and aironet PCI4800 Date: Mon, 7 May 2001 21:45:42 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C0D73F.10B6C9A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C0D73F.10B6C9A0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hello, I wonder is there a way to connect two phisical networks on = ethernel level in a situation like this: I have two subnets(subnet1,2) connected through 2 aironet PCI4800 = NICs(Cisco Aironet 340 Series) working on gateway1 and 2.(FreeBSD 3.3 = and 4.3 machines) -------------------\ = /------------------------- =20 | |=20 gateway1----->---------------<---------------- gateway2 = <-------------> Internet | | -------------------/ = \------------------------- subnet1 subnet2 I was told I could try using ProxyARP, but if I do so, I'll manege to = make machines on subnet1(for example) to see subnet2's machines. What I = need actually is some kind of bridging, and I don't know:=20 1) can I use bridging(turning on promiscuous mode) on aironet 2) on gateway2 i have ipfw As a third suggestion I got the idea of using netgraph. Allright, I'll appreciate any ideas for what way do you think I should = go ahead. Thanks in advance ------=_NextPart_000_0047_01C0D73F.10B6C9A0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hello, I wonder is there a way to = connect two=20 phisical networks on ethernel level in a situation like = this:
I have two subnets(subnet1,2) connected = through 2=20 aironet PCI4800 NICs(Cisco Aironet 340 Series) working on gateway1 = and=20 2.(FreeBSD 3.3 and 4.3 machines)
-------------------\       &n= bsp;           &nb= sp;           &nbs= p; /-------------------------   =20
      =    =20          |   =20             =    =20             = | 
   gateway1----->---------------<----------= ------ gateway2   =20 <-------------> Internet
          &nbs= p;        =20 |            =    =20             =    =20 |
-------------------/       &n= bsp;           &nb= sp;           &nbs= p;=20 \-------------------------
subnet1    =    =20             =    =20             =    =20         subnet2
 
I was told I could try using ProxyARP, = but if I do=20 so, I'll manege to make machines on subnet1(for example) to see = subnet2's=20 machines. What I need actually is some kind of bridging, and I don't = know:=20
1) can I  use bridging(turning on = promiscuous=20 mode) on aironet
2) on gateway2 i have ipfw
As a third suggestion I got the idea of = using=20 netgraph.
Allright, I'll appreciate any ideas for = what way do=20 you think I should go ahead.
Thanks in = advance
------=_NextPart_000_0047_01C0D73F.10B6C9A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 14:22:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from molly.straylight.com (molly.straylight.com [204.69.232.69]) by hub.freebsd.org (Postfix) with ESMTP id 5ED9B37B423 for ; Mon, 7 May 2001 14:22:17 -0700 (PDT) (envelope-from jonathan@graehl.org) Received: from case (root@localhost [127.0.0.1]) by molly.straylight.com (8.11.0/8.10.0) with ESMTP id f47LLmH16629; Mon, 7 May 2001 14:21:48 -0700 From: "Jonathan Graehl" To: "'Alfred Perlstein'" Cc: Subject: RE: Do I need to close after shutdown if I don't want to leak descriptors? (making sure TCP retransmits all my data) Date: Mon, 7 May 2001 14:22:13 -0700 Message-ID: <000201c0d73b$cae4abc0$6dfeac40@straylight.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2605 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <20010507022726.P18676@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for the suggestion - it does fit the bill, although I have to getsockopt(SO_SNDBUF on a per-socket basis (I'm using the kqueue NOTE_LOWAT, which doesn't trigger if I supply a very large number - the exact SO_SNDBUF needs to be used). I'd honestly just prefer to have the kernel close the socket for me, though ;) It is certain that a close() after shutdown() is needed to avoid leaking descriptors, then? > Here's a trick that may work. > > use setsockopt to set SO_SNDLOWAT == SO_SNDBUF, when you get > a writeable event back you know the socket is clear. this is > good because you should be able to go back to using > poll/kevent to monitor them. > > -- > -Alfred Perlstein - [alfred@freebsd.org] > Instead of asking why a piece of software is using "1970s > technology," start asking why software is ignoring 30 years > of accumulated wisdom. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 15:29:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by hub.freebsd.org (Postfix) with ESMTP id 516F637B422 for ; Mon, 7 May 2001 15:29:27 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.3/8.11.2) id f47MSfp16662; Mon, 7 May 2001 15:28:41 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200105072228.f47MSfp16662@ambrisko.com> Subject: Re: broadcast and aironet PCI4800 In-Reply-To: <004a01c0d70c$c668a4e0$52ad44c1@unisvishtov.bg> "from Radoslav Vasilev at May 7, 2001 09:45:42 pm" To: Radoslav Vasilev Date: Mon, 7 May 2001 15:28:41 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG, Radoslav Vasilev X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Radoslav Vasilev writes: | Hello, I wonder is there a way to connect two phisical networks on ethernel level in a situation like this: | I have two subnets(subnet1,2) connected through 2 aironet PCI4800 NICs(Cisco Aironet 340 Series) working on gateway1 and 2.(FreeBSD 3.3 and 4.3 machines) | -------------------\ /------------------------- | | | | gateway1----->---------------<---------------- gateway2 <-------------> Internet | | | | -------------------/ \------------------------- | subnet1 subnet2 | | I was told I could try using ProxyARP, but if I do so, I'll manege to make machines on subnet1(for example) to see subnet2's machines. What I need actually is some kind of bridging, and I don't know: | 1) can I use bridging(turning on promiscuous mode) on aironet | 2) on gateway2 i have ipfw | As a third suggestion I got the idea of using netgraph. | Allright, I'll appreciate any ideas for what way do you think I should go ahead. | Thanks in advance Seems like you don't have enough information in the picture. If for example subnet1 is 192.168.1 subnet2 is 192.168.2 the wireless gateway is 192.168.3 Internet is something Then this is a pure routing problem. Then learn about routing via "route" However, with -stable (ie after 4.3) there have been changes made to the Aironet driver to do promiscuous on wireless and the submitter of the patch has bridged the wireless and wired network together. In that case you could. subnet1 is 192.168.1 subnet2 is 192.168.1 the wireless gateway is 192.168.1 (bridged to subnet x) Internet is the default route. Then use could use netgraph bridge to tie the wireless adapters to your wired network. It would appear to be one big network. Even without the patches some things using VPN tunnels and bridging could tie stuff together. Really in this case subnet1 & subnet2 are effectively the same network. I haven't personaly done this (except routing) but giving you and idea of what to persue. Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 20: 3:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B92BC37B424 for ; Mon, 7 May 2001 20:03:54 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4833sV01693; Mon, 7 May 2001 20:03:54 -0700 (PDT) Date: Mon, 7 May 2001 20:03:54 -0700 From: "'Alfred Perlstein'" To: Jonathan Graehl Cc: freebsd-net@FreeBSD.ORG Subject: Re: Do I need to close after shutdown if I don't want to leak descriptors? (making sure TCP retransmits all my data) Message-ID: <20010507200353.X18676@fw.wintelcom.net> References: <20010507022726.P18676@fw.wintelcom.net> <000201c0d73b$cae4abc0$6dfeac40@straylight.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000201c0d73b$cae4abc0$6dfeac40@straylight.com>; from jonathan@graehl.org on Mon, May 07, 2001 at 02:22:13PM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Jonathan Graehl [010507 14:22] wrote: > Thanks for the suggestion - it does fit the bill, although I have to > getsockopt(SO_SNDBUF on a per-socket basis (I'm using the kqueue > NOTE_LOWAT, which doesn't trigger if I supply a very large number - the > exact SO_SNDBUF needs to be used). I'd honestly just prefer to have the > kernel close the socket for me, though ;) It is certain that a close() > after shutdown() is needed to avoid leaking descriptors, then? Yes. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 22:11:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m01.mx.aol.com (imo-m01.mx.aol.com [64.12.136.4]) by hub.freebsd.org (Postfix) with ESMTP id 74B3137B422 for ; Mon, 7 May 2001 22:11:37 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m01.mx.aol.com (mail_out_v30.10.) id n.52.2af0f5 (16234) for ; Tue, 8 May 2001 01:11:33 -0400 (EDT) Received: from netscape.com (aimmail02.aim.aol.com [205.188.144.194]) by air-in02.mx.aol.com (v77_r1.37) with ESMTP; Tue, 08 May 2001 01:11:33 -0400 Date: Tue, 08 May 2001 01:11:33 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: router advertisement after router solicitation Mime-Version: 1.0 Message-ID: <7F5EB17E.102EA3C7.9513E96F@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, This is regarding sending router advertisement on the receipt of router solicitation. When an icmp message of type router solicitation is received in the icmp6_input(). the function calls nd6_rs_input(). This function inturn calls nd6_cach_lladdr(). But no where in the above code rtadv related functions are called. AS all know rtadv is implemented as a daemon. But this daemon sends router advertisements periodically. If a host wants address prefixes immediately it sends router solicitaion to the router. But in the above case no router advertisement related things are called immediately.( the rfc 2462 mentions that if a host needs prefixes immmediately it has to send router soliciations). Kindly mail if iam right. If iam wrong can anybody mail the full sequence of events in freebsd for the above case. regards ravi prasad __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon May 7 22:21: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 65C7537B43C for ; Mon, 7 May 2001 22:21:03 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1C18D4B0B; Tue, 8 May 2001 14:21:00 +0900 (JST) To: raviprasad20@netscape.net Cc: freebsd-net@freebsd.org In-reply-to: raviprasad20's message of Tue, 08 May 2001 01:11:33 -0400. <7F5EB17E.102EA3C7.9513E96F@netscape.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: router advertisement after router solicitation From: itojun@iijlab.net Date: Tue, 08 May 2001 14:21:00 +0900 Message-ID: <18562.989299260@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hi, >This is regarding sending router advertisement on the receipt of >router solicitation. you keep asking (good) questions, but why? will you plan to send some summary to somewhere, or put up onto web, to give feedback to people? if you have no plan, i suggest you to do that. >When an icmp message of type router solicitation is received in >the icmp6_input(). the function calls nd6_rs_input(). This function >inturn calls nd6_cach_lladdr(). > >But no where in the above code rtadv related functions are called. from within sys/netinet6/icmp6.c:icmp6_input(), icmp6_rip6_input() is called. rtadvd(8) listens to raw IPv6 socket (IPPROTO_ICMPV6) and accepts data through the socket. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 8 12:23:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 5900E37B423 for ; Tue, 8 May 2001 12:23:16 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA64300; Tue, 8 May 2001 15:23:03 -0400 (EDT) (envelope-from wollman) Date: Tue, 8 May 2001 15:23:03 -0400 (EDT) From: Garrett Wollman Message-Id: <200105081923.PAA64300@khavrinen.lcs.mit.edu> To: "Jonathan Graehl" Cc: Subject: Do I need to close after shutdown if I don't want to leak descriptors? (making sure TCP retransmits all my data) In-Reply-To: <000001c0d6d5$87607e80$6dfeac40@straylight.com> References: <000001c0d6d5$87607e80$6dfeac40@straylight.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Problem: close() does not perform an orderly shutdown, does not resend > unacknowledged data - responds with RST to data/acks sent to me I suggest that this is a bug. > Incomplete solution: shutdown(SHUT_RDWR), but then what? Will the OS > close the fd for me once the other end acknowledges, or better yet, > closes its end as well, or do I need to close the fd? No, you still have to close. > (selecting for readable is not a solution; if they have > sent me data I am uninterested in reading, I will select readable) selecting for an exception *should* do what you want, but doesn't (this is also a bug). > Obviously, if shutdown fails (it shouldn't, I die on failure), you would > need to close to avoid descriptor leakage. But do I need to babysit the > descriptor after I have no more interest in it? Yes. shutdown != close. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue May 8 23:32:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from molly.straylight.com (molly.straylight.com [204.69.232.69]) by hub.freebsd.org (Postfix) with ESMTP id 950F237B423 for ; Tue, 8 May 2001 23:32:42 -0700 (PDT) (envelope-from jonathan@graehl.org) Received: from case (root@localhost [127.0.0.1]) by molly.straylight.com (8.11.0/8.10.0) with ESMTP id f496WTs28816; Tue, 8 May 2001 23:32:30 -0700 From: "Jonathan Graehl" To: "'Garrett Wollman'" Cc: Subject: RE: Do I need to close after shutdown if I don't want to leak descriptors? (making sure TCP retransmits all my data) Date: Tue, 8 May 2001 23:32:41 -0700 Message-ID: <000b01c0d851$dca62340$6dfeac40@straylight.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2605 In-Reply-To: <200105081923.PAA64300@khavrinen.lcs.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Problem: close() does not perform an orderly shutdown, does > not resend > > unacknowledged data - responds with RST to data/acks sent to me > > I suggest that this is a bug. That is my feeling as well. I am well aware that depending on the transport layer to ensure delivery of the "last word" does not obviate end-to-end application acknowledgment, but honestly, if I really wanted to improperly terminate a TCP connection, I already have that option with SO_LINGER and a 0 linger time. By default (without messing with SO_LINGER), a close() on a TCP connection should do the right thing (keep the send socket buffer around and retransmit until all is acknowledged; and accept, acknowledge, and discard data). However, I believe that FreeBSD is not alone in this shortcoming, so it would really only be a platform-specific optimization (one that is unnecessary if you use application level acknowledgments), saving two syscalls and some user bookkeeping per socket termination. > > > Incomplete solution: shutdown(SHUT_RDWR), but then what? > Will the OS > > close the fd for me once the other end acknowledges, or better yet, > > closes its end as well, or do I need to close the fd? > > No, you still have to close. > > > (selecting for readable is not a solution; if they have > > sent me data I am uninterested in reading, I will select readable) > > selecting for an exception *should* do what you want, but > doesn't (this is also a bug). There is no such concept (EVFILT_EXCEPTION?) for kqueue, although waiting for the socket to be writable with the low water mark = size of entire buffer, as suggested by Alfred, does let me ensure that all the data was acknowledged before closing (it does not tell me that they have closed the connection, though) (waiting for the buffer to drain can be done using NOTE_LOWAT in kqueue, although you have to getsockopt(SO_SNDBUF) per fd since the size can vary between remote and local sockets). -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 3:54:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by hub.freebsd.org (Postfix) with ESMTP id 97D7337B423 for ; Wed, 9 May 2001 03:54:09 -0700 (PDT) (envelope-from oscar@ac.upc.es) Received: from ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.11.0/8.11.0) with ESMTP id f49As2413230 for ; Wed, 9 May 2001 12:54:02 +0200 (MET DST) Message-ID: <3AF921CA.5C446E40@ac.upc.es> Date: Wed, 09 May 2001 12:54:03 +0200 From: Oscar-Ivan Lepe-Aldama Organization: DAC/UPC X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: es, en MIME-Version: 1.0 To: net@freebsd.org Subject: On the performance of the xl driver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have a 4.1.1 box set up as a router that seems to have trouble dealing with packet rates exceeding 1000 pkt/s. The router is a 100Mhz Pentium with 16MB of RAM and two 3Com905B-TX ethernet adapters attached each to a Ethernet subnetwork. The problem manifests itself when some packets experience a huge forwarding latency, relatively to the average value. The average forwarding latency time is 52us while the troubled packets exhibit a latency of up to 6000us. I have observed that this is due to a call to the xl_stats_update() routine while the kernel is at a high priority level (perhaps splimp). This happens as part of the xl_intr routine, when the network-adapter's interrupt status word has its XL_STAT_STATSOFLOW bit set. The xl_stats_update() takes almost 6000us to complete and processing for whichever packet that arrives during this time will be deferred. Moreover, I have observed that this only happens when the packet rate is 1000 pkt/s or more. At lower rates, the XL_STAT_STATSOFLOW bit is never set because the network-adapter's statistics buffer is periodicaly clean at a "sufficient" pace -the xl_stats_update() is called from softclock() at a low kernel's priority level.- To make matters worst, this is a phenomenon directly proportional to the packet rate. So the question is weather this is a bug or not and why. Another point. To temporarly solve this I have disable the network adapter's XL_STAT_STATSOFLOW interrupt (at if_xlreg.h, #define XL_INTRS) but I don't know what are the implications of this, so any comments are welcome. Best regards, -- ======================================================================== 0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC 0 0 0 e-mail: oscar@ac.upc.es | Modul D6, despatx 116 0 0 0 phone: +34 93 401 7187 | Jordi Girona, 1-3 U P C fax: +34 93 401 7055 | 08034 Barcelona - SPAIN WWW: http://www.ac.upc.es/homes/oscar/ ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 6: 1: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from vbook.express.ru (h129.37.elnet.msk.ru [195.58.37.129]) by hub.freebsd.org (Postfix) with ESMTP id 19FFD37B424 for ; Wed, 9 May 2001 06:00:30 -0700 (PDT) (envelope-from vova@vbook.express.ru) Received: (from vova@localhost) by vbook.express.ru (8.9.3/8.9.3) id JAA00651; Tue, 8 May 2001 09:49:48 +0400 (MSD) (envelope-from vova) From: "Vladimir B. Grebenschikov" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="PhLw+oqIYC" Content-Transfer-Encoding: 7bit Message-ID: <15095.35067.813462.898426@vbook.express.ru> Date: Tue, 8 May 2001 09:49:47 +0400 (MSD) To: Julian Elischer Cc: "Vladimir B. Grebenschikov" , freebsd-net@FreeBSD.ORG Subject: Re: netgraph interface names In-Reply-To: <3AF6E39A.A7447268@elischer.org> References: <15092.6166.422647.927779@vbook.express.ru> <3AF6E39A.A7447268@elischer.org> X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --PhLw+oqIYC Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Julian Elischer writes: > I was thinking of doing this.. > > but slightly differnt.... > renaming the node would change the interface name too. > but what you have would work as well. Only problem it is no hook between node renaming code in ng_base.c and interface allocation code in ng_iface.c below more extended patch, that supports allocation first free interface with name "ifname#". > "Vladimir B. Grebenschikov" wrote: > > > > Tring to use netgraph system for some pruposes > > (frame-relay/tunneling/sync) I found that it is too complicated to > > follow naming schemes for different clients, and build firewall > > tables And not very clean witch ngX for what. > > > > There two patches: > > > > first allow name netgraph network interface. > > > > # ngctl msg ng0: setifname \"sync0\" > > > > will name interace ng0 as sync0 > > > > second patch allows rename already named netgraph node (I don't understand why > > netgraph designers don't allow this) > > > > # ngctl name ng0: sync0 > > > > so small script will easy create interface: > > > > mkif() { > > name="$1" > > ngname=`( echo "mkpeer iface dummy inet"; echo "msg .:dummy getifname" ) \ > > | ngctl -f - | perl -n -e '/Args:\s+\"(ng\d+)\"/ && print "$1\n";'` > > if [ "$name" != "" ]; then > > ngctl msg $ngname: setifname \"$name\" > > ngctl name $ngname: $name > > ngname=$name > > fi > > } > > > > # SYNC interfaces > > mkif sync0 > > # some other netgraph stuff > > > > mkif sync1 > > ... > > mkif sync2 > > ... > > > > # framerelay > > mkif frm0 > > ... > > mkif frm1 > > ... > > --PhLw+oqIYC Content-Type: application/octet-stream Content-Disposition: attachment; filename="iface-setname.patch" Content-Transfer-Encoding: base64 LS0tIHN5cy9uZXRncmFwaC9uZ19pZmFjZS5oLm9yaWcJU2F0IE1heSAgNSAxMjozODozMyAy MDAxCisrKyBzeXMvbmV0Z3JhcGgvbmdfaWZhY2UuaAlTYXQgTWF5ICA1IDE0OjIxOjA5IDIw MDEKQEAgLTcwLDYgKzcwLDcgQEAKIAlOR01fSUZBQ0VfR0VUX0lGTkFNRSA9IDEsCS8qIHJl dHVybnMgc3RydWN0IG5nX2lmYWNlX2lmbmFtZSAqLwogCU5HTV9JRkFDRV9QT0lOVDJQT0lO VCwKIAlOR01fSUZBQ0VfQlJPQURDQVNULAorCU5HTV9JRkFDRV9TRVRfSUZOQU1FLCAgICAg ICAgICAgLyogc2V0IGludGVyZmFjZSBuYW1lICovCiB9OwogCiBzdHJ1Y3QgbmdfaWZhY2Vf aWZuYW1lIHsKLS0tIHN5cy9uZXRncmFwaC9uZ19pZmFjZS5jLm9yaWcJU2F0IE1heSAgNSAx MjozODoyNiAyMDAxCisrKyBzeXMvbmV0Z3JhcGgvbmdfaWZhY2UuYwlNb24gTWF5ICA3IDIw OjU4OjM2IDIwMDEKQEAgLTYyLDkgKzYyLDExIEBACiAjaW5jbHVkZSA8c3lzL3NvY2tldC5o PgogI2luY2x1ZGUgPHN5cy9zeXNsb2cuaD4KICNpbmNsdWRlIDxzeXMvbGlia2Vybi5oPgor I2luY2x1ZGUgPHN5cy9jdHlwZS5oPgogCiAjaW5jbHVkZSA8bmV0L2lmLmg+CiAjaW5jbHVk ZSA8bmV0L2lmX3R5cGVzLmg+CisjaW5jbHVkZSA8bmV0L2lmX2RsLmg+CiAjaW5jbHVkZSA8 bmV0L2ludHJxLmg+CiAjaW5jbHVkZSA8bmV0L2JwZi5oPgogCkBAIC0xNTcsNiArMTU5LDEz IEBACiAJfSwKIAl7CiAJICBOR01fSUZBQ0VfQ09PS0lFLAorCSAgTkdNX0lGQUNFX1NFVF9J Rk5BTUUsCisJICAic2V0aWZuYW1lIiwKKwkgICZuZ19pZmFjZV9pZm5hbWVfdHlwZSwKKwkg IE5VTEwKKwl9LAorCXsKKwkgIE5HTV9JRkFDRV9DT09LSUUsCiAJICBOR01fSUZBQ0VfUE9J TlQyUE9JTlQsCiAJICAicG9pbnQycG9pbnQiLAogCSAgTlVMTCwKQEAgLTY0NCw2ICs2NTMs NjggQEAKIAkJCWJyZWFrOwogCQkgICAgfQogCisJCWNhc2UgTkdNX0lGQUNFX1NFVF9JRk5B TUU6CisJCSAgICB7CisJCQlzdHJ1Y3QgbmdfaWZhY2VfaWZuYW1lICphcmcgPSAKKwkJCSAg ICAgICAoc3RydWN0IG5nX2lmYWNlX2lmbmFtZSAqKW1zZy0+ZGF0YTsKKwkJCWNoYXIgKnN0 cjsKKwkJCWludCB1bml0LCBtYXh1bml0ID0gLTE7CisJCQlpbnQgczsKKwkJCXN0cnVjdCBp Zm5ldCAqIGlmcHIgPSBOVUxMOworCisJCQkvKiBEZW55IHJlcXVlc3QgaWYgaW50ZXJmYWNl IGlzIFVQICovCisJCQlpZiAoKGlmcC0+aWZfZmxhZ3MgJiBJRkZfVVApICE9IDApIHsKKwkJ CSAgZXJyb3IgPSBFQlVTWTsKKwkJCSAgYnJlYWs7CisJCQl9CisJCQkKKwkJCXN0ciA9IGFy Zy0+bmdpZl9uYW1lICsgc3RybGVuKGFyZy0+bmdpZl9uYW1lKSAtIDE7CisJCQlpZiAoKnN0 ciA9PSAnIycpIAorCQkJICB1bml0ID0gLTE7IC8qIHVuaXQgPSAtMSBtZWFucyBmaXJzdCBh dmFpbGFibGUgdW5pdCAqLworCQkJZWxzZQorCQkJICBmb3IgKDsoc3RyID4gYXJnLT5uZ2lm X25hbWUpICYmIGlzZGlnaXQoKnN0cik7IHN0ci0tKTsKKwkJCQorCQkJaWYgKHN0ciA9PSBh cmctPm5naWZfbmFtZSkgeworCQkJICBlcnJvciA9IEVJTlZBTDsKKwkJCSAgYnJlYWs7CisJ CQl9CisKKwkJCWlmICh1bml0ICE9IC0xKQorCQkJICB1bml0ID0gc3RydG91bCgrK3N0ciwg TlVMTCwgMTApOworCisJCQkqc3RyID0gJ1wwJzsKKworCQkJLyogY2hlY2sgZm9yIGV4aXN0 aW5nIGludGVyZmFjZSB3aXRoIHNhbWUgbmFtZSAqLworCQkJcyA9IHNwbGltcCgpOworCQkJ VEFJTFFfRk9SRUFDSChpZnByLCAmaWZuZXQsIGlmX2xpbmspIAorCQkJICBpZiAoc3RyY21w KGlmcHItPmlmX25hbWUsIGFyZy0+bmdpZl9uYW1lKSA9PSAwKSB7CisJCQkgICAgaWYgKHVu aXQgPT0gLTEpIAorCQkJICAgICAgbWF4dW5pdCA9IChpZnByLT5pZl91bml0ID4gbWF4dW5p dCk/aWZwci0+aWZfdW5pdDptYXh1bml0OworCQkJICAgIGVsc2UgCisJCQkgICAgICBpZiAo aWZwci0+aWZfdW5pdCA9PSB1bml0KSB7CisJCQkJZXJyb3IgPSBFRVhJU1Q7CisJCQkJYnJl YWs7CisJCQkgICAgICB9CisJCQkgIH0KKworCQkJc3BseChzKTsKKwkJCWlmIChlcnJvcikg YnJlYWs7CisKKwkJCWlmICh1bml0ID09IC0xKSAKKwkJCSAgdW5pdCA9IG1heHVuaXQgKyAx OworCQkJCisJCQlNQUxMT0MoaWZwLT5pZl9uYW1lLCBjaGFyICosIHN0cmxlbihhcmctPm5n aWZfbmFtZSkgKyAxLCBNX05FVEdSQVBILCBNX05PV0FJVCk7CisJCQlzID0gc3BsaW1wKCk7 CisJCQlzdHJjcHkoaWZwLT5pZl9uYW1lLCBhcmctPm5naWZfbmFtZSk7CisJCQlpZnAtPmlm X3VuaXQgPSB1bml0OworCQkJc3BseChzKTsKKwkJCQorCQkJaWZfZGV0YWNoKGlmcCk7CisJ CQlpZl9hdHRhY2goaWZwKTsKKwkJCQorCQkJYnJlYWs7CisJCSAgICB9CisJCSAgICAKIAkJ Y2FzZSBOR01fSUZBQ0VfUE9JTlQyUE9JTlQ6CiAJCWNhc2UgTkdNX0lGQUNFX0JST0FEQ0FT VDoKIAkJICAgIHsK --PhLw+oqIYC Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000-2001 > ---> X_.---._/ -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, vova@express.ru --PhLw+oqIYC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 6:53: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id 6767F37B423 for ; Wed, 9 May 2001 06:52:51 -0700 (PDT) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id PAA94952 for ; Wed, 9 May 2001 15:52:40 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: Subject: Voice over IP, or something similar? Date: Wed, 9 May 2001 15:52:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <15095.35067.813462.898426@vbook.express.ru> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If this is the wrong place for this question, please simply point me in the right direction. :) I would like to build a WAN using FreeBSD boxes for firewalls and routers. I thought I had all the details figured out until my potential customer mentioned that he would like to use the WAN to carry voice. You know the reason - it is supposed to save money. Anyway, I am told I must use routers with appropriate interfaces to mix voice with IP. This blows the cost-effectiveness of my whole plan because it forces me to run a FreeBSD box for Firewall etc, AND a router. A bit redundant to say the least. So: is there anyone with any bright ideas for me whereby I can put voice over IP, but still use FreeBSD for routing, and avoid buying those horribly expensive router-based alternatives? Thanks, Patrick O'Reilly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 7:14: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by hub.freebsd.org (Postfix) with ESMTP id 000B237B422 for ; Wed, 9 May 2001 07:14:02 -0700 (PDT) (envelope-from oscar@ac.upc.es) Received: from ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.11.0/8.11.0) with ESMTP id f49EDq418752 for ; Wed, 9 May 2001 16:13:53 +0200 (MET DST) Message-ID: <3AF950A1.2D4A13F2@ac.upc.es> Date: Wed, 09 May 2001 16:13:53 +0200 From: Oscar-Ivan Lepe-Aldama Organization: DAC/UPC X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: es, en MIME-Version: 1.0 To: net@freebsd.org Subject: On the workings of the xl dirver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I would like to have information regarding the implementation of the xl_start_90xB function in the xl driver. After reading the code and the technical reference from 3com I still cannot understand how the driver signals the NIC for packet downloading. I know the code is OK as my FreeBSD box, loaded with a pair of 3C905B-TX NICs, works just fine: it forwards packets. But because I am interested in measuring the performance of the system (both software and hardware) I need to know the points where the software signals the hardware. Please help. Some details follow. In the case of the xl_start function (the xl driver has two implementations of the if_start operation: xl_start_90xB for 3c90xB NICs and xl_start for others) this is clear. It uses the following code, which follows the algorithm presented in the technical reference: 2276 /* 2277 * Queue the packets. If the TX channel is clear, update 2278 * the downlist pointer register. 2279 */ 2280 CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_DOWN_STALL); 2281 xl_wait(sc); 2282 2283 if (sc->xl_cdata.xl_tx_head != NULL) { 2284 sc->xl_cdata.xl_tx_tail->xl_next = start_tx; 2285 sc->xl_cdata.xl_tx_tail->xl_ptr->xl_next = 2286 vtophys(start_tx->xl_ptr); 2287 sc->xl_cdata.xl_tx_tail->xl_ptr->xl_status &= 2288 ~XL_TXSTAT_DL_INTR; 2289 sc->xl_cdata.xl_tx_tail = cur_tx; 2290 } else { 2291 sc->xl_cdata.xl_tx_head = start_tx; 2292 sc->xl_cdata.xl_tx_tail = cur_tx; 2293 } 2294 if (!CSR_READ_4(sc, XL_DOWNLIST_PTR)) 2295 CSR_WRITE_4(sc, XL_DOWNLIST_PTR, vtophys(start_tx->xl_ptr)); 2296 2297 CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_DOWN_UNSTALL); But in the case of the xl_start_90xB the code is like this: 2426 /* Start transmission */ 2427 sc->xl_cdata.xl_tx_prod = idx; 2428 start_tx->xl_prev->xl_ptr->xl_next = start_tx->xl_phys; As can be seen in this last case, there are no CSR_WRITE operations for signaling the NIC. However, the technical reference says the NIC has to be signaled for it to learn there is work to do. How is this being implemented is this case? Thanks. Best regards, -- ======================================================================== 0 0 0 Oscar-Ivan Lepe-Aldama | UPC-Campus Nord, DAC 0 0 0 e-mail: oscar@ac.upc.es | Modul D6, despatx 116 0 0 0 phone: +34 93 401 7187 | Jordi Girona, 1-3 U P C fax: +34 93 401 7055 | 08034 Barcelona - SPAIN WWW: http://www.ac.upc.es/homes/oscar/ ======================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 8: 9: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from sentry.granch.com (sentry.granch.com [212.109.197.55]) by hub.freebsd.org (Postfix) with ESMTP id 76C0637B422 for ; Wed, 9 May 2001 08:09:05 -0700 (PDT) (envelope-from shelton@sentry.granch.ru) Received: from sentry.granch.com (localhost [127.0.0.1]) by sentry.granch.com (8.11.3/8.11.3) with SMTP id f49F8UD06040; Wed, 9 May 2001 22:08:35 +0700 (NOVST) (envelope-from shelton@sentry.granch.ru) Content-Type: text/plain; charset="koi8-r" From: "Rashid N. Achilov" Reply-To: achilov@granch.ru Organization: Granch Ltd. To: Garrett Wollman , "Jonathan Graehl" Subject: Re: Do I need to close after shutdown if I don't want to leak descriptors? (making sure TCP retransmits all my data) Date: Wed, 9 May 2001 22:08:29 +0700 X-Mailer: KMail [version 1.2] Cc: References: <000001c0d6d5$87607e80$6dfeac40@straylight.com> <200105081923.PAA64300@khavrinen.lcs.mit.edu> In-Reply-To: <200105081923.PAA64300@khavrinen.lcs.mit.edu> MIME-Version: 1.0 Message-Id: <01050922082909.02773@sentry.granch.com> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wednesday 09 May 2001 02:23, Garrett Wollman wrote: > < said: > > Problem: close() does not perform an orderly shutdown, does not resend > > unacknowledged data - responds with RST to data/acks sent to me > > I suggest that this is a bug. WinDoze do so. When connection finished, it sends RST instead FIN :-) But it isn't good. shutdown() should be called before close(). > > > Incomplete solution: shutdown(SHUT_RDWR), but then what? Will the OS > > close the fd for me once the other end acknowledges, or better yet, > > closes its end as well, or do I need to close the fd? > > No, you still have to close. Yes, you still should close. shutdown() marks socket as "unusable for read/write/all" but don't free socket handle. > > > (selecting for readable is not a solution; if they have > > sent me data I am uninterested in reading, I will select readable) > > selecting for an exception *should* do what you want, but doesn't > (this is also a bug). > > > Obviously, if shutdown fails (it shouldn't, I die on failure), you would > > need to close to avoid descriptor leakage. But do I need to babysit the > > descriptor after I have no more interest in it? > > Yes. shutdown != close. I have set flag 'close-on-exec' when open socket, because when I accept new connetcion, daemon forked. And have called shutdown() BEFORE close(). -- With Best Regards. Rashid N. Achilov (RNA1-RIPE), Web: http://granch.ru/~shelton Granch Ltd. system administrator, e-mail: achilov@granch.ru PGP: 83 CD E2 A7 37 4A D5 81 D6 D6 52 BF C9 2F 85 AF 97 BE CB 0A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 8:15:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from zorak.cidera.com (zorak.cidera.com [207.239.230.137]) by hub.freebsd.org (Postfix) with ESMTP id 762C437B42C for ; Wed, 9 May 2001 08:15:21 -0700 (PDT) (envelope-from rharris@cidera.com) Received: from [207.239.230.157] (parthenon.cidera.com [207.239.230.157]) by zorak.cidera.com (8.11.0/8.11.0) with ESMTP id f49FFKw05228 for ; Wed, 9 May 2001 11:15:20 -0400 (EDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Wed, 09 May 2001 11:15:11 -0400 Subject: Bridge over tun0 waters... From: Rob Harris To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message was posted Feb of '99. I was wondering if anyone has made an efforts towards this yet. (i.e. Wanna make sure I don't make a hack that's already made.) Thanks. --Rob > the bridges above will be not be doing any IP routing, just forwarding > IP packets based on MAC addresses. you can do this with cisco's and > i'd assume most other major bridge/router vendors. of course you may > run into serious traffic jams if your bridging ethernet over a much > slower line, like a 56k. in fact as many already said the most obvious solution seems to use routing, not bridging. > i'm not sure if this can be done with freebsd however. Luigi's bridge > code and ppp would be the place to look (Luigi will probably be able > to answer this :). just because i am called... bridging in freebsd only works on ethernet-type networks. Someone already asked me that i also add support for 'tun' interfaces so that solutions like the one above are possible. Shouldn't be that hard to implement, just isn't there right now. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message --Rob +--------------------------------------------------------------------------+ | Rob Harris 8037 Laurel Lakes Court, Laurel MD 301.598.0500 x2236 | | Cidera, Inc. rharris@cidera.com fax: 301.598.0837 | +--------------------------------------------------------------------------+ "Don't rush me sonny. You rush a miracle man, you get rotten miracles." --Miracle Max, The Princess Bride To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 8:40:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f170.law11.hotmail.com [64.4.17.170]) by hub.freebsd.org (Postfix) with ESMTP id C8C3C37B422 for ; Wed, 9 May 2001 08:40:54 -0700 (PDT) (envelope-from anandfranklin@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 May 2001 08:40:54 -0700 Received: from 203.200.20.3 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 09 May 2001 15:40:54 GMT X-Originating-IP: [203.200.20.3] From: "Anand Franklin J" To: freebsd-net@freebsd.org Subject: kernel building for the changes in kernel source Date: Wed, 09 May 2001 15:40:54 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 May 2001 15:40:54.0675 (UTC) FILETIME=[6F198630:01C0D89E] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi!!! I have made the changes to the source of the kernel files. To build the kernel, the guidance i get from the website is 1: a)make buildworld problem is, it consumes too much time. b)make buildkernel c)make installkernel 2: a)use of config command but document says, this method was used in older version b)make buildkernel c)make installkernel please tell, which of the approach is used or there is any other approach with regard's franklin. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 8:42: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0B94E37B422 for ; Wed, 9 May 2001 08:42:01 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f49Ffqf88176; Wed, 9 May 2001 11:41:52 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 9 May 2001 11:41:51 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rob Harris Cc: freebsd-net@freebsd.org Subject: Re: Bridge over tun0 waters... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At least in FreeBSD 5.0-CURRENT, and quite possibly in RELENG_4, there's an if_tap driver, which serves a similar function to the if_tun driver. if_tap appears as /dev/tap*, and as tap* interfaces, and appears as an ethernet device. It is used by our VMware port to allow VMware to make use of a virtual interface which is then bridged as needed with other local ethernet devices. It would be easy to imagine a tunneling program that sat on /dev/tap0 on two machines, and linked them using UDP, then using the kernel bridging support (either the bridge support in ethernet.c, or using ng_bridge). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Wed, 9 May 2001, Rob Harris wrote: > > This message was posted Feb of '99. > I was wondering if anyone has made an efforts towards this yet. > (i.e. Wanna make sure I don't make a hack that's already made.) > Thanks. > --Rob > > > the bridges above will be not be doing any IP routing, just forwarding > > IP packets based on MAC addresses. you can do this with cisco's and > > i'd assume most other major bridge/router vendors. of course you may > > run into serious traffic jams if your bridging ethernet over a much > > slower line, like a 56k. > > in fact as many already said the most obvious solution seems to use > routing, not bridging. > > > i'm not sure if this can be done with freebsd however. Luigi's bridge > > code and ppp would be the place to look (Luigi will probably be able > > to answer this :). > > just because i am called... bridging in freebsd only works on > ethernet-type networks. Someone already asked me that i also > add support for 'tun' interfaces so that solutions like the one above > are possible. Shouldn't be that hard to implement, just isn't there > right now. > > cheers > luigi > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > --Rob > > +--------------------------------------------------------------------------+ > | Rob Harris 8037 Laurel Lakes Court, Laurel MD 301.598.0500 x2236 | > | Cidera, Inc. rharris@cidera.com fax: 301.598.0837 | > +--------------------------------------------------------------------------+ > "Don't rush me sonny. You rush a miracle man, you get rotten miracles." > --Miracle Max, The Princess Bride > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 12:50:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from softweyr.com (mail.dobox.com [208.187.122.44]) by hub.freebsd.org (Postfix) with ESMTP id DDF6337B424; Wed, 9 May 2001 12:50:18 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from localhost ([127.0.0.1] helo=softweyr.com ident=a5c5f56aa5856f0af74362e573ea7051) by softweyr.com with esmtp (Exim 3.16 #1) id 14xZyJ-0000Ab-00; Wed, 09 May 2001 13:50:07 -0600 Message-ID: <3AF99F6F.3888588B@softweyr.com> Date: Wed, 09 May 2001 13:50:07 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Ted Mittelstaedt Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: outgoing traffic load balancing with multiple ISP References: <006901c0d5a9$b2e4c3e0$1401a8c0@tedm.placo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ted Mittelstaedt wrote: > > Our redundancy is at the point where we have more of a problem detecting > that links are actually down and notifying the admin! Once we went for 6 > hours with a feed down because the What's Up box was pinging the wrong IP > number, and no customers or administrators noticed it because the network > didn't seem any slower or different than it normally is. mrtg? > Now that's redundancy for you. Er, resilient? They're only redundant if you're not using them. http://ezine.daemonnews.org/200105/dadvocate.html ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 9 20:38:51 2001 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id AB8EF37B423; Wed, 9 May 2001 20:38:49 -0700 (PDT) Subject: Re: On the workings of the xl dirver In-Reply-To: <3AF950A1.2D4A13F2@ac.upc.es> from Oscar-Ivan Lepe-Aldama at "May 9, 2001 04:13:53 pm" To: oscar@ac.upc.es (Oscar-Ivan Lepe-Aldama) Date: Wed, 9 May 2001 20:38:49 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010510033849.AB8EF37B423@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi, > I would like to have information regarding the implementation of the > xl_start_90xB function in the xl driver. After reading the code and the > technical reference from 3com I still cannot understand how the driver > signals the NIC for packet downloading. It doesn't. Instead, the xl_init() routine sets up the card to perform TX descriptor polling: if (sc->xl_type == XL_TYPE_905B) { /* Set polling interval */ CSR_WRITE_1(sc, XL_DOWN_POLL, 64); /* Load the address of the TX list */ CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_DOWN_STALL); xl_wait(sc); CSR_WRITE_4(sc, XL_DOWNLIST_PTR, vtophys(&sc->xl_ldata->xl_tx_list[0])); CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_DOWN_UNSTALL); xl_wait(sc); } The NIC itself checks to see when new descriptors are added to the download list. This saves the driver from having to issue the command to the NIC in the start routine. The polling feature was not available in the boomerang series chips, only in the cyclone series and later (hurricane, tornado), hence for the older NICs we have to use the non-polling transmit mechanism. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 3:51:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from web5305.mail.yahoo.com (web5305.mail.yahoo.com [216.115.106.114]) by hub.freebsd.org (Postfix) with SMTP id 9637D37B42C for ; Thu, 10 May 2001 03:51:18 -0700 (PDT) (envelope-from vishubp@yahoo.com) Message-ID: <20010510105118.912.qmail@web5305.mail.yahoo.com> Received: from [203.200.20.3] by web5305.mail.yahoo.com; Thu, 10 May 2001 11:51:18 BST Date: Thu, 10 May 2001 11:51:18 +0100 (BST) From: =?iso-8859-1?q?vishwanath=20pargaonkar?= Subject: kernel size.. To: questions@freebsd.org, freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, i have free bsd 4.2 stable. i did some changes may be 10-15 lines to kernel source. but thing i am amazed is kernel size. size of kernel.GENERIC is 3258128. but as of my kernel is 13068130 when i cheked it. my kernel is stable there is no probs. but y is size soo big?? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 8:20:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3B30837B422 for ; Thu, 10 May 2001 08:20:26 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4AFKQY24460 for net@freebsd.org; Thu, 10 May 2001 08:20:26 -0700 (PDT) Date: Thu, 10 May 2001 08:20:26 -0700 From: Alfred Perlstein To: net@freebsd.org Subject: getaddrinfo irritation Message-ID: <20010510082025.J18676@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ok, so I'm trying to write some pretty generic socket code over here. Using "our" APIs (getaddrinfo) is causing me much pain because I can't figure out how to map "tcp" -> SOCK_STREAM. Anyone have any clues on how to do this? TLI seems to make this too easy, but we don't have that. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 8:41:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id EAEBF37B423 for ; Thu, 10 May 2001 08:41:06 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA81367; Thu, 10 May 2001 11:40:49 -0400 (EDT) (envelope-from wollman) Date: Thu, 10 May 2001 11:40:49 -0400 (EDT) From: Garrett Wollman Message-Id: <200105101540.LAA81367@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: getaddrinfo irritation In-Reply-To: <20010510082025.J18676@fw.wintelcom.net> References: <20010510082025.J18676@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Using "our" APIs (getaddrinfo) is causing me much pain because I can't > figure out how to map "tcp" -> SOCK_STREAM. You don't. In the `hints' structure, you pass in ai_socktype == SOCK_STREAM. This is clearly documented in the manual page. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 9: 3:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 393F437B423 for ; Thu, 10 May 2001 09:03:25 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4AG3MG24756; Thu, 10 May 2001 09:03:22 -0700 (PDT) Date: Thu, 10 May 2001 09:03:22 -0700 From: Alfred Perlstein To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: getaddrinfo irritation Message-ID: <20010510090322.K18676@fw.wintelcom.net> References: <20010510082025.J18676@fw.wintelcom.net> <200105101540.LAA81367@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105101540.LAA81367@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, May 10, 2001 at 11:40:49AM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Garrett Wollman [010510 08:41] wrote: > < said: > > > Using "our" APIs (getaddrinfo) is causing me much pain because I can't > > figure out how to map "tcp" -> SOCK_STREAM. > > You don't. In the `hints' structure, you pass in ai_socktype == > SOCK_STREAM. This is clearly documented in the manual page. Duh. :) What I mean is how would one map: localhost:http:tcp into that? There seems to be no way to determine what I must do to ai_socktype based on the above string. Do I have to roll my own lookup code? -- -Alfred Perlstein - [alfred@freebsd.org] http://www.egr.unlv.edu/~slumos/on-netbsd.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 9: 9:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3CC2F37B424 for ; Thu, 10 May 2001 09:09:21 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4AG97s24850; Thu, 10 May 2001 09:09:07 -0700 (PDT) Date: Thu, 10 May 2001 09:09:07 -0700 From: Alfred Perlstein To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: getaddrinfo irritation Message-ID: <20010510090907.L18676@fw.wintelcom.net> References: <20010510082025.J18676@fw.wintelcom.net> <200105101540.LAA81367@khavrinen.lcs.mit.edu> <20010510090322.K18676@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010510090322.K18676@fw.wintelcom.net>; from bright@wintelcom.net on Thu, May 10, 2001 at 09:03:22AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Alfred Perlstein [010510 09:04] wrote: > * Garrett Wollman [010510 08:41] wrote: > > < said: > > > > > Using "our" APIs (getaddrinfo) is causing me much pain because I can't > > > figure out how to map "tcp" -> SOCK_STREAM. > > > > You don't. In the `hints' structure, you pass in ai_socktype == > > SOCK_STREAM. This is clearly documented in the manual page. > > Duh. :) > > What I mean is how would one map: localhost:http:tcp into that? > > There seems to be no way to determine what I must do to ai_socktype > based on the above string. > > Do I have to roll my own lookup code? What I'm trying is something like this: if (proto != NULL) { struct protoent *protoent; protoent = getprotobyname(proto); if (protoent != NULL) addrhint.ai_protocol = protoent->p_proto; else log_error("getprotobyname(%s)", proto); } error = getaddrinfo(addr, service, &addrhint, &addrinfo); Shouldn't it do the mapping of addrhint.ai_protocol=6 (tcp) into ai_socktype = SOCK_STREAM? Isn't this a bug of some sorts? -- -Alfred Perlstein - [alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 9:10:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 83A1537B422 for ; Thu, 10 May 2001 09:10:51 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA81574; Thu, 10 May 2001 12:10:46 -0400 (EDT) (envelope-from wollman) Date: Thu, 10 May 2001 12:10:46 -0400 (EDT) From: Garrett Wollman Message-Id: <200105101610.MAA81574@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: Re: getaddrinfo irritation In-Reply-To: <20010510090322.K18676@fw.wintelcom.net> References: <20010510082025.J18676@fw.wintelcom.net> <200105101540.LAA81367@khavrinen.lcs.mit.edu> <20010510090322.K18676@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > What I mean is how would one map: localhost:http:tcp into that? > There seems to be no way to determine what I must do to ai_socktype > based on the above string. Change the input format. The API was designed around the idea that programs care about which socket model they get, not the specific protocol. > Do I have to roll my own lookup code? Looks like it. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 9:13: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4B17437B422 for ; Thu, 10 May 2001 09:13:07 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA81594; Thu, 10 May 2001 12:12:59 -0400 (EDT) (envelope-from wollman) Date: Thu, 10 May 2001 12:12:59 -0400 (EDT) From: Garrett Wollman Message-Id: <200105101612.MAA81594@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: Re: getaddrinfo irritation In-Reply-To: <20010510090907.L18676@fw.wintelcom.net> References: <20010510082025.J18676@fw.wintelcom.net> <200105101540.LAA81367@khavrinen.lcs.mit.edu> <20010510090322.K18676@fw.wintelcom.net> <20010510090907.L18676@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Shouldn't it do the mapping of addrhint.ai_protocol=6 (tcp) > into ai_socktype = SOCK_STREAM? No. In the socket model, the protocol is subordinate to the type of socket. (For example, XNS SPP can implements both SOCK_SEQPACKET and SOCK_STREAM.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 9:24: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B0AC637B422 for ; Thu, 10 May 2001 09:24:03 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4AGO1h24968; Thu, 10 May 2001 09:24:01 -0700 (PDT) Date: Thu, 10 May 2001 09:24:01 -0700 From: Alfred Perlstein To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: getaddrinfo irritation Message-ID: <20010510092401.M18676@fw.wintelcom.net> References: <20010510082025.J18676@fw.wintelcom.net> <200105101540.LAA81367@khavrinen.lcs.mit.edu> <20010510090322.K18676@fw.wintelcom.net> <20010510090907.L18676@fw.wintelcom.net> <200105101612.MAA81594@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105101612.MAA81594@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, May 10, 2001 at 12:12:59PM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Garrett Wollman [010510 09:13] wrote: > < said: > > > Shouldn't it do the mapping of addrhint.ai_protocol=6 (tcp) > > into ai_socktype = SOCK_STREAM? > > No. In the socket model, the protocol is subordinate to the type of > socket. (For example, XNS SPP can implements both SOCK_SEQPACKET and > SOCK_STREAM.) Ugh, and just when I thought I had it licked... Index: getaddrinfo.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/getaddrinfo.c,v retrieving revision 1.20 diff -u -r1.20 getaddrinfo.c --- getaddrinfo.c 2001/03/17 14:25:23 1.20 +++ getaddrinfo.c 2001/05/10 16:25:10 @@ -415,6 +415,18 @@ } } } + /* + * If only protocol is supplied then lookup socktype + */ + else if (pai->ai_protocol != ANY) { + for (ex = explore; ex->e_af >= 0; ex++) { + if (pai->ai_protocol == ex->e_protocol) { + pai->ai_socktype = ex->e_socktype; + break; + } + } + } + } /* I guess this is a no-no then? It tries to match the protocol with the socktype. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 9:37:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 55BA637B424 for ; Thu, 10 May 2001 09:37:42 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA81740; Thu, 10 May 2001 12:37:39 -0400 (EDT) (envelope-from wollman) Date: Thu, 10 May 2001 12:37:39 -0400 (EDT) From: Garrett Wollman Message-Id: <200105101637.MAA81740@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: net@FreeBSD.ORG Subject: Re: getaddrinfo irritation In-Reply-To: <20010510092401.M18676@fw.wintelcom.net> References: <20010510082025.J18676@fw.wintelcom.net> <200105101540.LAA81367@khavrinen.lcs.mit.edu> <20010510090322.K18676@fw.wintelcom.net> <20010510090907.L18676@fw.wintelcom.net> <200105101612.MAA81594@khavrinen.lcs.mit.edu> <20010510092401.M18676@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I guess this is a no-no then? It tries to match the protocol with > the socktype. Well, the specification appears to leave this possibility open. It says: # A value of zero for ai_socktype means that the caller shall accept # any socket type. So it is not illegitimate for the library to say ``OK, he wants protocol 6, so let's pick a socket type that we know has a protocol 6''; the application has already indicated that it doesn't care. However, I would argue that any application that thinks it doesn't care is broken. So much of the API depends on whether the application is using a connection-oriented or connectionless model that it is difficult to conceive of any non-trivial application that didn't care what sort of socket type it received. So, I would suggest that the correct solution for your program is instead: if (strcmp(protocol, "tcp") == 0) hint.ai_socktype = SOCK_STREAM; else hint.ai_socktype = SOCK_DGRAM; ...or even better, require the user to specify which model it was using. (Again, most programs only make sense for one or the other.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 15: 1: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by hub.freebsd.org (Postfix) with ESMTP id A262F37B422 for ; Thu, 10 May 2001 15:01:02 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from milk.yahoo.com (milk.yahoo.com [206.251.16.37]) by mrout1.yahoo.com (8.11.1/8.11.1/y.out) with ESMTP id f4AM0mL83514; Thu, 10 May 2001 15:00:48 -0700 (PDT) Received: (from root@localhost) by milk.yahoo.com (8.11.0/8.11.0) id f4AM0la49567; Thu, 10 May 2001 15:00:47 -0700 (PDT) (envelope-from jayanth) Date: Thu, 10 May 2001 15:00:47 -0700 From: jayanth To: net@FreeBSD.ORG Cc: jlemon@flugsvamp.com Subject: t/tcp behaviour has changed in -current and -stable Message-ID: <20010510150047.F45897@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I would like to back out the DELAY_ACK macro changes for now. The ttcp code behaviour has changed because of the addition of the DELAY_ACK macro. The macro is forcing the ttcp code to send an immediate SYN, ACK for an initial ttcp segment which has the SYN/FIN/PSH flag set. Instead the SYN,ACK should be delayed such that next segment should be SYN/FIN/PSH from the server side. Change the macro to DELAY_ACK(tp) \ (tcp_delack_enabled) instead of #define DELAY_ACK(tp) \ (tcp_delack_enabled && !callout_pending(tp->tt_delack)) All version before r1.124 seem to work fine http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_input.c.diff?r1=1.123 &r2=1.124&f=h > > /* TTCP Code in tcp_input.c*/ > if ((to.to_flag & TOF_CC) != 0) { > if (((tp->t_flags & TF_NOPUSH) != 0) && > taop->tao_cc != 0 && CC_GT(to.to_cc, taop->tao_cc)) { > taop->tao_cc = to.to_cc; > tp->t_starttime = ticks; > tp->t_state = TCPS_ESTABLISHED; > /* > * If there is a FIN, or if there is data and the > * connection is local, then delay SYN,ACK(SYN) in > * the hope of piggy-backing it on a response > * segment. Otherwise must send ACK now in case > * the other side is slow starting. > */ > if (DELAY_ACK(tp) && ((thflags & TH_FIN) || > (tlen != 0 && > in_localaddr(inp->inp_faddr)))) { > callout_reset(tp->tt_delack, tcp_delacktime, > tcp_timer_delack, tp); > tp->t_flags |= TF_NEEDSYN; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > At this point NEEDSYN is set and so is the delack timer.... > > } else > tp->t_flags |= (TF_ACKNOW | TF_NEEDSYN); > > .................................................... > > if (thflags & TH_FIN) { > if (TCPS_HAVERCVDFIN(tp->t_state) == 0) { > socantrcvmore(so); > /* > * If connection is half-synchronized > * (ie NEEDSYN flag on) then delay ACK, > * so it may be piggybacked when SYN is sent. > * Otherwise, since we received a FIN then no > * more input can be expected, send ACK now. > */ > if (DELAY_ACK(tp) && (tp->t_flags & TF_NEEDSYN)) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > At this point the DELAY_ACK macro returns false because there is a > callout_pending(). Hence the TF_ACKNOW will be set. > ^^^^^^^^^^^^^ > > callout_reset(tp->tt_delack, tcp_delacktime, > tcp_timer_delack, tp); > else > tp->t_flags |= TF_ACKNOW; > jayanth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 10 23:45:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m04.mx.aol.com (imo-m04.mx.aol.com [64.12.136.7]) by hub.freebsd.org (Postfix) with ESMTP id 0DEB137B422 for ; Thu, 10 May 2001 23:45:17 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m04.mx.aol.com (mail_out_v30.10.) id n.7.152f078 (16216) for ; Fri, 11 May 2001 02:45:10 -0400 (EDT) Received: from netscape.com (aimmail02.aim.aol.com [205.188.144.194]) by air-in01.mx.aol.com (v77_r1.37) with ESMTP; Fri, 11 May 2001 02:45:10 -0400 Date: Fri, 11 May 2001 02:45:10 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: size of data to ip layer from tcp layer Mime-Version: 1.0 Message-ID: <2001AD8D.5466FCF3.9513E96F@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, This is regarding the size of data from TCP/UDP layer to the ip layer. The number of bytes sent from tcp layer to ip layer to send depends on the tcp MSS (maxium segment size).For an ethernet this size is 1460 bytes. Based on the above my understanding is this. a) Since MSS is 1460 bytes the maximum number of bytes sent from TCP to ip layer cannot exceed this value. b) The maximum sized packet that can be received by ip layer from ethernet device is 1460 bytes. c) In case the packet is fragmented at the sending end, at the receiving after reassembly the maximum packet size cannot exceed 1460 bytes. Please mail me if my understanding is correct. Also whether for ipv6 there is any change. regards ravi prasad __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 5:42:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f84.law4.hotmail.com [216.33.149.84]) by hub.freebsd.org (Postfix) with ESMTP id 3838E37B422 for ; Fri, 11 May 2001 05:42:36 -0700 (PDT) (envelope-from messiah_man@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 May 2001 05:42:36 -0700 Received: from 130.225.197.29 by lw4fd.law4.hotmail.msn.com with HTTP; Fri, 11 May 2001 12:42:35 GMT X-Originating-IP: [130.225.197.29] From: "Munish Chopra" To: freebsd-net@freebsd.org Subject: xl0: no memory for rx list -- packet dropped! Date: Fri, 11 May 2001 14:42:35 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 May 2001 12:42:36.0043 (UTC) FILETIME=[DB0B55B0:01C0DA17] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org One of the machines on our network spits out the following (constantly): xl0: no memory for rx list -- packet dropped! It is of course unreachable through the network. This popped up on 4.2-RELEASE one single time, then went away after a reboot. Now, on 4.3-RELEASE, it was running fine till about two hours ago. Reboots aren't helping. dmesg returns: 3Com 3c905B-TX Fast Etherlink XL Any help or explanation would be greatly appreciated. Cheers, Munish Chopra _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 6: 0:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by hub.freebsd.org (Postfix) with ESMTP id 4F6CB37B424 for ; Fri, 11 May 2001 06:00:53 -0700 (PDT) (envelope-from barney@mx.databus.com) Received: (from barney@localhost) by mx.databus.com (8.11.3/8.11.3) id f4BD0Yd87066; Fri, 11 May 2001 09:00:34 -0400 (EDT) (envelope-from barney) Date: Fri, 11 May 2001 09:00:34 -0400 From: Barney Wolff To: raviprasad20@netscape.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: size of data to ip layer from tcp layer Message-ID: <20010511090033.A87015@mx.databus.com> References: <2001AD8D.5466FCF3.9513E96F@netscape.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <2001AD8D.5466FCF3.9513E96F@netscape.net>; from raviprasad20@netscape.net on Fri, May 11, 2001 at 02:45:10AM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is not quite true. MSS can be set arbitrarily by the other end of the connection, and if the receiver is on a link with bigger MTU, or just wants things in big batches, it can set MSS up to 65535. It's up to your own end to check both MSS and the link MTU and decide what size segs to send down to IP. IP will fragment if it gets something it can't send on the link in one frame. 1460 is 1500 minus 20 for the IP header and 20 for the TCP header - Standard Ethernet data max is 1500, not 1460. For some special applications (Bridge trunking) this can be expanded somewhat. It would be a very bad idea to hard-code 1460 into any software you're writing. Barney Wolff On Fri, May 11, 2001 at 02:45:10AM -0400, raviprasad20@netscape.net wrote: > Hi, > This is regarding the size of data from TCP/UDP layer to the ip layer. The number of bytes sent from tcp layer to ip layer to send depends on the tcp MSS (maxium segment size).For an ethernet this size is 1460 bytes. > > Based on the above my understanding is this. > > a) Since MSS is 1460 bytes the maximum number of bytes sent from TCP to ip layer cannot exceed this value. > b) The maximum sized packet that can be received by ip layer from ethernet device is 1460 bytes. > c) In case the packet is fragmented at the sending end, at the receiving after reassembly the maximum packet size cannot exceed 1460 bytes. > > Please mail me if my understanding is correct. > Also whether for ipv6 there is any change. > > regards > ravi prasad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 7:44:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m04.mx.aol.com (imo-m04.mx.aol.com [64.12.136.7]) by hub.freebsd.org (Postfix) with ESMTP id 6C7A537B423 for ; Fri, 11 May 2001 07:44:07 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m04.mx.aol.com (mail_out_v30.10.) id n.c2.321831 (16231) for ; Fri, 11 May 2001 10:44:00 -0400 (EDT) Received: from netscape.com (aimmail11.aim.aol.com [205.188.144.203]) by air-in02.mx.aol.com (v77_r1.37) with ESMTP; Fri, 11 May 2001 10:44:00 -0400 Date: Fri, 11 May 2001 10:43:59 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: mbuf organization in case 65536 bytes of data. Mime-Version: 1.0 Message-ID: <43C92CAF.6B5F1DA4.9513E96F@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, My doubt is how data will be organized in buffers in case we want to transmit large amount of data. My doubt is regarding the organization of mbufs in case we want to transmit the maximum ip datagram size. In the normal case data is stored in clusters for data size greater than 208 bytes. My doubt is how the data will be organized in case of such large data. If mbufs are used we will have a long chain. Whether any other buffers are used.how the data is organized in such a case? How the data will be organized in case we want to transmit jumbograms in ipv6. I think that cluster concept of 2K bytes is too small. regards ravi prasad __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 7:45:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from imo-m08.mx.aol.com (imo-m08.mx.aol.com [64.12.136.163]) by hub.freebsd.org (Postfix) with ESMTP id 36A6137B43C for ; Fri, 11 May 2001 07:45:45 -0700 (PDT) (envelope-from raviprasad20@netscape.net) Received: from raviprasad20@netscape.net by imo-m08.mx.aol.com (mail_out_v30.10.) id n.1b.1622f1e (16233) for ; Fri, 11 May 2001 10:45:34 -0400 (EDT) Received: from netscape.com (aimmail11.aim.aol.com [205.188.144.203]) by air-in02.mx.aol.com (v77_r1.37) with ESMTP; Fri, 11 May 2001 10:45:34 -0400 Date: Fri, 11 May 2001 10:45:34 -0400 From: raviprasad20@netscape.net To: freebsd-net@freebsd.org Subject: mbuf organization Mime-Version: 1.0 Message-ID: <20BDEDE9.63310C1F.9513E96F@netscape.net> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, My doubt is how data will be organized in buffers in case we want to transmit large amount of data. My doubt is regarding the organization of mbufs in case we want to transmit the maximum ip datagram size. In the normal case data is stored in clusters for data size greater than 208 bytes. My doubt is how the data will be organized in case of such large data. If mbufs are used we will have a long chain. Whether any other buffers are used.how the data is organized in such a case? How the data will be organized in case we want to transmit jumbograms in ipv6. I think that cluster concept of 2K bytes is too small. regards ravi prasad __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 13:17:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from manhattan-gw.iij-america.com (manhattan-gw.iij-america.com [216.98.98.244]) by hub.freebsd.org (Postfix) with ESMTP id 788AD37B43C for ; Fri, 11 May 2001 13:17:21 -0700 (PDT) (envelope-from itojun@itojun.org) Received: by manhattan-gw.iij-america.com; id FAA12407; Sat, 12 May 2001 05:17:11 +0900 (JST) Received: from unknown(192.168.241.148) by manhattan-gw.iij-america.com via smap (4.1) id xma012398; Sat, 12 May 01 05:16:58 +0900 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 133D47D4; Sat, 12 May 2001 05:16:28 +0900 (JST) To: Nick Rogness Cc: freebsd-net@freebsd.org Subject: Re: gif tunnel woes X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino References: Date: Sat, 12 May 2001 05:16:27 +0900 Message-Id: <20010511201628.133D47D4@starfruit.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hello, regarding to the note on: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+2538+/usr/local/www/db/text/2001/freebsd-net/20010506.freebsd-net the symptom is repeatable. however, it seems to me that the multi destination mode is poorly documented, and needs certain (strange) configuration to work properly. i have no idea how can it be useful. the destination tunnel gateway address is taken from rt_gateway, so i guess you'd need to set routing table like this: % route add -inet 192.168.10.0 24.27.51.59 % route change -inet 192.168.10.0 24.27.51.59 -ifp gif0 which seems very counter-intuitive to me (NOTE: i did not test this). my preference is to dropp support for multi-destination mode from gif(4), as the multi-destination behavior is violating network layering (rt_gateway is in inner header, and gif(4) multi-destination mode uses it to determinte outer header). itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 14:20:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 085B537B424 for ; Fri, 11 May 2001 14:20:49 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f4BMXAb09127; Fri, 11 May 2001 17:33:11 -0500 (CDT) (envelope-from nick@rogness.net) Date: Fri, 11 May 2001 17:33:10 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Jun-ichiro itojun Hagino Cc: freebsd-net@FreeBSD.ORG Subject: Re: gif tunnel woes In-Reply-To: <20010511201628.133D47D4@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 12 May 2001, Jun-ichiro itojun Hagino wrote: > hello, regarding to the note on: > > > http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+2538+/usr/ > local/www/db/text/2001/freebsd-net/20010506.freebsd-net First off thanks a million for the response. > >the symptom is repeatable. however, it seems to me that the multi >destination mode is poorly documented, and needs certain (strange) >configuration to work properly. i have no idea how can it be useful. The reason I was experimenting in it was because using bi-directional gif tunnels, the number of them has to be staticlly compiled in ther kernel and has no way of growing the actual number of gif interfaces dynamically. So my options were to build N number of gif interfaces for every machine, or use nos-tun. The multi-destination tunnels could have been a work around...if they would have worked right. >the destination tunnel gateway address is taken from rt_gateway, >so i guess you'd need to set routing table like this: > >% route add -inet 192.168.10.0 24.27.51.59 >% route change -inet 192.168.10.0 24.27.51.59 -ifp gif0 > >which seems very counter-intuitive to me (NOTE: i did not test this). > >my preference is to dropp support for multi-destination mode >from gif(4), as the multi-destination behavior is violating network >layering (rt_gateway is in inner header, and gif(4) multi-destination > mode uses it to determinte outer header). Which would be fine. It would be nice to have a way to grow these gif tunnels on the fly, then nos-tun could be strapped as well. Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 15: 4:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id B4E4A37B423 for ; Fri, 11 May 2001 15:04:55 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.3/8.11.3) with ESMTP id f4BM2K256031; Fri, 11 May 2001 18:02:20 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <200105112202.f4BM2K256031@whizzo.transsys.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Jun-ichiro itojun Hagino Cc: Nick Rogness , freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: gif tunnel woes References: <20010511201628.133D47D4@starfruit.itojun.org> In-reply-to: Your message of "Sat, 12 May 2001 05:16:27 +0900." <20010511201628.133D47D4@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 May 2001 18:02:20 -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > my preference is to dropp support for multi-destination mode from > gif(4), as the multi-destination behavior is violating network layering > (rt_gateway is in inner header, and gif(4) multi-destination mode > uses it to determinte outer header). There's certainly a bunch of NBMA network media out there. The problem is abusing the routing table next hop as a way to specify the remote tunnel endpoint. This should be an attribute of the gif interface, configured outside of the routing infrastructure. Or, perhaps treated like ARP for ethernet; it's just an accident that the "MAC" address for a multi-point NBMA tunnel is an IPv4/IPv6 address. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 16:42:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id D90D037B62D; Fri, 11 May 2001 16:42:13 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA12297; Fri, 11 May 2001 16:42:11 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAx6aq3x; Fri May 11 16:41:56 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA04578; Fri, 11 May 2001 16:43:00 -0700 (MST) From: Terry Lambert Message-Id: <200105112343.QAA04578@usr08.primenet.com> Subject: FreeBSD breaks sockets two ways... To: freebsd-net@FreeBSD.ORG Date: Fri, 11 May 2001 23:43:00 +0000 (GMT) Cc: arch@FreeBSD.ORG X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have run into two issues, that I find really, really annoying. This is in FreeBSD 4.3 and 5.x. Bot machines are on a local (non-switched) segment (it works the same with a switch, but taking that out proves it is not the switch causing the problem). Primus ------ The first is that when you create a socket, and bind it to a specific local IP address, and then connect, it fails to allocate an automatic port private to the socket; specifically: int s; struct sockaddr_in sockaddr; s = socket(AF_INET, SOCK_STREAM, 0); bzero(&sockaddr,sizeof(sockaddr)); sockaddr.sin_family = AF_INET; sockaddr.sin_addr.s_addr = s_addr2; sockaddr.sin_port = 0; if (bind(s, (struct sockaddr *) &sockaddr, sizeof(sockaddr)) == -1) { perror("bind"); errx(1, "bind failed"); } ...in other words, the sockets are all hashed into the same (global) collsion domain, even though they are _not_ global, they are specific to a particular IP address. Secondus -------- On an OS where the above actually works (e.g. _not_ FreeBSD), when I make connections from two ports which are the same, but with different IP addresses, it seems that the MAC address is used by FreeBSD to differentiate connections, and _not_ the IP/port pair. This means that on FreeBSD, the incoming connection on two different source IPs from the same MAC address end up resetting the first connection, when the second one comes in; instead of getting two total connections, I end up getting only a single connection. Both of these seem to be serious screwups in the routing code hash lookup algorithm, acting as if everything is in the INADDR_ANY domain, and as if it were keying off the MAC address, and not the IP address... as it should be. Has anyone else seen this? Obviously, it's hard to reproduce FreeBSD-to-FreeBSD (at least without a BPF program on the client side to cause the problem)... I'm primarily interested in a fix for 4.3. Thanks, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 16:54:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.tgd.net (rand.tgd.net [64.81.67.117]) by hub.freebsd.org (Postfix) with SMTP id 0E67637B43E for ; Fri, 11 May 2001 16:54:38 -0700 (PDT) (envelope-from sean@mailhost.tgd.net) Received: (qmail 67706 invoked by uid 1001); 11 May 2001 23:54:32 -0000 Date: Fri, 11 May 2001 16:54:32 -0700 From: Sean Chittenden To: Terry Lambert Cc: freebsd-net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: FreeBSD breaks sockets two ways... Message-ID: <20010511165432.A67648@rand.tgd.net> References: <200105112343.QAA04578@usr08.primenet.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <200105112343.QAA04578@usr08.primenet.com>; from "tlambert@primenet.com" on Fri, May 11, 2001 at = 11:43:00PM X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ X-All-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Are you sure it's failing to allocate the port? I had a similar problem in trying to connect to a service, but found out that aliasing an IP didn't add the arp entry in the routing table (local connections were failing). If I added the arp entry by hand, everything was happy (is IP aliasing a part of the scneario you're describing?). arp -s a.b.c.d 00:60:08:aa:aa:aa pub arp -s a.b.c.e 00:60:08:aa:aa:ab pub A tad annoying, but it seems to work (yeah, I know about the ethers file, but I refuse to use it). -sc On Fri, May 11, 2001 at 11:43:00PM +0000, Terry Lambert wrote: > I have run into two issues, that I find really, really annoying. This > is in FreeBSD 4.3 and 5.x. Bot machines are on a local (non-switched) > segment (it works the same with a switch, but taking that out proves > it is not the switch causing the problem). >=20 >=20 > Primus > ------ >=20 > The first is that when you create a socket, and bind it to a > specific local IP address, and then connect, it fails to > allocate an automatic port private to the socket; specifically: --=20 Sean Chittenden --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: Sean Chittenden iEYEARECAAYFAjr8e7cACgkQn09c7x7d+q2tuQCaA6PwZyW5IG33AgevgaN+n5so pZkAnRjax8S0kGKdusPUWJ1/dv9si1FN =tJcl -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 17:36:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by hub.freebsd.org (Postfix) with ESMTP id 0B07337B43C for ; Fri, 11 May 2001 17:36:27 -0700 (PDT) (envelope-from nicolas.beauchesne@polymtl.ca) Received: from pornstar.polymtl.ca (HSE-Montreal-ppp3464504.sympatico.ca [65.92.182.98]) by smtp.polymtl.ca (8.9.3/8.9.3) with SMTP id UAA08772 for ; Fri, 11 May 2001 20:36:25 -0400 Message-Id: <200105120036.UAA08772@smtp.polymtl.ca> To: freebsd-net@freebsd.org Subject: gateway+multi-PPPoE Date: Fri, 11 May 2001 20:57:00 EDT From: "nicolas beauchesne" MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Reply-To: nicolas.beauchesne@polymtl.ca X-Mailer: BeOS Mail Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I'm triyng to set-up a Gateway that will use 3 different PPPoE (to the same provider) adsl connection (3 modem , 3 account), to distribute it back to a soho network. In instance to get the more bandwith possible. I've been able to set-up the gateway with one modem by using netgraph and PPP. I tought that using mpd would allow me to to get the maximun of these three connections. It seem to work well on the gateway. But the rest of the network is dead (the gate way see everybody and vice versa) but station dont see the net. If somebody have any idea how to make that thing work it will be a great help. P.S. I try that solution, if there's other who work better, please tell me . thanks Nicolas Beauchesne nicolas.beauchesne@polymtl.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 18:33:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 7532737B424 for ; Fri, 11 May 2001 18:33:33 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id AF49F4B0B; Sat, 12 May 2001 10:33:18 +0900 (JST) To: "Louis A. Mamakos" Cc: Nick Rogness , freebsd-net@FreeBSD.ORG In-reply-to: louie's message of Fri, 11 May 2001 18:02:20 -0400. <200105112202.f4BM2K256031@whizzo.transsys.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: gif tunnel woes From: itojun@iijlab.net Date: Sat, 12 May 2001 10:33:18 +0900 Message-ID: <12623.989631198@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> my preference is to dropp support for multi-destination mode from >> gif(4), as the multi-destination behavior is violating network layering >> (rt_gateway is in inner header, and gif(4) multi-destination mode >> uses it to determinte outer header). > >There's certainly a bunch of NBMA network media out there. The problem is >abusing the routing table next hop as a way to specify the remote >tunnel endpoint. This should be an attribute of the gif interface, >configured outside of the routing infrastructure. Or, perhaps treated >like ARP for ethernet; it's just an accident that the "MAC" address for >a multi-point NBMA tunnel is an IPv4/IPv6 address. well, in the case of ARP entries, you know that it is a layer-2 address (MACaddress) on rt_gateway because it is tagged as AF_LINK. for the routing entries used by gif multi desination mode, rt_gateway field is not distinguishable (if it is outer addr or inner addr). also i guess it unsuitable to compare with NBMA networks, as with most of the NBMA networks i guess rt_gateway field takes an AF_LINK sockaddr, not an AF_INET. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 11 18:46:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id B904B37B424; Fri, 11 May 2001 18:46:51 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id SAA00722; Fri, 11 May 2001 18:46:44 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpdAAAh3a4vb; Fri May 11 18:46:35 2001 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA24408; Fri, 11 May 2001 18:52:27 -0700 (MST) From: Terry Lambert Message-Id: <200105120152.SAA24408@usr06.primenet.com> Subject: Re: FreeBSD breaks sockets two ways... To: freebsd-net@FreeBSD.ORG Date: Sat, 12 May 2001 01:52:17 +0000 (GMT) Cc: arch@FreeBSD.ORG X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ] Are you sure it's failing to allocate the port? ] ] I had a similar problem in trying to connect to a service, but ] found out that aliasing an IP didn't add the arp entry in the routing ] table (local connections were failing). If I added the arp entry by ] hand, everything was happy (is IP aliasing a part of the scneario ] you're describing?). ] ] arp -s a.b.c.d 00:60:08:aa:aa:aa pub ] arp -s a.b.c.e 00:60:08:aa:aa:ab pub ] ] A tad annoying, but it seems to work (yeah, I know about the ] ethers file, but I refuse to use it). -sc Unfortunately, I'm very certain. I talked to Bill Paul about the gratuitous ARP problem last night; I was well aware of it; we added the ARP entries by hand to the target for the aliases on the source machine. I'm _positive_ on the outbound connection problem (the code fragment I attached should have done the job, and I've seen the FreeBSD code that's the problem, but am still pondering about how to fix it; I think I'll have to do two lookups, or hang a chain off a hash bucket indexed by IP last (instead of port). Hopefully, someone will get to this before I do. We've also tried by setting up the ARP table for the target machine, and then written the aforementioned BPF program to stage the connection attempts from a single client machine. We did the same thing from a second client on the same segment. The single client, two IP attempt failed, while the two machine attempt succeeded. The only difference in the packets that was reported by tcpdump was the source MAC address -- otherwise, they were byte-for-byte identical. So there is definitely a problem there with the index being by MAC instead of IP. Maybe this came in as part of the "aliased IP NFS client being seen as an attacker by the server" fix? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 12 2:55:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 3CDA037B43E for ; Sat, 12 May 2001 02:55:21 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4C9tF398464; Sat, 12 May 2001 10:55:15 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4C9tBX65051; Sat, 12 May 2001 10:55:11 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105120955.f4C9tBX65051@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: nicolas.beauchesne@polymtl.ca Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: gateway+multi-PPPoE In-Reply-To: Message from "nicolas beauchesne" of "Fri, 11 May 2001 20:57:00 EDT." <200105120036.UAA08772@smtp.polymtl.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 May 2001 10:55:11 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Hi! > > I'm triyng to set-up a Gateway that will use 3 different PPPoE (to > the same provider) adsl connection (3 modem , 3 account), to > distribute it back to a soho network. In instance to get the more > bandwith possible. > > I've been able to set-up the gateway with one modem by using netgraph > and PPP. > > I tought that using mpd would allow me to to get the maximun of these > three connections. ppp should do that too. > It seem to work well on the gateway. But the rest of the network is > dead (the gate way see everybody and vice versa) but station dont see > the net. > > If somebody have any idea how to make that thing work it will be a > great help. You don't describe exactly how you've got things set up. Are you using Multi-link ppp over PPPoE links ? If so, you'll need a very co-operative provider to sit at the other end. If you're setting up 3 distinct PPPoE links and then running a 4th ppp session using multi-link with (say) UDP links that talk accross each of your PPPoE setups to a remote server which demuxes them (by running a similar multi-link ppp setup), then you should be able to get this working :0) Feel free to post your configuration and I can see if it makes sense to me. > P.S. I try that solution, if there's other who work better, please tell > me . > thanks > > Nicolas Beauchesne > nicolas.beauchesne@polymtl.ca -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 12 6:25: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from sonic.kks.net (sonic.kks.net [213.161.0.18]) by hub.freebsd.org (Postfix) with ESMTP id 6D60037B43E for ; Sat, 12 May 2001 06:25:02 -0700 (PDT) (envelope-from maddave@suxx.eu.org) Received: from server.kibernet.net (8-158.ta.cable.kks.net [213.161.8.158]) by sonic.kks.net (Postfix) with ESMTP id 8C2DF1A for ; Sat, 12 May 2001 15:24:59 +0200 (CEST) Received: from spider.suxx.eu.org (unknown [194.249.141.2]) by server.kibernet.net (Postfix) with ESMTP id 6DBE6243A8 for ; Sat, 12 May 2001 15:24:52 +0200 (CEST) Received: by spider.suxx.eu.org (Postfix, from userid 1000) id DDADF1752E; Sat, 12 May 2001 15:26:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by spider.suxx.eu.org (Postfix) with ESMTP id BC9D532684 for ; Sat, 12 May 2001 15:26:08 +0200 (CEST) Date: Sat, 12 May 2001 15:26:08 +0200 (CEST) From: David Delibasic To: Subject: DUMMYNET and IPv6 Message-ID: <20010512152550.X20493-100000@spider.suxx.eu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hellow .... Will IPv6 start supporting DUMMYNET and when ??? With Regards, David > FreeBSD < -- > Power so serve < > Line noise provided by Telekom Slovenia < To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 12 13:57:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from mr200.netcologne.de (mr200.netcologne.de [194.8.194.109]) by hub.freebsd.org (Postfix) with ESMTP id 3C3FE37B423 for ; Sat, 12 May 2001 13:57:08 -0700 (PDT) (envelope-from pherman@frenchfries.net) Received: from husten.security.at12.de (dial-213-168-73-206.netcologne.de [213.168.73.206]) by mr200.netcologne.de (Mirapoint) with ESMTP id AFK23433; Sat, 12 May 2001 22:57:05 +0200 (CEST) Received: from localhost (localhost.security.at12.de [127.0.0.1]) by husten.security.at12.de (8.11.3/8.11.3) with ESMTP id f4CKuvj36941; Sat, 12 May 2001 22:56:57 +0200 (CEST) (envelope-from pherman@frenchfries.net) Date: Sat, 12 May 2001 22:56:57 +0200 (CEST) From: Paul Herman To: jayanth Cc: , Subject: Re: t/tcp behaviour has changed in -current and -stable In-Reply-To: <20010510150047.F45897@yahoo-inc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 10 May 2001, jayanth wrote: > I would like to back out the DELAY_ACK macro changes for now. The > ttcp code behavior has changed because of the addition of the > DELAY_ACK macro. > > The macro is forcing the ttcp code to send an immediate SYN, ACK > for an initial ttcp segment which has the SYN/FIN/PSH flag set. > Instead the SYN,ACK should be delayed such that next segment > should be SYN/FIN/PSH from the server side. I'm hesitant to comment, because I don't really have a patch :-) but I'll give it a whirl anyway. Thing is, delack is still broken. It just isn't nearly as broken now as it was before the patch. I'm pretty sure what you are seeing now, worked before only because of the brokenness. The way to go here is to fix this problem. Besides, if you back out the latest delack change, ttcp will be affected by the old delack problems anyway. I don't have a testbed for ttcp, so I'm flying blind, but how about where you wrote: > if (DELAY_ACK(tp) && (tp->t_flags & TF_NEEDSYN)) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > At this point the DELAY_ACK macro returns false because there is a > callout_pending(). Hence the TF_ACKNOW will be set. If the new ttcp SYN,ACKs *always* get delayed, having something like: if ( (DELAY_ACK(tp) || this_is_a_ttcp_connection) && (tp->t_flags & TF_NEEDSYN)) - or - if ( tcp_delack_enabled && (!callout_pending(...) || this_is_a_ttcp_connection) && (tp->t_flags & TF_NEEDSYN)) ...depending on what The Right Thing is when tcp_delack_enabled = 0. I don't know ttcp, so of course "this_is_a_ttcp_connection" should be replaced with the corresponding boolean. -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 12 16:59:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.cruzio.com (dsl3i239.cruzio.com [205.179.211.239]) by hub.freebsd.org (Postfix) with ESMTP id 165ED37B43E for ; Sat, 12 May 2001 16:59:08 -0700 (PDT) (envelope-from brucem@mail.cruzio.com) Received: (from brucem@localhost) by mail.cruzio.com (8.11.3/8.11.3) id f4CNkxk00390 for freebsd-net@freebsd.org; Sat, 12 May 2001 16:46:59 -0700 (PDT) (envelope-from brucem) Date: Sat, 12 May 2001 16:46:59 -0700 (PDT) From: "Bruce R. Montague" Message-Id: <200105122346.f4CNkxk00390@mail.cruzio.com> To: freebsd-net@freebsd.org Subject: Linksys Wavelan WPC11 non-laptop links Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This describes setup of an 802.11b (Wi-Fi) radio link between two desktop (non-laptop) PCs using LinkSys Wavelan cards and without using a separate access point, One end of the link ran FreeBSD 4.3-RC #5 and the other PicoBSD (same source code, that is, using 4.3 freebsd-stable). I knew little about this when I started, and if there is a single doc capturing this information I didn't find it. I used two LinkSys WPC11 wireless PCMCIA cards (which seem relatively common and reasonably cheap) and did _not_ use a separate base station or access point; the link is point-to-point. Although I found a number of helpful resources, there are a number of variables and a manual driver patch was required (for 4.3 freebsd-stable), so I thought I'd log this in one place. If I'm off in the weeds anywhere in the following or putting out bogus info, please let me know... ---------------------------------- * Helpful URLS include: http://www.live.com/wireless/unix-base-station.html http://www.onlamp.com/pub/a/bsd/2000/11/02/Big_Scary_Daemons.html http://people.freebsd.org/~wpaul/wi.patch and the online CVS files at http://www.freebsd.org/cgi/cvsweb.cgi * The LinkSys WPC11 PCMCIA card is similar to the Lucent Orinoco "gold/silver" cards, but with a few differences (incompatibilities). The generic name for these cards is "WAVELAN/IEEE 802.11b". The FreeBSD-stable driver ("device wi") is in files "/usr/src/sys/i386/isa/if_wi.c" and "if_wiregs.h". This driver has been moved in freebsd-current to the "usr/src/sys/dev/wi" directory, and appears to be undergoing a reasonable amount of enhancement (including mods motivated by "Linksys cards"). The "isa/if_wi.c" source has been moved to the attic, that is, deprecated. The wi driver is colloquially known as the "FreeBSD Wavelan driver" and on non-laptops under freebsd-stable it only works with ISA->PCMCIA bridge cards (not PCI->PCMCIA bridge cards). The chipset in the WPC11 is the Intersil (ex-Harris) HFA3841/HFA3842. The interface to the Orinoco and similar cards is based on some sort of firmware-driven microcontroller called the Lucent Hermes. Getting Lucent doc for this has apparently been a source of problems. According to the required "if_wi.c" driver patch for freebsd-stable, the WPC11 uses the "PRISM II chip" as opposed to the "Lucent chip". * Due to differences in laptop and non-laptop PCI hardware, use of a PCI->PCMCIA bridge card in non-laptops is not currently supported in FreeBSD-stable. See: http://groups.yahoo.com/group/freebsd-hackers/message/61239 * Thus, to use PCMCIA cards (PCCARDS) in desktop FreeBSD systems, ISA->PCMCIA bridge cards must be used. I had a hard time finding these. I ended up using two "LinkSys ProConnect Desktop PCMCIA Card Reader/Writer" (Model PCMRDWR) kits. These include an "internal" ISA->PCMCIA bridge card that connects by ribbon cable to a 2-slot PCMCIA card adapter physically similar to a floppy-drive unit. These are considered "external" PCMCIA kits because the PCMCIA card does not mount directly into the bridge card. PCI->PCMCIA bridge kits seem to be quite popular currently in association with Windows wireless networks. These seem to almost all be "internal" kits, that is, the PCMCIA card mounts directly in the bridge card, extending out the back of the PC. * A patch by Bill Paul must be applied to the FreeBSD-stable "isa/if_wi.c" driver file to support the LinkSys WPC11. It looks like there might be a slight version problem between the patch and 4.3 stable. Key steps to installing and configuring picobsd and freebsd support for the WPC11, using 4.3 freebsd-stable source, are: ------------------------------------- * In both kernel config files, assure the Wavelan driver is added: --- device wi --- This is already the case in GENERIC. In picobsd you probably need to put it into the PICOBSD config file in your config directory. ------------------------------------- * In both kernel config files, you also need the PCMCIA driver (also already in GENERIC, you'll probably only need one device in picobsd): ---- # PCCARD (PCMCIA) support device card device pcic0 at isa? irq 0 port 0x3e0 iomem 0xd0000 device pcic1 at isa? irq 0 port 0x3e2 iomem 0xd4000 disable ----- ------------------------------------- * Modify "/usr/src/sys/i386/isa/if_wi.c" and "/usr/src/sys/i386/isa/if_wiregs.h" as per patch: http://people.freebsd.org/~wpaul/wi.patch That is, download the patch in the "i386/isa" directory and do a "patch iobase = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, (1 << 6), rman_make_alignment_flags(1 << 6) | RF_ACTIVE); ---------------- with: ---------------- static int wi_alloc(dev) device_t dev; { struct wi_softc *sc = device_get_softc(dev); int rid; rid = 0; sc->iobase = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, (1 << 6), RF_ACTIVE); /* rman_make_alignment_flags(1 << 6) | RF_ACTIVE); */ ---------------- That is, just make the last argument "RF_ACTIVE". The "rman_make_alignment_flags()" looks like it works in freebsd-current. ------------------------------------ * Modify the FreeBSD "rc.conf" file to init the PCCARD driver via "pccardc" and run the PCCARD daemon, "pccardd" (add the following to "/etc/rc.conf"): --------------- pccard_enable="YES" pccard_mem="DEFAULT" --------------- For picoBSD, I ran the programs directly by editing "rc" (here "geode_ipfw" was my custom directory). In file: /usr/src/release/picobsd/geode_ipfw/floppy.tree/etc/rc add near the end: --------------- #### Enable pccard support: pccardc pccardmem 0xd0000 1>/dev/null && echo -n ' memory' pccardd -f /etc/pccard.conf && echo -n ' pccardd' ##### --------------- The "pccardd" command specifies a non-default "pccard.conf" (the "-f"; there is no "/etc/defaults" directory in a typical picoBSD configuration). ------------------------------------ * The "pccardd" daemon controls PCCARD activation on card insert. It is driven by a "database" config file that contains defaults for various known PCCARDS. Under FreeBSD the file is: /etc/defaults/pccard.conf This file does not contain a description for the LinkSys WPC11. The standard technique for adding "custom" PCCARD definitions is to put them in a "/etc/pccard.conf" file that is included by "/etc/defaults/pccard.conf". I created an "/etc/pccard.conf" file consisting of the following (a definition for the WPC11): --------------- # LinkSys WPC11: Derivative of Lucent WaveLAN/IEEE card "Instant Wireless " " Network PC CARD" config 0x1 "wi0" 9 0x10000 # insert sh /etc/server.sh --------------- * Note that it is _imperative_ that the strings on the "card" line be given exactly as specified, that is, with the trailing and leading spaces. These are the names that are displayed by the "pccardc dumpcis" command (see below). If these strings do not match, the "pccardd" daemon will complain - "No card in database for "Instant Wireless "(" Network PC CARD")". * The "9" in the "config" line is the IRQ used by the WPC11. This must be correct, that is, an available unused IRQ. Find an unused IRQ by doing a "dmesg | egrep irq" and using knowledge of the machine. A wrong irq often results in messages of the form "wi0: device timeout". * The " 0x10000 " in the "config" line is a set of control flags passed to the driver. IT IS ACTUALLY THESE FLAGS, not any hardware signature, that determines whether the driver treats the hardware as a Prism II or Lucent chip (vitally important). * Remove the comment # on the "insert" line after your "server.sh" (or whatever path/name) startup-script has been manually verified. ------------------------------------ * The last line in the "pccard.conf" file must be terminated by a new-line or the "pccardd" program will hang forever. ------------------------------------ * In picoBSD, you do not want to include the entire "pccard.conf" file, just the data you need. Create a file (using your config dir): /usr/src/release/picobsd/geode_ipfw/floppy.tree/etc/pccard.conf that consists of the following: --------------- # picoBSD PCCARD configuration file # # Generally available IO ports io 0x240-0x360 # Generally available IRQs (Built-in sound-card owners remove 5) irq 3 5 10 11 15 # Available memory slots memory 0xd4000 96k # # # # LinkSys WPC11: Derivative of Lucent WaveLAN/IEEE card "Instant Wireless " " Network PC CARD" config auto "wi" ? 0x10000 # insert sh /etc/client.sh # --------------- Again note that the last line in "pccard.conf" must end in a newline to avoid a "pccardd" hang. Depending on your hardware configuration, you may need to hardcode the "config" similar to the FreeBSD case. Remove the comment # from the "insert" line after your "client.sh" startup-script has been manually verified. ------------------------------------ * For picoBSD, add "pccardc", "pccardd", and "wicontrol" to the system to be built. In my example, in file: /usr/src/release/picobsd/geode_ipfw/crunch.conf add the following: ------- srcdirs /usr/src/usr.sbin/pccard # ------- and ------- progs pccardc progs pccardd progs wicontrol ------- The "source directories" needed in "crunch.conf" are the directories where the "Makefile" that builds the program is located. ------------------------------------ * The "card0" device node needs to exist in "/dev". * In picoBSD, edit the file named "config" in your configuration directory, for instance, in my case I edited file: /usr/src/release/picobsd/geode_ipfw/config: and added "card0" to the end: MY_DEVS=" ... card0" A complete example for my device build line is: ------- MY_DEVS="std tun2 vty10 fd0 ad0 ad0s1 ad0s2 acd0 pty0 cuaa0 cuaa1 bpf0 bpf1 bpf2 ad0s1a ad0s1b ad0s1c ad0s2a ad0s2b ad0s2c card0" ------- ------------------------------------ * Create start-scripts to bring up both sides of the link. The smallest connectivity-test scripts I used were: On the FreeBSD system, "/etc/server.sh": ------------------ # # Server-side 802.11b (WiFi) radio set-up. # # Note if you are using 40-bit cards, that # names are limited to 5 characters (5*8). # Newer cards may be 128-bit cards. # ifconfig wi0 down # wicontrol -i wi0 -c 0 wicontrol -i wi0 -p 3 # ifconfig wi0 192.168.0.2 # ------------------ On the picoBSD system, in: /usr/src/release/picobsd/geode_ipfw/floppy.tree/etc/client.sh file contents: ------------------ # # client-side 802.11b (WiFi) radio set-up. # # Note if you are using 40-bit cards, that # names are limited to 5 characters (5*8). # Newer cards may be 128-bit cards. # # ifconfig wi0 down # wicontrol -i wi0 -c 0 wicontrol -i wi0 -p 3 # ifconfig wi0 192.168.0.14 # ------------------ (naturally your IP addresses will differ). The "-c 0" means not to create (or join?) a BSS (cell) and "-p 3" means to operate the "port" in ad-hoc mode. In ad-hoc mode PCs talk directly to each other (as if on an ethernet link). Although apparently not necessary in ad-hoc mode, it seems reasonable to assign "station" (node) names ("-s") and the name of the "radio network" ("service set", SS, similar to a "cell") that one wants to join ("-n"). To actually create the named SS, use "-q" on the ``server'' (this probably only has meaning in BSS mode). Also, using encryption (WEP) and setting a key should be done in real operation. A more realistic set of startup-scripts is: ------------------ # # Server-side 802.11b (WiFi) radio set-up. # # Note if you are using 40-bit cards, that # names are limited to 5 characters (5*8). # Newer cards may be 128-bit cards. # ifconfig wi0 down # wicontrol -i wi0 -s srv1 # `station' (node) name. wicontrol -i wi0 -n bruce # Name of `radio-net/set' to join. wicontrol -i wi0 -q bruce # Name of `radio-net/set' to create. # wicontrol -i wi0 -e 1 # WEP encryption ON. wicontrol -i wi0 -k 0x1234512345 -v 1 # Set key 1. wicontrol -i wi0 -T 1 # Use key 1. # wicontrol -i wi0 -c 0 # No IBSS (AP). wicontrol -i wi0 -p 3 # Ad-hoc mode. # ifconfig wi0 192.168.0.2 # IP address. # ------------------ ------------------ # # client-side 802.11b (WiFi) radio set-up. # # Note if you are using 40-bit cards, that # names are limited to 5 characters (5*8). # Newer cards may be 128-bit cards. # # ifconfig wi0 down # wicontrol -i wi0 -s foo # `station' (node) name. wicontrol -i wi0 -n bruce # Name of `radio-net/set' to join. # # wicontrol -i wi0 -e 1 # WEP encryption ON. wicontrol -i wi0 -k 0x1234512345 -v 1 # Set key 1. wicontrol -i wi0 -T 1 # Use key 1. # wicontrol -i wi0 -c 0 # No IBSS. wicontrol -i wi0 -p 3 # Ad-hoc mode. # ifconfig wi0 192.168.0.14 # IP address. # ------------------ ------------------------------------ * Both systems should be rebuilt, and then booted once with the verbose switch (on FreeBSD, press enter on countdown and then "boot -v"). For (the new non-/boot/loader) picoBSD, at the "boot:" countdown prompt, type "-v" and hit Enter. * After boot, scan the output of "dmesg" for: "wi0: found PrismII chip" If you see "wi0: found Lucent chip", your "pccard.conf" file has something wrong. ------------------------------------ * In FreeBSD, assure that "card0" exists. "cd /dev" and do a "MAKEDEV card0" if no "card0" exists. ------------------------------------ * Manually execute and test the startup-scripts that contain the "wicontrol" commands. The "wicontrol" program can be considered a logical extension to "ifconfig" (in NetBSD it is apparently called "wiconfig"). * Before executing the scripts, an "ifconfig" will show "wi0" is not "UP", and the red LED on the WPC11 card will blink constantly. * Assigning "wi0" an IP address will also bring the device "UP". When this happens, the red LED on the WPC11 will stay solidly on. * A "wi0: init failed" always occurs on driver startup. This is a timeout. It appears innocuous. * Naturally, before using the link you need to configure your routing tables with commands on both systems similar to: netstat -rn route add default 192.168.0.2 * After this, the link should work. Verify with a "ping" to the other system, then exercise other TCP/IP traffic. ------------------------------------ * Commands that can be used to display status: -------------- * To display WPC11 settings: >wicontrol or >wicontrol -i wi0 Both these commands produce the same output; the default argument is "-i wi0". Output of this command includes the station (node) and "service set ID" (radio network) names: Station name: [ srv1 ] SSID for IBSS creation: [ bruce ] Current netname (SSID): [ bruce ] Desired netname (SSID): [ bruce ] Current BSSID: [ 00:00:00:00:00:00 ] These names are not to be confused with DNS or other names. The BSSID is 0 in 802.11b ad-hoc mode. Other values of interest are: Port type (1=BSS, 3=ad-hoc): [ 3 ] MAC address: [ 00:dd:e5:c0:00:72 ] TX rate (selection): [ 3 ] TX rate (actual speed): [ 11 ] Create IBSS: [ Off ] WEP encryption: [ Off ] TX encryption key: [ 1 ] Encryption keys: [ ][ ][ ][ ] The "Off" flag for "Create IBSS" indicates the card is in 802.11b ad-hoc mode. To see the values for transmit (TX) rate, do a "man wicontrol", which shows 3 to be "auto select high". -------------- * To display 802.11b link stats: >wicontrol -o This is useful for checking error rates on wireless links. -------------- * To display firmware PCMCIA values/settings in the WPC11 card: >pccardc dumpcis This shows the PCMCIA "Card Information Structure", which for the WPC11 includes: Version = 5.0, Manuf = [Instant Wireless ], card vers = [ Network PC CARD] Addit. info = [Version 01.02],[] This command can be given as soon as the "wi" driver is included in the kernel and the "pccardc pccardmem 0xd0000 " executed (that is, before the "pccard.conf" database is correct). =================== ==== Remarks ====== ================== The above only applies to 4.3 stable. Under freebsd-current the same basic procedure should work but the patches should not be needed. Helpful man pages: wi, wicontrol, pccardd, pccardc, pcard.conf. There appears to be some confusion in terminology between "ad-hoc", BSS, IBSS, and ESS modes. What appears to be a fairly widespread 3COM white paper, "What's New in Wireless LANs: The IEEE 802.11b Standard" (one copy at): http://www.pulsewan.com/data101/802_11_b_basics.htm defines ad-hoc mode as the same as IBSS ("Independent Basic Service Set"). In this mode an access point (AP, essentially a cell-controller) is not used; the wireless cards simply provide the equivalent of a local ethernet cable. In the 3COM doc a BSS is a "cell" controlled by an AP, and an ESS (extended SS) is a network of APs. I assumed the "wicontrol" BSS "port type" means an access point is to be used, and ad-hoc means no AP is used. I never did get the WPC11s to operate in BSS mode, that is, not in ad-hoc mode (but then, I did not have an AP). Ross Finlayson's experience at: http://www.live.com/wireless/unix-base-station.html (also without an AP) is presumably different because he was using Lucent Orinoco cards, perhaps with "updated" firmware? The WPC11 cards do not all appear the same. Some (presumably older) come with doc that says they work with 40-bit WEP encryption, others with doc that says they will work up to 128 bits. Both old and new cards seem to interoperate OK at 40-bits or with WEP off. I'm assuming some version of freebsd-current will eventually support PCI->PCMCIA bridges. Does freebsd-current already do this? I don't know if PC-104 (an ISA derivative) will work with ISA->PCMCIA bridges, although I assume something like these must exist. PicoBSD folks probably have experience with WPC11 cards and PC-104? The same WPC11 card, in the same machine, will not necessarily reuse the same MAC address across boots (presumably it uses an address that does not appear to be in use in the "cell"?) Rebooting a system may thus result in console/log messages on other systems of the form: "arp: moved from to on wi0" This does not appear to cause any problems. It appears to be the last byte of the MAC address that changes... but? I don't know if it's possible to use antennas with the WPC11 cards. People seem to only use antennas with true access point units, but somewhere some doc suggested that the access points are actually just using the same cards (with different firmware or settings?), so maybe there is a way to connect an antenna? Although 802.11b seems short-range using just the cards, people seem to achieve 802.11b links the better part of 10 miles using directional antennas (amplified? higher power?). - bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 12 17:17:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from hub.lovett.com (hub.lovett.com [216.60.121.161]) by hub.freebsd.org (Postfix) with ESMTP id 451F637B423 for ; Sat, 12 May 2001 17:17:19 -0700 (PDT) (envelope-from ade@lovett.com) Received: from ade by hub.lovett.com with local (Exim 3.22 #1) id 14yjZW-000NmR-00 for freebsd-net@FreeBSD.org; Sat, 12 May 2001 19:17:18 -0500 Date: Sat, 12 May 2001 19:17:18 -0500 From: Ade Lovett To: freebsd-net@FreeBSD.org Subject: Problems with ng_one2many Message-ID: <20010512191718.D90400@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have a box with 5 old-style netgear (de) interfaces on it, one talking to the outside world, and 4 sending large quantities of data to a number of other machines on the same switch. At the moment, we're setting up a bunch of separate network addresses, one per card (de1-de4) and then use the application to bind to particular addresses when sending data to one machine. Now, what I'd like to do is to aggregate de1-de4 into a single virtual interface, with a simple round-robin setup, giving me a 400Mbit pipe to play with, and making the internal network setup a great deal easier. I first looked at Bill Paul's fec netgraph module, but this lacks a pure round-robin approach, and odd things happen when the data load is greater than a single interface. I also note that there are a number of places in the code where it's suggested that the code is not MP-safe. After a bit more investigation, I came across ng_one2many which appears to do exactly what I want, only it just refuses to work for me. The machine is running 4.3-STABLE as of a day or so, all appropriate modules have been loaded, viz: matrix 86# kldstat Id Refs Address Size Name 1 5 0xc0100000 1b143c kernel 2 1 0xc71d5000 c3000 vinum.ko 3 1 0xc72f8000 3000 ng_one2many.ko 4 2 0xc72fc000 8000 netgraph.ko 5 1 0xc7307000 3000 ng_socket.ko Yet when I try to perform the first part of the setup as documented in the manpage, I get the following: matrix 131# /usr/sbin/ngctl mkpeer de1: one2many upper one ngctl: send msg: No such file or directory matrix 132# and obviously, everything else fails to do anything. Any suggestions? I guess I could take the fec code, and rip it to bits with a pure round-robin approach, but that seems like reinventing the wheel given the existence of ng_one2many. What am I missing here? Regards, -aDe -- Ade Lovett, Austin, TX. ade@FreeBSD.org FreeBSD: The Power to Serve http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message