From owner-freebsd-net Sun Mar 4 0:31: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from jason.argos.org (a1-3b010.neo.rr.com [24.93.181.10]) by hub.freebsd.org (Postfix) with ESMTP id 3A82337B718 for ; Sun, 4 Mar 2001 00:31:05 -0800 (PST) (envelope-from mike@jason.argos.org) Received: (from mike@localhost) by jason.argos.org (8.10.1/8.10.1) id f247tIS02432 for freebsd-net@freebsd.org; Sun, 4 Mar 2001 02:55:18 -0500 Date: Sun, 4 Mar 2001 02:55:18 -0500 From: Mike Nowlin To: freebsd-net@freebsd.org Subject: questions re: multiple internet conn routing Message-ID: <20010304025518.A1844@argos.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (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... The basic setup here (with just the single DSL line, 32 IPs on that line) is 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 vari= ous=20 ISDN links, plus another router that has a cable connection on it for outgo= ing=20 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=20 B..:) ) Ah, the joys of having a network supporting a lot of physical locations that has to be cost-effective.. 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 =20 =2E..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 --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjqh9OYACgkQJol4I8h9Gd+avwCfRyqG5xDglDdIFdwfvT1wBRkQ nq8AoIwIRd/pgU6TjsP/v7M6vR2ZFVyd =dKQP -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 4 2: 9:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id 206FF37B721 for ; Sun, 4 Mar 2001 02:09:55 -0800 (PST) (envelope-from hsu@FreeBSD.org) Received: from FreeBSD.org ([63.193.112.125]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G9O0030N3FU1C@mta6.snfc21.pbi.net> for freebsd-net@FreeBSD.ORG; Sun, 4 Mar 2001 01:52:42 -0800 (PST) Date: Sun, 04 Mar 2001 01:59:40 -0800 From: Jeffrey Hsu Subject: Re: how to implement TCP using RAW sockets To: guruchakravarthy@hotmail.com Cc: freebsd-net@FreeBSD.ORG Message-id: <0G9O0030O3FU1C@mta6.snfc21.pbi.net> MIME-version: 1.0 X-Mailer: exmh version 2.1.1 10/15/1999 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You might want to check out http://alpine.cs.washington.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 4 7:54:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from color.sics.se (color.sics.se [193.10.66.199]) by hub.freebsd.org (Postfix) with ESMTP id 1481237B718 for ; Sun, 4 Mar 2001 07:54:32 -0800 (PST) (envelope-from adam@sics.se) Received: from sidewalker.sics.se (sidewalker.sics.se [193.10.66.107]) by color.sics.se (8.9.3/8.9.3) with SMTP id QAA11994; Sun, 4 Mar 2001 16:54:12 +0100 (MET) env-to () env-from (adam@sics.se) Content-Type: text/plain; charset="iso-8859-1" From: Adam Dunkels To: "guru chakravarthy" , ilugc@aero.iitm.ernet.in, freebsd-net@FreeBSD.ORG, molter@tin.it, brandt@fokus.gmd.de Subject: Re: how to implement TCP using RAW sockets Date: Sun, 4 Mar 2001 16:52:16 +0100 X-Mailer: KMail [version 1.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <01030416521600.21726@sidewalker.sics.se> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Saturday 03 March 2001 11:39, guru chakravarthy wrote: > hai > > As a final year UG project we are doing implementation of TCP with some > modifications to it using IP Raw sockets in linux can any one show me some > help pages where i can find help on Raw socket implementation and other > details . > Is there any such implementation help on the net . ? I would suggest implementing it using the tun network interface (see "man tun" on FreeBSD). With this, it is possible to read and write packets directly from and to the kernel. It is also possible to use tcpdump to inspect the packets on the tun interface. I used this with great success when implementing the lwIP TCP/IP stack (http://www.sics.se/~adam/lwip). For Linux, the virtual tunneling device at http://vtun.sourceforge.net/ seems to have the same functionality as the BSD tun interface (and more), but I haven't had the time to test it. /adam -- Adam Dunkels http://www.sics.se/~adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 4 11:41:14 2001 Delivered-To: freebsd-net@freebsd.org Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by hub.freebsd.org (Postfix) with ESMTP id AB55D37B718 for ; Sun, 4 Mar 2001 11:41:11 -0800 (PST) (envelope-from pingpan@bourbon.cs.columbia.edu) Received: from bourbon.cs.columbia.edu (bourbon.cs.columbia.edu [128.59.19.24]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA10795; Sun, 4 Mar 2001 14:40:44 -0500 (EST) Received: from localhost (pingpan@localhost) by bourbon.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA14323; Sun, 4 Mar 2001 14:40:31 -0500 (EST) Date: Sun, 4 Mar 2001 14:40:31 -0500 (EST) From: Ping Pan To: guru chakravarthy Cc: , , , Subject: Re: how to implement TCP using RAW sockets 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 I think you can add a new protocol family to RAW, and intercept all TCP packets from the kernel directly. Check how to do that from Stevens's Vol 2 book. Should be simple. On Sat, 3 Mar 2001, guru chakravarthy wrote: > hai > > As a final year UG project we are doing implementation of TCP with some > modifications to it using IP Raw sockets in linux can any one show me some > help pages where i can find help on Raw socket implementation and other > details . > Is there any such implementation help on the net . ? > > It would be of great help if u can do this . > thanks > guru > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Mar 4 21:14:27 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 C9E4937B71A for ; Sun, 4 Mar 2001 21:14:17 -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 QAA24322 for Mon, 5 Mar 2001 16:14:03 +1100 (EST) Received: by MELEXC01 with Internet Mail Service (5.5.2448.0) id ; Mon, 5 Mar 2001 16:14:30 +1100 Message-ID: <710709BB8B02D311942E006067441810544275@MELEXC01> From: Murray Taylor To: "'freebsd-net@freebsd.org'" Subject: firewalling with NAT and PPP Date: Mon, 5 Mar 2001 16:13:35 +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 More questions as I attempt to get over the "learning cliff"! Do I run PPP with its nat actions enabled in the following setup or do I run natd on both interfaces NOTE: I'm still waiting for my hardware to turn up for the frame relay interface, so I'm just trying to get ahead... |============================| | ++++++++ | frame relay <- net x.y.z.0/26 ->| sr0<->ng0 <-> + ipfw + | | + & + | modem <- dynamic addr --->| tun0 <------> + natd + | | ++++++++ | | ^ | | | | internal net <--- 10.1.2.0/16 ->| fxp0 <------------ | | | future x.y.z.n machines <------>| fxp1 <--- ?? bridge ?? | | | | FreeBSD 4.2 release | |============================| My proposed firewall rules are like this so far ;-) (see below) Please see the area near the Big ?? mark... And later on I could be 'bridging' the x.y.z.0/26 net out 'sideways' to other machines that need to be directly visible on the internet via a fxp1 port. - Is bridging the appropriate method ?? - Do the other machines benefit from this firewall or do I need to make individual ones on the extra machines?? I'm in the process of acquiring the new FreeBSD Corporate Networkers Guide which I hope will become another useful "FM to R" on the bookshelf, but it appears to be a long snail trail from USofA to the Land Downunder ;-( cheers Murray Taylor Project Engineer Bytecraft P/L +61 3 9587 2555 +61 3 9587 1614 fax mtaylor@bytecraft.com.au ############ # Only in rare cases do you want to change these rules # ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 # If you're using 'options BRIDGE', uncomment the following line to pass ARP #${fwcmd} add 300 pass udp from 0.0.0.0 2054 to 0.0.0.0 # add deny all rule (current chicken/learning mode kernel is allow all from any to any) ###$(fxcmd) add 65000 deny all from any to any # This is a prototype setup for a simple firewall. Configure this # machine as a named server and ntp server, and point all the machines # on the inside at this machine for those services. ############ # outside interface network and netmask and ip frame_if="ng0" frame_net="x.y.z.0" frame_mask="255.255.255.192" frame_ip="x.y.z.1" # tun modem interface tun_if="tun0" # inside interface network and netmask and ip my_if="fxp0" my_net="10.1.2.0" my_mask="255.255.0.0" my_ip="10.1.2.30" # Stop spoofing ${fwcmd} add deny all from $(my_net):$(my_mask) to any in via $(frame_if) ${fwcmd} add deny all from $(my_net):$(my_mask) to any in via $(tun_if) ${fwcmd} add deny all from $frame_net):$frame_mask) to any in via $(my_if) # Stop RFC1918 nets on the outside interfaces ${fwcmd} add deny all from any to 10.0.0.0/8 via ${frame_if} ${fwcmd} add deny all from any to 10.0.0.0/8 via ${tun_if} ${fwcmd} add deny all from any to 172.16.0.0/12 via ${frame_if} ${fwcmd} add deny all from any to 172.16.0.0/12 via ${tun_if} ${fwcmd} add deny all from any to 192.168.0.0/16 via ${frame_if} ${fwcmd} add deny all from any to 192.168.0.0/16 via ${tun_if} # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interfaces ${fwcmd} add deny all from any to 0.0.0.0/8 via ${frame_if} ${fwcmd} add deny all from any to 0.0.0.0/8 via ${tun_if} ${fwcmd} add deny all from any to 169.254.0.0/16 via ${frame_if} ${fwcmd} add deny all from any to 169.254.0.0/16 via ${tun_if} ${fwcmd} add deny all from any to 192.0.2.0/24 via ${frame_if} ${fwcmd} add deny all from any to 192.0.2.0/24 via ${tun_if} ${fwcmd} add deny all from any to 224.0.0.0/4 via ${frame_if} ${fwcmd} add deny all from any to 224.0.0.0/4 via ${tun_if} ${fwcmd} add deny all from any to 240.0.0.0/4 via ${frame_if} ${fwcmd} add deny all from any to 240.0.0.0/4 via ${tun_if} # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP # address set to 192.0.2.1 then an incoming packet for it after being # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. # # natd interface should be frame relay netgraph output {fwcmd} add divert natd all from any to any via ${frame_if} # ?????? # ?? ?? # ?? # ?? # ?? # ?? # # ?? # # should this be here with PPP not doing nat # or should I move some of the tun rules up earlier with PPP doing nat {fwcmd} add divert natd all from any to any via ${tun_if} # Stop RFC1918 nets on the outside interfaces ${fwcmd} add deny all from 10.0.0.0/8 to any via ${frame_if} ${fwcmd} add deny all from 10.0.0.0/8 to any via ${tun_if} ${fwcmd} add deny all from 172.16.0.0/12 to any via ${frame_if} ${fwcmd} add deny all from 172.16.0.0/12 to any via ${tun_if} ${fwcmd} add deny all from 192.168.0.0/16 to any via ${frame_if} ${fwcmd} add deny all from 192.168.0.0/16 to any via ${tun_if} # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interfaces ${fwcmd} add deny all from 0.0.0.0/8 to any via ${frame_if} ${fwcmd} add deny all from 0.0.0.0/8 to any via ${tun_if} ${fwcmd} add deny all from 169.254.0.0/16 to any via ${frame_if} ${fwcmd} add deny all from 169.254.0.0/16 to any via ${tun_if} ${fwcmd} add deny all from 192.0.2.0/24 to any via ${frame_if} ${fwcmd} add deny all from 192.0.2.0/24 to any via ${tun_if} ${fwcmd} add deny all from 224.0.0.0/4 to any via ${frame_if} ${fwcmd} add deny all from 224.0.0.0/4 to any via ${tun_if} ${fwcmd} add deny all from 240.0.0.0/4 to any via ${if} # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established # Allow IP fragments to pass through ${fwcmd} add pass all from any to any frag # Allow setup of incoming email ${fwcmd} add pass tcp from any to ${frame_ip} 25 setup # Allow access to our DNS ${fwcmd} add pass tcp from any to ${frame_ip} 53 setup ${fwcmd} add pass udp from any to ${frame_ip} 53 ${fwcmd} add pass udp from ${frame_ip} 53 to any # Allow access to our WWW ${fwcmd} add pass tcp from any to ${frame_ip} 80 setup # Reject&Log all setup of incoming connections from the outside ${fwcmd} add deny log tcp from any to any in via ${frame_if} setup ${fwcmd} add deny log tcp from any to any in via ${tun_if} setup # Allow setup of any other TCP connection ${fwcmd} add pass tcp from any to any setup # Allow DNS queries out in the world ${fwcmd} add pass udp from any 53 to ${frame_ip} ${fwcmd} add pass udp from ${frame_ip} to any 53 # Allow NTP queries out in the world ${fwcmd} add pass udp from any 123 to ${frame_ip} ${fwcmd} add pass udp from ${frame_ip} to any 123 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 5 4:34:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 3369837B719 for ; Mon, 5 Mar 2001 04:34:23 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f25CYFI22344 for freebsd-net@freebsd.org; Mon, 5 Mar 2001 14:34:15 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200103051234.f25CYFI22344@zibbi.icomtek.csir.co.za> Subject: kernel: nd6_storelladdr failed, mbuf leak To: freebsd-net@freebsd.org Date: Mon, 5 Mar 2001 14:34:15 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL54 (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 configured a 4-stable machine to be a router, routing ipv4, ipv6 and ipx. To be able to do Ethernet_II framing on one interface and 802.3 on another I have used if_ef.ko. I then noticed that "... kernel: nd6_storelladdr failed" gets logged often and after a while all mbufs are used. It turned out that in sys/net/if_ethersubr.c in ether_output() when nd6_storelladdr() fails, it does a return(0) and does not free the mbuf. I checked -current and it is still like that. Now the reason it fails is that the ef(4) device use an ifp->if_type (IFT_XETHER) that nd6_storelladdr() does not expect. Oh as a workaround I have configured route6d to ignore fxp1f0. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 5 10:17:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id 49D3137B718 for ; Mon, 5 Mar 2001 10:17:22 -0800 (PST) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f25IHJ148704 for ; Mon, 5 Mar 2001 18:17:20 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Mon, 5 Mar 2001 18:17:19 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: freebsd-net@FreeBSD.ORG Subject: - TFTP: Time out - 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 +-----------+ +------------+ |FreeBSD 4.1|<--------->| Cisco 3640 | +-----------+ +------------+ I want to transfer a file from the FreeBSD machine to the Cisco. My machine is configured as a TFTP server and the cisco is "configured" as a client. The TFTP communication is stopped because of a timeout. Why should I have a timeout ? BUT, I can transfer a files from the Cisco to my machine witout any trouble. at this moment, the cisco is configured as a TFTP Server, and I think that my machine also, but it reacts as a client. Thanks, JC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 5 10:23:20 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 3298637B719 for ; Mon, 5 Mar 2001 10:23:16 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f25INCJ01001; Mon, 5 Mar 2001 10:23:12 -0800 (PST) Date: Mon, 5 Mar 2001 10:23:12 -0800 From: Alfred Perlstein To: Jean-Christophe Varaillon Cc: freebsd-net@FreeBSD.ORG Subject: Re: - TFTP: Time out - Message-ID: <20010305102312.U8663@fw.wintelcom.net> 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 jcv@vbc.net on Mon, Mar 05, 2001 at 06:17:19PM +0000 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Jean-Christophe Varaillon [010305 10:17] wrote: > > +-----------+ +------------+ > |FreeBSD 4.1|<--------->| Cisco 3640 | > +-----------+ +------------+ > > I want to transfer a file from the FreeBSD machine to the Cisco. > My machine is configured as a TFTP server and the cisco is "configured" > as a client. > > The TFTP communication is stopped because of a timeout. > > Why should I have a timeout ? Because afaik tftp has a really terrible client/server notion, there's no good way to tell if a client has 'gone away'. Without the timeout, if a client was to disappear the tftpd server would hang around forever. > BUT, I can transfer a files from the Cisco to my machine witout any > trouble. at this moment, the cisco is configured as a TFTP Server, and I > think that my machine also, but it reacts as a client. You should probably be able to fix this by changing the value of "TIMEOUT" in /usr/src/libexec/tftpd/tftpd.c, then doing this in /usr/src/libexec/tftpd: make ; make install -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 5 10:24:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 8A2CA37B719 for ; Mon, 5 Mar 2001 10:24:51 -0800 (PST) (envelope-from bmilekic@technokratis.com) Received: from jehovah ([24.202.203.190]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G9QLRB04.9M2; Mon, 5 Mar 2001 13:23:35 -0500 Message-ID: <005901c0a5a1$c54476d0$becbca18@jehovah> From: "Bosko Milekic" To: "John Hay" , References: <200103051234.f25CYFI22344@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak Date: Mon, 5 Mar 2001 13:26:17 -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 John Hay wrote: > I have configured a 4-stable machine to be a router, routing ipv4, ipv6 > and ipx. To be able to do Ethernet_II framing on one interface and 802.3 > on another I have used if_ef.ko. > > I then noticed that "... kernel: nd6_storelladdr failed" gets logged > often and after a while all mbufs are used. It turned out that in > sys/net/if_ethersubr.c in ether_output() when nd6_storelladdr() fails, > it does a return(0) and does not free the mbuf. I checked -current > and it is still like that. It should not be freeing the mbuf, because that mbuf is being passed as an argument to ether_output(). It is typically the caller that ought to be responsible for freeing the mbuf in this case. > Now the reason it fails is that the ef(4) device use an ifp->if_type > (IFT_XETHER) that nd6_storelladdr() does not expect. > > Oh as a workaround I have configured route6d to ignore fxp1f0. > > John > -- > John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 5 12: 4:47 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 6B91A37B718 for ; Mon, 5 Mar 2001 12:04:40 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f25K3vd32980; Mon, 5 Mar 2001 22:03:57 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200103052003.f25K3vd32980@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak In-Reply-To: <005901c0a5a1$c54476d0$becbca18@jehovah> from Bosko Milekic at "Mar 5, 2001 01:26:17 pm" To: bmilekic@technokratis.com (Bosko Milekic) Date: Mon, 5 Mar 2001 22:03:57 +0200 (SAT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I have configured a 4-stable machine to be a router, routing ipv4, > ipv6 > > and ipx. To be able to do Ethernet_II framing on one interface and > 802.3 > > on another I have used if_ef.ko. > > > > I then noticed that "... kernel: nd6_storelladdr failed" gets logged > > often and after a while all mbufs are used. It turned out that in > > sys/net/if_ethersubr.c in ether_output() when nd6_storelladdr() > fails, > > it does a return(0) and does not free the mbuf. I checked -current > > and it is still like that. > > It should not be freeing the mbuf, because that mbuf is being > passed as an argument to ether_output(). It is typically the caller > that ought to be responsible for freeing the mbuf in this case. The purpose of ether_output() is normally to get the packet (mbuf) onto the correct interface queue so that it will be sent out. As such whoever calls ether_output() is not going to do anything with that mbuf again. If ether_output don't put it on a queue, it should free it. Well maybe I was a bit vague about the exact place. I claim that the return(0) at line 188 of if_ethersubr.c in -stable and line 189 in -current should be "goto bad" or something that will either use the mbuf or do a m_freem() and not just return and leave the mbuf in the air. The code looks something like this: case AF_INET6: if (!nd6_storelladdr(&ac->ac_if, rt, m, dst, (u_char *)edst)) { /* this must be impossible, so we bark */ printf("nd6_storelladdr failed\n"); ===> return(0); } > > > Now the reason it fails is that the ef(4) device use an ifp->if_type > > (IFT_XETHER) that nd6_storelladdr() does not expect. > > > > Oh as a workaround I have configured route6d to ignore fxp1f0. > > John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 5 14:21:14 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 5938637B718 for ; Mon, 5 Mar 2001 14:21:06 -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 f25MhlY36059; Mon, 5 Mar 2001 16:43:47 -0600 (CST) (envelope-from nick@rogness.net) Date: Mon, 5 Mar 2001 16:43:46 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Mike Nowlin Cc: freebsd-net@FreeBSD.ORG Subject: Re: questions re: multiple internet conn routing In-Reply-To: <20010304025518.A1844@argos.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 Sun, 4 Mar 2001, Mike Nowlin wrote: > > Just had a second DSL connection installed, and have several questions > regarding how to map it into the FBSD router we use... > > The basic setup here (with just the single DSL line, 32 IPs on that > line) is 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.. > > 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? You should run 2 different copies of natd. More comments below. > > 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. The closest thing to Cisco's policy based routing (not including netgraph) is `ipfw fwd`. As a side note, 1 thing you are going to have a problem with is routing out these 2 different DSL providers. Once the packet gets diverted (inbound from DSL provider-2) to a private address and ran through your network, it doesn't know how to get back through to the original source DSL (provider2) network, if your default gateway is through DSL provider1. There is no way in FreeBSD to do route caching on inbound interfaces. If your DSL provider #1 is allowing only your hosts IP's to go through his network (likely) you're SOL! However, there is a solution to this problem. Run 3 copies of natd [!!], Why??? I'll see if I can explain. Consider the folowing diagram: ISP #1 ISP #2 | | \ / dc0 - BSD - dc1 | fxp0 | Internet net (10.0.0.0) The BSD machine is running 2 different copies of natd both operating on dc0 and dc1. It's default gateway is through ISP #1. What happens when packets originate from (or through) ISP #2? : 1) Packets get diverted to the proper redirect_address inside 2) Packets get sent to the internal machine 3) Machine responds to packet, sending it to the BSD machine ==> 4) BSD machine tries to send out ISP #1 because of default gateway 5) ...timeout...timeout...timeout... ACK! This is because FreeBSD doesn't support route caching. So you solve this by tagging packets coming in from ISP #2 by chaning the source address using natd -reverse and aliasing all inbound traffic to a non-routeable like (192.168.1.1). This tricks the internal machines to think that all traffic from ISP #2 is coming from one machine, 192.168.1.1. Now you can add the appropriate route on your BSD machine: # route add 192.168.1.1 -iface dc1 and force the packets to go the right way as they are on the return from the internal machines. Here's the tricky part. You also want to change the destination address (redirect_address) after the source address has been changed to 192.168.1.1 on incoming packets. This is were your 3rd natd comes into play. This 3rd natd will also keep track of your outbound address translations as well. So here is how the packets get treated for ISP #2 traffic: 1) Packets come in from a host (3.3.3.3) via ISP #2 2) destination address is changed to internal machine-A 3) Source address (3.3.3.3) is changed to 192.168.1.1 4) Packet is sent to machine-A 5) machine-A responds to packet, sends to BSD machine 6) BSD machine changes destination from 192.168.1.1 to 3.3.3.3 7) BSD machine changes source address from internal to public 8) Packet is sent to ISP #2 (ipfw fwd). The firewall rules for these operations are a tad tricky. Using a combination of skipto's, natd's, and fwd it seems to work OK. If anyone would like more detail (config files, etc) please let me know. There may be a better solution...anyone? 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 Mon Mar 5 19:43:47 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 180C837B719; Mon, 5 Mar 2001 19:43:35 -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 OAA20208; Tue, 6 Mar 2001 14:42:35 +1100 (EST) Received: by MELEXC01 with Internet Mail Service (5.5.2448.0) id ; Tue, 6 Mar 2001 14:42:43 +1100 Message-ID: <710709BB8B02D311942E006067441810544276@MELEXC01> From: Murray Taylor To: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: Firewalls and Samba Date: Tue, 6 Mar 2001 14:42:34 +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 Why is the firewall stopping Samba ??? OS - FreeBSD 4.2 Samba - 2.0.7 The general network is based on NT 4 servers with a PDC and BDC server, WINS servers, and DHCP addressing for all but the main servers. This is the first machine on the network that is FreeBSD. (There WILL be more if I have my way ;-) As such the Samba settings have been set to prevent browser elections etc. Until the Firewall was setup, all has been OK. Given the following Samba config file and the attached firewall rules, can it please be determined what is stoppping W95 explorer from finding the Samba shares? >> This also all applies to W98 << Upon Windoze boot, if net.inet.ip.fw.enable = 1, the shares are not visible, and indeed W95 thinks that Spyder is not on the network. If I set sysctl net.inet.ip.fw.enable = 0, W95 can immediately see the shares, both home and the webadmin share. Then I can reset net.inet.ip.fw.enable = 1, and Spyder and its shares remain visible to those who have already accessed them. Note that Spyder is pingable, telnetable, web browsable at all times from machines on our intranet EXAMPLE 1 If I select a Samba share with the firewall enabled, wait till W95 shows its hourglass, then quickly open the firewall via a telnet session, W95 then drops the hourglass and opens the share... so it appears that W95 is getting caught on something in a retry loop EXAMPLE 2 If I boot with the firewall enabled, W95 gets hung trying to reattach the shares. Cancelling the attachment allows the boot to continue. Explorer cannot open the shares and thinks that Spyder is not on the net. After disabling the firewall, the shares are still not visible from other programs (ie Notepad), unless and until I have selected the shares once in Explorer. Then all is AOK. I can then enable the firewall and continue. I have a NAI Sniffer capture file available of the attempt to connect Explorer with the firewall active... which seems to me to show a successful connection?? Most of the ipfw rules are taken from the 'simple' setting in rc.firewall. Rule 150 is my last attempt to open the door.... The firewall is defaulted to accept at present ************* The 128.1.2.x numbers are a historical 'hangover' from early company intranet days and are being changed to 10.1.2.x this Friday evening (the ancient chinese curse 'May you live in interesting times' will probably apply on this day/night...) The firewall rules are established at present, but the modem will not be physically connected to tun0's serial port until after Friday ************* I am currently considering this a firewall problem, not a Samba problem so am only posting it to -net and -questions at present. Murray Taylor Project Engineer Bytecraft P/L +61 3 9587 2555 +61 3 9587 1614 fax mtaylor@bytecraft.com.au ----------8<-------smb.conf # Samba config file created using SWAT # from 128.1.2.48 (128.1.2.48) # Date: 2001/02/28 10:03:54 # Global parameters [global] workgroup = BYTEMELB netbios name = SPYDER interfaces = fxp0 security = DOMAIN encrypt passwords = Yes password server = * os level = 0 local master = No wins server = 128.1.2.3 guest account = pcguest [homes] comment = Home Directories writeable = Yes browseable = No [webadmin] comment = Web Administrators path = /usr/web valid users = @webadmin writeable = Yes browseable = No ----------8<-------ipfw list output 00100 allow ip from any to any via lo0 00150 allow ip from any to any via fxp0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from any to 10.0.0.0/8 via tun0 00400 deny ip from any to 172.16.0.0/12 via tun0 00500 deny ip from any to 192.168.0.0/16 via tun0 00600 deny ip from any to 0.0.0.0/8 via tun0 00700 deny ip from any to 169.254.0.0/16 via tun0 00800 deny ip from any to 192.0.2.0/24 via tun0 00900 deny ip from any to 224.0.0.0/4 via tun0 01000 deny ip from any to 240.0.0.0/4 via tun0 01100 deny ip from 10.0.0.0/8 to any via tun0 01200 deny ip from 172.16.0.0/12 to any via tun0 01300 deny ip from 192.168.0.0/16 to any via tun0 01400 deny ip from 0.0.0.0/8 to any via tun0 01500 deny ip from 169.254.0.0/16 to any via tun0 01600 deny ip from 192.0.2.0/24 to any via tun0 01700 deny ip from 224.0.0.0/4 to any via tun0 01800 deny ip from 240.0.0.0/4 to any via tun0 01900 allow tcp from any to any established 02000 allow ip from any to any frag 02100 deny log logamount 100 tcp from any to any in recv tun0 setup 02200 allow tcp from any to any setup 65535 allow ip from any to any To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Mar 5 22: 0:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id D3A3537B719 for ; Mon, 5 Mar 2001 22:00:10 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f265xwP47418; Tue, 6 Mar 2001 07:59:58 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200103060559.f265xwP47418@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak In-Reply-To: <200103052003.f25K3vd32980@zibbi.icomtek.csir.co.za> from John Hay at "Mar 5, 2001 10:03:57 pm" To: jhay@icomtek.csir.co.za (John Hay) Date: Tue, 6 Mar 2001 07:59:58 +0200 (SAT) Cc: bmilekic@technokratis.com (Bosko Milekic), freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > I have configured a 4-stable machine to be a router, routing ipv4, > > ipv6 > > > and ipx. To be able to do Ethernet_II framing on one interface and > > 802.3 > > > on another I have used if_ef.ko. > > > > > > I then noticed that "... kernel: nd6_storelladdr failed" gets logged > > > often and after a while all mbufs are used. It turned out that in > > > sys/net/if_ethersubr.c in ether_output() when nd6_storelladdr() > > fails, > > > it does a return(0) and does not free the mbuf. I checked -current > > > and it is still like that. > > > > It should not be freeing the mbuf, because that mbuf is being > > passed as an argument to ether_output(). It is typically the caller > > that ought to be responsible for freeing the mbuf in this case. > > The purpose of ether_output() is normally to get the packet (mbuf) > onto the correct interface queue so that it will be sent out. As such > whoever calls ether_output() is not going to do anything with that > mbuf again. If ether_output don't put it on a queue, it should free > it. > > Well maybe I was a bit vague about the exact place. I claim that the > return(0) at line 188 of if_ethersubr.c in -stable and line 189 in > -current should be "goto bad" or something that will either use the > mbuf or do a m_freem() and not just return and leave the mbuf in the > air. > > The code looks something like this: > > case AF_INET6: > if (!nd6_storelladdr(&ac->ac_if, rt, m, dst, (u_char *)edst)) { > /* this must be impossible, so we bark */ > printf("nd6_storelladdr failed\n"); > ===> return(0); > } > I can try a different route too. You don't need to believe me, you can try it yourself. It isn't that much work. Build and install a kernel compiled with "options IPX" and "options INET6". Add a line if_ef_load="YES" to /boot/loader.conf. Add the line ipv6_enable="YES" to /etc/rc.conf. (I think this should be enough even if you don't have an ipv6 network.) Reboot. Login and then do the following, adjusting for your ethernet interface. Mine is fxp0. ifconfig fxp0f0 0x1234 ping6 ff02::%fxp0f0 You should now see "nd6_storelladdr failed" being written to your console. Monitor your mbuf usage with "netstat -m". John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 1:13: 1 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id 4FE7D37B718 for ; Tue, 6 Mar 2001 01:12:52 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14aDWT-0005iR-00; Tue, 6 Mar 2001 09:12:49 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aDUT-0003WO-00; Tue, 6 Mar 2001 09:10:45 +0000 From: "Andy [TECC NOPS]" To: "Alfred Perlstein" , "Jean-Christophe Varaillon" Cc: Subject: RE: - TFTP: Time out - Date: Tue, 6 Mar 2001 09:17:11 -0000 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20010305102312.U8663@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I always had these kinda problems both with FreeBSD, Linux, etc etc. Found various ways around them in the end but the best way is if you are running a version of IOS 12.0 or later on the Cisco then use the newer copy commands in IOS that allow ftp eg:- router> copy ftp://user:pass@box.whatever/config.cond startup-config much better than :- router> copy tftp startup-config Regards Andy > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Alfred Perlstein > Sent: 05 March 2001 18:23 > To: Jean-Christophe Varaillon > Cc: freebsd-net@FreeBSD.ORG > Subject: Re: - TFTP: Time out - > > > * Jean-Christophe Varaillon [010305 10:17] wrote: > > > > +-----------+ +------------+ > > |FreeBSD 4.1|<--------->| Cisco 3640 | > > +-----------+ +------------+ > > > > I want to transfer a file from the FreeBSD machine to the Cisco. > > My machine is configured as a TFTP server and the cisco is "configured" > > as a client. > > > > The TFTP communication is stopped because of a timeout. > > > > Why should I have a timeout ? > > Because afaik tftp has a really terrible client/server notion, > there's no good way to tell if a client has 'gone away'. Without > the timeout, if a client was to disappear the tftpd server would > hang around forever. > > > BUT, I can transfer a files from the Cisco to my machine witout any > > trouble. at this moment, the cisco is configured as a TFTP > Server, and I > > think that my machine also, but it reacts as a client. > > You should probably be able to fix this by changing the value of > "TIMEOUT" in /usr/src/libexec/tftpd/tftpd.c, then doing this in > /usr/src/libexec/tftpd: > > make ; make install > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 3:10: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id B0EAD37B719 for ; Tue, 6 Mar 2001 03:09:55 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14aFLj-0006Ou-00; Tue, 6 Mar 2001 11:09:51 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aFJi-00044P-00; Tue, 6 Mar 2001 11:07:46 +0000 From: "Andy [TECC NOPS]" To: "Jean-Christophe Varaillon" Cc: Subject: RE: - TFTP: Time out - Date: Tue, 6 Mar 2001 11:14:14 -0000 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > -----Original Message----- > From: Jean-Christophe Varaillon [mailto:jcv@vbc.net] > Sent: 06 March 2001 10:57 > Subject: RE: - TFTP: Time out - > > > Hi Andy, > > Do you know if it is possible to creat a blank file on the directory > Flash: of a cisco router 3640 ? I think "router> copy null flash:filename" should do the trick. Make use of the cisco online help. For example, using the ? char as below will provide you with most of what you need on ciscos. router> copy ? /erase Erase destination file system. flash: Copy from flash: file system ftp: Copy from ftp: file system null: Copy from null: file system nvram: Copy from nvram: file system rcp: Copy from rcp: file system running-config Copy from current system configuration slot0: Copy from slot0: file system slot1: Copy from slot1: file system startup-config Copy from startup configuration system: Copy from system: file system tftp: Copy from tftp: file system xmodem: Copy from xmodem: file system ymodem: Copy from ymodem: file system router> copy null ? flash: Copy to flash: file system ftp: Copy to ftp: file system lex: Copy to lex: file system null: Copy to null: file system nvram: Copy to nvram: file system rcp: Copy to rcp: file system running-config Update (merge with) current system configuration startup-config Copy to startup configuration system: Copy to system: file system tftp: Copy to tftp: file system router> copy null I used one of the Cisco 3660's here for these examples (rather than a 3640 you have) but the results will be pretty much the same. Regards Andy > > Regards, > Jean-Christophe. > > On Tue, 6 Mar 2001, Andy [TECC NOPS] wrote: > > > I always had these kinda problems both with > > FreeBSD, Linux, etc etc. Found various ways > > around them in the end but the best way is if > > you are running a version of IOS 12.0 or later > > on the Cisco then use the newer copy commands > > in IOS that allow ftp eg:- > > > > router> copy ftp://user:pass@box.whatever/config.cond startup-config > > > > much better than :- > > > > router> copy tftp startup-config > > > > Regards > > Andy > > > > > -----Original Message----- > > > From: owner-freebsd-net@FreeBSD.ORG > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Alfred Perlstein > > > Sent: 05 March 2001 18:23 > > > To: Jean-Christophe Varaillon > > > Cc: freebsd-net@FreeBSD.ORG > > > Subject: Re: - TFTP: Time out - > > > > > > > > > * Jean-Christophe Varaillon [010305 10:17] wrote: > > > > > > > > +-----------+ +------------+ > > > > |FreeBSD 4.1|<--------->| Cisco 3640 | > > > > +-----------+ +------------+ > > > > > > > > I want to transfer a file from the FreeBSD machine to the Cisco. > > > > My machine is configured as a TFTP server and the cisco is > "configured" > > > > as a client. > > > > > > > > The TFTP communication is stopped because of a timeout. > > > > > > > > Why should I have a timeout ? > > > > > > Because afaik tftp has a really terrible client/server notion, > > > there's no good way to tell if a client has 'gone away'. Without > > > the timeout, if a client was to disappear the tftpd server would > > > hang around forever. > > > > > > > BUT, I can transfer a files from the Cisco to my machine witout any > > > > trouble. at this moment, the cisco is configured as a TFTP > > > Server, and I > > > > think that my machine also, but it reacts as a client. > > > > > > You should probably be able to fix this by changing the value of > > > "TIMEOUT" in /usr/src/libexec/tftpd/tftpd.c, then doing this in > > > /usr/src/libexec/tftpd: > > > > > > make ; make install > > > > > > -- > > > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 3:27:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id 01FCB37B719 for ; Tue, 6 Mar 2001 03:27:24 -0800 (PST) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f26BRFC52507; Tue, 6 Mar 2001 11:27:15 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Tue, 6 Mar 2001 11:27:15 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: "Andy [TECC NOPS]" Cc: Alfred Perlstein , freebsd-net@FreeBSD.ORG Subject: RE: - TFTP: Time out - 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 I precise that I can download file from Router to my FreeBSD machine and not from my FreeBSD machine to the Cisco router. TFTP Methode: --- Router#copy tftp flash Address or name of remote host [x.x.x.48]? Source filename [tftpboot/c3640-i-mz.120-7.XK1.bin]? Destination filename [c3640-i-mz.120-7.XK1.bin]? Accessing tftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin... %Error opening tftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin (Timed out) Router# --- FTP Methode: --- Router#copy ftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin flash: Destination filename [c3640-i-mz.120-7.XK1.bin]? Accessing ftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin... %Error opening ftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin (Protocol error) Router# --- This is the sample of /etc/inetd.conf: --- ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l #telnet stream tcp nowait root /usr/libexec/telnetd telnetd #shell stream tcp nowait root /usr/libexec/rshd rshd #login stream tcp nowait root /usr/libexec/rlogind rlogind #finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s #exec stream tcp nowait root /usr/libexec/rexecd rexecd #uucpd stream tcp nowait root /usr/libexec/uucpd uucpd #nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd # run comsat as root to be able to print partial mailbox contents w/ biff, # or use the safer tty:tty to just print that new mail has been received. #comsat dgram udp wait tty:tty /usr/libexec/comsat comsat #ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot #bootps dgram udp wait root /usr/libexec/bootpd bootpd --- where: --- %cd / %ls -l ... drwxr-xr-x 2 nobody nobody 512 Mar 5 18:37 tftpboot ... --- Regards, Jean-Christophe. On Tue, 6 Mar 2001, Andy [TECC NOPS] wrote: > I always had these kinda problems both with > FreeBSD, Linux, etc etc. Found various ways > around them in the end but the best way is if > you are running a version of IOS 12.0 or later > on the Cisco then use the newer copy commands > in IOS that allow ftp eg:- > > router> copy ftp://user:pass@box.whatever/config.cond startup-config > > much better than :- > > router> copy tftp startup-config > > Regards > Andy > > > -----Original Message----- > > From: owner-freebsd-net@FreeBSD.ORG > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Alfred Perlstein > > Sent: 05 March 2001 18:23 > > To: Jean-Christophe Varaillon > > Cc: freebsd-net@FreeBSD.ORG > > Subject: Re: - TFTP: Time out - > > > > > > * Jean-Christophe Varaillon [010305 10:17] wrote: > > > > > > +-----------+ +------------+ > > > |FreeBSD 4.1|<--------->| Cisco 3640 | > > > +-----------+ +------------+ > > > > > > I want to transfer a file from the FreeBSD machine to the Cisco. > > > My machine is configured as a TFTP server and the cisco is "configured" > > > as a client. > > > > > > The TFTP communication is stopped because of a timeout. > > > > > > Why should I have a timeout ? > > > > Because afaik tftp has a really terrible client/server notion, > > there's no good way to tell if a client has 'gone away'. Without > > the timeout, if a client was to disappear the tftpd server would > > hang around forever. > > > > > BUT, I can transfer a files from the Cisco to my machine witout any > > > trouble. at this moment, the cisco is configured as a TFTP > > Server, and I > > > think that my machine also, but it reacts as a client. > > > > You should probably be able to fix this by changing the value of > > "TIMEOUT" in /usr/src/libexec/tftpd/tftpd.c, then doing this in > > /usr/src/libexec/tftpd: > > > > make ; make install > > > > -- > > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 3:35:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id 6576D37B719 for ; Tue, 6 Mar 2001 03:35:24 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14aFkQ-0006ez-00; Tue, 6 Mar 2001 11:35:22 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aFiQ-0004Di-00; Tue, 6 Mar 2001 11:33:18 +0000 From: "Andy [TECC NOPS]" To: "Jean-Christophe Varaillon" Cc: "Alfred Perlstein" , Subject: RE: - TFTP: Time out - Date: Tue, 6 Mar 2001 11:39:45 -0000 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > TFTP Methode: > --- Dunno about the tftp operation, could be a number of things. Try looking in /var/log/messages for ftpd[xx] error messages. > > FTP Methode: > --- > Router#copy ftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin flash: > Destination filename [c3640-i-mz.120-7.XK1.bin]? > Accessing ftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin... > %Error opening ftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin > (Protocol error) > Router# > --- here, you are missing the username:passwd combination. If you have a local account on the box, say "jean" then try copying the bin flash image to your local account:- freebsd$ cp /tftpboot/c3640-i-mz.120-7.XK1.bin ~jean/ Then, on the cisco do :- router> copy ftp://jean:xxxx@x.x.x.48/c3640-i-mz.120-7.XK1.bin flash: where you put your local account passwd after ftp://jean: Regards Andy > > This is the sample of /etc/inetd.conf: > --- > ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l > #telnet stream tcp nowait root /usr/libexec/telnetd telnetd > #shell stream tcp nowait root /usr/libexec/rshd rshd > #login stream tcp nowait root /usr/libexec/rlogind rlogind > #finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s > #exec stream tcp nowait root /usr/libexec/rexecd rexecd > #uucpd stream tcp nowait root /usr/libexec/uucpd uucpd > #nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd > # run comsat as root to be able to print partial mailbox contents w/ biff, > # or use the safer tty:tty to just print that new mail has been received. > #comsat dgram udp wait tty:tty /usr/libexec/comsat comsat > #ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l > -s /tftpboot > #bootps dgram udp wait root /usr/libexec/bootpd bootpd > --- > > where: > --- > %cd / > %ls -l > ... > drwxr-xr-x 2 nobody nobody 512 Mar 5 18:37 tftpboot > ... > --- > > > Regards, > Jean-Christophe. > > On Tue, 6 Mar 2001, Andy [TECC NOPS] wrote: > > > I always had these kinda problems both with > > FreeBSD, Linux, etc etc. Found various ways > > around them in the end but the best way is if > > you are running a version of IOS 12.0 or later > > on the Cisco then use the newer copy commands > > in IOS that allow ftp eg:- > > > > router> copy ftp://user:pass@box.whatever/config.cond startup-config > > > > much better than :- > > > > router> copy tftp startup-config > > > > Regards > > Andy > > > > > -----Original Message----- > > > From: owner-freebsd-net@FreeBSD.ORG > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Alfred Perlstein > > > Sent: 05 March 2001 18:23 > > > To: Jean-Christophe Varaillon > > > Cc: freebsd-net@FreeBSD.ORG > > > Subject: Re: - TFTP: Time out - > > > > > > > > > * Jean-Christophe Varaillon [010305 10:17] wrote: > > > > > > > > +-----------+ +------------+ > > > > |FreeBSD 4.1|<--------->| Cisco 3640 | > > > > +-----------+ +------------+ > > > > > > > > I want to transfer a file from the FreeBSD machine to the Cisco. > > > > My machine is configured as a TFTP server and the cisco is > "configured" > > > > as a client. > > > > > > > > The TFTP communication is stopped because of a timeout. > > > > > > > > Why should I have a timeout ? > > > > > > Because afaik tftp has a really terrible client/server notion, > > > there's no good way to tell if a client has 'gone away'. Without > > > the timeout, if a client was to disappear the tftpd server would > > > hang around forever. > > > > > > > BUT, I can transfer a files from the Cisco to my machine witout any > > > > trouble. at this moment, the cisco is configured as a TFTP > > > Server, and I > > > > think that my machine also, but it reacts as a client. > > > > > > You should probably be able to fix this by changing the value of > > > "TIMEOUT" in /usr/src/libexec/tftpd/tftpd.c, then doing this in > > > /usr/src/libexec/tftpd: > > > > > > make ; make install > > > > > > -- > > > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 3:37:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id 5884437B719 for ; Tue, 6 Mar 2001 03:37:26 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14aFmO-0006ft-00; Tue, 6 Mar 2001 11:37:24 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aFkN-0004E2-00; Tue, 6 Mar 2001 11:35:19 +0000 From: "Andy [TECC NOPS]" To: "Andy [TECC NOPS]" , "Jean-Christophe Varaillon" Cc: "Alfred Perlstein" , Subject: RE: - TFTP: Time out - Date: Tue, 6 Mar 2001 11:41:47 -0000 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org doh! > Try looking in /var/log/messages for ftpd[xx] error messages. should be tftpd[xx] error messages. Should look before I type! Ak To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 4:18:29 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id A098537B718 for ; Tue, 6 Mar 2001 04:18:22 -0800 (PST) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f26CILK53028 for ; Tue, 6 Mar 2001 12:18:21 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Tue, 6 Mar 2001 12:18:20 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: freebsd-net@FreeBSD.ORG Subject: RE: - TFTP: Time out - 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 In in /var/log/messages I have: Concerning the FTP Methode: --- Mar 6 11:22:35 homer ftpd[20832]: ANONYMOUS FTP LOGIN REFUSED FROM Mar 6 11:51:47 homer ftpd[21090]: FTP LOGIN FAILED FROM , Jean --- Concerning the TFTP Methode: --- Mar 6 11:54:17 homer tftpd[21105]: read: Connection refused Mar 6 11:54:21 homer tftpd[21107]: read: Connection refused Mar 6 11:54:26 homer tftpd[21109]: read: Connection refused --- So, finally I have a time out which stop my tftp communication because the file I want to download cannot be read. Question of access ? If so, why even with that it is not working properly: -- %cd / %ls -l ... drwxr-xr-x 2 nobody nobody 512 Mar 5 18:37 c3640-i-mz.120-7.XK1.bin ... --- ------- Jean-Christophe VARAILLON Network Engineer VBCnet GB Ltd Tel:44 (0) 117 929 1316 Fax:44 (0) 117 927 2015 On Tue, 6 Mar 2001, Andy [TECC NOPS] wrote: > > TFTP Methode: > > --- > > > > Dunno about the tftp operation, could be a number of things. > Try looking in /var/log/messages for ftpd[xx] error messages. > > > > > FTP Methode: > > --- > > Router#copy ftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin flash: > > Destination filename [c3640-i-mz.120-7.XK1.bin]? > > Accessing ftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin... > > %Error opening ftp://x.x.x.48/tftpboot/c3640-i-mz.120-7.XK1.bin > > (Protocol error) > > Router# > > --- > > here, you are missing the username:passwd combination. If you have > a local account on the box, say "jean" then try copying the bin > flash image to your local account:- > > freebsd$ cp /tftpboot/c3640-i-mz.120-7.XK1.bin ~jean/ > > Then, on the cisco do :- > > router> copy ftp://jean:xxxx@x.x.x.48/c3640-i-mz.120-7.XK1.bin flash: > > where you put your local account passwd after ftp://jean: > > Regards > Andy > > > > > This is the sample of /etc/inetd.conf: > > --- > > ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l > > #telnet stream tcp nowait root /usr/libexec/telnetd telnetd > > #shell stream tcp nowait root /usr/libexec/rshd rshd > > #login stream tcp nowait root /usr/libexec/rlogind rlogind > > #finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s > > #exec stream tcp nowait root /usr/libexec/rexecd rexecd > > #uucpd stream tcp nowait root /usr/libexec/uucpd uucpd > > #nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd > > # run comsat as root to be able to print partial mailbox contents w/ biff, > > # or use the safer tty:tty to just print that new mail has been received. > > #comsat dgram udp wait tty:tty /usr/libexec/comsat comsat > > #ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd > > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l > > -s /tftpboot > > #bootps dgram udp wait root /usr/libexec/bootpd bootpd > > --- > > > > where: > > --- > > %cd / > > %ls -l > > ... > > drwxr-xr-x 2 nobody nobody 512 Mar 5 18:37 tftpboot > > ... > > --- > > > > > > Regards, > > Jean-Christophe. > > > > On Tue, 6 Mar 2001, Andy [TECC NOPS] wrote: > > > > > I always had these kinda problems both with > > > FreeBSD, Linux, etc etc. Found various ways > > > around them in the end but the best way is if > > > you are running a version of IOS 12.0 or later > > > on the Cisco then use the newer copy commands > > > in IOS that allow ftp eg:- > > > > > > router> copy ftp://user:pass@box.whatever/config.cond startup-config > > > > > > much better than :- > > > > > > router> copy tftp startup-config > > > > > > Regards > > > Andy > > > > > > > -----Original Message----- > > > > From: owner-freebsd-net@FreeBSD.ORG > > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Alfred Perlstein > > > > Sent: 05 March 2001 18:23 > > > > To: Jean-Christophe Varaillon > > > > Cc: freebsd-net@FreeBSD.ORG > > > > Subject: Re: - TFTP: Time out - > > > > > > > > > > > > * Jean-Christophe Varaillon [010305 10:17] wrote: > > > > > > > > > > +-----------+ +------------+ > > > > > |FreeBSD 4.1|<--------->| Cisco 3640 | > > > > > +-----------+ +------------+ > > > > > > > > > > I want to transfer a file from the FreeBSD machine to the Cisco. > > > > > My machine is configured as a TFTP server and the cisco is > > "configured" > > > > > as a client. > > > > > > > > > > The TFTP communication is stopped because of a timeout. > > > > > > > > > > Why should I have a timeout ? > > > > > > > > Because afaik tftp has a really terrible client/server notion, > > > > there's no good way to tell if a client has 'gone away'. Without > > > > the timeout, if a client was to disappear the tftpd server would > > > > hang around forever. > > > > > > > > > BUT, I can transfer a files from the Cisco to my machine witout any > > > > > trouble. at this moment, the cisco is configured as a TFTP > > > > Server, and I > > > > > think that my machine also, but it reacts as a client. > > > > > > > > You should probably be able to fix this by changing the value of > > > > "TIMEOUT" in /usr/src/libexec/tftpd/tftpd.c, then doing this in > > > > /usr/src/libexec/tftpd: > > > > > > > > make ; make install > > > > > > > > -- > > > > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 4:23:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id 6E33437B718 for ; Tue, 6 Mar 2001 04:23:31 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14aGV0-0006w4-00; Tue, 6 Mar 2001 12:23:30 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aGSz-0004SM-00; Tue, 6 Mar 2001 12:21:25 +0000 From: "Andy [TECC NOPS]" To: "Jean-Christophe Varaillon" , Subject: RE: - TFTP: Time out - Date: Tue, 6 Mar 2001 12:27:53 -0000 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In in /var/log/messages I have: > > Concerning the FTP Methode: > --- > Mar 6 11:22:35 homer ftpd[20832]: ANONYMOUS FTP LOGIN REFUSED FROM > > Mar 6 11:51:47 homer ftpd[21090]: FTP LOGIN FAILED FROM > , Jean > --- you are missing the portion ftp://user:passwd@host...... and putting in ftp://host.... so the cisco is trying to use anon ftp. You should use a real account as per my last email! > Concerning the TFTP Methode: > --- > Mar 6 11:54:17 homer tftpd[21105]: read: Connection refused > Mar 6 11:54:21 homer tftpd[21107]: read: Connection refused > Mar 6 11:54:26 homer tftpd[21109]: read: Connection refused > --- > > So, finally I have a time out which stop my tftp communication because the > file I want to download cannot be read. Question of access ? > If so, why even with that it is not working properly: > -- > %cd / > %ls -l > ... > drwxr-xr-x 2 nobody nobody 512 Mar 5 18:37 c3640-i-mz.120-7.XK1.bin err, what's this! You've done a %cd / and then ls -l produces that?! Surely you've done %cd /tftpboot; ls -l haven't you????? And why is the file name appearing to be a directory?? tftp will produce a "read" error if the file does not exist which according to what you just wrote appears to be the case. Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 4:23:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from pinus.tt.luth.se (pinus.tt.luth.se [130.240.136.128]) by hub.freebsd.org (Postfix) with ESMTP id 0607837B718; Tue, 6 Mar 2001 04:23:49 -0800 (PST) (envelope-from solo@tt.luth.se) Received: from toffe2.tt.luth.se (toffe2.tt.luth.se [130.240.136.217]) by pinus.tt.luth.se (8.8.8/8.8.8) with SMTP id NAA08621; Tue, 6 Mar 2001 13:27:29 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: solo Reply-To: solo@tt.luth.se Organization: LTU To: questions@freebsd.org Subject: Bug in libsock++ ? Date: Tue, 6 Mar 2001 13:25:10 +0000 X-Mailer: KMail [version 1.2] Cc: net@freebsd.org MIME-Version: 1.0 Message-Id: <01030613251009.06484@toffe2.tt.luth.se> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm wondering if anyone have used libsocket 1.10 ? I've got a problem it looks like this: --- snip --- sockinetbuf si(sockbuf::sock_stream); cout << "bind: " << si.bind("127.0.0.1",5150) << endl; --- snip --- The problem is that bind is returning: EADDRNOTAVAIL Host is set correctly, but port is set to 0. If I use bind() it works! I've discovered the bug(?) in the constructor of socketinetaddr the sockaddr_in is not "zeroed", so bind fails. I've "patched" (?) the source file so it uses ::bzero((void*)(sock_addr_in*)this, sizeof(sockaddr_in)); in the constructor. Q1) Is this a bug? Q2) If it is a bug? Q2.1) How do I submit the source and to whom (is it neccesary)? Q2.2) Since this is rather obvious? Aren't thery any using this lib, and what should (I) use instead (some suggestions of a object oriented socket framework? please :-)? Many Regards and Thanks in Advance Mario Toffia mario.toffia@tt.luth.se (please cc: mario.toffia@telia.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 6 4:24:18 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 9A13C37B719 for ; Tue, 6 Mar 2001 04:24:15 -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) with ESMTP id VAA11356; Tue, 6 Mar 2001 21:20:25 +0900 (JST) To: John Hay Cc: bmilekic@technokratis.com (Bosko Milekic), freebsd-net@FreeBSD.ORG In-reply-to: jhay's message of Sat, 06 Mar 2001 07:59:58 +0200. <200103060559.f265xwP47418@zibbi.icomtek.csir.co.za> 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: kernel: nd6_storelladdr failed, mbuf leak From: itojun@iijlab.net Date: Tue, 06 Mar 2001 21:20:25 +0900 Message-ID: <11354.983881225@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> > > I then noticed that "... kernel: nd6_storelladdr failed" gets logged >> > > often and after a while all mbufs are used. It turned out that in >> > > sys/net/if_ethersubr.c in ether_output() when nd6_storelladdr() >> > fails, >> > > it does a return(0) and does not free the mbuf. I checked -current >> > > and it is still like that. will correct it. thanks for reporting. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 4:46:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id 3848B37B71A for ; Tue, 6 Mar 2001 04:46:39 -0800 (PST) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f26CkbD53305; Tue, 6 Mar 2001 12:46:37 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Tue, 6 Mar 2001 12:46:37 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: "Andy [TECC NOPS]" Cc: freebsd-net@FreeBSD.ORG Subject: RE: - TFTP: Time out - 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, 6 Mar 2001, Andy [TECC NOPS] wrote: > > In in /var/log/messages I have: > > > > Concerning the FTP Methode: > > --- > > Mar 6 11:22:35 homer ftpd[20832]: ANONYMOUS FTP LOGIN REFUSED FROM > > > > Mar 6 11:51:47 homer ftpd[21090]: FTP LOGIN FAILED FROM > > , Jean > > --- > > you are missing the portion ftp://user:passwd@host...... and > putting in ftp://host.... so the cisco is trying to use anon > ftp. You should use a real account as per my last email! I followed your e-mail: --- Router#conf t Router(config)#ip ftp username Jean Router(config)#ip ftp password poty89 Router(config)#end 19:16:29: %SYS-5-CONFIG_I: Configured from console by console Router#copy ftp://Jean:poty89@x.x.x.48/c3640-i-mz.120-7.XK1.bin flash: Destination filename [c3640-i-mz.120-7.XK1.bin]? Accessing ftp://Jean:poty89@x.x.x.48/c3640-i-mz.120-7.XK1.bin... %Error opening ftp://Jean:poty89@x.x.x.48/c3640-i-mz.120-7.XK1.bin (Protocol error) Router# --- In /var/log/messages I have: --- Mar 6 12:44:21 homer ftpd[21484]: FTP LOGIN FAILED FROM , Jean --- > > Concerning the TFTP Methode: > > --- > > Mar 6 11:54:17 homer tftpd[21105]: read: Connection refused > > Mar 6 11:54:21 homer tftpd[21107]: read: Connection refused > > Mar 6 11:54:26 homer tftpd[21109]: read: Connection refused > > --- > > > > So, finally I have a time out which stop my tftp communication because the > > file I want to download cannot be read. Question of access ? > > If so, why even with that it is not working properly: > > -- > > %cd / > > %ls -l > > ... > > drwxr-xr-x 2 nobody nobody 512 Mar 5 18:37 c3640-i-mz.120-7.XK1.bin > > err, what's this! You've done a %cd / and then ls -l produces that?! > Surely you've done %cd /tftpboot; ls -l haven't you????? And why is > the file name appearing to be a directory?? oups, mistake. Never c3640-i-mz.120-7.XK1.bin has been a directory. This is the way it was and it is: %cd / %ls -l total 15122 -rw-r--r-- 1 jcv jcv 0 Feb 26 14:10 ARCHIVE -rw-r--r-- 1 jcv jcv 1166 Nov 29 12:33 BGP -r--r--r-- 1 root wheel 4735 Jul 28 2000 COPYRIGHT -rw-r--r-- 1 jcv jcv 898 Mar 2 17:53 HowTo drwxr-xr-x 3 root wheel 512 Dec 4 14:23 RISCom -rw-r--r-- 1 jcv jcv 1580 Nov 6 15:54 VoIP -rw-r--r-- 1 jcv jcv 1004667 Sep 7 10:36 Zebra drwxr-xr-x 2 root wheel 1024 Aug 22 2000 bin drwxr-xr-x 3 root wheel 512 Aug 22 2000 boot -rw-r--r-- 1 nobody nobody 4991380 Mar 5 16:56 c3640-i-mz.120-7.XK1.bin .... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 4:48:57 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 6AA5737B718 for ; Tue, 6 Mar 2001 04:48:44 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f26CkWO56746; Tue, 6 Mar 2001 14:46:32 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200103061246.f26CkWO56746@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak In-Reply-To: <11354.983881225@coconut.itojun.org> from "itojun@iijlab.net" at "Mar 6, 2001 09:20:25 pm" To: itojun@iijlab.net Date: Tue, 6 Mar 2001 14:46:32 +0200 (SAT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > >> > > I then noticed that "... kernel: nd6_storelladdr failed" gets logged > >> > > often and after a while all mbufs are used. It turned out that in > >> > > sys/net/if_ethersubr.c in ether_output() when nd6_storelladdr() > >> > fails, > >> > > it does a return(0) and does not free the mbuf. I checked -current > >> > > and it is still like that. > > will correct it. thanks for reporting. > > itojun Great, thanks. Now I have a second question. What should be done about the interaction between if_ef(4) and nd6_storelladdr()? Should a IFT_XETHER be added to the case statement in nd6_storelladdr() or should if_ef(4) not try to do ipv6? John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 4:52:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id C775337B719 for ; Tue, 6 Mar 2001 04:52:38 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14aGxB-0007AW-00; Tue, 6 Mar 2001 12:52:37 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aGvB-0004au-00; Tue, 6 Mar 2001 12:50:33 +0000 From: "Andy [TECC NOPS]" To: "Jean-Christophe Varaillon" Cc: Subject: RE: - TFTP: Time out - Date: Tue, 6 Mar 2001 12:57:01 -0000 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > you are missing the portion ftp://user:passwd@host...... and > > putting in ftp://host.... so the cisco is trying to use anon > > ftp. You should use a real account as per my last email! > > I followed your e-mail: > --- > Router#conf t > Router(config)#ip ftp username Jean > Router(config)#ip ftp password poty89 > Router(config)#end > 19:16:29: %SYS-5-CONFIG_I: Configured from console by console > Router#copy ftp://Jean:poty89@x.x.x.48/c3640-i-mz.120-7.XK1.bin flash: > Destination filename [c3640-i-mz.120-7.XK1.bin]? > Accessing ftp://Jean:poty89@x.x.x.48/c3640-i-mz.120-7.XK1.bin... > %Error opening ftp://Jean:poty89@x.x.x.48/c3640-i-mz.120-7.XK1.bin > (Protocol error) > Router# err, no you didn't, I meant an account on your freebsd box, not the cisco. That snippet above created an acct on the cisco. > > > Concerning the TFTP Methode: > oups, mistake. > Never c3640-i-mz.120-7.XK1.bin has been a directory. > This is the way it was and it is: > %cd / > %ls -l > total 15122 > -rw-r--r-- 1 jcv jcv 0 Feb 26 14:10 ARCHIVE > -rw-r--r-- 1 jcv jcv 1166 Nov 29 12:33 BGP > -r--r--r-- 1 root wheel 4735 Jul 28 2000 COPYRIGHT > -rw-r--r-- 1 jcv jcv 898 Mar 2 17:53 HowTo > drwxr-xr-x 3 root wheel 512 Dec 4 14:23 RISCom > -rw-r--r-- 1 jcv jcv 1580 Nov 6 15:54 VoIP > -rw-r--r-- 1 jcv jcv 1004667 Sep 7 10:36 Zebra > drwxr-xr-x 2 root wheel 1024 Aug 22 2000 bin > drwxr-xr-x 3 root wheel 512 Aug 22 2000 boot > -rw-r--r-- 1 nobody nobody 4991380 Mar 5 16:56 > c3640-i-mz.120-7.XK1.bin > .... right, so where is the directory /tftpboot in the "ls -l" listing? The file c3640.... should then be in that directory. try this:- %cd /tmp %tftp localhost tftp> get c3640-i-mz.120-7.XK1.bin Received x bytes in 0.0 seconds tftp> quit % If you don't get that message, your local freebsd setup is at fault. Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 5: 9: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id 87B2137B718 for ; Tue, 6 Mar 2001 05:09:02 -0800 (PST) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f26D91g53585; Tue, 6 Mar 2001 13:09:01 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Tue, 6 Mar 2001 13:09:01 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: "Andy [TECC NOPS]" Cc: freebsd-net@FreeBSD.ORG Subject: RE: - TFTP: Time out - 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 > try this:- > > %cd /tmp > %tftp localhost > tftp> get c3640-i-mz.120-7.XK1.bin > Received x bytes in 0.0 seconds > tftp> quit > % > > If you don't get that message, your local freebsd setup > is at fault. > Here is the trouble. --- tftp> status Connected to localhost. Mode: netascii Verbose: off Tracing: off Rexmt-interval: 5 seconds, Max-timeout: 25 seconds tftp> get c3640-i-mz.120-7.XK1.bin Transfer timed out. tftp> status Connected to localhost. Mode: netascii Verbose: off Tracing: off Rexmt-interval: 5 seconds, Max-timeout: 25 seconds tftp> get tftpboot/c3640-i-mz.120-7.XK1.bin Transfer timed out. tftp> --- Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 5:10:21 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id 978FA37B718 for ; Tue, 6 Mar 2001 05:10:17 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14aHEG-0007G9-00; Tue, 6 Mar 2001 13:10:16 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aHCF-0004eg-00; Tue, 6 Mar 2001 13:08:11 +0000 From: "Andy [TECC NOPS]" To: "Jean-Christophe Varaillon" Cc: Subject: RE: - TFTP: Time out - Date: Tue, 6 Mar 2001 13:14:40 -0000 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ok, show me the results of this:- %ls -l /tftpboot/c3640-i-mz.120-7.XK1.bin Andy > -----Original Message----- > From: Jean-Christophe Varaillon [mailto:jcv@vbc.net] > Sent: 06 March 2001 13:09 > To: Andy [TECC NOPS] > Cc: freebsd-net@FreeBSD.ORG > Subject: RE: - TFTP: Time out - > > > > try this:- > > > > %cd /tmp > > %tftp localhost > > tftp> get c3640-i-mz.120-7.XK1.bin > > Received x bytes in 0.0 seconds > > tftp> quit > > % > > > > If you don't get that message, your local freebsd setup > > is at fault. > > > > Here is the trouble. > > --- > tftp> status > Connected to localhost. > Mode: netascii Verbose: off Tracing: off > Rexmt-interval: 5 seconds, Max-timeout: 25 seconds > tftp> get c3640-i-mz.120-7.XK1.bin > Transfer timed out. > > tftp> status > Connected to localhost. > Mode: netascii Verbose: off Tracing: off > Rexmt-interval: 5 seconds, Max-timeout: 25 seconds > tftp> get tftpboot/c3640-i-mz.120-7.XK1.bin > Transfer timed out. > > tftp> > --- > > Thanks. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 5:14:24 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id 8222237B719 for ; Tue, 6 Mar 2001 05:14:20 -0800 (PST) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f26DEJV53648; Tue, 6 Mar 2001 13:14:19 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Tue, 6 Mar 2001 13:14:19 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: "Andy [TECC NOPS]" Cc: freebsd-net@FreeBSD.ORG Subject: RE: - TFTP: Time out - 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 % ls -l /tftpboot/c3640-i-mz.120-7.XK1.bin -rw-r--r-- 1 nobody nobody 4991380 Mar 5 16:47 /tftpboot/c3640-i-mz.120-7.XK1.bin % On Tue, 6 Mar 2001, Andy [TECC NOPS] wrote: > ok, show me the results of this:- > > %ls -l /tftpboot/c3640-i-mz.120-7.XK1.bin > > Andy > > > -----Original Message----- > > From: Jean-Christophe Varaillon [mailto:jcv@vbc.net] > > Sent: 06 March 2001 13:09 > > To: Andy [TECC NOPS] > > Cc: freebsd-net@FreeBSD.ORG > > Subject: RE: - TFTP: Time out - > > > > > > > try this:- > > > > > > %cd /tmp > > > %tftp localhost > > > tftp> get c3640-i-mz.120-7.XK1.bin > > > Received x bytes in 0.0 seconds > > > tftp> quit > > > % > > > > > > If you don't get that message, your local freebsd setup > > > is at fault. > > > > > > > Here is the trouble. > > > > --- > > tftp> status > > Connected to localhost. > > Mode: netascii Verbose: off Tracing: off > > Rexmt-interval: 5 seconds, Max-timeout: 25 seconds > > tftp> get c3640-i-mz.120-7.XK1.bin > > Transfer timed out. > > > > tftp> status > > Connected to localhost. > > Mode: netascii Verbose: off Tracing: off > > Rexmt-interval: 5 seconds, Max-timeout: 25 seconds > > tftp> get tftpboot/c3640-i-mz.120-7.XK1.bin > > Transfer timed out. > > > > tftp> > > --- > > > > Thanks. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 7:26:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from bilver.wjv.com (dhcp-1-219.n01.orldfl01.us.ra.verio.net [157.238.210.219]) by hub.freebsd.org (Postfix) with ESMTP id 44F5237B737 for ; Tue, 6 Mar 2001 07:26:16 -0800 (PST) (envelope-from bill@bilver.wjv.com) Received: (from bill@localhost) by bilver.wjv.com (8.9.3/8.9.3) id KAA48533 for freebsd-net@freebsd.org; Tue, 6 Mar 2001 10:26:14 -0500 (EST) (envelope-from bill) Date: Tue, 6 Mar 2001 10:26:02 -0500 From: Bill Vermillion To: freebsd-net@freebsd.org Subject: Re: - TFTP: Time out - Message-ID: <20010306102602.A48426@wjv.com> Reply-To: bv@bilver.wjv.com 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 jcv@vbc.net on Tue, Mar 06, 2001 at 01:14:19PM +0000 Organization: W.J.Vermillion / Orlando - Winter Park Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Mar 06, 2001 at 01:14:19PM +0000, Jean-Christophe Varaillon thus spoke: > % ls -l /tftpboot/c3640-i-mz.120-7.XK1.bin > -rw-r--r-- 1 nobody nobody 4991380 Mar 5 16:47 > /tftpboot/c3640-i-mz.120-7.XK1.bin > % But in the / listing there was no directory of /tftpboot. That concerns me. The permission on the /tftpboot directory must be world readable as well as the file. We also need to be sure of his inetd.conf file to see that the /tftpboot is the directory specified. We aren't even sure if that is enabled are we? Just some thoughts. Bill -- Bill Vermillion - bv @ wjv . 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 6 7:28:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id CDB4537B71A for ; Tue, 6 Mar 2001 07:28:31 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14aJNu-0000XM-00; Tue, 6 Mar 2001 15:28:22 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aJLt-0005Nd-00; Tue, 6 Mar 2001 15:26:17 +0000 From: "Andy [TECC NOPS]" To: , Subject: RE: - TFTP: Time out - Date: Tue, 6 Mar 2001 15:32:48 -0000 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20010306102602.A48426@wjv.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Bill, just spent some time on this with him. The directory listing was a typo. I just asked him for the directory and file perms. I have his inetd.conf and it looks fine. Cheers Andy > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Bill Vermillion > Sent: 06 March 2001 15:26 > To: freebsd-net@freebsd.org > Subject: Re: - TFTP: Time out - > > > On Tue, Mar 06, 2001 at 01:14:19PM +0000, Jean-Christophe > Varaillon thus spoke: > > > % ls -l /tftpboot/c3640-i-mz.120-7.XK1.bin > > -rw-r--r-- 1 nobody nobody 4991380 Mar 5 16:47 > > /tftpboot/c3640-i-mz.120-7.XK1.bin > > % > > But in the / listing there was no directory of /tftpboot. > > That concerns me. The permission on the /tftpboot directory > must be world readable as well as the file. > > We also need to be sure of his inetd.conf file to see that > the /tftpboot is the directory specified. We aren't even sure > if that is enabled are we? > > Just some thoughts. > > Bill > > -- > Bill Vermillion - bv @ wjv . com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 8:37:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id 690A537B718 for ; Tue, 6 Mar 2001 08:37:07 -0800 (PST) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f26Gb5x56171; Tue, 6 Mar 2001 16:37:05 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Tue, 6 Mar 2001 16:37:05 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: "Andy [TECC NOPS]" Cc: freebsd-net@FreeBSD.ORG Subject: RE: - TFTP: Time out - 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 It is still not working between my machine and the cisco #( So, let summurize what I should fixe: === Make my FreeBSD machine as a tftp server === vi /etc/inetd.conf: -- tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /usr/home/jcv -- -- homer# ps auwx | grep inetd root 108 0.0 0.5 1044 604 ?? Is 27Feb01 0:00.19 inetd -wW jcv 23629 0.0 0.9 1548 1136 pc I+ 4:15PM 0:00.02 vi /etc/inetd.conf homer# kill -HUP 108 -- I can see that the server is actually listening: -- %netstat -a | grep tftp udp4 0 0 *.tftp *.* % -- ===== TFTP LOCALHOST TEST ===== %su Password: homer# cd /tftpboot homer# ls -l total 8544 -rw-r--r-- 1 nobody nobody 4991380 Mar 6 15:39 c3640-i-mz.120-7.XK1.bin -rw-r--r-- 1 nobody nobody 3731009 Mar 6 15:03 c3640-i-mz.120-9.bin homer# cd /usr/home/jcv homer# ls -l c3640-i-mz.120-9.bin -rw-r--r-- 1 nobody nobody 0 Mar 6 16:03 c3640-i-mz.120-9.bin homer# tftp 127.0.0.1 tftp> status Connected to 127.0.0.1. Mode: netascii Verbose: off Tracing: off Rexmt-interval: 5 seconds, Max-timeout: 25 seconds tftp> get /tftpboot/c3640-i-mz.120-9.bin Transfer timed out. tftp> quit homer#vi /var/log/messages ... Mar 6 16:29:03 homer tftpd[23756]: read: Connection refused Mar 6 16:29:08 homer tftpd[23758]: read: Connection refused ================================= Oh by the way, when you make your IOS upgrade form your tftp server to your router, you don't have to creat a blank file in flash ? Regards, Jean-Christophe. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 8:48: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id 9F8AE37B719 for ; Tue, 6 Mar 2001 08:48:02 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14aKcz-000164-00; Tue, 6 Mar 2001 16:48:01 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aKay-0005pE-00; Tue, 6 Mar 2001 16:45:56 +0000 From: "Andy [TECC NOPS]" To: "Jean-Christophe Varaillon" Cc: Subject: RE: - TFTP: Time out - Date: Tue, 6 Mar 2001 16:52:27 -0000 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK, from that all seems fine. But remeber that doing %tftp localhost and then trying a local get failed, so I suspect that there is something wrong with the local setup somewhere. Right, how come you have two lines beginning "tftp" in your /etc/inetd.conf ?? Thought there should be only one (the one ending -s /tftpboot). Big point here is that inetd is invoked -wW so it's wrapping. Check /etc/hosts.allow (or is it /usr/local/etc/hosts.allow these days? dunno, check up on it). Do a man inetd and check this yourself. Try doing %telnet localhost 69 and see if your daemon will even allow a connection. If none of these we'll try again Regards Andy > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Jean-Christophe > Varaillon > Sent: 06 March 2001 16:37 > To: Andy [TECC NOPS] > Cc: freebsd-net@FreeBSD.ORG > Subject: RE: - TFTP: Time out - > > > It is still not working between my machine and the cisco #( > > So, let summurize what I should fixe: > > === Make my FreeBSD machine as a tftp server === > > vi /etc/inetd.conf: > -- > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /usr/home/jcv > -- > > -- > homer# ps auwx | grep inetd > root 108 0.0 0.5 1044 604 ?? Is 27Feb01 0:00.19 inetd -wW > jcv 23629 0.0 0.9 1548 1136 pc I+ 4:15PM 0:00.02 vi > /etc/inetd.conf > homer# kill -HUP 108 > -- > > I can see that the server is actually listening: > -- > %netstat -a | grep tftp > udp4 0 0 *.tftp *.* > % > -- > > ===== TFTP LOCALHOST TEST ===== > %su > Password: > > homer# cd /tftpboot > homer# ls -l > total 8544 > -rw-r--r-- 1 nobody nobody 4991380 Mar 6 15:39 > c3640-i-mz.120-7.XK1.bin > -rw-r--r-- 1 nobody nobody 3731009 Mar 6 15:03 c3640-i-mz.120-9.bin > > homer# cd /usr/home/jcv > homer# ls -l c3640-i-mz.120-9.bin > -rw-r--r-- 1 nobody nobody 0 Mar 6 16:03 c3640-i-mz.120-9.bin > homer# tftp 127.0.0.1 > > tftp> status > Connected to 127.0.0.1. > Mode: netascii Verbose: off Tracing: off > Rexmt-interval: 5 seconds, Max-timeout: 25 seconds > tftp> get /tftpboot/c3640-i-mz.120-9.bin > Transfer timed out. > > tftp> quit > > homer#vi /var/log/messages > ... > Mar 6 16:29:03 homer tftpd[23756]: read: Connection refused > Mar 6 16:29:08 homer tftpd[23758]: read: Connection refused > > ================================= > > Oh by the way, when you make your IOS upgrade form your tftp server to > your router, you don't have to creat a blank file in flash ? > > > Regards, > Jean-Christophe. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 9: 9:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id AF76F37B719 for ; Tue, 6 Mar 2001 09:09:37 -0800 (PST) (envelope-from bmilekic@technokratis.com) Received: from jehovah ([24.202.203.190]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G9SCZ701.8VO; Tue, 6 Mar 2001 12:09:07 -0500 Message-ID: <005501c0a660$89fc2bd0$becbca18@jehovah> From: "Bosko Milekic" To: "John Hay" , Cc: References: <11354.983881225@coconut.itojun.org> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak Date: Tue, 6 Mar 2001 12:11:52 -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 itojun wrote: > > >> > > I then noticed that "... kernel: nd6_storelladdr failed" gets logged > >> > > often and after a while all mbufs are used. It turned out that in > >> > > sys/net/if_ethersubr.c in ether_output() when nd6_storelladdr() > >> > fails, > >> > > it does a return(0) and does not free the mbuf. I checked -current > >> > > and it is still like that. > > will correct it. thanks for reporting. > > itojun This behavior is absolutely horrible. What ought to be fixed, if ether_input() is supposed to be freeing the passed in mbuf, is that ether_input() should instead accept a pointer to a pointer so that after it frees the mbuf it can NULL out the initial pointer. Because of promoting similar existing coding practises in this area of the code, what we're seeing is ether_input() effectively returning an mbuf to the free list while the caller still holds a live pointer to that mbuf. Regards, Bosko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 9:50:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp.healthlink.on.ca (ns.uhealthnet.on.ca [205.211.160.10]) by hub.freebsd.org (Postfix) with ESMTP id B4E1037B71E for ; Tue, 6 Mar 2001 09:50:27 -0800 (PST) (envelope-from bsonne@mtsinai.on.ca) Received: from mshmail4.mtsinai.toronto.on.ca ([192.168.1.30]) by smtp.healthlink.on.ca (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id ca for ; Tue, 6 Mar 2001 12:52:51 -0500 Received: by mshmail4.mtsinai.toronto.on.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Mar 2001 12:50:19 -0500 Message-ID: From: "Sonne, Byron" To: "'freebsd-net@freebsd.org'" Subject: mpd errors when trying to connect using MS pptp client Date: Tue, 6 Mar 2001 12:50:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greetings all, When I try to connect to my FreeBSD 4.2 box (running mpd as a pptp server) using the Win2k pptp client, I get the following error "Disconnected. Error 619: The specified port is not connected". If I then look in my mpd.log, I see the following occur twice, here is one of them: Mar 6 12:43:33 cleric mpd: [pptp] LCP: SendConfigReq #21 Mar 6 12:43:33 cleric mpd: ACFCOMP Mar 6 12:43:33 cleric mpd: PROTOCOMP Mar 6 12:43:33 cleric mpd: MRU 1500 Mar 6 12:43:33 cleric mpd: MAGICNUM e76a24e1 Mar 6 12:43:33 cleric mpd: AUTHPROTO CHAP MSOFT Mar 6 12:43:33 cleric mpd: [pptp] error writing len 27 frame to bypass: No route to host Mar 6 12:43:33 cleric mpd: pptp0-0: ignoring SetLinkInfo Of major interest to me is the second last line that contains the "No route to host" comment. If they can start the handshake to the point where we can get an error, then it seems to me there has to be some kind of route. I thought perhaps my firewall rules were dropping a short packet generated in this exchange, but tweaking the rules didn't seem to make any difference (perhaps I didn't tweak them correctly ?) Can someone shed some more light on what this is trying to tell me? I'm hoping this will help point me in the right direction so I can figure out how to fix it. Regards, Byron Sonne To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 10: 3:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by hub.freebsd.org (Postfix) with ESMTP id 8EC7537B719 for ; Tue, 6 Mar 2001 10:03:27 -0800 (PST) (envelope-from barney@mx.databus.com) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f26I3ML68619; Tue, 6 Mar 2001 13:03:22 -0500 (EST) (envelope-from barney) Date: Tue, 6 Mar 2001 13:03:22 -0500 From: Barney Wolff To: "Sonne, Byron" Cc: "'freebsd-net@freebsd.org'" Subject: Re: mpd errors when trying to connect using MS pptp client Message-ID: <20010306130322.A68601@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from bsonne@mtsinai.on.ca on Tue, Mar 06, 2001 at 12:50:10PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can you ping the host you're talking to? The log lines describe options in a single LCP request being sent, which apparently cannot be sent because there is no route for the target IP addr. Barney Wolff On Tue, Mar 06, 2001 at 12:50:10PM -0500, Sonne, Byron wrote: > Greetings all, > > When I try to connect to my FreeBSD 4.2 box (running mpd as a pptp server) > using the Win2k pptp client, I get the following error "Disconnected. Error > 619: The specified port is not connected". > > If I then look in my mpd.log, I see the following occur twice, here is one > of them: > > Mar 6 12:43:33 cleric mpd: [pptp] LCP: SendConfigReq #21 > Mar 6 12:43:33 cleric mpd: ACFCOMP > Mar 6 12:43:33 cleric mpd: PROTOCOMP > Mar 6 12:43:33 cleric mpd: MRU 1500 > Mar 6 12:43:33 cleric mpd: MAGICNUM e76a24e1 > Mar 6 12:43:33 cleric mpd: AUTHPROTO CHAP MSOFT > Mar 6 12:43:33 cleric mpd: [pptp] error writing len 27 frame to bypass: No > route to host > Mar 6 12:43:33 cleric mpd: pptp0-0: ignoring SetLinkInfo > > Of major interest to me is the second last line that contains the "No route > to host" comment. If they can start the handshake to the point where we can > get an error, then it seems to me there has to be some kind of route. I > thought perhaps my firewall rules were dropping a short packet generated in > this exchange, but tweaking the rules didn't seem to make any difference > (perhaps I didn't tweak them correctly ?) > > Can someone shed some more light on what this is trying to tell me? I'm > hoping this will help point me in the right direction so I can figure out > how to fix it. > > Regards, > Byron Sonne > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 10:25:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 7823637B719 for ; Tue, 6 Mar 2001 10:25:12 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f26IN3064621; Tue, 6 Mar 2001 20:23:03 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200103061823.f26IN3064621@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak In-Reply-To: <005501c0a660$89fc2bd0$becbca18@jehovah> from Bosko Milekic at "Mar 6, 2001 12:11:52 pm" To: bmilekic@technokratis.com (Bosko Milekic) Date: Tue, 6 Mar 2001 20:23:03 +0200 (SAT) Cc: itojun@iijlab.net, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > >> > > I then noticed that "... kernel: nd6_storelladdr failed" gets > logged > > >> > > often and after a while all mbufs are used. It turned out > that in > > >> > > sys/net/if_ethersubr.c in ether_output() when > nd6_storelladdr() > > >> > fails, > > >> > > it does a return(0) and does not free the mbuf. I > checked -current > > >> > > and it is still like that. > > > > will correct it. thanks for reporting. > > > > itojun > > This behavior is absolutely horrible. What ought to be fixed, if > ether_input() is supposed to be freeing the passed in mbuf, is that > ether_input() should instead accept a pointer to a pointer so that > after it frees the mbuf it can NULL out the initial pointer. Because > of promoting similar existing coding practises in this area of the > code, what we're seeing is ether_input() effectively returning an mbuf > to the free list while the caller still holds a live pointer to that > mbuf. > Uhmm, we are talking about ether_output(), not ether_input(), but their behaviour is similar. I don't think any changes in the api is necessary. It has been like that from when I came in touch with 386bsd. You would need to change all the drivers and all the network stacks and also all the similar functions like fddi_input() and fddi_output(), etc. Both functions are called and handed a mbuf with the idea that it (ether_input() or ether_output()) should "send" it on as well as possible, normally it will be to add it to the correct interface or network stack queue. Any function calling ether_input() or ether_output() and expecting to be able to use that mbuf afterwards was written for a non BSD OS. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 10:56:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from brunel.uk1.vbc.net (brunel.uk1.vbc.net [194.207.2.8]) by hub.freebsd.org (Postfix) with ESMTP id 0977737B718 for ; Tue, 6 Mar 2001 10:56:37 -0800 (PST) (envelope-from jcv@vbc.net) Received: from localhost (jcv@localhost) by brunel.uk1.vbc.net (8.11.0/8.11.0) with ESMTP id f26IuYO57331; Tue, 6 Mar 2001 18:56:34 GMT X-Authentication-Warning: brunel.uk1.vbc.net: jcv owned process doing -bs Date: Tue, 6 Mar 2001 18:56:34 +0000 (GMT) From: Jean-Christophe Varaillon X-Sender: jcv@brunel.uk1.vbc.net To: "Andy [TECC NOPS]" Cc: freebsd-net@FreeBSD.ORG Subject: RE: - TFTP: Time out - 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, 6 Mar 2001, Andy [TECC NOPS] wrote: > OK, from that all seems fine. But remeber > that doing %tftp localhost and then trying > a local get failed, so I suspect that there > is something wrong with the local setup somewhere. > > Right, how come you have two lines beginning "tftp" > in your /etc/inetd.conf ?? Thought there should be > only one (the one ending -s /tftpboot). I uncommented the first line and I add another line to allow also an tftp access to /usr/home/jcv. > Big point here is that inetd is invoked -wW so it's > wrapping. Check /etc/hosts.allow (or is it > /usr/local/etc/hosts.allow > these days? dunno, check up on it). > Do a man inetd and check this yourself. -wW turn on TCP Wrapping. By "vi /etc/inted.conf" we can see that tftp is using UDP wrapping is used in a matter of security, no ? If yes, my router is , for the moment just close to my desk an it is not a remote router. > Try doing %telnet localhost 69 and see if your > daemon will even allow a connection. Even as a super user, the daemon does not allow the connection. --- %telnet localhost 69 Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused Trying ::1... telnet: connect to address ::1: Connection refused telnet: Unable to connect to remote host % --- > If none of these we'll try again > > Regards > Andy > > > > -----Original Message----- > > From: owner-freebsd-net@FreeBSD.ORG > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Jean-Christophe > > Varaillon > > Sent: 06 March 2001 16:37 > > To: Andy [TECC NOPS] > > Cc: freebsd-net@FreeBSD.ORG > > Subject: RE: - TFTP: Time out - > > > > > > It is still not working between my machine and the cisco #( > > > > So, let summurize what I should fixe: > > > > === Make my FreeBSD machine as a tftp server === > > > > vi /etc/inetd.conf: > > -- > > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot > > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /usr/home/jcv > > -- > > > > -- > > homer# ps auwx | grep inetd > > root 108 0.0 0.5 1044 604 ?? Is 27Feb01 0:00.19 inetd -wW > > jcv 23629 0.0 0.9 1548 1136 pc I+ 4:15PM 0:00.02 vi > > /etc/inetd.conf > > homer# kill -HUP 108 > > -- > > > > I can see that the server is actually listening: > > -- > > %netstat -a | grep tftp > > udp4 0 0 *.tftp *.* > > % > > -- > > > > ===== TFTP LOCALHOST TEST ===== > > %su > > Password: > > > > homer# cd /tftpboot > > homer# ls -l > > total 8544 > > -rw-r--r-- 1 nobody nobody 4991380 Mar 6 15:39 > > c3640-i-mz.120-7.XK1.bin > > -rw-r--r-- 1 nobody nobody 3731009 Mar 6 15:03 c3640-i-mz.120-9.bin > > > > homer# cd /usr/home/jcv > > homer# ls -l c3640-i-mz.120-9.bin > > -rw-r--r-- 1 nobody nobody 0 Mar 6 16:03 c3640-i-mz.120-9.bin > > homer# tftp 127.0.0.1 > > > > tftp> status > > Connected to 127.0.0.1. > > Mode: netascii Verbose: off Tracing: off > > Rexmt-interval: 5 seconds, Max-timeout: 25 seconds > > tftp> get /tftpboot/c3640-i-mz.120-9.bin > > Transfer timed out. > > > > tftp> quit > > > > homer#vi /var/log/messages > > ... > > Mar 6 16:29:03 homer tftpd[23756]: read: Connection refused > > Mar 6 16:29:08 homer tftpd[23758]: read: Connection refused > > > > ================================= > > > > Oh by the way, when you make your IOS upgrade form your tftp server to > > your router, you don't have to creat a blank file in flash ? > > > > > > Regards, > > Jean-Christophe. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 15:33: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 96E2737B719 for ; Tue, 6 Mar 2001 15:33:47 -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) with ESMTP id IAA18757; Wed, 7 Mar 2001 08:33:14 +0900 (JST) To: John Hay Cc: bmilekic@technokratis.com (Bosko Milekic), freebsd-net@FreeBSD.ORG In-reply-to: jhay's message of Sat, 06 Mar 2001 20:23:03 +0200. <200103061823.f26IN3064621@zibbi.icomtek.csir.co.za> 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: kernel: nd6_storelladdr failed, mbuf leak From: itojun@iijlab.net Date: Wed, 07 Mar 2001 08:33:14 +0900 Message-ID: <18755.983921594@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> > will correct it. thanks for reporting. http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/nd6.c.diff?r1=1.135&r2=1.136 itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 17: 3:11 2001 Delivered-To: freebsd-net@freebsd.org Received: from lotl.clari.net.au (lotl.clari.net.au [203.26.127.210]) by hub.freebsd.org (Postfix) with ESMTP id E00DD37B719 for ; Tue, 6 Mar 2001 17:03:05 -0800 (PST) (envelope-from stephen@clari.net.au) Received: from theforce.clari.net.au (theforce.clari.net.au [203.8.14.120]) by lotl.clari.net.au (8.9.3/8.9.1) with ESMTP id MAA95098 for ; Wed, 7 Mar 2001 12:02:35 +1100 (EST) (envelope-from stephen@clari.net.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 07 Mar 2001 12:09:03 +1100 (EST) Organization: ClariNET Internet Solutions From: Stephen Cimarelli To: freebsd-net@freebsd.org Subject: IPSEC + natd + IPFW Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All I have managed to get IPsec+gif tunelling to work but am having trouble setting up firewal rules, it seem that recieved ESP packets pass through the firewall rule set twice and hit my natd divert rules. Toget around this I had to add a rule like 00110 and 00115 00001 150 20400 count esp from any to any 00010 150 20400 allow esp from any to any in recv tun0 00011 0 0 allow esp from any to any out xmit tun0 00110 1560 231661 allow ip from 192.168.0.0/16 to 192.168.0.0/16 00115 9 756 allow ip from 10.10.0.0/16 to 192.168.0.0/16 via tun0 00120 6193 2543953 divert 8668 tcp from any to any out xmit tun0 00120 15 1233 divert 8668 udp from any to any out xmit tun0 00120 0 0 divert 8668 icmp from any to any out xmit tun0 00121 6132 6364485 divert 8668 tcp from any to any in recv tun0 00121 16 3516 divert 8668 udp from any to any in recv tun0 00121 21 1764 divert 8668 icmp from any to any in recv tun0 with 192.168. and 10.10 being the remote internal networks But there must be a better way ? ---------------------------------- E-Mail: Stephen Cimarelli Date: 07-Mar-01 Time: 11:51:44 ClariNet Internet Solutions +61 3 9486 0811 www.clari.net.au ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 17:20: 8 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 E91DE37B718 for ; Tue, 6 Mar 2001 17:20:03 -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 f271JxG24292; Tue, 6 Mar 2001 17:19:59 -0800 (PST) Message-ID: <3AA58CBF.819707E6@isi.edu> Date: Tue, 06 Mar 2001 17:19: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: Stephen Cimarelli Cc: freebsd-net@freebsd.org Subject: Re: IPSEC + natd + IPFW References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5E861A595937217AB6E4D5FA" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms5E861A595937217AB6E4D5FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Cimarelli wrote: > I have managed to get IPsec+gif tunelling to work but am having trouble setting > up firewal rules, it seem that recieved ESP packets pass through the firewall > rule set twice and hit my natd divert rules. Do you use IPsec tunnel mode, or IPsec transport mode + gif tunnels to do the tunneling? Also, in the ipfw rules below, your "via" clauses reference tun0, which is neither gif nor IPsec tunneling. > Toget around this I had to add a rule like 00110 and 00115 > > 00001 150 20400 count esp from any to any > 00010 150 20400 allow esp from any to any in recv tun0 > 00011 0 0 allow esp from any to any out xmit tun0 > 00110 1560 231661 allow ip from 192.168.0.0/16 to 192.168.0.0/16 > 00115 9 756 allow ip from 10.10.0.0/16 to 192.168.0.0/16 via tun0 > 00120 6193 2543953 divert 8668 tcp from any to any out xmit tun0 > 00120 15 1233 divert 8668 udp from any to any out xmit tun0 > 00120 0 0 divert 8668 icmp from any to any out xmit tun0 > 00121 6132 6364485 divert 8668 tcp from any to any in recv tun0 > 00121 16 3516 divert 8668 udp from any to any in recv tun0 > 00121 21 1764 divert 8668 icmp from any to any in recv tun0 -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms5E861A595937217AB6E4D5FA 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 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAxMDMwNzAxMTk1OVowIwYJKoZIhvcNAQkEMRYE FBTx4BVsFTZLIxG4zzuh/WESx9NoMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G CSqGSIb3DQEBAQUABIGAgtTQAobF3sBGGkKEoRDzgSfDYZGV/PgyguKvn2IJQL1Zo9l5BCzV ljy3rkByVAAywh8b3+PPM01Y1LTKKh6fUqCKkRXt2b35KAkdhvBRhFqdV5fOOykz4FWPG/pW atI+negjBQy1ZVXXru0n/jk/0fXlDGnuqmBXHF7QhLR1XTw= --------------ms5E861A595937217AB6E4D5FA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 18:37:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from lotl.clari.net.au (lotl.clari.net.au [203.26.127.210]) by hub.freebsd.org (Postfix) with ESMTP id 22C0E37B719 for ; Tue, 6 Mar 2001 18:37:13 -0800 (PST) (envelope-from stephen@clari.net.au) Received: from theforce.clari.net.au (theforce.clari.net.au [203.8.14.120]) by lotl.clari.net.au (8.9.3/8.9.1) with ESMTP id NAA02600; Wed, 7 Mar 2001 13:36:37 +1100 (EST) (envelope-from stephen@clari.net.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3AA58CBF.819707E6@isi.edu> Date: Wed, 07 Mar 2001 13:43:10 +1100 (EST) Organization: ClariNET Internet Solutions From: Stephen Cimarelli To: Lars Eggert Subject: Re: IPSEC + natd + IPFW Cc: freebsd-net@FreeBSD.ORG Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 07-Mar-01 Lars Eggert wrote: > Stephen Cimarelli wrote: >> I have managed to get IPsec+gif tunelling to work but am having trouble >> setting >> up firewal rules, it seem that recieved ESP packets pass through the >> firewall >> rule set twice and hit my natd divert rules. > > Do you use IPsec tunnel mode, or IPsec transport mode + gif tunnels to do > the tunneling? Well this is where it starts to get funny, I have 2 HOWTOs Both HOWTO's use gif tunnels, but the FreeBSD IPsec mini-HOWTO uses IPsec transport + gif tunnels and The IPSEC VPN tunnel on freeBSD 4.x howto uses IPsec tunnel + gif tunnels ------------------------------ For me only IPsec tunnel + gif tunnels works. >Also, in the ipfw rules below, your "via" clauses reference > tun0, which is neither gif nor IPsec tunneling. Yes but rules 110 and 115 are what I added to get it to work with natd, with out those rules ESP packets coming back in where getting diverted at rules 120, It seem has if the ESP where geting decoded and than getting internally feed back through the ipfw rules. > >> Toget around this I had to add a rule like 00110 and 00115 >> >> 00001 150 20400 count esp from any to any >> 00010 150 20400 allow esp from any to any in recv tun0 >> 00011 0 0 allow esp from any to any out xmit tun0 >> 00110 1560 231661 allow ip from 192.168.0.0/16 to 192.168.0.0/16 >> 00115 9 756 allow ip from 10.10.0.0/16 to 192.168.0.0/16 via tun0 >> 00120 6193 2543953 divert 8668 tcp from any to any out xmit tun0 >> 00120 15 1233 divert 8668 udp from any to any out xmit tun0 >> 00120 0 0 divert 8668 icmp from any to any out xmit tun0 >> 00121 6132 6364485 divert 8668 tcp from any to any in recv tun0 >> 00121 16 3516 divert 8668 udp from any to any in recv tun0 >> 00121 21 1764 divert 8668 icmp from any to any in recv tun0 > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California ---------------------------------- E-Mail: Stephen Cimarelli Date: 07-Mar-01 Time: 13:28:07 ClariNet Internet Solutions +61 3 9486 0811 www.clari.net.au ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Mar 6 21:12: 0 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 57C3337B718 for ; Tue, 6 Mar 2001 21:11:56 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from [66.27.64.64] (we-66-27-64-64.we.mediaone.net [66.27.64.64]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f275BrG26359; Tue, 6 Mar 2001 21:11:53 -0800 (PST) User-Agent: Microsoft-Entourage/9.0.2509 Date: Tue, 06 Mar 2001 21:11:51 -0800 Subject: Re: IPSEC + natd + IPFW From: Lars Eggert To: Stephen Cimarelli Cc: Message-ID: In-Reply-To: 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 At 1:43 PM +1100 3/7/01, Stephen Cimarelli wrote: > On 07-Mar-01 Lars Eggert wrote: >> Do you use IPsec tunnel mode, or IPsec transport mode + gif tunnels to do >> the tunneling? > > Well this is where it starts to get funny, I have 2 HOWTOs > Both HOWTO's use gif tunnels, but > the FreeBSD IPsec mini-HOWTO > uses IPsec transport + gif tunnels > and > The IPSEC VPN tunnel on freeBSD 4.x howto > uses IPsec tunnel + gif tunnels > ------------------------------ > For me only IPsec tunnel + gif tunnels works. First off, I have never used IPsec together with NAT. But it seems to me that you can set up one after the other. If you use IPsec tunnels, you shouldn't need gif tunnels at all. If you do, that is probably a sign that your routes aren't set up correctly. IPsec tunnels are configured in the SA database, and don't show up in the routing table. IPsec processing occurs before routing, and this works for simple cases. (E.g. "take all traffic that matches this pattern, and apply this tunnel-mode SA".) I suspect that you run into the same problem with IPsec tunnels that we (= the X-Bone project) ran into a while ago, when we tried to get dynamic routing to work over IPsec tunnels: It doesn't work - because IPsec tunnels aren't represented in the routing table, and thus are invisible to gated/mrtd. We solved this by using IPIP tunnels (= gif devices) together with IPsec transport mode. Tunneling is done first, and the transport mode IPsec SA is applied after IPIP encapsulation. In this case, your tunnels are represented in the routing table, and appear to be regular network interfaces (unlike IPsec tunnels.) I'm not sure how NAT fits into this picture though. It's probably based on packet matching/rewriting (like ipfw), in which case your IPsec tunnel mode SA probably won't be applied to the rewritten packet, and it falls on the floor. There's a good chance that IPIP tunnels still catch and forward them, however - routing is done after rewriting, as far as I remember. The other benefit of using IPIP tunnels + IPsec transport mode is that you can configure and debug the tunneling first, and then add IPsec processing after you've got the tunneling up. More details on this are in "Use of IPSEC Transport Mode for Virtual Networks" at ftp://ftp.isi.edu/internet-drafts/draft-touch-ipsec-vpn-01.txt Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 2:32:22 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 5504B37B727; Wed, 7 Mar 2001 02:32:08 -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 f27AVu623029; Wed, 7 Mar 2001 12:31:56 +0200 (EET) (envelope-from ru) Date: Wed, 7 Mar 2001 12:31:56 +0200 From: Ruslan Ermilov To: Jonathan Lemon Cc: Jonathan Lemon , net@FreeBSD.ORG Subject: Re: Delayed checksums commit broke UDP checksum calculation Message-ID: <20010307123156.A19829@sunbay.com> Mail-Followup-To: Jonathan Lemon , Jonathan Lemon , net@FreeBSD.ORG References: <20001116120936.A45755@sunbay.com> <20001116091954.A19895@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: <20001116091954.A19895@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Nov 16, 2000 at 09:19:54AM -0600 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Nov 16, 2000 at 09:19:54AM -0600, Jonathan Lemon wrote: > On Thu, Nov 16, 2000 at 12:09:36PM +0200, Ruslan Ermilov wrote: > > Hi! > > > > RFC768> If the computed checksum is zero, it is transmitted as all ones > > RFC768> (the equivalent in one's complement arithmetic). An all zero > > RFC768> transmitted checksum value means that the transmitter generated > > RFC768> no checksum. > > > > This (0x0000 -> 0xFFFF) apparently got broken in udp_usrreq.c,v 1.65. > > Actually, it got broken in a different fashion; I had originally moved > the above logic within in_cksum itself, and when that got taken out, > the UDP case wasn't updated. > Actually, the "logic move" was implemented wrong, and then got wiped out in revision 1.21 of sys/i386/i386/in_cksum.c. Also, you MFC'ed this fix for i386, but did not for alpha. (sys/alpha/alpha/in_cksum.c,v 1.5). > > Index: ip_output.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v > > retrieving revision 1.116 > > diff -u -p -r1.116 ip_output.c > > --- ip_output.c 2000/11/01 01:59:28 1.116 > > +++ ip_output.c 2000/11/16 10:05:06 > > @@ -974,6 +974,8 @@ in_delayed_cksum(struct mbuf *m) > > ip = mtod(m, struct ip *); > > offset = IP_VHL_HL(ip->ip_vhl) << 2 ; > > csum = in_cksum_skip(m, ip->ip_len, offset); > > + if (m->m_pkthdr.csum_flags & CSUM_UDP && csum == 0) > > + csum = 0xffff; /* per RFC768 */ > > offset += m->m_pkthdr.csum_data; /* checksum offset */ > > > > if (offset + sizeof(u_short) > m->m_len) { > > > This would work. Alternatively, you could change it to: > > if (csum == 0) > csum = 0xffff; > > So that the same logic applies to TCP packets as well. Currently, we > can send a TCP packet with a checksum of 0, which is legal. Of possible > interest is that Linux doesn't do this; they alwyas send a non-zero > checksum in the TCP case, if a checksum was computed. > Hmm, but why would we do this for TCP? This violates RFC 793. AFAIK, only UDP checksums are special. 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 Wed Mar 7 4:35:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from frmta01.chello.fr (smtp.chello.fr [212.186.224.12]) by hub.freebsd.org (Postfix) with ESMTP id 1AA0037B718 for ; Wed, 7 Mar 2001 04:35:23 -0800 (PST) (envelope-from spe@bsdfr.org) Received: from cha213245067102.chello.fr ([213.245.67.102]) by frmta01.chello.fr with ESMTP id <20010307123516.GJB433.frmta01@cha213245067102.chello.fr> for ; Wed, 7 Mar 2001 13:35:16 +0100 Date: Wed, 07 Mar 2001 13:32:48 CET From: Sebastien Petit To: freebsd-net@FreeBSD.org Subject: perhaps an updating local route problem when you delete an IPv4 alias Reply-To: spe@bsdfr.org X-Mailer: Spruce 0.6.5 for X11 w/smtpio 0.7.9 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-Id: <20010307123516.GJB433.frmta01@cha213245067102.chello.fr> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi FreeBSD team, Consider this manipulation on host A: # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 0 0 lo0 172.16 link#1 UC 0 0 xl0 => # ifconfig xl0 xl0: flags=8843 mtu 1500 inet 172.16.1.1 netmask 0xffff0000 broadcast 172.16.255.255 inet6 fe80::250:daff:fe66:aa87%xl0 prefixlen 64 scopeid 0x1 ether 00:50:da:66:aa:87 media: 100baseTX status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX # ifconfig xl0 alias 172.16.1.2 netmask 255.255.255.255 # ifconfig xl0 xl0: flags=8843 mtu 1500 inet 172.16.1.1 netmask 0xffff0000 broadcast 172.16.255.255 inet6 fe80::250:daff:fe66:aa87%xl0 prefixlen 64 scopeid 0x1 inet 172.16.1.2 netmask 0xffffffff broadcast 172.16.1.2 ether 00:50:da:66:aa:87 media: 100baseTX status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX At this step, all is good. When you ping 172.16.1.2 for example, kernel (I think) create a Local Host route (UHLW) for 172.16.1.2 to 00:50:da:66:aa:87 (mac address of xl0) and for 172.16.1.2/32 to link#1 (UC). # ping 172.16.1.2 (...) # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 0 0 lo0 172.16 link#1 UC 0 0 xl0 => 172.16.1.2 0:50:da:66:aa:87 UHLW 0 4 lo0 => 172.16.1.2/32 link#1 UC 0 0 xl0 => A problem of updating route appears when you delete the IPv4 alias on the interface like this: # ifconfig xl0 delete 172.16.1.2 netmask 255.255.255.255 # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire 127.0.0.1 127.0.0.1 UH 0 0 lo0 172.16 link#1 UC 0 0 xl0 => 172.16.1.2 0:50:da:66:aa:87 UHLW 0 4 lo0 => route to 172.16.1.2/32 is destructed so it's ok no problem, but route to 172.16.1.2 seems to stay and no deletion is performed. So a permanent arp entry exist for this IPv4 address (172.16.1.2): # arp -a -n ? (172.16.1.1) at 0:50:da:66:aa:87 permanent [ethernet] ? (172.16.1.2) at 0:50:da:66:aa:87 permanent [ethernet] This permanent entry is due to the problem route. So if another host B on the network own 172.16.1.2 IPv4 address, this host B send a gratuitous arp but host A don't update arp cache because permanent entry cannot be removed by a gratuitous arp. So If you want that host A communicate with host B and know the *real* arp entry, you must delete by hand this wrong route. Do you think that ifconfig must delete this route if it exist ? PS: problem does not appear when host A don't try to communicate with his IPv4 alias. Cheers. -- Sebastien Petit spe@bsdfr.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 7 6: 8:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from brisefer.cediti.be (brisefer.cediti.be [193.190.156.67]) by hub.freebsd.org (Postfix) with ESMTP id 9DA4737B719 for ; Wed, 7 Mar 2001 06:08:09 -0800 (PST) (envelope-from Olivier.Cherrier@cediti.be) Received: by brisefer.cediti.be with Internet Mail Service (5.5.2650.21) id <1TDVLMZN>; Wed, 7 Mar 2001 15:07:31 +0100 Message-ID: From: Olivier Cherrier To: "'freebsd-net@freebsd.org'" Subject: RE: mpd errors when trying to connect using MS pptp client Date: Wed, 7 Mar 2001 15:07:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems to be a netmask routing problem. Can you check the net config ? Olivier > >Can you ping the host you're talking to? The log lines describe >options in a single LCP request being sent, which apparently >cannot be sent because there is no route for the target IP addr. > >Barney Wolff > >On Tue, Mar 06, 2001 at 12:50:10PM -0500, Sonne, Byron wrote: >> Greetings all, >> >> When I try to connect to my FreeBSD 4.2 box (running mpd as >a pptp server) >> using the Win2k pptp client, I get the following error >"Disconnected. Error >> 619: The specified port is not connected". >> >> If I then look in my mpd.log, I see the following occur >twice, here is one >> of them: >> >> Mar 6 12:43:33 cleric mpd: [pptp] LCP: SendConfigReq #21 >> Mar 6 12:43:33 cleric mpd: ACFCOMP >> Mar 6 12:43:33 cleric mpd: PROTOCOMP >> Mar 6 12:43:33 cleric mpd: MRU 1500 >> Mar 6 12:43:33 cleric mpd: MAGICNUM e76a24e1 >> Mar 6 12:43:33 cleric mpd: AUTHPROTO CHAP MSOFT >> Mar 6 12:43:33 cleric mpd: [pptp] error writing len 27 >frame to bypass: No >> route to host >> Mar 6 12:43:33 cleric mpd: pptp0-0: ignoring SetLinkInfo >> >> Of major interest to me is the second last line that >contains the "No route >> to host" comment. If they can start the handshake to the >point where we can >> get an error, then it seems to me there has to be some kind >of route. I >> thought perhaps my firewall rules were dropping a short >packet generated in >> this exchange, but tweaking the rules didn't seem to make >any difference >> (perhaps I didn't tweak them correctly ?) >> >> Can someone shed some more light on what this is trying to >tell me? I'm >> hoping this will help point me in the right direction so I >can figure out >> how to fix it. >> >> Regards, >> Byron Sonne >> >> 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 6:32:13 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 B509A37B718 for ; Wed, 7 Mar 2001 06:32:06 -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 f27EW0d14170 for net@FreeBSD.org; Wed, 7 Mar 2001 16:32:00 +0200 (EET) (envelope-from ru) Date: Wed, 7 Mar 2001 16:32:00 +0200 From: Ruslan Ermilov To: net@FreeBSD.org Subject: [PATCH] IP_TTL, IP_TOS, and raw IP sockets Message-ID: <20010307163200.A97252@sunbay.com> Mail-Followup-To: net@FreeBSD.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! IP_TTL and IP_TOS setsockopt(2) options currently do not take any effect on raw IP sockets (actually, everything that uses rip_usrreqs function set). The attached patch fixes this. Also, I have the question. Should we use MAXTTL constant or net.inet.ip.ttl MIB variable, as the initial value for TTL? Finally, if anyone has any objections, send them now. 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 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: raw_ip.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v retrieving revision 1.73 diff -u -p -r1.73 raw_ip.c --- raw_ip.c 2001/02/04 13:13:08 1.73 +++ raw_ip.c 2001/03/07 14:26:12 @@ -197,13 +197,13 @@ rip_output(m, so, dst) } M_PREPEND(m, sizeof(struct ip), M_TRYWAIT); ip = mtod(m, struct ip *); - ip->ip_tos = 0; + ip->ip_tos = inp->inp_ip_tos; ip->ip_off = 0; ip->ip_p = inp->inp_ip_p; ip->ip_len = m->m_pkthdr.len; ip->ip_src = inp->inp_laddr; ip->ip_dst.s_addr = dst; - ip->ip_ttl = MAXTTL; + ip->ip_ttl = inp->inp_ip_ttl; } else { if (m->m_pkthdr.len > IP_MAXPACKET) { m_freem(m); @@ -458,6 +458,7 @@ rip_attach(struct socket *so, int proto, inp = (struct inpcb *)so->so_pcb; inp->inp_vflag |= INP_IPV4; inp->inp_ip_p = proto; + inp->inp_ip_ttl = MAXTTL; #ifdef IPSEC error = ipsec_init_policy(so, &inp->inp_sp); if (error != 0) { --gKMricLos+KVdGMg-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 6:40:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 531BA37B71A; Wed, 7 Mar 2001 06:40:35 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.2/8.11.0) with ESMTP id f27EeYa99809; Wed, 7 Mar 2001 09:40:34 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200103071440.f27EeYa99809@whizzo.transsys.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Ruslan Ermilov Cc: Jonathan Lemon , Jonathan Lemon , net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Delayed checksums commit broke UDP checksum calculation References: <20001116120936.A45755@sunbay.com> <20001116091954.A19895@prism.flugsvamp.com> <20010307123156.A19829@sunbay.com> In-reply-to: Your message of "Wed, 07 Mar 2001 12:31:56 +0200." <20010307123156.A19829@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Mar 2001 09:40:34 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > So that the same logic applies to TCP packets as well. Currently, we > > can send a TCP packet with a checksum of 0, which is legal. Of possible > > interest is that Linux doesn't do this; they alwyas send a non-zero > > checksum in the TCP case, if a checksum was computed. > > > Hmm, but why would we do this for TCP? This violates RFC 793. > AFAIK, only UDP checksums are special. 0x0000 and 0xFFFF are both 16-bit 1's complement representations of zero, so you could send either and still have the remote TCP validate the checksum. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 6:53:26 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 CB1C637B718; Wed, 7 Mar 2001 06:51:03 -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 f27EmMa35701; Wed, 7 Mar 2001 16:48:22 +0200 (EET) (envelope-from ru) Date: Wed, 7 Mar 2001 16:48:22 +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: <20010307164822.E97252@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103071440.f27EeYa99809@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Mar 07, 2001 at 09:40:34AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Mar 07, 2001 at 09:40:34AM -0500, Louis A. Mamakos wrote: > > > > So that the same logic applies to TCP packets as well. Currently, we > > > can send a TCP packet with a checksum of 0, which is legal. Of possible > > > interest is that Linux doesn't do this; they alwyas send a non-zero > > > checksum in the TCP case, if a checksum was computed. > > > > > Hmm, but why would we do this for TCP? This violates RFC 793. > > AFAIK, only UDP checksums are special. > > 0x0000 and 0xFFFF are both 16-bit 1's complement representations of > zero, so you could send either and still have the remote TCP validate > the checksum. > Louis, I recall our long discussion on the topic. It depends on how remote end verifies the checksum. It it uses the value in checksum field, then it is irrelevant. If it recomputes the checksum from scratch, it does matter, and they won't match if you replace 0x0000 computed checksum by 0xffff. And after I read Stevens, I still think they are the different values, and you can't receive zero for a two's complement sum if at least one item is non-zero. Therefore, checksum computed on any valid IP packet is guaranteed to be non-0xffff. That's why UDP uses zero to indicate no-checksum, and requires to replace 0xffff by 0. 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 Wed Mar 7 6:58:35 2001 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 6190937B71C; Wed, 7 Mar 2001 06:58:32 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.2/8.11.0) with ESMTP id f27EwWa99960; Wed, 7 Mar 2001 09:58:32 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200103071458.f27EwWa99960@whizzo.transsys.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Ruslan Ermilov Cc: Jonathan Lemon , Jonathan Lemon , net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Delayed checksums commit broke UDP checksum calculation References: <20001116120936.A45755@sunbay.com> <20001116091954.A19895@prism.flugsvamp.com> <20010307123156.A19829@sunbay.com> <200103071440.f27EeYa99809@whizzo.transsys.com> <20010307164822.E97252@sunbay.com> In-reply-to: Your message of "Wed, 07 Mar 2001 16:48:22 +0200." <20010307164822.E97252@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Mar 2001 09:58:32 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Wed, Mar 07, 2001 at 09:40:34AM -0500, Louis A. Mamakos wrote: > > > > > > So that the same logic applies to TCP packets as well. Currently, we > > > > can send a TCP packet with a checksum of 0, which is legal. Of possible > > > > interest is that Linux doesn't do this; they alwyas send a non-zero > > > > checksum in the TCP case, if a checksum was computed. > > > > > > > Hmm, but why would we do this for TCP? This violates RFC 793. > > > AFAIK, only UDP checksums are special. > > > > 0x0000 and 0xFFFF are both 16-bit 1's complement representations of > > zero, so you could send either and still have the remote TCP validate > > the checksum. > > > Louis, I recall our long discussion on the topic. It depends on how > remote end verifies the checksum. It it uses the value in checksum > field, then it is irrelevant. If it recomputes the checksum from > scratch, it does matter, and they won't match if you replace 0x0000 > computed checksum by 0xffff. > > And after I read Stevens, I still think they are the different values, > and you can't receive zero for a two's complement sum if at least one > item is non-zero. Therefore, checksum computed on any valid IP packet > is guaranteed to be non-0xffff. That's why UDP uses zero to indicate > no-checksum, and requires to replace 0xffff by 0. Whatever. Both +0 and -0 in 1's complement arithemetic are equivelent, just as a normalized and non-normalized floating point representation of the same value are "equal" even though the bit patterns are different. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 7:24:47 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 A703737B718; Wed, 7 Mar 2001 07:24:29 -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 f27FJuv39380; Wed, 7 Mar 2001 17:19:56 +0200 (EET) (envelope-from ru) Date: Wed, 7 Mar 2001 17:19:56 +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: <20010307171956.B36537@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103071458.f27EwWa99960@whizzo.transsys.com>; from louie@TransSys.COM on Wed, Mar 07, 2001 at 09:58:32AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Mar 07, 2001 at 09:58:32AM -0500, Louis A. Mamakos wrote: > > On Wed, Mar 07, 2001 at 09:40:34AM -0500, Louis A. Mamakos wrote: > > > > > > > > So that the same logic applies to TCP packets as well. Currently, we > > > > > can send a TCP packet with a checksum of 0, which is legal. Of possible > > > > > interest is that Linux doesn't do this; they alwyas send a non-zero > > > > > checksum in the TCP case, if a checksum was computed. > > > > > > > > > Hmm, but why would we do this for TCP? This violates RFC 793. > > > > AFAIK, only UDP checksums are special. > > > > > > 0x0000 and 0xFFFF are both 16-bit 1's complement representations of > > > zero, so you could send either and still have the remote TCP validate > > > the checksum. > > > > > Louis, I recall our long discussion on the topic. It depends on how > > remote end verifies the checksum. It it uses the value in checksum > > field, then it is irrelevant. If it recomputes the checksum from > > scratch, it does matter, and they won't match if you replace 0x0000 > > computed checksum by 0xffff. > > > > And after I read Stevens, I still think they are the different values, > > and you can't receive zero for a two's complement sum if at least one > > item is non-zero. Therefore, checksum computed on any valid IP packet > > is guaranteed to be non-0xffff. That's why UDP uses zero to indicate > > no-checksum, and requires to replace 0xffff by 0. > > Whatever. Both +0 and -0 in 1's complement arithemetic are equivelent, > just as a normalized and non-normalized floating point representation > of the same value are "equal" even though the bit patterns are different. > In two's complement arithmetics, yes. What matters here is how the the real checkers are implemented. For BSD-derived implementations, this does not matter. I don't know if others really exist. RFC 1624 is pretty clear on this topic. The usual Internet principle is in place (from RFC 791): "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)." To be CONSERVATIVE, the implementation MUST NOT transmit all-zero computed TCP checksum as all-ones; while they are certainly equivalent in two'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 two's complement sum on a non-two's-complement hardware, and compare the result with what stored in the checksum field. In this case, +0 and -0 will differ. 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. 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 Wed Mar 7 7:47:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id A727737B71A; Wed, 7 Mar 2001 07:47:06 -0800 (PST) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.2/8.11.0) with ESMTP id f27Fl6a00528; Wed, 7 Mar 2001 10:47:06 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200103071547.f27Fl6a00528@whizzo.transsys.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Ruslan Ermilov Cc: Jonathan Lemon , Jonathan Lemon , net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Delayed checksums commit broke UDP checksum calculation 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> In-reply-to: Your message of "Wed, 07 Mar 2001 17:19:56 +0200." <20010307171956.B36537@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Mar 2001 10:47:06 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In two's complement arithmetics, yes. What matters here is how the > the real checkers are implemented. For BSD-derived implementations, > this does not matter. I don't know if others really exist. RFC 1624 > is pretty clear on this topic. The usual Internet principle is in place > (from RFC 791): "In general, an implementation must be conservative in > its sending behavior, and liberal in its receiving behavior. That is, > it must be careful to send well-formed datagrams, but must accept any > datagram that it can interpret (e.g., not object to technical errors > where the meaning is still clear)." > To be CONSERVATIVE, the implementation MUST NOT transmit all-zero > computed TCP checksum as all-ones; while they are certainly equivalent > in two'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 two's complement sum on a non-two'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. 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. > 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. 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. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 8:23: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id B324037B718 for ; Wed, 7 Mar 2001 08:23:01 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14agiK-0000bV-00; Wed, 7 Mar 2001 16:23:00 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14aggJ-0004uT-00 for freebsd-net@freebsd.org; Wed, 7 Mar 2001 16:20:55 +0000 From: "Andy [TECC NOPS]" To: Subject: ipfw Date: Wed, 7 Mar 2001 16:27:23 -0000 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.2314.1300 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All Just built a new kernel with options IPFIREWALL options IPDIVERT and all went in ok. However, when I user the ipfw command to add a rule (or when rc.firewall does) I get the following error message:- ipfw: getsocketopt(IP_FW_ADD): Invalid argument Can anyone point out the obvious mistake I must be making? (4.2-STABLE install from the CDRom) Cheers Ak To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 8:39: 0 2001 Delivered-To: freebsd-net@freebsd.org Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by hub.freebsd.org (Postfix) with ESMTP id EFECB37B719 for ; Wed, 7 Mar 2001 08:38:57 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.9.3/8.9.3) id JAA56571; Wed, 7 Mar 2001 09:38:41 -0700 (MST) (envelope-from rousskov) Date: Wed, 7 Mar 2001 09:38:41 -0700 (MST) From: Alex Rousskov To: "Andy [TECC NOPS]" Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw 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 Wed, 7 Mar 2001, Andy [TECC NOPS] wrote: > Just built a new kernel with > > options IPFIREWALL > options IPDIVERT > > and all went in ok. However, when I > user the ipfw command to add a rule > (or when rc.firewall does) I get the > following error message:- > > ipfw: getsocketopt(IP_FW_ADD): Invalid argument > > Can anyone point out the obvious mistake > I must be making? I can only point out really obvious ones: - you forgot to "make depend" when building a new kernel - you forgot to "make install" after building a new kernel - you forgot to reboot after installing a new kernel - you built a kernel with a config file different from the config file you modified. Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 8:41:37 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.tecc.co.uk (luggage.tecc.co.uk [193.128.6.129]) by hub.freebsd.org (Postfix) with SMTP id 962F037B718 for ; Wed, 7 Mar 2001 08:41:33 -0800 (PST) (envelope-from andy@tecc.co.uk) Received: from fw-smtp.tecc.co.uk [195.217.37.39] by relay.tecc.co.uk with esmtp (Exim 1.70 #1) id 14ah0G-0000ix-00; Wed, 7 Mar 2001 16:41:32 +0000 Received: from [195.217.37.155] (helo=southampton) by fw-smtp.tecc.co.uk with smtp (Exim 2.12 #3) id 14agyF-00050Q-00; Wed, 7 Mar 2001 16:39:27 +0000 From: "Andy [TECC NOPS]" To: "Alex Rousskov" Cc: Subject: RE: ipfw Date: Wed, 7 Mar 2001 16:45:55 -0000 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) 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 Na did all that. Thanks thou, the answer was actually in my own email (I think still build new kernel) aka install from CDRom and 4.2-STABLE. Sure the CDRom is 4.2-RELEASE, so when did I cvsup my kernel src tree! dunno, reinstalled srcs so hopefully that's sort it out. cheers Ak > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: 07 March 2001 16:39 > To: Andy [TECC NOPS] > Cc: freebsd-net@FreeBSD.ORG > Subject: Re: ipfw > > > On Wed, 7 Mar 2001, Andy [TECC NOPS] wrote: > > > Just built a new kernel with > > > > options IPFIREWALL > > options IPDIVERT > > > > and all went in ok. However, when I > > user the ipfw command to add a rule > > (or when rc.firewall does) I get the > > following error message:- > > > > ipfw: getsocketopt(IP_FW_ADD): Invalid argument > > > > Can anyone point out the obvious mistake > > I must be making? > > I can only point out really obvious ones: > - you forgot to "make depend" when building a new kernel > - you forgot to "make install" after building a new kernel > - you forgot to reboot after installing a new kernel > - you built a kernel with a config file different from > the config file you modified. > > Alex. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 9: 4:54 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 07EA237B71A for ; Wed, 7 Mar 2001 09:04:46 -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 f27HWiv21052; Wed, 7 Mar 2001 11:32:44 -0600 (CST) (envelope-from nick@rogness.net) Date: Wed, 7 Mar 2001 11:32:44 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: "Andy [TECC NOPS]" Cc: freebsd-net@FreeBSD.ORG Subject: Re: ipfw 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 Wed, 7 Mar 2001, Andy [TECC NOPS] wrote: > Can anyone point out the obvious mistake > I must be making? In /etc/rc.conf: firewall_enable="YES" I can't remember if you need this even if the kernel is compiled with IPFIREWALL support 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 Wed Mar 7 10:11:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from worldclass.jolt.nu (lgh637b.hn-krukan.AC [212.217.139.112]) by hub.freebsd.org (Postfix) with ESMTP id 5CA6A37B71A for ; Wed, 7 Mar 2001 10:11:40 -0800 (PST) (envelope-from c4@worldclass.jolt.nu) Received: by worldclass.jolt.nu (Postfix, from userid 1000) id D734FC2; Wed, 7 Mar 2001 19:08:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by worldclass.jolt.nu (Postfix) with ESMTP id 6245B39; Wed, 7 Mar 2001 19:08:46 +0100 (CET) Date: Wed, 7 Mar 2001 19:08:45 +0100 (CET) From: Tobias Fredriksson To: Nick Rogness Cc: "Andy [TECC NOPS]" , freebsd-net@FreeBSD.ORG Subject: Re: ipfw 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 Wed, 7 Mar 2001, Nick Rogness wrote: > On Wed, 7 Mar 2001, Andy [TECC NOPS] wrote: > > > > Can anyone point out the obvious mistake > > I must be making? > > In /etc/rc.conf: > > firewall_enable="YES" > > I can't remember if you need this even if the kernel is compiled > with IPFIREWALL support or not. > well for the rc.firewall script to be runned... yes otherwise you only have default rule (normally deny all), but you are still able to do 'ipfw add .....' so... not really "needed" good to have ;) > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 10:57: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from news.IAEhv.nl (news.iae.nl [212.61.26.37]) by hub.freebsd.org (Postfix) with ESMTP id F1E9537B71B for ; Wed, 7 Mar 2001 10:57:01 -0800 (PST) (envelope-from Arjan.deVet@adv.iae.nl) Received: (from uucp@localhost) by news.IAEhv.nl (8.9.1/8.9.1) with IAEhv.nl id TAA09499 for freebsd-net@freebsd.org; Wed, 7 Mar 2001 19:57:00 +0100 (MET) Received: by adv.devet.org (Postfix, from userid 100) id 274253E15; Wed, 7 Mar 2001 19:55:57 +0100 (CET) Date: Wed, 7 Mar 2001 19:55:57 +0100 To: freebsd-net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010307195557.A22189@adv.devet.org> References: <200102080524.VAA54629@curve.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: Organization: Eindhoven, the Netherlands From: Arjan.deVet@adv.iae.nl (Arjan de Vet) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article Robert Watson wrote: >It seems that the ECONNABORTED is the "standard" way to address this >scenario; it might be an interesting exercise for someone to look at the >common application suites and see how they respond to various failure >modes in accept(). It certainly appears that BIND9 expects that. FYI, Postfix seems to have problems with the ECONNABORTED part of the change, see the mail below from postfix-users. Arjan -- Arjan de Vet, Eindhoven, The Netherlands URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl Subject: Re: errors from flush [again] In-Reply-To: <20010306234957.EE524BC06D@spike.porcupine.org> "from Wietse Venema at Mar 6, 2001 06:49:57 pm" To: Wietse Venema Date: Wed, 7 Mar 2001 10:26:22 -0500 (EST) Cc: Arjan de Vet , postfix-users@postfix.org Message-ID: <20010307152622.01B61BC070@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Postfix 20010228 is OK on FreeBSD 4.2-RELEASE. I just checked that the system behaves sanely when Postfix does connect() write() close() before the server has accept()ed the connection. Reportedly, some later FreeBSD versions introduce a race condition here. If the server accept()s the connection before the client close()s it, then the server may receive the data. If the server accept()s the connection after the client close()s it, the data is lost. In both cases, the client is told that the data was transmitted without error. This change in socket behavior breaks the Postfix flush service, and probably also breaks other parts of Postfix as well. It all depends on how quickly a server can call accept(), and thus, it all depends on how loaded a server is. This is a bad change. uname -a output: FreeBSD hades.porcupine.org 4.2-RELEASE FreeBSD 4.2-RELEASE #5: Sun Mar 4 18:58:52 EST 2001 wietse@hades.porcupine.org:/usr/src/sys/compile/GENERIC i386 Wietse Wietse Venema: > That's it. Postfix connects/writes/disconnects. The changed behavior > causes loss of data that was already written and acknowledged. > > The bad part is that there is no way for the sender to find out. > > Wietse > > Arjan de Vet: > > In article <20010306213602.11432BC06D@spike.porcupine.org> you write: > > > > >Every 100 seconds means whenever the master 'wakeup' timer goes > > >off. This means that UNIX-domain socket behavior has changed. > > > > I've looked through recent commits to socket code and this one may be > > the problem (not verified yet, it's time to go to sleep ;-): > > > > jlemon 2001/02/13 18:09:12 PST > > > > Modified files: > > sys/kern uipc_socket.c uipc_syscalls.c > > Log: > > Return ECONNABORTED from accept if connection is closed while on the > > listen queue, as well as the current behavior of a zero-length sockaddr. > > > > Obtained from: KAME > > Reviewed by: -net > > > > Revision Changes Path > > 1.88 +3 -6 src/sys/kern/uipc_socket.c > > 1.85 +15 -2 src/sys/kern/uipc_syscalls.c > > > > This change was applied on Feb 24 to FreeBSD 4.2-stable. > > > > The change in uipc_socket.c is: > > > > @@ -365,11 +365,8 @@ > > so->so_state &= ~SS_NOFDREF; > > if ((so->so_state & SS_ISDISCONNECTED) == 0) > > error = (*so->so_proto->pr_usrreqs->pru_accept)(so, > > nam); > > - else { > > - if (nam) > > - *nam = 0; > > - error = 0; > > - } > > + else > > + error = ECONNABORTED; > > splx(s); > > return (error); > > } > > > > ECONNABORTED is exactly the error I'm seeing now. > > > > >At the very least, the kernel could deliver the data that > > >is send with connect/write/disconnect. > > > > Arjan > > > > -- > > Arjan de Vet, Eindhoven, The Netherlands > > URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 12: 1:51 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 D29DA37B71A for ; Wed, 7 Mar 2001 12:01:48 -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 PAA25220 for ; Wed, 7 Mar 2001 15:04:06 -0500 (EST) (envelope-from peter@black.purplecat.net) Date: Wed, 7 Mar 2001 15:04:06 -0500 (EST) From: Peter Brezny To: freebsd-net@freebsd.org Subject: natd - static nat on multiple aliased ip's 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 Let's say I had two internal subnets that i'd like to nat with different external ip's, while also doing static nat on one of each of the internal ip's. Could i do that by doing something like thils: rc.conf natd_flags="-f /etc/natd.conf1" natd_flags="-f /etc/natd.conf2" rc.firewall $fwcmd add divert 8668 all from 10.1.1.1/24 to any via $oif $fwcmd add divert 8669 all from 10.1.2.1/24 to any via $oif natd.conf1 port 8668 interface fxp0 dynamic yes alias_address external_ip_1 redirect_address 10.1.1.4 external_ip_1 natd.conf2 port 8668 interface fxp0 dynamic yes alias_address external_ip_2 redirect_address 10.1.2.4 external_ip_2 TIA pb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 12:16:22 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 C677E37B718 for ; Wed, 7 Mar 2001 12:16:14 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f27KDoS39501; Wed, 7 Mar 2001 14:13:50 -0600 (CST) (envelope-from jlemon) Date: Wed, 7 Mar 2001 14:13:50 -0600 (CST) From: Jonathan Lemon Message-Id: <200103072013.f27KDoS39501@prism.flugsvamp.com> To: Arjan.deVet@adv.iae.nl, net@freebsd.org, wietse@porcupine.org, postfix-users@postfix.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] 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: >In article > Robert >Watson wrote: > >>It seems that the ECONNABORTED is the "standard" way to address this >>scenario; it might be an interesting exercise for someone to look at the >>common application suites and see how they respond to various failure >>modes in accept(). It certainly appears that BIND9 expects that. > >FYI, Postfix seems to have problems with the ECONNABORTED part of the >change, see the mail below from postfix-users. > >Arjan > >-- >Arjan de Vet, Eindhoven, The Netherlands >URL: http://www.iae.nl/users/devet/ for PGP key: finger devet@iae.nl > >Subject: Re: errors from flush [again] >In-Reply-To: <20010306234957.EE524BC06D@spike.porcupine.org> "from >Wietse Venema at Mar 6, 2001 06:49:57 pm" >To: Wietse Venema >Date: Wed, 7 Mar 2001 10:26:22 -0500 (EST) >Cc: Arjan de Vet , postfix-users@postfix.org >Message-ID: <20010307152622.01B61BC070@spike.porcupine.org> >From: wietse@porcupine.org (Wietse Venema) > >Postfix 20010228 is OK on FreeBSD 4.2-RELEASE. > >I just checked that the system behaves sanely when Postfix does > > connect() > write() > close() > >before the server has accept()ed the connection. > >Reportedly, some later FreeBSD versions introduce a race condition >here. If the server accept()s the connection before the client >close()s it, then the server may receive the data. If the server >accept()s the connection after the client close()s it, the data is >lost. In both cases, the client is told that the data was transmitted >without error. Actually, this is incorrect. The server in both cases will correctly receive the data from the client; it does not matter if the client has (correctly) closed the socket before the server gets around to accepting it. This case only applies to when connection is reset after the initial handshake, but before the connection is accepted. All we are doing is returning an error immediately via accept(), instead of waiting for a subsequent operation on the socket to fail. There is no change to the read/write semantics here; the local TCP endpoint (and any buffers) have already been destroyed. I probably poorly worded the commit message; it should read "return ECONNABORTED if connection receives a RST while on the listen queue". Under normal operation, the client's connection isn't really closed until it receives a FIN/ACK from the server. -- 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 7 12:24:15 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 B084137B719 for ; Wed, 7 Mar 2001 12:24:07 -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 f27KqH428013; Wed, 7 Mar 2001 14:52:17 -0600 (CST) (envelope-from nick@rogness.net) Date: Wed, 7 Mar 2001 14:52:17 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Peter Brezny Cc: freebsd-net@FreeBSD.ORG Subject: Re: natd - static nat on multiple aliased ip's 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 Wed, 7 Mar 2001, Peter Brezny wrote: > > Let's say I had two internal subnets that i'd like to nat with different > external ip's, while also doing static nat on one of each of the internal > ip's. Could i do that by doing something like thils: > > rc.conf > natd_flags="-f /etc/natd.conf1" > natd_flags="-f /etc/natd.conf2" Only the second line above will get executed. > > rc.firewall > $fwcmd add divert 8668 all from 10.1.1.1/24 to any via $oif > $fwcmd add divert 8669 all from 10.1.2.1/24 to any via $oif > The second rule will never get hit because the packets will only get divert through the first divert rule. > natd.conf1 > port 8668 > interface fxp0 > dynamic yes > alias_address external_ip_1 > redirect_address 10.1.1.4 external_ip_1 > > natd.conf2 > port 8668 > interface fxp0 > dynamic yes > alias_address external_ip_2 > redirect_address 10.1.2.4 external_ip_2 > The port statement on the second set is the same as the first. You really only need to run 1 natd and put both external ranges in your config. Like so: // In natd.conf: port 8668 interface fxp0 dynamic yes redirect_address 10.1.1.4 external_ip_1 redirect_address 10.1.2.4 external_ip_2 Then add ipfw fwd's to direct traffic the correct way. So the total ipfw ruleset would look like this: ... ipfw divert 8668 ip from any to any via fxp0 ipfw fwd A.A.A.A ip from external_range_1 to any out via fxp0 ipfw fwd B.B.B.B ip from external_range_2 to any out via fxp0 ... ... Where A.A.A.A is the gateway address of the external_range_1 and B.B.B.B is the gateway address of the external_range_2. 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 Wed Mar 7 13: 6:45 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 9FB7B37B718 for ; Wed, 7 Mar 2001 13:06:41 -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 f27LYqr29436; Wed, 7 Mar 2001 15:34:52 -0600 (CST) (envelope-from nick@rogness.net) Date: Wed, 7 Mar 2001 15:34:51 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Peter Brezny Cc: freebsd-net@freebsd.org Subject: Re: natd - static nat on multiple aliased ip's 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 Wed, 7 Mar 2001, Peter Brezny wrote: > > Won't your example below show all outbound traffic from the same > external ip, the ip that natd uses? > Yes and No, if the internal machine does not have a redirect_address statement in natd.conf then it will use the global interface or alias address outside the firewall. If redirect_address is used then the internal address carries redirect_address mapped external address when it goes outside the firewall. > I'd like to have the outbound traffic from internal range a.a.a.a have > one external ip and the outbound traffic from internal range b.b.b.b > have another external ip. Um, you can...but it is very complex with one interface. I'll try to explain why. Packets arrive and get translated to inside addresses...everything fine at this point...packet gets delivered to the inside machine...still no problem...but how does the packet on the return from the internal machine know which address to translate to when leaving the machine? Usually, it is seperate interface, which the ipfw divert rule is running on...and even then it is very tricky. If you search the archives back a couple of days, I gave an exmaple of how you would approach a problem like this. 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 Wed Mar 7 13:20:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by hub.freebsd.org (Postfix) with ESMTP id C476F37B718 for ; Wed, 7 Mar 2001 13:20:41 -0800 (PST) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id 8170EBC070; Wed, 7 Mar 2001 16:20:35 -0500 (EST) Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <200103072013.f27KDoS39501@prism.flugsvamp.com> "from Jonathan Lemon at Mar 7, 2001 02:13:50 pm" To: Jonathan Lemon Date: Wed, 7 Mar 2001 16:20:35 -0500 (EST) Cc: Arjan.deVet@adv.iae.nl, net@freebsd.org, wietse@porcupine.org, postfix-users@postfix.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010307212035.8170EBC070@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Several parts of Postfix do: connect() write() close(), where the close() may happen before the server has accept()ed the connection. Due to an incompatible change in FreeBSD 4.2-STABLE, this causes accept() after close() to fail. The already written data is lost. This is a bad incompatible change. 1 - It introduces a race condition where the result from connect() write() close() depends on how quickly the server can accept() the connection. 2 - The client gets no error notification. As far as the client knows, the write() and the close() completed without error. The above is experienced with UNIX-DOMAIN sockets. It is not known whether TCP sockets suffer from the same incompatible change. > Actually, this is incorrect. The server in both cases will correctly > receive the data from the client; it does not matter if the client has > (correctly) closed the socket before the server gets around to accepting it. This is incorrect. The accept() fails with ECONNABORTED, so that the server never receives the data. This is experienced by several people who compiled Postfix on FreeBSD 4.2-STABLE. This is wrong, because the client gets no error notification. As far as the client knows, the write() and the close() completed without error. > This case only applies to when connection is reset after the initial > handshake, but before the connection is accepted. All we are doing is > returning an error immediately via accept(), instead of waiting for a > subsequent operation on the socket to fail. There is no change to the > read/write semantics here; the local TCP endpoint (and any buffers) have > already been destroyed. Several parts of Postfix do connect() write() close(). This bug in FreeBSD happens when the server calls accept() after the client has close()d the connection. This bug in FreeBSD introduces a race condition where the result of connect() write() close() depends on how quickly the server can call accept(). This bug in FreeBSD causes loss of data, because the client has received success returns from write() and close(). I request that this bug in FreeBSD be fixed. Wietse To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 13:28:35 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 4D39937B71B for ; Wed, 7 Mar 2001 13:28:32 -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 f27Lubh30243; Wed, 7 Mar 2001 15:56:37 -0600 (CST) (envelope-from nick@rogness.net) Date: Wed, 7 Mar 2001 15:56:37 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Peter Brezny Cc: freebsd-net@FreeBSD.ORG Subject: Re: natd - static nat on multiple aliased ip's 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 Wed, 7 Mar 2001, Nick Rogness wrote: ACK! Read your message wrong...let me clarify. > On Wed, 7 Mar 2001, Peter Brezny wrote: > > > > > Let's say I had two internal subnets that i'd like to nat with different > > external ip's, while also doing static nat on one of each of the internal > > ip's. Could i do that by doing something like thils: > > > > rc.conf > > natd_flags="-f /etc/natd.conf1" > > natd_flags="-f /etc/natd.conf2" > > > Only the second line above will get executed. > Run the 2nd natd in /etc/rc.local. > > > > rc.firewall > > $fwcmd add divert 8668 all from 10.1.1.1/24 to any via $oif > > $fwcmd add divert 8669 all from 10.1.2.1/24 to any via $oif > > > > The second rule will never get hit because the packets will only > get divert through the first divert rule. > This was wrong. I didn't note the "2" in 10.1.2.1! Yes this setup is fine. > > natd.conf1 > > port 8668 > > interface fxp0 > > dynamic yes > > alias_address external_ip_1 > > redirect_address 10.1.1.4 external_ip_1 > > > > natd.conf2 > > port 8668 > > interface fxp0 > > dynamic yes > > alias_address external_ip_2 > > redirect_address 10.1.2.4 external_ip_2 > > > > The port statement on the second set is the same as the > first. The above configs look OK...sorry for the confusion. 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 Wed Mar 7 13:30: 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 6BDC937B71A for ; Wed, 7 Mar 2001 13:29:58 -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 f27Lw5Q30335; Wed, 7 Mar 2001 15:58:05 -0600 (CST) (envelope-from nick@rogness.net) Date: Wed, 7 Mar 2001 15:58:05 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Peter Brezny Cc: freebsd-net@FreeBSD.ORG Subject: Re: natd - static nat on multiple aliased ip's 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 Wed, 7 Mar 2001, Nick Rogness wrote: ACK! I read your email wrong. I responded with the correct reply...please void the message below. > > > > Won't your example below show all outbound traffic from the same > > external ip, the ip that natd uses? > > > > Yes and No, if the internal machine does not have a > redirect_address statement in natd.conf then it will use the > global interface or alias address outside the firewall. If > redirect_address is used then the internal address carries > redirect_address mapped external address when it goes outside the > firewall. > > > I'd like to have the outbound traffic from internal range a.a.a.a have > > one external ip and the outbound traffic from internal range b.b.b.b > > have another external ip. > Um, you can...but it is very complex with one interface. I'll try > to explain why. Packets arrive and get translated to inside > addresses...everything fine at this point...packet gets delivered > to the inside machine...still no problem...but how does the > packet on the return from the internal machine know which address > to translate to when leaving the machine? Usually, it is > seperate interface, which the ipfw divert rule is running on...and > even then it is very tricky. > > If you search the archives back a couple of days, I gave an > exmaple of how you would approach a problem like this. > > > 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 > 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 Wed Mar 7 13:45:29 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 EF56837B718 for ; Wed, 7 Mar 2001 13:45:26 -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 QAA82378; Wed, 7 Mar 2001 16:45:16 -0500 (EST) (envelope-from wollman) Date: Wed, 7 Mar 2001 16:45:16 -0500 (EST) From: Garrett Wollman Message-Id: <200103072145.QAA82378@khavrinen.lcs.mit.edu> To: spe@bsdfr.org Cc: freebsd-net@FreeBSD.ORG Subject: perhaps an updating local route problem when you delete an IPv4 alias In-Reply-To: <20010307123516.GJB433.frmta01@cha213245067102.chello.fr> References: <20010307123516.GJB433.frmta01@cha213245067102.chello.fr> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > A problem of updating route appears when you delete the IPv4 alias on the > interface like this: > # ifconfig xl0 delete 172.16.1.2 netmask 255.255.255.255 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 172.16 link#1 UC 0 0 xl0 => > 172.16.1.2 0:50:da:66:aa:87 UHLW 0 4 lo0 => Hmmm. That's an interesting bug. I think I understand how it happens, too. What happens when you do a `route get 172.16.1.2'? I have a suspicion that it will come with an RTA_IFA pointing to 172.16.1.1 rather than 172.16.1.2. This would cause in_ifadown() to ignore that route when the 172.16.1.2 interface address is deleted. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 15:10:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 5BA2C37B71A for ; Wed, 7 Mar 2001 15:10:15 -0800 (PST) (envelope-from tim@futuresouth.com) Received: (from tim@localhost) by shell.futuresouth.com (8.11.1/8.11.1) id f27NA9v26200 for freebsd-net@FreeBSD.ORG; Wed, 7 Mar 2001 17:10:09 -0600 (CST) Date: Wed, 7 Mar 2001 17:10:09 -0600 From: Tim To: freebsd-net@FreeBSD.ORG Subject: Intel (fxp) replacement Message-ID: <20010307171009.A25939@futuresouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Now that the fxp driver seems to be outdated, what is recommended for those us that build servers on a regular basis? It's a shame, the Intel cards generally work best under Windoze as well and I hate to start buying different types of cards. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 15:31:52 2001 Delivered-To: freebsd-net@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 5F70137B71A for ; Wed, 7 Mar 2001 15:31:50 -0800 (PST) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.9.0/8.8.7) with ESMTP id XAA02782 for ; Wed, 7 Mar 2001 23:31:44 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Wed, 7 Mar 2001 23:31:44 +0000 (GMT) From: "E.B. Dreger" To: freebsd-net@FreeBSD.ORG Subject: Re: Intel (fxp) replacement In-Reply-To: <20010307171009.A25939@futuresouth.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 > Date: Wed, 7 Mar 2001 17:10:09 -0600 > From: Tim > > Now that the fxp driver seems to be outdated, what is recommended for > those us that build servers on a regular basis? It's a shame, the Intel > cards generally work best under Windoze as well and I hate to start > buying different types of cards. Tulip :-) D-Link DFE-570TX are 32-bit four-port 21143TD cards for about $150. IIRC, the Kingston KNE-100TX is a [single-port] Tulip, too. Znyx, Adaptec, and some others have four-port Tulips as well; some of them are 64-bit cards. Not sure about single-port cards... Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet / EternalCommerce Division E-Mail: eddy@everquick.net Phone: (316) 794-8922 --------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Mar 7 15:38: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 9E31B37B718 for ; Wed, 7 Mar 2001 15:38:36 -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 SAA83209; Wed, 7 Mar 2001 18:38:34 -0500 (EST) (envelope-from wollman) Date: Wed, 7 Mar 2001 18:38:34 -0500 (EST) From: Garrett Wollman Message-Id: <200103072338.SAA83209@khavrinen.lcs.mit.edu> To: Tim Cc: freebsd-net@FreeBSD.ORG Subject: Intel (fxp) replacement In-Reply-To: <20010307171009.A25939@futuresouth.com> References: <20010307171009.A25939@futuresouth.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Now that the fxp driver seems to be outdated, Eh? What's ``outdated'' about it? -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 7 15:41:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id 8931D37B718 for ; Wed, 7 Mar 2001 15:41:34 -0800 (PST) (envelope-from tim@futuresouth.com) Received: (from tim@localhost) by shell.futuresouth.com (8.11.1/8.11.1) id f27NfMg29664; Wed, 7 Mar 2001 17:41:23 -0600 (CST) Date: Wed, 7 Mar 2001 17:41:22 -0600 From: Tim To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Subject: Re: Intel (fxp) replacement Message-ID: <20010307174122.A29600@futuresouth.com> References: <20010307171009.A25939@futuresouth.com> <200103072338.SAA83209@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: <200103072338.SAA83209@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Wed, Mar 07, 2001 at 06:38:34PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Apparently lack of support for newer cards. See the thread on -hackers. Tim On Wed, Mar 07, 2001 at 06:38:34PM -0500, Garrett Wollman wrote: > < said: > > > Now that the fxp driver seems to be outdated, > > Eh? What's ``outdated'' about it? > > -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 7 18:38:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by hub.freebsd.org (Postfix) with ESMTP id E712737B719 for ; Wed, 7 Mar 2001 18:38:34 -0800 (PST) (envelope-from mike@sentex.net) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.2/8.11.1) with SMTP id f282cVc29291; Wed, 7 Mar 2001 21:38:32 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Cc: freebsd-net@FreeBSD.ORG Subject: Re: Intel (fxp) replacement Date: Wed, 07 Mar 2001 21:38:31 -0500 Message-ID: References: <20010307171009.A25939@futuresouth.com> 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 7 Mar 2001 18:38:44 -0500, in sentex.lists.freebsd.net you wrote: >< said: > >> Now that the fxp driver seems to be outdated,=20 > >Eh? What's ``outdated'' about it? Some of the newer revs are not supported / recognized. Also, there is = the flow control issue with some switches that result in SCB timeout errors. There were patches posted, but have not been committed. Lugi@FreeBSD.org also raised an issue with smaller packets not being able to forward at = full rate. There are also some VLAN patches that would be nice to see integrated. ---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 Wed Mar 7 19:52:36 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 48DE337B718 for ; Wed, 7 Mar 2001 19:52:34 -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 MAA06253; Thu, 8 Mar 2001 12:52:31 +0900 (JST) To: wietse@porcupine.org (Wietse Venema) Cc: Jonathan Lemon , Arjan.deVet@adv.iae.nl, net@freebsd.org, postfix-users@postfix.org In-reply-to: wietse's message of Wed, 07 Mar 2001 16:20:35 EST. <20010307212035.8170EBC070@spike.porcupine.org> 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: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] From: itojun@iijlab.net Date: Thu, 08 Mar 2001 12:52:31 +0900 Message-ID: <6251.984023551@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Several parts of Postfix do: connect() write() close(), where the >close() may happen before the server has accept()ed the connection. >Due to an incompatible change in FreeBSD 4.2-STABLE, this causes >accept() after close() to fail. The already written data is lost. >This is a bad incompatible change. see SUSv2 and XNET 5.2 spec for accept(), and Stevens (unix network programming vol 1 2nd ed) section 5.11. http://www.opengroup.org/onlinepubs/007908799/xns/accept.html 4.3BSD behavior was very wrong (described in Stevens). old freebsd behavior (return 0-length sockaddr) was also wrong, it kills a set of applications including sendmail and BIND910. new freebsd behavior (ECONNABORTED) is at least SUSv2 conformant, and I expect it to be the behavior of other stacks. 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 7 20: 8:36 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 7A32C37B718 for ; Wed, 7 Mar 2001 20:08:33 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f28465855000; Wed, 7 Mar 2001 22:06:05 -0600 (CST) (envelope-from jlemon) Date: Wed, 7 Mar 2001 22:06:05 -0600 From: Jonathan Lemon To: itojun@iijlab.net Cc: Wietse Venema , Jonathan Lemon , Arjan.deVet@adv.iae.nl, net@freebsd.org, postfix-users@postfix.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010307220605.Q41963@prism.flugsvamp.com> References: <20010307212035.8170EBC070@spike.porcupine.org> <6251.984023551@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <6251.984023551@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 08, 2001 at 12:52:31PM +0900, itojun@iijlab.net wrote: > > >Several parts of Postfix do: connect() write() close(), where the > >close() may happen before the server has accept()ed the connection. > >Due to an incompatible change in FreeBSD 4.2-STABLE, this causes > >accept() after close() to fail. The already written data is lost. > >This is a bad incompatible change. > > see SUSv2 and XNET 5.2 spec for accept(), and Stevens (unix network > programming vol 1 2nd ed) section 5.11. > http://www.opengroup.org/onlinepubs/007908799/xns/accept.html > > 4.3BSD behavior was very wrong (described in Stevens). > > old freebsd behavior (return 0-length sockaddr) was also wrong, > it kills a set of applications including sendmail and BIND910. > > new freebsd behavior (ECONNABORTED) is at least SUSv2 conformant, > and I expect it to be the behavior of other stacks. The crucial part of Wietse's message (which he didn't mention in the first email) is that he's using this setup on unix-domain sockets. These probably have semantics which are slightly different. I believe the correct thing to do at this point is push the IS_DISCONNECTED test down to each protocol's accept routine, instead of short-circuiting it in soaccept. It looks like the short-circuit test was added in uipc_socket.c:1.41 in the NetBSD sources, which we brought over. I'm not sure why this test is actually needed, though. -- 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 7 20:26:46 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 23C6837B718 for ; Wed, 7 Mar 2001 20:26:39 -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 PAA20085; Thu, 8 Mar 2001 15:24:39 +1100 (EST) Received: by MELEXC01 with Internet Mail Service (5.5.2448.0) id ; Thu, 8 Mar 2001 15:25:12 +1100 Message-ID: <710709BB8B02D311942E006067441810544287@MELEXC01> From: Murray Taylor To: "'Stephen Cimarelli'" Cc: "'freebsd-net@freebsd.org'" Subject: RE: Firewalls and Samba Date: Thu, 8 Mar 2001 15:24:09 +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 It aint the firewall!! Further to default routes etc ..... I believe that I have cured the problem (final testing after the network number shift to the 10.x.y.z range and I connect the phone line!) Factoids: A Windoze computers on the network are given IP numbers via DHCP from an NT Server these include such things as the machine IP number WINS server IP numbers, the DHCP server number, the subnet mask and a default gateway B our company network has (for the convenience of the R&D noddies) a gateway defined into their internal - internal development network...which protects us from it too ;-) This gateway is the one distributed via DHCP above. C I didnt (and still dont) have all the company IP #'s in the hosts table or the named tables. ( I've only got the 5 or so that I am directly dealing with for our web development ) D ppp was starting up with the "set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.255" and "add default HISADDR" lines which of course setup a default route in the FreeBSD box E Samba is running on the FreeBSD box to allow W9x machines access certain shares F ipfw is up and running with a bunch of rules including "1100 deny ip from 10.0.0.0/0 to any via tun0" Result: M$ Explorer, when attempting to map the networked shares to a machine booting up encounters the Samba shares, and then it seems that somewhere M$ Explorer and /or Samba get bent out of shape by the default route on the FBSD box and tries to use it (for what I dont know). One then has to cancel the attempt to attach the shares or wait for the error "I cant do this" popup dialog. When the M$ machine has finished booting, going into Explorer and attempting to open the unattached shares, returns (eventually) the informative message that the "device is not attached to the network".... Mind you I am into the FreeBSD machine with telnet, can open a website on it via IE5 and can ping it to my hearts content... THE SOLUTION I think! remove the add default line from ppp.conf add it to the ppp.linkup file add a matching delete all line to ppp.linkdown and forgo auto dialling as there is not a default route pointing to the tun0 device until it is open (catch 22) I'm still not sure if there is a bug lurking in one side or the other here, and if this is just a work around or if this is the 'correct' way of doing things cheers and thanks (Stephen in particular) Murray Taylor Project Engineer Bytecraft P/L +61 3 9587 2555 +61 3 9587 1614 fax mtaylor@bytecraft.com.au > -----Original Message----- > From: Stephen Cimarelli [SMTP:stephen@clari.net.au] > Sent: Wednesday, 7 March 2001 11:51 > To: Murray Taylor > Subject: RE: Firewalls and Samba > > but why was the outside interface afecting internal trafic, was it because > of > the defoult route? > > > I would have thought that rule 150 should have done the job? > > > > > On 06-Mar-01 Murray Taylor wrote: > > yah, > > but that line is also one of the 'standard' lines in the SIMPLE firewall > > entry in rc.firewall > > and the 'standard' ppp setup for auto mode > > has this line > > > > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 > > > > in it, which I am using too.... > > > > mjt > > > >> > ---------------------------------- > E-Mail: Stephen Cimarelli > Date: 07-Mar-01 > Time: 10:45:21 > ClariNet Internet Solutions > +61 3 9486 0811 > www.clari.net.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 8 1:48:29 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 53AF137B718; Thu, 8 Mar 2001 01:48:11 -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 LAA84667; Thu, 8 Mar 2001 11:47:45 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: "FreeBSD Network List" , "FreeBSD IPFW List" Subject: FW: MS Shares through IPFW Date: Thu, 8 Mar 2001 11:47:45 +0200 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all! I need to allow some M$ clients to access M$ shares on an NT server, the clients and server being on opposite sides of a FreeBSD ipfw firewall. The firewall is running fine (has been for 6 months) but I cannot get this D**N Netbios stuff going. In my desperation I have gone as far as adding these two very loose rules, which are the very first rules in the ipfw chain: -------- /sbin/ipfw -q add 00009 allow log ip from 10.5.5.0/24 to 10.3.3.240 /sbin/ipfw -q add 00009 allow log ip from 10.3.3.240 to 10.5.5.0/24 -------- The 10.5.5.0/24 Subnet includes the client we are testing, and 10.3.3.240 is the NT Server. The 10.5.5.0/24 Subnet is remote across a VPN, but there are IP tunnels in place so that the extra hops are transparent -> I don't THINK they should be causing our problems. When the Client tries to map the share on the Server there is a whole bunch of traffic logged against rule #9, including ports UDP 137 and TCP 139, going back and forth between the client and server. The client is prompted for a login/password, which we enter VERY CAREFULLY to make sure we got it right, but thereafter the connection is refused. Is this something about M$ security, or is there something else I am not seeing that the firewall might be denying? The only curious thing I have observed is the following lines in the ipfw.log interspersed among all the "Accept" logs between these computers: -------- Mar 7 11:16:08 eccles /kernel: ipfw: 65534 Deny UDP 0.0.0.0:68 10.3.3.240:67 in via rl2 Mar 7 11:16:08 eccles /kernel: ipfw: 9 Accept UDP 10.5.5.1:67 10.3.3.240:67 in via rl2 Mar 7 11:16:08 eccles /kernel: ipfw: 9 Accept UDP 10.5.5.1:67 10.3.3.240:67 out via rl0 -------- I believe ports 67 and 68 are used for DHCP - we are not using DHCP anywhere, so I don't understand why this pops up, but I include it as it may be relevant ?!? Also, why is the source IP on the first line 0.0.0.0 ? Anyone with some more M$ / Netbios expertise - PLEASE HELP. Thanks, Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 2:27: 8 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 DCCD537B71A; Thu, 8 Mar 2001 02:27:02 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 4CA9D81D18; Thu, 8 Mar 2001 04:26:52 -0600 (CST) Date: Thu, 8 Mar 2001 04:26:52 -0600 From: Bill Fumerola To: Patrick O'Reilly Cc: FreeBSD Network List , FreeBSD IPFW List Subject: Re: FW: MS Shares through IPFW Message-ID: <20010308042652.Q31752@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 patrick@mip.co.za on Thu, Mar 08, 2001 at 11:47:45AM +0200 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 08, 2001 at 11:47:45AM +0200, Patrick O'Reilly wrote: > In my desperation I have gone as far as adding these two very loose rules, > which are the very first rules in the ipfw chain: > -------- > /sbin/ipfw -q add 00009 allow log ip from 10.5.5.0/24 to 10.3.3.240 > /sbin/ipfw -q add 00009 allow log ip from 10.3.3.240 to 10.5.5.0/24 > -------- > > The 10.5.5.0/24 Subnet includes the client we are testing, and 10.3.3.240 is > the NT Server. The 10.5.5.0/24 Subnet is remote across a VPN, but there are > IP tunnels in place so that the extra hops are transparent -> I don't THINK > they should be causing our problems. "Transparent" hops wouldn't be the problem. IP packets coming across the wire don't know the difference, neither does ipfw. > When the Client tries to map the share on the Server there is a whole bunch > of traffic logged against rule #9, including ports UDP 137 and TCP 139, > going back and forth between the client and server. The client is prompted > for a login/password, which we enter VERY CAREFULLY to make sure we got it > right, but thereafter the connection is refused. If the client is prompted for a login/password it would seem that a connection has been established (and the firewall doesn't seem to be the problem). If you REALLY want to know what makes this windows crap tick, put the two clients on the same subnet (on a hub, that makes this easy) and make your connection and have a sniffer like tcpdump or (if you're running X) ethereal. You'll get the entire picture and know exactly what rules to write instead of bogusly allowing * (if protecting those subnets is a goal). > -------- > Mar 7 11:16:08 eccles /kernel: ipfw: 65534 Deny UDP 0.0.0.0:68 > 10.3.3.240:67 in via rl2 > > I believe ports 67 and 68 are used for DHCP - we are not using DHCP > anywhere, so I don't understand why this pops up, but I include it as it may > be relevant ?!? Also, why is the source IP on the first line 0.0.0.0 ? What is the IP of a machine that has no IP (hint: and is looking for one..)? -- 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 Thu Mar 8 3:37:38 2001 Delivered-To: freebsd-net@freebsd.org Received: from msexchange.alx.unitedway.org (msmail.unitedway.org [38.204.190.251]) by hub.freebsd.org (Postfix) with ESMTP id BA51637B718; Thu, 8 Mar 2001 03:37:33 -0800 (PST) (envelope-from Johnny.Dang@msmail.unitedway.org) Received: by msmail.unitedway.org with Internet Mail Service (5.5.2650.21) id <1080MXH7>; Thu, 8 Mar 2001 06:38:15 -0500 Message-ID: From: Johnny.Dang@msmail.unitedway.org To: patrick@mip.co.za, freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: RE: MS Shares through IPFW Date: Thu, 8 Mar 2001 06:38:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A7C4.42DACABC" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A7C4.42DACABC Content-Type: text/plain; charset="iso-8859-1" Hi Patrick, Another issue here is the workgroup of the NT/Win PCs. You will have to set all PCs in the same workgroup named such as MYWORKGROUP, plus do you use authentication at all? Is your NT network in a peer-to-peer or domain schema? I hope this help. ------_=_NextPart_001_01C0A7C4.42DACABC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MS Shares through IPFW

Hi Patrick,

Another issue here is the workgroup of the NT/Win = PCs. You will have to set all PCs in the same workgroup named such as = MYWORKGROUP, plus do you use authentication at all? Is your NT network = in a peer-to-peer or domain schema? I hope this help.

------_=_NextPart_001_01C0A7C4.42DACABC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 5:52:17 2001 Delivered-To: freebsd-net@freebsd.org Received: from srv13-poa.poa.terra.com.br (srv13-poa.poa.zaz.com.br [200.248.149.91]) by hub.freebsd.org (Postfix) with ESMTP id 467A437B718; Thu, 8 Mar 2001 05:51:56 -0800 (PST) (envelope-from rafael.tonin@terra.com.br) Received: from srv8-poa.poa.terra.com.br (srv8-poa.poa.terra.com.br [200.248.149.15]) by srv13-poa.poa.terra.com.br (8.9.3/8.9.3) with ESMTP id KAA12451; Thu, 8 Mar 2001 10:51:55 -0300 Received: from bohr (dl-tnt7-C8B01462.poa.terra.com.br [200.176.20.98]) by srv8-poa.poa.terra.com.br (8.11.0/8.11.1) with SMTP id f28Dpl200510; Thu, 8 Mar 2001 10:51:47 -0300 Message-ID: <003901c0a7d7$91b465e0$6214b0c8@bohr> From: "Rafael Tonin" To: Cc: Subject: Intel PRO/100+ PCI problem Date: Thu, 8 Mar 2001 10:56:26 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C0A7BE.6BD7BF20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C0A7BE.6BD7BF20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 Anyone knows how to get this card to work? Really Thanks, Rafael Tonin Below is a copy of my dmesg: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-RELEASE #0: Mon Nov 20 13:02:55 GMT 2000 jkh@bento.FreeBSD.org:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (267.60-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x634 Stepping =3D 4 = Features=3D0x80f9ff real memory =3D 268419072 (262128K bytes) config> di sn0 config> di lnc0 config> di ie0 config> di fe0 config> di ed0 config> di cs0 config> di bt0 config> di aic0 config> di aha0 config> di adv0 config> q avail memory =3D 257069056 (251044K bytes) Preloaded elf kernel "kernel" at 0xc0436000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc043609c. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib2: at device 1.0 = on pci0 pci1: on pcib2 pci1: at 0.0 irq 11 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 4.1 = on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xd400-0xd41f irq 10 at device = 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.14, addr = 2, iclass 3/1 ums0: 5 buttons and Z dir. pci0: (vendor=3D0x1102, dev=3D0x0002) at 9.0 pci0: (vendor=3D0x1102, dev=3D0x7002) at 9.1 fxp0: at device 13.0 on pci0 fxp0: could not map memory device_probe_and_attach: fxp0 attach returned 6 pcib1: on motherboard pci2: on pcib1 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on = isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: MLC,PCL,PML plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio4: at port 0x3e8-0x3ef irq 5 on isa0 sio4: type 16550A ad0: 14324MB [29104/16/63] at ata0-master = UDMA66 afd0: 239MB [239/64/32] at ata0-slave = using PIO3 acd0: CDROM at ata1-master using PIO4 acd1: CD-RW at ata1-slave using = PIO4 Mounting root from ufs:/dev/ad0s2a ------=_NextPart_000_0036_01C0A7BE.6BD7BF20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm having some problems on configuring = my just=20 purchased Intel PRO/100+ PCI (reported by Intel as being P#:=20 689661-004).
 
When booting, FreeBSD 4.2 = reports:
 
fxp0: <Intel Pro 10/100B/100+ = Ethernet> at=20 device 13.0 on pci0
fxp0: could not map memory
 
Anyone knows how to get this card to=20 work?
 
Really Thanks,
 
Rafael Tonin
 
Below is a copy of my = dmesg:
 
Copyright (c) 1992-2000 The FreeBSD=20 Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, = 1992, 1993,=20 1994
 The Regents of the University of California. All rights=20 reserved.
FreeBSD 4.2-RELEASE #0: Mon Nov 20 13:02:55 GMT=20 2000
    jkh@be= nto.FreeBSD.org:/usr/src/sys/compile/GENERIC
Timecounter=20 "i8254"  frequency 1193182 Hz
CPU: Pentium II/Pentium II = Xeon/Celeron=20 (267.60-MHz 686-class CPU)
  Origin =3D "GenuineIntel"  Id = =3D=20 0x634  Stepping =3D 4
 =20 Features=3D0x80f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MC= A,CMOV,MMX>
real=20 memory  =3D 268419072 (262128K bytes)
config> di = sn0
config> di=20 lnc0
config> di ie0
config> di fe0
config> di=20 ed0
config> di cs0
config> di bt0
config> di=20 aic0
config> di aha0
config> di adv0
config> = q
avail memory=20 =3D 257069056 (251044K bytes)
Preloaded elf kernel "kernel" at=20 0xc0436000.
Preloaded userconfig_script "/boot/kernel.conf" at=20 0xc043609c.
Pentium Pro MTRR support enabled
md0: Malloc = disk
npx0:=20 <math processor> on motherboard
npx0: INT 16 = interface
pcib0:=20 <Host to PCI bridge> on motherboard
pci0: <PCI bus> on=20 pcib0
pcib2: <VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> = at=20 device 1.0 on pci0
pci1: <PCI bus> on pcib2
pci1: <NVidia = GeForce2 GTS graphics accelerator> at 0.0 irq 11
isab0: <VIA = 82C596B=20 PCI-ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on=20 isab0
atapci0: <VIA 82C596 ATA66 controller> port 0xd800-0xd80f = at=20 device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 = irq 15=20 on atapci0
uhci0: <VIA 83C572 USB controller> port = 0xd400-0xd41f irq 10=20 at device 4.2 on pci0
usb0: <VIA 83C572 USB controller> on=20 uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, = rev=20 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self = powered
ums0:=20 Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.14, addr 2, = iclass=20 3/1
ums0: 5 buttons and Z dir.
pci0: <unknown card> = (vendor=3D0x1102,=20 dev=3D0x0002) at 9.0
pci0: <unknown card> (vendor=3D0x1102, = dev=3D0x7002) at=20 9.1
fxp0: <Intel Pro 10/100B/100+ Ethernet> at device 13.0 on=20 pci0
fxp0: could not map memory
device_probe_and_attach: fxp0 = attach=20 returned 6
pcib1: <Host to PCI bridge> on motherboard
pci2: = <PCI=20 bus> on pcib1
fdc0: <NEC 72065B or clone> at port = 0x3f0-0x3f5,0x3f7=20 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: = <1440-KB=20 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller = (i8042)>=20 at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 = on=20 atkbdc0
kbd0 at atkbd0
vga0: <Generic ISA VGA> at port = 0x3c0-0x3df=20 iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags = 0x100 on=20 isa0
sc0: VGA <16 virtual consoles, flags=3D0x300>
sio0 at = port=20 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at = port=20 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel = port> at=20 port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset = (ECP/EPP/PS2/NIBBLE) in=20 COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
ppbus0: = IEEE1284=20 device found /NIBBLE/ECP
Probing for PnP devices on = ppbus0:
ppbus0:=20 <HEWLETT-PACKARD DESKJET 640C> MLC,PCL,PML
plip0: <PLIP = network=20 interface> on ppbus0
lpt0: <Printer> on ppbus0
lpt0:=20 Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
sio4: = <U.S.=20 Robotics 56K Voice INT> at port 0x3e8-0x3ef irq 5 on isa0
sio4: = type=20 16550A
ad0: 14324MB <QUANTUM FIREBALLlct10 15> [29104/16/63] at = ata0-master UDMA66
afd0: 239MB <IOMEGA ZIP 250 ATAPI Floppy>=20 [239/64/32] at ata0-slave using PIO3
acd0: CDROM <SONY CD-ROM = CDU4821>=20 at ata1-master using PIO4
acd1: CD-RW <Hewlett-Packard CD-Writer = Plus=20 8200> at ata1-slave using PIO4
Mounting root from=20 ufs:/dev/ad0s2a
------=_NextPart_000_0036_01C0A7BE.6BD7BF20-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 6:22: 0 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 A4B9537B71A; Thu, 8 Mar 2001 06:21:35 -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 QAA90760; Thu, 8 Mar 2001 16:21:24 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: "FreeBSD Network List" , "FreeBSD IPFW List" Subject: RE: FW: MS Shares through IPFW Date: Thu, 8 Mar 2001 16:21:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-reply-to: <20010308042652.Q31752@elvis.mu.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org FIXED !!! Thanks to you all (Bill, Blair and Johnny) for your help. It turns out the problem was not at the transport level at all (seriously red face now!) The login and password was the issue - Since the clients and server are not on the same windows NT domain, the NT server was validating the login against local users, not against users registered on the NT PDC. I have had a local user added to the NT server for the purpose of this connection, given the user access to the share AND the NTFS directories and files, and now it works just fine. PS: I have tightened the firewall rules to: > -------- > /sbin/ipfw -q add 00009 allow tcp from 10.5.5.0/24 to 10.3.3.240 139 > /sbin/ipfw -q add 00009 allow tcp from 10.3.3.240 139 to 10.5.5.0/24 > -------- and it works that way. This might help the next person trying to do the same thing... I'm still getting DHCP stuff floating about, but I'm sure that is another issue altogether... Thanks again, Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 7:38:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by hub.freebsd.org (Postfix) with ESMTP id 8547337B719 for ; Thu, 8 Mar 2001 07:38:18 -0800 (PST) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id 25296BC06D; Thu, 8 Mar 2001 10:38:17 -0500 (EST) Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <20010307220605.Q41963@prism.flugsvamp.com> "from Jonathan Lemon at Mar 7, 2001 10:06:05 pm" To: Jonathan Lemon Date: Thu, 8 Mar 2001 10:38:17 -0500 (EST) Cc: itojun@iijlab.net, Wietse Venema , Arjan.deVet@adv.iae.nl, net@freebsd.org, postfix-users@postfix.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010308153817.25296BC06D@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If the result of connect() write() close() depends on whether accept() happens after or before close(), then the behavior is broken. The client has received a successful return from write() and close(). The system is not supposed to lose the data, period. This race condition did not exist with UNIX-domain sockets on FreeBSD <= 4.2-RELEASE. It was introduced recently. If such behavior is required by standards (i.e. write() and close() succeed, but data is lost because accept() after close() fails) then those standards are badly, badly, broken. Wietse Jonathan Lemon: > On Thu, Mar 08, 2001 at 12:52:31PM +0900, itojun@iijlab.net wrote: > > > > >Several parts of Postfix do: connect() write() close(), where the > > >close() may happen before the server has accept()ed the connection. > > >Due to an incompatible change in FreeBSD 4.2-STABLE, this causes > > >accept() after close() to fail. The already written data is lost. > > >This is a bad incompatible change. > > > > see SUSv2 and XNET 5.2 spec for accept(), and Stevens (unix network > > programming vol 1 2nd ed) section 5.11. > > http://www.opengroup.org/onlinepubs/007908799/xns/accept.html > > > > 4.3BSD behavior was very wrong (described in Stevens). > > > > old freebsd behavior (return 0-length sockaddr) was also wrong, > > it kills a set of applications including sendmail and BIND910. > > > > new freebsd behavior (ECONNABORTED) is at least SUSv2 conformant, > > and I expect it to be the behavior of other stacks. > > > The crucial part of Wietse's message (which he didn't mention in > the first email) is that he's using this setup on unix-domain sockets. > These probably have semantics which are slightly different. > > I believe the correct thing to do at this point is push the > IS_DISCONNECTED test down to each protocol's accept routine, > instead of short-circuiting it in soaccept. It looks like the > short-circuit test was added in uipc_socket.c:1.41 in the NetBSD > sources, which we brought over. I'm not sure why this test is > actually needed, though. > -- > Jonathan > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 8: 1:50 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 0F7C337B71E for ; Thu, 8 Mar 2001 08:01:43 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f28Fvx977665; Thu, 8 Mar 2001 09:57:59 -0600 (CST) (envelope-from jlemon) Date: Thu, 8 Mar 2001 09:57:59 -0600 From: Jonathan Lemon To: Wietse Venema Cc: Jonathan Lemon , itojun@iijlab.net, Arjan.deVet@adv.iae.nl, net@freebsd.org, postfix-users@postfix.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010308095759.S41963@prism.flugsvamp.com> References: <20010307220605.Q41963@prism.flugsvamp.com> <20010308153817.25296BC06D@spike.porcupine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010308153817.25296BC06D@spike.porcupine.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote: > If the result of connect() write() close() depends on whether > accept() happens after or before close(), then the behavior is > broken. The client has received a successful return from write() > and close(). The system is not supposed to lose the data, period. What you seem to be missing here is that the behavior described above is ONLY specific to UNIX-DOMAIN sockets. The description above is generally (but not always) true for the TCP/IP protocol. Data CAN be lost if the TCP connection is RST. It has nothing to do with the ordering of accept() with respect to close(). -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 10: 0:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by hub.freebsd.org (Postfix) with ESMTP id DAA7837B718 for ; Thu, 8 Mar 2001 10:00:49 -0800 (PST) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id CC09DBC06D; Thu, 8 Mar 2001 13:00:48 -0500 (EST) Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: <20010308095759.S41963@prism.flugsvamp.com> "from Jonathan Lemon at Mar 8, 2001 09:57:59 am" To: Jonathan Lemon Date: Thu, 8 Mar 2001 13:00:48 -0500 (EST) Cc: Wietse Venema , itojun@iijlab.net, Arjan.deVet@adv.iae.nl, net@freebsd.org, postfix-users@postfix.org X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010308180048.CC09DBC06D@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Lemon: > On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote: > > If the result of connect() write() close() depends on whether > > accept() happens after or before close(), then the behavior is > > broken. The client has received a successful return from write() > > and close(). The system is not supposed to lose the data, period. > > What you seem to be missing here is that the behavior described > above is ONLY specific to UNIX-DOMAIN sockets. The description > above is generally (but not always) true for the TCP/IP protocol. The problem is observed with UNIX-domain sockets. > Data CAN be lost if the TCP connection is RST. It has nothing to > do with the ordering of accept() with respect to close(). Please educate me: how would RST come into this discussion at all? The client does connect() write() close(), there is no forced connection termination involved at all. Wietse To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 11:34:44 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 B6A1237B71C for ; Thu, 8 Mar 2001 11:34:40 -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 f28JYei01344; Thu, 8 Mar 2001 11:34:40 -0800 (PST) (envelope-from yushunwa@amc.isi.edu) Date: Thu, 8 Mar 2001 11:34:40 -0800 (PST) From: Yu-Shun Wang To: Cc: Yu-Shun Wang Subject: Strong vs. Weak ES models? 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, Has the topic of Strong/Weak ES model been discussed here? Please give me a pointer if the topic has been debated. I was wondering if there's a sysctl switch (like net.inet.ip.strongendsystem mentioned in NetBSD list) implemented in FreeBSD. yushun ____________________________________________________________________________ Yu-Shun Wang Information Sciences Institute University of Southern California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 13: 0:12 2001 Delivered-To: freebsd-net@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 7F7A037B718 for ; Thu, 8 Mar 2001 13:00:10 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f28Kxuw26866; Thu, 8 Mar 2001 12:59:56 -0800 From: "Jonathan Graehl" To: "Wietse Venema" Cc: "Freebsd-Net" Subject: RE: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Date: Thu, 8 Mar 2001 13:00:14 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <20010308180048.CC09DBC06D@spike.porcupine.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Data CAN be lost if the TCP connection is RST. It has nothing to > > do with the ordering of accept() with respect to close(). > > Please educate me: how would RST come into this discussion at all? > The client does connect() write() close(), there is no forced > connection termination involved at all. > > Wietse If you set the SO_LINGER socket option, a close() may generate RST and discard socket buffers/TCP state, as opposed to the standard behavior of keeping the data around and resending until the data and the FIN are acknowleged by the other end. I am not sure why this is supposed to be a good idea, though, but obviously, if you set that option, you are unconcerned about data loss, or you have already guarded against it with application-level acknowledgment. Let's agree: it is okay for accept to return an error code indicating the connection has already been terminated, so long as any data sent by the client (such that the client had every indication that it was received) is still available for the acceptor to read. -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 13:10:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 159E137B718 for ; Thu, 8 Mar 2001 13:10:15 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f28LAAw26947 for ; Thu, 8 Mar 2001 13:10:10 -0800 From: "Jonathan Graehl" To: "Freebsd-Net" Subject: RE: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Date: Thu, 8 Mar 2001 13:10:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I would like to preempt corrections to the effect that it is currently impossible for accept to return both an error code and a socket to read the data from. It sounds like there may be a bug in the behavior of accept w.r.t Unix Domain sockets. For TCP, if the client sends data, then closes with SO_LINGER sending a RST, and then the server accepts, it is appropriate to return an error code and even lose the sent data. However, if the client simply sends a FIN (indicating that it will send no more data), then the connection should definitely accept without error, since the connection is only half-closed, and the server can send data to the client (in this case of accepting a half-closed connection, for kevent, a read filter should mark EV_EOF, and a write filter should not) > Let's agree: it is okay for accept to return an error code indicating the > connection has already been terminated, so long as any data sent by the client > (such that the client had every indication that it was received) is still > available for the acceptor to read. > > -Jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 13:18:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from spike.porcupine.org (spike.porcupine.org [168.100.189.2]) by hub.freebsd.org (Postfix) with ESMTP id D432937B719 for ; Thu, 8 Mar 2001 13:18:24 -0800 (PST) (envelope-from wietse@porcupine.org) Received: by spike.porcupine.org (Postfix, from userid 1001) id EE154BC06D; Thu, 8 Mar 2001 16:18:23 -0500 (EST) Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] In-Reply-To: "from Jonathan Graehl at Mar 8, 2001 01:00:14 pm" To: Jonathan Graehl Date: Thu, 8 Mar 2001 16:18:23 -0500 (EST) Cc: Wietse Venema , Freebsd-Net X-Time-Zone: USA EST, 6 hours behind central European time X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010308211823.EE154BC06D@spike.porcupine.org> From: wietse@porcupine.org (Wietse Venema) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jonathan Graehl: > > > Data CAN be lost if the TCP connection is RST. It has nothing to > > > do with the ordering of accept() with respect to close(). > > > > Please educate me: how would RST come into this discussion at all? > > The client does connect() write() close(), there is no forced > > connection termination involved at all. > > If you set the SO_LINGER socket option, a close() may generate RST and discard > socket buffers/TCP state, as opposed to the standard behavior of keeping the > data around and resending until the data and the FIN are acknowleged by the > other end. I am not sure why this is supposed to be a good idea, though, but > obviously, if you set that option, you are unconcerned about data loss, or you > have already guarded against it with application-level acknowledgment. The discussion is about connect() write() close(). My intention is not to lose data after write() and close() return success. This is how all reasonable UNIX-domain socket implementations (*) have worked under Postfix for the past couple years. (*) This does not include Solaris UNIX-domain sockets. Postfix never worked reliably with those, and I had to use a different local IPC method for Solaris. > Let's agree: it is okay for accept to return an error code indicating the > connection has already been terminated, so long as any data sent by the client > (such that the client had every indication that it was received) is still > available for the acceptor to read. As in, accept() returns a valid descriptor AND sets errno at the same time? Why can't it just succeed, and have read() return EOF as appropriate? I mean, you don't blow away server-side buffered data whenever the client closes a socket. Wietse To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 14:19:12 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 788A637B718 for ; Thu, 8 Mar 2001 14:19:06 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f28MGB291175; Thu, 8 Mar 2001 16:16:11 -0600 (CST) (envelope-from jlemon) Date: Thu, 8 Mar 2001 16:16:11 -0600 From: Jonathan Lemon To: Wietse Venema Cc: Jonathan Lemon , itojun@iijlab.net, Arjan.deVet@adv.iae.nl, net@freebsd.org, postfix-users@postfix.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010308161611.B78851@prism.flugsvamp.com> References: <20010308095759.S41963@prism.flugsvamp.com> <20010308180048.CC09DBC06D@spike.porcupine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010308180048.CC09DBC06D@spike.porcupine.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote: > Jonathan Lemon: > > On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote: > > > If the result of connect() write() close() depends on whether > > > accept() happens after or before close(), then the behavior is > > > broken. The client has received a successful return from write() > > > and close(). The system is not supposed to lose the data, period. > > > > What you seem to be missing here is that the behavior described > > above is ONLY specific to UNIX-DOMAIN sockets. The description > > above is generally (but not always) true for the TCP/IP protocol. > > The problem is observed with UNIX-domain sockets. > > > Data CAN be lost if the TCP connection is RST. It has nothing to > > do with the ordering of accept() with respect to close(). > > Please educate me: how would RST come into this discussion at all? > The client does connect() write() close(), there is no forced > connection termination involved at all. Under normal circumstances, a connect(), write(), close() call should work. However, the code that was added was to handle the abnormal cases from the server's point of view. As you noted, this happened to break for unix-domain sockets under 4.2-stable, because of the following kernel semantics bug: + with unix-domain sockets, the connection is marked as DISCONNECTED as soon as the final close() is performed. + with TCP/IP sockets, a connection is marked "DISCONNECTING" on the final client close, but is NOT actually closed (marked as DISCONNECTED) until the server is notified that client's TCP/IP endpoint is gone. What we are trying to fix here is when the server, for some reason, happens to see the client forcibly tear down the endpoint before it can get around to to accepting the connection. From the server's point of view: + TCP/IP handshake from client, allocate protocol control blocks + receive data from client + client resets connection, pcb is destroyed Exactly why the client resets the connection isn't my concern at the moment. Some stacks may place a timeout on the FIN_WAIT state, and forcibly reset the reset the connection when the timer expires. Alternatively, the client may crash, and then RST in response to an ACK transmitted by the server. Or the other end may have set SO_LINGER, which will cause close() to send a RST. The unix-domain bug is because we were treating sockets in the DISCONNECTED state identically across all protocols, which turns out not to be the case. As for any data that already exists in the socket buffer on the server when the connection is aborted, I believe that the correct thing to do is discard it. This is the historical precedent, and is supported by the current standards. Below is a patch that will fix the behavior for unix-domain sockets. -- Jonathan Index: kern/uipc_socket.c =================================================================== RCS file: /ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.68.2.13 diff -u -r1.68.2.13 uipc_socket.c --- kern/uipc_socket.c 2001/02/26 04:23:16 1.68.2.13 +++ kern/uipc_socket.c 2001/03/08 02:34:00 @@ -360,10 +360,7 @@ if ((so->so_state & SS_NOFDREF) == 0) panic("soaccept: !NOFDREF"); so->so_state &= ~SS_NOFDREF; - if ((so->so_state & SS_ISDISCONNECTED) == 0) - error = (*so->so_proto->pr_usrreqs->pru_accept)(so, nam); - else - error = ECONNABORTED; + error = (*so->so_proto->pr_usrreqs->pru_accept)(so, nam); splx(s); return (error); } Index: netinet/tcp_usrreq.c =================================================================== RCS file: /ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.51 diff -u -r1.51 tcp_usrreq.c --- netinet/tcp_usrreq.c 2000/01/09 19:17:28 1.51 +++ netinet/tcp_usrreq.c 2001/03/08 16:21:28 @@ -417,6 +417,10 @@ struct inpcb *inp = sotoinpcb(so); struct tcpcb *tp; + if (so->so_state & SS_ISDISCONNECTED) { + error = ECONNABORTED; + goto out; + } COMMON_START(); in_setpeeraddr(so, nam); COMMON_END(PRU_ACCEPT); @@ -431,6 +435,10 @@ struct inpcb *inp = sotoinpcb(so); struct tcpcb *tp; + if (so->so_state & SS_ISDISCONNECTED) { + error = ECONNABORTED; + goto out; + } COMMON_START(); in6_mapped_peeraddr(so, nam); COMMON_END(PRU_ACCEPT); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 14:30:36 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 2684737B71A for ; Thu, 8 Mar 2001 14:30:32 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f28MUN603299; Thu, 8 Mar 2001 14:30:23 -0800 (PST) Date: Thu, 8 Mar 2001 14:30:23 -0800 From: Alfred Perlstein To: Jonathan Lemon Cc: Wietse Venema , itojun@iijlab.net, Arjan.deVet@adv.iae.nl, net@FreeBSD.ORG, postfix-users@postfix.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010308143022.E18351@fw.wintelcom.net> References: <20010308095759.S41963@prism.flugsvamp.com> <20010308180048.CC09DBC06D@spike.porcupine.org> <20010308161611.B78851@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: <20010308161611.B78851@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Mar 08, 2001 at 04:16:11PM -0600 X-all-your-base: are belong to us. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Jonathan Lemon [010308 14:19] wrote: > On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote: > > Jonathan Lemon: > > > On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote: > > > > If the result of connect() write() close() depends on whether > > > > accept() happens after or before close(), then the behavior is > > > > broken. The client has received a successful return from write() > > > > and close(). The system is not supposed to lose the data, period. > > > > > > What you seem to be missing here is that the behavior described > > > above is ONLY specific to UNIX-DOMAIN sockets. The description > > > above is generally (but not always) true for the TCP/IP protocol. > > > > The problem is observed with UNIX-domain sockets. > > > > > Data CAN be lost if the TCP connection is RST. It has nothing to > > > do with the ordering of accept() with respect to close(). > > > > Please educate me: how would RST come into this discussion at all? > > The client does connect() write() close(), there is no forced > > connection termination involved at all. > > Under normal circumstances, a connect(), write(), close() call > should work. However, the code that was added was to handle the > abnormal cases from the server's point of view. Just make sure your patch is ok with the unix file descriptor passing garbage collection code, it seems to rely on socket state to get things right. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 14:32:16 2001 Delivered-To: freebsd-net@freebsd.org Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by hub.freebsd.org (Postfix) with ESMTP id C155137B71A for ; Thu, 8 Mar 2001 14:32:12 -0800 (PST) (envelope-from barney@mx.databus.com) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f28MVR880137; Thu, 8 Mar 2001 17:31:27 -0500 (EST) (envelope-from barney) Date: Thu, 8 Mar 2001 17:31:27 -0500 From: Barney Wolff To: Wietse Venema Cc: Jonathan Graehl , Freebsd-Net Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010308173127.A80086@mx.databus.com> References: <20010308211823.EE154BC06D@spike.porcupine.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010308211823.EE154BC06D@spike.porcupine.org>; from wietse@porcupine.org on Thu, Mar 08, 2001 at 04:18:23PM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The graceful-close debate is a very old one, going back more than twenty years. X.25 and ISO-TP have non-graceful close - the close can pass data in the network and cause it to be lost. TCP is defined as graceful-close. In SVR4 TLI there are two types of stream "sockets" with graceful or ugly close semantics. Having said all that, I certainly agree with Wietse that the POLA demands that a PF-LOCAL stream socket behave like TCP. Barney Wolff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 14:34:46 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 7109837B71C for ; Thu, 8 Mar 2001 14:34:41 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f28MW8C91897; Thu, 8 Mar 2001 16:32:08 -0600 (CST) (envelope-from jlemon) Date: Thu, 8 Mar 2001 16:32:08 -0600 From: Jonathan Lemon To: Alfred Perlstein , g@flugsvamp.com Cc: Jonathan Lemon , Wietse Venema , itojun@iijlab.net, Arjan.deVet@adv.iae.nl, net@FreeBSD.ORG, postfix-users@postfix.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010308163208.C78851@prism.flugsvamp.com> References: <20010308095759.S41963@prism.flugsvamp.com> <20010308180048.CC09DBC06D@spike.porcupine.org> <20010308161611.B78851@prism.flugsvamp.com> <20010308143022.E18351@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010308143022.E18351@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 08, 2001 at 02:30:23PM -0800, Alfred Perlstein wrote: > * Jonathan Lemon [010308 14:19] wrote: > > On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote: > > > Jonathan Lemon: > > > > On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote: > > > > > If the result of connect() write() close() depends on whether > > > > > accept() happens after or before close(), then the behavior is > > > > > broken. The client has received a successful return from write() > > > > > and close(). The system is not supposed to lose the data, period. > > > > > > > > What you seem to be missing here is that the behavior described > > > > above is ONLY specific to UNIX-DOMAIN sockets. The description > > > > above is generally (but not always) true for the TCP/IP protocol. > > > > > > The problem is observed with UNIX-domain sockets. > > > > > > > Data CAN be lost if the TCP connection is RST. It has nothing to > > > > do with the ordering of accept() with respect to close(). > > > > > > Please educate me: how would RST come into this discussion at all? > > > The client does connect() write() close(), there is no forced > > > connection termination involved at all. > > > > Under normal circumstances, a connect(), write(), close() call > > should work. However, the code that was added was to handle the > > abnormal cases from the server's point of view. > > Just make sure your patch is ok with the unix file descriptor > passing garbage collection code, it seems to rely on socket state > to get things right. It doesn't change any of the socket state, nor does it touch the SS_NOFDREF flag, so the gc algorithm should be okay. Actually, all I'm doing here is pushing the decision down to each protocol, rather than short-circuiting the test at the socket layer. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 14:35: 8 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 29BEE37B728 for ; Thu, 8 Mar 2001 14:34:55 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f28MWPC91907; Thu, 8 Mar 2001 16:32:25 -0600 (CST) (envelope-from jlemon) Date: Thu, 8 Mar 2001 16:32:25 -0600 From: Jonathan Lemon To: Alfred Perlstein , g@flugsvamp.com Cc: Jonathan Lemon , Wietse Venema , itojun@iijlab.net, Arjan.deVet@adv.iae.nl, net@FreeBSD.ORG, postfix-users@postfix.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010308163208.C78851@prism.flugsvamp.com> References: <20010308095759.S41963@prism.flugsvamp.com> <20010308180048.CC09DBC06D@spike.porcupine.org> <20010308161611.B78851@prism.flugsvamp.com> <20010308143022.E18351@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010308143022.E18351@fw.wintelcom.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 08, 2001 at 02:30:23PM -0800, Alfred Perlstein wrote: > * Jonathan Lemon [010308 14:19] wrote: > > On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote: > > > Jonathan Lemon: > > > > On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote: > > > > > If the result of connect() write() close() depends on whether > > > > > accept() happens after or before close(), then the behavior is > > > > > broken. The client has received a successful return from write() > > > > > and close(). The system is not supposed to lose the data, period. > > > > > > > > What you seem to be missing here is that the behavior described > > > > above is ONLY specific to UNIX-DOMAIN sockets. The description > > > > above is generally (but not always) true for the TCP/IP protocol. > > > > > > The problem is observed with UNIX-domain sockets. > > > > > > > Data CAN be lost if the TCP connection is RST. It has nothing to > > > > do with the ordering of accept() with respect to close(). > > > > > > Please educate me: how would RST come into this discussion at all? > > > The client does connect() write() close(), there is no forced > > > connection termination involved at all. > > > > Under normal circumstances, a connect(), write(), close() call > > should work. However, the code that was added was to handle the > > abnormal cases from the server's point of view. > > Just make sure your patch is ok with the unix file descriptor > passing garbage collection code, it seems to rely on socket state > to get things right. It doesn't change any of the socket state, nor does it touch the SS_NOFDREF flag, so the gc algorithm should be okay. Actually, all I'm doing here is pushing the decision down to each protocol, rather than short-circuiting the test at the socket layer. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 21:56:38 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 576B837B71A for ; Thu, 8 Mar 2001 21:56:24 -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 OAA25800; Fri, 9 Mar 2001 14:56:21 +0900 (JST) To: Jonathan Lemon Cc: Wietse Venema , Arjan.deVet@adv.iae.nl, net@freebsd.org, postfix-users@postfix.org In-reply-to: jlemon's message of Thu, 08 Mar 2001 16:16:11 CST. <20010308161611.B78851@prism.flugsvamp.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] From: itojun@iijlab.net Date: Fri, 09 Mar 2001 14:56:21 +0900 Message-ID: <25798.984117381@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From the server's point of view: > > + TCP/IP handshake from client, allocate protocol control blocks > + receive data from client > + client resets connection, pcb is destroyed > >Exactly why the client resets the connection isn't my concern at >the moment. Some stacks may place a timeout on the FIN_WAIT state, >and forcibly reset the reset the connection when the timer expires. >Alternatively, the client may crash, and then RST in response to >an ACK transmitted by the server. Or the other end may have set >SO_LINGER, which will cause close() to send a RST. > >The unix-domain bug is because we were treating sockets in the >DISCONNECTED state identically across all protocols, which turns >out not to be the case. > >As for any data that already exists in the socket buffer on the >server when the connection is aborted, I believe that the correct >thing to do is discard it. This is the historical precedent, and >is supported by the current standards. > >Below is a patch that will fix the behavior for unix-domain sockets. from code inspection on netbsd, I guess you'd need to do something for other sys/net* families. maybe we need another per-domain/per-socket flag for this? itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 22:46:27 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 0A9A037B857 for ; Thu, 8 Mar 2001 22:46:20 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f296ihh52625; Fri, 9 Mar 2001 08:44:43 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200103090644.f296ihh52625@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak In-Reply-To: <18755.983921594@coconut.itojun.org> from "itojun@iijlab.net" at "Mar 7, 2001 08:33:14 am" To: itojun@iijlab.net Date: Fri, 9 Mar 2001 08:44:43 +0200 (SAT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > >> > will correct it. thanks for reporting. > > http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/nd6.c.diff?r1=1.135&r2=1.136 > > itojun > Any chance of this finding its way into -current and -stable (preferably before the release)? John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 23: 8:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 1DFAD37B718 for ; Thu, 8 Mar 2001 23:08:18 -0800 (PST) (envelope-from bmilekic@technokratis.com) Received: from jehovah ([24.202.203.190]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G9X55T05.D20; Fri, 9 Mar 2001 02:08:17 -0500 Message-ID: <015001c0a868$142be4e0$becbca18@jehovah> From: "Bosko Milekic" To: "John Hay" , Cc: References: <200103090644.f296ihh52625@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak Date: Fri, 9 Mar 2001 02:10:53 -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'll do it right now if itojun doesn't mind (to save him a task :-) ) and get authorization from Jordan to commit. Thanks, Bosko. John Hay wrote: > > > > >> > will correct it. thanks for reporting. > > > > http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/nd6.c.diff?r 1=1.135&r2=1.136 > > > > itojun > > > > Any chance of this finding its way into -current and -stable (preferably > before the release)? > > John > -- > John Hay -- John.Hay@icomtek.csir.co.za > > 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 8 23:11:44 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 4922137B71A for ; Thu, 8 Mar 2001 23:11:40 -0800 (PST) (envelope-from bmilekic@technokratis.com) Received: from jehovah ([24.202.203.190]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G9X5BF02.82Z; Fri, 9 Mar 2001 02:11:39 -0500 Message-ID: <015601c0a868$8cae4430$becbca18@jehovah> From: "Bosko Milekic" To: "Bosko Milekic" , "John Hay" , Cc: References: <200103090644.f296ihh52625@zibbi.icomtek.csir.co.za> <015001c0a868$142be4e0$becbca18@jehovah> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak Date: Fri, 9 Mar 2001 02:14:15 -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 Euuh, scratch that. I don't see anything committed to HEAD yet, at all. No use in MFCing something that hasn't yet been committed. :-) Bosko I wrote: > I'll do it right now if itojun doesn't mind (to save him a task :-) ) > and get authorization from Jordan to commit. > > Thanks, > Bosko. > > John Hay wrote: > > > > > > > >> > will correct it. thanks for reporting. > > > > > > > http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/nd6.c.diff?r > 1=1.135&r2=1.136 > > > > > > itojun > > > > > > > Any chance of this finding its way into -current and -stable > (preferably > > before the release)? > > > > John > > -- > > John Hay -- John.Hay@icomtek.csir.co.za > > > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Mar 8 23:14: 7 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 11DCF37B719 for ; Thu, 8 Mar 2001 23:14:05 -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) with ESMTP id QAA26823; Fri, 9 Mar 2001 16:11:47 +0900 (JST) To: "Bosko Milekic" Cc: "John Hay" , freebsd-net@FreeBSD.ORG In-reply-to: bmilekic's message of Fri, 09 Mar 2001 02:10:53 EST. <015001c0a868$142be4e0$becbca18@jehovah> 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: kernel: nd6_storelladdr failed, mbuf leak From: itojun@iijlab.net Date: Fri, 09 Mar 2001 16:11:47 +0900 Message-ID: <26821.984121907@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I'll do it right now if itojun doesn't mind (to save him a task :-) ) >and get authorization from Jordan to commit. please go ahead, i can review the diff if you want me to. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 0:59:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from sbox.tugraz.at (fstgss05.tu-graz.ac.at [129.27.3.24]) by hub.freebsd.org (Postfix) with ESMTP id BEE8E37B720 for ; Fri, 9 Mar 2001 00:59:43 -0800 (PST) (envelope-from dada@sbox.tugraz.at) Received: (from cyrus@localhost) by sbox.tugraz.at (8.11.3/8.11.3) id f298xcG19120; Fri, 9 Mar 2001 09:59:38 +0100 (MET) From: dada@sbox.tugraz.at To: freebsd-net@freebsd.org Subject: backlog of listen(2) Message-ID: <984128378.3aa89b7ab728f@sbox.tugraz.at> Date: Fri, 09 Mar 2001 09:59:38 +0100 (MET) Cc: mkamm@gmx.net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 X-Originating-IP: 129.27.43.17 X-WebMail-Company: Hotmail Killers, Inc. Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just curious: I noticed that FreeBSD and NetBSD will give you a 50% longer listen queue than what was requested with the second argument of listen(2). (You get trunc(N*3/2)+1 for backlog=N). Thus with the default SOMAXCONN of 128 (this is settable with a sysctl) we actually have a listen queue of 193 connections. (OpenBSD dropped the "divide by two" and gives you 200% more than requested.) Obviously this doesn´t break anything - it has been this way at least since BSD 4.4 Lite - but it makes me curious. Does anybody know why this was implemented other than it is documented? Btw, Linux counts exactly (gives 2*N+1) but since 2.2 only completed connections are counted. TIA, Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 2:38:36 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 91AE437B71B; Fri, 9 Mar 2001 02:38:07 -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 FAA56844; Fri, 9 Mar 2001 05:38:06 -0500 (EST) Date: Fri, 9 Mar 2001 05:38:06 -0500 (EST) From: "Matthew N. Dodd" To: freebsd-tokenring@freebsd.org, freebsd-net@freebsd.org Subject: Token Ring and IPX. Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1205283771-984134286=:54019" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1205283771-984134286=:54019 Content-Type: TEXT/PLAIN; charset=US-ASCII I've got a patch against -CURRENT to get our token ring code working against Novell 802.2 style IPX. This patch also may enable IPv6, however additional patches (not included) are required. I also took the time to do some code cleanups. :/ Anyhow, please find attached. My test consisted of mounting a Netware share using NWFS. # mount -a Filesystem 1K-blocks Used Avail Capacity Mounted on ... /SEX_KITTEN:WINTER/SYS 91980 28256 63724 31% /mnt # cd /mnt # du -s . 24642 . # 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 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 | This Space For Rent | ISO8802.5 4ever | --0-1205283771-984134286=:54019 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tr-ipx.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="tr-ipx.patch" SW5kZXg6IGlmX2lzbzg4MDI1c3Vici5jDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQpSQ1MgZmlsZTogL2N2cy9zcmMvc3lzL25ldC9pZl9pc284ODAyNXN1 YnIuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTQNCmRpZmYgLXUgLXIx LjE0IGlmX2lzbzg4MDI1c3Vici5jDQotLS0gaWZfaXNvODgwMjVzdWJyLmMJ MjAwMC8xMS8yNSAwNzozNTozMQkxLjE0DQorKysgaWZfaXNvODgwMjVzdWJy LmMJMjAwMS8wMy8wOSAxMDoxODo0Nw0KQEAgLTQxLDYgKzQxLDggQEANCiAg Ki8NCiANCiAjaW5jbHVkZSAib3B0X2luZXQuaCINCisjaW5jbHVkZSAib3B0 X2luZXQ2LmgiDQorI2luY2x1ZGUgIm9wdF9pcHguaCINCiANCiAjaW5jbHVk ZSA8c3lzL3BhcmFtLmg+DQogI2luY2x1ZGUgPHN5cy9zeXN0bS5oPg0KQEAg LTYwLDExICs2MiwxOSBAQA0KIA0KICNpbmNsdWRlIDxuZXQvaXNvODgwMjUu aD4NCiANCi0jaWZkZWYgSU5FVA0KKyNpZiBkZWZpbmVkKElORVQpIHx8IGRl ZmluZWQoSU5FVDYpDQogI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4NCiAjaW5j bHVkZSA8bmV0aW5ldC9pbl92YXIuaD4NCiAjaW5jbHVkZSA8bmV0aW5ldC9p Zl9ldGhlci5oPg0KICNlbmRpZg0KKyNpZmRlZiBJTkVUNg0KKyNpbmNsdWRl IDxuZXRpbmV0Ni9uZDYuaD4NCisjZW5kaWYNCisNCisjaWZkZWYgSVBYDQor I2luY2x1ZGUgPG5ldGlweC9pcHguaD4NCisjaW5jbHVkZSA8bmV0aXB4L2lw eF9pZi5oPg0KKyNlbmRpZg0KIA0KICNpbmNsdWRlIDxuZXQvYnBmLmg+DQog DQpAQCAtNzgsNiArODgsOCBAQA0KIA0KICNpbmNsdWRlIDxuZXQvaXNvODgw MjUuaD4NCiANCisjZGVmaW5lIElGUDJBQyhJRlApICgoc3RydWN0IGFycGNv bSAqKUlGUCkNCisNCiB2b2lkDQogaXNvODgwMjVfaWZhdHRhY2goc3RydWN0 IGlmbmV0ICppZnApDQogew0KQEAgLTEwMyw2ICsxMTUsMjAgQEANCiAgICAg ICAgIGJjb3B5KCgoc3RydWN0IGFycGNvbSAqKWlmcCktPmFjX2VuYWRkciwg TExBRERSKHNkbCksIGlmcC0+aWZfYWRkcmxlbik7DQogfQ0KIA0KKy8qDQor ICogUGVyZm9ybSBjb21tb24gZHV0aWVzIHdoaWxlIGRldGFjaGluZyBhIFRv a2VuIFJpbmcgaW50ZXJmYWNlDQorICovDQordm9pZA0KK2lzbzg4MDI1X2lm ZGV0YWNoKGlmcCwgYnBmKQ0KKyAgICAgICAgc3RydWN0IGlmbmV0ICppZnA7 DQorICAgICAgICBpbnQgYnBmOw0KK3sNCisJaWYgKGJwZikNCisgICAgICAg ICAgICAgICAgYnBmZGV0YWNoKGlmcCk7DQorCWlmX2RldGFjaChpZnApOw0K K30NCisNCisNCiBpbnQNCiBpc284ODAyNV9pb2N0bChzdHJ1Y3QgaWZuZXQg KmlmcCwgaW50IGNvbW1hbmQsIGNhZGRyX3QgZGF0YSkNCiB7DQpAQCAtMTIx LDYgKzE0NywzMiBAQA0KICAgICAgICAgICAgICAgICAgICAgICAgIGFycF9p ZmluaXQoKHN0cnVjdCBhcnBjb20gKilpZnAsIGlmYSk7DQogICAgICAgICAg ICAgICAgICAgICAgICAgYnJlYWs7DQogI2VuZGlmDQorI2lmZGVmIElQWA0K KyAgICAgICAgICAgICAgICAvKg0KKyAgICAgICAgICAgICAgICAgKiBYWFgg LSBUaGlzIGNvZGUgaXMgcHJvYmFibHkgd3JvbmcNCisgICAgICAgICAgICAg ICAgICovDQorICAgICAgICAgICAgICAgIGNhc2UgQUZfSVBYOg0KKyAgICAg ICAgICAgICAgICAgICAgICAgIHsNCisgICAgICAgICAgICAgICAgICAgICAg ICByZWdpc3RlciBzdHJ1Y3QgaXB4X2FkZHIgKmluYSA9ICYoSUFfU0lQWChp ZmEpLT5zaXB4X2FkZHIpOw0KKyAgICAgICAgICAgICAgICAgICAgICAgIHN0 cnVjdCBhcnBjb20gKmFjID0gSUZQMkFDKGlmcCk7DQorDQorICAgICAgICAg ICAgICAgICAgICAgICAgaWYgKGlweF9udWxsaG9zdCgqaW5hKSkNCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluYS0+eF9ob3N0ID0NCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqKHVuaW9uIGlw eF9ob3N0ICopDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYWMtPmFjX2VuYWRkcjsNCisgICAgICAgICAgICAgICAgICAgICAgICBl bHNlIHsNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJjb3B5 KChjYWRkcl90KSBpbmEtPnhfaG9zdC5jX2hvc3QsDQorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAoY2FkZHJfdCkgYWMtPmFjX2Vu YWRkciwNCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHNpemVvZihhYy0+YWNfZW5hZGRyKSk7DQorICAgICAgICAgICAgICAgICAg ICAgICAgfQ0KKw0KKyAgICAgICAgICAgICAgICAgICAgICAgIC8qDQorICAg ICAgICAgICAgICAgICAgICAgICAgICogU2V0IG5ldyBhZGRyZXNzDQorICAg ICAgICAgICAgICAgICAgICAgICAgICovDQorICAgICAgICAgICAgICAgICAg ICAgICAgaWZwLT5pZl9pbml0KGlmcC0+aWZfc29mdGMpOw0KKyAgICAgICAg ICAgICAgICAgICAgICAgIGJyZWFrOw0KKyAgICAgICAgICAgICAgICAgICAg ICAgIH0NCisjZW5kaWYNCiAgICAgICAgICAgICAgICAgZGVmYXVsdDoNCiAg ICAgICAgICAgICAgICAgICAgICAgICBpZnAtPmlmX2luaXQoaWZwLT5pZl9z b2Z0Yyk7DQogICAgICAgICAgICAgICAgICAgICAgICAgYnJlYWs7DQpAQCAt MTU1LDIzICsyMDcsMjcgQEANCiAgKiBJU084ODAyNSBlbmNhcHN1bGF0aW9u DQogICovDQogaW50DQotaXNvODgwMjVfb3V0cHV0KHN0cnVjdCBpZm5ldCAq aWZwLCBzdHJ1Y3QgbWJ1ZiAqbSwgc3RydWN0IHNvY2thZGRyICpkc3QsIHN0 cnVjdCBydGVudHJ5ICpydDApDQoraXNvODgwMjVfb3V0cHV0KGlmcCwgbSwg ZHN0LCBydDApDQorCXN0cnVjdCBpZm5ldCAqaWZwOw0KKwlzdHJ1Y3QgbWJ1 ZiAqbTsNCisJc3RydWN0IHNvY2thZGRyICpkc3Q7DQorCXN0cnVjdCBydGVu dHJ5ICpydDA7DQogew0KLQlyZWdpc3RlciBzdHJ1Y3QgaXNvODgwMjVfaGVh ZGVyICp0aDsNCisJdV9pbnQxNl90IHR5cGUgPSAwOw0KKyAgICAgICAgaW50 IGxvb3BfY29weSA9IDAsIGVycm9yID0gMCwgcmlmX2xlbiA9IDA7DQorIAl1 X2NoYXIgZWRzdFtJU084ODAyNV9BRERSX0xFTl07DQorCXN0cnVjdCBpc284 ODAyNV9oZWFkZXIgKnRoOw0KIAlzdHJ1Y3QgaXNvODgwMjVfaGVhZGVyIGdl bl90aDsNCi0JcmVnaXN0ZXIgc3RydWN0IGlzbzg4MDI1X3NvY2thZGRyX2Rh dGEgKnNkID0gKHN0cnVjdCBpc284ODAyNV9zb2NrYWRkcl9kYXRhICopZHN0 LT5zYV9kYXRhOw0KLSAgICAgICAgcmVnaXN0ZXIgc3RydWN0IGxsYyAqbDsN Ci0JcmVnaXN0ZXIgc3RydWN0IHNvY2thZGRyX2RsICpzZGwgPSBOVUxMOw0K LSAgICAgICAgaW50IGVycm9yID0gMCwgcmlmX2xlbiA9IDA7DQotIAl1X2No YXIgZWRzdFs2XTsNCi0JcmVnaXN0ZXIgc3RydWN0IHJ0ZW50cnkgKnJ0Ow0K LQlpbnQgbG9vcF9jb3B5ID0gMDsNCisJc3RydWN0IHNvY2thZGRyX2RsICpz ZGwgPSBOVUxMOw0KKwlzdHJ1Y3QgcnRlbnRyeSAqcnQ7DQogCXN0cnVjdCBh cnBjb20gKmFjID0gKHN0cnVjdCBhcnBjb20gKilpZnA7DQogDQogCWlmICgo aWZwLT5pZl9mbGFncyAmIChJRkZfVVB8SUZGX1JVTk5JTkcpKSAhPSAoSUZG X1VQfElGRl9SVU5OSU5HKSkNCiAJCXNlbmRlcnIoRU5FVERPV04pOw0KKwln ZXRtaWNyb3RpbWUoJmlmcC0+aWZfbGFzdGNoYW5nZSk7DQorDQogCXJ0ID0g cnQwOw0KLQlpZiAocnQpIHsNCisJaWYgKHJ0ICE9IE5VTEwpIHsNCiAJCWlm ICgocnQtPnJ0X2ZsYWdzICYgUlRGX1VQKSA9PSAwKSB7DQogCQkJcnQwID0g cnQgPSBydGFsbG9jMShkc3QsIDEsIDBVTCk7DQogCQkJaWYgKHJ0MCkNCkBA IC0yMDQsMzcgKzI2MCw2MSBAQA0KIAkvKiBHZW5lcmF0ZSBhIGdlbmVyaWMg ODAyLjUgaGVhZGVyIGZvciB0aGUgcGFja2V0ICovDQogCWdlbl90aC5hYyA9 IFRSX0FDOw0KIAlnZW5fdGguZmMgPSBUUl9MTENfRlJBTUU7DQotCW1lbWNw eShnZW5fdGguaXNvODgwMjVfc2hvc3QsIGFjLT5hY19lbmFkZHIsIHNpemVv ZihhYy0+YWNfZW5hZGRyKSk7DQorCSh2b2lkKW1lbWNweSgoY2FkZHJfdCln ZW5fdGguaXNvODgwMjVfc2hvc3QsIChjYWRkcl90KWFjLT5hY19lbmFkZHIs DQorCQlzaXplb2YoYWMtPmFjX2VuYWRkcikpOw0KIAlpZiAocmlmX2xlbikg ew0KIAkJZ2VuX3RoLmlzbzg4MDI1X3Nob3N0WzBdIHw9IFRSX1JJSTsNCiAJ CWlmIChyaWZfbGVuID4gMikgew0KIAkJCWdlbl90aC5yY2YgPSBzZGwtPnNk bF9yY2Y7DQotCQkJbWVtY3B5KGdlbl90aC5yZCwgc2RsLT5zZGxfcm91dGUs IHJpZl9sZW4gLSAyKTsNCisJCQkodm9pZCltZW1jcHkoKGNhZGRyX3QpZ2Vu X3RoLnJkLA0KKwkJCQkoY2FkZHJfdClzZGwtPnNkbF9yb3V0ZSwgcmlmX2xl biAtIDIpOw0KIAkJfQ0KIAl9DQogCQ0KLQ0KIAlzd2l0Y2ggKGRzdC0+c2Ff ZmFtaWx5KSB7DQogI2lmZGVmIElORVQNCiAJY2FzZSBBRl9JTkVUOg0KIAkJ aWYgKCFhcnByZXNvbHZlKGFjLCBydCwgbSwgZHN0LCBlZHN0LCBydDApKQ0K IAkJCXJldHVybiAoMCk7CS8qIGlmIG5vdCB5ZXQgcmVzb2x2ZWQgKi8NCi0J CS8qIEFkZCBMTEMgYW5kIFNOQVAgaGVhZGVycyAqLw0KLQkJTV9QUkVQRU5E KG0sIDgsIE1fRE9OVFdBSVQpOw0KLQkJaWYgKG0gPT0gMCkNCi0JCQlzZW5k ZXJyKEVOT0JVRlMpOw0KLQkJbCA9IG10b2QobSwgc3RydWN0IGxsYyAqKTsN Ci0JICAgICAgICBsLT5sbGNfdW4udHlwZV9zbmFwLmV0aGVyX3R5cGUgPSBo dG9ucyhFVEhFUlRZUEVfSVApOw0KLQkgICAgICAgIGwtPmxsY19kc2FwID0g bC0+bGxjX3NzYXAgPSBMTENfU05BUF9MU0FQOw0KLQkJbC0+bGxjX3VuLnR5 cGVfc25hcC5jb250cm9sID0gTExDX1VJOw0KLQkJbC0+bGxjX3VuLnR5cGVf c25hcC5vcmdfY29kZVswXSA9IDB4MDsNCi0JCWwtPmxsY191bi50eXBlX3Nu YXAub3JnX2NvZGVbMV0gPSAweDA7DQotCQlsLT5sbGNfdW4udHlwZV9zbmFw Lm9yZ19jb2RlWzJdID0gMHgwOw0KLQkJbWVtY3B5KGdlbl90aC5pc284ODAy NV9kaG9zdCwgZWRzdCwgc2l6ZW9mKGVkc3QpKTsNCisJCXR5cGUgPSBFVEhF UlRZUEVfSVA7DQorCQlicmVhazsNCisjZW5kaWYNCisjaWZkZWYgSU5FVDYN CisJY2FzZSBBRl9JTkVUNjoNCisJCWlmICghbmQ2X3N0b3JlbGxhZGRyKCZh Yy0+YWNfaWYsIHJ0LCBtLCBkc3QsICh1X2NoYXIgKillZHN0KSkgew0KKwkJ CS8qIHRoaXMgbXVzdCBiZSBpbXBvc3NpYmxlLCBzbyB3ZSBiYXJrICovDQor CQkJcHJpbnRmKCJuZDZfc3RvcmVsbGFkZHIgZmFpbGVkXG4iKTsNCisJCQly ZXR1cm4oMCk7DQorCQl9DQorCQl0eXBlID0gRVRIRVJUWVBFX0lQVjY7DQog CQlicmVhazsNCiAjZW5kaWYNCisjaWZkZWYgSVBYDQorCWNhc2UgQUZfSVBY Og0KKwl7DQorCQl1X2ludDhfdAkqY3A7DQogDQorCQl0eXBlID0gMDsNCisJ CWJjb3B5KChjYWRkcl90KSYoc2F0b2lweF9hZGRyKGRzdCkueF9ob3N0KSwg KGNhZGRyX3QpZWRzdCwNCisJCQlzaXplb2YgKGVkc3QpKTsNCisvKiAmKCgo c3RydWN0IHNvY2thZGRyX2lweCAqKWRzdCktPnNpcHhfYWRkci54X2hvc3Qp LCAqLw0KKw0KKwkJTV9QUkVQRU5EKG0sIDMsIE1fVFJZV0FJVCk7DQorCQlp ZiAobSA9PSAwKQ0KKwkJCXNlbmRlcnIoRU5PQlVGUyk7DQorCQltID0gbV9w dWxsdXAobSwgMyk7DQorCQlpZiAobSA9PSAwKQ0KKwkJCXNlbmRlcnIoRU5P QlVGUyk7DQorCQljcCA9IG10b2QobSwgdV9pbnQ4X3QgKik7DQorCQkqY3Ar KyA9IEVUSEVSVFlQRV9JUFhfODAyMjsNCisJCSpjcCsrID0gRVRIRVJUWVBF X0lQWF84MDIyOw0KKwkJKmNwKysgPSAweDAzOw0KKwl9DQorCWJyZWFrOw0K KyNlbmRpZg0KIAljYXNlIEFGX1VOU1BFQzoNCisJew0KKwkJc3RydWN0IGlz bzg4MDI1X3NvY2thZGRyX2RhdGEgKnNkOw0KIAkJLyoNCiAJCSAqIEZvciBB Rl9VTlNQRUMgc29ja2FkZHIuc2FfZGF0YSBtdXN0IGNvbnRhaW4gYWxsIG9m IHRoZQ0KIAkJICogbWFjIGluZm9ybWF0aW9uIG5lZWRlZCB0byBzZW5kIHRo ZSBwYWNrZXQuICBUaGlzIGFsbG93cw0KQEAgLTI0NywyNiArMzI3LDQ1IEBA DQogCQlzZCA9IChzdHJ1Y3QgaXNvODgwMjVfc29ja2FkZHJfZGF0YSAqKWRz dC0+c2FfZGF0YTsNCiAJCWdlbl90aC5hYyA9IHNkLT5hYzsNCiAJCWdlbl90 aC5mYyA9IHNkLT5mYzsNCi0JCW1lbWNweShnZW5fdGguaXNvODgwMjVfZGhv c3QsIHNkLT5ldGhlcl9kaG9zdCwgc2l6ZW9mKHNkLT5ldGhlcl9kaG9zdCkp Ow0KLQkJbWVtY3B5KGdlbl90aC5pc284ODAyNV9zaG9zdCwgc2QtPmV0aGVy X3Nob3N0LCBzaXplb2Yoc2QtPmV0aGVyX3Nob3N0KSk7DQorCQkodm9pZClt ZW1jcHkoKGNhZGRyX3QpZWRzdCwgKGNhZGRyX3Qpc2QtPmV0aGVyX2Rob3N0 LA0KKwkJCXNpemVvZihzZC0+ZXRoZXJfZGhvc3QpKTsNCisJCSh2b2lkKW1l bWNweSgoY2FkZHJfdClnZW5fdGguaXNvODgwMjVfc2hvc3QsDQorCQkJKGNh ZGRyX3Qpc2QtPmV0aGVyX3Nob3N0LCBzaXplb2Yoc2QtPmV0aGVyX3Nob3N0 KSk7DQogCQlyaWZfbGVuID0gMDsNCiAJCWJyZWFrOw0KLQ0KKwl9DQogCWRl ZmF1bHQ6DQogCQlwcmludGYoIiVzJWQ6IGNhbid0IGhhbmRsZSBhZiVkXG4i LCBpZnAtPmlmX25hbWUsIGlmcC0+aWZfdW5pdCwNCiAJCQlkc3QtPnNhX2Zh bWlseSk7DQogCQlzZW5kZXJyKEVBRk5PU1VQUE9SVCk7DQorCQlicmVhazsN CiAJfQ0KIA0KKwlpZiAodHlwZSAhPSAwKSB7DQorICAgICAgICAJc3RydWN0 IGxsYyAqbDsNCisJCU1fUFJFUEVORChtLCBzaXplb2YgKHN0cnVjdCBsbGMp LCBNX0RPTlRXQUlUKTsNCisJCWlmIChtID09IDApDQorCQkJc2VuZGVycihF Tk9CVUZTKTsNCisJCWwgPSBtdG9kKG0sIHN0cnVjdCBsbGMgKik7DQorCQls LT5sbGNfdW4udHlwZV9zbmFwLmV0aGVyX3R5cGUgPSBodG9ucyh0eXBlKTsN CisJCWwtPmxsY19kc2FwID0gbC0+bGxjX3NzYXAgPSBMTENfU05BUF9MU0FQ Ow0KKwkJbC0+bGxjX3VuLnR5cGVfc25hcC5jb250cm9sID0gTExDX1VJOw0K KwkJbC0+bGxjX3VuLnR5cGVfc25hcC5vcmdfY29kZVswXSA9DQorCQkJbC0+ bGxjX3VuLnR5cGVfc25hcC5vcmdfY29kZVsxXSA9DQorCQkJbC0+bGxjX3Vu LnR5cGVfc25hcC5vcmdfY29kZVsyXSA9IDA7DQorCX0NCisNCiAJLyoNCiAJ ICogQWRkIGxvY2FsIG5ldCBoZWFkZXIuICBJZiBubyBzcGFjZSBpbiBmaXJz dCBtYnVmLA0KIAkgKiBhbGxvY2F0ZSBhbm90aGVyLg0KIAkgKi8NCi0JDQog CU1fUFJFUEVORChtLCBJU084ODAyNV9IRFJfTEVOICsgcmlmX2xlbiwgTV9E T05UV0FJVCk7DQogCWlmIChtID09IDApDQogCQlzZW5kZXJyKEVOT0JVRlMp Ow0KIA0KKwkodm9pZCltZW1jcHkoKGNhZGRyX3QpJmdlbl90aC5pc284ODAy NV9kaG9zdCwgKGNhZGRyX3QpZWRzdCwNCisJCSAgICAgc2l6ZW9mKGVkc3Qp KTsNCisNCiAJLyogQ29weSBhcyBtdWNoIG9mIHRoZSBnZW5lcmljIGhlYWRl ciBhcyBpcyBuZWVkZWQgaW50byB0aGUgbWJ1ZiAqLw0KIAl0aCA9IG10b2Qo bSwgc3RydWN0IGlzbzg4MDI1X2hlYWRlciAqKTsNCiAJbWVtY3B5KHRoLCAm Z2VuX3RoLCBJU084ODAyNV9IRFJfTEVOICsgcmlmX2xlbik7DQpAQCAtMjgw LDIxICszNzksMjIgQEANCiAgICAgICAgICAqIG9uIHRoZSB3aXJlKS4gSG93 ZXZlciwgd2UgZG9uJ3QgZG8gdGhhdCBoZXJlIGZvciBzZWN1cml0eQ0KICAg ICAgICAgICogcmVhc29ucyBhbmQgY29tcGF0aWJpbGl0eSB3aXRoIHRoZSBv cmlnaW5hbCBiZWhhdmlvci4NCiAgICAgICAgICAqLyAgICAgDQotICAgICAg ICBpZiAoKGlmcC0+aWZfZmxhZ3MgJiBJRkZfU0lNUExFWCkgJiYNCi0gICAg ICAgICAgIChsb29wX2NvcHkgIT0gLTEpKSB7DQorICAgICAgICBpZiAoKGlm cC0+aWZfZmxhZ3MgJiBJRkZfU0lNUExFWCkgJiYgKGxvb3BfY29weSAhPSAt MSkpIHsNCiAgICAgICAgICAgICAgICAgaWYgKChtLT5tX2ZsYWdzICYgTV9C Q0FTVCkgfHwgKGxvb3BfY29weSA+IDApKSB7IA0KLSAgICAgICAgICAgICAg ICAgICAgICAgIHN0cnVjdCBtYnVmICpuID0gbV9jb3B5KG0sIDAsIChpbnQp TV9DT1BZQUxMKTsNCi0gICAgICAgICAgICAgICAgICAgICAgICAodm9pZCkg aWZfc2ltbG9vcChpZnAsDQotCQkJICAgIG4sIGRzdC0+c2FfZmFtaWx5LCBJ U084ODAyNV9IRFJfTEVOKTsNCi0gICAgICAgICAgICAgICAgfSBlbHNlIGlm IChiY21wKHRoLT5pc284ODAyNV9kaG9zdCwNCi0gICAgICAgICAgICAgICAg ICAgIHRoLT5pc284ODAyNV9zaG9zdCwgRVRIRVJfQUREUl9MRU4pID09IDAp IHsNCi0gICAgICAgICAgICAgICAgICAgICAgICAodm9pZCkgaWZfc2ltbG9v cChpZnAsDQotCQkJICAgIG0sIGRzdC0+c2FfZmFtaWx5LCBJU084ODAyNV9I RFJfTEVOKTsNCi0gICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4oMCk7 ICAgICAgLyogWFhYICovDQotICAgICAgICAgICAgICAgIH0gICAgICAgDQor ICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IG1idWYgKm47DQorCQkJ biA9IG1fY29weShtLCAwLCAoaW50KU1fQ09QWUFMTCk7DQorICAgICAgICAg ICAgICAgICAgICAgICAgKHZvaWQpaWZfc2ltbG9vcChpZnAsIG4sIGRzdC0+ c2FfZmFtaWx5LA0KKwkJCQkJICBJU084ODAyNV9IRFJfTEVOKTsNCisgICAg ICAgICAgICAgICAgfSBlbHNlDQorCQkJaWYgKGJjbXAodGgtPmlzbzg4MDI1 X2Rob3N0LCB0aC0+aXNvODgwMjVfc2hvc3QsDQorCQkJCSBFVEhFUl9BRERS X0xFTikgPT0gMCkgew0KKwkJCQkodm9pZClpZl9zaW1sb29wKGlmcCwgbSwg ZHN0LT5zYV9mYW1pbHksDQorCQkJCQkJIElTTzg4MDI1X0hEUl9MRU4pOw0K KyAgICAgICAgICAgICAgICAgICAgICAgIAlyZXR1cm4oMCk7ICAgICAgLyog WFhYICovDQorCQkJfSAgICAgICANCiAgICAgICAgIH0gICAgICANCiANCi0J aWYgKCEgSUZfSEFORE9GRl9BREooJmlmcC0+aWZfc25kLCBtLCBpZnAsIElT Tzg4MDI1X0hEUl9MRU4gKyA4KSkgew0KKwlpZiAoISBJRl9IQU5ET0ZGX0FE SigmaWZwLT5pZl9zbmQsIG0sIGlmcCwgSVNPODgwMjVfSERSX0xFTiArIChz aXplb2Yoc3RydWN0IGxsYykpKSApIHsNCiAJCXByaW50ZigiaXNvODgwMjVf b3V0cHV0OiBwYWNrZXQgZHJvcHBlZCBRRlVMTC5cbiIpOw0KIAkJc2VuZGVy cihFTk9CVUZTKTsNCiAJfQ0KQEAgLTMxMCw5MiArNDEwLDE1MSBAQA0KICAq IElTTyA4ODAyNSBkZS1lbmNhcHN1bGF0aW9uDQogICovDQogdm9pZA0KLWlz bzg4MDI1X2lucHV0KHN0cnVjdCBpZm5ldCAqaWZwLCBzdHJ1Y3QgaXNvODgw MjVfaGVhZGVyICp0aCwgc3RydWN0IG1idWYgKm0pDQoraXNvODgwMjVfaW5w dXQoaWZwLCB0aCwgbSkNCisJc3RydWN0IGlmbmV0ICppZnA7DQorCXN0cnVj dCBpc284ODAyNV9oZWFkZXIgKnRoOw0KKwlzdHJ1Y3QgbWJ1ZiAqbTsNCiB7 DQogCXJlZ2lzdGVyIHN0cnVjdCBpZnF1ZXVlICppbnE7DQotCXVfc2hvcnQg ZXRoZXJfdHlwZTsNCi0JcmVnaXN0ZXIgc3RydWN0IGxsYyAqbCA9IG10b2Qo bSwgc3RydWN0IGxsYyAqKTsNCisJcmVnaXN0ZXIgc3RydWN0IGxsYyAqbDsN CiANCiAJaWYgKChpZnAtPmlmX2ZsYWdzICYgSUZGX1VQKSA9PSAwKSB7DQog CQltX2ZyZWVtKG0pOw0KIAkJcmV0dXJuOw0KIAl9DQogDQotCXN3aXRjaCAo bC0+bGxjX2NvbnRyb2wpIHsNCi0JY2FzZSBMTENfVUk6DQotCQlicmVhazsN Ci0JY2FzZSBMTENfVEVTVDoNCi0JY2FzZSBMTENfVEVTVF9QOg0KLQl7DQot CQlzdHJ1Y3Qgc29ja2FkZHIgc2E7DQotCQlzdHJ1Y3QgYXJwY29tICphYyA9 IChzdHJ1Y3QgYXJwY29tICopaWZwOw0KLQkJc3RydWN0IGlzbzg4MDI1X3Nv Y2thZGRyX2RhdGEgKnRoMjsNCi0JCWludCBpOw0KLQkJdV9jaGFyIGMgPSBs LT5sbGNfZHNhcDsNCi0NCi0JCWlmICh0aC0+aXNvODgwMjVfc2hvc3RbMF0g JiBUUl9SSUkpIHsgLyogWFhYICovDQotCQkJcHJpbnRmKCJpc284ODAyNV9p bnB1dDogZHJvcHBpbmcgc291cmNlIHJvdXRlZCBMTENfVEVTVFxuIik7DQot CQkJbV9mcmVlKG0pOw0KLQkJCXJldHVybjsNCi0JCX0NCi0JCWwtPmxsY19k c2FwID0gbC0+bGxjX3NzYXA7DQotCQlsLT5sbGNfc3NhcCA9IGM7DQotCQlp ZiAobS0+bV9mbGFncyAmIChNX0JDQVNUIHwgTV9NQ0FTVCkpDQotCQkJYmNv cHkoKGNhZGRyX3QpYWMtPmFjX2VuYWRkciwgDQotCQkJICAgICAgKGNhZGRy X3QpdGgtPmlzbzg4MDI1X2Rob3N0LCBJU084ODAyNV9BRERSX0xFTik7DQot CQlzYS5zYV9mYW1pbHkgPSBBRl9VTlNQRUM7DQotCQlzYS5zYV9sZW4gPSBz aXplb2Yoc2EpOw0KLQkJdGgyID0gKHN0cnVjdCBpc284ODAyNV9zb2NrYWRk cl9kYXRhICopc2Euc2FfZGF0YTsNCi0JCWZvciAoaSA9IDA7IGkgPCBJU084 ODAyNV9BRERSX0xFTjsgaSsrKSB7DQotCQkJdGgyLT5ldGhlcl9zaG9zdFtp XSA9IGMgPSB0aC0+aXNvODgwMjVfZGhvc3RbaV07DQotCQkJdGgyLT5ldGhl cl9kaG9zdFtpXSA9IHRoLT5pc284ODAyNV9kaG9zdFtpXSA9IHRoLT5pc284 ODAyNV9zaG9zdFtpXTsNCi0JCQl0aC0+aXNvODgwMjVfc2hvc3RbaV0gPSBj Ow0KLQkJfQ0KLQkJdGgyLT5hYyA9IFRSX0FDOw0KLQkJdGgyLT5mYyA9IFRS X0xMQ19GUkFNRTsNCi0JCWlmcC0+aWZfb3V0cHV0KGlmcCwgbSwgJnNhLCBO VUxMKTsNCi0JCXJldHVybjsNCi0JfQ0KLQlkZWZhdWx0Og0KLQkJcHJpbnRm KCJpc284ODAyNV9pbnB1dDogdW5leHBlY3RlZCBsbGMgY29udHJvbCAweCUw MnhcbiIsIGwtPmxsY19jb250cm9sKTsNCi0JCW1fZnJlZW0obSk7DQotCQly ZXR1cm47DQotCX0NCi0NCi0gICAgICAgIG0tPm1fcGt0aGRyLmxlbiAtPSA4 Ow0KLSAgICAgICAgbS0+bV9sZW4gLT0gODsNCi0gICAgICAgIG0tPm1fZGF0 YSArPSA4OyAvKiBMZW5ndGggb2YgTExDIGhlYWRlciBpbiBvdXIgY2FzZSAq Lw0KLQ0KKwlnZXRtaWNyb3RpbWUoJmlmcC0+aWZfbGFzdGNoYW5nZSk7DQog CWlmcC0+aWZfaWJ5dGVzICs9IG0tPm1fcGt0aGRyLmxlbiArIHNpemVvZigq dGgpOw0KKw0KIAlpZiAodGgtPmlzbzg4MDI1X2Rob3N0WzBdICYgMSkgew0K LQkJaWYgKGJjbXAoKGNhZGRyX3QpZXRoZXJicm9hZGNhc3RhZGRyLCAoY2Fk ZHJfdCl0aC0+aXNvODgwMjVfZGhvc3QsIHNpemVvZihldGhlcmJyb2FkY2Fz dGFkZHIpKSA9PSAwKQ0KKwkJaWYgKGJjbXAoKGNhZGRyX3QpZXRoZXJicm9h ZGNhc3RhZGRyLA0KKwkJCSAoY2FkZHJfdCl0aC0+aXNvODgwMjVfZGhvc3Qs DQorCQkJIHNpemVvZihldGhlcmJyb2FkY2FzdGFkZHIpKSA9PSAwKQ0KIAkJ CW0tPm1fZmxhZ3MgfD0gTV9CQ0FTVDsNCiAJCWVsc2UNCiAJCQltLT5tX2Zs YWdzIHw9IE1fTUNBU1Q7DQotCX0gDQotCWlmIChtLT5tX2ZsYWdzICYgKE1f QkNBU1R8TV9NQ0FTVCkpDQogCQlpZnAtPmlmX2ltY2FzdHMrKzsNCisJfSAN CiANCi0JZXRoZXJfdHlwZSA9IG50b2hzKGwtPmxsY191bi50eXBlX3NuYXAu ZXRoZXJfdHlwZSk7DQorCWwgPSBtdG9kKG0sIHN0cnVjdCBsbGMgKik7DQog DQotCXN3aXRjaCAoZXRoZXJfdHlwZSkgew0KLSNpZmRlZiBJTkVUDQotCWNh c2UgRVRIRVJUWVBFX0lQOg0KKwlzd2l0Y2ggKGwtPmxsY19kc2FwKSB7DQor I2lmZGVmIElQWA0KKwljYXNlIEVUSEVSVFlQRV9JUFhfODAyMjoJLyogVGhh bmtzIGEgYnVuY2ggTm92ZWxsICovDQorCQlpZiAobC0+bGxjX3NzYXAgIT0g RVRIRVJUWVBFX0lQWF84MDIyKQ0KKwkJCWdvdG8gZHJvcGFueXdheTsNCiAJ CXRoLT5pc284ODAyNV9zaG9zdFswXSAmPSB+KFRSX1JJSSk7IA0KLQkJaWYg KGlwZmxvd19mYXN0Zm9yd2FyZChtKSkNCi0JCQlyZXR1cm47DQotCQlzY2hl ZG5ldGlzcihORVRJU1JfSVApOw0KLQkJaW5xID0gJmlwaW50cnE7DQorCQlt X2FkaihtLCAzKTsNCisJCXNjaGVkbmV0aXNyKE5FVElTUl9JUFgpOw0KKwkJ aW5xID0gJmlweGludHJxOw0KIAkJYnJlYWs7DQotDQotCWNhc2UgRVRIRVJU WVBFX0FSUDoNCi0JCXNjaGVkbmV0aXNyKE5FVElTUl9BUlApOw0KLQkJaW5x ID0gJmFycGludHJxOw0KLSAgICAgICAgICAgICAgICBicmVhazsNCiAjZW5k aWYNCisJY2FzZSBMTENfU05BUF9MU0FQOiB7DQorCQl1X2ludDE2X3QgdHlw ZTsNCisJCWlmIChsLT5sbGNfY29udHJvbCAhPSBMTENfVUkgfHwgbC0+bGxj X3NzYXAgIT0gTExDX1NOQVBfTFNBUCkNCisJCQlnb3RvIGRyb3Bhbnl3YXk7 DQorCQlpZiAobC0+bGxjX3VuLnR5cGVfc25hcC5vcmdfY29kZVswXSAhPSAw IHx8DQorCQkgICAgbC0+bGxjX3VuLnR5cGVfc25hcC5vcmdfY29kZVsxXSAh PSAwIHx8DQorCQkgICAgbC0+bGxjX3VuLnR5cGVfc25hcC5vcmdfY29kZVsy XSAhPSAwKQ0KKwkJCWdvdG8gZHJvcGFueXdheTsNCisJCXR5cGUgPSBudG9o cyhsLT5sbGNfdW4udHlwZV9zbmFwLmV0aGVyX3R5cGUpOw0KKwkJbV9hZGoo bSwgc2l6ZW9mKHN0cnVjdCBsbGMpKTsNCisJCXN3aXRjaCAodHlwZSkgew0K KyNpZmRlZiBJTkVUDQorCQljYXNlIEVUSEVSVFlQRV9JUDoNCisJCQl0aC0+ aXNvODgwMjVfc2hvc3RbMF0gJj0gfihUUl9SSUkpOyANCisJCQlpZiAoaXBm bG93X2Zhc3Rmb3J3YXJkKG0pKQ0KKwkJCQlyZXR1cm47DQorCQkJc2NoZWRu ZXRpc3IoTkVUSVNSX0lQKTsNCisJCQlpbnEgPSAmaXBpbnRycTsNCisJCQli cmVhazsNCisNCisJCWNhc2UgRVRIRVJUWVBFX0FSUDoNCisJCQlzY2hlZG5l dGlzcihORVRJU1JfQVJQKTsNCisJCQlpbnEgPSAmYXJwaW50cnE7DQorCQkJ YnJlYWs7DQorI2VuZGlmDQorI2lmZGVmIElQWAkvKiBYWFg6IHRoaXMsIEkg dGhpbmssIGlzIGJvZ3VzLiAqLw0KKwkJY2FzZSBFVEhFUlRZUEVfSVBYOg0K KwkJCXRoLT5pc284ODAyNV9zaG9zdFswXSAmPSB+KFRSX1JJSSk7IA0KKwkJ CXNjaGVkbmV0aXNyKE5FVElTUl9JUFgpOw0KKwkJCWlucSA9ICZpcHhpbnRy cTsNCisJCQlicmVhazsNCisjZW5kaWYNCisjaWZkZWYgSU5FVDYNCisJCWNh c2UgRVRIRVJUWVBFX0lQVjY6DQorCQkJdGgtPmlzbzg4MDI1X3Nob3N0WzBd ICY9IH4oVFJfUklJKTsgDQorCQkJc2NoZWRuZXRpc3IoTkVUSVNSX0lQVjYp Ow0KKwkJCWlucSA9ICZpcDZpbnRycTsNCisJCQlicmVhazsNCisjZW5kaWYN CisJCWRlZmF1bHQ6DQorCQkJcHJpbnRmKCJpc284ODAyNV9pbnB1dDogdW5l eHBlY3RlZCBsbGNfc25hcCBldGhlcl90eXBlICAweCUwMnhcbiIsIHR5cGUp Ow0KKwkJCW1fZnJlZW0obSk7DQorCQkJcmV0dXJuOw0KKwkJfQ0KKwkJYnJl YWs7DQorCX0NCisJY2FzZSBMTENfSVNPX0xTQVA6DQorCQlzd2l0Y2ggKGwt PmxsY19jb250cm9sKSB7DQorCQljYXNlIExMQ19VSToNCisJCQlnb3RvIGRy b3Bhbnl3YXk7DQorCQkJYnJlYWs7DQorICAgICAgICAgICAgICAgIGNhc2Ug TExDX1hJRDoNCisgICAgICAgICAgICAgICAgY2FzZSBMTENfWElEX1A6DQor CQkJaWYobS0+bV9sZW4gPCBJU084ODAyNV9BRERSX0xFTikNCisJCQkJZ290 byBkcm9wYW55d2F5Ow0KKwkJCWwtPmxsY193aW5kb3cgPSAwOw0KKwkJCWwt PmxsY19maWQgPSA5OyAgDQorCQkJbC0+bGxjX2NsYXNzID0gMTsNCisJCQls LT5sbGNfZHNhcCA9IGwtPmxsY19zc2FwID0gMDsNCisJCQkvKiBGYWxsIHRo cm91Z2ggdG8gKi8gIA0KKwkJY2FzZSBMTENfVEVTVDoNCisJCWNhc2UgTExD X1RFU1RfUDoNCisJCXsNCisJCQlzdHJ1Y3Qgc29ja2FkZHIgc2E7DQorCQkJ c3RydWN0IGFycGNvbSAqYWMgPSAoc3RydWN0IGFycGNvbSAqKWlmcDsNCisJ CQlzdHJ1Y3QgaXNvODgwMjVfc29ja2FkZHJfZGF0YSAqdGgyOw0KKwkJCWlu dCBpOw0KKwkJCXVfY2hhciBjID0gbC0+bGxjX2RzYXA7DQorDQorCQkJaWYg KHRoLT5pc284ODAyNV9zaG9zdFswXSAmIFRSX1JJSSkgeyAvKiBYWFggKi8N CisJCQkJcHJpbnRmKCJpc284ODAyNV9pbnB1dDogZHJvcHBpbmcgc291cmNl IHJvdXRlZCBMTENfVEVTVFxuIik7DQorCQkJCW1fZnJlZShtKTsNCisJCQkJ cmV0dXJuOw0KKwkJCX0NCisJCQlsLT5sbGNfZHNhcCA9IGwtPmxsY19zc2Fw Ow0KKwkJCWwtPmxsY19zc2FwID0gYzsNCisJCQlpZiAobS0+bV9mbGFncyAm IChNX0JDQVNUIHwgTV9NQ0FTVCkpDQorCQkJCWJjb3B5KChjYWRkcl90KWFj LT5hY19lbmFkZHIsIA0KKwkJCSAgICAgIAkJKGNhZGRyX3QpdGgtPmlzbzg4 MDI1X2Rob3N0LA0KKwkJCQkJSVNPODgwMjVfQUREUl9MRU4pOw0KKwkJCXNh LnNhX2ZhbWlseSA9IEFGX1VOU1BFQzsNCisJCQlzYS5zYV9sZW4gPSBzaXpl b2Yoc2EpOw0KKwkJCXRoMiA9IChzdHJ1Y3QgaXNvODgwMjVfc29ja2FkZHJf ZGF0YSAqKXNhLnNhX2RhdGE7DQorCQkJZm9yIChpID0gMDsgaSA8IElTTzg4 MDI1X0FERFJfTEVOOyBpKyspIHsNCisJCQkJdGgyLT5ldGhlcl9zaG9zdFtp XSA9IGMgPSB0aC0+aXNvODgwMjVfZGhvc3RbaV07DQorCQkJCXRoMi0+ZXRo ZXJfZGhvc3RbaV0gPSB0aC0+aXNvODgwMjVfZGhvc3RbaV0gPQ0KKwkJCQkJ dGgtPmlzbzg4MDI1X3Nob3N0W2ldOw0KKwkJCQl0aC0+aXNvODgwMjVfc2hv c3RbaV0gPSBjOw0KKwkJCX0NCisJCQl0aDItPmFjID0gVFJfQUM7DQorCQkJ dGgyLT5mYyA9IFRSX0xMQ19GUkFNRTsNCisJCQlpZnAtPmlmX291dHB1dChp ZnAsIG0sICZzYSwgTlVMTCk7DQorCQkJcmV0dXJuOw0KKwkJfQ0KKwkJZGVm YXVsdDoNCisJCQlwcmludGYoImlzbzg4MDI1X2lucHV0OiB1bmV4cGVjdGVk IGxsYyBjb250cm9sIDB4JTAyeFxuIiwgbC0+bGxjX2NvbnRyb2wpOw0KKwkJ CW1fZnJlZW0obSk7DQorCQkJcmV0dXJuOw0KKwkJfQ0KKwkJYnJlYWs7DQog CWRlZmF1bHQ6DQotCSAgICBtX2ZyZWVtKG0pOw0KLQkgICAgcmV0dXJuOw0K KwkJcHJpbnRmKCJpc284ODAyNV9pbnB1dDogdW5rbm93biBkc2FwIDB4JXhc biIsIGwtPmxsY19kc2FwKTsNCisJCWlmcC0+aWZfbm9wcm90bysrOw0KKwlk cm9wYW55d2F5Og0KKwkJbV9mcmVlbShtKTsNCisJCXJldHVybjsNCiAJfQ0K IA0KIAlpZiAoISBJRl9IQU5ET0ZGKGlucSwgbSwgTlVMTCkpDQpJbmRleDog aXNvODgwMjUuaA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6 IC9jdnMvc3JjL3N5cy9uZXQvaXNvODgwMjUuaCx2DQpyZXRyaWV2aW5nIHJl dmlzaW9uIDEuNA0KZGlmZiAtdSAtcjEuNCBpc284ODAyNS5oDQotLS0gaXNv ODgwMjUuaAkyMDAwLzAzLzE5IDIxOjM0OjM3CTEuNA0KKysrIGlzbzg4MDI1 LmgJMjAwMS8wMy8wOCAwMjowMTo0Mw0KQEAgLTc1LDYgKzc1LDggQEANCiAg KiBNaW5pbXVtIGFuZCBtYXhpbXVtIHBhY2tldCBwYXlsb2FkIGxlbmd0aHMu DQogICovDQogI2RlZmluZQlJU084ODAyNV9NSU5fTEVOCTAgDQorI2RlZmlu ZSBJU084ODAyNV9NQVhfTEVOXzQJNDQ2NA0KKyNkZWZpbmUJSVNPODgwMjVf TUFYX0xFTl8xNgkxNzk2MAkNCiAjZGVmaW5lCUlTTzg4MDI1X01BWF9MRU4J MTc5NjAJDQogDQogLyoNCkBAIC04NywxMyArODksMTggQEANCiAgKiBJU08g ODAyLjUgcGh5c2ljYWwgaGVhZGVyDQogICovDQogc3RydWN0IGlzbzg4MDI1 X2hlYWRlciB7DQotCXVfY2hhcglhYzsJCQkJICAgIC8qIGFjY2VzcyBjb250 cm9sIGZpZWxkICovDQotCXVfY2hhcglmYzsJCQkJICAgIC8qIGZyYW1lIGNv bnRyb2wgZmllbGQgKi8NCi0JdV9jaGFyCWlzbzg4MDI1X2Rob3N0W0lTTzg4 MDI1X0FERFJfTEVOXTsgIC8qIGRlc3RpbmF0aW9uIGFkZHJlc3MgKi8NCi0J dV9jaGFyCWlzbzg4MDI1X3Nob3N0W0lTTzg4MDI1X0FERFJfTEVOXTsgIC8q IHNvdXJjZSBhZGRyZXNzICovDQotCXVfc2hvcnQJcmNmOwkJCQkgICAgLyog cm91dGUgY29udHJvbCBmaWVsZCAqLw0KLQl1X3Nob3J0CXJkW1JJRl9NQVhf UkRdOwkJCSAgICAvKiByb3V0aW5nIGRlc2lnbmF0b3JzICovDQotfTsNCisJ dV9pbnQ4X3QJYWM7CQkJCSAgICAvKiBhY2Nlc3MgY29udHJvbCBmaWVsZCAq Lw0KKwl1X2ludDhfdAlmYzsJCQkJICAgIC8qIGZyYW1lIGNvbnRyb2wgZmll bGQgKi8NCisJdV9pbnQ4X3QJaXNvODgwMjVfZGhvc3RbSVNPODgwMjVfQURE Ul9MRU5dOyAgLyogZGVzdGluYXRpb24gYWRkcmVzcyAqLw0KKwl1X2ludDhf dAlpc284ODAyNV9zaG9zdFtJU084ODAyNV9BRERSX0xFTl07ICAvKiBzb3Vy Y2UgYWRkcmVzcyAqLw0KKwl1X2ludDE2X3QJcmNmOwkJCQkgICAgLyogcm91 dGUgY29udHJvbCBmaWVsZCAqLw0KKwl1X2ludDE2X3QJcmRbUklGX01BWF9S RF07CQkJICAgIC8qIHJvdXRpbmcgZGVzaWduYXRvcnMgKi8NCit9IF9fYXR0 cmlidXRlX18gKChfX3BhY2tlZF9fKSk7DQorDQorc3RydWN0IGlzbzg4MDI1 X3JpZiB7DQorCXVfaW50MTZfdAlyY2Y7CQkJCSAgICAvKiByb3V0ZSBjb250 cm9sIGZpZWxkICovDQorCXVfaW50MTZfdAlyZFtSSUZfTUFYX1JEXTsJCQkg ICAgLyogcm91dGluZyBkZXNpZ25hdG9ycyAqLw0KK30gX19hdHRyaWJ1dGVf XyAoKF9fcGFja2VkX18pKTsNCiANCiBzdHJ1Y3QgaXNvODgwMjVfc29ja2Fk ZHJfZGF0YSB7DQogCXVfY2hhciBldGhlcl9kaG9zdFtJU084ODAyNV9BRERS X0xFTl07DQpJbmRleDogaWZfbGxjLmgNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NClJDUyBmaWxlOiAvY3ZzL3NyYy9zeXMvbmV0L2lmX2xsYy5oLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS43DQpkaWZmIC11IC1yMS43IGlmX2xsYy5o DQotLS0gaWZfbGxjLmgJMTk5OS8wOC8yOCAwMDo0ODoxOAkxLjcNCisrKyBp Zl9sbGMuaAkyMDAxLzAzLzA5IDA5OjE0OjAzDQpAQCAtNDYsNDQgKzQ2LDQ1 IEBADQogICovDQogDQogc3RydWN0IGxsYyB7DQotCXVfY2hhcglsbGNfZHNh cDsNCi0JdV9jaGFyCWxsY19zc2FwOw0KKwl1X2ludDhfdAlsbGNfZHNhcDsN CisJdV9pbnQ4X3QJbGxjX3NzYXA7DQogCXVuaW9uIHsNCiAJICAgIHN0cnVj dCB7DQotCQl1X2NoYXIgY29udHJvbDsNCi0JCXVfY2hhciBmb3JtYXRfaWQ7 DQotCQl1X2NoYXIgY2xhc3M7DQotCQl1X2NoYXIgd2luZG93X3gyOw0KLQkg ICAgfSB0eXBlX3U7DQotCSAgICBzdHJ1Y3Qgew0KLQkJdV9jaGFyIG51bV9z bmRfeDI7DQotCQl1X2NoYXIgbnVtX3Jjdl94MjsNCi0JICAgIH0gdHlwZV9p Ow0KLQkgICAgc3RydWN0IHsNCi0JCXVfY2hhciBjb250cm9sOw0KLQkJdV9j aGFyIG51bV9yY3ZfeDI7DQotCSAgICB9IHR5cGVfczsNCisJCXVfaW50OF90 IGNvbnRyb2w7DQorCQl1X2ludDhfdCBmb3JtYXRfaWQ7DQorCQl1X2ludDhf dCBjbGFzczsNCisJCXVfaW50OF90IHdpbmRvd194MjsNCisJICAgIH0gdHlw ZV91IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsNCisJICAgIHN0cnVj dCB7DQorCQl1X2ludDhfdCBudW1fc25kX3gyOw0KKwkJdV9pbnQ4X3QgbnVt X3Jjdl94MjsNCisJICAgIH0gdHlwZV9pIF9fYXR0cmlidXRlX18oKF9fcGFj a2VkX18pKTsNCisJICAgIHN0cnVjdCB7DQorCQl1X2ludDhfdCBjb250cm9s Ow0KKwkJdV9pbnQ4X3QgbnVtX3Jjdl94MjsNCisJICAgIH0gdHlwZV9zIF9f YXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsNCiAJICAgIHN0cnVjdCB7DQot CSAgICAgICAgdV9jaGFyIGNvbnRyb2w7DQorCSAgICAgICAgdV9pbnQ4X3Qg Y29udHJvbDsNCiAJCXN0cnVjdCBmcm1yaW5mbyB7DQotCQkJdV9jaGFyIHJl al9wZHVfMDsNCi0JCQl1X2NoYXIgcmVqX3BkdV8xOw0KLQkJCXVfY2hhciBm cm1yX2NvbnRyb2w7DQotCQkJdV9jaGFyIGZybXJfY29udHJvbF9leHQ7DQot CQkJdV9jaGFyIGZybXJfY2F1c2U7DQotCQl9IGZybXJpbmZvOw0KLQkgICAg fSB0eXBlX2ZybXI7DQorCQkJdV9pbnQ4X3QgcmVqX3BkdV8wOw0KKwkJCXVf aW50OF90IHJlal9wZHVfMTsNCisJCQl1X2ludDhfdCBmcm1yX2NvbnRyb2w7 DQorCQkJdV9pbnQ4X3QgZnJtcl9jb250cm9sX2V4dDsNCisJCQl1X2ludDhf dCBmcm1yX2NhdXNlOw0KKwkJfSBmcm1yaW5mbyBfX2F0dHJpYnV0ZV9fKChf X3BhY2tlZF9fKSk7DQorCSAgICB9IHR5cGVfZnJtciBfX2F0dHJpYnV0ZV9f KChfX3BhY2tlZF9fKSk7DQogCSAgICBzdHJ1Y3Qgew0KLQkJdV9jaGFyIGNv bnRyb2w7DQotCQl1X2NoYXIgb3JnX2NvZGVbM107DQorCQl1X2ludDhfdCBj b250cm9sOw0KKwkJdV9pbnQ4X3Qgb3JnX2NvZGVbM107DQogCQl1X3Nob3J0 IGV0aGVyX3R5cGU7DQotCSAgICB9IHR5cGVfc25hcDsNCisJICAgIH0gdHlw ZV9zbmFwIF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18pKTsNCiAJICAgIHN0 cnVjdCB7DQotCQl1X2NoYXIgY29udHJvbDsNCi0JCXVfY2hhciBjb250cm9s X2V4dDsNCi0JICAgIH0gdHlwZV9yYXc7DQotCX0gbGxjX3VuOw0KLX07DQor CQl1X2ludDhfdCBjb250cm9sOw0KKwkJdV9pbnQ4X3QgY29udHJvbF9leHQ7 DQorCSAgICB9IHR5cGVfcmF3IF9fYXR0cmlidXRlX18oKF9fcGFja2VkX18p KTsNCisJfSBsbGNfdW4gX19hdHRyaWJ1dGVfXygoX19wYWNrZWRfXykpOw0K K30gX19hdHRyaWJ1dGVfXygoX19wYWNrZWRfXykpOw0KKw0KICNkZWZpbmUg bGxjX2NvbnRyb2wgICAgICAgICAgICBsbGNfdW4udHlwZV91LmNvbnRyb2wN CiAjZGVmaW5lCWxsY19jb250cm9sX2V4dCAgICAgICAgbGxjX3VuLnR5cGVf cmF3LmNvbnRyb2xfZXh0DQogI2RlZmluZSBsbGNfZmlkICAgICAgICAgICAg ICAgIGxsY191bi50eXBlX3UuZm9ybWF0X2lkDQpAQCAtMTAyLDYgKzEwMyw4 IEBADQogI2RlZmluZSBMTENfSVNGUkFNRUxFTiA0DQogI2RlZmluZSBMTENf VUZSQU1FTEVOICAzDQogI2RlZmluZSBMTENfRlJNUkxFTiAgICA3DQorI2Rl ZmluZSBMTENfU05BUEZSQU1FTEVOIDgNCisNCiANCiAvKg0KICAqIFVubnVt YmVyZWQgTExDIGZvcm1hdCBjb21tYW5kcw0K --0-1205283771-984134286=:54019-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 3: 1:27 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 F253537B719; Fri, 9 Mar 2001 03:01:20 -0800 (PST) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id MAA04870; Fri, 9 Mar 2001 12:01:19 +0100 (MET) Date: Fri, 9 Mar 2001 12:01:18 +0100 (CET) From: Harti Brandt To: Cc: Subject: Netgraph is leaking node references 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, it seems that netgraph is leaking references. One simple experiment to do is to repeat 'ngctl types' several times: 500 [root] (beagle) netgraph_atm/tests/ccatm # ngctl types There are 5 total types: Type name Number of living nodes --------- ---------------------- socket 9 sscfu 0 sscop 1 atm 2 tee 0 501 [root] (beagle) netgraph_atm/tests/ccatm # ngctl types There are 5 total types: Type name Number of living nodes --------- ---------------------- socket 10 sscfu 0 sscop 1 atm 2 tee 0 502 [root] (beagle) netgraph_atm/tests/ccatm # ngctl types There are 5 total types: Type name Number of living nodes --------- ---------------------- socket 11 sscfu 0 sscop 1 atm 2 tee 0 503 [root] (beagle) netgraph_atm/tests/ccatm # exit See the number of socket type nodes increasing. A ngctl list shows only the two persistant atm nodes and the ngctl socket node. Dumping the node list shows, that all the nodes have 0 hooks, are INVALID and CLOSING, but have references. This happens for all types (the sscop nodes above is one of these stuck nodes). The leaking references are probably hook references, because the number of dangling references in the dead nodes depends on the number of hooks it previously had. So what is the problem? harti PS: FreeBSD beagle.fokus.gmd.de 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Thu Mar 8 11:42:04 CET 2001 hbb@beagle.fokus.gmd.de:/opt/obj/usr/src/sys/BEAGLE i386 -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, harti@begemot.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 9 3:37:22 2001 Delivered-To: freebsd-net@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id E961037B719 for ; Fri, 9 Mar 2001 03:37:08 -0800 (PST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f29BZA959543; Fri, 9 Mar 2001 13:35:10 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200103091135.f29BZA959543@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak In-Reply-To: <26821.984121907@coconut.itojun.org> from "itojun@iijlab.net" at "Mar 9, 2001 04:11:47 pm" To: itojun@iijlab.net Date: Fri, 9 Mar 2001 13:35:10 +0200 (SAT) Cc: bmilekic@technokratis.com, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > >I'll do it right now if itojun doesn't mind (to save him a task :-) ) > >and get authorization from Jordan to commit. > > please go ahead, i can review the diff if you want me to. > Ok, here is a patch for -current. It was taken from the kame code with minor adjustments to fit into our tree. I have tested it on -current, but not on -stable yet. Itojun will you look it over please? I'm gone for the weekend now, so I'll only be able to commit it by Sunday night. If someone wants to do it before then, you're welcome. John -- John Hay -- John.Hay@icomtek.csir.co.za Index: sys/net/if_ethersubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_ethersubr.c,v retrieving revision 1.91 diff -u -r1.91 if_ethersubr.c --- sys/net/if_ethersubr.c 2001/02/18 17:54:52 1.91 +++ sys/net/if_ethersubr.c 2001/03/09 11:00:49 @@ -184,8 +184,7 @@ #ifdef INET6 case AF_INET6: if (!nd6_storelladdr(&ac->ac_if, rt, m, dst, (u_char *)edst)) { - /* this must be impossible, so we bark */ - printf("nd6_storelladdr failed\n"); + /* something bad happened */ return(0); } off = m->m_pkthdr.len - m->m_len; Index: sys/net/if_fddisubr.c =================================================================== RCS file: /home/ncvs/src/sys/net/if_fddisubr.c,v retrieving revision 1.49 diff -u -r1.49 if_fddisubr.c --- sys/net/if_fddisubr.c 2001/02/04 13:12:56 1.49 +++ sys/net/if_fddisubr.c 2001/03/09 11:01:18 @@ -180,8 +180,7 @@ #ifdef INET6 case AF_INET6: if (!nd6_storelladdr(&ac->ac_if, rt, m, dst, (u_char *)edst)) { - /* this must be impossible, so we bark */ - printf("nd6_storelladdr failed\n"); + /* something bad happened */ return(0); } type = htons(ETHERTYPE_IPV6); Index: sys/netinet6/nd6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v retrieving revision 1.7 diff -u -r1.7 nd6.c --- sys/netinet6/nd6.c 2001/02/26 03:41:13 1.7 +++ sys/netinet6/nd6.c 2001/03/09 10:20:04 @@ -970,6 +970,7 @@ return(1); break; default: + m_freem(m); return(0); } } @@ -1026,6 +1027,7 @@ ln, 0); } } + /* do not free mbuf here, it is queued into llinfo_nd6 */ return(0); } #endif /* OLDIP6OUTPUT */ @@ -1981,19 +1983,26 @@ *desten = 0; return(1); default: + m_freem(m); return(0); } } - if (rt == NULL || - rt->rt_gateway->sa_family != AF_LINK) { + if (rt == NULL) { + /* this could happen, if we could not allocate memory */ + m_freem(m); + return(0); + } + if (rt->rt_gateway->sa_family != AF_LINK) { printf("nd6_storelladdr: something odd happens\n"); + m_freem(m); return(0); } sdl = SDL(rt->rt_gateway); if (sdl->sdl_alen == 0) { /* this should be impossible, but we bark here for debugging */ printf("nd6_storelladdr: sdl_alen == 0\n"); + m_freem(m); return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 4:12:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id C9C4E37B718; Fri, 9 Mar 2001 04:12:33 -0800 (PST) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id C33D428E32; Fri, 9 Mar 2001 18:12:29 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id B510328DD7; Fri, 9 Mar 2001 18:12:29 +0600 (ALMT) Date: Fri, 9 Mar 2001 18:12:29 +0600 (ALMT) From: Boris Popov To: "Matthew N. Dodd" Cc: freebsd-tokenring@freebsd.org, freebsd-net@freebsd.org Subject: Re: Token Ring and IPX. 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 Fri, 9 Mar 2001, Matthew N. Dodd wrote: > I've got a patch against -CURRENT to get our token ring code working > against Novell 802.2 style IPX. Whee, thanks! -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 7:30:26 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 B48C037B719 for ; Fri, 9 Mar 2001 07:30:22 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 30565 invoked by uid 666); 9 Mar 2001 15:31:16 -0000 Received: from i079-234.nv.iinet.net.au (HELO elischer.org) (203.59.79.234) by mail.m.iinet.net.au with SMTP; 9 Mar 2001 15:31:16 -0000 Message-ID: <3AA8F6F2.99480745@elischer.org> Date: Fri, 09 Mar 2001 07:29:54 -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: Harti Brandt Cc: julian@freebsd.org, net@freebsd.org Subject: Re: Netgraph is leaking node references 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 Thanks Harti. I'll look at it (again) I thought I had fixed these.. oh well maybe I broke it again.. Hooks hold a reference on the node until their own references go to 0. The node holds a reference on teh hook, but the cycle is handled in the hook removal code. Since node removal first calls hook removal on each hook, and removes it's reference, it should all work out. I'll go through the logic again now. I must have forgotten something :-( Harti Brandt wrote: > > Hi, > > it seems that netgraph is leaking references. One simple experiment to do > is to repeat 'ngctl types' several times: > > 500 [root] (beagle) netgraph_atm/tests/ccatm # ngctl types > There are 5 total types: > Type name Number of living nodes > --------- ---------------------- > socket 9 > sscfu 0 > sscop 1 > atm 2 > tee 0 > 501 [root] (beagle) netgraph_atm/tests/ccatm # ngctl types > There are 5 total types: > Type name Number of living nodes > --------- ---------------------- > socket 10 > sscfu 0 > sscop 1 > atm 2 > tee 0 > 502 [root] (beagle) netgraph_atm/tests/ccatm # ngctl types > There are 5 total types: > Type name Number of living nodes > --------- ---------------------- > socket 11 > sscfu 0 > sscop 1 > atm 2 > tee 0 > 503 [root] (beagle) netgraph_atm/tests/ccatm # exit > > See the number of socket type nodes increasing. A ngctl list shows only > the two persistant atm nodes and the ngctl socket node. Dumping the node > list shows, that all the nodes have 0 hooks, are INVALID and CLOSING, but > have references. This happens for all types (the sscop nodes above is one > of these stuck nodes). The leaking references are probably hook > references, because the number of dangling references in the dead nodes > depends on the number of hooks it previously had. > > So what is the problem? > harti > > PS: > FreeBSD beagle.fokus.gmd.de 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Thu Mar 8 11:42:04 CET 2001 > hbb@beagle.fokus.gmd.de:/opt/obj/usr/src/sys/BEAGLE i386 > -- > harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private > brandt@fokus.gmd.de, harti@begemot.org -- __--_|\ 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 Fri Mar 9 8: 4: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from postal.jnpr.net (natint.juniper.net [207.17.136.129]) by hub.freebsd.org (Postfix) with ESMTP id 6D5C937B71B; Fri, 9 Mar 2001 08:04:02 -0800 (PST) (envelope-from walterg@juniper.net) Received: by postal.jnpr.net with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Mar 2001 08:04:02 -0800 Message-ID: From: Walter Goralski To: "'freebsd-hackers@freebsd.org'" , "'freebsd-net@freebsd.org'" Subject: Generating SYN packets. Date: Fri, 9 Mar 2001 08:03:58 -0800 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 Folks: Andreas Klemm, who ported cflowd to FreeBSD, suggested I use this vehicle to see if I could get some help. I am a course developer for Juniper Networks, and I have just written a 2-day advanced course on router firewall filters (this is one reason for the cflowd). We have participants in a strictly closed lab environment configuring filters to stop spoofs, smurf, fraggle, etc. In order to show they work, we also have a 4.2 FreeBSD laptop that can launch smurf, fraggle, etc. at the routers and the instructor's PC. The missing piece has been DOS SYN attacks. I have the really common "synk4.c" source that is all over the Web, but I get errors when I try to compile it ("it's the linux includes" someone told me). Now, I last used my C programming skills in the 80s on a Silent 700 teletype and a 3B20 mini, so I tried playing around with "programming by analogy" (hey, it sometimes works). I took fraggle.c and tried to substitute a tcp header for the udp header. Anyway, the compiler tells me there is a syntax error in tcp.h (right before the "n_long"), which strikes me as odd. Then it says I am using an "incomplete type" and dereferences all of my pointers. Sometimes I can force a compile and lonk, but none of my paramters get plugged into the packets when I use it. So: anybody got a quick and dirty SYN packet generator out there? A version of synk4 that runs on 4.2? An executable? I even tried to install hping2 from the FreeBSD ports collection, but of course *that* won't run either. (It says my ep0 interface is not defined (!) and seems to try to use lo.) If I use "make install," I get these run time errors; if I use "./configure" and then "make" I get compile errors, also about "overlapping" includes. (***Are my include files all screwed up?*** How could I tell?) But the cflowd and RADIUS servers, also installed a couple of weeks ago from these ports, run merrily along, so the basic system seems to be intact. I don't think my programming efforts have scrammed the system (and I don't have the cd-rom, since it's a company laptop), but I am very worried that I have somehow harmed the .h files. Meanwhile, I'm re-learning BSD socket coding. But this might be faster if anyone can help. (As a note, if anyone out there works for Juniper, I can configure remote access to the laptop if required.) Walter Goralski walterg@juniper.net 952-938-4483 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 8:49:30 2001 Delivered-To: freebsd-net@freebsd.org Received: from ohm.physics.purdue.edu (ohm.physics.purdue.edu [128.210.146.32]) by hub.freebsd.org (Postfix) with ESMTP id D874F37B718; Fri, 9 Mar 2001 08:49:24 -0800 (PST) (envelope-from will@physics.purdue.edu) Received: (from will@localhost) by ohm.physics.purdue.edu (8.11.2/8.9.3) id f29GpP552199; Fri, 9 Mar 2001 11:51:25 -0500 (EST) (envelope-from will@physics.purdue.edu) X-Authentication-Warning: ohm.physics.purdue.edu: will set sender to will@physics.purdue.edu using -f Date: Fri, 9 Mar 2001 11:51:25 -0500 From: Will Andrews To: Walter Goralski Cc: "'freebsd-hackers@freebsd.org'" , "'freebsd-net@freebsd.org'" Subject: Re: Generating SYN packets. Message-ID: <20010309115125.D45561@ohm.physics.purdue.edu> Reply-To: Will Andrews References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Do9hQ/bfCb4zBpLo" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from walterg@juniper.net on Fri, Mar 09, 2001 at 08:03:58AM -0800 X-Operating-System: FreeBSD 4.2-STABLE i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --Do9hQ/bfCb4zBpLo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 09, 2001 at 08:03:58AM -0800, Walter Goralski wrote: > The missing piece has been DOS SYN attacks. I have the really common > "synk4.c" source that is all over the Web, but I get errors when I try to > compile it ("it's the linux includes" someone told me). Now, I last used = my They're most likely right. Try changing "#include " to "#include " or "#include ". Linux has this weird idea that raw sockets headers should be under . Apparently they are the only OS that supports such behavior. ;) --=20 wca --Do9hQ/bfCb4zBpLo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6qQoMF47idPgWcsURAuycAJ9fphV5OzJjr9opRf3s8/q0ECM9iACdGvOK y5tILIKpASGmq1LlVdovOp8= =Puua -----END PGP SIGNATURE----- --Do9hQ/bfCb4zBpLo-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 9:42: 6 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 49A5F37B71F for ; Fri, 9 Mar 2001 09:42:03 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f29HdSk27992; Fri, 9 Mar 2001 11:39:28 -0600 (CST) (envelope-from jlemon) Date: Fri, 9 Mar 2001 11:39:28 -0600 From: Jonathan Lemon To: itojun@iijlab.net, net@freebsd.org Subject: Re: [itojun@iijlab.net: accept(2) behavior with tcp RST right after handshake] Message-ID: <20010309113928.I78851@prism.flugsvamp.com> References: <20010308161611.B78851@prism.flugsvamp.com> <25798.984117381@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <25798.984117381@coconut.itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Mar 09, 2001 at 02:56:21PM +0900, itojun@iijlab.net wrote: > > >From the server's point of view: > > > > + TCP/IP handshake from client, allocate protocol control blocks > > + receive data from client > > + client resets connection, pcb is destroyed > > > >Exactly why the client resets the connection isn't my concern at > >the moment. Some stacks may place a timeout on the FIN_WAIT state, > >and forcibly reset the reset the connection when the timer expires. > >Alternatively, the client may crash, and then RST in response to > >an ACK transmitted by the server. Or the other end may have set > >SO_LINGER, which will cause close() to send a RST. > > > >The unix-domain bug is because we were treating sockets in the > >DISCONNECTED state identically across all protocols, which turns > >out not to be the case. > > > >As for any data that already exists in the socket buffer on the > >server when the connection is aborted, I believe that the correct > >thing to do is discard it. This is the historical precedent, and > >is supported by the current standards. > > > >Below is a patch that will fix the behavior for unix-domain sockets. > > from code inspection on netbsd, I guess you'd need to do something for > other sys/net* families. maybe we need another per-domain/per-socket > flag for this? That might be cleaner in the long run rather than putting the test into each protocol layer. However, since FreeBSD is coming up on a release, I don't want to make an immediate change. I've only changed tcp/tcp6 behavior. The only other protocols that I know of that might need changing are ipx and aal; these will probably return EINVAL instead of ECONNABORTED at the moment. I think that the correct long term behavior would be to make the peer name available to the socket regardless of the state of the protocol connection (either hold the protocol block, or copy the name up to the socket layer). Then, restore the previous behavior of always returning a valid fd for the socket, even if the peer is closed. This provides two things: 1. The application is able to get the address of the peer who connected (whowever briefly). I've seen some requests for this particular feature. Doing this fixes the bug with DNS and Apache, which assume the returned address is valid. 2. The app will still be able to retrieve any data that is sitting in the TCP socket buffers, which might be desired in the TCP case (just as it is in the unix-domain case) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 10:37:58 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id B558837B71C for ; Fri, 9 Mar 2001 10:37:55 -0800 (PST) (envelope-from bmilekic@technokratis.com) Received: from jehovah ([24.202.203.190]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G9Y13704.L7Q; Fri, 9 Mar 2001 13:37:55 -0500 Message-ID: <006201c0a8c8$6be7e8e0$becbca18@jehovah> From: "Bosko Milekic" To: "John Hay" , Cc: References: <200103091135.f29BZA959543@zibbi.icomtek.csir.co.za> Subject: Re: kernel: nd6_storelladdr failed, mbuf leak Date: Fri, 9 Mar 2001 13:40:31 -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 John Hay wrote: > > > > >I'll do it right now if itojun doesn't mind (to save him a task :-) ) > > >and get authorization from Jordan to commit. > > > > please go ahead, i can review the diff if you want me to. > > > > Ok, here is a patch for -current. It was taken from the kame code > with minor adjustments to fit into our tree. I have tested it on > -current, but not on -stable yet. > > Itojun will you look it over please? > > I'm gone for the weekend now, so I'll only be able to commit it by > Sunday night. If someone wants to do it before then, you're welcome. I have this one sitting around which is a direct "port" of the KAME patch: http://people.freebsd.org/~bmilekic/code/kame_nd6.diff The differences between the two in terms of functionality are very small, but I prefer your patch because it removes the printf()s from if_ethersubr.c Since itojun OK'd it, I'll commit this today. I'll look into an immediate MFC. > John > -- > John Hay -- John.Hay@icomtek.csir.co.za [...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 11:49:15 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 C6F1637B718 for ; Fri, 9 Mar 2001 11:49:11 -0800 (PST) (envelope-from pbrezny@purplecat.net) Received: from ci377160a (ci377160-a.ashvil1.nc.home.com [24.15.65.26]) by black.purplecat.net (8.8.8/8.8.8) with SMTP id OAA02277 for ; Fri, 9 Mar 2001 14:51:34 -0500 (EST) (envelope-from pbrezny@purplecat.net) Reply-To: From: "Peter Brezny" To: Subject: advice on network plan Date: Fri, 9 Mar 2001 14:48:12 -0500 Message-ID: <000c01c0a8d1$e0970a00$cc01a8c0@ashvil1.nc.home.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm reconfiguring a network I inherited and I'm looking for advice on the best way to get it done. We are connected to a single T1, that's fire walled through a bsd box. behind that, aside from a local area network, we have a wireless network that provides connections to several small companies we provide service and an internet connection to. There are a couple of boxes on the wireless network that currently have public ip's which I am working on statically nat'ing to private addresses so I can physically separate the public and private networks, firewalling everything behind the bsd box connected to the t1. To make things a little more interesting, some of our clients want to be able to reach their desktop using pcanywhere, which I'm currently planning on doing via static nat public ip to local network customer gateway and mpd-netgraph for M$ PPTP connection to the customer's internal network. here's a picture of what I'm thinking of: T1----fbsd#1_gw_nat_ipfw----10.x.x.x------+-----local network | 10.20.x.x | 10.30.x.x--fbsd-gw_ipfw--wireless ethernet--fbsd_gw_ipfw customer network customer network Your suggestions and criticisms are appreciated. Peter Brezny purplecat.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 12: 7: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 16B0337B71F; Fri, 9 Mar 2001 12:06:36 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f29K6Sh01668; Fri, 9 Mar 2001 15:06:28 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 9 Mar 2001 15:06:27 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Walter Goralski Cc: "'freebsd-hackers@freebsd.org'" , "'freebsd-net@freebsd.org'" Subject: Re: Generating SYN packets. 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 Generally speaking, the most portable way to generate IP packets is to do so using the raw IP socket interface. However, I've also successfully generated packets using IPDIVERT, BPF, and custom kernel modules :-). I found the IPDIVERT performed quite nicely and was useful for exploring firewall rules, as you can reinsert packets at arbitrary points in the ruleset. The key elements of the process involve opening an appropriate raw socket, generating the TCP SYN packet, and then sending the packet out on the raw socket. I'm including excerpts of appropriate code below. If you decide to use some of it, feel free to attach the 2-clause BSD license at the bottom of the file to your resulting code. :-) Opening the socket is fairly straight-forward: socket_raw = socket(PF_INET, SOCK_RAW, IPPROTO_RAW); if (socket_raw == -1) { perror("socket"); return (-1); } There are a few socket options you should sec. This includes IP_OPTIONS to disable any existing IP options: error = setsockopt(socket_raw, IPPROTO_IP, IP_OPTIONS, NULL, 0); if (error) { perror("setsockopt"); return (-1); } Also, IP_HDRINCL to indicate to the IP stack that you're going to include a complete IP header in your packet, so it shouldn't prepend one: int ip_hdrincl = 1; error = setsockopt(socket_raw, IPPROTO_IP, IP_HDRINCL, (char *)&ip_hdrincl, sizeof(ip_hdrincl)); if (error) { perror("setsockopt"); exit(-1); } Depending on how long you're going to have the socket open for, you may want to close the read component of the socket or the buffers there will fill up with other IP garbage coming off the network, including ICMP, etc. error = shutdown(socket_raw, SHUT_RD); if (error) { perror("shutdown"); exit(-1); } Assembling the TCP packet is the more tricky part. There are two important parts: first, filling in the necessary IP and TCP header information, and second, generating the necessary checksums. You can also optionally throw in TCP options, such as MSS negotiation, SACK negotiation, and things like ECN support. Here's some pseudo-code that covers some of this, but you'll need to tweak it as needed. It assumes that the provided struct in_addr's are already in network byte order, but not the port numbers: struct tcphdr_pseudo { u_long thp_from; u_long thp_to; char thp_zero; char thp_proto; u_short thp_len; struct tcphdr thp_tcphdr; }; ... char *buf; int buflen; struct ip *ip; struct tcphdr *tcphdr; struct tcphdr_pseudo tcphdr_pseudo; bzero(buf, buflen); ip = (struct ip *) buf; tcphdr = (struct tcphdr *) (ip + 1); ip->ip_tos = 0; ip->ip_off = 0; ip->ip_p = IPPROTO_TCP; ip->ip_hl = sizeof(struct ip) >> 2; ip->ip_v = 4; ip->ip_len = ntohs(htons(sizeof(struct ip) + sizeof(struct tcphdr))); ip->ip_src = from; ip->ip_dst = to; ip->ip_ttl = 255; ip->ip_sum = 0; ip->ip_id = random(); I usually borrow the IP checksumming routing from /sbin/ping, sticking it in a seperate source file, and naming the function in_cksum(), taking two arguments: a pointer to the data, and size of the data. Generate the IP-layer checksum first. ip->ip_sum = in_cksum((u_short *)ip, sizeof(struct ip)); Now fill in the TCP header. memset(tcphdr, '\0', sizeof(*tcphdr)); tcphdr->th_sport = htons(12312); tcphdr->th_dport = htons(toport); tcphdr->th_seq = htonl(123123123); tcphdr->th_ack = 0; tcphdr->th_off = 5; tcphdr->th_flags = TCP_SYN; tcphdr->th_win = 1024; /* arbitrary */ tcphdr->th_urp = 0; tcphdr->th_sum = 0; Next, you'll need to generate the TCP checksum -- to do this, fill in the pseudo-header using the same fields as the real TCP and IP headers, and set the TCP header checksum to the in_cksum() of the psuedo-header: tcphdr_pseudo.thp_from = ip->ip_src.s_addr; tcphdr_pseudo.thp_to = ip->ip_dst.s_addr; tcphdr_pseudo.thp_zero = 0; tcphdr_pseudo.thp_tcphdr = *tcphdr; tcphdr_pseudo.thp_proto = IPPROTO_TCP; tcphdr_pseudo.thp_len = htons(sizeof(struct tcphdr)); tcphdr->th_sum = in_cksum((u_short *) &tcphdr_pseudo, sizeof(tcphdr_pseudo)); The final length of the packet is sizeof(struct ip) + sizeof(struct tcphdr). Note that I did not initialize the MSS TCP option, and that the window size I selected is probably inappropriate. Finally, I want to send the packet out over the previously opened raw socket: int outlen; outlen = sendto(socket_raw, buf, len, 0, (struct sockaddr *) sa, sizeof(*sa)); if (outlen != len) perror("sendto"); As noted above, a license is attached below. This is fairly straight-forward code, and you can probably find similar stuff in various Stevens books, which I would highly recommend as a source of further information. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services /*- * Copyright (c) 1999, 2000, 2001 Robert N. M. Watson * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * $FreeBSD: $ */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 12: 8:25 2001 Delivered-To: freebsd-net@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 5628F37B718; Fri, 9 Mar 2001 12:08:15 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f29K88w02786; Fri, 9 Mar 2001 12:08:08 -0800 From: "Jonathan Graehl" To: "Walter Goralski" Cc: "Freebsd-Net" , "freebsd-Arch" Subject: missing #includes in /usr/include headers (was RE: Generating SYN packets.) Date: Fri, 9 Mar 2001 12:08:17 -0800 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org cd /usr/ports/net/nemesis make install Nemesis (http://www.packetninja.net/nemesis/) is a command line tool that can easily generate syn packets; if you want a flood, write a script. There is also /usr/ports/net/libnet http://www.packetfactory.net/Projects/Libnet/ - it is used by nemesis and is supposed to provide simplified cross-platform support for low level packet building/injection. Specific to your problem: it seems that requires , but does not #include it. n_long is defined in in_systm.h and used in ip_icmp.h and ip.h (not tcp.h) I have complained without response (on freebsd-arch, maybe not the right place) of similar problems with the /usr/include headers - while they include some of their prerequisites, they seem to assume that you have already included several other headers. For instance, requires tcp.h but does not include it, udp_var.h requires udp.h and ip_var.h, icmp_var.h requires ip_icmp.h, ip.h, and in_systm.h ... and probably others that I did not notice since I had earlier included them for other purposes. There seemed to be code that should have been wrapped in an #ifdef KERNEL, although I didn't feel like #ifdefing it out and doing a make world to test. Correcting these compile errors in the headers requires some tiresome find/grep work, although I suppose the whole process of finding missing #includes could be (semi)automated. find . -name '*.[ch]*' -exec grep -H $1 {} \; Very few of the header files include their prereqs, although they are #ifdef wrapped to prevent re-inclusion: find /usr/include -name '*.h' -exec gcc -c -xc {} -o /dev/null \; gives reams of error messages. > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Walter Goralski > Sent: Friday, March 09, 2001 8:04 AM > To: 'freebsd-hackers@freebsd.org'; 'freebsd-net@freebsd.org' > Subject: Generating SYN packets. > > > Folks: > > Andreas Klemm, who ported cflowd to FreeBSD, suggested I use this vehicle to > see if I could get some help. > > I am a course developer for Juniper Networks, and I have just written a > 2-day advanced course on router firewall filters (this is one reason for the > cflowd). > > We have participants in a strictly closed lab environment configuring > filters to stop spoofs, smurf, fraggle, etc. In order to show they work, we > also have a 4.2 FreeBSD laptop that can launch smurf, fraggle, etc. at the > routers and the instructor's PC. > > The missing piece has been DOS SYN attacks. I have the really common > "synk4.c" source that is all over the Web, but I get errors when I try to > compile it ("it's the linux includes" someone told me). Now, I last used my > C programming skills in the 80s on a Silent 700 teletype and a 3B20 mini, so > I tried playing around with "programming by analogy" (hey, it sometimes > works). I took fraggle.c and tried to substitute a tcp header for the udp > header. Anyway, the compiler tells me there is a syntax error in tcp.h > (right before the "n_long"), which strikes me as odd. Then it says I am > using an "incomplete type" and dereferences all of my pointers. Sometimes I > can force a compile and lonk, but none of my paramters get plugged into the > packets when I use it. > > So: anybody got a quick and dirty SYN packet generator out there? A version > of synk4 that runs on 4.2? An executable? > > I even tried to install hping2 from the FreeBSD ports collection, but of > course *that* won't run either. (It says my ep0 interface is not defined (!) > and seems to try to use lo.) If I use "make install," I get these run time > errors; if I use "./configure" and then "make" I get compile errors, also > about "overlapping" includes. (***Are my include files all screwed up?*** > How could I tell?) > > But the cflowd and RADIUS servers, also installed a couple of weeks ago from > these ports, run merrily along, so the basic system seems to be intact. I > don't think my programming efforts have scrammed the system (and I don't > have the cd-rom, since it's a company laptop), but I am very worried that I > have somehow harmed the .h files. > > Meanwhile, I'm re-learning BSD socket coding. But this might be faster if > anyone can help. > > (As a note, if anyone out there works for Juniper, I can configure remote > access to the laptop if required.) > > Walter Goralski > walterg@juniper.net > 952-938-4483 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 12:21:39 2001 Delivered-To: freebsd-net@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id 9057137B718 for ; Fri, 9 Mar 2001 12:21:36 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f29KLWw03033; Fri, 9 Mar 2001 12:21:32 -0800 From: "Jonathan Graehl" To: "Freebsd-Net" Cc: "Walter Goralski" Subject: generating SYN packets with /usr/ports/net/nemesis and sh Date: Fri, 9 Mar 2001 12:21:41 -0800 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org #!/bin/sh i=50000; while [ $i -lt 50100 ]; do nemesis-tcp -S 209.68.199.246 -D 209.68.199.242 -fS -x $i -y 25; i=$(($i + 1)); done ... seems to work fine; a perl script would give a more legible for loop though ;) -- Jonathan Graehl email: jonathan@graehl.org web: http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 14:40:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D29B337B718; Fri, 9 Mar 2001 14:40:14 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA25011; Fri, 9 Mar 2001 23:40:09 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Jonathan Graehl" Cc: "Walter Goralski" , "Freebsd-Net" , "freebsd-Arch" Subject: Re: missing #includes in /usr/include headers (was RE: Generating SYN packets.) References: From: Dag-Erling Smorgrav Date: 09 Mar 2001 23:40:08 +0100 In-Reply-To: "Jonathan Graehl"'s message of "Fri, 9 Mar 2001 12:08:17 -0800" Message-ID: Lines: 18 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Jonathan Graehl" writes: > Specific to your problem: it seems that requires > , but does not #include it. n_long is defined in > in_systm.h and used in ip_icmp.h and ip.h (not tcp.h) I have > complained without response (on freebsd-arch, maybe not the right > place) of similar problems with the /usr/include headers - while > they include some of their prerequisites, they seem to assume that > you have already included several other headers. "If you want Linux, you know where to find it" The real bug is that the author of that software is a Linux weenie, and Linux header files are broken in such a way that they mask the fact that his program does not include the proper headers. DES -- Dag-Erling Smorgrav - des@ofug.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 9 15:15:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id D611E37B719 for ; Fri, 9 Mar 2001 15:15:42 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f29NFbw04145; Fri, 9 Mar 2001 15:15:37 -0800 From: "Jonathan Graehl" To: "Freebsd-Net" Cc: "Walter Goralski" Subject: RE: generating SYN packets with /usr/ports/net/nemesis and sh Date: Fri, 9 Mar 2001 15:15:49 -0800 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Replying to self (multiple personality disorder?): Once caveat ... if you're trying to simulate the resource-exhaustion effects of a true SYN flood (rather than simply testing the ability of your firewall / intrusion detection system to react to a flood), then you will need to prevent autogeneration of RSTs by your TCP stack in reply to the TCP SYN ACK replies from the host you are attacking. This could be accomplished either with firewall rules (I haven't done this on FreeBSD, but I believe you use ipfw). It is more easily accomplished with: sysctl -w net.inet.tcp.blackhole=1 (udp.blackhole presumably surpresses generation of ICMP port unreachable when there is nobody listening on a UDP port) Traditionally .blackhole has been used to make port scanners' lives more difficult (they will have to concurrently-initiate/manage/time-out pending probes, or else proceed extremely slowly if using the default TCP connection timeout), but tcp.blackhole can also facilitate an effective SYN flood attack. For several years, most production servers will use tcp syncookies when faced with a flood of syns ... the server, using no local state, sends a SYN ACK with the server initial sequence number chosen to encode various state, and present an unforgeable secret hash, so that SYN ACKs from the initiator can be verified without having to remember anything about the embryonic connection. > #!/bin/sh > i=50000; while [ $i -lt 50100 ]; do nemesis-tcp -S 209.68.199.246 -D > 209.68.199.242 -fS -x $i -y 25; i=$(($i + 1)); done > > ... seems to work fine; a perl script would give a more legible for > loop though > ;) > > -- > Jonathan Graehl > email: jonathan@graehl.org > web: http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Mar 9 18:36:49 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 2586D37B71A for ; Fri, 9 Mar 2001 18:36:47 -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 f2A35Vg14155 for ; Fri, 9 Mar 2001 21:05:32 -0600 (CST) (envelope-from nick@rogness.net) Date: Fri, 9 Mar 2001 21:05:31 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: freebsd-net@freebsd.org Subject: same interface Route Cache 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 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. It may be implemented nicely as a sysctl var or maybe a ifconfig option? 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 9 18:43:45 2001 Delivered-To: freebsd-net@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-158.dsl.lsan03.pacbell.net [63.207.60.158]) by hub.freebsd.org (Postfix) with ESMTP id 3F83337B719 for ; Fri, 9 Mar 2001 18:43:43 -0800 (PST) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F2E9066BCD; Fri, 9 Mar 2001 18:43:42 -0800 (PST) Date: Fri, 9 Mar 2001 18:43:42 -0800 From: Kris Kennaway To: Jonathan Graehl Cc: Walter Goralski , Freebsd-Net Subject: Re: missing #includes in /usr/include headers (was RE: Generating SYN packets.) Message-ID: <20010309184342.A13688@mollari.cthul.hu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jonathan@graehl.org on Fri, Mar 09, 2001 at 12:08:17PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 09, 2001 at 12:08:17PM -0800, Jonathan Graehl wrote: > Specific to your problem: it seems that requires , > but does not #include it. n_long is defined in in_systm.h and used in ip_icmp.h > and ip.h (not tcp.h) I have complained without response (on freebsd-arch, maybe > not the right place) of similar problems with the /usr/include headers - while Correct, -arch is for discussion of new architectural features. > they include some of their prerequisites, they seem to assume that you have > already included several other headers. This is considered to be the correct behaviour. Kris --OXfL5xGRrasGEqWY 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 iD8DBQE6qZTeWry0BWjoQKURAhUuAJ9G7daZrxPgRpDgolgi/6GiQ/JruwCgiaF8 wmvIdnnPBw4g6EeMa7Reulw= =dM75 -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 10 5:41: 7 2001 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id B588437B719; Sat, 10 Mar 2001 05:41:06 -0800 (PST) To: freebsd-net@freebsd.org From: Majordomo@FreeBSD.ORG Subject: Majordomo results Reply-To: Majordomo@FreeBSD.ORG Message-Id: <20010310134106.B588437B719@hub.freebsd.org> Date: Sat, 10 Mar 2001 05:41:06 -0800 (PST) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -- >>>> subscribe freebsd-net **** You are trying to subscribe one mailing list another. **** Your subscription request has been rejected. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 10 6:51: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: from server1.manmail.norlight.net (server1.manmail.norlight.net [207.170.4.2]) by hub.freebsd.org (Postfix) with SMTP id 7FEBA37B719 for ; Sat, 10 Mar 2001 06:50:59 -0800 (PST) (envelope-from hyun@staff.norlight.net) Received: (qmail 1997 invoked from network); 10 Mar 2001 14:50:30 -0000 Received: from gw-app-eng.norlight.net (HELO staff.norlight.net) (207.170.1.30) by server1.manmail.norlight.net with SMTP; 10 Mar 2001 14:50:30 -0000 Message-ID: <3AAA3F52.8AD19E74@staff.norlight.net> Date: Sat, 10 Mar 2001 08:50:58 -0600 From: Hyunseog Ryu Organization: Norlight Telecommunications X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Christophe Varaillon Cc: "Andy [TECC NOPS]" , freebsd-net@FreeBSD.ORG Subject: Re: - TFTP: Time out - References: Content-Type: multipart/mixed; boundary="------------E8A859026FE4E290ADF36910" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------E8A859026FE4E290ADF36910 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok. guys First, you only need one tftp configuration from /etc/inetd.conf file Either use /tftpboot or /usr/home/jcv. And killall -HUP inetd Then use following. get /c3640-i-mz.120-9.bin Remember that if you use -s /directory, actually tftp consider /directory as it's own / (root) directory. -s is used to change it's root directory to other . Because tftpd actually try to read "/tftpboot/c3640-i-mz.120-9.bin" from /tftpboot/tftpboot/c3640-i-mz.120-9.bin, it didn't work. Hyun Jean-Christophe Varaillon wrote: > > It is still not working between my machine and the cisco #( > > So, let summurize what I should fixe: > > === Make my FreeBSD machine as a tftp server === > > vi /etc/inetd.conf: > -- > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /usr/home/jcv > -- > > -- > homer# ps auwx | grep inetd > root 108 0.0 0.5 1044 604 ?? Is 27Feb01 0:00.19 inetd -wW > jcv 23629 0.0 0.9 1548 1136 pc I+ 4:15PM 0:00.02 vi > /etc/inetd.conf > homer# kill -HUP 108 > -- > > I can see that the server is actually listening: > -- > %netstat -a | grep tftp > udp4 0 0 *.tftp *.* > % > -- > > ===== TFTP LOCALHOST TEST ===== > %su > Password: > > homer# cd /tftpboot > homer# ls -l > total 8544 > -rw-r--r-- 1 nobody nobody 4991380 Mar 6 15:39 > c3640-i-mz.120-7.XK1.bin > -rw-r--r-- 1 nobody nobody 3731009 Mar 6 15:03 c3640-i-mz.120-9.bin > > homer# cd /usr/home/jcv > homer# ls -l c3640-i-mz.120-9.bin > -rw-r--r-- 1 nobody nobody 0 Mar 6 16:03 c3640-i-mz.120-9.bin > homer# tftp 127.0.0.1 > > tftp> status > Connected to 127.0.0.1. > Mode: netascii Verbose: off Tracing: off > Rexmt-interval: 5 seconds, Max-timeout: 25 seconds > tftp> get /tftpboot/c3640-i-mz.120-9.bin > Transfer timed out. > > tftp> quit > > homer#vi /var/log/messages > ... > Mar 6 16:29:03 homer tftpd[23756]: read: Connection refused > Mar 6 16:29:08 homer tftpd[23758]: read: Connection refused > > ================================= > > Oh by the way, when you make your IOS upgrade form your tftp server to > your router, you don't have to creat a blank file in flash ? > > Regards, > Jean-Christophe. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --------------E8A859026FE4E290ADF36910 Content-Type: text/x-vcard; charset=us-ascii; name="hyun.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Hyunseog Ryu Content-Disposition: attachment; filename="hyun.vcf" begin:vcard n:Ryu;Hyunseig tel;fax:262-792-7655 tel;work:262-792-7965 x-mozilla-html:FALSE org:Norlight Telecommunications;Applications Engineering adr:;;275 North Corporate Drive;Brookfield;WI;53045;USA version:2.1 email;internet:hyun@staff.norlight.net title:Network Engineer note:MCSE, CCDA fn:Hyunseig Ryu end:vcard --------------E8A859026FE4E290ADF36910-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 10 6:54: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from server1.manmail.norlight.net (server1.manmail.norlight.net [207.170.4.2]) by hub.freebsd.org (Postfix) with SMTP id 8AA4A37B718 for ; Sat, 10 Mar 2001 06:54:03 -0800 (PST) (envelope-from hyun@staff.norlight.net) Received: (qmail 2019 invoked from network); 10 Mar 2001 14:53:34 -0000 Received: from gw-app-eng.norlight.net (HELO staff.norlight.net) (207.170.1.30) by server1.manmail.norlight.net with SMTP; 10 Mar 2001 14:53:34 -0000 Message-ID: <3AAA400A.966DA35C@staff.norlight.net> Date: Sat, 10 Mar 2001 08:54:02 -0600 From: Hyunseog Ryu Organization: Norlight Telecommunications X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Christophe Varaillon Cc: "Andy [TECC NOPS]" , freebsd-net@FreeBSD.ORG Subject: Re: - TFTP: Time out - References: Content-Type: multipart/mixed; boundary="------------AA5A88502EA07219E35A2420" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------AA5A88502EA07219E35A2420 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Check the /etc/hosts.allow file. Put this in the first of the file. ALL : localhost 127.0.0.1 : allow ALL : your_router_ip_address : allow ALL : your_fbsd_ip_address : allow Hyun Jean-Christophe Varaillon wrote: > > On Tue, 6 Mar 2001, Andy [TECC NOPS] wrote: > > > OK, from that all seems fine. But remeber > > that doing %tftp localhost and then trying > > a local get failed, so I suspect that there > > is something wrong with the local setup somewhere. > > > > Right, how come you have two lines beginning "tftp" > > in your /etc/inetd.conf ?? Thought there should be > > only one (the one ending -s /tftpboot). > > I uncommented the first line and I add another line to allow also an tftp > access to /usr/home/jcv. > > > Big point here is that inetd is invoked -wW so it's > > wrapping. Check /etc/hosts.allow (or is it > > /usr/local/etc/hosts.allow > > these days? dunno, check up on it). > > Do a man inetd and check this yourself. > > -wW turn on TCP Wrapping. > By "vi /etc/inted.conf" we can see that tftp is using UDP > > wrapping is used in a matter of security, no ? > If yes, my router is , for the moment just close to my desk an it is not a > remote router. > > > Try doing %telnet localhost 69 and see if your > > daemon will even allow a connection. > > Even as a super user, the daemon does not allow the connection. > --- > %telnet localhost 69 > Trying 127.0.0.1... > telnet: connect to address 127.0.0.1: Connection refused > Trying ::1... > telnet: connect to address ::1: Connection refused > telnet: Unable to connect to remote host > % > --- > > If none of these we'll try again > > > > Regards > > Andy > > > > > > > -----Original Message----- > > > From: owner-freebsd-net@FreeBSD.ORG > > > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Jean-Christophe > > > Varaillon > > > Sent: 06 March 2001 16:37 > > > To: Andy [TECC NOPS] > > > Cc: freebsd-net@FreeBSD.ORG > > > Subject: RE: - TFTP: Time out - > > > > > > > > > It is still not working between my machine and the cisco #( > > > > > > So, let summurize what I should fixe: > > > > > > === Make my FreeBSD machine as a tftp server === > > > > > > vi /etc/inetd.conf: > > > -- > > > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot > > > tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /usr/home/jcv > > > -- > > > > > > -- > > > homer# ps auwx | grep inetd > > > root 108 0.0 0.5 1044 604 ?? Is 27Feb01 0:00.19 inetd -wW > > > jcv 23629 0.0 0.9 1548 1136 pc I+ 4:15PM 0:00.02 vi > > > /etc/inetd.conf > > > homer# kill -HUP 108 > > > -- > > > > > > I can see that the server is actually listening: > > > -- > > > %netstat -a | grep tftp > > > udp4 0 0 *.tftp *.* > > > % > > > -- > > > > > > ===== TFTP LOCALHOST TEST ===== > > > %su > > > Password: > > > > > > homer# cd /tftpboot > > > homer# ls -l > > > total 8544 > > > -rw-r--r-- 1 nobody nobody 4991380 Mar 6 15:39 > > > c3640-i-mz.120-7.XK1.bin > > > -rw-r--r-- 1 nobody nobody 3731009 Mar 6 15:03 c3640-i-mz.120-9.bin > > > > > > homer# cd /usr/home/jcv > > > homer# ls -l c3640-i-mz.120-9.bin > > > -rw-r--r-- 1 nobody nobody 0 Mar 6 16:03 c3640-i-mz.120-9.bin > > > homer# tftp 127.0.0.1 > > > > > > tftp> status > > > Connected to 127.0.0.1. > > > Mode: netascii Verbose: off Tracing: off > > > Rexmt-interval: 5 seconds, Max-timeout: 25 seconds > > > tftp> get /tftpboot/c3640-i-mz.120-9.bin > > > Transfer timed out. > > > > > > tftp> quit > > > > > > homer#vi /var/log/messages > > > ... > > > Mar 6 16:29:03 homer tftpd[23756]: read: Connection refused > > > Mar 6 16:29:08 homer tftpd[23758]: read: Connection refused > > > > > > ================================= > > > > > > Oh by the way, when you make your IOS upgrade form your tftp server to > > > your router, you don't have to creat a blank file in flash ? > > > > > > > > > Regards, > > > Jean-Christophe. > > > > > > > > > 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 --------------AA5A88502EA07219E35A2420 Content-Type: text/x-vcard; charset=us-ascii; name="hyun.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Hyunseog Ryu Content-Disposition: attachment; filename="hyun.vcf" begin:vcard n:Ryu;Hyunseig tel;fax:262-792-7655 tel;work:262-792-7965 x-mozilla-html:FALSE org:Norlight Telecommunications;Applications Engineering adr:;;275 North Corporate Drive;Brookfield;WI;53045;USA version:2.1 email;internet:hyun@staff.norlight.net title:Network Engineer note:MCSE, CCDA fn:Hyunseig Ryu end:vcard --------------AA5A88502EA07219E35A2420-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 10 8:34: 6 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 5546237B719 for ; Sat, 10 Mar 2001 08:34:02 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 3405 invoked by uid 666); 10 Mar 2001 16:35:00 -0000 Received: from i080-128.nv.iinet.net.au (HELO elischer.org) (203.59.80.128) by mail.m.iinet.net.au with SMTP; 10 Mar 2001 16:35:00 -0000 Message-ID: <3AAA575C.4985CA7D@elischer.org> Date: Sat, 10 Mar 2001 08:33:32 -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: Harti Brandt Cc: julian@freebsd.org, net@freebsd.org Subject: Re: Netgraph is leaking node references 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 Harti Brandt wrote: > > Hi, > > it seems that netgraph is leaking references. One simple experiment to do > is to repeat 'ngctl types' several times: [fix just checked in] I won't say what it was exactlt but I must have been REALLY TIRED when I checked that bug in.. send pointy hat and C language tutorial to: julian -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 10 12:42:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 843BC37B718; Sat, 10 Mar 2001 12:42:51 -0800 (PST) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f2AKgjC03194; Sat, 10 Mar 2001 13:42:50 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200103102042.f2AKgjC03194@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: wpaul@FreeBSD.ORG (Bill Paul) Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: call for testers: port aggregation netgraph module In-Reply-To: Your message of "Thu, 08 Feb 2001 13:25:09 PST." <20010208212509.E8D7D37B6AA@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Mar 2001 13:42:45 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Each link is checked once every second to see if the link is still up. >An attempt to send a packet over a dead link will cause the packet to >be shifted over to the next link in the bundle. Any chance this can be done through an async event rather than by polling? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 10 13: 2:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from et-gw.etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 29B8537B718; Sat, 10 Mar 2001 13:02:39 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by et-gw.etinc.com (8.9.3/8.9.3) with ESMTP id QAA85883; Sat, 10 Mar 2001 16:14:42 GMT (envelope-from dennis@etinc.com) Message-Id: <5.0.0.25.0.20010310161340.01fda9a0@mail.etinc.com> X-Sender: dennis@mail.etinc.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 10 Mar 2001 16:17:43 -0500 To: "Justin T. Gibbs" , wpaul@FreeBSD.ORG (Bill Paul) From: Dennis Subject: Re: call for testers: port aggregation netgraph module Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG In-Reply-To: <200103102042.f2AKgjC03194@aslan.scsiguy.com> References: 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 At 03:42 PM 03/10/2001, Justin T. Gibbs wrote: > >Each link is checked once every second to see if the link is still up. > >An attempt to send a packet over a dead link will cause the packet to > >be shifted over to the next link in the bundle. > >Any chance this can be done through an async event rather >than by polling? I've been meaning to ask about this...is there a reason that ethernet drivers dont call if_up and if_down like serial drivers on cable events? This is needed for load balancing so that the UP flag can be used instead of polling or an event. Of course a polling protocol is needed also. Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 10 13: 7: 3 2001 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 2284F37B718; Sat, 10 Mar 2001 13:07:00 -0800 (PST) Subject: Re: call for testers: port aggregation netgraph module In-Reply-To: <200103102042.f2AKgjC03194@aslan.scsiguy.com> from "Justin T. Gibbs" at "Mar 10, 2001 01:42:45 pm" To: gibbs@scsiguy.com (Justin T. Gibbs) Date: Sat, 10 Mar 2001 13:07:00 -0800 (PST) Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010310210700.2284F37B718@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >Each link is checked once every second to see if the link is still up. > >An attempt to send a packet over a dead link will cause the packet to > >be shifted over to the next link in the bundle. > > Any chance this can be done through an async event rather > than by polling? If there was, I would have done it. MII transceivers can't send an interrupt back through the MAC unless the MAC supports it, and many don't. Consequently, the MII spec says nothing about async notification of anything. You have to poll. Resistance is futile. Gigabit MII transceivers are another matter. Polling and gigabit speeds don't go to gether very well. All of the GMII transceivers I've seen (Tigon and SysKonnect cards) have an signal pin of some kind that's wired to an external interrupt source pin on the MAC. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 10 13:37:53 2001 Delivered-To: freebsd-net@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 80C9037B718; Sat, 10 Mar 2001 13:37:49 -0800 (PST) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f2ALbmC04064; Sat, 10 Mar 2001 14:37:48 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200103102137.f2ALbmC04064@aslan.scsiguy.com> To: wpaul@FreeBSD.ORG (Bill Paul) Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: call for testers: port aggregation netgraph module In-Reply-To: Your message of "Sat, 10 Mar 2001 13:07:00 PST." <20010310210700.2284F37B718@hub.freebsd.org> Date: Sat, 10 Mar 2001 14:37:48 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> >Each link is checked once every second to see if the link is still up. >> >An attempt to send a packet over a dead link will cause the packet to >> >be shifted over to the next link in the bundle. >> >> Any chance this can be done through an async event rather >> than by polling? > >If there was, I would have done it. Perhaps it would be best to create an interface that allows async notification but to provide a default implementation of the interface that polls? This would allow hardware that has a mechanism to detect the state change to override the default method while all other cards "just work" without modification by polling. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Mar 10 14:31:53 2001 Delivered-To: freebsd-net@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 6EF1237B718; Sat, 10 Mar 2001 14:31:50 -0800 (PST) Subject: Re: call for testers: port aggregation netgraph module In-Reply-To: <200103102137.f2ALbmC04064@aslan.scsiguy.com> from "Justin T. Gibbs" at "Mar 10, 2001 02:37:48 pm" To: gibbs@scsiguy.com (Justin T. Gibbs) Date: Sat, 10 Mar 2001 14:31:50 -0800 (PST) Cc: hackers@FreeBSD.ORG, net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010310223150.6EF1237B718@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> >Each link is checked once every second to see if the link is still up. > >> >An attempt to send a packet over a dead link will cause the packet to > >> >be shifted over to the next link in the bundle. > >> > >> Any chance this can be done through an async event rather > >> than by polling? > > > >If there was, I would have done it. > > Perhaps it would be best to create an interface that allows async > notification but to provide a default implementation of the interface > that polls? This would allow hardware that has a mechanism to detect > the state change to override the default method while all other > cards "just work" without modification by polling. Perhaps somebody who is not me should investigate this then. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message