From owner-freebsd-net Sun Mar 11 10:23:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from samar.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 9DECD37B718 for ; Sun, 11 Mar 2001 10:23:35 -0800 (PST) (envelope-from sseth@sasken.com) Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id XAA08520; Sun, 11 Mar 2001 23:53:17 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Sun, 11 Mar 2001 23:53:16 +0000 (IST) Received: from localhost (sseth@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id XAA01429; Sun, 11 Mar 2001 23:53:20 +0530 (IST) Date: Sun, 11 Mar 2001 23:53:20 +0530 (IST) From: Satyajeet Seth To: Cc: Subject: Ping Problem 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 Hi I have configured pseudo ethernet interfaces with the following requirements: 1. There is a ethernet interface fxp0 having MAC address MAC0. It also receives packets with destination MAC address MAC1 and MAC2. 2. The packets with destination MAC address MAC1 are sent to pseudo interface 1, nge0 and packets with destination MAC address MAC2 are sent to pseudo interface 2, nge1. This has been done using netgraph as follows: fxp0: <--> bpf <--> bpf <--> interface0 \ \ \ ------>interface1 \ \------------>interface2 I have used ng_eiface nodes impemented by Vitaly (available at http://www.riss-telecom.ru/~vitaly/) for interface1/2. I have set fxp0 in promiscuous mode. Could you suggest why I am unable to ping the pseudo ethernet interface IP addresses from any of the LAN machines? Is it because fxp0 is capable of sending packets only with its own MAC address and not MAC addresses of nge0 and nge1? My ifconfig settings and routing table entries are given below. pcs130# ifconfig -a fxp0: flags=8843 mtu 1500 inet 10.0.36.130 netmask 0xfffff000 broadcast 10.0.47.255 inet6 fe80::2d0:b7ff:febd:711%fxp0 prefixlen 64 scopeid 0x1 ether 00:d0:b7:bd:07:11 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UT P 10baseT/UTP lp0: flags=8810 mtu 1500 sl0: flags=c010 mtu 552 ppp0: flags=8010 mtu 1500 lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 gif0: flags=8010 mtu 1280 gif1: flags=8010 mtu 1280 gif2: flags=8010 mtu 1280 gif3: flags=8010 mtu 1280 faith0: flags=8000 mtu 1500 nge0: flags=8843 mtu 1500 inet 10.0.137.157 netmask 0xffffffff broadcast 10.0.137.157 inet6 fe80::211:22ff:fe33:4455%nge0 prefixlen 64 scopeid 0xb ether 00:11:22:33:44:55 nge1: flags=8843 mtu 1500 inet 10.0.198.158 netmask 0xffffffff broadcast 10.0.198.158 inet6 fe80::2d0:b7ff:febd:711%nge1 prefixlen 64 scopeid 0xc ether 11:22:33:44:55:66 pcs130# netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 10.0.32.1 UGSc 0 0 fxp0 10.0.32/20 link#1 UC 0 0 fxp0 => 10.0.32.1 link#1 UHLW 1 0 fxp0 => 10.0.36.130 0:d0:b7:bd:7:11 UHLW 0 40 lo0 10.0.137.157/32 link#11 UC 0 0 nge0 => 10.0.198.158/32 link#12 UC 0 0 nge1 => 127.0.0.1 127.0.0.1 UH 0 4 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%fxp0/64 link#1 UC fxp0 fe80::%lo0/64 fe80::1%lo0 Uc lo0 fe80::%nge0/64 link#11 UC nge0 fe80::%nge1/64 link#12 UC nge1 ff01::/32 ::1 U lo0 ff02::%fxp0/32 link#1 UC fxp0 ff02::%lo0/32 fe80::1%lo0 UC lo0 ff02::%nge0/32 link#11 UC nge0 ff02::%nge1/32 link#12 UC nge1 Thanks Satya To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 11 13:15: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131]) by hub.freebsd.org (Postfix) with ESMTP id 2C35937B71A for ; Sun, 11 Mar 2001 13:15:03 -0800 (PST) (envelope-from drwilco@drwilco.nl) Received: from ceres.drwilco.nl (10dyn212.dh.casema.net [212.64.31.212]) by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA00805; Sun, 11 Mar 2001 22:14:49 +0100 (CET) Message-Id: <4.3.2.7.0.20010311214608.00b351f0@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 11 Mar 2001 21:47:50 +0100 To: Satyajeet Seth From: "Rogier R. Mulhuijzen" Subject: Re: Ping Problem Cc: freebsd-net@FreeBSD.ORG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I have used ng_eiface nodes impemented by Vitaly >(available at http://www.riss-telecom.ru/~vitaly/) for interface1/2. I >have set fxp0 in promiscuous mode. Have you tried 'setautosrc 0' on the fxp0: node? DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 11 16:51:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 6444C37B718 for ; Sun, 11 Mar 2001 16:51:08 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 17132 invoked by uid 666); 12 Mar 2001 00:52:09 -0000 Received: from i003-048.nv.iinet.net.au (HELO elischer.org) (203.59.3.48) by mail.m.iinet.net.au with SMTP; 12 Mar 2001 00:52:09 -0000 Message-ID: <3AAC1D58.221D06F2@elischer.org> Date: Sun, 11 Mar 2001 16:50:33 -0800 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: Satyajeet Seth Cc: net@freebsd.org, gbnaidu@sasken.com Subject: Re: Ping Problem References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satyajeet Seth wrote: > > Hi > > I have configured pseudo ethernet interfaces with the following > requirements: > 1. There is a ethernet interface fxp0 having MAC address MAC0. It also > receives packets with destination MAC address MAC1 and MAC2. > 2. The packets with destination MAC address MAC1 are sent to pseudo > interface 1, nge0 and packets with destination MAC address MAC2 are sent > to pseudo interface 2, nge1. > > This has been done using netgraph as follows: > fxp0: <--> bpf <--> bpf <--> interface0 > \ \ > \ ------>interface1 > \ > \------------>interface2 > > I have used ng_eiface nodes impemented by Vitaly > (available at http://www.riss-telecom.ru/~vitaly/) for interface1/2. I What revision of FreeBSD? eiface is now in -current. (but not built by default) > have set fxp0 in promiscuous mode. > > Could you suggest why I am unable to ping the pseudo ethernet interface > IP addresses from any of the LAN machines? > > Is it because fxp0 is capable of sending packets only with its own MAC address and not MAC > addresses of nge0 and nge1? It's not impossible, but then bridging should fail to work too I would think. hmm maybe not.. Does another machine see any packets on the wire at all? If you insert a 'tee' between the bpf and the fxp do you see outgoing packets? > > My ifconfig settings and routing table entries are given below. > > pcs130# ifconfig -a > fxp0: flags=8843 mtu 1500 > inet 10.0.36.130 netmask 0xfffff000 broadcast 10.0.47.255 > inet6 fe80::2d0:b7ff:febd:711%fxp0 prefixlen 64 scopeid 0x1 > ether 00:d0:b7:bd:07:11 > media: autoselect (100baseTX ) status: active > supported media: autoselect 100baseTX 100baseTX 10baseT/UT > P 10baseT/UTP > lp0: flags=8810 mtu 1500 > sl0: flags=c010 mtu 552 > ppp0: flags=8010 mtu 1500 > lo0: flags=8049 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > gif0: flags=8010 mtu 1280 > gif1: flags=8010 mtu 1280 > gif2: flags=8010 mtu 1280 > gif3: flags=8010 mtu 1280 > faith0: flags=8000 mtu 1500 > nge0: flags=8843 mtu 1500 > inet 10.0.137.157 netmask 0xffffffff broadcast 10.0.137.157 > inet6 fe80::211:22ff:fe33:4455%nge0 prefixlen 64 scopeid 0xb > ether 00:11:22:33:44:55 > nge1: flags=8843 mtu 1500 > inet 10.0.198.158 netmask 0xffffffff broadcast 10.0.198.158 > inet6 fe80::2d0:b7ff:febd:711%nge1 prefixlen 64 scopeid 0xc > ether 11:22:33:44:55:66 > pcs130# netstat -rn > Routing tables > Internet: > Destination Gateway Flags Netif Expire > default 10.0.32.1 UGSc 0 0 fxp0 > 10.0.32/20 link#1 UC 0 0 fxp0 => > 10.0.32.1 link#1 UHLW 1 0 fxp0 => > 10.0.36.130 0:d0:b7:bd:7:11 UHLW 0 40 lo0 > 10.0.137.157/32 link#11 UC 0 0 nge0 => > 10.0.198.158/32 link#12 UC 0 0 nge1 => > 127.0.0.1 127.0.0.1 UH 0 4 lo0 > Internet6: > Destination Gateway Flags Netif > Expire > ::1 ::1 UH lo0 > fe80::%fxp0/64 link#1 UC fxp0 > fe80::%lo0/64 fe80::1%lo0 Uc lo0 > fe80::%nge0/64 link#11 UC nge0 > fe80::%nge1/64 link#12 UC nge1 > ff01::/32 ::1 U lo0 > ff02::%fxp0/32 link#1 UC fxp0 > ff02::%lo0/32 fe80::1%lo0 UC lo0 > ff02::%nge0/32 link#11 UC nge0 > ff02::%nge1/32 link#12 UC nge1 > > Thanks > Satya > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ 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 Sun Mar 11 19:47:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from samar.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 8205237B718 for ; Sun, 11 Mar 2001 19:46:59 -0800 (PST) (envelope-from sseth@sasken.com) Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id JAA15792; Mon, 12 Mar 2001 09:16:38 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Mon, 12 Mar 2001 09:16:37 +0000 (IST) Received: from localhost (sseth@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id JAA02257; Mon, 12 Mar 2001 09:16:43 +0530 (IST) Date: Mon, 12 Mar 2001 09:16:43 +0530 (IST) From: Satyajeet Seth To: Julian Elischer Cc: , Subject: Re: Ping Problem In-Reply-To: <3AAC1D58.221D06F2@elischer.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 Hi Please see my comments below. > > I have configured pseudo ethernet interfaces with the following > > requirements: > > 1. There is a ethernet interface fxp0 having MAC address MAC0. It also > > receives packets with destination MAC address MAC1 and MAC2. > > 2. The packets with destination MAC address MAC1 are sent to pseudo > > interface 1, nge0 and packets with destination MAC address MAC2 are sent > > to pseudo interface 2, nge1. > > > > This has been done using netgraph as follows: > > fxp0: <--> bpf <--> bpf <--> interface0 > > \ \ > > \ ------>interface1 > > \ > > \------------>interface2 > > > > I have used ng_eiface nodes impemented by Vitaly > > (available at http://www.riss-telecom.ru/~vitaly/) for interface1/2. I > > What revision of FreeBSD? eiface is now in -current. (but not built by default) > > have set fxp0 in promiscuous mode. > > > > Could you suggest why I am unable to ping the pseudo ethernet interface > > IP addresses from any of the LAN machines? > > > > Is it because fxp0 is capable of sending packets only with its own MAC address and not MAC > > addresses of nge0 and nge1? > > It's not impossible, but then bridging should fail to work too I would > think. hmm maybe not.. Does another machine see any packets on the wire > at all? If you insert a 'tee' between the bpf and the fxp do you see > outgoing packets? I am using FreeBSD 4.1. I followed Roger's suggestion about "autosrc 0" message. But "autosrc" message is not available in ng_ether. I have tried commenting bcopy((IFP2AC(priv->ifp))->ac_enaddr, eh->ether_shost, 6); in ng_ether_rcv_lower in ng_ether.c with the effect that fxp0 is able to send packets with pseudo ethernet interface MAC address. I have tried the following setup for pinging from nge0 to some machine on LAN. on pcs130 (Machine with pseudo ethernet interfaces, see output of "ifconfig -a" below) ============================== 1. #route change -host 10.0.36.134 -ifp nge0 Now arp starts to print messages like: arp: 'IP addr' is on fxp0 but got response from 'MAC address' on nge0. 2. #ping 10.0.36.134 This does not work. on pcs134(some machine on lan) ============================== Using tee's I found that 10.0.36.134 receives ethernet frames with src MAC address of nge0 and dest MAC address of 10.0.36.134. pcs134 response frames are sent to MAC address of default router 10.0.32.1. But pcs130 does not receive these frames. Thanks Satya > > My ifconfig settings and routing table entries are given below. > > > > pcs130# ifconfig -a > > fxp0: flags=8843 mtu 1500 > > inet 10.0.36.130 netmask 0xfffff000 broadcast 10.0.47.255 > > inet6 fe80::2d0:b7ff:febd:711%fxp0 prefixlen 64 scopeid 0x1 > > ether 00:d0:b7:bd:07:11 > > media: autoselect (100baseTX ) status: active > > supported media: autoselect 100baseTX 100baseTX 10baseT/UT > > P 10baseT/UTP > > lp0: flags=8810 mtu 1500 > > sl0: flags=c010 mtu 552 > > ppp0: flags=8010 mtu 1500 > > lo0: flags=8049 mtu 16384 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > > inet6 ::1 prefixlen 128 > > inet 127.0.0.1 netmask 0xff000000 > > gif0: flags=8010 mtu 1280 > > gif1: flags=8010 mtu 1280 > > gif2: flags=8010 mtu 1280 > > gif3: flags=8010 mtu 1280 > > faith0: flags=8000 mtu 1500 > > nge0: flags=8843 mtu 1500 > > inet 10.0.137.157 netmask 0xffffffff broadcast 10.0.137.157 > > inet6 fe80::211:22ff:fe33:4455%nge0 prefixlen 64 scopeid 0xb > > ether 00:11:22:33:44:55 > > nge1: flags=8843 mtu 1500 > > inet 10.0.198.158 netmask 0xffffffff broadcast 10.0.198.158 > > inet6 fe80::2d0:b7ff:febd:711%nge1 prefixlen 64 scopeid 0xc > > ether 11:22:33:44:55:66 > > pcs130# netstat -rn > > Routing tables > > Internet: > > Destination Gateway Flags Netif Expire > > default 10.0.32.1 UGSc 0 0 fxp0 > > 10.0.32/20 link#1 UC 0 0 fxp0 => > > 10.0.32.1 link#1 UHLW 1 0 fxp0 => > > 10.0.36.130 0:d0:b7:bd:7:11 UHLW 0 40 lo0 > > 10.0.137.157/32 link#11 UC 0 0 nge0 => > > 10.0.198.158/32 link#12 UC 0 0 nge1 => > > 127.0.0.1 127.0.0.1 UH 0 4 lo0 > > Internet6: > > Destination Gateway Flags Netif > > Expire > > ::1 ::1 UH lo0 > > fe80::%fxp0/64 link#1 UC fxp0 > > fe80::%lo0/64 fe80::1%lo0 Uc lo0 > > fe80::%nge0/64 link#11 UC nge0 > > fe80::%nge1/64 link#12 UC nge1 > > ff01::/32 ::1 U lo0 > > ff02::%fxp0/32 link#1 UC fxp0 > > ff02::%lo0/32 fe80::1%lo0 UC lo0 > > ff02::%nge0/32 link#11 UC nge0 > > ff02::%nge1/32 link#12 UC nge1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 11 23:52:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from tinny.eis.net.au (tinny.eis.net.au [203.12.171.1]) by hub.freebsd.org (Postfix) with ESMTP id 09DF137B718 for ; Sun, 11 Mar 2001 23:52:35 -0800 (PST) (envelope-from ernie@tinny.eis.net.au) Received: (from ernie@localhost) by tinny.eis.net.au (8.8.8/8.8.3) id RAA27317 for freebsd-net@freebsd.org; Mon, 12 Mar 2001 17:52:33 +1000 (EST) From: Ernie Elu Message-Id: <200103120752.RAA27317@tinny.eis.net.au> Subject: Intel 82562 chip breaks fxp driver? To: freebsd-net@freebsd.org Date: Mon, 12 Mar 2001 17:52:33 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] 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 just built up a 4.2-RELEASE system with an brand new Intel D815EEA motherboard that has onboard ethernet using the 82562 chipset. The card stops every few minutes with a /kernel: fxp0: SCB timeout error message. I have found reference to others experiencing the same problem with the 82562 chipset on FreeBSD, linux, and OpenBSD mail lists with no solutions going back as far as December. Has anyone found a workaround to this problem? - Ernie. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 5:20:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by hub.freebsd.org (Postfix) with ESMTP id 5784837B71A for ; Mon, 12 Mar 2001 05:20:25 -0800 (PST) (envelope-from mike@sentex.net) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.11.1/8.11.1) with SMTP id f2CDKED12829; Mon, 12 Mar 2001 08:20:14 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: ernie@eis.net.au (Ernie Elu) Cc: freebsd-net@FreeBSD.ORG Subject: Re: Intel 82562 chip breaks fxp driver? Date: Mon, 12 Mar 2001 08:20:14 -0500 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I remember a thread a few weeks ago about this. I thought it had to do = with flow control from certain switches. There was even a patch. I might not = be remembering it properly, but have a look through the archives for fxp = flow control and you will probably find it. Like I said, I am just going from memory and I could be wrong. ---Mike On 12 Mar 2001 02:52:46 -0500, in sentex.lists.freebsd.net you wrote: >I have just built up a 4.2-RELEASE system with an brand new Intel = D815EEA=20 >motherboard that has onboard ethernet using the 82562 chipset. > >The card stops every few minutes with a /kernel: fxp0: SCB timeout error >message. > >I have found reference to others experiencing the same problem with the >82562 chipset on FreeBSD, linux, and OpenBSD mail lists with no = solutions=20 >going back as far as December. > >Has anyone found a workaround to this problem? > >- Ernie. > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 5:21:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id ED56637B719; Mon, 12 Mar 2001 05:21:07 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f2CDDJA80981; Mon, 12 Mar 2001 15:13:19 +0200 (EET) (envelope-from ru) Date: Mon, 12 Mar 2001 15:13:19 +0200 From: Ruslan Ermilov To: "Louis A. Mamakos" Cc: Jonathan Lemon , Jonathan Lemon , net@FreeBSD.ORG Subject: Re: Delayed checksums commit broke UDP checksum calculation Message-ID: <20010312151319.A75899@sunbay.com> Mail-Followup-To: "Louis A. Mamakos" , Jonathan Lemon , Jonathan Lemon , net@FreeBSD.ORG References: <20001116120936.A45755@sunbay.com> <20001116091954.A19895@prism.flugsvamp.com> <20010307123156.A19829@sunbay.com> <200103071440.f27EeYa99809@whizzo.transsys.com> <20010307164822.E97252@sunbay.com> <200103071458.f27EwWa99960@whizzo.transsys.com> <20010307171956.B36537@sunbay.com> <200103071547.f27Fl6a00528@whizzo.transsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103071547.f27Fl6a00528@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Mar 07, 2001 at 10:47:06AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Mar 07, 2001 at 10:47:06AM -0500, Louis A. Mamakos wrote: > > > To be CONSERVATIVE, the implementation MUST NOT transmit all-zero > > computed TCP checksum as all-ones; while they are certainly equivalent > > in one's complement arithmetics, but RFC 793 does not grant us to do > > this conversion (as opposed to RFC 768), and there may an implementation > > exist that computes checksums from scratch using the "shift-and-add-carry" > > algorithm to compute the one's complement sum on a non-one's-complement > > hardware, and compare the result with what stored in the checksum field. > > In this case, +0 and -0 will differ. > > I disagree on your conservative interpretation of the spec. Here's > the text from RFC 793, on TCP, and what it has to say about the > checksum computation: > > Checksum: 16 bits > > The checksum field is the 16 bit one's complement of the one's > complement sum of all 16 bit words in the header and text. If a > segment contains an odd number of header and text octets to be > checksummed, the last octet is padded on the right with zeros to > form a 16 bit word for checksum purposes. The pad is not > transmitted as part of the segment. While computing the checksum, > the checksum field itself is replaced with zeros. > > The checksum also covers a 96 bit pseudo header conceptually > prefixed to the TCP header. This pseudo header contains the Source > Address, the Destination Address, the Protocol, and TCP length. > This gives the TCP protection against misrouted segments. This > information is carried in the Internet Protocol and is transferred > across the TCP/Network interface in the arguments or results of > calls by the TCP on the IP. > > +--------+--------+--------+--------+ > | Source Address | > +--------+--------+--------+--------+ > | Destination Address | > +--------+--------+--------+--------+ > | zero | PTCL | TCP Length | > +--------+--------+--------+--------+ > > The TCP Length is the TCP header length plus the data length in > octets (this is not an explicitly transmitted quantity, but is > computed), and it does not count the 12 octets of the pseudo > header. > > For the sake of illustration, assume that you're computing a checksum > over segment which contains all zeros. This will produce a sum with > a value of zero. When you take the 16 bit one's complement of this > value, you end up with 0xFFFF which is supposed to be put into the > checksum field. > Not possible. For IP, UDP, and TCP checksums, there is always a non-zero member in the sum (protocol). > For other segments which you're computing the checksum over, a > properly implemented 1's complement arithemetic sum will produce > a normalized +0 (0x0000) rather than a negative zero (0xFFFF). So > when you get to the step of taking the 1's complement (the logical > NOT operation), you'll never start with 0xFFFF to produce a 0x0000 > result. Of course the problem is that all these modern systems > apparently don't have high-fidelity emulation of 1's complement > add operations and are computing a -0 value along the way. > Hmm, from where did you take this? You seem to be constantly using the term "normalized", where the -0 in one's complement representation is replaced by +0, while the common definition of the one's complement sum sounds like this: : Addition of signed numbers in one's complement is performed using : binary addition with end-around carry. If there is a carry out of : the most significant bit of the sum, this bit must be added to the : least significant bit of the sum. References: http://www.cs.uaf.edu/~cs301/notes/Chapter4/node4.html Mano, M.M. 1993. Computer System Architecture, Third Edition ISBN: 0-13-175563-3. And the IP checksum is defined as follows: : The checksum field is the 16 bit one's complement of the one's : complement sum of all 16 bit words in the header. For purposes of : computing the checksum, the value of the checksum field is zero. From these definitions it follows that one's complement sum can never be all zeroes except when all items are zeroes, which is not the case for IP, UDP, and TCP. Hereby, the checksum can never be 0xFFFF except for UDP, which reserves 0 for "no checksum", and thus the computed checksum value of 0 is stored as 0xFFFF. > > To be LIBERAL, the implementation SHOULD verify checksums by computing > > the checksum using the value stored in the checksum field, and comparing > > the result with zero, as opposed to computing the checksum from scratch > > and comparing with the value stored in the checksum field. > > But computing a checksum with either 0xffff or 0x0000 WILL produce > the same result if you are implementing the Internet 1's complement > checksum algorithm correctly. > Let's assume (theoretically) that we are computing internet checksum for "all zeroes" fragment. Then one's complement sum for it will be 0x0000. The checksum, which is the one's complement of the latter, is 0xFFFF. If +0 and -0 were equivalent, then we could transmit 0x0000 as the checksum. The receiver then verifies the checksum: it computes one's complement sum which is all zeroes, and one's complement of the latter, which is 0xFFFF. But the receiver expects zero. > I can assure you that the stack I wrote in 1981, which ran on a > 1's complement-based CPU sent TCP checksums with value 0xFFFF in > the packet header, and it works Just Fine. I don't see how > reading that section of the TCP protocol spec would lead you to > believe otherwise. > I think then that your implementation is wrong WRT this. Yes, +0 and -0 are equivalent for the purposes of arithmetic operations in one's complement arithmetic, and +0 == -0 in one's complement arithmetics, but they are represented differently, and what matters here is the REPRESENTATION. If the computed checksum is +0, noone grants you (except UDP) to store -0 in place of it. If the sender follows this closely, the "normalization" is not needed. I.e., the receiver operating on a two's complement ALU can safely assume that it will receive all-ones after performing a two's complement sum over payload. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 6:10: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 16F2537B718 for ; Mon, 12 Mar 2001 06:09:57 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 28795 invoked by uid 666); 12 Mar 2001 14:10:57 -0000 Received: from i003-015.nv.iinet.net.au (HELO elischer.org) (203.59.3.15) by mail.m.iinet.net.au with SMTP; 12 Mar 2001 14:10:57 -0000 Message-ID: <3AACD88F.71BCAFEC@elischer.org> Date: Mon, 12 Mar 2001 06:09:19 -0800 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: Satyajeet Seth Cc: net@freebsd.org, gbnaidu@sasken.com Subject: Re: Ping Problem References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satyajeet Seth wrote: > > Hi > > Please see my comments below. > > > I am using FreeBSD 4.1. I followed Roger's suggestion about "autosrc 0" > message. But "autosrc" message is not available in ng_ether. > I have tried commenting > bcopy((IFP2AC(priv->ifp))->ac_enaddr, eh->ether_shost, > 6); > in ng_ether_rcv_lower in ng_ether.c with the effect that fxp0 is able to > send packets with pseudo ethernet interface MAC address. please upgrade to at least 4.1.1 which has the autosrc command. preferably to 4.2. If you need to maybe look at upgrading just netgraph and possibly if_ethersubr.c bit I would be happier to see a move up for the system as a whole. An upgrade within the '4' family should be pretty painless. > > I have tried the following setup for pinging from nge0 to some machine on > LAN. > > on pcs130 (Machine with pseudo ethernet interfaces, see output of > "ifconfig -a" below) > ============================== > 1. #route change -host 10.0.36.134 -ifp nge0 > Now arp starts to print messages like: > arp: 'IP addr' is on fxp0 but got response from 'MAC address' on nge0. broadcast frames received have to be sent to the interface that is on that net. To do this you would need to read arp packets to decide which network to send it. (sinc ethey are the usual users of broadcast messages. At the moment you MAY MAY have success if you enable some bridging as that disables some of those checks. > > 2. #ping 10.0.36.134 > This does not work. probably the arp packets are never getting back to the right interface You need to do more packet tracing. does the packet hit the wire? does the target respond? is there a arp packet before it? does the dest respond tothe arp? does the response appear in the arp table? does the destination in turn send an arp request before responding to the ping? does the arp response (broadcast) get assigned to an interface? does it get answered? from which interface? does the response hit the wire? It was never envisionned to multiplex multiple ether networks over a single network without adding a layer e.g. VLAN. This is what VLAN is for. The problems with broadcast packets is one of the problems. > > on pcs134(some machine on lan) > ============================== > Using tee's I found that 10.0.36.134 receives ethernet frames with src > MAC address of nge0 and dest MAC address of 10.0.36.134. > pcs134 response frames are sent to MAC address of default router > 10.0.32.1. But pcs130 does not receive these frames. why does the PC send to the default router? netmask problems I think mask == ffffffff is probably a problem. > > Thanks > Satya > > > > My ifconfig settings and routing table entries are given below. > > > > > > pcs130# ifconfig -a > > > fxp0: flags=8843 mtu 1500 > > > inet 10.0.36.130 netmask 0xfffff000 broadcast 10.0.47.255 > > > inet6 fe80::2d0:b7ff:febd:711%fxp0 prefixlen 64 scopeid 0x1 > > > ether 00:d0:b7:bd:07:11 > UC nge1 -- __--_|\ 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 Mar 12 10: 9: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from heidelberg.dotnet.com (heidelberg.dotnet.com [216.127.192.12]) by hub.freebsd.org (Postfix) with ESMTP id 0BC8E37B71C; Mon, 12 Mar 2001 10:08:44 -0800 (PST) (envelope-from parmor@dotnet.com) Received: from blah2 (ip45-padsl.dotnet.com [216.127.198.45]) by heidelberg.dotnet.com (8.9.3/8.9.3) with SMTP id MAA08684; Mon, 12 Mar 2001 12:08:29 -0600 Message-ID: <021a01c0ab1f$c897c7a0$2dc67fd8@blah2> From: "Paul Armor" To: , Subject: PPPoE Date: Mon, 12 Mar 2001 12:10:52 -0600 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 Okay, I feel stupid... I've got a 4.2 Release box set up as a firewall with some clients behind it. I'm using my BSD box as PPPoE client. My problem is the "win clients can't get to certain web sites" issue, I've verified by sending large ping packet from outside and it gets lost between tun0 and internal interface. I've tried the tcpmssd.rc stuff, but have not been able to get it working properly (all packets hit the divert rule, but drop somewhere inside). Can anyone suggest anything? Here are various details... 4.2 release options NETGRAPH options NETGRAPH_ETHER options NETGRAPH_PPPOE options NETGRAPH_SOCKET In kernel myprofile: set device PPPoE:fxp0 set mru 1492 set mtu 1492 set authname XXXXXX set authkey XXXXXX set log Phase tun command set dial set login set ifaddr /net /net add default HISADDR In ppp.conf network_interfaces="auto" ifconfig_fxp0="up" ppp_enable="YES" ppp_mode="dedicated" ppp_nat="NO" ppp_profile="myprofile" ifconfig_fxp1="inet netmask " ifconfig_tun0="inet 0.0.0.0 netmask " Thanks in advance for ANY help!!! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 10:13:30 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 3848037B71E for ; Mon, 12 Mar 2001 10:13:24 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA61145; Mon, 12 Mar 2001 13:13:22 -0500 (EST) (envelope-from wollman) Date: Mon, 12 Mar 2001 13:13:22 -0500 (EST) From: Garrett Wollman Message-Id: <200103121813.NAA61145@khavrinen.lcs.mit.edu> To: net@FreeBSD.org Cc: freebsd-standards@bostonradio.org Subject: MAXHOSTNAMELEN redux Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My bug report against the current POSIX draft was accepted. For the record, here are the changes being made. (``The indicated line'' is referring to a line in the definition of gethostname() where the length of the buffer was previously defined to be 256, including the terminating null. The excluding-null semantics were chosen for parallel construction with {NAME_MAX} and similar constants. At the indicated line, for 255 substitute {HOST_NAME_MAX}. At XBD page 261 () before line 8966 insert: {HOST_NAME_MAX} Maximum length of a host name (not including the terminating null) as returned from the gethostname() function. Minimum acceptable value: {_POSIX_HOST_NAME_MAX} Before line 9183, insert: {_POSIX_HOST_NAME_MAX} Maximum length of a host name (not including the terminating null) as returned from the gethostname() function. Value: 255 At XBD page 424 () before line 14818 insert: _SC_HOST_NAME_MAX At XSH page 1982 (sysconf()) before line 45530 insert: {HOST_NAME_MAX} _SC_HOST_NAME_MAX I include the last two changes for completeness only; I do not believe that applications are likely to use the sysconf() interface for this purpose. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 12:22: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from courier.netrail.net (courier.netrail.net [205.215.10.53]) by hub.freebsd.org (Postfix) with ESMTP id 0B4CF37B71A for ; Mon, 12 Mar 2001 12:21:52 -0800 (PST) (envelope-from cschreiber@netrail.net) Received: from cschriaber (localhost.netrail.net [127.0.0.1]) by courier.netrail.net (Postfix) with SMTP id ECC4AF8 for ; Mon, 12 Mar 2001 15:21:50 -0500 (EST) Reply-To: From: "Christian S." To: Subject: Alcatel SpeedTouch USB DSL Modem and FreeBSD Compatibility? Date: Mon, 12 Mar 2001 15:18:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, I searched the FreeBSD mailing lists for this issue and turned up a few hits, but no solid answers, so I thought that I would pose the question here - I have an Alcatel SpeedTouch USB DSL modem at home, and wanted to hook it up to my FreeBSD box. Unfortunately, as I understand it, there is currently no driver support for this. However, I heard that the Linux version of the driver may be available soon. I've hit just about every search engine looking for this, but can't seem to find any more recent information than around November/December of last year. If anyone has any information on when this might be available, I would appreciate it, as right now my Win98 box is my current firewall for my FreeBSD box(!), which to me is pretty much sacrilege.. :/ Thanks in Advance! Christian "...we have only twice as many genes as a fruit fly, or roughly the same number as an ear of corn, about 30,000." Ergo, we are all corn. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBOq0vACkK9qTvGvteEQLflwCgzy+UYaQPFrPirnSW3E9Oe+7hs4YAn1HX yNB0pzX+osshaxIjjibRKQG4 =kFWj -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 17:27:27 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 4BDDA37B71A; Mon, 12 Mar 2001 17:27:18 -0800 (PST) (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.2/8.11.2) with ESMTP id f2D1SlC10715; Tue, 13 Mar 2001 01:28:47 GMT (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 f2D1TkB08101; Tue, 13 Mar 2001 01:29:46 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200103130129.f2D1TkB08101@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Paul Armor" Cc: freebsd-questions@FreeBSD.org, freebsd-net@FreeBSD.org, brian@Awfulhak.org Subject: Re: PPPoE In-Reply-To: Message from "Paul Armor" of "Mon, 12 Mar 2001 12:10:52 CST." <021a01c0ab1f$c897c7a0$2dc67fd8@blah2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Mar 2001 01:29:46 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you upgrade to the latest version of ppp(8) (you can get an archive from http://www.Awfulhak.org/ppp.html) the problem should go away. ppp(8) now fixes this stuff itself (look for mssfixup in the man page). > Okay, I feel stupid... > > I've got a 4.2 Release box set up as a firewall with some clients behind it. > I'm using my BSD box as PPPoE client. My problem is the "win clients can't > get to certain web sites" issue, I've verified by sending large ping packet > from outside and it gets lost between tun0 and internal interface. I've > tried the tcpmssd.rc stuff, but have not been able to get it working > properly (all packets hit the divert rule, but drop somewhere inside). Can > anyone suggest anything? > > Here are various details... > 4.2 release > > options NETGRAPH > options NETGRAPH_ETHER > options NETGRAPH_PPPOE > options NETGRAPH_SOCKET > In kernel > > myprofile: > set device PPPoE:fxp0 > set mru 1492 > set mtu 1492 > set authname XXXXXX > set authkey XXXXXX > set log Phase tun command > set dial > set login > set ifaddr /net /net > add default HISADDR > In ppp.conf > > network_interfaces="auto" > ifconfig_fxp0="up" > ppp_enable="YES" > ppp_mode="dedicated" > ppp_nat="NO" > ppp_profile="myprofile" > ifconfig_fxp1="inet netmask " > ifconfig_tun0="inet 0.0.0.0 netmask " > > > Thanks in advance for ANY help!!! -- 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 Mon Mar 12 17:47:40 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 2E1B037B718 for ; Mon, 12 Mar 2001 17:47:36 -0800 (PST) (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.2/8.11.2) with ESMTP id f2D1mRC10854; Tue, 13 Mar 2001 01:48:27 GMT (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 f2D1nQB08449; Tue, 13 Mar 2001 01:49:26 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200103130149.f2D1nQB08449@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Garrett Wollman Cc: net@FreeBSD.org, freebsd-standards@bostonradio.org, brian@Awfulhak.org Subject: Re: MAXHOSTNAMELEN redux In-Reply-To: Message from Garrett Wollman of "Mon, 12 Mar 2001 13:13:22 EST." <200103121813.NAA61145@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Mar 2001 01:49:26 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just some ramblings.... I find this a bit odd. I concluded recently that NAME_MAX was the odd-one-out WRT not having the NUL only because it is the maximum size of a *component* of a path. When the value is used, it makes sense to talk in terms of the without-NUL value. This change seems to make it even more likely that people will forget whether MUMBLE_MAX includes the NUL or not. If I were defining this sort of thing (hah!), I'd have *_LEN as definitions without NULs and *_SIZE as definitions with the NUL. *_MAX seems to be used more commonly as the maximum number of something (ARG_MAX, CHILD_MAX), so NAME_MAX seems to be a misspelt version of NAME_CHARS_MAX.... ditto for PATH_MAX and probably others. Ok, I'm done :-) > My bug report against the current POSIX draft was accepted. For the > record, here are the changes being made. (``The indicated line'' is > referring to a line in the definition of gethostname() where the > length of the buffer was previously defined to be 256, including the > terminating null. The excluding-null semantics were chosen for > parallel construction with {NAME_MAX} and similar constants. > > At the indicated line, for 255 substitute {HOST_NAME_MAX}. > At XBD page 261 () before line 8966 insert: > > {HOST_NAME_MAX} > Maximum length of a host name (not including the terminating > null) as returned from the gethostname() function. > Minimum acceptable value: {_POSIX_HOST_NAME_MAX} > > Before line 9183, insert: > > {_POSIX_HOST_NAME_MAX} > Maximum length of a host name (not including the terminating > null) as returned from the gethostname() function. > Value: 255 > > At XBD page 424 () before line 14818 insert: > > _SC_HOST_NAME_MAX > > At XSH page 1982 (sysconf()) before line 45530 insert: > > {HOST_NAME_MAX} _SC_HOST_NAME_MAX > > I include the last two changes for completeness only; I do not > believe that applications are likely to use the sysconf() interface > for this purpose. > > -GAWollman -- 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 Mon Mar 12 18:11:21 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 9AEEE37B71A for ; Mon, 12 Mar 2001 18:11:17 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id VAA66732; Mon, 12 Mar 2001 21:10:15 -0500 (EST) (envelope-from wollman) Date: Mon, 12 Mar 2001 21:10:15 -0500 (EST) From: Garrett Wollman Message-Id: <200103130210.VAA66732@khavrinen.lcs.mit.edu> To: Brian Somers Cc: net@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: MAXHOSTNAMELEN redux In-Reply-To: <200103130149.f2D1nQB08449@hak.lan.Awfulhak.org> References: <200103121813.NAA61145@khavrinen.lcs.mit.edu> <200103130149.f2D1nQB08449@hak.lan.Awfulhak.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > This change seems to make it even more likely that people will forget > whether MUMBLE_MAX includes the NUL or not. I chose to conform to the definition of {NAME_MAX} because it was the one I was staring at when I wrote the aardvark. I could just as easily have used {LOGIN_NAME_MAX} or {PATH_MAX}. I think the common-sense interpretation when one speaks of the ``maximum length'' of some string is that it is the maximum value strlen() might return, and doesn't include metainformation. (Ghu help us when we get around to doing internationalized domain names!) There should probably be a limits(7) manual page which describes all of the system limits. > If I were defining this sort of thing (hah!), I'd have *_LEN as > definitions without NULs and *_SIZE as definitions with the NUL. foo_MAX was chosen because the namespace *_MIN and *_MAX were already reserved by ANSI C in the header file. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 18:39:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from chmod.ath.cx (CC2-1242.charter-stl.com [24.217.116.226]) by hub.freebsd.org (Postfix) with ESMTP id D3DCC37B718; Mon, 12 Mar 2001 18:39:21 -0800 (PST) (envelope-from ajh3@chmod.ath.cx) Received: by chmod.ath.cx (Postfix, from userid 1001) id 7DAF5A82A; Mon, 12 Mar 2001 20:38:56 -0600 (CST) Date: Mon, 12 Mar 2001 20:38:56 -0600 From: Andrew Hesford To: Paul Armor Cc: freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: Re: PPPoE Message-ID: <20010312203856.B20275@cec.wustl.edu> References: <021a01c0ab1f$c897c7a0$2dc67fd8@blah2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <021a01c0ab1f$c897c7a0$2dc67fd8@blah2>; from parmor@dotnet.com on Mon, Mar 12, 2001 at 12:10:52PM -0600 X-Loop: Andrew Hesford Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On a similar note, how stable is the PPPoE in RELENG_4? This would be useful to know if I ever decide to drop my cable for DSL. On Mon, Mar 12, 2001 at 12:10:52PM -0600, Paul Armor wrote: > Okay, I feel stupid... > > I've got a 4.2 Release box set up as a firewall with some clients behind it. > I'm using my BSD box as PPPoE client. My problem is the "win clients can't > get to certain web sites" issue, I've verified by sending large ping packet > from outside and it gets lost between tun0 and internal interface. I've > tried the tcpmssd.rc stuff, but have not been able to get it working > properly (all packets hit the divert rule, but drop somewhere inside). Can > anyone suggest anything? -- Andrew Hesford ajh3@chmod.ath.cx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 19:24:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by hub.freebsd.org (Postfix) with ESMTP id 6B4D837B718; Mon, 12 Mar 2001 19:24:48 -0800 (PST) (envelope-from mike@sentex.net) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.11.1/8.11.1) with SMTP id f2D3OeX84856; Mon, 12 Mar 2001 22:24:41 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: ajh3@chmod.ath.cx (Andrew Hesford) Cc: freebsd-net@freebsd.org, questions@freebsd.org Subject: Re: PPPoE Date: Mon, 12 Mar 2001 22:24:40 -0500 Message-ID: References: <021a01c0ab1f$c897c7a0$2dc67fd8@blah2> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12 Mar 2001 21:39:31 -0500, in sentex.lists.freebsd.net you wrote: >On a similar note, how stable is the PPPoE in RELENG_4? This would be >useful to know if I ever decide to drop my cable for DSL. Very. I am an admin at an ISP, and betweem the various PPPoE implementations on win32 (Enternet, RasPPPoE), standalone routers = (LinkSys, NexLan, D-Link, Netgear, Cisco, Netopia) and LINUX (RP), FreeBSD and then LINUX are the two most stable implementations. They are the only two I have seen that can reliably stay connected and reconnect no matter what = the termination reason. Generally, my box stays connected unless there is = some sort of layer one interruption, or the DSLAM reboots and I have have to re-synch. But it always comes back after that, right away on its own = which is more than I can say for the other implementations. ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 21: 5: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by hub.freebsd.org (Postfix) with ESMTP id AE02737B718; Mon, 12 Mar 2001 21:04:55 -0800 (PST) (envelope-from j.telford@sympatico.ca) Received: from johnny2k ([64.229.49.178]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010313050454.ZAUX2129.tomts5-srv.bellnexxia.net@johnny2k>; Tue, 13 Mar 2001 00:04:54 -0500 Message-ID: <001401c0ab7b$541df370$b231e540@johnny2k> From: "John Telford" To: "Andrew Hesford" , "Paul Armor" Cc: , References: <021a01c0ab1f$c897c7a0$2dc67fd8@blah2> <20010312203856.B20275@cec.wustl.edu> Subject: Re: PPPoE Date: Tue, 13 Mar 2001 00:06:13 -0500 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I set up a PPPoE firewall with Windows clients on the backside for an office 32 days ago (with help from the folks here and some other links, thanks) and so far it has only had 1 reconnect. Thats a lot better than our offices that use Cable connections. Since it is a remote office I also set it up to e-mail me the new ip # whenever it changes, for monitoring/support purposes. Regards, John. ----- Original Message ----- From: "Andrew Hesford" To: "Paul Armor" Cc: ; Sent: Monday, March 12, 2001 9:38 PM Subject: Re: PPPoE > On a similar note, how stable is the PPPoE in RELENG_4? This would be > useful to know if I ever decide to drop my cable for DSL. > > On Mon, Mar 12, 2001 at 12:10:52PM -0600, Paul Armor wrote: > > Okay, I feel stupid... > > > > I've got a 4.2 Release box set up as a firewall with some clients behind it. > > I'm using my BSD box as PPPoE client. My problem is the "win clients can't > > get to certain web sites" issue, I've verified by sending large ping packet > > from outside and it gets lost between tun0 and internal interface. I've > > tried the tcpmssd.rc stuff, but have not been able to get it working > > properly (all packets hit the divert rule, but drop somewhere inside). Can > > anyone suggest anything? > -- > Andrew Hesford > ajh3@chmod.ath.cx > > 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 Mar 12 21:38:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id EEAF537B719; Mon, 12 Mar 2001 21:38:23 -0800 (PST) (envelope-from bsddiy@21cn.com) Received: from William ([192.168.1.98]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id NAA22347; Tue, 13 Mar 2001 13:34:35 +0800 Date: Tue, 13 Mar 2001 13:44:58 +0800 From: David Xu X-Mailer: The Bat! (v1.48f) Personal Reply-To: David Xu Organization: Viasoft X-Priority: 3 (Normal) Message-ID: <13914214859.20010313134458@viasoft.com.cn> To: Julian Elischer Cc: Jonathan Lemon , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Subject: Re[2]: cvs commit: src/sys/netinet tcp_timer.c In-reply-To: <3AACF6E9.6730B7AE@elischer.org> References: <200103012211.f21MBEv96903@freefall.freebsd.org> <11619657876.20010312141256@viasoft.com.cn> <20010312081100.P78851@prism.flugsvamp.com> <3AACF6E9.6730B7AE@elischer.org> 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 Hello Julian, Tuesday, March 13, 2001, 12:18:49 AM, you wrote: JE> Jonathan Lemon wrote: >> >> On Mon, Mar 12, 2001 at 02:12:56PM +0800, David Xu wrote: >> > Hello Jonathan, >> > >> > Friday, March 02, 2001, 6:11:14 AM, you wrote: >> > >> > JL> jlemon 2001/03/01 14:11:14 PST >> > >> > JL> Modified files: (Branch: RELENG_4) >> > JL> sys/netinet tcp_timer.c >> > JL> Log: >> > JL> MFC: another component of TCP newreno I overlooked in last commit. >> > >> > JL> Revision Changes Path >> > JL> 1.34.2.4 +6 -1 src/sys/netinet/tcp_timer.c >> > >> > what is status of SACK implemention? >> >> I'm not sure that anyone is working on one at this time. When I >> investigated the issue around 1-2 years ago, I was shown some >> statisics indicating that less than 30% of the web actually used >> SACK, so I wasn't sufficiently motivated to do the work. JE> Msoft w98 and on use SAC >> -- >> Jonathan sigh, does it mean FreeBSD get behind in some TCP/IP features? I know Linux and OpenBSD support SACK, and possible NetBSD. -- David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 22: 1:35 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 4D92E37B718; Mon, 12 Mar 2001 22:01:30 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA37259; Mon, 12 Mar 2001 21:59:40 -0800 (PST) Date: Mon, 12 Mar 2001 21:59:39 -0800 (PST) From: Julian Elischer To: David Xu Cc: Jonathan Lemon , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Re[2]: cvs commit: src/sys/netinet tcp_timer.c In-Reply-To: <13914214859.20010313134458@viasoft.com.cn> 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 Tue, 13 Mar 2001, David Xu wrote: > Hello Julian, > > JE> Msoft w98 and on use SAC > > sigh, does it mean FreeBSD get behind in some TCP/IP features? > I know Linux and OpenBSD support SACK, and possible NetBSD. yes, three are several SACK implementations for FreeBSD but none has been adopted. My guess is that about 40-50% of all clients on teh internet are running SACK capable stacks now. As a server we really should support it. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 22:58:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.ruhr.de (in-ruhr4.ruhr.de [212.23.134.2]) by hub.freebsd.org (Postfix) with SMTP id F065637B718 for ; Mon, 12 Mar 2001 22:58:38 -0800 (PST) (envelope-from ue@nathan.ruhr.de) Received: (qmail 27786 invoked by uid 10); 13 Mar 2001 06:58:37 -0000 Received: (from ue@localhost) by nathan.ruhr.de (8.11.3/8.11.2) id f2D6mWi85824 for freebsd-net@freebsd.org; Tue, 13 Mar 2001 07:48:32 +0100 (CET) (envelope-from ue) Date: Tue, 13 Mar 2001 07:48:32 +0100 From: Udo Erdelhoff To: freebsd-net@freebsd.org Subject: Re: PPPoE Message-ID: <20010313074832.B83336@nathan.ruhr.de> Mail-Followup-To: freebsd-net@freebsd.org References: <021a01c0ab1f$c897c7a0$2dc67fd8@blah2> <20010312203856.B20275@cec.wustl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010312203856.B20275@cec.wustl.edu>; from ajh3@chmod.ath.cx on Mon, Mar 12, 2001 at 08:38:56PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Mar 12, 2001 at 08:38:56PM -0600, Andrew Hesford wrote: > On a similar note, how stable is the PPPoE in RELENG_4? This would be > useful to know if I ever decide to drop my cable for DSL. Rock stable. I've been using PPPoE since March 2k and haven't had any PPPoE-related problems that were caused by FreeBSD. -- Cocaine is nature's way of telling you you have too much money. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 12 23:14:53 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 9E48537B718; Mon, 12 Mar 2001 23:14:45 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2D7EWq08344; Mon, 12 Mar 2001 23:14:32 -0800 (PST) Date: Mon, 12 Mar 2001 23:14:32 -0800 From: Alfred Perlstein To: David Xu Cc: Julian Elischer , Jonathan Lemon , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Re[2]: cvs commit: src/sys/netinet tcp_timer.c Message-ID: <20010312231432.H29888@fw.wintelcom.net> References: <200103012211.f21MBEv96903@freefall.freebsd.org> <11619657876.20010312141256@viasoft.com.cn> <20010312081100.P78851@prism.flugsvamp.com> <3AACF6E9.6730B7AE@elischer.org> <13914214859.20010313134458@viasoft.com.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <13914214859.20010313134458@viasoft.com.cn>; from bsddiy@21cn.com on Tue, Mar 13, 2001 at 01:44:58PM +0800 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Xu [010312 21:39] wrote: > Hello Julian, > > Tuesday, March 13, 2001, 12:18:49 AM, you wrote: > > JE> Jonathan Lemon wrote: > >> > >> On Mon, Mar 12, 2001 at 02:12:56PM +0800, David Xu wrote: > >> > Hello Jonathan, > >> > > >> > Friday, March 02, 2001, 6:11:14 AM, you wrote: > >> > > >> > JL> jlemon 2001/03/01 14:11:14 PST > >> > > >> > JL> Modified files: (Branch: RELENG_4) > >> > JL> sys/netinet tcp_timer.c > >> > JL> Log: > >> > JL> MFC: another component of TCP newreno I overlooked in last commit. > >> > > >> > JL> Revision Changes Path > >> > JL> 1.34.2.4 +6 -1 src/sys/netinet/tcp_timer.c > >> > > >> > what is status of SACK implemention? > >> > >> I'm not sure that anyone is working on one at this time. When I > >> investigated the issue around 1-2 years ago, I was shown some > >> statisics indicating that less than 30% of the web actually used > >> SACK, so I wasn't sufficiently motivated to do the work. > > JE> Msoft w98 and on use SAC > >> -- > >> Jonathan > > sigh, does it mean FreeBSD get behind in some TCP/IP features? > I know Linux and OpenBSD support SACK, and possible NetBSD. We're terribly sorry we haven't been able to commit the code you sent in, can you please point out the PR you submitted to address this shortcoming? -- -Alfred Perlstein - [bright@wintelcom.net|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 Tue Mar 13 0: 1:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from online.tmx.com.au (online.tmx.com.au [192.150.129.1]) by hub.freebsd.org (Postfix) with ESMTP id 7D9B137B71B for ; Tue, 13 Mar 2001 00:00:43 -0800 (PST) (envelope-from mtaylor@bytecraft.com.au) Received: from melexc01.bytecraft.com.au ([203.9.250.249]) by online.tmx.com.au (8.9.3/8.8.8) with ESMTP id SAA18913 for Tue, 13 Mar 2001 18:53:59 +1100 (EST) Received: by MELEXC01 with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Mar 2001 14:18:13 +1100 Message-ID: <710709BB8B02D311942E00606744181054428D@MELEXC01> From: Murray Taylor To: "'freebsd-net@freebsd.org'" Subject: Frame Relay setup questions (and basis for tutorial?) Date: Tue, 13 Mar 2001 14:17:58 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This loooong email will hopefully allow the netgraph - network gurus to A: answer my remaining questions and B: grab this and make a tutorial 'worked example' (unless it is total blech of course) So to those who have already earned their stripes from one looking for his first (hopefully, not to painful) stripe..... RTFMs used - man netgraph, ng_frame_relay, ng_lmi, ng_iface, ng_rfc1490, ng_bridge - /usr/share/examples/netgraph/* - Daemonnews 200003 netgraph article by Archie Cobbs - previous freebsd-questions and -net mailings O'Reilly - DNS and BIND - Getting Connected - The internet at 56K and up Addison-Wesley - Practical Internetworking with TCP/IP and UNIX Other factoids about the networks - The melbourne net is Win 9x/NT centric and almost all addresses are served up by DHCP from the NT PDC - The FreeBSD boxen are being used for the frame relay/ webserving application only at present. - The FreeBSD boxen run Samba at the os level = 0 and other appropriate settings to avoid interaction with the Browse master election waffle of M$ land This is still theoretical, as I am still waiting for the copper connection ;-) ! But it is RSN !! -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o- The Questions: For the initial setup [1] Given the settings from Telstra for the Management protocol, do I need the netgraph ng_lmi module? For the WAN setup [1] Given that I understand that establishing the permanent virtual circuit (PVC) to the Sydney office will assign another DLCI number to us, is the netgraph extension I have made in start_if.ng1 (melbourne setup) correct? [2] Do I need to add a router daemon to the melbourne system now? More difficult questions (given DHCP nature of the network) [3] Do I need to fully populate the /etc/hosts table now? [4] Do I need to fully populate the DNS table in Spyder? Other questions (bonus points!) [1] if I need to bring out other xxx.yyy.zzz.0/26 addresses 'out-the-side' of Spyder for other 'net visible machines, how should it be done? There is'nt any lower / upper hooks on the ng_iface node to attach a ng_bridge. I assume that this would be the connections point as it is the 'effective ethernet port' that one normally hooks to, is it not? Murray Taylor Project Engineer Bytecraft P/L +61 3 9587 2555 +61 3 9587 1614 fax mtaylor@bytecraft.com.au -o-o-o-o-o-o-o-o-o-o-o-o-o--o-o-o-o-o-o-o-o-o-o-o-o The 2 setups to be examined w.r.t. the above questions Initial setup -- Internet Access from ByteMelb for website - select Management Protocol ITU-T (CCITT) Q933 Annex A no ANSI T1.617 Annex D yes (Telstra default) LMI (FRF Doc#001-208966) no - select physical interface X.21bis/V35 no X.21 yes G.704 no - Telstra assignments xxx.yyy.zzz.0/26 network DLCI 16 Internet link (Telstra 'Big Pond') - Hardware card WANic 405 with X21 interface uses sr(4) driver - kernel compiled with NETGRAPH - hardware setup ng0 ip fxp0 ip xxx.yyy.zzz.1 SPYDER 10.1.2.30 +----------+ | | +---+ |-+-+ +-| frame | N | X21 |s|n| |f| 100BaseT =======| T |========|r|g| |x|~~~~~~~~~~~~ relay | U | |0|0| |p| +---+ |-+-+ |0| | +-| | | | | | | | | +----------+ Netgraph setup for Internet access [ ](auto1023) -------+ [ lmi ](auto0) ---------+| [ ] || || [ sr0 ] [ ](dlci0) ---+| [ phys ](rawdata) --- (downstream)[ frame_relay ](dlci1023) -+ [ ] [ ](dlci16)--+ | +---------------------------------------------------------+ | | { ] [ ng0 ] +--- (downstream)[ rcf1490 ](inet) --- (inet)[ iface ] xxx.yyy.zzz.1 [ ] [ ] Desired Initial Routing default xxx.yyy.zzz.1 UGSc ng0 127.0.0.1 127.0.0.1 UH lo0 10.1.2.0 ff:ff:ff:ff:ff:ff UHLWb fxp0 10.1.2 link#1 UC fxp0 - - - - so the following is done in this sequence via rc.conf (written in the sequence that rc.network will process them) =============== network portions of rc.conf ========================== # # set up my hostname # hostname="spyder.bytecraft.au.com" # # network setup # network_interfaces="lo0 ng0 fxp0" # # (NB more needed in man pages re start_if.* files) # # start_if.ng0 file is run here automagically # ifconfig_lo0="inet 127.0.0.1" ifconfig_fxp0="inet 10.1.2.30 netmask 255.255.0.0" ifconfig_ng0="inet xxx.yyy.zzz.1 netmask 255.255.255.192" # # firewall # ipfw_enable="YES" ipfw_flags="/etc/firewall/rules" # # NAT setup here # natd_enable="YES" natd_interfaces="ng0" # # static routes # static_routes="ng0" route_ng0="-net 0.0.0.0 xxx.yyy.zzz.1" # # gateway enable # gateway_enable="YES" # # ----- end of netpass 1 # # named enable # named_enable="YES" named_flags="-u bind -g bind /etc/namedb/sandbox/named.conf" # # ----- end of netpass 2 # # sshd # sshd_enable="YES" # # ----- end of netpass 3 # # inetd flags # inetd_flags="" ============= end of network part of rc.conf ======================== the start_if.ng0 script ( basically a copy of the frame relay example file in /usr/share/examples/netgraph ) ================ start_if.ng0 ============================= #!/bin/sh # script to set up a frame relay link on the sr card. # The dlci used is selected below. The default is 16 # WANic 405 CARD=sr0 DLCI=16 # create a frame_relay type node and attach it to the sync port. ngctl mkpeer ${CARD}: frame_relay rawdata downstream # Attach the dlci output of the (de)multiplexor to a new # Link management protocol node. ngctl mkpeer ${CARD}:rawdata lmi dlci0 auto0 # Also attach dlci 1023, as it needs both to try autoconfiguring. # The Link management protocol is now alive and probing.. ngctl connect ${CARD}:rawdata ${CARD}:rawdata.dlci0 dlci1023 auto1023 # Attach the DLCI(channel) the Telco has assigned you to # a node to hadle whatever protocol encapsulation your peer # is using. In this case rfc1490 encapsulation. ngctl mkpeer ${CARD}:rawdata rfc1490 dlci${DLCI} downstream # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) # input of a netgraph "interface" node (ifconfig should show it as "ng0"). ngctl mkpeer ${CARD}:rawdata.dlci${DLCI} iface inet inet ================end of start_if.ng0 ========================== windoze machines that need internet access have their gateway set to 10.1.2.30 ** NOTE most internet access is inwards to apache webserver running on spyder ===================================================================== VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV ===================================================================== Second Setup Then when Sydney comes online as a WAN extension to the ByteMelb net Assumptions Private Virtual Circuit (PVC) defined as : DLCI 17 at bytemelb DLCI 16 at bytesyd MELBOURNE - hardware setup ng0 ip fxp0 ip xxx.yyy.zzz.1 SPYDER 10.1.2.30 ng1 ip +----------+ 10.1.2.250 | +-+ | | |n| | +---+ |-+g| +-| frame | N | X21 |s|0| |f| 100BaseT =======| T |========|r|-| |x|~~~~~~~~~~~~ relay | U | |0|n| |p| +---+ |-+g| |0| | |1| +-| | +-+ | | | | | | | +----------+ Netgraph redefined to this configuration [ ](auto1023) -------+ [ lmi ](auto0) ---------+| [ ] || || [ sr0 ] [ ](dlci0) ---+| [ phys ](rawdata) --- (downstream)[ frame_relay ](dlci1023) -+ [ ] [ ](dlci16) ---+ [ ](dlci17) --+| || +----------------------------------------------------------+| |+----------------------------------------------------------+ || || { ] [ ng0 ] |+--- (downstream)[ rcf1490 ](inet) --- (inet)[ iface ] 203.39.118.1 | [ ] [ ] | | [ ] [ ng1 ] +---- (downstream)[ rfc1490 ](inet) --- (inet)[ iface ] 10.1.2.250 [ ] [ ] Desired Initial Routing default xxx.yyy.zzz.1 UGSc ng0 127.0.0.1 127.0.0.1 UH lo0 10.1.7/24 10.1.2.250 UGS ng1 -- added WAN link 10.1.2.0 ff:ff:ff:ff:ff:ff UHLWb fxp0 10.1.2 link#1 UC fxp0 --- SYDNEY - hardware setup ng0 ip fxp0 ip 10.1.7.250 SYDGATE 10.1.7.1 +----------+ | | +---+ |-+-+ +-| frame | N | X21 |s|n| |f| 100BaseT =======| T |========|r|g| |x|~~~~~~~~~~~~ relay | U | |0|0| |p| +---+ |-+-+ |0| | +-| | | | | | | | | +----------+ Netgraph will be similar to original ByteMelb setup [ ](auto1023) -------+ [ lmi ](auto0) ---------+| [ ] || || [ sr0 ] [ ](dlci0) ---+| [ phys ](rawdata) --- (downstream)[ frame_relay ](dlci1023) -+ [ ] [ ](dlci16)--+ | +---------------------------------------------------------+ | | { ] [ ng0 ] +--- (downstream)[ rcf1490 ](inet) --- (inet)[ iface ] 10.1.7.250 [ ] [ ] Desired Initial Routing default 10.1.7.250 UGSc ng0 127.0.0.1 127.0.0.1 UH lo0 10.1.7.0 ff:ff:ff:ff:ff:ff UHLWb fxp0 10.1.7 link#1 UC fxp0 - - - - so the setups now are this (written in the sequence that rc.network will process them) =bytMelb==== WAN ===network portions of rc.conf ============== # # changes / additions marked by --------- WAN # # set up my hostname # hostname="spyder.bytecraft.au.com" # # network setup # network_interfaces="lo0 ng0 ng1 fxp0" ---------- WAN # # start_if.ng0 file is run here automagically # start_if.ng1 is run also ---------- WAN # ifconfig_lo0="inet 127.0.0.1" ifconfig_fxp0="inet10.1.2.30 netmask 255.255.0.0" ifconfig_ng0="inet xxx.yyy.zzz.1 netmask 255.255.255.192" ifconfig_ng1="inet 10.1.2.250 netmask 255.255.0.0" ---------- WAN # # firewall # ipfw_enable="YES" # # NAT setup here # natd_enable="YES" natd_interfaces="ng0" # # static routes # static_routes="ng0 ng1" ---------- WAN route_ng0="-net 0.0.0.0 -interface ng0" route_ng1="-net 10.1.7.0 10.1.2.250 255.255.0.0" ---------- WAN # # gateway enable # gateway_enable="YES" # # ----- end of netpass 1 # # named enable # named_enable="YES" named_flags="-u bind -g bind /etc/namedb/sandbox/named.conf" # # ----- end of netpass 2 # # sshd # sshd_enable="YES" # # ----- end of netpass 3 # # inetd flags # inetd_flags="" ============= end of network part of rc.conf ======================== the start_if.ng0 script ( basically a copy of the frame relay example file in /usr/share/examples/netgraph ) ===bytMelb== WAN =========== start_if.ng0 ========================== ----------- WAN no changes ============== end of start_if.ng0 =============================== ===bytMelb== WAN =========== start_if.ng1 ========================== #!/bin/sh # script to set up an additional frame relay link on the sr card. # WANic 405 CARD=sr0 # # WAN link to sydney DLCI=17 # Attach the DLCI(channel) the Telco has assigned you to # a node to handle whatever protocol encapsulation your peer # is using. In this case rfc1490 encapsulation. ngctl mkpeer ${CARD}:rawdata rfc1490 dlci${DLCI} downstream # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) # input of a netgraph "interface" node (ifconfig should show it as "ng1"). ngctl mkpeer ${CARD}:rawdata.dlci${DLCI} iface inet inet ====bytMelb== WAN ==========end of start_if.ng1 =================== windoze machines that need internet access have their gateway set to 10.1.2.30 other windoze machines should pass through to bytSyd OK due to netmask value 255.255.0.0 ???? ====bytSyd === WAN == network portions of rc.conf ================= # # set up my hostname # hostname="sydgate.bytecraft.au.com" # # network setup # network_interfaces="lo0 ng0 fxp0" # # start_if.ng0 file is run here automagically # ifconfig_lo0="inet 127.0.0.1" ifconfig_fxp0="inet 10.1.7.1 netmask 255.255.0.0" ifconfig_ng0="inet 10.1.7.250 netmask 255.255.0.0" # # firewall # ipfw_enable="NO" # # NAT setup here # natd_enable="NO" # # static routes # static_routes="ng0" route_ng0="-net 0.0.0.0 -interface ng0" # # gateway enable # gateway_enable="NO" # # ----- end of netpass 1 # # named enable # named_enable="NO" # # ----- end of netpass 2 # # sshd # sshd_enable="YES" # # ----- end of netpass 3 # # inetd flags # inetd_flags="" ===bytSyd== WAN == end of network part of rc.conf ====== the start_if.ng0 script ( basically a copy of the frame relay example file in /usr/share/examples/netgraph ) ===bytSyd== WAN ==== start_if.ng0 ===================== #!/bin/sh # script to set up a frame relay link on the sr card. # The dlci used is selected below. The default is 16 # WANic 405 CARD=sr0 DLCI=16 # create a frame_relay type node and attach it to the sync port. ngctl mkpeer ${CARD}: frame_relay rawdata downstream # Attach the dlci output of the (de)multiplexor to a new # Link management protocol node. ngctl mkpeer ${CARD}:rawdata lmi dlci0 auto0 # Also attach dlci 1023, as it needs both to try autoconfiguring. # The Link management protocol is now alive and probing.. ngctl connect ${CARD}:rawdata ${CARD}:rawdata.dlci0 dlci1023 auto1023 # Attach the DLCI(channel) the Telco has assigned you to # a node to hadle whatever protocol encapsulation your peer # is using. In this case rfc1490 encapsulation. ngctl mkpeer ${CARD}:rawdata rfc1490 dlci${DLCI} downstream # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) # input of a netgraph "interface" node (ifconfig should show it as "ng0"). ngctl mkpeer ${CARD}:rawdata.dlci${DLCI} iface inet inet ===bytSyd== WAN ====end of start_if.ng0 ====================== windoze machines that need internet access have their gateway set to 10.1.2.30 windoze machines should see melb system OK due to netmask value 255.255.0.0 ???? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 7:49:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from black.purplecat.net (ns1.purplecat.net [209.16.228.148]) by hub.freebsd.org (Postfix) with ESMTP id 3B12237B71B for ; Tue, 13 Mar 2001 07:49:25 -0800 (PST) (envelope-from peter@black.purplecat.net) Received: from localhost (peter@localhost) by black.purplecat.net (8.8.8/8.8.8) with ESMTP id KAA16701 for ; Tue, 13 Mar 2001 10:51:44 -0500 (EST) (envelope-from peter@black.purplecat.net) Date: Tue, 13 Mar 2001 10:51:44 -0500 (EST) From: Peter Brezny To: freebsd-net@freebsd.org Subject: route clarification 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 I've managed to get things working, but I've still got a question or two. Here's what i'm working with > internet ---- firewal/nat box ---- client firewall ---- client lan. > pub pub/10.30.1.1 10.30.1.20/10.20.21.1 10.20.21.x From Right to Left, each machine's default GW is the internal address of the machine to it's left. So the workstations on the client lan have their GW set to 10.20.21.1 and so on. With this config, the workstations on the client lan could ping both the inside and outside interface of the client firewall, but not the firewall/nat box. the client firewall could ping everything on either side. FInally with some help i figured out that packets were probably making it to the firewall/nat box due to the default route, but wern't finding their way out of the firewall/nat box back to where they came from. placing a route route add -net 10.20.21.124 10.30.1.20 on the firewall/nat box fixed this problem. My question is, why didn't routed or something figure this out on its own? Is this normal? or is the firewall on the firewall/nat box causing problems? Thanks in advance for your help. pb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 8: 8:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from 200-227-201-224-as.acessonet.com.br (200-227-201-249-as.acessonet.com.br [200.227.201.249]) by hub.freebsd.org (Postfix) with ESMTP id 8457837B72F for ; Tue, 13 Mar 2001 08:08:34 -0800 (PST) (envelope-from lioux@uol.com.br) Received: (qmail 1850 invoked by uid 1001); 13 Mar 2001 16:07:03 -0000 From: "Mario Sergio Fujikawa Ferreira" Date: Tue, 13 Mar 2001 13:06:41 -0300 To: Alfred Perlstein Cc: David Xu , Julian Elischer , Jonathan Lemon , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Re[2]: cvs commit: src/sys/netinet tcp_timer.c Message-ID: <20010313130641.A1766@Fedaykin.here> References: <200103012211.f21MBEv96903@freefall.freebsd.org> <11619657876.20010312141256@viasoft.com.cn> <20010312081100.P78851@prism.flugsvamp.com> <3AACF6E9.6730B7AE@elischer.org> <13914214859.20010313134458@viasoft.com.cn> <20010312231432.H29888@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: <20010312231432.H29888@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Mar 12, 2001 at 11:14:10PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Mar 12, 2001 at 11:14:10PM -0800, Alfred Perlstein wrote: > * David Xu [010312 21:39] wrote: > > Hello Julian, > > > > Tuesday, March 13, 2001, 12:18:49 AM, you wrote: > > > > JE> Jonathan Lemon wrote: > > >> > > >> On Mon, Mar 12, 2001 at 02:12:56PM +0800, David Xu wrote: > > >> > Hello Jonathan, > > >> > > > >> > Friday, March 02, 2001, 6:11:14 AM, you wrote: > > >> > > > >> > JL> jlemon 2001/03/01 14:11:14 PST > > >> > > > >> > JL> Modified files: (Branch: RELENG_4) > > >> > JL> sys/netinet tcp_timer.c > > >> > JL> Log: > > >> > JL> MFC: another component of TCP newreno I overlooked in last commit. > > >> > > > >> > JL> Revision Changes Path > > >> > JL> 1.34.2.4 +6 -1 src/sys/netinet/tcp_timer.c > > >> > > > >> > what is status of SACK implemention? > > >> > > >> I'm not sure that anyone is working on one at this time. When I > > >> investigated the issue around 1-2 years ago, I was shown some > > >> statisics indicating that less than 30% of the web actually used > > >> SACK, so I wasn't sufficiently motivated to do the work. > > > > JE> Msoft w98 and on use SAC > > >> -- > > >> Jonathan > > > > sigh, does it mean FreeBSD get behind in some TCP/IP features? > > I know Linux and OpenBSD support SACK, and possible NetBSD. > > We're terribly sorry we haven't been able to commit the code > you sent in, can you please point out the PR you submitted to > address this shortcoming? What about merging with luigi's code? Luigi? -- Mario S F Ferreira - UnB - Brazil - "I guess this is a signature." lioux at ( freebsd dot org | linf dot unb dot br ) flames to beloved devnull@someotherworldbeloworabove.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 8: 8:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from 200-227-201-249-as.acessonet.com.br (200-227-201-249-as.acessonet.com.br [200.227.201.249]) by hub.freebsd.org (Postfix) with ESMTP id EB4C237B730 for ; Tue, 13 Mar 2001 08:08:34 -0800 (PST) (envelope-from lioux@uol.com.br) Received: (qmail 1850 invoked by uid 1001); 13 Mar 2001 16:07:03 -0000 From: "Mario Sergio Fujikawa Ferreira" Date: Tue, 13 Mar 2001 13:06:41 -0300 To: Alfred Perlstein Cc: David Xu , Julian Elischer , Jonathan Lemon , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: Re[2]: cvs commit: src/sys/netinet tcp_timer.c Message-ID: <20010313130641.A1766@Fedaykin.here> References: <200103012211.f21MBEv96903@freefall.freebsd.org> <11619657876.20010312141256@viasoft.com.cn> <20010312081100.P78851@prism.flugsvamp.com> <3AACF6E9.6730B7AE@elischer.org> <13914214859.20010313134458@viasoft.com.cn> <20010312231432.H29888@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: <20010312231432.H29888@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Mar 12, 2001 at 11:14:10PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Mar 12, 2001 at 11:14:10PM -0800, Alfred Perlstein wrote: > * David Xu [010312 21:39] wrote: > > Hello Julian, > > > > Tuesday, March 13, 2001, 12:18:49 AM, you wrote: > > > > JE> Jonathan Lemon wrote: > > >> > > >> On Mon, Mar 12, 2001 at 02:12:56PM +0800, David Xu wrote: > > >> > Hello Jonathan, > > >> > > > >> > Friday, March 02, 2001, 6:11:14 AM, you wrote: > > >> > > > >> > JL> jlemon 2001/03/01 14:11:14 PST > > >> > > > >> > JL> Modified files: (Branch: RELENG_4) > > >> > JL> sys/netinet tcp_timer.c > > >> > JL> Log: > > >> > JL> MFC: another component of TCP newreno I overlooked in last commit. > > >> > > > >> > JL> Revision Changes Path > > >> > JL> 1.34.2.4 +6 -1 src/sys/netinet/tcp_timer.c > > >> > > > >> > what is status of SACK implemention? > > >> > > >> I'm not sure that anyone is working on one at this time. When I > > >> investigated the issue around 1-2 years ago, I was shown some > > >> statisics indicating that less than 30% of the web actually used > > >> SACK, so I wasn't sufficiently motivated to do the work. > > > > JE> Msoft w98 and on use SAC > > >> -- > > >> Jonathan > > > > sigh, does it mean FreeBSD get behind in some TCP/IP features? > > I know Linux and OpenBSD support SACK, and possible NetBSD. > > We're terribly sorry we haven't been able to commit the code > you sent in, can you please point out the PR you submitted to > address this shortcoming? What about merging with luigi's code? Luigi? -- Mario S F Ferreira - UnB - Brazil - "I guess this is a signature." lioux at ( freebsd dot org | linf dot unb dot br ) flames to beloved devnull@someotherworldbeloworabove.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 8:54:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 96EEE37B718 for ; Tue, 13 Mar 2001 08:53:51 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 12531 invoked by uid 666); 13 Mar 2001 16:54:54 -0000 Received: from i074-115.nv.iinet.net.au (HELO elischer.org) (203.59.74.115) by mail.m.iinet.net.au with SMTP; 13 Mar 2001 16:54:54 -0000 Message-ID: <3AAE5076.BF85C06@elischer.org> Date: Tue, 13 Mar 2001 08:53:10 -0800 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: Murray Taylor Cc: "'freebsd-net@freebsd.org'" Subject: Re: Frame Relay setup questions (and basis for tutorial?) References: <710709BB8B02D311942E00606744181054428D@MELEXC01> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Murray Taylor wrote: > > This loooong email will hopefully allow the netgraph - network gurus to > A: answer my remaining questions > and > B: grab this and make a tutorial 'worked example' (unless it is total blech > of course) > > So to those who have already earned their stripes from one looking for his > first > (hopefully, not to painful) stripe..... > > RTFMs used > - man netgraph, ng_frame_relay, ng_lmi, ng_iface, ng_rfc1490, ng_bridge > - /usr/share/examples/netgraph/* > - Daemonnews 200003 netgraph article by Archie Cobbs > - previous freebsd-questions and -net mailings > O'Reilly > - DNS and BIND > - Getting Connected - The internet at 56K and up > Addison-Wesley > - Practical Internetworking with TCP/IP and UNIX > > Other factoids about the networks > - The melbourne net is Win 9x/NT centric and almost all addresses are served > up by DHCP from the NT PDC > - The FreeBSD boxen are being used for the frame relay/ webserving > application > only at present. > - The FreeBSD boxen run Samba at the os level = 0 and other appropriate > settings to > avoid interaction with the Browse master election waffle of M$ land > > This is still theoretical, as I am still waiting for the copper connection > ;-) ! > But it is RSN !! > > -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o- > The Questions: > For the initial setup > > [1] Given the settings from Telstra for the Management protocol, do I need > the > netgraph ng_lmi module? yes FreeBSD will be happy without it but the telstra end will not enable the link unless it get's the regular link-ok packets that the lmi module sends. You can use any management protocol. the lmi module understands all three. (connect it to dlci0 and dlci1023 at once and it will try all possible combinations of dlci and protocol, or, use a specific protcol, attached to a praticular dlci as directed by the telstra instructions.. i.e AnnexA<---->dlci0 ANSI-AnnexD Iso/Ieee Annex D LMI- (sometimes refered to as "group-of-4") > > For the WAN setup > [1] Given that I understand that establishing the permanent virtual circuit > (PVC) > to the Sydney office will assign another DLCI number to us, is the netgraph > extension I have made in start_if.ng1 (melbourne setup) correct? > > [2] Do I need to add a router daemon to the melbourne system now? probably not. > > More difficult questions (given DHCP nature of the network) > [3] Do I need to fully populate the /etc/hosts table now? If the DHCP server is also the NDS server, probably not. > > [4] Do I need to fully populate the DNS table in Spyder? > > Other questions (bonus points!) > [1] if I need to bring out other xxx.yyy.zzz.0/26 addresses 'out-the-side' > of Spyder for other 'net visible machines, how should it be done? > There is'nt any lower / upper hooks on the ng_iface node to attach a > ng_bridge. I assume that this would be the connections point as it > is the 'effective ethernet port' that one normally hooks to, is it not? > > Murray Taylor > Project Engineer > > Bytecraft P/L +61 3 9587 2555 > +61 3 9587 1614 fax > mtaylor@bytecraft.com.au > > -o-o-o-o-o-o-o-o-o-o-o-o-o--o-o-o-o-o-o-o-o-o-o-o-o > The 2 setups to be examined w.r.t. the above questions > > Initial setup -- Internet Access from ByteMelb for website > > - select Management Protocol > ITU-T (CCITT) Q933 Annex A no > ANSI T1.617 Annex D yes (Telstra default) > LMI (FRF Doc#001-208966) no > > - select physical interface > X.21bis/V35 no > X.21 yes > G.704 no > > - Telstra assignments > xxx.yyy.zzz.0/26 network > DLCI 16 Internet link (Telstra 'Big Pond') > > - Hardware card WANic 405 with X21 interface > uses sr(4) driver - kernel compiled with NETGRAPH > > - hardware setup > > ng0 ip fxp0 ip > xxx.yyy.zzz.1 SPYDER 10.1.2.30 > +----------+ > | | > +---+ |-+-+ +-| > frame | N | X21 |s|n| |f| 100BaseT > =======| T |========|r|g| |x|~~~~~~~~~~~~ > relay | U | |0|0| |p| > +---+ |-+-+ |0| > | +-| > | | > | | > | | > | | > +----------+ > > Netgraph setup for Internet access > > [ ](auto1023) -------+ > [ lmi ](auto0) ---------+| > [ ] || > || > [ sr0 ] [ ](dlci0) ---+| > [ phys ](rawdata) --- (downstream)[ frame_relay ](dlci1023) -+ > [ ] [ ](dlci16)--+ > | > +---------------------------------------------------------+ > | > | { ] [ ng0 ] > +--- (downstream)[ rcf1490 ](inet) --- (inet)[ iface ] xxx.yyy.zzz.1 > [ ] [ ] > excellent, but if the telstra equipment also allows all management protocols the one you end up with is a roll of the dice.. you may prefer to use the specific protocol hooks for the lmi module attached to dlci0 > Desired Initial Routing > > default xxx.yyy.zzz.1 UGSc ng0 use the remote address for default.. i.e. the address at the telstra end. If in doubt as to what it is, set it to a random address in the ifconfig, make it the default route and then do a traceroute. It'll respond with it's correct address. Set that in as the remote address. > 127.0.0.1 127.0.0.1 UH lo0 > 10.1.2.0 ff:ff:ff:ff:ff:ff UHLWb fxp0 > 10.1.2 link#1 UC fxp0 > > - - - - so the following is done in this sequence via rc.conf > (written in the sequence that rc.network will process them) > > =============== network portions of rc.conf ========================== > # > # set up my hostname > # > hostname="spyder.bytecraft.au.com" > # > # network setup > # > network_interfaces="lo0 ng0 fxp0" > # > # (NB more needed in man pages re start_if.* files) > # > # start_if.ng0 file is run here automagically > # > ifconfig_lo0="inet 127.0.0.1" > ifconfig_fxp0="inet 10.1.2.30 netmask 255.255.0.0" > ifconfig_ng0="inet xxx.yyy.zzz.1 netmask 255.255.255.192" NO NO NO it is point-to-point link ifconfig ng0 MYADDRESS REMOTEADDRESS there is no netmask.. > # > # firewall > # > ipfw_enable="YES" > ipfw_flags="/etc/firewall/rules" > # > # NAT setup here > # > natd_enable="YES" > natd_interfaces="ng0" > # > # static routes > # > static_routes="ng0" > route_ng0="-net 0.0.0.0 xxx.yyy.zzz.1" is this the same as 'default'? > # > # gateway enable > # > gateway_enable="YES" > # > # ----- end of netpass 1 > # > # named enable > # > named_enable="YES" > named_flags="-u bind -g bind /etc/namedb/sandbox/named.conf" > # > # ----- end of netpass 2 > # > # sshd > # > sshd_enable="YES" > # > # ----- end of netpass 3 > # > # inetd flags > # > inetd_flags="" > > ============= end of network part of rc.conf ======================== > > the start_if.ng0 script > ( basically a copy of the frame relay example file in > /usr/share/examples/netgraph ) > > ================ start_if.ng0 ============================= > #!/bin/sh > # script to set up a frame relay link on the sr card. > # The dlci used is selected below. The default is 16 > > # WANic 405 > CARD=sr0 > DLCI=16 > > # create a frame_relay type node and attach it to the sync port. > ngctl mkpeer ${CARD}: frame_relay rawdata downstream > > # Attach the dlci output of the (de)multiplexor to a new > # Link management protocol node. > ngctl mkpeer ${CARD}:rawdata lmi dlci0 auto0 > > # Also attach dlci 1023, as it needs both to try autoconfiguring. > # The Link management protocol is now alive and probing.. > ngctl connect ${CARD}:rawdata ${CARD}:rawdata.dlci0 dlci1023 auto1023 > > # Attach the DLCI(channel) the Telco has assigned you to > # a node to hadle whatever protocol encapsulation your peer > # is using. In this case rfc1490 encapsulation. > ngctl mkpeer ${CARD}:rawdata rfc1490 dlci${DLCI} downstream > > # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) > # input of a netgraph "interface" node (ifconfig should show it as "ng0"). > ngctl mkpeer ${CARD}:rawdata.dlci${DLCI} iface inet inet > > ================end of start_if.ng0 ========================== > > windoze machines that need internet access have their gateway > set to 10.1.2.30 > > ** NOTE most internet access is inwards to apache webserver > running on spyder > > ===================================================================== > VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV > ===================================================================== > Second Setup > > Then when Sydney comes online as a WAN extension to the ByteMelb net > > Assumptions > Private Virtual Circuit (PVC) defined as : > DLCI 17 at bytemelb > DLCI 16 at bytesyd > > MELBOURNE > - hardware setup > > ng0 ip fxp0 ip > xxx.yyy.zzz.1 SPYDER 10.1.2.30 > ng1 ip +----------+ > 10.1.2.250 | +-+ | > | |n| | > +---+ |-+g| +-| > frame | N | X21 |s|0| |f| 100BaseT > =======| T |========|r|-| |x|~~~~~~~~~~~~ > relay | U | |0|n| |p| > +---+ |-+g| |0| > | |1| +-| > | +-+ | > | | > | | > | | > +----------+ > > Netgraph redefined to this configuration > > [ ](auto1023) -------+ > [ lmi ](auto0) ---------+| > [ ] || > || > [ sr0 ] [ ](dlci0) ---+| > [ phys ](rawdata) --- (downstream)[ frame_relay ](dlci1023) -+ > [ ] [ ](dlci16) ---+ > [ ](dlci17) --+| > || > +----------------------------------------------------------+| > |+----------------------------------------------------------+ > || > || { ] [ ng0 ] > |+--- (downstream)[ rcf1490 ](inet) --- (inet)[ iface ] 203.39.118.1 > | [ ] [ ] > | > | [ ] [ ng1 ] > +---- (downstream)[ rfc1490 ](inet) --- (inet)[ iface ] 10.1.2.250 > [ ] [ ] > > Desired Initial Routing > > default xxx.yyy.zzz.1 UGSc ng0 No, the default route is the IP address at the ISP end of the link, not at your end, (though in fact they could be the same address and it would still work.) Point-to-point interface routing decisions are made using the remote address. otherwise I thin you have it just right. The lmi module will log the DLCIs that it finds in the dmesg and /var/log/messages. > 127.0.0.1 127.0.0.1 UH lo0 > 10.1.7/24 10.1.2.250 UGS ng1 -- > added WAN link > 10.1.2.0 ff:ff:ff:ff:ff:ff UHLWb fxp0 > 10.1.2 link#1 UC fxp0 > > --- > SYDNEY > > - hardware setup > > ng0 ip fxp0 ip > 10.1.7.250 SYDGATE 10.1.7.1 > +----------+ > | | > +---+ |-+-+ +-| > frame | N | X21 |s|n| |f| 100BaseT > =======| T |========|r|g| |x|~~~~~~~~~~~~ > relay | U | |0|0| |p| > +---+ |-+-+ |0| > | +-| > | | > | | > | | > | | > +----------+ > > Netgraph will be similar to original ByteMelb setup > > [ ](auto1023) -------+ > [ lmi ](auto0) ---------+| > [ ] || > || > [ sr0 ] [ ](dlci0) ---+| > [ phys ](rawdata) --- (downstream)[ frame_relay ](dlci1023) -+ > [ ] [ ](dlci16)--+ > | > +---------------------------------------------------------+ > | > | { ] [ ng0 ] > +--- (downstream)[ rcf1490 ](inet) --- (inet)[ iface ] 10.1.7.250 > [ ] [ ] > > Desired Initial Routing > > default 10.1.7.250 UGSc ng0 > 127.0.0.1 127.0.0.1 UH lo0 > 10.1.7.0 ff:ff:ff:ff:ff:ff UHLWb fxp0 > 10.1.7 link#1 UC fxp0 > > - - - - so the setups now are this > (written in the sequence that rc.network will process them) > > =bytMelb==== WAN ===network portions of rc.conf ============== > # > # changes / additions marked by --------- WAN > # > # set up my hostname > # > hostname="spyder.bytecraft.au.com" > # > # network setup > # > network_interfaces="lo0 ng0 ng1 fxp0" ---------- WAN > # > # start_if.ng0 file is run here automagically > # start_if.ng1 is run also ---------- WAN > # > ifconfig_lo0="inet 127.0.0.1" > ifconfig_fxp0="inet 10.1.2.30 netmask 255.255.0.0" > ifconfig_ng0="inet xxx.yyy.zzz.1 netmask 255.255.255.192" no as above, ifconfig ng0 MYADDRESS TELSRAADDRESS ifconfig ng1 10.1.2.250 10.1.7.250 At sydney: ifconfig ng0 10.1.7.250 10.1.2.250 > ifconfig_ng1="inet 10.1.2.250 netmask 255.255.0.0" ---------- WAN > # > # firewall > # > ipfw_enable="YES" > # > # NAT setup here > # > natd_enable="YES" > natd_interfaces="ng0" > # > # static routes > # > static_routes="ng0 ng1" ---------- WAN > route_ng0="-net 0.0.0.0 -interface ng0" > route_ng1="-net 10.1.7.0 10.1.2.250 255.255.0.0" ---------- WAN > # > # gateway enable > # > gateway_enable="YES" > # > # ----- end of netpass 1 > # > # named enable > # > named_enable="YES" > named_flags="-u bind -g bind /etc/namedb/sandbox/named.conf" > # > # ----- end of netpass 2 > # > # sshd > # > sshd_enable="YES" > # > # ----- end of netpass 3 > # > # inetd flags > # > inetd_flags="" > > ============= end of network part of rc.conf ======================== > > the start_if.ng0 script > ( basically a copy of the frame relay example file in > /usr/share/examples/netgraph ) > > ===bytMelb== WAN =========== start_if.ng0 ========================== > > ----------- WAN no changes > > ============== end of start_if.ng0 =============================== > > ===bytMelb== WAN =========== start_if.ng1 ========================== > > #!/bin/sh > # script to set up an additional frame relay link on the sr card. > > # WANic 405 > CARD=sr0 > # > # WAN link to sydney > DLCI=17 > > # Attach the DLCI(channel) the Telco has assigned you to > # a node to handle whatever protocol encapsulation your peer > # is using. In this case rfc1490 encapsulation. > ngctl mkpeer ${CARD}:rawdata rfc1490 dlci${DLCI} downstream > > # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) > # input of a netgraph "interface" node (ifconfig should show it as "ng1"). > ngctl mkpeer ${CARD}:rawdata.dlci${DLCI} iface inet inet > > ====bytMelb== WAN ==========end of start_if.ng1 =================== > > windoze machines that need internet access have their gateway > set to 10.1.2.30 > > other windoze machines should pass through to bytSyd OK due to netmask > value 255.255.0.0 ???? > > ====bytSyd === WAN == network portions of rc.conf ================= > # > # set up my hostname > # > hostname="sydgate.bytecraft.au.com" > # > # network setup > # > network_interfaces="lo0 ng0 fxp0" > # > # start_if.ng0 file is run here automagically > # > ifconfig_lo0="inet 127.0.0.1" > ifconfig_fxp0="inet 10.1.7.1 netmask 255.255.0.0" > ifconfig_ng0="inet 10.1.7.250 netmask 255.255.0.0" ng interfaces are P2P > # > # firewall > # > ipfw_enable="NO" > # > # NAT setup here > # > natd_enable="NO" > # > # static routes > # > static_routes="ng0" > route_ng0="-net 0.0.0.0 -interface ng0" > # > # gateway enable > # > gateway_enable="NO" > # > # ----- end of netpass 1 > # > # named enable > # > named_enable="NO" > # > # ----- end of netpass 2 > # > # sshd > # > sshd_enable="YES" > # > # ----- end of netpass 3 > # > # inetd flags > # > inetd_flags="" > > ===bytSyd== WAN == end of network part of rc.conf ====== > > the start_if.ng0 script > ( basically a copy of the frame relay example file in > /usr/share/examples/netgraph ) > > ===bytSyd== WAN ==== start_if.ng0 ===================== > #!/bin/sh > # script to set up a frame relay link on the sr card. > # The dlci used is selected below. The default is 16 > > # WANic 405 > CARD=sr0 > DLCI=16 > > # create a frame_relay type node and attach it to the sync port. > ngctl mkpeer ${CARD}: frame_relay rawdata downstream > > # Attach the dlci output of the (de)multiplexor to a new > # Link management protocol node. > ngctl mkpeer ${CARD}:rawdata lmi dlci0 auto0 > > # Also attach dlci 1023, as it needs both to try autoconfiguring. > # The Link management protocol is now alive and probing.. > ngctl connect ${CARD}:rawdata ${CARD}:rawdata.dlci0 dlci1023 auto1023 > > # Attach the DLCI(channel) the Telco has assigned you to > # a node to hadle whatever protocol encapsulation your peer > # is using. In this case rfc1490 encapsulation. > ngctl mkpeer ${CARD}:rawdata rfc1490 dlci${DLCI} downstream > > # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) > # input of a netgraph "interface" node (ifconfig should show it as "ng0"). > ngctl mkpeer ${CARD}:rawdata.dlci${DLCI} iface inet inet > > ===bytSyd== WAN ====end of start_if.ng0 ====================== > > windoze machines that need internet access have their gateway > set to 10.1.2.30 > > windoze machines should see melb system OK due to netmask value > 255.255.0.0 ???? > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ 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 Tue Mar 13 9: 2:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 6C14837B719 for ; Tue, 13 Mar 2001 09:02:46 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 12777 invoked by uid 666); 13 Mar 2001 17:03:53 -0000 Received: from i074-115.nv.iinet.net.au (HELO elischer.org) (203.59.74.115) by mail.m.iinet.net.au with SMTP; 13 Mar 2001 17:03:53 -0000 Message-ID: <3AAE528F.60F2EB44@elischer.org> Date: Tue, 13 Mar 2001 09:02:07 -0800 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: Alfred Perlstein Cc: David Xu , Jonathan Lemon , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet tcp_timer.c References: <200103012211.f21MBEv96903@freefall.freebsd.org> <11619657876.20010312141256@viasoft.com.cn> <20010312081100.P78851@prism.flugsvamp.com> <3AACF6E9.6730B7AE@elischer.org> <13914214859.20010313134458@viasoft.com.cn> <20010312231432.H29888@fw.wintelcom.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > > > > sigh, does it mean FreeBSD get behind in some TCP/IP features? > > I know Linux and OpenBSD support SACK, and possible NetBSD. > > We're terribly sorry we haven't been able to commit the code > you sent in, can you please point out the PR you submitted to > address this shortcoming? to quote the SACK implementations list: FreeBSD: Luigi Rizzo' FreeBSD2.1R implementation FreeBSD: Eliot Yan of USC has also implemented SACK for FreeBSD: lyan@catarina.usc.edu there is at least one other too but I've lost it.. > > -- > -Alfred Perlstein - [bright@wintelcom.net|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 -- __--_|\ 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 Tue Mar 13 10: 3:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from samar.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id 5482F37B718 for ; Tue, 13 Mar 2001 10:03:16 -0800 (PST) (envelope-from sseth@sasken.com) Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id XAA05502; Tue, 13 Mar 2001 23:32:54 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Tue, 13 Mar 2001 23:32:53 +0000 (IST) Received: from localhost (sseth@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id XAA27751; Tue, 13 Mar 2001 23:32:58 +0530 (IST) Date: Tue, 13 Mar 2001 23:32:58 +0530 (IST) From: Satyajeet Seth To: Julian Elischer Cc: , Subject: Re: Ping Problem In-Reply-To: <3AACD88F.71BCAFEC@elischer.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 Hi Please see my comments below. > > I am using FreeBSD 4.1. I followed Roger's suggestion about "autosrc 0" > > message. But "autosrc" message is not available in ng_ether. > > I have tried commenting > > bcopy((IFP2AC(priv->ifp))->ac_enaddr, eh->ether_shost, > > 6); > > in ng_ether_rcv_lower in ng_ether.c with the effect that fxp0 is able to > > send packets with pseudo ethernet interface MAC address. > > please upgrade to at least 4.1.1 which has the autosrc command. > preferably to 4.2. If you need to maybe look at upgrading just netgraph > and possibly if_ethersubr.c bit I would be happier to see a move up for > the system as a whole. > > An upgrade within the '4' family should be pretty painless. I tried using a FreeBSD4.1.1 system, but the problem is still there. I suppose for now, my hack on FreeBSD4.1 will serve the purpose. Am I correct? > > > > I have tried the following setup for pinging from nge0 to some machine on > > LAN. > > > > on pcs130 (Machine with pseudo ethernet interfaces, see output of > > "ifconfig -a" below) > > ============================== > > 1. #route change -host 10.0.36.134 -ifp nge0 > > Now arp starts to print messages like: > > arp: 'IP addr' is on fxp0 but got response from 'MAC address' on nge0. > > broadcast frames received have to be sent to the interface that > is on that net. To do this you would need to read arp packets to decide > which network to send it. (sinc ethey are the usual users of broadcast > messages. At the moment you MAY MAY have success if you enable some bridging > as that disables some of those checks. > I tried putting 'options BRIDGE' in my configuration file. But now ARP resolution of pseudo ethernet interface returned MAC address of fxp0. So I reverted back. > > > > 2. #ping 10.0.36.134 > > This does not work. > > probably the arp packets are never getting back to the right interface > > You need to do more packet tracing. > does the packet hit the wire? Yes > does the target respond? Yes > is there a arp packet before it? Yes > does the dest respond tothe arp? Yes > does the response appear in the arp table? Yes > does the destination in turn send an arp request before responding to the ping? No. > does the arp response (broadcast) get assigned to an interface? > does it get answered? > from which interface? > does the response hit the wire? The answer to above three queries is no, because destination does not in turn send an arp request before responding to the ping. The ICMP request packets are reaching pseudo ethernet interface. But it is not responding back. This happens even if an ARP entry for the destination is there. Could you suggest what could be the problem? > > It was never envisionned to multiplex multiple ether networks over a single > network without adding a layer e.g. VLAN. This is what VLAN is for. > > The problems with broadcast packets is one of the problems. > > > > > on pcs134(some machine on lan) > > ============================== > > Using tee's I found that 10.0.36.134 receives ethernet frames with src > > MAC address of nge0 and dest MAC address of 10.0.36.134. > > pcs134 response frames are sent to MAC address of default router > > 10.0.32.1. But pcs130 does not receive these frames. > > why does the PC send to the default router? netmask problems I think > mask == ffffffff is probably a problem. Setting the same mask as fxp0 helps. My current ifconfig setting are: #ifconfig -a fxp0: flags=8943 mtu 150 0 inet 10.0.36.130 netmask 0xfffff000 broadcast 10.0.47.255 inet6 fe80::2d0:b7ff:febd:711%fxp0 prefixlen 64 scopeid 0x1 ether 00:d0:b7:bd:07:11 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10 baseT/UTP 10baseT/UTP lp0: flags=8810 mtu 1500 sl0: flags=c010 mtu 552 faith0: flags=8000 mtu 1500 gif0: flags=8010 mtu 1280 gif1: flags=8010 mtu 1280 gif2: flags=8010 mtu 1280 gif3: flags=8010 mtu 1280 lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x9 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 nge0: flags=8843 mtu 1500 inet 10.0.36.157 netmask 0xfffff000 broadcast 10.0.47.255 inet6 fe80::211:22ff:fe33:4455%nge0 prefixlen 64 scopeid 0xb ether 00:11:22:33:44:55 nge1: flags=8843 mtu 1500 inet 10.0.36.158 netmask 0xfffff000 broadcast 10.0.47.255 inet6 fe80::2d0:b7ff:febd:711%nge1 prefixlen 64 scopeid 0xc ether 11:22:33:44:55:66 Thanks Satya To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 12:37:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from black.purplecat.net (ns1.purplecat.net [209.16.228.148]) by hub.freebsd.org (Postfix) with ESMTP id 4A35D37B71C for ; Tue, 13 Mar 2001 12:37:24 -0800 (PST) (envelope-from peter@black.purplecat.net) Received: from localhost (peter@localhost) by black.purplecat.net (8.8.8/8.8.8) with ESMTP id PAA17666 for ; Tue, 13 Mar 2001 15:39:43 -0500 (EST) (envelope-from peter@black.purplecat.net) Date: Tue, 13 Mar 2001 15:39:43 -0500 (EST) From: Peter Brezny To: freebsd-net@freebsd.org Subject: problem with secondary dns update through ipfw firewall 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 I've got a problem with secondary DNS servers not being able to get updates from my primary through it's firewall. The firewall rules on the primary dns server (pertaining to dns) look like this. I thought I had my bases covered... # Allow DNS traffic from internet to query your DNS (for reverse # lookups etc). $fwcmd add allow tcp from any 53 to $ns1 53 setup $fwcmd add allow udp from any to $ns1 53 $fwcmd add allow udp from $ns1 53 to any I've also got: query-source address 209.16.228.145 port 53; In my named.conf on the primary dns server... However when secondaries create zone files, they are blank. I get the feeling it's a firewall problem because, when i configure the secondaries to use an internal address of the primary dns server (which has a keep-state allow all internal rule) in my test environment, the updates occur as expected. TIA pb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 13:17:34 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 88BA737B728 for ; Tue, 13 Mar 2001 13:17:30 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2DLl8814317; Tue, 13 Mar 2001 15:47:08 -0600 (CST) (envelope-from nick@rogness.net) Date: Tue, 13 Mar 2001 15:47:08 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Peter Brezny Cc: freebsd-net@FreeBSD.ORG Subject: Re: problem with secondary dns update through ipfw firewall 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 On Tue, 13 Mar 2001, Peter Brezny wrote: > I've got a problem with secondary DNS servers not being able to get > updates from my primary through it's firewall. > > The firewall rules on the primary dns server (pertaining to dns) look > like this. I thought I had my bases covered... > > > # Allow DNS traffic from internet to query your DNS (for reverse > # lookups etc). > $fwcmd add allow tcp from any 53 to $ns1 53 setup > $fwcmd add allow udp from any to $ns1 53 > $fwcmd add allow udp from $ns1 53 to any You are only allowing the setup of the zone transfer. You need to allow established traffic as well (tcp port 53). $fwdcmd add allow tcp from any 53 to any 53 This isn't very secure though. You can more specific ipfw rules that make this a little more secure. > > I've also got: > > query-source address 209.16.228.145 port 53; > > In my named.conf on the primary dns server... > > However when secondaries create zone files, they are blank. I get the > feeling it's a firewall problem because, when i configure the > secondaries to use an internal address of the primary dns server > (which has a keep-state allow all internal rule) in my test > environment, the updates occur as expected. yes, it is a firewall issue. 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 Tue Mar 13 14:48:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from web3102.mail.yahoo.com (web3102.mail.yahoo.com [204.71.202.187]) by hub.freebsd.org (Postfix) with SMTP id B267137B719 for ; Tue, 13 Mar 2001 14:48:37 -0800 (PST) (envelope-from guangruifu@yahoo.com) Message-ID: <20010313224837.21080.qmail@web3102.mail.yahoo.com> Received: from [216.98.102.225] by web3102.mail.yahoo.com; Tue, 13 Mar 2001 14:48:37 PST Date: Tue, 13 Mar 2001 14:48:37 -0800 (PST) From: Guangrui Fu Subject: Mobile IP implementation for FreeBSD To: mobile-ip , freebsd-net , freebsd-mobile MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm looking for open-sourced Mobile IP implementation on FreeBSD. Could anyone please give me some information? Many thanks, Guangrui __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 16:21:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by hub.freebsd.org (Postfix) with ESMTP id 52D5E37B719 for ; Tue, 13 Mar 2001 16:21:22 -0800 (PST) (envelope-from sales@mediagrade.ltd.uk) Received: from [213.1.65.210] (helo=shaleem) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 14cz2K-0006Uo-00 for net@FreeBSD.ORG; Wed, 14 Mar 2001 00:21:11 +0000 x-esmtp: 0 0 1 Message-ID: <6334200133140189254@shaleem> X-EM-Version: 5, 0, 0, 18 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: sales@mediagrade.ltd.uk X-MSMail-Priority: Normal From: "mediagrade team" To: Subject: MEDIA GRADE TRADE ENQUIRY Date: Wed, 14 Mar 2001 00:18:09 -00 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-SMTPExp-Version: 1, 0, 2, 2 X-SMTPExp-Registration: 00B0320C107602006905 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We are computer hardware specialists=2E We work within the retail sector a= s well as import/export=2E=20 Please let us know if you can supply the following:- QUANTITY=09DESCRIPTION=09=09=09 100+=09=09COMPAQ SERVERS =09=09FINAL PRICE PLEASE 1000+=09=09128 MB PC100 SDRAM =09=09(ANY BRAND)=09=09=09FINAL PRICE PLEASE 1000+=09=0964MB PC100 SDRAM =09=09(ANY BRAND)=09=09=09FINAL PRICE PLEASE 10000+=09=09P3 866MHZ FC-PGA=09=09FINAL PRICE PLEASE (=A3118) 1000+=09=09CELERON 800=09=09=09FINAL PRICE PLEASE 1000+=09=09CELERON 600=09=09=09FINAL PRICE PLEASE 10000 units=09486 DESKTOPS=09=09=09FINAL PRICE PLEASE=09=09=20 500 units =09P75 DESKTOPS=09=09=09FINAL PRICE PLEASE 200 units =09P100 DESKTOPS=09=09=09FINAL PRICE PLEASE 300 units =09P133 DESKTOPS=09=09=09FINAL PRICE PLEASE 500 units=09P166 DESKTOPS =09=09FINAL PRICE PLEASE=09 100 units=09P200 DESKTOPS =09=09FINAL PRICE PLEASE Monitors:=20 14" grade A - 500 units =09=09=09=09FINAL PRICE PLEASE 15" grade A - 1000 units =09=09=09=09FINAL PRICE PLEASE 14"/15" mix untested or defective -1000 units =09FINAL PRICE PLEASE 17" grade A - 200 units =09=09=09=09FINAL PRICE PLEASE 17" untested - 300 units=09=09=09=09FINAL PRICE PLEASE 200,000=09=0974min silver/blue unbranded=09=A30=2E10p per cd=2E =09=09=09cds 12x compatiable We are also looking for OEM SOFTWARE TITLES-BOXED & JEWEL CASED 20,000/60,000 TITLES PER MONTH - $0=2E50CENTS (AROUND THIS MARGIN) We also require large quantities of GSM MOBILE PHONES=85 All items shown are based on 100+ pieces 8210s 3310s 3210s C25s C35I 8850s 8250s T10s T28s Any other phones you can supply as well=2E Please list with price=2E Pri= ces must be below average trade price=2E Again on a regular basis=2E=09 Please note that this is a very serious order=2E We require these goods o= n a monthly basis=2E Please ask for Shaleem Media Grade Ltd=2E 2A Burges Road Eastham LONDON E6 2BH direct contact for Shaleem:- +44 07939008835 Sales: +44 208 471 0886 / 0080 Email: sales@mediagrade=2Eltd=2Euk =09Biz@mediagrade=2Eltd=2Euk =09Techsupport@mediagrade=2Eltd=2Euk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 16:22: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from hand.dotat.at (sfo-gw.covalent.net [207.44.198.62]) by hub.freebsd.org (Postfix) with ESMTP id 1C20937B71A for ; Tue, 13 Mar 2001 16:22:07 -0800 (PST) (envelope-from fanf@dotat.at) Received: from fanf by hand.dotat.at with local (Exim 3.20 #3) id 14cz23-000ESK-00; Wed, 14 Mar 2001 00:20:51 +0000 Date: Wed, 14 Mar 2001 00:20:51 +0000 From: Tony Finch To: Garrett Wollman Cc: Brian Somers , net@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: MAXHOSTNAMELEN redux Message-ID: <20010314002051.U96832@hand.dotat.at> References: <200103121813.NAA61145@khavrinen.lcs.mit.edu> <200103130149.f2D1nQB08449@hak.lan.Awfulhak.org> <200103130149.f2D1nQB08449@hak.lan.Awfulhak.org> <200103130210.VAA66732@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: <200103130210.VAA66732@khavrinen.lcs.mit.edu> Organization: Covalent Technologies, Inc Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Garrett Wollman wrote: > >I think the common-sense interpretation when one speaks of the >``maximum length'' of some string is that it is the maximum value >strlen() might return, and doesn't include metainformation. However it slightly uglifies idiomatic coding of things like array declarations and calls to malloc() and strlcpy() and so forth. Tony. -- f.a.n.finch fanf@covalent.net dot@dotat.at VIKING: NORTHEAST BACKING NORTHWEST 3 OR 4, OCCASIONALLY 5. SHOWERS. GOOD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 16:43:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 88ADB37B719 for ; Tue, 13 Mar 2001 16:43:30 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f2E0hUG19274 for ; Tue, 13 Mar 2001 16:43:30 -0800 (PST) Message-ID: <3AAEBEAE.F823CB8E@isi.edu> Date: Tue, 13 Mar 2001 16:43:26 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: net@FreeBSD.org Subject: Changing UDP select() behavior Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms428413B44FB1D00D6BDC821D" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms428413B44FB1D00D6BDC821D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I'm wondering if anyone has ever considered modifying the UDP behavior with regard to selecting: Currently, writing to a UDP socket either enqueues packets in the interface queue (returning success), or drops them on the floor (returning ENOBUFS) if the queue is full. Selecting-to-write on a UDP socket always succeeds, never blocks. I'm considering changing this, so that a select-to-write on a UDP socket will block until queue space becomes available. (I don't think this would violate UDP semantics, but is a big enough change to warrant a new sockopt to enable it.) Has this been considered/implemented in any OS? Does anyone see any serious problems with it? Feedback greatly appreciated! Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms428413B44FB1D00D6BDC821D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMxNDAwNDMyOVowIwYJKoZIhvcNAQkEMRYE FHcKBPi4fTMyx7DLM3Qpp30YIa87MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAeg7KxjiyzWxveJsQ+AcFfKAhwHcsw+ZJOHZMZU5ufV8AJmwuNKoV 3eq7SWDxW/WInDjHMk4zIeSuNGf8BiQlNDvJNBGu/lICZh8Dn8hvVK0k1H3jufLpWGyfVFHI 3oqzby5bQ4neQAFAgysRpI7ASo6xyjmfaONDvXFdCZW27YI= --------------ms428413B44FB1D00D6BDC821D-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 17: 2:56 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 94CE137B718 for ; Tue, 13 Mar 2001 17:02:52 -0800 (PST) (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.2/8.11.2) with ESMTP id f2E155C16939; Wed, 14 Mar 2001 01:05:06 GMT (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 f2E161a09824; Wed, 14 Mar 2001 01:06:01 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200103140106.f2E161a09824@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Lars Eggert Cc: net@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Changing UDP select() behavior In-Reply-To: Message from Lars Eggert of "Tue, 13 Mar 2001 16:43:26 PST." <3AAEBEAE.F823CB8E@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Mar 2001 01:06:01 +0000 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hi, > > I'm wondering if anyone has ever considered modifying the UDP behavior with > regard to selecting: > > Currently, writing to a UDP socket either enqueues packets in the interface > queue (returning success), or drops them on the floor (returning ENOBUFS) > if the queue is full. Selecting-to-write on a UDP socket always succeeds, > never blocks. > > I'm considering changing this, so that a select-to-write on a UDP socket > will block until queue space becomes available. (I don't think this would > violate UDP semantics, but is a big enough change to warrant a new sockopt > to enable it.) > > Has this been considered/implemented in any OS? Does anyone see any serious > problems with it? Feedback greatly appreciated! This'd be nice if it could be made to work. I guess the problem is that you don't actually know if a write() will succeed 'till you try it (and try to allocate an mbuf). Having said this, it would be nice if it was possible to pre-allocate (a small number of) mbufs for a pipe() or socketpair(), giving a reliable SOCK_DGRAM file-descriptor based ipc mechanism. > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California -- 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 Tue Mar 13 17:56:41 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 C54A937B718 for ; Tue, 13 Mar 2001 17:56:38 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA42646; Tue, 13 Mar 2001 20:56:32 -0500 (EST) (envelope-from wollman) Date: Tue, 13 Mar 2001 20:56:32 -0500 (EST) From: Garrett Wollman Message-Id: <200103140156.UAA42646@khavrinen.lcs.mit.edu> To: Lars Eggert Cc: net@FreeBSD.ORG Subject: Changing UDP select() behavior In-Reply-To: <3AAEBEAE.F823CB8E@isi.edu> References: <3AAEBEAE.F823CB8E@isi.edu> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I'm considering changing this, so that a select-to-write on a UDP socket > will block until queue space becomes available. Impossible. The only way to find out whether a packet (or set of packets, or a fragment of a packet) would be successfully enqueued is to try it. Even then there's no guarantee that it will get sent. (Actually, ``impossible'' is too strong -- we could restructure the entire network stack to make it possible to speculatively send packets just to support this change in select() semantics. It's merely impractical.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 22:16:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id DF03D37B719 for ; Tue, 13 Mar 2001 22:16:19 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 86E7481D01; Wed, 14 Mar 2001 00:16:19 -0600 (CST) Date: Wed, 14 Mar 2001 00:16:19 -0600 From: Bill Fumerola To: Nick Rogness Cc: Peter Brezny , freebsd-net@FreeBSD.ORG Subject: Re: problem with secondary dns update through ipfw firewall Message-ID: <20010314001619.O31752@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@rogness.net on Tue, Mar 13, 2001 at 03:47:08PM -0600 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Mar 13, 2001 at 03:47:08PM -0600, Nick Rogness wrote: > > # Allow DNS traffic from internet to query your DNS (for reverse > > # lookups etc). > > $fwcmd add allow tcp from any 53 to $ns1 53 setup > > $fwcmd add allow udp from any to $ns1 53 > > $fwcmd add allow udp from $ns1 53 to any > > You are only allowing the setup of the zone transfer. You need to > allow established traffic as well (tcp port 53). > > $fwdcmd add allow tcp from any 53 to any 53 > > This isn't very secure though. You can more specific ipfw rules > that make this a little more secure. Luckily, figuring out which servers you need to allow is pretty easy, you already have a list of them. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 22:39:41 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id C831737B719 for ; Tue, 13 Mar 2001 22:39:36 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id HAA14416; Wed, 14 Mar 2001 07:39:51 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200103140639.HAA14416@info.iet.unipi.it> Subject: Re: Changing UDP select() behavior In-Reply-To: <3AAEBEAE.F823CB8E@isi.edu> from Lars Eggert at "Mar 13, 2001 04:43:26 pm" To: Lars Eggert Date: Wed, 14 Mar 2001 07:39:50 +0100 (CET) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] 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 > Hi, > > I'm wondering if anyone has ever considered modifying the UDP behavior with > regard to selecting: > > Currently, writing to a UDP socket either enqueues packets in the interface > queue (returning success), or drops them on the floor (returning ENOBUFS) > if the queue is full. Selecting-to-write on a UDP socket always succeeds, > never blocks. I think it would require some substantial change to the network stack structure (basically to let your sockets sleep on an interface, and being woken up when the queue drains). There are fairness and efficiency issues here, because the device queue has so many "users" that the usual low-water/high-water strategy might cause a blocked socket to starve forever, so you might need to effectively block queueing if there are sockets sleeping on a queue, maybe issue a wakeup() on every single transmission when you have sockets waiting, and probably implement some ordering (maybe as simple as FIFO) for the waiting sockets. All in all I think this approach would only help a bit if if you were allowed to queue in the socket buffer (on which you can think of having some control, because you either opened the fd yourself or you inherited it from some parent), in addition to the device queue. cheers luigi > I'm considering changing this, so that a select-to-write on a UDP socket > will block until queue space becomes available. (I don't think this would > violate UDP semantics, but is a big enough change to warrant a new sockopt > to enable it.) > > Has this been considered/implemented in any OS? Does anyone see any serious > problems with it? Feedback greatly appreciated! > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California Content-Description: S/MIME Cryptographic Signature [Attachment, skipping...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 13 23: 8:51 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 0C44337B719 for ; Tue, 13 Mar 2001 23:08:29 -0800 (PST) (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 JAA64443; Wed, 14 Mar 2001 09:07:03 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: "Peter Brezny" , Subject: RE: route clarification Date: Wed, 14 Mar 2001 09:07:03 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter, > My question is, why didn't routed or something figure this out on its own? What? These are just computers, remember? Computers have a nasty habit of doing what we tell them to do, not what we want them to do! ;-) Seriously though, You do need to tell the firewall/nat box about the 10.20.21.0/24 network before it will route correctly to that network. While there was no route it would have used the default route, which would have sent the packets out onto the web (I presume), and your ISP probably filtered them at their router as these are reserved private addresses. The only thing I would change is that the route entry should really be: # route add -net 10.20.21.0/24 10.30.1.20 and not: # route add -net 10.20.21.124 10.30.1.20 This will ensure that the whole 10.20.21.0/24 network is correctly routed, not just the given IP. You will notice if you perform a 'route get 10.20.21.124' after using your original 'route add' that the result is: ---- # route get 10.20.21.124 route to: 10.20.21.124 destination: 10.20.21.124 mask: 255.255.255.255 <--- here is your problem gateway: 10.30.1.20 ---- Try 'route get 10.20.21.125' (I presume you want this IP to route the same way?) ---- # route get 10.20.21.125 route to: 10.20.21.125 destination: default mask: default gateway: ---- If you do: # route add -net 10.20.21.0/24 10.30.1.20 Try 'route get 10.20.21.125' and now you get: ---- # route get 10.20.21.125 route to: 10.20.21.125 destination: 10.20.21.0 mask: 255.255.255.0 <--- the netmask is correct now gateway: 10.30.1.20 ---- Have fun, Patrick. -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Peter Brezny Sent: 13 March 2001 17:52 To: freebsd-net@FreeBSD.ORG Subject: route clarification I've managed to get things working, but I've still got a question or two. Here's what i'm working with > internet ---- firewal/nat box ---- client firewall ---- client lan. > pub pub/10.30.1.1 10.30.1.20/10.20.21.1 10.20.21.x >From Right to Left, each machine's default GW is the internal address of the machine to it's left. So the workstations on the client lan have their GW set to 10.20.21.1 and so on. With this config, the workstations on the client lan could ping both the inside and outside interface of the client firewall, but not the firewall/nat box. the client firewall could ping everything on either side. FInally with some help i figured out that packets were probably making it to the firewall/nat box due to the default route, but wern't finding their way out of the firewall/nat box back to where they came from. placing a route route add -net 10.20.21.124 10.30.1.20 on the firewall/nat box fixed this problem. My question is, why didn't routed or something figure this out on its own? Is this normal? or is the firewall on the firewall/nat box causing problems? Thanks in advance for your help. pb 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 Mar 14 2:51:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id C2BB637B718 for ; Wed, 14 Mar 2001 02:51:43 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 30576 invoked by uid 666); 14 Mar 2001 10:52:50 -0000 Received: from i078-218.nv.iinet.net.au (HELO elischer.org) (203.59.78.218) by mail.m.iinet.net.au with SMTP; 14 Mar 2001 10:52:50 -0000 Message-ID: <3AAF4D16.6AEFD026@elischer.org> Date: Wed, 14 Mar 2001 02:51:02 -0800 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: Mike Nowlin Cc: freebsd-net@freebsd.org Subject: Re: questions re: multiple internet conn routing References: <20010304025518.A1844@argos.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Nowlin wrote: > > (Looking for some general pointers to solutions here...) > > Just had a second DSL connection installed, and have several questions > regarding how to map it into the FBSD router we use... I assume this is DSL without PPPoE.. > > The basic setup here (with just the single DSL line, 32 IPs on that line) is the ISP allocated you 32 addresses? (a /27 or something?) > DSL->Router->hosts, where DSL->Router is on dc0, and Router->hosts is on > fxp0. Basically, I added dc1 for the 2nd DSL connection. Local traffic is > split between fxp0 and dc2, depending on the subnet it's for. (10.193.x.x > or 10.98.x.x, and those subnets go to a pair of BSD routers that break > things down further, going to several ethernet segs and Cisco 804s for various > ISDN links, plus another router that has a cable connection on it for outgoing > FTP/HTTP requests from certain machines, not to mention the 200+ "ppp -auto" > links - kinda fun to figure out how a packet gets from point A to point > B..:) ) Ah, the joys of having a network supporting a lot of physical > locations that has to be cost-effective.. so you really nead the equivalent of two 'default' routes with some sort of load sharing.. You are correct in that you will need two natds running. I would use a random bit (say bit23) of the destination IP address to decide which to send the packet too (a simple ipfw rule) basically the simpler the better. #excempt lo0 from ant further processing. We trust it. ipfw add 50 accept ip from any to any via lo0 # separate the incoming from the outgoing packets on the machine. ipfw add 100 skipto 6000 ip from any to any out # Send any incoming packets from the outside world to be examined by natd ipfw add 100 skipto 150 ip from any to any rcv dc0 ipfw add 100 skipto 150 ip from any to any rcv dc1 # do no more processing on other incoming packets on the internal side. # we'll get them on the outgoing side. ipfw add 105 deny ip from any to 127.0.0.0/8 ipfw add 110 accept ip from any to any in #Incoming packets that need to be nat'd should be sent to the right natd ipfw add 150 skipto 300 ip to 0.0.1.0:0.0.1.0 ipfw add 200 divert 8998 ip from any to any ipfw add skipto 350 ip from any to any ipfw add 300 divert 8999 ip from any to any # Any incoming packets that get here have been translated # NATD will have culled any bad packets but yu might add your own # local further rules here if you don't trust it. # Addresses are now 10.x.x.x on the local end. (destination) # e.g. here I only allow outgoing session startups (natd duplicates this but...) ipfw add 350 reject tcp from any to any setup ipfw add 350 accept ip from any to any ##################### EXIT processing ############## # Only packets leaving the machine get here. # Only stuff destined to the outside world should be translated. # others are just passed to further processing ipfw add 900 skipto 7000 ip from any to any out xmit fxp0 ipfw add 900 skipto 7000 ip from any to any out xmit dc2 # Anything coming here should be translated. ipfw add 1500 skipto 2500 ip to 0.0.1.0:0.0.1.0 ipfw add 2000 divert 8998 ip from any to any ipfw add skipto 3000 ip from any to any ipfw add 2500 divert 8999 ip from any to any # put any general outgoing filters here ipfw add 3000 .......(next rule) ipfw add 3500 accept ip from any to any # filters for internal routing go here. ipfw add 7000 this will need tweeking to handle services on the gateway properly. You probably want to keep them through one or the other of your interfaces. > > All of our machines are assigned a 10.x.x.x address, and I use ipfw and natd > to do translation between the DSL1 and net-10 addresses - works beautifully. > > First question: after playing with this a bit, I've come to the decision > that I probably need to send NAT packets to two different divert sockets - > one for each DSL IP block. With /etc/natd.conf holding the NAT rules, is it > possible to have two "port" or "alias_address" lines: > > alias_address 1.2.3.4 > port 8668 > redirect_address 10.1.1.7 1.2.3.7 > redirect_address 10.1.1.8 1.2.3.8 > alias_address 5.6.7.1 > port 8669 > redirect_address 10.1.1.7 5.6.7.7 > redirect_address 10.1.1.8 5.6.7.8 > > ...or do I need to run two copies of natd for this to work correctly? > > Second question: I could probably do this blindfolded on a Cisco router, but > is there some way to accomplish the Cisco idea of "policy-based routing" on > a FBSD box? I basically need to look at the source address of a packet and > send it to the appropriate ethernet interface for the DSL IP block that > matches that source address. I'm guessing that netgraph might be involved, > but I haven't ever looked at it much more than the examples provided... (If > netgraph is involved, I may need a little more help than "Yes, it can be > done." :) ) > > Third question: I vaguely remember that netgraph packets don't go through > ipfw, possibly under certain circumstances. True? > > Thanks - Mike > > -------------------------------------------------------------------------------- > Part 1.2Type: application/pgp-signature -- __--_|\ 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 Wed Mar 14 3: 9: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id E234637B718 for ; Wed, 14 Mar 2001 03:09:00 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 30797 invoked by uid 666); 14 Mar 2001 11:10:08 -0000 Received: from i003-078.nv.iinet.net.au (HELO elischer.org) (203.59.3.78) by mail.m.iinet.net.au with SMTP; 14 Mar 2001 11:10:08 -0000 Message-ID: <3AAF5124.5F201288@elischer.org> Date: Wed, 14 Mar 2001 03:08:20 -0800 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: Satyajeet Seth Cc: net@freebsd.org, gbnaidu@sasken.com Subject: Re: Ping Problem References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satyajeet Seth wrote: > > > An upgrade within the '4' family should be pretty painless. > > I tried using a FreeBSD4.1.1 system, but the problem is still there. > I suppose for now, my hack on FreeBSD4.1 will serve the purpose. Am I > correct? > well 4.1.1 has the autosrc command which does what you are doing with your hack. > > I tried putting 'options BRIDGE' in my configuration file. But now ARP > resolution of pseudo ethernet interface returned MAC address of fxp0. So I > reverted back. wierd this suggests a packet somewhere is getting misdirected somewhere > > > > > > > 2. #ping 10.0.36.134 > > > This does not work. > > > > probably the arp packets are never getting back to the right interface > > > > You need to do more packet tracing. > > does the packet hit the wire? > Yes > > does the target respond? > Yes > > is there a arp packet before it? > Yes > > does the dest respond tothe arp? > Yes > > does the response appear in the arp table? > Yes > > does the destination in turn send an arp request before responding to > the ping? > No. > > > does the arp response > (broadcast) get assigned to an interface? > > does it get answered? > > from which interface? > > does the response hit the wire? > The answer to above three queries is no, because destination does not in > turn send an arp request before responding to the ping. I guess it learns from the arp enquiry. > > The ICMP request packets are reaching pseudo ethernet interface. But > it is not responding back. This happens even if an ARP entry for the > destination is there. Could you suggest what could be the problem? > > > > > > why does the PC send to the default router? netmask problems I think > > mask == ffffffff is probably a problem. > > Setting the same mask as fxp0 helps. does this mean that your problem is solved or just helped a bit? > > Thanks > Satya -- __--_|\ 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 Wed Mar 14 3:22:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-59.dsl.lsan03.pacbell.net [63.207.60.59]) by hub.freebsd.org (Postfix) with ESMTP id F129037B71C; Wed, 14 Mar 2001 03:22:23 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C9A7D66B6C; Wed, 14 Mar 2001 03:22:19 -0800 (PST) Date: Wed, 14 Mar 2001 03:22:19 -0800 From: Kris Kennaway To: Guangrui Fu Cc: mobile-ip , freebsd-net , freebsd-mobile Subject: Re: Mobile IP implementation for FreeBSD Message-ID: <20010314032219.A30923@mollari.cthul.hu> References: <20010313224837.21080.qmail@web3102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010313224837.21080.qmail@web3102.mail.yahoo.com>; from guangruifu@yahoo.com on Tue, Mar 13, 2001 at 02:48:37PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 13, 2001 at 02:48:37PM -0800, Guangrui Fu wrote: > Hi, >=20 > I'm looking for open-sourced Mobile IP implementation > on FreeBSD. Could anyone please give me some > information? KAME (www.kame.net) has an experimental implementation which will be integrated into FreeBSD at some point in the future once it's considered ready enough. Kris --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6r1RrWry0BWjoQKURAq+5AKDQhahBiMpxloTDQgsLF5jphJh34ACdEJIf 0nbm260/T/ZLfyu+IYWN4/4= =D/Zh -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 4:13:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from samar.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id C999837B719 for ; Wed, 14 Mar 2001 04:13:20 -0800 (PST) (envelope-from sseth@sasken.com) Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id RAA28038; Wed, 14 Mar 2001 17:43:06 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Wed, 14 Mar 2001 17:43:04 +0000 (IST) Received: from localhost (sseth@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id RAA10032; Wed, 14 Mar 2001 17:43:04 +0530 (IST) Date: Wed, 14 Mar 2001 17:43:04 +0530 (IST) From: Satyajeet Seth To: Julian Elischer Cc: , Subject: Re: Ping Problem In-Reply-To: <3AAF5124.5F201288@elischer.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 The problem is not solved. The pseudo ethernet interface(PEI) is responding with its MAC address. So arp resolution is taking place. But it is not responding to ICMP request packet. When I enable bridging the PEI's as well as fxp0 are responding to ARP with their MAC address leading to improper setting of MAC address at the other end. Thanks Satya On Wed, 14 Mar 2001, Julian Elischer wrote: > Satyajeet Seth wrote: > > > > > > An upgrade within the '4' family should be pretty painless. > > > > I tried using a FreeBSD4.1.1 system, but the problem is still there. > > I suppose for now, my hack on FreeBSD4.1 will serve the purpose. Am I > > correct? > > > well 4.1.1 has the autosrc command which does what you are doing with your hack. > > > > > I tried putting 'options BRIDGE' in my configuration file. But now ARP > > resolution of pseudo ethernet interface returned MAC address of fxp0. So I > > reverted back. > > wierd this suggests a packet somewhere is getting misdirected somewhere > > > > > > > > > > > 2. #ping 10.0.36.134 > > > > This does not work. > > > > > > probably the arp packets are never getting back to the right interface > > > > > > You need to do more packet tracing. > > > does the packet hit the wire? > > Yes > > > does the target respond? > > Yes > > > is there a arp packet before it? > > Yes > > > does the dest respond tothe arp? > > Yes > > > does the response appear in the arp table? > > Yes > > > does the destination in turn send an arp request before responding to > > the ping? > > No. > > > > > does the arp response > > (broadcast) get assigned to an interface? > > > does it get answered? > > > from which interface? > > > does the response hit the wire? > > The answer to above three queries is no, because destination does not in > > turn send an arp request before responding to the ping. > > I guess it learns from the arp enquiry. > > > > > The ICMP request packets are reaching pseudo ethernet interface. But > > it is not responding back. This happens even if an ARP entry for the > > destination is there. Could you suggest what could be the problem? > > > > > > > > > > why does the PC send to the default router? netmask problems I think > > > mask == ffffffff is probably a problem. > > > > Setting the same mask as fxp0 helps. > > does this mean that your problem is solved or just helped a bit? > > > > > Thanks > > Satya > > -- > __--_|\ 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 4:50:49 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 7314537B719; Wed, 14 Mar 2001 04:50:45 -0800 (PST) (envelope-from itojun@itojun.org) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id VAA23800; Wed, 14 Mar 2001 21:50:32 +0900 (JST) To: Kris Kennaway Cc: Guangrui Fu , mobile-ip , freebsd-net , freebsd-mobile In-reply-to: kris's message of Wed, 14 Mar 2001 03:22:19 PST. <20010314032219.A30923@mollari.cthul.hu> 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: Mobile IP implementation for FreeBSD From: itojun@iijlab.net Date: Wed, 14 Mar 2001 21:50:32 +0900 Message-ID: <23798.984574232@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> I'm looking for open-sourced Mobile IP implementation >> on FreeBSD. Could anyone please give me some >> information? > >KAME (www.kame.net) has an experimental implementation which will be >integrated into FreeBSD at some point in the future once it's >considered ready enough. KAME does mobile-ip6 only. we don't do mobile-ip4. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 4:59:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 6FBBB37B719 for ; Wed, 14 Mar 2001 04:59:45 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id f2ECxgn83674; Wed, 14 Mar 2001 13:59:42 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.2/8.11.0) id f2ECxV576409; Wed, 14 Mar 2001 13:59:31 +0100 (CET) (envelope-from asmodai) Date: Wed, 14 Mar 2001 13:59:30 +0100 From: Jeroen Ruigrok/Asmodai To: Yu-Shun Wang Cc: net@freebsd.org Subject: Re: Strong vs. Weak ES models? Message-ID: <20010314135930.D74704@daemon.ninth-circle.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from yushunwa@isi.edu on Thu, Mar 08, 2001 at 11:34:40AM -0800 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Yu-Shun, -On [20010308 22:05], Yu-Shun Wang (yushunwa@isi.edu) wrote: > Has the topic of Strong/Weak ES model been discussed here? > Please give me a pointer if the topic has been debated. In what sense discussed? What type we are? What we support? > I was wondering if there's a sysctl switch (like > net.inet.ip.strongendsystem mentioned in NetBSD list) > implemented in FreeBSD. Not as far as I know. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Religion... Is the opium of the people... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 5:38:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 34F0037B719; Wed, 14 Mar 2001 05:38:42 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id f2EDccd87956; Wed, 14 Mar 2001 14:38:38 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.2/8.11.0) id f2EDSlI76648; Wed, 14 Mar 2001 14:28:47 +0100 (CET) (envelope-from asmodai) Date: Wed, 14 Mar 2001 14:28:47 +0100 From: Jeroen Ruigrok/Asmodai To: Rafael Tonin Cc: freebsd-net@freebsd.org, jlemon@freebsd.org Subject: Re: Intel PRO/100+ PCI problem Message-ID: <20010314142847.E74704@daemon.ninth-circle.org> References: <003901c0a7d7$91b465e0$6214b0c8@bohr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <003901c0a7d7$91b465e0$6214b0c8@bohr>; from rafael.tonin@terra.com.br on Thu, Mar 08, 2001 at 10:56:26AM -0300 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20010308 22:02], Rafael Tonin (rafael.tonin@terra.com.br) wrote: >I'm having some problems on configuring my just purchased Intel PRO/100+ PCI (reported by Intel as being P#: 689661-004). > >When booting, FreeBSD 4.2 reports: > >fxp0: at device 13.0 on pci0 >fxp0: could not map memory You might want to try the latest sources Jonathan Lemon [cc:'d] came up with. I've looked at the diffs and he did some nice cleanups to bring the driver into the present. This might also fix your problem. Jona, did you already have tarball for 4-STABLE which people can just extract and compile a new kernel with? Btw, wrt nfxp, I looked at the code and it looks like a sane cleanup and I doubt we need a nfxp. I'll plug in a fxp [sb82558b based] with a Pulse transformer module/PHY [h1012] and test if it still works for me. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 E pluribus unum... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 6:51:10 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 60D2B37B718; Wed, 14 Mar 2001 06:51:08 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f2EElvY53783; Wed, 14 Mar 2001 08:47:57 -0600 (CST) (envelope-from jlemon) Date: Wed, 14 Mar 2001 08:47:57 -0600 From: Jonathan Lemon To: Jeroen Ruigrok/Asmodai Cc: Rafael Tonin , freebsd-net@freebsd.org, jlemon@freebsd.org Subject: Re: Intel PRO/100+ PCI problem Message-ID: <20010314084757.Y78851@prism.flugsvamp.com> References: <003901c0a7d7$91b465e0$6214b0c8@bohr> <20010314142847.E74704@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010314142847.E74704@daemon.ninth-circle.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Mar 14, 2001 at 02:28:47PM +0100, Jeroen Ruigrok/Asmodai wrote: > -On [20010308 22:02], Rafael Tonin (rafael.tonin@terra.com.br) wrote: > >I'm having some problems on configuring my just purchased Intel PRO/100+ PCI (reported by Intel as being P#: 689661-004). > > > >When booting, FreeBSD 4.2 reports: > > > >fxp0: at device 13.0 on pci0 > >fxp0: could not map memory > > You might want to try the latest sources Jonathan Lemon [cc:'d] came up > with. I've looked at the diffs and he did some nice cleanups to bring > the driver into the present. This might also fix your problem. > > Jona, did you already have tarball for 4-STABLE which people can just > extract and compile a new kernel with? Hmm, no. I should probably generate one. However, I do have the miibus.ko and if_fxp.ko binary modules for 4-STABLE, if you want to just drop those in a system and use it. http://www.flugsvamp.com/~jlemon/fbsd/drivers/ -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 7:51:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 14AC837B718 for ; Wed, 14 Mar 2001 07:51:29 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f2EFoYG19947; Wed, 14 Mar 2001 07:50:34 -0800 (PST) Message-ID: <3AAF934A.2D63C08A@isi.edu> Date: Wed, 14 Mar 2001 07:50:34 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: Brian Somers Cc: net@FreeBSD.ORG Subject: Re: Changing UDP select() behavior References: <200103140106.f2E161a09824@hak.lan.Awfulhak.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF966CAFD2A242213BA8FB589" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------msF966CAFD2A242213BA8FB589 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian Somers wrote: > Having said this, it would be nice if it was possible to pre-allocate > (a small number of) mbufs for a pipe() or socketpair(), giving a > reliable SOCK_DGRAM file-descriptor based ipc mechanism. We're talking Internet here, so it won't be reliable. It'd just block the select/write instead of dropping packets on the floor locally if there is no queue space. Mbufs are not the scare resource, queue space in the interface queue is. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------msF966CAFD2A242213BA8FB589 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMxNDE1NTAzNFowIwYJKoZIhvcNAQkEMRYE FB9QSTJeWUPzc2lbQBqbSV3cpiCRMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAqU/pz2fuOxHTcUsnDnmHxBuhBk+TUOXegRvEHoD1PGCgP+FqfkDw ZhJU1hTofC/N2E0cOkHGBbdA8IaMwM+gnG2hfW3CALeyHUF/hWsjvwHWJt9HjwuppmMU3Ncd SVSK0L8kjlCUgHJA2aRFQxZBUS2nVEqZEmWN2YVpBAlSBaA= --------------msF966CAFD2A242213BA8FB589-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 7:55: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 265C937B718 for ; Wed, 14 Mar 2001 07:55:02 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f2EFt0G20752; Wed, 14 Mar 2001 07:55:00 -0800 (PST) Message-ID: <3AAF9453.C4E07BE4@isi.edu> Date: Wed, 14 Mar 2001 07:54:59 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: Garrett Wollman Cc: net@FreeBSD.ORG Subject: Re: Changing UDP select() behavior References: <3AAEBEAE.F823CB8E@isi.edu> <200103140156.UAA42646@khavrinen.lcs.mit.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE15C34F4304A3053B630D998" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------msE15C34F4304A3053B630D998 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Garrett Wollman wrote: > > < said: > > > I'm considering changing this, so that a select-to-write on a UDP socket > > will block until queue space becomes available. > > Impossible. The only way to find out whether a packet (or set of > packets, or a fragment of a packet) would be successfully enqueued is > to try it. Even then there's no guarantee that it will get sent. > > (Actually, ``impossible'' is too strong -- we could restructure the > entire network stack to make it possible to speculatively send packets > just to support this change in select() semantics. It's merely > impractical.) You try to queue a packet, if fails, then you do things (e.g. use the UDP soscket buffer to keep it around until later). The trick is that you need to block with your network interface as a wait channel, and the dequeue loop needs to wakeup the sleepers when the queue is draining. I agree that it's not a trivial change, but I don't think it's impossible or impractical. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------msE15C34F4304A3053B630D998 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMxNDE1NTQ1OVowIwYJKoZIhvcNAQkEMRYE FKxjXvJWAhMj9Pj3OEpvAPa6oW0DMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAemv1JPWPw4Vy1/XNPpRZf3AJ6NUii/N7luYkgoCnTAAdS5b/wyJw 4nho0HBODLqKAXAfn2qfW6jgqBp5UDpksOi2kh2ielVdwI0c3YGU1ITx2jQbCw0cPKQCnBOV PNoo+sqwx5EGXV19PG51sUhgVKrc8oElIyBubWqHEs/Qc6c= --------------msE15C34F4304A3053B630D998-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 8: 6:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 2FB1437B719 for ; Wed, 14 Mar 2001 08:06:43 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f2EG6ZG22288; Wed, 14 Mar 2001 08:06:35 -0800 (PST) Message-ID: <3AAF970B.7A19438A@isi.edu> Date: Wed, 14 Mar 2001 08:06:35 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Changing UDP select() behavior References: <200103140639.HAA14416@info.iet.unipi.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4CE4311E37234E68B46B780A" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms4CE4311E37234E68B46B780A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > > > Hi, > > > > I'm wondering if anyone has ever considered modifying the UDP behavior with > > regard to selecting: > > > > Currently, writing to a UDP socket either enqueues packets in the interface > > queue (returning success), or drops them on the floor (returning ENOBUFS) > > if the queue is full. Selecting-to-write on a UDP socket always succeeds, > > never blocks. > > I think it would require some substantial change to the network > stack structure (basically to let your sockets sleep on an interface, > and being woken up when the queue drains). Exactly. > There are fairness and efficiency issues here, because the device > queue has so many "users" that the usual low-water/high-water > strategy might cause a blocked socket to starve forever, so you > might need to effectively block queueing if there are sockets > sleeping on a queue, maybe issue a wakeup() on every single > transmission when you have sockets waiting, and probably implement > some ordering (maybe as simple as FIFO) for the waiting sockets. I agree that these are definitly issues. However, I think UDP blocking may actually improve some of the fairness issues. Right now, if a process loops doing UDP writes without any application-level sleeping scheme on failed writes, your system becomes really loaded. UDP blocking would improve fairness in some sense by letting other processes run while the queue drains. As for efficiency, I agree that the per-packet send overhead will be larger. I'm not sure it'll be large enough to become a problem, though. > All in all I think this approach would only help a bit if > if you were allowed to queue in the socket buffer > (on which you can think of having some control, because you either > opened the fd yourself or you inherited it from some parent), > in addition to the device queue. Could you explain this a little more? I think I know where you're going with this, but I'm not sure :-) Thanks, Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms4CE4311E37234E68B46B780A Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMxNDE2MDYzNVowIwYJKoZIhvcNAQkEMRYE FO0zPH6DSBRI9eeFSJDo+oBFUdWiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAoXT8r85uaCxFjFFoXkBulaVm5dlH7XUNPHaG9FYvS38/6qA7L0qN wexFBo/fS7Wu62gDqiY5JiQpuxI5LR41wsW+xpn5+9PMP0gW64AE72YiIh0H42QNPI65YStd FDmeMthE1G+yicdOU8CwMioB6nwFGU5RE53McQM6oUgCL5Y= --------------ms4CE4311E37234E68B46B780A-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 8:22:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id C968A37B71D for ; Wed, 14 Mar 2001 08:22:39 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id RAA19510; Wed, 14 Mar 2001 17:22:52 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200103141622.RAA19510@info.iet.unipi.it> Subject: Re: Changing UDP select() behavior In-Reply-To: <3AAF970B.7A19438A@isi.edu> from Lars Eggert at "Mar 14, 2001 08:06:35 am" To: Lars Eggert Date: Wed, 14 Mar 2001 17:22:52 +0100 (CET) Cc: net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] 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 > As for efficiency, I agree that the per-packet send overhead will be > larger. I'm not sure it'll be large enough to become a problem, though. yes it is probably constant work to find the first sleeping socket on the queue and issue a wakeup. > > All in all I think this approach would only help a bit if > > if you were allowed to queue in the socket buffer > > (on which you can think of having some control, because you either > > opened the fd yourself or you inherited it from some parent), > > in addition to the device queue. > > Could you explain this a little more? I think I know where you're going > with this, but I'm not sure :-) i think i meant you want to buffer your overflowing packets in the socket buffer, and use them as an extension of the ipq. Basically once the interface queue is full, you create a list of socket buffers waiting for a transmit, then when a slot in the ifqueue becomes empty you fill it up with the next pkt from next the socket buffer without having to wakeup the process associated with it unless you pass the lowwater mark. But again, it is quite a bit of work to put all this code together, and you end up with something that other systems do not have so when you want to write portable code you still have to handle the old behaviour as well in userland. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 8:32:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 233B137B718 for ; Wed, 14 Mar 2001 08:32:51 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f2EGWiG26595; Wed, 14 Mar 2001 08:32:44 -0800 (PST) Message-ID: <3AAF9D2C.2A337CC8@isi.edu> Date: Wed, 14 Mar 2001 08:32:44 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: Changing UDP select() behavior References: <200103141622.RAA19510@info.iet.unipi.it> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE552710398391F6DD0E3E94C" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------msE552710398391F6DD0E3E94C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Luigi Rizzo wrote: > > > All in all I think this approach would only help a bit if > > > if you were allowed to queue in the socket buffer > > > (on which you can think of having some control, because you either > > > opened the fd yourself or you inherited it from some parent), > > > in addition to the device queue. > > > > Could you explain this a little more? I think I know where you're going > > with this, but I'm not sure :-) > > i think i meant you want to buffer your overflowing packets in the > socket buffer, and use them as an extension of the ipq. Basically > once the interface queue is full, you create a list of socket buffers > waiting for a transmit, then when a slot in the ifqueue becomes empty > you fill it up with the next pkt from next the socket buffer > without having to wakeup the process associated with it unless > you pass the lowwater mark. This is more elaborate that what I was proposing. I was only thinking about queueing one UDP packet per socket when blocking, so there are no socket buffer queueing issues. I think queueing more than one could be more problematic for some applications, since it might decouple the write call returning from the actual send time of the packet too much. It'd be interesting to make the number of packets allowed to be queued in a UDP socket buffer a parameter, though... > But again, it is quite a bit of work to put all this code together, > and you end up with something that other systems do not have so > when you want to write portable code you still have to handle > the old behaviour as well in userland. Yes. But we're talking research here :-) (E.g. once UDP blocking is there, I can use it to do other neat things in the networking stack...) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------msE552710398391F6DD0E3E94C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMxNDE2MzI0NFowIwYJKoZIhvcNAQkEMRYE FP8agwnwJCLryWHitUYEBiE1ZucAMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGABDIEPHWVe6Lh8TP8l64IhNjjdrSB2AoW1t0+bHeLvhEJFzLQpWqC tSbqkdYiRQTkoLQFjK2hueSnt9F9eI/AMVBUS2DupZdqOMoDOnWhCqfwO0PYAams3EYajOCq jF/4gvdfO6aR2HF9u6kl/wDc5DGR53Mi0469voPLjgKDR8E= --------------msE552710398391F6DD0E3E94C-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 8:56:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 734A637B718; Wed, 14 Mar 2001 08:56:33 -0800 (PST) (envelope-from ume@FreeBSD.org) Received: from localhost (IDENT:ZEFIK18BbQVa3WWArQKdsXtS3LK8dhUm18+9RVaXWkhhB7Rcgo5AjvKfwd/5CsXU@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.3/8.11.3/peace) with ESMTP/inet6 id f2EGrG304494; Thu, 15 Mar 2001 01:53:18 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Thu, 15 Mar 2001 01:53:16 +0900 (JST) Message-Id: <20010315.015316.85344842.ume@FreeBSD.org> To: alpha@FreeBSD.org, net@FreeBSD.org Subject: IPv4 address is not unsigned int From: Hajimu UMEMOTO X-Mailer: Mew version 1.95b97 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Mar_15_01:53:16_2001_677)--" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----Next_Part(Thu_Mar_15_01:53:16_2001_677)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I wish to close PR 9982. This PR suggests that IPv4 address is not unsigned int and fix it to 32bit long. So, I took in_addr_t changes from OpenBSD and made a patch. It may break binary compatibility on Alpha, where u_long is 64 bits but in_addr_t would still be 32 bits. It seems working well on my *Pentium* box. However, I have no 64 bits environment. Please review the changes. ----Next_Part(Thu_Mar_15_01:53:16_2001_677)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: in_addr_t.diff Content-Disposition: inline; filename="in_addr_t.diff" Index: include/arpa/inet.h =================================================================== RCS file: /home/ncvs/src/include/arpa/inet.h,v retrieving revision 1.11 diff -u -r1.11 inet.h --- include/arpa/inet.h 1999/08/27 23:45:00 1.11 +++ include/arpa/inet.h 2001/03/13 12:41:29 @@ -84,13 +84,13 @@ __BEGIN_DECLS int ascii2addr __P((int, const char *, void *)); char *addr2ascii __P((int, const void *, int, char *)); -unsigned long inet_addr __P((const char *)); +in_addr_t inet_addr __P((const char *)); int inet_aton __P((const char *, struct in_addr *)); -unsigned long inet_lnaof __P((struct in_addr)); -struct in_addr inet_makeaddr __P((u_long , u_long)); -char * inet_neta __P((u_long, char *, size_t)); -unsigned long inet_netof __P((struct in_addr)); -unsigned long inet_network __P((const char *)); +in_addr_t inet_lnaof __P((struct in_addr)); +struct in_addr inet_makeaddr __P((in_addr_t, in_addr_t)); +char * inet_neta __P((in_addr_t, char *, size_t)); +in_addr_t inet_netof __P((struct in_addr)); +in_addr_t inet_network __P((const char *)); char *inet_net_ntop __P((int, const void *, int, char *, size_t)); int inet_net_pton __P((int, const char *, void *, size_t)); char *inet_ntoa __P((struct in_addr)); Index: lib/libc/net/inet.3 =================================================================== RCS file: /home/ncvs/src/lib/libc/net/inet.3,v retrieving revision 1.11 diff -u -r1.11 inet.3 --- lib/libc/net/inet.3 2000/12/29 14:08:00 1.11 +++ lib/libc/net/inet.3 2001/03/13 12:41:29 @@ -55,9 +55,9 @@ .Fd #include .Ft int .Fn inet_aton "const char *cp" "struct in_addr *pin" -.Ft unsigned long +.Ft in_addr_t .Fn inet_addr "const char *cp" -.Ft unsigned long +.Ft in_addr_t .Fn inet_network "const char *cp" .Ft char * .Fn inet_ntoa "struct in_addr in" @@ -66,10 +66,10 @@ .Ft int .Fn inet_pton "int af" "const char *src" "void *dst" .Ft struct in_addr -.Fn inet_makeaddr "unsigned long net" "unsigned long lna" -.Ft unsigned long +.Fn inet_makeaddr "in_addr_t net" "in_addr_t lna" +.Ft in_addr_t .Fn inet_lnaof "struct in_addr in" -.Ft unsigned long +.Ft in_addr_t .Fn inet_netof "struct in_addr in" .Sh DESCRIPTION The routines Index: lib/libc/net/inet_addr.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/inet_addr.c,v retrieving revision 1.12 diff -u -r1.12 inet_addr.c --- lib/libc/net/inet_addr.c 1999/12/27 08:40:40 1.12 +++ lib/libc/net/inet_addr.c 2001/03/13 12:41:29 @@ -72,7 +72,7 @@ * ASCII internet address interpretation routine. * The value returned is in network order. */ -u_long /* XXX should be struct in_addr :( */ +in_addr_t /* XXX should be struct in_addr :( */ inet_addr(cp) register const char *cp; { @@ -96,7 +96,7 @@ struct in_addr *addr; { u_long parts[4]; - u_long val; + in_addr_t val; char *c; char *endptr; int gotend, n; Index: lib/libc/net/inet_lnaof.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/inet_lnaof.c,v retrieving revision 1.2 diff -u -r1.2 inet_lnaof.c --- lib/libc/net/inet_lnaof.c 1998/09/02 00:53:16 1.2 +++ lib/libc/net/inet_lnaof.c 2001/03/13 12:41:29 @@ -44,11 +44,11 @@ * internet address; handles class a/b/c network * number formats. */ -u_long +in_addr_t inet_lnaof(in) struct in_addr in; { - register u_long i = ntohl(in.s_addr); + register in_addr_t i = ntohl(in.s_addr); if (IN_CLASSA(i)) return ((i)&IN_CLASSA_HOST); Index: lib/libc/net/inet_makeaddr.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/inet_makeaddr.c,v retrieving revision 1.2 diff -u -r1.2 inet_makeaddr.c --- lib/libc/net/inet_makeaddr.c 1998/09/02 00:53:17 1.2 +++ lib/libc/net/inet_makeaddr.c 2001/03/13 12:41:29 @@ -45,9 +45,9 @@ */ struct in_addr inet_makeaddr(net, host) - u_long net, host; + in_addr_t net, host; { - u_long addr; + in_addr_t addr; if (net < 128) addr = (net << IN_CLASSA_NSHIFT) | (host & IN_CLASSA_HOST); Index: lib/libc/net/inet_neta.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/inet_neta.c,v retrieving revision 1.6 diff -u -r1.6 inet_neta.c --- lib/libc/net/inet_neta.c 1999/08/28 00:00:11 1.6 +++ lib/libc/net/inet_neta.c 2001/03/13 12:41:29 @@ -38,7 +38,7 @@ /* * char * * inet_neta(src, dst, size) - * format a u_long network number into presentation format. + * format a in_addr_t network number into presentation format. * return: * pointer to dst, or NULL if an error occurred (check errno). * note: @@ -48,7 +48,7 @@ */ char * inet_neta(src, dst, size) - u_long src; + in_addr_t src; char *dst; size_t size; { Index: lib/libc/net/inet_netof.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/inet_netof.c,v retrieving revision 1.2 diff -u -r1.2 inet_netof.c --- lib/libc/net/inet_netof.c 1998/09/02 00:53:17 1.2 +++ lib/libc/net/inet_netof.c 2001/03/13 12:41:29 @@ -43,11 +43,11 @@ * Return the network number from an internet * address; handles class a/b/c network #'s. */ -u_long +in_addr_t inet_netof(in) struct in_addr in; { - register u_long i = ntohl(in.s_addr); + register in_addr_t i = ntohl(in.s_addr); if (IN_CLASSA(i)) return (((i)&IN_CLASSA_NET) >> IN_CLASSA_NSHIFT); Index: lib/libc/net/inet_network.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/inet_network.c,v retrieving revision 1.6 diff -u -r1.6 inet_network.c --- lib/libc/net/inet_network.c 1999/11/04 04:30:44 1.6 +++ lib/libc/net/inet_network.c 2001/03/13 12:41:29 @@ -47,13 +47,14 @@ * The library routines call this routine to interpret * network numbers. */ -u_long +in_addr_t inet_network(cp) register const char *cp; { - register u_long val, base, n, i; + register in_addr_t val, base, n; register char c; - u_long parts[4], *pp = parts; + in_addr_t parts[4], *pp = parts; + register int i; again: val = 0; base = 10; Index: sys/netinet/in.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.h,v retrieving revision 1.53 diff -u -r1.53 in.h --- sys/netinet/in.h 2001/02/21 06:39:56 1.53 +++ sys/netinet/in.h 2001/03/13 12:41:29 @@ -232,7 +232,7 @@ * Internet address (a structure for historical reasons) */ struct in_addr { - u_int32_t s_addr; + in_addr_t s_addr; }; /* Index: sys/sys/types.h =================================================================== RCS file: /home/ncvs/src/sys/sys/types.h,v retrieving revision 1.41 diff -u -r1.41 types.h --- sys/sys/types.h 2000/10/27 11:45:49 1.41 +++ sys/sys/types.h 2001/03/13 12:41:30 @@ -73,6 +73,7 @@ typedef u_int32_t u_daddr_t; /* unsigned disk address */ typedef u_int32_t fixpt_t; /* fixed point number */ typedef u_int32_t gid_t; /* group id */ +typedef u_int32_t in_addr_t; /* base type for internet address */ typedef u_int32_t ino_t; /* inode number */ typedef long key_t; /* IPC key (for Sys V IPC) */ typedef u_int16_t mode_t; /* permissions */ ----Next_Part(Thu_Mar_15_01:53:16_2001_677)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: My Signature Content-Disposition: inline; filename=".signature-world" Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ ----Next_Part(Thu_Mar_15_01:53:16_2001_677)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 9: 0:34 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 29A8E37B719; Wed, 14 Mar 2001 09:00:30 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA49232; Wed, 14 Mar 2001 12:00:29 -0500 (EST) (envelope-from wollman) Date: Wed, 14 Mar 2001 12:00:29 -0500 (EST) From: Garrett Wollman Message-Id: <200103141700.MAA49232@khavrinen.lcs.mit.edu> To: Hajimu UMEMOTO Cc: alpha@FreeBSD.ORG, net@FreeBSD.ORG Subject: IPv4 address is not unsigned int In-Reply-To: <20010315.015316.85344842.ume@FreeBSD.org> References: <20010315.015316.85344842.ume@FreeBSD.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > +in_addr_t inet_lnaof __P((struct in_addr)); > +struct in_addr inet_makeaddr __P((in_addr_t, in_addr_t)); > +in_addr_t inet_netof __P((struct in_addr)); If anything, these interfaces should be removed. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 9: 3:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 2C5C837B718 for ; Wed, 14 Mar 2001 09:03:11 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 14 Mar 2001 17:03:10 +0000 (GMT) To: freebsd-net@freebsd.org Subject: UDP datagram max size. X-Request-Do: Date: Wed, 14 Mar 2001 17:03:10 +0000 From: David Malone Message-ID: <200103141703.aa78458@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to figure out what #define I should use for the largest UDP datagram. The header files don't seem to define a constant for this. The correct size would seem to be 65535 'cos there are two bytes in the UDP header for the size. IP_MAXPACKET and IPV6_MAXPACKET are available and have the right values, but these don't really seem to be the correct thing to use 'cos they don't take headers or the possibility Jumbo payload into account. I wanted to commit something for: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25050 but I'm not convinced that the patch is spot on. I could determine the data size and malloc memory dynamically I guess. David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 9:16: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 486EE37B718 for ; Wed, 14 Mar 2001 09:15:57 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f2EHFnG03777; Wed, 14 Mar 2001 09:15:49 -0800 (PST) Message-ID: <3AAFA745.AA3EC6B6@isi.edu> Date: Wed, 14 Mar 2001 09:15:49 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: David Malone Cc: freebsd-net@freebsd.org Subject: Re: UDP datagram max size. References: <200103141703.aa78458@salmon.maths.tcd.ie> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0617D6FE6914F636D4A0402D" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms0617D6FE6914F636D4A0402D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Malone wrote: > > I'm trying to figure out what #define I should use for the largest > UDP datagram. The header files don't seem to define a constant for > this. The correct size would seem to be 65535 'cos there are two > bytes in the UDP header for the size. > > IP_MAXPACKET and IPV6_MAXPACKET are available and have the right > values, but these don't really seem to be the correct thing to use > 'cos they don't take headers or the possibility Jumbo payload into > account. To support jumbograms, I don't think you'll get around dynamic memory allocation. (There is no reasonable upper bound for the buffer size.) However, RFC2675 says: The Jumbo Payload option is relevant only for IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets (that is, 65,535 + 40, where 40 octets is the size of the IPv6 header). The Jumbo Payload option need not be implemented or understood by IPv6 nodes that do not support attachment to links with MTU greater than 65,575. So it may be okay to punt on jumbograms for now, and use a 64K static buffer like the patch in the PR does. Even if you do implement support for jumbograms, I think keeping the 64K static buffer around as a "fast-path" for the common case makes sense. > I wanted to commit something for: > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25050 > > but I'm not convinced that the patch is spot on. I could determine > the data size and malloc memory dynamically I guess. -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms0617D6FE6914F636D4A0402D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMxNDE3MTU0OVowIwYJKoZIhvcNAQkEMRYE FHLP6eoXC7D8ZrN7h4FFHMTEJLlOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAEGJv8+u4kuhea6i4SLQHsXOXBtFJ4/YA9xftFu/O7m8fOU9HDfmI nVP8Y6BIQ0Vaxuj4nIF9LfisAVtFUTcqbGVRV4KZ+w54RomXfNufgCjJzLsuzxN2xhXVbQcH UDgS7EWOsPUToN+EBt/N+aZ+xbfMsDjiS/WjHAxTohlMVF0= --------------ms0617D6FE6914F636D4A0402D-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 9:20:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 4A74437B71A for ; Wed, 14 Mar 2001 09:20:09 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 14 Mar 2001 17:20:08 +0000 (GMT) To: Lars Eggert Cc: freebsd-net@freebsd.org Subject: Re: UDP datagram max size. In-reply-to: Your message of "Wed, 14 Mar 2001 09:15:49 PST." <3AAFA745.AA3EC6B6@isi.edu> X-Request-Do: Date: Wed, 14 Mar 2001 17:20:07 +0000 From: David Malone Message-ID: <200103141720.aa85840@salmon.maths.tcd.ie> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > So it may be okay to punt on jumbograms for now, and use a 64K static > buffer like the patch in the PR does. Even if you do implement support for > jumbograms, I think keeping the 64K static buffer around as a "fast-path" > for the common case makes sense. Does it talk about how jumbograms will apply to UDP? I suspect the max udp data size might be unchanged anyway... The problem remains even if I punt on jumbograms though, how should I spell 65536? David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 9:25:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 67C7737B719 for ; Wed, 14 Mar 2001 09:25:43 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f2EHPeG05260; Wed, 14 Mar 2001 09:25:40 -0800 (PST) Message-ID: <3AAFA994.8E7626F6@isi.edu> Date: Wed, 14 Mar 2001 09:25:40 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: David Malone Cc: freebsd-net@freebsd.org Subject: Re: UDP datagram max size. References: <200103141720.aa85840@salmon.maths.tcd.ie> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8B1185566CE722CBF24A37C2" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms8B1185566CE722CBF24A37C2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Malone wrote: > Does it talk about how jumbograms will apply to UDP? I suspect the > max udp data size might be unchanged anyway... It does (see below). And it does allow UDP packet with more than 64K of data. ftp://ftp.isi.edu/in-notes/rfc2675.txt 4. UDP Jumbograms The 16-bit Length field of the UDP header limits the total length of a UDP packet (that is, a UDP header plus data) to no greater than 65,535 octets. This document specifies the following modification of UDP to relax that limit: UDP packets longer than 65,535 octets may be sent by setting the UDP Length field to zero, and letting the receiver derive the actual UDP packet length from the IPv6 payload length. (Note that, prior to this modification, zero was not a legal value for the UDP Length field, because the UDP packet length includes the UDP header and therefore has a minimum value of 8.) The specific requirements for sending a UDP jumbogram are as follows: When sending a UDP packet, if and only if the length of the UDP header plus UDP data is greater than 65,535, set the Length field in the UDP header to zero. The IPv6 packet carrying such a large UDP packet will necessarily include a Jumbo Payload option in a Hop-by-Hop Options header; set the Jumbo Payload Length field of that option to be the actual length of the UDP header plus data, plus the length of all IPv6 extension headers present between the IPv6 header and the UDP header. For generating the UDP checksum, use the actual length of the UDP header plus data, NOT zero, in the checksum pseudo-header [IPv6, Section 8.1]. The specific requirements for receiving a UDP jumbogram are as follows: When receiving a UDP packet, if and only if the Length field in the UDP header is zero, calculate the actual length of the UDP header plus data from the IPv6 Jumbo Payload Length field minus the length of all extension headers present between the IPv6 header and the UDP header. In the unexpected case that the UDP Length field is zero but no Jumbo Payload option is present (i.e., the IPv6 packet is not a jumbogram), use the Payload Length field in the IPv6 header, in place of the Jumbo Payload Length field, in the above calculation. For verifying the received UDP checksum, use the calculated length of the UDP header plus data, NOT zero, in the checksum pseudo- header. > The problem remains even if I punt on jumbograms though, how should > I spell 65536? The max. possible UDP data length is max. IP packet size - minimum IP header length (w/o options) - UDP header length? Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms8B1185566CE722CBF24A37C2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMxNDE3MjU0MFowIwYJKoZIhvcNAQkEMRYE FL8zj9/OmwRQci7qtEhDRnPq/ePcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAssmd6cIEd1PBMEMt3JNRfSHmhJdbQTjH/TPLdauueMa6y5syiv8B qIR4pzAxjXAsIwYXxjEBViZ1TrA1PXsfLEoID+J5KyEBn8wr6bc9r+6KwfJqLodbLJ5EQZyr oOMhQJI9JUI9tlOenSjcb3PAdyJ0/cXMKQRKbpP3pgJDvtU= --------------ms8B1185566CE722CBF24A37C2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 9:49:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from sleepy.itsco.com (sleepy.itsco.com [216.27.47.11]) by hub.freebsd.org (Postfix) with SMTP id DDD1E37B718 for ; Wed, 14 Mar 2001 09:49:22 -0800 (PST) (envelope-from bvoltz@itsco.com) Received: by sleepy.itsco.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Mar 2001 12:49:17 -0500 Message-ID: <41E533716110D511BF0300805FCC206001331F@happy.itsco.com> From: Brent Voltz To: "'freebsd-net@freebsd.org'" Subject: Problems with ADSL and MPD PPPoE Date: Wed, 14 Mar 2001 12:50:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I am currently attempting to get PPPoE working using MPD on 4.2-Release. I'm talking to an Alcatel 1000. I can get connected using PPP and a tun interface, but I'm having no luck with MPD. The log file shows this: mpd: pid 202, version 3.2 (root@bsd 21:32 11-Mar-2001) [PPPoE] ppp node is "mpd202-PPPoE" [PPPoE] using interface ng0 [PPPoE] IPCP: peer address cannot be zero [PPPoE] IFACE: Open event [PPPoE] IPCP: Open event [PPPoE] IPCP: state change Initial --> Starting [PPPoE] IPCP: LayerStart [PPPoE:PPPoE] [PPPoE] bundle: OPEN event in state CLOSED [PPPoE] opening link "PPPoE"... [PPPoE] link: OPEN event [PPPoE] LCP: Open event [PPPoE] LCP: state change Initial --> Starting [PPPoE] LCP: LayerStart [PPPoE] device: OPEN event in state DOWN [PPPoE] exec: /sbin/ifconfig fxp1 up [PPPoE] can't create pppoe peer to fxp1:,orphans: No such file or directory [PPPoE] device is now in state OPENING [PPPoE] device: DOWN event in state OPENING [PPPoE] device is now in state DOWN [PPPoE] link: DOWN event [PPPoE] LCP: Down event I used the sample config files, edited with my username, password, ethernet interface, etc. Can anyone tell me what is failing? -- Brent Voltz Integrated Technical Services www.itsco.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 10: 1:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from amc.isi.edu (amc.isi.edu [128.9.160.102]) by hub.freebsd.org (Postfix) with ESMTP id 2938537B71C for ; Wed, 14 Mar 2001 10:01:21 -0800 (PST) (envelope-from yushunwa@amc.isi.edu) Received: from localhost (yushunwa@localhost) by amc.isi.edu (8.11.1/8.11.1) with ESMTP id f2EI1Gs03055; Wed, 14 Mar 2001 10:01:16 -0800 (PST) (envelope-from yushunwa@amc.isi.edu) Date: Wed, 14 Mar 2001 10:01:16 -0800 (PST) From: Yu-Shun Wang To: Jeroen Ruigrok/Asmodai Cc: Subject: Re: Strong vs. Weak ES models? In-Reply-To: <20010314135930.D74704@daemon.ninth-circle.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 Hi, The current FreeBSD (or all BSD IP stacks) implements Weak End System model as described in RFC 1122. And as Jonathan pointed out, there is a switch similar to but not completely does the Strong ES model called net.inet.ip.check_interface, but it's in either -stable or -current. Probably will be included in FreeBSD 4.3. regards, yushun. On Wed, 14 Mar 2001, Jeroen Ruigrok/Asmodai wrote: > Hi Yu-Shun, > > -On [20010308 22:05], Yu-Shun Wang (yushunwa@isi.edu) wrote: > > Has the topic of Strong/Weak ES model been discussed here? > > Please give me a pointer if the topic has been debated. > > In what sense discussed? What type we are? What we support? > > > I was wondering if there's a sysctl switch (like > > net.inet.ip.strongendsystem mentioned in NetBSD list) > > implemented in FreeBSD. > > Not as far as I know. > > -- > Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] > Documentation nutter/C-rated Coder BSD: Technical excellence at its best > D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 > Religion... Is the opium of the people... > > 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 Mar 14 10:10: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (ebola.biohz.net [206.80.1.35]) by hub.freebsd.org (Postfix) with ESMTP id 0502037B719; Wed, 14 Mar 2001 10:09:53 -0800 (PST) (envelope-from renaud@waldura.org) Received: from renaud (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 75F3A3A4D4; Wed, 14 Mar 2001 10:09:52 -0800 (PST) Message-ID: <002d01c0acb1$f7747fd0$3902010a@zerog.int> From: "Renaud Waldura" To: "Paul Armor" Cc: , References: <200103130129.f2D1TkB08101@hak.lan.Awfulhak.org> Subject: Re: PPPoE Date: Wed, 14 Mar 2001 10:09:52 -0800 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'll second that. Upgrade your ppp, set enable tcpmssfixup (or not, I believe it's on by default) in /etc/ppp/ppp.conf and you're all set. ----- Original Message ----- From: "Brian Somers" To: "Paul Armor" Cc: ; ; Sent: Monday, March 12, 2001 5:29 PM Subject: Re: PPPoE > If you upgrade to the latest version of ppp(8) (you can get an > archive from http://www.Awfulhak.org/ppp.html) the problem should go > away. ppp(8) now fixes this stuff itself (look for mssfixup in the > man page). > > > Okay, I feel stupid... > > > > I've got a 4.2 Release box set up as a firewall with some clients behind it. > > I'm using my BSD box as PPPoE client. My problem is the "win clients can't > > get to certain web sites" issue, I've verified by sending large ping packet > > from outside and it gets lost between tun0 and internal interface. I've > > tried the tcpmssd.rc stuff, but have not been able to get it working > > properly (all packets hit the divert rule, but drop somewhere inside). Can > > anyone suggest anything? > > > > Here are various details... > > 4.2 release > > > > options NETGRAPH > > options NETGRAPH_ETHER > > options NETGRAPH_PPPOE > > options NETGRAPH_SOCKET > > In kernel > > > > myprofile: > > set device PPPoE:fxp0 > > set mru 1492 > > set mtu 1492 > > set authname XXXXXX > > set authkey XXXXXX > > set log Phase tun command > > set dial > > set login > > set ifaddr /net /net > > add default HISADDR > > In ppp.conf > > > > network_interfaces="auto" > > ifconfig_fxp0="up" > > ppp_enable="YES" > > ppp_mode="dedicated" > > ppp_nat="NO" > > ppp_profile="myprofile" > > ifconfig_fxp1="inet netmask " > > ifconfig_tun0="inet 0.0.0.0 netmask " > > > > > > Thanks in advance for ANY help!!! > > -- > 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 Wed Mar 14 10:21:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from mymlan.lifix.fi (mymlan.lifix.fi [195.197.211.98]) by hub.freebsd.org (Postfix) with ESMTP id 9764937B71C; Wed, 14 Mar 2001 10:21:07 -0800 (PST) (envelope-from ban@lifix.fi) Received: from ban by mymlan.lifix.fi with local id 14dF1v-0004t1-00; Wed, 14 Mar 2001 19:25:47 +0200 Date: Wed, 14 Mar 2001 19:25:47 +0200 From: Bjorn Andersson To: Guangrui Fu Cc: mobile-ip , freebsd-net , freebsd-mobile Subject: Re: Mobile IP implementation for FreeBSD Message-ID: <20010314192547.B18619@mymlan.lifix.fi> Mail-Followup-To: Bjorn Andersson , Guangrui Fu , mobile-ip , freebsd-net , freebsd-mobile References: <20010313224837.21080.qmail@web3102.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20010313224837.21080.qmail@web3102.mail.yahoo.com>; from guangruifu@yahoo.com on Tue, Mar 13, 2001 at 02:48:37PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Mar 13 2001, at 14:48:37 -0800, Guangrui Fu wrote: > I'm looking for open-sourced Mobile IP implementation > on FreeBSD. Could anyone please give me some > information? Check out the Monarch Project: http://www.monarch.cs.cmu.edu/ Björn -- Björn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 11: 4:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from gollum.esys.ca (dhcp198-52.esys.ca [198.161.92.52]) by hub.freebsd.org (Postfix) with ESMTP id 08D5737B71C; Wed, 14 Mar 2001 11:04:23 -0800 (PST) (envelope-from lyndon@gollum.esys.ca) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.3/8.11.3) with ESMTP id f2EJ48c09287; Wed, 14 Mar 2001 12:04:08 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200103141904.f2EJ48c09287@gollum.esys.ca> From: Lyndon Nerenberg Organization: ACI / Messagingdirect X-URL: http://www.messagingdirect.com/ To: Bjorn Andersson Cc: mobile-ip , freebsd-net , freebsd-mobile Subject: Re: Mobile IP implementation for FreeBSD In-Reply-To: Message from Bjorn Andersson of "Wed, 14 Mar 2001 19:25:47 +0200." <20010314192547.B18619@mymlan.lifix.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9284.984596647.1@localhost> Date: Wed, 14 Mar 2001 12:04:08 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I'm looking for open-sourced Mobile IP implementation > > on FreeBSD. > Check out the Monarch Project: > http://www.monarch.cs.cmu.edu/ This supports FreeBSD 2.2.x, which is long dead. (And this was the case for the other mobile ip implementations I tracked down.) Is anyone working on this for a current version of FreeBSD (4.x) ? --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 11:17: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 8D15637B719; Wed, 14 Mar 2001 11:16:54 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA16832; Wed, 14 Mar 2001 12:16:34 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id MAA25818; Wed, 14 Mar 2001 12:16:34 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15023.50066.334891.956685@nomad.yogotech.com> Date: Wed, 14 Mar 2001 12:16:34 -0700 (MST) To: Lyndon Nerenberg Cc: Bjorn Andersson , mobile-ip , freebsd-net , freebsd-mobile Subject: Re: Mobile IP implementation for FreeBSD In-Reply-To: <200103141904.f2EJ48c09287@gollum.esys.ca> References: <20010314192547.B18619@mymlan.lifix.fi> <200103141904.f2EJ48c09287@gollum.esys.ca> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I'm looking for open-sourced Mobile IP implementation > > > on FreeBSD. > > > Check out the Monarch Project: > > http://www.monarch.cs.cmu.edu/ > > This supports FreeBSD 2.2.x, which is long dead. FreeBSD's networking stack isn't that much different from FreeBSD 2.X (or for that matter FreeBSD 1.X) to what it is now. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 11:19:47 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 B32F737B71C for ; Wed, 14 Mar 2001 11:19:43 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA37236; Wed, 14 Mar 2001 14:19:28 -0500 (EST) (envelope-from wollman) Date: Wed, 14 Mar 2001 14:19:28 -0500 (EST) From: Garrett Wollman Message-Id: <200103141919.OAA37236@khavrinen.lcs.mit.edu> To: nate@yogotech.com (Nate Williams) Cc: mobile-ip , freebsd-net Subject: Re: Mobile IP implementation for FreeBSD In-Reply-To: <15023.50066.334891.956685@nomad.yogotech.com> References: <20010314192547.B18619@mymlan.lifix.fi> <200103141904.f2EJ48c09287@gollum.esys.ca> <15023.50066.334891.956685@nomad.yogotech.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > FreeBSD's networking stack isn't that much different from FreeBSD 2.X > (or for that matter FreeBSD 1.X) to what it is now. More than you would think. It's not different in design, but there are enough new excrescences to require manual application of almost any nontrivial patch. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 11:21:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 78E1037B718 for ; Wed, 14 Mar 2001 11:21:15 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA16941; Wed, 14 Mar 2001 12:21:00 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id MAA25894; Wed, 14 Mar 2001 12:21:00 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15023.50331.644845.741506@nomad.yogotech.com> Date: Wed, 14 Mar 2001 12:20:59 -0700 (MST) To: Garrett Wollman Cc: nate@yogotech.com (Nate Williams), mobile-ip , freebsd-net Subject: Re: Mobile IP implementation for FreeBSD In-Reply-To: <200103141919.OAA37236@khavrinen.lcs.mit.edu> References: <20010314192547.B18619@mymlan.lifix.fi> <200103141904.f2EJ48c09287@gollum.esys.ca> <15023.50066.334891.956685@nomad.yogotech.com> <200103141919.OAA37236@khavrinen.lcs.mit.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > FreeBSD's networking stack isn't that much different from FreeBSD 2.X > > (or for that matter FreeBSD 1.X) to what it is now. > > More than you would think. It's not different in design, but there > are enough new excrescences to require manual application of almost > any nontrivial patch. Oh, I agree. But, the work required to merge in patches from old systems don't require a networking guru to apply them. However, that person certainly requires a working knowledge of programming. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 12: 9:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from gollum.esys.ca (dhcp198-52.esys.ca [198.161.92.52]) by hub.freebsd.org (Postfix) with ESMTP id 074F937B718 for ; Wed, 14 Mar 2001 12:09:34 -0800 (PST) (envelope-from lyndon@gollum.esys.ca) Received: from localhost (localhost [127.0.0.1]) by gollum.esys.ca (8.11.3/8.11.3) with ESMTP id f2EK9Xc11445 for ; Wed, 14 Mar 2001 13:09:33 -0700 (MST) (envelope-from lyndon@gollum.esys.ca) Message-Id: <200103142009.f2EK9Xc11445@gollum.esys.ca> From: Lyndon Nerenberg Organization: ACI / Messagingdirect X-URL: http://www.messagingdirect.com/ To: freebsd-net Subject: Re: Mobile IP implementation for FreeBSD In-Reply-To: Message from Nate Williams of "Wed, 14 Mar 2001 12:20:59 MST." <15023.50331.644845.741506@nomad.yogotech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11442.984600572.1@localhost> Date: Wed, 14 Mar 2001 13:09:33 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So what are the odds of getting this code incorporated into -current? Is this something that's in KAMEs realm of responsibility? (From what I've been able to track down, they aren't doing much active development of mobile ip right now.) --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 12:18:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 98ACB37B719 for ; Wed, 14 Mar 2001 12:18:20 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f2EKI3084227; Wed, 14 Mar 2001 22:18:03 +0200 (EET) (envelope-from ru) Date: Wed, 14 Mar 2001 22:18:03 +0200 From: Ruslan Ermilov To: David Malone Cc: freebsd-net@FreeBSD.ORG Subject: Re: UDP datagram max size. Message-ID: <20010314221803.A80894@sunbay.com> Mail-Followup-To: David Malone , freebsd-net@FreeBSD.ORG References: <200103141703.aa78458@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103141703.aa78458@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Wed, Mar 14, 2001 at 05:03:10PM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Mar 14, 2001 at 05:03:10PM +0000, David Malone wrote: > I'm trying to figure out what #define I should use for the largest > UDP datagram. The header files don't seem to define a constant for > this. The correct size would seem to be 65535 'cos there are two > bytes in the UDP header for the size. > > IP_MAXPACKET and IPV6_MAXPACKET are available and have the right > values, but these don't really seem to be the correct thing to use > 'cos they don't take headers or the possibility Jumbo payload into > account. > > I wanted to commit something for: > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25050 > > but I'm not convinced that the patch is spot on. I could determine > the data size and malloc memory dynamically I guess. > The maximum size of IPv4 UDP datagram is 65535-28=65507: IP_MAXPACKET - sizeof(struct ip) - sizeof(struct udp) provided that the send/receive buffers were set appropriately: : tcpdump: listening on lo0 : 127.0.0.1.49431 > 127.0.0.1.1: udp 65507 (frag 7691:16360@0+) : 127.0.0.1 > 127.0.0.1: (frag 7691:16360@16360+) : 127.0.0.1 > 127.0.0.1: (frag 7691:16360@32720+) : 127.0.0.1 > 127.0.0.1: (frag 7691:16360@49080+) : 127.0.0.1 > 127.0.0.1: (frag 7691:75@65440) -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 12:26:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by hub.freebsd.org (Postfix) with ESMTP id 2184537B718; Wed, 14 Mar 2001 12:26:08 -0800 (PST) (envelope-from krepel@fokus.gmd.de) Received: from fokus.gmd.de (dial-05 [193.174.152.250]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA08733; Wed, 14 Mar 2001 21:25:58 +0100 (MET) Message-ID: <3AAFD3DB.6381F3C9@fokus.gmd.de> Date: Wed, 14 Mar 2001 21:26:08 +0100 From: Falco Reply-To: krepel@fokus.gmd.de X-Mailer: Mozilla 4.76 (Macintosh; U; PPC) X-Accept-Language: en,de MIME-Version: 1.0 To: itojun@iijlab.net Cc: mobile-ip , freebsd-net , freebsd-mobile Subject: Re: Mobile IP implementation for FreeBSD References: <23798.984574232@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Perhaps you have allready find this: http://www.mobile-ip.de Some Links, but no for FreeBSD 4.x. But if you find an implementation there you could test it. Falco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 12:33:42 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 8340D37B719 for ; Wed, 14 Mar 2001 12:33:39 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 414ED81D01; Wed, 14 Mar 2001 14:33:39 -0600 (CST) Date: Wed, 14 Mar 2001 14:33:39 -0600 From: Bill Fumerola To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: problem with secondary dns update through ipfw firewall Message-ID: <20010314143339.R31752@elvis.mu.org> References: <20010314001619.O31752@elvis.mu.org> <000701c0ac9a$978cc4e0$46010a0a@wkst> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000701c0ac9a$978cc4e0$46010a0a@wkst>; from peter@sysadmin-inc.com on Wed, Mar 14, 2001 at 10:22:32AM -0500 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Mar 14, 2001 at 10:22:32AM -0500, Peter Brezny wrote: > Bill, > I do have a list? ... Which list is that? > > I think the light bulb is begining to glow, dimly but still glow. I guess I > only have to allow the root servers access? Is that what you mean? Typically you would want to allow queries from any addresses and zone transfers from secondary nameservers or from the primary nameservers that any of your servers secondary off of. > However I am still wondering why the firewall rules I have below arn't > allowing transfers, I do have an allow rule for established traffic, just > well above the rules below. > > $fwcmd add allow tcp from any to any established > > shouldn't this ruleset allow any DNS server to perform a transfer? a zone transfer, yes. that may or may not be what you want (but it can be controlled with named.conf as well if you just want simple ipfw rules) -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 14:51:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from cassie.foobarbaz.net (Cassie.FooBarBaz.NET [199.239.183.133]) by hub.freebsd.org (Postfix) with SMTP id A380037B718 for ; Wed, 14 Mar 2001 14:51:30 -0800 (PST) (envelope-from enkhyl@foobarbaz.net) Received: (qmail 33613 invoked by uid 1000); 14 Mar 2001 22:51:09 -0000 Date: Wed, 14 Mar 2001 14:51:09 -0800 From: Christopher Nielsen To: freebsd-net@FreeBSD.ORG Subject: Re: Intel PRO/100+ PCI problem Message-ID: <20010314145108.Q38002@cassie.foobarbaz.net> Reply-To: cnielsen@pobox.com Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <003901c0a7d7$91b465e0$6214b0c8@bohr> <20010314142847.E74704@daemon.ninth-circle.org> <20010314084757.Y78851@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010314084757.Y78851@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Wed, Mar 14, 2001 at 08:47:57AM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Mar 14, 2001 at 08:47:57AM -0600, Jonathan Lemon wrote: > On Wed, Mar 14, 2001 at 02:28:47PM +0100, Jeroen Ruigrok/Asmodai wrote: > > -On [20010308 22:02], Rafael Tonin (rafael.tonin@terra.com.br) wrote: > > >I'm having some problems on configuring my just purchased > > >Intel PRO/100+ PCI (reported by Intel as being P#: 689661-004). > > > > > >When booting, FreeBSD 4.2 reports: > > > > > >fxp0: at device 13.0 on pci0 > > >fxp0: could not map memory > > > > You might want to try the latest sources Jonathan Lemon [cc:'d] came up > > with. I've looked at the diffs and he did some nice cleanups to bring > > the driver into the present. This might also fix your problem. > > > > Jona, did you already have tarball for 4-STABLE which people can just > > extract and compile a new kernel with? > > Hmm, no. I should probably generate one. However, I do have the > miibus.ko and if_fxp.ko binary modules for 4-STABLE, if you want > to just drop those in a system and use it. > > http://www.flugsvamp.com/~jlemon/fbsd/drivers/ I have a -stable box with a pair of 82559s on the motherboard that I can use for testing, if you need/want testers for -stable. -- Christopher Nielsen - Metal-wielding pyro techie cnielsen@pobox.com "Any technology indistinguishable from magic is insufficiently advanced." --unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 17:21:35 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 8220937B718 for ; Wed, 14 Mar 2001 17:21:32 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f2F1IOa75456; Wed, 14 Mar 2001 19:18:24 -0600 (CST) (envelope-from jlemon) Date: Wed, 14 Mar 2001 19:18:24 -0600 (CST) From: Jonathan Lemon Message-Id: <200103150118.f2F1IOa75456@prism.flugsvamp.com> To: cnielsen@pobox.com, net@freebsd.org Subject: Re: Intel PRO/100+ PCI problem 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: >On Wed, Mar 14, 2001 at 08:47:57AM -0600, Jonathan Lemon wrote: >> On Wed, Mar 14, 2001 at 02:28:47PM +0100, Jeroen Ruigrok/Asmodai wrote: >> > -On [20010308 22:02], Rafael Tonin (rafael.tonin@terra.com.br) wrote: >> > >I'm having some problems on configuring my just purchased >> > >Intel PRO/100+ PCI (reported by Intel as being P#: 689661-004). >> > > >> > >When booting, FreeBSD 4.2 reports: >> > > >> > >fxp0: at device 13.0 on pci0 >> > >fxp0: could not map memory >> > >> > You might want to try the latest sources Jonathan Lemon [cc:'d] came up >> > with. I've looked at the diffs and he did some nice cleanups to bring >> > the driver into the present. This might also fix your problem. >> > >> > Jona, did you already have tarball for 4-STABLE which people can just >> > extract and compile a new kernel with? >> >> Hmm, no. I should probably generate one. However, I do have the >> miibus.ko and if_fxp.ko binary modules for 4-STABLE, if you want >> to just drop those in a system and use it. >> >> http://www.flugsvamp.com/~jlemon/fbsd/drivers/ > >I have a -stable box with a pair of 82559s on the motherboard >that I can use for testing, if you need/want testers for -stable. I've had a bunch of people test it already, thanks. However, I would still like to hear from someone whos card did not work before the driver was upgraded, but does work now. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 18:30:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from bear.mshindo.net (bear.mshindo.net [202.229.42.121]) by hub.freebsd.org (Postfix) with ESMTP id B4D1937B719; Wed, 14 Mar 2001 18:30:21 -0800 (PST) (envelope-from mshindo@mshindo.net) Received: from localhost (IDENT:mshindo@dhcp15.cosinecom.co.jp [202.229.42.15]) by bear.mshindo.net (8.11.1/8.11.1) with ESMTP id f2F2Mfn32999; Thu, 15 Mar 2001 11:22:41 +0900 (JST) (envelope-from mshindo@mshindo.net) Date: Thu, 15 Mar 2001 11:31:01 +0900 (JST) Message-Id: <20010315.113101.74755852.mshindo@mshindo.net> To: itojun@iijlab.net Cc: kris@obsecurity.org, guangruifu@yahoo.com, mobile-ip@sunroof.eng.sun.com, freebsd-net@FreeBSD.ORG, freebsd-mobile@FreeBSD.ORG Subject: Re: Mobile IP implementation for FreeBSD From: Motonori Shindo In-Reply-To: <23798.984574232@coconut.itojun.org> References: <20010314032219.A30923@mollari.cthul.hu> <23798.984574232@coconut.itojun.org> X-Mailer: Mew version 1.95b76 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-PGP-fingerprint: 06 B0 B1 A4 06 C1 6A 14 63 C0 D7 18 01 CD D9 83 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 Kris, From: itojun@iijlab.net Subject: Re: Mobile IP implementation for FreeBSD Date: Wed, 14 Mar 2001 21:50:32 +0900 Message-ID: <23798.984574232@coconut.itojun.org> > >> I'm looking for open-sourced Mobile IP implementation > >> on FreeBSD. Could anyone please give me some > >> information? > > > >KAME (www.kame.net) has an experimental implementation which will be > >integrated into FreeBSD at some point in the future once it's > >considered ready enough. > > KAME does mobile-ip6 only. we don't do mobile-ip4. CMU Monarch Project has a Mobile-IPv4 support for FreeBSD, but it only supports FreeBSD 2.2.2. For more detail, pls refer to: http://www.monarch.cs.cmu.edu/ =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@cosinecom.com Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 14 22:22:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from online.tmx.com.au (online.tmx.com.au [192.150.129.1]) by hub.freebsd.org (Postfix) with ESMTP id 4E2BC37B71A; Wed, 14 Mar 2001 22:21:37 -0800 (PST) (envelope-from mtaylor@bytecraft.com.au) Received: from melexc01.bytecraft.com.au ([203.9.250.249]) by online.tmx.com.au (8.9.3/8.8.8) with ESMTP id RAA19871; Thu, 15 Mar 2001 17:21:29 +1100 (EST) Received: by MELEXC01 with Internet Mail Service (5.5.2448.0) id ; Thu, 15 Mar 2001 17:23:04 +1100 Message-ID: <710709BB8B02D311942E006067441810544295@MELEXC01> From: Murray Taylor To: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Cc: "'Julian Elischer'" Subject: The Frame Relay setup / tutorial example revised Date: Thu, 15 Mar 2001 17:22:31 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a re-write of the network setup I am devising with fixes suggested by Julian Elisher (many thanks) There are still some questions though .... which anybody is welcome to take a shot at.... RTFMs used - man netgraph, ng_frame_relay, ng_lmi, ng_iface, ng_rfc1490, ng_bridge - /usr/share/examples/netgraph/* - Daemonnews 200003 netgraph article by Archie Cobbs - previous freebsd-questions and -net mailings O'Reilly - DNS and BIND - Getting Connected - The internet at 56K and up Addison-Wesley - Practical Internetworking with TCP/IP and UNIX Other factoids about the networks - The melbourne net is Win 9x/NT centric and almost all addresses are served up by DHCP from the NT PDC - The FreeBSD boxen are being used for the frame relay/ webserving application only at present. - The FreeBSD boxen run Samba at the os level = 0 and other appropriate settings to avoid interaction with the Browse master election waffle of M$ land This is still theoretical, as I am still waiting for the copper connection ;-) ! But it is RSN !! (I got the NTU in my hands today!) -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o- The Questions: For the initial setup [1] ANSWERED Given the settings from Telstra for the Management protocol, do I need the netgraph ng_lmi module? yes FreeBSD will be happy without it but the telstra end will not enable the link unless it get's the regular link-ok packets that the lmi module sends. You can use any management protocol. the lmi module understands all three. (connect it to dlci0 and dlci1023 at once and it will try all possible combinations of dlci and protocol, or, use a specific protcol, attached to a praticular dlci as directed by the telstra instructions.. i.e AnnexA<---->dlci0 ANSI-AnnexD Iso/Ieee Annex D LMI- (sometimes refered to as "group-of-4") For the WAN setup [1] Given that I understand that establishing the permanent virtual circuit (PVC) to the Sydney office will assign another DLCI number to us, is the netgraph extension I have made in start_if.ng1 (melbourne setup) correct? [2] ANSWERED Do I need to add a router daemon to the melbourne system now? probably not. More difficult questions (given DHCP nature of the network) [3] MORE DETEAIL GIVEN Do I need to fully populate the /etc/hosts table now? If the DHCP server is also the NDS server, probably not. Unfortunately the DHCP server is an NT box totally unrelated to the FreeBSD boxen (in fact it is 302 feet away on a CAT5 in the main company server room). I am running only a small /etc/hosts and DNS table configuration so that I can manage virtual hosts on Apache and give the web designers access to the web sites being developed Any one have more detail on managing / merging DHCP & DNS & hosts ?? [4] Do I need to fully populate the DNS table in Spyder? Other questions (bonus points!) [1] if I need to bring out other xxx.yyy.zzz.0/26 addresses 'out-the-side' of Spyder for other 'net visible machines, how should it be done? There is'nt any lower / upper hooks on the ng_iface node to attach a ng_bridge. I assume that this would be the connections point as it is the 'effective ethernet port' that one normally hooks to, is it not? -=-=-=-=-=-=-=-= Selected other comments by Julian (hopefully placed in enuf context) (on the netgraph I was using that used the auto0 and auto1023 hooks on the ng_lmi node) (...) if the telstra equipment also allows all management protocols the one you end up with is a roll of the dice.. you may prefer to use the specific protocol hooks for the lmi module attached to dlci0 now using specific protocol (on setting up initial routing on the netgraph frame relay interface) use the remote address for default.. i.e. the address at the telstra end. If in doubt as to what it is, set it to a random address in the ifconfig, make it the default route and then do a traceroute. It'll respond with it's correct address. Set that in as the remote address. (and more on the same routing) NO NO NO it is point-to-point link ifconfig ng0 MYADDRESS REMOTEADDRESS there is no netmask.. (I didn't know netgraph did this) The lmi module will log the DLCIs that it finds in the dmesg and /var/log/messages. Murray Taylor Project Engineer Bytecraft P/L +61 3 9587 2555 +61 3 9587 1614 fax mtaylor@bytecraft.com.au ============================================ THE REVISED SYSTEM SETUP ============================================ Initial setup -- Internet Access from ByteMelb for website - select Management Protocol ITU-T (CCITT) Q933 Annex A no ANSI T1.617 Annex D yes (Telstra default) LMI (FRF Doc#001-208966) no - select physical interface X.21bis/V35 no X.21 yes G.704 no - Telstra assignments xxx.yyy.zzz.0/26 network DLCI 16 Internet link (Telstra 'Big Pond') - Hardware card WANic 405 with X21 interface uses sr(4) driver - kernel compiled with NETGRAPH - hardware setup ng0 ip fxp0 ip xxx.yyy.zzz.1 SPYDER 10.1.2.30 +----------+ | | +---+ |-+-+ +-| frame | N | X21 |s|n| |f| 100BaseT =======| T |========|r|g| |x|~~~~~~~~~~~~ relay | U | |0|0| |p| +---+ |-+-+ |0| | +-| | | | | | | | | +----------+ Netgraph setup for Internet access <<<<<<< mod [ ] [ lmi ](annexD) --------+ [ ] | | [ sr0 ] [ ](dlci0) ---+ [ phys ](rawdata) --- (downstream)[ frame_relay ] [ ] [ ](dlci16)--+ | +---------------------------------------------------------+ | | { ] [ ng0 ] +--- (downstream)[ rcf1490 ](inet) --- (inet)[ iface ] xxx.yyy.zzz.1 [ ] [ ] Desired Initial Routing default TELSTRA_GATEWAY UGSc ng0 <<<<<<<< mod 127.0.0.1 127.0.0.1 UH lo0 10.1.2.0 ff:ff:ff:ff:ff:ff UHLWb fxp0 10.1.2 link#1 UC fxp0 - - - - so the following is done in this sequence via rc.conf (written in the sequence that rc.network will process them) =============== network portions of rc.conf ========================== # # set up my hostname # hostname="spyder.bytecraft.au.com" # # network setup # network_interfaces="lo0 ng0 fxp0" # # (NB more needed in man pages re start_if.* files) # # start_if.ng0 file is run here automagically # ifconfig_lo0="inet 127.0.0.1" ifconfig_fxp0="inet 10.1.2.30 netmask 255.255.0.0" ifconfig_ng0="inet xxx.yyy.zzz.1 TELSTRA-GATEWAY" <<<<<<<< mod # # firewall # ipfw_enable="YES" ipfw_flags="/etc/firewall/rules" # # NAT setup here # natd_enable="YES" natd_interfaces="ng0" # # static routes <<<<<<<< mod down to gateway section # # route(8) # A destination of default is a synonym for -net 0.0.0.0, which is the de- # fault route. # # If the destination is directly reachable via an interface requiring no # intermediary system to act as a gateway, the -interface modifier should # be specified; the gateway given is the address of this host on the common # network, indicating the interface to be used for transmission. Alter- # nately, if the interface is point to point the name of the interface it- # self may be given, in which case the route remains valid even if the lo- # cal or remote addresses change. # static_routes="ng0" # default route set to point out the frame relay link to big pond route_ng0="-net 0.0.0.0 -interface ng0" # # gateway enable # gateway_enable="YES" # # ----- end of netpass 1 # # named enable # named_enable="YES" named_flags="-u bind -g bind /etc/namedb/sandbox/named.conf" # # ----- end of netpass 2 # # sshd # sshd_enable="YES" # # ----- end of netpass 3 # # inetd flags # inetd_flags="" ============= end of network part of rc.conf ======================== the start_if.ng0 script ( basically a modified copy of the frame relay example file in /usr/share/examples/netgraph ) ================ start_if.ng0 ============================= #!/bin/sh # script to set up a frame relay link on the sr card. # The dlci used is selected below. The default is 16 # WANic 405 CARD=sr0 DLCI=16 # create a frame_relay type node and attach it to the sync port. ngctl mkpeer ${CARD}: frame_relay rawdata downstream # Attach the dlci output of the (de)multiplexor to a new <<<<<<<< mod # Link management protocol node using ANSI AnnexD ngctl mkpeer ${CARD}:rawdata lmi dlci0 annexD <<<<<<<< mod deleted dlci1023 hook # Attach the DLCI(channel) the Telco has assigned you to # a node to hadle whatever protocol encapsulation your peer # is using. In this case rfc1490 encapsulation. ngctl mkpeer ${CARD}:rawdata rfc1490 dlci${DLCI} downstream # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) # input of a netgraph "interface" node (ifconfig should show it as "ng0"). ngctl mkpeer ${CARD}:rawdata.dlci${DLCI} iface inet inet ================end of start_if.ng0 ========================== windoze machines that need internet access have their gateway set to 10.1.2.30 ** NOTE most internet access is inwards to apache webserver running on spyder ===================================================================== VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV ===================================================================== Then when Sydney comes online as a WAN extension to the ByteMelb net Assumptions Private Virtual Circuit (PVC) defined as : DLCI 17 at bytemelb DLCI 16 at bytesyd MELBOURNE - hardware setup ng0 ip fxp0 ip xxx.yyy.zzz.1 SPYDER 10.1.2.30 ng1 ip +----------+ 10.1.2.250 | +-+ | | |n| | +---+ |-+g| +-| frame | N | X21 |s|0| |f| 100BaseT =======| T |========|r|-| |x|~~~~~~~~~~~~ relay | U | |0|n| |p| +---+ |-+g| |0| | |1| +-| | +-+ | | | | | | | +----------+ Netgraph redefined to this configuration [ ] [ lmi ](annexD) --------+ [ ] | | [ sr0 ] [ ](dlci0) ---+ [ phys ](rawdata) --- (downstream)[ frame_relay ] [ ] [ ](dlci16) ---+ [ ](dlci17) --+| || +----------------------------------------------------------+| |+----------------------------------------------------------+ || || { ] [ ng0 ] |+--- (downstream)[ rcf1490 ](inet) --- (inet)[ iface ] 203.39.118.1 | [ ] [ ] | | [ ] [ ng1 ] +---- (downstream)[ rfc1490 ](inet) --- (inet)[ iface ] 10.1.2.250 [ ] [ ] Desired Initial Routing default TELSTRA-GATEWAY UGSc ng0 <<<<<<<< mod 127.0.0.1 127.0.0.1 UH lo0 10.1.7/24 10.1.7.250 UGS ng1 -- added WAN link 10.1.2.0 ff:ff:ff:ff:ff:ff UHLWb fxp0 10.1.2 link#1 UC fxp0 --- SYDNEY - hardware setup ng0 ip fxp0 ip 10.1.7.250 SYDGATE 10.1.7.1 +----------+ | | +---+ |-+-+ +-| frame | N | X21 |s|n| |f| 100BaseT =======| T |========|r|g| |x|~~~~~~~~~~~~ relay | U | |0|0| |p| +---+ |-+-+ |0| | +-| | | | | | | | | +----------+ Netgraph will be similar to original ByteMelb setup [ ] [ lmi ](annexD) --------+ [ ] | | [ sr0 ] [ ](dlci0) ---+ [ phys ](rawdata) --- (downstream)[ frame_relay ] [ ] [ ](dlci16)--+ | +---------------------------------------------------------+ | | { ] [ ng0 ] +--- (downstream)[ rcf1490 ](inet) --- (inet)[ iface ] 10.1.7.250 [ ] [ ] Desired Initial Routing default 10.1.2.250 UGSc ng0 <<<<<<<< mod 127.0.0.1 127.0.0.1 UH lo0 10.1.7.0 ff:ff:ff:ff:ff:ff UHLWb fxp0 10.1.7 link#1 UC fxp0 - - - - so the setups now are this (written in the sequence that rc.network will process them) =bytMelb==== WAN ===network portions of rc.conf ============== # # changes / additions marked by --------- WAN # # set up my hostname # hostname="spyder.bytecraft.au.com" # # network setup # network_interfaces="lo0 ng0 ng1 fxp0" ---------- WAN # # start_if.ng0 file is run here automagically # start_if.ng1 is run also ---------- WAN # ifconfig_lo0="inet 127.0.0.1" ifconfig_fxp0="inet10.1.2.30 netmask 255.255.0.0" # setup point to point link to Telstra <<<<<<<< mod ifconfig_ng0="inet xxx.yyy.zzz.1 TELSTRA-GATEWAY" # setup point to point link to BytSyd <<<<<<<< mod ifconfig_ng1="inet 10.1.2.250 10.1.7.250" ---------- WAN # # firewall # ipfw_enable="YES" # # NAT setup here # natd_enable="YES" natd_interfaces="ng0" # # static routes # <<<<<<<< mod down to gateway section # route(8) # A destination of default is a synonym for -net 0.0.0.0, which is the de- # fault route. # # If the destination is directly reachable via an interface requiring no # intermediary system to act as a gateway, the -interface modifier should # be specified; the gateway given is the address of this host on the common # network, indicating the interface to be used for transmission. Alter- # nately, if the interface is point to point the name of the interface it- # self may be given, in which case the route remains valid even if the lo- # cal or remote addresses change. static_routes="ng0 ng1" ---------- WAN # default route set to point out the frame relay link to big pond route_ng0="-net 0.0.0.0 -interface ng0" # sydney route set to the frame relay link to BytSyd route_ng1="-net 10.1.7.0/16 -interface ng1" # # gateway enable # gateway_enable="YES" # # ----- end of netpass 1 # # named enable # named_enable="YES" named_flags="-u bind -g bind /etc/namedb/sandbox/named.conf" # # ----- end of netpass 2 # # sshd # sshd_enable="YES" # # ----- end of netpass 3 # # inetd flags # inetd_flags="" ============= end of network part of rc.conf ======================== the start_if.ng0 script ( basically a copy of the frame relay example file in /usr/share/examples/netgraph ) ===bytMelb== WAN =========== start_if.ng0 ========================== ----------- WAN no changes ============== end of start_if.ng0 =============================== ===bytMelb== WAN =========== start_if.ng1 ========================== #!/bin/sh # script to set up an additional frame relay link on the sr card. # WANic 405 CARD=sr0 # # WAN link to sydney DLCI=17 # Attach the DLCI(channel) the Telco has assigned you to # a node to handle whatever protocol encapsulation your peer # is using. In this case rfc1490 encapsulation. ngctl mkpeer ${CARD}:rawdata rfc1490 dlci${DLCI} downstream # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) # input of a netgraph "interface" node (ifconfig should show it as "ng1"). ngctl mkpeer ${CARD}:rawdata.dlci${DLCI} iface inet inet ====bytMelb== WAN ==========end of start_if.ng1 =================== windoze machines that need internet access have their gateway set to 10.1.2.30 other windoze machines should pass through to bytSyd OK due to netmask value 255.255.0.0 ???? ====bytSyd === WAN == network portions of rc.conf ================= # # set up my hostname # hostname="sydgate.bytecraft.au.com" # # network setup # network_interfaces="lo0 ng0 fxp0" # # start_if.ng0 file is run here automagically # ifconfig_lo0="inet 127.0.0.1" ifconfig_fxp0="inet 10.1.7.1 netmask 255.255.0.0" # setup point to point link to BytMelb ifconfig_ng0="inet 10.1.7.250 10.1.2.250" <<<<<<<< mod # # firewall # ipfw_enable="NO" # # NAT setup here # natd_enable="NO" # # static routes # # <<<<<<<< mod down to gateway section # route(8) # A destination of default is a synonym for -net 0.0.0.0, which is the de- # fault route. # # If the destination is directly reachable via an interface requiring no # intermediary system to act as a gateway, the -interface modifier should # be specified; the gateway given is the address of this host on the common # network, indicating the interface to be used for transmission. Alter- # nately, if the interface is point to point the name of the interface it- # self may be given, in which case the route remains valid even if the lo- # cal or remote addresses change. static_routes="ng0" route_ng0="-net 0.0.0.0 -interface ng0" # # gateway enable # gateway_enable="NO" # # ----- end of netpass 1 # # named enable # named_enable="NO" # # ----- end of netpass 2 # # sshd # sshd_enable="YES" # # ----- end of netpass 3 # # inetd flags # inetd_flags="" ===bytSyd== WAN == end of network part of rc.conf ====== the start_if.ng0 script ===bytSyd== WAN ==== start_if.ng0 ===================== #!/bin/sh # script to set up a frame relay link on the sr card. # The dlci used is selected below. The default is 16 # WANic 405 CARD=sr0 DLCI=16 # create a frame_relay type node and attach it to the sync port. ngctl mkpeer ${CARD}: frame_relay rawdata downstream # Attach the dlci output of the (de)multiplexor to a new # Link management protocol node. ngctl mkpeer ${CARD}:rawdata lmi dlci0 annexD # Attach the DLCI(channel) the Telco has assigned you to # a node to hadle whatever protocol encapsulation your peer # is using. In this case rfc1490 encapsulation. ngctl mkpeer ${CARD}:rawdata rfc1490 dlci${DLCI} downstream # Attach the ip (inet) protocol output of the protocol mux to the ip (inet) # input of a netgraph "interface" node (ifconfig should show it as "ng0"). ngctl mkpeer ${CARD}:rawdata.dlci${DLCI} iface inet inet ===bytSyd== WAN ====end of start_if.ng0 ====================== windoze machines that need internet access have their gateway set to 10.1.2.30 windoze machines should see melb system OK due to netmask value default route through ng0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 3:47:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 73DF437B719 for ; Thu, 15 Mar 2001 03:47:37 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from mobile.wemm.org (mobile.wemm.org [10.0.0.5]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f2FBlbp52686 for ; Thu, 15 Mar 2001 03:47:37 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f2FBlZh83021; Thu, 15 Mar 2001 03:47:36 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200103151147.f2FBlZh83021@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jonathan Lemon Cc: cnielsen@pobox.com, net@FreeBSD.ORG Subject: Re: Intel PRO/100+ PCI problem In-Reply-To: <200103150118.f2F1IOa75456@prism.flugsvamp.com> Date: Thu, 15 Mar 2001 03:47:35 -0800 From: Peter Wemm Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon wrote: > In article you write: > >On Wed, Mar 14, 2001 at 08:47:57AM -0600, Jonathan Lemon wrote: > >> On Wed, Mar 14, 2001 at 02:28:47PM +0100, Jeroen Ruigrok/Asmodai wrote: > >> > -On [20010308 22:02], Rafael Tonin (rafael.tonin@terra.com.br) wrote: > >> > >I'm having some problems on configuring my just purchased > >> > >Intel PRO/100+ PCI (reported by Intel as being P#: 689661-004). > >> > > > >> > >When booting, FreeBSD 4.2 reports: > >> > > > >> > >fxp0: at device 13.0 on pci0 > >> > >fxp0: could not map memory > >> > > >> > You might want to try the latest sources Jonathan Lemon [cc:'d] came up > >> > with. I've looked at the diffs and he did some nice cleanups to bring > >> > the driver into the present. This might also fix your problem. > >> > > >> > Jona, did you already have tarball for 4-STABLE which people can just > >> > extract and compile a new kernel with? > >> > >> Hmm, no. I should probably generate one. However, I do have the >> miibus.ko and if_fxp.ko binary modules for 4-STABLE, if you want > >> to just drop those in a system and use it. > >> > >> http://www.flugsvamp.com/~jlemon/fbsd/drivers/ > > > >I have a -stable box with a pair of 82559s on the motherboard > >that I can use for testing, if you need/want testers for -stable. > > I've had a bunch of people test it already, thanks. However, I would > still like to hear from someone whos card did not work before the > driver was upgraded, but does work now. FYI, on a REALLY OLD fxp: fxp0: port 0xff20-0xff3f mem 0xff800000-0xff8fffff,0xffbde000-0xffbdefff irq 2 at device 6.0 on pci0 fxp0: using memory space register mapping fxp0: Ethernet address 00:a0:c9:49:aa:d3 fxp0: PCI IDs: 8086 1229 0000 0000 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bpf: fxp0 attached This actually does have the NatSemi phy on it and it is correctly detected. Unfortunately, I just locked that machine up with SMPng. oops. I can't verify that it works just yet.. We have another old machine with a NS phy on it (pII based instead of PPro based) and are working on it now. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 5:21: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 4F4F637B718 for ; Thu, 15 Mar 2001 05:20:59 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from mobile.wemm.org (mobile.wemm.org [10.0.0.5]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f2FDKxp52976 for ; Thu, 15 Mar 2001 05:20:59 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f2FDKwh83702; Thu, 15 Mar 2001 05:20:58 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200103151320.f2FDKwh83702@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jonathan Lemon , cnielsen@pobox.com, net@FreeBSD.ORG Subject: Re: Intel PRO/100+ PCI problem In-Reply-To: <200103151147.f2FBlZh83021@mobile.wemm.org> Date: Thu, 15 Mar 2001 05:20:58 -0800 From: Peter Wemm Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Wemm wrote: > Jonathan Lemon wrote: > > In article > you write: > > >On Wed, Mar 14, 2001 at 08:47:57AM -0600, Jonathan Lemon wrote: > > >> On Wed, Mar 14, 2001 at 02:28:47PM +0100, Jeroen Ruigrok/Asmodai wrote: > > >> > -On [20010308 22:02], Rafael Tonin (rafael.tonin@terra.com.br) wrote: > > >> > >I'm having some problems on configuring my just purchased > > >> > >Intel PRO/100+ PCI (reported by Intel as being P#: 689661-004). > > >> > > > > >> > >When booting, FreeBSD 4.2 reports: > > >> > > > > >> > >fxp0: at device 13.0 on pci0 > > >> > >fxp0: could not map memory > > >> > > > >> > You might want to try the latest sources Jonathan Lemon [cc:'d] came u p > > >> > with. I've looked at the diffs and he did some nice cleanups to bring > > >> > the driver into the present. This might also fix your problem. > > >> > > > >> > Jona, did you already have tarball for 4-STABLE which people can just > > >> > extract and compile a new kernel with? > > >> > > >> Hmm, no. I should probably generate one. However, I do have the > >> miibus.ko and if_fxp.ko binary modules for 4-STABLE, if you want > > >> to just drop those in a system and use it. > > >> > > >> http://www.flugsvamp.com/~jlemon/fbsd/drivers/ > > > > > >I have a -stable box with a pair of 82559s on the motherboard > > >that I can use for testing, if you need/want testers for -stable. > > > > I've had a bunch of people test it already, thanks. However, I would > > still like to hear from someone whos card did not work before the > > driver was upgraded, but does work now. > > FYI, on a REALLY OLD fxp: > > fxp0: port 0xff20-0xff3f mem 0xff800000-0xf f8fffff,0xffbde000-0xffbdefff irq 2 at device 6.0 on pci0 > fxp0: using memory space register mapping > fxp0: Ethernet address 00:a0:c9:49:aa:d3 > fxp0: PCI IDs: 8086 1229 0000 0000 > nsphy0: on miibus0 > nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > bpf: fxp0 attached > > This actually does have the NatSemi phy on it and it is correctly detected. > Unfortunately, I just locked that machine up with SMPng. oops. I can't > verify that it works just yet.. We have another old machine with a NS > phy on it (pII based instead of PPro based) and are working on it now. I spoke too soon: [machine 1, 10.0.0.18, ping 10.0.0.16] 05:14:13.248353 arp who-has 10.0.0.16 tell 10.0.0.18 05:14:14.258430 arp who-has 10.0.0.16 tell 10.0.0.18 05:14:15.268516 arp who-has 10.0.0.16 tell 10.0.0.18 05:14:16.278597 arp who-has 10.0.0.16 tell 10.0.0.18 [nsphy fxp, 10.0.0.16] 05:13:43.662723 arp who-has 10.0.0.16 tell 10.0.0.18 05:13:43.662895 arp reply 10.0.0.16 is-at 0:a0:c9:49:aa:d3 05:13:44.672965 arp who-has 10.0.0.16 tell 10.0.0.18 05:13:44.673169 arp reply 10.0.0.16 is-at 0:a0:c9:49:aa:d3 [the timestamps are out of sync, that makes no difference] It appears that the nsphy version is unable to actually transmit packets. It is recieving OK, just not sending. (or, the other machines are unable to see it, maybe the switch is dropping the packets as "damaged" or something?) $ dmesg | tail ... Thu Mar 15 05:06:51 PST 2001 fxp0: device timeout fxp0: device timeout fxp0: device timeout fxp0: device timeout ... This is an Intel PR440FX motherboard, so I can't send you the card. :-) Dual PPro-200MHz system, with onboard 82557 w/ real natsemi phy. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 9: 7:14 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 1CB3E37B719 for ; Thu, 15 Mar 2001 09:07:07 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f2FH3he04769; Thu, 15 Mar 2001 11:03:43 -0600 (CST) (envelope-from jlemon) Date: Thu, 15 Mar 2001 11:03:43 -0600 From: Jonathan Lemon To: Peter Wemm , Ollivier Robert Cc: Jonathan Lemon , cnielsen@pobox.com, net@FreeBSD.ORG Subject: Re: Intel PRO/100+ PCI problem Message-ID: <20010315110343.B82645@prism.flugsvamp.com> References: <200103151147.f2FBlZh83021@mobile.wemm.org> <200103151320.f2FDKwh83702@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200103151320.f2FDKwh83702@mobile.wemm.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 15, 2001 at 05:20:58AM -0800, Peter Wemm wrote: > > fxp0: port 0xff20-0xff3f mem 0xff800000-0xf > f8fffff,0xffbde000-0xffbdefff irq 2 at device 6.0 on pci0 > > fxp0: using memory space register mapping > > fxp0: Ethernet address 00:a0:c9:49:aa:d3 > > fxp0: PCI IDs: 8086 1229 0000 0000 > > nsphy0: on miibus0 > > nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > bpf: fxp0 attached > > > > This actually does have the NatSemi phy on it and it is correctly detected. > > Unfortunately, I just locked that machine up with SMPng. oops. I can't > > verify that it works just yet.. We have another old machine with a NS > > phy on it (pII based instead of PPro based) and are working on it now. > > It appears that the nsphy version is unable to actually transmit packets. > It is recieving OK, just not sending. (or, the other machines are unable > to see it, maybe the switch is dropping the packets as "damaged" or > something?) Try this following patch to mii/nsphy.c. It appears that we need to toggle some undocumented bits in order to get this PHY to work with the fxp driver. -- Jonathan Index: nsphy.c =================================================================== RCS file: /ncvs/src/sys/dev/mii/nsphy.c,v retrieving revision 1.7 diff -u -r1.7 nsphy.c --- nsphy.c 2001/02/07 19:57:16 1.7 +++ nsphy.c 2001/03/15 17:14:51 @@ -264,17 +264,20 @@ */ reg |= PCR_FLINK100; -#if 0 /* * Mystery bits which are supposedly `reserved', * but we seem to need to set them when the PHY - * is connected to some interfaces! + * is connected to some interfaces: + * + * 0x0400 is needed for fxp + * (Intel EtherExpress Pro 10+/100B, 82557 chip) + * (nsphy with a DP83840 chip) + * 0x0100 may be needed for some other card */ reg |= 0x0100 | 0x0400; -#endif -/* + PHY_WRITE(sc, MII_NSPHY_PCR, reg); -*/ + switch (IFM_SUBTYPE(ife->ifm_media)) { case IFM_AUTO: /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 10:30:40 2001 Delivered-To: freebsd-net@freebsd.org Received: from heidelberg.dotnet.com (heidelberg.dotnet.com [216.127.192.12]) by hub.freebsd.org (Postfix) with ESMTP id E2CD637B718 for ; Thu, 15 Mar 2001 10:30:36 -0800 (PST) (envelope-from parmor@dotnet.com) Received: from blah2 (ip42-padsl.dotnet.com [216.127.198.42]) by heidelberg.dotnet.com (8.9.3/8.9.3) with SMTP id MAA02767 for ; Thu, 15 Mar 2001 12:30:30 -0600 Message-ID: <000d01c0ad7e$4f116b00$2ac67fd8@blah2> From: "Paul Armor" To: References: <200103151147.f2FBlZh83021@mobile.wemm.org> <200103151320.f2FDKwh83702@mobile.wemm.org> <20010315110343.B82645@prism.flugsvamp.com> Subject: Re: Intel PRO/100+ PCI problem Date: Thu, 15 Mar 2001 12:32:35 -0600 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 Off topic...sort of interesting that it's an old National phy issue, I worked for several years on an embedded system that used a Natl. phy part that would exhibit this behaviour...at some random time after the system had been on the network, as I recall it could be an hour or several days...then it would just "drop off" the net...We switched phy parts as no one really could figure out why... very interesting... > On Thu, Mar 15, 2001 at 05:20:58AM -0800, Peter Wemm wrote: > > > fxp0: port 0xff20-0xff3f mem 0xff800000-0xf > > f8fffff,0xffbde000-0xffbdefff irq 2 at device 6.0 on pci0 > > > fxp0: using memory space register mapping > > > fxp0: Ethernet address 00:a0:c9:49:aa:d3 > > > fxp0: PCI IDs: 8086 1229 0000 0000 > > > nsphy0: on miibus0 > > > nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > bpf: fxp0 attached > > > > > > This actually does have the NatSemi phy on it and it is correctly detected. > > > Unfortunately, I just locked that machine up with SMPng. oops. I can't > > > verify that it works just yet.. We have another old machine with a NS > > > phy on it (pII based instead of PPro based) and are working on it now. > > > > It appears that the nsphy version is unable to actually transmit packets. > > It is recieving OK, just not sending. (or, the other machines are unable > > to see it, maybe the switch is dropping the packets as "damaged" or > > something?) > > Try this following patch to mii/nsphy.c. It appears that we need to > toggle some undocumented bits in order to get this PHY to work with > the fxp driver. > -- > Jonathan > > > Index: nsphy.c > =================================================================== > RCS file: /ncvs/src/sys/dev/mii/nsphy.c,v > retrieving revision 1.7 > diff -u -r1.7 nsphy.c > --- nsphy.c 2001/02/07 19:57:16 1.7 > +++ nsphy.c 2001/03/15 17:14:51 > @@ -264,17 +264,20 @@ > */ > reg |= PCR_FLINK100; > > -#if 0 > /* > * Mystery bits which are supposedly `reserved', > * but we seem to need to set them when the PHY > - * is connected to some interfaces! > + * is connected to some interfaces: > + * > + * 0x0400 is needed for fxp > + * (Intel EtherExpress Pro 10+/100B, 82557 chip) > + * (nsphy with a DP83840 chip) > + * 0x0100 may be needed for some other card > */ > reg |= 0x0100 | 0x0400; > -#endif > -/* > + > PHY_WRITE(sc, MII_NSPHY_PCR, reg); > -*/ > + > switch (IFM_SUBTYPE(ife->ifm_media)) { > case IFM_AUTO: > /* > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 16:38:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from online.tmx.com.au (online.tmx.com.au [192.150.129.1]) by hub.freebsd.org (Postfix) with ESMTP id 3A61237B71A; Thu, 15 Mar 2001 16:38:31 -0800 (PST) (envelope-from mtaylor@bytecraft.com.au) Received: from melexc01.bytecraft.com.au ([203.9.250.249]) by online.tmx.com.au (8.9.3/8.8.8) with ESMTP id LAA07821; Fri, 16 Mar 2001 11:38:27 +1100 (EST) Received: by MELEXC01 with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Mar 2001 11:39:43 +1100 Message-ID: <710709BB8B02D311942E00606744181054429B@MELEXC01> From: Murray Taylor To: "'freebsd-net@freebsd.org'" , "'freebsd-hackers@freebsd.org'" Subject: Netgraph error message Date: Fri, 16 Mar 2001 11:39:10 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I get the following messages when I fire up ngctl module_register: module netgraph already exists and linker_file_sysinit: "netgraph.ko" failed to register 17 I am using 4.3-BETA as at 13/mar and have options NETGRAPH in my kernel config I am using the ngctl command to configure a frame relay system (yes the hardware is here ;-) It all seems to run OK and I do get a ng0 interface and the frame relay system seems to be handshaking OK (I ran the script last night too, without the physical connection in place and got tons of timeout errors then, which have gone away now that the hardware is in place, so i am assuming that all is well in there) Murray Taylor Project Engineer Bytecraft P/L +61 3 9587 2555 +61 3 9587 1614 fax mtaylor@bytecraft.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 20: 0: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 5AF3E37B718 for ; Thu, 15 Mar 2001 20:00:03 -0800 (PST) (envelope-from archie@dellroad.org) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id TAA41760; Thu, 15 Mar 2001 19:45:18 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.2/8.11.2) id f2G4lgV67346; Thu, 15 Mar 2001 20:47:42 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200103160447.f2G4lgV67346@curve.dellroad.org> Subject: Re: Problems with ADSL and MPD PPPoE In-Reply-To: <41E533716110D511BF0300805FCC206001331F@happy.itsco.com> "from Brent Voltz at Mar 14, 2001 12:50:09 pm" To: Brent Voltz Date: Thu, 15 Mar 2001 20:47:41 -0800 (PST) Cc: "'freebsd-net@freebsd.org'" X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brent Voltz writes: > I am currently attempting to get PPPoE working using MPD on 4.2-Release. > I'm talking to an Alcatel 1000. I can get connected using PPP and a tun > interface, but I'm having no luck with MPD. The log file shows this: > > mpd: pid 202, version 3.2 (root@bsd 21:32 11-Mar-2001) > [PPPoE] ppp node is "mpd202-PPPoE" > [PPPoE] using interface ng0 > [PPPoE] IPCP: peer address cannot be zero > [PPPoE] IFACE: Open event > [PPPoE] IPCP: Open event > [PPPoE] IPCP: state change Initial --> Starting > [PPPoE] IPCP: LayerStart > [PPPoE:PPPoE] [PPPoE] bundle: OPEN event in state CLOSED > [PPPoE] opening link "PPPoE"... > [PPPoE] link: OPEN event > [PPPoE] LCP: Open event > [PPPoE] LCP: state change Initial --> Starting > [PPPoE] LCP: LayerStart > [PPPoE] device: OPEN event in state DOWN > [PPPoE] exec: /sbin/ifconfig fxp1 up > [PPPoE] can't create pppoe peer to fxp1:,orphans: No such file or directory > [PPPoE] device is now in state OPENING > [PPPoE] device: DOWN event in state OPENING > [PPPoE] device is now in state DOWN > [PPPoE] link: DOWN event > [PPPoE] LCP: Down event > > I used the sample config files, edited with my username, password, ethernet > interface, etc. Can anyone tell me what is failing? You might need to "kldload ng_ether" first.. ? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 21: 7:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from pcs113.sasi.com (samar.sasken.com [164.164.56.2]) by hub.freebsd.org (Postfix) with ESMTP id AC06137B71A for ; Thu, 15 Mar 2001 21:07:13 -0800 (PST) (envelope-from pmk@sasi.com) Received: from localhost (pmk@localhost) by pcs113.sasi.com (8.9.3/8.9.3) with ESMTP id KAA02254 for ; Fri, 16 Mar 2001 10:37:07 +0530 X-Authentication-Warning: pcs113.sasi.com: pmk owned process doing -bs Date: Fri, 16 Mar 2001 10:37:07 +0530 (IST) From: Mohana Krishna Penumetcha To: net@freebsd.org Subject: strange arp packets!!! 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 hi, while testing our software we have observed the following arp packets. 16:41:25.623476 arp who-has 0.0.0.0 tell 10.0.36.130 16:41:30.639372 arp who-has 0.0.0.0 tell 10.0.36.130 16:41:40.649838 arp who-has 0.0.0.0 tell 10.0.36.130 16:41:45.631430 arp who-has 0.0.0.0 tell 10.0.36.130 16:41:50.640533 arp who-has 0.0.0.0 tell 10.0.36.130 16:42:00.651104 arp who-has 0.0.0.0 tell 10.0.36.130(--> pcs130) i am little confused what this means, since 0.0.0.0 means "this host"? or is it that, it is meant to update the arp entry corresponding to pcs130 on other hosts in the subnet? in this case, it can as well say "10.0.36.130" instead of "0.0.0.0". pcs130 runs FreeBSD 4.0 and the dump is taken on a linux machine connected to pcs130. please cc the replies to me as i am not subscribed to this mailing list. -- mohan --------------------------------------------------------------------------- Creativity is allowing yourself to make mistakes and Art is knowing which ones to keep. -Dilbert Mohana Krishna P. ph:- 527 6100/6108 x4470 Telecom ODC, Sasken Communication Technologies, INDIA. http://www.sasken.com --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 21: 9: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from sleepy.itsco.com (sleepy.itsco.com [216.27.47.11]) by hub.freebsd.org (Postfix) with SMTP id 78B3F37B718 for ; Thu, 15 Mar 2001 21:08:57 -0800 (PST) (envelope-from bvoltz@itsco.com) Received: by sleepy.itsco.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 00:08:50 -0500 Message-ID: <41E533716110D511BF0300805FCC2060013323@happy.itsco.com> From: Brent Voltz To: 'Archie Cobbs ' Cc: "''freebsd-net@freebsd.org' '" Subject: RE: Problems with ADSL and MPD PPPoE Date: Fri, 16 Mar 2001 00:08:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Excellent! That worked! I have a follow-up question: With the PPPoE connection active on ng0, is it possible to use MPD to bring up a PPTP tunnel on ng1? -----Original Message----- From: Archie Cobbs To: Brent Voltz Cc: 'freebsd-net@freebsd.org' Sent: 3/15/01 11:47 PM Subject: Re: Problems with ADSL and MPD PPPoE Brent Voltz writes: > I am currently attempting to get PPPoE working using MPD on 4.2-Release. > I'm talking to an Alcatel 1000. I can get connected using PPP and a tun > interface, but I'm having no luck with MPD. The log file shows this: > > mpd: pid 202, version 3.2 (root@bsd 21:32 11-Mar-2001) > [PPPoE] ppp node is "mpd202-PPPoE" > [PPPoE] using interface ng0 > [PPPoE] IPCP: peer address cannot be zero > [PPPoE] IFACE: Open event > [PPPoE] IPCP: Open event > [PPPoE] IPCP: state change Initial --> Starting > [PPPoE] IPCP: LayerStart > [PPPoE:PPPoE] [PPPoE] bundle: OPEN event in state CLOSED > [PPPoE] opening link "PPPoE"... > [PPPoE] link: OPEN event > [PPPoE] LCP: Open event > [PPPoE] LCP: state change Initial --> Starting > [PPPoE] LCP: LayerStart > [PPPoE] device: OPEN event in state DOWN > [PPPoE] exec: /sbin/ifconfig fxp1 up > [PPPoE] can't create pppoe peer to fxp1:,orphans: No such file or directory > [PPPoE] device is now in state OPENING > [PPPoE] device: DOWN event in state OPENING > [PPPoE] device is now in state DOWN > [PPPoE] link: DOWN event > [PPPoE] LCP: Down event > > I used the sample config files, edited with my username, password, ethernet > interface, etc. Can anyone tell me what is failing? You might need to "kldload ng_ether" first.. ? -Archie ________________________________________________________________________ __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 21:30: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 5C8E337B718 for ; Thu, 15 Mar 2001 21:30:03 -0800 (PST) (envelope-from archie@dellroad.org) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA42298; Thu, 15 Mar 2001 21:26:09 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.11.2/8.11.2) id f2G6Smb67571; Thu, 15 Mar 2001 22:28:48 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200103160628.f2G6Smb67571@curve.dellroad.org> Subject: Re: Problems with ADSL and MPD PPPoE In-Reply-To: <41E533716110D511BF0300805FCC2060013323@happy.itsco.com> "from Brent Voltz at Mar 16, 2001 00:08:55 am" To: Brent Voltz Date: Thu, 15 Mar 2001 22:28:48 -0800 (PST) Cc: freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brent Voltz writes: > I have a follow-up question: With the PPPoE connection active on ng0, is it > possible to use MPD to bring up a PPTP tunnel on ng1? Sure... just use the same mpd and define a new bundle in mpd.conf. E.g.: default: load bundle1 load bundle2 bundle1: new -i ng0 pppoe pppoe ... bundle2: new -i ng1 pptp pptp ... -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 22:42:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.ruhr.de (in-ruhr4.ruhr.de [212.23.134.2]) by hub.freebsd.org (Postfix) with SMTP id EF9AE37B71A for ; Thu, 15 Mar 2001 22:42:39 -0800 (PST) (envelope-from ue@nathan.ruhr.de) Received: (qmail 30124 invoked by uid 10); 16 Mar 2001 06:42:38 -0000 Received: (from ue@localhost) by nathan.ruhr.de (8.11.3/8.11.2) id f2G6gdU02541; Fri, 16 Mar 2001 07:42:39 +0100 (CET) (envelope-from ue) Date: Fri, 16 Mar 2001 07:42:39 +0100 From: Udo Erdelhoff To: freebsd-net Cc: Murray Taylor , "'freebsd-hackers@freebsd.org'" Subject: Re: Netgraph error message Message-ID: <20010316074239.R83336@nathan.ruhr.de> Reply-To: freebsd-net Mail-Followup-To: freebsd-net , Murray Taylor , "'freebsd-hackers@freebsd.org'" References: <710709BB8B02D311942E00606744181054429B@MELEXC01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <710709BB8B02D311942E00606744181054429B@MELEXC01>; from mtaylor@bytecraft.com.au on Fri, Mar 16, 2001 at 11:39:10AM +1100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Mar 16, 2001 at 11:39:10AM +1100, Murray Taylor wrote: > I get the following messages when I fire up ngctl > > module_register: module netgraph already exists > linker_file_sysinit: "netgraph.ko" failed to register 17 > > I am using 4.3-BETA as at 13/mar > and have options NETGRAPH in my kernel config > > I am using the ngctl command to configure a frame relay system I assume that you are also using the netgraph nodes for frame relay. In that case, the error messages are probably mostly harmless. I've had similar messages when I tried to use mpd-netgraph on a box that had options NETGRAPH/NETGRAPH_ETHER/NETGRAPH_SOCKET/NETGRAPH_PPPOE in the kernel config. As far as I understand it, you have to use an all-or-nothing approach when it comes to netgraph. If you do not include any netgraph modules in your kernel, the system will load your modules and everything is fine. If you include all neccessary modules into the kernel, things will work as well. Things start to go downhill if some of the modules have been included in the kernel and some others have to be loaded. The system gets the information that the module NETGRAPH_FOO depends on NETGRAPH. The system ignores that netgraph.ko is already present in the kernel and will try to load the module. It's no big surprise that the operation fails. I managed to work around the problem by loading the additional modules manually (kldload ng_foo;kldload ng_bar;...). The correct fix is to include all neccessary modules in your kernel. Use a second shell while you are running ngctl and run kldstat. If you see any netgraph modules in the output, add them to your kernel config. NOTE: This was on a 4.1-stable system, things may have changed since then. /s/Udo -- "I don't want to run a company. I'm not good at managing people. You have a problem with the guy in the next cubicle? I don't care. Shoot him or something." -- Marc Andreesen, founder of Netscape, Rolling Stone, May 97 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 22:50:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from nimbus.superior.net (nimbus.superior.net [216.238.144.3]) by hub.freebsd.org (Postfix) with ESMTP id 3BEAC37B719 for ; Thu, 15 Mar 2001 22:50:18 -0800 (PST) (envelope-from miker@superior.net) Received: from SHIVA (cthulu.superior.net [216.238.130.251]) by nimbus.superior.net (8.9.3/8.9.3/RB) with SMTP id BAA24859 for ; Fri, 16 Mar 2001 01:50:16 -0500 (EST) Message-ID: <003d01c0ade5$d043e380$0200a8c0@SHIVA> From: "Mike" To: "'freebsd-net@freebsd.org'" References: <710709BB8B02D311942E00606744181054429B@MELEXC01> Subject: translate from iptables Date: Fri, 16 Mar 2001 01:53:25 -0500 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I'm trying to move everything from my RH Linux box to FreeBSD. So far everything is great on BSD and I'm very glad I switched. The only thing I have left to get functioning is Bnetd, the starcraft/diablo server. I have it "working" but there is a problem with people playing behind the firewall with people on the outside. To make a long story short, the following snippet is from the iptables firewall on my Linux box. It is what solved the problem and got everything working great: ********************************************************************** iptables -t nat -A PREROUTING -p udp -d 216.238.130.251 --dport 63010 -j DNAT --to-destination 192.168.0.2:6112 iptables -t nat -A PREROUTING -p udp -d 216.238.130.251 --dport 63011 -j DNAT --to-destination 192.168.0.3:6112 iptables -t nat -A PREROUTING -p udp -d 216.238.130.251 --dport 63012 -j DNAT --to-destination 192.168.0.4:6112 iptables -t nat -A POSTROUTING -p udp -s 192.168.0.2 --sport 6112 -j SNAT --to-source 216.238.130.251:63010 iptables -t nat -A POSTROUTING -p udp -s 192.168.0.3 --sport 6112 -j SNAT --to-source 216.238.130.251:63011 iptables -t nat -A POSTROUTING -p udp -s 192.168.0.4 --sport 6112 -j SNAT --to-source 216.238.130.251:63012 *********************************************************************** What I'm hoping is that someone will be able to tell me a way to do this same thing using natd or ipfwd or something like that. Any hints or help would be much appreciated:) Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 15 23:56:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 7385337B718; Thu, 15 Mar 2001 23:56:43 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f2G7uRb64573; Fri, 16 Mar 2001 09:56:27 +0200 (EET) (envelope-from ru) Date: Fri, 16 Mar 2001 09:56:27 +0200 From: Ruslan Ermilov To: Nick Rogness Cc: net@FreeBSD.org Subject: Re: natd divert injecting clarifications Message-ID: <20010316095627.C62097@sunbay.com> Mail-Followup-To: Nick Rogness , net@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@rogness.net on Thu, Mar 15, 2001 at 09:48:24PM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Redirected to -net] On Thu, Mar 15, 2001 at 09:48:24PM -0600, Nick Rogness wrote: > > Just to be sure I have it right. When the kernel diverts the packet to > natd, via ipfw: > > 1) kernel sends packet to natd > 2) natd read() the packet > 3) natd screws with it (changes dest addr,etc) > 4) natd write() the packet > 5) kernel reinjects the packet back into the firewall > > That's what I could get out of divert(4) and some of the natd source. > Bare with me...I'm a novice programmer. > > Is this correct? > Pretty much correct. 1) kernel sends packet to divert socket 2) natd reads from divert socket 3) natd screws with it 4) natd writes the packet to divert socket; the packet is treated as a completely new entity 5) divert socket's output routine reinjects the packet back "into the normal kernel IP packet processing", not into firewall Such questions are best answered on -net Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 0:19:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 7AA2B37B71A for ; Fri, 16 Mar 2001 00:19:47 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 1106B81D01; Fri, 16 Mar 2001 02:19:37 -0600 (CST) Date: Fri, 16 Mar 2001 02:19:37 -0600 From: Bill Fumerola To: Mike Cc: "'freebsd-net@freebsd.org'" Subject: Re: translate from iptables Message-ID: <20010316021937.H362@elvis.mu.org> References: <710709BB8B02D311942E00606744181054429B@MELEXC01> <003d01c0ade5$d043e380$0200a8c0@SHIVA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003d01c0ade5$d043e380$0200a8c0@SHIVA>; from miker@superior.net on Fri, Mar 16, 2001 at 01:53:25AM -0500 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Mar 16, 2001 at 01:53:25AM -0500, Mike wrote: > What I'm hoping is that someone will be able to tell me a way to do this > same thing using natd or ipfwd or something like that. Any hints or help > would be much appreciated:) ipfwd isn't what you want, natd is. read the man page on natd (there is an installation guide in the page) and read the parts of the configuration for "-redirect_port". -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 1:22:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id 9FB2737B719 for ; Fri, 16 Mar 2001 01:22:12 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id f2G9M9A88750; Fri, 16 Mar 2001 10:22:09 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.2/8.11.0) id f2G9M0611896; Fri, 16 Mar 2001 10:22:00 +0100 (CET) (envelope-from asmodai) Date: Fri, 16 Mar 2001 10:21:59 +0100 From: Jeroen Ruigrok/Asmodai To: Mohana Krishna Penumetcha Cc: net@freebsd.org Subject: Re: strange arp packets!!! Message-ID: <20010316102159.B11527@daemon.ninth-circle.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from pmk@sasi.com on Fri, Mar 16, 2001 at 10:37:07AM +0530 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20010316 06:25], Mohana Krishna Penumetcha (pmk@sasi.com) wrote: >16:41:25.623476 arp who-has 0.0.0.0 tell 10.0.36.130 >16:41:30.639372 arp who-has 0.0.0.0 tell 10.0.36.130 >16:41:40.649838 arp who-has 0.0.0.0 tell 10.0.36.130 >16:41:45.631430 arp who-has 0.0.0.0 tell 10.0.36.130 >16:41:50.640533 arp who-has 0.0.0.0 tell 10.0.36.130 >16:42:00.651104 arp who-has 0.0.0.0 tell 10.0.36.130(--> pcs130) > >i am little confused what this means, since 0.0.0.0 means "this host"? Not necessarily, 0.0.0.0 can also mean default gateway, which is the more common use nowadays. 0.0.0.0 for `this host' is an old use IIRC. >or is it that, it is meant to update the arp entry corresponding to >pcs130 on other hosts in the subnet? in this case, it can as well say >"10.0.36.130" instead of "0.0.0.0". I am not sure right now, might be because my head's a little foggy. What does arp -a and netstat -rn look like on the FreeBSD box and on the Linux box? -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 All of us visionaires with a rope around our neck... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 1:29:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from kabir.zssm.zp.ua (kabir.zssm.zp.ua [212.8.32.6]) by hub.freebsd.org (Postfix) with ESMTP id 8165037B719; Fri, 16 Mar 2001 01:29:22 -0800 (PST) (envelope-from paranoid@brain-fag.org) Received: (from eugene@localhost) by kabir.zssm.zp.ua (8.9.3/8.9.3) id LAA51437; Fri, 16 Mar 2001 11:29:15 +0200 (EET) (envelope-from paranoid@brain-fag.org) Date: Fri, 16 Mar 2001 11:29:15 +0200 From: Eugene Polovnikov To: net@freebsd.org, current@freebsd.org Subject: nos-tun & multihomed machines Message-ID: <20010316112914.A50671@zssm.zp.ua> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-NCC-RegID: ua.bonk Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi! Please, review the following PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=25847 Same patch is in the attach. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/CC/IT d-@ s: a- C++ UBSC++++$ P++>+++@ L- E--- W+ N++ o? K? w>-- O- M- V- PS@ PE@ Y+ PGP>+ t 5 X R tv- b+++(++++) DI-- D+(++) G>++ e- h--- r y+++ ------END GEEK CODE BLOCK------ --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p --- nos-tun.c.orig Fri Mar 16 11:01:38 2001 +++ nos-tun.c Fri Mar 16 11:17:35 2001 @@ -239,11 +239,13 @@ char *point_to = NULL; char *to_point = NULL; char *target; + char *source = NULL; char *protocol = NULL; int protnum; struct sockaddr t_laddr; /* Source address of tunnel */ struct sockaddr whereto; /* Destination of tunnel */ + struct sockaddr wherefrom; /* Source of tunnel */ struct sockaddr_in *to; char buf[0x2000]; /* Packets buffer */ @@ -272,7 +274,7 @@ argc -= optind; argv += optind; - if (argc != 1 || (devname == NULL) || + if ((argc != 1 && argc != 2) || (devname == NULL) || (point_to == NULL) || (to_point == NULL)) { usage(); } @@ -282,7 +284,11 @@ else protnum = atoi(protocol); - target = *argv; + if (argc == 1) { + target = *argv; + } else { + source = *argv++; target = *argv; + } /* Establish logging through 'syslog' */ openlog("nos-tun", LOG_PID, LOG_DAEMON); @@ -306,6 +312,15 @@ Finish(5); } + if (source) { + if (Set_address(source, (struct sockaddr_in *)&wherefrom)) + Finish(9); + if (bind(net, &wherefrom, sizeof(wherefrom)) < 0) { + syslog(LOG_ERR, "can't bind source address - %m"); + Finish(10); + } + } + if (connect(net,&whereto,sizeof(struct sockaddr_in)) < 0 ) { syslog(LOG_ERR,"can't connect to target - %m"); close(net); @@ -365,7 +380,7 @@ usage() { fprintf(stderr, -"usage: nos-tun -t -s -d -p \n"); +"usage: nos-tun -t -s -d -p [] \n"); exit(1); } --OXfL5xGRrasGEqWY-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 1:37: 4 2001 Delivered-To: freebsd-net@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id 74C8F37B719; Fri, 16 Mar 2001 01:36:58 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id f2G9atA90146; Fri, 16 Mar 2001 10:36:55 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.2/8.11.0) id f2G9ar312004; Fri, 16 Mar 2001 10:36:53 +0100 (CET) (envelope-from asmodai) Date: Fri, 16 Mar 2001 10:36:53 +0100 From: Jeroen Ruigrok/Asmodai To: Garrett Wollman Cc: Hajimu UMEMOTO , alpha@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: IPv4 address is not unsigned int Message-ID: <20010316103653.C11527@daemon.ninth-circle.org> References: <20010315.015316.85344842.ume@FreeBSD.org> <200103141700.MAA49232@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200103141700.MAA49232@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Wed, Mar 14, 2001 at 12:00:29PM -0500 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20010314 18:30], Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote: >< said: >> +in_addr_t inet_lnaof __P((struct in_addr)); >> +struct in_addr inet_makeaddr __P((in_addr_t, in_addr_t)); >> +in_addr_t inet_netof __P((struct in_addr)); > >If anything, these interfaces should be removed. Then we need to fix some code first, since, for example, inet_makeaddr() is still used. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Seek, and ye shall find; knock, and it shall be opened unto you... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 1:50:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id B990037B719; Fri, 16 Mar 2001 01:50:32 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id f2G9oU560395; Fri, 16 Mar 2001 10:50:30 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.2/8.11.0) id f2G9oRt12206; Fri, 16 Mar 2001 10:50:27 +0100 (CET) (envelope-from asmodai) Date: Fri, 16 Mar 2001 10:50:26 +0100 From: Jeroen Ruigrok/Asmodai To: Eugene Polovnikov Cc: net@freebsd.org, current@freebsd.org Subject: Re: nos-tun & multihomed machines Message-ID: <20010316105026.A12010@daemon.ninth-circle.org> References: <20010316112914.A50671@zssm.zp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010316112914.A50671@zssm.zp.ua>; from paranoid@brain-fag.org on Fri, Mar 16, 2001 at 11:29:15AM +0200 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20010316 10:43], Eugene Polovnikov (paranoid@brain-fag.org) wrote: >Please, review the following PR: >http://www.freebsd.org/cgi/query-pr.cgi?pr=25847 > >Same patch is in the attach. Just a question, the gif interface now part of the system does tunneling as well in as much the same way as nos-tun does. Does gif work for the multihomed case? [I'll otherwise when not getting any responses dig up the answer myself.] I ask this because it serves no purpose having an IPv4-only [as far as my knowledge goes] tunnel application, whilst we have a more flexible new solution present. Translated, does gif do what nos-tun can do and more? Yes? Let's rip out nos-tun and support the other well maintained solution. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Don't try to find the Answer where there ain't no Question here... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 2: 8:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 876A137B71A for ; Fri, 16 Mar 2001 02:08:10 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id f2GA87c62450; Fri, 16 Mar 2001 11:08:07 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.2/8.11.0) id f2GA83I12327; Fri, 16 Mar 2001 11:08:03 +0100 (CET) (envelope-from asmodai) Date: Fri, 16 Mar 2001 11:08:03 +0100 From: Jeroen Ruigrok/Asmodai To: Nick Rogness Cc: freebsd-net@freebsd.org Subject: Re: same interface Route Cache Message-ID: <20010316110803.B12010@daemon.ninth-circle.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from nick@rogness.net on Fri, Mar 09, 2001 at 09:05:31PM -0600 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20010310 04:00], Nick Rogness (nick@rogness.net) wrote: > >Is anyone working on route caching functionality within FreeBSD? This >would eliminate a lot of problems with using FreeBSD as a router...which >seems to be a common role of which FreeBSD seems to fit. Especially for >machine that are dual-homed. Correct me if wrong, but if I recall BSD natively already held a route cache, although it might not be the best route cache which we could come up with. I'll add this to my todo as well. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 All art is but imitation of Nature... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 2:23:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id 3B77737B718; Fri, 16 Mar 2001 02:23:55 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id f2GANq495037; Fri, 16 Mar 2001 11:23:52 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.2/8.11.0) id f2GALtj12410; Fri, 16 Mar 2001 11:21:55 +0100 (CET) (envelope-from asmodai) Date: Fri, 16 Mar 2001 11:21:54 +0100 From: Jeroen Ruigrok/Asmodai To: "Matthew N. Dodd" Cc: freebsd-tokenring@freebsd.org, freebsd-net@freebsd.org Subject: Re: Token Ring and IPX. Message-ID: <20010316112154.C12010@daemon.ninth-circle.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from winter@jurai.net on Fri, Mar 09, 2001 at 05:38:06AM -0500 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20010309 12:00], Matthew N. Dodd (winter@jurai.net) wrote: >Interested parties will also note that tcpdump is unable to properly >decode IPX packets over token ring; I've got a fix for this too... Matthew, am I correct in my assumption that all fixes needed for tcpdump can be handled in our own sources? Or do we need to send these to tcpdump.org? -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 No cord or cable can draw so forcibly, or bind so fast, as love can do with a single thread... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 2:31:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id E712437B718 for ; Fri, 16 Mar 2001 02:31:08 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from mobile.wemm.org (mobile.wemm.org [10.0.0.5]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f2GAV8p58110 for ; Fri, 16 Mar 2001 02:31:08 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f2GAV7h94432; Fri, 16 Mar 2001 02:31:07 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200103161031.f2GAV7h94432@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jonathan Lemon Cc: Ollivier Robert , cnielsen@pobox.com, net@FreeBSD.ORG Subject: Re: Intel PRO/100+ PCI problem In-Reply-To: <20010315110343.B82645@prism.flugsvamp.com> Date: Fri, 16 Mar 2001 02:31:07 -0800 From: Peter Wemm Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon wrote: > On Thu, Mar 15, 2001 at 05:20:58AM -0800, Peter Wemm wrote: > > > fxp0: port 0xff20-0xff3f mem 0xff800000 -0xf > > f8fffff,0xffbde000-0xffbdefff irq 2 at device 6.0 on pci0 > > > fxp0: using memory space register mapping > > > fxp0: Ethernet address 00:a0:c9:49:aa:d3 > > > fxp0: PCI IDs: 8086 1229 0000 0000 > > > nsphy0: on miibus0 > > > nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > bpf: fxp0 attached > > > > > > This actually does have the NatSemi phy on it and it is correctly detecte d. > > > Unfortunately, I just locked that machine up with SMPng. oops. I can't > > > verify that it works just yet.. We have another old machine with a NS > > > phy on it (pII based instead of PPro based) and are working on it now. > > > > It appears that the nsphy version is unable to actually transmit packets. > > It is recieving OK, just not sending. (or, the other machines are unable > > to see it, maybe the switch is dropping the packets as "damaged" or > > something?) > > Try this following patch to mii/nsphy.c. It appears that we need to > toggle some undocumented bits in order to get this PHY to work with > the fxp driver. > -- > Jonathan [patch trimmed] That did the trick! fxp0: port 0xff20-0xff3f mem 0xff800000-0xff8fffff,0xffbde000-0xffbdefff irq 2 at device 6.0 on pci0 fxp0: Ethernet address 00:a0:c9:49:aa:d3 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 7.0 on pci0 [2:28am]~-108# ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.655 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.430 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=0.469 ms ^C --- 10.0.0.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.430/0.518/0.655/0.098 ms [2:28am]~-109# ifconfig -a fxp0: flags=8843 mtu 1500 inet 10.0.0.16 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:a0:c9:49:aa:d3 media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX [2:30am]~-118# arp -an ? (10.0.0.1) at 0:d0:b7:1e:7b:de [ethernet] ? (10.0.0.2) at 0:90:27:58:45:32 [ethernet] ? (10.0.0.3) at 0:90:27:58:45:e4 [ethernet] ? (10.0.0.4) at 0:c0:2:51:69:31 [ethernet] ? (10.0.0.5) at 0:60:1d:f0:d5:86 [ethernet] ? (10.0.0.16) at 0:a0:c9:49:aa:d3 permanent [ethernet] ? (10.0.0.17) at 0:2:b3:15:84:20 [ethernet] ? (10.0.0.18) at 0:e0:81:11:25:e0 [ethernet] Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 2:41:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254]) by hub.freebsd.org (Postfix) with ESMTP id A242437B71D for ; Fri, 16 Mar 2001 02:41:48 -0800 (PST) (envelope-from roberto@eurocontrol.fr) Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.51.214]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "caerdonn.eurocontrol.fr", Issuer CN "CA ITM" (verified OK)) by matrix.eurocontrol.fr (Postfix/TLS) with ESMTP id D4A985C2F; Fri, 16 Mar 2001 11:41:47 +0100 (CET) Received: by caerdonn.eurocontrol.fr (Postfix/TLS, from userid 1193) id BC10D1C7; Fri, 16 Mar 2001 11:41:46 +0100 (CET) Date: Fri, 16 Mar 2001 11:41:46 +0100 From: Ollivier Robert To: Peter Wemm Cc: Jonathan Lemon , cnielsen@pobox.com, net@FreeBSD.ORG Subject: Re: Intel PRO/100+ PCI problem Message-ID: <20010316114146.A860@caerdonn.eurocontrol.fr> References: <20010315110343.B82645@prism.flugsvamp.com> <200103161031.f2GAV7h94432@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103161031.f2GAV7h94432@mobile.wemm.org>; from peter@netplex.com.au on Fri, Mar 16, 2001 at 02:31:07AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Peter Wemm: > That did the trick! Mine is working as well, thanks. FreeBSD 5.0-CURRENT #53: Fri Mar 16 09:47:20 CET 2001 roberto@caerdonn.eurocontrol.fr:/src/src/sys/compile/CAERDONN ... fxp0: port 0xfcc0-0xfcdf mem 0xfed00000-0xfedfffff,0xfecfe000-0xfecfefff irq 9 at device 17.0 on pci0 fxp0: Ethernet address 08:00:09:dc:23:7e nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0@pci0:17:0: class=0x020000 card=0x00000000 chip=0x12298086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 Fast Ethernet LAN Controller' class = network subclass = ethernet -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- Ollivier.Robert@eurocontrol.fr FreeBSD caerdonn.eurocontrol.fr 5.0-CURRENT #46: Wed Jan 3 15:52:00 CET 2001 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 2:42:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id A678237B719; Fri, 16 Mar 2001 02:42:45 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f2GAekc79979; Fri, 16 Mar 2001 12:40:46 +0200 (EET) (envelope-from ru) Date: Fri, 16 Mar 2001 12:40:46 +0200 From: Ruslan Ermilov To: Jeroen Ruigrok/Asmodai Cc: Eugene Polovnikov , net@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: nos-tun & multihomed machines Message-ID: <20010316124046.D67000@sunbay.com> Mail-Followup-To: Jeroen Ruigrok/Asmodai , Eugene Polovnikov , net@FreeBSD.ORG, current@FreeBSD.ORG References: <20010316112914.A50671@zssm.zp.ua> <20010316105026.A12010@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316105026.A12010@daemon.ninth-circle.org>; from asmodai@wxs.nl on Fri, Mar 16, 2001 at 10:50:26AM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Mar 16, 2001 at 10:50:26AM +0100, Jeroen Ruigrok/Asmodai wrote: > -On [20010316 10:43], Eugene Polovnikov (paranoid@brain-fag.org) wrote: > Hello, Engene! Hope you are doing well! :-) > >Please, review the following PR: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=25847 > > > >Same patch is in the attach. > > Just a question, > > the gif interface now part of the system does tunneling as well in as > much the same way as nos-tun does. Does gif work for the multihomed > case? [I'll otherwise when not getting any responses dig up the answer > myself.] > Yes, gif(4) works the same way, and multihomed enabled (see gifconfig(8)), with the exception that it always uses the IPPROTO_IPV4 (protocol 4) for encapsulating of IPv4 payload. > I ask this because it serves no purpose having an IPv4-only [as far as > my knowledge goes] tunnel application, whilst we have a more flexible > new solution present. > I fully agree. > Translated, does gif do what nos-tun can do and more? Yes? Let's rip > out nos-tun and support the other well maintained solution. > Except that it does not allow to use proto 94 (the default for nos-tun). Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 3:58:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id C470437B718; Fri, 16 Mar 2001 03:58:13 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by njord.bart.nl (8.10.1/8.10.1) with ESMTP id f2GBwAr74650; Fri, 16 Mar 2001 12:58:10 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.2/8.11.0) id f2GBw7213236; Fri, 16 Mar 2001 12:58:07 +0100 (CET) (envelope-from asmodai) Date: Fri, 16 Mar 2001 12:58:06 +0100 From: Jeroen Ruigrok/Asmodai To: Eugene Polovnikov , net@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: nos-tun & multihomed machines Message-ID: <20010316125806.J12010@daemon.ninth-circle.org> References: <20010316112914.A50671@zssm.zp.ua> <20010316105026.A12010@daemon.ninth-circle.org> <20010316124046.D67000@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010316124046.D67000@sunbay.com>; from ru@FreeBSD.ORG on Fri, Mar 16, 2001 at 12:40:46PM +0200 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20010316 12:45], Ruslan Ermilov (ru@FreeBSD.ORG) wrote: >On Fri, Mar 16, 2001 at 10:50:26AM +0100, Jeroen Ruigrok/Asmodai wrote: >> -On [20010316 10:43], Eugene Polovnikov (paranoid@brain-fag.org) wrote: [gif versus nos-tun] >Yes, gif(4) works the same way, and multihomed enabled (see gifconfig(8)), >with the exception that it always uses the IPPROTO_IPV4 (protocol 4) for >encapsulating of IPv4 payload. [gif preferred over nos-tun] >I fully agree. Noted. >> Translated, does gif do what nos-tun can do and more? Yes? Let's rip >> out nos-tun and support the other well maintained solution. >> >Except that it does not allow to use proto 94 (the default for nos-tun). I'm sure we can work something out with the KAME guys over this, if it is necessary to keep this in. *chalks up another task* -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 In the dark backward and abysm of time... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 4:40:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 1B67C37B719; Fri, 16 Mar 2001 04:40:22 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f2GCdAa92070; Fri, 16 Mar 2001 14:39:10 +0200 (EET) (envelope-from ru) Date: Fri, 16 Mar 2001 14:39:10 +0200 From: Ruslan Ermilov To: Jeroen Ruigrok/Asmodai Cc: Eugene Polovnikov , net@FreeBSD.ORG Subject: Re: nos-tun & multihomed machines Message-ID: <20010316143910.B90057@sunbay.com> Mail-Followup-To: Jeroen Ruigrok/Asmodai , Eugene Polovnikov , net@FreeBSD.ORG References: <20010316112914.A50671@zssm.zp.ua> <20010316105026.A12010@daemon.ninth-circle.org> <20010316124046.D67000@sunbay.com> <20010316125806.J12010@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316125806.J12010@daemon.ninth-circle.org>; from asmodai@wxs.nl on Fri, Mar 16, 2001 at 12:58:06PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [-current dropped (Bcc'ed)] On Fri, Mar 16, 2001 at 12:58:06PM +0100, Jeroen Ruigrok/Asmodai wrote: > -On [20010316 12:45], Ruslan Ermilov (ru@FreeBSD.ORG) wrote: > >On Fri, Mar 16, 2001 at 10:50:26AM +0100, Jeroen Ruigrok/Asmodai wrote: > >> -On [20010316 10:43], Eugene Polovnikov (paranoid@brain-fag.org) wrote: > > [gif versus nos-tun] > > >Yes, gif(4) works the same way, and multihomed enabled (see gifconfig(8)), > >with the exception that it always uses the IPPROTO_IPV4 (protocol 4) for > >encapsulating of IPv4 payload. > > [gif preferred over nos-tun] > > >I fully agree. > > Noted. > > >> Translated, does gif do what nos-tun can do and more? Yes? Let's rip > >> out nos-tun and support the other well maintained solution. > >> > >Except that it does not allow to use proto 94 (the default for nos-tun). > > I'm sure we can work something out with the KAME guys over this, if it > is necessary to keep this in. *chalks up another task* > It should be pretty easy to add the ``int gif_pproto'' member to the gif_softc structure, and expand gif_ioctl() interface to handle smth like SIOC[SG]IFPPROTO (where PPROTO stands for "physical protocol"). Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 5:26:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from nimbus.superior.net (nimbus.superior.net [216.238.144.3]) by hub.freebsd.org (Postfix) with ESMTP id 8AFF337B71A for ; Fri, 16 Mar 2001 05:26:50 -0800 (PST) (envelope-from miker@superior.net) Received: from mleach (gatekeeper1-jtn.corp.thebiz.net [216.238.128.67]) by nimbus.superior.net (8.9.3/8.9.3/RB) with SMTP id IAA04482; Fri, 16 Mar 2001 08:26:49 -0500 (EST) Message-ID: <000c01c0ae1c$c1540440$f0ff000a@corp.thebiz.net> From: "Mike" To: "Bill Fumerola" Cc: "'freebsd-net@freebsd.org'" References: <710709BB8B02D311942E00606744181054429B@MELEXC01> <003d01c0ade5$d043e380$0200a8c0@SHIVA> <20010316021937.H362@elvis.mu.org> Subject: Re: translate from iptables Date: Fri, 16 Mar 2001 08:26:48 -0500 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks, I'll see what I can find out from there:) Mike > On Fri, Mar 16, 2001 at 01:53:25AM -0500, Mike wrote: > > What I'm hoping is that someone will be able to tell me a way to do this > > same thing using natd or ipfwd or something like that. Any hints or help > > would be much appreciated:) > > ipfwd isn't what you want, natd is. read the man page on natd (there > is an installation guide in the page) and read the parts of the > configuration for "-redirect_port". > > -- > Bill Fumerola - security yahoo / Yahoo! inc. > - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 6:40:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from kabir.zssm.zp.ua (kabir.zssm.zp.ua [212.8.32.6]) by hub.freebsd.org (Postfix) with ESMTP id A5EA137B719; Fri, 16 Mar 2001 06:40:22 -0800 (PST) (envelope-from paranoid@brain-fag.org) Received: (from eugene@localhost) by kabir.zssm.zp.ua (8.9.3/8.9.3) id QAA52864; Fri, 16 Mar 2001 16:40:16 +0200 (EET) (envelope-from paranoid@brain-fag.org) Date: Fri, 16 Mar 2001 16:40:16 +0200 From: Eugene Polovnikov To: Ruslan Ermilov Cc: Jeroen Ruigrok/Asmodai , net@FreeBSD.ORG Subject: Re: nos-tun & multihomed machines Message-ID: <20010316164016.A52749@zssm.zp.ua> References: <20010316112914.A50671@zssm.zp.ua> <20010316105026.A12010@daemon.ninth-circle.org> <20010316124046.D67000@sunbay.com> <20010316125806.J12010@daemon.ninth-circle.org> <20010316143910.B90057@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010316143910.B90057@sunbay.com>; from ru@FreeBSD.ORG on Fri, Mar 16, 2001 at 02:39:10PM +0200 X-NCC-RegID: ua.bonk Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > >> > > >Except that it does not allow to use proto 94 (the default for nos-tun). > > > > I'm sure we can work something out with the KAME guys over this, if it > > is necessary to keep this in. *chalks up another task* > > > It should be pretty easy to add the ``int gif_pproto'' member to the > gif_softc structure, and expand gif_ioctl() interface to handle smth > like SIOC[SG]IFPPROTO (where PPROTO stands for "physical protocol"). At least it's need to add some mechanism for dynamic changing of inetsw. Something like that must exist in netgraph, IIRC. And I agree that when all nos-tun's functions be implemented nos-tun must go away. But can anyone say when ? -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/CC/IT d-@ s: a- C++ UBSC++++$ P++>+++@ L- E--- W+ N++ o? K? w>-- O- M- V- PS@ PE@ Y+ PGP>+ t 5 X R tv- b+++(++++) DI-- D+(++) G>++ e- h--- r y+++ ------END GEEK CODE BLOCK------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 6:58: 8 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 524AB37B718; Fri, 16 Mar 2001 06:58:05 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2GF2Ff09814; Fri, 16 Mar 2001 09:02:15 -0600 (CST) (envelope-from nick@rogness.net) Date: Fri, 16 Mar 2001 09:02:15 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Ruslan Ermilov Cc: net@FreeBSD.ORG Subject: Re: natd divert injecting clarifications In-Reply-To: <20010316095627.C62097@sunbay.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 Fri, 16 Mar 2001, Ruslan Ermilov wrote: > Pretty much correct. > > 1) kernel sends packet to divert socket > 2) natd reads from divert socket > 3) natd screws with it > 4) natd writes the packet to divert socket; the packet > is treated as a completely new entity > 5) divert socket's output routine reinjects the packet > back "into the normal kernel IP packet processing", not into > firewall Hmm. You pass it a 'tag' which, I thought, is the ipfw rule number of the firewall after which rule processing should restart. I think I understand your point though. > > > Such questions are best answered on -net > I sent it to freebsd-ipfw and waited for a day before sending this to hackers. I send lots of email to -net and rarely receive anything back. I wonder if people just skip over it or what? The only list were I can get (at least) a response is -hackers. It is very frustrating finding answers sometimes. Especially when I just need a clarification on something that most programmer's think 'duh stupid'. Anyway, Thanks for the reply...I appreciate it. [Sorry for the rant]. 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 Mar 16 7:24:39 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 CC4D537B718 for ; Fri, 16 Mar 2001 07:24:35 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2GFSi309891; Fri, 16 Mar 2001 09:28:44 -0600 (CST) (envelope-from nick@rogness.net) Date: Fri, 16 Mar 2001 09:28:44 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Jeroen Ruigrok/Asmodai Cc: freebsd-net@FreeBSD.ORG Subject: Re: same interface Route Cache In-Reply-To: <20010316110803.B12010@daemon.ninth-circle.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 Fri, 16 Mar 2001, Jeroen Ruigrok/Asmodai wrote: > -On [20010310 04:00], Nick Rogness (nick@rogness.net) wrote: > > > >Is anyone working on route caching functionality within FreeBSD? This > >would eliminate a lot of problems with using FreeBSD as a router...which > >seems to be a common role of which FreeBSD seems to fit. Especially for > >machine that are dual-homed. > > Correct me if wrong, but if I recall BSD natively already held a route > cache, although it might not be the best route cache which we could come > up with. Well, I'm sure it does have some route cache functionality but not what is considered to be useful. I'll clarify real quick for people who are asking 'why?'. Bare with me. As a packet comes in one interface, there should be a way when the packet comes back out to be sent out that same interface it was received on, regardless of what the default route says. For dual-homed hosts, this is a problem because your packet gets sent out the default gateway, which may or may not get filtered upstream. This is usually solved by running a routing deamon but most upstreams won't allow you to do that anyway (cable,dsl,etc). There is a workaround solution involving natd but it is a pain in the butt. > I'll add this to my todo as well. I've had some ideas on how someone would implement this. The more I think about it the more I think it should be similar to natd. The packet could be diverted like: ipfw divert route-cached ip from any to any in via ed0 or something similar. route-cached could be a userland program, like natd, with options: - setting different gateways for different interfaces - hold down timers ,etc Routes could be added into the routing table accordingly as packets come and go via this daemon. You or someone will have to validate this logic. I may be way off course here...but it was a stab. Maybe it belongs somewhere else. I've been preparing to write such a program, going off the base of natd. Please let me know if this is a good idea or not. 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 Mar 16 7:36:21 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 A2C9237B718; Fri, 16 Mar 2001 07:36:18 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2GFeFM09930; Fri, 16 Mar 2001 09:40:15 -0600 (CST) (envelope-from nick@rogness.net) Date: Fri, 16 Mar 2001 09:40:15 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Eugene Polovnikov Cc: Ruslan Ermilov , Jeroen Ruigrok/Asmodai , net@FreeBSD.ORG Subject: Re: nos-tun & multihomed machines In-Reply-To: <20010316164016.A52749@zssm.zp.ua> 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 Fri, 16 Mar 2001, Eugene Polovnikov wrote: [snip] > > And I agree that when all nos-tun's functions be implemented nos-tun > must go away. One thing I don't like about gif is you have to rebuild the kernel when you want to add another gif interface...or is there another way (besides building it with a huge number up front)? Whereas with nos-tun you just MAKEDEV a new tunnel device and your in business. 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 Mar 16 8:23:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 4E7E637B718; Fri, 16 Mar 2001 08:23:09 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f2GGLu506415; Fri, 16 Mar 2001 08:21:56 -0800 (PST) Message-ID: <3AB23DA4.46939A5B@isi.edu> Date: Fri, 16 Mar 2001 08:21:56 -0800 From: Lars Eggert Organization: USC Information Sciences Institute X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en, de MIME-Version: 1.0 To: Nick Rogness Cc: Eugene Polovnikov , Ruslan Ermilov , Jeroen Ruigrok/Asmodai , net@FreeBSD.ORG, xbone@ISI.EDU Subject: Re: nos-tun & multihomed machines References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA6A3665A2FEB2B5FF599A011" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------msA6A3665A2FEB2B5FF599A011 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nick Rogness wrote: > One thing I don't like about gif is you have to rebuild the kernel > when you want to add another gif interface...or is there another > way (besides building it with a huge number up front)? Whereas > with nos-tun you just MAKEDEV a new tunnel device and your in > business. I fully agree with Nick. Being able to create gifs dynamically would be a big win for us (http://www.isi.edu/xbone/). The old CAIRN distribution of FreeBSD had iti tunnels which you could create or delete by setting a sysctl controlling how many tunnel devices there were. Something like that, or the MAKEDEV way, would be great. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------msA6A3665A2FEB2B5FF599A011 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214 Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1 MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6 6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70 HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMxNjE2MjE1NlowIwYJKoZIhvcNAQkEMRYE FFVTiIG8bTON/h/RF/m9gw+GHw5jMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAAyPVt3/XNqALYZhCR1+/FA3p9KIW39xvFYP/cbC3TkDBHfNVv9mg SkLmBWSo0a4aKadbsOxtfycbwNrBCmdlLq8Efu13FcQdePSY/ip9KXP0QfR6CsUwc6Pr0VMY z3jBCJw6MLHGliBeUL7meXZ1+t1mYq3jA/7VNhDg/NIcFdo= --------------msA6A3665A2FEB2B5FF599A011-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 8:58: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 95B2537B719 for ; Fri, 16 Mar 2001 08:58:00 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f2GGvmH16771; Fri, 16 Mar 2001 18:57:48 +0200 (EET) (envelope-from ru) Date: Fri, 16 Mar 2001 18:57:48 +0200 From: Ruslan Ermilov To: Nick Rogness Cc: net@FreeBSD.ORG Subject: Re: natd divert injecting clarifications Message-ID: <20010316185748.D14036@sunbay.com> Mail-Followup-To: Nick Rogness , net@FreeBSD.ORG References: <20010316095627.C62097@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nick@rogness.net on Fri, Mar 16, 2001 at 09:02:15AM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Mar 16, 2001 at 09:02:15AM -0600, Nick Rogness wrote: > On Fri, 16 Mar 2001, Ruslan Ermilov wrote: > > > Pretty much correct. > > > > 1) kernel sends packet to divert socket > > 2) natd reads from divert socket > > 3) natd screws with it > > 4) natd writes the packet to divert socket; the packet > > is treated as a completely new entity > > 5) divert socket's output routine reinjects the packet > > back "into the normal kernel IP packet processing", not into > > firewall > > Hmm. You pass it a 'tag' which, I thought, is the ipfw > rule number of the firewall after which rule processing should > restart. I think I understand your point though. > I wanted to point you that div_output() (netinet/ip_divert.c) does not call IPFW directly; it is passed a tag from the user process, it then calls either ip_input() or ip_output() depending on whether a packet was written as incoming or outgoing, this this is ip_input() or ip_output() who check with IPFW. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 9: 1:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id DEF3337B719 for ; Fri, 16 Mar 2001 09:01:21 -0800 (PST) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id UAA02533; (8.9.3/vak/2.1) Fri, 16 Mar 2001 20:00:40 +0300 (MSK) Message-ID: <3AB2487D.1020906@cronyx.ru> Date: Fri, 16 Mar 2001 20:08:13 +0300 From: Kurakin Roman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: ru, en MIME-Version: 1.0 To: net@FreeBSD.ORG Subject: Multiport serial non PnP ISA card with 4.2 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I wonder, does some one use multiport serial card for ISA bus that didn't support PnP under FreeBSD 4.2? I have some problems with such card. I have some suspicions that this problem with all non PNP serial ISA cards on all 4.x Probably because driver expects existence of probed PnP device. Any suggestions? Kurakin Roman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 9:21:44 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 24A7B37B718 for ; Fri, 16 Mar 2001 09:21:35 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA60464; Fri, 16 Mar 2001 12:21:25 -0500 (EST) (envelope-from wollman) Date: Fri, 16 Mar 2001 12:21:25 -0500 (EST) From: Garrett Wollman Message-Id: <200103161721.MAA60464@khavrinen.lcs.mit.edu> To: Jeroen Ruigrok/Asmodai Cc: net@FreeBSD.ORG Subject: Re: IPv4 address is not unsigned int In-Reply-To: <20010316103653.C11527@daemon.ninth-circle.org> References: <20010315.015316.85344842.ume@FreeBSD.org> <200103141700.MAA49232@khavrinen.lcs.mit.edu> <20010316103653.C11527@daemon.ninth-circle.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Then we need to fix some code first, since, for example, inet_makeaddr() > is still used. Indeed, since anything which uses inet_makeaddr() is by definition broken. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 9:32:39 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 176ED37B719 for ; Fri, 16 Mar 2001 09:32:35 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA60083; Fri, 16 Mar 2001 11:40:15 -0500 (EST) (envelope-from wollman) Date: Fri, 16 Mar 2001 11:40:15 -0500 (EST) From: Garrett Wollman Message-Id: <200103161640.LAA60083@khavrinen.lcs.mit.edu> To: Jeroen Ruigrok/Asmodai Cc: freebsd-net@FreeBSD.ORG Subject: Re: same interface Route Cache In-Reply-To: <20010316110803.B12010@daemon.ninth-circle.org> References: <20010316110803.B12010@daemon.ninth-circle.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Correct me if wrong, but if I recall BSD natively already held a route > cache, although it might not be the best route cache which we could come > up with. It does, but there is only a single route cached there. A better implementation might have a small hash table (e.g., 16 entries), but that could make things more complex when we decide to delete a route. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 16 10:19:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 6F8A237B719; Fri, 16 Mar 2001 10:19:19 -0800 (PST) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f2GIJGa23052; Fri, 16 Mar 2001 20:19:16 +0200 (EET) (envelope-from ru) Date: Fri, 16 Mar 2001 20:19:16 +0200 From: Ruslan Ermilov To: net@FreeBSD.org Cc: Garrett Wollman Subject: Reading Stevens, playing routing games Message-ID: <20010316201916.A20185@sunbay.com> Mail-Followup-To: net@FreeBSD.org, Garrett Wollman Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! First of all, I would like to commit the attached patch; it removes duplicate code. Please review. Also, I found a nasty bug in IP routing. The new route added may not take immediate effect for routing decisions, because ip_forward() may use the cached route (rt_forwarding). DEMO (only relevant routes are shown). Step 1. On a router, add a route to the network (192.168.1). : # route add -net 192.168.1 gateway : add net 192.168.1: gateway gateway : : # netstat -rn : Routing tables : : Internet: : Destination Gateway Flags Refs Use Netif Expire : 192.168.1 gateway UGSc 0 0 rl0 Step 2. From some other host for which this machine is the default router, run ``traceroute -m 2 -n 192.168.1.1''. Observe, on the router, that the reference count grown on the 192.168.1 route. : # netstat -rn : Routing tables : : Internet: : Destination Gateway Flags Refs Use Netif Expire : 192.168.1 gateway UGSc 1 3 rl0 Step 3. Add RTF_REJECT host route to the destination: : # route add 192.168.1.1 -iface lo0 -reject : add host 192.168.1.1: gateway lo0 : # netstat -rn : Routing tables : : Internet: : Destination Gateway Flags Refs Use Netif Expire : 192.168.1 gateway UGSc 1 3 rl0 : 192.168.1.1 lo0 UHRS 0 0 lo0 Step 4. The fun begins. What you would expect if you run traceroute to 192.168.1.1 again? Obviously host route should take precedence over network route, and I expected ICMP Destination Unreachable. But... what's a hell? the new route did not take immediate effect, traceroute succeeded (192.168.1.1 still has zero refcound and use): : # netstat -rn : Routing tables : : Internet: : Destination Gateway Flags Refs Use Netif Expire : 192.168.1 gateway UGSc 1 6 rl0 : 192.168.1.1 lo0 UHRS 0 0 lo0 Step 5. The fun continues. From another host, run traceroute to another destination (to help router change rt_forward.ro_dst). traceroute -m 2 -n 192.168.1.2: : # netstat -rn : Routing tables : : Internet: : Destination Gateway Flags Refs Use Netif Expire : 192.168.1 gateway UGSc 1 9 rl0 : 192.168.1.1 lo0 UHRS 0 0 lo0 Step 6. Run traceroute again to 192.168.1.1. The fun ends. The solution I found so far is to unstaticize the ``rt_forward'', and invalidate the rt_forward.ro_rt in in_addroute() (in_rmx.c). Any better ideas? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.162 diff -u -p -r1.162 ip_input.c --- ip_input.c 2001/03/08 19:03:26 1.162 +++ ip_input.c 2001/03/16 17:34:30 @@ -1507,7 +1507,6 @@ ip_forward(m, srcrt) int srcrt; { register struct ip *ip = mtod(m, struct ip *); - register struct sockaddr_in *sin; register struct rtentry *rt; int error, type = 0, code = 0; struct mbuf *mcopy; @@ -1543,24 +1542,11 @@ ip_forward(m, srcrt) } #endif - sin = (struct sockaddr_in *)&ipforward_rt.ro_dst; - if ((rt = ipforward_rt.ro_rt) == 0 || - ip->ip_dst.s_addr != sin->sin_addr.s_addr) { - if (ipforward_rt.ro_rt) { - RTFREE(ipforward_rt.ro_rt); - ipforward_rt.ro_rt = 0; - } - sin->sin_family = AF_INET; - sin->sin_len = sizeof(*sin); - sin->sin_addr = ip->ip_dst; - - rtalloc_ign(&ipforward_rt, RTF_PRCLONING); - if (ipforward_rt.ro_rt == 0) { - icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_HOST, dest, 0); - return; - } + if (ip_rtaddr(ip->ip_dst) == 0) { + icmp_error(m, ICMP_UNREACH, ICMP_UNREACH_HOST, dest, 0); + return; + } else rt = ipforward_rt.ro_rt; - } /* * Save the IP header and at most 8 bytes of the payload, --ew6BAiZeqk4r7MaW-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 1:41:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id 8599437B718; Sat, 17 Mar 2001 01:41:49 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id EAA47330; Sat, 17 Mar 2001 04:41:47 -0500 (EST) Date: Sat, 17 Mar 2001 04:41:47 -0500 (EST) From: "Matthew N. Dodd" To: Jeroen Ruigrok/Asmodai Cc: freebsd-tokenring@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Token Ring and IPX. In-Reply-To: <20010316112154.C12010@daemon.ninth-circle.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 Fri, 16 Mar 2001, Jeroen Ruigrok/Asmodai wrote: > am I correct in my assumption that all fixes needed for tcpdump can be > handled in our own sources? Or do we need to send these to > tcpdump.org? I'm fairly sure we'll need to submit them to tcpdump.org. I need to verify that I've got the IPX support correct first though. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 5:39:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from stewart.chicago.il.us (dsl-64-128-23-213.telocity.com [64.128.23.213]) by hub.freebsd.org (Postfix) with ESMTP id D4FFE37B718 for ; Sat, 17 Mar 2001 05:39:29 -0800 (PST) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.11.0/8.11.0) with ESMTP id f2HDewO05045; Sat, 17 Mar 2001 07:40:58 -0600 Message-ID: <3AB3696A.26430DF@stewart.chicago.il.us> Date: Sat, 17 Mar 2001 07:40:58 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.17-14 i686) X-Accept-Language: en MIME-Version: 1.0 To: net@FreeBSD.org, sigtran@standards.nortelnetworks.com, tsvwg@ietf.org Subject: New SCTP reference implementation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear All: This message is to notify you of a new SCTP reference implementation available at: http://www.sctp.chicago.il.us Version 4.0.3 is now the current version... now for the list of features new to this implementation: ***IPv6 support. ***Support for FreeBSD kernel. There has been MAJOR restructuring to make the implementation IPv6 compliant. I have tested the major paths of the code BUT NOT some of the extensions. In particular the ADD-IP/DEL-IP/Set-Primary feature added in 4.0.2 has NOT been tested and will probably cause cores :0 I will test these and provide a new release as soon as I can ... sigh... Now the Kernel implementation support in FreeBSD is rock solid. Basically all the usual libraries are used, but the ole SCTP deamon has been moved into the kernel. You will find a new directory FreeBsdKern. Under this directory is netinet netinet6 and conf I am working off FreeBSD RELEASE.. I intend to move to STABLE soon but for now I wanted something really stable :) The conf has the updated 'files' that adds the new sctp files to the build. Copy or merge this with yours. The net directories contain the sctp code AND some modifications (very slight) to some of the modules. You can diff them to find the minor change ... in_proto for example.. But there is two new functions added to the in_pcb handling... this helps in the lib support of pmtu discovery (which I have not yet tested however so be aware this may not be too rock solid :0 Has soon as I can get through all my regression I will attempt to submit my changes to the FreeBSD community and see if they wish to adopt the kernel changes AND the library... There is also ongoing work to build a socket API stub that can be put in to match the SCTP sockets draft... more on this when it evolves.... Now For you linux folks you will find a LinuxKern directory with a ipv6/raw.c under it. This is because Linux has some real problems in its ipv6 stack (at least Redhat 7)in the use of raw sockets. It will NOT allow you to gain access to the full IPV6 header (which the sctp deamon needs). And even worse it does not let you put out a full IPv6 packet.. This fixes this to some degree but there are still problems since the stack is not capable of recognizing the address-unspecifed and filling it in with the interface address.... Beware if you use IPv6 with linux you may be in for some problems... I may go back and fix all of this and get the same SCTP deamon move to the kernel in place for linux but not now.. no cycles... sigh... Now as to Aix/True64/Solaris... I have no idea if the IPv6 code will work... I have no way to test this.. Please report problems to me and I will attempt to fix any issues... Enjoy R -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 6:41:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 919B437B71A; Sat, 17 Mar 2001 06:41:22 -0800 (PST) (envelope-from ume@FreeBSD.org) Received: from localhost (IDENT:WJXqsQemxu+a/yZiE2qXmkBE3bNU35d4dLIM4cGPDO8qQDnDmzsh1EhBuVcaAW/R@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.3/8.11.3/peace) with ESMTP/inet6 id f2HEbwR83437; Sat, 17 Mar 2001 23:38:00 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Sat, 17 Mar 2001 23:37:58 +0900 (JST) Message-Id: <20010317.233758.21880242.ume@FreeBSD.org> To: audit@FreeBSD.org, net@FreeBSD.org Subject: [CFR] IPv6 support for skeyaccess(3) From: Hajimu UMEMOTO X-Mailer: Mew version 1.95b97 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT 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 Hi, I wish to support IPv6 for skeyaccess(3). With this patch, you can specify IPv6 address using `internet' keyword into /etc/skey.access. Please review it. Index: lib/libskey/skeyaccess.c diff -u lib/libskey/skeyaccess.c.orig lib/libskey/skeyaccess.c --- lib/libskey/skeyaccess.c.orig Mon Oct 26 20:54:36 1998 +++ lib/libskey/skeyaccess.c Fri Mar 16 03:04:48 2001 @@ -63,8 +63,8 @@ static int match_group __P((struct login_info *)); static int match_token __P((char *)); static int is_internet_addr __P((char *)); -static struct in_addr *convert_internet_addr __P((char *)); -static struct in_addr *lookup_internet_addr __P((char *)); +static struct addrinfo *convert_internet_addr __P((char *)); +static struct addrinfo *lookup_internet_addr __P((char *)); #define MAX_ADDR 32 #define PERMIT 1 @@ -79,7 +79,7 @@ struct login_info { char *host_name; /* host name */ - struct in_addr *internet_addr; /* null terminated list */ + struct addrinfo *internet_addr; /* addrinfo chain */ char *user; /* user name */ char *port; /* login port */ }; @@ -120,22 +120,22 @@ login_info.user = user; login_info.port = port; - if (host != 0 && !is_internet_addr(host)) { + if (host != NULL && !is_internet_addr(host)) { login_info.host_name = host; } else { - login_info.host_name = 0; + login_info.host_name = NULL; } - if (addr != 0 && is_internet_addr(addr)) { + if (addr != NULL && is_internet_addr(addr)) { login_info.internet_addr = convert_internet_addr(addr); - } else if (host != 0) { + } else if (host != NULL) { if (is_internet_addr(host)) { login_info.internet_addr = convert_internet_addr(host); } else { login_info.internet_addr = lookup_internet_addr(host); } } else { - login_info.internet_addr = 0; + login_info.internet_addr = NULL; } /* @@ -146,19 +146,23 @@ printf("user: %s\n", login_info.user); printf("host: %s\n", login_info.host_name ? login_info.host_name : "none"); printf("addr: "); - if (login_info.internet_addr == 0) { + if (login_info.internet_addr == NULL) { printf("none\n"); } else { - int i; + struct addrinfo *res; + char haddr[NI_MAXHOST]; - for (i = 0; login_info.internet_addr[i].s_addr; i++) - printf("%s%s", login_info.internet_addr[i].s_addr == -1 ? - "(see error log)" : inet_ntoa(login_info.internet_addr[i]), - login_info.internet_addr[i + 1].s_addr ? " " : "\n"); + for (res = login_info.internet_addr; res; res = res->ai_next) { + getnameinfo(res->ai_addr, res->ai_addrlen, haddr, sizeof(haddr), + NULL, 0, NI_NUMERICHOST | NI_WITHSCOPEID); + printf("%s%s", haddr, res->ai_next ? " " : "\n"); + } } #endif result = _skeyaccess(fp, &login_info); fclose(fp); + if (login_info.internet_addr) + freeaddrinfo(login_info.internet_addr); return (result); } @@ -226,33 +230,99 @@ return (match ? permission : DENY); } +/* translate IPv4 mapped IPv6 address to IPv4 address */ + +static void +ai_unmapped(struct addrinfo *ai) +{ + struct sockaddr_in6 *sin6; + struct sockaddr_in *sin4; + u_int32_t addr; + int port; + + if (ai->ai_family != AF_INET6) + return; + sin6 = (struct sockaddr_in6 *)ai->ai_addr; + if (!IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr)) + return; + sin4 = (struct sockaddr_in *)ai->ai_addr; + addr = *(u_int32_t *)&sin6->sin6_addr.s6_addr[12]; + port = sin6->sin6_port; + memset(sin4, 0, sizeof(struct sockaddr_in)); + sin4->sin_addr.s_addr = addr; + sin4->sin_port = port; + sin4->sin_family = AF_INET; + sin4->sin_len = sizeof(struct sockaddr_in); + ai->ai_family = AF_INET; + ai->ai_addrlen = sizeof(struct sockaddr_in); +} + /* match_internet_addr - match internet network address */ static int match_internet_addr(login_info) struct login_info *login_info; { - char * tok; - u_int32_t pattern; - u_int32_t mask; - struct in_addr *addrp; + char *tok; + struct addrinfo *res; + struct sockaddr_storage pattern, mask; + struct sockaddr_in *addr4, *pattern4, *mask4; + struct sockaddr_in6 *addr6, *pattern6, *mask6; + int i, match; - if (login_info->internet_addr == 0) + if (login_info->internet_addr == NULL) return (0); if ((tok = need_internet_addr()) == 0) return (0); - pattern = inet_addr(tok); + if ((res = convert_internet_addr(tok)) == NULL) + return (0); + memcpy(&pattern, res->ai_addr, res->ai_addrlen); + freeaddrinfo(res); if ((tok = need_internet_addr()) == 0) return (0); - mask = inet_addr(tok); + if ((res = convert_internet_addr(tok)) == NULL) + return (0); + memcpy(&mask, res->ai_addr, res->ai_addrlen); + freeaddrinfo(res); + if (pattern.ss_family != mask.ss_family) + return (0); + mask4 = (struct sockaddr_in *)&mask; + pattern4 = (struct sockaddr_in *)&pattern; + mask6 = (struct sockaddr_in6 *)&mask; + pattern6 = (struct sockaddr_in6 *)&pattern; /* * See if any of the addresses matches a pattern in the control file. We * have already tried to drop addresses that belong to someone else. */ - for (addrp = login_info->internet_addr; addrp->s_addr; addrp++) - if (addrp->s_addr != INADDR_NONE && (addrp->s_addr & mask) == pattern) - return (1); + for (res = login_info->internet_addr; res; res = res->ai_next) { + ai_unmapped(res); + if (res->ai_family != pattern.ss_family) + continue; + switch (res->ai_family) { + case AF_INET: + addr4 = (struct sockaddr_in *)res->ai_addr; + if (addr4->sin_addr.s_addr != INADDR_NONE && + (addr4->sin_addr.s_addr & mask4->sin_addr.s_addr) == pattern4->sin_addr.s_addr) + return (1); + break; + case AF_INET6: + addr6 = (struct sockaddr_in6 *)res->ai_addr; + if (pattern6->sin6_scope_id != 0 && + addr6->sin6_scope_id != pattern6->sin6_scope_id) + break; + match = 1; + for (i = 0; i < 16; ++i) { + if ((addr6->sin6_addr.s6_addr[i] & mask6->sin6_addr.s6_addr[i]) != pattern6->sin6_addr.s6_addr[i]) { + match = 0; + break; + } + } + if (match) + return (1); + break; + } + } return (0); } @@ -369,53 +439,49 @@ static int is_internet_addr(str) char *str; { - int in_run = 0; - int runs = 0; + struct addrinfo *res; - /* Count the number of runs of characters between the dots. */ - - while (*str) { - if (*str == '.') { - in_run = 0; - } else { - if (!isdigit(*str)) - return (0); - if (in_run == 0) { - in_run = 1; - runs++; - } - } - str++; + if ((res = convert_internet_addr(str)) != NULL) + freeaddrinfo(res); + return (res != NULL); +} + +/* + * Nuke addrinfo entry from list. + * XXX: Depending on the implementation of KAME's getaddrinfo(3). + */ +static void nuke_ai(rp, res) +struct addrinfo **rp, *res; +{ + *rp = res->ai_next; + if (res->ai_canonname) { + if (res->ai_next && !res->ai_next->ai_canonname) + res->ai_next->ai_canonname = res->ai_canonname; + else + free(res->ai_canonname); } - return (runs == 4); + free(res); } /* lookup_internet_addr - look up internet addresses with extreme prejudice */ -static struct in_addr *lookup_internet_addr(host) +static struct addrinfo *lookup_internet_addr(host) char *host; { - struct hostent *hp; - static struct in_addr list[MAX_ADDR + 1]; - char buf[MAXHOSTNAMELEN + 1]; - int length; - int i; - - if ((hp = gethostbyname(host)) == 0 || hp->h_addrtype != AF_INET) - return (0); - - /* - * Save a copy of the results before gethostbyaddr() clobbers them. - */ - - for (i = 0; i < MAX_ADDR && hp->h_addr_list[i]; i++) - memcpy((char *) &list[i], - hp->h_addr_list[i], (size_t)hp->h_length); - list[i].s_addr = 0; - - strncpy(buf, hp->h_name, MAXHOSTNAMELEN); - buf[MAXHOSTNAMELEN] = 0; - length = hp->h_length; + struct addrinfo hints, *res0, *res, **rp; + char hname[NI_MAXHOST], haddr[NI_MAXHOST]; + int error; + + memset(&hints, 0, sizeof(hints)); + hints.ai_family = PF_UNSPEC; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = AI_PASSIVE | AI_CANONNAME; + if (getaddrinfo(host, NULL, &hints, &res0) != 0) + return (NULL); + if (res0->ai_canonname == NULL) { + freeaddrinfo(res0); + return (NULL); + } /* * Wipe addresses that appear to belong to someone else. We will get @@ -425,31 +491,51 @@ #define NEQ(x,y) (strcasecmp((x),(y)) != 0) #define NEQ3(x,y,n) (strncasecmp((x),(y), (n)) != 0) - while (--i >= 0) { - if ((hp = gethostbyaddr((char *) &list[i], length, AF_INET)) == 0) { + rp = &res0; + for (res = res0; res; res = res->ai_next) { + if (res->ai_family != AF_INET && res->ai_family != AF_INET6) { + nuke_ai(rp, res); + continue; + } + error = getnameinfo(res->ai_addr, res->ai_addrlen, + hname, sizeof(hname), + NULL, 0, NI_NAMEREQD | NI_WITHSCOPEID); + if (error) { + getnameinfo(res->ai_addr, res->ai_addrlen, haddr, sizeof(haddr), + NULL, 0, NI_NUMERICHOST | NI_WITHSCOPEID); syslog(LOG_ERR, "address %s not registered for host %s", - inet_ntoa(list[i]), buf); - list[i].s_addr = (u_int32_t) -1; + haddr, res0->ai_canonname); + nuke_ai(rp, res); + continue; } - if (NEQ(buf, hp->h_name) && NEQ3(buf, "localhost.", 10)) { + if (NEQ(res0->ai_canonname, hname) && + NEQ3(res0->ai_canonname, "localhost.", 10)) { + getnameinfo(res->ai_addr, res->ai_addrlen, haddr, sizeof(haddr), + NULL, 0, NI_NUMERICHOST | NI_WITHSCOPEID); syslog(LOG_ERR, "address %s registered for host %s and %s", - inet_ntoa(list[i]), hp->h_name, buf); - list[i].s_addr = (u_int32_t) -1; + haddr, hname, res0->ai_canonname); + nuke_ai(rp, res); + continue; } + rp = &res->ai_next; } - return (list); + return (res0); } /* convert_internet_addr - convert string to internet address */ -static struct in_addr *convert_internet_addr(string) +static struct addrinfo *convert_internet_addr(string) char *string; { - static struct in_addr list[2]; + struct addrinfo hints, *res; - list[0].s_addr = inet_addr(string); - list[1].s_addr = 0; - return (list); + memset(&hints, 0, sizeof(hints)); + hints.ai_family = PF_UNSPEC; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = AI_PASSIVE | AI_NUMERICHOST; + if (getaddrinfo(string, NULL, &hints, &res) != 0) + return (NULL); + return (res); } #ifdef TEST @@ -458,7 +544,7 @@ int argc; char **argv; { - struct hostent *hp; + struct addrinfo hints, *res; char host[MAXHOSTNAMELEN + 1]; int verdict; char *user; @@ -475,8 +561,18 @@ user = argv[1]; port = argv[2]; if (argv[3]) { - strncpy(host, (hp = gethostbyname(argv[3])) ? - hp->h_name : argv[3], MAXHOSTNAMELEN); + memset(&hints, 0, sizeof(hints)); + hints.ai_family = PF_UNSPEC; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = AI_PASSIVE | AI_CANONNAME; + if (getaddrinfo(argv[3], NULL, &hints, &res) == 0) { + if (res->ai_canonname == NULL) + strncpy(host, argv[3], MAXHOSTNAMELEN); + else + strncpy(host, res->ai_canonname, MAXHOSTNAMELEN); + freeaddrinfo(res); + } else + strncpy(host, argv[3], MAXHOSTNAMELEN); host[MAXHOSTNAMELEN] = 0; } verdict = skeyaccess(user, port, argv[3] ? host : (char *) 0, (char *) 0); -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 7:52:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 63BC937B71B for ; Sat, 17 Mar 2001 07:52:38 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=40c280af6b084a3e89191ca9cd257961) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14eJ01-0007E0-00; Sat, 17 Mar 2001 08:52:13 -0700 Message-ID: <3AB3882D.5EAC34@softweyr.com> Date: Sat, 17 Mar 2001 08:52:13 -0700 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: Nick Rogness Cc: Jeroen Ruigrok/Asmodai , freebsd-net@FreeBSD.ORG Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Rogness wrote: > > On Fri, 16 Mar 2001, Jeroen Ruigrok/Asmodai wrote: > > > -On [20010310 04:00], Nick Rogness (nick@rogness.net) wrote: > > > > > >Is anyone working on route caching functionality within FreeBSD? This > > >would eliminate a lot of problems with using FreeBSD as a router...which > > >seems to be a common role of which FreeBSD seems to fit. Especially for > > >machine that are dual-homed. > > > > Correct me if wrong, but if I recall BSD natively already held a route > > cache, although it might not be the best route cache which we could come > > up with. > > Well, I'm sure it does have some route cache functionality but not > what is considered to be useful. > > I'll clarify real quick for people who are asking 'why?'. Bare > with me. As a packet comes in one interface, there should be a > way when the packet comes back out to be sent out that same > interface it was received on, regardless of what the default route > says. You seem to have a deep misunderstanding of how the routing table works. The ingress interface has nothing to do with which interface the packet will egress on. The packet is received, checked against a list of local addresses, and delivered upstream if a match is found. If a match is not found, the forwarding variable is checked. If forwarding is off, the packet is dropped. If forwarding is one, the packet is delivered to ip_output. At this point, the packet is routed in exactly the same manner as a packet coming from the local host - a destination for it is found via the routing table (or short-circuited via the single-entry route cache if it is destined for the same IP address as the last packet that was routed) and sent out the proper interface. The default route is used ONLY if there is no better route that can be found. If the packet is sent back out the same interface it arrived on, the system will generate an ICMP redirect message instructing the source to send packets for this destination directly to OUR idea of the proper router for them, in order to save on redundant traffic. > For dual-homed hosts, this is a problem because your packet gets > sent out the default gateway, which may or may not get filtered > upstream. This is usually solved by running a routing deamon but > most upstreams won't allow you to do that anyway (cable,dsl,etc). If you have a dual-homed host that is simply routing an internal LAN to the external network, you don't need anything other than a default route. If it's not bound for the internal network, it goes to the external network, by definition. I completely fail to see that you have actually stated a problem yet. What exactly is the problem you think you're trying to solve here? -- "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 Sat Mar 17 8:20:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay2.wertep.com (relay2.wertep.com [194.44.90.130]) by hub.freebsd.org (Postfix) with ESMTP id A74F937B719; Sat, 17 Mar 2001 08:20:47 -0800 (PST) (envelope-from petro@She.wertep.com) Received: from She.wertep.com (she-tun-proxy [192.168.252.2]) by relay2.wertep.com (8.9.3/8.9.3) with ESMTP id SAA87674; Sat, 17 Mar 2001 18:20:38 +0200 (EET) (envelope-from petro@She.wertep.com) Received: from localhost (petro@localhost) by She.wertep.com (8.9.3/8.9.3) with ESMTP id SAA24608; Sat, 17 Mar 2001 18:21:00 +0200 (EET) (envelope-from petro@She.wertep.com) Date: Sat, 17 Mar 2001 18:21:00 +0200 (EET) From: petro To: freebsd-hackers@FreeBSD.ORG Cc: freebsd-net@FreeBSD.ORG Subject: Can't install FreeBSD 4.1 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 Hi! I try to install FreeBSD 4.1 when the proces of copying begin, (near 20% of /bin copied) I receive such error panic: general protection fault syncing disks ...... 99.. 99 99 99 automatic reboot in 15 seconds, press any key to abort. Thank you very much for any help. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 8:24: 3 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 0ECC637B71A for ; Sat, 17 Mar 2001 08:24:00 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2HGSPc17025; Sat, 17 Mar 2001 10:28:25 -0600 (CST) (envelope-from nick@rogness.net) Date: Sat, 17 Mar 2001 10:28:25 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: freebsd-net@FreeBSD.ORG Cc: Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache In-Reply-To: <3AB3882D.5EAC34@softweyr.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 Sat, 17 Mar 2001, Wes Peters wrote: [Wes, if you get this, for some reason I can't send to your domain.] You are not understanding what I am trying to say. Once again I'll try to clarify. > > For dual-homed hosts, this is a problem because your packet gets > > sent out the default gateway, which may or may not get filtered > > upstream. This is usually solved by running a routing deamon but > > most upstreams won't allow you to do that anyway (cable,dsl,etc). > > If you have a dual-homed host that is simply routing an internal LAN to > the external network, you don't need anything other than a default route. > If it's not bound for the internal network, it goes to the external > network, by definition. > Actually, that is not what "dual-homed" in the internet world means. Dual homed is having 2 *public* Internet connections. That's ISP lingo. > I completely fail to see that you have actually stated a problem yet. > > What exactly is the problem you think you're trying to solve here? > Consider the following. I have to restate this every damn couple of weeks to get it through. Here is the problem: ISP#1 ISP#2 | | | | --- xl0 FreeBSD xl1 ----- xl2 | | Internal network | | Machine 1 Packet 1 comes in through ISP #2 network. It comes into your internal network to machine 1. Machine 1 replies to the packet...but where does it go? It will exit through interface to ISP #1 because of the default gateway. It came in ISP #2 and left out ISP #1. There is your problem. What if you are running nat in this case....your hosed. You can check out route-cache at Cisco's online site. It may help to clarify as to why you would want to do this. If you check the -net mailing list this problem re-occurs over and over and over and over and over. To which there is a work around that's a bit messy. 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 Sat Mar 17 8:50:59 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 938C737B718 for ; Sat, 17 Mar 2001 08:50:56 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2HGtMQ17098; Sat, 17 Mar 2001 10:55:22 -0600 (CST) (envelope-from nick@rogness.net) Date: Sat, 17 Mar 2001 10:55:22 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: freebsd-net@FreeBSD.ORG Cc: Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache 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 On Sat, 17 Mar 2001, Nick Rogness wrote: More clarification. > > > I completely fail to see that you have actually stated a problem yet. > > > > What exactly is the problem you think you're trying to solve here? > > > > Consider the following. I have to restate this every damn couple > of weeks to get it through. Here is the problem: > > > ISP#1 ISP#2 > | | > | | > --- xl0 FreeBSD xl1 ----- > xl2 > | > | > Internal network > | > | > Machine 1 > > > Packet 1 comes in through ISP #2 network. It comes into your > internal network to machine 1. Machine 1 replies to the > packet...but where does it go? It will exit through interface > to ISP #1 because of the default gateway. It came in ISP #2 and > left out ISP #1. There is your problem. There is no way to tell your packet to go back out to ISP #2. That is the point I'm trying to get across. Unless your running a routing daemon. But is that really practical with cable modems, dsl, etc?...I don't think so. > > What if you are running nat in this case....your hosed. > natd on each interface is what I'm stating here...just to clarify. > You can check out route-cache at Cisco's online site. It may help > to clarify as to why you would want to do this. > > If you check the -net mailing list this problem re-occurs over and > over and over and over and over. To which there is a work around > that's a bit messy. 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 Sat Mar 17 9:27:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id E88D437B719 for ; Sat, 17 Mar 2001 09:27:17 -0800 (PST) (envelope-from alex@acecape.com) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id MAA03919; Sat, 17 Mar 2001 12:31:46 -0500 (EST) X-Authentication-Warning: spider.pilosoft.com: alexmail owned process doing -bs Date: Sat, 17 Mar 2001 12:31:46 -0500 (EST) From: Alex Pilosov X-Sender: alexmail@spider.pilosoft.com To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache 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 On Sat, 17 Mar 2001, Nick Rogness wrote: > There is no way to tell your packet to go back out to ISP #2. That is the > point I'm trying to get across. Unless your running a routing > daemon. But is that really practical with cable modems, dsl, etc?...I > don't think so. Is the clue really gone from this list? Now, correcting glaring mistakes of the above two posters: a) Multihomed means having two connections to public Internet b) route-cache means fast lookup of destination gateway. Lookup of destination gateway may be slow (see d), and it makes sense to keep track of a TCP connection and 'fast-switch' (cisco lingo) the following packets, caching the following data (destination, ACL list) from the first packet. Usually route-cache is implemented in hardware in ASICs, but sometimes it may make sense to implement it in software (when overhead of connection tracking is less than overhead of route/acl lookup). Route-cache has nothing to do with policy routing (d) c) Running routing daemons has, once again, nothing to do with policy routing. It only means you are consensually exchanging routes with your neighbours. IF you are big enough to run BGP4 to your upstreams, you need to run routing daemon (gated/zebra/etc), and you are not likely to have need for policy routing, because your IPs are all equal: all networks you have can(will?) be delivered (and can be sent over) over any interface that you have. d) Policy routing is a generic term for any sort of routing (i.e. choosing of destination gateway for a packet) that is not exclusively based on destination IP address. It may be based on src/dest port, TOS field, source IP address, etc. FreeBSD has no support of that, to my knowledge. Linux has something called 'iproute2' which does support it, by having multiple routing tables, and a ruleset that decides which routing table to use based on packet details. With policy routing, you indeed will be able to multihome, without any cooperation of your upstream (assuming strict filters on their ingress interfaces) and have things work. -- -- Alex Pilosov | http://www.acecape.com/dsl CTO - Acecape, Inc. | AceDSL:The best ADSL in Bell Atlantic area 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) New York, NY 10018 | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 9:50:50 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 4214A37B719 for ; Sat, 17 Mar 2001 09:50:45 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2HHtAS17263; Sat, 17 Mar 2001 11:55:10 -0600 (CST) (envelope-from nick@rogness.net) Date: Sat, 17 Mar 2001 11:55:09 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Alex Pilosov Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache 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 On Sat, 17 Mar 2001, Alex Pilosov wrote: > On Sat, 17 Mar 2001, Nick Rogness wrote: > > > There is no way to tell your packet to go back out to ISP #2. That is the > > point I'm trying to get across. Unless your running a routing > > daemon. But is that really practical with cable modems, dsl, etc?...I > > don't think so. > > Is the clue really gone from this list? > WHat is your problem? Are these comments really necessary? > > Now, correcting glaring mistakes of the above two posters: > > a) Multihomed means having two connections to public Internet > I mentioned that in my post if you would have read it. Multihomed can be multiple connections connections to the internet, not just 2. Dual-Homed is the proper terminology for 2 public connections. > b) route-cache means fast lookup of destination gateway. Lookup of > destination gateway may be slow (see d), and it makes sense to keep track > of a TCP connection and 'fast-switch' (cisco lingo) the following packets, > caching the following data (destination, ACL list) from the first packet. > Usually route-cache is implemented in hardware in ASICs, but sometimes it > may make sense to implement it in software (when overhead of connection > tracking is less than overhead of route/acl lookup). > > Route-cache has nothing to do with policy routing (d) > Who said anything about policy routing....where are you going with this. Cisco's ip route-cache same-interface has nothing to do with policy routing...and policy routing is not mentioned here. > c) Running routing daemons has, once again, nothing to do with policy > routing. It only means you are consensually exchanging routes with your > neighbours. IF you are big enough to run BGP4 to your upstreams, you need > to run routing daemon (gated/zebra/etc), and you are not likely to have > need for policy routing, because your IPs are all equal: all networks you > have can(will?) be delivered (and can be sent over) over any interface > that you have. > I didn't say anything about policy routing.... In the example I gave, routing daemons could be used to get a routing table from each upstream via BGP or whatever. Hence some routes would go out ISP#1 and some would go out ISP#2. > d) Policy routing is a generic term for any sort of routing (i.e. choosing > of destination gateway for a packet) that is not exclusively based on > destination IP address. It may be based on src/dest port, TOS field, > source IP address, etc. FreeBSD has no support of that, to my knowledge. > Linux has something called 'iproute2' which does support it, by having > multiple routing tables, and a ruleset that decides which routing table to > use based on packet details. FreeBSD does implement *some* form of polciy routing. man ipfw > > With policy routing, you indeed will be able to multihome, without any > cooperation of your upstream (assuming strict filters on their ingress > interfaces) and have things work. Not dynamically you can't. Because you would have to know every source IP and which interface it came in on, to send it back out the same interface to get the packet back. 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 Sat Mar 17 9:53:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id 6136B37B71A; Sat, 17 Mar 2001 09:53:19 -0800 (PST) (envelope-from ume@FreeBSD.org) Received: from localhost (IDENT:p8jkn3SzUJMbNWSKDclLcxnFnqs/dngHjSJCJ8hHEcbtOVG4LNOk5AaJzarYmRE6@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.3/8.11.3/peace) with ESMTP/inet6 id f2HHnvR45766; Sun, 18 Mar 2001 02:49:58 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Sun, 18 Mar 2001 02:49:57 +0900 (JST) Message-Id: <20010318.024957.70172896.ume@FreeBSD.org> To: audit@FreeBSD.org, net@FreeBSD.org Subject: Re: [CFR] IPv6 support for skeyaccess(3) From: Hajimu UMEMOTO In-Reply-To: <20010317.233758.21880242.ume@FreeBSD.org> References: <20010317.233758.21880242.ume@FreeBSD.org> X-Mailer: xcite1.38> Mew version 1.95b97 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT 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 >>>>> On Sat, 17 Mar 2001 23:37:58 +0900 (JST) >>>>> Hajimu UMEMOTO said: ume> I wish to support IPv6 for skeyaccess(3). With this patch, you can ume> specify IPv6 address using `internet' keyword into /etc/skey.access. ume> Please review it. Oops, previous patch touched the memory already freed. This is corrected version. Sorry for my inconvenience. Index: lib/libskey/skeyaccess.c diff -u lib/libskey/skeyaccess.c.orig lib/libskey/skeyaccess.c --- lib/libskey/skeyaccess.c.orig Mon Oct 26 20:54:36 1998 +++ lib/libskey/skeyaccess.c Sun Mar 18 01:29:48 2001 @@ -63,8 +63,8 @@ static int match_group __P((struct login_info *)); static int match_token __P((char *)); static int is_internet_addr __P((char *)); -static struct in_addr *convert_internet_addr __P((char *)); -static struct in_addr *lookup_internet_addr __P((char *)); +static struct addrinfo *convert_internet_addr __P((char *)); +static struct addrinfo *lookup_internet_addr __P((char *)); #define MAX_ADDR 32 #define PERMIT 1 @@ -79,7 +79,7 @@ struct login_info { char *host_name; /* host name */ - struct in_addr *internet_addr; /* null terminated list */ + struct addrinfo *internet_addr; /* addrinfo chain */ char *user; /* user name */ char *port; /* login port */ }; @@ -120,22 +120,22 @@ login_info.user = user; login_info.port = port; - if (host != 0 && !is_internet_addr(host)) { + if (host != NULL && !is_internet_addr(host)) { login_info.host_name = host; } else { - login_info.host_name = 0; + login_info.host_name = NULL; } - if (addr != 0 && is_internet_addr(addr)) { + if (addr != NULL && is_internet_addr(addr)) { login_info.internet_addr = convert_internet_addr(addr); - } else if (host != 0) { + } else if (host != NULL) { if (is_internet_addr(host)) { login_info.internet_addr = convert_internet_addr(host); } else { login_info.internet_addr = lookup_internet_addr(host); } } else { - login_info.internet_addr = 0; + login_info.internet_addr = NULL; } /* @@ -146,19 +146,23 @@ printf("user: %s\n", login_info.user); printf("host: %s\n", login_info.host_name ? login_info.host_name : "none"); printf("addr: "); - if (login_info.internet_addr == 0) { + if (login_info.internet_addr == NULL) { printf("none\n"); } else { - int i; + struct addrinfo *res; + char haddr[NI_MAXHOST]; - for (i = 0; login_info.internet_addr[i].s_addr; i++) - printf("%s%s", login_info.internet_addr[i].s_addr == -1 ? - "(see error log)" : inet_ntoa(login_info.internet_addr[i]), - login_info.internet_addr[i + 1].s_addr ? " " : "\n"); + for (res = login_info.internet_addr; res; res = res->ai_next) { + getnameinfo(res->ai_addr, res->ai_addrlen, haddr, sizeof(haddr), + NULL, 0, NI_NUMERICHOST | NI_WITHSCOPEID); + printf("%s%s", haddr, res->ai_next ? " " : "\n"); + } } #endif result = _skeyaccess(fp, &login_info); fclose(fp); + if (login_info.internet_addr) + freeaddrinfo(login_info.internet_addr); return (result); } @@ -226,33 +230,99 @@ return (match ? permission : DENY); } +/* translate IPv4 mapped IPv6 address to IPv4 address */ + +static void +ai_unmapped(struct addrinfo *ai) +{ + struct sockaddr_in6 *sin6; + struct sockaddr_in *sin4; + u_int32_t addr; + int port; + + if (ai->ai_family != AF_INET6) + return; + sin6 = (struct sockaddr_in6 *)ai->ai_addr; + if (!IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr)) + return; + sin4 = (struct sockaddr_in *)ai->ai_addr; + addr = *(u_int32_t *)&sin6->sin6_addr.s6_addr[12]; + port = sin6->sin6_port; + memset(sin4, 0, sizeof(struct sockaddr_in)); + sin4->sin_addr.s_addr = addr; + sin4->sin_port = port; + sin4->sin_family = AF_INET; + sin4->sin_len = sizeof(struct sockaddr_in); + ai->ai_family = AF_INET; + ai->ai_addrlen = sizeof(struct sockaddr_in); +} + /* match_internet_addr - match internet network address */ static int match_internet_addr(login_info) struct login_info *login_info; { - char * tok; - u_int32_t pattern; - u_int32_t mask; - struct in_addr *addrp; + char *tok; + struct addrinfo *res; + struct sockaddr_storage pattern, mask; + struct sockaddr_in *addr4, *pattern4, *mask4; + struct sockaddr_in6 *addr6, *pattern6, *mask6; + int i, match; - if (login_info->internet_addr == 0) + if (login_info->internet_addr == NULL) return (0); if ((tok = need_internet_addr()) == 0) return (0); - pattern = inet_addr(tok); + if ((res = convert_internet_addr(tok)) == NULL) + return (0); + memcpy(&pattern, res->ai_addr, res->ai_addrlen); + freeaddrinfo(res); if ((tok = need_internet_addr()) == 0) return (0); - mask = inet_addr(tok); + if ((res = convert_internet_addr(tok)) == NULL) + return (0); + memcpy(&mask, res->ai_addr, res->ai_addrlen); + freeaddrinfo(res); + if (pattern.ss_family != mask.ss_family) + return (0); + mask4 = (struct sockaddr_in *)&mask; + pattern4 = (struct sockaddr_in *)&pattern; + mask6 = (struct sockaddr_in6 *)&mask; + pattern6 = (struct sockaddr_in6 *)&pattern; /* * See if any of the addresses matches a pattern in the control file. We * have already tried to drop addresses that belong to someone else. */ - for (addrp = login_info->internet_addr; addrp->s_addr; addrp++) - if (addrp->s_addr != INADDR_NONE && (addrp->s_addr & mask) == pattern) - return (1); + for (res = login_info->internet_addr; res; res = res->ai_next) { + ai_unmapped(res); + if (res->ai_family != pattern.ss_family) + continue; + switch (res->ai_family) { + case AF_INET: + addr4 = (struct sockaddr_in *)res->ai_addr; + if (addr4->sin_addr.s_addr != INADDR_NONE && + (addr4->sin_addr.s_addr & mask4->sin_addr.s_addr) == pattern4->sin_addr.s_addr) + return (1); + break; + case AF_INET6: + addr6 = (struct sockaddr_in6 *)res->ai_addr; + if (pattern6->sin6_scope_id != 0 && + addr6->sin6_scope_id != pattern6->sin6_scope_id) + break; + match = 1; + for (i = 0; i < 16; ++i) { + if ((addr6->sin6_addr.s6_addr[i] & mask6->sin6_addr.s6_addr[i]) != pattern6->sin6_addr.s6_addr[i]) { + match = 0; + break; + } + } + if (match) + return (1); + break; + } + } return (0); } @@ -369,53 +439,50 @@ static int is_internet_addr(str) char *str; { - int in_run = 0; - int runs = 0; + struct addrinfo *res; - /* Count the number of runs of characters between the dots. */ - - while (*str) { - if (*str == '.') { - in_run = 0; - } else { - if (!isdigit(*str)) - return (0); - if (in_run == 0) { - in_run = 1; - runs++; - } - } - str++; + if ((res = convert_internet_addr(str)) != NULL) + freeaddrinfo(res); + return (res != NULL); +} + +/* + * Nuke addrinfo entry from list. + * XXX: Depending on the implementation of KAME's getaddrinfo(3). + */ +static struct addrinfo *nuke_ai(rp, res) +struct addrinfo **rp, *res; +{ + *rp = res->ai_next; + if (res->ai_canonname) { + if (res->ai_next && !res->ai_next->ai_canonname) + res->ai_next->ai_canonname = res->ai_canonname; + else + free(res->ai_canonname); } - return (runs == 4); + free(res); + return (*rp); } /* lookup_internet_addr - look up internet addresses with extreme prejudice */ -static struct in_addr *lookup_internet_addr(host) +static struct addrinfo *lookup_internet_addr(host) char *host; { - struct hostent *hp; - static struct in_addr list[MAX_ADDR + 1]; - char buf[MAXHOSTNAMELEN + 1]; - int length; - int i; - - if ((hp = gethostbyname(host)) == 0 || hp->h_addrtype != AF_INET) - return (0); - - /* - * Save a copy of the results before gethostbyaddr() clobbers them. - */ - - for (i = 0; i < MAX_ADDR && hp->h_addr_list[i]; i++) - memcpy((char *) &list[i], - hp->h_addr_list[i], (size_t)hp->h_length); - list[i].s_addr = 0; - - strncpy(buf, hp->h_name, MAXHOSTNAMELEN); - buf[MAXHOSTNAMELEN] = 0; - length = hp->h_length; + struct addrinfo hints, *res0, *res, **rp; + char hname[NI_MAXHOST], haddr[NI_MAXHOST]; + int error; + + memset(&hints, 0, sizeof(hints)); + hints.ai_family = PF_UNSPEC; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = AI_PASSIVE | AI_CANONNAME; + if (getaddrinfo(host, NULL, &hints, &res0) != 0) + return (NULL); + if (res0->ai_canonname == NULL) { + freeaddrinfo(res0); + return (NULL); + } /* * Wipe addresses that appear to belong to someone else. We will get @@ -425,31 +492,53 @@ #define NEQ(x,y) (strcasecmp((x),(y)) != 0) #define NEQ3(x,y,n) (strncasecmp((x),(y), (n)) != 0) - while (--i >= 0) { - if ((hp = gethostbyaddr((char *) &list[i], length, AF_INET)) == 0) { + res = res0; + rp = &res0; + while (res) { + if (res->ai_family != AF_INET && res->ai_family != AF_INET6) { + res = nuke_ai(rp, res); + continue; + } + error = getnameinfo(res->ai_addr, res->ai_addrlen, + hname, sizeof(hname), + NULL, 0, NI_NAMEREQD | NI_WITHSCOPEID); + if (error) { + getnameinfo(res->ai_addr, res->ai_addrlen, haddr, sizeof(haddr), + NULL, 0, NI_NUMERICHOST | NI_WITHSCOPEID); syslog(LOG_ERR, "address %s not registered for host %s", - inet_ntoa(list[i]), buf); - list[i].s_addr = (u_int32_t) -1; + haddr, res0->ai_canonname); + res = nuke_ai(rp, res); + continue; } - if (NEQ(buf, hp->h_name) && NEQ3(buf, "localhost.", 10)) { + if (NEQ(res0->ai_canonname, hname) && + NEQ3(res0->ai_canonname, "localhost.", 10)) { + getnameinfo(res->ai_addr, res->ai_addrlen, haddr, sizeof(haddr), + NULL, 0, NI_NUMERICHOST | NI_WITHSCOPEID); syslog(LOG_ERR, "address %s registered for host %s and %s", - inet_ntoa(list[i]), hp->h_name, buf); - list[i].s_addr = (u_int32_t) -1; + haddr, hname, res0->ai_canonname); + res = nuke_ai(rp, res); + continue; } + res = res->ai_next; + rp = &res->ai_next; } - return (list); + return (res0); } /* convert_internet_addr - convert string to internet address */ -static struct in_addr *convert_internet_addr(string) +static struct addrinfo *convert_internet_addr(string) char *string; { - static struct in_addr list[2]; + struct addrinfo hints, *res; - list[0].s_addr = inet_addr(string); - list[1].s_addr = 0; - return (list); + memset(&hints, 0, sizeof(hints)); + hints.ai_family = PF_UNSPEC; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = AI_PASSIVE | AI_NUMERICHOST; + if (getaddrinfo(string, NULL, &hints, &res) != 0) + return (NULL); + return (res); } #ifdef TEST @@ -458,7 +547,7 @@ int argc; char **argv; { - struct hostent *hp; + struct addrinfo hints, *res; char host[MAXHOSTNAMELEN + 1]; int verdict; char *user; @@ -475,8 +564,18 @@ user = argv[1]; port = argv[2]; if (argv[3]) { - strncpy(host, (hp = gethostbyname(argv[3])) ? - hp->h_name : argv[3], MAXHOSTNAMELEN); + memset(&hints, 0, sizeof(hints)); + hints.ai_family = PF_UNSPEC; + hints.ai_socktype = SOCK_STREAM; + hints.ai_flags = AI_PASSIVE | AI_CANONNAME; + if (getaddrinfo(argv[3], NULL, &hints, &res) == 0) { + if (res->ai_canonname == NULL) + strncpy(host, argv[3], MAXHOSTNAMELEN); + else + strncpy(host, res->ai_canonname, MAXHOSTNAMELEN); + freeaddrinfo(res); + } else + strncpy(host, argv[3], MAXHOSTNAMELEN); host[MAXHOSTNAMELEN] = 0; } verdict = skeyaccess(user, port, argv[3] ? host : (char *) 0, (char *) 0); -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 10:36:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id DA83137B718 for ; Sat, 17 Mar 2001 10:36:16 -0800 (PST) (envelope-from alex@acecape.com) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id NAA31298; Sat, 17 Mar 2001 13:41:18 -0500 (EST) X-Authentication-Warning: spider.pilosoft.com: alexmail owned process doing -bs Date: Sat, 17 Mar 2001 13:41:18 -0500 (EST) From: Alex Pilosov X-Sender: alexmail@spider.pilosoft.com To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache 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 On Sat, 17 Mar 2001, Nick Rogness wrote: > > b) route-cache means fast lookup of destination gateway. Lookup of > > destination gateway may be slow (see d), and it makes sense to keep track > > of a TCP connection and 'fast-switch' (cisco lingo) the following packets, > > caching the following data (destination, ACL list) from the first packet. > > Usually route-cache is implemented in hardware in ASICs, but sometimes it > > may make sense to implement it in software (when overhead of connection > > tracking is less than overhead of route/acl lookup). > > > > Route-cache has nothing to do with policy routing (d) > > Who said anything about policy routing....where are you going with > this. Cisco's ip route-cache same-interface has nothing to do > with policy routing...and policy routing is not mentioned here. Policy routing is what you need to route packets based on their source address to properly do multihoming. You keep on using word 'route caching' while this whole thing has _nothing_ to do with route caching. ip route-cache same-interface makes _no actual changes to routing_. The only thing it does is allows "same-interface" flows (that arrive on one interface and leave on same interface) to be cached. Without ip route-cache same-interface, they'll still behave identically, only slower. It is not recommended in certain cases because fast-switching code is known to behave sometimes incorrectly. > > c) Running routing daemons has, once again, nothing to do with policy > > routing. It only means you are consensually exchanging routes with your > > neighbours. IF you are big enough to run BGP4 to your upstreams, you need > > to run routing daemon (gated/zebra/etc), and you are not likely to have > > need for policy routing, because your IPs are all equal: all networks you > > have can(will?) be delivered (and can be sent over) over any interface > > that you have. > > > > I didn't say anything about policy routing.... In the example I > gave, routing daemons could be used to get a routing table from > each upstream via BGP or whatever. Hence some routes would go out > ISP#1 and some would go out ISP#2. > > > > d) Policy routing is a generic term for any sort of routing (i.e. choosing > > of destination gateway for a packet) that is not exclusively based on > > destination IP address. It may be based on src/dest port, TOS field, > > source IP address, etc. FreeBSD has no support of that, to my knowledge. > > Linux has something called 'iproute2' which does support it, by having > > multiple routing tables, and a ruleset that decides which routing table to > > use based on packet details. > > > FreeBSD does implement *some* form of polciy routing. man ipfw Sorry. I was mistaken: indeed, you should be able to use 'ipfw fwd' to accomplish what you need. > > With policy routing, you indeed will be able to multihome, without any > > cooperation of your upstream (assuming strict filters on their ingress > > interfaces) and have things work. > > > Not dynamically you can't. Because you would have to know every > source IP and which interface it came in on, to send it back out > the same interface to get the packet back. You don't need to know the interface. You must route based on the source IP. I.E: ISP A ISP B \ / ra rb \ / your router | | | (local) (ra and rb are respectively edge routers on ISP A and B's end connected to you). Note: On local network, you'll be essentially having two logical networks (different IPs, subnet, etc) on the same wire. Its not clean, but its perfectly supported. Now, assume you have IPs 11.1.1.* from ISP B, and 11.1.2.* from ISP B. You configure both IPs to machines on your 'local' network, and have something like this on the router: ipfw from 11.1.1.0 fwd ra ipfw from 11.1.2.0 fwd rb If this is not what you wanted to accomplish, please correct me. -- -- Alex Pilosov | http://www.acecape.com/dsl CTO - Acecape, Inc. | AceDSL:The best ADSL in Bell Atlantic area 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) New York, NY 10018 | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 10:44:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id CAB0C37B71A for ; Sat, 17 Mar 2001 10:44:39 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 26192 invoked by uid 666); 17 Mar 2001 18:45:57 -0000 Received: from i003-071.nv.iinet.net.au (HELO elischer.org) (203.59.3.71) by mail.m.iinet.net.au with SMTP; 17 Mar 2001 18:45:57 -0000 Message-ID: <3AB3B069.9EB5D3C7@elischer.org> Date: Sat, 17 Mar 2001 10:43:53 -0800 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: Nick Rogness Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Rogness wrote: > > On Sat, 17 Mar 2001, Nick Rogness wrote: > > There is no way to tell your packet to go back out to ISP #2. That is the > point I'm trying to get across. Unless your running a routing > daemon. But is that really practical with cable modems, dsl, etc?...I > don't think so. > > > > > What if you are running nat in this case....your hosed. > > > > natd on each interface is what I'm stating here...just to clarify. I sent out a mesage the other day with a suggestion as to how to this. (in fact using stateful ipfw rules we could even do better) did you see it? > -- __--_|\ 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 Sat Mar 17 10:49: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id EE90837B718 for ; Sat, 17 Mar 2001 10:49:03 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 26327 invoked by uid 666); 17 Mar 2001 18:50:21 -0000 Received: from i003-071.nv.iinet.net.au (HELO elischer.org) (203.59.3.71) by mail.m.iinet.net.au with SMTP; 17 Mar 2001 18:50:21 -0000 Message-ID: <3AB3B171.C89A0177@elischer.org> Date: Sat, 17 Mar 2001 10:48:17 -0800 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: Alex Pilosov Cc: Nick Rogness , freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex Pilosov wrote: > > On Sat, 17 Mar 2001, Nick Rogness wrote: > > > There is no way to tell your packet to go back out to ISP #2. That is the > > point I'm trying to get across. Unless your running a routing > > daemon. But is that really practical with cable modems, dsl, etc?...I > > don't think so. > > Is the clue really gone from this list? > > > > > With policy routing, you indeed will be able to multihome, without any > cooperation of your upstream (assuming strict filters on their ingress > interfaces) and have things work. it should be possible to use IPFW and natd to do this: IPFW could use Luigi's probability feature to select an interface to use for each initiating session and ipfw could use a stateful rule to 'remember the choice made' The final step is to select to which divert rule the packets eventually get sent. Each divert rule goes to a different natd, each of which is attached to a different outgoing interface. > > -- > -- > Alex Pilosov | http://www.acecape.com/dsl > CTO - Acecape, Inc. | AceDSL:The best ADSL in Bell Atlantic area > 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) > New York, NY 10018 | > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ 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 Sat Mar 17 10:55:46 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id A16D437B718 for ; Sat, 17 Mar 2001 10:55:41 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 26536 invoked by uid 666); 17 Mar 2001 18:56:59 -0000 Received: from i003-071.nv.iinet.net.au (HELO elischer.org) (203.59.3.71) by mail.m.iinet.net.au with SMTP; 17 Mar 2001 18:56:59 -0000 Message-ID: <3AB3B2FF.3A04B53C@elischer.org> Date: Sat, 17 Mar 2001 10:54:55 -0800 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: Alex Pilosov Cc: Nick Rogness , freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex Pilosov wrote: > You don't need to know the interface. You must route based on the source > IP. I.E: > > ISP A ISP B > \ / > ra rb > \ / > your router > | > | > | > (local) > > (ra and rb are respectively edge routers on ISP A and B's end connected to > you). > > Note: On local network, you'll be essentially having two logical > networks (different IPs, subnet, etc) on the same wire. Its not clean, but > its perfectly supported. > > Now, assume you have IPs 11.1.1.* from ISP B, and 11.1.2.* from ISP B. You > configure both IPs to machines on your 'local' network, and have something > like this on the router: > ipfw from 11.1.1.0 fwd ra > ipfw from 11.1.2.0 fwd rb this will do what you want for OUTGOING packets. incoming packets will probably all come in on one network. BTW you could do a more general rule by: ipfw add 3 from any to 0.0.1.0:0.0.1.0 fwd ra out xmt ed0 ipfw add 4 from any to any fwb rb out xmt ed0 (if ed0 was the default) > > If this is not what you wanted to accomplish, please correct me. > > -- > -- > Alex Pilosov | http://www.acecape.com/dsl > CTO - Acecape, Inc. | AceDSL:The best ADSL in Bell Atlantic area > 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) > New York, NY 10018 | > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ 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 Sat Mar 17 11:10:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id DC52937B718 for ; Sat, 17 Mar 2001 11:10:54 -0800 (PST) (envelope-from alex@acecape.com) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id OAA08955; Sat, 17 Mar 2001 14:15:39 -0500 (EST) X-Authentication-Warning: spider.pilosoft.com: alexmail owned process doing -bs Date: Sat, 17 Mar 2001 14:15:39 -0500 (EST) From: Alex Pilosov X-Sender: alexmail@spider.pilosoft.com To: Julian Elischer Cc: Nick Rogness , freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache In-Reply-To: <3AB3B2FF.3A04B53C@elischer.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, 17 Mar 2001, Julian Elischer wrote: > this will do what you want for OUTGOING packets. > incoming packets will probably all come in on one network. And to fix this, you play tricks with your DNS server :) A setup that I have at home: Domain with two listed nameservers (same machine, different IPs). BIND set up split-brained: two named.confs, one configured to listen only on IP on network A, the other on network B. Two zone files, one listing IPs on A, other on B. Result: BIND will reply with IPs that belong to the interface packet came in on. This provides load-sharing (nameservers for domain are usually queried randomly) and reliability (if one connection is down, everything still works, because the other "half" of nameserver is still running and giving out IPs on the correct interface). -- -- Alex Pilosov | http://www.acecape.com/dsl CTO - Acecape, Inc. | AceDSL:The best ADSL in Bell Atlantic area 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) New York, NY 10018 | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 11:21: 2 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 16B4937B718 for ; Sat, 17 Mar 2001 11:20:59 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2HJPPU17581; Sat, 17 Mar 2001 13:25:25 -0600 (CST) (envelope-from nick@rogness.net) Date: Sat, 17 Mar 2001 13:25:25 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Alex Pilosov Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache 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 On Sat, 17 Mar 2001, Alex Pilosov wrote: > On Sat, 17 Mar 2001, Nick Rogness wrote: > > > > b) route-cache means fast lookup of destination gateway. Lookup of > > > destination gateway may be slow (see d), and it makes sense to keep track > > > of a TCP connection and 'fast-switch' (cisco lingo) the following packets, > > > caching the following data (destination, ACL list) from the first packet. > > > Usually route-cache is implemented in hardware in ASICs, but sometimes it > > > may make sense to implement it in software (when overhead of connection > > > tracking is less than overhead of route/acl lookup). > > > > > > Route-cache has nothing to do with policy routing (d) > > > > Who said anything about policy routing....where are you going with > > this. Cisco's ip route-cache same-interface has nothing to do > > with policy routing...and policy routing is not mentioned here. > > Policy routing is what you need to route packets based on their source > address to properly do multihoming. You keep on using word 'route caching' > while this whole thing has _nothing_ to do with route caching. Yes, maybe it is a poor use of words. I am not meaning Cisco's `ip route-cache` for use with Fast switching. This is all I'm saying: 1) Packet comes in interface A with source A.A.A.A dest B.B.B.B 2) A route to that source IP (A.A.A.A) get's cache'd temporarily to go out Interface A. 3) So when the packet returns with destination of A.A.A.A go out interface A. This is easy to do without nat, but unfortunetly that is not the case here. > > ip route-cache same-interface makes _no actual changes to routing_. The > only thing it does is allows "same-interface" flows (that arrive on one > interface and leave on same interface) to be cached. Without ip > route-cache same-interface, they'll still behave identically, only slower. > It is not recommended in certain cases because fast-switching code is > known to behave sometimes incorrectly. > Yes, I understand Cisco's implementation. [snip] > > > > With policy routing, you indeed will be able to multihome, without any > > > cooperation of your upstream (assuming strict filters on their ingress > > > interfaces) and have things work. > > > > > > Not dynamically you can't. Because you would have to know every > > source IP and which interface it came in on, to send it back out > > the same interface to get the packet back. > You don't need to know the interface. You must route based on the source > IP. I.E: > > ISP A ISP B > \ / > ra rb > \ / > your router > | > | > | > (local) > > (ra and rb are respectively edge routers on ISP A and B's end connected to > you). > > Note: On local network, you'll be essentially having two logical > networks (different IPs, subnet, etc) on the same wire. Its not clean, but > its perfectly supported. > > Now, assume you have IPs 11.1.1.* from ISP B, and 11.1.2.* from ISP B. You > configure both IPs to machines on your 'local' network, and have something > like this on the router: > ipfw from 11.1.1.0 fwd ra > ipfw from 11.1.2.0 fwd rb > > > > If this is not what you wanted to accomplish, please correct me. > this does not work with natd. 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 Sat Mar 17 11:37:58 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 44E9637B719 for ; Sat, 17 Mar 2001 11:37:54 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA75388; Sat, 17 Mar 2001 14:37:33 -0500 (EST) (envelope-from wollman) Date: Sat, 17 Mar 2001 14:37:33 -0500 (EST) From: Garrett Wollman Message-Id: <200103171937.OAA75388@khavrinen.lcs.mit.edu> To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG Subject: Re: same interface Route Cache In-Reply-To: References: <3AB3882D.5EAC34@softweyr.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Packet 1 comes in through ISP #2 network. It comes into your > internal network to machine 1. Machine 1 replies to the > packet...but where does it go? It will exit through interface > to ISP #1 because of the default gateway. It came in ISP #2 and > left out ISP #1. There is your problem. That's the way Internet routing is supposed to work. If your routing table says a packet supposed to go one way, and it really needs to go another way, that's *user error* -- if you misconfigure your routing, FreeBSD will do what you ask it to; it can't read your mind! -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 11:54: 5 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 C843737B719 for ; Sat, 17 Mar 2001 11:54:01 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2HJsOl17677; Sat, 17 Mar 2001 13:54:28 -0600 (CST) (envelope-from nick@rogness.net) Date: Sat, 17 Mar 2001 13:54:24 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: same interface Route Cache In-Reply-To: <200103171937.OAA75388@khavrinen.lcs.mit.edu> 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, 17 Mar 2001, Garrett Wollman wrote: > < said: > > > Packet 1 comes in through ISP #2 network. It comes into your > > internal network to machine 1. Machine 1 replies to the > > packet...but where does it go? It will exit through interface > > to ISP #1 because of the default gateway. It came in ISP #2 and > > left out ISP #1. There is your problem. > > That's the way Internet routing is supposed to work. If your routing > table says a packet supposed to go one way, and it really needs to go > another way, that's *user error* -- if you misconfigure your routing, > FreeBSD will do what you ask it to; it can't read your mind! Yes, that is correct. That is how routing is suppose to happen. However, there should be a workaround available to do this...without setting up a routing peer with your upstreams. Unless you are an ISP, you can't just ask your DSL provider to give you this option. Most upstreams will filter your traffic so you can't have different source network addresses coming from your machine to their networks, only the IP's that they assign to you. SPoofing anyone? I am trying to proactively find a solution to this. Whether it is doable or not is another thing. Actually, I know it is doable because I'm doing it as we speak using 3 natd's, but it is ugly. After all, this seems to be a common setup with FreeBSD. If you want to BGP peer with someone, buy a Cisco. 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 Sat Mar 17 11:54:59 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 8609E37B718 for ; Sat, 17 Mar 2001 11:54:54 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2HJxJj17689; Sat, 17 Mar 2001 13:59:19 -0600 (CST) (envelope-from nick@rogness.net) Date: Sat, 17 Mar 2001 13:59:19 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Julian Elischer Cc: Alex Pilosov , freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache In-Reply-To: <3AB3B171.C89A0177@elischer.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, 17 Mar 2001, Julian Elischer wrote: > Alex Pilosov wrote: > > > > On Sat, 17 Mar 2001, Nick Rogness wrote: > > > > > There is no way to tell your packet to go back out to ISP #2. That is the > > > point I'm trying to get across. Unless your running a routing > > > daemon. But is that really practical with cable modems, dsl, etc?...I > > > don't think so. > > > > Is the clue really gone from this list? > > > > > > > > > > With policy routing, you indeed will be able to multihome, without any > > cooperation of your upstream (assuming strict filters on their ingress > > interfaces) and have things work. > > it should be possible to use IPFW and natd to do this: > IPFW could use Luigi's probability feature to select an interface to > use for each initiating session and ipfw could use a stateful rule > to 'remember the choice made' I would be interested to see what you are talking about with probability. I'll play with it this afternoon. Just to be clear to everyone, the problem I'm seeing is this: 1) Packet comes in with src A.A.A.A dest B.B.B.B in interface A (in from ISP #2) 2) natd-2 (listening on interface A from ISP #2) changes the destination from B.B.B.B to machine X.X.X.X (internal) 3) Packet gets sent to machine X.X.X.X on the internal network. 4) Machine X.X.X.X responds to B.B.B.B, sending the packet back to the BSD machine. 5) The BSD machine looks up in the routing table how to get to B.B.B.B. Oh no! Go out interface B connected to ISP#1...the default gateway. 6) This triggers natd-1 to change the source to C.C.C.C and sends the packet out to B.B.B.B on the default interface B because of the default gateway. 7) Machine B.B.B.B is expecting a response from A.A.A.A, but instead, it is seeing a response from C.C.C.C And Alex, you can't fwd based on source because of the 2 natd's on 2 different interfaces. The firewall does not keep track of INCOMING packets. So the firewall does not know the right interface to forward the packet to, so the wrong natd get's triggered. > > The final step is to select to which divert rule the packets eventually get > sent. > Each divert rule goes to a different natd, each of which is attached to a > different outgoing interface. I am going to look at what you suggested this afternoon to see if it works. 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 Sat Mar 17 12: 7:32 2001 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id E1E5237B718 for ; Sat, 17 Mar 2001 12:07:28 -0800 (PST) (envelope-from alex@pilosoft.com) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id PAA26624; Sat, 17 Mar 2001 15:12:17 -0500 (EST) Date: Sat, 17 Mar 2001 15:12:17 -0500 (EST) From: Alex Pilosov To: Garrett Wollman Cc: Nick Rogness , freebsd-net@FreeBSD.ORG Subject: Re: same interface Route Cache In-Reply-To: <200103171937.OAA75388@khavrinen.lcs.mit.edu> 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, 17 Mar 2001, Garrett Wollman wrote: > That's the way Internet routing is supposed to work. If your routing > table says a packet supposed to go one way, and it really needs to go > another way, that's *user error* -- if you misconfigure your routing, > FreeBSD will do what you ask it to; it can't read your mind! There are legitimate reasons why you may want more flexibility than simple destination-based routing. I.E. Having two connections, one satellite (fast cheap but high-latency) and one long-distance modem connection (slow, expensive but low-latency) and dynamically routing telnet packets over the modem connection. Or, traffic engineering: routing packets from a certain blocks over a certain interface, etc. -alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 17 20:48:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 1859C37B719 for ; Sat, 17 Mar 2001 20:48:06 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=d310c0531864e6027cf81c572427e76b) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14eV77-0007Ww-00; Sat, 17 Mar 2001 21:48:21 -0700 Message-ID: <3AB43E15.8D288A7F@softweyr.com> Date: Sat, 17 Mar 2001 21:48:21 -0700 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: Nick Rogness Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Rogness wrote: > > On Sat, 17 Mar 2001, Wes Peters wrote: > > [Wes, if you get this, for some reason I can't send to your > domain.] > > You are not understanding what I am trying to say. Once again I'll try to > clarify. > > > > For dual-homed hosts, this is a problem because your packet gets > > > sent out the default gateway, which may or may not get filtered > > > upstream. This is usually solved by running a routing deamon but > > > most upstreams won't allow you to do that anyway (cable,dsl,etc). > > > > If you have a dual-homed host that is simply routing an internal LAN to > > the external network, you don't need anything other than a default route. > > If it's not bound for the internal network, it goes to the external > > network, by definition. > > > > Actually, that is not what "dual-homed" in the internet > world means. Dual homed is having 2 *public* Internet > connections. That's ISP lingo. No, that's just wrong. "dual-homed" means it has two network interfaces; all routers are dual-homed at least. ISPs are not allowed to hijack the terminology any more that the Linux losers are. > > I completely fail to see that you have actually stated a problem yet. > > > > What exactly is the problem you think you're trying to solve here? > > > > Consider the following. I have to restate this every damn couple > of weeks to get it through. Here is the problem: > > ISP#1 ISP#2 > | | > | | > --- xl0 FreeBSD xl1 ----- > xl2 > | > | > Internal network > | > | > Machine 1 Your FreeBSD machine in this example has three interfaces, and needs to run a routing daemon. This typically means either routed or gated. > Packet 1 comes in through ISP #2 network. It comes into your > internal network to machine 1. Machine 1 replies to the > packet...but where does it go? It will exit through interface > to ISP #1 because of the default gateway. It came in ISP #2 and > left out ISP #1. There is your problem. The default route for Machine 1 should be, of course, the FreeBSD machine. Having a default route on the FreeBSD machine is a configuration error, because a default route doesn't make sense in the case of such a machine. You *must* run a routing daemon and use a routing protocol compatible with ISP#1 and ISP#2. I think you were trying to say "route table" instead of "route cache", which does make sense with this setup. The simple answer is get a copy of a good book on TCP/IP network administration, learn how to configure routed, and use the stuff the way it was meant to be used. > What if you are running nat in this case....your hosed. Why? > You can check out route-cache at Cisco's online site. It may help > to clarify as to why you would want to do this. Just use a routing protocol, that's what they were designed for. > If you check the -net mailing list this problem re-occurs over and > over and over and over and over. To which there is a work around > that's a bit messy. Lots of problems occur over and over again, that's why people write books to explain things like this. Trying to fit some half-baked notion of how IP routing is supposed to work in the code isn't a solution. -- "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 Sat Mar 17 20:59:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 611A037B718 for ; Sat, 17 Mar 2001 20:59:11 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=2bd55f9991100ea717d0c2fb7c2c863d) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14eVIB-0007X5-00; Sat, 17 Mar 2001 21:59:47 -0700 Message-ID: <3AB440C3.81EA95F2@softweyr.com> Date: Sat, 17 Mar 2001 21:59:47 -0700 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: Alex Pilosov Cc: Nick Rogness , freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex Pilosov wrote: > > On Sat, 17 Mar 2001, Nick Rogness wrote: > > > There is no way to tell your packet to go back out to ISP #2. That is the > > point I'm trying to get across. Unless your running a routing > > daemon. But is that really practical with cable modems, dsl, etc?...I > > don't think so. > > Is the clue really gone from this list? > > > Now, correcting glaring mistakes of the above two posters: > > a) Multihomed means having two connections to public Internet Multihomed means having two network connections. Period. > b) route-cache means fast lookup of destination gateway. Lookup of > destination gateway may be slow (see d), and it makes sense to keep track > of a TCP connection and 'fast-switch' (cisco lingo) the following packets, > caching the following data (destination, ACL list) from the first packet. > Usually route-cache is implemented in hardware in ASICs, but sometimes it > may make sense to implement it in software (when overhead of connection > tracking is less than overhead of route/acl lookup). Like the fastpath routing code I used to write for Xylan/Alcatel? ;^) Let's review: the route cache was implemented in pseudo-CAMS (content addressable memory) that were part of an ASIC, in software running on the processors embedded in the ASIC. Yup, looks like we're in agreement on this one. > Route-cache has nothing to do with policy routing (d) Right. Nick keeps saying "route cache" when he means "route table". > c) Running routing daemons has, once again, nothing to do with policy > routing. It only means you are consensually exchanging routes with your > neighbours. IF you are big enough to run BGP4 to your upstreams, you need > to run routing daemon (gated/zebra/etc), and you are not likely to have > need for policy routing, because your IPs are all equal: all networks you > have can(will?) be delivered (and can be sent over) over any interface > that you have. Right. When you have more than one "upstream" connection, a routing deamon is a necessity. > d) Policy routing is a generic term for any sort of routing (i.e. choosing > of destination gateway for a packet) that is not exclusively based on > destination IP address. It may be based on src/dest port, TOS field, > source IP address, etc. Right. Most of it is pure voodoo, and network administrators all over the planet use it to regularly screw their networks into the ground, but it's one of those features that routing switches have to have these days. > FreeBSD has no support of that, to my knowledge. No, and thank ${FREEBSD_DEITY} for that. The reason for this is because FreeBSD is developed by people who understand how IP routing works, and refuse to dork it up with idiocies like "policy routing". > Linux has something called 'iproute2' which does support it, by having > multiple routing tables, and a ruleset that decides which routing table to > use based on packet details. But it's just a gross hack. Flapping your default route between whichever interface seems to be working best at the moment would be just as effective. > With policy routing, you indeed will be able to multihome, without any > cooperation of your upstream (assuming strict filters on their ingress > interfaces) and have things work. You can do the same by picking one to be the default route and then entering known-good routes via the other interface to destinations that you think are "closer" or "faster" via that interface. If you think you can actually better the performance of BGP4, prove it. The prize is more money than you can possibly imagine, and I'll be glad to help you spend it. It would be possible to write a routing daemon that somehow snarfs each of the addresses that hit the default route and play traceroute games to determine which of your public addresses have a "better" path to it, but what Nick really really needs to do is get a pair of ISPs that aren't incompetent and that provide RIP to downstream customers. -- "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 Sat Mar 17 21: 0:33 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 570BD37B719 for ; Sat, 17 Mar 2001 21:00:30 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=e2ac17607717542762bb10950cc925a6) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14eVJZ-0007XD-00; Sat, 17 Mar 2001 22:01:13 -0700 Message-ID: <3AB44119.3666D825@softweyr.com> Date: Sat, 17 Mar 2001 22:01:13 -0700 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: Nick Rogness Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Rogness wrote: > > On Sat, 17 Mar 2001, Nick Rogness wrote: > > More clarification. > > > > > > I completely fail to see that you have actually stated a problem yet. > > > > > > What exactly is the problem you think you're trying to solve here? > > > > > > > Consider the following. I have to restate this every damn couple > > of weeks to get it through. Here is the problem: > > > > > > ISP#1 ISP#2 > > | | > > | | > > --- xl0 FreeBSD xl1 ----- > > xl2 > > | > > | > > Internal network > > | > > | > > Machine 1 > > > > > > Packet 1 comes in through ISP #2 network. It comes into your > > internal network to machine 1. Machine 1 replies to the > > packet...but where does it go? It will exit through interface > > to ISP #1 because of the default gateway. It came in ISP #2 and > > left out ISP #1. There is your problem. > > There is no way to tell your packet to go back out to ISP #2. That is the > point I'm trying to get across. Unless your running a routing > daemon. But is that really practical with cable modems, dsl, etc?...I > don't think so. Why would the physical media have anything to do with routing protocols? > > What if you are running nat in this case....your hosed. > > natd on each interface is what I'm stating here...just to clarify. natd doesn't correctly translate RIP packets? -- "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 Sat Mar 17 21: 8: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 5393B37B718 for ; Sat, 17 Mar 2001 21:08:04 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=cff7b0dba39fca979b0dd9de92415bca) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14eVOz-0007XJ-00; Sat, 17 Mar 2001 22:06:49 -0700 Message-ID: <3AB44269.650C7BFC@softweyr.com> Date: Sat, 17 Mar 2001 22:06:49 -0700 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: Alex Pilosov Cc: Garrett Wollman , Nick Rogness , freebsd-net@FreeBSD.ORG Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex Pilosov wrote: > > On Sat, 17 Mar 2001, Garrett Wollman wrote: > > > That's the way Internet routing is supposed to work. If your routing > > table says a packet supposed to go one way, and it really needs to go > > another way, that's *user error* -- if you misconfigure your routing, > > FreeBSD will do what you ask it to; it can't read your mind! > > There are legitimate reasons why you may want more flexibility than simple > destination-based routing. I.E. Having two connections, one satellite > (fast cheap but high-latency) and one long-distance modem connection > (slow, expensive but low-latency) and dynamically routing telnet packets > over the modem connection. Or, traffic engineering: routing packets from a > certain blocks over a certain interface, etc. The above are all pretty much vanilla route table manipulations, and don't require any "policy routing" other than some route table developments. Policy routing is a tool network administrators use to generate customer support calls to their equipment vendors. There are legitimate uses for such things: interactive video over VLANs, end-to-end QoS reservations that prefer links that can provide QoS, etc., but the ability of just about anyone to correctly configure such things has yet to be shown in my experience. -- "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 Sat Mar 17 22: 1:26 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 00D7C37B719 for ; Sat, 17 Mar 2001 22:01:23 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2I65dA19265; Sun, 18 Mar 2001 00:05:40 -0600 (CST) (envelope-from nick@rogness.net) Date: Sun, 18 Mar 2001 00:05:39 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Wes Peters Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache In-Reply-To: <3AB44119.3666D825@softweyr.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 Sat, 17 Mar 2001, Wes Peters wrote: > > > > > > > > > Packet 1 comes in through ISP #2 network. It comes into your > > > internal network to machine 1. Machine 1 replies to the > > > packet...but where does it go? It will exit through interface > > > to ISP #1 because of the default gateway. It came in ISP #2 and > > > left out ISP #1. There is your problem. > > > > There is no way to tell your packet to go back out to ISP #2. That is the > > point I'm trying to get across. Unless your running a routing > > daemon. But is that really practical with cable modems, dsl, etc?...I > > don't think so. > > Why would the physical media have anything to do with routing protocols? Just TRY to ask your cable or DSL provider to do BGP or any routing...it aint going to happen. Watch them laugh in your face. The point here is getting way out of hand. Of course a routing daemon would work. That has been said by myself throughout this thread. That's not the point. Sure you can run a routing daemon...it won't do any good if it is not recieving any routes from your upstreams because they won't peer with you because you only pay $40 a month for the service. Not everyone can afford a damn T1 to an ISP, get IP space and setup BGP. Those same people most often look for a UNIX box of some sort to do what they want. Yes, there is a time and place for policy routing. Any Network engineer that has been actually supporting large networks can tell you why you would use it, and there ARE very good reason to do it. The fact is, many FreeBSD machines are running this type of setup. Wouldn't it be nice to say "yeh we can do that"? Unfortunetly, that does not appear to be the case because adding flexibility seems to cause problems in the traditional ways of the BSD folk...which is understandable...because you would be breaking the rules. I understand. PS: This is not a hack for me, Wes, I suggested it after working with several people having this same problem. There is a workaround that is pretty ugly so I was looking for a cleaner solution...that's all! Thanks for the comments. Keep up the good work! 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 Sat Mar 17 22:41:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id D034337B718 for ; Sat, 17 Mar 2001 22:41:34 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 5432 invoked by uid 666); 18 Mar 2001 06:42:53 -0000 Received: from i087-050.nv.iinet.net.au (HELO elischer.org) (203.59.87.50) by mail.m.iinet.net.au with SMTP; 18 Mar 2001 06:42:53 -0000 Message-ID: <3AB4586F.3BB7E1B@elischer.org> Date: Sat, 17 Mar 2001 22:40:47 -0800 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: Nick Rogness Cc: Alex Pilosov , freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Rogness wrote: > > > > > > The final step is to select to which divert rule the packets eventually get > > sent. > > Each divert rule goes to a different natd, each of which is attached to a > > different outgoing interface. > > I am going to look at what you suggested this afternoon to see if > it works. I forgot to say that the reason for having the natd in the picture is so that the source address gets changed to be on the appropriate interface thus ensuring that the return packets come back via the same path. To the internet it looks like two different machines. (You could actually do it with only one natd with all other packets going straight out..) > > Nick Rogness > - Keep on routing in a Free World... > "FreeBSD: The Power to Serve!" -- __--_|\ 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 Sat Mar 17 22:46:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id 504C337B718 for ; Sat, 17 Mar 2001 22:46:30 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 5667 invoked by uid 666); 18 Mar 2001 06:47:48 -0000 Received: from i087-050.nv.iinet.net.au (HELO elischer.org) (203.59.87.50) by mail.m.iinet.net.au with SMTP; 18 Mar 2001 06:47:48 -0000 Message-ID: <3AB45997.D82A43B9@elischer.org> Date: Sat, 17 Mar 2001 22:45:43 -0800 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: Nick Rogness Cc: Alex Pilosov , freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Rogness wrote: > > On Sat, 17 Mar 2001, Julian Elischer wrote: > > > Alex Pilosov wrote: > > > > > > On Sat, 17 Mar 2001, Nick Rogness wrote: > > > > > > > There is no way to tell your packet to go back out to ISP #2. That is the > > > > point I'm trying to get across. Unless your running a routing > > > > daemon. But is that really practical with cable modems, dsl, etc?...I > > > > don't think so. > > > > > > Is the clue really gone from this list? > > > > > > > > > > > > > > > With policy routing, you indeed will be able to multihome, without any > > > cooperation of your upstream (assuming strict filters on their ingress > > > interfaces) and have things work. > > > > it should be possible to use IPFW and natd to do this: > > IPFW could use Luigi's probability feature to select an interface to > > use for each initiating session and ipfw could use a stateful rule > > to 'remember the choice made' > > I would be interested to see what you are talking about with > probability. I'll play with it this afternoon. you could make the selection of interface based upon a single bit in the remote addres but if you were talking to one machine they would all go across the same interface. it may be more 'fair' to use luigi's random selection and make interface independent of destination AND source. > > Just to be clear to everyone, the problem I'm seeing is this: > > 1) Packet comes in with src A.A.A.A dest B.B.B.B in interface A > (in from ISP #2) > > 2) natd-2 (listening on interface A from ISP #2) changes the > destination from B.B.B.B to machine X.X.X.X (internal) > > 3) Packet gets sent to machine X.X.X.X on the internal network. > > 4) Machine X.X.X.X responds to B.B.B.B, sending the packet > back to the BSD machine. > > 5) The BSD machine looks up in the routing table how to get to > B.B.B.B. Oh no! Go out interface B connected to ISP#1...the > default gateway. > > 6) This triggers natd-1 to change the source to C.C.C.C and sends > the packet out to B.B.B.B on the default interface B because of > the default gateway. you should have used a 'dynamic rule' to capture the state of the session. I've never done this, only read the code. > > 7) Machine B.B.B.B is expecting a response from A.A.A.A, but > instead, it is seeing a response from C.C.C.C > > And Alex, you can't fwd based on source because of the 2 natd's > on 2 different interfaces. The firewall does not keep track of > INCOMING packets. So the firewall does not know the right > interface to forward the packet to, so the wrong natd get's > triggered. it's up to teh remote machine to decide who it talks to.. you just have t DNS entries. Once an interface has been selected you used dynamic rules to 'lock it in'. > > > > > > The final step is to select to which divert rule the packets eventually get > > sent. > > Each divert rule goes to a different natd, each of which is attached to a > > different outgoing interface. > > I am going to look at what you suggested this afternoon to see if > it works. > > Nick Rogness > - Keep on routing in a Free World... > "FreeBSD: The Power to Serve!" -- __--_|\ 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 Sat Mar 17 23:37:50 2001 Delivered-To: freebsd-net@freebsd.org Received: from online.tmx.com.au (online.tmx.com.au [192.150.129.1]) by hub.freebsd.org (Postfix) with ESMTP id 6CC6537B723 for ; Sat, 17 Mar 2001 23:37:45 -0800 (PST) (envelope-from mtaylor@bytecraft.com.au) Received: from melexc01.bytecraft.com.au ([203.9.250.249]) by online.tmx.com.au (8.9.3/8.8.8) with ESMTP id SAA08504 for Sun, 18 Mar 2001 18:37:35 +1100 (EST) Received: by MELEXC01 with Internet Mail Service (5.5.2448.0) id ; Sun, 18 Mar 2001 18:39:09 +1100 Message-ID: <710709BB8B02D311942E00606744181054429C@MELEXC01> From: Murray Taylor To: "'freebsd-net'" Subject: RE: Netgraph error message Date: Sun, 18 Mar 2001 18:38:11 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No it hasn't changed in 4.3-BETA ... I have added options NETGRAPH_FRAME_RELAY options NETGRAPH_LMI options NETGRAPH_SOCKET options NETGRAPH_RFC1490 options NETGRAPH_IFACE to my config and all is silent ... cheers mjt > -----Original Message----- > From: Udo Erdelhoff [SMTP:ue@nathan.ruhr.de] > Sent: Friday, 16 March 2001 17:43 > To: freebsd-net > Cc: Murray Taylor; 'freebsd-hackers@freebsd.org' > Subject: Re: Netgraph error message > > On Fri, Mar 16, 2001 at 11:39:10AM +1100, Murray Taylor wrote: > > I get the following messages when I fire up ngctl > > > > module_register: module netgraph already exists > > linker_file_sysinit: "netgraph.ko" failed to register 17 > > > > I am using 4.3-BETA as at 13/mar > > and have options NETGRAPH in my kernel config > > > > I am using the ngctl command to configure a frame relay system > > I assume that you are also using the netgraph nodes for frame relay. In > that case, the error messages are probably mostly harmless. I've had > similar messages when I tried to use mpd-netgraph on a box that had > options NETGRAPH/NETGRAPH_ETHER/NETGRAPH_SOCKET/NETGRAPH_PPPOE in > the kernel config. > > As far as I understand it, you have to use an all-or-nothing approach when > it comes to netgraph. If you do not include any netgraph modules in your > kernel, the system will load your modules and everything is fine. If you > include all neccessary modules into the kernel, things will work as well. > Things start to go downhill if some of the modules have been included in > the kernel and some others have to be loaded. The system gets the > information that the module NETGRAPH_FOO depends on NETGRAPH. The system > ignores that netgraph.ko is already present in the kernel and will try to > load the module. It's no big surprise that the operation fails. > > I managed to work around the problem by loading the additional modules > manually (kldload ng_foo;kldload ng_bar;...). The correct fix is to > include > all neccessary modules in your kernel. Use a second shell while you are > running ngctl and run kldstat. If you see any netgraph modules in the > output, add them to your kernel config. > > NOTE: This was on a 4.1-stable system, things may have changed since then. > > /s/Udo > -- > "I don't want to run a company. I'm not good at managing people. > You have a problem with the guy in the next cubicle? > I don't care. Shoot him or something." > -- Marc Andreesen, founder of Netscape, Rolling Stone, May 97 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message