From owner-freebsd-net Sun Feb 17 0:40:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id C9C4537B404 for ; Sun, 17 Feb 2002 00:40:07 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020217084007.VMGO1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sun, 17 Feb 2002 08:40:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA44886; Sun, 17 Feb 2002 00:26:52 -0800 (PST) Date: Sun, 17 Feb 2002 00:26:50 -0800 (PST) From: Julian Elischer To: Zviratko Cc: freebsd-net@freebsd.org Subject: Re: Ethernet bonding/load balancing on fbsd 4-stable In-Reply-To: <004101c1b766$cee780b0$0500a8c0@notes> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 17 Feb 2002, Zviratko wrote: > Hi, > is there a preferred way to do ethernet load balancing? My situation is - 2 > cable modems connected to two ethernet cards on with a machine functioning > as a NAT gateway for LAN. I tried netgraph (ng_ether with round robin and > ng_fec). With ng_ether, I achieved packets being sent via one interface and > received on another one(not what I want), ng_fec didn't work at all (it just > silently dropped all outgoing packets). ng_fec needs a cisco at the other end (or possibly another freebsd machine with ng_fec but I don't know that). > Is there another way? I already did this with linux (by using bond.c > similiar to ng_fec) and it worked under the same conditions. > Any advice would be appreciated. if your outgoing packets are going to different hosts (and not just one) you could try: ipfw add 1000 fwd {remote 1} ip from any to 0.0.1.0:0.0.1.0 out xmit fxp1 ipfw add 1001 fwd {remote 2} ip from any to 0.0.0.0:0.0.1.0 out xmit fxp1 where "remote 1" and "remote 2" are the gateways on each cable modem, (or some address that will make them go to different ports) and fxp1 is the interface tha the routing table would make them go out of normally. alternatively, the netgraph approach should work but I'm guessing that you've set up something wrong.. what is your configuration? > Zviratko > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 17 3:14:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp07.wxs.nl (smtp07.wxs.nl [195.121.6.39]) by hub.freebsd.org (Postfix) with ESMTP id 29EF337B404; Sun, 17 Feb 2002 03:14:51 -0800 (PST) Received: from there ([80.60.248.65]) by smtp07.wxs.nl (Netscape Messaging Server 4.15) with SMTP id GROCKO02.5ZD; Sun, 17 Feb 2002 12:14:48 +0100 Content-Type: text/plain; charset="iso-8859-1" From: "Peter J. Blok" To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: if_wb w89c840af winbond card Date: Sun, 17 Feb 2002 12:14:48 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020217111451.29EF337B404@hub.freebsd.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I wonder if there is somebody who has a working winbond ethernet card. My card has a W89C840 chip and an AC104 PHY. The driver doesn't find the AC104 and as a result the kernel panics. The fix to avoid the panic is very easy, but i started to wonder if it is the AC104 that is causing this or that the driver is disfunctional for all PHYs. I am trying to determine why the PHY is not detected, but it helps to know if the code is completely broken or not. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 17 3:41:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawkins.dropbear.id.au (cu713.adelaide.adsl.on.net [150.101.236.205]) by hub.freebsd.org (Postfix) with ESMTP id 377B737B402 for ; Sun, 17 Feb 2002 03:41:23 -0800 (PST) Received: from localhost (jhawkins@localhost) by tardis.everard.bogus (8.11.6/8.11.6) with ESMTP id g1GNZJA11358 for ; Sun, 17 Feb 2002 10:05:19 +1030 (CST) (envelope-from justin@hawkins.dropbear.id.au) X-Authentication-Warning: tardis.everard.bogus: jhawkins owned process doing -bs Date: Sun, 17 Feb 2002 10:05:19 +1030 (CST) From: Justin Hawkins X-X-Sender: jhawkins@tardis.everard.bogus To: freebsd-net@freebsd.org Subject: mpd-netgraph as VPN client to Cisco 2500 Message-ID: <20020217094933.D9233-100000@tardis.everard.bogus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi folks, I'm trying to setup a VPN connection to my work's staff network. I think I'm running into the problem described here: http://www.geocrawler.com/mail/msg.php3?msg_id=7311422&list=165 IE: The physical IP address of the cisco device is the same as the tunnel endpoint address, and packets get encapsulated recursively. Here's what my routing table and interface look like after I bring the link up: Routing tables: Internet: Destination Gateway Flags Refs Use Netif Expire default xxx.xxx.xxx.xxx UGSc 27 1545 ed1 127.0.0.1 127.0.0.1 UH 13 7493 lo0 [snip] yyy.yyy.yyy.30 yyy.yyy.yyy.228 UH 2 11 ng0 ifconfig: ng0: flags=88d1 mtu 1500 inet6 fe80::500:dead:beef:1234%ng0 prefixlen 64 scopeid 0x9 inet yyy.yyy.yyy.228 --> yyy.yyy.yyy.30 netmask 0xffffffff Where yyy.yyy.yyy is my staff network class C, .30 is the VPN server (Cisco 2511), .228 is the negotiated client address for my FreeBSD box. When I try to ping I get: tardis:~ > ping yyy.yyy.yyy.30 PING yyy.yyy.yyy.30 (yyy.yyy.yyy.30): 56 data bytes ping: sendto: Resource deadlock avoided ping: sendto: Resource deadlock avoided ping: sendto: No buffer space available ping: sendto: No buffer space available During the opening of the connection with mpd-netgraph, I see this: [vpn] IPCP: rec'd Configure Request #50 link 0 (Req-Sent) IPADDR yyy.yyy.yyy.30 Same as PPTP IP; would cause routing loop NAKing with yyy.yyy.yyy.30 which is referenced in the geocrawler link above. Is the tunnel endpoint having the same IP as the physical interface completely unsupported? Could I possibly solve this by use of an ethernet alias on the 2511? Can provide more of the debug output from mpd while bringing up the link if necessary. Thanks! - Justin -- justin@hawkins.dropbear.id.au | "Don't sweat it -- http://hawkins.dropbear.id.au | it's only 1's and 0's" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 17 3:45: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from email.seznam.cz (smtp.seznam.cz [195.119.180.43]) by hub.freebsd.org (Postfix) with SMTP id 9010B37B404 for ; Sun, 17 Feb 2002 03:44:56 -0800 (PST) Received: (qmail 91692 invoked from network); 17 Feb 2002 11:44:54 -0000 Received: from linux.sux.cz (HELO notes) (62.24.72.206) by smtp.seznam.cz with SMTP; 17 Feb 2002 11:44:54 -0000 Message-ID: <003501c1b7a8$4431d5f0$0500a8c0@notes> From: "Zviratko" To: References: Subject: Re: Ethernet bonding/load balancing on fbsd 4-stable Date: Sun, 17 Feb 2002 12:43:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > Hi, > > is there a preferred way to do ethernet load balancing? My situation is - 2 > > cable modems connected to two ethernet cards on with a machine functioning > > as a NAT gateway for LAN. I tried netgraph (ng_ether with round robin and > > ng_fec). With ng_ether, I achieved packets being sent via one interface and > > received on another one(not what I want), ng_fec didn't work at all (it just > > silently dropped all outgoing packets). > > ng_fec needs a cisco at the other end (or possibly another freebsd > machine with ng_fec but I don't know that). > yes, bond.c does as well, but it worked in my situation because of the structure of the network I am on (basically, the nearest other host that understands IP is Cisco 6K (i think). It worked exactly in the way it should with ng_fec - 2 interfaces with the same MAC and IP and round robin routing policy. But when I look at netstat -in, I see no packets being sent out via fec0 (and thus they are dropped somewhere :-( ) > > Is there another way? I already did this with linux (by using bond.c > > similiar to ng_fec) and it worked under the same conditions. > > Any advice would be appreciated. > > if your outgoing packets are going to different hosts (and not just one) > you could try: > > ipfw add 1000 fwd {remote 1} ip from any to 0.0.1.0:0.0.1.0 out xmit fxp1 > ipfw add 1001 fwd {remote 2} ip from any to 0.0.0.0:0.0.1.0 out xmit fxp1 > > where "remote 1" and "remote 2" are the gateways on each cable modem, > (or some address that will make them go to different ports) > and fxp1 is the interface tha the routing table would make them go out of > normally. I will try that, but I guess default route has precedence over ipfw. > > alternatively, the netgraph approach should work but I'm guessing > that you've set up something wrong.. > what is your configuration? > > basically, I was trying the sample from man 4 ng_ether as following: ed1: ne2k card connected to cable modem ed2: ne2k card (another clone) connected to cable modem ngctl mkpeer ed2: one2many upper one ngctl connect ed2: ed2:upper lower many0 ngctl connect ed1: ed2:upper lower many1 ngctl msg ed1: setpromisc 1 ngctl msg ed1: setautosrc 0 # Configure all four links as up ngctl msg ed2:upper \ setconfig "{ xmitAlg=1 failAlg=1 enabledLinks=[ 1 1 1 1 ] }" # Bring up interface ifconfig ed2 inet my.ip.goes.here netmask 255.255.255.0 then, I set a route to my default gw, but all packets are then routed via one interface out and one in, but I want them flowing one-by-one via both as I used to do with bond.c. The one solution would be to route packets non-interface-specificaly, that means by random or round robin, but it seems like the "route" command doesn't support specifying interface at all! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 17 11:55:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 1188737B400 for ; Sun, 17 Feb 2002 11:55:35 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1HJtXN14453; Sun, 17 Feb 2002 11:55:33 -0800 (PST) (envelope-from rizzo) Date: Sun, 17 Feb 2002 11:55:33 -0800 From: Luigi Rizzo To: "Aaron D. Gifford" Cc: freebsd-net@FreeBSD.ORG Subject: Re: Bug in stateful code? Message-ID: <20020217115533.A14365@iguana.icir.org> References: <20020215225647.DBAB521CE8@ns1.infowest.com> <3C6DA100.3080108@tenebras.com> <20020216014335.AE41B213CA@ns1.infowest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020216014335.AE41B213CA@ns1.infowest.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I do not think your proposal is correct (the context is in your other posting). The firewall provides the basic mechanism, much like a CPU provides machine instructions. Your ruleset (your program) makes use of that. If you write the wrong program it's your business, not the cpu's business. The latter may trap in some cases (_invalid_ operands, e.g. division by 0), but not all of them (e.g. divide by 10 when you really wanted to divide by 0x10), and given that TCP packets may get lost or go through some other path, flagging these events is not ipfw business. cheers luigi On Fri, Feb 15, 2002 at 06:43:35PM -0700, Aaron D. Gifford wrote: > Heh, I MEANT to say: > > default: > if (q->state == (TH_SYN | TH_ACK)) { > /* > * Both forward SYN and ACK packets have been seen, without > * a reverse SYN+ACK packet in between, likely due to either > * a buggy rule set, or bogus traffic. > */ > if (fw_verbose) { > log(LOG_SECURITY | LOG_NOTICE, > "ipfw: Invalid stateful TCP rule (from %d): Middle " > "packet missing from three-way TCP handshake.", > q->rule->fw_number); > return NULL; /* Drop it as if not matched */ > } > } > > There. I don't know why I was calling the third packet a SYN+ACK in the > comments. The original also was missing some parenthesis, and used an > incorrect field name (q->parent->fw_number instead of q-.rule->fw_number). > > Sorry. Comes from leaping before looking, I supppose. > > Aaron out. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 17 13:12:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 3D48737B436 for ; Sun, 17 Feb 2002 13:12:11 -0800 (PST) Received: from keg (c1-vpn3.isi.edu [128.9.176.29]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g1HLC9Q14647; Sun, 17 Feb 2002 13:12:10 -0800 (PST) From: "Lars Eggert" To: "'Justin Hawkins'" , Subject: RE: mpd-netgraph as VPN client to Cisco 2500 Date: Sun, 17 Feb 2002 13:12:09 -0800 Organization: USC Information Sciences Institute MIME-Version: 1.0 Message-ID: <000d01c1b7f7$c3383390$b27ba8c0@keg> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01C1B7B4.B4B631C0" Importance: Normal In-Reply-To: <20020217094933.D9233-100000@tardis.everard.bogus> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C1B7B4.B4B631C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, this doesn't look like the same bug described in the link you posted. The other bug caused negotiation to completely fail, while it succeeds in your case. Looks like there's something else wring. What does your ifconfig look like after the link is up? Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG] On Behalf Of Justin Hawkins > Sent: Saturday, February 16, 2002 3:35 PM > To: freebsd-net@freebsd.org > Subject: mpd-netgraph as VPN client to Cisco 2500 > > > > Hi folks, > > I'm trying to setup a VPN connection to my work's staff > network. I think I'm running into the problem described here: > > http://www.geocrawler.com/mail/msg.php3?msg_id=7311422&list=165 > > IE: The physical IP address of the cisco device is the same > as the tunnel endpoint address, and packets get encapsulated > recursively. > > Here's what my routing table and interface look like after I > bring the link up: > > Routing tables: > > Internet: > Destination Gateway Flags Refs Use > Netif Expire > default xxx.xxx.xxx.xxx UGSc 27 1545 ed1 > 127.0.0.1 127.0.0.1 UH 13 7493 lo0 > [snip] > yyy.yyy.yyy.30 yyy.yyy.yyy.228 UH 2 11 ng0 > > ifconfig: > > ng0: > flags=88d1 mtu 1500 > inet6 fe80::500:dead:beef:1234%ng0 prefixlen 64 scopeid 0x9 > inet yyy.yyy.yyy.228 --> yyy.yyy.yyy.30 netmask 0xffffffff > > Where yyy.yyy.yyy is my staff network class C, .30 is the VPN > server (Cisco 2511), .228 is the negotiated client address > for my FreeBSD box. > > When I try to ping I get: > > tardis:~ > ping yyy.yyy.yyy.30 > PING yyy.yyy.yyy.30 (yyy.yyy.yyy.30): 56 data bytes > ping: sendto: Resource deadlock avoided > ping: sendto: Resource deadlock avoided > ping: sendto: No buffer space available > ping: sendto: No buffer space available > > During the opening of the connection with mpd-netgraph, I see this: > > [vpn] IPCP: rec'd Configure Request #50 link 0 (Req-Sent) > IPADDR yyy.yyy.yyy.30 > Same as PPTP IP; would cause routing loop > NAKing with yyy.yyy.yyy.30 > > which is referenced in the geocrawler link above. > > Is the tunnel endpoint having the same IP as the physical > interface completely unsupported? > > Could I possibly solve this by use of an ethernet alias on the 2511? > > Can provide more of the debug output from mpd while bringing > up the link if necessary. > > Thanks! > > - Justin > > -- > justin@hawkins.dropbear.id.au | "Don't sweat it -- > http://hawkins.dropbear.id.au | it's only 1's and 0's" > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > ------=_NextPart_000_0008_01C1B7B4.B4B631C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFzCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcN MjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1 KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZ FKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVc CM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx +NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIDWjCCA1YCAQEwgZow gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93 bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggIVMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDIxNzIxMTIwOVowIwYJ KoZIhvcNAQkEMRYEFLfCjkWaUZyin9XMwwkm0FzyrFhgMFgGCSqGSIb3DQEJDzFLMEkwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoG CCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQL ExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDBYFHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAb BgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBS U0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEBBQAEgYBIYbM9sB5WgXXdsXj52wJfDmMmlniO VkuOLZyr9oUA6GfuroEt1wXr1v7bcQvhTuHt8bFVBdfo5bS7ZJZB09DeeNykUP7DJuoxnp2e72vb rT0ISN8pm218DIZz7bFdQEiSMEOmWLGjKh/OnVuD6MuwO/xuiEomfLNJ0gTs5sY9vQAAAAAAAA== ------=_NextPart_000_0008_01C1B7B4.B4B631C0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 17 13:24:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from email.seznam.cz (smtp.seznam.cz [195.119.180.43]) by hub.freebsd.org (Postfix) with SMTP id 009A137B402 for ; Sun, 17 Feb 2002 13:24:23 -0800 (PST) Received: (qmail 16545 invoked from network); 17 Feb 2002 21:24:20 -0000 Received: from travicka.zelena.sk (HELO notes) (62.24.72.111) by smtp.seznam.cz with SMTP; 17 Feb 2002 21:24:20 -0000 Message-ID: <006901c1b7f9$75b991c0$0500a8c0@notes> From: "Zviratko" To: References: <003501c1b7a8$4431d5f0$0500a8c0@notes> <20020217205620.GN413@overlord.e-gerbil.net> Subject: Re: Ethernet bonding/load balancing on fbsd 4-stable Date: Sun, 17 Feb 2002 22:24:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I just got it to work by using ng_one2many: ifconfig ed1 up lladdr 00:88:e8:83:63:c0 ifconfig ed2 up lladdr 00:88:e8:83:63:c0 kldload /modules/ng_ether.ko ngctl mkpeer ed1: one2many upper one ngctl connect ed1: ed1:upper lower many0 ngctl connect ed2: ed1:upper lower many1 ngctl msg ed2: setpromisc 1 ngctl msg ed1: setpromisc 1 ngctl msg ed2: setautosrc 0 ngctl msg ed1:upper \ setconfig "{ xmitAlg=1 failAlg=1 enabledLinks=[ 1 1 1 1 ] }" ifconfig ed1 my.ip.is.here netmask 255.255.255.0 the only prerequirement is to have both interfaces UP and WITHTOUT IP! (otherwise it works only for local LAN, but you will have problem if trying to route traffic to a gateway - my situation). Other problem is, that if you have the same net on both interfaces in the beginning ( I have 62.24.72.0/24 on both) and you need to route via 62.24.72.1 as gateway, the only way is to set this script to use the FIRST initialized interface, otherwise you cannot(I can't) set gateway only for the second interface... Ufff... ;-) The result is a fine-working-non-laggy-double-speed-line :) beware: if you use cable modem, you need to have the same speed subscribed for both of them, otherwise, you will receive a whole bunch of DUP!s :) and both modems need to be on the same bridge. Thx all for help Zviratko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 2: 3:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 5B35237B402 for ; Mon, 18 Feb 2002 02:03:34 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id F06B4E5008; Sun, 17 Feb 2002 15:56:20 -0500 (EST) Date: Sun, 17 Feb 2002 15:56:20 -0500 From: Richard A Steenbergen To: Zviratko Cc: freebsd-net@freebsd.org Subject: Re: Ethernet bonding/load balancing on fbsd 4-stable Message-ID: <20020217205620.GN413@overlord.e-gerbil.net> References: <003501c1b7a8$4431d5f0$0500a8c0@notes> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003501c1b7a8$4431d5f0$0500a8c0@notes> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > ng_fec needs a cisco at the other end (or possibly another freebsd > > machine with ng_fec but I don't know that). Fast EtherChannel doesn't actually require a Cisco device on the other side, it is really just a "non-standardized standard" for the hashing that decides which physical interface the frame will go over. The other side may have a different decision making method resulting in different paths for bidirectional traffic, but that won't prevent it from working. The only real "cisco only" protocol is the PAgP (Port Aggregation Protocol) which is essentially just a FEC auto-negiotation protocol they made up. AFAIK noone other then Cisco actually implements this though. Of course now it is standardized under 802.3ad, which makes this whole discussion pointless. The netgraph module should probably be updated to reflect the new standard, but the existing stuff should still work. > yes, bond.c does as well, but it worked in my situation because of the > structure of the network I am on (basically, the nearest other host that > understands IP is Cisco 6K (i think). It worked exactly in the way it > should with ng_fec - 2 interfaces with the same MAC and IP and round > robin routing policy. But when I look at netstat -in, I see no packets > being sent out via fec0 (and thus they are dropped somewhere :-( ) It don't have to understand IP, and infact it don't have to understand any "link aggregation" method at all, in order to *receive* aggregated frames. If your server is transmitting 150Mbps but only receiving 20Mbps, you could linkagg 2 FastE links to a dumb NetGear switch and probably get away with it. All the inbound stuff would be transmitted over one link because the dumb switch didn't know how to do linkagg, but in that case it wouldn't really matter. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 9:16: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from mdv.dhs.org (mdv.xs4all.nl [213.84.209.48]) by hub.freebsd.org (Postfix) with ESMTP id DBF6E37B400 for ; Mon, 18 Feb 2002 09:15:49 -0800 (PST) Received: (from root@localhost) by mdv.dhs.org (8.11.6/8.11.6) id g1IHFl912359 for freebsd-net@freebsd.org; Mon, 18 Feb 2002 18:15:47 +0100 (CET) (envelope-from mdevries@mdv.dhs.org) Received: from marcel.mdv.dhs.org (marcel.mdv.int [192.168.1.3]) by mdv.dhs.org (8.11.6/8.11.6av) with ESMTP id g1IHFjn12352 for ; Mon, 18 Feb 2002 18:15:45 +0100 (CET) (envelope-from mdevries@mdv.dhs.org) Message-Id: <5.1.0.14.2.20020218164647.01edeaf8@outshine> X-Sender: mdevries@outshine X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Feb 2002 18:15:39 +0100 To: freebsd-net@freebsd.org From: Marcel de Vries Subject: network buffer problem Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, I'm getting alot of buffer problems with my internet connection. I'm using a (Dutch) Mxstream ADSL for Broadband internet connection. The ISDN Alcatel ADSL modem is loaded with firmware: Active : GSV7AA3.270 As you can see below I'm using mpd-netgraph for PPTP to connect on the ADSL modem (interface ng0) root@Dominator# mpd -v Version 3.7 (root@mdv.dhs.org 20:17 16-Feb-2002) interface ep0 is connected to the ADSL modem. A friend of mine with almost an indentical system also using mxstream ADSL had the same problem. But changing the MTU on ng0 to 1492 (IEEE 802.3/802.2 standard) solved his buffer problem. In my case it didn't solve... Setting NMBClusters in the kernelconf doesn't help at all. Tracked the BSD hackers archive, there are some known bugs regarding the ep driver and 'No buffer space available' Still fresh yet unsolved bugs? correct? My Error output : root@Dominator# ping -R -s 6144 www.bart.nl PING viaweb.vianetworks.nl (212.61.15.21): 6144 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available 6152 bytes from 212.61.15.21: icmp_seq=2 ttl=58 time=303.227 ms RR: mxstream.pbw.xs4all.net (194.109.5.66) 0.ge-0-3-0.xr1.pbw.xs4all.net (194.109.5.13) ams-ix.xs4all.net (193.148.15.48) amsterdam4.bart.net (194.158.190.72) router8.iae.nl (212.61.25.174) router22.iae.nl (212.61.15.1) morgoth.vianetworks.nl (212.61.15.21) router22.iae.nl (212.61.25.187) ams-ix.iae.net (193.148.15.82) 6152 bytes from 212.61.15.21: icmp_seq=3 ttl=58 time=302.734 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=4 ttl=58 time=304.016 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=5 ttl=58 time=303.142 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=6 ttl=58 time=303.004 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=7 ttl=58 time=302.006 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=8 ttl=58 time=302.970 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=9 ttl=58 time=302.672 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=10 ttl=58 time=302.604 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=11 ttl=58 time=312.702 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=12 ttl=58 time=303.242 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=14 ttl=58 time=302.006 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=15 ttl=58 time=302.340 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=16 ttl=58 time=302.982 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=17 ttl=58 time=301.376 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=18 ttl=58 time=322.473 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=19 ttl=58 time=304.341 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=20 ttl=58 time=301.912 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=21 ttl=58 time=445.256 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=22 ttl=58 time=302.685 ms (same route) ping: sendto: No buffer space available ping: sendto: No buffer space available 6152 bytes from 212.61.15.21: icmp_seq=25 ttl=58 time=302.050 ms (same route) ping: sendto: No buffer space available 6152 bytes from 212.61.15.21: icmp_seq=27 ttl=58 time=302.753 ms (same route) ping: sendto: No buffer space available ping: sendto: No buffer space available 6152 bytes from 212.61.15.21: icmp_seq=30 ttl=58 time=301.620 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=31 ttl=58 time=304.179 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=32 ttl=58 time=301.974 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=33 ttl=58 time=303.227 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=34 ttl=58 time=302.581 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=35 ttl=58 time=303.215 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=36 ttl=58 time=301.326 ms (same route) 6152 bytes from 212.61.15.21: icmp_seq=37 ttl=58 time=301.750 ms (same route) ^C --- viaweb.vianetworks.nl ping statistics --- 38 packets transmitted, 30 packets received, 21% packet loss round-trip min/avg/max/stddev = 301.326/308.412/445.256/25.723 ms Subject: No buffer space available System: FreeBSD ####### 4.5-STABLE FreeBSD 4.5-STABLE #3: Sat Feb 16 00:09:41 CET 2002 root@:/usr/src/sys/compile/DOMINATOR i386 Network: root@Dominator# ifconfig rl0: flags=8843 mtu 1500 inet 192.168.1.1 netmask 0xfffffff0 broadcast 192.168.1.15 atalk 65280.131 range 65280-65534 phase 2 broadcast 0.255 ether 00:40:95:2d:01:c8 media: Ethernet autoselect (100baseTX) status: active lp0: flags=8810 mtu 1500 ep0: flags=8843 mtu 1500 inet 10.0.0.150 netmask 0xffffff00 broadcast 10.0.0.255 ether 00:60:08:7e:77:74 media: Ethernet 10baseT/UTP lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 atalk 0.0 range 0-0 phase 2 ppp0: flags=8010 mtu 1500 gif0: flags=8051 mtu 1280 tunnel inet #.#.#.# --> #.#.#.# inet 192.168.1.1 --> 192.168.2.100 netmask 0xffffff00 ng0: flags=88d1 mtu 1492 inet #.#.#.# --> 195.190.240.105 netmask 0xffffffff 3/368/16768 mbufs in use (current/peak/max): 3 mbufs allocated to data 0/32/4192 mbuf clusters in use (current/peak/max) 156 Kbytes allocated to network (1% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Is there Thanks in advance! Grtz, Marcel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 11:42:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from mdv.dhs.org (mdv.xs4all.nl [213.84.209.48]) by hub.freebsd.org (Postfix) with ESMTP id CD74F37B402 for ; Mon, 18 Feb 2002 11:42:11 -0800 (PST) Received: (from root@localhost) by mdv.dhs.org (8.11.6/8.11.6) id g1IJgAT00307; Mon, 18 Feb 2002 20:42:10 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Received: from marcel.haveityourway.nl (marcel.mdv.int [192.168.1.3]) by mdv.dhs.org (8.11.6/8.11.6av) with ESMTP id g1IJg8h00300; Mon, 18 Feb 2002 20:42:08 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Message-Id: <5.1.0.14.2.20020218201731.01e36c40@outshine> X-Sender: mdevries@outshine X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Feb 2002 20:42:02 +0100 To: freebsd-net@freebsd.org From: Marcel de Vries Subject: Re: network buffer problem Cc: "Zviratko" In-Reply-To: <00b401c1b8a1$d0b76590$0500a8c0@notes> References: <5.1.0.14.2.20020218164647.01edeaf8@outshine> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Thanks for your reply. added sysctl, Set the default value's of 4.3 in the kernel. net.inet.tcp.sendspace=16384 net.inet.tcp.recvspace=16384 But still no buffer space messages when pinging a host. Can I try something else? also tried to lower udp.recvspace, but did not help :( But I never had this problem before in other releases, but they changed the IP stack in 4.5 right? grtz, Marcel At 18:29 18-02-2002 +0100, you wrote: >try lowering net.inet.tcp.sendspace and net.inet.tcp.recvspace(kernel, not >interface values), this happened to me when I was experimenting with >considerably high buffer values (such as 128k). And I've also encountered it >yesterday when trying to bond two interfaces and got routing all fscked up >:). So take a look at routing tables, maybe you bounce things trough some >interface twice or something.. >Maybe somebody with ADSL will help better. >Best regards >Zviratko > > >----- Original Message ----- >From: "Marcel de Vries" >To: >Sent: Monday, February 18, 2002 6:15 PM >Subject: network buffer problem > > > > Hi all, > > > > I'm getting alot of buffer problems with my internet connection. > > > > I'm using a (Dutch) Mxstream ADSL for Broadband internet connection. > > The ISDN Alcatel ADSL modem is loaded with firmware: Active : GSV7AA3.270 > > > > As you can see below I'm using mpd-netgraph for PPTP to connect on the >ADSL > > modem (interface ng0) > > root@Dominator# mpd -v > > Version 3.7 (root@mdv.dhs.org 20:17 16-Feb-2002) > > interface ep0 is connected to the ADSL modem. > > > > A friend of mine with almost an indentical system also using mxstream ADSL > > had the same problem. > > But changing the MTU on ng0 to 1492 (IEEE 802.3/802.2 standard) solved his > > buffer problem. > > In my case it didn't solve... > > > > Setting NMBClusters in the kernelconf doesn't help at all. > > Tracked the BSD hackers archive, there are some known bugs regarding the >ep > > driver and 'No buffer space available' > > Still fresh yet unsolved bugs? correct? > > > > > > My Error output > > : > > root@Dominator# ping -R -s 6144 www.bart.nl > > PING viaweb.vianetworks.nl (212.61.15.21): 6144 data bytes > > ping: sendto: No buffer space available > > ping: sendto: No buffer space available > > 6152 bytes from 212.61.15.21: icmp_seq=2 ttl=58 time=303.227 ms > > RR: mxstream.pbw.xs4all.net (194.109.5.66) > > 0.ge-0-3-0.xr1.pbw.xs4all.net (194.109.5.13) > > ams-ix.xs4all.net (193.148.15.48) > > amsterdam4.bart.net (194.158.190.72) > > router8.iae.nl (212.61.25.174) > > router22.iae.nl (212.61.15.1) > > morgoth.vianetworks.nl (212.61.15.21) > > router22.iae.nl (212.61.25.187) > > ams-ix.iae.net (193.148.15.82) > > 6152 bytes from 212.61.15.21: icmp_seq=3 ttl=58 time=302.734 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=4 ttl=58 time=304.016 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=5 ttl=58 time=303.142 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=6 ttl=58 time=303.004 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=7 ttl=58 time=302.006 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=8 ttl=58 time=302.970 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=9 ttl=58 time=302.672 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=10 ttl=58 time=302.604 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=11 ttl=58 time=312.702 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=12 ttl=58 time=303.242 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=14 ttl=58 time=302.006 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=15 ttl=58 time=302.340 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=16 ttl=58 time=302.982 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=17 ttl=58 time=301.376 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=18 ttl=58 time=322.473 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=19 ttl=58 time=304.341 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=20 ttl=58 time=301.912 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=21 ttl=58 time=445.256 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=22 ttl=58 time=302.685 ms (same >route) > > ping: sendto: No buffer space available > > ping: sendto: No buffer space available > > 6152 bytes from 212.61.15.21: icmp_seq=25 ttl=58 time=302.050 ms (same >route) > > ping: sendto: No buffer space available > > 6152 bytes from 212.61.15.21: icmp_seq=27 ttl=58 time=302.753 ms (same >route) > > ping: sendto: No buffer space available > > ping: sendto: No buffer space available > > 6152 bytes from 212.61.15.21: icmp_seq=30 ttl=58 time=301.620 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=31 ttl=58 time=304.179 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=32 ttl=58 time=301.974 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=33 ttl=58 time=303.227 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=34 ttl=58 time=302.581 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=35 ttl=58 time=303.215 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=36 ttl=58 time=301.326 ms (same >route) > > 6152 bytes from 212.61.15.21: icmp_seq=37 ttl=58 time=301.750 ms (same >route) > > ^C > > --- viaweb.vianetworks.nl ping statistics --- > > 38 packets transmitted, 30 packets received, 21% packet loss > > round-trip min/avg/max/stddev = 301.326/308.412/445.256/25.723 ms > > > > > > Subject: No buffer space available > > > > System: > > FreeBSD ####### 4.5-STABLE FreeBSD 4.5-STABLE #3: Sat Feb 16 00:09:41 CET > > 2002 root@:/usr/src/sys/compile/DOMINATOR i386 > > > > Network: > > root@Dominator# ifconfig > > rl0: flags=8843 mtu 1500 > > inet 192.168.1.1 netmask 0xfffffff0 broadcast 192.168.1.15 > > atalk 65280.131 range 65280-65534 phase 2 broadcast 0.255 > > ether 00:40:95:2d:01:c8 > > media: Ethernet autoselect (100baseTX) > > status: active > > lp0: flags=8810 mtu 1500 > > ep0: flags=8843 mtu 1500 > > inet 10.0.0.150 netmask 0xffffff00 broadcast 10.0.0.255 > > ether 00:60:08:7e:77:74 > > media: Ethernet 10baseT/UTP > > lo0: flags=8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 > > atalk 0.0 range 0-0 phase 2 > > ppp0: flags=8010 mtu 1500 > > gif0: flags=8051 mtu 1280 > > tunnel inet #.#.#.# --> #.#.#.# > > inet 192.168.1.1 --> 192.168.2.100 netmask 0xffffff00 > > ng0: flags=88d1 mtu 1492 > > inet #.#.#.# --> 195.190.240.105 netmask 0xffffffff > > > > 3/368/16768 mbufs in use (current/peak/max): > > 3 mbufs allocated to data > > 0/32/4192 mbuf clusters in use (current/peak/max) > > 156 Kbytes allocated to network (1% of mb_map in use) > > 0 requests for memory denied > > 0 requests for memory delayed > > 0 calls to protocol drain routines > > > > Is there > > Thanks in advance! > > Grtz, > > Marcel > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 11:50:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d85.as6.nwbl0.wi.voyager.net [169.207.128.85]) by hub.freebsd.org (Postfix) with ESMTP id 45D8137B404; Mon, 18 Feb 2002 11:50:28 -0800 (PST) Received: from localhost (silby@localhost) by patrocles.silby.com (8.11.6/8.11.6) with ESMTP id g1IDsQZ49834; Mon, 18 Feb 2002 13:54:27 GMT (envelope-from silby@silby.com) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 18 Feb 2002 13:54:26 +0000 (GMT) From: Mike Silbersack To: Marcel de Vries Cc: freebsd-net@freebsd.org, Subject: Re: network buffer problem In-Reply-To: <5.1.0.14.2.20020218164647.01edeaf8@outshine> Message-ID: <20020218135104.C48587-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 18 Feb 2002, Marcel de Vries wrote: > Hi all, > > I'm getting alot of buffer problems with my internet connection. > > I'm using a (Dutch) Mxstream ADSL for Broadband internet connection. > The ISDN Alcatel ADSL modem is loaded with firmware: Active : GSV7AA3.270 > > Setting NMBClusters in the kernelconf doesn't help at all. > Tracked the BSD hackers archive, there are some known bugs regarding the ep > driver and 'No buffer space available' > Still fresh yet unsolved bugs? correct? There is a fix for the "No buffer space available" problems due to the ep driver. It has been commmitted to -current, but not -stable as of yet. I suspect Warner will MFC the change in a few days. In the meantime, you could try manually applying this diff to your system: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ep/if_ep.c.diff?r1=1.107&r2=1.108 Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 12:31:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1013337B400 for ; Mon, 18 Feb 2002 12:31:48 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g1IKVji83806; Mon, 18 Feb 2002 13:31:46 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1IKVfL66664; Mon, 18 Feb 2002 13:31:45 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 18 Feb 2002 12:31:33 -0800 (PST) Message-Id: <20020218.123133.62268757.imp@village.org> To: silby@silby.com Cc: mdevries@mdv.dhs.org, freebsd-net@freebsd.org Subject: Re: network buffer problem From: "M. Warner Losh" In-Reply-To: <20020218135104.C48587-100000@patrocles.silby.com> References: <5.1.0.14.2.20020218164647.01edeaf8@outshine> <20020218135104.C48587-100000@patrocles.silby.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yes. I was going to commit this fix to -stable at bsdcon, but the number of problem laptops that I wanted to look at closely didn't allow it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 13:17:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by hub.freebsd.org (Postfix) with ESMTP id 0C29837B402 for ; Mon, 18 Feb 2002 13:16:46 -0800 (PST) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g1ILGij59734 for freebsd-net@freebsd.org; Mon, 18 Feb 2002 13:16:44 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200202182116.g1ILGij59734@ambrisko.com> Subject: Adding support for Netgear GA621 (TBI interface) To: freebsd-net@freebsd.org Date: Mon, 18 Feb 2002 13:16:44 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've been working on adding support for Netgears GA621 Gigabit Fiber card. I basically have it working. I'm still trying to refine the link detection code. I have been able to connect it to some other fiber card via a cross-over cable and send packets back and forth. I have some more testing to do when I get a fiber switch that works (first one didn't work and I'm waiting on a replacement). Here are patches based on -stable. I'd appreciate someone reviewing the changes and let me know if I'm going about it in the wrong direction or if it just needs minor changes. It's definitely a work in progress at the moment but appears to be functioning fairly well. Some of the ifmedia stuff I just stumbled through by looking at other drivers. I will need someone to verify I didn't break the copper verison since I only have a TBI (fiber) version. Thanks, Doug A. Index: if_ngereg.h =================================================================== RCS file: /cvs/src/sys/dev/nge/if_ngereg.h,v retrieving revision 1.4.2.2 diff -c -r1.4.2.2 if_ngereg.h *** if_ngereg.h 19 Sep 2001 23:14:28 -0000 1.4.2.2 --- if_ngereg.h 18 Feb 2002 21:12:15 -0000 *************** *** 128,133 **** --- 128,134 ---- #define NGE_CFG_PHYINTR_LNK 0x00080000 #define NGE_CFG_PHYINTR_DUP 0x00100000 #define NGE_CFG_MODE_1000 0x00400000 + #define NGE_CFG_TBI_EN 0x01000000 #define NGE_CFG_DUPLEX_STS 0x10000000 #define NGE_CFG_SPEED_STS 0x60000000 #define NGE_CFG_LINK_STS 0x80000000 *************** *** 420,426 **** /* TBI BMCR */ #define NGE_TBIBMCR_RESTART_ANEG 0x00000200 #define NGE_TBIBMCR_ENABLE_ANEG 0x00001000 ! #define NGE_TBIBMCR_LOOPBACK 0x00004000 /* TBI BMSR */ #define NGE_TBIBMSR_ANEG_DONE 0x00000004 --- 421,427 ---- /* TBI BMCR */ #define NGE_TBIBMCR_RESTART_ANEG 0x00000200 #define NGE_TBIBMCR_ENABLE_ANEG 0x00001000 ! #define NGE_TBIBMCR_LOOPBACK 0x00004000 /* TBI BMSR */ #define NGE_TBIBMSR_ANEG_DONE 0x00000004 *************** *** 429,434 **** --- 430,437 ---- /* TBI ANAR */ #define NGE_TBIANAR_HDX 0x00000020 #define NGE_TBIANAR_FDX 0x00000040 + #define NGE_TBIANAR_PS1 0x00000080 + #define NGE_TBIANAR_PS2 0x00000100 #define NGE_TBIANAR_PCAP 0x00000180 #define NGE_TBIANAR_REMFAULT 0x00003000 #define NGE_TBIANAR_NEXTPAGE 0x00008000 *************** *** 436,441 **** --- 439,446 ---- /* TBI ANLPAR */ #define NGE_TBIANLPAR_HDX 0x00000020 #define NGE_TBIANLPAR_FDX 0x00000040 + #define NGE_TBIANAR_PS1 0x00000080 + #define NGE_TBIANAR_PS2 0x00000100 #define NGE_TBIANLPAR_PCAP 0x00000180 #define NGE_TBIANLPAR_REMFAULT 0x00003000 #define NGE_TBIANLPAR_NEXTPAGE 0x00008000 *************** *** 656,661 **** --- 661,668 ---- struct callout_handle nge_stat_ch; SLIST_HEAD(__nge_jfreehead, nge_jpool_entry) nge_jfree_listhead; SLIST_HEAD(__nge_jinusehead, nge_jpool_entry) nge_jinuse_listhead; + u_int8_t nge_tbi; + struct ifmedia nge_ifmedia; }; /* Index: if_nge.c =================================================================== RCS file: /cvs/src/sys/dev/nge/if_nge.c,v retrieving revision 1.13.2.7 diff -c -r1.13.2.7 if_nge.c *** if_nge.c 14 Dec 2001 19:44:38 -0000 1.13.2.7 --- if_nge.c 18 Feb 2002 21:12:15 -0000 *************** *** 620,645 **** struct mii_data *mii; sc = device_get_softc(dev); ! mii = device_get_softc(sc->nge_miibus); ! if ((mii->mii_media_active & IFM_GMASK) == IFM_FDX) { ! NGE_SETBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_SETBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); } else { ! NGE_CLRBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_CLRBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); ! } ! /* If we have a 1000Mbps link, set the mode_1000 bit. */ ! if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_TX || ! IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_SX) { ! NGE_SETBIT(sc, NGE_CFG, NGE_CFG_MODE_1000); ! } else { ! NGE_CLRBIT(sc, NGE_CFG, NGE_CFG_MODE_1000); ! } return; } --- 620,674 ---- struct mii_data *mii; sc = device_get_softc(dev); ! if (sc->nge_tbi){ /* DJA check this */ ! ! /* ! * BUG: Can't read Link status so assume FDX unless HDX is ! * specified ! */ ! if (IFM_SUBTYPE(sc->nge_ifmedia.ifm_cur->ifm_media) ! == IFM_AUTO) { ! if (CSR_READ_4(sc, NGE_TBI_ANLPAR) & NGE_TBIANAR_FDX) { ! NGE_SETBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_SETBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); ! } else { ! NGE_CLRBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_CLRBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); ! } ! } else if ((sc->nge_ifmedia.ifm_cur->ifm_media & IFM_GMASK) ! != IFM_FDX) { ! NGE_CLRBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_CLRBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); ! } else { ! NGE_SETBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_SETBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); ! } } else { ! mii = device_get_softc(sc->nge_miibus); ! if ((mii->mii_media_active & IFM_GMASK) == IFM_FDX) { ! NGE_SETBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_SETBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); ! } else { ! NGE_CLRBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_CLRBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); ! } + /* If we have a 1000Mbps link, set the mode_1000 bit. */ + if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_TX || + IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_SX) { + NGE_SETBIT(sc, NGE_CFG, NGE_CFG_MODE_1000); + } else { + NGE_CLRBIT(sc, NGE_CFG, NGE_CFG_MODE_1000); + } + } return; } *************** *** 794,799 **** --- 823,829 ---- struct nge_softc *sc; struct ifnet *ifp; int unit, error = 0, rid; + const char *sep = ""; s = splimp(); *************** *** 953,966 **** * Do MII setup. */ if (mii_phy_probe(dev, &sc->nge_miibus, ! nge_ifmedia_upd, nge_ifmedia_sts)) { ! printf("nge%d: MII without any PHY!\n", sc->nge_unit); ! nge_free_jumbo_mem(sc); ! bus_teardown_intr(dev, sc->nge_irq, sc->nge_intrhand); ! bus_release_resource(dev, SYS_RES_IRQ, 0, sc->nge_irq); ! bus_release_resource(dev, NGE_RES, NGE_RID, sc->nge_res); ! error = ENXIO; ! goto fail; } /* --- 983,1030 ---- * Do MII setup. */ if (mii_phy_probe(dev, &sc->nge_miibus, ! nge_ifmedia_upd, nge_ifmedia_sts)) { ! if (CSR_READ_4(sc, NGE_CFG) & NGE_CFG_TBI_EN) { ! sc->nge_tbi = 1; ! device_printf(dev, "Using TBI\n"); ! ! sc->nge_miibus = dev; ! ! ifmedia_init(&sc->nge_ifmedia, 0, nge_ifmedia_upd, ! nge_ifmedia_sts); ! #define ADD(m, c) ifmedia_add(&sc->nge_ifmedia, (m), (c), NULL) ! #define PRINT(s) printf("%s%s", sep, s); sep = ", " ! ADD(IFM_MAKEWORD(IFM_ETHER, IFM_NONE, 0, 0), 0); ! device_printf(dev, " "); ! ADD(IFM_MAKEWORD(IFM_ETHER, IFM_1000_SX, 0, 0), 0); ! PRINT("1000baseSX"); ! ADD(IFM_MAKEWORD(IFM_ETHER, IFM_1000_SX, IFM_FDX, 0),0); ! PRINT("1000baseSX-FDX"); ! ADD(IFM_MAKEWORD(IFM_ETHER, IFM_AUTO, 0, 0), 0); ! PRINT("auto"); ! ! printf("\n"); ! #undef ADD ! #undef PRINT ! ifmedia_set(&sc->nge_ifmedia, ! IFM_MAKEWORD(IFM_ETHER, IFM_AUTO, 0, 0)); ! ! CSR_WRITE_4(sc, NGE_GPIO, CSR_READ_4(sc, NGE_GPIO) ! | NGE_GPIO_GP4_OUT ! | NGE_GPIO_GP1_OUTENB | NGE_GPIO_GP2_OUTENB ! | NGE_GPIO_GP3_OUTENB ! | NGE_GPIO_GP3_IN | NGE_GPIO_GP4_IN); ! ! } else { ! printf("nge%d: MII without any PHY!\n", sc->nge_unit); ! nge_free_jumbo_mem(sc); ! bus_teardown_intr(dev, sc->nge_irq, sc->nge_intrhand); ! bus_release_resource(dev, SYS_RES_IRQ, 0, sc->nge_irq); ! bus_release_resource(dev, NGE_RES, NGE_RID, ! sc->nge_res); ! error = ENXIO; ! goto fail; ! } } /* *************** *** 970,975 **** --- 1034,1040 ---- callout_handle_init(&sc->nge_stat_ch); fail: + splx(s); return(error); } *************** *** 991,998 **** ether_ifdetach(ifp, ETHER_BPF_SUPPORTED); bus_generic_detach(dev); ! device_delete_child(dev, sc->nge_miibus); ! bus_teardown_intr(dev, sc->nge_irq, sc->nge_intrhand); bus_release_resource(dev, SYS_RES_IRQ, 0, sc->nge_irq); bus_release_resource(dev, NGE_RES, NGE_RID, sc->nge_res); --- 1056,1064 ---- ether_ifdetach(ifp, ETHER_BPF_SUPPORTED); bus_generic_detach(dev); ! if (!sc->nge_tbi){ ! device_delete_child(dev, sc->nge_miibus); ! } bus_teardown_intr(dev, sc->nge_irq, sc->nge_intrhand); bus_release_resource(dev, SYS_RES_IRQ, 0, sc->nge_irq); bus_release_resource(dev, NGE_RES, NGE_RID, sc->nge_res); *************** *** 1330,1336 **** cur_rx->nge_mbuf = NULL; total_len = NGE_RXBYTES(cur_rx); NGE_INC(i, NGE_RX_LIST_CNT); - /* * If an error occurs, update stats, clear the * status word and leave the mbuf cluster in place: --- 1396,1401 ---- *************** *** 1343,1349 **** continue; } - /* * Ok. NatSemi really screwed up here. This is the * only gigE chip I know of with alignment constraints --- 1408,1413 ---- *************** *** 1505,1527 **** sc = xsc; ifp = &sc->arpcom.ac_if; ! mii = device_get_softc(sc->nge_miibus); ! mii_tick(mii); ! ! if (!sc->nge_link) { ! mii_pollstat(mii); ! if (mii->mii_media_status & IFM_ACTIVE && ! IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { ! sc->nge_link++; ! if (IFM_SUBTYPE(mii->mii_media_active) == IFM_1000_TX) printf("nge%d: gigabit link up\n", sc->nge_unit); ! if (ifp->if_snd.ifq_head != NULL) ! nge_start(ifp); ! } else ! sc->nge_stat_ch = timeout(nge_tick, sc, hz); ! } splx(s); --- 1569,1606 ---- sc = xsc; ifp = &sc->arpcom.ac_if; ! if (sc->nge_tbi){ ! if (!sc->nge_link) { ! if (CSR_READ_4(sc, NGE_TBI_BMSR) ! & NGE_TBIBMSR_ANEG_DONE){ printf("nge%d: gigabit link up\n", sc->nge_unit); ! nge_miibus_statchg(sc->nge_miibus); ! sc->nge_link++; ! if (ifp->if_snd.ifq_head != NULL) ! nge_start(ifp); ! } else ! sc->nge_stat_ch = timeout(nge_tick, sc, hz); ! } ! } else { ! mii = device_get_softc(sc->nge_miibus); ! mii_tick(mii); + if (!sc->nge_link) { + mii_pollstat(mii); + if (mii->mii_media_status & IFM_ACTIVE && + IFM_SUBTYPE(mii->mii_media_active) != IFM_NONE) { + sc->nge_link++; + if (IFM_SUBTYPE(mii->mii_media_active) + == IFM_1000_TX) + printf("nge%d: gigabit link up\n", + sc->nge_unit); + if (ifp->if_snd.ifq_head != NULL) + nge_start(ifp); + } else + sc->nge_stat_ch = timeout(nge_tick, sc, hz); + } + } splx(s); *************** *** 1547,1552 **** --- 1626,1636 ---- /* Disable interrupts. */ CSR_WRITE_4(sc, NGE_IER, 0); + /* Data LED on for TBI mode */ + if(sc->nge_tbi) + CSR_WRITE_4(sc, NGE_GPIO, CSR_READ_4(sc, NGE_GPIO) + | NGE_GPIO_GP3_OUT); + for (;;) { /* Reading the ISR register clears all interrupts. */ status = CSR_READ_4(sc, NGE_ISR); *************** *** 1588,1593 **** --- 1672,1683 ---- if (ifp->if_snd.ifq_head != NULL) nge_start(ifp); + /* Data LED off for TBI mode */ + + if(sc->nge_tbi) + CSR_WRITE_4(sc, NGE_GPIO, CSR_READ_4(sc, NGE_GPIO) + & ~NGE_GPIO_GP3_OUT); + return; } *************** *** 1738,1744 **** */ nge_stop(sc); ! mii = device_get_softc(sc->nge_miibus); /* Set MAC address */ CSR_WRITE_4(sc, NGE_RXFILT_CTL, NGE_FILTADDR_PAR0); --- 1828,1838 ---- */ nge_stop(sc); ! if (sc->nge_tbi){ ! mii = NULL; ! } else { ! mii = device_get_softc(sc->nge_miibus); ! } /* Set MAC address */ CSR_WRITE_4(sc, NGE_RXFILT_CTL, NGE_FILTADDR_PAR0); *************** *** 1836,1852 **** */ NGE_SETBIT(sc, NGE_VLAN_IP_TXCTL, NGE_VIPTXCTL_TAG_PER_PKT); - /* Set full/half duplex mode. */ - if ((mii->mii_media_active & IFM_GMASK) == IFM_FDX) { - NGE_SETBIT(sc, NGE_TX_CFG, - (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); - NGE_SETBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); - } else { - NGE_CLRBIT(sc, NGE_TX_CFG, - (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); - NGE_CLRBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); - } - /* * Enable the delivery of PHY interrupts based on * link/speed/duplex status changes. Also enable the --- 1930,1935 ---- *************** *** 1895,1909 **** sc = ifp->if_softc; ! mii = device_get_softc(sc->nge_miibus); ! sc->nge_link = 0; ! if (mii->mii_instance) { ! struct mii_softc *miisc; ! for (miisc = LIST_FIRST(&mii->mii_phys); miisc != NULL; ! miisc = LIST_NEXT(miisc, mii_list)) ! mii_phy_reset(miisc); } - mii_mediachg(mii); return(0); } --- 1978,2022 ---- sc = ifp->if_softc; ! if (sc->nge_tbi){ ! if (IFM_SUBTYPE(sc->nge_ifmedia.ifm_cur->ifm_media) ! == IFM_AUTO) { ! CSR_WRITE_4(sc, NGE_TBI_ANAR, ! CSR_READ_4(sc, NGE_TBI_ANAR) ! | NGE_TBIANAR_HDX | NGE_TBIANAR_FDX); ! CSR_WRITE_4(sc, NGE_TBI_BMCR, NGE_TBIBMCR_ENABLE_ANEG ! | NGE_TBIBMCR_RESTART_ANEG); ! CSR_WRITE_4(sc, NGE_TBI_BMCR, NGE_TBIBMCR_ENABLE_ANEG); ! } else if ((sc->nge_ifmedia.ifm_cur->ifm_media ! & IFM_GMASK) == IFM_FDX) { ! NGE_SETBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_SETBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); ! ! CSR_WRITE_4(sc, NGE_TBI_ANAR, 0); ! CSR_WRITE_4(sc, NGE_TBI_BMCR, 0); ! } else { ! NGE_CLRBIT(sc, NGE_TX_CFG, ! (NGE_TXCFG_IGN_HBEAT|NGE_TXCFG_IGN_CARR)); ! NGE_CLRBIT(sc, NGE_RX_CFG, NGE_RXCFG_RX_FDX); ! ! CSR_WRITE_4(sc, NGE_TBI_ANAR, 0); ! CSR_WRITE_4(sc, NGE_TBI_BMCR, 0); ! } ! ! CSR_WRITE_4(sc, NGE_GPIO, CSR_READ_4(sc, NGE_GPIO) ! & ~NGE_GPIO_GP3_OUT); ! } else { ! mii = device_get_softc(sc->nge_miibus); ! sc->nge_link = 0; ! if (mii->mii_instance) { ! struct mii_softc *miisc; ! for (miisc = LIST_FIRST(&mii->mii_phys); miisc != NULL; ! miisc = LIST_NEXT(miisc, mii_list)) ! mii_phy_reset(miisc); ! } ! mii_mediachg(mii); } return(0); } *************** *** 1920,1929 **** sc = ifp->if_softc; ! mii = device_get_softc(sc->nge_miibus); ! mii_pollstat(mii); ! ifmr->ifm_active = mii->mii_media_active; ! ifmr->ifm_status = mii->mii_media_status; return; } --- 2033,2082 ---- sc = ifp->if_softc; ! if (sc->nge_tbi){ /* DJA */ ! ifmr->ifm_status = IFM_AVALID; ! ifmr->ifm_active = IFM_ETHER; ! ! /* ! printf("NGE_TBI_BMCR %x\n",CSR_READ_4(sc, NGE_TBI_BMCR)); ! printf("NGE_TBI_BMSR %x\n",CSR_READ_4(sc, NGE_TBI_BMSR)); ! printf("NGE_TBI_ANAR %x\n",CSR_READ_4(sc, NGE_TBI_ANAR)); ! printf("NGE_TBI_ANLPAR %x\n",CSR_READ_4(sc, NGE_TBI_ANLPAR)); ! printf("NGE_TBI_ANER %x\n",CSR_READ_4(sc, NGE_TBI_ANER)); ! printf("NGE_TBI_ESR %x\n",CSR_READ_4(sc, NGE_TBI_ESR)); ! */ ! ! if (CSR_READ_4(sc, NGE_TBI_BMSR) & NGE_TBIBMSR_ANEG_DONE){ ! ifmr->ifm_status |= IFM_ACTIVE; ! } ! if (CSR_READ_4(sc, NGE_TBI_BMCR) & NGE_TBIBMCR_LOOPBACK) ! ifmr->ifm_active |= IFM_LOOP; ! if (!CSR_READ_4(sc, NGE_TBI_BMSR) & NGE_TBIBMSR_ANEG_DONE){ ! ifmr->ifm_active |= IFM_NONE; ! ifmr->ifm_status = 0; ! return; ! } ! ifmr->ifm_active |= IFM_1000_SX; ! if (IFM_SUBTYPE(sc->nge_ifmedia.ifm_cur->ifm_media) ! == IFM_AUTO) ! ifmr->ifm_active |= IFM_AUTO; ! if (CSR_READ_4(sc, NGE_TBI_ANLPAR) & NGE_TBIANAR_FDX){ ! ifmr->ifm_active |= IFM_FDX; ! }else if (CSR_READ_4(sc, NGE_TBI_ANLPAR) & NGE_TBIANAR_HDX){ ! ifmr->ifm_active |= IFM_HDX; ! } ! else if ((sc->nge_ifmedia.ifm_cur->ifm_media & IFM_GMASK) ! == IFM_FDX) ! ifmr->ifm_active |= IFM_FDX; ! else ! ifmr->ifm_active |= IFM_HDX; ! ! } else { ! mii = device_get_softc(sc->nge_miibus); ! mii_pollstat(mii); ! ifmr->ifm_active = mii->mii_media_active; ! ifmr->ifm_status = mii->mii_media_status; ! } return; } *************** *** 1995,2002 **** break; case SIOCGIFMEDIA: case SIOCSIFMEDIA: ! mii = device_get_softc(sc->nge_miibus); ! error = ifmedia_ioctl(ifp, ifr, &mii->mii_media, command); break; default: error = EINVAL; --- 2148,2161 ---- break; case SIOCGIFMEDIA: case SIOCSIFMEDIA: ! if (sc->nge_tbi){ /* DJA */ ! error = ifmedia_ioctl(ifp, ifr, &sc->nge_ifmedia, ! command); ! } else{ ! mii = device_get_softc(sc->nge_miibus); ! error = ifmedia_ioctl(ifp, ifr, &mii->mii_media, ! command); ! } break; default: error = EINVAL; *************** *** 2044,2050 **** ifp = &sc->arpcom.ac_if; ifp->if_timer = 0; ! mii = device_get_softc(sc->nge_miibus); untimeout(nge_tick, sc, sc->nge_stat_ch); CSR_WRITE_4(sc, NGE_IER, 0); --- 2203,2213 ---- ifp = &sc->arpcom.ac_if; ifp->if_timer = 0; ! if (sc->nge_tbi){ ! mii = NULL; ! } else { ! mii = device_get_softc(sc->nge_miibus); ! } untimeout(nge_tick, sc, sc->nge_stat_ch); CSR_WRITE_4(sc, NGE_IER, 0); *************** *** 2061,2070 **** */ itmp = ifp->if_flags; ifp->if_flags |= IFF_UP; ! ifm = mii->mii_media.ifm_cur; mtmp = ifm->ifm_media; ifm->ifm_media = IFM_ETHER|IFM_NONE; ! mii_mediachg(mii); ifm->ifm_media = mtmp; ifp->if_flags = itmp; --- 2224,2240 ---- */ itmp = ifp->if_flags; ifp->if_flags |= IFF_UP; ! ! if (sc->nge_tbi) ! ifm = sc->nge_ifmedia.ifm_cur; ! else ! ifm = mii->mii_media.ifm_cur; ! mtmp = ifm->ifm_media; ifm->ifm_media = IFM_ETHER|IFM_NONE; ! ! if (!sc->nge_tbi) ! mii_mediachg(mii); ifm->ifm_media = mtmp; ifp->if_flags = itmp; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 13:44: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.tgd.net (mail.tgd.net [209.81.25.10]) by hub.freebsd.org (Postfix) with ESMTP id B076537B400 for ; Mon, 18 Feb 2002 13:44:06 -0800 (PST) Received: by mail.tgd.net (Postfix, from userid 1001) id DE8F220F05; Mon, 18 Feb 2002 13:44:05 -0800 (PST) Date: Mon, 18 Feb 2002 13:44:05 -0800 From: Sean Chittenden To: Richard A Steenbergen Cc: Zviratko , freebsd-net@freebsd.org Subject: Re: Ethernet bonding/load balancing on fbsd 4-stable Message-ID: <20020218134405.A6619@ninja1.internal> References: <003501c1b7a8$4431d5f0$0500a8c0@notes> <20020217205620.GN413@overlord.e-gerbil.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020217205620.GN413@overlord.e-gerbil.net>; from "ras@e-gerbil.net" on Sun, Feb 17, 2002 at = 03:56:20PM X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > The only real "cisco only" protocol is the PAgP (Port Aggregation > Protocol) which is essentially just a FEC auto-negiotation protocol they > made up. AFAIK noone other then Cisco actually implements this though. Don't forget to add EIGRP and CDP to the list. -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 13:49:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 7291D37B416 for ; Mon, 18 Feb 2002 13:49:48 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16cvfH-000EqY-00; Mon, 18 Feb 2002 13:49:39 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sean Chittenden Cc: freebsd-net@freebsd.org Subject: Re: Ethernet bonding/load balancing on fbsd 4-stable References: <003501c1b7a8$4431d5f0$0500a8c0@notes> <20020217205620.GN413@overlord.e-gerbil.net> <20020218134405.A6619@ninja1.internal> Message-Id: Date: Mon, 18 Feb 2002 13:49:39 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> The only real "cisco only" protocol is the PAgP (Port Aggregation >> Protocol) which is essentially just a FEC auto-negiotation protocol they >> made up. AFAIK noone other then Cisco actually implements this though. > Don't forget to add EIGRP and CDP to the list. -sc actually, the one with serious operational impactis inter-router aps. this has never been standardized. hence one can not have a sdh/sonet primary/protect pair coming into a pair of routers each from different vendors. but why is this on a freebsd list? randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 14:11:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mdv.dhs.org (mdv.xs4all.nl [213.84.209.48]) by hub.freebsd.org (Postfix) with ESMTP id 85D5D37B402 for ; Mon, 18 Feb 2002 14:11:00 -0800 (PST) Received: (from root@localhost) by mdv.dhs.org (8.11.6/8.11.6) id g1IMAuj01778; Mon, 18 Feb 2002 23:10:56 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Received: from marcel.haveityourway.nl (marcel.mdv.int [192.168.1.3]) by mdv.dhs.org (8.11.6/8.11.6av) with ESMTP id g1IMArh01771; Mon, 18 Feb 2002 23:10:53 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Message-Id: <5.1.0.14.2.20020218231018.01f18948@outshine> X-Sender: mdevries@outshine X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Feb 2002 23:10:48 +0100 To: freebsd-net@freebsd.org From: Marcel de Vries Subject: Re: network buffer problem Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thanks for the quick reply. But I want to come back first about the identical system a friend of my is= =20 using only with the xl driver for his public interface. But today he told me when pinging to a host like ping -s 4096 www.bart.nl=20 and meanwhile enjoying the sound from the digitally imported shoutcast=20 server, the 'no buffer space messages reappeared. So he has the same problem only using the xl driver=85 But he was also complaining about that the problem never occurred in=20 FreeBSD 4.4 or 4.3.. But some other info, we also had trouble with our connections. First of all we both used natd and ipfw also we connected our BSD boxes=20 with GIF. When playing games natd always ended up using a lot of proctime like top=20 indicated about 60 to 90%. The connection suffered from it and as result=20 packet loss 100% and no recovery at all, I had to restart mpd and stuff. So ok, what=92s wrong? With my experience I could not find any errors even= =20 when using natd in verbose mode. All I could see was lot=92s of translations= ;-) But trying ipnat what seemed to be more stable gave me more hope, but now=20 I=92m suffering from no buffer space available, so to problem persists and= at=20 the end we are still losing the connection and mass packet loss=85 I really want to make a point, is it third party software =91mpd-3.7=20 Multi-link PPP daemon based on netgraph(4)=92 that is causing this or is it= =20 something in the TCP/IP stack of BSD that is changed or the driver support. We had these problems in 4.3, 4.4 and still in 4.5. From using mpd 3.1 to 3.7 nothing changed about our problem. I think it=92s an important notice why this is happening, because what if=20 this is a real TCP/IP stack issue this would be very wrong and bad for= FreeBSD. But I=92m still no expert so I have to leave this open for the Pro BSD=20 users/developers. Bye, Marcel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 15: 7:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d85.as6.nwbl0.wi.voyager.net [169.207.128.85]) by hub.freebsd.org (Postfix) with ESMTP id 90BCC37B417 for ; Mon, 18 Feb 2002 15:07:30 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g1IHBNs7000266; Mon, 18 Feb 2002 17:11:23 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g1IHBBLk000263; Mon, 18 Feb 2002 17:11:22 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 18 Feb 2002 17:11:11 +0000 (GMT) From: Mike Silbersack To: Marcel de Vries Cc: freebsd-net@freebsd.org Subject: Re: network buffer problem In-Reply-To: <5.1.0.14.2.20020218224119.01faca88@outshine> Message-ID: <20020218165433.T327-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 18 Feb 2002, Marcel de Vries wrote: > I really want to make a point, is it third party software =91mpd-3.7 > Multi-link PPP daemon based on netgraph(4)=92 that is causing this or is = it > something in the TCP/IP stack of BSD that is changed or the driver suppor= t. > > We had these problems in 4.3, 4.4 and still in 4.5. > From using mpd 3.1 to 3.7 nothing changed about our problem. > > I think it=92s an important notice why this is happening, because what if > this is a real TCP/IP stack issue this would be very wrong and bad for Fr= eeBSD. > > But I=92m still no expert so I have to leave this open for the Pro BSD > users/developers. > > Bye, > > Marcel If your friend with a different network card is having similar problems, I'd guess that mpd-netgraph is where you should start investigating. However, as I have never used mpd-netgraph, I have no idea what you should be looking at. If by chance a mpd guru does not wander into this thread, I suggest that you look through the old mailing list archives, see who has had experience with it before, and drop them an e-mail. As far as your other question about natd slowing down... I believe that someone was looking into that. If he manages to find the bottleneck and fix it, I suspect you'll see the announcement here. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 15:20:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 0300A37B405 for ; Mon, 18 Feb 2002 15:20:16 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020218232015.LVHM1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Mon, 18 Feb 2002 23:20:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA53757; Mon, 18 Feb 2002 15:11:11 -0800 (PST) Date: Mon, 18 Feb 2002 15:11:11 -0800 (PST) From: Julian Elischer To: Mike Silbersack Cc: Marcel de Vries , freebsd-net@freebsd.org Subject: Re: network buffer problem In-Reply-To: <20020218165433.T327-100000@patrocles.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 18 Feb 2002, Mike Silbersack wrote: > be looking at. If by chance a mpd guru does not wander into this thread, > I suggest that you look through the old mailing list archives, see who > has had experience with it before, and drop them an e-mail. contact archie@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 16:14:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id 1185837B402 for ; Mon, 18 Feb 2002 16:14:22 -0800 (PST) Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Postfix) with ESMTP id D17FA5D09; Mon, 18 Feb 2002 16:14:21 -0800 (PST) To: Marcel de Vries Cc: freebsd-net@freebsd.org Subject: Re: network buffer problem In-reply-to: Your message of "Mon, 18 Feb 2002 23:10:48 +0100." <5.1.0.14.2.20020218231018.01f18948@outshine> Date: Mon, 18 Feb 2002 16:14:21 -0800 From: "Kevin Oberman" Message-Id: <20020219001421.D17FA5D09@ptavv.es.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Just for the record, this one bit me (with an xl card) last week. It had never happened with 4.4-Release on the same system (my office desktop) but happened about a week after installing 4.5-Release. netstat -m showed no problems, but I could not ping, open an ssh connection to a remote system or any network activity. Sine I really needed this system running on the net, I re-booted rather than try to figure out what had happened. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 16:21:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id CA76B37B400 for ; Mon, 18 Feb 2002 16:21:16 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16cy1y-000JIy-00; Mon, 18 Feb 2002 16:21:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kevin Oberman Cc: freebsd-net@freebsd.org Subject: Re: network buffer problem References: <5.1.0.14.2.20020218231018.01f18948@outshine> <20020219001421.D17FA5D09@ptavv.es.net> Message-Id: Date: Mon, 18 Feb 2002 16:21:14 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org i had a jillion of these the other day while i was out of town. /kernel: fxp0: cluster allocation failed, packet dropped! /kernel: m_clalloc failed, consider increase NMBCLUSTERS value no net access, of course. it cleared itself up, no reboot. been running for five days since the problem and nothing else strange. 4.5-stable of 2002.02.09 randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 16:38: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 0E44137B404 for ; Mon, 18 Feb 2002 16:38:05 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1J0c2U22605; Mon, 18 Feb 2002 16:38:02 -0800 (PST) (envelope-from rizzo) Date: Mon, 18 Feb 2002 16:38:02 -0800 From: Luigi Rizzo To: Randy Bush Cc: Kevin Oberman , freebsd-net@FreeBSD.ORG Subject: Re: network buffer problem Message-ID: <20020218163802.B22456@iguana.icir.org> References: <5.1.0.14.2.20020218231018.01f18948@outshine> <20020219001421.D17FA5D09@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Feb 18, 2002 at 04:21:14PM -0800, Randy Bush wrote: > i had a jillion of these the other day while i was out of town. > > /kernel: fxp0: cluster allocation failed, packet dropped! > /kernel: m_clalloc failed, consider increase NMBCLUSTERS value > > no net access, of course. it cleared itself up, no reboot. been running > for five days since the problem and nothing else strange. can you show the output of "netstat -m" ? I wonder if the code to auto-size the number of clusters and mbuf isn't picking up too low values for your system. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 16:43:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mdv.dhs.org (mdv.xs4all.nl [213.84.209.48]) by hub.freebsd.org (Postfix) with ESMTP id CB08537B405 for ; Mon, 18 Feb 2002 16:43:52 -0800 (PST) Received: (from root@localhost) by mdv.dhs.org (8.11.6/8.11.6) id g1J0hq103166 for freebsd-net@freebsd.org; Tue, 19 Feb 2002 01:43:52 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Received: from marcel.haveityourway.nl (marcel.mdv.int [192.168.1.3]) by mdv.dhs.org (8.11.6/8.11.6av) with ESMTP id g1J0hoh03159 for ; Tue, 19 Feb 2002 01:43:50 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Message-Id: <5.1.0.14.2.20020219013744.01dab338@outshine> X-Sender: mdevries@outshine X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Feb 2002 01:43:41 +0100 To: freebsd-net@freebsd.org From: Marcel de Vries Subject: Re: network buffer problem In-Reply-To: <20020218165433.T327-100000@patrocles.silby.com> References: <5.1.0.14.2.20020218224119.01faca88@outshine> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Well it could be mpd, but my good old friend ;-) tested a view things. First he used DUMMYNET to simulate his ADSL connection in a LAN environment (100baseT) So he put in some packet loss and bandwidth limitations on his LAN and started pinging some hosts. He gets the same result of packets being lost with the message 'no buffer space available'. So in this way mpd wasn't used at all. This makes sense right. Could it be a configuration problem or a really hard to think IP stack problem? He was very sure to me about not having these problems when using previous versions of FreeBSD before release 4.5. I don't know if that's true. And most of the IP traffic is no problem at all, things that definitely cut the chase is to be generating a lot of UDP traffic like games do. This buffer seems to be running wild from that type of traffic. Tonight we lowered the following value's net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 We started gaming like for more then a hour and no problems at all. But I think it was not long enough. But I hope this is useful: To recover from a total down of the internet connection, I need to restart mpd. Mpd was patched to start the following script when executed. #!/bin/sh INTERFACE=$1 PROTOCOL=$2 LOCAL=$3 REMOTE=$4 /sbin/route delete default /sbin/ifconfig ng0 mtu 1492 /sbin/route add default $REMOTE [ -x /sbin/ipnat ] && /sbin/ipnat -CF -f /etc/ipnat.conf && ipf -y && echo -n 'ipnat' /usr/bin/killall -HUP inetd /usr/bin/killall snort /bin/sleep 15 && /usr/local/bin/snort -i ng0 -p -o -D -c /usr/local/etc/snort/snort.conf & So what kind of buffer would hit hs max limit and will be reset by this action? not nmb thats for sure, when check netstat -m everything seems normal. You see the mtu option in the script, there where dutch people having trouble with there ADSL mxstream connection regarding with use of mpd on the FreeBSD box. 'No buffer' messages also appeared for those users not for all. To alter the MTU helped in some cases. But I think that's not true, because when extremely using bandwidth like listen from streaming media and simultaneously pinging a host you could generate the message without any problems. And the message no buffer space available is not only a warning. It's heavy packet loss and that's a thing nobody wants to deal with. I hope this will clear up a few things, and as I see more FreeBSD folks replying on this subject something must be wrong in the world of IP BSD ;-) Thanks, Marcel de Vries At 17:11 18-02-2002 +0000, Mike Silbersack wrote: >On Mon, 18 Feb 2002, Marcel de Vries wrote: > > > I really want to make a point, is it third party software 'mpd-3.7 > > Multi-link PPP daemon based on netgraph(4)' that is causing this or is it > > something in the TCP/IP stack of BSD that is changed or the driver support. > > > > We had these problems in 4.3, 4.4 and still in 4.5. > > From using mpd 3.1 to 3.7 nothing changed about our problem. > > > > I think it's an important notice why this is happening, because what if > > this is a real TCP/IP stack issue this would be very wrong and bad for > FreeBSD. > > > > But I'm still no expert so I have to leave this open for the Pro BSD > > users/developers. > > > > Bye, > > > > Marcel > >If your friend with a different network card is having similar problems, >I'd guess that mpd-netgraph is where you should start investigating. > >However, as I have never used mpd-netgraph, I have no idea what you should >be looking at. If by chance a mpd guru does not wander into this thread, >I suggest that you look through the old mailing list archives, see who >has had experience with it before, and drop them an e-mail. > >As far as your other question about natd slowing down... I believe that >someone was looking into that. If he manages to find the bottleneck and >fix it, I suspect you'll see the announcement here. > >Mike "Silby" Silbersack > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 17: 3:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 980FE37B404 for ; Mon, 18 Feb 2002 17:03:25 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16cygh-000KXu-00; Mon, 18 Feb 2002 17:03:19 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: network buffer problem References: <5.1.0.14.2.20020218231018.01f18948@outshine> <20020219001421.D17FA5D09@ptavv.es.net> <20020218163802.B22456@iguana.icir.org> Message-Id: Date: Mon, 18 Feb 2002 17:03:19 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> /kernel: fxp0: cluster allocation failed, packet dropped! >> /kernel: m_clalloc failed, consider increase NMBCLUSTERS value > can you show the output of "netstat -m" ? # netstat -m 306/2352/6016 mbufs in use (current/peak/max): 264 mbufs allocated to data 42 mbufs allocated to packet headers 219/1504/1504 mbuf clusters in use (current/peak/max) 3596 Kbytes allocated to network (79% of mb_map in use) 249385 requests for memory denied 2 requests for memory delayed 0 calls to protocol drain routines there has been no reboot since the incident randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 17:25: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id CF2B337B404 for ; Mon, 18 Feb 2002 17:24:52 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1J1Oi422875; Mon, 18 Feb 2002 17:24:44 -0800 (PST) (envelope-from rizzo) Date: Mon, 18 Feb 2002 17:24:44 -0800 From: Luigi Rizzo To: Marcel de Vries Cc: freebsd-net@FreeBSD.ORG Subject: Re: network buffer problem Message-ID: <20020218172444.C22456@iguana.icir.org> References: <5.1.0.14.2.20020218224119.01faca88@outshine> <5.1.0.14.2.20020219013744.01dab338@outshine> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020219013744.01dab338@outshine> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ok, I have refrained from jumping into this thread but the noise is increasing and I think some clarifications are really necessary now. First of all: at various levels in the protocol stack, when a packet cannot be forwarded to the next layer, more often than not a ENOBUFS error is returned, which is propagated back and then printed by perror() as "no buffer space available". One of this situations is when a dummynet pipe fills up. So the test you report below with dummynet is telling absolutely nothing, and certainly it does not show an error or configuration problem. Second: ping makes no use of tcp, so changing the net.inet.tcp.{sendspace,recvspace} values has no [direct] impact on the behaviour of your ping. What I suspect is happening is that mpd is saturating either the divert socket queue (if you look in netinet/ip_divert.c, this size is fixed to 64k), or the buffer on the "tun" interface. My understanding stops here... if you can summarise what is the problem you were having initially, maybe i can give more details. cheers luigi On Tue, Feb 19, 2002 at 01:43:41AM +0100, Marcel de Vries wrote: > Well it could be mpd, but my good old friend ;-) tested a view things. > > First he used DUMMYNET to simulate his ADSL connection in a LAN environment > (100baseT) > > So he put in some packet loss and bandwidth limitations on his LAN and > started pinging some hosts. He gets the same result of packets being lost > with the message 'no buffer space available'. So in this way mpd wasn't > used at all. This makes sense right. Could it be a configuration problem or > a really hard to think IP stack problem? > > He was very sure to me about not having these problems when using previous > versions of FreeBSD before release 4.5. > > I don't know if that's true. > And most of the IP traffic is no problem at all, things that definitely cut > the chase is to be generating a lot of UDP traffic like games do. This > buffer seems to be running wild from that type of traffic. > > Tonight we lowered the following value's > net.inet.tcp.sendspace: 16384 > net.inet.tcp.recvspace: 16384 > > We started gaming like for more then a hour and no problems at all. > But I think it was not long enough. > > But I hope this is useful: To recover from a total down of the internet > connection, I need to restart mpd. Mpd was patched to start the following > script when executed. > > #!/bin/sh > INTERFACE=$1 > PROTOCOL=$2 > LOCAL=$3 > REMOTE=$4 > > /sbin/route delete default > /sbin/ifconfig ng0 mtu 1492 > /sbin/route add default $REMOTE > > [ -x /sbin/ipnat ] && /sbin/ipnat -CF -f /etc/ipnat.conf && ipf -y && > echo -n 'ipnat' > > /usr/bin/killall -HUP inetd > /usr/bin/killall snort > /bin/sleep 15 && /usr/local/bin/snort -i ng0 -p -o -D -c > /usr/local/etc/snort/snort.conf & > > So what kind of buffer would hit hs max limit and will be reset by this > action? > not nmb thats for sure, when check netstat -m everything seems normal. > > You see the mtu option in the script, there where dutch people having > trouble with there ADSL mxstream connection regarding with use of mpd on > the FreeBSD box. 'No buffer' messages also appeared for those users not for > all. To alter the MTU helped in some cases. > > But I think that's not true, because when extremely using bandwidth like > listen from streaming media and simultaneously pinging a host you could > generate the message without any problems. > > And the message no buffer space available is not only a warning. It's heavy > packet loss and that's a thing nobody wants to deal with. > > I hope this will clear up a few things, and as I see more FreeBSD folks > replying on this subject something must be wrong in the world of IP BSD ;-) > > Thanks, > > Marcel de Vries > > > > > > > > > > At 17:11 18-02-2002 +0000, Mike Silbersack wrote: > > > >On Mon, 18 Feb 2002, Marcel de Vries wrote: > > > >> I really want to make a point, is it third party software 'mpd-3.7 > >> Multi-link PPP daemon based on netgraph(4)' that is causing this or is it > >> something in the TCP/IP stack of BSD that is changed or the driver > >support. > >> > >> We had these problems in 4.3, 4.4 and still in 4.5. > >> From using mpd 3.1 to 3.7 nothing changed about our problem. > >> > >> I think it's an important notice why this is happening, because what if > >> this is a real TCP/IP stack issue this would be very wrong and bad for > >FreeBSD. > >> > >> But I'm still no expert so I have to leave this open for the Pro BSD > >> users/developers. > >> > >> Bye, > >> > >> Marcel > > > >If your friend with a different network card is having similar problems, > >I'd guess that mpd-netgraph is where you should start investigating. > > > >However, as I have never used mpd-netgraph, I have no idea what you should > >be looking at. If by chance a mpd guru does not wander into this thread, > >I suggest that you look through the old mailing list archives, see who > >has had experience with it before, and drop them an e-mail. > > > >As far as your other question about natd slowing down... I believe that > >someone was looking into that. If he manages to find the bottleneck and > >fix it, I suspect you'll see the announcement here. > > > >Mike "Silby" Silbersack > > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-net" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 17:32:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 2F35037B404 for ; Mon, 18 Feb 2002 17:32:34 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1J1WXS22940; Mon, 18 Feb 2002 17:32:33 -0800 (PST) (envelope-from rizzo) Date: Mon, 18 Feb 2002 17:32:33 -0800 From: Luigi Rizzo To: Randy Bush Cc: freebsd-net@FreeBSD.ORG Subject: Re: network buffer problem Message-ID: <20020218173233.D22456@iguana.icir.org> References: <5.1.0.14.2.20020218231018.01f18948@outshine> <20020219001421.D17FA5D09@ptavv.es.net> <20020218163802.B22456@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As i suspected, you have a quite small number of mbuf clusters in the system. I am unsure on how much memory you have and how your box is used, but mbufs are used quite a bit in the system. Each fxp device allocates 64 clusters in the receive queue, and can have up to 128 in the NIC transmit queue, and up to 50 or 128 in the if_ transmit queue. Same for other network interfaces. ipintrq consumes additional 50 clusters. socket buffers can also be big consumers, at 30-50 clusters each. If you have 4.5 and enough memory one option is to use MAXUSERS=0 and remove and "options NMBCLUSTERS" And if you wonder why you did not see the "out of buffers" message earlier, it's because it was committed sometime in december. cheers luigi On Mon, Feb 18, 2002 at 05:03:19PM -0800, Randy Bush wrote: > >> /kernel: fxp0: cluster allocation failed, packet dropped! > >> /kernel: m_clalloc failed, consider increase NMBCLUSTERS value > > can you show the output of "netstat -m" ? > > # netstat -m > 306/2352/6016 mbufs in use (current/peak/max): > 264 mbufs allocated to data > 42 mbufs allocated to packet headers > 219/1504/1504 mbuf clusters in use (current/peak/max) > 3596 Kbytes allocated to network (79% of mb_map in use) > 249385 requests for memory denied > 2 requests for memory delayed > 0 calls to protocol drain routines > > there has been no reboot since the incident > > randy > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 19: 0:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 51BDF37B400 for ; Mon, 18 Feb 2002 19:00:07 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA69509; Mon, 18 Feb 2002 18:55:16 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1J2seh91729; Mon, 18 Feb 2002 18:54:40 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202190254.g1J2seh91729@arch20m.dellroad.org> Subject: Re: mpd-netgraph as VPN client to Cisco 2500 In-Reply-To: <000d01c1b7f7$c3383390$b27ba8c0@keg> "from Lars Eggert at Feb 17, 2002 01:12:09 pm" To: Lars Eggert Date: Mon, 18 Feb 2002 18:54:40 -0800 (PST) Cc: "'Justin Hawkins'" , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lars Eggert writes: > this doesn't look like the same bug described in the link you posted. > The other bug caused negotiation to completely fail, while it succeeds > in your case. > > Looks like there's something else wring. What does your ifconfig look > like after the link is up? > > > I'm trying to setup a VPN connection to my work's staff > > network. I think I'm running into the problem described here: > > > > http://www.geocrawler.com/mail/msg.php3?msg_id=7311422&list=165 > > > > IE: The physical IP address of the cisco device is the same > > as the tunnel endpoint address, and packets get encapsulated > > recursively. Yes, this is the same problem. Mpd and the kernel have both been modified since that posting: - mpd will disallow the 'fatal' scenario - the 'fatal' scenario is no longer fatal, i.e., instead of the kernel panicing, it will just return the 'deadlock avoided' error Unfortunately, there is no fix for this yet. However you can try one trick, which is to set up a host route to the remote IP address via your default gateway. I'm not sure if this will work but it might (please report success/failure if you try it). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 19:15:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id B7D5937B402; Mon, 18 Feb 2002 19:15:06 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id TAA69596; Mon, 18 Feb 2002 19:03:24 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1J32m991795; Mon, 18 Feb 2002 19:02:48 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202190302.g1J32m991795@arch20m.dellroad.org> Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() In-Reply-To: <20020214191906.A7309@sunbay.com> "from Ruslan Ermilov at Feb 14, 2002 07:19:06 pm" To: Ruslan Ermilov Date: Mon, 18 Feb 2002 19:02:48 -0800 (PST) Cc: Garrett Wollman , net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ruslan Ermilov writes: > > > ping -s 127.1 1.2.3.4 > > > telnet -S 127.1 1.2.3.4 > > > > If someone explicitly overrides source-address selection, they are > > presumed to know WTF they are doing, and the kernel should not be > > trying to second-guess them. > > > That "someone" could be a bad guy playing dirty games with your box and > certainly knowing what he's doing. :-) > > So far, noone gave me a real example where using of net 127 outside > loopback would be useful. If there such an example exists, we should > wrap all three checks into a sysctl, including ip_input(), ip_output(), > and in_canforward() parts, where ip_input() exists for almost a year, > and in_canforward() existed since 1987. No example is required. The kernel should not be implementing what is essentially a policy decision. Note that the RFC you are holding up as gospel talks about hosts on THE Internet, not hosts on some private test network. You assume too much by assuming that all hosts running FreeBSD are connected directly to the Internet. By your argument, the kernel should also block admin attempts to configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an interface. That would put a lot of people behind NAT boxes out of business. If someone intentionally configures their machine in an unconventional way, why automatically assume they are doing something wrong? My vote is to not have any special cases in the kernel for 127/8... rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing in the kernel. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 19:15:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from hawkins.dropbear.id.au (cu713.adelaide.adsl.on.net [150.101.236.205]) by hub.freebsd.org (Postfix) with ESMTP id F15C837B405 for ; Mon, 18 Feb 2002 19:15:07 -0800 (PST) Received: from localhost (jhawkins@localhost) by tardis.everard.bogus (8.11.6/8.11.6) with ESMTP id g1J3DF394983; Tue, 19 Feb 2002 13:43:16 +1030 (CST) (envelope-from justin@hawkins.dropbear.id.au) X-Authentication-Warning: tardis.everard.bogus: jhawkins owned process doing -bs Date: Tue, 19 Feb 2002 13:43:15 +1030 (CST) From: Justin Hawkins X-X-Sender: jhawkins@tardis.everard.bogus To: archie@dellroad.org Cc: freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph as VPN client to Cisco 2500 In-Reply-To: <200202190254.g1J2seh91729@arch20m.dellroad.org> Message-ID: <20020219133856.J90345-100000@tardis.everard.bogus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 18 Feb 2002, Archie Cobbs wrote: > Yes, this is the same problem. Mpd and the kernel have both > been modified since that posting: > > - mpd will disallow the 'fatal' scenario > - the 'fatal' scenario is no longer fatal, i.e., instead of the > kernel panicing, it will just return the 'deadlock avoided' > error > > Unfortunately, there is no fix for this yet. However you can > try one trick, which is to set up a host route to the remote > IP address via your default gateway. I'm not sure if this will > work but it might (please report success/failure if you try it). I had a quick try just then, but I'm on the 'wrong' side of the link, so I managed to lock myself out for a while :-) Will try again later when I'm at home. Is this a hard thing to fix 'properly'? There was implied that some kernel changes were needed in that previous post. Pragmatically, I might just end up getting another IP address on the Cisco, it seems the easiest solution at the moment. Thanks Archie. - Justin -- justin@hawkins.dropbear.id.au | "Don't sweat it -- http://hawkins.dropbear.id.au | it's only 1's and 0's" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 19:26:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id D667F37B400 for ; Mon, 18 Feb 2002 19:26:33 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16d0vI-000OmK-00; Mon, 18 Feb 2002 19:26:32 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: network buffer problem References: <5.1.0.14.2.20020218231018.01f18948@outshine> <20020219001421.D17FA5D09@ptavv.es.net> <20020218163802.B22456@iguana.icir.org> <20020218173233.D22456@iguana.icir.org> Message-Id: Date: Mon, 18 Feb 2002 19:26:32 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > As i suspected, you have a quite small number of mbuf clusters > in the system. I am unsure on how much memory you have and how > your box is used, but mbufs are used quite a bit in the system. 128mb heavy net use: apache/ssl servers, 100k/day email service, ... > If you have 4.5 and enough memory one option is to use > MAXUSERS=0 and remove and "options NMBCLUSTERS" that's how it is now. before the latest builds, it uses to be MAXUSERS=96. maybe i should revert that. and i have to open the box sometime soon, so i'll shove a bunch of ram in it. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 20:13: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d154.as20.nwbl0.wi.voyager.net [169.207.139.156]) by hub.freebsd.org (Postfix) with ESMTP id 3195837B483 for ; Mon, 18 Feb 2002 20:10:27 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g1IME4FY000653; Mon, 18 Feb 2002 22:14:04 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g1IMDxjL000650; Mon, 18 Feb 2002 22:14:01 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 18 Feb 2002 22:13:59 +0000 (GMT) From: Mike Silbersack To: Randy Bush Cc: Luigi Rizzo , Subject: Re: network buffer problem In-Reply-To: Message-ID: <20020218221129.J636-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 18 Feb 2002, Randy Bush wrote: > > If you have 4.5 and enough memory one option is to use > > MAXUSERS=0 and remove and "options NMBCLUSTERS" > > that's how it is now. > > before the latest builds, it uses to be MAXUSERS=96. maybe i should > revert that. > > and i have to open the box sometime soon, so i'll shove a bunch of > ram in it. > > randy Yep, the autoscaling would have chosen MAXUSERS=64, so you've been running with fewer NMBCLUSTERS than usual. OTOH, whatever extraordinary event that caused you to run out of mbuf clusters that one time may very well also run you out of mbuf clusters even at MAXUSERS=96; mbuf clusters tend to get eaten pretty quickly. Either way, adding ram sounds like a good idea. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 20:15:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 5A24D37B6EB; Mon, 18 Feb 2002 20:13:12 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020219041312.SDVT1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Tue, 19 Feb 2002 04:13:12 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1J4DBq38446; Mon, 18 Feb 2002 20:13:11 -0800 (PST) (envelope-from cjc) Date: Mon, 18 Feb 2002 20:13:11 -0800 From: "Crist J. Clark" To: Archie Cobbs Cc: Ruslan Ermilov , Garrett Wollman , net@FreeBSD.ORG Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() Message-ID: <20020218201311.V48401@blossom.cjclark.org> References: <20020214191906.A7309@sunbay.com> <200202190302.g1J32m991795@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202190302.g1J32m991795@arch20m.dellroad.org>; from archie@dellroad.org on Mon, Feb 18, 2002 at 07:02:48PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Feb 18, 2002 at 07:02:48PM -0800, Archie Cobbs wrote: > Ruslan Ermilov writes: > > > > ping -s 127.1 1.2.3.4 > > > > telnet -S 127.1 1.2.3.4 > > > > > > If someone explicitly overrides source-address selection, they are > > > presumed to know WTF they are doing, and the kernel should not be > > > trying to second-guess them. > > > > > That "someone" could be a bad guy playing dirty games with your box and > > certainly knowing what he's doing. :-) > > > > So far, noone gave me a real example where using of net 127 outside > > loopback would be useful. If there such an example exists, we should > > wrap all three checks into a sysctl, including ip_input(), ip_output(), > > and in_canforward() parts, where ip_input() exists for almost a year, > > and in_canforward() existed since 1987. > > No example is required. The kernel should not be implementing what > is essentially a policy decision. > > Note that the RFC you are holding up as gospel talks about hosts > on THE Internet, not hosts on some private test network. You assume > too much by assuming that all hosts running FreeBSD are connected > directly to the Internet. No, RFC1122 is a set of requirements for hosts implementing _the Internet protocol._ 1. INTRODUCTION This document is one of a pair that defines and discusses the requirements for host system implementations of the Internet protocol suite. This RFC covers the communication protocol layers: link layer, IP layer, and transport layer. Its companion RFC, "Requirements for Internet Hosts -- Application and Support" [INTRO:1], covers the application layer protocols. This document should also be read in conjunction with "Requirements for Internet Gateways" [INTRO:2]. These documents are intended to provide guidance for vendors, implementors, and users of Internet communication software. They represent the consensus of a large body of technical experience and wisdom, contributed by the members of the Internet research and vendor communities. I believe it is the intention of FreeBSD to have a working, compliant IP implementation. > By your argument, the kernel should also block admin attempts to > configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an > interface. That would put a lot of people behind NAT boxes out of > business. There are no requirements or references to RFC1918, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 in RFC1122. > If someone intentionally configures their machine in an unconventional > way, why automatically assume they are doing something wrong? > > My vote is to not have any special cases in the kernel for 127/8... > rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing > in the kernel. You definately want to at least block incoming 127.0.0.1 in the kernel. Not doing so is a big security hole. Let's revisit that discussion all over again, http://www.securityfocus.com/archive/1/166648 -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 21: 0:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id A037537B404; Mon, 18 Feb 2002 21:00:18 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020219050018.RJST2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 19 Feb 2002 05:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA54951; Mon, 18 Feb 2002 20:49:56 -0800 (PST) Date: Mon, 18 Feb 2002 20:49:55 -0800 (PST) From: Julian Elischer To: "Crist J. Clark" Cc: Archie Cobbs , Ruslan Ermilov , Garrett Wollman , net@FreeBSD.ORG Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() In-Reply-To: <20020218201311.V48401@blossom.cjclark.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I suggest that you get Archie to walk over to the next desk and ask Van Jacobson. There's nothing like getting it from the Horse's mouth (so to speak). On Mon, 18 Feb 2002, Crist J. Clark wrote: > On Mon, Feb 18, 2002 at 07:02:48PM -0800, Archie Cobbs wrote: > > > > Note that the RFC you are holding up as gospel talks about hosts > > on THE Internet, not hosts on some private test network. You assume > > too much by assuming that all hosts running FreeBSD are connected > > directly to the Internet. > > No, RFC1122 is a set of requirements for hosts implementing _the > Internet protocol._ [...] > I believe it is the intention of FreeBSD to have a working, compliant > IP implementation. > > > By your argument, the kernel should also block admin attempts to > > configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an > > interface. That would put a lot of people behind NAT boxes out of > > business. > > There are no requirements or references to RFC1918, 10.0.0.0/8, > 172.16.0.0/12, or 192.168.0.0/16 in RFC1122. > > > If someone intentionally configures their machine in an unconventional > > way, why automatically assume they are doing something wrong? > > > > My vote is to not have any special cases in the kernel for 127/8... > > rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing > > in the kernel. > > You definately want to at least block incoming 127.0.0.1 in the > kernel. Not doing so is a big security hole. Let's revisit that > discussion all over again, That is what ipfw is for. > > http://www.securityfocus.com/archive/1/166648 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 21: 0:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id E113937B417; Mon, 18 Feb 2002 21:00:54 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id UAA70142; Mon, 18 Feb 2002 20:44:22 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1J4hji92220; Mon, 18 Feb 2002 20:43:45 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202190443.g1J4hji92220@arch20m.dellroad.org> Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() In-Reply-To: <20020218201311.V48401@blossom.cjclark.org> "from Crist J. Clark at Feb 18, 2002 08:13:11 pm" To: "Crist J. Clark" Date: Mon, 18 Feb 2002 20:43:45 -0800 (PST) Cc: Archie Cobbs , Ruslan Ermilov , Garrett Wollman , net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Crist J. Clark writes: > No, RFC1122 is a set of requirements for hosts implementing _the > Internet protocol._ OK... > > By your argument, the kernel should also block admin attempts to > > configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an > > interface. That would put a lot of people behind NAT boxes out of > > business. > > There are no requirements or references to RFC1918, 10.0.0.0/8, > 172.16.0.0/12, or 192.168.0.0/16 in RFC1122. Obviously, because 1918 > 1122. But I don't understand your point. My point is that if it's a private network, you can do whatever you want -- standards that were created to make machines on the same network interoperate don't apply to X if X is on a separate network. There are real people with valid reasons for doing "weird" things, for testing or whatever, on private networks. We shouldn't make life hard for them. If your host sends a 127/8 packet, I'd say chances are better than 90% that you intentionally configured it to do so. Note that "normal" people will still get the standard configuration which prevents transmitting 127/8 packets, as it has for many years, without this new change. So I don't see what the conflict is here, or why this extra check, which adds complexity and confusion, is needed. > > If someone intentionally configures their machine in an unconventional > > way, why automatically assume they are doing something wrong? > > > > My vote is to not have any special cases in the kernel for 127/8... > > rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing > > in the kernel. > > You definately want to at least block incoming 127.0.0.1 in the > kernel. Not doing so is a big security hole. Let's revisit that > discussion all over again, > > http://www.securityfocus.com/archive/1/166648 Yes, of course. We're talking about sending, not receiving, packets though. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 21:30:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 979AA37B405 for ; Mon, 18 Feb 2002 21:30:02 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA70396; Mon, 18 Feb 2002 21:18:34 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1J5Hwn93991; Mon, 18 Feb 2002 21:17:58 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202190517.g1J5Hwn93991@arch20m.dellroad.org> Subject: Re: mpd-netgraph as VPN client to Cisco 2500 In-Reply-To: <20020219133856.J90345-100000@tardis.everard.bogus> "from Justin Hawkins at Feb 19, 2002 01:43:15 pm" To: Justin Hawkins Date: Mon, 18 Feb 2002 21:17:58 -0800 (PST) Cc: archie@dellroad.org, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Justin Hawkins writes: > > Yes, this is the same problem. Mpd and the kernel have both > > been modified since that posting: > > > > - mpd will disallow the 'fatal' scenario > > - the 'fatal' scenario is no longer fatal, i.e., instead of the > > kernel panicing, it will just return the 'deadlock avoided' > > error > > > > Unfortunately, there is no fix for this yet. However you can > > try one trick, which is to set up a host route to the remote > > IP address via your default gateway. I'm not sure if this will > > work but it might (please report success/failure if you try it). > > I had a quick try just then, but I'm on the 'wrong' side of the link, so I > managed to lock myself out for a while :-) > > Will try again later when I'm at home. > > Is this a hard thing to fix 'properly'? There was implied that some kernel > changes were needed in that previous post. One semi-proper fix is for mpd to install a host route as described above (assuming that works). But you won't get packets between the two PPTP hosts encrypted (if you're doing that); packets going to other hosts through the tunnel will be though. The kernel doesn't know how to look into a packet to see if it's already been encapsulated or not, and say "if this packet to X has been encapsulated, then send it this way, otherwise send it that way". It only routes based on destination IP address, and in the case we're talking about they dest. IP is the same in both encapsulated and non-encapsulated forms. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 22:21:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from sln01.megadat.com (exchange.megadat.com [195.22.224.154]) by hub.freebsd.org (Postfix) with ESMTP id 74A4D37B400 for ; Mon, 18 Feb 2002 22:21:12 -0800 (PST) Received: by sln01.megadat.com with Internet Mail Service (5.5.2653.19) id <15X2TRC8>; Tue, 19 Feb 2002 08:21:08 +0200 Message-ID: <8E9035BABCA0514EB0E574B6A7082FC305319B@sln01.megadat.com> From: Girnet Vladimir To: "'net@freebsd.org'" Subject: RE: network buffer problem Date: Tue, 19 Feb 2002 08:21:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="koi8-r" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >On Mon, 18 Feb 2002, Randy Bush wrote: > > If you have 4.5 and enough memory one option is to use > > MAXUSERS=0 and remove and "options NMBCLUSTERS" >> >> that's how it is now. >> >> before the latest builds, it uses to be MAXUSERS=96. maybe i should >> revert that. >> >> and i have to open the box sometime soon, so i'll shove a bunch of >> ram in it. >> >> randy >Yep, the autoscaling would have chosen MAXUSERS=64, so you've been running >with fewer NMBCLUSTERS than usual. OTOH, whatever extraordinary event >that caused you to run out of mbuf clusters that one time may very well >also run you out of mbuf clusters even at MAXUSERS=96; mbuf clusters tend >to get eaten pretty quickly. >Either way, adding ram sounds like a good idea. :) >Mike "Silby" Silbersack I found, that NO_MATTER what type of interface do you use on FreeBSD 4.5R. When DUMMYNET is enabled, and use some pipe rulez, ping with packets more than 4096 always got ping: sendto: No buffer space available Looking forward to your reply, Vladimir Girnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 22:38:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 700A937B400 for ; Mon, 18 Feb 2002 22:38:38 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1J6cTo24889; Mon, 18 Feb 2002 22:38:29 -0800 (PST) (envelope-from rizzo) Date: Mon, 18 Feb 2002 22:38:29 -0800 From: Luigi Rizzo To: Girnet Vladimir Cc: "'net@freebsd.org'" Subject: Re: network buffer problem Message-ID: <20020218223828.E24558@iguana.icir.org> References: <8E9035BABCA0514EB0E574B6A7082FC305319B@sln01.megadat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E9035BABCA0514EB0E574B6A7082FC305319B@sln01.megadat.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Feb 19, 2002 at 08:21:01AM +0200, Girnet Vladimir wrote: > > I found, that NO_MATTER what type of interface do you use on FreeBSD 4.5R. > When DUMMYNET is enabled, and use some pipe rulez, ping with packets more > than 4096 always got > ping: sendto: No buffer space available The "always" part is false. It depends on how the pipes are configured. Please show us your rules. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 23: 0:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from sln01.megadat.com (exchange.megadat.com [195.22.224.154]) by hub.freebsd.org (Postfix) with ESMTP id A68E537B405 for ; Mon, 18 Feb 2002 23:00:52 -0800 (PST) Received: by sln01.megadat.com with Internet Mail Service (5.5.2653.19) id <15X2TRFD>; Tue, 19 Feb 2002 09:00:49 +0200 Message-ID: <8E9035BABCA0514EB0E574B6A7082FC305319C@sln01.megadat.com> From: Girnet Vladimir To: "'net@freebsd.org'" Subject: RE: network buffer problem Date: Tue, 19 Feb 2002 09:00:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="koi8-r" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > -----Original Message----- > From: Luigi Rizzo [mailto:rizzo@icir.org] > Sent: Tuesday, February 19, 2002 8:38 AM > To: Girnet Vladimir > Cc: 'net@freebsd.org' > Subject: Re: network buffer problem > > > On Tue, Feb 19, 2002 at 08:21:01AM +0200, Girnet Vladimir wrote: > > > > I found, that NO_MATTER what type of interface do you use > on FreeBSD 4.5R. > > When DUMMYNET is enabled, and use some pipe rulez, ping > with packets more > > than 4096 always got > > ping: sendto: No buffer space available > > The "always" part is false. It depends on how the pipes are > configured. > Please show us your rules. > > luigi > OK, I use such rulez: ipfw pipe 10 config bw 33600bit/s queue 5K ipfw pipe 11 config bw 64Kbit/s queue 10K ipfw pipe 12 config bw 128Kbit/s queue 15K and, the rule - ipfw add 500 pipe XX ip from any to a.b.c.d/e via fxp0 out after issue "ping -s 8192 a.b.c.d" , I got one reply and one ping: sendto: No buffer space available. VG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 23:13:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id E607A37B404 for ; Mon, 18 Feb 2002 23:13:17 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1J7DBG25219; Mon, 18 Feb 2002 23:13:11 -0800 (PST) (envelope-from rizzo) Date: Mon, 18 Feb 2002 23:13:11 -0800 From: Luigi Rizzo To: Girnet Vladimir Cc: "'net@freebsd.org'" Subject: Re: network buffer problem Message-ID: <20020218231311.F24558@iguana.icir.org> References: <8E9035BABCA0514EB0E574B6A7082FC305319C@sln01.megadat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8E9035BABCA0514EB0E574B6A7082FC305319C@sln01.megadat.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Feb 19, 2002 at 09:00:42AM +0200, Girnet Vladimir wrote: > > > OK, I use such rulez: > ipfw pipe 10 config bw 33600bit/s queue 5K > ipfw pipe 11 config bw 64Kbit/s queue 10K > ipfw pipe 12 config bw 128Kbit/s queue 15K > > and, the rule - ipfw add 500 pipe XX ip from any to a.b.c.d/e via fxp0 out > > after issue "ping -s 8192 a.b.c.d" , I got one reply and one ping: sendto: > No buffer space available. and what do you expect ? You are trying to put 8192+ byte packets each second in a queue of 5k/10k/15k of size. The queue will quickly fill up and this is why you get those responses. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 18 23:36: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id B69AF37B400; Mon, 18 Feb 2002 23:35:56 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020219073556.YAWL1214.rwcrmhc54.attbi.com@blossom.cjclark.org>; Tue, 19 Feb 2002 07:35:56 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1J7Ztc38891; Mon, 18 Feb 2002 23:35:55 -0800 (PST) (envelope-from cjc) Date: Mon, 18 Feb 2002 23:35:54 -0800 From: "Crist J. Clark" To: Archie Cobbs Cc: Ruslan Ermilov , Garrett Wollman , net@FreeBSD.ORG Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() Message-ID: <20020218233554.X48401@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020218201311.V48401@blossom.cjclark.org> <200202190443.g1J4hji92220@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202190443.g1J4hji92220@arch20m.dellroad.org>; from archie@dellroad.org on Mon, Feb 18, 2002 at 08:43:45PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Feb 18, 2002 at 08:43:45PM -0800, Archie Cobbs wrote: > Crist J. Clark writes: > > No, RFC1122 is a set of requirements for hosts implementing _the > > Internet protocol._ > > OK... > > > > By your argument, the kernel should also block admin attempts to > > > configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an > > > interface. That would put a lot of people behind NAT boxes out of > > > business. > > > > There are no requirements or references to RFC1918, 10.0.0.0/8, > > 172.16.0.0/12, or 192.168.0.0/16 in RFC1122. > > Obviously, because 1918 > 1122. But I don't understand your point. :) Good point. I meant references to the subject matter of RFC1918. (Not that RFCs don't frequently reference other RFCs with numbers greater than theirs.) > My point is that if it's a private network, you can do whatever > you want -- standards that were created to make machines on the > same network interoperate don't apply to X if X is on a separate > network. You can always do what you want. No one says you have to use the Internet protocol to have your systems communicate. > There are real people with valid reasons for doing "weird" things, > for testing or whatever, on private networks. We shouldn't make > life hard for them. I have no problem making life easy for them. > If your host sends a 127/8 packet, I'd say chances are better than > 90% that you intentionally configured it to do so. Exactly. I don't think anyone has a problem with letting people configure their machines to do something pathological like sending loopback packets outside of a host. But a stock system, that is, one out of the box, should be compliant with the Standard and NOT do this. > Note that "normal" people will still get the standard configuration > which prevents transmitting 127/8 packets, as it has for many years, > without this new change. No, as I have had to repeat many times, a stock FreeBSD system did NOT behave properly in this respect. Take a stock FreeBSD system before the change, sniff the default route, and type, $ ping 127.0.0.2 And watch the loopback packets head out onto the wire. > So I don't see what the conflict is here, or why this extra check, > which adds complexity and confusion, is needed. I'd personally prefer someone just fix lo0 so that, $ ifconfig lo0 inet 127.0.0.1 Actually added the route, 127 127.0.0.1 UGSc 0 0 lo0 Like, $ ifconfig lo0 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 Would imply, but it doesn't. I started digging into the code to see about fixing this, but no one seems to be sure if this brokeness is intentional or not, so I never got too enthusiastic. Short of fixing this, blocking 127/8 in the kernel makes life a little harder for those who want to do exotic things on their own nets, but it does prevent the leakage. > > > If someone intentionally configures their machine in an unconventional > > > way, why automatically assume they are doing something wrong? > > > > > > My vote is to not have any special cases in the kernel for 127/8... > > > rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing > > > in the kernel. > > > > You definately want to at least block incoming 127.0.0.1 in the > > kernel. Not doing so is a big security hole. Let's revisit that > > discussion all over again, > > > > http://www.securityfocus.com/archive/1/166648 > > Yes, of course. We're talking about sending, not receiving, > packets though. But what's the point of sending them if systems can't receive them? If you need to remove five lines ip_input.c to get them in the machine, why not just remove the same five from ip_output.c too (not that in_canforward(), in.c, hasn't blocked loopback packets for even longer than the input and output routines). One more time, my opinion on the best balance between having a default compliant system, but something people can do whatever kinky things they want in the privacy of their own ASs is (and the coding for this is trivial... once I find where the heck the loopback isn't being configured): 1) Remove the ip_output.c code blocking 127/8 destinations once the lo0 puts a route for 127/8 into the routing table. 2) Put a sysctl(8) wrapper on the ip_input.c check, net.inet.ip.acceptloopback. 3) Put a sysctl(8) wrapper on the in_canforward() check and 127/8 as a source address, net.inet.ip.fwdloopback. Would anyone be terribly unhappy with that or something like that? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 0:26:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 2E18F37B400 for ; Tue, 19 Feb 2002 00:26:09 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g1J8PDQ50351; Tue, 19 Feb 2002 10:25:13 +0200 (EET) (envelope-from ru) Date: Tue, 19 Feb 2002 10:25:13 +0200 From: Ruslan Ermilov To: cjclark@alum.mit.edu Cc: Archie Cobbs , Garrett Wollman , net@FreeBSD.ORG Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() Message-ID: <20020219082513.GA49060@sunbay.com> References: <20020218201311.V48401@blossom.cjclark.org> <200202190443.g1J4hji92220@arch20m.dellroad.org> <20020218233554.X48401@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020218233554.X48401@blossom.cjclark.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Feb 18, 2002 at 11:35:54PM -0800, Crist J. Clark wrote: > On Mon, Feb 18, 2002 at 08:43:45PM -0800, Archie Cobbs wrote: > > Crist J. Clark writes: > > > No, RFC1122 is a set of requirements for hosts implementing _the > > > Internet protocol._ > > > > OK... > > > > > > By your argument, the kernel should also block admin attempts to > > > > configure RFC 1918 addresses (10.x.x.x, 192.168.x.x, etc.) on an > > > > interface. That would put a lot of people behind NAT boxes out of > > > > business. > > > > > > There are no requirements or references to RFC1918, 10.0.0.0/8, > > > 172.16.0.0/12, or 192.168.0.0/16 in RFC1122. > > > > Obviously, because 1918 > 1122. But I don't understand your point. > > :) Good point. I meant references to the subject matter of > RFC1918. (Not that RFCs don't frequently reference other RFCs with > numbers greater than theirs.) > > > My point is that if it's a private network, you can do whatever > > you want -- standards that were created to make machines on the > > same network interoperate don't apply to X if X is on a separate > > network. > > You can always do what you want. No one says you have to use the > Internet protocol to have your systems communicate. > > > There are real people with valid reasons for doing "weird" things, > > for testing or whatever, on private networks. We shouldn't make > > life hard for them. > > I have no problem making life easy for them. > > > If your host sends a 127/8 packet, I'd say chances are better than > > 90% that you intentionally configured it to do so. > > Exactly. I don't think anyone has a problem with letting people > configure their machines to do something pathological like sending > loopback packets outside of a host. But a stock system, that is, one > out of the box, should be compliant with the Standard and NOT do > this. > > > Note that "normal" people will still get the standard configuration > > which prevents transmitting 127/8 packets, as it has for many years, > > without this new change. > > No, as I have had to repeat many times, a stock FreeBSD system did NOT > behave properly in this respect. Take a stock FreeBSD system before > the change, sniff the default route, and type, > > $ ping 127.0.0.2 > > And watch the loopback packets head out onto the wire. > I fully agree. Or yet worse, ping -S 127.0.0.1 1.2.3.4 which could not be fixed by just adding a route to -net 127. > > So I don't see what the conflict is here, or why this extra check, > > which adds complexity and confusion, is needed. > > I'd personally prefer someone just fix lo0 so that, > > $ ifconfig lo0 inet 127.0.0.1 > > Actually added the route, > > 127 127.0.0.1 UGSc 0 0 lo0 > > Like, > > $ ifconfig lo0 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > Would imply, but it doesn't. I started digging into the code to see > about fixing this, but no one seems to be sure if this brokeness is > intentional or not, so I never got too enthusiastic. > Nothing is broken here, we only add ARP routes by default. > Short of fixing this, blocking 127/8 in the kernel makes life a little > harder for those who want to do exotic things on their own nets, but > it does prevent the leakage. > What people neglect to see and comment on is that 127/8 was already disallowed unconditionally by in_canforward() for about 15 years. > > > > If someone intentionally configures their machine in an unconventional > > > > way, why automatically assume they are doing something wrong? > > > > > > > > My vote is to not have any special cases in the kernel for 127/8... > > > > rc.conf, rc.network, rc.firewall, et. al. is fine, but nothing > > > > in the kernel. > > > > > > You definately want to at least block incoming 127.0.0.1 in the > > > kernel. Not doing so is a big security hole. Let's revisit that > > > discussion all over again, > > > > > > http://www.securityfocus.com/archive/1/166648 > > > > Yes, of course. We're talking about sending, not receiving, > > packets though. > > But what's the point of sending them if systems can't receive them? If > you need to remove five lines ip_input.c to get them in the machine, > why not just remove the same five from ip_output.c too (not that > in_canforward(), in.c, hasn't blocked loopback packets for even longer > than the input and output routines). > > One more time, my opinion on the best balance between having a default > compliant system, but something people can do whatever kinky things > they want in the privacy of their own ASs is (and the coding for > this is trivial... once I find where the heck the loopback isn't being > configured): > > 1) Remove the ip_output.c code blocking 127/8 destinations once the > lo0 puts a route for 127/8 into the routing table. > Not enough to block packets originated from 127/8, see above. > 2) Put a sysctl(8) wrapper on the ip_input.c check, > net.inet.ip.acceptloopback. > > 3) Put a sysctl(8) wrapper on the in_canforward() check and 127/8 as a > source address, net.inet.ip.fwdloopback. > I think all these three places should share a single sysctl. Just waiting for a good name for a sysctl and a good real-life example where using of 127/8 as either a source or destination IP address would be useful. Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 0:40:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id A1CF037B43C for ; Tue, 19 Feb 2002 00:39:25 -0800 (PST) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id g1J8mB308627; Tue, 19 Feb 2002 02:48:12 -0600 (CST) (envelope-from nick@rogness.net) Date: Tue, 19 Feb 2002 02:48:11 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Zviratko Cc: freebsd-net@FreeBSD.ORG Subject: Re: Ethernet bonding/load balancing on fbsd 4-stable In-Reply-To: <003501c1b7a8$4431d5f0$0500a8c0@notes> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 17 Feb 2002, Zviratko wrote: > [SNIP] > > I will try that, but I guess default route has precedence over ipfw. Not in the case of ipfw fwd. The routing decision seems to be made before ipfw fwd changes the packet. Nick Rogness - Don't mind me...I'm just sniffing your packets To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 1:57: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 5E6F837B405; Tue, 19 Feb 2002 01:57:01 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020219095700.VINQ2626.rwcrmhc51.attbi.com@blossom.cjclark.org>; Tue, 19 Feb 2002 09:57:00 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1J9v0n39507; Tue, 19 Feb 2002 01:57:00 -0800 (PST) (envelope-from cjc) Date: Tue, 19 Feb 2002 01:57:00 -0800 From: "Crist J. Clark" To: Ruslan Ermilov Cc: Archie Cobbs , Garrett Wollman , net@FreeBSD.ORG Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() Message-ID: <20020219015700.A48401@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020218201311.V48401@blossom.cjclark.org> <200202190443.g1J4hji92220@arch20m.dellroad.org> <20020218233554.X48401@blossom.cjclark.org> <20020219082513.GA49060@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020219082513.GA49060@sunbay.com>; from ru@FreeBSD.ORG on Tue, Feb 19, 2002 at 10:25:13AM +0200 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Feb 19, 2002 at 10:25:13AM +0200, Ruslan Ermilov wrote: > On Mon, Feb 18, 2002 at 11:35:54PM -0800, Crist J. Clark wrote: [snip] > > I'd personally prefer someone just fix lo0 so that, > > > > $ ifconfig lo0 inet 127.0.0.1 > > > > Actually added the route, > > > > 127 127.0.0.1 UGSc 0 0 lo0 > > > > Like, > > > > $ ifconfig lo0 > > lo0: flags=8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 > > > > Would imply, but it doesn't. I started digging into the code to see > > about fixing this, but no one seems to be sure if this brokeness is > > intentional or not, so I never got too enthusiastic. > > > Nothing is broken here, we only add ARP routes by default. OK, so that's a reason we do not get the route. If we stick with that as proper behavior, I would then assert that this, > > $ ifconfig lo0 > > lo0: flags=8049 mtu 16384 > > inet 127.0.0.1 netmask 0xff000000 ^^^^^^^^^^^^^^^^^^ Information is at worst incorrect, and at best merely misleading and useless. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 3:31:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp0.adl1.internode.on.net (smtp0.adl1.internode.on.net [203.16.214.194]) by hub.freebsd.org (Postfix) with ESMTP id 2042737B405 for ; Tue, 19 Feb 2002 03:31:43 -0800 (PST) Received: from tardis.everard.bogus (cu713.adelaide.adsl.on.net [150.101.236.205]) by smtp0.adl1.internode.on.net (8.11.6/8.11.6) with ESMTP id g1JBWQa66994; Tue, 19 Feb 2002 22:02:26 +1030 (CST) (envelope-from justin@hawkins.dropbear.id.au) Received: from localhost (jhawkins@localhost) by tardis.everard.bogus (8.11.6/8.11.6) with ESMTP id g1JBVVe09374; Tue, 19 Feb 2002 22:01:31 +1030 (CST) (envelope-from justin@hawkins.dropbear.id.au) X-Authentication-Warning: tardis.everard.bogus: jhawkins owned process doing -bs Date: Tue, 19 Feb 2002 22:01:31 +1030 (CST) From: Justin Hawkins X-X-Sender: jhawkins@tardis.everard.bogus To: Archie Cobbs Cc: Lars Eggert , Subject: Re: mpd-netgraph as VPN client to Cisco 2500 In-Reply-To: <200202190254.g1J2seh91729@arch20m.dellroad.org> Message-ID: <20020219220031.W9239-100000@tardis.everard.bogus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 18 Feb 2002, Archie Cobbs wrote: > Unfortunately, there is no fix for this yet. However you can > try one trick, which is to set up a host route to the remote > IP address via your default gateway. I'm not sure if this will > work but it might (please report success/failure if you try it). Very happy to report that this works. I'm a happy VPN camper. - Justin -- justin@hawkins.dropbear.id.au | "Don't sweat it -- http://hawkins.dropbear.id.au | it's only 1's and 0's" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 5:24: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by hub.freebsd.org (Postfix) with ESMTP id 01EB637B417 for ; Tue, 19 Feb 2002 05:24:01 -0800 (PST) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 719254316F for ; Tue, 19 Feb 2002 14:23:56 +0100 (CET) Received: from lmserv2.lab.it.uc3m.es (lmserv2.lab.it.uc3m.es [163.117.144.152]) by smtp03.uc3m.es (Postfix) with ESMTP id 9DFF999DE3 for ; Tue, 19 Feb 2002 14:23:54 +0100 (CET) Received: from it.uc3m.es (alacran.it.uc3m.es [163.117.139.44]) by lmserv2.lab.it.uc3m.es (8.9.3/8.9.3) with ESMTP id OAA01526 for ; Tue, 19 Feb 2002 14:23:53 +0100 Message-ID: <3C7251E9.4B250385@it.uc3m.es> Date: Tue, 19 Feb 2002 14:23:53 +0100 From: Juan Francisco Rodriguez Hervella X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Lista Subject: NAT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, I have been doing some perfomance tests using the standard NAT implementation for FreeBsd, and also using NAT-PT, with the KAME implementation. In throughput and delay terms, the results are much worse for NAT4. May that result be due to the overloading introduced by ALG in the standard implementation? Maybe it has to analyse the packets deeper?? Thanks in advance. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 6:12: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from star.rila.bg (star.rila.bg [194.141.1.32]) by hub.freebsd.org (Postfix) with ESMTP id 80A2137B404; Tue, 19 Feb 2002 06:11:53 -0800 (PST) Received: from star.rila.bg (vlady@localhost [127.0.0.1]) by star.rila.bg (8.11.4/8.11.4) with SMTP id g1JEBpA71302; Tue, 19 Feb 2002 16:11:51 +0200 (EET) (envelope-from vladimirt@rila.bg) Date: Tue, 19 Feb 2002 16:11:51 +0200 From: Vladimir Terziev To: freebsd-net@freebsd.org Cc: freebsd-mobile@freebsd.org Subject: D-Link DWL-A520 support Message-Id: <20020219161151.746e8658.vladimirt@rila.bg> X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.7; i386-unknown-freebsd4.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have a wireless PCI card D-Link DWL-A520. I haven't managed to find out any information about the support of this card by FreeBSD. 1. Does FreeBSD support D-Link DWL-A520 cards and if the answer is 'yes', via which driver? 2. The DWL-A520 card supports IEEE 802.11a standart for wireless communication and my ISP have Cisco Access Points, which support IEEE 802.11b standart. Will DWL-A520 card work with this Access Points or not? any ideas? Vladimir To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 6:54:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from star.rila.bg (star.rila.bg [194.141.1.32]) by hub.freebsd.org (Postfix) with ESMTP id 1A59F37B417; Tue, 19 Feb 2002 06:54:36 -0800 (PST) Received: from star.rila.bg (vlady@localhost [127.0.0.1]) by star.rila.bg (8.11.4/8.11.4) with SMTP id g1JEsZA71368; Tue, 19 Feb 2002 16:54:35 +0200 (EET) (envelope-from vlady@rila.bg) Date: Tue, 19 Feb 2002 16:54:34 +0200 From: Vladimir Terziev To: freebsd-net@freebsd.org Cc: freebsd-mobile@freebsd.org Subject: Re: D-Link DWL-A520 support Message-Id: <20020219165434.2a35b57d.vlady@rila.bg> In-Reply-To: <20020219161151.746e8658.vladimirt@rila.bg> References: <20020219161151.746e8658.vladimirt@rila.bg> X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.7; i386-unknown-freebsd4.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm going to make a correction. The model of the card is not DWL-A520, but DWL-520. In that case the question #2 is not more valid. I know it's answer. Sorry for the mistake! Vladimir On Tue, 19 Feb 2002 16:11:51 +0200 Vladimir Terziev wrote: > > Hi, > > I have a wireless PCI card D-Link DWL-A520. I haven't managed to find out any information about the support of this card by FreeBSD. > > 1. Does FreeBSD support D-Link DWL-A520 cards and if the answer is 'yes', via which driver? > 2. The DWL-A520 card supports IEEE 802.11a standart for wireless communication and my ISP have Cisco Access Points, which support IEEE 802.11b standart. Will DWL-A520 card work with this Access Points or not? > > any ideas? > > Vladimir > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 7:10:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by hub.freebsd.org (Postfix) with ESMTP id C258237B400 for ; Tue, 19 Feb 2002 07:10:49 -0800 (PST) Received: by hanoi.cronyx.ru id SAA35184 for freebsd-net@FreeBSD.ORG.checked; (8.9.3/vak/2.1) Tue, 19 Feb 2002 18:08:02 +0300 (MSK) (envelope-from rik@cronyx.ru) Received: from cronyx.ru by hanoi.cronyx.ru with ESMTP id SAA35084 for ; (8.9.3/vak/2.1) Tue, 19 Feb 2002 18:05:15 +0300 (MSK) (envelope-from rik@cronyx.ru) Message-ID: <3C726A93.6030901@cronyx.ru> Date: Tue, 19 Feb 2002 18:09:07 +0300 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG Subject: Bpf interface discussion Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi I found one problem. Current bpf interface allows to work only with one link layer type during interface life time, but some network drivers such as SPPP or NETGRAPH support many link layer types and link layer type could be changed during interface life time. I suggest to add new function to bpf interface like this: void bpfsetdlt (struct ifnet *ifp, u_int dlt) { struct bpf_if *bp; for (bp = bpf_iflist; bp != NULL; bp = bp->bif_next) { if (ifp == bp->bif_ifp) break; } if (!bp) return; bp->bif_dlt = dlt; } Best regards, Roman Kurakin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 7:21:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from mdv.dhs.org (mdv.xs4all.nl [213.84.209.48]) by hub.freebsd.org (Postfix) with ESMTP id 8C90937B423 for ; Tue, 19 Feb 2002 07:20:31 -0800 (PST) Received: (from root@localhost) by mdv.dhs.org (8.11.6/8.11.6) id g1JFKVw00733; Tue, 19 Feb 2002 16:20:31 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Received: from marcel.haveityourway.nl (marcel.mdv.int [192.168.1.3]) by mdv.dhs.org (8.11.6/8.11.6av) with ESMTP id g1JFKSZ00726; Tue, 19 Feb 2002 16:20:28 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Message-Id: <5.1.0.14.2.20020219154939.00bb52d8@outshine> X-Sender: mdevries@outshine X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Feb 2002 16:20:18 +0100 To: Luigi Rizzo From: Marcel de Vries Subject: Re: network buffer problem Cc: freebsd-net@freebsd.org In-Reply-To: <20020218172444.C22456@iguana.icir.org> References: <5.1.0.14.2.20020219013744.01dab338@outshine> <5.1.0.14.2.20020218224119.01faca88@outshine> <5.1.0.14.2.20020219013744.01dab338@outshine> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sirs, Thank you for the clarification about 'no buffer space available' . First of all I want to bring a new flavor of a test I did. Switched back using natd again, used ping -s 4096 www.bart.nl and off course a 128k/bits winamp stream from digitally imported ;-) to see what will happen. I was impressed about not one 'no buffer space available' was printed from ping. Look at the result. --- viaweb.vianetworks.nl ping statistics --- 1943 packets transmitted, 1939 packets received, 0% packet loss round-trip min/avg/max/stddev = 206.312/308.874/1370.284/191.811 ms Packet loss zero!!! Just by changing for ipnat back to using natd. Netstat -m 1/160/16768 mbufs in use (current/peak/max): 1 mbufs allocated to data 0/52/4192 mbuf clusters in use (current/peak/max) 144 Kbytes allocated to network (1% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines This test must make a point right? So using the ipdivert kernel implementations instead of ipnat from IPFILTER would make such a difference strange right? As you asked I would like to tell you about the result that will occur from no buffer space available. Packet loss, a slow connection and at the end in some cases 100% packet loss. I checked proctime (top) values when testing natd and it was eating up only 5 to 8% max. But it's not strange to me to see natd eating up 90% proctime after playing a intensive network game for about 4 hours. So something is still pretty wrong, but I don't know what to tweak or where to look. And natd only will recover from killing it and restarting the daemon. Tweaking recvspace or sendspace doesn't provide any solution it could screw up things even more in my case, didn't noticed any result from it. And as I can see we can put mpd on the sideline here because I think it's not causing this behaviour I'm I right? Or you think mpd is still the real pain in the ass generating all these troubles. Thanks in advance. Marcel At 17:24 18-02-2002 -0800, Luigi Rizzo wrote: >Ok, I have refrained from jumping into this thread but >the noise is increasing and I think some clarifications are >really necessary now. > >First of all: at various levels in the protocol stack, when >a packet cannot be forwarded to the next layer, more often >than not a ENOBUFS error is returned, which is propagated back >and then printed by perror() as "no buffer space available". > >One of this situations is when a dummynet pipe fills up. So the >test you report below with dummynet is telling absolutely nothing, >and certainly it does not show an error or configuration problem. > >Second: ping makes no use of tcp, so changing the >net.inet.tcp.{sendspace,recvspace} values has no [direct] impact >on the behaviour of your ping. > >What I suspect is happening is that mpd is saturating either >the divert socket queue (if you look in netinet/ip_divert.c, >this size is fixed to 64k), or the buffer on the "tun" interface. > >My understanding stops here... if you can summarise >what is the problem you were having initially, maybe i >can give more details. > > cheers > luigi > >On Tue, Feb 19, 2002 at 01:43:41AM +0100, Marcel de Vries wrote: > > > Well it could be mpd, but my good old friend ;-) tested a view things. > > > > First he used DUMMYNET to simulate his ADSL connection in a LAN > environment > > (100baseT) > > > > So he put in some packet loss and bandwidth limitations on his LAN and > > started pinging some hosts. He gets the same result of packets being lost > > with the message 'no buffer space available'. So in this way mpd wasn't > > used at all. This makes sense right. Could it be a configuration > problem or > > a really hard to think IP stack problem? > > > > He was very sure to me about not having these problems when using previous > > versions of FreeBSD before release 4.5. > > > > I don't know if that's true. > > And most of the IP traffic is no problem at all, things that definitely > cut > > the chase is to be generating a lot of UDP traffic like games do. This > > buffer seems to be running wild from that type of traffic. > > > > Tonight we lowered the following value's > > net.inet.tcp.sendspace: 16384 > > net.inet.tcp.recvspace: 16384 > > > > We started gaming like for more then a hour and no problems at all. > > But I think it was not long enough. > > > > But I hope this is useful: To recover from a total down of the internet > > connection, I need to restart mpd. Mpd was patched to start the following > > script when executed. > > > > #!/bin/sh > > INTERFACE=$1 > > PROTOCOL=$2 > > LOCAL=$3 > > REMOTE=$4 > > > > /sbin/route delete default > > /sbin/ifconfig ng0 mtu 1492 > > /sbin/route add default $REMOTE > > > > [ -x /sbin/ipnat ] && /sbin/ipnat -CF -f /etc/ipnat.conf && ipf -y && > > echo -n 'ipnat' > > > > /usr/bin/killall -HUP inetd > > /usr/bin/killall snort > > /bin/sleep 15 && /usr/local/bin/snort -i ng0 -p -o -D -c > > /usr/local/etc/snort/snort.conf & > > > > So what kind of buffer would hit hs max limit and will be reset by this > > action? > > not nmb thats for sure, when check netstat -m everything seems normal. > > > > You see the mtu option in the script, there where dutch people having > > trouble with there ADSL mxstream connection regarding with use of mpd on > > the FreeBSD box. 'No buffer' messages also appeared for those users not > for > > all. To alter the MTU helped in some cases. > > > > But I think that's not true, because when extremely using bandwidth like > > listen from streaming media and simultaneously pinging a host you could > > generate the message without any problems. > > > > And the message no buffer space available is not only a warning. It's > heavy > > packet loss and that's a thing nobody wants to deal with. > > > > I hope this will clear up a few things, and as I see more FreeBSD folks > > replying on this subject something must be wrong in the world of IP BSD ;-) > > > > Thanks, > > > > Marcel de Vries > > > > > > > > > > > > > > > > > > > > At 17:11 18-02-2002 +0000, Mike Silbersack wrote: > > > > > > >On Mon, 18 Feb 2002, Marcel de Vries wrote: > > > > > >> I really want to make a point, is it third party software 'mpd-3.7 > > >> Multi-link PPP daemon based on netgraph(4)' that is causing this or > is it > > >> something in the TCP/IP stack of BSD that is changed or the driver > > >support. > > >> > > >> We had these problems in 4.3, 4.4 and still in 4.5. > > >> From using mpd 3.1 to 3.7 nothing changed about our problem. > > >> > > >> I think it's an important notice why this is happening, because what if > > >> this is a real TCP/IP stack issue this would be very wrong and bad for > > >FreeBSD. > > >> > > >> But I'm still no expert so I have to leave this open for the Pro BSD > > >> users/developers. > > >> > > >> Bye, > > >> > > >> Marcel > > > > > >If your friend with a different network card is having similar problems, > > >I'd guess that mpd-netgraph is where you should start investigating. > > > > > >However, as I have never used mpd-netgraph, I have no idea what you should > > >be looking at. If by chance a mpd guru does not wander into this thread, > > >I suggest that you look through the old mailing list archives, see who > > >has had experience with it before, and drop them an e-mail. > > > > > >As far as your other question about natd slowing down... I believe that > > >someone was looking into that. If he manages to find the bottleneck and > > >fix it, I suspect you'll see the announcement here. > > > > > >Mike "Silby" Silbersack > > > > > > > > > > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > > >with "unsubscribe freebsd-net" in the body of the message > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 7:36:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from rod.inty.net (rod.inty.net [195.224.93.241]) by hub.freebsd.org (Postfix) with ESMTP id 98D4937B400 for ; Tue, 19 Feb 2002 07:36:33 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by rod.inty.net (8.11.3/8.11.3) with ESMTP id g1JFaKD82607 for ; Tue, 19 Feb 2002 15:36:23 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g1JFaDYl031325 for ; Tue, 19 Feb 2002 15:36:13 GMT From: "Tariq Rashid" To: Subject: RE: network buffer problem -/- natd Date: Tue, 19 Feb 2002 15:40:06 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5.1.0.14.2.20020219154939.00bb52d8@outshine> X-Sender-IP: 10.0.1.156 X-INT-DeliveryDone: g1JFaDYl031325 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 54031 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org i too am currently looking into natd - it seems to eat more cpu as the number of connections it handles goes uip - not just the throughput. - i'm not an expert but truss, strace and grof show that most of the time is spent in sendto() ... ... i find this odd becuase recvfrom seems not to be so intensive. ps - can anyone tell me if the following assumption is correct: * if gprof, strace, etc show most of the time spent in sendto() then it immediately follows that this is what is using CPU time? * i know its a bit off topic but i could make a syscall which simpy sleeps, so shows up as taking time but isn;t doing much really? am i right? intY has automatically scanned this email with Sophos Anti-Virus (www.inty.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 9: 0:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 7405837B404; Tue, 19 Feb 2002 09:00:07 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id IAA74177; Tue, 19 Feb 2002 08:45:16 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1JGidW95983; Tue, 19 Feb 2002 08:44:39 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202191644.g1JGidW95983@arch20m.dellroad.org> Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() In-Reply-To: <20020219082513.GA49060@sunbay.com> "from Ruslan Ermilov at Feb 19, 2002 10:25:13 am" To: Ruslan Ermilov Date: Tue, 19 Feb 2002 08:44:38 -0800 (PST) Cc: cjclark@alum.mit.edu, Archie Cobbs , Garrett Wollman , net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ruslan Ermilov writes: > > > Note that "normal" people will still get the standard configuration > > > which prevents transmitting 127/8 packets, as it has for many years, > > > without this new change. > > > > No, as I have had to repeat many times, a stock FreeBSD system did NOT > > behave properly in this respect. Take a stock FreeBSD system before > > the change, sniff the default route, and type, > > > > $ ping 127.0.0.2 > > > > And watch the loopback packets head out onto the wire. Yes this is broken.. but only IF you are using the normal configuration where 127.0.0.1/8 is configured on lo0. So the bug is in the kernel routing to the 127/8 network, which should be via lo0 instead of the default route. The fact that 127/8 is normally configured on lo0 is a policy matter. > I fully agree. Or yet worse, > > ping -S 127.0.0.1 1.2.3.4 > > which could not be fixed by just adding a route to -net 127. Wait!! If I specify "-S 127.0.0.1" then that's what I want! Besides, you could use "-S 0.1.2.3" or any of millions of other "illegal" source IP addresses -- do we need a special kernel hack to prevent those as well?? "-S" means "Kernel, use this source address and DON'T ARGUE!" > > But what's the point of sending them if systems can't receive them? If > > you need to remove five lines ip_input.c to get them in the machine, > > why not just remove the same five from ip_output.c too (not that > > in_canforward(), in.c, hasn't blocked loopback packets for even longer > > than the input and output routines). Here's one example: you are probing other machines for broken firewalls. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 9:26:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id BF2DF37B402 for ; Tue, 19 Feb 2002 09:26:51 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id 4D465E5008; Mon, 18 Feb 2002 17:00:18 -0500 (EST) Date: Mon, 18 Feb 2002 17:00:18 -0500 From: Richard A Steenbergen To: Sean Chittenden Cc: freebsd-net@freebsd.org Subject: Re: Ethernet bonding/load balancing on fbsd 4-stable Message-ID: <20020218220017.GQ413@overlord.e-gerbil.net> References: <003501c1b7a8$4431d5f0$0500a8c0@notes> <20020217205620.GN413@overlord.e-gerbil.net> <20020218134405.A6619@ninja1.internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020218134405.A6619@ninja1.internal> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Feb 18, 2002 at 01:44:05PM -0800, Sean Chittenden wrote: > > The only real "cisco only" protocol is the PAgP (Port Aggregation > > Protocol) which is essentially just a FEC auto-negiotation protocol they > > made up. AFAIK noone other then Cisco actually implements this though. > > Don't forget to add EIGRP and CDP to the list. -sc Woops, I ment the "cisco only"isms related to link aggregation. One could list Cisco proprietary protocols that don't work with other vendors for days and still not get them all. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 9:30: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 0131F37B404 for ; Tue, 19 Feb 2002 09:30:03 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id JAA74351; Tue, 19 Feb 2002 09:17:26 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1JHGn796147; Tue, 19 Feb 2002 09:16:49 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202191716.g1JHGn796147@arch20m.dellroad.org> Subject: Re: mpd-netgraph as VPN client to Cisco 2500 In-Reply-To: <20020219220031.W9239-100000@tardis.everard.bogus> "from Justin Hawkins at Feb 19, 2002 10:01:31 pm" To: Justin Hawkins Date: Tue, 19 Feb 2002 09:16:49 -0800 (PST) Cc: Archie Cobbs , Lars Eggert , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Justin Hawkins writes: > > Unfortunately, there is no fix for this yet. However you can > > try one trick, which is to set up a host route to the remote > > IP address via your default gateway. I'm not sure if this will > > work but it might (please report success/failure if you try it). > > Very happy to report that this works. I'm a happy VPN camper. Glad to hear that.. thanks for the report. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 9:34:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 7B52637B419 for ; Tue, 19 Feb 2002 09:34:30 -0800 (PST) Received: from isi.edu (v8hi0fxsy9f0ulvk@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g1JHYPQ24216; Tue, 19 Feb 2002 09:34:25 -0800 (PST) Message-ID: <3C728CA0.70809@isi.edu> Date: Tue, 19 Feb 2002 09:34:24 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020213 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Archie Cobbs Cc: Justin Hawkins , freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph as VPN client to Cisco 2500 References: <200202191716.g1JHGn796147@arch20m.dellroad.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090005040500030607080508" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms090005040500030607080508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Justin, glad this worked for you! How did you stop the Cisco box from stupidly trying to hand its own IP address to the clients over and over? I don't even get past negotiation, since the Cisco won't hand out any other addresses... (It also doesn't help that the box isn't under my direct administration, but if I could tell the support people "go look at page X in Cisco manual Y", that'd probably allow them to fix it.) Thanks, Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms090005040500030607080508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDIxOTE3MzQyNFowIwYJKoZIhvcNAQkEMRYEFDVw+IjjxxlHTxSflmLup5LQlW8eMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAtYaABxUiQRy0koA/Uli42lRHq79uJranNHXTBUfs6oHm9wtE7iDB7E1VkkJO+67pJ mlzxcf7+WOR6C1ma2WOOOANiKzg2PSoNaaOUsBCQ85RgFYRZSMKxPM9QFo5vn5jlrUoG89mg aPFhzNoHLtaKTTICK9StQFFZH70S96gq6gAAAAAAAA== --------------ms090005040500030607080508-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 10:24:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from mdv.dhs.org (mdv.xs4all.nl [213.84.209.48]) by hub.freebsd.org (Postfix) with ESMTP id 6759D37B400 for ; Tue, 19 Feb 2002 10:24:17 -0800 (PST) Received: (from root@localhost) by mdv.dhs.org (8.11.6/8.11.6) id g1JIOGB02673 for freebsd-net@freebsd.org; Tue, 19 Feb 2002 19:24:16 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Received: from marcel.haveityourway.nl (marcel.mdv.int [192.168.1.3]) by mdv.dhs.org (8.11.6/8.11.6av) with ESMTP id g1JIODZ02666 for ; Tue, 19 Feb 2002 19:24:13 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Message-Id: <5.1.0.14.2.20020219192110.01f45e48@outshine> X-Sender: mdevries@outshine X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Feb 2002 19:24:09 +0100 To: freebsd-net@freebsd.org From: Marcel de Vries Subject: RE: network buffer problem -/- natd In-Reply-To: References: <5.1.0.14.2.20020219154939.00bb52d8@outshine> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org After 4 hours of pinging and listening to a shoutcast stream natd rised to his state of eating 34% proctime (top) Connection timed out, did a restart of mpd and everything is running normal agian. Bugs me. Grtz, Marcel At 15:40 19-02-2002 +0000, you wrote: > i too am currently looking into natd - it seems to eat more cpu as the >number of connections it handles goes uip - not just the throughput. > > - i'm not an expert but truss, strace and grof show that most of the time >is spent in sendto() ... > > ... i find this odd becuase recvfrom seems not to be so intensive. > > ps - can anyone tell me if the following assumption is correct: > > * if gprof, strace, etc show most of the time spent in sendto() > then it immediately follows that this is what is using > CPU time? > > > * i know its a bit off topic but i could make a syscall which > simpy sleeps, > so shows up as taking time but isn;t doing much really? > >am i right? > > >intY has automatically scanned this email with Sophos Anti-Virus >(www.inty.com) > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 10:44:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 5AF6537B416 for ; Tue, 19 Feb 2002 10:44:36 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1JIiWb31529; Tue, 19 Feb 2002 10:44:32 -0800 (PST) (envelope-from rizzo) Date: Tue, 19 Feb 2002 10:44:32 -0800 From: Luigi Rizzo To: Marcel de Vries Cc: freebsd-net@FreeBSD.ORG Subject: Re: network buffer problem -/- natd Message-ID: <20020219104432.A31233@iguana.icir.org> References: <5.1.0.14.2.20020219154939.00bb52d8@outshine> <5.1.0.14.2.20020219192110.01f45e48@outshine> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020219192110.01f45e48@outshine> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Feb 19, 2002 at 07:24:09PM +0100, Marcel de Vries wrote: > After 4 hours of pinging and listening to a shoutcast stream natd rised to > his state of eating 34% proctime (top) > Connection timed out, did a restart of mpd and everything is running normal > agian. somewhat unrelated, but... why are you using both mpd and natd ? wouldn't mpd do the address translation same as ppp does ? Anyways the performance problem could be easily explained by a poor implementation of the session lookup in libalias -- e.g. resulting in heavy scanning of long lists for each received packet, or things like that. From the (almost non-existent) comments in the libalias code it is not immediate to understand what is the underlying data structure -- maybe a hash table followed by lists -- nor if there are variables that one could monitor to see how the lookup strategy works (e.g. number of entries, average depth of the lists, etc. > > - i'm not an expert but truss, strace and grof show that most of the time > >is spent in sendto() ... This is probably related to a problem in natd which was fixed by Ruslan not long ago in current, and did not make it in RELENG_4_5 (it is in -stable though). The bug was that natd looped around a select which would always return the socket as writable, and it would keep retrying a sendto() until successful. The fix is to drop the packet when sendto fails, and rely on retransmissions instead. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 10:45:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id E122037B41E for ; Tue, 19 Feb 2002 10:45:03 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id KAA74727; Tue, 19 Feb 2002 10:25:42 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1JIP4O96413; Tue, 19 Feb 2002 10:25:04 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202191825.g1JIP4O96413@arch20m.dellroad.org> Subject: Re: mpd-netgraph as VPN client to Cisco 2500 In-Reply-To: <3C728CA0.70809@isi.edu> "from Lars Eggert at Feb 19, 2002 09:34:24 am" To: Lars Eggert Date: Tue, 19 Feb 2002 10:25:04 -0800 (PST) Cc: Archie Cobbs , Justin Hawkins , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lars Eggert writes: > How did you stop the Cisco box from stupidly trying to hand its own IP > address to the clients over and over? I don't even get past negotiation, > since the Cisco won't hand out any other addresses... (It also doesn't > help that the box isn't under my direct administration, but if I could > tell the support people "go look at page X in Cisco manual Y", that'd > probably allow them to fix it.) Newer versions of mpd will not even finish negotiation with a box that uses the same IP address inside & out... this was added as a safety check.. to disable this behavior and allow such negotiation, apply the patch below. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: ipcp.c =================================================================== RCS file: /home/cvs/archie/mpd/src/ipcp.c,v retrieving revision 1.3 retrieving revision 1.2 diff -u -r1.3 -r1.2 --- ipcp.c 2001/12/16 03:47:25 1.3 +++ ipcp.c 2001/04/12 17:03:31 1.2 @@ -19,7 +19,6 @@ #include "custom.h" #include "msg.h" #include "ngfunc.h" -#include "pptp.h" #include #include @@ -608,7 +607,7 @@ switch (mode) { case MODE_REQ: if (!IpAddrInRange(&ipcp->conf.peer_allow, *ip) || !ip->s_addr) { -nak_ip: if (ipcp->peer_addr.s_addr == 0) + if (ipcp->peer_addr.s_addr == 0) Log(LG_IPCP, (" %s", "no IP address available for peer!")); if (Enabled(&ipcp->conf.options, IPCP_CONF_PRETENDIP)) { Log(LG_IPCP, (" pretending that %s is OK, will ignore", @@ -621,17 +620,6 @@ Log(LG_IPCP, (" NAKing with %s", inet_ntoa(*ip))); FsmNak(fp, opt); break; - } - if (bund->links[0]->phys->type == &gPptpPhysType) { - struct in_addr pip; - - lnk = bund->links[0]; - pip = PptpGetPeerIp(); - if (ip->s_addr == pip.s_addr) { - Log(LG_IPCP, - (" Same as PPTP IP; would cause routing loop")); - goto nak_ip; - } } Log(LG_IPCP, (" %s is OK", inet_ntoa(*ip))); ipcp->peer_addr = *ip; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 10:55:41 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 7EEE737B417 for ; Tue, 19 Feb 2002 10:55:33 -0800 (PST) Received: from isi.edu (xzltpv6y2lyqm4a4@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g1JItTQ15762; Tue, 19 Feb 2002 10:55:29 -0800 (PST) Message-ID: <3C729FA0.9060700@isi.edu> Date: Tue, 19 Feb 2002 10:55:28 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020213 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: Archie Cobbs Cc: Justin Hawkins , freebsd-net@FreeBSD.ORG Subject: Re: mpd-netgraph as VPN client to Cisco 2500 References: <200202191825.g1JIP4O96413@arch20m.dellroad.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040908030607000100010609" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms040908030607000100010609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archie, Archie Cobbs wrote: > Newer versions of mpd will not even finish negotiation with a box > that uses the same IP address inside & out... this was added as a > safety check.. to disable this behavior and allow such negotiation, > apply the patch below. you put created that patch in repsonse to my email back then about the encapsulation loop :-) (and it works great in preventing the kernel panic). The problem with the Cisco we have here is that even when it gets a NAK during negotiation (when offering its IP address to mpd), it will stupidly retry with the same address over and over, until negotiation fails. Justin doesn't seem to have this problem; in the log he posted, his Cisco box gives him a valid IP address after the NAK. That's why I'm interested in how he made it do that. If I take out the NAK patch, I believe I'll see kernel panics again; or were you saying that adding a host route can prevent this? Thanks, Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms040908030607000100010609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDIxOTE4NTUyOFowIwYJKoZIhvcNAQkEMRYEFJTBMAErK2CMO4lgxIFdeWhc0FqmMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYCQ5Rr8uETDbJrPzVcdbs4Ov7Mn4Z19mfhIjkhjHhfKJ44fnEbC0hDDMk+kdDEg8P24 Jv0nJvsI0JzvxyupSg/eK8L94+mfpYeOnIcW4bIw3DwW6LELeJVdV9h4FTB6/EmmJK/05KXt 5WVk2cgenDfSG3pkGxxwnMO0V3gEFFufswAAAAAAAA== --------------ms040908030607000100010609-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 11:15: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id EB26037B405 for ; Tue, 19 Feb 2002 11:15:02 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id LAA74981; Tue, 19 Feb 2002 11:04:33 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1JJ3tD96565; Tue, 19 Feb 2002 11:03:55 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202191903.g1JJ3tD96565@arch20m.dellroad.org> Subject: Re: mpd-netgraph as VPN client to Cisco 2500 In-Reply-To: <3C729FA0.9060700@isi.edu> "from Lars Eggert at Feb 19, 2002 10:55:28 am" To: Lars Eggert Date: Tue, 19 Feb 2002 11:03:55 -0800 (PST) Cc: Archie Cobbs , Justin Hawkins , freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Lars Eggert writes: > If I take out the NAK patch, I believe I'll see kernel panics again; or > were you saying that adding a host route can prevent this? Adding a host route should prevent the kernel panic. However, there was also a fix made to ng_ksocket(4) that eliminates the panic from ever happening (the offending packet is simply dropped with EDEADLK). So, the first step is one should update their kernel to prevent the panic. Once this is done, you can worry about how to actually make it work (with the host route and mpd mods). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 11:40:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id BC14237B402 for ; Tue, 19 Feb 2002 11:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020219194008.KBIZ1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Tue, 19 Feb 2002 19:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA58300; Tue, 19 Feb 2002 11:30:08 -0800 (PST) Date: Tue, 19 Feb 2002 11:30:07 -0800 (PST) From: Julian Elischer To: Juan Francisco Rodriguez Hervella Cc: Lista Subject: Re: NAT In-Reply-To: <3C7251E9.4B250385@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org what's NAT4? On Tue, 19 Feb 2002, Juan Francisco Rodriguez Hervella wrote: > Hello, > I have been doing some perfomance tests using the standard NAT > implementation for FreeBsd, and also using NAT-PT, with the KAME > implementation. > > In throughput and delay terms, the results are much worse for NAT4. > > May that result be due to the overloading introduced by ALG in the > standard implementation? Maybe it has to analyse the packets deeper?? > > Thanks in advance. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 12:20:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mdv.dhs.org (mdv.xs4all.nl [213.84.209.48]) by hub.freebsd.org (Postfix) with ESMTP id 9757837B402 for ; Tue, 19 Feb 2002 12:20:02 -0800 (PST) Received: (from root@localhost) by mdv.dhs.org (8.11.6/8.11.6) id g1JKK2V03836; Tue, 19 Feb 2002 21:20:02 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Received: from marcel.haveityourway.nl (marcel.mdv.int [192.168.1.3]) by mdv.dhs.org (8.11.6/8.11.6av) with ESMTP id g1JKJxZ03822; Tue, 19 Feb 2002 21:19:59 +0100 (CET) (envelope-from mdevries@haveityourway.nl) Message-Id: <5.1.0.14.2.20020219204129.00b5aa20@outshine> X-Sender: mdevries@outshine X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Feb 2002 21:19:46 +0100 To: Luigi Rizzo From: Marcel de Vries Subject: Re: network buffer problem -/- natd Cc: freebsd-net@freebsd.org In-Reply-To: <20020219104432.A31233@iguana.icir.org> References: <5.1.0.14.2.20020219192110.01f45e48@outshine> <5.1.0.14.2.20020219154939.00bb52d8@outshine> <5.1.0.14.2.20020219192110.01f45e48@outshine> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, Unrelated but for everybody unknown with mpd: FYI: DESCRIPTION mpd is a user mode PPP daemon using the netgraph(4) networking system. By using Netgraph, mpd combines the robustness and flexibility of a user- mode PPP implementation with the speed and reliability of kernel-mode packet forwarding. All PPP negotiation is handled in user level code, while all data intensive operations such as encryption, compression, and multi-link framing are handled strictly in the kernel. Mpd supports sev- eral link layer types, a fully event-driven modem chat scripting lan- guage, and other features. -snip- As far as I know mpd still cannot manage IP masquerading :) I use mpd to setup a PPTP (gre encapsulation) connection between interface ep0 (public) and my Alcatel ADSL modem. Don't ask me why but it's the concept of a BIG telecom company we all love to hate in the Netherlands. KPN TELECOM. And most of the people use mpd in the Netherlands and find it a comfortable and more stable solution I think. Well I guess mxstream ADSL works fine in most cases. These other paid OS types like w9x/me, winnt, win2k/XP all can handle PPTP VPN connections only with the correct DUN version for the early win versions that is. And almost every ordinary household who owns a computer is running one of the disgusting platforms mentioned above. And I think it have to work great in combination with ADSL or else they could flush there concept down the drains. Because mxstream wants to attract and provide internet for this sector. There where a lot problems in the beginning of mxstream but they changed there design to make it more useful for a internet user. So as most of the BSD community who are in lucky circumstances to own a ADSL connection would love to use FreeBSD as a router for the rest of the network. I know more people are dealing with packet loss and losing there connection in use with mxstream ADSL. People that really use there internet extensive that is ;-) But how can we fix these problems or even look to a better alternative? Grtz, Marcel At 10:44 19-02-2002 -0800, Luigi Rizzo wrote: >On Tue, Feb 19, 2002 at 07:24:09PM +0100, Marcel de Vries wrote: > > After 4 hours of pinging and listening to a shoutcast stream natd rised to > > his state of eating 34% proctime (top) > > Connection timed out, did a restart of mpd and everything is running > normal > > agian. > >somewhat unrelated, but... why are you using both mpd and natd ? >wouldn't mpd do the address translation same as ppp does ? > >Anyways the performance problem could be easily explained by >a poor implementation of the session lookup in libalias -- e.g. >resulting in heavy scanning of long lists for each received packet, >or things like that. > > From the (almost non-existent) comments in the libalias code it is >not immediate to understand what is the underlying data structure >-- maybe a hash table followed by lists -- nor if there are variables >that one could monitor to see how the lookup strategy works (e.g. >number of entries, average depth of the lists, etc. > > > > - i'm not an expert but truss, strace and grof show that most of the time > > >is spent in sendto() ... > >This is probably related to a problem in natd which was fixed by >Ruslan not long ago in current, and did not make it in RELENG_4_5 >(it is in -stable though). > >The bug was that natd looped around a select which would always >return the socket as writable, and it would keep retrying a sendto() >until successful. >The fix is to drop the packet when sendto fails, and rely on retransmissions >instead. > > cheers > luigi > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 18:55:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 4CE6F37B417 for ; Tue, 19 Feb 2002 18:55:44 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020220025544.WVAT1214.rwcrmhc54.attbi.com@blossom.cjclark.org> for ; Wed, 20 Feb 2002 02:55:44 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1K2thA24011 for net@freebsd.org; Tue, 19 Feb 2002 18:55:43 -0800 (PST) (envelope-from cjc) Date: Tue, 19 Feb 2002 18:55:43 -0800 From: "Crist J. Clark" To: net@freebsd.org Subject: Odd Rule in rc.firewall6 Message-ID: <20020219185543.T48401@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was wondering if anyone here could explain this to me: ############ # Only in rare cases do you want to change these rules # ${fw6cmd} add 100 pass all from any to any via lo0 # # ND # # DAD ${fw6cmd} add pass ipv6-icmp from ff02::/16 to :: ${fw6cmd} add pass ipv6-icmp from :: to ff02::/16 I don't understand that first IPV6-ICMP rule. RFC2373 says, 2.5.2 The Unspecified Address The address 0:0:0:0:0:0:0:0 is called the unspecified address. ... The unspecified address must not be used as the destination address of IPv6 packets or in IPv6 Routing Headers. That rule sure looks like it is explicitly passing invalid traffic. Unless someone can enlighten my ignorance here, I'm going to nuke that rule. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 20:59: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from cheer.mahoroba.org (flets19-017.kamome.or.jp [218.45.19.17]) by hub.freebsd.org (Postfix) with ESMTP id 0BD7E37B404 for ; Tue, 19 Feb 2002 20:58:55 -0800 (PST) Received: from localhost (IDENT:ygQqQvT/Ibk3DjzxWFhT0xUBVlfE3Bg4aEnAxpFX4qg6lHyqqIqYGPBduGTwaj4w@localhost [IPv6:::1]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.2/8.12.2) with ESMTP/inet6 id g1K4vLKb094317 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Feb 2002 13:57:21 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 20 Feb 2002 13:57:21 +0900 Message-ID: From: Hajimu UMEMOTO To: cjclark@alum.mit.edu Cc: net@freebsd.org Subject: Re: Odd Rule in rc.firewall6 In-Reply-To: <20020219185543.T48401@blossom.cjclark.org> References: <20020219185543.T48401@blossom.cjclark.org> User-Agent: xcite1.38> Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.5-RELEASE MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Tue, 19 Feb 2002 18:55:43 -0800 >>>>> "Crist J. Clark" said: crist.clark> I was wondering if anyone here could explain this to me: crist.clark> # DAD crist.clark> ${fw6cmd} add pass ipv6-icmp from ff02::/16 to :: crist.clark> ${fw6cmd} add pass ipv6-icmp from :: to ff02::/16 crist.clark> I don't understand that first IPV6-ICMP rule. RFC2373 says, crist.clark> 2.5.2 The Unspecified Address crist.clark> The address 0:0:0:0:0:0:0:0 is called the unspecified address. crist.clark> ... crist.clark> The unspecified address must not be used as the destination address crist.clark> of IPv6 packets or in IPv6 Routing Headers. crist.clark> That rule sure looks like it is explicitly passing invalid crist.clark> traffic. Unless someone can enlighten my ignorance here, I'm going to crist.clark> nuke that rule. RFC2461 4.3. says: Source Address Either an address assigned to the interface from which this message is sent or (if Duplicate Address Detection is in progress [ADDRCONF]) the unspecified address. So, ${fw6cmd} add pass ipv6-icmp from :: to ff02::/16 must be retained. But, it seems ${fw6cmd} add pass ipv6-icmp from ff02::/16 to :: is not required. When I wrote this, maybe I might confused. But, I cannot test it just now. I'll test it tonight. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 19 22:58: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from garfield.bmk.com.au (bmkind.lnk.telstra.net [139.130.51.118]) by hub.freebsd.org (Postfix) with ESMTP id 6A64D37B400 for ; Tue, 19 Feb 2002 22:58:05 -0800 (PST) Received: from localhost (brendan@localhost) by garfield.bmk.com.au (8.9.3/8.9.3) with SMTP id RAA29805 for ; Wed, 20 Feb 2002 17:58:02 +1100 (EST) (envelope-from brendan@bmk.com.au) Date: Wed, 20 Feb 2002 17:58:02 +1100 (EST) From: Brendan Kosowski To: FreeBSD Networking Subject: Can't see "ed0" interface when I run pppd with defaultroute option Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, My ed0 interface has been set up using a typical LAN style IP address of 192.168.1.100. When I run pppd (connecting to my ISP) with the defaultroute option, I can't access services on my own ed0 IP address. Eg. "telnet 192.168.1.100 25" just hangs (instead of giving me the ESMTP prompt). If I delete the default route, I can see services on my own ed0 IP address again. It is almost as if the Default route has precedence over my own ed0 interface. Can anyone help with this problem ??? Thanks, Brendan... ------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 0:53:57 2002 Delivered-To: freebsd-net@freebsd.org Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by hub.freebsd.org (Postfix) with SMTP id 7CAFA37B402 for ; Wed, 20 Feb 2002 00:53:55 -0800 (PST) Message-ID: <20020220085354.5237.qmail@web11606.mail.yahoo.com> Received: from [202.94.3.60] by web11606.mail.yahoo.com via HTTP; Wed, 20 Feb 2002 00:53:54 PST Date: Wed, 20 Feb 2002 00:53:54 -0800 (PST) From: tang hongbin Subject: connection win2000 to racoon on freebsd4.3 To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear all; I tried to build VPN tunnels between win2000 professional and FreeBSD4.2 with RACOON as IKE negotiator. The procedures were described as following: 1: I set up local policies on win2000. 2: I added rules into racoon.conf and/or psk.txt. when I sended messages from win2000 to BSD VPN server, RACOON met problems at phase 2 and printed the following infomation: .... isakmp-info_recv_n():776 unknown notify message.... .. If you has succeeded in connecting win2000 and RACOON on FressBSD, please give your setup procedure in detail. Thank you bill.tang hongbintang@yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 0:59:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns.mmk.ru (ns1.mmk.ru [195.54.3.19]) by hub.freebsd.org (Postfix) with ESMTP id 773CA37B404 for ; Wed, 20 Feb 2002 00:59:18 -0800 (PST) Received: from antivirus.mmk.ru (sinful [161.8.100.3]) by ns.mmk.ru (8.11.6/8.11.6) with ESMTP id g1K8wss61886; Wed, 20 Feb 2002 13:58:54 +0500 (YEKT) Received: from wall.mmk.ru (localhost [127.0.0.1]) by antivirus.mmk.ru (8.11.6/8.11.6) with ESMTP id g1K8w2q11152; Wed, 20 Feb 2002 13:58:02 +0500 (ESK) Received: from wall (fw.dim.ru [1.1.1.2]) by wall.mmk.ru (8.11.6/8.11.6) with SMTP id g1K8tc800634; Wed, 20 Feb 2002 13:55:38 +0500 (YEKT) Message-ID: <01ec01c1b9ed$8da71690$02010101@wall> From: "Dmitry A. Bondareff" To: "tang hongbin" , References: <20020220085354.5237.qmail@web11606.mail.yahoo.com> Subject: Re: connection win2000 to racoon on freebsd4.3 Date: Wed, 20 Feb 2002 14:04:07 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Look here: http://www.daemonnews.org/200101/ipsec-howto.html Regards, Dmitry. ----- Original Message ----- From: "tang hongbin" To: Sent: Wednesday, February 20, 2002 1:53 PM Subject: connection win2000 to racoon on freebsd4.3 > Dear all; > > I tried to build VPN tunnels between win2000 > professional and FreeBSD4.2 with RACOON as IKE > negotiator. The procedures were described as > following: > > 1: I set up local policies on win2000. > 2: I added rules into racoon.conf and/or psk.txt. > > when I sended messages from win2000 to BSD VPN server, > RACOON met problems at phase 2 and printed the > following infomation: > .... > isakmp-info_recv_n():776 unknown notify message.... > .. > > If you has succeeded in connecting win2000 and RACOON > on FressBSD, please give your setup procedure in > detail. > > Thank you > > bill.tang > hongbintang@yahoo.com > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 1: 2: 8 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by hub.freebsd.org (Postfix) with ESMTP id 7BEC537B405 for ; Wed, 20 Feb 2002 01:02:03 -0800 (PST) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.33 #2) id 16dShG-000Kfu-00 for freebsd-net@freebsd.org; Wed, 20 Feb 2002 11:05:54 +0200 Received: from shell.devco.net ([196.15.188.7]) by mx1.dev.itouchnet.net with esmtp (Exim 3.33 #2) id 16dShD-000Kfd-00; Wed, 20 Feb 2002 11:05:51 +0200 Received: from bvi by shell.devco.net with local (Exim 3.33 #4) id 16dSg5-00093l-00; Wed, 20 Feb 2002 11:04:41 +0200 Date: Wed, 20 Feb 2002 11:04:41 +0200 From: Barry Irwin To: tang hongbin Cc: freebsd-net@freebsd.org Subject: Re: connection win2000 to racoon on freebsd4.3 Message-ID: <20020220110441.F25707@itouchlabs.com> References: <20020220085354.5237.qmail@web11606.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020220085354.5237.qmail@web11606.mail.yahoo.com>; from hongbintang@yahoo.com on Wed, Feb 20, 2002 at 12:53:54AM -0800 X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 79474-1014195954-64073@mx1.dev.itouchnet.net version $Name: REL_2_0_2 $ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have had win2k working fine. The trick is you need to use MMC and the ipsec snapin to map your own IPsec policies, specifically remove the standard Kerberos authentication and either use shared passwords, or certificates, both of which work with Racoon. The phase 2 failure is indicitive that either your shared secrets do not match ( have you checked the psk.txt file for racoon - modes are especially NB in this mode - but also that you have the right secret for the IP address) Barry -- Barry Irwin bvi@itouchlabs.com +27214875150 Systems Administrator: Networks And Security Itouch Labs http://www.itouchlabs.com South Africa On Wed 2002-02-20 (00:53), tang hongbin wrote: > Dear all; > > I tried to build VPN tunnels between win2000 > professional and FreeBSD4.2 with RACOON as IKE > negotiator. The procedures were described as > following: > > 1: I set up local policies on win2000. > 2: I added rules into racoon.conf and/or psk.txt. > > when I sended messages from win2000 to BSD VPN server, > RACOON met problems at phase 2 and printed the > following infomation: > .... > isakmp-info_recv_n():776 unknown notify message.... > .. > > If you has succeeded in connecting win2000 and RACOON > on FressBSD, please give your setup procedure in > detail. > > Thank you > > bill.tang > hongbintang@yahoo.com > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > -- Barry Irwin bvi@itouchlabs.com +27214875150 Systems Administrator: Networks And Security Itouch Labs http://www.itouchlabs.com South Africa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 2:46:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 80F6637B402 for ; Wed, 20 Feb 2002 02:46:32 -0800 (PST) Received: by smtp.nettoll.com; Wed, 20 Feb 2002 11:45:21 +0100 (MET) Date: Wed, 20 Feb 2002 11:46:09 +0100 (CET) From: Nicolas Fritsch X-X-Sender: nfritsch@mexico.nettoll.com To: freebsd-net@freebsd.org Subject: Interrupts / No interrupts Message-ID: <20020220114202.T64112-100000@mexico.nettoll.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! I'm working on an IP encapsulation protocol, a la IPSec. Since I need to manage sessions, I have "shared datum" among several IP packets, so I need to splnet() / splx() the code. A simple way to do it is just to protect my whole code inside a splnet(), and then splx() when it exits. I that a bad idea? Should I only protect some portions, and why? Thanks Nicolas Fritsch Software Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 3:23:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from brain.cc.rsu.ru (brain.cc.rsu.ru [195.208.252.154]) by hub.freebsd.org (Postfix) with ESMTP id 9364537B404 for ; Wed, 20 Feb 2002 03:23:41 -0800 (PST) Received: from localhost (os@localhost [127.0.0.1]) by brain.cc.rsu.ru (8.11.6/8.11.4) with ESMTP id g1KBNSp08837 for ; Wed, 20 Feb 2002 14:23:28 +0300 (MSK) (envelope-from os@rsu.ru) Date: Wed, 20 Feb 2002 14:23:28 +0300 (MSK) From: Oleg Sharoiko X-X-Sender: os@brain.cc.rsu.ru To: freebsd-net@freebsd.org Subject: routed md5 authentication Message-ID: <20020220135720.V256-100000@brain.cc.rsu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello! I was trying to make routed (4.5 stable) and cisco 3640 (12.1(5)T) RIPv2 work together. I discovered that MD5 authentications are not compatible. In particular routed skips 4 bytes (family and type fields of auth data record) of packet while computing hash for packet. This seems to be wrong according to rfc 2082. I made a patch to fix this problem. Could someone please revise it and commit if it's ok. BTW: Is it correct that first RIP request is always sent without authentication? p.s. Please CC to my email when reply, cause I'm not on the list. 1. For include/protocols/routed.h (additional constant) --- protocols/routed.h.org Wed Feb 20 14:08:07 2002 +++ protocols/routed.h Wed Feb 20 13:03:49 2002 @@ -98,7 +98,8 @@ int8_t md5_auth_len; /* 16 */ u_int32_t md5_seqno; /* sequence number */ u_int32_t rsvd[2]; /* must be 0 */ -#define RIP_AUTH_MD5_LEN RIP_AUTH_PW_LEN +#define RIP_AUTH_HDR_LEN 4 +#define RIP_AUTH_MD5_LEN 16 } a_md5; } au; }; 2. For sources of routed diff -u routed.org/input.c routed/input.c --- routed.org/input.c Wed Feb 20 10:48:56 2002 +++ routed/input.c Wed Feb 20 11:15:21 2002 @@ -967,7 +967,7 @@ */ if (TRACEPACKETS) { if (NA->au.a_md5.md5_auth_len - != RIP_AUTH_MD5_LEN) + != RIP_AUTH_HDR_LEN + RIP_AUTH_MD5_LEN) msglim(use_authp, from, "unknown MD5 RIPv2 auth len %#x" " instead of %#x from %s", @@ -989,7 +989,7 @@ } MD5Init(&md5_ctx); - MD5Update(&md5_ctx, (u_char *)rip, len); + MD5Update(&md5_ctx, (u_char *)rip, len+RIP_AUTH_HDR_LEN); MD5Update(&md5_ctx, ap->key, RIP_AUTH_MD5_LEN); MD5Final(hash, &md5_ctx); if (!memcmp(hash, na2->au.au_pw, sizeof(hash))) --- routed.org/output.c Wed Feb 20 10:47:48 2002 +++ routed/output.c Wed Feb 20 10:50:01 2002 @@ -303,7 +303,7 @@ na2->a_type = htons(1); na->au.a_md5.md5_pkt_len = htons(len); MD5Init(&md5_ctx); - MD5Update(&md5_ctx, (u_char *)wb->buf, len); + MD5Update(&md5_ctx, (u_char *)wb->buf, len + RIP_AUTH_HDR_LEN); MD5Update(&md5_ctx, ap->key, RIP_AUTH_MD5_LEN); MD5Final(na2->au.au_pw, &md5_ctx); wb->n++; -- Oleg Sharoiko. Software and Network Engineer Computer Center of Rostov State University. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 4:20:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from garfield.bmk.com.au (bmkind.lnk.telstra.net [139.130.51.118]) by hub.freebsd.org (Postfix) with ESMTP id D922237B400 for ; Wed, 20 Feb 2002 04:20:22 -0800 (PST) Received: from localhost (brendan@localhost) by garfield.bmk.com.au (8.9.3/8.9.3) with SMTP id XAA30266 for ; Wed, 20 Feb 2002 23:20:20 +1100 (EST) (envelope-from brendan@bmk.com.au) Date: Wed, 20 Feb 2002 23:20:20 +1100 (EST) From: Brendan Kosowski To: FreeBSD Networking Subject: gateway question in relation to "RFC 1918" IP addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If I set up a FreeBSD box as a gateway, how do I tell it not to route Private IP addresses ( ie. "RFC 1918" addresses ). Thanks, Brendan... ------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 4:43:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2]) by hub.freebsd.org (Postfix) with ESMTP id C7B4437B405 for ; Wed, 20 Feb 2002 04:43:19 -0800 (PST) Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.33 #2) id 16dW9N-000142-00 for freebsd-net@freebsd.org; Wed, 20 Feb 2002 14:47:09 +0200 Received: from shell.devco.net ([196.15.188.7]) by mx1.dev.itouchnet.net with esmtp (Exim 3.33 #2) id 16dW9M-00013c-00; Wed, 20 Feb 2002 14:47:08 +0200 Received: from bvi by shell.devco.net with local (Exim 3.33 #4) id 16dW8F-0009h7-00; Wed, 20 Feb 2002 14:45:59 +0200 Date: Wed, 20 Feb 2002 14:45:59 +0200 From: Barry Irwin To: Brendan Kosowski Cc: FreeBSD Networking Subject: Re: gateway question in relation to "RFC 1918" IP addresses Message-ID: <20020220144559.H25707@itouchlabs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from brendan@bmk.com.au on Wed, Feb 20, 2002 at 11:20:20PM +1100 X-Checked: This message has been scanned for any virusses and unauthorized attachments. X-iScan-ID: 4082-1014209229-47121@mx1.dev.itouchnet.net version $Name: REL_2_0_2 $ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed 2002-02-20 (23:20), Brendan Kosowski wrote: > > If I set up a FreeBSD box as a gateway, how do I tell it not to route > Private IP addresses ( ie. "RFC 1918" addresses ). You firewall them look at /etc/rc.firewall the standard option blocks the rfc 1918 addresses and a number of other spurious networks as mentioned in draft-manning-dusa-06.txt 9 IETF draft. Have a look at the man page for ipfw(8) should have all you need. Barry -- Barry Irwin bvi@itouchlabs.com +27214875150 Systems Administrator: Networks And Security Itouch Labs http://www.itouchlabs.com South Africa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 8: 2:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from web20102.mail.yahoo.com (web20102.mail.yahoo.com [216.136.226.39]) by hub.freebsd.org (Postfix) with SMTP id E7DE437B417 for ; Wed, 20 Feb 2002 08:02:06 -0800 (PST) Message-ID: <20020220160201.80971.qmail@web20102.mail.yahoo.com> Received: from [212.234.238.114] by web20102.mail.yahoo.com via HTTP; Wed, 20 Feb 2002 08:02:01 PST Date: Wed, 20 Feb 2002 08:02:01 -0800 (PST) From: ome ome Subject: MPD Server ? To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi. I would like to test a multi-link over 2 different types of device with MPD 3.7 (PPPoE and PPP over a serial link) between two stations on freeBSD 3.5. MPD works fine as client, so I would like to know if MPD 3.7 could be a server PPPoE? Moreover, could MPD be a multi-link server? Thanks in advance. __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 10:10:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from cheer.mahoroba.org (flets19-017.kamome.or.jp [218.45.19.17]) by hub.freebsd.org (Postfix) with ESMTP id A414637B402 for ; Wed, 20 Feb 2002 10:10:21 -0800 (PST) Received: from mille.mahoroba.org (IDENT:mX/isHdBO6HFpFArSx5DeDeFkoqeoBZPXmyT0FZ1xjKoyJ9l4+Ix09jbIbyPXwBH@mille.mahoroba.org [IPv6:2001:200:301:0:202:2dff:fe0a:6bee]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.12.2/8.12.2) with ESMTP/inet6 id g1KI7pKb059448 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Feb 2002 03:07:53 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 21 Feb 2002 03:07:50 +0900 Message-ID: From: Hajimu UMEMOTO To: cjclark@alum.mit.edu Cc: net@freebsd.org Subject: Re: Odd Rule in rc.firewall6 In-Reply-To: References: <20020219185543.T48401@blossom.cjclark.org> User-Agent: xcite1.38> Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.5-RELEASE MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>> Wed, 20 Feb 2002 13:57:21 +0900 >>> Hajimu UMEMOTO said: ume> must be retained. But, it seems ume> ${fw6cmd} add pass ipv6-icmp from ff02::/16 to :: ume> is not required. When I wrote this, maybe I might confused. ume> But, I cannot test it just now. I'll test it tonight. I just tested and committed. Thanks. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 10:40:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 80E8C37B41C for ; Wed, 20 Feb 2002 10:40:22 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020220184022.OKWK1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Wed, 20 Feb 2002 18:40:22 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA63375; Wed, 20 Feb 2002 10:23:20 -0800 (PST) Date: Wed, 20 Feb 2002 10:23:20 -0800 (PST) From: Julian Elischer To: ome ome Cc: freebsd-net@freebsd.org Subject: Re: MPD Server ? In-Reply-To: <20020220160201.80971.qmail@web20102.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org mpd does not know how to be a pppoe server. HOWEVER the pppoed program is designed to turn the normal ppp into a server. It is possible that archie might be able to make mpd use pppoed (or embed it) but I'm pretty sure he hasn't done it yet. MPD Is a multilink server, yes. On Wed, 20 Feb 2002, ome ome wrote: > Hi. > > I would like to test a multi-link over 2 different > types of device with MPD 3.7 (PPPoE and PPP over a > serial link) between two stations on freeBSD 3.5. > > MPD works fine as client, so I would like to know if > MPD 3.7 could be a server PPPoE? Moreover, could MPD > be > a multi-link server? > > Thanks in advance. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - Coverage of the 2002 Olympic Games > http://sports.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 10:57:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from smart-x.ctlc.interplex.ca (smart-x.ctlc.interplex.ca [209.71.202.73]) by hub.freebsd.org (Postfix) with ESMTP id D8AA937B425 for ; Wed, 20 Feb 2002 10:57:28 -0800 (PST) Received: (from deejay2@localhost) by smart-x.ctlc.interplex.ca (8.11.6/8.11.6) id g1KJ13W14714 for freebsd-net@freebsd.org; Wed, 20 Feb 2002 14:01:03 -0500 (EST) (envelope-from deejay2) Date: Wed, 20 Feb 2002 14:01:03 -0500 From: Dominic Blais To: freebsd-net@freebsd.org Subject: fxp device can't upload more than ~12Mbps Message-ID: <20020220140103.A14692@smart-x.ctlc.interplex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! It looks like all my fxp NIC can't upload more than 12Mbps while settled on 100baseTX full-duplex. It drops to 600kbps if I set it half-duplex... really weird.. If I set it full-duplex, I can download up to ~90Mbps which looks normal... If I set it half-duplex, it drops to ~50kbps ....really slow... I have the same problem with all my fxp cars on all my freebsd boxes. This is the data from the server: fxp0: port 0x2800-0x283f mem 0xc6f00000-0xc6ffffff,0xc6efd000-0xc6efdfff irq 11 at device 10.0 on$ fxp0: Ethernet address 00:d0:b7:b2:5b:a5 fxp0: flags=8843 mtu 1500 inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 inet6 fe80::2d0:b7ff:feb2:5ba5%fxp0 prefixlen 64 scopeid 0x2 ether 00:d0:b7:b2:5b:a5 media: 100baseTX status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP It runs on a Compaq Proliant server... Please reply to my address too..I'm not on freebsd-net.. Thanks a lot! -- Dominic Blais Administrateur reseau Interplex telecom -=[ http://www.interplex.ca ]=- Email: db@interplex.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 12:13:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.tgd.net (mail.tgd.net [209.81.25.10]) by hub.freebsd.org (Postfix) with ESMTP id 0608F37B400 for ; Wed, 20 Feb 2002 12:13:26 -0800 (PST) Received: by mail.tgd.net (Postfix, from userid 1001) id B2E1420F0A; Wed, 20 Feb 2002 12:13:25 -0800 (PST) Date: Wed, 20 Feb 2002 12:13:25 -0800 From: Sean Chittenden To: Dominic Blais Cc: freebsd-net@freebsd.org Subject: Re: fxp device can't upload more than ~12Mbps Message-ID: <20020220121325.B43091@ninja1.internal> References: <20020220140103.A14692@smart-x.ctlc.interplex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020220140103.A14692@smart-x.ctlc.interplex.ca>; from "deejay2@smart-x.ctlc.interplex.ca" on Wed, Feb 20, 2002 at = 02:01:03PM X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > If I set it full-duplex, I can download up to ~90Mbps which looks normal... > If I set it half-duplex, it drops to ~50kbps ....really slow... That's because the switch that you're plugged into is still running at full duplex. Hop onto the switch and force the port to half-duplex and you should see more normal flow. Why would you want half-duplex anyway? -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 14: 9:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (Postfix) with ESMTP id 7CB9437B405; Wed, 20 Feb 2002 14:09:06 -0800 (PST) Received: from there ([80.60.248.65]) by smtp01.wxs.nl (Netscape Messaging Server 4.15) with SMTP id GRUQV400.P3R; Wed, 20 Feb 2002 23:09:04 +0100 Content-Type: text/plain; charset="iso-8859-1" From: "Peter J. Blok" To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: if_wb driver problem - need help Date: Wed, 20 Feb 2002 23:09:04 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020220220906.7CB9437B405@hub.freebsd.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have a Winbond based card with an Altima AC104 media interface. No matter what I do i am not able to recognize the AC104 through the SIO interface. The BMSR register value stays at zero. I have the datasheets of both the Winbond and the Altima and everything looks ok. So far i see the frame to request the contents of the bmsr C24 is send ok to the AC10t thru the management interface. The ACK is never coming. Who has tips trying to make this thing work? I have also tried NetBSD without success. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 20:52:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from smart-x.ctlc.interplex.ca (smart-x.ctlc.interplex.ca [209.71.202.73]) by hub.freebsd.org (Postfix) with ESMTP id 344DA37B419 for ; Wed, 20 Feb 2002 20:52:28 -0800 (PST) Received: (from deejay2@localhost) by smart-x.ctlc.interplex.ca (8.11.6/8.11.6) id g1L4trl15362; Wed, 20 Feb 2002 23:55:53 -0500 (EST) (envelope-from deejay2) Date: Wed, 20 Feb 2002 23:55:53 -0500 From: Dominic Blais To: Sean Chittenden Cc: freebsd-net@freebsd.org Subject: Re: fxp device can't upload more than ~12Mbps Message-ID: <20020220235553.A15349@smart-x.ctlc.interplex.ca> References: <20020220140103.A14692@smart-x.ctlc.interplex.ca> <20020220121325.B43091@ninja1.internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020220121325.B43091@ninja1.internal>; from sean@chittenden.org on Wed, Feb 20, 2002 at 12:13:25PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Feb 20, 2002 at 12:13:25PM -0800, Sean Chittenden wrote: > > If I set it full-duplex, I can download up to ~90Mbps which looks normal... > > If I set it half-duplex, it drops to ~50kbps ....really slow... > > That's because the switch that you're plugged into is still running at > full duplex. Hop onto the switch and force the port to half-duplex > and you should see more normal flow. Why would you want half-duplex > anyway? -sc > It was an example..In fact, I want full duplex...but as you see, with full duplex, the fxp card send at 1.2MBps and receives at 9MBps... It receives at a normal speed..but sending is really slow and it looks like I'm not alone with this problem... -- Dominic Blais Administrateur reseau Interplex telecom -=[ http://www.interplex.ca ]=- Email: db@interplex.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 22:42:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from moab.cs.utah.edu (moab.cs.utah.edu [155.99.212.88]) by hub.freebsd.org (Postfix) with ESMTP id 9AFC937B400 for ; Wed, 20 Feb 2002 22:42:33 -0800 (PST) Received: from localhost (bwhite@localhost) by moab.cs.utah.edu (8.9.1/8.9.1) with ESMTP id XAA15432 for ; Wed, 20 Feb 2002 23:42:33 -0700 (MST) Date: Wed, 20 Feb 2002 23:42:33 -0700 (MST) From: Brian White To: freebsd-net@FreeBSD.ORG Subject: SACK (and older TCP stack) availability? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org To compare against simulation, I'm trying to collect any available TCP implementations -- preferably compatible with a recent(ish) kernel. We run 4.3, but could upgrade. I was hoping to find the usual suspects -- Tahoe, Reno, Vegas, New-Reno, and SACK. I realize this question is probably better phrased in terms of features rather than artificial names. But (please correct me), it seems that there are few options to disable TCP features to revert to a previous protocol realization. The most obvious exception is net.inet.tcp.newreno. (At the risk of exposing my naivete, does disabling New-Reno leave me with ... Reno? Or possibly some FreeBSD hybrid?) I tracked a thread from Aug 2001 in which Harkirat Singh announced his SACK implementation. But, this thread seems to have ended prematurely and grep'ing for SACK in current does not turn up anything interesting. What is it's status? Was the 4.3 SACK diff stable? I would greatly appreciate any responses (or browbeatings) being sent directly to me as well. Thank you, brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 20 23:50:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d173.as21.nwbl0.wi.voyager.net [169.207.139.239]) by hub.freebsd.org (Postfix) with ESMTP id 5668137B405 for ; Wed, 20 Feb 2002 23:50:32 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g1L1sOFY020318; Thu, 21 Feb 2002 01:54:24 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g1L1sKTV020315; Thu, 21 Feb 2002 01:54:22 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 21 Feb 2002 01:54:20 +0000 (GMT) From: Mike Silbersack To: Brian White Cc: freebsd-net@FreeBSD.ORG Subject: Re: SACK (and older TCP stack) availability? In-Reply-To: Message-ID: <20020221014912.M20299-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 20 Feb 2002, Brian White wrote: > To compare against simulation, I'm trying to collect any available TCP > implementations -- preferably compatible with a > recent(ish) kernel. We run 4.3, but could upgrade. I was hoping to find > the usual suspects -- Tahoe, Reno, Vegas, New-Reno, and SACK. > > I realize this question is probably better phrased in terms of features > rather than artificial names. But (please correct me), it seems that > there are few options to disable TCP features to revert to a previous > protocol realization. The most obvious exception is > net.inet.tcp.newreno. (At the risk of exposing my naivete, does disabling > New-Reno leave me with ... Reno? Or possibly some FreeBSD hybrid?) Your two choices as of now are Reno and NewReno, toggleable via the sysctl you mention. Naturally, neither implementation perfectly follows the spec(s); I doubt many real world implementations do. (The fact that NewReno has multiple variants described doesn't help this much.) > I tracked a thread from Aug 2001 in which Harkirat Singh announced his > SACK implementation. But, this thread seems to have ended prematurely and > grep'ing for SACK in current does not turn up anything interesting. What > is it's status? Was the 4.3 SACK diff stable? I never got time to test it, nor did any other committer I'm aware of. If someone were to do some good testing of the patch and post the results, that would be highly helpful in getting it on the road to being committed. Unadvocated patches ususally don't get committed. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 2:49:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.tgd.net (mail.tgd.net [209.81.25.10]) by hub.freebsd.org (Postfix) with ESMTP id 1235D37B416 for ; Thu, 21 Feb 2002 02:49:11 -0800 (PST) Received: by mail.tgd.net (Postfix, from userid 1001) id D4C9C20F16; Thu, 21 Feb 2002 02:49:10 -0800 (PST) Date: Thu, 21 Feb 2002 02:49:10 -0800 From: Sean Chittenden To: Dominic Blais Cc: freebsd-net@freebsd.org Subject: Re: fxp device can't upload more than ~12Mbps Message-ID: <20020221024910.F86510@ninja1.internal> References: <20020220140103.A14692@smart-x.ctlc.interplex.ca> <20020220121325.B43091@ninja1.internal> <20020220235553.A15349@smart-x.ctlc.interplex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020220235553.A15349@smart-x.ctlc.interplex.ca>; from "deejay2@smart-x.ctlc.interplex.ca" on Wed, Feb 20, 2002 at = 11:55:53PM X-PGP-Key: 0x1EDDFAAD X-PGP-Fingerprint: C665 A17F 9A56 286C 5CFB 1DEA 9F4F 5CEF 1EDD FAAD X-Web-Homepage: http://sean.chittenden.org/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > > If I set it full-duplex, I can download up to ~90Mbps which looks normal... > > > If I set it half-duplex, it drops to ~50kbps ....really slow... > > > > That's because the switch that you're plugged into is still running at > > full duplex. Hop onto the switch and force the port to half-duplex > > and you should see more normal flow. Why would you want half-duplex > > anyway? -sc > > BIt was an example..In fact, I want full duplex...but as you see, > with full duplex, the fxp card send at 1.2MBps and receives at > 9MBps... It receives at a normal speed..but sending is really slow > and it looks like I'm not alone with this problem... Sorry, I jumped the gun. Those numbers are magic numbers in my mind and almost always equate to a duplex mismatch. Dig through the archives on -net and -stable and look for some discussion regarding samba performance, I wonder if you can tweak a TCP setting or two. What version are you running? Any rate shapping (stranger things have happened)? -sc -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 4:29: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id 0BBA337B404 for ; Thu, 21 Feb 2002 04:28:58 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g1LCSkD98179 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 21 Feb 2002 07:28:48 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020221132702.0451fa88@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 13:39:13 +0100 To: Nick Rogness , Zviratko From: "Rogier R. Mulhuijzen" Subject: Re: Ethernet bonding/load balancing on fbsd 4-stable Cc: freebsd-net@FreeBSD.ORG In-Reply-To: References: <003501c1b7a8$4431d5f0$0500a8c0@notes> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 02:48 19-2-2002 -0600, Nick Rogness wrote: >On Sun, 17 Feb 2002, Zviratko wrote: > > > >[SNIP] > > > > I will try that, but I guess default route has precedence over ipfw. > > Not in the case of ipfw fwd. The routing decision seems to be > made before ipfw fwd changes the packet. That's correct, I use a few fwd rules to have packets return on the correct pipe on a dual-homed machine. Basically if the source address is on a different pipe than my default gateway and the destination is not the local subnet I fwd it to the other router. Works VERY sweetly. BTW, the fact that ng_one2many works for loadsharing over 2 cable modems means that your ISP is lazy with checking things (I think, I just woke up so thought processes are not doing too well yet =) ). What you could have done as well is tell natd to spread the connections over your 2 internet IPs, and then using fwd based on src to send to the right cable modem. But this would require both cable modems to have a different default gateway. If they have default gateway you could use ng_bpf to look at src address and sending it out the right ng_ether node. That *should* work even if your ISP does hard checks on whether or not incoming traffic comes in on the right cable modem. It will not spread a single connection over both modems, but it will spread load over both modems for returning packets, which I don't think your solution does. Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 4:43:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id 4020A37B402 for ; Thu, 21 Feb 2002 04:43:34 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g1LChAD98629 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 21 Feb 2002 07:43:12 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020221134511.044b1898@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 13:53:37 +0100 To: Marcel de Vries , Luigi Rizzo From: "Rogier R. Mulhuijzen" Subject: Re: network buffer problem -/- natd Cc: freebsd-net@FreeBSD.ORG In-Reply-To: <5.1.0.14.2.20020219204129.00b5aa20@outshine> References: <20020219104432.A31233@iguana.icir.org> <5.1.0.14.2.20020219192110.01f45e48@outshine> <5.1.0.14.2.20020219154939.00bb52d8@outshine> <5.1.0.14.2.20020219192110.01f45e48@outshine> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 21:19 19-2-2002 +0100, Marcel de Vries wrote: >I use mpd to setup a PPTP (gre encapsulation) connection between interface >ep0 (public) and my Alcatel ADSL modem. >Don't ask me why but it's the concept of a BIG telecom company we all love >to hate in the Netherlands. KPN TELECOM. > >And most of the people use mpd in the Netherlands and find it a >comfortable and more stable solution I think. Yeah, I use it too. >Well I guess mxstream ADSL works fine in most cases. These other paid OS >types like w9x/me, winnt, win2k/XP all can handle PPTP VPN connections >only with the correct DUN version for the early win versions that is. And >almost every ordinary household who owns a computer is running one of the >disgusting platforms mentioned above. And I think it have to work great in >combination with ADSL or else they could flush there concept down the >drains. Because mxstream wants to attract and provide internet for this sector. > >There where a lot problems in the beginning of mxstream but they changed >there design to make it more useful for a internet user. Such as using 10.0.0.0/8 and using NAT! =( Thanks to a few of the internet providers that use MxStream to do ADSL that has been pushed out. (To show you how messed up KPN is at times) >So as most of the BSD community who are in lucky circumstances to own a >ADSL connection would love to use FreeBSD as a router for the rest of the >network. > >I know more people are dealing with packet loss and losing there >connection in use with mxstream ADSL. People that really use there >internet extensive that is ;-) OK so I'm not the only one experiencing this from time to time. I have not seen any bufferspace messages however, am I correct that you don't get that anymore since switching to natd? I haven't had too much time to find out what's going on, but from time to time my connection seems to freeze up, and indeed when I look in top, natd is eating a large chunk of the CPU time. But when I look in trafshow I see something very strange. One connection has an enormous outbound rate. It would be trying to push a few megabytes per second down the 256Kbit upstream that I have (for other MxStream users, yes I have the Fast variant and I'm loving it!). There must be some sort of loop somewhere that's resending the same packet over and over again, as a lot of the times my windows box will be the one responsible for the connection and it's not pumping that data over my internal LAN. Any natd/mpd/netgraph guru's have any hints about where to start looking/how to debug this? If I'm not the only one having this problem I'd like to get this out of the way ASAP. Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 4:47:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id 547DF37B400 for ; Thu, 21 Feb 2002 04:47:20 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g1LCl6D98764 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 21 Feb 2002 07:47:09 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020221135706.044a9d58@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 13:57:33 +0100 To: Brendan Kosowski , FreeBSD Networking From: "Rogier R. Mulhuijzen" Subject: Re: Can't see "ed0" interface when I run pppd with defaultroute option In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 17:58 20-2-2002 +1100, Brendan Kosowski wrote: >Hi, > >My ed0 interface has been set up using a typical LAN style IP address of >192.168.1.100. Can you supply the output of 'ifconfig' and 'netstat -rnf inet'? Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 9: 5:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 17DE637B404 for ; Thu, 21 Feb 2002 09:05:44 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.6) id g1LH5f725219; Thu, 21 Feb 2002 12:05:41 -0500 (EST) (envelope-from wollman) Date: Thu, 21 Feb 2002 12:05:41 -0500 (EST) From: Garrett Wollman Message-Id: <200202211705.g1LH5f725219@khavrinen.lcs.mit.edu> To: Brian White Cc: freebsd-net@FreeBSD.ORG Subject: SACK (and older TCP stack) availability? In-Reply-To: References: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > net.inet.tcp.newreno. (At the risk of exposing my naivete, does disabling > New-Reno leave me with ... Reno? Or possibly some FreeBSD hybrid?) It leaves you with FreeBSD pre-New Reno. That's Reno, plus high-resolution timers, plus some retransmit-avoidance stuff that goes along with the high-resolution timers. A glance at the CVS logs for netinet/tcp_*.c will give you an idea of where and when things have changed. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 11:18:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id D9B8137B436 for ; Thu, 21 Feb 2002 11:17:53 -0800 (PST) Received: from isi.edu (e2qkmn7we6u7twem@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g1LJHqQ22641 for ; Thu, 21 Feb 2002 11:17:52 -0800 (PST) Message-ID: <3C7547E0.8050805@isi.edu> Date: Thu, 21 Feb 2002 11:17:52 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020213 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: net@freebsd.org Subject: incorrect checksums with xl? Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060704050603020100070205" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms060704050603020100070205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm looking at a packet trace taken of an xl card under 4.5, and I see bad IP and TCP/UDP checksums. The release notes state that checksumming maybe offloaded to the NIC now, but I'd still expect them to be correct in a packet trace! More specifically, the IP checksum is always zero, while the TCP and UDP checksums are non-zero but bad. However, netstat shows no packets arriving with bad checksums, so I assume that they get mangled somewhere in the kernel after inbound processing. (And the machine works fine on a network; I found this by accident.) Any clues? Thanks, Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms060704050603020100070205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDIyMTE5MTc1MlowIwYJKoZIhvcNAQkEMRYEFEBi2yQM/v392tTQCla6juHexILlMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYAQLkqRK1JPcb+NVQnO8qQwqRisBGq4cHsUAVZsPBtw9V9aTuNHZxYbQIIbjTO7yVso 0yiiwgWOsq6xKM/LuplzJiyvvEiVl18mfddDTIyCc5y6Liq2ut5wE8oQ1korOyJXyX4HEWcq hBa+qxeFvH4vWTmAFurrXPynJAwR3UlnWgAAAAAAAA== --------------ms060704050603020100070205-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 11:25:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id DA9B937B404 for ; Thu, 21 Feb 2002 11:25:51 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 89859AE278; Thu, 21 Feb 2002 11:25:51 -0800 (PST) Date: Thu, 21 Feb 2002 11:25:51 -0800 From: Alfred Perlstein To: Lars Eggert Cc: net@freebsd.org Subject: Re: incorrect checksums with xl? Message-ID: <20020221192551.GG12136@elvis.mu.org> References: <3C7547E0.8050805@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C7547E0.8050805@isi.edu> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Lars Eggert [020221 11:18] wrote: > Hi, > > I'm looking at a packet trace taken of an xl card under 4.5, and I see > bad IP and TCP/UDP checksums. The release notes state that checksumming > maybe offloaded to the NIC now, but I'd still expect them to be correct > in a packet trace! > > More specifically, the IP checksum is always zero, while the TCP and UDP > checksums are non-zero but bad. However, netstat shows no packets > arriving with bad checksums, so I assume that they get mangled somewhere > in the kernel after inbound processing. (And the machine works fine on a > network; I found this by accident.) > > Any clues? I'm not 100% on this, but bpf may be queueing the packet without doing a deep copy of it? Another thing may be that the card performs the checksum but uses the checksum area as a scratch area? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 13:44:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 14F3737B416 for ; Thu, 21 Feb 2002 13:44:24 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1LLi7952762; Thu, 21 Feb 2002 13:44:07 -0800 (PST) (envelope-from rizzo) Date: Thu, 21 Feb 2002 13:44:07 -0800 From: Luigi Rizzo To: Mike Silbersack Cc: Brian White , freebsd-net@FreeBSD.ORG Subject: Re: SACK (and older TCP stack) availability? Message-ID: <20020221134407.B52538@iguana.icir.org> References: <20020221014912.M20299-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020221014912.M20299-100000@patrocles.silby.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Feb 21, 2002 at 01:54:20AM +0000, Mike Silbersack wrote: > > > I tracked a thread from Aug 2001 in which Harkirat Singh announced his > > SACK implementation. But, this thread seems to have ended prematurely and > > grep'ing for SACK in current does not turn up anything interesting. What > > is it's status? Was the 4.3 SACK diff stable? > > I never got time to test it, nor did any other committer I'm aware of. > If someone were to do some good testing of the patch and post the results, > that would be highly helpful in getting it on the road to being committed. > Unadvocated patches ususally don't get committed. I actually looked at the patches, and by visual inspection, they broke the flow for standard TCP connections when SACK was disabled. This was also verified with TBIT. So even if the SACK implementation was correct (which I haven't checked in detail) they are a no-go unless someone puts significant work on them. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 14: 1:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d171.as12.nwbl0.wi.voyager.net [169.207.136.173]) by hub.freebsd.org (Postfix) with ESMTP id DC81737B443 for ; Thu, 21 Feb 2002 14:00:58 -0800 (PST) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.2/8.12.2) with ESMTP id g1LG4rFY023013; Thu, 21 Feb 2002 16:04:53 GMT (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.2/8.12.2/Submit) with ESMTP id g1LG4owb023010; Thu, 21 Feb 2002 16:04:52 GMT X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Thu, 21 Feb 2002 16:04:49 +0000 (GMT) From: Mike Silbersack To: Luigi Rizzo Cc: Brian White , Subject: Re: SACK (and older TCP stack) availability? In-Reply-To: <20020221134407.B52538@iguana.icir.org> Message-ID: <20020221160324.R22677-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 21 Feb 2002, Luigi Rizzo wrote: > I actually looked at the patches, and by visual inspection, > they broke the flow for standard TCP connections when SACK > was disabled. This was also verified with TBIT. > So even if the SACK implementation was correct > (which I haven't checked in detail) they are a no-go > unless someone puts significant work on them. > > cheers > luigi Whee! Ok, good to know. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 14:40:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id BA72E37B402 for ; Thu, 21 Feb 2002 14:40:14 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020221224014.CMYA1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Thu, 21 Feb 2002 22:40:14 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA69723; Thu, 21 Feb 2002 14:27:49 -0800 (PST) Date: Thu, 21 Feb 2002 14:27:48 -0800 (PST) From: Julian Elischer To: Luigi Rizzo Cc: Mike Silbersack , Brian White , freebsd-net@FreeBSD.ORG Subject: Re: SACK (and older TCP stack) availability? In-Reply-To: <20020221134407.B52538@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org tehn we need to tell teh author.. he seems to want then to be used . I'm sure he'd be reponsive to being told about the problems.. On Thu, 21 Feb 2002, Luigi Rizzo wrote: > On Thu, Feb 21, 2002 at 01:54:20AM +0000, Mike Silbersack wrote: > > > > > I tracked a thread from Aug 2001 in which Harkirat Singh announced his > > > SACK implementation. But, this thread seems to have ended prematurely and > > > grep'ing for SACK in current does not turn up anything interesting. What > > > is it's status? Was the 4.3 SACK diff stable? > > > > I never got time to test it, nor did any other committer I'm aware of. > > If someone were to do some good testing of the patch and post the results, > > that would be highly helpful in getting it on the road to being committed. > > Unadvocated patches ususally don't get committed. > > I actually looked at the patches, and by visual inspection, > they broke the flow for standard TCP connections when SACK > was disabled. This was also verified with TBIT. > So even if the SACK implementation was correct > (which I haven't checked in detail) they are a no-go > unless someone puts significant work on them. > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 21 20:48:14 2002 Delivered-To: freebsd-net@freebsd.org Received: from sithdroid.ns1.com.br (sithdroid.ns1.com.br [200.185.44.17]) by hub.freebsd.org (Postfix) with ESMTP id F2E1437B400 for ; Thu, 21 Feb 2002 20:47:53 -0800 (PST) Received: from ivan (20217.virtua.com.br [200.213.202.17] (may be forged)) by sithdroid.ns1.com.br (8.12.2/8.12.2) with SMTP id g1M4lpSK023992 for ; Fri, 22 Feb 2002 01:47:51 -0300 (BRT) Message-ID: <044f01c1ba94$7a5fa820$11cad5c8@mshome.net> From: "Ivan Coimbra" To: Subject: IPFW serious problems Date: Thu, 21 Feb 2002 01:59:01 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am having serious problems with the ipfw of FreeBSD. I am trying to use the forward of packages, and I am having the following problem: the ipfw doesn't make forward for non-local addresses! The options in the kernel are active (IPFIREWALL, IPFIREWALL_FORWARD, etc) and the option of forward of FreeBSD (gateway_enable = "YES") in /etc/rc.conf is active too! With local adresses (local machine) ipfw fwd work! Please, can you help me? ? Thanks, Ivan Coimbra São Paulo / Brasil To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 1: 1:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from tnt.yi.org (possamai.xs4all.nl [213.84.64.160]) by hub.freebsd.org (Postfix) with ESMTP id DD28A37B400 for ; Fri, 22 Feb 2002 01:01:15 -0800 (PST) Received: from localhost (tnt@localhost) by tnt.yi.org (8.11.6/8.11.6) with ESMTP id g1M91Da02548; Fri, 22 Feb 2002 10:01:14 +0100 (CET) (envelope-from tnt@tnt.yi.org) Date: Fri, 22 Feb 2002 10:01:13 +0100 (CET) From: Michele Possamai X-X-Sender: tnt@localhost Reply-To: possamai@xs4all.nl To: Ivan Coimbra Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPFW serious problems In-Reply-To: <044f01c1ba94$7a5fa820$11cad5c8@mshome.net> Message-ID: <20020222100004.V2533-100000@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I don't know what you exactly want to do.. but if you are using natd with ipfw try the options in natd.. they work a lot easier then ipfw.. On Thu, 21 Feb 2002, Ivan Coimbra wrote: > I am having serious problems with the ipfw of FreeBSD. I am trying to use > the forward of packages, and I am having the following problem: the ipfw > doesn't make forward for non-local addresses! The options in the kernel a= re > active (IPFIREWALL, IPFIREWALL_FORWARD, etc) and the option of forward of > FreeBSD (gateway_enable =3D "YES") in /etc/rc.conf is active too! > With local adresses (local machine) ipfw fwd work! > > Please, can you help me? ? > > Thanks, > Ivan Coimbra > S=E3o Paulo / Brasil > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 2:26:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 5E5E537B400 for ; Fri, 22 Feb 2002 02:26:31 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020222102626.SMVI1214.rwcrmhc54.attbi.com@blossom.cjclark.org> for ; Fri, 22 Feb 2002 10:26:26 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1MAQQj83932 for net@freebsd.org; Fri, 22 Feb 2002 02:26:26 -0800 (PST) (envelope-from cjc) Date: Fri, 22 Feb 2002 02:26:26 -0800 From: "Crist J. Clark" To: net@freebsd.org Subject: TCP Connections to a Broadcast Address Message-ID: <20020222022626.A83807@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org BSD-based TCP/IP code have a bug with respect to creating TCP connections to a broadcast address. This bug can potentially be a security vulnerability when firewall administrators assume that the TCP implementation works correctly and does not block broadcast addresses. The Standard: TCP connections are only valid when the destination address is a unicast address. That is, the destination must not be a multicast or broadcast address. One place this is clearly specified in the Standards is RFC 1122 (everyone's very most favorite RFC), 4.2.3.10 Remote Address Validation ... A TCP implementation MUST silently discard an incoming SYN segment that is addressed to a broadcast or multicast address. The Bug: Uncorrected BSD-based TCP implementations do not actually check if the destination IP address is a broadcast address. Rather, the packet's link layer address is checked. Here is the code from FreeBSD's tcp_input.c, * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN * in_broadcast() should never return true on a received * packet with M_BCAST not set. * * Packets with a multicast source address should also * be discarded. */ if (m->m_flags & (M_BCAST|M_MCAST)) goto drop; #ifdef INET6 if (isipv6) { if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst) || IN6_IS_ADDR_MULTICAST(&ip6->ip6_src)) goto drop; } else #endif if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || ip->ip_src.s_addr == htonl(INADDR_BROADCAST)) goto drop; The comment in the code reveals the reason for the mistake. The authors assume that no one would accidentally or maliciously break the rules. One can easily send packets with a unicast link-layer address, but containing an IP broadcast address. No check is made in the above code for such a pathological situation. A Demonstration: There are many ways to take advantage of this bug. Here is one easy way that will not interfere with normal operations of the test network: 1) On the victim machine add an alias for an unused network, # ifconfig if0 inet 192.0.2.1 alias 2) On the attack machine, which must be local to the victim on the interface configured in step (1), add a route(8), # route add 192.0.2.0/24 3) Now from the attacker, try to establish a TCP connection to the victim's broadcast address on any port that might be listening on the victim, # ssh The connection should succeed. Another slightly scarier attack, since it doesn't require any changes to the victim host, is to just change the attacker's idea of the netmask, making the network "bigger," so that the broadcast address of the network now looks like a unicast to the attacker. But remember this might break some things on the attacker while the network is misconfigured. The Vulnerability: This creates a potential security vulnerability. The firewall administrator may assume that it is not possible to establish TCP connections to a broadcast address and therefore may not protect it adequately. This vulnerability is mitigated by a number of factors: - If the firewall follows a more secure explicitly-pass-default-deny policy, this probably will not be a problem. - An attacking or misconfigured host must be local to the victim. - The attacking host can only connect to broadcast addresses on the local interface. One issue may exacerbates the problem for ipfw(8) users. The 'me' destination in an ipfw(8) rule does NOT match the interface's broadcast address. So, deny tcp from any to me via if0 Would not block a TCP connection to the broadcast address on if0. Using rules like the above on a firewall machine meant to allow forwarded traffic through the external interface, but not allow direct connections to the firewall is probably not uncommon, but it creates a vulnerable configuration. The Fix: Adding an in_broadcast() check trivially fixes the problem. Here is a patch (which fixes the comment too), Index: src/sys/netinet/tcp_input.c =================================================================== RCS file: /export/ncvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.146 diff -u -r1.146 tcp_input.c --- src/sys/netinet/tcp_input.c 4 Jan 2002 17:21:27 -0000 1.146 +++ src/sys/netinet/tcp_input.c 17 Feb 2002 12:54:39 -0000 @@ -798,11 +798,10 @@ } /* * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN - * in_broadcast() should never return true on a received - * packet with M_BCAST not set. - * - * Packets with a multicast source address should also - * be discarded. + * + * It is possible for a malicious (or misconfigured) + * attacker to send unicast link-layer packets with a + * broadcast IP address. Use in_broadcast() to find them. */ if (m->m_flags & (M_BCAST|M_MCAST)) goto drop; @@ -815,7 +814,8 @@ #endif if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || - ip->ip_src.s_addr == htonl(INADDR_BROADCAST)) + ip->ip_src.s_addr == htonl(INADDR_BROADCAST) || + in_broadcast(ip->ip_dst, m->m_pkthdr.rcvif)) goto drop; /* * SYN appears to be valid; create compressed TCP state Actions: I notified security-officer@freebsd.org on Feburary 17th. From examining NetBSD and OpenBSD source code, they appear to have the same flaw. security-offier@ at each was notified at the same time and provided with appropriate patches. I have been unable to actually test the vulnerabilities on an operational NetBSD or OpenBSD system. I have not heard anything from either NetBSD or OpenBSD, and no changes have been committed to their code. rwatson requested I post the above patch to net@ for community review and feedback. So, if no one has any problems with this fix, I will commit it. I have approval to add the fix to the RELENG_4_? security branches once the final fix has been reviewed. Some other remarks about the checks we see above: - The IN_MULTICAST() checks of the source address should not be necessary. Multicast source addresses are never valid for IP datagrams and should be rejected in the network layer. The same applies to the check for multicast source addresses in IPv6. - Since IPv6 does not have broadcasts, it should not be vulnerable provided the multicast check of the destination address is robust. I have not examined the IPv6 code in this respect. After the fix to FreeBSD is made and other *BSD's have ample time to responde, I do plan to send a quick note on the subject to Bugtraq. Thanks for reading. I look forward to comments on the fix. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 2:30:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 271EE37B400 for ; Fri, 22 Feb 2002 02:30:52 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020222103051.LQOQ2951.rwcrmhc53.attbi.com@blossom.cjclark.org> for ; Fri, 22 Feb 2002 10:30:51 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1MAUp383969 for net@freebsd.org; Fri, 22 Feb 2002 02:30:51 -0800 (PST) (envelope-from cjc) Date: Fri, 22 Feb 2002 02:30:51 -0800 From: "Crist J. Clark" To: net@freebsd.org Subject: Re: TCP Connections to a Broadcast Address Message-ID: <20020222023051.A83944@blossom.cjclark.org> Reply-To: cjc@freebsd.org References: <20020222022626.A83807@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020222022626.A83807@blossom.cjclark.org>; from cjc@blossom.cjclark.org on Fri, Feb 22, 2002 at 02:26:26AM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Please note, the previous mail on this topic I sent to net@ has a bad 'From:' address in the header. Replies will not make it back to me. In responses, please change the 'To:' to one of my valid addresses like "cjc@freebsd.org." I apologize for the confusion. I am still trying to figure out how mutt came up with that header. Thanks. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 3:27: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 5B3E037B400 for ; Fri, 22 Feb 2002 03:27:02 -0800 (PST) Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1MBQro86175; Fri, 22 Feb 2002 20:26:53 +0900 (JST) Date: Fri, 22 Feb 2002 20:26:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bart Matthaei Cc: freebsd-net@FreeBSD.ORG Subject: Re: mtu on gif devices In-Reply-To: <20020207220346.I68508@heresy.dreamflow.nl> References: <20020207220346.I68508@heresy.dreamflow.nl> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 36 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Sorry for the delayed response, >>>>> On Thu, 7 Feb 2002 22:03:46 +0100, >>>>> Bart Matthaei said: > The weird thing is, though, that since i've upgraded to 4.5, ssh > connections from my irix and bsd box in my network (which have > public ip's tunneled from work) die spontaniously. They either die > when i give it a lot of input, or when i idle for a bit. It smells > like a mtu problem to me, but i can't find the problem. > When i ssh directly from my router trough the tunnel to work, i get a > stable connection, so i figured the home-router itself is the source > of the problem. > Set up is like this: > colo (gif with mtu 1500) -> gif tunnel -> home-router (gif with mtu > 1500/ interfaces with mtu 1500) -> irix box (mtu 1200) / bsd box (mtu > 1500). > Both the irix and bsd box have the problem. > The problem was also occuring when the mtu of both gif devices were > set to 1280. > It all started when i upgraded my home router from 4.4 to 4.5. How did you configure (particularly the default) routes on the host "colo"? I've seen several reports that the default route on a tunnel link has somehow become bogus. BTW: if the problem happens regardless of the MTU value, the MTU setting may not be the reason. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 3:31:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 2389F37B417; Fri, 22 Feb 2002 03:31:45 -0800 (PST) Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1MBVco86207; Fri, 22 Feb 2002 20:31:38 +0900 (JST) Date: Fri, 22 Feb 2002 20:31:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Nick Sayer Cc: freebsd-net@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: TCPv6 lags in 4.5-RELEASE? In-Reply-To: <3C661D4E.9040908@quack.kfu.com> References: <3C661D4E.9040908@quack.kfu.com> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Sat, 09 Feb 2002 23:12:14 -0800, >>>>> Nick Sayer said: > I don't know if I can quantify the issue very well, but since moving > from 4.4-RELEASE to 4.5-RELEASE on my laptop, I've noticed that > TCP-over-IPv6 sessions get stuck rather easily. They end up in a state > where no further I/O will take place. TCP-over-IPv4 does not have this > problem. > This machine is using IPSEC over 802.11b (wi0 - a lucent gold card), and > a (gif0) tunnel for IPv6-over-v4 (without any IPSEC since it's tunneling > over v4 which is IPSECed anyway). If possible, please give us more details. For example, I'm wondering: Does the situation change if you do not use IPSEC? Does the situation change if you establish a TCP connection without IPv6-over-IPv4 tunnels? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 3:45:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from dreamflow.nl (dreamflow.nl [62.58.36.22]) by hub.freebsd.org (Postfix) with SMTP id 1346037B404 for ; Fri, 22 Feb 2002 03:45:06 -0800 (PST) Received: (qmail 21664 invoked by uid 1000); 22 Feb 2002 11:45:04 -0000 Date: Fri, 22 Feb 2002 12:45:04 +0100 From: Bart Matthaei To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: net@freebsd.org Subject: Re: mtu on gif devices Message-ID: <20020222124504.A89164@heresy.dreamflow.nl> References: <20020207220346.I68508@heresy.dreamflow.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Fri, Feb 22, 2002 at 08:26:52PM +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2002 at 08:26:52PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wr= ote: > Sorry for the delayed response, >=20 > How did you configure (particularly the default) routes on the host > "colo"? I've seen several reports that the default route on a tunnel > link has somehow become bogus. >=20 > BTW: if the problem happens regardless of the MTU value, the MTU > setting may not be the reason. Jinmei, The problem has already been fixxed. NAT + Gif tunnel is known to cause mtu problems. I overlooked that. I didn't have this problem in 4.4, so obviously something changed. (I also get a weird traceroute output when i trace something in my homenet from the outside world since my update to 4.5. If you want to hear this issue, let me know.) Regards, Bart --=20 Bart Matthaei bart@dreamflow.nl=20 Support wildlife -- vote for an orgy. --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8di9Agcc6pR+tCegRAlnqAKCqLGSZiib9Pe91r8WZ7YV5UNfXFQCeJNv0 hooMi8uR+FUeO8UusGQ0FoU= =0fFZ -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 3:47:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id BA4C537B404 for ; Fri, 22 Feb 2002 03:47:29 -0800 (PST) Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1MBlJo86368; Fri, 22 Feb 2002 20:47:20 +0900 (JST) Date: Fri, 22 Feb 2002 20:47:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Jay Austad" Cc: Subject: Re: gif0 tunnel and rip (using zebra) In-Reply-To: <54180709DD3FE145917BB165AFE7EFA002E0D4A3@mspexch2.office.mktw.net> References: <54180709DD3FE145917BB165AFE7EFA002E0D4A3@mspexch2.office.mktw.net> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Tue, 12 Feb 2002 13:13:51 -0600, >>>>> "Jay Austad" said: > I'm trying to propagate rip routes using zebra (ripd) across a gif0 > tunnel interface to another freebsd box running zebra. > I have zebra and ripd running, but they only seem to broadcast routes > out the fxp0 interface, and not across the gif0 tunnel. It's quite > annoying. A "show ip protocols" in the ripd vty shows that both fxp0 > and gif0 are sending and receiving RIP updates. However tcpdump shows > otherwise. I really don't need to use zebra, but I'd like to. I guess you should ask the question at the zebra mailing list. > The endpoints on the gif0 tunnel are tied down to addresses assigned to > the lo1 interface on each side. Should I tie these down to the > addresses assigned to fxp0 instead? You do not have to do that. > Also, does FreeBSD 4.5 support GRE tunnels? No, as far as I know. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 3:59:46 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id CB0A537B404; Fri, 22 Feb 2002 03:59:40 -0800 (PST) Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1MBxIo86481; Fri, 22 Feb 2002 20:59:19 +0900 (JST) Date: Fri, 22 Feb 2002 20:59:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Edwin Groothuis Cc: Miguel Mendez , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: IPv6-over-IPv4 problems since the upgrade to 4.5 In-Reply-To: <20020217122510.D491@k7.mavetju.org> References: <0D9185CE635BD511ACA50090277A6FCF1359DB@axcs18.cos.agilent.com> <20020216130842.A19081@energyhq.homeip.net> <20020217122510.D491@k7.mavetju.org> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Sun, 17 Feb 2002 12:25:10 +1100, >>>>> Edwin Groothuis said: >> I recently installed the freenet6 port to test IPv6 and have been >> experiencing similar problems, I can ping6 any host but my ftp >> connections stall at some point. >> >> As an alternative you can use Hurricane Electric's free tunnel. I'm >> using it now and it works like a champ. > I found what caused this. he.net uses the "route add -inet6 default > " statement while freenet6.net uses "route add -inet6 > default -interface gif0" statement. Could you tell me the exact address of ? Is it a link-local address, or a global one? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 4:48:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from topaz.mdcc.cx (topaz.mdcc.cx [212.204.230.141]) by hub.freebsd.org (Postfix) with ESMTP id 822DD37B402; Fri, 22 Feb 2002 04:48:42 -0800 (PST) Received: from k7.mavetju.org (topaz.mdcc.cx [212.204.230.141]) by topaz.mdcc.cx (Postfix) with ESMTP id F0B882B6BD; Fri, 22 Feb 2002 13:48:38 +0100 (CET) Received: by k7.mavetju.org (Postfix, from userid 1001) id 151A1725; Fri, 22 Feb 2002 23:48:29 +1100 (EST) Date: Fri, 22 Feb 2002 23:48:29 +1100 From: Edwin Groothuis To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: IPv6-over-IPv4 problems since the upgrade to 4.5 Message-ID: <20020222234829.F492@k7.mavetju.org> Mail-Followup-To: Edwin Groothuis , "JINMEI Tatuya / ?$B?@L@C#:H?(B" , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <0D9185CE635BD511ACA50090277A6FCF1359DB@axcs18.cos.agilent.com> <20020216130842.A19081@energyhq.homeip.net> <20020217122510.D491@k7.mavetju.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Fri, Feb 22, 2002 at 08:59:18PM +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Feb 22, 2002 at 08:59:18PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > >>>>> On Sun, 17 Feb 2002 12:25:10 +1100, > >>>>> Edwin Groothuis said: > > >> I recently installed the freenet6 port to test IPv6 and have been > >> experiencing similar problems, I can ping6 any host but my ftp > >> connections stall at some point. > >> > >> As an alternative you can use Hurricane Electric's free tunnel. I'm > >> using it now and it works like a champ. > > > I found what caused this. he.net uses the "route add -inet6 default > > " statement while freenet6.net uses "route add -inet6 > > default -interface gif0" statement. > > Could you tell me the exact address of ? Is it a > link-local address, or a global one? Routing tables: default 3ffe:b80:2:460::1 UGSc gif0 3ffe:b80:2:460::1 3ffe:b80:2:460::2 UH gif0 3ffe:b80:2:460::2 link#9 UHL lo0 And the interface configuration: gif0: flags=8051 mtu 1280 tunnel inet 203.173.130.126 --> 206.123.31.114 inet6 fe80::250:8bff:feb9:2d24%gif0 prefixlen 64 scopeid 0x9 inet6 3ffe:b80:2:460::2 --> 3ffe:b80:2:460::1 prefixlen 128 This is the situation when it works (i.e. with "route add -inet6 default ") Edwin -- Edwin Groothuis | Personal website: http://www.MavEtJu.org edwin@mavetju.org | Interested in MUDs? Visit Fatal Dimensions: ------------------+ http://www.FatalDimensions.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 6:13:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by hub.freebsd.org (Postfix) with SMTP id BC48F37B420 for ; Fri, 22 Feb 2002 06:13:26 -0800 (PST) Message-ID: <20020222141326.69663.qmail@web11604.mail.yahoo.com> Received: from [202.94.3.60] by web11604.mail.yahoo.com via HTTP; Fri, 22 Feb 2002 06:13:26 PST Date: Fri, 22 Feb 2002 06:13:26 -0800 (PST) From: tang hongbin Subject: why win2k can't connect to mpd bye pptp with mppe encryption? To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear All; I tried, on win2k, to dial-up to mpd(v3.7) on freebsd with mppe encryption. But I failed. win2k display error messages "the remote server doesn't support the data encrption type". I enabled "mpp-e40","mpp-e128" and "mpp-stateless". I also check mpd3.7's source Makefile and found no rc4.c files when MPPE option is set yes. Is it a bug? If you are interested in this problem,try it. If you succeeded in do so, let me share your joys. Your assistance would be greatly appreciated. Bill.tang hongbintang@yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 6:50:16 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id 8ACC637B400; Fri, 22 Feb 2002 06:50:06 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:b58f:942d:88f8:e401]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1MEo2o87750; Fri, 22 Feb 2002 23:50:02 +0900 (JST) Date: Fri, 22 Feb 2002 23:49:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Edwin Groothuis Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: IPv6-over-IPv4 problems since the upgrade to 4.5 In-Reply-To: <20020222234829.F492@k7.mavetju.org> References: <0D9185CE635BD511ACA50090277A6FCF1359DB@axcs18.cos.agilent.com> <20020216130842.A19081@energyhq.homeip.net> <20020217122510.D491@k7.mavetju.org> <20020222234829.F492@k7.mavetju.org> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Fri, 22 Feb 2002 23:48:29 +1100, >>>>> Edwin Groothuis said: >> > I found what caused this. he.net uses the "route add -inet6 default >> > " statement while freenet6.net uses "route add -inet6 >> > default -interface gif0" statement. >> >> Could you tell me the exact address of ? Is it a >> link-local address, or a global one? > Routing tables: > default 3ffe:b80:2:460::1 UGSc gif0 > 3ffe:b80:2:460::1 3ffe:b80:2:460::2 UH gif0 > 3ffe:b80:2:460::2 link#9 UHL lo0 > And the interface configuration: > gif0: flags=8051 mtu 1280 > tunnel inet 203.173.130.126 --> 206.123.31.114 > inet6 fe80::250:8bff:feb9:2d24%gif0 prefixlen 64 scopeid 0x9 > inet6 3ffe:b80:2:460::2 --> 3ffe:b80:2:460::1 prefixlen 128 Hmm, and what command did you type to cause this problem? If possible, please give me the network topology as well. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 8:32:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by hub.freebsd.org (Postfix) with ESMTP id B4EB937B402 for ; Fri, 22 Feb 2002 08:32:27 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:b58f:942d:88f8:e401]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g1MGWOo88447; Sat, 23 Feb 2002 01:32:24 +0900 (JST) Date: Sat, 23 Feb 2002 01:32:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ross Finlayson Cc: freebsd-net@FreeBSD.ORG Subject: Re: nd6_rtrequest: bad gateway value: stf0 In-Reply-To: <4.3.1.1.20020216130038.00babc30@localhost> References: <4.3.1.1.20020216130038.00babc30@localhost> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 48 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> On Sat, 16 Feb 2002 13:16:40 -0800, >>>>> Ross Finlayson said: > I have tried to configure my system (FreeBSD 4.5-STABLE) for 6to4, using > the "stf" interface, but am getting the error message "nd6_rtrequest: bad > gateway value: stf0" in my log, whenever I try to 'ping6' a remote IPv6 > address. This seems to be a bug in the kernel. Could you try the attached patch (which is for FreeBSD 4.5 RELEASE)? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp *** nd6.c.orig Sat Feb 23 01:29:42 2002 --- nd6.c Sat Feb 23 01:29:58 2002 *************** *** 1112,1117 **** --- 1112,1138 ---- return; } + if (req == RTM_RESOLVE && + (nd6_need_cache(ifp) == 0 || /* stf case */ + !nd6_is_addr_neighbor((struct sockaddr_in6 *)rt_key(rt), ifp))) { + /* + * FreeBSD and BSD/OS often make a cloned host route based + * on a less-specific route (e.g. the default route). + * If the less specific route does not have a "gateway" + * (this is the case when the route just goes to a p2p or an + * stf interface), we'll mistakenly make a neighbor cache for + * the host route, and will see strange neighbor solicitation + * for the corresponding destination. In order to avoid the + * confusion, we check if the destination of the route is + * a neighbor in terms of neighbor discovery, and stop the + * process if not. Additionally, we remove the LLINFO flag + * so that ndp(8) will not try to get the neighbor information + * of the destination. + */ + rt->rt_flags &= ~RTF_LLINFO; + return; + } + switch (req) { case RTM_ADD: /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 8:43:52 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id A76BB37B404 for ; Fri, 22 Feb 2002 08:43:47 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g1MGhjn20106; Fri, 22 Feb 2002 08:43:45 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g1MGhej38249; Fri, 22 Feb 2002 08:43:40 -0800 (PST) (envelope-from jdp) Date: Fri, 22 Feb 2002 08:43:40 -0800 (PST) Message-Id: <200202221643.g1MGhej38249@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: larse@ISI.EDU Subject: Re: incorrect checksums with xl? In-Reply-To: <3C7547E0.8050805@isi.edu> References: <3C7547E0.8050805@isi.edu> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <3C7547E0.8050805@isi.edu>, Lars Eggert wrote: > > I'm looking at a packet trace taken of an xl card under 4.5, and I see > bad IP and TCP/UDP checksums. The release notes state that checksumming > maybe offloaded to the NIC now, but I'd still expect them to be correct > in a packet trace! > > More specifically, the IP checksum is always zero, while the TCP and UDP > checksums are non-zero but bad. However, netstat shows no packets > arriving with bad checksums, so I assume that they get mangled somewhere > in the kernel after inbound processing. (And the machine works fine on a > network; I found this by accident.) > > Any clues? You are running tcpdump on the system that's sending the "bad" packets, right? It makes perfect sense. The TCP/IP stack knows that the NIC is going to insert the checksums, so it doesn't bother calculating them itself. So BPF is handed packets in mbufs without any checksums. On the way out to the wire, the NIC hardware/firmware adds the checksums, but they don't show up in the mbufs that are being sent to BPF. If you run tcpdump on the receiving system instead, you'll find that the checksums seen there are valid. The same thing happens in the bge driver, because it also offloads checksum generation to the NIC. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 8:52:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 09FDE37B404 for ; Fri, 22 Feb 2002 08:52:29 -0800 (PST) Received: from isi.edu (guxfy2v2czkqbhk0@hbo.isi.edu [128.9.160.75]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g1MGqPQ19544; Fri, 22 Feb 2002 08:52:25 -0800 (PST) Message-ID: <3C767749.3020302@isi.edu> Date: Fri, 22 Feb 2002 08:52:25 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020213 X-Accept-Language: en-us, de-de MIME-Version: 1.0 To: John Polstra Cc: net@freebsd.org Subject: Re: incorrect checksums with xl? References: <3C7547E0.8050805@isi.edu> <200202221643.g1MGhej38249@vashon.polstra.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040302030203040902050607" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a cryptographically signed message in MIME format. --------------ms040302030203040902050607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John, John Polstra wrote: > You are running tcpdump on the system that's sending the "bad" > packets, right? It makes perfect sense. The TCP/IP stack knows > that the NIC is going to insert the checksums, so it doesn't bother > calculating them itself. So BPF is handed packets in mbufs without > any checksums. On the way out to the wire, the NIC hardware/firmware > adds the checksums, but they don't show up in the mbufs that are being > sent to BPF. If you run tcpdump on the receiving system instead, > you'll find that the checksums seen there are valid. > > The same thing happens in the bge driver, because it also offloads > checksum generation to the NIC. that makes total sense. I'd like to see the paragraph above in big, bold letters in the xl(4) man page then - so far it doesn't discuss checksum offloading at all. :-) Thanks, Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California --------------ms040302030203040902050607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1 1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d 6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv 0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/ +TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2 aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTAyMDIyMjE2NTIyNVowIwYJKoZIhvcNAQkEMRYEFEu4YTUmbLjK0fCn062dXMv1EFrwMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB BQAEgYBz3A8wTfncgXzzrViUGLUSmrFfm0Oq0KUvokeqiGuQc1FRRMSTD+mSGUi1IgXCIAcu tfhrJFKkc2HCmOCOAhLwrYF46zwwCNnyF0ssu4COZr17lkbcMG6WGbu3+euItYcfunrDR57a AVp7x6osVY7D5dV2r14iU66JcejXK33CWgAAAAAAAA== --------------ms040302030203040902050607-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 9:10:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from studsboll.realworld.nu (a63.flamman.student.liu.se [130.236.218.63]) by hub.freebsd.org (Postfix) with ESMTP id 8AA7F37B417 for ; Fri, 22 Feb 2002 09:10:32 -0800 (PST) Received: from studsboll.realworld.nu (localhost [127.0.0.1]) by studsboll.realworld.nu (8.11.3/8.11.3) with SMTP id g1MHAUh10998 for ; Fri, 22 Feb 2002 18:10:31 +0100 (CET) (envelope-from doktorn@realworld.nu) Date: Fri, 22 Feb 2002 18:10:30 +0100 From: Rickard Borgmäster To: freebsd-net@freebsd.org Subject: IPSec VPN Questions, comments wanted :-) Message-Id: <20020222181030.5532a263.doktorn@realworld.nu> X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386-unknown-freebsd4.3) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm about to find a solutions t VPN-interconnect out branch offices. Today we have a main site with a /28-net where the network servers are located. Internal net is 10.0.0/24 with S-NAT for the servers. Branch offices use ICA protocol to connect to internal Windows Termnal server. Branch offices are rather small, tycically 1-3 laptop (Win2000/XP) computers and a network printer, connected to Internet via ADSL or ISDN. NAT addresses (192.168.1.x/24, each branch office uses same setup). Branch offices have static IP addresses, which will be passed in by the firewall. Branch office users typically travels a lot with their laptops, and need to connect to the main site from various locations. Firewall at main site is currently IPFilter on FreeBSD 4.3. This is what we want to acheive: 1)Connectivity from non-static addresses, encrypted. 2)Interconnect the branch office networks with main site network, encrypted. 3)User should never have to reconfigure laptop in order to connect to main site. This is the solution I had in mind: First of all: Upgrade main site firewall to latest FreeBSD-stable. 1) Create "Virtual Private Network" connections using built-in features of Win2000/XP, on the laptop computers. This is for use out-of-branch-office, ie at home, visiting customer/supplier. 2)Equip each branch office with a "multi-purpose" IPSec-capable firewall, ie Cisco 806, Multitech RF550VPN [1], Watchguard SOHO|tc. Set it up with an assigned private network id (ie, 10.0.1.0/28, 10.0.1.16/28, etc) per each branch office. The addresses will be provided to the laptops from this multi-purpose firewall via DHCP. 3)Now I hope the only differnce from the users point of view, would be that if he/she if out-of-office, the need to establish the transport-mode VPN connection->main site firewall, before they can use network services. If a user moves from one branch office to another, he/she only needs to plug his laptop in and should then be able to reach network services on the main site. Questionmarks: *Have I understood this right? ;) *With IPSec tunnel mode->Main site firewall, all branch office networks would be reachable from main site, right? Ie, from 10.0.0/24 I would be able to ping a network printer 10.0.1.12? *Should the users connect to the private addresses of the main site network (10.0.0/24) or the public addresses when they need to access network services? This is ofcourse a DNS matter, since we cannot put private addresses on a public DNS server. *Since the firewall must be set to accept IPSec connections from all source addresses, how does it know that it comes from an approved user? Is the connection authenticated using private keys or username/passwords or what? Don't you just love scenarios? =) Any ideas or feedback welcome. [1] Seems to be a nice product for this purpose. Low price (SEK3.000 / ~$300). Features NAT, Packet filtering, 4-port 10/100 Switch, PPPoE for automatic logon to ADSL provider, 5 Simultaneous IPSec tunnels, 700Kbps IPSec throughput, 6Mbps firewall throughput. Specs see: http://www.multitech.com/products/SOHO_VPN/ -- Rickard .--. .--. .----------------------------------------. | | | | .-. | Rickard Borgmäster | | | | |/ / | doktorn@sub.nu | .-^ | .--. | < | http://doktorn.sub.nu/ | ( o | ( () ) | |\ \ `----------------------------------------' `-----' `--' `--' `--' -- Rickard .--. .--. .----------------------------------------. | | | | .-. | Rickard Borgmäster | | | | |/ / | doktorn@sub.nu | .-^ | .--. | < | http://doktorn.sub.nu/ | ( o | ( () ) | |\ \ `----------------------------------------' `-----' `--' `--' `--' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 9:30:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 42BB637B405 for ; Fri, 22 Feb 2002 09:30:08 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g1MHU6n20333; Fri, 22 Feb 2002 09:30:06 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g1MHU6938450; Fri, 22 Feb 2002 09:30:06 -0800 (PST) (envelope-from jdp) Date: Fri, 22 Feb 2002 09:30:06 -0800 (PST) Message-Id: <200202221730.g1MHU6938450@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: larse@ISI.EDU Subject: Re: incorrect checksums with xl? In-Reply-To: <3C767749.3020302@isi.edu> References: <3C7547E0.8050805@isi.edu> <200202221643.g1MGhej38249@vashon.polstra.com> <3C767749.3020302@isi.edu> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <3C767749.3020302@isi.edu>, Lars Eggert wrote: > > You are running tcpdump on the system that's sending the "bad" > > packets, right? It makes perfect sense. The TCP/IP stack knows > > that the NIC is going to insert the checksums, so it doesn't bother > > calculating them itself. So BPF is handed packets in mbufs without > > any checksums. On the way out to the wire, the NIC hardware/firmware > > adds the checksums, but they don't show up in the mbufs that are being > > sent to BPF. If you run tcpdump on the receiving system instead, > > you'll find that the checksums seen there are valid. > > > > The same thing happens in the bge driver, because it also offloads > > checksum generation to the NIC. > > that makes total sense. I'd like to see the paragraph above in big, bold > letters in the xl(4) man page then - so far it doesn't discuss checksum > offloading at all. :-) I believe it's a fairly recent feature in the network stack that allows some drivers to take advantage of checksum offloading. I agree it would be nice if the individual driver man pages mentioned whether the NIC did offloading. On the other hand, the false checksum errors might better be documented in bpf(4) and tcpdump(1). There are other similar artifacts. One of them is seen when transmitting very short packets. Some NICs (e.g., the Intel 8254x) automatically pad these packets to the minimum Ethernet packet size while transmitting them. If you run tcpdump on the sending system, you'll see the short packets, before they are padded. If you run it on the receiving system, you'll see the padded packets. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 9:35:50 2002 Delivered-To: freebsd-net@freebsd.org Received: from db.nexgen.com (db.nexgen.com [66.92.98.149]) by hub.freebsd.org (Postfix) with SMTP id B86FF37B404 for ; Fri, 22 Feb 2002 09:35:47 -0800 (PST) Received: (qmail 4253 invoked from network); 22 Feb 2002 17:36:48 -0000 Received: from oxyetb.com (HELO alexus) (@66.92.98.145) by secure.nexgen.com with SMTP; 22 Feb 2002 17:36:48 -0000 Message-ID: <006501c1bbc7$5be0f500$0d00a8c0@alexus> From: "alexus" To: Subject: Fw: /kernel: arplookup xx.xxx.x.xx failed: could not allocate llinfo Date: Fri, 22 Feb 2002 12:35:45 -0500 Organization: NexGen MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org can someone explain me what does it means? i get this in my syslog /kernel: arplookup xx.xxx.x.xx failed: could not allocate llinfo /kernel: arpresolve: can't allocate llinfo for xx.xxx.x.xxrt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 9:38: 9 2002 Delivered-To: freebsd-net@freebsd.org Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by hub.freebsd.org (Postfix) with ESMTP id 2D8C337B400 for ; Fri, 22 Feb 2002 09:38:03 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA09609; Fri, 22 Feb 2002 09:37:49 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1MHbmJ01342; Fri, 22 Feb 2002 09:37:48 -0800 X-mProtect:  Fri, 22 Feb 2002 09:37:48 -0800 Nokia Silicon Valley Messaging Protection Received: from ipsec-7-58.iprg.nokia.com (205.226.7.58, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyeHTvo; Fri, 22 Feb 2002 09:37:45 PST Message-ID: <3C7682BF.99A66C3B@iprg.nokia.com> Date: Fri, 22 Feb 2002 09:41:19 -0800 From: Joe Eykholt Organization: Nokia IPRG X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: John Polstra Cc: net@FreeBSD.ORG, larse@ISI.EDU Subject: Re: incorrect checksums with xl? References: <3C7547E0.8050805@isi.edu> <200202221643.g1MGhej38249@vashon.polstra.com> <3C767749.3020302@isi.edu> <200202221730.g1MHU6938450@vashon.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It seems like along with the packet being sent up to bpf, there's a need for some flags that tell tcpdump about the packet. I haven't looked at the current implementation, but in another system, I found it useful to add a flag indicating whether the packet was being received or transmitted. Adding a flag indicating that no checksum generation has been done yet, but will be done by the NIC, would allow tcpdump to also ignore checksum errors on outgoing packets, or it could generate the checksum itself if displaying those bytes (in a hex output, e.g.). Joe Eykholt John Polstra wrote: > > In article <3C767749.3020302@isi.edu>, Lars Eggert wrote: > > > You are running tcpdump on the system that's sending the "bad" > > > packets, right? It makes perfect sense. The TCP/IP stack knows > > > that the NIC is going to insert the checksums, so it doesn't bother > > > calculating them itself. So BPF is handed packets in mbufs without > > > any checksums. On the way out to the wire, the NIC hardware/firmware > > > adds the checksums, but they don't show up in the mbufs that are being > > > sent to BPF. If you run tcpdump on the receiving system instead, > > > you'll find that the checksums seen there are valid. > > > > > > The same thing happens in the bge driver, because it also offloads > > > checksum generation to the NIC. > > > > that makes total sense. I'd like to see the paragraph above in big, bold > > letters in the xl(4) man page then - so far it doesn't discuss checksum > > offloading at all. :-) > > I believe it's a fairly recent feature in the network stack that > allows some drivers to take advantage of checksum offloading. I agree > it would be nice if the individual driver man pages mentioned whether > the NIC did offloading. On the other hand, the false checksum errors > might better be documented in bpf(4) and tcpdump(1). > > There are other similar artifacts. One of them is seen when > transmitting very short packets. Some NICs (e.g., the Intel 8254x) > automatically pad these packets to the minimum Ethernet packet size > while transmitting them. If you run tcpdump on the sending system, > you'll see the short packets, before they are padded. If you run it > on the receiving system, you'll see the padded packets. > > John > -- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chvgyam Trungpa > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 9:41:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id 49F4A37B405 for ; Fri, 22 Feb 2002 09:41:03 -0800 (PST) Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Postfix) with ESMTP id 74AA35D13; Fri, 22 Feb 2002 09:41:02 -0800 (PST) To: John Polstra Cc: net@freebsd.org, larse@ISI.EDU Subject: Re: incorrect checksums with xl? In-reply-to: Your message of "Fri, 22 Feb 2002 09:30:06 PST." <200202221730.g1MHU6938450@vashon.polstra.com> Date: Fri, 22 Feb 2002 09:41:02 -0800 From: "Kevin Oberman" Message-Id: <20020222174102.74AA35D13@ptavv.es.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Date: Fri, 22 Feb 2002 09:30:06 -0800 (PST) > From: John Polstra > Sender: owner-freebsd-net@FreeBSD.ORG > > In article <3C767749.3020302@isi.edu>, Lars Eggert wrote: > > > You are running tcpdump on the system that's sending the "bad" > > > packets, right? It makes perfect sense. The TCP/IP stack knows > > > that the NIC is going to insert the checksums, so it doesn't bother > > > calculating them itself. So BPF is handed packets in mbufs without > > > any checksums. On the way out to the wire, the NIC hardware/firmware > > > adds the checksums, but they don't show up in the mbufs that are being > > > sent to BPF. If you run tcpdump on the receiving system instead, > > > you'll find that the checksums seen there are valid. > > > > > > The same thing happens in the bge driver, because it also offloads > > > checksum generation to the NIC. > > > > that makes total sense. I'd like to see the paragraph above in big, bold > > letters in the xl(4) man page then - so far it doesn't discuss checksum > > offloading at all. :-) > > I believe it's a fairly recent feature in the network stack that > allows some drivers to take advantage of checksum offloading. I agree > it would be nice if the individual driver man pages mentioned whether > the NIC did offloading. On the other hand, the false checksum errors > might better be documented in bpf(4) and tcpdump(1). > > There are other similar artifacts. One of them is seen when > transmitting very short packets. Some NICs (e.g., the Intel 8254x) > automatically pad these packets to the minimum Ethernet packet size > while transmitting them. If you run tcpdump on the sending system, > you'll see the short packets, before they are padded. If you run it > on the receiving system, you'll see the padded packets. It should be documented in the bpf(4) page that some drivers may move some framing functionality to hardware, that bpf packet captures of transmit data will be on the data sent to the driver and not the data on the wire and that the man page for the driver involved should be checked for details . A note in tcpdump(1) would also be a "good thing" IMHO. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 9:44: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 8FFCE37B400 for ; Fri, 22 Feb 2002 09:44:00 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g1MHhwn20490; Fri, 22 Feb 2002 09:43:58 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g1MHhwh38542; Fri, 22 Feb 2002 09:43:58 -0800 (PST) (envelope-from jdp) Date: Fri, 22 Feb 2002 09:43:58 -0800 (PST) Message-Id: <200202221743.g1MHhwh38542@vashon.polstra.com> To: net@freebsd.org From: John Polstra Cc: jre@IPRG.nokia.com Subject: Re: incorrect checksums with xl? In-Reply-To: <3C7682BF.99A66C3B@iprg.nokia.com> References: <3C7547E0.8050805@isi.edu> <3C767749.3020302@isi.edu> <200202221730.g1MHU6938450@vashon.polstra.com> <3C7682BF.99A66C3B@iprg.nokia.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <3C7682BF.99A66C3B@iprg.nokia.com>, Joe Eykholt wrote: > > It seems like along with the packet being sent up to bpf, there's > a need for some flags that tell tcpdump about the packet. I haven't > looked at the current implementation, but in another system, I found > it useful to add a flag indicating whether the packet was being received > or transmitted. > > Adding a flag indicating that no checksum generation has been done yet, > but will be done by the NIC, would allow tcpdump to also ignore checksum > errors on outgoing packets, or it could generate the checksum itself > if displaying those bytes (in a hex output, e.g.). Remember, bpf is used by many things besides tcpdump. Adding these flags would require extending the bpf API. They couldn't be added for the default case, because that would break compatibility with other applications. They'd have to be enabled specifically, by means of a new ioctl. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 12:58:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id C64D337B400 for ; Fri, 22 Feb 2002 12:58:54 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id BCD3CE5008; Fri, 22 Feb 2002 15:58:53 -0500 (EST) Date: Fri, 22 Feb 2002 15:58:53 -0500 From: Richard A Steenbergen To: John Polstra Cc: net@freebsd.org, jre@IPRG.nokia.com Subject: Re: incorrect checksums with xl? Message-ID: <20020222205853.GC413@overlord.e-gerbil.net> References: <3C7547E0.8050805@isi.edu> <3C767749.3020302@isi.edu> <200202221730.g1MHU6938450@vashon.polstra.com> <3C7682BF.99A66C3B@iprg.nokia.com> <200202221743.g1MHhwh38542@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202221743.g1MHhwh38542@vashon.polstra.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Feb 22, 2002 at 09:43:58AM -0800, John Polstra wrote: > In article <3C7682BF.99A66C3B@iprg.nokia.com>, > Joe Eykholt wrote: > > > > It seems like along with the packet being sent up to bpf, there's > > a need for some flags that tell tcpdump about the packet. I haven't > > looked at the current implementation, but in another system, I found > > it useful to add a flag indicating whether the packet was being received > > or transmitted. > > > > Adding a flag indicating that no checksum generation has been done yet, > > but will be done by the NIC, would allow tcpdump to also ignore checksum > > errors on outgoing packets, or it could generate the checksum itself > > if displaying those bytes (in a hex output, e.g.). > > Remember, bpf is used by many things besides tcpdump. Adding these > flags would require extending the bpf API. They couldn't be added for > the default case, because that would break compatibility with other > applications. They'd have to be enabled specifically, by means of a > new ioctl. You could always just add a flags field to struct bpf_hdr, and hope noone is stupid enough to hardcode the size. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 13:46:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from topaz.mdcc.cx (topaz.mdcc.cx [212.204.230.141]) by hub.freebsd.org (Postfix) with ESMTP id E85B437B417; Fri, 22 Feb 2002 13:46:25 -0800 (PST) Received: from k7.mavetju.org (topaz.mdcc.cx [212.204.230.141]) by topaz.mdcc.cx (Postfix) with ESMTP id 905B12B6BE; Fri, 22 Feb 2002 22:46:21 +0100 (CET) Received: by k7.mavetju.org (Postfix, from userid 1001) id 8511D247; Sat, 23 Feb 2002 08:46:16 +1100 (EST) Date: Sat, 23 Feb 2002 08:46:16 +1100 From: Edwin Groothuis To: "JINMEI Tatuya / ?$B?@L@C#:H?(B" Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: IPv6-over-IPv4 problems since the upgrade to 4.5 Message-ID: <20020223084616.G492@k7.mavetju.org> Mail-Followup-To: Edwin Groothuis , "JINMEI Tatuya / ?$B?@L@C#:H?(B" , freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG References: <0D9185CE635BD511ACA50090277A6FCF1359DB@axcs18.cos.agilent.com> <20020216130842.A19081@energyhq.homeip.net> <20020217122510.D491@k7.mavetju.org> <20020222234829.F492@k7.mavetju.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jinmei@isl.rdc.toshiba.co.jp on Fri, Feb 22, 2002 at 11:49:59PM +0900 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Feb 22, 2002 at 11:49:59PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote: > >>>>> On Fri, 22 Feb 2002 23:48:29 +1100, > >>>>> Edwin Groothuis said: > > >> > I found what caused this. he.net uses the "route add -inet6 default > >> > " statement while freenet6.net uses "route add -inet6 > >> > default -interface gif0" statement. > >> > >> Could you tell me the exact address of ? Is it a > >> link-local address, or a global one? > > > Routing tables: > > default 3ffe:b80:2:460::1 UGSc gif0 > > 3ffe:b80:2:460::1 3ffe:b80:2:460::2 UH gif0 > > 3ffe:b80:2:460::2 link#9 UHL lo0 > > > And the interface configuration: > > gif0: flags=8051 mtu 1280 > > tunnel inet 203.173.130.126 --> 206.123.31.114 > > inet6 fe80::250:8bff:feb9:2d24%gif0 prefixlen 64 scopeid 0x9 > > inet6 3ffe:b80:2:460::2 --> 3ffe:b80:2:460::1 prefixlen 128 > > Hmm, and what command did you type to cause this problem? If possible, > please give me the network topology as well. The problem was when "route add -inet6 default -interface gif0" was used instead of the "route ... ". For the rest the configuration and the commands were the same. This is a layout of the 'network': +----------------------------------------------+ |MyBox | |----------------------------------------------| +- ISP ---|tun0 by ppp: | | | - 203.173.130.71/24 -> 203.56.8.99 | | | - fe80::250:8bff:feb9:2d24%tun0 prefixlen 64 | | |gif0 tunnel to 206.123.31.114 via tun0 | | | - 3ffe:b80:2:460::2 prefixlen 128 | | |vmnet1: | Internet | - 192.168.0.1/24 | | | - fe80::250:8bff:feb9:2d24%tun0 prefixlen 64 | | |fxp0: |--- Mac with | | - 192.168.1.1/24 | 192.168.1.2 | | - fe80::250:8bff:feb9:2d24%fxp0 prefixlen 64 | | +----------------------------------------------+ | | | +----------------------------------------------+ | |FreeNet6.net | | |----------------------------------------------+ +- ISP ---|some interface | | - 206.123.31.114/something | |IPv6 tunnel to 203.173.130.71 | | - 3ffe:b80:2:460::1 prefixlen 128 | +----------------------------------------------+ The symptons were that if I setup a TCP-session, the original message is at: http://www.freebsd.org/cgi/getmsg.cgi?fetch=279914+284924+/usr/local/www/db/text/2002/freebsd-hackers/20020217.freebsd-hackers Thanks for your questions, Edwin -- Edwin Groothuis | Personal website: http://www.MavEtJu.org edwin@mavetju.org | Interested in MUDs? Visit Fatal Dimensions: ------------------+ http://www.FatalDimensions.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 14:37:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from idealso.com (idealso.com [216.122.250.84]) by hub.freebsd.org (Postfix) with ESMTP id B42BE37B404 for ; Fri, 22 Feb 2002 14:37:26 -0800 (PST) Received: from att (12-245-208-165.client.attbi.com [12.245.208.165]) by idealso.com (8.11.0/8.11.0) with SMTP id g1MMbQD68196 for ; Fri, 22 Feb 2002 17:37:26 -0500 (EST) (envelope-from jeff@idealso.com) Reply-To: From: "Jeff Lawton" To: Subject: FW: 3com gigabit 3c996b-t Date: Fri, 22 Feb 2002 17:41:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C1BBC8.195C0980" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C1BBC8.195C0980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am having trouble getting a 3com 3c996b-t to installed correctly. Is here a reference on how to properly set up the bge(4) driver. I am useing 4.5 release Jeff ------=_NextPart_000_0020_01C1BBC8.195C0980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

