From owner-freebsd-net Sun Sep 9 21:10:59 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id B595F37B401 for ; Sun, 9 Sep 2001 21:10:46 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id NAA19456 for ; Mon, 10 Sep 2001 13:11:12 +0900 (JST) Date: Mon, 10 Sep 2001 13:10:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: freebsd-net@FreeBSD.ORG Subject: Forward: Re: ping gif0 References: <002b01c135a1$5aa23070$1200a8c0@gsicomp.on.ca> <003601c13718$24c99ce0$1200a8c0@gsicomp.on.ca> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Mon_Sep_10_13:10:46_2001-1" X-Dispatcher: imput version 980905(IM100) Lines: 232 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Multipart_Mon_Sep_10_13:10:46_2001-1 Content-Type: text/plain; charset=US-ASCII I'm forwarding a message directly to me, with a permission of the sender, because I myself do not have enough time to tackle this. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Mon_Sep_10_13:10:46_2001-1 Content-Type: message/rfc822 Message-ID: <003601c13718$24c99ce0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: References: <002b01c135a1$5aa23070$1200a8c0@gsicomp.on.ca> Subject: Re: ping gif0 Date: Thu, 6 Sep 2001 17:08:57 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01C136F6.9D4E8CB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C136F6.9D4E8CB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > >>>>> On Tue, 4 Sep 2001 20:26:04 -0400, > >>>>> "Matthew Emmerton" said: > > > I've got a question for all of you net hackers. > > When I configure a gif interface, why can't I ping the local endpoint on the > > inside of the tunnel? I've just been through hell and back trying to get > > some IPSec tunnels created (they're working now, thanks to all those who > > helped me out), and this was one of my big stumbling blocks -- since I > > couldn't ping the local or remote endpoint of the gif tunnel, I spent much > > time chasing down problems with gif when it wasn't a problem at all. > > Please be more specific. I guess we need at least > > - the version of the OS > - the result of 'ifconfig -a' > - the result of 'gifconfig -a' > - the result of 'netstat -rnal' > - the exact output of ping (do not *describe* the situation, please. > just copy and paste the output -by script(1) etc-) The information you requested is attached. I've also included a 'netstat -p ipsec' and the output from 'setkey -D' and 'setkey -PD'. This is the configuration for system on the one end of the tunnel; the other configuration is identical with the expected IP address changes. Telnet and other interactive sessions work fine across the link (and are ESP encapsulated), but ping to the endpoints or remote systems do not. -- Matt Emmerton ------=_NextPart_000_0033_01C136F6.9D4E8CB0 Content-Type: text/plain; name="gif-debug.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="gif-debug.txt" Script started on Thu Sep 6 10:32:28 2001=0A= waterloo.heers.on.ca# uname -a=0A= FreeBSD waterloo.heers.on.ca 4.3-RELEASE-p14 FreeBSD 4.3-RELEASE-p14 #4: = Tue Aug 28 23:46:59 EDT 2001 = root@waterloo.heers.on.ca:/usr/src/sys/compile/HEERSNAT i386=0A= waterloo.heers.on.ca# gifconfig -a=0A= gif0: flags=3D8011 mtu 1280=0A= inet 10.0.2.130 --> 10.0.2.2 netmask 0xffffffff =0A= physical address inet 209.167.75.123 --> 209.167.75.124=0A= gif1: flags=3D8010 mtu 1280=0A= physical address --> =0A= gif2: flags=3D8010 mtu 1280=0A= physical address --> =0A= gif3: flags=3D8010 mtu 1280=0A= physical address --> =0A= gif4: flags=3D8010 mtu 1280=0A= physical address --> =0A= gif5: flags=3D8010 mtu 1280=0A= physical address --> =0A= waterloo.heers.on.ca# ifconfig -a=0A= rl0: flags=3D8843 mtu 1500=0A= ether 00:50:ba:56:16:3c =0A= media: autoselect (none) status: active=0A= supported media: autoselect 100baseTX 100baseTX = 10baseT/UTP 10baseT/UTP 100baseTX =0A= rl1: flags=3D8843 mtu 1500=0A= inet 10.0.2.129 netmask 0xfffffff0 broadcast 10.0.2.143=0A= ether 00:50:ba:56:16:37 =0A= media: autoselect (100baseTX ) status: active=0A= supported media: autoselect 100baseTX 100baseTX = 10baseT/UTP 10baseT/UTP 100baseTX =0A= lp0: flags=3D8810 mtu 1500=0A= gif0: flags=3D8011 mtu 1280=0A= inet 10.0.2.130 --> 10.0.2.2 netmask 0xffffffff =0A= gif1: flags=3D8010 mtu 1280=0A= gif2: flags=3D8010 mtu 1280=0A= gif3: flags=3D8010 mtu 1280=0A= gif4: flags=3D8010 mtu 1280=0A= gif5: flags=3D8010 mtu 1280=0A= lo0: flags=3D8049 mtu 16384=0A= inet 127.0.0.1 netmask 0xff000000 =0A= tun0: flags=3D8151 mtu 1492=0A= inet 209.167.75.123 --> 171.68.187.1 netmask 0xffffff00 =0A= Opened by PID 158=0A= tun1: flags=3D8010 mtu 1500=0A= waterloo.heers.on.ca# netstat -rnal -f inet=0A= Routing tables=0A= =0A= Internet:=0A= Destination Gateway Flags Refs Use Netif = Expire=0A= default 171.68.187.1 UGSc 7 34558 tun0=0A= 10.0.2/26 10.0.2.2 UGSc 1 8521 gif0=0A= 10.0.2.2 10.0.2.130 UH 1 10 gif0=0A= 10.0.2.128/28 link#2 UC 0 0 rl1 = =3D>=0A= 10.0.2.129 0:50:ba:56:16:37 UHLW 0 22 lo0=0A= 10.0.2.137 0:40:5:df:5a:25 UHLW 0 116 rl1 = 415=0A= 10.0.2.138 0:40:5:df:37:97 UHLW 0 2 rl1 = 1042=0A= 10.0.2.139 0:40:5:de:b5:4c UHLW 2 7488 rl1 = 348=0A= 65.93.38.74 171.68.187.1 UGHW 2 34726 tun0=0A= 127.0.0.1 127.0.0.1 UH 0 12 lo0=0A= 171.68.187.1 209.167.75.123 UH 4 0 tun0=0A= 207.139.193.66 171.68.187.1 UGHW3 0 34560 tun0 = 3568=0A= 209.167.75.124 171.68.187.1 UGHW 1 34558 tun0=0A= waterloo.heers.on.ca# ping 10.0.2.2=0A= PING 10.0.2.2 (10.0.2.2): 56 data bytes=0A= ^C=0A= --- 10.0.2.2 ping statistics ---=0A= 15 packets transmitted, 0 packets received, 100% packet loss=0A= waterloo.heers.on.ca# ping 10.0.2.130=0A= PING 10.0.2.130 (10.0.2.130): 56 data bytes=0A= ping: sendto: Host is down=0A= ping: sendto: Host is down=0A= ping: sendto: Host is down=0A= ping: sendto: Host is down=0A= ping: sendto: Host is down=0A= ping: sendto: Host is down=0A= ^C=0A= --- 10.0.2.130 ping statistics ---=0A= 12 packets transmitted, 0 packets received, 100% packet loss=0A= waterloo.heers.on.ca# ping 10.0.2.1=0A= PING 10.0.2.1 (10.0.2.1): 56 data bytes=0A= ^C=0A= --- 10.0.2.1 ping statistics ---=0A= 8 packets transmitted, 0 packets received, 100% packet loss=0A= waterloo.heers.on.ca# ping 10.0.2.9=0A= PING 10.0.2.9 (10.0.2.9): 56 data bytes=0A= ^C=0A= --- 10.0.2.9 ping statistics ---=0A= 8 packets transmitted, 0 packets received, 100% packet loss=0A= waterloo.heers.on.ca# exit=0A= waterloo.heers.on.ca# netstat -p ipsec=0A= ipsec:=0A= 6913 inbound packets processed successfully=0A= 34 inbound packets violated process security policy=0A= 0 inbound packets with no SA available=0A= 0 invalid inbound packets=0A= 0 inbound packets failed due to insufficient memory=0A= 0 inbound packets failed getting SPI=0A= 0 inbound packets failed on AH replay check=0A= 0 inbound packets failed on ESP replay check=0A= 0 inbound packets considered authentic=0A= 0 inbound packets failed on authentication=0A= ESP input histogram:=0A= simple: 6913=0A= 8575 outbound packets processed successfully=0A= 0 outbound packets violated process security policy=0A= 0 outbound packets with no SA available=0A= 0 invalid outbound packets=0A= 0 outbound packets failed due to insufficient memory=0A= 0 outbound packets with no route=0A= ESP output histogram:=0A= simple: 8575=0A= waterloo.heers.on.ca# setkey -D=0A= 10.0.2.0/26[any] 10.0.2.128/28[any] any=0A= in ipsec=0A= esp/tunnel/209.167.75.124-209.167.75.123/require=0A= spid=3D5 seq=3D1 pid=3D3802=0A= refcnt=3D1=0A= 10.0.2.128/28[any] 10.0.2.0/26[any] any=0A= out ipsec=0A= esp/tunnel/209.167.75.123-209.167.75.124/require=0A= spid=3D6 seq=3D0 pid=3D3802=0A= refcnt=3D1=0A= waterloo.heers.on.ca# setkey -DP=0A= 209.167.75.123 209.167.75.124=0A= esp mode=3Dany spi=3D1001(0x000003e9) reqid=3D0(0x00000000)=0A= E: null=0A= replay=3D0 flags=3D0x00000040 state=3Dmature seq=3D1 pid=3D3803=0A= created: Sep 4 18:04:50 2001 current: Sep 6 17:09:55 2001=0A= diff: 169505(s) hard: 0(s) soft: 0(s)=0A= last: Sep 6 17:08:14 2001 hard: 0(s) soft: 0(s)=0A= current: 986988(bytes) hard: 0(bytes) soft: 0(bytes)=0A= allocated: 13608 hard: 0 soft: 0=0A= refcnt=3D2=0A= 209.167.75.124 209.167.75.123=0A= esp mode=3Dany spi=3D1000(0x000003e8) reqid=3D0(0x00000000)=0A= E: null=0A= replay=3D0 flags=3D0x00000040 state=3Dmature seq=3D0 pid=3D3803=0A= created: Sep 4 18:04:50 2001 current: Sep 6 17:09:55 2001=0A= diff: 169505(s) hard: 0(s) soft: 0(s)=0A= last: Sep 6 17:08:14 2001 hard: 0(s) soft: 0(s)=0A= current: 2078652(bytes) hard: 0(bytes) soft: 0(bytes)=0A= allocated: 10772 hard: 0 soft: 0=0A= refcnt=3D1=0A= ------=_NextPart_000_0033_01C136F6.9D4E8CB0-- --Multipart_Mon_Sep_10_13:10:46_2001-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 3:55: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id BE23C37B408 for ; Mon, 10 Sep 2001 03:55:01 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id f8AAsxi70415; Mon, 10 Sep 2001 11:55:00 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id f8AAsnJ57600; Mon, 10 Sep 2001 11:54:49 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200109101054.f8AAsnJ57600@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Forward: Re: ping gif0 In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Mon, 10 Sep 2001 13:10:46 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Sep 2001 11:54:49 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I'm forwarding a message directly to me, with a permission of the > sender, because I myself do not have enough time to tackle this. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp [.....] > > > I've got a question for all of you net hackers. > > > When I configure a gif interface, why can't I ping the local endpoint on > the > > > inside of the tunnel? I've just been through hell and back trying to > get > > > some IPSec tunnels created (they're working now, thanks to all those who > > > helped me out), and this was one of my big stumbling blocks -- since I > > > couldn't ping the local or remote endpoint of the gif tunnel, I spent > much > > > time chasing down problems with gif when it wasn't a problem at all. [.....] The local endpoint can't be pinged unless you've got a route for it... that's just the way the routing code works. You can ping the local address for an Ethernet interface, but that's just because the hardware returns such packets. Adding a loopback route or address alias is the way to handle this. -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 5:52: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id C440537B401 for ; Mon, 10 Sep 2001 05:52:01 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id VAA23503; Mon, 10 Sep 2001 21:52:19 +0900 (JST) Date: Mon, 10 Sep 2001 21:51:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Somers Cc: freebsd-net@FreeBSD.ORG Subject: Re: Forward: Re: ping gif0 In-Reply-To: <200109101054.f8AAsnJ57600@hak.lan.Awfulhak.org> References: <200109101054.f8AAsnJ57600@hak.lan.Awfulhak.org> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 33 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Mon, 10 Sep 2001 11:54:49 +0100, >>>>> Brian Somers said: > The local endpoint can't be pinged unless you've got a route for > it... that's just the way the routing code works. > You can ping the local address for an Ethernet interface, but that's > just because the hardware returns such packets. > Adding a loopback route or address alias is the way to handle this. Correct, but in this case, pinging the other end of the link also failed: gif0: flags=8011 mtu 1280 inet 10.0.2.130 --> 10.0.2.2 netmask 0xffffffff physical address inet 209.167.75.123 --> 209.167.75.124 waterloo.heers.on.ca# ping 10.0.2.2 PING 10.0.2.2 (10.0.2.2): 56 data bytes ^C --- 10.0.2.2 ping statistics --- 15 packets transmitted, 0 packets received, 100% packet loss I don't get the reason for this part. This is perhaps due to some IPsec issues? netstat gave us an interesting result: 34 inbound packets violated process security policy JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 7:22:31 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 4DA5737B403 for ; Mon, 10 Sep 2001 07:22:24 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id f8AEMJi71132; Mon, 10 Sep 2001 15:22:19 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id f8AEM8J60160; Mon, 10 Sep 2001 15:22:08 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200109101422.f8AEM8J60160@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Brian Somers , freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Forward: Re: ping gif0 In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Mon, 10 Sep 2001 21:51:49 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Sep 2001 15:22:08 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >>>>> On Mon, 10 Sep 2001 11:54:49 +0100, > >>>>> Brian Somers said: > > > The local endpoint can't be pinged unless you've got a route for > > it... that's just the way the routing code works. > > > You can ping the local address for an Ethernet interface, but that's > > just because the hardware returns such packets. > > > Adding a loopback route or address alias is the way to handle this. > > Correct, but in this case, pinging the other end of the link also > failed: > > gif0: flags=8011 mtu 1280 > inet 10.0.2.130 --> 10.0.2.2 netmask 0xffffffff > physical address inet 209.167.75.123 --> 209.167.75.124 > > waterloo.heers.on.ca# ping 10.0.2.2 > PING 10.0.2.2 (10.0.2.2): 56 data bytes > ^C > --- 10.0.2.2 ping statistics --- > 15 packets transmitted, 0 packets received, 100% packet loss > > I don't get the reason for this part. This is perhaps due to some > IPsec issues? netstat gave us an interesting result: > > 34 inbound packets violated process security policy This rings bells. I have been having difficulties with an IPSEC over gif setup recently, but they went away with the latest racoon update in the ports collection. They *may* have appeared with the previous racoon update - I'm not sure. The symptoms were bizarre. I had two LANs with an IP4 gif tunnel between them and an IPSEC transport policy encrypting ip4 data between the two public IP addresses. From anywhere on LAN1 I could send & receive data to the LAN2 private gateway IP number, but could not send data to any internal machines on LAN2. Trying to talk to internal machines on LAN2 resulted in authentication errors for the data coming into LAN1s gateway. Upgrading racoon on LAN2's gateway made the problem go away.... > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 8: 3:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by hub.freebsd.org (Postfix) with ESMTP id 80DC437B40B for ; Mon, 10 Sep 2001 08:03:10 -0700 (PDT) Received: from xena.gsicomp.on.ca ([65.93.38.74]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010910150225.UVSJ24586.tomts7-srv.bellnexxia.net@xena.gsicomp.on.ca>; Mon, 10 Sep 2001 11:02:25 -0400 Received: from localhost (matt@localhost) by xena.gsicomp.on.ca (8.11.1/8.11.1) with ESMTP id f8AEtZk34811; Mon, 10 Sep 2001 10:55:36 -0400 (EDT) (envelope-from matt@xena.gsicomp.on.ca) Date: Mon, 10 Sep 2001 10:54:20 -0400 (EDT) From: Matthew Emmerton To: Brian Somers Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , freebsd-net@FreeBSD.ORG Subject: Re: Forward: Re: ping gif0 In-Reply-To: <200109101422.f8AEM8J60160@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 10 Sep 2001, Brian Somers wrote: > > >>>>> On Mon, 10 Sep 2001 11:54:49 +0100, > > >>>>> Brian Somers said: > > > > > The local endpoint can't be pinged unless you've got a route for > > > it... that's just the way the routing code works. > > > > > You can ping the local address for an Ethernet interface, but that's > > > just because the hardware returns such packets. > > > > > Adding a loopback route or address alias is the way to handle this. > > > > Correct, but in this case, pinging the other end of the link also > > failed: > > > > gif0: flags=8011 mtu 1280 > > inet 10.0.2.130 --> 10.0.2.2 netmask 0xffffffff > > physical address inet 209.167.75.123 --> 209.167.75.124 > > > > waterloo.heers.on.ca# ping 10.0.2.2 > > PING 10.0.2.2 (10.0.2.2): 56 data bytes > > ^C > > --- 10.0.2.2 ping statistics --- > > 15 packets transmitted, 0 packets received, 100% packet loss > > > > I don't get the reason for this part. This is perhaps due to some > > IPsec issues? netstat gave us an interesting result: > > > > 34 inbound packets violated process security policy > > This rings bells. I have been having difficulties with an IPSEC over > gif setup recently, but they went away with the latest racoon update > in the ports collection. They *may* have appeared with the previous > racoon update - I'm not sure. The symptoms were bizarre. However, I'm not using racoon. Static keys, using '-E simple ""' as the encryption algorithm. (This helps me figure out whats going on with tcpdump and ethereal much more easily.) LAN1 machines can talk to LAN2 machines and vice versa with absolutely no problems. However, the LAN1 gateway can't talk to the LAN2 gateway and vice versa. As was pointed out, I need to set up some localhost routes in order to ping the local end of the tunnel. What remains is a) why can't I ping the remote end of the tunnel without receiving these "violated process security policy" messages, and b) why can't I connect to the remote end of the tunnel. The latter breaks DNS forwarding / HTTP proxy / sendmail forwarding, and is becoming a real problem. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 8:42: 5 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id 385C737B40A for ; Mon, 10 Sep 2001 08:41:49 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id f8AFfhi71375; Mon, 10 Sep 2001 16:41:43 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id f8AFfVJ61047; Mon, 10 Sep 2001 16:41:31 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200109101541.f8AFfVJ61047@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Emmerton Cc: Brian Somers , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Forward: Re: ping gif0 In-Reply-To: Message from Matthew Emmerton of "Mon, 10 Sep 2001 10:54:20 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Sep 2001 16:41:31 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > On Mon, 10 Sep 2001, Brian Somers wrote: > > > > >>>>> On Mon, 10 Sep 2001 11:54:49 +0100, > > > >>>>> Brian Somers said: > > > > > > > The local endpoint can't be pinged unless you've got a route for > > > > it... that's just the way the routing code works. > > > > > > > You can ping the local address for an Ethernet interface, but that's > > > > just because the hardware returns such packets. > > > > > > > Adding a loopback route or address alias is the way to handle this. > > > > > > Correct, but in this case, pinging the other end of the link also > > > failed: > > > > > > gif0: flags=8011 mtu 1280 > > > inet 10.0.2.130 --> 10.0.2.2 netmask 0xffffffff > > > physical address inet 209.167.75.123 --> 209.167.75.124 > > > > > > waterloo.heers.on.ca# ping 10.0.2.2 > > > PING 10.0.2.2 (10.0.2.2): 56 data bytes > > > ^C > > > --- 10.0.2.2 ping statistics --- > > > 15 packets transmitted, 0 packets received, 100% packet loss > > > > > > I don't get the reason for this part. This is perhaps due to some > > > IPsec issues? netstat gave us an interesting result: > > > > > > 34 inbound packets violated process security policy > > > > This rings bells. I have been having difficulties with an IPSEC over > > gif setup recently, but they went away with the latest racoon update > > in the ports collection. They *may* have appeared with the previous > > racoon update - I'm not sure. The symptoms were bizarre. > > However, I'm not using racoon. Static keys, using '-E simple ""' as the > encryption algorithm. (This helps me figure out whats going on with > tcpdump and ethereal much more easily.) > > LAN1 machines can talk to LAN2 machines and vice versa with absolutely no > problems. However, the LAN1 gateway can't talk to the LAN2 gateway and > vice versa. As was pointed out, I need to set up some localhost routes in > order to ping the local end of the tunnel. > > What remains is a) why can't I ping the remote end of the tunnel without > receiving these "violated process security policy" messages, and b) why > can't I connect to the remote end of the tunnel. The latter breaks > DNS forwarding / HTTP proxy / sendmail forwarding, and is becoming a real > problem. What does your security policy say ? I have this on the LAN1 gateway: spdadd LAN2PUB/32 LAN1PUB/32 ip4 -P in ipsec esp/transport//require; spdadd LAN1PUB/32 LAN2PUB/32 ip4 -P out ipsec esp/transport//require; and of course the in/out bits reversed on the LAN2 gateway. The important bit is the ``ip4'' bit. I don't expect connections to/from the public IP numbers to be caught by the policy - and in fact run NAT on both gateways. > -- > Matt Emmerton -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 8:56:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from opensrs.saignon.net (216-120-17-31.dsl.cust.tfb.com [216.120.17.31]) by hub.freebsd.org (Postfix) with ESMTP id AA9C937B406 for ; Mon, 10 Sep 2001 08:56:47 -0700 (PDT) Received: from tsaignmobl (u2938@prx2.ipivot.com [216.188.41.2]) by opensrs.saignon.net (8.11.4/8.11.3) with SMTP id f8AFvGb39153 for ; Mon, 10 Sep 2001 08:57:21 -0700 (PDT) (envelope-from tony@saign.com) From: Tony Saign Reply-To: To: Subject: DHCPD question... Date: Mon, 10 Sep 2001 08:55:59 -0700 Message-ID: <000101c13a11$16e49a20$da0b010a@tsaignmobl> 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 V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a FreeBSD (4.3) system running dhcpd, ipfw, and natd. 2 NICS one external net (internet), and 1 internal net. Everything is working normally, I can connect with all internal systems to web/ftp/email/ssh, etc. services. I am getting console error messages stating; Sep 10 07:24:06 p3 dhcpd: send_packet: Permission denied Sep 10 07:24:08 p3 last message repeated 5 times Sep 10 07:33:01 p3 natd[222]: failed to write packet back (Permission denied) Sep 10 07:33:01 p3 natd[222]: failed to write packet back (Permission denied) How can I track this down to find out what is actually getting denied?? Also, my leases are being assigned starting with 192.168.1.254 then 253 then 252 etc. Normally these go x.x.x.1 x.x.x.2 etc. anyone seen this before? Thanks in advance, -Tony To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 10: 1: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by hub.freebsd.org (Postfix) with ESMTP id D057F37B403 for ; Mon, 10 Sep 2001 10:00:59 -0700 (PDT) Received: from xena.gsicomp.on.ca ([65.93.38.74]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010910170058.XGMR24586.tomts7-srv.bellnexxia.net@xena.gsicomp.on.ca>; Mon, 10 Sep 2001 13:00:58 -0400 Received: from localhost (matt@localhost) by xena.gsicomp.on.ca (8.11.1/8.11.1) with ESMTP id f8AGs4R35076; Mon, 10 Sep 2001 12:54:12 -0400 (EDT) (envelope-from matt@xena.gsicomp.on.ca) Date: Mon, 10 Sep 2001 12:52:48 -0400 (EDT) From: Matthew Emmerton To: Brian Somers Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , freebsd-net@FreeBSD.ORG Subject: Re: Forward: Re: ping gif0 In-Reply-To: <200109101541.f8AFfVJ61047@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 10 Sep 2001, Brian Somers wrote: > > On Mon, 10 Sep 2001, Brian Somers wrote: > > > > > > >>>>> On Mon, 10 Sep 2001 11:54:49 +0100, > > > > >>>>> Brian Somers said: > > > > > > > > > The local endpoint can't be pinged unless you've got a route for > > > > > it... that's just the way the routing code works. > > > > > > > > > You can ping the local address for an Ethernet interface, but that's > > > > > just because the hardware returns such packets. > > > > > > > > > Adding a loopback route or address alias is the way to handle this. > > > > > > > > Correct, but in this case, pinging the other end of the link also > > > > failed: > > > > > > > > gif0: flags=8011 mtu 1280 > > > > inet 10.0.2.130 --> 10.0.2.2 netmask 0xffffffff > > > > physical address inet 209.167.75.123 --> 209.167.75.124 > > > > > > > > waterloo.heers.on.ca# ping 10.0.2.2 > > > > PING 10.0.2.2 (10.0.2.2): 56 data bytes > > > > ^C > > > > --- 10.0.2.2 ping statistics --- > > > > 15 packets transmitted, 0 packets received, 100% packet loss > > > > > > > > I don't get the reason for this part. This is perhaps due to some > > > > IPsec issues? netstat gave us an interesting result: > > > > > > > > 34 inbound packets violated process security policy > > > > > > This rings bells. I have been having difficulties with an IPSEC over > > > gif setup recently, but they went away with the latest racoon update > > > in the ports collection. They *may* have appeared with the previous > > > racoon update - I'm not sure. The symptoms were bizarre. > > > > However, I'm not using racoon. Static keys, using '-E simple ""' as the > > encryption algorithm. (This helps me figure out whats going on with > > tcpdump and ethereal much more easily.) > > > > LAN1 machines can talk to LAN2 machines and vice versa with absolutely no > > problems. However, the LAN1 gateway can't talk to the LAN2 gateway and > > vice versa. As was pointed out, I need to set up some localhost routes in > > order to ping the local end of the tunnel. > > > > What remains is a) why can't I ping the remote end of the tunnel without > > receiving these "violated process security policy" messages, and b) why > > can't I connect to the remote end of the tunnel. The latter breaks > > DNS forwarding / HTTP proxy / sendmail forwarding, and is becoming a real > > problem. > > What does your security policy say ? I have this on the LAN1 gateway: > > spdadd LAN2PUB/32 LAN1PUB/32 ip4 -P in ipsec esp/transport//require; > spdadd LAN1PUB/32 LAN2PUB/32 ip4 -P out ipsec esp/transport//require; > > and of course the in/out bits reversed on the LAN2 gateway. The > important bit is the ``ip4'' bit. I don't expect connections to/from > the public IP numbers to be caught by the policy - and in fact run > NAT on both gateways. I have this: spdadd 10.0.2.0/26 10.0.2.128/28 any -P in ipsec esp/tunnel/209.167.75.124-209.167.75.123/require; spdadd 10.0.2.128/28 10.0.2.0/26 any -P out ipsec esp/tunnel/209.167.75.123-209.167.75.124/require; Although now I'm slightly confused since I had switched from 'tunnel' to 'transport' after someone pointed out that since gif is a tunnel, I don't have to rely on IPSec's 'tunnel' mode do do the encapsulation. Am I getting bit by one-too-many layers of IPv4? -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 10:32:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id F3E7E37B401 for ; Mon, 10 Sep 2001 10:32:16 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.6/8.11.6) with ESMTP id f8AHWAi72026; Mon, 10 Sep 2001 18:32:13 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id f8AHVwJ69856; Mon, 10 Sep 2001 18:31:58 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200109101731.f8AHVwJ69856@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Emmerton Cc: Brian Somers , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , freebsd-net@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Forward: Re: ping gif0 In-Reply-To: Message from Matthew Emmerton of "Mon, 10 Sep 2001 12:52:48 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Sep 2001 18:31:58 +0100 From: Brian Somers Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > On Mon, 10 Sep 2001, Brian Somers wrote: > > > > On Mon, 10 Sep 2001, Brian Somers wrote: > > > > > > > > >>>>> On Mon, 10 Sep 2001 11:54:49 +0100, > > > > > >>>>> Brian Somers said: > > > > > > > > > > > The local endpoint can't be pinged unless you've got a route for > > > > > > it... that's just the way the routing code works. > > > > > > > > > > > You can ping the local address for an Ethernet interface, but that's > > > > > > just because the hardware returns such packets. > > > > > > > > > > > Adding a loopback route or address alias is the way to handle this. > > > > > > > > > > Correct, but in this case, pinging the other end of the link also > > > > > failed: > > > > > > > > > > gif0: flags=8011 mtu 1280 > > > > > inet 10.0.2.130 --> 10.0.2.2 netmask 0xffffffff > > > > > physical address inet 209.167.75.123 --> 209.167.75.124 > > > > > > > > > > waterloo.heers.on.ca# ping 10.0.2.2 > > > > > PING 10.0.2.2 (10.0.2.2): 56 data bytes > > > > > ^C > > > > > --- 10.0.2.2 ping statistics --- > > > > > 15 packets transmitted, 0 packets received, 100% packet loss > > > > > > > > > > I don't get the reason for this part. This is perhaps due to some > > > > > IPsec issues? netstat gave us an interesting result: > > > > > > > > > > 34 inbound packets violated process security policy > > > > > > > > This rings bells. I have been having difficulties with an IPSEC over > > > > gif setup recently, but they went away with the latest racoon update > > > > in the ports collection. They *may* have appeared with the previous > > > > racoon update - I'm not sure. The symptoms were bizarre. > > > > > > However, I'm not using racoon. Static keys, using '-E simple ""' as the > > > encryption algorithm. (This helps me figure out whats going on with > > > tcpdump and ethereal much more easily.) > > > > > > LAN1 machines can talk to LAN2 machines and vice versa with absolutely no > > > problems. However, the LAN1 gateway can't talk to the LAN2 gateway and > > > vice versa. As was pointed out, I need to set up some localhost routes in > > > order to ping the local end of the tunnel. > > > > > > What remains is a) why can't I ping the remote end of the tunnel without > > > receiving these "violated process security policy" messages, and b) why > > > can't I connect to the remote end of the tunnel. The latter breaks > > > DNS forwarding / HTTP proxy / sendmail forwarding, and is becoming a real > > > problem. > > > > What does your security policy say ? I have this on the LAN1 gateway: > > > > spdadd LAN2PUB/32 LAN1PUB/32 ip4 -P in ipsec esp/transport//require; > > spdadd LAN1PUB/32 LAN2PUB/32 ip4 -P out ipsec esp/transport//require; > > > > and of course the in/out bits reversed on the LAN2 gateway. The > > important bit is the ``ip4'' bit. I don't expect connections to/from > > the public IP numbers to be caught by the policy - and in fact run > > NAT on both gateways. > > I have this: > > spdadd 10.0.2.0/26 10.0.2.128/28 any -P in ipsec > esp/tunnel/209.167.75.124-209.167.75.123/require; > spdadd 10.0.2.128/28 10.0.2.0/26 any -P out ipsec > esp/tunnel/209.167.75.123-209.167.75.124/require; > > Although now I'm slightly confused since I had switched from 'tunnel' to > 'transport' after someone pointed out that since gif is a tunnel, I don't > have to rely on IPSec's 'tunnel' mode do do the encapsulation. > > Am I getting bit by one-too-many layers of IPv4? I think so. Try changing it to spdadd 209.167.75.124/32 209.167.75.123/32 ip4 -P in ipsec esp/transport//require; spdadd 209.167.75.123/32 209.167.75.124/32 ip4 -P out ipsec esp/transport//require; > -- > Matt Emmerton -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 11:48:29 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 D9CFC37B405 for ; Mon, 10 Sep 2001 11:48:23 -0700 (PDT) Received: from isi.edu (hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id f8AIlvQ27738; Mon, 10 Sep 2001 11:47:57 -0700 (PDT) Message-ID: <3B9D0ADD.2050009@isi.edu> Date: Mon, 10 Sep 2001 11:47:57 -0700 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.2-RELEASE i386; en-US; rv:0.9) Gecko/20010529 X-Accept-Language: en, de MIME-Version: 1.0 To: Matthew Emmerton Cc: Brian Somers , JINMEI Tatuya / =?ISO-8859-1?Q?=3F=3F=3F=3F?= , freebsd-net@FreeBSD.ORG Subject: Re: Forward: Re: ping gif0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Matthew Emmerton wrote: > I have this: > > spdadd 10.0.2.0/26 10.0.2.128/28 any -P in ipsec > esp/tunnel/209.167.75.124-209.167.75.123/require; > spdadd 10.0.2.128/28 10.0.2.0/26 any -P out ipsec > esp/tunnel/209.167.75.123-209.167.75.124/require; > > Although now I'm slightly confused since I had switched from 'tunnel' to > 'transport' after someone pointed out that since gif is a tunnel, I don't > have to rely on IPSec's 'tunnel' mode do do the encapsulation. You're using transport mode SAs (over an IP tunnel, but still not "IPsec tunnel mode"), so this should be "transport" not "tunnel". 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 Mon Sep 10 13:24:33 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 2E95937B406 for ; Mon, 10 Sep 2001 13:24:29 -0700 (PDT) Received: from simoeon.sentex.net (pyroxene.sentex.ca [199.212.134.18]) by smtp1.sentex.ca (8.11.6/8.11.6) with ESMTP id f8AKOS367520 for ; Mon, 10 Sep 2001 16:24:28 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20010910161626.0437bec0@marble.sentex.ca> X-Sender: mdtpop@marble.sentex.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 Sep 2001 16:18:40 -0400 To: freebsd-net@freebsd.org From: Mike Tancsa Subject: arp -s not working with VLANS ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is there a way to make a permanent mac entry for a VLAN interface ? e.g. if I try dsl-bdr2# arp -s 192.168.1.1 00:02:88:05:93:56 cannot intuit interface index and type for 192.168.1.1 dsl-bdr2# Or is this a limitation of arp with VLANs ? ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 14:52:54 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id 4A28637B40A for ; Mon, 10 Sep 2001 14:52:49 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 6FAB51E01F; Mon, 10 Sep 2001 17:52:48 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA09036; Mon, 10 Sep 2001 17:52:47 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA25873; Mon, 10 Sep 2001 14:52:47 -0700 (PDT) Message-Id: <200109102152.OAA25873@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mike@sentex.net Subject: Re: arp -s not working with VLANS ? Cc: freebsd-net@freebsd.org Date: Mon, 10 Sep 2001 14:52:47 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This should work in -stable and -current (arp.c version 1.22.2.2 or 1.29). You could apply this diff: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/arp/arp.c.diff?r1=1.22.2.1&r2=1.22.2.2 Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Sep 10 20:41:12 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 4FFBE37B406 for ; Mon, 10 Sep 2001 20:41:08 -0700 (PDT) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.6/8.11.6) with SMTP id f8B3f3x40747; Mon, 10 Sep 2001 23:41:03 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: fenner@research.att.com (Bill Fenner) Cc: freebsd-net@freebsd.org Subject: Re: arp -s not working with VLANS ? Date: Mon, 10 Sep 2001 23:41:02 -0400 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 10 Sep 2001 17:53:04 -0400, in sentex.lists.freebsd.net you wrote: > >This should work in -stable and -current (arp.c version 1.22.2.2 or >1.29). You could apply this diff: > >http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/arp/arp.c.diff?r1=3D1= .22.2.1&r2=3D1.22.2.2 I must have not put down my crack pipe, as its working now :-( Chalk it = up to pilot error as it workes on all 3 of my 802.1q enabled boxes. ---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 Tue Sep 11 22: 0: 9 2001 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id DE8BC37B403 for ; Tue, 11 Sep 2001 22:00:06 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA66125; Tue, 11 Sep 2001 21:46:22 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.3/8.11.3) id f8C4kMs36077; Tue, 11 Sep 2001 21:46:22 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200109120446.f8C4kMs36077@arch20m.dellroad.org> Subject: Re: DHCPD question... In-Reply-To: <000101c13a11$16e49a20$da0b010a@tsaignmobl> "from Tony Saign at Sep 10, 2001 08:55:59 am" To: tony@saign.com Date: Tue, 11 Sep 2001 21:46:22 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Tony Saign writes: > I have a FreeBSD (4.3) system running dhcpd, ipfw, and natd. 2 NICS one > external net (internet), and 1 internal net. > Everything is working normally, I can connect with all internal systems to > web/ftp/email/ssh, etc. services. > > I am getting console error messages stating; > > Sep 10 07:24:06 p3 dhcpd: send_packet: Permission denied > Sep 10 07:24:08 p3 last message repeated 5 times > Sep 10 07:33:01 p3 natd[222]: failed to write packet back (Permission denied) > Sep 10 07:33:01 p3 natd[222]: failed to write packet back (Permission denied) That error is typically due to a packet hitting a firewall rule. Check your ipfw ruleset. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 12 8:20: 6 2001 Delivered-To: freebsd-net@freebsd.org Received: from mail.tcoip.com.br (cerberus.tcoip.com.br [200.220.254.3]) by hub.freebsd.org (Postfix) with ESMTP id 3B9DE37B40A for ; Wed, 12 Sep 2001 08:20:02 -0700 (PDT) Received: from tcoip.com.br (2j2b5x0zx2mlo526@[192.168.60.194]) by mail.tcoip.com.br (8.11.1/8.11.1) with ESMTP id f8CFGwP04685 for ; Wed, 12 Sep 2001 12:16:58 -0300 Message-ID: <3B9F7C68.3040904@tcoip.com.br> Date: Wed, 12 Sep 2001 12:16:56 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20010808 X-Accept-Language: en, pt-br, ja MIME-Version: 1.0 To: net@freebsd.org Subject: Final Request for Review Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Now that 4.4 is almost out, I'd like people to test http://people.freebsd.org/~dcs/ip_output.c.diff for merge to stable something like a week after 4.4 is out. The patch makes the IP stack capable of sending multicast packets out application-selected interfaces in the absence of a default route (or a multicast route). If the interface has no IP assigned, the packet goes out with address 0.0.0.0. All this is in conformance with the multicast RFC, and would bring our behavior in sync with other unices out there (though other BSDs still don't allow this, it seems). It has been working on current for a few weeks now (releases 1.128 through 1.131, iirc -- there may have been an additional release before we got it right). -- Daniel C. Sobral (8-DCS) Daniel.Sobral@tcoip.com.br dcs@newsguy.com dcs@freebsd.org capo@notorious.bsdconspiracy.net A holding company is a thing where you hand an accomplice the goods while the policeman searches you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 12 8:23:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51]) by hub.freebsd.org (Postfix) with ESMTP id CED1237B401 for ; Wed, 12 Sep 2001 08:23:21 -0700 (PDT) Received: by tao.org.uk (Postfix, from userid 100) id 0F2FC130; Wed, 12 Sep 2001 16:23:19 +0100 (BST) Date: Wed, 12 Sep 2001 16:23:18 +0100 From: Josef Karthauser To: "Daniel C. Sobral" Cc: net@freebsd.org Subject: Re: Final Request for Review Message-ID: <20010912162318.G66526@tao.org.uk> References: <3B9F7C68.3040904@tcoip.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Zrag5V6pnZGjLKiw" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B9F7C68.3040904@tcoip.com.br>; from daniel.sobral@tcoip.com.br on Wed, Sep 12, 2001 at 12:16:56PM -0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --Zrag5V6pnZGjLKiw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 12, 2001 at 12:16:56PM -0300, Daniel C. Sobral wrote: > Now that 4.4 is almost out, I'd like people to test=20 > http://people.freebsd.org/~dcs/ip_output.c.diff for merge to stable=20 > something like a week after 4.4 is out. >=20 > The patch makes the IP stack capable of sending multicast packets out=20 > application-selected interfaces in the absence of a default route (or a= =20 > multicast route). If the interface has no IP assigned, the packet goes=20 > out with address 0.0.0.0. All this is in conformance with the multicast= =20 > RFC, and would bring our behavior in sync with other unices out there=20 > (though other BSDs still don't allow this, it seems). >=20 > It has been working on current for a few weeks now (releases 1.128=20 > through 1.131, iirc -- there may have been an additional release before= =20 > we got it right). Excellent work Daniel. This should fix zebra's OSPF handling. :) Joe --Zrag5V6pnZGjLKiw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjuffeYACgkQXVIcjOaxUBavNACfaNmEeeCPNRL/bJbvnP0woTby dVkAnj8zNSe4AjYqG4EDZ+pso86bt8DT =oFTz -----END PGP SIGNATURE----- --Zrag5V6pnZGjLKiw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 12 12:45:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from db.nexgen.com (db.nexgen.com [66.92.98.149]) by hub.freebsd.org (Postfix) with SMTP id CEA7C37B409 for ; Wed, 12 Sep 2001 12:45:02 -0700 (PDT) Received: (qmail 43597 invoked from network); 12 Sep 2001 19:44:34 -0000 Received: from localhost.nexgen.com (HELO alexus) (root@127.0.0.1) by localhost.nexgen.com with SMTP; 12 Sep 2001 19:44:34 -0000 Message-ID: <000701c13bc3$66c6f160$0d00a8c0@alexus> From: "alexus" To: Subject: port forwarding through natd and/or ipfw Date: Wed, 12 Sep 2001 15:44:56 -0400 Organization: NexGen MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi My goal is to access my Windows XP workstation that is behind N.A.T. FreeBSD box's firewall I've tried two ways and didn't succeed on any of them:( i was hoping some of you will help me to figure out what went wrong my public ip address is 66.92.98.145 and internal ip is 192.168.0.13 port that my XP workstation listens on is 3389r here is form XP (part from netstat) TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING so it *is* listening.. first i've tryed through natd su-2.05# grep 3389 /etc/natd.conf redirect_port tcp 192.168.0.13:3389 3389 su-2.05# ps auxww|grep natd root 69679 0.0 0.1 1096 640 p1 S+ 3:37PM 0:00.00 grep natd root 165 0.0 0.1 592 384 ?? Ss 9:24PM 1:30.78 /sbin/natd -u -f /etc/natd.conf -n fxp0 su-2.05# that didn't worked:( then i've tryed through firewall (ipfw) 00333 6 288 fwd 66.92.98.145,3389 tcp from any to 192.168.0.13 3389 this was a little bit more suscess then others due to at least this rule was matched .. but i didn't get to my XP workstation:( i *did* enabled firewall in kernel su-2.05# grep FIREWALL box options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about options IPFIREWALL_VERBOSE_LIMIT=10 #limit verbosity options IPFIREWALL_FORWARD #enable transparent proxy support su-2.05# any help/comments/recommendation would be a very much appreciated thanks in advance To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Sep 12 14:28: 2 2001 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 5870D37B40B; Wed, 12 Sep 2001 14:27:55 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1098) id 0E57781D05; Wed, 12 Sep 2001 16:27:50 -0500 (CDT) Date: Wed, 12 Sep 2001 16:27:50 -0500 From: Bill Fumerola To: alexus Cc: freebsd-ipfw@freebsd.org Subject: Re: port forwarding through natd and/or ipfw Message-ID: <20010912162749.D826@elvis.mu.org> References: <000701c13bc3$66c6f160$0d00a8c0@alexus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000701c13bc3$66c6f160$0d00a8c0@alexus>; from ml@db.nexgen.com on Wed, Sep 12, 2001 at 03:44:56PM -0400 X-Operating-System: FreeBSD 4.4-FEARSOME-20010909 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Sep 12, 2001 at 03:44:56PM -0400, alexus wrote: > 00333 6 288 fwd 66.92.98.145,3389 tcp from any to 192.168.0.13 > 3389 > > this was a little bit more suscess then others due to at least this rule was > matched .. but i didn't get to my XP workstation:( fwd just changes the nexthop (changes the routing decision). it doesn't rewrite ports or addresses. you need natd & -redirect_port for that. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 13 7:51: 8 2001 Delivered-To: freebsd-net@freebsd.org Received: from spitfire.velocet.net (spitfire.velocet.net [216.138.223.227]) by hub.freebsd.org (Postfix) with ESMTP id 0561137B41E for ; Thu, 13 Sep 2001 07:51:05 -0700 (PDT) Received: from nomad.tor.lets.net (H74.C220.tor.velocet.net [216.138.220.74]) by spitfire.velocet.net (Postfix) with SMTP id D209644A9D1 for ; Thu, 13 Sep 2001 10:51:03 -0400 (EDT) Received: (qmail 55015 invoked by uid 1001); 13 Sep 2001 14:45:47 -0000 Date: Thu, 13 Sep 2001 10:45:47 -0400 From: Steve Shorter To: freebsd-net@freebsd.org Subject: rfc1323: rc.conf and tuning(7) contradiction? Message-ID: <20010913104547.A55010@nomad.lets.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Howdy! I recently installed 4.4RC. In this release rfc1323 extensions are turned on by default which is a change from 4.3. However, tuning(7) says that rfc1323 extensions should be off unless "you absolutely have to" turn them on. I was wondering if the change in default behaviour is indicative of changes in the network code that make rfc1323 extensions less risky and that it is recommended to enable these extensions as is suggested by the change in default behaviour. thanx -steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 13 7:58:18 2001 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id 7BAA937B40B for ; Thu, 13 Sep 2001 07:58:16 -0700 (PDT) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id f8DEwFY12462 for freebsd-net@freebsd.org; Thu, 13 Sep 2001 09:58:15 -0500 (CDT) (envelope-from tinguely) Date: Thu, 13 Sep 2001 09:58:15 -0500 (CDT) From: mark tinguely Message-Id: <200109131458.f8DEwFY12462@web.cs.ndsu.nodak.edu> To: freebsd-net@freebsd.org Subject: tcp_usr_connect Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org in tcp_usr_connect() and tcp6_usr_connect() in sys/netinet/tcp_usrreq.c in both FreeBSD 4.3 and -current is there a missing tp = intotcpcb(inp); call? It seems from my eyes that "tp" is not initialized. --mark tinguely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 13 8:29:55 2001 Delivered-To: freebsd-net@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 5E7FE37B405 for ; Thu, 13 Sep 2001 08:29:54 -0700 (PDT) Received: by bazooka.unixfreak.org (Postfix, from userid 1000) id EA5793E2F; Thu, 13 Sep 2001 08:29:53 -0700 (PDT) Received: from bazooka.unixfreak.org (localhost [127.0.0.1]) by bazooka.unixfreak.org (Postfix) with ESMTP id DF8293C12E; Thu, 13 Sep 2001 08:29:53 -0700 (PDT) To: mark tinguely Cc: freebsd-net@freebsd.org Subject: Re: tcp_usr_connect In-Reply-To: <200109131458.f8DEwFY12462@web.cs.ndsu.nodak.edu>; from tinguely@web.cs.ndsu.nodak.edu on "Thu, 13 Sep 2001 09:58:15 -0500 (CDT)" Date: Thu, 13 Sep 2001 08:29:48 -0700 From: Dima Dorfman Message-Id: <20010913152953.EA5793E2F@bazooka.unixfreak.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org mark tinguely wrote: > > in tcp_usr_connect() and tcp6_usr_connect() in sys/netinet/tcp_usrreq.c > in both FreeBSD 4.3 and -current is there a missing > tp = intotcpcb(inp); > call? It seems from my eyes that "tp" is not initialized. It's initialized in COMMON_START(). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 13 9: 8: 1 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 5EF9137B40A for ; Thu, 13 Sep 2001 09:07:59 -0700 (PDT) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f8DG7Mp38138; Thu, 13 Sep 2001 11:07:22 -0500 (CDT) (envelope-from jlemon) Date: Thu, 13 Sep 2001 11:07:22 -0500 (CDT) From: Jonathan Lemon Message-Id: <200109131607.f8DG7Mp38138@prism.flugsvamp.com> To: steve@nomad.tor.lets.net, net@freebsd.org Subject: Re: rfc1323: rc.conf and tuning(7) contradiction? X-Newsgroups: local.mail.freebsd-net In-Reply-To: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article you write: >Howdy! > > I recently installed 4.4RC. > > In this release rfc1323 extensions are turned on by default >which is a change from 4.3. However, tuning(7) says that rfc1323 >extensions should be off unless "you absolutely have to" >turn them on. The tuning(7) man page should be updated to remove this comment. The "many hosts ... can't handle this feature" is dated and most likely no longer applies. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Sep 13 10: 0:34 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 3980A37B4EC for ; Thu, 13 Sep 2001 10:00:01 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8DGxeU02977; Thu, 13 Sep 2001 19:59:40 +0300 (EEST) (envelope-from ru) Date: Thu, 13 Sep 2001 19:59:40 +0300 From: Ruslan Ermilov To: Jonathan Lemon Cc: steve@nomad.tor.lets.net, net@FreeBSD.ORG Subject: Re: rfc1323: rc.conf and tuning(7) contradiction? Message-ID: <20010913195940.B2458@sunbay.com> References: <200109131607.f8DG7Mp38138@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: <200109131607.f8DG7Mp38138@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Thu, Sep 13, 2001 at 11:07:22AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Sep 13, 2001 at 11:07:22AM -0500, Jonathan Lemon wrote: > In article you write: > >Howdy! > > > > I recently installed 4.4RC. > > > > In this release rfc1323 extensions are turned on by default > >which is a change from 4.3. However, tuning(7) says that rfc1323 > >extensions should be off unless "you absolutely have to" > >turn them on. > > The tuning(7) man page should be updated to remove this comment. The > "many hosts ... can't handle this feature" is dated and most likely > no longer applies. > Please don't hesitate to do it! :-) -- 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 Thu Sep 13 20: 2:34 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 1A75837B401; Thu, 13 Sep 2001 20:02:22 -0700 (PDT) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f8E32La12637; Thu, 13 Sep 2001 20:02:21 -0700 Date: Thu, 13 Sep 2001 20:02:21 -0700 From: Brooks Davis To: net@freebsd.org, arch@freebsd.org Subject: review request: creating cloneable interfaces at boot Message-ID: <20010913200221.A11788@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd like to commit something like the following patch to create clonable interfaces at boot so they can be configured the normal way. Any one have comments or suggestions? -- Brooks Index: etc/rc.network =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/etc/rc.network,v retrieving revision 1.102 diff -u -r1.102 rc.network --- etc/rc.network 30 Jul 2001 23:12:02 -0000 1.102 +++ etc/rc.network 14 Sep 2001 02:54:15 -0000 @@ -127,6 +127,11 @@ ;; esac =20 + # Attempt to create cloned interfaces. + for ifn in ${cloned_interfaces}; do + ifconfig ${ifn} create + done + # Special options for sppp(4) interfaces go here. These need # to go _before_ the general ifconfig section, since in the case # of hardwired (no link1 flag) but required authentication, you @@ -151,6 +156,9 @@ [Aa][Uu][Tt][Oo]) network_interfaces=3D"`ifconfig -l`" ;; + *) + network_interfaces=3D"${network_interfaces} ${cloned_interfaces}" + ;; esac =20 dhcp_interfaces=3D"" @@ -796,7 +804,8 @@ continue ;; *) - ifconfig $i create tunnel ${peers} + ifconfig $i create >/dev/null 2>&1 + ifconfig $i tunnel ${peers} ;; esac done Index: etc/defaults/rc.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/etc/defaults/rc.conf,v retrieving revision 1.122 diff -u -r1.122 rc.conf --- etc/defaults/rc.conf 2 Sep 2001 23:34:19 -0000 1.122 +++ etc/defaults/rc.conf 12 Sep 2001 20:54:50 -0000 @@ -85,6 +85,8 @@ icmp_drop_redirect=3D"NO" # Set to YES to ignore ICMP REDIRECT packets icmp_log_redirect=3D"NO" # Set to YES to log ICMP REDIRECT packets network_interfaces=3D"auto" # List of network interfaces (or "auto"). +cloned_interfaces=3D"" # List of cloned network interfaces to create. +#cloned_interfaces=3D"gif0" # Restore pre-cloning GENERIC config. ifconfig_lo0=3D"inet 127.0.0.1" # default loopback device configuration. #ifconfig_lo0_alias0=3D"inet 127.0.0.254 netmask 0xffffffff" # Sample alia= s entry. #ifconfig_ed0_ipx=3D"ipx 0x00010010" # Sample IPX address family entry. Index: share/man/man5/rc.conf.5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvs/src/share/man/man5/rc.conf.5,v retrieving revision 1.133 diff -u -r1.133 rc.conf.5 --- share/man/man5/rc.conf.5 29 Aug 2001 05:39:06 -0000 1.133 +++ share/man/man5/rc.conf.5 14 Sep 2001 02:45:31 -0000 @@ -598,6 +598,14 @@ .Bd -literal ifconfig_ed0=3D"DHCP" .Ed +.It Va cloned_interfaces +.Pq Vt str +Set to the list of clonable network interfaces to create on this host. +Entries in +.Va cloned_interfaces +are automaticly appended to +.Va network_interfaces +for configuration. .It Va ppp_enable .Pq Vt bool If set to --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7oXM7XY6L6fI4GtQRAjUyAJ4oaqm5nzuq8eOHng6zbeis6CwhjgCdH2aY phfrNOAdiB/5ZqufZKqG1Bg= =fyDE -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 14 4:36:56 2001 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id D6AE437B410; Fri, 14 Sep 2001 04:36:40 -0700 (PDT) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f8EBZUS19283; Fri, 14 Sep 2001 14:35:30 +0300 (EEST) (envelope-from ru) Date: Fri, 14 Sep 2001 14:35:30 +0300 From: Ruslan Ermilov To: Brooks Davis Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: review request: creating cloneable interfaces at boot Message-ID: <20010914143530.E12915@sunbay.com> References: <20010913200221.A11788@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010913200221.A11788@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Thu, Sep 13, 2001 at 08:02:21PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Sep 13, 2001 at 08:02:21PM -0700, Brooks Davis wrote: > I'd like to commit something like the following patch to create clonable > interfaces at boot so they can be configured the normal way. Any one > have comments or suggestions? > Umm, how about extending the ${network_interfaces} functionality as follows. For each ${network_interfaces} argument, 1. if the value is `auto', add `ifconfig -l' to the list of interfaces 2. for every other argument which is not in the `ifconfig -l' list (ifconfig -l | grep -wq ${ifn} returns non-zero), but in the list of cloners (ifconfig -L) creates the corresponding interface. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 14 8:20:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id DEE4437B403; Fri, 14 Sep 2001 08:20:41 -0700 (PDT) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f8EFKfS08642; Fri, 14 Sep 2001 08:20:41 -0700 Date: Fri, 14 Sep 2001 08:20:41 -0700 From: Brooks Davis To: Ruslan Ermilov Cc: net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: review request: creating cloneable interfaces at boot Message-ID: <20010914082041.A7169@Odin.AC.HMC.Edu> References: <20010913200221.A11788@Odin.AC.HMC.Edu> <20010914143530.E12915@sunbay.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010914143530.E12915@sunbay.com>; from ru@FreeBSD.ORG on Fri, Sep 14, 2001 at 02:35:30PM +0300 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 14, 2001 at 02:35:30PM +0300, Ruslan Ermilov wrote: > Umm, how about extending the ${network_interfaces} functionality as follo= ws. > For each ${network_interfaces} argument, >=20 > 1. if the value is `auto', add `ifconfig -l' to the list of interfaces > 2. for every other argument which is not in the `ifconfig -l' list > (ifconfig -l | grep -wq ${ifn} returns non-zero), but in the > list of cloners (ifconfig -L) creates the corresponding interface. I don't really like that idea very much. If you implement 2) that way you lose ifconfig's auto module loading. You actually have to blindly try if you want that to work (and I do). Because of this, I like having a seperate variable that you only use for clonable interfaces. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7oiBIXY6L6fI4GtQRAux5AJkBfQxcIZP6WrZayPcSWrDCrVxa0wCdH1FC STBlZwq1mhV18Ayu0B/CWnc= =o+Jm -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 14 12:24:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id C300537B411 for ; Fri, 14 Sep 2001 12:23:57 -0700 (PDT) Received: (qmail 50194 invoked by uid 1000); 14 Sep 2001 19:24:19 -0000 Date: Fri, 14 Sep 2001 12:23:57 -0700 From: Jos Backus To: freebsd-net@freebsd.org Subject: How does getsockname() work? Message-ID: <20010914122357.A49323@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline User-Agent: Mutt/1.3.22.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I am seeing the following difference between FreeBSD and Solaris when using the attached program, which uses getsockname(). I am using the following command to test this program: snmpwalk -p 1234 public being either goldenbytes or taiko. On FreeBSD 4 I see: goldenbytes:~/udp% ./udp & [1] 64015 goldenbytes:~/udp% received on 0.0.0.0:0 received 37 bytes from 157.57.212.23:1446 received on 0.0.0.0:0 received 37 bytes from 157.57.212.23:1446 received on 0.0.0.0:0 received 37 bytes from 157.57.212.23:1446 received on 0.0.0.0:0 received 37 bytes from 157.57.212.23:1446 On Solaris 7 I see: taiko:~/udp% ./udp & [1] 21129 taiko:~/udp% received on 0.0.0.0:1234 received 37 bytes from 157.57.212.23:1448 received on 0.0.0.0:1234 received 37 bytes from 157.57.212.23:1448 received on 0.0.0.0:1234 received 37 bytes from 157.57.212.23:1448 received on 0.0.0.0:1234 received 37 bytes from 157.57.212.23:1448 The 0.0.0.0 is caused by using INADDR_ANY as the binding address; what I don't understand is why Solaris shows the portnumber whereas FreeBSD doesn't. Surely I am doing something wrong, but what? Thanks, -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="udp.c" #include #include #include #include #include #include #include #include #define PDU_SIZE 1500 struct sock { int fport; int fsockfd; long sockbuflen; }; static int init_sock(ctx) struct sock *ctx; { struct sockaddr_in local_address; bzero(&local_address, sizeof local_address); local_address.sin_family = AF_INET; local_address.sin_addr.s_addr = htonl(INADDR_ANY); local_address.sin_port = htons(ctx->fport); if ((ctx->fsockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { fprintf(stderr, "socket(): %s\n", strerror(errno)); exit(1); } if (bind(ctx->fsockfd, (struct sockaddr *)&local_address, sizeof local_address) < 0) { fprintf(stderr, "bind(): %s\n", strerror(errno)); exit(1); } } static int receive(ctx) struct sock *ctx; { unsigned char fpdu[PDU_SIZE]; struct sockaddr_in remote_address; struct sockaddr_in local_address; int i, len, n, local_len; while (1) { len = sizeof remote_address; if ((n = recvfrom(ctx->fsockfd, (char *)fpdu, sizeof(fpdu), 0, (struct sockaddr *)&remote_address, &len)) == -1) { fprintf(stderr, "recvfrom(): %s\n", strerror(errno)); exit(1); } if (getsockname(ctx->fsockfd, (struct sockaddr *)&local_address, &local_len) == -1) { fprintf(stderr, "getsockname(): %s\n", strerror(errno)); exit(1); } if (n > PDU_SIZE) { fprintf(stderr, "Warning: %d excess bytes discarded\n", n - PDU_SIZE); n = PDU_SIZE; } if (len != sizeof remote_address) { fprintf(stderr, "recvfrom() return address length %d - expected %d\n", len, sizeof remote_address); exit(1); } fprintf(stderr, "received on %s:%d\n", inet_ntoa(local_address.sin_addr), (int)ntohs(local_address.sin_port)); fprintf(stderr, "received %d bytes from %s:%d\n", n, inet_ntoa(remote_address.sin_addr), (int)ntohs(remote_address.sin_port)); } } int main(int ac, char *av[]) { struct sock s; s.fport = 1234; s.sockbuflen = 65536; init_sock(&s); receive(&s); } --PEIAKu/WMn1b1Hv9-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 14 13:56:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id B079D37B411 for ; Fri, 14 Sep 2001 13:56:12 -0700 (PDT) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id f8EKu0Z00200; Fri, 14 Sep 2001 16:56:00 -0400 (EDT) (envelope-from barney) Date: Fri, 14 Sep 2001 16:55:55 -0400 From: Barney Wolff To: Jos Backus Cc: freebsd-net@FreeBSD.ORG Subject: Re: How does getsockname() work? Message-ID: <20010914165555.A150@tp.databus.com> References: <20010914122357.A49323@lizzy.bugworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010914122357.A49323@lizzy.bugworks.com>; from josb@cncdsl.com on Fri, Sep 14, 2001 at 12:23:57PM -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You're using htons on an int. Try not doing that. Barney Wolff On Fri, Sep 14, 2001 at 12:23:57PM -0700, Jos Backus wrote: > I am seeing the following difference between FreeBSD and Solaris when using > the attached program, which uses getsockname(). > I am using the following command to test this program: > > snmpwalk -p 1234 public > > being either goldenbytes or taiko. > > On FreeBSD 4 I see: > > goldenbytes:~/udp% ./udp & > [1] 64015 > goldenbytes:~/udp% received on 0.0.0.0:0 > received 37 bytes from 157.57.212.23:1446 > received on 0.0.0.0:0 > received 37 bytes from 157.57.212.23:1446 > received on 0.0.0.0:0 > received 37 bytes from 157.57.212.23:1446 > received on 0.0.0.0:0 > received 37 bytes from 157.57.212.23:1446 > > On Solaris 7 I see: > > taiko:~/udp% ./udp & > [1] 21129 > taiko:~/udp% received on 0.0.0.0:1234 > received 37 bytes from 157.57.212.23:1448 > received on 0.0.0.0:1234 > received 37 bytes from 157.57.212.23:1448 > received on 0.0.0.0:1234 > received 37 bytes from 157.57.212.23:1448 > received on 0.0.0.0:1234 > received 37 bytes from 157.57.212.23:1448 > > The 0.0.0.0 is caused by using INADDR_ANY as the binding address; what I don't > understand is why Solaris shows the portnumber whereas FreeBSD doesn't. Surely > I am doing something wrong, but what? > > Thanks, > -- > Jos Backus _/ _/_/_/ Santa Clara, CA > _/ _/ _/ > _/ _/_/_/ > _/ _/ _/ _/ > josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; > #include > #include > #include > #include > #include > #include > #include > #include > > #define PDU_SIZE 1500 > > struct sock { > int fport; > int fsockfd; > long sockbuflen; > }; > > static int > init_sock(ctx) > struct sock *ctx; > { > struct sockaddr_in local_address; > > bzero(&local_address, sizeof local_address); > local_address.sin_family = AF_INET; > local_address.sin_addr.s_addr = htonl(INADDR_ANY); > local_address.sin_port = htons(ctx->fport); > > if ((ctx->fsockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { > fprintf(stderr, "socket(): %s\n", strerror(errno)); > exit(1); > } > if (bind(ctx->fsockfd, > (struct sockaddr *)&local_address, sizeof local_address) < 0) { > fprintf(stderr, "bind(): %s\n", strerror(errno)); > exit(1); > } > } > > static int > receive(ctx) > struct sock *ctx; > { > unsigned char fpdu[PDU_SIZE]; > struct sockaddr_in remote_address; > struct sockaddr_in local_address; > int i, len, n, local_len; > > while (1) { > len = sizeof remote_address; > if ((n = recvfrom(ctx->fsockfd, (char *)fpdu, > sizeof(fpdu), 0, > (struct sockaddr *)&remote_address, &len)) == -1) { > fprintf(stderr, "recvfrom(): %s\n", strerror(errno)); > exit(1); > } > if (getsockname(ctx->fsockfd, (struct sockaddr *)&local_address, > &local_len) == -1) { > fprintf(stderr, "getsockname(): %s\n", strerror(errno)); > exit(1); > } > if (n > PDU_SIZE) { > fprintf(stderr, "Warning: %d excess bytes discarded\n", > n - PDU_SIZE); > n = PDU_SIZE; > } > if (len != sizeof remote_address) { > fprintf(stderr, "recvfrom() return address length %d - expected %d\n", > len, sizeof remote_address); > exit(1); > } > fprintf(stderr, "received on %s:%d\n", > inet_ntoa(local_address.sin_addr), > (int)ntohs(local_address.sin_port)); > fprintf(stderr, "received %d bytes from %s:%d\n", > n, > inet_ntoa(remote_address.sin_addr), > (int)ntohs(remote_address.sin_port)); > } > } > > int > main(int ac, char *av[]) > { > struct sock s; > > s.fport = 1234; > s.sockbuflen = 65536; > > init_sock(&s); > > receive(&s); > } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 14 16:11:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 5820037B407 for ; Fri, 14 Sep 2001 16:11:46 -0700 (PDT) Received: (qmail 51561 invoked by uid 1000); 14 Sep 2001 23:12:08 -0000 Date: Fri, 14 Sep 2001 16:11:46 -0700 From: Jos Backus To: freebsd-net@FreeBSD.ORG Subject: Re: How does getsockname() work? Message-ID: <20010914161146.B49323@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <20010914122357.A49323@lizzy.bugworks.com> <20010914165555.A150@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010914165555.A150@tp.databus.com> User-Agent: Mutt/1.3.22.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Sep 14, 2001 at 04:55:33PM -0400, Barney Wolff wrote: > You're using htons on an int. Try not doing that. > Barney Wolff Oops. Then that's a bug in samplicator-1.2.1, from which I took the code. But after changing fport to an u_short it still does not work. > On Fri, Sep 14, 2001 at 12:23:57PM -0700, Jos Backus wrote: > > struct sock { > > int fport; > > int fsockfd; > > long sockbuflen; > > }; > > > > static int > > init_sock(ctx) > > struct sock *ctx; > > { > > struct sockaddr_in local_address; > > > > bzero(&local_address, sizeof local_address); > > local_address.sin_family = AF_INET; > > local_address.sin_addr.s_addr = htonl(INADDR_ANY); > > local_address.sin_port = htons(ctx->fport); Thanks, -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 14 17: 0:19 2001 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f195.law14.hotmail.com [64.4.21.195]) by hub.freebsd.org (Postfix) with ESMTP id E6B7A37B40B for ; Fri, 14 Sep 2001 17:00:16 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 14 Sep 2001 17:00:16 -0700 Received: from 138.89.30.212 by lw14fd.law14.hotmail.msn.com with HTTP; Sat, 15 Sep 2001 00:00:16 GMT X-Originating-IP: [138.89.30.212] From: "x x" To: freebsd-net@freebsd.org Subject: NAT and IPSEC Date: Fri, 14 Sep 2001 20:00:16 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Sep 2001 00:00:16.0755 (UTC) FILETIME=[66C41C30:01C13D79] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is it possible to use a signale FreeBSD box to serve as a NAT and IPSEC gateway? I can get either to work, but not both. Thanks. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 14 17: 8:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46]) by hub.freebsd.org (Postfix) with ESMTP id E7C7437B401 for ; Fri, 14 Sep 2001 17:08:02 -0700 (PDT) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id f8F07tZ01851; Fri, 14 Sep 2001 20:07:55 -0400 (EDT) (envelope-from barney) Date: Fri, 14 Sep 2001 20:07:50 -0400 From: Barney Wolff To: Barney Wolff Cc: Jos Backus , freebsd-net@FreeBSD.ORG Subject: Re: How does getsockname() work? Message-ID: <20010914200750.A1784@tp.databus.com> References: <20010914122357.A49323@lizzy.bugworks.com> <20010914165555.A150@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010914165555.A150@tp.databus.com>; from barney@databus.com on Fri, Sep 14, 2001 at 04:55:55PM -0400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Oh yeah - you have to initialize local_len to the max length you can accept. Whatever you took this code from either doesn't work reliably or you copied it wrong. Barney On Fri, Sep 14, 2001 at 04:55:55PM -0400, Barney Wolff wrote: > You're using htons on an int. Try not doing that. > Barney Wolff > > On Fri, Sep 14, 2001 at 12:23:57PM -0700, Jos Backus wrote: > > I am seeing the following difference between FreeBSD and Solaris when using > > the attached program, which uses getsockname(). > > I am using the following command to test this program: > > > > snmpwalk -p 1234 public > > > > being either goldenbytes or taiko. > > > > On FreeBSD 4 I see: > > > > goldenbytes:~/udp% ./udp & > > [1] 64015 > > goldenbytes:~/udp% received on 0.0.0.0:0 > > received 37 bytes from 157.57.212.23:1446 > > received on 0.0.0.0:0 > > received 37 bytes from 157.57.212.23:1446 > > received on 0.0.0.0:0 > > received 37 bytes from 157.57.212.23:1446 > > received on 0.0.0.0:0 > > received 37 bytes from 157.57.212.23:1446 > > > > On Solaris 7 I see: > > > > taiko:~/udp% ./udp & > > [1] 21129 > > taiko:~/udp% received on 0.0.0.0:1234 > > received 37 bytes from 157.57.212.23:1448 > > received on 0.0.0.0:1234 > > received 37 bytes from 157.57.212.23:1448 > > received on 0.0.0.0:1234 > > received 37 bytes from 157.57.212.23:1448 > > received on 0.0.0.0:1234 > > received 37 bytes from 157.57.212.23:1448 > > > > The 0.0.0.0 is caused by using INADDR_ANY as the binding address; what I don't > > understand is why Solaris shows the portnumber whereas FreeBSD doesn't. Surely > > I am doing something wrong, but what? > > > > Thanks, > > -- > > Jos Backus _/ _/_/_/ Santa Clara, CA > > _/ _/ _/ > > _/ _/_/_/ > > _/ _/ _/ _/ > > josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > #define PDU_SIZE 1500 > > > > struct sock { > > int fport; > > int fsockfd; > > long sockbuflen; > > }; > > > > static int > > init_sock(ctx) > > struct sock *ctx; > > { > > struct sockaddr_in local_address; > > > > bzero(&local_address, sizeof local_address); > > local_address.sin_family = AF_INET; > > local_address.sin_addr.s_addr = htonl(INADDR_ANY); > > local_address.sin_port = htons(ctx->fport); > > > > if ((ctx->fsockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { > > fprintf(stderr, "socket(): %s\n", strerror(errno)); > > exit(1); > > } > > if (bind(ctx->fsockfd, > > (struct sockaddr *)&local_address, sizeof local_address) < 0) { > > fprintf(stderr, "bind(): %s\n", strerror(errno)); > > exit(1); > > } > > } > > > > static int > > receive(ctx) > > struct sock *ctx; > > { > > unsigned char fpdu[PDU_SIZE]; > > struct sockaddr_in remote_address; > > struct sockaddr_in local_address; > > int i, len, n, local_len; > > > > while (1) { > > len = sizeof remote_address; > > if ((n = recvfrom(ctx->fsockfd, (char *)fpdu, > > sizeof(fpdu), 0, > > (struct sockaddr *)&remote_address, &len)) == -1) { > > fprintf(stderr, "recvfrom(): %s\n", strerror(errno)); > > exit(1); > > } > > if (getsockname(ctx->fsockfd, (struct sockaddr *)&local_address, > > &local_len) == -1) { > > fprintf(stderr, "getsockname(): %s\n", strerror(errno)); > > exit(1); > > } > > if (n > PDU_SIZE) { > > fprintf(stderr, "Warning: %d excess bytes discarded\n", > > n - PDU_SIZE); > > n = PDU_SIZE; > > } > > if (len != sizeof remote_address) { > > fprintf(stderr, "recvfrom() return address length %d - expected %d\n", > > len, sizeof remote_address); > > exit(1); > > } > > fprintf(stderr, "received on %s:%d\n", > > inet_ntoa(local_address.sin_addr), > > (int)ntohs(local_address.sin_port)); > > fprintf(stderr, "received %d bytes from %s:%d\n", > > n, > > inet_ntoa(remote_address.sin_addr), > > (int)ntohs(remote_address.sin_port)); > > } > > } > > > > int > > main(int ac, char *av[]) > > { > > struct sock s; > > > > s.fport = 1234; > > s.sockbuflen = 65536; > > > > init_sock(&s); > > > > receive(&s); > > } > > > 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 Sep 14 17:25:28 2001 Delivered-To: freebsd-net@freebsd.org Received: from w250.z064001178.sjc-ca.dsl.cnc.net (w250.z064001178.sjc-ca.dsl.cnc.net [64.1.178.250]) by hub.freebsd.org (Postfix) with SMTP id 4037E37B407 for ; Fri, 14 Sep 2001 17:25:26 -0700 (PDT) Received: (qmail 51938 invoked by uid 1000); 15 Sep 2001 00:25:47 -0000 Date: Fri, 14 Sep 2001 17:25:25 -0700 From: Jos Backus To: freebsd-net@FreeBSD.ORG Subject: Re: How does getsockname() work? Message-ID: <20010914172525.C49323@lizzy.bugworks.com> Reply-To: Jos Backus Mail-Followup-To: freebsd-net@FreeBSD.ORG References: <20010914122357.A49323@lizzy.bugworks.com> <20010914165555.A150@tp.databus.com> <20010914200750.A1784@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010914200750.A1784@tp.databus.com> User-Agent: Mutt/1.3.22.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Sep 14, 2001 at 08:07:28PM -0400, Barney Wolff wrote: > Oh yeah - you have to initialize local_len to the max length you > can accept. Whatever you took this code from either doesn't > work reliably or you copied it wrong. > Barney I indeed forgot to initialize local_len. It works fine now. Thanks! The bug in samplicator is still there in 1.3.1; I'll send a note to the author(s). -- Jos Backus _/ _/_/_/ Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/ _/ josb@cncdsl.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Sep 14 21:43: 0 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 4857937B403 for ; Fri, 14 Sep 2001 21:42:56 -0700 (PDT) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f8F4gtl47468; Fri, 14 Sep 2001 23:42:55 -0500 (CDT) (envelope-from nick@rogness.net) Date: Fri, 14 Sep 2001 23:42:55 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: x x Cc: freebsd-net@FreeBSD.ORG Subject: Re: NAT and IPSEC In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 14 Sep 2001, x x wrote: > Is it possible to use a signale FreeBSD box to serve as a NAT and IPSEC > gateway? I can get either to work, but not both. Thanks. Yes. Don't send the IPSEC packets through nat. Use gif tunnels instead. Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Sep 15 14:38: 5 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 87D9537B401 for ; Sat, 15 Sep 2001 14:38:01 -0700 (PDT) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by smtp1.sentex.ca (8.11.6/8.11.6) with SMTP id f8FLadT13636; Sat, 15 Sep 2001 17:36:39 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: ml@db.nexgen.com ("alexus") Cc: freebsd-net@freebsd.org Subject: Re: port forwarding through natd and/or ipfw Date: Sat, 15 Sep 2001 17:36:39 -0400 Message-ID: <08i7qt07tvms7vedjvrnelbvjarfqdjv7r@4ax.com> References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 12 Sep 2001 15:45:40 -0400, in sentex.lists.freebsd.net you wrote: >Hi > >My goal is to access my Windows XP workstation that is behind N.A.T. = FreeBSD >box's firewall >my public ip address is 66.92.98.145 and internal ip is 192.168.0.13 = port >that my XP workstation listens on is 3389r > >00333 6 288 fwd 66.92.98.145,3389 tcp from any to = 192.168.0.13 >3389 > >i *did* enabled firewall in kernel > >su-2.05# grep FIREWALL box >options IPFIREWALL #firewall >options IPFIREWALL_VERBOSE #print information about >options IPFIREWALL_VERBOSE_LIMIT=3D10 #limit verbosity >options IPFIREWALL_FORWARD #enable transparent proxy = support >su-2.05# I think you want DIVERT in there as well. In /etc/natd.conf (or where = you keep your rules), you want=20 redirect_port tcp 192.168.0.13:3389 66.92.98.145:3389 Get rid of the 333 fwd rule. Make sure there is the regular divert rule = as well that you get when you say YES to in /etc/rc.conf for natd. ---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