From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 17:16:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD9AE16A404 for ; Sun, 15 Apr 2007 17:16:11 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 3DC1E13C448 for ; Sun, 15 Apr 2007 17:16:09 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id DAA11394; Mon, 16 Apr 2007 03:15:58 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 16 Apr 2007 03:15:57 +1000 (EST) From: Ian Smith To: Bruce M Simpson In-Reply-To: <461A84BC.1040308@incunabulum.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: Call for testers: olsrd and IP_ONESBCAST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 17:16:11 -0000 On Mon, 9 Apr 2007, Bruce M Simpson wrote: > For a while now I have had a patch available to teach olsrd to use > IP_ONESBCAST instead of using libnet/bpf just to send broadcast > datagrams in FreeBSD, which has had IP_ONESBCAST for a few years now. Would 'a few years' likely include 5.5-STABLE? Which file/s will tell? > If anyone is using olsrd on FreeBSD I would greatly appreciate testing > and feedback for this patch: > http://people.freebsd.org/~bms/dump/olsrd-onesbcast.diff I've no reachable neighbours so far, but I've set it up and run it once or twice in anticipation of both geekier neighbours and better kit .. suppose you'll have come across https://www.open-mesh.net/batman ? If so, have you any thoughts on their rather savage dissing of olsrd as it stands, and apparent greater success with seeming raw, seat-of-pants, scarcely documented but possibly real-world-practical algorithms? Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 18:11:42 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B2EB16A402 for ; Sun, 15 Apr 2007 18:11:42 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 3916513C43E for ; Sun, 15 Apr 2007 18:11:40 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 46586 invoked from network); 15 Apr 2007 22:17:00 +0400 Received: from unknown (HELO localhost) (88.212.205.2) by mail.sub.ru with SMTP; 15 Apr 2007 22:17:00 +0400 X-Virus-Scanned: by amavisd-new at mail.sub.ru Received: from unknown ([88.212.205.2]) by localhost (mail-new.sub.ru [88.212.205.2]) (amavisd-new, port 10024) with SMTP id TGNWq777P7Vj for ; Sun, 15 Apr 2007 22:16:55 +0400 (MSD) Received: from unknown (HELO ?89.222.147.9?) (tarkhil%sub.ru@89.222.147.9) by techno.sub.ru with SMTP; 15 Apr 2007 18:16:55 -0000 Message-ID: <46226AD3.3030806@webmail.sub.ru> Date: Sun, 15 Apr 2007 22:11:31 +0400 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: FreeBSD-Net mailing list Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Please help with PF-based redirector X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 18:11:42 -0000 Hello! I'm trying to set up a box as round-robin TCP proxy. Of course, I'm trying to do everything on kernel-level. This simple setup rdr on sk0 proto tcp from any to any port = smtp -> port 25 round-robin should work. At least, I thought so. However, attempt to connect to port 25 yielded unexpected result. pfctl -s state shows self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- 89.108.94.211:56975 CLOSED:SYN_SENT connection never established, and no IP packet ever sends out to 89.108.94.212:25 I don't understand this thing. Maybe someone can point me to my error? (firewall rules a quite permissive, in fact, they are pass in quick and pass out quick for all interfaces. attempt to telnet to port 25 outside works ok) Alex. From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 20:07:06 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C436B16A400 for ; Sun, 15 Apr 2007 20:07:06 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 817E313C487 for ; Sun, 15 Apr 2007 20:07:06 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HdAzx-0007Nt-TZ for freebsd-net@freebsd.org; Sun, 15 Apr 2007 22:06:57 +0200 Received: from 83-131-166-8.adsl.net.t-com.hr ([83.131.166.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2007 22:06:57 +0200 Received: from ivoras by 83-131-166-8.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2007 22:06:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sun, 15 Apr 2007 22:06:37 +0200 Lines: 43 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCB1FCD6F77C71134B5A6E896" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-166-8.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) X-Enigmail-Version: 0.94.3.0 Sender: news Subject: ipfw, keep-state and limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 20:07:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB1FCD6F77C71134B5A6E896 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think I need to start filtering based on simultaneous connections from source IP addresses because of some abuse that's apparently going on, so, as I'm already using ipfw, I tried this: # ipfw add 6079 allow tcp from any to me 80 setup keep-state limit src-addr 10 To which ipfw replied: ipfw: only one of keep-state andlimit is allowed (including the "andlimit" typo). What I'm trying to do makes sense to me (and seems straightforward to implement, at least semantically): allow connections to port 80 with dynamic keep-state rules for individual clients, but allow only 10 connections from the same address. Is this a limitation in ipfw? Any suggestions? This is a 6-STABLE PAE+SMP machine. --------------enigCB1FCD6F77C71134B5A6E896 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIoXTldnAQVacBcgRAqwqAJ4hJg4vBpNLAtbKKGXA/1taY6P3NwCdG345 UTJqCHRrPc05rQqGNvQd/nM= =F42u -----END PGP SIGNATURE----- --------------enigCB1FCD6F77C71134B5A6E896-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 20:19:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DA6316A402 for ; Sun, 15 Apr 2007 20:19:05 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id F364613C457 for ; Sun, 15 Apr 2007 20:19:04 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HdBBZ-0000Xl-SX for freebsd-net@freebsd.org; Sun, 15 Apr 2007 22:18:57 +0200 Received: from 83-131-166-8.adsl.net.t-com.hr ([83.131.166.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2007 22:18:57 +0200 Received: from ivoras by 83-131-166-8.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2007 22:18:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sun, 15 Apr 2007 22:18:36 +0200 Lines: 92 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1C064251C9A3C21402BA7932" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-166-8.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Understanding ipfw keep-state dynamic rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 20:19:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C064251C9A3C21402BA7932 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On a rule: 06080 40997628 30756672556 allow tcp from any to me dst-port 80 setup keep-state ipfw -d show lists: ## Dynamic rules (774): 06080 948 38731 (108s) STATE tcp xx.172.115.202 1421 <-> my.ip.add.r 80 06080 985 42716 (83s) STATE tcp xx.67.223.104 1071 <-> my.ip.add.r 80 06080 863 35613 (283s) STATE tcp xx.10.57.15 2889 <-> my.ip.add.r 80 06080 985 42714 (83s) STATE tcp xx.67.223.104 1070 <-> my.ip.add.r 80 06080 328 14124 (53s) STATE tcp xx.139.119.108 1578 <-> my.ip.add.r 80 06080 25 3115 (218s) STATE tcp xx.131.91.227 1446 <-> my.ip.add.r 80 06080 143 111341 (68s) STATE tcp xx.53.69.19 2134 <-> my.ip.add.r 80 06080 768 57243 (58s) STATE tcp xx.0.135.14 1099 <-> my.ip.add.r 80 06080 669 27762 (283s) STATE tcp xx.139.74.217 2205 <-> my.ip.add.r 80 06080 1252 52827 (278s) STATE tcp xx.1.101.189 3833 <-> my.ip.add.r 80 06080 55 3234 (93s) STATE tcp xx.131.56.161 38373 <-> my.ip.add.r 80 06080 983 41973 (83s) STATE tcp xx.67.223.104 1068 <-> my.ip.add.r 80 06080 986 42606 (88s) STATE tcp xx.67.223.104 1067 <-> my.ip.add.r 80 06080 760 48062 (58s) STATE tcp xx.0.135.14 1101 <-> my.ip.add.r 80 06080 173 26123 (123s) STATE tcp xx.164.1.92 52510 <-> my.ip.add.r 80 06080 1437 142107 (98s) STATE tcp xx.193.203.99 50721 <-> my.ip.add.r 80 06080 985 42710 (83s) STATE tcp xx.67.223.104 1066 <-> my.ip.add.r 80 06080 5 1404 (296s) STATE tcp xx.172.46.212 2965 <-> my.ip.add.r 80 06080 960 39466 (108s) STATE tcp xx.53.72.69 1541 <-> my.ip.add.r 80 06080 986 42748 (88s) STATE tcp xx.67.223.104 1064 <-> my.ip.add.r 80 06080 671 28021 (238s) STATE tcp xx.139.74.217 2198 <-> my.ip.add.r 80 06080 666 27308 (118s) STATE tcp xx.163.196.124 62771 <-> my.ip.add.r 80 06080 102 45319 (98s) STATE tcp xx.131.91.227 1196 <-> my.ip.add.r 80 06080 1019 43213 (88s) STATE tcp xx.53.254.147 3804 <-> my.ip.add.r 80 06080 20 13796 (300s) STATE tcp xx.172.39.86 2072 <-> my.ip.add.r 80 06080 66 14493 (98s) STATE tcp xx.131.91.227 1197 <-> my.ip.add.r 80 06080 1140 173804 (78s) STATE tcp xx.81.188.12 64322 <-> my.ip.add.r 80 This is on a busy, but fast and fat-piped web server. Do the numbers in parentheses mean seconds the rule is active? The numbers seem very high, much higher that they should be (keepalive is active but the timeout is kept under 5 seconds, and the pages & files are mostly small). --------------enig1C064251C9A3C21402BA7932 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIoicldnAQVacBcgRAo5xAJ4mD3tTJELyFMGeTTrul5/4OgihrgCgvTFJ ROVES/lr1Uf8t41sXXVNiZY= =qd/d -----END PGP SIGNATURE----- --------------enig1C064251C9A3C21402BA7932-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 20:50:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 585AA16A47C for ; Sun, 15 Apr 2007 20:50:12 +0000 (UTC) (envelope-from root@herkules.letsbuild.ch) Received: from hades.letsbuild.ch (hades.letsbuild.ch [62.2.150.180]) by mx1.freebsd.org (Postfix) with ESMTP id DD2CB13C48C for ; Sun, 15 Apr 2007 20:50:10 +0000 (UTC) (envelope-from root@herkules.letsbuild.ch) Received: from herkules.letsbuild.ch (herkules.letsbuild.ch [62.2.150.182]) by hades.letsbuild.ch (Postfix) with ESMTP id 5883C1C569 for ; Sun, 15 Apr 2007 22:25:37 +0200 (CEST) Received: by herkules.letsbuild.ch (Postfix, from userid 0) id 4DA151C4718; Sun, 15 Apr 2007 22:25:37 +0200 (CEST) To: freebsd-net@freebsd.org Message-ID: <1176668737.25050.qmail@eBay> From: "From: eBay Member angelab5419" Date: Sun, 15 Apr 2007 22:25:37 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Question about Item #138811728649 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 20:50:12 -0000 eBay eBay sent this message Your registered name is included to show this message originated from eBay. [1]Learn more. [ltCurve.gif] eBay New Message Received from Seller for Item #138811728649 [rtCurve.gif] [s.gif] [s.gif] [s.gif] [s.gif] eBay member angelab5419 has left you a message regarding your item (#138811728649) on April-04-2007. Thank you, eBay [s.gif] View the dispute thread [s.gif] [2]Respond Now [s.gif] Details for item number: 138811728649 Item URL: [3]http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=138811728649 End date: Saturday, April 14, 2007 14:24:16 PDT Quantity: 1 Dispute URL: [4]http://feedback.ebay.com/ws/eBayISAPI.dll?ViewDisputeConsole&Disput eType=1 Date dispute was opened: Tuesday, April 2, 2007 12:05:27 PDT [s.gif] [s.gif] [s.gif] [s.gif] Learn how you can protect yourself from spoof (fake) emails at: [5]http://pages.ebay.com/education/spooftutorial This eBay notice was sent to you from eBay. Your account is registered on [6]www.ebay.com. As outlined in our User Agreement, eBay will send you required notifications about the site and your transactions. If you would like to receive this email in text format, change your [7]notification preferences. See our Privacy Policy and User Agreement if you have questions about eBay's communication policies. Privacy Policy: [8]http://pages.ebay.com/help/policies/privacy-policy.html User Agreement: [9]http://pages.ebay.com/help/policies/user-agreement.html Copyright © 2007 eBay, Inc. All Rights Reserved. Designated trademarks and brands are the property of their respective owners. eBay and the eBay logo are registered trademarks or trademarks of eBay, Inc. eBay is located at 2145 Hamilton Avenue, San Jose, CA 95125. References 1. http://pages.ebay.com/help/confidence/name-userid-emails.html 2. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 3. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 4. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 5. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 6. http://soot.unixhelper.org/SIngIn/signin.ebay.com/ws/eBayISAPI/index.html 7. http://cgi4.ebay.com/ws/eBayISAPI.dll?OptinLoginShow 8. http://pages.ebay.com/help/policies/privacy-policy.html 9. http://pages.ebay.com/help/policies/user-agreement.html From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 21:49:34 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C43816A401 for ; Sun, 15 Apr 2007 21:49:34 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 498A913C45E for ; Sun, 15 Apr 2007 21:49:34 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l3FLnOCX039415; Sun, 15 Apr 2007 14:49:24 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l3FLnMTg039414; Sun, 15 Apr 2007 14:49:22 -0700 (PDT) (envelope-from rizzo) Date: Sun, 15 Apr 2007 14:49:22 -0700 From: Luigi Rizzo To: Ivan Voras Message-ID: <20070415144922.A39338@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ivoras@fer.hr on Sun, Apr 15, 2007 at 10:06:37PM +0200 Cc: freebsd-net@freebsd.org Subject: Re: ipfw, keep-state and limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 21:49:34 -0000 On Sun, Apr 15, 2007 at 10:06:37PM +0200, Ivan Voras wrote: > I think I need to start filtering based on simultaneous connections from > source IP addresses because of some abuse that's apparently going on, > so, as I'm already using ipfw, I tried this: > > # ipfw add 6079 allow tcp from any to me 80 setup keep-state limit > src-addr 10 > > To which ipfw replied: > > ipfw: only one of keep-state andlimit is allowed > > (including the "andlimit" typo). > > What I'm trying to do makes sense to me (and seems straightforward to > implement, at least semantically): allow connections to port 80 with > dynamic keep-state rules for individual clients, but allow only 10 > connections from the same address. Is this a limitation in ipfw? Any > suggestions? if i remember well (the implementation dates back to 2001 or so) you just need to use "limit", as it implicitly installs a dynamic state entry (same as keep-state). cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 21:53:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F399416A400 for ; Sun, 15 Apr 2007 21:53:35 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id AD73F13C4B8 for ; Sun, 15 Apr 2007 21:53:35 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HdCf1-000455-UV for freebsd-net@freebsd.org; Sun, 15 Apr 2007 23:53:27 +0200 Received: from 83-131-166-8.adsl.net.t-com.hr ([83.131.166.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2007 23:53:27 +0200 Received: from ivoras by 83-131-166-8.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Apr 2007 23:53:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Sun, 15 Apr 2007 23:53:15 +0200 Lines: 31 Message-ID: References: <20070415144922.A39338@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7B0B050950F35736A5A4709C" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-166-8.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) In-Reply-To: <20070415144922.A39338@xorpc.icir.org> X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Re: ipfw, keep-state and limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 21:53:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7B0B050950F35736A5A4709C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Luigi Rizzo wrote: > if i remember well (the implementation dates back to 2001 or so) > you just need to use "limit", as it implicitly installs > a dynamic state entry (same as keep-state). Thanks, I'll try it tomorrow. If it works, may I suggest a change: make the error message say "keep-state is redundant with limits" and proceed like only "limits" exists? --------------enig7B0B050950F35736A5A4709C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIp7LldnAQVacBcgRArqtAJ9kfZ/QrGFhQ9prwmEeY8pikFsLMwCg1D+U 2aQjCaCtj+vV/c1jcDPcIFw= =O4d4 -----END PGP SIGNATURE----- --------------enig7B0B050950F35736A5A4709C-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 21:56:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29FE716A400 for ; Sun, 15 Apr 2007 21:56:23 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 174EF13C4AE for ; Sun, 15 Apr 2007 21:56:23 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l3FLuLES039530; Sun, 15 Apr 2007 14:56:21 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l3FLuLw7039529; Sun, 15 Apr 2007 14:56:21 -0700 (PDT) (envelope-from rizzo) Date: Sun, 15 Apr 2007 14:56:21 -0700 From: Luigi Rizzo To: Ivan Voras Message-ID: <20070415145621.B39338@xorpc.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ivoras@fer.hr on Sun, Apr 15, 2007 at 10:18:36PM +0200 Cc: freebsd-net@freebsd.org Subject: Re: Understanding ipfw keep-state dynamic rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 21:56:23 -0000 On Sun, Apr 15, 2007 at 10:18:36PM +0200, Ivan Voras wrote: > On a rule: > > 06080 40997628 30756672556 allow tcp from any to me dst-port 80 setup > keep-state > > ipfw -d show lists: > > ## Dynamic rules (774): > 06080 948 38731 (108s) STATE tcp xx.172.115.202 1421 <-> > my.ip.add.r 80 > 06080 985 42716 (83s) STATE tcp xx.67.223.104 1071 <-> > my.ip.add.r 80 ... > This is on a busy, but fast and fat-piped web server. > > Do the numbers in parentheses mean seconds the rule is active? The > numbers seem very high, much higher that they should be (keepalive is > active but the timeout is kept under 5 seconds, and the pages & files > are mostly small). yes the numbers should be the expire time for the rule. ipfw has a default timeout of 300, and the it only uses the "short" lifetimes when the remote end properly closes the connection with a FIN. If it doesn't, then the firewall cannot put a short timeout because the other endpoint could in principle want to send more data on the connection and we need to let it through. check the values of these sysctl variables net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 you normally end up using dyn_ack_lifetime for TCP session cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 22:00:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85C6E16A46D for ; Sun, 15 Apr 2007 22:00:52 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3E413C4DA for ; Sun, 15 Apr 2007 22:00:52 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l3FM0oM7039588; Sun, 15 Apr 2007 15:00:50 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l3FM0oUE039587; Sun, 15 Apr 2007 15:00:50 -0700 (PDT) (envelope-from rizzo) Date: Sun, 15 Apr 2007 15:00:50 -0700 From: Luigi Rizzo To: Ivan Voras Message-ID: <20070415150050.C39338@xorpc.icir.org> References: <20070415144922.A39338@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ivoras@fer.hr on Sun, Apr 15, 2007 at 11:53:15PM +0200 Cc: freebsd-net@freebsd.org Subject: Re: ipfw, keep-state and limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 22:00:52 -0000 On Sun, Apr 15, 2007 at 11:53:15PM +0200, Ivan Voras wrote: > Luigi Rizzo wrote: > > > if i remember well (the implementation dates back to 2001 or so) > > you just need to use "limit", as it implicitly installs > > a dynamic state entry (same as keep-state). > > Thanks, I'll try it tomorrow. If it works, may I suggest a change: make > the error message say "keep-state is redundant with limits" and proceed > like only "limits" exists? it certainly makes sense to change the error message and explain better what is wrong. However i really don't like the idea of accepting a wrong ipfw rule, because it encourages lazy programming practices. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 22:36:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E1A8116A402 for ; Sun, 15 Apr 2007 22:36:58 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6ABC813C45A for ; Sun, 15 Apr 2007 22:36:58 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls248.t-com.hr (ls248.t-com.hr [195.29.150.237]) by ls405.t-com.hr (Postfix) with ESMTP id 134F3144588; Mon, 16 Apr 2007 00:07:42 +0200 (CEST) Received: from ls248.t-com.hr (ls248.t-com.hr [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id 0F65AD5004A; Mon, 16 Apr 2007 00:07:42 +0200 (CEST) Received: from ls248.t-com.hr (ls248.t-com.hr [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id EDEC9D50047; Mon, 16 Apr 2007 00:07:41 +0200 (CEST) X-Envelope-Sender-Info: g5URFa92gX9K/Rg9VFA/rMAHjbtiLlWI28tB5bY/lrY6StkSH1j7CT0zJW9WjWDV X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.100] (83-131-166-8.adsl.net.t-com.hr [83.131.166.8]) by ls248.t-com.hr (Qmali) with ESMTP id BB87F5E00BE; Mon, 16 Apr 2007 00:07:41 +0200 (CEST) Message-ID: <4622A227.9090003@fer.hr> Date: Mon, 16 Apr 2007 00:07:35 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Luigi Rizzo References: <20070415145621.B39338@xorpc.icir.org> In-Reply-To: <20070415145621.B39338@xorpc.icir.org> X-Enigmail-Version: 0.94.3.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE77C8CDF91EF2876CD7333D1" Cc: freebsd-net@freebsd.org Subject: Re: Understanding ipfw keep-state dynamic rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 22:36:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE77C8CDF91EF2876CD7333D1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Luigi Rizzo wrote: > yes the numbers should be the expire time for the rule. So, the total time the connection was active or the time the connection had some traffic through it? > ipfw has a default timeout of 300, and the it only uses the > "short" lifetimes when the remote end properly closes the > connection with a FIN. If it doesn't, then the firewall > cannot put a short timeout because the other endpoint > could in principle want to send more data on the connection > and we need to let it through. Hmm. There are several dynamic rules with large expire times - could it mean that a lot of clients are not properly closing the connection? If I set net.inet.ip.fw.dyn_ack_lifetime to a small-ish value (like 15 seconds), will it interfere with long-lasting downloads or slow clients? Would it do anything to the server application? (e.g. close its side of the connection so the application doesn't keep the socket open for such a long time) --------------enigE77C8CDF91EF2876CD7333D1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIqInldnAQVacBcgRAkRTAKDp30yZZINWsLMAXCd/LYtL6gaQQQCeM/8Y 8BOJlYs8LuS9Y1Cp0I8QFz4= =Bw6x -----END PGP SIGNATURE----- --------------enigE77C8CDF91EF2876CD7333D1-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 15 22:54:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B4D616A403 for ; Sun, 15 Apr 2007 22:54:05 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id EBCB213C44B for ; Sun, 15 Apr 2007 22:54:04 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l3FMs21P040305; Sun, 15 Apr 2007 15:54:02 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l3FMs2WC040304; Sun, 15 Apr 2007 15:54:02 -0700 (PDT) (envelope-from rizzo) Date: Sun, 15 Apr 2007 15:54:02 -0700 From: Luigi Rizzo To: Ivan Voras Message-ID: <20070415155402.A40022@xorpc.icir.org> References: <20070415145621.B39338@xorpc.icir.org> <4622A227.9090003@fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4622A227.9090003@fer.hr>; from ivoras@fer.hr on Mon, Apr 16, 2007 at 12:07:35AM +0200 Cc: freebsd-net@freebsd.org Subject: Re: Understanding ipfw keep-state dynamic rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 22:54:05 -0000 On Mon, Apr 16, 2007 at 12:07:35AM +0200, Ivan Voras wrote: > Luigi Rizzo wrote: > > > yes the numbers should be the expire time for the rule. > > So, the total time the connection was active or the time the connection > had some traffic through it? it is the expire time (i.e. how many seconds from now the rule will be deleted). It should normally be the preset timeout (300 as a default for active sessions) minus the time for which the connection has been idle. > Hmm. There are several dynamic rules with large expire times - could it > mean that a lot of clients are not properly closing the connection? yes, i believe so. > If I set net.inet.ip.fw.dyn_ack_lifetime to a small-ish value (like 15 > seconds), will it interfere with long-lasting downloads or slow clients? this is related to the way TCP handles retransmissions, and i don't want to write a long explaination here. But if you make it shorter than the TCP retransmission timeout (which can be as large as 1 minute in some cases) you risk your connection to be dropped in case of a packet loss or two. > Would it do anything to the server application? (e.g. close its side of > the connection so the application doesn't keep the socket open for such > a long time) in terms of tcp, on the server you would need to send a FIN (to signal "no more data from me") followed by a RST (to signal "i am not listening anymore"). Maybe a shutdown(s, SHUT_RDWR) can do the job, probably just close() is not enough. But i am not 100% sure. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 03:30:48 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80F0E16A400; Mon, 16 Apr 2007 03:30:48 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7024313C484; Mon, 16 Apr 2007 03:30:48 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id E60F61A3C1C; Sun, 15 Apr 2007 20:31:00 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B2A215125C; Sun, 15 Apr 2007 23:30:47 -0400 (EDT) Date: Sun, 15 Apr 2007 23:30:47 -0400 From: Kris Kennaway To: current@FreeBSD.org, net@FreeBSD.org Message-ID: <20070416033047.GA31857@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: Subject: GPF in ether_output -> m_tag_locate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 03:30:48 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On an 8-core amd64 running up-to-date CVS sources: > Fatal trap 9: general protection fault while in kernel mode > cpuid = 7; apic id = 07 > instruction pointer = 0x8:0xffffffff802a7800 > stack pointer = 0x10:0xffffffffabc61960 > frame pointer = 0x10:0xffffffffabc61970 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 19 (swi4: clock sio) > Tracing pid 19 tid 100005 td 0xffffff00b9a7f000 > m_tag_locate() at m_tag_locate+0x20 > ether_output() at ether_output+0x2ec > ip_output() at ip_output+0x9b5 > udp_output() at udp_output+0x594 > udp_send() at udp_send+0x1c > nfs_timer() at nfs_timer+0x7de > softclock() at softclock+0x319 > ithread_execute_handlers() at ithread_execute_handlers+0x15d > ithread_loop() at ithread_loop+0x69 > fork_exit() at fork_exit+0x93 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffffabc61d30, rbp = 0 --- Kris --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGIu3nWry0BWjoQKURArDyAKC1wijBrzgTG6F1zNCiQpKdM2V0eQCgg6W9 nhPbhZFxKKkR9c1ki6d/cZk= =95PM -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 03:40:02 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA60F16A403; Mon, 16 Apr 2007 03:40:02 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CC3AB13C4BD; Mon, 16 Apr 2007 03:40:02 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 1A8641A3C1C; Sun, 15 Apr 2007 20:40:15 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id DFE0751288; Sun, 15 Apr 2007 23:40:01 -0400 (EDT) Date: Sun, 15 Apr 2007 23:40:01 -0400 From: Kris Kennaway To: Kris Kennaway Message-ID: <20070416034001.GA32090@xor.obsecurity.org> References: <20070416033047.GA31857@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20070416033047.GA31857@xor.obsecurity.org> User-Agent: Mutt/1.4.2.2i Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: GPF in ether_output -> m_tag_locate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 03:40:03 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 15, 2007 at 11:30:47PM -0400, Kris Kennaway wrote: > On an 8-core amd64 running up-to-date CVS sources: >=20 > > Fatal trap 9: general protection fault while in kernel mode > > cpuid =3D 7; apic id =3D 07 > > instruction pointer =3D 0x8:0xffffffff802a7800 > > stack pointer =3D 0x10:0xffffffffabc61960 > > frame pointer =3D 0x10:0xffffffffabc61970 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 19 (swi4: clock sio) > > Tracing pid 19 tid 100005 td 0xffffff00b9a7f000 > > m_tag_locate() at m_tag_locate+0x20 > > ether_output() at ether_output+0x2ec > > ip_output() at ip_output+0x9b5 > > udp_output() at udp_output+0x594 > > udp_send() at udp_send+0x1c > > nfs_timer() at nfs_timer+0x7de > > softclock() at softclock+0x319 > > ithread_execute_handlers() at ithread_execute_handlers+0x15d > > ithread_loop() at ithread_loop+0x69 > > fork_exit() at fork_exit+0x93 > > fork_trampoline() at fork_trampoline+0xe > > --- trap 0, rip =3D 0, rsp =3D 0xffffffffabc61d30, rbp =3D 0 --- #9 0xffffffff802a7800 in m_tag_locate (m=3D0xffffff0033956a00, cookie=3D0,= type=3D21, t=3D0x5f73736e0e000000) at ../../../kern/uipc_mbuf2.c:393 p =3D (struct m_tag *) 0x5f73736e0e000000 #10 0xffffffff802ed9dc in ether_output (ifp=3D0xffffff0000900800, m=3D0xfff= fff0033956a00, dst=3D0xffffffffabc61a38, rt0=3D0x0) at mbuf.h:950 type =3D 8 error =3D 865430226 hdrcmplt =3D 0 esrc =3D "\000\b\220\000\000=FF" edst =3D "\000\002=B3\027>\021" eh =3D (struct ether_header *) 0xffffff0033956ad2 loop_copy =3D 1 #11 0xffffffff80304345 in ip_output (m=3D0xffffff0033956a00, opt=3D0x0, ro= =3D0xffffffffabc61a30, flags=3D0, imo=3D0x0, inp=3D0xffffff00152a9e38) at ../../../netinet/ip_output.c:561 ip =3D (struct ip *) 0xffffff0033956ae0 ifp =3D (struct ifnet *) 0xffffff0000900800 m0 =3D (struct mbuf *) 0x0 hlen =3D 20 mtu =3D 1500 len =3D 0 error =3D 0 dst =3D (struct sockaddr_in *) 0xffffffffabc61a38 ia =3D (struct in_ifaddr *) 0xffffff001583e600 isbroadcast =3D 234881024 sw_csum =3D 0 iproute =3D {ro_rt =3D 0xffffff00949320f0, ro_dst =3D {sa_len =3D 1= 6 '\020', sa_family =3D 2 '\002', sa_data =3D "\000\000=CC\230=BF=E2\000\00= 0\000\000\000\000\000"}} odst =3D {s_addr =3D 0} #12 0xffffffff80317c24 in udp_output (inp=3D0xffffff00152a9e38, m=3D0xfffff= f0033956a00, addr=3D0x0, control=3D0xffffff0033956ae0, td=3D0xffffff00b9a7f= 000) at ../../../netinet/udp_usrreq.c:934 ui =3D (struct udpiphdr *) 0xffffff0033956ae0 len =3D 0 faddr =3D {s_addr =3D 3804207308} laddr =3D {s_addr =3D 3871316172} cm =3D (struct cmsghdr *) 0x0 src =3D {sin_len =3D 0 '\0', sin_family =3D 0 '\0', sin_port =3D 22= 405, sin_addr =3D {s_addr =3D 4294967040}, sin_zero =3D "\001\000\000\000\0= 00\000\000"} error =3D 55 ipflags =3D 0 fport =3D 264 lport =3D 4355 unlock_udbinfo =3D 0 #13 0xffffffff8031874c in udp_send (so=3D0xffffff0033956a00, flags=3D0, m= =3D0x0, addr=3D0x0, control=3D0x5f73736e0e000000, td=3D0xffffff00152a9e38) at ../../../netinet/udp_usrreq.c:1116 inp =3D (struct inpcb *) 0xffffff0033956a00 #14 0xffffffff8032ff8e in nfs_timer (arg=3D0xffffff0033956a00) at pcpu.h:168 rep =3D (struct nfsreq *) 0xffffff0008250600 m =3D (struct mbuf *) 0xffffff0057854a00 so =3D (struct socket *) 0xffffff00157d7bb8 nmp =3D (struct nfsmount *) 0xffffff001575f000 timeo =3D 234881024 error =3D 1468353024 now =3D {tv_sec =3D 89409, tv_usec =3D 181305} --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGIvARWry0BWjoQKURAnKeAJ9QnTANZ2zmprL04wJRHSMDeLHw7gCeMNSk W36Xbhhv1wmm8WyKt9h4+ic= =XZ+Q -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 04:37:43 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 022B816A400 for ; Mon, 16 Apr 2007 04:37:43 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by mx1.freebsd.org (Postfix) with ESMTP id A1E2013C468 for ; Mon, 16 Apr 2007 04:37:42 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1137282nza for ; Sun, 15 Apr 2007 21:37:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n+jI3JQCkCGv12mlB11FSX1LjhZbIlp4G1lLbmkl/xVCjx2Oc5OLwAPo7gUIaIlUgPkz6w6PWlKl+xppMUJEsPMVp+Kj0FOe+kU/76kN2s/VzeXgDDZD2+0QcA68eBlo2Qs4ufojCmO6jO9PYXf7Dwc2dGnbRpnbMKdOR/jzCAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QWstsgPmk0cX2DIzSaQQ7zG2N69jpyi45/+f7rsKn+Y+OiXrrNcND6MqxPIt3sAQNjTFWh+IjvLcu+fyN73KvuOAF4wWZpXn6YwZCMV4vJxhlL1zbBHKbtonAI54TXgKnJnx9qOuQuaBwTjGN8zySPiclN7xHw6UyNFY7Q9o6gc= Received: by 10.65.254.5 with SMTP id g5mr11233857qbs.1176698262015; Sun, 15 Apr 2007 21:37:42 -0700 (PDT) Received: by 10.65.182.19 with HTTP; Sun, 15 Apr 2007 21:37:41 -0700 (PDT) Message-ID: Date: Sun, 15 Apr 2007 21:37:41 -0700 From: "Kip Macy" To: "Kris Kennaway" In-Reply-To: <20070416034001.GA32090@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20070416033047.GA31857@xor.obsecurity.org> <20070416034001.GA32090@xor.obsecurity.org> Cc: current@freebsd.org, net@freebsd.org Subject: Re: GPF in ether_output -> m_tag_locate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 04:37:43 -0000 Please print out the mbuf's m_hdr and pkthdr. -Kip On 4/15/07, Kris Kennaway wrote: > On Sun, Apr 15, 2007 at 11:30:47PM -0400, Kris Kennaway wrote: > > On an 8-core amd64 running up-to-date CVS sources: > > > > > Fatal trap 9: general protection fault while in kernel mode > > > cpuid =3D 7; apic id =3D 07 > > > instruction pointer =3D 0x8:0xffffffff802a7800 > > > stack pointer =3D 0x10:0xffffffffabc61960 > > > frame pointer =3D 0x10:0xffffffffabc61970 > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > current process =3D 19 (swi4: clock sio) > > > Tracing pid 19 tid 100005 td 0xffffff00b9a7f000 > > > m_tag_locate() at m_tag_locate+0x20 > > > ether_output() at ether_output+0x2ec > > > ip_output() at ip_output+0x9b5 > > > udp_output() at udp_output+0x594 > > > udp_send() at udp_send+0x1c > > > nfs_timer() at nfs_timer+0x7de > > > softclock() at softclock+0x319 > > > ithread_execute_handlers() at ithread_execute_handlers+0x15d > > > ithread_loop() at ithread_loop+0x69 > > > fork_exit() at fork_exit+0x93 > > > fork_trampoline() at fork_trampoline+0xe > > > --- trap 0, rip =3D 0, rsp =3D 0xffffffffabc61d30, rbp =3D 0 --- > > #9 0xffffffff802a7800 in m_tag_locate (m=3D0xffffff0033956a00, cookie=3D= 0, type=3D21, t=3D0x5f73736e0e000000) at ../../../kern/uipc_mbuf2.c:393 > p =3D (struct m_tag *) 0x5f73736e0e000000 > #10 0xffffffff802ed9dc in ether_output (ifp=3D0xffffff0000900800, m=3D0xf= fffff0033956a00, dst=3D0xffffffffabc61a38, rt0=3D0x0) at mbuf.h:950 > type =3D 8 > error =3D 865430226 > hdrcmplt =3D 0 > esrc =3D "\000\b\220\000\000=FF" > edst =3D "\000\002=B3\027>\021" > eh =3D (struct ether_header *) 0xffffff0033956ad2 > loop_copy =3D 1 > #11 0xffffffff80304345 in ip_output (m=3D0xffffff0033956a00, opt=3D0x0, r= o=3D0xffffffffabc61a30, flags=3D0, imo=3D0x0, inp=3D0xffffff00152a9e38) > at ../../../netinet/ip_output.c:561 > ip =3D (struct ip *) 0xffffff0033956ae0 > ifp =3D (struct ifnet *) 0xffffff0000900800 > m0 =3D (struct mbuf *) 0x0 > hlen =3D 20 > mtu =3D 1500 > len =3D 0 > error =3D 0 > dst =3D (struct sockaddr_in *) 0xffffffffabc61a38 > ia =3D (struct in_ifaddr *) 0xffffff001583e600 > isbroadcast =3D 234881024 > sw_csum =3D 0 > iproute =3D {ro_rt =3D 0xffffff00949320f0, ro_dst =3D {sa_len =3D= 16 '\020', sa_family =3D 2 '\002', sa_data =3D "\000\000=CC\230=BF=E2\000\= 000\000\000\000\000\000"}} > odst =3D {s_addr =3D 0} > #12 0xffffffff80317c24 in udp_output (inp=3D0xffffff00152a9e38, m=3D0xfff= fff0033956a00, addr=3D0x0, control=3D0xffffff0033956ae0, td=3D0xffffff00b9a= 7f000) > at ../../../netinet/udp_usrreq.c:934 > ui =3D (struct udpiphdr *) 0xffffff0033956ae0 > len =3D 0 > faddr =3D {s_addr =3D 3804207308} > laddr =3D {s_addr =3D 3871316172} > cm =3D (struct cmsghdr *) 0x0 > src =3D {sin_len =3D 0 '\0', sin_family =3D 0 '\0', sin_port =3D = 22405, sin_addr =3D {s_addr =3D 4294967040}, sin_zero =3D "\001\000\000\000= \000\000\000"} > error =3D 55 > ipflags =3D 0 > fport =3D 264 > lport =3D 4355 > unlock_udbinfo =3D 0 > #13 0xffffffff8031874c in udp_send (so=3D0xffffff0033956a00, flags=3D0, m= =3D0x0, addr=3D0x0, control=3D0x5f73736e0e000000, td=3D0xffffff00152a9e38) > at ../../../netinet/udp_usrreq.c:1116 > inp =3D (struct inpcb *) 0xffffff0033956a00 > #14 0xffffffff8032ff8e in nfs_timer (arg=3D0xffffff0033956a00) at pcpu.h:= 168 > rep =3D (struct nfsreq *) 0xffffff0008250600 > m =3D (struct mbuf *) 0xffffff0057854a00 > so =3D (struct socket *) 0xffffff00157d7bb8 > nmp =3D (struct nfsmount *) 0xffffff001575f000 > timeo =3D 234881024 > error =3D 1468353024 > now =3D {tv_sec =3D 89409, tv_usec =3D 181305} > > From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 06:14:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FAD016A403 for ; Mon, 16 Apr 2007 06:14:31 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 39CB913C43E for ; Mon, 16 Apr 2007 06:14:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id QAA01015; Mon, 16 Apr 2007 16:14:09 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 16 Apr 2007 16:14:08 +1000 (EST) From: Ian Smith To: Luigi Rizzo In-Reply-To: <20070415150050.C39338@xorpc.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: ipfw, keep-state and limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 06:14:31 -0000 On Sun, 15 Apr 2007, Luigi Rizzo wrote: > On Sun, Apr 15, 2007 at 11:53:15PM +0200, Ivan Voras wrote: > > Luigi Rizzo wrote: > > > > > if i remember well (the implementation dates back to 2001 or so) > > > you just need to use "limit", as it implicitly installs > > > a dynamic state entry (same as keep-state). > > > > Thanks, I'll try it tomorrow. If it works, may I suggest a change: make > > the error message say "keep-state is redundant with limits" and proceed > > like only "limits" exists? > > it certainly makes sense to change the error message and > explain better what is wrong. > However i really don't like the idea of accepting a wrong ipfw rule, > because it encourages lazy programming practices. Agree about not 'correcting' invalid rules. ipfw(8) adequately implies (to me, anyway), in several places and most particularly in the STATEFUL FIREWALL section, that keep-state and limit are mutually exclusive, though I guess this could be stated a bit more explicitly in the RULE OPTIONS (MATCH PATTERNS) section for both keep-state and limit. Cheers, Ian From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 09:54:16 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 764B216A400 for ; Mon, 16 Apr 2007 09:54:16 +0000 (UTC) (envelope-from email@onlyoneink.emv1.net) Received: from emailer99-225.emv1.net (emailer99-225.emv1.net [84.14.99.225]) by mx1.freebsd.org (Postfix) with ESMTP id 172DE13C46C for ; Mon, 16 Apr 2007 09:54:15 +0000 (UTC) (envelope-from email@onlyoneink.emv1.net) Date: Mon, 16 Apr 2007 11:52:40 +0200 (CEST) From: Only One Ink To: "net@freebsd.org" Message-ID: <4520581260.1100485.1176717160640@sch3.emv2.com> MIME-Version: 1.0 X-EMV-CampagneId: 1100485$ X-EMV-MemberId: 4520581260$ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Un VTT Decathlon offert avec votre premiere commande X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "sceclient@onlyoneink.com" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 09:54:16 -0000 Onlyoneink Message invisible, cliquez ici Offre réservée à votre société Un VTT Decathlon offert pour toute commande supérieure à 400€HT ! VTT - Rockrider 5.0 h Conçu pour les amateurs de nature recherchant un vélo solide et polyvalent. Pour bénéficier de cette offre, rien de plus simple : - connectez vous sur notre site http://as1.emv2.com/I?a=A9X7Cqgr_6lj8TD39aL7agrigQ - dans la section "Panier", inscrivez le code suivant : OoiVTT16P17 ou copiez-collez le lien suivant dans votre navigateur web : http://as1.emv2.com/I?a=A9X7Cqgr_6lj8TD39aL7agvigg Votre vélo sera automatiquement ajoutée à votre panier lors de votre commande. Bonne journée. L'équipe OnlyOneInk 0 821 099 099 From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 10:21:20 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E88C16A402 for ; Mon, 16 Apr 2007 10:21:20 +0000 (UTC) (envelope-from email@welcomeoffice.emv1.net) Received: from emailer99-225.emv1.net (emailer99-225.emv1.net [84.14.99.225]) by mx1.freebsd.org (Postfix) with ESMTP id E3A4813C458 for ; Mon, 16 Apr 2007 10:21:19 +0000 (UTC) (envelope-from email@welcomeoffice.emv1.net) Date: Mon, 16 Apr 2007 12:19:44 +0200 (CEST) From: Welcome Office To: "net@freebsd.org" Message-ID: <4520581260.1096155.1176718784537@sch3.emv2.com> MIME-Version: 1.0 X-EMV-CampagneId: 1096155$ X-EMV-MemberId: 4520581260$ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Un avertisseur de radar offert avec votre premiere commande ! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "clientele@welcomeoffice.com" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 10:21:20 -0000 WELCOME OFFICE n°1 DU DISCOUNT AUX ENTREPRISES Message invisible, cliquez ici Offre réservée à votre société, Un avertisseur de radar INFORAD V2 offert pour toute première commande supérieure à 400¤ HT ! Le 1er avertisseur de radar légal. Préservez les points de votre permis ! Contient : - le récepteur GPS, - le câble de liaison USB, - 1 adaptateur allume cigare 12/24 Volts, - 2 pastilles velcro, - le manuel d'utilisation - Antenne Magnétique Auto Pour bénéficier de cette offre, rien de plus simple : - connectez vous sur notre site http://as1.emv2.com/I?a=A9X7Cqgr_6lj8TCE66L8vEPiBA - dans la section "Ma commande", inscrivez le code suivant : M16KRADP17 ou copiez-collez le lien suivant dans votre navigateur web http://as1.emv2.com/I?a=A9X7Cqgr_6lj8TCE66L8vEDiBQ Bonne journée. L'équipe WELCOME OFFICE From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 11:08:40 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4CF0916A409 for ; Mon, 16 Apr 2007 11:08:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1F713C4B8 for ; Mon, 16 Apr 2007 11:08:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3GB8e6O042896 for ; Mon, 16 Apr 2007 11:08:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3GB8cxB042892 for freebsd-net@FreeBSD.org; Mon, 16 Apr 2007 11:08:38 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Apr 2007 11:08:38 GMT Message-Id: <200704161108.l3GB8cxB042892@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 11:08:40 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/109406 net [ndis] Broadcom WLAN driver 4.100.15.5 doesn't work wi o kern/110959 net Filtering incoming packets with enc0 does not work wit 7 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net bridge interface given in rc.conf not taking an (stati o kern/110720 net [net] [patch] support for interface descriptions 11 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 11:59:46 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56C8816A46B for ; Mon, 16 Apr 2007 11:59:46 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9465C13C4C5 for ; Mon, 16 Apr 2007 11:59:45 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.181.183] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1HdPrj3Jtb-0007O4; Mon, 16 Apr 2007 13:59:30 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Mon, 16 Apr 2007 13:59:19 +0200 User-Agent: KMail/1.9.5 References: <46226AD3.3030806@webmail.sub.ru> In-Reply-To: <46226AD3.3030806@webmail.sub.ru> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4045303.TY0IIbxdmX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704161359.26059.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19w6CoSj8reHkMPeI1M10C9iNUdGsPKn32EDxe vmH3pQBqU7242NxFgjlqTZD6RjK6M0+7DE7NNFa5Q8ZQvwqpFp ZS4H5GYGL5bXHrNOBdpwg== Cc: Alex Povolotsky Subject: Re: Please help with PF-based redirector X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 11:59:46 -0000 --nextPart4045303.TY0IIbxdmX Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 15 April 2007 20:11, Alex Povolotsky wrote: > Hello! > > I'm trying to set up a box as round-robin TCP proxy. Of course, I'm > trying to do everything on kernel-level. > > This simple setup > > rdr on sk0 proto tcp from any to any port =3D smtp -> port 25 > round-robin > > should work. At least, I thought so. > > However, attempt to connect to port 25 yielded unexpected result. pfctl > -s state shows > > self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- > 89.108.94.211:56975 CLOSED:SYN_SENT Your test hosts seem to be on the same subnet. This does not work as you=20 seems to think. In the same broadcast domain it is not possible for the=20 pf box to forward the packet on behalf of the sending host (otherwise it=20 would confuse the recipient or the switch). Instead it emits icmp=20 redirects which are ignored in a normal setup. You have to separate the two networks in order for redirect to work the=20 way you want it to. > connection never established, and no IP packet ever sends out to > 89.108.94.212:25 > > I don't understand this thing. Maybe someone can point me to my error? > > (firewall rules a quite permissive, in fact, they are pass in quick and > pass out quick for all interfaces. attempt to telnet to port 25 outside > works ok) > > Alex. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart4045303.TY0IIbxdmX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGI2UeXyyEoT62BG0RAnwlAJ9vf0jNz19zi6dwT3IWxyglhad2BgCePRUr o946s6tMfZLMTF+iZQHvAiw= =VBRM -----END PGP SIGNATURE----- --nextPart4045303.TY0IIbxdmX-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 12:04:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B136016A400 for ; Mon, 16 Apr 2007 12:04:36 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 7E5B913C487 for ; Mon, 16 Apr 2007 12:04:35 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 32157 invoked from network); 16 Apr 2007 16:09:54 +0400 Received: from unknown (HELO localhost) (88.212.205.2) by mail.sub.ru with SMTP; 16 Apr 2007 16:09:54 +0400 X-Virus-Scanned: by amavisd-new at mail.sub.ru Received: from unknown ([88.212.205.2]) by localhost (mail-new.sub.ru [88.212.205.2]) (amavisd-new, port 10024) with SMTP id IkhZ0ngjzxOi; Mon, 16 Apr 2007 16:09:51 +0400 (MSD) Received: from unknown (HELO ?192.168.139.47?) (tarkhil%sub.ru@192.168.139.47) by techno.sub.ru with SMTP; 16 Apr 2007 12:09:50 -0000 Message-ID: <46236649.7000406@webmail.sub.ru> Date: Mon, 16 Apr 2007 16:04:25 +0400 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Max Laier References: <46226AD3.3030806@webmail.sub.ru> <200704161359.26059.max@love2party.net> In-Reply-To: <200704161359.26059.max@love2party.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Please help with PF-based redirector X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 12:04:36 -0000 Max Laier wrote: > On Sunday 15 April 2007 20:11, Alex Povolotsky wrote: > >> Hello! >> >> I'm trying to set up a box as round-robin TCP proxy. Of course, I'm >> trying to do everything on kernel-level. >> >> This simple setup >> >> rdr on sk0 proto tcp from any to any port = smtp -> port 25 >> round-robin >> >> should work. At least, I thought so. >> >> However, attempt to connect to port 25 yielded unexpected result. pfctl >> -s state shows >> >> self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- >> 89.108.94.211:56975 CLOSED:SYN_SENT >> > > Your test hosts seem to be on the same subnet. This does not work as you > seems to think. In the same broadcast domain it is not possible for the > pf box to forward the packet on behalf of the sending host (otherwise it > would confuse the recipient or the switch). Instead it emits icmp > redirects which are ignored in a normal setup. > > You have to separate the two networks in order for redirect to work the > way you want it to. > Okay, thanks a lot, I'll give a try Alex. From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 13:44:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1833516A420 for ; Mon, 16 Apr 2007 13:44:05 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE2113C45B for ; Mon, 16 Apr 2007 13:44:04 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l3GDqe3f027179; Mon, 16 Apr 2007 15:52:40 +0200 (MEST) Message-ID: <46237DA0.6060002@fer.hr> Date: Mon, 16 Apr 2007 15:44:00 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.10 (X11/20060911) MIME-Version: 1.0 To: Luigi Rizzo References: <20070415144922.A39338@xorpc.icir.org> <20070415150050.C39338@xorpc.icir.org> In-Reply-To: <20070415150050.C39338@xorpc.icir.org> X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigECDAF43EE64387902E0D0E1C" Cc: freebsd-net@freebsd.org Subject: Re: ipfw, keep-state and limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 13:44:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigECDAF43EE64387902E0D0E1C Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Luigi Rizzo wrote: >>> if i remember well (the implementation dates back to 2001 or so) >>> you just need to use "limit", as it implicitly installs >>> a dynamic state entry (same as keep-state). My new rule is: 06079 376036 286721568 allow tcp from any to me dst-port 80 setup=20 limit src-addr 15 And now ipfw -d show displays (among others): 06079 0 0 (0s) PARENT 2 tcp xx.53.98.13 0 <-> 0.0.0.0 = 0 06079 0 0 (0s) PARENT 1 tcp xx.29.147.17 0 <-> 0.0.0.0= 0 06079 0 0 (0s) PARENT 5 tcp xx.29.242.18 0 <-> 0.0.0.0= 0 06079 0 0 (0s) PARENT 0 tcp xx.53.68.19 0 <-> 0.0.0.0 = 0 06079 0 0 (0s) PARENT 1 tcp xx.53.18.22 0 <-> 0.0.0.0 = 0 06079 0 0 (8s) PARENT 1 tcp xx.55.213.39 0 <-> 0.0.0.0= 0 06079 0 0 (6s) PARENT 1 tcp xx.53.76.41 0 <-> 0.0.0.0 = 0 06079 0 0 (0s) PARENT 0 tcp xx.164.34.41 0 <-> 0.0.0.0= 0 I assume 0s in this case is good, and "PARENT n" means n connections=20 from the client? I've also got some dynamic rules referencing LIMIT on the same rule #: 06079 1471 1211349 (300s) LIMIT tcp xx.198.150.143 1507 <->=20 my.ip.ad.dr 80 06079 1243 988046 (300s) LIMIT tcp xx.198.150.143 1508 <->=20 my.ip.ad.dr 80 06079 25 15740 (299s) LIMIT tcp xx.53.74.51 1368 <->=20 my.ip.ad.dr 80 06079 7 1392 (223s) LIMIT tcp xx.254.251.10 3168 <->=20 my.ip.ad.dr 80 These are the individual connections, right? --------------enigECDAF43EE64387902E0D0E1C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGI32gldnAQVacBcgRAv8nAKCoDp30/eS+BA/GFYSfbZoCd+J1oACg1zf3 IM92K315AsQo2G4V9tx0j/w= =hrmA -----END PGP SIGNATURE----- --------------enigECDAF43EE64387902E0D0E1C-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 15:37:44 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61A3216A420 for ; Mon, 16 Apr 2007 15:37:44 +0000 (UTC) (envelope-from ywxwf@psor.cod.ee) Received: from pool-71-124-183-49.bstnma.east.verizon.net (pool-71-124-183-49.bstnma.east.verizon.net [71.124.183.49]) by mx1.freebsd.org (Postfix) with SMTP id D5A2A13C489 for ; Mon, 16 Apr 2007 15:37:43 +0000 (UTC) (envelope-from ywxwf@psor.cod.ee) Received: from ae.cjii ([31.183.220.173]) by pool-71-124-183-49.bstnma.east.verizon.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Apr 2007 11:37:15 -0400 Message-ID: <001b01c7803d$1c3627a0$addcb71f@ae.cjii> From: "Psor.Cod.Ee" To: Date: Mon, 16 Apr 2007 11:37:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Psoriasis - the most dangerous illness of 21 century! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 15:37:44 -0000 Visit our site, we have advises about Psoriasis, Forum for russianspeaking patients. http://psor.cod.ee/ This is not a Spam. We take your email adress from open source! From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 15:45:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BD3A16A400 for ; Mon, 16 Apr 2007 15:45:51 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6C313C45E for ; Mon, 16 Apr 2007 15:45:51 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l3GFjmVw058676; Mon, 16 Apr 2007 08:45:48 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l3GFjmEa058675; Mon, 16 Apr 2007 08:45:48 -0700 (PDT) (envelope-from rizzo) Date: Mon, 16 Apr 2007 08:45:48 -0700 From: Luigi Rizzo To: Ivan Voras Message-ID: <20070416084548.A58565@xorpc.icir.org> References: <20070415144922.A39338@xorpc.icir.org> <20070415150050.C39338@xorpc.icir.org> <46237DA0.6060002@fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <46237DA0.6060002@fer.hr>; from ivoras@fer.hr on Mon, Apr 16, 2007 at 03:44:00PM +0200 Cc: freebsd-net@freebsd.org Subject: Re: ipfw, keep-state and limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 15:45:51 -0000 On Mon, Apr 16, 2007 at 03:44:00PM +0200, Ivan Voras wrote: > Luigi Rizzo wrote: > >>> if i remember well (the implementation dates back to 2001 or so) > >>> you just need to use "limit", as it implicitly installs > >>> a dynamic state entry (same as keep-state). > > My new rule is: > 06079 376036 286721568 allow tcp from any to me dst-port 80 setup > limit src-addr 15 > > And now ipfw -d show displays (among others): > > 06079 0 0 (0s) PARENT 2 tcp xx.53.98.13 0 <-> 0.0.0.0 0 > 06079 0 0 (0s) PARENT 1 tcp xx.29.147.17 0 <-> 0.0.0.0 0 > 06079 0 0 (0s) PARENT 5 tcp xx.29.242.18 0 <-> 0.0.0.0 0 > 06079 0 0 (0s) PARENT 0 tcp xx.53.68.19 0 <-> 0.0.0.0 0 > 06079 0 0 (0s) PARENT 1 tcp xx.53.18.22 0 <-> 0.0.0.0 0 > 06079 0 0 (8s) PARENT 1 tcp xx.55.213.39 0 <-> 0.0.0.0 0 > 06079 0 0 (6s) PARENT 1 tcp xx.53.76.41 0 <-> 0.0.0.0 0 > 06079 0 0 (0s) PARENT 0 tcp xx.164.34.41 0 <-> 0.0.0.0 0 > > I assume 0s in this case is good, and "PARENT n" means n connections > from the client? you have to look at the source code because it has been a few years since i implemented them, but i believe the PARENT lines (which have 0's in the counters and unused fields) are the summary for the individual clients, and the individual entries are the 'LIMIT' rules below. I am not sure why there is a non-zero timeout in some of the parent rules cheers luigi > I've also got some dynamic rules referencing LIMIT on the same rule #: > 06079 1471 1211349 (300s) LIMIT tcp xx.198.150.143 1507 <-> > my.ip.ad.dr 80 > 06079 1243 988046 (300s) LIMIT tcp xx.198.150.143 1508 <-> > my.ip.ad.dr 80 > 06079 25 15740 (299s) LIMIT tcp xx.53.74.51 1368 <-> > my.ip.ad.dr 80 > 06079 7 1392 (223s) LIMIT tcp xx.254.251.10 3168 <-> > my.ip.ad.dr 80 > > These are the individual connections, right? > From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 16:05:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA39B16A406 for ; Mon, 16 Apr 2007 16:05:16 +0000 (UTC) (envelope-from desenvolvimento@dosaq.com.br) Received: from srvns1.netabc.com.br (web.netabc.com.br [200.245.88.28]) by mx1.freebsd.org (Postfix) with ESMTP id 63FEA13C4AD for ; Mon, 16 Apr 2007 16:05:15 +0000 (UTC) (envelope-from desenvolvimento@dosaq.com.br) Received: from projetos (201-27-186-122.dsl.telesp.net.br [201.27.186.122]) by srvns1.netabc.com.br (Vircom SMTPRS 4.35.480.0) with SMTP id for ; Mon, 16 Apr 2007 12:56:10 -0300 X-Modus-ReverseDNS: OK X-Modus-BlackList: 201.27.186.122=OK;desenvolvimento@dosaq.com.br=OK X-Modus-RBL: 201.27.186.122=OK X-Modus-Trusted: 201.27.186.122=NO From: MarcelCabral To: freebsd-net@freebsd.org Sender: MarcelCabral Date: Mon, 16 Apr 2007 15:53:41 GMT Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-AntiAbuse: Priority: Normal X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 Message-Id: <20070416160515.63FEA13C4AD@mx1.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Dosaq Noticias - X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 16:05:17 -0000 Caso n=E3o consiga visualizar as imagens, favor click na bar= ra acima deste texto de cor cinza para liberar as imagens. Caros clientes e amigos da Dosaq, estamos disponibi= lizando a apresenta=E7=E3o de nossa empresa e produtos. Agradecemos desde j=E1= pela aten=E7=E3o, e estamos a sua total disposi=E7=E3o para futuros esclarecimentos. Att. MarcelCabral Sup. Vendas 011-69466642 = Acesse nosso site [1]www.dosaq.com.br [2]vendas@dosaq.com.br Dosaq - = Bombas Dosadoras Rua Imoroti 113 - S.Jo=E3o Cl=EDmaco.-Sp. 3D"" [news.gif"] [projetos_p.jpg=] =95 Renascimento d= o Projeto Billings Pe=E7o licen=E7a para chamar a a= ten=E7=E3o das autoridades do Estado de S=E3o Paulo, dos colegas eng= enheiros, dos ambientalistas e da popula=E7=E3o que temos que f= echar urgentemente as comportas da entrada do t=FAnel n=BA = 7 da represa de Joan=F3polis do Sistema Cantareira. [3][vejamais.gif"] <= /TR> ...........................................= ...................................... [dicas.gif"] Devido ao grande volume de manuten= =E7=E3o dos equipamentos, realizada no final do ano, solicitada por nos= sos clientes, nosso estoque de pe=E7as de reposi=E7=E3o fica li= mitado, sugerimos que fa=E7am a reposi=E7=E3o de pe=E7as do Kit pre= ventivo de manuten=E7=E3o. ...........................................= ...................................... [sugestao.gif"] = =95 Sugerimos aos nossos clientes = que mantenham em seu almoxarifado um Kit preventivo para manuten=E7=E3o:&= nbsp; 2 bico de recalque 2 bico de suc=E7=E3o&n= bsp; 2 diafragma 2 v=E1lvulas de reten=E7=E3o 2 v=E1= lvula p=E9 de crivo [maquinas2.gif"] Fa=E7= a seu or=E7amento on-line! [4][form.gif"] DOSAQ E-mailing =E9 um servi=E7o = gratuito da Dosa= q - Ind=FAstria e com=E9rcio de bombas Ltda. Caso voc= =EA n=E3o queira continuar recebendo, responda este e-mail com a palavra EXCLUIR. um produto [5]Net ABC Internet ........................................................= .................................... References Visible links 1. 3D"http://www.dosaq.com.br/" 2. 3D"mailto:vendas@dosaq.com.br" 3. 3D"http://www.uniagua.org.br/website/default.asp= 4. 3D"http://www.dosaq.com.br/compra.asp" 5. 3D"http://www.netabc.com.br/index.asp= Hidden links: 6. 3D"http://www.uniagua.org.br/website/default.asp" 7. 3D"http://www.uniagua.org.br/website/default.asp= From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 16:06:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 138D216A406 for ; Mon, 16 Apr 2007 16:06:10 +0000 (UTC) (envelope-from cwdwe@psor.cod.ee) Received: from ppp91-122-12-8.pppoe.avangard-dsl.ru (ppp91-122-12-8.pppoe.avangard-dsl.ru [91.122.12.8]) by mx1.freebsd.org (Postfix) with SMTP id 1E1BE13C4BA for ; Mon, 16 Apr 2007 16:06:08 +0000 (UTC) (envelope-from cwdwe@psor.cod.ee) Received: from djajk.xtvk ([126.104.209.137]) by ppp91-122-12-8.pppoe.avangard-dsl.ru with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 20:06:38 +0400 Message-ID: <000e01c78041$37082a20$89d1687e@djajk.xtvk> From: "Psor.Cod.Ee" To: Date: Mon, 16 Apr 2007 20:06:38 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Psoriasis - the most dangerous illness of 21 century! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 16:06:10 -0000 Visit our site, we have advises about Psoriasis, Forum for russianspeaking patients. http://psor.cod.ee/ This is not a Spam. We take your email adress from open source! From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 16:24:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC12616A484 for ; Mon, 16 Apr 2007 16:24:52 +0000 (UTC) (envelope-from uxb@psor.cod.ee) Received: from p5086E32F.dip.t-dialin.net (p5086E32F.dip.t-dialin.net [80.134.227.47]) by mx1.freebsd.org (Postfix) with SMTP id 086FE13C4B9 for ; Mon, 16 Apr 2007 16:24:51 +0000 (UTC) (envelope-from uxb@psor.cod.ee) Received: from oxrtb.blj ([52.101.142.172]) by p5086E32F.dip.t-dialin.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Apr 2007 18:24:50 +0200 Message-ID: <000e01c78043$c20d8aa0$ac8e6534@oxrtb.blj> From: "Psor.Cod.Ee" To: Date: Mon, 16 Apr 2007 18:24:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 Subject: Psoriasis - the most dangerous illness of 21 century! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 16:24:52 -0000 Visit our site, we have advises about Psoriasis, Forum for russianspeaking patients. http://psor.cod.ee/ This is not a Spam. We take your email adress from open source! From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 16:33:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 529AB16A400 for ; Mon, 16 Apr 2007 16:33:12 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.t-com.hr (ls405.t-com.hr [195.29.150.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0971013C46A for ; Mon, 16 Apr 2007 16:33:11 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls248.t-com.hr (ls248.t-com.hr [195.29.150.237]) by ls405.t-com.hr (Postfix) with ESMTP id 7EF60145022; Mon, 16 Apr 2007 18:33:10 +0200 (CEST) Received: from ls248.t-com.hr (ls248.t-com.hr [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id 7A4D9D5004A; Mon, 16 Apr 2007 18:33:10 +0200 (CEST) Received: from ls248.t-com.hr (ls248.t-com.hr [127.0.0.1]) by ls248.t-com.hr (Qmlai) with ESMTP id 5EFDCD50047; Mon, 16 Apr 2007 18:33:10 +0200 (CEST) X-Envelope-Sender-Info: g5URFa92gX9K/Rg9VFA/rFyI1zZMlCwAswXg57+GjGo6StkSH1j7CT0zJW9WjWDV X-Envelope-Sender: ivoras@fer.hr Received: from [10.0.0.100] (83-131-108-33.adsl.net.t-com.hr [83.131.108.33]) by ls248.t-com.hr (Qmali) with ESMTP id 0EB185E011A; Mon, 16 Apr 2007 18:33:09 +0200 (CEST) Message-ID: <4623A539.4080600@fer.hr> Date: Mon, 16 Apr 2007 18:32:57 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Luigi Rizzo References: <20070415144922.A39338@xorpc.icir.org> <20070415150050.C39338@xorpc.icir.org> <46237DA0.6060002@fer.hr> <20070416084548.A58565@xorpc.icir.org> In-Reply-To: <20070416084548.A58565@xorpc.icir.org> X-Enigmail-Version: 0.94.3.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0807E3B53C23AB45115251FE" Cc: freebsd-net@freebsd.org Subject: Re: ipfw, keep-state and limit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 16:33:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0807E3B53C23AB45115251FE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Luigi Rizzo wrote: > you have to look at the source code because it has been a few years > since i implemented them, but i believe the PARENT lines (which have > 0's in the counters and unused fields) are the summary for the individu= al > clients, and the individual entries are the 'LIMIT' rules below. > I am not sure why there is a non-zero timeout in some of the parent > rules Judging from the lack of documentation and your memory it seems like I'm the only using this features ;) --------------enig0807E3B53C23AB45115251FE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGI6U/ldnAQVacBcgRAvCLAKC1vmQkLMIYq8E+nbmHb7cKkD10agCgz+PY gh8iZrVm4VEl+o7gkBZja7o= =lICS -----END PGP SIGNATURE----- --------------enig0807E3B53C23AB45115251FE-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 17:02:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D86916A401 for ; Mon, 16 Apr 2007 17:02:54 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id BC8CD13C487 for ; Mon, 16 Apr 2007 17:02:53 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 50968 invoked from network); 16 Apr 2007 21:08:14 +0400 Received: from unknown (HELO localhost) (88.212.205.2) by mail.sub.ru with SMTP; 16 Apr 2007 21:08:14 +0400 X-Virus-Scanned: by amavisd-new at mail.sub.ru Received: from unknown ([88.212.205.2]) by localhost (mail-new.sub.ru [88.212.205.2]) (amavisd-new, port 10024) with SMTP id S2SJm51Aji-M; Mon, 16 Apr 2007 21:08:10 +0400 (MSD) Received: from unknown (HELO ?192.168.139.47?) (tarkhil%sub.ru@192.168.139.47) by techno.sub.ru with SMTP; 16 Apr 2007 17:08:10 -0000 Message-ID: <4623AC35.7060301@webmail.sub.ru> Date: Mon, 16 Apr 2007 21:02:45 +0400 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Max Laier References: <46226AD3.3030806@webmail.sub.ru> <200704161359.26059.max@love2party.net> In-Reply-To: <200704161359.26059.max@love2party.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Please help with PF-based redirector X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 17:02:54 -0000 Max Laier wrote: > On Sunday 15 April 2007 20:11, Alex Povolotsky wrote: > >> Hello! >> >> I'm trying to set up a box as round-robin TCP proxy. Of course, I'm >> trying to do everything on kernel-level. >> >> This simple setup >> >> rdr on sk0 proto tcp from any to any port = smtp -> port 25 >> round-robin >> >> should work. At least, I thought so. >> >> However, attempt to connect to port 25 yielded unexpected result. pfctl >> -s state shows >> >> self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- >> 89.108.94.211:56975 CLOSED:SYN_SENT >> > > Your test hosts seem to be on the same subnet. This does not work as you > seems to think. In the same broadcast domain it is not possible for the > pf box to forward the packet on behalf of the sending host (otherwise it > would confuse the recipient or the switch). Instead it emits icmp > redirects which are ignored in a normal setup. > > You have to separate the two networks in order for redirect to work the > way you want it to. > I have separated them. #pfctl -s nat rdr on rl0 proto tcp from any to any port = smtp -> port 25 round-robin # pfctl -s state No ALTQ support in kernel ALTQ related functions disabled self tcp 89.108.94.212:25 <- 10.180.210.2:25 <- 10.180.210.1:61298 CLOSED:SYN_SENT tcpdump does not show any ICMP redirect unknown-1717# tcpdump -l -n -i rl0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on rl0, link-type EN10MB (Ethernet), capture size 96 bytes 20:53:14.907833 arp who-has 10.180.210.2 tell 10.180.210.1 20:53:14.907857 arp reply 10.180.210.2 is-at 00:0e:2e:98:7e:55 20:53:14.907924 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 20:53:17.907599 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 20:53:21.107441 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 20:53:24.307283 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 20:53:27.507126 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 20:53:30.706974 IP 10.180.210.1.57528 > 10.180.210.2.25: S 3593018807:3593018807(0) win 65535 ^C 8 packets captured 8 packets received by filter 0 packets dropped by kernel What am I doing wrong? Or I can only redirect routable traffic? Nope, I've added alias to "external" interface, no changes Alex From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 17:21:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E185C16A403; Mon, 16 Apr 2007 17:21:05 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog12.obsmtp.com (s200aog12.obsmtp.com [207.126.144.126]) by mx1.freebsd.org (Postfix) with SMTP id 0BA7013C43E; Mon, 16 Apr 2007 17:20:50 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob012.postini.com ([207.126.147.11]) with SMTP; Mon, 16 Apr 2007 17:20:49 UTC Received: from [10.0.0.89] (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 9996F18142F; Mon, 16 Apr 2007 18:20:49 +0100 (BST) Message-ID: <4623B0A2.5020006@tomjudge.com> Date: Mon, 16 Apr 2007 18:21:38 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: freebsd-net@freebsd.org, FreeBSD Stable List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Possible mtu bug in vlan or bce X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 17:21:06 -0000 Hi, I have seen some strange behaviour today with VLAN interfaces on bce interfaces. I am running 6.2 Release on i386. I have a bce interface setup on a gig-e network with an MTU of 8192 i attach a vlan interface to this and chnage the vlan if mtu to 1500 as it has 100Mbit devices on it. This does not seem to affect the MTU of the bce interface, the VLAN mtu is reported as changed by if config but the bce is not reported as changed. However I then start to get error messages saying that the NFS server is not responding as it is sending packets larger than 1500 bytes. If I try to raise the mtu of the vlan interface (to 8192 which is the value that ifconfig reports for bce0) at this stage ifconfig thows an error saying that the value is incorrect. If I then 'raise' (it already appears to be set to 8192 according to ifconfig) the mtu of bce0 to 8192 and then set the vlan interface mtu to 8192 the nfs server starts to work again. Is this a know bug/problem or should I raise a PR? Thanks Tom From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 18:39:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 626FD16A400 for ; Mon, 16 Apr 2007 18:39:03 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (mx1.ethionet.et [213.55.64.53]) by mx1.freebsd.org (Postfix) with ESMTP id 664E513C484 for ; Mon, 16 Apr 2007 18:39:02 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (localhost [127.0.0.1]) by localhost.ethionet.et (Postfix) with ESMTP id CEADA4FF8 for ; Mon, 16 Apr 2007 21:35:15 +0300 (EAT) Received: from rogue.navcom.lan (unknown [213.55.65.54])by mx1.ethionet.et ( Postfix) with SMTP id 3436350D9for ; Mon, 16 Apr 2 007 21:35:04 +0300 (EAT) Received: by rogue.navcom.lan (Postfix, from userid 1001)id 32E5D1BC1; Mon, 16 Apr 2007 13:16:09 +0300 (EAT) Date: Mon, 16 Apr 2007 13:16:09 +0300 From: Mike Makonnen To: freebsd-net@freebsd.org Message-ID: <20070416101609.GA2137@rogue.navcom.lan> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD/7.0-CURRENT (i386) X-imss-version: 2.46 X-imss-result: Passed X-imss-scores: Clean:24.87412 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:4 C:3 M:3 S:4 R:3 (1.0000 1.0000) Subject: ping6 extension headers bounds checking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 18:39:03 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello folks, Please review the attached patch for ping6(8) to fix PR kern/99425 You can attach extra headers to the ping6 packet by specifying, for example, extra routing information. This information is sent as control data with sendmsg(2) and when you get a reply is received as control data from recvmsg(2). In a nutshell, there are 2 problems: 1. The buffer supplied to recvmsg(2) to hold control (ancillary) data is, in some cases, too small to hold all the extra headers. 2. In verbose mode, when printing out the control data, it doesn't check to make sure that the stated length of the headers is within the bounds of the buffer. To address this I increased the buffer supplied to recvmsg(2) to the minimum required by rfc 3542 (10420 bytes) and I modified the functions that print the extra header information to print a warning if the buffer is too small and to print only as much information as contained in the buffer. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mmakonnen @ gmail.com | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm @ FreeBSD.Org | FreeBSD - http://www.freebsd.org --n8g4imXOkfNTN/H1 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ping6.diff" Index: sbin/ping6/ping6.c =================================================================== RCS file: /home/ncvs/src/sbin/ping6/ping6.c,v retrieving revision 1.29 diff -u -u -r1.29 ping6.c --- sbin/ping6/ping6.c 10 Feb 2005 09:19:32 -0000 1.29 +++ sbin/ping6/ping6.c 5 Apr 2007 22:32:52 -0000 @@ -150,6 +150,7 @@ #define ICMP6ECHOLEN 8 /* icmp echo header len excluding time */ #define ICMP6ECHOTMLEN sizeof(struct tv32) #define ICMP6_NIQLEN (ICMP6ECHOLEN + 8) +# define CONTROLLEN 10240 /* ancillary data buffer size RFC3542 20.1 */ /* FQDN case, 64 bits of nonce + 32 bits ttl */ #define ICMP6_NIRLEN (ICMP6ECHOLEN + 12) #define EXTRA 256 /* for AH and various other headers. weird. */ @@ -269,8 +270,8 @@ char *, size_t); void pr_pack(u_char *, int, struct msghdr *); void pr_exthdrs(struct msghdr *); -void pr_ip6opt(void *); -void pr_rthdr(void *); +void pr_ip6opt(void *, unsigned int); +void pr_rthdr(void *, unsigned int); int pr_bitrange(u_int32_t, int, int); void pr_retip(struct ip6_hdr *, u_char *); void summary(void); @@ -307,6 +308,7 @@ char *e, *target, *ifname = NULL, *gateway = NULL; int ip6optlen = 0; struct cmsghdr *scmsgp = NULL; + struct cmsghdr *cm; #if defined(SO_SNDBUF) && defined(SO_RCVBUF) u_long lsockbufsize; int sockbufsize = 0; @@ -1057,10 +1059,13 @@ seeninfo = 0; #endif + /* For control (ancillary) data received from recvmsg() */ + cm = (struct cmsghdr *)malloc(CONTROLLEN); + if (cm == NULL) + err(1, "malloc"); + for (;;) { struct msghdr m; - struct cmsghdr *cm; - u_char buf[1024]; struct iovec iov[2]; /* signal handling */ @@ -1127,9 +1132,9 @@ iov[0].iov_len = packlen; m.msg_iov = iov; m.msg_iovlen = 1; - cm = (struct cmsghdr *)buf; - m.msg_control = (caddr_t)buf; - m.msg_controllen = sizeof(buf); + memset(cm, 0, CONTROLLEN); + m.msg_control = (void *)cm; + m.msg_controllen = CONTROLLEN; cc = recvmsg(s, &m, 0); if (cc < 0) { @@ -1493,6 +1498,9 @@ pr_addr(from, fromlen)); return; } + if (((mhdr->msg_flags & MSG_CTRUNC) != 0) && + (options & F_VERBOSE) != 0) + warnx("some control data discarded, insufficient buffer size"); icp = (struct icmp6_hdr *)buf; ni = (struct icmp6_nodeinfo *)buf; off = 0; @@ -1735,28 +1743,31 @@ pr_exthdrs(mhdr) struct msghdr *mhdr; { - struct cmsghdr *cm; + struct cmsghdr *cm, *cm1; + unsigned int offset; - for (cm = (struct cmsghdr *)CMSG_FIRSTHDR(mhdr); cm; - cm = (struct cmsghdr *)CMSG_NXTHDR(mhdr, cm)) { + offset = 0; + cm1 = (struct cmsghdr *)CMSG_FIRSTHDR(mhdr); + for (cm = cm1; cm; cm = (struct cmsghdr *)CMSG_NXTHDR(mhdr, cm)) { if (cm->cmsg_level != IPPROTO_IPV6) continue; + offset = (caddr_t)CMSG_DATA(cm) - (caddr_t)cm1; switch (cm->cmsg_type) { case IPV6_HOPOPTS: printf(" HbH Options: "); - pr_ip6opt(CMSG_DATA(cm)); + pr_ip6opt(CMSG_DATA(cm), offset); break; case IPV6_DSTOPTS: #ifdef IPV6_RTHDRDSTOPTS case IPV6_RTHDRDSTOPTS: #endif printf(" Dst Options: "); - pr_ip6opt(CMSG_DATA(cm)); + pr_ip6opt(CMSG_DATA(cm), offset); break; case IPV6_RTHDR: printf(" Routing: "); - pr_rthdr(CMSG_DATA(cm)); + pr_rthdr(CMSG_DATA(cm), offset); break; } } @@ -1764,12 +1775,12 @@ #ifdef USE_RFC2292BIS void -pr_ip6opt(void *extbuf) +pr_ip6opt(void *extbuf, unsigned int cmoffset) { struct ip6_hbh *ext; int currentlen; u_int8_t type; - socklen_t extlen, len; + socklen_t extlen, len, origextlen; void *databuf; size_t offset; u_int16_t value2; @@ -1780,6 +1791,21 @@ printf("nxt %u, len %u (%lu bytes)\n", ext->ip6h_nxt, (unsigned int)ext->ip6h_len, (unsigned long)extlen); + /* + * Bounds checking on the ancillary data buffer. When calculating + * the number of items to show keep in mind: + * - The offset, in the ancillary data buffer, of this header + * - The size of the cmsg structure + * - The size of one unit (8 octets) + */ + if (CONTROLLEN < (extlen + CMSG_SPACE(0) + offset)) { + origextlen = extlen; + extlen -= (extlen - (CONTROLLEN - offset - CMSG_SPACE(0))) / 8; + warnx("options truncated, showing only %u (total=%u)", + (unsigned int)(extlen / 8 - 1), + (unsigned int)(ext->ip6h_len)); + } + currentlen = 0; while (1) { currentlen = inet6_opt_next(extbuf, extlen, currentlen, @@ -1816,7 +1842,7 @@ #else /* !USE_RFC2292BIS */ /* ARGSUSED */ void -pr_ip6opt(void *extbuf) +pr_ip6opt(void *extbuf, unsigned int cmoffset __unused) { putchar('\n'); return; @@ -1825,21 +1851,44 @@ #ifdef USE_RFC2292BIS void -pr_rthdr(void *extbuf) +pr_rthdr(void *extbuf, unsigned int offset) { struct in6_addr *in6; char ntopbuf[INET6_ADDRSTRLEN]; struct ip6_rthdr *rh = (struct ip6_rthdr *)extbuf; - int i, segments; + int i, segments, origsegs, rthsize, size0, size1; /* print fixed part of the header */ printf("nxt %u, len %u (%d bytes), type %u, ", rh->ip6r_nxt, rh->ip6r_len, (rh->ip6r_len + 1) << 3, rh->ip6r_type); - if ((segments = inet6_rth_segments(extbuf)) >= 0) + if ((segments = inet6_rth_segments(extbuf)) >= 0) { printf("%d segments, ", segments); - else + printf("%d left\n", rh->ip6r_segleft); + } else { printf("segments unknown, "); - printf("%d left\n", rh->ip6r_segleft); + printf("%d left\n", rh->ip6r_segleft); + return; + } + + /* + * Bounds checking on the ancillary data buffer. When calculating + * the number of items to show keep in mind: + * - The offset, in the ancillary data buffer, of this header + * - The size of the cmsg structure + * - The size of one segment (the size of one IPv6 address) + * - When dividing add a fudge factor of one in case the + * dividend is not evenly divisible by the divisor + */ + rthsize = (rh->ip6r_len + 1) * 8; + if (CONTROLLEN < (rthsize + CMSG_SPACE(0) + offset)) { + origsegs = segments; + size0 = inet6_rth_space(IPV6_RTHDR_TYPE_0, 0); + size1 = inet6_rth_space(IPV6_RTHDR_TYPE_0, 1); + segments -= (rthsize - (CONTROLLEN - offset - CMSG_SPACE(0))) / + (size1 - size0) + 1; + warnx("segments truncated, showing only %d (total=%d)", + segments, origsegs); + } for (i = 0; i < segments; i++) { in6 = inet6_rth_getaddr(extbuf, i); @@ -1860,7 +1909,7 @@ #else /* !USE_RFC2292BIS */ /* ARGSUSED */ void -pr_rthdr(void *extbuf) +pr_rthdr(void *extbuf, unsigned int offset __unused) { putchar('\n'); return; --n8g4imXOkfNTN/H1-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 18:39:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62B6F16A401 for ; Mon, 16 Apr 2007 18:39:03 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (mx1.ethionet.et [213.55.64.53]) by mx1.freebsd.org (Postfix) with ESMTP id 6665613C487 for ; Mon, 16 Apr 2007 18:39:02 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (localhost [127.0.0.1]) by localhost.ethionet.et (Postfix) with ESMTP id C990A4FAB for ; Mon, 16 Apr 2007 21:35:15 +0300 (EAT) Received: from rogue.navcom.lan (unknown [213.55.65.54])by mx1.ethionet.et ( Postfix) with SMTP id 36E2150DCfor ; Mon, 16 Apr 2 007 21:35:04 +0300 (EAT) Received: by rogue.navcom.lan (Postfix, from userid 1001)id 0A4DA108C; Mon, 16 Apr 2007 19:53:30 +0300 (EAT) Date: Mon, 16 Apr 2007 19:53:30 +0300 From: Mike Makonnen To: freebsd-net@freebsd.org Message-ID: <20070416165330.GA1956@rogue.navcom.lan> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=fdj2RfSjLxBAspz7 Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD/7.0-CURRENT (i386) X-imss-version: 2.46 X-imss-result: Passed X-imss-scores: Clean:42.39381 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:4 C:3 M:3 S:4 R:3 (1.0000 1.0000) Subject: inet6_rthdr_* functions fixes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 18:39:03 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi guys, Please take a look at the attached patch. They fix some issues I found while investigating the ping(8) PR (kern/99425). The behaviour of these functions is documented in rfc3542. Here are the details of the patch: 1. CMSG_NXTHDR(mhdr, cmsg) is supposed to dereference cmsg and return the next header in the chain. If cmsg is NULL it should return the first header. Currently if cmsg is NULL it doesn't compile, so I fixed it to return the first header if cmesg is NULL. 2. inet6_rth_(space|init|add) should do basic checking on their input to verify that the number of headers is between 0 and 127 inclusive. The second part of the patch to libc/net/rthdr.c addresses this issue. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mmakonnen @ gmail.com | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm @ FreeBSD.Org | FreeBSD - http://www.freebsd.org --fdj2RfSjLxBAspz7 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="rthdr.diff" Index: lib/libc/net/rthdr.c =================================================================== RCS file: /home/ncvs/src/lib/libc/net/rthdr.c,v retrieving revision 1.8 diff -u -u -r1.8 rthdr.c --- lib/libc/net/rthdr.c 19 Jul 2005 18:13:58 -0000 1.8 +++ lib/libc/net/rthdr.c 15 Apr 2007 19:35:32 -0000 @@ -292,7 +292,9 @@ { switch (type) { case IPV6_RTHDR_TYPE_0: - return (((segments * 2) + 1) << 3); + if ((segments >= 0) && (segments <= 127)) + return (((segments * 2) + 1) << 3); + /* FALLTHROUGH */ default: return (0); /* type not suppported */ } @@ -309,6 +311,9 @@ /* length validation */ if (bp_len < inet6_rth_space(IPV6_RTHDR_TYPE_0, segments)) return (NULL); + /* segment validation */ + if ((segments < 0) || (segments > 127)) + return (NULL); memset(bp, 0, bp_len); rth0 = (struct ip6_rthdr0 *)rth; @@ -334,6 +339,9 @@ switch (rth->ip6r_type) { case IPV6_RTHDR_TYPE_0: rth0 = (struct ip6_rthdr0 *)rth; + /* Don't exceed the number of stated segments */ + if (rth0->ip6r0_segleft == (rth0->ip6r0_len / 2)) + return (-1); nextaddr = (struct in6_addr *)(rth0 + 1) + rth0->ip6r0_segleft; *nextaddr = *addr; rth0->ip6r0_segleft++; Index: sys/sys/socket.h =================================================================== RCS file: /home/ncvs/src/sys/sys/socket.h,v retrieving revision 1.92 diff -u -u -r1.92 socket.h --- sys/sys/socket.h 3 Nov 2006 15:23:16 -0000 1.92 +++ sys/sys/socket.h 15 Apr 2007 14:53:04 -0000 @@ -471,11 +471,13 @@ /* given pointer to struct cmsghdr, return pointer to next cmsghdr */ #define CMSG_NXTHDR(mhdr, cmsg) \ - (((char *)(cmsg) + _ALIGN((cmsg)->cmsg_len) + \ + ((char *)(cmsg) == NULL ? CMSG_FIRSTHDR(mhdr) : \ + ((char *)(cmsg) + _ALIGN(((struct cmsghdr *)(cmsg))->cmsg_len) + \ _ALIGN(sizeof(struct cmsghdr)) > \ (char *)(mhdr)->msg_control + (mhdr)->msg_controllen) ? \ (struct cmsghdr *)0 : \ - (struct cmsghdr *)((char *)(cmsg) + _ALIGN((cmsg)->cmsg_len))) + (struct cmsghdr *)((char *)(cmsg) + \ + _ALIGN(((struct cmsghdr *)(cmsg))->cmsg_len))) /* * RFC 2292 requires to check msg_controllen, in case that the kernel returns --fdj2RfSjLxBAspz7-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 19:29:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42E9316A478 for ; Mon, 16 Apr 2007 19:29:59 +0000 (UTC) (envelope-from steve@freeslacker.net) Received: from mx.newtier.com (mx.newtier.com [66.235.239.10]) by mx1.freebsd.org (Postfix) with ESMTP id A03AF13C508 for ; Mon, 16 Apr 2007 19:29:57 +0000 (UTC) (envelope-from steve@freeslacker.net) Received: from [192.168.0.186] (office.newtier.com [66.235.239.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.newtier.com (Postfix) with ESMTP id 3744E22827 for ; Mon, 16 Apr 2007 11:58:26 -0700 (MST) Message-ID: <4623C7C3.8080305@freeslacker.net> Date: Mon, 16 Apr 2007 12:00:19 -0700 From: Steven Stremciuc User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: carp not setting interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 19:29:59 -0000 Hi, I have a 6.2-RELEASE-p3 machine (supermicro 6010h) on which carp is not working correctly. I have been using carp on other freebsd and openbsd machines without a problem, so I am not sure what is going wrong on this specific machine. The carp interfaces are created but there is no address assigned to them, and no information given about what went wrong. Is there anything I can do to get more info on where the problem lies? The machine is completely default except for enabling carp. > ifconfig fxp0: flags=8843 mtu 1500 options=8 inet 10.1.0.201 netmask 0xffffff00 broadcast 10.1.0.255 ether 00:30:48:11:64:85 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8802 mtu 1500 options=8 ether 00:30:48:11:6f:68 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 carp0: flags=9 mtu 1500 carp1: flags=9 mtu 1500 > cat /etc/rc.conf # -- sysinstall generated deltas -- # Sat Apr 14 13:20:02 2007 # Created: Sat Apr 14 13:20:02 2007 # Enable network daemons for user convenience. # Please make all changes to this file, not to /etc/defaults/rc.conf. # This file now contains just the overrides from /etc/defaults/rc.conf. defaultrouter="10.1.0.1" hostname="xxx.com" cloned_interfaces="carp0 carp1" ifconfig_fxp0="inet 10.1.0.201 netmask 255.255.255.0" ifconfig_carp0="vhid 801 pass xxxxxxxx 10.1.0.101/24" ifconfig_carp1="vhid 802 advskew 100 pass xxxxxxxx 10.1.0.102/24" inetd_enable="NO" keyrate="fast" moused_enable="NO" moused_type="NO" sshd_enable="YES" usbd_enable="YES" ntpd_enable="YES" > sysctl net.inet.carp net.inet.carp.allow: 1 net.inet.carp.preempt: 1 net.inet.carp.log: 1 net.inet.carp.arpbalance: 0 net.inet.carp.suppress_preempt: 0 I would really appreciate any ideas. Thanks, steve From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 19:37:28 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F87A16A401; Mon, 16 Apr 2007 19:37:28 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id F169E13C45B; Mon, 16 Apr 2007 19:37:27 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 5072A1A4D82; Mon, 16 Apr 2007 12:37:41 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6012B513AE; Mon, 16 Apr 2007 15:37:27 -0400 (EDT) Date: Mon, 16 Apr 2007 15:37:27 -0400 From: Kris Kennaway To: current@FreeBSD.org, net@FreeBSD.org Message-ID: <20070416193727.GA66684@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Cc: andre@FreeBSD.org Subject: Page fault in syncache_drop X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 19:37:28 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 8-core amd64, up-to-date CVS sources Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803134b4 stack pointer = 0x10:0xffffffffabe09890 frame pointer = 0x10:0xffffffffabe098a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 37 (irq31: bge0) [thread pid 37 tid 100043 ] Stopped at syncache_drop+0x4: cmpq $0,(%rdi) db> wh Tracing pid 37 tid 100043 td 0xffffff00b9409580 syncache_drop() at syncache_drop+0x4 syncache_add() at syncache_add+0x263 tcp_input() at tcp_input+0x7e0 ip_input() at ip_input+0x69d netisr_dispatch() at netisr_dispatch+0x51 ether_demux() at ether_demux+0x19f ether_input() at ether_input+0x3a8 bge_rxeof() at bge_rxeof+0x3ad bge_intr() at bge_intr+0x11b ithread_execute_handlers() at ithread_execute_handlers+0x15d ithread_loop() at ithread_loop+0x69 fork_exit() at fork_exit+0x93 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffabe09d30, rbp = 0 --- Kris --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGI9B3Wry0BWjoQKURAljXAJ9zQwkC6EWiS/48WFLL0v59yp/o0gCfSk++ TpLPUi/d+hofVtJl4OE8slA= =xNoL -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 20:26:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CCDF16A401 for ; Mon, 16 Apr 2007 20:26:11 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 2F19213C4AE for ; Mon, 16 Apr 2007 20:26:11 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.181.183] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1HdXm53fpY-0007Rw; Mon, 16 Apr 2007 22:26:10 +0200 From: Max Laier Organization: FreeBSD To: Mike Makonnen Date: Mon, 16 Apr 2007 22:25:59 +0200 User-Agent: KMail/1.9.5 References: <20070416101609.GA2137@rogue.navcom.lan> In-Reply-To: <20070416101609.GA2137@rogue.navcom.lan> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6362414.9bXbKn86yi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704162226.08931.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19X259zfdZ9g6aNw6jEFa/8ngyvlI1lCt/iLUI siLqqgyWXoi+7iH8oxU0A2I/Rsu2WfZY6w6639TZhQSCg7dowC C1qUhtjNbOS30Ux/773ew== Cc: freebsd-net@freebsd.org Subject: Re: ping6 extension headers bounds checking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 20:26:11 -0000 --nextPart6362414.9bXbKn86yi Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 16 April 2007 12:16, Mike Makonnen wrote: > Hello folks, > > Please review the attached patch for ping6(8) to fix PR kern/99425 > > You can attach extra headers to the ping6 packet by specifying, for > example, extra routing information. This information is sent as > control data with sendmsg(2) and when you get a reply is received > as control data from recvmsg(2). > > In a nutshell, there are 2 problems: > 1. The buffer supplied to recvmsg(2) to hold control (ancillary) > data is, in some cases, too small to hold all the extra headers. > 2. In verbose mode, when printing out the control data, it doesn't > check to make sure that the stated length of the headers is > within the bounds of the buffer. > > To address this I increased the buffer supplied to recvmsg(2) to the > minimum required by rfc 3542 (10420 bytes) and I modified the > functions that print the extra header information to print a > warning if the buffer is too small and to print only as much > information as contained in the buffer. I think it'd be better to supply the print functions with the rest of the=20 bufferlen instead of an offset. This way only the caller has to know the=20 size of the buffer - btw, do we get a result back i.e. how much buffer=20 was used. In addition you could check if the offset in the for-loop of=20 the caller is within bounds, before even attempting to call further. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart6362414.9bXbKn86yi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGI9vgXyyEoT62BG0RAmj+AJ9ZGpLgiwJxCUV5XIdLK6O2Jc9c5wCeIcEM qJRWRvAG4ca23DcrLnY/93g= =QBzG -----END PGP SIGNATURE----- --nextPart6362414.9bXbKn86yi-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 20:35:43 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 350D816A407 for ; Mon, 16 Apr 2007 20:35:43 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-defer01.adhost.com (mail-defer01.adhost.com [216.211.128.150]) by mx1.freebsd.org (Postfix) with ESMTP id 16BA513C4AD for ; Mon, 16 Apr 2007 20:35:43 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in07.adhost.com (mail-in07.adhost.com [10.211.128.140]) by mail-defer01.adhost.com (Postfix) with ESMTP id 71646EC437 for ; Mon, 16 Apr 2007 13:14:48 -0700 (PDT) (envelope-from mksmith@adhost.com) Received: from ad-exh01.adhost.lan (unknown [216.211.143.69]) by mail-in07.adhost.com (Postfix) with ESMTP id BAF511B506D; Mon, 16 Apr 2007 13:14:47 -0700 (PDT) (envelope-from mksmith@adhost.com) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 16 Apr 2007 13:14:53 -0700 Message-ID: <17838240D9A5544AAA5FF95F8D52031602018047@ad-exh01.adhost.lan> In-Reply-To: <4623C7C3.8080305@freeslacker.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: carp not setting interfaces Thread-Index: AceAXbascqadnoEKSpiBLeoZqj9QXgABW9lg References: <4623C7C3.8080305@freeslacker.net> From: "Michael K. Smith - Adhost" To: "Steven Stremciuc" , Cc: Subject: RE: carp not setting interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 20:35:43 -0000 Hello Steven: Answer (not necessarily the correct one) below. > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Steven Stremciuc > Sent: Monday, April 16, 2007 12:00 PM > To: freebsd-net@freebsd.org > Subject: carp not setting interfaces >=20 > Hi, >=20 > I have a 6.2-RELEASE-p3 machine (supermicro 6010h) on which carp is not > working correctly. I have been using carp on other freebsd and openbsd > machines without a problem, so I am not sure what is going wrong on > this > specific machine. The carp interfaces are created but there is no > address assigned to them, and no information given about what went > wrong. >=20 > Is there anything I can do to get more info on where the problem lies? > The machine is completely default except for enabling carp. >=20 > > ifconfig > fxp0: flags=3D8843 mtu 1500 > options=3D8 > inet 10.1.0.201 netmask 0xffffff00 broadcast 10.1.0.255 > ether 00:30:48:11:64:85 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=3D8802 mtu 1500 > options=3D8 > ether 00:30:48:11:6f:68 > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=3D8049 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > carp0: flags=3D9 mtu 1500 > carp1: flags=3D9 mtu 1500 >=20 > > cat /etc/rc.conf > # -- sysinstall generated deltas -- # Sat Apr 14 13:20:02 2007 > # Created: Sat Apr 14 13:20:02 2007 > # Enable network daemons for user convenience. > # Please make all changes to this file, not to /etc/defaults/rc.conf. > # This file now contains just the overrides from /etc/defaults/rc.conf. > defaultrouter=3D"10.1.0.1" > hostname=3D"xxx.com" > cloned_interfaces=3D"carp0 carp1" > ifconfig_fxp0=3D"inet 10.1.0.201 netmask 255.255.255.0" > ifconfig_carp0=3D"vhid 801 pass xxxxxxxx 10.1.0.101/24" > ifconfig_carp1=3D"vhid 802 advskew 100 pass xxxxxxxx 10.1.0.102/24" Have you tried the following syntax? ifconfig_carp0=3D"inet 10.1.0.101 netmask 255.255.255.0 vhid 801 pass xxxxxx" Regards, Mike From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 21:00:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D6A516A401 for ; Mon, 16 Apr 2007 21:00:12 +0000 (UTC) (envelope-from steve@freeslacker.net) Received: from mx.newtier.com (mx.newtier.com [66.235.239.10]) by mx1.freebsd.org (Postfix) with ESMTP id 57AE013C487 for ; Mon, 16 Apr 2007 21:00:12 +0000 (UTC) (envelope-from steve@freeslacker.net) Received: from [192.168.0.186] (office.newtier.com [66.235.239.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.newtier.com (Postfix) with ESMTP id F255122827; Mon, 16 Apr 2007 14:00:11 -0700 (MST) Message-ID: <4623E44D.4030105@freeslacker.net> Date: Mon, 16 Apr 2007 14:02:05 -0700 From: Steven Stremciuc User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Michael K. Smith - Adhost" References: <4623C7C3.8080305@freeslacker.net> <17838240D9A5544AAA5FF95F8D52031602018047@ad-exh01.adhost.lan> In-Reply-To: <17838240D9A5544AAA5FF95F8D52031602018047@ad-exh01.adhost.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: carp not setting interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 21:00:12 -0000 Hi Mike, > Have you tried the following syntax? > > ifconfig_carp0="inet 10.1.0.101 netmask 255.255.255.0 vhid 801 pass > xxxxxx" > Tried that but no change. Btw, my original syntax works fine on a seperate FreeBSD machine. Thanks for the suggestion. steve From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 21:05:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 404F416A500 for ; Mon, 16 Apr 2007 21:05:18 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id CBB2313C43E for ; Mon, 16 Apr 2007 21:05:17 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.181.183] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1HdYNs1oAO-0003Lf; Mon, 16 Apr 2007 23:05:16 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Mon, 16 Apr 2007 23:04:56 +0200 User-Agent: KMail/1.9.5 References: <4623C7C3.8080305@freeslacker.net> In-Reply-To: <4623C7C3.8080305@freeslacker.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5605183.8r61neipGO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200704162305.11182.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19uq10iaidrdu2UEO3/KialNyMZCtnki4RIn/r mxxsdyrQKrTc90mpVhoY9Ggno9fU/GkiQyw+VpycDSpCuml1Fq 5bKEeXx96IbeYb0U5IutA== Cc: Steven Stremciuc Subject: Re: carp not setting interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 21:05:18 -0000 --nextPart5605183.8r61neipGO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 16 April 2007 21:00, Steven Stremciuc wrote: > Hi, > > I have a 6.2-RELEASE-p3 machine (supermicro 6010h) on which carp is not > working correctly. I have been using carp on other freebsd and openbsd > machines without a problem, so I am not sure what is going wrong on > this specific machine. The carp interfaces are created but there is no > address assigned to them, and no information given about what went > wrong. > > Is there anything I can do to get more info on where the problem lies? > The machine is completely default except for enabling carp. > > > ifconfig > > fxp0: flags=3D8843 mtu 1500 > options=3D8 > inet 10.1.0.201 netmask 0xffffff00 broadcast 10.1.0.255 > ether 00:30:48:11:64:85 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=3D8802 mtu 1500 > options=3D8 > ether 00:30:48:11:6f:68 > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=3D8049 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > carp0: flags=3D9 mtu 1500 > carp1: flags=3D9 mtu 1500 > > > cat /etc/rc.conf > > # -- sysinstall generated deltas -- # Sat Apr 14 13:20:02 2007 > # Created: Sat Apr 14 13:20:02 2007 > # Enable network daemons for user convenience. > # Please make all changes to this file, not to /etc/defaults/rc.conf. > # This file now contains just the overrides from /etc/defaults/rc.conf. > defaultrouter=3D"10.1.0.1" > hostname=3D"xxx.com" > cloned_interfaces=3D"carp0 carp1" > ifconfig_fxp0=3D"inet 10.1.0.201 netmask 255.255.255.0" > ifconfig_carp0=3D"vhid 801 pass xxxxxxxx 10.1.0.101/24" > ifconfig_carp1=3D"vhid 802 advskew 100 pass xxxxxxxx 10.1.0.102/24" > inetd_enable=3D"NO" > keyrate=3D"fast" > moused_enable=3D"NO" > moused_type=3D"NO" > sshd_enable=3D"YES" > usbd_enable=3D"YES" > ntpd_enable=3D"YES" > > > sysctl net.inet.carp > > net.inet.carp.allow: 1 > net.inet.carp.preempt: 1 > net.inet.carp.log: 1 > net.inet.carp.arpbalance: 0 > net.inet.carp.suppress_preempt: 0 > > I would really appreciate any ideas. You didn't say, can you configure the carp interfaces by manual ifconfig? = =20 That would indicate a problem in the netstart/rc.d part. Maybe=20 mergemaster again? =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5605183.8r61neipGO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBGI+UHXyyEoT62BG0RAh63AJ41LQnlpddLtfrk1I3vOQUmL041+ACeKNuG oBbSL4Ffg0d8gQfEaQaXru4= =mqt1 -----END PGP SIGNATURE----- --nextPart5605183.8r61neipGO-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 21:17:21 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3EDA416A400 for ; Mon, 16 Apr 2007 21:17:21 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from smtp807.mail.ird.yahoo.com (smtp807.mail.ird.yahoo.com [217.146.188.67]) by mx1.freebsd.org (Postfix) with SMTP id 97E5E13C448 for ; Mon, 16 Apr 2007 21:17:20 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: (qmail 94576 invoked from network); 16 Apr 2007 21:17:19 -0000 Received: from unknown (HELO ?192.168.1.2?) (thomasjudge@btinternet.com@86.140.150.175 with plain) by smtp807.mail.ird.yahoo.com with SMTP; 16 Apr 2007 21:17:19 -0000 X-YMail-OSG: VNy32usVM1kNAvns6gOwXpsXGL3.VPOT0GP.8okVcfiTMf0rkNjvTSKr3duJvLt.E.WV.pGuEEJb.jxO.Eua4poK4Gw8q.jW1QbgQPy2k6BDQTmegq3kgF9NodSEkBC.shk3 Message-ID: <4623E876.5090407@tomjudge.com> Date: Mon, 16 Apr 2007 22:19:50 +0100 From: Tom Judge User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Carp caching routes to networks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 21:17:21 -0000 Hi, I came across an issue in RELENG_6_2 today where carp seems to be caching the network routes when the device is created. To trigger the problem try the following: ifconfig bce0 10.0.0.150/8 ifconfig carp0 create ifconfig bce0 172.31.23.2/24 ifconfig carp0 172.31.23.1/32 The last line will give an error indicating that it can not assign the address, I cant get the exact error message at the moment as I dont have access to the machine. I was just wondering if this was a known problem or if is should raise a PR? Thanks Tom From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 21:18:03 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADA6516A400 for ; Mon, 16 Apr 2007 21:18:03 +0000 (UTC) (envelope-from steve@freeslacker.net) Received: from mx.newtier.com (mx.newtier.com [66.235.239.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7A41013C46C for ; Mon, 16 Apr 2007 21:18:03 +0000 (UTC) (envelope-from steve@freeslacker.net) Received: from [192.168.0.186] (office.newtier.com [66.235.239.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.newtier.com (Postfix) with ESMTP id 2CFBA2281A; Mon, 16 Apr 2007 14:18:03 -0700 (MST) Message-ID: <4623E87C.50006@freeslacker.net> Date: Mon, 16 Apr 2007 14:19:56 -0700 From: Steven Stremciuc User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Max Laier References: <4623C7C3.8080305@freeslacker.net> <200704162305.11182.max@love2party.net> In-Reply-To: <200704162305.11182.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: carp not setting interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 21:18:03 -0000 Hi Max, > > You didn't say, can you configure the carp interfaces by manual ifconfig? > That would indicate a problem in the netstart/rc.d part. Maybe > mergemaster again? I get an error when trying to configure it manually via ifconfig. I don't know what this means. test# ifconfig carp0 create test# ifconfig fxp0: flags=8843 mtu 1500 options=8 inet 10.1.0.201 netmask 0xffffff00 broadcast 10.1.0.255 ether 00:30:48:11:64:85 media: Ethernet autoselect (100baseTX ) status: active fxp1: flags=8802 mtu 1500 options=8 ether 00:30:48:11:6f:68 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 carp0: flags=8 mtu 1500 and then: test# ifconfig carp0 vhid 801 pass mekmitasdigoat 10.1.0.101/24 ifconfig: SIOCSVH: Invalid argument thanks, steve From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 21:38:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADD1F16A400 for ; Mon, 16 Apr 2007 21:38:11 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in03.adhost.com (mail-in03.adhost.com [216.211.128.143]) by mx1.freebsd.org (Postfix) with ESMTP id 9243313C465 for ; Mon, 16 Apr 2007 21:38:11 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from ad-exh01.adhost.lan (unknown [216.211.143.69]) by mail-in03.adhost.com (Postfix) with ESMTP id 38B292A683C; Mon, 16 Apr 2007 14:38:07 -0700 (PDT) (envelope-from mksmith@adhost.com) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 16 Apr 2007 14:38:13 -0700 Message-ID: <17838240D9A5544AAA5FF95F8D5203160201805B@ad-exh01.adhost.lan> In-Reply-To: <4623E87C.50006@freeslacker.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: carp not setting interfaces Thread-Index: AceAbNAjsOfUD4tETQGneUUjv+4o9wAApDNg References: <4623C7C3.8080305@freeslacker.net><200704162305.11182.max@love2party.net> <4623E87C.50006@freeslacker.net> From: "Michael K. Smith - Adhost" To: "Steven Stremciuc" , "Max Laier" Cc: freebsd-net@freebsd.org Subject: RE: carp not setting interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 21:38:11 -0000 Ahh. See below. > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Steven Stremciuc > Sent: Monday, April 16, 2007 2:20 PM > To: Max Laier > Cc: freebsd-net@freebsd.org > Subject: Re: carp not setting interfaces >=20 > Hi Max, >=20 > > > > You didn't say, can you configure the carp interfaces by manual > ifconfig? > > That would indicate a problem in the netstart/rc.d part. Maybe > > mergemaster again? >=20 > I get an error when trying to configure it manually via ifconfig. I > don't know what this means. >=20 > test# ifconfig carp0 create > test# ifconfig > fxp0: flags=3D8843 mtu 1500 > options=3D8 > inet 10.1.0.201 netmask 0xffffff00 broadcast 10.1.0.255 > ether 00:30:48:11:64:85 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=3D8802 mtu 1500 > options=3D8 > ether 00:30:48:11:6f:68 > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=3D8049 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > carp0: flags=3D8 mtu 1500 >=20 > and then: >=20 > test# ifconfig carp0 vhid 801 pass mekmitasdigoat 10.1.0.101/24 > ifconfig: SIOCSVH: Invalid argument >=20 >From 'man ifconfig' - Looks like your vhid must be from 1 to 255, so 801 is probably what's breaking it. The following parameters are specific to carp(4) interfaces: advbase seconds Specifies the base of the advertisement interval in seconds. The acceptable values are 1 to 255. The default value is 1. advskew interval Specifies the skew to add to the base advertisement interval to make one host advertise slower than another host. It is speci- fied in 1/256 of seconds. The acceptable values are 1 to 254. The default value is 0. pass phrase Set the authentication key to phrase. vhid n Set the virtual host ID. This is a required setting. Acceptable values are 1 to 255. Regards, Mike From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 21:49:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20D3B16A403 for ; Mon, 16 Apr 2007 21:49:00 +0000 (UTC) (envelope-from steve@freeslacker.net) Received: from mx.newtier.com (mx.newtier.com [66.235.239.10]) by mx1.freebsd.org (Postfix) with ESMTP id 093D013C458 for ; Mon, 16 Apr 2007 21:48:59 +0000 (UTC) (envelope-from steve@freeslacker.net) Received: from [192.168.0.186] (office.newtier.com [66.235.239.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.newtier.com (Postfix) with ESMTP id 9093C2281A; Mon, 16 Apr 2007 14:48:59 -0700 (MST) Message-ID: <4623EFBC.4080906@freeslacker.net> Date: Mon, 16 Apr 2007 14:50:52 -0700 From: Steven Stremciuc User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Michael K. Smith - Adhost" References: <4623C7C3.8080305@freeslacker.net><200704162305.11182.max@love2party.net> <4623E87C.50006@freeslacker.net> <17838240D9A5544AAA5FF95F8D5203160201805B@ad-exh01.adhost.lan> In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160201805B@ad-exh01.adhost.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-net@freebsd.org Subject: Re: carp not setting interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 21:49:00 -0000 Hi Mike, > > >From 'man ifconfig' - Looks like your vhid must be from 1 to 255, so 801 > is probably what's breaking it. > That was it. Changing the vhid fixes the problem. Thanks so much for that. steve From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 22:18:41 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CDD916A402; Mon, 16 Apr 2007 22:18:41 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.freebsd.org (Postfix) with ESMTP id 1635613C465; Mon, 16 Apr 2007 22:18:41 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (ox2qot40sjjyr9fy@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id l3GLfp3I019928; Mon, 16 Apr 2007 14:41:51 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id l3GLfnmO019927; Mon, 16 Apr 2007 14:41:49 -0700 (PDT) (envelope-from jmg) Date: Mon, 16 Apr 2007 14:41:48 -0700 From: John-Mark Gurney To: Tom Judge Message-ID: <20070416214148.GX73385@funkthat.com> Mail-Followup-To: Tom Judge , freebsd-net@freebsd.org, FreeBSD Stable List References: <4623B0A2.5020006@tomjudge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4623B0A2.5020006@tomjudge.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org, FreeBSD Stable List Subject: Re: Possible mtu bug in vlan or bce X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 22:18:41 -0000 Tom Judge wrote this message on Mon, Apr 16, 2007 at 18:21 +0100: > I have seen some strange behaviour today with VLAN interfaces on bce > interfaces. I am running 6.2 Release on i386. > > I have a bce interface setup on a gig-e network with an MTU of 8192 i > attach a vlan interface to this and chnage the vlan if mtu to 1500 as it > has 100Mbit devices on it. This does not seem to affect the MTU of the > bce interface, the VLAN mtu is reported as changed by if config but the > bce is not reported as changed. However I then start to get error > messages saying that the NFS server is not responding as it is sending > packets larger than 1500 bytes. > > > If I try to raise the mtu of the vlan interface (to 8192 which is the > value that ifconfig reports for bce0) at this stage ifconfig thows an > error saying that the value is incorrect. If I then 'raise' (it already > appears to be set to 8192 according to ifconfig) the mtu of bce0 to 8192 > and then set the vlan interface mtu to 8192 the nfs server starts to > work again. Make sure that you change the host route's mtu down to the new MTU... I changed the MTU behavior a while back so that you could have a mixed network and support both large and regular sized MTU's on the same nextwork... # ifconfig em0 em0: flags=8843 mtu 9000 options=18b inet6 fe80::207:e9ff:fe0d:ad06%em0 prefixlen 64 scopeid 0x2 inet 192.168.0.21 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:07:e9:0d:ad:06 media: Ethernet autoselect (1000baseTX ) status: active # netstat -rnWfinet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Netif Expire default 192.168.0.14 UGS 0 8024 1500 em0 [...] 192.168.0.18 00:c0:f0:42:23:87 UHLW 1 2 1500 em0 1193 # route change 192.168.0.18 -mtu 9000 change host 192.168.0.18 # netstat -rnWfinet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Netif Expire [...] 192.168.0.18 00:c0:f0:42:23:87 UHLW 1 2 9000 em0 1172 # ifconfig em0 mtu 1500 # ifconfig em0 em0: flags=8843 mtu 1500 options=18b inet6 fe80::207:e9ff:fe0d:ad06%em0 prefixlen 64 scopeid 0x2 inet 192.168.0.21 netmask 0xffffff00 broadcast 192.168.0.255 ether 00:07:e9:0d:ad:06 media: Ethernet autoselect (1000baseTX ) status: active # netstat -rnWfinet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Netif Expire [..] 192.168.0.18 00:c0:f0:42:23:87 UHLW 1 2 9000 em0 1128 Hmmm... We may want to add code that detects when the host route's MTU is larger than the interface, and prevent that from happening. Though if an mtu daemon ever gets written, then that should take care of it. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Apr 16 22:53:00 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BBA316A407 for ; Mon, 16 Apr 2007 22:53:00 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from straycat.dhs.org (c-24-63-86-11.hsd1.ma.comcast.net [24.63.86.11]) by mx1.freebsd.org (Postfix) with ESMTP id 50D0B13C44B for ; Mon, 16 Apr 2007 22:52:58 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from [192.168.1.127] (bofh.straycat.dhs.org [192.168.1.127]) by straycat.dhs.org (8.13.8/8.13.8) with ESMTP id l3GMZ5DL007990 for ; Mon, 16 Apr 2007 18:35:05 -0400 (EDT) From: Tom McLaughlin To: freebsd-net@FreeBSD.org Content-Type: text/plain Date: Mon, 16 Apr 2007 18:35:05 -0400 Message-Id: <1176762905.1901.59.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: net/mpd4: Unable to pass pass traffic as pptp client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 22:53:00 -0000 Hi all, I'm trying to use mpd4 to connect my work's Cisco VPN concentrator. After fiddling with mpd.conf I can now get past the connection setup phase and authentication steps. According to the VPN concentrator's logs I have successfully connected but some bit later I am disconnected and the logs show no traffic passed in or out on my connection. While connected I can't ping or reach anything on the work network. After some googling I've found that others have had routing related issues but couldn't find exactly how they were resolved. Can anyone lend me a hand here and point me in the right direction? Below is my mpd.conf along with mpd's console messages along with my routing table. Thanks, tom (Please CC me on replies) mpd.conf: ---- vpn: new -i ng0 vpn vpn set iface disable on-demand set iface idle 0 # disconnect the client after 8 hours set iface session 28800 set iface enable tcpmssfix set auth authname "*****" set auth password "*****" set link yes acfcomp protocomp # If remote machine is NT you need this.. set link enable no-orig-auth set link enable keep-ms-domain set link no pap set link yes chap-msv1 set link mtu 1400 set link mru 1400 set link keep-alive 10 75 set ipcp no vjcomp set ipcp enable req-pri-dns set ipcp enable req-sec-dns set ipcp enable req-pri-nbns set ipcp enable req-sec-nbns set ipcp ranges 0.0.0.0/0 208.206.3.5/32 # # The five lines below enable Microsoft Point-to-Point encryption # (MPPE) using the ng_mppc(8) netgraph node type. # set bundle disable multilink set bundle enable compression # set bundle enable crypt-reqd set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless open mpd console log: ---- [root@bofh tom]# mpd4 Multi-link PPP daemon for FreeBSD process 10036 started, version 4.1 (tom@bofh.straycat.dhs.org 08:58 10-Apr-2007) CONSOLE: listening on 0.0.0.0 5005 [vpn] using interface ng0 [vpn] link: OPEN event [vpn] LCP: Open event [vpn] LCP: state change Initial --> Starting [vpn] LCP: LayerStart pptp0: connecting to 208.206.3.5 1723 pptp0: connected to 208.206.3.5 1723 pptp0: attached to connection with 208.206.3.5 1723 pptp0-0: outgoing call connected at 10000000 bps [vpn] PPTP call successful [vpn] link: UP event [vpn] link: origination is local [vpn] LCP: Up event [vpn] LCP: state change Starting --> Req-Sent [vpn] LCP: SendConfigReq #1 ACFCOMP PROTOCOMP MRU 1400 MAGICNUM 74561568 AUTHPROTO CHAP MSOFT [vpn] LCP: SendConfigReq #2 ACFCOMP PROTOCOMP MRU 1400 MAGICNUM 74561568 AUTHPROTO CHAP MSOFT [vpn] LCP: rec'd Configure Reject #2 link 0 (Req-Sent) ACFCOMP PROTOCOMP AUTHPROTO CHAP MSOFT [vpn] LCP: SendConfigReq #3 MRU 1400 MAGICNUM 74561568 [vpn] LCP: rec'd Configure Nak #3 link 0 (Req-Sent) MRU 1500 [vpn] LCP: SendConfigReq #4 MRU 1500 MAGICNUM 74561568 [vpn] LCP: rec'd Configure Request #1 link 0 (Req-Sent) AUTHPROTO CHAP MSOFT [vpn] LCP: SendConfigAck #1 AUTHPROTO CHAP MSOFT [vpn] LCP: state change Req-Sent --> Ack-Sent [vpn] LCP: rec'd Configure Ack #4 link 0 (Ack-Sent) MRU 1500 MAGICNUM 74561568 [vpn] LCP: state change Ack-Sent --> Opened [vpn] LCP: auth: peer wants CHAP, I want nothing [vpn] LCP: LayerUp [vpn] CHAP: rec'd CHALLENGE #1 Name: "" Using authname "*****" [vpn] CHAP: sending RESPONSE len:70 [vpn] CHAP: rec'd CHALLENGE #2 Name: "" Using authname "*****" [vpn] CHAP: sending RESPONSE len:70 [vpn] CHAP: rec'd SUCCESS #2 [vpn] LCP: authorization successful [vpn] Bundle up: 1 link, total bandwidth 64000 bps [vpn] IPCP: Open event [vpn] IPCP: state change Initial --> Starting [vpn] IPCP: LayerStart [vpn] CCP: Open event [vpn] CCP: state change Initial --> Starting [vpn] CCP: LayerStart [vpn] IPCP: Up event [vpn] IPCP: state change Starting --> Req-Sent [vpn] IPCP: SendConfigReq #1 IPADDR 0.0.0.0 PRIDNS 0.0.0.0 SECDNS 0.0.0.0 PRINBNS 0.0.0.0 SECNBNS 0.0.0.0 [vpn] CCP: Up event [vpn] CCP: state change Starting --> Req-Sent [vpn] CCP: SendConfigReq #1 MPPC 0x01000060:MPPE(40, 128 bits), stateless [vpn] IPCP: rec'd Configure Request #0 link 0 (Req-Sent) IPADDR 208.206.3.5 208.206.3.5 is OK [vpn] IPCP: SendConfigAck #0 IPADDR 208.206.3.5 [vpn] IPCP: state change Req-Sent --> Ack-Sent [vpn] CCP: rec'd Configure Request #0 link 0 (Req-Sent) MPPC 0x01000060:MPPE(40, 128 bits), stateless [vpn] CCP: SendConfigNak #0 MPPC 0x01000040:MPPE(128 bits), stateless [vpn] CCP: rec'd Configure Request #1 link 0 (Req-Sent) MPPC 0x01000040:MPPE(128 bits), stateless [vpn] CCP: SendConfigAck #1 MPPC 0x01000040:MPPE(128 bits), stateless [vpn] CCP: state change Req-Sent --> Ack-Sent [vpn] CCP: SendConfigReq #2 MPPC 0x01000060:MPPE(40, 128 bits), stateless [vpn] IPCP: SendConfigReq #2 IPADDR 0.0.0.0 PRIDNS 0.0.0.0 SECDNS 0.0.0.0 PRINBNS 0.0.0.0 SECNBNS 0.0.0.0 [vpn] CCP: rec'd Configure Nak #2 link 0 (Ack-Sent) MPPC 0x01000040:MPPE(128 bits), stateless [vpn] CCP: SendConfigReq #3 MPPC 0x01000040:MPPE(128 bits), stateless [vpn] IPCP: rec'd Configure Nak #2 link 0 (Ack-Sent) IPADDR 172.30.29.9 172.30.29.9 is OK PRIDNS 172.30.16.2 SECDNS 172.30.0.2 PRINBNS 172.30.16.3 SECNBNS 172.30.0.7 [vpn] IPCP: SendConfigReq #3 IPADDR 172.30.29.9 PRIDNS 172.30.16.2 SECDNS 172.30.0.2 PRINBNS 172.30.16.3 SECNBNS 172.30.0.7 [vpn] CCP: rec'd Configure Ack #3 link 0 (Ack-Sent) MPPC 0x01000040:MPPE(128 bits), stateless [vpn] CCP: state change Ack-Sent --> Opened [vpn] CCP: LayerUp Compress using: mppc (MPPE(128 bits), stateless) Decompress using: mppc (MPPE(128 bits), stateless) [vpn] IPCP: rec'd Configure Ack #3 link 0 (Ack-Sent) IPADDR 172.30.29.9 PRIDNS 172.30.16.2 SECDNS 172.30.0.2 PRINBNS 172.30.16.3 SECNBNS 172.30.0.7 [vpn] IPCP: state change Ack-Sent --> Opened [vpn] IPCP: LayerUp 172.30.29.9 -> 208.206.3.5 [vpn] IFACE: Up event [vpn] LCP: no reply to 1 echo request(s) [vpn] LCP: no reply to 2 echo request(s) [vpn] LCP: no reply to 3 echo request(s) [vpn] LCP: no reply to 4 echo request(s) [vpn] LCP: no reply to 1 echo request(s) [vpn] LCP: no reply to 2 echo request(s) [vpn] LCP: no reply to 3 echo request(s) [vpn] LCP: no reply to 4 echo request(s) [vpn] LCP: no reply to 5 echo request(s) [vpn] LCP: no reply to 6 echo request(s) [vpn] LCP: no reply to 7 echo request(s) [vpn] LCP: peer not responding to echo requests [vpn] LCP: state change Opened --> Stopping [vpn] AUTH: Accounting data for user : 154 seconds, 260 octets in, 1609 octets out [vpn] AUTH: Cleanup [vpn] Bundle up: 0 links, total bandwidth 9600 bps [vpn] IPCP: Close event [vpn] IPCP: state change Opened --> Closing [vpn] IPCP: SendTerminateReq #4 [vpn] error writing len 8 frame to bypass: Network is down [vpn] IPCP: LayerDown [vpn] IFACE: Down event [vpn] CCP: Close event [vpn] CCP: state change Opened --> Closing [vpn] CCP: SendTerminateReq #4 [vpn] error writing len 8 frame to bypass: Network is down [vpn] CCP: LayerDown [vpn] IPCP: Down event [vpn] IPCP: LayerFinish [vpn] No NCPs left. Closing links... [vpn] closing link "vpn"... [vpn] IPCP: state change Closing --> Initial [vpn] CCP: Down event [vpn] CCP: LayerFinish [vpn] CCP: state change Closing --> Initial [vpn] LCP: SendTerminateReq #5 [vpn] LCP: LayerDown [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] LCP: state change Stopping --> Closing [vpn] LCP: SendTerminateReq #6 pptp0: read: Connection reset by peer pptp0: killing connection with 208.206.3.5 1723 pptp0-0: killing channel [vpn] PPTP call terminated [vpn] link: DOWN event [vpn] LCP: Down event [vpn] LCP: LayerFinish [vpn] LCP: state change Closing --> Initial netstat [root@bofh mpd4]# netstat -r -f inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default linksys UGS 0 8516 em0 localhost localhost UH 0 640 lo0 172.30.29.9/32 lo0 US 0 0 lo0 192.168.1 link#2 UC 0 0 em0 linksys 00:06:25:dc:a0:f1 UHLW 2 0 em0 1024 shorthair 00:09:5b:0b:78:e2 UHLW 1 6401 em0 1180 COMPASS 00:11:d8:f9:70:aa UHLW 1 73381 em0 1160 bofh 00:11:25:85:e4:fc UHLW 1 193 lo0 192.168.1.255 ff:ff:ff:ff:ff:ff UHLWb 1 84 em0 208.206.3.5 172.30.29.9 UH 0 7 ng0 ifconfig [root@bofh tom]# ifconfig ng0 ng0: flags=88d1 mtu 1396 inet 172.30.29.9 --> 208.206.3.5 netmask 0xffffffff -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | | BSD# http://www.mono-project.com/Mono:FreeBSD | From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 03:55:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3023C16A402 for ; Tue, 17 Apr 2007 03:55:12 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id DBCFA13C46A for ; Tue, 17 Apr 2007 03:55:11 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 67CF15C19 for ; Tue, 17 Apr 2007 13:36:43 +1000 (EST) From: Alan Garfield To: freebsd-net@freebsd.org Content-Type: text/plain Date: Tue, 17 Apr 2007 13:36:43 +1000 Message-Id: <1176781003.6367.12.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Subject: fake MAC addresses and ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 03:55:12 -0000 Hi all, I've got a small problem I'm hoping one of you highly skilled individuals might have the answer to. I've got a little driver that communicates via a small buffer on the motherboard of a Sun Fire V20z to a built-in "service processor" which is running Linux. The driver on both sides makes the buffer look like a Ethernet interface. Now I've ported the Linux driver across to FreeBSD so far without to much trouble, but now I've hit the limits of my knowledge. The driver can receive data from the SP just fine, I can tcpdump the interface and I get all the traffic no problem. But when I attempt to send anything I get :- arplookup 169.254.101.2 failed: could not allocate llinfo arpresolve: can't allocate route for 169.254.101.2 The Linux driver I'm porting simply grabbed any outgoing arp requests, made up an appropriate response with the pre-defined fake MAC's, put it into the input queue and ate the request packet. Now in FreeBSD I cannot see a way to do this other than overriding the if_output function in the ifp with something of my own. I've tried to do it in if_start but I never see any arp requests. But I also think the whole thing is a bit of an ugly hack. Now I'm thinking I have to do something with rtrequest instead, but I have no idea what I am required to do in that function to insert the fake MACs to resolve the route. I get a call for RTM_ADD but then I don't know what I'm suppose to do. There is no similar device drivers I can gauge what to do (except the plip driver which doesn't seem to worry about arp at all!). Any help would be most appreciated as I'm almost done and I'm running out of spare time to get this working! Many thanks, Alan. From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 05:05:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27DBF16A404 for ; Tue, 17 Apr 2007 05:05:31 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2219313C469 for ; Tue, 17 Apr 2007 05:05:25 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id l3G8LP3f005183; Mon, 16 Apr 2007 10:21:25 +0200 (MEST) Message-ID: <46232FF8.2030604@fer.hr> Date: Mon, 16 Apr 2007 10:12:40 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.10 (X11/20060911) MIME-Version: 1.0 To: Luigi Rizzo References: <20070415145621.B39338@xorpc.icir.org> <4622A227.9090003@fer.hr> <20070415155402.A40022@xorpc.icir.org> In-Reply-To: <20070415155402.A40022@xorpc.icir.org> X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA70F5668284487A1C97D1AE5" Cc: freebsd-net@freebsd.org Subject: Re: Understanding ipfw keep-state dynamic rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 05:05:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA70F5668284487A1C97D1AE5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Luigi Rizzo wrote: > On Mon, Apr 16, 2007 at 12:07:35AM +0200, Ivan Voras wrote: >> Luigi Rizzo wrote: >> >>> yes the numbers should be the expire time for the rule. >> So, the total time the connection was active or the time the connectio= n >> had some traffic through it? >=20 > it is the expire time (i.e. how many seconds from now the rule > will be deleted). It should normally be the preset timeout > (300 as a default for active sessions) minus the time for which > the connection has been idle. So is there a way to find out from this listing which connections have=20 been stalled too long? "Short" expire times may mean closed connections=20 or may mean a rule that's been active for a long time and is now almost=20 expired. > in terms of tcp, on the server you would need to send a FIN > (to signal "no more data from me") followed by a RST (to signal > "i am not listening anymore"). Maybe a shutdown(s, SHUT_RDWR) > can do the job, probably just close() is not enough. > But i am not 100% sure. I can't modify the server. I was hoping ipfw would send a RST to both=20 sides if a rule expires. --------------enigA70F5668284487A1C97D1AE5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGIy/+ldnAQVacBcgRAkNSAKC/o6/YoSah2wdKA/zZ9mq9ESf/EQCgxN85 Bn2Fvx1SkaFu/jEDD74T9tA= =qOlw -----END PGP SIGNATURE----- --------------enigA70F5668284487A1C97D1AE5-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 06:33:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61A7816A402 for ; Tue, 17 Apr 2007 06:33:08 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (mx1.ethionet.et [213.55.64.53]) by mx1.freebsd.org (Postfix) with ESMTP id 6658A13C469 for ; Tue, 17 Apr 2007 06:33:07 +0000 (UTC) (envelope-from mtm@FreeBSD.Org) Received: from mx1.ethionet.et (localhost [127.0.0.1]) by localhost.ethionet.et (Postfix) with ESMTP id 2D34A51A9; Tue, 17 Apr 2007 09:29:21 +0300 (EAT) Received: from rogue.navcom.lan (unknown [213.55.69.157])by mx1.ethionet.et (Postfix) with SMTP id 8D44D51A2; Tue, 17 Apr 2007 09:29:16 +0300 (EAT) Received: by rogue.navcom.lan (Postfix, from userid 1001)id EC017124A; Tue, 17 Apr 2007 09:35:53 +0300 (EAT) Date: Tue, 17 Apr 2007 09:35:53 +0300 From: Mike Makonnen To: Max Laier Message-ID: <20070417063553.GA2053@rogue.navcom.lan> References: <20070416101609.GA2137@rogue.navcom.lan> <200704162226.08931.max @love2party.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <200704162226.08931.max@love2party.net> User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD/7.0-CURRENT (i386) X-imss-version: 2.46 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:4 C:3 M:3 S:4 R:3 (1.0000 1.0000) Cc: freebsd-net@freebsd.org Subject: Re: ping6 extension headers bounds checking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 06:33:08 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 16, 2007 at 10:25:59PM +0200, Max Laier wrote: > > I think it'd be better to supply the print functions with the rest of the > bufferlen instead of an offset. This way only the caller has to know the > size of the buffer - Ok, Done. See attached patch. >btw, do we get a result back i.e. how much buffer > was used. In addition you could check if the offset in the for-loop of > the caller is within bounds, before even attempting to call further. On the first part: no and yes :). The cmsg structure tells you the length, including the cmsg header, which is fine if the buffer is big enough. If the buffer is too small, the stated length in the cmsg structure stays the same but MSG_CTRUNC is appended to msg_flags to tell you that dome data was discarded at the end because it didn't fit in the buffer. On the second part: Done. see attached patch. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mmakonnen @ gmail.com | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm @ FreeBSD.Org | FreeBSD - http://www.freebsd.org --LZvS9be/3tNcYl/X Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="ping6.diff" Index: sbin/ping6/ping6.c =================================================================== RCS file: /home/ncvs/src/sbin/ping6/ping6.c,v retrieving revision 1.29 diff -u -r1.29 ping6.c --- sbin/ping6/ping6.c 10 Feb 2005 09:19:32 -0000 1.29 +++ sbin/ping6/ping6.c 17 Apr 2007 06:07:53 -0000 @@ -150,6 +150,7 @@ #define ICMP6ECHOLEN 8 /* icmp echo header len excluding time */ #define ICMP6ECHOTMLEN sizeof(struct tv32) #define ICMP6_NIQLEN (ICMP6ECHOLEN + 8) +# define CONTROLLEN 10240 /* ancillary data buffer size RFC3542 20.1 */ /* FQDN case, 64 bits of nonce + 32 bits ttl */ #define ICMP6_NIRLEN (ICMP6ECHOLEN + 12) #define EXTRA 256 /* for AH and various other headers. weird. */ @@ -269,8 +270,8 @@ char *, size_t); void pr_pack(u_char *, int, struct msghdr *); void pr_exthdrs(struct msghdr *); -void pr_ip6opt(void *); -void pr_rthdr(void *); +void pr_ip6opt(void *, unsigned int); +void pr_rthdr(void *, unsigned int); int pr_bitrange(u_int32_t, int, int); void pr_retip(struct ip6_hdr *, u_char *); void summary(void); @@ -307,6 +308,7 @@ char *e, *target, *ifname = NULL, *gateway = NULL; int ip6optlen = 0; struct cmsghdr *scmsgp = NULL; + struct cmsghdr *cm; #if defined(SO_SNDBUF) && defined(SO_RCVBUF) u_long lsockbufsize; int sockbufsize = 0; @@ -1057,10 +1059,13 @@ seeninfo = 0; #endif + /* For control (ancillary) data received from recvmsg() */ + cm = (struct cmsghdr *)malloc(CONTROLLEN); + if (cm == NULL) + err(1, "malloc"); + for (;;) { struct msghdr m; - struct cmsghdr *cm; - u_char buf[1024]; struct iovec iov[2]; /* signal handling */ @@ -1127,9 +1132,9 @@ iov[0].iov_len = packlen; m.msg_iov = iov; m.msg_iovlen = 1; - cm = (struct cmsghdr *)buf; - m.msg_control = (caddr_t)buf; - m.msg_controllen = sizeof(buf); + memset(cm, 0, CONTROLLEN); + m.msg_control = (void *)cm; + m.msg_controllen = CONTROLLEN; cc = recvmsg(s, &m, 0); if (cc < 0) { @@ -1493,6 +1498,9 @@ pr_addr(from, fromlen)); return; } + if (((mhdr->msg_flags & MSG_CTRUNC) != 0) && + (options & F_VERBOSE) != 0) + warnx("some control data discarded, insufficient buffer size"); icp = (struct icmp6_hdr *)buf; ni = (struct icmp6_nodeinfo *)buf; off = 0; @@ -1735,28 +1743,33 @@ pr_exthdrs(mhdr) struct msghdr *mhdr; { - struct cmsghdr *cm; + struct cmsghdr *cm, *cm1; + int bufsize; - for (cm = (struct cmsghdr *)CMSG_FIRSTHDR(mhdr); cm; - cm = (struct cmsghdr *)CMSG_NXTHDR(mhdr, cm)) { + bufsize = 0; + cm1 = (struct cmsghdr *)CMSG_FIRSTHDR(mhdr); + for (cm = cm1; cm; cm = (struct cmsghdr *)CMSG_NXTHDR(mhdr, cm)) { if (cm->cmsg_level != IPPROTO_IPV6) continue; + bufsize = CONTROLLEN - ((caddr_t)CMSG_DATA(cm) - (caddr_t)cm1); + if (bufsize <= 0) + return; switch (cm->cmsg_type) { case IPV6_HOPOPTS: printf(" HbH Options: "); - pr_ip6opt(CMSG_DATA(cm)); + pr_ip6opt(CMSG_DATA(cm), (unsigned int)bufsize); break; case IPV6_DSTOPTS: #ifdef IPV6_RTHDRDSTOPTS case IPV6_RTHDRDSTOPTS: #endif printf(" Dst Options: "); - pr_ip6opt(CMSG_DATA(cm)); + pr_ip6opt(CMSG_DATA(cm), (unsigned int)bufsize); break; case IPV6_RTHDR: printf(" Routing: "); - pr_rthdr(CMSG_DATA(cm)); + pr_rthdr(CMSG_DATA(cm), (unsigned int)bufsize); break; } } @@ -1764,12 +1777,12 @@ #ifdef USE_RFC2292BIS void -pr_ip6opt(void *extbuf) +pr_ip6opt(void *extbuf, unsigned int bufsize) { struct ip6_hbh *ext; int currentlen; u_int8_t type; - socklen_t extlen, len; + socklen_t extlen, len, origextlen; void *databuf; size_t offset; u_int16_t value2; @@ -1780,6 +1793,18 @@ printf("nxt %u, len %u (%lu bytes)\n", ext->ip6h_nxt, (unsigned int)ext->ip6h_len, (unsigned long)extlen); + /* + * Bounds checking on the ancillary data buffer: + * subtract the size of a cmsg structure from the buffer size. + */ + if (bufsize < (extlen + CMSG_SPACE(0))) { + origextlen = extlen; + extlen = bufsize - CMSG_SPACE(0); + warnx("options truncated, showing only %u (total=%u)", + (unsigned int)(extlen / 8 - 1), + (unsigned int)(ext->ip6h_len)); + } + currentlen = 0; while (1) { currentlen = inet6_opt_next(extbuf, extlen, currentlen, @@ -1816,7 +1841,7 @@ #else /* !USE_RFC2292BIS */ /* ARGSUSED */ void -pr_ip6opt(void *extbuf) +pr_ip6opt(void *extbuf, unsigned int bufsize __unused) { putchar('\n'); return; @@ -1825,21 +1850,43 @@ #ifdef USE_RFC2292BIS void -pr_rthdr(void *extbuf) +pr_rthdr(void *extbuf, unsigned int bufsize) { struct in6_addr *in6; char ntopbuf[INET6_ADDRSTRLEN]; struct ip6_rthdr *rh = (struct ip6_rthdr *)extbuf; - int i, segments; + int i, segments, origsegs, rthsize, size0, size1; /* print fixed part of the header */ printf("nxt %u, len %u (%d bytes), type %u, ", rh->ip6r_nxt, rh->ip6r_len, (rh->ip6r_len + 1) << 3, rh->ip6r_type); - if ((segments = inet6_rth_segments(extbuf)) >= 0) + if ((segments = inet6_rth_segments(extbuf)) >= 0) { printf("%d segments, ", segments); - else + printf("%d left\n", rh->ip6r_segleft); + } else { printf("segments unknown, "); - printf("%d left\n", rh->ip6r_segleft); + printf("%d left\n", rh->ip6r_segleft); + return; + } + + /* + * Bounds checking on the ancillary data buffer. When calculating + * the number of items to show keep in mind: + * - The size of the cmsg structure + * - The size of one segment (the size of one Type 0 route header) + * - When dividing add a fudge factor of one in case the + * dividend is not evenly divisible by the divisor + */ + rthsize = (rh->ip6r_len + 1) * 8; + if (bufsize < (rthsize + CMSG_SPACE(0))) { + origsegs = segments; + size0 = inet6_rth_space(IPV6_RTHDR_TYPE_0, 0); + size1 = inet6_rth_space(IPV6_RTHDR_TYPE_0, 1); + segments -= (rthsize - (bufsize - CMSG_SPACE(0))) / + (size1 - size0) + 1; + warnx("segments truncated, showing only %d (total=%d)", + segments, origsegs); + } for (i = 0; i < segments; i++) { in6 = inet6_rth_getaddr(extbuf, i); @@ -1860,7 +1907,7 @@ #else /* !USE_RFC2292BIS */ /* ARGSUSED */ void -pr_rthdr(void *extbuf) +pr_rthdr(void *extbuf, unsigned int bufsize __unused) { putchar('\n'); return; --LZvS9be/3tNcYl/X-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 08:44:23 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C49F216A400 for ; Tue, 17 Apr 2007 08:44:23 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: from mail.sub.ru (mail.sub.ru [88.212.205.2]) by mx1.freebsd.org (Postfix) with SMTP id 9C54C13C44B for ; Tue, 17 Apr 2007 08:44:21 +0000 (UTC) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 88154 invoked from network); 17 Apr 2007 12:49:42 +0400 Received: from unknown (HELO localhost) (88.212.205.2) by mail.sub.ru with SMTP; 17 Apr 2007 12:49:42 +0400 X-Virus-Scanned: by amavisd-new at mail.sub.ru Received: from unknown ([88.212.205.2]) by localhost (mail-new.sub.ru [88.212.205.2]) (amavisd-new, port 10024) with SMTP id plNAyMk1CEQJ; Tue, 17 Apr 2007 12:49:37 +0400 (MSD) Received: from unknown (HELO ?192.168.139.47?) (tarkhil%sub.ru@192.168.139.47) by techno.sub.ru with SMTP; 17 Apr 2007 08:49:37 -0000 Message-ID: <462488D5.2070907@webmail.sub.ru> Date: Tue, 17 Apr 2007 12:44:05 +0400 From: Alex Povolotsky User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Max Laier References: <46226AD3.3030806@webmail.sub.ru> <200704161359.26059.max@love2party.net> In-Reply-To: <200704161359.26059.max@love2party.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Please help with PF-based redirector X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 08:44:23 -0000 Max Laier wrote: > On Sunday 15 April 2007 20:11, Alex Povolotsky wrote: > >> Hello! >> >> I'm trying to set up a box as round-robin TCP proxy. Of course, I'm >> trying to do everything on kernel-level. >> >> This simple setup >> >> rdr on sk0 proto tcp from any to any port = smtp -> port 25 >> round-robin >> >> should work. At least, I thought so. >> >> However, attempt to connect to port 25 yielded unexpected result. pfctl >> -s state shows >> >> self tcp 89.108.94.212:25 <- 89.108.94.91:25 <- >> 89.108.94.211:56975 CLOSED:SYN_SENT >> > > Your test hosts seem to be on the same subnet. This does not work as you > seems to think. In the same broadcast domain it is not possible for the > pf box to forward the packet on behalf of the sending host (otherwise it > would confuse the recipient or the switch). Instead it emits icmp > redirects which are ignored in a normal setup. > > You have to separate the two networks in order for redirect to work the > way you want it to. > Sorry, things are not THAT simple. I've tried the setup: unknown-1717# ifconfig rl0: flags=8843 mtu 1500 options=8 inet 10.180.210.2 netmask 0xffffff00 broadcast 10.180.210.255 ether 00:0e:2e:98:7e:55 media: Ethernet autoselect (100baseTX ) status: active sk0: flags=8943 mtu 1500 options=b inet 89.108.94.91 netmask 0xfffff000 broadcast 89.108.95.255 inet 10.180.220.1 netmask 0xffffff00 broadcast 10.180.220.255 ether 00:18:f3:5c:de:6d media: Ethernet autoselect (100baseTX ) status: active plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 pfsync0: flags=0<> mtu 1348 syncpeer: 224.0.0.240 maxupd: 128 carp0: flags=49 mtu 1500 inet 89.108.94.92 netmask 0xfffff000 carp: MASTER vhid 21 advbase 1 advskew 0 unknown-1717# pfctl -s nat No ALTQ support in kernel ALTQ related functions disabled nat on sk0 inet from 10.180.210.0/24 to any -> (sk0) round-robin rdr on rl0 proto tcp from any to any port = smtp -> port 25 round-robin seems reasonable. yes? FIRST connect works ok Than - no success at all for some time. Than - works again unknown-1717# pfctl -s state No ALTQ support in kernel ALTQ related functions disabled self tcp 89.108.65.126:25 <- 10.180.210.2:25 <- 10.180.210.1:62736 CLOSED:SYN_SENT self tcp 89.108.65.126:25 <- 10.180.210.2:25 <- 10.180.210.1:58177 FIN_WAIT_2:FIN_WAIT_2 self tcp 89.108.94.212:25 <- 10.180.210.2:25 <- 10.180.210.1:57950 FIN_WAIT_2:FIN_WAIT_2 self tcp 89.108.94.212:25 <- 10.180.210.2:25 <- 10.180.210.1:58727 CLOSED:SYN_SENT self tcp 89.108.65.124:25 <- 10.180.210.2:25 <- 10.180.210.1:63480 CLOSED:SYN_SENT self tcp 10.180.210.1:63480 -> 89.108.94.91:54490 -> 89.108.65.124:25 SYN_SENT:CLOSED self tcp 10.180.210.1:62736 -> 10.180.220.1:52675 -> 89.108.65.126:25 SYN_SENT:CLOSED self tcp 10.180.210.1:58177 -> 89.108.94.91:51550 -> 89.108.65.126:25 FIN_WAIT_2:FIN_WAIT_2 self tcp 10.180.210.1:58727 -> 10.180.220.1:50704 -> 89.108.94.212:25 SYN_SENT:CLOSED self tcp 10.180.210.1:57950 -> 89.108.94.91:65245 -> 89.108.94.212:25 FIN_WAIT_2:FIN_WAIT_2 You can see that some connections works, and some fails. 110% problem is NOT on real SMTP servers' side. Alex. From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 09:39:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1AE116A403 for ; Tue, 17 Apr 2007 09:39:28 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from wmail.teledomenet.gr (wmail.teledomenet.gr [213.142.128.16]) by mx1.freebsd.org (Postfix) with ESMTP id 57B3713C44C for ; Tue, 17 Apr 2007 09:39:28 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from iris (unknown [192.168.1.71]) by wmail.teledomenet.gr (Postfix) with ESMTP id CB95E1C8970; Tue, 17 Apr 2007 11:35:24 +0300 (EEST) From: Nikos Vassiliadis To: freebsd-net@freebsd.org Date: Tue, 17 Apr 2007 12:12:29 +0300 User-Agent: KMail/1.9.1 References: <1176762905.1901.59.camel@localhost> In-Reply-To: <1176762905.1901.59.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704171212.29307.nvass@teledomenet.gr> Cc: Tom McLaughlin Subject: Re: net/mpd4: Unable to pass pass traffic as pptp client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 09:39:29 -0000 On Tuesday 17 April 2007 01:35, Tom McLaughlin wrote: > Hi all, > > I'm trying to use mpd4 to connect my work's Cisco VPN concentrator. > After fiddling with mpd.conf I can now get past the connection setup > phase and authentication steps. According to the VPN concentrator's > logs I have successfully connected but some bit later I am disconnected > and the logs show no traffic passed in or out on my connection. While > connected I can't ping or reach anything on the work network. After > some googling I've found that others have had routing related issues but > couldn't find exactly how they were resolved. Can anyone lend me a hand > here and point me in the right direction? Below is my mpd.conf along > with mpd's console messages along with my routing table. > > Thanks, > tom > (Please CC me on replies) > > mpd.conf: > ---- > vpn: > new -i ng0 vpn vpn > set iface disable on-demand > set iface idle 0 > # disconnect the client after 8 hours > set iface session 28800 > set iface enable tcpmssfix > > set auth authname "*****" > set auth password "*****" > > set link yes acfcomp protocomp > # If remote machine is NT you need this.. > set link enable no-orig-auth > set link enable keep-ms-domain > set link no pap > set link yes chap-msv1 > set link mtu 1400 > set link mru 1400 > set link keep-alive 10 75 > > set ipcp no vjcomp > set ipcp enable req-pri-dns > set ipcp enable req-sec-dns > set ipcp enable req-pri-nbns > set ipcp enable req-sec-nbns > set ipcp ranges 0.0.0.0/0 208.206.3.5/32 > # > # The five lines below enable Microsoft Point-to-Point encryption > # (MPPE) using the ng_mppc(8) netgraph node type. > # > set bundle disable multilink > set bundle enable compression > # set bundle enable crypt-reqd > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > open > > mpd console log: > ---- > [root@bofh tom]# mpd4 > Multi-link PPP daemon for FreeBSD > process 10036 started, version 4.1 (tom@bofh.straycat.dhs.org 08:58 10-Apr-2007) > > CONSOLE: listening on 0.0.0.0 5005 > [vpn] using interface ng0 > [vpn] link: OPEN event > [vpn] LCP: Open event > [vpn] LCP: state change Initial --> Starting > [vpn] LCP: LayerStart > pptp0: connecting to 208.206.3.5 1723 > pptp0: connected to 208.206.3.5 1723 > pptp0: attached to connection with 208.206.3.5 1723 > pptp0-0: outgoing call connected at 10000000 bps > [vpn] PPTP call successful > [vpn] link: UP event > [vpn] link: origination is local > [vpn] LCP: Up event > [vpn] LCP: state change Starting --> Req-Sent > [vpn] LCP: SendConfigReq #1 > ACFCOMP > PROTOCOMP > MRU 1400 > MAGICNUM 74561568 > AUTHPROTO CHAP MSOFT > [vpn] LCP: SendConfigReq #2 > ACFCOMP > PROTOCOMP > MRU 1400 > MAGICNUM 74561568 > AUTHPROTO CHAP MSOFT > [vpn] LCP: rec'd Configure Reject #2 link 0 (Req-Sent) > ACFCOMP > PROTOCOMP > AUTHPROTO CHAP MSOFT > [vpn] LCP: SendConfigReq #3 > MRU 1400 > MAGICNUM 74561568 > [vpn] LCP: rec'd Configure Nak #3 link 0 (Req-Sent) > MRU 1500 > [vpn] LCP: SendConfigReq #4 > MRU 1500 > MAGICNUM 74561568 > [vpn] LCP: rec'd Configure Request #1 link 0 (Req-Sent) > AUTHPROTO CHAP MSOFT > [vpn] LCP: SendConfigAck #1 > AUTHPROTO CHAP MSOFT > [vpn] LCP: state change Req-Sent --> Ack-Sent > [vpn] LCP: rec'd Configure Ack #4 link 0 (Ack-Sent) > MRU 1500 > MAGICNUM 74561568 > [vpn] LCP: state change Ack-Sent --> Opened > [vpn] LCP: auth: peer wants CHAP, I want nothing > [vpn] LCP: LayerUp > [vpn] CHAP: rec'd CHALLENGE #1 > Name: "" > Using authname "*****" > [vpn] CHAP: sending RESPONSE len:70 > [vpn] CHAP: rec'd CHALLENGE #2 > Name: "" > Using authname "*****" > [vpn] CHAP: sending RESPONSE len:70 > [vpn] CHAP: rec'd SUCCESS #2 > [vpn] LCP: authorization successful > [vpn] Bundle up: 1 link, total bandwidth 64000 bps > [vpn] IPCP: Open event > [vpn] IPCP: state change Initial --> Starting > [vpn] IPCP: LayerStart > [vpn] CCP: Open event > [vpn] CCP: state change Initial --> Starting > [vpn] CCP: LayerStart > [vpn] IPCP: Up event > [vpn] IPCP: state change Starting --> Req-Sent > [vpn] IPCP: SendConfigReq #1 > IPADDR 0.0.0.0 > PRIDNS 0.0.0.0 > SECDNS 0.0.0.0 > PRINBNS 0.0.0.0 > SECNBNS 0.0.0.0 > [vpn] CCP: Up event > [vpn] CCP: state change Starting --> Req-Sent > [vpn] CCP: SendConfigReq #1 > MPPC > 0x01000060:MPPE(40, 128 bits), stateless > [vpn] IPCP: rec'd Configure Request #0 link 0 (Req-Sent) > IPADDR 208.206.3.5 > 208.206.3.5 is OK > [vpn] IPCP: SendConfigAck #0 > IPADDR 208.206.3.5 > [vpn] IPCP: state change Req-Sent --> Ack-Sent > [vpn] CCP: rec'd Configure Request #0 link 0 (Req-Sent) > MPPC > 0x01000060:MPPE(40, 128 bits), stateless > [vpn] CCP: SendConfigNak #0 > MPPC > 0x01000040:MPPE(128 bits), stateless > [vpn] CCP: rec'd Configure Request #1 link 0 (Req-Sent) > MPPC > 0x01000040:MPPE(128 bits), stateless > [vpn] CCP: SendConfigAck #1 > MPPC > 0x01000040:MPPE(128 bits), stateless > [vpn] CCP: state change Req-Sent --> Ack-Sent > [vpn] CCP: SendConfigReq #2 > MPPC > 0x01000060:MPPE(40, 128 bits), stateless > [vpn] IPCP: SendConfigReq #2 > IPADDR 0.0.0.0 > PRIDNS 0.0.0.0 > SECDNS 0.0.0.0 > PRINBNS 0.0.0.0 > SECNBNS 0.0.0.0 > [vpn] CCP: rec'd Configure Nak #2 link 0 (Ack-Sent) > MPPC > 0x01000040:MPPE(128 bits), stateless > [vpn] CCP: SendConfigReq #3 > MPPC > 0x01000040:MPPE(128 bits), stateless > [vpn] IPCP: rec'd Configure Nak #2 link 0 (Ack-Sent) > IPADDR 172.30.29.9 > 172.30.29.9 is OK > PRIDNS 172.30.16.2 > SECDNS 172.30.0.2 > PRINBNS 172.30.16.3 > SECNBNS 172.30.0.7 > [vpn] IPCP: SendConfigReq #3 > IPADDR 172.30.29.9 > PRIDNS 172.30.16.2 > SECDNS 172.30.0.2 > PRINBNS 172.30.16.3 > SECNBNS 172.30.0.7 > [vpn] CCP: rec'd Configure Ack #3 link 0 (Ack-Sent) > MPPC > 0x01000040:MPPE(128 bits), stateless > [vpn] CCP: state change Ack-Sent --> Opened > [vpn] CCP: LayerUp > Compress using: mppc (MPPE(128 bits), stateless) > Decompress using: mppc (MPPE(128 bits), stateless) > [vpn] IPCP: rec'd Configure Ack #3 link 0 (Ack-Sent) > IPADDR 172.30.29.9 > PRIDNS 172.30.16.2 > SECDNS 172.30.0.2 > PRINBNS 172.30.16.3 > SECNBNS 172.30.0.7 > [vpn] IPCP: state change Ack-Sent --> Opened > [vpn] IPCP: LayerUp > 172.30.29.9 -> 208.206.3.5 > [vpn] IFACE: Up event > [vpn] LCP: no reply to 1 echo request(s) > [vpn] LCP: no reply to 2 echo request(s) > [vpn] LCP: no reply to 3 echo request(s) > [vpn] LCP: no reply to 4 echo request(s) > [vpn] LCP: no reply to 1 echo request(s) > [vpn] LCP: no reply to 2 echo request(s) > [vpn] LCP: no reply to 3 echo request(s) > [vpn] LCP: no reply to 4 echo request(s) > [vpn] LCP: no reply to 5 echo request(s) > [vpn] LCP: no reply to 6 echo request(s) > [vpn] LCP: no reply to 7 echo request(s) > [vpn] LCP: peer not responding to echo requests > [vpn] LCP: state change Opened --> Stopping > [vpn] AUTH: Accounting data for user : 154 seconds, 260 octets in, 1609 octets out > [vpn] AUTH: Cleanup > [vpn] Bundle up: 0 links, total bandwidth 9600 bps > [vpn] IPCP: Close event > [vpn] IPCP: state change Opened --> Closing > [vpn] IPCP: SendTerminateReq #4 > [vpn] error writing len 8 frame to bypass: Network is down > [vpn] IPCP: LayerDown > [vpn] IFACE: Down event > [vpn] CCP: Close event > [vpn] CCP: state change Opened --> Closing > [vpn] CCP: SendTerminateReq #4 > [vpn] error writing len 8 frame to bypass: Network is down > [vpn] CCP: LayerDown > [vpn] IPCP: Down event > [vpn] IPCP: LayerFinish > [vpn] No NCPs left. Closing links... > [vpn] closing link "vpn"... > [vpn] IPCP: state change Closing --> Initial > [vpn] CCP: Down event > [vpn] CCP: LayerFinish > [vpn] CCP: state change Closing --> Initial > [vpn] LCP: SendTerminateReq #5 > [vpn] LCP: LayerDown > [vpn] link: CLOSE event > [vpn] LCP: Close event > [vpn] LCP: state change Stopping --> Closing > [vpn] LCP: SendTerminateReq #6 > pptp0: read: Connection reset by peer > pptp0: killing connection with 208.206.3.5 1723 > pptp0-0: killing channel > [vpn] PPTP call terminated > [vpn] link: DOWN event > [vpn] LCP: Down event > [vpn] LCP: LayerFinish > [vpn] LCP: state change Closing --> Initial > > > netstat > [root@bofh mpd4]# netstat -r -f inet > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default linksys UGS 0 8516 em0 > localhost localhost UH 0 640 lo0 > 172.30.29.9/32 lo0 US 0 0 lo0 > 192.168.1 link#2 UC 0 0 em0 > linksys 00:06:25:dc:a0:f1 UHLW 2 0 em0 1024 > shorthair 00:09:5b:0b:78:e2 UHLW 1 6401 em0 1180 > COMPASS 00:11:d8:f9:70:aa UHLW 1 73381 em0 1160 > bofh 00:11:25:85:e4:fc UHLW 1 193 lo0 > 192.168.1.255 ff:ff:ff:ff:ff:ff UHLWb 1 84 em0 > 208.206.3.5 172.30.29.9 UH 0 7 ng0 > > > ifconfig > [root@bofh tom]# ifconfig ng0 > ng0: flags=88d1 mtu 1396 > inet 172.30.29.9 --> 208.206.3.5 netmask 0xffffffff > It seems that your external peer address is the same with the internal peer address. You connect to pptp-server-ip through your linksys and then say that pptp-server-ip is reachable through the tunnel. So it routes everything destined for pptp-server-ip through the tunnel. I think that such configuration is valid for other operating systems. I don't know if you can work-around the problem on your own, maybe you have to contact the VPN concentrator's admin. Perhaps you can modify the routing table (the external peer address should be reachable as it was, though linksys) and invent some peer address using "ifconfig ng0 your_address 10.0.0.1 netmask 0xffffffff". But it's not nice... Can you convice the concentrator's administrator to use another address for his internal side? HTH, Nikos From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 11:49:01 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8A2C16A40A for ; Tue, 17 Apr 2007 11:49:01 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id ADECF13C458 for ; Tue, 17 Apr 2007 11:48:58 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3HBmpSf090905; Tue, 17 Apr 2007 15:48:52 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3HBmiI5090899; Tue, 17 Apr 2007 15:48:44 +0400 (MSD) (envelope-from yar) Date: Tue, 17 Apr 2007 15:48:44 +0400 From: Yar Tikhiy To: Bruce M Simpson Message-ID: <20070417114843.GC77216@comp.chem.msu.su> References: <45FE9E24.8010201@incunabulum.net> <20070319152837.GA3984@svzserv.kemerovo.su> <20070321092605.GB41715@comp.chem.msu.su> <461B222B.5030602@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <461B222B.5030602@incunabulum.net> User-Agent: Mutt/1.5.9i Cc: Eugene Grosbein , net@freebsd.org Subject: Re: Interface index hack in IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 11:49:01 -0000 On Tue, Apr 10, 2007 at 06:35:39AM +0100, Bruce M Simpson wrote: > Yar Tikhiy wrote: > >Quagga still uses it, too, if its configure script detects FreeBSD > >or NetBSD. I'm afraid it was me who submitted the patch to the > >Quagga folks when I'd found that Quagga's ospfd couldn't handle > >unnumbered P2P interfaces in FreeBSD because their local IPs weren't > >unique. Unfortunately, Quagga doesn't seem to use the protocol > >independent part of the RFC 3678 API yet. > > > > A preliminary patch for the Rhyolite.com routed is available at: > http://people.freebsd.org/~bms/dump/routed.rfc3678.diff > > The upcoming rewrite of IPv4 multicast host-mdoe logic (currently in > bms_netdev) adds support for the Linux-derived 'struct ip_mreqn' for > specifying interface indexes to IP_MULTICAST_IF. The RFC 3678 API is > implemented; IGMPv3 and MLDv2 may be hooked in later on subject to > available resources. > > The RFC 1724 hack has been completely removed from the kernel in this > spin. The new code passes the existing regression tests for any-source > multicast. I hope to have source-specific multicast regression tests in > the main tree ASAP, I am very close to a code drop. > > Whilst the radical approach of rewriting this stuff may break legacy > applications, they should probably be updated to support the new APIs > anyway, given that Linux 2.6 and Microsoft Windows "Longhorn" both > support RFC 3678. By the way, what was so wrong with the RFC 1724 hack that it had to be removed? I'm by no means insisting on it, just curious. Thanks! -- Yar From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 12:00:59 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE93A16A401 for ; Tue, 17 Apr 2007 12:00:59 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD5713C46C for ; Tue, 17 Apr 2007 12:00:59 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l3HC0wB6002130; Tue, 17 Apr 2007 22:00:58 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l3HC0wJk002129; Tue, 17 Apr 2007 22:00:58 +1000 (EST) (envelope-from peter) Date: Tue, 17 Apr 2007 22:00:58 +1000 From: Peter Jeremy To: Alan Garfield Message-ID: <20070417120058.GN1624@turion.vk2pj.dyndns.org> References: <1176781003.6367.12.camel@hiro.auspc.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline In-Reply-To: <1176781003.6367.12.camel@hiro.auspc.com.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: freebsd-net@freebsd.org Subject: Re: fake MAC addresses and ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 12:01:00 -0000 --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Apr-17 13:36:43 +1000, Alan Garfield wrote: >I've got a little driver that communicates via a small buffer on the >motherboard of a Sun Fire V20z to a built-in "service processor" which >is running Linux. The driver on both sides makes the buffer look like a >Ethernet interface. I'd be interested in using this. >arplookup 169.254.101.2 failed: could not allocate llinfo >arpresolve: can't allocate route for 169.254.101.2 > >The Linux driver I'm porting simply grabbed any outgoing arp requests, >made up an appropriate response with the pre-defined fake MAC's, put it >into the input queue and ate the request packet. A quick-and-dirty work-around would seem to be arp -s 169.254.101.2 Fa:ke:ma:cA:dd:re:ss Otherwise, I think you would need to fiddle with the transmit packet code in your driver. --=20 Peter Jeremy --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGJLb5/opHv/APuIcRAsKQAKCEEqPJ2KZ+ouCERwAnTpDudh7lfQCeMStd w5xA9hHi6B3UbezXKYY9WLk= =B2wr -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 15:26:17 2007 Return-Path: X-Original-To: net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E65516A402 for ; Tue, 17 Apr 2007 15:26:17 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CA6CD13C44C for ; Tue, 17 Apr 2007 15:26:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 96321 invoked from network); 17 Apr 2007 14:50:15 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Apr 2007 14:50:15 -0000 Message-ID: <4624E717.1040208@freebsd.org> Date: Tue, 17 Apr 2007 17:26:15 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Kris Kennaway References: <20070416193727.GA66684@xor.obsecurity.org> In-Reply-To: <20070416193727.GA66684@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: Page fault in syncache_drop X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 15:26:17 -0000 Kris Kennaway wrote: > 8-core amd64, up-to-date CVS sources > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff803134b4 > stack pointer = 0x10:0xffffffffabe09890 > frame pointer = 0x10:0xffffffffabe098a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 37 (irq31: bge0) > [thread pid 37 tid 100043 ] > Stopped at syncache_drop+0x4: cmpq $0,(%rdi) > db> wh > Tracing pid 37 tid 100043 td 0xffffff00b9409580 > syncache_drop() at syncache_drop+0x4 > syncache_add() at syncache_add+0x263 > tcp_input() at tcp_input+0x7e0 > ip_input() at ip_input+0x69d > netisr_dispatch() at netisr_dispatch+0x51 > ether_demux() at ether_demux+0x19f > ether_input() at ether_input+0x3a8 > bge_rxeof() at bge_rxeof+0x3ad > bge_intr() at bge_intr+0x11b > ithread_execute_handlers() at ithread_execute_handlers+0x15d > ithread_loop() at ithread_loop+0x69 > fork_exit() at fork_exit+0x93 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffffffabe09d30, rbp = 0 --- Fixed in rev. 1.110 of sys/netinet/tcp_syncache.c. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 18:26:53 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B5CC16A400 for ; Tue, 17 Apr 2007 18:26:53 +0000 (UTC) (envelope-from bill.marquette@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 126EF13C483 for ; Tue, 17 Apr 2007 18:26:52 +0000 (UTC) (envelope-from bill.marquette@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so200060ugh for ; Tue, 17 Apr 2007 11:26:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RYSoHNttssOzb65ibbjPX1AqhPNIag8rMmQp7+HismnrvgfTS/OVo9yA7WZnFf0nLcXtG50wh+0GzrMK129IwMA/ERBV2WnFqTiFOq2knuftP2twpixQ94BsYoDhKCLpQEQPXgpkHXnJYmygSeGSfhCbc6OjHdef3M9ZwcLg2DM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IzDARmme0OW3pNd0KiUFU7yloVo8QaR8Ff4KqBBUyML9FoYsTZH2UFznPdr89bmuXOVMw1B0gtTXGTxOsHmgfiI6BVHd/V060R+r9hjEw8pz35382EnbS1m8DBepVJJtLFzBXeeZseXzT36el/D7UDnCHVve3aNOQP3V8rBiOBU= Received: by 10.67.97.7 with SMTP id z7mr655167ugl.1176832829535; Tue, 17 Apr 2007 11:00:29 -0700 (PDT) Received: by 10.67.48.2 with HTTP; Tue, 17 Apr 2007 11:00:29 -0700 (PDT) Message-ID: <55e8a96c0704171100v2222eed4g606a8f5f25f2c06b@mail.gmail.com> Date: Tue, 17 Apr 2007 13:00:29 -0500 From: "Bill Marquette" To: freebsd-net@freebsd.org In-Reply-To: <55e8a96c0704171025n4a3a8893s912886f6cfd7b36a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <55e8a96c0704171025n4a3a8893s912886f6cfd7b36a@mail.gmail.com> Subject: Fwd: ng_tag and pf? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 18:26:53 -0000 Forwarding to -net to get a larger audience. Any help would be appreciated. Thanks --Bill ---------- Forwarded message ---------- From: Bill Marquette Date: Apr 17, 2007 12:25 PM Subject: ng_tag and pf? To: "freebsd-pf@freebsd.org" Is it possible to use ng_tag in conjunction with pf? I have a setup in OpenBSD currently where I use the bridge interface to apply a tag to a packet based on the mac address so that when pf gets the packet it can apply a reply-to rule to it to keep traffic flows symmetric (the upstream device(s) also keep state, so the reply path has to be the same). I'm looking to duplicate this in FreeBSD with pf and I think ng_tag and maybe ng_bpf can make this happen, but I'm at a bit of a loss as to how at this point. Any pointers or at least a "yes it's absolutely possible, figure it out and let us know the exact config" answer would be very much appreciated. Thanks --Bill From owner-freebsd-net@FreeBSD.ORG Tue Apr 17 19:08:29 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9059616A403 for ; Tue, 17 Apr 2007 19:08:29 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from webmail24.mail.yandex.net (webmail24.mail.yandex.net [213.180.223.151]) by mx1.freebsd.org (Postfix) with ESMTP id 08D9613C45E for ; Tue, 17 Apr 2007 19:08:28 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (webmail24) by mail.yandex.ru id S491645AbXDQSzt for ; Tue, 17 Apr 2007 22:55:49 +0400 Received: from [82.211.152.12] ([82.211.152.12]) by mail.yandex.ru with HTTP; Tue, 17 Apr 2007 22:55:49 +0400 From: "Andrey V. Elsukov" To: bill.marquette@gmail.com MIME-Version: 1.0 Message-Id: <89271176836149@webmail24.yandex.ru> Date: Tue, 17 Apr 2007 22:55:49 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: freebsd-net@freebsd.org Subject: Re: ng_tag and pf? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 19:08:29 -0000 > Is it possible to use ng_tag in conjunction with pf? I have a setup At this time it's impossible. You can use ng_tag(4) in conjunction with ipfw(4). -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 00:43:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07C3116A402 for ; Wed, 18 Apr 2007 00:43:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA6613C45E for ; Wed, 18 Apr 2007 00:43:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so1515835pyh for ; Tue, 17 Apr 2007 17:43:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=pj3VVqjTkQJsfzsfZkHcYfWxNsdGWNRnBkp5uDLra+wfmdP3R90JCLuGqcx412xF1DuQITIhgGXdC+qZ6JVqwa7d9C4RYUn2b4zsK4KCyMmWwxApVCspF/WbtSeIXM+Qs80H1h7KmF39+I34YwtMwt+laJ7YzcLqRonGc2oj+rE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=PszUt6dmBPaia5V1cGhqbHkxxm4LZbugtpwLpoW7twuw2/TPFjnnshst43c0jZqBZv7izyRU0M2FfRQFOfvfmXAB/rrF4HZu5xSRl+TrLkbeTSxW79P0dWsgumqd1Z/Yl7Pj02iljQTvJn8T2iLv7+nGypSvNcCSBo48t3FTIJY= Received: by 10.65.61.16 with SMTP id o16mr15940309qbk.1176857003831; Tue, 17 Apr 2007 17:43:23 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTP id 16sm24402666nzo.2007.04.17.17.43.19; Tue, 17 Apr 2007 17:43:22 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l3I0i22Y030961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Apr 2007 09:44:02 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l3I0i1uS030960; Wed, 18 Apr 2007 09:44:01 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 18 Apr 2007 09:44:01 +0900 From: Pyun YongHyeon To: "Prokofiev S.P." Message-ID: <20070418004401.GB30554@cdnetworks.co.kr> References: <20070413104122.I17217@logos.uptel.net> <20070414030556.GA12777@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070414030556.GA12777@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Hang up/down re0: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 00:43:25 -0000 On Sat, Apr 14, 2007 at 12:05:56PM +0900, To Prokofiev S.P. wrote: > On Fri, Apr 13, 2007 at 11:48:15AM +0300, Prokofiev S.P. wrote: > > > > I have a problem on FreeBSD 6.2-STABLE with NIC D-Link DGE-528(T). > > When I put interface into promiscuous mode or output by tcpdump or simply > > ifconfig xxx promisc/ifconfig xxx -promisc, the NIC hang down and then hang > > up. > > This is not normal behaviour... > > Please try attached patch and let me know the result. > Thanks. For a record, patch committed. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 01:05:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A049F16A400 for ; Wed, 18 Apr 2007 01:05:28 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 65B8113C43E for ; Wed, 18 Apr 2007 01:05:28 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 79A025C19; Wed, 18 Apr 2007 11:05:27 +1000 (EST) From: Alan Garfield To: Peter Jeremy In-Reply-To: <20070417120058.GN1624@turion.vk2pj.dyndns.org> References: <1176781003.6367.12.camel@hiro.auspc.com.au> <20070417120058.GN1624@turion.vk2pj.dyndns.org> Content-Type: text/plain Date: Wed, 18 Apr 2007 11:05:27 +1000 Message-Id: <1176858327.4426.9.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: fake MAC addresses and ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 01:05:28 -0000 On Tue, 2007-04-17 at 22:00 +1000, Peter Jeremy wrote: > On 2007-Apr-17 13:36:43 +1000, Alan Garfield wrote: > >I've got a little driver that communicates via a small buffer on the > >motherboard of a Sun Fire V20z to a built-in "service processor" which > >is running Linux. The driver on both sides makes the buffer look like a > >Ethernet interface. > > I'd be interested in using this. Yeah it's going to be pretty handy. I'm also going to port the Poci control daemon too, which should allow FreeBSD to be controlled via the SP. If you'd like to look/test the code just pop me an email. Once I figure out the license requirements I'm hoping to have it added to FreeBSD HEAD. > >The Linux driver I'm porting simply grabbed any outgoing arp requests, > >made up an appropriate response with the pre-defined fake MAC's, put it > >into the input queue and ate the request packet. > > A quick-and-dirty work-around would seem to be > arp -s 169.254.101.2 Fa:ke:ma:cA:dd:re:ss Tried that, I get :- set: can only proxy for 169.254.101.2 .... and it still doesn't work! :) > Otherwise, I think you would need to fiddle with the transmit packet > code in your driver. Yeah, I'm beginning to think this will be the case and that I'm starting to hate ARP and the lack of kernel docs on the subject. Thanks, Alan. From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 01:50:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2D1916A482 for ; Wed, 18 Apr 2007 01:50:10 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6411313C45E for ; Wed, 18 Apr 2007 01:50:10 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id A6C655C64 for ; Wed, 18 Apr 2007 11:50:09 +1000 (EST) From: Alan Garfield To: freebsd-net@freebsd.org Content-Type: text/plain Date: Wed, 18 Apr 2007 11:50:09 +1000 Message-Id: <1176861009.4426.21.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Subject: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 01:50:10 -0000 Hi all! One word.... HOW! :) I've no clue what this FreeBSD ARP stuff is all about, there is little or no documentation, there are 14 different sock_addr's which seem to have a bazillion different fields, and I cannot output a simple debug statement without getting 'error: dereferencing pointer to incomplete type' errors! Sorry for the rant, I'm just frustrated. :) I've been going great on this port, but now I've struck ARP and have been stuck for days and I cannot seem to get myself out no matter how much kernel code I grep it still all looks Greek to me. I understand what ARP is and how it does it's thing. I even understand how Linux does it, but I cannot get a handle on how/why FreeBSD does what it does. Can someone point me in the direction or give an example to output debug from an rtrequest method. Currently I've got :- ---- static void jnet_rtrequest(int cmd, struct rtentry *rt, struct rt_addrinfo *info) { struct ifnet *ifp = rt->rt_ifp; struct jnet_softc *sc = ifp->if_softc; RT_LOCK_ASSERT(rt); switch (cmd) { case RTM_ADD: device_printf(sc->dev, "RTM_ADD. \n"); if (SIN(rt_key(rt))->sin_family == AF_INET) { device_printf(sc->dev, "AF_INET \n"); } break; case RTM_RESOLVE: device_printf(sc->dev, "RTM_RESOLVE. \n"); break; case RTM_DELETE: device_printf(sc->dev, "RTM_DELETE. \n"); break; } rt->rt_rmx.rmx_mtu = rt->rt_ifp->if_mtu; } ---- I just want an idea of the structures involved, and what I need to implement to intercept and injecting a fake MAC so my buffer driver can communicate with the other side without ARP errors. Any help would be more than appreciated (eg. I'd I'll buy you a case of beer next time you're in Sydney Australia). Thanks, Alan. From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 07:36:37 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A877016A402 for ; Wed, 18 Apr 2007 07:36:37 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235]) by mx1.freebsd.org (Postfix) with ESMTP id 6AFFE13C46C for ; Wed, 18 Apr 2007 07:36:37 +0000 (UTC) (envelope-from ivo.vachkov@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so65605wxc for ; Wed, 18 Apr 2007 00:36:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cCTbMK5TvKzKFFISIXjy6qm0PamX6TK8TkHMQKu5A8eco//xy4owndVICut42N7yJavAjbR/V09AztdidloRtuGPQz+D5jGNRNX1w4DUwpSDlfWQuSLuw1TDMU5tO9Ijg3lqOsOXe8xrx5oyFdBsuZobWeRUv4rNYS0eZCD4LKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aGegZJ18obSjDFfkt7S109lbUJSMLzF4OEhvYzB0NPM8RwL3OFoKpB8HJeKll5nvQGJ9I484MObjUiQKSf01sIh5NQUpkK0E92Ye331QSJVIQUI53pg445bZMJS7DiftV4nHZjEPh0ljSMaQDsGAX6t1QLEaYnR5hYaSyTeROpE= Received: by 10.90.115.9 with SMTP id n9mr48334agc.1176880283241; Wed, 18 Apr 2007 00:11:23 -0700 (PDT) Received: by 10.90.119.8 with HTTP; Wed, 18 Apr 2007 00:11:23 -0700 (PDT) Message-ID: Date: Wed, 18 Apr 2007 10:11:23 +0300 From: "Ivo Vachkov" To: "Alan Garfield" In-Reply-To: <1176861009.4426.21.camel@hiro.auspc.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1176861009.4426.21.camel@hiro.auspc.com.au> Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 07:36:37 -0000 please, give us more info about the connection between ARP (address resolution protocol) and rtentry/rtrequest. about the debug information: man 9 printf man 9 log On 4/18/07, Alan Garfield wrote: > Hi all! > > One word.... HOW! :) > > I've no clue what this FreeBSD ARP stuff is all about, there is little > or no documentation, there are 14 different sock_addr's which seem to > have a bazillion different fields, and I cannot output a simple debug > statement without getting 'error: dereferencing pointer to incomplete > type' errors! > > Sorry for the rant, I'm just frustrated. :) I've been going great on > this port, but now I've struck ARP and have been stuck for days and I > cannot seem to get myself out no matter how much kernel code I grep it > still all looks Greek to me. > > I understand what ARP is and how it does it's thing. I even understand > how Linux does it, but I cannot get a handle on how/why FreeBSD does > what it does. > > Can someone point me in the direction or give an example to output debug > from an rtrequest method. Currently I've got :- > > ---- > static void > jnet_rtrequest(int cmd, struct rtentry *rt, struct rt_addrinfo > *info) > { > struct ifnet *ifp = rt->rt_ifp; > struct jnet_softc *sc = > ifp->if_softc; > > RT_LOCK_ASSERT(rt); > > switch (cmd) > { > > case > RTM_ADD: > device_printf(sc->dev, "RTM_ADD. \n"); > > if (SIN(rt_key(rt))->sin_family == AF_INET) > { > device_printf(sc->dev, "AF_INET > \n"); > } > > > break; > > case RTM_RESOLVE: > device_printf(sc->dev, "RTM_RESOLVE. > \n"); > > break; > > case RTM_DELETE: > device_printf(sc->dev, "RTM_DELETE. > \n"); > break; > } > > rt->rt_rmx.rmx_mtu = rt->rt_ifp->if_mtu; > } > ---- > > I just want an idea of the structures involved, and what I need to > implement to intercept and injecting a fake MAC so my buffer driver can > communicate with the other side without ARP errors. > > Any help would be more than appreciated (eg. I'd I'll buy you a case of > beer next time you're in Sydney Australia). > > Thanks, > Alan. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 12:55:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D8DA716A401 for ; Wed, 18 Apr 2007 12:55:49 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 4BE7013C487 for ; Wed, 18 Apr 2007 12:55:48 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3ICtjO5047049; Wed, 18 Apr 2007 16:55:45 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3IC6N1K046008; Wed, 18 Apr 2007 16:06:23 +0400 (MSD) (envelope-from yar) Date: Wed, 18 Apr 2007 16:06:23 +0400 From: Yar Tikhiy To: Alan Garfield Message-ID: <20070418120622.GF40826@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176861009.4426.21.camel@hiro.auspc.com.au> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 12:55:49 -0000 On Wed, Apr 18, 2007 at 11:50:09AM +1000, Alan Garfield wrote: > Hi all! > > One word.... HOW! :) > > I've no clue what this FreeBSD ARP stuff is all about, there is little > or no documentation, there are 14 different sock_addr's which seem to > have a bazillion different fields, and I cannot output a simple debug > statement without getting 'error: dereferencing pointer to incomplete > type' errors! > > Sorry for the rant, I'm just frustrated. :) I've been going great on > this port, but now I've struck ARP and have been stuck for days and I > cannot seem to get myself out no matter how much kernel code I grep it > still all looks Greek to me. > > I understand what ARP is and how it does it's thing. I even understand > how Linux does it, but I cannot get a handle on how/why FreeBSD does > what it does. > [...] > > I just want an idea of the structures involved, and what I need to > implement to intercept and injecting a fake MAC so my buffer driver can > communicate with the other side without ARP errors. Could you tell more details on the problem you are trying to solve now. Sorry, but I fail to see what errors you get, and why. Doesn't the Service Processor on the other side of that little Ethernet link behave as a conventional IP host? (Alan is writing a driver for the interface between the CPU and the Service Processor found in Sun Fire. Of course, FreeBSD runs on the CPU, while the SP executes a sort of Linux. The interface mimics Ethernet, but I don't know what lengths it goes to in doing so.) -- Yar From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 18:50:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1339C16A417 for ; Wed, 18 Apr 2007 18:50:24 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id E039713C4D3 for ; Wed, 18 Apr 2007 18:50:21 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id BAD2B217F26; Wed, 18 Apr 2007 14:50:34 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 18 Apr 2007 14:50:22 -0400 X-Sasl-enc: B9ibPfFHSqHZgEMpwaq/msgiJoRF/GB0FKiF6+PaVTWX 1176922220 Received: from [212.50.171.200] (unknown [212.50.171.200]) by mail.messagingengine.com (Postfix) with ESMTP id D079910E1A; Wed, 18 Apr 2007 14:50:19 -0400 (EDT) Message-ID: <46266861.8040907@incunabulum.net> Date: Wed, 18 Apr 2007 19:50:09 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alan Garfield References: <1176781003.6367.12.camel@hiro.auspc.com.au> In-Reply-To: <1176781003.6367.12.camel@hiro.auspc.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: fake MAC addresses and ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 18:50:24 -0000 Some ideas: 1. Enable IFF_STATICARP on your interface to stop ARP sending out to resolve the IP/MAC address tuple. 2. Consider that you can deal with resolution in userland (RTF_RESOLVE) but this involves changing the net's entry (route) in the FTE. You'd then process RTM_RESOLVE messages and install routes yourself -- it's possible to do arp in userland with this. 3. Try to avoid using the 169.254.0.0/16 prefix as it has a specific meaning. We don't implement interface scoping for these addresses yet so the FTE can't deal with them appearing more than once for the same subnet; it may be easier to pick something else -- note that if ARP is enabled for an interface with one of these addresses, all ARP traffic is forced to be broadcast as per the zeroconf RFCs. BMS From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 18:56:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18C5016A403 for ; Wed, 18 Apr 2007 18:56:56 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id E830F13C459 for ; Wed, 18 Apr 2007 18:56:55 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 28B76218013; Wed, 18 Apr 2007 14:57:09 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 18 Apr 2007 14:56:56 -0400 X-Sasl-enc: UA4ta46bCYidKw01TOMlzTgtoXKlpqlRSpw+QpE2jfhf 1176922614 Received: from [212.50.171.200] (unknown [212.50.171.200]) by mail.messagingengine.com (Postfix) with ESMTP id AA30A130FA; Wed, 18 Apr 2007 14:56:53 -0400 (EDT) Message-ID: <462669EB.7090705@incunabulum.net> Date: Wed, 18 Apr 2007 19:56:43 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alan Garfield References: <1176861009.4426.21.camel@hiro.auspc.com.au> In-Reply-To: <1176861009.4426.21.camel@hiro.auspc.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 18:56:56 -0000 Alan Garfield wrote: > Hi all! > > One word.... HOW! :) > > I've no clue what this FreeBSD ARP stuff is all about, there is little > or no documentation, there are 14 different sock_addr's which seem to > have a bazillion different fields, and I cannot output a simple debug > statement without getting 'error: dereferencing pointer to incomplete > type' errors! > The ARP code is pretty well documented in TCP/IP Illustrated Volume 2 and hasn't really significantly changed. Whilst I personally dislike how reentry happens in some of the paths, it works. In BSD, ARP lives in the routing table, which can be confusing to newcomers; such entries have the RTF_LLINFO flag set. From the sounds of it, if you are having to fake MAC addresses, you would be better off just enabling static mode ARP on the interface, possibly also enabling IFF_SMART ('manages own routes') on your interface and explicitly purging and re-adding your ARP entries from within your driver rather than trying to hack the rtrequest code to munge things on the fly. arp_rtrequest() is driver-independent code and will get hooked up to your code anyway when the net/ framework notices that your driver is one of IFT_ETHER. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 21:07:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7BEF16A402 for ; Wed, 18 Apr 2007 21:07:18 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 60B3D13C45D for ; Wed, 18 Apr 2007 21:07:18 +0000 (UTC) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 984FF1CC58; Thu, 19 Apr 2007 09:07:16 +1200 (NZST) Date: Thu, 19 Apr 2007 09:07:16 +1200 From: Andrew Thompson To: freebsd-net@freebsd.org Message-ID: <20070418210716.GB325@heff.fud.org.nz> References: <200704170035.l3H0ZBqE026989@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200704170035.l3H0ZBqE026989@repoman.freebsd.org> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: cvs commit: src/sbin/ifconfig Makefile ifconfig.8 iflagg.c iftrunk.c src/share/man/man4 Makefile lagg.4 trunk.4 src/sys/modules Makefile src/sys/modules/if_lagg Makefile src/sys/modules/if_trunk Makefile src/sys/conf NOTES files ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 21:07:18 -0000 Please note the following change. trunk was only in HEAD for a week so the few people who tried it out already need to be aware of the name change. Andrew On Tue, Apr 17, 2007 at 12:35:11AM +0000, Andrew Thompson wrote: > thompsa 2007-04-17 00:35:11 UTC > > FreeBSD src repository > > Modified files: > sbin/ifconfig Makefile ifconfig.8 > share/man/man4 Makefile > sys/modules Makefile > sys/conf NOTES files > sys/sys priv.h > sys/net ieee8023ad_lacp.c ieee8023ad_lacp.h if.c > if_ethersubr.c if_var.h > Added files: > sbin/ifconfig iflagg.c > share/man/man4 lagg.4 > sys/modules/if_lagg Makefile > sys/net if_lagg.c if_lagg.h > Removed files: > sbin/ifconfig iftrunk.c > share/man/man4 trunk.4 > sys/modules/if_trunk Makefile > sys/net if_trunk.c if_trunk.h > Log: > Rename the trunk(4) driver to lagg(4) as it is too similar to vlan trunking. > > The name trunk is misused as the networking term trunk means carrying multiple > VLANs over a single connection. The IEEE standard for link aggregation (802.3 > section 3) does not talk about 'trunk' at all while it is used throughout IEEE > 802.1Q in describing vlans. > > The lagg(4) driver provides link aggregation, failover and fault tolerance. > > Discussed on: current@ From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 01:56:57 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F128516A403 for ; Thu, 19 Apr 2007 01:56:57 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 7B8A913C46C for ; Thu, 19 Apr 2007 01:56:57 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 4F5DF5C19; Thu, 19 Apr 2007 11:56:54 +1000 (EST) From: Alan Garfield To: Yar Tikhiy In-Reply-To: <20070418120622.GF40826@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> Content-Type: text/plain Date: Thu, 19 Apr 2007 11:56:54 +1000 Message-Id: <1176947814.4175.39.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 01:56:58 -0000 On Wed, 2007-04-18 at 16:06 +0400, Yar Tikhiy wrote: > > > I just want an idea of the structures involved, and what I need to > > implement to intercept and injecting a fake MAC so my buffer driver can > > communicate with the other side without ARP errors. > > Could you tell more details on the problem you are trying to solve > now. Sorry, but I fail to see what errors you get, and why. Doesn't > the Service Processor on the other side of that little Ethernet > link behave as a conventional IP host? Well it sort of does and it sort of doesn't unfortunately. It's MAC addresses are faked in the driver on both sides, and any ARP requests are caught and a fake response is generated. It's a wee bit ugly. >From the GPL Linux driver ---- int jnet_tx(struct sk_buff *skb, struct net_device *dev) { [...] if(htons(eth->h_proto) == ETH_P_ARP && arp->ar_op == ARPOP_REQUEST) { //send fake response. jnet_arpResponse(dev); netif_wake_queue(jnet_devs); priv->fifoFull = FALSE; dev_kfree_skb(skb); // Free the SKB for arps too. } else { //so send the data [...] } } ---- void jnet_arpResponse( struct net_device *dev ) { [...] //Fill in all the blanks. memcpy(ðArp.eth.h_dest, localMac, sizeof(localMac)); memcpy(ðArp.eth.h_source, remoteMac, sizeof(remoteMac)); ethArp.eth.h_proto = ETH_P_ARP; ethArp.arp.ar_hrd = htons(ARPHRD_ETHER); ethArp.arp.ar_pro = htons(ETH_P_IP); ethArp.arp.ar_hln = sizeof(localMac); ethArp.arp.ar_pln = sizeof(uint32_t); ethArp.arp.ar_op = htons(ARPOP_REPLY); memcpy(ðArp.ar_sha, remoteMac, sizeof(remoteMac)); memcpy(ðArp.ar_sip, &priv->myConfigIpSettings.platIp, sizeof(uint32_t)); memcpy(ðArp.ar_tha, localMac, sizeof(localMac)); memcpy(ðArp.ar_tip, &priv->myConfigIpSettings.spIp, sizeof(uint32_t)); [...] } ---- The problem I'm really seeing is I'm getting no mbuf's in my jnet_start(). It always returns zero. ---- static void jnet_start_locked(struct ifnet* ifp) { // {{{ struct jnet_softc *sc = ifp->if_softc; struct mbuf *m0, *m; device_printf(sc->dev, "jnet_start_locked() called.\n"); JNET_ASSERT_LOCKED(sc); outputloop: // Check if there are buffered packets and an we're idle which // shouldn't happen at this point if (sc->txb_inuse && (sc->tx_busy == 0)) { device_printf(sc->dev, "packets buffered, but tx idle.\n"); jnet_tx(sc); } // Check if there is room to put another packet in the buffer. if (sc->txb_inuse == sc->txb_cnt) { device_printf(sc->dev, "No room left in tx buffer.\n"); // No room left. Set OACTIVE to tell everyone ifp->if_drv_flags |= IFF_DRV_OACTIVE; return; } IFQ_DRV_DEQUEUE(&ifp->if_snd, m); if (m == 0) { device_printf(sc->dev, "m == 0.\n"); // If buffers aren't filled we can still accept // more packets. So reset OACTIVE ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; return; } // Copy mbuf to PRS m0 = m; //set address counter to zero, then read the entire fifo //bus_space_write_1(sc->iot[JNET_IOREGS], sc->ioh[JNET_IOREGS], JNET_STS_OFFSET, 0x00); device_printf(sc->dev, "mbuf len: %i.\n", m0->m_len); // Output to PRS buffer [...] sc->txb_inuse++; m_freem(m0); // Loop to top to possibly buffer more packets goto outputloop; // }}} } ---- ... and I get these ARP errors. ---- jnet0: port 0xa8,0xae-0xaf irq 19 on acpi0 jnet0: Ethernet address: 00:09:3d:00:00:03 jnet0: jnet_start_locked() called. jnet0: m == 0. jnet0: RTM_ADD. arplookup 169.254.101.2 failed: could not allocate llinfo arpresolve: can't allocate route for 169.254.101.2 ---- ... whenever I try and send anything. Many thanks for you continued help. Alan. From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 02:01:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB61E16A400 for ; Thu, 19 Apr 2007 02:01:10 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 8120B13C455 for ; Thu, 19 Apr 2007 02:01:10 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id D1A265C19; Thu, 19 Apr 2007 12:01:09 +1000 (EST) From: Alan Garfield To: "Bruce M. Simpson" In-Reply-To: <46266861.8040907@incunabulum.net> References: <1176781003.6367.12.camel@hiro.auspc.com.au> <46266861.8040907@incunabulum.net> Content-Type: text/plain Date: Thu, 19 Apr 2007 12:01:09 +1000 Message-Id: <1176948069.4175.44.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: fake MAC addresses and ARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 02:01:10 -0000 On Wed, 2007-04-18 at 19:50 +0100, Bruce M. Simpson wrote: > Some ideas: > > 1. Enable IFF_STATICARP on your interface to stop ARP sending out to > resolve the IP/MAC address tuple. I'll try this. > 2. Consider that you can deal with resolution in userland (RTF_RESOLVE) > but this involves changing the net's entry (route) in the FTE. You'd > then process RTM_RESOLVE messages and install routes yourself -- it's > possible to do arp in userland with this. Ok that's a little above my head, but I'll look into it. :) The IP addresses and such are setup by a userland task already. So having to adjust ARP wouldn't be out of the question. > 3. Try to avoid using the 169.254.0.0/16 prefix as it has a specific > meaning. We don't implement interface scoping for these addresses yet so > the FTE can't deal with them appearing more than once for the same > subnet; it may be easier to pick something else -- note that if ARP is > enabled for an interface with one of these addresses, all ARP traffic is > forced to be broadcast as per the zeroconf RFCs. Unfortunately that's the IP addresses the little SP on the motherboard is coded to use. It can be changed after the userland task starts and configures both interfaces by the back-channel traffic over the interface, but I can't really get away from this subnet, the manufacturer has picked it. :( Seemed a little silly to me too. Thanks, -A. From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 02:43:58 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3E5F16A400 for ; Thu, 19 Apr 2007 02:43:58 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id AC06C13C4AE for ; Thu, 19 Apr 2007 02:43:58 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 0090C5D25 for ; Thu, 19 Apr 2007 12:43:57 +1000 (EST) From: Alan Garfield To: freebsd-net@freebsd.org Content-Type: text/plain Date: Thu, 19 Apr 2007 12:43:57 +1000 Message-Id: <1176950637.4175.59.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 02:43:59 -0000 On Wed, 2007-04-18 at 19:56 +0100, Bruce M. Simpson wrote: > The ARP code is pretty well documented in TCP/IP Illustrated Volume 2 > and hasn't really significantly changed. Whilst I personally dislike how > reentry happens in some of the paths, it works. Might have to this book to my collection. The information available on the net isn't all that conclusive (when is it ever :). > In BSD, ARP lives in the > routing table, which can be confusing to newcomers; such entries have > the RTF_LLINFO flag set. You're telling me about confusing to newcomers! :) > From the sounds of it, if you are having to fake MAC addresses, you > would be better off just enabling static mode ARP on the interface, > possibly also enabling IFF_SMART ('manages own routes') on your > interface and explicitly purging and re-adding your ARP entries from > within your driver rather than trying to hack the rtrequest code to > munge things on the fly. arp_rtrequest() is driver-independent code and > will get hooked up to your code anyway when the net/ framework notices > that your driver is one of IFT_ETHER. This sounds like the right way. I think static ARP and IFF_SMART would fix my little issue. Are there any examples of using IFF_SMART in the kernel code base? Thanks, Alan. From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 07:35:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0819C16A401 for ; Thu, 19 Apr 2007 07:35:31 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 4EBD013C44B for ; Thu, 19 Apr 2007 07:35:30 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3J7ZRua084357; Thu, 19 Apr 2007 11:35:27 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3J7ZQZt084355; Thu, 19 Apr 2007 11:35:26 +0400 (MSD) (envelope-from yar) Date: Thu, 19 Apr 2007 11:35:25 +0400 From: Yar Tikhiy To: Alan Garfield Message-ID: <20070419073525.GA60301@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176947814.4175.39.camel@hiro.auspc.com.au> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 07:35:31 -0000 On Thu, Apr 19, 2007 at 11:56:54AM +1000, Alan Garfield wrote: > On Wed, 2007-04-18 at 16:06 +0400, Yar Tikhiy wrote: > > > > > I just want an idea of the structures involved, and what I need to > > > implement to intercept and injecting a fake MAC so my buffer driver can > > > communicate with the other side without ARP errors. > > > > Could you tell more details on the problem you are trying to solve > > now. Sorry, but I fail to see what errors you get, and why. Doesn't > > the Service Processor on the other side of that little Ethernet > > link behave as a conventional IP host? > > Well it sort of does and it sort of doesn't unfortunately. It's MAC > addresses are faked in the driver on both sides, and any ARP requests > are caught and a fake response is generated. It's a wee bit ugly. I wonder if this hack can be avoided... The other side could just respond to our ARP requests. > >From the GPL Linux driver > ---- > > int jnet_tx(struct sk_buff *skb, struct net_device *dev) > { > > [...] > > if(htons(eth->h_proto) == ETH_P_ARP && > arp->ar_op == ARPOP_REQUEST) { > //send fake response. > jnet_arpResponse(dev); > netif_wake_queue(jnet_devs); > priv->fifoFull = FALSE; > dev_kfree_skb(skb); // Free the SKB for arps too. > } else { > //so send the data > > [...] > } > } > > ---- > > void jnet_arpResponse( struct net_device *dev ) > { > > [...] > > //Fill in all the blanks. > memcpy(ðArp.eth.h_dest, localMac, sizeof(localMac)); > memcpy(ðArp.eth.h_source, remoteMac, sizeof(remoteMac)); > ethArp.eth.h_proto = ETH_P_ARP; > > ethArp.arp.ar_hrd = htons(ARPHRD_ETHER); > ethArp.arp.ar_pro = htons(ETH_P_IP); > ethArp.arp.ar_hln = sizeof(localMac); > ethArp.arp.ar_pln = sizeof(uint32_t); > ethArp.arp.ar_op = htons(ARPOP_REPLY); > > memcpy(ðArp.ar_sha, remoteMac, sizeof(remoteMac)); > memcpy(ðArp.ar_sip, &priv->myConfigIpSettings.platIp, > sizeof(uint32_t)); > > memcpy(ðArp.ar_tha, localMac, sizeof(localMac)); > memcpy(ðArp.ar_tip, &priv->myConfigIpSettings.spIp, > sizeof(uint32_t)); > > [...] > > } > > ---- > > The problem I'm really seeing is I'm getting no mbuf's in my > jnet_start(). It always returns zero. > > ---- > > static void > jnet_start_locked(struct ifnet* ifp) > { > // {{{ > struct jnet_softc *sc = ifp->if_softc; > > struct mbuf *m0, *m; > > device_printf(sc->dev, "jnet_start_locked() called.\n"); > > JNET_ASSERT_LOCKED(sc); > > outputloop: > > // Check if there are buffered packets and an we're idle which > // shouldn't happen at this point > if (sc->txb_inuse && (sc->tx_busy == 0)) { > device_printf(sc->dev, "packets buffered, but tx > idle.\n"); > jnet_tx(sc); > } > > // Check if there is room to put another packet in the buffer. > if (sc->txb_inuse == sc->txb_cnt) { > > device_printf(sc->dev, "No room left in tx buffer.\n"); > > // No room left. Set OACTIVE to tell everyone > ifp->if_drv_flags |= IFF_DRV_OACTIVE; > return; > } > > IFQ_DRV_DEQUEUE(&ifp->if_snd, m); > > if (m == 0) { > > device_printf(sc->dev, "m == 0.\n"); > > // If buffers aren't filled we can still accept > // more packets. So reset OACTIVE > ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; > return; > } > > // Copy mbuf to PRS > m0 = m; > > //set address counter to zero, then read the entire fifo > //bus_space_write_1(sc->iot[JNET_IOREGS], sc->ioh[JNET_IOREGS], > JNET_STS_OFFSET, 0x00); > > > device_printf(sc->dev, "mbuf len: %i.\n", m0->m_len); > > // Output to PRS buffer > [...] > > sc->txb_inuse++; > > m_freem(m0); > > // Loop to top to possibly buffer more packets > goto outputloop; > > > // }}} > } > > ---- > > ... and I get these ARP errors. > > ---- > jnet0: port 0xa8,0xae-0xaf irq 19 on > acpi0 > jnet0: Ethernet address: 00:09:3d:00:00:03 > jnet0: jnet_start_locked() called. > jnet0: m == 0. > jnet0: RTM_ADD. > arplookup 169.254.101.2 failed: could not allocate llinfo > arpresolve: can't allocate route for 169.254.101.2 > ---- > > ... whenever I try and send anything. Did you set the maximum lengths for the output queue and the driver queue in the attach function? -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 08:54:25 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 443FA16A400 for ; Thu, 19 Apr 2007 08:54:25 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 09D0C13C465 for ; Thu, 19 Apr 2007 08:54:24 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 55DFA5D66; Thu, 19 Apr 2007 18:54:24 +1000 (EST) From: Alan Garfield To: Yar Tikhiy In-Reply-To: <20070419073525.GA60301@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> Content-Type: text/plain Date: Thu, 19 Apr 2007 18:54:23 +1000 Message-Id: <1176972863.4177.7.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 08:54:25 -0000 On Thu, 2007-04-19 at 11:35 +0400, Yar Tikhiy wrote: > > ... and I get these ARP errors. > > > > ---- > > jnet0: port 0xa8,0xae-0xaf irq 19 on > > acpi0 > > jnet0: Ethernet address: 00:09:3d:00:00:03 > > jnet0: jnet_start_locked() called. > > jnet0: m == 0. > > jnet0: RTM_ADD. > > arplookup 169.254.101.2 failed: could not allocate llinfo > > arpresolve: can't allocate route for 169.254.101.2 > > ---- > > > > ... whenever I try and send anything. > > Did you set the maximum lengths for the output queue and the driver > queue in the attach function? ---- // Configure the structure for the device ifp->if_softc = sc; if_initname(ifp, device_get_name(dev), device_get_unit(dev)); // Function pointers ifp->if_start = jnet_start; ifp->if_ioctl = jnet_ioctl; ifp->if_watchdog = jnet_watchdog; ifp->if_init = jnet_init; // Interface specifics ifp->if_flags = IFF_SIMPLEX; IFQ_SET_MAXLEN(&ifp->if_snd, IFQ_MAXLEN); ifp->if_snd.ifq_drv_maxlen = IFQ_MAXLEN; IFQ_SET_READY(&ifp->if_snd); ifp->if_timer = MAX_TIMEOUT; // Set our fake MAC address bcopy(localMac, sc->enaddr, 6); // Attach the ethernet interface ether_ifattach(ifp, sc->enaddr); // Reset the mtu ifp->if_mtu = JNET_MTU; ---- I think so. :) I beginning to think the ARP issue is a symptom not the cause. The cause may well be something is wrong with my initialisation of the output queue and my handling of the de-queueing packets. I've looked at many if_* drivers sources and they all seem very similar to what I've already done. -A. From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 09:38:57 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02AE416A401 for ; Thu, 19 Apr 2007 09:38:57 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 539FC13C45B for ; Thu, 19 Apr 2007 09:38:56 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3J9cmKo089623; Thu, 19 Apr 2007 13:38:48 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3J9clIp089620; Thu, 19 Apr 2007 13:38:47 +0400 (MSD) (envelope-from yar) Date: Thu, 19 Apr 2007 13:38:47 +0400 From: Yar Tikhiy To: Alan Garfield Message-ID: <20070419093847.GC60301@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176972863.4177.7.camel@hiro.auspc.com.au> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 09:38:57 -0000 On Thu, Apr 19, 2007 at 06:54:23PM +1000, Alan Garfield wrote: > On Thu, 2007-04-19 at 11:35 +0400, Yar Tikhiy wrote: > > > > ... and I get these ARP errors. > > > > > > ---- > > > jnet0: port 0xa8,0xae-0xaf irq 19 on > > > acpi0 > > > jnet0: Ethernet address: 00:09:3d:00:00:03 > > > jnet0: jnet_start_locked() called. > > > jnet0: m == 0. > > > jnet0: RTM_ADD. > > > arplookup 169.254.101.2 failed: could not allocate llinfo > > > arpresolve: can't allocate route for 169.254.101.2 > > > ---- > > > > > > ... whenever I try and send anything. > > > > Did you set the maximum lengths for the output queue and the driver > > queue in the attach function? > > ---- > // Configure the structure for the device > ifp->if_softc = sc; > if_initname(ifp, device_get_name(dev), device_get_unit(dev)); > > // Function pointers > ifp->if_start = jnet_start; > ifp->if_ioctl = jnet_ioctl; > ifp->if_watchdog = jnet_watchdog; > ifp->if_init = jnet_init; > > // Interface specifics > ifp->if_flags = IFF_SIMPLEX; Try setting those flags to IFF_SIMPLEX | IFF_BROADCAST | IFF_MULTICAST I have no direct evidence, but ARP may have trouble operating on an interface w/o IFF_BROADCAST, as it utilizes broadcasts. Essentially, IFF_BROADCAST just means that the interface has a broadcast address, but there may be some indirect consequences via the routing table. Anyway, an Ethernet interface ought to have IFF_BROADCAST set on it because it's a broadcast interface. > IFQ_SET_MAXLEN(&ifp->if_snd, IFQ_MAXLEN); > ifp->if_snd.ifq_drv_maxlen = IFQ_MAXLEN; > IFQ_SET_READY(&ifp->if_snd); > ifp->if_timer = MAX_TIMEOUT; > > // Set our fake MAC address > bcopy(localMac, sc->enaddr, 6); Just a style note: the 6 should be ETHER_ADDR_LEN. We prefer ETHER_ADDR_LEN to sizeof(...) because sizeof returns size_t, while an int is sometimes needed. (int and size_t have different width on 64-bit architectures.) ETHER_ADDR_LEN expands to the constant 6, which gets the correct type provided that the function has been prototyped. > // Attach the ethernet interface > ether_ifattach(ifp, sc->enaddr); > > // Reset the mtu > ifp->if_mtu = JNET_MTU; > ---- > > I think so. :) > > I beginning to think the ARP issue is a symptom not the cause. The cause > may well be something is wrong with my initialisation of the output > queue and my handling of the de-queueing packets. I've looked at many > if_* drivers sources and they all seem very similar to what I've already > done. Please try fixing the interface flags. Could you also show output from "ifconfig jnetX" and "netstat -rn" after the interface has been configured (i.e., had IP assigned)? P.S. Was the name "jnet" inherited from the Linux driver? -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 09:51:16 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D90F816A400 for ; Thu, 19 Apr 2007 09:51:16 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 3772813C44C for ; Thu, 19 Apr 2007 09:51:15 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id CDA665C19; Thu, 19 Apr 2007 19:51:13 +1000 (EST) From: Alan Garfield To: Yar Tikhiy In-Reply-To: <20070419093847.GC60301@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> Content-Type: text/plain Date: Thu, 19 Apr 2007 19:51:13 +1000 Message-Id: <1176976273.4177.17.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 09:51:17 -0000 On Thu, 2007-04-19 at 13:38 +0400, Yar Tikhiy wrote: > > > ---- > > // Configure the structure for the device > > ifp->if_softc = sc; > > if_initname(ifp, device_get_name(dev), device_get_unit(dev)); > > > > // Function pointers > > ifp->if_start = jnet_start; > > ifp->if_ioctl = jnet_ioctl; > > ifp->if_watchdog = jnet_watchdog; > > ifp->if_init = jnet_init; > > > > // Interface specifics > > ifp->if_flags = IFF_SIMPLEX; > > > Try setting those flags to > IFF_SIMPLEX | IFF_BROADCAST | IFF_MULTICAST > > I have no direct evidence, but ARP may have trouble operating on > an interface w/o IFF_BROADCAST, as it utilizes broadcasts. Essentially, > IFF_BROADCAST just means that the interface has a broadcast address, > but there may be some indirect consequences via the routing table. Will do. I only removed them in the hope of finding what was wrong. I'll put them back. > Anyway, an Ethernet interface ought to have IFF_BROADCAST set on > it because it's a broadcast interface. > > > IFQ_SET_MAXLEN(&ifp->if_snd, IFQ_MAXLEN); > > ifp->if_snd.ifq_drv_maxlen = IFQ_MAXLEN; > > IFQ_SET_READY(&ifp->if_snd); > > ifp->if_timer = MAX_TIMEOUT; > > > > // Set our fake MAC address > > bcopy(localMac, sc->enaddr, 6); > > Just a style note: the 6 should be ETHER_ADDR_LEN. We prefer > ETHER_ADDR_LEN to sizeof(...) because sizeof returns size_t, while > an int is sometimes needed. (int and size_t have different width > on 64-bit architectures.) ETHER_ADDR_LEN expands to the constant > 6, which gets the correct type provided that the function has been > prototyped. Yep no problem. Easily fixed. I'm actually going through and fixing my style while I compute this problem in my head. :) > > I beginning to think the ARP issue is a symptom not the cause. The cause > > may well be something is wrong with my initialisation of the output > > queue and my handling of the de-queueing packets. I've looked at many > > if_* drivers sources and they all seem very similar to what I've already > > done. > > Please try fixing the interface flags. > > Could you also show output from "ifconfig jnetX" and "netstat -rn" > after the interface has been configured (i.e., had IP assigned)? ---- [alan@twofish jnet_pci]$ ifconfig bge0: flags=8843 mtu 1500 options=1b inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:09:3d:13:21:6a media: Ethernet autoselect (1000baseTX ) status: active bge1: flags=8802 mtu 1500 options=1b ether 00:09:3d:13:21:6b media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 jnet0: flags=845 mtu 241 inet 169.254.101.3 netmask 0xffff0000 ether 00:09:3d:00:00:03 ---- [alan@twofish jnet_pci]$ netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.1.1 UGS 0 192 bge0 127.0.0.1 127.0.0.1 UH 0 0 lo0 169.254 link#4 UC 0 0 jnet0 192.168.1 link#1 UC 0 0 bge0 192.168.1.1 00:17:95:ba:b8:a6 UHLW 2 0 bge0 37 192.168.1.8 00:04:76:3b:0a:57 UHLW 1 45 bge0 1199 192.168.1.99 00:15:58:2d:85:c7 UHLW 2 12188 bge0 1172 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#3 UHL lo0 ff01:3::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 ---- I think I've made a little break through! I've removed :- ---- case SIOCSIFADDR: ifp->if_flags |= IFF_UP; ifa = (struct ifaddr *)data; if (ifa != 0) ifa->ifa_rtrequest = jnet_rtrequest; break; ---- .... and now it seems like I'm actually getting mbuf's and no more ARP errors! ---- jnet0: port 0xa8,0xae-0xaf irq 19 on acpi0 jnet0: Ethernet address: 00:09:3d:00:00:03 jnet0: jnet_start_locked() called. jnet0: m == 0. jnet0: jnet_start_locked() called. jnet0: mbuf len: 42. jnet0: packets buffered, but tx idle. jnet0: TX called jnet0: m == 0. jnet0: jnet_start_locked() called. jnet0: packets buffered, but tx idle. jnet0: TX called jnet0: mbuf len: 42. jnet0: packets buffered, but tx idle. jnet0: TX called jnet0: m == 0. ---- So what did I do?!? Was my rtrequest function stuffing everything up, all it did was set the rt MTU and return. My tx just consumes the packets at the moment, I've not written the buffer writing code yet. I'll do that now and see if packets move. :) > P.S. Was the name "jnet" inherited from the Linux driver? Yeah it's what the Linux driver is called. Can be something else, got a better name? :) -A. From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 11:38:49 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AEB816A400 for ; Thu, 19 Apr 2007 11:38:49 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 5C73413C46A for ; Thu, 19 Apr 2007 11:38:48 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3JBcjOL092941; Thu, 19 Apr 2007 15:38:45 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3JBchYa092935; Thu, 19 Apr 2007 15:38:43 +0400 (MSD) (envelope-from yar) Date: Thu, 19 Apr 2007 15:38:42 +0400 From: Yar Tikhiy To: Alan Garfield Message-ID: <20070419113842.GE60301@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176976273.4177.17.camel@hiro.auspc.com.au> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 11:38:49 -0000 On Thu, Apr 19, 2007 at 07:51:13PM +1000, Alan Garfield wrote: [...] > > > > I beginning to think the ARP issue is a symptom not the cause. The cause > > > may well be something is wrong with my initialisation of the output > > > queue and my handling of the de-queueing packets. I've looked at many > > > if_* drivers sources and they all seem very similar to what I've already > > > done. > > > > Please try fixing the interface flags. > > > > Could you also show output from "ifconfig jnetX" and "netstat -rn" > > after the interface has been configured (i.e., had IP assigned)? > > ---- > [alan@twofish jnet_pci]$ ifconfig > bge0: flags=8843 mtu 1500 > options=1b > inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:09:3d:13:21:6a > media: Ethernet autoselect (1000baseTX ) > status: active > bge1: flags=8802 mtu 1500 > options=1b > ether 00:09:3d:13:21:6b > media: Ethernet autoselect (1000baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > jnet0: flags=845 mtu 241 > inet 169.254.101.3 netmask 0xffff0000 > ether 00:09:3d:00:00:03 Note that jnet0 has no broadcast address. That should be wrong for an Ethernet interface. (Honestly, I'm still uncertain whether it is legal at all for an interface to have none of the following flags: BROADCAST, POINTOPOINT, LOOPBACK.) > ---- > [alan@twofish jnet_pci]$ netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif > Expire > default 192.168.1.1 UGS 0 192 bge0 > 127.0.0.1 127.0.0.1 UH 0 0 lo0 > 169.254 link#4 UC 0 0 jnet0 ^^^^^^^^^ This record is there. Good... Note the C (cloning) flag. Individual ARP records will be "cloned" from this one via the rtresolve mechanism. > 192.168.1 link#1 UC 0 0 bge0 > 192.168.1.1 00:17:95:ba:b8:a6 UHLW 2 0 bge0 > 37 > 192.168.1.8 00:04:76:3b:0a:57 UHLW 1 45 bge0 > 1199 > 192.168.1.99 00:15:58:2d:85:c7 UHLW 2 12188 bge0 > 1172 > > Internet6: > Destination Gateway Flags > Netif Expire > ::1 ::1 UHL > lo0 > fe80::%lo0/64 fe80::1%lo0 U > lo0 > fe80::1%lo0 link#3 UHL > lo0 > ff01:3::/32 fe80::1%lo0 UC > lo0 > ff02::%lo0/32 fe80::1%lo0 UC > lo0 > ---- > > > I think I've made a little break through! I've removed :- > > ---- > case SIOCSIFADDR: > ifp->if_flags |= IFF_UP; > ifa = (struct ifaddr *)data; > if (ifa != 0) > ifa->ifa_rtrequest = jnet_rtrequest; > break; > ---- > > .... and now it seems like I'm actually getting mbuf's and no more ARP > errors! > > ---- > jnet0: port 0xa8,0xae-0xaf irq 19 on > acpi0 > jnet0: Ethernet address: 00:09:3d:00:00:03 > jnet0: jnet_start_locked() called. > jnet0: m == 0. > jnet0: jnet_start_locked() called. > jnet0: mbuf len: 42. > jnet0: packets buffered, but tx idle. > jnet0: TX called > jnet0: m == 0. > jnet0: jnet_start_locked() called. > jnet0: packets buffered, but tx idle. > jnet0: TX called > jnet0: mbuf len: 42. > jnet0: packets buffered, but tx idle. > jnet0: TX called > jnet0: m == 0. > ---- > > So what did I do?!? Was my rtrequest function stuffing everything up, > all it did was set the rt MTU and return. In fact, you were overriding the normal ARP's arp_rtrequest() handler for the addresses. Grep /sys/netinet/if_ether.c for ifa_rtrequest. See also rtentry(9) (again, search for ifa_rtrequest). That's why nothing worked. > My tx just consumes the packets at the moment, I've not written the > buffer writing code yet. I'll do that now and see if packets move. :) > > > P.S. Was the name "jnet" inherited from the Linux driver? > > Yeah it's what the Linux driver is called. Can be something else, got a > better name? :) Perhaps just "jn"? Some utilities still have trouble with long interface names[1], and they are a drag to type in. :-) So I'd rather keep the name as short as possible. -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 13:01:47 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CDA016A406 for ; Thu, 19 Apr 2007 13:01:47 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id BBBC113C45A for ; Thu, 19 Apr 2007 13:01:46 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 9A0951B10F96 for ; Thu, 19 Apr 2007 15:01:45 +0200 (CEST) Received: from [192.168.3.125] (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 9789D1B10ED2 for ; Thu, 19 Apr 2007 15:01:45 +0200 (CEST) Message-ID: <46276839.4090301@sun-fish.com> Date: Thu, 19 Apr 2007 16:01:45 +0300 From: Stefan Lambrev User-Agent: Thunderbird 1.5.0.10 (X11/20070326) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Subject: wpi driver. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stefan.lambrev@sun-fish.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 13:01:47 -0000 Hello, Are there any news about wpi driver ? Something that can be compiled on freebsd 6.2 stable ? I tried the latest drivers from http://www.clearchain.com/~benjsc/download, but no success :( I tried and from perforce but I've got this error: # make Warning: Object directory not changed from original /root/wpi/sys/modules/wpi @ -> /usr/src/sys machine -> /usr/src/sys/amd64/include :> opt_bdg.h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h cc -O2 -fno-strict-aliasing -pipe -g -DWITNESS -DINVARIANT_SUPPORT -DINVARIANTS -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/root/wpi/sys/modules/wpi/../../ -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c: In function `wpi_firmware_get': /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c:294: warning: assignment discards qualifiers from pointer target type *** Error code 1 Stop in /root/wpi/sys/modules/wpi. -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 13:03:48 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3C6216A403 for ; Thu, 19 Apr 2007 13:03:48 +0000 (UTC) (envelope-from proks@logos.uptel.net) Received: from logos.uptel.net (logos.uptel.net [195.138.170.125]) by mx1.freebsd.org (Postfix) with ESMTP id 6BFF913C480 for ; Thu, 19 Apr 2007 13:03:48 +0000 (UTC) (envelope-from proks@logos.uptel.net) Received: from logos.uptel.net (logos.uptel.net [195.138.170.125]) by logos.uptel.net (Postfix) with ESMTP id 181F433C83 for ; Thu, 19 Apr 2007 16:03:47 +0300 (EEST) Date: Thu, 19 Apr 2007 16:03:47 +0300 (EEST) From: "Prokofiev S.P." To: freebsd-net@freebsd.org Message-ID: <20070419160040.X17270@logos.uptel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: Hang up/down re0: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 13:03:48 -0000 Thanks for commit ! Problem with vlanhwtag is not only with ssh... I experimented also with ftp: upload - 1-3 KB/s download - 10 MB/s And here experiment with iperf: freebsd - server with re0 logos - server with fxp0 freebsd>[13:18:22]#>iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 64.0 KByte (default) ------------------------------------------------------------ [ 4] local 195.138.170.121 port 5001 connected with logos port 62951 [ 4] 0.0-10.0 sec 111 MBytes 93.0 Mbits/sec freebsd>[13:19:30]#>iperf -c logos ------------------------------------------------------------ Client connecting to logos, TCP port 5001 TCP window size: 65.0 KByte (default) ------------------------------------------------------------ [ 3] local 195.138.170.121 port 50422 connected with logos port 5001 [ 3] 0.0-12.8 sec 128 KBytes 81.6 Kbits/sec Thus we have the assymetric traffic (u/d~1/1000) at re0 with vlanhwtag... The same situation was observed with the driver rl (u/d~1/2) several years ago. On Tue, 17 Apr 2007, Pyun YongHyeon wrote: > On Tue, Apr 17, 2007 at 01:35:57PM +0300, Prokofiev S.P. wrote: > > Hello Pyun YongHyeon! > > > > I have updated src on April, 13th and versions of these files differ > > from yours, therefore I have corrected your patch (attached). > > After rebuilding kernel the bug has disappeared. > > Very good job! Thank you! > > Commit please in source. > > > > Thanks for testing. It seems that was a long standing bug. > I've burned all mana. I'll commit it tomorrow. > > > But even earlier I have found one more bug on this NIC. > > If to not switch off "vlanhwtag" (ifconfig re0 -vlanhwtag) ssh connection > > is lost through time and can not establish new. > > > > Do you mean VLAN h/w tagging didn't work at all for ssh connection? > What about other connections with VLAN? > > -- > Regards, > Pyun YongHyeon > From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 13:50:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FA4816A401 for ; Thu, 19 Apr 2007 13:50:05 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9EE13C4AE for ; Thu, 19 Apr 2007 13:50:05 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 228C75C19; Thu, 19 Apr 2007 23:50:00 +1000 (EST) From: Alan Garfield To: Yar Tikhiy In-Reply-To: <20070419113842.GE60301@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> <20070419113842.GE60301@comp.chem.msu.su> Content-Type: text/plain Date: Thu, 19 Apr 2007 23:50:00 +1000 Message-Id: <1176990600.4177.26.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 13:50:05 -0000 On Thu, 2007-04-19 at 15:38 +0400, Yar Tikhiy wrote: > inet 127.0.0.1 netmask 0xff000000 > > jnet0: flags=845 mtu 241 > > inet 169.254.101.3 netmask 0xffff0000 > > ether 00:09:3d:00:00:03 > > Note that jnet0 has no broadcast address. That should be wrong for > an Ethernet interface. (Honestly, I'm still uncertain whether it is > legal at all for an interface to have none of the following flags: > BROADCAST, POINTOPOINT, LOOPBACK.) Now looks like :- ---- jnet0: flags=8847 mtu 241 inet 169.254.101.3 netmask 0xffff0000 broadcast 169.254.255.255 ether 00:09:3d:00:00:03 ---- > > 169.254 link#4 UC 0 0 jnet0 > ^^^^^^^^^ > This record is there. Good... Note the C (cloning) flag. > Individual ARP records will be "cloned" from this one via > the rtresolve mechanism. Now looks even better like this :- ---- 169.254 link#4 UC 0 0 jnet0 169.254.101.2 00:09:3d:00:00:02 UHLW 1 1882 jnet0 687 ---- Ooo an look at this :- ---- [alan@twofish jnet_pci]$ ping 169.254.101.2 PING 169.254.101.2 (169.254.101.2): 56 data bytes 64 bytes from 169.254.101.2: icmp_seq=0 ttl=255 time=2.816 ms 64 bytes from 169.254.101.2: icmp_seq=1 ttl=255 time=2.709 ms 64 bytes from 169.254.101.2: icmp_seq=2 ttl=255 time=2.734 ms 64 bytes from 169.254.101.2: icmp_seq=3 ttl=255 time=2.736 ms 64 bytes from 169.254.101.2: icmp_seq=4 ttl=255 time=2.730 ms 64 bytes from 169.254.101.2: icmp_seq=5 ttl=255 time=2.744 ms ---- Looks like it's working! > In fact, you were overriding the normal ARP's arp_rtrequest() handler > for the addresses. Grep /sys/netinet/if_ether.c for ifa_rtrequest. > See also rtentry(9) (again, search for ifa_rtrequest). That's why nothing > worked. Indeed, I still don't fully understand what the problem was really. But it seems to be working ok now. BUT! Now I have a weird bug. SSH on the SP whinges about :- ---- localhost $ ssh -v 169.254.101.3 OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090703f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to 169.254.101.3 [169.254.101.3] port 22. debug1: Connection established. debug1: identity file /home/manager/.ssh/identity type -1 debug1: identity file /home/manager/.ssh/id_rsa type -1 debug1: identity file /home/manager/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5p1 FreeBSD-20061110 debug1: match: OpenSSH_4.5p1 FreeBSD-20061110 pat OpenSSH* Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.4p1 debug1: SSH2_MSG_KEXINIT sent d475 078f 7eae aef6 Disconnecting: Bad packet length -730527857. debug1: Calling cleanup 0x1001fc68(0x0) localhost $ ---- ... bad packet length! UGH! :) Since there is no telnet, vi or any other _testable_ services on the SP I'm stuffed to figure out what's wrong with the packets on the SP side. I can tcpdump on the platform side and everything looks peachy. How can I look at the tcp packet length in the data? > > Yeah it's what the Linux driver is called. Can be something else, got a > > better name? :) > > Perhaps just "jn"? Some utilities still have trouble with long > interface names[1], and they are a drag to type in. :-) So I'd > rather keep the name as short as possible. Yeah 'jn' sounds ok to me. Although it's really not going to be that common unless you have these SunFire or NewISys servers. :) Thanks, Alan. From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 17:39:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0A7A16A400 for ; Thu, 19 Apr 2007 17:39:19 +0000 (UTC) (envelope-from yoitsmeremember@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.235]) by mx1.freebsd.org (Postfix) with ESMTP id 8EEF613C45A for ; Thu, 19 Apr 2007 17:39:19 +0000 (UTC) (envelope-from yoitsmeremember@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so540065nza for ; Thu, 19 Apr 2007 10:39:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BJBmhNxSU8cSjCiH1jzOMMxD/aiA3bORFknweBGhg1L6duiS4Chvk129tz8VLAXOP9Ryk4FvQ4hsFTBltbAv9B7fGQ+5SsRkOrc9fvyDA20g7SutdqNSnufzn2C7m0TTszA/A4abK99wSwWW4TDJ41UYmhMj94cz2LrEkreDJMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Qf8MkuMBYqCeI0W7SnDGYlBs4AuOMFaagsartV+hIxeAeFIZ8GRavjUzErSi4lQibn5QHGYU/6phifK6OEtabE1SZYoKKaydWECVdU5W6Ch7uYB4aQbdkAmXv5K6oOGBLzpkE64iTiVbtFEWrP4QOYJroWGdzX6M+06h5If9Meg= Received: by 10.114.108.15 with SMTP id g15mr873433wac.1177004358050; Thu, 19 Apr 2007 10:39:18 -0700 (PDT) Received: by 10.114.72.5 with HTTP; Thu, 19 Apr 2007 10:39:17 -0700 (PDT) Message-ID: Date: Thu, 19 Apr 2007 12:39:17 -0500 From: Orum To: "FreeBSD-Net mailing list" In-Reply-To: <46276839.4090301@sun-fish.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46276839.4090301@sun-fish.com> Subject: Re: wpi driver. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yoitsmeremember@evil-geni.us List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 17:39:19 -0000 Stefan, I've gotten it to work on 6.2, but you need to get the patched version (specifically made for 6.2) from this location: http://www.bsdmon.com/download/20070121-wpi-freebsd.tar.gz You will also need to install the wpi-firmware port (not in the ports tree yet) from a later official release. I'm sorry to say I don't remember the link for the tar archive that included the port. Also note that it's still a very touchy driver, and might need to be unloaded/reloaded to get up and running (at least, that seems to fix it on my T60). In addition WPA/WPA2 do not work with it (don't know about WEP as I've never tried). Thanks, Ian On 4/19/07, Stefan Lambrev wrote: > Hello, > > Are there any news about wpi driver ? > Something that can be compiled on freebsd 6.2 stable ? > I tried the latest drivers from > http://www.clearchain.com/~benjsc/download, but no success :( > > I tried and from perforce but I've got this error: > > # make > Warning: Object directory not changed from original > /root/wpi/sys/modules/wpi > @ -> /usr/src/sys > machine -> /usr/src/sys/amd64/include > :> opt_bdg.h > awk -f @/tools/makeobjops.awk @/kern/device_if.m -h > awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h > awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h > cc -O2 -fno-strict-aliasing -pipe -g -DWITNESS -DINVARIANT_SUPPORT > -DINVARIANTS -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- > -I/root/wpi/sys/modules/wpi/../../ -I. -I@ -I@/contrib/altq > -I@/../include -I/usr/include -finline-limit=8000 -fno-common > -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 > -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c > /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c > /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c: In function > `wpi_firmware_get': > /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c:294: warning: > assignment discards qualifiers from pointer target type > *** Error code 1 > > Stop in /root/wpi/sys/modules/wpi. > > -- > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 17:53:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B162516A404 for ; Thu, 19 Apr 2007 17:53:36 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id DE1D413C448 for ; Thu, 19 Apr 2007 17:53:35 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3JHrX9c007289; Thu, 19 Apr 2007 21:53:33 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3JHrWg1007286; Thu, 19 Apr 2007 21:53:32 +0400 (MSD) (envelope-from yar) Date: Thu, 19 Apr 2007 21:53:31 +0400 From: Yar Tikhiy To: Alan Garfield Message-ID: <20070419175331.GA5999@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> <20070419113842.GE60301@comp.chem.msu.su> <1176990600.4177.26.camel@hiro.auspc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176990600.4177.26.camel@hiro.auspc.com.au> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 17:53:36 -0000 On Thu, Apr 19, 2007 at 11:50:00PM +1000, Alan Garfield wrote: [...] > > BUT! Now I have a weird bug. > > SSH on the SP whinges about :- > > ---- > localhost $ ssh -v 169.254.101.3 > OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090703f > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Rhosts Authentication disabled, originating port will not be > trusted. > debug1: ssh_connect: needpriv 0 > debug1: Connecting to 169.254.101.3 [169.254.101.3] port 22. > debug1: Connection established. > debug1: identity file /home/manager/.ssh/identity type -1 > debug1: identity file /home/manager/.ssh/id_rsa type -1 > debug1: identity file /home/manager/.ssh/id_dsa type -1 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_4.5p1 FreeBSD-20061110 > debug1: match: OpenSSH_4.5p1 FreeBSD-20061110 pat OpenSSH* > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.4p1 > debug1: SSH2_MSG_KEXINIT sent > d475 078f 7eae aef6 > Disconnecting: Bad packet length -730527857. > debug1: Calling cleanup 0x1001fc68(0x0) > localhost $ > ---- > > ... bad packet length! UGH! :) > > Since there is no telnet, vi or any other _testable_ services on the SP > I'm stuffed to figure out what's wrong with the packets on the SP side. > I can tcpdump on the platform side and everything looks peachy. 1. Ping the Linux side with packets close to the MTU in size (ping -s), use different data patterns (ping -p), see with tcpdump -X if the data gets damaged. 2. Capture a broken SSH session (tcpdump -s0 -w ssh.cap) and analyze it off-line with Ethereal/Wireshark (I hope it has a dissector for SSH). The sessions doesn't reash encryption, so the damage should be clear. > How can I look at the tcp packet length in the data? tcpdump -v, but it seems to be SSH packet length, not TCP one. AFAIK, the SSH protocol utilizes packets of its own over the TCP stream. > > > Yeah it's what the Linux driver is called. Can be something else, got a > > > better name? :) > > > > Perhaps just "jn"? Some utilities still have trouble with long > > interface names[1], and they are a drag to type in. :-) So I'd > > rather keep the name as short as possible. > > Yeah 'jn' sounds ok to me. Although it's really not going to be that > common unless you have these SunFire or NewISys servers. :) Nevertheless, it can be a reference driver working with real hardware for other folks to study. -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 21:05:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F31A16A403 for ; Thu, 19 Apr 2007 21:05:04 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id A09D113C459 for ; Thu, 19 Apr 2007 21:05:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l3JL51ji003608; Fri, 20 Apr 2007 07:05:01 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l3JL51sQ003607; Fri, 20 Apr 2007 07:05:01 +1000 (EST) (envelope-from peter) Date: Fri, 20 Apr 2007 07:05:01 +1000 From: Peter Jeremy To: Alan Garfield Message-ID: <20070419210501.GA828@turion.vk2pj.dyndns.org> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> <20070419113842.GE60301@comp.chem.msu.su> <1176990600.4177.26.camel@hiro.auspc.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <1176990600.4177.26.camel@hiro.auspc.com.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 21:05:04 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Apr-19 23:50:00 +1000, Alan Garfield wrote: >debug1: Local version string SSH-2.0-OpenSSH_3.4p1 >debug1: SSH2_MSG_KEXINIT sent >d475 078f 7eae aef6=20 >Disconnecting: Bad packet length -730527857. >debug1: Calling cleanup 0x1001fc68(0x0) >localhost $=20 'Bad packet length' is coming from ssh (packet.c:packet_read_poll2()) and (as Yar suggested) is related to SSH's own packetisation, rather than TCP. The reported packet length is the 'd475 078f' immediately above. Note that at this stage, SSH has not negotiated encryption so working thru a tcpdump output is still practical. I suspect that there's a problem with the packet sizes. >> > Yeah it's what the Linux driver is called. Can be something else, got a >> > better name? :) >>=20 >> Perhaps just "jn"? Some utilities still have trouble with long >> interface names[1], and they are a drag to type in. :-) So I'd >> rather keep the name as short as possible. > >Yeah 'jn' sounds ok to me. Although it's really not going to be that >common unless you have these SunFire or NewISys servers. :) All the utilities I've seen will just truncate the names. Since we already have 4-character interface names (eg vlan), and there will never be more than one of these, I'd prefer to leave it as jnet. There are a limited number of 2-letter combinations and 4 letters is more descriptive. (I would far prefer that "vlan" be truncated to something shorter so that my daily reports don't have 48 lines stating 'vlan1'). --=20 Peter Jeremy --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGJ9l9/opHv/APuIcRAg15AJwN83NSq0LGpVIC0JEp42eevQOyGgCgxKuy BDtz0KN7u7UtiAG00q+phP4= =ujUo -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 02:59:05 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 63D7616A404 for ; Fri, 20 Apr 2007 02:59:05 +0000 (UTC) (envelope-from webmaster@web-tricks.net) Received: from smtp2.abac.com (smtp2.abac.com [216.55.128.210]) by mx1.freebsd.org (Postfix) with ESMTP id 553D313C465 for ; Fri, 20 Apr 2007 02:59:05 +0000 (UTC) (envelope-from webmaster@web-tricks.net) Received: from c-24-23-32-234.hsd1.ca.comcast.net ([24.23.32.234] helo=dragon) by smtp2.abac.com with esmtpa id 1Hein5-000LCp-Fv for freebsd-net@freebsd.org; Thu, 19 Apr 2007 19:24:03 -0700 Message-ID: <002901c782f3$0b4789d0$dedca8c0@dragon> From: To: Date: Thu, 19 Apr 2007 19:24:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Subject: New Config of Jails & 4 port NIC with 6.2 stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 02:59:05 -0000 Hello Everyone! A FreeBSD Grasshopper needs help. PIII 1Ghz. 1/2 gig ram two 80 gig drives One 4 port D-link NIC. Freebsd 6.2 stable +Gnome & Xorg, webmin installed I have comcast with a Netgear wireless router like to configure the above with Jails My aim is local DNS, DHCP, Apache1.3, MySQL 4, PHP4, etc, etc. basic server stuff. I guess jaling the DNS, DHCP in one jail then Jailing MySQL & Apache This would leave one port on NIC card. Not sure where to start! I would like to have a one NIC port stay on web. After that I am not sure where to go. From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 10:34:00 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEC7616A401 for ; Fri, 20 Apr 2007 10:34:00 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 4DBD813C48C for ; Fri, 20 Apr 2007 10:33:59 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.8/8.13.8) with ESMTP id l3KAXx3e006498; Fri, 20 Apr 2007 20:33:59 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.8/8.13.8/Submit) id l3KAXvUH006497; Fri, 20 Apr 2007 20:33:57 +1000 (EST) (envelope-from peter) Date: Fri, 20 Apr 2007 20:33:57 +1000 From: Peter Jeremy To: webmaster@web-tricks.net Message-ID: <20070420103357.GF5257@turion.vk2pj.dyndns.org> References: <002901c782f3$0b4789d0$dedca8c0@dragon> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Content-Disposition: inline In-Reply-To: <002901c782f3$0b4789d0$dedca8c0@dragon> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: freebsd-net@freebsd.org Subject: Re: New Config of Jails & 4 port NIC with 6.2 stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 10:34:00 -0000 --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Apr-19 19:24:37 -0700, webmaster@web-tricks.net wrote: >A FreeBSD Grasshopper needs help. This is probably more -questions fodder but anyway... >like to configure the above with Jails >My aim is local DNS, DHCP, Apache1.3, MySQL 4, PHP4, etc, etc. >basic server stuff. Whilst you need an IP address for a jail, you don't need to dedicate an interface to a jail. Typically, you would create a number of aliases on one interface and assign them to jails. If you have lots of public addresses then you could use aliases on your public NIC. Alternatively, you can create aliases on lo0 and use firewall software (ipfw, IPfilter or pf) to redirect packets to the appropriate alias. If you really need distinct physical interfaces, you could use an IEEE 802.1Q VLAN trunk into your FreeBSD box and break it out into as many vlan interfaces as you want. --=20 Peter Jeremy --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGKJcV/opHv/APuIcRAsyEAJ93t8cGXq8jXyeHfWOc3CFWfxXKhgCfdg/S ObinAVmBOinyG1h6lMMhVA8= =1NBd -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 11:41:04 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C6E2D16A400 for ; Fri, 20 Apr 2007 11:41:04 +0000 (UTC) (envelope-from mipam@ux11.ltcm.net) Received: from ux11.ltcm.net (213-84-197-131.adsl.xs4all.nl [213.84.197.131]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3CF13C45D for ; Fri, 20 Apr 2007 11:41:03 +0000 (UTC) (envelope-from mipam@ux11.ltcm.net) Received: from ux11.ltcm.net (mipam@localhost.ltcm.net [IPv6:::1]) by ux11.ltcm.net (8.12.9/8.12.9/UX11TT) with ESMTP id l3KB49rP032732 for ; Fri, 20 Apr 2007 13:04:09 +0200 (MEST) Received: from localhost (mipam@localhost) by ux11.ltcm.net (8.12.9/8.12.9/Submit) with ESMTP id l3KB47jL003271 for ; Fri, 20 Apr 2007 13:04:08 +0200 (MEST) Date: Fri, 20 Apr 2007 13:04:07 +0200 (MEST) From: Mipam To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Device polling in the 5.x series X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 11:41:04 -0000 Hi All, Just to check. Still running some 5.x systems here and experiences trouble where device polling is turned on. I must add that i am using intel cards, so the em driver is involved as well. When i turn off device polling, the system is way more stable. Did polling ever really work well in the 5.x series with the em driver? Regards, Mipam. From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 12:49:11 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE5A416A400 for ; Fri, 20 Apr 2007 12:49:11 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3E36613C458 for ; Fri, 20 Apr 2007 12:49:10 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Level: 2 [X] Received: from [212.86.226.11] (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.8) with ESMTPA id 22668307; Fri, 20 Apr 2007 14:49:08 +0300 Message-ID: <4628A8B3.2090900@mavhome.dp.ua> Date: Fri, 20 Apr 2007 14:49:07 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8b) Gecko/20051108 MIME-Version: 1.0 To: Nikos Vassiliadis References: <1176776612.00725618.1176764402@10.7.7.3> <1176816181.00725799.1176802803@10.7.7.3> In-Reply-To: <1176816181.00725799.1176802803@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Tom McLaughlin Subject: Re: net/mpd4: Unable to pass pass traffic as pptp client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 12:49:11 -0000 232487741 Nikos Vassiliadis wrote: >>pptp0: connecting to 208.206.3.5 1723 >>[vpn] IPCP: LayerUp >> 172.30.29.9 -> 208.206.3.5 > >>ifconfig >>[root@bofh tom]# ifconfig ng0 >>ng0: flags=88d1 mtu 1396 >> inet 172.30.29.9 --> 208.206.3.5 netmask 0xffffffff > > It seems that your external peer address is the same with the internal > peer address. You connect to pptp-server-ip through your linksys and > then say that pptp-server-ip is reachable through the tunnel. So it > routes everything destined for pptp-server-ip through the tunnel. I > think that such configuration is valid for other operating systems. > I don't know if you can work-around the problem on your own, maybe > you have to contact the VPN concentrator's admin. Perhaps you can > modify the routing table (the external peer address should be reachable > as it was, though linksys) and invent some peer address using > "ifconfig ng0 your_address 10.0.0.1 netmask 0xffffffff". > But it's not nice... > > Can you convice the concentrator's administrator to use another > address for his internal side? It would be a better way. But if it is not possible you could use 'ipfw fwd' rule to forward all PPTP's GRE and controling TCP packets via physical interface instead of tunnel. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 12:51:24 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3935216A403 for ; Fri, 20 Apr 2007 12:51:24 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id 9ABC313C4C1 for ; Fri, 20 Apr 2007 12:51:22 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: by mu-out-0910.google.com with SMTP id g7so1056664muf for ; Fri, 20 Apr 2007 05:51:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EpBYBpMRNhrGIeE6axhOz/E2VRkMTK6W4TFw2Bk5iG4wcBo9vqU/JnR71R4TLPKqJUGPvRihiKPQdLdLcGc0ZibmM6I8AVLBr4t50TUT0G0SgrF6aJ7cCbmd708f9FWFs1D4fJst3agSRSm0ujT6r7YLA+BdRTNsM/ebbmwvElA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=tSocAbh6DvCqE5z/SRA0gEZPPK/TSLjkfaqkKG/TZSXv4IVsF/XzEHu3Q2qUuLZvIYyKOB2uH5Lx7t7ToOMpipAivaI6dLm6BKujnZILFrjCnIvc6tQzx7qbp1Pg7SVNJGPG9rwSHPINELeESgcWjDkFtauzxdbxR9NNpFqlCOU= Received: by 10.82.163.13 with SMTP id l13mr4486709bue.1177071858017; Fri, 20 Apr 2007 05:24:18 -0700 (PDT) Received: by 10.82.191.16 with HTTP; Fri, 20 Apr 2007 05:24:17 -0700 (PDT) Message-ID: <80f4f2b20704200524s3447e98et1990403b711e42f7@mail.gmail.com> Date: Fri, 20 Apr 2007 08:24:17 -0400 From: "Jim Stapleton" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: attempting VPN again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 12:51:24 -0000 OK, I found a Windows based VPN server at work (we have one windows + 2 cisco) I figured I'd try that because it was the least painful to setup elsewhere (meaning fewer things that vary in configuration?), and I found *some* references to connecting to it. http://lists.freebsd.org/pipermail/freebsd-net/2006-June/010891.html Here are my files. Anything in ALL CAPS is a replacement for some information I'd rather not display publically. /usr/local/etc/mpd/mpd.conf ======================================== vpn: new -i nve0 vpn vpn set iface session 28800 set bundle authname "WORK-DOMAIN\\WORK-USERNAME" set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e56 set ccp yes mpp-e128 # set this to your correct routing information set iface route EXTERNAL-WORK-VPN-IP/24 set link enable no-orig-auth open ======================================== /usr/local/etc/mpd/mpd.secret ======================================== WORK-DOMAIN\\WORK-USERNAME WORK-PASSWORD ======================================== /usr/local/etc/mpd/mpd.secret ======================================== vpn: set link type pptp # set pptp self 1.2.3.4 set pptp peer EXTERNAL-WORK-VPN-IP set pptp enable originate outcall ======================================== sjss@elrond 08:12:45 (1) /usr/local/etc/mpd > sudo mpd ======================================== Multi-link PPP for FreeBSD, by Archie L. Cobbs. Based on iij-ppp, by Toshiharu OHNO. mpd: pid 91637, version 3.18 (root@elrond.ameritech.net 22:07 19-Apr-2007) [vpn] interface "nve0" is not a netgraph interface [vpn] netgraph initialization failed mpd: no bundles defined mpd: no bundles defined mpd: no bundles defined mpd: no bundles defined mpd: no bundles defined mpd: no bundles defined mpd: no bundles defined mpd: no bundles defined mpd: no bundles defined mpd: no bundles defined [:] ======================================== Here's a point of confusion for me (I tested all using ipconfig): (1) My machine at work is a windows machine, ip config reports a netmask of 255.255.254.0 (2) The machine I admin is also windows, with 255.255.255.0 as it's netmask (3) My windows desktop, when VPNing in has a netmask of 255.255.255.255 for the VPN interface. Any suggestions on how to get this up? This is one of only two tasks I need to boot into windows (at home) to accomplish currently, and I'd like to rectify that. It looks like I need to make a netgraph bridge, but I don't know where to start looking for that one. Netgraph(4) wasn't enlightening for me. The ipsec section of the handbook left me more confused then I was when I started. Thanks, -Jim Stapleton From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 13:29:01 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 361AD16A40F for ; Fri, 20 Apr 2007 13:29:01 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by mx1.freebsd.org (Postfix) with ESMTP id 6E34A13C48A for ; Fri, 20 Apr 2007 13:29:00 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: by mu-out-0910.google.com with SMTP id g7so1069149muf for ; Fri, 20 Apr 2007 06:28:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UYOsBxdAbZN7nI7uU6LKu6YTCVPrc8NuVsOXLi+uMiPSnQPOpfQBjLVGqMI1wy6eRsQWSTA7dus2VbDx/XcmhVCSOJP/Ky4kiStJk3prOZW1tfFRuT5bKvxVhgF6w0JbKA/N6Lnz9zAj0qVQLPDcXo6r5lJRMIZ9G1U+VgKJVSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZI4ezBFzB+KnHPr0y2Nb2Cb0AHBjnm1uWvm4aJ5GPt/MhS31b27XpX8WuTPjA+IS+rsf0Ti3tcTgAvyK5uiOQ/QaYl2uk+Ag2T+KpwgrEnV3F3q+WhBTyJewfxhdl8DQ5f1VwIfMuFiRTRXGO9wUN/CO9JSX9gocmTbFYol0wjA= Received: by 10.82.162.14 with SMTP id k14mr4604104bue.1177075738050; Fri, 20 Apr 2007 06:28:58 -0700 (PDT) Received: by 10.82.191.16 with HTTP; Fri, 20 Apr 2007 06:28:58 -0700 (PDT) Message-ID: <80f4f2b20704200628g3228cedbhaf8e7c1a24b790f7@mail.gmail.com> Date: Fri, 20 Apr 2007 09:28:58 -0400 From: "Jim Stapleton" To: freebsd-net@freebsd.org In-Reply-To: <80f4f2b20704200524s3447e98et1990403b711e42f7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <80f4f2b20704200524s3447e98et1990403b711e42f7@mail.gmail.com> Subject: Re: attempting VPN again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 13:29:01 -0000 OK, I figured ng0 stood for negraph, so I switched nve0 go ng0, and it had *some* improvement. I get a lot farther along. (When I man'ed ng0 - or attempted to, I accidentally did nge, and though that the sample was using a national semiconductors gigabit-ethernet controller, and I had to switch it to my own nvidia based system). Anyway, now I get a log string of connection setup stuff, which appears to connect until it gets this error: [vpn] CCP: state change Ack-Sent --> Opened [vpn] CCP: LayerUp Compress using: MPPE, 128 bit Decompress using: MPPE, 128 bit [vpn] setting interface ng0 MTU to 1500 bytes [vpn] IPCP: rec'd Configure Ack #4 link 0 (Ack-Sent) IPADDR [HIDDEN-VALID-IP] [vpn] IPCP: state change Ack-Sent --> Opened [vpn] IPCP: LayerUp [HIDDEN-VALID-IP] -> [HIDDEN-VALID-IP] [vpn] IFACE: Up event [vpn] setting interface ng0 MTU to 1500 bytes [vpn] exec: /sbin/ifconfig ng0 [HIDDEN-VALID-IP] [HIDDEN-VALID-IP] netmask 0xffffffff -link0 [vpn] exec: /sbin/route add [HIDDEN-VALID-IP] -iface lo0 [vpn] exec: /sbin/route add [HIDDEN-VALID-IP] [HIDDEN-VALID-IP] -netmask 0xffffff00 [vpn] IFACE: Up event [vpn] LCP: no reply to 1 echo request(s) [vpn] LCP: no reply to 2 echo request(s) [vpn] LCP: no reply to 3 echo request(s) [vpn] LCP: no reply to 4 echo request(s) [vpn] LCP: no reply to 5 echo request(s) [vpn] LCP: no reply to 6 echo request(s) [vpn] LCP: no reply to 7 echo request(s) [vpn] LCP: peer not responding to echo requests [vpn] LCP: LayerFinish [vpn] LCP: LayerStart [vpn] LCP: state change Opened --> Starting [vpn] LCP: phase shift NETWORK --> DEAD [vpn] setting interface ng0 MTU to 1500 bytes [vpn] up: 0 links, total bandwidth 9600 bps [vpn] IPCP: Down event [vpn] IPCP: state change Opened --> Starting [vpn] IPCP: LayerDown [vpn] IFACE: Down event [vpn] exec: /sbin/route delete [HIDDEN-VALID-IP] [HIDDEN-VALID-IP] -netmask 0xffffff00 [vpn] exec: /sbin/route delete [HIDDEN-VALID-IP] -iface lo0 [vpn] exec: /sbin/ifconfig ng0 down delete -link0 [vpn] CCP: Down event [vpn] CCP: state change Opened --> Starting [vpn] CCP: LayerDown [vpn] CCP: Close event [vpn] CCP: state change Starting --> Initial [vpn] CCP: LayerFinish [vpn] LCP: LayerDown [vpn] device: CLOSE event in state UP pptp0-0: clearing call [vpn] device is now in state CLOSING [vpn] device: OPEN event in state CLOSING [vpn] device is now in state CLOSING [vpn] device: DOWN event in state CLOSING [vpn] device is now in state DOWN [vpn] link: DOWN event [vpn] LCP: Down event [vpn] device: OPEN event in state DOWN [vpn] pausing 9 seconds before open [vpn] device is now in state DOWN [vpn] device: OPEN event in state DOWN [vpn] device is now in state DOWN pptp0-0: peer call disconnected res=zero? err=none pptp0-0: killing channel pptp0: closing connection with SERVER-VPN-IP-ADDR:1723 pptp0: killing connection with SERVER-VPN-IP-ADDR:1723 [vpn] closing link "vpn"... [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] LCP: state change Starting --> Initial [vpn] LCP: LayerFinish [vpn] device: CLOSE event in state DOWN [vpn] device is now in state DOWN A few IPs have been cleaned out with anything else sensitive, there's a lot more, which I can clean up and send here, but, I don't know what is needed. Any ideas (or what more info should I send?) Thanks, -Jim Stapleton On 4/20/07, Jim Stapleton wrote: > OK, I found a Windows based VPN server at work (we have one windows + 2 cisco) > > I figured I'd try that because it was the least painful to setup > elsewhere (meaning fewer things that vary in configuration?), and I > found *some* references to connecting to it. > http://lists.freebsd.org/pipermail/freebsd-net/2006-June/010891.html > > Here are my files. Anything in ALL CAPS is a replacement for some > information I'd rather not display publically. > > /usr/local/etc/mpd/mpd.conf > ======================================== > vpn: > new -i nve0 vpn vpn > > set iface session 28800 > set bundle authname "WORK-DOMAIN\\WORK-USERNAME" > set bundle enable compression > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e56 > set ccp yes mpp-e128 > # set this to your correct routing information > set iface route EXTERNAL-WORK-VPN-IP/24 > set link enable no-orig-auth > open > ======================================== > > /usr/local/etc/mpd/mpd.secret > ======================================== > WORK-DOMAIN\\WORK-USERNAME WORK-PASSWORD > ======================================== > > /usr/local/etc/mpd/mpd.secret > ======================================== > vpn: > set link type pptp > # set pptp self 1.2.3.4 > set pptp peer EXTERNAL-WORK-VPN-IP > set pptp enable originate outcall > ======================================== > > > > sjss@elrond 08:12:45 (1) /usr/local/etc/mpd > sudo mpd > ======================================== > Multi-link PPP for FreeBSD, by Archie L. Cobbs. > Based on iij-ppp, by Toshiharu OHNO. > mpd: pid 91637, version 3.18 (root@elrond.ameritech.net 22:07 19-Apr-2007) > [vpn] interface "nve0" is not a netgraph interface > [vpn] netgraph initialization failed > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > [:] > ======================================== > > > > Here's a point of confusion for me (I tested all using ipconfig): > (1) My machine at work is a windows machine, ip config reports a > netmask of 255.255.254.0 > (2) The machine I admin is also windows, with 255.255.255.0 as it's netmask > (3) My windows desktop, when VPNing in has a netmask of > 255.255.255.255 for the VPN interface. > > > > Any suggestions on how to get this up? This is one of only two tasks I > need to boot into windows (at home) to accomplish currently, and I'd > like to rectify that. > > It looks like I need to make a netgraph bridge, but I don't know where > to start looking for that one. Netgraph(4) wasn't enlightening for me. > The ipsec section of the handbook left me more confused then I was > when I started. > > Thanks, > -Jim Stapleton > From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 13:35:19 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E752316A403 for ; Fri, 20 Apr 2007 13:35:19 +0000 (UTC) (envelope-from nicolas@nixsoftware.com) Received: from mail.blazis.com (hazel.blazis.com [75.126.205.130]) by mx1.freebsd.org (Postfix) with ESMTP id C45CB13C48A for ; Fri, 20 Apr 2007 13:35:19 +0000 (UTC) (envelope-from nicolas@nixsoftware.com) Received: from www by mail.blazis.com with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1Hesyw-0000AJ-KM; Fri, 20 Apr 2007 08:16:58 -0500 To: Jim Stapleton MIME-Version: 1.0 Date: Fri, 20 Apr 2007 8:16:58 -0500 From: Nicolas Gieczewski In-Reply-To: <80f4f2b20704200524s3447e98et1990403b711e42f7@mail.gmail.com> References: <80f4f2b20704200524s3447e98et1990403b711e42f7@mail.gmail.com> Message-ID: X-Sender: nicolas@nixsoftware.com User-Agent: RoundCube Webmail/0.1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: attempting VPN again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 13:35:20 -0000 On Fri, 20 Apr 2007 08:24:17 -0400, "Jim Stapleton" wrote: > /usr/local/etc/mpd/mpd.conf > ======================================== > vpn: > new -i nve0 vpn vpn > > set iface session 28800 > set bundle authname "WORK-DOMAIN\\WORK-USERNAME" > set bundle enable compression > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e56 > set ccp yes mpp-e128 > # set this to your correct routing information > set iface route EXTERNAL-WORK-VPN-IP/24 > set link enable no-orig-auth > open > ======================================== In mpd.conf, you need to set the interface to a valid netgraph interface name, e.g. ng0. mpd will create it for you if it does not exist. The physical interface (e.g. nve0) is specified in mpd.links, not here. Additionally, you have a blank line between the "new" command and the first "set" command. I suspect that's causing the "no bundles defined" errors: > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined > mpd: no bundles defined -- Nicolas Gieczewski From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 13:35:27 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C41616A402 for ; Fri, 20 Apr 2007 13:35:27 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by mx1.freebsd.org (Postfix) with ESMTP id B1A8813C448 for ; Fri, 20 Apr 2007 13:35:26 +0000 (UTC) (envelope-from stapleton.41@gmail.com) Received: by mu-out-0910.google.com with SMTP id g7so1071343muf for ; Fri, 20 Apr 2007 06:35:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ekTAXPuX7guBAOdRN/TroNyejwDk8i8o6QrWvb9uEvn3MA+NosOYISCvgGW8scd3x0qGI19hSXZQKO0TY7hWn0XSbfyltnoEzvNV3nfWJWmQSBVffNN55x/w0mKCPexMUDCn/p1Nz/2p6rpsSJDtAy0w4sXoiTyeqA4Rz3ln7PQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V67dzq1fho2ljoW8VaigyQmrz2qAPebrUFPof8Uio5/CM1zvez+zRsbuuinbWY1OHRBKl8i77pSFmKAZg5Ds1YpkQG0x6a0fjwUKDSRhpG6SE+e9OuW/NkJSOzehZXSBeaDie1y/lZlxTe9ZoFU6QWJIhjtUKOk4/MUf8DkQGrw= Received: by 10.82.134.12 with SMTP id h12mr4567468bud.1177076125416; Fri, 20 Apr 2007 06:35:25 -0700 (PDT) Received: by 10.82.191.16 with HTTP; Fri, 20 Apr 2007 06:35:25 -0700 (PDT) Message-ID: <80f4f2b20704200635i48b1771cjbea13146152dc68e@mail.gmail.com> Date: Fri, 20 Apr 2007 09:35:25 -0400 From: "Jim Stapleton" To: "Nicolas Gieczewski" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <80f4f2b20704200524s3447e98et1990403b711e42f7@mail.gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: attempting VPN again X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 13:35:27 -0000 Thanks, I tried the nve0->ng0 thing (see my other email). After reading yours, I tried removing the extra blank line, but that did not fix anything either, or change the output. Thanks, -Jim Stapleton On 4/20/07, Nicolas Gieczewski wrote: > > On Fri, 20 Apr 2007 08:24:17 -0400, "Jim Stapleton" wrote: > > /usr/local/etc/mpd/mpd.conf > > ======================================== > > vpn: > > new -i nve0 vpn vpn > > > > set iface session 28800 > > set bundle authname "WORK-DOMAIN\\WORK-USERNAME" > > set bundle enable compression > > set ccp yes mppc > > set ccp yes mpp-e40 > > set ccp yes mpp-e56 > > set ccp yes mpp-e128 > > # set this to your correct routing information > > set iface route EXTERNAL-WORK-VPN-IP/24 > > set link enable no-orig-auth > > open > > ======================================== > > In mpd.conf, you need to set the interface to a valid netgraph interface name, e.g. ng0. mpd will create it for you if it does not exist. The physical interface (e.g. nve0) is specified in mpd.links, not here. > > Additionally, you have a blank line between the "new" command and the first "set" command. I suspect that's causing the "no bundles defined" errors: > > > mpd: no bundles defined > > mpd: no bundles defined > > mpd: no bundles defined > > mpd: no bundles defined > > mpd: no bundles defined > > mpd: no bundles defined > > mpd: no bundles defined > > mpd: no bundles defined > > mpd: no bundles defined > > mpd: no bundles defined > > > -- > Nicolas Gieczewski > > From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 13:55:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89C5E16A400 for ; Fri, 20 Apr 2007 13:55:52 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 071A213C46E for ; Fri, 20 Apr 2007 13:55:51 +0000 (UTC) (envelope-from stefan.lambrev@sun-fish.com) Received: from blah.sun-fish.com (localhost [127.0.0.1]) by blah.sun-fish.com (Postfix) with ESMTP id 2AB8C1B10F99; Fri, 20 Apr 2007 15:55:50 +0200 (CEST) Received: from [192.168.3.125] (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 27FA51B10F8B; Fri, 20 Apr 2007 15:55:50 +0200 (CEST) Message-ID: <4628C665.8030403@sun-fish.com> Date: Fri, 20 Apr 2007 16:55:49 +0300 From: Stefan Lambrev User-Agent: Thunderbird 1.5.0.10 (X11/20070326) MIME-Version: 1.0 To: yoitsmeremember@evil-geni.us References: <46276839.4090301@sun-fish.com> In-Reply-To: Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP on BLAH Cc: FreeBSD-Net mailing list Subject: Re: wpi driver. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stefan.lambrev@sun-fish.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 13:55:52 -0000 Hi, Thanks for the quick reply. But ... Orum wrote: > Stefan, > > I've gotten it to work on 6.2, but you need to get the patched version > (specifically made for 6.2) from this location: > http://www.bsdmon.com/download/20070121-wpi-freebsd.tar.gz This does NOT compile on FreeBSD 6.2-stable from 12 Mar 2007. The error is the same. > > You will also need to install the wpi-firmware port (not in the ports > tree yet) from a later official release. I'm sorry to say I don't > remember the link for the tar archive that included the port. > > Also note that it's still a very touchy driver, and might need to be > unloaded/reloaded to get up and running (at least, that seems to fix > it on my T60). In addition WPA/WPA2 do not work with it (don't know > about WEP as I've never tried). Not very useful without WPA(2) as I do not want to share my network .. :) I'm more interested is there something new about the driver with the new firmware, because it was mentioned in last quarter report, and few other places on the net, but there is nothing new "released". > > Thanks, > Ian > > On 4/19/07, Stefan Lambrev wrote: >> Hello, >> >> Are there any news about wpi driver ? >> Something that can be compiled on freebsd 6.2 stable ? >> I tried the latest drivers from >> http://www.clearchain.com/~benjsc/download, but no success :( >> >> I tried and from perforce but I've got this error: >> >> # make >> Warning: Object directory not changed from original >> /root/wpi/sys/modules/wpi >> @ -> /usr/src/sys >> machine -> /usr/src/sys/amd64/include >> :> opt_bdg.h >> awk -f @/tools/makeobjops.awk @/kern/device_if.m -h >> awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h >> awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h >> cc -O2 -fno-strict-aliasing -pipe -g -DWITNESS -DINVARIANT_SUPPORT >> -DINVARIANTS -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- >> -I/root/wpi/sys/modules/wpi/../../ -I. -I@ -I@/contrib/altq >> -I@/../include -I/usr/include -finline-limit=8000 -fno-common >> -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 >> -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float >> -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c >> /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c >> /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c: In function >> `wpi_firmware_get': >> /root/wpi/sys/modules/wpi/../../dev/wpi/if_wpi.c:294: warning: >> assignment discards qualifiers from pointer target type >> *** Error code 1 >> >> Stop in /root/wpi/sys/modules/wpi. >> >> -- >> Best Wishes, >> Stefan Lambrev >> ICQ# 24134177 >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 14:03:28 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 453DA16A402 for ; Fri, 20 Apr 2007 14:03:28 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id C772713C469 for ; Fri, 20 Apr 2007 14:03:27 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 624895C19; Sat, 21 Apr 2007 00:03:25 +1000 (EST) From: Alan Garfield To: Yar Tikhiy In-Reply-To: <20070419175331.GA5999@comp.chem.msu.su> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> <20070419113842.GE60301@comp.chem.msu.su> <1176990600.4177.26.camel@hiro.auspc.com.au> <20070419175331.GA5999@comp.chem.msu.su> Content-Type: text/plain Date: Sat, 21 Apr 2007 00:03:25 +1000 Message-Id: <1177077805.4063.7.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 14:03:28 -0000 On Thu, 2007-04-19 at 21:53 +0400, Yar Tikhiy wrote: > 1. Ping the Linux side with packets close to the MTU in size (ping > -s), use different data patterns (ping -p), see with tcpdump -X if > the data gets damaged. Yeah I figured out. I wasn't handling mbuf chains properly so a bit of the packet wasn't being put into the buffer. Fixed that now.... BUT! Now I get this after I log in and try to output anything more than a few characters (eg. ls -la) :- ---- Disconnecting: Corrupted MAC on input. ---- I'm sure it's something to do with how I'm doing the output. Does this look sane? ---- static void jnet_start_locked(struct ifnet* ifp) { /* {{{ */ struct jnet_softc *sc = ifp->if_softc; struct mbuf *m0, *m; int i, total_len; //device_printf(sc->dev, "jnet_start_locked() called.\n"); JNET_ASSERT_LOCKED(sc); outputloop: if ((&ifp->if_snd)->ifq_len == TX_QUEUE_SIZE || (&ifp->if_snd)->ifq_drv_len == TX_QUEUE_SIZE) { /* No room left. Set OACTIVE to tell everyone */ ifp->if_drv_flags |= IFF_DRV_OACTIVE; return; } IFQ_DRV_DEQUEUE(&ifp->if_snd, m); if (m == 0) { /* * Space is still available in buffers so allow * new packets to be added */ ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; return; } m0 = m; /* set address counter to zero, then read the entire fifo */ bus_space_write_1(sc->iot[PRS1_IO_OFFSET], sc->ioh[PRS1_IO_OFFSET], PRS1_STATUS_OFFSET, 0x00); /* Output the IP_CHAR to tell SP the buffer is an IP packet */ bus_space_write_1(sc->iot[PRS1_IO_OFFSET], sc->ioh[PRS1_IO_OFFSET], PRS1_DATA_OFFSET, IP_CHAR); total_len = 0; // Loop over mbuf chain and output data to PRS1 DATA register - Packet max length should // already be worked out by the upper layers while (m0) { if(m0->m_len) { total_len += m0->m_len; /* Output ethernet frame to prs buffer */ bus_space_write_multi_1(sc->iot[PRS1_IO_OFFSET], sc->ioh[PRS1_IO_OFFSET], PRS1_DATA_OFFSET, mtod(m0, unsigned char *), m0->m_len); } m0 = m0->m_next; } device_printf(sc->dev, "len: %i padding: %i total: %i\n", total_len, FRAME_SIZE - total_len, total_len + (FRAME_SIZE - total_len)); /* Added padding to fill what's left of the buffer */ for (i = total_len; i < FRAME_SIZE; i++) { bus_space_write_1(sc->iot[PRS1_IO_OFFSET], sc->ioh[PRS1_IO_OFFSET], PRS1_DATA_OFFSET, 0x00); } m0 = m; BPF_MTAP(ifp, m0); m_freem(m0); /* Loop to top to possibly buffer more packets */ goto outputloop; } ---- > Nevertheless, it can be a reference driver working with real hardware > for other folks to study. It's simple enough once I figured out where the pitfalls are. :) -A. From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 15:11:14 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F180B16A404 for ; Fri, 20 Apr 2007 15:11:14 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id CB26C13C4BF for ; Fri, 20 Apr 2007 15:11:14 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 1DE80216AF6 for ; Fri, 20 Apr 2007 11:11:16 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 20 Apr 2007 11:11:15 -0400 X-Sasl-enc: emVM/RGqEpb5pQXdmO+VQ+fxRrbkimaNWDI1FlPG4+2O 1177081874 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 6C79B1426D for ; Fri, 20 Apr 2007 11:11:14 -0400 (EDT) Message-ID: <4628D810.5070109@FreeBSD.org> Date: Fri, 20 Apr 2007 16:11:12 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: FreeBSD-Net mailing list References: <462039C0.4070400@incunabulum.net> In-Reply-To: <462039C0.4070400@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CODE DROP] Source-Specific Multicast for FreeBSD 7: Phase 1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 15:11:15 -0000 I've had some feedback from Robert Watson which has been factored into the branch. Thanks, Robert! If I hear no objections I'll aim to commit this code to -CURRENT within the next week, subject to approval. No MFC is planned because of the magnitude of the change. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 15:20:29 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C0B916A403 for ; Fri, 20 Apr 2007 15:20:29 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 06CB913C489 for ; Fri, 20 Apr 2007 15:20:28 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 74E1721760B for ; Fri, 20 Apr 2007 11:20:30 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 20 Apr 2007 11:20:29 -0400 X-Sasl-enc: NBq5lMzVa6st4vveEf3gOdvxuRBiT2TPtB6kd/QNkkJu 1177082428 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 84D3F2942D for ; Fri, 20 Apr 2007 11:20:28 -0400 (EDT) Message-ID: <4628DA3A.3050309@incunabulum.net> Date: Fri, 20 Apr 2007 16:20:26 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.10 (X11/20070407) MIME-Version: 1.0 To: FreeBSD-Net mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: MFC of ether_input() changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 15:20:29 -0000 Hi, Does anyone want to see these changes MFCed, or otherwise object to such an MFC? The introduction of M_PROMISC did the following: * Drop frames immediately if the interface is not marked IFF_UP. * Always trim off the frame checksum if present. * Always use M_VLANTAG in preference to passing 802.1Q frames to consumers. * Use __func__ consistently for KASSERT(). * Use the M_PROMISC flag to detect situations where ether_input() may reenter itself on the same call graph with the same mbuf which was promiscuously received on behalf of subsystems such as netgraph, carp, and vlan. * 802.1P frames (that is, VLAN frames with an ID of 0) will now be passed to layer 3 input paths. * Deal with the special case for CARP in a sane way. For end users the main change of interest will be the ability for FreeBSD to receive 802.1p frames, even if it doesn't do anything with the priority fields right now. If I hear 'yeses' I will try to MFC this as time permits. Regards, BMS From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 16:03:52 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A25916A406 for ; Fri, 20 Apr 2007 16:03:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outR.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id 7771113C44C for ; Fri, 20 Apr 2007 16:03:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Fri, 20 Apr 2007 08:31:50 -0700 Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2BC56125AE1; Fri, 20 Apr 2007 09:03:51 -0700 (PDT) Message-ID: <4628E470.1080207@elischer.org> Date: Fri, 20 Apr 2007 09:04:00 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Bruce M Simpson References: <4628DA3A.3050309@incunabulum.net> In-Reply-To: <4628DA3A.3050309@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Net mailing list Subject: Re: MFC of ether_input() changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 16:03:52 -0000 Bruce M Simpson wrote: > Hi, > > Does anyone want to see these changes MFCed, or otherwise object to such > an MFC? > The introduction of M_PROMISC did the following: > > * Drop frames immediately if the interface is not marked IFF_UP. ok > * Always trim off the frame checksum if present. > * Always use M_VLANTAG in preference to passing 802.1Q frames > to consumers. ok, though I may have to change production code (or at least retest it) > * Use __func__ consistently for KASSERT(). ok > * Use the M_PROMISC flag to detect situations where ether_input() > may reenter itself on the same call graph with the same mbuf which > was promiscuously received on behalf of subsystems such as > netgraph, carp, and vlan. ok > * 802.1P frames (that is, VLAN frames with an ID of 0) will now be > passed to layer 3 input paths. > * Deal with the special case for CARP in a sane way. I don't use CARP > > For end users the main change of interest will be the ability for > FreeBSD to receive 802.1p frames, even if it doesn't do anything with > the priority fields right now. > > If I hear 'yeses' I will try to MFC this as time permits. OK by me, but I defer to anyone who says no.. > > Regards, > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 16:53:31 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1301516A400 for ; Fri, 20 Apr 2007 16:53:31 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 554C913C489 for ; Fri, 20 Apr 2007 16:53:29 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l3KGrPkt052360; Sat, 21 Apr 2007 00:53:25 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l3KGrP89052359; Sat, 21 Apr 2007 00:53:25 +0800 (KRAST) (envelope-from eugen) Date: Sat, 21 Apr 2007 00:53:25 +0800 From: Eugene Grosbein To: Bruce M Simpson Message-ID: <20070420165325.GA51541@svzserv.kemerovo.su> References: <4628DA3A.3050309@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4628DA3A.3050309@incunabulum.net> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD-Net mailing list Subject: Re: MFC of ether_input() changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 16:53:31 -0000 On Fri, Apr 20, 2007 at 04:20:26PM +0100, Bruce M Simpson wrote: > For end users the main change of interest will be the ability for > FreeBSD to receive 802.1p frames, even if it doesn't do anything with > the priority fields right now. > > If I hear 'yeses' I will try to MFC this as time permits. The ability to deal with 802.1p is nice, and I'd like to see this happen hoping that would be another step towards more mature QoS support. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 17:43:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBA9F16A414 for ; Fri, 20 Apr 2007 17:43:18 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2A613C4DE for ; Fri, 20 Apr 2007 17:43:18 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id l3KHhI9c067847; Fri, 20 Apr 2007 10:43:18 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id l3KHhIrP067846; Fri, 20 Apr 2007 10:43:18 -0700 (PDT) (envelope-from rizzo) Date: Fri, 20 Apr 2007 10:43:18 -0700 From: Luigi Rizzo To: Bruce M Simpson Message-ID: <20070420104318.A67833@xorpc.icir.org> References: <4628DA3A.3050309@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4628DA3A.3050309@incunabulum.net>; from bms@incunabulum.net on Fri, Apr 20, 2007 at 04:20:26PM +0100 Cc: FreeBSD-Net mailing list Subject: Re: MFC of ether_input() changes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 17:43:18 -0000 On Fri, Apr 20, 2007 at 04:20:26PM +0100, Bruce M Simpson wrote: > Hi, > > Does anyone want to see these changes MFCed, or otherwise object to such > an MFC? > The introduction of M_PROMISC did the following: > > * Drop frames immediately if the interface is not marked IFF_UP. > * Always trim off the frame checksum if present. > * Always use M_VLANTAG in preference to passing 802.1Q frames > to consumers. > * Use __func__ consistently for KASSERT(). > * Use the M_PROMISC flag to detect situations where ether_input() > may reenter itself on the same call graph with the same mbuf which > was promiscuously received on behalf of subsystems such as > netgraph, carp, and vlan. > * 802.1P frames (that is, VLAN frames with an ID of 0) will now be > passed to layer 3 input paths. > * Deal with the special case for CARP in a sane way. > > For end users the main change of interest will be the ability for > FreeBSD to receive 802.1p frames, even if it doesn't do anything with > the priority fields right now. > > If I hear 'yeses' I will try to MFC this as time permits. yes please! luigi From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 19:20:55 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB0F816A400 for ; Fri, 20 Apr 2007 19:20:55 +0000 (UTC) (envelope-from webmaster@web-tricks.net) Received: from smtp2.abac.com (smtp2.abac.com [216.55.128.210]) by mx1.freebsd.org (Postfix) with ESMTP id C81B913C448 for ; Fri, 20 Apr 2007 19:20:55 +0000 (UTC) (envelope-from webmaster@web-tricks.net) Received: from c-24-23-32-234.hsd1.ca.comcast.net ([24.23.32.234] helo=dragon) by smtp2.abac.com with esmtpa id 1Heyf9-000CbR-Ed for freebsd-net@freebsd.org; Fri, 20 Apr 2007 12:20:55 -0700 Message-ID: <007701c78381$1a690ae0$dedca8c0@dragon> From: Cc: References: <002901c782f3$0b4789d0$dedca8c0@dragon> <20070420103357.GF5257@turion.vk2pj.dyndns.org> Date: Fri, 20 Apr 2007 12:21:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Subject: Re: New Config of Jails & 4 port NIC with 6.2 stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 19:20:55 -0000 Ok, thanks, i see more! This helps a grate deal I will be back as i goof stuff up, LOL Thank you much ----- Original Message ----- From: Peter Jeremy To: webmaster@web-tricks.net Cc: freebsd-net@freebsd.org Sent: Friday, April 20, 2007 3:33 AM Subject: Re: New Config of Jails & 4 port NIC with 6.2 stable From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 19:26:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFE9F16A404 for ; Fri, 20 Apr 2007 19:26:56 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A3C9813C4C7 for ; Fri, 20 Apr 2007 19:26:55 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Heyku-00027d-RO for freebsd-net@freebsd.org; Fri, 20 Apr 2007 21:26:52 +0200 Received: from 83-131-172-117.adsl.net.t-com.hr ([83.131.172.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 21:26:52 +0200 Received: from ivoras by 83-131-172-117.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 21:26:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Fri, 20 Apr 2007 21:26:38 +0200 Lines: 50 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBC8984628C2F9087825C18F6" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 83-131-172-117.adsl.net.t-com.hr User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) X-Enigmail-Version: 0.94.3.0 Sender: news Subject: Network interface failover in 6.2? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 19:26:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBC8984628C2F9087825C18F6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I need to set up a simple NIC failover in a 6.2 host, connected to Cisco 2950 switches. From searching the web it seems that the simples option for me is to use ng_fec (I'd rather use trunk/lagg, but I can't use -current for this). Since I haven't used netgraph before, I'd appreciate any advices and caveats (especially: is anyone using this in production?)= =2E =46rom documentation and examples found on the web it looks like I need t= o do this: ngctl mkpeer fec dummy fec ngctl msg fec0: add_iface '"em0"' ngctl msg fec0: add_iface '"em1"' ifconfig fec0 up ifconfig fec0 inet x netmask y Is this correct / all? I also found a pointer to use ng_one2many but a) ng_fec is supposed to make use of the router's support (FEC), and b) it looks more complicated to configure. What is the practical meaning / difference between mode_mac and mode_inet in ng_fec? One other thing: where should I add the above configuration? In /etc/rc.local? --------------enigBC8984628C2F9087825C18F6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKRPuldnAQVacBcgRAhIDAKD9MfNbNN54SA8GhLYyAzW5+reZggCg8fEa mpEMciHxc+b+7BgT5aaZpFc= =deO/ -----END PGP SIGNATURE----- --------------enigBC8984628C2F9087825C18F6-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 21:24:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AEF116A401 for ; Fri, 20 Apr 2007 21:24:56 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from straycat.dhs.org (c-24-63-86-11.hsd1.ma.comcast.net [24.63.86.11]) by mx1.freebsd.org (Postfix) with ESMTP id 9268613C46C for ; Fri, 20 Apr 2007 21:24:55 +0000 (UTC) (envelope-from tmclaugh@sdf.lonestar.org) Received: from [192.168.1.127] (bofh.straycat.dhs.org [192.168.1.127]) by straycat.dhs.org (8.13.8/8.13.8) with ESMTP id l3KLOmN7021048; Fri, 20 Apr 2007 17:24:50 -0400 (EDT) From: Tom McLaughlin To: Alexander Motin In-Reply-To: <4628A8B3.2090900@mavhome.dp.ua> References: <1176776612.00725618.1176764402@10.7.7.3> <1176816181.00725799.1176802803@10.7.7.3> <4628A8B3.2090900@mavhome.dp.ua> Content-Type: text/plain Date: Fri, 20 Apr 2007 17:24:48 -0400 Message-Id: <1177104288.2950.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Nikos Vassiliadis Subject: Re: net/mpd4: Unable to pass pass traffic as pptp client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 21:24:56 -0000 On Fri, 2007-04-20 at 14:49 +0300, Alexander Motin wrote: > 232487741 > Nikos Vassiliadis wrote: > >>pptp0: connecting to 208.206.3.5 1723 > >>[vpn] IPCP: LayerUp > >> 172.30.29.9 -> 208.206.3.5 > > > >>ifconfig > >>[root@bofh tom]# ifconfig ng0 > >>ng0: flags=88d1 mtu 1396 > >> inet 172.30.29.9 --> 208.206.3.5 netmask 0xffffffff > > > > It seems that your external peer address is the same with the internal > > peer address. You connect to pptp-server-ip through your linksys and > > then say that pptp-server-ip is reachable through the tunnel. So it > > routes everything destined for pptp-server-ip through the tunnel. I > > think that such configuration is valid for other operating systems. > > I don't know if you can work-around the problem on your own, maybe > > you have to contact the VPN concentrator's admin. Perhaps you can > > modify the routing table (the external peer address should be reachable > > as it was, though linksys) and invent some peer address using > > "ifconfig ng0 your_address 10.0.0.1 netmask 0xffffffff". > > But it's not nice... > > > > Can you convice the concentrator's administrator to use another > > address for his internal side? > > It would be a better way. But if it is not possible you could use 'ipfw > fwd' rule to forward all PPTP's GRE and controling TCP packets via > physical interface instead of tunnel. > I found some doc after googling and I followed the instructions here: http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn/fbsd-cisco-vpn.pdf That's gotten me closer. I created an iface up-script to fix the routes after connecting. [root@bofh tom]# netstat -r -f inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default linksys UGS 0 81879 em0 localhost localhost UH 0 96 lo0 172.30 172.30.16.14 UGS 0 2 ng0 172.30.16.14 172.30.29.64 UH 1 2 ng0 172.30.29.64/32 lo0 US 0 0 lo0 192.168.1 link#2 UC 0 0 em0 linksys 00:06:25:dc:a0:f1 UHLW 2 0 em0 884 shorthair 00:09:5b:0b:78:e2 UHLW 1 9169 em0 720 COMPASS 00:11:d8:f9:70:aa UHLW 1 26909 em0 1039 192.168.1.255 ff:ff:ff:ff:ff:ff UHLWb 1 341 em0 [root@bofh tom]# ifconfig ng0 ng0: flags=88d1 mtu 1396 inet 172.30.29.64 --> 172.30.16.14 netmask 0xffffffff I tried pinging while sniffing ng0 and em0 and I see the ping traveling through ng0 and then a PPP compressed data packet out em0. I end up receiving back a PPP LCP protocol reject from the concentrator back to em0 and the following message from mpd4 [vpn] LCP: rec'd Protocol Reject #2 link 0 (Opened) [vpn] LCP: protocol 0xee0b was rejected One bit of advice I received was turning off encryption but this is not an option for me. This same issue appears to have been around since mpd3. tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | | BSD# http://www.mono-project.com/Mono:FreeBSD | From owner-freebsd-net@FreeBSD.ORG Fri Apr 20 23:40:51 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7777016A404 for ; Fri, 20 Apr 2007 23:40:51 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 6121713C46C for ; Fri, 20 Apr 2007 23:38:36 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3KNcYGW053284 for ; Sat, 21 Apr 2007 03:38:34 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3KNaJGv053249; Sat, 21 Apr 2007 03:36:19 +0400 (MSD) (envelope-from yar) Date: Sat, 21 Apr 2007 03:36:19 +0400 From: Yar Tikhiy To: Alan Garfield Message-ID: <20070420233619.GC52136@comp.chem.msu.su> References: <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> <20070419113842.GE60301@comp.chem.msu.su> <1176990600.4177.26.camel@hiro.auspc.com.au> <20070419175331.GA5999@comp.chem.msu.su> <1177077805.4063.7.camel@hiro.auspc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1177077805.4063.7.camel@hiro.auspc.com.au> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 23:40:51 -0000 On Sat, Apr 21, 2007 at 12:03:25AM +1000, Alan Garfield wrote: > On Thu, 2007-04-19 at 21:53 +0400, Yar Tikhiy wrote: > > > 1. Ping the Linux side with packets close to the MTU in size (ping > > -s), use different data patterns (ping -p), see with tcpdump -X if > > the data gets damaged. > > Yeah I figured out. I wasn't handling mbuf chains properly so a bit of > the packet wasn't being put into the buffer. Fixed that now.... > > BUT! > > Now I get this after I log in and try to output anything more than a few > characters (eg. ls -la) :- > > ---- > Disconnecting: Corrupted MAC on input. > ---- That looks like data corruption happening when TCP segments and/or IP packets become relatively large, i.e., approach or reach the mtu limit. > I'm sure it's something to do with how I'm doing the output. Does this > look sane? Well, there's certain space for improvement, but now I fail to find a bug that would result in corrupted data. Would you mind testing the link with ping using packets of size equal to, just below, and slightly above the mtu, and with different data patterns? See -s and -p options to ping. You can observe the patterns in echo replies with tcpdump -X. The data patterns in echo requests and echo replies should be exactly the same. If they aren't, the character of corruption can hint you at the bug. > ---- > static void > jnet_start_locked(struct ifnet* ifp) > { > /* {{{ */ > struct jnet_softc *sc = ifp->if_softc; > struct mbuf *m0, *m; > int i, total_len; > > //device_printf(sc->dev, "jnet_start_locked() called.\n"); > > JNET_ASSERT_LOCKED(sc); > > outputloop: > > if ((&ifp->if_snd)->ifq_len == TX_QUEUE_SIZE || > (&ifp->if_snd)->ifq_drv_len == TX_QUEUE_SIZE) { > > /* No room left. Set OACTIVE to tell everyone */ > ifp->if_drv_flags |= IFF_DRV_OACTIVE; > return; > } > > IFQ_DRV_DEQUEUE(&ifp->if_snd, m); > > if (m == 0) { > > /* > * Space is still available in buffers so allow > * new packets to be added > */ > ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; > return; > } > > m0 = m; > > /* set address counter to zero, then read the entire fifo */ > bus_space_write_1(sc->iot[PRS1_IO_OFFSET], > sc->ioh[PRS1_IO_OFFSET], PRS1_STATUS_OFFSET, 0x00); > > /* Output the IP_CHAR to tell SP the buffer is an IP packet */ > bus_space_write_1(sc->iot[PRS1_IO_OFFSET], > sc->ioh[PRS1_IO_OFFSET], PRS1_DATA_OFFSET, IP_CHAR); > > total_len = 0; > > // Loop over mbuf chain and output data to PRS1 DATA register - > Packet max length should > // already be worked out by the upper layers > while (m0) { > > if(m0->m_len) { > total_len += m0->m_len; > > /* Output ethernet frame to prs buffer */ > bus_space_write_multi_1(sc->iot[PRS1_IO_OFFSET], > sc->ioh[PRS1_IO_OFFSET], > PRS1_DATA_OFFSET, mtod(m0, > unsigned char *), m0->m_len); > > } > m0 = m0->m_next; > } > > device_printf(sc->dev, "len: %i padding: %i total: %i\n", > total_len, FRAME_SIZE - total_len, total_len + > (FRAME_SIZE - total_len)); > > /* Added padding to fill what's left of the buffer */ > for (i = total_len; i < FRAME_SIZE; i++) { > bus_space_write_1(sc->iot[PRS1_IO_OFFSET], > sc->ioh[PRS1_IO_OFFSET], PRS1_DATA_OFFSET, 0x00); > } > > m0 = m; > > BPF_MTAP(ifp, m0); > > m_freem(m0); > > /* Loop to top to possibly buffer more packets */ > goto outputloop; > } > ---- > > > > > Nevertheless, it can be a reference driver working with real hardware > > for other folks to study. > > It's simple enough once I figured out where the pitfalls are. :) > > -A. -- Yar From owner-freebsd-net@FreeBSD.ORG Sat Apr 21 16:30:13 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D2B216A400 for ; Sat, 21 Apr 2007 16:30:13 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4EBD113C43E for ; Sat, 21 Apr 2007 16:30:13 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.197] (c220-239-255-86.rivrw3.nsw.optusnet.com.au [220.239.255.86]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 404905C18; Sun, 22 Apr 2007 02:30:12 +1000 (EST) Message-ID: <462A3BF1.5070202@fromorbit.com> Date: Sun, 22 Apr 2007 02:29:37 +1000 From: Alan Garfield User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Yar Tikhiy References: <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> <20070419113842.GE60301@comp.chem.msu.su> <1176990600.4177.26.camel@hiro.auspc.com.au> <20070419175331.GA5999@comp.chem.msu.su> <1177077805.4063.7.camel@hiro.auspc.com.au> <20070420233619.GC52136@comp.chem.msu.su> In-Reply-To: <20070420233619.GC52136@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 16:30:13 -0000 Yar Tikhiy wrote: >> ---- >> Disconnecting: Corrupted MAC on input. >> ---- > > That looks like data corruption happening when TCP segments and/or > IP packets become relatively large, i.e., approach or reach the mtu > limit. Indeed that would appear to be the case. >> I'm sure it's something to do with how I'm doing the output. Does this >> look sane? > > Well, there's certain space for improvement, Aww it's not _that_ bad is it. :) hehe > but now I fail to find a > bug that would result in corrupted data. Phew /me wipes brow... so I'm not _totally_ useless then. :) > Would you mind testing the link with ping using packets of size > equal to, just below, and slightly above the mtu, and with different > data patterns? See -s and -p options to ping. You can observe the > patterns in echo replies with tcpdump -X. The data patterns in > echo requests and echo replies should be exactly the same. If they > aren't, the character of corruption can hint you at the bug. I've done a pretty preliminary tcpdump'ing and the packets seem ok above and below the MTU via the bpf taps. I wonder if it's a bug in the SP side... then again I could be completely off base and it's all my dodgy codes fault. :) I'll poke around with tcpdump and ping a bit more. Many thanks again Yar, Alan.