I am having trouble getting a 3com 3c996b-t = to installed correctly. Is = here a reference on how to properly set up = the bge(4) driver. I am useing 4.5 release

 

 

 

Jeff<= /p>

 <= /p>

------=_NextPart_000_0020_01C1BBC8.195C0980-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 14:54:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 3F62337B442 for ; Fri, 22 Feb 2002 14:52:52 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 3A8365EF2; Fri, 22 Feb 2002 23:52:51 +0100 (CET) Date: Fri, 22 Feb 2002 23:52:51 +0100 From: Jesper Skriver To: Jeff Lawton Cc: freebsd-net@FreeBSD.ORG Subject: Re: FW: 3com gigabit 3c996b-t Message-ID: <20020222235251.A32972@FreeBSD.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jeff@idealso.com on Fri, Feb 22, 2002 at 05:41:03PM -0500 X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5 5EB4 22AB F0EC F956 1C31 X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Feb 22, 2002 at 05:41:03PM -0500, Jeff Lawton wrote: > I am having trouble getting a 3com 3c996b-t to installed correctly. Is > here a reference on how to properly set up the bge(4) driver. I am > useing 4.5 release If you told what the problem was, it would be a whole lot easier to help ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 15:54:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from idealso.com (idealso.com [216.122.250.84]) by hub.freebsd.org (Postfix) with ESMTP id 4F5CB37B402 for ; Fri, 22 Feb 2002 15:54:45 -0800 (PST) Received: from att (12-245-208-165.client.attbi.com [12.245.208.165]) by idealso.com (8.11.0/8.11.0) with SMTP id g1MNshD80598 for ; Fri, 22 Feb 2002 18:54:44 -0500 (EST) (envelope-from jeff@idealso.com) Reply-To: From: "Jeff Lawton" To: Subject: RE: 3com gigabit 3c996b-t Date: Fri, 22 Feb 2002 18:58:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <20020222235251.A32972@FreeBSD.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bge detects the card and it shows up on ifconfig it does not detect 1000basetx on autoselect even though the card and the switch both register 1000baset. I connected it to a 100base t port and it seems to work fine. How do I get it to switch to 1000baset This is the bge section of ifconfig bge0: flags=8843 mtu 1500 options=3 inet 192.168.0.166 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::204:76ff:fee0:12a9%bge0 prefixlen 64 scopeid 0x1 ether 00:04:76:e0:12:a9 media: Ethernet autoselect (100baseTX ) status: active Jeff -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Jesper Skriver Sent: Friday, February 22, 2002 5:53 PM To: Jeff Lawton Cc: freebsd-net@FreeBSD.ORG Subject: Re: FW: 3com gigabit 3c996b-t On Fri, Feb 22, 2002 at 05:41:03PM -0500, Jeff Lawton wrote: > I am having trouble getting a 3com 3c996b-t to installed correctly. Is > here a reference on how to properly set up the bge(4) driver. I am > useing 4.5 release If you told what the problem was, it would be a whole lot easier to help ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 16:27:15 2002 Delivered-To: freebsd-net@freebsd.org Received: from idealso.com (idealso.com [216.122.250.84]) by hub.freebsd.org (Postfix) with ESMTP id D29A237B400 for ; Fri, 22 Feb 2002 16:27:05 -0800 (PST) Received: from att (12-245-208-165.client.attbi.com [12.245.208.165]) by idealso.com (8.11.0/8.11.0) with SMTP id g1N0R4D87613 for ; Fri, 22 Feb 2002 19:27:04 -0500 (EST) (envelope-from jeff@idealso.com) Reply-To: From: "Jeff Lawton" To: Subject: 3com gigabit 3c996b-t Date: Fri, 22 Feb 2002 19:30:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C1BBD7.6A706C80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C1BBD7.6A706C80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On 100baset it only works for a few minuites I can mount other nfs drives and ftp to other machines. But when I ssh in to it. I get in and about 4 commands, it disconnects and will not let me back in and It can no longer connect to anything either. Jeff Lawton Ideal Solution, LLC ------=_NextPart_000_0028_01C1BBD7.6A706C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

