From owner-freebsd-net@FreeBSD.ORG Sun Jun 29 16:36:05 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2640437B401 for ; Sun, 29 Jun 2003 16:36:05 -0700 (PDT) Received: from jchurch.neville-neil.com (jchurch.neville-neil.com [209.157.133.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9472B44027 for ; Sun, 29 Jun 2003 16:36:04 -0700 (PDT) (envelope-from gnn@neville-neil.com) Received: from jchurch.neville-neil.com.neville-neil.com (localhost [127.0.0.1])h5TNa3jb074274 for ; Sun, 29 Jun 2003 16:36:03 -0700 (PDT) (envelope-from gnn@neville-neil.com) Date: Sun, 29 Jun 2003 16:36:03 -0700 Message-ID: <87y8zkwj6k.wl@jchurch.neville-neil.com.neville-neil.com> From: "George V. Neville-Neil" To: freebsd-net@freebsd.org User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Subject: Another question on locking... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 29 Jun 2003 23:36:05 -0000 Hi, Looking at the code in uipc_socket.c and udp_usrreq.c I am a bit confused as to how the locking mechanism works between the sockets and the protocols. The socket calls all occur under Giant, which the protocols do not deal with, and the protocols all lock on the inp mutex, which the socket calls do not deal with. Furthermore the sblock/sbunlock calls are only use by the socket layer. I'm reading udp_input() as it's simpler to follow. Have I missed something? What prevents a protocol from writing to a socket buffer at the wrong time or the socket code from tweaking it at the wrong time? Is this handled simply because of the priority of the threads doing the work? Thanks, George From owner-freebsd-net@FreeBSD.ORG Sun Jun 29 17:56:41 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D9A637B401 for ; Sun, 29 Jun 2003 17:56:41 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C26424400B for ; Sun, 29 Jun 2003 17:56:40 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h5U0u6KJ095712; Sun, 29 Jun 2003 20:56:06 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h5U0u6Gg095709; Sun, 29 Jun 2003 20:56:06 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 29 Jun 2003 20:56:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "George V. Neville-Neil" In-Reply-To: <87y8zkwj6k.wl@jchurch.neville-neil.com.neville-neil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Another question on locking... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 30 Jun 2003 00:56:41 -0000 The locking in the -CURRENT tree for the socket stack is currently incomplete; something we hope greatly to remedy on the way to 5.2-RELEASE. So currently all this code runs under the Giant lock, which is why it's safe. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories On Sun, 29 Jun 2003, George V. Neville-Neil wrote: > Hi, > > Looking at the code in uipc_socket.c and udp_usrreq.c I am a > bit confused as to how the locking mechanism works between the > sockets and the protocols. The socket calls all occur under > Giant, which the protocols do not deal with, and the protocols > all lock on the inp mutex, which the socket calls do not deal > with. Furthermore the sblock/sbunlock calls are only use by > the socket layer. I'm reading udp_input() as it's simpler to > follow. Have I missed something? What prevents a protocol > from writing to a socket buffer at the wrong time or the > socket code from tweaking it at the wrong time? Is this > handled simply because of the priority of the threads doing > the work? > > Thanks, > George > _______________________________________________ > 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 Sun Jun 29 19:28:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6035437B401 for ; Sun, 29 Jun 2003 19:28:10 -0700 (PDT) Received: from mails.tsinghua.edu.cn (mails.tsinghua.edu.cn [166.111.8.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68AB643FE3 for ; Sun, 29 Jun 2003 19:28:09 -0700 (PDT) (envelope-from lguohan00@mails.tsinghua.edu.cn) Received: (eyou send program); Mon, 30 Jun 2003 10:24:58 +0800 Message-ID: <256939898.27476@mails.tsinghua.edu.cn> X-EYOUMAIL-SMTPAUTH: lguohan00@mails.tsinghua.edu.cn Received: from unknown (HELO garfield) (unknown@210.25.128.102) by 166.111.8.16 with SMTP; Mon, 30 Jun 2003 10:24:58 +0800 Message-ID: <004001c33eaf$0858ebb0$668019d2@garfield> From: "Lu Guohan" To: Date: Mon, 30 Jun 2003 10:26:37 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [TCP Bug]The snd_cwnd is set to very very large size. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 30 Jun 2003 02:28:10 -0000 SGVsbG8sDQogICAgDQpCcmllZiBEZXNjcmlwdGlvbjoNCiAgICBJbiB0aGUgbG9zcyByZWNvdmVy eSBwaGFzZSwgd2hlbiBhIHJldHJhbnNtaXQgcGFja2V0IGdldCBsb3N0LCB0aGUgc2VuZGVyIHdp bGwgZmluYWxseSB0aW1lb3V0LiBUaGVuLCBhZnRlciB0aGUgc2VuZGVyIHJlY2VpdmVzIHRoZSB0 aGUgYWNrIHBhY2tldCB0aGF0IGFja2VkIHRoZSByZXRyYW5zbWl0dGVkIHBhY2tldCwgaW4gY2Vy dGFpbiBzaXR1YXRpb25zLCB0aGUgc2VuZGVyIHdpbGwgcmVnYXJkIHRoZSBhY2sgYXMgYW4gcGFy dGlhbCBhY2ssIHdoZXJlIHRoZSAnc25kX2N3bmQnIHdpbGwgYmUgc2V0IHRvIGEgdmVyeSBsYXJn ZSBzaXplLCBhcHByb3htYXRlbHkgdG8gdGhlIG1heGltdW0gdmFsdWUgb2YgYSB1X2xvbmcgaW50 ZWdlci4gQW5kIHRvdGFsIGJ5dGVzIGVxdWFscyB0byBhIHJlY2VpdmVyIHdpbmRvdyBzaXplIHdp bGwgYmUgc2VudCBvdXQgaW4gYSBidXJzdC4NCg0KVHJhY2VzOg0KKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNClNlbmRlciBTaWRlOg0KMDY6MDE6MzMuNDI0MDQ0IE9yc29uLmNvbW1w bGV4LWxpbmsgPiBSb3lGNV8xLjQ5MTYxOiAuIGFjayA1MTExNjkgd2luIDMwNDA4DQowNjowMToz My40MjQ2MzUgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTE0MDY1OjUx NTUxMygxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgIFtMT1NUIV0gDQowNjowMTozMy40MjQ3MTggUm95 RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTE1NTEzOjUxNjk2MSgxNDQ4KSBh Y2sgMSB3aW4gMzMzMDQNCjA2OjAxOjMzLjQyNDgyNiBSb3lGNV8xLjQ5MTYxID4gT3Jzb24uY29t bXBsZXgtbGluazogLiA1MTY5NjE6NTE4NDA5KDE0NDgpIGFjayAxIHdpbiAzMzMwNCANCjA2OjAx OjMzLjQyODcxMCBPcnNvbi5jb21tcGxleC1saW5rID4gUm95RjVfMS40OTE2MTogLiBhY2sgNTEy NjE3IHdpbiAzMTg1NiANCjA2OjAxOjMzLjQyOTI4MSBSb3lGNV8xLjQ5MTYxID4gT3Jzb24uY29t bXBsZXgtbGluazogLiA1MTg0MDk6NTE5ODU3KDE0NDgpIGFjayAxIHdpbiAzMzMwNA0KMDY6MDE6 MzMuNTM4NTQyIE9yc29uLmNvbW1wbGV4LWxpbmsgPiBSb3lGNV8xLjQ5MTYxOiAuIGFjayA1MTQw NjUgd2luIDMxODU2IA0KMDY6MDE6MzMuNTM5MTc3IFJveUY1XzEuNDkxNjEgPiBPcnNvbi5jb21t cGxleC1saW5rOiAuIDUxOTg1Nzo1MjEzMDUoMTQ0OCkgYWNrIDEgd2luIDMzMzA0ICBbTE9TVCFd DQowNjowMTozMy44MTkwMTcgT3Jzb24uY29tbXBsZXgtbGluayA+IFJveUY1XzEuNDkxNjE6IC4g YWNrIDUxNDA2NSB3aW4gMzE4NTYgDQowNjowMTozMy44MTk4NTAgT3Jzb24uY29tbXBsZXgtbGlu ayA+IFJveUY1XzEuNDkxNjE6IC4gYWNrIDUxNDA2NSB3aW4gMzE4NTYgDQowNjowMTozMy44MjIx MDkgT3Jzb24uY29tbXBsZXgtbGluayA+IFJveUY1XzEuNDkxNjE6IC4gYWNrIDUxNDA2NSB3aW4g MzE4NTYgDQowNjowMTozMy44MjI1MjggUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxp bms6IC4gNTE0MDY1OjUxNTUxMygxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgIERVUDNbTE9TVCFdDQow NjowMTozNC40ODgwNTUgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTE0 MDY1OjUxNTUxMygxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgIFRPW0xPU1QhXQ0KMDY6MDE6MzUuNjM2 OTgwIFJveUY1XzEuNDkxNjEgPiBPcnNvbi5jb21tcGxleC1saW5rOiAuIDUxNDA2NTo1MTU1MTMo MTQ0OCkgYWNrIDEgd2luIDMzMzA0ICBUTw0KMDY6MDE6MzYuMDMwNDE2IE9yc29uLmNvbW1wbGV4 LWxpbmsgPiBSb3lGNV8xLjQ5MTYxOiAuIGFjayA1MTk4NTcgd2luIDI2MDY0DQowNjowMTozNi4w MzA0NTIgT3Jzb24uY29tbXBsZXgtbGluayA+IFJveUY1XzEuNDkxNjE6IC4gYWNrIDUxOTg1NyB3 aW4gMzE4NTYNCi0tLS0tLS0tLUJ1cnN0IG9mIHBhY2tldHMgDQowNjowMTozNi4wMzEwMDggUm95 RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTE5ODU3OjUyMTMwNSgxNDQ4KSBh Y2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzExNDYgUm95RjVfMS40OTE2MSA+IE9yc29uLmNv bW1wbGV4LWxpbms6IC4gNTIxMzA1OjUyMjc1MygxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjow MTozNi4wMzEyNTcgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTIyNzUz OjUyNDIwMSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzEzNTQgUm95RjVfMS40 OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTI0MjAxOjUyNTY0OSgxNDQ4KSBhY2sgMSB3 aW4gMzMzMDQgDQowNjowMTozNi4wMzE0NTEgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4 LWxpbms6IC4gNTI1NjQ5OjUyNzA5NygxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4w MzE2MjIgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTI3MDk3OjUyODU0 NSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzE3MjUgUm95RjVfMS40OTE2MSA+ IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTI4NTQ1OjUyOTk5MygxNDQ4KSBhY2sgMSB3aW4gMzMz MDQgDQowNjowMTozNi4wMzE4MzIgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6 IC4gNTI5OTkzOjUzMTQ0MSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzI2NDcg Um95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTMxNDQxOjUzMjg4OSgxNDQ4 KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzI3MDEgUm95RjVfMS40OTE2MSA+IE9yc29u LmNvbW1wbGV4LWxpbms6IC4gNTMyODg5OjUzNDMzNygxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQow NjowMTozNi4wMzI4MjkgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTM0 MzM3OjUzNTc4NSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzI4NzQgUm95RjVf MS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTM1Nzg1OjUzNzIzMygxNDQ4KSBhY2sg MSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzI5MjcgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1w bGV4LWxpbms6IC4gNTM3MjMzOjUzODY4MSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMToz Ni4wMzI5ODQgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTM4NjgxOjU0 MDEyOSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzMwMjkgUm95RjVfMS40OTE2 MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTQwMTI5OjU0MTU3NygxNDQ4KSBhY2sgMSB3aW4g MzMzMDQgDQowNjowMTozNi4wMzMwNzkgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxp bms6IC4gNTQxNTc3OjU0MzAyNSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzMx MzkgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTQzMDI1OjU0NDQ3Mygx NDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzMxODggUm95RjVfMS40OTE2MSA+IE9y c29uLmNvbW1wbGV4LWxpbms6IC4gNTQ0NDczOjU0NTkyMSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQg DQowNjowMTozNi4wMzMyMzYgUm95RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IFAg NTQ1OTIxOjU0NzM2OSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzQwNTggUm95 RjVfMS40OTE2MSA+IE9yc29uLmNvbW1wbGV4LWxpbms6IC4gNTQ3MzY5OjU0ODgxNygxNDQ4KSBh Y2sgMSB3aW4gMzMzMDQgDQowNjowMTozNi4wMzQ1MzAgUm95RjVfMS40OTE2MSA+IE9yc29uLmNv bW1wbGV4LWxpbms6IC4gNTQ4ODE3OjU1MDI2NSgxNDQ4KSBhY2sgMSB3aW4gMzMzMDQNCjA2OjAx OjM2LjAzNDYzMCBSb3lGNV8xLjQ5MTYxID4gT3Jzb24uY29tbXBsZXgtbGluazogLiA1NTAyNjU6 NTUxNzEzKDE0NDgpIGFjayAxIHdpbiAzMzMwNCANCioqKioqKioqKioqKioqKioqKioqKioqKioq KioNCg0KDQpEZXNjcmlwdGlvbiB3aXRoIENvZGU6DQoxLiBXaGVuIGEgcGFja2V0IGlzIGxvc3Qg YW5kIDMgZHVwYWNrcyByZWNlaXZlZCwgVENQIHNldHMgc25kX3JlY292ZXIgPSBzbmRfbWF4IGFu ZCByZXRyYW5zbWl0IHRoZSBwYWNrZXQuKHRjcF9pbnB1dC5jKQ0KDQoyLiBUaGUgcmV0cmFuc21p dGVkIHBhY2tldCBnZXQgbG9zdCwgYW5kIHRpbWVvdXQgaGFwcGVucy4gVGhlbiwgVENQIHNldHMg c25kX2N3bmQgPSB0X21heHNlZy4odGNwX3RpbWVyLmMpDQoNCjMuIFdoZW4gdGhlIGFjayBvZiB0 aGUgcmV0cmFuc21pdGVkIHBhY2tldCBhcnJpdmVzLCBUQ1AgY2hlY2tzIGlmIHRoZSBhY2sgaXMg YSBwYXJ0aWFsIGFjazoNCiAgaWYgKHRjcF9kb19uZXdyZW5vKSB7DQogICBpZiAoU0VRX0xUKHRw LT5zbmRfdW5hLCB0cC0+c25kX3JlY292ZXIpKSB7DQogICAgaWYgKFNFUV9MVCh0aC0+dGhfYWNr LCB0cC0+c25kX3JlY292ZXIpKSB7DQoNCiAgSWYgbXVsdGlwbGUgZGF0YSBwYWNrZXRzIGdldCBs b3N0IGluIHRoZSBwcmV2aW91cyByb3VuZCwgdGhlIGFjayB3aWxsIGJlIHJlZ2FyZGVkIGFzIHBh cnRpYWwgYWNrcywgYW5kIHRjcF9uZXdyZW5vX3BhcnRpYWxfYWNrKCkgaXMgY2FsbGVkLg0KDQo0 LiBJbiB0Y3BfbmV3cmVub19wYXJ0aWFsX2FjaygpLCBzbmRfY3duZCB3aWxsIGJlIHJlc2V0LiAN CiAgICB0cC0+c25kX2N3bmQgLT0gKHRoLT50aF9hY2sgLSB0cC0+c25kX3VuYSAtIHRwLT50X21h eHNlZyk7DQogICBJbiB0aGlzIHNpdHVhdGlvbiwgc25kX2N3bmQgPSB0X21heHNlZywgYW5kICh0 aF9hY2sgLSBzbmRfdW5hIC0gdF9tYXhzZWcpIHdpbGwgdXN1YWxseSBiaWdnZXIgdGhhbiB0aGUg dF9tYXhzZWcsIHNvIHNuZF9jd25kIHdpbGwgYmUgc2V0IHRvIGEgdmVyeSBsYXJnZSB2YWx1ZS4N Cg0KU3VnZ2VzdGVkIFNvbHV0aW9uOg0KICAgUmVzZXQgdGhlIHNuZF9yZWNvdmVyIHRvIHRoX2Fj ayBpbiB0Y3BfdGltZXJfcmV4bXQoKS4gQmVjYXVzZSBpZiB0aW1lb3V0IGhhcHBlbnMsIGl0IG1l YW5zIHdlIGFyZSBub3cgc3dpdGNoaW5nIHRvIFRDUCBzbG93IHN0YXJ0IGFsZ29yaXRobSwgYW5k IGxlYXZlIHRoZSBuZXdyZW5vIGxvc3MgcmVjb3ZlcnkgcGhhc2UuIEluIGZyZWVic2QsIHNuZF9y ZWNvdmVyIGlzIHRoZSBtYWluIHNpZ24gdG8gaW5kaWNhdGUgd2hldGhlciB0aGUgVENQIGlzIGlu IG5ld3Jlbm8gTFIgcGhhc2Ugb3Igbm90LiBTbywgc25kX3JlY292ZXIgc2hvdWxkIGJlIHJlc2V0 IGluIHRpbWVvdXQoKS4NCiAgICANCg0KQWZmZWN0ZWQgRnJlZUJTRCB2ZXJzaW9uOg0KbmV3UmVu byB2ZXJzaW9ucyBzdWNoIGFzIFJFTEVORzVfMSwgUkVMRU5HNCwgUkVMRU5HNF84LCBSRUxFTkc0 XzcgLi4uDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpMdSBHdW9o YW4NCkRlcGFydG1lbnQgb2YgRWxlY3Ryb25pYyBFbmdpbmVlcmluZw0KVHNpbmdodWEgVW5pdmVy c2l0eSwgICAgICBQLlIuIENoaW5hDQpsZ3VvaGFuMDBAbWFpbHMudHNpbmdodWEuZWR1LmNuDQoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KDQo= From owner-freebsd-net@FreeBSD.ORG Mon Jun 30 02:24:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C96D37B401 for ; Mon, 30 Jun 2003 02:24:37 -0700 (PDT) Received: from cell.sick.ru (cell.sick.ru [195.91.162.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3338643FCB for ; Mon, 30 Jun 2003 02:24:36 -0700 (PDT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.6/8.12.8) with ESMTP id h5U9OUNx025232 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 30 Jun 2003 13:24:31 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.6/8.12.6/Submit) id h5U9OTp5025231; Mon, 30 Jun 2003 13:24:29 +0400 (MSD) Date: Mon, 30 Jun 2003 13:24:29 +0400 From: Gleb Smirnoff To: Archie Cobbs Message-ID: <20030630092429.GA25207@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Archie Cobbs , freebsd-net@FreeBSD.ORG References: <20030627141126.GA13409@cell.sick.ru> <200306281457.h5SEvEV0017111@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200306281457.h5SEvEV0017111@arch20m.dellroad.org> User-Agent: Mutt/1.5.1i cc: freebsd-net@FreeBSD.ORG Subject: Re: ng_ppp: how to send NGM_PPP_SET_CONFIG? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 30 Jun 2003 09:24:37 -0000 On Sat, Jun 28, 2003 at 09:57:14AM -0500, Archie Cobbs wrote: A> You need a userland daemon, such as mpd (see ports), to control A> the ng_ppp node. With mpd try the "ng" device type. Thanks! I'll try. I have looked into mpd some time ago (espcially into RADIUS and PPPoE parts), but I have missed "ng" device type. It is really universal and helpful. May be it'll be necessary to mention in ng_ppp(4), that it can not act without userland daemon? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Jun 30 12:21:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B618737B401 for ; Mon, 30 Jun 2003 12:21:30 -0700 (PDT) Received: from mail.dada.it (mail3.dada.it [195.110.100.3]) by mx1.FreeBSD.org (Postfix) with SMTP id C705A43FF5 for ; Mon, 30 Jun 2003 12:21:27 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 10913 invoked from network); 30 Jun 2003 19:21:21 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 30 Jun 2003 19:21:21 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id DBF46623D; Mon, 30 Jun 2003 21:21:22 +0200 (CEST) Date: Mon, 30 Jun 2003 21:21:22 +0200 From: Alessandro de Manzano To: net@freebsd.org Message-ID: <20030630212122.A72414@libero.sunshine.ale> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Operating-System: FreeBSD 4.7-STABLE cc: mobile@freebsd.org Subject: strange PPP negotiation problem with GPRS mobile phone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alessandro de Manzano List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 19:21:31 -0000 Hello! I'm having very strange (to me) PPP problems with a 4.8-R notebook trying to connect to the Internet via a GPRS mobile phone. Note: The exactly same hardware works fine with WinXP so it should work under FreeBSD also, I guess ;-)) Situation: I'm using the following /etc/ppp/ppp.conf file (comments removed) default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) set device /dev/cuaa0 set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" set timeout 180 # 3 minute idle timer (the default) enable dns # request DNS info (for resolv.conf) disable ipv6cp disable mppe vodamobile: set speed 57600 set phone +393492002800 set authname set authkey add default HISADDR disable dns vodagprs: set speed 57600 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \"\" ATZ OK-AT-OK ATE1Q0 OK AT+CGDCONT=1,\\\"IP\\\",\\\"web.omnitel.it\\\",\\\"0.0.0.0\\\" OK \\dATDT\\T TIMEOUT 40 CONNECT" set phone *99\# set authname set authkey add default HISADDR # disable dns disable vjcomp disable deflate disable protocomp enable pap as you see it's quite simple. I'm using the "vodagprs" label ("vodamobile" works fine but is GSM 9600 bps) and I got the peculiar AT-commands digging in Google for configs like mine (Motorola T280 + Vodafone Omnitel GPRS) I added later all the "disable XXX" commands trying to resolve the problem, because under WinXP with plain vanilla configuration it works fine (no custom software required), so I thought it could be some odd PPP settings... PPP negotiation starts but ends quite immediately for some problem I can't understand. Here is a typical /var/log/ppp.log snippet: (it is a bit long) Jun 30 20:55:54 asusmobile ppp[133]: Phase: Using interface: tun0 Jun 30 20:55:54 asusmobile ppp[133]: Phase: deflink: Created in closed state Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: default: set device /dev/cuaa0 Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: default: set speed 115200 Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: default: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: default: set timeout 180 Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: default: enable dns Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: default: disable ipv6cp Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: default: disable mppe Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: set speed 57600 Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" ATZ OK-AT-OK ATE1Q0 OK AT+CGDCONT=1,\"IP\",\"web.omnitel.it\",\"0.0.0.0\" OK \dATDT\T TIMEOUT 40 CONNECT Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: set phone *99# Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: set authname Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: set authkey Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: add default HISADDR Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: disable vjcomp Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: disable deflate Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: disable protocomp Jun 30 20:55:54 asusmobile ppp[133]: tun0: Command: vodagprs: enable pap Jun 30 20:55:54 asusmobile ppp[134]: tun0: Phase: PPP Started (background mode). Jun 30 20:55:54 asusmobile ppp[134]: tun0: Phase: bundle: Establish Jun 30 20:55:54 asusmobile ppp[134]: tun0: Phase: deflink: closed -> opening Jun 30 20:55:54 asusmobile ppp[134]: tun0: Phase: deflink: Connected! Jun 30 20:55:54 asusmobile ppp[134]: tun0: Phase: deflink: opening -> dial Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Phone: *99# Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: deflink: Dial attempt 1 of 1 Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Send: ATZ^M Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Expect(5): OK Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Received: ATZ^M^M Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Received: OK^M Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Send: ATE1Q0^M Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Expect(5): OK Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Received: ATE1Q0^M^M Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Received: OK^M Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Send: AT+CGDCONT=1,"IP","web.omnitel.it","0.0.0.0"^M Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Expect(5): OK Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Received: AT+CGDCONT=1,"IP","web.omnitel.it","0.0.0.0"^M^M Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Received: OK^M Jun 30 20:55:54 asusmobile ppp[134]: tun0: Chat: Send: ATDT*99#^M Jun 30 20:55:56 asusmobile ppp[134]: tun0: Chat: Expect(40): CONNECT Jun 30 20:55:56 asusmobile ppp[134]: tun0: Chat: Received: ATDT*99#^M^M Jun 30 20:55:56 asusmobile ppp[134]: tun0: Chat: Received: CONNECT^M Jun 30 20:55:56 asusmobile ppp[134]: tun0: Phase: deflink: dial -> carrier Jun 30 20:55:57 asusmobile ppp[134]: tun0: Phase: deflink: /dev/cuaa0: CD detected Jun 30 20:55:57 asusmobile ppp[134]: tun0: Phase: deflink: carrier -> login Jun 30 20:55:57 asusmobile ppp[134]: tun0: Phase: deflink: login -> lcp Jun 30 20:55:57 asusmobile ppp[134]: tun0: LCP: FSM: Using "deflink" as a transport Jun 30 20:55:57 asusmobile ppp[134]: tun0: LCP: deflink: State change Initial --> Closed Jun 30 20:55:57 asusmobile ppp[134]: tun0: LCP: deflink: State change Closed --> Stopped Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: LayerStart Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACFCOMP[2] Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: State change Stopped --> Req-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(1) state = Req-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(0) state = Req-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACFCOMP[2] Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(2) state = Req-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigReq(32) state = Req-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x000094c8 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigAck(32) state = Req-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x000094c8 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: State change Req-Sent --> Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(2) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(1) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(3) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(3) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(2) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(4) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(4) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(3) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(5) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(5) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(4) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(6) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(6) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(5) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(7) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(7) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(6) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(8) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(8) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(7) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(9) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(9) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(8) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(10) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(10) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(9) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(11) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(11) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(10) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(12) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(12) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(11) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(13) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(13) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(12) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(14) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(14) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(13) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(15) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(15) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(14) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: deflink: Too many LCP REQs sent - abandoning negotiation Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(15) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendTerminateReq(16) state = Ack-Sent Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: State change Ack-Sent --> Closing Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvTerminateAck(16) state = Closing Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: LayerFinish Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: State change Closing --> Closed Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: State change Closed --> Initial Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: deflink: Disconnected! Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: deflink: lcp -> logout Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: deflink: logout -> hangup Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: deflink: Disconnected! Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: deflink: Connect time: 4 secs: 430 octets in, 1659 octets out Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: deflink: 31 packets in, 33 packets out Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: total 522 bytes/sec, peak 0 bytes/sec on Mon Jun 30 20:55:54 2003 Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: deflink: hangup -> closed Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: bundle: Dead Jun 30 20:55:58 asusmobile ppp[134]: tun0: Phase: PPP Terminated (normal). Jun 30 20:55:58 asusmobile ppp[133]: tun0: Phase: Parent: Child failed (errdead) Jun 30 20:55:58 asusmobile ppp[134]: tun0: Chat: Parent notified of failure I hope someone will be so kind and nice to read my mail till this sentence ;) and trying to explain to me what happened in PPP handshake. Have someone else ever been succesful in establishing GPRS data connections with Vodafone (Europe) as ISP ? I accept any hints and suggestion! Many many thanks in advance! :) -- bye! Ale From owner-freebsd-net@FreeBSD.ORG Mon Jun 30 12:44:51 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E609937B401; Mon, 30 Jun 2003 12:44:51 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DA7943FAF; Mon, 30 Jun 2003 12:44:51 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5527C72FE3; Mon, 30 Jun 2003 12:44:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 53C6772FDC; Mon, 30 Jun 2003 12:44:51 -0700 (PDT) Date: Mon, 30 Jun 2003 12:44:51 -0700 (PDT) From: Doug White To: Alessandro de Manzano In-Reply-To: <20030630212122.A72414@libero.sunshine.ale> Message-ID: <20030630124257.M31036@carver.gumbysoft.com> References: <20030630212122.A72414@libero.sunshine.ale> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: mobile@freebsd.org cc: net@freebsd.org Subject: Re: strange PPP negotiation problem with GPRS mobile phone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 30 Jun 2003 19:44:52 -0000 On Mon, 30 Jun 2003, Alessandro de Manzano wrote: > I'm having very strange (to me) PPP problems with a 4.8-R notebook > trying to connect to the Internet via a GPRS mobile phone. Quick analysis: It doesn't like something in the negotiation, since it rejects config attempts. Usually its supposed to tell you what it didn't like, but I'm not seeing that in the printout. Try reducing the MTU. its about the only thing you can adjust :) > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendConfigReq(7) state = Ack-Sent > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: ACCMAP[6] 0x00000000 > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MRU[4] 1500 > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM[6] 0x46e4317a > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: RecvConfigRej(7) state = Ack-Sent I wonder if you can turn this off: > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(6) state = Ack-Sent > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Jun 30 13:28:55 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DEC037B401 for ; Mon, 30 Jun 2003 13:28:55 -0700 (PDT) Received: from daniel.ameriroots.com (daniel.ameriroots.com [64.249.12.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 266B043FA3 for ; Mon, 30 Jun 2003 13:28:54 -0700 (PDT) (envelope-from orville@weyrich.com) Received: from bashful.weyrich.com (bashful.weyrich.com [198.49.110.8]) by btuyet.weyrich.com (8.11.3/8.11.3) with ESMTP id h5U4ljv49103 for ; Sun, 29 Jun 2003 21:47:45 -0700 (MST) (envelope-from orville@weyrich.com) Received: from localhost (orville@localhost) by bashful.weyrich.com (8.11.3/8.11.3) with ESMTP id h5U4Jb130865 for ; Sun, 29 Jun 2003 21:19:37 -0700 (MST) (envelope-from orville@weyrich.com) X-Authentication-Warning: bashful.weyrich.com: orville owned process doing -bs Date: Sun, 29 Jun 2003 21:19:37 -0700 (MST) From: "Orville R. Weyrich_Jr" X-X-Sender: To: In-Reply-To: Message-ID: <20030629211239.G22284-100000@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: SSL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 30 Jun 2003 20:28:55 -0000 I checked the Apache Web site and found an article from 1998 that said that RSA had a patent on encryption needed for SSL in the USA. Somewhere I recall hearing that the patent had expired. Is this true? What I really need (want) is an inexpensive way to give my Apache server a secure channel for users to log in without transmitting cleartext passwords (the actual data after they log in is NOT sensitive, I just need to know that it came from a trusted user). Anybody have current information on how I can comply with US law and meet my requirement as inexpensively as possible? I gather that I can be my own certificate authority if the people running the web browsers trust me to be who I say I am, but there is that pesky RSA license (?). The application is a political organization, not a commercial venture if that is of any benefit in obtaining pattent relief. ------------------------------------------------------------------- Orville R. Weyrich, Jr. Weyrich Computer Consulting mailto:orville@weyrich.com KD7HJV http://www.weyrich.com ------------------------------------------------------------------- From owner-freebsd-net@FreeBSD.ORG Mon Jun 30 13:43:08 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74BAA37B404 for ; Mon, 30 Jun 2003 13:43:08 -0700 (PDT) Received: from mail.dada.it (mail3.dada.it [195.110.100.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 610B443F85 for ; Mon, 30 Jun 2003 13:43:06 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 909 invoked from network); 30 Jun 2003 20:43:02 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 30 Jun 2003 20:43:01 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id 1F474623D; Mon, 30 Jun 2003 22:43:03 +0200 (CEST) Date: Mon, 30 Jun 2003 22:43:03 +0200 From: Alessandro de Manzano To: Doug White Message-ID: <20030630224303.A72949@libero.sunshine.ale> References: <20030630212122.A72414@libero.sunshine.ale> <20030630124257.M31036@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030630124257.M31036@carver.gumbysoft.com>; from dwhite@gumbysoft.com on Mon, Jun 30, 2003 at 12:44:51PM -0700 X-Operating-System: FreeBSD 4.7-STABLE cc: mobile@freebsd.org cc: net@freebsd.org Subject: Re: strange PPP negotiation problem with GPRS mobile phone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alessandro de Manzano List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 20:43:08 -0000 On Mon, Jun 30, 2003 at 12:44:51PM -0700, Doug White wrote: > Quick analysis: It doesn't like something in the negotiation, since it > rejects config attempts. Usually its supposed to tell you what it didn't > like, but I'm not seeing that in the printout. mmm... seems you're right, I'm starting to understand a bit of PPP's logfile ;) All that Recv config Rejected.. > > Try reducing the MTU. its about the only thing you can adjust :) tried, either MTU or MRU, either as "set mtu ..." (1440, 1492, etc.) or "set mtu max ..." , nothing changes :( > I wonder if you can turn this off: > > > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: deflink: SendIdent(6) state = Ack-Sent > > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: MAGICNUM 46e4317a > > Jun 30 20:55:58 asusmobile ppp[134]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Turn off what ? Sorry, but I lost you ;( ;) I'm *sure* it is some stupid/odd thing in PPP config, because that @!#$%& of Win's PPP works fine :(( sigh! However many many thanks for your kind help ! If you've some other hints I'm always here ;)) -- bye! Ale From owner-freebsd-net@FreeBSD.ORG Mon Jun 30 14:29:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4169937B401 for ; Mon, 30 Jun 2003 14:29:04 -0700 (PDT) Received: from fubar.adept.org (fubar.adept.org [63.147.172.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA81143FAF for ; Mon, 30 Jun 2003 14:29:03 -0700 (PDT) (envelope-from mike@adept.org) Received: by fubar.adept.org (Postfix, from userid 1001) id B0DD11524B; Mon, 30 Jun 2003 14:29:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fubar.adept.org (Postfix) with ESMTP id AD44E15247 for ; Mon, 30 Jun 2003 14:29:03 -0700 (PDT) Date: Mon, 30 Jun 2003 14:29:03 -0700 (PDT) From: Mike Hoskins To: freebsd-net@freebsd.org In-Reply-To: <20030629211239.G22284-100000@localhost> Message-ID: <20030630142745.T49599@fubar.adept.org> References: <20030629211239.G22284-100000@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: SSL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 30 Jun 2003 21:29:04 -0000 On Sun, 29 Jun 2003, Orville R. Weyrich_Jr wrote: > I checked the Apache Web site and found an article from 1998 that said > that RSA had a patent on encryption needed for SSL in the USA. > Somewhere I recall hearing that the patent had expired. Is this true? I believe it expired in 2000, http://www.seifried.org/security/cryptography/crypto-book/appendix-e.html (Google "RSA Patent Expire" -- multiple sources confirm the date.) -mrh -- From: "Spam Catcher" To: spam-catcher@adept.org Do NOT send email to the address listed above or you will be added to a blacklist! From owner-freebsd-net@FreeBSD.ORG Mon Jun 30 14:37:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54C3637B4FA for ; Mon, 30 Jun 2003 14:37:01 -0700 (PDT) Received: from mail.dada.it (mail3.dada.it [195.110.100.3]) by mx1.FreeBSD.org (Postfix) with SMTP id A4CB143FDD for ; Mon, 30 Jun 2003 14:36:31 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 30620 invoked from network); 30 Jun 2003 21:36:25 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 30 Jun 2003 21:36:25 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id D6BA76248; Mon, 30 Jun 2003 23:36:26 +0200 (CEST) Date: Mon, 30 Jun 2003 23:36:26 +0200 From: Alessandro de Manzano To: Doug White Message-ID: <20030630233626.A73415@libero.sunshine.ale> References: <20030630212122.A72414@libero.sunshine.ale> <20030630124257.M31036@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030630124257.M31036@carver.gumbysoft.com>; from dwhite@gumbysoft.com on Mon, Jun 30, 2003 at 12:44:51PM -0700 X-Operating-System: FreeBSD 4.7-STABLE cc: mobile@freebsd.org cc: Reinhard Speyerer cc: net@freebsd.org Subject: Re: strange PPP negotiation problem with GPRS mobile phone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alessandro de Manzano List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2003 21:37:01 -0000 On Mon, Jun 30, 2003 at 12:44:51PM -0700, Doug White wrote: > Quick analysis: It doesn't like something in the negotiation, since it > rejects config attempts. Usually its supposed to tell you what it didn't > like, but I'm not seeing that in the printout. Ok, now after the kind help of Mr. Speyerer I've reached the following phase: Now PPP seems to negotiate some IP address, but after about a second it still close the session... Could someone, please, help me understanding what's wrong now according to this log ? ;) Many thanks forever :)) Jun 30 23:27:13 asusmobile ppp[274]: Phase: Using interface: tun0 Jun 30 23:27:13 asusmobile ppp[274]: Phase: deflink: Created in closed state Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: default: ident user-ppp VERSION (built COMPILATIONDATE) Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: default: set device /dev/cuaa0 Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: default: set speed 115200 Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: default: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" AT OK-AT-OK ATE1Q0 OK \dATDT\T TIMEOUT 40 CONNECT Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: default: set timeout 180 Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: default: enable dns Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: default: disable ipv6cp Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: default: disable mppe Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: set speed 57600 Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: set dial ABORT BUSY ABORT NO\sCARRIER TIMEOUT 5 "" ATZ OK-AT-OK ATE1Q0 OK AT+CGDCONT=1,\"IP\",\"web.omnitel.it\",,0,0 OK AT+CGQREQ=1,0,0,0,0,0 OK ATD*99***1# TIMEOUT 85 CONNECT Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: set phone Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: set login Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: set authname Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: set authkey Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: set timeout 0 Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: add default HISADDR Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: disable dns Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: disable vjcomp Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: disable deflate Jun 30 23:27:15 asusmobile ppp[274]: tun0: Command: vodagprs: disable protocomp Jun 30 23:27:15 asusmobile ppp[275]: tun0: Phase: PPP Started (background mode). Jun 30 23:27:15 asusmobile ppp[275]: tun0: Phase: bundle: Establish Jun 30 23:27:15 asusmobile ppp[275]: tun0: Phase: deflink: closed -> opening Jun 30 23:27:15 asusmobile ppp[275]: tun0: Phase: deflink: Connected! Jun 30 23:27:15 asusmobile ppp[275]: tun0: Phase: deflink: opening -> dial Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: deflink: Dial attempt 1 of 1 Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Send: ATZ^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Expect(5): OK Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: ATZ^M^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: OK^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Send: ATE1Q0^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Expect(5): OK Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: ATE1Q0^M^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: OK^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Send: AT+CGDCONT=1,"IP","web.omnitel.it",,0,0^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Expect(5): OK Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: AT+CGDCONT=1,"IP","web.omnitel.it",,0,0^M^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: OK^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Send: AT+CGQREQ=1,0,0,0,0,0^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Expect(5): OK Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: AT+CGQREQ=1,0,0,0,0,0^M^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: OK^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Send: ATD*99***1#^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Expect(85): CONNECT Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: ATD*99***1#^M^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Chat: Received: CONNECT^M Jun 30 23:27:15 asusmobile ppp[275]: tun0: Phase: deflink: dial -> carrier Jun 30 23:27:16 asusmobile ppp[275]: tun0: Phase: deflink: /dev/cuaa0: CD detected Jun 30 23:27:16 asusmobile ppp[275]: tun0: Phase: deflink: carrier -> login Jun 30 23:27:16 asusmobile ppp[275]: tun0: Phase: deflink: login -> lcp Jun 30 23:27:16 asusmobile ppp[275]: tun0: LCP: FSM: Using "deflink" as a transport Jun 30 23:27:16 asusmobile ppp[275]: tun0: LCP: deflink: State change Initial --> Closed Jun 30 23:27:16 asusmobile ppp[275]: tun0: LCP: deflink: State change Closed --> Stopped Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: LayerStart Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: ACFCOMP[2] Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MRU[4] 1500 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MAGICNUM[6] 0x570341ed Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: State change Stopped --> Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: RecvConfigRej(1) state = Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: SendIdent(0) state = Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MAGICNUM 570341ed Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: ACFCOMP[2] Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: SendConfigReq(2) state = Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MRU[4] 1500 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MAGICNUM[6] 0x570341ed Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: RecvConfigReq(32) state = Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MAGICNUM[6] 0x003aaa33 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: SendConfigAck(32) state = Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: AUTHPROTO[4] 0xc023 (PAP) Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MAGICNUM[6] 0x003aaa33 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: State change Req-Sent --> Ack-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: RecvConfigAck(2) state = Ack-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: ACCMAP[6] 0x00000000 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MRU[4] 1500 Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MAGICNUM[6] 0x570341ed Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: State change Ack-Sent --> Opened Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: LayerUp Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: deflink: SendIdent(1) state = Opened Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: MAGICNUM 570341ed Jun 30 23:27:17 asusmobile ppp[275]: tun0: LCP: TEXT user-ppp 3.1 (built Jun 15 2003) Jun 30 23:27:17 asusmobile ppp[275]: tun0: Phase: bundle: Authenticate Jun 30 23:27:17 asusmobile ppp[275]: tun0: Phase: deflink: his = PAP, mine = none Jun 30 23:27:17 asusmobile ppp[275]: tun0: Phase: Pap Output: ******** Jun 30 23:27:17 asusmobile ppp[275]: tun0: Warning: Sending empty PAP authname! Jun 30 23:27:17 asusmobile ppp[275]: tun0: Phase: Pap Input: SUCCESS () Jun 30 23:27:17 asusmobile ppp[275]: tun0: CCP: FSM: Using "deflink" as a transport Jun 30 23:27:17 asusmobile ppp[275]: tun0: CCP: deflink: State change Initial --> Closed Jun 30 23:27:17 asusmobile ppp[275]: tun0: CCP: deflink: LayerStart. Jun 30 23:27:17 asusmobile ppp[275]: tun0: CCP: deflink: SendConfigReq(1) state = Closed Jun 30 23:27:17 asusmobile ppp[275]: tun0: CCP: PRED1[2] Jun 30 23:27:17 asusmobile ppp[275]: tun0: CCP: deflink: State change Closed --> Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: Phase: deflink: lcp -> open Jun 30 23:27:17 asusmobile ppp[275]: tun0: Phase: bundle: Network Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: FSM: Using "deflink" as a transport Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: State change Initial --> Closed Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: LayerStart. Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: IPADDR[6] 127.0.0.1 Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: State change Closed --> Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: RecvConfigReq(33) state = Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: IPADDR[6] 192.168.100.101 Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: SendConfigAck(33) state = Req-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: IPADDR[6] 192.168.100.101 Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: State change Req-Sent --> Ack-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: RecvConfigReq(33) state = Ack-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: IPADDR[6] 192.168.100.101 Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: SendConfigAck(33) state = Ack-Sent Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: IPADDR[6] 192.168.100.101 Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: RecvTerminateReq(34) state = Opened Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: LayerDown Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: SendTerminateAck(34) state = Opened Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: State change Opened --> Stopping Jun 30 23:27:19 asusmobile ppp[275]: tun0: CCP: deflink: State change Req-Sent --> Starting Jun 30 23:27:19 asusmobile ppp[275]: tun0: CCP: deflink: LayerFinish. Jun 30 23:27:19 asusmobile ppp[275]: tun0: CCP: deflink: State change Starting --> Initial Jun 30 23:27:19 asusmobile ppp[275]: tun0: Phase: deflink: open -> lcp Jun 30 23:27:19 asusmobile ppp[275]: tun0: IPCP: deflink: State change Ack-Sent --> Starting Jun 30 23:27:19 asusmobile ppp[275]: tun0: IPCP: deflink: LayerFinish. Jun 30 23:27:19 asusmobile ppp[275]: tun0: IPCP: Connect time: 2 secs: 0 octets in, 0 octets out Jun 30 23:27:19 asusmobile ppp[275]: tun0: IPCP: 0 packets in, 0 packets out Jun 30 23:27:19 asusmobile ppp[275]: tun0: IPCP: total 0 bytes/sec, peak 0 bytes/sec on Mon Jun 30 23:27:17 2003 Jun 30 23:27:19 asusmobile ppp[275]: tun0: IPCP: deflink: State change Starting --> Initial Jun 30 23:27:19 asusmobile ppp[275]: tun0: Phase: bundle: Terminate Jun 30 23:27:20 asusmobile ppp[275]: tun0: Phase: deflink: Carrier lost Jun 30 23:27:20 asusmobile ppp[275]: tun0: LCP: deflink: State change Stopping --> Starting Jun 30 23:27:20 asusmobile ppp[275]: tun0: LCP: deflink: LayerFinish Jun 30 23:27:20 asusmobile ppp[275]: tun0: LCP: deflink: State change Starting --> Initial Jun 30 23:27:20 asusmobile ppp[275]: tun0: Phase: deflink: Disconnected! Jun 30 23:27:20 asusmobile ppp[275]: tun0: Phase: deflink: lcp -> logout Jun 30 23:27:20 asusmobile ppp[275]: tun0: Phase: deflink: Disconnected! Jun 30 23:27:20 asusmobile ppp[275]: tun0: Phase: deflink: logout -> hangup Jun 30 23:27:20 asusmobile ppp[275]: tun0: Phase: deflink: Connect time: 5 secs: 240 octets in, 354 octets out Jun 30 23:27:20 asusmobile ppp[275]: tun0: Phase: deflink: 10 packets in, 11 packets out Jun 30 23:27:20 asusmobile ppp[275]: tun0: Phase: total 118 bytes/sec, peak 133 bytes/sec on Mon Jun 30 23:27:18 2003 Jun 30 23:27:21 asusmobile ppp[275]: tun0: Phase: deflink: hangup -> closed Jun 30 23:27:21 asusmobile ppp[275]: tun0: Phase: bundle: Dead Jun 30 23:27:21 asusmobile ppp[275]: tun0: Phase: PPP Terminated (normal). Jun 30 23:27:21 asusmobile ppp[274]: tun0: Phase: Parent: Child failed (errdead) Jun 30 23:27:21 asusmobile ppp[275]: tun0: Chat: Parent notified of failure -- bye! Ale From owner-freebsd-net@FreeBSD.ORG Mon Jun 30 15:37:06 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFFA637B401; Mon, 30 Jun 2003 15:37:06 -0700 (PDT) Received: from franka.aracnet.com (franka.aracnet.com [216.99.193.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 302C343FE0; Mon, 30 Jun 2003 15:37:06 -0700 (PDT) (envelope-from henryt_NOSPAM@aracnet.com) Received: from aracnet.com (216-99-197-252.dial.spiritone.com [216.99.197.252]) (authenticated bits=0) by franka.aracnet.com (8.12.9/8.12.9) with ESMTP id h5UMaQga015346; Mon, 30 Jun 2003 15:36:34 -0700 Message-ID: <3F00BB97.1040900@aracnet.com> Date: Mon, 30 Jun 2003 15:37:11 -0700 From: henry tieman User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alessandro de Manzano References: <20030630212122.A72414@libero.sunshine.ale> In-Reply-To: <20030630212122.A72414@libero.sunshine.ale> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: mobile@freebsd.org cc: net@freebsd.org Subject: Re: strange PPP negotiation problem with GPRS mobile phone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 30 Jun 2003 22:37:07 -0000 Alessandro de Manzano wrote: >Hello! > >I'm having very strange (to me) PPP problems with a 4.8-R notebook >trying to connect to the Internet via a GPRS mobile phone. > >Note: The exactly same hardware works fine with WinXP so it should work >under FreeBSD also, I guess ;-)) > >Situation: I'm using the following /etc/ppp/ppp.conf file (comments >removed) > > > I use ppp as my usual connection method, it's slow but reliable. My ISP reciently (6 months ago) switched from a "UNIX" terminal server to a "RAS" server. So I had to revisit my ppp config reciently. The only major difference between your configuration file and mine are you disabled lots of things and I set my mtu to 500. If I were trying to get this working - I would comment out the disable lines and set the MTU smaller. Because you are using a mobile phone you may have to set your MTU really small, like 300. Is there a coresponding MRU? If there is it should also be small. There is a posibility that mobile phones want a complete packet before sending any data - in which case you will have to either try to make ppp send larger packets or set the timeout values in ppp to a larger value. And no I don't know what that timeout value is called. I also looked through the trace... there is one thing I saw in my trace but not yours: Jun 30 14:33:20 eric ppp[624]: tun0: LCP: deflink: State change Req-Sent --> Ack -Rcvd Jun 30 14:33:20 eric ppp[624]: tun0: LCP: deflink: RecvConfigReq(2) state = Ack- Rcvd O.K. it's two lines but the trace you sent never enters Ack-Rcvd state before the PAP authentication. And that is probably the symptom of the problem. Henry -- Henry Tieman Objects in the mirror are closer than they appear. From owner-freebsd-net@FreeBSD.ORG Mon Jun 30 20:14:17 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B250B37B401 for ; Mon, 30 Jun 2003 20:14:17 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id F288043FBD for ; Mon, 30 Jun 2003 20:14:15 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jun 2003 23:14:03 -0400 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Date: Mon, 30 Jun 2003 23:13:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: using memory after freed in tcp_syncache (syncache_timer()) w ith ipfw: patch attached X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 03:14:18 -0000 Synopsis: under some ipfw conditions, tcp_syncache has syncache_respond() call ip_output call ip_input call syncache_drop(), which drops the 'syncache' that is being worked on, or corrupts the list, etc. This is typically seen from syncache_timer or syncache_add. I've attached a patch that I believe corrects this problem. I'm observing it on 4.7, but I believe it equally affects RELENG_4 and CURRENT. This seems to make the problem I was seeing go away. I'm currently running with 2K syn/second through the original condition, will let it go overnight like that. I think that will flush out if i've introduced a leak or other crash. Can someone who knows this code perhaps critique what I've done? Essentially I have made syncache_drop() instead defer the delete onto a different list. In the timer, I delete the syncache entries from the delete list. This costs some performance and memory, but was the best way I could come up with. --don Index: tcp_syncache.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_syncache.c,v retrieving revision 1.5.2.8.1000.3 diff -U3 -r1.5.2.8.1000.3 tcp_syncache.c --- tcp_syncache.c 4 Feb 2003 01:52:03 -0000 1.5.2.8.1000.3 +++ tcp_syncache.c 1 Jul 2003 03:05:22 -0000 @@ -85,6 +85,7 @@ #include #include +static int syncache_delete; static int tcp_syncookies = 1; SYSCTL_INT(_net_inet_tcp, OID_AUTO, syncookies, CTLFLAG_RW, &tcp_syncookies, 0, @@ -127,6 +128,7 @@ struct callout tt_timerq[SYNCACHE_MAXREXMTS + 1]; }; static struct tcp_syncache tcp_syncache; +static TAILQ_HEAD(syncache_delete_list, syncache) sc_delete_list; SYSCTL_NODE(_net_inet_tcp, OID_AUTO, syncache, CTLFLAG_RW, 0, "TCP SYN cache"); @@ -204,6 +206,9 @@ rt->rt_flags, NULL); RTFREE(rt); } +#if defined(DIAGNOSTIC) + memset(sc, 0xee, sizeof(struct syncache)); +#endif zfree(tcp_syncache.zone, sc); } @@ -258,6 +263,8 @@ tcp_syncache.cache_limit -= 1; tcp_syncache.zone = zinit("syncache", sizeof(struct syncache), tcp_syncache.cache_limit, ZONE_INTERRUPT, 0); + + TAILQ_INIT(&sc_delete_list); } static void @@ -331,6 +338,18 @@ s = splnet(); + if ((sc->sc_flags & SCF_DELETE) == 0) { + sc->sc_flags |= SCF_DELETE; + syncache_delete = 1; + TAILQ_INSERT_TAIL(&sc_delete_list, sc, sc_delete); + + splx(s); + return; + } + if (sc->sc_delete.tqe_next || sc->sc_delete.tqe_prev) { + TAILQ_REMOVE(&sc_delete_list, sc, sc_delete); + } + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); sch->sch_length--; tcp_syncache.cache_count--; @@ -359,6 +378,8 @@ s = splnet(); if (callout_pending(&tcp_syncache.tt_timerq[slot]) || !callout_active(&tcp_syncache.tt_timerq[slot])) { + if (syncache_delete) + goto delete_cleanup; splx(s); return; } @@ -392,6 +413,17 @@ if (nsc != NULL) callout_reset(&tcp_syncache.tt_timerq[slot], nsc->sc_rxttime - ticks, syncache_timer, (void *)(slot)); + +delete_cleanup: + sc = TAILQ_FIRST(&sc_delete_list); + while (sc != NULL) { + nsc = TAILQ_NEXT(sc, sc_delete); + syncache_drop(sc, NULL); + sc = nsc; + } + TAILQ_INIT(&sc_delete_list); + syncache_delete = 0; + splx(s); } @@ -1335,6 +1367,7 @@ sc = zalloc(tcp_syncache.zone); if (sc == NULL) return (NULL); + bzero(sc, sizeof(*sc)); /* * Fill in the syncache values. * XXX duplicate code from syncache_add Index: tcp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.56.2.12 diff -U3 -r1.56.2.12 tcp_var.h --- tcp_var.h 24 Aug 2002 18:40:26 -0000 1.56.2.12 +++ tcp_var.h 1 Jul 2003 02:33:57 -0000 @@ -224,8 +224,10 @@ #define SCF_CC 0x08 /* negotiated CC */ #define SCF_UNREACH 0x10 /* icmp unreachable received */ #define SCF_KEEPROUTE 0x20 /* keep cloned route */ +#define SCF_DELETE 0x40 /* I'm being deleted */ TAILQ_ENTRY(syncache) sc_hash; TAILQ_ENTRY(syncache) sc_timerq; + TAILQ_ENTRY(syncache) sc_delete; }; struct syncache_head { From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 05:57:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEE7137B40D; Tue, 1 Jul 2003 05:57:04 -0700 (PDT) Received: from erdos.dsm.fordham.edu (erdos.dsm.fordham.edu [150.108.64.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0D3043F93; Tue, 1 Jul 2003 05:57:01 -0700 (PDT) (envelope-from tanzer@dsm.fordham.edu) Received: from erdos.dsm.fordham.edu (localhost [127.0.0.1]) by erdos.dsm.fordham.edu (8.12.8/8.12.8) with ESMTP id h61Cuxsr009913; Tue, 1 Jul 2003 08:56:59 -0400 Received: from localhost (tanzer@localhost)h61Cut7a009909; Tue, 1 Jul 2003 08:56:55 -0400 Date: Tue, 1 Jul 2003 08:56:55 -0400 (EDT) From: "Edward F. Tanzer" To: freebsd-net@freebsd.org, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: chrisy@flirble.org Subject: ANNOUNCE: Multipath Patches for 4.8-STABLE Available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 12:57:05 -0000 Multipath route table. Ported to FreeBSD 4.8 by Ed Tanzer . Version 5, released agains FreeBSD 4.8-STABLE 2003/06/27 http://www.dsm.fordham.edu/~tanzer/multipath/ From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 07:02:41 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E16537B40D; Tue, 1 Jul 2003 07:02:41 -0700 (PDT) Received: from rohrpostix.tallence.de (rohrpostix.tallence.de [212.77.172.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5728B44031; Tue, 1 Jul 2003 07:02:40 -0700 (PDT) (envelope-from stb@lassitu.de) Received: from devcli80.devlan.j2w (blue.tallence.de [212.77.172.82]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by rohrpostix.tallence.de (Postfix) with ESMTP id 6F8E61AD971; Tue, 1 Jul 2003 16:02:37 +0200 (CEST) Date: Tue, 01 Jul 2003 16:02:34 +0200 From: Stefan Bethke To: Alessandro de Manzano Message-ID: <2147483647.1057075354@[172.20.20.180]> In-Reply-To: <20030630233626.A73415@libero.sunshine.ale> References: <20030630212122.A72414@libero.sunshine.ale> <20030630124257.M31036@carver.gumbysoft.com> <20030630233626.A73415@libero.sunshine.ale> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: mobile@freebsd.org cc: net@freebsd.org Subject: Re: strange PPP negotiation problem with GPRS mobile phone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 14:02:42 -0000 On Montag, 30. Juni 2003 23:36 Uhr +0200 Alessandro de Manzano wrote: > Now PPP seems to negotiate some IP address, but after about a second it > still close the session... > > Could someone, please, help me understanding what's wrong now according > to this log ? ;) > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: SendConfigAck(33) state = Ack-Sent > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: IPADDR[6] 192.168.100.101 > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression > Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: RecvTerminateReq(34) state = Opened > Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: LayerDown > Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: SendTerminateAck(34) state = Opened > Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: State change Opened --> Stopping > Jun 30 23:27:19 asusmobile ppp[275]: tun0: CCP: deflink: State change Req-Sent --> Starting > Jun 30 23:27:19 asusmobile ppp[275]: tun0: CCP: deflink: LayerFinish. The peer is disconnecting. This might be due to either the Van Jacobsen compression (option vjcomp), or the Link Quality Request Echo (option lqr) being active or inactive. IIRC, for a GPRS connection, the phone acts as the PPP peer, and at least my Nokia 6310i does not like LQR Echo and VJ. With both of them enabled, the connection keeps going for a few seconds, and then gets dropped by the peer. With both of them disabled, it works fine for me on T-Mobile netowrks in Germany, Austria and the US. HTH, Stefan -- Stefan Bethke, Phone +49 170 346 0140 From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 07:55:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D66F37B401 for ; Tue, 1 Jul 2003 07:55:39 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 960A944025 for ; Tue, 1 Jul 2003 07:55:38 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jul 2003 10:55:37 -0400 Message-ID: From: Don Bowman To: "'freebsd-net@freebsd.org'" Date: Tue, 1 Jul 2003 10:55:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: using memory after freed in tcp_syncache (syncache_timer()) w ith ipfw: patch attached X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 14:55:39 -0000 From: Don Bowman [mailto:don@sandvine.com] > > Synopsis: under some ipfw conditions, tcp_syncache has > syncache_respond() call ip_output call ip_input call syncache_drop(), > which drops the 'syncache' that is being worked on, or corrupts > the list, etc. This is typically seen from syncache_timer or > syncache_add. > > I've attached a patch that I believe corrects this problem. > I'm observing it on 4.7, but I believe it equally affects RELENG_4 > and CURRENT. > > This seems to make the problem I was seeing go away. I'm > currently running with 2K syn/second through the original condition, > will let it go overnight like that. I think that will flush > out if i've introduced a leak or other crash. > > Can someone who knows this code perhaps critique what I've done? > > Essentially I have made syncache_drop() instead defer the delete > onto a different list. In the timer, I delete the syncache entries > from the delete list. This costs some performance and memory, but > was the best way I could come up with. > There was an error in the previous patch. Index: tcp_syncache.c =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_syncache.c,v retrieving revision 1.5.2.8.1000.3 diff -U5 -r1.5.2.8.1000.3 tcp_syncache.c --- tcp_syncache.c 4 Feb 2003 01:52:03 -0000 1.5.2.8.1000.3 +++ tcp_syncache.c 1 Jul 2003 14:32:29 -0000 @@ -83,16 +83,18 @@ #endif /*IPSEC*/ #include #include +static int syncache_delete_flag; static int tcp_syncookies = 1; SYSCTL_INT(_net_inet_tcp, OID_AUTO, syncookies, CTLFLAG_RW, &tcp_syncookies, 0, "Use TCP SYN cookies if the syncache overflows"); static void syncache_drop(struct syncache *, struct syncache_head *); +static void syncache_delete(struct syncache *, struct syncache_head *); static void syncache_free(struct syncache *); static void syncache_insert(struct syncache *, struct syncache_head *); struct syncache *syncache_lookup(struct in_conninfo *, struct syncache_head **); static int syncache_respond(struct syncache *, struct mbuf *); static struct socket *syncache_socket(struct syncache *, struct socket *); @@ -125,10 +127,11 @@ u_int next_reseed; TAILQ_HEAD(, syncache) timerq[SYNCACHE_MAXREXMTS + 1]; struct callout tt_timerq[SYNCACHE_MAXREXMTS + 1]; }; static struct tcp_syncache tcp_syncache; +static TAILQ_HEAD(syncache_delete_list, syncache) sc_delete_list; SYSCTL_NODE(_net_inet_tcp, OID_AUTO, syncache, CTLFLAG_RW, 0, "TCP SYN cache"); SYSCTL_INT(_net_inet_tcp_syncache, OID_AUTO, bucketlimit, CTLFLAG_RD, &tcp_syncache.bucket_limit, 0, "Per-bucket hash limit for syncache"); @@ -202,10 +205,13 @@ rtrequest(RTM_DELETE, rt_key(rt), rt->rt_gateway, rt_mask(rt), rt->rt_flags, NULL); RTFREE(rt); } +#if defined(DIAGNOSTIC) + memset(sc, 0xee, sizeof(struct syncache)); +#endif zfree(tcp_syncache.zone, sc); } void syncache_init(void) @@ -256,10 +262,12 @@ * older one. */ tcp_syncache.cache_limit -= 1; tcp_syncache.zone = zinit("syncache", sizeof(struct syncache), tcp_syncache.cache_limit, ZONE_INTERRUPT, 0); + + TAILQ_INIT(&sc_delete_list); } static void syncache_insert(sc, sch) struct syncache *sc; @@ -312,12 +320,28 @@ static void syncache_drop(sc, sch) struct syncache *sc; struct syncache_head *sch; { + if ((sc->sc_flags & SCF_DELETE) == 0) { + sc->sc_flags |= SCF_DELETE; + syncache_delete_flag = 1; + TAILQ_INSERT_TAIL(&sc_delete_list, sc, sc_delete); + } +} + +static void +syncache_delete(sc, sch) + struct syncache *sc; + struct syncache_head *sch; +{ int s; + if ((sc->sc_flags & SCF_DELETE) == 0) { + printf("ERROR ERROR ERROR: SCF_DELETE == 0\n"); + return; + } if (sch == NULL) { #ifdef INET6 if (sc->sc_inc.inc_isipv6) { sch = &tcp_syncache.hashbase[ SYNCACHE_HASH6(&sc->sc_inc, tcp_syncache.hashmask)]; @@ -329,10 +353,12 @@ } } s = splnet(); + TAILQ_REMOVE(&sc_delete_list, sc, sc_delete); + TAILQ_REMOVE(&sch->sch_bucket, sc, sc_hash); sch->sch_length--; tcp_syncache.cache_count--; TAILQ_REMOVE(&tcp_syncache.timerq[sc->sc_rxtslot], sc, sc_timerq); @@ -357,10 +383,12 @@ int s; s = splnet(); if (callout_pending(&tcp_syncache.tt_timerq[slot]) || !callout_active(&tcp_syncache.tt_timerq[slot])) { + if (syncache_delete_flag) + goto delete_cleanup; splx(s); return; } callout_deactivate(&tcp_syncache.tt_timerq[slot]); @@ -390,10 +418,21 @@ SYNCACHE_TIMEOUT(sc, slot + 1); } if (nsc != NULL) callout_reset(&tcp_syncache.tt_timerq[slot], nsc->sc_rxttime - ticks, syncache_timer, (void *)(slot)); + +delete_cleanup: + sc = TAILQ_FIRST(&sc_delete_list); + while (sc != NULL) { + nsc = TAILQ_NEXT(sc, sc_delete); + syncache_delete(sc, NULL); + sc = nsc; + } + TAILQ_INIT(&sc_delete_list); + syncache_delete_flag = 0; + splx(s); } /* * Find an entry in the syncache. @@ -1333,10 +1372,11 @@ data = data >> SYNCOOKIE_WNDBITS; sc = zalloc(tcp_syncache.zone); if (sc == NULL) return (NULL); + bzero(sc, sizeof(*sc)); /* * Fill in the syncache values. * XXX duplicate code from syncache_add */ sc->sc_ipopts = NULL; Index: tcp_var.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_var.h,v retrieving revision 1.56.2.12 diff -U5 -r1.56.2.12 tcp_var.h --- tcp_var.h 24 Aug 2002 18:40:26 -0000 1.56.2.12 +++ tcp_var.h 1 Jul 2003 02:33:57 -0000 @@ -222,12 +222,14 @@ #define SCF_WINSCALE 0x02 /* negotiated window scaling */ #define SCF_TIMESTAMP 0x04 /* negotiated timestamps */ #define SCF_CC 0x08 /* negotiated CC */ #define SCF_UNREACH 0x10 /* icmp unreachable received */ #define SCF_KEEPROUTE 0x20 /* keep cloned route */ +#define SCF_DELETE 0x40 /* I'm being deleted */ TAILQ_ENTRY(syncache) sc_hash; TAILQ_ENTRY(syncache) sc_timerq; + TAILQ_ENTRY(syncache) sc_delete; }; struct syncache_head { TAILQ_HEAD(, syncache) sch_bucket; u_int sch_length; From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 08:34:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13FE637B401; Tue, 1 Jul 2003 08:34:10 -0700 (PDT) Received: from hole.shrew.net (cs24354-246.austin.rr.com [24.243.54.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1972043FD7; Tue, 1 Jul 2003 08:34:09 -0700 (PDT) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (localhost.shrew.net [127.0.0.1]) by hole.shrew.net (8.12.9/8.12.9) with SMTP id h61FZVYv045470; Tue, 1 Jul 2003 15:35:31 GMT (envelope-from mgrooms@shrew.net) Message-Id: <200307011535.h61FZVYv045470@hole.shrew.net> Received: from 65.118.63.254 (auth. user mgrooms@mail.shrew.net) by mail.shrew.net with HTTP; Tue, 01 Jul 2003 15:35:31 +0000 To: freebsd-current@freebsd.org Date: Tue, 01 Jul 2003 15:35:30 +0000 X-Mailer: IlohaMail/0.8.7 (On: mail.shrew.net) From: "Matthew Grooms" Bounce-To: "Matthew Grooms" Errors-To: "Matthew Grooms" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-hackers@freebsd.org cc: freebsd-net@freebsd.org Subject: BIOCSSEESENT ioctl on 5.1 ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 15:34:10 -0000 Question, Is there somthing magic about setting this flag? I wrote a small program ( built on 5.1 ) that uses the bpf to read broadcast packets off a local private network, forward them to a peer ( over IPSEC ) who in turn drops them onto its private network ( and visa-versa ). To prevent looping, I was hoping to set the BIOCSSEESENT flag on the fd. Unfortunately, when this option is set I no longer receive any packets on the interface. Here is the relevent code. // open the berkley packet filter device int32_t hbpf; int32_t mnum =3D 0; char device[ 25 ]; do { sprintf( device,"/dev/bpf%d", mnum ); mnum++; hbpf =3D open( device, O_RDWR ); } while( hbpf < 0 && errno =3D=3D EBUSY ); if( hbpf =3D=3D -1 ) { printf( "failed to open a packet filter device\n" ); printf( "exiting ...\n" ); return -1; } printf( "using filter device '%s'\n", device ); // assign the filter to a network device struct ifreq ifr; strcpy( ifr.ifr_name, config.get_service_iface() ); if( ioctl( hbpf, BIOCSETIF, ( uint32_t ) &ifr ) =3D=3D -1 ) { printf( "unable to assign filter to network device \'%s\'\n", ifr.ifr_name ); printf( "exiting ..." ); return -1; } printf( "using network device \'%s\'\n", ifr.ifr_name ); // dont buffer packet data uint32_t value =3D 1; if( ioctl( hbpf, BIOCIMMEDIATE, &value ) =3D=3D -1 ) { printf( "unable to set BIOCIMMEDIATE option for filter device\n" ); printf( "exiting ...\n" ); return -1; } // use promiscuous mode if( ioctl( hbpf, BIOCPROMISC, &value ) =3D=3D -1 ) { printf( "unable to set BIOCPROMISC option for filter device\n" ); printf( "exiting ...\n" ); return -1; } // use non-blocking io if( ioctl( hbpf, FIONBIO, &value ) =3D=3D -1 ) { printf( "unable to set FIONBIO option for filter device\n" ); printf( "exiting ...\n" ); return -1; } // disable header complete mode if( ioctl( hbpf, BIOCSHDRCMPLT, &value ) =3D=3D -1 ) { printf( "unable to set BIOCGHDRCMPLT option for filter device\n" ); printf( "exiting ...\n" ); return -1; } // don't return localy generated packets value =3D 0; if( ioctl( hbpf, BIOCSSEESENT, &value ) =3D=3D -1 ) { printf( "unable to set BIOCGSEESENT option for filter device\n" ); printf( "exiting ...\n" ); return -1; } // get the filter buffer size int32_t buff_size; if( ioctl( hbpf, BIOCGBLEN, &buff_size ) =3D=3D -1 ) { printf( "unable to obtain filter buffer size\n" ); printf( "exiting ...\n" ); return -1; } // setup our bpf filter machine data uint32_t ins_count =3D 8; uint32_t ins_index =3D 0; struct bpf_insn * insns =3D new struct bpf_insn[ ins_count ]; if( !insns ) { printf( "unable to alloc filter macine data\n" ); printf( "exiting ...\n" ); return -1; } insns[ ins_index ].code =3D BPF_LD+BPF_H+BPF_ABS; // load data ( half word ) insns[ ins_index ].k =3D 12; // offset ( protocol ) ins_index++; insns[ ins_index ].code =3D BPF_JMP+BPF_JEQ+BPF_K; // cmp equality and jmp insns[ ins_index ].jt =3D 0; // true offset insns[ ins_index ].jf =3D 5; // false offset insns[ ins_index ].k =3D 0x0800; // value ins_index++; insns[ ins_index ].code =3D BPF_LD+BPF_B+BPF_ABS; // load data ( byte ) insns[ ins_index ].k =3D 23; // offset ( transport type ) ins_index++; insns[ ins_index ].code =3D BPF_JMP+BPF_JEQ+BPF_K; // cmp equality and jmp insns[ ins_index ].jt =3D 0; // true offset insns[ ins_index ].jf =3D 3; // false offset insns[ ins_index ].k =3D 0x11; // value ins_index++; /* * TODO : check for a matching port */ insns[ ins_index ].code =3D BPF_LD+BPF_W+BPF_ABS; // load data ( word ) insns[ ins_index ].k =3D 30; // offset ( destination addre ins_index++; insns[ ins_index ].code =3D BPF_JMP+BPF_JEQ+BPF_K; // cmp equality and jmp insns[ ins_index ].jt =3D 0; // true offset insns[ ins_index ].jf =3D 1; // false offset insns[ ins_index ].k =3D 0xffffffff; // value ins_index++; insns[ ins_index ].code =3D BPF_RET+BPF_K; // return ( passed ) insns[ ins_index ].k =3D ( u_int ) -1; // accept byte count ( everyt ins_index++; insns[ ins_index ].code =3D BPF_RET+BPF_K; // return ( failed ) insns[ ins_index ].jt =3D 0; // insns[ ins_index ].jf =3D 0; // insns[ ins_index ].k =3D 0; // accept byte count ( ignore ins_index++; // assign the bpf filter program struct bpf_program bpfp; bpfp.bf_insns =3D insns; bpfp.bf_len =3D ins_count; if( ioctl( hbpf, BIOCSETF, &bpfp ) =3D=3D -1 ) { printf( "unable to set filter program\n" ); printf( "exiting ...\n" ); return -1; } PS ... From what I can tell, I am following the bpf manpage to the tee and think there could be possibly an issue with this on 5.1. Could anyone help please. Thanks in advance ... -Matthew From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 10:42:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56D0A37B401; Tue, 1 Jul 2003 10:42:57 -0700 (PDT) Received: from hole.shrew.net (cs24354-246.austin.rr.com [24.243.54.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 869F443FEC; Tue, 1 Jul 2003 10:42:56 -0700 (PDT) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (localhost.shrew.net [127.0.0.1]) by hole.shrew.net (8.12.9/8.12.9) with SMTP id h61HhNOW001213; Tue, 1 Jul 2003 17:43:24 GMT (envelope-from mgrooms@shrew.net) Message-Id: <200307011743.h61HhNOW001213@hole.shrew.net> Received: from 65.118.63.254 (auth. user mgrooms@mail.shrew.net) by mail.shrew.net with HTTP; Tue, 01 Jul 2003 17:43:23 +0000 To: "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" Date: Tue, 01 Jul 2003 17:43:23 +0000 X-Mailer: IlohaMail/0.8.7 (On: mail.shrew.net) From: "Matthew Grooms" Bounce-To: "Matthew Grooms" Errors-To: "Matthew Grooms" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: BIOCSSEESENT ioctl on 5.1 ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 17:42:57 -0000 Woops, Please disregard the previous post ... amature programmer at play. Can an ioctl call return before processing the request? When I started using seperate variables for the int=3D1 and int=3D0 ioctl values, everything works fine. -Matthew >Question, > > Is there somthing magic about setting this flag? > .. From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 10:59:55 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1BA337B401 for ; Tue, 1 Jul 2003 10:59:54 -0700 (PDT) Received: from hole.shrew.net (cs24354-246.austin.rr.com [24.243.54.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC2943F93 for ; Tue, 1 Jul 2003 10:59:54 -0700 (PDT) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (localhost.shrew.net [127.0.0.1]) by hole.shrew.net (8.12.9/8.12.9) with SMTP id h61I0MOW001329 for freebsd-net@freebsd.org; Tue, 1 Jul 2003 18:00:22 GMT (envelope-from mgrooms@shrew.net) Message-Id: <200307011800.h61I0MOW001329@hole.shrew.net> Received: from 65.118.63.254 (auth. user mgrooms@mail.shrew.net) by mail.shrew.net with HTTP; Tue, 01 Jul 2003 18:00:22 +0000 To: "freebsd-net@freebsd.org" Date: Tue, 01 Jul 2003 18:00:22 +0000 X-Mailer: IlohaMail/0.8.7 (On: mail.shrew.net) From: "Matthew Grooms" Bounce-To: "Matthew Grooms" Errors-To: "Matthew Grooms" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: broadcast udp packets ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 17:59:55 -0000 One more question, Is there any way to generate a udp broadcast ( all routes 255.255.255.255 ) packet using a standard sendto() without it being translated into a local network broadcast? Is this just not "allowed"? -Matthew From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 12:01:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 930E637B405 for ; Tue, 1 Jul 2003 12:01:16 -0700 (PDT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F5174403F for ; Tue, 1 Jul 2003 12:01:15 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([141.149.47.46]) by out003.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030701190114.NRTQ4805.out003.verizon.net@mac.com>; Tue, 1 Jul 2003 14:01:14 -0500 Message-ID: <3F01DA79.4080709@mac.com> Date: Tue, 01 Jul 2003 15:01:13 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Grooms References: <200307011800.h61I0MOW001329@hole.shrew.net> In-Reply-To: <200307011800.h61I0MOW001329@hole.shrew.net> X-Enigmail-Version: 0.76.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [141.149.47.46] at Tue, 1 Jul 2003 14:01:14 -0500 cc: "freebsd-net@freebsd.org" Subject: Re: broadcast udp packets ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 19:01:16 -0000 Matthew Grooms wrote: > Is there any way to generate a udp broadcast ( all routes > 255.255.255.255 ) packet using a standard sendto() without it being > translated into a local network broadcast? Is this just not "allowed"? Are you trying to use 255.255.255.255 to reach something not on a local subnet? If you have multiple interfaces, a broadcast to 255.255.255.255 should go out on all of them. That being said, the all-ones broadcast address means "all local networks", and most routers will block such traffic from passing on in any event. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 12:50:07 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48D7D37B401; Tue, 1 Jul 2003 12:50:07 -0700 (PDT) Received: from mwinf0604.wanadoo.fr (smtp3.wanadoo.fr [193.252.22.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D8DC43FF9; Tue, 1 Jul 2003 12:50:06 -0700 (PDT) (envelope-from vjardin@wanadoo.fr) Received: from venus.vincentjardin.net (AVelizy-102-1-6-222.w193-253.abo.wanadoo.fr [193.253.220.222]) by mwinf0604.wanadoo.fr (SMTP Server) with ESMTP id 30FDC280016B; Tue, 1 Jul 2003 21:50:05 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Vincent Jardin To: "Edward F. Tanzer" , freebsd-net@freebsd.org, Date: Tue, 1 Jul 2003 21:50:10 +0200 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200307012150.10105.vjardin@wanadoo.fr> cc: chrisy@flirble.org Subject: Re: ANNOUNCE: Multipath Patches for 4.8-STABLE Available X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 19:50:07 -0000 What are the main differences between your patch and the Kame's one ? http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/net/radix_mpath.c?rev=3D= 1.13&content-type=3Dtext/x-cvsweb-markup Regards, Vincent Le Mardi 1 Juillet 2003 14:56, Edward F. Tanzer a =E9crit : > Multipath route table. > Ported to FreeBSD 4.8 by Ed Tanzer . > > Version 5, released agains FreeBSD 4.8-STABLE 2003/06/27 > > http://www.dsm.fordham.edu/~tanzer/multipath/ > > _______________________________________________ > 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 Tue Jul 1 13:50:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 450E737B401; Tue, 1 Jul 2003 13:50:26 -0700 (PDT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C610043F93; Tue, 1 Jul 2003 13:50:25 -0700 (PDT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id B531B72FE3; Tue, 1 Jul 2003 13:50:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id B3BE872FDC; Tue, 1 Jul 2003 13:50:25 -0700 (PDT) Date: Tue, 1 Jul 2003 13:50:25 -0700 (PDT) From: Doug White To: Alessandro de Manzano In-Reply-To: <20030630233626.A73415@libero.sunshine.ale> Message-ID: <20030701134658.U40881@carver.gumbysoft.com> References: <20030630212122.A72414@libero.sunshine.ale> <20030630233626.A73415@libero.sunshine.ale> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: mobile@freebsd.org cc: Reinhard Speyerer cc: net@freebsd.org Subject: Re: strange PPP negotiation problem with GPRS mobile phone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 20:50:26 -0000 On Mon, 30 Jun 2003, Alessandro de Manzano wrote: > Ok, now after the kind help of Mr. Speyerer I've reached the following > phase: > > Now PPP seems to negotiate some IP address, but after about a second it > still close the session... The remote boots you off 2 seconds after it finishes bringing up ppp all the way. Perhaps you've disabled too much now? > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: State change Initial --> Closed > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: LayerStart. > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: SendConfigReq(1) state = Closed > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: IPADDR[6] 127.0.0.1 That must be a dummy value... but I think its supposed to be all 0s if you are asking for a valid ip. > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: State change Closed --> Req-Sent > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: deflink: RecvConfigReq(33) state = Req-Sent > Jun 30 23:27:17 asusmobile ppp[275]: tun0: IPCP: IPADDR[6] 192.168.100.101 Does that look like a valid IP from your provider? > Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: RecvTerminateReq(34) state = Opened > Jun 30 23:27:19 asusmobile ppp[275]: tun0: LCP: deflink: LayerDown The remote asked that you go away so you failed some sort of check at something beyond the ppp layer. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 14:46:06 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A277237B401 for ; Tue, 1 Jul 2003 14:46:06 -0700 (PDT) Received: from hole.shrew.net (cs24354-246.austin.rr.com [24.243.54.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6267D44005 for ; Tue, 1 Jul 2003 14:46:05 -0700 (PDT) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (localhost.shrew.net [127.0.0.1]) by hole.shrew.net (8.12.9/8.12.9) with SMTP id h61LkXOW001888; Tue, 1 Jul 2003 21:46:34 GMT (envelope-from mgrooms@shrew.net) Message-Id: <200307012146.h61LkXOW001888@hole.shrew.net> Received: from 65.118.63.254 (auth. user mgrooms@mail.shrew.net) by mail.shrew.net with HTTP; Tue, 01 Jul 2003 21:46:33 +0000 To: "Chuck Swiger" Date: Tue, 01 Jul 2003 21:46:33 +0000 X-Mailer: IlohaMail/0.8.7 (On: mail.shrew.net) In-Reply-To: <3F01DA79.4080709@mac.com> From: "Matthew Grooms" Bounce-To: "Matthew Grooms" Errors-To: "Matthew Grooms" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cc: "freebsd-net@freebsd.org" Subject: Re: broadcast udp packets ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 21:46:06 -0000 Well, Ok, sounds stupid right, well here is a bit of background. My friend and I have an IPSEC tunnel in between our two private networks connected by BSD firewalls w/ cable modems. Without going into too much detail, certain programs ( win32 games ) use all-routes broadcasts to advertise the info pertaining to the workstaion hosting a particular game. After much searching, I could find no mechanism in FreeBSD that would allow me to pass these broadcasts from a private network, across the IPSEC tunnel and to the distant private network. ( tried all sorts of nat and bridging configurations ) As a result, I decided to write a small relay daemon that used bpf to pick up the broadcast messages from the local private network, forward them to a peer that in turn drops it on to the distant private network. ( I know, its a lot of work to play a game but it sounded like a fun project ) In any case, I have most of it working well but am getting loops when the bpf dropps the packet on the wire at the far end. It reads the packet in after writing it out and forwards it back to the originating relay partner, just like a really bad pong game. Setting BIOCSSEESENT on the fd does not seem to do the trick. Any Ideas? In any case, I wrote a quick little program to generate a broadcast message for use with testing the relay daemon ( I got tired of waiting for bootp requests to be picked up by my cable modem as a test case ). Unfortunately, I can never get the test program generate an all-routes broadcast, they always come out as network directed broadcasts. ... If there is not a more conventional way of going about it, I guess I will just have to generate one using the bpf. On 7/1/2003, "Chuck Swiger" wrote: >Matthew Grooms wrote: >> Is there any way to generate a udp broadcast ( all routes >> 255.255.255.255 ) packet using a standard sendto() without it being >> translated into a local network broadcast? Is this just not "allowed"? > >Are you trying to use 255.255.255.255 to reach something not on a local subnet? > >If you have multiple interfaces, a broadcast to 255.255.255.255 should go out on >all of them. That being said, the all-ones broadcast address means "all local >networks", and most routers will block such traffic from passing on in any event. > >-- >-Chuck > From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 15:04:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B5E137B401 for ; Tue, 1 Jul 2003 15:04:16 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42DDB43FF7 for ; Tue, 1 Jul 2003 15:04:15 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h61M4EQv094726; Tue, 1 Jul 2003 18:04:14 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h61M4Efq094725; Tue, 1 Jul 2003 18:04:14 -0400 (EDT) Date: Tue, 1 Jul 2003 18:04:14 -0400 From: Barney Wolff To: Matthew Grooms Message-ID: <20030701220414.GA94127@pit.databus.com> References: <3F01DA79.4080709@mac.com> <200307012146.h61LkXOW001888@hole.shrew.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307012146.h61LkXOW001888@hole.shrew.net> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: "freebsd-net@freebsd.org" Subject: Re: broadcast udp packets ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 22:04:16 -0000 On Tue, Jul 01, 2003 at 09:46:33PM +0000, Matthew Grooms wrote: > > In any case, I wrote a quick little program to generate a broadcast > message for use with testing the relay daemon ( I got tired of waiting for > bootp requests to be picked up by my cable modem as a test case ). > Unfortunately, I can never get the test program generate an all-routes > broadcast, they always come out as network directed broadcasts. There's a sleazy way. I was told it by Irix support in 1994, and if I'm not mistaken dhclient uses it still today. Ifconfig your interface with an alias of 255.0.0.1/8. Told you it was sleazy. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Tue Jul 1 15:12:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5A9E37B401 for ; Tue, 1 Jul 2003 15:12:48 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 262EC43F75 for ; Tue, 1 Jul 2003 15:12:48 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc12) with ESMTP id <2003070122124601400mdcbke>; Tue, 1 Jul 2003 22:12:46 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA61892; Tue, 1 Jul 2003 15:12:44 -0700 (PDT) Date: Tue, 1 Jul 2003 15:12:43 -0700 (PDT) From: Julian Elischer To: Matthew Grooms In-Reply-To: <200307012146.h61LkXOW001888@hole.shrew.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "freebsd-net@freebsd.org" Subject: Re: broadcast udp packets ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 22:12:49 -0000 you can use netgraph to make a "virtual bridge" see /usr/share/examples/netgraph for an example of a single bridge. attach one of the bridge hooks on each site to an ng_socket node that has made a udp vpn.. see the vpn example for that.. by combining both the bridge and vpn examples you can hook the two sites together in a bridged manner. On Tue, 1 Jul 2003, Matthew Grooms wrote: > Well, > > Ok, sounds stupid right, well here is a bit of background. My friend and > I have an IPSEC tunnel in between our two private networks connected by BSD > firewalls w/ cable modems. Without going into too much detail, certain > programs ( win32 games ) use all-routes broadcasts to advertise the info > pertaining to the workstaion hosting a particular game. After much searching, > I could find no mechanism in FreeBSD that would allow me to pass these > broadcasts from a private network, across the IPSEC tunnel and to the distant > private network. ( tried all sorts of nat and bridging configurations ) > > As a result, I decided to write a small relay daemon that used bpf to > pick up the broadcast messages from the local private network, forward them > to a peer that in turn drops it on to the distant private network. ( I know, > its a lot of work to play a game but it sounded like a fun project ) In any > case, I have most of it working well but am getting loops when the bpf dropps > the packet on the wire at the far end. It reads the packet in after writing > it out and forwards it back to the originating relay partner, just like a > really bad pong game. Setting BIOCSSEESENT on the fd does not seem to do the > trick. Any Ideas? > > In any case, I wrote a quick little program to generate a broadcast > message for use with testing the relay daemon ( I got tired of waiting for > bootp requests to be picked up by my cable modem as a test case ). > Unfortunately, I can never get the test program generate an all-routes > broadcast, they always come out as network directed broadcasts. > > ... If there is not a more conventional way of going about it, I guess > I will just have to generate one using the bpf. > > On 7/1/2003, "Chuck Swiger" wrote: > > >Matthew Grooms wrote: > >> Is there any way to generate a udp broadcast ( all routes > >> 255.255.255.255 ) packet using a standard sendto() without it being > >> translated into a local network broadcast? Is this just not "allowed"? > > > >Are you trying to use 255.255.255.255 to reach something not on a local > subnet? > > > >If you have multiple interfaces, a broadcast to 255.255.255.255 should go > out on > >all of them. That being said, the all-ones broadcast address means "all > local > >networks", and most routers will block such traffic from passing on in any > event. > > > >-- > >-Chuck > > > _______________________________________________ > 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 Tue Jul 1 15:50:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9864A37B401 for ; Tue, 1 Jul 2003 15:50:18 -0700 (PDT) Received: from hole.shrew.net (cs24354-246.austin.rr.com [24.243.54.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id D456B43FCB for ; Tue, 1 Jul 2003 15:50:17 -0700 (PDT) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (localhost.shrew.net [127.0.0.1]) by hole.shrew.net (8.12.9/8.12.9) with SMTP id h61Mo6OW002248; Tue, 1 Jul 2003 22:50:06 GMT (envelope-from mgrooms@shrew.net) Message-Id: <200307012250.h61Mo6OW002248@hole.shrew.net> Received: from 65.118.63.254 (auth. user mgrooms@mail.shrew.net) by mail.shrew.net with HTTP; Tue, 01 Jul 2003 22:50:06 +0000 To: "Julian Elischer" Date: Tue, 01 Jul 2003 22:50:06 +0000 X-Mailer: IlohaMail/0.8.7 (On: mail.shrew.net) In-Reply-To: From: "Matthew Grooms" Bounce-To: "Matthew Grooms" Errors-To: "Matthew Grooms" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cc: "freebsd-net@freebsd.org" Subject: Re: broadcast udp packets ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 01 Jul 2003 22:50:19 -0000 Hey, Thanks for the response. I will look into netgraph then. I was thinking it could be useful to have flexable utility that could be used to bridge distant broadcast domains ( w/filtering ). The home-grown thingy is an exercise to learn more about unix programming. Most of my experience is with win32 stuff. Any ideas as to why setting BIOCSSEESENT on the fd doesnt seem have any effect on bpf returning locally generated traffic? -Matthew On 7/1/2003, "Julian Elischer" wrote: >you can use netgraph to make a "virtual bridge" > >see /usr/share/examples/netgraph for an example of a single bridge. > >attach one of the bridge hooks on each site to an ng_socket node that >has made a udp vpn.. >see the vpn example for that.. > >by combining both the bridge and vpn examples you can hook the two >sites together in a bridged manner. > > > >On Tue, 1 Jul 2003, Matthew Grooms wrote: > >> Well, >> >> Ok, sounds stupid right, well here is a bit of background. My friend and >> I have an IPSEC tunnel in between our two private networks connected by=20 BSD >> firewalls w/ cable modems. Without going into too much detail, certain >> programs ( win32 games ) use all-routes broadcasts to advertise the info >> pertaining to the workstaion hosting a particular game. After much searching, >> I could find no mechanism in FreeBSD that would allow me to pass these >> broadcasts from a private network, across the IPSEC tunnel and to the distant >> private network. ( tried all sorts of nat and bridging configurations ) >> >> As a result, I decided to write a small relay daemon that used bpf to >> pick up the broadcast messages from the local private network, forward them >> to a peer that in turn drops it on to the distant private network. ( I know, >> its a lot of work to play a game but it sounded like a fun project ) In any >> case, I have most of it working well but am getting loops when the bpf dropps >> the packet on the wire at the far end. It reads the packet in after writing >> it out and forwards it back to the originating relay partner, just like a >> really bad pong game. Setting BIOCSSEESENT on the fd does not seem to do the >> trick. Any Ideas? >> >> In any case, I wrote a quick little program to generate a broadcast >> message for use with testing the relay daemon ( I got tired of waiting for >> bootp requests to be picked up by my cable modem as a test case ). >> Unfortunately, I can never get the test program generate an all-routes >> broadcast, they always come out as network directed broadcasts. >> >> ... If there is not a more conventional way of going about it, I guess >> I will just have to generate one using the bpf. >> >> On 7/1/2003, "Chuck Swiger" wrote: >> >> >Matthew Grooms wrote: >> >> Is there any way to generate a udp broadcast ( all routes >> >> 255.255.255.255 ) packet using a standard sendto() without it being >> >> translated into a local network broadcast? Is this just not "allowed"? >> > >> >Are you trying to use 255.255.255.255 to reach something not on a local >> subnet? >> > >> >If you have multiple interfaces, a broadcast to 255.255.255.255 should go >> out on >> >all of them. That being said, the all-ones broadcast address means "all >> local >> >networks", and most routers will block such traffic from passing on in any >> event. >> > >> >-- >> >-Chuck >> > >> _______________________________________________ >> 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 Wed Jul 2 00:10:17 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09D0037B401; Wed, 2 Jul 2003 00:10:17 -0700 (PDT) Received: from mail.takas.lt (mail-src.takas.lt [212.59.31.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E2C044020; Wed, 2 Jul 2003 00:10:15 -0700 (PDT) (envelope-from tanzer@dsm.fordham.edu) Received: from mail pickup service by mail.takas.lt with Microsoft SMTPSVC; Wed, 2 Jul 2003 10:10:13 +0300 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.5329); Tue, 1 Jul 2003 16:11:31 +0300 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 3B1BC56022; Tue, 1 Jul 2003 06:10:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 233AD37B405; Tue, 1 Jul 2003 06:10:59 -0700 (PDT) Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEE7137B40D; Tue, 1 Jul 2003 05:57:04 -0700 (PDT) Received: from erdos.dsm.fordham.edu (erdos.dsm.fordham.edu [150.108.64.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0D3043F93; Tue, 1 Jul 2003 05:57:01 -0700 (PDT) (envelope-from tanzer@dsm.fordham.edu) Received: from erdos.dsm.fordham.edu (localhost [127.0.0.1]) by erdos.dsm.fordham.edu (8.12.8/8.12.8) with ESMTP id h61Cuxsr009913; Tue, 1 Jul 2003 08:56:59 -0400 Received: from localhost (tanzer@localhost)h61Cut7a009909; Tue, 1 Jul 2003 08:56:55 -0400 Date: Tue, 1 Jul 2003 08:56:55 -0400 (EDT) From: "Edward F. Tanzer" To: freebsd-net@freebsd.org, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-hackers@freebsd.org Errors-To: owner-freebsd-hackers@freebsd.org X-OriginalArrivalTime: 01 Jul 2003 13:11:31.0852 (UTC) FILETIME=[4A4984C0:01C33FD2] cc: chrisy@flirble.org Subject: ANNOUNCE: Multipath Patches for 4.8-STABLE Available X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 07:10:17 -0000 Multipath route table. Ported to FreeBSD 4.8 by Ed Tanzer . Version 5, released agains FreeBSD 4.8-STABLE 2003/06/27 http://www.dsm.fordham.edu/~tanzer/multipath/ _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 00:19:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C47B337B404 for ; Wed, 2 Jul 2003 00:19:30 -0700 (PDT) Received: from mailman.research.att.com (H-135-207-24-32.research.att.com [135.207.24.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6D1843FA3 for ; Wed, 2 Jul 2003 00:19:29 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71])h627Cu3j030951; Wed, 2 Jul 2003 03:12:56 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])h627HZXs020163; Wed, 2 Jul 2003 03:17:35 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h627JSB02890; Wed, 2 Jul 2003 00:19:28 -0700 (PDT) Message-Id: <200307020719.h627JSB02890@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: mgrooms@shrew.net Date: Wed, 2 Jul 2003 00:19:27 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d cc: freebsd-net@freebsd.org Subject: Re: broadcast udp packets ... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 07:19:31 -0000 The short answer is no, you can't, in_pcb turns 255.255.255.255 into the "primary" interface's broadcast address. I doubt this is actually useful behavior, but that's not what you asked =) Bill From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 04:38:58 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DA1E37B401 for ; Wed, 2 Jul 2003 04:38:58 -0700 (PDT) Received: from web13601.mail.yahoo.com (web13601.mail.yahoo.com [216.136.175.112]) by mx1.FreeBSD.org (Postfix) with SMTP id 9142C43FE0 for ; Wed, 2 Jul 2003 04:38:57 -0700 (PDT) (envelope-from tomysterious@yahoo.se) Message-ID: <20030702113857.47036.qmail@web13601.mail.yahoo.com> Received: from [194.236.155.218] by web13601.mail.yahoo.com via HTTP; Wed, 02 Jul 2003 13:38:57 CEST Date: Wed, 2 Jul 2003 13:38:57 +0200 (CEST) From: =?iso-8859-1?q?jonas=20linden?= To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: ipfw+natd/divert port mapping problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 11:38:58 -0000 Hi! I've set up a new firewall using freebsd 4.8. I'm using ipfw with natd to do port mapping. Everything worked fine while being on my test network. When I moved the firewall to the real place I changed the outer NICs IP nr. When I did this the port mapping stopped working. Status: * There are no files on the firewall that contains the old ip nr at all. * These are the only registered packets by ipfw: 00100 16 3062 allow log ip from any to any via lo0 01700 6 288 divert 8668 log ip from any to any via fxp0 01706 6 288 allow log tcp from CLIENT_IP_NR 1024-65535 to INNER_WEB_SERVER_IP_NR 80 * The log says: ipfw: 1700 Divert 8668 TCP CLIENT_IP_NR:1224 OUTER_NIC_IP_NR:80 in via fxp0 ipfw: 1706 Accept TCP CLIENT_IP_NR:1224 INNER_SERVER_IP_NR:80 in via fxp0 ipfw: 1700 Divert 8668 TCP CLIENT_IP_NR:1224 OUTER_NIC_IP_NR:80 in via fxp0 ipfw: 1706 Accept TCP CLIENT_IP_NR:1224 INNER_SERVER_IP_NR:80 in via fxp0 ipfw: 1700 Divert 8668 TCP CLIENT_IP_NR:1224 OUTER_NIC_IP_NR:80 in via fxp0 ipfw: 1706 Accept TCP CLIENT_IP_NR:1224 INNER_SERVER_IP_NR:80 in via fxp0 *tcpdumps on the inner NIC doesn't register anything. *if I start natd with -v I get: In [TCP] [TCP] CLIENT_IP_NR:1224 -> OUTER_NIC_IP_NR:80 aliased to [TCP] CLIENT_IP_NR:1224 -> INNER_SERVER_IP_NR:80 In [TCP] [TCP] CLIENT_IP_NR:1224 -> OUTER_NIC_IP_NR:80 aliased to [TCP] CLIENT_IP_NR:1224 -> INNER_SERVER_IP_NR:80 In [TCP] [TCP] CLIENT_IP_NR:12324 -> OUTER_NIC_IP_NR:80 aliased to [TCP] CLIENT_IP_NR:1224 -> INNER_SERVER_IP_NR:80 It feels like the packets just disappears. Does anybody know what I might've done wrong and where? /Jonas _____________________________________________________ Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express Se mer på: http://se.docs.yahoo.com/info/express/help/index.html From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 06:34:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B03E37B401 for ; Wed, 2 Jul 2003 06:34:57 -0700 (PDT) Received: from mail.svzserv.kemerovo.su (mail.svzserv.kemerovo.su [213.184.65.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7054F43FB1 for ; Wed, 2 Jul 2003 06:34:53 -0700 (PDT) (envelope-from eugen@grosbein.pp.ru) Received: from main.svzserv.kemerovo.su (root@hq.svzserv.kemerovo.su [213.184.65.65])h62DYkPZ045845 for ; Wed, 2 Jul 2003 21:34:46 +0800 (NKZS) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (D00015.dialonly.kemerovo.su [213.184.66.105]) h62DYhwQ034065 for ; Wed, 2 Jul 2003 21:34:44 +0800 (NKZS) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.9/8.12.9) with ESMTP id h62DW10i000642 for ; Wed, 2 Jul 2003 21:32:01 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.9/8.12.9/Submit) id h62DW1o8000641 for net@freebsd.org; Wed, 2 Jul 2003 21:32:01 +0800 (KRAST) Date: Wed, 2 Jul 2003 21:32:01 +0800 From: Eugene Grosbein To: net@freebsd.org Message-ID: <20030702213201.A599@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Comment-To: All Subject: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: eugen@grosbein.pp.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2003 13:34:57 -0000 Hi! Suppose, we have a router running FreeBSD 4.8-STABLE. Some of transit IP-packets have non-zero IP Precedence. Is it possible to set up the router to rearrange interface queues so that such packets are sent first? Eugene From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 07:02:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1AD437B401 for ; Wed, 2 Jul 2003 07:02:30 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 4586543FFD for ; Wed, 2 Jul 2003 07:02:28 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 20365 invoked from network); 2 Jul 2003 14:02:26 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 2 Jul 2003 14:02:26 -0000 Message-ID: <3F02E5F2.4090407@tenebras.com> Date: Wed, 02 Jul 2003 07:02:26 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: net@freebsd.org References: <20030702213201.A599@grosbein.pp.ru> In-Reply-To: <20030702213201.A599@grosbein.pp.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 14:02:31 -0000 Eugene Grosbein wrote: > Suppose, we have a router running FreeBSD 4.8-STABLE. > Some of transit IP-packets have non-zero IP Precedence. > Is it possible to set up the router to rearrange interface queues > so that such packets are sent first? It seems to me you could use dummynet/ipfw2 to provide a stronge PREFERENCE for packets w/non-zero precedence -- the fairness aspect of dummynet queues works against your stated aim, but probabilistically you could pass all such packets ahead of others. The fairness guarantee means that, even if you had a steady stream of non-zero precedence packets, some others would be transmitted. From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 08:54:56 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32CB237B401 for ; Wed, 2 Jul 2003 08:54:56 -0700 (PDT) Received: from mail.svzserv.kemerovo.su (mail.svzserv.kemerovo.su [213.184.65.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF96443FBD for ; Wed, 2 Jul 2003 08:54:53 -0700 (PDT) (envelope-from eugen@grosbein.pp.ru) Received: from main.svzserv.kemerovo.su (root@hq.svzserv.kemerovo.su [213.184.65.65])h62FsnPZ055776; Wed, 2 Jul 2003 23:54:49 +0800 (NKZS) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (D00015.dialonly.kemerovo.su [213.184.66.105]) h62FskwQ023979; Wed, 2 Jul 2003 23:54:47 +0800 (NKZS) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.9/8.12.9) with ESMTP id h62Fsi0i001802; Wed, 2 Jul 2003 23:54:44 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.9/8.12.9/Submit) id h62Fsgg6001801; Wed, 2 Jul 2003 23:54:42 +0800 (KRAST) Date: Wed, 2 Jul 2003 23:54:42 +0800 From: Eugene Grosbein To: Michael Sierchio Message-ID: <20030702235442.A1757@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F02E5F2.4090407@tenebras.com> cc: net@freebsd.org Subject: Re: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 15:54:56 -0000 > It seems to me you could use dummynet/ipfw2 to provide a > stronge PREFERENCE for packets w/non-zero precedence -- > the fairness aspect of dummynet queues works against your > stated aim, but probabilistically you could pass all > such packets ahead of others. The fairness guarantee > means that, even if you had a steady stream of non-zero > precedence packets, some others would be transmitted. And what bandwidth of pipe should I use? Note that I do not need traffic shaping, I need to rearrange queues only. Eugene P.S. Please CC: me as I'm not in the list. From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 09:18:49 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 834C437B401 for ; Wed, 2 Jul 2003 09:18:49 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E702143FA3 for ; Wed, 2 Jul 2003 09:18:48 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h62GImkN076666; Wed, 2 Jul 2003 09:18:48 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h62GImgr076665; Wed, 2 Jul 2003 09:18:48 -0700 (PDT) (envelope-from rizzo) Date: Wed, 2 Jul 2003 09:18:48 -0700 From: Luigi Rizzo To: Eugene Grosbein Message-ID: <20030702091848.A76558@xorpc.icir.org> References: <3F02E5F2.4090407@tenebras.com> <20030702235442.A1757@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030702235442.A1757@grosbein.pp.ru>; from eugen@grosbein.pp.ru on Wed, Jul 02, 2003 at 11:54:42PM +0800 cc: net@freebsd.org Subject: Re: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 16:18:49 -0000 On Wed, Jul 02, 2003 at 11:54:42PM +0800, Eugene Grosbein wrote: > > It seems to me you could use dummynet/ipfw2 to provide a > > stronge PREFERENCE for packets w/non-zero precedence -- ... > And what bandwidth of pipe should I use? > Note that I do not need traffic shaping, > I need to rearrange queues only. Are you really sure that you are seeing significant queueing in your system ? Reordering packets based on precedence/priority typically makes sense at the bottleneck, not elsewhere. And your bottleneck is probably your ISP, not your local router. If, on the contrary, you have some kind of "slow" interface, such as various kinds of serial lines etc. you might in principle put a call to "if_tx_rdy()" in the 'transmit complete' interrupt service routine of the device driver, and put pipe ... config bw foo0 where foo0 is the name of your device (I introduced this in 3.x times, though no device supports it). cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 09:29:10 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9673437B401 for ; Wed, 2 Jul 2003 09:29:10 -0700 (PDT) Received: from mail.svzserv.kemerovo.su (mail.svzserv.kemerovo.su [213.184.65.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF0C643F85 for ; Wed, 2 Jul 2003 09:29:08 -0700 (PDT) (envelope-from eugen@grosbein.pp.ru) Received: from main.svzserv.kemerovo.su (root@hq.svzserv.kemerovo.su [213.184.65.65])h62GT5PZ057468 for ; Thu, 3 Jul 2003 00:29:05 +0800 (NKZS) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (D00015.dialonly.kemerovo.su [213.184.66.105]) h62GNrwQ044137 for ; Thu, 3 Jul 2003 00:28:16 +0800 (NKZS) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (smmsp@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.9/8.12.9) with ESMTP id h62GNl0i002217 for ; Thu, 3 Jul 2003 00:23:47 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.9/8.12.9/Submit) id h62GMlh4002180; Thu, 3 Jul 2003 00:22:47 +0800 (KRAST) Date: Thu, 3 Jul 2003 00:22:47 +0800 From: Eugene Grosbein To: Michael Sierchio Message-ID: <20030703002247.A2097@grosbein.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i cc: net@freebsd.org Subject: Re: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 16:29:10 -0000 > It seems to me you could use dummynet/ipfw2 to provide a > stronge PREFERENCE for packets w/non-zero precedence -- Well, I see now that FreeBSD has very simple and unmanaged interface queues, these are FIFO queues. So if I create dummynet queue and assign better weight to IP packets with ipprecedence, they probably come into interface's FIFOs first and will go out first. That's good, but that is not guaranteed. Then, if prioritized packed arrives when FIFO is not empty, it will not be allowed to go out before packets without ipprecedence that are already in FIFO. That's bad. Eugene P.S. Please CC: me as I'm not in the list. From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 09:38:49 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB3D237B401 for ; Wed, 2 Jul 2003 09:38:49 -0700 (PDT) Received: from mail.svzserv.kemerovo.su (mail.svzserv.kemerovo.su [213.184.65.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B3BD43F3F for ; Wed, 2 Jul 2003 09:38:48 -0700 (PDT) (envelope-from eugen@grosbein.pp.ru) Received: from main.svzserv.kemerovo.su (root@hq.svzserv.kemerovo.su [213.184.65.65])h62GchPZ059126; Thu, 3 Jul 2003 00:38:44 +0800 (NKZS) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (D00015.dialonly.kemerovo.su [213.184.66.105]) h62GccwQ054324; Thu, 3 Jul 2003 00:38:39 +0800 (NKZS) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (eugen@localhost [127.0.0.1]) by grosbein.pp.ru (8.12.9/8.12.9) with ESMTP id h62Gaq0i002376; Thu, 3 Jul 2003 00:36:52 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.12.9/8.12.9/Submit) id h62Gaq5h002375; Thu, 3 Jul 2003 00:36:52 +0800 (KRAST) Date: Thu, 3 Jul 2003 00:36:52 +0800 From: Eugene Grosbein To: Luigi Rizzo Message-ID: <20030703003651.A2262@grosbein.pp.ru> References: <3F02E5F2.4090407@tenebras.com> <20030702235442.A1757@grosbein.pp.ru> <20030702091848.A76558@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030702091848.A76558@xorpc.icir.org>; from rizzo@icir.org on Wed, Jul 02, 2003 at 09:18:48AM -0700 cc: net@freebsd.org Subject: Re: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 16:38:50 -0000 On Wed, Jul 02, 2003 at 09:18:48AM -0700, Luigi Rizzo wrote: > > > It seems to me you could use dummynet/ipfw2 to provide a > > > stronge PREFERENCE for packets w/non-zero precedence -- > ... > > And what bandwidth of pipe should I use? > > Note that I do not need traffic shaping, > > I need to rearrange queues only. > > Are you really sure that you are seeing significant queueing > in your system ? It seems so. > Reordering packets based on precedence/priority > typically makes sense at the bottleneck, not elsewhere. My prioritized traffic is VoIP that is low volume but intolerate to delays. > And your bottleneck is probably your ISP, not your local router. This traffic originates, passes and terminates inside our heterogeneous network completely. > If, on the contrary, you have some kind of "slow" interface, > such as various kinds of serial lines etc. you might in > principle put a call to "if_tx_rdy()" in the 'transmit complete' > interrupt service routine of the device driver, and put > > pipe ... config bw foo0 > > where foo0 is the name of your device (I introduced this in > 3.x times, though no device supports it). Sadly, I really have slow media (overloaded 2Mbit WaveLan) but it is served by standalone router (not bridge) that is capable to rearrange packets using IP precedence. My FreeBSD is connected using 10Mbit ethernet with that WaveLan router (that's name is Revolution) and this 10Mbit segment is loaded too. So if FreeBSD could rearrange queues using IP precedence, that would be pretty useful. Can it? Eugene From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 10:05:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2267B37B437 for ; Wed, 2 Jul 2003 10:05:26 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id E7CF543FD7 for ; Wed, 2 Jul 2003 10:05:23 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 20886 invoked from network); 2 Jul 2003 17:05:22 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 2 Jul 2003 17:05:22 -0000 Message-ID: <3F0310CE.5070302@tenebras.com> Date: Wed, 02 Jul 2003 10:05:18 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: Eugene Grosbein References: <20030703002247.A2097@grosbein.pp.ru> In-Reply-To: <20030703002247.A2097@grosbein.pp.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 17:05:26 -0000 Eugene Grosbein wrote: > Then, if prioritized packed arrives when FIFO is not empty, > it will not be allowed to go out before packets without ipprecedence > that are already in FIFO. That's bad. That's not quite right. The prioritized packet will presumably be handled by a different (dummynet) queue, and that queue will have a higher weight than the other queue (for lower priority traffic). Luigi will correct me if I'm wrong, but it's probably important to keep the high-priority VoIP queue small -- either in bytes or packets, representing the actual bandwidth. This will cause he WFQ to kick in. Because of fairness, it won't *prevent* low-priority packets from being transmitted -- and that's important, since queueing systems can suffer horrible locks from a small amount of traffic otherwise -- but it should accomplish your goal. Tuning is your job, though, Zhenya. ;-) From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 10:31:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AAFC37B401 for ; Wed, 2 Jul 2003 10:31:16 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id C493343F75 for ; Wed, 2 Jul 2003 10:31:15 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 21033 invoked from network); 2 Jul 2003 17:31:15 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 2 Jul 2003 17:31:15 -0000 Message-ID: <3F0316DE.3040301@tenebras.com> Date: Wed, 02 Jul 2003 10:31:10 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 17:31:16 -0000 Currently, performance w/divert sockets and natd in ipfirewall on a compute-bound platform (ELAN-133MHz) shows ipfw+natd throughput to be 50% of that offered by ipfilter+ipnat. Is there anything that can be done to speed up either the performance of divert and natd? Alternatively, could network address translation be merged into ipfirewall? As we move from 1000BASE-TX to 10000BASE-TX, this will become more of an issue, even on 3GHz machines. Comments? Suggestions? Vision? From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 11:14:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27E8C37B401 for ; Wed, 2 Jul 2003 11:14:44 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6544943FD7 for ; Wed, 2 Jul 2003 11:14:43 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h62IEgQv004237; Wed, 2 Jul 2003 14:14:42 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h62IEgPT004236; Wed, 2 Jul 2003 14:14:42 -0400 (EDT) Date: Wed, 2 Jul 2003 14:14:42 -0400 From: Barney Wolff To: jonas linden Message-ID: <20030702181442.GA4179@pit.databus.com> References: <20030702113857.47036.qmail@web13601.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030702113857.47036.qmail@web13601.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: freebsd-net@freebsd.org Subject: Re: ipfw+natd/divert port mapping problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 18:14:44 -0000 On Wed, Jul 02, 2003 at 01:38:57PM +0200, jonas linden wrote: > I've set up a new firewall using freebsd 4.8. I'm > using ipfw with natd to do port mapping. Everything > worked fine while being on my test network. When I > moved the firewall to the real place I changed the > outer NICs IP nr. When I did this the port mapping > stopped working. I'd put "via OUTER_INTERFACE" on the divert statement, and check routing, forwarding enabled. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 11:38:40 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FC2837B401; Wed, 2 Jul 2003 11:38:40 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7956A43F3F; Wed, 2 Jul 2003 11:38:39 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h62IccQv004433; Wed, 2 Jul 2003 14:38:38 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h62IccqD004432; Wed, 2 Jul 2003 14:38:38 -0400 (EDT) Date: Wed, 2 Jul 2003 14:38:38 -0400 From: Barney Wolff To: Michael Sierchio Message-ID: <20030702183838.GB4179@pit.databus.com> References: <3F0316DE.3040301@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0316DE.3040301@tenebras.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 18:38:40 -0000 On Wed, Jul 02, 2003 at 10:31:10AM -0700, Michael Sierchio wrote: > > Currently, performance w/divert sockets and natd in ipfirewall > on a compute-bound platform (ELAN-133MHz) shows ipfw+natd throughput > to be 50% of that offered by ipfilter+ipnat. > > Is there anything that can be done to speed up either the > performance of divert and natd? Alternatively, could network > address translation be merged into ipfirewall? > > As we move from 1000BASE-TX to 10000BASE-TX, this will become > more of an issue, even on 3GHz machines. > > Comments? Suggestions? Vision? NAT is not a security feature, and should be used only where it is actually necessary to translate addresses, and as far towards the edge as possible. If you believe you need to NAT at even 1Gb, I'd look very hard at the requirements. The performance hit on crossing the kernel-userspace boundary for natd is inherent, apart from any code optimization that might be possible. But moving NAT into the kernel has great impact on kernel memory usage, which needs much more care than in user space. NATs can be DoS'd, and running out of kernel memory can be fatal. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 11:44:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62B7C37B401 for ; Wed, 2 Jul 2003 11:44:18 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id C1A1E43FE0 for ; Wed, 2 Jul 2003 11:44:17 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 21431 invoked from network); 2 Jul 2003 18:44:16 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 2 Jul 2003 18:44:16 -0000 Message-ID: <3F0327FE.3030609@tenebras.com> Date: Wed, 02 Jul 2003 11:44:14 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: Barney Wolff References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> In-Reply-To: <20030702183838.GB4179@pit.databus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 18:44:18 -0000 Barney Wolff wrote: > NAT is not a security feature, Many would disagree with that assertion. > and should be used only where it is > actually necessary to translate addresses, and as far towards the edge > as possible. This is typically where firewalls are found. > If you believe you need to NAT at even 1Gb, I'd look > very hard at the requirements. Sadly, requirements are often exogenous. > The performance hit on crossing the kernel-userspace boundary for natd > is inherent, apart from any code optimization that might be possible. Right, it's the copying of data that creates the ultimate barrier. Ruslan has suggested an analogue to divert that uses ng_ksocket. That might be promising. > But moving NAT into the kernel has great impact on kernel memory usage, > which needs much more care than in user space. NATs can be DoS'd, > and running out of kernel memory can be fatal. Stateful packet filters can be DoS'd. From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 11:55:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3BB737B401; Wed, 2 Jul 2003 11:55:39 -0700 (PDT) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEA8843FAF; Wed, 2 Jul 2003 11:55:38 -0700 (PDT) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h62ItcQv004749; Wed, 2 Jul 2003 14:55:38 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h62ItcBP004748; Wed, 2 Jul 2003 14:55:38 -0400 (EDT) Date: Wed, 2 Jul 2003 14:55:38 -0400 From: Barney Wolff To: Michael Sierchio Message-ID: <20030702185538.GA4555@pit.databus.com> References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0327FE.3030609@tenebras.com> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 18:55:40 -0000 On Wed, Jul 02, 2003 at 11:44:14AM -0700, Michael Sierchio wrote: > >NAT is not a security feature, > > Many would disagree with that assertion. They would be wrong. Find a real security expert and ask. ... > >But moving NAT into the kernel has great impact on kernel memory usage, > >which needs much more care than in user space. NATs can be DoS'd, > >and running out of kernel memory can be fatal. > > Stateful packet filters can be DoS'd. Yes, but it's not necessary to keep state for connections from outside in, only from inside out. If you have an enemy inside, nothing will help you. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 12:26:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C476B37B401; Wed, 2 Jul 2003 12:26:48 -0700 (PDT) Received: from out001.verizon.net (out001pub.verizon.net [206.46.170.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91EC843FBD; Wed, 2 Jul 2003 12:26:45 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([141.149.47.46]) by out001.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030702192644.JHUP12592.out001.verizon.net@mac.com>; Wed, 2 Jul 2003 14:26:44 -0500 Message-ID: <3F0331EE.6020707@mac.com> Date: Wed, 02 Jul 2003 15:26:38 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> In-Reply-To: <3F0327FE.3030609@tenebras.com> X-Enigmail-Version: 0.76.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out001.verizon.net from [141.149.47.46] at Wed, 2 Jul 2003 14:26:44 -0500 cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 19:26:49 -0000 Michael Sierchio wrote: > Barney Wolff wrote: >> NAT is not a security feature, > > Many would disagree with that assertion. Many people are wrong, then. NAT is not a security feature. Check the list archives of ... [ ... ] >> If you believe you need to NAT at even 1Gb, I'd look >> very hard at the requirements. > > Sadly, requirements are often exogenous. Nice word. :-) [ NAT sucks. In a very useful way, of course. Exogenous requirements may impose unreasonable constraints upon implementing the technically preferrable solution, just as "inept excess verbiage may disqualify qualifiers". And "But soft, what light through yonder window breaks?" and other tasty bits from the "Applesoft Reference Manual".... ] -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 13:11:03 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0B3737B401 for ; Wed, 2 Jul 2003 13:11:03 -0700 (PDT) Received: from login.caida.org (login.caida.org [192.172.226.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5781F43FCB for ; Wed, 2 Jul 2003 13:11:03 -0700 (PDT) (envelope-from patrick@caida.org) Received: from login.caida.org (localhost [127.0.0.1]) by login.caida.org (8.12.9/8.12.9) with ESMTP id h62KB12e025673 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Jul 2003 13:11:01 -0700 (PDT) Received: from localhost (patrick@localhost)h62KB16d025670; Wed, 2 Jul 2003 13:11:01 -0700 (PDT) X-Authentication-Warning: login.caida.org: patrick owned process doing -bs Date: Wed, 2 Jul 2003 13:11:01 -0700 (PDT) From: Patrick Verkaik To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Patrick Verkaik Subject: multiple routing tables? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 20:11:04 -0000 Does FreeBSD support multiple routing tables? If not, is any work being done in this area? From what I can find, it seems that Linux has this. The reason I'm asking is that I'd like to simulate a number of BGP routers on one box. Thanks, Patrick From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 13:30:29 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA20537B401 for ; Wed, 2 Jul 2003 13:30:29 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37F0543FAF for ; Wed, 2 Jul 2003 13:30:29 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h62KUOq7011346; Wed, 2 Jul 2003 13:30:24 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h62KUOYd011342; Wed, 2 Jul 2003 13:30:24 -0700 Date: Wed, 2 Jul 2003 13:30:24 -0700 From: Brooks Davis To: Patrick Verkaik Message-ID: <20030702203023.GA6814@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org Subject: Re: multiple routing tables? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 20:30:30 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 02, 2003 at 01:11:01PM -0700, Patrick Verkaik wrote: >=20 > Does FreeBSD support multiple routing tables? If not, is any work being > done in this area? From what I can find, it seems that Linux has this. >=20 > The reason I'm asking is that I'd like to simulate a number of BGP routers > on one box. There's a project to virtualize the network stack at: http://www.tel.fer.hr/zec/vimage/ It should do what you want. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/A0DeXY6L6fI4GtQRApyhAKCnpFwE5SsF78l0wUrQRqqGbTjTOQCghBnd Yy1fhQwrOoOu3tg/hB4N7ZU= =A/2E -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 14:33:19 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE21E37B401 for ; Wed, 2 Jul 2003 14:33:19 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id B83BC43F85 for ; Wed, 2 Jul 2003 14:33:18 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 21859 invoked from network); 2 Jul 2003 21:33:18 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 2 Jul 2003 21:33:17 -0000 Message-ID: <3F034F99.2080607@tenebras.com> Date: Wed, 02 Jul 2003 14:33:13 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <20030702185538.GA4555@pit.databus.com> In-Reply-To: <20030702185538.GA4555@pit.databus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 21:33:20 -0000 Barney Wolff wrote: > On Wed, Jul 02, 2003 at 11:44:14AM -0700, Michael Sierchio wrote: > >>>NAT is not a security feature, >> >>Many would disagree with that assertion. > > They would be wrong. Find a real security expert and ask. Clearly that would not be you. Both static and dynamic (or "hide") nat have security functions. > Yes, but it's not necessary to keep state for connections from outside in, > only from inside out. If you have an enemy inside, nothing will help you. Actually, you're quite mistaken. There are reasons for maintaining state for VPN and other connections that are unrelated to public services. And it's probably better to exhaust mbufs at the perimeter than the interior... From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 14:38:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D5F937B401 for ; Wed, 2 Jul 2003 14:38:26 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 3419343FDD for ; Wed, 2 Jul 2003 14:38:25 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 21894 invoked from network); 2 Jul 2003 21:38:24 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 2 Jul 2003 21:38:24 -0000 Message-ID: <3F0350C7.7010009@tenebras.com> Date: Wed, 02 Jul 2003 14:38:15 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> In-Reply-To: <3F0331EE.6020707@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 21:38:26 -0000 Chuck Swiger wrote: > Many people are wrong, then. NAT is not a security feature. We simply disagree. > [ NAT sucks. In a very useful way, of course. Exogenous requirements > may impose unreasonable constraints upon implementing the technically > preferrable solution, just as "inept excess verbiage may disqualify > qualifiers". And "But soft, what light through yonder window breaks?" > and other tasty bits from the "Applesoft Reference Manual".... ] Yep, NAT sucks. Exogenous requirements are often generated by marketing fools who think we need to match a technically trivial and meaningless feature in someone else's product. However, twenty some odd years of software engineering has taught me to pick my fights ;-) Back to the original topic -- divert functionality for ng_ksocket? Useful for much more than nat. From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 14:40:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FA3C37B401 for ; Wed, 2 Jul 2003 14:40:01 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 716E443FBF for ; Wed, 2 Jul 2003 14:40:00 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 65564 invoked from network); 2 Jul 2003 21:39:59 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 2 Jul 2003 21:39:59 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 2 Jul 2003 18:39:42 -0500 (CDT) From: Mike Silbersack To: Michael Sierchio In-Reply-To: <3F0316DE.3040301@tenebras.com> Message-ID: <20030702183443.C1913@odysseus.silby.com> References: <3F0316DE.3040301@tenebras.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@FreeBSD.ORG cc: freebsd-net@FreeBSD.ORG Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 21:40:01 -0000 On Wed, 2 Jul 2003, Michael Sierchio wrote: > Currently, performance w/divert sockets and natd in ipfirewall > on a compute-bound platform (ELAN-133MHz) shows ipfw+natd throughput > to be 50% of that offered by ipfilter+ipnat. > > Is there anything that can be done to speed up either the > performance of divert and natd? Alternatively, could network > address translation be merged into ipfirewall? > > As we move from 1000BASE-TX to 10000BASE-TX, this will become > more of an issue, even on 3GHz machines. > > Comments? Suggestions? Vision? If you have some time to throw at the problem, you might consider using gprof on natd in order to determine what exactly about natd is slow. As is commonly mentioned, the kernel <-> userspace switch is probably one reason for natd's relative slowness, but I would bet that a decent speedup could be achieved just by optimizing natd. Heck, it might be as simple as increasing the size of some hash tables or buffers. Tell us how it goes. :) Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 15:42:50 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D64037B408 for ; Wed, 2 Jul 2003 15:42:50 -0700 (PDT) Received: from cultdeadsheep.org (charon.cultdeadsheep.org [80.65.226.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92D3943FDF for ; Wed, 2 Jul 2003 15:42:47 -0700 (PDT) (envelope-from sheepkiller@cultdeadsheep.org) Received: (qmail 28047 invoked from network); 2 Jul 2003 22:42:45 -0000 Received: from unknown (HELO chuck.cultdeadsheep.org) (192.168.0.12) by goofy.cultdeadsheep.org with SMTP; 2 Jul 2003 22:42:45 -0000 Date: Thu, 3 Jul 2003 00:42:26 +0200 From: Clement Laforet To: Mike Silbersack Message-Id: <20030703004226.026fdfa4.sheepkiller@cultdeadsheep.org> In-Reply-To: <20030702183443.C1913@odysseus.silby.com> References: <3F0316DE.3040301@tenebras.com> <20030702183443.C1913@odysseus.silby.com> Organization: tH3 cUlt 0f tH3 d3@d sH33p X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-portbld-freebsd5.1) X-Face: ._cVVRDn#-2((lnfi^P7CoD4htI$4+#G/G)!w|,}H5yK~%(3-C.JlEYbOjJGFwJkt*7N^%z jYeu[;}]}F"3}l5R'l"X0HbvT^D\Q&%deCo)MayY`);TO Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-ipfw@FreeBSD.ORG cc: freebsd-net@FreeBSD.ORG Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 22:42:50 -0000 Hi, On Wed, 2 Jul 2003 18:39:42 -0500 (CDT) Mike Silbersack wrote: > > Comments? Suggestions? Vision? > > If you have some time to throw at the problem, you might consider > using gprof on natd in order to determine what exactly about natd is > slow. As is commonly mentioned, the kernel <-> userspace switch is > probably one reason for natd's relative slowness, but I would bet that > a decent speedup could be achieved just by optimizing natd. Heck, it > might be as simple as increasing the size of some hash tables or > buffers. > > Tell us how it goes. :) Few weeks ago, I've post a patch which impoves natd for INCOMING connections (and breaks some options), I ran gprof to find where natd and libalias lack of performance : 1. sendto(), recvfrom() [natd] an gettimeofday() [libalias] eat a lot of CPU 2. [libalias] hash tables for incoming pakets is VERY poor since the hash is based on alias address, it's mandatory for outgoing connections I think, but for incoming redirect, it eats a lot of time (47% according to gprof under heavy load), since the hash key is the same for all incoming packets. 3. expire mecanisms is too slow, having small tables under heavy load slows NAT'ing drastically. I had best performance with #define LINK_TABLE_OUT_SIZE 4091 #define LINK_TABLE_IN_SIZE 8123 4. matching might be improved to. Better with tables dedicated to redirects ("only" ~50% of CPU time, for ~55Mbp/s on a PIII 700, 90% of this CPU time was used by syscalls). My 2cts... If somebody cares, I'm currently writing an in-kernel && in-ipfw NAT to perform load balancing, if you have any suggestion, I'm all ears :) Regards, clem From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 16:06:35 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42E2737B401; Wed, 2 Jul 2003 16:06:35 -0700 (PDT) Received: from pop016.verizon.net (pop016pub.verizon.net [206.46.170.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54EAA43F85; Wed, 2 Jul 2003 16:06:34 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([141.149.47.46]) by pop016.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030702230633.CZRV3199.pop016.verizon.net@mac.com>; Wed, 2 Jul 2003 18:06:33 -0500 Message-ID: <3F036571.8030609@mac.com> Date: Wed, 02 Jul 2003 19:06:25 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com> In-Reply-To: <3F0350C7.7010009@tenebras.com> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from [141.149.47.46] at Wed, 2 Jul 2003 18:06:33 -0500 cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 23:06:35 -0000 Michael Sierchio wrote: > Chuck Swiger wrote: >> Many people are wrong, then. NAT is not a security feature. > > We simply disagree. To the extent that "security" is a matter of opinion, I guess that's all right: I'm not concerned if other people have different opinions than I do. To the extent that security is a testable, measurable, repeatable, and refutable subject-- that is to say, to the extent that security is a science with deals in facts, not opinions-- NAT plus a packet-filtering firewall (such as natd+ipfw) provides no better security than the packet-filtering firewall would alone. By itself, NAT provides no benefit to security, and some implementations actually reduce the security of the system compared with not running NAT. Let me pull out a couple of quotes from various people: "> I recognise what you are saying, but what I was trying to understand was, > are the low-end appliance 'firewalls' really providing much more security > than NAT? In a small office/home situation if people are going to use IRC, My point was that they're able to provide more security- but if you're going to align a security policy with a NAT device, then you're giving up a large part of the point of having a firewall. If we, as a community can get people to use *firewalls* for *firewalling* then we'll have done both ourselves and everyone else a better service than to say "oh, just use anything that'll let you connect." > they would just reconfigure their firewall to do so, after all they own it. > I was just trying to get all the 'block xyz outbound' issues out of the way. > > Can NAT sessions be hijacked or somehow abused to give access to the > internal network? There is the case of visiting a hostile website and > "inviting in" some problematic programs, but apart from that are the > appliance based firewalls doing more than that? In general, NAT based things aren't written for security, they're written for network re-mapping, so there can be things that escape the author that a firewall author shouldn't miss (or may have tested by a 3rd party for some level of assurance.[1]) Firewalls should handle things like source routed packets, overlapping fragments, etc. They also may handle things like VPNs, authentication, "enterprise" policy enforcement, etc. Paul [1.] Obviously, I'm highly biased about which certification program a firewall should pass to be on the market. My employer owns ICSA Labs, this list is hosted from there, etc. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@patriot.net which may have no basis whatsoever in fact." probertson@trusecure.com Director of Risk Assessment TruSecure Corporation" -- "I would add that a large number of these hospitals have elected to do NAT from their router/ Internet Gateway. Worst yet they depend on their router as THE FW. This is a bad choice for any network topology, which connects to the Internet, IMHO. Such topologies are vulnerable to Disclosure, Integrity and DDOS threats and place the majority of the raise the risk cost on the NAT/Router. This is a poor response to meet HIPAA compliance requirements. Sorry CISCO." -- "Since NAT actually adds no security, I'd put the nameservers on a DMZ of their own and not NAT between them and the Internet. For internal lookups, I'd use separate internal servers that forward to the DMZ servers for non-internal domains. Or use views to cause the DMZ servers to return different answers for queries from inside. You can still NAT between inside and outside if management insists." -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 16:19:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE3B937B401; Wed, 2 Jul 2003 16:19:39 -0700 (PDT) Received: from skynet.stack.nl (skynet.stack.nl [131.155.140.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id F34A143F93; Wed, 2 Jul 2003 16:19:38 -0700 (PDT) (envelope-from dean@dragon.stack.nl) Received: by skynet.stack.nl (Postfix, from userid 65534) id 94B903E2F; Thu, 3 Jul 2003 01:20:14 +0200 (CEST) Received: from dragon.stack.nl (dragon.stack.nl [2001:610:1108:5011:207:e9ff:fe09:230]) by skynet.stack.nl (Postfix) with ESMTP id 2E29B3E27; Thu, 3 Jul 2003 01:20:10 +0200 (CEST) Received: by dragon.stack.nl (Postfix, from userid 1600) id 76FEE5F187; Thu, 3 Jul 2003 01:19:33 +0200 (CEST) Date: Thu, 3 Jul 2003 01:19:33 +0200 From: Dean Strik To: Michael Sierchio Message-ID: <20030702231933.GD17796@dragon.stack.nl> References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F0350C7.7010009@tenebras.com> X-Editor: VIM Rulez! http://www.vim.org/ X-MUD: Outerspace - telnet://mud.stack.nl:3333 X-Really: Yes User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 23:19:40 -0000 Michael Sierchio wrote: > Chuck Swiger wrote: > > >Many people are wrong, then. NAT is not a security feature. > > We simply disagree. Puh-leaze. Not this discussion again. Can we stay on topic please? -- Dean C. Strik Eindhoven University of Technology dean@stack.nl | dean@ipnet6.org | http://www.ipnet6.org/ "This isn't right. This isn't even wrong." -- Wolfgang Pauli From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 16:32:51 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F01737B401; Wed, 2 Jul 2003 16:32:51 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F80A43F93; Wed, 2 Jul 2003 16:32:47 -0700 (PDT) (envelope-from ru@sunbay.com) Received: from whale.sunbay.crimea.ua (ru@localhost [127.0.0.1]) h62NWfVU063369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jul 2003 02:32:42 +0300 (EEST) (envelope-from ru@sunbay.com) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.12.9/8.12.8/Submit) id h62NWfFd063364; Thu, 3 Jul 2003 02:32:41 +0300 (EEST) (envelope-from ru) Date: Thu, 3 Jul 2003 02:32:41 +0300 From: Ruslan Ermilov To: Chuck Swiger Message-ID: <20030702233241.GD48919@sunbay.com> References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com> <3F036571.8030609@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tmoQ0UElFV5VgXgH" Content-Disposition: inline In-Reply-To: <3F036571.8030609@mac.com> User-Agent: Mutt/1.5.4i cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 23:32:51 -0000 --tmoQ0UElFV5VgXgH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 02, 2003 at 07:06:25PM -0400, Chuck Swiger wrote: [...] > By itself, NAT provides no benefit to security, and some implementations= =20 > actually reduce the security of the system compared with not running NAT.= =20 >=20 Our natd(8) contributes to security somewhat, by providing the -deny_incoming option. Also, by using a dedicated IP address for a NAT, and blocking (with a firewall) all incoming packets that do not match an already established connections (originated locally, or mapped with static redirection rules), you secure your NAT host. (This is even without the -deny_incoming option to natd(8).) Here's the relevant part of the functioning firewall ruleset: # Route to the per-interface ruleset. ${fwcmd} add skipto 1000 ip from any to any via ${iif} ${fwcmd} add skipto 2000 ip from any to any via ${oif} =2E.. # EXTERNAL INTERFACE RULESET # Spoof protection. ${fwcmd} add 2000 deny ip from ${inet} to any in =2E.. # NAT. ${fwcmd} add divert natd ip from ${inet} to any out ${fwcmd} add divert natd ip from any to ${nat} in ${fwcmd} add deny ip from any to ${nat} in Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software Ltd, ru@FreeBSD.org FreeBSD committer --tmoQ0UElFV5VgXgH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/A2uZUkv4P6juNwoRAj2SAJ9aIe42xbaPocME6I4UxKDvtfAPTQCdGhi/ BiAC1vDJPZmpBY3/m7T7fMQ= =PYBU -----END PGP SIGNATURE----- --tmoQ0UElFV5VgXgH-- From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 16:42:47 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E110037B401 for ; Wed, 2 Jul 2003 16:42:47 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id CF65943FF9 for ; Wed, 2 Jul 2003 16:42:46 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 22638 invoked from network); 2 Jul 2003 23:42:46 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 2 Jul 2003 23:42:46 -0000 Message-ID: <3F036DEE.8010408@tenebras.com> Date: Wed, 02 Jul 2003 16:42:38 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: Chuck Swiger References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com> <3F036571.8030609@mac.com> In-Reply-To: <3F036571.8030609@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 02 Jul 2003 23:42:48 -0000 Chuck Swiger wrote: > To the extent that "security" is a matter of opinion, I guess that's all > right: I'm not concerned if other people have different opinions than I do. Security is an ill-defined concept. I prefer to think in terms of mitigating risk. In any case, deny_incoming offers some extra measure of security. > By itself, NAT provides no benefit to security, and some implementations > actually reduce the security of the system compared with not running > NAT. Sure, some implementations do. natd(8) was the first NAT daemon AFAIK to correctly handle the problem of rewriting the included IP header in ICMP error messages from nat'd hosts. > Let me pull out a couple of quotes from various people: You were better off when invoking "science" -- now you're invoking the mob ;-) > "Since NAT actually adds no security, You're of the school that sez "what I tell you three times is true?" From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 17:30:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 161F437B404 for ; Wed, 2 Jul 2003 17:30:36 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 99A8743FFB for ; Wed, 2 Jul 2003 17:30:34 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 7908 invoked from network); 3 Jul 2003 00:30:33 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 3 Jul 2003 00:30:33 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 2 Jul 2003 21:30:16 -0500 (CDT) From: Mike Silbersack To: Chuck Swiger In-Reply-To: <3F036571.8030609@mac.com> Message-ID: <20030702212709.M1913@odysseus.silby.com> References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com> <3F036571.8030609@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Jul 2003 00:30:36 -0000 On Wed, 2 Jul 2003, Chuck Swiger wrote: > By itself, NAT provides no benefit to security, and some implementations > actually reduce the security of the system compared with not running NAT. Let > me pull out a couple of quotes from various people: Please explain this point more. Say I have 1000 win 9x boxes connected to the internet with routable IPs and no firewall. How will placing them behind a NAT box make them less secure? Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 17:48:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79BD837B401; Wed, 2 Jul 2003 17:48:36 -0700 (PDT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84B2A43F85; Wed, 2 Jul 2003 17:48:35 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([141.149.47.46]) by out005.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030703004834.BQYB20032.out005.verizon.net@mac.com>; Wed, 2 Jul 2003 19:48:34 -0500 Message-ID: <3F037D5B.9070908@mac.com> Date: Wed, 02 Jul 2003 20:48:27 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com> <3F036571.8030609@mac.com> <3F036DEE.8010408@tenebras.com> In-Reply-To: <3F036DEE.8010408@tenebras.com> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [141.149.47.46] at Wed, 2 Jul 2003 19:48:34 -0500 cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Jul 2003 00:48:36 -0000 Michael Sierchio wrote: > Chuck Swiger wrote: [ ... ] > Security is an ill-defined concept. I prefer to think in terms > of mitigating risk. Sure, that works for me. > In any case, deny_incoming offers some extra measure of security. Does it? Serious question, as none of the connections deny_incoming may block would be permitted in the absence of natd and the divert socket, or ipf/ipnat, if you prefer. From "man natd": If you specify real firewall rules, it is best to specify line 2 at the start of the script so that natd sees all packets before they are dropped by the firewall. Wrong order, if you prioritize security-- you worry about NAT'ing traffic that is permitted by the security policy and firewall rules. Most people implementing NAT who follow this advice effectively circumvent egress filtering that may have otherwise applied. [ ... ] >> Let me pull out a couple of quotes from various people: > > You were better off when invoking "science" -- now you're > invoking the mob ;-) If I quoted the opinions of a bunch of chemists about the relative security, or lack thereof, of NAT-- it would be entirely valid to criticise the relevance or expertise those people have with regard to the subject. :-) However, if one were to ask these chemists about acid-base titration, solutions chemistry, and the like, their responses would not be "mere opinion" or "invoking the mob". Their comments would be that of professionals discussing their chosen field, and include real-world observational data from experiments they themselves have performed. >> "Since NAT actually adds no security, > > You're of the school that sez "what I tell you three times is true?" It worked for Dorothy, right? :-) -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 18:05:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C08D837B404; Wed, 2 Jul 2003 18:05:11 -0700 (PDT) Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8644843FE0; Wed, 2 Jul 2003 18:05:10 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([141.149.47.46]) by pop015.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030703010509.BEDC20810.pop015.verizon.net@mac.com>; Wed, 2 Jul 2003 20:05:09 -0500 Message-ID: <3F03813E.9020407@mac.com> Date: Wed, 02 Jul 2003 21:05:02 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com> <3F036571.8030609@mac.com> <20030702212709.M1913@odysseus.silby.com> In-Reply-To: <20030702212709.M1913@odysseus.silby.com> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop015.verizon.net from [141.149.47.46] at Wed, 2 Jul 2003 20:05:09 -0500 cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Jul 2003 01:05:12 -0000 Mike Silbersack wrote: [ ... ] > Please explain this point more. > > Say I have 1000 win 9x boxes connected to the internet with routable IPs > and no firewall. How will placing them behind a NAT box make them less > secure? "man natd" suggests that you've just enabled IP spoofing for the LAN: You should be aware of the fact that, with these firewall settings, everyone on your local network can fake his source-address using your host as gateway. If there are other hosts on your local net- work, you are strongly encouraged to create firewall rules that only allow traffic to and from trusted hosts. People using NAT tend to permit arbitrary outbound connections from clients rather than, for example, mandating that all permitted client connections go through a designated and monitored proxy. The placement of the divert rule early on tends to circumvent egress filtering. However, I would suggest that my point has less to do with whether NAT can reduce the security of a completely open network with no firewall any further (although there are ways that it could), and more to do with whether the combination of firewall+NAT is particularly safe and secure compared with firewall-without-NAT. At the very least, using NAT on the firewall increases the scope and potential of denial-of-service attacks to exhaust kernel memory or sockets (if use_sockets is set). -- -Chuck PS: But I also saw comments from Ruslan and Dean, and I'm willing to let this issue lapse rather than prolong a debate that people don't think is on-topic. From owner-freebsd-net@FreeBSD.ORG Wed Jul 2 18:26:17 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C81D37B401; Wed, 2 Jul 2003 18:26:17 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1F0E43FD7; Wed, 2 Jul 2003 18:26:16 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc12) with ESMTP id <2003070301261601400gjfnre>; Thu, 3 Jul 2003 01:26:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA72269; Wed, 2 Jul 2003 18:26:11 -0700 (PDT) Date: Wed, 2 Jul 2003 18:26:09 -0700 (PDT) From: Julian Elischer To: Clement Laforet In-Reply-To: <20030703004226.026fdfa4.sheepkiller@cultdeadsheep.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@FreeBSD.ORG cc: freebsd-net@FreeBSD.ORG Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Jul 2003 01:26:17 -0000 On Thu, 3 Jul 2003, Clement Laforet wrote: > Hi, > > On Wed, 2 Jul 2003 18:39:42 -0500 (CDT) > Mike Silbersack wrote: > > > > Comments? Suggestions? Vision? > > > > If you have some time to throw at the problem, you might consider > > using gprof on natd in order to determine what exactly about natd is > > slow. As is commonly mentioned, the kernel <-> userspace switch is > > probably one reason for natd's relative slowness, but I would bet that > > a decent speedup could be achieved just by optimizing natd. Heck, it > > might be as simple as increasing the size of some hash tables or > > buffers. > > > > Tell us how it goes. :) > > Few weeks ago, I've post a patch which impoves natd for INCOMING > connections (and breaks some options), I ran gprof to find where > natd and libalias lack of performance : > 1. sendto(), recvfrom() [natd] an gettimeofday() [libalias] eat a lot of > CPU > 2. [libalias] hash tables for incoming pakets is VERY poor since the > hash is based on alias address, it's mandatory for outgoing connections > I think, but for incoming redirect, it eats a lot of time (47% > according to gprof under heavy load), since the hash key is the same for > all incoming packets. > 3. expire mecanisms is too slow, having small tables under heavy load > slows NAT'ing drastically. > I had best performance with > #define LINK_TABLE_OUT_SIZE 4091 > #define LINK_TABLE_IN_SIZE 8123 > 4. matching might be improved to. > > Better with tables dedicated to redirects ("only" ~50% of CPU time, for > ~55Mbp/s on a PIII 700, 90% of this CPU time was used by syscalls). > > My 2cts... > > If somebody cares, I'm currently writing an in-kernel && in-ipfw NAT to > perform load balancing, if you have any suggestion, I'm all ears :) > also make sure your rules say divert xxxx ip from any to [IPADRESS] in recv [interface] and divert xxxx ip from not [IPADDR] recv [inside-if] out xmit [interface] to avoid sending packets to the NATd that have no possible reason to go there.. All incoming nat'd packets are addressed to the local machine All outgoing packets that should be nat'd are from somewhere else. I've seen cases where thre is a lot of interference with NAT from other traffic making natd do extra work for no reason.. > Regards, > > clem > _______________________________________________ > 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 Wed Jul 2 18:30:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2641137B401 for ; Wed, 2 Jul 2003 18:30:00 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BB1343FAF for ; Wed, 2 Jul 2003 18:29:58 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])h631TpCo075456; Thu, 3 Jul 2003 09:29:52 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <3F03867A.79F82968@kuzbass.ru> Date: Thu, 03 Jul 2003 09:27:22 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Michael Sierchio References: <20030703002247.A2097@grosbein.pp.ru> <3F0310CE.5070302@tenebras.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: Eugene Grosbein cc: net@freebsd.org Subject: Re: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Jul 2003 01:30:00 -0000 Michael Sierchio wrote: > > Eugene Grosbein wrote: > > > Then, if prioritized packed arrives when FIFO is not empty, > > it will not be allowed to go out before packets without ipprecedence > > that are already in FIFO. That's bad. > > That's not quite right. The prioritized packet will presumably be > handled by a different (dummynet) queue, and that queue will have > a higher weight than the other queue (for lower priority traffic). In addition to dummynet WFQ queue there is interface FIFO queue. Always, even in the absence of dummynet :-) It keeps packets that cannot be transmitted immediately because device is busy. And FIFO, by definition, will not allow prioritized packets to go out before others. Eugene From owner-freebsd-net@FreeBSD.ORG Thu Jul 3 01:30:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B75F37B401; Thu, 3 Jul 2003 01:30:11 -0700 (PDT) Received: from da.mailomat.net (mailomat.net [212.185.46.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id A956343FE0; Thu, 3 Jul 2003 01:30:05 -0700 (PDT) (envelope-from ap@bnc.net) Received: This line has been intentionally left blank. Received: from colossus.bnc.net (port-212-202-7-149.reverse.qsc.de [212.202.7.149]) (user=bnc.mail author=<> mech=PLAIN bits=0) h638RD8J023951; Thu, 3 Jul 2003 10:27:15 +0200 (CEST) (envelope-from ap@bnc.net) Received: from colossus.bnc.net (localhost [IPv6:::1]) by colossus.bnc.net (8.12.6/8.12.6) with ESMTP id h638TqZ1092903; Thu, 3 Jul 2003 10:29:53 +0200 (CEST) (envelope-from ap@colossus.bnc.net) Received: (from ap@localhost) by colossus.bnc.net (8.12.6/8.12.6/Submit) id h638Tquw092902; Thu, 3 Jul 2003 10:29:52 +0200 (CEST) (envelope-from ap) Date: Thu, 3 Jul 2003 10:29:52 +0200 From: Achim Patzner To: Chuck Swiger Message-ID: <20030703082952.GA92881@bnc.net> References: <3F0316DE.3040301@tenebras.com> <20030702183838.GB4179@pit.databus.com> <3F0327FE.3030609@tenebras.com> <3F0331EE.6020707@mac.com> <3F0350C7.7010009@tenebras.com> <3F036571.8030609@mac.com> <3F036DEE.8010408@tenebras.com> <3F037D5B.9070908@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F037D5B.9070908@mac.com> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS perl-11 cc: freebsd-ipfw@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: Performance improvement for NAT in IPFIREWALL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Jul 2003 08:30:11 -0000 On Wed, Jul 02, 2003 at 08:48:27PM -0400, Chuck Swiger wrote: > >>"Since NAT actually adds no security, > >You're of the school that sez "what I tell you three times is true?" > It worked for Dorothy, right? :-) Well... If you only want to convince hillbillies it might be enough. Actually NAT makes networks safer; it has been stopping a lot of drive-by self-foot-shooting by Windows users around me (who were so frustrated by not being able to run their c00l borgware. You see? I'm a strong believer in "the enemy is NOT out there on the Net"... Achim From owner-freebsd-net@FreeBSD.ORG Thu Jul 3 01:35:42 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 811B837B405 for ; Thu, 3 Jul 2003 01:35:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 173DF43FE3 for ; Thu, 3 Jul 2003 01:35:41 -0700 (PDT) (envelope-from molter@tin.it) Received: from tin.it (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2003 10:35:56 +0200 Received: from cisco.com (localhost [127.0.0.1])h638XZI7000275 for ; Thu, 3 Jul 2003 10:33:35 +0200 (MET DST) Received: from www.example.org (dhcp-nic-val-26-108.cisco.com [64.103.26.108]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id KAA06743 for ; Thu, 3 Jul 2003 10:35:39 +0200 (MET DST) Received: (qmail 27819 invoked by uid 1000); 3 Jul 2003 08:35:24 -0000 Date: Thu, 3 Jul 2003 10:35:24 +0200 From: Marco Molteni To: freebsd-net@freebsd.org Message-ID: <20030703083524.GB25021@cobweb.example.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: multiple routing tables? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Jul 2003 08:35:42 -0000 Patrick Verkaik wrote [2003-07-02]: > > Does FreeBSD support multiple routing tables? If not, is any work being > done in this area? From what I can find, it seems that Linux has this. > > The reason I'm asking is that I'd like to simulate a number of BGP routers > on one box. At the 2nd European BSD conference there were two presentations about this topic, one was the stack virtualization cited by Brooks, the other was "Advanced VPN support" that, if I remember correctly, implemented multiple routing tables. More info at http://bsdconeurope.org/papers/, see Riccardo Scandariato, Advanced VPN support on FreeBSD systems marco -- C'e' chi sa andare in moto su una ruota sola, ma bisogna essere bravi, e se uno non lo sa fare va su due ruote come me e tutte le persone normali. -- Luigi Rizzo. From owner-freebsd-net@FreeBSD.ORG Thu Jul 3 06:38:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30A3437B401 for ; Thu, 3 Jul 2003 06:38:26 -0700 (PDT) Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by mx1.FreeBSD.org (Postfix) with SMTP id AE80643FBF for ; Thu, 3 Jul 2003 06:38:25 -0700 (PDT) (envelope-from tomysterious@yahoo.se) Received: from as1-2-2.ov.s.bonet.se (HELO yahoo.se) (tomysterious@194.236.155.218 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Jul 2003 13:38:25 -0000 Message-ID: <3F043162.9625A63@yahoo.se> Date: Thu, 03 Jul 2003 15:36:35 +0200 From: jonas linden X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20030702113857.47036.qmail@web13601.mail.yahoo.com> <20030702181442.GA4179@pit.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: ipfw+natd/divert port mapping problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: e96_jol@e.kth.se List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 13:38:26 -0000 Thanks for the input. I still have the same problem but ... I've now found that I can divert the traffic to any ip nr on my LAN but the web servers ip nr. I've tampered around with the fw rules and it's still the same thing. I've looked for that ip nr in all the files and found nothing. I have really simple fw rules and natd is started with /sbin/natd -l -s -m -log_facility A_FACILITY -a OUTER_NIC_IP_NR -redirect_port tcp INNER_SERVER_IP_NR:80 80 I can reach the inner server with ssh and the routing table looks fine. What could be wrong? Thanks /Jonas Linden Barney Wolff wrote: > On Wed, Jul 02, 2003 at 01:38:57PM +0200, jonas linden wrote: > > I've set up a new firewall using freebsd 4.8. I'm > > using ipfw with natd to do port mapping. Everything > > worked fine while being on my test network. When I > > moved the firewall to the real place I changed the > > outer NICs IP nr. When I did this the port mapping > > stopped working. > > I'd put "via OUTER_INTERFACE" on the divert statement, and check routing, > forwarding enabled. > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the 'Net. > _______________________________________________ > 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 Thu Jul 3 12:31:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E86337B405 for ; Thu, 3 Jul 2003 12:31:34 -0700 (PDT) Received: from mail.dada.it (mail2.dada.it [195.110.100.2]) by mx1.FreeBSD.org (Postfix) with SMTP id E18FD44005 for ; Thu, 3 Jul 2003 12:31:31 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 29766 invoked from network); 3 Jul 2003 19:31:25 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 3 Jul 2003 19:31:25 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id 164516248; Thu, 3 Jul 2003 21:31:22 +0200 (CEST) Date: Thu, 3 Jul 2003 21:31:22 +0200 From: Alessandro de Manzano To: Doug White Message-ID: <20030703213122.A87802@libero.sunshine.ale> References: <20030630212122.A72414@libero.sunshine.ale> <20030630233626.A73415@libero.sunshine.ale> <20030701134658.U40881@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030701134658.U40881@carver.gumbysoft.com>; from dwhite@gumbysoft.com on Tue, Jul 01, 2003 at 01:50:25PM -0700 X-Operating-System: FreeBSD 4.7-STABLE cc: mobile@freebsd.org cc: Reinhard Speyerer cc: net@freebsd.org Subject: Re: strange PPP negotiation problem with GPRS mobile phone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alessandro de Manzano List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2003 19:31:34 -0000 IT WORKS ! :) Adding an explicit "set ifaddr" statement as suggested by Mr. Speyerer was the key of this issue ! Now PPP(8) correctly negotiate with the peer and all works ! Im currently using the GPRS connection to writing this mail ;) I would thank everbody answered me, many many thanks to you all! -- bye! Ale From owner-freebsd-net@FreeBSD.ORG Thu Jul 3 13:11:32 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CA9637B401 for ; Thu, 3 Jul 2003 13:11:32 -0700 (PDT) Received: from www.ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52D6643F85 for ; Thu, 3 Jul 2003 13:11:31 -0700 (PDT) (envelope-from ambrisko@www.ambrisko.com) Received: from www.ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.8p1/8.12.8) with ESMTP id h63KBUO7082546 for ; Thu, 3 Jul 2003 13:11:30 -0700 (PDT) (envelope-from ambrisko@www.ambrisko.com) Received: (from ambrisko@localhost) by www.ambrisko.com (8.12.8p1/8.12.8/Submit) id h63KBUds082545 for freebsd-net@freebsd.org; Thu, 3 Jul 2003 13:11:30 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200307032011.h63KBUds082545@www.ambrisko.com> To: freebsd-net@freebsd.org Date: Thu, 3 Jul 2003 13:11:30 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: Suggesting for fixing VLAN bridging the right way X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Jul 2003 20:11:32 -0000 I'm trying to bridge VLAN traffic to network that doesn't have that VLAN, something like: (vlan network) -> fxp0 -> vlan0 <- FreeBSD bridge -> rl0 (no tag) Both of the networks are the same except one side is tagged the other has no tag. It works fine in the "no tag" -> "tag" direction. It fails in the "tag" -> "no tag" direction since ether_demux we bail out on this check: if (!(BDG_ACTIVE(ifp))) { /* * Discard packet if upper layers shouldn't see it because it * was unicast to a different Ethernet address. If the driver * is working properly, then this situation can only happen * when the interface is in promiscuous mode. */ if ((ifp->if_flags & IFF_PROMISC) != 0 && (eh->ether_dhost[0] & 1) == 0 && bcmp(eh->ether_dhost, IFP2AC(ifp)->ac_enaddr, ETHER_ADDR_LEN) != 0 && (ifp->if_flags & IFF_PPROMISC) == 0) { m_freem(m); return; } } since it doesn't consider VLAN tagged packets coming in the headers won't match this paradigm so the packets get through out. I did a quick hack and changed it to: if (!(BDG_ACTIVE(ifp))) { /* * Discard packet if upper layers shouldn't see it because it * was unicast to a different Ethernet address. If the driver * is working properly, then this situation can only happen * when the interface is in promiscuous mode. */ if ((ifp->if_flags & IFF_PROMISC) != 0 && (eh->ether_dhost[0] & 1) == 0 && bcmp(eh->ether_dhost, IFP2AC(ifp)->ac_enaddr, ETHER_ADDR_LEN) != 0 && (ifp->if_flags & IFF_PPROMISC) == 0) { /* * Let VLAN packets go to the SW VLAN node needed for * bridging */ if (! (vlan_input_p != NULL && ntohs(eh->ether_type) == ETHERTYPE_VLAN )) { m_freem(m); return; } } } That makes it work. I rather doubt this is the right solution. Suggestions greatly appreciated. This issue is in -current and -stable. Thanks, Doug A. From owner-freebsd-net@FreeBSD.ORG Thu Jul 3 15:01:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47AF337B401 for ; Thu, 3 Jul 2003 15:01:11 -0700 (PDT) Received: from www.ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61A5744033 for ; Thu, 3 Jul 2003 15:01:10 -0700 (PDT) (envelope-from ambrisko@www.ambrisko.com) Received: from www.ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.8p1/8.12.8) with ESMTP id h63M0YO7088407; Thu, 3 Jul 2003 15:00:34 -0700 (PDT) (envelope-from ambrisko@www.ambrisko.com) Received: (from ambrisko@localhost) by www.ambrisko.com (8.12.8p1/8.12.8/Submit) id h63M0YcL088406; Thu, 3 Jul 2003 15:00:34 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200307032200.h63M0YcL088406@www.ambrisko.com> In-Reply-To: To: Julian Elischer Date: Thu, 3 Jul 2003 15:00:34 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Suggesting for fixing VLAN bridging the right way X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 03 Jul 2003 22:01:11 -0000 Julian Elischer writes: | how does netgraph bridging do? I'm actually using netgraph bridging sort-of, kind-of. Since I don't care about loops and I'm only connecting to interfaces together I just doing ngctl connect vlan0: rl0: lower lower with the setpromisc, setautosrc etc. Luigi's bridging had the same issue. This is actually a simple test case. What I'm doing it actually more complicated for our product VLAN testing. With this hack now my test stuff works (I do a IP re-map to do a poor man's virtualization of the network stack ... which by the way I tried out the latest virtual network stuff. It sort-of worked but ran into some bugs and quirks). So this is a fundamental bug, in which the packets from the NIC don't make it to the vlan SW layer and things break. I guess I didn't explain that part well based on some other questions I got. You also have to set the NIC in promiscous mode as well. Seems like if you configure a VLAN and modes those things should get enabled on the base NIC. Granted it could get funky with HW VLAN support. It strange since I don't ifconfig the NIC but I always have to do an 'ifconfig up' to make the VLAN work at all. That's a little odd. Also you can see the bug via tcpdumps. You see the packets come in on the NIC but never make to the vlan iface. Doug A. | On Thu, 3 Jul 2003, Doug Ambrisko wrote: | | > I'm trying to bridge VLAN traffic to network that doesn't have that VLAN, | > something like: | > (vlan network) -> fxp0 -> vlan0 <- FreeBSD bridge -> rl0 (no tag) | > | > Both of the networks are the same except one side is tagged the other | > has no tag. | > | > It works fine in the "no tag" -> "tag" direction. It fails in the | > "tag" -> "no tag" direction since ether_demux we bail out on this | > check: | > if (!(BDG_ACTIVE(ifp))) { | > /* | > * Discard packet if upper layers shouldn't see it because it | > * was unicast to a different Ethernet address. If the driver | > * is working properly, then this situation can only happen | > * when the interface is in promiscuous mode. | > */ | > if ((ifp->if_flags & IFF_PROMISC) != 0 | > && (eh->ether_dhost[0] & 1) == 0 | > && bcmp(eh->ether_dhost, | > IFP2AC(ifp)->ac_enaddr, ETHER_ADDR_LEN) != 0 | > && (ifp->if_flags & IFF_PPROMISC) == 0) { | > m_freem(m); | > return; | > } | > } | > | > since it doesn't consider VLAN tagged packets coming in the headers | > won't match this paradigm so the packets get through out. I did a quick | > hack and changed it to: | > if (!(BDG_ACTIVE(ifp))) { | > /* | > * Discard packet if upper layers shouldn't see it because it | > * was unicast to a different Ethernet address. If the driver | > * is working properly, then this situation can only happen | > * when the interface is in promiscuous mode. | > */ | > if ((ifp->if_flags & IFF_PROMISC) != 0 | > && (eh->ether_dhost[0] & 1) == 0 | > && bcmp(eh->ether_dhost, | > IFP2AC(ifp)->ac_enaddr, ETHER_ADDR_LEN) != 0 | > && (ifp->if_flags & IFF_PPROMISC) == 0) { | > /* | > * Let VLAN packets go to the SW VLAN node needed for | > * bridging | > */ | > if (! (vlan_input_p != NULL | > && ntohs(eh->ether_type) == ETHERTYPE_VLAN )) { | > m_freem(m); | > return; | > } | > } | > } | > | > That makes it work. I rather doubt this is the right solution. | > | > Suggestions greatly appreciated. This issue is in -current and -stable. | > | > Thanks, | > | > Doug A. | > _______________________________________________ | > 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 Thu Jul 3 20:23:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7FEE37B401 for ; Thu, 3 Jul 2003 20:23:00 -0700 (PDT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AAB443FDD for ; Thu, 3 Jul 2003 20:22:59 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (s1f3tl7q@news1.macomnet.ru [195.128.64.14]) by relay.macomnet.ru (8.11.6/8.11.6) with ESMTP id h643Mn58977860; Fri, 4 Jul 2003 07:22:49 +0400 (MSD) Date: Fri, 4 Jul 2003 07:22:49 +0400 (MSD) From: Maxim Konovalov To: Doug Ambrisko In-Reply-To: <200307032011.h63KBUds082545@www.ambrisko.com> Message-ID: <20030704071300.L49237@news1.macomnet.ru> References: <200307032011.h63KBUds082545@www.ambrisko.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Suggesting for fixing VLAN bridging the right way X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 04 Jul 2003 03:23:01 -0000 Hi Doug, Your analysis is correct (kern/46961), I am slowly working on the fix but no ETA. It seems NetBSD recently has fixed a similar issue, haven't checked this fact yet, just saw a promising commit log in if_ethersubr.c. -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Sat Jul 5 12:33:37 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6649937B401 for ; Sat, 5 Jul 2003 12:33:37 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5B9343FE1 for ; Sat, 5 Jul 2003 12:33:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h65JXakN062810; Sat, 5 Jul 2003 12:33:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h65JXWoF062809; Sat, 5 Jul 2003 12:33:32 -0700 (PDT) (envelope-from rizzo) Date: Sat, 5 Jul 2003 12:33:32 -0700 From: Luigi Rizzo To: Eugene Grosbein Message-ID: <20030705123332.A60972@xorpc.icir.org> References: <20030703002247.A2097@grosbein.pp.ru> <3F0310CE.5070302@tenebras.com> <3F03867A.79F82968@kuzbass.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F03867A.79F82968@kuzbass.ru>; from eugen@kuzbass.ru on Thu, Jul 03, 2003 at 09:27:22AM +0800 cc: Eugene Grosbein cc: net@freebsd.org Subject: Re: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 05 Jul 2003 19:33:37 -0000 sorry for the late reply... [thread about prioritizing packet at the bottleneck interface] On Thu, Jul 03, 2003 at 09:27:22AM +0800, Eugene Grosbein wrote: ... > In addition to dummynet WFQ queue there is interface FIFO queue. unfortunately, there are actually two queues -- one is struct ifnet:struct ifqueue if_snd, which is always present; the other one is the 'transmit ring' (or various other names) which is sometimes just one or two slots, and sometimes a long list of buffers that the hardware drains as conditions permit. Certain hardware even has multiple, prioritized transmit rings, but there is no support for them in our drivers (basically we don't have an API for that). Typically (but this is device dependent) the output routines punch through if_snd and enqueue directly into the transmit ring, and when that fills up the driver switches mode of operation and queues into if_snd, until the hardware signals that the transmit ring has room available, drains if_snd and the driver returns to the previous mode. Now, the 'transmit ring not full' condition is very driver-dependent, some only assert it when the ring is completely empty, others when there is one slot available, others when there are some empty slot. Bottom line -- the whole architecture has been designed with FIFO in mind, and implementing any different queueing policy will involve some significant rewriting of the device drivers, plus, potentially, some significant performance loss. [BTW speaking of this, just have a look at how convoluted is the function red_drops() in dummynet, and that is for a "simple" marking algorithm. Prioritizing packets involves a lot more synchronization with the device because you might need to change the next packet to transmit even if there are some already queued]. cheers luigi > Always, even in the absence of dummynet :-) > It keeps packets that cannot be transmitted immediately > because device is busy. And FIFO, by definition, > will not allow prioritized packets to go out before others. > > Eugene > _______________________________________________ > 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 Sat Jul 5 19:36:59 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B41EE37B401 for ; Sat, 5 Jul 2003 19:36:59 -0700 (PDT) Received: from web13403.mail.yahoo.com (web13403.mail.yahoo.com [216.136.175.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C55243FE9 for ; Sat, 5 Jul 2003 19:36:59 -0700 (PDT) (envelope-from giffunip@yahoo.com) Message-ID: <20030706023659.43553.qmail@web13403.mail.yahoo.com> Received: from [200.91.194.207] by web13403.mail.yahoo.com via HTTP; Sun, 06 Jul 2003 03:36:59 BST Date: Sun, 6 Jul 2003 03:36:59 +0100 (BST) From: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" To: freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: res_nmkquery() and res_nsend() ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Jul 2003 02:37:00 -0000 Hi; I was checking the Debian GNU-BSD list and they reported this to the NetBSD people: http://lists.debian.org/debian-bsd/2003/debian-bsd-200307/msg00010.html For those too lazy: "The res_mkquery() and res_send() functions have been deprecated in favour of res_nmkquery() and res_nsend() for long time and are being removed from Glibc for newer ABI versions. This particularly includes x86_64-*, powerpc64-*, *-gnu and *-k*bsd-gnu, but more are to come. libhesiod uses these functions in ./hesiod.c and thus won't build for these systems." I think obsolete (used in the subject of the original email) is too harsh a word for res_mkquery and res_send, but the Solaris manpage I checked does include res_n* . Perhaps someone that knows well the particular RFCs may want to look at this. cheers, Pedro. ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ From owner-freebsd-net@FreeBSD.ORG Sat Jul 5 19:52:30 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7982337B401 for ; Sat, 5 Jul 2003 19:52:30 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4746643FBF for ; Sat, 5 Jul 2003 19:52:28 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])h662qMCo024333; Sun, 6 Jul 2003 10:52:23 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <3F078E39.ABC0822F@kuzbass.ru> Date: Sun, 06 Jul 2003 10:49:29 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Win98; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Luigi Rizzo References: <20030703002247.A2097@grosbein.pp.ru> <3F0310CE.5070302@tenebras.com> <3F03867A.79F82968@kuzbass.ru> <20030705123332.A60972@xorpc.icir.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: ipprecedence X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 Jul 2003 02:52:30 -0000 Luigi Rizzo wrote: > Bottom line -- the whole architecture has been designed with > FIFO in mind, and implementing any different queueing policy > will involve some significant rewriting of the device drivers, > plus, potentially, some significant performance loss. Thank you for detailed explanation. I hope that dummynet's WFQ would be sufficient but not sure: will it correctly process weights whith zero-bandwidth pipe? I mean one dummynet pipe (bw 0) and two dummynet queues for that pipe assigning weight 1 and weight 100. That's for each direction of traffic, of course. Eugene