From owner-freebsd-net Sun Apr 28 11:40:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 5E63937B41B for ; Sun, 28 Apr 2002 11:40:23 -0700 (PDT) Received: from pool0493.cvx21-bradley.dialup.earthlink.net ([209.179.193.238] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 171taw-0004XU-00 for net@freebsd.org; Sun, 28 Apr 2002 11:40:22 -0700 Message-ID: <3CCC41FA.D2BA610E@mindspring.com> Date: Sun, 28 Apr 2002 11:39:54 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Subject: ip_flow and ipf_tos 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 to me that it would be useful to break out the ip_tos field in the ipflow_lookup() function, just like in the ipflow_hash() function, and make it an unsigned long (the packing of the structure makes it a 32 bit value (or 64 bit, on Alpha) anyway. This also means calling the mtod() (which is a macro) before the call to ipflow_create() and adding a u_long parameter there (or u_int32_t, if you prefer). The net upshot of this is that it would be possible to use any unsigned (32 bit, in most cases) value to do the flow identification, so that, other than ipflow_fastforward() itself, the ip_tos is not necessarily used for the flow identification. This is useful for local hash preterbation: the common case for any application other than a generic router is going to have identical ip_tos values on almost all traffic, which makes it not very useful for uniquifying the hash. Rather than dictate what I personally think would be useful, I'd like to have implementation-not-policy; also, the break out of the value would make the code more generally useful. Right now, ip_tos (and ipf_tos) is an 8 bit value, of which only the first 6 bits are used in the hash, while the hash value pass itself is a 32 bit value (in most cases: it's "unsigned"). I'd like to push the value into the same space as the src.s_addr feedback, which would have the net effect of making 2 more bits of the standard implementation useful. What do people think about this? The changes themselves are really trivial, and it only puts an extra push/pop into the common code path in order to get the functionality, and doesn't bloat the data structure size at all... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 28 13: 7:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from sofia.digsys.bg (sofia.digsys.bg [193.68.3.250]) by hub.freebsd.org (Postfix) with ESMTP id 4391537B41B for ; Sun, 28 Apr 2002 13:07:29 -0700 (PDT) Received: from comm.uni-svishtov.bg (ns.uni-svishtov.bg [193.68.172.1]) by sofia.digsys.bg (8.9.0/8.9.0) with ESMTP id XAA19954 for ; Sun, 28 Apr 2002 23:07:21 +0300 (EEST) Received: from grinch.uni-svishtov.bg (grinch.uni-svishtov.bg [193.68.172.9]) by comm.uni-svishtov.bg (8.9.3/8.9.3) with ESMTP id XAA10539 for ; Sun, 28 Apr 2002 23:07:20 +0300 (EEST) Received: from deckland (deckland.uni-svishtov.bg [193.68.173.82]) by grinch.uni-svishtov.bg (8.12.1/8.12.1) with SMTP id g3SK7HIw024936 for ; Sun, 28 Apr 2002 23:07:20 +0300 (EEST) Message-ID: <000801c1eef0$4f6f9900$52ad44c1@deckland> From: "Radoslav Vasilev" To: Subject: Date: Sun, 28 Apr 2002 23:07:23 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1EF09.748BD5F0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1EF09.748BD5F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable unsuscribe freebsd-net ------=_NextPart_000_0005_01C1EF09.748BD5F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
unsuscribe = freebsd-net
------=_NextPart_000_0005_01C1EF09.748BD5F0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 28 13:57: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from mice.XGforce.COM (adsl-63-203-118-74.dsl.lsan03.pacbell.net [63.203.118.74]) by hub.freebsd.org (Postfix) with ESMTP id ABFC337B400; Sun, 28 Apr 2002 13:56:55 -0700 (PDT) Received: from ssn (brams.XGforce.COM [63.203.118.78]) by mice.XGforce.COM (8.11.6/8.11.6) with SMTP id g3SL3KQ38752; Sun, 28 Apr 2002 14:03:23 -0700 (PDT) (envelope-from mattl3@earthlink.net) Message-ID: <002301c1eef6$5894d940$4e76cb3f@ssn> From: "Matt" To: "Baldur Gislason" , "Terry Lambert" Cc: , References: <5.1.1.2.2.20020426234504.029f7c30@208.141.46.3> <3CCA4004.B9A8D57A@mindspring.com> <20020427161558.CC4CF2744@tesla.foo.is> Subject: Re: load balancing with 2 nic cards possible? Date: Sun, 28 Apr 2002 13:50:31 -0700 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 Disposition-Notification-To: "Matt" 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 You may try some other kind of load balance and fail safe from www.xgforce.com. It's a layer 3 and layer 7 global clustering software for FreeBSD. ----- Original Message ----- From: "Baldur Gislason" To: "Terry Lambert" Cc: ; Sent: Saturday, April 27, 2002 9:14 AM Subject: Re: load balancing with 2 nic cards possible? > I have tried that fec driver, no luck. I get the interface up, but when I try > to transmit packets over it I get "invalid argument" or something like that, > I had the network cards hooked to a Cisco catalyst and I had grouped the > ports, and I've tried two types of network cards, 3com 905C and Intel > EtherExpress 100 > > Baldur Gislason > > On Saturday 27 April 2002 06:07, you wrote: > > Gary Stanley wrote: > > > Is it possible to split the load of IP traffic with 2 ethernet cards on a > > > 4.x machine? I'm new to "load balancing" in a sense, however, I'd like to > > > try something that seems more "robust" > > > > http://people.freebsd.org/~wpaul/FEC/4.x/ > > > > -- Terry > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" 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 Apr 28 16:37:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 6071137B400 for ; Sun, 28 Apr 2002 16:37:47 -0700 (PDT) Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 29 Apr 2002 00:37:46 +0100 (BST) To: net@freebsd.org Subject: soisdisconnected tweak. X-Request-Do: Date: Mon, 29 Apr 2002 00:37:46 +0100 From: David Malone Message-ID: <200204290037.aa51029@salmon.maths.tcd.ie> 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 When soisdisconnected is called on a socket, the connection is marked as broken the socket can't recieve or send any more data. As far as I can tell, any data which is queued for output cannot be sent, but remains queued in the socket until it is closed. The patch below makes soisdisconnected drop whatever data is queued, so that the mbufs can be reused straight away and you don't have to wait for the socket to be closed. I've been running this patch on several 4.X machines for some time and on my -current box at home with no side effects. I wonder if there is any reason not to commit it? David. Index: sys/kern/uipc_socket2.c =================================================================== RCS file: /cvs/FreeBSD-CVS/src/sys/kern/uipc_socket2.c,v retrieving revision 1.85 diff -u -r1.85 uipc_socket2.c --- sys/kern/uipc_socket2.c 20 Mar 2002 04:39:32 -0000 1.85 +++ sys/kern/uipc_socket2.c 24 Mar 2002 09:21:50 -0000 @@ -157,6 +157,7 @@ so->so_state &= ~(SS_ISCONNECTING|SS_ISCONNECTED|SS_ISDISCONNECTING); so->so_state |= (SS_CANTRCVMORE|SS_CANTSENDMORE|SS_ISDISCONNECTED); wakeup((caddr_t)&so->so_timeo); + sbdrop(&so->so_snd, so->so_snd.sb_cc); sowwakeup(so); sorwakeup(so); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 28 17:57:42 2002 Delivered-To: freebsd-net@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id A238337B400; Sun, 28 Apr 2002 17:57:39 -0700 (PDT) Received: from pool0509.cvx22-bradley.dialup.earthlink.net ([209.179.199.254] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 171zTz-00013n-00; Sun, 28 Apr 2002 17:57:36 -0700 Message-ID: <3CCC9A61.A154D411@mindspring.com> Date: Sun, 28 Apr 2002 17:57:05 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Cc: Baldur Gislason , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: load balancing with 2 nic cards possible? References: <5.1.1.2.2.20020426234504.029f7c30@208.141.46.3> <3CCA4004.B9A8D57A@mindspring.com> <20020427161558.CC4CF2744@tesla.foo.is> <002301c1eef6$5894d940$4e76cb3f@ssn> 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 Matt wrote: > You may try some other kind of load balance and fail safe from > www.xgforce.com. It's a layer 3 and layer 7 global clustering software for > FreeBSD. Wrong kind of "load balancing". The original poster wanted channel bonding, not server load balancing. The layer 3 in the referenced product is (apparently) not really layer 3. VIPs alone do not a layer 3 load balancer make. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Apr 28 18: 8:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id DB17137B405 for ; Sun, 28 Apr 2002 18:08:23 -0700 (PDT) Received: from pool0509.cvx22-bradley.dialup.earthlink.net ([209.179.199.254] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 171zeQ-0005GT-00; Sun, 28 Apr 2002 18:08:23 -0700 Message-ID: <3CCC9CE7.B838EA8C@mindspring.com> Date: Sun, 28 Apr 2002 18:07:51 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: net@freebsd.org Cc: dwmalone@maths.tcd.ie Subject: Re: soisdisconnected tweak. 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 ] When soisdisconnected is called on a socket, the connection is ] marked as broken the socket can't recieve or send any more data. ] As far as I can tell, any data which is queued for output cannot ] be sent, but remains queued in the socket until it is closed. ] ] The patch below makes soisdisconnected drop whatever data is queued, ] so that the mbufs can be reused straight away and you don't have ] to wait for the socket to be closed. A shutdown guarantees that the data is transferred from the socket buf to the TCP buf. The real question here is how you get to the state you claim is happening: the so isdisconnected() should stall the calling process until the data has drained, if this is the case, or it should never get called until the buffer is empty. In general, it's valid to have data sitting there waiting, if the data has been sent, but not acknowledged, since an ACK for a previous segment -- indicating that some of the data was lost in transit -- will trigger a retransmit. The retransmitted data has to come from somewhere, for the TCP close semantics to be correct. So back to the real question: how do you get into a situation where data that is *rightly* never to be transmitted is hung there waiting? I can't see how this can ever legitimately happen. Is this maybe part of the sysctl/tcpcb hack thing? If so, then the correct place to do this is on the sysctl write to get rid of the socket: not in the soisdisconnected() call... in other words, it's a discrete event, and has to be handled as such. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 29 1:15:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from web20009.mail.yahoo.com (web20009.mail.yahoo.com [216.136.225.72]) by hub.freebsd.org (Postfix) with SMTP id 613AB37B420 for ; Mon, 29 Apr 2002 01:15:44 -0700 (PDT) Message-ID: <20020429081543.18716.qmail@web20009.mail.yahoo.com> Received: from [61.223.6.124] by web20009.mail.yahoo.com via HTTP; Mon, 29 Apr 2002 01:15:43 PDT Date: Mon, 29 Apr 2002 01:15:43 -0700 (PDT) From: Vincent Chen Subject: IPSec tunnel status? 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 have a freebsd act as VPN gateway which support PPTP and IPSec. I am trying to monitor those incoming connections. For PPTP, I can use snmp to get ngx status and statics. Is there any to monitor IPsec tunnel like those PPTP connection? Thanks, Vincent Chen, __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 29 2: 6:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from web12201.mail.yahoo.com (web12201.mail.yahoo.com [216.136.173.85]) by hub.freebsd.org (Postfix) with SMTP id EC82F37B400 for ; Mon, 29 Apr 2002 02:06:52 -0700 (PDT) Message-ID: <20020429090652.92612.qmail@web12201.mail.yahoo.com> Received: from [203.124.128.243] by web12201.mail.yahoo.com via HTTP; Mon, 29 Apr 2002 02:06:52 PDT Date: Mon, 29 Apr 2002 02:06:52 -0700 (PDT) From: kshitij gunjikar Subject: IP options related question 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, I have a question related to record routes in the FreeBSD code. In the ip_dooptions() fn in ip_input.c there is this code in the Record Route option. /* * If no space remains, ignore. */ off--; /* 0 origin */ if (off > optlen - (int)sizeof(struct in_addr)) break; (void)memcpy(&ipaddr.sin_addr, &ip->ip_dst, sizeof(ipaddr.sin_addr)); /* * locate outgoing interface; if we're the destination, * use the incoming interface (should be same). */ if ((ia = (INA)ifa_ifwithaddr((SA)&ipaddr)) == 0 && (ia = ip_rtaddr(ipaddr.sin_addr)) == 0) { type = ICMP_UNREACH; code = ICMP_UNREACH_HOST; goto bad; } 1. Why is the ICMP_UNREACH_HOST generated? 2. Because if a route is not found, then am I wrong in saying ICMP_UNREACH_NETWORK must be generated. Also, how does ip_rtaddr() find out that the IP address is not of the directly connected networks? I'm sure something is wrong in my understanding can somebody please point out. Regards Kshitij __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 29 2: 7: 5 2002 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 44CE237B400 for ; Mon, 29 Apr 2002 02:06:59 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 29 Apr 2002 10:06:58 +0100 (BST) To: Terry Lambert Cc: net@freebsd.org Subject: Re: soisdisconnected tweak. In-reply-to: Your message of "Sun, 28 Apr 2002 18:07:51 PDT." <3CCC9CE7.B838EA8C@mindspring.com> X-Request-Do: Date: Mon, 29 Apr 2002 10:06:56 +0100 From: David Malone Message-ID: <200204291006.aa93819@salmon.maths.tcd.ie> 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 > A shutdown guarantees that the data is transferred from the socket > buf to the TCP buf. The real question here is how you get to the > state you claim is happening: the so isdisconnected() should stall > the calling process until the data has drained, if this is the case, > or it should never get called until the buffer is empty. I think your fears about data being lost here may be unfounded. The description of soisdisconnected() says: ... soisdisconnected() is called when the connection to the peer is totally severed. This seems to mean that that either the connection has timed out or has been aborted. I think it should be safe to drop any data which is waiting to be sent if connection is actually severed. I've included a list of the places where soisdisconnected is called from, and they all seem pretty final. David. unp_detach unp_disconnect raw_uabort raw_udisconnect ddp_disconnect ddp_abort at_pcbdetach atm_sock_connect (if connect fails) ngs_rmnode div_abort rip_abort tcp_input (TCPS_FIN_WAIT_1 && ourfinisacked) || (TCPS_CLOSING && ourfinisacked) || (TCPS_FIN_WAIT_2 && FIN) tcp_close tcp_usrclosed (and we're in state >= TCPS_FIN_WAIT_2) udp_abort rip6_abort udp6_abort ipx_abort ipx_drop ipx_usr_abort ipx_disconnect spx_close natm_usr_disconnect natm_usrreq for PRU_DISCONNECT idp_abort idp_drop idp_usrreq for PRU_DISCONNECT and PRU_ABORT spp_close To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 29 3:55:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 42B2737B404 for ; Mon, 29 Apr 2002 03:55:21 -0700 (PDT) Received: from pool0031.cvx40-bradley.dialup.earthlink.net ([216.244.42.31] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 1728oP-0005HS-00; Mon, 29 Apr 2002 03:55:18 -0700 Message-ID: <3CCD2679.B5D5A709@mindspring.com> Date: Mon, 29 Apr 2002 03:54:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Malone Cc: net@freebsd.org Subject: Re: soisdisconnected tweak. References: <200204291006.aa93819@salmon.maths.tcd.ie> 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 David Malone wrote: > > A shutdown guarantees that the data is transferred from the socket > > buf to the TCP buf. The real question here is how you get to the > > state you claim is happening: the so isdisconnected() should stall > > the calling process until the data has drained, if this is the case, > > or it should never get called until the buffer is empty. > > I think your fears about data being lost here may be unfounded. > The description of soisdisconnected() says: > > ... soisdisconnected() is called when the connection to the > peer is totally severed. > > This seems to mean that that either the connection has timed out > or has been aborted. I think it should be safe to drop any data > which is waiting to be sent if connection is actually severed. > > I've included a list of the places where soisdisconnected is called > from, and they all seem pretty final. I think you are complaining about the default for the keepalive socket option. I think you will get the behaviour ytou desire without hacking up the code, just by: sysctl -w net.inet.tcp.always_keepalive=0 PS: You still didn't answer the question; yes, it's called when the connection is "totally severed". But when is the connection ever "totally severed"? PPS: Ask yourself: how is it that it's *EVER* possible for the function soisdisconnected() to be called without the socket buffer having been emptied *FIRST*. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 29 4:41:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mk-smarthost-2.mail.uk.tiscali.com (mk-smarthost-2.mail.uk.worldonline.com [212.74.112.72]) by hub.freebsd.org (Postfix) with ESMTP id 173CB37B41B; Mon, 29 Apr 2002 04:41:32 -0700 (PDT) Received: from [212.139.129.125] (helo=bloodhound.uk.worldonline.com) by mk-smarthost-2.mail.uk.tiscali.com with esmtp (Exim 3.35 #1) id 1729WY-000HaN-00; Mon, 29 Apr 2002 12:40:54 +0100 Received: from brian by bloodhound.uk.worldonline.com with local (Exim 3.22 #1) id 1729X7-0000vS-00; Mon, 29 Apr 2002 12:41:29 +0100 Date: Mon, 29 Apr 2002 12:41:29 +0100 From: Brian Candler To: freebsd-fs@freebsd.org, freebsd-net@freebsd.org Subject: Re: NFS clearing attribute cache in nfs_open Message-ID: <20020429124129.A3409@linnet.org> References: <20020426181535.B2748@linnet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020426181535.B2748@linnet.org>; from B.Candler@pobox.com on Fri, Apr 26, 2002 at 06:15:35PM +0100 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 comments so far. It looks like the best solution for me is going to be to boot diskless into a ramdisk. It's been quite a job finding out how to do that; there doesn't seem to be much in the way of documentation. Reverse-engineering the source suggests that the following methods exist: (1) Including an MD image within the kernel itself options MD_ROOT options MD_ROOT_SIZE n # kilobytes then use usr/src/release/write_mfs_in_kernel.c to patch the image into the kernel. Trouble is you must reserve sufficient space for the image, and repatch a clean kernel every time you wish to change the ramdisk. (2) Module preload mechanism dev/md/md.c calls preload_search_info(mod, MODINFO_NAME) This accepts a 'module' of type "md_image" or "mfs_root" It then creates a ramdisk using data at MODINFO_ADDR of MODINFO_SIZE. These in turn come from sys/kern/subr_module.c which uses a block of "preload_metadata" As far as I can tell, either I can put something like load -t md_image myfile in boot/loader.rc, or do what release/Makefile does, which is to put mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/boot/mfsroot" in boot/loader.conf. I'm not sure if that's sufficient to replace the NFS root, or if I have to recompile the kernel _without_ options BOOTP and BOOTP_NFSROOT for this to work, but I'll give it a go later on... Cheers, Brian. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Apr 29 20:27:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe56.law14.hotmail.com [64.4.20.191]) by hub.freebsd.org (Postfix) with ESMTP id 8A51937B404 for ; Mon, 29 Apr 2002 20:27:41 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Apr 2002 20:27:41 -0700 X-Originating-IP: [138.89.20.178] From: "ipver4" To: Subject: CCP does not work between Linux ppp client and FreeBSD ppp server Date: Mon, 29 Apr 2002 23:27:29 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C1EFD5.6E40FD70" 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 Message-ID: X-OriginalArrivalTime: 30 Apr 2002 03:27:41.0470 (UTC) FILETIME=[FC2A2BE0:01C1EFF6] 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_0043_01C1EFD5.6E40FD70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (This is a PPP related question.) It seems the RedHat Linux 7.2 PPP client does not work with the FreeBSD = 4.5 PPP server in the CCP (Compression Control Protocol) negotiation. = Briefly, the problem looks like the following: Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> = PPP server Linux <-- CCP conf reject (schemes, B and C) <-- PPP server (That is, the PPP server picked the compression scheme A, and rejected = the rest.) Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> = PPP server Linux <-- CCP conf reject (schemes, B and C) <-- PPP server (repeat may times without progress.) It seems the Linux client did not follow the PPP protocol and ignored = the CCP reject messages. The correct message exchange should look like the following: Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> = PPP server Linux <-- CCP conf reject (schemes, B and C) <-- PPP server ---> CCP conf request (scheme A) --> PPP server <--- CCP conf ACK (scheme A) <-- PPP server Comments? P.S. I am using PPPoE for the testing. ------=_NextPart_000_0043_01C1EFD5.6E40FD70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(This is a PPP related = question.)
 
It seems the RedHat Linux 7.2 PPP = client does not=20 work with the FreeBSD 4.5 PPP server in the CCP (Compression = Control=20 Protocol) negotiation. Briefly, the problem looks like the=20 following:
 
Linux ---> CCP conf request (with 3 = compression=20 schemes, A, B and C) --> PPP server
Linux <-- CCP conf reject (schemes, = B and C)=20 <-- PPP server
(That is, the PPP server picked the = compression=20 scheme A, and rejected the rest.)
 
Linux ---> CCP conf request (with 3 = compression=20 schemes, A, B and C) --> PPP server
Linux <-- CCP conf reject (schemes, = B and C)=20 <-- PPP server
(repeat may times without progress.)
 
It seems the Linux client did not follow the PPP protocol and = ignored=20 the CCP reject messages.
The correct message exchange should look like the = following:
 
Linux ---> CCP conf request (with 3 = compression=20 schemes, A, B and C) --> PPP server
Linux <-- CCP conf reject (schemes, = B and C)=20 <-- PPP server
         ---> CCP conf = request=20 (scheme A) --> PPP server
        <---  CCP conf = ACK=20 (scheme A) <-- PPP server
 
Comments?
 
P.S. I am using PPPoE for the=20 testing.
------=_NextPart_000_0043_01C1EFD5.6E40FD70-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 30 8: 7:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7]) by hub.freebsd.org (Postfix) with ESMTP id C4B5437B41A for ; Tue, 30 Apr 2002 08:07:56 -0700 (PDT) Received: (from tinguely@localhost) by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id g3UF7tN32713; Tue, 30 Apr 2002 10:07:55 -0500 (CDT) (envelope-from tinguely) Date: Tue, 30 Apr 2002 10:07:55 -0500 (CDT) From: mark tinguely Message-Id: <200204301507.g3UF7tN32713@web.cs.ndsu.nodak.edu> To: net@FreeBSD.ORG, tlambert2@mindspring.com Subject: Re: ip_flow and ipf_tos In-Reply-To: <3CCC41FA.D2BA610E@mindspring.com> 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 > Right now, ip_tos (and ipf_tos) is an 8 bit value, of which only > the first 6 bits are used in the hash, while the hash value pass > itself is a 32 bit value (in most cases: it's "unsigned"). I'd > like to push the value into the same space as the src.s_addr > feedback, which would have the net effect of making 2 more bits > of the standard implementation useful. I have no complaints to your proposal. The question I had was: what would happen when the high bits implement Early Congestion Notification (RFC3168)? Wouldn't we want to mask off these bits from the hash anyway? --mark tinguely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 30 8:41:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 0AC9837B400 for ; Tue, 30 Apr 2002 08:41:43 -0700 (PDT) Received: from pool0453.cvx21-bradley.dialup.earthlink.net ([209.179.193.198] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 172Zl3-0003Uh-00; Tue, 30 Apr 2002 08:41:38 -0700 Message-ID: <3CCEBB15.D89B94E7@mindspring.com> Date: Tue, 30 Apr 2002 08:41:09 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mark tinguely Cc: net@FreeBSD.ORG Subject: Re: ip_flow and ipf_tos References: <200204301507.g3UF7tN32713@web.cs.ndsu.nodak.edu> 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 mark tinguely wrote: > > Right now, ip_tos (and ipf_tos) is an 8 bit value, of which only > > the first 6 bits are used in the hash, while the hash value pass > > itself is a 32 bit value (in most cases: it's "unsigned"). I'd > > like to push the value into the same space as the src.s_addr > > feedback, which would have the net effect of making 2 more bits > > of the standard implementation useful. > > I have no complaints to your proposal. The question I had was: > what would happen when the high bits implement Early Congestion > Notification (RFC3168)? Wouldn't we want to mask off these bits > from the hash anyway? Yes. It would be nice if such masking were explicit, so that the code could be read by mere mortals, though. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 30 10:29:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 05B0637B417 for ; Tue, 30 Apr 2002 10:29:37 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 30 Apr 2002 18:29:36 +0100 (BST) To: Terry Lambert Cc: net@freebsd.org Subject: Re: soisdisconnected tweak. In-reply-to: Your message of "Mon, 29 Apr 2002 03:54:49 PDT." <3CCD2679.B5D5A709@mindspring.com> X-Request-Do: Date: Tue, 30 Apr 2002 18:29:35 +0100 From: David Malone Message-ID: <200204301829.aa56944@salmon.maths.tcd.ie> 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 > PPS: Ask yourself: how is it that it's *EVER* possible for the function > soisdisconnected() to be called without the socket buffer having been > emptied *FIRST*. I think it is quite simple. Say that the machine to which you are talking is powerd down while you are sending data to it. When you stop getting ACKs back data will begin to build up in the socket socket buffer. After TCP_MAXRXTSHIFT retransmits the connection will be timed out because you get no responses to your ACKs and soisdisconnected() will be called. You should be able to reproduce the problem by enabeling discard in inetd.conf and then adding firewall rules which block non-syn packets to discard and running the program below (which opens lots of connections to discard, fills the socket buffers, waits until the tcp connection is timed out and then closes the connections). You can see that the mbufs used for data are not freed until the sockets are actually closed. (The code is based on some Andreas Persson sent me to tickle a sendfile bug about 18 months ago). David. #include #include #include #include #include #include #include #include #include #include #include #include #define FDS 64 #define SENDS 63 #define HOST "127.0.0.1" #define PORT 9 int fds[FDS]; char buf[1024]; int main() { int i, j, k; struct sockaddr_in sin; for (i = 0; i < FDS; i++) { fds[i] = socket(AF_INET, SOCK_STREAM, 0); if (fds[i] == -1) err(1, "socket"); memset(&sin, 0, sizeof(sin)); if (bind(fds[i], (struct sockaddr *)&sin, sizeof(sin)) == -1) err(1, "bind"); memset(&sin, 0, sizeof(sin)); sin.sin_addr.s_addr = inet_addr(HOST); sin.sin_port = htons(PORT); sin.sin_family = AF_INET; if (connect(fds[i], (struct sockaddr *)&sin, sizeof(sin)) == -1) err(1, "connect"); if (fcntl(fds[i], F_SETFL, O_NONBLOCK) == -1) err(1, "fcntl"); } printf("Bound and ready\n"); system("netstat -m"); for (j = 0; j < FDS; j++) { for(k = 0; k < SENDS; k++) { if (write(fds[j], buf, sizeof(buf)) != sizeof(buf)) { if (errno != EWOULDBLOCK) warn("write"); else break; } } if (errno != EWOULDBLOCK) printf("Didn't fill fd=%d\n", fds[j]); } printf("Data written\n"); system("netstat -m"); printf("Waiting 10 minutes for retransmits to timeout\n"); sleep(600); system("netstat -m"); for (j = 0; j < FDS; j++) if (read(fds[j], buf, sizeof(buf)) > 0) printf("Odd, read worked for fd=%d\n", fds[j]); else if (errno != ETIMEDOUT) warn("read"); printf("Before close\n"); system("netstat -m"); for (j = 0; j < FDS; j++) close(fds[j]); printf("After close\n"); system("netstat -m"); exit(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 30 14: 0:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by hub.freebsd.org (Postfix) with ESMTP id 9BCE437B417 for ; Tue, 30 Apr 2002 14:00:28 -0700 (PDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 14AF311DD; Tue, 30 Apr 2002 15:00:28 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id DC872439; Tue, 30 Apr 2002 15:00:27 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 30 Apr 2002 15:00:27 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <262CMP4V>; Tue, 30 Apr 2002 15:00:27 -0600 Message-ID: <0D9185CE635BD511ACA50090277A6FCF03880866@axcs18.cos.agilent.com> From: "DOROVSKOY,IGOR (A-Portsmouth,ex1)" To: "'gfr@lucent.com'" , freebsd-net@freebsd.org Subject: RE: Problems with nge driver and copper GbE cards Date: Tue, 30 Apr 2002 15:00:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Did anybody knows why copper GbE cards are so slow? Both copper and Fiber >GbE cards are in the same kind of PCI slot and identical machines. The extra >memory on GA620 should not cause 40-50% difference in my opinion. It seems like this is "nge" driver of other problem, may be hardware... In my experiments (year ago under 3.x) I got the same results for copper vs. fiber using the same "ti" driver in netperf tests GA620 (fiber) vs. GA620T (copper). Regards, Igor ua3qrz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 30 14:26:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f174.sea1.hotmail.com [207.68.163.174]) by hub.freebsd.org (Postfix) with ESMTP id 9ACD637B41C for ; Tue, 30 Apr 2002 14:26:54 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Apr 2002 14:26:54 -0700 Received: from 156.153.255.236 by sea1fd.sea1.hotmail.msn.com with HTTP; Tue, 30 Apr 2002 21:26:54 GMT X-Originating-IP: [156.153.255.236] From: "Carolyn Longfoot" To: freebsd-net@freebsd.org Subject: NAT/DNS/WEB Date: Tue, 30 Apr 2002 17:26:54 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2002 21:26:54.0466 (UTC) FILETIME=[BFF53E20:01C1F08D] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have a machine that's a dual homed host running NAT and DNS, connected to the outside world with a static IP. It seems I can nslookup 'www.mydomain.com' from the outside, so I think my DNS responds to lookups from the outside. I am pointing 'WWW' via DNS to a separate machine called web.mydomain.com but for some reason from the outside I cannot get to http://www.mydomain.com. It is working from the inside however. My confusion is therefore the following: how can I test that outside DNS queries are resolved correctly and why would requests for http://www... not get routed to the Web server? I'm pretty sure nothing relevant (UDP 53 or IP 80) gets dropped by the firewall btw., I checked /var/log/security. This is my first attempt at DNS so please be gentle :-) I'm looking for a conceptual answer but I can follow up with config files if it helps. I read some old posts at 'Ask Mr.DNS' that talked about running 'split DNS'. Is that still necessary? Thanks so much, Caro _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 30 14:53:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.clifftop.net (machassociates-6.dsl.easynet.co.uk [217.204.162.182]) by hub.freebsd.org (Postfix) with ESMTP id 03C7537B41C for ; Tue, 30 Apr 2002 14:53:24 -0700 (PDT) Received: from Gandalf (gandalf.shire.com [192.168.1.5]) (authenticated bits=0) by smtp.clifftop.net (8.12.3/8.12.3) with ESMTP id g3ULq32x070221; Tue, 30 Apr 2002 22:52:03 +0100 (BST) From: "Danny Horne" To: "Carolyn Longfoot" , Subject: RE: NAT/DNS/WEB Date: Tue, 30 Apr 2002 22:52:03 +0100 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.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 > -----Original Message----- > From: owner-freebsd-net@FreeBSD.ORG > [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Carolyn Longfoot > Sent: Tuesday 30 April 2002 10:27pm > To: freebsd-net@FreeBSD.ORG > Subject: NAT/DNS/WEB > > I have a machine that's a dual homed host running NAT and DNS, > connected to > the outside world with a static IP. It seems I can nslookup > 'www.mydomain.com' from the outside, so I think my DNS responds > to lookups > from the outside. > > I am pointing 'WWW' via DNS to a separate machine called web.mydomain.com > but for some reason from the outside I cannot get to > http://www.mydomain.com. It is working from the inside however. > What IP address are you using for the web server & is the server behind the firewall? It's my guess you've given it a private IP address --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.351 / Virus Database: 197 - Release Date: 19/04/2002 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 30 17:13:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from bg.sics.se (uofa-dsl-nen-23.dakotacom.net [150.135.176.23]) by hub.freebsd.org (Postfix) with ESMTP id A88F937B405; Tue, 30 Apr 2002 17:13:20 -0700 (PDT) Received: (from bg@localhost) by bg.sics.se (8.11.6/8.11.6) id g3R17GX08156; Fri, 26 Apr 2002 18:07:16 -0700 (MST) (envelope-from bg) To: Brian Candler Cc: freebsd-fs@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: NFS clearing attribute cache in nfs_open References: <20020426181535.B2748@linnet.org> From: Bjoern Groenvall Date: 26 Apr 2002 18:07:15 -0700 In-Reply-To: Brian Candler's message of "Fri, 26 Apr 2002 18:15:35 +0100" Message-ID: Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.6 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 SunOS 4 used to have a NFS mount mount option nocto (no close to open consistency checking) that would suppress getting fresh attributes when opening a file. IMHO it is ok to enable this option on filesystems that never change (or atleast rarely). I always used it when mounting /usr on diskless systems. It put less load on the server and also eliminated some delays. One may also safely enable this option on filesystems that are accesed from only one host at a time. It all boils down to if there is no writing or sharing, then, there can be no inconsistencies if nocto is enabled. Hope this helps, Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Apr 30 18:39: 8 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 E55D837B440; Tue, 30 Apr 2002 18:38:41 -0700 (PDT) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020501013840.XXQD9799.rwcrmhc51.attbi.com@gateway.posi.net>; Wed, 1 May 2002 01:38:40 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g411cX211045; Tue, 30 Apr 2002 18:38:39 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Tue, 30 Apr 2002 18:38:33 -0700 (PDT) From: Kelly Yancey To: Bill Fenner Cc: arch@FreeBSD.ORG, Subject: Re: Overflowing sockaddr_dl's sdl_data buffer In-Reply-To: <200204211826.LAA05288@windsor.research.att.com> Message-ID: <20020430181359.G11009-300000@gateway.posi.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-819770887-1020217113=:11009" 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-819770887-1020217113=:11009 Content-Type: TEXT/PLAIN; charset=US-ASCII Attached are (very) simple patches which attempt to address the problem. I've included -net in the CC to solicit a larger audience. On Sun, 21 Apr 2002, Bill Fenner wrote: > > I think that sdl_data should go back to being a variable-length buffer, > and the source routing stuff should be reimplemented somewhere else > (perhaps at the end of the variable-length buffer). > > What uses the source-routing fields? > > Bill > Yeah, this is the route I favor, except that it would clearly break compatibility with 3rd party binary-only drivers. Personally, I would really like to see a solution implemented in the RELENG_4 branch. To that extent, the attached patches keep the sockaddr_dl at it's current size but allots the entire 34 bytes needed for token-ring source routing to the sdl_data field (for a total of 46 bytes). The token-ring code just embeds it's source routing information in the sdl_data field now. I also removed setting the source routing control field to zero for non-iso88025 sockaddr_dl's since all of the code which examines the field appears to contingent on the interface being of the iso88025 persuasion. That said, this leaves ample room in the sockaddr_dl structure for interface name and MAC address in the sockaddr_dl (too much, but the overall size hasn't changed). However, token ring interface names are still limited to 6 characters before they risk overflowing the sdl_data field with their source routing information. This is no worse than the existing situation wherein a token ring interface with more than 6 characters would cause the last byte(s) of the hardware address to get clobbered by the source routing control field. One point I am a little leary of is that in in_arpinput() the original code appears to have made provision for receiving an ISO88025 frame on a non-token ring interface and trusted the source routing information contained in such a frame. First, is this a correct reading of the code? And second, is this correct behavior? If so, I can easily restore it. There are 2 sets of attached patches: one for -current and one for -stable (the one suffixed with a 4). I've tested these pretty extensively on -stable but haven't done any testing at all for -current (admittingly, not even a build); furthermore all testing was just with ethernet...I do not have access to any token ring hardware. I would appreciate any feedback regarding the approach and anyone who can confirm that I haven't horribly borked token ring source routing. If all looks well, then ifconfig (and others?) will have to be updated to not try and print source routing information unless the interface is token ring. Thanks, Kelly kbyanc@{posi.net,FreeBSD.org} The original message for those subscribed to -net but not -arch: From kbyanc@posi.net Tue Apr 30 18:13:51 2002 Date: Sun, 21 Apr 2002 01:48:42 -0700 (PDT) From: Kelly Yancey To: arch@FreeBSD.ORG Subject: Overflowing sockaddr_dl's sdl_data buffer While working on a product at work, I discovered that it is trivial to overflow the sdl_data buffer in sockaddr_dl structures. In our case, I enountered the bug by creating a vlan100 interface. The sdl_data buffer is populated with both the interface name and the parent interface's hardware address; in his case 7 characters for the interface name and 6 more for the parent's MAC address for a total of 13 characters (sdl_data is only defined for 12 characters). As a result, the sdl_rcf field is garbage (actually, the last octet of the MAC address). While, I worked around the problem in our product, I would prefer to see the bug fixed in FreeBSD proper. So, I would like to solicit discussion of the proper fix for this bug. Should sdl_data's length be extended (say 16 characters)? This would surely break binary compatibility and only postpones the issue (imagine an interface with a longer name). Should bound's checking be added to eliminate the (supposedly optional) interface name from the sdl_data buffer if there is not room? If so, how does one ensure all drivers (including 3rd party) perform the bounds-checking? Surely there are other options too. In any event, the comment in sys/net/if_dl.h for the sdl_data field needs updating because since the source routing information was added following the sdl_data field it is impossible for the sdl_data field to be larger than that defined by the structure definition. Thanks, Kelly kbyanc@{posi.net,FreeBSD.org} --0-819770887-1020217113=:11009 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sdl_data-overflow4.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20020430183833.I11009@gateway.posi.net> Content-Description: Content-Disposition: attachment; filename="sdl_data-overflow4.diff" SW5kZXg6IG5ldC9pZl9kbC5oDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL2hvbWUvY3ZzL2Fjcy9iYXNlL3NyYy9zeXMvbmV0L2lmX2Rs Lmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjEuMS4xDQpkaWZmIC11IC1y MS4xLjEuMSBpZl9kbC5oDQotLS0gbmV0L2lmX2RsLmgJMjIgTWFyIDIwMDIg MDQ6MTE6MDAgLTAwMDAJMS4xLjEuMQ0KKysrIG5ldC9pZl9kbC5oCTMwIEFw ciAyMDAyIDIwOjE0OjA5IC0wMDAwDQpAQCAtNjYsMTAgKzY2LDggQEANCiAJ dV9jaGFyCXNkbF9ubGVuOwkvKiBpbnRlcmZhY2UgbmFtZSBsZW5ndGgsIG5v IHRyYWlsaW5nIDAgcmVxZC4gKi8NCiAJdV9jaGFyCXNkbF9hbGVuOwkvKiBs aW5rIGxldmVsIGFkZHJlc3MgbGVuZ3RoICovDQogCXVfY2hhcglzZGxfc2xl bjsJLyogbGluayBsYXllciBzZWxlY3RvciBsZW5ndGggKi8NCi0JY2hhcglz ZGxfZGF0YVsxMl07CS8qIG1pbmltdW0gd29yayBhcmVhLCBjYW4gYmUgbGFy Z2VyOw0KKwljaGFyCXNkbF9kYXRhWzQ2XTsJLyogbWluaW11bSB3b3JrIGFy ZWEsIGNhbiBiZSBsYXJnZXI7DQogCQkJCSAgIGNvbnRhaW5zIGJvdGggaWYg bmFtZSBhbmQgbGwgYWRkcmVzcyAqLw0KLQl1X3Nob3J0CXNkbF9yY2Y7CS8q IHNvdXJjZSByb3V0aW5nIGNvbnRyb2wgKi8NCi0JdV9zaG9ydAlzZGxfcm91 dGVbMTZdOwkvKiBzb3VyY2Ugcm91dGluZyBpbmZvcm1hdGlvbiAqLw0KIH07 DQogDQogI2RlZmluZSBMTEFERFIocykgKChjYWRkcl90KSgocyktPnNkbF9k YXRhICsgKHMpLT5zZGxfbmxlbikpDQpJbmRleDogbmV0L2lmX2lzbzg4MDI1 c3Vici5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hv bWUvY3ZzL2Fjcy9iYXNlL3NyYy9zeXMvbmV0L2lmX2lzbzg4MDI1c3Vici5j LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEuMQ0KZGlmZiAtdSAtcjEu MS4xLjEgaWZfaXNvODgwMjVzdWJyLmMNCi0tLSBuZXQvaWZfaXNvODgwMjVz dWJyLmMJMjIgTWFyIDIwMDIgMDQ6MTE6MDAgLTAwMDAJMS4xLjEuMQ0KKysr IG5ldC9pZl9pc284ODAyNXN1YnIuYwkzMCBBcHIgMjAwMiAyMToyNzoxMiAt MDAwMA0KQEAgLTIwMiw4ICsyMDIsOCBAQA0KIA0KIAkvKiBDYWxjdWxhdGUg cm91dGluZyBpbmZvIGxlbmd0aCBiYXNlZCBvbiBhcnAgdGFibGUgZW50cnkg Ki8NCiAJaWYgKHJ0ICYmIChzZGwgPSAoc3RydWN0IHNvY2thZGRyX2RsICop cnQtPnJ0X2dhdGV3YXkpKQ0KLQkJaWYgKHNkbC0+c2RsX3JjZiAhPSBOVUxM KQ0KLQkJCXJpZl9sZW4gPSBUUl9SQ0ZfUklGTEVOKHNkbC0+c2RsX3JjZik7 DQorCQlpZiAoU0RMX0lTTzg4MDI1KHNkbCktPnRybGRfcmNmICE9IE5VTEwp DQorCQkJcmlmX2xlbiA9IFRSX1JDRl9SSUZMRU4oU0RMX0lTTzg4MDI1KHNk bCktPnRybGRfcmNmKTsNCiANCiAJLyogR2VuZXJhdGUgYSBnZW5lcmljIDgw Mi41IGhlYWRlciBmb3IgdGhlIHBhY2tldCAqLw0KIAlnZW5fdGguYWMgPSBU Ul9BQzsNCkBAIC0yMTIsOCArMjEyLDkgQEANCiAJaWYgKHJpZl9sZW4pIHsN CiAJCWdlbl90aC5pc284ODAyNV9zaG9zdFswXSB8PSBUUl9SSUk7DQogCQlp ZiAocmlmX2xlbiA+IDIpIHsNCi0JCQlnZW5fdGgucmNmID0gc2RsLT5zZGxf cmNmOw0KLQkJCW1lbWNweShnZW5fdGgucmQsIHNkbC0+c2RsX3JvdXRlLCBy aWZfbGVuIC0gMik7DQorCQkJZ2VuX3RoLnJjZiA9IFNETF9JU084ODAyNShz ZGwpLT50cmxkX3JjZjsNCisJCQltZW1jcHkoZ2VuX3RoLnJkLCBTRExfSVNP ODgwMjUoc2RsKS0+dHJsZF9yb3V0ZSwNCisJCQkgICAgICAgcmlmX2xlbiAt IDIpOw0KIAkJfQ0KIAl9DQogCQ0KSW5kZXg6IG5ldC9pc284ODAyNS5oDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvY3ZzL2Fj cy9iYXNlL3NyYy9zeXMvbmV0L2lzbzg4MDI1Lmgsdg0KcmV0cmlldmluZyBy ZXZpc2lvbiAxLjEuMS4xDQpkaWZmIC11IC1yMS4xLjEuMSBpc284ODAyNS5o DQotLS0gbmV0L2lzbzg4MDI1LmgJMjIgTWFyIDIwMDIgMDQ6MTE6MDAgLTAw MDAJMS4xLjEuMQ0KKysrIG5ldC9pc284ODAyNS5oCTMwIEFwciAyMDAyIDIx OjI3OjA1IC0wMDAwDQpAQCAtMTAyLDYgKzEwMiwxNSBAQA0KIAl1X2NoYXIg ZmM7DQogfTsNCiANCitzdHJ1Y3QgaXNvODgwMjVfc29ja2FkZHJfZGxfZGF0 YSB7DQorCXVfc2hvcnQJIHRybGRfcmNmOw0KKwl1X3Nob3J0CSp0cmxkX3Jv dXRlW1JJRl9NQVhfTEVOXTsNCit9Ow0KKw0KKyNkZWZpbmUgU0RMX0lTTzg4 MDI1KHMpCQkoKHN0cnVjdCBpc284ODAyNV9zb2NrYWRkcl9kbF9kYXRhICop CVwNCisJCQkJICgocyktPnNkbF9kYXRhICsgbWluKChzKS0+c2RsX25sZW4g KwlcDQorCQkJCSAgKHMpLT5zZGxfYWxlbiArIChzKS0+c2RsX3NsZW4sIDEy KSkpDQorDQogLyoNCiAgKiBTdHJ1Y3R1cmUgb2YgYSA0OC1iaXQgaXNvIDgw Mi41IGFkZHJlc3MuDQogICogICggV2UgY291bGQgYWxzbyBhZGQgdGhlIDE2 IGJpdCBhZGRyZXNzZXMgYXMgYSB1bmlvbikNCkluZGV4OiBuZXRpbmV0L2lm X2V0aGVyLmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJDUyBmaWxlOiAv aG9tZS9jdnMvYWNzL2Jhc2Uvc3JjL3N5cy9uZXRpbmV0L2lmX2V0aGVyLmMs dg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjUNCmRpZmYgLXUgLXIxLjUgaWZf ZXRoZXIuYw0KLS0tIG5ldGluZXQvaWZfZXRoZXIuYwkyOSBNYXIgMjAwMiAy MDozMzo1NyAtMDAwMAkxLjUNCisrKyBuZXRpbmV0L2lmX2V0aGVyLmMJMzAg QXByIDIwMDIgMjE6Mjc6MjMgLTAwMDANCkBAIC01MjksNiArNTI5LDcgQEAN CiAJcmVnaXN0ZXIgc3RydWN0IGFycGNvbSAqYWMgPSAoc3RydWN0IGFycGNv bSAqKW0tPm1fcGt0aGRyLnJjdmlmOw0KIAlzdHJ1Y3QgZXRoZXJfaGVhZGVy ICplaDsNCiAJc3RydWN0IGlzbzg4MDI1X2hlYWRlciAqdGggPSAoc3RydWN0 IGlzbzg4MDI1X2hlYWRlciAqKTA7DQorCXN0cnVjdCBpc284ODAyNV9zb2Nr YWRkcl9kbF9kYXRhICp0cmxkOw0KIAlyZWdpc3RlciBzdHJ1Y3QgbGxpbmZv X2FycCAqbGEgPSAwOw0KIAlyZWdpc3RlciBzdHJ1Y3QgcnRlbnRyeSAqcnQ7 DQogCXN0cnVjdCBpZmFkZHIgKmlmYTsNCkBAIC02NDcsNyArNjQ4LDYgQEAN CiB1cGRhdGU6DQogCQkodm9pZCltZW1jcHkoTExBRERSKHNkbCksIGVhLT5h cnBfc2hhLCBzaXplb2YoZWEtPmFycF9zaGEpKTsNCiAJCXNkbC0+c2RsX2Fs ZW4gPSBzaXplb2YoZWEtPmFycF9zaGEpOw0KLSAgICAgICAgICAgICAgICBz ZGwtPnNkbF9yY2YgPSAodV9zaG9ydCkwOw0KIAkJLyoNCiAJCSAqIElmIHdl IHJlY2VpdmUgYW4gYXJwIGZyb20gYSB0b2tlbi1yaW5nIHN0YXRpb24gb3Zl cg0KIAkJICogYSB0b2tlbi1yaW5nIG5pYyB0aGVuIHRyeSB0byBzYXZlIHRo ZSBzb3VyY2UNCkBAIC02NTUsMTMgKzY1NSwxNCBAQA0KIAkJICovDQogCQlp ZiAoYWMtPmFjX2lmLmlmX3R5cGUgPT0gSUZUX0lTTzg4MDI1KSB7DQogCQkJ dGggPSAoc3RydWN0IGlzbzg4MDI1X2hlYWRlciAqKW0tPm1fcGt0aGRyLmhl YWRlcjsNCisJCQl0cmxkID0gU0RMX0lTTzg4MDI1KHNkbCk7DQogCQkJcmlm X2xlbiA9IFRSX1JDRl9SSUZMRU4odGgtPnJjZik7DQogCQkJaWYgKCh0aC0+ aXNvODgwMjVfc2hvc3RbMF0gJiBUUl9SSUkpICYmDQogCQkJICAgIChyaWZf bGVuID4gMikpIHsNCi0JCQkJc2RsLT5zZGxfcmNmID0gdGgtPnJjZjsNCi0J CQkJc2RsLT5zZGxfcmNmIF49IGh0b25zKFRSX1JDRl9ESVIpOw0KLQkJCQlt ZW1jcHkoc2RsLT5zZGxfcm91dGUsIHRoLT5yZCwgcmlmX2xlbiAtIDIpOw0K LQkJCQlzZGwtPnNkbF9yY2YgJj0gfmh0b25zKFRSX1JDRl9CQ1NUX01BU0sp Ow0KKwkJCQl0cmxkLT50cmxkX3JjZiA9IHRoLT5yY2Y7DQorCQkJCXRybGQt PnRybGRfcmNmIF49IGh0b25zKFRSX1JDRl9ESVIpOw0KKwkJCQltZW1jcHko dHJsZC0+dHJsZF9yb3V0ZSwgdGgtPnJkLCByaWZfbGVuIC0gMik7DQorCQkJ CXRybGQtPnRybGRfcmNmICY9IH5odG9ucyhUUl9SQ0ZfQkNTVF9NQVNLKTsN CiAJCQkJLyoNCiAJCQkJICogU2V0IHVwIHNvdXJjZSByb3V0aW5nIGluZm9y bWF0aW9uIGZvcg0KIAkJCQkgKiByZXBseSBwYWNrZXQgKFhYWCkNCkBAIC02 NzUsOSArNjc2LDcgQEANCiAJCQltLT5tX2RhdGEgLT0gODsNCiAJCQltLT5t X2xlbiAgKz0gODsNCiAJCQltLT5tX3BrdGhkci5sZW4gKz0gODsNCi0JCQl0 aC0+cmNmID0gc2RsLT5zZGxfcmNmOw0KLQkJfSBlbHNlIHsNCi0JCQlzZGwt PnNkbF9yY2YgPSAodV9zaG9ydCkwOw0KKwkJCXRoLT5yY2YgPSB0cmxkLT50 cmxkX3JjZjsNCiAJCX0NCiAJCWlmIChydC0+cnRfZXhwaXJlKQ0KIAkJCXJ0 LT5ydF9leHBpcmUgPSB0aW1lX3NlY29uZCArIGFycHRfa2VlcDsNCg== --0-819770887-1020217113=:11009 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sdl_data-overflow.diff" Content-Transfer-Encoding: BASE64 Content-ID: <20020430183833.U11009@gateway.posi.net> Content-Description: Content-Disposition: attachment; filename="sdl_data-overflow.diff" SW5kZXg6IG5ldC9pZl9kbC5oDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL25ldC9pZl9kbC5oLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS4xMQ0KZGlmZiAtdSAtdSAtcjEuMTEgaWZf ZGwuaA0KLS0tIG5ldC9pZl9kbC5oCTE5IE1hciAyMDAyIDIxOjU0OjE2IC0w MDAwCTEuMTENCisrKyBuZXQvaWZfZGwuaAkxIE1heSAyMDAyIDAxOjExOjQy IC0wMDAwDQpAQCAtNjYsMTAgKzY2LDggQEANCiAJdV9jaGFyCXNkbF9ubGVu OwkvKiBpbnRlcmZhY2UgbmFtZSBsZW5ndGgsIG5vIHRyYWlsaW5nIDAgcmVx ZC4gKi8NCiAJdV9jaGFyCXNkbF9hbGVuOwkvKiBsaW5rIGxldmVsIGFkZHJl c3MgbGVuZ3RoICovDQogCXVfY2hhcglzZGxfc2xlbjsJLyogbGluayBsYXll ciBzZWxlY3RvciBsZW5ndGggKi8NCi0JY2hhcglzZGxfZGF0YVsxMl07CS8q IG1pbmltdW0gd29yayBhcmVhLCBjYW4gYmUgbGFyZ2VyOw0KKwljaGFyCXNk bF9kYXRhWzQ2XTsJLyogbWluaW11bSB3b3JrIGFyZWEsIGNhbiBiZSBsYXJn ZXI7DQogCQkJCSAgIGNvbnRhaW5zIGJvdGggaWYgbmFtZSBhbmQgbGwgYWRk cmVzcyAqLw0KLQl1X3Nob3J0CXNkbF9yY2Y7CS8qIHNvdXJjZSByb3V0aW5n IGNvbnRyb2wgKi8NCi0JdV9zaG9ydAlzZGxfcm91dGVbMTZdOwkvKiBzb3Vy Y2Ugcm91dGluZyBpbmZvcm1hdGlvbiAqLw0KIH07DQogDQogI2RlZmluZSBM TEFERFIocykgKChjYWRkcl90KSgocyktPnNkbF9kYXRhICsgKHMpLT5zZGxf bmxlbikpDQpJbmRleDogbmV0L2lmX2lzbzg4MDI1c3Vici5jDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lz L25ldC9pZl9pc284ODAyNXN1YnIuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9u IDEuMjANCmRpZmYgLXUgLXUgLXIxLjIwIGlmX2lzbzg4MDI1c3Vici5jDQot LS0gbmV0L2lmX2lzbzg4MDI1c3Vici5jCTE0IERlYyAyMDAxIDE5OjI4OjQz IC0wMDAwCTEuMjANCisrKyBuZXQvaWZfaXNvODgwMjVzdWJyLmMJMSBNYXkg MjAwMiAwMToxMTo0MiAtMDAwMA0KQEAgLTI1Myw4ICsyNTMsOCBAQA0KIA0K IAkvKiBDYWxjdWxhdGUgcm91dGluZyBpbmZvIGxlbmd0aCBiYXNlZCBvbiBh cnAgdGFibGUgZW50cnkgKi8NCiAJaWYgKHJ0ICYmIChzZGwgPSAoc3RydWN0 IHNvY2thZGRyX2RsICopcnQtPnJ0X2dhdGV3YXkpKQ0KLQkJaWYgKHNkbC0+ c2RsX3JjZiAhPSBOVUxMKQ0KLQkJCXJpZl9sZW4gPSBUUl9SQ0ZfUklGTEVO KHNkbC0+c2RsX3JjZik7DQorCQlpZiAoU0RMX0lTTzg4MDI1KHNkbCktPnRy bGRfcmNmICE9IE5VTEwpDQorCQkJcmlmX2xlbiA9IFRSX1JDRl9SSUZMRU4o U0RMX0lTTzg4MDI1KHNkbCktPnRybGRfcmNmKTsNCiANCiAJLyogR2VuZXJh dGUgYSBnZW5lcmljIDgwMi41IGhlYWRlciBmb3IgdGhlIHBhY2tldCAqLw0K IAlnZW5fdGguYWMgPSBUUl9BQzsNCkBAIC0yNjQsOSArMjY0LDEwIEBADQog CWlmIChyaWZfbGVuKSB7DQogCQlnZW5fdGguaXNvODgwMjVfc2hvc3RbMF0g fD0gVFJfUklJOw0KIAkJaWYgKHJpZl9sZW4gPiAyKSB7DQotCQkJZ2VuX3Ro LnJjZiA9IHNkbC0+c2RsX3JjZjsNCisJCQlnZW5fdGgucmNmID0gU0RMX0lT Tzg4MDI1KHNkbCktPnRybGRfcmNmOw0KIAkJCSh2b2lkKW1lbWNweSgoY2Fk ZHJfdClnZW5fdGgucmQsDQotCQkJCShjYWRkcl90KXNkbC0+c2RsX3JvdXRl LCByaWZfbGVuIC0gMik7DQorCQkJCShjYWRkcl90KVNETF9JU084ODAyNShz ZGwpLT50cmxkX3JvdXRlLA0KKwkJCQlyaWZfbGVuIC0gMik7DQogCQl9DQog CX0NCiAJDQpJbmRleDogbmV0L2lzbzg4MDI1LmgNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvbmV0L2lz bzg4MDI1Lmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjUNCmRpZmYgLXUg LXUgLXIxLjUgaXNvODgwMjUuaA0KLS0tIG5ldC9pc284ODAyNS5oCTE4IE1h ciAyMDAxIDA1OjQxOjA3IC0wMDAwCTEuNQ0KKysrIG5ldC9pc284ODAyNS5o CTEgTWF5IDIwMDIgMDE6MTE6NDIgLTAwMDANCkBAIC0xMDksNiArMTA5LDE1 IEBADQogCXVfY2hhciBmYzsNCiB9Ow0KIA0KK3N0cnVjdCBpc284ODAyNV9z b2NrYWRkcl9kbF9kYXRhIHsNCisJdV9zaG9ydAkgdHJsZF9yY2Y7DQorCXVf c2hvcnQJKnRybGRfcm91dGVbUklGX01BWF9MRU5dOw0KK307DQorDQorI2Rl ZmluZSBTRExfSVNPODgwMjUocykJCSgoc3RydWN0IGlzbzg4MDI1X3NvY2th ZGRyX2RsX2RhdGEgKikJXA0KKwkJCQkgKChzKS0+c2RsX2RhdGEgKyBtaW4o KHMpLT5zZGxfbmxlbiArCVwNCisJCQkJICAocyktPnNkbF9hbGVuICsgKHMp LT5zZGxfc2xlbiwgMTIpKSkNCisNCiAvKg0KICAqIFN0cnVjdHVyZSBvZiBh IDQ4LWJpdCBpc28gODAyLjUgYWRkcmVzcy4NCiAgKiAgKCBXZSBjb3VsZCBh bHNvIGFkZCB0aGUgMTYgYml0IGFkZHJlc3NlcyBhcyBhIHVuaW9uKQ0KSW5k ZXg6IG5ldGluZXQvaWZfZXRoZXIuYw0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9uZXRpbmV0L2lmX2V0 aGVyLmMsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjkxDQpkaWZmIC11IC11 IC1yMS45MSBpZl9ldGhlci5jDQotLS0gbmV0aW5ldC9pZl9ldGhlci5jCTIw IE1hciAyMDAyIDE1OjU2OjM2IC0wMDAwCTEuOTENCisrKyBuZXRpbmV0L2lm X2V0aGVyLmMJMSBNYXkgMjAwMiAwMToxMTo0MyAtMDAwMA0KQEAgLTU3MSw2 ICs1NzEsNyBAQA0KIAlzdHJ1Y3QgZXRoZXJfaGVhZGVyICplaDsNCiAJc3Ry dWN0IGFyY19oZWFkZXIgKmFyaDsNCiAJc3RydWN0IGlzbzg4MDI1X2hlYWRl ciAqdGggPSAoc3RydWN0IGlzbzg4MDI1X2hlYWRlciAqKTA7DQorCXN0cnVj dCBpc284ODAyNV9zb2NrYWRkcl9kbF9kYXRhICp0cmxkOw0KIAlyZWdpc3Rl ciBzdHJ1Y3QgbGxpbmZvX2FycCAqbGEgPSAwOw0KIAlyZWdpc3RlciBzdHJ1 Y3QgcnRlbnRyeSAqcnQ7DQogCXN0cnVjdCBpZmFkZHIgKmlmYTsNCkBAIC02 OTcsNyArNjk4LDYgQEANCiAJCX0NCiAJCSh2b2lkKW1lbWNweShMTEFERFIo c2RsKSwgYXJfc2hhKGFoKSwNCiAJCSAgICBzZGwtPnNkbF9hbGVuID0gYWgt PmFyX2hsbik7DQotICAgICAgICAgICAgICAgIHNkbC0+c2RsX3JjZiA9ICh1 X3Nob3J0KTA7DQogCQkvKg0KIAkJICogSWYgd2UgcmVjZWl2ZSBhbiBhcnAg ZnJvbSBhIHRva2VuLXJpbmcgc3RhdGlvbiBvdmVyDQogCQkgKiBhIHRva2Vu LXJpbmcgbmljIHRoZW4gdHJ5IHRvIHNhdmUgdGhlIHNvdXJjZQ0KQEAgLTcw NSwxMyArNzA1LDE0IEBADQogCQkgKi8NCiAJCWlmIChpZnAtPmlmX3R5cGUg PT0gSUZUX0lTTzg4MDI1KSB7DQogCQkJdGggPSAoc3RydWN0IGlzbzg4MDI1 X2hlYWRlciAqKW0tPm1fcGt0aGRyLmhlYWRlcjsNCisJCQl0cmxkID0gU0RM X0lTTzg4MDI1KHNkbCk7DQogCQkJcmlmX2xlbiA9IFRSX1JDRl9SSUZMRU4o dGgtPnJjZik7DQogCQkJaWYgKCh0aC0+aXNvODgwMjVfc2hvc3RbMF0gJiBU Ul9SSUkpICYmDQogCQkJICAgIChyaWZfbGVuID4gMikpIHsNCi0JCQkJc2Rs LT5zZGxfcmNmID0gdGgtPnJjZjsNCi0JCQkJc2RsLT5zZGxfcmNmIF49IGh0 b25zKFRSX1JDRl9ESVIpOw0KLQkJCQltZW1jcHkoc2RsLT5zZGxfcm91dGUs IHRoLT5yZCwgcmlmX2xlbiAtIDIpOw0KLQkJCQlzZGwtPnNkbF9yY2YgJj0g fmh0b25zKFRSX1JDRl9CQ1NUX01BU0spOw0KKwkJCQl0cmxkLT50cmxkX3Jj ZiA9IHRoLT5yY2Y7DQorCQkJCXRybGQtPnRybGRfcmNmIF49IGh0b25zKFRS X1JDRl9ESVIpOw0KKwkJCQltZW1jcHkodHJsZC0+dHJsZF9yb3V0ZSwgdGgt PnJkLCByaWZfbGVuIC0gMik7DQorCQkJCXRybGQtPnRybGRfcmNmICY9IH5o dG9ucyhUUl9SQ0ZfQkNTVF9NQVNLKTsNCiAJCQkJLyoNCiAJCQkJICogU2V0 IHVwIHNvdXJjZSByb3V0aW5nIGluZm9ybWF0aW9uIGZvcg0KIAkJCQkgKiBy ZXBseSBwYWNrZXQgKFhYWCkNCkBAIC03MjUsOSArNzI2LDcgQEANCiAJCQlt LT5tX2RhdGEgLT0gODsNCiAJCQltLT5tX2xlbiAgKz0gODsNCiAJCQltLT5t X3BrdGhkci5sZW4gKz0gODsNCi0JCQl0aC0+cmNmID0gc2RsLT5zZGxfcmNm Ow0KLQkJfSBlbHNlIHsNCi0JCQlzZGwtPnNkbF9yY2YgPSAodV9zaG9ydCkw Ow0KKwkJCXRoLT5yY2YgPSB0cmxkLT50cmxkX3JjZjsNCiAJCX0NCiAJCWlm IChydC0+cnRfZXhwaXJlKQ0KIAkJCXJ0LT5ydF9leHBpcmUgPSB0aW1lX3Nl Y29uZCArIGFycHRfa2VlcDsNCg== --0-819770887-1020217113=:11009-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 1 2:59:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from gta.com (mailgate.gta.com [199.120.225.4]) by hub.freebsd.org (Postfix) with SMTP id 6EFC137B416 for ; Wed, 1 May 2002 02:59:16 -0700 (PDT) Received: (qmail 77488 invoked by uid 1000); 30 Apr 2002 20:32:37 -0000 Date: Tue, 30 Apr 2002 16:32:37 -0400 From: Larry Baird To: freebsd-net@freebsd.org Subject: PPPoE performance difference Message-ID: <20020430163237.A71846@gta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I had a friend that was claiming that they were seeing poor PPPoE performance from FreeBSD 4.4 as compared to Win2K. Since he is in Japan and I am in the US its a bit difficult to do hands on trouble shooting. So I decided to set up my on PPPoE server and see if I could reduplicate any of his claims. I setup a 4.5-RELEASE box as my PPPoE server and a 4.5-STABLE box as my PPPoE client. Both hosts are using Intel Pro 10/100 (fxp) nics. The client is a relatively fast 999.72-MHz 686-class CPU. The server is a slow 133.27-MHz 586-class CPU. I am seeing a performance difference that I can't explain. Coping of a large file (2.6MB) using scp to the server from the client takes about 7 seconds. Coping the same file from the server to the client takes 14 seconds. Any body have any idea why the two directions are so different? BTW, copying the file over ethernet (not PPPoE) takes 3 seconds in both directions between the same hosts using the same nics. The ppp.conf file for the server is: default: # set log Phase Chat LCP IPCP CCP tun command enable mssfixup set log error ident user-ppp VERSION (built COMPILATIONDATE) set dns 10.10.1.7 10.10.1.9 accept dns allow users enable chap enable pap set timeout 0 enable lqr accept lqr enable sroutes gta3: allow mode direct set mru 1492 set mtu 1492 set speed sync set ifaddr 10.199.2.1 10.199.2.110-10.199.2.200 255.255.255.255 For the client I used the following ppp.conf default: set socket none PPP0: set redial 0 0 set timeout 0 set reconnect 20 50000 set ifaddr 0.0.0.0/0 0.0.0.0/0 accept chap disable pap set authname testuser3 set authkey testpass set ctsrts off enable dns set dns 10.0.0.1 10.0.0.2 resolv readonly enable lqr set lqrperiod 20 accept lqr accept acfcomp accept protocomp accept pred1 accept vjcomp set log error set openmode active enable mssfixup set device PPPoE:fxp0:gta3 set speed sync set dial set cd 10 set login set mru 1492 set mtu 1492 Thanks for your time, Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gnatbox.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 1 9:41:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from ada.snu.ac.kr (ada.snu.ac.kr [147.46.106.49]) by hub.freebsd.org (Postfix) with ESMTP id A03AB37B416 for ; Wed, 1 May 2002 09:41:14 -0700 (PDT) Received: from ada.snu.ac.kr (localhost [127.0.0.1]) by ada.snu.ac.kr (8.12.2/8.12.2) with ESMTP id g41GfCja025748; Thu, 2 May 2002 01:41:12 +0900 (KST) (envelope-from redjade@ada.snu.ac.kr) Received: (from redjade@localhost) by ada.snu.ac.kr (8.12.2/8.12.2/Submit) id g41GfCtM025747; Thu, 2 May 2002 01:41:12 +0900 (KST) Date: Thu, 2 May 2002 01:41:11 +0900 From: Kyunghwan Kim To: freebsd-net@freebsd.org Subject: divert part is missing in bridge? Message-ID: <20020502014111.A25698@ada.snu.ac.kr> Reply-To: redjade@atropos.snu.ac.kr 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 I made a bridge with two NICs and configured natd-ipfw stuff. Then message below was seen. "/kernel: bdg_forward: No rules match, so dropping packet!" Comments in bdg_forward() in bridge.c say that /* * XXX add divert/forward actions... */ Routine that handles diverted packets in bridge is not yet implemented? Regards, Kyunghwan Kim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed May 1 10:40:19 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 9B4CF37B416 for ; Wed, 1 May 2002 10:40:08 -0700 (PDT) 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 <20020501174008.CNNH9799.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 1 May 2002 17: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 KAA72763; Wed, 1 May 2002 10:34:59 -0700 (PDT) Date: Wed, 1 May 2002 10:34:58 -0700 (PDT) From: Julian Elischer To: redjade@atropos.snu.ac.kr Cc: freebsd-net@freebsd.org Subject: Re: divert part is missing in bridge? In-Reply-To: <20020502014111.A25698@ada.snu.ac.kr> 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 you are correct.. diversion is difficult because returned packets are handed tothe IPinout code which is obviously wrong for a bridged packet.. It's nto so complicated code however, so you may consider fully understanding the problem and solving it if you want a project :-) On Thu, 2 May 2002, Kyunghwan Kim wrote: > I made a bridge with two NICs and configured natd-ipfw stuff. > Then message below was seen. > "/kernel: bdg_forward: No rules match, so dropping packet!" > > Comments in bdg_forward() in bridge.c say that > /* > * XXX add divert/forward actions... > */ > Routine that handles diverted packets in bridge is not yet implemented? > > Regards, > Kyunghwan Kim > > 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 May 2 5:49:11 2002 Delivered-To: freebsd-net@freebsd.org Received: from dignus.com (sdsl-64-32-254-102.dsl.iad.megapath.net [64.32.254.102]) by hub.freebsd.org (Postfix) with ESMTP id C300937B416; Thu, 2 May 2002 05:48:59 -0700 (PDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.11.6/8.11.3) with ESMTP id g42CieA44777; Thu, 2 May 2002 08:44:40 -0400 (EDT) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.11.6/8.11.3) id g42CkCQ45735; Thu, 2 May 2002 08:46:12 -0400 (EDT) (envelope-from rivers) Date: Thu, 2 May 2002 08:46:12 -0400 (EDT) From: Thomas David Rivers Message-Id: <200205021246.g42CkCQ45735@lakes.dignus.com> To: K.J.Koster@kpn.com, rivers@dignus.com Subject: RE: Anyone using pptp? Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <59063B5B4D98D311BC0D0001FA7E452205FDA69A@l04.research.kpn.com> 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 Thomas, > > > > > Well - I'm still trying to get pptp to cooperate and set up > > a VPN connection to a Microsoft VPN server. > > > > I'm just wondering - is there _anyone_ out there that has > > met with success using pptp - and, if so, could you share > > your /etc/ppp/ppp.conf settings? > > > http://kjkoster.org/?page=content/adsl.jsp It's specific for my provider, > though. > > Kees Jan > Thanks Kees! I read through your web pages - very nicely done, by the way! But - I'm afraid your /etc/ppp/ppp.conf doesn't work for me. Here's the current issue: The Microsoft VPN server I'm talking to is insisting on an encrypted MPPE connection at the LCP level. That connection requires MSChapV2 (0x81). If I add enable MSChapV2 in /etc/ppp/ppp.conf - then our ppp client requires that the peer (the Microsoft VPN server) authenticate using MSChapV2. But, the Microsoft VPN peer refuses that (it's configured to not use MSChapV2. So - I'm in the situation of both requiring and disallowing MSChapV2. Does anyone know if there is a way in /etc/ppp/ppp.conf to accomplish this? Some people on the Linux lists suggested that the FreeBSD ppp might have a "noauth" option, which meant that the peer didn't have to authenticate itself - but I couldn't find such an option. Any pointers would be appreciated! - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 2 8:26:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by hub.freebsd.org (Postfix) with ESMTP id 9586B37B417 for ; Thu, 2 May 2002 08:26:20 -0700 (PDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 11:26:19 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE460236AE@ftmail> From: Matt Impett To: "'freebsd-net@FreeBSD.org'" Subject: source MAC address Date: Thu, 2 May 2002 11:26:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello all, I am implementing mobileIP in user space on freeBSD and was curious about something. In order to do mobileIP IP address assignment, my process on freeBSD has to be able to receive an IP packet and learn the source MAC address that it came from (I am sure that the packet is only going one hop). I have been able to do this using the BPF device, but am concerned about a few things: 1) When using the BPF device, the IP packet still goes to the IP stack, and since I am no longer listening on the UDP port number, a ICMP port unreachable is sent. I guess I could us ip_fw to fix this. 2) When using the BPF device, I am bypassing the IP stack. Therefore, I am losing things like reassembly, IPSEC, etc.. Is there another way to get this info up to an application without using BPF? Likewise, I also want to be able to force IP packets out to a particular MAC address, regardless of the IP destination address of the packet. Once again, I know BPF can do this, but then I have similar concerns to the ones above. For example, what do I set the IP ID field to?? If I accidentally match an ID field that the kernel has used previously, then reassembly could get confused on the end host. thanks a lot, matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 2 8:40:35 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 C8B6A37B425 for ; Thu, 2 May 2002 08:40:08 -0700 (PDT) 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 <20020502154008.XOJI2627.rwcrmhc54.attbi.com@InterJet.elischer.org>; Thu, 2 May 2002 15: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 IAA77662; Thu, 2 May 2002 08:28:44 -0700 (PDT) Date: Thu, 2 May 2002 08:28:42 -0700 (PDT) From: Julian Elischer To: Matt Impett Cc: "'freebsd-net@FreeBSD.org'" Subject: Re: source MAC address In-Reply-To: <8C92E23A3E87FB479988285F9E22BE460236AE@ftmail> 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 look at the following alternat ways to get data out of the kernel: 1/ ipfw + divert 2/ netgraph (can attach to sockets and interfaces and can provide sockets and interfaces.. mix-n-match) On Thu, 2 May 2002, Matt Impett wrote: > Hello all, > > I am implementing mobileIP in user space on freeBSD and was curious about > something. In order to do mobileIP IP address assignment, my process on > freeBSD has to be able to receive an IP packet and learn the source MAC > address that it came from (I am sure that the packet is only going one hop). > I have been able to do this using the BPF device, but am concerned about a > few things: > 1) When using the BPF device, the IP packet still goes to the IP stack, and > since I am no longer listening on the UDP port number, a ICMP port > unreachable is sent. I guess I could us ip_fw to fix this. > 2) When using the BPF device, I am bypassing the IP stack. Therefore, I am > losing things like reassembly, IPSEC, etc.. > > Is there another way to get this info up to an application without using > BPF? > > Likewise, I also want to be able to force IP packets out to a particular MAC > address, regardless of the IP destination address of the packet. Once > again, I know BPF can do this, but then I have similar concerns to the ones > above. For example, what do I set the IP ID field to?? If I accidentally > match an ID field that the kernel has used previously, then reassembly could > get confused on the end host. > > thanks a lot, > matt > > 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 May 2 12:30: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 D78A037B41A; Thu, 2 May 2002 12:30:07 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA78335; Thu, 2 May 2002 12:22:08 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g42JM8H97301; Thu, 2 May 2002 12:22:08 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205021922.g42JM8H97301@arch20m.dellroad.org> Subject: Re: Anyone using pptp? In-Reply-To: <200205021246.g42CkCQ45735@lakes.dignus.com> "from Thomas David Rivers at May 2, 2002 08:46:12 am" To: Thomas David Rivers Date: Thu, 2 May 2002 12:22:08 -0700 (PDT) Cc: K.J.Koster@kpn.com, freebsd-hackers@FreeBSD.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 Thomas David Rivers writes: > If I add > enable MSChapV2 > in /etc/ppp/ppp.conf - then our ppp client requires that the > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > the Microsoft VPN peer refuses that (it's configured to not use > MSChapV2. Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? -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 Thu May 2 12:42:23 2002 Delivered-To: freebsd-net@freebsd.org Received: from dignus.com (sdsl-64-32-254-102.dsl.iad.megapath.net [64.32.254.102]) by hub.freebsd.org (Postfix) with ESMTP id B1A8937B417; Thu, 2 May 2002 12:42:09 -0700 (PDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.11.6/8.11.3) with ESMTP id g42JbfA48364; Thu, 2 May 2002 15:37:41 -0400 (EDT) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.11.6/8.11.3) id g42JdEK49871; Thu, 2 May 2002 15:39:14 -0400 (EDT) (envelope-from rivers) Date: Thu, 2 May 2002 15:39:14 -0400 (EDT) From: Thomas David Rivers Message-Id: <200205021939.g42JdEK49871@lakes.dignus.com> To: archie@dellroad.org, rivers@dignus.com Subject: Re: Anyone using pptp? Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, K.J.Koster@kpn.com In-Reply-To: <200205021922.g42JM8H97301@arch20m.dellroad.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 > > Thomas David Rivers writes: > > If I add > > enable MSChapV2 > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > the Microsoft VPN peer refuses that (it's configured to not use > > MSChapV2. > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? > > -Archie > Something like that... but - that's the default setting. With the default setting, it seems to pass through CHAP (0x80) Authentication. But - then, the MPPE encryption is not allowed - because MPPE compression requires MSChapV2 (0x81) Authentication... and, the VPN server doesn't authenticate that way. I notice there is a line in the ppp man page: For now, ppp can only get encryption keys from CHAP 81 authentication. But - the (Microsoft Win2000) VPN server I'm trying to talk do doesn't allow CHAP 81 authentication, but wants to use MPPE... - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 2 13: 0:38 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 8124237B416; Thu, 2 May 2002 13:00:31 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA78509; Thu, 2 May 2002 12:49:33 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g42JnXq97404; Thu, 2 May 2002 12:49:33 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205021949.g42JnXq97404@arch20m.dellroad.org> Subject: Re: Anyone using pptp? In-Reply-To: <200205021939.g42JdEK49871@lakes.dignus.com> "from Thomas David Rivers at May 2, 2002 03:39:14 pm" To: Thomas David Rivers Date: Thu, 2 May 2002 12:49:33 -0700 (PDT) Cc: archie@dellroad.org, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, K.J.Koster@kpn.com 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 Thomas David Rivers writes: > > > enable MSChapV2 > > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > > the Microsoft VPN peer refuses that (it's configured to not use > > > MSChapV2. > > > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? > > Something like that... but - that's the default setting. With the > default setting, it seems to pass through CHAP (0x80) Authentication. > > But - then, the MPPE encryption is not allowed - because MPPE > compression requires MSChapV2 (0x81) Authentication... and, the > VPN server doesn't authenticate that way. > > I notice there is a line in the ppp man page: > > For now, ppp can only get encryption keys from CHAP 81 > authentication. > > But - the (Microsoft Win2000) VPN server I'm trying to talk do doesn't > allow CHAP 81 authentication, but wants to use MPPE... In that case you need to use mpd I guess. -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 Thu May 2 13:18:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from dignus.com (sdsl-64-32-254-102.dsl.iad.megapath.net [64.32.254.102]) by hub.freebsd.org (Postfix) with ESMTP id AB77937B9D9; Thu, 2 May 2002 13:16:37 -0700 (PDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.11.6/8.11.3) with ESMTP id g42KCHA48619; Thu, 2 May 2002 16:12:17 -0400 (EDT) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.11.6/8.11.3) id g42KDoc50328; Thu, 2 May 2002 16:13:50 -0400 (EDT) (envelope-from rivers) Date: Thu, 2 May 2002 16:13:50 -0400 (EDT) From: Thomas David Rivers Message-Id: <200205022013.g42KDoc50328@lakes.dignus.com> To: archie@dellroad.org, rivers@dignus.com Subject: Re: Anyone using pptp? Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, K.J.Koster@kpn.com In-Reply-To: <200205021949.g42JnXq97404@arch20m.dellroad.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 Archie Cobbs wrote: > > Thomas David Rivers writes: > > > > enable MSChapV2 > > > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > > > the Microsoft VPN peer refuses that (it's configured to not use > > > > MSChapV2. > > > > > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? > > > > Something like that... but - that's the default setting. With the > > default setting, it seems to pass through CHAP (0x80) Authentication. > > > > But - then, the MPPE encryption is not allowed - because MPPE > > compression requires MSChapV2 (0x81) Authentication... and, the > > VPN server doesn't authenticate that way. > > > > I notice there is a line in the ppp man page: > > > > For now, ppp can only get encryption keys from CHAP 81 > > authentication. > > > > But - the (Microsoft Win2000) VPN server I'm trying to talk do doesn't > > allow CHAP 81 authentication, but wants to use MPPE... > > In that case you need to use mpd I guess. > > -Archie > Yes - after some other investigation - I arrived at the same idea. mpd fails as well... with something very similar... it seems to send a CCP configuration request and simply gets no answer back from the Microsoft server. From the VPN log (you can see toward the bottom that both IPCP and CCP complain that parameter negotiation failed): [vpn] LCP: authorization successful [vpn] LCP: phase shift AUTHENTICATE --> NETWORK [vpn] up: 1 link, total bandwidth 64000 bps [vpn] IPCP: Up event [vpn] IPCP: state change Starting --> Req-Sent [vpn] IPCP: SendConfigReq #1 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: Open event [vpn] CCP: state change Initial --> Starting [vpn] CCP: LayerStart [vpn] CCP: Up event [vpn] CCP: state change Starting --> Req-Sent [vpn] CCP: SendConfigReq #1 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #2 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #2 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #3 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #3 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #4 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #4 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #5 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #5 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #6 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #6 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #7 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #7 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #8 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #8 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #9 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #9 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: SendConfigReq #10 IPADDR 192.168.1.1 COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [vpn] CCP: SendConfigReq #10 MPPC 0x01000060: MPPE, 40 bit, 128 bit, stateless [vpn] IPCP: state change Req-Sent --> Stopped [vpn] IPCP: LayerFinish [vpn] IPCP: parameter negotiation failed [vpn] IPCP: LayerFinish [vpn] CCP: state change Req-Sent --> Stopped [vpn] CCP: LayerFinish [vpn] CCP: parameter negotiation failed [vpn] CCP: Close event [vpn] CCP: state change Stopped --> Closed [vpn] CCP: encryption required, but MPPE was not negotiated in both directions [vpn] CCP: failed to negotiate required encryption [vpn] CCP: Close event [vpn] CCP: LayerFinish [vpn] IPCP: failed to negotiate required encryption [vpn] IPCP: LayerFinish [vpn] CCP: LayerFinish [vpn] bundle: CLOSE event in state OPENED [vpn] closing link "vpn"... [vpn] bundle: CLOSE event in state CLOSED [vpn] closing link "vpn"... [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] LCP: state change Opened --> Closing [vpn] LCP: phase shift NETWORK --> TERMINATE [vpn] up: 0 links, total bandwidth 9600 bps [vpn] IPCP: Down event [vpn] IPCP: state change Stopped --> Starting [vpn] IPCP: LayerStart [vpn] CCP: Down event [vpn] CCP: state change Closed --> Initial [vpn] CCP: Close event [vpn] closing link "vpn"... [vpn] LCP: SendTerminateReq #4 [vpn] LCP: LayerDown [vpn] bundle: CLOSE event in state CLOSED [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] bundle: OPEN event in state CLOSED [vpn] opening link "vpn"... [vpn] link: CLOSE event [vpn] LCP: Close event [vpn] link: OPEN event [vpn] LCP: Open event [vpn] LCP: state change Closing --> Stopping pptp0: CID 0xdac8 in SetLinkInfo not found [vpn] LCP: rec'd Terminate Ack #4 link 0 (Stopping) [vpn] LCP: state change Stopping --> Stopped [vpn] LCP: phase shift TERMINATE --> ESTABLISH [vpn] LCP: LayerFinish [vpn] device: CLOSE event in state UP pptp0-0: clearing call [vpn] device is now in state CLOSING [vpn] device: DOWN event in state CLOSING [vpn] device is now in state DOWN [vpn] link: DOWN event [vpn] LCP: Down event [vpn] LCP: state change Stopped --> Starting [vpn] LCP: phase shift ESTABLISH --> DEAD [vpn] LCP: LayerStart [vpn] device: OPEN event in state DOWN [vpn] pausing 7 seconds before open [vpn] device is now in state DOWN [vpn] device: OPEN event in state DOWN [vpn] device is now in state DOWN pptp0-0: peer call disconnected res=zero? err=none pptp0-0: killing channel pptp0: closing connection with 157.189.4.10:1723 pptp0: invalid length 16 for type 4 pptp0: killing connection with 157.189.4.10:1723 ^Cmpd: caught fatal signal int mpd: fatal error, exiting [vpn] IPCP: Down event [vpn] IFACE: Close event [vpn] IPCP: Close event [vpn] IPCP: state change Starting --> Initial [vpn] IPCP: LayerFinish mpd: process 3199 terminated office# ^Dexit Script done on Thu May 2 11:03:31 2002 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 2 14: 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 171E837B41D; Thu, 2 May 2002 14:00:06 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA78954; Thu, 2 May 2002 13:54:58 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g42KsvJ97713; Thu, 2 May 2002 13:54:57 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205022054.g42KsvJ97713@arch20m.dellroad.org> Subject: Re: Anyone using pptp? In-Reply-To: <200205022013.g42KDoc50328@lakes.dignus.com> "from Thomas David Rivers at May 2, 2002 04:13:50 pm" To: Thomas David Rivers Date: Thu, 2 May 2002 13:54:57 -0700 (PDT) Cc: freebsd-net@FreeBSD.ORG, K.J.Koster@kpn.com 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 [ note: freebsd-hackers being removed from the cc: list ] Thomas David Rivers writes: > mpd fails as well... with something very similar... it seems to > send a CCP configuration request and simply gets no answer > back from the Microsoft server. From the VPN log (you can see > toward the bottom that both IPCP and CCP complain that > parameter negotiation failed): Maybe the server is having trouble acquiring an IP address for you via DHCP? Sometimes this kind of trace results from the server 'freezing up' due to any random error condition such as no DHCP, network access denied, etc. -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 Thu May 2 14:20:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id B6A7B37B41E; Thu, 2 May 2002 14:20:33 -0700 (PDT) Received: from pool0524.cvx21-bradley.dialup.earthlink.net ([209.179.194.14] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 173O05-0001XW-00; Thu, 02 May 2002 14:20:29 -0700 Message-ID: <3CD1AD80.DFCC100F@mindspring.com> Date: Thu, 02 May 2002 14:20:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Archie Cobbs Cc: Thomas David Rivers , K.J.Koster@kpn.com, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Anyone using pptp? References: <200205021922.g42JM8H97301@arch20m.dellroad.org> 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 Archie Cobbs wrote: > Thomas David Rivers writes: > > If I add > > enable MSChapV2 > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > the Microsoft VPN peer refuses that (it's configured to not use > > MSChapV2. > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? The MS PAP/CHAP stuff never made it to RFC because of the protocol layering violations. I think the problem T.D.R. is seeing are a result of not having some covert channel, which is *not* MSChapV2, to get a session key for the VPN session. I guess we need to see a packet trace for a Windows machine being successful, and a FreeBSD machine being unsuccessful, in order to run a side-by-side comparison. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 2 14:22:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 0887B37B416 for ; Thu, 2 May 2002 14:22:25 -0700 (PDT) Received: from pool0524.cvx21-bradley.dialup.earthlink.net ([209.179.194.14] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 173O1t-0004F5-00; Thu, 02 May 2002 14:22:22 -0700 Message-ID: <3CD1ADF0.A883274@mindspring.com> Date: Thu, 02 May 2002 14:21:52 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Archie Cobbs Cc: Thomas David Rivers , freebsd-net@FreeBSD.ORG, K.J.Koster@kpn.com Subject: Re: Anyone using pptp? References: <200205022054.g42KsvJ97713@arch20m.dellroad.org> 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 Archie Cobbs wrote: > [ note: freebsd-hackers being removed from the cc: list ] > Thomas David Rivers writes: > > mpd fails as well... with something very similar... it seems to > > send a CCP configuration request and simply gets no answer > > back from the Microsoft server. From the VPN log (you can see > > toward the bottom that both IPCP and CCP complain that > > parameter negotiation failed): > > Maybe the server is having trouble acquiring an IP address > for you via DHCP? Sometimes this kind of trace results from > the server 'freezing up' due to any random error condition > such as no DHCP, network access denied, etc. Actually, I've seen something very similar to this; the Windows stuff actually says "authenticating with server" followed by "authenticating to network". It actually goes through two authentication cycles, for some types of connections. Maybe it's not reauthenticating? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 2 14:36:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from dignus.com (sdsl-64-32-254-102.dsl.iad.megapath.net [64.32.254.102]) by hub.freebsd.org (Postfix) with ESMTP id 1295B37B419; Thu, 2 May 2002 14:36:26 -0700 (PDT) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.11.6/8.11.3) with ESMTP id g42LW2A49191; Thu, 2 May 2002 17:32:02 -0400 (EDT) (envelope-from rivers@dignus.com) Received: (from rivers@localhost) by lakes.dignus.com (8.11.6/8.11.3) id g42LXZE51368; Thu, 2 May 2002 17:33:35 -0400 (EDT) (envelope-from rivers) Date: Thu, 2 May 2002 17:33:35 -0400 (EDT) From: Thomas David Rivers Message-Id: <200205022133.g42LXZE51368@lakes.dignus.com> To: archie@dellroad.org, tlambert2@mindspring.com Subject: Re: Anyone using pptp? Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, K.J.Koster@kpn.com, rivers@dignus.com In-Reply-To: <3CD1AD80.DFCC100F@mindspring.com> 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 Terry Lambert wrote: > > Archie Cobbs wrote: > > Thomas David Rivers writes: > > > If I add > > > enable MSChapV2 > > > in /etc/ppp/ppp.conf - then our ppp client requires that the > > > peer (the Microsoft VPN server) authenticate using MSChapV2. But, > > > the Microsoft VPN peer refuses that (it's configured to not use > > > MSChapV2. > > > > Don't you want something like "allow MSChapV2" and "disable MSChapV2" ? > > The MS PAP/CHAP stuff never made it to RFC because of the > protocol layering violations. > > I think the problem T.D.R. is seeing are a result of not > having some covert channel, which is *not* MSChapV2, to get > a session key for the VPN session. > > I guess we need to see a packet trace for a Windows machine > being successful, and a FreeBSD machine being unsuccessful, > in order to run a side-by-side comparison. Believe me! I've asked for such a thingy... apparently, the "magic software" needed to do a packet trace on Windows isn't installed on the server. - Dave Rivers - -- rivers@dignus.com Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 2 15: 5:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id B438137B42A; Thu, 2 May 2002 15:05:18 -0700 (PDT) Received: from pool0524.cvx21-bradley.dialup.earthlink.net ([209.179.194.14] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 173OhO-0002xV-00; Thu, 02 May 2002 15:05:14 -0700 Message-ID: <3CD1B7FD.A23C5ED3@mindspring.com> Date: Thu, 02 May 2002 15:04:45 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas David Rivers Cc: archie@dellroad.org, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG, K.J.Koster@kpn.com Subject: Re: Anyone using pptp? References: <200205022133.g42LXZE51368@lakes.dignus.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 Thomas David Rivers wrote: > > I guess we need to see a packet trace for a Windows machine > > being successful, and a FreeBSD machine being unsuccessful, > > in order to run a side-by-side comparison. > > Believe me! I've asked for such a thingy... apparently, > the "magic software" needed to do a packet trace on Windows > isn't installed on the server. You should be able to do it at the client (your) end, and they should be able to do it with some pain on their end by setting up a "monitoring port" on the switch for the server traffic, and doing a dump on whatever box they have available that can do dumps. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 2 17:31:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from fw.wemm.org (12-232-135-171.client.attbi.com [12.232.135.171]) by hub.freebsd.org (Postfix) with ESMTP id BDB7937B41B for ; Thu, 2 May 2002 17:31:25 -0700 (PDT) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (8.11.6/8.11.6) with ESMTP id g430VP407962 for ; Thu, 2 May 2002 17:31:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 7495338FD for ; Thu, 2 May 2002 17:31:25 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-net@freebsd.org Subject: PHY patch, please test. (fwd) Date: Thu, 02 May 2002 17:31:25 -0700 From: Peter Wemm Message-Id: <20020503003125.7495338FD@overcee.wemm.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 Poul-Henning is proposing removing some synchronization features of miibus. Can somebody who understands this please check into it? I'm forwarding it here because it was posted to the wrong list. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 ------- Forwarded Message Date: Wed, 01 May 2002 11:45:37 +0200 From: Poul-Henning Kamp To: current@FreeBSD.ORG Subject: PHY patch, please test. This patch simplifies the auto-negotiation in the MII/PHY code, but I don't have enough weird ethernet cards to test it out. Please test and if it doesn't work send me dmesg -v output and info on what netcard it breaks. http://phk.freebsd.dk/patch/phy00.patch I hope to commit it this weekend. I am also interested to hear from people using the NetGear 622 or other if_nge based gigabit cards. Thanks in advance! - -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu May 2 22:46:15 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 B5F5537B405 for ; Thu, 2 May 2002 22:46:10 -0700 (PDT) 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 <20020503054610.MTKI5896.rwcrmhc53.attbi.com@blossom.cjclark.org>; Fri, 3 May 2002 05:46:10 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g435k9571437; Thu, 2 May 2002 22:46:09 -0700 (PDT) (envelope-from cjc) Date: Thu, 2 May 2002 22:46:09 -0700 From: "Crist J. Clark" To: Matt Impett Cc: "'freebsd-net@FreeBSD.org'" Subject: Re: source MAC address Message-ID: <20020502224609.A71286@blossom.cjclark.org> References: <8C92E23A3E87FB479988285F9E22BE460236AE@ftmail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8C92E23A3E87FB479988285F9E22BE460236AE@ftmail>; from M.Impett@flarion.com on Thu, May 02, 2002 at 11:26:16AM -0400 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 Thu, May 02, 2002 at 11:26:16AM -0400, Matt Impett wrote: > Hello all, > > I am implementing mobileIP in user space on freeBSD and was curious about > something. In order to do mobileIP IP address assignment, my process on > freeBSD has to be able to receive an IP packet and learn the source MAC > address that it came from (I am sure that the packet is only going one hop). > I have been able to do this using the BPF device, but am concerned about a > few things: > 1) When using the BPF device, the IP packet still goes to the IP stack, and > since I am no longer listening on the UDP port number, a ICMP port > unreachable is sent. I guess I could us ip_fw to fix this. By the time the system learns its IP address, you can open up a UDP socket and listen there. No need to use bpf(4). No ICMP unreachable sent. In the initial phases, before the system learns its IP, this is when you need to use bpf(4), but the system won't generate ICMP unreachable since the packet doesn't go to the IP stack. > 2) When using the BPF device, I am bypassing the IP stack. Therefore, I am > losing things like reassembly, IPSEC, etc.. Make sure you don't need those things in the bootstrapping phases. ;) > Is there another way to get this info up to an application without using > BPF? Even the dhclient(8) uses bpf(4) now. I seems to be the best tool for the job. > Likewise, I also want to be able to force IP packets out to a particular MAC > address, regardless of the IP destination address of the packet. Once > again, I know BPF can do this, but then I have similar concerns to the ones > above. For example, what do I set the IP ID field to?? IP ID? Set the DF bit, then the IP ID field won't ever be used. Set it to zero or the constant value of your choice. -- 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 May 3 1:27:50 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 B955937B420; Fri, 3 May 2002 01:27:37 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1098) id 888D1AE1D7; Fri, 3 May 2002 01:27:37 -0700 (PDT) Date: Fri, 3 May 2002 01:27:37 -0700 From: Bill Fumerola To: andrew mejia Cc: freebsd-net@FreeBSD.ORG Subject: Re: network design Message-ID: <20020503082737.GN688@elvis.mu.org> Reply-To: freebsd-net@FreeBSD.org References: <3CD17557.7BC1F7C0@mindspring.com> <20020503073501.67347.qmail@web14802.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020503073501.67347.qmail@web14802.mail.yahoo.com> User-Agent: Mutt/1.3.27i X-Operating-System: FreeBSD 4.5-MUORG-20020423 i386 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ this is probably more appropriate for -net, -hackers bcc:'d ] On Fri, May 03, 2002 at 08:35:01AM +0100, andrew mejia wrote: > [andrew]$ exactly what i would suggest. a single > NIC can handle multiple assigments pretty easily, > unless you're expecting mega-traffic. but even then > you could use the native load balancing/caching tech- > nology offered with some other freewares (like > apache web server). finding content in the above post is like a "Where's Waldo?" puzzle. you would suggest exactly what? this has nothing to do with multiple IP addresses (which is what i assume you're talking about when you say, "NIC can handle multiple assignments") neither in the traditional 'secondary address' sense nor as IPs aliased to a loopback interface. this has nothing to do with load balancing or webservers or caching or mega-traffic(?!). this is about representing within the freebsd network stack ethernet cards that support multiple (>1) unicast mac addresses through either multiple perfect filter entries or a multicast filter borrowed to serve such a purpose. until freebsd has a way of supporting this, failover technologies like vrrp (or any where members 'share' a common lladdr) will be impossible to implement properly. i believe the hangup is that adding an interface to network drivers is the easy part relative to teaching the network stack about network cards with more then one lladdr. specifically, which mac address do you use when putting a frame onto the wire that was locally generated? forwarded? -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 3 6:39:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from tesla.foo.is (tesla.reverse-bias.org [217.151.166.96]) by hub.freebsd.org (Postfix) with ESMTP id 020D637B421; Fri, 3 May 2002 06:39:03 -0700 (PDT) Received: from there (eniac.foo.is [192.168.1.25]) by tesla.foo.is (Postfix) with SMTP id 9D6DD2744; Fri, 3 May 2002 13:38:56 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" From: Baldur Gislason To: Dan Protich Subject: Re: misc/37696: Virtual hosts broken Date: Fri, 3 May 2002 13:37:39 +0000 X-Mailer: KMail [version 1.3.2] References: <200205030539.g435dsbm090704@nwww.freebsd.org> In-Reply-To: <200205030539.g435dsbm090704@nwww.freebsd.org> Cc: freebsd-gnats-submit@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020503133856.9D6DD2744@tesla.foo.is> 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 Problem exists between keyboard and chair. The reason why ifconfig complains is that you're assigning a point-to-point address to an ethernet interface and both addresses have the same point-to-point address. This is how you add ips to an interface: ifconfig xl0 192.168.1.1 netmask 255.255.255.0 # this is the primary ifconfig xl0 add 192.168.1.254 netmask 255.255.255.255 # All extra addresses within the same subnet MUST have netmask 0xffffffff or 255.255.255.255 to prevent routing problems. Baldur On Friday 03 May 2002 05:39, you wrote: > >Number: 37696 > >Category: misc > >Synopsis: Virtual hosts broken > >Confidential: no > >Severity: serious > >Priority: high > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Thu May 02 22:40:01 PDT 2002 > >Closed-Date: > >Last-Modified: > >Originator: Dan Protich > >Release: 4.6-PRERELEASE > >Organization: > > Shell-box Computers Inc. > > >Environment: > > bash-2.05a$ uname -a > FreeBSD sinister.shell-box.com 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #0: > Sat Mar 2 02:32:42 EST 2002 > root@sinister.shell-box.com:/usr/obj/usr/src/sys/GENERIC i386 bash-2.05a$ > > >Description: > > Thought that i would upgrade freebsd box and main dns server was on it only > accepted 1 virtual host and not a 2nd and wouldnt allow manual add of vhost > rc.conf network information wouldn't accept did a upgrade from 4.5-release > also kernel upgrade. > > >How-To-Repeat: > > sinister# ifconfig vr0 66.118.153.201 66.118.153.255 alias > sinister# ifconfig vr0 66.118.153.254 66.118.153.255 alias > ifconfig: ioctl (SIOCAIFADDR): File exists > sinister# > doesn't exist? > sinister# ifconfig > vr0: flags=8843 mtu 1500 > inet 66.118.153.66 netmask 0xffffff00 broadcast 66.118.153.255 > inet6 fe80::207:95ff:fea8:153b%vr0 prefixlen 64 scopeid 0x1 > inet 66.118.153.201 netmask 0xff000000 broadcast 66.118.153.255 > ether 00:07:95:a8:15:3b > media: Ethernet autoselect (100baseTX ) > status: active > lp0: flags=8810 mtu 1500 > sl0: flags=c010 mtu 552 > faith0: flags=8002 mtu 1500 > lo0: flags=8049 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 > inet 127.0.0.1 netmask 0xff000000 > ppp0: flags=8010 mtu 1500 > sinister# > > >Fix: > > > >Release-Note: > >Audit-Trail: > >Unformatted: > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-bugs" 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 May 3 10: 4:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id 7B05D37B416 for ; Fri, 3 May 2002 10:04:08 -0700 (PDT) Received: from pool0248.cvx40-bradley.dialup.earthlink.net ([216.244.42.248] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 173gTW-0001b5-00; Fri, 03 May 2002 10:04:07 -0700 Message-ID: <3CD2C2EA.334B5629@mindspring.com> Date: Fri, 03 May 2002 10:03:38 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Cc: andrew mejia Subject: Re: network design References: <3CD17557.7BC1F7C0@mindspring.com> <20020503073501.67347.qmail@web14802.mail.yahoo.com> <20020503082737.GN688@elvis.mu.org> 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 Bill Fumerola wrote: > this is about representing within the freebsd network stack ethernet > cards that support multiple (>1) unicast mac addresses through either > multiple perfect filter entries or a multicast filter borrowed to serve > such a purpose. until freebsd has a way of supporting this, failover > technologies like vrrp (or any where members 'share' a common lladdr) > will be impossible to implement properly. There is a VRRP implementation for FreeBSD that uses raw sockets and puts the interface into promiscuous mode. It manually handles whether or not it responds to ARPs. So it's possible. I think that the use of promiscuous mode is ugly, but... it works. http://www.bsdshell.net/ It's in ports/network. > i believe the hangup is that adding an interface to network drivers is > the easy part relative to teaching the network stack about network cards > with more then one lladdr. specifically, which mac address do you use > when putting a frame onto the wire that was locally generated? forwarded? I think this is mostly a card feature; Intel Gigabit Ethernet supports 16m Tigon III supports 4, and Tigon II supports 1 additional MAC address. I think the drivers, in these cases, need to export more than one single interface. If you do that, it's not a stack problem at all, it's an interrupt processing problem in the driver, since you have to differentiate inbound packets. The MAC address you use when sending or forwarding... is the MAC address for the virtual interface pointed to by the route. This probably needs to be virtualized as well, so that you can get the same effect by sticking a card in promiscuous mode; I would *not* suggest using the Linux VRRP implementation approach (implemented on the fxp driver) with the multicast hack. My reasoning for disdaining the multicast hack is that it can only ever work for one address, and when you lose it, you lose multicast support, which is mostly unacceptable. I think that things like SLPv2 are only going to become more common (SLP is one of the base protocols for some of Sun's Java Services platform), and losing multicast in trade for VRRP will eventually be a bad tradeoff. If not now, then when more cards support additional MAC addresses. When I posted on this, it was really to encourage someone to want to work on making cards that support it export more than one MAC address. I currently don't have the hardware needed to do the hacking on the drivers for this one. I would be more than willing, though, once the hardware version was happy, to work on the promiscuous mode software version on top of other cards that didn't support it in hardware. The constraint, to my mind, is the hardware interfaces, so any design has to permit hardware support before it can permit emulated hardware support (or emulation of more MACs than the hardware can support on hardware that supports more than one MAC, but fewer than the desired amount -- e.g. the Tigon II support for a single additional MAC doesn't allow more than two routers in a redundancy domain). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 3 20:17:12 2002 Delivered-To: freebsd-net@freebsd.org Received: from saturn.home.ben.com (12-224-234-131.client.attbi.com [12.224.234.131]) by hub.freebsd.org (Postfix) with ESMTP id 4093737B404 for ; Fri, 3 May 2002 20:17:09 -0700 (PDT) Received: from pulsar.home.ben.com (pulsar.home.ben.com [172.17.42.9]) by saturn.home.ben.com (8.12.3/8.12.3) with ESMTP id g443H52D004168 for ; Fri, 3 May 2002 20:17:06 -0700 (PDT) Received: (from bjj@localhost) by pulsar.home.ben.com (8.11.6/8.6.12) id g443H3c02194 for freebsd-net@freebsd.org; Fri, 3 May 2002 20:17:03 -0700 (PDT) Date: Fri, 3 May 2002 20:17:03 -0700 From: Ben Jackson To: freebsd-net@freebsd.org Subject: ip_output: why IPSEC before IPF/IPFW? Message-ID: <20020504031703.GA2184@pulsar.home.ben.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 I have a FreeBSD box connected to my cable modem which NATs for the rest of my home network. Recently I set up IPSEC between that box and a few others as an experiment. Direct connections between these boxes work fine. However, since ip_output checks IPSEC before IPF/IPFW, my ipnat rules for the inside hosts are not applied until after the IPSEC check. Since they don't match the IPSEC rule (which is point-to-point, using transport mode) they fall through, get rewritten by ipnat into packets which WOULD match the SAD, and then sent directly. The far end rejects them because its policy is "require" ESP. Obviously this would work if I had *two* FreeBSD boxes, and had the "outermost" one handle only IPSEC and the "inner" one do IPF, but wouldn't it be easier to just move the IPSEC test below IPF/IPFW? ip_input would also have to change, but it's already in the right order, it just skips the IPF/IPFW section in the event of IPSEC traffic. Please CC me on the reply, I'm not on the list. Thanks. -- Ben Jackson http://www.ben.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri May 3 22:20:15 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 9B77837B41D for ; Fri, 3 May 2002 22:20:06 -0700 (PDT) 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 <20020504052006.EKWO2627.rwcrmhc54.attbi.com@InterJet.elischer.org>; Sat, 4 May 2002 05:20:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA85889; Fri, 3 May 2002 22:10:57 -0700 (PDT) Date: Fri, 3 May 2002 22:10:56 -0700 (PDT) From: Julian Elischer To: Ben Jackson Cc: freebsd-net@freebsd.org Subject: Re: ip_output: why IPSEC before IPF/IPFW? In-Reply-To: <20020504031703.GA2184@pulsar.home.ben.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 Thanks for bringing this up.. I'm actually flabberghasted that it's so. I've been assuming it was the other way around. The advantage of having it the other way would be to be able to do other evil things to ipsec packets, but as it is you can totally block all packets and ipsec will still work.. but that's certainly not POLA.. because we tell teh world that the ipfw works on ALL packets. I'd vote to reverse it... On Fri, 3 May 2002, Ben Jackson wrote: > I have a FreeBSD box connected to my cable modem which NATs for the rest > of my home network. Recently I set up IPSEC between that box and a few > others as an experiment. Direct connections between these boxes work fine. > > However, since ip_output checks IPSEC before IPF/IPFW, my ipnat rules > for the inside hosts are not applied until after the IPSEC check. Since > they don't match the IPSEC rule (which is point-to-point, using transport > mode) they fall through, get rewritten by ipnat into packets which WOULD > match the SAD, and then sent directly. The far end rejects them because > its policy is "require" ESP. > > Obviously this would work if I had *two* FreeBSD boxes, and had the > "outermost" one handle only IPSEC and the "inner" one do IPF, but wouldn't > it be easier to just move the IPSEC test below IPF/IPFW? > > ip_input would also have to change, but it's already in the right order, > it just skips the IPF/IPFW section in the event of IPSEC traffic. > > Please CC me on the reply, I'm not on the list. Thanks. > > -- > Ben Jackson > > http://www.ben.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 Fri May 3 22:38:23 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 2A2C837B419 for ; Fri, 3 May 2002 22:38:21 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g445cCx27004; Fri, 3 May 2002 22:38:12 -0700 (PDT) (envelope-from rizzo) Date: Fri, 3 May 2002 22:38:12 -0700 From: Luigi Rizzo To: Julian Elischer Cc: Ben Jackson , freebsd-net@FreeBSD.ORG Subject: Re: ip_output: why IPSEC before IPF/IPFW? Message-ID: <20020503223812.C26854@iguana.icir.org> References: <20020504031703.GA2184@pulsar.home.ben.com> 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 Fri, May 03, 2002 at 10:10:56PM -0700, Julian Elischer wrote: ... > Thanks for bringing this up.. > I'm actually flabberghasted that it's so. I've been assuming it was the > other way around. > The advantage of having it the other way would be to be able to do other > evil > things to ipsec packets, but as it is you can totally block > all packets and ipsec will still work.. > but that's certainly not POLA.. because we tell teh world that > the ipfw works on ALL packets. except when we use ipfastforwarding, which is also anything but POLA... cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 4 14:39:52 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 2B07137B404 for ; Sat, 4 May 2002 14:39:34 -0700 (PDT) Received: from localhost (bwhite@localhost) by moab.cs.utah.edu (8.9.1/8.9.1) with ESMTP id PAA25666 for ; Sat, 4 May 2002 15:39:33 -0600 (MDT) Date: Sat, 4 May 2002 15:39:33 -0600 (MDT) From: Brian White To: freebsd-net@FreeBSD.ORG Subject: FBSD 4.3 New Reno Fast Retransmit Behavior 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'm seeing what I believe to be a bug in FreeBSD 4.3's New Reno fast retransmit algorithm-- delays of up to 1 second between retransmissions. Would someone please verify and/or correct me? If this is a bug, has it been fixed? I'm using dummynet between two nodes to drop the 10th _data_ packet in a TCP stream. I have seen this both with 0 and 100 ms configured delays. Obviously, the drop happens in slow start. In _both_ cases, I have set the slowstart_flightsize (local and non-local) to 2. There seem to be two problematic cases. In the first, _both_ of these conditions fire in tcp_input.c: else if (++tp->t_dupacks == tcprexmtthresh) { and if (tcp_do_newreno && SEQ_LT(th->th_ack, tp->snd_recover)) { The behavior is such that upon receiving the triple duplicate ACK for the dropped packet, the next packet in the stream is transmitted. Instead of the retransmission. The sender then receives another ACK and promptly waits hundreds of ms (up to 1 second) before finally doing the retransmission. This is the first tcpdump below. In the second case, neither of the above conditionals fire. i.e. no triple duplicate ack detection? Only 3 ACKs are received in this case. Then a 1 second wait and finally the retransmission. tcpdump Case 2 below. I'm a bit out of my league here. But, it looks to me that regardless of triple duplicate ACK detection, the packet is retransmitted because of a timeout? Is that "analysis" correct? Is it correct behavior? The delays are annotated with a comment (#) below. Much thanks. Brian Case 1: 15:13:32.547864 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: S 3599924535:3599924535(0) win 16384 (DF) 15:13:32.548083 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: S 2723034168:2723034168(0) ack 3599924536 win 28800 (D F) 15:13:32.548112 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . ack 1 win 17280 (DF) 15:13:33.547691 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 1:961(960) ack 1 win 17280 (DF) 15:13:33.547699 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: P 961:1001(40) ack 1 win 17280 (DF) 15:13:33.548428 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 1001 win 27800 (DF) 15:13:33.548456 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 1001:1961(960) ack 1 win 17280 (DF) 15:13:33.548466 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 1961:2921(960) ack 1 win 17280 (DF) 15:13:33.548475 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 2921:3881(960) ack 1 win 17280 (DF) 15:13:33.549409 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 1961 win 28800 (DF) 15:13:33.549425 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 3881:4841(960) ack 1 win 17280 (DF) 15:13:33.551401 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 3881 win 27840 (DF) 15:13:33.551416 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 4841:5801(960) ack 1 win 17280 (DF) 15:13:33.551426 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 5801:6761(960) ack 1 win 17280 (DF) 15:13:33.552410 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 4841 win 28800 (DF) 15:13:33.552426 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 6761:7721(960) ack 1 win 17280 (DF) 15:13:33.554402 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 6761 win 27840 (DF) 15:13:33.554417 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 7721:8681(960) ack 1 win 17280 (DF) 15:13:33.554426 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 8681:9641(960) ack 1 win 17280 (DF) 15:13:33.554435 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 9641:10601(960) ack 1 win 17280 (DF) 15:13:33.556131 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 7721 win 28800 (DF) 15:13:33.556147 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 10601:11561(960) ack 1 win 17280 (DF) 15:13:33.556414 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 7721 win 28800 (DF) 15:13:33.557396 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 7721 win 28800 (DF) 15:13:33.558400 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 7721 win 28800 (DF) 15:13:33.563881 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 11561:12521(960) ack 1 win 17280 (DF) 15:13:33.570055 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 7721 win 28800 (DF) # excessive delay here 15:13:34.547493 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 7721:8681(960) ack 1 win 17280 (DF) 15:13:34.548222 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 12521 win 24000 (DF) 15:13:34.548246 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 12521:13481(960) ack 1 win 17280 (DF) 15:13:34.548256 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 13481:14441(960) ack 1 win 17280 (DF) Case 2: 15:13:17.728243 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: S 4011861307:4011861307(0) win 16384 (DF) 15:13:17.729122 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: S 3443738345:3443738345(0) ack 4011861308 win 28800 (D F) 15:13:17.729150 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . ack 1 win 17280 (DF) 15:13:18.748002 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 1:961(960) ack 1 win 17280 (DF) 15:13:18.748009 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: P 961:1001(40) ack 1 win 17280 (DF) 15:13:18.750040 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 1001 win 28760 (DF) 15:13:18.750065 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 1001:1961(960) ack 1 win 17280 (DF) 15:13:18.750074 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 1961:2921(960) ack 1 win 17280 (DF) 15:13:18.750084 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 2921:3881(960) ack 1 win 17280 (DF) 15:13:18.752196 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 2921 win 27840 (DF) 15:13:18.752212 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 3881:4841(960) ack 1 win 17280 (DF) 15:13:18.752222 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 4841:5801(960) ack 1 win 17280 (DF) 15:13:18.752231 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 5801:6761(960) ack 1 win 17280 (DF) 15:13:18.753206 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 3881 win 28800 (DF) 15:13:18.753222 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 6761:7721(960) ack 1 win 17280 (DF) 15:13:18.755197 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 5801 win 27840 (DF) 15:13:18.755213 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 7721:8681(960) ack 1 win 17280 (DF) 15:13:18.755222 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 8681:9641(960) ack 1 win 17280 (DF) 15:13:18.756204 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 6761 win 28800 (DF) 15:13:18.756219 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 9641:10601(960) ack 1 win 17280 (DF) 15:13:18.758197 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 7721 win 28800 (DF) 15:13:18.758212 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 10601:11561(960) ack 1 win 17280 (DF) 15:13:18.759192 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 7721 win 28800 (DF) 15:13:18.760190 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 7721 win 28800 (DF) # delay here 15:13:19.757836 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 7721:8681(960) ack 1 win 17280 (DF) 15:13:19.759034 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 11561 win 24960 (DF) 15:13:19.759057 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 11561:12521(960) ack 1 win 17280 (DF) 15:13:19.759066 192.168.1.2.commplex-link > 192.168.1.3.commplex-link: . 12521:13481(960) ack 1 win 17280 (DF) 15:13:19.759081 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 11561 win 28800 (DF) 15:13:19.761006 192.168.1.3.commplex-link > 192.168.1.2.commplex-link: . ack 13481 win 27840 (DF) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 4 16: 1:18 2002 Delivered-To: freebsd-net@freebsd.org Received: from syn.codemonkey.net (h24-76-106-61.vc.shawcable.net [24.76.106.61]) by hub.freebsd.org (Postfix) with ESMTP id 45E3E37B41C for ; Sat, 4 May 2002 16:00:56 -0700 (PDT) Received: from syn.codemonkey.net (jason@localhost [127.0.0.1]) by syn.codemonkey.net (8.12.2/8.12.1) with ESMTP id g44N0Xqq018239; Sat, 4 May 2002 16:00:33 -0700 (PDT) Received: (from jason@localhost) by syn.codemonkey.net (8.12.2/8.12.0/Submit) id g44N0Mu3010094; Sat, 4 May 2002 16:00:22 -0700 (PDT) X-Authentication-Warning: syn.codemonkey.net: jason set sender to jason@codemonkey.net using -f To: Julian Elischer Cc: Ben Jackson , freebsd-net@FreeBSD.ORG Subject: Re: ip_output: why IPSEC before IPF/IPFW? References: From: Jason Ish Date: Sat, 04 May 2002 16:00:22 -0700 In-Reply-To: (Julian Elischer's message of "Fri, 3 May 2002 22:10:56 -0700 (PDT)") Message-ID: <87pu0b7c3d.fsf@syn.codemonkey.net> Lines: 18 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.1 (Cuyahoga Valley, i386-unknown-openbsd3.0) 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 Julian Elischer writes: > Thanks for bringing this up.. > I'm actually flabberghasted that it's so. I've been assuming it was the > other way around. > The advantage of having it the other way would be to be able to do other > evil > things to ipsec packets, but as it is you can totally block > all packets and ipsec will still work.. > but that's certainly not POLA.. because we tell teh world that > the ipfw works on ALL packets. > > I'd vote to reverse it... You have to be careful when you reverse it. If you are doing NAT and have IPsec tunnels that are supposed to tunnel your private addresses the packets will be NAT'd before matching an IPsec policy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 4 21:17:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 7267237B416; Sat, 4 May 2002 21:17:31 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g454HQA28992; Sat, 4 May 2002 22:17:26 -0600 (MDT) (envelope-from ken) Date: Sat, 4 May 2002 22:17:26 -0600 From: "Kenneth D. Merry" To: current@FreeBSD.org Cc: net@FreeBSD.org Subject: zero copy sockets patches available Message-ID: <20020504221726.A28940@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have released a new zero copy sockets snapshot; the patches are against yesterday's (May 3rd) -current. The astute reader may note that it has been quite a while (November 2000) since my last zero copy code release, and all I can say is "time, motivation, lack of local equipment". Anyway, the code and a FAQ (I've updated it a bit, but not thoroughly) is available here: http://people.freebsd.org/~ken/zero_copy/ Comments, questions, reviews are all welcome. A sample benchmark: {gondolin:/usr/local/netperf:15:0} ./netperf -H nargothrond-ge TCP STREAM TEST to nargothrond-ge : histogram Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 262144 262144 262144 10.01 989.06 That, in and of itself, is unremarkable. I can get that sort of speed going between two machines running -stable. (In fact the sender is running -stable, the receiver is running -current.) The remarkable thing here is the CPU utilization on the receiver -- only about 35% on average during the 10 second run. If I turn off zero copy receive, CPU utilization on the receiver goes up to around 60% or so. The difference is a bit larger on the send side. Before you ask "can I do this on my system??", please see item 4 of the FAQ. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat May 4 22:15: 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 DF3B037B417 for ; Sat, 4 May 2002 22:15:02 -0700 (PDT) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA97013; Sat, 4 May 2002 22:08:44 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g4558ij09336; Sat, 4 May 2002 22:08:44 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200205050508.g4558ij09336@arch20m.dellroad.org> Subject: Re: ip_output: why IPSEC before IPF/IPFW? In-Reply-To: <87pu0b7c3d.fsf@syn.codemonkey.net> "from Jason Ish at May 4, 2002 04:00:22 pm" To: Jason Ish Date: Sat, 4 May 2002 22:08:43 -0700 (PDT) Cc: Julian Elischer , Ben Jackson , 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 Jason Ish writes: > > I'd vote to reverse it... > > You have to be careful when you reverse it. If you are doing NAT and > have IPsec tunnels that are supposed to tunnel your private addresses > the packets will be NAT'd before matching an IPsec policy. ISTR that the KAME guys asked the lists about this exact question, ie., whether IPSec or ipfw should come first.. so there may be a useful discussion archived somewhere. -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