On 100baset it only works for a few minuites I can mount other = nfs drives and ftp to other machines. But when I ssh in to it. I get in and = about 4 commands, it disconnects and will not let me back in and It can no = longer connect to anything either.

 

Jeff Lawton<= /p>

Ideal Solution, = LLC<= /p>

 <= /p>

------=_NextPart_000_0028_01C1BBD7.6A706C80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 18:55:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from idealso.com (idealso.com [216.122.250.84]) by hub.freebsd.org (Postfix) with ESMTP id 2304C37B405; Fri, 22 Feb 2002 18:55:28 -0800 (PST) Received: from att (12-245-208-165.client.attbi.com [12.245.208.165]) by idealso.com (8.11.0/8.11.0) with SMTP id g1N2tMD20416; Fri, 22 Feb 2002 21:55:27 -0500 (EST) (envelope-from jeff@idealso.com) Reply-To: From: "Jeff Lawton" To: , Subject: siocsifmedia error w/bge driver Date: Fri, 22 Feb 2002 21:58:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am attempting to install a 3com 996b-t on a 4.5 i386 machine and I receive “siocsifmedia Device Not Configured” when I attempt to for it into 1000basetx mode with the following command: Ifconfig bge0 media 1000baseTX Any help with this is greatly appreciated. Jeff Lawton Ideal Solution, LLC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 19:39:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from gw.gbch.net (gw.gbch.net [203.143.238.93]) by hub.freebsd.org (Postfix) with SMTP id CDAA337B400 for ; Fri, 22 Feb 2002 19:39:22 -0800 (PST) Received: (qmail 48407 invoked by uid 1001); 23 Feb 2002 13:39:20 +1000 X-Posted-By: GJB-Post 2.23 27-Nov-2001 X-Operating-System: FreeBSD 4.2-RELEASE i386 X-Uptime: 44 days, 20 hrs X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-GPG-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-PGP-Public-Keys: http://www.gbch.net/keys.html Message-Id: Date: Sat, 23 Feb 2002 13:39:20 +1000 From: Greg Black To: net@freebsd.org Subject: ppp -nat fails with adsl, but ok with modem Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've had ppp -nat working just fine over a normal modem link, but it is not working at all well on my ADSL link to the same provider. To quantify "not working at all well", although I can ping and traceroute ok from the hosts on my LAN, HTTP and FTP traffic is so slow and bursty as to be useless. Clicking on a link with Netscape will see short bursts of data with long periods (of a minute or more) where it says "stalled". Clicking on from my gateway host gets the page in an eye-blink, but on the NAT hosts, it will take 40 seconds to load the top banner and the "FreeBSD GNOME News Flash" heading, then another delay of 40 or so seconds before the rest of the page will be displayed. Even then, Netscape thinks it has stalled and keeps waiting for the last bit of data. With FTP, a small transfer (e.g., a directory listing of / on ftp.freebsd.org) will complete normally; but something slightly larger (e.g., a listing of /pub/FreeBSD on the same server), will produce: ftp> cd /pub/FreeBSD 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for '/bin/ls'. ftp: netin: Connection reset by peer 226 Transfer complete. ftp> quit 421 Timeout (60 seconds): closing control connection. If I do the same things from the host that is connected to the modem(s), everything works fine, for both types of connections. I'm finding this very frustrating, and I'm wondering if there's something weird about PPPoE with the ADSL link that needs some special magic in order for things to work properly. If anybody can point me at the truth, I'd be most grateful. Alternatively, if anybody can suggest steps I could take to identify the nature of the problem, that would also be most welcome. Greg Black To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 21:25:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from promiscuous.dyndns.org (12-248-252-154.client.attbi.com [12.248.252.154]) by hub.freebsd.org (Postfix) with ESMTP id 30DBC37B400 for ; Fri, 22 Feb 2002 21:25:52 -0800 (PST) Received: from sensor (win2k [192.168.1.107]) by promiscuous.dyndns.org (Postfix) with SMTP id 90B3B52BC6 for ; Fri, 22 Feb 2002 23:17:12 -0600 (CST) Message-ID: <000501c1bc2a$8bfac3c0$6b01a8c0@remingtonltd.com> From: "Onie Camara" To: Subject: subscribe Date: Fri, 22 Feb 2002 23:25:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org subscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 22 23:33:58 2002 Delivered-To: freebsd-net@freebsd.org Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by hub.freebsd.org (Postfix) with SMTP id 0806237B402 for ; Fri, 22 Feb 2002 23:33:56 -0800 (PST) Message-ID: <20020223073355.69284.qmail@web11604.mail.yahoo.com> Received: from [202.94.3.60] by web11604.mail.yahoo.com via HTTP; Fri, 22 Feb 2002 23:33:55 PST Date: Fri, 22 Feb 2002 23:33:55 -0800 (PST) From: tang hongbin Subject: I can't build freebsd4.2 kernel with option NETGRAPH_MPPC_ENCRYPTION?? To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear all; When I selected options NETGRAPH_MPPC_ENCRYPTION, rather than options NETGRAPH_MPPC_COMPRESSION, in kernel config and tried to rebuild freebsd v42. kernel, I failed. The system printed the error messages as following ..... linking kernel ng_mppc.o: In function `ng_mppc_constructor': ng_mppc.o(.text+0xc): undefined reference to `M_NETGRAPH' ng_mppc.o(.text+0x40): undefined reference to `ng_make_node_common' ng_mppc.o(.text+0x59): undefined reference to `M_NETGRAPH' ng_mppc.o: In function `ng_mppc_rcvmsg': ng_mppc.o(.text+0x194): undefined reference to `M_NETGRAPH' ng_mppc.o(.text+0x1bd): undefined reference to `M_NETGRAPH' ng_mppc.o(.text+0x2b7): undefined reference to `M_NETGRAPH' ng_mppc.o(.text+0x2c6): undefined reference to `M_NETGRAPH' ng_mppc.o(.text+0x335): more undefined references to `M_NETGRAPH' follow ng_mppc.o: In function `ng_mppc_rcvdata': .... The system doesn't know where macro M_NETGRAPH. Could you please rebuild your kernel with "options NETGRAPH_MPPC_ENCRYPTION " in kernel config file. If you succeeded in doing so, please let me share your success. thanks bill.tang __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 0:51: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21308.mail.yahoo.com (web21308.mail.yahoo.com [216.136.128.174]) by hub.freebsd.org (Postfix) with SMTP id B325237B402 for ; Sat, 23 Feb 2002 00:51:02 -0800 (PST) Message-ID: <20020223085102.65678.qmail@web21308.mail.yahoo.com> Received: from [131.247.2.17] by web21308.mail.yahoo.com via HTTP; Sat, 23 Feb 2002 00:51:02 PST Date: Sat, 23 Feb 2002 00:51:02 -0800 (PST) From: Praveen Ikkurthy Subject: Is Dell truemobile 1150 supported? To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All! Could anyone of you please let me know whether Dell TrueMobile 1150 Wireless PCMCIA card supported on FreeBSD. Thank you. Regards, Praveen __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 1:18:10 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.jeamland.net (rafe.jeamland.net [203.18.243.114]) by hub.freebsd.org (Postfix) with ESMTP id 867B737B400 for ; Sat, 23 Feb 2002 01:18:07 -0800 (PST) Received: from ratchet.int.jeamland.net (ratchet.jeamland.net [210.15.217.227]) by mail.jeamland.net (Postfix) with ESMTP id 4FC2270605; Sat, 23 Feb 2002 20:17:59 +1100 (EST) Subject: Re: Is Dell truemobile 1150 supported? From: Benno Rice To: Praveen Ikkurthy Cc: freebsd-net@freebsd.org In-Reply-To: <20020223085102.65678.qmail@web21308.mail.yahoo.com> References: <20020223085102.65678.qmail@web21308.mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jsouGja3JxNLFq0Tqf8T" X-Mailer: Evolution/1.0.2 Date: 23 Feb 2002 21:17:57 +1200 Message-Id: <1014455879.396.3.camel@ratchet.jeamland.net> Mime-Version: 1.0 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=-jsouGja3JxNLFq0Tqf8T Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2002-02-23 at 20:51, Praveen Ikkurthy wrote: > Hi All! >=20 > Could anyone of you please let me know whether Dell > TrueMobile 1150 Wireless PCMCIA card supported on > FreeBSD. It certainly is, and you can find this out by checking /etc/defaults/pccard.conf: ... # Dell TrueMobile (OEMed Lucent WaveLAN/IEEE) card "Dell" "TrueMobile 1150 Series PC Card" config 0x1 "wi" ? insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop ... and it's also supported by NEWCARD: pccard1: CIS version PC Card Standard 5.0 pccard1: CIS info: Dell, TrueMobile 1150 Series PC Card, Version 01.01,=20 pccard1: Manufacturer code 0x156, product 0x2 pccard1: function 0: network adapter, ccr addr 3e0 mask 1 pccard1: function 0, config table entry 1: I/O card; irq mask ffff; iomask 6, iospace 0-3f; rdybsy_active wp_active bvd_active io16 irqpulse irqlevel wi0: at port 0xe000-0xe03f irq 11 function 0 config 1 on pccard1 wi0: 802.11 address: 00:02:2d:40:0a:32 wi0: using Lucent chip or unknown chip (This message is being sent via a Dell TrueMobile 1150 =3D)) --=20 Benno Rice benno@FreeBSD.org --=-jsouGja3JxNLFq0Tqf8T Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjx3XkUACgkQXjRwWofFmQkw0wCcDndWbeyP0Oxna5Wr94auzq9G 7ZQAn2ajMQDgx8tLUILVS7oVKm3ACnSQ =gW32 -----END PGP SIGNATURE----- --=-jsouGja3JxNLFq0Tqf8T-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 3:50:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id F098B37B405; Sat, 23 Feb 2002 03:50:36 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g1NBoX450311; Sat, 23 Feb 2002 13:50:33 +0200 (EET) (envelope-from ru) Date: Sat, 23 Feb 2002 13:50:33 +0200 From: Ruslan Ermilov To: "Crist J. Clark" Cc: net@FreeBSD.org Subject: Re: TCP Connections to a Broadcast Address Message-ID: <20020223115033.GB47437@sunbay.com> References: <20020222022626.A83807@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020222022626.A83807@blossom.cjclark.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Feb 22, 2002 at 02:26:26AM -0800, Crist J. Clark wrote: > BSD-based TCP/IP code have a bug with respect to creating TCP > connections to a broadcast address. This bug can potentially be a > security vulnerability when firewall administrators assume that the > TCP implementation works correctly and does not block broadcast > addresses. > > > The Standard: > > TCP connections are only valid when the destination address is a > unicast address. That is, the destination must not be a multicast or > broadcast address. One place this is clearly specified in the > Standards is RFC 1122 (everyone's very most favorite RFC), > > 4.2.3.10 Remote Address Validation > > ... > > A TCP implementation MUST silently discard an incoming SYN > segment that is addressed to a broadcast or multicast > address. > > > The Bug: > > Uncorrected BSD-based TCP implementations do not actually check if the > destination IP address is a broadcast address. Rather, the packet's > link layer address is checked. Here is the code from FreeBSD's > tcp_input.c, > > * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN > * in_broadcast() should never return true on a received > * packet with M_BCAST not set. > * > * Packets with a multicast source address should also > * be discarded. > */ > if (m->m_flags & (M_BCAST|M_MCAST)) > goto drop; > #ifdef INET6 > if (isipv6) { > if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst) || > IN6_IS_ADDR_MULTICAST(&ip6->ip6_src)) > goto drop; > } else > #endif > if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || > IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || > ip->ip_src.s_addr == htonl(INADDR_BROADCAST)) > goto drop; > > The comment in the code reveals the reason for the mistake. The > authors assume that no one would accidentally or maliciously break the > rules. One can easily send packets with a unicast link-layer address, > but containing an IP broadcast address. No check is made in the above > code for such a pathological situation. > Nice catch! > Adding an in_broadcast() check trivially fixes the problem. Here is a > patch (which fixes the comment too), > > Index: src/sys/netinet/tcp_input.c > =================================================================== > RCS file: /export/ncvs/src/sys/netinet/tcp_input.c,v > retrieving revision 1.146 > diff -u -r1.146 tcp_input.c > --- src/sys/netinet/tcp_input.c 4 Jan 2002 17:21:27 -0000 1.146 > +++ src/sys/netinet/tcp_input.c 17 Feb 2002 12:54:39 -0000 > @@ -798,11 +798,10 @@ > } > /* > * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN > - * in_broadcast() should never return true on a received > - * packet with M_BCAST not set. > - * > - * Packets with a multicast source address should also > - * be discarded. > + * > + * It is possible for a malicious (or misconfigured) > + * attacker to send unicast link-layer packets with a > + * broadcast IP address. Use in_broadcast() to find them. > */ > if (m->m_flags & (M_BCAST|M_MCAST)) > goto drop; > @@ -815,7 +814,8 @@ > #endif > if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || > IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || > - ip->ip_src.s_addr == htonl(INADDR_BROADCAST)) > + ip->ip_src.s_addr == htonl(INADDR_BROADCAST) || > + in_broadcast(ip->ip_dst, m->m_pkthdr.rcvif)) > goto drop; > /* > * SYN appears to be valid; create compressed TCP state > The patch is incomplete (see dropwithreset below). Here's the tcp_input.c part of the original delta that introduced this bug: : Script started on Sat Feb 23 13:37:18 2002 : $ sccs prs -r7.35 tcp_input.c : D 7.35 93/04/07 19:28:08 sklower 159 158 00007/00003/01623 : MRs: : COMMENTS: : Mostly changes recommended by jch for variable subnets & multiple : IP addresses per physical interface. May require further work. : : $ sccs sccsdiff -up -r7.34 -r7.35 tcp_input.c : SCCS/s.tcp_input.c: 7.34 vs. 7.35 : --- /tmp/get.19874.7.34 Sat Feb 23 13:37:41 2002 : +++ /tmp/get.19874.7.35 Sat Feb 23 13:37:41 2002 : @@ -518,9 +518,13 @@ findpcb: : goto dropwithreset; : if ((tiflags & TH_SYN) == 0) : goto drop; : - /* RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN */ : + /* : + * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN : + * in_broadcast() should never return true on a received : + * packet with M_BCAST not set. : + */ : if (m->m_flags & (M_BCAST|M_MCAST) || : - in_broadcast(ti->ti_dst) || IN_MULTICAST(ti->ti_dst.s_addr)) : + IN_MULTICAST(ti->ti_dst.s_addr)) : goto drop; : am = m_get(M_DONTWAIT, MT_SONAME); /* XXX */ : if (am == NULL) : @@ -1271,7 +1275,7 @@ dropwithreset: : * Don't bother to respond if destination was broadcast/multicast. : */ : if ((tiflags & TH_RST) || m->m_flags & (M_BCAST|M_MCAST) || : - in_broadcast(ti->ti_dst) || IN_MULTICAST(ti->ti_dst.s_addr)) : + IN_MULTICAST(ti->ti_dst.s_addr)) : goto drop; : if (tiflags & TH_ACK) : tcp_respond(tp, ti, m, (tcp_seq)0, ti->ti_ack, TH_RST); : $ : Script done on Sat Feb 23 13:37:43 2002 I think you should just back the CSRG revision 7.35 out of tcp_input.c, mentioning what was wrong with removing in_broadcast() check. route add -net 192.168.4 192.168.1.1 ping 192.168.4.255 on a directly attached 192.168.1 network isn't a "malicious use". Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 4:28:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 007C037B402; Sat, 23 Feb 2002 04:28:31 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020223122830.MQUV2626.rwcrmhc51.attbi.com@blossom.cjclark.org>; Sat, 23 Feb 2002 12:28:30 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1NCST217289; Sat, 23 Feb 2002 04:28:29 -0800 (PST) (envelope-from cjc) Date: Sat, 23 Feb 2002 04:28:28 -0800 From: "Crist J. Clark" To: Ruslan Ermilov Cc: net@FreeBSD.ORG Subject: Re: TCP Connections to a Broadcast Address Message-ID: <20020223042828.E16048@blossom.cjclark.org> References: <20020222022626.A83807@blossom.cjclark.org> <20020223115033.GB47437@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020223115033.GB47437@sunbay.com>; from ru@FreeBSD.ORG on Sat, Feb 23, 2002 at 01:50:33PM +0200 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Feb 23, 2002 at 01:50:33PM +0200, Ruslan Ermilov wrote: [snip] > Nice catch! Igor M Podlesny , PR misc/35022, caught it. I just analyzed it. [snip] > The patch is incomplete (see dropwithreset below). Here's the tcp_input.c > part of the original delta that introduced this bug: I considered what to do for non-SYN segments, but I didn't see a requirement in the standards (I may have missed it), so I just didn't touch it. > : Script started on Sat Feb 23 13:37:18 2002 > : $ sccs prs -r7.35 tcp_input.c > : D 7.35 93/04/07 19:28:08 sklower 159 158 00007/00003/01623 > : MRs: > : COMMENTS: > : Mostly changes recommended by jch for variable subnets & multiple > : IP addresses per physical interface. May require further work. [snip] > I think you should just back the CSRG revision 7.35 out of tcp_input.c, > mentioning what was wrong with removing in_broadcast() check. Where'd you pull this out? I'll integrate this version. > route add -net 192.168.4 192.168.1.1 > ping 192.168.4.255 > > on a directly attached 192.168.1 network isn't a "malicious use". Then I would put that under the "misconfigured" header. The machine you are pinging from would have to be local to 192.168.4.0/24 also, why are you routing it through 192.168.1.1? But there may be some situations that I have not considered where one might wish to do that. Anyway, if there are legit configurations where this rears its head, it is even worse. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 4:45:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id E28EA37B402; Sat, 23 Feb 2002 04:45:41 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g1NCjan54144; Sat, 23 Feb 2002 14:45:36 +0200 (EET) (envelope-from ru) Date: Sat, 23 Feb 2002 14:45:35 +0200 From: Ruslan Ermilov To: "Crist J. Clark" Cc: net@FreeBSD.ORG Subject: Re: TCP Connections to a Broadcast Address Message-ID: <20020223124535.GB52291@sunbay.com> References: <20020222022626.A83807@blossom.cjclark.org> <20020223115033.GB47437@sunbay.com> <20020223042828.E16048@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020223042828.E16048@blossom.cjclark.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Feb 23, 2002 at 04:28:28AM -0800, Crist J. Clark wrote: > On Sat, Feb 23, 2002 at 01:50:33PM +0200, Ruslan Ermilov wrote: > [snip] > > > Nice catch! > > Igor M Podlesny , PR misc/35022, caught it. I just > analyzed it. > > [snip] > > > The patch is incomplete (see dropwithreset below). Here's the tcp_input.c > > part of the original delta that introduced this bug: > > I considered what to do for non-SYN segments, but I didn't see a > requirement in the standards (I may have missed it), so I just didn't > touch it. > > > : Script started on Sat Feb 23 13:37:18 2002 > > : $ sccs prs -r7.35 tcp_input.c > > : D 7.35 93/04/07 19:28:08 sklower 159 158 00007/00003/01623 > > : MRs: > > : COMMENTS: > > : Mostly changes recommended by jch for variable subnets & multiple > > : IP addresses per physical interface. May require further work. > > [snip] > > > I think you should just back the CSRG revision 7.35 out of tcp_input.c, > > mentioning what was wrong with removing in_broadcast() check. > > Where'd you pull this out? I'll integrate this version. > > > route add -net 192.168.4 192.168.1.1 > > ping 192.168.4.255 > > > > on a directly attached 192.168.1 network isn't a "malicious use". > > Then I would put that under the "misconfigured" header. The machine > you are pinging from would have to be local to 192.168.4.0/24 also, > why are you routing it through 192.168.1.1? But there may be some > situations that I have not considered where one might wish to do > that. > Um, why? Router B: if0 (192.168.1.1/24) and if1 (192.168.4.1/24) Router A: if0 (192.168.1.2/24) On router A: route add -net 192.168.4 192.168.1.1, telnet 192.168.4.255. Or even simpler: Router: if0 (192.168.1.1/24 and 192.168.100.1/24) Host: if0 (192.168.1.2, default gateway 192.168.1.1) On host: $ ping 192.168.100.255 PING 192.168.100.255 (192.168.100.255): 56 data bytes 64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=0.245 ms 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.207 ms 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.207 ms ^C --- 192.168.100.255 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.207/0.220/0.245/0.018 ms $ telnet 192.168.100.255 25 Trying 192.168.100.255... Connected to 192.168.100.255. Escape character is '^]'. 220 my.router.local.net ESMTP Sendmail 8.11.6/8.11.2; Sat, 23 Feb 2002 14:39:21 +0200 (EET) > Anyway, if there are legit configurations where this rears its head, > it is even worse. > Yes. :-) Cheers, -- Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 4:50: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from relay1.macomnet.ru (relay1.macomnet.ru [195.128.64.10]) by hub.freebsd.org (Postfix) with ESMTP id 72EDF37B404; Sat, 23 Feb 2002 04:49:57 -0800 (PST) Received: from news1.macomnet.ru (news1.macomnet.ru [195.128.64.14]) by relay1.macomnet.ru (8.11.6/8.11.6) with ESMTP id g1NCnuH7642734; Sat, 23 Feb 2002 15:49:56 +0300 (MSK) Date: Sat, 23 Feb 2002 15:49:55 +0300 (MSK) From: Maxim Konovalov To: "Crist J. Clark" Cc: Ruslan Ermilov , Subject: Re: TCP Connections to a Broadcast Address In-Reply-To: <20020223042828.E16048@blossom.cjclark.org> Message-ID: <20020223154842.G31228-100000@news1.macomnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 04:28-0800, Feb 23, 2002, Crist J. Clark wrote: > On Sat, Feb 23, 2002 at 01:50:33PM +0200, Ruslan Ermilov wrote: > [snip] > > > Nice catch! > > Igor M Podlesny , PR misc/35022, caught it. I just > analyzed it. Isn't kern/19722 about the same bug? > [snip] maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 7:25:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 2377A37B402; Sat, 23 Feb 2002 07:25:21 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020223152520.WZSK1147.rwcrmhc52.attbi.com@blossom.cjclark.org>; Sat, 23 Feb 2002 15:25:20 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1NFPKq22652; Sat, 23 Feb 2002 07:25:20 -0800 (PST) (envelope-from cjc) Date: Sat, 23 Feb 2002 07:25:20 -0800 From: "Crist J. Clark" To: Ruslan Ermilov Cc: net@FreeBSD.ORG Subject: Re: TCP Connections to a Broadcast Address Message-ID: <20020223072520.J16048@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20020222022626.A83807@blossom.cjclark.org> <20020223115033.GB47437@sunbay.com> <20020223042828.E16048@blossom.cjclark.org> <20020223124535.GB52291@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020223124535.GB52291@sunbay.com>; from ru@FreeBSD.ORG on Sat, Feb 23, 2002 at 02:45:35PM +0200 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Feb 23, 2002 at 02:45:35PM +0200, Ruslan Ermilov wrote: [snip] > Router B: if0 (192.168.1.1/24) and if1 (192.168.4.1/24) > Router A: if0 (192.168.1.2/24) > > On router A: route add -net 192.168.4 192.168.1.1, telnet 192.168.4.255. > > Or even simpler: > > Router: if0 (192.168.1.1/24 and 192.168.100.1/24) > Host: if0 (192.168.1.2, default gateway 192.168.1.1) Did 192.168.4.1/24 just become 192.168.100.1/24? > On host: > > $ ping 192.168.100.255 > PING 192.168.100.255 (192.168.100.255): 56 data bytes > 64 bytes from 192.168.100.1: icmp_seq=0 ttl=64 time=0.245 ms > 64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.207 ms > 64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.207 ms > ^C > --- 192.168.100.255 ping statistics --- > 3 packets transmitted, 3 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.207/0.220/0.245/0.018 ms > $ telnet 192.168.100.255 25 > Trying 192.168.100.255... > Connected to 192.168.100.255. > Escape character is '^]'. > 220 my.router.local.net ESMTP Sendmail 8.11.6/8.11.2; Sat, 23 Feb 2002 14:39:21 +0200 (EET) I can't reproduce this. I was only ever able to connect to the broadcast on the local interface. On victim "router (192.168.64.50):" $ netstat -rn -f inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.64.254 UGSc 14 1768 dc0 127.0.0.1 127.0.0.1 UH 1 137708 lo0 172.16 link#3 UC 3 0 ep0 172.16.0.1 0:20:af:17:f:11 UHLW 0 2 lo0 192.168.64 link#1 UC 6 0 dc0 192.168.64.50 0:4:5a:40:d9:e5 UHLW 11 5310274 lo0 192.168.64.60 0:c0:f0:5a:6c:a UHLW 4 11416791 dc0 514 On attacker "host (192.168.64.60):" $ netstat -rn -f Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.64.254 UGSc 1 0 dc0 127 127.0.0.1 UGSc 0 0 lo0 127.0.0.1 127.0.0.1 UH 1 1776 lo0 172.16 192.168.64.50 UGSc 1 4 dc0 192.168.64 link#1 UC 3 0 dc0 192.168.64.50 0:4:5a:40:d9:e5 UHLW 6 1318188 dc0 1003 Now on "host," $ ping 172.16.0.1 PING 172.16.0.1 (172.16.0.1): 56 data bytes 64 bytes from 172.16.0.1: icmp_seq=0 ttl=64 time=0.518 ms 64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=0.541 ms ^C --- 172.16.0.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.518/0.530/0.541/0.011 ms This works fine as expected with the weak-ES model. But for me, $ ping 172.16.255.255 PING 172.16.255.255 (172.16.255.255): 56 data bytes ^C --- 172.16.255.255 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss $ telnet 172.16.255.255 Trying 172.16.255.255... telnet: connect to address 172.16.255.255: Operation timed out telnet: Unable to connect to remote host I can't reach the broadcast on the other interface. The "router" is FreeBSD 4.5-RELEASE without any patches. I'm not sure what I might be doing wrong. If you are correct, and you can cross interfaces, this is a much bigger problem. I didn't mention it in your first mail, but the in_broadcast() function as used in the patch you sent is different than the current implementation. in_broadacast() currently takes an address and an interface. If you are correct, we'd have to loop through the interface list... which makes this uglier. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 8:25:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.cksoft.de (ns1.cksoft.de [62.111.66.1]) by hub.freebsd.org (Postfix) with ESMTP id DDC0937B404 for ; Sat, 23 Feb 2002 08:25:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ns1.cksoft.de (Postfix) with ESMTP id 454F614FB6 for ; Sat, 23 Feb 2002 17:25:08 +0100 (CET) Received: by ns1.cksoft.de (Postfix, from userid 66) id 27FBD14FB1; Sat, 23 Feb 2002 17:25:07 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id B090A22E6C; Sat, 23 Feb 2002 17:22:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9ABBF22E6B; Sat, 23 Feb 2002 17:22:24 +0100 (CET) Date: Sat, 23 Feb 2002 17:22:24 +0100 (CET) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: freebsd-net@freebsd.org Cc: "Bjoern A. Zeeb" Subject: net/if.c ifconf() question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-11 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, had some problems with new isc dhcpd. The problem was that the supplied buffer was not big enough in common/discover.c when doing i = ioctl(sock, SIOCGIFCONF, &ic); My question now after a short look at this is: net/if.c: static int ifconf(cmd, data) only fills the supplied buffer as long as more data fits and only returns the length of bytes copied into the buffer. In userspace how can one decide if we got all data ? Should ifconf() either return -EFAULT if buffer does not fit or return the total length of data needed for all interface information ? Please cc me because I'm not on the list. Thanks. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 12: 0:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 11CA437B417 for ; Sat, 23 Feb 2002 12:00:13 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id LAA05839; Sat, 23 Feb 2002 11:53:02 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1NJqH014317; Sat, 23 Feb 2002 11:52:17 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202231952.g1NJqH014317@arch20m.dellroad.org> Subject: Re: I can't build freebsd4.2 kernel with option NETGRAPH_MPPC_ENCRYPTION?? In-Reply-To: <20020223073355.69284.qmail@web11604.mail.yahoo.com> "from tang hongbin at Feb 22, 2002 11:33:55 pm" To: tang hongbin Date: Sat, 23 Feb 2002 11:52:17 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org tang hongbin writes: > Dear all; > When I selected options > NETGRAPH_MPPC_ENCRYPTION, rather than options > NETGRAPH_MPPC_COMPRESSION, in kernel config and tried > to rebuild freebsd v42. kernel, I failed. The system > printed the error messages as following > ..... > linking kernel > ng_mppc.o: In function `ng_mppc_constructor': > ng_mppc.o(.text+0xc): undefined reference to > `M_NETGRAPH' Did you remember to include "options NETGRAPH" ? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 12:15: 6 2002 Delivered-To: freebsd-net@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id F083137B416 for ; Sat, 23 Feb 2002 12:15:02 -0800 (PST) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA05951; Sat, 23 Feb 2002 12:08:43 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g1NK7wb14385; Sat, 23 Feb 2002 12:07:58 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200202232007.g1NK7wb14385@arch20m.dellroad.org> Subject: Re: why win2k can't connect to mpd bye pptp with mppe encryption? In-Reply-To: <20020222141326.69663.qmail@web11604.mail.yahoo.com> "from tang hongbin at Feb 22, 2002 06:13:26 am" To: tang hongbin Date: Sat, 23 Feb 2002 12:07:58 -0800 (PST) Cc: freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org tang hongbin writes: > I tried, on win2k, to dial-up to mpd(v3.7) on > freebsd with mppe encryption. But I failed. win2k > display error messages "the remote server doesn't > support the data encrption type". I enabled > "mpp-e40","mpp-e128" and "mpp-stateless". I also check > mpd3.7's source Makefile and found no rc4.c files when > MPPE option is set yes. Is it a bug? Windows error messages are approximate at best. Posting the mpd log would be helpful in tracking this down. FYI, the RC4 part is done in the kernel. Cheers, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 18:20:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from idealso.com (idealso.com [216.122.250.84]) by hub.freebsd.org (Postfix) with ESMTP id B192E37B405 for ; Sat, 23 Feb 2002 18:20:10 -0800 (PST) Received: from att (12-245-208-165.client.attbi.com [12.245.208.165]) by idealso.com (8.11.0/8.11.0) with SMTP id g1O2K8D15452 for ; Sat, 23 Feb 2002 21:20:09 -0500 (EST) (envelope-from jeff@idealso.com) Reply-To: From: "Jeff Lawton" To: Subject: 3com gigabit 3c996b-t Date: Sat, 23 Feb 2002 21:23:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "siocsifmedia Device Not Configured" when I attempt to force it into 1000basetx mode with the following command: Ifconfig bge0 media 1000baseTX Any help with this is greatly appreciated. > > > > > Jeff Lawton > Ideal Solution, LLC > > -----Original Message----- > From: Jesper Skriver [mailto:jesper@skriver.dk] > Sent: Saturday, February 23, 2002 8:52 AM > To: Jeff Lawton > Subject: Re: FW: 3com gigabit 3c996b-t > > On Fri, Feb 22, 2002 at 07:17:27PM -0500, Jeff Lawton wrote: > > Bge detects the card and it shows up on ifconfig it does not detect > > 1000basetx on autoselect even though the card and the switch both register > > 1000baset. I connected it to a 100base t port and it seems to work fine. > How > > do I get it to switch to 1000baset > > 'man bge' would tell you > > ifconfig bge0 media 1000baseTX > > /Jesper > > -- > Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 > Work: Network manager @ AS3292 (Tele Danmark DataNetworks) > Private: FreeBSD committer @ AS2109 (A much smaller network ;-) > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. > /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 23 22: 1:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id B906437B402 for ; Sat, 23 Feb 2002 22:01:11 -0800 (PST) Received: from randy by rip.psg.com with local (Exim 3.35 #1) id 16erih-0005tk-00 for freebsd-net@freebsd.org; Sat, 23 Feb 2002 22:01:11 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-net@freebsd.org Subject: telling dns through userland ppp to windows xp dialup client Message-Id: Date: Sat, 23 Feb 2002 22:01:11 -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 4.5-stable userland ppp default: set log Phase Chat LCP IPCP CCP tun command ident user-ppp VERSION (built COMPILATIONDATE) set log phase lcp chat enable dns set timeout 0 that "enable dns" seemed to tell win98 folk what the dns address to use was. but it does not seem to tell win xp pro dialup. got clue? randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message